SlideShare ist ein Scribd-Unternehmen logo
Seite 1
Projekt APOK
Microservice Management
mit Mesosphere DC/OS
Seite 2
Die Vision - Ende 2015
• Dev - Projekt APOK
• schnellere Time-to-Market
• agile Methodiken, Scrum, Continuous Delivery, DevOps
• kleine autonome interdisziplinäre Teams, Conway’s Law
• vertikale Dekomposition, self-contained systems, Microservices
• zeitgemäße Softwareprodukte und den Anforderungen angepasste
Produktauswahl, breiteres Produktportfolio
• Ops - BA-Private-Cloud-Programm
• Ressourcen im self-service, “AWS-Gefühl”
• kontinuierliche Verfügbarkeit, always-on
• einheitliche, vereinfachte Administration
• einheitliches Logging und Monitoring
Seite 3
Projekt APOK - Ende 2015
Seite 4
Portalmakroarchitektur: Vertikale Dekomposition
ContentSuche
JobSuche
BNO
DVO
Kontakt
Veranstaltungen
Frontend Integration
OnlineASU
Terminvergabe
Profil
Integration / Plattformprodukte
Container Plattform
Content(DAM)
Content(WCS)
Vertikale:
Sicherheitsinfrastruktur / WebSSO
Seite 5
• Eine Vertikale ist für sich alleine voll funktional und besitzt keine
Abhängigkeiten zu Komponenten außerhalb
• Funktionalitäten wie UI oder Backend werden von Microservices als
REST-Ressourcen zur Verfügung gestellt
• Unabhängig voneinander deploybare und skalierbare, kleine Services kapseln
Funktionalitäten und Plattformprodukte (z.B. Elasticsearch, Kafka, Cassandra)
• Vertikale verfügen über eine eigene autarke Datenhaltung
• Die Vertikalen und deren Bestandteile sind agil von einem kleinen Team
isoliert entwickelbar, testbar und auslieferbar
Shared Nothing von Vertikalen – Vertikale sind autonom
Seite 6
Betriebliche Komplexität von Microservices (1 / 2)
• Die Anzahl von zu liefernden Artefakten steigt exponential
• Traditionelle zentrale Betriebseinheiten würden zum Bottleneck
• DevOps-Methodik ist zwingend
• Verantwortung für deploy und run bei den Entwicklerteams
Seite 7
Betriebliche Komplexität von Microservices (2 / 2)
• rapid provisioning → Rechner Ressourcen im self-service
• basic monitoring → Logging und Monitoring im self-service
• rapid application deployment → automatisierte Deployment-Pipelines
https://martinfowler.com/bliki/MicroservicePrerequisites.html
Seite 8
BA-Private-Cloud Programm – Ende 2015
Seite 9
Cloud-Computing oder Virtualisierung 2.0?
Native
• unterschiedliche Architekturen
• unterschiedliche Denkmuster
• unterschiedliche Ziele
• unterschiedliche Software-Produkte
Enterprise-IT Cloud-Computing
Seite 10
Enterprise IT
Seite 11
Cloud-Computing
Seite 12
Cloud-Computing zum Nachlesen...
Seite 13
Cloud-Computing-Pattern
einige Cloud-Computing Pattern - es gibt mehr, aber
die Folgenden sind wichtig!
Quelle: Randy Bias, Pets vs. Cattle, The Elastic Cloud Story, DevOps Chicago Meeting 26.2.2014
Seite 14
Resilienz - Die Verantwortung für Verfügbarkeit liegt bei
der Software
Enterprise-IT Cloud-Computing
Seite 15
Pets vs. Cattle
• einzigartig
• kitty.company.com
• spezialisiert, getuned
• scale-up
• viele identische
• kh01.company.com
• generisch
• scale-out
Seite 16
scale out vs. scale-up
Seite 17
Beispiel für scale-out: verteilte DB Cassandra mehr Server
= mehr Storage = mehr IOs = lineare Skalierbarkeit
Seite 18
kleine Fehlerdomänen
Seite 19
Antipattern: große Fehlerdomänen = große Einschläge
Seite 20
Compute: RAIS = Redundant Array of Inexpensive
Servers
Seite 21
Netzwerk: einfache, geroutete, flache Spine-and-Leaf
Topologie
Seite 22
Storage: Local Storage oder Direct Attached Storage
• cloud-native Software managed ihre Replikation ohne spezielle Hardware
• Netzisolation und Zugriffskontrolle via SDN
• Lokaler Storage oder DAS in der selben physikalischen Infrastruktur wie
die Applikationen
DB-Lan
Backend-FW
C-MAN
App Server
vs.
Seite 23
Virtualisierung mit LINUX Containern - der Hypervisor
der Zukunft ist KEIN Hypervisor
Seite 24
Virtualisierung mit LINUX Containern 2018 - Bare Metal
Angebote in der Public Cloud
Seite 25
Mesosphere DC/OS
• 7/2016 Aufbau der Container-Plattform als zukünftige Plattform
für Applikationen im Rahmen von BA-Online 2020
• So weit möglich Umsetzung der genannten Cloud-Pattern
Seite 26
Mesosphere DC/OS - Data Center Operating System
Seite 27
Mesosphere DC/OS - Nodes
Seite 28
Architektur Mesosphere DC/OS
Seite 29
Don’t roll your own...
Seite 30
SysArch DC/OS in der BA - Entwicklung / Test
• 1 Cluster für alle Entwicklungs- und Testaktivitäten
• x-86 Standard Hardware, lokaler Storage
• Adressierung über Hardware-Loadbalancer
• Healthcheck Container erlauben kontrolliertes Entfernen eines Standorts
Seite 31
• Identische Cluster für Dev/Test und Produktion
• Produktion aktiv-aktiv auf 2 Standorten
• 2 unabhängige DC/OS Installationen in Produktion
•
SysArch DC/OS in der BA - Produktion aktiv-aktiv
DC/OS-Cluster Thf DC/OS-Cluster Vdt
Seite 32
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 33
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 34
Mesosphere DC/OS - aus der Stratosphäre
Seite 35
Apache Mesos - Ressourcen-Management und
Ressourcen-Isolation
● offene Standards, herstellerunabhängig
● flexibel, modular, kein Lock-In
● erweiterbar für zukünftige Entwicklungen
● robust, seit 2011 im Produktionsbetrieb
Container Network - CNI Container Storage - CSI
Container Runtime - OCI
Seite 36
Apache Mesos - Architektur
Seite 37
Service Orchestrierung von Applikationen mit DC/OS
Marathon
http://container.webapps.idst.ibaintern.de
Beispiel für eine Continuous Delivery
Pipeline auf Basis von DC/OS,
Marathon, Docker und Jenkins
vollständige Abstraktion der
Infrastruktur vom Entwickler
PUT app.json
Seite 38
Container Konfiguration in DC/OS (1)
Seite 39
Container Konfiguration in DC/OS (2)
Seite 40
Container Konfiguration in DC/OS (3)
Seite 41
Container Konfiguration in DC/OS (4)
Seite 42
Container Konfiguration in DC/OS (4)
Seite 43
ein Kontext in DC/OS
Seite 44
Microservices einer Vertikale in DC/OS
Seite 45
DC/OS Frameworks
Seite 46
Frameworks: Produktspezifisches 2-level scheduling
mit Mesos Frameworks für stateful Services
Scheduler
Cassandra
Mesos Master
Zookeeper
Quorum
Standby Master Standby Master
Scheduler
Kafka
Scheduler
Marathon
Host1
Mesos Agent
UCR
Container
Containerstateless
Container
Kafka
Cassandra
= Framework Marathon
= Framework Cassandra
= Framework Kafka
Host2
Mesos Agent
UCR
Container
Containerstateless
Container
Kafka
Cassandra
Host3
Mesos Agent
UCR
Container
Containerstateless
Container
Kafka
Cassandra
Docker
Registry
DC/OS
Catalogue
Plattformprodukte Applikationen
Seite 47
Automatisierter Betrieb von Plattformprodukten mit
DC/OS Frameworks
• Automatisierung betrieblicher Tasks für geclusterte datenhaltende
Services wie Elasticsearch, Cassandra, Kafka...
• Provisionierung / Erweiterung eines Clusters
• Konfiguration einzelner Clustermember
• Upgrade, Wartung, Tasks ohne Downtime
• Fail-Over (Task, Node, RZ) ohne Downtime
• Integration dieser Produkte in DC/OS
• Security (Authentifizierung, Verschlüsselung)
• Netzwerk, Storage
• CLI, UI, Monitoring, Logging
• Software-Repository, Konfigurations- management
Seite 48
Automatisierte Verteilung von Anwendungen in einem
generischen Hardware Cluster
pets vs. cattle
Loadbalancer
Webserver
AppServer
DB
Messaging
DC/OStraditionelle IT
Seite 49
DC/OS Catalogue (Private Universe)
Seite 50
Security - einige Organisationen benötigen TLS im
Cluster ...
obwohl der Netzverkehr die Backplane nie verlässt...
Seite 51
Konfigurationsmanagement - Secrets und Zertifikate
• sichere Ablage von Secrets und Zertifikaten in einem Secret Store
• rollenbasierter Zugriff
• ermöglicht verschlüsselte Kommunikation innerhalb des Clusters (TLS)
Seite 52
Sicherheit - Benutzerverwaltung, Rechte und Rollen
• Benutzerverwaltung, Rollen- und Rechteverwaltung, AD-Integration
• Integration von Plattformprodukten wie Kafka und Cassandra
• eigene CA mit Möglichkeit zur Verwendung eigener Zertifikate
Seite 53
Monitoring und Logging
• einheitliches Monitoring aller Applikationen UND Plattformprodukte
mit Hilfe von DC/OS Metrics und DC/OS Logging
• Sammeln aller Metriken und Logs und Übertragung in ELK-Stack
• Dashboards können von Entwicklern nach Bedarf selbst erstellt
werden
Seite 54
Standards für Container-Plattform
Private Container Registry
Base Images app.json
Host 1 Host x
local volumes local volumes
bridged network
http://con-sint.webapp.idst.ibaintern.de/apok/dev/contentsuche
from
push
pull
CD Pipeline
Container-Format
Plattformprodukte
Healthchecks
RHEL7.4
Seite 55
Java und LINUX Container
die JVM ist -aktuell- nicht container-aware!
Seite 56
LINUX Container: namespaces vs. cgroups
namespaces dienen der
Isolation
control groups verwalten
Ressourcen
pid (Prozesse) cpu (CPU Shares!)
net (Netzwerk Interface, Routing) cpuset (Zuweisen Prozess auf CPU)
ipc (System V Prozesskommunikation) memory (RAM inkl. Swap)
mnt (mount points, Filesysteme) blkio (Begrenzung read / writes)
uts (hostname) devices
user (uids) net_cls, net_prio
(Netzwerkdurchsatz)
• namespaces = begrenzen, was man benutzt
• cgroups = begrenzen, wieviel man benutzt
Seite 57
• CPU Shares (Anteil an der CPU-Zeit aller Kerne eines Servers)
• CPU Sets (hier nicht relevant!)
• Priorisierung der verfügbaren CPU-Zeit über alle Kerne eines Hosts
• Default (komplette CPU-Zeit): 1024 pro Kern
• sudo cgcreate –g cpu:tralala
• sudo cgset –r cpu.shares=768 tralala
• → Reservierung auf 75% der insgesamt verfügbaren CPU-Zeit bei einem Kern
• Freie CPU-cycle werden an andere cgroups gegeben!
• Limitierung erfolgt erst, wenn keine CPU-Ressourcen über dem Limit verfügbar
• CPU shares geben also eine Garantie mindestens den angegebenen
Anteil an CPU-Zeit zu erhalten d.h. eher eine Reservierung als ein Limit
• CFS (Completely Fair Scheduler) = harte Limitierung der CPU-Shares
cgroups: CPU
Seite 58
Java im Container - CPU Probleme
• Bis JDK9 ist die JVM nicht container-aware, sie wird auf Basis des
Hosts initialisiert
• verfügbare CPU: JDK 7/8 : Ressourcen über sysconf
• sysconf(_SC_NRPROCESSORS_ONLN);
• → Runtime.getRuntime().availableProcessors == 32
• Berechnung der verfügbaren Threads für GC, JIT, etc. erfolgt auf dieser Basis
• Langsamer Startup bei Verwendung von CFS
• Erhöhung der Reservierung notwendig
• Trick: Pod mit einem sleep(60) Container deployen, der die Reservierung so
eine Minute lang erhöht
• Empfehlung für typische Java Applikationen (RAM-lastig): Nutzung
von CPU shares ohne CFS, d.h. weiche Limits
• hoher CPU Verbrauch von Java Applikationen ist oft ein gc-Problem...
Seite 59
cgroups: Memory
• Jede cgroup kann harte oder weiche Limits für Memory erhalten
• unter Mesos / Docker: Für Hauptspeicher immer harte Limits
• Überschreitung → Swap → OOM killer
• Problem: Swap, Default cgroups = 2 * mem → zu hoch!
• Workaround: Übergabe memory-swap = mem als Parameter an docker-engine
• Log:
• Empfehlung: Swapping an den Mesos Hosts ausschalten!
... mem.cpp:625] OOM notifier is triggered for container
tec32_healthcheck.9d17bc84-0a4c-11e7-a081-70b3d5800003
… mem.cpp: 644] OOM detected for container
tec32_healthcheck.9d17bc84-0a4c-11e7-a081-70b3d5800003
… mem.cpp: 685] Memory limit exceeded: Requested: 2048MB Maximum used: 2048MB
Seite 60
Java im Container - CPU Probleme
• Bis JDK9 ist die JVM nicht container-aware, sie wird auf Basis des
Hosts initialisiert
• verfügbares RAM JDK 7/8 : typischerweise ¼ des RAMs des Hosts
• Angabe von -Xmx zur Begrenzung des Heaps zwingend
• Startup beschleunigen durch -Xms = -Xmx
• Erhöhung RAM löst meist schon gc-Probleme
• Problem: seit JDK8 laufen große Teile der JVM außerhalb des
Heaps
• mind. 300 MB + Java Heap, bei Produkten wie Cassandra, Kafka,
Elasticsearch, Lucene Page Cache einkalkulieren!
Seite 61
Bei der Dimensionierung des Container-RAMs darf
nicht nur der Java-Heap berücksichtigt werden
OS-Tools (RHEL)
JRE8
Code Cache für JIT JRE8
Eden
Old Space
Meta Space
NIO
-Xms, -Xmx
-XX:MaxMetaspaceSize
~96M
~256M
~60M
Direct Buffers
I/OOS Page Cache
Threads 1M pro Thread bei 64Bit
JVM Heap
Konstant
Variabel
Seite 62
Memory: Lessons Learned - Thanks for the RAM!
Seite 63
Enter JDK10 - alles wird gut?
erkennt cpusets und cpushares
Annahmen bzgl. RAM sind naiv, -Xms und -Xmx weiterhin
notwendig
Java benötigt weiterhin viel Memory im Vergleich zu anderen
Sprachen
Seite 64
Lessons Learned nach einem Jahr DC/OS:
• Produktionsbetrieb mit LINUX-Containern auf DC/OS ist auch für eine
klassische Enterprise-IT Organisation machbar
• zuverlässig, keinerlei “on-call-events” in Produktion
• schnelle MTTR (mean time to recovery) bei Infrastrukturfehlern
• vollständige Automation des Betriebs von modernen
Plattformprodukten (Cassandra, Kafka, Elasticsearch…)
• große Vorteile von Containern gegenüber VMs
• Ressourcen-Pool für Dev/Test hat sich bewährt
• einheitlicher Betrieb von sehr heterogenen Produkten
• Applikationen, WebServer, Proxies, Piwik, Invaris, Cassandra, Kafka,
Elasticsearch, Fremdprodukte, …
• ...

Weitere ähnliche Inhalte

Was ist angesagt?

MEAN SCS in der Cloud
MEAN SCS in der CloudMEAN SCS in der Cloud
MEAN SCS in der Cloud
Torsten Fink
 
Cloud Transformation im Rechenzentrum
Cloud Transformation im RechenzentrumCloud Transformation im Rechenzentrum
Cloud Transformation im Rechenzentrum
A. Baggenstos & Co. AG
 
Microservices mit Java EE - am Beispiel von IBM Liberty
Microservices mit Java EE - am Beispiel von IBM LibertyMicroservices mit Java EE - am Beispiel von IBM Liberty
Microservices mit Java EE - am Beispiel von IBM Liberty
Michael Hofmann
 
CodeTalks Vortrag: Automatisierung mit Ansible & Jenkins @ LeanIX Enterprise ...
CodeTalks Vortrag: Automatisierung mit Ansible & Jenkins @ LeanIX Enterprise ...CodeTalks Vortrag: Automatisierung mit Ansible & Jenkins @ LeanIX Enterprise ...
CodeTalks Vortrag: Automatisierung mit Ansible & Jenkins @ LeanIX Enterprise ...
LeanIX GmbH
 
Erfahrungsbericht über die Aktualisierung einer Consumer Mailplattform mit UC...
Erfahrungsbericht über die Aktualisierung einer Consumer Mailplattform mit UC...Erfahrungsbericht über die Aktualisierung einer Consumer Mailplattform mit UC...
Erfahrungsbericht über die Aktualisierung einer Consumer Mailplattform mit UC...
Univention GmbH
 
Collaboration Days 2011 - Damit die Tester schneller ran können.
Collaboration Days 2011 - Damit die Tester schneller ran können.Collaboration Days 2011 - Damit die Tester schneller ran können.
Collaboration Days 2011 - Damit die Tester schneller ran können.
David Schneider
 
Windows Azure SQL Databases
Windows Azure SQL DatabasesWindows Azure SQL Databases
Windows Azure SQL Databases
Jan Hentschel
 
Single Sign-On durch LDAP Anbindung an den Basler Schulen – Anforderung, Umfa...
Single Sign-On durch LDAP Anbindung an den Basler Schulen – Anforderung, Umfa...Single Sign-On durch LDAP Anbindung an den Basler Schulen – Anforderung, Umfa...
Single Sign-On durch LDAP Anbindung an den Basler Schulen – Anforderung, Umfa...
Univention GmbH
 
Einführung in Puppet und Vagrant
Einführung in Puppet und VagrantEinführung in Puppet und Vagrant
Einführung in Puppet und Vagrant
s0enke
 
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
 
Schlanke Webarchitekturen nicht nur mit JSF 2 und CDI
Schlanke Webarchitekturen nicht nur mit JSF 2 und CDISchlanke Webarchitekturen nicht nur mit JSF 2 und CDI
Schlanke Webarchitekturen nicht nur mit JSF 2 und CDI
adesso AG
 
DWX Developer Week 2015 - Microservice architecture applied
DWX Developer Week 2015 - Microservice architecture appliedDWX Developer Week 2015 - Microservice architecture applied
DWX Developer Week 2015 - Microservice architecture applied
Ramon Anger
 
Service Orchestrierung mit Apache Mesos
Service Orchestrierung mit Apache MesosService Orchestrierung mit Apache Mesos
Service Orchestrierung mit Apache Mesos
Ralf Ernst
 
Enterprise UI
Enterprise UIEnterprise UI
Enterprise UI
gedoplan
 
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
 
Vorlesung - Cloud Infrastrukturen - Einleitung | anynines
Vorlesung - Cloud Infrastrukturen - Einleitung | anyninesVorlesung - Cloud Infrastrukturen - Einleitung | anynines
Vorlesung - Cloud Infrastrukturen - Einleitung | anynines
anynines GmbH
 
Was ist neu in .NET 4.5?
Was ist neu in .NET 4.5?Was ist neu in .NET 4.5?
Was ist neu in .NET 4.5?
Digicomp Academy AG
 
SQL oder NoSQL - Die Auswahl der richtigen Datenbankplattform für die Cloud
SQL oder NoSQL - Die Auswahl der richtigen Datenbankplattform für die CloudSQL oder NoSQL - Die Auswahl der richtigen Datenbankplattform für die Cloud
SQL oder NoSQL - Die Auswahl der richtigen Datenbankplattform für die Cloud
AWS Germany
 
Vorlesung - Cloud Infrastrukturen - OpenStack Part 1 | anynines
Vorlesung - Cloud Infrastrukturen - OpenStack Part 1 | anyninesVorlesung - Cloud Infrastrukturen - OpenStack Part 1 | anynines
Vorlesung - Cloud Infrastrukturen - OpenStack Part 1 | anynines
anynines GmbH
 
May the forge be with you
May the forge be with youMay the forge be with you
May the forge be with you
Sandro Sonntag
 

Was ist angesagt? (20)

MEAN SCS in der Cloud
MEAN SCS in der CloudMEAN SCS in der Cloud
MEAN SCS in der Cloud
 
Cloud Transformation im Rechenzentrum
Cloud Transformation im RechenzentrumCloud Transformation im Rechenzentrum
Cloud Transformation im Rechenzentrum
 
Microservices mit Java EE - am Beispiel von IBM Liberty
Microservices mit Java EE - am Beispiel von IBM LibertyMicroservices mit Java EE - am Beispiel von IBM Liberty
Microservices mit Java EE - am Beispiel von IBM Liberty
 
CodeTalks Vortrag: Automatisierung mit Ansible & Jenkins @ LeanIX Enterprise ...
CodeTalks Vortrag: Automatisierung mit Ansible & Jenkins @ LeanIX Enterprise ...CodeTalks Vortrag: Automatisierung mit Ansible & Jenkins @ LeanIX Enterprise ...
CodeTalks Vortrag: Automatisierung mit Ansible & Jenkins @ LeanIX Enterprise ...
 
Erfahrungsbericht über die Aktualisierung einer Consumer Mailplattform mit UC...
Erfahrungsbericht über die Aktualisierung einer Consumer Mailplattform mit UC...Erfahrungsbericht über die Aktualisierung einer Consumer Mailplattform mit UC...
Erfahrungsbericht über die Aktualisierung einer Consumer Mailplattform mit UC...
 
Collaboration Days 2011 - Damit die Tester schneller ran können.
Collaboration Days 2011 - Damit die Tester schneller ran können.Collaboration Days 2011 - Damit die Tester schneller ran können.
Collaboration Days 2011 - Damit die Tester schneller ran können.
 
Windows Azure SQL Databases
Windows Azure SQL DatabasesWindows Azure SQL Databases
Windows Azure SQL Databases
 
Single Sign-On durch LDAP Anbindung an den Basler Schulen – Anforderung, Umfa...
Single Sign-On durch LDAP Anbindung an den Basler Schulen – Anforderung, Umfa...Single Sign-On durch LDAP Anbindung an den Basler Schulen – Anforderung, Umfa...
Single Sign-On durch LDAP Anbindung an den Basler Schulen – Anforderung, Umfa...
 
Einführung in Puppet und Vagrant
Einführung in Puppet und VagrantEinführung in Puppet und Vagrant
Einführung in Puppet und Vagrant
 
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
 
Schlanke Webarchitekturen nicht nur mit JSF 2 und CDI
Schlanke Webarchitekturen nicht nur mit JSF 2 und CDISchlanke Webarchitekturen nicht nur mit JSF 2 und CDI
Schlanke Webarchitekturen nicht nur mit JSF 2 und CDI
 
DWX Developer Week 2015 - Microservice architecture applied
DWX Developer Week 2015 - Microservice architecture appliedDWX Developer Week 2015 - Microservice architecture applied
DWX Developer Week 2015 - Microservice architecture applied
 
Service Orchestrierung mit Apache Mesos
Service Orchestrierung mit Apache MesosService Orchestrierung mit Apache Mesos
Service Orchestrierung mit Apache Mesos
 
Enterprise UI
Enterprise UIEnterprise UI
Enterprise UI
 
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
 
Vorlesung - Cloud Infrastrukturen - Einleitung | anynines
Vorlesung - Cloud Infrastrukturen - Einleitung | anyninesVorlesung - Cloud Infrastrukturen - Einleitung | anynines
Vorlesung - Cloud Infrastrukturen - Einleitung | anynines
 
Was ist neu in .NET 4.5?
Was ist neu in .NET 4.5?Was ist neu in .NET 4.5?
Was ist neu in .NET 4.5?
 
SQL oder NoSQL - Die Auswahl der richtigen Datenbankplattform für die Cloud
SQL oder NoSQL - Die Auswahl der richtigen Datenbankplattform für die CloudSQL oder NoSQL - Die Auswahl der richtigen Datenbankplattform für die Cloud
SQL oder NoSQL - Die Auswahl der richtigen Datenbankplattform für die Cloud
 
Vorlesung - Cloud Infrastrukturen - OpenStack Part 1 | anynines
Vorlesung - Cloud Infrastrukturen - OpenStack Part 1 | anyninesVorlesung - Cloud Infrastrukturen - OpenStack Part 1 | anynines
Vorlesung - Cloud Infrastrukturen - OpenStack Part 1 | anynines
 
May the forge be with you
May the forge be with youMay the forge be with you
May the forge be with you
 

Ähnlich wie Jug nbg containerplattform dcos

Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
QAware GmbH
 
Cloud-native Apps 2.0
Cloud-native Apps 2.0Cloud-native Apps 2.0
Cloud-native Apps 2.0
QAware GmbH
 
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
 
micro services
micro servicesmicro services
micro services
smancke
 
Skalierung & Performance
Skalierung & PerformanceSkalierung & Performance
Skalierung & Performance
glembotzky
 
Data Center Automation for the Cloud
Data Center Automation for the CloudData Center Automation for the Cloud
Data Center Automation for the Cloud
inovex GmbH
 
OEM Cloud Control - Hochverfügbar von Kopf bis Fuß
OEM Cloud Control - Hochverfügbar von Kopf bis Fuß OEM Cloud Control - Hochverfügbar von Kopf bis Fuß
OEM Cloud Control - Hochverfügbar von Kopf bis Fuß
DanielHillinger
 
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
Virttoo org
 
Architektur und Automation als Enabler für DevOps
Architektur und Automation als Enabler für DevOpsArchitektur und Automation als Enabler für DevOps
Architektur und Automation als Enabler für DevOps
matfsw
 
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
AOE
 
Product Update: Infopark Cloud Express - Thomas Witt
Product Update: Infopark Cloud Express - Thomas WittProduct Update: Infopark Cloud Express - Thomas Witt
Product Update: Infopark Cloud Express - Thomas Witt
JustRelate
 
1. Cloud Native Meetup Innsbruck, 23.11.2023
1. Cloud Native Meetup Innsbruck, 23.11.20231. Cloud Native Meetup Innsbruck, 23.11.2023
1. Cloud Native Meetup Innsbruck, 23.11.2023
Johannes Kleinlercher
 
Public Cloud Erfahrungsbericht SBB
Public Cloud Erfahrungsbericht SBBPublic Cloud Erfahrungsbericht SBB
Public Cloud Erfahrungsbericht SBB
BATbern
 
BizSpark goes Cloud
BizSpark goes CloudBizSpark goes Cloud
BizSpark goes Cloud
Patric Boscolo
 
skilllocation Foliensatz zu Microsoft Azure
skilllocation Foliensatz zu Microsoft Azureskilllocation Foliensatz zu Microsoft Azure
skilllocation Foliensatz zu Microsoft Azure
Carola Pantenburg
 
Cloud Infrastructure with Crossplane
Cloud Infrastructure with CrossplaneCloud Infrastructure with Crossplane
Cloud Infrastructure with Crossplane
QAware GmbH
 
Enterprise Cloud Native ist das neue Normal
Enterprise Cloud Native ist das neue NormalEnterprise Cloud Native ist das neue Normal
Enterprise Cloud Native ist das neue Normal
QAware GmbH
 
papaya AWS Präsentation CeBIT 2010
papaya AWS Präsentation CeBIT 2010papaya AWS Präsentation CeBIT 2010
papaya AWS Präsentation CeBIT 2010
papaya
 
Server Revolutions- Der Spring Source DM Server
Server Revolutions- Der Spring Source DM ServerServer Revolutions- Der Spring Source DM Server
Server Revolutions- Der Spring Source DM Server
Sandro Sonntag
 
Make Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform EngineeringMake Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform Engineering
QAware GmbH
 

Ähnlich wie Jug nbg containerplattform dcos (20)

Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
 
Cloud-native Apps 2.0
Cloud-native Apps 2.0Cloud-native Apps 2.0
Cloud-native Apps 2.0
 
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
 
micro services
micro servicesmicro services
micro services
 
Skalierung & Performance
Skalierung & PerformanceSkalierung & Performance
Skalierung & Performance
 
Data Center Automation for the Cloud
Data Center Automation for the CloudData Center Automation for the Cloud
Data Center Automation for the Cloud
 
OEM Cloud Control - Hochverfügbar von Kopf bis Fuß
OEM Cloud Control - Hochverfügbar von Kopf bis Fuß OEM Cloud Control - Hochverfügbar von Kopf bis Fuß
OEM Cloud Control - Hochverfügbar von Kopf bis Fuß
 
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
 
Architektur und Automation als Enabler für DevOps
Architektur und Automation als Enabler für DevOpsArchitektur und Automation als Enabler für DevOps
Architektur und Automation als Enabler für DevOps
 
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
 
Product Update: Infopark Cloud Express - Thomas Witt
Product Update: Infopark Cloud Express - Thomas WittProduct Update: Infopark Cloud Express - Thomas Witt
Product Update: Infopark Cloud Express - Thomas Witt
 
1. Cloud Native Meetup Innsbruck, 23.11.2023
1. Cloud Native Meetup Innsbruck, 23.11.20231. Cloud Native Meetup Innsbruck, 23.11.2023
1. Cloud Native Meetup Innsbruck, 23.11.2023
 
Public Cloud Erfahrungsbericht SBB
Public Cloud Erfahrungsbericht SBBPublic Cloud Erfahrungsbericht SBB
Public Cloud Erfahrungsbericht SBB
 
BizSpark goes Cloud
BizSpark goes CloudBizSpark goes Cloud
BizSpark goes Cloud
 
skilllocation Foliensatz zu Microsoft Azure
skilllocation Foliensatz zu Microsoft Azureskilllocation Foliensatz zu Microsoft Azure
skilllocation Foliensatz zu Microsoft Azure
 
Cloud Infrastructure with Crossplane
Cloud Infrastructure with CrossplaneCloud Infrastructure with Crossplane
Cloud Infrastructure with Crossplane
 
Enterprise Cloud Native ist das neue Normal
Enterprise Cloud Native ist das neue NormalEnterprise Cloud Native ist das neue Normal
Enterprise Cloud Native ist das neue Normal
 
papaya AWS Präsentation CeBIT 2010
papaya AWS Präsentation CeBIT 2010papaya AWS Präsentation CeBIT 2010
papaya AWS Präsentation CeBIT 2010
 
Server Revolutions- Der Spring Source DM Server
Server Revolutions- Der Spring Source DM ServerServer Revolutions- Der Spring Source DM Server
Server Revolutions- Der Spring Source DM Server
 
Make Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform EngineeringMake Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform Engineering
 

Jug nbg containerplattform dcos

  • 1. Seite 1 Projekt APOK Microservice Management mit Mesosphere DC/OS
  • 2. Seite 2 Die Vision - Ende 2015 • Dev - Projekt APOK • schnellere Time-to-Market • agile Methodiken, Scrum, Continuous Delivery, DevOps • kleine autonome interdisziplinäre Teams, Conway’s Law • vertikale Dekomposition, self-contained systems, Microservices • zeitgemäße Softwareprodukte und den Anforderungen angepasste Produktauswahl, breiteres Produktportfolio • Ops - BA-Private-Cloud-Programm • Ressourcen im self-service, “AWS-Gefühl” • kontinuierliche Verfügbarkeit, always-on • einheitliche, vereinfachte Administration • einheitliches Logging und Monitoring
  • 3. Seite 3 Projekt APOK - Ende 2015
  • 4. Seite 4 Portalmakroarchitektur: Vertikale Dekomposition ContentSuche JobSuche BNO DVO Kontakt Veranstaltungen Frontend Integration OnlineASU Terminvergabe Profil Integration / Plattformprodukte Container Plattform Content(DAM) Content(WCS) Vertikale: Sicherheitsinfrastruktur / WebSSO
  • 5. Seite 5 • Eine Vertikale ist für sich alleine voll funktional und besitzt keine Abhängigkeiten zu Komponenten außerhalb • Funktionalitäten wie UI oder Backend werden von Microservices als REST-Ressourcen zur Verfügung gestellt • Unabhängig voneinander deploybare und skalierbare, kleine Services kapseln Funktionalitäten und Plattformprodukte (z.B. Elasticsearch, Kafka, Cassandra) • Vertikale verfügen über eine eigene autarke Datenhaltung • Die Vertikalen und deren Bestandteile sind agil von einem kleinen Team isoliert entwickelbar, testbar und auslieferbar Shared Nothing von Vertikalen – Vertikale sind autonom
  • 6. Seite 6 Betriebliche Komplexität von Microservices (1 / 2) • Die Anzahl von zu liefernden Artefakten steigt exponential • Traditionelle zentrale Betriebseinheiten würden zum Bottleneck • DevOps-Methodik ist zwingend • Verantwortung für deploy und run bei den Entwicklerteams
  • 7. Seite 7 Betriebliche Komplexität von Microservices (2 / 2) • rapid provisioning → Rechner Ressourcen im self-service • basic monitoring → Logging und Monitoring im self-service • rapid application deployment → automatisierte Deployment-Pipelines https://martinfowler.com/bliki/MicroservicePrerequisites.html
  • 9. Seite 9 Cloud-Computing oder Virtualisierung 2.0? Native • unterschiedliche Architekturen • unterschiedliche Denkmuster • unterschiedliche Ziele • unterschiedliche Software-Produkte Enterprise-IT Cloud-Computing
  • 13. Seite 13 Cloud-Computing-Pattern einige Cloud-Computing Pattern - es gibt mehr, aber die Folgenden sind wichtig! Quelle: Randy Bias, Pets vs. Cattle, The Elastic Cloud Story, DevOps Chicago Meeting 26.2.2014
  • 14. Seite 14 Resilienz - Die Verantwortung für Verfügbarkeit liegt bei der Software Enterprise-IT Cloud-Computing
  • 15. Seite 15 Pets vs. Cattle • einzigartig • kitty.company.com • spezialisiert, getuned • scale-up • viele identische • kh01.company.com • generisch • scale-out
  • 16. Seite 16 scale out vs. scale-up
  • 17. Seite 17 Beispiel für scale-out: verteilte DB Cassandra mehr Server = mehr Storage = mehr IOs = lineare Skalierbarkeit
  • 19. Seite 19 Antipattern: große Fehlerdomänen = große Einschläge
  • 20. Seite 20 Compute: RAIS = Redundant Array of Inexpensive Servers
  • 21. Seite 21 Netzwerk: einfache, geroutete, flache Spine-and-Leaf Topologie
  • 22. Seite 22 Storage: Local Storage oder Direct Attached Storage • cloud-native Software managed ihre Replikation ohne spezielle Hardware • Netzisolation und Zugriffskontrolle via SDN • Lokaler Storage oder DAS in der selben physikalischen Infrastruktur wie die Applikationen DB-Lan Backend-FW C-MAN App Server vs.
  • 23. Seite 23 Virtualisierung mit LINUX Containern - der Hypervisor der Zukunft ist KEIN Hypervisor
  • 24. Seite 24 Virtualisierung mit LINUX Containern 2018 - Bare Metal Angebote in der Public Cloud
  • 25. Seite 25 Mesosphere DC/OS • 7/2016 Aufbau der Container-Plattform als zukünftige Plattform für Applikationen im Rahmen von BA-Online 2020 • So weit möglich Umsetzung der genannten Cloud-Pattern
  • 26. Seite 26 Mesosphere DC/OS - Data Center Operating System
  • 29. Seite 29 Don’t roll your own...
  • 30. Seite 30 SysArch DC/OS in der BA - Entwicklung / Test • 1 Cluster für alle Entwicklungs- und Testaktivitäten • x-86 Standard Hardware, lokaler Storage • Adressierung über Hardware-Loadbalancer • Healthcheck Container erlauben kontrolliertes Entfernen eines Standorts
  • 31. Seite 31 • Identische Cluster für Dev/Test und Produktion • Produktion aktiv-aktiv auf 2 Standorten • 2 unabhängige DC/OS Installationen in Produktion • SysArch DC/OS in der BA - Produktion aktiv-aktiv DC/OS-Cluster Thf DC/OS-Cluster Vdt
  • 32. Seite 32 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
  • 33. Seite 33 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!
  • 34. Seite 34 Mesosphere DC/OS - aus der Stratosphäre
  • 35. Seite 35 Apache Mesos - Ressourcen-Management und Ressourcen-Isolation ● offene Standards, herstellerunabhängig ● flexibel, modular, kein Lock-In ● erweiterbar für zukünftige Entwicklungen ● robust, seit 2011 im Produktionsbetrieb Container Network - CNI Container Storage - CSI Container Runtime - OCI
  • 36. Seite 36 Apache Mesos - Architektur
  • 37. Seite 37 Service Orchestrierung von Applikationen mit DC/OS Marathon http://container.webapps.idst.ibaintern.de Beispiel für eine Continuous Delivery Pipeline auf Basis von DC/OS, Marathon, Docker und Jenkins vollständige Abstraktion der Infrastruktur vom Entwickler PUT app.json
  • 44. Seite 44 Microservices einer Vertikale in DC/OS
  • 46. Seite 46 Frameworks: Produktspezifisches 2-level scheduling mit Mesos Frameworks für stateful Services Scheduler Cassandra Mesos Master Zookeeper Quorum Standby Master Standby Master Scheduler Kafka Scheduler Marathon Host1 Mesos Agent UCR Container Containerstateless Container Kafka Cassandra = Framework Marathon = Framework Cassandra = Framework Kafka Host2 Mesos Agent UCR Container Containerstateless Container Kafka Cassandra Host3 Mesos Agent UCR Container Containerstateless Container Kafka Cassandra Docker Registry DC/OS Catalogue Plattformprodukte Applikationen
  • 47. Seite 47 Automatisierter Betrieb von Plattformprodukten mit DC/OS Frameworks • Automatisierung betrieblicher Tasks für geclusterte datenhaltende Services wie Elasticsearch, Cassandra, Kafka... • Provisionierung / Erweiterung eines Clusters • Konfiguration einzelner Clustermember • Upgrade, Wartung, Tasks ohne Downtime • Fail-Over (Task, Node, RZ) ohne Downtime • Integration dieser Produkte in DC/OS • Security (Authentifizierung, Verschlüsselung) • Netzwerk, Storage • CLI, UI, Monitoring, Logging • Software-Repository, Konfigurations- management
  • 48. Seite 48 Automatisierte Verteilung von Anwendungen in einem generischen Hardware Cluster pets vs. cattle Loadbalancer Webserver AppServer DB Messaging DC/OStraditionelle IT
  • 49. Seite 49 DC/OS Catalogue (Private Universe)
  • 50. Seite 50 Security - einige Organisationen benötigen TLS im Cluster ... obwohl der Netzverkehr die Backplane nie verlässt...
  • 51. Seite 51 Konfigurationsmanagement - Secrets und Zertifikate • sichere Ablage von Secrets und Zertifikaten in einem Secret Store • rollenbasierter Zugriff • ermöglicht verschlüsselte Kommunikation innerhalb des Clusters (TLS)
  • 52. Seite 52 Sicherheit - Benutzerverwaltung, Rechte und Rollen • Benutzerverwaltung, Rollen- und Rechteverwaltung, AD-Integration • Integration von Plattformprodukten wie Kafka und Cassandra • eigene CA mit Möglichkeit zur Verwendung eigener Zertifikate
  • 53. Seite 53 Monitoring und Logging • einheitliches Monitoring aller Applikationen UND Plattformprodukte mit Hilfe von DC/OS Metrics und DC/OS Logging • Sammeln aller Metriken und Logs und Übertragung in ELK-Stack • Dashboards können von Entwicklern nach Bedarf selbst erstellt werden
  • 54. Seite 54 Standards für Container-Plattform Private Container Registry Base Images app.json Host 1 Host x local volumes local volumes bridged network http://con-sint.webapp.idst.ibaintern.de/apok/dev/contentsuche from push pull CD Pipeline Container-Format Plattformprodukte Healthchecks RHEL7.4
  • 55. Seite 55 Java und LINUX Container die JVM ist -aktuell- nicht container-aware!
  • 56. Seite 56 LINUX Container: namespaces vs. cgroups namespaces dienen der Isolation control groups verwalten Ressourcen pid (Prozesse) cpu (CPU Shares!) net (Netzwerk Interface, Routing) cpuset (Zuweisen Prozess auf CPU) ipc (System V Prozesskommunikation) memory (RAM inkl. Swap) mnt (mount points, Filesysteme) blkio (Begrenzung read / writes) uts (hostname) devices user (uids) net_cls, net_prio (Netzwerkdurchsatz) • namespaces = begrenzen, was man benutzt • cgroups = begrenzen, wieviel man benutzt
  • 57. Seite 57 • CPU Shares (Anteil an der CPU-Zeit aller Kerne eines Servers) • CPU Sets (hier nicht relevant!) • Priorisierung der verfügbaren CPU-Zeit über alle Kerne eines Hosts • Default (komplette CPU-Zeit): 1024 pro Kern • sudo cgcreate –g cpu:tralala • sudo cgset –r cpu.shares=768 tralala • → Reservierung auf 75% der insgesamt verfügbaren CPU-Zeit bei einem Kern • Freie CPU-cycle werden an andere cgroups gegeben! • Limitierung erfolgt erst, wenn keine CPU-Ressourcen über dem Limit verfügbar • CPU shares geben also eine Garantie mindestens den angegebenen Anteil an CPU-Zeit zu erhalten d.h. eher eine Reservierung als ein Limit • CFS (Completely Fair Scheduler) = harte Limitierung der CPU-Shares cgroups: CPU
  • 58. Seite 58 Java im Container - CPU Probleme • Bis JDK9 ist die JVM nicht container-aware, sie wird auf Basis des Hosts initialisiert • verfügbare CPU: JDK 7/8 : Ressourcen über sysconf • sysconf(_SC_NRPROCESSORS_ONLN); • → Runtime.getRuntime().availableProcessors == 32 • Berechnung der verfügbaren Threads für GC, JIT, etc. erfolgt auf dieser Basis • Langsamer Startup bei Verwendung von CFS • Erhöhung der Reservierung notwendig • Trick: Pod mit einem sleep(60) Container deployen, der die Reservierung so eine Minute lang erhöht • Empfehlung für typische Java Applikationen (RAM-lastig): Nutzung von CPU shares ohne CFS, d.h. weiche Limits • hoher CPU Verbrauch von Java Applikationen ist oft ein gc-Problem...
  • 59. Seite 59 cgroups: Memory • Jede cgroup kann harte oder weiche Limits für Memory erhalten • unter Mesos / Docker: Für Hauptspeicher immer harte Limits • Überschreitung → Swap → OOM killer • Problem: Swap, Default cgroups = 2 * mem → zu hoch! • Workaround: Übergabe memory-swap = mem als Parameter an docker-engine • Log: • Empfehlung: Swapping an den Mesos Hosts ausschalten! ... mem.cpp:625] OOM notifier is triggered for container tec32_healthcheck.9d17bc84-0a4c-11e7-a081-70b3d5800003 … mem.cpp: 644] OOM detected for container tec32_healthcheck.9d17bc84-0a4c-11e7-a081-70b3d5800003 … mem.cpp: 685] Memory limit exceeded: Requested: 2048MB Maximum used: 2048MB
  • 60. Seite 60 Java im Container - CPU Probleme • Bis JDK9 ist die JVM nicht container-aware, sie wird auf Basis des Hosts initialisiert • verfügbares RAM JDK 7/8 : typischerweise ¼ des RAMs des Hosts • Angabe von -Xmx zur Begrenzung des Heaps zwingend • Startup beschleunigen durch -Xms = -Xmx • Erhöhung RAM löst meist schon gc-Probleme • Problem: seit JDK8 laufen große Teile der JVM außerhalb des Heaps • mind. 300 MB + Java Heap, bei Produkten wie Cassandra, Kafka, Elasticsearch, Lucene Page Cache einkalkulieren!
  • 61. Seite 61 Bei der Dimensionierung des Container-RAMs darf nicht nur der Java-Heap berücksichtigt werden OS-Tools (RHEL) JRE8 Code Cache für JIT JRE8 Eden Old Space Meta Space NIO -Xms, -Xmx -XX:MaxMetaspaceSize ~96M ~256M ~60M Direct Buffers I/OOS Page Cache Threads 1M pro Thread bei 64Bit JVM Heap Konstant Variabel
  • 62. Seite 62 Memory: Lessons Learned - Thanks for the RAM!
  • 63. Seite 63 Enter JDK10 - alles wird gut? erkennt cpusets und cpushares Annahmen bzgl. RAM sind naiv, -Xms und -Xmx weiterhin notwendig Java benötigt weiterhin viel Memory im Vergleich zu anderen Sprachen
  • 64. Seite 64 Lessons Learned nach einem Jahr DC/OS: • Produktionsbetrieb mit LINUX-Containern auf DC/OS ist auch für eine klassische Enterprise-IT Organisation machbar • zuverlässig, keinerlei “on-call-events” in Produktion • schnelle MTTR (mean time to recovery) bei Infrastrukturfehlern • vollständige Automation des Betriebs von modernen Plattformprodukten (Cassandra, Kafka, Elasticsearch…) • große Vorteile von Containern gegenüber VMs • Ressourcen-Pool für Dev/Test hat sich bewährt • einheitlicher Betrieb von sehr heterogenen Produkten • Applikationen, WebServer, Proxies, Piwik, Invaris, Cassandra, Kafka, Elasticsearch, Fremdprodukte, … • ...