ThingWorx HA의 최종 일관성
클러스터 모드에서 ThingWorx를 실행하면 모델 변경 사항이 최종적으로 클러스터 전체에 일관되게 적용됩니다. 서버 A의 변경 사항을 서버 B, C 등으로 동기화하는 데 약간의 시간이 걸립니다. 변경 사항을 동기화하기 위해 ThingWorx 모델 지속성 공급자에서 유지 관리되는 sync_log에 변경 사항이 기록됩니다. 클러스터의 각 서버는 구성 가능한 빈도(기본값: 100밀리초)로 변경 감시자 서비스를 실행하고 sync_log에서 엔티티 변경 사항을 감시합니다. 변경 감시자는 데이터베이스가 정보 소스라고 가정하고 해당 서버에서 변경된 엔티티를 언로드하고 다시 로드합니다. 이러한 최종 일관성은 모델 및 구성 변경 사항에만 적용되는 반면 상태는 즉시 일관됩니다.
• HTTP - HTTP는 고정 세션을 사용하므로 개별 사용자가 단일 시스템에 연결됩니다. 따라서 사용자가 모든 변경 사항을 즉시 봅니다. 다른 서버에서 다른 사용자가 수행한 변경 사항은 최종적으로 일관됩니다.
• WebSocket - 모델 변경이 WebSocket을 통해 수행되는 경우 현재 모델 버전이 WebSocket 세션에 저장됩니다. WebSocket 요청은 부하 분산을 위해 여러 서버를 순환합니다. 해당 WebSocket 세션에서 수행된 다음 요청은 세션이 연결된 서버가 세션에 저장된 버전 이상이 될 때까지 일시 중지됩니다. 서버가 1~2초 내에 동기화할 수 없으면 제한 시간이 초과됩니다.
다음 시나리오에서는 사용자에 대한 영향이 줄어든 상황에 대해 설명합니다.
• 시나리오 1: HTTP
장치 > HAProxy > 플랫폼 1..N
이 시나리오에서는 플랫폼 1에 연결하여 모델을 변경합니다. 그런 다음 다른 사용자를 플랫폼 2에 연결하고 변경 사항을 확인하면 변경 사항이 최종적으로 표시됩니다. 클러스터는 동기화 프로세스를 통해 모델 변경 사항이 적용되어 최종적으로 일관됩니다. 이 사용 사례에 해당하는 경우 변경 사항을 사용할 수 있게 될 때까지 다시 시도하는 메커니즘을 포함해야 합니다.
• 시나리오 2: WebSocket
장치 > HAProxy > CXServer1..N = > 플랫폼 1..N
이 시나리오에서는 장치와 Connection Server가 지점 간 방식으로 연결됩니다. 플랫폼 요청은 서버를 통해 순환됩니다. 장치에서 모델을 변경한 후 다른 서버로 향하는 다른 요청을 수행할 경우, 요청을 처리하기 전에 첫 번째 변경 사항이 다른 서버에 반영됩니다. 해당 요청은 모델 버전이 최소한 변경 사항이 적용된 버전과 동기화될 때까지 요청이 지연됩니다. 일정 기간 동안 버전을 동기화할 수 없는 경우 요청 제한 시간이 초과됩니다. 따라서 이 장치는 어떤 서버와도 통신하여 적절한 응답을 받을 수 있습니다.
두 번째 장치를 연결하고 첫 번째 장치에서 수행한 변경 사항을 확인하도록 하면 최종적으로 두 번째 장치에 일관성이 적용됩니다. 시스템은 단일 연결을 통한 변경 사항만 기다립니다.
• 시나리오 3: 모델을 변경하기 위한 HTTP 요청이 연결된 장치로 알림을 트리거합니다.
장치 > HAProxy > CXServer1..N = > 플랫폼 1..N
사용자가 모델을 변경하고 정의를 다시 끌어올 수 있도록 장치가 변경에 대한 알림을 받습니다. 장치가 아직 변경 사항을 볼 수 없는 서버에서 데이터를 끌어왔을 수 있습니다. 이제 WebSocket 세션에 모델 버전이 삽입되므로 모델 버전이 더 낮은 서버에서 장치가 요청을 수행할 경우 서버는 결과를 반환하기 전에 해당 모델 버전 이상으로 동기화될 때까지 기다립니다. 제때에 동기화할 수 없으면 요청 제한 시간이 초과됩니다.
따라서 새 postCommitEventQueue가 추가되었습니다. 속성 변경과 같은 추가된 이벤트는 전체 트랜잭션이 커밋되고 새 모델 버전이 알려진 후에 발생합니다. 장치에서 알림을 받으면 서버가 원래 변경 사항으로 일관된 상태가 될 때까지 해당 장치로부터의 향후 요청을 기다리도록 하기 위해 WebSocket 세션에 모델 버전이 삽입됩니다.
sync_log 지우기
사물 모델이 변경될 때마다 sync_log는 이전 엔트리가 제거될 때까지 계속 증가합니다. 모델이 변경되면 sync_log의 연관된 엔트리를 제거하여 sync_log의 크기를 줄이고 클러스터의 성능과 안정성을 향상시킬 수 있습니다.
Sync_log 제거는 구성 탭의 클러스터링 하위 시스템에서 구성됩니다. 자동 제거를 활성화하려면 제거 일정을 구성하고 일괄 처리 크기를 구성합니다.
|
설정
|
기본값
|
설명
|
|
Enable
|
True(활성화됨)
|
이 설정은 자동 제거를 활성화하거나 비활성화합니다.
|
|
Schedule
|
0 30 0 * * ?
|
이렇게 하면 sync_log 제거 일정이 설정됩니다.
|
|
Batch size for purge
|
10000
|
이는 가장 오래된 것부터 시작하여 sync_log에서 삭제할 레코드 수를 나타냅니다.
|