NoSQL – Regarde les instances tomber ! par Vincent Beretti3. 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
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. Ippon Technologies © 2014
Théorème CAP
Un système distribué a au plus 2 des 3 propriétés énoncées
ci-dessus.
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. 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. 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. Ippon Technologies © 2014
Primary - KO
● Environ 5 secondes d’indisponibilité
● Nouveau noeud Primaire est disponible
● Écritures & lectures envoyées au nouveau noeud Primaire
13. Ippon Technologies © 2014
Primary - OK - Election
Secondary Secondary
Primary
Primary Secondary
Primary
Client
Client
heartbeat
heartbeat
T
T+1
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. 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. Ippon Technologies © 2014
Primary + Secondary - KO
Et si le dernier noeud secondaire tombe ?
DEMO
Primary Secondary
Primary
Client
heartbeat
17. Ippon Technologies © 2014
Primary + Secondary - KO
Base totalement indisponible alors qu’il reste 1 noeud !
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. 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. 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. 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
23. Ippon Technologies © 2014
Primary - KO - Secondary Preferred
Répartition de charge (au détriment de la cohérence)
24. Ippon Technologies © 2014
Morcellement
Morcellement
Partitionnement du réseau au sein du cluster
Cas déploiement multi-datacenter
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. 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. 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. 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'
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. 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. 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. Ippon Technologies © 2014
Noeud KO
Et si un noeud tombe ?
DEMO
Scénario
● 3 noeuds, RF=3
● read & upsert en continu
A
B C
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. 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. 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. 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. 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. 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. 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
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. 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
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. Ippon Technologies © 2014
Questions
MongoDB ReadPreferences
Election
Questions ?
Cassandra
ConsistencyLevel
Hinted off Repair
Read Repair
ReplicaSet
Hints
CAP Theorem
Morcellement
Replication Factor