A few quick notes on putting your JSS in Rackspace

[kitzy]

I've spent the past couple months building out a multi-context JSS environment in Rackspace, and I wanted to share what I've learned.

Server Time Settings

If you're using Cloud Databases as your MySQL backend, your Cloud DB instance runs on UTC time. Your JSS will pull its time from your database, and there is no way in the JSS to offset to your local timezone. You just have to keep in mind that "server time" will always be different (eg. 5 hours ahead for EST). I have a feature request in for JSS timezone settings here: https://jamfnation.jamfsoftware.com/featureRequest.html?id=1074

Database Connection Times

If you're using Cloud Databases as your MySQL backend, be aware that the Cloud DB instance will kill sleeping connections after 120 seconds. By default, the JSS has a keep alive time of 300 seconds. This could result in performance issues due to dropped DB connections. To fix this, change the value for IdleConnectionTestPeriod from 300 to something lower than 120 in the file /path/to/tomcat/webapps/$instanceName/WEB-INF/xml/DataBase.xml

This can be scripted as well (especially if you're using my JSSDeploy script: https://github.com/jkitzmiller/jssdeploy), with the following command:

sed "s@<IdleConnectionTestPeriod>.*@<IdleConnectionTestPeriod>100</IdleConnectionTestPeriod>@" -i /var/lib/tomcat7/webapps/$instanceName/WEB-INF/xml/DataBase.xml

Network Segments

As of version 8.63, the IP address in a machine's inventory record is based on the IP the client is connecting from. If your client and JSS are on the same network (or talking over a site-to-site VPN), you will get the client's local IP address. Unfortunately, once the JSS is in the cloud, the JSS will only see the client's WAN address. If you have multiple locations with their own WAN connections, you can add the WAN address as a network segment, and the network segment functionality will still work as expected.

http://www.johnkitzmiller.com/blog/2013/2/22/what-ive-learned-building-a-multi-context-jss-in-racksp...

[myronjoffe]

How much better performance wise is it having a separate Cloud Database. Apposed to having 1 cloud server running the Database, tomcat etc... ?

[myronjoffe]

Have you had a look at an extended Attribute that captures the local ip of the client? Depending what you want to do might be useful.

[kitzy]

I used Cloud Databases because the environment I built is actually clustered, so there are a few servers running Tomcat all talking to the same database. I could have spun up another couple servers to build my own MySQL cluster, but using Cloud Databases was cheaper and quicker. Definitely a win once we worked out the issues I mentioned in the OP.

We have an extension attribute to capture the local IP of the client which is used by a couple scripts, but the network segments are very powerful, giving us the ability to automatically set buildings in inventory, distribution points, netboot servers and SU servers, which is very useful to us as an MSP.

[kitzy]

How much better performance wise is it having a separate Cloud Database. Apposed to having 1 cloud server running the Database, tomcat etc... ?

To touch on this a little further, it wasn't so much about performance as it was about eliminating as many single points of failure as possible. Having Tomcat and MySQL all running on a single server means the JSS is dead if that single server goes down. Cloud Databases operates on a massive cluster, and I can spin up as many Tomcat servers as my heart desires. In this configuration, servers can go down all day but my JSS will stay up.