SlideShare ist ein Scribd-Unternehmen logo
1 von 36
Downloaden Sie, um offline zu lesen
1
INFINISPAN / JDG
Schneller Zugriff und / oder Datenkonsistenz im Cluster
11.02.2016
2
Über mich
@RedHat seit 2011
Senior Software Maintenance Engineer
Support Product Lead JBoss Data Grid
EAP Wildfly Clustering / EJB
JDG Infinispan
JAVA seit 1996
JBoss seit 2000
Java Magazin Autor
Wolf-Dieter Fink
3 . 1
ÜBERBLICK JDG | INFINISPANÜBERBLICK JDG | INFINISPAN
Infinipan
Community Project
Kein professioneller Support
Schnellere Release
Nutze JGroups für Kommuniktion
http://infinispan.org
JDG
Basiert auf Infinispan
Professioneller Support @redhat.com
Langsamere Release Zyklen
Längerer Maintenance
https://access.redhat.com/support/policy/updates/jboss_notes/
3 . 2
ÜBERBLICK JDG | INFINISPANÜBERBLICK JDG | INFINISPAN
Key Value Store ( NoSQL )
'HashMap' mit weiteren Features
Distributed oder Replicated im Cluster
Automatische Eviction und Expiration
Querying; continues Queries
Listeners / Events
Near Caching für HotRod clients
Distributed Invocation
Kommende Änderungen
Map/Reduce (JDG 6.x und Infinispan 7)
ersetzt durch 'Distributed' Java8 Streams (ISPN 8+)
Server seitige scripts
3 . 3
ÜBERBLICK JDG | INFINISPANÜBERBLICK JDG | INFINISPAN
Embedded (Library) Mode
Cache in der gleichen JVM wie die Anwendung
Schneller in-Memory Zugriff
Unterstützung von 2PC Transaktionen
Configuration in der Anwendung mittels XML oder Programatisch
JCache interface verfügbar
3 . 4
ÜBERBLICK JDG | INFINISPANÜBERBLICK JDG | INFINISPAN
Client / Server Mode
Komplett getrennt von der Anwendung
Eigene Konfiguration über XML oder Management Interface
Hot Rod Client
Intelligenter Zugriff über ConsistentHash
Java C++ C# (next node.js)
Rest
Memcache
4
PROBLEMATIK IM BETRIEBPROBLEMATIK IM BETRIEB
Änderung der Node Anzahl
Start (Join)
Stop (Leave)
State Transfer
updates im Cluster
Garbage Collection
Network
5 . 1
Verhalten bei geplanter Änderung
Cluster Coordinator
Startet rebalancing für Distributed Caches
Key's werden anhand des ConsistentHash und numOwner
neu (Segmentweise) verteilt
Protokolliert Start und Ende des Rebalancing
Setzt neue "Stabile" Cluster-View
Node
Informiert den Cluster-Coordinator
Speichert oder läd Daten wenn PersistentStore vorhanden
5 . 2
Probleme bei geplanten (re)starts
Verzögerte Response beim Zugriff
Daten werden ggf. von anderen Nodes angefordert
Zu viele Daten im Cache
Timeout für initialen StateTransfer
Massive Full GC's
Netzwerk Latenz oder Überlastung
6
Problematiken zur Laufzeit
Garbage Collection dauert länger als
eingestellte JGroups failure detection
Split-Brain -> Rebalancing
Nicht genügend Threads um die
Kommunikation sicherzustellen
Timeouts oder lange Laufzeiten beim Sync/Async
Im Sync-Mode schlägt der Update fehl
Im Async-Mode entstehen Inkonsistenzen da nicht
wiederholt wird
Netzwerk Ausfall
Split-Brain - Rebalancing
7 . 1
Aktuelle Java VM verwenden
JVM default Heap passt nicht!
-Xms == -Xmx (kein adaptives sizing)
Heap vergrößern da Cache-Daten länger leben
Old Genetation für Daten im Cache
Empfehlung max 50-60% Nutzung
Immer GC logging einschalten und prüfen
Large pages -XX:+UseLargePages
Abhilfen und Lösungen
1. Garbage Collection
7 . 2
-XX:NewSize -> 500M...2GB
(NewGen klein halten abhängig von der Anwendung)
CMS Balance problem
Klein -> möglicherweise weniger Durchsatz
Groß -> Probleme durch verschieben temporärer Daten -> Old
Vergrößern des Survivor space -XX:SurvivorRatio=16 (32)
CMS Probleme (parallel CMS failures)
früher starten (parallel)
-XX:CMSInitiatingOccupancyFraction=60 -XX:+UseCMSInitiatingOccupancyOnly
Aktivieren PermGen collection
-XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled
Abhilfen und Lösungen
1. Garbage Collection (CMS)
7 . 3
Festlegen der Pausenzeiten (als Startwert) –XX:MaxGCPauseMillis
500ms für 32GB; 1000ms für 64GB
Größer >> Besserer Durchsatz
Probleme mit FullGC oder "to space overflow/exhausted"
Größere MaxGCPauseMillis wählen
HEAP vergrößern
Ändern von -XX:InitiatingHeapOccupancyPercent (default 45)
Nicht kleiner als der Prozentsatz von Daten!
Vergrößern von -XXConcGCThreads
Aktivieren PermGen collection
-XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled
Abhilfen und Lösungen
1. Garbage Collection (G1)
7 . 4
Abhilfen und Lösungen
UDP Multicast
JGroups tests (in jgroups.jar enthalten)
MCastSender, mehrere MCastReceiver
ClusterTest
IPv4 IPv6 missmatch
explizit -Djava.net.preferIPv4Stack=true||false
Bind Adresse setzen (nicht 0.0.0.0)
JGroups TCP Stack ist nicht für große Cluster geeignet (<10)
!!
2. Netzwerk
7 . 5
Abhilfen und Lösungen
REPL ist nicht für große Cluster geeignet
Empfehlung max. 10 Nodes
JGroups OOB Threads werden genutzt für StateTransfer
Bis JDG 6.3 oder Infinispan7
JGroups ClusterMessages gehen verloren (Heartbeat,
Alive)
Überlastung führt zu message drop
3. Konfiguration
8
CAP Theorem ( )wikipedia
Consistency
C
A
Availablility
P
Partition tolerance
Alle Replikate werden
konsistent verändert
Anfragen werden stets
beantwortet
Bei Teilausfall oder Partitionierung
arbeitet das System weiter
9
Split Brain
Split
Rebalance für jede Partition
Einträge können in jeder beliebigen Partition
vorgenommen werden
Unterschiedliche Updates in verschiedenen Partitions
Verhalten bis JDG6.3 Infinispan 7.0
Merge
Neue PrimaryOwner werden bestimmt, ohne Sync
Einträge auf Nodes die nicht Owner sind werden gelöscht!
Inkonsistenz möglich
1 ... <numOwner> Varianten
10
Split Brain
Split
Nicht mehr verfügbare Nodes werden aus dem CH gelöscht
Kein Unterschied ob Shutdown oder Crash
Zwei oder mehr Partitionen können die Einträge unterschiedlich Ändern
Änderungen die vorgenommen wurden bevor der Split erkannt wurde werden
eventuell nur Teilweise ausgeführt
Verhalten ab JDG6.4 Infinispan 7.1
Merge
Partition mit der höchsten ID gewinnt, alle anderen werden gelöscht!
Nach erzeugen eines neuen CH werden die Einträge wieder anhand von
numOwners verteilt
Datenverlust!
Keine Möglichkeit individuell Einträge zusammenzuführen
Unter Umständen hoher Traffic
11 . 1
Partition Handling
(ab JDG 6.4 Infinispan 7.1)
Eine Partition wird AVAILABLE wenn ...
Die Majorität der letzen "Stabilen View" enthalten ist
Weniger als numOwners die View verlassen haben
Es kann maximal nur eine geben!!
Wird pro Cache konfiguriert
Abhängig von der Anzahl der Nodes wird eine Partition
AVAILABLE oder DEGRADED im Falle eines Split
Eine Partition wird DEGRADED wenn ...
Alle Owner eines Segments die View verlassen
Nicht die Majorität der Nodes enthalten ist
11 . 2
Partition Handling
(ab JDG 6.4 Infinispan 7.1)
Die Zeitspanne zwischen physikalischem und logischem Split
hängt ab von JGroups timeouts (FD* protokoll)
Ein get() während dieser Zeit kann alte Werte lesen
Ein put() kann je nach Einstellung (async) teilweise ausgeführt
werden
Transaktionen in der Zeitspanne können auf manchen Nodes
committed worden sein
11 . 3
Partition Handling
(ab JDG 6.4 Infinispan 7.1)
Erzeugt einen neuen CH und startet einen StateTransfer
Nach erfolgtem StateTransfer ist die Partition die neue
"Stabile View"
Der Cache arbeitet wie gewohnt weiter
Eine Partition im Mode AVAILABLE
11 . 4
Partition Handling
(ab JDG 6.4 Infinispan 7.1)
Erzeugt KEINEN neuen CH
Startet KEINEN StateTransfer
get/put sind möglich wenn alle Owner eines Keys in dieser
Partition liegen
Das gilt auch für das Anlegen oder Löschen von Einträgen
Befinden sich nicht alle Owner in der Partition wird eine
AvailablilityException geworfen
(extends RuntimeException)
Eine Partition im Mode DEGRADED
11 . 5
Partition Handling
(ab JDG 6.4 Infinispan 7.1)
Merge
AVAILABLE <--> DEGRAGED
DEGRADED wird gelöscht
Koordinator started re-hash
Wird neue "Stabile View"
DEGRADED <--> DEGRADED
Summe beider Partitionen erfüllt nicht die Bedingung für AVAILABLE
Nichts, immer noch DEGRADED
Summe beider Partitionen erfüllt die Bedingung für AVAILABLE
Koordinator started re-hash
Wird AVAILABLE und neue "Stabile View"
12 . 1
Partition Handling
Beispiel 3 Nodes 2 Owner
Cluster im Normalzustand
12 . 2
Partition Handling
Beispiel 3 Nodes 2 Owner
Cluster nach physikalischem Split
12 . 3
Partition Handling
Beispiel 3 Nodes 2 Owner
Cluster nach logischem Split
Partition 1
full access
Partition 2
no access
always AvailabilityException
join clear the partition
Embedded
Nur Anwendungen in N1/N2
funktionieren
Client/Server (remote access)
Funktional
Seltener Fall das der View
update nur N3 enthält
13 . 1
Partition Handling
Beispiel 4 Nodes 2 Owner
Cluster im Normalzustand
13 . 2
Partition Handling
Beispiel 4 Nodes 2 Owner
Cluster nach physikalischem Split
13 . 3
Partition Handling
Beispiel 4 Nodes 2 Owner
Cluster nach logischem Split
Beide Partitionen
Zugriff auf 'grün'
AvailabilityException 'rot'
Embedded
nur lokaler Zugriff
entweder K1 K4
oder K5
Client/Server (remote access)
Oft beide Partitions enthalten
Zugriff auf K1 K4 K5
14
Partition Handling
Was ist mit einem replizierenden Cache ?
Was passiert wenn ein REPL cache in 2/2 nodes getrennt wird?
Alle sind DEGRADED es ist kein key mehr erreichbar!
Was ist wenn ein REPL cache in 1/3 nodes getrennt wird?
Die einzelne Node is DEGRADED und kein Key erreichbar!
Die anderen Nodes führen einen ReHash durch und sind komplett
erreichbar!
15 . 1
Partition Handling - Fazit
Partition Handling ist keine Ideale Lösung für alle Anwendungen
GC und Environment Tuning ist unerläßlich
Anwendung muss ggf. für PH angepasst werden um auf
AvailabilityExceptions zu reagieren
Nachteile im embedded Mode da weniger Einträge zu erreichen
sind als im Client/Server Modus
PH verfügbar ab JDG 6.4 | Infinispan 7.1
Weitere Verbesserungen ab JDG 6.5 | Infinispan 8
15 . 2
Partition Handling - Desaster
Partieller Totalausfall von Nodes nach einem
Split
Werden Nodes neu gestarted in dem Status werden
diese als neu erkannt und bleiben DEGRADED
Die nicht mehr vorhandene Instanz bleibt im CH
eingetragen
In diese Situation muss ein administrativer Eingriff
manuell erfolgen
15 . 3
Partition Handling - Hilfreiches
org.infinispan.partitionhandling.impl.PartitionHandlingManagerImpl
ERROR -> abgelehnten Zugriff (nur target)
DEBUG -> Mode Änderungen per Cache
TRACE -> Zugriff und Status per Key
Manuelle Änderung des Cache Mode
JMX
jboss.infinispan.Cache.<name>.”clustered”.Cache.Attributes.cacheAvailability
CLI
/subsystem=infinispan/cache-container=clustered/distributed-cache=default:write-
attribute(name=cache-availability, value=AVAILABLE)
Achtung! Inkonsistente Änderungen
(z.B. zwei AVAILABLE partitions)
Führen zu unerwartetem Verhalten beim Merge
16
Partition Handling
Dokumentation
Java Magazin 9/2015
JDG Administration Guide (6.5)
31. Handling Network Partitions
17
Partition Handling - Ausblick
Verbesserter Merge
Wiedererkennung von Nodes nach Restart
Verschiedene Modi für Partition Handling
Read-Only
Callback API für Merge customizing (PRODMGT-
1453)
ISPN-5290
ISPN-6187
ISPN-5511
Zükünftige Verbesserungen
18
Vielen Dank !
Noch Fragen?

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (7)

Macit Kandemir, Flexible Datenbank-Anwendungen mit MongoDB
Macit Kandemir, Flexible Datenbank-Anwendungen mit MongoDBMacit Kandemir, Flexible Datenbank-Anwendungen mit MongoDB
Macit Kandemir, Flexible Datenbank-Anwendungen mit MongoDB
 
Leichtgewichtige Microservices mit Java EE 7
Leichtgewichtige Microservices mit Java EE 7Leichtgewichtige Microservices mit Java EE 7
Leichtgewichtige Microservices mit Java EE 7
 
Speeding up Java Persistence
Speeding up Java PersistenceSpeeding up Java Persistence
Speeding up Java Persistence
 
WildFly als Plattform moderner Enterprise-Anwendungen
WildFly als Plattform moderner Enterprise-AnwendungenWildFly als Plattform moderner Enterprise-Anwendungen
WildFly als Plattform moderner Enterprise-Anwendungen
 
Java EE 7 - Enterprise-Anwendungen ohne Ballast
Java EE 7 - Enterprise-Anwendungen ohne BallastJava EE 7 - Enterprise-Anwendungen ohne Ballast
Java EE 7 - Enterprise-Anwendungen ohne Ballast
 
AngularJS
AngularJSAngularJS
AngularJS
 
Wie viel Client braucht das Web?JSF, Vaadin und AngularJS im Vergleich
Wie viel Client braucht das Web?JSF, Vaadin und AngularJS im VergleichWie viel Client braucht das Web?JSF, Vaadin und AngularJS im Vergleich
Wie viel Client braucht das Web?JSF, Vaadin und AngularJS im Vergleich
 

Ähnlich wie Infinispan / JBoss Data Grid - Schneller Zugriff auf große Datenmengen im Cluster

P-I-DO_Automatisierung_Backup_Switches.pdf
P-I-DO_Automatisierung_Backup_Switches.pdfP-I-DO_Automatisierung_Backup_Switches.pdf
P-I-DO_Automatisierung_Backup_Switches.pdf
jnxexo
 

Ähnlich wie Infinispan / JBoss Data Grid - Schneller Zugriff auf große Datenmengen im Cluster (20)

MySQL Hochverfügbarkeitslösungen
MySQL HochverfügbarkeitslösungenMySQL Hochverfügbarkeitslösungen
MySQL Hochverfügbarkeitslösungen
 
MySQL HA and Security
MySQL HA and SecurityMySQL HA and Security
MySQL HA and Security
 
Virtualized Exadata - the first 4 "productive" years...
Virtualized Exadata - the first 4 "productive" years...Virtualized Exadata - the first 4 "productive" years...
Virtualized Exadata - the first 4 "productive" years...
 
JBoss AS / EAP Clustering
JBoss AS / EAP  ClusteringJBoss AS / EAP  Clustering
JBoss AS / EAP Clustering
 
Mercurial
MercurialMercurial
Mercurial
 
P-I-DO_Automatisierung_Backup_Switches.pdf
P-I-DO_Automatisierung_Backup_Switches.pdfP-I-DO_Automatisierung_Backup_Switches.pdf
P-I-DO_Automatisierung_Backup_Switches.pdf
 
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
 
Git vs SVN - Eine vergleichende Einführung
Git vs SVN - Eine vergleichende EinführungGit vs SVN - Eine vergleichende Einführung
Git vs SVN - Eine vergleichende Einführung
 
Exchange Server 2019 MetaCache Database und BigFunnel
Exchange Server 2019 MetaCache Database und BigFunnelExchange Server 2019 MetaCache Database und BigFunnel
Exchange Server 2019 MetaCache Database und BigFunnel
 
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
 
Funktionale Reaktive Programmierung mit Sodium
Funktionale Reaktive Programmierung mit SodiumFunktionale Reaktive Programmierung mit Sodium
Funktionale Reaktive Programmierung mit Sodium
 
PostgreSQL News
PostgreSQL NewsPostgreSQL News
PostgreSQL News
 
Big Data Community Webinar vom 16. Mai 2019: Oracle NoSQL DB im Überblick
Big Data Community Webinar vom 16. Mai 2019: Oracle NoSQL DB im ÜberblickBig Data Community Webinar vom 16. Mai 2019: Oracle NoSQL DB im Überblick
Big Data Community Webinar vom 16. Mai 2019: Oracle NoSQL DB im Überblick
 
9. Direct Access Workshop - Marc Eggenberger
9. Direct Access Workshop - Marc Eggenberger9. Direct Access Workshop - Marc Eggenberger
9. Direct Access Workshop - Marc Eggenberger
 
Sql Server Grundlagen für Sharepoint Administratoren
Sql Server Grundlagen für Sharepoint AdministratorenSql Server Grundlagen für Sharepoint Administratoren
Sql Server Grundlagen für Sharepoint Administratoren
 
Sql Server GrundlagenfüR Share Point Admins
Sql Server GrundlagenfüR Share Point AdminsSql Server GrundlagenfüR Share Point Admins
Sql Server GrundlagenfüR Share Point Admins
 
JavaAktuell - Skalierbare Cluster-Topologien mit dem JBoss AS 7
JavaAktuell - Skalierbare Cluster-Topologien mit dem JBoss AS 7JavaAktuell - Skalierbare Cluster-Topologien mit dem JBoss AS 7
JavaAktuell - Skalierbare Cluster-Topologien mit dem JBoss AS 7
 
Monitoring und Profiling von Java-Anwendungen
Monitoring und Profiling von Java-AnwendungenMonitoring und Profiling von Java-Anwendungen
Monitoring und Profiling von Java-Anwendungen
 
Roadshow Oracle Database 12c: News & Features
Roadshow Oracle Database 12c: News & FeaturesRoadshow Oracle Database 12c: News & Features
Roadshow Oracle Database 12c: News & Features
 

Infinispan / JBoss Data Grid - Schneller Zugriff auf große Datenmengen im Cluster

  • 1. 1 INFINISPAN / JDG Schneller Zugriff und / oder Datenkonsistenz im Cluster 11.02.2016
  • 2. 2 Über mich @RedHat seit 2011 Senior Software Maintenance Engineer Support Product Lead JBoss Data Grid EAP Wildfly Clustering / EJB JDG Infinispan JAVA seit 1996 JBoss seit 2000 Java Magazin Autor Wolf-Dieter Fink
  • 3. 3 . 1 ÜBERBLICK JDG | INFINISPANÜBERBLICK JDG | INFINISPAN Infinipan Community Project Kein professioneller Support Schnellere Release Nutze JGroups für Kommuniktion http://infinispan.org JDG Basiert auf Infinispan Professioneller Support @redhat.com Langsamere Release Zyklen Längerer Maintenance https://access.redhat.com/support/policy/updates/jboss_notes/
  • 4. 3 . 2 ÜBERBLICK JDG | INFINISPANÜBERBLICK JDG | INFINISPAN Key Value Store ( NoSQL ) 'HashMap' mit weiteren Features Distributed oder Replicated im Cluster Automatische Eviction und Expiration Querying; continues Queries Listeners / Events Near Caching für HotRod clients Distributed Invocation Kommende Änderungen Map/Reduce (JDG 6.x und Infinispan 7) ersetzt durch 'Distributed' Java8 Streams (ISPN 8+) Server seitige scripts
  • 5. 3 . 3 ÜBERBLICK JDG | INFINISPANÜBERBLICK JDG | INFINISPAN Embedded (Library) Mode Cache in der gleichen JVM wie die Anwendung Schneller in-Memory Zugriff Unterstützung von 2PC Transaktionen Configuration in der Anwendung mittels XML oder Programatisch JCache interface verfügbar
  • 6. 3 . 4 ÜBERBLICK JDG | INFINISPANÜBERBLICK JDG | INFINISPAN Client / Server Mode Komplett getrennt von der Anwendung Eigene Konfiguration über XML oder Management Interface Hot Rod Client Intelligenter Zugriff über ConsistentHash Java C++ C# (next node.js) Rest Memcache
  • 7. 4 PROBLEMATIK IM BETRIEBPROBLEMATIK IM BETRIEB Änderung der Node Anzahl Start (Join) Stop (Leave) State Transfer updates im Cluster Garbage Collection Network
  • 8. 5 . 1 Verhalten bei geplanter Änderung Cluster Coordinator Startet rebalancing für Distributed Caches Key's werden anhand des ConsistentHash und numOwner neu (Segmentweise) verteilt Protokolliert Start und Ende des Rebalancing Setzt neue "Stabile" Cluster-View Node Informiert den Cluster-Coordinator Speichert oder läd Daten wenn PersistentStore vorhanden
  • 9. 5 . 2 Probleme bei geplanten (re)starts Verzögerte Response beim Zugriff Daten werden ggf. von anderen Nodes angefordert Zu viele Daten im Cache Timeout für initialen StateTransfer Massive Full GC's Netzwerk Latenz oder Überlastung
  • 10. 6 Problematiken zur Laufzeit Garbage Collection dauert länger als eingestellte JGroups failure detection Split-Brain -> Rebalancing Nicht genügend Threads um die Kommunikation sicherzustellen Timeouts oder lange Laufzeiten beim Sync/Async Im Sync-Mode schlägt der Update fehl Im Async-Mode entstehen Inkonsistenzen da nicht wiederholt wird Netzwerk Ausfall Split-Brain - Rebalancing
  • 11. 7 . 1 Aktuelle Java VM verwenden JVM default Heap passt nicht! -Xms == -Xmx (kein adaptives sizing) Heap vergrößern da Cache-Daten länger leben Old Genetation für Daten im Cache Empfehlung max 50-60% Nutzung Immer GC logging einschalten und prüfen Large pages -XX:+UseLargePages Abhilfen und Lösungen 1. Garbage Collection
  • 12. 7 . 2 -XX:NewSize -> 500M...2GB (NewGen klein halten abhängig von der Anwendung) CMS Balance problem Klein -> möglicherweise weniger Durchsatz Groß -> Probleme durch verschieben temporärer Daten -> Old Vergrößern des Survivor space -XX:SurvivorRatio=16 (32) CMS Probleme (parallel CMS failures) früher starten (parallel) -XX:CMSInitiatingOccupancyFraction=60 -XX:+UseCMSInitiatingOccupancyOnly Aktivieren PermGen collection -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled Abhilfen und Lösungen 1. Garbage Collection (CMS)
  • 13. 7 . 3 Festlegen der Pausenzeiten (als Startwert) –XX:MaxGCPauseMillis 500ms für 32GB; 1000ms für 64GB Größer >> Besserer Durchsatz Probleme mit FullGC oder "to space overflow/exhausted" Größere MaxGCPauseMillis wählen HEAP vergrößern Ändern von -XX:InitiatingHeapOccupancyPercent (default 45) Nicht kleiner als der Prozentsatz von Daten! Vergrößern von -XXConcGCThreads Aktivieren PermGen collection -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled Abhilfen und Lösungen 1. Garbage Collection (G1)
  • 14. 7 . 4 Abhilfen und Lösungen UDP Multicast JGroups tests (in jgroups.jar enthalten) MCastSender, mehrere MCastReceiver ClusterTest IPv4 IPv6 missmatch explizit -Djava.net.preferIPv4Stack=true||false Bind Adresse setzen (nicht 0.0.0.0) JGroups TCP Stack ist nicht für große Cluster geeignet (<10) !! 2. Netzwerk
  • 15. 7 . 5 Abhilfen und Lösungen REPL ist nicht für große Cluster geeignet Empfehlung max. 10 Nodes JGroups OOB Threads werden genutzt für StateTransfer Bis JDG 6.3 oder Infinispan7 JGroups ClusterMessages gehen verloren (Heartbeat, Alive) Überlastung führt zu message drop 3. Konfiguration
  • 16. 8 CAP Theorem ( )wikipedia Consistency C A Availablility P Partition tolerance Alle Replikate werden konsistent verändert Anfragen werden stets beantwortet Bei Teilausfall oder Partitionierung arbeitet das System weiter
  • 17. 9 Split Brain Split Rebalance für jede Partition Einträge können in jeder beliebigen Partition vorgenommen werden Unterschiedliche Updates in verschiedenen Partitions Verhalten bis JDG6.3 Infinispan 7.0 Merge Neue PrimaryOwner werden bestimmt, ohne Sync Einträge auf Nodes die nicht Owner sind werden gelöscht! Inkonsistenz möglich 1 ... <numOwner> Varianten
  • 18. 10 Split Brain Split Nicht mehr verfügbare Nodes werden aus dem CH gelöscht Kein Unterschied ob Shutdown oder Crash Zwei oder mehr Partitionen können die Einträge unterschiedlich Ändern Änderungen die vorgenommen wurden bevor der Split erkannt wurde werden eventuell nur Teilweise ausgeführt Verhalten ab JDG6.4 Infinispan 7.1 Merge Partition mit der höchsten ID gewinnt, alle anderen werden gelöscht! Nach erzeugen eines neuen CH werden die Einträge wieder anhand von numOwners verteilt Datenverlust! Keine Möglichkeit individuell Einträge zusammenzuführen Unter Umständen hoher Traffic
  • 19. 11 . 1 Partition Handling (ab JDG 6.4 Infinispan 7.1) Eine Partition wird AVAILABLE wenn ... Die Majorität der letzen "Stabilen View" enthalten ist Weniger als numOwners die View verlassen haben Es kann maximal nur eine geben!! Wird pro Cache konfiguriert Abhängig von der Anzahl der Nodes wird eine Partition AVAILABLE oder DEGRADED im Falle eines Split Eine Partition wird DEGRADED wenn ... Alle Owner eines Segments die View verlassen Nicht die Majorität der Nodes enthalten ist
  • 20. 11 . 2 Partition Handling (ab JDG 6.4 Infinispan 7.1) Die Zeitspanne zwischen physikalischem und logischem Split hängt ab von JGroups timeouts (FD* protokoll) Ein get() während dieser Zeit kann alte Werte lesen Ein put() kann je nach Einstellung (async) teilweise ausgeführt werden Transaktionen in der Zeitspanne können auf manchen Nodes committed worden sein
  • 21. 11 . 3 Partition Handling (ab JDG 6.4 Infinispan 7.1) Erzeugt einen neuen CH und startet einen StateTransfer Nach erfolgtem StateTransfer ist die Partition die neue "Stabile View" Der Cache arbeitet wie gewohnt weiter Eine Partition im Mode AVAILABLE
  • 22. 11 . 4 Partition Handling (ab JDG 6.4 Infinispan 7.1) Erzeugt KEINEN neuen CH Startet KEINEN StateTransfer get/put sind möglich wenn alle Owner eines Keys in dieser Partition liegen Das gilt auch für das Anlegen oder Löschen von Einträgen Befinden sich nicht alle Owner in der Partition wird eine AvailablilityException geworfen (extends RuntimeException) Eine Partition im Mode DEGRADED
  • 23. 11 . 5 Partition Handling (ab JDG 6.4 Infinispan 7.1) Merge AVAILABLE <--> DEGRAGED DEGRADED wird gelöscht Koordinator started re-hash Wird neue "Stabile View" DEGRADED <--> DEGRADED Summe beider Partitionen erfüllt nicht die Bedingung für AVAILABLE Nichts, immer noch DEGRADED Summe beider Partitionen erfüllt die Bedingung für AVAILABLE Koordinator started re-hash Wird AVAILABLE und neue "Stabile View"
  • 24. 12 . 1 Partition Handling Beispiel 3 Nodes 2 Owner Cluster im Normalzustand
  • 25. 12 . 2 Partition Handling Beispiel 3 Nodes 2 Owner Cluster nach physikalischem Split
  • 26. 12 . 3 Partition Handling Beispiel 3 Nodes 2 Owner Cluster nach logischem Split Partition 1 full access Partition 2 no access always AvailabilityException join clear the partition Embedded Nur Anwendungen in N1/N2 funktionieren Client/Server (remote access) Funktional Seltener Fall das der View update nur N3 enthält
  • 27. 13 . 1 Partition Handling Beispiel 4 Nodes 2 Owner Cluster im Normalzustand
  • 28. 13 . 2 Partition Handling Beispiel 4 Nodes 2 Owner Cluster nach physikalischem Split
  • 29. 13 . 3 Partition Handling Beispiel 4 Nodes 2 Owner Cluster nach logischem Split Beide Partitionen Zugriff auf 'grün' AvailabilityException 'rot' Embedded nur lokaler Zugriff entweder K1 K4 oder K5 Client/Server (remote access) Oft beide Partitions enthalten Zugriff auf K1 K4 K5
  • 30. 14 Partition Handling Was ist mit einem replizierenden Cache ? Was passiert wenn ein REPL cache in 2/2 nodes getrennt wird? Alle sind DEGRADED es ist kein key mehr erreichbar! Was ist wenn ein REPL cache in 1/3 nodes getrennt wird? Die einzelne Node is DEGRADED und kein Key erreichbar! Die anderen Nodes führen einen ReHash durch und sind komplett erreichbar!
  • 31. 15 . 1 Partition Handling - Fazit Partition Handling ist keine Ideale Lösung für alle Anwendungen GC und Environment Tuning ist unerläßlich Anwendung muss ggf. für PH angepasst werden um auf AvailabilityExceptions zu reagieren Nachteile im embedded Mode da weniger Einträge zu erreichen sind als im Client/Server Modus PH verfügbar ab JDG 6.4 | Infinispan 7.1 Weitere Verbesserungen ab JDG 6.5 | Infinispan 8
  • 32. 15 . 2 Partition Handling - Desaster Partieller Totalausfall von Nodes nach einem Split Werden Nodes neu gestarted in dem Status werden diese als neu erkannt und bleiben DEGRADED Die nicht mehr vorhandene Instanz bleibt im CH eingetragen In diese Situation muss ein administrativer Eingriff manuell erfolgen
  • 33. 15 . 3 Partition Handling - Hilfreiches org.infinispan.partitionhandling.impl.PartitionHandlingManagerImpl ERROR -> abgelehnten Zugriff (nur target) DEBUG -> Mode Änderungen per Cache TRACE -> Zugriff und Status per Key Manuelle Änderung des Cache Mode JMX jboss.infinispan.Cache.<name>.”clustered”.Cache.Attributes.cacheAvailability CLI /subsystem=infinispan/cache-container=clustered/distributed-cache=default:write- attribute(name=cache-availability, value=AVAILABLE) Achtung! Inkonsistente Änderungen (z.B. zwei AVAILABLE partitions) Führen zu unerwartetem Verhalten beim Merge
  • 34. 16 Partition Handling Dokumentation Java Magazin 9/2015 JDG Administration Guide (6.5) 31. Handling Network Partitions
  • 35. 17 Partition Handling - Ausblick Verbesserter Merge Wiedererkennung von Nodes nach Restart Verschiedene Modi für Partition Handling Read-Only Callback API für Merge customizing (PRODMGT- 1453) ISPN-5290 ISPN-6187 ISPN-5511 Zükünftige Verbesserungen