Planning and migrating a small organization from Exchange 2007 to 2013 (Part 7)

By /

If you would like to read the other parts in this article series please go to:

Introduction

In the previous parts to this series we began our journey to migrate from Exchange 2007 to Exchange 2013, beginning with investigating what we’ve got to contend with in our existing environment.

With that valuable information, we’re now ready to look at what needs to be done next when planning the Exchange 2013 deployment. We’ll start the next two parts in this series by using the information gathered during discovery along with business inputs to define what will be required from our upgraded Exchange environment.

Planning for Deployment

Exchange Server Sizing

In the previous part to this series, we’ve already covered the Environment Configuration and Mailbox Configuration sections of the Exchange 2013 Server Role Requirements calculator. We’ll continue with the remaining input sections.

Role Requirements Input Factors – Backup Configuration

As the solution we’re designing is for a smaller organization and for the purposes of this series won’t use Database Availability Groups, we’ll be performing backups of Exchange. As mentioned previously the virtual environment the solution is based upon uses Exchange-aware backups to provide backup and restore functionality.

Therefore we’ll need to ensure these parameters are factored in. As the solution we’re using (Veeam) works at the storage subsystem level we’ll choose Hardware VSS Backup/Restore for the Backup Methodolpgy, and for the Backup Frequency, we’ll choose Daily Full to reflect how our backup software is configured to work.

The next two questions relate to how long an administrator would reasonably expect to have to deal with a case of failed backups or network issues preventing the backups from working. This is one area to edge on the side of caution with and especially in the case of a smaller organization think about how long it’s actually reasonable to expect a backup failure to take to fix. For example, if you’re the only administrator of the solution and the whole office takes a week off for Christmas, then you don’t want a backup failure to cause Exchange to stop working while everyone’s away because it’s run out of space to keep log files. Additionally, it might take another few days after you return to the office to get a support call resolved with the backup vendor.

Based on the above, we’ve chosen to be pretty cautious and specify a Backup/Truncation Failure Tolerance of 14 days. If you think there might be a longer Network Failure that prevents backups, specify the value in the subsequent field:

Image
Figure 1: Backup Configuration

As an afterthought – a backup failure of two weeks would be fairly undesirable and if you’re expecting that to happen, then it might be time to consider some additional monitoring software to make sure that a failure doesn’t go unnoticed for that amount of time!

Role Requirement Factors – Storage Configuration

For both this section and the next, we’ll refer back to the Target Hardware information we determined in the previous part of this series. As you’ll no-doubt remember, we’ve got 3.5″ 2TB 7200RPM SAS disks available for this deployment. We’ll enter these in the Primary Datacenter Server Disk Configuration Section:

Image
Figure 2: Primary Datacenter Disk Configuraton

Naturally, if you’re using a different mix of disks, then make sure you enter appropriate values here. The key thing we’re aiming to do is ensure that the calculator knows what underlying storage is available so it can determine not only if enough space is available, but also how many disks are required to deliver the right performance. For example if the Databases will fit within a single pair of our disks, but the calculator recommends 10 disks for the Databases, this is your first indication that it might be better for you to re-evaluate the type of disks you are using. For most Exchange 2013 implementations 7200RPM SAS or SATA disks will be fine.

You’ll notice we’ve not touched upon the Storage Options and Secondary Datacenter Disk Configuration sections. As we’re deploying a smaller organization with a single server the calculator already knows the questions in these sections are irrelevant as they relate to Database copies and secondary datacenters and can be safely ignored.

Role Requirement Factors – Processor Configuration

From our Target Hardware information we’ll input our total Processor Cores per Server and the SPECint2006 rate value and enter them into the Mailbox Server Guest Machines question:

Image
Figure 3: Server Configuration

Finally, for virtual environments we’ll adjust the Hypervisor CPU Adjustment Factor. This value takes into account the overhead the Hypervisor places on the CPU – after all within a virtual environment you don’t get the full use of the resources the physical server possesses. By default this value is a recommended default for Hyper-V environments. VMware don’t provide similar guidance, and leave the customer to determine this. For our virtual environment (which is on vSphere) we’ll leave the 10% default:

Image
Figure 4: Processor Configuration

Reviewing the Role Requirements

After entering information into the Input worksheet of the calculator, we can now examine the output from the tool. Our first point of call is the Role Requirements worksheet.

What we’ll look for here is some key information that will help validate our input, perhaps make us look at different options and use to determine the requirements for the machine that will act as our Exchange 2013 server. Before we continue, take a moment to read through each section so you are familiar with the output.

We’ll have a look in the Server Configuration section to determine the RAM required, and in the case of a virtual machine, the minimum number of Virtual CPU cores required. You’ll find this within Server Configuration:

Image
Figure 5: Role Requirements for Server Configuration

Bear in mind the 4 CPU cores above are the minimum that will be utilized by our multi-role server. You may want to increase this to ensure you’ve got more overhead to account for unexpected load. We’ll go with 4 cores, and choose to monitor CPU utilization during testing and increase if necessary – one of the benefits of a virtual environment.

We’ll also see within that section that the location for the Transport Database is highlighted:

Image
Figure 6: Transport DB Location

For most small environments we’ll hope and expect that this will be the System Disk as this means we don’t need to dedicate disks for the transport database and can simply install Exchange onto the system disk (usually C:) of the virtual machine.

You’ll also see the Disk Space Requirements within this section. Feel free to take a quick look, however we’ll come to those in the next section. What we will make note of is the Host IO and Throughput Requirements:

Image
Figure 7: Role Requirements for Host Throughput

The Per Server column tells us the expected IOPs this virtual machine is going to command against the disks. This will be paramount later, when we perform JetStress tests to ensure the storage does indeed meet the requirements.

Volume Requirements

As we being to conclude collecting information from the calculator, we’ll move over onto the Volume Requirements. You’ll see on the left hand side the expected usage of Mailbox Databases on-disk, but the key information we need to play the actual specifications of the servers is the Db and Log Volume Design Per Server table. You’ll see, as shown below, a list of the databases along with the actual volume size required:

Image
Figure 8: Database and Log Volume Requirements

You’ll also see in the top left of the Volume Requirements section the Restore Volume Design.

Image
Figure 9: Recovery Database Requirements

We’ll use these values to work out the disk sizes to use for Exchange. When it comes to Volumes, let’s just take a moment to clear up a few misconceptions about what the calculator means when it says volumes. This does not mean partitions, but instead generally means each volume is something that the Windows Server sees as an entire, actual disk.

From a Virtualization point of view this might mean a VMDK or VHD represent a volume; but from a SAN point of view it can be known as a few things, most commonly a LUN. On RAID storage it’s typical that you’ll create a “RAID group”, or a single, large RAID array, and then use the RAID management software to carve it up into volumes using the SAN or RAID management software.

Storage Design

After reviewing information on the remaining worksheets, we’ll examine the Storage Design worksheet. There’s a fair bit of information here, which if you’re building a Database Availability group is very useful (such as the number of disks you’ll require across all your servers and JBOD storage architecture information).

For our small, single server, the most important information is the headline figures – the number of disks we need to support the Database, Log and Restore Volume requirements:

Image
Figure 10: Disk Requirements for Database, Log and Restore

We’ll see the RAID architecture that’s been automatically chosen along with the disks we chose earlier. The number of disks required will, put simply, depend on two major factors; the performance required and the space required. If, for example two 7.2K RPM disks will provide sufficient performance and space when configured as a RAID 1/0 array, then this may be suggested. However, if more IO is required we may see more disks required to provide enough spindles to support our system leaving a lot of unused space. In this type of situation, you may wish to re-assess the type of disks you use, either using cheaper smaller slow disks, or large, expensive disks that provide better performance. The great thing about using the calculator is you can adjust the settings to try out different disks you have access to, or can consider buying and find the right solution for your deployment.

Our Exchange 2013 Server Specification

We’ll now collate the sizing information and put together the specification for our Exchange Server. First, let’s take a look at the basics – the server name, CPU, RAM, and system disk:

Server Name vCPUs RAM System Disk Size System Disk Drive Exchange Install Location
E15M01 4 32GB 100GB C: System Disk

Table 1

Next, and this is only a recommendation – we’ll specify a separate disk for the Windows Pagefile. Exchange requires the pagefile size to be the installed memory size plus 10MB, therefore a 40GB pagefile volume gives us a little overhead:

Pagefile Requirements Pagefile Volume Size Pagefile drive
32GB+10MB (32778MB) 40GB D:

Table 2

We also require somewhere to store the Exchange databases and log files. First let’s take a look at what we’ve found we need for Exchange Databases and Log Disks:

Required Physical Database   Disks Number of Database Volumes Per Database Volume Size Total Database Volumes Size
4 4 274GB 1096GB
Required Physical Log Disks Number of Log Volumes Per Log Volume Size Total Database Volumes Size
2 4 28GB 56GB

Table 3

And to ensure we’ve got the right information a little later on when we mount these disks, we’ll record the names we’ll use for the mount points. If you’d prefer to use drive letters then do so.

Database 1 Mount Point Database 2 Mount Point Database 3 Mount Point Database 4 Mount Point
C:\ExchangeDatabases\DB01 C:\ExchangeDatabases\DB02 C:\ExchangeDatabases\DB03 C:\ExchangeDatabases\DB04
Database 1 Log Mount Point Database 2 Log Mount Point Database 3 Log Mount Point Database 4 Log Mount Point
C:\ExchangeDatabases\DB01_Log C:\ExchangeDatabases\DB02_Log C:\ExchangeDatabases\DB03_Log C:\ExchangeDatabases\DB04Log

Table 4

Finally, we’ll specify the disk size and mount point we’ll use for the Restore/Maintenance disk:

Restore/Maintenance LUN Size Restore/Maintenance LUN Mount   Point
224GB C:\ExchangeDatabases\Restore

Table 5

With our specification decided upon, the base server can be built, ready for Exchange to be installed. You’ll see our Exchange Server VM below – as you can see we’ve built it to the specification above:

Image
Figure 11: Our base virtual machine within VMware vSphere

Summary

Before we continue and start installing Exchange onto our brand new server, we’ve got a few tasks, which you should have identified during the discovery sections in this series. We’ll cover these at the beginning of the next part in this series and then move onto installing Exchange 2013 pre-requisites.

If you would like to read the other parts in this article series please go to:

About The Author

Steve is a 5 times recipient of the MVP (Microsoft’s Most Valuable Professional) award from Microsoft, is a regular international conference speaker, podcast host, regular blogger, plus he is the author of a number of popular Exchange books. Steve is Head of Messaging and UC at top Office 365 partner Content and Code, responsible for their Exchange and Skype for Business offerings. Steve has worked on a vast number of Exchange and Office 365 projects across customers large and small, often with complex requirements and loves to share his expertise.

Read Next

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top