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

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

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

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

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

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

Чтобы узнать, как развернуть Azure NetApp Files для обеспечения устойчивости вашего решения и как надежность влияет на другие аспекты вашей архитектуры, см. в разделе Лучшие практики архитектуры для Azure NetApp Files в #REF! Well-Architected Framework.

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

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

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

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

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

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

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

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

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

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

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

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

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

Azure NetApp Files поддерживает зональные развертывания томов. Используйте функцию размещения томов в зонах доступности в Azure NetApp Files для развертывания каждого тома в одной зоне доступности по вашему выбору. Эту функцию можно использовать только в том случае, если Azure NetApp Files присутствует в этой зоне доступности и имеет достаточную емкость. Если у вас есть приложения, чувствительные к задержке, вы можете развернуть том в той же зоне доступности, что и ваши вычислительные ресурсы #REF! и ваши другие службы.

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

Диаграмма, показывающая размещение томов в зоне доступности Azure NetApp Files.

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

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

Требования

  • Region support: кросс-зонная репликация доступна во всех регионах, включающих зоны доступности, поддерживающих Azure NetApp Files.

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

  • Репликация разрешена между различными подписками #REF! только в том случае, если они находится в одном клиенте #REF!.

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

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

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

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

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

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

  • Размещение тома:

    • Создайте новый том или настройте существующий том с поддержкой зоны доступности. Сведения о настройке зон доступности для томов в Azure NetApp Files см. в разделе Управляемая зона доступности для размещения томов Azure NetApp Files.

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

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

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

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

  • Репликация между зонами:

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

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

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

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

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

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

    Это важно

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

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

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

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

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

  • Notification: Чтобы отслеживать работоспособность тома 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 (целевой) в другом регионе, который корпорация Майкрософт предварительно выбирает. Эта возможность позволяет переключиться на резерв критического приложения в случае регионального сбоя или катастрофы.

Замечание

Вы также можете реплицировать один том в другую зону доступности и в другой регион. Для получения дополнительной информации см. Understand Azure NetApp Files replication.

Требования

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

Соображения

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

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

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

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

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

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

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

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

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

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

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

    Это важно

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

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

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

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

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

  • Notification: Чтобы отслеживать работоспособность тома 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, предоставляя полностью управляемое решение резервного копирования для долгосрочного восстановления, архива и соответствия требованиям. Резервные копии, создаваемые службой, хранятся в хранилище #REF! независимо от моментальных снимков томов, доступных для краткосрочного восстановления или клонирования. Резервные копии, которые принимает служба, можно восстановить в новых томах Azure NetApp Files в регионе. Azure NetApp Files поддерживает резервное копирование как по расписанию на основе политик, так и вручную по запросу.

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

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

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

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

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

  • Last updated on