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
Prochain SlideShare
Chargement dans…5
×

NoSQL – Regarde les instances tomber ! par Vincent Beretti

2 412 vues

Publié le

Dans le monde des base de données NoSQL, l’accent est souvent mis sur la haute disponibilité. Ces bases disposent donc généralement de mécanismes complexes de réplication, de failover…

L’objectif de cette conférence est de présenter ces aspects sur MongoDB. Tout en abordant les aspects théoriques de ces mécanismes, une partie dynamique montrera le comportement des clusters sous forte charge.

Les mécanismes de Cassandra seront également présentés. Si le temps le permet, une démo sera également jouée.

Le lien vers le repository github :
https://github.com/vberetti/ippevent-20-05-2014

Publié dans : Ingénierie
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
2 412
Sur SlideShare
0
Issues des intégrations
0
Intégrations
805
Actions
Partages
0
Téléchargements
125
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

NoSQL – Regarde les instances tomber ! par Vincent Beretti

  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

×