18 Ağustos 2016 Perşembe

Yüksek Erişebilirlik ve Felaketten Kurtarma Çözümleri (High Availability and Disaster Recovery)

Hizmet aldığımız veya verdiğimiz sistemlerin ihtiyaç duyulduğunda erişilebilir olması son derece önemlidir. Özellikle kurumsal firmalar müşteri memnuniyeti, kurumsal imaj ve karlılık gibi daha bir çok neden dolayı sürekli erişebilir olmayı arzularlar.

Bazı kuruluşlar için hizmet kesintilerinin bedeli inanılmaz boyutlara ulaşabilir. Son zamanlarda yapılmış bir kaç araştırma sonucuna göz atalım; Gartner'ı n araştırmasına göre büyük işletmelerin plansız hizmet kesintilerinin saatlik maliyeti $42,000 civarı olmaktadır. Ponemon Institute bu değeri dakikada $5,600 olarak tespit etmiştir. InformationWeek de IT kesinti maliyetinin yılda $26.5 milyar gelir kaybına yol açtığını vurgulamıştır.

InternetWeek (4/3/2000) ve Fibre Channel tarafından yayınlanan bir kaç sonuca göz atalım:

2000 yılı Saatlik Kesinti Maliyeti
Brokerage operations  $6,450,000.00
Credit card authorization  $2,600,000.00
Ebay (1 outage 22 hours)  $225,000.00
Amazon.com  $180,000.00
Package shipping services  $150,000.00
Home shopping channel  $113,000.00
Catalog sales center  $90,000.00
Airline reservation center  $89,000.00
Cellular service activation  $41,000.00
On-line network fees  $25,000.00
ATM service fees  $14,000.00

Ek olarak Dell'in bir açıklamasına göre 10 saatlik kesintilerinin bedeli $83 milyona, bir online komisyonculuk (simsarlık, brokerlık) firması olan eTrade'in açıklamasına göre ise 1 saatlik kesintilerinin bedeli $8 milyona tekabül etmekteymiş.

Siz de kendi işletmeniz için kesinti maliyetini hesaplayabilirsiniz. Bunun için basitçe şu formülü uygulayabilirsiniz: 

(Yıllık Brüt Gelir/Yıllık Toplam Çalışma Saati) x Kesintinin Etki Yüzdesi x Toplam Kesinti Saati

Veya bu konuda farklı parametrelerle çalışan hesap makinelerine İnternet üzerinden erişebilirsiniz. Ben birini kullanarak sizin için hesaplama yaptım. Sonuçlar şöyle :

Bu hesaba göre yıllık $20 milyon dolar geliri olan 15 kişilik bir işletme dakikada $218, saatte $13 bin'lık bir maliyetle karşı karşıya kalıyor görünüyor.

Burada doğrudan parasal kayıp üzerine istatistikler verdik. Ancak tekrar hatırlatmak isterim müşteri memnuniyetsizliğinden ve imaj zedelenmesinden dolayı ortaya çıkacak dolaylı maliyetlerin acısı daha fazla olabilir. Güven giderse, pazar da para da gider.


Erişebilirlik Yüzdesi


Kuruluşlar hizmetleri kesintiye uğramadan, sistemin 24*365 çalışır durumda olmasını isterler. Ancak bu mümkün değildir. Yazılımsal, donanımsal beklenmedik hatalardan tutun da doğal felaketlere kadar bir çok sebeple plansız kesintiler olabilir. Bunun yanısıra zaman içerisinde bakım, güncelleme, yükseltme gibi planlı kesintiler de yapmamız gerekebilir. 

Sistemlerin hizmet verir durumda olduğu zamana uptime hizmet veremediği zamana downtime adı verilir. Downtimeın sıfır olması mümkün değil. Ancak sıfıra yaklaştırabilmek mümkün.

Sistemlerin hizmet verir durumda olduğu sürenin (Server Uptime) kalitesi yani erişebilirlikleri (Availability) yüzdelerle ifade edilir. 

Yaygın söylemleri aşağıdaki gibi bir araya getirebiliriz:

Dokuzlu Adedi Erişebilirlik Yüzdesi Yıllık Kesinti Aylık Kesinti Haftalık Kesinti
2 dokuzlu 99,00% 3,65 gün 7,30 saat 1,68 saat
3 dokuzlu 99,90% 8,76 saat 43,8 dakika 10,1 dakika
4 dokuzlu 99,99% 52,6 dakika 4,38 dakika 1,01 dakika
5 dokuzlu 99,999% 5,26 dakika 26,28 saniye 6,06 saniye

Tablodaki erişebilirlik yüzdelerine göz attığımızda herkesin gönlü 5 dokuzlunun performansından yana olabilir. Tabi ki bu performansın bir maliyeti var. Dokuz sayısı arttıkça birden fazla cihaz ve yazılım lisansı ihtiyacı ortaya çıkar. Dolayısıyla fiyat performans hesabını iyi yapmak ve optimum topolojiyi belirlemek gerekir. Aksi halde cihaz ve lisansa ödenen miktar kesinti halinde ortaya çıkacak olan kayıptan daha yüksek meblağlara ulaşabilir.

Erişebilirlik yüzdesini şu şekilde hesaplayabilirsiniz:
Erişebilirlik Yüzdesi = ([(Toplam Süre - Kesinti Süresi)]/Toplam Süre)x100

Bunu bir örnekle açıklayalım: haftada 2 saat, ayda 8 saat kesinti olmasına tahammül edilebilecek bir sistem için erişebilirlik yüzdesi şöyle hesaplanır: 
(8.760 - (8 x 12) / 8.760) x 100 = 98,9 (yani %98,9 erişilebilir bir sistem.)
(Not: 1 yıl yaklaşık olarak 8.760 saattir.)


Kesintiler ve Çözümler


Sistemin kesintiye uğradığı ana Felaket anı (Disaster Point) adı verilir. Eğer hiç bir önlem alınmadıysa felaket olup bittikten sonra yapacak pek bir şey yoktur. İlk iş elimizdeki yedekleri kullanarak sistemi biran önce en son çalışır olduğu noktaya geri getirmek olur. Bazen yedekleri kullanmak sistemi son çalışır olduğu noktaya kadar getiremez. Bazen felaketin türüne göre yedekleri kullanmadan da sistemi kurtarmak mümkün olabilir.  Bu noktada korkulan ve asıl sancılı olan veri kaybını sineye çekerek çok eski yedeklerden geri dönmek zorunda kalınan senaryolardır.

Eğer bir takım önlemler almışsak kesintileri sancısız atlatmak mümkün olabilir. Bu önlemler maliyetli olsa da kesinti zamanlarında problemleri bertaraf etmeyi oldukça kolaylaştırır. Çoğu zaman hiç bir müdahale yapmaya gerek kalmadan sistem kendi kendine, hissettirmeden, milisaniyeler içerisinde felaketi atlatır. 


Planlı ve plansız kesintiler olabilir. Bu kesintilerden önce alınacak önlemlere Yüksek erişebilirlik (High Availability) çözümleri, sonra yapılan müdahalelere de Felaketten Kurtarma (Disaster Recovery) çözümleri adı verilir.


Felaketten Kurtarma (Disaster Recovery) Çözümleri


Felaketin boyutuna göre çok çeşitli çözümler uygulanabilir. Korkulan çözümler yedekler kullanılarak uygulanan çözümlerdir. O yüzden yedeklere odaklanalım.

Yedeklerin bir şekilde bozulduğu durumlarda zaten yapılacak pek bir şey kalmaz. Yedeklerin kullanılabildiği durumlarda da bilinçsiz müdahaleler yüzünden kurtarılacak kısımlarda veri kaybı yaşanabilir.

Uzun uzun konuşmak mümkün ancak temelde üç şekilde veri kaybı yaşanır:
  1. Önceden alınmış yedekler bozulmuş olabilir veya plansız alınan yedekler yüzünden yedekleme zinciri bozulmuş olabilir.
  2. Veritabanına başarıyla kaydedilmiş ancak henüz yedeklenememiş bilgiler kaybedilebilir.
  3. Sistem hizmet dışı iken gönderilen talepler yakalanamaz.
Yedekleme (Backup) ve yedekten dönme(Restore) konusu oldukça geniş. Bu yazımızda küçük ve önemli bir kaç ipucu verip geçelim istiyorum:
  • Yedek alma planınızı optimize edin ve bunu dökümante edin. Full, Diff, Log, T-Log, Partial vs. yöntemlerini gerekirse harmanlayın. Yönetilebilir ve güvenli olsunlar. Bunun için şu soruların cevabını göz önünde bulundurun.
    • RPO: Recovery Point Objective (Ne kadarlık bir zaman aralığındaki verinin kaybolmasını tahammül edebilirim?)
    • RTO: Recovery Time Objective (Sistemi ayağa kaldırmak için ne kadarlık bir zaman aralığına tahammül edebilirim?)
  • Yedeklerinizin bozulup bozulmadığını test ortamlarında geri dönüşler yaparak kontrol edin. Başırıyla dönülebildiği teyit edilmemiş bir yedek hiç alınmamış gibidir. 
  • Yedeklerinizi üçüncü parti sıkıştırma yazılımları ile değil SQL Server'ın kendi sıkıştırma özelliği ile sıkıştırın. 
  • Yedeklerinizin kopyalarını uzak lokasyonlara da alın. SQL Server ile aynı cihaz üzerinde duran yedeklere güvenmeyin.
  • Belli aralıklarla test ortamlarında felaket senaryoları oluşturun ve pratik yapın. Sonuçları direktifler listesine dönüştürün. Bu gerçek bir problem esnasında soğuk kanlı ve idraki açık olmanızı sağlar. 

Yüksek Erişebilirlik (High Availability) Çözümleri


Felaket (kesintiler diye düşünelim) önce bir takım önlemler alınırsa hizmet kalitesinde hissedilir derecede bir eksilme görülmeyebilir. Buradaki çözümler birden fazla instanceın, yerine göre cihazın birlikte kullanımıyla ilgili çözümlerdir. Bu konuya ne kadar yatırım yapılırsa o kadar verim alınabilir. Ancak cihaz, lisans ve bakım maliyetleri göz önünde bulundurularak optimum çözümü belirlemek gerekir. Aksi halde yatırım anlamsız dahası zararlı olabilir.

HA çözümleri ciddi yönetim becerisi gerektirir. Fakat planlı ve plansız kesintileri de milisaniyeler seviyesine indirir, yedekliliği arttırır ve daha büyük problemlerle yüzleşme ihtimalini azaltarak işleri kolaylaştırır. 

SQL Server 2012 ve sonrasında şu HA çözümleri kullanılabilmektedir.

Resmi tıklayarak büyütebilirsiniz.
  • AlwaysOn FailOver Cluster
    • Birden fazla server için donanım bazlı bir çözüm sunar. 
    • Instance (SQL Server kurulumu diyelim) seviyesindeki nesneler için erişebilirliği mümkün kılar
    • Bir server aktif diğerleri yazma ve okumaya kapalı şekilde pasif modda durur.
    • Aktif server kapandığında pasif olan diğer server otomatik olarak devreye girer.
    • Serverlar veritabanının olduğu aynı depolama birimine bağlıdırlar. Depoalama birimi zarar görürse veritabanına serverlar üzerinden erişilemez. Bu sistemin zayıf tarafı disk hatalarıdır.
    • Özel donanımlar ve yazılım gerektirdiği için pahalı bir çözümdür.
  • Databases Mirroring
    • Veritabanı seviyesinde bir çözümdür. 
    • Veritabanının birden fazla kopyası tutulur. Biri arızalansa diğeri ile hizmet devam eder.
    • Sistem senkron veya asenkron veri eşleştirmesi yapabilir.
    • Otomatik veya manual görev değişimi (FailOver) yapılabilir.
    • İkincil serverdan (Database Snapshots ile) raporlama amaçlı erişim sağlanabilir.
    • Network yavaş ile özellikle senkron modda hizmet yavaşlar.
    • Birden fazla veritabanı kopyası olacağı için daha fazla depolama alanına ihtiyaç duyulur.
  • Log Shipping
    • Fakir adamın mirroring yaklaşımı olarak ifade edilir.
    • Birden fazla servera veritabanının kopyasını istenen gecikme süreleri ile göndermek mümkün olur.
    • Farklı editionlarla birlikte çalışmak mümkündür.
    • Temelde backup/restore planları ile çalışır.
    • Otomatik failover özelliği yoktur. 
    • Veritabanı kopyaları oluştuğu için daha fazla depolama alanına ihtiyaç duyulur.
  • AlwaysOn Availability Groups
    • Windows Cluster alt yapısını kullanan, Mirroring ve Log Shipping özelliklerini bir araya getiren SQL Server 2012 sonrası duyurulan bir çözümdür.
    • Birden fazla veritabanını bir arada farklı serverlar ile eşleştirmek mümkündür. Log Shipping gibi birden fazla server arasında eşleştirme yapılabilir (SQL Server 2016 ile 9 servera kadar).
    • Database Mirroring gibi senkron ve asenkron modda çalışabilir.
    • Otomatik Failover desteği vardır. 
    • İkincil veritabanları okumaya açık olarak tanımlanabilir. Böylece raporlama ve yedekleme iş yükü birincil sunucudan ikincil sunuculara dağıtılabilir.
  • Replication
    • Pek de HA çözümü olarak kabul edilmez. Daha çok veri senkronizasyonundan sorumludur.
    • Kendi için de çeşitleri vardır. Konumuzla kısmen ilgilidir ancak çoğunlukla farklı başlıklar altında ele alınır.
Bu çözümleri aynı topolojide belli kurallar çerçevesinde birlikte kullanmak da mümkün.

Bu konuda SQL Server 2016'nın edition desteği de şöyle:


Özetle;


Çoğu kuruluşun hayatı kesintisiz devam etmesi gereken kritik hizmetlere bağlıdır. Bu hizmetlerin devamlılığı için fiyat performans hesapları iyi yapılmış optimum sistemler kurmak gerekir. Hem felaketten önce alınacak Yüksek Erişebilirlik (High Availability) çözüm önlemleri hem felaketten sonra yapılacak Felaketten Kurtarma (Disaster Recovery) aksiyonları veritabanı yönetiminin titizlikle üzerinde durması gereken bedeli ağır konulardır. 

Bu konularla ilgili test ortamları oluşturmalı ve belli aralıklar muhtemel senaryolar üzerinde tatbikatlar yapılmalıdır. Bu tatbikatlardan acil durumlarda yapılacaklar listesi hazırlanmalı ve gerekli taraflar ile paylaşılmalıdır. Ve tabi ki belli aralıklarla stratejileri gözden geçirmeye devam etmek gerekir. Bu efor, veri kaybından doğan hasar giderilirken stres altında sarf edilecek eforun yanında hiç bir şey değildir.


Hiç yorum yok:

Yorum Gönderme