Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Ausfallsichere Kultur mit Plone

  • 941 views
Uploaded on

Redundanter Kulturserver der Niederösterreich Kulturwirtschaft GmbH

Redundanter Kulturserver der Niederösterreich Kulturwirtschaft GmbH

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
941
On Slideshare
938
From Embeds
3
Number of Embeds
2

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 3

http://127.0.0.1 2
http://localhost 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Dank Roland, ich möchte jetzt ein wenig in die Welt der Virtualisierung, der Redundanz und des technischen Webpublishings mit Plone eintauchen. Wenn dies für Sie noch Fremdwörter sind bleiben Sie trotzdem sitzen. Ich versuche behutsam die Begriffe zu erklären.
  • Kurz zu meiner Person: Mein Name ist Jens Klein. Ich bin Geschäftsführer von Klein und Partner in Innsbruck.
  • Gleich mit Frage starten: Wer betreibt in seiner Organisation eigene Server? Wer davon hat eine evolutionär 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 führt auch zum Ziel! Meist sind gewachsene Umgebungen nicht hübsch. Admin Willi hat was aufgesetzt wo sein Nachfolger nur noch die Hände über dem Kopf zusammenschlägt. Ganz so schlimm war es bei der Nöku nicht...
  • Admin war auch Webeentwickler.
  • Die Basis war ein altes Debian Linux und im Prinzip waren es seine Stabilität und Wartungsfreundlichkeit die trotzdem alles am Leben hielt. Und es gibt für Debian sehr viel allgemeine Dokumentation. Das Bewährte soll zu recht behalten werden. Nur das Konzept drumherum musste erneuert werden. Hier war ein Projekt notwendig.
  • Es hat viele Webportale und viele Dienste bei der Nöku. Diese müssen alle gehostet werden. Wir können für alles einen Server hinstellen. Viel Hardware. Viel Wartung, viel kann ausfallen. Teuer ist es auch. Also für jeden Dienst zwei Server? Aktuelle Hardware ist sehr leistungsfähig. Also setzten wir auf Virtualisierung. Aber diesmal strukturiert.
  • Ziele wurden definiert. Hier die wichtigsten.
  • Dann konnte die Show starten.
  • Das wichtigeste waren die Plone Seiten, aber auch andere Dienste sind involviert.
  • Die Neuinstallation musste sukkzessiv passieren, der laufende Betrieb sollte so wenig wie möglich unterbrochen werden. Es sollte ein fliessender Übergang werden. Was wir hier nicht richtig eingeschätzt hatten war der Gesamtzeitraum. Aus wenigen Monaten wurde schließlich über ein Jahr. Mit anschliessendem Update auf Debian Squeeze. Alle Dinge sind im Fluss, sogar Debian.
  • Wer von Ihnen hat einen virtuellen Server gemietet oder einen Cloud-Dienst gebucht? Wer betreibt eine eigene Virtualisierungsumgebung? VMWare ESX? Linux-basierte Lösungen wie XEN, KVM, OpenVZ?
  • Wir haben klassischerweise eine Server. Einen echten physikalisch vorhandenen zum Anfassen. Da installieren wir ein Beriebssystem drauf. Z.B. Linux, Ubuntu Linux …
  • Jetzt kommen dort virtuelle Maschinen drauf. Bei der Nöku sind es sechs. Aber zum Verstehen wie das funktioniert sind drei genau richtig.
  • Drei pro Server.
  • Ausfallsicherheit.
  • Im Flugzeug ist z.B. alles doppelt, ausfallsicher, redundant. Und wenn nur ein System ausfällt wird meist schon „notgelandet“. So ist es uns auf dem Rückflug von der Plone Conference im Herbst in SF gegangen. Ein Notsauerstofftank für die Piloten viel aus. Chicago ließ uns erst 24h später wieder los. Webserver laufen auch gut auf einem System noch weiter, dennoch sollten man zusehen, dass man die Redundanz bald wieder herstellt.
  • Bei der Nöku laufen der Webserver und die Datenbank direkt redundant. Dazu werden immer Paare gleich konfigurierter (geklonter) Virtueller Maschinen gebildet. Um die Datenbestände redundant zu halten wird das Filesystem ständig vom aktiven auf das inaktive System kopiert – oder repliziert. Die Kontrolle hat eine Software, die ständig prüft ob die aktive Schwestermaschine noch da ist und falls nicht umschaltet. Plone wird anders redundant gehalten, dazu komme ich später.
  • 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.
  • Wir haben Virtualisierung, Redundanz und Verkettetes Webpusblishing. Das Orchester spielt auf. Und soll dabei seine Möglichkeiten voll ausnuzten.

Transcript

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