A year ago, I wrote a blog about using the cloud for training environments. A year has passed, that has been filled with very successful training events, all running in the cloud! Along the way we learned a few things that I would like to share.
First, the notion of cloud and internet seems to evoke a realm that has no real boundaries nor location. Well, I apologize if I’m shattering any dreams, but the cloud is hosted in datacenters, which are connected to the internet. As a consequence, just like when purchasing a house, location is an important aspect. Is it critical? No it’s not. We have sometimes run a training event using cloud-based server instances hosted on another continent. It’s just not optimal. Of course it’s not so much about physical distance, but rather about network paths and latency.
Our original plan was to use a central application server, and have many client entities connect to it, whether using a terminal server or directly from the students’ computers. That is a viable option, provided that you pay attention to sizing, just like with any environment. But we quickly realized that there are some things, like tuning, that can be better illustrated if each student gets his/her own server. While that is more difficult to implement in a traditional environment, in the cloud, it’s just a few clicks and a few dollars away. An added benefit is isolation. If a student inadvertently damages a system, it does not affect the rest of the group.
Now imagine that you have 100 students… So you have to start 100 servers. That can be quite tedious… Thankfully we had a tool that let us create landscapes of multiple servers. A good compromise between ease of use and granularity is to manage the server instances in blocks of 10-20. Another important benefit of the landscapes, that we have not taken advantage of yet, is that you can add some scripts that will automatically set up networking parameters. This allows for landscapes of multi-server environments, that can easily be multiplied without having to change parameters manually in each system.
Another important tool is the scheduler. You can set your landscape or server instances to start and stop automatically, for example 7am to 7pm weekdays only. And you can set an end date, so past that date the schedule is inactive. It’s convenient and saves a lot of money as you don’t pay much for inactive server instances.
There is, however, one aspect of the cloud that can be a bit frustrating. We used the Elastic Cloud (EC2) and an important thing to be aware of is that the disk storage is not really there until you use it. In other words, it’s like a near-online storage. But as files are accessed, they are brought online and remain in that state. As a consequence, the storage is initially very slow, but then as the system starts using the files, the storage performance becomes much better and actually becomes impressively fast. It just needs to “warm up”. An easy but time-consuming workaround is a process that reads every file in the system, that you can run before you need the systems. (It’s based on the Unix DD command, ported to the Windows platform). In our experience, that process was taking about 6 hours, and by the time the students accessed the servers, the storage performance was optimal!
Beyond the flexibility that the cloud provides, there’s another great asset that has had a tremendous impact on the attendees: performance! We consistently received great comments from the attendees on the performance of the systems:
“My experience was OUTSTANDING”
“A ton of well assembled material put together by people that understand it, delivered really fast on a great training systems environment.”