실패 발생 시 예상 동작
이 항목에서는 하나 이상의 구성 요소 실패에 응답할 때 ThingWorx 클러스터링 구성에서 발생하는 작업을 설명합니다.
부하 분산 실패
작업 및 결과는 배포된 부하 분산 HA 솔루션에 따라 달라집니다. 모든 부하 분산 노드 간에 세션 콘텐츠를 공유할 수 있는 용량이 부하 분산에 있는 경우 활성 세션이 중단되지 않아야 합니다.
HAProxy 서버 실패
유일한 HAProxy 노드가 실패하거나 모든 HAProxy 노드가 실패하면 다음과 같은 결과가 발생합니다.
• 해당 IP 주소를 통해 ThingWorx 리더에 여전히 액세스할 수 있지만 HAProxy IP 주소를 통해서는 액세스할 수 없습니다.
• HAProxy를 통한 ThingWorx로의 요청이 ThingWorx에 도달하지 않습니다.
여러 HAProxy 노드 중 하나가 실패하면 다음과 같은 결과가 발생합니다.
• 백업 HAProxy가 새 마스터가 되면 기존 사용자 세션이 ThingWorx Composer에서 인식됩니다. 사용자가 다시 로그인하지 않아야 합니다.
• 백업 HAProxy가 마스터가 될 때까지 매쉬업이 로드되지 않습니다.
• 백업 HAProxy가 마스터가 될 때까지 Composer의 검색 엔티티가 로드되지 않습니다.
• 백업 HAProxy가 마스터가 될 때까지 요청이 ThingWorx에 도달하지 않습니다.
ThingWorx 서버 실패
ThingWorx 서버가 실패하면 다음과 같은 결과가 발생합니다.
• 상태 확인 ping이 실패하므로 서버가 부하 분산에서 제거됩니다. 제거 시점은 확인 빈도에 따라 달라집니다.
• ZooKeeper가 서버 실패를 감지하고 내부 서비스 검색에서 제거하고 Connection Server와 같은 감시자에게 이를 알립니다.
• 서버가 단일 서버이면 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가 복구되면 새 단일 노드가 선택되고 처리가 계속됩니다.
Connection Server
• Connection Server가 ZooKeeper에서 LOST 상태를 가져올 경우 ThingWorx 서버의 상태를 알 수 없으므로 종료됩니다.
Ignite
• ZooKeeper 클러스터가 클러스터의 모든 노드에 항상 표시된다고 가정합니다. 노드가 ZooKeeper와 연결이 끊기면 노드가 종료되고 다른 노드는 이 노드를 실패한 노드 또는 연결이 끊긴 노드로 취급합니다.
Ignite 실패
Ignite 실패가 가져오는 영향은 데이터 복제 수준에 따라 다릅니다. Ignite는 항상 클러스터에서 두 개 이상의 노드에 데이터를 저장하도록 구성해야 합니다. 따라서 한 노드가 손실되더라도 시스템에 영향을 주지 않습니다.
여러 노드가 손실된 경우 데이터 손실이 발생할 수 있으며 이로 인해 시스템이 일관되지 않은 상태가 될 수 있습니다. 이 경우 Ignite 및 ThingWorx를 완전히 종료하는 것이 좋습니다. 그런 다음 Ignite를 다시 시작하고 ThingWorx를 다시 시작할 수 있습니다. Ignite는 응용 프로그램 메모리이며 손실될 경우 처리 동작이 일관되지 않을 수 있습니다.
ThingWorx가 Ignite 노드에 연결할 수 없는 총체적인 Ignite 오류가 발생하면 ThingWorx가 종료됩니다.
데이터 백업에 대한 자세한 내용은 다음을 참조하십시오.
PostgreSQL 실패
PostgreSQL 실패에 대한 이 설명은 다음 구성을 토대로 합니다.
• 세 개의 PostgreSQL 노드(기록기, 판독기 및 대기)
• PostgreSQL 노드 간 스트리밍 복제 사용
• PostgreSQL 노드에 대한 클라이언트 액세스를 관리하는 Pgpool-II 노드 하나와 PostgreSQL 복구 절차를 관리하는 Pgpool-II 노드 하나
PostgreSQL 서버가 실패하면 활성 Pgpool-II 노드가 실패를 감지하고 해당 서버로의 요청 라우팅을 중지합니다. 실패 발생 전에 정보가 커밋되어 다른 노드로 복제되지 않은 경우 실패 발생 시 저장 중이었던 사용자 또는 장치 데이터는 손실될 수 있습니다.
마스터 PostgreSQL 노드가 실패하면(동기화 및 잠재 노드가 시작되어 실행 중이라고 가정함) 다음과 같은 결과가 발생합니다.
• 동기화 노드로의 장애 조치가 Pgpool-II를 통해 발생합니다. 이제 잠재 노드가 새 마스터 노드에 대한 동기화 노드가 됩니다. 데이터베이스에 대한 쓰기가 여전히 가능합니다(예: 새 엔티티 만들기 및 BDWS에 데이터 쓰기).
• 원래 마스터가 다시 온라인 상태가 되면 원래 마스터를 사용하도록 환경을 수동으로 정리 및 구성해야 합니다.
두 대기 노드가 모두 실패하면(마스터 노드가 여전히 시작되어 실행 중이라고 가정함) 다음과 같은 결과가 발생합니다.
• 장애 조치가 발생하지 않으며 마스터 노드에 복제할 노드가 0개 있습니다.
• Composer에는 여전히 액세스할 수 있습니다. 엔티티가 로드되고 볼 수는 있지만 저장할 수는 없습니다. 로그를 볼 수 있습니다.
• PostgreSQL이 데이터를 대기 노드에 복제해야 하므로 데이터베이스에 쓰기가 필요한 작업(예: 엔티티 만들기 및 저장, 지속 속성에 값 설정, 스트림 엔트리 추가)은 성공하지 못합니다.
마스터 노드와 동기화 대기 노드가 실패하면 다음과 같은 결과가 발생합니다.
• 잠재 노드로의 장애 조치가 발생합니다. 이제 잠재 노드가 복제할 노드가 0개인 마스터 노드가 됩니다.
• Composer에 액세스할 수 있습니다. 엔티티가 로드되고 볼 수는 있지만 저장할 수는 없습니다. 로그를 볼 수 있습니다.
• 쓰기가 중단되고 결국 실패하므로 데이터베이스에 쓰기가 필요한 작업(예: 엔티티 만들기 및 저장, 지속 속성에 값 설정, 스트림 엔트리 추가)은 성공하지 못합니다.
세 노드가 모두 실패하면 다음과 같은 결과가 발생합니다.
• 사용 가능한 노드가 없기 때문에 장애 조치가 발생하지 않습니다.
• Composer가 데이터베이스에 액세스할 수 없습니다. 따라서 엔티티가 로드되지 않습니다. 대부분의 서비스가 작동하지 않으며(플랫폼 하위 시스템과 같은 하위 시스템 서비스는 작동할 수도 있음) 시스템 기능이 제한됩니다(로그, 시스템 모니터링 및 매쉬업은 작동할 수도 있음).
• 데이터베이스에 대한 쓰기 및 읽기가 가능하지 않습니다.
ThingWorx 및 PostgreSQL 실패
ThingWorx 리더 및 PostgreSQL 마스터가 모두 실패하면 다음과 같은 결과가 발생합니다.
• ThingWorx 리더가 다운되고 PostgreSQL 데이터베이스의 동기화 노드가 PostgreSQL 마스터 노드가 된 후 대기 ThingWorx 인스턴스가 리더가 됩니다.
◦ 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 주소가 전송됩니다.
• 장애 조치 중 잠시 서비스를 사용할 수 없습니다.