Posts Tagged ‘Xsan’

Xsan & Media Composer

Monday, April 22nd, 2013

There’s a product out there called SANFusion that can allow Media Composer to read disk images on Xsan as though each were a separate workspace in AvidFS. This allows environments to leverage existing pools of storage sitting on Xsan as though they were sitting on an Isis or a Terablock. Check it out at SANFusion:

SAN Fusion is an easy and cost-effective solution that allows you to use Avid Media Composer with your existing Xsan infrastructure.

By using an existing Xsan volume as a backing-store for SAN Fusion’s virtualized workspaces, editors can experience authentic Unity-style bin sharing and locking from within Media Composer 5.5.3 or later. Unlike other solutions that purport to make Avid work with Xsan, SAN Fusion is a client-side application with no additional server or minimum number of seats to buy.

SAN Fusion clients mount and unmount workspaces on demand through our intuitive GUI to provide Media Composer a real-time translation layer between it and Apple’s Xsan filesystem. The end result is the best of both worlds: Avid’s first class bin and media sharing combined with Apple’s storage-agnostic low (or no) cost cluster filesystem.

The $1,500 price tag shouldn’t scare you off. Just compare the cost of a Promise X30 to the same amount of storage from Avid and you’ll get the idea why. And if you need any help with such things, give us a shout at sales@318.com.

Tags: , , , , ,
Posted in Xsan | Comments Off

Setting up a Qlogic Fibre Channel Switch For Xsan

Wednesday, April 11th, 2012

Qlogic switches can be configured via a built-in Web-based administration tool, or via their Command Line Interface over a serial connection. The Web-based tool is the fastest and easiest method of getting one up and running.

By default, Qlogic switches have an IP address of 10.0.0.1. The default username is “admin”, and the default password is “password”. Set your computer’s IP address to 10.0.0.2, with a Subnet Mask of 255.255.255.0 and no router/gateway. Open a web browser – Firefox is your best option – and go to 10.0.0.1. The Java applet will prompt a security warning – please confirm that the applet can control your computer. It won’t do anything bad.

On first logging in, you will be warned that the default password has not been changed. Please change the password. It’s very easy for somebody to make your fibre fabric not work right. Once you have done so, configure the IP address of the switch.

Please check and see if a firmware update is available for the switch before proceeding any further with setup. It’s definitely going to be easiesr to get a firmware update applied before you’ve got an Xsan using your fabric. Go to http://driverdownloads.qlogic.com/QLogicDriverDownloads_UI/NewDefault.aspx and click on Switches, then Fibre Channel Switches, choose the correct model, and click “Go”.

Devices on a fibre network are identified by their World Wide Name, or WWN. WWNs are guaranteed to be universally unique, which is a good thing, but they’re not designed to be read by humans. That’s why Qlogic lets you assign Nicknames to your devices. You should assign meaningful and easily decipherable Nicknames to all of your devices. Go to Fabric, and then Nicknames. You’ll see a list of all the WWNs (including vendor information), and which port they’re connected to. Double-click in the “Nickname” box, enter what you like, and when you’re done, click “Apply”. Accurate and comprehensible Nicknames make everything else easier, particularly the next step, which is Zoning.

Communication on a Fibre Channel network is controlled by Zones. In order for Fibre Channel devices to see one another (e.g. for clients to see storage), they must be in a zone together. In a small environment, it’s feasible to create a single zone, and place all devices in that zone. However, it isn’t necessary for Xsan clients and controllers to be able to communicate via Fibre Channel – all of their communication happens across the Metadata Network. If you want the best performance, then, it’s best to separate the devices logically into multiple zones to avoid excessive traffic on the Fibre Channel network. Devices can be added directly to a zone, or they can be grouped into Aliases, which can then be added to a zone.

As an example, imagine an environment with 15 Xsan clients, 2 Metadata controllers, and 2 Promise E-Class arrays. The clients need to communicate with the Promise storage, and the controllers do as well, but the clients and controllers don’t need to communicate with one another. Three aliases should be created and two zones should be created: one alias for each class of device, and one zone for each necessary communications channel.

Aliases

  • clients: Contains all Xsan clients
  • controllers: Contains both Metadata controllers
  • storage: Contains both Promises

Zones

  • XsanControllers: Contains the controllers and storage aliases
  • XsanClients: Contains the clients and storage aliases

Zones are contained in Zone Sets. Many Zone Sets can be configured, but only one Zone Set can be active at any time. Once you’ve created zones for your devices, put all those zones into a Zone Set, and make sure that you activate that Zone Set when you’re finished with your configuration changes.

Storage devices and clients on a Fibre Channel network present themselves to the switch differently, and require configuration specific to their role. There are port properties that need to be set to provide the best performance. Xsan controllers and clients are “Initiators”, and storage devices are “Targets”. Device Scan, when enabled, queries every newly connected device to determine whether or not it is a Target or an Initiator. I/O Streamguard attempts to prevent disruption by suppressing some types of communication between initiators. Since we know what every device will be, and what port they’re on, we can set Device Scan and I/O Streamguard appropriately and avoid the excess traffic.

Initiators: Enable I/O Streamguard Disable Device Scan Targets: Disable I/O Streamguard Enable Device Scan

Once you have your Nicknames, Zones, and port settings configured, you switch should be ready for use, and you can move on to configuring your storage, clients, and controllers.

Tags: , ,
Posted in Xsan | Comments Off

Xsan Deployment Checklist

Tuesday, April 10th, 2012

One of the harder aspects of building systems consistently in a repeatable fashion is that you often need a checklist to follow in order to maintain that consistency. Therefore, we’ve started an Xsan Installation Checklist, which we hope will help keep all the i’s dotted and t’s crossed. Feel free to submit any items we should add to the checklist and also feel free to use it to verify the configuration of your own Xsans.

Preparation

[ ] Work out ahead of time how permissions will be dealt with:

  • Active Directory
  • Open Directory
  • Local Clients in same group with different UIDs.

[ ] If Active Directory is already in place, verify that system are bound properly.

[ ] If Open Directory is already in place, verify that system are bound properly.

[ ] If Open Directory is not already in place, configure Open Directory.

[ ] All client Public interfaces should have working forward and reverse DNS resolution.

Fibre Channel (Qlogic)

[ ] Update Qlogic firmware to latest on all switches.

[ ] Set nicknames for all devices in the fabric.

[ ] Export the nicknames.xml file and give to customer or import to workstation running Qlogic San Surfer.

[ ] Set the domain IDs on the Qlogic. Different Domain ID for each switch.

[ ] Set port speed manually on Qlogic and clients. Don’t use auto-negotiation.

[ ] Configure the appropriate Qlogic port properties for Targets (Storage) and Initiators (Clients).

Targets

  • Device Scan On
  • I/O Streamguard Off
  • Initiators
  • Device Scan Off
  • I/O Streamguard On

[ ] Avoid fully populating Qlogic 9200 blades, only use 8-12 ports of each blade to avoid flooding backplane.

[ ] If the switch has redundant power, plug each PS into different circuits.

[ ] Split HBA (client port) and storage ports across switches, i.e. port 0 on switch 1, port 1 on switch 2.

Storage (Promise)

[ ] Update Controller firmware to latest version

[ ] If client has a spare controller, update that as well.  Also label box with updated firmware number

[ ] Work out LUNs for MetaData/Journal and Data (MD should be RAID 1, Data should be RAID 5 or 6)

[ ] Adjust script for formatting Promise RAIDs – refer to this link  http://support.apple.com/kb/HT1200

[ ] Start formatting LUNS according to strategy – this can take up to 24 hours.

Metadata Network

[ ] If customer has Spanning Tree enabled, make sure Portfast is enabled as well. If possible, disable ST.

[ ] Verify that both clients and servers have GigE connection.

General Client/Server

[ ] Label your NICs clearly: Public LAN and Metadata LAN.

[ ] Configure Metadata network with IP and Subnet Mask only. No router or DNS.

[ ] Disable unused network interfaces.

[ ] Make sure Public Interface is top interface in System Preferences/Network

[ ] Disable IPv6 on all interfaces.

[ ] Energy Saver settings: Make sure “put hard disks to sleep when possible” is disabled.

[ ] Make sure Startup Disk is set to the proper local boot volume.

Metadata Controllers

[ ] Install XSAN on Snow Leopard machines and below (XSAN is included with Lion)

[ ] All MDCs should have mirrored boot drives, with AutoRebuild enabled.

[ ] Sync the clocks via NTP. Make sure all clients and MDCs point to same NTP server.

[ ] Add MDCs to XSAN

Volume Configuration

[ ] Label all the LUNs clearly.

[ ] Configure the MetaData LUN as a mirrored Raid 1.

[ ] Use an even number of LUNs per pool.

[ ] Use Apple defaults for block size and stripe breadth and test to see if performance is acceptable.

[ ] Do NOT enable Extended Attributes.

[ ] Verify email notification is turned on.

[ ] Make sure the customer knows not to go below 20% free space.

XSAN Creation/Management

[ ] Verify that the same version of Xsan is running on on all MDCs and clients.

[ ] For 10.6 and below – Add XSAN Serial numbers to XSAN Admin

[ ] Add Clients to XSAN

[ ] Verify performance of XSAN

  • Test speed
  • Test IO
  • Test sustained throughput
  • Test with different file types
  • Test within applications (real world testing)

[ ] Document XSAN for client

[ ] Upload documentation

 

Tags: , ,
Posted in General Technology, Xsan | Comments Off

Configuring a Qlogic Fibre Channel switch for Xsan

Tuesday, February 28th, 2012

Qlogic switches can be configured via a built-in Web-based administration tool, or via their Command Line Interface over a serial connection. The Web-based tool is the fastest and easiest method of getting one up and running.

By default, Qlogic switches have an IP address of 10.0.0.1. The default username is “admin”, and the default password is “password”. Set your computer’s IP address to 10.0.0.2, with a Subnet Mask of 255.255.255.0 and no router/gateway. Open a web browser – Firefox is your best option – and go to 10.0.0.1. The Java applet will prompt a security warning – please confirm that the applet can control your computer. It won’t do anything bad.

On first logging in, you will be warned that the default password has not been changed. Please change the password. It’s very easy for somebody to make your fibre fabric not work right. Once you have done so, configure the IP address of the switch.

Please check and see if a firmware update is available for the switch before proceeding any further with setup. It’s definitely going to be easiesr to get a firmware update applied before you’ve got an Xsan using your fabric. Go to Qlogic’s Support Site and click on Switches, then Fibre Channel Switches, choose the correct model, and click “Go”.

Devices on a fibre network are identified by their World Wide Name, or WWN. WWNs are guaranteed to be universally unique, which is a good thing, but they’re not designed to be read by humans. That’s why Qlogic lets you assign Nicknames to your devices. You should assign meaningful and easily decipherable Nicknames to all of your devices. Go to Fabric, and then Nicknames. You’ll see a list of all the WWNs (including vendor information), and which port they’re connected to. Double-click in the “Nickname” box, enter what you like, and when you’re done, click “Apply”. Accurate and comprehensible Nicknames make everything else easier, particularly the next step, which is Zoning.

Communication on a Fibre Channel network is controlled by Zones. In order for Fibre Channel devices to see one another (e.g. for clients to see storage), they must be in a zone together. In a small environment, it’s feasible to create a single zone, and place all devices in that zone. However, it isn’t necessary for Xsan clients and controllers to be able to communicate via Fibre Channel – all of their communication happens across the Metadata Network. If you want the best performance, then, it’s best to separate the devices logically into multiple zones to avoid excessive traffic on the Fibre Channel network. Devices can be added directly to a zone, or they can be grouped into Aliases, which can then be added to a zone.

As an example, imagine an environment with 15 Xsan clients, 2 Metadata controllers, and 2 Promise E-Class arrays. The clients need to communicate with the Promise storage, and the controllers do as well, but the clients and controllers don’t need to communicate with one another. Three aliases should be created and two zones should be created: one alias for each class of device, and one zone for each necessary communications channel.

  • Aliases
    1. clients: Contains all Xsan clients
    2. controllers: Contains both Metadata controllers.
    3. storage: Contains both Promises
  • Zones
    1. XsanControllers: Contains the controllers and storage aliases
    2. XsanClients: Contains the clients and storage aliases

Zones are contained in Zone Sets. Many Zone Sets can be configured, but only one Zone Set can be active at any time. Once you’ve created zones for your devices, put all those zones into a Zone Set, and make sure that you activate that Zone Set when you’re finished with your configuration changes.

Storage devices and clients on a Fibre Channel network present themselves to the switch differently, and require configuration specific to their role. There are port properties that need to be set to provide the best performance. Xsan controllers and clients are “Initiators”, and storage devices are “Targets”. Device Scan, when enabled, queries every newly connected device to determine whether or not it is a Target or an Initiator. I/O Streamguard attempts to prevent disruption by suppressing some types of communication between initiators. Since we know what every device will be, and what port they’re on, we can set Device Scan and I/O Streamguard appropriately and avoid the excess traffic.

  • Initiators:
    • Enable I/O Streamguard
    • Disable Device Scan
  • Targets:
    • Disable I/O Streamguard
    • Enable Device Scan

Once you have your Nicknames, Zones, and port settings configured, you switch should be ready for use, and you can move on to configuring your storage, clients, and controllers.

Tags: , , , , , , , , , , , ,
Posted in General Technology, Xsan | Comments Off

The Impact of Directory Services on Xsan

Monday, January 23rd, 2012

When you’re dealing with file ownership and permissions, context is very important. Xsan volumes, from the point of view of an Xsan client, are local storage. There’s no daemon acting as gatekeeper or mediator, so when files are created or modified, the clients will use the standard mechanisms for assigning ownership and access rights, as they would with any local drive. In the absence of a shared authentication context, local user accounts will end up owning the files, and their permissions will be according to the default umask.

Mac OS X keeps track of such things by numerical User ID, and all Mac OS X systems start assigning local UIDs beginning with 501. It shouldn’be be too difficult to see how this can end badly. Users will potentially be able to overwrite files owned by other users, or access files they shouldn’t be able to, or not be able to access files that they should.

A directory service, therefore, is a key component in a proper deployment of Xsan. A directory service provides a shared context that will keep User ID collisions from happening. Also, users and groups can be managed centrally, and not on each workstation. This is especially important in large Xsan environments. Also, it will be possible to leverage Access Control Lists, and not POSIX permissions, to manage access to files and folders. POSIX permissions aren’t flexible enough to effectively manage the requirements of most Xsan environments.

It doesn’t matter whether you’re using Open Directory, Active Directory, or a Golden Triangle. You can even integrate Xsan with Novell’s eDirectory. Any of these will provide a much smoother and easy to manage Xsan.

Tags: , , , , , , ,
Posted in Directory Services, Xsan | Comments Off

Active Storage releases mMedia & mVault

Monday, January 9th, 2012

Active Storage has some awesome new products that were announced today:

ActiveSAN Joined By High-Capacity On-line Storage and Near-line Archive Components for Adaptable Production Platform

LAS VEGAS (Storage Visions), January 9, 2012 – Active Storage, the leader in high-performance storage solutions for media and creative professionals, today announced the mMedia platform, a complete end-to-end workflow storage solution for post and broadcast production.

The mMedia platform centers around an enhanced ActiveSAN high- performance metadata controller appliance, and adds two exciting new products, mRAID and mVault (also announced today, see related releases), along with optimized management software; all were combined and demonstrated for the first time, live, on the Storage Visions show floor to reveal a complete, unified mMedia platform installation.

With scalable performance and capacity, mMedia provides content producers the components to assemble complete storage solutions that meet their individual needs plus the integration and management software that lets them choose the best production tools in the industry. Together mMedia is more than a collection of components; it’s a complete media creation storage platform for storing and managing content from ingest to archive.

“mMedia is the platform of the future for broadcast production,” said Alex Grossman, founder and president of Active Storage, Inc. “mMedia provides an integrated workflow storage platform with the performance, scalability and configuration flexibility to meet nearly every broadcast and post-production facility’s ingest, on-line and near-line archive capability.”

The mMedia platform leverages Active Storage’s strong partnerships with industry leaders by offering an open platform that works with other production solutions.

“The mMedia platform is a very exciting development for the Levels
Beyond Reach Engine,” says Art Raymond, CEO of Levels Beyond. “We deploy to some of the largest and most demanding creative workflow sites in the world, including major MSO’s, Studios, Broadcast Networks and Live Sports distributed globally. We’re very enthusiastic about the potential of deploying our solution leveraging the new mMedia Platform to deliver even tighter integration, speed and management for a more advanced customer experience than exists in the market today.”

“Our technology on Active’s mMedia platform can support significantly more capable Media Asset Management solutions for Adobe Premiere, Apple Final Cut and Avid workflows,” says Danny Gold, VP Client Solutions of Levels Beyond. “The combination of Reach Engine and the new mMedia Platform is a complete game- changing way to deliver cost-effective, seamlessly integrated high- performance archive solutions.”

About Active Storage:
Active Storage, Inc. is the innovative storage leader for media and creative professionals, broadcast, post-production, on-line and archive solutions. Fast, reliable and easy to deploy, Active Storage products deliver a best-of-breed user experience, marrying award-winning industrial design, unmatched speed, reliability and customer service. Ease of use and robust performance make Active Storage the first choice for complex professional storage deployments.

318 is an Active Storage reseller and can work with you to plan for and acquire Active Storage products into your storage environment. For more information, contact your 318 Professional Services Manager or sales@318.com if you do not yet have one.

Tags: , , , , , , , , , ,
Posted in IT Management, Mac OS X Server, Xsan | Comments Off

Final Cut Pro X

Tuesday, September 20th, 2011

Version 10.0.1 of Final Cut Pro X is now out. This update returns the ability to use Final Cut Pro X projects and Events on Xsan. This is a must for multi-user environments. Users can now each others media and projects, and edit them from any system on the SAN, as with previous versions of Final Cut.

Additionally, some other new features including custom starting timecode, the new Tribute theme, GPU-accelerated exports, One-step transitions, media stems export and of course, XML support. XML support is very important as it introduces the ability to integrate Final Cut Pro X with asset management systems or APIs from other applications. The ability to interact with other tools helps to plan and implement an automated workflow, reducing the labor for reoccurring tasks common in media environments.


Apple also now provides a free 30 day trial to Final Cut Pro X. If your organization is considering migrating from Final Cut Studio into Final Cut Pro X, or if you have a Final Cut Server based asset management solution that you would like to migrate to something newer and supported, then please feel free to contact your 318 Professional Services Manager, or sales@318.com if you do not yet have one.

Tags: , , ,
Posted in iPhone, IT Management, Mac OS X, Mac OS X Server, Web Development | Comments Off

Video on Using Xsan in OS X Lion

Wednesday, July 20th, 2011

Tags: , , , , ,
Posted in Mac OS X | Comments Off

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!

Tags: , , , ,
Posted in Xsan | Comments Off

Thunderbolt Adapters for Xsan

Tuesday, April 12th, 2011

As usual, there’s plenty to talk about after NAB. One of 2011′s favorites for us so far is the ability to attach a MacBook Pro to an Xsan using one of the newly introduced Thunderbolt -> Fibre Channel adapters.

The above adapter, from Promise, allows for 4Gbps and is “Fully Qualified” for Xsan. This allows the mobile user to be a first class citizen in a fibre channel SAN environment, not having to go through slow NAS heads to access large files, but instead connecting directly to Xsan or other fibre channel solutions!

For more, see http://www.promise.com/storage/raid_series.aspx?region=en-US&m=1054⊂_m=sub_m_8&rsn1=40&rsn3=49

Tags: , , , , ,
Posted in Mac OS X | Comments Off

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)

Tags: , , , ,
Posted in General Technology, Mac OS X, Mac OS X Server, Xsan | Comments Off

Video: Creating a Device on Final Cut Server

Wednesday, July 29th, 2009

Tags: , , , , ,
Posted in Mac OS X, Mac OS X Server, Xsan | Comments Off

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.

Tags: , , , , , , , , , , , , , ,
Posted in Mac OS X, Xsan | Comments Off

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.

Tags: , , , , , , , , ,
Posted in Xsan | Comments Off

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.

Tags: , ,
Posted in Xsan | Comments Off

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/article.php/20090407150134377.

Tags: , , , , , , , , , , , , , , , ,
Posted in General Technology, IT Management, Scripts, Xsan | Comments Off

License.dat and StorNext

Tuesday, March 10th, 2009

We recently did a post on Xsanity about integrating Red Hat Enterprise Linux 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).

Tags: , , , , , , , , , ,
Posted in General Technology, IT Management, Linux, Mass Deployments, Xsan | Comments Off

Article on Xsanity – Linux + Xsan

Tuesday, January 13th, 2009

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.

Tags: , , , , ,
Posted in Editorial, General Technology, Xsan | Comments Off

Preventing Firewall Issues with Xsan

Monday, October 16th, 2006

Introduction

Xsan requires a dedicated ethernet network in the supported architecture by Apple. For systems that are obtaining directory information or need to be wired into the corporate network of many organizations this can cause issues. Namely that Xsan will attempt to use the corporate network for connectivity with clients. We see this in many configurations and it can cause dropped packets, unmountable volumes and other intermittent issues.

One way to fix this for metadata controllers is to choose the network adapter that you would like to use on the metadata network in Server Admin. This can be done by:

Open Xsan Admin
Click on the Xsan listed under SAN Components
Clicking on Setup
Click on Computers
Click on the metadata controller
Choose the network controller you would like to connect using
This doesn’t always work, and selecting a network controller to use is not an available option with Xsan clients and older versions of the Xsan software. A fix to get around this issue for these systems is to block metadata traffic on the production network interface. Here is an example of how to do this using ipfw. This example assumes that you are using Tiger Server for your metadata controller. Once we step through this using Server Admin we will explain the same thing using the configuration files which should help users of old versions of Mac OS X Server or of Mac OS X Workstation.

Through this entire article we are going to assume that the IP address of our metadata controllers production IP is 192.168.50.5. The IP address of our metadata controllers metadata IP is 10.0.0.5. If metadata goes over the 192.168.50.x network then it will likely cause issues, so our goal throughout is going to be blocking metadata traffic on 192.168.50.5. There are also many ways to do this. We are going to focus on blocking outgoing traffic for Xsan on the production IP. Another way to accomplish this might be to block all traffic for metadata for the network range of 192.168.50.x. There are many different ways to do this (including using managed switches) but this way has been working for us.

DISCLAIMER : Be very careful playing with the firewall on a headless server. The last thing you want to do is block yourself from being able to ARD or SSH into a system you are trying to administer. Also try to make sure that you do this stuff while you have the opportunity for a little down-time as you might need a little time to troubleshoot. Also, be sure to backup the service settings before making any changes. To do this, drag the small icon in the lower right-hand corner of the firewall service screen to the desktoop. When you see the + icon let go of the icon and it will save the service settings. If you need to restore this later you can drag the file back over to the Server Admin screen.

Using Firewall in Server Admin

First we’re going to enable Firewall (ipfw):

Open Server Admin from /Applications/Server
Authenticate to the server you are configuring
Click on Firewall under the Computers and Servers List
Click on Settings
Click on Services
Click on the Start Service button in the toolbar of Server Admin
Now we’re going to define the ports to block (see Figure 1):

Click on the + sign to add a service
Enter Xsan under the Name field
Enter “536, 537” (without the quotes) under the Port field
Leave the Protocol set to TCP
Click on OK

Figure 1 – Defining Ports

Now we’re going to define the addresses to block this port for (see Figure 2):
Click on Address Groups
Click on the + sign to add an address group
Name the address group Production IP
Click on the + sign beside Addresses in group
Remove Any if it is present
Type the IP address of your internal IP for the production network
Click OK

Figure 2 – Creating the Address Group

Now we’re going to create the rule for blocking the Xsan ports (see Figure 3):
Click on the Advanced tab
Uncheck all of the rules that deny if you want to first test your base config (you can always go back and add rules once you’ve become more familiar with the Firewall service)
Click on the + button
In the Action drop-down choose the Deny option
In the Protocol drop-down choose the TCP option
In the Service drop-down choose the newly created Xsan service
In the Address drop-down choose the newly created Production IP address
In the Destination drop-down select Any
The Ports should read 536, 537 as this is what we defined earlier
In the Interface drop-down choose Out
Click OK

Figure 3 – Configuring the Rule

Using the IPFW from the Command Line
Personally I find it much easier to do most of this using the command line. For systems not running Mac OS X Server you will need to use the command-line. To do this you would use the ipfw.conf file that is created to define what types of traffic are allowed. The ipfw.conf file is located at /private/etc/ipfilter/ipfw.conf.

The default ipfw.conf file looks like something like this:

# ipfw.conf.default – Installed by Apple, never modified by Server Admin app
#
# ipfw.conf – The servermgrd process (the back end of Server Admin app)
# creates this from ipfw.conf.default if it’s absent, but does not modify it.
#
# Administrators can place custom ipfw rules in ipfw.conf.
#
# Whenever a change is made to the ipfw rules by the Server Admin application and saved:
# 1. All ipfw rules are flushed
# 2. The rules defined by the Server Admin app (stored as plists) are exported to
# /etc/ipfilter/ipfw.conf.apple and loaded into the firewall via ipfw.
# 3. The rules in /etc/ipfilter/ipfw.conf are loaded into the firewall via ipfw.
# Note that the rules loaded into the firewall are not applied unless the firewall is enabled.
#
# The rules resulting from the Server Admin app’s IPFirewall and NAT panels are numbered:
# 10 – from the NAT Service – this is the NAT divert rule, present only
# when he NAT service is started via the Server Admin app.
# 1000 – from the “Advanced” panel – the modifiable rules, ordered by their
# relative position in the drag-sortable rule list
# 12300 – from the “General” panel – “allow”" rules that punch specific holes
# in the firewall for specific services
# 63200 – from the “Advanced” panel – the non-modifiable rules at the bottom
# of the panel’s rule list
#
# Refer to the man page for ipfw(8) for more information.
#
# The following rules are already added by default:
# #add 01000 allow all from any to any via en0
#add 01010 deny all from any to 127.0.0.0/8
#add 01020 deny ip from 224.0.0.0/4 to any in
#add 01030 deny tcp from any to 224.0.0.0/4 in
#add 12300 (“allow” rules from the “General” panel)
#…
#add 65534 deny ip from any to any
First, we’re going to allow all traffic for both controllers. For this example doing this will make sure that we don’t have any problems with connecting to Xsan Admin (port 311) or ARD. To do this, take out the # for the line that reads:

#add 01000 allow all from any to any via en0
By removing a # from the beginning of a line you are uncommenting the line or enabling the rule. I like to go through and put a commented line for some rules that are complicated so that other techs at my company can figure out what they do if they need to troubleshoot something that I’ve done. To do this you just begin the line with a #.

Also the en0 here might be en1 or lo1 for some metadata controllers. You can use the Network Utility to determine which adapter is using which ethernet port name.

Next you will create another rule that adds a line that denies outgoing traffic for ports 536 and 537 (Sun Grid Engine Qmaster) over the ethernet adapter being used for the metadata network. This adapter can easily be identified using the Network System Preference. This rule looks something like this assuming that 192.168.50.5 is the IP address the server is using for its metadata network interface:

add 65534 deny tcp from 192.168.50.1 to any dst-port 536, 537 out
Reading from left to right we are telling ipfw to add a rule with a unique ID that denies TCP traffic from the IP address of the metadata network interface that is running on ports 536 or 537 for outgoing traffic. The unique ID number also acts as a priority that rules should be run in. A full sample file could be as short as:

#The following line enables network traffic on the Production Network
add 01000 allow all from any to any via en0
#The following line enables network traffic on the Metadata Network
add 01000 allow all from any to any via en1
#The following line disables Xsan Traffic for the Production Network
add 65534 deny tcp from 192.168.50.5 to any dst-port 536, 537 out
Finally, once you are sure that your configuration is good, use Server Admin to enable the Firewall service as we described at the beginning of this article. Remember not to block port 311 or you will not be able to use Xsan Admin to administer the client.

Just in case you use Linux clients

For Linux clients of Xsan I find that using iptables is a great way to accomplish this same task. The two commands to create the deny rule using iptables would be something like this assuming that eth0 is your production network:

Iptables –A PREROUTING –o eth0 -s any –p tcp –dport 536 -j DROP
Iptables –A PREROUTING –o eth0 -s any –p tcp –dport 537 -j DROP
If iptables is not already started you can type:

Service iptables start
The command to view active rules for iptables is:

Chkconfig –list iptables
Saving Windows for Last

Windows XP and Server 2003 have equally as robust firewall features. To limit traffic over ports you would use Windows Firewall for Windows XP and Routing and Remote Access for Windows Server 2003. While Windows Server 2003 is a little beyond the scope of this document, I can help you get started. For Windows XP:

Click on Start
Click on Connect To
Click on Show All Network Connections
Click on Change Windows Firewall Settings (see Figure 4)

Figure 4 – Network Connections

Once you have your Windows Firewall control panel open, click On and make sure that the Don’t allow exceptions check-box is unchecked (see Figure 5)

Click on Advanced
Use the check-boxes under Network Connection Settings to disable the Firewall for the Metadata Controller (see Figure 6)

Figure 5 – Enabling Windows Firewall

Figure 6 – Windows Firewall Advanced Settings

Tags: , , , , , , , , , , , , ,
Posted in General Technology, Linux, Mac OS X, Mac OS X Server, Network Architecture, Scripts, Security, Windows, Xsan | Comments Off

Howto Install Xsan

Monday, January 2nd, 2006

Planning Storage
The most typical storage found in Xsan setups is the Apple XRAID. Any XRAID will work within an Xsan deployment. XRAID systems being used in an Xsan should have the maximum amount of RAM available, which is 512MB.

The Apple XRAID comes with 14 drive modules. Drive modules in an XRAID are split into two channels, each with 7 modules. Drive modules are just UltraATA or SATA enclosures for the Hard Drives used in an XRAID. XRAIDs are available in sizes up to 10.5TB. Due to the large amount of media, it can take 30 or more hours to format the RAID completely. While there are options that allow writing to the XRAID while it is formatting this is often going to cause a performance decrease on the XRAID.

Each controller of the XRAID has a serial port, a Gigabit Ethernet port and a Gigabit Fibre channel port. For best performance, both controllers should be used when using an Xserve RAID with Xsan.

This brings up the two main factors when planning the storage needs for an Xsan: speed and space. Space is typically the biggest choice made when purchasing storage devices. Since all of the Xserve RAIDs get their space aggregated to create two gigabits per Xserve RAID, the speed requirements can often mean a need for purchasing more Xserve RAIDs even when the extra space is not a requirement.
Configuring the XRAID
The RAID Admin Utility is used when configuring an Apple XRAID. Multiple LUNs, or RAIDs can be configured in each RAID. The RAID Admin Utility should be used when specifying which drives are used in each RAID and what RAID levels they shall use as well as RAID settings and notifications.

When you open RAID Admin you will first want to add a RAID to administer. To do this:
1. Open RAID Admin from /Applications/Server (see Figure 2.x)

Figure 2.x Raid Admin

2. Click on the button for Add System.
3. From the list of available Xserve RAIDs select the RAID you would like to administer (see Figure 2.x).
4. Enter the admin password. By default the password to monitor an Xserve RAID is public.
5. Click Add. If the password is correct, you will now see the Xserve RAID listed in RAID Admin.

Figure 2.x Add RAID Screen

Once you have added all of the Xserve RAIDs to RAID Admin you will likely want to customize the settings of each. In order to do so:
1. Open RAID Admin from /Applications/Server.
2. Click Settings in the toolbar of RAID Admin.
3. Enter the management password for the Xserve RAID you are customizing the settings for.
4. Under the System tab (see Figure 2.x):
a. Enter the Name for the Xserve RAID in the System Name field.
b. Enter the Location in the Location field. This is only used so that when people are administering or monitoring the RAID they will know where it is.
c. Enter the contact information for the administrator of the RAID in the Contact field. This is only used when monitoring personell need to contact the administrator.
d. Select a Time Synchronization Method and if appropriate enter an NTP server to be used for clock synchronization.
e. Use the Change buttons in the Passwords section to change the monitoring and management password for the RAID.
f. Uncheck the Enable audible system alerts if you do not want the Xserve RAID to emit a loud noise if a component on the device fails. This is not advised as if something fails you likely really want to know.
g. Uncheck the box for Restart automatically after a power failure if you want the Xserve RAID to reboot if it looses power.
h. Uncheck the box for Enable SNMP if you will not be using SNMP traps to monitor the device. If you will do not use SNMP then for security purposes you should disable this option.

Figure 2.x System Settings

5. Each controller on the Xserve RAID has its own network controller. By defualt these receive DHCP addresses. We suggest giving each network controller a static IP address or using Static Mappings in your DHCP pool to give controllers IP address. If IP addresses change, then controllers are no longer available in RAID Admin and must be readded which is not typically a good idea. Network settings can be configured under the Network Tab (see Figure 2.x).

Figure 2.x Network Settings

6. The Fibre Channel settings are available under the Fibre Channel tab. This is where the WWN is available to be viewed, Hard Loops are created, speeds are set to static and the topology is defined. These can typically be left as they are unless you will be using arbitrated loops in your Fibre Channel topology (see Figure 2.x).

Figure 2.x Fibre Channel Settings

7. The Performance tab can be used to customize certain features that may enhance performance of the Xserve RAID (see Figure 2.x).
a. Drive cache can be enabled and disabled for each array. Drive cache …
b. Write Cache can be enabled or disabled per controller. Write cache …
c. Read Prefetch can be set to 1 stripe, 8 stripes or 128 stripes for each controller. The number of stripes for the Read Prefetch

Figure 2.x Performance Settings

You will now want to setup the LUNs for the RAID. If you remember from Chapter 1, a LUN is a logical portion of an Xserve RAID. These are referred to as Arrays in RAID Admin.

Each array will be assigned a RAID level depending on your requirements. The RAID levels supported on an Xserve RAID are:
RAID 0 offers no redundancy. While RAID 0 gives the fastest speeds of media and the most inexpensive solution where data availability is concerned there is absolutely no fault tolerance.
RAID 1 comes with the highest cost where data is concerned.
RAID 3 has one drive dedicated to parity.
RAID 5 stripes parity data across all of the drives in the RAID giving RAID 5 volumes full redundancy at the lowest cost of drive space.

To create a LUN in RAID Admin:
1. Open RAID Admin.
2. Select the Xserve RAID you will be creating a LUN on.
3. Click on the Create Array button in the toolbar of RAID Admin.
4. Enter the management password for the Xserve RAID and click OK.
5. Select the RAID level of the LUN (see Figure 2.x).

Figure 2.x Setting up a LUN

6. Select the Drives to be included in the LUN by clicking in the box on each drive.
7. If you wish to begin writing data onto the Xsan during the initialization period of the drives, leave the background initialization option enabled for now.
8. The prefered configuration for drives used in an XSAN environment is to enable the Use drive cache option. You should do so now.

9. Click on Create Array.
10. You will no be placed back at the RAID Admin screen while the Xserve RAID restarts the controller. Wait for this before attempting to reformat any other LUNs.

Installing the Metadata Network
The Metadata network is a private Ethernet network used exclusively for Metadata. This is one of the least documented components of an Xsan.
There should be a gigabit network for Xsan metadata and the network should be configured with static addresses to keep DHCP traffic at a minimum. There should also be no DNS records point to IP addresses within the metadata network unless required. DNS can be used, but it is often easier to not use DNS as there are stringent requirements for how DNS is configured on the Metadata network.
You should use gigabit Ethernet PCI cards, a gigabit Ethernet switch, and good quality (Cat-5e or Cat-6) cabling. In the Network preference pane’s “Network Port Configuration,” the private network interface should be listed below the public network interface. This sets the public interface as the default. When configuring the private interface’s TCP/IP parameters, only fill in IP Address and Subnet Mask. Leave the other fields such as Gateway, Default Domain and Name Servers blank.
Choose an IP address range that is unrouted and unassigned to a DNS domain (see below).

There are three IP subnets primarily used for private network ranges. They are 10.0.0.0 to 10.255.255.255, 192.168.0.0 to 192.168.168.255.255 and 172.16.0.0 to 172.31.255.255. This offers a lot of flexibility to make sure that the range is not duplicated on other parts of your network. The range of private IP address that you choose to use should not be used by any other network you can access.

The address range 192.168.1.1 – 192.168.1.254 is often used by consumer router manufacturers. If this is the range you use on your network to connect to the Internet, you must not use it for your metadata network. Choose another range.
DNS is a trickier issue to diagnose. Last week, for example, I was setting up a SAN for a small workgroup in a large corporation. Following the instructions in the Xsan guide, we set the private network to use the 192.168.1.x with a 255.255.255.0 subnet mask. We found that Xsan Admin was working extremely slowly. Every tab change or refresh took minutes to complete.
With the proper Terminal command, we were able to determine that the corporate IT department was already using the range 192.168 for another division in its network. Xsan Admin was trying the (incorrect) DNS name for the server for each transaction, timing out, and falling back to the IP address. By changing the range of the private network to 10.17.17.1 with a 255.255.255.0 mask, we were able to eliminate the timeouts without modifying DNS. We chose the “17.17″ randomly, but confirmed that it was not in use elsewhere on the corporate network.
Choosing a Subnet Mask
The subnet mask tells the computer how big the IP range is. A subnet mask of 255.255.255.0 is equivalent to a range of x.x.x.1 – x.x.x.254. This mask is appropriate for almost all private metadata networks.
Useful Terminal commands
dig +short -x 192.168.1.1
This command queries your DNS servers to see if an address has an associated name. If there is no name, then no result is returned. For example, dig +short -x 17.254.3.183 returns apple.com.. (Although Xsan can work with IPs that have associated DNS addresses, the DNS records must be configured perfectly. It is far easier just to keep DNS out of the picture.)
lsof -ni4 | grep fsm
When run from the active metadata controller, shows the IP addresses of all connected Xsan clients. This may be useful to determine that all clients are connecting via the correct network. If you see any addresses in your public range, you have routing problems.
Setting up the Fibre Channel Switches
When configuring the SAN switches, a computer will need to have an IP within the same Subnet as the SAN switch initially. The IP of the switch can then be changed to be one within the LAN network of the SAN or the general network so that on a move forward basis the SAN switch will be configable from a client or Metadata controller.

Headless Installations
Much to the chagrin of many administrators and the humor of many older UNIX administrators, the Xserves no longer being shipped with a graphics card. This is now an upgrade that many administrators do not know they will need to puchase. Apple suggests using Xserves as Metadata Controllers, but doesn’t think to tell administrators that they will have no video for the system. Luckily, Apple has provided us with numerous ways around this issue.

One of the best features of Mac OS X Server is that the when you boot to a CD or DVD SSH and a client for the Mac OS X Server Setup Assistant are automatically running on the system. You can use Setup Assistant to complete the installation that was started at the factory.

How do you find the system on the network. Bonjour browser can be useful for this. The Setup Assistant will search the network for systems that are waiting for this portion of the installation to be complete.

The password to log into an Xserve when it is booted to the CD is the first eight digits of the servers serial number. If you are installing on an older Xserve, the serial number may be “12345678.”

/System/Library/ServerSetup/sa_srchr IP_Address

You can also boot to a Fibre Channel port.

Once the server has been installed, you should be able to tap in using Apple Remote Desktop
Setting up Xsan
Once you have setup all of your LUNs or Arrays, then you will be ready to go about installing the Xsan software. We suggest setting up the LUNs first, because it allows them some time to format before you begin writing data to them.

You will install the Xsan software on all of the systems that will be running as Metadata Controllers and on all of the client computers. To install the Xsan software:
1. Run the Install Xsan.mpkg file from the Xsan Install Disc.
2. Read the Welcome to the Xsan Installer screen and click Continue.
3. Read the Important Information and click Continue.
4. Read the Software License Agreement and click Continue.
5. Agree to the Software License Agreement by clicking on the Agree button.
6. Select the volume for the Xsan software to be installed on.
7. Once your Destination has been selected, click Continue (see Figure 2.x).

Figure 2.x Select a Destination

8. If you would like to only install the Xsan software and not the Xsan admin program to manage the xSan then click on Customize and uncheck the box for that package (see Figure 2.x).

Figure 2.x Custom Installation

9. Whether you are installing both the Xsan software and the Xsan Admin software click Install when you are ready to install.
10. Run Software Update and update each system running the Xsan software to the latest version before going on to configure the Xsan.

Creating a Volume

Figure 2.x

Figure 2.x
Creating Storage Pools

Figure 2.x
Starting the Volume
Once the volume has been created, you will likely want to start it. This is going to be a common step so remember how to complete this task. Also, remember that if you stop the volume, you will first want to unmount the volume from all client computers.
1. Open Xsan Admin from /Applications/Server.
2. Under the SAN Components list click on the Volume you would like to start.
3. Click on the Start Volume button in the toolbar.

Mounting the Volume
To mount a volume:
4. Open Xsan Admin from /Applications/Server.
5. Under the SAN Components list click on the Volume you would like to mount.
6. Click on the Clients tab for the volume.
7. Click on the client you would like to mount the volume for (see Figure 2.x).
8. Click on the Mount Read Only if the client system does not need to write to the volume. If the client system does need to write to the volume, click on the Mount Read Write button.

Figure 2.x Mounting the Volume on a client

9. Once you have mounted the volume, click on it using the Finder.
10. Click on the Finder menu of the system and select Get Info.
11. Make sure that the volume size and attribute look as they should.

Figure 2.x Get Info on Mounted Volume

Tags: , , , , , , , , , , , , , , , , , ,
Posted in Mac OS X Server, Mass Deployments, Xsan | Comments Off