snap manager bestpractice

Network Appliance, a pioneer and industry leader in data storage technology, helps organizations understand and meet complex technical challenges with advanced storage solutions and global data management strategies.

SnapManager for Microsoft Exchange Best Practices

John Phillips and Adrian Simays, Network Appliance Inc. | 8/2003 | TR 3233

TECHNICAL REPORT

TECHNICAL REPORT

Network Appliance Inc.

1

TECHNICAL REPORT

Table of Contents1 2 3 4 5 6 7 8 9 10 11 12 13 Introduction Exchange and Filer Design Preparing the Exchange Host (Windows Server) and Filer Installing Network Appliance SnapDrive Software Creating and Managing Virtual Disks with SnapDrive GUI Installing and Configuring Network Appliance SnapManager for Exchange Snapshot Backing Up and Restoring Exchange with SnapManager Using SnapManager for Exchange with Network Appliance SnapMirror Management Tools Summary Ethernet and FCP Technology Diagrams Additional Resources 3 4 8 9 12 13 15 17 23 26 29 30 31


2

TECHNICAL REPORT

1) Introduction This paper is intended to be a best practice guide and is for experienced Microsoft Exchange administrators who have read the Network Appliance SnapDrive and SnapManager for Exchange installation and administration guides. Readers of this best practice guide should have a solid understanding of the Exchange storage architecture and Exchange administration, as well as Exchange backup and restore concepts. The recommendations found in this document are best practices to assist with the design and configuration of SnapManager for Exchange in Windows 2000 and Windows 2003 environments with Microsoft Exchange 2000 and Microsoft Exchange 2003. Note: Both the SnapDrive and SnapManager for Exchange installation and administration guides can be found at http://now.netapp.com (username and password required). Factors That Affect Exchange Scalability Microsoft Exchange is considered a mission-critical application by small and large companies alike. If employees are not able to send and receive e-mail, access their calendars, or retrieve contact information, it can be disruptive and costly to businesses. In order to design and implement highly available Exchange architectures, system managers must look well beyond the availability of their server hardware. Exchange server scalability is often limited by how long it takes to back up and restore data rather than by server performance. Exchange databases can grow rapidly in size while storing e-mail, rich media, calendaring, and contact and workgroup information. As the databases grow larger, it becomes increasingly difficult to complete time-consuming tape backup operations in a reasonable amount of time. In the case of an outage it can take days to restore service, assuming all of the backup tapes are available and error-free. If a virus or software error renders a particular database inaccessible, all of the users whose mailboxes exist within that database cannot access their data. The range of outages can be anywhere from a few hours to several days or even a week or more. To improve data availability, administrators must strive to balance server scalability and manageability by imposing mailbox limits and by limiting the number of users per server or storage group. Network Appliance SnapManager 3.0 for Exchange Network Appliance SnapManager for Microsoft Exchange enables Microsoft Exchange to leverage the many powerful and specialized features inherent in Network Appliance storage technology. Benefits at a glance: Quickly back up and restore Exchange storage groups and databases using Network Appliance Snapshot technology The Network Appliance SnapDrive Microsoft Management Console (MMC) application provides an easy-to-use graphical interface to simplify the management of NetApp disk, storage, and Snapshot resources


3

TECHNICAL REPORT

Full integration with the Microsoft Volume Shadow copy Services (VSS) snapshot API architecture when running Exchange 2003 on Windows Server 2003 Greater data consolidation and scalability for Exchange servers Network Appliance storage technology offers industry-leading performance Exchange data stored in Snapshot copies can be automatically mirrored to one or more locations for archival or disaster recovery purposes Exchange servers are able to serve more data and are easier to scale and manage Flexible pools of storage can provide storage resources for multiple Exchange servers, and capacity can be added on-the-fly without downtime as storage needs grow The ability to quickly back up and restore online Exchange data in Snapshot copies is the primary purpose of SnapManager for Microsoft Exchange. SME dramatically reduces the time it takes to back up and recover Exchange data from online Snapshot files. 2) Exchange and Filer Design Planning Exchange and Filer Use There are many factors to consider when designing a Microsoft Exchange environment on a Network Appliance filer. Important factors include volume sizing for Exchange data and transaction logs, which include the number of disks per storage volume and the placement of critical Exchange files. First, LUNs (disks) must be provisioned by the filer for use by the Exchange server(s). The process in which LUNs are created and mounted by the Exchange server is summarized below: 1. A volume, or collection of physical disks, is created on the filer 2. LUN objects, which are created by using SnapDrive, are created on LUN-dedicated filer volumes* 3. LUNs are mounted by the Exchange server and appear as disks with drive letters, etc. 4. Exchange data is moved to or created on the LUNs as configured by SnapManager for Exchange *If file access (network shares) is required for home directories, etc., a separate volume should be created for that purpose. To ensure optimum LUN performance, volumes created for LUNs should not be used for other purposes. Calculating Exchange Database Size To ensure that you create volumes that meet the Exchange database requirements, you must calculate the potential size of your virtual disks. The following formula can help you calculate your Exchange database size:


4

TECHNICAL REPORT

DB size = ((number of mailboxes * mailbox quota) / single instance sharing ratio) + deleted item cache Where: The single instance ratio can be found through a performance monitor counter under MSExchangeIS Private. In the following example it is calculated to be 1.5. The deleted item cache is 20% (calculated by multiplying by 1.20). For 1000 users with 100MB, mailbox quota (((1000 * 100MB) / 1.5) * 1.2) = 8000MB, or about 80GB Applying this result for future growth, assuming the Exchange environment will grow by 10% annually over the course of three years (for illustration purposes only), add an additional 24GB ((80GB * .10) * 3). Calculating Exchange Transaction Log Size How much disk space is required for your Exchange database transaction logs can be calculated by estimating the number of transaction logs that are generated on your server. To estimate how many transaction logs are generated, note the number of transaction logs that accumulate in the transaction log directory immediately before a backup. Use that number to estimate how much disk space you need (you should do this over a period of several days and use the maximum number). The following formula works best for calculating virtual disk size required for a transaction log drive: Virtual disk size = ((number of transaction logs generated per day * 5MB) * (number of Snapshot copies to keep online + 1 for the active file system)) Where: Each transaction log is 5MB (after a log file is filled, a new 5MB log file is created) If a server generates 200 transaction logs in one day, then there is about 1GB of transaction logs at the end of the day (200 * 5MB = 1GB). If the plan is to keep five days of SnapManager backups online at the same time, then: ((200 * 5MB) * (5 + 1)) = 6000MB, or about 6GB. Note: If storing transaction logs from multiple storage groups on the same virtual disk, then apply this formula to each set of transaction log files and combine the total of each transaction log set to estimate a virtual disk size. Snapshot Management When sizing virtual disks for Microsoft Exchange, consider the number of Snapshot copies that will be created and the length of time they will be kept. Disk space consumed by a Snapshot backup consists only of the blocks that have changed since the last one was created. For example, a 100GB store has a Snapshot copy created at midnight. If between midnight and noon the following day, 500MB of data was added to, changed in, or deleted from the information store data


5

TECHNICAL REPORT

files, the copy would consume only 500MB. However, if that same 100GB store Snapshot copy was kept for 20 days and experienced the same rate of data change during that period, the Snapshot copy would now consume 10GB (500MB * 20 days). Properly managing Snapshot requires balancing the number of copies and the length of time they are kept. Space Reservation As part of the space reservation feature, WAFL reserves blocks equal to two times the specified size of the LUN being created. If a volume of 80GB is being created with a planned growth rate of an additional 24GB, enough spindles to accommodate 208GB ((80 + 24) * 2) will be required. Space reservation is designed to guarantee writes for virtual disks. More information on space reservations can be found later in this document. Migration Impact Migrations are another factor that can influence available disk space. When migrating from an existing mail system to Microsoft Exchange, single-instance store features are unavailable. Single-instance store provides pointers to a single mail message, so one 100kB e-mail sent to 50 people in the mail system will require 100kB of space (Exchange 2000 supports single-instance store per storage group). Since single-instance stores cannot be retained during a migration, 50 instances of the 100kB e-mail will require 5MB of space. Once the migration is complete, new e-mails received in Exchange will be stored using the single-instance store. (Even during Microsoft Exchange 5.5 to Microsoft Exchange 2000 upgrades you may require up to 30% more disks during the migration process. Be prepared to design the volumes with enough free space to accommodate the migration, even if this space is unused once the migration is complete.) Volume Sizing Recap Following the examples provided in this section, one could estimate the volume size for the storage group volume to be:Exchange storage group 80GB

Future growth accommodation 24GB Maximum storage group size Snapshot copies Space reservation Total volume size 104GB 10GB 104GB 218GB*

* This number represents a single storage group containing 1,000 users with 100MB per mailbox.


6

TECHNICAL REPORT

Following the examples provided in this section, one could estimate the volume size for the transaction log volume to be:Transaction log Snapshot copy 6GB

Daily Exchange transaction logs 500MB Space reservation Total volume size 6.5GB 13GB*

* This number represents transaction logs for a single storage group.

Remember, there may be times when the number of mailboxes or the size of the public folders sporadically grows on an Exchange server and thus requires additional free disk space. Having extra free disk space on hand avoids emergency administrator intervention. Unlike traditional storage systems, NetApp filers allow disks to be added on-the-fly on an as-needed basis as storage needs grow. Exchange File Placement Designing the placement of Exchange files will be critical to the overall performance and the protection of critical Exchange data. When configuring Microsoft Exchange in an SME environment, the following Exchange files should be stored on LUNs: Exchange storage groups containing private and public databases Exchange transaction logs Exchange SMTP files (for high-volume environments) When configuring SnapManager for Exchange, it is important to place the Exchange databases and the Exchange transaction log files on separate volumes. This is recommended for both recovery and performance. If the databases and log files are stored on the same volume and a catastrophic failure occurs to the disks in that volume, all Exchange data will be affected. For optimal performance, separate LUNs should be used for each storage group. The databases within a given storage group must reside on a dedicated LUN. All databases within a storage group are backed up and restored together. Restoring an individual database within a storage group is not possible unless that database (priv.edb, for example) resides on its own dedicated LUN. However, the transaction logs from different storage groups can share a LUN. Exchange SMTP Mailroot Directories For high-volume Exchange environments, performance can be improved by placing the Exchange


7

TECHNICAL REPORT

SMTP Mailroot directories on a dedicated volume. When messages arrive at the Exchange 2003 server through the SMTP service, the data is written to the hard disk as an .eml file. By default, these files are stored locally on the Exchange server. The SMTP Mailroot directories include: msExchSmtpBadMailDirectory msExchSmtpPickupDirectory msExchSmtpQueueDirectory Moving these directories requires editing Active Directory; administrators must use caution when performing this action. More information can be found in Microsoft's Knowledge Base Article 318230. MSCS Quorum Disk Requirement If the deployment will use the filer as a quorum device, another LUN will need to be created in addition to those created for the Exchange database and transaction log LUNs. Microsoft recommends that Exchange virtual servers not own the quorum device. Create an additional two-disk volume with a LUN dedicated for the quorum resource. For more information on MSCS clusters and Exchange, please see the Additional Resources section at the end of this paper. Multiple Virtual Disks per Volume in Exchange Although SnapDrive and Data ONTAPTM support multiple virtual disks per volume, disaster recovery and performance should be considered before implementing. Multiple LUNs stored on the same volume could result in data loss for an entire Exchange organization. If the Exchange database and transaction log files are stored on the same volume and the volume becomes unavailable, archived Snapshot backups will be the only way to restore the Exchange environment. Another consideration when storing multiple LUNs on the same filer volume is performance. Avoid placing heavily used storage groups on the same volume. Filer volumes used for Exchange should never be shared with non-Exchange data. Remember, Exchange databases and Exchange log files should never be stored on the same volume. 3) Preparing the Exchange Host (Windows Server) and Filer There are several things that need to be done to prepare a filer and the Exchange host for optimal performance and to eliminate the possibility of error. Refer to the latest SnapDrive and SnapManager for Exchange administration guides to ensure the proper licenses and options are enabled on the filer. Filer Requirements Data ONTAP 6.5 or above and SnapDrive 3.0; for current Data ONTAP requirements please visit http://now.netapp.com FCP, iSCSI, SnapRestore, and SnapMirror (if SnapMirror is used) licenses must be enabled


8

TECHNICAL REPORT

A qualified Gigabit or Fibre Channel host bus adapter (HBA) target card for use with iSCSI or FCP 4) Installing Network Appliance SnapDrive Software SnapDrive interfaces directly with Network Appliance filers and the Microsoft Windows Server volume manager to facilitate the management of virtual disks provisioned on NetApp storage. Network Appliance SnapDrive software is composed of a Win32 service, a Microsoft Management Console (MMC) Windows management application, and the device drivers for iSCSI and FCP. SnapDrive provides a layer of abstraction and a consistent, transparent interface between Network Appliance filers and Windows applications. The Fibre Channel protocol (FCP) and iSCSI resources that are managed by SnapDrive appear to the Windows host server and its applications as locally attached disks. In addition to providing a management interface and presenting NetApp LUNs to the Windows operating system as basic disks, SnapDrive is capable of managing all of the functions related to Snapshot copies. Prior to launching the installation of SnapDrive, use the following checklist to help eliminate the potential for errors or delays during or after the installation. Resolve any hardware, cabling, or network issues or other errors. Make sure all of the necessary software and printed or electronic documentation (found on http://now.netapp.com) are organized and nearby before beginning. Configure DNS, host name, and IP addressrelated services: o Verify that all related systems, including filers, Exchange servers, and clients, are configured to use an appropriately configured DNS server (for more information, see TR 3124 at www.netapp.com/tech_library/3124.html). Manually add the filers' host names to DNS. Enable, configure, and test RSH access on the filer(s) for administrative access (for more information, see the Data ONTAP product documentation).

o o

License all of the necessary protocols and software on the filer. Configure the filer(s) to join the Windows 2000 or Windows 2003 Active Directory domain by using the FilerView administration tool or by running filer> cifs setup on the console (for more information, see Chapter 3 of the Data ONTAP 6.5 File Access Management Guide).


9

TECHNICAL REPORT

Make sure the filers' date and time are synchronized with the Active Directory domain controllers. This is necessary for Kerberos authentication. A time difference greater than five minutes will result in failed authentication attempts. Verify that all of the service packs and hot fixes are applied to the Microsoft Windows and Microsoft Exchange servers. SnapDrive Installation Tips Prior to installing the SnapDrive application, the iSCSI or Fibre Channel HBA drivers must be installed. The SnapDrive installation wizard provides an option to install the drivers before proceeding with the installation. Note: Do not proceed with the SnapDrive 3.x installation until the iSCSI or HBA drivers are installed and the host rebooted. When using FCP, it is not necessary to install the iSCSI drivers.

Figure 1) SnapDrive installation wizard


10

TECHNICAL REPORT

Figure 2) SnapDrive service account Once the device driver is installed, select the same account used by the Microsoft Exchange services when selecting the service account for the SnapDrive and SnapManager for Microsoft Exchange services. When creating or configuring the properties for the domain service account, select the Password never expires checkbox. Doing so protects the account and service from failing due to user password policies. Reminder: It's important to make certain the service account has the following permissions: Read and write or full control access to the locations on the filer in which LUNs will be created (likely if it's already a member of the administrator's group). RSH access to the filer(s). For more information on configuring RSH, see the Data ONTAP Administration Guide.


11

TECHNICAL REPORT

Microsoft Volume Shadow Copy Services (VSS) and SME 3.0 When using SnapManager for Microsoft Exchange in conjunction with Microsoft Exchange 2003 and Windows Server 2003; the NetApp VSS Hardware Provider must be installed. Customers may download the NetApp VSS Hardware Provider software from http://now.netapp.com. For more specific information and system requirements on installing SnapManager for Microsoft Exchange, see Chapter 2 of the SnapManager for Microsoft Exchange Installation and Administration Guide. SnapManager for Microsoft Exchange is integrated with the VSS architecture in Windows Server 2003 and Exchange Server 2003. The following chart describes where SnapManager for Exchange and NetApp storage fit into the VSS framework.

SnapManager for Exchange and the VSS Architecture Volume Shadow Copy Service Windows Server 2003 VSS Requestor NetApp SnapManager for Microsoft Exchange VSS Writer Exchange Server 2003 VSS Hardware Provider NetApp FAS200, FAS800 series, FAS900 series filers

5) Creating and Managing Virtual Disks with the SnapDrive GUI Once installed, SnapDrive can be used to create LUNs on Network Appliance filers for use by Windows 2003 and Windows 2000 hosts. The process of creating a LUN is virtually the same, and there is no distinction at the host application level. LUNs are virtual disks on the filer that are accessed over either TCP/IP (for iSCSI) or Fibre Channel (for FCP) disk access protocols. General Tips for Creating LUNs: When specifying a UNC path to the volume or qtree to create a LUN, use IP addresses instead of host names. This is particularly important with iSCSI, as host-to-IP name resolution issues can interfere with the locating and mounting of iSCSI LUNs during the boot process. Always use SnapDrive to create LUNs for use with Windows to avoid the complexities inherent in Fibre Channel. Calculate disk space requirements to allow for data growth, Snapshot copies, and space reservations.


12

TECHNICAL REPORT

Leave automatic Snapshot scheduling off as configured by SnapDrive. To turn off automatic Snapshot activities, use FilerView or the following example command: filer> vol options voldata1 nosnap on

Figure 3) Specifying a virtual disk path Important Tips for Using Fibre Channel: Verify that all of the hardware and software meets the supported system requirements. The latest hardware and software requirements for filer platforms, host platforms, Fibre Channel switches, and third-party software are available on the NOW Web site. Log onto the NOW Web site at http://now.netapp.com and view the SAN support matrix for the latest information and updates. For more information on configuring Fibre Channel between Windows hosts and filers, please see the Host Bus Adapter Installation and Setup Guide for Fibre Channel Protocol on Windows. 6) Installing and Configuring Network Appliance SnapManager 3.0 for Exchange General Info After following the steps outlined in the SnapDrive 3.x Installation Guide and as listed in the previous sections of this paper, proceed with the installation of SnapManager for Exchange. The SnapManager for Exchange program is a powerful tool that allows for moving the Exchange database and log files as well as controlling backup schedules and managing Snapshot. It is important to protect access to SME, since the altering of Exchange settings could produce undesirable results.


13

TECHNICAL REPORT

Esefile Microsoft's esefile utility verifies the page-level integrity of the Exchange databases and is required by SME. Esefile can be found on the Microsoft Exchange server/service pack CD located under Support\Utils\i386 (since the esefile utility is updated with service pack releases, you must manually copy this utility from the latest Exchange service pack). Upon first use of SME, the user is prompted to specify the location of the esefile.exe utility. While it is possible to cancel this request, it will appear during every use of the management console until configured. If page file verification is not run during the backup process, it will be required prior to a restore. SnapManager 3.0 for Microsoft Exchange in a Cluster Environment When configuring a cluster environment, it is critical to install SME on both nodes of the cluster. In the event the first node in the cluster becomes unavailable, the SnapManager functions can immediately be performed on the second node without waiting. Installing SnapManager for Exchange on the cluster nodes is the last step when configuring a clustered Exchange environment. 1. On the first node of the cluster, install SME and use the configuration wizard to move the Exchange data paths to the LUN resource locations. 2. Create a Snapshot backup of the Exchange environment after the installation and configuration are complete on the first node. 3. After a successful backup, fail the cluster to the second node in the cluster and ensure the Exchange services work as expected. 4. Install SME on the second node of the cluster and run the configuration wizard to update the database locations on the server. 5. Create another Snapshot copy of the data to ensure backups work from both nodes of the cluster. Upgrading from Exchange 5.5 During the upgrade from Exchange 5.5, the SnapManager for Exchange 5.5 program cannot be upgraded to the latest version of SnapManager for Exchange. If SnapManager for Exchange 5.5 exists, it must be uninstalled before SnapManager for Exchange 2000 can be installed. The full Exchange migration guide and upgrade steps can be found at http://now.netapp.com. An important step prior to migrating databases to Exchange 2000 or Exchange 2003 is to run the esefile (eseutil for Exchange 2003) utility on the Exchange 5.5 database. Esefile will check the consistency of the data to ensure there are no problems with the data prior to migration. If the esefile


14

TECHNICAL REPORT

utility is not run against the database and an Exchange upgrade fails, the entire environment must be rolled back to an Exchange 5.5 environment before recovering to a recent Snapshot backup. 7) Snapshot It is beyond the scope of this paper to explore Snapshot in great detail. However, it is necessary to understand the fundamentals of the unique Network Appliance Snapshot functionality and how it relates to Microsoft Exchange. Network Appliance Snapshot backups occur in a matter of seconds, and each consumes only the amount of disk space that has changed since the last Snapshot copy was created. Thus they consume minimal disk space while providing up to 255 online point-in-time images using Data ONTAP 6.4. The amount of disk space consumed by an individual Snapshot copy is determined by two factors: The rate data changes within the file system (in MB/sec or MB/hour, for example) The amount of time that elapses between creation of Snapshot copies The measure of change (in megabytes, gigabytes, etc.) that occurs in the file system between creation of Snapshot copies is called the delta. The total amount of disk space required by a given Snapshot copy equals the delta changes in the file system and a small amount of Snapshot metadata.1 For more information on Snapshot technology and Snapshot internals, see TR 3043, SnapMirror and SnapRestore: Advances in Snapshot Technology (www.netapp.com/tech_library/3043.html). Snapshot Copies Created by SnapManager for Exchange When SnapManager for Exchange creates Snapshot backups, it names them according to the server name, date, and time. The one exception is the most recent Snapshot copy, which ends with "recent" instead of a date and time. When another Snapshot backup occurs, it assumes the "recent" name, and the former one is renamed to reflect its original date and time. Exchange Database Snapshotexchsnap__tmlssrv1__recent 1% ( 1%) 0% ( 0%) Jan 30 03:54 exchsnap__tmlssrv1_01-30-2003_03.43.15 2% ( 1%) 0% ( 0%) Jan 30 03:39 exchsnap__tmlssrv1_01-30-2003_03.31.34 3% ( 2%) 0% ( 0%) Jan 30 03:27 exchsnap__tmlssrv1_01-30-2003_03.18.29 14% (11%) 0% ( 0%) Jan 30 03:14

Transaction Log Snapshoteloginfo__tmlssrv1__recent 0% ( 0%) 0% ( 0%) Jan 30 03:54 eloginfo__tmlssrv1_01-30-2003_03.43.15 7% ( 7%) 0% ( 0%) Jan 30 03:39 eloginfo__tmlssrv1_01-30-2003_03.31.34 11% ( 5%) 0% ( 0%) Jan 30 03:28

eloginfo__tmlssrv1_01-30-2003_03.18.29

15% ( 4%)

0% ( 0%)

Jan 30 03:14

Mounting Snapshot Copies of LUNs for Write Access Snapshot backups of the Exchange storage group databases are read-only point-in-time images. This protects the data and guarantees the integrity of the Snapshot backups. In certain situations an administrator may require read/write access to the storage group in a Snapshot copy to build a recovery or other server for testing purposes. In this case write access rather than the need to actually


15

TECHNICAL REPORT

write data is required. This is because Microsoft Exchange must be able to update the database headers in order to mount them. LUNs in Snapshot can be mounted for write access by using the Connect Disk function within SnapDrive to connect to a LUN in a Snapshot copy.

Figure 4) Mounting a Snapshot backup from within SnapDrive.*

Special virtual disk files with an .rws extension are created when connecting to a LUN to facilitate this purpose. Instead of taking the time to copy the Snapshot data into the active file system, the .rws file is linked to the original Snapshot data. Therefore read requests are read from the Snapshot data, and writes are written to the .rws file. When the read/write Snapshot copy is no longer required and SnapDrive is used to disconnect from the (rws) virtual disk, the .rws file is deleted along with any writes that occurred to the .rws file. Therefore the source Snapshot copy is not modified. Issues When Mounting the "Recent" Snapshot Copy The latest Snapshot backup is always the exchsnap__servername__recent Snapshot copy. This can be confusing if the former Snapshot backup was mounted while it was named as the "recent" Snapshot copy. In this example, the mounted version of the formerly "recent" Snapshot copy will continue to be labeled as such as long as it's mounted. This is true even though it is no longer the actual most recent copy and has been renamed to reflect the date and time it was created. The change is not reflected in the active mount.


16

TECHNICAL REPORT

Disk Space Consumed by Read/Write Snapshot Copies Even though read/write Snapshot files are initially linked to the existing blocks in the Snapshot copy, it is necessary for the filer to allocate blocks equal to the entire size of the file should it be completely overwritten and a copy of it created. There must be enough available disk space to accommodate the entire size of the original LUN while the read/write Snapshot copy is mounted. The space consumed by the read/write Snapshot copy is marked as free disk space when it is dismounted using the Disconnect Disk command within SnapDrive. Note: Though technically possible, it is not recommended to create duplicates of read/write Snapshot copies (.rws files) unless absolutely necessary. Space Reservation Space reservation is designed to ensure that protected files (or files that have space reservation turned on) always have the free space they expect and so that a Snapshot copy of the LUN can complete even if 100% of its blocks have changed. Data ONTAP 6.3x only allowed space reservation to be turned on or off at the volume level. Data ONTAP 6.4 provides for space reservation at the qtree and file levels. Any file may be designated as protected, but it is turned on by default for LUNs. The rest of this section will discuss space reservation as it exists in Data ONTAP. When creating a virtual disk, the filer verifies there is enough available disk space to accommodate the specified size. By default, WAFL reserves blocks equal to two times the specified size of the LUN so that all future writes can complete. If space reservation was not enabled, it would be possible to oversubscribe the available storage. If this occurred, Exchange could unexpectedly run out of disk space while trying to complete writes to one of its database files. On each filer volume, reserved space equal to the amount of protected space for all virtual disks (and any protected files) is set aside. The amount of reserved space is dynamic and can vary if protected files are added, deleted, etc. If the available disk space runs low, writes to unreserved files and the creation of Snapshot backups are restricted in favor of completing writes to protected files. Databases in particular do not react well to surprises stemming from failed file system writes. Microsoft Exchange somewhat anticipates the possibility of running out of space by its use of reserve logs, but reserve log files are only designed to capture a very small amount of data required to shut down a storage group in a consistent state. Note: SnapDrive requires that all LUNs have space reservation enabled. Disabling space reservation for a LUN is not supported with SnapDrive. 8) Backing Up and Restoring Exchange with SnapManager Recommended Settings Configuring a backup schedule for Exchange data will vary from site to site based on the requirements of the organization. Proper scheduling of SnapManager backups requires consideration of the tape archival solution's backup speed. SnapManager backups can be completed much more quickly than tape solutions if esefile verification is not conducted. This capability may tempt Exchange


17

TECHNICAL REPORT

administrators into scheduling SnapManager backups in frequencies as often as hourly. While this strategy would provide quick recovery times due to the minimal amount of transaction replay during a restore, there is a catch. Keep in mind that only esefile-verified SnapManager backups can be archived to tape. Remember, esefile verification will impact the Exchange server's CPU and should be run from a server other than the production Exchange server. The best strategy for SnapManager and tape archive schedules is to consider the tape backup strategy required to meet SLAs, the desired total number of SnapManager backups per day, Exchange client activity schedules, and the total time required to complete esefile verification. Then devise a schedule that allows for esefile verification to complete and does not encroach on the time necessary to complete a tape archive. For example:Tape archives of the Exchange server desired: 1 per day Tape archive time: SnapManager backups per day desired: Total storage group size: 2 hours 4 (7 a.m., noon, 8 p.m., 11 p.m.) 100GB

With this data, esefile verification will take approximately 50 minutes (100GB/2GB/min for esefile verification). SnapManager backups should not be conducted while tape archives are being completed, so the total time increment required between Snapshot operations is approximately two hours and 50 minutes (50 minutes for esefile verification plus 120 minutes for tape archiving to complete). Since only four SnapManager backups are required per day, they can be evenly spaced out every six hours without conflicting with the two-hour-and-50-minute tape archival process. The SnapManager backups can also be strategically scheduled to occur at times of lighter Exchange usage: 7 a.m. is before the main logon period of 9 a.m., noon is during lunch, 8 p.m. is after most people go home, and 11 p.m. is the backup that will be archived to tape. This strategy relies on the esefile verification speed and the time it takes to complete a tape archive. Esefile verification times vary from one environment to another. In order to accurately predict esefile verification speed, create a SnapManager backup of an Exchange 2000 server, mount the storage group LUNs, and then time the esefile procedure against the database files (both .EDB and .STM). This will allow accurate prediction of esefile speeds in your environment. Tape archival speeds usually can be retrieved from tape software backup logs. Storage Group Sets A storage group set is one or more Exchange storage groups that belong to the same Exchange server and are stored on the same filer volume. When one storage group on a volume is selected to be backed up, all the others on that volume are automatically preselected. A volume containing a storage group set to be backed up can also contain Exchange storage groups belonging to other servers. These storage groups constitute their own storage group sets, depending


18

TECHNICAL REPORT

on the Exchange server they belong to. To create a recoverable backup of the storage group, you must use the SnapManager backup feature and explicitly configure that storage group as the backup target to the Exchange server it belongs to. SnapInfo Directories The SnapInfo directory contains the information about each storage group backup set created by a SnapManager backup. A subdirectory under the SnapInfo directory is created for each backup set and contains the transaction logs backed up as part of that Snapshot operation as well as the recovery information for that specific Snapshot duplicate. Every time a SnapManager backup is created, a new backup set subdirectory is created under the SnapInfo directory and is populated with the appropriate information and data. A complete backup set consists of this SnapInfo subdirectory and the corresponding backup of the virtual disk drive that stores the Microsoft Exchange databases. Note: The SnapInfo directory can be found on the virtual disk configured for the transaction logs. Do not attempt to delete or move any of the files or folders found in the SnapInfo directory. Tape Archive The combination of SnapManager for Exchange and tape archives of SnapManager backup sets provides a solid disaster recovery solution for Microsoft Exchange information store data. Please keep in mind that information store data is only one piece of a complete Exchange disaster recovery plan. A complete disaster recovery backup strategy must also include system-level backups of the Exchange server as well as Active Directory domain controllers in the domain running Microsoft Exchange. The recommended strategy for archiving SnapManager for Exchange backups requires two different backup operations. 1. The first operation utilizes NDMP or dump for the storage group database Snapshot copies. This will ensure the complete archive of the Snapshot backup containing the storage group databases. 2. The second operation should use a CIFS-based or local backup of the LUN where the transaction logs and SnapInfo directory are located. The archives should be generated off of the most recent verified backup set of the entire Exchange server, ensuring all storage groups and their associated log files are properly archived under the most recent Snapshot name. NetApp recommends that the transaction log backup operation occur chronologically first, followed by the database volume backup. This order of operations will reduce the amount of time when a tape backup and a SnapManager backup may conflict due to the renaming of transaction log directories. Archiving single storage groups from SnapManager backups is not recommended. This task requires a full understanding of the Snapshot naming conventions used by SnapManager for Exchange and should not be attempted without knowing which Snapshot backups contain the appropriate storage groups and logs for a given point in time. The appropriate steps to archive an entire Exchange server are: 1. Create a SnapManager backup of the entire Exchange server (all storage groups).


19

TECHNICAL REPORT

Figure 5) Creating a SnapManager backup for the Exchange server. 2. Use NDMP or dump to back up the Snapshot files containing storage group databases. o The naming convention for the appropriate Snapshot file to archive is /vol/LUN_volume_name/.snapshot/snapshot_name.

Figure 6) Viewing LUN locations in Computer Manager. o In this example, dump the volumes that are associated with drives G: and H:, which are /vol/data2 and /vol/data3 on the eddie filer.


20

TECHNICAL REPORT

o

The appropriate Snapshot copies to dump in this example with two storage groups would be /vol/data2/.snapshot/exchsnap__tmw2k3__recent and /vol/data3/.snapshot/exchsnap__tmw2k3__recent.

3. Use CIFS or a local backup program to back up the appropriate SnapInfo transaction log directory or directories. o Only the most recent SnapManager backup of the log files will need to be archived. The naming convention for the appropriate directory using a CIFS-based backup is \\Exchange_server_name\SnapInfo_LUN_Drive_Letter$\SnapInfo_Directory_Path \Exchange_server_name\storage_group_name\Exchange_server_name__recent. This example used two storage groups, so both of the following directories will need to be archived: F:\NetApp SnapManager\SnapInfo\EXCH__TMW2K3\SG__First Storage Group\TMW2K3__recent F:\NetApp SnapManager\SnapInfo\EXCH__TMW2K3\SG__SG2\TMW2K3__recent Other Exchange Backup Solutions SnapManager for Exchange utilizes log files for full recoverability. The use of other vendor backup utilities may inhibit the ability of SnapManager to recover data if the utility truncates log files after completion. Make sure that any backup utilities used to back up Exchange while running in a SnapManager for Exchange environment do not truncate log files. Combining backup types against the Exchange database is not supported and will likely lead to loss of data. Only SME backups should be performed against the Exchange databases. Other backup utilities should still be used for the Windows system files and for the Windows system state data, including the Active Directory information for disaster recovery purposes. Restore Best Practices When restoring a Snapshot backup to a production Exchange environment, there are two choices available to the administrator. A point-in-time restore allows a restore to be made at a specific point in time, taking the Exchange environment exactly as it was when the backup was created. If the last backup was performed the night before at midnight, the restore will bring the Exchange system online reflecting the way it looked at midnight the night before. An up-to-the-minute restore can be performed using any available SnapManager backup as long as a contiguous set of transaction logs exists that allows transactions to be played forward from the backup time to the current point in time. Regardless of the restore procedure that is chosen based on the situation, there are many important factors to keep in mind regarding Exchange restores. All databases in a target storage group will be dismounted at restore time. For Microsoft cluster environments, all resources on the virtual disk (all storage groups on the same virtual server) are taken offline. Renaming Storage Groups

o


21

TECHNICAL REPORT

It is important not to try to start the Exchange virtual disk during the restore process. Any storage groups that have been renamed cannot be restored using Snapshot copies created prior to the name change. NetApp recommends performing a backup of the storage group immediately following any major changes, such as renaming a storage group or database. Disaster Recovery While Snapshot provides protection against Exchange data corruption or virus infections, it does not protect against a catastrophic hardware failure with the Exchange server or a problem with the operating system. To protect against these potential issues, a standby server will provide the fastest recovery option. There are two methods available for a rapid recovery of Exchange data in the event of a disaster: a standby recovery server using identical hardware and a standby recovery server using nonidentical hardware. Although these methods sound similar, there are different steps required for each. To implement a standby server using the same hardware, use identical hardware configured with the same firmware updates, software, and applications as the Exchange host requires. Either the standby server can be used to mount the hard drives from the original Exchange server (if necessary), or it can be quickly built to act as the original Exchange server. In addition to a recent Snapshot copy of the Exchange database and the SnapInfo directory, a copy of the Windows system state on the Exchange server will be required. The following is a high-level overview of the steps to take when recovering to a disaster recovery server using identical hardware. Each organization should have these steps well documented and tested prior to actually recovering a failed mail system. 1. Have an identical server with Windows 2000 prepared and assign a temporary computer name. 2. Ensure this server is a member of a workgroup instead of a domain. 3. Important: Ensure the original Exchange server is not online. 4. Restore the system state data to the preconfigured Windows server. 5. Run Exchange 2000 setup using the disaster recovery mode switch (setup.exe /DisasterRecovery). Install service packs using this mode as well. 6. Reinstall applications such as SnapDrive, SnapManager for Exchange, and antivirus solutions. 7. Reconnect the LUN drives and use the database configuration wizard to update the location of the Exchange databases.


22

TECHNICAL REPORT

8. Restore the Exchange databases using the latest Snapshot copies. Ensure the Exchange services have started and the databases are mounted. For organizations that cannot afford to implement a standby server using identical hardware, the Exchange services can be moved to another available server that is not identical to the Exchange host, allowing for quick recovery of the Exchange data. This procedure includes many of the steps similar to using the identical hardware approach. Moving Exchange to a different server requires resetting the computer account in the domain prior to restoring the system state. You must also add the following registry key for service pack builds: HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\Setup DWORD_NAME: ServicePackBuild SP1 HEX_VALUE: 1268 SP2 HEX_VALUE: 1682 SP3 HEX_VALUE: 1869 Note: It is important in both methods to ensure the new Exchange server uses the IP address of the original Exchange server to eliminate any possible problems or confusion. While moving the Exchange services to nonidentical hardware is a cost-effective solution, implementing a standby recovery server using identical hardware is the recommended solution. Identical hardware will ensure compatibility with all components and allows for the option of mounting the hard drives from the production Exchange server in the event something other than the hard drive fails in the Exchange host. More information on both these procedures can be found in the Additional Resources section at the end of this document. 9) Using SnapManager for Exchange with Network Appliance SnapMirror Network Appliance SnapMirror technology mirrors data to one or more Network Appliance filers over a local area network (LAN) or wide area network (WAN). Once source and destination relationships are established, a SnapMirror baseline transfer initializes the mirror to create a replica of the source on the destination. SnapMirror maintains the synchronization of the replica through efficient, incremental updates. Thus SnapMirror is highly effective and efficient in its use of valuable bandwidth, as it does not repeatedly send the entire LUN. The frequency of SnapMirror update events is determined by the frequency of SME backups. SnapDrive triggers SnapMirror updates upon completion of a SnapManager backup procedure. The SnapMirror maximum transfer rate can also be adjusted in kilobytes per second. Key SnapMirror Concepts and Tips: SnapMirror relationships are based on sources and destinations. A destination updates the mirrored copy or replica of its source by "pulling" data across a LAN or WAN when an update event is triggered by the source. Consistent with the pulling nature of SnapMirror, relationships are defined by specifying sources from which the destination filers synchronize their replicas.


23

TECHNICAL REPORT

Destination filers are identified on source filers by assigning destination filers privileges via the "snapmirror.access" protocol access option or by inclusion in the snapmirror.allow file. SnapDrive currently works with volume SnapMirror (VSM) only. Qtree SnapMirror (QSM) is not supported. As discussed earlier, SnapManager is integrated with SnapDrive, which interfaces directly with Network Appliance filers using the iSCSI or FCP disk access protocols. SnapManager relies upon SnapDrive for disk management, controlling Snapshot, and SnapMirror events.

Figure 7) SnapManager and SnapMirror Components Checklist for Configuring SnapManager and SnapMirror: Install (via CIFS setup) both filers into the same Windows domain as the Exchange organization. Configure the Exchange, SnapDrive, and SnapManager Win32 services to use the same logon service account. Make sure the SnapDrive service account has the "Log on as a service" right in the Windows operating system (normally occurs during installation). Verify that RSH commands work between the Exchange server(s) and both filers using the specified service account. License and enable FCP and/or iSCSI on both filers. License and enable SnapMirror on both filers. Establish SnapMirror relationships.


24

TECHNICAL REPORT

Make sure the filer's SnapMirror schedule is turned OFF by assigning the "- - - -" value (four dashes separated by spaces). Initialize the mirror configurations. SnapMirror updates to the specified destinations will occur after the completion of every SME backup. SnapDrive and FilerView can be used to verify the successful completion and state of the configured mirrors.


25

TECHNICAL REPORT

Figure 8) SnapMirror Status in FilerView 10) Management Tools Snapshot Reserve Usage Monitoring The task of monitoring the Snapshot reserve is automatically configured at the time of LUN creation. Simply monitor the application event log for warning events generated in the SnapDrive source and Snapshot monitor event category. Figure 9 demonstrates that due to Snapshot consumption, the reserve must be expanded to 63%, and there is not enough disk space to do so. In order to rectify such a situation, either add more disks to the volume or remove some of the oldest SnapManager for Microsoft Exchange 2000 backups.


26

TECHNICAL REPORT

Figure 9) LUN error due to space limitations. Disk Space Usage Monitoring The amount of disk space used by Exchange should be monitored to ensure that the logical drives (LUNs) containing data do not run out of space. Exchange 2000 includes a monitoring function that can be used to notify administrators of low disk space. To enable this functionality for the LUNs, navigate to the Tools | Monitoring and Status | Status section of the Exchange 2000 System Manager. Create an entry for each LUN with the appropriate thresholds for your installation. The example shown in Figure 10 will monitor both the database (F:) and log (G:) drives for low disk space conditions. (A warning is sent when the available space drops below 2GB, and a critical state message is sent when the drive is below 1GB.)


27

TECHNICAL REPORT

Figure 10) Monitoring virtual disks in Exchange. Monitoring NIC Utilization in Single-Homed Configurations NetApp recommends monitoring NIC card traffic utilization as a best practice. However, when the single-gigabit NIC deployment model is implemented, this task is required. Monitoring the NIC utilization is necessary in this deployment model because Exchange client, Exchange database, and all other network traffic can be seen by the single-gigabit interface. Malicious network attacks or broken network equipment may cause enough traffic to affect Exchange performance. System monitoring can be used to track the total amount of data received and sent by the interface using the "Bytes Total/sec" of the network interface object. Simply monitor this counter after initial installation to derive a baseline. Then set an alert to be sent if traffic flow increases significantly over the baseline average. Filer Event Monitoring Monitor the filer event logs to ensure proper operation of the filer. Issues may be discovered in the event logs that require administrative action. One such action may be to replace a disk in a volume if spare disks are not available. This task can be completed by using the FilerView utility built into Data ONTAP. This utility can be started by pointing a Web browser to http://filername/na_admin. Next, click the FilerView link. FilerView will start and will ask for the credentials of a filer administrator. Once logged onto FilerView, click the Filer menu option on the left side of the screen. Then choose the Syslog Messages menu option.


28

TECHNICAL REPORT

Review the log on the right side of the screen for any issues that may require administrative action. For more information on FilerView, refer to the Data ONTAP System Administrator's Guide.

Figure 11) Syslog messages in FilerView.

Terminal Server Microsoft Terminal Server is not recommended as a way of administrating SnapDrive or SnapManager for Exchange. When creating virtual disks from a terminal server session, the drives can appear as if they were not created or have been disconnected when in fact they are operating without errors. The only way to fully resolve problems when using Terminal Server is to log out of the session (but do not disconnect). NetApp recommends avoiding Terminal Server for server management when possible. 11) Summary Network Appliance SnapManager for Microsoft Exchange is a complete data management solution that provides backup and restore features using Snapshot technology. By reducing backup and restore times, minimizing Exchange outages, and consolidating Exchange storage, SME delivers a costeffective solution for managing critical Exchange data. In conclusion, the recommendations made in this paper are intended to be best practices for most environments. This paper should be used as a set of guidelines when designing, deploying, or administrating SnapManager for Exchange. To ensure a supported and stable environment, familiarize yourself with the resources provided in this paper and involve an Exchange specialist if necessary.


29

TECHNICAL REPORT

12) Ethernet and FCP Technology Diagrams


30

TECHNICAL REPORT

13) Additional Resources TR 3124: Integrating NetApp Filers with the Microsoft Active Directory www.netapp.com/tech_library/3124.html Exchange 2000 Documentation and Release Notes www.microsoft.com/exchange/techinfo/productdoc/ 2000/E2Kdocumentation.asp Exchange 2000 Deployment Guide www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/exchange/exchange2000/ deploy/upgrdmigrate/ex2kupgr/deploy/default.asp Chapter 9 of Exchange 2000 Deployment Guide, "Tuning Exchange for Performance" www.microsoft.com/technet/treeview/default.asp?url=/TechNet/prodtechnol/ exchange/exchange2000/deploy/upgrdmigrate/ex2kupgr/deploy/d_09_tt1.asp Exchange 2000 Planning Guide www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/ exchange/exchange2000/deploy/upgrdmigrate/ex2kupgr/planus/default.asp Exchange Up-to-Date Web Site www.microsoft.com/exchange/techinfo/deployment/2000/E2Kuptodate.asp Deploying Exchange 2000 Clusters www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID= 824A63A2-F722-4BFF-A223E71B856F83C4 Disaster Recovery for Microsoft Exchange 2000 Server www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/


31

TECHNICAL REPORT

exchange/exchange2000/proddocs/onlinebooks/disrec/default.asp Exchange 2000 Top 50 Issues and Solutions http://support.microsoft.com/default.aspx?scid=/support/exch2000/e2khottopics.asp Microsoft KB article 266096: "Exchange 2000 Requires /3GB Switch When Using More than 1GB of RAM" http://support.microsoft.com/default.aspx?scid=kb;[LN];266096 Microsoft KB article 313707: "Exchange 2000 May Lose Network Connectivity under Heavy Load" http://support.microsoft.com/default.aspx?scid=kb;[LN];313707 Microsoft KB article 298064: "Scalability Planning for Exchange 2000 Server" http://support.microsoft.com/default.aspx?scid=kb;[LN];298064 Microsoft KB article 318230: "How to Change the Exchange 2000 SMTP Mailroot Directory" http://support.microsoft.com/default.aspx?scid=kb;EN-US;q318230 Microsoft KB article 297289: "How to Move Exchange 2000 to New Hardware and Keep the Same Server Name" http://support.microsoft.com/default.aspx?scid=kb;EN-US;q297289* Snapshot metadata consumes a very small amount of disk space (32MB per terabyte).

Network Appliance, Inc. Company Confidential and Proprietary. 2002 Network Appliance, Inc. All rights reserved. Specifications subject to change without notice. NetApp, the Network Appliance logo, FAServer, FilerView, NetCache, SecureShare, SnapManager, SnapMirror, SnapRestore, and WAFL are registered trademarks and Network Appliance, ApplianceWatch, BareMetal, Camera-to-Viewer, Center-to-Edge, ContentDirector, ContentFabric, ContentReporter, DataFabric, Data ONTAP, EdgeFiler, HyperSAN, InfoFabric, MultiStore, NearStore, NetApp Availability Assurance, NetApp ProTech Expert, NOW, NOW (NetApp on the Web), RoboCache, RoboFiler, SecureAdmin, Serving Data by Design, Smart SAN, SnapCache, SnapCopy, SnapDirector, SnapDrive, SnapFilter, SnapMigrator, Snapshot, SnapSuite, SnapVault, SohoCache, SohoFiler, The evolution of storage, Vfiler, and Web Filer are trademarks of Network Appliance, Inc. in the U.S. and other countries. All other brands or products are trademarks or registered trademarks of their respective holders and should be treated as such.


32

snap manager bestpractice

Documents