Three Reasons to Choose Tegile for your Exchange Deployment

Back in the days of Exchange 2000 and Exchange 2003, the world’s most popular email and calendaring system carried with it such extreme I/O loads and unpredictability that Microsoft wouldn’t support the product unless the storage environment with architected in very specific ways.  With Exchange 2007, Microsoft made major changes to Exchange’s storage needs, resulting in a massively reduced I/O footprint.  This move was a first step in enabling Exchange to run well in virtual environments, which Microsoft officially supported starting with Exchange 2007.  With Exchange 2010 and Exchange 2013, Microsoft has gone even further, reducing the product’s I/O needs to just a fraction of what they were in the old days.

These I/O changes don’t necessarily mean that you can simply throw any old storage at Exchange, though.  It’s still important to ensure that your storage is scalable to meet Exchange’s fluctuating I/O needs, particularly now that you can place many, many more mailboxes on a single Exchange server than was ever possible in the past.

Fortunately, Tegile’s Zebi line of storage arrays are perfectly suited to all things Exchange and can support even the largest Exchange environments and brings – or sometimes returns – to Exchange some critical features that can massively reduce the total cost of storage in the Exchange environment.

Deduplication

Exchange 2003 fully supported deduplication, but in that product, Microsoft called it Single Instance Storage.  It was a method by which Exchange would store only a single copy of a message and its attachments even if that message was sent to 1,000 people.  With Exchange 2007, attachments are still single instanced, but message bodies are not.  In other words, if you sent a message to 1,000 people, the attachments would be stored just once, but the message itself would is stored 1,000 times.  In Exchange 2010, Microsoft finally jettisoned single instance storage altogether.

The reason Microsoft did this is simple:  As hard drives continued to increase in size, the space savings was no longer worth the massive I/O tradeoff.  Microsoft’s single instance engine was an I/O hog, requiring a lot of IOPS.  Microsoft made the decision that providing a low IOPS per mailbox service was more important than the capacity savings introduced by their implementation of deduplication.

With Tegile, you get the best of both worlds!  When you couple a Tegile array with your Exchange 2010 or 2013 implementation, you still get the massive server density capability that is enabled by those versions of Exchange; you can place thousands of mailboxes on a single server.  But, you also get powerful deduplication provided by the Tegile array.  So, you get the great capacity benefit that was found in Exchange 2003 with the great density found in the latest versions of the product.

I call that a win/win!

Do DAG without the complexity of DAG

Database Availability Groups are the Exchange way to provide a highly available architecture.  Depending on the resiliency requirements and the distribution of the active mailbox users, multiple DAG groups can be configured to better suit an organization’s needs.

DAG adds additional I/O load to data storage for operations such as database synchronization and log replication. It also significantly increases the storage capacity requirements by twice or more; this is because a DAG provides resiliency by maintaining one or more copies of Exchange databases. While providing unparalleled high performance and capacity, Tegile’s Zebi inline compression and de-duplication technology can further lower your storage investment by reducing DAG database and log capacity by up to 75%.  That alone is good.

But, if your needs are relatively simple and you want to add some simplicity to your environment, skip the DAG!  For resiliency, and as alternative to DAG, Tegile Zebi provides remote database and log replication. Zebi remote replication is based on an application consistent snapshot, which means that the databases and logs on the remote Zebi array are always transactionally consistent. When the primary site is down, the Microsoft Exchange Server on the DR site can continue providing mail services, which minimizes the service interruption during disaster recovery.

It’s another win/win scenario!

Virtual simplicity

There is growing trend to deploy Microsoft Exchange Servers on virtualized infrastructure. Tegile Zebi arrays supports VMware ESX/ESXi, Citrix XenServer and Microsoft Hyper-V and are certified by all of these server virtualization providers.

Zebi arrays also provide hypervisor aware backup, accelerating the virtual machine provisioning and installation of Microsoft Exchange Server roles through integration with the VMware vStorage API of Data Protection, VAAI and Microsoft VSS.

To best utilize Zebi in virtualized Microsoft Exchange Server deployments follow the general Zebi best practices for ESX, XenServer or Hyper-V, plus the additional Microsoft Exchange specific best practices.

Summary

Tegile Zebi and Exchange were practically made for each other.  For more information about this “chocolate and peanut butter perfection” read the following materials:

Tegile Zebi for Microsoft Exchange Server

Best Practices Guide for Exchange 2010

 


One comment on “Three Reasons to Choose Tegile for your Exchange Deployment

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>