Tag Archives: SAN

configure XSAN 4 – Yosemite – El Capitan

Situation

You want to connect an OSX 10.10 (Yosemite) or OSX 10.11 (El Capitan) client to your existing StorNext SAN or XSAN. Both OSX versions are XSAN 4 based.

Yosemite’s embedded XSAN version is compatible with SNFS 4.3 & 4.7.
The XSAN version within El-Capitan apparently is only compatible with StorNext 5.x but not with StorNext 4.7 as officially listed in the matrix.

I don’t claim to know it better as the officials from Quantum or Apple but if you look under the hood, the cvversion command returns a 4.3 build. Based on that and the knowledge that many other users have connected their XSAN 4 clients to a SNFS 4.7 based MDC’s without any issues of connectivity or data integrity (would be the worst case ever), it’s up to you to go that path and connect to an existing 4.7 based StorNext MDC and step outside the supported matrix.

Continue reading

StorNext labels gone? DON’T panic!

Topic

In SAN environments labels are often used to address a specific LUN, rather than using the device identifiers or numbers, to simplify the addressing of devices. Plus, a device does not have to be tied to a unique device number/id.

Losing a label due to a crash, or a defective hardware part or simply because a client overwrote the label, leaves the administrator in a quite scary und definitely uncomfortable situation. Data can’t be accessed or could even be lost.

Continue reading

StorNext performance: Allocation fill or round robin?

Topic

There are many ways to configure and optimize your file system under StorNext, and one option that makes (or can make) a difference is the allocation strategy. Which setting to use depends on your storage and the type of content you create. For the media and entertainment world we talk about unstructured data.

For the sake of this example, I create an imaginary setup with a StorNext based MDC and one 24bay RAID (dual controller) with 2 x 24bay expansion chassis. Continue reading

Never Mix Up Throughput or IOPS with Stream Performance

What to Know and What to Ask When You Shop for Storage at NAB or

How to Evaluate Different Storage Solutions for Post,  Where Real-Time Access Is Crucial

 

The most important mistake to avoid when evaluating a SAN (or NAS) storage solution is also the most common one: confusing throughput or IOPS with stream performance. Throughput or high IOPS will not provide you with the performance you need in a workflow with real-time access requirements.

And this is where it becomes tricky. Unfortunately not all storage vendors possess the expertise or experience to really understand the difference between the requirements of their standard industrial customers and their customers in the M&E or post-production sector. While industrial customers consider a storage setup with high throughput and IOPS to be high performance, customers in M&E need high (real-time) streaming performance. Bandwidth and IOPS are secondary, if not entirely irrelevant.  Post-production applications working with sequence-based raw (single frame) material write to and read from the storage sequentially, as opposed to unstructured IT environments where data is read and written randomly.

A pretty common and recurring situation when it comes to buying storage could look like this. A customer expects to have eight attached clients in total, six of which need real-time read/play in 2K raw, while two clients will require 4K raw access. Most customers do the math this way: 2 clients x 4K = 2400MB/s   +   6 clients x 2K = 1800MB/s; therefore a total throughput of 4200MB/s is required.

Since all storage vendors know what their products can do in regard to IOPS or random throughput, a vendor may tell the customer that they need, for example, two RAIDs, each providing 2500MB/s. Combined, that will provide the requested 4200MB/s, plus 800MB/s of overhead. For a standard IT-based environment, this calculation might be correct, and the SAN would probably be perfectly suitable. But when it comes to sequential and concurrent data access by more than one client at a time, the entire setup becomes a whole different beast. With a setup like this, the post-production facility will realize a couple of weeks after the SAN has been deployed that the performance is far below the eight concurrent streams they actually needed.

What went wrong? Our example customer XYZ’s requirements have not been accounted for, or – even worse – were not understood in full. To explain this in a pictographic example, customer XYZ needed a setup that was able to play two songs from a record at the same time – and vendor ZYX provided one turntable record player. Now the customer has to lift the arm of the record player (seeking) and move it to the new position on the record (latency), then lift the arm again to return it to the original position (seeking and latency) and start from the beginning. Every time the arm is lifted, there will be no music playing, no matter how fast the arm is moved.

 

Read full article at studiodaily.com