SlideShare ist ein Scribd-Unternehmen logo
Service Orchestrierung mit
Apache Mesos
Herausforderungen beim Betrieb von Docker-Containern und
Microservice Architekturen
About
• Ralf Ernst
• Senior IT-Architect im IT-Systemhaus der BA
• Schwerpunkt Systemarchitektur und Infrastruktur
von großen verteilten Systemen
• davor Software-Architekt, Projektleiter, Lead
Developer in verschiedenen JEE-Projekten
• davor Developer im UNIX Umfeld (C, Perl, sh)
• davor Developer Mainframes (BS2000)
• Twitter: @ralfernst
Apache Mesos –Open Source DataCenter
Computing
• Top-Level Apache Projekt
• Ursprünglich entwickelt in den AmpLabs der
UC Berkeley
• Weiterentwickelt von Twitter und AirBnb
• Verwaltung von Ressourcen eines Hardware-
Clusters (Ports, CPU, RAM, Disk, I/Os, …)
• Offenes System - APIs in C++, Java/Scala,
Python, Go, Erlang, Haskell
• Hochverfügbar, Skalierung über 10000te
Knoten
Google: Systeme sollen nicht automatisiert werden, sondern automatisch funktionieren!
Mesos – User
Mesosphere DC/OS
• Mesosphere DC/OS
• Seit 19.4.2016 Open-Source http://dcos.io
• 60 Partner u.a.: Microsoft, HPE, Cisco, Citrix, Accenture, NGINX, Puppet, Chef,
EMC, NetApp, Autodesk, …
• Kommerzielles Angebot von Mesosphere selbst für die Zielgruppe „Fortune
2000“ z.B. Apple, Verizon, PayPal
• DC/OS = PaaS auf Basis von Mesos
• Package Manager und Installer für CentOS, UI, CLI
• Universe: App Shop für Mesos Frameworks - One Click Install von Spark,
Kafka, Cassandra, Jenkins, ArangoDB, ….
• Security, Netzzonen, DNS, Load-Balancing, Service-Discovery, Admin-Tools,
Monitoring etc.
Mesos - Motivation
• Abstraktion der Infrastruktur durch
Zusammenfassung aller Ressourcen eines
HW-Clusters zu einem „Mainframe“
• Isolation der Ressourcen durch LINUX-
Container
• Docker ist hier nur ein Spezialfall
• Ressourcen = CPU, RAM, Disk, Ports, …
• Vollkommene Entkopplung zwischen den
Applikationen und der Infrastruktur
• Erlaubt klare Rollentrennung zwischen
Dev und Ops
„Pets vs. Cattle“ Randy Bias, CloudScaling bekannt durch Vortrag CERN Data Centre Evolution
Pets vs. Cattle - CERN Data Centre Evolution
Mesos als „DataCenter Kernel“
Mesos Frameworks – ein offenes
erweiterbares Ökosystem
Mesos Architektur
Mesos – 2-level scheduling
Mesos – Beispiel: 2-level scheduling
Marathon – init für Mesos
• Framework für langlaufende Prozesse
• Start, stop, scale, update
• REST-API, WEB-UI zur Übergabe von Parametern
• Hochverfügbar - Leader election über Zookeeper wie Mesos Master
• Docker support, Download der Executables über URIs (tar.gz, zip, etc.)
• Rolling deployments, upgrades, restarts
• Health Checks, Ready Checks
• Artifact Store zur Speicherung von applikationsspezifischen „Secrets“
• Event-Bus für Drittanwendungen z.B. Service Discovery über marathon-lb
Demo Mesos und Marathon
Mesos - Konventionen
• Ressources sind z.B. cpu, ram, port und disk und werden vom Mesos
Master gemanaged
• Attribute sind simple Key-Value Paare, die an die Frameworks übergeben
werden
• Ressourcen werden als Scalars, Ranges und Sets gemanaged
• Zuordnung von Ressources zu Roles
• Frameworks binden eine bestimmte Rolle oder „any“  Isolation verschiedener
Frameworks möglich
• Ermöglicht gezielte Überprovisionierung von Ressourcen eines Slaves
Mesos – Advanced Features
• Constraints: Genau ein Task pro Node, Task auf genau einer Node, …
• Mesos Fetcher – Download von Ressourcen über URIs in die Sandbox eines
Tasks (z.B. tar-Archive)
• Oversubscription für „best-effort-Tasks“
• Persistent volumes bzw. multiple disk ressources für Storage
• Quotas für unterschiedliche Frameworks
• Reservations auf Slaves für bestimmte Rollen
• Replicated Logging: Fehlertolerante Log-Replikation des Masters und von
Frameworks
• Monitoring: Metriken über REST-API
Marathon – Orchestrierung von Groups
Apps
Group
Apps
Apps
Apps
Apps
Tasks
Apps
Apps
Apps
Tasks
=
Hierarchie:
depends
1:n
1:n
1:n
1:n
Beispiel:
Service Orchestrierung
Service Orchestrierung im Reality Check
• Dependency Management
• Service Discovery und Loadbalancing
• Running at scale
• Stateful Services
• Monitoring & Logging
• Aktuell: wenig Standards, viele heterogene (Teil-)Lösungen
Dependency Management – Server
• Die unter Mesos liegenden Maschinen müssen nach wie vor
provisioniert und konfiguriert werden
• Allerdings stark vereinfacht, da nur noch wenige Rollen
• Grundsätzlich: Mesos Master und Mesos Slave Maschinen
• Zusätzlich: Admin-Nodes, Edge-Nodes, Nodes f. spezielle Mesos-Rollen, …
• Definition von Port-Ranges zwingend
• Nicht jeder hat die Infrastruktur der „Hyperscaler“
• Hyperconverged Systems sind ideale Partner z.B. Nutanix, Cisco FlexPod
• Realität ist anders: heterogene Hardware, vorhandener SAN-Storage, etc.
• Konfigurationsmanagement mit z.B. Ansible, Chef oder Puppet
• Module für Chef und Puppet existieren
Dependency Management - Applikationen
• Entwickler sollen keine Annahmen über die darunterliegende
Infrastruktur machen
• 12-factor apps
• Geeignete Deploymentformate:
• Container erleichtern dies wesentlich, das Docker-Format ist etabliert und
sehr gut geeignet
• Lösung für Nicht-Docker-Applikationen: Deployment z.B. als tarball über URIs
und Mesos Fetcher in Verbindung mit MesosFetcher Cache
• Lösungen für „secrets“
• Environment-Variable ???, Shared-FS (URIs!), Marathon Artifacts, Hashicorp
Vault, …
Service Discovery und Load-Balancing
• Service Discovery Mechanismen behandeln nur die Erreichbarkeit von
Services untereinander, sorgen aber nicht für ein intelligentes Routing
• Service Discovery und Load-Balancing hängen aber eng miteinander
zusammen
• Statische Ports
• Dynamische Ports
• Service-Registries
Service Discovery - statische Service Ports
• Jede Instanz eines Services läuft auf einem eigenen Host mit „well-
known-Port“
• Sobald mehrere Instanzen auf demselben Host laufen, müssen diese
eine eigene IP erhalten
• Software-Defined Networks (SDNs) wie Flannel, Calico, Weave, …
• Discovery erfolgt typischerweise über DNS-A Records / Service
Registry
• Docker, Kubernetes (Flannel) und Mesos (Calico) entwickeln z.Zt.
Lösungen in Richtung VIPs
• Ziel: Hostübergreifende Kommunikation ohne Proxies mit Overlay-
Netzwerken
Service Discovery - dynamische Service Ports
• Bridged Network ist in einem Mesos-Cluster ohne SDN die einzig
sinnvolle Alternative
• Ausnahme: Legacy-Applikationen, die feste Host-Ports voraussetzen
• DNS Load-Balancing?
• SRV Records, langsamer Refresh, DNS-Caches
• Typische Lösungen: Reverse Proxy, dass well-known ports oder Pfade
auf dynamische Ports mapped
• Nginx, HAProxy, …
• Dynamische Konfiguration mit den aktuellen Daten von z.B. Marathon über
dessen Event-Bus: Bamboo, marathon-lb, AirBnb Synapse/Nerve, …
• Herausforderung: reload des Proxies ohne Downtime bei vielen Routen
Typische Loadbalancing und Service Discovery
Topologie mit Marathon und HAProxy
Service Discovery - Service-Registries
• Registries liefern kein
Routing!
• Teilweise sehr spezielle
Lösungen wie WeaveDNS
oder Eureka
• Vielversprechend ist eine
Kombination von DNS und
Load-Balancing / Routing
DNS und Loadbalancing - Traefik
Demo Mesos DNS und traefik
Worker Node
Traefik
App
Mesos Slave
App App
Worker Node
Traefik
App
Mesos Slave
App App
Worker Node
Traefik
App
Mesos Slave
App App
Worker Node
Traefik
App
Mesos Slave
App App
Worker Node
Traefik
App
Mesos Slave
App App
Control Node
Mesos DNS
Mesos Master
Mesos
Marathon
Control Node
Mesos DNS
Mesos Master
Mesos
Marathon
Beispiel für eine System- / Deployment-
Architektur
Control Node
Mesos DNS
Mesos
Marathon
Mesos Master
Zookeeper
Worker Node
Traefik
App
Mesos Slave
App App
StorageStorage
Admin Node
Mesos DNS
Mesos Master
Mesos
Marathon
Admin Node
Admin Reverse
Proxy
Logging
(Elasticsearch /
Kibana)
Private Registry
Edge Node
Public Frontend
API-Gateway
Enterprise DNS
Dev / Ops User
http
tcp
http http
DNS
Running at scale
• Private Registry
• Isolierung verschiedener Projekte voneinander
• Pragmatische Lösung: verschiedene Registries…
• Hochverfügbar auslegen!
• Hohe Anforderungen an Netzwerk und das darunterliegende File-
System
• HDFS, Clustered File-Systeme
• Base Images standardisieren, kleine Images verwenden
Running at scale
• Performance
• Container müssen adäquat gesized werden
• Ressource-Limit überschritten: Container wird gekilled
• Ressourcen sind nicht homogen
• 1 CPU = 1 Share aber nicht jeder Core ist gleich! Gilt auch für RAM
• Noisy neighbours
• Schlechte Netzwerk-Isolation, viel Kommunikation, Interferenzen
• Definition von Rollen für Maschinen, um besonders ressourcenhungrige Tasks
zu isolieren
Running at scale - Hochverfügbarkeit
• Mesos ist eine gute Grundlage für hochverfügbare Applikationen
• Mesos und Marathon handeln rolling upgrades, canaries, auto-scaling
• Eine Container-basierte Architektur macht eine Applikation aber nicht
automatisch resilient
• Die Verfügbarkeit von Applikationen wird vom Entwickler bestimmt
• Weiterhin existieren SPOFs: z.B. Docker Dämon
• Failover und Persistierung von Zuständen muss nach wie vor durch
die Applikation selbst geschehen
• Zookeeper ist hierfür ein gutes Werkzeug…
Stateful Services
• Stateful Services werden von Mesos und Marathon unterstützt
• Mesos Frameworks für ArangoDB, Elasticsearch, Cassandra, Hadoop, …
• Local Disk
• Persistent Volumes auf einem Slave bleiben auch nach Beendigung eines Containers
erhalten
• über Metadaten wird ein Container immer wieder auf der selben „richtigen“ Node
gestartet
• Shared-FS oder besser Clustered FS
• SAN (Block Storage) wird zunehmend unterstützt (EMC, Netapps, …)
• Beispiel: EMC rexray Treiber für Block Storage mit Docker
• Für EMC SAN-Familie, aber z.B. auch für Open Stack Cinder
• Unterstützung in Mesos: DVDI (Docker Volume Driver Isolator module)
Demo Mesos Persistent Volumes
Monitoring
• Viele Facetten
• Alarmierung, Resilienz
• Fehleranalyse – Logging
• Metriken von Services und Applikationen
• Kapazitätsplanung des gesamten Hardware Clusters
• Pragmatisch bleiben!
Alarmierung, Resilienz
• Gute Unterstützung von Healthchecks und Resilienz durch Marathon
• Automatisierte Restarts
• Neuprovisionierung bei Hardware-Ausfällen
• Healthchecks
• verpflichtend
• Je mehr, je besser
• Ready-state
Logging
• Log-Aggregation zwingend
• Standardisiertes Log-Format
• Getrennte Hardware für Logs, niemals lokale Platten
• Logs sollten Prozess-Ids, ECIDs, UserIds o.ä. enthalten
• Logging nach stdout / stderr
• Konfiguration der Log-Files durch Ops
• Typischerweise Umleitung mit logstash
• ELK-Stack zur Auswertung
Metriken von Services, Applikationen,
Hardware
• Allocation vs. Utilization
• Monitoring von CPU und RAM unter Last
• Auswertung der Metriken von Mesos
• Mesos Konsole, Mesos-UI
• End2End Monitoring
• Logging von TimeStamps via Javascript
• Regelmäßiges Reporting auf Basis dieser Daten
• Tools: sysdig Monitoring, Prometheus und viele, viele mehr
Demo scale-up und Mesos-UI
Zusammenfassung
• Service-Orchestrierung mit Mesos ist gut möglich und „im großen
Stil“ produktionserprobt
• DC/OS liefert hier eine schlüsselfertige Komplettlösung
• Etablierte Partner wie HP, MS oder Cisco
• Mesos bleibt dabei ein offeneres System als andere Lösungen
• Aktuell sehr hohe Dynamik (Anzahl Releases, etc.)
• Viele Fragen sind offen, viele Lösungen existieren, best-practices
bilden sich erst langsam heraus

Weitere ähnliche Inhalte

Was ist angesagt?

JBoss EAP clustering
JBoss EAP clustering JBoss EAP clustering
JBoss EAP clustering
hwilming
 
AdminCamp 2011 Performance
AdminCamp 2011 PerformanceAdminCamp 2011 Performance
AdminCamp 2011 Performance
Ulrich Krause
 
Vorlesung - Cloud Infrastrukturen - Clusterbau | anynines
Vorlesung - Cloud Infrastrukturen - Clusterbau  | anyninesVorlesung - Cloud Infrastrukturen - Clusterbau  | anynines
Vorlesung - Cloud Infrastrukturen - Clusterbau | anynines
anynines GmbH
 
Datenbankoptimierung
DatenbankoptimierungDatenbankoptimierung
Datenbankoptimierung
Cenarion Information Systems GmbH
 
Datenbanken - Eine Übersicht (WPMeetUP München)
Datenbanken - Eine Übersicht (WPMeetUP München)Datenbanken - Eine Übersicht (WPMeetUP München)
Datenbanken - Eine Übersicht (WPMeetUP München)
Dietmar Leher
 
Webinar SharePoint auf AWS
Webinar SharePoint auf AWSWebinar SharePoint auf AWS
Webinar SharePoint auf AWS
AWS Germany
 
Daos
DaosDaos
MySQL Hochverfügbarkeitslösungen
MySQL HochverfügbarkeitslösungenMySQL Hochverfügbarkeitslösungen
MySQL Hochverfügbarkeitslösungen
Lenz Grimmer
 
GWAVACon 2015: SEP - Backuplösungen auf dem Prüfstand
GWAVACon 2015: SEP - Backuplösungen auf dem PrüfstandGWAVACon 2015: SEP - Backuplösungen auf dem Prüfstand
GWAVACon 2015: SEP - Backuplösungen auf dem Prüfstand
GWAVA
 
Citrix XenServer 5.6: Die Neuerungen
Citrix XenServer 5.6: Die NeuerungenCitrix XenServer 5.6: Die Neuerungen
Citrix XenServer 5.6: Die Neuerungen
netlogix
 
Klonen von Exadata-Datenbanken mit der Oracle ZFS Appliance - Ein Erfahrungsb...
Klonen von Exadata-Datenbanken mit der Oracle ZFS Appliance - Ein Erfahrungsb...Klonen von Exadata-Datenbanken mit der Oracle ZFS Appliance - Ein Erfahrungsb...
Klonen von Exadata-Datenbanken mit der Oracle ZFS Appliance - Ein Erfahrungsb...
Loopback.ORG
 
MySQL Hochverfügbarkeitslösungen
MySQL HochverfügbarkeitslösungenMySQL Hochverfügbarkeitslösungen
MySQL Hochverfügbarkeitslösungen
Lenz Grimmer
 

Was ist angesagt? (13)

What is new in xen Server
What is new in xen ServerWhat is new in xen Server
What is new in xen Server
 
JBoss EAP clustering
JBoss EAP clustering JBoss EAP clustering
JBoss EAP clustering
 
AdminCamp 2011 Performance
AdminCamp 2011 PerformanceAdminCamp 2011 Performance
AdminCamp 2011 Performance
 
Vorlesung - Cloud Infrastrukturen - Clusterbau | anynines
Vorlesung - Cloud Infrastrukturen - Clusterbau  | anyninesVorlesung - Cloud Infrastrukturen - Clusterbau  | anynines
Vorlesung - Cloud Infrastrukturen - Clusterbau | anynines
 
Datenbankoptimierung
DatenbankoptimierungDatenbankoptimierung
Datenbankoptimierung
 
Datenbanken - Eine Übersicht (WPMeetUP München)
Datenbanken - Eine Übersicht (WPMeetUP München)Datenbanken - Eine Übersicht (WPMeetUP München)
Datenbanken - Eine Übersicht (WPMeetUP München)
 
Webinar SharePoint auf AWS
Webinar SharePoint auf AWSWebinar SharePoint auf AWS
Webinar SharePoint auf AWS
 
Daos
DaosDaos
Daos
 
MySQL Hochverfügbarkeitslösungen
MySQL HochverfügbarkeitslösungenMySQL Hochverfügbarkeitslösungen
MySQL Hochverfügbarkeitslösungen
 
GWAVACon 2015: SEP - Backuplösungen auf dem Prüfstand
GWAVACon 2015: SEP - Backuplösungen auf dem PrüfstandGWAVACon 2015: SEP - Backuplösungen auf dem Prüfstand
GWAVACon 2015: SEP - Backuplösungen auf dem Prüfstand
 
Citrix XenServer 5.6: Die Neuerungen
Citrix XenServer 5.6: Die NeuerungenCitrix XenServer 5.6: Die Neuerungen
Citrix XenServer 5.6: Die Neuerungen
 
Klonen von Exadata-Datenbanken mit der Oracle ZFS Appliance - Ein Erfahrungsb...
Klonen von Exadata-Datenbanken mit der Oracle ZFS Appliance - Ein Erfahrungsb...Klonen von Exadata-Datenbanken mit der Oracle ZFS Appliance - Ein Erfahrungsb...
Klonen von Exadata-Datenbanken mit der Oracle ZFS Appliance - Ein Erfahrungsb...
 
MySQL Hochverfügbarkeitslösungen
MySQL HochverfügbarkeitslösungenMySQL Hochverfügbarkeitslösungen
MySQL Hochverfügbarkeitslösungen
 

Andere mochten auch

Docker Swarm: Docker Native Clustering
Docker Swarm: Docker Native ClusteringDocker Swarm: Docker Native Clustering
Docker Swarm: Docker Native Clustering
Docker, Inc.
 
Opensource approach to design and deployment of Microservices based VNF
Opensource approach to design and deployment of Microservices based VNFOpensource approach to design and deployment of Microservices based VNF
Opensource approach to design and deployment of Microservices based VNF
Michelle Holley
 
Is 875 wind load
Is 875   wind loadIs 875   wind load
Is 875 wind load
dreamsunlimitedshelke
 
Mindmappen
MindmappenMindmappen
Mindmappenyperlaan
 
The Common protocol
The Common protocolThe Common protocol
The Common protocol
Sivashanmugam Palaniappan
 
Performance testing for web-scale
Performance testing for web-scalePerformance testing for web-scale
Performance testing for web-scale
Izzet Mustafaiev
 
Gsm jammer
Gsm jammerGsm jammer
Gsm jammer
Dr-Ahmed Elkorany
 
Distributed cat herding
Distributed cat herdingDistributed cat herding
Distributed cat herding
Jilles van Gurp
 
Java management extensions (jmx)
Java management extensions (jmx)Java management extensions (jmx)
Java management extensions (jmx)
Tarun Telang
 
IOT Exploitation
IOT Exploitation	IOT Exploitation
Hangul
HangulHangul
Hangul
stepupias
 
AWS Cost Visualizer
AWS Cost VisualizerAWS Cost Visualizer
AWS Cost Visualizer
Institut Teknologi Bandung
 
Elk stack
Elk stackElk stack
Elk stack
datamantra
 
AWS re:Invent 2014 | (ARC202) Real-World Real-Time Analytics
AWS re:Invent 2014 | (ARC202) Real-World Real-Time AnalyticsAWS re:Invent 2014 | (ARC202) Real-World Real-Time Analytics
AWS re:Invent 2014 | (ARC202) Real-World Real-Time Analytics
Socialmetrix
 
Resume -Resume -continous monitoring
Resume -Resume -continous monitoringResume -Resume -continous monitoring
Resume -Resume -continous monitoring
Tony Kenny
 
Visualize your data in Data Lake with AWS Athena and AWS Quicksight Hands-on ...
Visualize your data in Data Lake with AWS Athena and AWS Quicksight Hands-on ...Visualize your data in Data Lake with AWS Athena and AWS Quicksight Hands-on ...
Visualize your data in Data Lake with AWS Athena and AWS Quicksight Hands-on ...
Amazon Web Services
 
Failing at Scale - PNWPHP 2016
Failing at Scale - PNWPHP 2016Failing at Scale - PNWPHP 2016
Failing at Scale - PNWPHP 2016
Chris Tankersley
 
Roxar Multiphase Meter
Roxar Multiphase MeterRoxar Multiphase Meter
Roxar Multiphase Meter
ali_elkaseh
 
AWS May Webinar Series - Streaming Data Processing with Amazon Kinesis and AW...
AWS May Webinar Series - Streaming Data Processing with Amazon Kinesis and AW...AWS May Webinar Series - Streaming Data Processing with Amazon Kinesis and AW...
AWS May Webinar Series - Streaming Data Processing with Amazon Kinesis and AW...
Amazon Web Services
 
Automating interactions with Zabbix (Raymond Kuiper / 12-02-2015)
Automating interactions with Zabbix (Raymond Kuiper / 12-02-2015)Automating interactions with Zabbix (Raymond Kuiper / 12-02-2015)
Automating interactions with Zabbix (Raymond Kuiper / 12-02-2015)
Nederlandstalige Zabbix Gebruikersgroep
 

Andere mochten auch (20)

Docker Swarm: Docker Native Clustering
Docker Swarm: Docker Native ClusteringDocker Swarm: Docker Native Clustering
Docker Swarm: Docker Native Clustering
 
Opensource approach to design and deployment of Microservices based VNF
Opensource approach to design and deployment of Microservices based VNFOpensource approach to design and deployment of Microservices based VNF
Opensource approach to design and deployment of Microservices based VNF
 
Is 875 wind load
Is 875   wind loadIs 875   wind load
Is 875 wind load
 
Mindmappen
MindmappenMindmappen
Mindmappen
 
The Common protocol
The Common protocolThe Common protocol
The Common protocol
 
Performance testing for web-scale
Performance testing for web-scalePerformance testing for web-scale
Performance testing for web-scale
 
Gsm jammer
Gsm jammerGsm jammer
Gsm jammer
 
Distributed cat herding
Distributed cat herdingDistributed cat herding
Distributed cat herding
 
Java management extensions (jmx)
Java management extensions (jmx)Java management extensions (jmx)
Java management extensions (jmx)
 
IOT Exploitation
IOT Exploitation	IOT Exploitation
IOT Exploitation
 
Hangul
HangulHangul
Hangul
 
AWS Cost Visualizer
AWS Cost VisualizerAWS Cost Visualizer
AWS Cost Visualizer
 
Elk stack
Elk stackElk stack
Elk stack
 
AWS re:Invent 2014 | (ARC202) Real-World Real-Time Analytics
AWS re:Invent 2014 | (ARC202) Real-World Real-Time AnalyticsAWS re:Invent 2014 | (ARC202) Real-World Real-Time Analytics
AWS re:Invent 2014 | (ARC202) Real-World Real-Time Analytics
 
Resume -Resume -continous monitoring
Resume -Resume -continous monitoringResume -Resume -continous monitoring
Resume -Resume -continous monitoring
 
Visualize your data in Data Lake with AWS Athena and AWS Quicksight Hands-on ...
Visualize your data in Data Lake with AWS Athena and AWS Quicksight Hands-on ...Visualize your data in Data Lake with AWS Athena and AWS Quicksight Hands-on ...
Visualize your data in Data Lake with AWS Athena and AWS Quicksight Hands-on ...
 
Failing at Scale - PNWPHP 2016
Failing at Scale - PNWPHP 2016Failing at Scale - PNWPHP 2016
Failing at Scale - PNWPHP 2016
 
Roxar Multiphase Meter
Roxar Multiphase MeterRoxar Multiphase Meter
Roxar Multiphase Meter
 
AWS May Webinar Series - Streaming Data Processing with Amazon Kinesis and AW...
AWS May Webinar Series - Streaming Data Processing with Amazon Kinesis and AW...AWS May Webinar Series - Streaming Data Processing with Amazon Kinesis and AW...
AWS May Webinar Series - Streaming Data Processing with Amazon Kinesis and AW...
 
Automating interactions with Zabbix (Raymond Kuiper / 12-02-2015)
Automating interactions with Zabbix (Raymond Kuiper / 12-02-2015)Automating interactions with Zabbix (Raymond Kuiper / 12-02-2015)
Automating interactions with Zabbix (Raymond Kuiper / 12-02-2015)
 

Ähnlich wie Service Orchestrierung mit Apache Mesos

Jug nbg containerplattform dcos
Jug nbg containerplattform dcosJug nbg containerplattform dcos
Jug nbg containerplattform dcos
Ralf Ernst
 
Hadoop 2.0 - The Next Level
Hadoop 2.0 - The Next LevelHadoop 2.0 - The Next Level
Hadoop 2.0 - The Next Level
Sascha Dittmann
 
Microservices and Container Management with Mesosphere DC/OS
Microservices and Container Management with Mesosphere DC/OSMicroservices and Container Management with Mesosphere DC/OS
Microservices and Container Management with Mesosphere DC/OS
Ralf Ernst
 
Introduction to Apache Maven 3 (German)
Introduction to Apache Maven 3 (German)Introduction to Apache Maven 3 (German)
Introduction to Apache Maven 3 (German)
Chris Michael Klinger
 
Private Cloud mit Open Source
Private Cloud mit Open SourcePrivate Cloud mit Open Source
Private Cloud mit Open Source
Daniel Schneller
 
Cloud-native Applikationen
Cloud-native ApplikationenCloud-native Applikationen
Cloud-native Applikationen
QAware GmbH
 
Überblick Oracle Datenbank Hochverfügbarkeit
Überblick Oracle Datenbank HochverfügbarkeitÜberblick Oracle Datenbank Hochverfügbarkeit
Überblick Oracle Datenbank Hochverfügbarkeit
Ileana Somesan
 
Docker Hosting (Webinar vom 10. März 2016)
Docker Hosting (Webinar vom 10. März 2016)Docker Hosting (Webinar vom 10. März 2016)
Docker Hosting (Webinar vom 10. März 2016)
NETWAYS
 
Docker Workbench
Docker WorkbenchDocker Workbench
Docker Workbench
Patrick Paechnatz
 
Einführung in Elasticsearch - August 2014
Einführung in Elasticsearch - August 2014Einführung in Elasticsearch - August 2014
Einführung in Elasticsearch - August 2014
inovex GmbH
 
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
Ramon Anger
 
Node.js
Node.jsNode.js
Supersonic Java für die Cloud: Quarkus
Supersonic Java für die Cloud: QuarkusSupersonic Java für die Cloud: Quarkus
Supersonic Java für die Cloud: Quarkus
OPEN KNOWLEDGE GmbH
 
Docker - Containervirtualisierung leichtgemacht
Docker - Containervirtualisierung leichtgemachtDocker - Containervirtualisierung leichtgemacht
Docker - Containervirtualisierung leichtgemacht
B1 Systems GmbH
 
Cloud Computing - PaaS
Cloud Computing - PaaSCloud Computing - PaaS
Cloud Computing - PaaS
Thomas Bachmann
 
Suse in der neuen Welt des Rechenzentrums - ein Beispiel
Suse in der neuen Welt des Rechenzentrums - ein BeispielSuse in der neuen Welt des Rechenzentrums - ein Beispiel
Suse in der neuen Welt des Rechenzentrums - ein Beispiel
ATIX AG
 
Infrastructure as Code - BaselOne 17
Infrastructure as Code - BaselOne 17Infrastructure as Code - BaselOne 17
Infrastructure as Code - BaselOne 17
remigius-stalder
 
Nosql Hintergründe und Anwendungen
Nosql Hintergründe und AnwendungenNosql Hintergründe und Anwendungen
Nosql Hintergründe und Anwendungen
Andy Whole
 
Eval Apache Storm vs. Spark Streaming - German
Eval Apache Storm vs. Spark Streaming - GermanEval Apache Storm vs. Spark Streaming - German
Eval Apache Storm vs. Spark Streaming - German
Erik Schmiegelow
 
GWAVACon - Exchange 2013 Überblick (deutsch)
GWAVACon - Exchange 2013 Überblick (deutsch)GWAVACon - Exchange 2013 Überblick (deutsch)
GWAVACon - Exchange 2013 Überblick (deutsch)
GWAVA
 

Ähnlich wie Service Orchestrierung mit Apache Mesos (20)

Jug nbg containerplattform dcos
Jug nbg containerplattform dcosJug nbg containerplattform dcos
Jug nbg containerplattform dcos
 
Hadoop 2.0 - The Next Level
Hadoop 2.0 - The Next LevelHadoop 2.0 - The Next Level
Hadoop 2.0 - The Next Level
 
Microservices and Container Management with Mesosphere DC/OS
Microservices and Container Management with Mesosphere DC/OSMicroservices and Container Management with Mesosphere DC/OS
Microservices and Container Management with Mesosphere DC/OS
 
Introduction to Apache Maven 3 (German)
Introduction to Apache Maven 3 (German)Introduction to Apache Maven 3 (German)
Introduction to Apache Maven 3 (German)
 
Private Cloud mit Open Source
Private Cloud mit Open SourcePrivate Cloud mit Open Source
Private Cloud mit Open Source
 
Cloud-native Applikationen
Cloud-native ApplikationenCloud-native Applikationen
Cloud-native Applikationen
 
Überblick Oracle Datenbank Hochverfügbarkeit
Überblick Oracle Datenbank HochverfügbarkeitÜberblick Oracle Datenbank Hochverfügbarkeit
Überblick Oracle Datenbank Hochverfügbarkeit
 
Docker Hosting (Webinar vom 10. März 2016)
Docker Hosting (Webinar vom 10. März 2016)Docker Hosting (Webinar vom 10. März 2016)
Docker Hosting (Webinar vom 10. März 2016)
 
Docker Workbench
Docker WorkbenchDocker Workbench
Docker Workbench
 
Einführung in Elasticsearch - August 2014
Einführung in Elasticsearch - August 2014Einführung in Elasticsearch - August 2014
Einführung in Elasticsearch - August 2014
 
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
 
Node.js
Node.jsNode.js
Node.js
 
Supersonic Java für die Cloud: Quarkus
Supersonic Java für die Cloud: QuarkusSupersonic Java für die Cloud: Quarkus
Supersonic Java für die Cloud: Quarkus
 
Docker - Containervirtualisierung leichtgemacht
Docker - Containervirtualisierung leichtgemachtDocker - Containervirtualisierung leichtgemacht
Docker - Containervirtualisierung leichtgemacht
 
Cloud Computing - PaaS
Cloud Computing - PaaSCloud Computing - PaaS
Cloud Computing - PaaS
 
Suse in der neuen Welt des Rechenzentrums - ein Beispiel
Suse in der neuen Welt des Rechenzentrums - ein BeispielSuse in der neuen Welt des Rechenzentrums - ein Beispiel
Suse in der neuen Welt des Rechenzentrums - ein Beispiel
 
Infrastructure as Code - BaselOne 17
Infrastructure as Code - BaselOne 17Infrastructure as Code - BaselOne 17
Infrastructure as Code - BaselOne 17
 
Nosql Hintergründe und Anwendungen
Nosql Hintergründe und AnwendungenNosql Hintergründe und Anwendungen
Nosql Hintergründe und Anwendungen
 
Eval Apache Storm vs. Spark Streaming - German
Eval Apache Storm vs. Spark Streaming - GermanEval Apache Storm vs. Spark Streaming - German
Eval Apache Storm vs. Spark Streaming - German
 
GWAVACon - Exchange 2013 Überblick (deutsch)
GWAVACon - Exchange 2013 Überblick (deutsch)GWAVACon - Exchange 2013 Überblick (deutsch)
GWAVACon - Exchange 2013 Überblick (deutsch)
 

Service Orchestrierung mit Apache Mesos

  • 1. Service Orchestrierung mit Apache Mesos Herausforderungen beim Betrieb von Docker-Containern und Microservice Architekturen
  • 2. About • Ralf Ernst • Senior IT-Architect im IT-Systemhaus der BA • Schwerpunkt Systemarchitektur und Infrastruktur von großen verteilten Systemen • davor Software-Architekt, Projektleiter, Lead Developer in verschiedenen JEE-Projekten • davor Developer im UNIX Umfeld (C, Perl, sh) • davor Developer Mainframes (BS2000) • Twitter: @ralfernst
  • 3. Apache Mesos –Open Source DataCenter Computing • Top-Level Apache Projekt • Ursprünglich entwickelt in den AmpLabs der UC Berkeley • Weiterentwickelt von Twitter und AirBnb • Verwaltung von Ressourcen eines Hardware- Clusters (Ports, CPU, RAM, Disk, I/Os, …) • Offenes System - APIs in C++, Java/Scala, Python, Go, Erlang, Haskell • Hochverfügbar, Skalierung über 10000te Knoten Google: Systeme sollen nicht automatisiert werden, sondern automatisch funktionieren!
  • 5. Mesosphere DC/OS • Mesosphere DC/OS • Seit 19.4.2016 Open-Source http://dcos.io • 60 Partner u.a.: Microsoft, HPE, Cisco, Citrix, Accenture, NGINX, Puppet, Chef, EMC, NetApp, Autodesk, … • Kommerzielles Angebot von Mesosphere selbst für die Zielgruppe „Fortune 2000“ z.B. Apple, Verizon, PayPal • DC/OS = PaaS auf Basis von Mesos • Package Manager und Installer für CentOS, UI, CLI • Universe: App Shop für Mesos Frameworks - One Click Install von Spark, Kafka, Cassandra, Jenkins, ArangoDB, …. • Security, Netzzonen, DNS, Load-Balancing, Service-Discovery, Admin-Tools, Monitoring etc.
  • 6. Mesos - Motivation • Abstraktion der Infrastruktur durch Zusammenfassung aller Ressourcen eines HW-Clusters zu einem „Mainframe“ • Isolation der Ressourcen durch LINUX- Container • Docker ist hier nur ein Spezialfall • Ressourcen = CPU, RAM, Disk, Ports, … • Vollkommene Entkopplung zwischen den Applikationen und der Infrastruktur • Erlaubt klare Rollentrennung zwischen Dev und Ops „Pets vs. Cattle“ Randy Bias, CloudScaling bekannt durch Vortrag CERN Data Centre Evolution
  • 7. Pets vs. Cattle - CERN Data Centre Evolution
  • 9. Mesos Frameworks – ein offenes erweiterbares Ökosystem
  • 11. Mesos – 2-level scheduling
  • 12. Mesos – Beispiel: 2-level scheduling
  • 13. Marathon – init für Mesos • Framework für langlaufende Prozesse • Start, stop, scale, update • REST-API, WEB-UI zur Übergabe von Parametern • Hochverfügbar - Leader election über Zookeeper wie Mesos Master • Docker support, Download der Executables über URIs (tar.gz, zip, etc.) • Rolling deployments, upgrades, restarts • Health Checks, Ready Checks • Artifact Store zur Speicherung von applikationsspezifischen „Secrets“ • Event-Bus für Drittanwendungen z.B. Service Discovery über marathon-lb
  • 14. Demo Mesos und Marathon
  • 15. Mesos - Konventionen • Ressources sind z.B. cpu, ram, port und disk und werden vom Mesos Master gemanaged • Attribute sind simple Key-Value Paare, die an die Frameworks übergeben werden • Ressourcen werden als Scalars, Ranges und Sets gemanaged • Zuordnung von Ressources zu Roles • Frameworks binden eine bestimmte Rolle oder „any“  Isolation verschiedener Frameworks möglich • Ermöglicht gezielte Überprovisionierung von Ressourcen eines Slaves
  • 16. Mesos – Advanced Features • Constraints: Genau ein Task pro Node, Task auf genau einer Node, … • Mesos Fetcher – Download von Ressourcen über URIs in die Sandbox eines Tasks (z.B. tar-Archive) • Oversubscription für „best-effort-Tasks“ • Persistent volumes bzw. multiple disk ressources für Storage • Quotas für unterschiedliche Frameworks • Reservations auf Slaves für bestimmte Rollen • Replicated Logging: Fehlertolerante Log-Replikation des Masters und von Frameworks • Monitoring: Metriken über REST-API
  • 17. Marathon – Orchestrierung von Groups Apps Group Apps Apps Apps Apps Tasks Apps Apps Apps Tasks = Hierarchie: depends 1:n 1:n 1:n 1:n Beispiel:
  • 19. Service Orchestrierung im Reality Check • Dependency Management • Service Discovery und Loadbalancing • Running at scale • Stateful Services • Monitoring & Logging • Aktuell: wenig Standards, viele heterogene (Teil-)Lösungen
  • 20. Dependency Management – Server • Die unter Mesos liegenden Maschinen müssen nach wie vor provisioniert und konfiguriert werden • Allerdings stark vereinfacht, da nur noch wenige Rollen • Grundsätzlich: Mesos Master und Mesos Slave Maschinen • Zusätzlich: Admin-Nodes, Edge-Nodes, Nodes f. spezielle Mesos-Rollen, … • Definition von Port-Ranges zwingend • Nicht jeder hat die Infrastruktur der „Hyperscaler“ • Hyperconverged Systems sind ideale Partner z.B. Nutanix, Cisco FlexPod • Realität ist anders: heterogene Hardware, vorhandener SAN-Storage, etc. • Konfigurationsmanagement mit z.B. Ansible, Chef oder Puppet • Module für Chef und Puppet existieren
  • 21. Dependency Management - Applikationen • Entwickler sollen keine Annahmen über die darunterliegende Infrastruktur machen • 12-factor apps • Geeignete Deploymentformate: • Container erleichtern dies wesentlich, das Docker-Format ist etabliert und sehr gut geeignet • Lösung für Nicht-Docker-Applikationen: Deployment z.B. als tarball über URIs und Mesos Fetcher in Verbindung mit MesosFetcher Cache • Lösungen für „secrets“ • Environment-Variable ???, Shared-FS (URIs!), Marathon Artifacts, Hashicorp Vault, …
  • 22. Service Discovery und Load-Balancing • Service Discovery Mechanismen behandeln nur die Erreichbarkeit von Services untereinander, sorgen aber nicht für ein intelligentes Routing • Service Discovery und Load-Balancing hängen aber eng miteinander zusammen • Statische Ports • Dynamische Ports • Service-Registries
  • 23. Service Discovery - statische Service Ports • Jede Instanz eines Services läuft auf einem eigenen Host mit „well- known-Port“ • Sobald mehrere Instanzen auf demselben Host laufen, müssen diese eine eigene IP erhalten • Software-Defined Networks (SDNs) wie Flannel, Calico, Weave, … • Discovery erfolgt typischerweise über DNS-A Records / Service Registry • Docker, Kubernetes (Flannel) und Mesos (Calico) entwickeln z.Zt. Lösungen in Richtung VIPs • Ziel: Hostübergreifende Kommunikation ohne Proxies mit Overlay- Netzwerken
  • 24. Service Discovery - dynamische Service Ports • Bridged Network ist in einem Mesos-Cluster ohne SDN die einzig sinnvolle Alternative • Ausnahme: Legacy-Applikationen, die feste Host-Ports voraussetzen • DNS Load-Balancing? • SRV Records, langsamer Refresh, DNS-Caches • Typische Lösungen: Reverse Proxy, dass well-known ports oder Pfade auf dynamische Ports mapped • Nginx, HAProxy, … • Dynamische Konfiguration mit den aktuellen Daten von z.B. Marathon über dessen Event-Bus: Bamboo, marathon-lb, AirBnb Synapse/Nerve, … • Herausforderung: reload des Proxies ohne Downtime bei vielen Routen
  • 25. Typische Loadbalancing und Service Discovery Topologie mit Marathon und HAProxy
  • 26. Service Discovery - Service-Registries • Registries liefern kein Routing! • Teilweise sehr spezielle Lösungen wie WeaveDNS oder Eureka • Vielversprechend ist eine Kombination von DNS und Load-Balancing / Routing
  • 28. Demo Mesos DNS und traefik
  • 29. Worker Node Traefik App Mesos Slave App App Worker Node Traefik App Mesos Slave App App Worker Node Traefik App Mesos Slave App App Worker Node Traefik App Mesos Slave App App Worker Node Traefik App Mesos Slave App App Control Node Mesos DNS Mesos Master Mesos Marathon Control Node Mesos DNS Mesos Master Mesos Marathon Beispiel für eine System- / Deployment- Architektur Control Node Mesos DNS Mesos Marathon Mesos Master Zookeeper Worker Node Traefik App Mesos Slave App App StorageStorage Admin Node Mesos DNS Mesos Master Mesos Marathon Admin Node Admin Reverse Proxy Logging (Elasticsearch / Kibana) Private Registry Edge Node Public Frontend API-Gateway Enterprise DNS Dev / Ops User http tcp http http DNS
  • 30. Running at scale • Private Registry • Isolierung verschiedener Projekte voneinander • Pragmatische Lösung: verschiedene Registries… • Hochverfügbar auslegen! • Hohe Anforderungen an Netzwerk und das darunterliegende File- System • HDFS, Clustered File-Systeme • Base Images standardisieren, kleine Images verwenden
  • 31. Running at scale • Performance • Container müssen adäquat gesized werden • Ressource-Limit überschritten: Container wird gekilled • Ressourcen sind nicht homogen • 1 CPU = 1 Share aber nicht jeder Core ist gleich! Gilt auch für RAM • Noisy neighbours • Schlechte Netzwerk-Isolation, viel Kommunikation, Interferenzen • Definition von Rollen für Maschinen, um besonders ressourcenhungrige Tasks zu isolieren
  • 32. Running at scale - Hochverfügbarkeit • Mesos ist eine gute Grundlage für hochverfügbare Applikationen • Mesos und Marathon handeln rolling upgrades, canaries, auto-scaling • Eine Container-basierte Architektur macht eine Applikation aber nicht automatisch resilient • Die Verfügbarkeit von Applikationen wird vom Entwickler bestimmt • Weiterhin existieren SPOFs: z.B. Docker Dämon • Failover und Persistierung von Zuständen muss nach wie vor durch die Applikation selbst geschehen • Zookeeper ist hierfür ein gutes Werkzeug…
  • 33. Stateful Services • Stateful Services werden von Mesos und Marathon unterstützt • Mesos Frameworks für ArangoDB, Elasticsearch, Cassandra, Hadoop, … • Local Disk • Persistent Volumes auf einem Slave bleiben auch nach Beendigung eines Containers erhalten • über Metadaten wird ein Container immer wieder auf der selben „richtigen“ Node gestartet • Shared-FS oder besser Clustered FS • SAN (Block Storage) wird zunehmend unterstützt (EMC, Netapps, …) • Beispiel: EMC rexray Treiber für Block Storage mit Docker • Für EMC SAN-Familie, aber z.B. auch für Open Stack Cinder • Unterstützung in Mesos: DVDI (Docker Volume Driver Isolator module)
  • 35. Monitoring • Viele Facetten • Alarmierung, Resilienz • Fehleranalyse – Logging • Metriken von Services und Applikationen • Kapazitätsplanung des gesamten Hardware Clusters • Pragmatisch bleiben!
  • 36. Alarmierung, Resilienz • Gute Unterstützung von Healthchecks und Resilienz durch Marathon • Automatisierte Restarts • Neuprovisionierung bei Hardware-Ausfällen • Healthchecks • verpflichtend • Je mehr, je besser • Ready-state
  • 37. Logging • Log-Aggregation zwingend • Standardisiertes Log-Format • Getrennte Hardware für Logs, niemals lokale Platten • Logs sollten Prozess-Ids, ECIDs, UserIds o.ä. enthalten • Logging nach stdout / stderr • Konfiguration der Log-Files durch Ops • Typischerweise Umleitung mit logstash • ELK-Stack zur Auswertung
  • 38. Metriken von Services, Applikationen, Hardware • Allocation vs. Utilization • Monitoring von CPU und RAM unter Last • Auswertung der Metriken von Mesos • Mesos Konsole, Mesos-UI • End2End Monitoring • Logging von TimeStamps via Javascript • Regelmäßiges Reporting auf Basis dieser Daten • Tools: sysdig Monitoring, Prometheus und viele, viele mehr
  • 39. Demo scale-up und Mesos-UI
  • 40. Zusammenfassung • Service-Orchestrierung mit Mesos ist gut möglich und „im großen Stil“ produktionserprobt • DC/OS liefert hier eine schlüsselfertige Komplettlösung • Etablierte Partner wie HP, MS oder Cisco • Mesos bleibt dabei ein offeneres System als andere Lösungen • Aktuell sehr hohe Dynamik (Anzahl Releases, etc.) • Viele Fragen sind offen, viele Lösungen existieren, best-practices bilden sich erst langsam heraus