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 devretmesi olacak mı?
Öneriler
İş gereksinimlerinizi göz önünde bulundurun. Bir sistemin yerleşik olarak sahip olduğu yedeklilik miktarı hem maliyeti hem de karmaşıklığı etkileyebilir. Mimarinizin tasarımı, kurtarma süresi hedefi (RTO) gibi iş gereksinimlerinizi yansıtmalıdır. Örneğin, çok bölgeli dağıtımlar tek bölge dağıtımlara göre daha pahalıdır ve yönetimi daha karmaşıktır. Yük devretme ve yeniden çalışma işlemleri için işletimsel yordamlarınızın olması gerekir. Ek maliyet ve karmaşıklık bazı iş senaryoları için zorunluyken bazıları için gereksizdir.
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ğıtma hakkında bilgi edinmek için bkz. Ölçeklenebilirlik ve kullanılabilirlik için birden çok VM.
Veritabanlarını çoğaltın. Azure SQL Veritabanı ve Cosmos DB, verileri bir bölge içinde otomatik olarak çoğaltır ve bölgeler arasında coğrafi çoğaltmayı etkinleştirebilirsiniz. IaaS veritabanı çözümü kullanıyorsanız, Always On kullanılabilirlik grupları gibi çoğaltma ve yük devretmeyi SQL Server birini seçin.
Coğrafi çoğaltmayı etkinleştirin. Azure SQL Veritabanı ve Cosmos DB için coğrafi çoğaltma, bir veya daha fazla ikincil bölgede verilerinizin okunabilir ikincil kopyalarını oluşturur. Kesinti durumunda, veritabanı yazma işlemleri için ikincil bölgeye yük devretme gerçekleştirebilir.
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.
Birden fazla bölgeye dağıtın. En yüksek kullanılabilirlik için uygulamayı birden fazla bölgeye dağıtın. Böylece, bir bölgenin tamamını etkileyen bir sorun oluştuğunda, uygulama başka bir bölgeye yük devretme gerçekleştirebilir. Aşağıdaki diyagramda, yük devretme işlemleri için Azure Traffic Manager kullanan bir çok bölgeli uygulama gösterilmiştir.
Ön ve arka uç yük devretmeyi eşitleyin. Ön uçta yük devretme gerçekleştirmek için Azure Traffic Manager kullanın. Ön uç bir bölgede ulaşılamaz hale gelirse, Traffic Manager yeni istekleri ikincil bölgeye yönlendirir. Veritabanı çözümünüze bağlı olarak veritabanının yükünü devretme konusunda koordinasyona gereksinim duyabilirsiniz.
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.
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.