Key Visual - Manage Your Business Integration
 

Mai

13

Migration WebSphere ESB Nach IBM Integration Bus - Infrastruktur

By Thorsten Theelen on We, May/13/2015 : 10:18

Mit dem bevorstehenden Ende des WebSphere ESB (WESB) als Standalone-Integrationsprodukt steht vielen Kunden in nächster Zeit eine Migration auf den IBM Integration Bus (IIB) bevor. Dabei müssen sich nicht nur die Entwickler an völlig neue Konzepte und ein ganz anderes Entwicklungsvorgehen gewöhnen. Auch auf der Infrastruktur-Seite gibt es große Unterschiede zwischen WESB und IIB. Im Folgenden werden die Infrastruktur-Konzepte der beiden Produkte miteinander verglichen und die bei der Migration zu beachtenden Aspekte beschrieben.

WebSphere ESB Topologie

Der WESB verwendet den WebSphere Application Server (WAS) als Laufzeitumgebung und kann daher auch auf die Standard-Mechanismen des Application Servers zurückgreifen. Die empfohlene Infrastruktur für hochverfügbare WAS-Umgebungen ist die so genannte "Golden Topology". Hier werden die Anwendungen, Messaging-Komponenten sowie unterstützende Applikationen, wie z.B. Administrationswerkzeuge je auf einen eigenen Application Server Cluster aufgeteilt (AppTarget-, Support- und Messaging-Cluster), die wiederum auf mehrere Server verteilt werden können. Dadurch wird die Hochverfügbarkeit der Umgebung gewährleistet und ein Load Balancing zwischen den verschiedenen Servern ermöglicht.

Eine weitere zentrale WAS-Instanz, der Deployment Manager (DMGR) wird verwendet um die gesamte Umgebung zu administrieren. Die Serverinstanzen sind untereinander synchronisiert. Wird z.B. über den Deployment Manager eine WESB-Integrationslösung im AppTarget-Cluster installiert, wird diese automatisch auf alle Cluster-Mitglieder verteilt. Soll die Last gleichmäßig auf die verschiedenen Cluster-Seiten verteil werden, kann dies z.B. über einen vorgeschalteten Load Balancer geschehen.

IBM Integration Bus Komponenten

Ganz anders sieht es beim IIB aus. Dieser läuft nicht innerhalb des WebSphere Application Servers, sondern bringt eine eigene Laufzeitumgebung mit. Die zentrale Komponente des IIB ist der Integration Node, bei dem es sich um eine Instanz des IIB's handelt. Innerhalb des Integration Nodes kann es eine beliebige Zahl von Integration Servern geben. Dabei handelt es sich jeweils um eine Java-VM, in der dann die eigentlichen Integrationslösungen laufen. Das Nutzen in der Verwendung mehrerer getrennter Integration Server liegt darin, dass IIB-Anwendungen so nach fachlichen oder technischen Aspekten gruppiert und auch voneinander isoliert werden können, z.B. um die Auswirkungen eines Ausfalls einer Anwendung auf andere Anwendungen zu minimieren. Dabei ist jedoch zu beachten, dass jeder zusätzliche Integration Server die Hardware-Anforderungen, insbesondere den Hauptspeicherbedarf deutlich erhöht.

Einen Lastausgleich erzielt man auf dem IIB, indem man mehrere Integration Nodes auf unterschiedlichen Servern einrichtet und die Integrationslösungen auf jedem dieser Server installiert. Anders als beim WESB sind die Integrationsknoten nicht untereinander synchronisiert und es gibt auch keinen zentralen Deployment Manager. Die Installation muss also unabhängig auf allen am Load Balancing beteiligten Servern installiert werden.

Es gibt verschiedene Ansätze zur Einrichtung einer hochverfügbaren IIB-Umgebung. Der IIB und das zugrunde liegende WebSphere MQ bieten einen eigenen Hochverfügbarkeits-Mechanismus. Dieser hat jedoch technische Voraussetzungen, die nicht in allen Fällen erfüllt werden können. Eine mögliche Alternative ist die Verwendung von Betriebssystemseitigen HA-Clustertechnologien wie z.B. HACMP auf AIX-Systemen. Heutzutage werden immer mehr virtuelle Maschinen (VM) anstelle von physischen Servern verwendet, daher werden hochverfügbare Umgebungen auf Basis von VM-Images immer häufiger, oft in Verbindung mit SAN-Filesystemen.

Welche Technologie die richtige ist, hängt individuell von den Kundenanforderungen und den bestehenden technischen Möglichkeiten ab.

Vorgehen bei der Migration

Die zuvor beschriebenen Unterschiede zwischen der WESB- und IIB-Infrastruktur führen dazu, dass bei einer Migration kaum Konzepte aus der alten Umgebung übernommen werden können, stattdessen muss die Infrastruktur weitgehend neu geplant werden. Hochverfügbarkeit und Lastverteilung funktionieren beim IIB anders als beim WESB, aber auch die Administration unterscheidet sich stark. Dies fängt bei Deployments an, die nicht mehr über einen zentralen Deployment Manager, sondern pro Server durchgeführt werden müssen, und geht bis hin zu Security-Einstellungen, die beim IIB auf MQ-Basis durchgeführt werden, während der WESB auf die entsprechenden Werkzeuge des WAS zurückgreifen kann.
Viele der zu treffenden Entscheidungen sind kundenindividuell, es gibt keine für alle möglichen Szenarien richtige oder beste Lösung. Daher muss einer erfolgreichen Migration eine sorgfältige Konzeptions- und Planungsphase vorausgehen.

Falls Sie in nächster Zeit eine Migration vom WebSphere ESB auf den IBM Integration Bus planen, stehen wir Ihnen mit unserer Erfahrung im Umgang mit beiden Produkten zur Verfügung. Gerne unterstützen wir Sie bei der Konzeption der neuen Umgebung, aber auch bei der späteren Installation, Konfiguration und beim Betrieb.


Margin
Blog-Autor
Thorsten Theelen
Thorsten Theelen
Software Engineer
+49-221-97343-40
Margin
Informationen
7.0.1  7.0.2  8.0  Absatzmarkt  Active MQ  Active  Administration  Agile Lösungen  Agility  AMS  Analyst  Analytics  Anbindung  Anforderungen  Anwenderkonfernz  Apache  Application Server  API Management  API  AS2  ASP  Automatisierung  b2b  B2B Integration  Basic  Big Data  Blogreihe  Bluemix  Blueworks  BPM  Broker  BRMS  Bus  Business Process Management  Business Rules  Buzzword  Camel  Cast Iron  Cloud API  Cloud Computing  Cloud Integration  Cloud  Commerce  Compliance  Conference  Connect:Direct  CPLEX  CXF  DataPower  Decision Server Insights  Deployer  Deployment  Development  DFDL  Digitalisierte Prozesse  Digitalisierung  Domino  DSI  e-Fachverfahren  ersteinrichtung  Edi  Edition  Einführung  Einsatz  Entscheidung  Entwicklung  ESB  Excel  Fahrplanoptimierung  Features  Federated Connectivity  File Transfer  Filetransfer  Finance  FTE  gentran  gis  Geschäftsprozesse  Go Live  Google  Governance  Hardware ESB  Hosting  Hybrid-Cloud  Hybrid Cloud  Hybrid  IBM Blueworks  IBM BPM  IBM Integration Bus  IBM InterConnect  IBM  ILOG DOC  ILOG LNP  ILOG Transportation Analyst  ILOG  Impact  Infrastruktur  Installation  Integration as a Service  Integration Bus  Integration  Integrator  Interoperabilität  IT-Business-Alignment  Konfiguration  Linear  LNP  Logistik  monitoring  M2M  Manage File Transfer  Management  Marktplatz  Mathematik  Mediation  Message Broker  Messages  Messagesight  Messaging  MFT  Migration  Modellierung  MQ  MQTT  Multicast  Muster  Nachlese  Neuerungen in V7.0.1  Neuerungen  off-premise  on-premise  ODM  ODME  Öffentliche Verwaltung  Open Source  Operational Decision Management  Optimierung  OPL  OSGi  Outsourcing  PaaS  Pattern Integration  Pattern  Patterns  Performance  Portfolio  Praxis  Private  Process Server  Produktionsplanung  Prozessautomatisierung  Prozessintegration  Prozessmodelierung  Prozessoptimierung  PureSystem  Qualität  Real Time  Regelmanagement  Rollen  Routenplanung  Routing  ROI  SaaS API  SaaS Integration  SaaS  Salesforce  Schwerpunktanalyse  Script  SCM  Security  Service Federation Management  Servicemix  SFM  SI  Slotting  SoapUI  SOA Cloud Symposium  SOA  SPSS  Standard  Standardplattform  Standardtool  Standortoptimierung  Sterling Integrator  Sterling  SugarCRM  Symposium  Template  TIP  TM1  TOSCA  Transportation  Transportoptimierung  Übersicht  Umstieg  Unix  Update  vergleich  Vorteile  worklight  workload  wtc  Wartung  Websphere  Websphere: Rollen  WebService Security  WebSphere Enterprise Service Bus  WebSphere ESB  WebSphere MessageBroker  WebSphere Technical Conference  WebSphere  WESB  Workloads  WODM  XAR