1. Plone Konferenz München 2012 Ausfallsichere Kultur mit Plone Teil 2 Jens W. Klein <jk@kleinundpartner.at> 23.02. 2012

4. Fokus auf Python, Zope, Plone, Pyramid, Linux

6. Der Leidensdruck: Die gewachsene Umgebung

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

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

23. Statische Seiten und sehr wenig PHP

25. Testumgebung für neue Plones

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

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)

42. eigene virtuelle Netzwerkkart(en)

43. virtueller Bildschirm ist VNC Port => Fernwartung

44. CPU-Cores und RAM werden zugeteilt.

45. Priorisierung möglich

47. „offizielle“ Linux VM

48. robust

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

54. Security-Upgrades im laufenden Betrieb

55. Hardware-Tausch bei laufendem Betrieb

57. Startup-Routinen müssen angepasst werden

58. Redundante Dienste (1) Normalbetrieb

59. Redundante Dienste (1) Ausfall eines Servers

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)

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

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

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