Good afternoon. So my name's Doug Brooks. I'm a product manager for server hardware at Apple. And I'd like to talk to you a little bit today about deploying XServe. So XServe has had an exciting year. The product is just a little over one year old. We've had a major update to the product back in February and an addition of the compute node in March. And so I'd like to talk to you a little bit about deploying XServe. So before we dive right into XServe, we'd like to position a little bit about how XServe fits in a broader IT sense. And what's interesting is, you know, since we've launched the XServe and actually in our customer research before we launched XServe, we had an opportunity to talk to a wide range of customers and really help understand what some of their challenges are deploying servers. And there were a lot of constant themes that were shared with us. And things like operational costs continually under review. I mean, the old story of doing more with less or doing a lot more with a little bit more is a continual challenge. Availability of service, you know, the incredible speed and worldwide presence of the Internet has made time irrelevant, which means that, you know, opportunities for downtime are slim and few and in between. So availability of service in a variety of ways has been continually challenging and important.

Deployment time is shorter, so time to ramp up systems and get hardware installed and networking available and services up and running is needing to be done again in less and less time. Systems per administrator increasing. And I'm sure many of you relate to this. You're having more services, more servers, more physical boxes being deployed, and needing to manage more and more of those resources.

And server utilization is higher, having servers work more, do more, and be able to maintain that utilization rate, again, a continual challenge. So the big question becomes, well, what does Apple have to offer in this space, besides we think is a pretty neat one-U box? And so I think it's important to understand what we see as our value proposition in the IT market to address these specific issues. So from a cost perspective, we think we have a great offering from a hardware and software and software licensing perspective with low cost of hardware, low cost of storage, and unlimited client licenses built in.

And hopefully you've seen in some of the other sessions the ability to host more users at a much lower cost, have more storage available on your networks is a big value that Apple can deliver with our server products. From availability, well, you know, we designed these boxes from the ground up to be servers. And so that means reliability and availability both in hardware and software. And that's, you know, something that we strive with these products. Deployment time. You know, XServe is designed, and we'll talk more about it here, to be easy to deploy, easy to manage, and very easy to, you know, roll these systems out. And so, again, that is a key design goal that we build into these products to provide that.

And finally, server utilization. Our goal is here to provide power flexibility at a lower cost. So tremendous amount of services built in, tremendous amount of resources and the hardware to deliver upon these requirements. Thank you. So what are we going to talk about today? So quite a number of things.

First of all, I think it's important to answer the why XServe question. So we'll touch on that. Speeds and feeds. XServe has been around, so we're not going to spend an incredible amount of time about the hardware feature set. But I think it's important to provide a high level architectural review. What we really see are the server value features in XServe that we have to offer.

And of course then deployment. What things can we look at to make it easy to deploy these boxes both regarding physical hardware type issues and software type issues. And we'll have a number of things that we'll touch on there. And a very important -- get asked this a lot -- is backup strategies. So we'll touch on the latest and available backup strategies for Mac OS X and Mac OS X Server. And finally resources. where we can point you to for more information on all of these topics. So let's start with why XServe. So we fundamentally believe that XServe is the easiest way to deliver very powerful network services, been able to put a tremendous amount of technology into a 1U rack-mounted server form factor with incredible storage capability.

And one of the real advantages of XServe is the Mac OS X server software having a powerful open source foundation with very robust server services, and later on top of that, but with fantastic remote management capabilities, very core to the design. We think we've offered many of the same features that people love about Linux, open source, great system resources, but integrated all from one vendor, one place. So one-click install gets you all of those features built in, ready to go. And, again, powerful open standards-based services. Hopefully you've attended many of the IT tracks this week, and it's been a continual theme, open standards technologies built in, best of breed. And, finally, more capabilities at less cost, really trying to provide a very value-oriented platform with lots of services and capabilities.

So a quick review of the hardware. So XServe, again, was designed from the ground up to really be a phenomenal server platform. This was not a G4 tower stuck on its side in a smaller enclosure. It really optimized this platform to be a phenomenal server platform. So that means a couple different things.

So first of all, it's a rack-mounted form factor. So being able to fit in industry-standard racks. I like to joke it's an industry-standard rack. It's not the 20-inch wide Apple special rack. Industry standard rack, one-use server, that does mean 1.75 inches, not two. So, you know, industry standard, be able to fit that in with existing network gear, existing server gear right in your data center environment.

But, you know, look at the hardware. We've packed a tremendous amount of technology in a very small amount of space. So single and dual G4 processors, dual gigabit Ethernet, each on their own PCI interface for bandwidth and throughput. Four hot plug hard drives using a hot plug architecture that's based on ATA hard drives, which is interesting. When we first launched XSERV, a lot of people asked questions about, however, now, you know, because so much in the industry is beginning to utilize ATA hard drives in this space, not nearly questioned as much, and we think we have a great proposition with performance and storage capability with the storage architecture in XServe. Thank you. And of course, PCI expandability. Two 12-inch PCI slots, 6466, delivering very high performance, especially when connected to external devices like our own XSERV RAID, really leveraging the PCI performance of XSERV.

What I really wanted to highlight, though, is the architecture of XServe because, again, this is really optimized, you know, to be a server. And what that gives us, what it really means is a lot of storage bandwidth and a lot of networking bandwidth. And so being able to offer features like dual gigabit Ethernet, again, each on their own PCI interface, which gives us the ability to really keep those channels moving data very efficiently without them competing for bandwidth on the system. And the storage architecture, again, on its own PCI bus, very high-speed PCI bus, each hard drive has its own independent ATA controller, so quad-independent ATA controllers. What that gives us is tremendous scalability as we add storage. When we add additional hard drives to the XSERV, not only are we adding raw capacity to the system, we're adding more storage bandwidth in the system. So especially when we look at high-bandwidth applications where we're striping drives together, very strong scalability of storage in the box. And of course the ability to go external to again to devices like our XServe RAID for additional storage capacity. Thank you.

And of course, we put this in what we think is a real phenomenal rack-mounted enclosure. So again, designed for ease of access. XSERV slides out on rails, so that right within the rack it slides open. You have access to all the key components. Everything's on thumb screws or standoffs for quick and easy repairability. Any component can be swapped in roughly a minute.

So a very serviceable design. We couple that with unique programs like our AppleCare Spares Parts program, where you can have spare kits right on site. So should you have any component problems, they can be swapped out in site very quickly and easily. A lot of flexibility, and we'll talk more about the rack mounting options that we have with XSERV.

The other real key thing that many people overlook when we first look at XServe is the dedicated hardware monitoring that's built into the system. Again, being a rack mounted server platform, these things are designed to live in a data center, live in a rack. You shouldn't have to as a system administrator spend your time physically in front of the machine. We want to minimize that as much as possible. That means being able to provide health and status information about the server at all times. So we actually have hardware built in on the logic board of the XSERV that is pulling data about the entire system and delivering that to our remote management tools.

So we're monitoring things like the voltages coming off the power supplies of each rail, the speed of the blowers, temperature in two different locations of the box, status and throughput of the Ethernet interfaces, status and health of the hard drive modules. As a matter of fact, we're doing things like reading the smart data off the hard drives, been able to do, look for performance and health data, and look for what are called pre-failure analysis, looking for things that are indicating future problems.

We then wrap that data all up into our server monitor management tool, which has the ability to perform e-mail notifications and things like that. So our server monitor tool is a Cocoa application that can monitor one or more XSERVs in a single interface. You can see several servers being monitored here. You have status indicators for all the key components. So green lights are good for all the key components. Yellow is a warning condition. Red is an error condition. and you can drill into any of those components with one click to get detailed information. If you want to know the exact temperature of the top unit in your rack, very easy to do that. What's really interesting about this tool is that the data, hopefully some of you had the opportunity to go to some of the Mac OS X server sessions where they talked about the management protocol. We use the same architecture with Server Monitor. This application is actually just reading XML data and presenting it to you in a GUI interface. But that XML data is available on the system. We've actually had customers be able to extract that data and use that in their own monitoring tools. And so that's been very handy from that perspective, looking for more automated, you know, scriptable analysis of this information.

So just a review of the major XServe configurations to highlight the new compute node. We actually currently offer three configurations of our XServe. So the first two are our, you know, quote-unquote server configuration, single and dual processor, you know, single hard drive up to 720 gigabytes of internal storage, CD-ROM, VGA standard, and, of course, Mac OS X server and limited client license. To highlight, the new compute node that we introduced in the March time frame is a machine specifically optimized for compute-intensive tasks. This is primarily in response to customer requests for an XSERV streamlined for things like compute clustering.

And again, if you were in the compute clustering session, you saw some of those units in a demo up on stage. So this machine is streamlined for that. Two processors, single hard drive, single gigabit Ethernet, the onboard Ethernet, no CD-ROM because you don't want one of those in every single unit and also much lower price than the standard dual processor configuration. What's interesting about this unit is while we targeted it for compute clustering tasks, it's also been very popular in any kind of computational intense application. It's been very popular for things like web application servers where you don't need a lot of storage on the node. It's getting data from external databases or things, and so it's been very interesting in those kind of deployments as well.

And of course, just to touch on it, again, you've heard a lot about Mac OS X Server in the various sessions this week, but what really wraps up XServe in an incredible package is the Mac OS X Server software. And so actually in this session, everything I'm going to be talking about is focused on the currently shipping Mac OS X Server software, Jaguar Server. I'll touch at the very end on some features that benefit XServe deployments from the Panther Server at the very end.

But again, with XSERV, Mac OS X server unlimited client license in the server configurations with a wealth of services built right in, ready to be deployed right out of the box. Incredible package. So what I really wanted to get into now in more depth is the deployment issues. And I have a variety of topics from rack and power and networking out to software installations, high availability with IP failover backup, And also a few pointers on key command line tools that I found system administrators might not know about that are very essential. If you're not familiar with some of the special tools that we provide, I just wanted to highlight those for you at the end. So I wanted to start off with racks. Since XServe is a rack-mounted server, one of the first requirements is that you have a rack somewhere to put this in. And so while every now and then we find an XServe out on a table, we kind of shy away from that. It's not designed for things like stacking on top of it or monitors on top of it. We highly discourage that kind of deployment. This thing is built for racks and we have quite a number of flexible rack deployments. XServe can support both two-post and four-post racks. And so two-post is really handy. We see this a lot in environments that have a lot of networking gear already installed and can install the XServe in an existing two-post It's a center mount bracket that mounts on the side of the box. It's kind of cantilever mounted in the unit. I want to stress, though, and this will come up in a minute, is that if you ever plan on mounting an XSERV RAID with XSERV, we really recommend you go right out and get the four-post rack, and I'll touch on that again in a minute. From a four-post rack perspective, one of the key things to understand about XSERV is the depth requirements. Again, we've packed a tremendous amount of technology into a 1U form factor, And it's a 28-inch deep unit, and we recommend it be installed in a rack that's 30 inches deep or more. The actual brackets support up to 36 inches of rack depth right out of the box with no additional brackets. But that 30-inch depth is a standard server depth, and we really recommend you look at racks that meet those requirements. It's a much cleaner, easier installation and gives you the best environment. Now, with the slot-loading XSERV, we did add, based on customer requests, some additional short brackets that give you the ability to mount XSERV at 24, 26 inches deep. This was a big request for people who had existing AV racks, typically with audio and video gear, that were shorter. And so now with the slot-load XSERV, we have the ability to mount that. It mounts very nicely. The issue there that you just have to understand is that we don't get any shorter with that. So you still have about two inches hanging out the back on a 26-inch rack. So if that's appropriate, you can configure that in that standard rack, and that works great. Just to highlight that we include in the box all the various mounting hardware, English and metric threads. And one of the things that we did based on customer requests with the slot load XServe is we included the cage nuts that get mounted into the square hole rack so that you have everything you need. right in the box.

So a couple suggestions and recommendations based on feedback and experience. First and foremost, just a reminder, XRV-RAID, being a little bigger unit, a little heavier unit, is designed exclusively for four-post racks. It has quite an extensive mounting range, but it's important that it gets put into a four-post rack. And so if you're planning on adding one or deploying them together, start there. Very important. Little suggestion, people are deploying several of these, bottom up works better than top down. I like to suggest letting gravity do some work for you. It's real important to get the units in nice and squarely and if you let gravity just take care of the positioning for you, they stack up very nicely. Plus once you get the first one in, the rest go in quite easily. So a little suggestion there. With the Slotload XServe, we also provided an installation template. It's actually a metal bar with some holes in it. We highly recommend you use this for your final installation of the lid in the unit. What happens is you place this onto, when you attach the lid into the rack, you place the bracket on and you use that as you tighten the screws into the rack. What happens is because the lid is what you actually mount in the rack, if you over-tighten When they're under tightened, the screws, the lid can be slightly deformed in or out making it very difficult to get the XServe in. Sometimes it can be actually a little loose and there can be too much play in the rails. This bracket was designed to make sure everything's perfect. With that bracket being used, tighten the screws in and the unit slides right in just perfectly. That is a little suggestion that we've added with the new Slotload XServe. the little thing is that with the Slotload XServe, we've added a CD protector bracket to the Slotload CD bay. We really recommend you keep that protector on during the entire installation process.

I know a lot of the first things people want to do is pull it off and look at the fascia of the unit, but it's best if that be left on. It prevents any deformation in the fascia on where the sleety goes into the machine. If it's torqued in that unit. It's cosmetic. It doesn't affect the CD going in or out, but we like to make them look as nice as possible in the rack, and so that protector provides that strength during installation.

So I'm going to talk a little bit about power and environmental requirements. We have a nice advantage with the PowerPC G4 processor in that the power requirements and heat output compared to other competing processors in the 1U form factor tend to be much lower, and so I wanted to highlight that for you here. The power supply is actually rated for the worst possible condition with an XSERV. So we actually rate the power supply at 3.6 amps, 345 watts.

That includes margin on top of that. In reality, it's pretty challenging to, on a single processor system, to use more than about 200 watts in the system for most typical configurations. And in the dual processor, pretty challenging to use more than 350 watts. So this provides some additional guidelines when you're actually planning, for example, UPS deployment on the loads that are needed. We actually document specific configurations and power and thermal output requirements in our knowledge base. So there's actually -- if you go into the KBase, kbase.info.apple.com, search on XSERV and BTU, you'll find these specs actually fleshed out in a lot more detail. We do several different kinds of configurations and give you that as examples for power and heat output. And that gives you some scaling guidelines there based on room requirements. Obviously one of the challenges is that when you have a lot of these in a small space, you want to make sure that the room stays within operational temperatures to prevent overheating. Now, we do have system monitors tracking temperatures, and you will get alerts if the systems get too warm, but proper environmentals is important for any kind of server environment.

So just what does this translate into UPS loads? Wanted to give you some examples. These are two common APC UPSs, a 1U-1000 UPS, ideal for one or two XSERVs, and then a bigger APC 3U-3000 UPS that can handle several XSERVs. So just to give you some guidelines, the single 1UX UPS give you 30 minutes of power to a typical configured XSERV. That would be a dual processor XServe. And around 15 minutes of kind of the worst case scenario, fully loaded, fully maxed out XServe. For comparison, the bigger APC UPS for X6 XSERVs of typical configuration will give you around 15 minutes of power. And for a fully loaded worst case scenario, around five minutes of power. So still plenty of time to do proper shutdown procedures. Worth noting also that APC has software to connect these UPSs for proper shutdown behavior.

Networking. So, you know, networking is critical in a server environment, and of course that's one of the main reasons why we provided dual gigabit Ethernet out of the back of the machine. So XSERV standard configurations come with dual gigabit Ethernet, one built in on the logic board and one in our AGP PCI combo slot. So one of the big advantages of the XSERV in that configuration is that we have this combo slot. It's really our third PCI slot, And this can take either a 4X high performance AGP video card or the way we configure it for standard server configurations is a PCI Ethernet card.

And so that gives you a second high performance copper interconnect for gigabit Ethernet. The PCI Ethernet card actually is a slightly superior card from a performance standpoint. We found it to be about 10 to 15 percent in performance greater than the onboard Ethernet. And what's interesting is that that is the actual Ethernet card we used in some of the benchmarking. For example, that set the web bench record that we did when we benchmarked the slot load XSERVs. So, very strong performance in that Ethernet card, and we tend to recommend people use that as their primary interface for serving clients.

A little note, though, our remote setup software, and we'll talk more about that in a minute, prefers or expects to use built-in Ethernet. Okay, so we recommend what you do is use the built-in Ethernet to bring the system up and configure it and use the PCI Ethernet as your primary interface for your services.

Now, we've got a lot of questions about people looking for optical cards who want to connect optical gigabit Ethernet to the system. And there are actually several third-party solutions. Apple doesn't offer a card off of our store, but there are several key third-party solutions in this space to provide that solution. Asante has probably the most popular card, the 1000SX Giganix card, and just recently discovered a vendor who has Mac OS X drivers. 3M has a line of optical cards called Volition that have Mac OS X drivers. And so that has two optical gigabit Ethernet solutions.

And finally, I get asked this a lot, with the slot loading XServe, the software that we ship, Mac OS X server 1024, had a new feature in it called IP over FireWire. And so when you added that to your XServe, a new EN2 would often show up in the system preferences paying for Ethernet. And that's actually IP over FireWire. Matter of fact, in Panther server it actually will show up named IP over FireWire to make it a little more obvious what that is. Had a lot of people wonder did their server suddenly grow a new Ethernet interface.

So this is really exciting. IP over FireWire, especially on the slot loading XServe with having dual 800 megabit FireWire on the back. We can use this as an IP interface. Matter of fact, we can chain down the rack with very inexpensive FireWire 9-pin to 9-pin cables and connect a bunch of Xers over IP over FireWire. This gives us an ideal third interface for things like management, replications, and IP failover. We'll actually talk about its use in IP failover in a little bit. It's a -- you know, think of it as a built-in interface that you can now very easily use for those environments, and it's very handy for that. It delivers very good performance and, you know, just works like an Ethernet interface from that perspective. You know, one of the benefits here is that it lets you keep your high performance copper gigabit Ethernet ports available to serve clients on your network and use this as a back channel for management and things like that.

One thing I did want to mention with IP over FireWire is that when you have those machines connected together, you want to be very careful about plugging other devices in. So one of the things, the challenge is that now that those machines are connected together, their FireWire bus is now shared across those machines. And one of the great things about XServe is we have a FireWire port on the front. I like to brag with our friends in Power Mac, we were the first ones to put the FireWire on the front of the machine. So you put that iPod in and plug it into the front, you actually have all the machines that are connected with that FireWire bus will see it concurrently. And so it could actually mount on several machines which would be less than desirable. So just something to be considering when you are using IP over FireWire to be very careful plugging in additional devices, non-IP over FireWire type devices into that FireWire bus because it is a shared bus.

SNMP, one of the features that XServe introduced in Mac OS X Server, actually with the original XServe with 10.1.5 is SNMP capability. And this has been built in since then and is a great capability. Really wanted to call out and highlight because we have a lot of customers in heterogeneous environments who want to take advantage of SNMP monitoring and plug it in into tools like OpenView or Intermapper or some of the NEON tools that we bundle on on the slot load X serve. And this is built in, and the only challenge is that it's deactivated by default.

And so to turn it on, you actually have to add one line into etsy host config and just say SNMP server equals yes. And that will activate the SNMP stack, and it will start up automatically from then on out. It's worth noting that in Jaguar, SNMP server equals no is not in the default script.

You actually have to add it as a new line. A lot of people look, can I just change no to yes? It's actually not in the host config script. You have to go in and add it. And then, of course, highly recommend you run the SNMP conf tool, which actually allows you to plug in system-specific information, you know, host name, contact information, email address, all the things so that when you connect to it over SNMP, you get some meaningful information beyond network statistics and other valuable information that SNMP provides back.

If you're not familiar with SNMP or configuring it, There are great man pages built in. Our implementation of SNMP is actually based on NetSNMP, and so there's a great resource, of course, the NetSNMP web page that I'd point you to for more information about specifics about the MIBs and configuration above and beyond what we provide in the man pages. Thank you.

I wanted to talk now about software installation. One of the great things about Mac OS X Server on XServe is we have a variety of ways to configure the machines and have, because of the headless nature of rack-mounted servers, have a lot of new tools that we've built for XServe and other environments to make it easy to deploy these machines in the rack. Our goal is that if you want to hook up a monitor and keyboard to an XServe, great, go ahead. should work just like you would expect, but we want to make it really easy to take this XServe brand new out of the box, rack it, power it up, and just configure it remotely, never ever having to connect a monitor and keyboard and make that a really great user experience. And we think we've done that, so I wanted to highlight the various methods of configuring the software on XServe.

Before I get into that, I wanted to highlight a new feature that was in the slot load XServe that we introduced with the slot load XServe, which we call our front panel boot menu. On the original XServe, the system identifier button, the button with the triangle on it, when you powered up the machine and held that button, it was like holding down the C key on your keyboard. It forced the machine to boot off the CD-ROM, and that was great for the same kind of operations. But what we found out is that a lot of people wanted to do some of the other things that you could do. with what we call the snag keys or the special keys on the keyboard. And so we've actually added more features in the new slot load XServe to provide this. And what we've actually implemented is by using the light show, the two rows of eight blue LEDs and the button on the front is implemented a very simple boot menu on the XServe. So what you do is when you power up the machine, you hold down that same system identifier button for a couple seconds, and what it will do is it will actually flash. and you'll get a single blue LED that will count out across the eight LEDs. And now when you press the system identifier button, it will indicate those LEDs from one to eight from the right to the left. That is how you count that. And each LED then has a special meaning. And when you've selected the number LED that you're looking for, you then hold down the system identifier button for a few seconds. You'll see the indicator count up and down, and when you release it, it will go ahead and follow that action. And so what we have now is seven commands that can be implemented right on the front of the XR without any additional keyboard or other interaction. Obviously, the first one is boot from CD. So you press that. If there's a CD in the drive, it will eject it very handy. And when you put a CD in, it will now attempt to boot from that CD if it's a bootable CD. The second one is like holding down the N key. It's the net boot command. Net boot, and we'll touch on this a little bit, net boot is a great way to mass deploy servers. You can use it for network configuration, have it image the machine automatically, or in cluster environments, you might choose to net boot the entire cluster for a single system image. So you can do net boot right from the front of the machine. Again, no keyboard needed.

The third light indicates boot from the internal hard drive. And so what it will do is it will start in bay one, which is the leftmost hard drive, and attempt to boot from that, and then try to boot from drive two, three, and four. So it will basically search the internal drive base for a viable boot hard drive.

If you select option number four, it will actually attempt to boot from a device other than the built-in device that you've already chosen previously. So if you want to actually troubleshoot your built-in system boot drive and you want to instead boot off an iPod or a FireWire drive or something, you can select this option. It will scan and boot from the first available device that it finds. It's also worth noting, because I don't think I mentioned it elsewhere in the slides, you can actually boot off of our XServe RAID, and we actually have people who are doing that. So very handy to be able to boot off a fiber channel.

Option number five, it turns the XServe into target disk mode. Now, this is extremely, extremely powerful. We'll talk more about this in a second. With target disk mode, it basically turns the XServe temporarily into a FireWire hard drive. And you can plug that into your PowerBook and mount those hard drives right over FireWire like it was a little FireWire hard drive.

What's unique about the implementation on XServe is that we've actually allowed it to mount all four hard drive bays. Okay, so you can have four hard drive bays, and rather than just showing drive zero, or bay one, I should say, it will mount all the available drives out through FireWire.

Option number six, of course, is the zap the PRAM magic command. And finally, option number seven is the equivalent of booting into open firmware. This is very powerful for people who want to kind of get under the hood and give very specific commands to the firmware. We've also added some intelligence to this. If you don't have a keyboard plugged in, it automatically activates the serial port on the back as a console. So you can go right in through the serial port, tell it to boot off of a specific device or do specific troubleshooting. that you might want to do at the open firmware level, which is fortunately very, very rare, but when you want to do it, it's very easy to activate that.

So I wanted to highlight that because we'll use that in context to some of these examples. So, you know, I want to take the first and easiest implementation of deploying XR software, which is the easy plug-in-the-keyboard-and-mouse method. And, you know, this is, you know, works just like you would expect.

You know, plug it in, boot from the CD, install it, off you go, just like you would any other machine. Very simple, very straightforward when you have the ability to have a keyboard and mouse handy to be plugged in. What's also interesting about this approach is using the target disk mode function, we can install using the XServe really like it was a target hard drive. So this is really great. You can take your PowerBook, turn your XServe into a hard drive, plug it in, install from your PowerBook onto the XServe like it was a boot drive, and actually install Mac OS X through that method using your PowerBook or other FireWire capable Macintosh system as your screen and keyboard and actually host processor at that time. So a very, very easy way to deploy and reimage and manipulate the software on your XServe. It's also really handy in the rack because what you can do is you can take one configured XServe, mount a second XServe in the rack with a short little FireWire cable on the rack using the front mounted FireWire ports and just move data from one XServe to the over FireWire target disk mode. It actually, you know, you can clone one machine configuration to another over FireWire rather trivially with FireWire target disk mode. So this is a really handy feature you can use in these environments.

The next thing I wanted to talk about is remote configuration user server assistant. This was a specific feature we added to support headless installation of the software for XServe but yet provide a really simplified and powerful user experience. So it still provides a graphical user interface. The way this works is that you, again, using the front panel mode can boot the system from the install CD that comes with XServe. You boot that up. And if you've ever wondered why it takes a little bit longer to boot Mac OS X server CDs on the XServe, it's because it's creating this remote hosting capability.

What it's actually doing is booting the environment, creating -- making networking available. And then what you do is run a utility called server assistant that you run on a remote host, PowerBook, for example, that's plugged into the network on the same subnet. You find that XServe remotely using a rendezvous type technology and then configure the system through the same server assistant you would see as if you were on the machine locally. To give you an idea what this looks like, what you do is this is from a client machine you run on your PowerBook, the server assistant, and it comes up and asks you what you want to do. configure a remote machine or install a server or reinstall the server software so you can actually do a complete reinstallation in a headless environment. So in this case we'll reinstall or install Mac OS X server software. It will then scan your local subnet using, again, the same protocol as Rendezvous, looking for machines on that subnet. And it will list their current IP address, their MAC address, so you can validate the exact hardware port that you're talking to what it thinks its host name is. And these will -- you refresh, you might see one, you might see a dozen servers, depending on how many are in configuration mode. And I'm going to stress that this is only available when it's in this booted configuration mode. This isn't something that you can connect to to an XServe at any time, obviously for security reasons. You don't want to make it easy for anyone to reinstall your server software. So once you find this machine that you're looking for, you click on it, continue, and will prompt you for a password. And because the machine is in a remote configuration mode, the machine could be in an unknown state. What we've decided to use as the authentication is actually the hardware serial number of the machine.

So we actually use the first eight digits of the hardware serial number, and that's actually why we put the serial number on the back of the machine and on the front inside of the machine. If you just slide open the X server about two inches, you'll see a little printed serial number tag on the inside of the machine as as well as on the back, making it very easy to get access to that information. So you enter the first eight digits of the serial number to authenticate.

It will continue, and you then continue through the assistant just like you would locally, you know, language, boot device, option packs you want installed, ask you for your IP address, all the questions you would answer normally now are being done remotely. It's sending those remote commands over to the machine in an encrypted fashion, basically using an SSH type encrypted communication session. The machine will configure itself, reboot, and then it's in exactly a known state that you can log into as the administrator with server administration tools and configure your services from there on out. So very, very powerful and simple user interface to do this remote server assistant mode.

The other approach I wanted to talk about briefly is network install. So one of the abilities you have to do, and this is really handy when you're deploying a large number of XSERVs in a given environment, is to use the network install capabilities that's built into Mac OS X server.

So basically using a server as kind of a hosting server that can host and install environment for other machines on the network. So you can create a disk image using the network image utility that's in 10.2 Server. We highly recommend if you're doing a server install that you use version 10.2.5 or later, the network image utility that ships with 10.2.5 or later. Note that the system software that you're installing on the machine doesn't have to be necessarily at that revision, but the utility that creates the disk image needs to be. actually some specific server things that were addressed in 10.2.5 version.

So what it will do is when you run this utility, it will actually ask you for the server software CD, you place that in the machine, and off you go to create that image. You then can net boot that off, and it's just like booting from CD and have that administration capability. So here's a look at the actual utility itself, being able to create an install image. It will create that image, and off you go. You can make that your net boot network image that's available.

The last thing I wanted to talk about is probably one of the most powerful tools for XServe deployment, which is a command line tool called ASR. This is a tool that allows you to basically take an image of a server that can be completely configured and blast it onto other machines. It's very fast, very efficient, and can be very flexible in the way you use this machine. So you literally can take a known boot image, slap it in one bay of an XServe, take a blank drive in the other bay of the image, pull up terminal, type in ASR, you know, target source volume, target volume, some optional flags depending on if you want to use them, verbose options and erasable options are highly recommended. And off you go. It will clone that drive that's now perfectly bootable drive. You can stick in another XSERV and bring up in a completely known environment.

Now, what's really amazing about ASR is that you have the ability to host these disk images that become the image that you're blasting onto a server from a web server. So imagine this. You can create a pristine image of every server, type of server that you have in your environment. This is the web server. This is the DNS server. This is the file server. Create a disk image of it, whether it be for backup or for replication purposes. Put that image up on a web server.

And using the HTTP URL to that disk image as the source image blasts that from a web server onto a hard drive. Very, very amazing capability, very fast, very The other thing I wanted to mention is that there are actually some unique third-party products coming that help this environment. This is a prototype of a product that a company called Extreme Mac is working on and will be shipping shortly. This is an Apple Drive module device that has FireWire on the back. So you'll be able to take this device, plug it into a PowerBook, a PowerMac, and read and write to Apple Drive modules for configuration, take this out, stick it in an XServe, and a very easy way to deploy images and software onto an XServe drive from another host machine. So look forward to products like that providing new options for you as well.

So one of the other things I wanted to talk about, kind of moving topics here, is availability. So Mac OS X Server has a unique architecture in 10.2 Server called IP Failover that provides a way to have two servers kind of provide a master/slave failover environment for availability. This is built into a Jaguar server. It requires an IP connection be connected between a private IP connection between two servers for use as a heartbeat.

So what happens is we have two servers on a common private network that are passing a heartbeat between the two of them saying, you know, I'm alive, are you alive? And this is ideal for using IP over FireWire. Again, a small FireWire cable between two servers with IP over FireWire gives you the perfect connection for this kind of environment. It has the ability to fail over. So one server goes out, the other machine takes over and then fail back. So when the other machine comes back up, have it resolve its services back. And this is ideal out of the box for static services. Things like QuickTime streaming, web services, where the data behind the service doesn't change on a frequent basis. Because very important, it in and of itself does not replicate data, and we'll talk about strategies for that in a minute. So I just wanted to give you a graphical environment of what this looks like. So we have two servers, and what's important about this is that the secondary server doesn't have to be a server just sitting idle doing nothing that just is waiting for the primary server to fail. Both servers can be actively serving other services. And what we have here are machines that have a minimum of two Ethernet interfaces, or IP over FireWire. Each one has its own unique public interface and public IP address. Here the primary server is 1001.1, and the secondary server is 1001.2. And then they have a private interface. Again, this could be Ethernet or IP over FireWire that they use to communicate privately between them for heartbeat information. In this case, it's the 192 addresses,.1 and.2. And so these machines are sending, again, live messages between the two machines. Now, let's get into a situation where the primary server, for any number of reasons, dies, whether it be the network link or hardware failure, the machine then would stop sending heartbeat messages to the secondary server.

At that point, the secondary server using the IP failover ability would kick off a series of scripts that would determine the specific actions that would happen. In this case, you know, our primary server is a Web server, our secondary is a streaming server. What we might choose to do here is fire up the Web server on the secondary server. And what it will do is it will add -- it will take over the IP address of the primary server, becoming its presence on the network. So in this case, we're keeping both services alive, both web services and streaming services, and because the IP address is assigned to those, continue to be alive, the clients out on the network would see no loss in services.

Those -- because this is completely script-driven, though, you have the ability to tune the exact behavior. You might decide the Web service is of high transactional ability and decide that you really need to kill off the streaming server or maybe just nice it down to a much lower priority because these are all scripts that determine this behavior. You have that ability to determine that exact behavior.

Now, as I mentioned, IP failover does not replicate data, okay? So obviously the service needs to be able to fire up and run that service in the proper configuration. So you need to have data staged there and configuration files staged there for the situations when those get fired off. And obviously you can use tools like rsync as just one example to replicate that data between the two services. So this can be very powerful for the services.

Obviously this architecture is not ideal for things like file services that have heavy data requirements behind it. You can imagine if it's my home directory server and I fail over to a secondary server, if my home directory isn't there, it's not good to me that the server is still available. It's the data behind it that's important. So this is really ideal for things like web services and streaming services as two examples.

Again, I want to stress that these are script driven, so you have complete flexibility over the exact behaviors of what happens. We actually provide sample scripts which you then can customize and tune to your specific environment. It also has the ability to send email notifications and things like that so that you know when you're in this kind of situation. The other thing I didn't go into in much detail, but there are also corresponding scripts that determine what happens when the primary server comes back up. So we fail back and bring the original services up as expected.

I also want to stress that for availability, IP failover isn't the only strategy. Many applications have their own architecture for IP failover or for high availability, really, and that's the best way to handle availability because you can determine that on an application-specific basis. Some examples are Stalkers CommuniGate have an excellent two-node clustered version that provides a high availability mail server. And again, having application level awareness is much better than a generic service and that's an excellent solution for those environments. - Yes.

IP failover also isn't the only way to achieve availability. Using external load balancers for things like multiple web servers that can take a server out of the loop when a server fails is also another option. And I also wanted to mention a new third-party option from a fiber channel storage perspective. You know, one of the questions I get asked a lot is, well, if we could put our storage out on, say, an XServe RAID, external storage device, could we have that storage move over to the second server so that my home directories do follow me if I fail over to a secondary server? Obviously this requires the ability to map the storage from one machine to another. And while we don't provide that functionality out of the box, a company called Astera has some new drivers for their fiber channel cards that have scriptable capabilities to do this.

So this is brand new. I haven't tested it yet, but it looks like a promising solution that could really complement a IP failover configuration. Thank you. I also just wanted to finish by talking about backup. Backup is a continual challenge given the huge quantities of data we're able to host, given the turnover of data, how much data turns on a regular basis, and the reality that the time we have to backup is continually shrinking. The other reality is that RAID, while very critical from a server deployment perspective, provide data availability in and of itself is not a backup solution.

So first of all, update on the latest options available for backing up on Mac OS X server. So first and foremost, Dance Retrospex product continues to have both client and server solutions for Mac OS X. So that product continues to be available. We have clients for a number of enterprise backup solutions.

Eureka, Legato, Pterodactyl, Tivoli, Veritas, some examples. So while we can't be the backup engine, we can be a client to an existing and enterprise backup solution. And the reality is if you're deploying an XServe into an existing heterogeneous environment, it's very likely you already have one of these out there already and so can plug into those environments. And finally, one of the most recent additions to the backup space for Mac OS X is a third-party product from the TOLUS group called BRU. So this product is interesting from a number of perspectives. First of all, it's one of the first backup engines available on Mac OS X that can backup on multiple tape drives concurrently. So it can drive multiple tape heads. When you need to backup a large amount of data fast, multiple tape heads is one of the only way you can achieve that. It can drive very large tape libraries. It's driver agnostic. So it's been able to plug in just about every tape backup device I've seen so far. And it can backup over any available I/O channel, whether it be entry level USB or FireWire devices, SCSI changers or rather uniquely backup over fiber channel. So some of the higher end backup solutions are actually connected over fiber channel. This is particularly interesting because you can get the backup data movement off of your Ethernet network and use the bandwidth available on fiber channel. So this is a really excellent solution. The other big trend that we're seeing is disk-to-disk backup. Given the data turn on a regular basis and the quantities of data, it's really hard for tape to keep up. And so we're seeing more and more customers deploy XServe and XServe RAID as backup solutions. And there are a number of ways you can do this, a number of software techniques. But basically for the low cost of storage available with XServe and XServe RAID, you know, use an XServe RAID as a backup target going disk to disk. And whether it be multiple servers backing up over gigabit Ethernet to a backup repository or going over fiber channel as a secondary, even off site, one of the benefits of fiber channels, we can go hundreds of meters, even kilometers out over optical fiber channel for off site replication on a second XSERV So this is a really growing trend, and for large databases, large data sets, this is a very viable way to do backup. So just to finish up, the last thing I wanted to highlight were some what I'll consider essential commands from a command line perspective that can complement an XR deployment scenario.

I get asked all the time, you know, I'm coming from another Unix platform, and if config doesn't always work the way I expect it to on Mac OS X, or how do I do this command on Mac OS X? I wanted to really highlight some of the commands that are unique to Mac OS X but give you very powerful capabilities. First of all, there's two very powerful system configuration tools, the most important being network setup. Everything you can do in the network preference pane in Mac OS X you can do through scripting or through command line in network setup.

You can turn on and off interfaces, reorder them, set them to DHCP, set them to static IP addresses, get what current values are set, a very, very powerful tool. So rather than ifconfig, make sure you look up the man page for network setup. And actually if you just type network setup at the command line, it will spit back all of its options. We have a similar tool called system setup that gives you access to a lot of the preference type information, system name, date and time, network time server, on and on and on.

System management tools, one of the ones I find most valuable are the Disk Utility command. Disk Utility is the command line equivalent of Disk Utility.app. It lets you do things like create RAID sets, destroy RAID sets, rebuild RAID sets, partition disks, format disks. Very, very handy for configuration. Also great because you can script this very powerfully and so completely automate a specific setup requirement. We have a number of tools for things like directory services, DS import/export to be able to batch import users in and out. Create home directory. Until you log in from the GUI, your home directory isn't created. And so you can force it to be created using this command line option. Obviously the SNMP configuration tool and disk to base monitor is a background daemon that will monitor disk utilization on the server, and if you do a man on that command, you can see it has some very powerful capabilities for learning you about disk operations.

Finally, software update, command line software update to be able to, from SSH, update to the latest versions of software through software update. Disk Key Finder is an interesting little utility. It's a utility that will return the bay number of the drive in your XSERV. So if you ever want to configure from a path name into a bay 1, bay 2, bay 3, bay 4, this little utility will do that. Very handy for scripts. And, of course, there's a command line installer to be able to install packages of the command line. And finally, the ASR command we referenced So just to wrap up this session, we're running very close out of time here.

The reality is that with IT being faced with continual challenges, being able to deploy machines and services, we really feel that with XServe and Mac OS X Server and XServe RAID we can simplify server deployment, provide faster services at lower costs with much easier system administration experience. Now, there's been a lot of talk about Panther over the course of this week. I really just wanted to highlight a few quick features that are unique, we think will be very handy for XServe deployments. A number of unique features. One of the most important ones being the automatic setup feature. So we can take the setup experience and automate it even further than what we've talked about today.

Finally, just to wrap up, I wanted to point you to some other sessions. Many of these were done earlier in the week, so if you weren't able to attend them, I encourage you to watch the videos when they're available. Highlight the Deploying XServe RAID session. That's tomorrow afternoon. Talk more in depth about the storage side of our server products. Thank you.

Also wanted to highlight some of the developer and Core OS applications that I think are important from a system administrator side. Again, a lot of these -- actually all of these happened earlier this week, but again, video opportunities for replay. And finally, an invitation. Welcome feedback, questions and comments. And my e-mail address is here, d.brooks. Always welcome your feedback on XServe and your particular deployments and scenarios. Finally, from a developer perspective, Skip Levins is our server technology evangelist. And his email is up there from a developer side with specific development level questions and resources.

Finally, some key references. We have put a tremendous amount of effort into putting more resources available on the XServe and server web pages. We have a lot of resources there, and we'll continue to grow those over time. Have apple.com/server as kind of the one-stop shopping point for that location. A very, very valuable mailing list that Apple hosts on our list serves is the Mac OS X server mailing list.