SQL Server Linux için Always On Availability Groups kurulumu , yapılandırılması

SQL Server 2017 ve SQL Server 2019 Linux işletim sistemi üzerinde çalışabilmektedir ve SQL Server 2017 ile Windows Failover Cluster’a ihtiyaç duymadan SQL Server Always On Availability Groups kurulumu yapılabilir oldu.

SQL Server Always On klasik kullanımda Windows Server Failover Cluster (WSFC)’a ihtiyacımız var, Linux üzerinde bu işlemi Pacemaker kullanarak yapabiliriz.

Linux da SQL Server AlwaysOn AG iki cluster türü ile kullanabilirsiniz.

1. External :  pacemaker kullanarak, otomatik failover sağlamak ve devamlığı artırmak için kullanılıyor.
2. None :  pacemaker ihtiyacı olmadan, sadece read scale ve manuel failover için kullanılıyor.

Windows üzerinde Windows Failover Cluster; failover, health monitoring ve resource management ,host edilen uygulama konfigürasyonu, node’lardaki değişikliklerin güncellenmesi ve bunların cluster’a yayılması gibi işlevleri var. Baktığınızda Windows için Windows Failover Cluster’ın önemi ve rolü çok büyük.

Peki ya Linux?

Linux üzerinde WSFC servisi olmadığından bu konfigürasyon bilgileri (metadata) SQL Server instance tarafından master database’inde tutuluyor. Windows da ihtiyaç duyulan bir witness olmadığından  (file-share witness gibi) bir problem anında cluster’ın ayakta kalmasını sağlayacak üçüncü bir çözümün olması gerekliliğini yaratıyor. Yani External seçili bir Linux SQL Server AG yapacaksanız iki node değil üç node’lu bir yapı kurmanız gerekiyor ama tabi burada üç node olması maliyeti artıracağı için “configuration only replica” tanımlaması ile gerekli metadata dağıtımı ve devamlılık için ilgili veriyi üzerinde tutması sağlanarak çözüme kavuşturdular.

Bu kadar teorik bilgiden sonra hızlıca örneklendirmeye geçelim. Test ortamı için Microsoft Azure üzerinde konumlandırdığım iki adet Linux makinem var. Ubuntu 20.04 kurulu olan sunucuların bilgisi aşağıdaki gibidir.

sqlinuxnode1 : 10.1.0.4

sqlinuxnode2 : 10.1.0.6

SQL Server Linux kurulumlarını da beraber gerçekleştiriyor olacağız, bu sebepten kendi ortamlarınızda deneyimleyebilirsiniz. Her sunucuda 1433 ve 5022 portlarına erişim izni veriyorum.

Putty aracılığı ile sunuculara erişim sağlıyorum ve yeni paketleri yüklemeden önce mevcut gelen paketlerin güncellenmelerini sağlıyorum.

sudo apt-get update

sudo apt-get -y upgrade

Güncellemelerin etkin olması için her ihtimale karşılık sunucularımı yeniden başlatıyorum.

sudo reboot

Sistemin MS SQL apt repolarına güvenmesi için GPG anahtarını ekliyorum.

sudo wget -qO- https://packages.microsoft.com/keys/microsoft.asc | sudo apt-key add –

Ubuntu 20.04 kullandığımı söylemiştim. Sisteme bu versiyon için ihtiyacımız olan Microsoft SQL Server 2019 apt deposunu ekliyorum.

sudo add-apt-repository "$(wget -qO- https://packages.microsoft.com/config/ubuntu/18.04/mssql-server-2019.list)"

SQL Server kurulumlarını gerçekleştirmek için aşağıdaki komutları kullanalım.

sudo apt update

sudo apt install mssql-server

Kurulum sırasında sizde sözleşmeyi kabul etmeniz istenecek. Y yazıp enter ile devam ediyoruz.

Resim 1 – Sözleşme onayı

Kurulumu tamamladıktan sonra sizden “sudo /opt/mssql/bin/mssql-conf setup” komutunu çalıştırmanız istenecektir.

Resim 2 – İlk Kurulum

Kurulum için ihtiyacınız olan kodu çalıştırdığınızda sizden SQL Server’ın hangi versiyonunu seçmek istediğiniz sorulacaktır. Örneğimizde biz “Developer” editionı seçiyor olacağız. Bu yüzden 2 ile devam ediyoruz.

Resim 3 – Versiyon seçimi

Versiyon seçimi sonrasında tekrar bir lisans onaylama istiyor. Bu adımı da geçiyoruz.  Kurulum için son adım olarak bizden bir sistem yöneticisi (sa kullanıcısı) şifresi istiyor. Güçlü bir şifre oluşturup devam ediyoruz.

Resim 4 – SA Kullanıcının şifresinin belirlenmesi

SA kullanıcısnın şifresini de belirledik ve gördüğünüz gibi SQL Server servisininin çalıştığı bilgisi ekranda karşımıza geldi.

SQL Server 2019’u Linux Ubuntu 20.04’e başarılı bir şekilde kurduk. Yani ilk adımı aslında başarılı bir şekilde sağladık. Diğer adımlara geçmeden lokal IP adreslerini – sizler ile paylaştığım ip adresleri – ben Azure üzerinden Sabit IP olarak atadım. Sizlerde kendi ortamlarınızda bu konuyu deneyimlerken mutlaka lokal IP adreslerini sabit IP olarak atamanız gerekiyor.

IP adreslerini kontrol etmek için aşağıdaki kodu putty üzerinden çalıştırabilirsiniz.

Resim 5 – ifconfig çalışmadı.

Gördüğünüz gibi ifconfig bulunamadı uyarısı verip, nasıl çalıştırmam gerektiğini bana gösteriyor. “sudo apt install net-tools” çalıştırmam gerekiyormuş. Gerekli kodu çalıştırdıktan sonra tekrar ifconfig putty üzerinden çalıştırıyorum.

Resim 6 – ifconfig çalıştı

Tıpkı SQL Server 2019 kurulumu gibi bu ip kontrol işlemlerini her iki sunucuda ayrı ayrı gerçekleştirdim.

Bir sonraki adım ise üzerinde çalıştığımız sunucunun hostname bilgisini kontrol etmemiz. Hostname bilgisi 15 karakterden uzun olmamalıdır.

sudo cat /etc/hostname

Sunucu isimlerini de kontrol ettikten sonra sunucularınız birbirleri ile iletişim kurmada sorun yaşamaması adına /etc/hosts dosyalarını güncelleyelim. Fakat bu işlem için önce root yetkisine sahip olmamız gerekiyor. ( sudo su kullanarak root yetkisi geçiş yapıyoruz. )

sqlinuxnode1 için /etc/hosts dosyası; nano /etc/hosts  yada sudo nano /etc/hosts

Resim 7 – sqlinuxnode1 etc hosts dosyası

Burada kırmızı ile işaretlenen kısım benim girişini yaptığım sunucu bilgilerimdir. Sizde kendi sunucu lokal sabit ip adreslerini ve sunucu hostname bilgilerini girmelisiniz ki sunucular birbirleri arasında iletişim kurarken sorun yaşamasınlar. Nano editörü ile açtık, değişiklik yaptık ve Ctrl + X ile kaydedip çıkıyoruz.  Aynı işlemi sqllinuxnode2 için de gerçekleştiriyoruz.

Resim 8 – sqlinuxnode2 etc hosts dosyası

Host dosyaları üzerinde gerekli işlemleri yaptıktan sonra sunucular arasında iletişimde bir sorun olup olmadığını kontrol etmek için ping atıyoruz.

ping sqlinuxnode2

Resim 9 – sqllinuxnode1 den sqllinuxnode2 ye ping

Resim9 da sqlinuxnode1 sunucusundan sqlinuxnode2 sunucusuna ping attık. Şimdi sqlinuxnode2 sunucusundan sqlinuxnode1 sunucuna ping atıp kontrol edelim.

Resim 10 – sqlinuxnode2 den sqlinuxnode1 e ping

Her iki sunucumuzda hazır, şimdi yapmamız gereken ister bu ortama erişen bir sunucu üzerinden isterseniz de lokal ortamda kullandığınız bir bilgisayardan bu sunuculara erişim sağlayıp diğer adımları yapıyor olacağız. Ben 1433 ve 5022 numaralı portları açmıştım. Sadece yapmam gereken sunucuların host isimlerinden erişim sağlamak için kendi Windows bilgisayarında host dosyasını düzenlemem gerekiyor.

Windows’da host dosyası C:\Windows\System32\drivers\etc içerisinde bulunur ve bunu bir metin düzenleyicisi ile açıp değişiklik yapabilirsiniz.

Ayarlamaları da yaptıktan sonra SSMS ile bağlantı sağlıyoruz.

Resim 11 – SSMS ile bağlantı hatası

Eğer ki SSMS ile bağlantı sağlarken yukarıdaki gibi bir hata alıyorsanız SSMS Connect To Server’da Connection Properties kısımında “Trust server certificate” işaretlemeniz gerekmektedir.

Resim 12 – Trust server certificate

SSMS ile tekrar bağlanmayı deniyoruz, eğer bir sorun yoksa aşağıdaki resimdeki gibi bağlantımız başarılı olacaktır.

Resim 13 – SSMS bağlantı durumu

Bağlantı ayarlarımızda da bir sorun olmadığa göre artık SQL Server Linux üzerinde Always On yapılandırmasına gerçekleştirmeye başlayalım.

Windows SQL Server’da SQL Server Configuration Manager kullanarak SQL Server Always On’u etkinleştiriyoruz. Fakat SQL Server Linux bir GUI yapılandırma yöneticisine sahip değildir. HADR’yi etkinleştirmek için mssql-conf yardımcı programını kullanıyoruz.

Her iki sunucuda aşağıdaki komutu çalıştırıyoruz.

sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled  1

Resim 14 – HADR aktif etme

Komut çalıştırma sonrası yukarıdaki resimde gördüğünüz gibi bizden SQL Server servisi restart etmemiz gerektiğini söylüyor ve işlem için ihtiyacımız olan kodu veriyor.

systemctl restart mssql-server.service

Restart işleminide yaptıktan sonra artık SSMS üzerinden Always On High Availability işlemlerine devam edebiriz.

AG oluşturabilmek için her iki sunucuda AlwaysOn_health Extended Event özelliğini aşağıdaki kod ile açmamız gerekiyor. Bu işlemi SSMS aracılığı ile yada Azure Data Studio aracılığı ile gerçekleştirebilirsiniz.

ALTER EVENT SESSION  AlwaysOn_health ON SERVER WITH (STARTUP_STATE=ON);

Şimdi SQL Server Linux’un Always On yapılandırmasının en önemli kısımına geldik. Burada Master Key, Certificate oluşturup yedeğini diğer sunucuya geri dönüyor olacağız. Çünkü Linux üzerinde mirroring endpoint’ler arasındaki iletişim sertifika ile oluyor. Sertifika işleminden sonra endpoint noktalarını oluşturmamız gerekiyor.

İki sunucudan birinde aşağıdaki kodları çalıştırıp master key ve sertifikayı oluşturabiliriz.

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'DMC@123*!';

CREATE CERTIFICATE sqllinuxdb_sertifika  WITH SUBJECT = 'sqllinuxdb_sertifika';

Ben yukarıdaki kodları sqlinuxnode1 de çalıştırdım. Şimdi ise oluşturduğumuz “sqllinuxdb_sertifika” sertifikasının yedeğini alalım.

Eğer ki bir sebepten oluşturduğunuz sertifikayı silmek isterseniz /var/opt/mssql/data/ altındaki cer ve pvk dosyalarını silin. Daha sonra “DROP CERTIFICATE sqllinuxdb_sertifika; “ile sertifikayı ve en son master key’i silin

USE master;
DROP MASTER KEY;

Artık oluşturduğumuz bir sertifika var ve bu sertifikayı diğer sunucuya kopyalamamız gerekiyor.

sudo scp sqllinuxdb_*.* dmcadmin@sqlinuxnode2/var/opt/mssql/data/

Resim 15 – Sertifika taşıma

Resim 15 den görüldüğü üzere cer ve pvk dosyalarını sqllinuxnode2’a başarılı bir şekilde /tmp dizinine taşıdık.

Taşıma işlemi sonrasında chown komutunu kullarak dosyaların sahipliğini mssql kullanıcısına verelim. Fakat öncesinde ls -ltr ile kontrol edelim.

Resim 16 – ls ltr ile sahiplik kontrolü

Gördüğünüz üzere dosyaların sahipliği dmcadmin olarak gözüküyor. Bu dosyaların /var/opt/mssql/data klasörü içerisine taşıyalım sonra sahipliğini mssql yapalım.

scp sqllinuxdb_*.* /var/opt/mssql/data

Taşıma işlemini gerçekleştirdik. Şimdi sahipliği değiştirelim.

chown mssql sqllinuxdb_*.*
chgrp mssql sqllinuxdb_*.*

Resim 17 – ls ltr sahiplik değişim kontrolü

Yedeğimizi şimdi sqllinuxnode2’a import edelim.

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'DMC@123*!';
USE master
GO
OPEN MASTER KEY
DECRYPTION BY PASSWORD = 'DMC@123*!'
IF EXISTS (SELECT * FROM sys.certificates WHERE name = 'sqllinuxdb_sertifika')
DROP CERTIFICATE sqllinuxdb_sertifika
CREATE CERTIFICATE sqllinuxdb_sertifika 
FROM FILE = '/var/opt/mssql/data/sqllinuxdb_sertifika.cer'
WITH PRIVATE KEY
(
FILE = '/var/opt/mssql/data/sqllinuxdb_sertifika_pvk.pvk' ,
DECRYPTION BY PASSWORD = 'DMC@123*!'
)

Sertifikala işlemlerini de halletiğimize göre sınra Endpoint noktalarını oluşturmaya geldi. Aşağıdaki kodu her iki sunucuda çalıştıralım. Port bilgisi varsayılan olarak gelen 5022’i verdim.

CREATE ENDPOINT [Hadr_endpoint]
AS TCP (LISTENER_PORT = 5022)
FOR DATABASE_MIRRORING (
ROLE = ALL,
AUTHENTICATION = CERTIFICATE sqllinuxdb_sertifika,
ENCRYPTION = REQUIRED ALGORITHM AES
);
ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;

5022 için ubuntu üzerinde firewall izinleri de aşağıdaki kod ile verelim.

sudo apt install ufw
sudo ufw allow 5022 

Artık kalan adımlarda klasik sürecimiz olan SQL Server AG işlemlerini sırası ile gerçekleştirebiliriz.

Resim 18 – AG Name ve Cluster Type seçimi

Yukarıdaki resimde gördüğünüz cluster type alanında NONE ile beraber EXTERNAL de mevcut. Bu iki cluster tipinin neler olduğunu yazının başında anlattım. Bu yüzden NONE ile devam ediyorum.

Bir sonraki ekran AG içerisinde yer almasını istediğiniz veritabanlarınızı seçeceğiniz kısımdır. Burada benim sadece SQLEKIBI isimli veritabanım var. Onu seçip devam ediyorum.

Resim 19 – AG için veritabanı seçimi

Bir sonraki ekran AG için ekleyeceğiniz instance bilgilerinin olduğu kısım. Burada “Add instance…” diyip linuxsqlnode2’u ekliyorum.

Resim 20 – AG için instance ekleme

Yukarıdaki resimde gördüğünüz gibi eklediğim yeni instance için ikincil node okunabilir olarak işaretledim. Endpoints sekmesine geçiyorum ve endpoint bilgilerini kendime göre revize ediyorum.

Resim 21 – Endpoint bilgileri

Diğer ayarları default olarak bırakıyorum.

Bir sonraki ekran Data senkranizasyonun nasıl olacağını gösteriyor. Bu kısımı da varsayılan olarak bırakıyorum.

Resim 22 – AG için Data Senkranizasyonu

Son adımlara geliyoruz, bir sonraki ekran AG için yaptığımız tanımların doğrulanmasının yapıldığı ekrandır. Bu ekranda listener tanımlaması yapmadığımız için uyarı göreceğiz ama işlemimize devam ediyoruz.

Nihayet son adıma geldik ve yaptığımız işlemlerin sonucu olarak yeşil bir ekran ile karşılaşıyoruz.

Resim 23 – AG Sonuç

Yukarıdaki resimde gördüğünüz gibi SQL Server Linux üzerinde Always On AG tanımlamasını başarılı bir şekilde gerçekleştirdik. Son olarak birde Always On Dashboard üzerinden bakalım ve yazımızı sonlandıralım.

Resim 24 – AG Dashboard

Bir yazıyı daha bitirmiş olmanın mutluluğu içerisindeyim. Bu yazıda sizlere Linux üzerinde bir SQL Server Always On Clusterını nasıl çalıştırabileceğinizi, hangi amaç ile SQL Server Linux Always On Clusterını kullanabileceğinizden bahsettim. Sonraki içeriklerde görüşmek üzere.

#sql #sqlserver #sqlserverlinux #sqllinux #sqllinuxAlwaysOn #alwaysOnAG #SQLServerAlwaysOnAvailabilityGroups #pacemaker #linux #microsoft #microsoftloveLinux #dmc #dmcteknoloji #sqlekibi