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

  • Статья

Устойчивость представляет собой возможность восстановления системы после сбоев и продолжения работы. Каждая технология имеет собственные режимы сбоев, которые необходимо учитывать при разработке и реализации приложения. Используйте этот контрольный список для проверки факторов устойчивости конкретных служб Azure. Дополнительные сведения о проектировании устойчивых приложений см. в разделе Разработка надежных приложений Azure.

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

Уровень "Стандартный" или "Премиум". Эти уровни поддерживают промежуточные слоты и автоматическое резервное копирование. Дополнительные сведения см. в статье Подробный обзор планов службы приложений Azure.

Избегайте увеличения или уменьшения масштаба. Вместо этого выберите уровень и размер экземпляра в соответствии с требованиями к производительности при типичной нагрузке, а затем выполните горизонтальное увеличение масштаба экземпляров для обработки изменений объема трафика. Увеличение или уменьшение масштаба может вызвать перезапуск приложения.

Сохраняйте конфигурацию в виде настроек приложений. Используйте настройки приложения, чтобы сохранить параметры конфигурации в качестве настроек приложения. Определите параметры в шаблонах Resource Manager или с помощью PowerShell, чтобы применить их в процессе автоматического развертывания или обновления. Этот подход надежнее. Дополнительные сведения см. в статье Настройка веб-приложений в службе приложений Azure.

Используйте разные планы службы приложений для рабочей и тестовой сред. Не используйте слоты в рабочем развертывании для тестирования. Все приложения, которые находятся в одном плане службы приложений, совместно используют одни экземпляры виртуальных машин. Если разместить рабочее и тестовое развертывание в одном плане, это может негативно повлиять на рабочее развертывание. Например, нагрузочные тесты могут привести к ухудшению производительности активного рабочего сайта. Поместив тестовые развертывания в отдельный план, можно изолировать их от рабочей версии.

Отделите веб-приложения от веб-API. Если в решении есть как веб-интерфейс, так и веб-API, рассмотрите возможность их разбивки на отдельные приложения Службы приложений. Такой подход помогает распределять решения по рабочим нагрузкам. Вы можете запускать веб-приложение и API в отдельных планах службы приложений, чтобы они могли масштабироваться независимо друг от друга. Если изначально этот уровень масштабируемости не требуется, можно развертывать приложения в одном плане и позже переместить их в отдельные планы (при необходимости).

Развертывание планов, избыточных между зонами, Служба приложений. В поддерживаемых регионах Служба приложений планы можно развернуть как избыточное по зонам, что означает, что экземпляры автоматически распределяются по зонам доступности. Служба приложений автоматически распределяет трафик между зонами и обрабатывает отработку отказа, если зона возникает сбой. Дополнительные сведения см. в разделе "Миграция Служба приложений в поддержку зоны доступности".

Избегайте использования функции резервного копирования службы приложений для резервного копирования баз данных Azure SQL. Вместо этого используйте автоматическое резервное копирование базы данных SQL. При резервном копировании службы приложений база данных экспортируется в BACPAC-файл SQL, использующий единицы DTU.

Выполните развертывание в промежуточном слоте. Создайте слот развертывания для размещения в промежуточной среде. Разверните обновления приложений в промежуточном слоте и проверьте развертывание, прежде чем переносить его в рабочую среду. Это снижает вероятность неправильного обновления в рабочей среде. Это также гарантирует, что все экземпляры подготовлены перед перемещением в рабочую среду. Для многих приложений довольно долго выполняются начальная загрузка и "холодный" запуск. Дополнительные сведения см. в статье Настройка промежуточных сред в службе приложений Azure.

Создайте слот развертывания для хранения последнего известного корректного развертывания (LKG). При развертывании обновления в рабочей среде переместите предыдущее рабочее развертывание в слот LKG. Это упрощает откат неправильного развертывания. Если в дальнейшем обнаруживается проблема, можно быстро вернуться к версии LKG. Дополнительные сведения см. в статье Basic web application (Базовое веб-приложение).

Включите ведение журнала диагностики, в частности для приложения и веб-сервера. Ведение журнала важно для мониторинга и диагностики. Ознакомьтесь со статьей Включение ведения журнала диагностики для веб-приложений в службе приложений Azure.

Храните данные журнала в хранилище BLOB-объектов. Это упрощает сбор и анализ данных.

Создайте отдельную учетную запись хранения для журналов. Не используйте одну учетную запись хранения для журналов и данных приложения. Это помогает предотвратить снижение производительности приложения из-за ведения журнала.

Отслеживайте производительность. Используйте службу мониторинга производительности, например New Relic или Application Insights, чтобы контролировать производительность и поведение загруженных приложений. Мониторинг производительности дает вам представление о приложении в режиме реального времени. Он позволяет диагностировать проблемы и выполнять анализ основной причины сбоев.

Azure Load Balancer

Выберите номер SKU "Стандартный". Load Balancer (цен. категория обеспечивает измерение надежности, которое не является базовым — для зон доступности и устойчивости зон. Когда зона становится недоступна, это не влияет на работу Load Balancer ценовой категории "Стандартный". Таким образом, развертывания устойчивы к сбоям зон в пределах региона. Кроме того, служба Load Balancer ценовой категории "Стандартный" поддерживает глобальную балансировку нагрузки, что делает приложение устойчивым также и к сбоям в масштабе региона.

Подготовьте по крайней мере два экземпляра. Разверните подсистему балансировки нагрузки Azure по крайней мере с двумя экземплярами в серверной части. Один экземпляр может привести к возникновению единой точки отказа. Чтобы обеспечить масштабируемость, может потребоваться использовать Load Balancer в сочетании с Масштабируемыми наборами виртуальных машин.

Используйте правила исходящего трафика. Правила исходящего трафика гарантируют, что вы не столкнулись с сбоями подключения в результате исчерпания портов SNAT. Ознакомьтесь со сведениями об исходящих подключениях. Хотя правила для исходящего трафика помогают оптимизировать работу решения с небольшим или средним масштабом развертывания, для рабочих нагрузок рекомендуется использовать Load Balancer ценовой категории "Стандартный" или развертывание подсети с NAT виртуальной сети.

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

Подготовьте по крайней мере два экземпляра. Разверните шлюз приложений как минимум с двумя экземплярами. Один экземпляр является единой точкой отказа. Используйте два или более экземпляров для обеспечения избыточности и масштабируемости. В соответствии с соглашением об уровне обслуживания необходимо предоставить два или более экземпляров среднего или большего размера.

Azure Cosmos DB

Настройте избыточность зоны. При использовании избыточности зоны Azure Cosmos DB синхронно реплика tes все записи в зонах доступности. Он автоматически выполняет отработку отказа в случае сбоя зоны. Дополнительные сведения см. в статье "Обеспечение высокого уровня доступности с помощью Azure Cosmos DB".

Реплицируйте базу данных в разные регионы. Azure Cosmos DB позволяет связать любое количество регионов Azure с учетной записью базы данных Azure Cosmos DB. База данных Azure Cosmos DB может иметь один регион записи и несколько регионов чтения. В случае сбоя в регионе записи можно выполнять чтение из другой реплики. Клиентский пакет SDK обрабатывает это автоматически. Кроме того, можно выполнить отработку отказа региона записи в другой регион. Дополнительные сведения см. в статье Как работает глобальное распределение данных в Azure с помощью Cosmos DB.

Event Hubs

Использование контрольных точек. Потребитель события должен записывать свою текущую позицию в постоянное хранилище с предопределенным интервалом. Таким образом, если работа потребителя приостановлена (например, происходит сбой потребителя или сбой узла), то новый экземпляр может возобновить чтение потока с последней записанной позиции. См. дополнительные сведения о потребителях событий.

Обработка повторяющихся сообщений. При сбое потребителя события обработка сообщений возобновляется с последней записанной контрольной точки. Все сообщения, обработанные после последней контрольной точки, будут обработаны повторно. Поэтому логика обработки сообщений должна быть идемпотентной. Или приложение должно уметь дедуплицировать сообщения.

Обработка исключений. Потребитель события обычно обрабатывает пакет сообщений в цикле. Вы должны обработать исключения в этом цикле обработки, чтобы избежать потери всего пакета сообщений, если одно сообщение приводит к возникновению исключения.

Использование недоставленных сообщений. Если обработка сообщения приводит к временному сбою, поместите сообщение в очередь недоставленных сообщений, чтобы отслеживать состояние. В зависимости от сценария можно повторно отправить сообщение позже, применить компенсирующую транзакцию или предпринять другое действие. Обратите внимание, что в Центрах событий нет встроенной функции очереди недоставленных сообщений. Вместо этого можно использовать хранилище очередей Azure, служебную шину, Функции Azure или другой механизм обработки событий.

Настройте избыточность зоны. Если избыточность зоны включена в пространстве имен, центры событий автоматически реплика tes изменяются между несколькими зонами доступности. Если одна зона доступности завершается ошибкой, отработка отказа происходит автоматически. Дополнительные сведения см. в статье Регионы и зоны доступности в Azure.

Реализация аварийного восстановления с помощью отработки отказа в дополнительное пространство имен Центров событий. Дополнительные сведения см. в статье Географическое аварийное восстановление в Центрах событий Azure.

Кэш Azure для Redis

Настройте избыточность зоны. Если в кэше включена избыточность зоны, Кэш Azure для Redis распределяет виртуальные машины, в которых размещается кэш в нескольких зонах доступности. Избыточность зоны обеспечивает высокий уровень доступности и отказоустойчивость в случае сбоя центра обработки данных. Дополнительные сведения см. в разделе "Включение избыточности зоны" для Кэш Azure для Redis.

Настройка георепликации. Георепликация предоставляет механизм связывания двух экземпляров Кэша Azure для Redis категории "Премиум". Данные, записанные в основном кэше, реплицируются во вторичный кэш только для чтения. Дополнительные сведения см. в статье Настройка георепликации для Кэша Azure для Redis.

Настройка сохраняемости данных. Постоянное хранение Redis позволяет постоянно хранить данные, размещенные в Redis. Также можно создавать моментальные снимки и архивировать данные, которые можно будет восстановить в случае сбоя оборудования. Дополнительные сведения см. в статье Настройка сохраняемости данных для Кэша Azure для Redis уровня "Премиум".

Если вы используете Кэш Azure для Redis как временный кэш данных, а не постоянное хранилище, возможно, эти рекомендации будут неприменимы.

Подготовьте несколько реплик. Используйте как минимум две реплики, чтобы обеспечить высокую доступность операций чтения, или три, чтобы обеспечить высокую доступность операций чтения и записи.

Используйте избыточность зоны. Вы можете развернуть реплика Когнитивного поиска в нескольких зонах доступности. Такой подход помогает вашей службе оставаться в эксплуатации даже при сбое центра обработки данных. Дополнительные сведения см. в разделе "Надежность" в Когнитивный поиск Azure

Настройте индексаторы для развертываний в нескольких регионах. Если имеется развертывание в нескольких регионах, рассмотрите варианты непрерывности индексирования.

  • Если источник данных геоизбыток реплика, обычно следует указать каждый индексатор каждой региональной службы Когнитивный поиск Azure на локальный источник данных реплика. Однако мы не рекомендуем использовать этот подход для больших наборов данных, хранящихся в Базе данных SQL Azure. Причина заключается в том, что Когнитивный поиск Azure не может выполнять добавочное индексирование из вторичных База данных SQL реплика только из первичных реплика. Вместо этого укажите для всех индексаторов первичную реплику. После отработки отказа наведите указатель на индексаторы Когнитивный поиск Azure на новый первичный реплика.

  • Если источник данных не реплика геоизбыток, наведите указатель на несколько индексаторов в одном источнике данных, чтобы Когнитивный поиск Azure службы в нескольких регионах непрерывно и независимо индексировать из источника данных. Дополнительные сведения см. в статье Рекомендации по производительности и оптимизации Поиска Azure.

Cлужебная шина

Используйте уровень "премиум" для рабочих нагрузок. Премиум-сообщения служебной шины Azure предоставляют выделенные и зарезервированные вычислительные ресурсы и объем памяти для поддержки прогнозируемой производительности и пропускной способности. Они также предоставляют доступ к новым функциям, доступным только для премиум-клиентов. Вы можете определить количество сообщений на основе ожидаемых рабочих нагрузок.

Обработка повторяющихся сообщений. Если издатель перестает работать сразу после отправки сообщения или при неполадках в сети или системе, он может ошибочно не записать, что сообщение было доставлено, и может отправить одно и то же сообщение в систему дважды. Служебная шина Azure может решить эту проблему, включив обнаружение повторяющихся сообщений. Дополнительные сведения см. в разделе Синхронизация удостоверений и устойчивость обнаружения.

Обработка исключений. API обмена сообщениями генерирует исключения, когда возникает ошибка пользователя, настройки или другая ошибка. Код клиента (отправителя и получателя) должен обрабатывать эти исключения в своем коде. Это особенно важно в использовании пакетной обработки во избежании потери целой партии сообщений. Дополнительные сведения см. в статье Исключения обмена сообщениями служебной шины.

Политика повтора Служебная шина позволяет выбрать наилучшую политику повтора для ваших приложений. Политика по умолчанию разрешает максимально 9 повторных попыток с ожиданием 30 секунд, но это можно настраивать дополнительно. Дополнительные сведения см. на странице Политика повтора — служебная шина.

Использование недоставленных сообщений. Если сообщение не может быть обработано или доставлено любому получателю после нескольких попыток, оно перемещается в очередь недоставленных сообщений. Внедрите процесс чтения сообщений из очереди недоставленных сообщений, проверьте их и устраните проблему. В зависимости от сценария вы можете повторить сообщение как есть, внести изменения и повторить попытку отправки или отказаться от него. Дополнительные сведения см. в статье Обзор очередей недоставленных сообщений служебной шины.

Используйте избыточность зоны. Если избыточность зоны включена в пространстве имен, служебная шина автоматически реплика изменения между несколькими зонами доступности. Если одна зона доступности завершается ошибкой, отработка отказа происходит автоматически. Дополнительные сведения см. в статье Рекомендации по изолированию приложений от простоев и аварий служебной шины.

Используйте геоизбыточное аварийное восстановление. Географическое аварийное восстановление гарантирует, что обработка данных будет продолжать работать в другом регионе или центре обработки данных, если весь регион или центр данных Azure станет недоступным из-за стихийного бедствия. Дополнительные сведения см. в разделе Географическое аварийное восстановление в служебной шине Azure.

Хранилище

Используйте хранилище, избыточное между зонами. Хранилище, избыточное между зонами (ZRS), синхронно копирует данные между тремя зонами доступности Azure в основном регионе. Если зона доступности возникает сбой, служба хранилища Azure автоматически выполняется отработка отказа в альтернативную зону. Дополнительные сведения см. в статье Репликация службы хранилища Azure.

При использовании геоизбыточности настройте доступ на чтение. Если вы используете архитектуру с несколькими регионами, используйте подходящий уровень хранилища для глобальной избыточности. При использовании RA-GRS или RA-GZRS данные реплика в дополнительный регион. RA-GRS использует локально избыточное хранилище (LRS) в основном регионе, а RA-GZRS использует хранилище, избыточное между зонами (ZRS) в основном регионе. Обе конфигурации предоставляют доступ только для чтения к данным в дополнительном регионе. Если в основном регионе произошел сбой хранилища, приложение может считывать данные из дополнительного региона, если это возможно. Дополнительные сведения см. в статье Репликация службы хранилища Azure.

Используйте управляемые диски в качестве дисков виртуальных машин.Служба Управляемые диски обеспечивает более высокую надежность виртуальных машин в группах доступности, так как диски достаточно изолированы друг от друга, что позволяет избежать единой точки отказа. Кроме того, управляемые диски не подпадают под ограничения операций ввода-вывода в секунду для виртуальных жестких дисков (VHD), созданных в учетной записи хранения. Дополнительные сведения см. в статье Управление доступностью виртуальных машин Windows в Azure.

Создайте резервную очередь в другом регионе, чтобы создать хранилище очередей. Для служба хранилища очереди реплика доступно только для чтения, так как невозможно выполнить очередь или отмену элементов. Вместо этого создайте резервную очередь в учетной записи хранения в другом регионе. Если служба хранилища Azure сбой, приложение может использовать очередь резервного копирования, пока основной регион не станет доступным снова. Таким образом, приложение может продолжать обрабатывать новые запросы во время сбоя.

База данных SQL

Уровень "Стандартный" или "Премиум". Эти уровни обеспечивают более длительный период восстановления на определенный момент времени (35 дней). Дополнительные сведения см. в статье Что такое уровни служб Базы данных SQL.

Включите аудит базы данных SQL. Аудит может использоваться для диагностики вредоносных атак или ошибки из-за человеческого фактора. Дополнительные сведения см. в статье Приступая к работе с аудитом базы данных SQL.

Используйте активную георепликацию, чтобы создать доступную для чтения вторичную реплику в другом регионе. Если произойдет сбой вашей базы данных-источника (или вам просто потребуется перевести ее в автономный режим), выполните отработку отказа в ручном режиме в любую базу данных-получатель. До отработки отказа база данных-получатель остается доступной только для чтения. Дополнительные сведения см. в статье Обзор. Группы отработки отказа и активная георепликация.

Используйте сегментирование. Рассмотрите возможность использования сегментирования для горизонтального секционирования базы данных. Сегментирование может обеспечить изоляцию от сбоев. Дополнительные сведения см. в статье Развертывание с помощью Базы данных SQL Azure.

Используйте восстановление до точки во времени для восстановления после ошибки пользователя. При восстановлении до точки во времени база данных возвращается в состояние на более ранний момент времени. Дополнительные сведения см. в статье Восстановление базы данных Azure SQL с помощью создаваемых автоматически резервных копий.

Используйте геовосстановление для восстановления после сбоя службы. При геовосстановлении база данных восстанавливается из геоизбыточной резервной копии. Дополнительные сведения см. в статье Восстановление базы данных Azure SQL с помощью создаваемых автоматически резервных копий.

Azure Synapse Analytics

Не отключайте геоизбыточное резервное копирование. По умолчанию Synapse Analytics выполняет полную резервную копию данных в выделенном пуле SQL каждые 24 часа для аварийного восстановления. Не рекомендуется отключать эту функцию. Дополнительные сведения см. в разделе о геоизбыточных резервных копиях.

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

Архивируйте базу данных. Если вы уже используете службу Azure Backup для архивации виртуальных машин, рассмотрите возможность ее использования для рабочих нагрузок SQL Server с помощью DPM. При таком подходе используется одна роль администратора архивации для организации и единая процедура восстановления для виртуальных машин и SQL Server. В противном случае используйте управляемое резервное копирование SQL Server в Microsoft Azure.

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

Выполняйте восстановление размещения вручную. После отработки отказа диспетчера трафика выполните восстановление размещения вручную, а не автоматически. Убедитесь, что все подсистемы приложения полностью работоспособны, и лишь затем выполните восстановление размещения. В противном случае могут возникнуть ситуации, в которых приложение будет переходить между центрами обработки данных. Дополнительные сведения см. в статье Запуск виртуальных машин Windows в нескольких регионах для обеспечения высокой доступности.

Создайте конечную точку проверки работоспособности. Создайте пользовательскую конечную точку, которая сообщает об общей работоспособности приложения. Это позволяет диспетчеру трафика выполнить отработку отказа при сбое любого критического пути, а не только внешнего интерфейса. Конечная точка должна возвращать код ошибки HTTP, если какая-либо критическая зависимость неработоспособна или недоступна. Однако не сообщайте об ошибках некритических служб. В противном случае проверка работоспособности может вызвать ненужную отработку отказа, создавая ложные срабатывания. Дополнительные сведения см. в статье Мониторинг конечных точек в диспетчере трафика.

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

Не выполняйте рабочую нагрузку на одной виртуальной машине. Одно развертывание виртуальной машины неустойчиво при плановом или внеплановом обслуживании. Вместо этого поместите несколько виртуальных машин в группу доступности или масштабируемый набор виртуальных машин перед подсистемой балансировки нагрузки.

Укажите группу доступности при подготовке виртуальной машины. В настоящее время после подготовки виртуальную машину невозможно добавить в группу доступности. Добавляя новую виртуальную машину в имеющуюся группу доступности, обязательно создайте сетевую карту для виртуальной машины и добавьте ее в серверный пул адресов в подсистеме балансировки нагрузки. В противном случае подсистема балансировки нагрузки не будет маршрутизировать сетевой трафик на эту виртуальную машину.

Поместите каждый уровень приложения в отдельных группах доступности. В n-уровневом приложении не следует размещать виртуальные машины из разных уровней в одной группе доступности. Виртуальные машины в группе доступности располагаются в доменах сбоя и доменах обновления. Тем не менее, чтобы получить преимущества избыточности этих доменов, каждая виртуальная машина в группе доступности должна иметь возможность обрабатывать одни и те же клиентские запросы.

Репликация виртуальных машин с помощью Site Recovery. При репликации виртуальных машин Azure с помощью Site Recovery все диски виртуальных машин непрерывно и асинхронно реплицируются в целевой регион. Точки восстановления создаются каждые несколько минут. Это обеспечивает требуемую целевую точку восстановления (RPO) в минутах. Можно выполнять аварийное восстановление столько раз, сколько требуется. Это не повлияет на рабочее приложение или текущую репликацию. См. дополнительные сведения об отработке аварийного восстановления в Azure.

Выберите подходящий размер виртуальной машины в соответствии с требованиями к производительности. При перемещении имеющейся рабочей нагрузки в Azure выберите начальный размер виртуальной машины, который больше всего соответствует вашим локальным серверам. Затем измерьте производительность фактической рабочей нагрузки по таким ресурсам, как потребление ЦП, памяти и дисковых операций ввода-вывода в секунду, и при необходимости измените размер виртуальной машины. Это гарантирует, что приложение будет правильно работать в облачной среде. Кроме того, если требуется использовать несколько сетевых карт, то учтите ограничения на количество сетевых карт для каждого размера.

Используйте управляемые диски в качестве виртуальных жестких дисков.Служба Управляемые диски обеспечивает более высокую надежность виртуальных машин в группах доступности, так как диски достаточно изолированы друг от друга, что позволяет избежать единой точки отказа. Кроме того, управляемые диски не подпадают под ограничения операций ввода-вывода в секунду для виртуальных жестких дисков (VHD), созданных в учетной записи хранения. Дополнительные сведения см. в статье Управление доступностью виртуальных машин Windows в Azure.

Устанавливайте приложения на диск данных, а не на диск операционной системы. В противном случае можно превысить предельный размер диска.

Используйте службу Azure Backup для архивации виртуальных машин. Резервные копии позволяют обеспечить защиту от случайной потери данных. Дополнительные сведения см. в статье Защита виртуальных машин Azure в хранилище служб восстановления.

Включение ведения журналов диагностики. Включите основные метрики работоспособности, журналы инфраструктуры и диагностику загрузки. Если виртуальную машину невозможно загрузить, для обнаружения неисправностей можно использовать диагностику загрузки. Дополнительные сведения см. в обзоре журналов диагностики Azure.

Настройте Azure Monitor. Собирайте и анализируйте данные мониторинга виртуальных машин Azure, включая гостевую операционную систему и рабочие нагрузки, которые выполняются в ней. См. страницу Azure Monitor и краткое руководство по Azure Monitor.

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

Чтобы разрешать или блокировать общедоступные IP-адреса, добавьте в подсеть группу безопасности сети. Блокируйте доступ злоумышленников или разрешите доступ только для пользователей с привилегиями для доступа к приложению.

Создайте пользовательскую проверку работоспособности. При проверке работоспособности Load Balancer может тестироваться HTTP или TCP. Если виртуальная машина работает на HTTP-сервере, проверка HTTP поможет лучше определить состояние работоспособности, чем проверка TCP. Для проверки HTTP используйте настраиваемую конечную точку, которая сообщает об общей работоспособности приложения, включая все критические зависимости. Дополнительные сведения см. в разделе Обзор Azure Load Balancer.

Не блокируйте проверку работоспособности. Проверка работоспособности Load Balancer отправляется с известного IP-адреса — 168.63.129.16. Не блокируйте входящий и исходящий трафик для этого IP-адреса в политиках брандмауэра или правилах группы безопасности сети. При блокировании проверки работоспособности подсистема балансировки нагрузки удаляет виртуальную машину из ротации.

Включите ведение журнала для Load Balancer. В журналах показано, сколько виртуальных машин на серверной стороне не получают сетевой трафик из-за неудачных ответов проверки. Дополнительные сведения см. в статье Служба анализа журналов для Azure Load Balancer.