Надежность в Реестр контейнеров Azure

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

При использовании #REF! надежность является совместной ответственностью. Корпорация Майкрософт предоставляет ряд возможностей для поддержки устойчивости и восстановления. Вы несете ответственность за понимание того, как работают эти возможности во всех используемых вами службах, а также за выбор возможностей, необходимых для достижения бизнес-целей и целей бесперебойной работы.

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

Рекомендации по развертыванию в рабочей среде для обеспечения надежности

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

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

• Подготовьте реестр контейнеров в регионе, поддерживающем зоны доступности.

• Для сценариев с несколькими регионами настройте георепликацию для распространения реестра в нескольких регионах на основе конкретных географических требований и требований к соответствию.

Обзор архитектуры надежности

Реестр контейнеров основан на распределенной инфраструктуре #REF! для обеспечения высокой доступности и устойчивости данных. Служба состоит из нескольких ключевых компонентов, которые работают вместе для обеспечения надежности. На следующей схеме показана архитектура основной службы.

Схема, демонстрирующая архитектуру службы реестра контейнеров с клиентским доступом, уровнем управления, плоскости данных и компонентами уровня хранилища.

• Плоскость управления — это централизованный компонент управления в домашнем регионе для конфигурации реестра, конфигурации проверки подлинности и политик репликации.

• План данных — это распределенная служба, которая обрабатывает операции отправки и загрузки образа контейнера в регионах и зонах доступности.

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

Корпорация Майкрософт отвечает за управление базовой инфраструктурой реестра контейнеров, которая включает следующие типы обслуживания:

• Обслуживание плоскости управления для управления реестром

• Обслуживание плоскости передачи данных для операций с образами контейнеров в регионах и зонах доступности

В качестве клиента вы несете ответственность за следующие действия:

• Устойчивость на уровне приложения: Реализуйте соответствующую логику повторных попыток и обработку отказов в контейнерных приложениях и платформах оркестрации.

• Конфигурация устойчивости зоны: Убедитесь, что реестр контейнеров развернут в регионе, поддерживающем зоны доступности.

• Конфигурация георепликации: Выберите подходящие регионы для георепликации на основе географического распределения, соответствия и требований к производительности.

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

Замечание

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

Устойчивость к временным сбоям

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

Все облачные приложения должны следовать #REF! рекомендации по обработке временных ошибок при обмене данными с любыми размещенными в облаке API, базами данных и другими компонентами. Дополнительные сведения см. в Рекомендациях по обработке временных сбоев.

Реестр контейнеров обрабатывает временные ошибки посредством нескольких механизмов. Служба реализует автоматическую логику повторных попыток для операций реестра и поддерживает пул подключений для эффективного использования ресурсов. Операции реестра контейнеров предназначены быть идемпотентными, что позволяет безопасно повторять операции push и pull. Задачи автоматически обрабатывают временные ошибки при выполнении многих типов операций.

Для клиентских приложений, использующих реестр контейнеров, реализуйте соответствующие политики повторных попыток с экспоненциальным обратным выходом при выполнении операций реестра. Используйте официальный клиент Docker или пакеты SDK реестра контейнеров, которые включают встроенные механизмы повторных попыток для распространенных временных сбоев.

Устойчивость к сбоям зоны доступности

Зоны Availability физически разделяют группы центров обработки данных в #REF! регионе. При сбое одной зоны службы могут переключиться на одну из оставшихся зон.

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

Избыточность зон включена по умолчанию для всех реестров в регионах, поддерживающих зоны доступности, что делает ресурсы более устойчивыми автоматически и без дополнительных затрат. Это улучшение применяется ко всем уровням служб, включая "Базовый" и "Стандартный", и применяется как к новым, так и к существующим реестрам.

Это важно

Портал #REF! и другие средства могут еще не точно отображать обновление отказоустойчивости зоны.

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

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

Соображения

• Поддержка региона: Реестры, избыточные для зон, можно развертывать в любом регионе, поддерживающем зоны доступности. Если ваш реестр находится в регионе, который не поддерживает зоны доступности, чтобы сделать его зонально-резервированным, необходимо создать новый реестр в регионе, поддерживающем зоны доступности. Затем необходимо перенести образы контейнеров, создав конвейер передачи или импортируя образы контейнеров.

Соображения

• Задачи: Задачи реестра контейнеров в настоящее время не поддерживают зоны доступности. Зональная избыточность применяется к самой службе реестра, но не к задачам или их операциям.

• Георепликация: Если в реестре используется георепликация, все реплики, созданные в регионах с зонами доступности, автоматически удаляются из зоны.

Себестоимость

Избыточность зоны включается в реестры контейнеров без дополнительных затрат.

Настройка поддержки зоны доступности

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

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

• Отключите избыточность в зоне. Избыточность зоны не может быть отключена.

Поведение, когда все зоны работоспособны

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

Схема, показывающая избыточность зоны реестра контейнеров во время обычных операций.

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

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

Поведение во время сбоя зоны

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

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

Схема, показывающая поведение реестра контейнеров при отказе зоны. Автоматический переход на доступные зоны. Одна зона помечается как недоступная.

• Обнаружение и ответ: Платформа реестра контейнеров автоматически обнаруживает сбои в зоне доступности и инициирует ответ. Служба автоматически направляет трафик в оставшиеся здоровые зоны. Нет необходимости в ручном вмешательстве для инициации переключения зоны.

• Уведомления: Корпорация Майкрософт не уведомляет вас об отключении зоны. Однако вы можете использовать Работоспособность служб Azure для понимания общего состояния службы, включая любые сбои зоны, и настроить оповещения Service Health для уведомления о проблемах.

  Вы также можете отслеживать метрики доступности реестра в Azure Monitor.

• Активные запросы: Когда зона доступности становится недоступной, любые выполняющиеся запросы, связанные с ресурсами в этой неисправной зоне доступности, прекращаются. Они должны быть пересмотрены.

• Ожидаемая потеря данных: Все последние записи, сделанные в неисправной зоне, могут не реплицироваться в другие регионы, что означает, что они могут быть потеряны до восстановления зоны. Как правило, потеря данных будет меньше 15 минут, но это не гарантируется.

• Ожидаемое время простоя: Небольшое время простоя может возникать во время автоматической процедуры отработки отказа, так как трафик перенаправляется в исправные зоны. Это время простоя обычно составляет несколько секунд для большинства операций реестра. Рекомендуем следовать лучшим практикам обработки временных ошибок, чтобы свести к минимуму влияние переключения на резервную зону в ваших приложениях.

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

Восстановление зоны

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

Тестирование на сбои в зоне

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

Устойчивость к сбоям на уровне региона

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

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

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

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

Георепликация реестра контейнеров не зависит от парных регионов #REF!. Вы можете выбрать любое сочетание регионов #REF! для репликации на основе ваших конкретных географических, производственных и требований к соответствию. Каждый геореплицированный реестр функционирует как конечная точка реестра. Он поддерживает большинство операций реестра, включая загрузку и выгрузку образов, а также задачи управления.

В этом разделе приведены сведения о георепликации, так как она связана с надежностью. Дополнительные сведения см. в разделе "Георепликация в реестре контейнеров".

Требования

• Region support: Георепликация доступна во всех #REF! регионах, где поддерживается уровень "Премиум". Вы можете реплицировать в любое сочетание регионов, независимо от того, спарены ли эти регионы в #REF!.
• Чтобы включить георепликацию, необходимо использовать уровень "Премиум".

Соображения

• Зонально-избыточные реплики: Любая реплика, созданная в регионе с зонами доступности, автоматически становится зонально-избыточной.

• Плоскость управления: Плоскость управления выполняется в домашнем регионе. Если домашний регион недоступен, операции плоскости управления недоступны, и вы не сможете изменить конфигурацию реестра.

• Задачи: Задачи реестра контейнеров в настоящее время не поддерживают геореплики. Задачи всегда выполняются в домашнем регионе. Если домашний регион недоступен, задача не выполняется.

Себестоимость

Каждый геореплицированный регион оплачивается отдельно в соответствии с ценами категории "Премиум" для соответствующего региона. Плата за исходящий трафик также применяется для передачи данных между регионами во время начальной репликации и текущей синхронизации.

Настройка поддержки нескольких регионов

Георепликация может быть настроена во время создания реестра или добавления в существующие реестры Premium. Георепликация можно настроить с помощью портала #REF!, шаблонов Azure CLI, Azure PowerShell или Azure Resource Manager.

• Создайте геореплицированный реестр. Настройте георепликацию после создания реестра, указав дополнительные регионы.

• Включите георепликацию в существующем реестре. Чтобы включить возможности георепликации, обновите существующие реестры уровня "Базовый" или "Стандартный" до уровня "Премиум". В любое время можно изменить регионы репликации. Дополнительные сведения см. в разделе "Настройка георепликации".

• Отключите георепликацию. Удалите отдельные региональные реплики с помощью портала #REF! или средств командной строки. Реестр домашних регионов не может быть удален.

Поведение, когда все регионы работоспособны

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

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

• Маршрутизация трафика между регионами: Реестр контейнеров работает в активной конфигурации, где каждая региональная конечная точка может обслуживать все операции плоскости данных независимо, включая операции чтения и записи. Операции уровня данных, такие как отправка и извлечение контейнеров, автоматически направляются с помощью диспетчера трафика с критериями, основанными на производительности, чтобы определить оптимальную региональную конечную точку.

• Репликация данных между регионами: Георепликация автоматически синхронизирует образы контейнеров и артефакты во всех настроенных регионах с помощью асинхронной репликации с конечной согласованностью. Служба использует доступное для содержимого хранилище, чтобы эффективно реплицировать только уникальные слои изображений. Этот подход сводит к минимуму использование пропускной способности и время репликации. Операции чтения и записи работают во всех геореплицированных регионах. Изменения, внесенные в любой регион, реплицируются во все остальные регионы.

  Репликация обычно завершается в течение нескольких минут изменений. Однако время репликации данных не гарантируется. Большие образы контейнеров или часто обновляемые данные могут дольше реплицироваться во всех регионах.

Поведение во время сбоя региона

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

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

Схема, показывющая поведение реестра контейнеров во время регионального сбоя.

• Обнаружение и ответ: Реестр контейнеров отслеживает работоспособность каждой региональной реплики и отвечает за перенаправление трафика в другой регион.

• Уведомления: Корпорация Майкрософт не уведомляет вас об отключении региона автоматически. Однако вы можете использовать Работоспособность служб Azure, чтобы понять общее состояние службы, включая сбои в любом регионе, и настроить оповещения Service Health для уведомления о проблемах.

  Вы также можете отслеживать метрики доступности реестра для каждой региональной конечной точки в Azure Monitor.

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

• Ожидаемая потеря данных: Любые последние записи, сделанные в неисправном регионе, могут не реплицироваться в другие регионы. Этот сбой означает, что они могут быть потеряны до тех пор, пока регион не восстановится. Как правило, потеря данных, как ожидается, будет меньше 15 минут, но это не гарантируется.

• Ожидаемое время простоя: Для операций плоскости данных ожидается небольшое время простоя во время переключения, что обычно занимает от 1 до 2 минут.

  Если основной регион недоступен, операции в контрольной плоскости недоступны, пока регион не восстановится.

• Перенаправка трафика: Когда регион становится недоступным, операции контейнера автоматически направляются в другую реплику в работоспособном регионе. Клиентам не нужно изменять конечную точку, в которой они взаимодействуют с реестром. Корпорация Майкрософт автоматически обрабатывает маршрутизацию, переключение на резервный режим и возврат к рабочему состоянию.

Восстановление региона

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

Проверка сбоев в регионе

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

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

Резервное копирование и восстановление

Реестр контейнеров поддерживает экспорт образов контейнеров и артефактов из реестра во внешнее хранилище или альтернативные реестры. Используйте возможности импорта и экспорта реестра контейнеров или стандартные команды Docker для создания копий критически важных образов контейнеров для сценариев аварийного восстановления.

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

Соглашение об уровне обслуживания

Соглашение об уровне обслуживания (SLA) для служб #REF! описывает ожидаемую доступность каждой службы и условия, которые должно соответствовать вашему решению для достижения этого ожидания доступности. Дополнительные сведения см. в разделе SLAs для онлайн-сервисов.

Связанный контент

• Надежность #REF!
• Уровни служб реестра контейнеров
• Рекомендации по реестру контейнеров
• Мониторинг реестра контейнеров
• Цены на реестр контейнеров
• Импорт образов контейнеров в реестр контейнеров