Plone Konferenz München 2012 Ausfallsichere Kultur mit Plone Teil 2 Jens W. Klein <jk@kleinundpartner.at> 23.02.2012 1 von 33
Über uns Jens Klein Geschäftsführer Klein & Partner KG Software Developer and FOSS Enthusiaist KUP - Klein & Partner KG Agentur für Webtechnlogien aus Innsbruck (AT) Fokus auf Python, Zope, Plone, Pyramid, Linux Gründungsmitglied der BlueDynamics Alliance BlueDynamics Alliance Kooperation von 8 Firmen der DACH Region 2 von 33
Der Leidensdruck: Die gewachsene Umgebung 3 von 33
Was war Evolutionär gewachsene Systemstruktur: 3 Server, 1 ohne Wartungsvertrag, 2 veraltet teilweise XEN-Virtualisiert Debian-Systeme tw. veraltet keine bzw. unzureichende Dokumentation der Administrator wechselte den Job Upgrade mit Neuplanung notwendig. 4 von 33
Der Plan: Umbau, Modernisierung, Linux basierte Lösungen 5 von 33
Mission Der ausfallsichere Kulturserver 6 von 33
Ziele Redundanz Sicherheit Performance bei Spitzenlast Gute Ausnutzung vorhandener Hardware Migration auf neue Hardware in Zukunft einfacher Kostengünstig (Hardware, Lizenzen, Wartung) Dokumentation 7 von 33
8 von 33
Dienste Extern: 29 Plone Portale Statische Seiten und sehr wenig PHP DNS (primary/secondary) Intern Reverse-Cache, Load-balancer, Outgoing SMTP, MySQL, Samba, ZEO-Server, Subversion, ssh Testumgebung für neue Plones 9 von 33
Planung Einen neuen Server anschaffen Betrieb mit alten Servern aufrecht erhalten Neuen Server virtualisiert aufsetzen Dienste alter Server iterativ übertragen und Plones aus Shared Instance lösen/ updaten. Besseren alten Server virtualisieren und redundant zu neuem Server konfigurieren Schlechteren alter Server virtualisieren und als Testumgebung nutzen 10 von 33
Achse 1: Virtualisierung 11 von 33
Virtualität...... ist die Eigenschaft einer Sache, nicht in der Form zu existieren, in der sie zu existieren scheint, aber in ihrem Wesen oder ihrer Wirkung einer in dieser Form existierenden Sache zu gleichen. Wikipedia 12 von 33
Vorteile einer Virtuellen Maschine Hardware-Unabhängigkeit: sie können z.b. von alter auf neue Hardware verschoben werden, schnelles Backup und Wiederherstellung einer komplexen Installation möglich, einfache Abtrennung der Dienste gemäß Sicherheitsrichtlinien in versch. NetzwerkZonen innerhalb eines echten Servers, Klonen von Installationen spart Zeit bei gleichförmigen Installationen. 13 von 33
Virtuelle Evolution (1) 14 von 33
Virtuelle Evolution (2) Ubuntu Linux Debian Linux Debian Linux 15 von 33 Debian Linux
Virtuelle Evolution (3) 16 von 33
Eigenschaften einer Virtuellen Maschine eigene virtuelle Festplatte (nur ein File im Mutter-Linux) eigene virtuelle Netzwerkkart(en) virtueller Bildschirm ist VNC Port => Fernwartung CPU-Cores und RAM werden zugeteilt. Priorisierung möglich 17 von 33
Virtualisierungstechnologie KVM (Kernel Based Virtual Maschine) offizielle Linux VM robust gutes Toolset vorhanden: Virtual shell (virsh) qemu-* Basis Betriebssystem Ubuntu 10.04 LTS Ubuntu-eigene Tools und Support Images qcow2 (copy-on-write) 18 von 33
Achse2: Redundanz 19 von 33
Der Begriff Redundanz... bezeichnet allgemein in der Technik das zusätzliche Vorhandensein funktional gleicher oder vergleichbarer Ressourcen eines technischen Systems, wenn diese bei einem störungsfreien Betrieb im Normalfall nicht benötigt werden. Wikipedia 20 von 33
Vorteile und Nachteile von Redundanz Keine Ausfälle bei spontanen Hardwareschäden Security-Upgrades im laufenden Betrieb Hardware-Tausch bei laufendem Betrieb Aufwendiges Einspielen von Datenbank-Backups nach Schäden entfällt Komplexere Konfiguration ist selbst Fehleranfällig Startup-Routinen müssen angepasst werden 21 von 33
Redundante Dienste (1) Normalbetrieb 22 von 33
Redundante Dienste (1) Ausfall eines Servers 23 von 33
Redundanz in der Praxis Bei Hardwareausfall Schaltzeiten von unter 2 Sekunden Public Failover IP-Adressen für NGINX Master/ Slave Filesystem für ZODB, Samba und MySQL Dienste werden regelbasiert in korrekter Reihenfolge gestartet und gestoppt aber: Plone läuft nicht(!) über Corosync (-> pound) 24 von 33
Redundanztechnologie OpenAIS (Beteiligte Knoten + Benachrichtigung) Pacemaker (Cluster Resource Manager) mit Regelsystem zur Clustersteuerung Corosync Cluster Engine (Implementierung/ Integration obiger Dienste, Sicherstellung der Service Verfügbarkeit ) OSF-Scripte zu Service Start/Stop/Status (Erweiterung von Linux Standard Base InitScripten) DRBD Blockdevice (Filesystem) Replikation 25 von 33
Achse 3: Webpublishing 26 von 33
Webpublishing als Verkettung von spezialisierten Diensten HTTP-Request wird von NGINX Webserver angenommen und vollständig gepuffert Varnish Proxy Cache bekommt HTTP-Request, wenn im Cache wird direkt ausgeliefert. Pound Load-Balancer bekommt HTTP-Request und sucht im Round-Robin Verfahren einen verfügbaren ZEO-Client (Plone). Plone bekommt den HTTP-Request, lädt sich Objekte aus der ZODB und rendert die Seite, liefert aus (HTTP-Response). 27 von 33
Webpublishing bei der Nöku Request/ Response 28 von 33
Webpublishing Vorteile der Verkettung Webserver federt Requests ab (buffering) Proxy-Cache nimmt Last vom Plone Weg Elemente aus dem Cache sind schneller beim Webbrowser Spitzenlasten können abgefangen werden Load-Balancing verteilt Spitzenlast und Ausfall einer Maschine/ einzelner ZEO-Clients möglich Dynamische horizontale Skalierung durch Hinzufügen von weiterer Maschinen möglich 29 von 33
Die Orchestrierung 30 von 33
Zusammenspiel in voller Besetzung unter Nutzung der Resourcen 31 von 33
Kleine Besetzung bei Ausfall eines Servers 32 von 33
Diskussion Fragen 33 von 33