Xsan 2.2.1 has been released. Updates include:
At 318 we see a number of Final Cut Server installations. And for most of those jobs you should use an Xsan, have editors edit-in-place and develop custom automations. But Final Cut Server doesn’t have to be super complicated; nor does it have to be super expensive to integrate. At the end of the day it’s all about what a customer is expecting to get out of the product – and that’s how the product is developed and priced: to scale with the customers needs.
One of the most marketable and best features of Final Cut Server is that it is a way to catalog assets. These assets can be stored anywhere you want, provided that they are reliably accessible by the server. Given a username and password, users of Final Cut Server can then access the assets whether or not they can actually get to them using server shares or flat file systems. This allows Final Cut Server to bring logic to an otherwise chaotic form of storing data.
Once catalogued you can then tag assets with metadata. This means that when you go to find assets in the future you can do so quickly and easily. You can preview, annotate and then download those assets, no matter where they are stored – even on a Drobo or some large Firewire media sets. And if you decide to edit-in-place in the future, the fact that assets are stored in a logical space (called a Device) means that if you see the value, that you have an easy upgrade into more online media, such as an Xsan volume – but you don’t have to do it all at once to start seeing value.
And value is the key aspect of Final Cut Server. You can spend as much or as little as you need in order to get value out of the product. Sometimes the smallest features are what organizations will derive the most value out of. Not always, but sometimes… And when you see the value of the smaller features you can then make a decision based on your organizations goals and workflows what else will be of value. If you’d like to discuss a Final Cut Server implementation, whether it’s the basic initial installation, complicated workflow integration or custom scripting, contact 318 for more information. We’re here to help, whether or not the implementation is on the cheap.
Vmeter is another great product that you can bolt onto your Xsan from Vicom Systems. Vmeter allows you to get
statistics of bandwidth allocation for Xsan clients. But Vmeter doesn’t stop there. It also allows you to meter, or limit, the amount of bandwidth that is allocated to client machines, maximizing bandwidth for some users and tiering your performance allocation.
Vguard, also by Vicom Systems, is based on the technology included in Vmirror, the LUN mirroring solution, but goes a step further. Vguard allows you to setup another Xsan and use that SAN as a backup. We’re not going to go so far as to call it a snapshot, but it’s everything but.
Overall, Vicom integrates well with Xsan and fills some of the holes that the product itself has. For more information on Vmeter, Vguard or Vmirror, contact your 318 account manager today.
The Xsan and Final Cut Server monitors have been announced at Xsanity and are now available for download. These will monitor processor and memory utilization of the Xsan and Final Cut Server processes respectively. SSH tunneling will hopefully be added soon so that you can run them remotely but that’s closer to a 1.x release rather than the .x release that is available.
318 has published another article on Xsanity, for scripting various notifications and monitors for Xsan and packaged up into a nice package installer. You can find it here
http://www.xsanity.com/index.php?topic=tips.
We recently did a post on Xsanity about integrating StorNext clients with Xsan. It is very important that when you’re doing this type of integration that you remember that all metadata controllers need to have that license.dat file. If they don’t then not all of your clients will failover properly. When you’re finished with the integration, we recommend backing up the entire /Library/FileSystems/Xsan/config directory and running a cvgather. This final step will also make sure that if you need to restore a metadata controller that you won’t have to have a new license.dat file generated (amongst others).
After a long silence on Xsanity, 318 has published the first of a number of articles for the site. The article focuses on how to install and configure StorNext clients running Red Hat Enterprise Linux (RHEL) to connect to an Xsan. It is available here.