Clusterlar Arası AlwaysOn Kurulumu-Distributed AlwaysOn(DAG)

Ömer AKKÖK

Bu makalede SQL Server 2016 versiyonu ile hayatımıza giren Distributed AlwaysOn(DAG) özelliğinden bahsedeceğiz.

• DAG Farklı Windows Failover Cluster (WSFC)’lar arası AlwaysON kurabilmemize olanak sağlamaktadır.
• DAG kullanabilmemiz aktifleştirebilemiz için ortamlarımızın fiziksel, sanal yada bulutta olması bu özelliği kullanmamıza engel değildir.ortamlarımızda WFSC ve 5022,1433 portlarımızın erişimi olması yeterlidir.
• SQL Sürümlerinin MS SQL 2016 ve üzeri sql sürümleri olmalıdır. SQL Özelliği olduğu için İşletim sisteminin farklılıkları engel değildir.
• DAG yapılandırması Klasik AG yapılandırmasından biraz farklıdır. Normalde her bir AG dahil olduğu replikaları Primary ve Secondary olarak beslerken burada Hem kendi AG’ sinde bulunan replikaları hemde DAG’a bağlı olan İletici(Forwarder) AG yi besler. İletici(Forwarder) ile birlikte farklı secondarylerde beslenebilir. Bu durumlarda Primary harici 2. WSFC lerde dahil sadece read-only olarak hizmet verebilir. Failover edilip Primary olmadığı sürece.
• Clusterless AlwaysON dan farkı, Clusterless AlwaysOn için yeni bir AG kurarken Cluster type=NONE olması gerekmektedir. Bu durumda mevcut clusterımıza dahil olan replikalarımızda Auto-Failover özelliği engellenir. DAG ile AG kurulumundaki Cluster Type=Windows Server Failover Cluster seçildiğinden aynı AG üzerinden hem clustera dahil olan replikalar otomatik Failover olabilecek hem de cluster dışı AG ler beslenebilecektir. Clusterless AlwaysOn Kurulumu için bknz:
• Sync yada Async olarak kullanılabilir.
• Auto-Failover özelliği bulunamamaktadır.
• Failoverlar’da FORCE_FAILOVER_ALLOW_DATA_LOSS seçeneği ile farklı WSFC’lerdeki AG lere Failover edilebilir.
• DAG’ı SSMS üzerinde izleyemiyoruz. DMV’ler yardımıyla Redo ve Commit zamanlarını kontrol edebiliriz.

Peki Neden Kullanmalıyız ?

1) Normal şartlarda Multi-Subnet AO ile aynı WSFC ye aldığımız farklı Subnetteki sunucuları AO ekleyerek tek bir primary node ile secondary nodeları besliyoruz. Bu yapıda Cluster ,witness ve vote bağımlılığımız oluyor. Bu şekilde Clusteri kaybettiğimizde tüm AG ler hizmet veremez durumlara geliyor. DAG ile bu senaryolarda Cluster, witness ve vote kendi cluster içinde olacağı için bağımlılık kalkmış oluyor. herhangi bir şekilde 1.Clusteri kaybettiğimiz senaryoda 2.Clusterımız hala ayakta kalıyor tabi manuel müdahale ile FORCE_FAILOVER_ALLOW_DATA_LOSS geçeneği ile data kaybı var ise kabul ederek failover yapılıp, ileticiyi primary olarak yapılandırabiliyoruz.

2) Farklı Clusterlar da bulunan bir çok prod ortamımız olduğunu düşünelim bu prod ortamların ise doğrulama yapmak için bir veri tabanına ihtiyacı var. Örneğin UserDB tüm prod-rapor ortamların UserDB içerisindeki User tablosunda sorgulama yapıyor. İşte tam bu noktada DAG ile farklı clusterlara UserDB veri tabanını Sync bir şekilde replikasyonunu sağlamana olanak tanır. Normal şartlarda UserDB veri tabanına sorguya gidip prod ortamda yük yaratacakken bu şekilde yükü yayarak erişilebilirlik daha da artırılabilir.

3) Sql Upgrade  (Sql Server 2016 >>> Sql Server 2017) sunucu değişikliği çalışmalarında da DAG kullanılabilir. SQL 2016 ile gelen bir özellik olduğu için daha önce ki sürümler desteklenmemektedir.

4) Windows Server 2012 r2 işletim sistemine sahip bir ortama sahibiz ve bu ortamı Windows Server 2016 yada daha üst versiyona sahip bir WSFC ortama taşımak istiyoruz. Bu aşamada da DAG yapılandırarak Geçişleri hızlı bir şekilde sağlayıp failover sonrası yeni clusterda olan tüm replikaları hızlı bir şekilde besleyerek ayağa kaldırabiliriz.

DAG yapılandırmak;

Bu yapılandırma ile mevcut bir AG de bulunan dbleri mevcut ortamı bozmadan DAG yöntemi ile farklı bir WSFC ortamına da replikasyonunu sağlayacağız ve failover yapacağız.

AG_CL2 Mevcutta WindowsFailoverCluster AO;

Kurulum;

1) Eğer AG yok ve DAG yapılmak isteniyorsa bir endpoint oluşturmak gerekiyor;

2) Endpointlere servis hesaplarını çapraz yetkilendiriyoruz. (Primary instance’ın service hesabını Secondary instance’da, Secondary İnstance’in service hesabını Primary’de);

3) DAG’da bulunacak tüm AG lerde Çalıştırılır;

4) Secondary instance’da yeni bir AG oluşturulur;

 

5) Primary İnstance’da DAG yaratılır;

6) Secondary instance’da JOIN edilir;

 

7)DAG kurulumu tamamlandı.Secondary instanceda bulunan DBler Kullanılacaksa Sadece Read-Only olarak açılabilir.

DAG İzleme:

DAG özelinde Sync durumlarının Kontrolü İçin;

Script1;

 

Script2;

 

 

DAG ile beslenen secondary’ye failover;

1) Primary ve secondary instancelarda AG statülerini synchronized yap

2) Kontrol için SYNCHRONIZED olmasını bekle!

3) LSN kontrolü yapılır;

4) LSN’ler eşit ise primary instance da çalıştırılır.

5) Failover Yapılır

6) Failover oldu. Eski Primaryi kullanacaksak Async çekelim.

7) Read-only yapmak istiyorsak;

İyi çalışmalar.

Yorum yapın