Bereitstellung vor Ort versus Cloud-Bereitstellung

Bevor Sie Workloads von einer lokalen Bereitstellung von „ IBM® App Connect Enterprise “ auf „ App Connect “ in „ IBM “ ( webMethods Hybrid Integration ) verlagern, sollten Sie sich mit den Unterschieden hinsichtlich Zuständigkeiten, Architektur, Konfiguration und Laufzeitverhalten vertraut machen.

Verantwortlichkeiten

App Connect ist ein vollständig verwaltetes Software-as-a-Service-Angebot ( SaaS ). IBM ist für die Bereitstellung und Wartung der Infrastruktur zuständig. Als Nutzer von „ App Connect “ sind Sie für Ihre Integrationsinhalte verantwortlich, einschließlich der Gestaltung und Bereitstellung Ihrer Integrationslaufzeiten und Nachrichtenabläufe. Sie sind gemeinsam mit IBM für die Erstellung, Konfiguration und Aktualisierung von Integrationslaufzeiten verantwortlich. Bei diesem Modell der geteilten Verantwortung übernimmt der Dienst automatisch einige operative Aufgaben, die Sie zuvor selbst gesteuert haben. Weitere Aufgaben werden über die Service-APIs und die Benutzeroberfläche verwaltet.

Weitere Informationen finden Sie in der Übersicht über die Verantwortlichkeiten für „ webMethods Hybrid Integration “.

Lösungsarchitektur

App Connect wird auf Amazon Web Services ( AWS ) und Microsoft Azure bereitgestellt und trennt Verwaltungsfunktionen von Integrationsaufgaben. Der Dienst bietet eine mandantenfähige Steuerungsebene für die Verwaltung und die Erstellung von Inhalten. Eine Datenebene sorgt durch dedizierte Laufzeitkomponenten für jeden Mandanten für die Isolierung der Workloads. Der Dienst ist über drei Verfügbarkeitszonen verteilt, was für hohe Verfügbarkeit und automatisches Failover sorgt.

Laufzeitmodell

Bei einer lokalen Bereitstellung von „ App Connect Enterprise “ werden Integrationen in der Regel auf Integrationsservern bereitgestellt, die von Integrationsknoten verwaltet werden. In „ App Connect “ erstellen Sie eine oder mehrere Integrationslaufzeitumgebungen, die funktional mit Integrationsservern gleichzusetzen sind.

Die Integrationslaufzeiten in „ App Connect “ sind containerbasiert und deklarativ, was bedeutet, dass sie über definierte Laufzeitkonfigurationen verwaltet werden. Wenn Sie eine Laufzeitumgebung erstellen oder aktualisieren, legen Sie eine entsprechende Konfiguration fest. Der Dienst richtet die Laufzeitumgebung dann mithilfe eines Blue-Green -Deployment-Ansatzes ein oder aktualisiert sie. Bei diesem Ansatz erstellt der Dienst eine neue Version der Laufzeitumgebung und leitet den Datenverkehr dorthin um, ohne die Verarbeitung zu unterbrechen.

Weitere Informationen finden Sie unter „Erstellen einer Laufzeitumgebung “.

Neustarts während der Laufzeit und Abgleich

App Connect nutzt einen Abgleichprozess ohne Ausfallzeiten, wenn Sie Integrationslaufzeiten aktualisieren oder neue Integrationen bereitstellen.

Wenn Sie eine Laufzeitkonfiguration aktualisieren oder eine weitere Integration bereitstellen, erstellt das System eine neue Instanz der Laufzeitumgebung mit der aktualisierten Konfiguration. Die bestehende Laufzeitumgebung verarbeitet weiterhin Anfragen, während die neue Instanz gestartet wird. Sobald die neue Instanz bereit ist, leitet das System neue Anfragen an sie weiter und fährt die vorherige Instanz ordnungsgemäß herunter. Beim Herunterfahren sendet das System ein Signal an die vorherige Laufzeitinstanz, damit diese noch laufende Anfragen abschließen kann, bevor sie beendet wird. Dadurch wird sichergestellt, dass bereits laufende Abläufe ohne Unterbrechung zu Ende geführt werden. Die meisten Abläufe werden innerhalb der sanften Abschaltphase abgeschlossen. Lang andauernde Vorgänge können jedoch möglicherweise vor ihrem Abschluss abgebrochen werden.

Containerbasierte Bereitstellung

App Connect „in webMethods Hybrid Integration “ basiert auf „ App Connect “ in Containern. Containerbasierte Bereitstellungen verhalten sich anders als herkömmliche Softwareinstallationen, und diese Unterschiede können sich darauf auswirken, wie Integrationen gruppiert, verwaltet und skaliert werden.
Isolierung bei der Bereitstellung
Bei Container-Bereitstellungen werden Gruppen von Integrationen in der Regel unabhängig voneinander in ihrer eigenen Container-Laufzeitumgebung bereitgestellt, anstatt wie bei einer herkömmlichen, zentralisierten Broker -Bereitstellung. Dieser Ansatz hat Vorteile, erfordert aber auch eine sorgfältige Planung.
Ressourcenzuordnung
CPU und Arbeitsspeicher werden für jede Laufzeitkonfiguration festgelegt. Die Laufzeitumgebungen werden unabhängig voneinander konfiguriert und skaliert, um den Anforderungen Ihrer Arbeitslast gerecht zu werden und den Ressourcenverbrauch zu steuern.
Versionsverwaltung der Laufzeitumgebung
Jede Laufzeitumgebung verfügt über eine eigene Produkt-Laufzeitumgebung, sodass Sie Laufzeitumgebungen für verschiedene unterstützte Versionen erstellen und diese unabhängig voneinander aktualisieren können.
Deklarative Konfiguration
Sie konfigurieren Ihre Laufzeitumgebungen, bevor Sie Integrationen darin bereitstellen, anstatt Befehle nach der Bereitstellung zu verwenden.

Wenn Sie bestehende Integrationen migrieren, legen Sie fest, wie diese gruppiert und in den Integrationslaufzeitumgebungen von „ App Connect “ bereitgestellt werden sollen. Ein gängiger Ansatz ist es, Ihre bestehende lokale Bereitstellung zu spiegeln. Beispielsweise können Sie die Integrationen von einem Integrationsserver oder einer Ausführungsgruppe in eine einzelne Laufzeitumgebung bereitstellen.

App Connect ermöglicht zudem flexiblere Bereitstellungsmodelle. Sie können Integrationen auf der Grundlage von Faktoren wie den Merkmalen der Arbeitslast, den Verfügbarkeitsanforderungen, der Häufigkeit von Upgrades oder Kostenaspekten auf mehrere Laufzeitumgebungen aufteilen. Jede Laufzeitumgebung ist mit Kosten verbunden, daher müssen Sie ein Gleichgewicht zwischen betrieblicher Isolation und effizienter Ressourcennutzung finden.

Konfigurationszuordnung und Abhängigkeiten

In einer lokalen Umgebung werden Integrationslaufzeiten häufig mithilfe von Befehlen wie mqsichangeproperties konfiguriert und stützen sich dabei auf Dateien, die auf dem Hostsystem vorhanden sind, wie beispielsweise Konfigurationsdateien von „ ODBC “ oder Keystores.

In „ App Connect “ erfolgt die gesamte Konfiguration deklarativ, indem Konfigurationsressourcen erstellt und diesen Integrationslaufzeiten zugeordnet werden. Die folgenden Konfigurationstypen stellen Ressourcen dar, auf die Nachrichtenflüsse häufig verweisen.
  • server.conf.yaml konfiguriert die meisten Einstellungen, die Sie über Befehle wie „ App Connect Enterprise “ vornehmen, beispielsweise mqsichangeproperties.
  • setdbparms.txt enthält Einzelheiten zu mqsisetdbparms den Befehlen, die für die Integrationslaufzeit ausgeführt werden müssen.
  • Policy project erstellt Richtlinien in einem Richtlinienprojekt, um das Verhalten von Nachrichtenflüssen und Knoten zur Laufzeit zu steuern.
  • Keystore und Truststore stellen Keystores und Truststores bereit, die von der Laufzeitumgebung oder den Nachrichtenflüssen verwendet werden können.
  • Generic files stellt allgemeine Dateien bereit, auf die die Laufzeitumgebung oder Nachrichtenflüsse verweisen können.

Ermitteln Sie vor der Migration alle externen Dateiabhängigkeiten oder Laufzeiteigenschaften und stellen Sie sicher, dass diese den entsprechenden Konfigurationstypen in „ App Connect “ zugeordnet sind.

Weitere Informationen finden Sie unter „Konfigurationstypen “.

Anbindung an lokale Systeme

Viele Integrationen, die auf App Connect bereitgestellt werden, müssen mit Anwendungen und Systemen interagieren, die weiterhin lokal betrieben werden. App Connect unterstützt hybride Konnektivitätsszenarien durch Portweiterleitung, aufrufbare Flows und „ AWS PrivateLink “. (Sie können auch eine DNS-Zuordnung konfigurieren, um den Datenverkehr von einer Anwendungsdomäne zu einem Endpunkt im privaten Netzwerk weiterzuleiten.)
Portweiterleitung
Sie können die Portweiterleitung konfigurieren, um eine sichere Verbindung zu Anwendungen und Systemen in Ihrem privaten Netzwerk herzustellen. Jeder Mandant unter App Connect verfügt über einen eigenen Switch-Server, der mit den Laufzeiten unter App Connect kommuniziert. Sie laden einen sicheren Agenten herunter und führen ihn in Ihrem privaten Netzwerk aus. Der Agent baut eine ausgehende Verbindung zu dem Switch-Server auf, der Ihrer Service-Instanz zugeordnet ist. Diese Verbindung ermöglicht bidirektionalen Datenverkehr, ohne dass Sie eingehende Ports in Ihrer Firewall öffnen müssen. Die Verbindung ist durch gegenseitiges TLS gesichert.

Ein häufiges Anwendungsszenario für die Portweiterleitung ist die Kommunikation mit einer Datenbank oder einem Web IBM MQ, die lokal betrieben werden. Sie können die Portweiterleitung jedoch auch nutzen, um Anwendungen und Systeme in anderen Netzwerken oder öffentlichen Clouds anzubinden.

Weitere Informationen finden Sie unter „Verbindung zu einem privaten Netzwerk über einen Switch-Server herstellen “.

Aufrufbare Flüsse
Callable Flows nutzen den Switch-Server auch, um Flows zu verbinden, die lokal und in der „ App Connect “ ausgeführt werden. Sie können beispielsweise einen „ App Connect Enterprise “-Flow in Ihrem privaten Netzwerk ausführen und diesen Flow dann direkt aus einem Flow aufrufen, der unter App Connect gehostet wird. Sie können einem Flow einen „Callable Flow Input“-Knoten hinzufügen und den Flow mit den Verbindungsdaten für den Switch-Server in einer Laufzeitumgebung bereitstellen. Der Datenfluss wird dann registriert und steht anderen Datenflüssen zur Verfügung, die mit demselben Switch-Server verbunden sind. Im „ App Connect Designer“ und im „ IBM App Connect Enterprise Toolkit“ stehen aufrufbare Flussknoten und Verbindungselemente zur Verfügung, sodass Flüsse aus dem Designer Flüsse aus dem Toolkit aufrufen können und umgekehrt. Aufrufbare Flows werden häufig für die Integration von „ SAP “ verwendet oder wenn Sie Daten näher an der Anwendung verarbeiten möchten.

Weitere Informationen finden Sie unter „Übersicht über aufrufbare Flows “.

AWS PrivateLink
AWS PrivateLink stellt eine private Netzwerkverbindung zwischen App Connect und einer Virtual Private Cloud in Ihrem Amazon Web Services -Konto ( AWS ) her, ohne öffentliche IP-Adressen oder das Internet zu nutzen. Um „ AWS PrivateLink “ zu nutzen, erstellen Sie einen VPC-Endpunkt (Virtual Private Cloud) und eine private gehostete Zone in Amazon Route 53. Die Daten werden über das „ AWS “-Netzwerk und nicht über das Internet privat weitergeleitet. App Connect unterstützt die Verwendung von AWS PrivateLink für die ein- und ausgehende Kommunikation. Die Kommunikation erfolgt in eine Richtung, daher müssen Sie für den eingehenden und den ausgehenden Datenverkehr separate Verbindungen einrichten. Ein gängiges Szenario für „ AWS PrivateLink “ besteht darin, „ AWS “-Dienste in Ihrer Virtual Private Cloud zu aktivieren, um über einen eingehenden privaten Link „ App Connect “-Integrationen auszulösen. Ebenso können „ App Connect “-Integrationen über eine ausgehende private Verbindung Dienste von „ AWS “ aufrufen.

Weitere Informationen finden Sie unter „Verbindung zu AWS -Diensten mit AWS PrivateLink herstellen “.

Wenn Sie den Secure Agent nicht verwenden, können Sie Firewalls so konfigurieren, dass der Zugriff auf Ihr privates Netzwerk oder auf Anwendungen, die IP-Whitelisting nutzen, ermöglicht wird. Eine Liste der IP-Adressen, die „ App Connect “ für die ausgehende Kommunikation verwendet, finden Sie unter „Outbound IP addresses “ in der Dokumentation zu „ webMethods Hybrid Integration “.

Verfügbarkeit und Skalierbarkeit

App Connect wird in jeder Region über mehrere Verfügbarkeitszonen verteilt, um hohe Verfügbarkeit und automatisches Failover zu gewährleisten. Um die Ausfallsicherheit zu erhöhen, können Sie mehrere Replikate einer Integrationslaufzeitumgebung konfigurieren. Der Dienst versucht, Replikate auf verschiedene Verfügbarkeitszonen zu verteilen, und plant die Laufzeitumgebungen automatisch neu, falls eine Zone ausfällt.

Prüfen Sie bei der Planung Ihrer Migration die Verfügbarkeitsanforderungen Ihrer Integrationen und richten Sie gegebenenfalls mehrere Laufzeit-Replikate ein, um diese Anforderungen zu erfüllen.

Verhalten bei Upgrades und Versionskontrolle

IBM verwaltet die Installation und Aktualisierung der zugrunde liegenden „ App Connect “-Plattform. Sie legen fest, welche Version die jeweilige Integrations-Laufzeitumgebung verwendet, indem Sie beim Erstellen der Laufzeitumgebung eine der unterstützten Versionen auswählen.

Je nachdem, welche Versionsoption Sie wählen, können die Laufzeitkomponenten automatisch aktualisiert werden, sobald neue Fixpacks oder Modifikationsreleases verfügbar sind. Entscheiden Sie, ob Sie automatische Updates wünschen oder lieber mehr Kontrolle darüber haben möchten, neue Versionen zu testen, bevor Sie sie in der Produktionsumgebung einsetzen.

Weitere Informationen finden Sie unter „Aktualisieren der Version Ihrer Integrationslaufzeitumgebung “.

CI/CD-Pipelines

Die API für „ App Connect “ bietet alle Funktionen, die Sie für die Bereitstellung und Verwaltung Ihrer Integrationen und Laufzeiten benötigen. Weitere Informationen finden Sie in der API-Übersicht.

Produktbeschränkungen und Verhaltensunterschiede

Einige Funktionen, die in lokalen Bereitstellungen von „ App Connect Enterprise “ verfügbar sind, sind in „ App Connect “ nicht verfügbar oder verhalten sich dort anders. Ein Beispiel hierfür ist das Fehlen eines standardmäßigen lokalen Warteschlangenmanagers in containerbasierten Bereitstellungen. Weitere Informationen finden Sie unter „Bekannte Einschränkungen “ und „Unterstützte Ressourcen in importierten BAR-Dateien “.