Ziele

• Verstehen Sie die Konzepte hinter einem VPC-basierten Hub-and-Spoke-Modell.
• Machen Sie sich mit der Implementierung eines Firewall-Routers und einer Transit-VPC-Umgebung vertraut.
• Machen Sie sich mit VPC-Ingress-und Egress-Routing vertraut.
• Asymmetrische Routing-Probleme identifizieren und optional beheben.
• Verbinden Sie VPCs über Transit Gateway.

Vorbereitende Schritte

Für dieses Lernprogramm ist Folgendes erforderlich:

• terraform zur Bereitstellung von Ressourcen mithilfe von IaC (Infrastructure as Code)
• python zum optionalen Ausführen der pytest-Befehle
• Wenn Sie einen Firewall-Router implementieren, müssen Sie IP-Spoofing-Prüfungen aktivieren.
• Ein SSH-Schlüssel, um sich mit den virtuellen Servern zu verbinden. Wenn Sie keinen SSH-Schlüssel haben, folgen Sie den Anweisungen zum Erstellen eines Schlüssels für VPC.

In den Voraussetzungen finden Sie einige Optionen, einschließlich einer Dockerfile zum einfachen Erstellen der vorausgesetzten Umgebung.

Darüber hinaus:

• Überprüfen Sie die Benutzerberechtigungen. Stellen Sie sicher, dass Ihr Benutzerkonto über ausreichende Berechtigungen zum Erstellen und Verwalten aller Ressourcen in diesem Lernprogramm verfügt. Siehe die Liste von:
  • erforderliche Berechtigungen für VPC.
  • erforderliche Berechtigungen für die Erstellung von Transit Gateway
  • erforderliche Berechtigungen für IP-Spoofing-Prüfungen.

IP-Adresse und Teilnetzlayout

In diesem Schritt stellen Sie die VPC-Netzressourcen bereit. Planen Sie sorgfältig, indem Sie einen Adressierungsplan für eine VPC entwerfen und nicht überlappende CIDR-Blöcke verwenden.

Es ist verlockend, den CIDR-Bereich zuerst durch VPC aufzuteilen, aber dies erschwert das Routing. Stellen Sie sich stattdessen eine Verfügbarkeitszone als einen einzelnen CIDR-Block vor und jede VPC nutzt einen Ausschnitt davon.

Dieses Diagramm zeigt nur Zone 1 detaillierter. Die Teilnetzgrößen und das Layout sind in den anderen Zonen identisch:

Über dem Unternehmen befindet sich links und die IBM Cloud auf der rechten Seite. In der IBM Cloud für Simplictiy wird eine einzelne Zone für die Transit-VPC und Spoke 0 dargestellt. Beachten Sie, dass sich die CIDR-Blöcke nicht überschneiden und VPCs alle einen CIDR-Block in jeder Zone verbrauchen:

• Die lokale CIDR ist 192.168.0.0/16.
• Die Zonen in dieser Region mit mehreren Zonen sind 10.*.0.0/16. Die zweite Ziffer: 1, 2, 3 ist die Zonennummer (dargestellt für Dallas/us-south):
  • 10.10.1.0.0/16, Zone 1, Dallas 1, us-south-1.
  • 10.10.2.0.0/16, Zone 2, Dallas 2, us-south-2.
  • 10.10.3.0.0/16, Zone 3, Dallas 3, us-south-3.
• Die Transit-VPC verbraucht CIDRs 10.*.15.0/24:
  • 10.1.15.0/24, Zone 1
  • 10.2.15.0/24, Zone 2
  • 10.3.15.0/24, Zone 3
• Spoke 0 konsumiert 10.*.0.0/24 oder CIDRs:
  • 10.1.0.0/24, Zone 1
  • 10.2.0.0/24, Zone 2
  • 10.3.0.0/24, Zone 3.
• Die Teilnetz-CIDRs unterteilen /24 weiter in /26.

Die Teilnetze in Transit und Spoke sind für die verschiedenen Ressourcentypen bestimmt:

• worker-zugängliche Rechenressourcen VPC-Instanzen, Lastausgleichsfunktionen, Red Hat OpenShiftusw. In diesem Lernprogramm werden VPC-Instanzen demonstriert.
• dns- DNS Services Location Appliances, die in Teil 2 verwendet werden.
• vpe- VPE for VPC in Teil 2 verwendet.
• fw-firewall-router VPC-Instanzen (nur während der Übertragung).

VPC-Netzressourcen bereitstellen

1. Das zugehörige GitHub-Repository enthält die Quellendateien für die Implementierung der Architektur. Klonen Sie in einer Desktop-Shell das Repository:

   git clone https://github.com/IBM-Cloud/vpc-transit
   cd vpc-transit
   

2. Das Verzeichnis config_tf enthält Konfigurationsvariablen, die Sie konfigurieren müssen.

   cp config_tf/template.terraform.tfvars config_tf/terraform.tfvars
   

3. Bearbeiten Sie config_tf/terraform.tfvars und verwenden Sie die Kommentare in dieser Datei als Richtlinie.

4. Da es wichtig ist, dass jede Ebene in der richtigen Reihenfolge installiert wird und einige Schritte in diesem Lernprogramm mehrere Ebenen installieren, wird ein Shellbefehl ./apply.sh bereitgestellt. Die folgende Hilfe wird angezeigt:

   ./apply.sh
   

5. Sie können alle konfigurierten Ebenen anwenden, indem Sie ./apply.sh : : ausführen. Die Doppelpunkte sind Kurzform für erste (oder config_tf) und letzte (power_tf). Mit -p werden die Ebenen gedruckt:

   ./apply.sh -p : :
   

   Dabei handelt es sich um eine URL ähnlich der folgenden:

   directories: config_tf enterprise_tf transit_tf spokes_tf transit_spoke_tgw_tf test_instances_tf test_lbs_tf enterprise_link_tf firewall_tf transit_ingress_tf spokes_egress_tf all_firewall_tf all_firewall_asym_tf dns_tf vpe_transit_tf vpe_spokes_tf power_tf
   

6. Wenn Sie noch keinen haben, besorgen Sie sich einen Plattform-API-Schlüssel und exportieren Sie den API-Schlüssel zur Verwendung durch Terraform:

   export IBMCLOUD_API_KEY=YourAPIKEy
   

7. In diesem ersten Schritt gelten in config_tf, enterprise_tf, transit_tf, spokes_tf und transit_spoke_tgw_tf:

   ./apply.sh : transit_spoke_tgw_tf
   

Die VPCs und Teilnetze wurden erstellt. Die Transit-VPC und Peripherieserver wurden über eine bereitgestellte Transit Gatewayverbunden. Öffnen Sie Virtual Private Clouds im Browser. Öffnen Sie die Transit-VPC und notieren Sie die CIDR-Blöcke für Adresspräfixe und Teilnetze. Untersuchen Sie auch das Unternehmen und die Spoke-VPCs. Öffnen Sie Transit Gateway und klicken Sie auf das Transit Gateway, um die Verbindung zwischen den Transit-VPCs und den Spoke-VPCs anzuzeigen.

Testinstanzen erstellen

VPC Virtual Server-Instanzen, VSIs, werden zum Testen der Netzkonnektivität bereitgestellt. Eine Testinstanz wird zu jedem der Worker-Teilnetze (eines pro Zone) im Unternehmen, im Transit und in jedem der Spokes hinzugefügt. Wenn die Standardkonfiguration von 3 Zonen und 2 Spokes verwendet wird, dann werden 12 Instanzen bereitgestellt.

1. Testinstanzen erstellen

   ./apply.sh test_instances_tf
   

Es kann aufschlussreich sein, die bei jedem Schritt in der IBM Cloud-Konsole erstellten Ressourcen zu untersuchen. Öffnen Sie optional Virtual Private Clouds. Klicken Sie auf der linken Seite auf Virtuelle Serverinstanzen und beachten Sie die erstellten Instanzen.

Testen

In diesem Lernprogramm werden Kommunikationspfade nacheinander hinzugefügt. Eine pytest-Testsuite wird verwendet, um Kommunikationspfade umfassend zu testen. Am Ende des Lernprogramms wird erwartet, dass alle Tests bestanden werden.

Es ist nicht erforderlich, dass der Leser pytest verwendet, um die Ergebnisse zu überprüfen. Folgen Sie dem Lernprogramm, wenden Sie die Ebenen an und vertrauen Sie den im Lernprogramm beschriebenen Ergebnissen. Der Leser kann die VPC-Ressourcen wie VSIs, Teilnetze und Routentabellen nach ihrer Erstellung weiterhin untersuchen.

Jeder pytest-Test stellt eine SSH-Verbindung zu einer der Instanzen her und führt einen Typ von Konnektivitätstest aus, z. B. die Ausführung eines curl-Befehls für eine der anderen Instanzen. Die SSH-Standardumgebung wird für die Anmeldung bei den Instanzen verwendet. Wenn unerwartete Testergebnisse angezeigt werden, lesen Sie den Abschnitt pytest troubleshooting.

1. Führen Sie die curl-Tests der Zone 1 in der Suite mit dem Flag -m (Markierungen) aus. Wählen Sie die mit curl, lz1 (linke Zone 1) und rz1 (rechte Zone 1) markierten Tests aus.

   Ihre erwarteten Ergebnisse sind: Konnektivität innerhalb einer VPC, z. B. Unternehmen <-> Unternehmen wird BESTANDEN. Die Konnektivität zwischen Transit und Spokes wird Bestanden. Cross VPC from enterprise-> transit or spokes will be FEHLGESCHLAGEN.

   pytest -m "curl and lz1 and rz1"
   

   Unten sehen Sie ein Beispiel für eine Ausgabe:

   root@ea28970e0897:/usr/src/app# pytest -m "curl and lz1 and rz1"
   ===================================================== test session starts ======================================================
   platform linux -- Python 3.12.3, pytest-8.1.1, pluggy-1.4.0 -- /usr/local/bin/python
   cachedir: .pytest_cache
   rootdir: /usr/src/app
   configfile: pytest.ini
   testpaths: py
   plugins: xdist-3.5.0
   collected 36 items / 20 deselected / 16 selected
   
   py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-enterprise-z1-worker] PASSED                                   [  6%]
   py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-transit-z1-worker] FAILED                                      [ 12%]
   py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-spoke0-z1-worker] FAILED                                       [ 18%]
   py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-spoke1-z1-worker] FAILED                                       [ 25%]
   py/test_transit.py::test_curl[l-transit-z1-worker -> r-enterprise-z1-worker] FAILED                                      [ 31%]
   py/test_transit.py::test_curl[l-transit-z1-worker -> r-transit-z1-worker] PASSED                                         [ 37%]
   py/test_transit.py::test_curl[l-transit-z1-worker -> r-spoke0-z1-worker] PASSED                                          [ 43%]
   py/test_transit.py::test_curl[l-transit-z1-worker -> r-spoke1-z1-worker] PASSED                                          [ 50%]
   py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-enterprise-z1-worker] FAILED                                       [ 56%]
   py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-transit-z1-worker] PASSED                                          [ 62%]
   py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-spoke0-z1-worker] PASSED                                           [ 68%]
   py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-spoke1-z1-worker] PASSED                                           [ 75%]
   py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-enterprise-z1-worker] FAILED                                       [ 81%]
   py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-transit-z1-worker] PASSED                                          [ 87%]
   py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-spoke0-z1-worker] PASSED                                           [ 93%]
   py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-spoke1-z1-worker] PASSED                                           [100%]
   
   =================================================== short test summary info ====================================================
   FAILED py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-transit-z1-worker] - assert False
   FAILED py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-spoke0-z1-worker] - assert False
   FAILED py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-spoke1-z1-worker] - assert False
   FAILED py/test_transit.py::test_curl[l-transit-z1-worker -> r-enterprise-z1-worker] - assert False
   FAILED py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-enterprise-z1-worker] - assert False
   FAILED py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-enterprise-z1-worker] - assert False
   ========================================= 6 failed, 10 passed, 20 deselected in 38.76s =========================================
   

Eine Änderung an der Netzkonfiguration kann einige Testläufe dauern, damit das zugrunde liegende VPC-Netzsystem konsistent wird. Wenn die erwarteten Ergebnisse nicht angezeigt werden, müssen Sie den Test zunächst mehrmals erneut ausführen.

Die r- und l- stehen für r ight und l eft. Der mittlere Teil des Namens gibt Enterprise, Transit, spoke0, spoke1, ... an. z1, z2, ... geben die Zone an. Der Test stellt eine SSH-Verbindung zur linken Instanz her. Auf der linken Instanz wird die Verbindung zur rechten Instanz versucht. test_curl führt eine curl-Konnektivität für die linke Instanz zur rechten Instanz aus.

Zusammenfassend geht der Test test_curl[l-enterprise-z1 -> r-transit-z1] wie folgt vor:

1. Stellen Sie eine SSH-Verbindung zu einer Testinstanz in Unternehmenszone 1 her.
2. Führen Sie eine curl zu Transitzone 1 aus.
3. Bestätigen Sie, dass die Rückgabezeichenfolge die ID der Transitzone 1 enthält, die als erfolgreich oder fehlgeschlagen markiert werden soll.

Die Datei README.md im zugehörigen GitHub-Repository enthält weitere Details und den Quellcode.

Connect Enterprise to Transit über Direct Link und Transit Gateway

IBM Cloud® Direct Link mit Transit Gatewaybereitstellen.

IBM Cloud® Direct Link ist ein schneller sicherer Datenpfad für die Verbindung eines Unternehmens mit IBM Cloud. In diesem Lernprogramm wird Transit Gateway für die Verteilung verwendet. Die Verwendung von Transit Gateway ist für eine lokale Verbindung optional.

Das Unternehmen in diesem Lernprogramm wird mit einer anderen VPC simuliert. Wenn Sie dieses simulierte Unternehmen (tatsächlich eine andere VPC) über Transit Gateway verbinden, stellen Sie sicher, dass die Erfahrung mit Direct Linksehr nahe an der Erfahrung liegt, die Sie mit {{site.data.keyword.dl_short} erleben würden.

1. Wenden Sie die Schicht enterprise_link_tf an:

   ./apply.sh enterprise_link_tf
   

2. Führen Sie die curl-Tests für Zone 1 in der Suite my mit dem Flag -m (Markierungen) aus. Wählen Sie die mit curl, lz1 (linke Zone 1) und rz1 (rechte Zone 1) markierten Tests aus.

   Ihre erwarteten Ergebnisse sind: Konnektivität innerhalb einer VPC, Transit <-> Spoke (s), Unternehmen <-> Transit, Spoke (s) <-> Spoke (s) bestanden, aber Unternehmen <-> Spoke (s) nicht.

   pytest -m "curl and lz1 and rz1"
   

Verbindung zwischen Unternehmen und Spoke (s) über Transit NFV Firewall-Router

Das Incentive für eine Transit-VPC für Unternehmen <-> Clouddatenverkehr besteht in der Regel darin, Netzdatenverkehr weiterzuleiten, zu untersuchen, zu überwachen und zu protokollieren. In diesem Schritt wird eine Firewall-Router-Appliance in jeder Zone der Transit-VPC installiert.

NFV-Router

Stellen Sie die Firewall-Router-Appliances bereit. Eine Ingress-Routentabelle für {{site.data.keyword.tg_short}} wurde der Transit-VPC hinzugefügt, wie durch die gepunkteten Linien angegeben. In jeder Zone der Transit-VPC zur Aufnahme des Firewall-Routers wurde ein Teilnetz erstellt.

Die Konnektivität zwischen dem Unternehmen und einem Spoke wird über eine Network Function Virtualization, NFV, Firewall-Router-Instanz in der Transit-VPC erreicht. In der Produktion können Sie einen aus dem Katalog auswählen oder einen eigenen mitbringen. Bei dieser Demonstration wird ein Ubuntu-Image mit einem eingerichteten Kernel-iptables verwendet, um alle Pakete von der Quelle an das Ziel weiterzuleiten. In diesem Lernprogramm wird keine Firewallprüfung durchgeführt.

Die Terraform-Konfiguration konfiguriert die Firewall-Router-Instanz mit allow_ip_spoofing. Sie müssen IP-Spoofing-Prüfungen aktivieren, bevor Sie fortfahren.

1. Wenden Sie die Schicht firewall_tf an:

   ./apply.sh firewall_tf
   

2. Führen Sie die Testsuite aus.

   Ihre erwarteten Ergebnisse sind: Konnektivität innerhalb einer VPC, Enterprise-> Transit, Enterprise <-> sprach denselben Zonenpass. Aber alle Transit-> Spoke, alle Transit-> Unternehmen scheitern aufgrund asymmetrischer Routing-Probleme.

   pytest -m "curl and lz1 and (rz1 or rz2)"
   

   Teil 2 dieses Lernprogramms leitet den gesamten VPC-Datenverkehr <-> über den Firewall-Router weiter und löst diese Probleme. Aber zuerst ist es wichtig zu lernen, was passiert.

Firewall für Transit-Zieldatenverkehr entfernen

Die IBM Cloud VPC verwendet das statusbasierte Routing nach Industriestandard für die Überwachung sicherer TCP-Verbindungen. Es ist erforderlich, dass die TCP-Verbindungen denselben Pfad auf dem Weg nach außen verwenden. Eine Ausnahme ist die direkte Serverrückgabe, die von Routern wie Netz Load Balancer verwendet wird. So können eingehende Verbindungen vom Unternehmen über die Firewall an die Transit-Testinstanz übergeben und direkt an den Ersteller zurückgegeben werden.

Dies ist nicht hilfreich, wenn der Datenverkehr, der aus der Transittestinstanz stammt, über Transit Gateway und anschließend über Ingress-Routing an den Firewall-Router zurückgeleitet wird. Diese Verbindung bleibt am Firewall-Router (3) hängen und wird nicht wieder an den Worker weitergeleitet, wie in rot dargestellt. Verkehrtransit-> Unternehmen und Transit-> Spoke schlagen fehl.

Eine mögliche Lösung besteht darin, das Senden von Datenverkehr an die Transit-VPC an den Firewall-Router zu stoppen. Die breiten Ingress-Routen für den Transit leiten derzeit Datenverkehr an den Firewall-Router weiter. Es können spezifischere Routen für die Übertragung an Delegieren zum Standardverhalten hinzugefügt werden-direkt an das beabsichtigte Ziel anstelle des Firewall-Routers senden.

Dieses Diagramm zeigt den gewünschten Verkehrsfluss für diesen Schritt. Nur das Unternehmen <-> Spoke durchläuft die Firewall:

1. Unternehmen <-> Transit
2. Sprach <-> Transit
3. Spoke <-> Spoke
4. Unternehmen <--transit firewall-router--> spoke

Dieses Routing kann durch Hinzufügen der folgenden Routen zur Routentabelle transit ingress erreicht werden:

1. Um den aktuellen Wert der Ingress-Routentabelle zu beobachten, rufen Sie die Routing-Tabellen für VPC in der IBM Cloud-Konsole auf. Wählen Sie in der Dropdown-Liste die Transit-VPC und anschließend die Routing-Tabelle tgw-ingress aus.

2. Nehmen Sie die Änderungen an der Routing-Tabelle vor, indem Sie die Schicht 'transit_ingress' anwenden:

./apply.sh transit_ingress_tf

1. Aktualisieren Sie die Browseranzeige der Routing-Tabelle, um die neuen Routen zu beobachten.

2. Führen Sie die Testsuite aus.

   Ihre erwarteten Ergebnisse sind: Alle Tests führen zu PASSED.

   pytest -m "curl and lz1 and (rz1 or rz2)"
   

Es ist interessant zu beachten, wie zonenübergreifender Datenverkehr zwischen Unternehmen und Spokes in der Konfiguration fließt. Unternehmen sendet Datenverkehr an die richtige Zone und über den Firewall-Router über Ingress-Routing in der Transit-VPC. Transit Gateway hat erfahren, dass 192.168.0.0/16 in allen Zonen verfügbar ist und die Weiterleitung an die Transit-VPC über die zugänglich gemachten Unternehmensrouten in derselben Zone wie der Spoke erfolgt, wie im folgenden Diagramm dargestellt:

Routing-Zusammenfassung

Basisrouting ist abgeschlossen:

• Unternehmen <-> Transit
• Transit <-> Speiche (n)
• Unternehmen < -- (Transit-Firewall-Router)-- > Peripherieserver

Produktionshinweise und Schlussfolgerungen

Die VPC-Referenzarchitektur für IBM Cloud for Financial Services enthält viel mehr Details zum Schützen von Workloads in IBM Cloud.

Einige offensichtliche Änderungen müssen vorgenommen werden:

• CIDR-Blöcke wurden aus Gründen der Übersichtlichkeit und Einfachheit ausgewählt. Die Verfügbarkeitszonen in der Region mit mehreren Zonen könnten 10.0.0.0/10, 10.64.0.0/10oder 10.128.0.0/10 sein, um den Adressraum zu sparen. Der Adressraum für Workerknoten könnte auf Kosten von Firewall, DNS und VPE erweitert werden.
• Sicherheitsgruppen für jede der Netzschnittstellen für Worker-VSIs, Virtual Private Endpoint Gateways, DNS-Positionen und Firewalls sollten sorgfältig berücksichtigt werden.
• Die Netzzugriffssteuerungslisten für jedes Teilnetz sollten sorgfältig berücksichtigt werden.

Variable IP-Adressen wurden allen Testinstanzen zugeordnet, um Konnektivitätstests über SSH zu unterstützen. Dies ist in der Produktion weder erforderlich noch wünschenswert.

Implementieren Sie kontextbasierte Einschränkungen, um den Zugriff auf alle Ressourcen weiter zu steuern.

In diesem Lernprogramm haben Sie eine Hub-VPC und eine Gruppe von Spoke-VPCs erstellt. Sie haben die erforderlichen Verfügbarkeitszonen für die Architektur angegeben und eine Gruppe von Teilnetzen in den VPCs erstellt. Sie haben in jeder Zone einen Transit-VPC-Firewall-Router für die Weiterleitung von Datenverkehr erstellt. Testinstanzen wurden verwendet, um die Konnektivität zu überprüfen und potenzielle Probleme zu identifizieren. Routing-Tabellenrouten wurden verwendet, um die erforderlichen Datenverkehrspfade zu identifizieren.

Ressourcen entfernen

Es ist nicht erforderlich, die Ressourcen zu entfernen, wenn Sie mit dem zweiten Teil dieses Lernprogramms fortfahren möchten.

Führen Sie terraform destroy in allen Verzeichnissen in umgekehrter Reihenfolge mit dem Befehl ./apply.sh aus:

./apply.sh -d : spokes_egress_tf

Lernprogramm erweitern

Es wird empfohlen, mit Teil 2 dieses Lernprogramms fortzufahren, in dem der gesamte VPC-übergreifende Datenverkehr über den Firewall-Router, VPE for VPC und DNS, weitergeleitet wird.

Ihre Architektur wird sich wahrscheinlich von der hier dargestellten unterscheiden, aber wahrscheinlich aus den hier beschriebenen grundlegenden Komponenten aufgebaut sein. Ideen zum Erweitern dieses Lernprogramms:

• Integrieren Sie eingehenden öffentlichen Internetzugang mithilfe von IBM Cloud® Internet Services.
• Fügen Sie Datenflussprotokollerfassung während der Übertragung hinzu.
• Stellen Sie jede der Spokes in ein separates Konto in einem Unternehmen.
• Erzwingen Sie einen Teil des Spoke-to-Spoke-Datenverkehrs durch die Firewall und einen Teil nicht durch die Firewall.
• Ersetzen Sie die Worker-VSIs durch Red Hat OpenShift on IBM Cloud und die VPC-Lastausgleichsfunktion.
• Erzwingen Sie den gesamten abgehenden Datenverkehr über die Firewall in der Transit-VPC und über öffentliche Gateways.

Zugehörige Inhalte

• IBM Cloud for Financial Services
• Implementierung isolierter Workloads über mehrere Standorte und Regionen hinweg
• Öffentliches Front-End und privates Back-End in einer virtuellen privaten Cloud,
• Virtualisierung von Netzfunktionen
• Privater Hub und Spoke mit transparentem VNF und Spoke-to-Spoke-Datenverkehr