Slides in german from a talk I gave at W-JAX 2017 about Mesosphere DC/OS at ITSYS of BA

1. Microservices und Container Management mit
Mesosphere DC/OS
IT-Systemhaus der BA - November 2017

2. Seite 2
IT-Systemhaus der BA - Full-Service IT-Provider für
die Bundesagentur für Arbeit

3. Seite 3
Über das IT-Systemhaus der BA -
Zahlen und Fakten

4. Seite 4
Über mich
Ralf Ernst
Senior-IT-Architekt beim IT-Systemhaus der BA
Twitter: @ralfernst

5. Seite 5
Microservices und Container Management
▬ es existiert nicht nur Conways Law
▬ sondern leider auch Murphys Law
▬ verteilte Systeme sind tückisch
▬ aber es gibt Plattformen

6. Seite 6
Mesosphere DC/OS im BA-ITSYS
▬ DC/OS ist aktuell im BA-ITSYS die Produktionsplattform für
kritische Services für arbeitsagentur.de
PoC mit
Mesos und
Marathon
2/2016 9/2016 11/2016 4/2017 12/2017
Einführung
Mesosphere
DC/OS
Dev/Test
Cluster
bereit
Produktions
betrieb mit
10 Services
Produktions
betrieb mit
25-30
Services

7. Seite 7
Mesosphere DC/OS

8. Seite 8
Mesosphere DC/OS – Bestandteile
© Mesosphere Inc. - 2017

9. Seite 9
Wir haben eine Plattform! What could possibly go
wrong?

10. Seite 10
Betrieb von Containern mit Mesosphere DC/OS
▬ Infrastruktur
▬ Plattform
▬ außerhalb des Clusters
▬ innerhalb des Clusters

11. Seite 11
Infrastruktur

12. Seite 12
Deployment-Architektur der DC/OS Komponenten
All Nodes
Master Nodes Agent Nodes

13. Seite 13
DC/OS Node Types

14. Seite 14
Systemarchitektur - Mesosphere DC/OS Dev/Test
Cluster im BA-ITSYS
DC/OS-Cluster Dev/Test

15. Seite 15
Systemarchitektur - Mesosphere DC/OS
Produktions-Cluster im BA-ITSYS auf 2 Standorten
DC/OS-Cluster Thf DC/OS-Cluster Vdt

16. Seite 16
Systemarchitektur - Multi-Data-Center
▬ Identische Cluster für Dev/Test und Produktion
▬ Produktion aktiv-aktiv auf 2 Standorten
▬ x-86 Standard Hardware, lokaler Storage (DAS)
▬ 2 unabhängige DC/OS Installationen in Produktion
▬ Netztrennung über Firewalls
▬ Adressierung über Hardware-Loadbalancer
• Healthcheck Container erlauben kontrolliertes Entfernen eines Standorts

17. Seite 17
Implikationen der Systemarchitektur Multi
Data-Center aktiv-aktiv
▬ Container: stateless
▬ Messaging: Apache Kafka Cluster lokal, Replikation mit Mirrormaker
▬ Persistenz: Apache Cassandra Ringe, standortübergreifend
▬ Suche: Elasticsearch Cluster, lokal
▬ BASE: basic availability, soft-state, eventual consistency

18. Seite 18
Plattform

19. Seite 19
Architektur Mesos

20. Seite 20
Empfehlungen
▬ HA von Anfang an
• 3 Master, >2 Public Nodes, >5 Private Nodes pro Standort
• Nodes müssen unabhängig voneinander abschaltbar sein
• keine großen, lieber mehr kleine Server verwenden (horizontal skalieren)
▬ Automatisierung von Anfang an
• ein Cluster automatisch (wieder-)herstellen
• automatisiert Nodes aus dem Cluster entfernen und wieder hinzufügen
bzw.neue Nodes provisionieren und zum Cluster hinzufügen
▬ Logging, Monitoring von Anfang an
• Log-Aggregation und Auswertung (ELK, Graylog), Mesos Metrics

21. Seite 21
Lessons Learned
▬ regelmäßiges Testen der Recovery-Features
• produktionsidentischer Aufbau, mit den entsprechenden Applikationen
• real world Ausfälle und Wartungen unter Last
▬ Upgrades ohne Downtime
• keine Versionen überspringen, Backups anfertigen
▬ DC/OS unterstützt unterbrechungsfreien Betrieb
• Wartungen und Upgrades zu “normalen” Bürozeiten ohne Downtime
• Gotcha: Docker Demon nicht unter Kontrolle des Mesos Agents!

22. Seite 22
außerhalb des Clusters

23. Seite 23
Routing
▬ Routing von Kommunikation in und aus dem Cluster
ausschließlich über Reverse Proxies auf den public agents
▬ DC/OS verwendet marathon-lb als Edge Loadbalancer
• Lastverhalten, Redundanz!
• bei Anwendungen mit hoher Last evtl. dedizierte Instanzen hinzufügen
▬ zusätzlich Proxies zur gesicherten Kommunikation aus dem
Cluster heraus erforderlich
• im BA-ITSYS: Docker-Container mit Squid-Proxy

24. Seite 24
Administration
▬ Routing von Administrationszugriffen über den DC/OS
Admin-Router in eigener Netzzone
▬ Bastion-Hosts als Proxies zum Admin-Router
• Redundanz, 2 Standorte
• DC/OS CLI, Http-Proxy zur UI
• Bootstrap-Node für Installation DC/OS
▬ Nutzung des IAM von DC/OS
• Rollen: superuser, SRE-Team, Entwickler (Namespace des Produkts)

25. Seite 25
innerhalb des Clusters

26. Seite 26
Sicherheit im Cluster
▬ Achten auf
• Base-Images, Benutzerprivilegien, Sandbox-escapes
• Verschlüsselung interner Kommunikation
• DC/OS strict-mode verwenden
▬ Deployments ausschließlich über standardisierte CD-Pipeline
• Quality Gates (aktuelle Base-Images, Image-Scans)
• Validierung von Dockerfile und Marathon app-definition
• Template für Marathon app-definition um sinnvolle Defaults zu erzwingen

27. Seite 27
Standards
▬ Base Images
▬ CD-Pipeline
▬ bridged Netzwerk
▬ local-persistent-volumes
▬ Produktauswahl / Betrieb für Persistenz und Messaging nicht
durch Entwicklerteams
▬ Housekeeping (Images, laufende Container in Dev/Test)

28. Seite 28
Isolation
▬ Nutzung von constraints und Mesos-Host-Rollen für eine
sinnvolle Verteilung der Container
▬ Limitierung von Schaden durch Hardware-Ausfälle / Wartung
▬ Limitierung von Schaden, den Benutzer verursachen können
• gegenüber anderen Benutzern aber auch gegenüber Plattformdiensten
▬ Verhinderung kaskadierender Fehler
• asynchrone Kommunikation, Circuit-Breaker, Time-Outs, Replikation

29. Seite 29
Dimensionierung von Containern im Cluster
▬ BA-ITSYS: Nutzung von CPU-shares
• anfangs Probleme mit over-subscription, jetzt Default: 0,1 = fair-share
• CPU-share ist ein weiches Limit
▬ Problem Swapping
• Default cgroups: swap = 2 * memory
• zu wenig RAM → viele swappende Container → Swap-Space voll
• Abhilfe: Übergabe des docker-Parameters memory-swap = mem
▬ Lessons Learned: Container-RAM nicht zu klein dimensionieren
ggf. Swapping auf LINUX-Ebene ganz abschalten

30. Seite 30
Java und Linux Container

31. Seite 31
die JVM ist -aktuell- nicht container-aware
▬ die JVM hat keinerlei Kenntnis von cgroups
• erste Anpassungen in JDK9 und JDK8-151 “experimental”
▬ Initialisierung der JVM erfolgt mit
• RAM: sysconf(_SC_PHYS_PAGES) * sysconf(_SC_PAGESIZE);
• CPU: sysconf(_SC_NRPROCESSORS_ONLN);
▬ Anzahl verfügbarer Threads potentiell viel zu hoch
• z.B. ParallelGCThreads, Anzahl Threads für JIT, HotSpot Optimierungen
▬ Begrenzung von RAM-Verbrauch zwingend
• -Xmx, -Xms, -XX:MaxMetaspaceSize (ex PermGen, off-Heap)

32. Seite 32
Bei der Dimensionierung des Container-RAMs darf
nicht nur der Heap berücksichtigt werden
▬ einige Werte:
• JRE8: ca. 256M
• Code Cache für JIT JRE8: 96M
• Threads: 1M bei 64 Bit-Systemen
• NIO mit Direct Buffer (off heap)
• OS Tools: ca. 60MB bei RHEL
• I/O: Page Cache des Betriebssystems für I/O
▬ Java 8 Threading nutzt sog. malloc arenas:
• 64MB virtual memory pro Thread
• Folge: virtual memory steigt kontinuierlich

33. Seite 33
Thanks for the RAM!

34. Seite 34
Fazit

35. Seite 35
Lessons Learned - Container-Technologie
▬ Produktionsbetrieb mit LINUX-Containern auf DC/OS ist auch für
eine klassische Enterprise-IT Organisation machbar
▬ Empfehlungen:
• keine eigene komplette PaaS bauen
• Integration beachten
• frühzeitig Standards definieren
• Think big: Automatisierung, HA, Security und Monitoring realisieren
• Start small: mit wenig Containern früh in Produktion

36. Seite 36
Microservices und Container Management mit
Mesosphere DC/OS
ein erstes (Zwischen-)Fazit nach einem Jahr DC/OS:
▬ zuverlässig, keinerlei “on-call-events” in Produktion
▬ gute Akzeptanz in der Entwicklung
▬ Möglichkeit, moderne Technologien mit geringem Aufwand
einzusetzen, auszuprobieren und zu betreiben
▬ für das BA-ITSYS ist diese Technologie auch ein Einstieg in neue
Denkmuster wie DevOps, Resilienz, Continuous Delivery

37. Seite 37
Fragen
???