I use the cow vs puppy analogy a lot when talking with our customers and potential customers. There are a number of articles on the Internet that talk about the cow vs. puppy relationship when it comes to your infrastructure servers, but I wanted talk about how we approach that analogy with respect to the MyCloudIT RDS deployment.
The analogy talks about the fact that we have traditionally treated our servers like puppies. When we think about our puppies, if one is sick, the whole world stops, and we spend whatever we need to spend to get the puppy healthy again. When you think about the way we’ve traditionally treated our servers, it’s pretty similar to the way we treat our puppies. Typically, the business stops until the server is healthy again, and just like with the puppy, cost is not an issue.
When you think about treating servers like a cow, that means if a server gets sick, you typically remove it from the server farm (herd) and replace it with another server. This really changes the dynamic of how we approach servers, thus making them more generic than they have been in the past.
Traditionally, we don’t give servers we treat like cows unique names, typically generic names like FileServer001 thru FileServer010, where servers we treat like puppies are given unique names like AcctngSvr or PayrollSvr. Virtualization was the first step in separating the server OS and unique configuration from the actual hardware. We now refer to the “server OS and unique configuration” as a “virtual machine”. As Virtualization evolved, we got to the point that when we encountered a hardware issue, we could easily move the virtual machine from one physical server to another. The cloud continues to build on this capability by removing the overhead of hardware management from the user. If “the cloud” senses that the physical hardware your virtual machine is running on is having an issue, “the cloud” can automatically move your virtual machine to a different physical server.
So how does that fit into our cow vs. puppy discussion and MyCloudIT? In a typical RDS (or RemoteApp deployment), your session hosts can be treated like cows. If a session host fails, you can just replace it and move on. This is especially useful if you have more than one session host in the collection. When you have more than one session host in your collection, you can always clone a functional session host, then use the clone to add additional session hosts to the collection. Cloning an existing, functional session host eliminates the need to configure new sessions hosts from scratch. Since you are cloning an existing session host, it will already be configured with the appropriate software and configuration.
Session hosts typically remain generic in a deployment, the biggest sign of VMs remaining generic is that they do not contain any user data. The User Profile Disk (UPD) stores all of the customer specific settings including the users “My Documents” folder. This means that there is no customer data typically stored on a session host, hence the session hosts can be treated like “cows”. If the session host has issues, just replace it with a new session host. The file share on the RDSMGMT server also aids in keeping the session host generic because you can store the actual data on the RDSMGMT share. In this scenario, let’s think of QuickBooks. If you can store the QuickBooks datafile on the RDSMGMT server file share, then a user logged onto any of the session hosts will be able to access the QuickBooks data file.
For most scenarios, treating the session host like a cow is the right move, but sometimes, you need to store customer data on a session host. In this instance, you need to treat the session host like a “puppy” and ensure it is protected with backups, since the actual VM is no longer generic and must be protected from VM corruption, or malicious software.