Exchange 2007 Storage Groups A storage group is a grouping of mailbox and/or Public Folder databases that shares a single backup schedule and a single set of transaction log fi les.. As
Trang 1The Exchange Product Group had several design goals related to mailbox server storage design One of the goals was to allow an average user to have a considerably larger mailbox (2GB and larger) than was the case in Exchange 2003, where the norm was approximately 100MB to 300MB Another design goal was to reduce the I/O (to lower the demand from the storage subsystem), done by taking advantage of 64-bit hardware, which gives us the opportunity to use much more memory than was
the case in previous Exchange versions Because Exchange Server 2007 can take advantage of more
memory, a larger chunk of each user’s mailbox can be stored in the memory, which reduces disk I/O
In Figure 4.1 you see a screenshot of the Exchange Management Console (EMC) with the
Mailbox node selected As you can see, this particular server holds several storage groups, mailbox
databases, and a single Public Folder database
Figure 4.1 The Mailbox Subnode in the Server Confi guration Work Center
In the following sections, we’ll go through how you manage and confi gure storage groups,
mailbox databases, and Public Folder databases
Exchange 2007 Storage Groups
A storage group is a grouping of mailbox and/or Public Folder databases that shares a single backup
schedule and a single set of transaction log fi les Storage groups are managed using their separate
Trang 2server processes; the idea behind splitting up databases in storage groups is primarily to reduce the overhead that results from multiple sets of transaction log fi les
As most of you’ll recall, Exchange Server 2003 Standard Edition supported one storage group and two stores—one mailbox and one Public Folder store (when excluding the Recovery Storage Group, of course) Exchange Server 2003 Enterprise Edition supported a total of four storage groups, each containing a maximum of fi ve store databases The limit of a database in Exchange Server 2003 Standard Edition was 16GB (although raised to 75GB when Exchange 2003 Service Pack 2 was applied) There was no limit on a database in Exchange Server 2003 Enterprise Edition; well, actually, there was a 16 terabyte limit, but this limit was caused by hardware
As we explained in Chapter 2, Exchange Server 2007 comes in two fl avors: a Standard Edition and
an Enterprise Edition, just like previous versions of Exchange The mailbox server in Exchange Server
2007 Standard Edition supports a total of fi ve storage groups and fi ve databases Unlike Exchange 2003 and previous versions of Exchange, there’s no longer a database storage limit in the Standard Edition The mailbox server in the Exchange 2007 Enterprise Edition supports up to 50 storage groups and a maximum of 50 databases per server Exchange 2007 allows you to create up to fi ve databases
in each storage group, as is the case with Exchange 2003, but best practice is to create one database per storage group So, why should you have a one-to-one relationship between storage groups and databases? That’s primarily because you’ll be up and running a lot faster when dealing with disaster recovery scenarios and the like
As was the case with Exchange 2003, it’s still okay to keep all storage groups on the same spindles, but in terms of performance, it’s better to keep them separated—although that would be quite unrealistic for most organizations that were using, for example, 30 storage groups!
Local and Cluster Continuous Replication
Exchange Server 2007 fi nally has native support for continuous replication, which is a functionality that will make it possible to keep a second copy of a database held in a particular storage group The second copy of a database will be updated using log fi le shipping and log fi le replay The idea with keeping a second copy of a database is, of course, to get up and running in a couple of minutes by being able to switch to the second database with just a couple of mouse clicks (or CMDlets), should the original database crash or get corrupted Having a second constantly updated copy of a database also means you don’t have to perform a full backup of the database as often as you used to With local continuous replication or cluster continuous replication deployed, you could, for example, take
a weekly backup instead of a daily one, which is the typical backup schedule
The new continuous replication functionality can be enabled for storage groups on a single
Exchange 2007 mailbox server (known as local continuous replication), and it can also be used with
an Exchange 2007 mailbox cluster (known as a clustered continuous replication setup) We won’t dive
into the details of how you enable, confi gure, and manage this functionality in this chapter;
we cover them in depth in Chapter 8
Creating a New Storage Group
Let’s take a look at how you create a new storage group in Exchange Server 2007:
1 Open the Exchange Management Console and expand the Server Confi guration work center node, then select the Mailbox subnode.
Trang 32 Now click New Storage Group in the Action pane.
3 The New Storage Group Wizard shown in Figure 4.2 will appear Here you’ll need to
provide a name for the new storage group as well as specify the location for the transaction
log fi les and the system fi les Do so by clicking the Browse buttons, then click New.
NOTE
You also have the option of enabling local continuous replication for the storage
group by putting a check mark in the Enable Continuous Replication for this storage
group box If you don’t do so while creating the storage group, you can easily do
so later
Figure 4.2 Creating a New Storage Group
Trang 44 On the Completion page, you can see whether or not the storage group was created successfully, as well as the CMDlet code required to create the storage group using the
Exchange Management Shell (EMS) Click Finish to exit the wizard (see Figure 4.3).
NOTE
As you can see in Figure 4.3, you can also create a new storage group via the
EMS using the New-StorageGroup cmdlet For additional information about the
New-StorageGroup cmdlet, type Get-Help New-StorageGroup in the EMS.
Figure 4.3 Creation of New Storage Group Completed Successfully
Trang 5Now let’s try to open the Properties page for a storage group so that we can see what can be
confi gured here (see Figure 4.4) It looks as though not much can be confi gured from here; actually, you can only change the name of the respective storage group as well as enable or disable circular
logging Most of us know circular logging, but for the few readers who don’t, this is a feature that,
when enabled, will allow Exchange to overwrite the transaction log fi les This will reduce disk space used by the log fi les and is a best practice when you, for example, move a large group of mailboxes
from one storage group to another But under normal circumstances, you should keep this feature
disabled; enabling it will limit your capability of restoring all data in a database doing a disaster
recovery Here’s the reason that this is so: As we already mentioned, enabling the feature will allow
Exchange to overwrite the log fi les every time a new fi le is generated This means that you’ll only be able to restore data up to the last full backup of a database, and if you do this, say, each night and the database crashes and is corrupted in the afternoon, you’ll want be able to restore any data generated
in the database between the last full backup and the time of the disaster So, we repeat: Unless you
know what you’re doing, keep this feature disabled
Figure 4.4 The Properties Page of a Storage Group