Jim McBee, Devin L. Ganger, and I just finished the Microsoft Unified Communications: Featuring Exchange Server 2007 Roadshow that "Windows IT Pro" put on. I got to visit some fun places (such as the fabulous Orpheum Theater in Phoenix and Times Square in New York), and I got to hear a lot of interesting questions about Exchange 2007, Microsoft Office Communications Server 2007, and Microsoft's product strategy. As I was thinking about my topic for this week's column, one question kept insinuating itself into my mind: What's up with storage groups (SGs) in Exchange 2007?
Recall the early days of Exchange Server: we had one mailbox database (priv.edb) and one public folder database (pub.edb) per server, plus a directory database (dir.edb). This design was simple and straightforward, but it had some limitations. First, if your single database was lost or damaged, so were all the mailboxes in it. Second, if your database got too large to back up or restore within the available time, your options were limited to deleting mail or moving some mailboxes to another server.
Exchange 2000 Server introduced the concept of SGs, logical objects that could contain multiple databases. Transaction logs were associated with the SG, but databases could be backed up and restored independently of one another. Suddenly we went from having two databases to having as many as 20 on a single server—a welcome new degree of freedom. Like any other freedom, though, it came with caveats, namely that adding SGs used a significant amount of additional RAM. Microsoft recommended "filling" databases within SGs before adding more SGs.
Exchange Server 2003 removed the memory penalty for using multiple SGs, so the recommendation changed: If you wanted to have, for instance, four mailbox databases on a server, Microsoft recommended using four SGs so that each database would have an independent set of transaction logs. Associating logs with a particular database greatly eases recovery operations, as did the addition of Recovery Storage Groups (RSGs). For more information about RSGs, see "Recovery Storage Groups Explained," May 9, 2003.
Exchange 2007 makes another significant change to the SG mechanism. Whereas Exchange 2003 and Exchange 2000 limited you to 20 databases spread across as many as 5 SGs, the Exchange 2007 Enterprise Edition lets you have up to 50 databases and 50 SGs. You can have 50 SGs, each with 1 database; or 10 SGs, each with 5 databases; or 25 SGs with 2 databases each; or any other combination, provided that you don't exceed 5 databases per SG. (Exchange 2007 Standard Edition gives you a total of 5 SGs and 5 databases). This increase opens up a whole range of new things to think about.
First, having multiple SGs with a 1:1 database to SG ratio means that you can effectively use local continuous replication (LCR) and cluster continuous replication (CCR). LCR and CCR are activated for individual SGs, and they protect one database per SG. If you want to protect multiple databases, put them in their own SGs.
Second, Microsoft still recommends using separate volumes (or, more precisely, LUNs) to hold the databases and transaction logs for each SG. Let's say you want to use 25 SGs, each with 1 database. Because Windows can handle a maximum of only 26 drive letters, you'll have to use volume mount points; the bigger problem is that your storage system might not be able to accommodate an additional 50 LUNs.
Exchange 2007's use of SGs also has implications for backup and restore; if you're using Microsoft Volume Shadow Copy Service (VSS), you might find it more convenient to group databases together for backup so that you back up sets of databases and logs instead of individual SGs. If you're not using VSS, you'll have to contend with the fact that (as far as I know) the streaming backup APIs still limit you to backing up only four databases (all from different SGs) at a time. This limitation will undoubtedly complicate your backup planning as you increase the number of SGs.
Microsoft's Robert Quimbey wrote a fascinating article about configuring and validating storage designs for Exchange 2007 on the Microsoft Exchange Team Blog. I recommend that you read his post if you're interested in this topic and want a deeper understanding of how to provision storage for large or busy servers. I'll write more about aspects of Exchange storage, and about some of the more interesting questions I heard on the roadshow, in future columns.
End of Article
)
It's a shame that the default public folder tree (All Public Folders) can only be hosted in or mapped to one database per server (let alone storage groups). We have over 1TB of public folders, so its a case of heap them all in one huge database, or split them over a number of servers (anti-consolidation = back to square 1 .. nooo :o) ... so we have settled on two servers each with a single 1TB database \o/ , and PF replication of all folders between the two. Not ideal. A bit rubbish actually, but Symantec Enterprise Vault is archiving them to reduce the foot print a bit.
Arguing that they aren't supposed to be used for storage is old hat, there is obviously a requirement here.
How about a post on public folders and their 'de-emphasisng in exch2k7 .. .. is sharepoint really a viable replacement/alternative yet ? .. i heard there are migration tools .. but i've not heard of anyone doing it. I hate the idea of dragging them over into exch2k7 the way they are now.
saltbar May 24, 2007 (Article Rating: