SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

  • Home
  • Products
    • SIOS DataKeeper for Windows
    • SIOS Protection Suite for Linux
  • News and Events
  • Clustering Simplified
  • Success Stories
  • Contact Us
  • English
  • 中文 (中国)
  • 中文 (台灣)
  • 한국어
  • Bahasa Indonesia
  • ไทย

Step-By-Step: How to configure a SANless MySQL Linux failover cluster in Amazon EC2

August 18, 2020 by Jason Aw Leave a Comment

Step-By-Step: How to configure a SANless MySQL Linux failover cluster in Amazon EC2

Step-By-Step: How to configure a SANless MySQL Linux failover cluster in Amazon EC2

In this step by step guide, I will take you through all steps required to configure a highly available, 2-node MySQL cluster (plus witness server) in Amazon’s Elastic Compute Cloud (Amazon EC2). The guide includes both screenshots, shell commands and code snippets as appropriate. I assume that you are somewhat familiar with Amazon EC2 and already have an account. If not, you can sign up today. I’m also going to assume that you have basic familiarity with Linux system administration and failover clustering concepts like Virtual IPs, etc.

Failover clustering has been around for many years. In a typical configuration, two or more nodes are configured with shared storage to ensure that in the event of a failover on the primary node, the secondary or target node(s) will access the most up-to-date data. Using shared storage not only enables a near-zero recovery point objective, it is a mandatory requirement for most clustering software. However, shared storage presents several challenges. First, it is a single point of failure risk. If shared storage – typically a SAN – fails, all nodes in the cluster fails. Second, SANs can be expensive and complex to purchase, setup and manage. Third, shared storage in public clouds, including Amazon EC2 is either not possible, or not practical for companies that want to maintain high availability (99.99% uptime), near-zero recovery time and recovery point objectives, and disaster recovery protection.

The following demonstrates how easy it is to create a SANless cluster in the clouds to eliminate these challenges while meeting stringent HA/DR SLAs. The steps below use MySQL database with Amazon EC2 but the same steps could be adapted to create a 2-node cluster in AWS to protect SQL, SAP, Oracle, or any other application.

NOTE: Your view of features, screens and buttons may vary slightly from screenshots presented below

1. Create a Virtual Private Cloud (VPC)
2. Create an Internet Gateway
3. Create Subnets (Availability Zones)
4. Configure Route Tables
5. Configure Security Group
6. Launch Instances
7. Create Elastic IP
8. Create Route Entry for the Virtual IP
9. Disable Source/Dest Checking for ENIs
10. Obtain Access Key ID and Secret Access Key
11. Linux OS Configuration
12. Install EC2 API Tools
13. Install and Configure MySQL
14. Install and Configure Cluster
15. Test Cluster Connectivity

Overview

This article will describe how to create a cluster within a single Amazon EC2 region. The cluster nodes (node1, node2 and the witness server) will reside different Availability Zones for maximum availability. This also means that the nodes will reside in different subnets.

The following IP addresses will be used:

  • node1: 10.0.0.4
  • node2: 10.0.1.4
  • witness: 10.0.2.4
  • virtual/”floating” IP: 10.1.0.10

Step 1: Create a Virtual Private Cloud (VPC)

First, create a Virtual Private Cloud (aka VPC). A VPC is an isolated network within the Amazon cloud that is dedicated to you. You have full control over things like IP address blocks and subnets, route tables, security groups (i.e. firewalls), and more. You will be launching your Azure Iaas virtual machines (VMs) into your Virtual Network.

From the main AWS dashboard, select “VPC”

Under “Your VPCs”, make sure you have selected the proper region at the top right of the screen. In this guide the “US West (Oregon)” region will be used, because it is a region that has 3 Availability Zones. For more information on Regions and Availability Zones, click here.

Give the VPC a name, and specify the IP block you wish to use. 10.0.0.0/16 will be used in this guide:

You should now see the newly created VPC on the “Your VPCs” screen:

Step 2: Create an Internet Gateway

Next, create an Internet Gateway. This is required if you want your Instances (VMs) to be able to communicate with the internet.

On the left menu, select Internet Gateways and click the Create Internet Gateway button. Give it a name, and create:

Next, attach the internet gateway to your VPC:

Select your VPC, and click Attach:

 

Step 3: Create Subnets (Availability Zones)

Next, create 3 subnets. Each subnet will reside in it’s own Availability Zone. The 3 Instances (VMs: node1, node2, witness) will be launched into separate subnets (and therefore Availability Zones) so that the failure of an Availability Zone won’t take out multiple nodes of the cluster.

The US West (Oregon) region, aka us-west-2, has 3 availability zones (us-west-2a, us-west-2b, us-west-2c). Create 3 subnets, one in each of the 3 availability zones.

Under VPC Dashboard, navigate to Subnets, and then Create Subnet:

Give the first subnet a name (“Subnet1)”, select the availability zone us-west-2a, and define the network block (10.0.0.0/24):

Repeat to create the second subnet availability zone us-west-2b:

Repeat to create the third subnet in availability zone us-west-2c:

Once complete, verify that the 3 subnets have been created, each with a different CIDR block, and in separate Availability Zones, as seen below:

Step 4: Configure Route Tables

Update the VPC’s route table so that traffic to the outside world is sent to the Internet Gateway created in a previous step. From the VPC Dashboard, select Route Tables. Go to the Routes tab, and by default only one route will exist which allows traffic only within the VPC.

Click Edit:

Add another route:

The Destination of the new route will be “0.0.0.0/0” (the internet) and for Target, select your Internet Gateway. Then click Save:

Next, associate the 3 subnets with the Route Table. Click the “Subnet Associations” tab, and Edit:

Check the boxes next to all 3 subnets, and Save:

Verify that the 3 subnets are associated with the main route table:

Later, we will come back and update the Route Table once more, defining a route that will allow traffic to communicate with the cluster’s Virtual IP, but this needs to be done AFTER the linux Instances (VMs) have been created.

Step 5: Configure Security Group

Edit the Security Group (a virtual firewall) to allow incoming SSH and VNC traffic. Both will later be used to configure the linux instances as well as installation/configuration of the cluster software.

On the left menu, select “Security Groups” and then click the “Inbound Rules” tab. Click Edit:

Add rules for both SSH (port 22) and VNC. VNC generally uses ports in the 5900, depending on how you configure it, so for the purposes of this guide, we will open the 5900-5910 port range. Configure accordingly based on your VNC setup:

Step 6: Launch Instances

We will be provisioning 3 Instances (Virtual Machines) in this guide. The first two VMs (called “node1” and “node2”) will function as cluster nodes with the ability to bring the MySQL database and it’s associated resources online. The 3rd VM will act as the cluster’s witness server for added protection against split-brain.

To ensure maximum availability, all 3 VMs will be deployed into different Availability Zones within a single region. This means each instance will reside in a different subnet.

Go to the main AWS dashboard, and select EC2:

 

Create “node1”

Create your first instance (“node1”). Click Launch Instance:

Select your linux distribution. The cluster software used later supports RHEL, SLES, CentOS and Oracle Linux. In this guide we will be using RHEL 7.X:

Size your instance accordingly. For the purposes of this guide and to minimize cost, t2.micro size was used because it’s free tier eligible. See here for more information on instance sizes and pricing.

Next, configure instance details. IMPORTANT: make sure to launch this first instance (VM) into “Subnet1“, and define an IP address valid for the subnet (10.0.0.0/24) – below 10.0.0.4 is selected because it’s the first free IP in the subnet.
NOTE: .1/.2/.3 in any given subnet in AWS is reserved and can’t be used.

Next, add an extra disk to the cluster nodes (this will be done on both “node1” and “node2”). This disk will store our MySQL databases and the later be replicated between nodes.

NOTE: You do NOT need to add an extra disk to the “witness” node. Only “node1” and “node2”. Add New Volume, and enter in the desired size:

Define a Tag for the instance, Node1:

Associate the instance with the existing security group, so the firewall rules created previous will be active:

Click Launch:

IMPORTANT: If this is the first instance in your AWS environment, you’ll need to create a new key pair. The private key file will need to be stored in a safe location as it will be required when you SSH into the linux instances.

Create “node2”

Repeat the steps above to create your second linux instance (node2). Configure it exactly like Node1. However, make sure that you deploy it into “Subnet2” (us-west-2b availability zone). The IP range for Subnet2 is 10.0.1.0/24, so an IP of 10.0.1.4 is used here:

Make sure to add a 2nd disk to Node2 as well. It should be the same exact size as the disk you added to Node1:

Give the second instance a tag…. “Node2”:

Create “witness”

Repeat the steps above to create your third linux instance (witness). Configure it exactly like Node1&Node2, EXCEPT you DON’T need to add a 2nd disk, since this instance will only act as a witness to the cluster, and won’t ever bring MySQL online.

Make sure that you deploy it into “Subnet3” (us-west-2c availability zone). The IP range for Subnet2 is 10.0.2.0/24, so an IP of 10.0.2.4 is used here:

NOTE: default disk configuration is fine for the witness node. A 2nd disk is NOT required:

Tag the witness node:

It may take a little while for your 3 instances to provision. Once complete, you’ll see then listed as running in your EC2 console:

Step 7: Create Elastic IP

Next, create an Elastic IP, which is a public IP address that will be used to connect into you instance from the outside world. Select Elastic IPs in the left menu, and then click “Allocate New Address”:

 

Select the newly created Elastic IP, right-click, and select “Associate Address”:

Associate this Elastic IP with Node1:

Repeat this for the other two instances if you want them to have internet access or be able to SSH/VNC into them directly.

Step 8: create Route Entry for the Virtual IP

At this point all 3 instances have been created, and the route table will need to be updated one more time in order for the cluster’s Virtual IP to work. In this multi-subnet cluster configuration, the Virtual IP needs to live outside the range of the CIDR allocated to your VPC.

Define a new route that will direct traffic to the cluster’s Virtual IP (10.1.0.10) to the primary cluster node (Node1)

From the VPC Dashboard, select Route Tables, click Edit. Add a route for “10.1.0.10/32” with a destination of Node1:

Step 9: Disable Source/Dest Checking for ENIs

Next, disable Source/Dest Checking for the Elastic Network Interfaces (ENI) of your cluster nodes. This is required in order for the instances to accept network packets for the virtual IP address of the cluster.

Do this for all ENIs.

Select “Network Interfaces”, right-click on an ENI, and select “Change Source/Dest Check”.

Select “Disabled“:

Step 10: Obtain Access Key ID and Secret Access Key

Later in the guide, the cluster software will use the AWS Command Line Interface (CLI) to manipulate a route table entry for the cluster’s Virtual IP to redirect traffic to the active cluster node. In order for this to work, you will need to obtain an Access Key ID and Secret Access Key so that the AWS CLI can authenticate properly.

In the top-right of the EC2 Dashboard, click on your name, and underneath select “Security Credentials” from the drop-down:

Expand the “Access Keys (Access Key ID and Secret Access Key)” section of the table, and click “Create New Access Key”. Download Key File and store the file in a safe location.

Step 11: Configure Linux OS

Connect to the linux instance(s):

To connect to your newly created linux instances (via SSH), right-click on the instance and select “Connect”. This will display the instructions for connecting to the instance. You will need the Private Key File you created/downloaded in a previous step:

Example:

Here is where we will leave the EC2 Dashboard for a little while and get our hands dirty on the command line, which as a Linux administrator you should be used to by now.

You aren’t given the root password to your Linux VMs in AWS (or the default “ec2-user” account either), so once you connect, use the “sudo” command to gain root privileges:

$sudo su –

Unless you have already have a DNS server setup, you’ll want to create host file entries on all 3 servers so that they can properly resolve each other by nameEdit /etc/hosts

Add the following lines to the end of your /etc/hosts file:

10.0.0.4 node1
10.0.1.4 node2
10.0.2.4 witness
10.1.0.10 mysql-vip

Disable SELinux

Edit /etc/sysconfig/linux and set “SELINUX=disabled”:

# vi /etc/sysconfig/selinux

 

# This file controls the state of SELinux on the system. # SELINUX= can take one of these three values:

#   enforcing – SELinux security policy is enforced.

#   permissive – SELinux prints warnings instead of enforcing.

# disabled – No SELinux policy is loaded.

SELINUX=disabled

# SELINUXTYPE= can take one of these two values:

#       targeted – Targeted processes are protected, #       mls – Multi Level Security protection.

SELINUXTYPE=targeted

Set Hostnames

By default, these Linux instances will have a hostname that is based upon the server’s IP address, something like “ip-10-0-0-4.us-west-2.compute.internal”

You might notice that if you attempt to modify the hostname the “normal” way (i.e. editing /etc/sysconfig/network, etc), after each reboot, it reverts back to the original!! I found a great thread in the AWS discussion forums that describes how to actually get hostnames to remain static after reboots.

Details here: https://forums.aws.amazon.com/message.jspa?messageID=560446

Comment out modules that set hostname in “/etc/cloud/cloud.cfg” file. The following modules can be commented out using #.

# – set_hostname

# – update_hostname

Next, also change your hostname in /etc/hostname.

Reboot Cluster Nodes

Reboot all 3 instances so that SELinux is disabled, and the hostname changes take effect.

Install and Configure VNC (and related packages)

In order to access the GUI of our linux servers, and to later install and configure our cluster, install VNC server, as well as a handful of other required packages (cluster software needs the redhat-lsb and patch rpms).

# yum groupinstall “X Window System”

# yum groupinstall “Server with GUI”

# yum install tigervnc-server xterm wget unzip patch redhat-lsb

# vncpasswd

The following URL is a great guide to getting VNC Server running on RHEL 7 / CentOS 7:For RHEL 7.x/CentOS7.x:

https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-vnc-remote-access-for-the- gnome-desktop-on-centos-7

NOTE: This example configuration runs VNC on display 2 (:2, aka port 5902) and as root (not secure). Adjust accordingly!

# cp /lib/systemd/system/vncserver@.service /etc/systemd/system/vncserver@:2.serv

# vi /etc/systemd/system/vncserver@:2.service

[Service]

Type=forking

# Clean any existing files in /tmp/.X11-unix environment ExecStartPre=/bin/sh -c ‘/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :’

ExecStart=/sbin/runuser -l root -c “/usr/bin/vncserver %i -geometry 1024×768” PIDFile=/root/.vnc/%H%i.pid

ExecStop=/bin/sh -c ‘/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :’

# systemctl daemon-reload

# systemctl enable vncserver@:2.service

# vncserver :2 -geometry 1024×768

For RHEL/CentOS 6.x systems:

# vi /etc/sysconfig/vncservers

 

VNCSERVERS=”2:root” VNCSERVERARGS[2]=”-geometry 1024×768″

 

# service vncserver start

# chkconfig vncserver on

Open a VNC client, and connect to the <ElasticIP:2>. If you can’t get it, it’s likely your linux firewall is in the way. Either open the VNC port we are using here (port 5902), or for now, disable the firewall (NOT RECOMMENDED FOR PRODUCTION ENVIRONMENTS):

# systemctl stop firewalld

# systemctl disable firewalld

Partition and Format the “data” disk

When the linux instances were launched, and extra disk was added to each cluster node to store the application data we will be protecting. In this case it happens to be MySQL databases.

The second disk should appear as /dev/xvdb. You can run the “fdisk -l” command to verify. You’ll see that
/dev/xvda (OS) is already being used.

# fdisk -l

# Start End Size Type NameDisk /dev/xvda: 10.7 GB, 10737418240 bytes, 20971520 sectors Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk label type: gpt

1 2048 4095 1M BIOS boot parti
2 4096 20971486 10G Microsoft basic
Disk /dev/xvdb: 2147 MB, 2147483648 bytes, 4194304 sectors Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes

Here I will create a partition (/dev/xvdb1), format it, and mount it at the default location for MySQL, which is
/var/lib/mysql. Perform the following steps on BOTH “node1” and “node2”:

# fdisk /dev/xvdb

Welcome to fdisk (util-linux 2.23.2).

 

Changes will remain in memory only, until you decide to write them. Be careful before using the write command.

 

Device does not contain a recognized partition table

Building a new DOS disklabel with disk identifier 0x8c16903a.

 

Command (m for help): n

Partition type:

p      primary (0 primary, 0 extended, 4 free) e    extended

Select (default p): p

Partition number (1-4, default 1): 1

First sector (2048-4194303, default 2048): <enter>

Using default value 2048

Last sector, +sectors or +size{K,M,G} (2048-4194303, default 4194303): <enter>

Using default value 4194303

Partition 1 of type Linux and of size 2 GiB is set

 

Command (m for help): w

The partition table has been altered!

Calling ioctl() to re-read partition table. Syncing disks.

# mkfs.ext4 /dev/xvdb1
# mkdir /var/lib/mysql

On node1, mount the filesystem:

# mount /dev/xvdb1 /var/lib/mysql

The EC2 API Tools (EC2 CLI) must be installed on each of the cluster nodes, so that the cluster software can later manipulate Route Tables, enabling connectivity to the Virtual IP.

Step 12: Install EC2 API Tools

The following URL is an excellent guide to setting this up:

http://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/set-up-ec2-cli-linux.html

Here are the key steps:
Download, unzip, and move the CLI tools to the standard location (/opt/aws):

# wget http://s3.amazonaws.com/ec2-downloads/ec2-api-tools.zip

# unzip ec2-api-tools.zip

# mv ec2-api-tools-1.7.5.1/ /opt/aws/

# export EC2_HOME=”/opt/aws”

If java isn’t already installed (run “which java” to check), install it:

# yum install java-1.8.0-openjdk

# export JAVA_HOME=”/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.71-

Example (Based on default config of RHEL 7.2 system. Adjust accordingly)

You’ll need your AWS Access Key and AWS Secret Key. Keep these values handy, because they will be needed later during cluster setup too! Refer to the following URL for more information:

https://console.aws.amazon.com/iam/home?#security_credential

# export AWS_ACCESS_KEY=your-aws-access-key-id

# export AWS_SECRET_KEY=your-aws-secret-key

Test CLI utility functionality:

# /opt/aws/bin/ec2-describe-regions
REGION eu-west-1 ec2.eu-west-1.amazonaws.com
REGION ap-southeast-1 ec2.ap-southeast-1.amazonaws.com
REGION ap-southeast-2 ec2.ap-southeast-2.amazonaws.com
REGION eu-central-1 ec2.eu-central-1.amazonaws.com
REGION ap-northeast-2 ec2.ap-northeast-2.amazonaws.com
REGION ap-northeast-1 ec2.ap-northeast-1.amazonaws.com
REGION us-east-1 ec2.us-east-1.amazonaws.com
REGION sa-east-1 ec2.sa-east-1.amazonaws.com
REGION us-west-1 ec2.us-west-1.amazonaws.com
REGION us-west-2 ec2.us-west-2.amazonaws.com

Step 13: Install and Configure MySQL

Next, install the MySQL packages, initialize a sample database, and set “root” password for MySQL. In RHEL7.X, the MySQL packages have been replaced with the MariaDB packages.

On “node1”:

# yum install mariadb mariadb-server

# mount /dev/xvdb1 /var/lib/mysql

# /usr/bin/mysql_install_db –datadir=”/var/lib/mysql/” –user=mysql

# mysqld_safe –user=root –socket=/var/lib/mysql/mysql.sock –port=3306 –datadi

#

# # NOTE: This next command allows remote connections from ANY host.  NOT a good # echo “update user set Host=’%’ where Host=’node1′; flush privileges | mysql mys #

# #Set MySQL’s root password to ‘SIOS’

# echo “update user set Password=PASSWORD(‘SIOS’) where User=’root’; flush

Create a MySQL configuration file. We will place this on the data disk (that will later be replicated –
/var/lib/mysql/my.cnf). Example:

# vi /var/lib/mysql/my.cnf

 

[mysqld] datadir=/var/lib/mysql

socket=/var/lib/mysql/mysql.sock

pid-file=/var/run/mariadb/mariadb.pid user=root

port=3306

# Disabling symbolic-links is recommended to prevent assorted security risks symbolic-links=0

[mysqld_safe]

log-error=/var/log/mariadb/mariadb.log pid-file=/var/run/mariadb/mariadb.pid

 

[client] user=root password=SIOS

Move the original MySQL configuration file aside, if it exists:

# mv /etc/my.cnf /etc/my.cnf.orig

On “node2”, you ONLY need to install the MariaDB/MySQL packages. The other steps aren’t required:On “node2”:

[root@node2 ~]# yum install mariadb mariadb-server

Step 14: Install and Configure the Cluster

At this point, we are ready to install and configure our cluster. SIOS Protection Suite for Linux (aka SPS-Linux) will be used in this guide as the clustering technology. It provides both high availability failover clustering features (LifeKeeper) as well as real-time, block level data replication (DataKeeper) in a single, integrated solution. SPS-Linux enables you to deploy a “SANLess” cluster, aka a “shared nothing” cluster meaning that cluster nodes don’t have any shared storage, as is the case with EC2 Instances.

Install SIOS Protection Suite for Linux

Perform the following steps on ALL 3 VMs (node1, node2, witness):

Download the SPS-Linux installation image file (sps.img) and and obtain either a trial license or purchase permanent licenses. Contact SIOS for more information.

You will loopback mount it and run the “setup” script inside, as root (or first “sudo su -” to obtain a root shell) For example:

# mkdir /tmp/install

# mount -o loop sps.img /tmp/install

# cd /tmp/install

# ./setup

During the installation script, you’ll be prompted to answer a number of questions. You will hit Enter on almost every screen to accept the default values. Note the following exceptions:

  • On the screen titled “High Availability NFS” you may select “n” as we will not be creating a highly available NFS server
  • Towards the end of the setup script, you can choose to install a trial license key now, or later. We will install the license key later, so you can safely select “n” at this point
  • In the final screen of the “setup” select the ARKs (Application Recovery Kits, i.e. “cluster agents”) you wish to install from the list displayed on the screen.
    • The ARKs are ONLY required on “node1” and “node2”. You do not need to install on “witness” Navigate the list with the up/down arrows, and press SPACEBAR to select the following:
        • lkDR – DataKeeper for Linux
        • lkSQL – LifeKeeper MySQL RDBMS Recovery Kit
      • This will result in the following additional RPMs installed on “node1” and “node2”:
        • steeleye-lkDR-9.0.2-6513.noarch.rpm steeleye-lkSQL-9.0.2-6513.noarch.rpm

Install Witness/Quorum package

The Quorum/Witness Server Support Package for LifeKeeper (steeleye-lkQWK) combined with the existing failover process of the LifeKeeper core allows system failover to occur with a greater degree of confidence in situations where total network failure could be common. This effectively means that failovers can be done while greatly reducing the risk of “split-brain” situations.

Install the Witness/Quorum rpm on all 3 nodes (node1, node2, witness):

# cd /tmp/install/quorum

# rpm -Uvh steeleye-lkQWK-9.0.2-6513.noarch.rpm

On ALL 3 nodes (node1, node2, witness), edit /etc/default/LifeKeeper, set NOBCASTPING=1
On ONLY the Witness server (“witness”), edit /etc/default/LifeKeeper, set WITNESS_MODE=off/none

Install the EC2 Recovery Kit Package

SPS-Linux provides specific features that allow resources to failover between nodes in different availability zones and regions. Here, the EC2 Recovery Kit (i.e. cluster agent) is used to manipulate Route Tables so that connections to the Virtual IP are routed to the active cluster node.

Install the EC2 rpm (node1, node2):

# cd /tmp/install/amazon

# rpm -Uvh steeleye-lkECC-9.0.2-6513.noarch.rpm

Install a License key

On all 3 nodes, use the “lkkeyins” command to install the license file that you obtained from SIOS:

# /opt/LifeKeeper/bin/lkkeyins <path_to_file>/<filename>.lic

Start LifeKeeper

On all 3 nodes, use the “lkstart” command to start the cluster software:

# /opt/LifeKeeper/bin/lkstart

Set User Permissions for LifeKeeper GUI

On all 3 nodes, create a new linux user account (i.e. “tony” in this example). Edit /etc/group and add the “tony” user to the “lkadmin” group to grant access to the LifeKeeper GUI. By default only “root” is a member of the group, and we don’t have the root password here:

 

# useradd tony

# passwd tony

# vi /etc/group

 

lkadmin:x:1001:root,tony

Open the LifeKeeper GUI

Make a VNC connection to the Elastic IP (Public IP) address of node1. Based on the VNC configuration from above, you would connect to <Public_IP>:2 using the VNC password you specified earlier. Once logged in, open a terminal window and run the LifeKeeper GUI using the following command:

# /opt/LifeKeeper/bin/lkGUIapp &

You will be prompted to connect to your first cluster node (“node1”). Enter the linux userid and password specified during VM creation:

Next, connect to both “node2” and “witness” by clicking the “Connect to Server” button highlighted in the following screenshot:

You should now see all 3 servers in the GUI, with a green checkmark icon indicating they are online and healthy:

Create Communication Paths

Right-click on “node1” and select Create Comm Path

Select BOTH “node2” and “witness” and then follow the wizard. This will create comm paths between:


node1 & node2 node1 & witness


A comm path still needs to be created between node2 & witness. Right click on “node2” and select Create Comm Path. Follow the wizard and select “witness” as the remote server:


At this point the following comm paths have been created:

node1 <—> node2 node1 <—> witness node2 <—> witness

The icons in front of the servers have changed from a green “checkmark” to a yellow “hazard sign”. This is because we only have a single communication path between nodes.

If the VMs had multiple NICs (information on creating Azure VMs with multiple NICs can be found here, but won’t be covered in this article), you would create redundant comm paths between each server.


To remove the warning icons, go to the View menu and de-select “Comm Path Redundancy Warning”:


Result:

 

Verify Communication Paths

Use the “lcdstatus” command to view the state of cluster resources. Run the following commands to verify that you have correctly created comm paths on each node to the other two servers involved:

# /opt/LifeKeeper/bin/lcdstatus -q -d node1
MACHINE NETWORK ADDRESSES/DEVICE STATE PRIO node2 TCP 10.0.0.4/10.0.1.4

ALIVE 1 witness TCP 10.0.0.4/10.0.2.4 ALIVE 1
#/opt/LifeKeeper/bin/lcdstatus -q -d node2
MACHINE NETWORK ADDRESSES/DEVICE STATE PRIO node1 TCP 10.0.1.4/10.0.0.4

ALIVE 1 witness TCP 10.0.1.4/10.0.2.4 ALIVE 1
#/opt/LifeKeeper/bin/lcdstatus -q -d witness

MACHINE NETWORK ADDRESSES/DEVICE STATE PRIO node1 TCP 10.0.2.4/10.0.0.4
ALIVE 1 node2 TCP 10.0.2.4/10.0.1.4 ALIVE 1

Create a Data Replication cluster resource (i.e. Mirror)

Next, create a Data Replication resource to replicate the /var/lib/mysql partition from node1 (source) to node2 (target). Click the “green plus” icon to create a new resource:


Follow the wizard with these selections:

Please Select Recovery Kit: Data Replication Switchback Type: intelligent

Server: node1

Hierarchy Type: Replicate Exiting Filesystem

Existing Mount Point: /var/lib/mysql

Data Replication Resource Tag: datarep-mysql

File System Resource Tab: /var/lib/mysql

Bitmap File: (default value)

Enable Asynchronous Replication: No

After the resource has been created, the “Extend” (i.e. define backup server) wizard will appear.

Use the following selections:

Target Server: node2 Switchback Type: Intelligent Template Priority: 1

Target Priority: 10 Target Disk: /dev/xvdb1

Data Replication Resource Tag: datarep-mysql Bitmap File: (default value)

Replication Path: 10.0.0.4/10.0.1.4 Mount Point: /var/lib/mysql

Root Tag: /var/lib/mysql

The cluster will look like this:

Create Virtual IP

Next, create a Virtual IP cluster resource. Click the “green plus” icon to create a new resource:


Follow the wizard to create the IP resource with these selections:

Select Recovery Kit: IP Switchback Type: Intelligent IP Resource: 10.1.0.10

Netmask: 255.255.255.0

Network Interface: eth0

IP Resource Tag: ip-10.1.0.10

Extend the IP resource with these selections:

Switchback Type: Intelligent Template Priority: 1

Target Priority: 10

IP Resource: 10.1.0.10

Netmask: 255.255.255.0

Network Interface: eth0

IP Resource Tag: ip-10.1.0.10

The cluster will now look like this, with both Mirror and IP resources created:

Configure a Ping List for the IP resource

By default, SPS-Linux monitors the health of IP resources by performing a broadcast ping. In many virtual and cloud environments, broadcast pings don’t work. In a previous step, we set “NOBCASTPING=1” in
/etc/default/LifeKeeper to turn off broadcast ping checks. Instead, we will define a ping list.

This is a list of IP addresses to be pinged during IP health checks for this IP resource.

In this guide, we will add the witness server (10.0.2.4) to our ping list.

Right-click on the IP resource (ip-10.1.0.10) and select Properties:

You will see that initially, no ping list is configured for our 10.1.0.0 subnet. Click “Modify Ping List”:

Enter “10.0.2.4” (the IP address of our witness server), click “Add address” and finally click “Save List”:


You will be returned to the IP properties panel, and can verify that 10.0.2.4 has been added to the ping list. Click OK to close the window:

Create the MySQL resource hierarchy

Next, create a MySQL cluster resource. The MySQL resource is responsible for stopping/starting/monitoring of your MySQL database.

Before creating MySQL resource, make sure the database is running. Run “ps -ef | grep sql” to check.

If it’s running, great – nothing to do. If not, start the database back up:

# mysqld_safe –user=root –socket=/var/lib/mysql/mysql.sock –port=3306 –datadi

Follow the wizard with to create the IP resource with these selections:To create, click the “green plus” icon to create a new resource:

Select Recovery Kit: MySQL Database Switchback Type: Intelligent Server: node1

Location of my.cnf: /var/lib/mysql

Location of MySQL executables: /usr/bin

Database Tag: mysql

Extend the IP resource with the following selections:

Target Server: node2 Switchback Type: intelligent Template Priority: 1

Target Priority: 10

As a result, your cluster will look as follows. Notice that the Data Replication resource was automatically moved underneath the database (dependency automatically created) to ensure it’s always brought online before the database:

Create an EC2 resource to manage the route tables upon failover

SPS-Linux provides specific features that allow resources to failover between nodes in different availability zones and regions. Here, the EC2 Recovery Kit (i.e. cluster agent) is used to manipulate Route Tables so that connections to the Virtual IP are routed to the active cluster node.

To create, click the “green plus” icon to create a new resource:


Follow the wizard to create the EC2 resource with these selections:

Select Recovery Kit: Amazon EC2 Switchback Type: Intelligent Server: node1

EC2 Home: /opt/aws

EC2 URL: ec2.us-west-2.amazonaws.com

AWS Access Key: (enter Access Key obtained earlier) AWS Secret Key: (enter Secret Key obtained earlier) EC2 Resource Type: RouteTable (Backend cluster)

IP Resource: ip-10.1.0.10

EC2 Resource Tag: ec2-10.1.0.10

Extend the IP resource with the following selections:

Target Server: node2 Switchback Type: intelligent Template Priority: 1

Target Priority: 10

EC2 Resource Tag: ec2-10.1.0.10

The cluster will look like this. Notice how the EC2 resource is underneath the IP resource:

Create a Dependency between the IP resource and the MySQL Database resource

Create a dependency between the IP resource and the MySQL Database resource so that they failover together as a group. Right click on the “mysql” resource and select “Create Dependency”:

On the following screen, select the “ip-10.1.0.10” resource as the dependency. Click Next and continue through the wizard:

At this point the SPS-Linux cluster configuration is complete. The resource hierarchy will look as follows:

Step 15: Test Cluster Connectivity

At this point, all of our Amazon EC2 and Cluster configurations are complete! Cluster resources are currently active on node1:

Test connectivity to the cluster from the witness server (or another linux instance if you have one) SSH into the witness server, “sudo su -” to gain root access. Install the mysql client if needed:

[root@witness ~]# yum -y install mysql

Test MySQL connectivity to the cluster:

[root@witness ~]# mysql –host=10.1.0.10 mysql -u root -p

Execute the following MySQL query to display the hostname of the active cluster node:

MariaDB [mysql]> select @@hostname;

++

| @@hostname |

++

| node1     |

++

1 row in set (0.00 sec) MariaDB [mysql]>

Using LifeKeeper GUI, failover from Node1 -> Node2″. Right-click on the mysql resource underneath node2, and select “In Service…”:

After failover has completed, re-run the MySQL query. You’ll notice that the MySQL client has detected that the session was lost (during failover) and automatically reconnects:

Execute the following MySQL query to display the hostname of the active cluster node, verifying that now “node2” is active:

MariaDB [mysql]> select @@hostname;

ERROR 2006 (HY000): MySQL server has gone away No connection. Trying to reconnect…

Connection id:      12

Current database: mysql

++

| @@hostname |

++

| node2     |

++

1 row in set (0.53 sec) MariaDB [mysql]>

Reproduced with permission from SIOS

 

Filed Under: Clustering Simplified Tagged With: #SANLess, amazon, AWS, cluster, Linux

Configure Sanless Hyper-V Failover Cluster With DataKeeper

February 19, 2018 by Jason Aw Leave a Comment

Configure Sanless Hyper-V Failover Cluster With DataKeeper

Questions about SANLess

Q. What is a SANLess cluster?
A. It is a cluster that uses local storage instead of a SAN.

Q. Why would I want to Configure Sanless Hyper-V Failover Cluster?
A. There are a few reasons:

  • Eliminate the cost of a SAN
  • Eliminate the SAN as a single point of failure
  • Take advantage of high speed storage options such a Fusion-io ioDrives and other high speed storage devices that plug in locally
  • Stretch the cluster across geographic locations for disaster recovery
  • Simplify management
  • Eliminate the need for a SAN administrator

Configure Sanless Hyper-V Failover Cluster with DataKeeper Cluster Edition is easy

If you know anything about Windows Server Failover Clustering, then you already know 99% of the solution. No need to worry if you have never built a Windows Server Failover Cluster before. Microsoft has made it easy and painless. For the beginners, I have written a step-by-step article that tells you how to build a Windows Server 2012 #SANLess cluster in my blog post here.

Two Options For Making A Highly Available Virtual Machine

If you have followed the steps in my post, you are ready to create your first highly available virtual machine. The first option assumes that you have an existing virtual machine that you want to make highly available. The second option assumes you are building a highly available virtual machine from scratch.

Configuring The DataKeeper Volume Cluster Resource

A SANLess Hyper-V cluster requires one VM per volume. Therefore, you will want to make sure you have your storage partitioned so that you have enough volumes for each VM. The storage on each cluster node should be configured identically in terms of drive letters and partition sizes. Have the partitions configured properly and your VM resides on the partition you want to replicate. Then, open the DataKeeper interface and walk through the three step wizard to create the DataKeeper Volume Resources as shown in below.

First, open the DataKeeper interface and click on Connect to Server. Do this twice to connect to both servers.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Once you are connected, click on Create Job to create a mirror of the volume that contains the virtual machine you want to make highly available as shown below. In this example we will mirror the E drive.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Whenever possible, keep replication traffic on a private network. In this case, we are using the 10.0.0.0/8 network for replication traffic. This can be a simple patch cable that connects the two servers across two unused NICs.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

The final screen shows the options available for mirroring. For local area networks, Synchronous mirroring is preferred. When replicating across wide area networks, you will want to use Asynchronous replication and possibly enable compression. I would not limit the Maximum bandwidth. Because that could potentially cause your mirror to go out of sync if your rate of change (Disk Right Bytes/sec) exceeds the Maximum bandwidth specified. However, you may want to temporarily enable Maximum bandwidth during the initial mirror creation process. Otherwise, DataKeeper may flood the network with the initial replication traffic as it tries to get in sync as quickly as possible. Both Maximum bandwidth and Compression settings can be adjusted after the mirror is created. However, you cannot change between Synchronous and Asynchronous mirroring once the mirror has been created without deleting the mirror and recreating it.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

At the end of the mirror creation process you will see a popup asking if you want to auto-register this volume as a cluster volume. Select Yes, this will create a DataKeeper volume resource in Failover Clustering Available Storage.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

You are now ready to create your highly available VMs.

Option 1 – Clustering An Existing VM

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Once again, this procedure assumes you have an existing VM that you want to make highly available. If you do not have an existing VM, you will want to follow the procedure in Option 2 – Creating a Highly Available VM. Otherwise, you should have a VM when looking at Hyper-V Manager as shown below.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

All the VM files should already be located on the replicated volume, as shown below. If not, you will have to relocate the files before attempting to cluster the VM.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

To begin the clustering process, open up Failover Cluster Manager. Right click on Configure Roles and choose Virtual Machine as the role you want to create.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

This will launch the High Availability Wizard. At this point you should select the VM that you want to cluster and step through the wizard as shown below.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

You will see that the VM resource will be created, but there will be some warnings. The warnings indicate that the E drive is not currently part of the VM Cluster Resource Group.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

To make the DataKeeper Volume E part of the VM Cluster Resource Group, right click on the role and choose Add Storage. Add the DataKeeper Volume that you will see listed in Available Disks.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

The last part is to choose the Properties of the Virtual Machine Configuration (not the Virtual Machine) resource and make it dependent upon the storage you just added to the resource group.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

You should now be able to start the VM.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Option 2- Creating A Highly Available VM From Scratch

Assuming you want to create a highly available VM from scratch, you can complete this entire process from the Hyper-V Virtual Machine Manager as shown below. This step assumes that you have already created a mirror of the E drive using DataKeeper as described in Configuring the DataKeeper Volume Resource section.

To get started, open the Failover Cluster Manager and right click on Roles and choose Virtual Machine – New Virtual Machine.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Follow through with the steps of the wizard and select the options that you want to use for the VM. When choosing where to place the VM, select the cluster node that currently is the owner of Available Storage. It will also be the source of the mirror.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Make sure when specifying the Name and Location of the VM, you select the location of the replicated volume.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

The rest of the options are up to you. Just make sure the VHD file is located on the replicated volume.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

You will see the highly available VM is created, but there is a warning about the storage. You will need to add the DataKeeper Volume Resource to the VM Cluster Resource Group as shown below.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

After the DataKeeper Volume is added to the VM Cluster Resource Group, add the DataKeeper Volume as a dependency of the Virtual Machine Configuration resource.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

You now have a highly available virtual machine.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Summary

In this blog post, we discussed what constitutes a #SANLess cluster. We chose SIOS DataKeeper to Configure Sanless Hyper-V Failover Cluster. Once built, the cluster behaves exactly like a SAN based cluster, This includes having the ability to do Live Migration, Quick Migration and automated failover in the event of unexpected failures.

A #SANLess cluster eliminates the expense of a SAN as well as the single point of failure of a SAN. DataKeeper Cluster Edition supports multiple nodes in a SAN. So configurations that stretch both LAN and WAN are all possible solutions for Hyper-V high availability and disaster recovery. DataKeeper supports any local storage. This opens up the possibility of using high speed local attached SSD or NAND Flash storage for high performance without giving up high availability.

If you enjoy reading tips to Configure Sanless Hyper-V Failover Cluster, read more about clustering here

Reported with permission from https://clusteringformeremortals.com/2014/03/04/configuring-a-sanless-hyper-v-failover-cluster-with-datakeeper-cluster-edition/

Filed Under: Clustering Simplified, Datakeeper Tagged With: #SANLess, cluster, configure sanless hyper v failover cluster, Microsoft Windows Server Failover Clustering, SIOS DataKeeper Cluster Edition

SIOS SANless Clusters Provide HA Protection Needed to Deploy SAP in Microsoft Azure

September 5, 2017 by Jason Aw Leave a Comment

Case Study: Zespri – SIOS DataKeeper Cluster Edition

Protects One of the largest SAP in Azure Implementations

Azure high availability, SQL Server Clusters

Filed Under: Success Stories Tagged With: #SANLess, #SANLess Clusters for SQL Server Environments, #SANLess Clusters for Windows Environments, Azure, Hybrid Cloud, SIOS DataKeeper Cluster Edition

Deploy 2-node File Server Failover Cluster in Azure using ARM

July 19, 2017 by Jason Aw Leave a Comment

Deploy 2-node File Server Failover Cluster In Azure Using ARM

In this post we will detail the specific steps required to deploy a 2-node File Server Failover Cluster in a single region of Azure using Azure Resource Manager. I will assume you are familiar with basic Azure concepts as well as basic Failover Cluster concepts and will focus this article on what is unique about deploying a File Server Failover Cluster in Azure.

With DataKeeper Cluster Edition you are able to take the locally attached storage, whether it is Premium or Standard Disks, and replicate those disks either synchronously, asynchronously or a mix or both, between two or more cluster nodes. In addition, a DataKeeper Volume resource is registered in Windows Server Failover Clustering which takes the place of a Physical Disk resource. Instead of controlling SCSI-3 reservations like a Physical Disk Resource, the DataKeeper Volume controls the mirror direction, ensuring the active node is always the source of the mirror. As far as Failover Clustering is concerned, it looks, feels and smells like a Physical Disk and is used the same way Physical Disk Resource would be used.

Pre-Requisites

  • You have used the Azure Portal before and are comfortable deploying virtual machines in Azure IaaS.
  • Have obtained a license or eval license of SIOS DataKeeper

Deploying A File Server Failover Cluster Instance Using The Azure Portal

To build a 2-node File Server Failover Cluster Instance in Azure, we are going to assume you have a basic Virtual Network based on Azure Resource Manager and you have at least one virtual machine up and running and configured as a Domain Controller. Once you have a Virtual Network and a Domain configured, you are going to provision two new virtual machines which will act as the two nodes in our cluster.

Our environment will look like this:

DC1 – Our Domain Controller and File Share Witness
SQL1 and SQL2 – The two nodes of our File Server Cluster

Provisioning The Two Cluster Nodes (SQL1 And SQL2)

Using the Azure Portal, we will provision both SQL1 and SQL2 exactly the same way. There are numerous options to choose from including instance size, storage options, etc. This guide is not meant to be an exhaustive guide to deploying Servers in Azure as there are some really good resources out there and more published every day. However, there are a few key things to keep in mind when creating your instances, especially in a clustered environment.

Availability Set – It is important that both SQL1, SQL2 AND DC1 reside in the same availability set. By putting them in the same Availability Set we are ensuring that each cluster node and the file share witness reside in a different Fault Domain and Update Domain. This helps guarantee that during both planned maintenance and unplanned maintenance the cluster will continue to be able to maintain quorum and avoid downtime.

3
Figure 3 – Be sure to add both cluster nodes and the file share witness to the same Availability Set

STATIC IP ADDRESS

Once each VM is provisioned, you will want to go into the setting and change the settings so that the IP address is Static. We do not want the IP address of our cluster nodes to change.

4
Figure 4 – Make sure each cluster node uses a static IP

Storage

As far as Storage is concerned, you will want to consult Performance best practices for SQL Server in Azure Virtual Machines. In any case, you will minimally need to add at least one additional disk to each of your cluster nodes. DataKeeper can use Basic Disk, Premium Storage or even Storage Pools consisting of multiple disks in a storage pool. Just be sure to add the same amount of storage to each cluster node and configure it identically. Also, be sure to use a different storage account for each virtual machine to ensure that a problem with one Storage Account does not impact both virtual machines at the same time.

5
Figure 5 – make sure to add additional storage to each cluster node

Create The Cluster

Assuming both cluster nodes (SQL1 and SQL2) have been provisioned as described above and added to your existing domain, we are ready to create the cluster. Before we create the cluster, there are a few Features that need to be enabled. These features are .Net Framework 3.5 and Failover Clustering. These features need to be enabled on both cluster nodes. You will also need to enable the FIle Server Role.

6
Figure 6 – enable both .Net Framework 3.5 and Failover Clustering features and the File Server on both cluster nodes

Once that role and those features have been enabled, you are ready to build your cluster. Most of the steps I’m about to show you can be performed both via PowerShell and the GUI. However, I’m going to recommend that for this very first step you use PowerShell to create your cluster. If you choose to use the Failover Cluster Manager GUI to create the cluster you will find that you wind up with the cluster being issues a duplicate IP address.

Without going into great detail, what you will find is that Azure VMs have to use DHCP. By specifying a “Static IP” when we create the VM in the Azure portal all we did was create sort of a DHCP reservation. It is not exactly a DHCP reservation because a true DHCP reservation would remove that IP address from the DHCP pool. Instead, this specifying a Static IP in the Azure portal simply means that if that IP address is still available when the VM requests it, Azure will issue that IP to it. However, if your VM is offline and another host comes online in that same subnet it very well could be issued that same IP address.

There is another strange side effect to the way Azure has implemented DHCP. When creating a cluster with the Windows Server Failover Cluster GUI when hosts use DHCP (which they have to), there is not option to specify a cluster IP address. Instead it relies on DHCP to obtain an address. The strange thing is, DHCP will issue a duplicate IP address, usually the same IP address as the host requesting a new IP address. The cluster will usually complete, but you may have some strange errors and you may need to run the Windows Server Failover Cluster GUI from a different node in order to get it to run. Once you get it to run you will want to change the cluster IP address to an address that is not currently in use on the network.

You can avoid that whole mess by simply creating the cluster via Powershell and specifying the cluster IP address as part of the PowerShell command to create the cluster.

You can create the cluster using the New-Cluster command as follows:

New-Cluster -Name cluster1 -Node sql1,sql2 -StaticAddress 10.0.0.101 -NoStorage

After the cluster creation completes, you will also want to run the cluster validation by running the following command:

Test-Cluster

7
Figure 7 – The output of the cluster creation and the cluster validation commands

Create The File Share Witness

Because there is no shared storage, you will need to create a file share witness on another server in the same Availability Set as the two cluster nodes. By putting it in the same availability set you can be sure that you only lose one vote from your quorum at any given time. If you are unsure how to create a File Share Witness you can review this article http://www.howtonetworking.com/server/cluster12.htm. In my demo I put the file share witness on domain controller. I have published an exhaustive explanation of cluster quorums at https://blogs.msdn.microsoft.com/microsoft_press/2014/04/28/from-the-mvps-understanding-the-windows-server-failover-cluster-quorum-in-windows-server-2012-r2/

Install DataKeeper

After the cluster is created it is time to install DataKeeper. It is important to install DataKeeper after the initial cluster is created so the custom cluster resource type can be registered with the cluster. If you installed DataKeeper before the cluster is created you will simply need to run the install again and do a repair installation.

8
Figure 8 – Install DataKeeper after the cluster is created

During the installation you can take all of the default options.  The service account you use must be a domain account and be in the local administrators group on each node in the cluster.

9
Figure 9 – the service account must be a domain account that is in the Local Admins group on each node

Once DataKeeper is installed and licensed on each node you will need to reboot the servers.

Create The DataKeeper Volume Resource

To create the DataKeeper Volume Resource you will need to start the DataKeeper UI and connect to both of the servers.
10Connect to SQL1
11

Connect to SQL2
12

Once you are connected to each server, you are ready to create your DataKeeper Volume. Right click on Jobs and choose “Create Job”
13

Give the Job a name and description.
14

Choose your source server, IP and volume. The IP address is whether the replication traffic will travel.
15 - File Server Failover Cluster

Choose your target server.
16

Choose your options. For our purposes where the two VMs are in the same geographic region we will choose synchronous replication. For longer distance replication you will want to use asynchronous and enable some compression.
17

By clicking yes at the last pop-up you will register a new DataKeeper Volume Resource in Available Storage in Failover Clustering.
18

You will see the new DataKeeper Volume Resource in Available Storage.
19

Create The File Server Cluster Resource

To create the File Server Cluster Resource, we will use Powershell once again rather than the Failover Cluster interface. This is when the virtual machines are configured to use DHCP, the GUI based wizard will not prompt us to enter a cluster IP address. Instead, it will issue a duplicate IP address. To avoid this, we will use a simple powershell command to create the FIle Server Cluster Resource and specify the IP Address

Add-ClusterFileServerRole -Storage "DataKeeper Volume E" -Name FS2 -StaticAddress 10.0.0.201

Make note of the IP address you specify here. It must be a unique IP address on your network. We will use this same IP address later when we create our Internal Load Balancer.

Create The Internal Load Balancer

Here is where failover clustering in Azure is different than traditional infrastructures. The Azure network stack does not support gratuitous ARPS, so clients cannot connect directly to the cluster IP address. Instead, clients connect to an internal load balancer and are redirected to the active cluster node. What we need to do is create an internal load balancer. This can all be done through the Azure Portal as shown below.

First, create a new Load Balancer
30

You can use an Public Load Balancer if your client connects over the public internet. But assuming your clients reside in the same vNet, we will create an Internal Load Balancer. The important thing to take note of here is that the Virtual Network is the same as the network where your cluster nodes reside. Also, the Private IP address that you specify will be EXACTLY the same as the address you used to create the SQL Cluster Resource.
31

After the Internal Load Balancer (ILB) is created, you will need to edit it. The first thing we will do is to add a backend pool. Through this process you will choose the Availability Set where your SQL Cluster VMs reside. However, when you choose the actual VMs to add to the Backend Pool, be sure you do not choose your file share witness. We do not want to redirect SQL traffic to your file share witness.
32
33

The next thing we will do is add a Probe. The probe we add will probe Port 59999. This probe determines which node is active in our cluster.
34

And then finally, we need a load balancing rule to redirect the SMB traffic, TCP port 445 The important thing to notice in the screenshot below is the Direct Server Return is Enabled. Make sure you make that change.

445_ilb

Fix The File Server IP Resource

The final step in the configuration is to run the following PowerShell script on one of your cluster nodes. This will allow the Cluster IP Address to respond to the ILB probes and ensure that there is no IP address conflict between the Cluster IP Address and the ILB. Please take note; you will need to edit this script to fit your environment. The subnet mask is set to 255.255.255.255, this is not a mistake, leave it as is. This creates a host specific route to avoid IP address conflicts with the ILB.

# Define variables
$ClusterNetworkName = “” 
# the cluster network name 
(Use Get-ClusterNetwork on Windows Server 2012 of higher to find the name)
$IPResourceName = “” 
# the IP Address resource name 
$ILBIP = “” 
# the IP Address of the Internal Load Balancer (ILB)
Import-Module FailoverClusters
# If you are using Windows Server 2012 or higher:
Get-ClusterResource $IPResourceName | Set-ClusterParameter 
-Multiple @{Address=$ILBIP;ProbePort=59999;SubnetMask="255.255.255.255";
Network=$ClusterNetworkName;EnableDhcp=0}
# If you are using Windows Server 2008 R2 use this: 
#cluster res $IPResourceName /priv enabledhcp=0 address=$ILBIP probeport=59999  
subnetmask=255.255.255.255

Creating File Shares

You will find that using the File Share Wizard in Failover Cluster Manager does not work. Instead, you will simply create the file shares in Windows Explorer on the active node. Failover clustering automatically picks up those shares and puts them in the cluster.

Note that the”Continuous Availability” option of a file share is not supported in this configuration.

Conclusion

You should now have a functioning File Server Failover Cluster. If you have ANY problems, please reach out to me on Twitter @daveberm. Need a DataKeeper evaluation key fill out the form at http://us.sios.com/clustersyourway/cta/14-day-trial and SIOS will send an evaluation key sent out to you.

Reproduced with permission from Clusteringformeremortals

Filed Under: Clustering Simplified, Datakeeper Tagged With: #SANLess, #SANLess Clusters for SQL Server Environments, #SANLess Clusters for Windows Environments, Azure, DataKeeper Cluster Edition, file server failover cluster, highly available cluster, MSSQLTips, SQL Server

Expert Advice on High Availability SQL Server and Machine Learning Analytics – Blogs, Webinars and Live Events

November 22, 2016 by sios2017 Leave a Comment

SIOS experts in high availability SQL Server cluster protection routinely share their knowledge and provide expert advice through webinars, blogs, and live events.

Blog Post: Step-by-Step Guide to High Availability SQL Server v.Next Linux High Availability
Click here to learn how to deploy a Linux VM in Azure running SQL Server and how to configure a 2-node failover cluster to make it highly available without the need for shared storage. https://clusteringformeremortals.com/category/high-availability/

Blog Post:  Deploying a Highly Available File Server in Azure IAAS (ARM) with SIOS DataKeeper This blog is a step-by-step guide to deploying a two-node File Server Failover Cluster in a single region of Azure using Azure Resource Manager.

Live Webinar: December 15, 2016 –  Webinar: Keeping the Peace with Your Sys Admins while Providing High Availability SQL Server. Join SQL Server MVP Dave Bermingham as he walks through common use cases that cause conflict between SQL DB Admins and VM Admins when SQL Server HA is involved. He will also describe a simple, conflict-free way for SQL Server admins to get what they need for a successful implementation of SQL Server. Register here.

Live Webinar: December 8, 2016 – Understanding vSphere Analytics: Machine Learning vs Threshold-based. Join David Davis, 8-time vExpert and Partner at ActualTechMedia and Experts from SIOS Technology in this real-world, practical, hands-on webinar! Find out the differences between different vSphere analytics approaches and how to choose a solution that’s best for you. Register here.

Recorded Webinar – VMware Guest Based SQL Server High Availability Clusters – Ways to Protect SQL and Maintain Flexibility. Watch this recorded webinar and hear Dave Bermingham, Microsoft Clustering and Datacenter MVP and Tony Tomarchio, Director of Field Engineering at SIOS discuss ways to create a high availability cluster to protect SQL in a VMware environment without sacrificing IT flexibility or important VMware features, and whether you can have a cluster and multi-site replication with VMware. Register here.

Filed Under: Blog posts, News and Events Tagged With: #high availability SQL Server, #ML, #SANLess, Azure, Machine Learning, SQL

  • 1
  • 2
  • 3
  • …
  • 10
  • Next Page »

Recent Posts

  • Video: The SIOS Advantage
  • Demo Of SIOS DataKeeper For A Three-Node Cluster In AWS
  • 2023 Predictions: Data Democratization To Drive Demand For High Availability
  • Understanding the Complexity of High Availability for Business-Critical Applications
  • Epicure Protects Business Critical SQL Server with Amazon EC2 and SIOS SANLess Clustering Software

Most Popular Posts

Maximise replication performance for Linux Clustering with Fusion-io
Failover Clustering with VMware High Availability
create A 2-Node MySQL Cluster Without Shared Storage
create A 2-Node MySQL Cluster Without Shared Storage
SAP for High Availability Solutions For Linux
Bandwidth To Support Real-Time Replication
The Availability Equation – High Availability Solutions.jpg
Choosing Platforms To Replicate Data - Host-Based Or Storage-Based?
Guide To Connect To An iSCSI Target Using Open-iSCSI Initiator Software
Best Practices to Eliminate SPoF In Cluster Architecture
Step-By-Step How To Configure A Linux Failover Cluster In Microsoft Azure IaaS Without Shared Storage azure sanless
Take Action Before SQL Server 20082008 R2 Support Expires
How To Cluster MaxDB On Windows In The Cloud

Join Our Mailing List

Copyright © 2023 · Enterprise Pro Theme on Genesis Framework · WordPress · Log in