Häufig gestellte Fragen

Sind die Kosten für die Relay-Rechenressourcen im Service Satellite enthalten?

Die IBM Cloud-Ressourcen, die für das Relay und Satellite verwendet werden, werden separat in Rechnung gestellt.

Fallen zusätzliche Gebühren für den Zugriff auf IBM Cloud-Services über Direct Linkan?

Nein, es fallen keine zusätzlichen Gebühren für den Zugriff auf Services über Direct Linkan.

Warum benötige ich Direct Link?

Standardmäßig wird der ausgehende Datenverkehr von Ihrem Standort zu den IBM Cloud-Diensten über das öffentliche Internet geleitet. Wenn Sie Direct Link nutzen, wird der ausgehende Datenverkehr von Ihrem Standort über Direct Link geleitet, anstatt das öffentliche Internet zu nutzen.

Meine Organisation inaktiviert den Internetzugriff durch Design. Kann ich Standorte und Hosts, die mit Direct Linkverbunden sind, erstellen und verwalten?

Wenn Sie über Direct Linkverfügen, können Sie es für Satellite-Services verwenden. Mit Direct Linkkönnen Sie Standorte erstellen und Hosts ohne Zugriff auf das öffentliche Internet zuordnen.

Kann ich RHEL-Hosts verwenden, um Direct Linkeinzurichten?

Nein. Sie müssen sowohl über einen RHCOS-fähigen Standort verfügen als auch RHCOS-Hosts an Ihrem Standort verwenden, um Direct Linkverwenden zu können.

Kann ich den gesamten Datenverkehr an IBM Cloud über Direct Link anstelle des Internets umleiten?

Derzeit unterstützen nicht alle Services Direct Link. Ob der gesamte Datenverkehr Direct Link nutzen kann, hängt davon ab, welche Dienste Sie verwenden. Überprüfen Sie die Dokumentation der jeweiligen Dienste, um deren Konnektivitätsanforderungen zu ermitteln.

Auf welche IBM Cloud-Services kann ich über Direct Link zugreifen, um den Zugriff über das Internet zu vermeiden?

Nachdem Sie diese Anweisungen befolgt haben, werden Satellite und OpenShift auf Satellite über Direct Link funktionieren. Wenn zusätzliche Dienste in einer Satellite-Umgebung bereitgestellt werden, überprüfen Sie die Dokumentation der einzelnen Dienste auf deren Konnektivitätsanforderungen, da einige Dienste einen öffentlichen Internetzugang erfordern.

Wenn ich zwei Standorte habe, die Direct Linkverwenden, kann ich sie verwenden, damit Direct Link von einem Standort zum anderen übernommen wird?

Diese Funktion ist noch nicht verfügbar.

Wie kann ich die Kapazität von Direct Link für meinen Standort festlegen?

Es gibt keine zusätzlichen Dimensionierungsanforderungen für die Verwendung von Direct Link. Sie können also Ihren Standort wie einen normalen Standort dimensionieren, d. h. basierend auf den Services, die Sie verwenden.

Kann ich mit einem Klick alles bereitstellen, was zur Aktivierung von Direct Link erforderlich ist, um manuelle Fehler zu vermeiden?

Derzeit ist keine Implementierung mit einem Klick für Direct Link verfügbar.

Zielanwendungsfall

Kunden, die aktuell Direct Link zwischen IBM und lokalen oder anderen öffentlichen Clouds verwenden, können sie weiterhin für Satellite verwenden. Dies ermöglicht Kunden Folgendes:

• Zugriff auf Services in IBM Cloud von einer Satellite-Position über Direct Link; Beispiele sind Sicherungen in IBM Cloud® Object Storage, das Senden von Metriken an IBM Cloud Monitoring, das Verfolgen von Ereignissen in IBM Cloud Activity Trackeroder das Senden von Protokollen an IBM Cloud Log Analysis.
• Zugriff auf Services, die an einer Satellite-Position von IBM Cloudausgeführt werden.
• Zugriff auf öffentliche Cloud-Services außerhalb von IBM Cloud.

Auf diese können Sie mithilfe von Satellite-Endpunktadressen zugreifen, die erstellt wurden, um Datenverkehr über Direct Link anstelle des Internets weiterzuleiten.

Dies verhindert, dass sensible Daten des Kunden über das öffentliche Internet übertragen werden, z. B. Protokollierung, Backups oder Daten zwischen integrierten Services in der Hybrid-Cloud-Umgebung. Dies trägt auch zur Optimierung von Ingress-/Egress-Gebühren bei.

Übersicht

Standardmäßig leiten zwei Satellite-Link-Komponenten – der Tunnel-Server und der Connector – den Netzwerkverkehr zwischen IBM Cloud und den Ressourcen an Ihrem Satellite-Standort über eine sichere TLS-Verbindung weiter. Dieses Dokument behandelt den Anwendungsfall der Nutzung einer TLS-Verbindung über Direct Link.

Bei dieser Konfiguration wird der private Cloud-Serviceendpunkt des Tunnelservers verwendet, um Datenverkehr über das private Netz IBM Cloud weiterzuleiten (siehe 166.9.0.0/8 Servicenetz. Die Kommunikation mit dem privaten Cloud-Serviceendpunkt des Tunnelservers muss jedoch über 166.9.X.X/16-IP-Adressbereich im privaten IBM Cloud-Netz, der nicht von IBM Cloud Direct Linkweitergeleitet werden kann

Um den Zugriff auf den 166.9.X.X/16-Bereich zu aktivieren, erstellen Sie ein Relay in Ihrem IBM Cloud-Konto, das eingehenden Proxy-Datenverkehr zum Endpunkt des privaten Cloud-Service des Tunnelservers umkehrt. Standardmäßig hat Relay Ingress eine IP-Adresse im internen 10.X.X.X/8-IP-Adressbereich, auf die über eine Direct Link-Verbindung zugegriffen werden kann.

Das folgende Diagramm veranschaulicht den Datenfluss.

1. Netzverkehr, der von Ihrem Standort stammt, z. B. eine Anforderung von einem IBM Cloud Satellite-Cluster an einen IBM Cloud-Service, wird über den Link-Service über Direct Link an den privaten Relay-Ingress weitergeleitet, der über eine über direkte Verbindungen weiterleitbare Adresse verfügt.
2. Das Relay leitet eine neue Sitzung ein, um die Anforderung an den privaten Cloud-Serviceendpunkt des Tunnelservers weiterzuleiten, der an eine IP-Adresse im Bereich 166.9.X.X/16 (Link private Adresse) endet.

Ziele

Sie können Red Hat- CoreOS-fähige Standorte erstellen, ohne auf das öffentliche Internet zugreifen zu müssen. Der gesamte Datenverkehr wird von Direct Link abgewickelt und bleibt intern.

Zu den übergeordneten Schritten gehören:

1. Erstellen Sie eine Red Hat CoreOS aktivierte Satellite Position mit Ihrem IBM Cloud-Konto, das Ihre Direct Linkbeendet.
2. Erstellen Sie ein Relay, bei dem es sich um einen Reverse Proxy handelt, der http/https und sicheres Websocket unterstützt.
3. Bereitstellung v Red Hat- CoreOS-Hosts. Passen Sie die Hosts an, indem Sie das Zündscript verwenden, das als Anhangscript für die in Schritt 1 erstellte Position heruntergeladen wird.

Voraussetzungen

• Sie müssen eine Position für Red Hat CoreOS aktiviert haben Satellite. Wenn Sie noch keine haben, befolgen Sie die Anweisungen unter Creating a Red Hat CoreOS enabled Satellite Location, um sie zu erstellen.
• Direct Link ist zwischen der Satellite-Zielposition und IBM Cloud-spezifischen VPC-oder klassischen Clustern verfügbar.
• Stellen Sie sicher, dass Ihre IBM Cloud Direct Link-Verbindung auf den IP-Adressbereich 10.X.X.X/8 zugreifen kann. Prüfen Sie den Netzentwurf, um IP-Konflikte zwischen zwei Enden von Direct Linkzu verhindern.
• Installieren Sie die IBM Cloud-CLI und Plug-ins und installieren Sie die Kubernetes-CLI(kubectl).
• Stellen Sie sicher, dass für Ihr IBM Cloud-Konto VRF (Virtual Router Function) für die Verwendung von Serviceendpunkten aktiviert ist.
• Stellen Sie sicher, dass Sie über die folgenden Zugriffsrichtlinien verfügen. Weitere Informationen finden Sie unter Benutzerberechtigungen überprüfen.
  • Administrator- IBM Cloud-Zugriffsrolle für die IAM-Plattform unter IBM Cloud Kubernetes Service
  • Administrator- IBM Cloud e IAM-Plattform-Zugriffsrolle für IBM Cloud Container Registry
  • Writer oder Manager IBM Cloud IAM-Servicezugriffsrolle für IBM Cloud Kubernetes Service
  • Administrator- IBM Cloud e IAM-Plattform-Zugriffsrolle für IBM Cloud Container Registry
  • Administrator- IBM Cloud-Zugriffsrolle für die IAM-Plattform für IBM Cloud Satellite
  • Manager IBM Cloud IAM-Servicezugriffsrolle für IBM Cloud Satellite
  • Administrator- IBM Cloud-Zugriffsrolle für die IAM-Plattform für Object Storage
  • Schreibberechtigter oder Manager IBM Cloud IAM-Plattformzugriffsrolle für IBM Cloud Object Storage
  • Administrator- IBM Cloud-IAM-Plattform-Zugriffsrolle für IBM Cloud Certificate Manager
  • Schreibberechtigter oder Manager IBM Cloud IAM-Plattformzugriffsrolle für IBM Cloud Certificate Manager
  • Anzeigeberechtigter IBM Cloud IAM-Plattformzugriffsrolle für die Ressourcengruppe, die Sie mit Satellite
  • Manager IBM Cloud IAM-Servicezugriffsrolle für IBM Cloud Schematics
• Stellen Sie gezielt einen Kubernetes-Cluster bereit und richten Sie darin einen NGINX-Reverse-Proxy ein, um an die Endpunkte Direct Link weiterzuleiten.

Position von Red Hat CoreOS aktiviert Satellite erstellen

Sie können diesen Schritt überspringen, wenn Sie bereits über einen Red Hat CoreOS verfügen, der für den Standort Satellite aktiviert ist.

Melden Sie sich bei Ihrem IBM Cloud-Konto an, das über Direct Link verfügt, und erstellen Sie einen Red Hat-Standort unter CoreOS mit aktivierter Satellite-Funktion. Weitere Informationen finden Sie unter Satellite-Standort erstellen.

Relay erstellen

Das Relay ist ein HTTP-/HTTPS-Reverse-Proxy, der sichere WebSocket-Verbindungen unterstützt. Es kann auf VSI, Red Hat OpenShift oder IBM Cloud Kubernetes Service als Classic oder VPC ausgeführt werden. Die folgenden Schritte zeigen ein Beispiel für die Bereitstellung eines Reverse-Proxys NGINX in einem ausschließlich privaten VPC- Red Hat OpenShift-Cluster (auf privaten VPC-Knoten).

Eine wichtige Voraussetzung ist ein gültiger Name, der dem privaten Ingress des Clusters (Relay Ingress) zugeordnet werden kann, und ein gültiges Zertifikat auf IBM Cloud. In IBM Cloud, VPC-Clustern Red Hat OpenShift auf privaten Knoten werden private Standardhostnamen und -zertifikate bereitgestellt. Sie können sie verwenden oder Ihren angepassten Hostnamen und Ihr Zertifikat verwenden. In diesem Beispiel werden der private Standardhostname und die Zertifikate verwendet.

Hinweise zu VPC-Clustern für dieses Szenario:

• Zone: Jede mehrzonenfähige VPC-Zone
• Workerknotentyp: Beliebiger Typ der VPC-Infrastruktur
• Version: 4.x.x
• Worker-Pool: Mindestens 2 Workerknoten
• Subnetze: Fügen Sie IP-Subnetze des Ingress Load Balancer ein, wenn die Standardbereiche mit den Werten --pod-subnet und --service-subnet des Clusters Red Hat OpenShift auf Satellite oder dem Netzwerk-CIDR, in dem die Hosts Satellite oder Red Hat OpenShift vor Ort bereitgestellt werden, in Konflikt stehen.
• Cloud-Service-Endpunkte: Geben Sie die Option --disable-public-service-endpoint nicht an, wenn Sie sowohl öffentliche als auch private Endpunkte verwenden möchten.
• Verteilen Sie den Standard-Worker-Pool über mehrere Zonen, um die Verfügbarkeit Ihres klassischen oder VPC-Clusters zu erhöhen.
• Stellen Sie sicher, dass mindestens zwei Workerknoten in jeder Zone vorhanden sind, sodass die privaten ALBs, die Sie in nachfolgenden Schritten konfigurieren, hoch verfügbar sind und ordnungsgemäß Versionsaktualisierungen empfangen können.

Im folgenden Beispiel werden standardmäßig ein privater VPC-Cluster und ein privater Ingress-Controller erstellt. Sie können jedoch auch einen Red Hat OpenShift-Cluster mit aktiviertem Endpunkt für einen Public-Cloud-Dienst verwenden; in diesem Fall wird Ihr Cluster standardmäßig jedoch nur mit einem öffentlichen Ingress-Controller erstellt. Wenn Sie Ihr Relay mithilfe eines Clusters mit einem öffentlichen Serviceendpunkt einrichten möchten, müssen Sie zuerst den privaten Ingress-Controller aktivieren und ihn mit einer Unterdomäne und einem Zertifikat registrieren, indem Sie die Schritte unter Ingress einrichten ausführen.

1. Erstellen Sie einen reinen privaten Red Hat OpenShift-Cluster auf VPC. Weitere Informationen finden Sie unter VPC-Cluster erstellen.

   Es gibt viele Möglichkeiten, Apps in einem Red Hat OpenShift-Cluster in einer VPC bereitzustellen. In diesem Beispiel wird die App ausschließlich über private Endpunkte privat bereitgestellt – dies ist der häufigste Anwendungsfall für Kunden von Direct Link. Red Hat OpenShift-Cluster, die ausschließlich über private Endpunkte privat bereitgestellt werden, verfügen standardmäßig über einen privaten Namen und ein Zertifikat. Sie werden in diesem Beispiel verwendet, um die Reverse-Proxy-Pods von NGINX bereitzustellen. Sie können die Standardnamen verwenden oder Ihren angepassten Hostnamen und Ihr Zertifikat verwenden. Weitere Informationen finden Sie unter Apps in VPC-Clustern mit einem privaten Cloud-Serviceendpunkt privat zugänglich machen.

2. Erstellen Sie eine Secret Manager-Instanz und registrieren Sie sie im Red Hat OpenShift-Cluster, das im vorherigen Schritt erstellt wurde. Weitere Informationen finden Sie unter Serviceinstanz von Secrets Manager erstellen.

3. Rufen Sie die Ingress-Details von Direct Linkab.

   ibmcloud oc cluster get --cluster CLUSTER_NAME_OR_ID | grep Ingress
   

   Beispielausgabe:

   Ingress Subdomain:      mycluster-i000.us-south.containers.appdomain.cloud
   Ingress Secret:         mycluster-i000
   

   Wenn Sie in diesem Szenario den Befehl nslookup für die Ingress-Subdomain ausführen, wird diese auf die private IP-Adresse des IBM-Dienstes (10.0.0.0/8) aufgelöst. Das Hinzufügen von Routen, um die Ingress-IP-Adresse (10.0.0.0/8) von der lokalen Umgebung des Kunden aus erreichbar zu machen, wird in diesem Dokument nicht behandelt. Sie sind dafür verantwortlich, das Routing zwischen der lokalen Umgebung und dem Ingress-Relay auf IBM Cloud zu ermöglichen.

4. Holen Sie sich die geheime CRN.

   ibmcloud oc ingress secret get -c CLUSTER --name SECRET_NAME --namespace openshift-ingress
   

5. Erstellen Sie einen Namespace für den Reverse-Proxy NGINX.

   kubectl create ns dl-reverse-proxy
   

6. Kopieren Sie das Standard- TLS-Geheimnis von in openshift-ingress das Projekt, in dem NGINX bereitgestellt werden soll.

   ibmcloud oc ingress secret create --cluster CLUSTER_NAME_OR_ID --cert-crn CRN --name SECRET_NAME --namespace dl-reverse-proxy
   

7. Kopieren Sie den folgenden Inhalt der Ingress-Ressourcendatei in Ihr lokales Verzeichnis. Ersetzen Sie VALUE_FROM_INGRESS_SUBDOMAIN und VALUE_FROM_INGRESS_SECRET durch Ihre eigenen Werte.

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: dl-ingress-resource
     annotations:
       kubernetes.io/ingress.class: "public-iks-k8s-nginx"
       nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
       nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"
   spec:
     tls:
     - hosts:
       - satellite-dl.VALUE_FROM_INGRESS_SUBDOMAIN
       secretName: VALUE_FROM_INGRESS_SECRET
     rules:
     - host: satellite-dl.VALUE_FROM_INGRESS_SUBDOMAIN
       http:
         paths:
         - path: /
           pathType: Prefix
           backend:
             service:
               name: nginxsvc
               port:
                 number: 80
   

8. Erstellen Sie Ingress.

   oc apply -f myingressresource.yaml -n <dl-reverse-proxy>
   

9. Rufen Sie den Namen des internen Ingress-Hosts des Tunnelservers Direct Link ab, indem Sie folgenden Befehl ausführen.

   ibmcloud sat endpoint ls --location LOCATION_ID
   

10. Notieren Sie in der Ausgabe den Positionsendpunkt. Ersetzen Sie c-01, c-02 oder c-03 durch d-01-ws, d-02-ws oder d-03-ws und entfernen Sie den Port. Beispiel: c-01.private.us-south.link.satellite.cloud.ibm.com:40934 wird zu d-01-ws.private.us-south.link.satellite.cloud.ibm.com. Dieser Wert kann als Wert für proxy_pass https in der Datei ConfigMap verwendet werden.

11. Kopieren Sie den Inhalt der Datei NGINX ( ConfigMap ) in Ihr lokales Verzeichnis. Bei dieser Konfiguration wird entweder ein WS-Reverse-Proxy oder ein HTTPS-Reverse-Proxy auf den Endpunkt Direct Link des Tunnel-Servers angewendet. Ersetzen Sie VALUE_FROM_INGRESS_SUBDOMAIN und VALUE_FOR_PROXY_PASS durch Ihre eigenen Werte.

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: confnginx
    data:
      nginx.conf: |
        user  nginx;
        worker_processes  1;
        error_log  /var/log/nginx/error.log warn;
        events {
            worker_connections  4096;
        }
        http {
          include       /etc/nginx/mime.types;
          default_type  application/octet-stream;
          log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                              '$status $body_bytes_sent "$http_referer" '
                              '"$http_user_agent" "$http_x_forwarded_for"';
          access_log  /var/log/nginx/access.log  main;
          sendfile        on;
          keepalive_timeout  65;
          server_names_hash_bucket_size  128;
          server {
            listen 80;
            server_name VALUE_FROM_INGRESS_SUBDOMAIN;
            proxy_connect_timeout 180;
            proxy_send_timeout 180;
            proxy_read_timeout 180;
            location /ws {
              proxy_pass https://VALUE_FOR_PROXY_PASS;
              proxy_ssl_server_name on;
              proxy_http_version 1.1;
              proxy_set_header Upgrade $http_upgrade;
              proxy_set_header Connection "upgrade";
            }
            location / {
              proxy_pass https://VALUE_FOR_PROXY_PASS;
            }
          }
        }
    

12. Kopieren Sie die Bereitstellungsdatei NGINX.

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nginx
      labels:
        app: nginx
    spec:
      selector:
        matchLabels:
          app: nginx
      replicas: 2
      template:
        metadata:
          labels:
            app: nginx
      spec:
        containers:
          - name: nginx
            image: nginx:alpine
            ports:
            - containerPort: 80
            volumeMounts:
              - name: nginx-config
                mountPath: /etc/nginx/nginx.conf
                subPath: nginx.conf
        volumes:
          - name: nginx-config
            configMap:
              name: confnginx
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: nginxsvc
      labels:
        app: nginx
    spec:
      type: NodePort
      ports:
      - port: 80
        protocol: TCP
        name: http
      - port: 443
        protocol: TCP
        name: https
      - port: 8080
        protocol: TCP
        name: tcp
      selector:
        app: nginx
    

13. Erstellen Sie die ConfigMap der NGINX (dl-reverse-proxy).

    oc apply -f confnginx.yaml -n dl-reverse-proxy
    

14. Legen Sie das richtige Profil scc fest und erstellen Sie die NGINX (dl-reverse-proxy).

    oc adm policy add-scc-to-user anyuid system:serviceaccount:dl-reverse-proxy:default
    oc apply -f nginx-app.yaml -n dl-reverse-proxy
    

15. Überprüfen Sie noch einmal, ob der NGINX läuft, indem Sie die Pods auflisten.

    oc get pods
    

    NAME                     READY   STATUS    RESTARTS   AGE
    nginx-757fbc9f85-gv2p6   1/1     Running   0          53s
    nginx-757fbc9f85-xvmrj   1/1     Running   0          53s
    

16. Überprüfen Sie die Protokolle.

    oc logs -f nginx-757fbc9f85-gv2p6
    

    /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
    /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
    /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
    10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
    10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
    /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
    /docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
    /docker-entrypoint.sh: Configuration complete; ready for start up
    

17. Überprüfen Sie Ingress.

    oc get ingress
    

    NAME                  CLASS    HOSTS                                                                                                       ADDRESS                                                                                                     PORTS     AGE
    dl-ingress-resource   <none>   mysatellite-dl.myname-cluster10-22bfd3cd491bdeb5a0f661fb1e2b0c44-0000.us-south.containers.appdomain.cloud   router-default.myname-cluster10-22bfd3cd491bdeb5a0f661fb1e2b0c44-0000.us-south.containers.appdomain.cloud   80, 443   19m
    

18. Verbinden Sie sich mit der URL.

    curl -k https://mysatellite-dl.myname-cluster10-22bfd3cd491bdeb5a0f661fb1e2b0c44-0000.us-south.containers.appdomain.cloud
    

    {"status":"UP"}
    

Umleitung des Datenverkehrs zur Verwendung des Direct Link Pfad

Nun, da das Relay bereit ist, eingehenden Datenverkehr an den internen Ingress des Tunnelservers weiterzuleiten, können Sie Ihren Standorthost oder Connector so einrichten, dass er seinen Datenverkehr über das Relay umleitet. Dadurch wird sichergestellt, dass der gesamte Datenverkehr auf dem Direct Link in Ihrem privaten Netzwerk bleibt und kein Datenverkehr über das öffentliche Internet läuft.

Leiten Sie den Datenverkehr für Ihren Connector-Agenten oder Standort-Host um, indem Sie die entsprechenden Anweisungen unten befolgen.