SQL Server 2005

Second in a series of step-by- step

guides forthe protection of

the MicrosoftWindows Server

System

2

Sponsored by

Nelson Ruest & Danielle Ruest A Report by Resolutions Enterprises

Designing High Availability for

SQL Server2005

Setting up Database Protection MechanismsIf your organization wants to rely on database systems to operate, then they need to supportyou in the implementation of protection systems for the databases you manage. Depending onthe type of protection you want, you’ll usually have three options with which to work. If youwant total protection, you’ll use a combination of all three:

• Proper system understanding• Service protection through built-in, high-availability services• Data replication systemsThe first option is really the first rule of any DBA; you can’t protect what you don’t know

you have and Microsoft offers several tools to help at this level. The second relies on services andfunctionalities that are both at the SQL Server and Windows Server 2003 level to implement dataand service redundancy schemes. This can involve up to three different strategies: log shipping,data mirroring and the Microsoft Cluster Service. (Note that data mirroring is only available forSQL Server 2005.) The last approach relies on third-party tools and can help ensure that youhave a readily available replica of your data so that you can bring it back up immediately in theevent of any failure.

Each of these is explained in detail here, and each applies to either SQL 2000 or SQL 2005(except data mirroring, which is exclusive to version 2005.

Step 1:Know Your SQL Server ArchitectureToday’s modern database applications rely on an n-tier architecture. This means that different application roles are played by different servers. For example, you will often have a Web front-end to the application, which is the interface users rely on to access the applica-tion’s functions, and is the presentation layer. Next, you may have a middleware tier that provides application logic. This may or may not run on the same servers as the Web interface.

The end of downtime, period!Job No. 1 for database administrators (DBAs) is making sure

that the data they’re responsible for is available all the time.

That’s because for anyone who implements database systems

with Microsoft SQL Server, be it 2000 or 2005, data availability

quickly becomes mission-critical. This is why DBAs must

ensure that they have some form of protection in place for these

systems, be it a rapid-recovery or a high-availability system.

They know that, should any outage occur, they will be held

responsible and faced with the repair of the system.

What if you could completely avoid downtime? What if you

could go home knowing that the system would always be up.Well,

if you’re a DBA and you want database peace of mind, read on.

Finally, you’ll have a data back-end thatprovides data-management services to theapplication and serves to persist data modifications. This third layer is the DBA’sresponsibility because it’s where SQL Serverresides.

This third layer can be in several formsbecause there are various flavors of SQLServer. Applications can rely on any of them,including Microsoft SQL Server 2000 DesktopEngine or the newer SQL Server 2005 ExpressEdition, but enterprises should really rely on more comprehensive editions of either SQL Server 2000 or 2005 because they providemuch more robust database services and support high-availability solutions.

Depending on the type of application youcreate, you may need to rely on several sec-ondary services to make sure it is always up.These can include services such as ActiveDirectory (AD), the dynamic host configura-tion protocol (DHCP), the domain name sys-tem (DNS), and, of course, a series of securityservices, such as anti-virus and anti-spyware,to make sure the data is always protected.Depending on the clientele for your solution,you may also need additional protectionmechanisms such as firewalls (see Figure 1).These secondary services don’t fall under theresponsibility of the DBA, but they may affectdata availability.

Figure 1 illustrates that even the simplestapplication architecture can become complicated, and complicated architecture isvulnerable by default. So, the first step in protecting this system is through the use ofproper documentation, outlining each aspectof the application’s configuration. Proper documentation will assist you in a rapid diag-nosis of issues as they arise and help you as a DBA to understand the dependencies of theapplications you support.

In addition to proper documentation, youmay want to implement a monitoring systemto proactively protect the data you manage.Microsoft Operations Manager 2005 (MOM)provides an excellent means of monitoring andcontrolling all versions of SQL Server. MOM provides an operator console that lets admin-istrators know the health of the system at alltimes. What’s better, you can create customconsoles for DBAs listing only the items they’reresponsible for and giving them constantfeedback on the status of their SQL servers.

In addition, MOM’s framework lets soft-ware developers create special management

Step 2: Use Built-in, High-Availability Measures

Typical n-tier Application Structure

F I G U R E 1

Now that you know more about your database systems, you can move on tothe second step: using built-in features to protect the availability of thedata. These features come from both SQL Server itself and from the WindowsServer 2003 operating system. They include:

• Log Shipping• Data Mirroring• Microsoft Cluster Service (MSCS)Each strategy can be used to protect data at the server and the site level.

The server level ensures that data is available on another server within thesame site, while the site level ensures that data resides in another site to protect from site-level disasters. Each of the strategies relies on the availabilityof a primary and secondary, or backup, SQL Server.

Using Log ShippingIn SQL Server 2000, you need to use the Enterprise Edition to support logshipping and all versions of SQL Server 2005, except for the Express Edition,will support it.

Log shipping relies on SQL Server Agent jobs to make periodic backups of the transaction logs on a production or primary server and send them to a secondary or standby server. The secondary server can be located in the samesite, providing server-level protection, or it can be in a remote site, providingsite-level protection. Then Agent jobs on the standby server will use the same

packs for specific products. As part of itsnew Common Engineering Criteria, Microsoftensures that new management packs aredelivered with each and every component ofthe Windows Server System. This is why allversions of SQL from 2000 to 2005 includeMOM management packs. In fact, there are two management packs for SQL Server,one from Microsoft and one from Quest Corp.Both include extended expert knowledge onthe health status of SQL and can go a longway toward making sure your SQL systemsare monitored proactively. This lets yousolve issues before they become problems.In addition, upon the generation of analert, MOM can even take action itself andrun custom SQL scripts to further protectthe data.

Another powerful tool that includesexpert knowledge of SQL is the SQL Server2000 Best Practice Analyzer (BPA). Thisstandalone tool analyzes your databaseinfrastructure and provides recommenda-tions for improved availability. It identifiesconfiguration issues and will also indicate if your configuration is supported byMicrosoft. Microsoft is working on a versionfor SQL Server 2005, which should bereleased later this fall.

timeframe to load or restore the received transaction logs into a copyof the production database. Of course, you need to begin by loading afull backup of the production database on the standby server (seeFigure 2).

The advantage of log shipping is that it doesn’t have to be limitedto a single standby server; logs can be shipped to several standbyservers both within and outside the production site. In addition, itdoesn’t have to focus on a single database; log shipping can protectseveral different databases on the same production system, shippingthem to the same or different standby servers. Log shipping isn’t just aprotection mechanism, it’s also a good tool to use to generate a secondary, development copy of the production database.

The disadvantage of log shipping is that there’s no automaticfailover capability. So in the event of a disaster, you have to manuallyactivate the secondary copy of the database.

At the very least, log shipping provides an excellent means of protec-tion for the data itself and allows you to control the shipping scheduleto further protect the system.

Database MirroringWith the release of SQL Server 2005, Microsoft has tried to addressdatabase availability through the use of data mirroring. Though it wasnot available in the release to manufacturing (RTM) version of SQL2005, it is now available through the release of SQL Server 2005Service Pack 1.

The major advantage of database mirroring is that, unlike log ship-ping, in the event of a disaster or the unavailability of the primarydatabase, no manual action is required because a standby databaselocated on a secondary server will be available almost immediately.Like log shipping, database mirroring can be applied to one or severaldatabases and sent to one or more standby servers.

Database mirroring relies on two, optionally three, systems. The firstis the primary production server. The second is the standby server. Thisserver contains a copy of the databases you want to protect. The thirdis a potential witness system that monitors database availability and

performs the switchover auto-matically in the event of a failureof the primary database. Allservers in a mirrored configura-tion must be running one of threeeditions of SQL Server 2005:Workgroup, Standard orEnterprise, with the exception ofthe witness system, which canrely on SQL Server 2005 Express.Mirroring works by shippingtransaction logs from the produc-tion to the mirrored database.This means that the mirroreddatabase is not available until afailover occurs, but it can runother, non-mirrored databases

(see Figure 3).You can run mirroring in either asynchronous or synchronous modes.

Both have their advantages and disadvantages. With asynchronous mir-roring, you have better system performance, but you have the opportuni-ty for data inconsistency, because the transactions on the main server arecommitted without waiting to hear if they were transmitted to the mir-ror. In synchronous mode, each transaction is mirrored to the standbydatabase before being committed to the production database. This hasthe best data consistency, but it directly affects performance. The wit-ness server is only required if you run synchronous mirroring because thisis the only mode that supports automatic failover. Using a witness will ensure that the data-base is always available so long as at least two of the three server rolesare available.

Automatic failover of database mirroring requires the new SQL NativeClient because it supports automatic redirection to the mirrored database. Database mirroring is designed to protect data at the data-base level and can work both within the same site and across a widearea network (WAN) link. Clearly, the slower the connection is, the moreimpact it will have on performance if synchronous mirroring is used.The disadvantage of database mirroring is that it provides protection atthe database and not the server level, so you must format each serverwith the same configurations. If they’re not exactly the same, failovermay not work properly.

Microsoft Cluster ServiceAt the server level, Microsoft offers Microsoft Cluster Service (MSCS),which relies on shared storage to function. Multiple servers provideredundant services, but are connected to the same storage system.When the service fails on one server, it’s automatically picked up byanother that’s part of the cluster. The same cluster can host multipleinstances of SQL Server because an MSCS cluster running onWindows Server 2003 can have between one and eight nodes: twonodes if the connectivity between the server and storage system isSCSI; up to eight if you use Fibre Channel or iSCSI.

F I G U R E 2Using Log Shipping to Protect Data

Remember that each node must have the capability to handle itsown services—as well as failover services for non-working nodes—when you plan for server capacity. So if you’re running two instances ofSQL Server on a two-node cluster, each node must have enough RAMand processing power to run the instance it’s responsible for, in addi-tion to having enough RAM and processing power for the otherinstance. This way, if there’s a problem with one node, the second willbe able to run its own instance and the failover instance from thefailed node.

Also remember that MSCS uses the share-nothing cluster model; thismeans that each instance of SQL Server must have exclusive access to aportion of the shared disk. In fact, you need to have a shared disk for thecluster service itself, and a different shared disk for each single instanceof SQL that you want to run on the cluster (see Figure 4).

While MSCS is a powerful tool to protect data availability, it tends tobe limited to single sites, mostly because it’s much more complicated tobuild geographically dispersed clusters. This is because the cluster serv-ice relies on a heartbeat to determine if failover is required. This heart-beat is easier to maintain on a local area network (LAN) than on a WAN.

Step 3: Protect YourDatabases with ReplicationTechnologyUsing the traditional mechanisms provided by Microsoft to protect both database and server availability makes a lot of sense, mostlybecause they’re designed to work with and support SQL Server—butthey do have limitations. This is why it’s also a good idea to examinethird-party solutions—such as those from CA XOsoft, Symantec,EMC, Double-Take Software and others. Replication technology offersthe ability to have real-time data replication of your SQL servers. Inaddition, it’s possible to add application monitoring, automaticpushbutton failover and automatic failback for complete system pro-tection both in the same site and at remote sites. Because of this,replication tools can provide server-level or site-level protection. Youcan also add tools that protect data to the last consistent state, mak-ing sure that when you recover from a failure, you will not recover cor-

rupted data. For automated failover, you can redirect DomainName System (DNS) entries to the failover server, making failovercompletely transparent and avoiding the need for special clients.Finally, if you’re looking at third-party tools, you’ll want a solutionthat lets you perform disaster recovery testing in real time, with-out disrupting either users or replication between partner servers.One tool, CA XOsoft’s Assured Recovery, provides this capability. Nosolution is complete without this testing capability.

While SQL Server 2005 includes its own replication mechanisms, itdoes not compare with the capabilities of these third-party toolsbecause they are designed with high availability in mind. You can usethese replication and data assurance solutions on their own or youcan combine them with your existing protection mechanisms. Theywork on the principle of real-time replication, replication that can beintra-site, occurring within the same LAN or inter-site, occurringbetween two sites over the WAN. They include bandwidth control soyou don’t have to worry about losing your existing WAN throughput.And, through their application monitoring capabilities, they can con-trol automatic failover—transparent to users—in the event of a localor remote disaster.

The source of the data doesn’t matter—your database can be clus-tered or not clustered. Using these tools, you can set up one of many

Using DatabaseMirroring toProtect Data

Using MSCS to Protect DataF I G U R E 4

F I G U R E 3

different high-availability scenarios (see Figure 5).Each manufacturer lets you test their tools online in their own environments. If

that doesn’t work for you, use the following procedure to set up your own test, usingyour own databases and server builds.

Set up a testing lab. To keep it simple, rely on virtual machines. Both Microsoftand VMware offer free copies of their virtualization technologies (see Resources).That means you can even do it on a workstation if you have to, but of course, itwould be best to use a server-class machine. You’ll need to prepare a copy of theoriginal servers you want to protect, and then create duplicate servers for each.You’ll also need key services such as AD and DNS to support the failover test. Tomake it easier to capture your existing SQL servers, use the Microsoft Virtual ServerMigration Tool (see Resources) to create virtual machine copies of the existingphysical servers. Because Microsoft virtual machines run on both Virtual Server andVMware Server, this tool can be used with either one.

Next, select the vendor you want to test and then download the trial version of thesoftware from the manufacturer’s Web site. You’ll need to run the tool’s installer toinstall the necessary components on your workstation.

Depending on the selected technology, you might also have to install the replica-tion technology engine on the Master and Replica servers for each database server youwant to protect.

Next, create a replication and failover scenario. Make sure you set it up to provide automatic failover. This might imply relying on a DNS redirection.

Now, you’re ready to test the failover, either automatically or manually. When youfail over, the replica server becomes the holder of live data. Make sure the tool allowsyou to run a ”backward” scenario to ensure that the data changes are replicated back tothe original production server. Repeat as often as you need to to make sure you’re satis-fied with the results. You should also test data failures to make sure you recover fromnon-corrupted data.

Then, when you’re completely satisfied that everything works as, move to acquire alicense for the product and install it on your production systems.

It’s a simple test. The longest part will be the first step because it takes time to

prepare duplicate servers and duplicateservices, but the beauty of virtualmachines is that once you have one, it’sreally easy to generate more. Once youhave what you need, then you can moveto apply the solution to your production machines.One other advantage of using virtualmachines, is that it doesn’t matter ifyou make mistakes, just make sure youuse copies of the machines to test. Thatway you can start over at any time.Another advantage is that you can make sure you get the procedures downpat before you have to take any steps inproduction.

Replication technologies provide some of the very best protection

scenarios available anywhere. You can protect at the serv-er or the site level and do it all through the same process-es. Try them, you’ll like them. The most important deci-sion you’ll have to make is to determine which tool touse. Use the following guidelines to do so:

• The engine must be specifically designed to replicateSQL Server data, both 2000 and 2005.

• The engine must provide application monitoring toidentify if or when a failover is required.

• The engine must include a data corruption protectionto make sure you replicate only valid data.

• Finally, the engine must support online and sched-uled testing capabilities

Do yourself a favor. Try these technologies today. Youwon’t want to go back. No more downtime, no moreirate user e-mails, no more management woes. END

www.Reso-Net.com

About the Authors Danielle Ruest and Nelson Ruest, MCSE,MCT, Microsoft MVP, are IT professionals specializing in systemsadministration, migration planning, software management and architecture design. They are authors of multiple books, notably two books published by McGraw-Hill Osborne,“Windows Server 2003: Best Practices for EnterpriseDeployments”, ISBN 0-07-222343-X and “Windows Server 2003 Pocket Administrator”, ISBN 0-07-222977-2 as well as“Preparing for .NET Enterprise Technologies”, published byAddison Wesley, ISBN 0-201-73487-7. They have extensiveexperience in high availability and systems recovery.

F I G U R E 5

Relying onReplicationTechnologies to protect SQL Server

Continue to the next page for online resources.

ResourcesMicrosoft SQL Server: www.microsoft.com/sql/default.mspx Microsoft Visio 2003 Connector for Microsoft Baseline Security Analyzer: www.microsoft.com/technet/security/tools/mbsavisio.mspx Microsoft Operations Manager 2005: www.microsoft.com/mom/default.mspx MOM Management Pack for SQL Server: www.microsoft.com/technet/prodtechnol/mom/mom2005/catalog.aspx The SQL 2000 Best Practices Analyzer: www.microsoft.com/downloads/details.aspx?FamilyID=B352EB1F-D3CA-44EE-893E-9E07339C1F22&displaylang=en SQL Server 2005 Service Pack 1: www.microsoft.com/downloads/details.aspx?familyid=cb6c71ea-d649-47ff-9176-e7cac58fd4bc&displaylang=en Microsoft Virtual Server 2005: www.microsoft.com/windowsserversystem/virtualserver/default.mspx VMware Server: www.vmware.com/products/server/ Microsoft Virtual Server Migration Toolkit: www.microsoft.com/windowsserversystem/virtualserver/evaluation/vsmt.mspx CA XOsoft Solutions site: www.XOsoft.com/products/index.shtml CA XOsoft Download site: www.XOsoft.com/download/index.shtml EMC RepliStor Web site: http://software.emc.com/products/software_az/replistor.htmSymantec Veritas Replication Exec Web Site: www.symantec.com/Products/enterprise?c=prodinfo&refId=50 Double-Take Software Web Site: www.nsisoftware.com/default.aspx

Build Your Own SQL Server Test BedRelying on virtual machine (VM) technologyto create virtual environments is a great idea.You can use the following procedure to createyour own virtual test bed. You can rely on eitherVMware Server or Microsoft Virtual Server R2 toprovide virtualization services, but keep in mindthat the procedures will differ slightly from oneto the other.

Note: Because several licenses of WindowsServer and Windows XP are required in this testbed, it is best to obtain a subscription to eitherMicrosoft TechNet (http://technet.microsoft.com/en-us/subscriptions/default.aspx) orMicrosoft MSDN (http://msdn.microsoft.com/subscriptions/) before proceeding. Eachgives you access to 10 licenses of the operatingsystems, as well as licenses of SQL Server.

In order to create your test bed, you’ll needmachines simulating the following roles:

• Domain Controller (DC): The DC role willsupport integrated authentication scenarios.

• Primary SQL Server: A machine runningWindows Server 2003 Enterprise Edition, whichwill let you support server clustering, if needed.

• Secondary SQL Server: A secondmachine running Windows Server 2003Enterprise Edition.

• Workstation: Machine running Windows XP.This workstation can act as a managementmachine, as well as a testing machine to testaccess to the SQL service.

• User Accounts: These will allow you to testaccess to the SQL service.

• Service Accounts: Create these in ActiveDirectory. One account is required for SQL; oth-ers may be required to test other technologiessuch as clustering. Like all service accounts,they need the following characteristics:

• Complex password• Password never expires• User cannot change password• On the local machines they need:

• The “Log on as a service” access right• The “Allow log on locally” right• The “Act as part of the operating system right• To be a member of the local administrators

If your production environment uses differentvalues for these accounts, you should make theappropriate modifications.

To create the test bed, follow these steps: • Locate an appropriate host machine and

install the virtualization technology of yourchoice. Make sure you have enough disk spaceand RAM on the physical host to run more thanone virtual machine. Each VM runs at about256MB of RAM, so a physical host with about2GB should work. In addition, VMs tend to takeup at least 4GB of disk space. If you decide touse your own workstation as the host, use anexternal disk to increase performance.

• Next, prepare one new machine usingWindows Server 2003 Enterprise Edition. Add allof the appropriate service packs and hotfixes.Next, you can use the SysPrep utility found inthe Deploy.CAB file located on the Windows

Server 2003 installation CD. This will let youdepersonalize this machine so that you canmake as many copies as you need without hav-ing to go through the rebuild process over andover again.

• Make a folder on the C: drive and call itSysPrep (C:\SysPrep).

• To run SysPrep, you need four files from theDeploy.CAB file: Factory.exe, SysPrep.exe,SetupMgr.exe, SetupCl.exe. Copy them to theSysPrep folder.

• Launch SetupMgr.exe and run through thewizard to create a SysPrep.inf file. Cancel theSetup Manager once the file is ready.

If your server is ready, make a copy of thefiles and folder that make up the VM. This willgive you access to the original machine withouthaving to go through the SysPrep process.

• Use the new copied machine. Start upWindows Server and then go to the SysPrepfolder to launch SysPrep.exe.

• Leave the default values enabled and clickon the Reseal button. This will depersonalize theserver image and prepare it for reproduction.

• Make sure you always make copies of thismachine before launching it again.

Once the SysPrepped machine is created,make a copy of the folder that contains its files.Rename the new folder as well as the files thatmake it up. Name them Domain Controller andadd this machine to the virtualization interface.You’ll need to make sure the configuration isproperly set so you can launch this new machine.

• Launch Windows Server. Modify the TCP/IPvalues to give it a static address. Give it its ownIP address as the DNS server. Domain Controllersneed to point to themselves as DNS servers.

• Next, use Manage Your Server to add theDomain Controller role. Use the following values:

Domain Controller in a New Forest.Domain Name: Testbed.LocalNetBIOS Name: TESTBEDWhen the DNS error displays, select the

option to install and configure DNS on this serv-er. You’ll need access to the Windows Serverinstallation files. Accept all defaults from thenon.

Once the Domain Controller has been creat-ed, use Active Directory Users and Computers tocreate the service account. Call it SQLService oruse your own production name. This is a differ-ent directory, so using the same account namehas no impact on your network.

• Next, prepare two new machines runningby copying the SysPrepped machine. Theyshould have the following characteristics:

Machine name: SQLOne and SQLTwoMachine location: C:\VMs\MachineNameMachine files: machinename.xxx and

machinename.xxxRAM: 256MBNetwork Cards: 2Disks: 3 (System, Data and

Transaction Logs)• Install SQL Server according to your own

best practices on each machine. • Use a backup of one of your production

databases to populate the two servers withdata.

• Create the client machine using the sameapproach as the initial build of the SysPrepserver. Make a copy and install the SQL Clientutilities on the new workstation. This will letyou test access to the data.

• Before you perform any test, copy theentire test bed. This will allow you to keep apristine copy and also allow you to destroy anyfailed tests without any worries.

• Now you’re ready to proceed. Downloadwhichever solution you want to try and run itthrough its paces. Good luck!