MSSQL SERVER ALWAYS_ON KURULUMU-3

Bu makalede AlwaysOn kurulumu makalemizin üçüncü kısmını görmüş olacağız. Bu makalede AlwaysOn kurulumunu sıfırdan ele almış olacağız. Bu makalemde Microsoft sql server teknolojisinden en gelişmişi olan AlwaysOn kurulumundan bahsedeceğim.

AlwaysOn teknolojisi Mirroring Teknolojisinin üzerine kurulmuştur. Mirroring’in geliştirişmiş halidir diyebiliriz AlwaysOn kurabilmek için aynı windows cluster içerisinde olması zorunlu olan en az 2 sunucuya ihtiyaç duyulur. 

AlwaysOn’da birden fazla veritabanı grubu oluşturulabiliyor. Bu gruba AG(Availability Group) deniyor. Failover AG bazında gerçekleşiyor. Failover cluster olmadan da alwayson yapısı kurulabilir. Bu durumda manuel failover işlemi gerçekleşir. Listener ip manuel bir şekilde değiştirme yapılır.

AlwaysOn kurulumu için bulunmuş olduğumuz instance’da Always On High Availability yerine tıklıyoruz. Ben AlwaysOn kurulumunu S1\TEST instance üzerinde yapıyorum.

Resimde AlwaysOn High Availability olan yere tıkladıktan sonra aşağıdaki hata mesajıyla karşılaştım.

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

Bu hata mesajı sql server üzerinde AlwaysOn özelliğinin aktif edilmesi gerektiğini söylüyor. Bu özelliği aktif etmek için bulunduğumuz sunucuda Windows arama kısmına Sql Server 2017 Configuration Manager yazıyorum. AlwaysOn aktif etme işlemi iki sunucumdada aynı anda yapılmaktadır.

SQL Server Services kısmında SQL Server(TEST) kısmına sağ tıklayıp properties kısmına giriyoruz.

Yeni gelen ekranda AlwaysOn High Availability sekmesinde Enable AlwaysOn Availability Groups ikonunu işaretlememiz gerekiyor. Burada başka önemli olan kısım Windows failover cluster name kısmında bizim kurmuş olduğumuz cluster gözükmesi gerekmektedir.

Not: Non Cluster AG kuracağımız zamanda bu kısmın aktif edilmesi gerekmektedir. Non Cluster AG kurulumundada cluster isminin seçilirken gözükmesi bir sorun teşkil etmemektedir. Başka bir makalede Non Cluster AG yapısını ele almış olacağım.

Bu ayarlamaları yaptıktan sonra apply deyip çıkıyoruz. Bizden servisi restart yapmam gerektiğini söylüyor.

Bunun için sql servis’i restart yapıyorum.

NOT: Sql configuration  manager bölümünde network alanında named ve tcp yapılarını enable edilmesi gerekmektedir.

S1 sunucusunda bu işlemlerimi yaptıktan sonra aynı AlwaysOn aktifleşme işlemlerini S2 sunucusunda da yapıyorum. S2 sunucumda aynı ayarlamaları yaptıktan sonra AlwaysOn kurulumu yapacağım  S1 sunucuma geliyorum.

Resimdede görüldüğü gibi AlwaysOn bölümünün açıldığını görmüş oluyoruz. Artık AlwaysOn kurulumuna başlayabiliriz. AlwaysOn High Availability sekmesine sağ tıklayıp New Availability Group Wizard’a tıklıyorum.

Gelen ekranda Next deyip ilerliyorum.

Gelen ekranda Availability group name kısmında AG’ye bir isim veriyorum. Cluster type kısmında hangi cluster yapısını kullanıyorsak onu seçiyoruz. Ben Windows Server Failover Cluster yapısını kullandığım için cluster type’ı onu seçiyorum.

Database Level Health Detection (Veritabanı Sağlık Algılama):Veritabanı seviyesinde sağlık kontrolü yapar. Normalde Availability Group sağlık kontrolü (failover durumu), sunucu seviyesinde yapılır. Ancak bu seçenek aktif edildiğinde, sadece sunucu değil, veritabanı içindeki sağlık problemleri de dikkate alınarak failover tetiklenebilir. Örneğin: Disk hataları, Transaction log dolması, Veritabanı erişim hataları gibi durumlar failover’a neden olabilir. Avantajı daha hassas ve doğru failover kararları verilir.

Distributed Transaction Coordinator (DTC), MSDTC servisini kullanarak birden fazla veritabanına yayılmış işlemleri yönetir. Eğer işaretlenirse, her veritabanı için ayrı DTC desteği sağlanır. Özellikle çoklu veritabanı transaction’ları kullanan uygulamalarda faydalıdır. SQL Server Always On gibi yüksek erişilebilirlik yapılarında, birden fazla veritabanı veya sunucu arasında işlemlerin tutarlı ve güvenli bir şekilde yönetilmesini sağlar. DTC, dağıtık işlemlerin koordinasyonunu üstlenerek, veritabanlarındaki değişikliklerin tutarlı ve güvenilir bir şekilde uygulanmasına olanak tanır. Bu, özellikle dağıtık veritabanı senaryolarında, verilerin tutarsızlık göstermesini engeller ve yüksek erişilebilirlik sağlayan yapıları daha sağlam hale getirir. Örneğin: Bir transaction, hem Veritabanı-1 hem Veritabanı-2 üzerinde çalışıyorsa, DTC devreye girer. Ancak: Always On kullanırken DTC desteklemeyen veritabanları varsa, bu ayar kapalı tutulmalı. Eğer işaretlenirse, DTC desteklemeyen veritabanlarında hata oluşabilir. Seçip seçmemek tercihinize bağlıdır.

Not: Failover cluster kurulduğunda sunucuları restart etmek gerekiyor. Non Cluster AG yapılacağı zaman aşağıdaki ekranda herhangi bir cluster mimarisi seçilmez.

Next deyip bir sonraki adıma geçiyorum.

Sql instance’ında kurulu olan  veritabanının geldiğini görmüş oluyoruz. Yukarıdaki resimde dikkat edersek bir sonraki adıma geçemediğimizi görmekteyiz. AdventureWorks2014 veritabanını AlwaysOn’a dahil edebilmem için recovery model’in full olması gerekiyor bunun için AlwaysOn yapısına alacağımız  veritabanının üzerine sağ tıklayıp properties>options kısmından recovery model’i full yapıyorum. Çünkü secondary sunucusu ldf dosyasını okuyarak kendini senkron eder. Çünkü sql serverda yapılan her işlem ldf dosyasına yazılır.

Bu işlemi yaptıktan sonra tekrar AlwaysOn kurulum ekranına geliyorum tekrar refresh yapıyorum.

Şimdi ise bu veritabanının backup’ının alınması gerektiğini söylüyor. Bunun için AdventureWorks2014 veritabanının backup’ını alıyorum. Bu işlem AlwaysOn yapısının kendini garanti altına almasından dolayıdır.

Backup’ı alıp tekrardan AlwaysOn kurulum ekranında refresh yaptığımda veritabanının AlwaysOn için gereksinimleri karşıladığını görüyoruz. Veritabanı dahil  ettikten sonra next deyip bir sonraki ekrana geçiyorum.

Bir sonraki ekranda primary ve secondary sunucularımı belirliyorum gerekli konfigürasyonunu yapıyorum.

Add Replica diyerek secondary sunucum olan S2 sunucusunu seçiyorum. Aynı instance ismi olunmasına dikkat edilmeli. Disaster recovery yönetemindede bu ekrana gelinir 3. Nodumuz eklenir.

Connect dedikten sonra  S2\TEST’i secondary olarak eklemiş oluyorum.

Not: Alwayson yapısında replicayı ag yapısından çıkarınca secondary sunucusunda AG yapımız silinmektedir. Kısacası replikanın çıkarılması Secondary sunucusunun silinmesini sağlıyor.

Readable Secondary makinam secondary’den okuna bilsinmi seçeneği karşımıza çıkıyor. Bazen raporlama işlemleri veya sürekli select sorgunun çekildiği işlemler için makinayı yormak istemeyiz. Bu seçenek no ise ikinci sunucuda veritabanını açamaz bile kullanıcı. Readable seçeneği secondary sunucusunda okunup okunmayacağını  yada kullanıcının secondary sunucusuna gidip databaseleri açıp içini görüp görmemesini belirliyoruz. Başka bir makalede Read-Only Routing işleminde bu konuyu ele almış olacağız.

Availability Mode kısmını senkron bir şekilde bir şekilde set edersek primary sunucusuna gelen istek secondary sunucusuna yazılmadan kullanıcıya işlem tamamlandı bilgisi iletilmeyecektir. Bu mode seçildiğinde Automatic Failover işleminin manuel veya otomatik  bir şekilde ayarlaması gerekmektedir. Sizin isteğinize veya ihtiyacınıza göre bir durum

Asenkron olarak seçilirse sistem siz failover modunu  otomatik bir şekilde yapsanız da  aşağıdaki resimde görüldüğü gibi hata mesajı  verecektir.

Çok yoğun transaction olan sistemlerde   asenkron olması tavsiye edilir. İki sunucuda da bu işlem yapılır. Çünkü güncel olan sunucu başka zamanda secondary olabilir.

Asenkron olarak ayarlandıktan sonra failover işleminin manuel yapılması gerekmekte buda herhangi bir sıkıntı durumunda veri merkezine gidip failover işlemini manuel yapmanıza sebep olur. Mode kısmı asenkron olarak seçilirse primary sunucusu elimizde donanım ve network yapısına göre senkron olma durumları değişmektedir. Secondary sunucunun geriden gelmesi milisaniye veya saniyeler türündedir.

Eğer aşağıdaki gibi otomatik failover işlemi seçilirse availability mode synchronous commit moduna geliyor. Veri kaybının olmaması için büyük sistemlerde manuel bir şekilde bırakılır herhangi bir failover anında sistem kendini ikinci sunucuya atıp ayağa kalkmaya çalışmasın diye  otomatik mode manuel’e alınması  durumlarında AG resolving moduna düşer bunun için ikinci makinada AG üzerine tıklayıp failover dememiz gerekiyor.

Herhangi bir failover anında system’in otomatik failover işlemini yapmasını istiyorsak yukarıda  İşaretli olan  seçeneği seçiyoruz. Availability mode kısmında primary ve secondary sunucularının verileri aktarırken senkron veya asenkron aktarılmasını belirliyoruz. Index rebuild işlemlerinde performans kaybı daha fazla olduğu için sıkıntı yaşayan sistemlerde Index Rebuild öncesi AG’yi asenkron moduna alınır. Otomatik failover işlemi veritabanında herhangi bir sorun anında veya transaction log dolması gibi sebeplerden dolayı geçmez sunucuda bulunan donanımsal bir hatadan dolayı failover işlemi gerçekleşmektedir.

Disaster Recovery durumunda mevcut olan cluster’ımıza yeni bir sunucu ekleyeceğimiz zaman bu sunucu secondary olarak kalır Automatic Failover kısmında herhangi bir şey seçilmez. Bu cluster’a eklenen yeni sunucuda availability mode kısmı asenkron olarak seçilir.

 Bu adımı geçtikten sonra endpoint kısmına geliyoruz.

Endpoints bölümünde ise port number veya endpoint ayarlamaları yapabiliriz. 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. Kısacası farklı bir instance altında AG oluşturacağınız zaman Endpoint 5023 olmaktadır.

Kurulu bir AG üzerine replica ekleneceği zaman endpoint’i farklı olabilir veya default ta kalabilir buna dikkat edilmesi lazım manuel bir şekilde düzeltmemize sql server izin veriyor.

Bu ekranda herhangi bir değişiklik yapmadan üst tarafta bulunan Backup Preferences bölümüne geçiyorum. Bu ekranda backup’ların nereden alınması gerektiğini soruyor. Primary kısmını seçiyorum. Bu seçim tüm backup’lar primary sunucusunda gerçekleşir. Diğer kısımlar sayfamızda AlwaysOn katagorisinde detaylı bir şekilde paylaşılmış olunacak. Bu makalede amacımız sadece always on kurulumunu gerçekleştirmek. Bu ayarlar S1\TEST replicasına bir veritabanı ekleneceği zamanki default ayarlar. Yani aşağıdaki kısımda AG oluştururken ne seçersek her veritabanı oluşumunda default olarak seçilen seçenek karşımıza gelir.

Primary seçip üst tarafta bulunan Listener kısmına geçiyorum.

Listener bölümünde kullanıcıların sql server’ a bağlanırken primary sunucusunun hangi sunucu olduğunu öğreneceği bir  listener oluşturmamız gerekecek son kullanıcılar veritabanı sunucularına bağlanırken bu listener’ı veya port numaralarını bilecek ve bağlanacak. Bu yüzden bir listener ismi port numarası ve add bölümünden bir kullanılmayan ip’ye ihtiyaç duyacağız. Kullanıcılar AlwaysOn altında çalışan sunucuların fiziksel isimlerini bilmez sadece listener ismine gelir bakar hangisi primary’se ona gider. Listener altında  Windows cluster objesine full yetki verilir. Bu işlem ilgili OU altında yapılır.

Not: Disaster recovery kuracaksak kurulu olan alanda ikinci bir listener ismi eklenmesi gerekmektedir. Herhangi bir sorun anında kullanıcılarımız Listener altında tanımlanan yeni listeler ile dns kaydı değiştirilerek listener objesinin sorunsuz bir şekilde sistem ayakta olmaya devam edecektir. ikinci listener eklenirse failover cluster ekranında ilgili AG altında ikinci verilen ip görülür. Bu ip disable modundadır. Ne zaman gerçek listener ip’si disable moduna düşerse ikinci ip aktif olmaktadır.

Listener ismi ve port numarası belirledik şimdi ise add bölümünden ip adresi belirlememiz gerekiyor.

Not: Disaster Recovery  yeni bir node eklediğinde AG altına listener ekranında sağ altta bulunan add kısmı aktif oluyor.

Sunucularımla aynı network bloğunda olması için kullanılmayan bir ip’nin belirtilmesi gerekiyor.

 AD sunucumda Listener Dns Manager bölümene eklenmiş durumda. İp yanlış oluşturmuş olabilirim.

Not: Mevcut Cluster yapımız kendi aralarında konuşur hangi sunucunun primary olduğunu regedit denilen bölüme kaydeder. Listener ise Regedit üzerinden hangi sunucunun primary olduğunu öğrenir.

Read-Only Routing bölümünde hangi sunucuda kullanıcıların okuma yapacağı veya rapor çekeceği sunucu belirlenir. İlgili Makaleyi okumak için linke tıklayınız.

Next deyip bir sonraki adıma geçilir. AdventureWorks2014 veritabanının  S2 sunucusuna nasıl aktarılacağını belirliyoruz. Bizim elimizde AdventureWorks2014 veritabanı küçük olduğu için Automatic seeding modu seçilir. Eğer database boyutumuz küçükse bu mode seçilir. Diğer kısımların ne iş yapacağı  uygulamalı bir şekilde başka bir makalenin konusu. TEKER TEKER DENİYECEĞİZ. Automatic seeding modu makalesine okumak için linke tıklayınız.

Next deyip bir sonraki adıma geçiyoruz. Always-on’un başarılı bir şekilde kurulduğunu görmüş oluyoruz.

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 deyip bir sonraki aşamaya geçiyoruz. Finish deyip Always On kurulumunu tamamlıyoruz. Sağ alt köşede Script diyerek te kodla işlemlerimizi tamamlayabiliriz.

Not: Sql Server instance ile listener port numarası farklı olabilir. Başka bir instance veya kullanılan portu girdiğimizde hata mesajıyla karşılaşacaktık.

Şimdi S1\TEST instance’ından Always On High Availability kısmını bakıyoruz.

S2\TEST instance’ında Always on High Availability kısmına bakalım.

S2\TEST instance’ındada AlwaysOn’un doğru bir şekilde yapılandırıldığını görmüş oluyoruz.

Yukarıdaki resimlerde AlwaysOn High Availability kısmından iki sunucu ve instance’ımda  konfigürasyonunu görebiliriz. Şunu da belirtmek gerekir ki yukarıda listener’ı tanımlarken listener sayesinde kullanıcı AlwaysOn arkasında hangi sunucu olduğunu bilmez demiştik. Kullanıcı listener ismi ve port numarası ile bağlanır hangi sunucu primary ise ona gider. Cluster kendi arasında konuşarak bir sanal ip üretir ve listener’a nereye gideceğini öğretir.

S1 sunucusu primary olduğunda listener’a bağlandığında aşağıdaki resim gibi olmaktadır. Diğer bağlanma şekilleri listener_ismi, listeler_port_numarası veya listener_ip,listener_port_numarası

Active directory üzerinden objemizin oluştuğunu görmüş oluyoruz.

Aynı durumu Dns Manager  üzerinde de görebiliriz.

Görmüş olduğumuz tüm bu bölümlerde AlwaysOn konfigürasyonunu yapmış bulunmaktayız. Bundan sonraki kurulum makalelerimizde daha detaylı bir şekilde tüm kurulum adımlarını  görmüş olacağız.

Oluşan  listener’a SQLCLS clusterımıza tam yetki verilir. Çünkü listener bu yapı sayesinde primary secondary sunucusunu öğrenmek isteyecektir.

Bu makalede sıfırdan AlwaysOn kurulumunu ele almıştık. Başka bir makalede görüşmek dileğiyle…

“Şüphesiz benim namazım, bütün ibâdetlerim, hayatım ve ölümüm, Âlemlerin Rabbi Allah içindir.” Enam-162