eBook
Available on Compatible NOOK devices, the free NOOK App and in My Digital Library.
Related collections and offers
Overview
- Includes a description of how the move to a 64-bit application reduced the I/O behavior
- Storage hardware technologies and Windows storage stack features for Exchange server
- Exchange Server 2007 Continuous Replication and Windows Server 2008 Failover Clustering
- Performance monitoring and analysis to optimize the Exchange Server 2007 configuration
Product Details
| ISBN-13: | 9780080560038 |
|---|---|
| Publisher: | Elsevier Science |
| Publication date: | 04/08/2011 |
| Series: | Digital Press Storage Technologies |
| Sold by: | Barnes & Noble |
| Format: | eBook |
| Pages: | 560 |
| File size: | 14 MB |
| Note: | This product may take a few minutes to download. |
About the Author
Juergen Hasslauer is a Solution Architect for HP Consulting and Integration based in Germany. He supports customers to help them define the architecture of their IT solutions. His current focus is designing highly available Microsoft Exchange environments and infrastructure optimization using virtualization solutions. Juergen is a frequent speaker at industry conferences such as Microsoft Exchange Connections.
Read an Excerpt
Designing Storage for Exchange 2007 SP1
By Pierre Bijaoui Juergen Hasslauer
Digital Press
Copyright © 2008 Elsevier, Inc.All right reserved.
ISBN: 978-0-08-056003-8
Chapter One
Introduction to Exchange 2007 Storage
In this chapter, we review aspects of storage design for Exchange 2007 that you should be aware of. This "launch pad" provides background information on the purpose of this book.
Where to Start?
Deploying Exchange 2007 will require you to make decisions about the type of storage you will need to provide to one of the most critical business application on the market. Microsoft Exchange is a dominant mail and messaging platform, often used also as a corporate address book and time management application.
If you think about it, email is about sending and receiving data; for users, it's having a repository of relatively unstructured data and querying that repository similar to a database. Storage is therefore a critical component in your deployment. In fact, given the tremendous progress made in the world of processors, and the adoption of 64-bit computing by Exchange 2007, storage is the most critical component in your design. This is the thing to get right from the beginning, or you run the risk of continuous problems in your deployment, eventually delivering an email service that does not help your users or customers.
When dealing with Exchange storage, we always find it necessary to first work the requirements for the storage and then figure out the best solution. Those requirements can be quite simple (e.g., I want a 5-GB mailbox) or more complex (e.g., ability to recover all Tier-1 users within 4 hours after a major disaster).
The logical flow of handling your requirements could be similar to Figure 1-1 (nonexhaustive sample).
The flow in Figure 1-1 is based on standard architecture methodology and does not pretend to be the only approach to handling requirements. In fact, many customers of Exchange 2007 already have such methodology. The need for such a structured approach is there to ensure that you provide the best solution to your problems, and not attempt to replicate a solution that, after all, does not address your problems, but others' problems. For example, are you certain that you wish to create an ISP-type mail environment with large mailboxes and no service level? Or perhaps you will want a combination of both? Or, you may want to have 1-GB mailboxes with absolutely no loss of data and to be able to sustain a natural disaster within a 100-mile/kilometer radius.
What's new with Exchange 2007?
Microsoft with Exchange 2007 has embarked on a journey that started with the 64-bit route. 64-bit computing has been possible since Windows NT4 (with Digital's Alpha processor). However, Microsoft focused their development of subsequent versions of Microsoft Exchange for the i386 instruction set (processors manufactured primarily by Intel and AMD), running on 32-bit address space. It really was not a problem until the data sets (the database hosting the mailboxes) used by Microsoft Exchange grew to a point where it was necessary to break the single private Information Store model to allow for easier manageability. With Exchange 2000, we saw the adoption of a multiple database model, where mailboxes could be held in several smaller databases, instead of just one big database in a single file. This was further extended with Exchange 2007 (up to 50 databases can be defined for a single server), now that the barriers of the Virtual Address space (3GB and a few bytes) of the Information Store process are broken, thanks to 64-bit computing. Many more databases can be handled by a single Exchange 2007 server, allowing for a better granularity when dealing with individual databases and transaction log files. The databases can be smaller in size, or even better, you can have the same number of users per server, but with a much larger mailbox size, while keeping a reasonable size for the individual databases (200GB is considered the practical maximum).
You may wonder why we discuss 64-bit computing in a book about storage. In fact, much of the storage optimization and improvements found with Exchange 2007 are due to the ability to use larger quantities of RAM (up to 10 times more RAM should be used for a high-end server compared to Exchange 2003, allowing for effective database page caching). While we discuss those new functions later in this book, you will have to remember that choosing the right memory sizing for your server is extremely important to relieve the Microsoft Exchange–induced I/O pressure on the storage subsystem components. Reducing that pressure will result in better user experience, better behavior in shared storage environments (by decreasing the burst of I/O requests and making Exchange less dependent on high-performance storage), and the ability to have more choices for your storage components.
Public folders still exist in Exchange 2007, yet Microsoft definitely put the emphasis on Microsoft Office SharePoint Server for collaboration and shared information. It means basically that if you currently run a Microsoft Exchange environment, and you use public folders, you will still have the possibility to continue using them, but you should seriously consider an exit strategy, because public folders are not likely to get any attention from Microsoft in the long run.
Microsoft touched the tip of information life-cycle management with Exchange 2007 with the use of managed folders. These will provide great assistance for environments where you wish to keep email for compliance purposes, yet not clutter users' mailboxes. The data are still preserved in the Microsoft Exchange databases, but a special area is created to host messages and items that are governed by a retention policy (Figure 1-2).
Exchange 2007 administrators can create management policies that define how long content can exist in user folders and whether content within that folder should deleted or journaled. These policies can be established on standard folders or custom (as defined by an administrator) folders. Custom folders are provisioned in the user's mailbox and are useable via Outlook 2003 SP2, Outlook 2007 and Outlook Web Access. They are just like any other folder except they cannot be deleted, unless the administrator decides to no longer manage them.
Messaging records management is therefore a way for administrators to comply with corporate policies for message retention and lifecycle. As you deploy this function, you will have to be careful about the overhead, both from a transactional standpoint (incurred by the action of moving messages, scanning mailboxes or deleting messages) and from a capacity standpoint: keeping messages around can bust your users' mailbox quota and lead to further problems in Outlook 2007 cache mode. Because the Outlook 2007 cache is based on PST technology (but called an OST), it suffers from the same "issues" found with large PSTs: an excessive number of I/O requests are required each time you add, delete, or modify items in the OST, every time you browse folders, or perform information scanning and retrieval. The result is a degraded user experience, and until Microsoft improves the local cache technology in Outlook, we suggest keeping the mailbox size to approximately 2GB.
The real novelty brought by Exchange 2007 is the database replication: the ability to continuously, although with a slight delay, keep a replica of a database up-to-date, and use that replica in case the source database fails. Think of it as a log shipping mechanism, except that it is fully integrated in the product, with proper instrumentation (e.g., using PowerShell), monitoring, and ease of use. It means that if you are ready to double your storage capacity, you can bring your messaging service to new levels of availability and possibly amend backup and recovery policies in a way you never imagined for an Exchange server (e.g., daily differential weekly full).
The result is that the best practices for storage that we used with previous releases of Microsoft Exchange must now be revisited, because Microsoft changed the product, and also because the industry has made progress in certain compartments of storage technology.
In summary
Thus, we take you on a journey for designing the best storage solution for your environment. Remember that what is best for you today may not be optimal 3 years from now and may not be for a company equivalent to yours. That's a challenge relevant to our industry, that is, the fact that we deal with changing technology, and that storage as we know it today will probably be significantly different 5 years from now from both technology and functionality standpoints.
The important matter is to solve your business requirements with the most appropriate technology and implementation, and to conform to best practices.
Exchange 2007 Server Roles and Usage of Storage
Figure 1-3 describes the server roles for Exchange 2007 at RTM. With Exchange 2007 SP1, you can now run Microsoft Exchange on Windows Server 2008, in addition to Windows Server 2003 SP1 and later.
In this section, we review the storage requirements for each of the roles.
Common requirements
Whatever the role of your server, you will need to provide a boot volume to the Windows operating system. The purpose of the system disk is to host the binaries of the operating system and applications, and to host the page file, which allows for virtual memory management on Windows. Little performance is required from system disks on Windows and Exchange servers. There is no significant paging activity because the Microsoft Exchange database engine will ensure using physical memory as it becomes available. If the server gets low on physical memory, Exchange will proceed to decrease its utilization of physical memory. This is particularly true for the mailbox role. It can apply as well to other roles, such as the Hub Transport Server role that will make full use of RAM for caching messages during transfer, thus preventing slow storage access. Of course, if you use complementary software to your Exchange 2007 server setup, such as a file system antivirus, a backup application, or any kind of monitoring software, you will need to ensure that indeed the system is not paging excessively. This can be monitored quite easily using the Windows performance monitor that we discuss in Chapter 11.
It's generally a good idea to have ample room on your system disk. Given the rather large size of disks, a disk fill-up condition on Windows servers these days is a pretty nasty situation to explain to your manager. You can't get disks smaller than 72GB? Fine! Make use of them and create partitions for the operating system that prevent file fragmentation and disk-full events, and comply with your crash dump management and performance monitoring policies. You might also want to break this 72GB mirror set in two or more partitions in order to create separation between vital system storage and storage that the system needs but will not cause downtime in case it gets full. For example, we frequently recommend to our customers to create a separate partition of the Windows Event and Internet Information Server log files.
Mailbox server storage
Mailbox servers are by far the most important role in an Exchange 2007 deployment when it comes to storage design. The purpose of mailbox servers is to hold a number of databases (50 maximum per server), and each database holds the mail for mailboxes homed to that database. The structure of the database is a series of tables (Figure 1-4) that contain the following:
* The list of the mailboxes
* For each mailbox, the list of folders
* For each folder, the list of messages or items
* For each message or item, a list of body part, attributes, and attachments
There is no hard-coded limit to the number of mailboxes, folders, or items that can be stored in an Exchange database. There are some practical limits, such as the number of items in the critical path folders. The critical path folders are Inbox, Calendar, Sent Items, and Contacts. These folders are used regardless of the user being connected (Inbox and Calendar) or for sending email. If you have too many items (5000 or more), the server will start getting more load than usual, and the user experience for normal operations will be degraded due to the large number of items in the folder. The size of the items is not important: it is the count that matters. You can have a very large number of items in a folder (e.g., 15,000 emails) as long as you do not use this folder often. If you have so many items in your Inbox, every time a message is delivered to you, it will cause more I/O to the database. Opening your client will also cause a larger than usual count of I/O requests. The net result is a larger footprint of Microsoft Exchange on your storage subsystem, where you will obtain two to three times more I/O per second than if you had proper maintenance.
(Continues...)
Excerpted from Designing Storage for Exchange 2007 SP1 by Pierre Bijaoui Juergen Hasslauer Copyright © 2008 by Elsevier, Inc.. Excerpted by permission of Digital Press. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
Table of Contents
1: Introduction to Exchange 2007 Storage2: Basic Concepts of I/O Systems
3: Storage Technologies
4: Windows Storage
5: Designing Your Exchange 2007 Server
6: Exchange Server 2007 Failover Clustering
7: Data Replication Solutions for Exchange
8: Backup
9: Recovery
10: Storage Design Validation
11: Performance Monitoring and Analysis
12: Best Practices and Sample Configurations