ThingWorx 고가용성
ThingWorx 고가용성 개요
중요 사물 인터넷(IoT) 시스템의 중단 기간을 줄이기 위해 HA(고가용성) 환경에서 작동하도록 ThingWorx를 구성할 수 있습니다. 이 안내서에서는 ThingWorx 시스템에 필요한 HA 고려 사항 및 ThingWorx HA 배포를 구성하는 구성 요소에 대해 설명합니다.
모든 HA 배포는 기능 및 확장 요구사항만 충족하도록 설계된 배포와 비교했을 때 추가 리소스가 필요합니다. 이러한 추가 리소스는 하드웨어 기반 리소스(예: 서버, 디스크, 부하 분산 등) 및 소프트웨어 기반 리소스(예: 동기화 서비스 및 부하 분산)입니다. 그런 다음 HA 배포 내에 단일 실패 지점이 없도록 추가 리소스를 구성합니다.
모든 HA 배포는 사용자 배포에서 응용 프로그램의 가동 시간 요구사항을 분석한 SLA(서비스 수준 계약)를 기반으로 해야 합니다. 예를 들어, 매월 몇 시간이나 시스템이 오프라인 상태가 될 수 있습니까? 이 시간이 시스템 실패, 응용 프로그램 업그레이드 또는 둘 다를 위한 허용된 다운타임입니까? HA 시스템에 필요한 추가 리소스 수는 목표하는 SLA에 따라 달라집니다. 일반적으로 SLA는 늘어나므로 이를 충족하기 위한 리소스 요구량도 증가합니다.
정의
• 고가용성
장시간 지속적으로 작동하는 시스템 또는 구성 요소입니다.
• 활성/활성
동시에 작동할 수 있는 동일한 응용 프로그램의 인스턴스 수입니다.
• 활성/수동
한 번에 작동할 수 있는 응용 프로그램의 한 인스턴스입니다. 추가 인스턴스를 사용할 수 있으며 필요한 경우 서비스를 넘겨 받을 수 있어야 합니다.
• 리더 또는 마스터
활성/수동 HA 구성에서 모든 트래픽이 라우팅되는 활성 서버입니다.
• 대기
현재 리더가 실패할 경우 서비스를 넘겨 받기 위해 대기 중인 활성/수동 HA 구성의 서버입니다.
• 가상 IP 주소
응용 프로그램을 나타내는 IP 주소입니다. 가상 IP를 사용하는 클라이언트는 일반적으로 부하 분산으로 라우팅된 후 응용 프로그램을 실행 중인 서버로 요청을 전달합니다.
• 부하 분산
네트워크 트래픽을 수신하고 트래픽을 수락할 준비가 된 응용 프로그램으로 트래픽을 분산하는 장치입니다. 활성/수동 HA 구성의 경우 부하 분산이 트래픽을 현재 리더로 전달합니다. 활성/활성 HA 구성의 경우 부하 분산이 트래픽을 여러 응용 프로그램 중 하나로 전달합니다.
• 장애 조치
실패나 예약된 다운타임으로 인해 주 구성 요소를 사용할 수 없을 때 시스템 구성 요소(예: 프로세서, 서버, 네트워크 또는 데이터베이스)의 기능을 보조 시스템 구성 요소가 수행하는 백업 작동 모드입니다.
고가용성을 위한 ThingWorx 참조 아키텍처
다음 이미지는 고가용성 구성의 ThingWorx를 보여줍니다.
다음은 이 구성의 구성 요소 및 HA 배포에서의 구성 요소 역할입니다.
• 사용자 및 장치 - HA 기능에서 역할이 없습니다. 사용자 및 장치 관점에서는 어떤 변경도 없습니다. 주 ThingWorx 서버가 변경되더라도 사용자 및 장치는 항상 동일한 URL 및 IP 주소를 사용합니다.
• 방화벽 - 어떠한 HA 기능도 선택적 기능으로 간주할 수 없습니다. 대개 방화벽은 보안 요구사항을 구현하기 위해 배치됩니다.
• 부하 분산 - 부하 분산은 부하 부산이 지원하는 응용 프로그램에 대한 가상 IP 주소를 관리합니다. 해당 가상 IP 주소로 라우팅되는 모든 트래픽은 트래픽을 수신할 수 있는 활성 응용 프로그램으로 전달됩니다.
• ThingWorx Connection Servers - 자산에서 WebSocket 트래픽을 수신하여 ThingWorx Platform으로 라우팅합니다. 연결 서버는 활성/활성 구성에서 작동할 수 있습니다. 자산이 특정 Connection Server로 전달된 후에는 항상 동일한 Connection Server를 사용해야 합니다. 해당 서버가 오프라인 상태가 되면 사용 가능한 다른 Connection Server로 자산이 리디렉션되어야 합니다.
• ThingWorx Foundation - 모든 사용자 및 자산 트래픽을 수신합니다. ThingWorx Foundation은 하나의 리더 서버와 하나 이상의 대기 서버로 구성된 활성/수동 구성에서 작동합니다. 리더 서버가 온라인이고 트래픽을 수신합니다. 대기 서버는 응용 프로그램이 실행 중일 때 시동된 상태로 실행되지만 데이터베이스에 대한 활성 연결은 없으며 트래픽을 수신하지 않습니다. 부하 분산은 모든 트래픽을 리더로 라우팅합니다. 리더가 오프라인 상태가 되면 대기가 리더로 수준이 올라가고 새 리더로 트래픽이 라우팅됩니다.
• ThingWorx 저장소 - ThingworxPlatform, ThingworxStorage 및 ThingworxBackupStorage와 같은 필수 스토리지 위치 및 구현을 지원하기 위해 추가된 추가 스토리지 위치입니다. HA 환경의 경우 모든 ThingWorx 서버(리더 및 대기)가 동일하게 액세스할 수 있는 공통 스토리지 위치에 ThingWorx 저장소가 있어야 합니다.
• Apache ZooKeeper - ZooKeeper는 ThingWorx가 특정 시점에 ThingWorx 서버 중 하나를 리더로 선택할 때 사용하는 중앙 집중식 조정 서비스입니다. ZooKeeper 클라이언트는 하트비트를 유지하고 현재 ThingWorx 리더 실패와 같은 구성 변경에 반응하기 위해 각 ThingWorx 서버에 포함되어 있습니다.
• PostgreSQL HA 구성의 경우 PostgreSQL은 상시 대기 구성에 있는 하나 이상의 서버 노드를 통해 작동합니다. 한 노드가 모든 쓰기 트래픽을 수신하고 다른 노드 중 하나가 모든 읽기 트래픽을 수신할 수 있습니다. 각 노드를 최신 상태로 유지하기 위해 모든 노드 간에 스트리밍 복제가 활성화됩니다.
• Pgpool-II - PostgreSQL HA 구성에서만 사용됩니다. Pgpool-II 노드는 ThingWorx 요청(읽기 및 쓰기)을 수신하여 적절한 PostgreSQL 노드로 전달합니다. 또한 각 PostgreSQL 노드의 상태를 모니터링하고 노드 중 하나가 오프라인 상태가 되면 작업의 대상을 변경하고 장애 조치를 시작할 수 있습니다.
• Microsoft SQL Server(그림에 없음) - Microsoft 장애 조치(Failover)는 하나 이상의 MS SQL 서버가 온라인이고 사용 가능한 상태가 되도록 보장하는 데 사용됩니다.
• DSE(DataStax Enterprise) - DSE 구현은 ThingWorx HA 구성에 필요하지 않습니다. 구현의 수집 요구사항을 충족하기 위해 필요한 경우에는 HA에 맞게 구성되어 있는지 확인하십시오. 일반적인 DSE 구현은 대부분의 HA 요구사항을 충족합니다. DSE 구현에는 콘텐츠를 수집하는 여러 개의 Cassandra 노드와 두 개 이상의 Solr 노드가 있습니다. DSE 디자인은 모든 콘텐츠를 하나 이상의 다른 노드에 복제합니다.
 |
설치 전 요구사항
참고 및 경고:
• 이 HA 프로세스에 포함된 단계는 HA 구성의 관계형 데이터베이스(PostgreSQL, Microsoft SQL Server 및 DataStax Enterprise)를 사용해 본 경험이 있는 데이터베이스 관리자(DBA)가 사용해야 합니다. 설치, 최적화 및 고가용성 클러스터링에 대한 지식이 필요합니다.
• 여기에 제공된 지침은 HA 환경 배포를 위한 것입니다. 생산 환경에서 추가 성능 조정이 필요할 수 있지만 이에 대해서는 이 문서에서 다루지 않습니다.
• 자세한 단계는 참조용 예이며 QA 또는 샌드박스 환경 전용입니다. 설치 관리자는 생산 환경에서 최적의 성능을 위해 명령 및 설정을 편집해야 할 수 있습니다.
• 생산 환경에서 사용하기 전에 모든 장애 조치 구성을 완전히 테스트하고 검증해야 합니다.
• 이 프로세스의 단계에서는 실패한 리더가 수정된 다음 리더 위치로 되돌아가는 페일백 시나리오에 대해서는 설명하지 않습니다. 이 문서에서는 실패한 구성 요소가 수정된 후 리더가 아닌 구성 요소로서 서비스로 되돌아간다고 가정합니다.
지원되는 운영 체제
일반 HA 요구사항
가상 IP 주소
• 연결 서버에 대한 사용자 및 자산(연결 서버를 사용하는 경우)
• ThingWorx Foundation에 대한 연결 서버
• PostgreSQL HA에 대한 ThingWorx Foundation(PostgreSQL을 사용하는 경우)
• Microsoft SQL Server HA에 대한 ThingWorx Foundation(Microsoft SQL Server를 사용하는 경우)
하드웨어 요구사항
여기에 제공된 단계에서는 ThingWorx HA 구성에 완전한 하드웨어 중복이 사용된다고 가정합니다.
• 하드웨어 수준에서 단일 실패 지점을 방지하려면 응용 프로그램의 각 인스턴스가 별개의 하드웨어에서 실행되어야 합니다. 예를 들어, ThingWorx 서버(물리적, 가상 또는 클라우드 기반)가 동일한 물리적 하드웨어에서 작동되지 않아야 합니다.
• 하드웨어 실패 위험을 완화하기 위해 이 요구사항은 ThingWorx HA 구성의 모든 응용 프로그램(ThingWorx, PostgreSQL, DataStax Enterprise, ZooKeeper 등)에 적용됩니다.
• 여기에 제공된 프로세스에서는 중복 라우터, 스위치, 전원 공급 장치 등이 있다고 가정합니다.
HA 구성의 ThingWorx 속성
장애 조치 시 데이터 손실을 방지하려면 ThingWorx 속성을 지속 속성으로 설정해야 합니다. 지속 속성이 아닐 경우 주 서버에서 보조 서버로의 장애 조치 시 메모리 내 값이 지워집니다.
PostgreSQL 요구사항
• Pgpool-II 및 PostgreSQL DB가 RHEL 또는 Ubuntu 환경에 설치되어 있어야 합니다.
• 최소 두 개의 DB 호스트 서버가 지원되는 버전의 PostgreSQL을 실행 중이어야 합니다. 세 개가 권장됩니다.
• watchdog이 구성된 Pgpool-II 3.7.<최신>을 실행 중인 두 개의 서버가 일반적입니다. 여기에서는 이러한 예를 제공하지만 Pgpool-II를 사용하지 않는 다른 HA 구성도 사용할 수 있습니다.
Microsoft SQL Server 요구사항
• 최소 두 개의 DB 호스트 서버가 지원되는 버전의 Microsoft SQL Server를 실행 중이어야 합니다.
• Microsoft SQL Server가 다음 Microsoft HA 방법 중 하나를 통해 작동하도록 구성되어 있습니다.
◦ AlwaysOn 장애 조치(Failover) 클러스터 인스턴스
◦ Always On 가용성 그룹
DataStax Enterprise 요구사항
• DataStax Enterprise 클러스터용 최소 다섯 개의 노드:
◦ 세 개의 Cassandra 노드
◦ 두 개의 Solr 노드
◦ (선택 사항) 관리 작업용 DSE OpsCenter 노드 한 개. OpsCenter는 작동에 중요하지 않으며 고가용성 구성이 필요하지 않기 때문입니다.
InfluxDB 요구사항
• 최소 두 개의 메타 노드, 대부분의 사용 사례에 세 개 권장
• 최소 두 개의 데이터 노드, 짝수 개수의 데이터 노드 사용 권장
• 일반 배포에는 세 개의 메타 노드와 짝수(예: 두 개)의 데이터 노드가 있어야 합니다.