Her şeyin yedekli olmasını sağlamaMake all things redundant

Tek hata noktalarından kaçınmak için uygulamanızın özünde yedekli olmasını sağlayınBuild redundancy into your application, to avoid having single points of failure

Dayanıklı uygulamalar, hataların etrafından dolaşmanın bir yolunu bulur.A resilient application routes around failure. Uygulamanızdaki kritik yolları belirleyin.Identify the critical paths in your application. Yol üzerindeki her bir noktada yedeklilik var mı?Is there redundancy at each point in the path? Bir alt sistem başarısız olduğunda uygulama başka bir şeye yük devredecek mi?If a subsystem fails, will the application fail over to something else?

ÖnerilerRecommendations

İş gereksinimlerinizi göz önünde bulundurun.Consider business requirements. Bir sistemin yerleşik olarak sahip olduğu yedeklilik miktarı hem maliyeti hem de karmaşıklığı etkileyebilir.The amount of redundancy built into a system can affect both cost and complexity. Mimarinizin tasarımı, kurtarma süresi hedefi (RTO) gibi iş gereksinimlerinizi yansıtmalıdır.Your architecture should be informed by your business requirements, such as recovery time objective (RTO). Ö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.For example, a multi-region deployment is more expensive than a single-region deployment, and is more complicated to manage. Yük devretme ve yeniden çalışma işlemleri için işletimsel yordamlarınızın olması gerekir.You will need operational procedures to handle failover and failback. Ek maliyet ve karmaşıklık bazı iş senaryoları için zorunluyken bazıları için gereksizdir.The additional cost and complexity might be justified for some business scenarios and not others.

VM’leri bir yük dengeleyicinin arkasına yerleştirin.Place VMs behind a load balancer. Görev açısından kritik iş yükleri için tek bir VM kullanmayın.Don't use a single VM for mission-critical workloads. Bunun yerine, yük dengeleyicinin arkasına birden çok VM yerleştirin.Instead, place multiple VMs behind a load balancer. Herhangi bir VM kullanılamaz duruma gelirse, yük dengeleyici trafiği iyi durumdaki diğer VM'lere dağıtır.If any VM becomes unavailable, the load balancer distributes traffic to the remaining healthy VMs. Bu yapılandırmayı dağıtma hakkında bilgi edinmek için bkz. Ölçeklenebilirlik ve kullanılabilirlik için birden çok VM.To learn how to deploy this configuration, see Multiple VMs for scalability and availability.

Yük dengeli VM'ler diyagramı

Veritabanlarını çoğaltın.Replicate databases. 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.Azure SQL Database and Cosmos DB automatically replicate the data within a region, and you can enable geo-replication across regions. Bir IaaS veritabanı çözümü kullanıyorsanız, SQL Server Always On Kullanılabilirlik Grupları gibi çoğaltmayı ve yük devretmeyi destekleyen bir çözüm seçin.If you are using an IaaS database solution, choose one that supports replication and failover, such as SQL Server Always On Availability Groups.

Coğrafi çoğaltmayı etkinleştirin.Enable geo-replication. 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.Geo-replication for Azure SQL Database and Cosmos DB creates secondary readable replicas of your data in one or more secondary regions. Kesinti durumunda, veritabanı yazma işlemleri için ikincil bölgeye yük devretme gerçekleştirebilir.In the event of an outage, the database can fail over to the secondary region for writes.

Kullanılabilirlik için bölümleyin.Partition for availability. Çoğunlukla ölçeklenebilirliği geliştirmek için kullanılan veritabanı bölümleme stratejisi kullanılabilirliği de artırabilir.Database partitioning is often used to improve scalability, but it can also improve availability. Bir parça devre dışı kalsa bile diğer parçalara erişilebilir.If one shard goes down, the other shards can still be reached. Bir parçada gerçekleşen bir hata, toplamda işlemlerin yalnızca bir alt kümesinde kesintiye neden olur.A failure in one shard will only disrupt a subset of the total transactions.

Birden fazla bölgeye dağıtın.Deploy to more than one region. En yüksek kullanılabilirlik için uygulamayı birden fazla bölgeye dağıtın.For the highest availability, deploy the application to more than one region. 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.That way, in the rare case when a problem affects an entire region, the application can fail over to another region. Aşağıdaki diyagramda, yük devretme işlemleri için Azure Traffic Manager kullanan bir çok bölgeli uygulama gösterilmiştir.The following diagram shows a multi-region application that uses Azure Traffic Manager to handle failover.

Yük devretme işlemleri için Azure Traffic Manager'ı kullanarak diyagramı

Ön ve arka uç yük devretmeyi eşitleyin.Synchronize front and backend failover. Ön uçta yük devretme gerçekleştirmek için Azure Traffic Manager kullanın.Use Azure Traffic Manager to fail over the front end. Ön uç bir bölgede ulaşılamaz hale gelirse, Traffic Manager yeni istekleri ikincil bölgeye yönlendirir.If the front end becomes unreachable in one region, Traffic Manager will route new requests to the secondary region. Veritabanı çözümünüze bağlı olarak veritabanının yükünü devretme konusunda koordinasyona gereksinim duyabilirsiniz.Depending on your database solution, you may need to coordinate failing over the database.

Otomatik yük devretme, el ile yeniden çalışma kullanın.Use automatic failover but manual failback. Traffic Manager kullanarak otomatik yük devretme gerçekleştirin, ancak otomatik yeniden çalışma gerçekleştirmeyin.Use Traffic Manager for automatic failover, but not for automatic failback. Otomatik yeniden çalışma, birincil bölgenin durumu tamamen normale dönmeden önce bu bölgeye geçiş yapma riskini taşır.Automatic failback carries a risk that you might switch to the primary region before the region is completely healthy. Bunun yerine, el ile yeniden çalıştırmadan önce tüm uygulama alt sistemlerinin iyi durumda olduğunu doğrulayın.Instead, verify that all application subsystems are healthy before manually failing back. Ayrıca, veritabanına bağlı olarak yeniden çalıştırmadan önce veri tutarlılığını denetlemeniz gerekebilir.Also, depending on the database, you might need to check data consistency before failing back.

Traffic Manager için de yedeklilik sağlayın.Include redundancy for Traffic Manager. Traffic Manager, olası bir hata noktasıdır.Traffic Manager is a possible failure point. 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.Review the Traffic Manager SLA, and determine whether using Traffic Manager alone meets your business requirements for high availability. Aksi durumda, yeniden çalıştırma çözümü olarak başka bir trafik yönetim çözümü eklemeyi göz önünde bulundurun.If not, consider adding another traffic management solution as a failback. 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.If the Azure Traffic Manager service fails, change your CNAME records in DNS to point to the other traffic management service.