ThingWorx 클러스터 크기 조정 고려 사항
ThingWorx Foundation 노드 크기 조정
클러스터링된 작업에서 개별 ThingWorx Foundation 노드의 크기 조정은 대체로 변경되지 않습니다. 각 클러스터 노드에는 전체 사물 모델을 로드하기에 충분한 메모리가 있어야 합니다. 따라서 각 클러스터 노드의 크기는 단일 서버 노드의 크기와 일치해야 합니다. 예를 들어, 중간 규모의 단일 서버는 16개의 vCPU 및 32GiB RAM입니다. 마찬가지로 두 개 노드 클러스터의 경우 각 클러스터 노드는 16개의 vCPU 및 32GiB RAM이 됩니다.
Apache Ignite를 별도로 배포하는 경우 속성 상태 정보가 Ignite 노드로 전송되면 Foundation 서버 메모리 소비가 약간 줄어들 수 있습니다.
CPU 사용률은 백그라운드 클러스터 동기화 작업을 실행하기 위해 증가합니다. 공유 캐시의 추가 대기 시간으로 인해 클러스터링된 구성에서 개별 작업이 약간 더 느려질 수도 있습니다. 이는 여러 노드에서 더 많은 수의 작업(비즈니스 로직 및/또는 사용자 요청)을 병렬로 실행하는 기능에 의해 오프셋됩니다.
고가용성의 경우 개별 노드의 올바른 크기가 결정되면 응용 프로그램의 최대 로드를 처리하는 데 필요한 것보다 하나 이상 더 많은 ThingWorx Foundation 노드를 배포하는 것이 좋습니다. 이렇게 하면 단일 노드 실패 시 클러스터가 성능 기대치를 계속 충족할 수 있습니다.
연결 서버 노드 크기 조정
클러스터링된 작업에서는 장치 로드를 클러스터 간에 분산하거나 노드 실패가 발생하는 경우 다시 분산하기 위해 연결 서버가 필요합니다.
Foundation 노드와 마찬가지로 필요한 장치 수를 처리하는 데 필요한 것보다 하나 이상 더 많은 연결 서버를 배포하는 것이 좋습니다. 이렇게 하면 단일 연결 서버 노드가 실패하는 경우 연결 서버에서 모든 장치와의 연결을 유지할 수 있습니다.
개별 연결 서버 옵션에 대한 시스템 요구사항은 ThingWorx Connection Services 도움말 센터를 검토하십시오.
Apache Zookeeper 노드 크기 조정
Apache ZooKeeper는 분산된 응용 프로그램의 동기화를 위한 오픈 소스 솔루션입니다. Apache ZooKeeper는 ThingWorx 노드에 대해 모니터링 및 리더 선택을 제공합니다.
3개의 노드로 구성된 한 세트(각각 두 개의 vCPU 및 2GiB RAM 포함)가 권장됩니다. 쿼럼을 유지하려면 홀수 개의 인스턴스가 필요합니다.
자세한 내용은 Apache Zookeeper 시스템 요구사항(https://zookeeper.apache.org/doc/r3.1.2/zookeeperAdmin.html#sc_systemReq)을 참조하십시오.
데이터베이스 노드 크기 조정
고가용성이 초과되면 클러스터링된 ThingWorx 구성에서 데이터베이스 로드가 증가합니다. 이를 설명하기 위해 Microsoft Azure 가상 컴퓨터를 사용하는 다음 5가지 서로 다른 중규모 배포에서 동일한 로드 테스트를 수행했습니다.
|
단일 노드 및 클러스터 성능 비교(PostgreSQL에만 해당)
|
|||||
|---|---|---|---|---|---|
|
Foundation
|
1 × F16s_v2
|
2 × F16s_v2
|
3 × F16s_v2
|
4 × F16s_v2
|
5 × F16s_v2
|
|
Ignite
|
없음
|
3 × F8s_v2
|
3 × F8s_v2
|
3 × F8s_v2
|
3 × F8s_v2
|
|
PostgreSQL
|
1 × F16s_v2
|
1 × F16s_v2
|
1 × F16s_v2
|
1 × F16s_v2
|
1 × F16s_v2
|
|
InfluxDB
|
없음
|
없음
|
없음
|
없음
|
없음
|
|
노드당 결과 수(평균)
|
26,000 WPS
19 HTTP Ops
|
12,000 WPS
10 HTTP Ops
|
10,000 WPS
6 HTTP Ops
|
7,000 WPS
6 HTTP Ops
|
6,000 WPS
2 HTTP Ops
|
|
총 결과 수
|
24,000 WPS
19 HTTP Ops
|
30,000 WPS
24 HTTP Ops
|
28,000 WPS
22 HTTP Ops
|
30,000 WPS
12 HTTP Ops
|
|
|
미리 알림: 크기 조정 안내서의 권장 사항은 초기 기준선을 사용하여 ThingWorx 구현의 크기를 조정하기 위한 것입니다. 개별 결과는 에지 구성, 응용 프로그램 로드 등에 따라 달라집니다.
|
|||||
위의 테스트는 소규모 데이터 수집 개선 사항을 보여주지만 HTTP 요청 성능은 부적절한 데이터베이스 리소스로 인해 개선되지 않습니다.
이를 해결하기 위해 대규모 RDBMS 인스턴스 및/또는 아래에 표시된 대로 InfluxDB를 사용하여 확장성을 향상시킬 수 있습니다.
|
단일 노드 및 클러스터 성능 비교(PostgreSQL과 InfluxDB)
|
|||||
|---|---|---|---|---|---|
|
Foundation
|
1 × F16s_v2
|
2 × F16s_v2
|
3 × F16s_v2
|
4 × F16s_v2
|
5 × F16s_v2
|
|
Ignite
|
없음
|
3 × F8s_v2
|
3 × F8s_v2
|
3 × F8s_v2
|
3 × F8s_v2
|
|
PostgreSQL
|
1 × F8s_v2
|
1 × F8s_v2
|
1 × F8s_v2
|
1 × F8s_v2
|
1 × F8s_v2
|
|
InfluxDB
|
1 × F8s_v2
|
1 × F8s_v2
|
1 × F8s_v2
|
1 × F8s_v2
|
1 × F8s_v2
|
|
노드당 결과 수(평균)
|
90,000 WPS
120 HTTP Ops
|
53,000 WPS
187 HTTP Ops
|
39,000 WPS
148 HTTP Ops
|
31,500 WPS
127 HTTP Ops
|
27,000 WPS
108 HTTP Ops
|
|
총 결과 수
|
106,000 WPS
375 HTTP Ops
|
118,000 WPS
445 HTTP Ops
|
126,000 WPS
508 HTTP Ops
|
135,000 WPS
540 HTTP Ops
|
|
|
미리 알림: 크기 조정 안내서의 권장 사항은 초기 기준선을 사용하여 ThingWorx 구현의 크기를 조정하기 위한 것입니다. 개별 결과는 에지 구성, 응용 프로그램 로드 등에 따라 달라집니다.
|
|||||
 |
InfluxDB 오픈 소스는 이러한 테스트에 사용되었으며 고가용성을 제공하지 않습니다. InfluxDB Enterprise는 생산 ThingWorx 클러스터 구현에 권장됩니다. InfluxDB Enterprise 크기 조정의 경우 표시된 두 개의 InfluxDB "데이터" 노드와 3개의 "메타" 노드(일반적으로 각각 1~2개의 vCPU 및 0.5~1GiB RAM으로 구성)를 계획합니다. InfluxDB 크기 조정에 대한 자세한 내용은 https://docs.influxdata.com/influxdb/v1.8/guides/hardware_sizing/을 참조하십시오.
|
Apache Ignite 노드 크기 조정
ThingWorx 클러스터에서 Apache Ignite는 속성 값 및 추가 데이터(예: 파일 전송 작업)에 대한 공유 캐시를 제공합니다.
Ignite는 ThingWorx Foundation 프로세스 내에 포함될 수 있으며 이 경우 별도의 설치는 필요하지 않습니다. 또는 보다 큰 로드 분산의 경우 Ignite를 별도의 클러스터로 배포할 수도 있습니다.
Ignite는 다음 두 가지 모드 중 하나로 실행될 수도 있습니다.
• PARTITIONED 모드 - 데이터가 여러 파티션으로 균등하게 나눠지고 참여 노드 간에 균등하게 분할됩니다. 최상의 캐시 쓰기 성능입니다.
• REPLICATED 모드 - 각 Ignite 인스턴스에는 모든 데이터 요소의 복사본이 있습니다. 최상의 캐시 읽기 성능입니다.
자세한 내용은 캐시 모드의 Apache Ignite 설명서(https://apacheignite.readme.io/docs/cache-modes)를 참조하십시오.
Ignite에서의 기본 로드는 각 ThingWorx Foundation과 Ignite 인스턴스 간의 네트워크 처리량입니다. CPU, 디스크 또는 메모리 요구사항이 클라우드 공급자의 더 작은 VM 크기를 나타낼 수 있지만 제한적이거나 한정된 네트워크 처리량을 모니터링하는 것은 중요합니다.
처리량 문제가 발생하면 보다 많은 네트워크 용량의 대규모 시스템으로 이동하거나 분할 모드를 사용하여 Ignite 노드를 더 추가하여 로드를 분산하여 해당 문제를 해결할 수 있습니다.
대략적으로 처음 시작할 때에는 ThingWorx Foundation 노드와 동일한 메모리 크기가 대체로 안전한 추정치가 됩니다.
공유 캐시의 메모리 공간을 보다 정확하게 계산하려면 다음을 수행하십시오.
1. ThingWorx 속성 캐시에 대한 VTQ(값, 타임스탬프 및 품질) 메모리 공간을 계산합니다.
a. 각 사물 유형에 대해 메모리의 데이터 유형 크기를 결정합니다. 예를 들어, 속성이 50자로 된 문자열이고 각 문자에 2바이트가 필요한 경우 해당 문자열에는 100바이트의 메모리가 필요합니다.
b. 8바이트를 더합니다. (해당 값의 날짜/시간에 대해 4와 값의 품질에 대해 4를 더한 값)
c. 2를 곱합니다. ThingWorx는 각 속성의 현재 값과 이전 값을 캐시합니다.
d. 해당 유형의 사물 수를 곱합니다.
e. 각 사물 유형에 대한 결과를 함께 더합니다.
2. Ignite의 메모리 내 색인에 대해 30%를 더합니다.
3. Ignite 클러스터에서 원하는 데이터 복사본 수를 곱합니다. 예를 들어, 단일 Ignite 노드가 실패하는 경우 데이터가 손실되지 않도록 데이터를 한 번 백업하려는 경우에는 2를 곱합니다.
4. 배포할 Ignite 클러스터 노드의 수로 나눕니다.
5. 각 Ignite 노드에는 해당 작업을 위한 추가 ~300MB가 필요합니다.
자세한 내용은 Apache Ignite 설명서(https://apacheignite.readme.io/docs/capacity-planning)를 참조하십시오.