One of the great benefits for us in IT is that as hardware and storage prices have come down, and performance has increased, we are more able to offer services that in the past was prohibitively expensive to deliver. Rapid deployment and expansion of service, redundancy, and very high availability are all possible now for a fraction of the cost of a few years ago. Granted, it still costs more to provide such high quality service. Let’s take a look at how virtualization, replication and high availability, impact storage requirements and costs.

Virtualization allows us to deploy servers without tying resources to a single specific hardware system. The images can be moved from one system to another, cloned, made redundant and thereby easily allow expansion of particular applications and services. Virtual servers are a foundation for simple, rapid, consistent scalability. Having several or many identical instances allows us to deliver high availability far more easily. Virtual images do take space, and must run on a base platform, so clearly a single VM takes more space and resources that the same service running on dedicated hardware.

High Availability (HA) is the IT goal of having continuously available service for a particular application, connection or resource. Sometimes this is done via fail-over from a primary to a secondary connection or resource. It is also possible via load balancing. The load balancing can be accomplished at the application layer, at a gateway layer, or via an appliance. Load balancing is also possible at the name lookup level. For the purposes of this discussion we are considering application, gateway, and appliance types of load balancing and fail-over. Application layer mail gateway routing is often built-in to the system, whereby the gateway has alternate choices to try if its primary gateway is unavailable. This may be implemented in different ways depending on the vendor and the service. For SMTP there are underlying standards and requirements for gateway and routing behavior.

Replication of data that changes is key for us to have consistent service in the event of a failure of one of the data storage servers. So virtual images aren’t enough–we need to have the changing data replicated from the primary location to one or more redundant locations, ideally in real time.
Storage requirements obviously go up linearly for every replicated server. If you have a series of servers with the same OS, configuration, applications and local data replicated, you should then have for every n servers you have n times the storage requirements. For three servers, you have three times the base storage requirements. For 10 servers, 10 times the storage needed. Fortunately performance and reliability scale far better than the required storage. Another important factor is that the front end application layer or Web layer doesn’t hold all of the data presented. It should be clear that not every server hosts the directory of email addresses and user identities. And the Web interface doesn’t host the mail messages or the directory–it’s just a front end. The mail messages themselves are in a database, data store, or file store (depending on the mail server, platform and configuration you have picked) and that database can be highly available and replicated, but there isn’t a message store duplicating all messages on every server and replicating them to each one. Instead, the design is usually a central store, perhaps with one replica in a cluster. Similarly there are few directories, often replicated between sites or across long distances to improve performance for lookups by local users.

A very straightforward HA server layout might look something like this: two (or more) servers on the Web tier, two for each of the apps on the application tier, two directory servers and two message store servers for each site. So what might be possible to run on even one server or two in total, we now have eight servers defined, such that we have redundancy at every tier.

HA Cluster Architecture

We then  need to consider base storage requirements for each type of server along with the number of servers we are going to have of each type, in order to determine how much virtual drive space and/or SAN space our servers will consume. As we discover, we always want to budget toward the high end of space calculations, and then put in even more in our estimate for future unexpected situations. For example, on some of the servers we may want or need to take a snapshot of the entire message store to work with, but need to create it locally; so however big in gigabytes our message store is, we’ll need at least that much more room locally to copy or restore such an image. Repair and optimization tools for data stores and databases also may need similarly large amounts of space to work creating temp files or new copies of the data. So, a 15 GB virtual drive might seem big to begin with, but if you build up an 8 GB data store on it, you’re “out of space” if you need to make a copy locally. Consider also if you need to restore from a backup and don’t want to delete the in-place store. Of course, often such work can be done on network drives, but again be warned that disk performance will be much higher locally.

Many of the clustering and distribution of services concepts are available within Microsoft Exchange and are integrated into the application suite, but it’s worth it to understand how these ideas work independent of just a single messaging platform like Exchange.

Virtualization, Replication, Storage and High Availability

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators