Microsoft SQL Server 2017 on Linux AG Cluster Type None and External

Merhaba,

Bu makale Pacemaker ve Microsoft SQL Server on Linux yazılarının devamı niteliğinde olup, öncesinde bir göz atmanızda fayda olacağı düşüncesindeyim çünkü ilgili yazılardaki cluster kurulumu veMicrosoft SQL Server kurulumları bu makalede yok. Biraz uzun ama keyifli bir yazı olduğunu düşünüyorum.

Windows üzerindeki Availability Group (AG) yaratabilmek için Windows Server Failover Cluster (WSFC), Linux üzerinde ise WSFC’e karşılık Pacemaker kullanılıyor.

Windows üzerinde WSFC rolü çok büyük;  failover, health monitoring ve resource management dışında metadata bilgisinin ki içersinde hem WSFC konfigürasyonu, host edilen uygulama konfigürasyonu, node’lardaki değişikliklerin güncellenmesi ve bunların cluster’a yayılması gibi işlevleri var.

Linux üzerinde Microsoft SQL Server 2017 AG konfigürasyonu için iki tip cluster tipi mevcut, bunlardan biri EXTERNAL diğeri ise NONE. Aralarındaki fark ise kısaca ;

  • NONE, pacemaker ihtiyacı olmadan, sadece read scale ve manuel failover için kullanılıyor.
  • EXTERNAL, pacemaker kullanarak, otomatik failover sağlamak ve devamlığı artırmak için kullanılıyor.

Linux üzerinde WSFC servisi olmadığından bu konfigürasyon bilgileri (metadata) SQL Server instance tarafından master database’inde tutulmaya başlıyor buda bize herhangi bir witness olmadığında (file-share witness gibi) konfigürasyonun tutulacağı problem anında cluster’ın ayakta kalmasını sağlayacak üçüncü bir üyenin olması gerekliliğini yaratıyor, böylece bu üç node’a dağıtık bir metadata bilgisinin olmasını sağlıyor.

Yani kısacası, EXTERNAL tipinde yani Linux üzerinde otomatik failover olacak şekilde bir AG kuracaksanız, üç adet node’a ihtiyacınız var. Buda size üç adet lisans anlamına geleceğinden gözleriniz parlayabilir fakat şöyle bir hinlik yapılmış 🙂

Hinlik şu, configuration only replica, herhangi bir veritabanının yedeğini üzerinde tutmuyor sadece gerekli metadata dağıtımı ve devamlılık için ilgili veriyi üzerinde tutuyor. Burada Microsoft tarafından önerilende ücretsiz kullanabildiğiniz Express versiyonunu olabilir.

Linux üzerinde Read Scale AG (Mysql bilgisi olanlar için Master-Slave desek ışıklar yanmaya başlar)

Elimizde bu işlem için iki adet host var bunlardan biri 10.110.110.210 ve diğeri 10.110.110.211 ve bunlara Microsoft SQL Server kurulu.

Şöyle bir çılgınlık var, vermiş olduğunuz sunucuların hostname’lerini kontrol edin, 15 karakteri geçmesinler 😦

/etc/hosts dosyalarını güncelleyin, tüm node’lar birbirlerini hostname üzerinden çözebilir olsunlar

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4

::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

10.110.110.210  mssql1.dorukcloud.com mssql1

10.110.110.211  mssqlonlinux2.dorukcloud.com mssqlonlinux2

10.110.110.212  mssqlonlinux3.dorukcloud.com mssqlonlinux3

Burada pacemaker ihtiyac olmadan NONE tipinde bir AG kuralım (/dev/null deselerdi keşke, NONE nedir ?)

Kurduğumuz Microsoft SQL Server 2017 instance’ların AG için aktive etmemiz gerekiyor, bu işlemi yaptıktan sonra instance’ları restart etmelisiniz.

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

systemctl restart mssql-server

Not* : Set edilebilecek diğer tüm server özellikler için bakınız

Not* : Eğer bu kısmı atlarsanız aşağıdaki hata ile karışalaşacaksınız GUI’de.

Bu arada bu konfigürasyonu yaparken hem GUI hemde t-sql script’lerle nasıl yapabilirizede bakacağız.

Elimdeki bir Windows server’a SSMS 17.9 indirdin ve kurun.

SSMS üzerinden her ikisine birden bağlanın ;

  • Herhangi bir mssql sunucusu üzerinde iki adet test veritabanı yaratın. (Varsayılı olarak recovert mode full geliyor ama siz yinede kontrol edin)
    • DB1 : LinuxTestAlwaysOnNoneType
    • DB2: LinuxTestAlwaysOnExternalType
  • Her iki veritabanınında yedeklerini alın.

Linux üzerinde mirroring endpoint’ler arasındaki iletişim sertifika ile oluyor bunu için önce sertifika yaratıp daha sonrada AG üyeleri arasındaki mirroring işlemleri için endpoint tanımlamalıyız. (Yakında WINDOWS Auth’de geliyor olacakmış.)

Herhangi bir mssql node üzerinde aşağıdaki T-SQL’i script’ini çalıştırın. Ben bunu 10.110.110.210 üzerinde çalıştırdım.

CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘2Masterkeysifresi!’;
CREATE CERTIFICATE dbm_certificate WITH SUBJECT = ‘dbm’;
BACKUP CERTIFICATE dbm_certificate
TO FILE = ‘/var/opt/mssql/data/dbm_certificate.cer’
WITH PRIVATE KEY (
FILE = ‘/var/opt/mssql/data/dbm_certificate.pvk’,
ENCRYPTION BY PASSWORD = ‘2Privatekeysifresi!’
);

Not*: Olası durumlarda ilgili sertifikayı şifresi veya x bir neden ile bunları silmek isteyebilirsiniz. Bu durumda aşağıdaki komutları kullanalısınız.

  • Öncelikle /var/opt/mssql/data/ altındaki cer ve pvk dosyalarını silin
  • Daha sonra sertifikayı silin
    • DROP CERTIFICATE dbm_certificate;
  • Ve en son master key’i silin
    • USE master;
    • DROP MASTER KEY;

Elimizde yaratılmış bir sertifika var artık ve bunun diğer mssql sunucusuna kopyalayın. Aşağıdaki komutları 10.110.110.210 üzerinde çalıştırdım.

scp dbm_certificate.* root@10.110.110.211:/var/opt/mssql/data/

ssh root@10.110.110.211 chown mssql:mssql /var/opt/mssql/data/dbm_certificate.*

Diğer mssql server üzerinde export’unu aldığımız sertifikayı import edelim.

CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘2Masterkeysifresi!’;
CREATE CERTIFICATE dbm_certificate
FROM FILE = ‘/var/opt/mssql/data/dbm_certificate.cer’
WITH PRIVATE KEY (
FILE = ‘/var/opt/mssql/data/dbm_certificate.pvk’,
DECRYPTION BY PASSWORD = ‘2Privatekeysifresi!’
);

Not*: Burada ben bir sertifika yarattım ve bunu diğer node’lara import ettim, bunun dışında her node üzerinde farklı sertifikalar yaratıp bunlarıda node’lara dağıtıp, import edebilirsiniz.

Şimdi endpoint’leri yaratalım, aşağıdaki komutu her iki mssql sunucusundada çalıştırın.

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

Not* : Endpoint yaratırken LISTENER tanımınıda set edebilirdik, ihtiyacımız olmadığından eklemedim.

Şimdi GUI’e geçelim biraz, AG üzerinde sağ tuş ile Wizard’ı çalıştırın.

Opsiyonları seçerken, küme ismini ve küme tipini NONE olarak belirleyelim.

Not* : Database Level Health Detection kutucuğunu işaretledim, bu Microsoft SQL 2016 ile beraber gelmiş bir özellik, burada disk bozulmaları, diskteki yer kalmama durumları, loglarda ve hardware üzerindeki bozulmalarda failover yapıp daha iyi bir şekilde yönetebilir oluyor sistemi, bakınız

Dökümanlarda bu kutucuğu t-sql olarak “ALTER EVENT SESSION [AlwaysOn_health] ON SERVER WITH (STARTUP_STATE=ON)” şeklinde göreceksiniz.

AG’e ekleyeceğiniz ilgili veritabanını seçin ver ilerleyin

Önce bir endpoint durumuna bakalım

Şimdide kopyaları ayarlayalım

  • Failover Mode dikkat ederseniz sadece Manuel (NONE Type Cluster)
  • Her iki mssql sunucusunuda okunabilir olarak ayarlayalım

Veri tabanı yaratılması ve data senkronizasyonu otomatik olsun diye set edelim.

Doğrulama tamam mı ? (Listener set etmediğimi daha önce belirtmiştim)

ileri > İleri ve kurulum bitmiştir

Not* : Wizard çıktısındaki script çıktısına ulaşmak için bu link’e tıklayabilirisiniz.

Artık LinuxTestAlwaysOnNoneType veritabanında tablo yaratıp içersine veri koyup senkronizasyonu test edebilirsiniz. Benim kurulumumda çalışıyor, umarım sizinkindede çalışıyordur.

Failover için bir test yapalım, primary değil secondary olarak çalışan replika node’a bağlanıp aşağıdaki komutu çalıştırın.

use master;
ALTER AVAILABILITY GROUP LinuxIsAlwaysOnNone FORCE_FAILOVER_ALLOW_DATA_LOSS;

Eğer primary ile secondary yer değiştir ise herşey tamam demek oluyor.

Birde hızlıca EXTERNAL küme tipini ele alalım

Oldukça kolay olacak çünkü daha önce pacemaker ile ilgili iki önceki metindeki konfigürasyon ile biraz önce NONE tipinde bir küme oluşturduğumuzdan ilgili endpoint’ler, üstüne üstlük Linux üzerinde mssql express kurulumunuda bir önceki metinde tanımları yapmıştık.

Elimizde iki adet host vardı Microsoft SQL Server kurulu, bunlardan biri 10.110.110.210 ve 10.110.110.211. Şimdi bunlara sadece config only üçüncü bir host daha ekleyeceğiz ip adresi 10.110.110.212 olan. Bu sunucuda MSSQL Express kurulu (Maliyet’i artırmamak için EXTERNAL küme modunda bu şekilde yapmamız gerekiyor.)

External küme modunda pacemaker kullanacağız.

Başlayalım …

EXTERNAL küme tipi bize HA sağlayacak, olası bir durumda otomatik failover yaparak erişilebilirliği devamlı hale getirecek.

EXTERNAL küme tipi için WSFC yerine Pacemaker kullanacağız, Pacemaker konfigürasyonunuda AG konfigürasyonunudan sonra yapılacak.

Şimdi yeni sunucuyuda AG için kullanıma hazır hale getirelim, 10.110.110.210 ve 10.110.110.211’e endpoint kurmuştuk şimdi 10.110.110.212’e kuralım.

SSMS’e 10.110.110.212’de ekliyorum

/etc/hosts dosyasında her üç mssql sunucununda birbirlerini çözdüğüne emin olmamız lazım, bunları gözden geçirin.

Always On aktive ediyorum 10.110.110.212 üzerinde …

/opt/mssql/bin/mssql-conf set hadr.hadrenabled  1
systemctl restart mssql-server

Endpoint yaratmak için sertifikaları kopyalayıp, import ediyorum ..

scp dbm_certificate.* root@10.110.110.212:/var/opt/mssql/data/
ssh root@10.110.110.212 chown mssql:mssql /var/opt/mssql/data/dbm_certificate.*

CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘2Masterkeysifresi!’;
CREATE CERTIFICATE dbm_certificate
FROM FILE = ‘/var/opt/mssql/data/dbm_certificate.cer’
WITH PRIVATE KEY (
FILE = ‘/var/opt/mssql/data/dbm_certificate.pvk’,
DECRYPTION BY PASSWORD = ‘2Privatekeysifresi!’
);

MSSQL Express için yartacağımız endpoint rolü witness olmalı

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

Evet, yeni bir Availability Group yaratalım, wizard’ı tetikleyin ….

Değişiklik belli ekranlarda olacağı için sadece o ilgili ekranları ekliyorum, tip EXTERNAL ….

İlgili veritabının seçelim (dikkat! veritabanı yaratılmış ve yedek alınmış olmalı)

Gördüğünüz gibi üç adet mssql sunucumuzu ekledik, failover mode external, otomatik failover olması için availability mode senkron olmak zorunda, iki node’u read replika, diğer üçüncü node ise configuration only olarak durmakta.

Script hali için

Pacemaker Konfigürasyonu

Pacemaker mssql sunucularına ulaşıp HA yönetebilmesi için mssql üzerinde bir kullanıcı ve belirli haklara sahip olması gerekiyor AG üzerinde.

Bunun için tüm mssql sunucular üzerinde aşağıdaki komutları çalıştırın.
Not*: 
LinuxIsAlwaysOnExternal AG’nin adı.

USE master
CREATE LOGIN pacemaker
WITH PASSWORD = ‘!guvenL34’
GRANT ALTER, CONTROL, VIEW DEFINITION ON AVAILABILITY GROUP::LinuxIsAlwaysOnExternal to pacemaker
GRANT VIEW SERVER STATE TO pacemaker

Pacemaker’ın failover/HA mekanizmasını yönetebilmesi için bu kullanıcıdan kendisini haberdar etmemiz gerekiyor.

echo ‘pacemaker’ >> /var/opt/mssql/secrets/passwd
echo ‘!guvenL34’ >> /var/opt/mssql/secrets/passwd

Bu passwd dosya tüm AG oluşturan node’larda ilgili dizinde olması gerekiyor, ilgili dosyayı 10.110.110.210 üzerinde oluşturduğumdan ordan diğer node’lara kopyalıyorum.

cd /var/opt/mssql/secrets/passwd
scp passwd root@10.110.110.211:/var/opt/mssql/secrets/
scp passwd root@10.110.110.212:/var/opt/mssql/secrets/

Sadece root okuyabilir şekilde bırakıyoruz, pacemaker’ı root kullanıcısı yönetiyor çünkü …

chmod 400 /var/opt/mssql/secrets/passwd (10.110.110.210 üzerinde)

chmod 400 /var/opt/mssql/secrets/passwd (10.110.110.211 üzerinde)

chmod 400 /var/opt/mssql/secrets/passwd (10.110.110.212 üzerinde)

Tüm mssql kurulu node’larda pacemaker resource agent’ları kurmalıyız ki pacemaker durumu nasıl yönetebileceğini bilsin

yum install mssql-server-ha -y

Pacemaker MSSQL 2017 ile beraber tanıtılmış REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT diye bir parametreyide yönetiyor, bu parametre ile read scale, HA&Data Protection ve sadece Data Protection ile ilgili karar verebiliyorsunuz, amaç hangi durumlarda failover olur, failover olur ise yeni primary R/W duruma geçer mi veya kaç adet kopyası yazılmalı ki sistemde problemsiz devam etsin, eğer edemiyor ise transaction’a sistem kapansın gibi ayarlamalar için kullanılıyor.

Pacemaker ile iligili yazımda zaten bir cluster yaratmıştım iki sunucudan oluşan şimdi bu fırsat ile üçüncü suncuyu cluster’a nasıl ekleyeceğimide görmüş oldum.

10.110.110.212 – mssqlonlinux3 sunucusuna bağlanın ve Pacemaker için gerekli linux paketlerini kurup, ilgili adımları ilerletin.

yum install -y pacemaker pcs; systemctl enable pcsd ; systemctl start pcsd

Hacluster şifresini diğer sunucular ile aynı set edin

passwd hacluster

Bu işlemden sonra cluster’ın çalıştığı diğer sunuculardan birinde (Ör:10.110.110.210) yeni sunucuyu auth edin ve ilgili sunucuyu cluster’a ekleyin.

pcs cluster auth mssqlonlinux3

pcs cluster node add mssqlonlinux3

Yine yeni node üzerinde aşağıdaki komutları çalıştırın

pcs cluster start

pcs cluster enable

pcs property set stonith-enabled=false

pcs status  komutu ile cluster’ı kontrol edin ..

Not*: Eğer olurda üç node göremez iseniz, emin olmak için son eklediğiniz sunucuyu restart edin ve tekrardan “pcs status” komutunu çalıştırıp küme durumunu kontrol edin.

Herhangi bir node üzerinde timeout, hata durumunda restart etmek için gereki değerleri güncelleyelim

pcs property set start-failure-is-fatal=true

pcs property set cluster-recheck-interval=2min

Pacemaker üzerinde AG yönetebilmek için kaynağı yaratalım

pcs resource create AG_External ocf:mssql:ag ag_name=LinuxIsAlwaysOnExternal meta failure-timeout=60 master notify=true

pcs status

3 nodes configured

4 resources configured

Online: [ mssql1 mssqlonlinux2 mssqlonlinux3 ]

Full list of resources:

Cluster_VIP (ocf::heartbeat:IPaddr2): Started mssql1

Master/Slave Set: AG_External-master [AG_External]

     Masters: [ mssql1 ]

     Stopped: [ mssqlonlinux2 mssqlonlinux3 ]

Biraz bekleyelim, tekrar bakalım

Full list of resources:

Cluster_VIP (ocf::heartbeat:IPaddr2): Started mssql1

Master/Slave Set: AG_External-master [AG_External]

     Masters: [ mssql1 ]

     Slaves: [ mssqlonlinux2 mssqlonlinux3 ]

Listener için bir Virtual IP yaratılması gerekiyor ki daha önce zaten yaratmıştım, bakınız. VIP bizim mssql listener olacak.

Şimdi VIP ile AG’i birbirine bağlayalım ki beraber sağa sola taşınabilsinler

pcs constraint colocation add Cluster_VIP AG_External-master INFINITY with-rsc-role=Master

Kontrol etmek için

pcs constraint list

Bu arada ordering diye birşey, herhangi gibi bir failover’da önce IP adresinin değil, önce servisi veya veritabanının aktive edilmesi daha sonra IP geçmesini istiyorsanız aşağıdaki gibi set etmelisiniz

pcs constraint order promote AG_External-master then start Cluster_VIP

Test …

Test için bir tablo yaratıp içersine bir iki veri yazalım, bunun için hazırdaki ilgili t-sql’i kullanabilirsiniz.

*Uyarı : Microsoft test dışında cluster tipi external olan bir yapıda SSMS ve T-SQL üzerinde herhangi bir failover girişiminin uygulanmamasını, bunu Pacemaker tarafından yönetmesini belirtiyor.

Bizim iki senkron kopya ve bir konfigürasyon node’umuz var idi , bu durumda “REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT” değeri varsayılı olarak 0 olarak set edilmiştir eğer olurda primary down olur ise , secondary olarak çalışan R/W mode’da çalışmaya devam edecek bu ayarda.

Not* : İki senkron kopya ve bir konfigürasyon modunda eğer olurda ikinci kopya ve konfigürasyon node’u bir şekilde devre dışı kalır ise bu durumda sistem çalışmaz hale gelecektir, birinci kopya herhangi bir işleme cevap vermeyektir.

pcs status diyerek durumu kontrol edin …

Online: [ mssql1 mssqlonlinux2 mssqlonlinux3 ]

Full list of resources:

Cluster_VIP (ocf::heartbeat:IPaddr2): Started mssql1

Master/Slave Set: AG_External-master [AG_External]

     Masters: [ mssql1 ]

     Slaves: [ mssqlonlinux2 mssqlonlinux3 ]

Şimdi biz manuel failover değilde direkt birinci gözüken kopya olan “mssql1” ‘i direkt shutdown edelim ve bakalım neler olacak.

Gördüğünüz gibi “mssqlonlinux2” ‘i promote ediyor , “mssql1” üzerindeki instance’a login olamadığını söylüyor.

Online: [ mssql1 mssqlonlinux2 mssqlonlinux3 ]

Full list of resources:

Cluster_VIP (ocf::heartbeat:IPaddr2): Stopped

Master/Slave Set: AG_External-master [AG_External]

     AG_External (ocf::mssql:ag): Promoting mssqlonlinux2

     Slaves: [ mssqlonlinux3 ]

     Stopped: [ mssql1 ]

Failed Actions:

* AG_External_demote_0 on mssql1 ‘unknown error’ (1): call=46, status=complete, exitreason=’2018/10/14 13:00:51 Could not connect to instance: Unresponsive or down Login error: mssql: Login failed for user ‘pacemaker’. O’,

    last-rc-change=’Sun Oct 14 13:00:51 2018′, queued=0ms, exec=196ms

Bir daha bakalım …

mssqlonlinux2” aktif artık birincil kopya o, bu arada IP adreside yeni makineye geçmiş, ben henüz listener eklemedim ama kendisi aslında listener ip adresi olacaktır ayarlandığında.

Online: [ mssqlonlinux2 mssqlonlinux3 ]

OFFLINE: [ mssql1 ]

Full list of resources:

Cluster_VIP (ocf::heartbeat:IPaddr2): Started mssqlonlinux2

Master/Slave Set: AG_External-master [AG_External]

     Masters: [ mssqlonlinux2 ]

     Slaves: [ mssqlonlinux3 ]

     Stopped: [ mssql1 ]

GUI üzerinden’den kontrol ettiğimide ilgili durumu doğruluyor

,

Dilerseniz bu durumdayken birkaç eklenti daha yapıp, kapattığımız makineyi tekrardan geri açtığımızda sync olduğunu görelim.

Geri gelmiş …

Online: [ mssql1 mssqlonlinux2 mssqlonlinux3 ]

Full list of resources:

Cluster_VIP (ocf::heartbeat:IPaddr2): Started mssqlonlinux2

Master/Slave Set: AG_External-master [AG_External]

     Masters: [ mssqlonlinux2 ]

     Slaves: [ mssql1 mssqlonlinux3 ]

GUI’den bir bakalım, herşey tamam ! 

Neden elle failover yapmadın derseniz, kolayıma geldi çünkü elle failover yaptığımızda pacemaker location constraints ekliyormuş, location constraints ilgili kaynağın nerede çalışacağını belirler, ilgili kaynak için preferred node gibi.

İlgili manuel failover yaptıktan sonra bu location constraints silmek gerekiyormuş ve bu sadece bu tip testlerde oluşuyormuş otomatik failover’larda bu tip bir bilgi yok. Siz denemek istiyorsanız ilgili link’i takip edin lütfen.

Birde listener ekleyelim …

Aşağıdaki komutu primary instance üzerinde çalıştırın.

ALTER AVAILABILITY GROUP LinuxIsAlwaysOnExternal
ADD LISTENER ‘LL’ ( WITH IP ( (‘10.110.110.215′,’255.255.0.0’) ) , PORT = 1433 );

Evet, şimdi sıra geldi K8s üzerinde bu işi yapmaya, bunun için hazırlamış olduğum henüz bitmemiş bir çalışma var, arkasından persistent storage olayına baktıktan sonra K8s üzerinde MSSQL.

Güzel olacak …

Advertisements

Posted on 14/10/2018, in Clustering, Database, MSSQL 2017 on Linux, pacemaker and tagged , , , , , , , , , , , , . Bookmark the permalink. Leave a comment.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: