실패 발생 시 예상 동작
이 단원에서는 하나 이상의 구성 요소 실패에 응답할 때 ThingWorx HA 구성에서 발생하는 작업을 설명합니다.
ThingWorx 서버 실패
ThingWorx 리더 노드 실패
수행되는 HA 절차
1. ZooKeeper가 리더로부터 아무런 응답을 받지 못합니다.
2. ZooKeeper가 대기 ThingWorx 서버 풀에서 새 리더를 선택합니다.
3. ZooKeeper가 대기 노드에 리더가 되도록 알립니다.
4. 새 리더가 데이터베이스에 연결되고 ThingWorx 모델을 초기화합니다.
5. 새 리더가 모든 ThingWorx 요청이 새 리더로 라우팅되도록 하는 확인을 부하 분산으로 보냅니다.
6. 부하 분산에서 모든 ThingWorx 트래픽을 새 리더로 라우팅합니다.
부하 분산 실패
작업 및 결과는 배포된 부하 분산 HA 솔루션에 따라 달라집니다. 모든 부하 분산 노드 간에 세션 콘텐츠를 공유할 수 있는 용량이 부하 분산에 있는 경우 활성 세션이 중단되지 않아야 합니다.
HAProxy 서버 실패
유일한 HAProxy 노드가 실패하거나 모든 HAProxy 노드가 실패하면 다음과 같은 결과가 발생합니다.
• 해당 IP 주소를 통해 ThingWorx 리더에 여전히 액세스할 수 있지만 HAProxy IP 주소를 통해서는 액세스할 수 없습니다.
• HAProxy를 통한 ThingWorx로의 요청이 ThingWorx에 도달하지 않습니다.
여러 HAProxy 노드 중 하나가 실패하면 다음과 같은 결과가 발생합니다.
• 백업 HAProxy가 새 마스터가 되면 기존 사용자 세션이 ThingWorx Composer에서 인식됩니다. 사용자가 다시 로그인하지 않아야 합니다.
• 백업 HAProxy가 마스터가 될 때까지 매쉬업이 로드되지 않습니다.
• 백업 HAProxy가 마스터가 될 때까지 Composer의 검색 엔티티가 로드되지 않습니다.
• 백업 HAProxy가 마스터가 될 때까지 요청이 ThingWorx에 도달하지 않습니다.
Zookeeper 노드 실패
한 개의 ZooKeeper 노드 실패
세 ZooKeeper 노드 중 하나가 실패하면 다음과 같은 결과가 발생합니다.
• 다른 ZooKeeper 노드가 실패하고 응답합니다.
• 실패한 노드가 현재 리더일 경우 새 ZooKeeper 리더가 선택됩니다.
• 모든 ThingWorx 서버는 영향을 받지 않아야 합니다. 모든 ThingWorx 서버는 활성 및 액세스 가능 상태를 유지합니다.
두 개의 ZooKeeper 노드 실패
• 원래 세 개의 노드 ZooKeeper 설정에서는 쿼럼을 구성하기 위해 두 개의 서버를 사용할 수 있는 것으로 예상하기 때문에 ZooKeeper에 대한 노드 선택이 발생할 수 없습니다. 허용되는 최대 실패 수 = ceil(N/2) - 1
• 나머지 ZooKeeper 인스턴스는 리더도 아니고 대기도 아닙니다.
• 리더 선택을 위해 ZooKeeper와 통신할 수 없으므로 ThingWorx 리더가 종료됩니다.
• 하나 이상의 다른 ZooKeeper 노드가 온라인 상태가 될 때까지 ThingWorx 대기 서버가 ZooKeeper와 통신을 재시도합니다.
• 둘 이상의 ZooKeeper 노드가 다시 온라인 상태가 되면 ZooKeeper 리더 선택이 발생합니다. ThingWorx 대기 노드가 ZooKeeper에 다시 연결되고 새 리더가 됩니다.
• 이전 ThingWorx 리더를 다시 시작해야 대기 노드가 됩니다.
ThingWorx 및 ZooKeeper 실패
ZooKeeper와 ThingWorx의 리더가 둘 다 실패하면 다음과 같은 결과가 발생합니다.
• '한 개의 ZooKeeper 노드 실패' 아래에 모든 조건이 나열됩니다. 먼저 새 ZooKeeper 리더를 결정해야 새 ZooKeeper 리더가 새 ThingWorx 리더를 결정합니다.
• '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 마스터가 설정되면 연결에 성공합니다.
Pgpool-II 및 PostgreSQL 실패
PostgreSQL 및 Pgpool-II가 실패하면 다음과 같은 결과가 발생합니다.
• PostgreSQL 대기 노드가 마스터 노드가 됩니다.
• Pgpool-II 대기 노드가 마스터 노드가 되고 마스터 노드에 가상 IP 주소가 전송됩니다.
• 장애 조치 중 잠시 서비스를 사용할 수 없습니다.