So, the calculator is now out in the wild to help you size your Exchange 2013 servers to cope with messaging traffic for your new implementation. But if you’ve been reading up on the new sizing, then you’ll know things have changed a fair bit. In short, it’s more CPU intensive, needs more RAM but has lower IO requirements.
The first point of note is simple – if you’re looking to do a direct comparison between a deployment on Exchange 2010 and Exchange 2013, then you might find yourself slightly disappointed and won’t necessarily see the benefits.
A case in point is smaller deployments. Using the calculator, I’ve looked at a (reasonably common) Exchange 2010 virtualized deployment sizing and directly compared it to the requirements for Exchange 2013. A really small virtual deployment for a few hundred users would take maybe 8GB RAM, need a couple of virtual CPUs and IOPs would not be an issue because the supporting SAN has more IO than is needed.
Deployments like this – the kind where you have 2-3 Hypervisor hosts sitting on a NetApp, will not see major hardware benefits with Exchange 2013, because they don’t have any characteristic that taxes the hardware to any limits already. The only major change between the sizing between Exchange 2010 and 2013 was the memory, which jumped to 24GB.
So, the rule of thumb for the small deployment on a virtual infrastructure is simple – make sure the Hypervisor host has more memory. If you’d have specified 64GB RAM for each Hypervisor host, then you’ll probably need 96GB RAM. It won’t cost a lot more, but you’ll get Exchange 2013 features. Just remember, you’ll probably want an Office Web Apps server too.
However organizations considering such a small deployment might want to weigh up the costs of moving to Exchange Online (starting at £2.60 per user a month!)
As you scale up, you’ll really start to see the benefits of Exchange 2013. In Exchange 2010, the option of JBOD was there and still is, however re-seeding databases after failed disks certainly put many off. Therefore, a good, safe option was to use RAID 10 or RAID 1 sets for Databases and Logs, using up to around 2TB MDL SAS/SATA direct-attached storage.
This is where it starts to get interesting with Exchange 2013. Pretty much any organization considering a DAG should now really use JBOD, thanks to Auto Reseed – a feature that replicates the easy automation so many love about hardware raid (i.e. online spares, automatic re-build of disks after a failure).
Because JBOD probably should be your starting point, you get to save money on disks. In Exchange 2010 you could have 2TB disks with 1 database/log set per disk. You can now have up to 4TB disks, with multiple database/log sets per disk with Exchange 2013 JBOD. Therefore, we’ve got a great opportunity to use a LOT less disks.
Because you’re using less disks, you can in many cases look to design for building-block server storage. No expensive DAS arrays hanging off the back, just something like HP Proliant DL380 G8s with 12 4TB disks per server. 2x4TB disks as system volumes and the rest for JBOD.
My comparison for you here is a slightly larger environment, 2000 mailboxes running on physical hardware.
On Exchange 2010, the theoretical design went for multi-role servers using RAID 10 with a single-site DAG with two nodes (each with 6 cores, 16GB RAM) and 2 database copies. This results in 110 disks across the two nodes. We’d backup Exchange using VSS to more storage somewhere else.
On Exchange 2013, we re-think the design slightly and go for JBOD with again, a single site DAG with 4 nodes (same 6 cores and 16GB RAM per node) and 3 database copies. We dispense with traditional backups. This results in 36 disks.
Yes, you read that right. 36 disks in Exchange 2013, versus 110 disks in Exchange 2010. As well as using 74 fewer disks we also get an additional database copy and the ability to dispense with expensive, traditional backups.
As you can see, that’s a great result:
Exchange 2013 for small deployments in virtual environments is fine. You’ll need to use a bit more RAM, but it’s still viable, however Exchange Online certainly becomes slightly more attractive. Exchange 2013 for larger deployments versus Exchange 2010.. It’s a no brainer!
Download the Exchange 2013 Server Role Requirements Calculator from here. Just remember – think different!
I’m pleased to announce that our first UC Architects app is now available! Programmed by Johan Veldhuis, one of the crew, you can download each episode or listen and stream online.
You’ll also find links to each of our websites and of course our twitter stream. It’s a version 1.0 so if you find any bugs, just let us know and we’ll hopefully get them fixed!
My latest SearchExchange.com article is now online. In this article, I’ll show you how to configure one of the important add-ons for Exchange 2013 (and SharePoint and Lync 2013 too), Office Web Apps Server.
Office Web Apps Server represents a way for users to access Web-browser-based versions of Word, Excel, PowerPoint and OneNote within OWA. This tip discusses why it's important, requirements for implementation and also details how to build a small Office Web Apps infrastructure and integrate it with Exchange Server 2013.
You’ll find great code snippets and short tips on MSExchange.org within the Knowledgebase section. My latest three are now available:
Reducing the Office 365 DirSync Schedule
Sometimes the default 3-hour DirSync schedule is not often enough. This quick tip explains how to reduce the sync schedule to something that better fits your organization:
Performing Maintenance on Office 365 DirSync
After DirSync has been running for a while, advanced users who access the FIM GUI might notice that the logs start to increase in volume. This script shows you how to keep things under control:
Scheduling an Exchange PowerShell Task
A quick simple tip here for anyone that needs to schedule an Exchange PowerShell script as a task. As you’ll see, it’s quite simple and easy, so if you need to regularly get a data export, this script is for you:
If you’ve been following my series, Migrating a standalone Office 365 tenant to Exchange 2010, you’ll be pleased to know the final two parts of the series, part seven and part eight are now available. This completes the series and hopefully will be useful if you find the need to bring an Exchange Online tenant back on-premises.
The parts of the series are listed below:
- Migrating a standalone Office 365 tenant to Exchange 2010 (Part 1)
- Migrating a standalone Office 365 tenant to Exchange 2010 (Part 2)
- Migrating a standalone Office 365 tenant to Exchange 2010 (Part 3)
- Migrating a standalone Office 365 tenant to Exchange 2010 (Part 4)
- Migrating a standalone Office 365 tenant to Exchange 2010 (Part 5)
- Migrating a standalone Office 365 tenant to Exchange 2010 (Part 6)
- Migrating a standalone Office 365 tenant to Exchange 2010 (Part 7)
- Migrating a standalone Office 365 tenant to Exchange 2010 (Part 8)