So, you've already virtualized all the easy stuff. You've replaced that rusty old hardware off of your datacenter floor and migrated legacy applications to a virtual infrastructure. You've even toyed with creating a disaster recovery plan that relies heavily on virtualization offerings from VMware and Microsoft. But that's so 2006. Which servers remained after that first go-around? What was taboo during your first consolidation project? What prevented you from moving every piece of hardware on the datacenter floor to a VM? Early on, many administrators used virtualization solely as a consolidation tool - a platform for squeezing as many low-end servers onto one piece of hardware as the CPU and RAM would allow. But now that the technology (and its users) matured, the important question to ask oneself is: do the same barriers exist that prevented virtualizing those once "taboo" workloads?
In working with a wide variety of clients, we've recognized that one of the most frequently excluded services from the initial virtualization initiative is e-mail. Be it uncertainty of performance levels, lack of knowledge about migrating e-mail, or fear of virtualization in general, e-mail had not traditionally been a primary candidate for consolidation. However, in the last 1-2 years, we have seen a much greater adoption rate for virtualized e-mail services - especially those moving to Microsoft Exchange 2007 environments. Exchange 2007 took gigantic steps forward in both performance and availability with its new feature set and its 64-bit-only architecture.
Recently, I had the pleasure of meeting with a client for a virtualization project. While speaking with them I caught notice of an e-mail upgrade project and learned that the customer was moving to Exchange 2007. As always, it was important to get an understanding of the client's current environment, their pain points, and the business drivers behind the upgrade. It turns out that they had experienced a catastrophic failure of their existing e-mail environment resulting in a corrupt mail database (information store), corrupt backup data and ultimately lost e-mail messages. The restoration process that ensued took several days and even then, there were countless messages that could not be restored. As a result crippling the organization's ability to conduct business for several days, upper management put down a strict rule set for recovering from such a failure. The objectives included the following:
· -A Recovery Time Objective (RTO) of 2 hours in the event of data failure / system failure
· -A Recovery Point Objective (RPO) of 6 hours in the event of data failure / system failure
· -Site redundancy (Disaster Recovery)
· -Ability to meet ongoing / increasing demands for data retention
The IT department matched these requirements to Exchange 2007 and its rich feature set. One of the most attractive features of Exchange 2007 is...Please click here to finish reading this entry.
Technorati
Del.icio.us
Slashdot
Digg
twitter
