Blackout ist tabu - Verfügbarkeit auf Exasystemen
Werbung
Blackout ist tabu - Verfügbarkeit auf Exasystemen Matthias Fuchs Exaday - 13. April 2016 - Hamburg Matthias Fuchs Principal Consultant [email protected] Twitter @hias222 OCP Engineered Systems Architektur und Konzeption Oracle Infrastruktur Tuning DB und Middleware Vernetzen mit esentri 2 Unser Fokus liegt auf der Middleware > > > > > Oracle ADF & MAF Oracle SOA & BPM Suite Java Enterprise Edition Oracle Weblogic esentri Middleware Toolbox > Cloud > Oracle Java Cloud > Oracle Integration & Process Cloud > Oracle Mobile Cloud > Mehr > Digitalisierung & Industrie 4.0 > Internet of Things > Forms Evolution 3 Eine Allianz für volles Programm rund um den Red Stack Ziel der scope alliance ist es, durch die Vernetzung von Experten den Zugang und Einsatz von Oracle Produkten und Services für Kunden einfacher zu gestalten. In gemeinsamen Projekten bündeln 200 Oracle Spezialisten ihre Expertise aus allen wichtigen Bereichen des Oracle Portfolio, angefangen bei Hardware, über Datenbanken bis hin zu Middleware und Anwendungsentwicklung. 4 Unsere begeisterten Kunden EINFACH MEHR > VERTRAUEN 5 7 Jahre erfolgreiche Oracle Projekte 6 Blackout ist tabu - Verfügbarkeit auf Exasystemen > Verfügbarkeit > Allgemein > ACID > Cap Theorie > Anzahl Rechenzentren > Webscale vs Enterprise > Facebook,Amazon, Oracle SOA > Architektur für die Verfügbarkeit der Exasystems > Exadata > Exalogic > Exadata & Exalogic > Maintenance > Patching > Site Guard > Far Sync > ODA vs Exa Wiki - Verfügbarkeit > Die Verfügbarkeit eines technischen Systems ist die Wahrscheinlichkeit oder das Maß, dass das System bestimmte Anforderungen zu bzw. innerhalb eines vereinbarten Zeitrahmens erfüllt. > Alternativ ist Verfügbarkeit von einer Menge an Objekten definiert als der Anteil der verfügbaren Objekten an der Gesamtzahl der Objekte in dieser Menge. Sie ist ein Qualitätskriterium und eine Kennzahl eines Systems. https://de.wikipedia.org/wiki/Verf%C3%BCgbarkeit Verfügbarkeit Verfübarkeit = !"#$%&'"(&*!"#$%&$+#,$--'"(& !"#$%&'"(& > Downtime: > Geplante Downtime: keine Ausfallzeit > Ungeplante Downtime: Ausfallzeit > Verfügbarkeit 24x7 vollständig > Jede Downtime ist Ausfallzeit Theorien zu Datenbanken bzw. verteilten Systemen > ACID > Atomic – Consistent – Isolated – Durable > „Standard für SQL Datenbanken“ > CAP > Consistency – Availability - Partition Tolerance > Basis für verteilte Datenbanken ACID > Definiert von Jim Gray Ende der 1970er Jahre > „A transaction is a transformation of state which has the properties of atomicity (all or nothing), durability (effects survive failures) and consistency (a correct transformation)“ > Standard für alle relationalen Datenbanksysteme > Atomic: > Atomar oder abgeschlossen > Alles oder Nichts > Consistent > Sequenz von Datenoperationen (Transaktion) hinterlässt einen Konsistenten Zustand > Normalisierung - Fremdschlüssel > Isolated > Mehrere Transaktionen können parallel ablaufen > Eine Transaktion sieht nicht keine Änderungen einer anderen laufenden Transaktion > Durable > Alle Änderungen nach erfolgreichen commit bleiben erhalten > Auch Hard- oder Software Fehler verändern die Daten danach nicht Theorem CAP > Eric Brewer aus dem Jahre 2000 > Im Jahr 2002 veröffentlichten Seth Gilbert und Nancy Lynch vom MIT einen axiomatischen Beweis von Brewers Vermutung, und etablierten diese somit als Theorem > nach dem CAP-Theorem kann ein verteiltes System zwei der folgenden Eigenschaften gleichzeitig erfüllen, jedoch nicht alle drei > Consisteny > Jeder sieht das gleiche > Availibility > In einem Fehlerfall bleibt die Datenbank verfügbar > Partition Tolerence > Das System arbeitet auch bei Verlust von Nachrichten, einzelner Netzknoten oder Partition des Netzes weiter. C > Beispiel: > AP – Domain Name System > CA – Relationales Datenbank Management System > CP – Banking-Anwendungen A P CAP Strict Consistency No Go Consistency Partition Toleranz Availibility Eventual Consistency Ein oder Zwei Rechenzentren > Ein Rechenzentrum > Out of the Box Engineered System > Alle Komponenten Redundant > Zwei Rechnenzentren > Active – Passive > Active – Active > Varianten > Brandschutzabschnitte > Near – Far 1 Active - Active Webscale vs Enterprise: Facebook - Scaling > > > > Probleme viele Millionen User gleichzeitig zu bedienen Lösungen wie RAC (Oracle) konnten die Skalierung nur bedingt abdecken Ökonomisch nicht sinnvoll Lösungen > Memcache – Vorladen von Daten > Sharding – Stückelung der Datenbanken > Sharding > Twitter und Facebook verteilen die Daten auf viele Datenbanken (MySQL) > Verteilt auf Basis eines Key Schlüssels 1 Webscale vs Enterprise: Facebook Sharding Web Server Memcache Datenbank Read Only Slave Shard A-F Shard G-P Shard Q-Z Read Read/write Webscale vs Enterprise: Facebook - aber > Komplexe Applikationen > Es muss das richtige Shard angesprochen werden > Während des Wachstums werden die Teile unterschiedlich verteilt Maintenance > Abgespecktes SQL > Keine Abfragen über alles > Joins werden kompliziert > ACID nicht möglich > Lastverteilung über die Knoten kompliziert > Änderungen an den Shards verlangen extrem hohen Administrativen Aufwand Webscale vs Enterprise: Amazon – DynamoDB System > Continuous Availability > Kleinste Ausfälle Verursachen einen Umsatzeinbruch > Partition Toleranz > Als Globales Unternehmen sollen Ausfälle von Teilen keinen Einfluss auf die Gesamtverfügbarkeit haben > Keine Verlust eine Bestellung oder eines Warenkorbs > Auch bei Benutzung von mehreren Endgeräte sollen alle Daten erhalten bleiben > No exklusiv locks > Effizency > Möglichst gute Responsezeiten der Applikation > „Online customers were notoriously fickle and impatient“ 1 Webscale vs Enterprise: Amazon 1. write A I B 2. write 3. write H C G Anderes Rechenzentrum D F Unterschiedliches Rack E Entscheidung pro Insert Webscale vs Enterprise: Amazon – und mehr > Consistent hashing: > Hashes werden als Primärer Key verwendet.Aufgrund der Hashes werden die Nodes zugeteilt. Ein Rebalancing ist meist nicht notwendig und es ergibt sich ein ausgeglichener Cluster ist möglich. > Tunable consistency: > Es ist möglich die Konsistenz bei einzelnen Operation zu beeinflussen. Dadurch wird entweder eine hohe Schreib- oder Lesegeschwindigkeit erreicht. > strong consistency, eventual consistency, weak consistency > Data versioning: > Dadurch das keine Aktion geblockt wird, ist es möglich, dass mehrere Versionen eines Objekts entstehen können. Dies kann entweder automatisch aufgelöst werden oder der Anwender muss die Konflikte bereinigen. > Wenn ein Objekt von 2 Computern gleichzeitig in den Warenkorb gelegt wird, kann es passieren das es doppelt vorhanden ist. Hier muss der Anwender eingreifen. Webscale vs Enterprise: Oracle SOA Maximum Availability Architecture (MAA) Active-Active > Multi Rechenzentrum Active-Active Deployment > Im Vergleich zu Active-Passive Deployments, muss bei einem Ausfall eine Middletier Seite, die Passive Seite nicht erst gestartet werden > Die Datenbank ist nur in einem Rechenzentrum Aktiv (Active-Passive) > Im Falle eines Ausfalls bzw. Switch der Datenbank werden sofort alle Datasources beider Seiten neu konfiguriert > Desaster Recovery Optimierung – Minimierung von > Recovery Point Objective (RPO) - Zeit, die vom Zeitpunkt des Schadens bis zur vollständigen Wiederherstellung der Geschäftsprozesse verloren vergeht > Recovery Time Objective (RTO) - wie viele Daten/Transaktionen gehen bei einem Systemausfall verloren 2 Webscale vs Enterprise: Oracle SOA Maximum Availability Architecture (MAA) http://www.oracle.com/technetwork/database/availability/fmw11gsoamultidc-aa-1998491.pdf Webscale vs Enterprise: Oracle SOA Maximum Availability Architecture (MAA) Active-Active > Möglichst viele Daten in der Datenbank halten – Tlogs, JMS > asynchronous Kommunikation zwischen 2 ZFS Storage – kein Einfluss auf Produktions Performance > Der Spiegel auf dem stadby ZFS ist garantiert write-order consistent > Status des letzten kompletten Transfers > Patching ist deutlich erschwert im vergleich zu Active-Passive Deployments > Problem – wann switched die Datenbank, Quorum mit 2 Rechenzentren nicht ausreichend 2 Architektur: Oracle Datenbank - Exadata RAC DB ..... ACFS Node x Node 1 Exadata Architektur: Oracle Datenbank – Exadata Active - Passive RAC DB RAC DB ..... ..... ACFS Dataguard Node x Node 1 Exadata ACFS Node x Node 1 Exadata Architektur: Oracle Datenbank – Exadata Active - Active RAC DB RAC DB ..... ..... ACFS ACFS Node x Node 1 Exadata Golden Gate Active-Active Node x Node 1 Exadata Architektur:Vergleich Datenbanken Exadata Patching Features Consistency Partition Tolerance Availibility +/- +/- +++ N/A +++ Exadata Active +++ - Passive 1 +++ +++ +/- * +++ * Exadata Active - Active - - +++ +++ One Exadata ++ *Dataguard Mode 2 Architektur: Oracle Middleware – Single Exalogic OTD - OHS OTD - OHS Weblogic Domäne ..... Weblogic Domäne Node 1 Node x Exalogic Datenbank Architektur: Oracle Middleware – Two Exalogic, Two Domains Loadbalancer OTD - OHS Node 1 Exalogic OTD - OHS OTD - OHS OTD - OHS Weblogic Domäne Weblogic Domäne .... . Weblogic Domäne ..... Node x Weblogic Domäne Node 1 Node x Exalogic Architektur: Oracle Middleware – Two Exalogic, One Domains Loadbalancer OTD - OHS OTD - OHS OTD - OHS OTD - OHS Weblogic Domäne .... . Node 1 Exalogic ..... Weblogic Domäne Node x Node 1 Node x Exalogic Architektur:Vergleich Exalogic Patching Features Caching One Exalogic +/- +/- Two Exalogic,Two Domains 1 +++ --- Two Exalogic, One Domain - +++ Architektur: Exadata und Exalogic Loadbalancer Exalogic Exalogic zwei unabhängig Domänen Grid Link Verbindung Exadata Exadata Data Guard Sync Architektur: Exadata und Exalogic Grid Link Verbindung Verbindung im Aktiven DB Rechenzentrum mit Infiniband, im Standby Rechenzentrum 10 GBit Dataguard Je nach gewählten Einstellung im Dataguard hat es Einfluss auf die Verfügbarkeit und Datenverlust bei Netzwerkausfall zwischen den Rechenzentren * -> Far Sync Patching Middleware Eine Seite/Domäne wird außer Betrieb genommen Patching DB Dataguard Switch Automatischer Switch Bei zwei Rechenzentren nur bedingt möglich -> Observer, Siteguard * http://www.trivadis.com/sites/default/files/downloads/fsfo_understood_decus07.pdf Maintenance: Patching Exadata & Exalogic System Kommentar Rolling Exadata & Exalogic Readme beachten – nur zwischen Minor Releases Exadata Storage Für Rolling Patching High Redundancy dringend empfohlen Dataguard Patch Standby First – während Patchen ggf. kein Failover möglich Exalogic Virtuell Kontrollstack Backup Exalogic Storage Umschaltung der Heads während des Patches, Impact Applikation Exalogic Applikation sind getrennt zu betrachten Immer Prechecks ausführen – detaillierte Planung, nach Release des Patches mind. 2 Wochen warten 3 Maintenance: Oracle Site Guard > Automates DR operations between sites > Preintegrated with the ZFS Storage Appliance Oracle FMW for Oracle Exalogic Elastic Cloud Machine > Preintegrated with Oracle Data Guard for Oracle Exadata Database Machine > > > > Alles aus Cloud Control steuerbar (emcli + GUI) Im Cloud Control in der Software Library abgelegt Dataguard Broker für Dataguard wird unterstützt Abgleich Storage um Dateisystem abzugleichen Maintenance: Oracle Site Guard http://www.oracle.com/technetwork/database/availability/oracle-site-guard-overview-2167478.pdf Maintenance: Dataguard Far Sync http://www.oracle.com/technetwork/database/availability/farsync-2267608.pdf Maintenance: Far Sync Flight Box - Axxana Oracle Database Appliance – Exadata, Exalogic ODA Exa Patching Storage Patches?! Full Rolling Patching Minor Releases (Readme!) – High Redundancy Cloud Control Plugin Full Integrated Size Erweiterung durch Storage Shelfs Frei konfigurierbar – DB Nodes, Exacells, Exalogic Nodes Vielen Dank! 41
