Exchange 2010 integrates high availability and messaging
resilience into the core architecture, providing a simple unified
framework for both high availability and disaster recovery. This
approach allows Exchange 2010 to improve continuous replication and
replace the clustering features in Exchange 2007 with a more robust
solution that doesn't require expensive hardware and also requires less
maintenance.
Mailbox databases
continue to be the primary type of database used with Exchange Server.
Exchange Server 2010 also supports public folder databases. However,
Exchange Server 2010 does not make public
folders mandatory because Microsoft Office Outlook 2007 and later
releases do not use public folders for accessing free/busy data or the
offline address book (OAB). Instead, Outlook 2007 and later access this
information from the organization's Client Access servers. How does
this work? Client Access servers provide Web services, which in turn
allow clients to access mail, free/busy data, OAB data, and other
Exchange data using Hypertext Transfer Protocol (HTTP).
Outlook 2003
clients and earlier clients require a public folder database to connect
to Exchange Server. These clients use public folders to access
free/busy information and the OAB. If you have Outlook 2003 or earlier
clients, as well as other Messaging Application Programming Interface
(MAPI) clients, these clients can continue to access public folders on
mailbox servers running Exchange Server 2010. You manage public folder
configuration using the Public Folder Management Console and the Exchange Management Shell.
Note
Exchange Server 2010 does not support public folder access using Network
News Transfer Protocol (NNTP) or public folder access using Internet
Message Access Protocol version 4 (IMAP4). Exchange Server 2010 also
does not support non-MAPI top-level folders in your public folder
databases. The only way to maintain this functionality in an Exchange
2010 organization is to maintain a server running Exchange Server 2003.
When you install the first mailbox server in the organization, this
server's information store typically has a single, default mailbox
database and a single, default public folder database. However, the
specific configuration depends on your responses during setup. When you
are installing the first mailbox server, Setup prompts you to:
-
Specify whether you want to create the default mailbox database. If
you decide to create one, you can also specify its name and location.
-
Specify whether any client computers run Outlook 2003 or earlier or Entourage.
If you answer yes, a default public folder database is created. If you
answer no, a default public folder database is not created.
Note
In an Exchange organization with existing Exchange 2003 servers, you
are not prompted about clients running Outlook 2003 or earlier or
Entourage. In a mixed organization like this, Setup creates a public
folder database automatically to ensure backward compatibility.
When you install additional mailbox servers in the organization,
these servers have only one database initially—the default mailbox
database, if you choose to create it. The reason for this default
configuration is that the decision whether a public folder database is
needed in the organization is determined only when you install the
first mailbox server. When you install additional mailbox servers, you
are not prompted about clients running Outlook 2003 and earlier or
Entourage. A key reason for this is that only one public folder
database is required in an Exchange organization and any other public
folder databases are optional. Keep in mind that regardless of your
selections during setup, you can create a default public folder
database as well as additional public folder databases at any time
using the Exchange Management tools.
Understanding Database Structures
Unlike earlier releases of Exchange, Exchange Server 2010 does not use storage groups, and functionality associated with storage
groups has been moved to the database level. Because of these changes,
Exchange databases have a single, dedicated log stream, which is
represented by a series of sequentially named log files. Each log file is 1 megabyte (MB) in size.
In addition to log files, databases have several other types of files associated with them. As Table 1 shows, these files include one or more checkpoint
files, a temporary working file, and one or more transaction log files.
Depending on the state of Exchange Server, you might see other working
files as well. When you create a database, you can specify separate
folder locations to use for database files and transaction
logs. Each database has content-indexing files associated with it as
well. These files are generated by the full-text search services
running on mailbox servers.
Table 1. Data and Log Files Used by Databases
|
TYPE OF FILE |
FILE NAME |
DESCRIPTION |
|---|
|
DATA FILES
| | |
|
Database file |
DatabaseName.edb |
Primary database file that contains mailbox data |
|
Temporary data |
Tmp.edb |
Temporary workspace for processing transactions |
|
Checkpoint file |
E##.chk |
Checkpoint file that tracks the point up to which the transactions in the log file have been committed |
|
TRANSACTION LOG FILES
| | |
|
Primary log file |
E##.log |
Primary log file that contains a record of all changes that have yet to be committed |
|
Secondary log files |
E##00000001.log, E##00000002.log, … |
Additional log files used as needed |
|
Reserve log files |
E##Res00001.jrs, E##Res00002.jrs, … |
Files used to reserve space for additional log files if the primary log file becomes full |
|
FULL-TEXT INDEXING FILES
| | |
|
Content index-related files |
.ci, .wid, .dir, .000, .001, .002 |
Files used for full-text indexing of mailbox data |
You use Exchange databases
to ease the administrative burden that comes with managing large
installations. For example, instead of having a single 10-terabyte (TB)
database for the entire organization, you can create ten 1-TB databases
that you can manage more easily.
Tip
As a best practice, 2 TB is the largest recommended size
for Exchange Server 2010 databases when you have two or more mailbox
database copies. This large size is made possible by the significant
core improvements in Exchange Server 2010. You'll also find that large
databases make it easier to support the large mailboxes that might be
required by your organization's managers and executives. Still, most
mailboxes should be limited to between 2 GB and 10 GB in size.
When you create a mailbox or public folder database, you specify the
name for the database, and this name sets the name of the primary
database file as well. For example, if you create a mailbox database
called MarketingDept, the primary database file is set as
MarketingDept.edb. With Exchange Server 2010, the default location for
database files is the same as the log folder. If you want a database to
be in a different location, you can specify the location you want to
use. Separating database files and log files from the same database and
putting them on different volumes backed by different physical disks
can help you scale your organization while ensuring high performance
and recoverability.
Tip
Recoverability is the primary reason for separating database files
and log files. For example, in the case of a failure on a drive where a
database is stored, the transaction logs needed for complete recovery
would then be on a different (and probably functioning) drive. Whether
you want to use this approach depends on the size and configuration of
your Exchange Mailbox servers as well as the service level agreements
you need to comply with.
The many files associated with databases provide granular control
over Exchange Server, and if you configure the data files properly,
they can help you scale your Exchange organization efficiently while
ensuring optimal performance. In a small implementation of Exchange,
you might want to place all the data files
on the same drive. As you scale from a small organization to a larger
organization, you'll generally want to organize data according to databases,
placing all the data for each database on separate drives. You can't
always do this, however, in a small-to-medium-size organization with
limited resources. For example, if you have ten 1-TB databases and only
five data drives, you might want to have the five data drives
configured as follows:
-
Drive 1 with Database 1 and Database 2 and all related data files.
-
Drive 2 with Database 3 and Database 4 and all related data files.
-
Drive 3 with Database 5 and Database 6 and all related data files.
-
Drive 4 with Database 7 and Database 8 and all related data files.
-
Drive 5 with Database 9 and Database 10 and all related data files.
In a storage area network (SAN) implementation where you are using logical
unit numbers (LUNs) and don't know about the underlying disk structure,
placing the databases on separate LUNs should be sufficient. To protect
the data, you might want to consider using hardware RAID
(Redundant Array Of Inexpensive Disks), which is likely already
implemented if you are using a SAN. However, if you configure a
database availability group with multiple member servers that each have
one or more copies of mailbox databases, you likely don't need to use
any type of RAID—you likely won't need daily backups either. Just
remember that Microsoft recommends having at least three database
copies in addition to the active copy.
Note
REAL WORLD If the idea of not
needing RAID seems like a radical concept, the idea of not needing to
perform backups of your Exchange data might seem revolutionary.
However, when you have multiple copies of your data on separate
servers, you really might not need to create daily backups of your
Exchange data. This doesn't mean that you won't need to create backups
ever—it just means you might not need daily backups of Exchange data.
You will probably still want to create regular backups of your Exchange
servers and still create periodic full backups of all server and
Exchange data to rotate to off-site storage as a safeguard against
catastrophe.
Database available groups can also make you rethink your use of SANs.
Rather than having a single, massive (and likely very expensive)
storage device, you might want to rely on a server's internal drives or
multiple smaller (and likely less expensive) storage devices. One
reason to use internal drives is that reliable, multiple-TB hard drives
are becoming increasingly available, and several servers with multiple,
large internal hard drives will likely cost a fraction of the price of
a single massive SAN. If you use SANs,
you might find that multiple smaller storage devices are better than a
single, massive storage device because you'll then be protected against
a single source of failure (the storage device) causing an outage on
all your mailbox servers. I know, I know…the SAN should never go down,
but it can (and does) happen.
