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


Часто задаваемые вопросы об устойчивости приложений для Azure NetApp Files

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

Что рекомендуется для обработки потенциальных сбоев приложений из-за событий обслуживания службы хранилища?

Azure NetApp Files может проходить периодическое плановое обслуживание (например, обновления платформы, службы или обновления программного обеспечения). С точки зрения протокола файлов (NFS/S МБ) операции обслуживания неразрывны, если приложение может обрабатывать приостановки операций ввода-вывода, которые могут произойти кратко во время этих событий. Паузы ввода-вывода обычно короткие, начиная от нескольких секунд до 30 секунд. Протокол NFS особенно надежный, а файловые операции клиента-сервера продолжаются нормально. Для некоторых приложений может потребоваться настройка для обработки приостановки операций ввода-вывода до 30–45 секунд. Таким образом, убедитесь, что вы знаете параметры устойчивости приложения, чтобы справиться с событиями обслуживания службы хранилища. Для интерактивных приложений, использующих протокол S МБ, обычно достаточно стандартных параметров протокола.

Важно!

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

Необходимо ли принять специальные меры предосторожности для приложений на основе S МБ?

Да, для некоторых приложений на основе S МБ требуется S МБ прозрачной отработки отказа. Прозрачная отработка отказа SMB позволяет выполнять операции обслуживания в службе Azure NetApp Files, не прерывая подключения к серверным приложениям, которые хранят данные в томах SMB и имеют доступ к ним. Для поддержки S МБ прозрачной отработки отказа для определенных приложений Azure NetApp Files теперь поддерживает параметр S МБ непрерывной доступности. Использование S МБ непрерывной доступности поддерживается только для рабочих нагрузок:

Внимание

Пользовательские приложения не поддерживаются в S МБ непрерывной доступности и не могут использоваться с томами с поддержкой непрерывной доступности S МБ.

Я запускаю IBM MQ в Azure NetApp Files. Какие меры предосторожности можно предпринять, чтобы избежать сбоев из-за событий обслуживания службы хранилища, несмотря на использование протокола NFS?

Если вы используете приложение IBM MQ в конфигурации общих файлов, где данные и журналы IBM MQ хранятся в томе Azure NetApp Files, рекомендуется повысить устойчивость во время событий обслуживания службы хранилища:

  • Необходимо использовать только протокол NFS версии 4.1.
  • Для обеспечения высокой доступности следует использовать конфигурацию IBM MQ с несколькими экземплярами с использованием общих томов NFS версии 4.1.
  • Необходимо проверить функциональные возможности конфигурации IBM с несколькими экземплярами с помощью общих томов NFS версии 4.1.
  • Следует реализовать масштабируемую архитектуру IBM MQ вместо использования одной конфигурации IBM MQ большого нескольких экземпляров. Распространяя нагрузку на обработку сообщений между несколькими парами много экземпляров IBM MQ, вероятность прерывания работы службы может быть уменьшена, так как каждая пара много экземпляров MQ будет обрабатывать меньше сообщений.

Примечание.

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

Архитектура горизонтального масштабирования будет состоять из нескольких пар IBM MQ с несколькими экземплярами, развернутыми за azure Load Balancer. Затем приложения, настроенные для взаимодействия с IBM MQ, будут настроены для взаимодействия с экземплярами IBM MQ через Azure Load Balancer. Для поддержки, связанной с IBM MQ на общих томах NFS, необходимо получить поддержку поставщиков в IBM.

Я выполняю Apache ActiveMQ с LevelDB или KahaDB в Azure NetApp Files. Какие меры предосторожности можно предпринять, чтобы избежать сбоев из-за событий обслуживания службы хранилища, несмотря на использование протокола NFS ?

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

Модели высокой доступности ActiveMQ гарантируют, что экземпляр брокера всегда находится в сети и может обрабатывать трафик сообщений. Две наиболее распространенные модели высокой доступности ActiveMQ включают совместное использование файловой системы по сети. Цель — предоставить levelDB или KahaDB экземплярам активных и пассивных брокеров. Эти модели высокого уровня доступности требуют, чтобы блокировка уровня ОС была получена и сохранена в файле в каталогах LevelDB или KahaDB, называемых блокировкой. Существуют некоторые проблемы с этой моделью высокого уровня доступности ActiveMQ. Они могут привести к ситуации без главного доступа, когда реплика не знает, что он может заблокировать файл. Они также могут привести к конфигурации master-master, которая приводит к повреждению индекса или журнала и в конечном итоге потере сообщений. Большинство этих проблем возникают из-за факторов, не связанных с контролем ActiveMQ. Например, плохо оптимизированный клиент NFS может привести к тому, что блокировка данных становится устаревшей при загрузке, что приводит к простою no-master во время отработки отказа.

Так как большинство проблем с этим решением высокой доступности связаны с неточной блокировкой файлов на уровне ОС, сообщество ActiveMQ представило концепцию подключаемого хранилища locker в версии 5.7 брокера. Такой подход позволяет пользователю воспользоваться разными средствами общей блокировки, используя блокировку базы данных JDBC на уровне строк, а не блокировку файловой системы на уровне ОС. Для поддержки или консультаций по архитектуре и развертываниям ActiveMQ вы должны обратиться в OpenLogic by Perforce.

Я выполняю Apache ActiveMQ с LevelDB или KahaDB в Azure NetApp Files. Какие меры предосторожности можно предпринять, чтобы избежать сбоев из-за событий обслуживания службы хранилища, несмотря на использование протокола S МБ?

Общая индустрия рекомендация заключается в том, чтобы не запускать общее хранилище KahaDB в CIFS/S МБ. Если у вас возникли проблемы с точным состоянием блокировки, проверка из подключаемого модуля JDBC служба хранилища Locker, который может обеспечить более надежный механизм блокировки. Для поддержки или консультаций по архитектуре и развертываниям ActiveMQ вы должны обратиться в OpenLogic by Perforce.

Я выполняю Boomi в Azure NetApp Files. Какие меры предосторожности можно предпринять, чтобы избежать сбоев из-за событий обслуживания службы хранилища?

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

Boomi рекомендует Буми Молекула используется для реализации высокой доступности для Boomi Atom. Требования к системе буми молекулы, которые можно использовать либо NFS с поддержкой блокировки NFS (поддержка NLM), либо S МБ файловых ресурсов. В контексте Azure NetApp Files тома NFSv4.1 поддерживают NLM.

Boomi рекомендует использовать общую папку S МБ с виртуальными машинами Windows; для NFS Boomi рекомендует виртуальные машины Linux.

Примечание.

Общие папки непрерывной доступности Azure NetApp Files не поддерживаются в Boomi.

Следующие шаги