Installing the SAN


Now that we've gone over the fine points of planning the SAN, and you have made purchase decisions relevant to the bandwidth and capacity needs of the SAN, it's time to hook up the spigots and get the thing running.

Note

Before you go barreling into these steps, make sure you realize that your Xserve RAIDs need to be "cooked" (powered up for the first 36 hours of its life for a format and verification process) in order to work optimally when added to the SAN. So, if your Xserve RAID is brand new, take it out of its box, hook up both power cords to the Xserve RAID and to the wall, power it up from the button in the rear, and leave it alonefor a day or so. When all the blue lights turn off, hold down the power button for a moment until the unit shuts down. Then you can begin.


Installing the Fibre Channel and Ethernet Cards

First, with all equipment powered down, we will install the necessary internal hardware for our SAN.

1.

Install Fibre Channel host bus adapter (HBA) cards into each Mac (G4, G5, or Xserve) that is being connected to the SAN directly.

Installing the Fibre HBA into a G5 PowerMac, in this case, into slot 4 (133 MHz PCI-X)

Installing the Fibre HBA into an Xserve G5

Note

Fibre Channel cards are most often installed into PCI-X slot 2 or 3 of G5s (the slots that are closer to the bottom of the computer), reserving the upper PCI-X 133-MHz slot 4 (and its isolated PCI-X bus) for fast cards such as capture cards. However, if a particular machine will not need capture hardware, install the Fibre Channel HBA into slot 4. Alternately, if your G5 has a fast capture card in slot 4, and has a nVidia GeForce 6800 or ATI Radeon 9800 graphics card, your choice of where to put the Fibre card will be limited to PCI slot 3, due to the extra thickness of these graphics cards. There are no limitations to where you install the Fibre Channel controller card on a PowerMac G4 or either G4 or G5 Xserve.

Dual-processor G5 PCI slot locations

The next step is necessary if you intend to have the Macs in your SAN access your facility's network or the Internet.

2.

Install Ethernet network interface cards (NICs) into each Mac (G4 or G5) that needs to connect to the facility's network.

Note

Wow, it's getting crowded back there. If you have a capture card installed in PCI slot 4 and a Fibre card in slot 2 or 3, your choice is simple: install the NIC in the last remaining slot. However, if you have one of the double-wide graphics cards mentioned in the last note, a Fibre card in PCI slot 3, and a capture card in PCI slot 4, you have run out of slots! Unless you intend to use Airport as your outer network (which has its own security issues), Apple is currently recommending not using a capture card in a G5 that sports a double-wide graphics card that will also be on an Xsan. Alternately, you can now spring for the newer single-slot ATI X800 card that is able to drive 30-inch monitors. In this case, the bandwidth-hungry Fibre card should be reinstalled in PCI slot 4 and the Ethernet NIC in PCI slot 3. Xserve G5s come with two built-in Ethernet ports, so you won't need a NIC for these machines.

Connecting the Fibre Channel Network

Get your thumb and forefinger readyit's time to make the connections necessary for the Fibre Channel network to function.

1.

If you are using optical cables for your Fibre infrastructure, make sure to attach the optical transceivers, mentioned earlier, to each end of your optical Fibre cables.

Note

When using optical Fibre cable, take great care not to bend, kink, tread on, or otherwise mistreat the cables, because they are very susceptible to failure if any part of the Fibre substrate is damaged. Optical cables should be laid into conduit, rather than pulled through. Faulty optical cables are also very hard to troubleshoot, apart from simply changing them out to see if the problem goes away. Needless to say, it's best to have more cable than necessary in order to do this.

2.

Connect either copper or optical Fibre cables to both ports of each Fibre Channel controller card on each Mac, including your server, that is being connected to the SAN.

Connecting a copper Fibre cable to a G5 PowerMac Fibre HBA

Connecting a copper Fibre cable to an Xserve G5 Fibre HBA

Note

Although not mandatory, hooking up two cables to each Fibre Channel HBA allows the multipathing function of the Xsan software to function. If one port fails, the other port will take over for communication. Having two cables will also increase the data bandwidth capability of each computer, which is critical when implementing Xsan for post-production use. However, MDCs read and write such small amounts of data to the SAN that one cable is sufficient for hooking the MDC to the switch.

3.

Connect either copper or optical Fibre cables to both controller ports of each Xserve RAID that is being connected to the SAN.

Note

In this exercise, you'll configure two Xserve RAIDs, but your implementation may use more or fewer. Just make sure you have enough ports on your Fibre switch for everyone.

4.

Connect all the other ends of the cables to the Fibre Channel switch.

Note

If you truly want to geek out on the connections to the Fibre switch, the customary protocol is to hook up connections for the Xserve RAIDs to the last available and active ports on the switch. The MDC (and standby MDC) nodes get hooked up to the first available ports. The client nodes get hooked up to the ports right in the middle.

We won't cover zoning of Fibre switches, or whether switches auto-sense if connectors are optical or copper. Most recommended switches do not have preset zones, and they automatically sense what kind of cable is plugged into what port, which makes them easy to use. However, many switches require specialized firmware for use with Xsan. To that end, be sure to consult the manuals and support sites of your switch for more information.

Connecting the Private Metadata Network

We will now hook up the Ethernet network that will handle the metadata. Some installations that are not concerned about connecting the machines on the SAN to the facility's network will create their private network out of the built-in Ethernet ports on the Macs. However, if you need to have your SAN machines also on the facility network, and have installed Ethernet NICs in each G4 or G5 that will be on the SAN, you will then create your metadata network with either the NIC or the built-in port, with the remaining port used to access the outer network. Just make sure to be consistent across all nodes, as to which interface you will use. For Xserve G5s, we will use the en0 (lower) port to configure the metadata network. Later on, you can assign the settings for the facility network to the built-in port on G4s and G5s, and the en1 (upper) port on Xserves.

1.

Connect CAT 5e (or better yet, CAT 6) Ethernet cables to the appropriate Ethernet port (built-in Ethernet port on G4s and G5s and first-generation G4 Xserves, and the lower port labeled 1 on Xserve G5s) for each Mac on the SAN.

Connecting a CAT 5e cable to the built-in Ethernet port on a G5 PowerMac

Connecting a CAT 5e cable to port 1 (lower) of a Xserve G5

2.

Connect the other end of each cable to your Gigabit (1000BaseT) or 100BaseT Ethernet switch.

Connecting a CAT 5e cable to the GigE switch

Implementing Directory Services, Part 1

It's now time to create the directory server that will be responsible for creating and managing the users and groups on the SAN.

If you already have a directory set up at your facility, whether it is being served up by Mac OS X Server's Open Directory or Microsoft Windows' Active Directory, you may want to bind your controller and client nodes on your SAN to that pre-existing directory, using the outer Ethernet network. If so, you can skip this section.

However, on installs of six or fewer client nodes, it is permissible for an Xserve running OS X Server to also act as the controller node for the SAN. For larger installs, you will want OS X Server running on a separate Xserve, and a separate G5 or Xserve acting as the controller node. Think of the difference between a small restaurant and a huge banquet facility: the former can get away with one chef, whereas the latter definitely needs a main chef and a sous-chef.

We will assume you have purchased an Xserve that will serve up directory services for the SAN while simultaneously acting as its primary MDC, and that you have an install of six or fewer client nodes. Therefore, we will proceed as follows:

1.

Configure the Xserve.

2.

Update the Xserve's OS X Server to the latest version (if needed).

3.

Create an Open Directory Master on the Xserve.

4.

Set up the users and groups of our SAN.

5.

Install Xsan software.

6.

Configure the Xserve as the primary metadata controller (MDC).

This section covers the first three of these steps. We will cover the remaining three steps later.

We hope you found the previous sections blissful and mindless, because that state of mind will now end. As we said before, this part will be easier with an Xsan Medallion and/or ACSA-certified integrator at your side or in your head, whichever is more convenient.

What We Won't Cover

Regardless of the size of your SAN, the configuration of OS X Server is the same. Because of space constraints, here is what we will not cover in this section:

  • Installing a fresh copy of OS X Server on an Xserve

  • Updating an Xserve's OS X Server software from 10.X.X to 10.3.X or 10.4.X

  • Installing, updating, or configuring OS X Server on a G5, rather than an Xserve

  • Implementing OS X Server on the outer network of the SAN

For more information about these scenarios, you can go to the following online resources:

  • www.apple.com/server/documentationApple's excellent online documentation page

  • consultants.apple.comApple's online search tool to find ACTC and ACSA consultants in your area

  • www.afp548.comAn online forum specifically oriented toward OS X Server implementation

  • www.macosxhints.comAn online forum focused on OS X in general, but with excellent threads on OS X Server as well

There are also excellent Web resources for Xsan implementation:

  • www.xsanity.comA Web site specifically dedicated to the foibles of Xsan implementation

  • www.creativecow.netTheir Apple Xsan forum is a frequent hub of new ideas and solution

    Note

    The installation process described in the following sections is solely for implementing directory services for use with Xsan. OS X Server has many services to offer your facility, such as Web and mail services, firewall protection, and the like. In the following steps, we will only be implementing directory services for an isolated SAN system.


Configuring a Client Node to Act as a Temporary Remote Admin

1.

Power up the Ethernet switch for the metadata network.

2.

Power up the Xserve.

Note

Most Xserves are headless, meaning they have no graphics cards installed to drive a monitor. As a result, most are configured and administered remotely. If you already have a PowerMac or PowerBook that has the OS X Server Administration Tools installed on it, you can connect this machine to the Ethernet switch to perform this part of the process, and skip steps 3 and 4.

3.

Power up another Mac on the network that will serve as a client node.

We will use this Mac to configure the Xserve remotely.

4.

Log in to this Mac on an admin account.

5.

Install OS X Administration Tools on this client node.

More Info

The OS X Administration Tools are a free download from www.apple.com/support/downloads. Make sure to download any update to the tools to make sure they are the latest.

6.

Install Apple Remote Desktop on this client node.

More Info

Apple Remote Desktop (ARD) is an indispensable part of remote control and configuration of any network. It also costs money. For more information, see www.apple.com/remotedesktop.

Configuring the Xserve Remotely

Now that we've installed the OS X Server Administration Tools software on our client, we can connect to and configure our Xserve.

1.

Continuing on the client node, launch the Server Assistant application, located in /Applications/Server/.

2.

Select "Set up a remote server" and click Continue.

You will be presented with a list of servers, and hopefully, through the magic of Bonjour, you will see the Xserve, with the default name of localhost waiting to be configured.

3.

Double-click in the Password column for the Xserve and type in the first eight characters of the Xserve's serial number, then press Return.

Tip

You can find the serial number of an Xserve on a label in the back, along the bottom panel, under the PCI slots. You will probably have to remove your connected Fibre cable to see the number. You can also find the serial number on a side of the box that the server came in. If you are using a G5 desktop as your server, remove the side panel, and you will see the serial number at the bottom part of the inside frame.

4.

Click Continue to authenticate the server.

You will then be passed to the main configuration screens. You will be asked for the language to configure the server in, the keyboard configuration, and finally the serial number for OS X Server.

You will then be prompted to create an admin account on the server, which you will then use to log into it remotely from now on. Choose this admin username and password wisely.

The next screen will ask for the server's name to replace the default name localhost. In our case, we'll use a short, sweet name for our server: mdc.

5.

Enter mdc.local in the first two fields of this screen, but only mdc in the last, then click Continue.

Our server's name from now on will be mdc.local. You will now be at the Network Interfaces screen.

6.

Turn off all interfaces except for the Built-in Ethernet port's TCP/IP, then click Continue.

You are now presented with the TCP/IP Connection screen.

In order for our metadata network to have as little chatter as possible, we will configure static IP addresses for each machine. We'll start with the Xserve and work our way out from there. The following table has suggestions for private address ranges for the isolated network. In our steps, we'll use the ten-dot range.

Private Network Address Ranges

Private Address Range

Associated Subnet Mask

Comments

10.0.0.0 10.255.255.255

255.0.0.0

10/8

172.16.0.0 172.31.255.255

255.240.0.0

172.16/12

192.168.0.0 192.168.255.255

255.255.0.0

192.168/16


7.

In the TCP/IP Connection window, choose Manually from the Configure pull-down menu.

8.

Type 10.1.0.1 in the IP Address box, 255.0.0.0 in the Subnet Mask box, and finally 10.1.0.1 in the Router box, then click Continue.

Note

Notice that we have placed the same address in both the IP Address and Router boxes. The metadata network actually has no router, since its information is not being routed to or from a larger network. The reason for the fake router address is for the routing tables of the server, just in case a client machine asks for data not on the metadata network. The server, when queried, will simply drop this request.

If you invested in a managed Ethernet switch, the switch itself will have an IP address. In this case, you can assign the router setting for step 8 to the address of your managed switch.

9.

In the Directory Usage screen, leave the "Set directory usage to" pull-down menu as Standalone Server, then click Continue.

Note

Most seasoned OS X Server administrators would tell you that you should really create an Open Directory Master once the server is configured and properly running. They would be right, so we'll be promoting this server to an Open Directory Master after we have it up and running.

The Assistant then asks if we'd like to employ other services.

10.

In the Services screen, click the last check boxApple Remote Desktop Clientthen click Continue.

We will need ARD on in order to further configure or update the OS of the server using Apple Remote Desktop.

11.

Select the appropriate time zone from the Time Zone screen, then click Continue.

12.

In the next screen, Network Time, deselect the "Use a network time server" button, and click Continue.

Since we are not connected to the Internet on this metadata network, trying to ping an external time server will just add chatter.

13.

Finally, review all of your settings and click Apply.

After a few minutes of configuration time, you will be presented with a box stating that the server needs to be restarted.

14.

Click Continue Now to restart the Xserve, or just wait until it restarts itself.

15.

Quit the Server Assistant.

Hopefully, you have a frothy beverage to enjoy at this point, because you are 87.3 percent done configuring your Xserve. Mazel Tov!

Setting the Client Node's Static IP Address

As you'll recall, we configured our Xserve with a static IP address. In order to talk to it again, we'll have to configure our client node with complementary IP information.

1.

Still on the client node, choose System Preferences from the blue Apple menu, and go to the Network pane.

2.

From the Location pull-down menu, choose New Location.

3.

Name the new location Metadata Network and click OK.

4.

From the Show pull-down menu, choose Network Port Configurations.

5.

Turn off all ports except for Built-in Ethernet.

6.

From the Show pull-down menu, choose Built-in Ethernet.

You will be looking at the TCP/IP Settings for this machine.

7.

From the Configure IPv4 pull-down menu, choose Manually.

8.

Type 10.1.0.100 in the IP Address box, 255.0.0.0 in the Subnet Mask box, and 10.1.0.1 in the Router box.

Note

Again, if you are using a managed Ethernet switch on your metadata network, place the IP address of the switch in the Router box for step 8.

This will be the address for this client node.

9.

Click Apply Now and close the System Preferences window.

Updating the Xserve to the Latest Version of OS X Server

If you have the luxury of having the latest OS X Server install discs, you can skip this step. If not, you'll need to update your server software to the latest version. This is true even if your Xserve is not acting as an MDC. Since our metadata network does not currently connect to the Internet, you will do a little old-fashioned sneaker-net transfer of the update packages to the network.

1.

From your facility's network, download the latest Mac OS X Server Combined Update from www.apple.com/support/downloads.

2.

If you are running an older Xserve G5, download the Xserve G5 Firmware Update 5.1.7f1, also available from the URL in step 1.

3.

Transfer these packages to a FireWire drive.

4.

Plug the FireWire drive into front FireWire port of the Xserve.

5.

On the client node, launch Apple Remote Desktop.

6.

In the Remote Desktop Setup screen, enter an admin username and password identical to the admin account for the server, then click Done.

Both your MDC server and your local client pop up in ARD's scanner list, which shows up by default.

In some cases, the ARD client we turned on when we configured the Xserve will be an older version. Follow these steps to update the client software on the Xserve to the latest version.

1.

Select the MDC server in the list.

2.

Choose Manage > Upgrade Client Software.

You will be prompted to add this computer to the Master List.

3.

Enter mdc.local in the DNS name box, and the username and password of the admin account for the server in the appropriate boxes, then click Add.

4.

In the Upgrade Client Software screen, click Upgrade.

It will take a little while to install and start up the new ARD client software on the server. A status window will pop up to inform you of the progress of the upgrade.

5.

When the upgrade is complete, close the Status window.

Now that we have the right version of the ARD client software running on the server, it's time to install the packages from the FireWire drive.

1.

Back in the main window of ARD, click your MDC server, then click the Control icon in the toolbar.

A login screen appears.

2.

Enter the admin account username and password, and click the Log In icon.

3.

Now that you are in, install each package from the FireWire drive.

Note

If you perform the Xserve G5 firmware update, you will be required to shut down the Xserve and hold down the power button when starting it up again to reprogram the firmware. Read the About document that comes with the firmware update for more information.

4.

When all your packages have been installed, quit Apple Remote Desktop.

Creating the Open Directory

In the next steps, we will set up the server to serve a directory using Open Directory. This will allow us to create a listing of users and groups that will be universally accessible throughout the network. We'll use the Server Admin application to do this.

1.

From our trusty client node, launch Server Admin, which you'll find in /Applications/Server/.

When the program launches, you will be prompted to add a server to administer.

2.

Enter mdc.local in the Address box, and the username and password of the admin user in the next two boxes, and click Connect.

Information about the server loads into the window.

3.

From the list of services at left, click the Open Directory service.

4.

Click the Settings tab.

5.

Change the Role from Standalone Server to Open Directory Master.

You'll then be prompted to enter information about the directory.

6.

The directory admin username and password should be different from your "regular" server admin username and password for security reasons, but it's your choice. The dialog box suggests a username of "diradmin." Fill in the rest as shown in the following image.

7.

Click Save.

Setting Up Users and Groups Using Workgroup Manager

Now that the directory is created, we'll run Workgroup Manager and populate the directory with some users and groups. The users and groups we'll create will be fake, just for fun, but feel free to substitute your actual users and groups instead. We do this now, because once we set up and configure the client nodes, and bind them to the directory, the users of the SAN will already have been set up in the directory: all your users will have to do is log in to the machine on which they'll be working.

1.

With Server Admin still open, click the handy Workgroup Manager button in the upper-left corner of the interface.

Workgroup Manager automatically launches.

More Info

Since Server Admin and Workgroup Manager are used so often with one another, they have hot link buttons to the other program in the upper-left corner of their interfaces.

2.

At the Workgroup Manager Connect screen, type mdc.local in the Address box, and the directory administrator username and password in the next two boxes, and click Connect.

Once we're connected, the main Workgroup Manager appears. From here, we'll first add some groups.

1.

In the upper left of the window, click the Groups tab.

2.

Click the New Group button in the toolbar.

A new group, Untitled 1, with the GID of 1025, appears in the list at the left.

3.

In the Name box, type Creatives.

The short name creatives automatically gets created as you type.

4.

Click Save.

5.

Use steps 2 through 4 to create two more groups: Editors, with a GID of 1026, and Graphics, with a GID of 1027.

When you're done, your three groups should look like this:

Next we'll create some users for our directory.

1.

Click back on the User tab in the upper left.

2.

Click the New User button in the toolbar.

A new user, with the name of Untitled 1 and the UID of 1025, appears in the list in the left.

We will now modify the name of this user.

3.

At the right, in the Name box, type Albert, then press Tab twice.

Albert's short name is, rightfully, albert.

4.

In the Password and Verify boxes, enter Albert's password.

For fun and ease, just enter albert for the password.

5.

In the upper area of the window, click the Groups tab.

6.

Click the plus (+) button at right to assign some groups to Albert.

A drawer appears, with your newly created groups in a draggable list.

7.

Drag the Creatives group to the Primary Group ID box (which currently states 20) in the main window.

Albert's primary group ID changes to 1025, that of the Creatives group.

8.

Drag the Editors group to the Other Groups box.

9.

Also drag the staff group to the Other Groups box.

We make Albert a member of staff since staff is a system-level group.

10.

In the upper right of the window, click the Home tab.

We will now establish that the user's home directory will mount locally where they log in from, which is necessary for FCP to run correctly.

11.

Click the plus (+) button to add a home directory path.

A dialog appears for you to place in the path information.

12.

In the Home box, type /Users/albert and click OK.

13.

Click Save.

The user info is saved into the directory.

14.

Use steps 3 through 7 to create another user, Bonnie, making her password the same as her short name. When assigning groups to Bonnie, make her Primary Group ID Creatives, and her three other groups: Editors, Graphics and staff. Then, instead of steps 11 through 13, substitute the following steps.

15.

After you click Bonnie's Home tab, you'll see a /Users home directory path already specified for her. Click the little disc icon in the list that has /Users listed next to it, which will highlight it.

16.

Click Save.

Bonnie's info is saved into the directory.

Note

After creating the first user in a directory, as you did with Albert, Workgroup Manager assumes you wish to have all additional users' home directories along the same path. This is why it was not necessary to manually put in the path for Bonnie's home directory.

17.

Use the same steps to create a final user, Charles, whose password is the same as his short name. Charles' Primary Group ID should once again be Creatives, but let's make Charles exclusively a graphics guy: only place Graphics and staff in his Other Groups box. Finally, make sure to click the Home tab and make sure his home directory is also /Users.

To review, we have all three folks in our Creatives and staff groups, but Albert is exclusively an editor; Charles is exclusively a graphics guy; and the multi-talented Bonnie is a member of both. This is just one of many group schemes you can use to divide your users into manageable chunks.

You could also group folks by title or even the job number of their current project. You can see that adding, modifying, and deleting users and groups through the Workgroup Manager is very powerful.

18.

Quit Workgroup Manager.

Congratulations are in order again, because we have now finished setting up the first, and most difficult, part of our Directory Server. Now, let's get the SAN actually up and running.

Installing Xsan Software

It's time to get the software installed on each machine on the SAN. We'll first get our other client nodes booted and configured on our metadata network, so we can do as much of this as remotely as possible.

Setting the Additional Client Nodes' Static IP Addresses

Note

Every additional client node must have an admin account, and you should log into this admin account as you configure the machines in the next two subsections.


1.

Start up each additional client node, and log in as an admin user.

2.

For each additional client node, follow steps 1 through 9 in the "Setting the Client Node's Static IP Address" section, but modify step 8 slightly by entering 10.1.0.101 for the next node's IP address, then 10.1.0.102, and so on.

3.

For ease of implementation, it helps to place each machine's IP address on a sticky note on the edge of its screen.

Installing Xsan Software via ARD

Now we will install the Xsan software on all of our machines that will be on the SAN, which includes all of our client nodes and our Xserve.

1.

Get back onto our trusty Admin client node, and pop the Xsan Software Install CD into the optical drive.

2.

When you see the CD mount on the Desktop, double-click the CD icon to open it.

3.

Find the Install_Xsan.mpkg application and drag it to the Desktop.

4.

Eject the CD.

5.

Launch Apple Remote Desktop.

Now that you've added all the other client nodes onto the metadata network, you'll see their IP addresses in the main Remote Desktop window. Now we will upgrade the ARD client software on all these machines, in one step, like we did with our Xserve earlier.

1.

Select all the client Nodes in the current scanner list.

2.

Choose Manage > Upgrade Client Software.

You will be prompted to add each computer to the Master List.

3.

Enter the username and password of the admin account for that particular client in the appropriate boxes, then click Add.

4.

Repeat step 3 for each client node.

5.

In the Upgrade Client Software screen, click Upgrade.

6.

When the upgrade is complete, close the Status window.

From here, you can install the Xsan software on all your machines, and the Xserve, in one step, from one location.

1.

Select all the client nodes (except the one that you are currently on) and your MDC server in the list.

2.

Choose Manage > Install Packages.

3.

Drag the Install_Xsan.mpkg icon from the Desktop to the Install Packages window.

4.

Click the "Restart target computers after installation" check box.

5.

Click Install.

The Xsan software will automatically copy over to, and install itself on, each of your selected computers. They will also all restart when finished.

6.

When the task is complete, close the Status window.

Note

You may not want to install the Xsan Admin application (the program that administers the SAN, similar in design to Server Admin) on any machine belonging to anyone you wouldn't want trying to administer the SAN. But perform the install using the preceding method anyway. If you don't, some system resources that aid the MDC in first discovering the clients may not be installed. You can always manually delete the Xsan Admin application, located in /Applications/Server, from the client machine once the software has been installed and the machine has restarted.

Further, we are assuming that every client node has OS X 10.3.8 installed on it. If it doesn't, use ARD to update each client node to 10.3.8, then install the Xsan software.

7.

Quit Apple Remote Desktop.

8.

Finally, install the Xsan software on the Mac you are using to do all of this centralized work. (It's right there on the Desktop.) It needs Xsan as well!

9.

When the installer finishes, restart the machine.

Implementing Directory Services, Part 2

Now that we have all the software installed, it's time to get the client nodes bound to the directory that we set up earlier.

Binding the Client Nodes to the Directory Server

We will configure the Directory Access applicationfound in each client node's /Applications/Utilities folderto look for directory information from our Xserve. This way, end users will be able to log in from a client node and be able to have proper access to different directories on the SAN volume(s). More importantly, each end user and group will have unique user and groups IDs, which will make the MDC very happy.

1.

After our Admin client node has restarted from its Xsan software install, launch Apple Remote Desktop on it.

2.

Select the first additional client node on the list, and click the Control icon in the toolbar.

3.

In this client node's Control window, launch the Directory Access application, found in the /Applications/Utilities folder.

4.

Observe the lock icon in the lower left. If it's locked, click it and authenticate with the admin username and password for that client node.

5.

In the middle of the window, click the LDAPv3 listing, then click Configure.

6.

Click the blue disclosure triangle next to Show Options.

7.

Click New to create a new configuration.

8.

Type mdc.local in the Server Name or IP Address box.

9.

De-select the Use For Contacts check box, and click Continue.

10.

Click OK to leave this sub-window.

11.

Click OK to complete the binding.

12.

Quit Directory Access.

13.

Close the Remote Desktop control window for this node.

14.

Repeat steps 2 through 13 for each additional client node.

Now let's remember to bind our Admin client to the directory as well.

1.

Leave Remote Access running, and launch Directory Access on the Admin client.

2.

For this final client, follow steps 3 through 12 in the preceding exercise.

Finally, we will shut down all the machines, before we fire up everything in sequence and get ready to configure the SAN.

1.

Back in Remote Desktop, select all machines, including your MDC server, on the Remote Access list (except your Admin client), and choose Manage > Shut Down, then click the Shut Down button.

Watch in glee as all the machines shut down.

2.

Quit Remote Desktop on the Admin client.

3.

Shut down the Admin client.

Setting Up and Configuring the SAN with Xsan Admin

These final steps will allow us to get our storage and our nodes together and create a SAN. Let's go.

Firing the Whole Thing Up

It's time to power everything up, in sequence, in order to use Xsan Admin to create and configure our SAN.

1.

Power up, in order, the

  • Ethernet switch (if not already on)

  • Fibre switch (these take up to two minutes to power up)

  • Xserve RAID (wait until all status lights in the front of the unit are on)

  • Xserve (and wait until it's fully up, then...)

  • Clients

Note

Wait a minute! We haven't talked about setting up or configuring our Xserve RAID! In our exercise, we will make four assumptions:

  • All Xserve RAIDs, no matter how many drives they have in them, come from the factory preconfigured as RAID Level 5. Because the Xserve RAID is optimized for RAID 5 usage, you might not see much better performance if you reformat it to RAID Level 0. So, our suggestion is to leave it as is.

  • You've read the little note about "cooking" your RAID. If not, go back near the beginning of the "Installing the SAN" section and read it.

  • Your RAID is either fresh from Apple or has had its firmware updated to the latest and greatest version. If not, use RAID Admin to upgrade the firmware of your RAID. See Apple's support Web site for more info on this.

  • You are configuring two Xserve RAIDs, but you can configure as many as you like, up to 256 5.6 TB Xserve RAIDs per volume! You'll just be labeling and throwing more LUNs into your storage pool. More on that later.

Authenticating and Serializing Nodes

The pieces of the puzzle will come together in this next step, where we use the powerful and simple Xsan Admin app to create and mount the SAN.

1.

Once again from the trusty Admin client, launch the Xsan Admin application, located in /Applications/Server.

Upon launching, the program will ask for an address to log into. We will give it the address of the machine we want to be the metadata controller, which is our server.

2.

In the Address box, enter mdc.local, then authenticate with the name and password of the server's admin account, and click Connect.

3.

Click the Setup tab.

Hopefully, you'll see as many entries as you have nodes in your SAN in the list that appears: your MDC server, plus the IP addresses of all of your clients.

We're now going to validate all our nodes with serial numbers, so make sure to have them handy. Remember, you'll need a unique serial number for each node, including the metadata controller.

1.

Double-click the entry for your MDC server.

A window drops down, prompting you for information.

2.

From the Role pop-up menu, choose Controller.

The Failover Priority should automatically be set to High, and Built-In Ethernet should appear under the last pop-up menu.

3.

Enter the serial number.

Enter on of your serial numbers, and if you with, fill the Registered To and Organization fields with appropriate information.

We are setting our server to be the MDC (and only MDC) of this SAN. Further, the first MDC will always get a high failover priority, because we will want this node to be the MDC first. Later, if you add more MDCs, you'll set their priorities in the order you would want them to take over the SAN in case one fails. Lastly, with the selection of the built-in Ethernet of the server, we have officially dubbed our Ethernet network the metadata network.

4.

Click OK.

Your MDC server should have a green light next to it, reflecting its new status as an MDC.

5.

Double-click your first client node.

You will be presented with an authentication for this address.

6.

Type in the administrator's user name and password for this machine and click Authenticate.

In a moment, the listing will show an orange dot next to it, meaning that a successful authentication has happened across the network.

7.

Double-click this client node again.

You are prompted for a serial number.

8.

Type in a new serial number for this node, and click OK.

Since this node is a client, we needn't change anything once the password is in place. We should return to the list with this node shining green as well.

9.

Repeat steps 5 through 8 for the rest of your client nodes.

When you are finished, all nodes should have green lights shining.

10.

In the SAN Name box, type a name for your SAN.

This isn't the volume name; just a nice name for the SAN in general.

11.

In the lower-right corner of the interface, click Save.

You will see the SAN name reflected in the SAN Components list at left.

Assembling and Starting the Volume

This part is really fun: here you get to get to create a huge storage volume by dragging and dropping icons!

1.

In the upper area of the interface, click the LUNs tab.

You'll see four (or more or less, depending on the number of Xserve RAIDs you have on hand) LUNs with yellow dots in this list. These LUNs are ready for use, but are not labeled as Apple Cluster File System (ACFS) LUNs for our volume, so we'll do that now.

Note

For factory-fresh Xserve RAIDs, you'll see two LUNS per Xserve RAID on your Fibre switch. If you see fewer than two, check connections on the switch or on the back of each RAID.

2.

Double-click the first LUN.

A window drops down and asks for a label name.

3.

Type LUN1 into the box and click OK.

4.

Repeat steps 2 and 3 for each additional LUN, incrementing the number at the end of the name each time (LUN2, LUN3, LUN4).

5.

When finished, click Save.

The labels are applied to the LUNs, which now gleam green.

Note

Once LUNs are labeled for Xsan's ACFS, they are no longer available for good old HFS+ formatting. In order to get them unlabeled, I'm afraid you'll have to venture into the command-line interface and use the cvlabel command, which will be necessary if you ever intend to use these LUNs for HFS+ again. More info on this in the Xsan Admin Guide.

6.

In the upper area of the interface, click the Storage tab.

Here is our volume playground.

7.

Click the Volume icon.

A window drops down to ask for a volume name.

8.

Type in the name for your volume, and click OK.

An icon for your volume appears in the Storage window.

You just entered the name of the disc that the nodes will see mounted on the Desktop. We will leave the other settings (Block Allocation Size and Allocation Strategy) unchanged because they are set up perfectly for general purpose video file usage. You can read more about them in the Xsan Admin Guide.

9.

Click the Storage Pool icon.

A window drops down to ask for information about this storage pool.

10.

Type POOL1 in the storage pool Name box.

11.

Click "Any data" for the "Use for" setting.

Note

We have the option of creating our initial storage pool exclusively for metadata and process journal information only. This is to increase performance on nonmetadata storage pools by isolating the relatively small and articulate metadata to its own pool. One day you might do this. Today, this storage pool will contain both the aforementioned data and regular ordinary data, happily commingling.

12.

Leave the Stripe Breadth at 256 blocks and click OK.

Note

Apple says that a Stripe Breadth of 256 blocks yields the best general use performance on fully populated (14-drive) Xserve RAIDs.

Also, someone somewhere on our SAN will want read and write permissions, so we'll keep that setting at its default.

Finally, the Multipath Method is set to Rotate to switch to a second Fibre cable if the first one fails.

A Storage Pool icon appears, indented inside your volume.

13.

Click the Available LUNs button.

A drawer reveals your ready-to-drag, labeled LUNs.

14.

Grab them and drag them to your pool.

Your volume is now built. Look how big that thing is!

15.

Click the Close Drawer button.

You are prompted with a warning about mixing metadata and user data in the same Storage Pool. As mentioned earlier, you should avoid this for best performance, but for our exercise, it'll suffice.

16.

Click Save.

The volume creation process takes just a moment.

17.

In the upper left of the interface, click the disclosure triangle next to your SAN name.

Your volume pops up nested below it.

18.

Select the volume name.

19.

Click the Start Volume button.

Again, another pause as the volume gets ready to be mounted. After a while, you'll see a green light next to the volume name at left.

Mounting the Volume on the Nodes

Notice now that when clicked on the volume, our button names have changed. Now the interface changes its context to the settings of our volume. This is how we will mount the volume on the nodes.

1.

Click the Clients tab.

A list of your authenticated and serialized nodes appears.

Now don't go crazy here. Although we can mount the drives on all clients simultaneously, let's mount one node at a time.

2.

Select one of your client nodes (the one you are currently working on is ideal) from the list.

3.

Click the Mount Read & Write button.

After a short pause, you'll see a thing of beauty on your Desktop: a SAN volume to call your very own.

4.

Repeat steps 2 and 3 for all the additional nodes, including your server!

5.

Have fun running around the room(s), watching the volume pop up on everyone's Desktops.

This is required.

Note

Okay, a bit of seriousness here is necessary. If any of your nodes have gone to sleep during this process, it's best to wake them up before you try to mount the volume.

Implementing Directory Services, Part 3

At this point, you've probably picked this book back up after putting it down hours ago and playing extensively with your volume, establishing crazy speed tests and discovering all kinds of interesting phenomena that happen with file-level locking cluster file systems. So, if you can, put your lab coat away, and let's get down to the big reason why we created a directory in the first place, and that is to create specific areas on the SAN where different users or groups have access and read/write permissions. The exercises here are designed more for stimulating creative solutions for your storage challenges than dictating how they should look, but feel free to steal any part that works for you.

Creating Root-Level Directories

Next, we'll look at Xsan Admin's capability to create root-level (and only root-level) folders on the volume, and then we'll assign specific permission to those folders. If our workflow is simple, and we need general areas where one group can get into and others can't, Xsan Admin will do the trick for us.

Note

We can always set permissions to volume folders deeper than root level by simply creating them in the Finder, getting information about the folder, and setting permission settings there. Even though all the computers on our SAN are bound by a centralized directory, meaning that our directory's users and groups appear in everyone's lists, we'll probably want to make these folders when logged into the server via ARD, or by using OS X Server Workgroup Manager. You can learn more about setting detailed file and folder permissions in the OS X Server Admin Guide.


1.

Back in Xsan Admin, click your volume and then click the Affinities tab.

Note

You must have the volume mounted on the MDC for the Affinities and Quotas tabs to work in Xsan.

2.

In the upper-right area, click the plus (+) button to create a root-level folder.

A window drops down to ask for a name and affinity for the folder.

3.

Type Editors Work in the Name box.

4.

From the Storage Pool Affinity pop-up menu, choose POOL1.

5.

Click OK.

A folder appears nested inside the volume.

Note

Affinities are an excellent feature of Xsan that we're not able to leverage here, since we have only one measly storage pool. Essentially, we could direct all data placed in this folder to a specific storage pool in our volume, allowing us to save the data to a faster or more secure storage pool. Neat, huh? Read more about it in the Xsan Admin Guide.

Now let's set specific permissions for this folder.

1.

Click the Editors Work folder.

2.

In the lower-right area, where the permissions data is, click the plus (+) button.

Another drawer appears with a list of all our directory's users.

3.

Drag the drawer out a little more to see the UIDs for everyone in our crowded list.

Note

Sorry for the clutter, but this list is a proper server list, which includes process users. These users are not people, but actual system processes that have usernames.

4.

Click the Groups button of this drawer.

Now we see all the groups in our directory, plus all the server groups, with their corresponding GIDs.

5.

Find the Editors group and drag it to the Group box in the lower portion of the interface window.

6.

For extra security, change the Other settings to No Access.

No one but the Editors group will even be able to get into the folder, let alone read or write to it!

7.

Using your knowledge of this interface, create another root-level folder called Graphics Work, and assign Read & Write permissions to the Graphics group. Lock this folder to all others, just like you did with the first folder.

8.

Finally, create a Creative Drop Box folder, and assign Read & Write permissions to the Creatives group, but Write Only access to Others. This way, anyone can drop something in this folder for use by the Creatives.

9.

Click Save to save all this work.

10.

Quit Xsan Admin.

To review: we have the Editors Work folder that will be available only to the Editors group; the Graphics Work folder, available only to the Graphics folks; and the Creative Drop Box, which all Creatives have access to, and anyone else can drop stuff for the Creatives in. Now let's have a look at how our directory works.

Logging in as Directory Users

What we'll do now is log out of a machine (any client node on the SAN will do), and log in as one of our users, to see the effect of these root-level folders we've created.

1.

Choose Log out (Username) from the Apple menu or press Cmd-Shift-Q on the client node to log out.

2.

Press Return to confirm.

When the login window appears, you will now see an Other icon.

3.

Click the Other icon.

4.

Authenticate as Charles (username charles, password charles).

5.

Open the volume and look at the permissions of the folders.

Looks like Charles, who is a graphics guy, can get into the Graphics and Creative folders, but not into the Editors'.

6.

Log out and authenticate as Albert this time.

7.

Open the volume and take a look.

Albert, being a cutter, can't get into the Graphics folder. This may be a problem, but hopefully you know how to fix it. Let's move on.

8.

Log out and authenticate as Bonnie.

Bonnie, talented cat that she is, has access to all the folders, since she is a member of both the Editors and Graphics groups, and also is a creative.

9.

Log out and authenticate as the administrator on that machine.

10.

Open up the volume.

What? We gave access to everyone only with the Creative Drop Box, but even then it was only write access. Why can the client's admin get into all these folders?

The answer is simple. The admin of this machine bears the same UID as the admin for the server, 501, so Xsan sees them as the same user.

As we said earlier, every new OS X Mac, when it first starts up, gives the first user admin access and a UID of 501, just like it did with our server. Do you see the chaos we would have if we didn't have a proper directory? Do you also see why that, on a SAN, you can't give out admin privileges willy-nilly anymore?

So, as a rule, we need to add a strong password for the admin user for each of our nodes on the SAN, and create regular non-admin users for those who will use the SAN day-to-day. Some facilities will elect to create an "install admin" user that will have admin privileges in order to install applications, plug-ins, and the like. These specialized admin users should be created locally in System Preferences > Accounts, making sure they have a UID other than 501, so that they are never confused with the 501 admin of either the server or client node.



Apple Pro Training Series. Optimizing Your Final Cut Pro System. A Technical Guide to Real-World Post-Production
Apple Pro Training Series. Optimizing Your Final Cut Pro System. A Technical Guide to Real-World Post-Production
ISBN: N/A
EAN: N/A
Year: 2004
Pages: 205

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net