Plone Konferenz München 2012 Ausfallsichere Kultur mit Plone Teil 2 Jens W. Klein <jk@kleinundpartner.at> 23.02. 2012
Über uns <ul><li>Jens Klein </li><ul><li>Geschäftsführer Klein & Partner KG
Software Developer and FOSS Enthusiaist </li></ul><li>KUP - Klein & Partner KG </li><ul><li>Agentur für Webtechnlogien aus...
Fokus auf Python, Zope, Plone, Pyramid, Linux
Gründungsmitglied der BlueDynamics Alliance </li></ul><li>BlueDynamics Alliance </li><ul><li>Kooperation von 8 Firmen der ...
Der Leidensdruck: Die gewachsene Umgebung
Was war Evolutionär gewachsene Systemstruktur: <ul><li>3 Server, 1 ohne Wartungsvertrag, 2 veraltet
teilweise XEN-Virtualisiert
Debian-Systeme tw. veraltet
keine bzw. unzureichende Dokumentation
der Administrator wechselte den Job </li></ul>->  Upgrade mit Neuplanung notwendig.
Der Plan: Umbau, Modernisierung, Linux basierte Lösungen
Mission Der ausfallsichere Kulturserver
Ziele <ul><li>Redundanz
Sicherheit
Performance bei Spitzenlast
Gute Ausnutzung vorhandener Hardware
Migration auf neue Hardware in Zukunft  einfacher
Kostengünstig (Hardware, Lizenzen, Wartung)
Dokumentation </li></ul>
 
Dienste Extern: <ul><li>29 Plone Portale
Statische Seiten und sehr wenig PHP
DNS (primary/secondary) </li></ul>Intern <ul><li>Reverse-Cache, Load-balancer, Outgoing SMTP, MySQL, Samba, ZEO-Server, Su...
Testumgebung für neue Plones </li></ul>
Planung <ul><li>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 </li></ul>
Achse 1: Virtualisierung
Virtualität ... ... ist die Eigenschaft einer Sache, nicht in der Form zu existieren, in der sie zu existieren scheint, ab...
Prochain SlideShare
Chargement dans…5
×

Ausfallsichere Kultur mit Plone

1 237 vues

Publié le

Redundanter Kulturserver der Niederösterreich Kulturwirtschaft GmbH

Publié dans : Technologie
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Ausfallsichere Kultur mit Plone

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

×