Makale Özeti

Eğer gerekinimleriniz ve ihtiyaçlarınız donanımsal bazda sürekli kullanılabilirlik gerektiriyor ve etkin olarak kullanılan sunucunuz da donanımsal bir arıza olduğunda da yedek sunucunuza otomatik olarak geçiş yapmak istiyorsanız ve bununla birlikte bütçeniz de kısıtlı değilse SQL Server Failover Clustering tam size göre!

Makale

SQL Server Failover Clustering

Eğer gerekinimleriniz ve ihtiyaçlarınız donanımsal bazda sürekli kullanılabilirlik gerektiriyor ve etkin olarak kullanılan sunucunuz da donanımsal bir arıza olduğunda da yedek sunucunuza otomatik olarak geçiş yapmak istiyorsanız ve bununla birlikte bütçeniz de kısıtlı değilse SQL Server Failover Clustering tam size göre! Bu noktada, Otomatik Geçiş (Automatic Failover) hakkında az çok bilgi sahibi olan arkadaşlar hemen “Neden Database Mirroring değil?” diyebilir; o noktaya da başka bir yazımda değineceğim.

Aslında Clustering (küme), SQL Server’ a has bir özellik değildir. SQL Server Failover Cluster’ ı, MSCS (Microsoft Cluster Services) üzerine kurarız. Yani SQL Server Failover Cluster sistemini kurmadan önce, Windows Server’ da bulunan Küme Yöneticisi (Cluster Administrator) ‘ni kullanarak MSCS’ i yapılandırmamız ve gerekli ayarları da yapmamız gerekir. (MSDTC servisinin kurulumu, Kaynak ve Grup ayarları, Otomatik Geçiş ve Otomatik Geri-Geçiş sistemlerinin ayarları gibi)

Her Kümenin en az bir tane Quorum Disk’ i vardır. Bu diskte, Küme sistemi hakkında üretilen kayıtlar (log) tutulur. Bu kayıtlar geçiş bilgilerini barındırır. SAN (“Storage Area Network”, yani bir veya bir çok SCSI veya SATA diskten oluşan bir depolama birimi) üzerinde 50-100MB’ lık bir disk alanı bile kâfidir. Bununla birlikte Microsoft 250MB önerir.

SQL Server Failover Clustering’ in iki biçimi vardır. Bunlar: “Active\Active” ve “Active\Passive” dir. Aslında bu deyimler artık demode olmuşlardır ve bunların yerine "bir veya birden fazla aktif düğüm" tanımlaması kullanılır.
 

 

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.

Bir Windows Server 2003 sunucusunda en fazla 8 düğümden oluşan bir Küme oluşturabilirsiniz. Bu kısıtlama işletim sistemiyle alâkalıdır. Küme sistemini kullanabileceğiniz işletim sistemleri sürümleri Windows Server 2003 Enterprise ve Datacenter Edition’ lardır. Windows Server' ın eski versiyonları da Küme' yi destekler. 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 başka yazılarımda 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.

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


Ekrem Önsoy