SQL Server Always ON AG(Availability Group) Oluşturmak

Always ON teknolojisi Mirroring Teknolojisinin üzerine kurulmuştur. Mirroring’in geliştirişmiş halidir diyebiliriz. “Database Mirroring Nedir ve Nasıl Yapılır? Mirroring Hataları ve Çözümleri..” isimli makalemi okumak isteyebilirsiniz.

Always On HA(High Availability) ve DR(Disaster Recovery) çözümüdür.

High Availability yüksek erişilebilirlik demektir. Genelde aynı veri merkezinde, birden fazla sunucu ile yapılır. Sunuculardan birinin arızalanması sonucu diğerinin devreye girmesini sağlayan teknolojidir.

Disaster Recovery felaket kurtarma demektir. Veri merkezinde oluşabilecek herhangi beklenmedik bir felaket sonucu(deprem, sel, yangın) veri merkezinin tamamen hizmet veremez duruma gelme ihtimaline karşı genelde uzak bir lokasyonda farklı bir veri merkezi kurularak sağlanır. Örneğin veri merkeziniz Ankara da ise felaket kurma merkezi olarak İstanbul’u ya da daha az riskli bir şehri tercih edebilirsiniz.

Always On kurabilmek için aynı windows cluster içersinde olması zorunlu olan en az 2 sunucuya ihtiyaç duyulur. HA ve DR çözümlerini AG(Availability Group) ile sağlar.

Hatırlarsanız Database Mirroring’de veritabanı bazında mirroring yapılıyordu. Always ON’da  ise birden fazla veritabanı grubu oluşturulabiliyor. Bu gruba AG(Availability Group) deniyor. Failover AG bazında gerçekleşiyor. Örneğin instance’ınız üzerinde 50 veritabanınız var. Bu 50 veritabanını için 5 tane AG oluşturdunuz. Bu 5 AG’nin 3 tanesini 1.sunucuda, 2 tanesinide 2.sunucuda aktif olarak çalıştırabilirsiniz. Ya da ne zaman ihtiyaç duyarsanız AG bazında failover işlemini gerçekleştirerek AG’nin aktif olduğu sunucuyu değiştirebilirsiniz. Always On AG veritabanı uzmanının işini bir hayli kolaylaştırdı.

Mirroring’de ki gibi Senkron ve Asenkron veritabanları vardır. AG bazında Senkron ve Asenkron olarak set edebilirsiniz.

AG’yi senkron olarak set ederseniz AG içindeki tüm veritabanları senkron bir şekilde çalışacaktır. Yani primary veritabanına gelen bir istek secondary veritabanında işlenmeden kullanıcıya işlem tamamlandı bilgisi iletilmeyecektir. Bu çok yoğun transaction alan veritabanlarında biraz performans kaybına neden olabilir. Ama otomatik failover senkron ag’lerde yapılabildiği için rahatça uyuyabilirsiniz. Sunucularda herhangi bir sıkıntı olması durumunda kimse farkında bile olmadan AG diğer sunucudan otomatik bir şekilde hizmet vermeye devam edecektir.

AG’yi asenkron olarak set ederseniz primary veritabanına gelen bir istek secondary veritabanına işlenmeyi beklemeden direk kullanıcıya işlem tamamlandı bilgisi iletilecektir ve arka tarafta senkronizasyon yapılacaktır. Hep merak edilen soru şudur: Asenkron AG’de secondary veritabanları ne kadar geriden gelir? Belli bir süresi yoktur. Mevcut donanım ve network’ün performansına göre bu süre değişir. Ama genelde birkaç saniyedir.

AG bazında otomatik ya da manual failover ayarı yapabilirsiniz. Otomatik failover yapabilmek için AG’yi senkron olarak set etmeniz gerekir. Ben çok yoğun transaction içeren sistemler yönetiyor olmama rağmen genelde Ag’yi senkron ve otomatik olarak set ediyorum. Index rebuild işlemlerinde performans kaybı daha fazla olduğu için sıkıntı yaşayan sistemlerde Index Rebuild öncesi AG’yi asenkrona alıyorum.

Otomatik failover işlemi AG’ye dahil bir veritabanında oluşan bir hata sonucu gerçekleşmez. Availability Replica seviyesinde gerçekleşir. Yani AG’deki veritabanlarından biri corrupt olmuş,transaction log’u dolmuş, data file’ı dolmuş gibi sebeplerde otomatik failover gerçekleşmez.

HA ve DR’nin Always ON’da nasıl kullanıldığını anlamınız için size bir örnek vereyim. Veri merkezinizde 2 sunucunuz var. Bu ikisini windows cluster yaptınız. Bu ikisi üzerinde Always on kurdunuz ve senkron yaptınız. Bu işleme HA(High Availability) çözümü deriz. Veri merkezinde bir sıkıntı olma ihtimaline karşı başka bir şehirdeki veri merkezinizde de bir sunucuz daha  var. Bu 3.sunucuyuda mevcut windows cluster’ınıza dahil ettiniz ve mevcut always on’unuza replica olarak eklediniz ve asenkron yaptınız. Bu işleme de DR(Disaster Recovery) çözümü deriz. Always On’da aynı AG için birden fazla secondary yapabiliriz.

Şimdi HA çözümü için Always On AG(Availability Group) kurulumuna başlayalım.

Öncelikle sağlamamız gerekenleri aşağıda listeledim:

• Aynı windows cluster’a dahil 2 sunucunuzun olması gerekiyor. Sistem grubunuzdan isteyebilir ya da kendiniz kurabilirsiniz.
• Bu 2 sunucu üzerinde de SQL Server’ı stand-alone olarak kurmanız gerekiyor. “SQL Server Kurulumu” isimli makalemde detay bilgi bulabilirsiniz.
• Bu 2 sunucu üzerinde kurmuş olduğunuz stand-alone instance’ların service account’larını aynı domain kullanıcısına set edin. Örneğin [domainim\userım](“SQL Server Configuration Manager ayarları” isimli makalemi okuyabilirsiniz.)
• Bu 2 sunucu üzerinde best practice olarak aynı boyutta ve aynı isimde drive’lar olmalı. Drive’ların içinde aynı pathler olmalı. Örneğin 1.sunucuda M drive’ı/disk’i varsa 2.sunucuda da aynı boyutta M drive’ı olmalı. 1.Sunucuda M Drive’ının altında Data isminde klasör varsa 2.sunucuda da aynı klasör olmalı. 
• Bu 2 sunucuda kurulmuş olan Windows Cluster Account’a(Windows Cluster’ın ismi) bu 2 sunucunun Active Directory’de bulunduğu OU(Organization Unit)’da Create Computer Object yetkisinin verilmesi gerekiyor. Kurumunuzdaki Active Directory uzmanı ile konuşup SQL Server Sunucularınız için bir OU oluşturmanızı tavsiye ederim. OU oluşturduktan sonra bu OU’ya uygulanacak policy’leri de belirlemelisiniz.

Bu yetkiyi vermezseniz listener oluştururken aşağıdaki gibi bir hata alırsınız.

The WSFC cluster could not bring the Network Name resource with DNS name ‘testAG’ online. The DNS name may have been taken or have a conflict with existing name services, or the WSFC cluster service may not be running or may be inaccessible. Use a different DNS name to resolve name conflicts, or check the WSFC cluster log for more information.

The attempt to create the network name and IP address for the listener failed. The WSFC service may not be running or may be inaccessible in its current state, or the values provided for the network name and IP address may be incorrect. Check the state of the WSFC cluster and validate the network name and IP address with the network administrator. (Microsoft SQL Server, Error: 19471)

Policylerle ilgili aşağıdaki makalelerimi okumanızı tavsiye ederim.

“SQL Server Kullanıcı Locklama Politikası“,

“secpol.msc(Security Policy SQL Server Ayarları)“,

“SQL Server Parola Politikası“,

“Login oluşturmak ve yetkilendirmek“

• AG’ye alınacak veritabanlarının full recovery model’de olması gerekiyor.
• Veritabanı full backup’ının alınması gerekiyor.(Full Recovery Model’e çektikten sonra bir kere full backup aldıysanız gerek yok)

Çorba tarifinden önce malzeme listesi gibi oldu ama idare edin. 🙂

2 sunucu üzerinde de SQL Server kurulumunu yaptıktan sonra ve yukarda belirttiğim hazırlıklarımızı tamamladıktan sonra AG oluşturma işlemine geçebiliriz.

Öncelikle iki instance üzerindede Always ON özelliğini aktif etmemiz gerekir. Aktif etmezseniz aşağıdaki gibi bir hata alırsınız.

The AlwaysOn feature must be enabled for the server instance ” before you can create an availability group on this instance..

Always On’u enable etmek için SQL Server Configuration Manager’ı Run As Administrator ile açıyoruz. SQL Server Services kısmında instance’ımaza sağ tıklayarak properties diyoruz.

Açılan sekmede AlwaysOn High Availability kısmına gelip Enable AlwaysOn Availability Groups’u tıklayıp ok diyerek bu instance üzerinde Always On’u aktif hale getiriyoruz. Bu işlemi iki sunucuda da Always On yapacağımız instance için gerçekleştirmemiz gerekiyor. Bu işlem servis restart’ı gerektirecektir. Kontrollü olarak sql server servislerinizi restart edebilirsiniz.

Always On’u iki sunucu üzerindeki instance’da aktif hale getirdikten sonra aşağıdaki gibi SSMS üzerinden AlwaysOn High Availability kısmından New Availability Wizard’a tıklıyoruz.

Gelen ekranda AG’ye bir isim vermemiz gerekiyor. Ben IlkAG ismini verdim. Next diyerek ilerliyoruz.

Gelen ekranda oluşturacağımız AG’ye dahil edeceğimiz veritabanları seçiyoruz. AG’ye almaya uygun veritabanlarının Status’u Meets prerequisities şeklinde gelir.  TestDB’yi seçerek ilerliyoruz.

Bir sonraki ekranda Replicas kısmında add diyerek diğer sunucuda Always On yapacağımız secondary instance’a bağlanıyoruz. Instance isimlerinin aynı olmasına dikkat edin. Örneğin sunucu1\Instance1 primary sunucunuz olacaksa, secondary sunucunuzdaki instance sunucu2\Instance1 olsun. Yani iki sunucudaki named instance’ın adı da bu örnekte Instance1.

Bağlantı tamamlandıktan sonra aşağıdaki gibi bir ekranın karşınıza çıkması gerekir.

Biz kuracağımız AG’yi senkron ve otomatik failover olabilecek şekilde set etmek istediğimiz için aşağıdaki şekilde gerekli alanları işaretliyoruz.

Readable Seconday’yi şimdilik No olarak bırakıyoruz. Always On’da secondary veritabanından okuma yapabilmek için

“Always On Secondary Sunucudan Read Yapmak” isimli makalemi okuyabilirsiniz.

Replicas sekmesinde belirttiğimiz işlemleri yaptıktan sonra Endpoints sekmesine geçiyoruz ve karşımıza aşağıdaki gibi bir ekran geliyor.

Aynı sunucuda birden fazla instance kullanıyorsanız her instance için değişik bir endpoint portu kullanmanız gerekecektir. Default endpoint portu 5022 ‘dir. Örneğin 3 instance’ınız var. İlk instance için ag oluştururken yukardaki ekranda default olarak 5022 portu gelir. İkinci instance’ınız için bir ag oluşturacağınız zaman Enpoint URL kısmından portu değiştirmelisiniz. İkinci instance için 5023, üçüncü instance için 5024 portunu kullanabilirsiniz. Biz bu instance için daha önceki oluşturduğumuz ag’de 5023 portunu kullanmıştık. Aynı instance üzerinde ikinci bir ag oluşturduğumuz için default olarak 5023 geldi.

Bir değişiklik yapmadan Backup Preferences sekmesine geçiyoruz ve karşımıza aşağıdaki gibi bir ekran geliyor. Bu ekranda Backupları almak için tercih edilen instance’ı soruyor. İçlerinden birini seçmelisiniz.

Ben  sadece primary’i seçerek başka değişiklik yapmadan Listener sekmesine geçiyorum.

Listener Nedir? 2 sunucumuz var ve veritabanı o anda hangi sunucuda aktif çalışıyor olursa olsun, uygulama tek bir IP üzerinden aktif olan sunucudaki veritabanına(primary veritabanı) gider. Bunu sağlayan listener’dır. Listener’ın sanal bir ismi ve sanal bir IP’si olur. Uygulama, Always On çalışan 2 sunucunun fiziksel isimlerini ve fiziksel IP’lerini bilmez. Listener ekranı açıldığında aşağıdaki gibi Listener DNS Name’ine oluşacak AG’nin sanal sunucu ismini veriyorum. Port kısmındanda uygulamanın bu AG’deki veritabanlarına bağlanacağı port bilgisini veriyorum. Network Mode kısmından da Static IP’yi seçerek alt taraftan Add diyorum ve sanal IP’mi ekliyorum. Uygumacılar veritabanı IP’si olarak bu IP’yi bilecekler.

Verebileceğiniz IP’yi network biriminize sorabilirsiniz. Başka birinin kullandığı IP’yi verirseniz sıkıntı yaşarsınız.

Next diyerek ilerliyorum. Bir sonraki ekranda bizden secondary veritabanı ile senkronizasyonun ilk tanımlarken nasıl yapılacağını soruyor.

Full seçersek, seçtiğimiz her veritabanının full backup’ını ve log backup’ını otomatik olarak alıp secondary sunucuya kendisi aktarır ve bu işlem için iki instance’ın sql server servis hesaplarının okuma ve yazma yetkisi olan bir paylaşım/share ister. Share tanımlamak için “Paylaşım Tanımlamak ve Tanımladığımız Paylaşımı SQL Server’ın olduğu sunucuya Map Etmek” isimli makalemden faydalanabilirsiniz. Yalnız tanımladığınız share’in olduğu diskte seçtiğiniz veritabanlarının tamamının full backup’ının ve log backup’ının sığacağı kadar yer olmalıdır.

Join only seçersek, seçtiğimiz her veritabanının full backup’ını ve log backup’ını manual olarak alıp manual olarak secondary sunucuya bu adımı geçmeden önce aktarmamız gerekir.

Skip initial data synchronization’ı seçersek yine her veritabanının full backup’ını ve log backup’ını manual olarak alıp manual olarak secondary sunucuya aktarmamız gerekir ama bu işlemi daha sonra yaparız. Ben bu seçeneği bugüne kadar hiç kullanmadım. Full seçerek bir paylaşım veriyoruz ve next diyoruz.

Bir sonraki ekranda gerekli kontrolleri yapıyor. Eğer bir sorun çıkarsa sorunu çözüp Re-run validation diyebilirsiniz. Sorunu çözmek için Back tuşuna basarak geri gidebilir ve yanlış yaptığınız bir ayarı düzeltip tekrar next diyerek ilerleyebilirsiniz. Bizim kurulumumuzda bir sorun çıkmadı.

Next diyerek ilerliyoruz ve en son finish diyoruz. Benim örneğimde aşağıdaki gibi listener haricinde her şeyi doğru oluşturdu.

Yukardaki Create Availability Group Listener ‘testAG’ yazısının yanındaki Error’a tıkladığımızda hatanın detayını aşağıdaki gibi görebiliriz.

Ben genelde AG kurarken AG’yi kurduğum instance hangi port’u kullanıyorsa AG’ye o portu veriyorum. Burda değişik bir port verirsem nasıl bir hata ile karşılaşacağımızı görmeniz için başka bir instance’ın kullandığı portu girdim.

Creating availability group listener resulted in an error.

Listener’ı oluşturamamasına rağmen AG ‘yi oluşturdu. IlkAG’nin altına gelip Availability Group Listeners’dan Add Listener diyerek yukarda anlattığımız gibi tanımlayabiliriz.

Bizim tanımladığımız bu örnekte uygulamacılara vereceğiniz erişim bilgileri(connection string’lerine yazacakları veritabanı erişim bilgisi) aşağıdaki gibidir:

TestAG,1435 ya da listenertanımlarkenverdiğinizIP,1435

SSMS üzerinden de bu şekilde bağlanabilirsiniz. Aşağıda bağlandığımızda AG’ye aldığımız veritabanının sonunda (Synchronized) yazdığını görüyorsunuz.

Always On ile ilgili diğer makalelerim aşağıdaki gibidir. Ayrıca sitemizin arama kısmına öğrenmek istediğinizi konuları yazarak da ihtiyacınız olan makalelere ulaşabilirsiniz. 

“AG(Availability Group) ‘a dahil olan veritabanlarının backup’ını almak“,

“Always On Alert Sistemi“,

“SQL Server Always On Mimarisinde Secondary Sunucuda Veritabanının Ne kadar geriden geldiğini bulmak“,

“SQL Server Availability Group Failover İşlemi“,

“SQL Server Availability Group Veritabanları Senkronizasyon Durumları“,

“Registered Server ile Birden Fazla Instance Üzerinde Aynı Script’i Çalıştırmak“