Поделиться через

Надежность в Azure NetApp Files

В этой статье описывается поддержка надежности в Azure NetApp Files, охватывающая устойчивость внутри региона через зоны доступности и развертывания в нескольких регионах.

Надежность — это общая ответственность между вами и корпорацией Майкрософт. Это руководство позволяет определить, какие варианты надежности соответствуют конкретным бизнес-целям и целям простоя.

Azure NetApp Files — это собственное решение для хранения файлов корпоративного уровня, которое легко интегрировано в Azure, что обеспечивает общий доступ к файлам между клиентами через протоколы SMB и NFS. Предназначен для обеспечения высокой производительности Azure NetApp Files предлагает масштабируемое и безопасное хранилище файлов, управляемое как услуга.

Чтобы использовать Azure NetApp Files, необходимо настроить учетную запись NetApp, содержащую пулы емкости , которые в свою очередь размещают тома. Вы можете самостоятельно настроить емкость и пропускную способность и управлять параметрами защиты данных, адаптированными к различным потребностям. Вы можете включить репликацию между томами, даже если они расположены в разных расположениях.

Рекомендации по развертыванию в производственной среде

Сведения о развертывании Azure NetApp Files для поддержки требований к надежности решения и о том, как надежность влияет на другие аспекты архитектуры, см. в статье "Рекомендации по архитектуре Azure NetApp Files" в Azure Well-Architected Framework.

Временные сбои

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

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

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

С точки зрения протокола файлов (например, NFS и SMB) временные ошибки не нарушаются, если приложение может обрабатывать приостановки ввода-вывода, которые могут кратко произойти во время этих событий. Паузы ввода-вывода обычно короткие, начиная от нескольких секунд до 30 секунд. Для некоторых приложений может потребоваться настройка для обработки приостановки ввода-вывода.

Протокол NFS особенно надежный, а файловые операции клиента-сервера обычно продолжаются нормально. Для некоторых приложений может потребоваться настройка для обработки приостановки ввода-вывода до 30–45 секунд. Убедитесь, что вы знаете параметры устойчивости приложения, чтобы справиться с событиями обслуживания службы хранилища.

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

Непрерывная доступность SMB доступна только для определенных приложений.

Дополнительные рекомендации см. в часто задаваемых вопросы об устойчивости приложений Azure NetApp Files.

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

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

Azure NetApp Files поддерживает зональные развертывания томов. Функция размещения томов в зоне доступности Azure NetApp Files позволяет развертывать каждый том в отдельной зоне доступности, если Azure NetApp Files присутствует в этой зоне доступности и имеет достаточную емкость. Если у вас есть приложения с учетом задержки, вы можете развернуть том в той же зоне доступности, что и вычислительные ресурсы Azure и другие службы в той же зоне.

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

Схема размещения томов в зоне доступности NetApp Files.

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

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

Поддержка регионов

Репликация между зонами доступна во всех регионах с поддержкой зоны доступности с присутствием Azure NetApp Files.

Соображения

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

  • Репликация разрешена между различными подписками Azure, если они находятся в одном клиенте Microsoft Entra.

  • Другие вопросы, связанные с зонами доступности в Azure NetApp Files, см. в статье "Требования и рекомендации по использованию репликации между зонами " и "Управление размещением томов зоны доступности".

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

Дополнительная плата не взимается, чтобы включить размещение томов в зоне доступности в Azure NetApp Files. Вы оплачиваете только пулы емкости и ресурсы, которые развертываются в этих зонах.

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

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

Необходимо отдельно настроить размещение томов и репликацию между зонами.

Нормальная работа

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

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

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

    Это важно

    Расписание репликации на 10 минут не поддерживается для больших томов с помощью репликации между зонами.

Опыт понижения зоны

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

  • Обнаружение и ответ: Вы несете ответственность за обнаружение потери зоны доступности и инициирование отработки отказа.

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

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

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

  • Ожидаемая потеря данных: Объем потери данных (также называемый целевой точкой восстановления или RPO), который можно ожидать во время отработки отказа зоны, зависит от настроенного расписания репликации между зонами.

    Расписание репликации Типичный RPO
    Каждые 10 минут 20 минут.
    Ежечасный Два часа
    Ежедневно Менее 48 часов

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

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

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

Возврат к исходному состоянию

Восстановление размещения — это ручной процесс, требующий выполнения операции повторной синхронизации, повторного развертывания репликации и повторного подключения исходного тома для доступа клиента. Дополнительные сведения см. в статье "Управление аварийным восстановлением с помощью Azure NetApp Files".

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

Вы можете безопасно протестировать конфигурацию репликации между зонами с помощью моментальных снимков тома. Сведения о высокоуровневом подходе к тестированию конфигурации репликации между зонами см. в статье "Тестирование аварийного восстановления для Azure NetApp Files".

Поддержка нескольких регионов

По умолчанию Azure NetApp Files — это служба с одним регионом. Если регион становится недоступным, тома, хранящиеся в этом регионе, также недоступны. Чтобы повысить устойчивость в случае регионального сбоя, Azure NetApp Files поддерживает репликацию между регионами. Вы можете асинхронно реплицировать данные из тома Azure NetApp Files (источника) в одном регионе в другой том Azure NetApp Files (назначение) в другом регионе, предварительно выбранном корпорацией Майкрософт. Эта возможность позволяет переключиться на резерв критического приложения в случае регионального сбоя или катастрофы.

Замечание

Вы также можете реплицировать один том в другую зону доступности и в другой регион. Дополнительные сведения см. в статье "Общие сведения о репликации между зонами" в Azure NetApp Files.

Поддержка регионов

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

Соображения

Репликация разрешена между различными подписками Azure, если они находятся в одном клиенте Microsoft Entra.

Другие рекомендации, связанные с репликацией между регионами в Azure NetApp Files, см. в статье "Требования и рекомендации по использованию репликации между регионами".

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

Репликация между регионами взимается на основе объема реплицируемых данных. Дополнительные сведения и некоторые примеры сценариев см. в статье "Модель затрат" для репликации между регионами.

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

Нормальная работа

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

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

  • Репликация данных между регионами: Репликация Azure NetApp Files между регионами означает, что все изменения исходного тома асинхронно реплицируются в тома назначения. Вы можете решить, насколько часто должна выполняться репликация. Репликация между регионами поддерживает три расписания репликации: 10 минут, почасовой и ежедневной.

    Это важно

    Расписание репликации в 10 минут не поддерживается для больших томов с помощью репликации между регионами.

  • Мониторинг работоспособности репликации: Вы можете отслеживать работоспособность связи пиринга и настроить оповещения, чтобы уведомить вас о том, что задержка репликации увеличивается за пределы ожидаемого порогового значения. Дополнительные сведения см. в разделе "Отображение работоспособности и мониторинг состояния связи репликации".

Опыт региональной недоступности

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

  • Обнаружение и ответ: Вы несете ответственность за обнаружение потери региона и инициирование отработки отказа.

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

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

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

  • Ожидаемая потеря данных: Объем потери данных (также называемый целевой точкой восстановления или RPO), который можно ожидать во время отработки отказа региона, зависит от настроенного расписания репликации между регионами.

    Расписание репликации Типичный RPO
    Каждые 10 минут Менее 20 минут
    Ежечасный Менее двух часов
    Ежедневно Менее 48 часов

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

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

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

Возврат к исходному состоянию

Восстановление размещения — это ручной процесс, требующий выполнения операции повторной синхронизации, повторного развертывания репликации и повторного подключения исходного тома для доступа клиента. Дополнительные сведения см. в статье "Управление аварийным восстановлением с помощью Azure NetApp Files".

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

Вы можете безопасно протестировать конфигурацию репликации между регионами с помощью моментальных снимков тома. Сведения о высокоуровневом подходе к тестированию конфигурации репликации между регионами см. в статье "Тестирование аварийного восстановления для Azure NetApp Files".

Резервные копии

Резервное копирование Azure NetApp Files расширяет возможности защиты данных Azure NetApp Files, предоставляя полностью управляемое решение для резервного копирования для долгосрочного восстановления, архива и соответствия требованиям. Резервные копии, создаваемые службой, хранятся в хранилище Azure, независимо от снимков тома, доступных для краткосрочного восстановления или клонирования. Резервные копии, сделанные службой, можно восстановить в новых томах Azure NetApp Files в регионе. Резервное копирование Azure NetApp Files поддерживает резервные копии на основе политик и резервные копии вручную (по запросу).

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

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

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

Соглашение об уровне обслуживания (SLA) для Azure NetApp Files описывает ожидаемую доступность службы и условия, которые должны быть выполнены для достижения этого ожидания доступности. Дополнительные сведения см. в соглашениях об уровне обслуживания (SLA) для веб-служб.

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