It has been a while since I’ve posted something new, so I am back and now want to catchup with a couple of new and cool things that we have been working on.
Recently, we released a great whitepaper that we’ve been working on as a result of all of our Solutions work against Exchange 2010. We’ve derived many best practices for sizing and design for deploying Exchange 2010 on EMC VNX and EMC VMAX platforms and we want to share that with you.
In this paper, we will discuss disk and RAID selection, LUN layout, and how to size when you might have already used the Exchange Role Calc and want to apply that detail to your EMC array design.
We also answer some key questions such as:
- Should I consider thin LUN with Exchange 2010 on VNX? What about VMAX?
- What are some of the most important design considerations for Exchange 2010 on VNX and VMAX?
- Should I use FAST VP with Exchange 2010 or VNX or VMAX?
- Should I consider FAST Cache in my Exchange design?
- What about Storage Pools vs RAID groups on VNX?
Examples of Exchange storage building blocks are also discussed along with the methodology that we use in our own Solutions labs to derive a desired storage design. Our customers also want to know what our recommendations are when HA/DR is considered, such as what options are there to apply additional protection against my Exchange DAG?
I encourage you to please check out this paper if you have not already seen it. You can find it on our new EMC Community Network “Everything Microsoft at EMC” site at: https://community.emc.com/community/connect/everything_microsoft
My collegue Adrian Simays who runs the excellent Virtual Winfrastructure Blog and his team have worked tirelessly to create this excellent community site and I think you will find it to be very informative resource on everything Microsoft at EMC.
As well, this paper has been posted on EMC.COM at: http://www.emc.com/collateral/hardware/white-papers/h8888-exch-2010-storage-best-pract-design-guid-emc-storage.pdf
Until next time,
Microsoft updated their virtualization guidance for Exchange 2010 right around the time of TechEd, and I have started to get more and more questions from customers around virtualizing Exchange 2010 based on some of the solutions we have been creating. If you haven’t already seen the Microsoft whitepaper you can find it here:
There was also a presentation that was done by Jeff Mealiffe and Jim Lucey from the Exchange Product Group here. that delves into the highlights of the whitepaper.
With the increasing popularity of virtualizing Exchange 2010 a number of questions usually arise around High Avaliability and BC/DR options (aka Site Resiliency) and how they are effected by Virtualization. The good news is very little and with technologies like Hyper-V Live Migration, VM/HA, VMWare’s Site Recovery Manager you will have additional options that can provide other things to think about. Since these technologies can now have coexistence with DAG one must consider how or if these other options come into play.
Let’s start with local HA options. The use of Database Availability Groups (DAG) is certainly a popular option when virtualizing Exchange but in order to have a Microsoft supported configuration with DAG’s you need to follow a few rules. First Exchange server virtual machines, including Exchange Mailbox virtual machines that are part of a Database Availability Group (DAG), can be combined with host-based failover clustering and migration technology as long as the virtual machines are configured such that they will not save and restore state on disk when moved or taken offline. So all failover activity must result in a cold start when the virtual machine is activated on the target. Another important point is to make sure the VM’s housing your active databases are not on the same physical hardware as the VM or VM’s housing the passive copies thus avoiding a single point of failure with the physical hardware. Overall using DAG’s is a virtualized environment are a good option that are supported by Microsoft as long as you follow a few simple rules.
Another option that customers have asked about in virtualized environment for the cost reduction and simplicity is to deploy stand alone mailbox servers and use the built in hypervisor HA mechanisms like VM/HA or Hyper-V Clustering to handle the local HA. With this option only a single RAID protected copy of the database and logs is deployed locally and can help with the cost of deploying multiple DAG copies. It is important to understand, that Hypervisor based HA is not Application aware HA, but for some customers it can meet the requirements for the solution.
For many customers a single RAID protected copy that is being protected by a software or hardware based VSS backup solution is adequate protection based on the requirements. With this option you are protected from the loss of a disk with the RAID, from a physical server loss with VM/HA or Hyper-V Clustering and database corruption with a VSS snapshots. The biggest concern most customers have with this option is patching of the OS or Application, since it will require a reboot of the server. For those that have maintenance windows, this may be less of a concern if you have scheduled periods where you are able to reboot the servers.
When discussing BC/DR/Site Resiliency options, leveraging stretched DAG copies are a great option as well as technologies such as VMWare’s Site Recovery Manager (combined with a storage replication technology such as EMC RecoverPoint or EMC SRDF) if you are looking to restart entire VMs and data from your entire data center into a DR site, as well as the database portability option built into Exchange (yes, it’s still around!). DB portability has taken a back seat to DAG these days, but it is still a very handy option if your BC/DR solution needs to address many more applications than just Exchange, and it’s a nice method to still consider.
Our customers have also been very interested in a recent EMC Proven Solution that we did to leverage a local, 2-copy DAG for HA and leveraging storage replication capability from EMC RecoverPoint to implement a DR solution in the remote site. This solution was discussed at EMC World 2011 and the whitepaper can be found here: Exchange 2010 DR Options with Cross-Site DAG and EMC RecoverPoint
Thanks to Chris Devine from EMC Strategic Solutions who contributed to this post.
Until next time,
EMC World 2011 is next week in sunny Las Vegas, NV and we are finalizing our preparations for the show. I will be there and speaking in two Exchange specific sessions which should be excellent sessions if you are interested in what kinds of cool solutions that we have been cooking up in our labs:
First up, myself and one of my rockstar Solutions Engineers Boris Voronin, will be delivering Exchange 2010 Business Continuity and DR with VMWare on Monday, May 9th from 2-3pm and also repeating on Thursday from 1-2pm. This session will discuss one of our hot new solutions where showcased a cross-site Exchange 2010 DAG and how that solution would be contrasted with a solution featuring a local DAG for HA, but leveraging EMC RecoverPoint Continuous Remote Replication (CRR) with Exchange Database Portability for customers who like options with storage replication for DR. The whitepaper is featured here: http://www.emc.com/collateral/software/white-papers/h8104-exchange-cross-site-dag-recoverpoint-wp.pdf
Second up, is Microsoft Exchange 2010: EMC Storage Best Practices that myself and my other rockstar Solutions Architect, Chris Devine will be delivering. This session will delve into all the great details that you need to know when designing and rolling out your Exchange Storage Design on EMC platforms. We will also be going into some great design detail on some of our most recent Exchange solutions. This session will be on Monday, May 9th from 5-6pm and on Thursday, May 12th from 8:30-9:30am.
Also, my two Sharepoint and SQL partner in crime, Eyal Sharon and James Baldwin will be chatting on Microsoft Sharepoint: EMC Infrastructure Best Practices on Tuesday, May 10th from 11:30-12:30 and Thursday from 1-2pm.
We also have several other great sessions such as EMC Unified Storage with Microsoft Hyper-V: Performance and Best Practices being delivered by Dave “Butch” Butchart which will be very exciting. There are too many great ones to add but if you want to see the full list then check out: http://windowtotheprivatecloud.com/microsoft-emc-world-my-session-agenda/
Between sessions, you can find me hanging out manning the Microsoft solutions station at the “Cloud Meets Big Data Booth” in the Solutions Pavilion in Sands Expo center. This runs from Mon-Thur. We will be showcasing demo’s of the latest and greatest from the EMC Microsoft Solutions labs and showing off some of our latest creations.
Hope to see you in Vegas. If you are attending, please be sure to stop by and say hello.
Until next time,
Recently, we released some great new whitepapers for Exchange 2010 proven out on our new EMC VNX series arrays. If you didn’t already see all of the EMC launch buzz around VNX, you can read more about the VNX buzz here.
The VNX series line is EMC’s new unified line replacing the previous CX and Celerra line. A quick overview of the VNX line is below:
Some of the goals of the VNX Exchange 2010 testing was to get our hands on some of the new 2TB NL-SAS drives that we knew would be popular with Exchange customers so large, cheap drives can be used to enable large mailboxes. 2 HA copies via DAGs were also deployed in each of these solutions to enable for some local HA.
First up, the VNX5700 testing where we setup a simulated customer environment of approximately 16,000 mailboxes, 2GB per mailbox, 150 msgs sent/receive (0.15 IOPS) and 2 HA copies for each DB. This was done with the 2TB NL-SAS drives and the hypervisor tested in our case was VMWare vSphere 4.1. Diagram of the test environment looked like this:
In this particular test, we utilized two Vsphere hosts with Active/Passive copies spread out across VMs in each host. In a normal run, the VMs were configured for 2000 mailboxes in a normal run, 4000 in a single failure (2000A, 2000P).
In the whitepaper for this solution, we show you how to do all of the IOPS and capacity calculations manually, but you can obviously use tools like the Exchange Role Calc as well. We also show you how to use a building block approach to scale the solution. In our case, the requirement was for 16,000 mailboxes so we determined in this solution that 16 2TB disks in R10 was the best mix of performance and capacity for each BB. A total of 4 BB was used, so a total of 64 2TB disks (note: this is your performance and DB capacity req’s only, extra disks required for things like snapshot protection, restore LUN etc which we did not show).
To do some performance validation, we did a two hour Jetstress performance test on the four building blocks (32TB). We saw 2,859 Jetstress IOPS against the required 2,400 with all four servers around 14ms read latency, and 3ms write latency. Very good results:
We also wanted to show some of the goodness that comes with our VMWare integration into EMC Unisphere which will provide administrators with great visibility into our vSphere environment:
And on the VNX5300, we did a mix of FC and iSCSI testing to show efficiencies with both types of connectivity knowing that we all like options. We also tested the VNX5300 running on Microsoft Hyper-V (again, we all love options).
In the VNX5300 testing solution, the 4000 user building block was also utilized with a similar 0.15 IOPS per mailbox profile with 2GB mailboxes and also using the 16 2TB NL-SAS drives. Even with 1GB/s iSCSI on our 2 BB testing, Jetstress performance looked very good. In the diagram below you will see where we compared the 2 BB to 1BB to get an idea of the numbers:
As we saw in the testing, iSCSI network utilization moves up to about 70% in the 2 VM test, so this is something that should be considered. We covered some of the iSCSI best practices that we used in our labs in this paper, so please keep those in mind during your planning.
You can read all of the full details on the Exchange 2010 testing with VNX5700 in the Exchange Server 2010 Performance Review with VNX5700 here: http://www.emc.com/collateral/hardware/white-papers/h8152-exchange-performance-vnx-wp.pdf
Performance Review for the VNX5300 can be found here: http://www.emc.com/collateral/hardware/white-papers/h8158-exchange-performance-vnx-wp.pdf
Until next time,
Quick update on Microsoft publishing of EMC and our partners Tested Exchange Solutions that we’ve blogged about before. Microsoft has now published one of our two Tested Exchange Solutions out on the Tested Exchange solutions page on TechNet:
This whitepaper was a joint collaboration between EMC/Microsoft/Brocade/Dell and was formally titled “Zero Data Loss Disaster Recovery for Exchange 2010″ and featured our Replication Enabler for Exchange plug in to Exchange 2010 DAG (10,000 users per site/20k users total), with EMC CX4-480 storage, Brocade ServerIron ADX Load Balancing and Fabric, along with Dell R910 servers all supporting a virtualized Exchange 2010 infrastructure on Hyper-V.
We are still waiting on the other Tested Exchange Solution that was performed in collaboration with Cisco on their excellent Unified Compute System platform. But, you can get the full EMC version blogged about here from late last year.
Last, stay tuned for some exciting solutions update on what we have been cooking up for our VMAX/SRDF/VMWare HA and Site Recovery Manager solution for Exchange 2010, along with Exchange 2010 DAG/Recoverpoint solution. We also have exciting kit coming out on what we’ve been up to with our new EMC VNX platform with Exchange 2010.
I don’t want to waste too much time responding to HP DAS marketing guys as I like to keep my blog more of a marketing free zone, but this blog post made me have a good laugh this morning:
HP DAS Marketing guy, HPStorageGuy, claims that he heard from another guy at VM World that an unknown EMC guy said that ”SAN is the best and really only option for storage”
We all know personal opinions are one thing, but the fact of the matter is that customer choice is a good thing and there isn’t one answer for every business problem. I believe that SAN is a great choice for Exchange storage (it is certainly not the only one), and it should be noted that Exchange is not the only application in the data center either. We’ve showcased many solutions from this blog that show how there is a fit in many customer scenarios. Customers want choice and for some customers that choice is going with dedicated storage for applications like Exchange and for others it is leveraging the power of shared storage to store data for many applications.
Customers like SherWeb have told us how EMC Virtual Provisioning has given them a competitive advantange in their Exchange 2010 Hosted environment, something they just could not do with a dedicated storage solution for Exchange. And on this blog, we’ve highlighted solutions all the way down to the Iomega StorCenter IX12 line all the way up to the VMAX line.
I can’t say I’m too familar with the published Exchange solutions that my other esteemed collegues at other organizations have put together, but I can say that what we’ve put together around our solutions for Exchange 2010 offers customers choices across the stack.
I’m happy for the guys at HP and their announcement for the E5000 Messaging Appliance. Like any technology choice, this product has a fit for some customers and other customers will continue to choose to store Exchange data and other enterprise data on EMC VNX, EMC VNXe or EMC Symmetrix VMAX.
During the first part of the year, you will start to see some of our new Exchange solutions featuring Exchange on VNX, VNXe, and our private cloud solution enabled by vBlock. Solutions that offer customers a choice no matter what the fit!
A new post on the Exchange Team Blog by Microsoft EEC Program Manager, Rob Simpson unveiled the Exchange 2010 Tested Solutions whitepapers that EMC participated in with Microsoft along with our partners Cisco, Brocade, and Dell. Both of these solutions were discussed on this blog last year and highlighted.
We have received excellent feedback from customers on the value of these solutions and the fact that they are highly detailed and validated reference architectures for Exchange 2010 solutions. If you didn’t catch what these whitepapers were about, you can read the whitepapers at:
- Business Continuity for Exchange 2010 – EMC/Microsoft/Cisco – http://www.emc.com/collateral/hardware/white-papers/h7337-exchange-unified-cisco-hyper-v-wp.pdf
- Zero Data Loss Disaster Recovery for Exchange 2010 – EMC/Microsoft/Brocade/Dell – http://www.emc.com/collateral/software/white-papers/h7410-zero-data-loss-exchange-wp.pdf
For the last several years, there has been a battle (some even describe it as a war) waged out in the Exchange community around the storage choices for Exchange Server… SAN or DAS?
First a little background..
Back when I started with Exchange Server 4.0 in 1996 as an Exchange Administrator, disks and memory were expensive. Just deploying Exchange across 4GB SCSI disks were a luxury and SANs had not been in play in the Intel based servers, usually reserved for midrange and mainframe systems. All disks were usually internal to the server (yes, I have fond memories of the beautiful tan Compaq Proliant 5000′s with 512MB of memory and 4GB disks!) or connected externally via SCSI cables to shelves.
Before Exchange 2007 came on the scene, debate on storage types for Exchange was rarely a conversation with customers or the community. Exchange 5.5 into Exchange 2000 and Exchange 2003 was all about 15k FC disks, the fastest you could find and you went with it.
Fast forward to Exchange 2007 and the DAS vs. SAN battle on Exchange officially begins it’s saga. There have been many of blog posts, many analyst stories, much discussion from both sides of the camp – much of which can tend to become heated and almost to the point of being a religious debate between those who primarily are on the hardware side of the businesses and those on the software side of the business. The Exchange guys vs. the SAN guys, and the hardware guys not seeing eye to eye with the software guys and vice versa.
A recent blog post from my Microsoft Certified Master colleague at Microsoft, a very well-respected member of Microsoft Consulting, Robert Gilles who posted his take on the topic in his post “Robert’s Rules of Exchange: Storage Planning and Testing” at: http://msexchangeteam.com/archive/2011/01/07/457471.aspx that just came out today and I like Robert’s style about bringing some great points about selecting storage for Exchange.
SAN Guys vs. DAS Guys and Exchange Guys
I find it interesting that in the Exchange SAN vs. DAS saga, the “SAN Guys” or whatever names the guys that sell you ‘other’ storage other than Direct Attached Storage have typically become the known (and I am sad to say this as an employee of a major storage vendor, EMC) as the bad guys in many Exchange circles because the SAN guys are said by several in the Exchange communities to offer Exchange solutions that are too complex, too expensive, and to hard to maintain. The “DAS Guys” or the guys who sell you your Exchange servers and non-SAN storage are said to be the good guys now because their stuff is said to be easier, cheaper, and less complex.
On RAID vs. JBOD topic this has started to become another big one almost as big as the SAN vs. DAS topic, I think for most customers its easier to let hardware RAID manage itself, but there is a place for JBOD as long as you understand what you are wanting out of the solution and what it does and doesn’t do. Robert pointed out that Microsoft and Gmail do use JBOD in their solutions, obiviously the teams maintaining those solutions have a very high amount of operational prowess that may not equate to what all organizations have in place.
I like to say that as a storage vendor, not necessarily a SAN only vendor, there are certainly customer requirements that could drive the need for storage solutions that are more complex and areas where DAS storage might not meet the requirements where more centralized storage can. Especially when customers are considering much more of their enterprise architecture other than Exchange Server. With the push to Cloud computing (Private or Public), many CIO/CTO’s are now viewing computing as a much more of a shared utility model where blocks of storage and compute are carved off to provide pieces of infrastructure and customers are showing more and more of where virtualized solutions are becoming more in the mix (Exchange and several other products).
So, when considering DAS vs. SAN I think all requirements have to be considered such as if virtualization is a strong consideration (not just Exchange servers, but other mission critical apps) or if the organization takes a more centralized view of managing storage resources rather than allowing departmental storage proliferation. SANs have become easier to manage, and EMC with Unisphere and our other competitors have excellent interfaces to their storage that makes management much easier than things used to be. Let’s not forget some of the great interfaces that hypervisors have given us into the storage. We’ve done great things integrating our hardware with both Microsoft Hyper-V and with VMWare vSphere.
In many of the Exchange solutions that I have showcased on this blog, I try not to get more into the hardcore religious battles of SAN vs. DAS. Instead, we try to show customers the value of our Exchange solutions that go up and down the stack, to meet customer needs from SMB customers to mid-size, up to the largest enterprises. In previous posts, we have shown you that there is a great Exchange 2010 story for HA/Site Resiliency with large mailboxes with the SMB offering from our Iomega division and the StorCenter IX12 product which is a fit from the 1-250 user environments, we’ve also hit on the largest platform and solutions we’ve done there for our Symmetrix V-MAX line which focus into the large enterprise.
So, in short..Exchange Guys out there, please don’t hate us SAN Guys..Our solutions aren’t as big and bad as some out there would like you to think We love Exchange too and want to help you deploy our solutions with Exchange 2010. We believe that it doesn’t have to be about SAN vs. DAS, but just come down to the right solutions to meet the requirements.
Myself along with several other EMC’ers will be at EMC World 2011 in Las Vegas on May 9-12 at The Venetian, so please come join us. I will have a few sessions at the show focusing on EMC and Exchange 2010 solutions.
Until next time,
We recently have published a very detailed Proven Solution Guide titled “EMC Virtual Infrastructure for Exchange 2010 – Enabled by EMC Symmetrix VMAX, VMWare vSphere 4, and EMC Replication Manager”. This solution was built out in our EMC Hopkinton Solutions Center where we wanted to showcase a 20,000 mailbox deployment on EMC Symmetrix VMAX utilizing Microsoft Exchange Database Availability Group (DAG) for high availability.
The simulated user profile requirements were:
- Mailbox Profile: 150 msgs sent/received per day – .15 IOPS for DAG
- Mailbox size – 1GB, virtually provisioned for 2.5GB
- DAG copies: 2 HA DAG copies in a single DAG
- RTO: 5 minutes
In this case, we used our previous Exchange building block on VMWare VSphere of 5,000 users per Exchange mailbox server/VM guest and aimed for 8 total DBs per server (4 active/4 passive copies). Each mailbox server was determined to utilize 6 vCPU per with a total of 32GB per VM per Microsoft recommended calculations. Across 2 ESX hosts, we deployed a total of 32 active and 32 passive DB, with 625 users per DB and accounted for interruption of service of either of the hosts so that active DBs across VMs could be taken over by Mailbox roles on the other ESX host.
The physical architecture of the solution is described below where we utilized two ESX hosts (based on Dell PE R900, 128GB RAM, 2-dual port 4GB Qlogic HBA), and Cisco MDS9509 FC switching into the VMAX FAs:
Database layout across hosts/DAG members looked like this, which is pretty typical for a DAG architecture where the aim is to distributed active/passive copies evenly across the members and since this is virtualized implementation the aim was also to distribute across physical hosts:
We all know there are some occasions where a DAG copy will need to be reseeded, so we also wanted to look at what impacts we will see when re-seeds do occur. We didn’t do the reseeding under load, so this is a best case scenario:
- Steady 40% network util on a 1GB/s link during reseeding
- DB of 575GB and Index of 250GB took 6 hours and 15 minutes to seed both DB and index. This factors to approx 2.2GB/minute for a single DB.
We also covered some specific design guidelines for virtualizing Exchange 2010 on the EMC Symmetrix VMAX which were addressed and the specific disk design layout that was calculated based on our Proven guidance with sizing for Exchange 2010. Virtual provisioning is also key in this solution and we layed out some of the design considerations when planning for thin pool design on VMAX:
- Thin pool for Exchange Mailbox Role is recommended – provides a much more granular design and allows for easier troubleshooting and perf analysis if needed.
- Use large Data Devices (120-240GB for thin pools)
- Use concatenated Thin Device Metas – as data devices are already striped in the disk group
In our case, we use thin pools per Exchange Mailbox role and each thin pool was supported via a Disk group with 16-600GB 10k FC disks and a 240GB data devices were used with R5 (7+1) protection.
We also really wanted to show some performance and functionality testing with EMC Replication Manager and EMC TimeFinder for Symmetrix to show how we perform with snapshots of Passive DBs in the DAG. These provide our point-in-time and roll-forward restores in the event of what is usually the most common form of corruption which is logical. A single Replication Manager mount host was used in the case to run the RM Management console and provide the VSS requestor function for our snapshots. The following diagram shows our strategy for snaps of the passive DAG copies:
Snapshots are great, but how well do they perform. With VSS snapshots, usually the most time consuming part is the Consistency check. With 2 copy DAG, consistency checks are less important because checks are already being done as log files are being copied to the other host so we worry less about physical corruption. Microsoft mentions this in the “VSS Frequently Asked Questions” with Exchange 2010 at: http://msdn.microsoft.com/en-us/library/aa579091(EXCHG.140).aspx
In our case, we wanted to show some of the job timings we observed in our testing:
- Each RM job contained 2.53 TB of Exchange data
- Consistency checks were performed on snaps of passive copy to determine impact (as mentioned above it is not as much of an issue to skip daily consistency checks when you have a 2 copy DAG). We say best practice to one run per week.
Another question that we addressed in how much snap space is required to protect the Exchange data. We measured the amount of space required over a 48 hour period and took snaps against 24 passive copies over 6-hour increments when LoadGen was running. Snap space for single DB and log Lun was around 2% a day, and data change rates also come into play. We saw about a 5% change rate.
Finally, 3 test scenarios were run with LoadGen to test overall performance of the solution under varying conditions:
- Test 1 – Normal operation – Very Heavy LoadGen load against 20,000 active mailboxes and taking snapshot off passive DAG copy
- Test 2- Mailbox Role down – Very Heavy LoadGen load against 20,000 active mailbox with single MBX server down
- Test 3- Consistency check running on passive – Loadgen against passive, and run for 24 hours during consistency check
In summary, we proved that the solution provides outstanding performance, enabling large mailbox with virtual provisioning on the VMAX and leveraging space-saving TimeFinder snapshots, along with the strong integration with Exchange 2010 via EMC Replication Manager. Virtualizing Exchange 2010 with VMWare vSphere provides a solid solution where you can consolidate Exchange roles and provide HA with Exchange DAGs.
You can find the full Proven Solutions Guide at: http://www.emc.com/collateral/software/technical-documentation/h7392-virtual-exchange-vmax-vsphere-psg.pdf
Until next time,
The idea of large mailboxes with low costs disks is something Microsoft loves to promote with Exchange 2010. We are all well aware of the I/O improvements with ESE in Exchange 2010 and the use of large SATA disks has made the large mailboxes a reality for customer who prefer SATA over FC or SAS disks for their cost efficiency and growing capacity.
In May of this year, EMC’s Iomega division released the StorCenter IX12-300r Network Storage Array which is aimed at small to medium business customers. The base configuration starts at 4TB and can be expanded up to 24TB in a single array in either a file or block level (iSCSI) configuration.
Due to the low cost, but large capacity of the IX12 we decided that these would be a great platform to show how well Exchange 2010 can work with low cost storage enabling large mailboxes that customers want. The initial result was our Exchange Solutions Reviewed Program (ESRP) submission for 260 users on the IX12 where we showed a building block for 260 users with 10GB mailboxes in a 3 HA copy Database Avaliability Group. Yes, even small to medium customers can have large mailboxes and HA/DR!
The ESRP for the IX12 was a great start, but we wanted to take it further into a more capable configuration up to 1000 users and show how we could push the IX12 farther and showcase how several IX12′s could be put together in a Site Resilient configuration with large 4GB mailboxes and in an Exchange Native Data Protection scenario (i.e. backupless) with Lagged copies for point in time protection. Oh yeah, we also wanted to show how Exchange 2010 would be virtualized in a low cost Microsoft Windows 2008 R2 Hyper-V environment for customers who have made the decision to virtualize Exchange with Hyper-V.
The result is contained in a new whitepaper that we just released called “EMC Business Continuity for Exchange 2010 Enabled by EMC Iomega IX12-300r and Microsoft Database Avaliability Groups”
The physical environment that we designed in this Solution looks like this:
Some of the key proof points contained in this whitepaper are how both HA and Lagged copies can be distributed across mailbox roles and how the Site Resiliency process works with DAC enabled.
This is something that is commonly misunderstood and we show you how we did the testing to simulate a site failure. The other thing we captured is what we saw with DAG seeding performance and this testing from both and local and remote scenario.
For instance, we saw in a local failure scenario that a user was back online after a single server failure in 21 seconds. Jetstress performance for this array was also very good as achieved transactional IOPS/sec were around the 76-80 per server mark with read and write latency between 15-17ms.
Overall, we were very pleased with the results from this Solution and the findings show that even with a low cost array like the StorCenter IX12 with a powerful hypervisor like Microsoft Hyper-V, it can be a very cost effective and powerful solution for Exchange 2010 to enable a large mailbox experience with HA and DR capability, even for the small to medium sized customer. The StorCenter comes in about 4-5k retail, so check with your favorite reseller on these.
If you want to read more, please see the detailed whitepaper at: http://www.emc.com/collateral/hardware/white-papers/h8035-business-continuity-exchange-iomega-wp.pdf
Until next time,