Bulut, Sunucu ve Yönetilen BT
Bulut Sunucularda Yüksek Erişilebilirlik Nasıl Tasarlanır?
Yüksek erişilebilirlik, yedek sunucu eklemekten fazlasıdır. Hata noktalarını, veri katmanını, trafik yönetimini ve kurtarma testlerini birlikte ele alan bir mimari rehberi.
Yüksek erişilebilirlik bir sistem özelliğidir
Bulut sunucularda yüksek erişilebilirlik, bir bileşen arızalandığında hizmetin kabul edilebilir düzeyde çalışmayı sürdürmesini amaçlar. Aynı uygulamayı başka bir sunucuya kurmak bu hedefin yalnızca bir parçasıdır. İsteklerin sağlıklı sunucuya yönlendirilmesi, verinin erişilebilir kalması ve operasyon ekibinin sorunu doğru teşhis etmesi de gerekir. Birbirine bağımlı katmanlardan biri çalışmıyorsa kullanıcı açısından hizmet yine kesilmiş olabilir.
Bulutta çalışmak, uygulamayı kendiliğinden kesintiye dayanıklı yapmaz. Sağlayıcının altyapı özellikleriyle kurumun yapılandırma ve işletim sorumluluklarını ayrı değerlendirin. Sanal makinenin yeniden başlatılması yararlı olsa da uygulamanın açılması ve yeniden trafik alması sırasında kullanıcılar etkilenebilir. Tasarımın odağı yalnızca makinenin ayakta olması değil, kullanıcının işini tamamlayabilmesidir.
Bu nedenle işe ürün seçerek değil, kritik iş akışlarını tanımlayarak başlayın. Sipariş oluşturma, çalışan girişi ve belge yükleme aynı öncelikte olmayabilir. Kesinti sırasında hangi işlevlerin korunacağını, hangilerinin geçici olarak sınırlandırılabileceğini belirleyin. Böylece bütçeyi her bileşeni aynı düzeyde çoğaltmak yerine gerçek iş riskine yönlendirebilirsiniz.
Öne çıkanlar
İş gereksinimlerini ölçülebilir hedeflere çevirin
Mimari kararları kabul edilebilir kesinti ve veri kaybı üzerinden verin. Hedefler belirlenmeden çalışma modeli seçmek, gereksiz maliyete veya yetersiz korumaya yol açabilir. Operasyon, finans ve iş birimlerini değerlendirmeye katın; raporların gecikmesiyle sipariş kaydının kaybolması aynı etkiyi yaratmaz. Hedefleri tasarımın kabul ölçütleri olarak kaydedin ve test sonuçlarıyla karşılaştırın. Ölçümün başlangıcını ve bitişini de açıkça tanımlayın. Arızanın oluşması, alarmın üretilmesi ve kullanıcının yeniden işlem tamamlayabilmesi farklı anlardır. Bu ayrım, toparlanma süresinin yalnızca teknik bir bileşenin açılışıyla sınırlı değerlendirilmesini önler ve iyileştirme alanlarını görünür kılar. Gereksinimler değiştiğinde hedefleri yeniden gözden geçirin. İşlevler arasında öncelik farkı varsa hedefleri de buna göre ayırın. Bütün uygulamayı tek bir erişilebilirlik ölçüsüyle değerlendirmek, kritik bir işlemin yaşadığı sorunu genel ortalamaların içinde gizleyebilir. Hedeflerin kim tarafından onaylandığını ve hangi koşullarda değiştirileceğini de belgeleyin; teknik ekip ile iş birimleri aynı beklentiyle hareket etsin.
Hizmet düzeyi hedefi
Başarılı işlem oranını, yanıt süresini ve kullanılabilirliği kullanıcı deneyimine göre tanımlayın. Ölçümün kapsadığı uç noktalar ve başarısız sayılan işlemler açık olsun. Sunucunun yanıt vermesi, iş işleminin tamamlandığını göstermez.
Kurtarma hedefleri
RTO, hizmetin yeniden çalışır duruma getirilmesi için hedeflenen süreyi; RPO ise kabul edilebilir veri kaybının zaman cinsinden sınırını ifade eder. Bu hedefler çoğaltma yöntemini ve kurtarma planını etkiler.
İşletim bütçesi
Yedek kapasitenin yanında veri aktarımı, depolama, izleme ve bakım yükünü hesaplayın. Ekibin yönetemeyeceği karmaşıklık yeni hata kaynakları yaratabilir; sade ve test edilen bir tasarımı tercih edin.
Uygulama süreci
Tek hata noktalarını uçtan uca bulun
Tek hata noktası, arızalandığında hizmeti durduran ve işlevini devralacak alternatifi bulunmayan bileşendir. İncelemeyi sunucu listesiyle sınırlamayın. Kullanıcının işlem yolunu ve ekibin kurtarma sırasında ihtiyaç duyacağı araçları birlikte değerlendirin. Yanlış bir ağ kuralı gibi yapılandırma hataları, bütün kopyaları aynı anda erişilemez hale getirebilir. Çalışmanın sonunda yalnızca bileşen listesi değil, sorumluları belli bir risk haritası oluşmalıdır. Her riskin etkilediği işlevi ve karşı önlemini kaydedin. Kurtarma araçlarına, erişim bilgilerine ve operasyon yönergelerine ana ortam kullanılamadığında nasıl ulaşılacağını da sınayın. Müdahalenin yalnızca belirli kişilerin bilgisine bağlı kalmasını önleyin; erişim ve sorumlulukları önceden netleştirin. Bağımlılık haritasını altyapı değişikliklerinden sonra güncelleyin. Yeni bir kimlik sağlayıcısı, dosya hizmeti veya ağ geçidi eklenmesi, daha önce bulunmayan bir kesinti riski yaratabilir. Karşı önlemi olmayan bağımlılıkları da görünür tutun; gerektiğinde ilgili işlevi geçici olarak sınırlandırmak, teknik çoğaltmadan daha gerçekçi bir seçenek olabilir. Bu kararın kullanıcıya nasıl yansıyacağını da belgeleyin.
- 01
İstek yolunu çizin
DNS, yük dengeleyici, uygulama, veri tabanı, depolama ve dış servisleri haritalayın. Kimlik doğrulama, sertifika yenileme ve gizli bilgi yönetimi gibi arka plandaki bağımlılıkları da ekleyin.
- 02
Ortak bağımlılıkları sorgulayın
Ayrı sunucuların aynı disk, ağ geçidi veya kullanılabilirlik alanına bağlı olması ortak kesinti riski yaratabilir. Sağlayıcının hata alanlarını ve servislerin bu alanlar arasındaki davranışını dokümantasyondan doğrulayın.
- 03
Kalan kapasiteyi sınayın
Bir sunucu veya alan devre dışı kaldığında kalan kaynakların yükü taşıdığını doğrulayın. Otomatik ölçeklemede kaynak kotalarını, başlatma süresini ve bağımlılık limitlerini hesaba katın.
Karşılaştırma
Yerleşim seçeneğini çalışma modelinden ayırın
Çoklu kullanılabilirlik alanı: Aynı bölgedeki ayrı hata alanlarına dağıtım hedeflenir.
Çoklu bölge: Bölgesel kesintilere hazırlık sağlar; veri çoğaltma, yönlendirme ve operasyon yükü ayrıca planlanır.
Aktif-aktif: Çalışan kopyalar trafik işler. Oturum yönetimi, veri tutarlılığı ve arıza sonrası kapasite tasarlanmalıdır.
Aktif-pasif: Bekleyen ortam gerektiğinde devreye girer. Güncelliği, geçiş koşulları ve hazır olma durumu test edilmelidir.
Öne çıkanlar
Veri katmanının kurtarma davranışını ayrıca tasarlayın
Veri tabanı, kuyruk ve dosya hizmetleri geçmiş durumu korur. Bu bileşenlerde kopya oluşturmak kadar hangi kopyanın yetkili olduğu da önemlidir. Yönetilen servislerde otomatik geçişin kapsamını, istemciden beklenen davranışı ve yedekleme seçeneklerini doğrulayın. Yüksek erişilebilirliği tamamlamak için [yedekleme ve felaket kurtarma](/yedekleme-ve-felaket-kurtarma) gereksinimlerini başlangıçta ele alın. Kuyrukta bekleyen bir mesaj yeniden işlenebilir; önbellek kaybı ise veri tabanına ek yük bindirebilir. Her bileşenin kurtarma davranışını ayrı belgeleyin. Böylece bir geçiş sırasında yalnızca veri tabanının değil, bütün işlem zincirinin nasıl davranacağı anlaşılır. Geri yüklenen verinin uygulamayla gerçekten kullanılabildiğini doğrulamak da bu çalışmanın parçasıdır. Veri katmanında başarı ölçütü yalnızca bağlantının yeniden kurulması değildir. Geçiş öncesinde başlatılan işlemlerin sonucu, eksik kayıtlar ve olası tekrarlar da incelenmelidir. Uygulama ekibiyle veri sorumluları aynı senaryoyu birlikte değerlendirsin; böylece altyapı açısından başarılı görünen bir geçişin iş verisi üzerindeki etkisi gözden kaçmaz ve belirsizlikler erken belirlenir.
Çoğaltma yöntemini anlayın
Eşzamanlı ve eşzamansız çoğaltma; gecikme, kullanılabilirlik ve veri kaybı açısından farklı sonuçlar doğurabilir. Çoğaltma gecikmesini izleyin ve geçiş sonrasında hangi verinin korunduğunu test edin.
Yazma yetkisini yönetin
Tek yazarlı tasarımlarda ağ bölünmesinin birden fazla düğümü bağımsız yazıcıya dönüştürmesini önleyecek mekanizmaları doğrulayın. Birincil değiştiğinde bağlantı havuzlarını ve işlem tekrarlarını birlikte sınayın.
Yedeklemeyi ayrı koruma olarak görün
Yanlış silme veya veri bozulması diğer kopyalara da taşınabilir. Çoğaltmayı yedekleme yerine koymayın; bağımsız yedekleri ve uygulamayla kullanılabilir geri yükleme sonuçlarını doğrulayın.
Uygulama süreci
Otomatik geçişi kontrollü kesinti testleriyle doğrulayın
Mimari diyagram, geçişin gerçekten çalıştığını göstermez. Testleri önce uygun bir deneme ortamında yürütün; üretimdeki doğrulamaları etki alanı sınırlandırılmış bir planla gerçekleştirin. Sunucu kapanmasının yanında bağlantı yavaşlaması ve dış servis kesintisi gibi senaryoları da değerlendirin. Amaç yedek bileşenin açılması değil, kullanıcı işlemlerinin hedeflenen şekilde sürmesidir. Test kayıtlarında arızanın algılanmasını, geçiş kararını ve hizmetin toparlanmasını ayrı aşamalar olarak izleyin. Böylece gecikmenin izleme sisteminden, otomasyondan veya uygulamanın hazırlanmasından kaynaklandığı anlaşılır. Yeniden başlatmalarla yeniden denemelerin birbirini tetikleyerek yükü artırmadığını kontrol edin. Beklenen davranış gerçekleşmezse testin yanında tasarım varsayımını da güncelleyin. Testin kapsamı kadar güvenli biçimde sonlandırılması da önemlidir. Etki beklenen sınırları aştığında kimin karar vereceğini ve hangi geri alma adımının uygulanacağını önceden belirleyin. Sonuçları yalnızca başarılı veya başarısız olarak sınıflandırmayın; kullanıcı etkisini, veri durumunu ve müdahale sırasında yaşanan belirsizlikleri de kaydedin. Düzeltmeleri doğrulamak için aynı senaryoyu tekrar çalıştırın.
- 01
Senaryoyu ve sınırları belirleyin
Beklenen davranışı, test sorumlusunu, etkilenecek bileşenleri ve kabul edilemez etkide testi durduracak koşulları yazın. Geri alma yolunun uygulanabilir olduğundan emin olun.
- 02
Kullanıcı işlemleriyle ölçün
Kontrollü arıza sırasında giriş, okuma ve yazma akışlarını çalıştırın. Alarmı, trafik değişimini ve işlem sonuçlarını gözlemleyin. Eksik veya yinelenen kayıtları ayrıca kontrol edin.
- 03
Normal çalışmaya dönüşü sınayın
Arızalı bileşenin yeniden katılımını, veri eşitlenmesini ve kapasitenin toparlanmasını doğrulayın. Bulguları sorumlulara atayın; düzeltmelerden sonra aynı senaryoyu tekrar çalıştırın.
Kontrol listesi
Devreye alma ve günlük işletim için son kontrol
Kesintiye dayanıklılık ilk kurulumdan sonra da korunmalıdır. Yeni sürüm, güvenlik kuralı veya büyüyen veri hacmi önceki varsayımları geçersiz kılabilir. Son kontrolü altyapı, uygulama ve veri sorumlularıyla birlikte yapın. Ertelenen riskleri sorumlusu, gerekçesi ve iş etkisiyle kaydedin; kontrol listesini önemli değişikliklerden sonra yeniden değerlendirin. Altyapı ekranları sağlıklı görünse bile kullanıcı işlemlerinin tamamlandığını dışarıdan yapılan kontrollerle doğrulayın. Müdahale yönergelerini ve ekip erişimlerini güncel tutun; alarmın kime ulaşacağı ve ilk adımın ne olacağı kesinti anında belirsiz kalmasın. Altyapı ve uygulama değişikliklerini aynı kabul sürecinde değerlendirin. Bir dağıtımın başarıyla tamamlanması, geçiş ve kurtarma davranışının korunduğu anlamına gelmez. Özellikle ağ kuralları, veri şeması ve erişim yetkileri değiştiğinde ilgili senaryoları yeniden inceleyin. Önceki test sonuçlarını yeni yapılandırma için otomatik olarak geçerli saymayın; gerekli doğrulamaları planlayın. Kontrol listesini yalnızca onay toplamak için kullanmayın. Her maddenin hangi riski azalttığını ve hangi kanıtla tamamlandığını belirtin. Test kaydı, güncel bir müdahale yönergesi veya doğrulanmış geri yükleme sonucu, sorumluların aynı durumu değerlendirmesine yardımcı olur. Eksikler kapatıldığında ilgili belgeleri de güncelleyin; işletim bilgisi ortamın gerisinde kalmasın.
- ✓
Yapılandırma ve dağıtım
Altyapı tanımlarını sürümleyin, ortam farklarını izleyin ve yeni sürümü kontrollü trafikle doğrulayın. Geri alma yolunun veri şeması değişiklikleriyle uyumunu kontrol edin.
- ✓
İzleme ve müdahale
Kaynak tüketiminin yanında hata oranını, gecikmeyi ve kritik işlem başarısını izleyin. Her alarm için sorumlu, ilk kontrol adımı ve gerektiğinde izlenecek müdahale yolu belli olsun.
- ✓
Kapasite ve kurtarma
Eksik kapasiteyle çalışma, yedekten geri yükleme ve arıza sonrası dönüş sonuçlarını kaydedin. Kritik açıklar çözülmeden mimariyi tamamlanmış kabul etmeyin.
Tasarımı kurumun operasyon kapasitesiyle eşleştirin
İyi bir yüksek erişilebilirlik tasarımı, hata noktalarını azaltırken ekibin yönetebileceği bir yapı kurar. Kritik işlem yollarını çıkarın, hedeflerinizi belirleyin ve en büyük kesinti risklerini önceliklendirin. Uygulama çoğaltma, trafik yönetimi, veri koruma ve test adımlarını birbirine bağlı bir plan olarak ele alın. Her ek bileşenin hangi riski azalttığını açıklayabilmelisiniz.
Bikare ile planlama yaparken [bulut altyapı ve buluta geçiş hizmetleri](/bulut-altyapi-ve-buluta-gecis-hizmetleri) kapsamında ele alınacak değerlendirme ve mimari ihtiyaçlarını netleştirin. İzleme, bakım ve müdahale beklentilerini ise [BT bakım ve teknik destek hizmetleri](/bt-bakim-ve-teknik-destek-hizmetleri) görüşmelerinde gündeme alın. Hizmet kapsamını varsaymak yerine sorumluluk paylaşımını ve test beklentilerini keşif aşamasında açıklığa kavuşturun.
Sonuçta yüksek erişilebilirlik, yalnızca yedek sunucu bulundurmak değil; arızanın nasıl algılanacağını, hizmetin nasıl sürdürüleceğini ve normal çalışmaya nasıl dönüleceğini bilmektir. Başarıyı kaynak sayısıyla değil, gerçekçi kesinti senaryolarında gözlenen kullanıcı etkisiyle değerlendirin. Mimari kararları ölçüm, düzenli test ve güncel operasyon yönergeleriyle destekleyin.
Mimariyi yaşayan bir plan olarak ele alın. Yeni bağımlılıklar, değişen iş öncelikleri ve test bulguları sonraki kapasite kararlarına yansımalıdır. Ekip üyelerinin aynı belgelere erişebilmesi ve sorumlulukların açık olması, sürekliliğin belirli kişilerin deneyimine bağlı kalmasını azaltır. Böylece yüksek erişilebilirlik, kurulum hedefi olmaktan çıkıp günlük işletimin bir parçasına dönüşür.
Keşfetmeye devam et
İlgili içerik ve hizmetler
Konuyu tamamlayan Bikare içeriklerine göz atın.
