Darf s ein bisschen mehr sein? Scaling Out Oracle SOA Suite 11g Cluster

Transkript

1 Darf s ein bisschen mehr sein? Scaling Out Oracle SOA Suite 11g Cluster OPITZ CONSULTING GmbH 2010 Seite 1

2 Fahrplan 1. Wann und wofür brauche ich einen Oracle SOA Suite Cluster? 2. Welche Technologien kann ich für einen SOA Suite Cluster nutzen und wie sieht so ein Cluster exemplarisch aus? 3. Wie implementiere ich einen SOA Suite Cluster? 4. Wie reagiere ich auf steigende Last? OPITZ CONSULTING GmbH 2010 Seite 2

3 1. Motivation für einen Oracle SOA Suite Cluster OPITZ CONSULTING GmbH 2010 Seite 3

4 Ausfallsicherheit Schutz bei Hardwareausfall Stromversorgung Storage Serverkomponenten Netzwerkkomponenten Schutz bei Softwareausfall Prozessabsturz Überlast Konfigurationsfehler Beschädigung von Software- oder Konfigurationsdateien durch logische Korruption OPITZ CONSULTING GmbH 2010 Seite 4

5 Kosten für Ausfallsicherheit Ausfallsicherheit kostet Geld Höhere Kosten für Hardware Höhere Kosten für Lizenzen Höhere Kosten für Anwendungsentwicklung und Tests Höhere Kosten für Betrieb und Wartung Ausfälle können aber noch viel teurer sein Welche Kosten Fallen an, wenn das System einer Fachabteilungen eine Zeit lang nicht zur Verfügung steht? wenn Geschäftspartner nicht auf das System kommen? wenn Kunden bestimmte Dienste nicht nutzen können? Und wie wirken sich Ausfälle auf Kundentreue oder das Vertrauen von Geschäftspartnern aus? OPITZ CONSULTING GmbH 2010 Seite 5

6 Planung der Ausfallsicherheit Ausfallsicherheit benötigt Planung Welche Verfügbarkeit muss ich gewährleisten? Wo habe ich SPOFs Single Point of Failures? Funktioniert meine Anwendung auch im Cluster? Wie überwache ich mein System? Wie gehe ich mit Backup und Recovery um? Wann und wie oft teste ich Failover, und Desaster Recovery? OPITZ CONSULTING GmbH 2010 Seite 6

7 Lastverteilung Vergrößerung der Leistungsfähigkeit einer Oracle SOA Suite durch Verteilung der Last auf mehrere Hardwareknoten Notwendig, wenn die gewünschte Leistungsfähigkeit nicht mit einer SOA Suite Single Node Installation erreichbar ist. OPITZ CONSULTING GmbH 2010 Seite 7

8 Aspekte bei Lastverteilung Kosten Auch Lastverteilung ist teurer als Single Node Installationen lohnt sich aber, wenn die dadurch erwarteten Mehreinnahmen oder Kosteneinsparungen den Mehrpreis übersteigen Planung Definition der geforderten Leistungsfähigkeit: Durchsatz Antwortzeit Ermittlung der benötigten Hardware Erste Abschätzung anhand von Mengengerüsten Endgültige Bestimmung durch Lasttests OPITZ CONSULTING GmbH 2010 Seite 8

9 Lastverteilung und Ausfallsicherheit Ein lastverteiltes System ist nicht automatisch ausfallsicher Je nach definierten SLAs kann ein System schon bei schlechter Antwortzeit/Durchsatz als eingeschränkt oder nicht verfügbar gelten Muss ein ausfallsicheres System auch lastverteilt werden, muss eine Leistungsreserve eingeplant werden, die den Ausfall eines Knotens toleriert Achtung: Steigt die Last während der Lebenszeit eines Systems, muss die eingeplante Leistungsreserve entsprechend angepasst werden OPITZ CONSULTING GmbH 2010 Seite 9

10 Technologien für einen SOA Suite Cluster OPITZ CONSULTING GmbH 2010 Seite 10

11 Oracle WebLogic ist die technologische Basis für die Oracle SOA Suite 11g bietet technische Möglichkeiten für Hochverfügbarkeit und Lastverteilung OPITZ CONSULTING GmbH 2010 Seite 11

12 WebLogic Domain Grundidee Gruppe von logisch zusammengehörigen WebLogic Server (WLS) Instanzen, die sich eine gemeinsame Konfiguration teilen. Regeln Die Instanzen können unterschiedliche Patch-Level enthalten. (Rolling Update) config.xml OPITZ CONSULTING GmbH 2010 Seite 12

13 Admin Server Grundidee Ist der zentrale Controller einer Domain Aufgaben Betrieb der Admin-Console verteilt Konfiguration an die Server Starten und Stoppen von Servern Deployment auf Server Monitor und Manager für Ressourcen Realisiert die Server- und Service-Migration Regeln Pro Domain genau einen Admin Server In Produktion kein Host für Applikationen Admin Server ist kein SPOF, und muss nicht permanent Online sein Domain Admin Server config.xml Admin Console Managed Servers OPITZ CONSULTING GmbH 2010 Seite 13

14 Managed Server Grundidee Instanz zum Betrieb von Applikationen, Diensten Aufgaben "Arbeitstiere" im Domain-Kontext Betreiben, Skalieren oder Optimieren von JEE Anwendungen und Layer Hosted die Applikation soa_infra Regeln eigne JVM pro Server Änderungen nur zentral über Admin-Server enthält "Read-Only" Kopie der Domain-Konfiguration keine beschränkte Anzahl pro Domain JNDI JMS Queue JDBC Pool JNDI JNDI JMS Queue JDBC Pool JMS Queue JDBC Pool OPITZ CONSULTING GmbH 2010 Seite 14

15 Node Manager Grundidee Agent und Hintertürchen zu Maschinen Aufgaben Starten, Stoppen und Prüfen von Remote-Instanzen Server-Health Tool entdeckt "Failed" Instanzen Auto-Restart-If-Killed Heartbeat Regeln prinzipiell optional, aber komfortabel, zwingend bei Whole Server Migration/Migrateable Target nur ein Node Manager pro Maschine domainunabhängig Domain Maschine A Maschine B Admin Server Managed Server (Shutdown) Managed Server (Running) Maschine A Maschine B Node Manager OPITZ CONSULTING GmbH 2010 Seite 15

16 WebLogic Cluster Grundidee Last auf mehrere Managed Server verteilen Regeln Der Cluster ist ein virtuelles Objekt innerhalb einer Domäne Mehrere Managed Server können einem Cluster zugeordnet werden Deployments sowie andere Objekte (JMS-Queues, JDBC Pools, ) können dem gesamten Cluster oder einzelnen Managed Servern im Cluster zugeordnet werden (Targeting) Machine A Admin Server config. xml Managed Server 1 Domain Machine B Cluster Managed Server 2 OPITZ CONSULTING GmbH 2010 Seite 16

17 Session Replikation Java EE Session Requests eines Benutzers müssen immer an denselben Managed Server gehen, da die anderen Managed Server im Cluster die Session nicht kennen Session Replikation Anwendungen in einem WebLogic Cluster können ihre Session an die anderen Managed Server replizieren. Dann ist es egal wohin der Request geht Cluster Managed Server 1 Managed Server 2 Session Replikation OPITZ CONSULTING GmbH 2010 Seite 17

18 WebLogic Migratable Target Grundidee Failover Aufgabe Schutz gegen Ausfall eines Services, z.b. ein JMS Server Bei Ausfall, Migration des Services Regeln Services können nur innerhalb eines Clusters migriert werden Service ist einem Managed Server fest zugewiesen Andere Managed Server können als Kandidat für dessen Übernahme konfiguriert werden Cluster Managed Server 1 Managed Server 2 Service Migration OPITZ CONSULTING GmbH 2010 Seite 18

19 WebLogic Whole Server Migration Aufgabe Schutz gegen Ausfall eines managed Servers managed Server wird automatisch auf einen anderen Rechnerknoten migriert Machine A Admin Server config. xml Domain Machine B Regeln Managed Server gehört zu einem Cluster Virtuelle IP für managed Server darf nicht statisch konfiguriert sein Schwenk der IP Adresse mit wlsifconfig.sh Managed Server 1 Cluster Whole Server Migration Managed Server 1 Migration des managed Servers durch Node Manager OPITZ CONSULTING GmbH 2010 Seite 19

20 Coherence Verteilter In-Memory Cache Cluster für Java Objekte Jeder Knoten eines Coherence Clusters enthält alle Daten aber jeder Knoten ist nur für eine Partition dieser Daten zuständig Fällt ein Knoten aus, werden die Daten sofort automatisch neu partitioniert Tritt ein neuer Knoten in den Cluster ein, erhält er alle Daten und es wird neu partitioniert Wird von der SOA Suite zum Deployment von Composites verwendet OPITZ CONSULTING GmbH 2010 Seite 20

21 JMS Distributed Destination Eine Gruppe von JMS Queues oder Topics Erscheint dem Client als eine Queue/Topic Ermöglicht JMS Loadbalancing und Failover OPITZ CONSULTING GmbH 2010 Seite 21

22 SOA Suite HA OPITZ CONSULTING GmbH 2010 Seite 22

23 Loadbalancer Empfehlung: Nutzen eines Hardware Loadbalancers Um SPoF auszuschließen, wird ein Standby LB benötigt Falls benötigt, auf Session Stickiness achten OPITZ CONSULTING GmbH 2010 Seite 23

24 Web Tier Der Oracle HTTP Server (OHS) aus der Web Tier arbeitet im Beispiel als active-active Cluster Zudem fungiert der OHS wiederum selbst als Loadbalancer Vorteil: fällt ein OHS aus, wird die Last dennoch auf alle Managed Server verteilt OPITZ CONSULTING GmbH 2010 Seite 24

25 Admin Server Fällt der Admin Server aus, können keine Konfigurationsänderungen durchgeführt werden Es können auch keine Deployments durchgeführt werden Die Managed Server laufen aber mit all ihren Anwendungen unbeeinflusst weiter Der Admin Server ist damit kein SPoF Dennoch gibt es Möglichkeiten, den Admin Server Failover fähig zu machen Er benötigt dann eine eigene VIP und das Domain Home für den AdminServer muss auf einer shared Disk liegen OPITZ CONSULTING GmbH 2010 Seite 25

26 Managed Server Die Managed Server der SOA Suite sind im Beispiel geclustered Sie sind zudem mittels Whole Server Migration failoverfähig Dafür benötigen sie je eine eigene IP Außerdem müssen die Verzeichnisse für die JMS Persistent Stores auf einer Shared Disk liegen OPITZ CONSULTING GmbH 2010 Seite 26

27 Metadata Repository Database In einer HA Umgebung muss auch die Metadata Repository Datenbank für die SOA Suite hochverfügbar sein Hierfür eignen sich Dataguard oder verschiedene Clustersysteme wie Oracle Grid Infrastructure, Veritas, HACMP, Muss darüber hinaus die Leistungsfähigkeit der Datenbank gesteigert werden, eignet sich Oracle Real Application Cluster (RAC) OPITZ CONSULTING GmbH 2010 Seite 27

28 Einen SOA Suite Cluster implementieren OPITZ CONSULTING GmbH 2010 Seite 28

29 Konfiguration Single Node Cluster OPITZ CONSULTING GmbH 2010 Seite 30

30 Konfiguration Single Node Cluster Unterschied: OPITZ CONSULTING GmbH 2010 Seite 33

32 Konfiguration Single Node Cluster Für spätere Skalierung immer Managed Servers, Clusters du Machines auswählen OPITZ CONSULTING GmbH 2010 Seite 36

38 wenn SOA Cluster - Konfiguration verteilen Node 1 cd $WLS_SERVER/common/bin - pack.sh -managed=true -domain=$soa_domain -template=soadomaintemplate.jar -template_name=soa_domain_template Node 2 cd $WLS_SERVER/common/bin scp oracle@node2.opitz-consulting.int: $WLS_SERVER/common/bin/soadomaintemplate.jar OPITZ CONSULTING GmbH 2010 Seite 45

39 Next Steps - NodeManager Nodemanager Configuration /u01/app/oracle/middleware/wlserver_10.3/common/nodema nager/nodemanager.properties StopScriptEnabled=true StartScriptEnabled=true OPITZ CONSULTING GmbH 2010 Seite 46

40 Next Steps Listen Adress OPITZ CONSULTING GmbH 2010 Seite 47

41 Next Steps Hostname Verification OPITZ CONSULTING GmbH 2010 Seite 48

42 HTTP Server Installation Notwendig: Oracle HTTP Server (OHS) Wird mit der Oracle Web Tier ausgeliefert Zusätzliche Komponenten OPMN WebCache OPITZ CONSULTING GmbH 2010 Seite 49

43 HTTP Server OPITZ CONSULTING GmbH 2010 Seite 51

49 HTTP Server mod_wl_ohs.conf # SOA soa-infra app <Location /soa-infra> SetHandler weblogic-handler WebLogicCluster NODE1:8001,NODE1:8002 </Location> ORACLE_BASE/admin/<instance_name>/bin/opmnctl startproc ias-component=ohs1 Callback Adresse für SOA-INFRA einrichten OPITZ CONSULTING GmbH 2010 Seite 60

50 Admin Server Failover Konfiguration Die Listen Adresse für den Admin Server anpassen Environment -> Servers Lock and Edit Klick auf AdminServer Listen Addresse anpassen, z.b. cfcvip.mycompany.com Save Activate Changes Neustart des Administration Servers OPITZ CONSULTING GmbH 2010 Seite 62

51 Admin Server Failover Konfiguration 2 Admin Server auf shared Disk legen und via GridInfra failoverfähig machen benötigt eigene VIP und Ressource in GridInfra Admin Server stoppen AdminServer Verzeichnisse aus dem DOMAINHOME auf shared Disk kopieren Symbolische Links auf allen Knoten erstellen AdminServer starten via GridInfra starten OPITZ CONSULTING GmbH 2010 Seite 63

52 Scale Up und Scale Out: Auf steigende Last reagieren OPITZ CONSULTING GmbH 2010 Seite 64

53 End to End Monitoring Wie reagiert die Anwendung aus Sicht des Benutzers/Consumer? Definiton von SLAs Definition von Use Cases Messung von Antwortzeiten durch Agenten/Robots für die definierten Use Cases OPITZ CONSULTING GmbH 2010 Seite 65

54 Ressourcen Monitoring Wie stark sind die beteiligten Ressourcen ausgelastet: CPU Hauptspeicher Festplatten Speicher Festplatten IO Netzwerk IO Logfilemonitoring Timeout Fehler: HTTP, Database, Out of Memory Exception Auch die anderen Komponenten betrachten Loadbalancer Ggf. die Komponente an der SSL terminiert Datenbank: Storage, Statistiken, OPITZ CONSULTING GmbH 2010 Seite 66

55 Volumetrisches Monitoring Pro Zeiteinheit, wie viele Gleichzeitig angemeldete Benutzer (Concurrent User) BPEL Prozesse Mediator Transformationen JMS Messages Theoretisches Sizing im Alltag meist nur als grober Anhaltspunkt brauchbar Grenzen eines Systems müssen per Lasttest ermittelt werden Ggf. Neukalibrierung dieser Grenzen nach Tuningmassnahmen Funktionalen Erweiterungen OPITZ CONSULTING GmbH 2010 Seite 67

56 Scale Up Über die Zeit können die Lastanforderungen an die SOA Suite steigen Vergrößerter Benutzerkreis Neue Funktionen Neue Anwendungen Die Performance der SOA Suite ist nicht mehr ausreichend Das End to End Monitoring meldet vermehrt orange Warnungen (Antwortzeiten nahe an SLA Verletzungen) Das Volumen basierte Monitoring meldet vermehrt orange Warnungen (Volumina nah an der im Lasttest ermittelten Grenze) Die Hardware besitzt noch Leistungsreserven Das Ressourcen Monitoring ist grün => Maßnahmen zur besseren Auslastung der Hardware OPITZ CONSULTING GmbH 2010 Seite 68

57 Scale Up Massnahmen Analyse des Flaschenhalses Z.B.: Heap Speicher ausgelastet => Heap Size vergrößern Mitunter kann ein SOA Suite Managed Server die CPU Kerne eines großen Servers nicht auslasten => Scale Up durch Erweiterung des SOA Suite Clusters um weitere Managed Server auf der bestehenden Hardware OPITZ CONSULTING GmbH 2010 Seite 69

58 Scale Up durchführen In der WebLogic Console auf Lock & Edit klicken Unter Environment->Servers einen bestehenden SOA managed Server auswählen und klonen OPITZ CONSULTING GmbH 2010 Seite 70

59 Scale Up durchführen Namen, Listen Address und Port eingeben, mit OK bestätigen Activate Changes anklicken OPITZ CONSULTING GmbH 2010 Seite 71

60 Scale Up durchführen JMS Server analog zu den bestehenden anlegen: Unter Services->Messaging->JMS Servers : SOAJMSServer_auto_3 Target->soa_server3 UMSJMSServer_auto_3 Target->soa_server3 OPITZ CONSULTING GmbH 2010 Seite 72

61 Scale Up durchführen Folgende Verzeichnisse anlegen: $DOMAIN_HOME/SOAJMSFileStore_auto_3 $DOMAIN_HOME/UMSJMSFileStore_auto_3 OPITZ CONSULTING GmbH 2010 Seite 73

62 Scale Up durchführen Subdeployments analog zu den bestehenden anlegen: Unter Services->Messaging->JMS Modules, SOAJMSModule, Reiter Subdeployments : SOAJMSServer Target->SOAJMSServer_auto_3 Die 9-stellige Zahl ist zufällig gewählt und unterschiedlich zu den bestehenden OPITZ CONSULTING GmbH 2010 Seite 74

63 Scale Up durchführen Ein vergleichbares Subdeployment für UMSJMSSystemResource UMSJMSServer Target->UMSJMSServer_auto_3 OPITZ CONSULTING GmbH 2010 Seite 75

64 Scale Up durchführen Analog zu den bestehenden Queues, folgende Queues für SOAJMSModule anlegen, Target: SOAJMSServer Unter Services->Messaging->JMS Modules, SOAJMSModule B2BEventQueue_auto_3 B2B_IN_QUEUE_auto_3 B2B_OUT_QUEUE_auto_3 EDNQueue_auto_3 Queue NotificationSenderQueue_auto_3 TestFwkQueue_auto_3 OPITZ CONSULTING GmbH 2010 Seite 76

65 Scale Up durchführen Analog zu den bestehenden Topics, folgende Topics für SOAJMSModule anlegen, Target: SOAJMSServer Unter Services->Messaging->JMS Modules, SOAJMSModule B2BBroadcastTopic_auto_3 XmlSchemaChangeNotificationTopic_auto_3 OPITZ CONSULTING GmbH 2010 Seite 77

66 Scale Up durchführen Analog zu den bestehenden Queues, folgende Queues für UMSJMSSystemResource anlegen, Target: UMSJMSServer Unter Services->Messaging->JMS Modules, UMSJMSSystemResource OraSDPM/Queues/OraSDPMAppDefRcvQ1_auto_3 OraSDPM/Queues/OraSDPMDriverDefSndQ1_auto_3 OraSDPM/Queues/OraSDPMEngineCmdQ_auto_3 OraSDPM/Queues/OraSDPMEngineRcvQ1_auto_3 OraSDPM/Queues/OraSDPMEngineSndQ1_auto_3 OraSDPM/Queues/OraSDPMWSRcvQ1_auto_3 und fertig! OPITZ CONSULTING GmbH 2010 Seite 78

67 Scale out Die Performance der SOA Suite ist nicht mehr ausreichend Das End to End Monitoring meldet vermehrt orange Warnungen (Antwortzeiten nahe an SLA Verletzungen) Das Volumen basierte Monitoring meldet vermehrt orange Warnungen (Volumina nah an der im Lasttest ermittelten Grenze) Auch die Hardware ist stark ausgelastet Das Ressourcen Monitoring meldet vermehrt orange Warnungen (Zustände nah an der definierten Auslastungsgrenze) => Soweit möglich/sinnvoll: Aufstocken der Hardware und Scale Up Speichererweiterung, CPU Auf-, Nachrüstung, Plattenspeicher, => Erweiterung um zusätzliche Hardware Server OPITZ CONSULTING GmbH 2010 Seite 79

68 Scale Out Maßnahmen Fall 1: Es befinden sich mehrere Komponenten (HTTP Server, SOA Suite, Datenbank) auf einem Server. (Dies kann der z.b. bei einer Art eingeschränktem Pilotbetrieb der Fall sein, nach dessen Ablauf die SOA Suite in den Regelbetrieb überführt wird) => Separieren der Komponenten auf eigene Server Fall 2: Die Komponenten sind bereits vollständig separiert, nun muss der SOA Suite Cluster um weitere managed Server auf eigener Hardware erweitert werden OPITZ CONSULTING GmbH 2010 Seite 80

69 Scale Out durchführen Installation der Software (Java, WebLogic, SOA Suite) auf dem neuen Server Replizieren der Domäne auf den neuen Server Ggf. Shared Filesystems verfügbar machen Weiteres Vorgehen wie bei einem Scale Up OPITZ CONSULTING GmbH 2010 Seite 81