1. Chapter 10 : Designing a SQL Server 2005 Solution for High Availability MCITP Administrator: Microsoft SQL Server 2005 Database Server Infrastructure Design Study Guide (70-443)

2. SQL Server 2005 High Availability Dependence on databases is growing. More applications used 24x7 Maintenance periods shrinking or being eliminated. High availability can help © Wiley Inc. 2006. All Rights Reserved.

3. SQL Server 2005 Technologies SQL Server 2005 has four main technologies –Failover clustering –Database mirroring –Log shipping –Replication Each meets different goals and solves separate problems © Wiley Inc. 2006. All Rights Reserved.

4. Availability Measured in different ways (application, database, network) Holy Grail - 5’s (99.999%) –Equates to 5 minutes of downtime a year. –Single server can’t get here Need some technology to distribute load © Wiley Inc. 2006. All Rights Reserved.

5. Availability – cont’d Issues affecting availability –Maintenance –Upgrades Multiple servers can mitigate issues © Wiley Inc. 2006. All Rights Reserved.

6. Examining HA Technologies Trying to increase availability Identify Single Points of Failure –CPU –Disk drive –Power Supply –Network –OS –SQL Server –Others © Wiley Inc. 2006. All Rights Reserved.

7. Setting HA Goals Since each technology solves different problems, need to identify which ones you need to solve. –Hardware failures –Geological disasters –Application problems. –Automated failover © Wiley Inc. 2006. All Rights Reserved.

8. HA System Limitations High availability <> Scalability Data Loss potential Delays during failover © Wiley Inc. 2006. All Rights Reserved.

9. Failover Clustering Most common HA technology Improved from SQL Server 2000 Entire instance is protected from disaster SQL Server Agent, Notification Services, Analysis Services, and replication failed over. Virtual node presented to clients © Wiley Inc. 2006. All Rights Reserved.

10. Failover Clustering Limitations Shared Disk Resources Cost Hardware limitations Complex network configuration Employee training (DBA and system administrator) © Wiley Inc. 2006. All Rights Reserved.

11. Designing Clustering Node count limited by MSCS resources –8 nodes with Windows 2003 Datacenter and SQL Enterprise –SQL Standard limited to 2 nodes Active/Active v Active/Passive N+1 configurations © Wiley Inc. 2006. All Rights Reserved.

12. Designing Clustering – cont’d Geographic considerations –Protect against isolated disaster (fire, bomb, etc.) –Hardware and networking can be very expensive. Hardware decisions –Must be on the HCL –Shared disk subsystem required © Wiley Inc. 2006. All Rights Reserved.

13. Designing Clustering – cont’d Licensing –Only active nodes must be licensed. © Wiley Inc. 2006. All Rights Reserved.

14. Database Mirroring New technology introduced in SQL Server 2005. Not supported in RTM, need SP1 Addresses high cost and overkill of clustering in some situations. © Wiley Inc. 2006. All Rights Reserved.

15. Database Mirroring – cont’d Automatic Failover Uses any Windows hardware, even disparate hardware between servers Protects against disk failure Very fast failover Operates at the database level © Wiley Inc. 2006. All Rights Reserved.

16. Database Mirroring Limitations Database Level means that logins must be manually setup on both servers. Master, msdb, model not protected SQL Agent jobs not failed over. ADO.NET 2.0 clients required for automatic failover. © Wiley Inc. 2006. All Rights Reserved.

17. Database Mirroring - Roles Principal – database to be protected Secondary – database that receives the updates from the principal Witness – optional server used to initiate automatic failover Quorum of two servers required to initiate failover. © Wiley Inc. 2006. All Rights Reserved.

18. Database Mirroring Protection Levels High Performance Mode –No confirmation from secondary –No automatic failover –Some data loss possible High Protection Mode –Secondary acknowledges updates –Manual failover required –No witness © Wiley Inc. 2006. All Rights Reserved.

19. Database Mirroring Protection Levels – cont’d High Availability Mode –Automatic failover supported –Updates acknowledged –Witness required © Wiley Inc. 2006. All Rights Reserved.

20. Configuring Database Mirroring Endpoints needed on each server to transfer updates. Initialize mirror database with a backup. ALTER DATABASE SET PARTNER to begin updates. Be sure you test failover and failback. © Wiley Inc. 2006. All Rights Reserved.

21. Log Shipping Based on normal backup and restore procedures Enterprise edition required in previous versions. Supported in Standard in 2005. Supports multiple secondary servers Secondary databases can be used for reporting. © Wiley Inc. 2006. All Rights Reserved.

22. Log Shipping Limitations No automatic failover Application changes may be required to failover Secondary server name must be different. Operates at the database level © Wiley Inc. 2006. All Rights Reserved.

23. Log Shipping Roles Primary server –Normal server for clients Secondary server –One or more servers receiving log backups from the primary Monitor server –Stores tracking information about backups and restores. © Wiley Inc. 2006. All Rights Reserved.

24. Failover with Log Shipping Must be performed by DBA –Restore remaining logs on secondary using the NORECOVERY option –Backup tail from primary server if possible –Restore tail on secondary –Bring secondary online with the RECOVERY option. –Configure clients to connect to the secondary © Wiley Inc. 2006. All Rights Reserved.

25. Replication Not specifically a high availability technology. Can be adapted for HA situations Use Transactional or Merge replication for HA © Wiley Inc. 2006. All Rights Reserved.

26. Transactional Replication for High Availability Use low latency batches to move transactions Similar to log shipping, but can be faster Secondary system is full live for queries. Disparate hardware can be used Operates at the publication level, not database level. © Wiley Inc. 2006. All Rights Reserved.

27. Merge Replication with High Availability Similar to transactional replication. Updates can be made to either the primary or secondary nodes Can scale the system when both nodes are active © Wiley Inc. 2006. All Rights Reserved.

28. Highly Available Storage Any HA solution requires highly available storage Two main choices –RAID –SAN © Wiley Inc. 2006. All Rights Reserved.

29. RAID Technology Redundant Array of Inexpensive Disks –RAID 0 - Striping –RAID 1 – Mirroring –RAID 5 – Striping with Parity –RAID 1 + 0 – Combine RAID 0 + 1 RAID 0 not suitable for databases. © Wiley Inc. 2006. All Rights Reserved.

30. SAN Storage Large set of disks attached to multiple servers. May use RAID technology Specialized installations with proprietary hardware Work with vendors to design database storage © Wiley Inc. 2006. All Rights Reserved.

31. Designing an HA Solution Consider more than the database server Consider Failover times Application failover issues Cost of solutions © Wiley Inc. 2006. All Rights Reserved.

32. Nontechnical Issues In a disaster situation, consider other issues –Staffing –Geographic connections –Load on secondary server © Wiley Inc. 2006. All Rights Reserved.

33. Preparing for Migration Develop a plan to move to the HA solution –Minimize downtime –Train staff –Network Abstraction –Test © Wiley Inc. 2006. All Rights Reserved.

34. Summary Each HA technology has different benefits and costs Each solves different problems Match up needs with the technology Test the solution to be prepared for a real disaster © Wiley Inc. 2006. All Rights Reserved.