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.

Not: Sadece replica eklenmek isteniyorsa wizard ekranından mümkün değildir. Bunun için New Availability Group.. tek replica olarak AG yapımızı oluşturabiliriz.

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

Normal şartlarda SQL Server AG, bir “failover” (diğer sunucuya geçiş) kararı verirken örnek (instance) sağlığına bakar. Yani SQL Server servisi çalışıyorsa, her şey yolunda kabul edilir. Ancak bazen servis çalışsa bile veritabanı bozulabilir veya erişilemez hale gelebilir.

• Neden Önemli: Veritabanı bazlı bir sorun yaşandığında sistemin “donup kalmasını” engeller ve iş sürekliliğini sağlar.
• Ne İşe Yarar: Bu kutucuğu işaretlediğinizde, AG artık sadece servisi değil, veritabanının kendi durumunu da izler. Eğer veritabanı “suspect” moduna düşerse veya bir I/O hatası nedeniyle erişilemez olursa, AG bunu fark eder ve otomatik olarak sağlam olan diğer node’a (senin senaryonda henüz yükseltmediğin 2017 node’una veya 2019 node’una) geçiş başlatır.

Per Database DTC Support (Distributed Transaction Coordinator)

DTC, birden fazla veritabanı veya farklı sunucular arasında gerçekleşen işlemleri (transaction) yöneten bir Windows servisidir.

• Ne İşe Yarar: Eskiden SQL Server AG yapıları, “Distributed Transactions” dediğimiz (örneğin iki farklı veritabanına aynı anda veri yazan ve biri hata verirse ikisini de geri alan işlemler) yapıları tam olarak desteklemiyordu. Bu seçenek, her veritabanının kendi DTC bağlamında çalışmasına izin verir.
• Eğer uygulamanız BEGIN DISTRIBUTED TRANSACTION komutunu kullanıyorsa veya mikroservis mimarisiyle farklı DB’ler arasında veri tutarlılığı sağlıyorsa, bu seçeneği işaretlemeniz gerekir.

Bu özellik SQL Server 2016 SP2 ve sonrasında geldiği için, 2017’den 2019’a geçiş sürecinde bu özelliğin aktif olması her iki tarafta da desteklendiği anlamına gelir.

DTC, şu senaryolarda devreye girer:

• Senaryo A: Aynı SQL Instance içindeki Veritabanı_1 ve Veritabanı_2 arasında veri transferi yapıyorsun ve ikisinin de aynı anda “commit” (onaylanması) veya hata anında ikisinin birden “rollback” (iptal edilmesi) gerekiyor.
• Senaryo B: Sunucu_A üzerindeki bir tabloyu güncellerken, eş zamanlı olarak Sunucu_B (Linked Server) üzerindeki bir tabloyu da güncelliyorsun.

Özetle: Bu ayar, “veritabanının nerede çalıştığı” ile değil, “veritabanının dış dünyayla (diğer DB’ler veya sunucularla) yaptığı atomik işlemlerin güvenliği” ile ilgilidir.

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.

Always On, veriyi ikincil sunuculara (Secondary Replicas) göndermek için Transaction Log kayıtlarını kullanır.

• Simple Recovery Model‘de, bir işlem (transaction) tamamlandığında ve bir “checkpoint” oluştuğunda, log kayıtları otomatik olarak silinir (truncate edilir). Bu, geçmişe dönük log zincirinin kırılması anlamına gelir.
• Full Recovery Model‘de ise log kayıtları, siz bir Log Backup alana kadar saklanır. Always On bu kesintisiz log zincirine ihtiyaç duyar; çünkü ikincil sunucunun, birincil sunucuda gerçekleşen her bir değişikliği sırasıyla ve eksiksiz olarak alması gerekir.

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.

SQL Server’da bir veritabanını Simple modelden Full modele aldığınızda, sistem teknik olarak hala “Pseudo-Simple” (Yalancı-Basit) durumunda bekler. Yani siz sadece bir ayarı değiştirmiş olursunuz, ancak veritabanı henüz gerçek bir Full Recovery gibi davranmaya başlamaz.

İşte bu yüzden SQL Server, bir veritabanını Always On grubuna eklemeden önce mutlaka bir Full Backup (ve ardından genellikle bir Log Backup) almanızı şart koşar. Bunun temel nedenleri şunlardır:

Full Recovery modelinin en büyük özelliği, işlemleri (transactions) log dosyasında biriktirmesidir. Ancak SQL Server, nereye kadar biriktireceğini ve bu zincirin nereden başlayacağını bilmek ister. SQL Server, log dosyasını hala “Simple” modeldeymiş gibi otomatik olarak temizlemeye devam eder. SQL Server bir “Checkpoint” oluşturur ve “Tamam, artık bir geri dönüş noktamız var, bundan sonraki her hareketi log zincirine eklemeye başlıyorum” der.

Always On yapısında veritabanı ikincil sunucuya (Secondary) gönderilirken, iki sunucunun da aynı başlangıç noktasına sahip olması gerekir. İkincil sunucuya veritabanını geri yüklerken (restore), SQL Server “Ben bu veritabanının hangi yedeğine dayalıyım?” sorusunun cevabını arar. Eğer bir yedek (backup) yoksa, ikincil sunucu birincil sunucudan gelen log kayıtlarını (redo log) hangi verinin üzerine yazacağını bilemez.

Full Backup, veritabanının o anki durumunu bir “fotoğraf” gibi çeker ve bir LSN numarası atar. Always On mekanizması, ikincil sunucuya veriyi gönderirken şunu kontrol eder: “İkincil sunucudaki en son LSN, birincil sunucudaki Full Backup LSN’i ile uyumlu mu?” Eğer arada kopuk bir zincir (broken chain) varsa, veriler asla senkronize olmaz.

Özetle

Eğer sadece ayarı “Full” yapıp yedek almazsanız;

1. Log dosyası büyümez, kendi kendini silmeye devam eder.
2. Always On sihirbazı “Status: Full backup is required” uyarısı verir.
3. İkincil sunucu (Secondary Replica) veriyi kabul edecek bir “temel” (base) bulamaz.

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.

Replica eklemeden önce aşağıdaki resimde çerçeve içerisine alınmış bölümün ne işe yaradığına değinelim.

Bir ana sunucuda (Primary) bir işlem (transaction) yapıldığında, bu işlemin “tamamlandı” sayılabilmesi için kaç tane ikincil sunucunun (Secondary) bu veriyi başarıyla aldığını ve kendi günlüğüne (log) yazdığını belirler.

• Değer “0” olduğunda: Ana sunucu, ikincil sunucuların veriyi alıp almadığını beklemez. Kendi üzerine yazınca işlemi onaylar (commit eder). Bu en yüksek performanslı ama veri kaybı riski olan yöntemdir.
• Değer “1” veya daha fazla olduğunda: Ana sunucu, işlemi onaylamadan önce en az belirlediğiniz sayıdaki ikincil sunucudan “Veriyi aldım ve kaydettim” onayı gelene kadar bekler.

Özetle: Bu kutucuğa girdiğiniz sayı, “Verim güvende olsun diye en az kaç sunucuya kopyalanmadan işlem bitmesin?” sorusunun cevabıdır. Normal şartlarda bu ayarın tam anlamıyla çalışması için replikaların Synchronous commit (Senkron) modunda olması gerekir. Asenkron modda bu değer genellikle 0 bırakılır çünkü asenkron yapı doğası gereği onay beklemez.

Kaldığımız yerden devam edecek olursak Add Replica diyerek secondary sunucum olan S2 sunucusunu seçiyorum. Aynı instance ismi olunmasına dikkat edilmeli. Disaster recovery yöntemindede bu ekrana gelinir 3. Node’muz 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. Mevcut database’ler restoring moduna geçmektedir.

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. Yada belirli komutlarla failover işleminin tetiklenmesi gerekmektedir.

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.

SQL Server Always On Availability Groups mimarisinde Endpoint (Uç Nokta), veritabanı replikasyonu ve sunucular arası haberleşme için kullanılan “kapı” görevini görür. SQL Server varsayılan olarak 0.0.0.0 (tüm IP’ler) üzerinden dinleme yapar. Eğer sunucunuzda birden fazla ağ kartı (NIC) varsa ve replikasyon trafiğini özel bir “Heartbeat” veya “Replication” kablosuna/ağına yönlendirmek istiyorsanız, bunu sihirbaz üzerinden değil, T-SQL ile yapmalısınız.

Endpoint oluştururken veya düzenlerken LISTENER_IP parametresini kullanabilirsiniz:

ALTER ENDPOINT [Hadr_endpoint] 
STATE = STARTED 
AS TCP (LISTENER_PORT = 5022, LISTENER_IP = (192.168.10.5)) -- Buraya ilgili Ethernet'in IP'sini yazmalısınız.

Eğer IP belirtmezseniz (ALL), SQL Server sunucudaki tüm aktif ağ kartlarından gelen 5022 trafiğini kabul eder.

Normalde LISTENER_IP = ALL (varsayılan) derseniz, SQL Server sunucu üzerindeki tüm aktif IP’lerden 5022 portuna gelen istekleri kabul eder. Ancak siz 192.168.10.5 gibi spesifik bir IP tanımladığınızda:

• Gelen Trafik (Inbound): Sadece bu IP’ye gelen 5022 paketlerini dinler.
• Giden Trafik (Outbound): Diğer replikaya log gönderirken, işletim sistemi yönlendirme tablosuna (routing table) bakar ve bu IP bloğuna en yakın olan kartı seçer.

Veri senkronizasyonu (Log hardening) için sadece bu port ve IP kullanılır. Ancak sunucuların genel sağlığı (Quorum/Heartbeat) için arka planda Windows Cluster servisinin kendi trafiği devam eder.

Dikkat Etmeniz Gereken Kritik Noktalar

• Endpoint URL Güncellemesi: Eğer IP bazlı bir kısıtlamaya gittiyseniz, Availability Group sihirbazındaki veya özelliklerindeki Endpoint URL kısmının bu IP ile çözümlendiğinden emin olmalısınız. Eğer DNS kullanıyorsanız, o DNS kaydının 192.168.10.5 adresine gittiğini teyit edin.
• Firewall Kuralları: Sunucu üzerindeki Windows Firewall veya donanımsal firewall cihazlarında, sadece ana ağdaki değil, bu özel “Replikasyon Etherneti” üzerindeki 5022 portuna da izin vermelisiniz.
• Yedeklilik (Redundancy): Eğer bu Ethernet kartı veya kablosu arızalanırsa, SQL Server diğer kartları (Public LAN gibi) otomatik olarak kullanamaz. Çünkü siz onu bu IP’ye sabitlediniz. Bu durumda Availability Group “Not Synchronizing” durumuna düşer.

Her sunucunun endpoint konfigürasyonu kendi içinde bağımsızdır.

• Primary (S1): Port 5023
• Secondary (S2): Port 5022 olarak ayarlanabilir. Önemli olan, Endpoint URL kısmında karşı tarafın hangi portu dinlediğini doğru yazmaktır. Ancak yönetimsel kolaylık ve kafa karışıklığını önlemek adına sektör standardı olarak tüm replikalarda aynı port (genelde 5022) kullanılır.

Replikasyon (veri senkronizasyonu) için sadece bu port kullanılır. Ancak bir AG yapısının sağlıklı çalışması için arka planda başka portlar da gereklidir.

• Windows Server Failover Cluster (WSFC): UDP 3343, TCP 135 ve RPC portları (sunucuların birbirinin ayakta olup olmadığını anlaması için).
• SQL Portu (1433): Uygulamaların veritabanına bağlanması için.
• Endpoint Portu (5022): Sadece replikalar arası LDF (log) trafiği için.

Encrypt Data: İki sunucu arasında gidip gelen log paketlerinin ağ üzerinde şifrelenip şifrelenmeyeceğini belirler.

• Faydaları: Ağ trafiği (sniffer vb. araçlarla) dinlense bile veriler okunamaz. Güvenlik ve uyumluluk (KVKK, GDPR vb.) açısından seçili kalması önerilir.
• Zararları: Veri paketlenirken ve açılırken çok küçük bir miktar CPU yükü getirir. Ancak modern işlemcilerde bu fark hissedilmeyecek kadar azdır.

Eğer bu seçenek seçiliyse, iki sunucunun da şifreleme algoritması (AES vb.) konusunda anlaşabilmesi gerekir. Genellikle sertifika tabanlı veya Windows Authentication (Kerberos/NTLM) üzerinden otomatik halledilir.

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.

Listener, aslında cluster servisinin yönettiği sanal bir IP adresi ve DNS ismidir.

• Yönlendirme: İstemci, ListenerName üzerinden bağlanmaya çalıştığında, Cluster servisi bu IP’nin o an hangi düğümde (node) “Online” olduğunu kontrol eder.
• Bağlantı İsteği: Trafik, aktif olan sunucunun IP adresine ve SQL portuna (genelde 1433) şeffaf bir şekilde yönlendirilir.
• Failover Durumu: Eğer ana sunucu çökerse, Cluster servisi Listener IP’sini ikincil sunucuya taşır. İstemci bağlantısı kısa bir süreliğine kopar ancak aynı isimle (Listener ismiyle) tekrar bağlandığında yeni aktif sunucuya ulaşır.

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.

Not: İlerleyen sql server sürümlerinde Disaster Recovery sunucusu Availability group altına eklenecekse farklı subnette olan sunucu ile aynı networkte olan ikinci bir listener üzerinden eklenmesi gerekmektedir. Failover cluster ekranında ilgili AG rolünün alt kısmında Network bölümünde ikinci ip adresi görünür. İkinci listener’ın offline modunda olduğu görülmektedir. Ayrıca herhangi bir FK sunucusuna geçiş işleminde Failover cluster ekranında Failover cluster yapısını seçtikten sonra ikinci bir ip adresinin eklenmesi gerekmektedir.

• Farklı bir subnetten Availability group altına ikinci bir listener eklenmesinden bahsetmiştik. Bunun failover cluster adımını da failover cluster bölümüne girdikten sonra alt bölümde Server Name kısmında ilgili cluster ismini seçip properties dedikten sonra eklenmesi gerekmektedir.

Add denilip farklı subnettten tahsis edilmiş olan ip adresinin eklenmesi gerekmektedir. Dependencies kısmında eklenen bu ip adreslerimizi görebiliriz. Dependencies kısmında eklenilen ip adresleri bağımlılık olarak görülmektedir.

İlgili işlemi gerçekleştirdikten sonra bu cluster altında bulunan tüm node’ların Restart edilmesi gerekmektedir.

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

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.

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; Listener sayesinde kullanıcı Always On yapısının arkasındaki fiziksel sunucu düğümlerinden bağımsız hale gelir. Kullanıcı sadece Listener ismi ve port numarası ile bağlantı sağlar; o anda hangi sunucu Primary rolündeyse trafik otomatik olarak ona yönlendirilir. Windows Server Failover Cluster (WSFC), Listener için tanımlanan sanal IP’yi her zaman aktif olan sunucu üzerinde tutar ve bir failover durumunda bu IP’yi saniyeler içinde yeni Primary sunucuya taşıyarak sürekliliği sağlar.

İşte SQL Server dünyasında:

• Listener: Şirketin ana telefon numarasıdır.
• Sunucular (Node1, Node2): Arka plandaki operatörlerdir.
• Yönlendirme: Cluster yapısı bakıyor: Santral seni her zaman “Asıl Patron”a (Primary) bağlar
• Primary Sunucu: O an telefona bakmaya yetkili olan asıl operatördür.

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ı

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