ThingWorx 고가용성 > HA 클러스터링 문제 해결
HA 클러스터링 문제 해결
각 서버에 응용 프로그램 키가 있지만 해당 값이 비어 있음
이 문제는 각 서버에서 암호화 키가 서로 다를 때 발생합니다. 키 저장소가 제대로 공유되지 않은 경우 이 문제가 발생할 수 있습니다.
보안 관리 도구를 사용하여 keystore-password 및 keystore.pfx 파일을 구성할 수 있습니다. 그런 다음, ThingworxStorage 디렉터리를 각 플랫폼 인스턴스에서 공유해야 합니다.
공유가 가능하지 않은 경우 한 서버를 시작하여 keystore-password 및 keystore.pfx 파일을 생성하고 다른 시스템에 복사한 후 시스템을 시작해야 합니다:
1. 한 서버를 시작하여 /ThingworxPlatform/keystore-password 및 /ThingworxStorage/keystore.pfx 파일을 생성합니다.
2. 이러한 파일을 다른 서버에 복사한 다음 다른 서버를 시작합니다.
서버 A에 생성된 사물이 서버 B에 없음
고가용성(HA)은 데이터베이스 전체에서 모델을 동기화하여 작동합니다. 이 동기화는 약 100밀리초마다 발생하며 구성 가능합니다. 모든 서버는 동일한 PostgreSQL 데이터베이스 인스턴스를 가리켜야 합니다. 따라서 플랫폼 설정의 데이터베이스 구성을 확인하여 연결 설정이 일치하는지 확인합니다. HA 클러스터에서 PostgreSQL을 실행하려면 Pgpool-II 및 기본-보조 PostgreSQL 구성을 사용하여 PostgreSQL HA 구성을 따라야 합니다.
일부 서버에서 속성 값이 설정되지 않음
서버 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 오류 때문에 서버가 시작되지 않음
서비스 검색을 구현하려면 서버를 시작하기 전에 외부 서비스가 ThingWorx에 연결하는 데 필요한 HTTP_PORT가 정의되어 있어야 합니다. 이 포트는 플랫폼 응용 프로그램이 실행되는 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 Connection Server가 ThingWorx에 연결할 수 없으며 인증 오류가 발생함
ThingWorx 서버에서 응용 프로그램 키를 생성하고 이 응용 프로그램 키를 ThingWorx Connection Server 구성에 추가해야 합니다. 이 키가 없거나 일치하지 않는 경우 플랫폼에 대한 연결을 생성하려고 시도하면 Connection Server에서 인증 오류가 발생합니다.
ThingWorx Connection Server가 ThingWorx 서버를 찾을 수 없음
ThingWorx Connection Server가 플랫폼에 연결되지 않을 경우 ThingWorx 서버에 저장된 HTTP_PORT 환경 변수가 플랫폼이 실행되고 있는 포트로 설정되어 있으며 서비스 이름이 ThingWorx에 대해 구성된 서비스 이름과 일치하는지 확인하십시오. 둘 중 하나가 잘못된 경우 Connection Server가 ThingWorx 서버를 찾지 못합니다.
또한 ThingWorx 서버가 Apache ZooKeeper에 잘못된 주소를 등록했을 수 있습니다. 이 문제는 ThingWorx 서버가 ZooKeeper가 실행되는 시스템의 IP 주소를 확인하려고 할 때 발생할 수 있습니다. 주소 확인 프로그램은 호스트 시스템의 모든 네트워크 인터페이스에 있는 모든 IP 주소를 검색하여 시스템의 LAN 주소일 가능성이 가장 높은 IP 주소를 확인합니다. 시스템에 IP 주소가 여러 개 있는 경우, 이 방법은 시스템에 사이트-로컬 IP 주소가 한 개(예: 192.168.x.x 또는 10.10.x.x, 일반적으로 IPv4)가 있으면 이 주소를 기본으로 설정하며 시스템에 사이트-로컬 IP 주소가 두 개 이상 있으면 첫 번째 주소를 반환합니다. 시스템에 사이트-로컬 주소가 없으면 이 방법은 검색한 첫 번째 비루프백 주소(IPv4 또는 IPv6)를 반환합니다.
응용 프로그램 성능 문제
클러스터링 환경에서는 사물 데이터가 분산되므로 응용 프로그램이 작성되는 방식이 성능에 큰 영향을 줍니다. 스크립트가 실행되는 서버 외부로의 라운드 트립을 줄이는 것이 중요합니다. 자세한 내용은 HA 응용 프로그램을 위한 모범 사례를 참조하십시오.
캐시 공급자가 시작되지 않음
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에 연결 제한 시간, 클라이언트 연결 또는 네트워크 지연 문제가 있는 경우 platform-settings.json 파일의 cache 설정에서 다음 고급 Ignite 구성을 활성화합니다. 각 값을 구성하는 방법에 대한 자세한 내용은 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. 다음에 설명된 대로 고정 잠금을 기다리는 동안 중단되지 않도록 MS 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
도움이 되셨나요?