Makalem daha ziyade, Veritabanı Yöneticileri “VTY” (İngilizcesi de “Database Administrator” dır ve kısaltması da ”DBA” dir. ) ‘ ne yöneliktir. Terimleri ve kavramları daha iyi anlayabilmek için Bilgi Teknolojileri konusuna biraz aşina olmanız, donanım hakkında ve SQL Server 2005 hakkında genel bilgi sahibi olmanız gerekir.
Bu yazı dizimde size, SQL Server 2005 ile birlikte kullanabileceğiniz Sürekli Kullanılabilirlik (High Availibility) sistemlerinden bahsedeceğim; sistemlerin kurulumlarının tek tek nasıl yapıldığını anlatmaktan veya her şeyin ayrıntısına inmekten ziyade, “Neden?”, “Hangi durumlarda?” ve “Ne zaman?” kullanılabileceklerini anlatmaya çalışacağım. Zaman zaman da ayrıntı gibi görünen güzel tiyolar da vereceğim. Amacım, bu kavramlar hakkında genel olarak bilgi sahibi olmanızı sağlamak. Yazı dizimin en bölümünde de anlattığım sistemler arasındaki artı ve eksileri özetleyeceğim. Böylece hangi teknolojinin sizin için avantajlı olduğunu daha kolay kavrayabileceğinizi düşünüyorum.
Sürekli Kullanılabilirlik nedir?
“Sürekli Kullanılabilirlik” kavramını daha iyi anlatabilmek için sizinle bir örnek paylaşmak istiyorum.
7\24 çalışan ve alış-veriş işlemleri yapılan ve adı da www.aldım-verdım.kom.tr olan bir internet sitesi düşünün. Bir tıraş makinesi satın almak istiyorsunuz ve ilk önce, önceden de alışveriş yaptığınız ve güvendiğiniz bu siteye bakmak istediniz; ama bir de bakıyorsunuz ki site çalışmıyor! Neden? Ya bir donanım arızası, ya bir sistem içi kullanıcı hatası, ya yazılım\donanım bakımı vb. sonuçta bir kesinti var ve sisteme bağlanamıyorsunuz. Ne yaparsınız? Eğer aceleniz varsa ve hemen bir sonuca varmak istiyorsanız, o zaman başka bir alış veriş sitesine bakarsınız ve belki de gördüğünüz seçenekler size cazip gelir ve siparişinizi o siteye verirsiniz.
Sürekli Kullanılabilirlik sistemi olmayan www.aldım-verdım.kom.tr ne kaybetti? Müşteri, bir anlamda da para kaybetti. Belki de bahsi geçen müşteri alışveriş yaptığı diğer siteden memnun kalacak ve bir daha www.aldım-verdım.kom.tr ‘den alışveriş yapmayacak. Tam tersi, kötü olarak etrafına reklamınızı da yapabilir.
İşte bu gibi durumları yaşamamak için, bir Sürekli Kullanılabilirlik sistemi kurmak ve ileriye dönük, doğru bir sistem seçimi yapmak kaçınılmaz ve zorunludur.
Elbette kimse işlerinin kesintiye uğramasını istemez, ama...
“Kim işlerinin yarıda kalmasını ve boş boş beklemeyi, bunun sonucunda mali kayıplar yaşamayı ister ki?” diye düşünebilirsiniz. Aslında kimse işinin bölünmesini elbette istemez; ama ya yeterli bilgi donanımına sahip olmayan (bu nedenle de ne yapabileceğinden bihaber) personelden dolayı ya da Bilgi İşlem bölümüne ayrılan yetersiz bütçeden dolayı Sürekli Kullanılabilirlik için gerekli yatırımlar yapılmaz.
Her şeyin olduğu gibi, bilgisayarlarımızda veya sunucularımızda kullandığımız donanım bileşenlerinin de sınırlı ömürleri vardır ve bu donanımlardan birinde veya birkaçında herhangi bir sorun yaşandığında, en azından bir Sürekli Kullanılabilirlik sisteminin kurulmadığı ortamlarda kesinti sorunları yaşanır. Yani beklenmeyen başa gelir. Bu gibi iş kesintilerinden kaçınmak için, Sürekli Kullanılabilirlik çözümlerini kullanırız.
SQL Server 2005 ile birlikte kullanabileceğimiz Sürekli Kullanılabilirlik seçenekleri:
- SQL Server Failover Clustering,
- Database Mirroring,
- Replication ve
- Log Shipping’ tir.
Hesinin de duruma göre artıları da var eksileri de. Hangisini seçmek isteyeceğiniz de, başta dediğim gibi ihtiyacınıza göre değişir. Yukarıda bahsettiğim Sürekli Kullanılabilirlik seçeneklerinden tek tek bahsedeceğim. Her seçenek sırayla ayrı bir yazı olarak yayınlanacak.
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 sunucunuzda donanımsal bir arıza olduğunda da yedek sunucunuza otomatik olarak geçiş yapmak istiyorsanız ve bununla birlikte bütçeniz de çok 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 daha sonra değineceğim.
Aslında Clustering (küme), SQL Server’ a has bir özellik değildir. SQL Server Failover Cluster’ ı, MSCS (Microsoft Cluster Services- Microsoft Küme Servisleri) ü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 bir 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 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.
Yukarıdaki şekilde, iki düğümden (“Node” yani iki SQL Server sunucusu), bir SAN ‘dan oluşan SQL Server “Active\Active” Failover Clustering şeması görüyorsunuz.
Düğümlerde yerel diskler mevcuttur. Fakat veritabanı dosyaları ve Küme kayıt (log) dosyaları 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’ da olduğu için sağlıklı düğüm, 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.
En fazla 8 düğümden oluşan bir Küme oluşturabilirsiniz. Bu arada, 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 sistemde etkin olarak çalışıyor. 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 tema, 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 darboğaz demektir. İ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 sadece bir Paylaşılmış Disk vardır. Active\Passive’ te de iki düğümdeki donanımın da aynı olmasına dikkat edin. Meselâ Düğüm1’ in hafızasının 4GB, Düğüm2’ nin ise 2GB olduğu bir senaryo düşünün. Düğüm1’ in de mevcut hafızasının %75’ ini kullanarak çalıştığını varsayalım. O zaman Düğüm1’ de bir sorun olduğunda ve Düğüm2’ ye geçiş yapıldığında ne olur? Tabii ki hafıza darboğazı sorunu ile karşı karşıya kalırsınız ki, inanın hiç de hoş olmaz.
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, raporlama amacıyla kullanılabilecek en iyi çözüm bence Transactional Replication’ dır. Neden diğer çözümlerin değil de bu çözümün en iyisi olduğunu düşündüğümü ve diğer çözümlerin artı ve eksilerini, diğer çözümleri de anlattıktan sonra bu yazı dizimin en sonunda anlatacağım.
Konu hakkındaki aklınıza takılan soruları, yaşadığınız sorunları veya eleştirilerinizi lütfen bana bildirin.
--
Ekrem Önsoy
1 yorum:
Açıklayıcı bir makale olmuş. Teşekkürler.
Yorum Gönder