Устранение неисправностей для кластеризации HA

ThingWorx высокой доступности > Устранение неисправностей для кластеризации HA

Ключ приложения существует на каждом сервере, но его значение является пустым

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

Можно сконфигурировать файл keystore-password и файл keystore.pfx, используя Инструмент управления безопасностью. Затем каталог ThingworxStorage должен быть открыт для общего доступа для каждого экземпляра платформы.

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

1. Запустите один сервер, чтобы создать файлы /ThingworxPlatform/keystore-password и /ThingworxStorage/keystore.pfx.

2. Скопируйте эти файлы на другой сервер, а затем запустите этот другой сервер.

Вещь, созданная на сервере A, не находится на сервере B

Высокая доступность (HA) работает посредством синхронизации модели через базу данных. Синхронизация происходит приблизительно каждые 100 мс, но этот параметр можно настраивать. Все серверы должны указывать на один и тот же экземпляр базы данных PostgreSQL; поэтому проверьте конфигурацию базы данных в настройках платформы, чтобы убедиться, что настройки соединения совпадают. Если требуется выполнить PostgreSQL в кластере высокой доступности, необходимо следовать конфигурации PostgreSQL HA с использованием Pgpool-II и конфигурации основного-дополнительного PostgreSQL.

Значения свойств не задаются на всех серверах

Если вы задали значение свойства в памяти на сервере A и не увидели обновления значения на сервере B, значит неправильно сконфигурирован уровень кэша, который удерживает состояние. ThingWorx сохраняет состояния свойств в кэше Apache Ignite, который можно запускать как встроенный или распределенный. Журнал топологии записывается в журнал приложения и журналы Ignite, в которых отображается число клиентов и серверов в кластере. Необходимо подтвердить, что это зарегистрированное число серверов соответствует ожидаемому числу серверов. Если серверы не могут взаимодействовать друг с другом, это может быть вызвано брандмауэрами; Ignite будет выполняться только локально.

Например:

# log entry showing platform 1 has 2 clients and 1 server
platform1_1 | 13-Jan-2020 17:08:53.231 INFO [disco-event-worker-#37%twx-core-server%] org.apache.ignite.logger.java.JavaLogger.info Topology snapshot [ver=5, locNode=0cab6e47, servers=1, clients=2, state=ACTIVE, CPUs=12, offheap=1.6GB, heap=9.9GB]
# log entry showing platform 2 has 2 clients and 1 server
platform2_1 | 13-Jan-2020 15:02:29.736 INFO [ForkJoinPool.commonPool-worker-1] org.apache.ignite.logger.java.JavaLogger.info Topology snapshot [ver=4, locNode=c7383c40, servers=1, clients=3, state=ACTIVE, CPUs=16, offheap=1.6GB, heap=14.0GB]

Сервер не будет запущен из-за ошибки HTTP_PORT

Порт HTTP_PORT, через который внешние сервисы должны подключаться к ThingWorx, необходимо определить перед запуском сервера, чтобы применить обнаружение сервисов. Это открытый в Apache Tomcat порт, где выполняется приложение платформы. Эта переменная среды должна быть доступна для процесса, выполняющего Tomcat. Для конфигурирования можно использовать файл setEnv или обновить определение сервиса.

Определение сервиса Tomcat:

[Unit]
Description=Apache Tomcat Web Application Container
After=network.target
[Service]
Type=forking
PIDFile=/var/run/tomcat.pid
Environment=CATALINA_PID=/var/run/tomcat.pid
Environment=JAVA_HOME=/usr/lib/jvm/jdk1.8.0_191
Environment=HTTP_PORT=8080
Environment=CATALINA_HOME=/usr/share/tomcat9/9.0.26
Environment=CATALINA_BASE=/usr/share/tomcat9/9.0.26

Серверу подключения ThingWorx не удается подключиться к ThingWorx с ошибками аутентификации

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

Серверу подключения ThingWorx не удается найти серверы ThingWorx

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

Кроме того, сервер ThingWorx мог зарегистрировать неверный адрес в Apache ZooKeeper. Это может произойти, если сервер ThingWorx пытается определить IP-адрес компьютера, на котором выполняется ZooKeeper. Сопоставитель адресов будет проверять все IP-адреса всех сетевых интерфейсов на хост-компьютере, чтобы определить IP-адрес, который, скорее всего, будет являться адресом в локальной сети. Если компьютер имеет несколько IP-адресов, этот метод будет отдавать предпочтение IP-адресу локального сайта (при наличии такового у компьютера) (например, 192.168.x.x или 10.10.x.x, обычно IPv4) и будет возвращать первый адрес локального сайта, если у компьютера их несколько. Если у компьютера нет адреса локального сайта, этот метод возвратит первый найденный адрес, не являющийся кольцевым (IPv4 или IPv6).

Проблемы с производительностью приложения

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

Поставщик кэша не запускается

Если поставщик кэша Apache Ignite не запускается, это может быть связано с проблемой конфигурации. Например,

platform1_1 | 2020-07-13 17:34:14.965+0000 [L: ERROR] [O: E.c.q.l.c.Logger] [I: ] [U: SuperUser] [S: ] [P: platform1] [T: main] *** CRITICAL ERROR ON STARTUP: Failed to start CacheProvider com.thingworx.cache.ignite.IgniteCacheProvider

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

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

Проблемы с подключением Apache Ignite

При наличии в Ignite проблем с тайм-аутом соединения, подключением клиента или сетевой задержкой активируйте следующие расширенные конфигурации Ignite с помощью настроек cache в файле platform-settings.json. Сведения о настройке каждого значения см. в документации по Ignite. Дополнительные сведения о файле platform-settings.json см. в разделе Настройки платформы для ThingWorx HA.

# This failure timeout automatically controls the following parameters: getSocketTimeout(), getAckTimeout(), getMaxAckTimeout(), getReconnectCount().
# If any of those parameters is set explicitly, the failure timeout setting will be ignored. For example, for stable low-latency networks the
# failure detection timeout may be set to ~120 ms.
failure-detection-timeout = 10000
client-failure-detection-timeout = 30000
# should only be used for advanced configuration
tcp-communication-spi {
connection-timeout = 5000
socket-write-timeout = 2000
slow-client-queue-limit = 0
}
# should only be used for advanced configuration
tcp-discovery-spi {
socket-timeout = 5000
ack-timeout = 5000
join-timeout = 5000
network-timeout = 5000
connection-recovery-timeout = 5000
reconnect-count = 10
reconnect-delay = 2000
so-linger = 5
stats-print-frequency = 0
}

Задержанные блокировки в поставщиках моделей

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

• В PostgreSQL

a. Задайте тайм-аут блокировки в PostgreSQL во избежание зависания при ожидании для задержанных блокировок, как описано в документе https://www.postgresql.org/docs/9.3/static/runtime-config-client.html (на английском языке).

Например:

SET lock_timeout = 3000

b. Попытайтесь получить блокировку для таблицы.

c. Если серверу не удается получить блокировку из-за тайм-аута блокировки, определите возраст существующей блокировки с помощью следующего запроса:

select extract(epoch from (now() - query_start)) from pg_stat_activity where query like '%lock <tableName> in exclusive mode;'

d. Если возраст блокировки превышает заданный порог, выполните следующий запрос, чтобы найти процесс, удерживающий блокировку на данной таблице.

SELECT t.schemaname,
t.relname,
l.locktype,
l.page,
l.virtualtransaction,
l.pid,
l.mode,
l.granted
FROM pg_locks l
JOIN pg_stat_all_tables t ON l.relation = t.relid
WHERE t.schemaname <> 'pg_toast'::name AND t.schemaname <> 'pg_catalog'::name and t.relname = '<tableName>'

e. Прервите процесс, удерживая блокировку с помощью следующей команды:

SELECT pg_terminate_backend(pid);

• В MS SQL

a. Задайте тайм-аут блокировки в МС SQL, чтобы избежать зависания при ожидании для задержанных блокировок, как описано в документе https://docs.microsoft.com/en-us/sql/t-sql/statements/set-lock-timeout-transact-sql?view=sql-server-2017 (на английском языке).

Например:

set lock_timeout 3000;

b. Попытайтесь получить блокировку для таблицы.

c. Если серверу не удалось получить блокировку из-за тайм-аута блокировки, выполните следующий запрос, чтобы найти процесс, удерживающий блокировку данной таблице.

select
object_name(p.object_id) as tablename, request_owner_id, session_id
from
sys.dm_tran_locks l
inner join sys.partitions p on l.resource_associated_entity_id = p.object_id inner join sys.dm_tran_session_transactions tst ON l.request_owner_id = tst.transaction_id
and object_name(p.object_id) = '<tableName>'

d. Определите возраст существующей блокировки с помощью следующего запроса, передав session_id, загруженный на предыдущем шаге.

select datediff(second, (select last_batch from master.dbo.sysprocesses where spid = <session_id>), CURRENT_TIMESTAMP)

e. Если возраст блокировки превышает заданный порог, используйте session_id из предыдущего результата запроса, чтобы завершить процесс, удерживающий блокировку, с помощью следующей команды:

kill <sessionId>;

Ошибки EnsembleTracker

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

2021-03-22 06:35:10.092+0000 [L: ERROR] [O: o.a.c.f.i.EnsembleTracker] [I: ] [U: ] [S: ] [P: VTWSandboxSVA2] [T: main-EventThread] Invalid config event received: {server.2=52.149.229.159:2888:3888:participant, server.1=0.0.0.0:2888:3888:participant, server.3=13.92.154.53:2888:3888:participant, version=0}

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

Следующая конфигурация может вызвать ошибку:

server.1= xx.xxx.x.xx:2888:3888
server.2= xx.xxx.x.xx:2888:3888
server.3= xx.xxx.x.xx:2888:3888

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

server.1= xx.xxx.x.xx:2888:3888;2181
server.2= xx.xxx.x.xx:2888:3888;2181
server.3= xx.xxx.x.xx:2888:3888;2181

Было ли это полезно?