온프레미스 커넥터 호스트 배포

Tulip 통합을 위한 온프레미스 커넥터 호스트(OPCH)의 배포, 구성 및 유지 관리에 필요한 기술적 단계를 알아보세요.

이 문서는 OPCH의 물리적 배포 및 수명 주기 관리를 담당하는 담당자를 위한 기술 참조 가이드입니다. 커넥터 호스트는

외부 웹 서비스, 데이터베이스 및 OPC UA 서버로의 연결을 용이하게 하는 데 사용되는 서비스입니다. 모든 Tulip 인스턴스에는 기본적으로 클라우드 커넥터 호스트가 있습니다.

온프레미스 커넥터 호스트가 아키텍처에 적합한지 판단할 때 고려해야 할 몇 가지 사항이 있습니다.

전제 조건

계속 진행하기 전에 Tulip 커넥터 호스트의 기본 사항을 숙지했는지 확인하십시오: * 커넥터 호스트 * 온프레미스 커넥터 호스트

네트워킹

온프레미스 커넥터 호스트를 배포하는 가장 일반적인 이유는 로컬 네트워크 내에 호스팅된 시스템에 연결할 때 제공하는 이점 때문입니다. 온프레미스 방식을 사용하면 Tulip에서 외부 시스템으로의 모든 연결이 로컬 네트워크 내부에서 시작됩니다. 네트워크에서 Tulip으로의 모든 연결은 보안 WebSocket을 통해 아웃바운드 방식으로 이루어집니다.

이는 서비스에 대한 인바운드 액세스가 필요한 클라우드 커넥터 호스트와는 대조적입니다. 일반적으로 Tulip의 클라우드에서 서비스로 들어오는 보안 WebSocket 연결을 허용하는 것은 IT 부서의 결정 사항이며, 대개 WAN 라우터/방화벽의 포트 포워딩 규칙을 통해 이루어집니다.

온프레미스 커넥터 호스트 배포

기술 표준

온프레미스 솔루션을 배포하기로 결정된 경우, Tulip은 분산형 Docker 이미지를 사용하는 셀프 서비스 방식을 권장합니다. 이를 구현하는 가장 쉬운 방법은 리눅스 배포판이 설치된 가상 머신을 사용하는 것입니다.

또한 Tulip은 사이트의 단일 장애 지점을 방지하기 위해 가상 머신당 온프레미스 커넥터 호스트를 하나만 호스팅할 것을 권장합니다.

가상 머신 요구 사항:

• RAM - 4 GB
• ROM - 8~16GB 디스크 용량
• CPU - 2코어
• Docker 버전 - 20.10 이상

네트워킹 요구 사항과 관련하여, 온프레미스 커넥터 호스트는 다음을 갖추고 있습니다:

• IP 주소
• 다음에 대한 DNS 확인
• 포트 443을 통한 Tulip( 여기에 나열된 IP)로의 아웃바운드 액세스
• 여기에 있는 Docker 저장소로 향하는 아웃바운드 액세스
• 포트를 통해 모든 관련 외부 시스템으로의 아웃바운드 액세스

여기에서 전체 네트워크 요구 사항 목록을 확인하세요

배포

다음 섹션에서는 다양한 환경에서 온프레미스 커넥터 호스트를 배포하는 방법을 설명합니다. AWS와 Azure 모두 Docker 이미지를 실행할 수 있는 컨테이너 서비스를 제공합니다.

AWS

웹 UI와 다음 지침 세트를 사용하십시오: https://aws.amazon.com/getting-started/hands-on/deploy-docker-containers/

Azure (Bash): LTS16+ OPCH

az container create `-g <AZURE 내 리소스 그룹 이름> `--name <컨테이너 이름> `--cpu 2 `--memory 3 `--restart-policy Always `--public.ecr.aws/tulip/connector-host:<TAG>--os-type Linux `-e TULIP_UUID='<UUID>' `TULIP_FACTORY='https://<사용자 사이트>.tulip.co' `TULIP_MACHINE_SECRET='<SECRET>' `TULIP_DEVICE_TYPE='onprem' `TULIP_LOGGING_TO_TULIP=true`TULIP_TELEMETRY_TO_TULIP=true`TULIP_CONNECTORS_HTTP_PROXY='' `TULIP_CONNECTORS_HTTPS_PROXY=''

Azure (Bash): LTS16 이전 OPCH

az container create `-g <AZURE 내 리소스 그룹 이름> `--name <컨테이너 이름> `--cpu 2 `--memory 3 `--restart-policy Always `--public.ecr.aws/tulip/connector-host:<TAG> `--os-type Linux `-e TULIP_UUID='<UUID>' `TULIP_FACTORY='https://<사용자 사이트>.tulip.co' `TULIP_MACHINE_SECRET='<SECRET>' `TULIP_DEVICE_TYPE='onprem' `CONNECTORS_HTTP_PROXY='' `CONNECTORS_HTTPS_PROXY=''

Linux VM: LTS16+ OPCH

docker run -d \ --name tulip-connector-host \ -e TULIP_FACTORY='https://<FACTORY>.tulip.co' \ -e TULIP_UUID='<UUID>' \ -e TULIP_MACHINE_SECRET='<SECRET>' \ -e TULIP_DEVICE_TYPE='onprem' \ -e TULIP_LOGGING_TO_TULIP=true \ -e TULIP_TELEMETRY_TO_TULIP=true \ -e TULIP_CONNECTORS_HTTP_PROXY='' \ -e TULIP_CONNECTORS_HTTPS_PROXY='' \ --restart=always \ --net=host \ public.ecr.aws/tulip/connector-host:<TAG>

Linux VM: LTS16 이전 OPCH

 --name tulip-connector-host \  
 -e TULIP\_FACTORY='https://.tulip.co' \  
 -e TULIP\_UUID='' \  
 -e TULIP\_MACHINE\_SECRET='' \  
 -e TULIP\_DEVICE\_TYPE='onprem' \  
 -e CONNECTORS\_HTTP\_PROXY='' \  
 -e CONNECTORS\_HTTPS\_PROXY='' \  
 -e EXIT\_ON\_DISCONNECT=true \ --restart=always \  
 --net=host \  
 --mount type=volume,source=tuliplog,target=/log \  
 public.ecr.aws/tulip/connector-host:

Windows (PowerShell): LTS16+ OPCH

docker run -d --name tulip-connector-host -e TULIP_FACTORY='https://<FACTORY>.tulip.co' -e TULIP_UUID='<UUID>' -e TULIP_MACHINE_SECRET='<SECRET>' -e TULIP_DEVICE_TYPE='onprem' -e TULIP_LOGGING_TO_TULIP=true -e TULIP_TELEMETRY_TO_TULIP=true -e TULIP_CONNECTORS_HTTP_PROXY='' -e TULIP_CONNECTORS_HTTPS_PROXY='' --restart=always --net=host public.ecr.aws/tulip/connector-host:<TAG>

Windows (PowerShell): LTS16 이전 버전 OPCH

docker run -d --name tulip-connector-host -e TULIP_FACTORY='https://<FACTORY>.tulip.co' -e TULIP_UUID='<UUID>' -e TULIP_MACHINE_SECRET='<SECRET>' -e TULIP_DEVICE_TYPE='onprem' -e HTTP_PROXY='' -e HTTPS_PROXY='' -e EXIT_ON_DISCONNECT=true --restart=always --net=host --mount type=volume,source=tuliplog,target=/log public.ecr.aws/tulip/connector-host:<TAG>

인증서 오류 해결

OPCH가 “인증서 체인에 자체 서명된 인증서가 있음” 오류와 함께 시작에 실패하는 경우, 근본 원인은 사용자 정의 인증서를 사용하는 기업용 프록시/방화벽이 Tulip Cloud와의 보안 연결을 차단하고 있기 때문일 수 있습니다.

증상 - OPCH가 “Never seen” 상태를 표시함 - 시작 중에 프로세스가 종료됨 - 로그에 SSL 인증서 체인 오류가 기록됨

이 문제를 해결하려면, 아래와 같이 환경 변수를 설정하여 OPCH 시작 시 참조할 추가 인증 기관(CA)을 지정하십시오. 참고로, 해당 파일은 Docker 컨테이너 내에 존재해야 합니다.

LTS16 이전 버전의 OPCH의 경우: -e CONNECTORS_EXTRA_TRUSTED_CAS_FROM_FILES='["/etc/tulipCa/ca.pem"]'

LTS16 이상 OPCH의 경우: -e TULIP_CONNECTORS_EXTRA_TRUSTED_CAS_FROM_FILES='["/etc/tulipCa/ca.pem"]'

온프레미스 커넥터 호스트 업그레이드

:::(경고) (Edge IO도 업그레이드가 필요할 수 있습니다)
OPCH는 Edge IO 장치에서 실행될 수 있습니다. 장치에서 자동 업그레이드 기능이 활성화되어 있지 않은 경우, 수동으로 업그레이드해야 합니다.

모든 OPCH 업그레이드를 완료한 후에도 이 경고 배너가 계속 표시된다면, Edge IO 도 업데이트되었는지 확인하십시오.
:::

Tulip은 장기 지원(LTS) 릴리스 일정에 따라 온프레미스 커넥터 호스트(OPCH) 업데이트를 제공합니다. 서비스를 업그레이드하려면 다음 지침을 따르십시오:

OPCH 업그레이드 과정에서는 파드가 중지되고 다시 생성되는 동안 서비스 중단이 발생합니다.

1. On-Premise Connector Host Docker 이미지의 최신 버전을 확보하십시오.

   docker pull public.ecr.aws/tulip/connector-host:<TAG>2. 아래 명령어를 실행하여 Docker 컨테이너 ID를 확인하십시오.

   docker ps3. TULIP_FACTORY, TULIP_UUID 및 TULIP_MACHINE_SECRET에 액세스할 수 있다면 4단계로 진행하십시오. 그렇지 않은 경우, 다음 명령을 실행하고 이 명령의 출력을 안전한 위치에 저장하십시오.

   docker exec <컨테이너 ID> env4. 기존 Docker 컨테이너를 중지합니다.

   docker stop <컨테이너 ID>5. 기존 Docker 컨테이너를 제거합니다.

   docker rm <컨테이너 ID>6. 저장해 둔 자격 증명을 사용하여 표준 Docker run 명령어를 실행합니다.

LTS16 이상 OPCH의 경우: docker run -d \ --name tulip-connector-host \ -e TULIP_FACTORY='https://<FACTORY>.tulip.co' \ -e TULIP_UUID='<UUID>' \ -e TULIP_MACHINE_SECRET='<SECRET>' \ -e TULIP_DEVICE_TYPE='onprem' \ -e TULIP_LOGGING_TO_TULIP=true \ -e TULIP_TELEMETRY_TO_TULIP=true \ -e TULIP_CONNECTORS_HTTP_PROXY='' \ -e TULIP_CONNECTORS_HTTPS_PROXY='' \ --restart=always \ --net=host \ public.ecr.aws/tulip/connector-host:<TAG>LTS16 이전 버전의 OPCH의 경우: docker run -d \ --name tulip-connector-host \ -e TULIP_FACTORY='https://<FACTORY>.tulip.co' \ -e TULIP_UUID='<UUID>' \ -e TULIP_MACHINE_SECRET='<SECRET>' \ -e TULIP_DEVICE_TYPE='onprem' \ -e CONNECTORS_HTTP_PROXY='' \ -e CONNECTORS_HTTPS_PROXY='' \ -e EXIT_ON_DISCONNECT=true \ --restart=always \ --net=host \ --mount type=volume,source=tuliplog,target=/log \ public.ecr.aws/tulip/connector-host:<TAG>

1. 새 Docker 컨테이너가 실행 중인지 확인합니다.

   docker ps

커넥터 환경을 사용하여 업그레이드를 테스트하십시오

각 커넥터에는 세 가지 환경(프로덕션, 프리프로덕션, 개발)이 있으며, 각 환경은 고유한 커넥터 호스트를 가질 수 있고 서로 다른 버전을 사용할 수 있습니다. 애플리케이션의 상태(개발 버전, 승인 대기 중, 게시됨)에 따라 다른 환경을 사용할 수 있습니다.커넥터 호스트 검증을 수행하는 예상 절차는 다음과 같습니다. 1. 개발용 OPCH를 업그레이드합니다. 2. 검증용 커넥터 호스트를 업그레이드합니다(여기서 사전 운영 환경은 개발 환경을 가리킵니다). 1. 커넥터 페이지 또는 애플리케이션의 개발 모드에서 커넥터를 테스트합니다. 3. 검증 테스트가 완료되면 운영용 커넥터 호스트를 업그레이드합니다.

자세한 내용은 ‘커넥터 환경’을 참조하십시오.

또는 개발 인스턴스에서 OPCH를 먼저 업그레이드한 후, 프로덕션 환경을 안심하고 업그레이드할 수도 있습니다.

외부 로그 관리 도구로 로그 전송

온프레미스 커넥터 호스트(OPCH) 로그를 타사 도구로 전달하여 중앙 집중식 모니터링 및 문제 해결을 수행할 수 있습니다. OPCH는 환경 변수를 통해 Datadog, Grafana Loki 및 Splunk를 지원합니다. 사용 가능한 로그 유형은 OPCH의 상태(특히 팩토리와의 연결 상태), 커넥터 호출 실행 및 구독 로그와 관련이 있습니다. OPCH 시작 흐름의 일환으로, 사용자는 로그를 전달할 외부 로깅 도구에 대한 구성을 지정할 수 있습니다. 여러 서비스에 대한 자격 증명이 추가된 경우, 로그는 모든 서비스로 전송됩니다.

1. 목적지 선택
2. Datadog: 글로벌 엔드포인트; API 키만 필요합니다.
3. Grafana Loki: 고객이 호스팅하는 Loki; URL에 기본 인증(Basic Auth)을 포함할 수 있습니다.
4. Splunk (HEC): 다중 인스턴스; URL과 토큰이 모두 필요합니다.
5. 환경 변수 추가: 아래 변수를 커넥터 호스트 환경에 추가하십시오. 선택한 대상에 해당하는 변수만 사용하십시오.

Datadog

• TULIP_LOGGING_DATADOG_API_KEY=<사용자의_Datadog_API_키>

Grafana Loki

• TULIP_LOGGING_LOKI_URL=https://<user>:<password>@loki.your-domain.com/loki/api/v1/push
  (URL에 user:password를 포함하면 기본 인증(Basic auth)이 지원됩니다. — 선택 사항입니다.)

Splunk (HEC)

• TULIP_LOGGING_SPLUNK_URL=https://splunk.your-domain.com:8088/services/collector
• TULIP_LOGGING_SPLUNK_TOKEN=<your_splunk_hec_token>

1. 커넥터 호스트 재시작

새로운 환경 변수가 적용되도록 서비스를 다시 시작하십시오.

1. 전송 확인

작업(예: 커넥터 함수 실행)을 생성하고 로그가 대상 위치에 표시되는지 확인하십시오:

• Datadog: 호스트/서비스 이름에 대한 최근 로그를 확인합니다.
• Loki: Grafana Explore에서 호스트 레이블이나 알려진 메시지 부분 문자열을 기준으로 쿼리하십시오.
• Splunk: 해당 호스트의 최근 이벤트를 검색합니다(예: index=<your_index> source="tulip-connector-host").
• 로깅 변경 또는 비활성화
• 대상 위치를 변경하려면 변수를 새로운 제공업체로 업데이트하고(기존 변수는 제거하십시오).
• 로깅을 비활성화하려면 로깅 변수를 제거하고 서비스를 다시 시작하십시오.

추가 정보

Grafana Alloy 익스포터를 기반으로 한 구현:

Datadog 익스포터:https://grafana.com/docs/alloy/next/reference/components/otelcol/otelcol.exporter.datadog/

Splunk HEC 익스포터: https://grafana.com/docs/alloy/next/reference/components/otelcol/otelcol.exporter.splunkhec/

인바운드 및 아웃바운드 호출 부하

이 섹션에서는 OPCH가 Tulip Cloud로 전송하는 HTTP 요청의 수에 대해 설명합니다. 이러한 요청은 고정 속도 요청 (항상 실행됨)과 가변 속도 요청 (구성 및 활동에 따라 달라짐)으로 분류할 수 있습니다.

고정 빈도 요청

이러한 요청은 일정하고 예측 가능한 빈도로 발생합니다:

변동 빈도의 요청

이러한 요청은 구성 및 활동에 따라 달라집니다.
변경 사항이나 이벤트가 많이 발생할수록 요청 빈도가 높아집니다.

계산 예시

다음과 같은 설정을 가정해 봅시다:- 머신 데이터 소스 1개- 500개의 머신 속성, 각 속성이 1Hz (초당 1회)로 데이터를 보고함

최악의 경우 요청 빈도:`빈도(최악의 경우) = (6 + 1 + 20) + 40 + 60 + 240 = 367 요청/분

추가 참고 자료

Docker에 대한 로그 회전 활성화

Docker 로그 회전을 사용하지 않는 기존 온프레미스 Connector Hosts 의 경우, 디스크 공간이 적절하게 관리되도록 여기에서 설명된 지침을 따르십시오.

OPCH 상태 확인

OPCH를 Azure 또는 Kubernetes 기반 서비스 오케스트레이터와 통합하려면 다음 구성을 사용할 수 있습니다.

LTS16 이상 OPCH의 경우:

OPCH를 Azure 또는 Kubernetes 기반 서비스 오케스트레이터와 통합하려면 다음 구성을 사용할 수 있습니다. 상태 확인 엔드포인트는 임의의 포트에 할당되며 루트 경로 /health-check에서 노출됩니다. 선택적으로 TULIP_HEALTH_HTTP_PORT를 지정된 포트로 설정하여 할당된 포트를 재정의할 수 있습니다. 예: TULIP_HEALTH_HTTP_PORT = 80. 응답이 성공하면 HTTP 상태 코드 204가 반환되며, 이는 OPCH 서비스가 정상적으로 작동 중임을 나타냅니다.

LTS16 이전 버전의 OPCH의 경우:

OPCH를 Azure 또는 Kubernetes 기반 서비스 오케스트레이터와 통합하려면 다음 구성을 사용할 수 있습니다. 헬스 체크 엔드포인트를 사용하려면 환경 변수 CONNECTORS_HEALTHZ_SERVER_ENABLED를 true로 설정해야 합니다.이 엔드포인트는 포트 9223에서 사용 가능하며 루트 경로 /에 노출됩니다. 선택적으로 CONNECTORS_PORT를 지정된 포트로 설정하여 기본 포트 9223을 재정의할 수 있습니다. 예: CONNECTORS_PORT = 80

성공적인 응답은 HTTP 상태 코드 200(OK)을 반환하며, 이는 OPCH 서비스가 정상적으로 작동하고 있음을 나타냅니다.
선택적으로 CONNECTORS_PORT를 지정된 포트로 설정하여 기본 포트 9223을 재정의할 수 있습니다. 예: CONNECTORS_PORT = 80

성공적인 응답 시 HTTP 상태 코드 200(OK)이 반환되며, 이는 OPCH 서비스가 정상적으로 작동하고 있음을 나타냅니다.

{{snippet.원하는 정보를 찾으셨나요?}}