BilgisayarDersleri.NET

Yazımızın ikinci bölümünde bu alternatif teknolojileri incelerken Oracle ve SQL Server'ın bu teknolojileri nasıl uyguladığını görecegiz.

 

SQL Server 2005 - N-Way Clustering
Windows Server 2003 tarafından sağlanan gelişmiş clustering desteği ile, SQL Server 2005, SQL Server 2003 Datacenter Edition üzerinde çalıştırıldığında  8-node'lu, Windows Server 2003 Enterprise Edition ya da Windows 2000 Datacenter Server üzerinde çalıştırıldığında 4-node'lu ve Windows 2000 Advanced Server üzerinde çalıştırıldığında 2 node2lu  cluster'ları destekler.

 

Microsoft Windows Clustering servisleri veritabanı platformlarını sunucu sorunlarından korumak için önemli bir teknolojidir. Windows Clustering servisleri SQL Server, Oracle ve DB2 gibi tüm enterprise ürünler tarafından kullanılabilmektedir. Farklı Windows Server işletim sistemleri destekledikleri cluster node sayılarında farklılıklar gösterirler. Aşağıdaki tabloda Windows 2000 Server ve Windows Server 2003 ailesindeki farklı işletim sistemlerinin kaçar node desteklediğini görebilirsiniz.

Operating System	Nodes
Windows 2000 Server	0
Windows 2000 Advanced Server	2
Windows 2000 Datacenter Server	4
Windows Server 2003 Standard Edition	0
Windows Server 2003 Enterprise Edition	4
Windows Server 2003 Datacenter Edition	8 (SQL Server Enterprise Edition 64-bit only)

Şekil 2. Windows Server Ailesi Clustering Desteği

 

Windows Clustering'de, her fiziksel sunucu bir "node" olarak adlandırılır. Node'lar bir araya gelerek bir cluster'ı oluştururlar. Cluster'daki bütün node'lar birbirlerinin durumunu kontrol etmek için devamlı olarak iletişim halindedirler. Eğer cluster'daki bir node herhangi bir sorundan dolayı erişilemez duruma gelirse, diğer bir node otomatik olarak sorunlu node'un görevlerini devralır ve kullanıcılara sorunlu node ile aynı servisleri sunmaya devam eder. Bu işlemin adı "failover" ?dır. Serviste hiç kesinti yaşatmadan failover işlemini gerçekleştirebilen çok özel donanımsal çözümlerin yanında, Windows cluster'ın failover işlemi için yaklaşık ortalama 20 saniye gibi bir süreye ihtiyacı vardır. Bu sure kullanılan donanım ve failover işlemi olduğu sıradaki veritabanı aktivitesinin yoğunluğuna bağlı olarak uzayabilir ya da kısalabilir. Node'un erişimi kesildiğinde sorunlu node'a bağlanan istemcilerin bağlantısı kesilir. İstemciler tekrar bağlanmayı denediklerinde devreye giren diğer node'a bağlanır ve servis almaya devam ederler.

 

Windows Clustering çözümü uygulayabilemniz için Microsoft tarafından Windows Clustering tarafından kullabilmek üzere sertifikalandırılmış bir sunucu sistemi kullanmanız gerekmektedir. Desteklenen donanım platformlarının listesini Windows HCL Home Web sayfasından bulabilirsiniz.

 

Windows Clustering aşağıdaki avantajları sağlar :

• Otomatik failover. Herhangi bir node'da sorun tespit edildiğinde cluster, servisleri otomatik olarak birincil node'dan (sorunlu olan node) ikincil node'a taşır.
• İstemciler sorunu algılamazlar. Failover tamamlandıktan sonra, istemciler aynı ismi ya da IP adresini kullanarak servis almaya devam ederler.
• İşlemsel bütünlük. Sorun olduğu anda aktif olan tüm işlemler saklanır ve failover işlemi bittiğinde tekrar kaldıkları yerden devam ederler.
• Hızlı failover. Birçok senaryoda failover işlemi 20-30 saniyede tamamlanır. Veritabanı işlemlerinin başlaması failover işleminden sonra ileriye sarılacak ya da geri alınacak verilerin sayısına bağlı olarak değişebilir.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Şekil 3. 2-Node Clustering

 

Bir cluster aşağıdaki donanımlara ihtiyaç duymaktadır :

• Windows Server işletim sistemi için bir hard disk. Bu disk paylaştırılmamıştır ve ortak, paylaşılan depolama alanının denetleyicisine bağlı değildir. Disk kendi denetleyicisine bağlıdır  ve erişilebilirliği arttırmak için mirroring gibi teknolojilerle korunmalıdır.
• Cluster'ın paylaşılan depolama alanına bağlanabilmek için SCSI ya da Fibre Chanenel adaptörü.
• İki ağ arabirim kartı (Network Interface Card - NIC). Biri cluster node'unu istemcilerin erişeceği ağa bağlamak için, diğeri ise cluster'ın node'ları arasında iletişim için kullandığı "Heartbeat" denilen, node'ların birbirinin erişilebilirliğini kontrol ettikleri özel ağ içindir.

 

Cluster'daki node'lar paylaşılan bir depolama alanı kullandıkları için birbirlerine yakın olmaları gerekmektedir. Node'lar arasındaki mesafe depolama alanı için kullanılan sisteme bağlıdır. Node'lar, SCSI bağlantısı kullanılıyorsa birkaç metre uzaklıkta, Fibre Channel kullanılıyorsa birbirlerine ortalama 150 km. uzakta olabilirler.

Bu çözüm, sunucuda ortaya çıkabilecek sorunlardan korumakla beraber tüm lokasyonu etkileyecek sorunlardan sistemlerinizi koruyamayacaktır (yangın, deprem v.b.). "Geo-clusters" adı verilen çözüm, cluster node'larını coğrafi olarak farklı lokasyonlara ayırma yöntemiyle bu sorunu hedefler. Geo-clusters'ın çalışma prensibi, quarum diskini farklı lokasyonlar arasında senkronize etmeye dayanır. Cluster node'ları arasındaki coğrafi mesafenin farkında değildir, dolayısıyla geo-cluster çözümleri firmanın altyapısında, ağ ve depolama seviyelerinde uygulanır.

 

SQL server 2005 ve Windows Server 2003'ün birleşimiyle kullanılan N+1 cluster konfigurasyonu (N tane aktif node ve 1 tane pasif node) düşük maliyetli ve esnek yüksek erişilebilirlik senaryoları gerçekleştirmenize olanak tanır. Örneğin, sekiz node'lu bir cluster yapısında, yedi node aktif olarak farklı servisleri kullanıcılara sunarken, sekizinci node herhangi bir node'da sorun çıkma ihtimaline karşı pasif olarak bekleyebilir. Şekil 4'te 8-Node clustering örneklendirilmiştir.

 

 

 

 

 

 

 

 

 

Şekil 4. 8-Node Clustering

 

 

SQL Server 2005 - Database Mirroring
SQL Server 2005'le gelen Database Mirroring (Veritabanı Aynalama) teknolojisi sunucu ya da veritabanı sorunlarından kaynaklanan plan dışı aksama sürelerinden korunmanız için bir başka güçlü opsiyondur.

İsminden anlaşılabileceği  gibi, Database Mirroring veritabanı seviyesinde failover hizmeti sunar. Birincil veritabanında bir sorun oluştuğunda, Database Mirroring ikinci bir SQL Server sisteminde çalışan ikinci bir veritabanını hemen devreye alır. Database Mirroring sıfır veri kaybı ile sistemlerinizin erişilebilirliğini arttırmanıza olanak tanır. İkincil veritabanı her zaman birincil veritabanında çalışan işlem ile güncel tutulur. Database Mirroring teknolojisini kullanıyor olmanın diğer işlemlere olan yükü ise hemen hemen hiç yoktur.

Sunucu seviyesinde çalışan Windows Clustering servislerinden farklı olarak, Database Mirroring veritabanı seviyesinde uygulanır. Clustering teknolojisi failover işlemi için 20-30 saniyeye (donanıma ve sorun anındaki veritabanı aktivitesine bağlı olarak daha da çok sürebilir) ihtiyaç duyarken, Database Mirroring teknolojisi birkaç saniye içinde failover işlemini gerçekleştirir.

 

Database Mirroring, Windows Cluster servislerine göre disk sorunlarına karşı daha fazla koruma sağlar, çünkü Database Mirroring'de disk paylaştırılmamıştır. Bununla beraber, çalışmak için özel donanıma ihtiyaç duyan clustering teknolojisinde node'lar arasındaki mesafe (heartbeat sinyallerinin node'lar arası gidip gelebilmesi için) maksimimum 150 km civarındayken, Database Mirroring'de node'lar arasındaki mesafede herhangi bir limit yoktur ve SQL Server'I destekleyen tüm standart donanımlarla beraber çalışabilir.

 

Database Mirroring üç farklı sistem ile birlikte kullanılır : Birincil sunucu, ikincil sunucu ve witness (gözlemci).

 

Birincil sunucu kullanıcılara hizmet sunan aktif SQL Server sistemidir. İkincil sunucunun görevi ise birincil sunucunun veritabanının kopyasını saklamaktır. Veritabanının ikincil sunucudaki kopyası sadece yedek olarak durmaktadır ve kullanıcılara hizmet vermemektedir. Wtiness denilen sistem ise kimin birıncil olacağına karar veren sunucudur.

 

Database Mirroring transaction log'ların birincil sunucudan ikincil sunucuya gönderilmesi ve ikincil sunucuya uygulanması ile gerçekleşir. Bu sistem Log Shipping e benzer (bir sonraki başlıkta Log Shipping anlatılacaktır), en temel iki fark ise, Database Mirroring'de loglar aynı zamanda direk olarak ikincil sunucuya yazılır ve yaptığınız konfigurasyona göre, istenilirse birincil sunucuda bir arıza oluştuğunda otomatik olarak ikincil sunucu devreye girebilir.

 

İstemci birincil sunucuya bir sorgu (insert, update, delete gibi) gönderdiğinde bu istek, veritabanına yazılmadan önce loglara yazılır. Daha sonra transaction log kayıtları ikincil sunucuya gönderilir ve ikincil sunucunun transaction log'una yazılır. İkincil sunucu kayıtları log'una yazdıktan sonra birincil sunucuya onay gönderir. Bu sayede her iki veritabanının log'unda aynı verinin olduğuna emin olunur. İstemciden "Commit" komutu (istemcinin işlemin çalıştırılmasına dair gönderdiği onay) geldiğinde, birincil sunucu, istemciye "işlem başarılı" mesajı göndermeden önce  ikincil sunucudan onay alır. İkincil sunucu transactional log'ları devamlı güncellemesi gerektiği için, devamlı olarak "geri yükleme" modundadır.

 

 

Şekil 5 - Principal ve Mirror server'ların çalışlması

 

İstemcilere yüksek erişilebilirlik sağlamak için Data Mirroring teknolojisi Microsoft Data Access Components (MDAC)'e yapılan "Transparent Client Redirection / Şeffaf İstemci Yeniden Yönlendirmesi" olarak adlandırılan bir güncelleme ile beraber çalışır. Transparent Client Redirection, birincil sunucuda herhangi bir sorun olduğunda, birincil sunucuya bağlanan istemcilerin otomatik olarak ikincil sunucuya yönlendirilmesini sağlar. Transparent Client Rediraction özelliği MDAC katmanında çalıştığı için, istemcilerin bu özelliği kullanabilmeleri için uygulamalarında herhangi bir değişiklik yapmak zorunda kalmazlar.

Normal şartlar altında ikincil veritabanı devamlı "loading / geri yükleme" modunda olduğu için kullanıcılar tarafından kullanılamaz. Fakat geri yükleme modundaki ikincil veritabanının snapshot'u alınarak ikincil veritabanına read-only (sadece okunabilir (örneğin raporlama için)) erişim sağlanabilir. Snapshot'lar normalde veri değişmediği sürece boş veritabanları olsa bile, bir kullanıcı snapshot'a bir sorgu gönderdiğinde, eğer o veri sayfası henüz daha değişmemiş ve dolayısıyla veritabanın snapshot'una yazılmamışsa sorgu snapshot'u alınan kaynak veritabanına yönlendirilir (Detaylar ve çalışma prensibi için Şekil 1b'yi tekrar inceleyiniz). Bu şekilde, ikincil veritabanını raporlama gibi sadece okuma gereken işlemler için kullanabilirsiniz.

 

SQL Server 2005 - Log Shipping

SQL Server 2005 ve daha önceki versiyonlarında da mevcut bulunan bu yüksek erişilebilirlik servisi, daha önceki SQL Server verisyonları gibi SQL Server 2005'te de sunulmaktadır. Log shipping, sunucu hatalarına karşı veritabanını koruyan düşük maliyetli bir çözümdür. Log shipping, SQL Server çalıştırabilen herhangi bir platformda uygulanabilir. Log shipping, birincil veritabanından transactional log yedeği alınarak bu yedeklerin otomatik olarak beklemede olan ikincil sunucuya (ya da sunuculara) geri yüklenmesi ile iki sunucudaki verileri senkronize tutma esasına dayanır. Beklemede olan ikincil sunucuya log yedeği geri yüklenmeden önce bir kerelik birincil ve ikincil veritabanını eşitlemek için once birincil veritabanında full backup alınıp beklemede olan ikincil veritabanına geri yüklenmelidir. Log shipping'i belirli zaman aralıkları ile gerçekleşmesi için ayarlayabilirsiniz. Bu kullanıcı tanımlı gecikme, olası bir hatada ya da sorunda bozuk verinin ikincil veritabanına geri yüklenmesini engellemek için zaman tanır.

Log shipping aşağıdaki bileşenlerden oluşur :

• Birincil sunucu. Bu sunucu canlı veritabanını çalıştırır. SQL Server Agent'daki zamanlanmış görevler transaction log'ların periyodik yedeklerini alırlar.
• İkincil (beklemede) sunucu. İkincil sunucu canlı veritabanının devamlı yükleme modundaki versiyonunu çalıştırır. Bu sunucuda çalışan SQL Server Agent zamanlanmış görevleri periyodik olarak birincil sunucudaki transaction log yedeklerini kendisine kopyalar ve yükleme modundaki veritabanına geri yükler.
• İzleme sunucusu. Birincil ve ikincil sunucuların durumunu izler.

 

Windows Clustering Services ya da Database Mirroring teknolojilerinden farklı olarak, log shipping, birincil sunucuda erişimi engelleyecek bir sorun ortaya çıktığında otomatik olarak ikincil sunucuyu aktif hale getirip birincil ve ikincil sunucunun rollerini değiştiremez, bu işlemi manuel yapmak zorundasınız. Log shipping'i Windows Clustering Services ile beraber kullanarak veritabanınızı hem sunucu sorunlarına hem de tüm lokasyonu etkileyebilecek felaketlere karşı koruyabilirsiniz.

 

SQL Server 2005 - Replication
SQL'deki replication tiplerinden biri olan "Transactional Replication", sunucu sorunlarına karşı kullanabileceğiniz bir başka teknolojidir. Replication aslında bir yüksek erişilebilirlik teknolojisi olarak tasarlanmamış olsa da (çünkü birincil veritabanı ile ikincil veritabanı arasında sorgular göndererek çalışır), transactional replication'ı düşük maliyetli veritabanı sunucusu yedekleme mekanizması olarak kullanabilirsiniz. Şekil 6'da transactional replication'un çalışma metolojisini çok genel olarak görebilirsiniz.

SQL Server transactional replication üç temel bileşenden oluşur :

• Publisher. Publisher replike edilecek verinin kaynağıdır.
• Subscriber. Subscriber'lar verilerin gönderileceği hedeftir.
• Distributor. Distributor Publisher'dan Subscriber'a / Subscriber'lara verinin gönderilmesini gerçekleştiri

 

Transactional replication Publisher'ı Subscriber'larla senkronize etmeye başlamadan önce, bir kerelik, publisher ile subscriber eşitlenmelidir. Bunu bir kerelik, başlangıçta, kaynak veritabanının snapshot'unu alıp hedef veritabanı ile eşitleyerek sağlar.. Daha sonra değişiklikler düzenli olarak Subscriber'lara gönderilmeye başlar.

 

Bu replication tipinin avantajı ise, hedef sunucu devamlı erişilebilir olduğu için raporlama sunucusu olarak kullanılabilir. Bununla birlikte, transactional replication, yüksek erişilebilirlik sağlayan bir teknoloji olarak tasarlanmamıştır, iolası bir sorun halinde kincil sunucuyu, birincil sunucunun rolünü alması için manuel olarak ayarlamanız gerekmektedir, bu işlem otomatik olmaz. Log shipping, transactional replication Windows Clustering Services ile beraber kullanılarak iki farklı lokasyonda saklanan sunucular ile yüksek erişilebilirlik sağlamak için kullanılabilir.

 

Oracle 10g - Real Application Clusters (RAC)

Oracle'ın desteklediği yüksek erişilebilirlik çözümleri SQL Server 2005'in desteklediklerine çok benzerdir. Oracle Fail Safe ile birlikte sekiz node'a kadar Windows Clustering Services kullanabilirsiniz. Oracle aynı zamanda log shipping'e çok benzeyen "loosely coupled clusters" teknolojisini desteklerken transactional replication'u da destekler.

Oracle, aynı zamanda 9i de ilk defa sunulan ve Oracle 10g ile de sunulmaya devam eden bir başka yüksek erişilebilirlik teknolojisini sunar : Oracle Real Application Clusters (RAC). Oracle 10g Standart Edition ve Enterprise Edition ile birlikte sunulan RAC, Oracle Standard Edition'da maksimum dört işlemci kullanabilmektedir. Management pack, monitoring pack ve partitioning gibi gelişmiş RAC özellikleri sadece Oracle Enterprise Edition ile birlikte sunulmaktadır. Oracle 10g Standard Edition'dan Enterprise Edition'a geçiş ise oldukça maiyetlidir. Oracle Standard Edition CPU başına 15,000 US$ ?a lisanslanırken Enterprise Edition'da CPU başına lisans ücreti 40,000 US$ ?e çıkıyor.

 

Oracle'ın RAC'ı "node" adı verilen birçok bilgisayarın birbirine bağlanması ve tek bir bilgisayar gibi çalışması ile oluşan bir yapıdır. Windows Clustering Services'e benzer olarak, Oracle, RAC'ı sadece belirli donanım platformlarında kullanabilirsiniz. Desteklenen donanım platformlarını http://metalink.oracle.com/ adresinde bulabilirsiniz.

 

Oracle, RAC'ı maksimum 64 node için destekler; bu sayı işletim sistemine bağlı olarak azalabilir.

 

 

 

Şekil 6. Oracle RAC

 

Herhangi bir node'da sorun oluştuğunda kısa bir sure için bağlantı durdurulur, sistemdeki lock'lar tekrar dağıtılır ve RAC node'ları senkronize edilir. Oracle RAC paylaşılan depolama alanı kullanır ve disk arızalarından korunmak için Oracle'ın sadece Enterprise Edition'da bulunan Data Guard teknolojisini kullanmanız gerekir.

Oracle RAC yüksek erişilebilir sistemlere istemcilerin bağlantısı için iki tip connection (bağlantı) failover'ı destekler :

• Connection failover. Eğer istemcinin ilk bağlantısı sırasında bir bağlantı sorunu yaşanırsa, uygulama cluster'daki farklı bir node'a aynı sanal sunucu ismi ile tekrar bağlanmanyı deneyebilir.
• Transparent Application Failover (TAF). Eğer bağlantı sağlandıktan sonra bir bağlantı sorunu oluşursa, bağlantı farklı bir node'a kaydırılabilir. TAF, o anki işlemlerin durumunu kaydettiği için connection failover'a gore daha fazla sistem kaynağı harcar. TAF kullanabilmek için, uygulama kodu yeni Oracle Call Interface (OCI) ?i kullanacak şekilde değiştirilmelidir ve uygulamada "lost session state (oturum kaybetme durumu)" yönetimi ilgili kod bulunmamalıdır. Bunlara ek olarak, update işlemleri geri sarılmalıdır ve server state (server durum) bilgisi failover edilemez.

Windows Clustering'e benzer olarak RAC failover da heartbeat ya da node izleme mekanizmalarına ihtiyaç duyar. Node izleme özelliği node'larda ortaya çıkacak herhangi bir sorun durumunda RAC cluster'ın hızlıca kaynakları senkronize etmesine olanak tanır. RAC'in eşzamanlı active-active mimarisi çok hızlı failover yapabilmesine olanak tanır. Birden falza Oracle birden fazla node'da aktif haldedir ve bütün bu node'lar aynı veritabanına senkronize olurlar. Bütün node'lar depolama alanını eşzamanlı sahiplenebildikleri için aktif / pasif clustering mimarisindeki gibi diskin sahiplik bilgisinin transfer edilmesi gerekmez ve sunucunun kodu zaten belleğe yüklenmiştir. Bir RAC node'u hizmet veremez duruma geldiğinde, failover işlemi sorunlu node'un cluster'dan çıkarılması ve sorunlu node'un sahipliğinde olan kaynakların diğer node'lara dağıtılması ile başlar. Failover bittiğinde sorunlu node'da devam etmekte olan sorgular diğer node'da en baştan çalıştırılırlar.

 

Oracle 10g Data Guard

SQL Server 2005'in Database Mirroring'ine benzer olarak, Oracle Data Guard çalışan veritabanının bir kopyasını ikincil bir sunucuda tutmak için transaction log'ları kullanır. SQL Server 2005'te olduğu gibi, birincil sunucuda herhangi bir sorun olduğunda ikincil sunucuyu aktif hale  getirebilir. Oracle'ın Data Guard çalışan veritabanının dokuz taneye kadar ikincil kopyasını farklı sunucularda tutabilir. Data Guard üc farklı modda çalışabilir :

• Maximum Protection (Maksimum Koruma). Maksimum koruma modunda veri eşzamanlı olarak birincil veritabanından ikincil veritabanına gönderilir. Bütün ikincil veritabanlarında işlem bitene kadar birincil veritabanındaki işlemler sonlandırılmaz. Eğer ikinci sunucuda işlemler tamamlanamazsa, birincil sunucudaki işlemler de durdurulur.
• Maximum Availability (Maksimum Erişilebilirlik). Maksimum erişilebilirlik modu da maksimum koruma moduna benzer çalışır, fakat ilk ikincil veritabanındaki işlem tamamlandığında birincil veritabanı işleme devam eder. İkincil veritabanında ortaya çıkabilecek bir sorun, birincil veritabanının işlemlerini durdurmasına sebep olmaz.

• Maximum Performance (Maksimum Performans). Maksimum performans modunda, birincil veri tabanı işlemlere devam ederken veriler asenkron olarak ikincil veritabanlarına gönderilir. Birincil veritabanı işlemlere devam etmek için herhangi bir ikincil veritabanından onay beklemez.

 

Data Guard sadece Oracle Enterprise Edition'da mevcuttur.

 

Kapanış

Sadece teknolojiyi göz önünde bulundurarak oluşturacağınız bir plan size çoğu zaman hedeflediğiniz hizmet zamanlarını veremeyecektir çünkü yüksek erişilebilirlik insan, yöntem ve teknolojinin birleşmesiyle sağlanabilir. Doğru donanım ve yazılım platformlarını seçerek işe başlamak doğru bir başlangıç olacaktır. Bu noktadan sonra, yüksek erişilebilirlik doğru planlama ve doğru teknolojilerle birleştirilmiş, dökümantasyon, eğitim ve yan faktörlerle oluşturulabilir.

 

Yüksek erişilebilirlik ihtiyacınız ihtiyacınız iş ihtiyaçlarınız tarafından belirlenir, var olan  teknoloji tarafından değil. Her zaman daha erişilebilir sistemler kurmak tercih edilse de, unutmamak gerekir ki, daha erişilebilir sistemler kurmak demek daha fazla maliyet anlamına gelir. Dolayısıyla, sizin işinizin ihtiyacı olan yüksek erişilebilirliği doğru saptamak çok kritik bir noktadır. SQL Server 2005 ve Oracle 10g, her iki ürün de yüksek erişilebilirlik çözümleri sunuyorlar. Bunun yanında her iki platformun maliyeti ve kullanım kolaylığı aynı değil. Microsoft SQL Server 2005 enterprise seviyede yüksek erişilebilirlik özelliklerini düşük maliyete ve Oracle 10g'den daha az kompleksiteyle sağlamaktadır.