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?

Ö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.

Bahşiş

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ölgeleri kullanmak için Öneriler.

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. Bu yapılandırmayı dağıtmayı öğrenmek için bkz. [Ölçeklenebilirlik ve kullanılabilirlik için birden çok VM][multi-vm-blueprint].

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.

Ç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.

Traffic Manager'ı çok bölgeli bir çözümde 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 Traffic Manager'ı kullanın. Ön uç bir bölgede ulaşılamaz hale gelirse, Traffic Manager 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. Traffic Manager kullanarak otomatik yük devretme gerçekleştirin, ancak otomatik yeniden çalışma gerçekleştirmeyin. 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, veritabanına bağlı olarak yeniden çalıştırmadan önce veri tutarlılığını denetlemeniz gerekebilir.

Bunu başarmak için yük devretmeden sonra Traffic Manager'ın birincil uç noktasını 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.

Traffic Manager için de yedeklilik sağlayın. Traffic Manager, olası bir hata noktasıdır. Traffic Manager SLA’sını gözden geçirin ve yalnızca Traffic Manager kullanımıyla, yüksek kullanılabilirliğe ilişkin iş gereksinimlerinizin karşılanıp karşılanmadığını belirleyin. Aksi durumda, yeniden çalıştırma çözümü olarak başka bir trafik yönetim çözümü eklemeyi göz önünde bulundurun. Azure Traffic Manager hizmeti başarısız olursa, DNS’teki CNAME kayıtlarınızı diğer trafik yönetimi hizmetini gösterecek şekilde değiştirin.