SQL Server Active \ Active Failover Clustering

                                      
 
Yukarıdaki şekilde, iki düğümden (Node), bir Heartbeat bağlantısından ve bir SAN ‘dan oluşan SQL Server “Active\Active” Failover Clustering şeması görüyorsunuz. Tabii ki bu yapı bu kadar basit değil ve sunucunuzun daha başka ihtiyaçları da olacak, fakat bu ihtiyaçlar bu konumuzun dışında.

Düğümlerde yerel diskler mevcuttur. Fakat veritabanı dosyaları SAN' daki Paylaştırılmış Disklerde (Shared Disk) ve Küme kayıt (log) dosyaları da gene SAN üzerindeki Quorum Disk’ te saklanır. Nedeni de çok basit, Küme içerisinde bulunan Düğüm1 veya Düğüm2’ de bir sorun çıktığında, sorunlu düğümdeki servisler Otomatik Geçiş ile sağlıklı düğüm üzerinde çalışmaya başlarlar. Veritabanı dosyaları da SAN’ daki Paylaştırılmış Disklerde olduğu için Failover işlemi gerçekleştiğinde sağlıklı düğüm Paylaştırılmış Disk kaynaklarını (Resource) üzerine alır ve veritabanı dosyalarını istemcilere kullandırtmaya devam edebilir. Eğer veritabanı dosyaları düğümlerin yerel disklerinde olsaydı, o zaman sorunlu düğüm kapandığında ve ulaşılamaz olduğunda Küme sisteminin bir anlamı kalmayacaktı; çünkü bozulan düğümün servisleri sağlıklı düğüme geçseler bile veritabanları, bozulan düğümün yerel diskinde olduğu için istemciler ulaşmaları gereken dosyalara ulaşamayacaklardı.

Düğümler arasında Kalp Atışı (Heartbeat) denilen bir sistem mevcuttur. Bu sistemi, iki düğüm arasında bir “Crossover” kablo bağlayarak veya sadece Küme içerisindeki düğümlerin yer alacağı bir HUB veya Switch kullanarak da gerçekleştirebilirsiniz. Maksat, kalp atışını dinleyerek, hangi sunucunun yaşayıp, hangisinin öldüğünü (yani o an çalışmadığını) tespit etmektir. Bu işlem için yerel ağın kullanılması tavsiye edilmez. Nedenleri ise, yerel ağa yükleyeceği ekstra yüktür ayrıca yerel ağda kaynaklanacak bir sorun düğümlerim sürekli Failover olmasına neden olabilir. Bu nedenle en sağlıklısı Heartbeat için adanmış bir sistem kullanmaktır.

Windows Server 2003' te en fazla 8 düğümden oluşan bir Küme oluşturabilirsiniz. Küme sistemini kullanabileceğiniz işletim sistemleri Windows Server 2003 Enterprise ve Datacenter Edition’ lardır. SQL Server 2005’ in Standard Edition’ ınında 2, Enterprise Edition’ ınında da 8’ e kadar düğüm kullanabilirsiniz.

Windows Server 2003’ ün Edition’ larındaki farklılıkları görmek için http://www.microsoft.com/technet/windowsserver/evaluate/features/compare.mspx adresine göz atabilirsiniz.

SQL Server 2005 Edition’ larındaki farklılıkları görmek için ise http://www.microsoft.com/sql/prodinfo/features/compare-features.mspx adresine göz atabilirsiniz.

Active\Active yapı için iki SQL Server lisansına ihtiyacınız olacak. Çünkü iki sistem de etkin olarak çalışıyor olacak. Ama Active\Passive’ de sadece bir lisans yeterli oluyor. Peki nedir Active\Active ile Active\Passive arasındaki fark?

İki düğümü de etkin şekilde kullanmak istediğimizde, yani meselâ Düğüm1’ i daha ziyade veritabanına veri yazmak (OLTP), Düğüm2’ yi ise raporlama (OLAP) için (veya başka bir amaçla da olabilir tabii ki; ana konu, iki düğümün de etkin olarak kullanılmasıdır) kullanacağınız zaman Active\Active bir yapı kullanabilirsiniz. Bu yapıda iki düğüm de etkin olarak çalışmaktadırlar ve her düğümün kendi sahip olduğu ve SAN üzerinde bulunan Paylaşılmış Disk’ i vardır. Düğüm1’ de donanımsal olarak bir arıza başgösterdiğinde, Düğüm1’ in servisleri Otomatik Geçiş ile Düğüm2’ ye geçecektir. Bu noktada da şöyle bir sorun oluşabilir. İki düğümün de donanımsal olarak aynı özelliklere haiz olduğunu varsayalım (ki tavsiye edilen budur). Düğüm1’ in %70 kapasiteyle çalıştığını ve Düğüm2’ nin de %60 kapasiteyle çalıştığını düşünün. Düğüm1’ in servisleri Düğüm2’ nin üzerine geçtiğinde, Düğüm2’ nin üzerine binen yük %130 olacaktır ki, bu da kaynaklarda darboğaz oluşması anlamına gelmektedir. İster hafızada olsun, ister disklerde, isterse işlemcide. Sisteminiz kitlenecek ve gelen isteklere cevap veremez duruma gelecektir. Bu nedenle, Active\Active yapıda bu noktaya çok dikkat etmek gerekir.

Eğer Düğüm1’ i hem veri yazmak hem de raporlama için kullanacaksanız ve sunucunuz da bu yükü kaldırabiliyorsa ve “Düğüm2 boşa yatsa da olur, yeter ki vakti geldiğinde Otomatik Geçiş işlemi gerçekleştirilsin ve ben de çalışmalarıma devam edebileyim” diyorsanız o zaman Active\Passive’ de size göre. Bu yapıda bir Paylaşılmış Disk de yeter.

SQL Server Failover Clustering çözümü size sadece Sürekli Kullanılabilirlik işlevini kazandırır. Felâket Önleyici (Disaster Recovery, Redundancy) gibi bir niteliği yoktur. Yani Paylaşılmış Disk’ lerinizde oluşabilecek bir veri kaybını, tek başına Failover Clustering kullanarak önleyemezsiniz. Replication, Database Mirroring ve Log Shipping Felâket Önleyici sistemler olarak kullanılabilirler. İlgili konularda bu teknolojilerin bu niteliklerinden de bahsedeceğim.

SQL Server Failover Clustering’ i, Replication, Database Mirroring ve Log Shipping çözümleriyle birlikte de kullanabilirsiniz.

Meselâ Active\Active bir yapıda, Düğüm2’ yi raporlama amacıyla kullanabileceğimizden bahsetmiştim. İşte bunu, yukarıda saydığım çözümlerden biriyle yapabilirsiniz. Bununla birlikte, ikinci düğümde raporlama amacıyla kullanılabilecek en iyi çözüm bence Transactional Replication’ dır.

Konu hakkındaki aklınıza takılan soruları, yaşadığınız sorunları veya eleştirilerinizi lütfen bana bildirin.


Sevgiler,
Ekrem Önsoy