SQL Server 2008 Cluster-to-Standalone Protection using Double-Take Availability 6.0

SQL Server 2008 Cluster-to-Standalone Protection using Double-Take Availability 6.0


The following video demonstrates how to protect SQL Server 2008 that is running on a Windows Server 2008 R2 Failover Cluster, to a standalone installation of SQL Server 2008 using Double-Take Availability 6.0.

The demonstration specifically details:
  • Viewing the cluster and clustered SQL components/data
  • View the SQL install on the standalone target/standby server
  • Configure the Double-Take job using the Double-Take Console
  • Monitor the Double-Take job (mirroring and replication) also includes movement of cluster resources between cluster nodes to show that cluster as a whole is being protected
  • Fail (shutdown) the cluster and watch failover of SQL Server to standalone target server
  • On failed over target server, add data to SQL Server
  • Re-introduce cluster
  • Restore data (online) from failed over target to the cluster, including demonstrating real-time replication
  • Failback to cluster from the standalone failed over target
  • Validate current data is present on the cluster
  • Restart Double-Take job (to re-protect cluster to standalone target server)
  • Validate the cluster is functional by once again switching cluster resources from one node to the other.


Demonstration


YouTube Video : SQL Server 2008 Cluster-to-Standalone Protection using Double-Take Availability 6.0

Double-Take SQL Server Protection Requirements

In addition to the Core Double-Take requirements (see Double-Take User Guide), you must also meet the following requirements to protect SQL.
  • SQL versions—Double-Take can protect Microsoft SQL Server or Express 2005, 2008, 2008 R2, or 2012.
  • SQL and network configuration—The following requirements and limitations apply to your SQL server and network configuration.
  • All Microsoft best practices should be used for all versions of SQL.
  • You should use the same version, service pack, and architecture (32-bit or 64-bit) of SQL Server on both the source and target servers.
  • If you are using SQL 2008 R2, cluster to cluster configurations are supported, however, the AlwaysOn cluster feature is not supported.
  • If you are using SQL Express 2008, you will need to enable and start the SQL Browser Service. By default, this service is set to disabled. Additionally, you will need to enable TCP/IP to accept remote connections. To do this, launch the SQL Server Configuration Manager. Expand SQL Server Network Configuration, and under Protocols enable TCP/IP.
  • If you are using SQL Express 2005, you will need to enable named pipes and TCP/IP to accept remote connections. To do this, launch the SQL Server Configuration Manager. Expand SQL Server 2005 Network Configuration, and under Protocolsenable Named Pipes and TCP/IP.
  • The SQL program files must be installed in the same location on the source and target.
  • The drive letter(s) where SQL stores its data on the source must be the same on the target.
  • The source and target servers must have named instances with the same name installed prior to configuring protection.
  • Single-label DNS domain names (those without a suffix such as .com, .corp, .net) are not supported.
  • In environments where the FIPS security policy is enabled, you must use impersonation, which requires the following.
  • The user running the Double-Take Console must have all appropriate rights to update the domain (that is, only impersonation is supported).
  • You must manually verify DNS rights by running the DFO utility with the /test parameter.
  • Microsoft Server Core is not supported.
  • If your source and target are in a domain, they should be in the same domain. If they are not, the SQL Server service on both the source and target servers must be configured to start with the same domain user account.
  • If your source and target are in a workgroup, make sure the source server's NIC does not register the IP addresses with DNS.
  • If you are using SQL 2005 or later and are using a domain service account that is not in the domain or local Administrators security group, the replicated databases will not mount on the target after failover or on the source after restore because of security restrictions at the file system level. You need to place the SQL 2005 service account in the local Administrators group on the source and target because of the way these versions of use local groups for NTFS permissions.
  • You may want to exclude the tempdb database to reduce mirroring and replication traffic.
  • Transparent Data Encryption (TDE) is supported for SQL 2008, however the SQL service must be running with the same service account on the source and target.
  • You should use a domain user account as the Windows Service Account for SQL. See "Setting up Windows Service Accounts" on the Microsoft web site for more information. You should include this account in the local Administrators group on your source and target to ensure that the appropriate permissions for the replicated databases and log files will be available after failover and failback.
  • Double-Take does not support a SQL default instance that is using non-default ports.
  • Supported configurations—The following table identifies the supported configurations for a SQL job.
Configuration Supported Not Supported
One-to-one, active/standby X
Source to target configuration One-to-one, active/active X
Many-to-one X
One-to-many X
Chained X
Single server X
Standalone-to-standalone X
Standalone-to-cluster X
Cluster-to-cluster X
Server configuration Cluster Shared Volumes (CSV) guest level X
Cluster Shared Volumes (CSV) host level X



Article ID: SLN310463

Last Date Modified: 08/14/2018 03:52 AM


Rate this article

Accurate
Useful
Easy to understand
Was this article helpful?
Yes No
Send us feedback
Comments cannot contain these special characters: <>()\
Sorry, our feedback system is currently down. Please try again later.

Thank you for your feedback.