Azure uygulamaları için olağanüstü durum kurtarmaDisaster recovery for Azure applications

Olağanüstü Durum Kurtarma (DR), yıkıcı bir uygulama işlevselliği kaybından kurtarma üzerinde odaklanmıştır.Disaster recovery (DR) is focused on recovering from a catastrophic loss of application functionality. Örneğin, uygulamanızı barındıran bir Azure bölgesinde kullanılamaz duruma gelirse, uygulamanızı çalıştıran veya başka bir bölgede erişmek için bir plan gerekir.For example, if an Azure region hosting your application becomes unavailable, you need a plan for running your application or accessing your data in another region.

İş ve teknoloji sahipleri, ne kadar işlevselliği bir olağanüstü durum sırasında gerekli olduğunu belirlemeniz gerekir.Business and technology owners must determine how much functionality is required during a disaster. Bu işlevsellik düzeyine birkaç biçimde olabilir: tamamen kullanılamaz, işlevsellik veya Gecikmeli işleme aracılığıyla kullanılabilen kısmen veya tamamen kullanılabilir.This level of functionality can take a few forms: completely unavailable, partially available via reduced functionality or delayed processing, or fully available.

Dayanıklılık ve yüksek kullanılabilirlik stratejileri, geçici hata koşullarını işlemek için tasarlanmıştır.Resiliency and high availability strategies are intended for handling temporary failure conditions. Bu planı çalıştırma, kişileri, süreçleri ve çalışmaya devam edebilmesi için sisteme izin destekleyen uygulamaları içerir.Executing this plan involves people, processes, and supporting applications that allow the system to continue functioning. Planınızı hataları prova içermelidir ve ses planı emin olmak için veritabanı kurtarma testi.Your plan should include rehearsing failures and testing the recovery of databases to ensure the plan is sound.

Azure olağanüstü durum kurtarma özellikleriAzure disaster recovery features

Azure kullanılabilirlik değerlendirmelerine ile sağladığından dayanıklılık teknik Kılavuzu olağanüstü durum kurtarmayı desteklemek üzere tasarlanmıştır.As with availability considerations, Azure provides resiliency technical guidance designed to support disaster recovery. Azure ve olağanüstü durum kurtarma kullanılabilirlik özellikleri arasında bir ilişki bulunmaktadır.There is also a relationship between availability features of Azure and disaster recovery. Örneğin, yönetim rolleri hata etki alanları arasında bir uygulamanın kullanılabilirliğini artırır.For example, the management of roles across fault domains increases the availability of an application. Söz konusu yönetimin bir "olağanüstü durum" senaryosuna bir işlenmemiş bir donanım hatası oluşur.Without that management, an unhandled hardware failure would become a “disaster” scenario. Bu kullanılabilirlik özellikleri ve stratejileri yararlanarak önemli bir olağanüstü durum sağlama, uygulamanızın yer.Leveraging these availability features and strategies is an important part of disaster-proofing your application. Ancak bu makalede daha ciddi (ve nadir) olağanüstü durum olayları için genel kullanılabilirlik sorunları gider.However, this article goes beyond general availability issues to more serious (and rarer) disaster events.

Birden çok veri merkezi bölgesiMultiple datacenter regions

Azure çok sayıda bölgede dünyanın dört bir yanındaki veri merkezlerinde tutar.Azure maintains datacenters in many regions around the world. Bu altyapı, sistem tarafından sağlanan coğrafi çoğaltma, Azure Storage ikincil bölgeye gibi çeşitli olağanüstü durum kurtarma senaryolarını destekler.This infrastructure supports several disaster recovery scenarios, such as system-provided geo-replication of Azure Storage to secondary regions. Dünyanın dört bir yanındaki birden fazla konuma bir bulut hizmeti de kolayca ve hesaplı bir şekilde dağıtabilirsiniz.You can also easily and inexpensively deploy a cloud service to multiple locations around the world. Maliyetini ve zorluğunu derlenmesi ve birden çok bölgede kendi veri merkezlerinizi bakımı ile karşılaştırın.Compare this with the cost and difficulty of building and maintaining your own datacenters in multiple regions. Veri ve hizmetlerinizi birden çok bölgeye dağıtım, uygulamanız tek bir bölgede büyük bir kesintiye korunmasına yardımcı olur.Deploying data and services to multiple regions helps protect your application from a major outage in a single region. Olağanüstü durum kurtarma planınızı tasarlarken, eşleştirilmiş bölgelerin kavramı anlamak önemlidir.As you design your disaster recovery plan, it’s important to understand the concept of paired regions. Daha fazla bilgi için iş sürekliliği ve olağanüstü durum kurtarma (BCDR): Azure eşleştirilmiş bölgeleri.For more information, see Business continuity and disaster recovery (BCDR): Azure Paired Regions.

Azure Site RecoveryAzure Site Recovery

Azure Site Recovery bölgeleri arasında Azure Vm'lerini çoğaltma için basit bir yol sağlar.Azure Site Recovery provides a simple way to replicate Azure VMs between regions. İkincil bölgedeki herhangi bir ek kaynak sağlamanız gerekmez çünkü en az yönetim yükü var.It has minimal management overhead, because you don't need to provision any additional resources in the secondary region. Çoğaltmayı etkinleştirdiğinizde Site Recovery otomatik olarak gerekli kaynaklara hedef bölgede kaynak VM ayarları temel alarak oluşturur.When you enable replication, Site Recovery automatically creates the required resources in the target region, based on the source VM settings. Otomatik sürekli çoğaltma sağlar ve tek bir tıklamayla uygulama yük devretme gerçekleştirmenize olanak sağlar.It provides automated continuous replication, and enables you to perform application failover with a single click. Ayrıca, yük devretme, üretim iş yükleri veya sürmekte olan çoğaltmayı etkilemeden test ederek olağanüstü durum kurtarma tatbikatı çalıştırabilirsiniz.You can also run disaster recovery drills by testing failover, without affecting your production workloads or ongoing replication.

Azure Traffic ManagerAzure Traffic Manager

Bir bölgeye özgü hata oluştuğunda, hizmetleri veya başka bir bölgede dağıtımlar için trafiği yeniden yönlendirmeniz gerekir.When a region-specific failure occurs, you must redirect traffic to services or deployments in another region. Azure trafiği birincil bölgeye başarısız olursa, kullanıcı trafiğinin başka bir bölgeye yük devretme otomatikleştirir Manager gibi hizmetleri aracılığıyla bu durumu çözmek en etkili.It is most effective to handle this via services such as Azure Traffic Manager, which automates the failover of user traffic to another region if the primary region fails. Etkili bir DR stratejisi tasarlarken, Traffic Manager'ın temellerini anlamanız önemlidir.Understanding the fundamentals of Traffic Manager is important when designing an effective DR strategy.

Traffic Manager trafik yönlendirme yöntemi ve sistem durumu uç nokta göre en uygun uç noktaya istemci istekleri yönlendirmek için etki alanı adı sistemi (DNS) kullanır.Traffic Manager uses the Domain Name System (DNS) to direct client requests to the most appropriate endpoint based on a traffic-routing method and the health of the endpoints. Aşağıdaki diyagramda, kullanıcıların bir Traffic Manager URL'ye bağlanın (http://myATMURL.trafficmanager.net) gerçek site URL'leri soyutlar (http://app1URL.cloudapp.net ve http://app2URL.cloudapp.net).In the following diagram, users connect to a Traffic Manager URL (http://myATMURL.trafficmanager.net) which abstracts the actual site URLs (http://app1URL.cloudapp.net and http://app2URL.cloudapp.net). Kullanıcı isteklerini, yapılandırılmış göre uygun temel URL yönlendirilir Traffic Manager yönlendirme yöntemini.User requests are routed to the proper underlying URL based on your configured Traffic Manager routing method. Bu makale için yalnızca yük devretme seçeneğiyle ilgili ulaşacağız.For the sake of this article, we will be concerned with only the failover option.

Azure Traffic Manager aracılığıyla yönlendirme

Traffic Manager yapılandırırken, hangi kullanıcıların hizmete bağlanmak için kullanacağı bir yeni Traffic Manager DNS ön ekini belirtin.When configuring Traffic Manager, you provide a new Traffic Manager DNS prefix, which users will use to access your service. Özet Yük Dengeleme bir düzey artık daha yüksek bölgesel düzeyde traffic Manager.Traffic Manager now abstracts load balancing one level higher that the regional level. Traffic Manager DNS yönettiği tüm dağıtımlar için bir CNAME eşlenir.The Traffic Manager DNS maps to a CNAME for all the deployments that it manages.

Traffic Manager'ın içinde bir hata oluşursa, kullanıcılar için yönlendirilir dağıtımlar öncelikli listesi belirtin.Within Traffic Manager, you specify a prioritized list of deployments that users will be routed to when failure occurs. Traffic Manager, dağıtım uç noktalarını izler.Traffic Manager monitors the deployment endpoints. Birincil dağıtım kullanılamaz duruma gelirse Traffic Manager kullanıcıları öncelik listesindeki bir sonraki dağıtım yönlendirir.If the primary deployment becomes unavailable, Traffic Manager routes users to the next deployment on the priority list.

Traffic Manager yük devri sırasında nereye karar olsa da, (Traffic Manager ilgisiz) yük devretme modunda değilseniz ancak yük devretme etki alanınızı etkin olmayan veya etkin olup olmadığını karar verebilirsiniz.Although Traffic Manager decides where to go during a failover, you can decide whether your failover domain is dormant or active while you're not in failover mode (which is unrelated to Traffic Manager). Traffic Manager birincil sitedeki bir hatayı algılar ve o sitenin kullanıcılar şu anda olup hizmet ne olursa olsun yük devretme siteye yuvarlanır.Traffic Manager detects a failure in the primary site and rolls over to the failover site, regardless of whether that site is currently serving users.

Azure Traffic Manager nasıl çalıştığı hakkında daha fazla bilgi için bkz:For more information on how Azure Traffic Manager works, refer to:

Azure'a olağanüstü durum senaryolarıAzure disaster scenarios

Aşağıdaki bölümlerde, birkaç farklı türde olağanüstü durum senaryoları kapsar.The following sections cover several different types of disaster scenarios. Bölge genelinde hizmet kesintilerinden yalnızca birçok farklı uygulama hatalarının nedenini değildir.Region-wide service disruptions are not the only cause of application-wide failures. Ayrıca kötü tasarım ve yönetim hataları kesintiler için yol açabilir.Poor design and administrative errors can also lead to outages. Bir hatanın olası nedenleri tasarım ve kurtarma planınızın test aşamaları sırasında göz önünde bulundurmanız önemlidir.It's important to consider the possible causes of a failure during both the design and testing phases of your recovery plan. İyi bir plan Azure özelliklerinden yararlanır ve bunları uygulamaya özgü stratejileriyle artırmaktadır.A good plan takes advantage of Azure features and augments them with application-specific strategies. Seçilen yanıt uygulamanın önemini tarafından belirlenen kurtarma noktası hedefi (RPO) ve kurtarma süresi hedefi (RTO).The chosen response is determined by the importance of the application, the recovery point objective (RPO), and the recovery time objective (RTO).

Uygulama hatasıApplication failure

Azure Traffic Manager, konak sanal makine temel alınan donanım veya işletim sistemi yazılım kaynaklanan hataları otomatik olarak işler.Azure Traffic Manager automatically handles failures that result from the underlying hardware or operating system software in the host virtual machine. Azure, yeni bir rol örneği oluşturur ve kullanılabilir havuza ekler.Azure creates a new role instance and adds it to the available pool. Birden fazla rol örneği zaten çalışıyorsa Azure başarısız olan düğümün değiştirirken diğer çalışan rolü örnekleri işleme geçer.If more than one role instance was already running, Azure shifts processing to the other running role instances while replacing the failed node.

Donanım veya işletim sistemi temel alınan bir hatasız önemli uygulama hataları oluşabilir.Serious application errors can occur without any underlying failure of the hardware or operating system. Uygulama hatalı mantıksal veya veri bütünlüğü sorunları nedeniyle geri dönülemez bir özel durum nedeniyle başarısız olabilir.The application might fail due to catastrophic exceptions caused by bad logic or data integrity issues. İzleme sistemi hata koşulları algılamak ve uygulama Yöneticisi bildir uygulama koduna yeterli telemetri içermesi gerekir.You must include sufficient telemetry in the application code so that a monitoring system can detect failure conditions and notify an application administrator. Olağanüstü durum kurtarma işlemlerinin bir role sahip bir yönetici bir yük devretme işlemini tetikleyin veya kullanılabilirlik kesinti çözümlenirken kritik hataları kabul karar verebilirsiniz.An administrator who has full knowledge of the disaster recovery processes can decide whether to trigger a failover process or accept an availability outage while resolving the critical errors.

Veri bozulmasıData corruption

Azure otomatik olarak Azure SQL veritabanı ve Azure depolama veri üç kez nedenle farklı hata etki alanlarında aynı bölgede içinde depolar.Azure automatically stores Azure SQL Database and Azure Storage data three times redundantly within different fault domains in the same region. Coğrafi çoğaltma kullanıyorsanız, verileri farklı bir bölgede üç kez depolanır.If you use geo-replication, the data is stored three additional times in a different region. Ancak, verileri, hızlı bir şekilde birincil kopya bu verileri, kullanıcılarınızın veya uygulamanızı bozarsa, bir kopya için çoğaltır.However, if your users or your application corrupts that data in the primary copy, the data quickly replicates to the other copies. Ne yazık ki bu bozuk verilerin birden çok kopyasını sonuçlanır.Unfortunately, this results in multiple copies of corrupt data.

Olası bir bozulma verilerinizi yönetmek için iki seçeneğiniz vardır.To manage potential corruption of your data, you have two options. İlk olarak, özel bir yedekleme stratejisi yönetebilirsiniz.First, you can manage a custom backup strategy. Yedeklemeleriniz, Azure'da veya şirket içinde iş gereksinimlerini veya İdaresi yönetmelikleri bağlı olarak depolayabilirsiniz.You can store your backups in Azure or on-premises, depending on your business requirements or governance regulations. Başka bir seçenek, bir SQL veritabanını kurtarmak için zaman içinde nokta geri yükleme seçeneğini kullanmaktır.Another option is to use the point-in-time restore option to recover a SQL database. Daha fazla bilgi için olağanüstü durum kurtarma stratejileri veri bölümüne bakın.For more information, see the data strategies for disaster recovery section below.

Ağ kesintisiNetwork outage

Azure ağ kısımlarını erişilemediğinde, uygulama veya veri erişemiyor olabilir.When parts of the Azure network are inaccessible, you may be unable to access your application or data. Ağ sorunları nedeniyle bir veya daha fazla rol örneğini kullanılamıyorsa, Azure uygulamanızı kalan kullanılabilir örneğini kullanır.If one or more role instances are unavailable due to network issues, Azure uses the remaining available instances of your application. Uygulamanızı bir Azure ağ kesintisi nedeniyle verilerini erişemiyorsanız, yerel olarak önbelleğe alınan verileri kullanarak uygulama azaltılmış işlevsellikle potansiyel olarak çalıştırabilirsiniz.If your application cannot access its data because of an Azure network outage, you can potentially run with reduced application functionality locally by using cached data. Sınırlı işlevsellikte uygulamanızı çalıştırmak için olağanüstü durum kurtarma stratejisi tasarlama gerekir.You need to design the disaster recovery strategy to run with reduced functionality in your application. Bazı uygulamalar için bu pratik olmayabilir.For some applications, this might not be practical.

Bağlantı geri yüklenene kadar verileri alternatif bir konuma depolamak başka bir seçenektir.Another option is to store data in an alternate location until connectivity is restored. Azaltma işlevi bir seçenek değilse, uygulama kapalı kalma süresi veya başka bir bölgeye yük devretme kalan seçenekler şunlardır.If reducing functionality is not an option, the remaining options are application downtime or failover to an alternate region. Sınırlı işlevsellikte çalışan bir uygulama tasarımını kadar bir iş teknik bir olarak kararıdır.The design of an application running with reduced functionality is as much a business decision as a technical one. Bu açıklanan bölümünde daha fazla uygulamanın işlevselliği azaltılmış.This is discussed further in the section on reduced application functionality.

Bağımlı bir hizmet hatasıFailure of a dependent service

Azure düzenli kesinti yaşamak birçok hizmet sunar.Azure provides many services that can experience periodic downtime. Örneğin, Azure Redis Cache uygulamanıza önbelleğe alma özellikleri sağlayan çok kiracılı bir hizmet olan.For example, Azure Redis Cache is a multi-tenant service which provides caching capabilities to your application. Bağımlı hizmet kullanılamıyorsa, uygulamanızda neler göz önünde bulundurmanız önemlidir.It's important to consider what happens in your application if the dependent service is unavailable. Birçok açıdan, bu senaryo ağ kesintisi senaryosuna benzer.In many ways, this scenario is similar to the network outage scenario. Ancak, her hizmetin bağımsız olarak sonuçları genel planınız için olası geliştirmeleri göz önünde bulundurur.However, considering each service independently results in potential improvements to your overall plan.

Azure Redis Cache, olağanüstü durum kurtarma avantajları, bulut hizmeti dağıtımı içinde uygulamanıza önbelleğe alınmasını sağlar.Azure Redis Cache provides caching to your application from within your cloud service deployment, which provides disaster recovery benefits. İlk olarak, hizmet artık dağıtıma yerel rolleri üzerinde çalışır.First, the service now runs on roles that are local to your deployment. Bu nedenle, daha iyi izlemek ve önbellek durumu yönetimi işlemlerinizi genel bulut hizmeti için bir parçası olarak yönetmek kullanabilirsiniz.Therefore, you're better able to monitor and manage the status of the cache as part of your overall management processes for the cloud service. Bu tür bir önbelleğe alma, diğer düğümlerde yinelenen kopyalarını bulundurmak yoluyla tek bir düğüm başarısız olursa önbelleğe alınan verileri koruyan önbelleğe alınan veriler için yüksek kullanılabilirlik gibi yeni özellikler de sunar.This type of caching also exposes new features such as high availability for cached data, which preserves cached data if a single node fails by maintaining duplicate copies on other nodes.

Yüksek kullanılabilirlik aktarım hızı azaltır ve yazma işlemleri ikincil kopyalar da upedate gerekir çünkü gecikme süresi artar unutmayın.Note that high availability decreases throughput and increases latency because write operations must also upedate any secondary copies. Önbelleğe alınmış verileri depolamak için gerekli bellek miktarını etkili bir şekilde işledi, kapasite planlaması sırasında dikkate gerekir.The amount of memory required to store the cached data is effectively doubled, which must be taken into account during capacity planning. Bu örnek, her bağımlı hizmetin genel kullanılabilirliği ve yıkıcı hataları Direnci geliştiren özellikler olabilir gösterir.This example demonstrates that each dependent service might have capabilities that improve your overall availability and resistance to catastrophic failures.

Her bağlı hizmet, hizmet kesintisi etkilerini anlamanız gerekir.With each dependent service, you should understand the implications of a service disruption. Önbelleğe alma örnek önbelleğinizi geri yükleyene kadar veriler bir veritabanından doğrudan erişmek mümkün olabilir.In the caching example, it might be possible to access the data directly from a database until you restore your cache. Bu uygulama verilerinin tam erişim sağlarken performansın düşmesine neden olacaktır.This would result in reduced performance while providing full access to application data.

Bölge genelinde hizmet kesintisiRegion-wide service disruption

Önceki hataları temelde aynı Azure bölgesinde yönetilebilir hataları olmuştur.The previous failures have primarily been failures that can be managed within the same Azure region. Ancak, bir hizmet kesintisi tüm bölge olma olasılığını için hazırlamanız gerekir.However, you must also prepare for the possibility that there is a service disruption of the entire region. Bölge genelinde hizmet kesintisi oluşursa, verilerinizi yerel olarak yedekli kopyaların kullanılamaz.If a region-wide service disruption occurs, the locally redundant copies of your data are not available. Coğrafi çoğaltma etkinleştirildiğinde, BLOB'lar ve tablolar farklı bir bölgede üç ek kopya vardır.If you have enabled geo-replication, there are three additional copies of your blobs and tables in a different region. Microsoft kayıp bölge bildirirse, Azure DNS girdilerini coğrafi olarak çoğaltılmış bölgeye yeniden eşlemesi.If Microsoft declares the region lost, Azure remaps all of the DNS entries to the geo-replicated region.

Not

Bu işlem üzerinde herhangi bir denetim yok ve yalnızca bölge genelinde hizmet kesintisi için meydana gelir unutmayın.Be aware that you don't have any control over this process, and it will occur only for region-wide service disruption. Kullanmayı Azure Site Recovery daha iyi bir RPO ve RTO elde etmek için.Consider using Azure Site Recovery to achieve better RPO and RTO. Site Recovery, kabul edilebilir kesinti nedir ve ne zaman çoğaltılmış sanal makinelere yük devretmek karar uygulaması sağlar.Site Recovery allows application to decide what is an acceptable outage, and when to fail over to the replicated VMs.

Azure genelinde hizmet kesintisiAzure-wide service disruption

Olağanüstü durum planlama olası felaketler aralığının tamamı dikkate almanız gerekir.In disaster planning, you must consider the entire range of possible disasters. En önemlisi hizmet kesintilerinden birini tüm Azure bölgelerinde aynı anda içerir.One of the most severe service disruptions would involve all Azure regions simultaneously. Diğer hizmet kesintilerinden olduğu gibi ile ilgili olay geçici kesinti riskini kabul etmek karar verebilirsiniz.As with other service disruptions, you might decide to accept the risk of temporary downtime in that event. Bölgeleri kapsayan yaygın hizmet kesintilerinden bağımlı hizmetler veya tek bölge içeren yalıtılmış hizmet kesintilerinden daha çok nadir.Widespread service disruptions that span regions are much rarer than isolated service disruptions involving dependent services or single regions.

Ancak, bazı görev açısından kritik uygulamalar için çok bölgeli hizmet kesintisi bir yedekleme planı ihtiyacınız olduğuna karar.However, you may decide that certain mission-critical applications require a backup plan for a multi-region service disruption. Bu planı içerebilir hizmetlere devrederek bir alternatif bulut veya karma şirket içi ve bulut çözümü.This plan might include failing over to services in an alternative cloud or a hybrid on-premises and cloud solution.

Azaltılmış uygulama işleviReduced application functionality

İyi tasarlanmış bir uygulama genellikle gevşek bilgi değişimi desenleri uygulamasını yine de birbirleriyle iletişim hizmetleri kullanır.A well-designed application typically uses services that communicate with each other though the implementation of loosely coupled information-interchange patterns. DR kullanımı kolay uygulama hizmet düzeyinde sorumlulukların açıkça ayrılması gerekir.A DR-friendly application requires separation of responsibilities at the service level. Bu uygulamanın tamamı getirme gelen bağımlı hizmetin kesilmesini önler.This prevents the disruption of a dependent service from bringing down the entire application. Örneğin, bir web ticaret uygulaması için şirket Y göz önünde bulundurun. Aşağıdaki modüller, uygulamayı oluşturan:For example, consider a web commerce application for Company Y. The following modules might constitute the application:

  • Ürün Kataloğu ürünlere göz atabilir, kullanıcıların sağlar.Product Catalog allows users to browse products.
  • Alışveriş sepeti ürünleri, alışveriş sepetine eklemek/kaldırmak kullanıcıların sağlar.Shopping Cart allows users to add/remove products in their shopping cart.
  • Sipariş durumu kullanıcı sipariş sevkiyat durumunu gösterir.Order Status shows the shipping status of user orders.
  • Sipariş gönderimi ödeme siparişi göndererek alışveriş oturum sonlandırır.Order Submission finalizes the shopping session by submitting the order with payment.
  • Sipariş işleme sipariş için veri bütünlüğünü doğrular ve bir miktar kullanılabilirlik denetimi gerçekleştirir.Order Processing validates the order for data integrity and performs a quantity availability check.

Bu uygulamadaki bir hizmet bağımlılığı kullanılamaz hale geldiğinde, bağımlılık kurtarır kadar nasıl hizmet çalışmıyor?When a service dependency in this application becomes unavailable, how does the service function until the dependency recovers? İyi tasarlanmış bir sistem, yalıtım sınırlarını sorumlulukların açıkça ayrılması, hem tasarım zamanında hem de çalışma zamanında aracılığıyla uygular.A well-designed system implements isolation boundaries through separation of responsibilities, both at design time and at runtime. Her hata kurtarılabilir ve kurtarılamaz olarak kategorilere ayırabilirsiniz.You can categorize every failure as recoverable and non-recoverable. Kurtarılamaz hatalar hizmeti getirir, ancak alternatifleri aracılığıyla kurtarılabilir bir hatanın azaltabilirsiniz.Non-recoverable errors will bring down the service, but you can mitigate a recoverable error through alternatives. Bazı sorunları otomatik olarak hataların işlenmesi ve diğer işlemler yapmayı ele kullanıcı için saydamdır.Certain problems addressed by automatically handling faults and taking alternate actions are transparent to the user. Daha ciddi bir hizmet kesintisi sırasında uygulama tamamen kullanılamayabilir.During a more serious service disruption, the application might be completely unavailable. Sınırlı işlevsellikte kullanıcı isteklerini işleme devam üçüncü bir seçenektir.A third option is to continue handling user requests with reduced functionality.

Örneğin, siparişler barındırma veritabanı kalırsa, sipariş işleme hizmeti satış işlem işleme yeteneğini kaybeder.For instance, if the database for hosting orders goes down, the Order Processing service loses its ability to process sales transactions. Mimarisine bağlı olarak, zor veya imkansız sipariş gönderme ve sipariş işleme hizmeti devam etmek için uygulamanın olabilir.Depending on the architecture, it might be difficult or impossible for the Order Submission and Order Processing services of the application to continue. Uygulama bu senaryo işlemek üzere tasarlanmamıştır, uygulamanın tamamı çevrimdışı.If the application is not designed to handle this scenario, the entire application might go offline. Ürün verileri farklı bir konumda depolanır, ancak daha sonra ürün kataloğu modülü hala ürünleri görüntülemek için kullanılabilir.However, if the product data is stored in a different location, then the Product Catalog module can still be used for viewing products. Ancak, uygulamanın diğer bölümlerini Envanter sıralama veya sorgular gibi kullanılabilir değil.However, other parts of the application are unavailable, such as ordering or inventory queries.

Azaltılmış uygulama işlevler kullanılabilir olduğuna karar vermeyle ilgili, hem kurumsal karar hem de teknik karar gerçekleşir.Deciding what reduced application functionality is available is both a business decision and a technical decision. Uygulama kullanıcılarının geçici sorunları nasıl bilgilendirecektir karar vermeniz gerekir.You must decide how the application will inform the users of any temporary problems. Yukarıdaki örnekte, uygulama ürünleri görüntülemek ve bunları bir alışveriş sepetine eklemek sağlayabilir.In the example above, the application might allow viewing products and adding them to a shopping cart. Ancak, kullanıcı, satın almasını kolaylaştıran çalıştığında, uygulamanın sıralama işlevlerini geçici olarak kullanılamıyor kullanıcıyı uyarır.However, when the user attempts to make a purchase, the application notifies the user that the ordering functionality is temporarily unavailable. Bu müşteriler için ideal değildir, ancak bir uygulama genelinde hizmet kesintisi engel olmaz.This isn't ideal for the customer, but it does prevent an application-wide service disruption.

Olağanüstü durum kurtarma için veri stratejileriData strategies for disaster recovery

Uygun veri işleme, olağanüstü durum kurtarma planı, zorlu bir yönüdür.Proper data handling is a challenging aspect of a disaster recovery plan. Kurtarma işlemi sırasında veri geri yükleme, genellikle en çok zaman alır.During the recovery process, data restoration typically takes the most time. Hatadan sonra işlevleri sonucunda veri kurtarma hatası ve tutarlılık için zor sorunları azaltmak için farklı seçenekleri.Different choices for reducing functionality result in difficult challenges for data recovery from failure and consistency after failure.

Geri yükleme ya da uygulamanın verilerin bir kopyasını korumak için gereken bir noktadır.One consideration is the need to restore or maintain a copy of the application’s data. Bu veriler, başvuru ve ikincil bir siteye işlem temelli amaçlar için kullanır.You will use this data for reference and transactional purposes at a secondary site. Bir şirket içi dağıtım, birden çok bölge olağanüstü durum kurtarma stratejisi uygulamak için pahalı ve uzun Planlama işlemi gerektirir.An on-premises deployment requires an expensive and lengthy planning process to implement a multiple-region disaster recovery strategy. Rahatça, Azure dahil olmak üzere çoğu bulut sağlayıcıları kolayca birden çok bölgeye uygulamalarının dağıtımını sağlar.Conveniently, most cloud providers, including Azure, readily allow the deployment of applications to multiple regions. Bu bölgeler, coğrafi olarak birden çok bölgeli hizmet kesintisi ender olması gerektiğini şekilde dağıtılır.These regions are geographically distributed in such a way that multiple-region service disruption should be extremely rare. Bölgeler arasında veri işleme stratejisi için tüm olağanüstü durum kurtarma planı başarısını faktörlere biridir.The strategy for handling data across regions is one of the contributing factors for the success of any disaster recovery plan.

Aşağıdaki bölümlerde, olağanüstü durum kurtarma teknikleri veri yedekleri, başvuru veri ve işlem verilerini ilgili açıklanmaktadır.The following sections discuss disaster recovery techniques related to data backups, reference data, and transactional data.

Yedekleme ve geri yüklemeBackup and restore

Uygulama verilerinin düzenli yedeklemeler bazı olağanüstü durum kurtarma senaryolarını destekler.Regular backups of application data can support some disaster recovery scenarios. Farklı depolama kaynakları farklı teknikleri gerektirir.Different storage resources require different techniques.

SQL VeritabanıSQL Database

Temel, standart ve Premium SQL veritabanı katmanları için veritabanını kurtarmak için zaman içinde nokta geri yükleme yararlanabilirsiniz.For the Basic, Standard, and Premium SQL Database tiers, you can take advantage of point-in-time restore to recover your database. Daha fazla bilgi için genel bakış: SQL veritabanı ile iş sürekliliği ve veritabanı olağanüstü durum kurtarma bulut.For more information, see Overview: Cloud business continuity and database disaster recovery with SQL Database. Başka bir seçenek, SQL veritabanı için etkin coğrafi çoğaltma kullanmaktır.Another option is to use Active Geo-Replication for SQL Database. Bu otomatik olarak veritabanı değişiklikleri ikincil veritabanları aynı Azure bölgesinde veya hatta farklı bir Azure bölgesinde çoğaltır.This automatically replicates database changes to secondary databases in the same Azure region or even in a different Azure region. Bu makalede sunulan daha el ile veri eşitleme yöntemlerden bazıları olası bir alternatif sunar.This provides a potential alternative to some of the more manual data synchronization techniques presented in this article. Daha fazla bilgi için genel bakış: SQL veritabanı etkin coğrafi çoğaltma.For more information, see Overview: SQL Database Active Geo-Replication.

Ayrıca, yedekleme için daha fazla el ile bir yaklaşım kullanın ve geri yükleyin.You can also use a more manual approach for backup and restore. İşlemsel tutarlılık veritabanının bir yedeğini oluşturmak için veritabanı kopyasını komutunu kullanın.Use the DATABASE COPY command to create a backup copy of the database with transactional consistency. Azure Blob Depolama alanında depolanan BACPAC dosyalarını (veritabanı şemasını ve ilişkili verileri içeren sıkıştırılmış) verme veritabanlarına destekleyen Azure SQL veritabanı, içeri/dışarı aktarma hizmetini de kullanabilirsiniz.You can also use the import/export service of Azure SQL Database, which supports exporting databases to BACPAC files (compressed files containing your database schema and associated data) that are stored in Azure Blob storage.

Azure Depolama'nın yerleşik yedeklilik aynı bölgedeki yedekleme dosyasını iki kopyasını oluşturur.The built-in redundancy of Azure Storage creates two replicas of the backup file in the same region. Ancak, olağanüstü durum senaryolarda kaybedebilir veri miktarı olan RPO, yedekleme işlemi çalıştırma sıklığını belirler.However, the frequency of running the backup process determines your RPO, which is the amount of data you might lose in disaster scenarios. Örneğin, her saat başında bir yedekleme gerçekleştirmek ve iki dakika önce saatin üstüne bir olağanüstü durum oluştuğunda düşünün.For example, imagine that you perform a backup at the top of each hour, and a disaster occurs two minutes before the top of the hour. Son yedeklemenin gerçekleştirildiği sonra kaydedilen veri 58 dakika kaybedersiniz.You lose 58 minutes of data recorded after the last backup was performed. Ayrıca, bir bölge genelinde hizmet kesintisi karşı korumak için alternatif bir bölgeye BACPAC dosyaları kopyalamanız gerekir.Also, to protect against a region-wide service disruption, you should copy the BACPAC files to an alternate region. Ardından, farklı bölgedeki bu yedekleri geri yükleme seçeneğiniz de vardır.You then have the option of restoring those backups in the alternate region. Daha fazla ayrıntı için genel bakış: SQL veritabanı ile iş sürekliliği ve veritabanı olağanüstü durum kurtarma bulut.For more details, see Overview: Cloud business continuity and database disaster recovery with SQL Database.

SQL Veri AmbarıSQL Data Warehouse

SQL veri ambarı için kullanmak coğrafi yedekleri eşleştirilmiş bir bölge olağanüstü durum kurtarma için geri yüklemek için.For SQL Data Warehouse, use geo-backups to restore to a paired region for disaster recovery. Bu yedeklemeler her 24 saatte alınır ve 20 dakika içinde geri yükleme eşleştirilmiş bölgede olabilir.These backups are taken every 24 hours and can be restore within 20 minutes in the paired region. Bu özellik tüm SQL veri ambarları için varsayılan olarak açıktır.This feature is on by default for all SQL data warehouses. Veri ambarınıza geri yükleme hakkında daha fazla bilgi için bkz. geri PowerShell kullanarak bir Azure coğrafi bölgesinden.For more information on how to restore your data warehouse, see Restore from an Azure geographical region using PowerShell.

Azure StorageAzure Storage

Azure depolama için özel bir yedekleme işlemi geliştirin veya çok sayıda üçüncü taraf yedekleme araçlarından birini kullanın.For Azure Storage, you can develop a custom backup process or use one of many third-party backup tools. Burada depolama kaynaklarını birbirine başvuru birçok uygulama tasarımı ek karmaşıklık gerektiğini unutmayın.Note that most application designs have additional complexities where storage resources reference each other. Örneğin, bir sütunda Azure Depolama'da bir blob bağlanan bir SQL veritabanı göz önünde bulundurun.For example, consider a SQL database that has a column that links to a blob in Azure Storage. Yedekleri aynı anda gerçekleşecek değil, veritabanı hatasından önce yedeklenmedi bir blob için bir işaretçi olabilir.If the backups do not happen simultaneously, the database might have a pointer to a blob that was not backed up before the failure. Uygulama veya olağanüstü durum kurtarma planı işlemleri kurtarma işleminden sonra Bu tutarsızlığı işlemek için uygulamanız gerekir.The application or disaster recovery plan must implement processes to handle this inconsistency after a recovery.

Diğer veri platformlarıOther data platforms

Elasticsearch veya MongoDB, gibi kendi özellikleri ve önemli noktalar bir tümleşik yedekleme ve geri yükleme işlemi oluştururken diğer-olarak-hizmet altyapı (Iaas), veri platformları barındırılan.Other infrastructure-as-a-service (IaaS) hosted data platforms, such as Elasticsearch or MongoDB, have their own capabilities and considerations when creating an integrated backup and restore process. Bu veri platformları için genel bir yerel veya kullanılabilir tümleştirme tabanlı çoğaltma veya olarak anlık görüntüsünün alınması özellikleri kullanmak için önerilir.For these data platforms, the general recommendation is to use any native or available integration-based replication or snapshotting capabilities. Bu özellikler mevcut değil veya uygun olmayan, uygulama verilerinin zaman içinde nokta bir kopyasını oluşturmak için Azure Backup hizmeti veya yönetilen ve yönetilmeyen disk anlık görüntülerini kullanarak düşünün.If those capabilities do not exist or are not suitable, then consider using Azure Backup Service or managed/unmanaged disk snapshots to create a point-in-time copy of application data. Her durumda, tutarlı yedekler, özellikle de uygulama verileri birden çok dosya sistemlerinin yayıldığında veya birden çok sürücü birim yöneticileri veya yazılım tabanlı RAID kullanarak bir tek bir dosya sistemine birleştirildiğinde elde etmek nasıl belirlemek önemlidir.In all cases, it’s important to determine how to achieve consistent backups, especially when application data spans multiple files systems, or when multiple drives are combined into a single file system using volume managers or software-based RAID.

Başvuru veri modelini olağanüstü durum kurtarmaReference data pattern for disaster recovery

Başvuru verileri uygulama işlevselliğini destekleyen salt okunur verilerdir.Reference data is read-only data that supports application functionality. Bu genellikle sık değiştirmez.It typically does not change frequently. Yedekleme ve geri yükleme bölge genelinde hizmet kesintilerini işlemek için bir yöntem olsa RTO görece uzun.Although backup and restore is one method to handle region-wide service disruptions, the RTO is relatively long. Uygulamanın ikincil bir bölgeye dağıttığınızda, bazı stratejiler başvuru verileri için RTO artırabilir.When you deploy the application to a secondary region, some strategies can improve the RTO for reference data.

Olduğundan başvuru veri değişikliklerini seyrek, ikincil bölgede başvuru verilerini kalıcı bir kopyasını tutarak RTO performansını artırabilirsiniz.Because reference data changes infrequently, you can improve the RTO by maintaining a permanent copy of the reference data in the secondary region. Bu, olağanüstü bir durumda yedeklemeleri geri yüklemek için gereken zamanı ortadan kaldırır.This eliminates the time required to restore backups in the event of a disaster. Birden çok bölge olağanüstü durum kurtarma gereksinimlerimizi karşılamak için uygulama ve birden çok bölgede birlikte başvuru verilerini dağıtmanız gerekir.To meet the multiple-region disaster recovery requirements, you must deploy the application and the reference data together in multiple regions. Başvuru verileri rolüne dış depolama alanına veya bir birleşimi için hem de kendisine dağıtabilirsiniz.You can deploy reference data to the role itself, to external storage, or to a combination of both.

Başvuru veri dağıtım modeline işlem düğümleri içinde örtük olarak olağanüstü durum kurtarma gereksinimleri karşılar.The reference data deployment model within compute nodes implicitly satisfies the disaster recovery requirements. Başvuru verileri dağıtımı, SQL veritabanı, her bölge için başvuru verilerinin bir kopyasını dağıtma gerektirir.Reference data deployment to SQL Database requires that you deploy a copy of the reference data to each region. Strateji, Azure depolama için geçerlidir.The same strategy applies to Azure Storage. Birincil ve ikincil bölgeye Azure Depolama'da depolanan tüm başvuru verilerinin bir kopyasını dağıtmanız gerekir.You must deploy a copy of any reference data that's stored in Azure Storage to the primary and secondary regions.

Veri yayınına birincil ve ikincil bölgeler

Başvuru verileri dahil tüm verileri kendi uygulamaya özgü yedekleme yordamları uygulamalısınız.You must implement your own application-specific backup routines for all data, including reference data. Bölgeler arasında coğrafi olarak yedekli kopyalar, yalnızca bir bölge genelinde hizmet kesintisi içinde kullanılır.Geo-replicated copies across regions are used only in a region-wide service disruption. Genişletilmiş bir kapalı kalma süresini önlemek için Görev açısından kritik uygulama verileri bölümlerini ikincil bölgeye dağıtın.To prevent extended downtime, deploy the mission-critical parts of the application’s data to the secondary region. Bu topoloji örneği için bkz: Aktif-Pasif modeli.For an example of this topology, see the active-passive model.

İşlemsel veri modelini olağanüstü durum kurtarmaTransactional data pattern for disaster recovery

Tam olarak işlevsel bir olağanüstü durum modu stratejisinin uygulama ikincil bölgeye işlem verilerini zaman uyumsuz olarak çoğaltılmasını gerektirir.Implementation of a fully functional disaster mode strategy requires asynchronous replication of the transactional data to the secondary region. İçinde çoğaltma oluşabilen pratik zaman pencereleri uygulama RPO özelliklerini belirler.The practical time windows within which the replication can occur will determine the RPO characteristics of the application. Çoğaltma penceresi sırasında birincil bölgeden kayıp veri kurtarmaya devam.You might still recover the data that was lost from the primary region during the replication window. Daha sonra ikincil bölgeye ile birleştirebilmesi olabilir.You might also be able to merge with the secondary region later.

Aşağıdaki örnekler mimarisi bir yük devretme senaryosunda işlem tabanlı veri işleme için çeşitli yollar hakkında bazı fikirler sağlayın.The following architecture examples provide some ideas on different ways of handling transactional data in a failover scenario. Bu örneklerin ayrıntılı olmadığına dikkat edin önemlidir.It's important to note that these examples are not exhaustive. Örneğin, Ara depolama konumlarına kuyruklar gibi Azure SQL veritabanı ile değiştirilebilir.For example, intermediate storage locations such as queues might be replaced with Azure SQL Database. Kuyrukların kendileri, Azure depolama veya Azure Service Bus kuyrukları olabilir (bakın Azure kuyrukları ve Service Bus kuyrukları - benzerlikler ve karşıtlıklar).The queues themselves might be either Azure Storage or Azure Service Bus queues (see Azure queues and Service Bus queues - compared and contrasted). Sunucu depolama konumlarını Ayrıca, SQL veritabanı yerine Azure tabloları gibi farklı olabilir.Server storage destinations might also vary, such as Azure tables instead of SQL Database. Ayrıca, çalışan rolleri, çeşitli adımlarda aracılar olarak eklenebilir.In addition, worker roles might be inserted as intermediaries in various steps. Bu mimari tam olarak öykünmek değil ancak ilgili modüller ve işlem tabanlı veri kurtarma çeşitli alternatifler dikkate alınması gereken hedeftir.The intent is not to emulate these architectures exactly, but to consider various alternatives in the recovery of transactional data and related modules.

Olağanüstü durum kurtarma için hazırlığı kapsamında işlem verilerini çoğaltmaReplication of transactional data in preparation for disaster recovery

İşlem verileri tutmak için Azure depolama kuyruklarını kullanan bir uygulamayı düşünün.Consider an application that uses Azure Storage queues to hold transactional data. Bu, çalışan rolleri, ayrılmış bir mimari sunucu veritabanında işlem verilerini işlemek sağlar.This allows worker roles to process the transactional data to the server database in a decoupled architecture. Bu, ön uç rollerini bu verilerin anında sorgu gerekiyorsa, geçici olarak önbelleğe alma biçimi kullanmak için işlemleri gerektirir.This requires the transactions to use some form of temporary caching if the front-end roles require the immediate query of that data. Veri kaybı toleransı düzeyine bağlı olarak, kuyruklar, veritabanı veya depolama kaynakların tümünü çoğaltmak seçebilirsiniz.Depending on the level of data-loss tolerance, you might choose to replicate the queues, the database, or all of the storage resources. Birincil bölge kesilse birincil bölgeye geri geldiğinde yalnızca veritabanı çoğaltması ile kuyruklarda veri kurtarmaya devam edebilirsiniz.With only database replication, if the primary region goes down, you can still recover the data in the queues when the primary region comes back.

Aşağıdaki diyagramda, burada veritabanını bölgeler arasında eşitlenen bir mimari gösterilmektedir.The following diagram shows an architecture where the server database is synchronized across regions.

Olağanüstü durum kurtarma için hazırlığı kapsamında işlem verilerini çoğaltma

Bu mimari uygulamak için en büyük güçlük bölgeler arasında çoğaltma stratejisidir.The biggest challenge to implementing this architecture is the replication strategy between regions. Azure SQL Data Sync hizmeti, bu tür bir çoğaltma sağlar.The Azure SQL Data Sync service enables this type of replication. Şu andan itibaren hizmet Önizleme aşamasındadır ve henüz üretim ortamları için önerilmez.As of this writing, the service is in preview and is not yet recommended for production environments. Daha fazla bilgi için genel bakış: SQL veritabanı ile iş sürekliliği ve veritabanı olağanüstü durum kurtarma bulut.For more information, see Overview: Cloud business continuity and database disaster recovery with SQL Database. Üretim uygulamaları için kod içinde kendi çoğaltma mantığı oluşturma veya üçüncü taraf çözümde yatırım gerekir.For production applications, you must invest in a third-party solution or create your own replication logic in code. Mimarisine bağlı olarak, çift yönlü, daha karmaşık olan çoğaltma olabilir.Depending on the architecture, the replication might be bidirectional, which is more complex.

Olası uygulama yapabileceğiniz kullanın, önceki örnekte ara sıra.One potential implementation might make use of the intermediate queue in the previous example. Son depolama hedefi verileri işler çalışan rolü, hem birincil bölge hem de ikincil bölgeye değişiklik neden olabilir.The worker role that processes the data to the final storage destination might make the change in both the primary region and the secondary region. Bu Önemsiz görevler değildir ve bu makalenin kapsamı dışındadır çoğaltma kod için tam yönergeler verilmiştir.These are not trivial tasks, and complete guidance for replication code is beyond the scope of this article. Zaman ve ikincil bölgeye veri çoğaltma için bir yaklaşım içine test yaparlar.Invest significant time and testing into the approach for replicating data to the secondary region. Ek işleme ve test, yük devretme ve kurtarma işlemlerini herhangi bir olası veri tutarsızlıkları veya yinelenen işlemler doğru bir şekilde işlemek sağlanmasına yardımcı olur.Additional processing and testing can help ensure that the failover and recovery processes correctly handle any possible data inconsistencies or duplicate transactions.

Not

Çoğu Bu yazıda, platform (PaaS) hizmet olarak odaklanır.Most of this paper focuses on platform as a service (PaaS). Ancak, karma uygulamalar için ek çoğaltma ve kullanılabilirlik seçenekleri, Azure sanal makinelerini kullanın.However, additional replication and availability options for hybrid applications use Azure Virtual Machines. Bu karma uygulamalar, Azure içindeki sanal makinelerde SQL Server barındırma (Iaas) hizmet olarak altyapı kullanın.These hybrid applications use infrastructure as a service (IaaS) to host SQL Server on virtual machines in Azure. Bu SQL Server'da AlwaysOn Kullanılabilirlik grupları veya günlük aktarma gibi geleneksel kullanılabilirlik yaklaşım sağlar.This allows traditional availability approaches in SQL Server, such as AlwaysOn Availability Groups or Log Shipping. AlwaysOn gibi bazı teknikleri, yalnızca şirket içi SQL Server örnekleri ve Azure sanal makineler arasında çalışır.Some techniques, such as AlwaysOn, work only between on-premises SQL Server instances and Azure virtual machines. Daha fazla bilgi için Azure sanal Makineler'de SQL Server için yüksek kullanılabilirlik ve olağanüstü durum kurtarma.For more information, see High availability and disaster recovery for SQL Server in Azure Virtual Machines.

İşlem yakalama için azaltılmış uygulama işleviReduced application functionality for transaction capture

Sınırlı işlevsellikte işleyen ikinci bir mimari kullanmayı düşünün.Consider a second architecture that operates with reduced functionality. İkincil bölgedeki uygulama raporlama, iş zekası (BI) ya da kuyruklar boşaltma gibi tüm işlevleri, devre dışı bırakır.The application in the secondary region deactivates all the functionality, such as reporting, business intelligence (BI), or draining queues. Bu iş gereksinimleri tarafından tanımlanan işlem tabanlı iş akışları, yalnızca en önemli türlerini kabul eder.It accepts only the most important types of transactional workflows, as defined by business requirements. Sistem işlemleri yakalar ve kuyruklara yazar.The system captures the transactions and writes them to queues. Sistem, hizmet kesintisi ilk aşaması sırasında veri işlemeyi erteleme.The system might postpone processing the data during the initial stage of the service disruption. Birincil bölge sisteminde beklenen zaman aralığında yeniden etkinleştirildiğinde, çalışan rolleri birincil bölgedeki kuyrukları tükenir.If the system on the primary region is reactivated within the expected time window, the worker roles in the primary region can drain the queues. Bu işlem veritabanı birleştirme gereğini ortadan kaldırır.This process eliminates the need for database merging. Fazla aktarmalı birincil bölgeden hizmet kesintisi yaşanırsa uygulama kuyrukların işleme başlayabilirsiniz.If the primary region service disruption goes beyond the tolerable window, the application can start processing the queues.

Bu senaryoda, ikincil bölgede veritabanı birincil yeniden etkinleştirildikten sonra birleştirilmelidir artımlı işlemsel verileri içerir.In this scenario, the database in the secondary region contains incremental transactional data that must be merged after the primary is reactivated. Aşağıdaki diyagramda, birincil bölgeye geri yüklenene kadar geçici olarak işlem verilerini depolamak için bu stratejiyi gösterir.The following diagram shows this strategy for temporarily storing transactional data until the primary region is restored.

İşlem yakalama için azaltılmış uygulama işlevi

Veri Yönetimi teknikleri dayanıklı Azure uygulamaları için daha fazla bilgi için bkz. hatasız: Yönergeler için dayanıklı bulut mimarileri.For more discussion of data management techniques for resilient Azure applications, see Failsafe: Guidance for Resilient Cloud Architectures.

Olağanüstü durum kurtarma için dağıtım topolojileriDeployment topologies for disaster recovery

Bölge genelinde hizmet kesintilerini işlemek için Görev açısından kritik uygulamaları hazırlamanız gerekir.You must prepare mission-critical applications to handle region-wide service disruptions. Birden çok bölgeli dağıtım stratejisini işletimsel planlama içine dahil edilip derecelendirilir.Incorporate a multiple-region deployment strategy into the operational planning.

Birden çok bölgeli dağıtımlar uygulama ve başvuru verileri ikincil bölgeye bir olağanüstü durum sonrası yayımlamak için BT işlemleri gerektirebilir.Multiple-region deployments might involve IT processes to publish the application and reference data to the secondary region after a disaster. Uygulama için anında yük devretme gerekiyorsa, dağıtım işlemi bir Aktif/Pasif Kurulum veya aktif/aktif Kurulum gerektirebilir.If the application requires instant failover, the deployment process might involve an active/passive setup or an active/active setup. Bu dağıtım türünde mevcut alternatif bölgesinde çalıştırılan uygulama örneklerini sahiptir.This type of deployment has existing instances of the application running in the alternate region. Bir yönlendirme hizmeti gibi Azure Traffic Manager DNS düzeyinde Yük Dengeleme hizmetleri sunar.A routing service such as Azure Traffic Manager provides load-balancing services at the DNS level. Bu hizmet kesintilerini algılamak ve gerektiğinde farklı bölgelerdeki kullanıcılara yol.It can detect service disruptions and route the users to different regions when needed.

Bu kurtarma başından itibaren çözüm oluşturma başarılı Azure'a olağanüstü durum kurtarma içerir.A successful Azure disaster recovery includes building that recovery into the solution from the start. Bulut, geleneksel bir barındırma sağlayıcısında mevcut olmayan bir olağanüstü durum sırasında arızalarına karşı kurtarmak için ek seçenekler sağlar.The cloud provides additional options for recovering from failures during a disaster that are not available in a traditional hosting provider. Özellikle, bir hata önce boşta kaynakların maliyetini önleme farklı bir bölgede kaynakları dinamik olarak ve hızlı bir şekilde ayırabilirsiniz.Specifically, you can dynamically and quickly allocate resources in a different region, avoiding the cost of idle resources prior to a failure.

Aşağıdaki bölümlerde, olağanüstü durum kurtarma için farklı dağıtım topolojileri kapsar.The following sections cover different deployment topologies for disaster recovery. Genellikle, var. bir tradeoff daha yüksek maliyet veya ek kullanılabilirlik için karmaşıklıkTypically, there's a tradeoff in increased cost or complexity for additional availability.

Tek bölgeli dağıtımSingle-region deployment

Tek bölge dağıtımlara gerçekten bir olağanüstü durum kurtarma topoloji değildir, ancak diğer mimarileri karşıtlığını yöneliktir.A single-region deployment is not really a disaster recovery topology, but is meant to contrast with the other architectures. Tek bölgeli dağıtımları, azure'de uygulamalar için yaygın olarak; Ancak, bir olağanüstü durum kurtarma topolojisi gereksinimlerini karşılamıyor.Single-region deployments are common for applications in Azure; however, they do not meet the requirements of a disaster recovery topology.

Aşağıdaki diyagramda, tek bir Azure bölgesinde çalışan bir uygulama gösterilmektedir.The following diagram depicts an application running in a single Azure region. Azure Traffic Manager ve hata ve yükseltme etki alanları kullanımını bölge içinde bir uygulamanın kullanılabilirliğini artırın.Azure Traffic Manager and the use of fault and upgrade domains increase availability of the application within the region.

Tek bölgeli dağıtım

Bu senaryoda, bir tek hata noktası veritabanıdır.In this scenario, the database is a single point of failure. Azure, iç kopyaya farklı hata etki alanları arasında verileri çoğaltan rağmen bu çoğaltma, yalnızca aynı bölge içinde gerçekleşir.Though Azure replicates the data across different fault domains to internal replicas, this replication occurs only within the same region. Uygulama, geri dönülemez bir arıza hataya dayanamaz olamaz.The application cannot withstand a catastrophic failure. Bölge kullanılamaz duruma gelirse, bu nedenle tüm hizmet örneklerini ve depolama kaynakları dahil olmak üzere hata etki alanları yapın.If the region becomes unavailable, then so do the fault domains, including all service instances and storage resources.

Tüm ancak en az önemli uygulamalar, uygulamalarınızı birden çok bölgede dağıtma için bir plan oluşturmanız gerekir.For all but the least critical applications, you must devise a plan to deploy your applications across multiple regions. Ayrıca, RTO göz önünde bulundurun ve kullanmak için hangi dağıtım topolojisi dikkate sınırlamaları maliyet gerekir.You should also consider RTO and cost constraints in considering which deployment topology to use.

Farklı bölgeler arasında yük devretme destek belirli yaklaşımlar şimdi bir göz atalım.Let's take a look now at specific approaches to supporting failover across different regions. Bu örneklerin tümü, işlem açıklamak için iki bölge kullanın.These examples all use two regions to describe the process.

Azure Site Recovery kullanarak yük devretmeFailover using Azure Site Recovery

Azure Site Recovery kullanarak Azure VM çoğaltmayı etkinleştirdiğinizde, çeşitli kaynaklar ikincil bölgede oluşturur:When you enable Azure VM replication using Azure Site Recovery, it creates several resources in the secondary region:

  • Kaynak grubu.Resource group.
  • Sanal ağ (VNet).Virtual network (VNet).
  • Depolama hesabı.Storage account.
  • Yük devretme sonrasında Vm'leri barındırmak için kullanılabilirlik kümeleri.Availability sets to hold VMs after failover.

Birincil bölgedeki VM disk üzerindeki veri yazma, sürekli olarak ikincil bölgede depolama hesabına aktarılır.Data writes on the VM disks in the primary region are continuously transferred to the storage account in the secondary region. Kurtarma noktaları hedef depolama hesabında birkaç dakikada oluşturulur.Recovery points are generated in the target storage account every few minutes. Bir yük devretme başlatın, kurtarılan VM'ler hedef kaynak grubu, sanal ağ ve kullanılabilirlik kümesi içinde oluşturulur.When you initiate a failover, the recovered VMs are created in the target resource group, VNet, and availability set. Yük devretme sırasında herhangi bir kullanılabilir kurtarma noktası seçebilirsiniz.During a failover, you can choose any available recovery point.

İkincil bir Azure bölgesine yeniden dağıtmaRedeployment to a secondary Azure region

Yaklaşım, yeniden dağıtım için ikincil bir bölgeye, uygulamaları ve veritabanlarının çalışan yalnızca birincil bölgeye sahiptir.For the approach of redeployment to a secondary region, only the primary region has applications and databases running. İkincil bölgeye otomatik yük devretme için ayarlanmadı.The secondary region is not set up for an automatic failover. Böylece olağanüstü bir durum gerçekleştiğinde, hizmet yeni bölgedeki tüm bölümleri hızlanması gerekir.So when a disaster occurs, you must spin up all the parts of the service in the new region. Bu bulut hizmeti dağıtma, verilerin geri yüklenmesi ve DNS trafiği yönlendirecek şekilde değiştirerek Azure'a bir bulut hizmeti karşıya içerir.This includes uploading a cloud service to Azure, deploying the cloud service, restoring the data, and changing DNS to reroute the traffic.

Birden çok bölgeli seçeneklerin en Hesaplı olsa da en kötü RTO özelliklere sahiptir.Although this is the most affordable of the multiple-region options, it has the worst RTO characteristics. Bu modelde, hizmet paketi ve veritabanı yedeklemelerini depolanan şirket içinde veya Azure Blob Depolama örneğinde ikincil bölgeye.In this model, the service package and database backups are stored either on-premises or in the Azure Blob storage instance of the secondary region. Ancak, yeni bir hizmeti dağıtma ve işlemi sürdürür önce verileri geri yükleyin.However, you must deploy a new service and restore the data before it resumes operation. Hatta tam otomasyonla yedekleme depolamadan veri aktarımı, çok zaman yeni bir veritabanı ortam sağlama kullanır.Even with full automation of the data transfer from backup storage, provisioning a new database environment consumes a lot of time. Veri yedekleme disk depolama alanından boş veritabanı için ikincil bölgede yapılması taşıma, geri yükleme işlemi en pahalı parçasıdır.Moving data from the backup disk storage to the empty database on the secondary region is the most expensive part of the restore process. Bununla birlikte, çoğaltılan değil çünkü yeni veritabanını çalışır duruma getirmek için bunu gerekir.You must do this, however, to bring the new database to an operational state because it isn't replicated.

Hizmet paketleri ikincil bölgedeki Blob storage'da depolamak için en iyi yaklaşımdır bakın.The best approach is to store the service packages in Blob storage in the secondary region. Bu, bir şirket içi geliştirme makinesinden dağıttığınızda ne olan Azure, paket yükleme gereğini ortadan kaldırır.This eliminates the need to upload the package to Azure, which is what happens when you deploy from an on-premises development machine. Hizmet paketleri yeni bir bulut hizmeti için Blob depolama alanından PowerShell betiklerini kullanarak dağıtabilirsiniz.You can quickly deploy the service packages to a new cloud service from Blob storage by using PowerShell scripts.

Bu seçenek, yüksek bir RTO toleransına kritik olmayan uygulamalar için pratik bir yöntemdir.This option is practical only for non-critical applications that can tolerate a high RTO. Bu, örneğin, birkaç saat boyunca kapalı olabilir, ancak 24 saat içinde kullanılabilir olması için gerekli bir uygulama için çalışabilir.For instance, this might work for an application that can be down for several hours but is required to be available within 24 hours.

İkincil bir Azure bölgesine yeniden dağıtma

Aktif-pasifActive-passive

Birçok şirket favor seçim bir Aktif-Pasif topolojidir.An active-passive topology is the choice that many companies favor. Bu topoloji iyileştirmeler yeniden dağıtım yaklaşımı maliyet görece küçük bir artış ile RTO için sağlar.This topology provides improvements to the RTO with a relatively small increase in cost over the redeployment approach. Bu senaryoda, yok birincil ve ikincil bir Azure bölgesi.In this scenario, there is again a primary and a secondary Azure region. Tüm trafiği birincil bölgeye üzerinde etkin dağıtıma gider.All of the traffic goes to the active deployment on the primary region. Veritabanı iki bölgeleri üzerinde çalıştığından ikincil bölgeye daha iyi olağanüstü durum kurtarma için hazır.The secondary region is better prepared for disaster recovery because the database is running on both regions. Ayrıca, bir eşitleme bunlar arasında bir yerde mekanizmadır.Additionally, a synchronization mechanism is in place between them. Bekleme bu yaklaşımın iki çeşidi içerebilir: veritabanı yalnızca bir yaklaşım veya ikincil bölgedeki tam dağıtımı.This standby approach can involve two variations: a database-only approach or a complete deployment in the secondary region.

Yalnızca veritabanıDatabase only

Aktif-Pasif topolojinin ilk varyasyonu yalnızca birincil bölgeye dağıtılmış bulut hizmeti uygulaması vardır.In the first variation of the active-passive topology, only the primary region has a deployed cloud service application. Ancak, yeniden dağıtım yaklaşımının aksine, her iki bölgede veritabanı içeriğiyle eşitlenir.However, unlike the redeployment approach, both regions are synchronized with the contents of the database. (Daha fazla bilgi için üzerinde bölümüne bakın. olağanüstü durum kurtarma için işlemsel veri modelini.) Olağanüstü bir durum gerçekleştiğinde, daha az etkinleştirme gereksinimi yoktur.(For more information, see the section on transactional data pattern for disaster recovery.) When a disaster occurs, there are fewer activation requirements. İkincil bölge'de uygulamayı başlatmak için yeni veritabanı bağlantı dizelerini değiştirmek ve trafiği yeniden yönlendirmek için DNS girişleri değiştirin.You start the application in the secondary region, change connection strings to the new database, and change the DNS entries to reroute traffic.

Yeniden dağıtım yaklaşımı gibi zaten hizmet paketleri daha hızlı dağıtım için ikincil bölgedeki Azure Blob storage'da depoladığınız.Like the redeployment approach, you should have already stored the service packages in Azure Blob storage in the secondary region for faster deployment. Ancak, veritabanının hazır ve çalışır durumda olduğundan, veritabanı geri yükleme işlemi gerektiren ek yükü çoğunu uygulanmaz.However, you don’t incur the majority of the overhead that database restore operation requires, because the database is ready and running. Bu, uygun maliyetli bir DR desen (ve en sık kullanılan) yaparak bu süreyi önemli ölçüde tasarruf sağlar.This saves a significant amount of time, making this an affordable DR pattern (and the one most frequently used).

Aktif-Pasif, yalnızca veritabanı

Tam çoğaltmaFull replica

Aktif-Pasif topolojinin ikinci varyasyonu, tam bir dağıtım hem birincil bölge hem de ikincil bölgeye sahiptir.In the second variation of the active-passive topology, both the primary region and the secondary region have a full deployment. Bu dağıtım, bulut Hizmetleri ile eşitlenmiş veritabanı içerir.This deployment includes the cloud services and a synchronized database. Ancak, yalnızca birincil bölge etkin bir şekilde kullanıcılardan ağ istekleri işlediğinin.However, only the primary region is actively handling network requests from the users. Yalnızca birincil bölgeye bir hizmet kesintisi yaşandığında ikincil bölgeye etkin hale gelir.The secondary region becomes active only when the primary region experiences a service disruption. Bu durumda, tüm yeni ağ istekleri ikincil bölgeye yol.In that case, all new network requests route to the secondary region. Azure Traffic Manager, bu yük devretme otomatik olarak yönetebilirsiniz.Azure Traffic Manager can manage this failover automatically.

Yük devretme, yalnızca veritabanı değişim daha hızlı Hizmetleri zaten dağıtılmış olan oluşur.Failover occurs faster than the database-only variation because the services are already deployed. Bu topoloji, çok düşük bir RTO sağlar.This topology provides a very low RTO. İkincil bir yük devretme bölge birincil bölgeye sahip hatasından sonra hemen kullanıma hazır olması gerekir.The secondary failover region must be ready to go immediately after failure of the primary region.

Bu topoloji, daha hızlı yanıt süresi, birlikte önceden ayırır ve yedekleme hizmetleri, olağanüstü bir durum sırasında yeni örnekleri ayrılacak alanı yetersizliği olasılığını önleme dağıtır.Along with a quicker response time, this topology pre-allocates and deploys backup services, avoiding the possibility of a lack of space to allocate new instances during a disaster. Bu, ikincil Azure bölgesine kapasitesine yaklaşıyor durumunda önemlidir.This is important if your secondary Azure region is nearing capacity. Hiçbir hizmet düzeyi sözleşmesi (SLA) garanti eder herhangi bir bölgedeki bir veya daha fazla yeni bulut Hizmetleri hemen dağıtabilirsiniz.No service-level agreement (SLA) guarantees that you can instantly deploy one or more new cloud services in any region.

Bu modelde en hızlı yanıt süresi için birincil ve ikincil bölgede benzer Ölçek (Rol örneklerinin sayısını) olmalıdır.For the fastest response time with this model, you must have similar scale (number of role instances) in the primary and secondary regions. Avantajları rağmen kullanılmayan bilgi işlem örnekleri için ödeme maliyetlidir ve bu en akıllıca finansal seçim olmayabilir.Despite the advantages, paying for unused compute instances is costly, and this might not be the most prudent financial choice. Bu nedenle, ikincil bölgede yapılması bulut Hizmetleri biraz ölçeği aşağı sürümünü kullanmak için daha yaygındır.Because of this, it's more common to use a slightly scaled-down version of cloud services on the secondary region. Ardından Hızlı yük devretme ve gerekirse ikincil dağıtımını ölçeklendirin.Then you can quickly fail over and scale out the secondary deployment if necessary. Yük devretme işlemini otomatik hale birincil bölgeye erişilemez duruma geldikten sonra yüke bağlı olarak ek örnekleri etkinleştirmeniz.You should automate the failover process so that after the primary region is inaccessible, you activate additional instances, depending on the load. Bu gibi bir otomatik ölçeklendirme mekanizması kullanımını gerektirebilir sanal makine ölçek kümeleri.This might involve the use of an autoscaling mechanism like virtual machine scale sets.

Aşağıdaki diyagramda, burada bir Aktif-Pasif topolojisinde tam olarak dağıtılmış bir bulut hizmeti birincil ve ikincil bölge içeren modeli gösterilmektedir.The following diagram shows the model where the primary and secondary regions contain a fully deployed cloud service in an active-passive topology.

Aktif-Pasif, tam çoğaltma

Etkin-etkinActive-active

Etkin-etkin bir topolojide, tam olarak cloud services ve veritabanı için her iki bölgede de dağıtılır.In an active-active topology, the cloud services and database are fully deployed in both regions. Aktif-Pasif modelin aksine, kullanıcı trafiğini iki bölgeleri alırsınız.Unlike the active-passive model, both regions receive user traffic. Bu seçenek, Hızlı Kurtarma zamanı verir.This option yields the quickest recovery time. Hizmetleri her bölgede iş yükünün bir bölümü işlemek için zaten ölçeklenir.The services are already scaled to handle a portion of the load at each region. DNS, zaten ikincil bölgeye kullanacak şekilde etkinleştirilmiştir.DNS is already enabled to use the secondary region. Kullanıcılar için uygun bölgeyi yönlendirmek nasıl saptanırken karmaşıklık yoktur.There's additional complexity in determining how to route users to the appropriate region. Hepsini bir kez deneme zamanlama mümkün olabilir.Round-robin scheduling might be possible. Belirli kullanıcıları belirli bir bölgeye birincil kopya verilerinin yer aldığı kullanmanızı daha yüksektir.It's more likely that certain users would use a specific region where the primary copy of their data resides.

Yük devretme durumunda, birincil bölgeye yalnızca DNS devre dışı.In case of failover, simply disable DNS to the primary region. Bu, tüm trafiği ikincil bölgeye yönlendirir.This routes all traffic to the secondary region.

Bu modelde, hatta bazı farklılıklar vardır.Even in this model, there are some variations. Örneğin, ana veritabanı kopyasını sahibi olan bir birincil bölge Aşağıdaki diyagramda gösterilmiştir.For example, the following diagram depicts a primary region which owns the master copy of the database. Bulut hizmetleri her iki bölgede de birincil veritabanına yazın.The cloud services in both regions write to that primary database. İkincil dağıtım birincil ya da çoğaltılan veritabanından okuyabilirsiniz.The secondary deployment can read from the primary or replicated database. Bu örnekte çoğaltmalar tek yönlüdür.Replication in this example is one-way.

Etkin-etkin

Önceki şemada etkin-etkin mimaride bir dezavantajı vardır.There is a downside to the active-active architecture in the preceding diagram. Ana kopya var. bulunduğundan ikinci bir bölgeye ilk bölgeye veritabanına erişmeniz gerekir.The second region must access the database in the first region because the master copy resides there. Bir bölge dışından verileri eriştiğinizde performansı ciddi ölçüde düştüğü.Performance significantly drops off when you access data from outside a region. Bölgeler arası veritabanı çağrılarında bazı tür grubu oluşturma stratejisi bu çağrılardan performansını artırmak için göz önünde bulundurmalısınız.In cross-region database calls, you should consider some type of batching strategy to improve the performance of these calls. Daha fazla bilgi için SQL veritabanı uygulama performansını artırmak için toplu işlem kullanma nasıl.For more information, see How to use batching to improve SQL Database application performance.

Alternatif bir mimari, kendi veritabanına doğrudan erişme her bir bölgeye gerektirebilir.An alternative architecture might involve each region accessing its own database directly. Bu modelde, herhangi bir türde iki yönlü çoğaltmayı, her bölgede veritabanlarını eşitlemek için gereklidir.In that model, some type of bidirectional replication is required to synchronize the databases in each region.

Önceki topolojilerle RTO genellikle azaltarak maliyetleri ve karmaşıklığı artırır.With the previous topologies, decreasing RTO generally increases costs and complexity. Etkin-etkin topolojisi farklılık göstermesi bu maliyet deseni.The active-active topology deviates from this cost pattern. Etkin-etkin topolojide, birincil bölgeye Aktif-Pasif topolojide olduğu gibi çok örneklerinde gerekmeyebilir.In the active-active topology, you might not need as many instances on the primary region as you would in the active-passive topology. Birincil bölgede bir Aktif-Pasif mimari üzerinde 10 örnek varsa, yalnızca bir etkin-etkin mimarisinde her bölgede 5 gerekebilir.If you have 10 instances on the primary region in an active-passive architecture, you might need only 5 in each region in an active-active architecture. Her iki bölgeleri artık yük paylaşın.Both regions now share the load. Bu, bir yarı etkin edilgen bölgeyi temel yük devretme için bekleme 10 örnek ile bekleme tutarsanız maliyet tasarrufu Aktif-Pasif topoloji üzerinde olabilir.This might be a cost savings over the active-passive topology if you keep a warm standby on the passive region with 10 instances waiting for failover.

İkincil bölgeye birincil bölgeye geri yükleyene kadar yeni kullanıcıların ani aşırı yükleme talebiyle alabilirsiniz farkında olun.Realize that until you restore the primary region, the secondary region might receive a sudden surge of new users. 10.000 kullanıcı varsa her sunucuda birincil bölgeye bir hizmet kesintisi yaşandığında, 20.000 kullanıcı işlemek ikincil bölgeye aniden sahiptir.If there are 10,000 users on each server when the primary region experiences a service disruption, the secondary region suddenly has to handle 20,000 users. İkincil bölgeye kurallarında izleme bu artış ve çift örnekleri ikincil bölgede algılaması gerekir.Monitoring rules on the secondary region must detect this increase and double the instances in the secondary region. Bunun hakkında daha fazla bilgi için üzerinde bölümüne bakın. hata algılama.For more information on this, see the section on failure detection.

Karma şirket içi ve bulut çözümüHybrid on-premises and cloud solution

Şirket içinde çalışan bir hibrit uygulama oluşturmak için ek bir olağanüstü durum kurtarma stratejisi olan ve bulut.One additional strategy for disaster recovery is to architect a hybrid application that runs on-premises and in the cloud. Uygulamaya bağlı olarak, birincil bölgeye iki konumdan olabilir.Depending on the application, the primary region might be either location. Önceki mimarileri göz önünde bulundurun ve birincil veya ikincil bölgeye bir şirket içi konumunuz olarak düşünün.Consider the previous architectures and imagine the primary or secondary region as an on-premises location.

Bu karma mimarilerde bazı zorluklar vardır.There are some challenges in these hybrid architectures. İlk olarak, bu makalenin en ele PaaS mimarisi desenleri.First, most of this article has addressed PaaS architecture patterns. Azure'a özel yapılar Traffic Manager rolleri ve bulut Hizmetleri gibi Azure PaaS uygulamalarda tipik dayanır.Typical PaaS applications in Azure rely on Azure-specific constructs such as roles, cloud services, and Traffic Manager. Bu tür bir PaaS uygulama için bir şirket içi çözüm oluşturmayı önemli ölçüde farklı bir mimari gerektirir.Creating an on-premises solution for this type of PaaS application would require a significantly different architecture. Bu yönetim ya da maliyet açısından uygun olmayabilir.This might not be feasible from a management or cost perspective.

Ancak, olağanüstü durum kurtarma için karma bir çözüm mimarileri Iaas temelli gibi buluta geçirilmiş geleneksel mimarilerde için daha az zorlukları vardır.However, a hybrid solution for disaster recovery has fewer challenges for traditional architectures that have been migrated to the cloud, such as IaaS-based architectures. Iaas uygulamaları doğrudan şirket içi eşdeğeri olan bulutta sanal makineler kullanır.IaaS applications use virtual machines in the cloud that can have direct on-premises equivalents. Sanal ağlar, buluttaki makineler ile şirket içi ağ kaynaklarına bağlanmak için de kullanabilirsiniz.You can also use virtual networks to connect machines in the cloud with on-premises network resources. Bu, yalnızca PaaS uygulamaları ile mümkün olmayan çeşitli olanaklar sağlar.This allows several possibilities that are not possible with PaaS-only applications. Örneğin, SQL Server AlwaysOn Kullanılabilirlik grupları hem de veritabanı yansıtma gibi olağanüstü durum kurtarma çözümleri yararlanabilirsiniz.For example, SQL Server can take advantage of disaster recovery solutions such as AlwaysOn Availability Groups and database mirroring. Ayrıntılar için bkz yüksek kullanılabilirlik ve olağanüstü durum kurtarma için SQL Server Azure sanal makineler'de.For details, see High availability and disaster recovery for SQL Server in Azure virtual machines.

Iaas çözümlerini de yük devretme seçeneği Azure'ı kullanmak şirket içi uygulamalar için daha kolay bir yol sağlar.IaaS solutions also provide an easier path for on-premises applications to use Azure as the failover option. Mevcut bir şirket içi bölgesinde tümüyle işlevsel bir uygulamaya sahip olabilir.You might have a fully functioning application in an existing on-premises region. Bununla birlikte, yük devretme için coğrafi olarak ayrı bir bölge korumak için gereken kaynakları yetersiz ne olur?However, what if you lack the resources to maintain a geographically separate region for failover? Uygulamanızı Azure'da çalışan sanal makineler ve sanal ağlar'ı kullanmaya karar verebilir.You might decide to use virtual machines and virtual networks to get your application running in Azure. Bu durumda, verileri buluta eşitleme işlemleri tanımlayın.In that case, define processes that synchronize data to the cloud. Azure dağıtım ikincil bölgeye yük devretme için kullanılacak olur.The Azure deployment then becomes the secondary region to use for failover. Birincil bölge, şirket içi uygulama kalır.The primary region remains the on-premises application. Iaas mimarileri ve özellikleri hakkında daha fazla bilgi için bkz. sanal makineler belgeleri.For more information about IaaS architectures and capabilities, see the Virtual Machines documentation.

Alternatif bulutAlternative cloud

Burada Microsoft Azure'un geniş yeteneklerini hala dahili uyumluluk kuralları veya kuruluşunuz tarafından gerekli ilkelerini karşılamayabilir durumlar vardır.There are situations where the broad capabilities of Microsoft Azure still may not meet internal compliance rules or policies required by your organization. Bile en iyi hazırlama ve bir olağanüstü durum sırasında yedekleme sistemlerini uygulamak için tasarım bir bulut hizmeti sağlayıcısının genel hizmet kesintisi sırasında yetersiz.Even the best preparation and design to implement backup systems during a disaster are inadequate during a global service disruption of a cloud service provider.

Kullanılabilirlik gereksinimlerini maliyet ve karmaşıklığı ile yüksek kullanılabilirlik ile karşılaştırmanız gerekir.You should compare availability requirements with the cost and complexity of increased availability. Risk analizi gerçekleştirin ve RTO ve RPO, çözümünüz için tanımlayın.Perform a risk analysis, and define the RTO and RPO for your solution. Uygulamanızı kapalı kalma süresi kabul etmiyorsa ek bulut çözümünü kullanmayı düşünebilirsiniz.If your application cannot tolerate any downtime, you might consider using an additional cloud solution. Tüm Internet arıza sürece başka bir bulut çözümü Azure küresel olarak erişilemez hale gelirse, kullanılabilir olabilir.Unless the entire Internet goes down, another cloud solution might still be available if Azure becomes globally inaccessible.

Karma senaryo olduğu gibi önceki olağanüstü durum kurtarma mimarileri devretme dağıtımlarında da başka bir bulut çözümü içinde mevcut olabilir.As with the hybrid scenario, the failover deployments in the previous disaster recovery architectures can also exist within another cloud solution. Alternatif bulut DR siteleri yalnızca çok az, varsa, kapalı kalma süresi olan bir RTO sağlar çözümleri için kullanılmalıdır.Alternative cloud DR sites should be used only for solutions whose RTO allows very little, if any, downtime. Azure dışındaki bir DR sitesi kullanan bir çözüm yapılandırma, geliştirme, dağıtma ve korumak için daha fazla iş gerektiğini unutmayın.Note that a solution that uses a DR site outside Azure will require more work to configure, develop, deploy, and maintain. Ayrıca, Bulutlar arası mimaride kendini kanıtlamış yöntemleri uygulamak daha zor.It's also more difficult to implement proven practices in a cross-cloud architecture. Bulut platformları benzer bir üst düzey kavramlarını olmakla birlikte, API'ler ve mimariler farklıdır.Although cloud platforms have similar high-level concepts, the APIs and architectures are different.

DR stratejinize birden çok bulut platformu dayanıyorsa, çözümün tasarım Soyutlama Katmanı eklemek için değerlidir.If your DR strategy relies upon multiple cloud platforms, it's valuable to include abstraction layers in the design of the solution. Bu, geliştirme ve olağanüstü durum oluşması halinde, farklı bulut platformları için aynı uygulamanın farklı iki versiyonunu bakımının ihtiyacını ortadan kaldırır.This eliminates the need to develop and maintain two different versions of the same application for different cloud platforms in case of disaster. Olarak karma senaryo ile Azure Container Service ile Azure sanal makineleri ve bu gibi durumlarda buluta özgü PaaS tasarımları kullanımı kolay olabilir.As with the hybrid scenario, the use of Azure Virtual Machines or Azure Container Service might be easier in these cases than the use of cloud-specific PaaS designs.

OtomasyonAutomation

Az önce Bahsettiğimiz desenleri bazıları hızlı etkinleştirme çevrimdışı dağıtımlarının yanı sıra belirli bölümlerini bir sistem geri yükleme gerektirir.Some of the patterns that we just discussed require quick activation of offline deployments as well as restoration of specific parts of a system. Otomasyon betikleri bağlı kaynakları etkinleştirebilir ve çözümleri hızlı bir şekilde dağıtın.Automation scripts can activate resources on demand and deploy solutions rapidly. Otomasyon DR ile ilgili örnekler aşağıdaki Azure PowerShell, ancak kullanarak Azure CLI veya Hizmet Yönetimi REST API'si de iyi seçeneklerdir.The DR-related automation examples below use Azure PowerShell, but using the Azure CLI or the Service Management REST API are also good options.

Otomasyon betikleri değil şeffaf bir şekilde Azure tarafından işlenen DR özelliklerini yönetebilir.Automation scripts manage aspects of DR not transparently handled by Azure. Bu, İnsan hatası en aza indirir, tutarlı ve tekrarlanabilir sonuçlar üretir.This produces consistent and repeatable results, minimizing human error. Önceden tanımlanmış DR betikleri, ayrıca bir olağanüstü durum sırasında bir sistem ve onun bağlı parçalarını yeniden süresini azaltır.Predefined DR scripts also reduce the time to rebuild a system and its constituent parts during a disaster. El ile nasıl dakikada aşağı ve kaybeden paradan tasarruf ederken sitenize geri şekil denemek istemiyorum.You don’t want to try to manually figure out how to restore your site while it's down and losing money every minute.

Betiklerinizin başlangıçtan bitişe kadar sürekli olarak test edin.Test your scripts repeatedly from start to finish. Temel işlevleri doğruladıktan sonra test edin emin olun olağanüstü durum benzetimi.After verifying their basic functionality, make sure to test them in disaster simulation. Bu işlemler ve betikler kusurlarını motorudur.This helps uncover defects in the scripts or processes.

Otomasyon ile en iyi yöntem, PowerShell betikleri veya komut satırı arabirimi (CLI) betikleri Azure'a olağanüstü durum kurtarma için bir depo oluşturmaktır.A best practice with automation is to create a repository of PowerShell scripts or command-line interface (CLI) scripts for Azure disaster recovery. Açıkça işaretleyin ve hızlı erişim için kategorilere ayırın.Clearly mark and categorize them for quick access. Deposu ve betikler sürüm oluşturma işlemlerini yönetmek için birincil bir kişi belirleyin.Designate a primary person to manage the repository and versioning of the scripts. Belge açıklamaları parametreleri ve örnekleri betik kullanımı ile bunların yanı sıra.Document them well with explanations of parameters and examples of script use. Ayrıca, bu belge ile Azure dağıtımlarınızı eşitleyin emin olun.Also ensure that you keep this documentation in sync with your Azure deployments. Bu, birincil bir kişi deponun tüm bölümleri sorumlu olan amacı alt çizgi.This underscores the purpose of having a primary person in charge of all parts of the repository.

Hata algılamaFailure detection

Kullanılabilirlik ve olağanüstü durum kurtarma ile ilgili sorunlar doğru bir şekilde işlemek için belirleme ve tanılama hataları mümkün olması gerekir.To correctly handle problems with availability and disaster recovery, you must be able to detect and diagnose failures. Gelişmiş sunucu ve hızlı bir sistem veya bileşenleri aniden kullanılamaz duruma geldiğinde tanımak için izleme dağıtım gerçekleştirin.Perform advanced server and deployment monitoring to quickly recognize when a system or its components suddenly become unavailable. Bulut hizmeti ve bağımlılıklarını genel durumunu değerlendirmek araçları izleme, bu iş parçası gerçekleştirebilirsiniz.Monitoring tools that assess the overall health of the cloud service and its dependencies can perform part of this work. Uygun bir Microsoft aracı System Center 2016.One suitable Microsoft tool is System Center 2016. Üçüncü taraf araçları izleme özellikleri de sağlar.Third-party tools can also provide monitoring capabilities. Çoğu izleme çözümleri temel performans sayaçları ve hizmet kullanılabilirliğini izleyin.Most monitoring solutions track key performance counters and service availability.

Bu araçlar önemli olsa da, hata algılama ve bir bulut hizmetinde raporlama için planlamanız gerekir.Although these tools are vital, you must plan for fault detection and reporting within a cloud service. Azure tanılama düzgün bir şekilde kullanmayı planlamanız gerekir.You must also plan to properly use Azure Diagnostics. Özel performans Sayaçlarınızı veya olay günlüğü girişleri, genel stratejisinin bir parçası da olabilir.Custom performance counters or event-log entries can also be part of the overall strategy. Bu, hataları hızlı bir şekilde sorunu tanılamak ve tüm özelliklerini geri yükleme sırasında daha fazla veri sağlar.This provides more data during failures to quickly diagnose the problem and restore full capabilities. İzleme Araçları, uygulama durumunu belirlemek için kullanabileceğiniz ek ölçümleri de sağlar.It also provides additional metrics that the monitoring tools can use to determine application health. Daha fazla bilgi için Azure bulut hizmetlerinde Azure tanılamayı etkinleştirme.For more information, see Enabling Azure Diagnostics in Azure Cloud Services. Bir genel "sistem durumu modeli" planlama hakkında bilgi için bkz. hatasız: Yönergeler için dayanıklı bulut mimarileri.For a discussion of how to plan for an overall “health model,” see Failsafe: Guidance for Resilient Cloud Architectures.

Olağanüstü durum benzetimiDisaster simulation

Benzetimi test, takım üyelerinin nasıl tepki gözlemlemek için iş katında küçük gerçek zamanlı konuşmaların durumlarda oluşturmayı içerir.Simulation testing involves creating small real-life situations on the work floor to observe how the team members react. Benzetimleri, ayrıca nasıl etkili çözümler kurtarma planında da gösteriyoruz.Simulations also show how effective the solutions are in the recovery plan. Böylece yine de gerçek durumlar gibi HİSSEDİYORSUNUZ sırasında oluşturulan senaryoları gerçek iş kesintiye yok benzetimleri çalıştırın.Execute simulations so that the created scenarios don't disrupt actual business, while still feeling like real situations.

Mimari oluşturma "geçiş"Panosu el ile kullanılabilirlik sorunları benzetimini yapmak için uygulama türünü göz önünde bulundurun.Consider architecting a type of “switchboard” in the application to manually simulate availability issues. Örneğin, bir yazılım anahtarından veritabanı erişimi özel durumlarını sıralama bir modül için çalışmasına neden olarak tetikleyin.For instance, through a soft switch, trigger database access exceptions for an ordering module by causing it to malfunction. Ağ arabirimi düzeyinde diğer modüller için benzer basit yaklaşımlardan alabilir.You can take similar lightweight approaches for other modules at the network interface level.

Benzetim yeterince sağlanmayan ele alınan sorunları vurgular.The simulation highlights any issues that were inadequately addressed. Benzetimli senaryoları tamamen denetlenebilir olmalıdır.The simulated scenarios must be completely controllable. Bu kurtarma planı başarısız olmuş gibi görünüyor olsa bile, durum normal geri önemli bozuklukları neden olmadan geri yükleyebilirsiniz, anlamına gelir.This means that, even if the recovery plan seems to be failing, you can restore the situation back to normal without causing any significant damage. Ne zaman ve nasıl benzetimi alıştırmalar çalıştırılan hakkında üst düzey yönetim bildirmek önemlidir.It’s also important that you inform higher-level management about when and how the simulation exercises will be executed. Bu plan, benzetimi sırasında etkilenen kaynaklar ve zaman ayrıntı.This plan should detail the time or resources affected during the simulation. Ayrıca başarı ölçümleri, olağanüstü durum kurtarma planınızı test ederken tanımlayın.Also define the measures of success when testing your disaster recovery plan.

Azure Site Recovery kullanıyorsanız, azure'a çoğaltma stratejinizi doğrulamak veya herhangi bir veri kaybı veya kesinti süresi olmadan bir olağanüstü durum kurtarma tatbikatı gerçekleştirme için bir yük devretme testi çalıştırabilirsiniz.If you are using Azure Site Recovery, you can execute a test failover to Azure, to validate your replication strategy or perform a disaster recovery drill without any data loss or downtime. Yük devretme testi devam eden VM çoğaltması veya üretim ortamınızı etkilemez.A test failover does not affect on the ongoing VM replication or your production environment.

Diğer birçok tekniği, olağanüstü durum kurtarma planlarını test edebilirsiniz.Several other techniques can test disaster recovery plans. Ancak, çoğu, temel bu teknikler yalnızca bir çeşidi değildir.However, most of them are simply variations of these basic techniques. Bunun amacı test olduğu kurtarma planını uygulanabilirliğini değerlendirilecek.The intent of this testing is to evaluate the feasibility of the recovery plan. Olağanüstü durum kurtarma testi boşlukları temel kurtarma planında bulmak için ayrıntıları ele alınmaktadır.Disaster recovery testing focuses on the details to discover gaps in the basic recovery plan.

Hizmeti özel KılavuzuService-specific guidance

Aşağıdaki konularda, olağanüstü durum kurtarma belirli Azure hizmetlerinin açıklanmaktadır:The following topics describe disaster recovery specific Azure services:

HizmetService KonuTopic
MySQL için Azure VeritabanıAzure Database for MySQL MySQL için Azure veritabanı'nda iş sürekliliğine genel bakışOverview of business continuity with Azure Database for MySQL
PostgreSQL için Azure VeritabanıAzure Database for PostgreSQL PostgreSQL için Azure veritabanı'nda iş sürekliliğine genel bakışOverview of business continuity with Azure Database for PostgreSQL
Cloud ServicesCloud Services Azure hizmetinde Azure Cloud Services’ı etkileyen kesintiler olduğunda yapılması gerekenlerWhat to do in the event of an Azure service disruption that impacts Azure Cloud Services
Cosmos DBCosmos DB Azure Cosmos DB'de iş sürekliliği için otomatik bölgesel yük devretmeAutomatic regional failover for business continuity in Azure Cosmos DB
Key VaultKey Vault Azure Key Vault kullanılabilirlik ve yedeklilikAzure Key Vault availability and redundancy
DepolamaStorage Bir Azure depolama kesinti oluşursa yapmanız gerekenlerWhat to do if an Azure Storage outage occurs
SQL VeritabanıSQL Database Geri yükleme için ikincil bir Azure SQL veritabanı veya yük devretmeRestore an Azure SQL Database or failover to a secondary
Sanal makinelerVirtual machines Bir Azure hizmet kesintisi Azure sanal makineleri etkiler. olay, yapmanız gerekenlerWhat to do in the event that an Azure service disruption impacts Azure virtual machines
Sanal ağlarVirtual networks Sanal ağ – iş sürekliliğiVirtual Network – Business Continuity