Jamf Blog

The Art of Scaling a JSS

Jamf product experts, Douglas Worley and Steve Welgoss, shared what it takes to scale a JSS, including discussing the right architecture needed for different environments and the tools necessary to get there.

Watch this JNUC session in its entirety.

Whether you’re expanding from 1,000 devices to 20,000 or just looking to add another 200, in today’s session, Jamf product experts, Douglas Worley and Steve Welgoss, shared what it takes to scale a JSS, including discussing the right architecture needed for different environments and the tools necessary to get there.

With a total of 10 years at Jamf under their belts, Worley and Welgoss have seen a number of large deployments, including some commonalities in the ones that went well.

“The past year or so has been full of a few exciting announcements about some large-scale Apple deployments using Casper Suite,” Worley said. “While we cannot speak to any specifics about any particular project or company, our goal is to share some stories and insights into some of the larger deployments we have been party to.”

The duo started with some key terminology, pointing out that with the Jamf rebrand, the JSS was renamed to Jamf Pro Server. A number of additional clarifications helped set the stage for the complexity of the presentation.

Starting with a look at the server platform, Worley explained Casper Suite can be installed on any platform IT admins want to support. He said, “It’s funny. I’ve worked in Mac IT for more than 12 years, and I’ve never touched so many Windows servers until I worked for Jamf.” He continued saying, “Some of these OS platforms have better inherent security or support. Some are cheaper, and some are easier for various kinds of nerds to support. It’s all the same to us. If we test against them, then we commit to supporting it.”

They then took a look at the basic single server setup, explaining that part of every sale includes a JumpStart – a service engagement where Jamf experts work with clients to install all components of Casper Suite onto a server. Deployments for new customers occur on an all-in-one server, with the option to break them out into different, discrete servers – a way to spread out the load.

“Usually, a basic single-server setup doesn’t provide access to manage computers and devices off the local network,” Welgoss explained. “There is a lot of benefit in providing management functionality to devices on either side of the company LAN, but that will usually require a different configuration.”

Welgoss went on to explain that one stock server can only handle a certain number of managed devices. Once that point is reached, the JSS needs to scale to handle the extra traffic.

There are two scaling methodologies:

Scaling Vertically: Adding more resources to the server.

Scaling Horizontally: Adding more stock servers into the cluster.

While there are pros and cons to each method, users often choose one, the other or both depending on their specific environment. Scaling vertically is typically less expensive, but it is also more complicated, because it requires attention to a number of configuration files. Scaling horizontally is usually easier, because a basic VM with standard Tomcat/Java/MySQL configurations require very little attention once installed.

So how do you know what to use? Ask yourself the following questions:

1) Which team(s) will be involved with standing up new servers, and how comfortable are they in making customizations to them?

2) Which team(s) will be involved in configuring each new server?

3) What core OS will we be working on, and is licensing a concern?

“The first step we can provide for external access is to put a Casper Suite web server in the DMZ,” Welgoss explained. “At this point a split-horizon DNS would tell devices on both sides of the corporate network how to find a Jamf web server, each of which share the same database.”

They then walked through a couple of setup options, pointing out key inventory management concerns. “Some of the largest deployments I’ve seen limit how many policies run an Inventory Update,” Worley said. “By running the update too often, it’s possible to see certain database tables blow up in size.”

After reviewing a handful of scripting tips and tricks, Worley shared information about a Distributed Clustered Setup – another way to scale your environment by distributing the roles of web apps within the cluster.

The session ended with a look at memcached – an up-an-coming piece of Casper Suite. “You can think of the architecture here kind of like a Fusion Drive in your iMac,” Worley explained. “Just like how a Fusion drive has a flash buffer to go along with the faster/slower spinning platter disk, memcached will provide a really fast read/write buffer pool to share recent transactions with the other Jamf web servers.” Of course, there’s more to come!

Subscribe to the Jamf Blog

Have market trends, Apple updates and Jamf news delivered directly to your inbox.

To learn more about how we collect, use, disclose, transfer, and store your information, please visit our Privacy Policy.