{"id":9693,"date":"2017-01-15T17:39:17","date_gmt":"2017-01-15T16:39:17","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/introducing-high-availability-with-sql-server-on-linux\/"},"modified":"2023-07-18T07:38:35","modified_gmt":"2023-07-18T05:38:35","slug":"introducing-high-availability-with-sql-server-on-linux","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/introducing-high-availability-with-sql-server-on-linux\/","title":{"rendered":"Introducing high-availability with SQL Server on Linux"},"content":{"rendered":"

A couple of months ago, I did my first installation of SQL Server on Linux. I wrote about it in this <\/span>blog post<\/span><\/a>. So now it\u2019s time to start the new year by talking about high availability on Linux with SQL Server vNext. Running standalone instances will be suitable for scenarios but I guess introducing high-availability with critical environments still remain mandatory.Currently, the CTP1 supports installing a <\/span>SQL Server Failover Cluster Instance<\/span><\/a> on the top of RHEL HA Add-on based on Pacemaker. This is a good start although I hope to see also availability groups in the future (maybe a future CTP version). In this blog post I will not go into details of my installation process because some steps will certainly change over the time but I would like to share my notes (or feelings) about this new way to achieve high availability with SQL Server on Linux world. <\/span><\/p>\n

I performed the installation by using the same infrastructure exposed on the Microsoft documentation. As usual, my environment is fully virtualized with Hyper-V. <\/span><\/p>\n

\"blog<\/span><\/p>\n

So, the first step consisted in installing 3 virtual machines based on a CentOS 7 distribution (the Microsoft documentation is intended\u00a0to RHEL 7 but CentOS 7\u00a0is perfectly\u00a0suitable in our case). The first two ones concerned the cluster and SQL Server. I performed the same <\/span>installation process<\/span><\/a> to install SQL Server on Linux. No change here. The third one concerned the NFS server. So let\u2019s show my storage configuration:<\/span><\/p>\n

[mikedavem@nfs ~]$ sudo fdisk -l | grep -i sd\nDisk \/dev\/sda: 21.5 GB, 21474836480 bytes, 41943040 sectors\n\/dev\/sda1   *        2048     2099199     1048576   83  Linux\n\/dev\/sda2         2099200    41943039    19921920   8e  Linux LVM\nDisk \/dev\/sdb: 10.7 GB, 10737418240 bytes, 20971520 sectors\n\/dev\/sdb1            2048    20971519    10484736   83  Linux\nDisk \/dev\/sdc: 10.7 GB, 10737418240 bytes, 20971520 sectors\n\/dev\/sdc1            2048    20971519    10484736   83  Linux<\/pre>\n
The corresponding partition \/dev\/sdb1<\/em> (ext4 formatted) need to be mounted automatically by the system and will be used as a shared storage by the NFS server afterwards.<\/p>\n
[mikedavem@nfs ~]$ cat \/etc\/fstab\n#\n# \/etc\/fstab\n# Created by anaconda on Thu Jan 12 21:46:34 2017\n#\n\u2026\n\n\/dev\/mapper\/cl-root     \/                       xfs     defaults        0 0\nUUID=e4f5fc0b-1fd4-4e18-b655-a76b87778b73 \/boot                   xfs     defaults        0 0\n\/dev\/mapper\/cl-swap     swap                    swap    defaults        0 0\n\/dev\/sdb1       \/mnt\/sql_data_nfs       ext4    auto,user,rw    0 0\n\/dev\/sdc1       \/mnt\/sql_log_nfs        ext4    auto,user,rw    0 0<\/pre>\n
Then my NFS server will expose the shared directory \/mnt\/sql_data_nfs <\/em>to the cluster layer.<\/p>\n
[mikedavem@nfs ~]$ cat \/etc\/exports\n\/mnt\/sql_data_nfs 192.168.5.0\/24(rw,sync,no_subtree_check,no_root_squash)\n\/mnt\/sql_log_nfs  192.168.5.0\/24(rw,sync,no_subtree_check,no_root_squash)<\/pre>\n
We will focus only on the directory \/mnt\/sql_data_nfs in this case.<\/p>\n
[mikedavem@nfs ~]$ showmount -e\nExport list for nfs.dbi-services.com:\n\/mnt\/sql_log_nfs  192.168.5.0\/24\n\/mnt\/sql_data_nfs 192.168.5.0\/24<\/pre>\n
That\u2019s it. My directory is ready to be used by my SQL Server cluster nodes as shared storage for my databases. Let\u2019s continue with the second step. We need to install the cluster underlying infrastructure which includes components as Pacemaker (the resource manager) and Corosync (Communication layer between cluster nodes). <\/span><\/p>\n
\"blog<\/p>\n
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 From Microsoft <\/em>documentation<\/em><\/a><\/p>\n
By reading the Pacemaker documentation on the web, I could find out similar concepts we may have with Microsoft and the Windows Failover Cluster feature. After facing some configuration issues, here my final configuration.<\/p>\n