View
1.169
Download
2
Category
Preview:
Citation preview
Ausfallsichere Kultur mit Plone
Plone Konferenz
Mnchen 2012
Ausfallsichere Kulturmit Plone
Teil 2
Jens W. Klein 23.02.2012
Dank Roland, ich mchte jetzt ein wenig in die Welt der Virtualisierung, der Redundanz und des technischen Webpublishings mit Plone eintauchen.
Wenn dies fr Sie noch Fremdwrter sind bleiben Sie trotzdem sitzen. Ich versuche behutsam die Begriffe zu erklren.
ber uns
Jens KleinGeschftsfhrer Klein & Partner KG
Software Developer and FOSS Enthusiaist
KUP - Klein & Partner KGAgentur fr Webtechnlogien aus Innsbruck (AT)
Fokus auf Python, Zope, Plone, Pyramid, Linux
Grndungsmitglied der BlueDynamics Alliance
BlueDynamics AllianceKooperation von 8 Firmen der DACH Region
Kurz zu meiner Person: Mein Name ist Jens Klein. Ich bin Geschftsfhrer von Klein und Partner in Innsbruck.
Der Leidensdruck:
Die gewachsene Umgebung
Gleich mit Frage starten:
Wer betreibt in seiner Organisation eigene Server? Wer davon hat eine evolutionr gewachsene Umgebung?
Das hat viele Vorteile, aber eben auch Nachteile. Cloud-Computing soll ja das Allheilmittel sein. Der Kontrollverlust wird weggerechnet. Wir glauben ein guter Mittelweg fhrt auch zum Ziel!
Meist sind gewachsene Umgebungen nicht hbsch. Admin Willi hat was aufgesetzt wo sein Nachfolger nur noch die Hnde ber dem Kopf zusammenschlgt.
Ganz so schlimm war es bei der Nku nicht...
Was war
Evolutionr 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.
Admin war auch Webeentwickler.
Der Plan:
Umbau, Modernisierung, Linux basierte Lsungen
Die Basis war ein altes Debian Linux und im Prinzip waren es seine Stabilitt und Wartungsfreundlichkeit die trotzdem alles am Leben hielt. Und es gibt fr Debian sehr viel allgemeine Dokumentation.
Das Bewhrte soll zu recht behalten werden.
Nur das Konzept drumherum musste erneuert werden.
Hier war ein Projekt notwendig.
Mission
Der ausfallsichere Kulturserver
Es hat viele Webportale und viele Dienste bei der Nku. Diese mssen alle gehostet werden.
Wir knnen fr alles einen Server hinstellen. Viel Hardware. Viel Wartung, viel kann ausfallen. Teuer ist es auch.
Also fr jeden Dienst zwei Server?
Aktuelle Hardware ist sehr leistungsfhig. Also setzten wir auf Virtualisierung. Aber diesmal strukturiert.
Ziele
Redundanz
Sicherheit
Performance bei Spitzenlast
Gute Ausnutzung vorhandener Hardware
Migration auf neue Hardware in Zukunft einfacher
Kostengnstig (Hardware, Lizenzen, Wartung)
Dokumentation
Ziele wurden definiert. Hier die wichtigsten.
Dann konnte die Show starten.
Dienste
Extern:29 Plone Portale
Statische Seiten und sehr wenig PHP
DNS (primary/secondary)
InternReverse-Cache, Load-balancer, Outgoing SMTP, MySQL, Samba, ZEO-Server, Subversion, ssh
Testumgebung fr neue Plones
Das wichtigeste waren die Plone Seiten, aber auch andere Dienste sind involviert.
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 lsen/ updaten.
Besseren alten Server virtualisieren und redundant zu neuem Server konfigurieren
Schlechteren alter Server virtualisieren und als Testumgebung nutzen
Die Neuinstallation musste sukkzessiv passieren, der laufende Betrieb sollte so wenig wie mglich unterbrochen werden. Es sollte ein fliessender bergang werden.
Was wir hier nicht richtig eingeschtzt hatten war der Gesamtzeitraum.
Aus wenigen Monaten wurde schlielich ber ein Jahr. Mit anschliessendem Update auf Debian Squeeze. Alle Dinge sind im Fluss, sogar Debian.
Achse 1: Virtualisierung
Wer von Ihnen hat einen virtuellen Server gemietet oder einen Cloud-Dienst gebucht?
Wer betreibt eine eigene Virtualisierungsumgebung?
VMWare ESX?
Linux-basierte Lsungen wie XEN, KVM, OpenVZ?
Virtualitt ...
... 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
Vorteile einer
Virtuellen Maschine
Hardware-Unabhngigkeit: sie knnen z.B. von alter auf neue Hardware verschoben werden,
schnelles Backup und Wiederherstellung einer komplexen Installation mglich,
einfache Abtrennung der Dienste gem Sicherheitsrichtlinien in versch. Netzwerk-Zonen innerhalb eines echten Servers,
Klonen von Installationen spart Zeit bei gleichfrmigen Installationen.
Virtuelle Evolution (1)
Wir haben klassischerweise eine Server. Einen echten physikalisch vorhandenen zum Anfassen.
Da installieren wir ein Beriebssystem drauf. Z.B. Linux, Ubuntu Linux
Virtuelle Evolution (2)
Ubuntu Linux
Debian Linux
Debian Linux
Debian Linux
Jetzt kommen dort virtuelle Maschinen drauf. Bei der Nku sind es sechs.
Aber zum Verstehen wie das funktioniert sind drei genau richtig.
Virtuelle Evolution (3)
Drei pro Server.
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 mglich
Virtualisierungs-technologie
KVM (Kernel Based Virtual Maschine)
offizielle Linux VM
robust
gutes Toolset vorhanden:Virtual shell (virsh)
qemu-*
Basis Betriebssystem Ubuntu 10.04 LTSUbuntu-eigene Tools und Support
Images qcow2 (copy-on-write)
Achse2: Redundanz
Ausfallsicherheit.
Der Begriff Redundanz
... bezeichnet allgemein in der Technik das zustzliche Vorhandensein funktional gleicher oder vergleichbarer Ressourcen eines technischen Systems, wenn diese bei einem strungsfreien Betrieb im Normalfall nicht bentigt werden.
Wikipedia
Im Flugzeug ist z.B. alles doppelt, ausfallsicher, redundant.
Und wenn nur ein System ausfllt wird meist schon notgelandet.
So ist es uns auf dem Rckflug von der Plone Conference im Herbst in SF gegangen. Ein Notsauerstofftank fr die Piloten viel aus. Chicago lie uns erst 24h spter wieder los.
Webserver laufen auch gut auf einem System noch weiter, dennoch sollten man zusehen, dass man die Redundanz bald wieder herstellt.
Vorteile und Nachteile
von Redundanz
Keine Ausflle bei spontanen Hardwareschden
Security-Upgrades im laufenden Betrieb
Hardware-Tausch bei laufendem Betrieb
Aufwendiges Einspielen von Datenbank-Backups nach Schden entfllt
Komplexere Konfiguration ist selbst Fehleranfllig
Startup-Routinen mssen angepasst werden
Redundante Dienste (1)
Normalbetrieb
Bei der Nku laufen der Webserver und die Datenbank direkt redundant. Dazu werden immer Paare gleich konfigurierter (geklonter) Virtueller Maschinen gebildet.
Um die Datenbestnde redundant zu halten wird das Filesystem stndig vom aktiven auf das inaktive System kopiert oder repliziert.
Die Kontrolle hat eine Software, die stndig prft ob die aktive Schwestermaschine noch da ist und falls nicht umschaltet.
Plone wird anders redundant gehalten, dazu komme ich spter.
Redundante Dienste (1)
Ausfall eines Servers
Redundanz in der Praxis
Bei Hardwareausfall Schaltzeiten von unter 2 Sekunden
Public Failover IP-Adressen fr NGINX
Master/ Slave Filesystem fr ZODB, Samba und MySQL
Dienste werden regelbasiert in korrekter Reihenfolge gestartet und gestoppt
aber: Plone luft nicht(!) ber Corosync (-> pound)
Redundanztechnologie
OpenAIS (Beteiligte Knoten + Benachrichtigung)
Pacemaker (Cluster Resource Manager) mit Regelsystem zur Clustersteuerung
Corosync Cluster Engine (Implementierung/ Integration obiger Dienste, Sicherstellung der Service Verfgbarkeit )
OSF-Scripte zu Service Start/Stop/Status (Erweiterung von Linux Standard Base Init-Scripten)
DRBD Blockdevice (Filesystem) Replikation
Achse 3: Webpublishing
Technisch ist Webpublishing der Vorgang bei dem ein Webbrowser (IE, FF, Safari, usw). Eine Anfrage an abschickt und ein Webserver daraufhin eine Antwort mit einer Webseite, einem Bild oder anderen Medien zurueckschickt.
Webpublishing als Verkettung von
spezialisierten Diensten
HTTP-Request wird von NGINX Webserver angenommen und vollstndig 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 verfgbaren ZEO-Client (Plone).
Plone bekommt den HTTP-Request, ldt sich Objekte aus der ZODB und rendert die Seite, liefert aus (HTTP-Response).
Webpublishing
bei der Nku
Request/
Response
Webpublishing
Vorteile der Verkettung
Webserver federt Requests ab (buffering)
Proxy-Cache nimmt Last vom Plone WegElemente aus dem Cache sind schneller beim Webbrowser
Spitzenlasten knnen abgefangen werden
Load-Balancing verteilt Spitzenlast undAusfall einer Maschine/ einzelner ZEO-Clients mglich
Dynamische horizontale Skalierung durch Hinzufgen von weiterer Maschinen mglich
Die Orchestrierung
Wir haben Virtualisierung, Redundanz und Verkettetes Webpusblishing.
Das Orchester spielt auf.
Und soll dabei seine Mglichkeiten voll ausnuzten.
Zusammenspiel in voller Besetzung unter Nutzung der Resourcen
Kleine Besetzung bei Ausfall eines Servers
Diskussion
Fragen
Klicken Sie, um das Format des Titeltextes zu bearbeiten
Klicken Sie, um die Formate des Gliederungstextes zu bearbeitenZweite GliederungsebeneDritte GliederungsebeneVierte GliederungsebeneFnfte GliederungsebeneSechste GliederungsebeneSiebente GliederungsebeneAchte GliederungsebeneNeunte Gliederungsebene
Text: Creative Commons Namensnennung-Keine kommerzielle Nutzung- Keine Bearbeitung 3.0 sterreich Lizenz.
von
Recommended