Контрольный список для обеспечения устойчивости конкретных служб AzureResiliency checklist for specific Azure services

Устойчивость — это способность системы восстанавливаться после сбоев и продолжать работать.Resiliency is the ability of a system to recover from failures and continue to function. Каждая технология имеет собственные режимы сбоев, которые необходимо учитывать при разработке и реализации приложения.Every technology has its own particular failure modes, which you must consider when designing and implementing your application. Используйте этот контрольный список для проверки факторов устойчивости конкретных служб Azure.Use this checklist to review the resiliency considerations for specific Azure services. Дополнительные сведения о проектировании устойчивых приложений см. в статье Разработка надежных приложений Azure.For more information about designing resilient applications, see Design reliable Azure applications.

Служба приложенийApp Service

Уровень "Стандартный" или "Премиум".Use Standard or Premium tier. Эти уровни поддерживают промежуточные слоты и автоматическое резервное копирование.These tiers support staging slots and automated backups. Дополнительные сведения см. в статье Подробный обзор планов службы приложений Azure.For more information, see Azure App Service plans in-depth overview

Избегайте увеличения или уменьшения масштаба.Avoid scaling up or down. Вместо этого выберите уровень и размер экземпляра в соответствии с требованиями к производительности при типичной нагрузке, а затем выполните горизонтальное масштабирование экземпляров для обработки изменений объема трафика.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. Увеличение или уменьшение масштаба может вызвать перезапуск приложения.Scaling up and down may trigger an application restart.

Сохраняйте конфигурацию в виде настроек приложений.Store configuration as app settings. Используйте настройки приложения, чтобы сохранить параметры конфигурации в качестве настроек приложения.Use app settings to hold configuration settings as app settings. Определите параметры в шаблонах Resource Manager или с помощью PowerShell, чтобы применить их в процессе автоматического развертывания или обновления. Этот подход надежнее.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. Дополнительные сведения см. в статье Настройка веб-приложений в службе приложений Azure.For more information, see Configure web apps in Azure App Service.

Используйте разные планы службы приложений для рабочей и тестовой сред.Create separate App Service plans for production and test. Не используйте слоты в рабочем развертывании для тестирования.Don't use slots on your production deployment for testing. Все приложения, которые находятся в одном плане службы приложений, совместно используют одни экземпляры виртуальных машин.All apps within the same App Service plan share the same VM instances. Если разместить рабочее и тестовое развертывание в одном плане, это может негативно повлиять на рабочее развертывание.If you put production and test deployments in the same plan, it can negatively affect the production deployment. Например, нагрузочные тесты могут привести к ухудшению производительности активного рабочего сайта.For example, load tests might degrade the live production site. Поместив тестовые развертывания в отдельный план, можно изолировать их от рабочей версии.By putting test deployments into a separate plan, you isolate them from the production version.

Отделите веб-приложения от веб-API.Separate web apps from web APIs. Если в решении есть веб-интерфейс и веб-API, рассмотрите возможность разбить их на отдельные приложения службы приложений.If your solution has both a web front end and a web API, consider decomposing them into separate App Service apps. Такой подход помогает распределять решения по рабочим нагрузкам.This design makes it easier to decompose the solution by workload. Вы можете запускать веб-приложение и API в отдельных планах службы приложений, чтобы они могли масштабироваться независимо друг от друга.You can run the web app and the API in separate App Service plans, so they can be scaled independently. Если изначально этот уровень масштабируемости не требуется, можно развертывать приложения в одном плане и позже переместить их в отдельные планы (при необходимости).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.Avoid using the App Service backup feature to back up Azure SQL databases. Вместо этого используйте автоматические резервные копии базы данных SQL.Instead, use SQL Database automated backups. Резервная копия службы приложений экспортирует базу данных в BACPAC-файл SQL, который стоимостью DTU.App Service backup exports the database to a SQL BACPAC file, which costs DTUs.

Выполняйте развертывания в промежуточном слоте.Deploy to a staging slot. Создайте слот развертывания для размещения в промежуточной среде.Create a deployment slot for staging. Разверните обновления приложений в промежуточном слоте и проверьте развертывание, прежде чем переносить его в рабочую среду.Deploy application updates to the staging slot, and verify the deployment before swapping it into production. Это снижает вероятность неправильного обновления в рабочей среде.This reduces the chance of a bad update in production. Это также гарантирует, что все экземпляры подготовлены перед перемещением в рабочую среду.It also ensures that all instances are warmed up before being swapped into production. Для многих приложений довольно долго выполняются начальная загрузка и "холодный" запуск.Many applications have a significant warmup and cold-start time. Дополнительные сведения см. в статье Настройка промежуточных сред в службе приложений Azure.For more information, see Set up staging environments for web apps in Azure App Service.

Создайте слот развертывания для хранения последнего известного корректного развертывания (LKG).Create a deployment slot to hold the last-known-good (LKG) deployment. При развертывании обновления в рабочей среде переместите предыдущее рабочее развертывание в слот LKG.When you deploy an update to production, move the previous production deployment into the LKG slot. Это упрощает откат неправильного развертывания.This makes it easier to roll back a bad deployment. Если в дальнейшем обнаруживается проблема, можно быстро вернуться к версии LKG.If you discover a problem later, you can quickly revert to the LKG version. Дополнительные сведения см. в статье Basic web application (Базовое веб-приложение).For more information, see Basic web application.

Включите ведение журнала диагностики, в частности для приложения и веб-сервера.Enable diagnostics logging, including application logging and web server logging. Ведение журнала важно для мониторинга и диагностики.Logging is important for monitoring and diagnostics. Ознакомьтесь со статьей Включение ведения журнала диагностики для веб-приложений в службе приложений Azure.See Enable diagnostics logging for web apps in Azure App Service

Храните данные журнала в хранилище BLOB-объектов.Log to blob storage. Это упрощает сбор и анализ данных.This makes it easier to collect and analyze the data.

Создайте отдельную учетную запись хранения для журналов.Create a separate storage account for logs. Не используйте одну учетную запись хранения для журналов и данных приложения.Don't use the same storage account for logs and application data. Это помогает предотвратить снижение производительности приложения из-за ведения журнала.This helps to prevent logging from reducing application performance.

Отслеживайте производительность.Monitor performance. Используйте службу мониторинга производительности, например New Relic или Application Insights, чтобы контролировать производительность и поведение загруженных приложений.Use a performance monitoring service such as New Relic or Application Insights to monitor application performance and behavior under load. Мониторинг производительности дает вам представление о приложении в режиме реального времени.Performance monitoring gives you real-time insight into the application. Он позволяет диагностировать проблемы и выполнять анализ основной причины сбоев.It enables you to diagnose issues and perform root-cause analysis of failures.

Шлюз приложенийApplication Gateway

Подготовьте по крайней мере два экземпляра.Provision at least two instances. Разверните шлюз приложений как минимум с двумя экземплярами.Deploy Application Gateway with at least two instances. Один экземпляр является единой точкой отказа.A single instance is a single point of failure. Используйте два или более экземпляров для обеспечения избыточности и масштабируемости.Use two or more instances for redundancy and scalability. В соответствии с соглашением об уровне обслуживания необходимо предоставить два или более экземпляров среднего или большего размера.In order to qualify for the SLA, you must provision two or more medium or larger instances.

База данных CosmosCosmos DB

Реплицируйте базу данных в разные регионы.Replicate the database across regions. Cosmos DB позволяет связать любое количество регионов Azure с учетной записью базы данных Cosmos DB.Cosmos DB allows you to associate any number of Azure regions with a Cosmos DB database account. База данных Cosmos DB может иметь один регион записи и несколько регионов чтения.A Cosmos DB database can have one write region and multiple read regions. В случае сбоя в регионе записи можно выполнять чтение из другой реплики.If there is a failure in the write region, you can read from another replica. Клиентский пакет SDK обрабатывает это автоматически.The Client SDK handles this automatically. Кроме того, можно выполнить отработку отказа региона записи в другой регион.You can also fail over the write region to another region. Дополнительные сведения см. в статье Как работает глобальное распределение данных в Azure с помощью Cosmos DB.For more information, see How to distribute data globally with Azure Cosmos DB.

Центры событийEvent Hubs

Использование контрольных точек.Use checkpoints. Потребитель события должен записывать свою текущую позицию в постоянное хранилище с предопределенным интервалом.An event consumer should write its current position to persistent storage at some predefined interval. Таким образом, если работа потребителя приостановлена (например, происходит сбой потребителя или сбой узла), то новый экземпляр может возобновить чтение потока с последней записанной позиции.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. См. дополнительные сведения о потребителях событий.For more information, see Event consumers.

Обработка повторяющихся сообщений.Handle duplicate messages. При сбое потребителя события обработка сообщений возобновляется с последней записанной контрольной точки.If an event consumer fails, message processing is resumed from the last recorded checkpoint. Все сообщения, обработанные после последней контрольной точки, будут обработаны повторно.Any messages that were already processed after the last checkpoint will be processed again. Поэтому логика обработки сообщений должна быть идемпотентной. Или приложение должно уметь дедуплицировать сообщения.Therefore, your message processing logic must be idempotent, or the application must be able to deduplicate messages.

Обработка исключений.Handle exceptions.. Потребитель события обычно обрабатывает пакет сообщений в цикле.An event consumer typically processes a batch of messages in a loop. Вы должны обработать исключения в этом цикле обработки, чтобы избежать потери всего пакета сообщений, если одно сообщение приводит к возникновению исключения.You should handle exceptions within this processing loop to avoid losing an entire batch of messages if a single message causes an exception.

Использование недоставленных сообщений.Use a dead-letter queue. Если обработка сообщения приводит к временному сбою, поместите сообщение в очередь недоставленных сообщений, чтобы отслеживать состояние.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. В зависимости от сценария можно повторно отправить сообщение позже, применить компенсирующую транзакцию или предпринять другое действие.Depending on the scenario, you might retry the message later, apply a compensating transaction, or take some other action. Обратите внимание, что в Центрах событий нет встроенной функции очереди недоставленных сообщений.Note that Event Hubs does not have any built-in dead-letter queue functionality. Вместо этого можно использовать хранилище очередей Azure, служебную шину, Функции Azure или другой механизм обработки событий.You can use Azure Queue Storage or Service Bus to implement a dead-letter queue, or use Azure Functions or some other eventing mechanism.

Реализация аварийного восстановления с помощью отработки отказа в дополнительное пространство имен Центров событий.Implement disaster recovery by failing over to a secondary Event Hubs namespace. Дополнительные сведения см. в статье Географическое аварийное восстановление в Центрах событий Azure.For more information, see Azure Event Hubs Geo-disaster recovery.

Кэш Azure для RedisAzure Cache for Redis

Настройка георепликации.Configure Geo-replication. Георепликация предоставляет механизм связывания двух кэшей Azure уровня "Премиум" для экземпляров Redis.Geo-replication provides a mechanism for linking two Premium-tier Azure Cache for Redis instances. Данные, записанные в основном кэше, реплицируются во вторичный кэш только для чтения.Data written to the primary cache is replicated to a secondary read-only cache. Дополнительные сведения см. в статье Настройка георепликации для кэша Azure для Redis .For more information, see How to configure geo-replication for Azure Cache for Redis

Настройка сохраняемости данных.Configure data persistence. Постоянное хранение Redis позволяет постоянно хранить данные, размещенные в Redis.Redis persistence allows you to persist data stored in Redis. Также можно создавать моментальные снимки и архивировать данные, которые можно будет восстановить в случае сбоя оборудования.You can also take snapshots and back up the data, which you can load in case of a hardware failure. Дополнительные сведения см. в статье Настройка сохраняемости данных для кэша Azure уровня "Премиум" для Redis .For more information, see How to configure data persistence for a Premium-tier Azure Cache for Redis

Если вы используете кэш Azure для Redis как временный кэш данных, а не как постоянное хранилище, эти рекомендации могут не применяться.If you are using Azure Cache for Redis as a temporary data cache and not as a persistent store, these recommendations may not apply.

Подготовьте несколько реплик.Provision more than one replica. Используйте как минимум две реплики, чтобы обеспечить высокую доступность операций чтения, или три, чтобы обеспечить высокую доступность операций чтения и записи.Use at least two replicas for read high-availability, or three for read-write high-availability.

Настройте индексаторы для развертываний в нескольких регионах.Configure indexers for multi-region deployments. Если имеется развертывание в нескольких регионах, рассмотрите варианты непрерывности индексирования.If you have a multi-region deployment, consider your options for continuity in indexing.

  • Если источник данных геореплицируется, вы должны, как правило, указывать для каждого индексатора каждой региональной службы поиска Azure свою локальную реплику источника данных.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. Однако мы не рекомендуем использовать этот подход для больших наборов данных, хранящихся в Базе данных SQL Azure.However, that approach is not recommended for large datasets stored in Azure SQL Database. Причина в том, что служба "Поиск Azure" не может выполнить добавочное индексирование из вторичных реплик базы данных SQL, а только из первичной реплики.The reason is that Azure Search cannot perform incremental indexing from secondary SQL Database replicas, only from primary replicas. Вместо этого укажите для всех индексаторов первичную реплику.Instead, point all indexers to the primary replica. После отработки отказа укажите для индексаторов службы "Поиск Azure" новую первичную реплику.After a failover, point the Azure Search indexers at the new primary replica.

  • Если источник данных не геореплицируется, укажите для нескольких индексаторов один источник данных, чтобы службы Поиска Azure в нескольких регионах непрерывно и независимо индексировали источник данных.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. Дополнительные сведения см. в статье вопросы производительности и оптимизации службы поиска Azure.For more information, see Azure Search performance and optimization considerations.

Служебная шинаService Bus

Используйте уровень "премиум" для рабочих нагрузок.Use Premium tier for production workloads. Премиум-сообщения служебной шины Azure предоставляют выделенные и зарезервированные вычислительные ресурсы и объем памяти для поддержки прогнозируемой производительности и пропускной способности.Service Bus Premium Messaging provides dedicated and reserved processing resources, and memory capacity to support predictable performance and throughput. Они также предоставляют доступ к новым функциям, доступным только для премиум-клиентов.Premium Messaging tier also gives you access to new features that are available only to premium customers at first. Вы можете определить количество сообщений на основе ожидаемых рабочих нагрузок.You can decide the number of messaging units based on expected workloads.

Обработка повторяющихся сообщений.Handle duplicate messages. Если издатель перестает работать сразу после отправки сообщения или при неполадках в сети или системе, он может ошибочно не записать, что сообщение было доставлено, и может отправить одно и то же сообщение в систему дважды.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. Служебная шина Azure может решить эту проблему, включив обнаружение повторяющихся сообщений.Service Bus can handle this issue by enabling duplicate detection. Дополнительные сведения см. в разделе Синхронизация удостоверений и устойчивость обнаружения.For more information, see Duplicate detection.

Обработка исключений.Handle exceptions. API обмена сообщениями генерирует исключения, когда возникает ошибка пользователя, настройки или другая ошибка.Messaging APIs generate exceptions when a user error, configuration error, or other error occurs. Код клиента (отправителя и получателя) должен обрабатывать эти исключения в своем коде.The client code (senders and receivers) should handle these exceptions in their code. Это особенно важно в использовании пакетной обработки во избежании потери целой партии сообщений.This is especially important in batch processing, where exception handling can be used to avoid losing an entire batch of messages. Дополнительные сведения см. в статье Исключения обмена сообщениями служебной шины.For more information, see Service Bus messaging exceptions.

Политика повтораRetry policy. Служебная шина позволяет выбрать наилучшую политику повтора для ваших приложений.Service Bus allows you to pick the best retry policy for your applications. Политика по умолчанию разрешает максимально 9 повторных попыток с ожиданием 30 секунд, но это можно настраивать дополнительно.The default policy is to allow 9 maximum retry attempts, and wait for 30 seconds but this can be further adjusted. Дополнительные сведения см. на странице Политика повтора — служебная шина.For more information, see Retry policy – Service Bus.

Использование недоставленных сообщений.Use a dead-letter queue. Если сообщение не может быть обработано или доставлено любому получателю после нескольких попыток, оно перемещается в очередь недоставленных сообщений.If a message cannot be processed or delivered to any receiver after multiple retries, it is moved to a dead letter queue. Внедрите процесс чтения сообщений из очереди недоставленных сообщений, проверьте их и устраните проблему.Implement a process to read messages from the dead letter queue, inspect them, and remediate the problem. В зависимости от сценария вы можете повторить сообщение как есть, внести изменения и повторить попытку отправки или отказаться от него.Depending on the scenario, you might retry the message as-is, make changes and retry, or discard the message. Дополнительные сведения см. в статье Обзор очередей недоставленных сообщений служебной шины.For more information, see Overview of Service Bus dead-letter queues.

Используйте геоизбыточное аварийное восстановление.Use Geo-Disaster Recovery. Географическое аварийное восстановление гарантирует, что обработка данных будет продолжать работать в другом регионе или центре обработки данных, если весь регион или центр данных Azure станет недоступным из-за стихийного бедствия.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. Дополнительные сведения см. в разделе Географическое аварийное восстановление в служебной шине Azure.For more information, see Azure Service Bus Geo-disaster recovery.

Служба хранилищаStorage

Используйте геоизбыточное хранилище с доступом для чтения для данных приложения.For application data, use read-access geo-redundant storage (RA-GRS). Хранилище RA-GRS реплицирует данные в дополнительный регион и предоставляет доступ только для чтения из вторичного региона.RA-GRS storage replicates the data to a secondary region, and provides read-only access from the secondary region. При наличии доступа к хранилищу в первичном регионе приложение может считывать данные из вторичного региона.If there is a storage outage in the primary region, the application can read the data from the secondary region. Дополнительные сведения см. в статье Репликация службы хранилища Azure.For more information, see Azure Storage replication.

Для дисков виртуальных машин используйте управляемые диски.For VM disks, use managed disks. Управляемые диски обеспечивают лучшую надежность виртуальных машин в группе доступности, так как диски достаточно изолированы друг от друга, чтобы избежать единых точек отказа.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. Кроме того, управляемые диски не подвержены ограничениям операций ввода-вывода для виртуальных жестких дисков, созданных в учетной записи хранения.Also, managed disks aren't subject to the IOPS limits of VHDs created in a storage account. Дополнительные сведения см. в статье Управление доступностью виртуальных машин Windows в Azure.For more information, see Manage the availability of Windows virtual machines in Azure.

Создайте резервную очередь в другом регионе, чтобы создать хранилище очередей.For Queue storage, create a backup queue in another region. Для хранилища очередей реплика, предназначенная только для чтения, ограничена в использовании, так как вы не можете ставить элементы в очередь или удалять их из нее.For Queue storage, a read-only replica has limited use, because you can't queue or dequeue items. Вместо этого создайте резервную очередь в учетной записи хранения в другом регионе.Instead, create a backup queue in a storage account in another region. При отказе хранилища приложение может использовать резервную очередь, пока основной регион снова не станет доступен.If there is a storage outage, the application can use the backup queue, until the primary region becomes available again. Таким образом приложение может обрабатывать новые запросы.That way, the application can still process new requests.

База данных SQLSQL Database

Уровень "Стандартный" или "Премиум".Use Standard or Premium tier. Эти уровни обеспечивают более длительный период восстановления на определенный момент времени (35 дней).These tiers provide a longer point-in-time restore period (35 days). Дополнительные сведения см. в статье Что такое уровни служб Базы данных SQL.For more information, see SQL Database options and performance.

Включите аудит базы данных SQL.Enable SQL Database auditing. Аудит может использоваться для диагностики вредоносных атак или ошибки из-за человеческого фактора.Auditing can be used to diagnose malicious attacks or human error. Дополнительные сведения см. в статье Приступая к работе с аудитом базы данных SQL.For more information, see Get started with SQL database auditing.

Используйте активную георепликацию, чтобы создать доступную для чтения вторичную реплику в другом регионе.Use Active Geo-Replication Use Active Geo-Replication to create a readable secondary in a different region. Если произойдет сбой вашей базы данных-источника (или вам просто потребуется перевести ее в автономный режим), выполните отработку отказа в ручном режиме в любую базу данных-получатель.If your primary database fails, or simply needs to be taken offline, perform a manual failover to the secondary database. До отработки отказа база данных-получатель остается доступной только для чтения.Until you fail over, the secondary database remains read-only. Дополнительные сведения см. в статье Обзор. Группы отработки отказа и активная георепликация.For more information, see SQL Database Active Geo-Replication.

Используйте сегментирование.Use sharding. Рассмотрите возможность использования сегментирования для горизонтального секционирования базы данных.Consider using sharding to partition the database horizontally. Сегментирование может обеспечить изоляцию от сбоев.Sharding can provide fault isolation. Дополнительные сведения см. в статье Развертывание с помощью Базы данных SQL Azure.For more information, see Scaling out with Azure SQL Database.

Используйте восстановление до точки во времени для восстановления после ошибки пользователя.Use point-in-time restore to recover from human error. При восстановлении до точки во времени база данных возвращается в состояние на более ранний момент времени.Point-in-time restore returns your database to an earlier point in time. Дополнительные сведения см. в статье Восстановление базы данных SQL Azure с помощью автоматических резервных копий.For more information, see Recover an Azure SQL database using automated database backups.

Используйте геовосстановление для восстановления после сбоя службы.Use geo-restore to recover from a service outage. При геовосстановлении база данных восстанавливается из геоизбыточной резервной копии.Geo-restore restores a database from a geo-redundant backup. Дополнительные сведения см. в статье Восстановление базы данных SQL Azure с помощью автоматических резервных копий.For more information, see Recover an Azure SQL database using automated database backups.

Хранилище данных SQLSQL Data Warehouse

Не отключайте геоизбыточное резервное копирование.Do not disable geo-backup. По умолчанию в Хранилище данных SQL каждые 24 часа выполняется полное резервное копирование данных для аварийного восстановления.By default, SQL Data Warehouse takes a full backup of your data every 24 hours for disaster recovery. Не рекомендуется отключать эту функцию.It is not recommended to turn this feature off. Дополнительные сведения см. в разделе о геоизбыточных резервных копиях.For more information, see Geo-backups.

SQL Server на виртуальной машинеSQL Server running in a VM

Реплицируйте базу данных.Replicate the database. Для репликации базы данных используйте SQL Server группы доступности Always On.Use SQL Server Always On availability groups to replicate the database. При сбое в одном экземпляре SQL Server они обеспечивают высокий уровень доступности.Provides high availability if one SQL Server instance fails. Дополнительные сведения см. в статье Запуск виртуальных машин Windows для n-уровневого приложения.For more information, see Run Windows VMs for an N-tier application

Архивируйте базу данных.Back up the database. Если вы уже используете службу Azure Backup для архивации виртуальных машин, рассмотрите возможность ее использования для рабочих нагрузок SQL Server с помощью DPM.If you are already using Azure Backup to back up your VMs, consider using Azure Backup for SQL Server workloads using DPM. При таком подходе используется одна роль администратора архивации для организации и единая процедура восстановления для виртуальных машин и SQL Server.With this approach, there is one backup administrator role for the organization and a unified recovery procedure for VMs and SQL Server. В противном случае используйте управляемое резервное копирование SQL Server в Microsoft Azure.Otherwise, use SQL Server Managed Backup to Microsoft Azure.

Диспетчер трафикаTraffic Manager

Выполняйте восстановление размещения вручную.Perform manual failback. После отработки отказа диспетчера трафика выполните восстановление размещения вручную, а не автоматически.After a Traffic Manager failover, perform manual failback, rather than automatically failing back. Убедитесь, что все подсистемы приложения полностью работоспособны, и лишь затем выполните восстановление размещения.Before failing back, verify that all application subsystems are healthy. В противном случае можно создать ситуацию, когда приложение переворачивается между центрами обработки данных.Otherwise, you can create a situation where the application flips back and forth between datacenters. Дополнительные сведения см. в статье Запуск виртуальных машин Windows в нескольких регионах для обеспечения высокой доступности.For more information, see Run VMs in multiple regions for high availability.

Создайте конечную точку проверки работоспособности.Create a health probe endpoint. Создайте пользовательскую конечную точку, которая сообщает об общей работоспособности приложения.Create a custom endpoint that reports on the overall health of the application. Это позволяет диспетчеру трафика выполнить отработку отказа при сбое любого критического пути, а не только внешнего интерфейса.This enables Traffic Manager to fail over if any critical path fails, not just the front end. Конечная точка должна возвращать код ошибки HTTP, если какая-либо критическая зависимость неработоспособна или недоступна.The endpoint should return an HTTP error code if any critical dependency is unhealthy or unreachable. Однако не сообщайте об ошибках некритических служб.Don't report errors for non-critical services, however. В противном случае проверка работоспособности может вызвать ненужную отработку отказа, создавая ложные срабатывания.Otherwise, the health probe might trigger failover when it's not needed, creating false positives. Дополнительные сведения см. в статье Мониторинг конечных точек в диспетчере трафика.For more information, see Traffic Manager endpoint monitoring and failover.

Виртуальные машиныVirtual Machines

Не выполняйте рабочую нагрузку на одной виртуальной машине.Avoid running a production workload on a single VM. Одно развертывание виртуальной машины неустойчиво при плановом или внеплановом обслуживании.A single VM deployment is not resilient to planned or unplanned maintenance. Вместо этого следует разместить несколько виртуальных машин в группе доступности или масштабируемом наборе виртуальных машинс подсистемой балансировки нагрузки на передний план.Instead, put multiple VMs in an availability set or virtual machine scale set, with a load balancer in front.

Укажите группу доступности при подготовке виртуальной машины.Specify an availability set when you provision the VM. В настоящее время после подготовки виртуальную машину невозможно добавить в группу доступности.Currently, there is no way to add a VM to an availability set after the VM is provisioned. Добавляя новую виртуальную машину в имеющуюся группу доступности, обязательно создайте сетевую карту для виртуальной машины и добавьте ее в серверный пул адресов в подсистеме балансировки нагрузки.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. В противном случае подсистема балансировки нагрузки не будет маршрутизировать сетевой трафик на эту виртуальную машину.Otherwise, the load balancer won't route network traffic to that VM.

Поместите каждый уровень приложения в отдельных группах доступности.Put each application tier into a separate Availability Set. В n-уровневом приложении не следует размещать виртуальные машины из разных уровней в одной группе доступности.In an N-tier application, don't put VMs from different tiers into the same availability set. Виртуальные машины в группе доступности располагаются в доменах сбоя и доменах обновления.VMs in an availability set are placed across fault domains (FDs) and update domains (UD). Тем не менее, чтобы получить преимущества избыточности этих доменов, каждая виртуальная машина в группе доступности должна иметь возможность обрабатывать одни и те же клиентские запросы.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.

Репликация виртуальных машин с помощью Site Recovery.Replicate VMs using Azure Site Recovery. При репликации виртуальных машин Azure с помощью Site Recoveryвсе диски виртуальных машин постоянно реплицируются в целевой регион в асинхронном режиме.When you replicate Azure VMs using Site Recovery, all the VM disks are continuously replicated to the target region asynchronously. Точки восстановления создаются каждые несколько минут.The recovery points are created every few minutes. Это обеспечивает требуемую целевую точку восстановления (RPO) в минутах.This gives you a Recovery Point Objective (RPO) in the order of minutes. Вы можете выполнять детализацию аварийного восстановления столько раз, сколько нужно, не затрагивая рабочее приложение или текущую репликацию.You can conduct disaster recovery drills as many times as you want, without affecting the production application or the ongoing replication. Дополнительные сведения см. в статье выполнение перехода на аварийное восстановление в Azure.For more information, see Run a disaster recovery drill to Azure.

Выберите подходящий размер виртуальной машины в соответствии с требованиями к производительности.Choose the right VM size based on performance requirements. При перемещении имеющейся рабочей нагрузки в Azure выберите начальный размер виртуальной машины, который больше всего соответствует вашим локальным серверам.When moving an existing workload to Azure, start with the VM size that's the closest match to your on-premises servers. Затем измерьте производительность фактической рабочей нагрузки по таким ресурсам, как потребление ЦП, памяти и дисковых операций ввода-вывода в секунду, и при необходимости измените размер виртуальной машины.Then measure the performance of your actual workload with respect to CPU, memory, and disk IOPS, and adjust the size if needed. Это гарантирует, что приложение будет правильно работать в облачной среде.This helps to ensure the application behaves as expected in a cloud environment. Кроме того, если требуется использовать несколько сетевых карт, то учтите ограничения на количество сетевых карт для каждого размера.Also, if you need multiple NICs, be aware of the NIC limit for each size.

Используйте управляемые диски для виртуальных жестких дисков.Use managed disks for VHDs. Управляемые диски обеспечивают лучшую надежность виртуальных машин в группе доступности, так как диски достаточно изолированы друг от друга, чтобы избежать единых точек отказа.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. Кроме того, управляемые диски не подвержены ограничениям операций ввода-вывода для виртуальных жестких дисков, созданных в учетной записи хранения.Also, managed disks aren't subject to the IOPS limits of VHDs created in a storage account. Дополнительные сведения см. в статье Управление доступностью виртуальных машин Windows в Azure.For more information, see Manage the availability of Windows virtual machines in Azure.

Устанавливайте приложения на диск данных, а не на диск операционной системы.Install applications on a data disk, not the OS disk. В противном случае можно превысить предельный размер диска.Otherwise, you may reach the disk size limit.

Используйте службу Azure Backup для архивации виртуальных машин.Use Azure Backup to back up VMs. Резервные копии позволяют обеспечить защиту от случайной потери данных.Backups protect against accidental data loss. Дополнительные сведения см. в статье Защита виртуальных машин Azure с помощью хранилища служб восстановления.For more information, see Protect Azure VMs with a Recovery Services vault.

Включите журналы диагностики.Enable diagnostic logs. Включите базовые метрики работоспособности, журналы инфраструктуры и диагностику загрузки.Include basic health metrics, infrastructure logs, and boot diagnostics. Если виртуальную машину невозможно загрузить, для обнаружения неисправностей можно использовать диагностику загрузки.Boot diagnostics can help you diagnose a boot failure if your VM gets into a non-bootable state. Дополнительные сведения см. в статье Обзор журналов диагностики Azure.For more information, see Overview of Azure Diagnostic Logs.

Используйте расширение AzureLogCollector.Use the AzureLogCollector extension. (Только для виртуальных машин Windows.) Это расширение объединяет журналы платформы Azure и загружает их в службу хранилища Azure без необходимости удаленного входа оператора в виртуальную машину.(Windows VMs only.) This extension aggregates Azure platform logs and uploads them to Azure storage, without the operator remotely logging into the VM. Дополнительные сведения см. в статье Расширение AzureLogCollector.For more information, see AzureLogCollector Extension.

Виртуальная сетьVirtual Network

Чтобы список разрешений или заблокировать общедоступные IP-адреса, добавьте в подсеть группу безопасности сети.To whitelist or block public IP addresses, add a network security group to the subnet. Блокируйте доступ злоумышленников или разрешите доступ только для пользователей с привилегиями для доступа к приложению.Block access from malicious users, or allow access only from users who have privilege to access the application.

Создайте пользовательскую проверку работоспособности.Create a custom health probe. При проверке работоспособности Load Balancer может тестироваться HTTP или TCP.Load Balancer Health Probes can test either HTTP or TCP. Если виртуальная машина работает на HTTP-сервере, проверка HTTP поможет лучше определить состояние работоспособности, чем проверка TCP.If a VM runs an HTTP server, the HTTP probe is a better indicator of health status than a TCP probe. Для проверки HTTP используйте настраиваемую конечную точку, которая сообщает об общей работоспособности приложения, включая все критические зависимости.For an HTTP probe, use a custom endpoint that reports the overall health of the application, including all critical dependencies. Дополнительные сведения см. в разделе Обзор Azure Load Balancer.For more information, see Azure Load Balancer overview.

Не блокируйте проверку работоспособности.Don't block the health probe. Проверка работоспособности Load Balancer отправляется с известного IP-адреса — 168.63.129.16.The Load Balancer Health probe is sent from a known IP address, 168.63.129.16. Не блокируйте входящий и исходящий трафик этого IP-адреса в политиках брандмауэра или в правилах групп безопасности сети.Don't block traffic to or from this IP in any firewall policies or network security group rules. При блокировании проверки работоспособности подсистема балансировки нагрузки удаляет виртуальную машину из ротации.Blocking the health probe would cause the load balancer to remove the VM from rotation.

Включите ведение журнала для Load Balancer.Enable Load Balancer logging. В журналах показано, сколько виртуальных машин на серверной стороне не получают сетевой трафик из-за неудачных ответов проверки.The logs show how many VMs on the back-end are not receiving network traffic due to failed probe responses. Дополнительные сведения см. в статье Служба анализа журналов для Azure Load Balancer.For more information, see Log analytics for Azure Load Balancer.