Hyper-Converged Failover Cluster for SQL Instance Configuration and ...

Hyper-Converged Failover Cluster for SQL Instance Configuration and Installation Guide Lenovo Storage DX8200D

January 2018

Lenovo.com/systems

Lenovo Install Guide

Hyper-Converged Failover Cluster for SQL Instance

Hyper-converged Failover Cluster for SQL Instance Configuration and Installation Guide. Lenovo Storage DX8200D General Information This document provides an overview of the configuration and installation steps of Windows Server Failover Cluster creation for SQL Server instance on top of DCS two-node server group deployed through ADK process. The process applied only to the DX8200D series servers based on DataCore SANsymphony PSP6U4 installed on Microsoft Windows Server 2012 R2 and Microsoft SQL Server 2016 SP1. The document assumes that the DX8200D is solely used for the hyper-converged SQL Cluster setup and no storage is provided to external hosts. The procedure instructs to start/stop the DataCore virtualization and reboot servers multiple times without further pre-checks. Logical solution overview on the diagram below:

2



Windows Server Failover Cluster Environment

Failover Cluster Client network communication Client Application Services

DataCore Environment connections

CLIENT NETWORK

Cluster Instance

SQL Server Instance

CSV

SERVER 1

Mirrored Virtual Disks

SERVER 2

3



Overall network architecture of the solution shown on the diagram below: Server 1

Microsoft Failover Cluster Instance SQL Server Instance

Server 2

CSV

Heartbeat

LOM NIC

| 1 Gbit Link |

LOM NIC

LOM NIC

| 1 Gbit Link |

LOM NIC

iSCSI-BE-01

| 10 Gbit Link |

iSCSI-BE-02

Redundant Switch Infrastructure

| 10 Gbit Link |

iSCSI-BE-01

| 10 Gbit Link |

iSCSI-BE-02

Client Network

Virtualization Service

Heartbeat

NIC Team Switch Independent Cluster + Prod Management

Management

Communication Service

Microsoft Failover Cluster Instance SQL Server Instance

Client Network

NIC Team Switch Independent Cluster + Prod

DataCore Service

CSV

iSCSI-MR-01 I/T

DataCore Service

iSCSI-MR-01 I/T

| 10 Gbit Link |

Communication Service

vEthernet NIC iSCSI-MR-02 iSCSI-MR-01 I/T I/T

iSCSI-MR-02 I/T

iSCSI-FE-01 I/T

| 10 Gbit Link |

iSCSI-FE-02 I/T

| 10 Gbit Link |

Redundant Switch Infrastructure

| 10 Gbit Link |

vEthernet NIC iSCSI-FE-01 I/T

| 10 Gbit Link |

vEthernet NIC iSCSI-MR-02 iSCSI-FE-02 I/T

Virtualization Service

Steps overview: 1. ADK post deployment configuration. 2. Windows Updates. 3. Domain join. 4. Installation and configuration of the Windows Server Failover Cluster.

4



5. Installation of a SQL Server Failover Cluster instance (FCI).

5


1.


ADK post deployment configuration After ADK deployment completed, there are few additional configurations needed: - Reconfigure Back End and “Onboard-Team” interfaces; - Adjust Cache size; - IP Addresses and connections to FE ports configuration; - Mirrored virtual disks creation and serving; - Windows partition creation on served mirrored virtual disks.

Reconfigure Back End and “Onboard-Team” interfaces 1. Reconfigure Back End (BE) interfaces Important note! iSCSI-BE network interfaces (named through ADK deployment as “Slot4_Bottom_iSCSI-BE-01” and “Slot-8_Left_iSCSI-BE-02” in the Windows OS and with “_” prefix in the DataCore Management Console) connection must reside in the same network as “Onboard-Team” NIC Teaming interface and have access to DNS, Active Directory, SQL Server client infrastructure. Be aware that BE interfaces after operations proceeded in paragraphs 1.1-2.2, will be part of the client connectivity network for the failover cluster itself and SQL Server failover cluster instance clients. Note! It is good practice to rename network interfaces in the Windows OS and DataCore Management Console, as well as cluster networks in the Cluster Console (discussed later in this document) according their purpose, for ease of management. 1.1. Rename iSCSI-BE network interfaces in the Windows OS according their new role as a NIC team members. It can be done by navigating to Windows “Control Panel”, “Network and Internet”,” Network and Sharing Center” and select “Change adapter settings”. For example, “Slot-4_Bottom_iSCSI-BE-01” may be renamed to “Slot-4_Bottom__OnboardTeam” and “Slot-8_Left_iSCSI-BE-02” interface to “Slot-8_Left__Onboard-Team”.

6



Example below:

2. Reconfigure “Onboard-Team” interface 2.1. Before going further, on both DataCore servers, add renamed iSCSI-BE interfaces to the “Onboard-Team” NIC teaming interface. To proceed this operation, open Windows “Server Manager”, navigate to “All Servers” pane, choose server, right click on it and choose “Configure NIC Teaming” item. In the “Teams” window choose “Onboard-Team”, right click, open properties; checkbox renamed BE interfaces and apply like shown on the screenshot below:

7



Wait until state of the former iSCSI-BE interfaces became “Active”. 2.2. Remove 1Gb NICs (Mid-Left and Most-Left Onboard-LOM interfaces) from the “OnboardTeam” NIC team. To do this, locate in the NIC Teaming properties 1Gb interfaces which are in “Active” state, uncheck and apply. After configuration applied, open “Additional properties” menu; in the “Standby adapter” menu choose one of renamed BE interfaces as standby adapter and apply. Note! The “Onboard-Team” NIC Teaming interface is configured to use Active/Standby model of work. This approach is chosen to avoid switch interconnectivity issues and problems related to network protocols extended configuration. Active/Standby model is simpler to set up. The NIC Teaming interface still work in “Switch Independent” mode.

8



Here is an example of standby configuration:

9



After NIC Teaming configuration finished, there are four 1Gb LOM network interfaces available for cluster internal use. Note! After adding BE interfaces to the NIC team, in the DataCore Management Console the one BE-port will go away. This is expected because it is added to the team. The other port is remaining, as the team gets the MAC of the primary adapter, which then is identified by DataCore software. Unused onboard interfaces should be disabled as they otherwise bring up own targets which either should be configured, or not being existent at all. 2.3. Open the DataCore Management Console and connect to deployed Server Group (default group name is “DataCore”). For each server, right click on server and run “Rescan Ports”. 2.4. Navigate to “Server Ports” menu (on each server) and verify that ports status similar discussed in previous note. Example in the screenshot:

2.5. Rename the healthy BE interface according name given to Windows NIC as shown in example below. In this example, in the DCS console BE interface with name “SERVERSAN-2_Slot-4_Bottom_iSCSIBE-01” renamed to “SERVERSAN-2_Slot-4_Bottom_Onboard-Team”

10



2.6. Rename and deselect roles assignment of another BE interface which now has name like “Server iSCSI Port 12 [FE, MR]” as shown in the example below. In this example, in the DCS console BE interface with name “Server iSCSI Port 12 [FE, MR]”” renamed to “SERVERSAN-2_Slot-4_Bottom_Onboard-Team” with disabled roles:

2.7. Delete the absent BE port with status “Not present” like shown in the screenshot below:

11



Adjust Cache size 1. Configure cache size Note! To avoid unpredictable situation with server memory usage by DataCore server and SQL Server instance, adjust the cache size to 32Gb on each DataCore server. 1.1. Open the DataCore Management Console and connect to deployed Server Group (default group name is “DataCore”), choose server, navigate to “Settings” pane, expand “Cache Settings” menu, choose “Set cache size to:” box and set cache to 32Gb, apply the setting. Example can be seen on the screenshot below:

In order to make this setting active, choose server again, right click, choose “Stop DataCore Server” and wait until the server state became “Stopped”; then right click on the server again and choose “Start DataCore Server”. Wait until the server state became “Running” and then proceed with next DataCore server. 1.2. Verify that cache settings applied; it can be seen in the “Info” tab and in the “Cache” field of

12



the server’s panel in console, like shown on the screenshot below:

13



IP Addresses and connections to FE ports configuration 1. Check if Mirror ports connections are active. 1.1. Open the DataCore Management Console and connect to deployed Server Group (default group name is “DataCore”), choose server and open the “Server Ports” menu, locate initiator port and mirror ports (“MR” in the name by default); 1.2. Choose “Remote Ports” tab and verify that server’s initiator logged in to remote mirror ports and server’s mirror ports logged in by remote server’s initiator. Here is an example on the screenshot.

2. Verify that Front End ports are in healthy state. 2.1. In the DataCore Management Console navigate to front end ports (“FE” in the name). Ports should have green icons. “Not connected” status will change after FE ports will be used by initiators. 2.2. Verify that the IP addresses are assigned correctly to the FE ports. IP address can be seen in the “IP address” field near the status icon.

14



3. Configure FE ports. Note! Be careful configuring IP addresses on the FE ports. They are very important for further iSCSI connections configuration. Both FE ports of both servers must be accessible from within one Layer 2 network. Don´t apply any type of routing.

15



Required physical cable connection for Frontend-Ports is shown on the diagram below. While this seems unexpected to connect one server to one switch only, this is necessary to ensure the connection of at least one server keeps up, if one switch fails: Switch Uplink connection FE to Switch 10G cable link

Server 2

Server 1 iSCSI-FE-01 I/T

iSCSI-FE-02 I/T

SWITCH 1

iSCSI-FE-01 I/T

iSCSI-FE-02 I/T

SWITCH 2

3.1. Configure IP addresses in the same network subnet for the FE ports on both servers. Here is an example how the first server configured in the server group to meet this step.

3.2 Check TCP-IP-connectivity between servers: SRV01 - SRV01 iSCSI-FE-01 to SRV01 iSCSI-FE-02 - SRV01 iSCSI-FE-02 to SRV01 iSCSI-FE-01 - SRV01 iSCSI-FE-01 to SRV02 iSCSI-FE-01

16



- SRV01 iSCSI-FE-02 to SRV02 iSCSI-FE-02 SRV02 - SRV02 iSCSI-FE-01 to SRV02 iSCSI-FE-02 - SRV02 iSCSI-FE-02 to SRV02 iSCSI-FE-01 - SRV02 iSCSI-FE-01 to SRV01 iSCSI-FE-01 - SRV02 iSCSI-FE-02 to SRV01 iSCSI-FE-02 Simple test to check it using PowerShell: Test-NetConnection -ComputerName “FE_IP_Address” -Port 3260 3.3. After IP addresses configuration and TCP-connection check, navigate to each server in the DataCore Management Console, right click and choose “Rescan Ports”.

4. Configure iSCSI initiator connections (with MPIO support). 4.1. Open “iSCSI initiator” tool from the Windows “Server Manager”. Proceed this operation on both servers. Discover FE related target portals with explicit IP addresses of Initiator: - discover local server FE target portals with cross connection between server’s FE ports (local FE01 act as initiator for local FE-02 portal, local FE-02 act as initiator for local FE-01 portal); - discover remote server FE target portals (local FE-01 act as initiator for remote FE-01 portal, local FE-02 act as initiator for remote FE-02 portal).

17



The logical configuration is shown on the diagram below: Initiator to Target connection direction

SERVER 1

SERVER 2

iSCSI-FE-01 I/T

iSCSI-FE-01 I/T

iSCSI-FE-02 I/T

iSCSI-FE-02 I/T

Here is an example on the screenshot of Front End only connections from the first server in the group:

4.2. Open the “Targets” and connect to the FE targets on both servers: - set the checkbox “Enable multi-path”; - connect targets using explicit configuration (as described on paragraph 4.1 for discovery process by selecting the source IP address of each iSCSI connection); - verify that targets are in the “Connected” status and listed in the tab “Favorite Targets”.

18



Example on the screenshot:

4.3. Check if FE and Initiator ports are connected in DataCore console as described in paragraph 1. Connections to the both server FE portal from each server’s Initiator should be seen. Example Initiator connections from the first server in the group:

19



Mirrored virtual disks creation and serving 1. Create virtual disks. Note! At least a minimum of two virtual disks for failover cluster configuration and SQL Server instance are needed: - small virtual disk as a Witness disk in cluster quorum (minimal size 512 Mb); - suitable virtual disk as Cluster Shared Volume for SQL Server instance installation. Concrete virtual disk(s) configuration and size depends on the application consuming the SQL Server failover cluster instance. Sizing and design topic of SQL Server failover cluster instance is out scope for this installation guide. Note! Be aware that all virtual disks created for failover cluster purpose must be mirrored. 1.1. In the DataCore Management Console navigate to the “Virtual Disks” item, right click and choose “Create Virtual Disks”: - assign proper name, size and other needed properties, choose Type “Mirrored”, configure reservation (if needed) and click Next; - verify that “Step 2” contains both DataCore servers and Source type is Disk pool, click Next; - if needed configure advanced options (such as disk reservation, which would prevent oversubscription of the storage pool) and click Finish. Proceed with similar virtual disk creation operation for all disks which needed. 1.2. Verify that Virtual Disks in healthy state; navigate to the “Virtual Disks” in the DataCore Management Console and choose virtual disk. Every virtual disk should have: - icon with status “On-line”; - “Data status” in the “Info” tab “Up to date” for both DataCore servers; - All paths in “Active” state below the “Path” tab. Note! Even, if virtual disks in “On-line” and “Up to date” states, it may take some time until all paths are showing “Active” state. Sample example on the screenshots below:

20



21



2. Serve virtual disks (both servers) Note! All mirrored virtual disks should be served to servers in “Redundant path” mode. Note! Even if not technically necessary, it is good practice to use/ensure consistent LUN numbers for both servers to be able to easily identify disks 2.1. In the DataCore Management Console navigate to the “Virtual Disks” item, right click and choose “Serve to Hosts”; select both hosts (shift down) and click Next; on the “Select Paths” step choose “Redundant path” and click Finish. Warning popup will occur, click “Yes” to finish serving operation. Proceed similar steps for every virtual disk which will be used as a disk resource in failover cluster. 2.2. Verify the served virtual disks status by choosing virtual disk in the DataCore Management Console: - “Info” tab should contain names of the servers, which virtual disks served to in the “Host(s)” item; - “Paths” tab should list all connections for the virtual disk (Front End and Mirror connections) with “Active” state. 2.3. In the DataCore Management Console navigate to the “DataCore Disks” item, choose the recently served virtual disk. Switch to “Paths” tab. The list of active connections (two connections for each initiator) should be seen. Note! Before paths become “Active” they will be shown as “Connected” state. Please, be patient and wait until paths became “Active”. Sample example on the screenshot below:

22



2.4. Run as administrator PowerShell Console or CMD console on both servers and use “mpclaim.exe” command line utility to check if MPIO configuration correct. Command syntax: mpclaim.exe -v “Path to result file”. Here is the example:

Review the log file created. If everything configured properly each served mirrored virtual disk with redundant paths, will have four paths: - two “Active/Optimized”; - two “Active/Unoptimized”. To identify disks in the result file, proceed with the steps: a) Run PowerShell as administrator and use cmdlet Get-Disk to search DataCore Multi-Path disks Unique IDs: Get-Disk -FriendlyName "DataCore*Multi*Path*" | ft -Property Number, UniqueId, FriendlyName –AutoSize In result will be Unique ID (UniqueId field) for each served mirrored disk through redundant paths. See screenshot example below:

b) Open “mpclaim.exe” result file and find the disks with the SN fields equal to Unique IDs.

Windows partition creation on served mirrored virtual disks

23



1. Create Windows partition. Note! Disk formatting procedure can take long even if “Perform a quick format” option chosen. This behavior is expected and related to the “TRIM” or “SCSI UNMAP” command. To avoid long formatting procedure the system can be instructed to avoid using these commands. This is done through “fsutil” command line utility. For further instructions see Q&A article with ID 1544 available by link https://datacore.custhelp.com/app/answers/detail/a_id/1544/kw/disable%20delete. 1.1. On one of the servers open Windows Disk Management console, rescan disks, bring served disks online, initialize disks, and create NTFS volume with proper configuration. Rescan disks on the second server.

2.

Windows Updates Run Windows updates process on both nodes and reboot them sequentially. Prior rebooting next DCS server, check if: - servers interconnected and in healthy state; - connection from initiator to Front End and Mirror ports are active; - mirrored virtual disks in healthy state and all paths are active. The complete Windows update process may take from 30 minutes to 3 hours. All available - important and optional - updates should be installed. Consider skipping “preview” marked monthly update rollups.

3.

Domain join 1. Run domain join procedure on each server sequentially. 1.1. Prior rebooting next DCS server, check if: - servers interconnected and in healthy state; - connection from initiator to Front End and Mirror ports are active; - mirrored virtual disks in healthy state and all paths are active.

Note! Onboard management interface (NIC team interface) should be properly configured and have access to the DNS and Active Directory servers.

24



Note! If the Active Directory environment is strict and there is special OU for the DX8200D computers as well as failover cluster objects, consider following approach: - User account which used for join DataCore servers to domain, should have enough privileges to create computer objects in the given OU and to delegate control to the objects on the OU level; - Run PowerShell cmdlet “Add-Computer” to join Servers to the given OU. Below the example:

1.2. To use domain user as administrator in the DataCore Server Group, Open the DataCore Management console, in the top ribbon choose “Common Actions” and “Register User”; then type user name in format “DOMAIN\UserName”(and fill other needed field), choose role “Full Privilages” and push “Register”. Note! It is possible to use one domian user as a DataCore administrator and as a cluster administrator.

25


4.


Installation and configuration of the Windows Server Failover Cluster. This step includes few sub steps: - Installation of the Windows Server Failover Cluster Feature on the DataCore servers; - Failover cluster creation; - Failover cluster configuration (networks, quorum, disks) Note! Official documentation about Windows Server 2012 R2 Failover Clustering available by the link https://technet.microsoft.com/en-us/library/hh831579(v=ws.11).aspx

Installation of the Windows Server Failover Cluster Feature on the DataCore servers Using Windows “Server Manager” tool run the “Add Roles and Features Wizard”, choose the server, navigate to the feature selection, choose “Failover Clustering” and finish the installation. Proceed this operation for both DataCore servers.

Failover cluster creation Creation of failover cluster consists of two steps: - validation Wizard; - cluster creation. Note! Before running failover cluster creation Wizard consider to define proper names and IP addresses for the cluster and SQL Server instance. This Names and IP Addresses will used for cluster objects creation in the Active Directory and DNS records for proper cluster name resolution. During cluster installation, the Wizard will show a window for cluster name and IP address. Note! User, which runs the cluster installation Wizard, should have: a) Proper privileges on both servers (Administrator) and on the OU level in Active Directory. If user running Wizard is Active Directory Domain Administrator, it is easiest way to deploy failover cluster. Default container for the failover cluster is “Computers”. b) If user running cluster deployment Wizard is not member of the Domain Administrators (in strict Active Directory environment), then user must have enough permissions in the given OU. Minimal required permissions: “Create Computer Objects” and “Read All Properties”. 26



Also user must be a local Administrator on both servers. More information about user accounts in strict Active Directory environment can be found in the TechNet article https://technet.microsoft.com/en-us/library/9965eec5-2500-4038-b4e8ae1dfb7d9ec9

1. Run failover cluster installation Wizard 1.1. Before running Wizard, for the validation time period, disable IMM network adapter on both DataCore servers (name of the adapter, given through ADK deployment is “IMM-InterfaceLENOVO__unconfigured”). 1.2. Using Windows “Server Manger” open “Failover Cluster Manager” console and choose “Create Cluster”. Add DataCore server names and proceed with validation Wizard. Important Note! All tests must be chosen and proceeded by validation wizard! Safe of the result as it may be needed later on. 1.3. Review the validation report. For proper failover cluster creation and configuration, the validation report should be without errors (there might be warnings, but warnings are suitable for further cluster creation operation). Good status of report is “Testing has completed successfully”. If there are errors in the validation report, review them and fix. Save validation report. Only after that start the process again. 1.4. After validation Wizard finished, enable IMM network adapters on both servers.

2. Continue with failover cluster installation Wizard 2.1. After validation process finished proceed with further Wizard’s steps. Type NetBIOS name and IP address for the failover cluster. Here is an example on the screenshot :

27



Note! If failover cluster computer object (CNO) needs to be on the specific OU (for example, in strict Active Directory environment), the cluster name should be in the format of distinguished name as shown on the screenshot below:

28



2.2. On the “Confirmation” page of the Wizard, there is a checkbox which allows to add all available disks to the cluster. Uncheck the box without worries and add disks later. Click Next to create cluster and after click Finish to close the information window. If disks were not added during the installation, then a warning message will occur related to the quorum configuration. The message can be ignored. The quorum configuration will be issued in the next step. 2.3. Once failover cluster created check the OU (either “Computers” or given OU) for cluster object existence with the name provided during cluster installation Wizard. 2.4. Open “Failover Cluster Manager” and try to connect to the cluster name.

29



Here is an example screenshot of a newly created cluster:

Navigate to the “Cluster Core Resources” and check if cluster name and IP address in “Online” status.

30



Failover cluster configuration (networks, quorum, disks) 1. Configure cluster networks Note! For the Cluster internal usage (CSV, heartbeat) a minimum of two 1Gbit network interfaces is needed. For example, Mid-Right and Most-Right LOM NICs may be used to achieve this requirement. Yet, all four 1Gb network interfaces might be used for Cluster networking to increase bandwidth for the CSV cluster network. Note! To be discovered by Cluster networking subsystem, network interfaces must reside in different network subnets. 1Gbit interfaces need to be configured according this requirement. For example, if used two 1Gb NICs for Cluster only communication, then IP addresses for the NICs should be configured from two different subnets on each server. For example: - NICs named “Onboard-LOM_Mid-Right” on both servers have IP Address in 192.168.101.0/24 subnet (Server 1 – 192.168.101.1, Server 2 – 192.168.101.2); - NICs named “Onboard-LOM_Most-Right” on both servers have IP Address in 192.168.102.0/24 subnet (Server 1 – 192.168.102.1, Server 2 – 192.168.102.2); Verify ICMP connectivity between each server. To check that all work in proper manner, use ping command line utility or PowerShell cmdlet Test-Connection. Examples: a) ping 192.168.101.2 (from Server 1) ping 192.168.102.2 (from Server 1) b) ping 192.168.101.1 (from Server 2) ping 192.168.102.1 (from Server 2) Note! Due to increasing the redundancy of the Cluster only network connections based on 1Gb NICs, consider to use more than one network switch and/or use cross-over direct cable connection at least for one pair of 1Gb NICs between servers. Note! To increase performance of Client connectivity, it is possible to add additional 10Gb network card to the server (for example to Slot 6). Then repeat the steps of adding NIC to the NIC teaming group and proceed Cluster network configuration (if needed).

31



1.1. Rename the cluster network to match their function. Open the “Failover Cluster Manager” navigate to the “Networks” pane, choose each network. Identify the network association with the NICs; to do this navigate to the “Network Connections” tab below of each network as shown on the example screenshot below for the network named “Cluster Network 1”:

32



1.2. Rename each network matching their function in the properties of chosen network as shown on the example screenshot below. On the example “Cluster Network 1” renamed to “Management_and_Production”:

1.3. Final result may be like seen on the example screenshot below:

33



1.2. In the “Failover Cluster Manager” navigate to the “Networks” pane and proceed with network configuration. Choose the network and assign the cluster network communication role. Important Note! Consider following configuration for the networks: - IMM, FE and MR 10Gb interfaces based Cluster networks should be configured to “None” for Cluster use. It can be done by choosing the option “Do not allow cluster network communication on this network” as shown on the example screenshot below:

34



- Onboard management interface (“Onboard-Team”) based Cluster network should be configured for “Cluster and Client” use as shown on the screenshot:

35



- 1Gb LOM interfaces based Cluster networks should be used for “Cluster Only”, as seen on the example screenshot below:

For each Cluster network based on 1Gb interface and assigned to “Cluster only” usage, run PowerShell cmdlet to manually assign a “Metric” value below 1000 (for example - 800). This ensures that the cluster uses the interface for the CSV traffic. Note! It must be the lowest metric being configured. Syntax: (Get-ClusterNetwork “Cluster Network Name”).Metric = 800 Screenshot:

36



To check metric configuration for all networks run cmdlet Get-ClusterNetwork: Get-ClusterNetwork | Sort Metric | ft -Property Name, Metric, Address -AutoSize Screenshot example:

1.2. After cluster network configuration finished, in the “Networks” pane, check the networks status – it should be “Up”. See the screenshot example below:

37



1.3. Check a status of the cluster object network name and IP address as described in paragraph 2.4 of the topic “Failover cluster creation”. Note! If failover cluster is configured side by side with the DataCore software (up to version 10.0.6.5), there is a known behavior: An additional DataCore server port will be displayed after each server reboot leaving the old port in “unavailable state”. The name is similar to “Server iSCSI Port 29”. The status of the port will be “Not Connected” and IP address assigned from APIPA range like “169.254.2.201”. FE and MR roles will be assigned automatically. It is good / recommended practice to uncheck the roles assignment and apply configuration. “Unavailable” ports can be ignored or deleted Here is an example on the screenshots below: 1) New port “Server iSCSI Port 29” discovered after reboot.

2) The port “Server iSCSI Port 29” became “Not Present” after next reboot.

38



Note! Be aware that after proceeded operations in paragraph 4.2 of the current section, the DataCore software will assign two new iSCSI target ports and will name them in same manner as described in previous note; FE and MR roles will be assigned to the ports automatically. Uncheck the roles assignment and apply configuration. Ports can be renamed to further distinguish these ports and ports generated after every server reboot (as described in previous note).

39



2. Add disks 2.1. Open “Failover Cluster Manager” console and navigate to “Storage”,” Disks” item, right click and chose “Add Disk”. Choose disks – witness disk and disk for SQL Server instance installation (and other disks if created and served). 2.2. Navigate again to the “Disks” item and check the status of added disks. They should be in “Online” status as shown on the screenshot below:

3. Configure quorum 3.1. Before configuring a quorum, set the quorum arbitration time parameter. This is necessary to ensure correct cluster operation. To do it, open PowerShell as Administrator and run following commands: $cluster = Get-Cluster $cluster.QuorumArbitrationTimeMax = 60 See the screenshot below:

Verify that setting applied by the following command: $cluster = Get-Cluster $cluster.QuorumArbitrationTimeMax Note! More information about this topic can be found in the DataCore document “The Host Server Microsoft Windows Configuration Guide”. See paragraph “Microsoft Cluster Settings”. The document is available through the following link http://datacore.custhelp.com/app/answers/detail/a_id/1560/kw/host%20server.

40



3.2. In the “Failover Cluster Manager” navigate to the cluster name, choose it, right click and navigate to “More actions” and choose “Configure Cluster Quorum Settings…” like shown on the screenshot below:

41



Choose “Advanced quorum configuration”, on the next screen leave “All Nodes” without changes, on the next screen choose “Configure a disk witness” and on the step of selecting the proper disk choose small disk created for this purpose as shown on the screenshot:

42



Then proceed with the last steps and finish the Wizard. 3.2. Verify in the “Disks” pane that chosen disk now assigned to “Disk Witness in Quorum”. 3.3. Recommendation: Name the Cluster disks according to their usage. In the Failover Cluster Console navigate to Disks, choose each disk, right click, “Properties” item and change the name from default name. In the screenshot below can be seen changed “Cluster Disk 1” to “CSV01” and “Cluster Disk 2” to “Disk Witness”:

43



4. Create CSV volume 4.1. In the “Failover Cluster Manager” navigate to the “Disks” pane, choose disk(s) created and served to be CSV volume(s) (not witness disk), right click and choose the item “Add to Cluster Shared Volumes”. 4.2. In the “Disks” pane verify that chosen disk(s) now assigned to “Cluster Shared Volume”. 4.3. On the Windows Explorer navigate to the CSV default folder by the path “C:\ClusterStorage\”. For each cluster disk configured as CSV volume, in the given folder should be dedicated folder with format “Volume1” and so on. The full path to each CSV volume will be similar to this example: “C:\ClusterStorage\Volume1”. Check this folder on both DataCore servers and try to create/delete file there. Note! For ease of management it is good practice to change the name of the CSV volume folder available by path “C:\ClusterStorage\” to different, according the name of the cluster disk defined in the paragraph 3.3. 4.4. To change the name of the CSV folder, on one server, navigate to path “C:\ClusterStorage\”, choose CSV volume folder and rename it. Example shown on the screenshot below. On the example, the folder of the CSV volume “CSV01” renamed from “Volume1” to “CSV01”

Important Note! Be aware, operation of changing CSV folder name via Windows Explorer should be done before SQL Server instance installation and after instance installed this folder could not be renamed.

5.

Installation of a SQL Server Failover Cluster instance (FCI). This step includes few general sub steps:

44



- Create SQL Server failover cluster instance (FCI) on first server node; - Add second server to SQL Server FCI; - Additional post deployment steps. Note! Before starting the SQL Server failover cluster instance deployment, check if every requirement met: - failover cluster configured properly and in healthy state; - CSV volume(s) created on top of cluster disk with proper disk(s) configuration and size; - user running SQL Server installation have administrative privileges on the servers; - network name and IP address dedicated to the FCI are chosen; - review the official documentation for SQL Server failover cluster installation available by the link https://docs.microsoft.com/en-us/sql/sql-server/failover-clusters/install/sql-server-failovercluster-installation

1. Create SQL Server failover cluster instance (FCI) on first DataCore server node 1.1. Run “setup.exe” from the installation media of Microsoft SQL Server 2016, navigate to “Installation” pane on the installation Wizard window, choose “New SQL Server failover cluster installation”, on the next screens specify a “Product Key”, accept License Agreement, pass global rules and check box to check latest Microsoft updates; 1.2. On the step “Install Failover Cluster Rules” verify that there are no errors and check “Microsoft Cluster Service (MSCS) cluster verification errors” is in “Passed” status. It is possible that test related to WMI service will fail as shown on the screenshot below:

45



To resolve the issue, open Windows “Server Manager”, “Windows Firewall with Advanced Security”, choose “Inbound rules” and enable the rule “Windows Management Instrumentation (WMI-In)” on both DataCore servers. Example on the screenshot below:

1.3. On the next screen, choose “Database Engine Services” to install as illustrated on the screenshot below:

46



Pass the “Feature Rules” step. 1.4. Type the SQL Server FCI network name which will be used for client connectivity to the database engine and define database instance name (Default instance “MSSQLSERVER” or Named instance).

47



Here is an example:

1.5. On the “Cluster Resource Group” step verify that SQL Server resource group contains the database instance name and navigate to the “Cluster Disk Selection” step as shown on the

48



example screenshot below:

1.6. On the cluster network configuration, check box a network subnet, type IP Address.

49



Example:

1.7. On the “Server Configuration” step enter domain user account and password for database engine and agent services, choose “Perform Volume Maintenance Task privilege to SQL Server Database Engine Service” (if needed) and change collation settings (if needed). Note! During installation SQL server wizard assign needed permissions on the machine. 1.8. On the “Database Engine Configuration” step add SQL Server administrators (groups or user accounts) and define the Data Directories and TempDB configuration. Default configuration of the root directory is “C:\ClusterStorage\CSV01” (name of the CSV volume may vary). Note! Databases and their logs can be installed only to CSV volume.

50



Screenshot:

Pass next Wizard steps until installation complete.

1.8. Check if the files of the SQL Server installed and the SQL Server folder hierarchy located on the CSV volume by the path “C:\ClusterStorage\CSV01” (name of the CSV volume may vary).

51



Example on the screenshot:

1.9. Verify the state of the SQL Server FCI by navigating on “Failover Cluster Manager” console to roles pane. SQL Server FCI should have “Running” status as shown on the screenshot:

2. Add second DataCore server to SQL Server FCI 2.1. Run “setup.exe” from the installation media of Microsoft SQL Server 2016 on the second server, navigate to “Installation” pane on the installation Wizard window, choose “Add node to a SQL Server failover cluster”, on the next screens specify a “Product Key”, accept License Agreement, pass global rules and check box to check latest Microsoft updates; 2.2. On the step “Install Failover Cluster Rules” verify that there are no errors and check “Microsoft Cluster Service (MSCS) cluster verification errors” is in “Passed” status; 52



2.3. On the “Cluster Node Configuration” step, choose a SQL Server instance name; on the next step check box near the proper Cluster network subnet which contains SQL Server FCI IP address, like on the screenshot below:

2.4. On the “Service Accounts” page enter the passwords for the database engine and agent services user accounts and checkbox “Perform Volume Maintenance Task privilege to SQL Server Database Engine Service” (if needed). Proceed through last steps of the installation Wizard until second SQL Server FCI node will be installed. 2.5. On the “Failover Cluster Manager” console navigate to the “Roles” pane, choose the SQL Server FCI, right click and try “Move” action with selecting node; try to move instance to the second server and check if instance on “Running” status.

3. Additional post deployments steps 3.1. Configure Windows Firewall. Default TCP port used for the SQL Server FCI – 1433. Allow this port for inbound connection on both servers. The availability of the TCP port can be tested via PowerShell: Test-NetConnection -ComputerName “SQL Server FCI Name” -Port 1433 3.2. Re-configure SQL Server FCI access point IP address (if needed). If SQL Server FCI needed to bind to different Cluster network and/or IP address, on the “Failover Cluster Manager” console navigate to the “Roles” pane, choose the SQL Server FCI and below there is “Resources” tab; locate the network name and open properties for adding or changing current address configuration. 3.3. Configure SQL Server FCI failover policy. Note! Default failover policy for SQL Server FCI allows only one failure in six hours. If in this given period occurred more than one failures, then SQL FCI will left in failed state; to run SQL FCI in

53



such case, manual start action will be required. For testing purpose and/or according company’s failover requirements, configure this setting. In the “Failover Cluster Manager” console navigate to the “Roles” pane; choose the SQL Server FCI, right click and in the properties item there are settings related to failover behavior, possible owners and priority. Here is an example screenshot with default failover configuration:

54



LENOVO PROVIDES THIS PUBLICATION “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. This information could include technical inaccuracies or typographical errors. Changes may be made to the information herein; these changes will be incorporated in new editions of the publication. Lenovo may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any performance data contained herein was determined in a controlled environment; therefore, the results obtained in other operating environments may vary significantly. Some measurements may have been made on development-level systems, and there is no guarantee that these measurements will be the same on generally available systems. Furthermore, some measurements may have been estimated through extrapolation. Actual results may vary. Users of this document should verify the applicable data for their specific environment. Any references in this publication to non-Lenovo Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this Lenovo product, and use of those Web sites is at your own risk. Lenovo, the Lenovo logo, System x, and ThinkServer, are trademarks of Lenovo in the United States, other countries, or both. Intel and Xeon are trademarks of Intel Corporation in the United States, other countries, or both. Microsoft, Windows Storage Server 2012, Windows Server 2012, and the Windows Logo are trademarks of Microsoft Corporation in the United States, other countries, or both.

55

Hyper-Converged Failover Cluster for SQL Instance Configuration and ...

Hyper-Converged Failover Cluster for SQL Instance Configuration and ...

Suggest Documents

Download SQL Cluster Configuration for Autodesk ... - Under the Hood

Setup for Failover Clustering and Microsoft Cluster Service - VMware

Setup for Failover Clustering and Microsoft Cluster Service - VMware

Setup for Failover Clustering and Microsoft Cluster Service - VMware [PDF]

Setup for Failover Clustering and Microsoft Cluster Service - ESXi 5.1

Setup for Failover Clustering and Microsoft Cluster Service - ESXi 5.0

Setup for Failover Clustering and Microsoft Cluster Service - VMware

Setup for Failover Clustering and Microsoft Cluster Service - VMware

Setup for Failover Clustering and Microsoft Cluster Service - ESXi 5.1

[PDF] Download Pro SQL Server 2008 Failover Clustering - Google Sites

Impact of Pacemaker Failover Configuration on Mean Time to ...

PDF Pro SQL Server 2008 Failover Clustering - Google Sites

traditional vs cluster set configuration

Configuring a failover cluster on a Dell ... - Dell Community

SimpliVity Hyperconverged Infrastructure - Altcomp

SimpliVity Hyperconverged Infrastructure - Altcomp

Providing Failover for BGAN and FleetBroadband

SANchk: SQL-Based SAN Configuration Checking

infographic hyperconverged - SLIDEBLAST.COM

Lenovo Database Configuration for Microsoft SQL ... - Amazon AWS

Lenovo Database Configuration for Microsoft SQL Server 2016 â 6TB

Lenovo Database Configuration for Microsoft SQL Server 2014 â 95TB

Lenovo Database Configuration for Microsoft SQL Server 2016 â 6TB

Lenovo Database Configuration for Microsoft SQL Server 2014 â 7TB

Hyper-Converged Failover Cluster for SQL Instance Configuration and ...