Telepítsen egy helyszíni csatlakozó-kiszolgálót

Ismerje meg a Tulip-integrációkhoz szükséges helyszíni csatlakozó-hostok (OPCH) telepítésének, konfigurálásának és karbantartásának technikai lépéseit.

Ez a cikk technikai útmutató azok számára, akik az OPCH fizikai telepítéséért és életciklus-kezeléséért felelősek. A csatlakozó-gazdagép egy olyan szolgáltatás, amely megkönnyíti a kapcsolatok létrehozását

külső webszolgáltatásokhoz, adatbázisokhoz és OPC UA-kiszolgálókhoz. Minden Tulip-példány alapértelmezés szerint rendelkezik Cloud Connector Hosttal.

Számos szempontot figyelembe kell venni annak eldöntésekor, hogy a helyszíni csatlakozó-gazdagép megfelelő-e az adott architektúrához.

Előfeltételek

Mielőtt továbbhaladna, győződjön meg arról, hogy ismeri a Tulip csatlakozó-hostok alapjait:* Csatlakozó-hostok* Helyi csatlakozó-hostok

Hálózat

A helyszíni csatlakozó-kiszolgáló telepítésének leggyakoribb indoka az a előny, amelyet a helyi hálózaton belül tárolt rendszerekhez való csatlakozás során nyújt. A helyszíni megoldásnál a Tulip és a külső rendszerek közötti összes kapcsolat a helyi hálózaton belülről indul. A hálózatából induló összes kapcsolat kifelé irányul a Tulip felé, biztonságos WebSocket-en keresztül.

Ez ellentétben áll a felhőalapú csatlakozó-kiszolgálókkal, amelyek bejövő hozzáférést igényelnek a szolgáltatásokhoz. Általában az IT-részleg dönti el, hogy engedélyezi-e a Tulip felhőjéből a szolgáltatás felé irányuló bejövő, biztonságos WebSocket-kapcsolatokat, gyakran a WAN-útválasztón/tűzfalon beállított port-átirányítási szabályok segítségével.

Helyi csatlakozó-kiszolgáló telepítése

Műszaki szabványok

Ha a helyszíni megoldás telepítése mellett döntenek, a Tulip egy elosztott Docker-képet használó önkiszolgáló megoldást javasol. Ennek megvalósítására a legegyszerűbb módszer egy Linux-disztribúcióval ellátott virtuális gép használata.

A Tulip azt is javasolja, hogy virtuális gépenként csak egy helyszíni csatlakozó-gazdagépet üzemeltessenek, hogy elkerüljék a telephelyek egyetlen hibaforrását.

A virtuális gép követelményei:

• RAM – 4 GB
• ROM – 8–16 GB lemezterület
• CPU – 2 mag
• Docker verzió – 20.10 vagy újabb

A hálózati követelmények tekintetében az On-Premise Connector Host a következőket tartalmazza:

• IP-cím
• DNS-feloldás a következő címre
• Kimenő hozzáférés a 443-as porton a Tuliphoz (az IP-címek itt találhatók)
• Kimenő hozzáférés a Docker-tárházhoz itt
• Kimenő hozzáférés minden releváns külső rendszerhez a megadott portokon keresztül

A hálózati követelmények teljes listáját itt tekintheti meg

Telepítés

A következő szakasz bemutatja, hogyan telepíthető egy helyszíni csatlakozó-gazdagép különböző környezetekben. Az AWS és az Azure egyaránt kínál olyan konténer szolgáltatásokat, amelyek képesek a Docker-kép futtatására.

AWS

Használja a webes felhasználói felületet és ezt az útmutatót: https://aws.amazon.com/getting-started/hands-on/deploy-docker-containers/

Azure (Bash): LTS16+ OPCH

az container create `-g <AZ AZURE-BEN LÉVŐ ERŐFORRÁS-CSOPORT NEVE> `--name <A KONTÉNER NEVE> `--cpu 2 `--memory 3 `--restart-policy Always `--public.ecr.aws/tulip/connector-host:<TAG>--os-type Linux `-e TULIP_UUID='<UUID>' `TULIP_FACTORY='https://<AZ ÖN WEBHELYE>.tulip.co' `TULIP_MACHINE_SECRET='<TITKOS KÓD>' `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 előtti OPCH

az container create `-g <AZ AZURE-BEN LÉVŐ ERŐFORRÁS-CSOPORT NEVE> `--name <A KONTÉNER NEVE> `--cpu 2 `--memory 3 `--restart-policy Always `--public.ecr.aws/tulip/connector-host:<TAG> `--os-type Linux `-e TULIP_UUID='<UUID>' `TULIP_FACTORY='https://<AZ ÖN WEBHELYE>.tulip.co' `TULIP_MACHINE_SECRET='<TITKOS KÓD>' `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 előtti verzió

 --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 előtti 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>

Tanúsítványhibák elhárítása

Ha az OPCH nem indul el, és „önaláírt tanúsítvány a tanúsítványláncban” hibát jelez, az oka az lehet, hogy a vállalati proxy/tűzfal egyedi tanúsítványai megakadályozzák a biztonságos kapcsolatot a Tulip Clouddal.

Tünetek: – Az OPCH „Never seen” (Még nem látott) állapotot jelenít meg – A folyamat az indítás során leáll – SSL-tanúsítványlánc-hibák a naplófájlokban

A probléma megoldásához az OPCH indításakor az alábbi környezeti változóval hivatkozhat további tanúsító hatóságokra. Fontos megjegyezni, hogy a fájlnak a Docker-konténerben kell lennie.

LTS16 előtti OPCH-verziók esetén: -e CONNECTORS_EXTRA_TRUSTED_CAS_FROM_FILES='["/etc/tulipCa/ca.pem"]'

LTS16-os vagy újabb OPCH esetén: -e TULIP_CONNECTORS_EXTRA_TRUSTED_CAS_FROM_FILES='["/etc/tulipCa/ca.pem"]'

Helyi csatlakozó-gép frissítése

:::(Figyelem) (Lehet, hogy az Edge IO-t is frissíteni kell)
Az OPCH futtatható az Edge IO eszközökön. Ha az eszközön nincs engedélyezve az automatikus frissítés, akkor azt manuálisan kell elvégezni.

Ha ez a figyelmeztető sáv az összes OPCH-frissítés befejezése után is megjelenik, kérjük, győződjön meg arról, hogy az Edge IO -je is frissítve lett.
:::

A Tulip az On-Premise Connector Host frissítéseit a hosszú távú támogatásra (LTS) vonatkozó kiadási ütemtervnek megfelelően bocsátja ki. A szolgáltatás frissítéséhez kövesse az alábbi utasításokat:

Az OPCH frissítési folyamata leállási időt eredményez, mivel a pod leáll és újra létrehozásra kerül.

1. Szerezze be az On-Premise Connector Host Docker-kép legújabb verzióját.

   docker pull public.ecr.aws/tulip/connector-host:<TAG>2. Futtassa az alábbi parancsot a Docker-konténer azonosítójának lekéréséhez.

   docker ps3. Ha rendelkezik a TULIP_FACTORY, a TULIP_UUID és a TULIP_MACHINE_SECRET értékekkel, folytassa a 4. lépéssel. Ha nem, futtassa a következő parancsot, és a parancs kimenetét tárolja biztonságos helyen.

   docker exec <container-id> env4. Állítsa le a meglévő Docker-konténert.

   docker stop <container-id>5. Távolítsa el a meglévő Docker-konténert.

   docker rm <container-id>6. Futtassa a szokásos Docker run parancsot a tárolt hitelesítő adatok felhasználásával.

LTS16+ OPCH esetén: 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 előtti OPCH esetén: 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. Ellenőrizze, hogy az új Docker-konténer aktív-e.

   docker ps

Használja a csatlakozó környezeteit a frissítés teszteléséhez

Minden csatlakozónak három különböző környezete van (termelés, előkészítés és fejlesztés), és ezeknek a környezeteknek mindegyike rendelkezhet saját csatlakozó-géppel, amelyek különböző verziójúak lehetnek. Az alkalmazás állapotától (fejlesztési verzió, jóváhagyásra vár, közzétett) függően különböző környezet használható.A csatlakozó-gazdagép érvényesítésének várható folyamata a következő: 1. Frissítse a fejlesztési OPCH-t. 2. Frissítse az érvényesítési csatlakozó-gazdagépet (a pre-production környezet itt a dev-re mutat). 1. Tesztelje a csatlakozót a csatlakozók oldalon vagy az alkalmazás fejlesztési módjában. 3. Amikor az érvényesítési tesztelés befejeződött, frissítse a termelési csatlakozó-gazdagépet.

További információkért lásd a Csatlakozó-környezetek című részt.

Alternatív megoldásként frissítheti az OPCH-t a fejlesztési példányán, majd nyugodtan frissítheti a termelési környezetet.

Naplózás külső naplókezelő eszközökbe

A helyszíni csatlakozó-gazdagép naplóit továbbíthatja harmadik féltől származó eszközökhöz a központosított felügyelet és hibaelhárítás érdekében. Az OPCH környezeti változók segítségével támogatja a Datadog, a Grafana Loki és a Splunk használatát. A rendelkezésre álló napló típusok az OPCH állapotához (különösen a gyárral való kapcsolatához), a csatlakozóhívások végrehajtásához és az előfizetési naplókhoz kapcsolódnak. Az OPCH indítási folyamatának részeként a felhasználók megadhatják a külső naplózóeszköz konfigurációját, ahová a naplókat továbbítani szeretnék. Ha több szolgáltatás hitelesítő adatait adják meg, a naplók az összes szolgáltatáshoz elküldésre kerülnek

1. Válassza ki a célhelyet
2. Datadog: Globális végpont; csak API-kulcsra van szükség.
3. Grafana Loki: Ügyfél által üzemeltetett Loki; az URL tartalmazhat alapvető hitelesítést.
4. Splunk (HEC): Több példány; URL-re és tokenre is szükség van.
5. Környezeti változók hozzáadása: Adja hozzá az alábbi változókat a csatlakozó gazdagép környezetéhez. Csak a választott célhelyhez tartozókat használja.

Datadog

• TULIP_LOGGING_DATADOG_API_KEY=<a_Datadog_API-kulcsa>

Grafana Loki

• TULIP_LOGGING_LOKI_URL=https://<user>:<password>@loki.your-domain.com/loki/api/v1/push
  (Az alapvető hitelesítés támogatott, ha a felhasználónevet és a jelszót beágyazza az URL-be — opcionális.)

Splunk (HEC)

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

1. Indítsa újra a csatlakozó gazdagépet

Indítsa újra a szolgáltatást, hogy az új környezeti változók hatályba lépjenek.

1. Ellenőrizze az átvitelt

Hozzon létre tevékenységet (pl. futtasson egy csatlakozó funkciót), és ellenőrizze, hogy a naplófájlok megjelennek-e a célhelyen:

• Datadog: Ellenőrizze a legutóbbi naplóbejegyzéseket a gazdagép/szolgáltatás neve alapján.
• Loki: Keressen a Grafana Explore-ban a gazdagép címkéje vagy egy ismert üzenet részszövege alapján.
• Splunk: Keresse meg a gazdagépről származó legutóbbi eseményeket (pl.: index=<your_index> source="tulip-connector-host").
• A naplózás módosítása vagy letiltása
• A célhelyek közötti váltáshoz frissítse a változókat az új szolgáltatóra (és távolítsa el a régieket).
• A letiltáshoz távolítsa el a naplózási változókat, majd indítsa újra a szolgáltatást.

További információk

A Grafana Alloy exportálókra épülő megvalósítás:

Datadog exportáló:https://grafana.com/docs/alloy/next/reference/components/otelcol/otelcol.exporter.datadog/

Splunk HEC exportáló: https://grafana.com/docs/alloy/next/reference/components/otelcol/otelcol.exporter.splunkhec/

Bejövő és kimenő hívásterhelés

Ez a szakasz elmagyarázza, hogy az OPCH hány HTTP-kérelmet küld a Tulip Cloudnak. Ezek a kérelmek két csoportba sorolhatók: fix gyakoriságú kérelmek (mindig futnak) és változó gyakoriságú kérelmek (a konfigurációtól és a tevékenységtől függően).

Állandó gyakoriságú kérések

Ezek a kérések állandó, előre jelezhető gyakorisággal jelentkeznek:

Változó gyakoriságú lekérdezések

Ezek a lekérdezések a konfigurációtól és a tevékenységtől függenek.
Minél több változás vagy esemény történik, annál magasabb a kérések aránya.

Számítási példa

Vegyünk egy olyan konfigurációt, amelyben: - 1 gépi adatforrás- 500 gépi attribútum, amelyek mindegyike 1 Hz-es frekvenciával (másodpercenként egyszer) jelent adatokat

Legrosszabb esetben várható kérelemfrekvencia:`Frekvencia (legrosszabb eset) = (6 + 1 + 20) + 40 + 60 + 240 = 367 kérelem/perc

További hivatkozások

A naplórotáció engedélyezése a Docker esetében

A Docker naplórotációt nem használó, meglévő helyszíni Connector Hosts esetében kövesse az itt dokumentált utasításokat a lemezterület megfelelő fenntartásának biztosítása érdekében.

Az OPCH állapotának ellenőrzése

Az OPCH integrálásához az Azure- vagy Kubernetes-alapú szolgáltatás-koordinátorral a következő konfigurációt használhatja:

LTS16+ OPCH esetén:

Az OPCH integrálásához az Azure- vagy Kubernetes-alapú szolgáltatás-koordinátorral a következő konfigurációt használhatja: Az állapotellenőrzési végpont véletlenszerűen kerül hozzárendelésre egy porthoz, és a /health-check gyökérútvonalon érhető el. Opcionálisan a kijelölt port felülírható úgy, hogy a TULIP_HEALTH_HTTP_PORT változót a megadott portra állítja be. Például: TULIP_HEALTH_HTTP_PORT = 80. A sikeres válasz 204-es HTTP-állapotkódot ad vissza, jelezve, hogy az OPCH-szolgáltatás megfelelő állapotban van és működőképes.

LTS16 előtti OPCH esetén:

Az OPCH Azure- vagy Kubernetes-alapú szolgáltatás-koordinátorba történő integrálásához a következő konfigurációt használhatja: Az állapotellenőrzési végpontot a CONNECTORS_HEALTHZ_SERVER_ENABLED környezeti változó true értékre állításával kell engedélyezni.A végpont a 9223-as porton érhető el, és a / gyökérkönyvtárban található. Opcionálisan az alapértelmezett 9223-as port felülírható a CONNECTORS_PORT változó beállításával a megadott portra. Például: CONNECTORS_PORT = 80

Sikeres válasz esetén a rendszer 200-as (OK) HTTP-állapotkódot ad vissza, jelezve, hogy az OPCH-szolgáltatás rendben van és működőképes.
Opcionálisan az alapértelmezett 9223-as port felülírható a CONNECTORS_PORT beállításával a kívánt portra. Például: CONNECTORS_PORT = 80

Sikeres válasz esetén a rendszer 200-as (OK) HTTP-állapotkódot ad vissza, jelezve, hogy az OPCH-szolgáltatás rendben van és működik.

{{snippet.Megtalálta, amit keresett?}}