Yedeklilik, Kullanılabilirlik ve Hata Alanları

Ön koşul: iş hizmeti zincirini ve compute–network–storage veri yolunu çıkarabilmelisin. Bu dersin sonunda kullanılabilirlik, yedeklilik, yüksek kullanılabilirlik, felaket kurtarma ve veri koruma kavramlarını birbirinin yerine kullanmadan açıklayabilecek; iş etkisinden MTD, RTO ve RPO konuşmasına geçebilecek; ortak hata alanlarını ve planlı bakım yollarını diyagram üzerinde gösterebilecek; dayanıklılık iddiası için test kanıtı isteyebileceksin. Sürenin yaklaşık 29 dakikası anlatı ve örneklere, 15 dakikası Arven kararına, 10 dakikası kontrollere ayrılır. Bu ders ayrıntılı DR runbook’u veya backup ürünü tasarlamaz; bunlar sonraki modüllerdedir. Buradaki amaç, “yedekli” gibi geniş bir kelimeyi hangi arızaya, hangi zaman ve veri kaybı hedefine, hangi topoloji ve operasyon kanıtına dayandığını soran ölçülebilir bir karar diline çevirmektir.

Dayanıklılık tasarımı cihaz sayısından önce iş etkisiyle başlar. Hizmet durduğunda hangi süreç bekler, güvenlik veya mevzuat etkisi oluşur mu, gelir ve müşteri deneyimi nasıl değişir, manuel çalışma ne kadar sürer ve biriken işlemleri geri kazanmak için ne kadar ek süre gerekir? NIST SP 800-34 Rev. 1, iş etki analizini kurtarma gereksinimlerini önceliklendiren temel adım olarak ele alır. Maximum Tolerable Downtime iş sürecinin kabul edebileceği toplam kesinti sınırını, RTO sistem kaynağının kabul edilemez etki oluşmadan önce ne kadar sürede geri gelmesi gerektiğini, RPO ise kesinti öncesinde verinin hangi noktaya kadar geri kazanılmasının beklendiğini anlatır. RTO hizmetin ayağa kalkma zamanına, RPO tolerans gösterilen veri kaybı penceresine yön verir; biri diğerinin yerine kullanılamaz.

Yedeklilik bir işlevi yerine getirebilecek ek kapasite veya yol bulunmasıdır; fakat kullanılabilirlik sonucu topoloji, geçiş mekanizması, yazılım davranışı, veri tutarlılığı ve operasyonla birlikte oluşur. İki sunucu aynı rack, PDU, top-of-rack switch, hypervisor yönetimi veya storage üzerinde bulunuyorsa birçok ortak hata alanını paylaşır. İki storage controller aynı şasi içindeyse belirli controller arızalarını yönetebilir, bütün şasi veya üst güç yoluna karşı koruma sağlamayabilir. İki site arasında replikasyon bulunması, uygulamanın diğer sitede başlatılabildiğini, DNS ve kimlik bağımlılıklarının hazır olduğunu ya da verinin uygulama açısından tutarlı olduğunu tek başına göstermez. Her “iki tane var” ifadesinin ardından şu üç soru gelir: hangi arıza senaryosuna karşı, yollar nerede birleşiyor ve geçiş en son ne zaman hedef süre içinde test edildi?

Uptime Institute Tier sınıfları veri merkezi saha altyapısının performans hedefini topoloji üzerinden ayırır. Tier I temel kapasiteyi, Tier II yedekli kapasite bileşenlerini, Tier III planlı olarak herhangi bir kapasite bileşeni veya dağıtım yolunun IT operasyonunu etkilemeden çıkarılabilmesini ifade eden concurrently maintainable yaklaşımı, Tier IV ise tekil ekipman arızası veya dağıtım yolu kesintisinin IT operasyonunu etkilememesini hedefleyen fault tolerant yaklaşımı tanımlar. Daha yüksek Tier otomatik olarak her iş için “daha iyi” seçim değildir; maliyet ve operasyon karmaşıklığı iş gereksinimiyle eşleşmelidir. Ayrıca Tier bir tesis topolojisi ve sertifikasyon çerçevesidir; uygulamanın hatasız olduğunu, veri replikasyonunu veya kurumun DR planını sertifikalandırmaz. Pre-Sales müşterinin resmî sertifikasını görmeden “Tier III benzeri” ifadeyi sertifika gibi kullanmaz.

Hata alanı, tek bir olaydan birlikte etkilenebilecek bileşenler grubudur. Sınır; cihaz, şasi, rack, enerji hattı, switch, kablo güzergâhı, cluster, storage pool, yönetim düzlemi, oda, bina, kampüs, telekom taşıyıcısı veya insan/operasyon süreci olabilir. Diyagramda iki yol çizilmiş olması fiziksel ve mantıksal bağımsızlığı kanıtlamaz. İki fiber aynı kanalizasyon hattından geçebilir; iki DNS sunucusu aynı sanallaştırma cluster’ında olabilir; iki site aynı kimlik veya yönetim servisine bağımlı olabilir; iki operatör aynı hatalı runbook’u uygulayabilir. Hata alanı analizi için senaryo seç, etkilenen ortak öğeyi işaretle, algılama–karar–geçiş–doğrulama zincirini yaz ve kalan kapasitenin yoğun yükü taşıyıp taşımadığını ölç. “N+1” gibi etiketler yalnız hangi kapasite biriminde ve hangi koşulda tanımlandığıyla anlamlıdır.

Dayanıklılık tasarımının kanıtı kontrollü test ve gerçek olay öğrenmesidir. Test, yalnız ikinci düğüme ping atmak veya replikasyonun “yeşil” görünmesi değildir. Başlangıç koşulları, tetiklenen arıza, beklenen otomatik veya manuel davranış, karar sahibi, süre ölçüm noktaları, veri tutarlılığı kontrolü, kullanıcı kabul işlemi, geri dönüş ve gözlenen sapmalar kaydedilir. Masa başı egzersizi sorumluluk ve iletişim boşluklarını; bileşen testi teknik geçişi; hizmet testi uçtan uca sonucu; site senaryosu daha geniş bağımlılıkları gösterir. Üretim riski nedeniyle test kapsamı aşamalı ve onaylı yürütülür. Başarısız test kötü haber değil, kontrollü ortamda bulunan mimari bilgidir. Test yapılmadığı hâlde pazarlama terimini güvence gibi kullanmak ise saklı risktir.

Arven yönetimi “iki veri merkezimiz olduğuna göre sipariş portalı kesintisizdir” varsayımıyla yeni yatırım bütçesini azaltmak istiyor. İstanbul ve Ankara arasında veri replikasyonu var; fakat iş birimi RTO/RPO’yu onaylamamış, uygulama başlatma sırası dağınık notlarda, iki sitenin kimlik ve DNS yönetimi İstanbul’a bağımlı. Üstelik replikasyon hatalı veya şifrelenmiş veriyi de karşı tarafa taşıyabilir; bu nedenle replikasyon bağımsız backup ve temiz kurtarma kanıtının yerini tutmaz. Pre-Sales önce iş etki oturumu yapar: sipariş kaybı toleransı, yoğun sezon kesintisi, manuel sipariş alma kapasitesi, yeniden işleme süresi ve kabul işlemi belirlenir. Ardından hedefler teknik zincire çevrilir; hangi yerel arızanın HA, hangi geniş olayın DR, hangi veri olayının backup/restore ile yönetileceği ayrılır.

Arven için tek bir “en yüksek koruma” seviyesi yerine hizmet sınıfları önerilir. Bayi sipariş portalı ve kimlik servisi daha kısa hedeflere, raporlama ve arşiv daha uzun hedeflere sahip olabilir. İstanbul’da planlı bakım yolu, host/rack/network/storage hata alanları ve kalan kapasite sınanır. Ankara kurtarmasında yönetim erişimi, DNS, güvenlik politikası, veri tutarlılığı, uygulama sırası ve kullanıcı kabulü runbook’a girer. Her hedefin maliyet ve operasyon yükü açık yazılır. Resmî Tier sertifikası varsa kapsamı belgelenir; yoksa tesis topolojisi bağımsız teknik review konusu yapılır ve sertifika ima edilmez. Karar, “iki site var” cümlesinden ölçülebilir hizmet hedefi, arıza senaryosu ve test takvimine dönüşür.