Tek sunucuyla çalışan her sistemin ortak bir zaafı vardır: o sunucu durduğunda hizmet de durur. Donanım arızası, işletim sistemi çökmesi, bakım penceresi veya hatalı bir güncelleme — hepsi tam kesinti anlamına gelir. Yüksek erişilebilirlik, bu tekil arıza noktasını ortadan kaldırma disiplinidir.
Bu yazı, fiziksel (dedicated) sunucular ile çoklu sunucu mimarisine geçişin nasıl planlanacağını ve hangi katmanların yedeklenmesi gerektiğini anlatıyor.
Önce Şu Soruyu Cevaplayın
Yüksek erişilebilirlik pahalıdır: en az iki katı donanım, daha karmaşık bir mimari ve daha fazla yönetim yükü getirir. Bu maliyeti üstlenmeden önce tek bir soruyu netleştirin:
Bir saatlik kesinti size ne kaybettirir?
Cevap somut bir tutarsa, o tutarı yıllık kesinti beklentinizle çarpın ve çoklu yapının yıllık ek maliyetiyle karşılaştırın. Bu hesap, kararı duygusal olmaktan çıkarır. Kurumsal bir tanıtım sitesinde bir saatlik kesintinin maliyeti düşükken, aktif bir e-ticaret sitesinde aynı süre ciddi bir gelir kaybıdır — ve iki durum farklı mimariler gerektirir.
Yedeklenmesi Gereken Katmanlar
"İki sunucu aldım, artık yüksek erişilebilirim" düşüncesi eksiktir. Bir sistemin tekil arıza noktaları katman katman ele alınmalıdır:
| Katman | Tekil arıza noktası | Çözüm |
|---|---|---|
| Uygulama sunucusu | Tek makine | Yük dengeleyici arkasında en az iki sunucu |
| Yük dengeleyici | Dengeleyicinin kendisi | İki dengeleyici + yüzen IP |
| Veritabanı | Tek veritabanı sunucusu | Çoğaltma (replication) + devralma |
| Dosya depolama | Yüklemeler tek sunucuda | Paylaşımlı depolama veya nesne deposu |
| Oturum verisi | Sunucu belleğinde | Merkezi oturum deposu |
| DNS | Tek ad sunucusu | Yedekli DNS servisi |
Zincirin en zayıf halkası, tüm zincirin dayanıklılığını belirler. Uygulama sunucularınızı çoğaltıp veritabanını tek bırakırsanız, veritabanı sunucusu durduğunda sistem yine durur.
En Zor Kısım: Durum Yönetimi
Birden fazla sunucuya trafik dağıtmak teknik olarak kolaydır. Zor olan, uygulamanın durumunu (state) yönetmektir.
Oturumlar
Kullanıcı A sunucusunda giriş yapıp bir sonraki isteği B sunucusuna düşerse, oturum bilgisi orada olmadığı için sistem onu çıkış yapmış sayar. Bu, çoklu sunucu mimarisine geçen sistemlerin ilk karşılaştığı sorundur.
İki çözüm vardır: kullanıcıyı hep aynı sunucuya yönlendirmek (yapışkan oturum) veya oturumları tüm sunucuların eriştiği merkezi bir depoda tutmak. İkincisi doğru çözümdür — yapışkan oturumda o sunucu durduğunda oradaki tüm kullanıcılar oturumunu kaybeder ve yük dağılımı da dengesizleşir.
Yüklenen Dosyalar
Kullanıcı A sunucusuna bir görsel yüklerse, B sunucusuna düşen bir istek o görseli bulamaz. Çözüm, yüklemeleri sunucuların yerel diskinde değil paylaşımlı bir depolamada veya nesne deposunda tutmaktır. Bu değişiklik uygulama kodunda düzenleme gerektirebilir ve geçiş planında en çok emek isteyen kalem genellikle budur.
Önbellek
Her sunucunun kendi yerel önbelleği varsa, içerik güncellendiğinde bazı sunucular eski içeriği sunmaya devam eder. Merkezi bir önbellek deposu veya tüm sunuculara ulaşan bir temizleme mekanizması gerekir.
Veritabanı Yedekliliği
En kritik ve en dikkat gerektiren katman burasıdır, çünkü veri tutarlılığı devreye girer.
- Ana-yedek çoğaltma: Yazma işlemleri ana sunucuya gider, yedek sunucu sürekli senkronize olur. Ana sunucu durduğunda yedek devralır. En yaygın ve en anlaşılır düzendir. Devralmanın otomatik mi elle mi olacağına karar vermeniz gerekir — otomatik devralma hızlıdır ama yanlış tetiklenirse iki sunucunun aynı anda ana olduğu tehlikeli bir duruma yol açabilir.
- Okuma çoğaltması: Yazma tek sunucuda kalır, okuma sorguları birden fazla kopyaya dağıtılır. Okuma ağırlıklı sistemlerde performansı belirgin biçimde artırır ama yazma tarafı hâlâ tekil arıza noktasıdır.
Her iki düzende de dikkat edilecek nokta çoğaltma gecikmesidir: yedek sunucu ana sunucudan birkaç saniye geride olabilir. Kullanıcı bir kayıt oluşturup hemen listeye baktığında, sorgu yedek sunucuya düşerse kaydı göremeyebilir. Uygulamanın bu davranışı hesaba katması gerekir.
Aşamalı Geçiş Yolu
Tek sunucudan tam yedekli mimariye tek adımda geçmek gerekmez. Kazanç/emek oranına göre sıralı bir yol:
- Durumu dışarı çıkarın: Oturumları merkezi depoya, yüklemeleri paylaşımlı depolamaya taşıyın. Bu adım henüz yedeklilik getirmez ama sonraki her adımı mümkün kılar — ve tek başına yapılabilir.
- Veritabanını ayırın: Veritabanını uygulama sunucusundan ayrı bir makineye alın. Böylece uygulama sunucusunu çoğaltmak mümkün hale gelir.
- İkinci uygulama sunucusunu ekleyin: Yük dengeleyici arkasına ikinci sunucuyu koyun. Artık uygulama katmanında yedeklisiniz.
- Veritabanı çoğaltmasını kurun: Ana-yedek düzeni kurun ve devralma prosedürünü yazın.
- Yük dengeleyiciyi yedekleyin: İkinci dengeleyici ve yüzen IP ile son tekil arıza noktasını da kapatın.
Her adım bağımsız bir kazanç sağlar ve bir sonrakini kolaylaştırır. Birinci adım özellikle değerlidir: tek sunucuda kalsanız bile, durumu dışarı çıkarmış bir uygulama taşınması ve yeniden kurulması çok daha kolay bir uygulamadır.
Devralmayı Test Edin
Kurulmuş ama hiç test edilmemiş bir devralma mekanizması, çalışacağı varsayılan bir mekanizmadır. Planlı bir bakım penceresinde ana sunucuyu bilinçli olarak durdurun ve şunları ölçün: devralma gerçekleşti mi, ne kadar sürdü, kullanıcılar ne yaşadı, veri kaybı oldu mu?
Bu testte tipik olarak ortaya çıkan bulgular şunlardır: devralma sonrası elle müdahale gerektiren bir adım, kimsenin fark etmediği bir yapılandırma farkı ve beklenenden uzun süren bir geçiş. Bunları planlı testte öğrenmek, gerçek arıza anında öğrenmekten kıyaslanamayacak kadar iyidir.
Sonuç
Yüksek erişilebilirlik, sunucu sayısını artırmakla değil tekil arıza noktalarını tek tek kapatmakla elde edilir. En zor kısım donanım değil, uygulamanın durumunu sunuculardan ayırmaktır — ve bu adım, çoklu yapıya geçmeseniz bile değerlidir. Kararı vermeden önce bir saatlik kesintinin maliyetini hesaplayın; o sayı, bu mimarinin size gerekip gerekmediğini net biçimde söyler.
Sıkça Sorulan Sorular (SSS)
İki sunucu almak yüksek erişilebilirlik sağlar mı?
Tek başına hayır. Veritabanı, dosya depolama ve oturum yönetimi hâlâ tekil arıza noktalarıysa, ikinci uygulama sunucusu yalnızca yük dağıtımı sağlar. Yedeklilik, tüm katmanlarda tekil arıza noktasının kapatılmasıyla oluşur.
Otomatik devralma kurmalı mıyım?
Kesinti toleransınız düşükse evet, ama dikkatli kurun. Yanlış tetiklenen bir otomatik devralma, iki sunucunun aynı anda kendini ana sanması gibi ciddi veri tutarsızlığı senaryolarına yol açabilir. Ölçülü bir alternatif, hızlı ve iyi belgelenmiş bir elle devralma prosedürüdür.
Yüksek erişilebilirlik maliyeti ne kadar artırır?
En az iki katı donanım, artı yük dengeleyici ve paylaşımlı depolama. Buna yönetim karmaşıklığının getirdiği emek de eklenir. Bu yüzden karar, kesinti maliyeti hesabına dayanmalıdır — her sistem bu yatırımı hak etmez.
Çoğaltma gecikmesi sorun yaratır mı?
Okuma sorguları yedek sunucuya dağıtılıyorsa yaratabilir: yeni yazılan bir kayıt, henüz senkronize olmamış bir kopyadan okunduğunda görünmez. Kritik akışlarda (sipariş sonrası ekran gibi) okumayı ana sunucuya yönlendirmek yaygın bir çözümdür.
