ThingWorx высокой доступности
Общие сведения о кластеризации ThingWorx высокой доступности
Чтобы уменьшить продолжительность бездействия критичных систем Интернета вещей (IoT), можно сконфигурировать ThingWorx для работы в среде высокой доступности (HA) в кластерном режиме. Кластеризация обеспечивает дополнительную масштабируемость и высокую доступность в предположении, что все компоненты сконфигурированы должным образом.
 |
Кластеризация HA не должна использоваться для решения аварийного восстановления.
|
|
|
Использование нескольких зон доступности для развертывания HA не поддерживается. Задержка сети между зонами может быть слишком большой, что не позволит обеспечить постоянное взаимодействие ThingWorx и узлами Apache Ignite.
|
В следующих разделах описаны настройка и конфигурация среды кластеризации, а также компоненты и соображения по развертыванию ThingWorx HA.
Все развертывания высокой доступности требуют дополнительных ресурсов сравнительно с развертыванием, разработанным только для удовлетворения функциональных требований и масштабирования. Эти дополнительные ресурсы основываются на оборудовании (например, серверы, диски, системы балансировки нагрузки и т. д.) и на программном обеспечении (например, сервисы синхронизации и балансировка нагрузки). После этого дополнительные ресурсы настраиваются так, чтобы гарантировать отсутствие одиночных точек сбоя в развертывании высокой доступности.
Все развертывания высокой доступности должны основываться на соглашении об уровне обслуживания (SLA), в котором были проанализированы требования к работоспособности приложения для развертывания. Например, сколько часов в месяц система может быть автономной? Это разрешенное время простоя для системных сбоев, обновления приложений или и того и другого. Количество дополнительных ресурсов, требуемых для системы высокой доступности, зависит от соглашения об уровне обслуживания, которому должна соответствовать система. В целом по мере повышения уровня обслуживания также растут требования к ресурсам для выполнения соглашения.
Глоссарий терминов
• высокая надежность
Система или компонент, работоспособные в течение всего требуемого периода времени.
• масштабируемость
Возможность увеличения нагрузки, которую может поддерживать система путем увеличения памяти, емкости диска или мощности центрального процессора или путем добавления серверов.
• кластер
Экземпляры одного и того же приложения, которые могут работать одновременно. Кластер обеспечивает высокую доступность и масштабируемость.
• одиночный
Одиночный сервер - это один сервер в кластере, обрабатывающий взаимодействие между кластерами, например таймеры и планировщики. Это гарантирует, что задания в кластере выполняются только один раз.
• виртуальный IP-адрес
IP-адрес, который представляет приложение. Клиенты, использующие виртуальный IP-адрес, обычно маршрутизируются в балансировщик нагрузки, который затем направляет запрос на сервер, где выполняется приложение.
• балансировщик нагрузки
Устройство, которое принимает сетевой трафик и распределяет его в приложения, готовые принимать трафик.
• переключение при отказе
Режим работы резервного копирования, при котором функции системного компонента (например, процессора, сервера, сети или базы данных) перенимаются вторичными компонентами системы, когда основной компонент становится недоступным из-за сбоя или запланированного времени отключения.
• конечная согласованность
Изменениям требуется время для распространения на все серверы в кластерной среде.Дополнительные сведения см. в разделе Конечная согласованность.
• общее состояние
Состояние, которое является общим для нескольких серверов в кластере и гарантированно является одинаковым независимо от того, на каком сервере выполняется поиск.Данные свойства являются примером общего состояния, в котором текущее значение свойства одинаково на всех серверах.
Справочная архитектура ThingWorx для высокой доступности
На следующем рисунке показана кластерная конфигурация ThingWorx.
Следующие компоненты могут быть частью развертывания кластера:
• Пользователи и устройства - нет ролей в функциональности HA. С их точки зрения, ничего не меняется. Они всегда используют одни и те же URL-адреса и IP-адреса, даже если на основном сервере ThingWorx есть изменения.
• Брандмауэры - не имеют функции высокой доступности и могут рассматриваться как необязательные. Брандмауэры часто размещаются для применения требований безопасности.
• Балансировщики нагрузки - балансировщики нагрузки управляют виртуальным IP-адресом для приложения, которое они поддерживают. Весь трафик, маршрутизируемый на этот виртуальный IP-адрес, направляется активному приложению, которое может его принимать.
• Серверы соединений ThingWorx - принимают трафик веб-сокетов из активов и направляют его в ThingWorx Platform. Серверы соединений могут работать в конфигурации кластера. После перенаправления актива на конкретный сервер соединений актив должен всегда использовать тот же сервер соединений. Если этот сервер переходит в автономный режим, актив должен быть перенаправлен на другой доступный сервер соединений.
• ThingWorx Foundation - принимает весь трафик пользователей и активов.
• Репозитории ThingWorx - это необходимые места хранения, такие как ThingworxPlatform, ThingworxStorage и ThingworxBackupStorage, а также любые дополнительные места хранения, добавленные для поддержки вашей реализации. Для кластерной среды папки хранилища должны существовать в общем расположении хранилища, где все серверы ThingWorx могут получить доступ к ним.
• Apache ZooKeeper - представляет централизованный сервис координации, используемый сервером соединений ThingWorx и Ignite для обнаружения сервисов, выборов одиночных серверов и координации распределения.
• Apache Ignite - предоставляет кэш распределенной памяти для реализации общего состояния на серверах в кластере.
• PostgreSQL - для конфигурации высокой доступности PostgreSQL работает через два или несколько серверных узлов в конфигурации горячего резервирования. Один узел принимает весь трафик записи, а один из других узлов может принимать весь трафик чтения. Между всеми узлами активируется потоковая репликация, чтобы поддерживать каждый узел в актуальном состоянии.
• Pgpool-II - используется только в конфигурациях PostgreSQL высокой доступности. Узлы Pgpool-II принимают запросы ThingWorx (на чтение и запись) и направляют их в соответствующий узел PostgreSQL. Кроме того, отслеживается работоспособность каждого узла PostgreSQL и могут инициироваться переключение при отказе и перенацеливание заданий, когда один из узлов переходит в автономный режим.
• Microsoft SQL Server (не изображен) - переключение при отказе Microsoft используется для того, чтобы обеспечить работу по крайней мере одного сервера MS SQL в интерактивном и доступном состоянии.
• InfluxDB - реализация InfluxDB не требуется для кластерной конфигурации ThingWorx. Если это необходимо для удовлетворения требований к приему данных в конкретной реализации, убедитесь, что она сконфигурирована для высокой доступности.