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 has been released. Updates include:
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.
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.
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:
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).
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 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.
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.