NoSQL – Regarde les instances tomber ! par Vincent Beretti

Regarde les instances tomber
20 mai 2014
Vincent Beretti

Ippon Technologies © 2014
Sommaire
● Théorie
● MongoDB
● Cassandra
● Conclusion

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

Théorie

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.

Théorème CAP
Un système distribué a au plus 2 des 3 propriétés énoncées
ci-dessus.

Theorème CAP
A
C P
MongoDB
CassandraRDBMS

MongoDB

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

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

Primary - KO
Et si le noeud primaire tombe ?
DEMO
Scénario
● 3 noeuds
● read & upsert en continu
Secondary Secondary
Primary
WriteRead

Primary - KO
● Environ 5 secondes d’indisponibilité
● Nouveau noeud Primaire est disponible
● Écritures & lectures envoyées au nouveau noeud Primaire

Primary - OK - Election
Secondary Secondary
Primary
Primary Secondary
Primary
Client
Client
heartbeat
heartbeat
T
T+1

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

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));

Primary + Secondary - KO
Et si le dernier noeud secondaire tombe ?
DEMO
Primary Secondary
Primary
Client
heartbeat

Base totalement indisponible alors qu’il reste 1 noeud !

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

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é ?

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

Et si le noeud primaire tombe ?
DEMO
Scénario
● 3 noeuds
● ReadPreferences
○ Primary preferred
○ Secondary preferred
Secondary Secondary
Primary

Primary - KO - Primary Preferred
Reads
Writes

Primary - KO - Secondary Preferred
Répartition de charge (au détriment de la cohérence)

Morcellement
Morcellement
Partitionnement du réseau au sein du cluster
Cas déploiement multi-datacenter

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

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 OUTPUT -p ALL -d 172.17.0.4 -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

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

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'

Cassandra

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

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

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

Noeud KO
Et si un noeud tombe ?
DEMO
Scénario
● 3 noeuds, RF=3
A
B C

Noeuds KO
Et si 2 noeuds tombent ?
A
B C

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)

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

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

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

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

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.

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

R + W > N
A
B C
ONE + ALL
A
B C
ALL + ONE
A
B C
QUORUM + QUORUM

Noeuds KO - Consistency Level
Et si un noeud ou 2 noeuds tombent ?
DEMO
Scénario
● 3 noeuds, RF=3
○ Consistency level = QUORUM
A
B C

La configuration en “mode cohérent” avec QUORUM ne permet
pas de résister à la chute de 2 noeuds.
Noeuds KO - Consistency Level

Conclusion

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

Questions
MongoDB ReadPreferences
Election
Questions ?
Cassandra
ConsistencyLevel
Hinted off Repair
Read Repair
ReplicaSet
Hints
CAP Theorem
Morcellement
Replication Factor

blog.ippon.frippon.fr ippon-hosting.com
@ippontech contact@ippon.fr

NoSQL – Regarde les instances tomber ! par Vincent Beretti

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (20)

Dernier

Dernier (9)

NoSQL – Regarde les instances tomber ! par Vincent Beretti