Belirli Azure Hizmetleri için dayanıklılık denetim listesiResiliency checklist for specific Azure services

Dayanıklılık bir sistemin hatalardan kurtularak çalışmaya devam özelliğidir ve biri yazılım kalitesinin yapı taşları.Resiliency is the ability of a system to recover from failures and continue to function, and is one of the pillars of software quality. Her teknoloji tasarlarken ve uygulamanızı hayata dikkate almanız gereken kendi belirli hata modlarını sahiptir.Every technology has its own particular failure modes, which you must consider when designing and implementing your application. Belirli Azure Hizmetleri için dayanıklılık konuları gözden geçirmek için bu denetim listesini kullanın.Use this checklist to review the resiliency considerations for specific Azure services. Ayrıca gözden genel dayanıklılık denetim listesi.Also review the general resiliency checklist.

App ServiceApp Service

Standart veya Premium katmanı kullanın.Use Standard or Premium tier. Bu katmanlar, hazırlama yuvaları destekler ve otomatik yedeklemeler.These tiers support staging slots and automated backups. Daha fazla bilgi için Azure App Service planlarına ayrıntılı genel bakışFor more information, see Azure App Service plans in-depth overview

Ölçeği artırılabilen veya azaltılabilen kaçının.Avoid scaling up or down. Bunun yerine, bir katman ve normal yük altında performans gereksinimlerinizi karşılayacak örnek boyutu seçin ve ardından ölçeğini trafik hacmindeki değişikliklere işlemek üzere örnek.Instead, select a tier and instance size that meet your performance requirements under typical load, and then scale out the instances to handle changes in traffic volume. Yukarı ve aşağı ölçeklendirme uygulamanın yeniden başlatılmasını tetikleyebilir.Scaling up and down may trigger an application restart.

Uygulama ayarları olarak Store yapılandırması.Store configuration as app settings. Uygulama ayarları, yapılandırma ayarlarını uygulama ayarları olarak tutmak için kullanın.Use app settings to hold configuration settings as app settings. Ayarları kaynak yöneticisi şablonlarınızda veya otomatikleştirilmiş bir dağıtımının parçası olarak uygulamadan / güncelleştirme işlemi, daha güvenilir oldu, PowerShell kullanarak tanımlayın.Define the settings in your Resource Manager templates, or using PowerShell, so that you can apply them as part of an automated deployment / update process, which is more reliable. Daha fazla bilgi için Azure App Service'te web uygulamalarını yapılandırma.For more information, see Configure web apps in Azure App Service.

Üretim ve test için ayrı App Service planları oluşturun.Create separate App Service plans for production and test. Yuvalar, üretim dağıtımınızı test için kullanmayın.Don't use slots on your production deployment for testing. Aynı App Service planı içinde tüm uygulamalar aynı VM örneklerini paylaşın.All apps within the same App Service plan share the same VM instances. Üretim ve test dağıtımları aynı plana yerleştirirseniz, Üretim dağıtımı olumsuz yönde etkileyebilir.If you put production and test deployments in the same plan, it can negatively affect the production deployment. Örneğin, yük testleri Canlı üretim sitesini düşebilir.For example, load tests might degrade the live production site. Test dağıtımları ayrı planı koyarak, bunları üretim sürümünden yalıtın.By putting test deployments into a separate plan, you isolate them from the production version.

Web API'leri ayrı web uygulamaları.Separate web apps from web APIs. Çözümünüzün, hem bir web ön ucu hem de web API'si varsa, bunları ayrı App Service uygulamaları parçalama göz önünde bulundurun.If your solution has both a web front-end and a web API, consider decomposing them into separate App Service apps. Bu tasarım, çözüm iş yüküne göre parçalara ayırın kolaylaştırır.This design makes it easier to decompose the solution by workload. Web uygulaması ve API bağımsız olarak ölçeklendirilebilir için ayrı App Service planlarında çalıştırabilirsiniz.You can run the web app and the API in separate App Service plans, so they can be scaled independently. Ölçeklenebilirlik düzeyine ihtiyacınız yoksa ilk olarak, uygulamaları aynı plana dağıtabilir ve gerekirse ayrı planlara daha sonra hareket.If you don't need that level of scalability at first, you can deploy the apps into the same plan, and move them into separate plans later, if needed.

Azure SQL veritabanlarını yedeklemek için App Service yedekleme özelliğini kullanmaktan kaçının.Avoid using the App Service backup feature to back up Azure SQL databases. Bunun yerine, SQL veritabanı otomatik yedeklerinde.Instead, use SQL Database automated backups. App Service yedekleme veritabanı dtu'ları maliyetleri bir SQL .bacpac dosyası için dışarı aktarır.App Service backup exports the database to a SQL .bacpac file, which costs DTUs.

Hazırlama yuvasına dağıtın.Deploy to a staging slot. Hazırlama için bir dağıtım yuvası oluşturur.Create a deployment slot for staging. Uygulama güncelleştirmeleri hazırlama yuvasına dağıtma ve üretime geçirmeden önce dağıtımın doğrulayın.Deploy application updates to the staging slot, and verify the deployment before swapping it into production. Bu, hatalı bir güncelleştirme üretimde olasılığını azaltır.This reduces the chance of a bad update in production. Ayrıca, tüm örnekleri üretime takas önce warmed olduğunu sağlar.It also ensures that all instances are warmed up before being swapped into production. Birçok uygulama, bir önemli Isınma ve soğuk başlangıç saati ' var.Many applications have a significant warmup and cold-start time. Daha fazla bilgi için hazırlık Azure App service'taki web apps için ortamları ayarlama.For more information, see Set up staging environments for web apps in Azure App Service.

(LKG) son bilinen iyi dağıtımı tutmak için bir dağıtım yuvası oluşturur.Create a deployment slot to hold the last-known-good (LKG) deployment. Üretim için bir güncelleştirme dağıttığınızda, önceki üretim dağıtımını LKG yuvaya taşıyın.When you deploy an update to production, move the previous production deployment into the LKG slot. Bu, hatalı bir dağıtım geri almak kolaylaştırır.This makes it easier to roll back a bad deployment. Daha sonra bir sorun bulursanız, hızlı bir şekilde LKG sürüme geri dönebilirsiniz.If you discover a problem later, you can quickly revert to the LKG version. Daha fazla bilgi için temel web uygulaması.For more information, see Basic web application.

Tanılama günlüğünü etkinleştirmeuygulama günlüğüne kaydetme ve web sunucusu günlüğü dahil olmak üzere.Enable diagnostics logging, including application logging and web server logging. Günlüğe kaydetme, izleme ve tanılama için önemlidir.Logging is important for monitoring and diagnostics. Bkz: Azure App Service'te web apps için tanılama günlüğünü etkinleştirmeSee Enable diagnostics logging for web apps in Azure App Service

BLOB depolamaya günlük.Log to blob storage. Bu, verileri toplayıp analiz kolaylaştırır.This makes it easier to collect and analyze the data.

Günlükler için ayrı bir depolama hesabı oluşturun.Create a separate storage account for logs. Aynı depolama hesabındaki günlükler ve uygulama verileri için kullanmayın.Don't use the same storage account for logs and application data. Bu, uygulama performansı azaltarak gelen günlük önlemeye yardımcı olur.This helps to prevent logging from reducing application performance.

Performansını izleme.Monitor performance. İzleme hizmeti gibi bir performans New Relic veya Application Insights uygulama performansını izleme ve yük altında davranışı.Use a performance monitoring service such as New Relic or Application Insights to monitor application performance and behavior under load. Performans izleme, uygulamanın gerçek zamanlı Öngörüler sağlar.Performance monitoring gives you real-time insight into the application. Sorunları tanılayın ve hataların kök neden analizi gerçekleştirmek sağlar.It enables you to diagnose issues and perform root-cause analysis of failures.

Application GatewayApplication Gateway

En az iki örnek sağlayın.Provision at least two instances. Application Gateway ile en az iki örnek dağıtın.Deploy Application Gateway with at least two instances. Tek bir örneği tek bir hata noktasıdır.A single instance is a single point of failure. Yedeklilik ve ölçeklenebilirlik için iki veya daha fazla örneğini kullanın.Use two or more instances for redundancy and scalability. İçin kullanabilmek SLA, iki veya daha fazla Orta büyüklükte ya da daha büyük örnek hazırlamanız gerekir.In order to qualify for the SLA, you must provision two or more medium or larger instances.

Cosmos DBCosmos DB

Veritabanı bölgede çoğaltın.Replicate the database across regions. Cosmos DB, dilediğiniz sayıda Azure bölgesinde bir Cosmos DB veritabanı hesabıyla ilişkilendirmek sağlar.Cosmos DB allows you to associate any number of Azure regions with a Cosmos DB database account. Bir Cosmos DB veritabanı, bir yazma bölgesi ve birden çok okuma bölgesi sahip olabilir.A Cosmos DB database can have one write region and multiple read regions. Yazma bölgesinde bir hata varsa, başka bir kopya okuyabilirsiniz.If there is a failure in the write region, you can read from another replica. İstemci SDK'sı bunu otomatik olarak yönetir.The Client SDK handles this automatically. Başka bir bölgeyi yazma bölgesi devredebilir.You can also fail over the write region to another region. Daha fazla bilgi için küresel olarak Azure Cosmos DB ile verileri nasıl dağıtılacağını.For more information, see How to distribute data globally with Azure Cosmos DB.

Event HubsEvent Hubs

Kontrol noktalarını kullanma.Use checkpoints. Olay tüketicisi, kalıcı depolama için bazı önceden tanımlı aralıklarla geçerli konumunu yazmalısınız.An event consumer should write its current position to persistent storage at some predefined interval. Tüketici (örneğin, tüketici kilitlenme veya konak başarısız) bir hata oluşursa, bu şekilde, daha sonra yeni bir örneğini son kaydedilen konumundan akışı okuma devam edebilir.That way, if the consumer experiences a fault (for example, the consumer crashes, or the host fails), then a new instance can resume reading the stream from the last recorded position. Daha fazla bilgi için olay tüketicileri.For more information, see Event consumers.

Yinelenen iletileri işler.Handle duplicate messages. Olay tüketicisi başarısız olursa, ileti işleme kaydedilen son denetim noktasından sürdürülür.If an event consumer fails, message processing is resumed from the last recorded checkpoint. Son denetim noktasından sonra zaten işlenmiş olan herhangi bir iletiyi yeniden işlenebilir.Any messages that were already processed after the last checkpoint will be processed again. Bu nedenle, ileti işleme mantığı bir kez etkili olmalıdır veya uygulama ileti yinelemelerini erişebilmelidir.Therefore, your message processing logic must be idempotent, or the application must be able to deduplicate messages.

Özel durumları işler. .Handle exceptions.. Olay tüketicisi, genellikle toplu olarak mesaj döngü içinde işler.An event consumer typically processes a batch of messages in a loop. Bir özel durum tek bir ileti neden olursa toplu işin tamamını iletilerinin kaybetmemek için bu işleme döngü içinde özel durum işlemesi gerekir.You should handle exceptions within this processing loop to avoid losing an entire batch of messages if a single message causes an exception.

Geçerliliğini yitirmiş kuyruk kullanın.Use a dead-letter queue. Bir iletiyi işlemeyi geçici olmayan bir hata sonucu durumunu izleyebilmeniz için ileti bir eski ileti sırası yerleştirin.If processing a message results in a non-transient failure, put the message onto a dead-letter queue, so that you can track the status. Senaryoya bağlı olarak, iletiyi daha sonra yeniden deneyin, telafi edici bir işlem uygulayın veya diğer bazı işlemler yapması.Depending on the scenario, you might retry the message later, apply a compensating transaction, or take some other action. Event Hubs herhangi bir yerleşik eski ileti sırası işlevi sahip olmadığını unutmayın.Note that Event Hubs does not have any built-in dead-letter queue functionality. Eski ileti sırası uygulamak için Azure kuyruk depolama veya Service Bus'ı kullanın veya Azure işlevleri veya başka bir olay mekanizmasını kullanın.You can use Azure Queue Storage or Service Bus to implement a dead-letter queue, or use Azure Functions or some other eventing mechanism.

Olağanüstü durum kurtarma yük devretme ikincil bir Event Hubs ad alanı tarafından uygulayın.Implement disaster recovery by failing over to a secondary Event Hubs namespace. Daha fazla bilgi için Azure Event Hubs coğrafi olağanüstü durum kurtarma.For more information, see Azure Event Hubs Geo-disaster recovery.

Redis CacheRedis Cache

Coğrafi çoğaltmayı yapılandırma.Configure Geo-replication. Coğrafi çoğaltma, iki Premium katmanı, Azure Redis Cache örnekleri bağlama için bir mekanizma sağlar.Geo-replication provides a mechanism for linking two Premium tier Azure Redis Cache instances. Birincil önbelleğe yazılan veri ikincil salt okunur önbellek için çoğaltılır.Data written to the primary cache is replicated to a secondary read-only cache. Daha fazla bilgi için Azure Redis Cache için coğrafi çoğaltmayı yapılandırmaFor more information, see How to configure Geo-replication for Azure Redis Cache

Veri kalıcılığı yapılandırın.Configure data persistence. Redis kalıcılığı, Redis içinde depolanan verileri kalıcı hale getirmenize olanak tanır.Redis persistence allows you to persist data stored in Redis. Ayrıca, anlık ve bir donanım hata durumunda yükleyebilirsiniz verileri yedekleyin.You can also take snapshots and back up the data, which you can load in case of a hardware failure. Daha fazla bilgi için Premium Azure Redis Cache için veri kalıcılığı yapılandırmaFor more information, see How to configure data persistence for a Premium Azure Redis Cache

Kalıcı depoya değil de, geçici veri önbelleği olarak Redis Cache kullanıyorsanız, bu önerileri geçerli olmayabilir.If you are using Redis Cache as a temporary data cache and not as a persistent store, these recommendations may not apply.

Birden fazla çoğaltma sağlayın.Provision more than one replica. Yüksek kullanılabilirlik okuma veya okuma-yazma yüksek kullanılabilirlik için üç için en az iki çoğaltmaları kullanın.Use at least two replicas for read high-availability, or three for read-write high-availability.

Dizin oluşturucular çok bölgeli dağıtımlar için yapılandırın.Configure indexers for multi-region deployments. Çok bölgeli dağıtımlar, dizin oluşturma, süreklilik seçenekleri göz önünde bulundurun.If you have a multi-region deployment, consider your options for continuity in indexing.

  • Coğrafi olarak çoğaltılmış veri kaynağı ise genellikle her dizin oluşturucu her bölgesel Azure Search hizmeti için yerel veri kaynağı çoğaltması işaret etmelidir.If the data source is geo-replicated, you should generally point each indexer of each regional Azure Search service to its local data source replica. Ancak, Azure SQL veritabanı'nda depolanan büyük veri kümeleri için bu yaklaşım önerilmez.However, that approach is not recommended for large datasets stored in Azure SQL Database. Azure arama yalnızca birincil çoğaltmalara gelen ikincil SQL veritabanı çoğaltmaların Artımlı dizin oluşturma işlemini gerçekleştiremiyor nedenidir.The reason is that Azure Search cannot perform incremental indexing from secondary SQL Database replicas, only from primary replicas. Bunun yerine, tüm dizin oluşturucuların birincil çoğaltmaya işaret edecek.Instead, point all indexers to the primary replica. Yük devretme sonrasında Azure Search dizin oluşturucularında yeni birincil çoğaltmaya işaret edin.After a failover, point the Azure Search indexers at the new primary replica.

  • Coğrafi olarak çoğaltılmış veri kaynağını değil, aynı veri kaynağında birden çok dizin oluşturucu, böylece birden fazla bölgede Azure Search hizmetlerini sürekli olarak ve bağımsız bir şekilde veri kaynağından dizin noktası.If the data source is not geo-replicated, point multiple indexers at the same data source, so that Azure Search services in multiple regions continuously and independently index from the data source. Daha fazla bilgi için Azure Search, performans ve iyileştirme konuları.For more information, see Azure Search performance and optimization considerations.

Service BusService Bus

Üretim iş yükleri için Premium katmanı kullanımı.Use Premium tier for production workloads. Service Bus Premium Mesajlaşma ayrılmış ve ayrılmış işlem kaynakları ve tahmin edilebilir performans ve aktarım hızı desteklemek için bellek kapasitesi sağlar.Service Bus Premium Messaging provides dedicated and reserved processing resources, and memory capacity to support predictable performance and throughput. Premium Mesajlaşma katmanı yalnızca premium müşterilerine ilk kullanılabilir yeni özelliklere erişim sunar.Premium Messaging tier also gives you access to new features that are available only to premium customers at first. Beklenen iş yükleri üzerinde temel Mesajlaşma birimi sayısını karar verebilirsiniz.You can decide the number of messaging units based on expected workloads.

Yinelenen iletileri işleyen.Handle duplicate messages. Bir yayımcı hemen bir ileti gönderdikten sonra başarısız oluyor ya da ağ veya sistem sorunları karşılaştığında, ileti teslim edildi ve aynı ileti iki kez sisteme gönderebilir kaydetmek deneyebileceğinizi yüklenemeyebilir.If a publisher fails immediately after sending a message, or experiences network or system issues, it may erroneously fail to record that the message was delivered, and may send the same message to the system twice. Service Bus, yinelenen algılama sağlayarak bu sorunu başa çıkabilir.Service Bus can handle this issue by enabling duplicate detection. Daha fazla bilgi için yinelenen algılama.For more information, see Duplicate detection.

Özel durumları işlemek.Handle exceptions. Mesajlaşma API'lerini özel durumlar oluşturmaya kullanıcı hatası, yapılandırma hatası veya başka bir hata oluşur.Messaging APIs generate exceptions when a user error, configuration error, or other error occurs. İstemci kodu (göndericiler ve alıcılar) kodlarında bu özel durumları işlemeniz gerekir.The client code (senders and receivers) should handle these exceptions in their code. Bu özellikle toplu işlem, toplu işin tamamını iletilerinin kaybetmemek için özel durum işleme nerede kullanılabilir işlenirken önemlidir.This is especially important in batch processing, where exception handling can be used to avoid losing an entire batch of messages. Daha fazla bilgi için Service Bus Mesajlaşma özel durumları.For more information, see Service Bus messaging exceptions.

Yeniden deneme ilkesi.Retry policy. Service Bus, uygulamalarınız için en iyi yeniden deneme ilkesi seçmenize olanak sağlar.Service Bus allows you to pick the best retry policy for your applications. 9 en fazla yeniden deneme sayısı ve 30 saniye bekleyin, ancak bu daha da ayarlanabilir izin vermek için varsayılan ilkedir.The default policy is to allow 9 maximum retry attempts, and wait for 30 seconds but this can be further adjusted. Daha fazla bilgi için yeniden deneme ilkesi – Service Bus.For more information, see Retry policy – Service Bus.

Eski ileti sırası kullanın.Use a dead-letter queue. Bir ileti işleme veya birden çok denemeden sonra herhangi bir alıcıya teslim edilemeyen kuyruğa taşınmıştır.If a message cannot be processed or delivered to any receiver after multiple retries, it is moved to a dead letter queue. Atılacak Mektubu kuyruktan iletileri okumak, bunları inceleyin ve sorunu çözmek için bir işlem uygulayın.Implement a process to read messages from the dead letter queue, inspect them, and remediate the problem. Senaryoya bağlı olarak, ileti olarak yeniden deneme-olduğundan, değişiklikleri yapın ve yeniden deneyin veya iletiyi göz ardı.Depending on the scenario, you might retry the message as-is, make changes and retry, or discard the message. Daha fazla bilgi için Service Bus genel bakış edilemeyen.For more information, see Overview of Service Bus dead-letter queues.

Coğrafi olağanüstü durum kurtarma'yı kullanmak.Use Geo-Disaster Recovery. Coğrafi olağanüstü durum kurtarma, veri işleme farklı bir bölge veya veri merkezi içinde bir Azure bölgesinin tamamını ya da veri merkezi bir olağanüstü durum nedeniyle kullanılamaz hale gelirse çalışmaya devam etmesini sağlar.Geo-disaster recovery ensures that data processing continues to operate in a different region or datacenter if an entire Azure region or datacenter becomes unavailable due to a disaster. Daha fazla bilgi için Azure Service Bus Geo-olağanüstü durum kurtarma.For more information, see Azure Service Bus Geo-disaster recovery.

DepolamaStorage

Uygulama verileri için okuma erişimli coğrafi olarak yedekli depolama (RA-GRS) kullanın.For application data, use read-access geo-redundant storage (RA-GRS). RA-GRS depolama verilerin ikincil bölgeye çoğaltır ve ikincil bölgeden salt okunur erişim sağlar.RA-GRS storage replicates the data to a secondary region, and provides read-only access from the secondary region. Birincil bölgede bir depolama kesintisi varsa, uygulamanın ikincil bölgeden verileri okuyabilir.If there is a storage outage in the primary region, the application can read the data from the secondary region. Daha fazla bilgi için Azure depolama çoğaltma.For more information, see Azure Storage replication.

VM diskleri için yönetilen diskleri kullanın.For VM disks, use Managed Disks. [Yönetilen diskler] managed-disks diskler ayrı tek hata noktalarından kaçınmak üzere birbirinden olduğundan daha fazla güvenilirlik bir kullanılabilirlik kümesindeki VM'ler için sağlayın.Managed Disks provide better reliability for VMs in an availability set, because the disks are sufficiently isolated from each other to avoid single points of failure. Ayrıca, yönetilen diskleri bir depolama hesabında oluşturulan VHD IOPS limitlerine tabi değildir.Also, Managed Disks aren't subject to the IOPS limits of VHDs created in a storage account. Daha fazla bilgi için azure'daki Windows sanal makinelerin kullanılabilirliğini yönetme.For more information, see Manage the availability of Windows virtual machines in Azure.

Kuyruk depolama için başka bir bölgede bir yedek kuyruk oluşturun.For Queue storage, create a backup queue in another region. Kuyruk veya öğeleri sıradan çıkarma için kuyruk depolama, kullanım, salt okunur bir çoğaltması sınırlıdır.For Queue storage, a read-only replica has limited use, because you can't queue or dequeue items. Bunun yerine, başka bir bölgede bir depolama hesabında bir yedek kuyruk oluşturun.Instead, create a backup queue in a storage account in another region. Bir depolama kesintisi ise, uygulama birincil bölge tekrar kullanılabilir olana kadar yedek kuyruğu kullanabilirsiniz.If there is a storage outage, the application can use the backup queue, until the primary region becomes available again. Bu şekilde, uygulama yine de yeni istekleri işleyebilir.That way, the application can still process new requests.

SQL VeritabanıSQL Database

Standart veya Premium katmanı kullanın.Use Standard or Premium tier. Bu katmanlar, daha uzun zaman içinde nokta geri yükleme süresi (35 gün) sunar.These tiers provide a longer point-in-time restore period (35 days). Daha fazla bilgi için SQL veritabanı seçenekleri ve performansı.For more information, see SQL Database options and performance.

SQL veritabanı denetimini etkinleştirin.Enable SQL Database auditing. Denetim kötü amaçlı saldırıları ya da insan hatası tanılamak için kullanılabilir.Auditing can be used to diagnose malicious attacks or human error. Daha fazla bilgi için SQL veritabanı denetimini kullanmaya başlama.For more information, see Get started with SQL database auditing.

Etkin coğrafi çoğaltma kullanın kullanım etkin coğrafi farklı bir bölgede okunabilir ikincil oluşturmak için çoğaltma.Use Active Geo-Replication Use Active Geo-Replication to create a readable secondary in a different region. Birincil veritabanınız başarısız olursa veya yalnızca erişmesi çevrimdışı duruma, ikincil veritabanına el ile bir yük devretme gerçekleştirin.If your primary database fails, or simply needs to be taken offline, perform a manual failover to the secondary database. Siz yük devredene kadar ikincil veritabanı salt okunur olarak kalır.Until you fail over, the secondary database remains read-only. Daha fazla bilgi için SQL veritabanı etkin coğrafi çoğaltma.For more information, see SQL Database Active Geo-Replication.

Parçalama kullanın.Use sharding. Parçalama, veritabanını yatay olarak bölümlemek için kullanmayı düşünün.Consider using sharding to partition the database horizontally. Parçalama hata Yalıtımı sağlar.Sharding can provide fault isolation. Daha fazla bilgi için Azure SQL veritabanı ile ölçek genişletme.For more information, see Scaling out with Azure SQL Database.

Belirli bir noktaya geri yükleme, insan hatasından kurtarmak için kullanın.Use point-in-time restore to recover from human error. Belirli bir noktaya geri yükleme veritabanı önceki bir noktaya sürede döndürür.Point-in-time restore returns your database to an earlier point in time. Daha fazla bilgi için otomatik veritabanı yedeklerini kullanarak bir Azure SQL veritabanını kurtarma.For more information, see Recover an Azure SQL database using automated database backups.

Coğrafi geri yükleme, bir hizmet kesintisinden kurtarmak için kullanın.Use geo-restore to recover from a service outage. Coğrafi geri yükleme, coğrafi olarak yedekli bir yedekten bir veritabanını geri yükler.Geo-restore restores a database from a geo-redundant backup. Daha fazla bilgi için otomatik veritabanı yedeklerini kullanarak bir Azure SQL veritabanını kurtarma.For more information, see Recover an Azure SQL database using automated database backups.

SQL Veri AmbarıSQL Data Warehouse

Coğrafi yedekleme devre dışı bırakmayın.Do not disable geo-backup. Varsayılan olarak, SQL veri ambarı tam olağanüstü durum kurtarma için 24 saatte, verilerin yedeğini alır.By default, SQL Data Warehouse takes a full backup of your data every 24 hours for disaster recovery. Bu özellik devre dışı bırakmak için önerilmez.It is not recommended to turn this feature off. Daha fazla bilgi için coğrafi yedekleri.For more information, see Geo-backups.

Bir VM'de çalışan SQL ServerSQL Server running in a VM

Veritabanı çoğaltma.Replicate the database. Veritabanı çoğaltma için SQL Server Always On kullanılabilirlik grupları'nı kullanın.Use SQL Server Always On Availability Groups to replicate the database. Tek bir SQL Server örneği başarısız olursa yüksek kullanılabilirlik sağlar.Provides high availability if one SQL Server instance fails. Daha fazla bilgi için N katmanlı bir uygulama için Windows Vm'leri çalıştırmaFor more information, see Run Windows VMs for an N-tier application

Veritabanını yedekleme.Back up the database. Zaten kullanıyorsanız Azure Backup , Vm'leri yedekleme için kullanmayı düşünün DPM kullanan SQL Server iş yükleri için Azure Backup.If you are already using Azure Backup to back up your VMs, consider using Azure Backup for SQL Server workloads using DPM. Bu yaklaşımda, kuruluş için bir yedek Yönetici rolü ve Vm'leri ve SQL Server için bir birleşik kurtarma yordamı yok.With this approach, there is one backup administrator role for the organization and a unified recovery procedure for VMs and SQL Server. Aksi takdirde kullanın Microsoft azure'da SQL Server yönetilen yedekleme.Otherwise, use SQL Server Managed Backup to Microsoft Azure.

Traffic ManagerTraffic Manager

El ile yeniden çalışma gerçekleştirin.Perform manual failback. Otomatik olarak başarısız geri yerine bir Traffic Manager yük devretmeden sonra el ile yeniden çalışma gerçekleştirin.After a Traffic Manager failover, perform manual failback, rather than automatically failing back. Yeniden çalıştırmadan önce tüm uygulama alt sistemlerinin iyi durumda olduğunu doğrulayın.Before failing back, verify that all application subsystems are healthy. Aksi takdirde, burada uygulama veri merkezleri arasında ileri ve geri çevirir bir durum oluşturabilirsiniz.Otherwise, you can create a situation where the application flips back and forth between data centers. Daha fazla bilgi için Vm'leri yüksek kullanılabilirlik için birden fazla bölgede çalıştırma.For more information, see Run VMs in multiple regions for high availability.

Bir sistem durumu araştırma uç noktası oluşturun.Create a health probe endpoint. Uygulamanın genel durumunu raporlayan bir özel bir uç noktası oluşturun.Create a custom endpoint that reports on the overall health of the application. Bu, herhangi kritik yol başarısız olursa, yalnızca ön uç yük devretme için Traffic Manager sağlar.This enables Traffic Manager to fail over if any critical path fails, not just the front end. Uç nokta, herhangi bir kritik bağımlılığı sağlıksız veya ulaşılamaz durumdaysa bir HTTP hata kodu döndürmesi gerekir.The endpoint should return an HTTP error code if any critical dependency is unhealthy or unreachable. Kritik olmayan hizmetler için hataları, ancak rapor yok.Don't report errors for non-critical services, however. Aksi halde, hatalı pozitif sonuçları oluşturma değil gerektiğinde durum yoklaması yük devretme tetikleyebilir.Otherwise, the health probe might trigger failover when it's not needed, creating false positives. Daha fazla bilgi için Traffic Manager uç nokta izleme ve yük devretme.For more information, see Traffic Manager endpoint monitoring and failover.

Virtual MachinesVirtual Machines

Bir üretim iş yükünü tek bir VM üzerinde çalıştırmayın.Avoid running a production workload on a single VM. Tek bir VM dağıtımı için planlı veya Plansız bakım dayanıklı değildir.A single VM deployment is not resilient to planned or unplanned maintenance. Bunun yerine, bir kullanılabilirlik kümesindeki birden çok VM yerleştirin veya VM ölçek kümesi, önde gelen bir yük dengeleyici ile.Instead, put multiple VMs in an availability set or VM scale set, with a load balancer in front.

Bir kullanılabilirlik kümesini VM'yi sağlarken belirtin.Specify an availability set when you provision the VM. Şu anda, VM sağlandıktan sonra kullanılabilirlik kümesine için bir VM eklemek için hiçbir yolu yoktur.Currently, there is no way to add a VM to an availability set after the VM is provisioned. Eklediğinizde, yeni bir VM için mevcut bir kullanılabilirlik kümesi, VM için bir NIC oluşturup emin olun ve arka uç adres havuzuna yük dengeleyici üzerindeki NIC ekleyin.When you add a new VM to an existing availability set, make sure to create a NIC for the VM, and add the NIC to the back-end address pool on the load balancer. Aksi takdirde, yük dengeleyicinin ağ trafiğini yönlendirir ve bu da o sanal makineye olmaz.Otherwise, the load balancer won't route network traffic to that VM.

Her uygulama katmanı, bir ayrı kullanılabilirlik kümesine yerleştirin.Put each application tier into a separate Availability Set. N katmanlı bir uygulama içinde VM'lerin aynı kullanılabilirlik kümesine farklı katmanı arasından yerleştirmeyin.In an N-tier application, don't put VMs from different tiers into the same availability set. Bir kullanılabilirlik kümesindeki VM'lerin hata etki alanları (FD) arasında yer alır ve güncelleme etki alanları (UD).VMs in an availability set are placed across fault domains (FDs) and update domains (UD). Ancak, UD ve Fd'ler yedeklilik faydalanmak için kullanılabilirlik kümesindeki her VM aynı istemci isteklerini işleyebilmesi olması gerekir.However, to get the redundancy benefit of FDs and UDs, every VM in the availability set must be able to handle the same client requests.

Azure Site RECOVERY'yi kullanarak VM'lerin çoğaltın.Replicate VMs using Azure Site Recovery. Çoğaltma zaman kullanarak Azure Vm'lerine Site Recovery, tüm VM disklerini sürekli olarak hedef bölgede için zaman uyumsuz olarak çoğaltılır.When you replicate Azure VMs using Site Recovery, all the VM disks are continuously replicated to the target region asynchronously. Kurtarma noktaları, birkaç dakikada oluşturulur.The recovery points are created every few minutes. Bu, bir kurtarma noktası hedefi (RPO) dakika düzeyinde sağlar.This gives you a Recovery Point Objective (RPO) in the order of minutes. Üretim uygulaması veya sürmekte olan çoğaltmayı etkilemeden istediğiniz kadar olarak olağanüstü durum kurtarma tatbikatı gerçekleştirebilirsiniz.You can conduct disaster recovery drills as many times as you want, without impacting the production application or the ongoing replication. Daha fazla bilgi için Azure'a olağanüstü durum kurtarma tatbikatı çalıştırma.For more information, see Run a disaster recovery drill to Azure.

Performans gereksinimlerine göre doğru VM boyutunu seçin.Choose the right VM size based on performance requirements. Mevcut bir iş yükünü Azure'a taşırken, şirket içi sunucularınıza en yakın eşleşme VM boyutu ile başlayın.When moving an existing workload to Azure, start with the VM size that's the closest match to your on-premises servers. Ardından CPU, bellek ve disk IOPS göre gerçek İş yükünüzün performansını ölçmek ve gerekirse boyutunu ayarlayın.Then measure the performance of your actual workload with respect to CPU, memory, and disk IOPS, and adjust the size if needed. Bu uygulama bir bulut ortamında beklendiği gibi davrandığından emin olmak için yardımcı olur.This helps to ensure the application behaves as expected in a cloud environment. Ayrıca birden çok NIC gerekiyorsa, her boyut için NIC sınırı farkında olun.Also, if you need multiple NICs, be aware of the NIC limit for each size.

Yönetilen diskler için VHD kullanın.Use Managed Disks for VHDs. [Yönetilen diskler] managed-disks diskler ayrı tek hata noktalarından kaçınmak üzere birbirinden olduğundan daha fazla güvenilirlik bir kullanılabilirlik kümesindeki VM'ler için sağlayın.Managed Disks provide better reliability for VMs in an availability set, because the disks are sufficiently isolated from each other to avoid single points of failure. Ayrıca, yönetilen diskleri bir depolama hesabında oluşturulan VHD IOPS limitlerine tabi değildir.Also, Managed Disks aren't subject to the IOPS limits of VHDs created in a storage account. Daha fazla bilgi için azure'daki Windows sanal makinelerin kullanılabilirliğini yönetme.For more information, see Manage the availability of Windows virtual machines in Azure.

Uygulamalar, işletim sistemi diski bir veri diski yükleyin.Install applications on a data disk, not the OS disk. Aksi takdirde, disk boyut sınırına ulaşabilir.Otherwise, you may reach the disk size limit.

Vm'leri yedekleme için Azure Backup'ı kullanın.Use Azure Backup to back up VMs. Yedeklemeler, yanlışlıkla veri kaybına karşı koruyun.Backups protect against accidental data loss. Daha fazla bilgi için bir kurtarma Hizmetleri kasası ile Azure sanal makineleri koruma.For more information, see Protect Azure VMs with a recovery services vault.

Tanılama günlüklerini etkinleştirme, temel sistem durumu ölçümleri, altyapı günlükleri de dahil olmak üzere ve önyükleme tanılaması.Enable diagnostic logs, including basic health metrics, infrastructure logs, and boot diagnostics. Önyükleme Tanılaması, VM'nizi önyüklenebilir olmayan bir duruma girmesi durumunda önyükleme hatasını tanılamanıza yardımcı olabilir.Boot diagnostics can help you diagnose a boot failure if your VM gets into a non-bootable state. Daha fazla bilgi için genel bakış, Azure tanılama günlükleri.For more information, see Overview of Azure Diagnostic Logs.

AzureLogCollector uzantısını kullanın.Use the AzureLogCollector extension. (Yalnızca Windows Vm'leri.) Bu uzantı, Azure platformu günlükleri toplar ve bunları VM'ye uzaktan oturum işleci olmadan Azure Depolama'ya yükler.(Windows VMs only.) This extension aggregates Azure platform logs and uploads them to Azure storage, without the operator remotely logging into the VM. Daha fazla bilgi için AzureLogCollector uzantısı.For more information, see AzureLogCollector Extension.

Sanal AğVirtual Network

Beyaz liste veya blok için genel IP adresleri, alt ağa bir NSG ekleyin.To whitelist or block public IP addresses, add an NSG to the subnet. Kötü niyetli kullanıcıların erişimi engellemeye veya uygulamaya erişmek için ayrıcalığına sahip kullanıcılardan erişim izni.Block access from malicious users, or allow access only from users who have privilege to access the application.

Bir özel durum araştırması oluşturun.Create a custom health probe. Yük Dengeleyici sistem durumu Araştırmalarının HTTP'yi veya TCP'yi test edebilirsiniz.Load Balancer Health Probes can test either HTTP or TCP. Bir VM için bir HTTP sunucusu çalıştırıyorsa, HTTP araştırması bir daha iyi sistem durumu bir TCP araştırması daha göstergesidir.If a VM runs an HTTP server, the HTTP probe is a better indicator of health status than a TCP probe. Bir HTTP araştırması oluşturmak için tüm kritik bağımlılıklar dahil olmak üzere uygulamanın genel durumunu raporlayan özel bir uç noktasını kullanın.For an HTTP probe, use a custom endpoint that reports the overall health of the application, including all critical dependencies. Daha fazla bilgi için Azure Load Balancer'a genel bakış.For more information, see Azure Load Balancer overview.

Durum yoklaması engellemez.Don't block the health probe. Yük Dengeleyici durum araştırması bir bilinen IP adresinden, 168.63.129.16 gönderilir.The Load Balancer Health probe is sent from a known IP address, 168.63.129.16. Herhangi bir güvenlik duvarı ilkelerini veya ağ güvenlik grubu (NSG) kuralları bu IP veya trafiği engelleme.Don't block traffic to or from this IP in any firewall policies or network security group (NSG) rules. Durum yoklaması engelleme VM döndürme kaldırmak yük dengeleyici neden olur.Blocking the health probe would cause the load balancer to remove the VM from rotation.

Yük Dengeleyici günlüklerini etkinleştirin.Enable Load Balancer logging. Günlükler, arka uçta kaç tane Vm'niz Göster makinenin başarısız araştırma yanıtları nedeniyle ağ trafiği almıyor.The logs show how many VMs on the back-end are not receiving network traffic due to failed probe responses. Daha fazla bilgi için Azure Load Balancer için Log analytics.For more information, see Log analytics for Azure Load Balancer.