SQL Server 2011 CTP3 İle Yüksek Erişilebilirlik Çözümleri - ALWAYSON 1
SQL Server Denali CTP1 sürümüyle başlayan HADRON servis özelliği CTP3 sürümünün çıkması ile beraber “ALWAYSON” olarak devam ediyor, bu makale serisinde sizlere “ALWAYSON” servis özelliği ile gelen yeni yüksek erişilebilirlik özelliklerini , bu özelliklerin kullanılabileceği en uygun senaryoları paylaşıp örneklerle detaylandırıyor olacağım.
Bildiğiniz gibi “Database Mirroring” SQL Server 2005 SP1 ile hayata geçmiş bir yüksek erişilebilirlik özelliğidir, bu özellik basit bir anlatımla veritabanı işlem günlüklerinin (transaction logs) değişen kısımlarının ağ üzerinden başka bir sunucuya taşınarak , bu sunucuda eşlenik bir veritabanına işlenmesiyle tamamlanan bir süreci ifade ediyor ve bu süreç sonunda bir aynalanmış veritabanı oluşuyor. SQL Server Denali sürümündeki “Availability Group” kavramıda “Database Mirroring” teknolojisi üzerine geliştirilmiş bir özellik olarak karşımıza çıkıyor. Bu özellik sayesinde birden fazla veritabanlarını gruplayarak aynalayabilir, bir veritabanı hizmet veremediği için ikincil sunucuya taşındığı zaman grubundaki tüm veritabanlarının taşınmasını sağlayabilirsiniz, bir diğer büyük özellik ise artık ikincil sunucudaki veritabanlarının okunabilirlik durumunu “Availability Group” kurulumunda belirleyebiliyoruz. Bu özelliğe ileride örneklerle olarak değineceğiz.
Bildiğiniz gibi “Database Mirroring” yapısında bir veritabanının ikincil sunucuya yük devrini (fail over) otomatik sağlamak için “witness” rolünde bir sunucu yerleştirmemiz gerekiyordu, bu rolde çalışan sunucu birincil veritabanı sunucusunda çalışan veritabanlarının ulaşılamaz hale gelmesi durumunda ikincil sunucuya otomatik olarak yük devri yapması için “failover” mekanizmasını tetikliyordu, “Availability Group” larda ise otomatik “failover” işlemi windows cluster servisleri tarafından gerçekleştiriliyor, yeni bir Availability Group” tanımlandığı zaman bu aynı zamanda windows cluster servislerinde bir uygulama kaynağı (application resource) olarak otomatik tanımlanıyor. Tabiki bu özellikten anlaşılacağı gibi “ALWAYSON” servis özelliğini açabilmemiz için SQL Server Denali CTP3 ü kurduğumuz sunucuların bir kümelenmiş windows sunucularının düğümleri(node) olması şartı var fakat SQL Server Denali CTP3 “Stand Alone” olarak kurulu olmalı. Bu gereksimin bakış açımıza göre bize bir çok avantajlı senaryo sağlayabiliyor.
Senaryo-1 : Ayrı Sunucular, Ayrı Görevler
“Availability Group” ların “Hight safety” özelliği “Database Mirroring” den gelmektedir ve bu da aradaki veri trafiğinin senkron olmasını belirtir, bu özellikte bir veritabanı işlemi öncelikle ikincil sunucuda daha sonrasında birincil sunucuda işlenir. Aşağıdaki senaryo “Hight safety” ve okunabilir ikincil sunucu özelliği sayesinde bizlere okuma ve yazma görevlenin tamamen ayrılabileceği ortam sağlamaktadır, hatta ikincil sunucuyu okurken yapılan bağlantıların sadece okuma amaçlı gelmelerini “Availability Group” kurulumu esnasında zorlayabiliyoruz. Bu konuya örneğimizde değiniyor olacağız
Bu senaryoyu kurgularken istatistiklerin güncel olmaması gibi bir aykırı durum senaryosu ile karşılaşabileceğimizi düşünebilirsiniz. Bildiğiniz gibi istatistikler performans açısından gerektiğinde tanımlanması ve güncellenmesi açısından oldukça büyük bir öneme sahip veritabanı tablosu nesneleridir. Microsoft mühendisleri bu noktada konuyu bir adım daha ileri götürüp ikincil veritabanları sunucusundaki veritabanlarının ihtiyaç halinde otomatik olarak tanımlanmasını ve güncellenmesini sağlamışlar. Bu konuyu örneğimizde detaylandırıp , “AUTOSTAT” olarak adlandırılan bu mekanizmanın nasıl çalıştığını anlayacağız.
“ALWAYSON” servis özelliğinin bize sağladığı bir diğer heyecan verici özellik ise ikincil veritabanı sunucularının çoklanabileceği. “Window Failover Clustering” “Multi Site Clustrering” desteğine sahip olduğundan dolayı bu “Availability Group” larda kullanılan ikincil eşlenik sunucular farklı ağ ortamlarda bunulabilir, örneğin ODM (Olağanüstü Durum Merkezi) de bulunan veritabanı sunucularındaki veritabanlarını merkezdekilerle gruplayıp ayrı bir ikincil eşlenik sunucu olarak çıkarabilirsiniz ve hatta aradaki iletişimi asenkron olarak kurgulayabilirsiniz. Eskiden bu kurguyu hayata geçirmek günler , hatta haftalar sürerken “ALWAYSON” servis özelliğinin “Availability Group” nesneleriyle artık bir kaç mouse darbesinden ibaret.
Bir diğer güzel özelliği bize “Availability Group Listener” lar sağlıyor. “Failover Clustering” gözüyle baktığımız zaman “Availability Group Listener” nesnesi uygulama kaynağına (application resource) bağlı bir “Client Access Point” nesnesine (IP Adresi ve Ağ ismi kaynağı) denk geliyor. Kısaca “Availability Group Listener” nesneleri bize tek bir IP Adresi ve Ağ ismi ile birincil eşlenik sunucuya bağlanmamızı ve istemci bağlantılarını yapılandırmamızı sağlıyor
Tanımlı “Availability Group” ları izlemek için SQL Server 2011 CTP3 ile beraber 10 yeni dmv geliyor, bunlar bizlere eşlenik sunuculardan, kümelenmiş windows sunuculara kadar bir çok detay bilgiyi veriyor. SQL Server bu bilginin bir kısmını Windows Failover Cluster servisi ile entegrasyon için tutuyor, bir başka dmv grubu “Availability Group” lerin tanımlama bilgilerini sağlarken ,diger dmv ler ise tanımlanan “Availability Group” ların sağlık durumu hakkında bilgiler veriyor. Bu DMV lerin neredeyse tamamına makele serimizin ilerleyen bölümlerinde “DMV lerle Availability Groupları Tanımak” bölümünde değineceğiz.
Makele serimizin bu bu bölümünde SQL Server 2011 CTP3 ile gelen “ALWAYSON” servis özelliklerine değinmeye çalıştık, serimizin ilerleyen bölümlerinde “ALWAYSON” paylaşımlarımız örneklerle devam ediyor olacak.