Archive for the ‘Xsan’ Category

318 CatDV Installation Checklist

Wednesday, January 11th, 2012

318 has been doing a lot of work with CatDV recently and as such, we are starting to build a large library of assets for the product. We have built a checklist for the installation and planning of a CatDV asset management system. The checklist is a quick guide to server installation, worker nodes, client configuration, using SSL, watch folders, conditions, queries, conversations and processing.

The checklist can be downloaded here:

318 CatDV Installation Checklist

318 CatDV Installation Checklist

For more information about CatDV, related storage issues or other aspects of your technology environment, please feel free to contact your Professional Services Manager or sales@318.com. For more information about 318, see us on the web at 318.com.

Monitoring Xsan with Nagios and SNMP

Monday, December 12th, 2011

Monitoring a system or device using SNMP (a SonicWALL, for instance) is simple enough, provided you have the right MIB. XSNMP is an Open Source project that provides a simple Preference Pane to manage SNMP on OS X, and it also includes an MIB developed by LithiumCorp. This MIB provides OS X’s SNMP agent to gather and categorize information relating specifically to Mac OS X, Mac OS X Server, and Xsan.

XSNMP-MIB can be downloaded from GitHub, or directly from Lithium.

Download the XSNMP-MIB.txt file and put it in /usr/share/snmp/mibs. You can verify that the MIB is loaded by running snmpwalk on the system, specifying the XSNMP Version OID. If snmpwalk returns the version, the MIB is installed correctly. If it returns an error about an “Unknown Object Identifier”, then the MIB isn’t installed in the right spot.

bash$ snmpwalk -c public -v 1 my.server.address XSNMP-MIB::xsnmpVersion
XSNMP-MIB::xsnmpVersion.0 = Gauge32: 1

The fact that the MIB was developed by Lithium doesn’t stop us from using it with Nagios, though. You can define a Nagios service to gather the free space available on your Xsan volume by adding the following to a file called xsan_usage.cfg. Put the file in your Nagios config directory.

define service{
host_name xsan_controller
service_description Xsan Volume Free Space
check_command check_snmp!-C public -o xsanVolumeFreeMBytes.1 -m XSNMP-MIB
}

The host_name should match the Nagios host definition for your Xsan Controller. The service_description can be any arbitrary string that makes sense and describes the service.

The check_command definition is the actual command that’s run. The -C flag defines the SNMP community string, the -m flag defines which MIB should be loaded (you can use “-m all” to just load them all), and the -o flag defines which OID we should return. “xsanVolumeFreeMBytes.1″ should return the free space, in MB, of the first Xsan volume.

Final Cut Server EOL’d – What do we do now?

Friday, December 9th, 2011

318 has been working to provide our clients with a strategy to replace Final Cut Server, now that FCS has been EOL’d by Apple. We are proud to announce a comprehensive strategy and solution in the form of CatDV Enterprise Server and Client, by Square Box Systems, LTD.

The first question should always be, “Do we need to implement a new solution?” In many cases, and at least for now, the answer may be “No, not yet.” There will come a time, however, when the needs of the workflow, software, hardware, or some other factor will necessitate a new Digital Asset Management (DAM) System implementation.

Once the decision has been made to deploy a new DAM, many additional questions will arise. How do we keep our metadata intact? Can we re-use our clip and edit proxies? How do we keep our current automations? 318 can work with you to address these issues. We are asking ourselves the same questions with an eye towards minimizing the hassles associated with migrating such a major piece of infrastructure.

318 has spent the last year evaluating many of the DAM solutions in the marketplace, with an emphasis on whether or not the solution is an appropriate replacement for Final Cut Server in terms of cost, functionality and scalability, and after many internal discussions, CatDV best matched these criteria. In terms of cost, CatDV is one of the most affordable solutions in the marketplace. In terms of functionality, CatDV matches or exceeds the functionality of Final Cut Server. In terms of scalability, CatDV far exceeds the capabilities of Final Cut Server.

The final link in the chain is migrating data and recreating workflows from Final Cut Server to CatDV. 318 has the facility and ability to migrate your metadata with a minimum of user intervention. We also have the ability to analyze your Final Cut Server workflows and re-create the functionality in CatDV, including shell scripting and highly customized workflow integrations for ingest and archive.

We are a CatDV authorized reseller, and have staff trained by CatDV personnel. 318 stands ready to spec, deploy, configure and maintain your CatDV solution and help you with the transition from your Final Cut Server to CatDV. Please don’t hesitate to contact us for a demo and discussion of what CatDV can do for your video workflows.

Finally, 318 is working with other vendors to continue expanding our portfolio of SAN and DAM solutions. Keep on the lookout for what will hopefully be a few other additions once our thorough vetting process has been completed! If you would like further information on any of this, please feel free to contact your Professional Services Manager or sales@318.com if you do not yet have one.

The All New Promise x30

Wednesday, April 13th, 2011

Yesterday, we mentioned Thunderbolt adapters for Xsan. But NAB 011 isn’t over and we have more announcements to bring up. Promise has announced their all new x30 series. With a spiffy new chassis design, these things now sport 8Gbps controllers, up to 48TB of space and up to 8 in a stack (that’s 7 expansion per chassis).

Oh, and we’d be remiss not to mention the redesigned management screen, a massive improvement over the command and control pane of glass we had before! A web-based management tool, by the way, that works on iPad! And management is easier now that you don’t have to restart the units every time you need to make a software update.

For more information on the new Promise x30, see:

http://www.promise.com/storage/raid_series.aspx?region=en-US&m=1053&sub_m=sub_m_8&rsn1=40&rsn3=48

To discuss how 318 can assist your organization in leveraging these new tools from Promise, from integrating a fleet of MacBook Pros with Xsan to bolting on additional storage for the always-full Xsan, contact your 318 Professional Services Manager, or sales@318.com if you do not yet have one!

ActiveSAN, the Metadata Appliance!

Monday, January 31st, 2011

For those concerned about the disappearance of the highly rack dense systems that are fibre channel enabled from Apple’s portfolio, now there is ActiveSAN:

318 is an Active Storage reseller. Please feel free to contact your Professional Services Manager or sales@318.com if you do not yet have a Professional Services Manager and we will work with you to find the best solution to any and all Xsan client needs.

Final Cut Server Client for iPad

Wednesday, January 19th, 2011

Yes, you heard that right. You can now browse assets, edit metadata, annotate clips and download clip proxies from Final Cut Server using an iPad.

ClipTouch, from Factorial in New Zealand is a slick, sleek client for Final Cut Server. Per the Factorial website, it supports:

– No server configuration required
– Search and discover assets
– Directly download and view clip proxies
– Supports the default proxy setting
– Clip timecode display
– Change asset metadata
– Browse and add annotations
– Archive and Restore assets to any archive device
– Respects permission sets based on your login
– Supports direct and VPN connections

After using it to view some assets were optimized using the special compressor settings that Factorial posted, I have to say that I’m impressed with how well it works and with how the interface just looks plain sexy. A job well done! Check it out on the App Store.

Defragmenting an Xsan Volume to Reallocate Storage

Friday, January 14th, 2011

In the life of an Xsan shop, you will at one point or another be presented with the need to defragment your volume. Defragmenting a volume is a good way to recover lost performance, but can also be beneficial in other scenarios: defragging is an absolute must after performing a bandwidth-style expansion of your volume, and is often recommended (though not absolutely necessary) when performing a capacity-style expansion. In case you’re confused, a bandwidth expansion is the type of expansion performed when you add LUNs to a specific storage pool. Conversely, a capacity expansion involves simply adding new storage pools to an existing volume.

Because the make-up of a storage pool is drastically altered when a bandwidth expansion is performed, the data is not properly distributed across any of the new LUNs that were added to the pool, this results in a shadow-effect where all capacity of the storage pool is not available for use by the system. Because of this, it is an absolute requirement that a defrag routine is ran. To perform this defrag, we use the standard snfsdefrag command, but we use the special ‘-d’ flag, which ensures that this shadowed storage space is reclaimed and that data is properly distributed across the storage pool:

snfsdefrag -dr /Volumes/MyXsanVolume

There are several scenarios where it may be desirable to rebalance the data on an existing volume. A capacity expansion of a volume will result in one or more new storage pools being added to the volume, but the new storage will not have any data written to it. Alternatively, an allocation strategy of round-robin or fill can, over time, result in a poor distribution of data across your storage. By spreading data across the storage evenly, you ensure that all disks are running at similar capacities, therefore netting more consistent performance across the volume, as disk performance tends to degrade as capacity increases.

When an snfsdefrag is ran, it will defragment files as specified by your parameters, and these files will be distributed onto the volume as per your allocation strategy. If you defragment a volume that has a ‘Fill’ allocation strategy, you will not gain any benefits of having evenly distributed data, though your individual files will no longer be fragmented.

Thus, if your main goal is balance all data across the volume, it will be necessary to change the volume’s allocation strategy to Balance and then defragment the volume. This will result in fragmented files to be relocated the lowest-capacity pool, an extremely effective method for balancing data. In Xsan 2.x, you can change a volume’s allocation strategy at the GUI level, which can be changed while the volume is live. In our experience, the change can be performed live and will not result in Xsan client service interruption to the volume, and active transfers proceed with no disruption. Even so, it’s best to perform the switch at a time when there’s minimal activity (preferably none) on the volume and no active transfers in progress.

Once you’ve converted the volume to the new strategy, you can proceed with the optimization, which is a fairly straightforward defrag performed with the command

snfsdefrag -r /Volumes/VolumeName

This will defragment any files with more than one extent, re-provisioning the optimized files to the next LUN in the allocation strategy. And because we’re now using the Balance strategy, the next LUN will always be the one with the lowest capacity—-our new LUNs, in this case. If, however, you had a healthy Xsan volume, this command may not properly balance data, because fragmented files will be rare. In such an event, run the command

snfsdefrag -r -m 0 /Volumes/VolumeName

This will defragment files with more than 0 extents, which is every file on the system, letting you rest assured that the volume will be nicely balanced at the end of the operation. The main trade off here is that doing so re-provisions all files on the volume, which can be a very time consuming task. If the volume has standard levels of fragmentation, running the command without the flag should do a decent job of balancing without having to operate against non-fragmented files as well.

PresSTORE Article on Xsanity

Tuesday, November 16th, 2010

We have posted a short article on the availability of PresSTORE 4.1 on Xsanity at http://www.xsanity.com/article.php/20101116105720183. Enjoy!

Building MultiSAN with Xsan 2.x

Monday, April 26th, 2010

In Xsan 2, MultiSAN was introduced. MultiSAN allows you to assign different sets of primary, secondary and tertiary metadata controllers to volumes. This provides a performance benefit for some environments that have saturated resources on a given metadata controller. However, MultiSAN does not allow you to build separate SANs. All of the volumes are still members of that single “Xsan”, meaning that volumes can be mounted and/or controlled for any of the clients. You can have 2 volumes, each with a dedicated metadata controller, but both sharing a single backup metadata controller. You can also have 2 volumes, each with a dedicated metadata controller that fails over to the other metadata controller.

But if you do have 2 SANs, completely separate from one another, you cannot then have a client on both. Therefore, having multiple SANs isn’t exactly MultiSAN. MultiSAN means going from having a single metadata controller that controls your entire environment to having a slightly more object-oriented approach to metadata controllers. Which brings us to the question “do I need MultiSAN?” My answer is an if/then statement. If your metadata controller’s fsm or fsmpm processes are spiraling out of control then yes, you may (or you may have corruption in metadata somewhere. For coming up with the answer to my question I posted an Xsan monitor app awhile back on my apps page. But if your fsm/fsmpm processes barely tip above 1% and you’re still having bandwidth problems then look at stripe breadth/block size, fabric and defragmentation before considering buying a bunch of iron to move metadata controlling off onto dedicated hardware.

Now, if you do decide to integrate MultiSAN then to do so is a very straight forward process. First add the all of the metadata controllers as clients to the SAN. Then, create the volume. When creating a volume you will eventually come to a screen to define Volume Failover Priority. Here, you will see each of the clients that you have installed (in the beginning this might only be the metadata controllers). Check the box for each of the clients that you would like to be a metadata controller (I recommend no less than two but in most installations no more than 3 metadata controllers per volume). In this screen you can then also set priority by dragging each controller higher or lower in the list of controllers. If you only have two metadata controllers then the primary would be at the top of the list followed by the backup metadata controller. When you are satisfied with your configuration click on the Continue button and complete the volume configuration as you normally would. You can also invoke the Volume Priority screen from within Xsan Admin for pre-existing volumes.

This article was initially posted at http://krypted.com/mac-os-x-server/defining-multisan/

New ActiveStorage iPhone App

Tuesday, January 26th, 2010

Active Storage has released a new iPhone app that you can use to monitor the status of their new XRAID ES. If you are interested in the Active Storage products then please call 318 at 310-581-9500 for more information and pricing.

The App is available on the App Store.

Xsan 2.2.1

Friday, December 18th, 2009

Xsan 2.2.1 has been released. Updates include:

  1. Improved filesystem reliability
  2. Improved cvfsck (the Xsan filesystem repair tool)
  3. Resolves QuickTime reporting “invalid public movie atom found” on playback
  4. Eliminates “An unknown disk has been inserted” message when mounting Xsan volumes (occurs in Mac OS X 10.5 Leopard only)

Video: Creating a Device on Final Cut Server

Wednesday, July 29th, 2009

BRU Server 2.0 Now Available

Friday, July 24th, 2009

BRU Server 2.0 was released this week, offering a long anticipated update to the popular cross platform backup suite of applications. The main two features that the TOLIS group is highlighting include Encryption of backup target sets and client initiated backup.

Whether you are a BRU, Atempo, Bakbone, Backup Exec or Retrospect environment, 318 can assist you with planning, testing, verifying or restoring backups. Contact your 318 account manager today for more details.

Final Cut Server on the Cheap

Monday, July 13th, 2009

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 & Vguard for Xsan

Thursday, July 9th, 2009

Vmeter is another great product that you can bolt onto your Xsan from Vicom Systems. Vmeter allows you to get
Vmeter SQL Statistics 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.

Xsan and Final Cut Server Monitors

Friday, May 1st, 2009

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.

EMC Celerra NX4 Defaults

Wednesday, April 15th, 2009

The EMC Celerra NX4 comes with a number of IPs (and other settings) set from the factory. The IP addressing, by default, is as follows:

  • Primary Internal Network – 128.221.252.100
  • Backup Internal Network – 128.221.253.100
  • Netmask 255.255.255.0
  • IP of Storage Processor A – 128.221.252.200
  • IP of Storage Processor B – 128.221.253.201
  • Gateway IP of Storage Processor A – 128.221.252.104
  • Gateway IP of Storage Processor B – 128.221.253.104

New article on Xsan Scripting by 318

Saturday, April 11th, 2009

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.

License.dat and StorNext

Tuesday, March 10th, 2009

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).

Mac OS X: Using tail

Saturday, August 16th, 2008

You can dynamically watch new lines come into log files in Mac OS X. In order to do this you can use the tail command with the -f switch. So if you want to watch your system.log file and run some processes you think will cause errors you can use the following command:

tail -f system.log

ZFS: What was all that fuss about?

Friday, November 2nd, 2007

ZFS was released by a team at Sun in November of 2004. The name stands for “Zettabyte File System”. ZFS is a 128-bit file system, so it can store 18 billion billion (18.4 × 1018) times more data than current 64-bit systems. We’re not going to sit here and do the math for that but you are more than welcome to figure out what the theoretical size is at that point – all we can say is that it’s friggin’ huge.

Traditional file systems reside on single devices and require a volume manager to use more than one device to generate a logical or physical volume. ZFS is built on top of virtual storage pools called zpools. A zpool is constructed of virtual devices called vdevs. Vdevs are constructed of block devices that include files, partitions, or drives. Block devices within a vdev can be configured in a variety of different manners, depending on the needs of a user. The storage capacity of all vdevs is available to all of the file system instances in the zpool. This is similar in some ways to how Xsan builds volumes, but more customizable and without a requirement for vdevs to be based on Fibre Channel storage in order to be accessible by multiple hosts.

Quotas can be set to limit the amount of space a file system instance can occupy and a reservation can be set to guarantee that space will be available to a file system instance. This gives some nice features to those wanting to limit access for some volumes while still making sure other volumes have the space that will be required for planned future possible expansions. Other features of ZFS include: snapshots, write-cache, filesystem based encryption (in Alpha stage of development) and checksumming.

While users of Leopard may be disappointed in the fact that ZFS did not make it in the final build, giving greater volume sizes and more features for volume management, rest assured that Apple will be thoroughly testing any new file systems before making them available to the public and that with something as precious as a file system, if it wasn’t ready for prime time then it’s good that it wasn’t included with Leopard. ZFS is still going through changes and is not a completed or matured project by any stretch of the imagination. In /Library/FileSystems you will see that ZFS is not present but the framework for future ZFS is present which can be seen by the introduction of some ZFS binaries to the system. So keep a look out for ZFS in the future and maybe even an SDK from SUN on using it at some point.

Xsan: Sometimes You’re Going to Loose a Drive

Wednesday, April 4th, 2007

Sometimes a drive fails, or a RAID controller goes down on an array with a redundant drive and the parity on a RAID must be rebuilt. In other words, if you loose a drive in a RAID 5, RAID 1, RAID 0+1 or RAID 3 array you will be left with a degraded RAID (also referred to as a critical RAID) unless you have configured your Xserve RAID to use a hot spare. If you are using a hot spare on the channel of the failed drive the RAID will begin to rebuild itself automatically. If you are not using a hot spare, upgrading your degraded RAID back to a healthy state should happen as quickly as possible to avoid data loss. In the event of a second drive failure on the array most of the data could be lost – and Murphy’s Law is evil when it comes to RAIDs. The data should be backed up as quickly as possible if it has not already been backed up.

Once the data is backed up, you should perform a rebuild of the parity for the array. The partiy is rebuilt based on the data that is on the array. This does not fix any issues that may be present with actual data. In other words, if you were using the Xserve RAID as a local volume it would only repair issues with the array and not also perform a repair disk on the drives. In an Xsan any data corruption could force you to rebuild you volume from the LUNs. You would not need to relabel the LUNs, but you may have to rebuild your volume

In many situations you will be able to simply swap the bad drive out with an identical good drive and configure it as a hot spare. Then the Xserve RAID will automatically begin rebuilding the array, moving it from a degraded state into a healthy state.

However, there are often logical issues with drives and arrays. Also, hot spares do not always join the degraded array. In these situations you may need to manually rebuild an array. To do this:
Silence the alarm on the Xserve RAID.
Verify that you have a clean backup of your data.
Verify that you have a clean backup of your data again or better, have someone else check as well.
Open up your trusty Xserve RAID Spare Parts Kit and grab the spare drive module.
Remove the drive module that has gone down (typically the one with the amber light).
Install the new drive in your now empty slot.
Open RAID Admin from the /Applications/Server directory.
Click on the RAID containing the damagemed array.
Click on the Advanced button in the toolbar.
Enter the management password for the Xserve RAID you are rebuilding the parity for.
Click on the button for Verify or Rebuild Parity and click on Continue.
Select the array needing to be rebuilt.
Click Rebuild Array and be prepared to wait for hours during the rebuild process. It is possible to use the array during the rebuild process – although if you don’t have to use the array it is probably best not to as you will see a performance loss. During the rebuild the lights on the drive will flash between an amber and a green state.
Once the rebuild is complete, perform a Verify Array on the RAID.
Verify the data on the volumes using the array.
Order a new drive to replace the broken drive in your Xserve RAID Spare Parts Kit.

If the rebuild of the data does not go well and the array is lost then you will likely need to delete the array and readd it. This will cause you to loose the data that was stored on that array and possibly on the volume, so it can never hurt to call Apple first and see if they have any more steps you can attempt. This is one of the many good reasons for backing data up. Just because you are using a RAID does not mean you should not back your data up.

The Verify Array can also be used to help troubleshoot issues with corrupted arrays.

This process has been tested using firmware 1.5 and below for Xserve RAIDs.