Bu makalede Non Cluster AlwaysOn kavramına değineceğiz. Herhangi bir cluster yapımız olmadan AlwaysOn işlemini ele alacağız.
Not: Sunucularımız aynı network üzerinde ise cluster olmadan SSMS üzerinden bağlantı gerçekleştirilir. Sadece firewall (güvenlik duvarı) izinlerinin verilmiş olması yeterlidir.
Non-Clustered AlwaysOn (AlwaysOn Availability Groups) terimi, SQL Server’da Availability Groups’ın, Windows Server Failover Clustering (WSFC) gerektirmeyen bir yapılandırmasını ifade eder. Burada aslında “Non-clustered” tabiri, WSFC’nin kullanımı yerine, AlwaysOn Availability Groups’ın standalone bir şekilde, ancak yine de yüksek erişilebilirlik (high availability) ve felaketten kurtarma (disaster recovery) sağlamak amacıyla kullanılabileceği bir durumu belirtir. Ancak, teknik olarak, AlwaysOn Availability Groups işlevselliği için Windows Server Failover Cluster (WSFC) gereklidir. Yani, AlwaysOn özelliği, Failover Clustering’in desteği ile çalışır.
Bu teknoloji aslında Database Mirroring’in yerine getirilmiş bir teknoloji.
Farklı subnetlerde olan AlwaysOn mimarisinde failover cluster bize sorun yaşatabiliyor. IP çakışmaları, quorum (çoğunluk) mekanizması sorunları ve network gecikmeleri nedeniyle “Failover” işlemleri karmaşıklaşabilir. Cluster-less yapı ile Windows seviyesindeki bu karmaşıklıktan kurtulursunuz. SQL Server, replikasyonu kendi içinde (veritabanı motoru seviyesinde) yönetir. Bizde cluster’sız bir şekilde non clustered bir şekilde oluşturabiliyoruz.
Farklı domainlerdeki (veya bir domain yapısı olmayan Workgroup ortamındaki) SQL Server’lar arasında her non clustered veya failover cluster tabanlı alwayson yapısı kurabilirsiniz. Ancak her iki yöntemin de kendine has “olmazsa olmaz” teknik gereksinimleri vardır.
Non-Clustered (Cluster-less) Mimari
Bu yöntemde Windows Failover Cluster (WSFC) kurulmaz. SQL Server, veriyi kendi iç mekanizmasıyla senkronize eder.
- Bağlantı Şekli: Sunucular farklı domainlerde olduğu için birbirlerini Windows üzerinden tanımazlar. Bu yüzden Sertifika Tabanlı Kimlik Doğrulama (Certificate-based Authentication) kullanılır.
- Kullanım Amacı: Genellikle veri yedekliliği veya raporlama (Read-Scale) için tercih edilir.
- Dezavantajı: Otomatik Failover (geçiş) yoktur. Bir sorun anında sistemi manuel olarak diğer sunucuya geçirmeniz gerekir.
“Failover Cluster Tabanlı (Domain-Independent) Mimari
Eğer “farklı domainlerde olsun ama yine de otomatik geçiş (failover) yapsın” derseniz, bu durumda Domain-Independent Availability Group yapısını kurmanız gerekir.
- DNS Suffix: Her iki sunucunun da birbirini DNS üzerinden görebilmesi için birincil DNS son eklerinin (DNS Suffix) yapılandırılması şarttır.
- Windows Cluster: Windows Server 2016 ve üzeri sürümlerde, sunucular farklı domainlerde olsa bile bir “Cluster” oluşturabilirler.
- Quorum (Çoğunluk): Farklı domainlerdeki bu yapıda, oylama mekanizması (Quorum) için genellikle bir Cloud Witness (Azure üzerinde) veya her iki domainin de erişebildiği bir File Share Witness (Ortak Paylaşım Alanı) kullanılır.
Kaldığımız yerden devam edecek olursak:
Non Cluster AlwaysOn yapısında herhangi bir otomatik failover yapısı yok. Failover işlemini biz manuel bir şekilde yapıyoruz.
Non Cluster AlwaysOn yapımızı kurabilmek için sql server configuration manager ekranından instance’ımızın olduğu servise gelip alwayson high availability sekmesinin aktif olduğuna bakmalıyız iki sunucumuzda. Cluster ismimizin görünmesi bir sorun teşkil etmez.
Adventureworks2012 database üzerinde işlem yapacağız. AlwaysOn’a dahil olabilmesi için recovery model full olması gerekmekte ve full backup’ının alınmış olması gerekmektedir. Çünkü secondary sunucusu ldf dosyasını referans alarak senkron olur ve full backup alınmasının sebebi ise kendini garanti altına almış olur.
Always On High Availability sekmesine gelinip New Availability Group Wizard sekmesine tıklanır.
Gelen ekranda AlwaysOn yapımıza bir isim verdikten sonra Cluster type kısmında herhangi bir cluster mimarisi seçmiyorum. Bu yüzden NONE seçeneğini işaretliyorum.
Gereksinimleri karşıladığı için gelen ekranda ilgili veritabanımı seçiyorum Next diyiyorum.
Gelen ekranda Add Replica deyip ikinci bir replicamı ekliyorum.
S2\TEST instance’ımı seçiyorum.
Replicamı ekledikten sonra failover mode kısmı sadece manuel modda kaldığını görmüş oluyoruz. Herhangi bir cluster yapısı olmadığı için failover mode bu şekilde kalır.
Daha sonra üst kısımda bulunan endpoints kısmından veya backup references, listener kısmında bir değişiklik yapmıyorum.
Listener kısmınada ne kadar listener tanımlasaktada listener kavramı bu yapıda çalışmıyor. Çünkü kendimiz elimizle manuel bir şekilde değiştirmiş olacağız. Listener neydi son kullanıcının hangi sunucu primary ise o sunucuya bağlanmasını sağlıyordu. Peki listener hangi sunucunun primary olduğunu failover listener konuşmasından öğrenmiş olur. Bu yapımızda Cluster olmadığını manuel listener ip güncellenmesi gerekmektedir.
Dns’e bir kayıt giriyoruz. Bu listener’a primary makinamızın ip adresini giriyoruz. Bir sıkıntı anında S1\test instance’ımda listener dns kaydına gidip ikinci makinenin ip’sinin manuel bir şekilde yazılması gerçekleşmektedir. Bu işlem manuel bir şekilde gerçekleşir.
Bu açıklamayı yaptıktan sonra Next deyip bir sonraki aşamaya geçiyorum.
Database küçük olduğu için automatic seeding modunda kalabilir.
Next deyip bir sonraki adıma geçiyorum.
Kontrolleri tamamladıktan sonra Next deyip bir sonraki aşamaya geçip kurulumu sonlandırıyorum.
Close deyip ekranı kapattıktan sonra Primary sunucumda kurulumun başarılı bir şekilde olduğunu görmüş oluyoruz.
İkinci sunucumuz olan S2\TEST’de de AG yapımızın geldiğini görmüş oluyoruz.
Kullanıcılarımız veritabanlarına bağlanmak için bir listener olmadığı için bir Dns Name’e ihtiyaç vardır. Active Directory kurulu olduğu AD sunucusunda Windows arama yerine Dns yazarsak Dns arayüzüne bağlanmış oluruz.
Bağlandıktan sonra domain’e almış olduğum sunucu adlarım cluster ismim ve farklı kurmuş olduğum cluster always on yapısı için oluşturduğum LISTENER isminde listener adı ve yapılarını Dns Manager ekranında görmüş oluyoruz.
Dns Manager ekranına boş bir alana tıkladıktan sonra New Host diyerek bir kayıt oluşturuyorum.
Gelen ekranda Host’uma bir isim veriyorum ve primary makinamın ip adresini giriyorum.
Add Host dedikten sonra Yeni Host’umun oluşturduğunu görmüş oluyorum.
Hostumuzu oluşturduktan sonra bu yeni host kullanıcılarımın connection string’ine yazacağı Dns Name olacak artık.
Primary makinamda herhangi bir sıkıntı olduğunda mevcut availability group’umu hemen failover işlemi yapıp Dns Manager ekranından LISTENER2 hostumun üzerine sağ tıklayıp properties’dan ip adresini ikinci sunucumuzun ip adresi yapmamız yeterli.
Failover yapmadan önce otomatikmen listener’a vermiş olduğumuz primary makinenin ip adresini çözer.
Daha sonra sunucularımın arasında AG bazlı bir failover işlemi yapalım.
Bir Data kaybı olacağını söylüyor Çünkü asenkron modda olduğu için.
Gelen ekranda Next deyip bir sonraki aşamaya geçiyoruz.
Primary olacak yeni replica sunucum olan S2\TEST makinasına bağlanıyorum.
Next deyip gelen ekranda finish dedikten sonra işlemlerimi tamamlıyorum.
Failover işlemini yaptıktan sonra secondary makinamız Not Sychronizing durumda bunun için secondary sunucusunda Availability Databases altına gelip ilgili database’i resume yapmak gerekiyor. Aşağıdaki resim failover işlemi yapmadan önceki S1 sunucumun durumu.
Resimde görüldüğü gibi secondary sunucusunda database durmuş durumda Resume deyip işlemlerimi tamamlıyorum.
Not: AG yapımız asenkron modunda olduğu için veritabanını Resume yapmamız gerekiyor.
Database’i AG altında senkron yaptıktan sonra Active Directory’de Dns Manager’e gelip LISTENER2 ip değişikliğini yeni primary sunucumuz yapmamız gerekiyor.
Dns ip’sini manuel bir şekilde değiştirdikten sonra cmd komut satırında ipconfig/flushdns yapıp Dns’in ön belleğinde yer alan verileri sıfırlayarak temizliyorum.
Yukarıdaki resimde görüldüğü gibi işlemlerimizi başarılı bir şekilde yapmış olduk.
Non Cluster AlwaysOn Yapısının:
Faydaları:
- Failover Clustering’in karmaşıklığından kaçınılır ve hızlı bir yapılandırma sağlar. Kurulum işlemleri daha kolaydır.
- Her bir replica kendi depolama alanını kullanır, bu da sanal ortamlar ve bulut tabanlı altyapılarla uyumlu olmasını sağlar.
- Primary ve secondary replika arasında veri replikasyonu ile yüksek erişilebilirlik sağlanır. Asenkron commit modunda bile failover yapılabilir.
- Senkronize commit veya asenkron commit seçenekleri ile esnek bir yapı sağlanır. Coğrafi olarak uzak sunuculara veri replikasyonu yapılabilir.
- Windows Server Failover Clustering (WSFC) kullanımı gerektirmez, bu da ek yazılım ve yapılandırma gereksinimini ortadan kaldırır. Yöneticiler için yükü azaltır.
- Replikalar üzerinden yedekleme ve kurtarma işlemleri yapılabilir, esnek çözümler sunar.
Zararları:
- Asenkron commit kullanıldığında, veriler gecikmeli aktarılabilir ve veri kaybı yaşanabilir. Senkron commit kullanılmazsa verilerde tutarsızlık olabilir.
- Failover clustering olmadığı için otomatik failover desteği sınırlıdır. Failover işlemi için manuel müdahale gerekebilir.
- Failover Clustering’in sunduğu yönetim araçları ve izleme özellikleri kullanılamaz, bu da ek yönetimsel çaba gerektirir.
- Ağ bağlantısındaki kesintiler veya ağ gecikmeleri, replikasyonun düzgün çalışmamasına yol açabilir. Düşük ağ performansı, senkronizasyon sorunlarına neden olabilir.
- Felaketten kurtarma senaryolarında Failover Clustering’in sunduğu kolaylıklar eksiktir. Felaket durumunda secondary replica’nın devreye girmesi için daha fazla manuel müdahale gerekebilir.
- Ağ üzerinden yapılan replikasyon, yüksek trafik veya ağ gecikmesi durumunda performans sorunlarına yol açabilir. Asenkron commit kullanıldığında senkronizasyon hızı düşük olabilir.
- Paylaşılan disk olmayan yapılar felaket senaryolarında daha büyük veri kaybı riski taşıyabilir. İkincil replikada veriler tam olarak güncellenmeyebilir.
Bu makalede Non Cluster AlwaysOn yapısını ele almış olduk. Başka bir makalede görüşmek dileğiyle.
*Göklerde ve yerde ne varsa hepsi Allah’ındır. Allah’ın ilmi ve kudreti her şeyi kuşatmıştır. Nisa-126*
