You are currently browsing the tag archive for the ‘microsoft’ tag.
Short Answer: Yes!
In my dealings with customers I’ve been requesting performance data from their storage systems whenever I can to see how different applications and environments react to new features. Today I’m going to give you some more real-world data, straight from a customer’s production EMC NS480.
I’ve pulled various stats out of Analyzer for this customer’s Exchange server, which has 3 mail databases totaling about 1TB of mail stored on the NS480 via FibreChannel connect. Since this customer is not extremely large (similar to most of our customers) they are using this NS480 for pretty much everything from VMWare, SQL, and Exchange, to NAS, web/app content, and Business Intelligence systems. There is about 30TB of block data and another 100TB of NAS data. FASTCache is enabled for all LUNs and Pools with just 183GB of usable FASTCache space (4 x 100GB SSDs). So in this environment, with a modest amount of FASTCache and very mixed workload, how does Exchange fare?
Let’s first take a look at the Exchange workload itself for a 24 hour period: (Note: There were no reads from the Exchange log LUNs to speak of so I left that out of this analysis.)
Total Read IOPS for the 3 databases: (the largest peak is a result of database maintenance jobs and the smaller peaks are due to backup jobs) Here it’s tough to see due to the maintenance and backup peaks, but production IO during the work day is about 200-400IOPS. By the way, a source-deduplicating incremental-forever backup technology, such as Avamar, could drastically reduce the IO Load and duration of the nightly backup
Total Write IOPS for the 3 databases: Obviously more changes to the database occurring during the work day.
Total Write IOPS for the 3 Log files: Log data is typically cached easily in the SP cache so FAST Cache isn’t terribly required here but I’m including it to show whether there is any value to using FASTCache with Exchange logs.
Now let’s look at the FASTCache hit ratios for this same set of data: (average of all 3 DBs)
First, the Read Activity: Here you can see that aside from the maintenance and backup jobs, FASTCache is servicing 70-90% of the Read IOPs. Keep in mind that a FASTCache miss could still be a Cache Hit if the data is in SP Cache. What’s interesting about this is that it looks like the nightly maintenance job is pushing the highest load.
And the Write Activity: The beauty of EMC’s FASTCache implementation being a read/write cache, the benefit extends beyond just read IO. Here you see that FASTCache is servicing 60-80% of the writes for these Exchange Databases. That’s a huge load off the backend disks.
And the Log Writes: Since Log writes are usually not a performance problem, I would say that FASTCache is not necessary here, and the average 30% hit ratio shown here is not great. If you wanted to spend the time to tune FASTCache a bit, you might consider disabling FASTCache for Log LUNs to devote the FASTCache capacity to more cache friendly workloads.
All in all you can see that for the database data, FASTCache is servicing a significant portion of the user generated workload, reducing the backend disk load and improving overall performance.
Hopefully this gives you a sense of what FASTCache could do for your Exchange environment, reducing backend disk workload for reads AND writes. I must reiterate, since an SP Cache hit is shown as a FASTCache miss, an 80% FASTCache hit ratio does not mean that 20% of the IOs are hitting disk. To illustrate this, I’ve graphed the sum of SP Cache Hits and FAST Cache Hits for a single database. You can see that in many cases we’re hitting a total of 100% cache hits.
Most interesting is the backup window where SP Cache is really handling a huge amount of the load. This is actually due to the Prefetch algorithms kicking in for the sequential read profile of a backup, something CX/VNX is very good at.
(Warning: This is a long post…)
You have a critical application that you can’t afford to lose:
So you want to replicate your critical applications because they are, well, critical. And you are looking at the top midrange storage vendors for a solution. NetApp touts awesome efficiency, awesome snapshots, etc while EMC is throwing considerable weight behind it’s 20% Efficiency Guarantee. While EMC guarantees to be 20% more efficient in any unified storage solution, there is perhaps no better scenario than a replication solution to prove it.
I’m going to describe a real-world scenario using Microsoft Exchange as the example application and show why the EMC Unified platform requires less storage, and less WAN bandwidth for replication, while maintaining the same or better application availability vs. a NetApp FAS solution. The example will use a single Microsoft Exchange 2007 SP2 server with ten 100GB mail databases connected via FibreChannel to the storage array. A second storage array exists in a remote site connected via IP to the primary site and a standby Exchange server is attached to that array.
- 100GB per database, 1 database per storage group, 1 storage group per LUN, 130GB LUNs
- 50GB Log LUNs, ensure enough space for extra log creation during maintenance, etc
- 10% change rate per day average
- Nightly backup truncates logs as required
- Best Practices followed by all vendors
- 1500 users (Heavy Users 0.4IOPS), 10% of users leverage Blackberry (BES Server = 4X IOPS per user)
- Approximate IOPS requirement for Exchange: 780IOPS for this server.
- EMC Solution: 2 x EMC Unified Storage systems with SnapView/SANCopy and Replication Manager
- NetApp Solution: 2 x NetApp FAS Storage systems with SnapMirror and SnapManager for Exchange
- RPO: 4 hours (remote site replication update frequency)
Based on those assumptions we have 10 x 130GB DB LUNs and 10 x 50GB Log LUNs and we need approximately 780 host IOPS 50/50 read/write from the backend storage array.
Disk IOPS calculation: (50/50 read/write)
- RAID10, 780 host IOPS translates to 1170 disk IOPS (r+w*2)
- RAID5, 780 host IOPS translates to 1950 disk IOPS (r+w*4)
- RAIDDP is essentially RAID6 so we have about 2730 disk IOPS (r + w*6)
Note: NetApp can create sequential stripes on writes to improve write performance for RAIDDP but that advantage drops significantly as the volumes fill up and free space becomes fragmented which is extremely likely to happen after a few months or less of activity.
Assuming 15K FiberChannel drives can make 180 IOPS with reasonable latencies for a database we’d need:
- RAID10, Database 6.5 disks (round up to 8), using 450GB 15K drives = 1.7TB usable (1 x 4+4)
- RAID5, 10.8 disks for RAID5 (round up to 12), using 300GB 15K drives = 2.8TB usable (2 x 5+1)
- RAID6/DP, 15.1 disks for RAID6 (round up to 16), using 300GB 15K drives = 3.9TB usable (1 x 14+2)
Log writes are highly cachable so we generally need fewer disks; for both the RAID10 and RAID5 EMC options we’ll use a single RAID1 1+1 raid group with 2 x 600GB 15K drives. Since we can’t do RAID1 or RAID10 on NetApp we’ll have to use at least 3 disks (1 data and 2 parity) for the 500GB worth of Log LUNs but we’ll actually need more than that.
Picking a RAID Configuration and Sizing for snapshots:
For EMC, the RAID10 solution uses fewer disks and provides the most appropriate amount of disk space for LUNs vs. the RAID5 solution. With the NetApp solution there really isn’t another alternative so we’ll stick with the 16 disk RAID-DP config. We have loads of free space but we need some of that for snapshots which we’ll see next. We also need to allocate more space to the Log disks for those snapshots.
Since we expect about 10% change per day in the databases (about 10GB per database) we’ll double that to be safe and plan for 20GB of changes per day per LUN (DB and Log).
NetApp arrays store snapshot data in the same volume (FlexVol) as the application data/LUN so you need to size the FlexVol’s and Aggregates appropriately. We need 200GB for the DB LUNs and 200GB for the Log LUNs to cover our daily change rate but we’re doubling that to 400GB each to cover our 2 day contingency. In the case of the DB LUNs the aggregate has more than enough space for the 400GB of snapshot data we are planning for but we need to add 400GB to the Log aggregate as well so we need 4 x 600GB 15K drives to cover the Exchange logs and snapshot data.
EMC Unified arrays store snapshot data for all LUNs in centralized location called the Reserve LUN Pool or RLP. The RLP actually consists of a number of LUNs that can be used and released as needed by snapshot operations occurring across the entire array. The RLP LUNs can be created on any number of disks, using any RAID type to handle various IO loads and sizing an RLP is based on the total change rate of all simultaneously active snapshots across the array. Since we need 400GB of space in the Reserve LUN Pool for one day of changes, we’ll again be safe by doubling that to 800GB which we’ll provide with 6 dedicated 300GB 15K drives in RAID10.
At this point we have 20 disks on the NetApp array and 16 disks on the EMC array. We have loads of free space in the primary database aggregate on the NetApp but we can’t use that free space because it’s sized for the IOPS workload we expect from the Exchange server.
In order to replicate this data to an alternate site, we’ll configure the appropriate tools.
- Install Replication Manager on a server and deploy an agent to each Exchange server
- Configure SANCopy connectivity between the two arrays over the IP ports built-in to each array
- In Replication Manager, Configure a job that quiesces Exchange, then uses SANCopy to incrementally update a copy of the database and log LUNs on the remote array and schedule for every 4 hours using RM’s built in scheduler.
- Install SnapManager for Exchange on each Exchange server
- Configure SnapMirror connectivity betweeen the two arrays over the IP ports built-in to each array
- In SnapManager, Configure a backup job that quiesces Exchange and takes a Snapshot of the Exchange DBs and Logs, then starts a SnapMirror session to replicate the updated FlexVol (including the snapshot) to the remote array. Configure a schedule in Windows Task Manager to run the backup job every 4 hours.
Both the EMC and NetApp solutions run on schedule, create remote copies, and everything runs fine, until...
Tuesday night during the weekly maintenance window, the Exchange admins decide to migrate half of the users from DB1, to DB2 and DB3 and half of the users from DB4, to DB5 and DB6. About 80GB of data is moved (25GB to each of the target DBs.) The transactions logs on DB1 and DB4 jump to almost 50GB, 35GB each on DB2, DB3, DB5, and DB6.
On the NetApp array, the 50GB log LUNs already have about 10GB of snapshot data stored and as the migration is happening, new snapshot data is tracked on all 6 of the affected DB and Log LUNs. The 25GB of new data plus the 10GB of existing data exceeds the 20GB of free space in the FlexVol that each LUN is contained in and guess what… Exchange chokes because it can no longer write to the LUNs.
There are workarounds: First, you enable automatic volume expansion for the FlexVols and automatic Snapshot deletion as a secondary fallback. In the above scenario, the 6 affected FlexVols autoextend to approximately 100GB each equaling 300GB of snapshot data for those 6 LUNs and another 40GB for the remaining 4 LUNs. There is only 60GB free in the aggregate for any additional snapshot data across all 10 LUNs. Now, SnapMirror struggles to update the 1200GB of new data (application data + snapshot data) across the WAN link and as it falls behind more data changes on the production LUNs increasing the amount of snapshot data and the aggregate runs out of space. By default, SnapMirror snapshots are not included in the “automatically delete snapshots” option so Exchange goes down. You can set a flag to allow SnapMirror owned snapshots to be automatically deleted but then you have to resync the databases from scratch. In order to prevent this problem from ever occurring, you need to size the aggregate to handle >100% change meaning more disks.
Consider how the EMC array handles this same scenario using SANCopy. The same changes occur to the databases and approximately 600GB of data is changed across 12 LUNs (6 DB and 6 Log). When the Replication Manager job starts, SANCopy takes a new snapshot of all of the blocks that just changed for purposes of the current update and begins to copy those changed blocks across the WAN.
- SANCopy/Inc is not tracking the changes that occur AS they occur, only while an update is in process so the Reserve LUN Pool is actually empty before the update job starts. If you want additional snapshots on top of the ones used for replication, that will increase the amount of data in the Reserve LUN Pool for tracking changes, but snapshots are created on both arrays independently and the snapshot data is NOT replicated. This nuance allows you to have different snapshot schedules in production vs. disaster recovery for example.
- Because SANCopy/Inc only replicates the blocks that have changed on the production LUNs, NOT the snapshot data, it copies only half of the data across the WAN vs SnapMirror which reduces the time out of sync. This translates to lower WAN utilization AND a better RPO.
- IF an update was occurring when the maintenance took place, the amount of data put in the Reserve LUN pool would be approximately 600GB (leaving 200GB free for more changed data). More efficient use of the Snapshot pool and more flexibility.
- IF the Reserve LUN Pool ran out of space, the SANCopy update would fail but the production LUNs ARE NEVER AFFECTED. Higher availability for the critical application that you devoted time and money to replicate.
- Less spinning disk on the EMC array vs. the NetApp.
EMC has several replication products available that each act differently. I used SANCopy because, combined with Replication Manager, it provides similar functionality to NetApp SnapMirror and SnapManager. MirrorView/Async has the same advantages as SANCopy/Incremental in these scenarios and can replicate Exchange, SQL, and other applications without any host involvement.
Higher Application availability, lower WAN Utilization , Better RPO, Fewer Spinning Disks, without even leveraging advanced features for even better efficiency and performance.