Apple devices in your school? Run Apple’s caching server.

If you are running any significant number of Apple devices in your network - OS X or iOS devices, then you owe it to your users, your network, and your Internet connection to run Apple’s caching server.

First - what is it?

The caching service is a part of OS X Server, and it provides a buffer (or cache) between your devices inside your network, and Apple’s servers. With a properly deployed caching server running, you effectively reduce the amount of traffic passing through your connection to your (expensive and slow) ISP link, and keeping that traffic on your (cheaper and faster) local network.

What does it cache?

Quite a bit. The caching server holds a local copy of:

  • Mac software and updates
  • iOS software and updates
  • iCloud data and files
  • iTunes U data and files
  • Books
  • and the infamous Apple “Other”

To illustrate how it works, consider the following scenario. You have 1000 iPads inside your network in the hands of students and staff (I do!). Each iPad is now required to go load the next version of iOS. Let’s assume that the installer is 3gb to download for this example.

Without the caching server, each iPad contacts Apple’s download servers across your (relatively) slow Internet connection, and downloads the 3gb file. That’s 1000 requests of 3gb each - or 3tb of data across your ISP's link. Unless you have some super-duper huge pipe to the Internet installed at your school, that’s a huge burden on that connection - so much so that you’ll likely bring it to it’s knees!

With the caching server, the first device that requests the update contacts Apple’s server. However, because the caching server has registered itself with Apple, the following conversation occurs:

  1. iPad reports the public IP address it’s coming from to Apple
  2. Apple sees that a caching server has registered from that same public IP address
  3. Apple delivers the requested 3gb file to the caching server
  4. Apple tells the iPad (and every one else that requests the file from your network) that it is available on the caching server inside the private network.
  5. Client then downloads file from caching server at internal network speeds
  6. Every other device that requests the same file is redirected to the copy already on the caching server

In this scenario, that 3gb file is downloaded across your Internet connection once - then every subsequent request by a device inside your network gets the file from your internal caching server. That saves your Internet connection bandwidth for other tasks, like serving YouTube videos to everyone else in your building.

So - how do you set a caching server up? It’s pretty easy. You need two things to make this work:

  1. A reliable, spare Mac you can dedicate (a Mac mini is an excellent choice)
  2. $30 for the OS X Server purchase from the App Store

Set your Mac up, and make sure you are using a wired connection with a static IP address. If at all possible, you want to connect this Mac as close to the network core as possible, because you don’t want to make clients traverse extra hops to reach it. 

In my preferred topology, I have separate wired and wireless core switches. I actually connect my caching servers to the wireless core switch, because the vast majority of my Apple devices, both OS X and iOS, connect wirelessly. By being at the core switch (which is usually your most powerful one anyways) it’s the fastest and most direct route the client can take.

One your Mac is all setup, buy and install OS X Server on the Mac. I recommend you follow some of the excellent “how to” articles on basic OS X Server setup. You don’t need to worry about Open Directory, or anything else - you want this Mac to be dedicated to caching if at all possible, so it’s pretty straightforward to install.

Once Server is installed and running, open up the services panel on the left and click on your server name at the top. We are going to confirm the external IP address that this Mac is going to report to Apple.

Main OS X Server Panel

As you can see, this server is reporting it’s external IP as 50.xxx.xxx.xxx - hopefully, this is a number you or your network team recognizes.

It is important to note here that if you have multiple, redundant connections, and each one reports a different external IP address, then you will need a separate, dedicated Mac running the caching service to be effective. 

For example, we have a both a fiber based connection to the Internet, and as a fall back, an active cable connection. Each gateway reports a unique public IP address for traffic passing through those lines - so I need a separate caching server for each one.

If that is your situation, you will also need to create some routing rules in your gateway/router so that each caching server you setup ALWAYS goes through the same connection. If you don’t create those rules, then it is likely that when your router decides which direction to pass traffic at any given time, you could have both caching servers reporting on 1 address, and none on your other(s).

Assuming you have 1 connection (or you have planned for multiple ones as described above) the rest of the process is easy. 

Click on the Caching service on the left. When the service panel opens, turn on the switch at the top right. You’re done.

Caching Service Panel

As you can see, there are some options, but for all but the most complicated, the only one you need to worry about is how much disk space you allow the caching service to use.

Depending on the mix of devices in your network, and the types of services you use (iCloud, iTunes U, lots of apps, etc.) your decision on how much disk space to allow is up to you. If you dedicated a Mac to caching, and you have a robust number of devices on your network, give it as much as you can up to about 75% - you don’t want to run the risk of running out of disk space. As you can see, you can even specify an external disk, but unless you are attaching via Thunderbolt, I wouldn’t recommend using external media.

If you want to get super complicated, you can even specify which subnets are allowed to talk to this caching server. That setup is beyond the scope of this post, but you can see the options under the Edit Permissions… box:

This the one place you can also see why having a caching server per public IP address is important - unless you are willing to dive into some fancy network settings, you should leave these options alone.

Before I end, I want to point out two things about the main screen.

First, as your cache server gathers content, the space used meter will start to fill up with various colors, indicating how much of each type of content is cached. Hovering over each part will tell you the amount.

The other thing I want to highlight is the little message at the bottom of the image - it’s hidden in the above example because of the pop-up, so here is this screen again, without the pop-up:

See the little grey text? You can have more than 1 caching server servicing clients on the same network! In my environment, we actually have 4 caching servers running - two for each external IP we pass traffic across.

Why would you have more than 1 caching server? 

If you have a large number of clients that are active using iOS and Mac updates, iCloud file access, and iTunes U courses in your network, we’ve found that a single caching server can become overwhelmed. The servers stop responding to ping requests in a timely manner, sending the clients back out to the Internet for content that is already available inside the local network.

If you have more than one caching server configured correctly, they find each other, and share cached content, referring clients between them automatically. Pretty cool.

Lastly, the caching server can fill up over time. While they have some intelligence to purge old data (as far as I can tell), I follow a different rule. I push that Reset… button on our servers a few times a year - usually during week long school vacations, and the beginning and end of summer. 

I figure that by those natural breaks, enough cycles of app updates, OS updates, etc. have happened that we can clear out old content, and allow only the latest requests to start filling the cache again.

My use of the caching service had one additional upside for us - it allowed us to maintain our existing Internet connection speeds for over 2 years, all while adding 400 devices a year. That saved us cash every month. 

Cache for cash. Perhaps Apple would like to buy that bit of marketing genius from me? I doubt too..

--kw