SlideShare ist ein Scribd-Unternehmen logo
1 von 37
Microservices und Container Management mit
Mesosphere DC/OS
IT-Systemhaus der BA - November 2017
Seite 2
IT-Systemhaus der BA - Full-Service IT-Provider für
die Bundesagentur für Arbeit
Seite 3
Über das IT-Systemhaus der BA -
Zahlen und Fakten
Seite 4
Über mich
Ralf Ernst
Senior-IT-Architekt beim IT-Systemhaus der BA
Twitter: @ralfernst
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
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
Seite 7
Mesosphere DC/OS
Seite 8
Mesosphere DC/OS – Bestandteile
© Mesosphere Inc. - 2017
Seite 9
Wir haben eine Plattform! What could possibly go
wrong?
Seite 10
Betrieb von Containern mit Mesosphere DC/OS
▬ Infrastruktur
▬ Plattform
▬ außerhalb des Clusters
▬ innerhalb des Clusters
Seite 11
Infrastruktur
Seite 12
Deployment-Architektur der DC/OS Komponenten
All Nodes
Master Nodes Agent Nodes
Seite 13
DC/OS Node Types
Seite 14
Systemarchitektur - Mesosphere DC/OS Dev/Test
Cluster im BA-ITSYS
DC/OS-Cluster Dev/Test
Seite 15
Systemarchitektur - Mesosphere DC/OS
Produktions-Cluster im BA-ITSYS auf 2 Standorten
DC/OS-Cluster Thf DC/OS-Cluster Vdt
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
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
Seite 18
Plattform
Seite 19
Architektur Mesos
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
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!
Seite 22
außerhalb des Clusters
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
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)
Seite 25
innerhalb des Clusters
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
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)
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
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
Seite 30
Java und Linux Container
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)
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
Seite 33
Thanks for the RAM!
Seite 34
Fazit
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
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
Seite 37
Fragen
???

Weitere ähnliche Inhalte

Was ist angesagt?

MySQL Performance Tuning für Oracle-DBA's
MySQL Performance Tuning für Oracle-DBA'sMySQL Performance Tuning für Oracle-DBA's
MySQL Performance Tuning für Oracle-DBA'sFromDual GmbH
 
Der Datenbank-Backup ist gemacht - was nun?
Der Datenbank-Backup ist gemacht - was nun?Der Datenbank-Backup ist gemacht - was nun?
Der Datenbank-Backup ist gemacht - was nun?FromDual GmbH
 
Weltweite Produktionsdatenverwaltung mit MySQL-Replikation
Weltweite Produktionsdatenverwaltung mit MySQL-ReplikationWeltweite Produktionsdatenverwaltung mit MySQL-Replikation
Weltweite Produktionsdatenverwaltung mit MySQL-ReplikationFromDual GmbH
 
MySQL Backup/Recovery
MySQL Backup/RecoveryMySQL Backup/Recovery
MySQL Backup/RecoveryFromDual GmbH
 
MySQL High Availability Solutions
MySQL High Availability SolutionsMySQL High Availability Solutions
MySQL High Availability SolutionsFromDual GmbH
 
MySQL - New Features 5.6
MySQL - New Features 5.6MySQL - New Features 5.6
MySQL - New Features 5.6FromDual GmbH
 
Einführung in Elasticsearch - August 2014
Einführung in Elasticsearch - August 2014Einführung in Elasticsearch - August 2014
Einführung in Elasticsearch - August 2014inovex GmbH
 
DAOG SIG: HA Architekturen mit MySQL
DAOG SIG: HA Architekturen mit MySQLDAOG SIG: HA Architekturen mit MySQL
DAOG SIG: HA Architekturen mit MySQLFromDual GmbH
 
Tipps zur Performanceoptimierung für Liferay Portal
Tipps zur  Performanceoptimierung für Liferay PortalTipps zur  Performanceoptimierung für Liferay Portal
Tipps zur Performanceoptimierung für Liferay PortalStefan Hilpp
 
DOAG 2011: MySQL Replication
DOAG 2011: MySQL ReplicationDOAG 2011: MySQL Replication
DOAG 2011: MySQL ReplicationFromDual GmbH
 
FROSCON 2011: MySQL Performance Tuning
FROSCON 2011: MySQL Performance TuningFROSCON 2011: MySQL Performance Tuning
FROSCON 2011: MySQL Performance TuningFromDual GmbH
 
DOAG 2011: MySQL Performance Tuning
DOAG 2011: MySQL Performance TuningDOAG 2011: MySQL Performance Tuning
DOAG 2011: MySQL Performance TuningFromDual GmbH
 
Nagios Conference 2007 | Vmware Monitoring by Ingo Latschner
Nagios Conference 2007 | Vmware Monitoring by Ingo LatschnerNagios Conference 2007 | Vmware Monitoring by Ingo Latschner
Nagios Conference 2007 | Vmware Monitoring by Ingo LatschnerNETWAYS
 
MySQL Replication for Beginners
MySQL Replication for BeginnersMySQL Replication for Beginners
MySQL Replication for BeginnersFromDual GmbH
 
FROSCON 2011: MySQL Replication
FROSCON 2011: MySQL ReplicationFROSCON 2011: MySQL Replication
FROSCON 2011: MySQL ReplicationFromDual GmbH
 
Webanwendungen mit Apache HBase entwickeln
Webanwendungen mit Apache HBase entwickelnWebanwendungen mit Apache HBase entwickeln
Webanwendungen mit Apache HBase entwickelnRoman Roelofsen
 
DOAG SIG: MySQL Replikation, Scale-Out, Master- Master Replikation, Backup
DOAG SIG: MySQL Replikation, Scale-Out, Master- Master Replikation, BackupDOAG SIG: MySQL Replikation, Scale-Out, Master- Master Replikation, Backup
DOAG SIG: MySQL Replikation, Scale-Out, Master- Master Replikation, BackupFromDual GmbH
 
Internet Briefing 2011: NoSQL with MySQL
Internet Briefing 2011: NoSQL with MySQLInternet Briefing 2011: NoSQL with MySQL
Internet Briefing 2011: NoSQL with MySQLFromDual GmbH
 

Was ist angesagt? (20)

MySQL Performance Tuning für Oracle-DBA's
MySQL Performance Tuning für Oracle-DBA'sMySQL Performance Tuning für Oracle-DBA's
MySQL Performance Tuning für Oracle-DBA's
 
Der Datenbank-Backup ist gemacht - was nun?
Der Datenbank-Backup ist gemacht - was nun?Der Datenbank-Backup ist gemacht - was nun?
Der Datenbank-Backup ist gemacht - was nun?
 
Weltweite Produktionsdatenverwaltung mit MySQL-Replikation
Weltweite Produktionsdatenverwaltung mit MySQL-ReplikationWeltweite Produktionsdatenverwaltung mit MySQL-Replikation
Weltweite Produktionsdatenverwaltung mit MySQL-Replikation
 
MySQL Backup/Recovery
MySQL Backup/RecoveryMySQL Backup/Recovery
MySQL Backup/Recovery
 
MySQL Backup
MySQL BackupMySQL Backup
MySQL Backup
 
MySQL High Availability Solutions
MySQL High Availability SolutionsMySQL High Availability Solutions
MySQL High Availability Solutions
 
MySQL - New Features 5.6
MySQL - New Features 5.6MySQL - New Features 5.6
MySQL - New Features 5.6
 
Einführung in Elasticsearch - August 2014
Einführung in Elasticsearch - August 2014Einführung in Elasticsearch - August 2014
Einführung in Elasticsearch - August 2014
 
DAOG SIG: HA Architekturen mit MySQL
DAOG SIG: HA Architekturen mit MySQLDAOG SIG: HA Architekturen mit MySQL
DAOG SIG: HA Architekturen mit MySQL
 
Tipps zur Performanceoptimierung für Liferay Portal
Tipps zur  Performanceoptimierung für Liferay PortalTipps zur  Performanceoptimierung für Liferay Portal
Tipps zur Performanceoptimierung für Liferay Portal
 
DOAG 2011: MySQL Replication
DOAG 2011: MySQL ReplicationDOAG 2011: MySQL Replication
DOAG 2011: MySQL Replication
 
FROSCON 2011: MySQL Performance Tuning
FROSCON 2011: MySQL Performance TuningFROSCON 2011: MySQL Performance Tuning
FROSCON 2011: MySQL Performance Tuning
 
DOAG 2011: MySQL Performance Tuning
DOAG 2011: MySQL Performance TuningDOAG 2011: MySQL Performance Tuning
DOAG 2011: MySQL Performance Tuning
 
Docker Workbench
Docker WorkbenchDocker Workbench
Docker Workbench
 
Nagios Conference 2007 | Vmware Monitoring by Ingo Latschner
Nagios Conference 2007 | Vmware Monitoring by Ingo LatschnerNagios Conference 2007 | Vmware Monitoring by Ingo Latschner
Nagios Conference 2007 | Vmware Monitoring by Ingo Latschner
 
MySQL Replication for Beginners
MySQL Replication for BeginnersMySQL Replication for Beginners
MySQL Replication for Beginners
 
FROSCON 2011: MySQL Replication
FROSCON 2011: MySQL ReplicationFROSCON 2011: MySQL Replication
FROSCON 2011: MySQL Replication
 
Webanwendungen mit Apache HBase entwickeln
Webanwendungen mit Apache HBase entwickelnWebanwendungen mit Apache HBase entwickeln
Webanwendungen mit Apache HBase entwickeln
 
DOAG SIG: MySQL Replikation, Scale-Out, Master- Master Replikation, Backup
DOAG SIG: MySQL Replikation, Scale-Out, Master- Master Replikation, BackupDOAG SIG: MySQL Replikation, Scale-Out, Master- Master Replikation, Backup
DOAG SIG: MySQL Replikation, Scale-Out, Master- Master Replikation, Backup
 
Internet Briefing 2011: NoSQL with MySQL
Internet Briefing 2011: NoSQL with MySQLInternet Briefing 2011: NoSQL with MySQL
Internet Briefing 2011: NoSQL with MySQL
 

Ähnlich wie Microservices and Container Management with Mesosphere DC/OS

Jug nbg containerplattform dcos
Jug nbg containerplattform dcosJug nbg containerplattform dcos
Jug nbg containerplattform dcosRalf Ernst
 
Tipps & Tricks für den erfolgreichen Einsatz von GPU-Computing
Tipps & Tricks für den erfolgreichen Einsatz von GPU-ComputingTipps & Tricks für den erfolgreichen Einsatz von GPU-Computing
Tipps & Tricks für den erfolgreichen Einsatz von GPU-ComputingJörn Dinkla
 
Service Orchestrierung mit Apache Mesos
Service Orchestrierung mit Apache MesosService Orchestrierung mit Apache Mesos
Service Orchestrierung mit Apache MesosRalf Ernst
 
Back to Basics - Webinar 6: Produktivsetzung einer Anwendung
Back to Basics - Webinar 6: Produktivsetzung einer AnwendungBack to Basics - Webinar 6: Produktivsetzung einer Anwendung
Back to Basics - Webinar 6: Produktivsetzung einer AnwendungMongoDB
 
Avoid Network-Issues and Polling
Avoid Network-Issues and PollingAvoid Network-Issues and Polling
Avoid Network-Issues and PollingKai Donato
 
Ruby on Rails in a metro session
Ruby on Rails in a metro sessionRuby on Rails in a metro session
Ruby on Rails in a metro sessionVirttoo org
 
bccon-2014 adm01 tipps-und-skripts-aus-dem-leben-eines-ibm-connections-admins
bccon-2014 adm01 tipps-und-skripts-aus-dem-leben-eines-ibm-connections-adminsbccon-2014 adm01 tipps-und-skripts-aus-dem-leben-eines-ibm-connections-admins
bccon-2014 adm01 tipps-und-skripts-aus-dem-leben-eines-ibm-connections-adminsICS User Group
 
Tipps und Skripts aus dem Leben eines Connections Admins
Tipps und Skripts aus dem Leben eines Connections AdminsTipps und Skripts aus dem Leben eines Connections Admins
Tipps und Skripts aus dem Leben eines Connections AdminsKlaus Bild
 
20101011 roadshow-2010-ssds-grundlagen-know-how-und-konkrete-konfiguration-fuer
20101011 roadshow-2010-ssds-grundlagen-know-how-und-konkrete-konfiguration-fuer20101011 roadshow-2010-ssds-grundlagen-know-how-und-konkrete-konfiguration-fuer
20101011 roadshow-2010-ssds-grundlagen-know-how-und-konkrete-konfiguration-fuerWerner Fischer
 
Continuous Delivery für Cloud-native Anwendungen auf Cloud-nativer Infrastruktur
Continuous Delivery für Cloud-native Anwendungen auf Cloud-nativer InfrastrukturContinuous Delivery für Cloud-native Anwendungen auf Cloud-nativer Infrastruktur
Continuous Delivery für Cloud-native Anwendungen auf Cloud-nativer InfrastrukturQAware GmbH
 
Die Containerplattform Lego für DevOps
Die Containerplattform Lego für DevOpsDie Containerplattform Lego für DevOps
Die Containerplattform Lego für DevOpsATIX AG
 
Where are all transactions gone? Was in_der_cloud_alles_verboten_ist
Where are all transactions gone? Was in_der_cloud_alles_verboten_istWhere are all transactions gone? Was in_der_cloud_alles_verboten_ist
Where are all transactions gone? Was in_der_cloud_alles_verboten_istRamon Anger
 
Cloud Deployment und (Auto)Scaling am Beispiel von Angrybird
Cloud Deployment und (Auto)Scaling am Beispiel von AngrybirdCloud Deployment und (Auto)Scaling am Beispiel von Angrybird
Cloud Deployment und (Auto)Scaling am Beispiel von AngrybirdAOE
 
20111006 roadshow-io-performance
20111006 roadshow-io-performance20111006 roadshow-io-performance
20111006 roadshow-io-performanceWerner Fischer
 
WebSocket my APEX!
WebSocket my APEX!WebSocket my APEX!
WebSocket my APEX!Kai Donato
 
Icsug conf 14_tipps-und-skripts-fuer-ibm-connections-administratoren
Icsug conf 14_tipps-und-skripts-fuer-ibm-connections-administratorenIcsug conf 14_tipps-und-skripts-fuer-ibm-connections-administratoren
Icsug conf 14_tipps-und-skripts-fuer-ibm-connections-administratorenICS User Group
 

Ähnlich wie Microservices and Container Management with Mesosphere DC/OS (20)

Jug nbg containerplattform dcos
Jug nbg containerplattform dcosJug nbg containerplattform dcos
Jug nbg containerplattform dcos
 
Tipps & Tricks für den erfolgreichen Einsatz von GPU-Computing
Tipps & Tricks für den erfolgreichen Einsatz von GPU-ComputingTipps & Tricks für den erfolgreichen Einsatz von GPU-Computing
Tipps & Tricks für den erfolgreichen Einsatz von GPU-Computing
 
Service Orchestrierung mit Apache Mesos
Service Orchestrierung mit Apache MesosService Orchestrierung mit Apache Mesos
Service Orchestrierung mit Apache Mesos
 
PostgreSQL News
PostgreSQL NewsPostgreSQL News
PostgreSQL News
 
Back to Basics - Webinar 6: Produktivsetzung einer Anwendung
Back to Basics - Webinar 6: Produktivsetzung einer AnwendungBack to Basics - Webinar 6: Produktivsetzung einer Anwendung
Back to Basics - Webinar 6: Produktivsetzung einer Anwendung
 
Avoid Network-Issues and Polling
Avoid Network-Issues and PollingAvoid Network-Issues and Polling
Avoid Network-Issues and Polling
 
Ruby on Rails in a metro session
Ruby on Rails in a metro sessionRuby on Rails in a metro session
Ruby on Rails in a metro session
 
bccon-2014 adm01 tipps-und-skripts-aus-dem-leben-eines-ibm-connections-admins
bccon-2014 adm01 tipps-und-skripts-aus-dem-leben-eines-ibm-connections-adminsbccon-2014 adm01 tipps-und-skripts-aus-dem-leben-eines-ibm-connections-admins
bccon-2014 adm01 tipps-und-skripts-aus-dem-leben-eines-ibm-connections-admins
 
Tipps und Skripts aus dem Leben eines Connections Admins
Tipps und Skripts aus dem Leben eines Connections AdminsTipps und Skripts aus dem Leben eines Connections Admins
Tipps und Skripts aus dem Leben eines Connections Admins
 
20101011 roadshow-2010-ssds-grundlagen-know-how-und-konkrete-konfiguration-fuer
20101011 roadshow-2010-ssds-grundlagen-know-how-und-konkrete-konfiguration-fuer20101011 roadshow-2010-ssds-grundlagen-know-how-und-konkrete-konfiguration-fuer
20101011 roadshow-2010-ssds-grundlagen-know-how-und-konkrete-konfiguration-fuer
 
CPU Update Juni 2017
CPU Update Juni 2017CPU Update Juni 2017
CPU Update Juni 2017
 
Continuous Delivery für Cloud-native Anwendungen auf Cloud-nativer Infrastruktur
Continuous Delivery für Cloud-native Anwendungen auf Cloud-nativer InfrastrukturContinuous Delivery für Cloud-native Anwendungen auf Cloud-nativer Infrastruktur
Continuous Delivery für Cloud-native Anwendungen auf Cloud-nativer Infrastruktur
 
Die Containerplattform Lego für DevOps
Die Containerplattform Lego für DevOpsDie Containerplattform Lego für DevOps
Die Containerplattform Lego für DevOps
 
Where are all transactions gone? Was in_der_cloud_alles_verboten_ist
Where are all transactions gone? Was in_der_cloud_alles_verboten_istWhere are all transactions gone? Was in_der_cloud_alles_verboten_ist
Where are all transactions gone? Was in_der_cloud_alles_verboten_ist
 
Cloud Deployment und (Auto)Scaling am Beispiel von Angrybird
Cloud Deployment und (Auto)Scaling am Beispiel von AngrybirdCloud Deployment und (Auto)Scaling am Beispiel von Angrybird
Cloud Deployment und (Auto)Scaling am Beispiel von Angrybird
 
20111006 roadshow-io-performance
20111006 roadshow-io-performance20111006 roadshow-io-performance
20111006 roadshow-io-performance
 
WebSocket my APEX!
WebSocket my APEX!WebSocket my APEX!
WebSocket my APEX!
 
Boston webcast nv_me_2016-09
Boston webcast nv_me_2016-09Boston webcast nv_me_2016-09
Boston webcast nv_me_2016-09
 
Icsug conf 14_tipps-und-skripts-fuer-ibm-connections-administratoren
Icsug conf 14_tipps-und-skripts-fuer-ibm-connections-administratorenIcsug conf 14_tipps-und-skripts-fuer-ibm-connections-administratoren
Icsug conf 14_tipps-und-skripts-fuer-ibm-connections-administratoren
 
JavaScript Performance
JavaScript PerformanceJavaScript Performance
JavaScript Performance
 

Microservices and Container Management with Mesosphere DC/OS

  • 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
  • 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
  • 12. Seite 12 Deployment-Architektur der DC/OS Komponenten All Nodes Master Nodes Agent Nodes
  • 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
  • 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!
  • 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)
  • 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
  • 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