Microsoft SQL Server

Transcription

1 Microsoft SQL Server

2 Abstract This white paper outlines the best practices for Microsoft SQL Server Failover Cluster Instance data protection with Cohesity DataPlatform. December 2017 Table of Contents About This Guide...2 Intended Audience...2 Microsoft SQL Server Recovery Models...2 High Availability for Microsoft SQL Servers...3 Comparison of Microsoft SQL Server High Availability Options...4 Microsoft SQL Server Failover Cluster Instance...4 Cohesity Architecture...5 Configuration Overview...5 Cohesity Windows Agent...6 User Accounts and Permissions...6 Installing Cohesity Windows Agent...6 Configure Protection Policy...8 Configure Protection Job...9 Performing Backups...9 Microsoft SQL Server Transaction Logs...11 Performing Restores...11 Instant Volume Mount...12 Recover MS SQL Server...13 Clone-Attach...15 Summary...16 About the Author

3 Microsoft SQL Server Failover Clustering Instances with Cohesity DataProtect About This Guide This paper details the steps and best practices to deploy Cohesity DataProtect for protecting Microsoft SQL Server Failover Cluster Instances. Cohesity DataProtect provides a comprehensive, scale-out and flexible data protection solution for enterprise organizations. In this guide, IT administrators are defined as individuals who have the role of managing storage and data protection of applications (virtual or physical) in a data center. Database administrators are individuals who have the purpose of managing database applications such as Microsoft SQL Servers. Cohesity Software version 4.2 and later, extends the support for business-critical applications such as Microsoft SQL Server by allowing IT administrators to leverage Microsoft s Volume Shadow Copy Services (VSS) for application-aware data protection for MS SQL Server Failover Cluster Instance support. With Cohesity DataProtect 4.2, we added support for MS SQL Server on Failover Cluster Instances. IT administrators can leverage Microsoft s Volume Shadow Copy Services (VSS) for application-aware data protection for MS SQL Server Failover Cluster Instances. Intended Audience This paper is written for IT administrators and DBAs familiar with managing data protection of Microsoft SQL Servers. Cohesity recommends having familiarity with the following: Cohesity DataProtect Cohesity DataPlatform Microsoft Windows Server Failover Clustering (WSFC) Microsoft SQL Server Failover Cluster Instance (FCI) Microsoft SQL Server Recovery Models Microsoft SQL Server backup and restore operations occur within the framework of a recovery model. Microsoft SQL Server recovery model is a database property that controls: How the transactions are logged Whether transaction logs are required for backup, and the restore options available. Microsoft SQL Server recovery models include: Simple Recovery Model > There are no log backups with a simple recovery model, and recovery is only up to the last backup point in time. In a simple recovery model the changes that occur after the most recent backups are left unprotected. It is not recommended to use the simple recovery model in a production environment. Full Recovery Model > For full recovery model, log backups are required. MS SQL Server administrators can recover to any specific point in time. However, if the tail of the log is damaged, transaction log backup must be redone. Bulk Logged Recovery Model > Log backups are required for bulk logged recovery model, but this model reduces log space usage with minimal logging for bulk operations. Changes since the last backup must be redone if the log is damaged. With Bulk Logged recovery model, MS SQL Server administrators can recover to the end of any backup but point-in-time recovery is not supported. 2.

4 The restore process in Microsoft SQL is a sequence of steps: 1. The contents are initialized and the data recovered from one or more backups 2. The transactions logs are applied to roll forward (optionally), followed by bringing the database online and exiting the recovery process. Microsoft SQL Server restore includes the following options: Restore with NORECOVERY. This option allows roll forward to continue with the next statement in the sequence including any scripts that database administrators may want to execute. Restore with RECOVERY means that rollback should be performed after roll forward successfully completes for the current backup. High Availability for Microsoft SQL Servers Hardware or software failure of a server is inevitable in any data center. A hard disk failure or software failure of a server means applications or clients connecting to that server will experience downtime. Microsoft applications such as Microsoft SQL Server are designed to support high availability to ensure that vital business infrastructures are always on and available. Microsoft SQL Server offers a variety of high availability options: Failover Clustering > Provides high availability for an entire instance of SQL server. Failover clustering is a combination of one or more nodes with shared disks. Database Mirroring Log Shipping Replication > Database mirroring increases the database availability. It supports near instant failover by maintaining a standby database. It can operate in synchronous high-safety mode, where a committed transaction is committed to both servers, or in an asynchronous high performance mode, where it does not wait for the mirror server to write the log to the disk. > Log shipping operates at the database level, similar to database mirroring. Log shipping allows one or more warm standby servers, with secondary databases, that are updated periodically from log backups of the primary database. Review the Comparison of Microsoft SQL Server High Availability Options section for more details. > Replication allows distribution of data from the primary server to one or more secondary servers. This enables real-time availability and scalability across the servers. Always On Availability Groups > Always On Availability Groups is an enterprise-level high-availability and DR solution. Always On Availability Groups was introduced with Microsoft SQL Server 2012 and requires Microsoft s SQL Server Enterprise Edition. An availability group fails over at the availability replica and supports automatic failover, planned manual failover and forced manual failover. Note: Cohesity recommends reviewing the Cluster scalability section of the following Microsoft TechNet to determine the maximum number of nodes supported in a Microsoft failover cluster for future Microsoft SQL Server migration projects. 3.

5 Comparison of Microsoft SQL Server High Availability Options With Microsoft SQL Server FCI, only one of the nodes owns the WSFC resource group at a time. There is also a dependency on shared storage, and data protection is at the instance level. Secondary nodes in a Microsoft SQL Server FCI are not readable. In a DR scenario, resource group ownership is moved to another WSFC node when the primary node is unavailable. Failed over resources includes server, instance, and database. Microsoft SQL Servers with database mirroring protects at the database level by creating a secondary copy. However, there is a disadvantage with database mirroring. The secondary database copy is standby only. Database mirroring is deprecated in a future version of Microsoft SQL Server. Cohesity recommends reviewing the Microsoft SQL Server deprecated features for future Microsoft SQL Server migration projects. Log shipping takes advantage of automatically sending transaction log backups from a primary server instance to one or more secondary instances. Transaction log backups are applied to every secondary database individually. Log shipping provides a disaster recovery solution by allowing the databases to be in separate MS SQL Server instances. However, the secondary databases are also standby only. Replication relies on a publish-subscribe model. A primary MS SQL Server is known as the publisher and can distribute data to secondary servers. Microsoft SQL Server with replication allows for more than one copy to exist. However, there is no automatic failover, and extra care is recommended to ensure data validity and consistency across all servers. In comparison, Microsoft SQL Server Always On Availability Groups uses WSFC cluster, but there is no dependency on shared storage. Protection is at the database level, and non-primary nodes can be readable secondaries. In a DR scenario, failed-over resources include database only. MS SQL Server Always On Availability Groups supports automatic failover, planned manual failover, and forced failover. Microsoft SQL Server Failover Cluster Instance Microsoft application administrators can leverage SQL Server failover cluster instance to protect at the instance level through node redundancy. Figure 1 shows an example of a 2-node Microsoft SQL Server FCI. SQLNode1 is the primary node that currently owns the WSFC resource group. The following SQL query can be used to determine the current owner of a WSFC resource group: select * from sys.dm_os_cluster_nodes select SERVERPROPERTY( instancename ) SQLCLUSTER1\SQLINST1 (10GigE) SQLNode1 Heartbeat SQLNode2 Database Shared Storage Figure 1 - Microsoft SQL Server Failover Cluster Instance 4.

6 Cohesity Architecture Cohesity delivers a hyper-converged, web-scale platform that consolidates all secondary storage and data services onto a single, efficient solution. Cohesity simplifies data protection, consolidates file and object services, provides instant access to test/dev copies, and performs in-place searches and analytics, all on a software-defined platform that spans from the edge to the cloud. Cohesity s scale-out distributed file system was built from the ground up to ensure complete scalability to enable organizations to flexibly grow their environment by adding nodes to a cluster. With this scalability, organizations can eliminate the costs of data migrations and forklift upgrades, while benefiting from the simplicity of a homogenous solution. Cohesity dramatically simplifies data protection across the enterprise. Cohesity s integrated backup, archive, replication, disaster recovery, and public/private cloud support, combined with its inherent context awareness, and eliminates the need for cataloging software, separate backup software, and other ancillary backup infrastructure. A Microsoft SQL Server FCI with Cohesity DataProtect provides IT organizations with a complete HA and DR solution built for modern web-scale data centers. Figure 2 shows the simplicity integrating Cohesity DataProtect to any Microsoft SQL Server FCI. Cohesity recommends reviewing the following blogs on Protecting SQL Server with Cohesity and Physical Server Protection. SQLCLUSTER1\SQLINST1 (10GigE) SQLNode1 Heartbeat SQLNode2 DataProtect DataPlatform Database Shared Storage Figure 2 - Microsoft SQL Server (FCI) with Cohesity DataProtect Configuration Overview The configuration of Cohesity DataProtect for Microsoft SQL Server FCI is divided into the following tasks: Install Cohesity Windows Agent on all Windows SQL Server FCI nodes Create Database Protection Policy for Microsoft SQL Server Create MS SQL Server Protection job 5.

7 Cohesity Windows Agent Virtualized standalone Microsoft SQL Servers can be protected using Cohesity DataProtect with VMware VADP. With MS SQL Servers, Cohesity Windows Agent must be installed and used for application-aware data protection. User Accounts and Permissions A Windows user account with the following permissions is required for MS SQL Server backup with Cohesity Windows Agent: Backups and restore operations Stop or start the SQL Server services If the MS SQL Server is a member of a Windows workgroup, the user account should be part of the local administrator group of the MS SQL Server. The user account should have Microsoft SQL sa user privileges. If the MS SQL Server(s) is a member of the Active Directory Domain, the Active Directory user account must have Administrator privileges and MS SQL sa user privileges on the MS SQL Server. The user account must also have logon rights on the MS SQL Server for Cohesity Windows Agent install. Installing Cohesity Windows Agent From the Cohesity UI, navigate to the Protection > Sources and select Download Physical Agents (see figure 3). Figure 3 - Download Physical Agents Install the Cohesity Agent on the Microsoft SQL Server. For example, in figure 4, the Active Directory domain user account is a member of the local administrator group on the MS SQL Server with logon rights to install the Cohesity Windows Agent. The user tme\backup also has sysadmin server role on the Microsoft SQL Server. Figure 4 - Setup Cohesity Agent 6.

8 Repeat the Cohesity Windows Agent Install process on all Microsoft SQL Server FCI nodes that will be protected using Cohesity DataProtect. From the Cohesity UI, register the Microsoft SQL Server Failover Cluster Instance (see figure 5). The Microsoft SQL Server Failover Cluster Instance that should be used for registration can be found from the Windows Failover Cluster Manager > Roles > SQL Server > Server Name. Note: It is a requirement that the Cohesity Windows Agent is installed on all Microsoft SQL Server FCI nodes. Figure 5 - Register MS SQL Cluster Figure 6 shows an example of a Microsoft SQL Server Failover Cluster Instance from a Windows Failover Cluster Manager UI. The SQLCLUSTER1.mycorp.local IP address is Figure 6 - Microsoft SQL Server FCI 7.

9 Cohesity supports registering physical servers by FQDN or IP addresses. However, it is recommended to register the Microsoft SQL Server Failover Cluster Instance using the fully qualified domain name (FQDN). In this example, SQLCLUSTER1.mycorp.local is used to register with the Cohesity Cluster. Note: It is recommended to validate the forward and reverse DNS lookup of the Microsoft SQL Server Failover Cluster Instance before registering with the Cohesity Cluster. Configure Protection Policy Using the Cohesity UI, create a Database Protection Policy (see figure 7). Figure 7 - New Database Protection Policy Protection policy creation with Cohesity DataProtect is intuitive and wizard-driven.. The user can use Cohesity s Policy Manager to review the Microsoft SQL Server protection policy (see figure 8). Click on the database policy to review or edit the protection schedule and options. Figure 8 - MS SQL Database Protection Policy 8.

10 Configure Protection Job From the Cohesity UI, create a new Microsoft SQL Server Protection Job (see figure 9). Figure 9 - MS SQL Server Protection Job In the Select Source phase (step 3), select Physical Servers & MS SQL Clusters option (see figure 10). Figure 10 - Select Source In step 4, select the MS SQL Server Failover Cluster Instance FQDN registered with the Cohesity Cluster. In this example, SQLCLUSTER1.mycorp.local is the registered MS SQL Cluster used in step 4 in Select Objects. Performing Backups A good MS SQL Server protection strategy will include periodic log backups as the log backups provide the ability to roll forward to any specific instance from the full backup to the time the transaction log backup was taken. MS SQL Server log backups offer the flexibility to roll forward to any point in time restores. The size of the database and the Recovery Point Objectives (RPO) determines if log backups are required. The size of the database and the RTO defines the type of protection needed (simple recovery, full recovery, full, differential or log backups). Microsoft SQL Server administrators can also take advantage of Cohesity DataProtect to include periodic database log backups for any point in time recovery. Figure 11 shows the Database Logs options in a MS SQL Server Database policy. In this example, the Microsoft SQL Server FCI has a full weekly backup with log backup frequency of every hour. 9.

11 Figure 11 - Cohesity MS SQL Server Database log backup frequency From the Cohesity Protection jobs UI, IT administrators can select Run Now to manually start the Microsoft SQL Server Failover Cluster Instance protection job (see figure 12). Figure 12 - Cohesity Protection Job Options In the Cohesity Cluster UI, the MS SQL Database Protection Job > Backup Run Details will show all the Microsoft SQL Server FCI databases found and protected by Cohesity DataProtect. For example, figure 13 shows Cohesity DataProtect leveraging Microsoft SQL Server VSS to protect all the Microsoft SQL Server FCI databases. Figure 13 - Cohesity Cluster MS SQL Protection Job Details Microsoft SQL Server administrators can also take advantage of Microsoft s SQL Server logs to confirm business-critical databases are protected with Cohesity DataProtect. For example, figure 14 shows the corresponding Microsoft SQL Server logs for the backup run. 10.

12 Figure 14 - Microsoft SQL Server Logs Microsoft SQL Server Transaction Logs With a simple recovery model, log truncation occurs when the database is backed up. However, with the other recovery models, transaction logs are not truncated until all log records are backed up. The purpose of this is to maintain the log chain and ensure that the log records do not have broken log sequence numbers. Log truncation occurs when the IT administrator selects database log backup in the Cohesity DataProtect backup policy. The size of a physical log file is not affected in log truncation. To reduce the physical size of a log file involves the process of shrinking the transaction log. It is not recommended to shrink the Microsoft SQL Server transaction log if point-in-time recovery or recover from corruption is required. Performing Restores With Cohesity DataProtect, IT administrators get a web-scale solution that supports unlimited snapshots and clones, distributed file system for consolidating backup storage, files, objects, test/dev copies and in-place analytics. Cohesity DataProtect, a hyper-converged secondary storage platform offers modern data center unparallel scalability to address growing IT business requirements. Microsoft SQL Server Failover Cluster Instances protected by Cohesity DataProtect can be recovered using either of the following methods: Instant Volume Mount > I nstantly mount volumes from the Source Server to a Mount Target defined by the IT administrator or the MS SQL Server administrator. Recover SQL >R estore MS SQL Instance database to the original MS SQL Server Instance or another MS SQL Server Instance. Recover MS SQL allows IT administrators or MS SQL administrator to utilize MS SQL Server Restore with NORECOVERY or MS SQL Server Restore with RECOVERY. 11.

13 IT administrators can leverage instant volume mount to make any Source Server volumes available to any Mount Target. Using the successful backup jobs completed for the MS SQL Server FCI instance, the IT administrator can select any MS SQL job runs and choose instant volume mount (see figure 15). Cohesity DataProtect allows IT administrator to perform the following DR operations: Copy-Attach Clone-Attach > Copy attach allows any MS SQL Server databases to be copied and attached to any MS SQL Server instance for recovery. > Clone-Attach allows users to attach any backed up databases on Cohesity DataProtect to any MS SQL Server instances instantly. Clone-Attach is advantageous for large databases that would otherwise require hours to restore. In this case, the Cohesity DataPlatform acts as the storage layer for the cloned database(s). QoS will be used to serve any random IO the user performs on the db. Note: Use of Copy-Attach or Clone-Attach requires the source and target are of the same type. For example, if the backup source is a virtual server, the target must also be a virtual server. Instant Volume Mount From the Cohesity Cluster UI, select the MS SQL Server protection job for restore Instant Volume Mount (see figure 15). Figure 15 - Instant Volume Mount From the Cohesity Mount Volume UI, IT administrators or MS SQL Server administrators can define the Mount Target by selecting Change Server. When the Mount Target is selected, Select Volumes to mount and click on Create Task. As shown in figure 16, the IT administrator chooses the original MS SQL Server FCI for the Source Server and the Mount Target. In this example, the IT Administrator selected S volume from the Source Server for the mount. Figure 16 - Mount Volume 12.

14 Figure 17 shows successful Instant Volume Mount task. This demonstrates that Cohesity DataProtect has successfully mounted the Source Server volume on the Mount Target in C:\CohesityMounts directory. The Microsoft SQL Server administrator can easily copy the master database files (MDF) and corresponding log database files (LDF) for Test/Dev purposes or run MS SQL Server queries to copy data from tables rather than importing the entire database (after the database is attached to the MS SQL Server). Note: For MS SQL Server performance, it is recommended to separate the MDF and LDF files on different disk volumes. Figure 17 - Instant Volume Mount task completed successfully. When the MS SQL Server administrator has completed the database restore or data copy task, Cohesity recommends running Tear Down to remove the temporary volume mount. Recover MS SQL Server IT administrators or even Microsoft SQL Server administrators can utilize Cohesity Recovery to recover any Microsoft SQL Server databases to the original MS SQL Server instance or to another MS SQL Server instance that is registered to the Cohesity Cluster. From the Cohesity Cluster UI, select Recover > MS SQL from the Recovery page (see figure 18). Figure 18 - Recover MS SQL 13.

15 Any IT administrator can leverage Cohesity DataProtect built-in analytics and search to find any file or object for recovery. For example, automated global indexing powers Google-like search. Using instant wildcard search for any VM, file or object on the Cohesity DataProtect is simple. When the IT administrator and the MS SQL Server administrator has determined which database to recover, they can select the database and set the recovery options (see figure 19). Figure 19 - Set Recovery Options 14.

16 Cohesity recommends following Microsoft SQL Server Recovery model best practices for tail log captures. Full Recovery model and Bulk Logged Recovery model should capture tail logs. Select Continue to perform the MS SQL Server FCI database restore. The Restore MS SQL Server job details should show the restore task completed successfully (see figure 20). Figure 20 - Successful MS SQL Server FCI database restore Clone-Attach From the UI of the Cohesity Cluster, select Test & Dev > Clone operation. In the What do you want to clone? UI, select MS SQL as shown in figure 21. Figure 21 - Clone Operation 15.

17 In the Clone MS SQL UI, leverage the Google-like search to find the MS SQL Server or database name. In the Set Clone Options, identify the MS SQL Server Host and MS SQL Server Instance. In step 2, IT administrators also have the option to rename the database for the clone operation (see figure 22). Figure 22 - Clone MS SQL Select Continue to complete the Clone MS SQL process. When the clone operation is completed. Cohesity recommends executing Tear Down Clone to release all resources when the cloned database is not required anymore (see figure 23). A tear down process will delete the cloned database and any changes made to the database will be lost. Summary Figure 23 - Tear Down Clone Cohesity DataProtect provides a comprehensive solution to your data center storage requirements. A Cohesity DataProtect is not just for backups, but a solution that consolidates data protection, consolidate files, object services, and provides instant access to test/dev copies, on a single platform. Data centers with Cohesity DataProtect can also perform in-place searches and analytics. IT administrators, application and database administrators can rely on Cohesity DataProtect to store and safeguard business applications, and corporate data without compromises. About the Author Dominic Cheah is a Technical Marketing Engineer at Cohesity. In his role, Dominic focuses on business-critical applications, databases, and data protection with Enterprise and Cloud Storage. Version History Version Date Document Version History Version 1.0 Nov 2017 Original Document Cohesity, Inc. Address 300 Park Ave., Suite 800, San Jose, CA contact@cohesity.com 2018 Cohesity. All Rights Reserved Cohesity, All Rights Reserved 16.