İki uygulama sunucusu aynı arıza nedenini paylaşabilir

İkinci bir uygulama sunucusu, arızalanan sürecin görevini üstlenebilir. Müşterinin çalışmaya devam edebilmesi ise ortak kullanılan bileşenlere de bağlıdır. Bu nedenle sonraki yatırım, yalnız sunucu sayısını artırmak yerine belirlenmiş bir arızayı karşılamalıdır.

Microsoft, kritik akışlarda işlem gücü, veri ve ağ katmanlarının yedeklilik açısından birlikte ele alınmasını önerir. Uygulama katmanını ikiye çıkarmak, bütün akışın durumunu henüz açıklamaz.

Ortak yolu görünür kılmak

Kurgusal örnekte müşteriler bir proje listesi açar. Ayrı sanal makinelerdeki iki uygulama örneği bunun için aynı veritabanını okur. Önlerinde tek bir yük dengeleyici vardır ve ekip tarafından işletilir. İstekleri dağıtır; burada kendi içinde yedekli çalışan yönetilen bir erişim hizmeti kastedilmez. Çalışmayı sürdürmek için gereken oturum verisi yalnız tek bir uygulama örneğinde tutulmaz.

Tablodaki kimlikler yalnız bu örneğe aittir. Başlangıçta veritabanı veya yük dengeleyicinin yerine geçecek bir bileşen yoktur. Tablo beklenen etkileri açıklar; ölçülmüş erişilebilirlik değildir.

İkinci uygulama örneği hangi arızayı karşılayabilir?

İlk durum bile sınanması gereken bir beklentidir. Kalan makine aşırı yüklenirse veya yönlendirme çalışmazsa yalnız var olması yetmez. İki VM de konumu, elektriği veya başka altyapıyı paylaşabilir; gerçek arıza alanları gereksinime uygun olmalıdır.

Ortak veri katmanını ayrıca ele almak

Proje listesi veritabanı arızasında da erişilebilir kalacaksa veri katmanının uygun bir erişilebilirlik ve devralma yaklaşımına ihtiyacı vardır. Kabul edilen veri kaybı, tutarlılık ve devam eden yazmaların davranışı belirlenmelidir. İkinci veritabanı süreci de tek başına güvenli devamı kanıtlamaz.

Microsoft, çalışan replikalar ile belirli bir zamana ait yedek kopyaları ayırır. Yedek, bir geri yükleme yoluna hizmet eder; kendiliğinden hemen hazır çalışan yedek veritabanı değildir. Replikasyon, istenmeyen veri değişikliğinden sonra sınanmış geri yüklemenin yerini tutmaz. Gerekli önlemler iş hedefine bağlıdır.

Etkilenen kullanıcı akışıyla karar vermek

Microsoft’un arıza analizi her kritik akışı, iç ve dış bağımlılıklarıyla izler. Örneğimizde tablodaki üç durum, izin verilmiş bir test ortamında ayrı ayrı sınanmalıdır. Algılama, proje listesi yüklenirken oluşan davranış, yeniden çalışma ve sorumlu rol kaydedilmelidir.

Kararlaştırılmış geri yükleme yolu veritabanı kesintisini yeterince karşılıyorsa ek uygulama örneği süreç arızaları veya bakım için yine yararlı olabilir. İş ihtiyacı, veritabanı veya erişim arızasında da çalışmayı gerektiriyorsa bu boşluklar giderilmiş olmaz. Makine sayısından bir erişilebilirlik oranı türetilemez.

Kaynaklar

• Microsoft — Architecture strategies for designing for redundancy

• Microsoft — Architecture strategies for performing failure mode analysis

• Microsoft — Redundancy, replication, and backup