|Latest 7 Posts
| The Future of Exchange- The Next Eldorado|
Mon, Oct 15th 2012 187
| Does Exchange 2013 kill third party monitoring applications?|
Fri, Oct 5th 2012 166
| Is the Microsoft Exchange Admin Community still powerful? |
Tue, Oct 2nd 2012 102
| Microsoft Exchange Conference, Day One|
Tue, Sep 25th 2012 112
| Microsoft Exchange 2013: What’s New?|
Wed, Sep 19th 2012 164
| Exchange Server 2013, the Cloud, Exchange security, see you all at MEC 2012!|
Tue, Sep 11th 2012 106
| The MEC Returns...|
Fri, Sep 7th 2012 109
Sorry, no records were found!
||Exchange 2010 Monitoring: Database Management (Part 1, New Features and Best Practices)
The GSX Blog
The release of Exchange 2010 brought about some differences in the ways we need to look at database management. Gone are LCR, CCR and SCR replaced by Database Availability Groups. Exchange 2010 also introduces new user functionality and enhanced integration with other Microsoft messaging and collaboration platforms. This article will highlight the things that an administrator needs to take into consideration from a database perspective, divided into four separate posts:
- New Features and Best Practices
- Ongoing Management and Statistics
- Maintenance, Backup and Recovery
- Managing your Exchange 2010 databases with GSX Solutions
This is the first post, New Features and Best Practices
Ok, let’s get started by highlighting some of the major departures from Exchange 2007. As mentioned above High availability options for Mailbox Databases provided in Exchange 2007 have been replaced by Database Availability Groups in Exchange 2010. This provides database level high availability as opposed to server level. DAG’s can therefore protect from database corruption, server failure or site failure with up to sixteen copies of each database. Each server that runs Exchange 2010 Enterprise edition can host up to 100 database copies.
High availability for Client Access is now provided by creating Client Access Server arrays. Client Access server arrays can consist of multiple Client Access servers in a single Active Directory site providing a single endpoint for all client connectivity. The RPC Client Access service now allows all Outlook clients to access their mailbox through the CAS. This provides improved performance and redundancy by freeing Outlook clients from a particular Mailbox server.
Exchange 2010 also includes shadow redundancy which protects e-mail in transit. If a Transport server fails after it has received a message, but before it was able to deliver it to the proper mailbox server, the sending server will detect the failure and attempt to redeliver the message to a different Transport server for delivery.
Also new to Exchange 2010, the Mailbox Server Role can be combined with any other role, regardless of whether or not the mailbox server participates in a Database Availability Group. This was not possible in HA scenarios for Exchange 2007. If a mailbox server had hosted CCR or SCR HA, no other roles could be installed concurrently.
When it comes to Databases in Exchange 2010 there are some best practices we should follow when designing our disk layout. Many different configurations are supported but from a performance perspective some options are better than others. Aside from RAID type and configuration we need to consider file placement, database sizes and log truncation. Looking below let’s consider configuration for high availability.
For Exchange OS and system disks best practice is to deploy RAID 1/10 using a dedicated array group not hosting system LUNs and data LUNs on the same array group. For Exchange mailbox databases and logs (.edb) again RAID 1/10 is considered best practice and if lagged, database copies should have two or more lagged copies, or the lagged copies should be protected with RAID.
Database and logs file are typically placed on separate array groups however with Exchange 2010 high availability it isn’t necessarily needed. Best practice is to set the stripe size for disk arrays at 256Kb or greater, taking into consideration you storage vendors best practices as well. In Exchange 2010 database sizes are supported up to 16 Tb however best practice is to keep databases to 2Tb or less, provisioning at 120% of maximum database size. Finally when using Exchange 2010 data protection features we should enable circular logging and provision for three days beyond replay lag setting of log generation capacity.
Hopefully we’ve provided a good introduction to Exchange 2010 and some best practices around database management. Please check back next week for part 2 on where I review ongoing management including typical management shell commands and important database statistics.
Also in the meantime, check our website to see our overall solution for Exchange 2010 monitoring.
Dec 14, 2011
Sorry, no records were found!
| Recent Blog Posts