The Challenge

Esbjerg Kommune is the fifth largest city in Denmark. It was recently recognized for its outstanding program to support and develop Entrepreneurship in the community. The IT Department of Esbjerg Kommune services 20,000 users across various departments such as central administration, schools and other critical municipal services.

Esbjerg was running on a 5+ year old Exchange 2003 deployment. Their goal was to upgrade to Exchange 2010 and virtualize the entire Exchange environment. Virtualization allows organizations to consolidate servers which helps reduce capital equipment expenditures, as well as operational expenses related to service, manageability and ease of administration. “While we were aware of the improvements in performance that come with successive generations of Exchange, we were worried this would still not be enough  to deliver the performance levels required. This concern was also exacerbated by the fact that we wanted to run on a virtualized platform. Hence, to alleviate this issue we wanted to leverage some form of I/O acceleration since we believe the biggest challenge would indeed be related to I/O” said Esben Foverskov, head of IT infrastructure.

Esbjerg’s internal users were already challenged by long response times for general Outlook tasks. In particular, Calendar lookups were a major source of user frustration as multiple calendar lookups could take an excessive amount of time, or cause Outlook to hang. Virtualizing an already stressed environment would create even more I/O, meaning the new solution would have to service an even greater workload, while utilizing existing storage systems. The Exchange 2010 upgrade project was thus a high profile, and extremely visible project for the IT Department. They were determined to improve the user experience without changing the storage infrastructure so as not to compromise existing connectivity and redundancy. 

The Solution

As Esben and his team thought through the ideal architecture, taking into consideration the existing infrastructure, it became evident that they would need a hybrid solution that was low latency to eliminate or reduce Exchange access times with high I/O performance to handle the increased I/O that virtualization causes. It was determined they needed a caching solution for their ESX server. “Local SSD disk in our ESX servers was considered, but that would not complement our storage system. Google Search turned up very few “hits” for ESX caching technology however, one was for ioTurbine and upon exploration it looked like ioTurbine had everything we were looking for.”

Focused Performance Caching

With primary storage based on a NetApp V-series, which acts as a gateway in front of two enterprise storage arrays, Esben thought about using NetApp PAM (performance acceleration modules) but realized this would not solve the issue. According to Esben the PAM module acts as a kind of I/O boost for the whole storage system, but he would not be able to control where this additional I/O performance should go and its Exchange response times would still suffer from higher network latency, which would reduce the impact that fast I/O would have on actual application response times.

Furthermore, his NetApp system was full and that meant he would have to remove host bus adapters in order to make room for PAM cards. This would require changing the storage architecture and thus compromise on other matters such as connectivity and redundancy. Since the system was full, it could only accommodate a maximum of two PAM cards, meaning that future scalability of the solution was not possible.

“Simply put, deploying ioTurbine in the server targeted the Exchange-specific performance issue and eliminated the network latency compared to using PAM in the NetApp storage system. Putting solid state technology in the storage system is a quick fix, but it does not really help that much in terms of response time. The latency of a SAN is milliseconds, and we were keen to find a solution that could provide more I/O with faster response time than our SAN”, said Esben. “We wanted to put the “power” into the hypervisor, which would provide the lowest latency possible in our opinion.”

A Low-latency, High I/O, Virtualized Exchange Deployment

The ioTurbine software, in tandem with ioDrives, appeared to meet all of Esbjerg’s requirements so Esben and his team went forward with a Proof of Concept (PoC), which demonstrated great performance improvements for the virtual machines.

With good results from the PoC, the team moved forward with a production deployment. “When we put Exchange 2010 into production with ioTurbine, the results were significant, about a 20% end user performance increase.” “Outlook was extremely responsive and we no longer had any issues whatsoever with calendar look ups. We believe this is a combination of improvements in the Exchange 2010 architecture and the benefits of the ioTurbine caching software.” Esben and the team were also pleasantly surprised when they noticed the SAN seemed to be performing faster as well. Investigation revealed that, with ioTurbine in place, there was a 40% reduction on the primary storage load. “Of course,” said Esben, “with the read I/O being satisfied from cache, the primary storage would have a reduced workload and could more efficiently process the write I/O. This offloading of the SAN is a bonus!”

“In short, our existing ESX farm and storage infrastructure can now accommodate an increasing workload and we won’t have to invest in more spindles to achieve our performance targets. It is a great situation for us.” With the virtualized Exchange platform in place and room to spare on the cache, Esben is looking toward the forthcoming SQL virtualization project in 2012 with great confidence.

Virtualized Exchange Deployment Architecture

Primary mailbox servers

• Four virtual servers, each running the Exchange 2010 Mailbox Server role using Database Availability Groups (DAG)
  • Attaches to storage using iSCSI in the guest OS

Primary CAS/HUB array

• Three virtual servers, each VM dedicated to the following Exchange 2010 server rolles
  • Client Access Server
  • Hub Transport Server

Secondary CAS/HUB array for external access

Two virtual servers that share the deployment of the following Exchange 2010 server roles

• Client Access Server
• Hub Transport Server

Summary

By deploying Fusion’s ioTurbine and ioDrive, Esbjerg Kommune enjoys:

• Virtualize performance-sensitive workloads that until now could not be virtualized
• 40% reduction on SAN workload, freeing SAN resources for future growth and other applications
• Reduced spending on storage
• 20% faster Exchange performance for greater end user productivity
• Operational benefits related to service, manageability and ease of administration

About the Customer

Esbjerg Kommune is in the Municipality of Esbjerg, located on the southern west coast of Denmark. Esbjerg is Denmark’s 5th largest city and the main base for Denmark’s offshore activities related to oil, gas and wind energy.