Perşembe , 14 Aralık 2017

SQL Server Always On Mimarisi

Kurumların başarısı verdikleri hizmetin ve sundukları verilerin kesintisiz olması ile doğru orantılıdır. Diğer bir değişle uygulamaların yüksek erişilebilir olması ve Disaster Recovery senaryolarıyla da sistemimizde oluşacak bir hata sonucu sistemin çalışmasının minimum seviyede aksamasının sağlanmasıdır. SQL Serverın 2012 öncesindeki sürümlerinde hem High Availability(Yüksek erişilebilirlik) hem de Disaster Recovery sağlamak için Failover Clustering, mirroring, log Shipping ve Replikasyon gibi teknolojiler kullanılabiliyordu. Her bir teknolojinin kendine has avantajlarının ve dezavantajlarının olması sebebiyle genelde HADR(High Availability ve Disaster Recovery) sağlamak adına bu teknolojiler beraber kullanılıyordu. Fakat SQL Server 2012 ile beraber tanıtılan Always On özelliği ile önceden birkaç teknolojiyi beraber kullanarak elde ettiğimiz HADR seviyesini artık sadece Always On kullanarak elde edebileceğiz.
Şimdi SQL Server 2012 öncesinde yüksek seviyede HADR sağlamak için beraber kullandığımız teknolojileri kısaca inceleyelim. Öncelikle hem otomatik Failover sağlayan hem de birden fazla Data Center’da verilerin tutulmasını sağlayan mimarimizi inceleyelim.

Always on 1

Yukarıdaki mimaride yüksek seviyede HADR sağlayabilmek için farklı iki lokasyonda bulunan Primary Data Center ile Secondary Data Center’daki SQL Serverlarımız öncelikle kendi içlerinde Failover Clustering kullanılarak ilgili Data Center içinde High Availability sağlanmıştır.  Daha sonra buradaki yapı başka bir lokasyona SQL Server Mirroring mimarisinin asenkron seçeneği ile başka bir lokasyondaki Data Center’a taşınarak da Disaster Recovery sağlanmıştır. Böylece iki farklı teknoloji kullanılarak yüksek seviyeli HADR mimarisini kurmuş olduk.

Yukarıdaki yapı her ne kadar yüksek seviyede HADR çözümü sunsa bile bazı dezavantajları mevcuttur. Örneğin Data Centerların içinde Otomatik Failover için kullanılan Failover cluster mimarisinin yüksek maliyeti ve daha da önemlisi üçüncü bir Data Center’ın Disaster Recovery için kullanılamamasıdır. Yani bu yapıda sadece iki Data Center arasında veri transferi yapabiliriz. Çünkü iki Data Center arasında veri transferi için kullandığımız Mirroring mimarisi sadece iki Server arasında gerçekleşmektedir.  Aslında bu yapının birçok dezavantajı var olan başka çözümlerin bir arada kullanılması ile çözülebilir. Örneğin aynı yapıyı Mirroring ve Log Shipping mimarilerini beraber kullanarak tasarlayalım.

Always on 2

Alternatif olarak kullanabileceğimiz yukarıdaki senaryoda bir önceki senaryonun dezavantajlarını gidermiş gibi görünüyoruz. Örneğin her bir Data Center içinde Failover Cluster yerine Mirroring mimarisinin kullanılmasıyla hem daha düşük maliyetli bir yapı sağlamış oluyoruz hem de Failover Clustering mimarisindeki az bir ihtimal olsa da SAN üzerinde disklerde oluşacak hataya karşı sistemi korumuş oluyoruz.  Fakat bildiğimiz gibi Mirroring mimarisinde otomatik Failover işlemini gerçekleştirmek için fazladan bir tane Witness Server kullanmak zorundayız.  Ayrıca yukarıda şematize ettiğimiz yapıda Data Center’lar arasında Log Shipping mimarisinin kullanarak aynı anda birden fazla Data Center’a verilerin transfer edilmesini sağlayabiliyoruz. Fakat bildiğimiz gibi Log Shipping mimarisinde Primary Server ile Secondary Server arasındaki veri transferi anlık olarak değil belli bir gecikme süresi ile sağlanmaktadır. Bu durum bize olası bir Disaster durumunda veri kaybına sebep olacaktır.

Microsoft SQL Server 2012 ile beraber sunmuş olduğu Always On özelliği ile hem bizi bu karmaşık senaryodan hem de bu senaryoların birçok dezavantajlarından kurtarmaktadır. Always On mimarisi AlwaysOn Availability Groups ve AlwaysOn Failover Cluster Instances adlı iki farklı özelliği bünyesinde bulundurarak kolay kurulup yönetilebilen yüksek seviyeli bir HADR çözümünü bize sunmaktadır. Kısaca özetlemek gerekirse AlwaysOn Availability Groups kullandığımız veritabanı ya da veritabanları için aynı anda Failover sağlayabiliyor. Ayrıca Bu Failover işlemini birden fazla hedef Servera gerçekleştirebilmekte olup en önemlisi de bu hedef Serverlarında aktif bir şekilde erişebilir olmasıdır. AlwaysOn Failover Cluster Instances ise bize SQL Serverın Instance bazında Failover olanağı sağlamaktadır. Ayrıca bu Failover işlemini yine birden fazla hedefe aynı gerçekleştirebilmektedir. Şimdi kurulum işlemine geçmeden bu iki özelliği yakından tanıyalım.

AlwaysOn Availability Groups

AlwaysOn Availability Groups Mirroring işlemine bir alternatif olarak gösterilebilir. Fakat AlwaysOn Availability Groups ile Mirroring ile yapamadığımız birden fazla Secondary Server kullanabilme ve kullanılan Secondary Serverların da aynı anda aktif olarak çalışma işlemlerini Mirroring ile yapamıyorduk. Gerçi Mirroring senaryolarında Secondary veritabanımızın Snapshotını alarak Read-Only olarak erişebiliyorduk. Fakat AlwaysOn Availability Groups teknolojisi ile artık böyle bir kullanıma gerek kalmıyor. Ayrıca AlwaysOn Availability Groups özelliği Mirroring işleminin avantajlarından olan hem otomatik hem de Manuel Failover yapısını desteklemektedir.

Şimdi AlwaysOn Availability Groups teknolojisi ile nasıl yüksek seviyeli HADR çözümü sağlayabileceğimize bakalım.

Always on 3

Yukarıdaki şekilde tasarlanmış bir mimari ile en yüksek seviyede HADR sağlayabiliriz. Öncelikle Replica1 kullandığımız ana SQL Server olup bu SQL Server birden fazla Secondary Server(Multiple Secondaries) özelliği ile senkron bir şekilde Replica2 ve Replica3 makinelerine veri transferini gerçekleştirmektedir. Bu şekilde veri transferinin amacı High Availabilty sağlamaktır. Aynı şekilde asenkron olarak yine farklı bir lokasyonda tutulan Replica4 adlı Servera da veriler transfer edilerek de Disaster Recovery sağlanması hedeflenmektedir. Ayrıca AlwaysOn Availability Groups teknolojisi ile kullanacağımız bir başka avantaj ise Replica3 ve Replica4 Serverlarının hem raporlama hem de düzenli yedekleme için kullanılması ile asıl makinemiz Replica1 üzerindeki yükü de azaltmasıdır.

AlwaysOn Availability Groups teknolojisi arka planda Windows Failover Clustering mimarisi ile beraber çalışmaktadır. Fakat SQL Server Failover Clustering yapısından farklı olarak hem Shared hem de lokal disklerle konfigure edilebilmektedir. Ayrıca SQL Server Failover Clustering yapısından farklı olarak hem senkron hem de asenkron veri transferine olanak sağlamaktadır. Bir başka avantajı ise herhangi bir backup dosyasına ihtiyaç duymadan otomatik Page Repair işlemini gerçekleştirebilmesidir.

AlwaysOn Availability Groups teknolojisi arka planda Windows Failover Clustering mimarisini kullandığı için mimarinin tasarımına başlamadan önce Windows Failover Clustering yapısını konfigure etmeliyiz. Bu konfigürasyonu tamamladıktan sonra SQL Server Management Stdio aracı ile AlwaysOn Availability Groups teknolojisi yapılandırmak gerekmektedir.

AlwaysOn Availability Groups teknolojisi için otomatik Failover işlemi Windows Server Failover Cluster (WSFC) tarafından sağlanmaktadır. Ayrıca AlwaysOn Availability Groups içinde yer alacak SQL Server Instance’larımız Failover olarak kurulmak zoruna değildir.

AlwaysOn Availability Groups içinde aktif olan(Primary) Server üzerinde gerçekleşen her transaction grup içindeki diğer Serverlara(Replicalar) da gönderilmektedir. Bu şekilde Primary Server ile Replicalar arasındaki transaction trafiği Mirroring mimarisindeki gibi Senkron ve Asenkron olmak üzere iki farklı şekilde yürütülebilmektedir. Senkron mimaride Primary Server üzerinde başlatılan bir transaction’ın başarılı sayılması için tüm replikalarda da başarılı bir şekilde transaction’ın tamamlanması gerekir. Bu şekilde senkron bir yapının kullanımı Primary server ve replikalar arasındaki veri bütünlüğü ve tutarlılığını sağlamayı garanti etse bile Primary server üzerinde gerçekleştirilen bir transaction’ın daha geç bitmesine sebep olur. Bir diğer kullanabileceğimiz yöntem olan Asenkron mimaride ise Primary Server üzerinde transaction bittiğinde replikalardan herhangi bir geri bildirim beklenmeden transaction başarılı sayılır. Bu mimaride Primary Server üzerindeki transactionlar erken tamamlanmasına rağmen Primary Server ile Replikalar arasındaki veri bütünlüğü garanti edilemez.

Availability Group Listener Kavramı

AlwaysOn Availability Groups içinde birden fazla SQL Server bulunmakta olup sadece aktif olan Serverın kullanıcı ile doğrudan etkileşimli olduğunu diğer replikaların sadece Failover durumunda Primary olarak görev yaptıklarını söylemiştik. Böyle bir durumda Clientların herhangi bir sorgu çalıştırırken ya da bir işlem yaparken AlwaysOn Availability Groups içinde hangi Serverın Primary olduğunu bilmeleri gerekmektedir. Aslında bu bilgi bir defaya mahsus Clientlara verilse bile Primary Serverın AlwaysOn Availability Groups içinde değişme olasılığı olduğu için her zaman aynı ip adresi ya da aynı bilgisayar adı bize Primary Servera erişmeyi garanti etmez. Bu nedenle böyle bir sorunu çözmek için SQL Server 2012 öncesinde Failover cluster mimarisinde kullandığımız Virtual Network Name yapısına benzeyen Availability Group Listener kavramı geliştirilmiştir. Böylece Client bilgisayarların AlwaysOn Availability Groups içinde hangi serverın Primary olduğunu bilmeden sadece verilen bir isimle veya ip adresi bilgisiyle Availability Group Listener’a erişmeleri sağlanır ve Availability Group Listener o an bağlanmak isteyen Clientı Primary Servera yönlendirir.

Availability Group Listener konfigure edilirken Network içinde kullanılmayan bir ip adresi, benzersiz bir isim ve bir port bilgisine ihtiyaç duyar. Bu şekilde Availability Group Listener gerekli olduğu durumlarda AlwaysOn Availability Gruplara erişerek o anki aktif olan Primary Servera yönlendirme yapabilmektedir.

Sistemimizde birden fazla AlwaysOn Availability Groups tanımlanabilmesine rağmen her AlwaysOn Availability Groups için sadece bir tane Availability Group Listener tanımlanabilmektedir. Eğer sistemimizde birden fazla AlwaysOn Availability Groups tanımlamışsak her biri içinde birer tane tane Availability Group Listener tanımlayabiliriz.

AlwaysOn Availability Groups Gereksinimleri

AlwaysOn Availability Groups kurulumuna geçmeden önce sistemimizin bazı gereksinimleri karşılıyor olması gerekmektedir.

  • AlwaysOn Availability Groups içindeki tüm Serverlar aynı domain içinde olmalıdırlar.
  • AlwaysOn Availability Groups içindeki tüm Serverlar Windows Server Failover Cluster yapısına eklenmelidir.
  • AlwaysOn Availability Groups içindeki tüm Serverlarda Always On özelliği aktif edilmelidir.
  • AlwaysOn Availability Groups içinde bulunacak tüm veritabanları Full Recovery modda olmalıdır.
  • Kurluma başlamadan Primary Server üzerindeki AlwaysOn Availability Groups içinde bulunacak veritabanlarının Full backupları alınarak Replikalar üzerinde Restore edilmelidir.
  • AlwaysOn Availability Groups içindeki herhangi bir Server Domain Controller olmamalı yani diğer bir değişle hiçbir Serverın üzerinde Active Directory Domain Services rolü bulunmamalıdır.

Yukarıdaki gereksinimleri sağladıktan sonra  bir sonraki makalede AlwaysOn Availability Groups kurulumuna geçebiliriz.

 

 

Hakkında ismailadar

7 yorum

  1. Celaleddin DEV

    güzel bir döükman olmuş teşekkürler…

  2. Merhaba
    ben kurulumlari gerceklestirdim eger transaction sayisi cok fazla bir yapiya sahipseniz ve raporlama sıkıntısı yasamaktaysaniz kesinlikle kullanmalisiniz….

  3. Hocam yazı için çok teşekkürler detaylı ve çok faydali bir çalışma oldu benim için.

  4. Merhaba İsmail Bey
    Disaster Recovery projemizde sıfır data kaybı garanti eden bir sistem kurmak istiyorum. Ancak;
    Syncronous mirror kurulumu transaction zamanını uzattığı için kullanamıyorum. Logshipping ve replikasyon data kaybına neden olabileceği için uygun değil. Always on mimarisi aslında mirror ve logshipping in beraber kullanımı olduğu için primary datacenterda transaction gecikmesine, secondary data centerda ise log aktarımı zamanı farkından dolayı data kaybına neden olacağı için uygun olmaığını düşünüyorum. Bunun haricinde 2008 r2 serverlarımız da mevcut.
    Always on hakkında yukarıda bahsettiğim çekincelerim sizce de doğru mu ? Secondary data center da 2008 r2 serverları da düşünerek sıfır data kaybı hedefi için neler yapılabilir ? Gerekirse tool öneriniz var mı ?
    Teşekkürler.

Cevapla

E-posta adresiniz yayınlanmayacak. Required fields are marked *

*


*

Şu HTML etiketlerini ve özelliklerini kullanabilirsiniz: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>