Ожидаемое поведение при возникновении сбоев
В этом разделе описаны действия, которые выполняются в кластерной конфигурации ThingWorx в процессе реагирования на сбой одного или нескольких компонентов.
Сбои балансировщика нагрузки
Действия и результаты зависят от развернутого решения высокой доступности балансировщика нагрузки. Активные сессии не должны прерываться, если балансировщик нагрузки имеет возможность предоставления общего доступа к содержимому сессии для всех узлов балансировщика нагрузки.
Сбой сервера HAProxy
При сбое одного или всех узлов HAProxy происходит следующее:
• Лидер ThingWorx будет все еще доступен через его IP-адрес, но не через IP-адрес HAProxy.
• Запросы, отправляемые в ThingWorx через HAProxy, не будут достигать ThingWorx.
При сбое одного из нескольких узлов HAProxy происходит следующее:
• Существующие сессии пользователя будут распознаны в ThingWorx Composer после того, как резервный HAProxy станет новым главным узлом. Пользователю не потребуется снова выполнять вход в систему.
• Мэшапы не будут загружены до тех пор, пока резервный HAProxy не станет главным.
• Обзор сущностей в Composer не будет загружен до тех пор, пока резервный HAProxy не станет главным.
• Запросы не будут достигать ThingWorx до тех пор, пока резервный HAProxy не станет главным.
Сбои сервера ThingWorx
При сбое сервера ThingWorx происходит следующее:
• Сервер исключается из балансировщика нагрузки, поскольку проверка работоспособности не пройдет. Время его исключения зависит от частоты проверок.
• ZooKeeper обнаруживает отказ сервера, исключает его из внутреннего обнаружения сервисов и уведомляет наблюдателей, таких как сервер соединений.
• Если сервер был одиночным сервером, ZooKeeper уведомляет другие серверы и выбирает новый одиночный сервер.
Клиенты, подключенные к серверу, могут получать ошибки, пока выполняется переключение, но затем переключаются к новому серверу.
Возможна потеря данных при сбое сервера или если сервер остановлен. В этих случаях данные в очередях пакетов будут потеряны. Если вместо сбоя сервера происходит его выключение, то причиной описанных выше событий является отмена регистрации сервера, а очереди пакетов очищаются.
Узлы ThingWorx Platform не работают
Пока хотя бы один экземпляр Platform находится в рабочем состоянии, другие узлы могут быть перезапущены без влияния на систему. Однако если все узлы Platform остановлены или неработоспособны, состояние, сохраненное в Ignite, станет несогласованным. В этом случае необходимо остановить перед перезапуском все узлы Platform и все узлы Ignite.
1. Остановите все узлы Platform.
2. Остановите все узлы Ignite.
3. Перезапустите все узлы Ignite.
4. Перезапустите все узлы Platform.
Если Ignite не перезапущен, сопоставления привязок и другие данные, хранящиеся в Ignite, будут неправильными и со временем приведут к нерегулярному поведению.
Сбои ZooKeeper
Сбой узла
При сбое одного из узлов ZooKeeper происходит следующее.
• Другие узлы ZooKeeper обнаруживают отсутствие ответа.
• Если неисправный узел является текущим лидером, выбирается новый лидер ZooKeeper.
Сбой нескольких узлов
Если произошел сбой нескольких узлов и ZooKeeper теряет свой кворум, он переводится в режим только для чтения и отклоняет запросы на изменение.
• Выбор нового лидера ZooKeeper в этом случае будет невозможен, так как исходная установка ZooKeeper с тремя узлами предполагает доступность двух серверов для обеспечения кворума. Максимально допустимое количество ошибок = ceil(N/2) - 1
• Оставшиеся экземпляры ZooKeeper не будут ни ведущим, ни резервным узлом.
• Все клиенты получат состояние SUSPENDED, а в конечном итоге - LOST.
Серверы ThingWorx
• В состоянии SUSPENDED роль одиночного сервера будет отменена. В течение этого времени таймеры или планировщики не выполняются.
• В статусе LOST все узлы выключаются.
• Если ZooKeeper восстанавливается до тайм-аута системы, то будет выбран новый одиночный сервер и обработка продолжится.
Сервер соединений
• Если сервер соединений получает состояние LOST из ZooKeeper, он будет выключен, так как не знает статус серверов ThingWorx.
Ignite
• Предполагается, что кластер ZooKeeper всегда является видимым для всех узлов в кластере. Если узел отсоединяется от ZooKeeper, он выключается и другие узлы рассматривают его как сбойный или отсоединенный.
Сбои Ignite
Влияние сбоев Ignite зависит от уровня репликации данных. Ignite всегда должен быть сконфигурирован для сохранения данных по крайней мере на двух узлах в кластере. Таким образом, если теряется один узел, это не влияет на систему.
Если теряются несколько узлов, возможна потеря данных, которая может перевести систему в несогласованное состояние. В этом случае рекомендуется полное выключение Ignite и ThingWorx. Затем можно перезапустить Ignite и перезапустить ThingWorx. Ignite представляет память приложения и, если она теряется, поведение при обработке может быть крайне несогласованным.
При общем сбое Ignite, когда ThingWorx не может соединиться ни с одним узлом Ignite, работа ThingWorx будет завершена.
Дополнительные сведения о резервных копиях данных см. в следующих документах:
Сбои PostgreSQL
Это обсуждение сбоев PostgreSQL основано на следующей конфигурации.
• Три узла PostgreSQL (писатель, читатель и резервный)
• Использование потоковой репликации между узлами PostgreSQL
• Два узла Pgpool-II, которые управляют доступом клиентов к узлам PostgreSQL и процедурами восстановления PostgreSQL
В случае сбоя сервера PostgreSQL активный узел Pgpool-II обнаруживает сбой и останавливает пересылку запросов на этот сервер. Данные пользователя или устройства, сохраняемые в момент сбоя, могут быть потеряны, если перед сбоем эта информация не была зафиксирована и реплицирована в других узлах.
В случае сбоя главного узла PostgreSQL (при условии, что синхронизированный и потенциальный узлы исправны и выполняются) происходит следующее.
• Выполняется переключение при отказе на синхронизирующий узел через Pgpool-II. Потенциальный узел теперь становится синхронизированным узлом нового главного узла. Запись в базу данных все еще возможна (например, создание новых сущностей и запись данных в BDWS).
• Если первоначальный главный узел возвращается к работе, необходимо вручную очистить и сконфигурировать среду для использования первоначального главного узла.
В случае сбоя обоих резервных узлов (при условии, что главный узел исправен и выполняется) происходит следующее.
• Переключения при отказе не происходит, и главный узел будет иметь нулевые узлы для репликации.
• Composer будет оставаться доступным. Сущности будут загружены и могут просматриваться, но не сохраняться. Журналы можно просматривать.
• Действия, которые требуют записи в базу данных (например, создание и сохранение сущности, задание значений для постоянных свойств и добавление потоковой записи) не будут успешными, так как PostgreSQL необходимо выполнять репликацию данных на резервный узел.
При сбое главного узла и синхронизированного резервного узла происходит следующее.
• Выполняется переключение при отказе на потенциальный узел. Потенциальный узел теперь является главным узлом без узлов для репликации.
• Composer будет доступен. Сущности будут загружены и могут просматриваться, но не сохраняться. Журналы можно просматривать.
• Действия, которые требуют записи в базу данных (например, создание и сохранение сущности, задание значений для постоянных свойств и добавление потоковой записи), не будут успешными, так как процесс записи будет зависать и завершаться сбоем.
При сбое всех трех узлов происходит следующее:
• Переключение при отказе не выполняется, так как нет доступных узлов.
• Composer не имеет доступа к базе данных. Поэтому сущности не будут загружаться и большинство сервисов работать не будут (сервисы подсистемы, такие как подсистема платформы, могут продолжать работать), а функциональные возможности подсистемы будут ограничены (журналы, мониторинг системы и мэшапы могут работать).
• Запись в базу данных и чтение из нее будут невозможны.
Сбой ThingWorx и PostgreSQL
В случае сбоя и лидера ThingWorx, и главного узла PostgreSQL происходит следующее.
• Резервный экземпляр ThingWorx становится лидером после выхода из строя лидера ThingWorx, а синхронизированный узел базы данных PostgreSQL становится главным узлом PostgreSQL.
◦ Потенциальный узел базы данных PostgreSQL становится новым синхронизированным узлом.
◦ ThingWorx Composer доступен, и может выполняться запись в базу данных PostgreSQL (можно создавать, править и удалять сущности, а также добавлять данные).
• Если первоначальный главный узел PostgreSQL необходимо будет восстановить в качестве главного узла, потребуется вручную выполнить очистку узлов PostgreSQL и Pgpool-II.
Сбой узла Pgpool-II
Сбой активного узла Pgpool-II
Если имеет место сбой активного узла Pgpool-II, резервная копия обнаружит это и переключит на себя обработку всех запросов к серверам PostgreSQL. Пользователи, зарегистрированные на активном сервере ThingWorx, могут столкнуться с задержкой в своих приложениях, и могут быть потеряны данные пользователя или устройства, которые сохранялись в момент сбоя в работе узла Pgpool-II.
Сбой всех узлов Pgpool-II
При сбое всех экземпляров Pgpool-II ThingWorx потеряет доступ к содержимому PostgreSQL и произойдет сбой большинства функций. Некоторая ограниченная функциональность может быть доступна в следующих областях:
• Ведение журналов - журнал приложения может по-прежнему дополняться сообщениями об ошибках.
• Мониторинг системы (например, мэшап MonitoringPlatformStats)
• Мэшапы - виджеты, которые не используют сервисы или данные из базы данных, по-прежнему могут работать.
• Значения непостоянных свойств.
• Сервисы, которые не зависят от базы данных.
Сбой ThingWorx и Pgpool-II
Если сбои экземпляров лидера ThingWorx и главного узла Pgpool-II возникают одновременно, происходит следующее:
• Лидер ThingWorx теряет лидерство, и лидером становится один из резервных узлов.
• Главный узел Pgpool-II теряет виртуальный IP-адрес. Один из резервных узлов Pgpool-II становится главным, и виртуальный IP-адрес переназначается на него.
• Резервный сервер ThingWorx будет пытаться полностью соединиться с базой данных и достигнет успеха только после назначения нового главного узла Pgpool.
• Будут применены процедура и поведение, описанные в подразделе "Сбой ведущего сервера ThingWorx".
Сбой Pgpool-II и PostgreSQL
При сбое PostgreSQL и Pgpool-II происходит следующее:
• Резервный узел PostgreSQL становится главным.
• Резервный узел Pgpool-II становится главным узлом, и ему передается виртуальный IP-адрес.
• На время переключения при отказе сервисы становятся временно недоступными.