January 2012, How-To Bulletin #3
Posted by Jordan Steinke on 31 January 2012 03:56 PM
January, 2012 How-To Bulletin #3
This month's contents:
To all of our customers and reseller partners;
Happy New Year to everyone, and we hope your winter time holidays were pleasant. 2012 is going to be an exciting year for us, and hopefully for all of you as well. We're sure that everyone has big plans for the new year, resolutions and what not. We've started ours, and we're sticking to them!
At the end of 2011 we released our Procyon. An HA platform with a 3U chassis solution with robust features and support for multiple workspaces. A week ago, as of this writing, we officially announced our Triton, a new single server edition of our BrightDrive occupying a mere 1U of rack space. Like our Procyon, Triton features our smartest BrightClip yet: BrightClip 2.0, and also features StorNext 4.2.
2012 is starting out with a bang, and we intend to keep it that way!
This month's issue takes a step back from a specific product how-to and addresses one of the issues we've been hearing about lately regarding rights management. It's an interesting read, even for myself on the sales side of the fence, and explores some of the causes and solutions of permisions and rights management in a SAN environment.
Brian Adams, our technical sales engineer, has also written an article regarding concurrency testing, and how we determine the realistic and predictable capabilities of our solutions, and to be cautionary with other solutions that promise more than they can deliver.
We hope you enjoy them both!
How to Feature By Roger Beck:
In a shared environment as in a Linux based NAS, the permission can be set via the exports file or the Samba configuration or even through yp (yellow pages aka NIS). Comparing it to a SAN based solution you will most likely run into permission issues which you haven't experienced before. Before each client was writing into the shared volume and all the others could collaborate as expected and since you have a SAN, you face the problem that content created by client-A can't be modified from client-B or others.
Due to the nature of SAN solutions, every client sees the shared workspace (volume) as a local disk because of the FC fabric underneath. This provides extreme fast access to the data for reads and write but has no rights management involved. StorNext which is the base layer for your BrightDrive isn't interested in dealing with permissions or any kind of rights management, hence while every client is the "owner" of this workspace they don't have any knowledge about those other clients.
As mentioned, the underlying StorNext layer has a "don't care" policy even you can read in the manuals that StorNext supports ACL (access control list), but only as a client function on the server and workspace itself.
To get around all this permission hassle you have basically 3 options to make your life easier again.
A) The big and may more expensive way is to have a Windows DC or a OS/X server which can act as a domain controller and support ACL. All client would authenticate against those domain controller and the workspace configuration can have ACL support enabled (not data destructive for a workspace). This is more expensive because it would need a dedicated server.
B) In case you have a Linux based server, you can setup and activate NIS. Also here you have to have the clients authenticate against this server. NIS is limited in the view of permission and not as granular as Windows DC or OS/X server but still a way to go. Only drawback on this might be the Windows world which can not native connect to a NIS server.
C) the most common way is to match IDs. This can be the UID (user ID) or the GID (group ID). Matching the UID is not as easy as it sounds because nowadays many vendors expect a certain UID or apply a new UID every time a new version of the application is installed. On OS/X i.e. it depends which username was created first.
The easiest solution seems to be the one where you squeeze all users into a common GID and change the umask so you allow other group members to modify your content. In case you are not aware of it, every user can be member of multiple groups.
i.e. You create a group called SAN-USER with GID 900 you simply have to create the /ect/groups file, add the new group and add the user to the new group. If has to be done on every Linux or MAC client of course.
The default umask is 0022 which will result in a permission mask of 755. While this won't allow other group members to modify files, you have to change the umask to 0002 (775 for files and 664 for directories).
We got Linux and OS/X to collaborate and now we tell Windows to do the same. There are variables for a workspace which can be set to enforce UID, GID and permissions, just like Samba. A reseller or the BTI TSG needs to make the modification on the workspace and a restart of the affected workspace will be required.
This should give you a bit more control and less file touching again.
Technical Sales: Concurrency Testing: How We Determine Stream Counts by Brian Adams
Nearly every other vendor of SAN storage for video reports "best case" stream counts. On a fresh file system, starting empty, they lay down some material at beginning of disk (BOD) where the performance is best, and the material will be contiguous since the file system is not yet fragmented. Then they "play" the material and see how many streams they can get. This is a valid number, but it's "best case" and does not represent a real volume in use.
At BTI, we do "worst case" testing: Lay down clips at BOD, middle of disk (MOD or 50% full), and end of disk (EOD or 99% full.) Now when we "play" those clips we are forcing the disk heads to seek frantically between BOD, MOD and EOD. If you could see the disk heads (our "topless demo" video on the web site) they will be a blur of motion. If we can get X real-time streams like that, it means we can actually list X streams in our documentation, even when the test clips are spread from BOD to EOD.
On top of that, with BrightClip we can generally state that the clips themselves (DPX sequences) will not be fragmented or scattered. Without BrightClip, our competition needs to not only force clips to BOD / MOD / EOD, they also need to expect the clip sequences will become scattered, so in actuality the worst case gets even worse without BrightClip!
For example, when we tested Astella, it could sustain 3 "2K" DPX streams at BOD / MOD / EOD. If I wanted to report "best case" (all BOD streams) it could do 4 or 5 streams!
I hope this makes clear there is more to stream count than meets the eye.
Back to Contents
A new version of DataMover has been released. Please contact email@example.com to inquire about a 30-day trial version!
Our Procyon has been met with enthusiasm in the installations we've already been part of. Being an entire HA solution in 3U of rackspace has significant advantages over other solutions: Reduced cooling needs, reduced energy consumption, even aesthetics if you're so inclined! Questions about our Procyon can be directed to firstname.lastname@example.org, or through our worldwide partner network.
We'd like to remind everyone about a few of our ongoing offers to under support customers:
Our next February How-To will feature another useful how-to, please look for that in your inbox towards the beginning of the month!
Bright Technologies, Inc.
10405 Double R Blvd
Reno, NV 89521
P +1 775.823.9002
F +1 775.201.0027
Watch our new BrightDrive Movie!
Back to Contents