0

Seeing as this is my first design, I'm hoping to make sure I haven't missed any glaring issues before deployment.

enter image description here

7
  • Why are you creating separate LUN's? Why not just present the entire vDisk as a single LUN to your pair of hypervisors and create the virtual hard drives for each VM from that? I'm thinking that not may people carve it up the way you have in your diagram.
    – joeqwerty
    Sep 3, 2015 at 20:23
  • All the reading material I was finding talked about carving out the LUNs for both performance and backup administration. But I'll admit it was hard to find documentation directly referring to an implementation this small. Sep 3, 2015 at 20:32
  • I've never seen anyone carve out LUN's for specific virtual machines. I also don't see how there'd be any performance benefit as the LUN's are all carved out of the same underlying vDisk. If you had separate vDisks then possibly. If you're really talking about separating the I/O between the database drive and the log file drive then you've achieved that at the virtual hard disk level in each VM, there's no need to do it at the LUN level, and again, probably doesn't achieve anything at that level. Additionally you may be "locking" yourself in by doing it at the LUN level.
    – joeqwerty
    Sep 3, 2015 at 20:39
  • I did wonder that myself too. Maybe that specific issue wasn't being addressed in what I was reading. So maybe a better way to go would be 1 big old LUN and then separate VMFS partitions presented to the servers? Sep 3, 2015 at 20:45
  • Present it as a single LUN to the hypervisors and provision it as a single datastore on the hypervisors. Then carve it up as separate VMDK's at the virtual machine level. Of course, this is just my opinion. Let's see if anyone else weighs in on your design.
    – joeqwerty
    Sep 3, 2015 at 20:48

2 Answers 2

1

The Exchange Team's preferred architecture (PA) for Exchange 2013 includes these quotes:

the cost and complexity of the SAN based storage system that was at the heart of Exchange until the 2007 release, drove the Exchange Team to step up its investment in the storage stack and to evolve the Exchange application to integrate the important elements of storage directly into its architecture. We recognized that every SAN system would ultimately fail, and that implementing a highly redundant system using SAN technology would be cost-prohibitive. In response, Exchange has evolved from requiring expensive, scaled-up, high-performance SAN storage and related peripherals, to now being able to run on cheap, scaled-out servers with commodity, low-performance SAS/SATA drives in a JBOD configuration with commodity disk controllers. This architecture enables Exchange to be resilient to any storage related failure, while enabling you to deploy large mailboxes at a reasonable cost.

[..]

Physical hardware is deployed rather than virtualized hardware for two reasons:

Virtualization adds an additional layer of management and complexity, which introduces additional recovery modes that do not add value, as Exchange provides equivalent functionality out of the box.

By having virtual machines which can failover and external SAN storage, but then layering Exchange DAGs on top, you aren't necessarily getting "more better", but you're certainly getting "more complex and costly and more overhead".

By having two physical servers, two virtual servers, you're doing a lot of separation, but then you're backing everything with the same RAID5 vDisk, which removes some of the point of separate Exchange servers - if the storage fails, both your redundant servers go down. It also adds some IO contention - your writes will go to the database, to the database logs, and then be replicated to another database and another database log, all writing to the same RAID5 and generating logs on the same drives as well. Have you made any IOPS or email throughput estimates?

There's quite a lot of disks in your setup so that might not be a bottleneck - but out of the 13TB available in the vDisk, your LUNs for Exchange only add up to 1.5TB. Does that mean you're planning to have 11.5TB of unrelated virtual machines on the same disks?


35-40 users. 120 mailboxes. >10GB mailbox size. and 500GB Exchange Database drives, each with a live DB and a copy? Because that looks like they will be more than full right from the start.

4
  • Both the DL380s will host other VMs besides Exchange. As for the DAG, is having shared storage a reason NOT to have a DAG? I was required to design the system to have 1 operational server even if the other was taken offline for any reason. I had read that doing VM fail-over wasn't a good idea for Exchange so it seemed a DAG was a logical way to go. I do get the failure point tho. Also, the sizing looks odd because the majority of the mailboxes are very small. I just needed to accommodate the outliers. Sep 3, 2015 at 22:42
  • Is there any better way you see structure the exchange setup with the hardware above? Its all I have at my disposal and its intended to host quite a few VMs. Sep 3, 2015 at 22:49
  • I don't think it's a reason NOT to have a DAG. HA crash-and-reboot isn't ideal, but ... you could restore a 350Gb virtual machine from backup in what, 1-4 hours? You're buying 2x disk space, 2x Exchange licenses, Windows Enterprise licenses for clustering (if you aren't buying datacenter for each vhost), a more complex install, more effort to maintain. To avoid a low probability 4-hour outage for 40 users? On a system which already has host redundancy, disk redundancy, and more? Isn't it thousands of dollars of overkill? But if the spec says two and they want to pay for that... Sep 3, 2015 at 23:21
  • Heh, you won't get any argument from me that there is an odd prioritization there. That email delivery is considered to be the holy grail and such. But hey, if they are happy that I can provide exactly what is asked for then its a win. Sep 4, 2015 at 0:52
0

According to Ignite's Exchange Server Preferred Architecture there's no point of doing DAG at your situation. Simply put - Underlying infrastructure beats the sole purpose of the DAG. Have you considered Office365 for such deployment? By the time you finish paying for 2xExchange and CAL licenses the client would probably start migration to the next version of Exchange (not 2016, the next one). If you are going the host a lot of VMs there, perhaps it would be worth while to consider assigning the vCPU and vMemory resources to several other VMs? Exchange is a memory-beast. It always was and always will be the case. The next version uses more memory than a previous one, it was always been like that.

P.S. Viewing the presentation is highly recommended, it will provide a clear picture on how to treat and groom Exchange.

1
  • I pitched the cloud solution first. No go there. I'll have a look at the provided link. I've become pretty torn on the storage layout over the last couple days. I really want to break up the storage into a few different RAID groups so the DAG makes more sense. I'm just pretty apprehensive about decreasing the overall IOPS if I go that route. Sep 8, 2015 at 16:27

Not the answer you're looking for? Browse other questions tagged .