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

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

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

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

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

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

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

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

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

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

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

Все облачные приложения должны следовать рекомендациям по обработке временных ошибок 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 в той же зоне, используют домен сбоя зоны доступности. Репликация между различными томами на уровне платформы отсутствует.

Диаграмма, показывающая размещение томов в зоне доступности Azure 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. Azure Monitor обнаруживает аномалии, которые указывают на сценарий уменьшения зоны с помощью метрик реального времени, таких как операции ввода-вывода в секунду (IOPS), задержка и использование емкости. Вы можете настроить оповещения и уведомления для отправки администраторам, чтобы они могли немедленно реагировать, перебалансировав общие папки или инициируя отработку отказа или другие протоколы аварийного восстановления.

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

  • Ожидаемая потеря данных: Объем потери данных или целевой точки восстановления (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. 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 описывает ожидаемую доступность каждой службы и условия, которые должно соответствовать вашему решению для достижения этого ожидания доступности. Для получения дополнительной информации см. Соглашения об уровне обслуживания для онлайн-сервисов.

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

  • Last updated on