Hizmet aldığımız veya verdiğimiz firmaların ihtiyaç duyulduğu her an erişilebilir olması son derece önemlidir. Özellikle kurumsal firmalar müşteri memnuniyeti, kurumsal imaj, rekabet ve karlılık gibi daha bir çok nedenden dolayı hızlı ve sürekli erişebilir olmaktan vazgeçemezler.
Bazı kuruluşlar için hizmet kesintilerinin bedeli çok ağır olabilir. Gartner'ın yapmış olduğu bir araştırmaya göre büyük ölçekli bir kuruluşun 1 saatlik kesintisinin bedeli 42 bin dolar civarındadır. Geçtiğimiz senelerde InformationWeek dergisinde yayınlanan bir analize göre IT kesintilerinin bedeli 26,5 milyar dolara çıkmıştır.
Çoğu kuruluşun hayatı tümüyle kesintisiz devam etmesi gereken hizmetlere bağlıdır. Bu hizmetlerin devamlılığı için fiyat-performans analizleri iyi yapılmış güvenilir sistemler kurmak gerekir.
Sistemlerin durduğu, hizmetin devam edemediği anı felaket anı olarak kabul edersek; felaketten sonra sistemi tekrar işler hale getirmek için yapılacak işlemlere Felaket Kurtarma - Disaster Recovery (DR), felaket olmadan önce alınacak önlemlere de Yüksek Erişilebilirlik - High Availability (HA) deriz.
Felaket olup sistem tekrar işler hale gelene kadar iki tür kayıp yaşanır; bunların ilki hasar gören verinizle veya verinizin yedeklenmemiş kısmıyla ilgilidir. ikincisi ise sistemi tekrar işler hale getirene kadar geçen sürede yakalayamadığınız verilerle ilgilidir. Her ikisinin de maliyeti maddi ve manevi açılardan çok ciddi seviyelere ulaşabilir.
DR adına yapılacak işlemler temelde sağlıklı şekilde alınmış backuplardan ve snapshotlardan dönmekle ilgilidir. HA adına alınan önlemler ise temelde birden fazla server için cluster yapısı kurmak ve kopya-replica veritabanları oluşturmakla ilgilidir.
HA felsefesinde server yönetimi her ne kadar görece daha pahalı olsa da, DR felsefesinde server yönetiminde karşılaşılan kayıplar çok daha pahalıya mâl olabilmektedir.
Sistemin ayakta olduğu süreye uptime, kesinti olup cevap veremediği süreye downtime denir. Sistemin hizmet vermeye başladığı andan itibaren felaket olup cevap veremediği ve tekrar hizmet vermeye başladığı ana kadar geçen toplam süreye total elapsed time adı verilir. Bu değişkenler üzerinden sistemin erişilebilirlik yüzdesi hesaplanır. Özellikle bulut hizmeti veren firmalar sistemleri ne kadar ayakta tutabildiklerini bu yüzdelerle ifade ederler.
Bir örnek üzerinden açıklayalım:
Haftalık olarak bakım, onarım ve yükseltme adına bir takım çalışmalar yaptığımızı düşünelim. Bu çalışmalar için serverı en müsait zamanlarda toplamda haftada 2 saat kadar erişime kapattığımızı düşünelim.
Haftada 2 saat kesinti, kabaca ayda 8 saat kesinti yapar. Bu yılda 96 saat demektir.
Tüm yılda 24*365 yani 8760 saat bulunsun.
Erişilebilirlik Yüzdesi = (( toplam geçen süre - toplam kesinti süresi ) / toplam geçen süre ) * 100
EY = ((8760 - 96)/8760)*100
EY= 98.9
Bu durumda böyle bir sistem yılda %98.9'luk uptime ile hizmet vermektedir deriz.
Haftada 2 saatlik kesinti bazı hizmetler için makul görünebilir. Ancak bazı hizmetler için asla kabul edilemez. Dahası gerçek manada ölümcül sonuçlar doğurabilir.
Rekabette avantajı elden bırakmak istemeyen firmalar için ise yüksek performans ve yüksek erişilebilirlik zorunluluktur. Amazon'un yapmış olduğu bir açıklamaya göre 100 ms gecikmeleri satışarını %1 düşürmektedir. Başka bir açıklamalarına göre her saniyenin değeri 1.6 milyar dolar civarındadır.
Sistemlerin %100 uptimea sahip olması pratikte pek mümkün değildir. Bakım, onarım ve yükseltme her sistemde bir şekilde olur. Kesintiler insan algısının altına düşse de mevcuttur. Bu sebeple sistemlerin uptime yüzdeleri %99.999 biçiminde olur ve kaç dokuz olduğuna göre isimlendirilir.
Mesela; iki dokuzluk yani %99.0'lık uptimea sahip bir sistem yılda 3.65 gün haftada 1.68 saat downtimea sahiptir. Beş dokuzluk yani %99.999'luk uptimea sahip bir sistem ise yılda sadece 5.26 dakika, haftada ise 6.06 saniye downtime sahiptir. Sistemler genelde üç dokuzluk yani %99.9'luk uptimea sahip olur. Bu da yılda 8.76 saat, ayda 43.8 dakika, haftada 10.1 dakika downtime demektir.
Sürekli erişilebilir olmak sizin için önemliyse ve olası bir felakette hizmet kesintisini saniyeler, hatta mili saniyeler seviyesinde tutmak isterseniz; yüksek erişilebilirlik - HA çözümlerine odaklanmanız gerekir.
SQL Server 2017 ile birlikte felaket öncesi alınabilecek önlemler şunlardır:
- AlwaysOn Failover Cluster (Uzun zamandır var. Bazı versiyonlarda geliştirildi.)
- AlwasyOn Availabilty Groups (SQL Server 2012 ile birlikte geldi ve her versiyonda geliştirildi.)
- Database Mirroring (Uzun zamandır var. Yeni versiyonlarda görmeyebiliriz.)
- Basic Availability Groups (Mirroringin yerini alıyor. Standart editionda 2 Server 1 DB için kurulabilir.)
- Clusterless Availability Group (Yüksek erişilebilirlik çözümü sayılmaz. DB kopyası oluşturur.)
- Log Shipping (Uzun zamandır var. Backup-restore ile DB kopyası oluşturulur.)
- Replication (Yüksek erişilebilirlik çözümü sayılmaz. Tablo seviyesinde kopya oluşturulur)
Replication tablo seviyesinde yayıncı, dağıtıcı ve abone rollerinde gazete dağıtım mantığında veri kopyalamak için kullanılır. Yüksek erişilebilirlik çözümü sayılmaz. Biz de bu sebeple Replicationı serimizin odağı dışında tutuyoruz.
SQL Server 2017 Enterprise ve Standart Editionda desteklenme durumu şöyle:
Serinin devamında bu çözümlerin hangi editionlarda ne şekilde desteklendiğine, temel topolojilere ve çözümlerin avantajlı-dezavantajlı yönlerine odaklanacağız.
Hiç yorum yok:
Yorum Gönder