Take Control of OS X Server, Chapter 2: Choosing Server Hardware
This article is a pre-release chapter in the upcoming “Take Control of OS X Server,” by Charles Edge, scheduled for public release later in 2014. Apart from Chapter 1: Introducing OS X Server, and Chapter 2: Choosing Server Hardware, these chapters are available only to TidBITS members; see “Take Control of OS X Server” Streaming in TidBITS for details.
Choosing Server Hardware
Perhaps the hardest part of OS X Server is getting started. What computer should you use for your server? How much RAM and storage space should it have?
As the carpenter’s saying goes, “Measure twice, cut once.” Rarely is this more true than when planning to deploy a server. The more people who will access the shared resources of the server, the more the saying applies.
There are three main areas to consider: Storage, Server Resources (such as CPU and RAM), and Bandwidth. Plus, how you configure your server depends on what types of services you’ll be hosting, how many of them you plan to run, and how many users will be connecting.
For instance, file servers typically need more storage and bandwidth. Web and database servers typically need more CPU and RAM. Servers managing network services such as Open Directory, DHCP, and DNS are often not taxed at all, so it would be better to have redundant servers than to pour additional resources into a single server.
File sizes are growing astronomically. For file servers and backup servers, you really can’t purchase enough storage, and that is especially true if you’re storing video. There are two elements to consider when it comes to storage:
- How much? The total amount of storage should correlate to your needs, with a bit of future proofing built in.
- Throughput: Throughput to the storage is mostly pertinent in solutions for video, database servers, and other data-intensive systems. For most smaller environments, unless you want to stream video, a Thunderbolt or USB 3 storage array is sufficient, with enough space to back up your data.
When planning storage, consider having a smaller drive or partition (maybe 100 GB) as the boot volume and a larger one as your data volume. Separate disks are always fine, but it’s often easier (and a better use of resources) to make multiple partitions on a disk by partitioning it in Disk Utility. Also, separating your data and your operating system keeps the server stable even if you fill up the data drive and, in the event of corruption or failure, lets you restore one without having to restore both.
The only time you want to avoid partitioning is if you are using SQL databases or anything else that’s disk-intensive, since performance will suffer. In such a situation, each volume should ideally have its own dedicated drive or dedicated drives in a RAID configuration.
Server Resources (CPU & RAM)
A stock Mac mini or older Mac Pro usually has ample resources for offering basic services such as file serving. When figuring out what Mac to buy or press into service, and how to equip it, you’ll need to keep two basic variables in mind: CPU power and amount of RAM.
There is no magic formula for planning a server deployment; however, the more services that you will be running, the more memory you will need, and the more users that will access each service, the more CPU you will usually need so that each service can process requests faster.
How heavily each service will be used determines how powerful a CPU your server will need. For some environments, such as a home file server, Apple’s cylindrical Mac Pro would be overkill, unless you’re also using it for home decor. Stick with a Mac mini for a home file server.
On the other hand, if you expect to have more than 50 users accessing your file server, or if your server will be engaged in a CPU-intensive process like video transcoding, then the top-of-the-line performance of the Mac Pro may be welcome. And if your budget doesn’t have room for a new Mac Pro, a previous-generation Mac Pro tower would be a good compromise.
As I said, when it comes to RAM, the key thing to realize is that the more services you run on a single server, the more memory that server should have. For example, if a server is going to run directory services, file sharing, and shared calendars, plus manage DNS for the network and manage incoming backups, even for a smaller environment, you’ll need much more memory than a server that is just hosting directory services or file sharing for even 100 or more people.
Each service requires memory, and I generally recommend at least 4 GB per service, although many services can’t utilize more than 8 GB. You should always start a Mac server with at least 8 GB of memory and go up from there, depending on how many services you want to run.
When it comes to thinking about server performance, you must always keep bandwidth in mind, but it can be a bit more complex than some of the other topics in this chapter. At a base level, you must consider the network interface on the client, the network interface on the server, and the network link between the two.
Since all recent Macs have gigabit Ethernet ports, you’ll get the best performance if everyone sticks with wired Ethernet (assuming your Ethernet cabling is in good shape and you have gigabit Ethernet switches).
Where you start to run into trouble is with Wi-Fi, where the caveats start to pile up. In theory, 802.11g maxes out at 54 megabits per second (Mbps), 802.11n can hit 150 Mbps, and 802.11ac can go as high as 1.3 gigabits per second. In the real world, throughput is dependent on many variables, and never reaches the advertised maximums. In short, wireless is likely to be a lot slower than wired.
The practical upshot is that your server should be connected to your network solely via wired Ethernet, and any client computers for whom performance is important should also be on wired Ethernet.
But even then, meeting bandwidth requirements is a growing challenge, thanks to the amount of data being pushed through servers continuing to increase. If you are deploying a file server, consider how many people will be opening and saving files from your server simultaneously, such as first thing in the morning when everyone comes in, or at the end of the day.
For a small ad production company, for instance, this might involve ten people who have to work on a 5 GB video file. Even if the company’s server is a Mac Pro with gigabit Ethernet, it could take well over a minute for users to open files. A minute may not sound like much, but when you’re waiting for a file to open or save, it can be an eternity.
When thinking about bandwidth requirements, note that the potential throughput required is the number of users accessing files multiplied by the size of the typical files accessed. So consider how a typical user would access files and multiply that person’s maximum throughput by the number of users, keeping in mind what your network type can do. For instance, if you have ten users going over gigabit Ethernet interfaces, you could have a maximum throughput of 10 gigabits, which a single gigabit Ethernet interface cannot provide for. What to do?
Luckily, there are three main ways of increasing bandwidth, and while the specifics are beyond the scope of this book, the following advice should set you on the right path. All of these options can be pricey and are listed in order of potential expense, but time is money, so if you need the speed…
- Provide an interface for each user. Mac Pros have a lot of Thunderbolt ports, each of which can each have its own IP address, making it possible for each user to have a dedicated network interface.
- Consider bonding multiple Ethernet ports together using link aggregation. To use link aggregation, you need a switch that supports the feature. A beneficial side effect of link aggregation is redundancy. If one Ethernet port goes down, the overall connection remains active, with the remaining ports maintaining connections.
- If you’re using a Mac Pro as your server, invest in a 10 gigabit Ethernet network card. This will require 10 gigabit switches and network adapters, plus at least Cat6 Ethernet cabling.
Realistically, most people reading this book won’t need to go to such lengths. If the amount of time users will have to wait for files to open and save is satisfactory to all parties then there’s no need to have more than the standard single gigabit Ethernet interface. And if you’re running a Web server on a network with a 10 Mbps connection, you aren’t likely to ever saturate a gigabit Ethernet interface.
Read More: About | Chapter 1 | Chapter 2 | Chapter 3 | Chapter 4 | Chapter 5 | Chapter 6 | Chapter 7 | Chapter 8 | Chapter 9 | Chapter 10 | Chapter 11 | Chapter 12 | Chapter 13 | Chapter 14
Perhaps in the sidebar on "What about iMacs?" you could address another common configuration: the home user who has OS X Server installed as a small part of the machine's total use. While you may be advocating for a machine dedicated to server duties only, out in the world there's people like me who are mainly looking to set up a replacement for iCloud or other cloud services because I don't want to entrust my data to a large company's remote servers.
What considerations should a user like me keep in mind? (late 2012 iMac, 24GB Ram, wired Ethernet connection to an Airport router, DynDNS providing a pseudo-static IP address.) I'd be surprised if I'm the only person out here using Mac OS X Server in this way.
That's an interesting point, Matt, and one I must admit to not having considered, mostly because there are certain conflicts between the use of a personal Mac and a server (the fact that personal Macs are usually allowed to go to sleep being one obvious issue).
But of course, if you're running OS X Server purely for your own syncing purposes, or for minimal file sharing with a spouse's Mac that wouldn't be in use at unexpected times, there's no inherent reason this couldn't work.
On the plus side, I expect that, apart from the sleep issue, most of the rest of the advice will be appropriate, if occasionally slight overkill.
We'll see what Charles thinks!
One thing that might be cool is to add a few more "use case" paragraphs or sidebars for different scenarios., with pros and cons and Charles's comments on his enthusiasm over the recommendation. This book may pull out more use cases where the server has a very light load, overall, even if it is an essential component of an overall networking/sharing strategy.
My family gets pretty angry at me when our home server is offline (which might be caused by Dora the Explorer games crashing the server). Late homework gets blamed on the outage, missed appointments, etc. Personally, I'd rather run a 3 year old version of OS X Server on my old computer as a production home server than have a mixed-use computer. But if you want the latest and greatest features I could see having to use one system for both.
I tried to make a point of saying that you don't need a big, beefy server and the server should be built to the scale you need. Two or three people at home should be able to use a mixed-use server; however, I still try to have a dedicated server when possible.
Matt, you're not alone. I'm in the same situation and am hoping to get some of the same perspectives from this book.
I think it'll be important for Charles [not Adam! Oops!] to make distinctions, when necessary, between the business and family uses of Server, something that's sorely lacking in other titles.
We've always had an internal server (not running OS X Server until now, though!) and it has always been a hand-me-down computer - historically my previous Power Mac, although the last switch was from a Power Mac G5 to a Mac mini when Tonya upgraded from it to an iMac.
I'd personally be quite hesitant to host significant services on a personal Mac, if only because other people could be working on it when I decide to reboot (or crash - my Mac Pro has been quite flaky since upgrading to Mavericks). But it's certainly technically possible, and doesn't really require anything significantly different in terms of configuration.
Oh, and my first major goal since installation has been to sync calendar and contacts across my office iMac, portable MPPro, iPhone, and iPad. Eventually my spouse's MB and iOS devices will be added into the mix. The calendar service is just about stable now, but the contacts have been very frustrating across devices--which has left me using Google as a synching hub until I get things sorted out.
Sharing this information may help with visualizing your audience, and I'm so glad that you're doing this book!
We definitely cover the Calendar service. While we cover the Contacts service, it's worth mentioning that it's not like a shared repository of vcards. It's definitely meant to sync each users contact information with the server. When we've tried to use a shared account for that it seems like contacts invariably get changed or deleted and there's no audit trail for who did so, since everyone is using the same account. But we absolutely cover those services (within the realm of what OS X Server can actually do). And I use my daughters account on my home server as the examples in the text! :)
There's an interesting and useful discussion of Thunderbolt 2 versus 1 and the issues around channels, ports and buses over on MacBreak Studio.
They're building their ultimate FCP X setup (fun in itself...) but useful info on throughput here in Part Two from about 2.20 onwards on throughput as well as smart cable attachment which I had not seen elsewhere.
This comment came in via email, and I wanted to share it here. The advice above suggests, for certain use cases, to add a 10 gigabit Ethernet network card to a Mac Pro. That will not work with the new second-generation (cylinder) Mac Pro, because it has no card slots. You'd be looking at a Thunderbolt option.
Hi Adam / Charles
I have been wanting this book for years so I was very happy to see this in my RSS feed!
Just a couple of comments.
Regarding Adam's "we’re walking a fine line in figuring how deep to go”, I feel strongly that anyone who purchases a book about running a server will be fairly technically competent. So I would *always* err on he side of giving more low-level detail wherever possible. Some Take Control Books are going to be more "basic user” friendly, but for this book to be useful to anyone it needs to have techie info that is sometimes complex (which is why I would buy the book), else it risks trying to please everyone and actually being useful to no one. I’m expecting lots of terminal commands and real world set-up advise from someone who has clearly done this for paying clients.
Specific to Chapter 2
I would like to see more information about the link aggregation. There is a lot of space given to “Bandwidth” in the chapter but nothing detailed about how achieve more. The 1st bullet point says that the MP has multiple Thunderbolt ports and each one can have an IP - I presume you mean if you use a TB to Ethernet network adaptor. The 2nd bullet point about link aggregation is in reality what you would probably do, but there are no instructions about how to set this up.
I know how to set-up a bonded pair of NICs and also understand that Apple supports the standard LACP protocol - what I can not find anywhere is what load-balacing method Apple uses to send traffic out of each member NIC or if its active or passive mode LACP? (Even if some one replied in these forums it would be helpful). These are the sorts of details that would help someone setting this up for real - rather than just reading the book for interest.
OS X supports 802.1q for VLANs and 802.3ad for LACP (I find I usually end up using both at the same time). When given the option for type, you will usually use Trunk and if given the option, I usually select Round-Robin so it's active-active (the default for Trunks is often active-passsive. YMMV with regards to terminology with switching vendors as that doesn't seem too standard.
I'll try and add link aggregation steps, but given that I've never seen it used in a home environment I might also just make that an appendix. :)
But in your Chapter 1 you say this book is not just for the home enthusiast but also for "administrator of dozens of computers in a busy office .... or a professional system administrator" - so thats back to my point that I feel the book should be low-level useful not just a basic overview.
Regarding the trunking and LCAP. I am a very experienced network administrator and so fully understand both concepts, what I lack is an understanding of how to implement them on the Mac server. As LACP and .1q are IETF RFC standards you can just refer to the standard terminology as this is the same cross vendor (Juniper and Cisco both call a trunk a trunk etc..).
After reading Apple manuals I still have no idea what load-balancing method is used (or even if is possible to set this on the Mac side)? The Mac way of setting a VLAN tag is very strange - you seem to have to tie this to a NIC (rather than set this under the NICs settings), but then if you have a vlan assigned to both NICs you can't then bond them??? I hope you can shed some light on this.
Methods: I've only used round robin. I've tried dynamic, the proprietary ones from HP and ratio with no success. If I set the switch to failover then that will work, but otherwise it's always been round-robin.
VLAN: If you look at 'networksetup -listallhardwareports' that will show you the physical ports, or devices. You then can use 'networksetup -listdevicesthatsupportVLAN' to see the devices that can support tagging. Provided the bond0 interface shows up you should be able to tag it with the -createVLAN option.
Hope that helps!
Thanks for the comments, Jonathan! What we're struggling with is that we do have a lot of home users who might be interested in running OS X Server on a personal Mac, as well as folks like you who are looking for highly technical details. As you can see from his response, Charles knows a ton about the topics, but I don't know enough (I've never even contemplated bonding NICs, much less worried about the load-balancing method :-)) to ask those questions of Charles or to help design the structure of the chapters to accommodate such technical details.
What I'm pondering is if there's a way to indicate which bits of information are relevant to which audiences. I could see sidebars being useful for calling out highly technical content, but they can't really be more than a page long in our template, so we might need a way of indicating the difference at the Heading 2 level.
I just hit that in the Directory Services chapter, where the issue of setting up an Open Directory replica comes up. That's necessary only on larger networks, where there will be multiple servers, so it's completely irrelevant to the home user or small office network. But it's good information and should absolutely be covered, and we need to figure out how to make it clear who should or should not read it.
I think there are several guides to OSX Server which target the high end user. Peachpit and O'Reilly are good sources.
Better for Take Control to keep a focus on the enthusiast, sometime professional rather than an industry professional operating at scale. Look at the home / small office scenario which a lot of Macs end up being used in, small creative teams to families.
Just my 2¢.
Since this is my situation - migrating a soon-to-be-not-my-main-Mac mini to a home server - I'm mostly interested in this approach. I don't plan to be serving a web site to the outside world; I want to use a server to host local files (mostly videos), provide software update caching, and whatever else it's good for (perhaps Time Machine backups). My guess is that most readers of this book will be in my situation.
It might be good to focus on the closed, home environment, but then have sidebars that talk about more complex uses, such as serving websites and hosting your own email.
Some thoughts you might like to incorporate: WRT boot disks, for years I have habitually made room for 2 partitions, and sometimes 3. Two allow me to back up the active one regularly, and quickly revert to the backup if a system or app update causes problems, or to easily switch from the current o/s (e.g. 10.9) to a previous release (e.g. 10.8). Three allow me to do both. (This is one of the things I've loved about Macs, as opposed to Windows, for years - even decades!).
I also habitually put my home directories (and many 3rd party apps) in yet another partition. This results in smaller boot partitions (+ faster backups of those partitions) and less disk usage (i.e. avoid multiple copies of apps).
In this chapter I am missing a mention about using server hardware "headless", i.e. without connected screen and keyboard. OS-X allows remote management of the server from any client through screen sharing. It is very convenient to use a small Mac Mini stored somewhere in the house and manage it from your normal mac.
Preparation: At the headless mac in SystemPreferences/Sharing the checkbox ScreenSharing must be checked.
But one caveat: After disconnecting the monitor, the headless mac stops using GPU acceleration and you get terrible laggy mouse movement and typing. Easy solution: there are two cheap dongles available from NewerTech (thunderbolt port) and CompuLab (HDMI port), which simulate a connected screen and solve this issue.