0
Regarde les instances tomber
20 mai 2014
Vincent Beretti
Ippon Technologies © 2014
Sommaire
● Théorie
● MongoDB
● Cassandra
● Conclusion
Ippon Technologies © 2014
Objectifs
Objectifs de la présentation
● Comprendre les contraintes d’un système distribué
● Voi...
Ippon Technologies © 2014
Théorie
Ippon Technologies © 2014
Théorème CAP
Theoreme CAP
Conjecture décrite en 2000 par Eric Brewer de Berkeley. Il y
présente ...
Ippon Technologies © 2014
Théorème CAP
Un système distribué a au plus 2 des 3 propriétés énoncées
ci-dessus.
Ippon Technologies © 2014
Theorème CAP
A
C P
MongoDB
CassandraRDBMS
Ippon Technologies © 2014
MongoDB
Ippon Technologies © 2014
MongoDB
● Base orientée document
● Modèle asymétrique
○ 1 noeud primaire
○ n noeuds secondaires
...
Ippon Technologies © 2014
Bac à sable
● Docker
○ mongod
○ ssh
● REST App
○ spring boot
○ spring data mongoDB
● Gatling
Mon...
Ippon Technologies © 2014
Primary - KO
Et si le noeud primaire tombe ?
DEMO
Scénario
● 3 noeuds
● read & upsert en continu...
Ippon Technologies © 2014
Primary - KO
● Environ 5 secondes d’indisponibilité
● Nouveau noeud Primaire est disponible
● Éc...
Ippon Technologies © 2014
Primary - OK - Election
Secondary Secondary
Primary
Primary Secondary
Primary
Client
Client
hear...
Ippon Technologies © 2014
Primary - OK - Election
Critères d’élection
● ! hidden, ! arbitrer, priority !=0
● priority + ha...
Ippon Technologies © 2014
Primary - OK - Client Java
DefaultServer.java
this.stateNotifier = new ServerStateNotifier(serve...
Ippon Technologies © 2014
Primary + Secondary - KO
Et si le dernier noeud secondaire tombe ?
DEMO
Primary Secondary
Primar...
Ippon Technologies © 2014
Primary + Secondary - KO
Base totalement indisponible alors qu’il reste 1 noeud !
Ippon Technologies © 2014
Primary + Secondary - KO
Secondary Secondary
Primary
Primary Secondary
Primary
heartbeat
T
T+1
[...
Ippon Technologies © 2014
Primary - KO - ReadPreferences
Par défaut,
Si le primaire tombe
● perte des lectures et écriture...
Ippon Technologies © 2014
Primary - KO - ReadPreferences
ReadPreferences
Paramètre d’appel
● PRIMARY : default, cohérence ...
Ippon Technologies © 2014
Primary - KO - ReadPreferences
Et si le noeud primaire tombe ?
DEMO
Scénario
● 3 noeuds
● read &...
Ippon Technologies © 2014
Primary - KO - Primary Preferred
Reads
Writes
Ippon Technologies © 2014
Primary - KO - Secondary Preferred
Répartition de charge (au détriment de la cohérence)
Ippon Technologies © 2014
Morcellement
Morcellement
Partitionnement du réseau au sein du cluster
Cas déploiement multi-dat...
Ippon Technologies © 2014
Morcellement
Et si le cluster est morcelé ?
DEMO
Scénario
● 5 noeuds
● iptables Primary
172.17.0...
Ippon Technologies © 2014
Morcellement
IPTables sur noeuds 172.17.0.2 et 172.17.0.3
iptables -A INPUT -p ALL -s 172.17.0.4...
Ippon Technologies © 2014
Secondary
172.17.0.2
Secondary
172.17.0.3
Primary
172.17.0.4
Secondary
172.17.0.5
Secondary
172....
Ippon Technologies © 2014
Secondary
172.17.0.2
Secondary
172.17.0.3
Primary
172.17.0.4
Secondary
172.17.0.5
Secondary
172....
Ippon Technologies © 2014
Cassandra
Ippon Technologies © 2014
Cassandra
Cassandra
● Base orientée colonnes
● Modèle symétrique
○ n noeuds disponibles en lectu...
Ippon Technologies © 2014
Replication Factor
Nombre de noeuds sur lesquels une données va être répliquée.
A définir lors d...
Ippon Technologies © 2014
Bac à sable
● Docker
○ dsc-community
○ ssh
○ iptables
● REST App
○ spring boot
○ datastax java d...
Ippon Technologies © 2014
Noeud KO
Et si un noeud tombe ?
DEMO
Scénario
● 3 noeuds, RF=3
● read & upsert en continu
A
B C
Ippon Technologies © 2014
Noeuds KO
Et si 2 noeuds tombent ?
A
B C
Ippon Technologies © 2014
Noeuds KO
Pas d’interruption du service : aucune requête KO !
Mais la cohérence n’est pas assuré...
Ippon Technologies © 2014
Hinted off Repair
Hinted off Repair
Le noeud conserve la réplication dans la table system.hints ...
Ippon Technologies © 2014
Hinted off Repair - DEMO
$ ./nodetool --host 172.17.0.3 tpstats
Pool Name Active Pending Complet...
Ippon Technologies © 2014
Read Repair
Read repair
Réparation asynchrone des données
● Demande client d’une donnée à un noe...
Ippon Technologies © 2014
ReadRepair
A
B C
T+3A
B C
T+2
A
B C
T A
B C
T+1
Read
digest query
digest query
OK
KO
update value
Ippon Technologies © 2014
Consistency Level
Assurer la cohérence
Cassandra propose le mécanisme de Consistency Level.
Le c...
Ippon Technologies © 2014
Consistency Level
Une donnée sera forcément cohérente si
R + W > N
R : nombre de noeuds écrits; ...
Ippon Technologies © 2014
R + W > N
A
B C
ONE + ALL
A
B C
ALL + ONE
A
B C
QUORUM + QUORUM
Ippon Technologies © 2014
Noeuds KO - Consistency Level
Et si un noeud ou 2 noeuds tombent ?
DEMO
Scénario
● 3 noeuds, RF=...
Ippon Technologies © 2014
La configuration en “mode cohérent” avec QUORUM ne permet
pas de résister à la chute de 2 noeuds...
Ippon Technologies © 2014
Conclusion
Ippon Technologies © 2014
Conclusion
“On a long enough timeline, the survival rate for everyone drops
to zero”
● Contraint...
Ippon Technologies © 2014
Questions
MongoDB ReadPreferences
Election
Questions ?
Cassandra
ConsistencyLevel
Hinted off Rep...
blog.ippon.frippon.fr ippon-hosting.com
@ippontech contact@ippon.fr
Upcoming SlideShare
Loading in...5
×

Ippevent - Regarde les instances tomber - 20 mai 2014

204

Published on

Ippevent - Regarde les instances tomber

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
204
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
15
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Ippevent - Regarde les instances tomber - 20 mai 2014"

  1. 1. Regarde les instances tomber 20 mai 2014 Vincent Beretti
  2. 2. Ippon Technologies © 2014 Sommaire ● Théorie ● MongoDB ● Cassandra ● Conclusion
  3. 3. Ippon Technologies © 2014 Objectifs Objectifs de la présentation ● Comprendre les contraintes d’un système distribué ● Voir ces contraintes en application sur 2 architectures différentes ● Observer les comportements lors ○ de la chute d’instances ○ du morcellement du réseau ● Comprendre certains mécanismes de haute disponibilité ● Utiliser la configuration pour privilégier la disponibilité ou la cohérence
  4. 4. Ippon Technologies © 2014 Théorie
  5. 5. Ippon Technologies © 2014 Théorème CAP Theoreme CAP Conjecture décrite en 2000 par Eric Brewer de Berkeley. Il y présente les contraintes inhérentes à tout système distribué. 3 propriétés : ● Consistency (Cohérence) : tous les noeuds possèdent exactement la même donnée à un instant T ● Availability (Disponibilité) : la donnée est disponible à tout moment. ● Partition tolerance (Résistance au “morcellement”): le système peut continuer à opérer même en cas de perte d’ une partie du système.
  6. 6. Ippon Technologies © 2014 Théorème CAP Un système distribué a au plus 2 des 3 propriétés énoncées ci-dessus.
  7. 7. Ippon Technologies © 2014 Theorème CAP A C P MongoDB CassandraRDBMS
  8. 8. Ippon Technologies © 2014 MongoDB
  9. 9. Ippon Technologies © 2014 MongoDB ● Base orientée document ● Modèle asymétrique ○ 1 noeud primaire ○ n noeuds secondaires ● CP : consistency + network partition tolerance ● Redondance et haute disponibilité grâce au “Replica Set” MongoDB Secondary Secondary Primary WriteRead ReplicationReplication
  10. 10. Ippon Technologies © 2014 Bac à sable ● Docker ○ mongod ○ ssh ● REST App ○ spring boot ○ spring data mongoDB ● Gatling MongoDB mongod docker container REST App Gatling mongod docker container mongod docker container
  11. 11. Ippon Technologies © 2014 Primary - KO Et si le noeud primaire tombe ? DEMO Scénario ● 3 noeuds ● read & upsert en continu Secondary Secondary Primary WriteRead ReplicationReplication
  12. 12. Ippon Technologies © 2014 Primary - KO ● Environ 5 secondes d’indisponibilité ● Nouveau noeud Primaire est disponible ● Écritures & lectures envoyées au nouveau noeud Primaire
  13. 13. Ippon Technologies © 2014 Primary - OK - Election Secondary Secondary Primary Primary Secondary Primary Client Client heartbeat heartbeat T T+1
  14. 14. Ippon Technologies © 2014 Primary - OK - Election Critères d’élection ● ! hidden, ! arbitrer, priority !=0 ● priority + haute ● optime + récent ● ! vetoed ● quorum visibility Pas plus de 7 voters Possibilité de veto même par les non-voters
  15. 15. Ippon Technologies © 2014 Primary - OK - Client Java DefaultServer.java this.stateNotifier = new ServerStateNotifier(serverAddress, serverStateListener, settings.getHeartbeatSocketSettings(), mongo); this.scheduledFuture = scheduledExecutorService.scheduleAtFixedRate(stateNotifier, 0, settings.getHeartbeatFrequency(MILLISECONDS), MILLISECONDS); ServerStateNotifier.java final CommandResult isMasterResult = connection.runCommand(mongo.getDB("admin"), new BasicDBObject("ismaster", 1)); final CommandResult buildInfoResult = connection.runCommand(mongo.getDB("admin"), new BasicDBObject("buildinfo", 1)); serverDescription = createDescription(isMasterResult, buildInfoResult, elapsedNanosSum / count); // [...] serverStateListener.stateChanged( new ChangeEvent<ServerDescription>(currentServerDescription, serverDescription));
  16. 16. Ippon Technologies © 2014 Primary + Secondary - KO Et si le dernier noeud secondaire tombe ? DEMO Primary Secondary Primary Client heartbeat
  17. 17. Ippon Technologies © 2014 Primary + Secondary - KO Base totalement indisponible alors qu’il reste 1 noeud !
  18. 18. Ippon Technologies © 2014 Primary + Secondary - KO Secondary Secondary Primary Primary Secondary Primary heartbeat T T+1 [rsMgr] can't see a majority of the set, relinquishing primary [rsMgr] replSet relinquishing primary state
  19. 19. Ippon Technologies © 2014 Primary - KO - ReadPreferences Par défaut, Si le primaire tombe ● perte des lectures et écritures durant l'élection Si le dernier noeud secondaire tombe ● perte complète des lectures et écritures Noeuds secondaires utiles qu’en cas de failover. Sacrifier la cohérence pour gagner en disponibilité ?
  20. 20. Ippon Technologies © 2014 Primary - KO - ReadPreferences ReadPreferences Paramètre d’appel ● PRIMARY : default, cohérence +++, disponibilité -- ● PRIMARY_PREFERRED : cohérence ++ et disponibilité + ● SECONDARY : cohérence --, disponibilité ++ ● SECONDARY_PREFERRED : cohérence --, disponibilité +++ ● NEAREST : disponibilité +++ A configurer en fonction du besoin métier
  21. 21. Ippon Technologies © 2014 Primary - KO - ReadPreferences Et si le noeud primaire tombe ? DEMO Scénario ● 3 noeuds ● read & upsert en continu ● ReadPreferences ○ Primary preferred ○ Secondary preferred Secondary Secondary Primary ReplicationReplication
  22. 22. Ippon Technologies © 2014 Primary - KO - Primary Preferred Reads Writes
  23. 23. Ippon Technologies © 2014 Primary - KO - Secondary Preferred Répartition de charge (au détriment de la cohérence)
  24. 24. Ippon Technologies © 2014 Morcellement Morcellement Partitionnement du réseau au sein du cluster Cas déploiement multi-datacenter
  25. 25. Ippon Technologies © 2014 Morcellement Et si le cluster est morcelé ? DEMO Scénario ● 5 noeuds ● iptables Primary 172.17.0.2 Secondary 172.17.0.3 Secondary 172.17.0.4 Secondary 172.17.0.5 Secondary 172.17.0.6
  26. 26. Ippon Technologies © 2014 Morcellement IPTables sur noeuds 172.17.0.2 et 172.17.0.3 iptables -A INPUT -p ALL -s 172.17.0.4 -j DROP iptables -A INPUT -p ALL -s 172.17.0.5 -j DROP iptables -A INPUT -p ALL -s 172.17.0.6 -j DROP iptables -A OUTPUT -p ALL -d 172.17.0.4 -j DROP iptables -A OUTPUT -p ALL -d 172.17.0.5 -j DROP iptables -A OUTPUT -p ALL -d 172.17.0.6 -j DROP Primary 172.17.0.2 Secondary 172.17.0.3 Secondary 172.17.0.4 Secondary 172.17.0.5 Secondary 172.17.0.6
  27. 27. Ippon Technologies © 2014 Secondary 172.17.0.2 Secondary 172.17.0.3 Primary 172.17.0.4 Secondary 172.17.0.5 Secondary 172.17.0.6 [rsMgr] can't see a majority of the set, relinquishing primary [rsMgr] replSet relinquishing primary state [rsMgr] replSet SECONDARY [rsMgr] replSet closing client sockets after relinquishing primary Election
  28. 28. Ippon Technologies © 2014 Secondary 172.17.0.2 Secondary 172.17.0.3 Primary 172.17.0.4 Secondary 172.17.0.5 Secondary 172.17.0.6 [rsMgr] not electing self, [...] but 172.17.0.4:27017 is already primary and more up-to-date'
  29. 29. Ippon Technologies © 2014 Cassandra
  30. 30. Ippon Technologies © 2014 Cassandra Cassandra ● Base orientée colonnes ● Modèle symétrique ○ n noeuds disponibles en lectures et ecriture ● AP : Availability + network partition tolerance A B C
  31. 31. Ippon Technologies © 2014 Replication Factor Nombre de noeuds sur lesquels une données va être répliquée. A définir lors de la définition du keyspace (~= schema) Cassandra - Replication Factor A B C CREATE KEYSPACE IF NOT EXISTS myKsp WITH REPLICATION = { 'class' : 'SimpleStrategy', 'replication_factor' : 3 } A B C A B C RF : 1 RF : 2 RF : 3
  32. 32. Ippon Technologies © 2014 Bac à sable ● Docker ○ dsc-community ○ ssh ○ iptables ● REST App ○ spring boot ○ datastax java driver ● Datastax Ops Center Cassandra REST App GatlingOpsCenter cassandra docker container agent cassandra docker container agent cassandra docker container agent
  33. 33. Ippon Technologies © 2014 Noeud KO Et si un noeud tombe ? DEMO Scénario ● 3 noeuds, RF=3 ● read & upsert en continu A B C
  34. 34. Ippon Technologies © 2014 Noeuds KO Et si 2 noeuds tombent ? A B C
  35. 35. Ippon Technologies © 2014 Noeuds KO Pas d’interruption du service : aucune requête KO ! Mais la cohérence n’est pas assurée. Cependant, Cassandra dispose de plusieurs mécanismes pour assurer une cohérence “à terme” (eventually consistent)
  36. 36. Ippon Technologies © 2014 Hinted off Repair Hinted off Repair Le noeud conserve la réplication dans la table system.hints si un noeud est KO pour la rejouer quand il sera à nouveau disponible. Temps de conservation par défaut de 3h. A B C Write 1 Repl. Repl. A B C Repl. Write 1 T T+1
  37. 37. Ippon Technologies © 2014 Hinted off Repair - DEMO $ ./nodetool --host 172.17.0.3 tpstats Pool Name Active Pending Completed [...] HintedHandoff 1 1 3 Stockage des Hints Renvoi des hints au noeud défaillant
  38. 38. Ippon Technologies © 2014 Read Repair Read repair Réparation asynchrone des données ● Demande client d’une donnée à un noeud A ● Réponse du noeud A ● Envoi un digest de sa valeur du noeud A aux autres noeuds B et C pour vérifier la valeur ○ la valeur de A est trop ancienne: re-synchronization ○ un des noeuds B et C a une valeur trop ancienne: re- synchronization Échange peu coûteux (digest) Aléatoire (10%) : read_repair_chance configurable
  39. 39. Ippon Technologies © 2014 ReadRepair A B C T+3A B C T+2 A B C T A B C T+1 Read digest query digest query OK KO update value
  40. 40. Ippon Technologies © 2014 Consistency Level Assurer la cohérence Cassandra propose le mécanisme de Consistency Level. Le consistency level permet de s’assurer de l’application de la requête sur le nombre de noeuds suivants: ● ONE (par défaut) ● TWO ● THREE ● QUORUM : (total/2) +1 ● ALL Cette valeur est configurable au niveau de chaque requête.
  41. 41. Ippon Technologies © 2014 Consistency Level Une donnée sera forcément cohérente si R + W > N R : nombre de noeuds écrits; W : nombre de noeuds lus; N : nombre total de noeuds Exemples : ● QUORUM + QUORUM > N ● ALL + ONE > N ● ONE + ALL > N
  42. 42. Ippon Technologies © 2014 R + W > N A B C ONE + ALL A B C ALL + ONE A B C QUORUM + QUORUM
  43. 43. Ippon Technologies © 2014 Noeuds KO - Consistency Level Et si un noeud ou 2 noeuds tombent ? DEMO Scénario ● 3 noeuds, RF=3 ● read & upsert en continu ○ Consistency level = QUORUM A B C
  44. 44. Ippon Technologies © 2014 La configuration en “mode cohérent” avec QUORUM ne permet pas de résister à la chute de 2 noeuds. Noeuds KO - Consistency Level
  45. 45. Ippon Technologies © 2014 Conclusion
  46. 46. Ippon Technologies © 2014 Conclusion “On a long enough timeline, the survival rate for everyone drops to zero” ● Contraintes d’un système distribué : C - A - P ● Impact architecture symétrique / asymétrique ● CP / AP n’est pas figé ● Utilisation de la configuration au niveau requête pour privilégier cohérence ou disponibilité ● Contraintes dictées par l’utilisation fonctionnelle de la donnée https://github.com/vberetti/ippevent-20-05-2014
  47. 47. Ippon Technologies © 2014 Questions MongoDB ReadPreferences Election Questions ? Cassandra ConsistencyLevel Hinted off Repair Read Repair ReplicaSet Hints CAP Theorem Morcellement Replication Factor
  48. 48. blog.ippon.frippon.fr ippon-hosting.com @ippontech contact@ippon.fr
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×