Bulut Sunucu Seçerken Yüksek Erişilebilirlik Nasıl Değerlendirilir?

Bulut sunucu, fiziksel bir makinenin arızalanamayacağı anlamına gelmez. Yüksek erişilebilirlik; işlemci, depolama, ağ ve uygulama katmanlarında hangi yedekliliğin bulunduğuna bağlıdır. Tek bir sanal sunucu çalıştırmak basit bir başlangıç olabilir; ancak kritik bir uygulamada sağlayıcının altyapı davranışını, kurtarma seçeneklerini ve sizin kuracağınız yedekli yapıyı ayrı ayrı değerlendirmek gerekir.

Bulut sunucu ile yüksek erişilebilirlik aynı şey değildir

Bulut sunucu genellikle sanallaştırılmış işlem gücü, bellek, disk ve ağ kaynaklarının bir altyapı havuzundan sunulduğu bir hizmettir. Fiziksel ana makine arızalandığında sanal sunucunun başka bir ana makinede yeniden başlatılabilmesi mümkün olabilir; fakat bu davranışın otomatik olup olmadığı, yeniden başlatmanın ne kadar süreceği ve çalışan oturumların korunup korunmadığı sağlayıcının mimarisine bağlıdır.

Bu nedenle “altyapı yedekli” ifadesini uygulamanın kesintisiz çalışacağı şeklinde yorumlamayın. Tek bulut sunucunuzun işletim sistemi bozulabilir, uygulama verisi hatalı bir işlemle değişebilir veya aynı sanal makineye bağlı bir disk erişilemez hale gelebilir. Yedeklilik, arızanın türüne ve hangi katmanda oluştuğuna göre farklı sonuç verir.

Yedekliliği katmanlara ayırarak inceleyin

Önce uygulamanızın hangi kesintiyi tolere edebildiğini belirleyin. Trafiği kritik olmayan bir yönetim panelinde kısa süreli yeniden başlatma kabul edilebiliyorsa tek bulut sunucu ve düzenli yedek yeterli olabilir. Sipariş alan bir uygulamada ise yalnızca sunucunun yeniden açılması yetmez; veritabanı, dosyalar, DNS ve trafik yönlendirmesi de birlikte ele alınmalıdır.

• İşlem katmanı: Sanal makinenin fiziksel ana makine arızasında otomatik taşınıp taşınmadığını ve bunun yeniden başlatma mı yoksa canlı taşıma mı olduğunu öğrenin. Canlı taşıma, her arızada verinin kayıpsız korunacağı anlamına gelmez.
• Depolama katmanı: Disklerin tek fiziksel noktaya mı, yoksa birden fazla depolama bileşenine mi dayandığını sorun. Kopyalı depolama altyapısı sunucu yedeğinin yerini tutmaz; yanlışlıkla silinen veriyi geri getirmek için ayrıca sürümlemeli yedek gerekir.
• Ağ ve erişim katmanı: İkinci bir sanal sunucuya geçişte IP, DNS veya yük dengeleme davranışının nasıl değişeceğini kontrol edin. Ağ yedekliliği, uygulamanın yeni sunucuya otomatik yönlendirileceğini garanti etmez.
• Uygulama ve veri katmanı: İki sunucu aynı anda çalışacaksa oturumların, yüklenen dosyaların ve veritabanı yazmalarının nasıl eşitleneceğini tasarlayın. Bu ayrıntı çözülmemişse ikinci sunucu yalnızca çalışıyor görünür, fakat tutarlı hizmet veremeyebilir.

İhtiyaca uygun mimariyi nasıl seçersiniz?

İş yükünüz tek sunucuda çalışıyor, kısa bir bakım kesintisi kabul ediliyor ve düzenli geri yükleme testi yapabiliyorsanız, yüksek otomasyonlu bir tekil bulut sunucusu makul olabilir. Bu durumda seçiminiz; hızlı geri yükleme, izleme, anlık görüntü ve ayrı yedekleme seçeneklerine dayanmalıdır. Ancak kesinti maliyeti yükseliyorsa, yalnızca daha büyük bir sunucuya geçmek sorunu çözmez; çünkü daha fazla kaynak, tek hata noktasını ortadan kaldırmaz.

Uygulama iki sunucuda çalışabiliyor, veritabanı çoğaltması destekleniyor ve trafik bir yük dengeleyici üzerinden dağıtılabiliyorsa, birden fazla bulut sunucusu daha uygun bir yapı oluşturabilir. Buna karşılık uygulama yerel diskteki geçici olmayan dosyalara ve tek bir IP adresine sıkı biçimde bağlıysa, doğrudan çoklu sunucuya geçmek yerine önce dosya depolama, oturum ve DNS geçiş planını çözmek gerekir.

Örneğin diyelim ki bir şirketin ürün kataloğu gün içinde okunuyor, fakat siparişler ayrı bir sistemde tutuluyor ve birkaç dakikalık kesinti kabul ediliyor. Bu durumda tek bulut sunucusu, ayrı yedek ve belgelenmiş geri yükleme prosedürüyle gereksiz bir çoklu sunucu karmaşasından kaçınabilir. Aynı uygulama anlık sipariş alıyor ve kesinti doğrudan gelir kaybına yol açıyorsa, ikinci sunucu ile veri katmanının birlikte tasarlanması daha anlamlıdır; yalnızca aynı uygulama dosyalarını iki makineye kopyalamak yeterli değildir.

İlk değerlendirmede uygulanacak kontrol akışı

Hizmeti satın almadan veya mevcut yapıyı büyütmeden önce sağlayıcının panelinde ve teknik dokümantasyonunda şu akışı uygulayın. Her yanıtı yazılı olarak kaydedin; çünkü “bulut” adı farklı hizmetlerde farklı kurtarma davranışlarını ifade edebilir.

1. Arıza senaryosunu tanımlayın: Ana makine, disk, ağ veya işletim sistemi arızasından hangisini değerlendirdiğinizi yazın. Sağlayıcının bu senaryoda otomatik yeniden başlatma, başka ana makineye alma veya yalnızca manuel kurtarma sunduğunu ayırın.
2. Geri yükleme kaynağını kontrol edin: Anlık görüntü, yedek ve çoğaltılmış disk seçeneklerini ayrı ayrı inceleyin. Yedek farklı bir hata alanında tutulmuyorsa, aynı altyapı arızasında ona da erişilemeyebileceğini varsayın.
3. Test ortamında geri dönüş deneyin: Üretim verisini değiştirmeden küçük bir test sunucusunda yedekten geri yükleme başlatın. Beklenen sonuç, uygulamanın açılması kadar dosyaların, veritabanı bağlantısının ve yapılandırmanın tutarlı olmasıdır. Sadece sanal makinenin açılması yeterli kanıt değildir.
4. Geçiş bağımlılıklarını listeleyin: DNS TTL değeri, sabit IP kullanımı, oturum saklama, dosya yükleme ve veritabanı bağlantılarını kontrol edin. İkinci sunucuya geçişte bunlardan biri manuel işlem gerektiriyorsa, kurtarma süresine o adımı da ekleyin.
5. Kabul ölçütü belirleyin: Planlı testte hangi URL'nin açılacağı, yeni verinin yazılacağı ve yedekten hangi zaman noktasına dönüleceği önceden tanımlı olsun. Test başarısızsa üretime geçmek yerine eksik katmanı düzeltin; örneğin uygulama açılıyor fakat yüklenen dosyalar görünmüyorsa sorun işlem gücünden çok ortak depolama tasarımındadır.

Sonraki adım olarak, tek sunucu mu yoksa çoklu sunucu mu gerektiğini seçmeden önce sağlayıcının kurtarma davranışını ve kendi uygulamanızın veri bağımlılıklarını aynı belgede karşılaştırın. Farklı hizmet seçeneklerini incelemek için sunucu kiralama çözümleri sayfasını kullanabilirsiniz; teknik kararınızı yine ilgili hizmetin güncel dokümantasyonuyla doğrulayın.