JSS and file share on same VM?

luke_jaeger
Contributor

We are setting up new virtualized JAMF infrastructure this summer. Both JSS and file share are going to be Ubuntu VM's in the same hosting environment. Is there any reason we can't run JSS and Samba fileserver on the same VM? It would make administration a little simpler.

7 REPLIES 7

blackholemac
Valued Contributor III

I would suggest that as a bad idea from my point of view. Your JSS already runs MySQL and Tomcat which use quite a bit of physical memory and processor resources. It may also use quite a bit of disk space depending on how big your database is.

If you try to unite your DP and your JSS altogether on one server, you would also have a single point of failure. Splitting the servers up give you the benefits of scaling. The benefits are described thusly. Perhaps you have a lot of Macs and you need scripts and packages running constantly. Having that run on the same server as the JSS would suck up quite a bit of resources, especially if you have a lot of Macs.

There are some that require services separated even further....DPs on multiple servers, MySQL on its own server and Tomcat on multiple servers. I would at least recommend separating your DP from your JSS (Tomcat/MySQL). Considering I don't know how many iOS/macOS clients you service, I can't properly recommend more info on scaling, but I do know you should separate the DPP from the JSS.

Chris_Hafner
Valued Contributor II

To add: I don't really think that Administering that type of setup would be easier. Breaking up the services would make problem-solving far simpler while providing far more flexibility in your upgrade path. i.e. say a certain version of Tomcat works well with your V<Mbut MySQL doesn't You can then tweak and manage each VM to support the unique needs of its intended service.

luke_jaeger
Contributor

We have about 800 Macs under management. I know that separate JSS and DP is the recommendation, but our VM guy wondered why it makes a difference? It's all running on the same infrastructure anyway, so theoretically we could spin up a VM with adequate resources for both.

I just want to make sure this isn't a case of "we've always done it this way because we've always done it this way"

blackholemac
Valued Contributor III

@luke.jaeger This is definitely not a case of "we've always done it this way...". In my case, the art of scaling for us was learned through the school of hard knocks. We've always separated our DP from our JSS because our system was designed to separate services, but even with that separation, our JSS alone got overwhelmed during standardized testing a year and half ago due to severe lack of planning regarding scaling.

I read that you are using 800 Macs under management. I don't have an iOS count so we will assume zero for purposes of this illustration. Each of your Macs are going to be inventorying every 15 minutes assuming you have zero policies or profiles (which I know is not the case, but I'm going to illustrate.) At a minimum that is 3200 check-ins hitting your JSS hourly. Now I assume you have set policies to run including scripts and packages. Among these 3,200 check-ins, perhaps 400-500 of them are going to have a policy tied to the recurring checkin that installs a small package. That would be 3200 check-ins themselves plus 400-500 them hitting the SMB service to install a package from. Now that is quite a strain on even a well configured single server. Perhaps you are also pushing configuration profiles...great thats 3200 of them doing checkin with the server as a result of an MDM check-in, some of the devices which will be missing that profile...more strain on your server downloading those XML files. Now let's assume you are still imaging (I am but you may not be), well during a machine reimage, you will be hitting the SMB part of your single server very hard downloading upwards of 40-60 GB of files...again more strain. Basically your clients have to map the SMB share for most installation (and sometimes scripts that you run). Lots of strain. In short, at a minimum, you will at least need to separate your DP from your JSS.

Now, I'll enlighten you to our setup for a comparison if that helps. I have 5000 iOS devices and 464 Macs under management. We have always separated our DP from the JSS itself, but once Casper Focus/Apple Classroom came into play, running that alone on our iPad fleet during a high stress testing scenario caused our single JSS to crash miserably under the load. (We also were doing Cisco ISE integration with our JSS which was a factor). Right now to service that fleet properly, we have separated our MySQL from our Tomcat and added two additional Tomcat backends to handle the load. I also built myself a dedicated admin console to administer our JSS under security from inside our network only. Finally we added an extra Tomcat instance just to handle Cisco ISE integration (We have since taken that down as we ran into Cisco ISE licensing issues unrelated.) So basically I have 5 servers plus my DP that we need to adequately handle our load. This on a very fast 10 GB pipe. We also handle external traffic on our servers. Finally to handle external traffic, I am experimenting with Azure to be my DP for external clients.

This sounds like a lot of overkill but I built it using recycled VMs from decommissioned servers mostly. It is overkill but I built it to basically last us five years even if we did add an additional 1000-2000 iPads.

The short of this discussion is that separation of services is always a smart thing. You don't want a bad SMB session to overload your entire JSS and you don't want your server to crash in the middle of an important event for your organization.

Finally to do scaling right, I am going to recommend reading/watching this JAMF session: The Art of Scaling a JSS. If you liked everything you learned in this article consider attending the CJA class if you are really looking to do scaling right. The instructors have developed a good strong boot camp that will help you to scale to fit any organization. I would advise having some time in managing your JSS on a day to day basis for a while or the class might be a tough one. Don't let the "no prerequisites" fool you. The only reason this class has no prereqs is because it is a speciality class devoted solely to scaling your JSS not to operating it.

luke_jaeger
Contributor

good info, thanks for detailed response

robert_allen
New Contributor

I was recently testing out running JSS and a Samba file server off the same VM. This month, Samba announced a major security vulnerability: https://www.samba.org/samba/security/CVE-2017-7494.html

I brought down my test machine so I could research the problem more. It made me realize that had my JSS been in production on the same machine as the Samba server, I would have had to bring down both even though the JSS was fine.

blackholemac
Valued Contributor III

The decision whether to do this or not ultimately comes down to what you want to support in your environment. Could a unified JSS/DP work in practice...maybe? Is there likely to be issues...yes.

For instance if all you have is one VM to do this all with and you have no other option, it is better than not having a management product at all, but I would be asking at a minimum for at least one separate VM (with adequate storage and resources) to dedicate one to file sharing as well as one to the JSS itself.

If I have 3 VMs to dedicate to this project, maybe I do one internal JSS (MySQL and Tomcat), one DMZ instance to service external clients (Tomcat only) and one file share distribution point.

If I had 4 VMs, I would do one internal JSS (MySQL and Tomcat), one DMZ Tomcat instance (Tomcat only), and 2 distribution points to handle different network segments on your network given that you are tilted more toward Mac than iOS.

If I had more, I might consider separating MySQL from Tomcat and adding more Tomcat instances (behind a load balancer), DPs as needed. You can scale up as big or as small as you like from here.

The key to building out and scaling is knowing exactly what you are managing, where you are managing it, what you are adding in the near future, and what resources you have to work with and who to ask for more in a true pinch.

You might also consider asking Jamf to host your infrastructure. I'm not saying that works for everyone, but it's something to consider. Please keep us updated on your deliberations.