Das Dokument behandelt die Implementierung und den Betrieb von Microservices und Container-Management mit Mesosphere DC/OS im IT-Systemhaus der Bundesagentur für Arbeit. Es beschreibt die Systemarchitektur, Betriebsempfehlungen, Sicherheitsaspekte und Lessons Learned aus einem Jahr Produktionsbetrieb. Es wird betont, dass die Technologie zuverlässig ist und eine gute Akzeptanz in der Entwicklung erreicht wurde, jedoch auch die Notwendigkeit von Automatisierung und standardisierten Vorgehensweisen hervorgehoben.

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
???