Her şeyin yedekli olmasını sağlama
Tek hata noktalarından kaçınmak için uygulamanızın özünde yedekli olmasını sağlayın
Dayanıklı uygulamalar, hataların etrafından dolaşmanın bir yolunu bulur. Uygulamanızdaki kritik yolları belirleyin. Yol üzerindeki her bir noktada yedeklilik var mı? Bir alt sistem başarısız olduğunda, uygulama başka bir şeye yük devredecek mi?
Mükemmel bir uygulamada tekdüzen yedeklilik eklemek, sisteminizin kullanılabilirliğini üstel olarak artırabilir. Örneğin, eşdeğer, eşit dengeli bileşenlere sahip N
olduğunuzu düşünün:
- bağımsız olarak arıza yapabilir ve aynı anda havuzdan çıkarılabilir
- aynı duruma sahip veya hiç durum yok
- arıza sırasında kalıcı olarak kaybedilen devam eden bir çalışma yok
- özelliklerde aynıdır
- birbirine bağımlılıkları yok
- ek arıza olmadan kapasitenin azaltılmasını işler
Her bileşenin A
kullanılabilirliği varsa, genel sistem kullanılabilirliği formülü 1 - (1 - A)^N
kullanılarak hesaplanabilir.
Öneriler
İş gereksinimlerinizi göz önünde bulundurun. Bir sistemin yerleşik olarak sahip olduğu yedeklilik miktarı hem maliyeti hem de karmaşıklığı etkileyebilir. Mimariniz, kurtarma süresi hedefi (RTO) ve kurtarma noktası hedefi (RPO) gibi iş gereksinimleriniz tarafından bilgilendirilmelidir. Ayrıca performans gereksinimlerinizi ve ekibinizin karmaşık kaynak kümelerini yönetme becerisini de göz önünde bulundurmalısınız.
Çok bölgeli ve çok bölgeli mimarileri göz önünde bulundurun. Kullanılabilirlik alanlarının ve bölgelerinin dayanıklılığı ve farklı mimari denge kümelerini nasıl sağladığını anladığınızdan emin olun.
Azure kullanılabilirlik alanları, bir bölge içindeki yalıtılmış veri merkezleri kümeleridir. Kullanılabilirlik alanlarını kullanarak tek bir veri merkezinin veya tüm kullanılabilirlik alanının hatalarına karşı dayanıklı olabilirsiniz. Kullanılabilirlik alanlarını kullanarak maliyet, risk azaltma, performans ve kurtarılabilirlik arasında denge sağlayabilirsiniz. Örneğin, mimarinizde alanlar arası yedekli hizmetler kullandığınızda, Azure coğrafi olarak ayrılmış örnekler arasında otomatik veri çoğaltma ve yük devretme sağlar ve bu da birçok farklı risk türünü azaltır.
Görev açısından kritik bir iş yükünüz varsa ve bölge genelinde kesinti riskini azaltmanız gerekiyorsa, çok bölgeli bir dağıtımı göz önünde bulundurun. Çok bölgeli dağıtımlar sizi bölgesel afetlere karşı yalıtsa da, bunların bir maliyeti vardır. Çok bölgeli dağıtımlar tek bölgeli dağıtımlardan daha pahalıdır ve yönetilmesi daha karmaşıktır. Yük devretme ve yeniden çalışma işlemlerini işlemek için işlem yordamlarına ihtiyacınız olacaktır. RPO gereksinimlerinize bağlı olarak, bölgeler arası veri çoğaltmayı etkinleştirmek için biraz daha düşük performans kabul etmeniz gerekebilir. Ek maliyet ve karmaşıklık, bazı iş senaryoları için gerekçelendirilebilir.
İpucu
Birçok iş yükü için alanlar arası yedekli mimari en iyi denge kümesini sağlar. İş gereksinimleriniz, bölge genelinde kesinti riskini azaltmanız gerektiğini gösteriyorsa ve böyle bir yaklaşımda yer alan dengeleri kabul etmeye hazırsanız, çok bölgeli bir mimariyi göz önünde bulundurun.
Çözümünüzü kullanılabilirlik alanlarını ve bölgelerini kullanacak şekilde tasarlama hakkında daha fazla bilgi edinmek için bkz . Kullanılabilirlik alanlarını ve bölgelerini kullanma önerileri.
VM’leri bir yük dengeleyicinin arkasına yerleştirin. Görev açısından kritik iş yükleri için tek bir VM kullanmayın. Bunun yerine, yük dengeleyicinin arkasına birden çok VM yerleştirin. Herhangi bir VM kullanılamaz duruma gelirse, yük dengeleyici trafiği iyi durumdaki diğer VM'lere dağıtır.
Veritabanlarını çoğaltın. Azure SQL Veritabanı ve Azure Cosmos DB verileri otomatik olarak bir bölge içinde çoğaltır ve daha yüksek dayanıklılık için kullanılabilirlik alanları arasında çoğaltılacak şekilde yapılandırılabilir. Bölgeler arasında coğrafi çoğaltmayı etkinleştirmeyi de seçebilirsiniz. Azure SQL Veritabanı ve Azure Cosmos DB için coğrafi çoğaltma, verilerinizin bir veya daha fazla ikincil bölgede ikincil okunabilir çoğaltmalarını oluşturur. Birincil bölgede bir kesinti oluşursa, veritabanı yazma işlemleri için ikincil bölgeye yük devredebilir. Çoğaltma yapılandırmasına bağlı olarak, hesaplanmamış işlemlerden kaynaklanan bazı veri kayıplarıyla karşılaşabilirsiniz.
IaaS veritabanı çözümü kullanıyorsanız, SQL Server AlwaysOn kullanılabilirlik grupları gibi çoğaltma ve yük devretmeyi destekleyen bir çözüm seçin.
Kullanılabilirlik için bölümleyin. Çoğunlukla ölçeklenebilirliği geliştirmek için kullanılan veritabanı bölümleme stratejisi kullanılabilirliği de artırabilir. Bir parça devre dışı kalsa bile diğer parçalara erişilebilir. Bir parçada gerçekleşen bir hata, toplamda işlemlerin yalnızca bir alt kümesinde kesintiye neden olur.
Yedekli bileşenlerinizi test edin ve doğrulayın. Güvenilirlik, basitlikten ve yedeklilik eklemeden birçok yolla karmaşıklığı artırabilir. Yedeklilik eklemenin aslında daha yüksek kullanılabilirliğe yol açtığını güvence altına almak için aşağıdakileri doğrulamanız gerekir:
- Sisteminiz sağlıklı ve iyi durumda olmayan yedekli bileşenleri güvenilir bir şekilde algılayabilir ve bunları bileşen havuzundan güvenli ve hızlı bir şekilde kaldırabilir mi?
- Sisteminiz , yedekli bileşenlerin ölçeğini güvenilir bir şekilde genişletebilir mi?
- Rutin, geçici ve acil durum iş yükü işlemleriniz yedekliliği işleyebilir mi?
Çok bölgeli çözümler
Aşağıdaki diyagramda, yük devretme işlemleri için Azure Traffic Manager kullanan bir çok bölgeli uygulama gösterilmiştir.
Yük devretme yönlendirme mekanizmanız olarak çok bölgeli bir çözümde Traffic Manager veya Azure Front Door kullanıyorsanız aşağıdaki önerileri göz önünde bulundurun:
Ön ve arka uç yük devretmeyi eşitleyin. Ön uçta yük devretme yapmak için yönlendirme mekanizmanızı kullanın. Bir bölgede ön uca ulaşılamaz hale gelirse, yük devretme yeni istekleri ikincil bölgeye yönlendirir. Arka uç bileşenlerinize ve veritabanı çözümünüze bağlı olarak, arka uç hizmetleriniz ve veritabanlarınız üzerinde yük devretmeyi koordine etmeniz gerekebilir.
Otomatik yük devretme, el ile yeniden çalışma kullanın. Yük devretme için otomasyon kullanın, ancak yeniden çalışma için kullanmayın. Otomatik yeniden çalışma, birincil bölgenin durumu tamamen normale dönmeden önce bu bölgeye geçiş yapma riskini taşır. Bunun yerine, el ile yeniden çalıştırmadan önce tüm uygulama alt sistemlerinin iyi durumda olduğunu doğrulayın. Ayrıca yeniden başarısız olmadan önce veri tutarlılığını denetlemeniz gerekir.
Bunu başarmak için yük devretmeden sonra birincil uç noktayı devre dışı bırakın. Yoklamaların izleme aralığı kısaysa ve tolere edilen hata sayısı küçükse, yük devretme ve yeniden çalışma kısa bir süre içinde gerçekleşir. Bazı durumlarda devre dışı bırakma işlemi zamanında tamamlanamaz. Onaylanmamış yeniden çalışmadan kaçınmak için, tüm alt sistemlerin iyi durumda olduğunu doğrulayabilen bir sistem durumu uç noktası da uygulamayı göz önünde bulundurun. Sistem Durumu Uç Noktası İzleme düzenine bakın.
Yönlendirme çözümünüz için yedeklilik ekleyin. Görev açısından kritik web uygulamaları için Genel yönlendirme yedekliliği çözümü tasarlamayı göz önünde bulundurun.