Отказоустойчивость

Каждая ИТ-система служит определенной цели. Чтобы выполнить эту задачу, она должен быть доступна для использования. Некоторые ИТ-системы критически важны для бизнеса и, следовательно, должны быть отказоустойчивыми, без или с минимальными периодами времени, когда они могут быть частично или полностью недоступны. Другие системы менее важны, и определенное количество запланированных или внеплановых простоев для них приемлемо, например, если пользователи могут вернуться к альтернативным рабочим процессам или просто подождать, пока система снова станет доступной. Многие системы находятся где-то посередине между этими двумя крайностями.

Определение и анализ доступности

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

Примечание:

Высокая доступность, хотя и связана с аварийным восстановлением (DR), является отдельным понятием. Как правило, высокая доступность ориентирован на предотвращение незапланированных простоев для предоставления сервисов, в то время как аварийное восстановление сосредоточено на сохранении данных и ресурсов, необходимых для восстановления системы до предыдущего приемлемого состояния после аварии. При реализации планов аварийного восстановления предоставление сервисов обычно прерывается до тех пор, пока система не будет восстановлена. Дополнительные сведения см. в разделе Резервное копирование и аварийное восстановление .

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

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

  • Активный-активный, который представляет собой шаблон отказоустойчивости, основанный на двух или более системах, активно принимающих и обрабатывающих запросы. В системе «активный-активный» каждый узел, получающий запрос, равен другим, и запросы обычно распределяются по нагрузке таким образом, что они отправляются примерно в равной пропорции каждому внутреннему узлу.
  • Активный-пассивный, также называемый первичным/резервным, представляет собой шаблон отказоустойчивости, при котором запросы пользователей полностью поступают в одну систему, а вторая система ожидает сценария, когда она понадобится, либо из-за сбоя основной системы (когда активная система прекращает обработку запросов), либо через запланированное переключение, что приводит к отправке пользовательского трафика в пассивную систему, которая теперь считается активной системой.
  • Отказоустойчивые системы спроектированы таким образом, чтобы поддерживать полную синхронизацию с активной системой, но готовы принимать трафик только в том случае, если основная система по какой-либо причине вышла из строя. Система отказоустойчивости похожа на конфигурацию “активный-пассивный”, но может иметь другие рабочие процессы, связанные с “отработкой отказа” в этой системе.

Целевые показатели доступности

Одним из показателей, с помощью которого можно измерить доступность, является время безотказной работы, которое обычно измеряется как процент времени, за которое система была «доступна» в течение определенного периода. Определение «доступного» является субъективным и должно быть задано на ранних этапах процесса проектирования системы, чтобы можно было достичь общего соглашения по этой цели. Желаемый уровень доступности часто определяется как целевое время безотказной работы, часто выражаемое в девятках. Например:

  • 99% (две девятки) - эквивалентно 3,65 дням допустимого простоя в году
  • 99,9% (три девятки) - эквивалентно 8,77 часам допустимого времени простоя в год

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

Уровни критичности

Еще один подход, который используют организации в отношении доступности, заключается в установлении уровней критичности для обслуживаемых ими систем, от несущественных до базовых, в зависимости от влияния, которое сбой может оказать на организацию. Рекомендации могут касаться взаимодействия с пользователем, финансовых, репутационных и нормативных последствий, а также каждый уровень критичности может иметь свое целевое определение SLA. Некоторые организации могут называть определенную систему «Tier 1» или «Business Critical», в то время как другие системы относятся к «Tier 2» или менее критичны для бизнеса и, таким образом, имеют меньше ограничений или различных конфигураций.

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

  • Тщательный выбор высококачественных программных и аппаратных компонентов, специально разработанных для сокращения среднего времени между отказами (MTBF), в отличие от использования стандартных компонентов.
  • Устранение любой отдельной точки (точек) отказа в системе за счет обеспечения избыточных измерений всех компонентов. Единая точка отказа — это часть программного или аппаратного обеспечения, которая в случае сбоя приводит к недоступности всей системы. Благодаря единой точке отказа система может выдержать сбой любого компонента без заметного влияния на доступность.
  • Разработка планов по восстановлению системы в случае, если она действительно станет недоступной, и тестирование этих планов. Это может включать определение целевых показателей для приемлемого количества времени, необходимого для восстановления доступности системы, и допустимой потери данных.
  • Применение политик и процедур с акцентом на управление изменениями для минимизации вероятности случайных или непреднамеренных сбоев, например, из-за человеческой ошибки.

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

Рекомендации по проектированию

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

Часто проектные ограничения делятся на следующие категории:

  • Потребности бизнеса: бизнес-требования организации определяют, какой объем простоя является приемлемым, начиная от нулевого времени простоя и заканчивая часами или днями простоя до восстановления системы. Это называется допустимым временем восстановления (RTO). Бизнес-требования также указывают, какую потерю данных, выраженную во времени, можно допустить в случае сбоя. Это называется целевой точкой восстановления (RPO), показатель обычно находится в диапазоне от нуля секунд до потери данных за неделю.
  • Схема развертывания: выбор конкретной схемы развертывания часто заранее определяет, в какой степени соображения доступности должны учитываться при принятии подробных решений по проектированию. Другими словами, при построении системы на основе предложений SaaS или PaaS многие из этих решений уже приняты организацией, которая размещает предложение. С другой стороны, развертывание программного обеспечения ГИС-сервера в центре обработки данных, которым владеет и управляет ваша организация, обеспечивает высочайший уровень гибкости в отношении точного удовлетворения ваших требований к доступности, но также сопряжено с наибольшей ответственностью.
  • Инфраструктура: в большинстве случаев ИТ-специалистам, которые проектируют и создают ГИС-системы для развертывания в центрах обработки данных, которыми управляет ваша организация, не нужно беспокоиться о базовой физической инфраструктуре, такой как хостинг, электропитание, охлаждение и сеть, потому что они уже созданы и обычно обеспечивают высокий уровень доступности этих основных факторов.
  • Техническое обслуживание: для некоторых систем критически важна возможность установки исправлений или обновлений систем без простоев, чтобы гарантировать, что они не повлияют на пользователей, а другие системы смогут работать непрерывно. В этих случаях установка исправлений на “скользящей” основе или с использованием сине-зеленой или основной/резервной среды может соответствовать этим целям, но потенциальное влияние желаемых действий по обслуживанию и частота обслуживания необходимо учитывать при проектировании любой системы.

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

Использование коммерческой облачной инфраструктуры как услуги (IaaS), будь то виртуальные машины или кластеры Kubernetes, также ограничивает ваши возможности.

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

Отказоустойчивые схемы

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

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

Portal for ArcGIS

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

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

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

Узнайте больше о настройке развертывания с высокой доступностью Portal for ArcGIS.

ГИС-сервер

Высокодоступный сайт ГИС-сервера состоит из двух или более полностью избыточных компьютеров, которые объединены в “сайт” ArcGIS Server, где рабочие нагрузки распределяются по всем узлам, что является конфигурацией “активный-активный “. Высокодоступный ГИС-сервер также требует подсистемы балансировки нагрузки для маршрутизации запросов к компьютерам-участникам, обычно с циклическим подходом, хотя веб-трафик также может быть маршрутизирован первичным-резервным способом.

Состояние компьютеров в общем доступе к сайту определяется в основном через общее хранилище для каталогов сервера и хранилища конфигурации, обычно это общий файловый ресурс типа NFS или UNC. Для облачных систем также доступны облачные варианты, такие как хранилище DynamoDB и S3 в AWS или хранилище Azure Files в Microsoft Azure.

Примечание:

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

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

Web Adaptor

Web Adaptor может быть развернут с избыточностью на двух или более машинах, при этом каждый экземпляр будет полностью зарезервирован в конфигурации «активный-активный». Для этой конфигурации требуется интерфейсная подсистема балансировки нагрузки, на которую клиенты отправляют запросы, которая распределяет запросы между обоими узлами веб-адаптеров. Дополнительные ресурсы доступны в документации.

ArcGIS Data Store

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

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

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

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

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

Реляционные базы данных

Доступность ресурсов базы данных — это специализированная область архитектуры с множеством специфичных для поставщика опций для каждого отдельного предложения базы данных, включая схемы «активный-активный» и «активный-пассивный». Как правило, ArcGIS может подключаться к этим конфигурациям, когда в процессе регистрации данных, с помощью которого осуществляется доступ к сервисам или они публикуются, используется псевдоним DNS или гибкий IP-адрес, доступ к которому всегда осуществляется из ArcGIS, но который может указывать на другую серверную базу данных в случае сбоя в работе основной системы. В этом сценарии компоненты ArcGIS не знают об изменениях в серверной базе данных и продолжают работать как ожидается, предполагая, что доступны те же учетные данные, схема и строки.

Рекомендации по проектированию

Чтобы сделать обоснованный и эффективный выбор, связанный с высокой доступностью, рассмотрите следующие рекомендации по проектированию:

  • Резервные копии: создание резервных копий развертывания ArcGIS – это самый простой способ избежать потери данных и сократить время простоя. Это позволяет восстановить элементы, которые существовали на момент создания резервной копии, и значительно сокращает время на операцию.
  • Управление системами только для чтения и чтения/записи: если приложение или система являются системой только для чтения, в которой пользователи в основном просматривают данные, управляемые в другом месте, достижение отказоустойчивой конфигурации упрощается, так как можно использовать конфигурацию «активный-активный». Если правки создаются пользователями, то в системе чтения/записи обычно существует сочетание уровней «активный-активный» и «активный-пассивный», что позволяет поддерживать первичную, активную базу данных записей, которая также поддерживает пассивную, резервную или отказоустойчивую систему, чтобы быть готовой к приему трафика в случае сбоя.
  • Дублирование и избыточность: реализуйте несколько экземпляров определенных компонентов системы, потенциально включая географическую избыточность, чтобы уменьшить количество единых точек отказа. Подумайте о навыках, необходимых для обслуживания системы. Учтите, что человек с такой же легкостью может быть единственной точкой отказа.
  • Планы тестирования и мониторинг системы: оцените способность системы соответствовать требуемому уровню обслуживания путем тестирования нагрузок, производительности и функций аварийного переключения. Все планы тестирования и связанные с ними действия должны быть частью общего управления системой. Непрерывный мониторинг системы для устранения проблем до того, как они приведут к широкомасштабному или неустранимому сбою.
  • К другим рекомендациям по обеспечению высокой доступности относятся автоматизация, совместная работа, балансировка нагрузки, и разделение рабочих нагрузок.
Top