If you don’t know when you’re about to run out of disk space on the log LUN, you’re totally doing it wrong. It leaves me slack-jawed with astonishment that in 2012 we still have administrators who suffer unplanned downtime due to log volumes filling up because of poor design or problems with backups. Stop the madness! Check your backups regularly and use monitoring, be it however primitive, to ensure that you don’t have this problem.

Paul is referring to this post on the MS Exchange Team blog, which mentions that:

…the number one reason why our Premier customers open Exchange 2010 critical situations is because Mailbox databases dismount due to running out of disk space on the transaction log LUN.

Either I missed that post when it was published a few months ago or I glossed over it and it didn’t catch my attention enough.

I’ve been stung by transaction log disks running out of space, even as recently as last year. I work in a very large Exchange environment where backups and storage monitoring are performed by two different teams, both of them outside of my team.

That puts us in the situation where failed backups, combined with either a storage monitoring problem or a human error in the escalation processes can (and has) caused a log volume to fill up. Another situation that can arise is when new servers are provisioned, our help desks begin putting mailboxes on them before they’ve been added to the backups.

Which is why I wrote this script to check the Exchange database backups and alert my team when they have not been backed up in the 48 hours or more. In fact that script is a better version than the one we run in production (I haven’t ported over the improvements I later made at home to the original).

Ever since we put it in place that script has alerted us to numerous situations before they could evolve into disasters.

Setting it up as a scheduled task to run daily is a job that will take you less than half an hour. I highly recommend it, not just because I wrote the script, but because it adds a valuable layer of protection to your environment.

Related posts:

• How to Set Up an Automated Exchange 2010 Database Backup Alert Email
• PowerShell Script: Check Exchange Mailbox Database Last Backup Time
• How to Health Check an Exchange 2010 Mailbox Server
• PowerShell Script: Check Exchange 2010 Database Backups
• Exchange 2010: Are Passive Database Copies Included in Backups of DAG Members?

This article Avoid Running Out of Transaction Log Disk Space on Exchange Servers is © 2012 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

Plenty of articles have been written about this so I won’t revisit the issue in much detail, except to summarise with these points:

• Disk storage technology has basically plateaued in speed capabilities (ie, disks aren’t getting faster)
• Disk storage technology is a lot cheaper in high capacity, lower performance types (eg SATA II, SAS)
• The previous Exchange database engine used a schema that permitted SIS but did not permit further optimization of performance (specifically, allowing sequential reads)
• Removing SIS and redesigning the database schema to permit sequential reads resulted in massive performance improvements (as much as 70% less disk IO for typical behaviour)

Does This Mean More Exchange Storage?

The major concern from Exchange Server customers was the impact this would have on their Exchange storage requirements.  If SIS is removed, does that mean more disk and tape storage is going to be required?  Especially as more and more organizations are already moving to larger mailboxes?

Furthermore, is that increase going to be exponential because of the increasing popularity of disk duplication (eg SAN mirroring) and the nature of Exchange Server 2010 Database Availability Groups (multiple database copies across many servers)?

Short answer, yes.  All of those storage requirements are likely to increase when your organization moves to Exchange Server 2010.

How Much More Storage is Needed?

In real world migrations I have seen mailbox databases grow by between 20% and 50% just from moving all of the mailboxes from an Exchange 2003 or 2007 server to Exchange Server 2010.

Similarly, growth of email storage over time also increases by similar factors.

So with that in mind, how can an organization mitigate the risk of storage costs getting out of control when they move to Exchange Server 2010?

Reducing Storage Costs for Exchange Server 2010

Firstly, take advantage of the Exchange Server 2010 database performance improvements by deploying Exchange 2010 on lower cost storage (eg SATA II or SAS instead of 15k SCSI).  Some customers are tempted to use “what we’ve already got” and deploy on their existing high performance SAN, when in reality a smarter move would be to provision the Exchange 2010 mailbox servers with lower cost, lower speed direct-attached storage (DAS) for storing mailbox databases.

Secondly, don’t duplicate Exchange 2010 data unnecessarily.  If you have deployed an Exchange 2010 DAG, don’t also utilize SAN mirroring for mailbox database storage.  Let the Exchange 2010 application-layer replication handle it for you (Exchange 2010 SP1 introduced block-level replication to resolve one of the remaining criticisms of the Exchange 2010 asynchronous file-level replication).

Finally, look to alternative methods of de-duplicating Exchange mailbox data in organizations utilizing large mailboxes.  For example, many backup applications are now including data de-dupe capabilities, as do enterprise-grade email archiving solutions.

Related posts:

• Avoid Running Out of Transaction Log Disk Space on Exchange Servers
• Exchange Server Archiving: Review of GFI MailArchiver
• Exchange Server 2010 Mailbox Server Backup and Recovery
• How to Restore an Individual Exchange 2010 Mailbox with Windows Server Backup
• Outlook 2007 Update Adds Exchange Server 2010 Archiving Support

This article What is the Real Effect of Removing Single Instance Storage in Exchange Server 2010 is © 2010 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

This calculator is an essential part of the Exchange admin’s toolkit and I highly recommend staying up to date with new releases.

The update includes these improvements and new features:

• Added the ability to define a custom number of databases that you would like to implement in the solution.
• Added support for 2-node site resilient Database Availability Groups.
• Added 1 and 6 processor cores as selectable options.
• Improved breakdown of the activation scenarios in a site resilient solution.
• Improved breakout of the role requirements section.
• The Storage Design tab now indicates that when you select a custom RAID configuration that the calculator ignores RAID-5 and RAID-6 for 5.xK and 7.2K spindles due to performance concerns.
• Updated processor utilization results to show the processor utilization even if it is above the recommended threshold.
• Made conditional formatting improvements throughout the calculator to warn you when you have a configuration that will not work.
• Improved various cell comments.

Find out more on their blog post here or download the updated calculator here.

Related posts:

• Avoid Running Out of Transaction Log Disk Space on Exchange Servers
• How to Health Check an Exchange 2010 Mailbox Server
• How to Install Updates on Exchange Server 2010 Database Availability Groups
• How to Set Up an Automated Exchange 2010 Database Backup Alert Email
• Exchange 2010: Are Passive Database Copies Included in Backups of DAG Members?

This article Exchange 2010 Mailbox Server Requirements Calculator Updated is © 2010 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

Link: Microsoft Exchange Server 2007 Storage Considerations: DAS or SAN

Related posts:

• Browsing Mailbox Databases in Exchange 2007 and 2010
• How to Modify Recipient Scope in the Exchange Management Shell
• Configuring the Exchange Server 2007 Product Key
• Project Coconut: Part 2 – Sizing the Exchange Server 2007 servers
• Are you getting enough IOPS in your diet?

This article Video: Exchange Server 2007 storage considerations by EMC is © 2008 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

• Project Coconut: Introduction
• Project Coconut: Part 1 – Getting the environment up to scratch
• Project Coconut: Part 2 – Sizing the Exchange Server 2007 servers
• Project Coconut: Part 3 – Deploying the first Exchange Server 2007 server
• Project Coconut: Part 4 – Configuring Standby Continuous Replication
• Project Coconut: Part 5 – Its mailbox migration time!
• Project Coconut: Part 6 – Finishing the job

Sizing the Exchange Server 2007 Servers

In this post in the Project Coconut series I’ll describe the process that was undertaken for sizing the hardware that will run the Exchange Server 2007 servers.

Microsoft provides extensive guidance on how to calculate your hardware requirements for Exchange Server 2007. If you are embarking on an Exchange Server 2007 project you should familiarise yourself with these resources.

• Planning processor configurations
• Planning memory configurations
• Planning storage configurations
• Mailbox Server role storage calculator

I certainly recommend you read the abovementioned resources, however here are some guidelines that I follow which outlining the bare minimum, recommended, and maximum configurations.

Note that CPU cores refer to modern, server class CPU cores (ie, not your 3 year old Pentium 4 desktop processor). Maximum figures represent the point at which you would consider adding more servers to continue scaling upwards. Although the maximum memory recommendations are below what 64-bit hardware and 64-bit Windows Server are capable of running, they represent the level at which adding more memory is not cost effective due to diminishing returns.

Client Access Server

Hub Transport Server

Mailbox Server

As there are no Unified Messaging or Edge Transport servers involved in this project I have excluded them from this post.

Multi-Role Server

Although the above guidelines are fairly straight-forward, sizing a multi-role Exchange Server 2007 server is a slightly different story. The “Typical” installation of Exchange Server 2007 installs the Client Access, Hub Transport, and Mailbox server roles.

Mailbox Server Memory Recommendations

In the tables above I mention “per-mailbox calculations” for servers that will hold the Mailbox Server role. What this means is that you plan for base amount of memory plus an amount of memory for each mailbox that will be hosted on the server.

The base amounts of memory are calculated using the Microsoft guidance here. Microsoft provides memory sizing guidance right up to the maximum (for Enterprise Edition) of 50 storage groups, but I will reproduce only the first few rows here.

Note that SP1 has some memory utilisation improvements as you scale to more storage groups compared to RTM.

In the case of Project Coconut we are planning for five storage groups, and using Exchange Server 2007 SP1, so the base memory amount is 4Gb.

To apply the per-mailbox memory sizing you use the following Microsoft guidance. Microsoft defines the different user types here.

For Project Coconut we have profiled the users as “Average”, and there are approximately 1000 of them. We also want to provide scalability up to around 1250 users. So, 1300 x 3.5Mb = 4550, divided by 1024 = 4.4Gb.

Base memory for a multi-roled server of 4Gb plus 4.4Gb for up to 1300 mailbox users and rounding it up to an even number brings us to a memory sizing of 9Gb. Both the production and standby servers will be provisioned with this amount of memory.

Storage Recommendations

The recommendations for most server roles are simple – separate the operating system from the application files, and on Hub Transport servers separate the Transport Queue from any other volumes if possible (this is more important in very large environments than it is in smaller environments).

For mailbox servers there is a lot more to consider, so have a read of my post on designing mailbox server storage.

In the next part of Project Coconut I’ll describe the process for introducing the first Exchange Server 2007 server into an existing organisation.

Related posts:

• Exchange 2010 Mailbox Server Requirements Calculator Updated
• Video: Exchange Server 2007 storage considerations by EMC
• Are you getting enough IOPS in your diet?
• Update Rollup 6 for Exchange 2007 SP3 Released
• Avoid Running Out of Transaction Log Disk Space on Exchange Servers

This article Project Coconut: Part 2 – Sizing the Exchange Server 2007 servers is © 2008 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

Storage guys

What are IOPS?

IOPS stands for Input/Output operations Per Second, and is basically a measure of how fast a disk (or disk array) can read and write data to and from a hard disk.

IOPS are somewhat important to your Exchange Server 2007 design because you want to ensure you provide Exchange with an adequate storage configuration to handle the transactional I/O load it will produce in daily operations.

Gross generalisation #1 – in smaller environments you will often find that simply providing enough storage capacity of the usual recommended RAID types will achieve your IOPS needs.

Gross generalisation #2 – in larger environments you will often find that simply providing enough IOPS of the usual recommended RAID types will achieve your storage capacity needs.

What type of RAID do you recommend?

Very simply:

• Transaction Logs – RAID1+0, RAID1, or RAID5 (in that order of preference)
• Databases – RAID5

Where do I get some IOPS then?

Microsoft (once again) has provided extensive guidance on how to plan your Exchange Server 2007 storage design.  Although there are considerations for several of the Exchange Server 2007 roles most often the only role you need to pay very close attention to is the Mailbox Server role.

Here is an example of calculating IOPS requirements for a simple 1000 mailbox environment.  Although in this example the server is multi-role, the Transport queue is on a separate LUN and therefore the Transaction Log and Database LUN IOPS can be calculated without taking it into consideration.

Your first stop should be the Exchange Server 2007 Storage Calculator.  This is an Excel spreadsheet developed by the Exchange Server Team at Microsoft to help customers calculate their storage requirements.

First enter some basic information, such as the version of Exchange you are deploying (in this case SP1), the number of mailbox servers, and whether any continuous replication is being deployed.

Next, enter the type of user profile that best represents the environment.  I have selected 1000 “average” users (10 sent/40 received per day), with a 250mb mailbox limit.

Switch to the “Storage Requirements” tab and you will be presented with the results of the IOPS calculations.

Now we see that the calculator is estimating 206 IOPS for databases, and 68 IOPS for transaction logs.  How can we design a disk layout to provide this?  Lets look at the types of disks we will be using here.

A 10K SCSI disk provides 100 IOPS/disk.  A 15K SCSI disk provides 120 IOPS/disk.  The customer in this example has 15K disks.

When used in a RAID configuration there is an IOPS penalty applied to the calculation as follows:

• RAID 0 – x1.0 penalty
• RAID1/1+0 – x0.8 penalty
• RAID5 – x0.57 penalty

Being budget conscious the customer wishes to go with RAID1 for transaction logs, and RAID5 for databases.  We are provided with two 15K SCSI 300Gb disks (do you still buy smaller than that?) for the transaction logs and four 15k SCSI 300Gb disks for the databases.

So given the above data, the IOPS that will be provided by the disks are as follows:

• Transaction logs – (2 x 120 IOPS) x 0.8 penalty = 192 IOPS.  This exceeds the requirement of  68 IOPS for transaction logs.
• Databases – (4 x 120 IOPS) x 0.57 penalty = 273 IOPS.  This exceeds the requirement of 206 IOPS for databases.

You can also see that if 1000 mailboxes is considered a “larger” environment then Gross Generalisation #2 is proven, in that providing adequate IOPS to the Exchange server has also met storage capacity requirements:

• Transaction logs – 2 x 300Gb RAID1 = 279Gb usable space.  This exceeds the requirement of 72Gb storage capacity for transaction logs.
• Databases – 4 x 300Gb RAID5 = 838Gb usable space.  This exceeds the requirement of 441Gb storage capacity for databases.

Resources:

• Planning Storage Configurations – Microsoft Technet
• Exchange Server 2007 Mailbox Server Storage Calculator
• RAID Disk Space Utilisation Calculator
• IOPS on Wikipedia

Related posts:

• Video: Exchange Server 2007 storage considerations by EMC
• Project Coconut: Part 2 – Sizing the Exchange Server 2007 servers
• Update Rollup 6 for Exchange 2007 SP3 Released
• Avoid Running Out of Transaction Log Disk Space on Exchange Servers
• Error: Outlook Was Unable to Recover Some or All of the Items in this Folder

This article Are you getting enough IOPS in your diet? is © 2008 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com