So in this session, we're going to start off by talking about why you may need a SAN file system for other benefits. And we're going to spend a pretty good chunk of time talking about all the key features of XAN, everything from the basic file system to the management, to performance, to cross-platform support.

And we're going to cover what it takes to deploy XAN. Basically, we're going to go over the basic hardware configuration with a few examples. And then to conclude the session, we're going to talk about different software and hardware product Apple offers to build SAN and also build different solutions on top of it. So that should keep us busy for next hour, hour and a half. And then at 10:30, we're gonna talk about how Exant works from engineering perspective. So, for example, we're gonna talk about things like what gets passed on the wire when you make a file system call.

And we're gonna spend lots of time talking about the administration of XSAN. In fact, we're gonna have a demo of XSAN admin software using it to set up SAN from scratch, or almost from scratch. So that should be pretty fun. Right, and then we're gonna talk about different aspects of administration, such as command line tools. Then we're gonna talk about a few tips for developers, things they should watch out for when accessing some volumes, X sum volumes, things such as scalability and locking and other issues.

And lastly, we're going to talk about XM Developer API. We're going to have a demo for a couple sample applications using that API. And it's pretty visual, so it should be pretty entertaining. So with that, I would like to introduce the speaker of the first session, Tom Gaugen, Director of Server and Storage Software from Worldwide Product Marketing. TOM GAUGEN: Thanks, Kazem.

Good morning, everyone. So it's first thing in the morning, and I was playing hockey last night until late. So I'm going to try to move along quickly and hopefully keep myself going and keep all of you going as well. I have a few questions to ask right from the beginning. How many of you are familiar with storage area networks in general? OK, that's good. How many of you have actually deployed a storage area network? All right. How many of you put a SAN or a cluster file system on that storage area network? And how many of you have written a cluster file system? Yeah, see, I knew Ted Kline was in the audience, so I knew I could find someone who had done that at least. So I'm going to take you through kind of an overview of storage, storage area networks, and XSAN, give you some background information on XSAN and storage area networks in general, just to make sure that we're all using the same terminology, because in the industry, the terminology somewhat varies from vendor to vendor. So I'll take you through what we're doing. I'm going to give you some information on our cluster, our SAN file system, and then I'm going to conclude by taking you through the range of products we now offer for IT deployments. So let's jump right in real quickly. This is XSAN, and we refer to it as the SAN file system for Mac OS X. And I can't say this will be the final mock-up of the box, but this is our product. We introduced this at NAB in April. It actually won an award as best of show at NAB. People were very excited about it. We demonstrated it at NAB. I think we had six terabytes of storage in a single volume. shared among five or six different systems.

These were desktop systems and we were doing video, real-time online video editing from those systems. So it provides some really, really great performance, some great features. Okay, there we go. So as a backgrounder, for some of you, I know some of you this will be very trivial. On the other hand, for some of you, I just want to bring you all up to speed on sort of why we decided we needed to have a SAN file system or a cluster file system. And I'm going to take you through the basics of storage architectures, but I'll move along quickly so we don't bore some of you in the audience. So direct attached storage, or DAS, this is very, very simple. Everybody does this. It's plugging an external storage device into a server or a desktop. The desktop or server mounts that storage device. And of course, if it's a file server, it can actually share that storage to clients across your network. And it does that with typical network file sharing protocols. So it's pretty straightforward. You can use Fiber Channel or SCSI interconnect between the server or the desktop.

And of course, you could use FireWire if you wanted to as well. There's a number of direct attached storage interconnects. Today, you could use USB and share that if you wanted to. Now, the one thing about this is that the file server becomes a potential bottleneck for the performance of that overall system. The file server is the only way to access that external storage, and the file server is the final arbiter on who gets access to that storage. So everything goes through that one file server. Now, not only is it a performance bottleneck, but it is a potential single point of failure as well.

Now, what came out and came into vogue a few years ago were NAS devices, network attached storage. The reason these are very interesting is that these are purpose-built appliances for sharing storage over the network. So in a sense, it's just like a direct attached storage device except that it's storage with an embedded file server. It's a good way to think about it.

So it has some really great advantages, one of which is typically NAS devices are extremely easy to deploy, very quick to get them up and running. And that's because they are single purpose devices. Their whole point is to share storage on the network. At the same time, they do suffer from some of the same performance and scalability limitations as direct attached storage. Now there's a whole range of very sophisticated things that some companies offer in terms of storage virtualization services, where they can actually make multiple NAS devices appear like-- and on the network appear like a single device, or they can eliminate some of these single points of failure. But it is fairly complex to deploy the storage virtualization software to accomplish this.

Now, in a storage area network, this is where multiple storage devices are attached to a fiber channel network. That's really what a storage area network's all about. Now, fiber channel today, as well as iSCSI-- you could use a different type of network called iSCSI. This is SCSI protocol over IP, over ethernet. But for all intents and purposes today, when I talk about a SAN, I'm going to be talking about a SAN based on fiber channel. So we have multiple storage devices connected to a fiber channel switch, and then we have multiple servers that are able to access those storage devices. Now, a key thing is that they essentially access the storage devices. And in a sense, they share the storage devices, but they don't share the data on the storage devices. I'll get into a little bit of detail on that right now. So why a SAN file system?

Well, as I said, a SAN, you have multiple computers accessing the same storage device. In the example here, we've got an XSERV RAID connected to a fiber channel switch. The XSERV RAID presents two RAID controllers, hence the two fiber channel lines coming down from the top, and the fiber channel switch to the three XSERVs that are shown here. These three XSERVs are connected via fiber channel to the fiber channel switch, and they can see the XSERV RAID. Each one of them can. In fact, they could take that storage from the XSERV RAID and they can reshare it using network protocols, such as AFP SMB or NFS, across the network to these clients. So they can do the exact same thing that a NAS device or direct attached storage can do.

However, the challenge with this, before you have a SAN file system, is that each RAID set is effectively a volume, and the volumes are connected separately to each one of the servers. So you have A, B, and C up in there, denoted by the colors, and A, B, and C are mounted by each of those servers. Only one server can mount one file system. So a server could mount multiple file systems, but the file system or the A or the B or the C can only be mounted by one server. Can't be mounted by two servers at the same time.

So each RAID set is mapped to a server. That's a process called provisioning in the SAN world. And that's what that's all about. The reason a SAN file system is interesting is you eliminate these data silos. Keep in mind that server A over here only sees the data in volume A. Server B only sees the data in volume B. Server C only sees the data in volume C. That's before a SAN file system.

After a SAN file system, you can actually have data, A, B, and C, as denoted up above, in a single volume. So this would be a single 3, 3 and 1/2 terabyte volume on the XSERV RAID. And that volume can be seen by each of these servers. So this is kind of a subtle difference between network-attached storage and SANs, in that the file system used for a SAN can actually-- volumes created by that file system can actually be mounted directly with direct block level access by each of the servers or desktops that's attached to the SAN. So multiple computers, all three of these computers can read and write to the same volume at the same time. And this is block level access. Very very different from, in a sense, from when you have a network file system, it may may be sharing a file system to multiple computers, but final arbitration, block level access to the volume that it's sharing is arbitrated by the file server itself, by that single file server. This is very different. And of course, it could reshare that volume to all of these clients as well. So now we have three servers able to share the data that's on that volume out to the network.

Now, the nice thing about a SAN file system is it's very, very easy to scale. So you want to add more storage. You've gone past 3 and 1/2 terabytes, and you want to go to 5 or 6 terabytes of storage. You literally add the storage in. You can grow the file system. And all of the systems that are attached directly to the file system simply see a larger volume with more space for more data.

Now, again, the other thing you can do is you can add more servers to the SAN as well and share the data in the volume through more file servers. So you can literally get more network performance out of the SAN than you would get with having a single server sharing a volume. Because now you have three, four, five, or six, as we show here, servers able to share the data that's on the same volume. So that's why a SAN file system is very interesting. A little overview of XSAN.

XSAN is for high performance storage networking. So it's very, very fast. In fact, when you set up an XSAN system properly configured, it'll be-- I don't say this to a lot of you-- it'll be much, much faster than the internal disk drive on your system. In fact, you will get whatever the storage architecture that you deploy can give you. XSAN is very, very lightweight in terms of its overhead on the storage infrastructure. It has a high availability architecture.

So you can imagine a system like this is going to be deployed in mission critical environments. We've done a lot of things to make sure that when you deploy it that way, if any single failure happens somewhere on the system, we've got you covered. And I'm gonna take you through some of that as well. XSAN provides some really, really interesting volume management tools. And that's where we get into some of the nomenclature I mentioned. And I'm going to walk you through a little bit of the volume management tools and show you what we're talking about there. And then later on, I know the guys are going to show you how to actually set up a SAN volume.

XSAN is going to be easy to use. And when I say easy, I don't want to be really lightweight about this whole thing. Obviously, you need to know about storage area networks to get one built and one running, even before you put XSAN on it. You're going to need to know a little bit about SAN file systems and how to deploy them. But for most of the mainstream configurations, we're hoping that our management tools will help you get those up and running in a nice, optimized way without having to know too, too much detail about the innards of the SAN file system. So I'll tell you a little bit about that. And we have a great story when it comes to compatibility and interoperability, and I'm going to run you through all of that because no SAN solution stands on its own. No SAN solution from a single vendor really stands on its own. And you need partners involved to be successful in this space. So what is it? It's a 64-bit cluster file system. So it's a full 64-bit cluster file system.

Now, on Panther, that means that you'll get up to 16 terabyte volumes. That's the limitation built into Panther today. On Tiger, that limitation goes away with XSAN. So on Tiger, you'll be able to build very, very large, if you don't think 16 terabytes is large enough, very large volumes. Now, to give you some idea of what's happening in the video space, there are customers that have asked us for over 100 terabytes of storage in a single volume. And so we're going to take a shot at meeting their needs as we go through the deployments of XSAN. You can obviously have billions of files. Up to 64 concurrent clients can access an XN volume. So what does that mean? That means that you can have up to 64 systems-- I showed you six systems in the largest deployment I showed here-- you can have up to 64 servers or desktops or a mix of the two accessing the same volume, direct block level access over fiber channel to that one volume. And of course, you could create multiple volumes as well and have a different 64 connect to a different set of volumes. That does not mean that you are in any way limited by the number of network clients that are coming in over AFP, SMB, or NFS and connecting into a file server that is directly connected to the SAN. We're only talking about here the number of machines that are directly connected to the SAN. And of course, it gives you file level locking. And what this really means is that on a single volume, you can have multiple readers and multiple writers.

So you can have multiple computers writing to the same volume at the same time, and you can have multiple computers reading from the same volume, and in fact, in this case, reading from the same file at the same time. The only limitation, if you call it that, is that you can only have one computer writing to a particular file at a given time.

So from an HA perspective, we do a couple of things. There's a thing called a metadata controller, and I'm going to show you a little bit more about what that's all about in subsequent slides. But the metadata controller is like the traffic cop for the SAN. What the metadata controller does is that any time a computer on the SAN wants to open a file, read a file, write to a file, it first talks to the metadata controller. And it says, can I open that file? I'd like a read/write access to this file xyz. And the metadata controller checks and says, OK, no one else has got read/write access right now. So here you go. You can have read/write access. And here's where the file is located.

But note the difference from a network file system. It doesn't say, here's the file. It says, here's where the file is located. And then the computer that requested the file goes in over fiber channel directly to the storage at the block level and reads or writes to that file. So that's what metadata controller failover is all about, is providing a secondary metadata controller. You can imagine if the metadata controller fails, then you've got a real problem on your network, on your SAN, because nobody knows if they're allowed to have access to a file, where the file's located, and so forth. XAN comes out of the box with support for metadata controller failover. If any metadata controller on your SAN fails, the XAN computers, the computers running XAN, will get together, and they will nominate another one of these computers to take over the duties of the metadata controller. They will do that automatically, and that will happen within seconds of a detected failure in the metadata controller. So that's what metadata controller failover is all about. One other added note about it, because we ship XSAN with the metadata controller software built in, unlike a lot of other SAN vendors, any XSAN system connected to the SAN can be the metadata controller. So we support something called cascading failover. This means if the second metadata controller, if that person who stumbled into the machine and kicked the power cord out stumbles into the next metadata controller and kicks the power cord out, then the next system on the SAN will take over.

And so as long as any one system, any one XSAN system is up and running, you have access to your data. We think that's extremely important with these systems. Of course, the file system's journaled. You'd expect that. And that's why we can actually recover the file system within seconds of a failure. The other metadata controller takes over, accesses the file system, runs the journals, and you're up and running within seconds. We support something called fiber channel multi-pathing. So some of you may have purchased an XSERV, and you may have gotten the fiber channel card that goes along with it. We have a fiber channel host bus adapter, or HBA, that goes into the machine so that you can connect a fiber channel cable into the XSERV or into a Power Mac G5.

The thing is that that card actually supports two connectors. And you could actually run both those connectors to the fiber channel switch where they can see the storage. And the reason we do that is that we use both of those connectors in XSAN. This is what multipathing is called. It refers to. And we can use both those connectors to send requests for packets or blocks of storage and receive those blocks of storage. So you can actually get a theoretical 4 gigabits per second.

Each fiber channel connection provides 2 gigabits per second. You can get a theoretical 4 gigabits per second into an XSERV G5, for example. Now, keep in mind that that's theoretical, because you'd have to have a storage architecture on the other side of the SAN. You'd have to have hard drives and RAID controllers and so forth that can actually deliver four gigabits per second. But if you had that, you could get it in there. The other thing with multi-pathing is if one of the paths breaks-- so if someone steps, that same guy who's stumbling around your data center actually breaks one of the fiber cables that are running to your storage or joining to your switch. The other connection continues to work, and the file system continues to function, and that computer continues to have access to the data that's on the storage. So that's fiber channel multipathing. There's one last feature. Now, this feature is interesting because it actually requires that you, those of you who are developers, be involved in this. And this is called bandwidth reservation. Now, I want to kind of describe, in a sense, I mentioned that if you have theoretical 4 gigabits per second, you can get that into the computer if you have the storage architecture to support it. It can get very expensive to say support 4 gigabits per second into every computer that you have on the SAN. Those of you who have tried to do some of this understand what I mean. You have to buy a lot of storage to be able to do that. You have to have a lot of disk drive spinning in order to be able to deliver data like that. So when most people design their SAN, they design it to deliver the bandwidth that they need for typical operations. They look at the mean. They look at what they're usually doing every day, day to day. So if you're a video person and you're doing SD video, you'll design your SAN to give you multiple streams of SD video and audio, and it's some type of audio, to each of the systems that are connected, each of the editing bays, for example, that are connected to your SAN. In the same sense, if you're setting it up for file storage, you'll take a look at each of the servers that you have sharing the files across the network and say, how much bandwidth, storage bandwidth, do I need to provide for each of these machines?

You'll sum it all up, and you'll try to create an environment that delivers that from a storage architecture perspective. Now, in some cases, someone may walk in say, you know what, and this happens in the video space a lot. You walk in and suddenly someone wants to capture HD video right into the sand. Now, that's a critical operation. It's going to take an hour or two or three, depends on what you're doing. And you want to let them do that. And you want to make sure that while they're doing that, if some editor comes into another station and sits down and decides to edit some stuff, that they can't mess up this critical capture operation that's happening in one of the stations. So the way that works is that the software managing the capture operation can be written to use our bandwidth reservation APIs. We have a set of APIs for this. So it can be written to use that. And so the administrator, when they set up the capture operation, can say, I want this particular operation in this particular file handle, for example, to get x, y percent of the available storage bandwidth. So you know what your storage bandwidth generally is, and you say, well, I want to make sure that this guy always has 65 percent of the available storage bandwidth.

No matter what these other stations try to do, fail them if you have to, make sure this guy always gets everything he needs. And that's what bandwidth reservation allows you to do. You of the available bandwidth to a specific file handle, you do that for certain critical operations that don't happen very often. So that you can literally get more bandwidth out of your system in a sense. It's not going to give you any more than you have, but you can deliver a certain amount of that bandwidth directly to one operation when you need to do that sort of thing. So that's what bandwidth reservation is all about.

From a volume management perspective, we support a range of things. And I'm going to walk you through a little bit with this with some pictures. Storage pooling-- so we group multiple storage devices together, really multiple RAID devices typically. And you'll hear me, we'll hear others refer to them as LUNs, logical unit numbers. A LUN is simply a logical grouping of storage that's hidden behind some form of RAID controller, typically. And so, for example, with the XSERV RAID, as many of you know, it has two RAID controllers in it, seven drives on either side attached to each of the RAID controllers. If you took the seven over here and just did, say, RAID 5 across them all to that RAID controller, the seven over here, RAID 5 across them to that controller, when you looked at it across the fiber channel network with XSANS or with XSANS admin tools, you would see two LUNs.

And these two LUNs can then be grouped together in something we call the storage pool. In fact, you can group multiple LUNs across multiple devices into multiple storage pools, in fact. So I'll show you how we can do that sort of thing and what that's all about. We can dynamically scale volumes, as I mentioned earlier. So you can grow these volumes.

We support things like volume mapping and affinities. I'm going to go into a little bit of detail on this. You can decide with the XSAN admin tools which systems connected to the SAN are able to mount which volumes, and you can have that mount occur. You can force that mount or force that mount right from your admin console. And as I mentioned, the admin console works remotely, so you can actually run that on a PowerBook or an iBook and connect into your SAN remotely and take care of that type of management. Affinities I'll go through. It's better to do a diagram for that because it becomes really, really clear what affinities are all about with the diagram. And we do have offline defragmentation tools. Now, the file system is designed, and by design, designed to minimize, if not eliminate, fragmentation. But there are, of course, certain operations that can happen on a file system that are sort of out at the fringes that can cause some amount of fragmentation. And so we include the defragmentation tools along with the product so that you can run those if necessary on the file system. So let's talk about how we create a volume.

I mentioned the XSERV RAID. I build a RAID set, as I mentioned, from, say, those seven drives. format it or initialize it, I should say RAID 5, and I do that with the RAID admin tools. We have to be very clear about what tools we use with XAN because you will not be using disk utility with XAN. Okay? Disk utility is for creating HFS Plus or UFS volumes and doing software RAID. XAN has its own volume format, and so when you create an XAN volume, you'll be using the XSAN admin tools to do this. So we create a RAID 5 LUN. We haven't got a volume yet, but we've got a LUN. It shows up on Fiber Channel.

We can take multiple LUNs, as I mentioned, and put them into a storage pool. And the storage pool allows you to group multiple LUNs that are similar to each other. So take multiple RAID 5 LUNs. Each LUN, say, is one and a quarter terabytes in size, and you group them together. What XN does is automatically stripes data across the storage pool. So now you have this logical grouping of storage, this logical pool of RAID 5 lawns.

You can actually create multiple pools and put them into a single volume. Now in the example I'm showing here, we have a RAID 5 storage pool made up of one or more RAID 5 LUNs, and a RAID 1 or a mirrored set storage pool made up of one or more RAID 1 or mirrored sets.

OK, and we've pooled the two things together. We haven't pooled them together. We've grouped them together in a single volume. Now, some of you out there are saying, well, that's kind of cool, but where does my data go? Right? I mean, does it go on the RAID 5 hardware? Does it go on the RAID 1 hardware? Just exactly where does it go? And that's what's kind of interesting about affinities. So we all know the RAID 5, in theory at least, would be a little bit faster than the RAID 1.

and typical storage hardware. The RAID 1, however, is mirrored. So it's actually the most protected type of storage that you have. It's a mirrored set. So you have fastest and most protected. Now what you can do is you can actually, through affinities, associate those storage pools with directories or folders in the finder or folders in that volume. So if you had a couple of desktops hooked up, as I've shown here.

You can literally provide the user with two folders. In this case, I've called them fastest and most protected. You could call them work in progress and final work, for example. And the work in progress could go to the RAID 5, and the final work could go to the RAID 1. So in a sense, in reality, affinities will really help you set up interesting workflows across the SAN and move data around the SAN into the type or category or class of storage that is relevant or most useful, most appropriate, for the type of data that you want to store in it. So this is a really interesting feature of XSAN, and I invite you to check that out as well.

From road administration perspective, as I mentioned, fairly easy to configure. We do real time monitoring. We'll do event notifications. We'll do things like email you or page you in the event of a metadata controller failover, a fiber channel problem, a quota problem. We support usage quotas. We have both soft and hard quotas. And we do have integration into LDAP. And this is where I'll take a little digression here, if you'll allow me this. So from... From a SAN perspective, the file system sits underneath the standard sort of API set, file system API set in Mac OS X and Mac OS X Server. So for all intents and purposes, it just looks like another locally attached internal, if you will, volume on your system or drive on your system. And this is really, really interesting for a couple of reasons. Now, with a couple of caveats, too. That internal drive looks and behaves mostly like UFS, follows POSIX locking semantics, and is case-sensitive. So all XAN systems will be case-sensitive.

And we are relying on all of you to do the proper thing from a locking standpoint in your applications. So when you open a file for a user for read-write access, open it. And typically in Carbon, this takes care of itself automatically. But if you're doing a Cocoa app or a Unix application, open it and assert the POSIX lock for that operation. And we will adhere to that and use that in XAN to make sure that your data doesn't get trampled by some other user. Now, so that's where XAN sits. And the reason that's interesting is that on our systems, that means that you can control access to XAN, to the folders and the files in XAN, using a directory server. So when the person logs into the machine, or when they remotely attach to a server and go in using, say, a file service, They have an identity, a UID, that has been given to them by the directory server at login time. And all of the machines connected to the directory server-- in other words, all the machines on the SAN connected to the directory server-- recognize that UID and will use that UID to determine whether or not that person has access to a folder or file on the SAN.

And because XSAN is coming out in the fall, jump ahead a little bit, but XSAN is coming out in the fall, right now we're adhering to POSIX permissions, but not ACLs on XSAN. So we use the permissions model that's built into Panther for that. But that gives you some control over who has access over data in XSAN, gives you full integration with an LDAP directory server, and for that matter, Kerberos infrastructure as well, because we're sitting, as I said, below the file system layer in the operating system.

So I mentioned a complete SAN solution, and mentioned that you need partners to really pull this off. So from a hardware perspective, we offer XSERV RAID. It will be qualified on XSERV RAID. It will be qualified with the XSERV G4 and G5. It will also be qualified with the Power Mac G5 and with Power Mac G4s back to dual 800s or better.

We have our own Fibre Channel PCI card that we're qualifying the system with as well. It's going to be qualified with our professional software, including Mac OS X, Mac OS X Server, and many of our professional applications. We have worked with the Fibre Channel switch vendors and we're testing with these switches. There's a list of switches on our website that we're testing with from Brocade, Qlogic, and Emulex. So check those out. And from a data management and interoperability standpoint, we have worked with ADIC to ensure that you can add Windows, Linux, and other Unix systems to the SAN. And ADIC is supporting XSAN with their Stornex file system. The compatibility is with their Stornex file system. And they're also supporting XSAN with their Stornex management suite. Now what that means is that you can use their data management tools as a foundation for something called-- some of you will be familiar with this-- but something called information lifecycle management. And this is policy-based storage management. And they have some really, really great products to do this. And you'll be able to use those with XSAN to do things like-- I mean, I think of it as backup on steroids, but basically to be able to migrate your data from tier on to tier two storage and migrate it all the way back to tape. So, and to automate a lot of that process.

So just a little view of how this can happen. You can literally put XSAN on, say, a Power Mac G5, an XServe G5, have that connected in. It sees the SAN volume. There's a metadata controller, so XSAN's up there running on another XServe G5 as well. But you could literally take a couple of servers running Windows or Linux and have those servers connected into the SAN as well. Now those machines would be running the Stornex file system from ADIC, and you can purchase it from them. It will install and run and allow you to see the XSAN volumes. And as well, you could use the Storinex storage management software to back up and maintain all of the data in your SAN as well. So this is a full and complete solution that we're offering here. I'll take a drink of water here, but I want to take you through quickly some example deployments.

And in the kind of walkthrough of some example deployments, I also want to show you how you, specifically, how you set up some of the infrastructure for XSAN. Now in the later session, they're going to get right under the covers and show you more of this, but I want to give all of you kind of an overview of how all of this works.

So when you're setting up an XSAN, you need a storage device, which is an XSERV RAID. You need a fiber channel switch. You need, obviously, the XSAN systems, the systems that are going to access the storage. And this will be servers or desktops. And you run XSAN on each of these. And they all connect in over fiber channel to the storage area network. One of these systems you're going to denote or decide is going to be your metadata controller. Remember that traffic cop for the SAN.

So fiber channel network, you get high speed. You'll get on each fiber roughly-- well, roughly, you'll get the scope for 2 gigabits or 200 megabits per second. And we have numbers up on the website on what the XR-RAID can actually give you sustained. But it's on the order of 180, 190 megabytes per second sustained throughput.

Correct me, guys, if I'm wrong on that one, but that's my understanding of those numbers. So you get that out of the XSERV RAID, and you can, of course, provide that to each of those machines. Now, each of these systems-- I want to be very clear about this-- needs to have a copy of XAN running on them.

So you buy four copies of XAN, you put it on the four systems, install it, get it configured using the XAN admin tools, select one machine as the metadata controller, decide and wait which of the other machines should actually be the backup or standby metadata controller if the metadata controller fails and you're on your way. Well, sort of.

There's a back channel network that needs to be deployed with XSAN. We refer to it as the metadata network. I don't want to confuse you with the metadata that's associated with the spotlight technology. Metadata we're talking about here is file system metadata. File system locks and locations and all of that sort of stuff. So the file system metadata is moved around on a separate metadata network. Now, this is just a TCP/IP ethernet network that you set up between all of these systems. And-- What it provides is really out-of-band communications. And the reason this is important, and the reason it's architected this way, is that what you're sending back and forth with metadata is small packets. So small requests. I need to open up this file. OK, you can open up this file. FibroChannel is really optimized for large chunks of data.

And so if we were to take all the metadata operations that would happen on a large SAN and run them across fiber channel, we'd be bogging down your fiber channel network, where all your storage performance is, with metadata communications. So to optimize around this, we put the data, the big chunks of information, on the storage network, on the fiber channel network, and we put the metadata on a separate network. Now, the actual metadata actually lives on the SAN, but it's accessed and cached by the metadata controller, and then it's controlled, and access to it is controlled by the metadata controller. So this separate out-of-band network. Now, I'll have a lot of people have come up to me and said, so do I have to use a separate network for the metadata network?

And the answer is, well, it's IP. You don't have to use one. But if you use your local area network, for example, and someone initiates a large FTP transfer across that network for whatever reason, that may inhibit some of the metadata traffic on that network. And that may slow down your file system. And I almost guarantee it'll slow down your file system. Because that will delay those packets being sent to the metadata controller. So we recommend, very strongly recommend, is that you use a separate network for this metadata controller network.

Now the good news is that you can do that, and you can still share the data over Ethernet when you're using, for example, an XSERV G5, because we do have two gigabit Ethernet connectors on the back of the XSERV G5. So use one of them for the metadata network, and use the second one for your local area network. And as I mentioned, you can then share the data using common networking protocols to as many clients as you want over your local network. Now these machines, to be clear, the bottom ones, the desktops that are shown here, do not have to be running XAN. You do not need an XAN license for them. Of course, with Mac OS X Server, you get an unlimited client license. You can connect up as many clients to do file sharing with the unlimited client licensing as you want. And we don't care whether that data comes from. If it comes from the SAN, that's great.

So as I mentioned, dual gigabit Ethernet in the XServe G5 to support this. Now you could also, in another sense, use this to back up some kind of backup and use this as the storage pool for a web service as well. Whether it's a website, QuickTime streaming server, or something like that, and have internet clients connected into them. But in any case, there's two networks. There's the main network where the data transfer happens, And there's the metadata network, which is where the file system does all of its operations, with the exception of doing the actual block level access to storage, which happens over the fiber channel network.

When we deploy XSAN in kind of a post-production environment, we deploy XSAN to desktops. And I'm sure those of you in the audience who do a lot of work in video. So you create a SAN volume using multiple XSERV RAIDs, fiber channel switch, metadata controller, server makes a nice metadata controller, and then you set up the desktops with access to the SAN. You can also, on the same network, put a server there, have it reshare some of that information using the QuickTime streaming server. So you can imagine a workflow where you're doing video editing and when, for example, at the end of the day or at the end of their time working on this project, an editor makes a QuickTime movie and posts it into a special folder where the QuickTime streaming server can share it out to, say, a producer or a director who wants to just check in over the network without having to come down to the editing bay.

And, of course, you could put appropriate security and access control around all of that. So this is an example of using XAN and post-production workflow. Now, the thing I'm not showing here that you do have to set up again is that private Ethernet network that connects all of these systems and the metadata controller. So there'll be a private Ethernet network. You can multi-home these systems, So you could use a second Ethernet connection. You can put another, an external, well, a gigabit card into the XRF G5, for example, or you could even use the airport connection on the XRF G5 to connect it to the Internet or connect it to your local network. You want to reserve one Ethernet port for the metadata network.

Computational clusters are another area that we're looking at with XSAN. And in this case, we're showing a very large cluster. For small clusters, as I said, up to 64 systems can connect to the SAN. So if you had a small cluster of 4, 16, 32 systems, you could actually have them all connected directly to the SAN over fiber channel with block-level access to a single storage pool, which means they all can be using the exact same data, writing back to the exact same location at the same time. Now, if you have a very large deployment, and, of course, we use the Virginia Tech one all the time, 1,100 G5s. Now, they, of course, XAN isn't available, so they weren't able to do this. But if they had chosen to do so, they could have actually created an environment where of those 1,100, say 20 of them, 25 of them, pick 55 of them, say 55 of them were connected into the SAN directly. And those 55 were the head nodes for another 20 machines in the cluster.

So the head node connected block level fiber channel directly into the SAN. And then what it does is uses NFS to share the data, or AFP, to share the data to the other XSERVs in the cluster, the other 20 for which it's responsible. And you create a network between those 20 in the head node, another 20 in the head node.

And now you've covered 1,100 machines. And for 55 of them, they're feeding data or they're getting data directly from the SAN at very high speed. And they're able to reshare that over, say, gigabit ethernet to another 20. Now, I can tell you that BEAT's trying to reshare that data over gigabit ethernet to another 1,100. So this is a way of more easily or more quickly distributing the data around a computational cluster.

So I'm going to go through a few of our products here and run through some of that as soon as I get a-- Another drink of water here. I'll run through some of this and give you an idea of the kind of products that we're offering in this space. And then I want to give you an idea of why we think we can be very successful in this space, in both video, regular storage consolidation projects that I've shown you, and also in computational clustering, where price performance is really what counts. So Mac OS X Server, qualified with XSAN, delivers all sorts of great services. I'm sure most of you caught the earlier sessions on what the next version of the server is all about. We'll be qualifying Tiger Server with XSAN as well when Tiger Server is closer to availability. XServe G5, phenomenal performance in a one-use server, an amazing box, and I'm sure you've seen some of the sessions on that as well.

We do offer a fiber channel PCI card. Many of you may not have realized that. This is a PCI card that goes into an XSERV or into a Power Mac and delivers a dual port, 2 gigabits per second on each channel. So it's a really, really nice card. It's a 64-bit, 66 megahertz PCI card. Neat thing is we actually include the cables. And these cables on the street would be something like $150, $200 a piece, but we include the cables as part of the package for the PCI card. We have the XSERV RAID. This is a 3.5 terabyte solution in a 3U enclosure.

Again, very, very high speed. If you stripe across the channels, as it says, over 336 megabytes per second, striping across the two controllers, very easy to set up. This is RAID setup in three easy steps. Very, very nice solution. This one's actually qualified not only for Mac OS X, Windows, and Linux. And as we said, it'll be qualified for XSAN. And nice solution, $3 per gigabyte. I have this joke I have with-- just as a digression with the guy who runs our server and storage hardware. I said he should only have three slides on XSERV RAID. The first one should say $3 per gigabyte. The second one should say $3 per gigabyte. And the third one should say, did I mention $3 per gigabyte? It's a beautiful, beautiful box. And XSAN. And as I mentioned, XSAN, concurrent access, shared volumes up to 64 computers. Lot of great features in there from a high availability or HA standpoint. Gives you direct block level, high speed access over a fiber channel to the storage. Provides some really, really cool volume management capabilities. It comes with some great remote administration tools. And of course, we have great cross-platform support with full interoperability with the StoreNext file system from ADIC. So really, really complete solution there.

And we have some great server and store support options. And we got a lot of questions on this yesterday. And I just invite you to check out the latest offerings that we offer in that space. I do want to run you through the prices. The thing that's key here, and the reason I'm running through some of the marketing slides right now, is that a lot of people have said to us, look, we look at iSCSI, we look at Fiber Channel. We're not sure what's going to happen, but it sure looks like iSCSI is going to take over. And when we look at it, we say, well, first of all, you'll never be doing video over iSCSI. You're not in the foreseeable future. And in fact, it's very, very difficult to get any kind of high performance out of iSCSI. And when you do, you get into using really interesting proprietary hardware to do that. And that drives the expense way up. Most people want iSCSI because it's cheaper than Fibre Channel. That's the clear reason why they want that sort of thing. So we took a look at it. We feel that Fibre Channel is actually ripe for price reduction. And so we're going to change this market entirely. And so we're offering these products at an incredibly low price compared to anything else on the market. Yes, I know. So $999 for 10-server, unlimited client license, XSERV G5, $3,000. 10-server is included with that. The PCI card is $500 with the cables included. The XServe RAID, that $11,000 price is with everything you can put in it. Three and a half terabytes of storage, 128 megs of cash, etc., etc. And then XSAN, under $1,000 per node and unlimited capacity. So.

So as some of you know, that's easily, from a software standpoint, that's a fifth to a tenth of the price of comparable solutions on the market today. And that's no exaggeration. You can check it out with other vendors. It's a fifth to a tenth the price of comparable solutions. And many solutions actually charge you on the basis of the amount of storage that you put in place.

Many solutions charge you extra for the metadata controller software. All of that stuff is built into XSAN. So as I said, we're driving down the cost of this infrastructure. XSAN will be available in the fall of 2004. So we're going to have it out to you in the fall of 2004. XSAN is in beta today.

We made our first beta available at NAB. There is a program up on the site, apple.com slash XSAN, and there's a little link hidden over in the corner referring to the beta program. So you can go to apple.com slash xsand slash beta if you want to sign up for the beta program. Now, the great thing about this, in a sense, is we've had several hundred people already sign up for the program in the couple of months that we've been making it available. And I will tell you, if you want to be part of the program, this is why I'm fascinated that there's been that many people sign up. You have to have an XServe RAID. You have to have a qualified fiber channel switch. and you have to have two or more of either XServe G5s, XServe G4s, or PowerMac G5s, and you have to have our fiber channel PCI cards. So in reality, that's $30,000, $40,000 worth of gear that you have to take offline and use it for XSAN testing. Yet I really appreciate it. I know there's a lot of you out there in the audience today who are doing that with us, and we really, really appreciate it. If you are interested in doing that, go sign up at the website and we'll get you the bits. We are backlogged today in terms of requests. We've just been overwhelmed with them, but we really appreciate that.