nosql – regarde les instances tomber ! par vincent beretti
DESCRIPTION
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-2014TRANSCRIPT
Regarde les instances tomber20 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é● 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
Ippon Technologies © 2014
Théorie
Ippon Technologies © 2014
Théorème CAP
Theoreme CAPConjecture 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.
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 PMongoDB
CassandraRDBMS
Ippon Technologies © 2014
MongoDB
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
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
Ippon Technologies © 2014
Primary - KO
Et si le noeud primaire tombe ?
DEMOScénario● 3 noeuds● read & upsert en continu
Secondary Secondary
Primary
WriteRead
ReplicationReplication
Ippon Technologies © 2014
Primary - KO
● Environ 5 secondes d’indisponibilité● Nouveau noeud Primaire est disponible● Écritures & lectures envoyées au nouveau noeud Primaire
Ippon Technologies © 2014
Primary - OK - Election
Secondary Secondary
Primary
Primary Secondary
Primary
Client
Client
heartbeat
heartbeat
T
T+1
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 votersPossibilité de veto même par les non-voters
Ippon Technologies © 2014
Primary - OK - Client JavaDefaultServer.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));
Ippon Technologies © 2014
Primary + Secondary - KO
Et si le dernier noeud secondaire tombe ?
DEMO
Primary Secondary
Primary
Client
heartbeat
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
[rsMgr] can't see a majority of the set, relinquishing primary[rsMgr] replSet relinquishing primary state
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é ?
Ippon Technologies © 2014
Primary - KO - ReadPreferences
ReadPreferencesParamè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
Ippon Technologies © 2014
Primary - KO - ReadPreferences
Et si le noeud primaire tombe ?
DEMOScénario● 3 noeuds● read & upsert en continu● ReadPreferences
○ Primary preferred○ Secondary preferred
Secondary Secondary
PrimaryReplicationReplication
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
MorcellementPartitionnement du réseau au sein du clusterCas déploiement multi-datacenter
Ippon Technologies © 2014
Morcellement
Et si le cluster est morcelé ?
DEMOScénario● 5 noeuds● iptables Primary
172.17.0.2
Secondary172.17.0.3
Secondary172.17.0.4
Secondary172.17.0.5
Secondary172.17.0.6
Ippon Technologies © 2014
Morcellement
IPTables sur noeuds 172.17.0.2 et 172.17.0.3iptables -A INPUT -p ALL -s 172.17.0.4 -j DROPiptables -A INPUT -p ALL -s 172.17.0.5 -j DROPiptables -A INPUT -p ALL -s 172.17.0.6 -j DROPiptables -A OUTPUT -p ALL -d 172.17.0.4 -j DROPiptables -A OUTPUT -p ALL -d 172.17.0.5 -j DROPiptables -A OUTPUT -p ALL -d 172.17.0.6 -j DROP
Primary172.17.0.2
Secondary172.17.0.3
Secondary172.17.0.4
Secondary172.17.0.5
Secondary172.17.0.6
Ippon Technologies © 2014
Secondary172.17.0.2
Secondary172.17.0.3
Primary172.17.0.4
Secondary172.17.0.5
Secondary172.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
Ippon Technologies © 2014
Secondary172.17.0.2
Secondary172.17.0.3
Primary172.17.0.4
Secondary172.17.0.5
Secondary172.17.0.6
[rsMgr] not electing self, [...] but 172.17.0.4:27017 is already primary and more up-to-date'
Ippon Technologies © 2014
Cassandra
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
Ippon Technologies © 2014
Replication FactorNombre 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
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
Ippon Technologies © 2014
Noeud KO
Et si un noeud tombe ?
DEMOScé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ée.
Cependant, Cassandra dispose de plusieurs mécanismes pour assurer une cohérence “à terme” (eventually consistent)
Ippon Technologies © 2014
Hinted off Repair
Hinted off RepairLe 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 CWrite 1
Repl.
Repl.
A
B CRepl. Write 1
T T+1
Ippon Technologies © 2014
Hinted off Repair - DEMO
$ ./nodetool --host 172.17.0.3 tpstatsPool Name Active Pending Completed [...]HintedHandoff 1 1 3
Stockage des Hints
Renvoi des hints au noeud défaillant
Ippon Technologies © 2014
Read Repair
Read repairRé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
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érenceCassandra 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.
Ippon Technologies © 2014
Consistency Level
Une donnée sera forcément cohérente si
R + W > NR : nombre de noeuds écrits; W : nombre de noeuds lus; N : nombre total de noeuds
Exemples :● QUORUM + QUORUM > N● ALL + ONE > N● ONE + ALL > N
Ippon Technologies © 2014
R + W > N
A
B C
ONE + ALLA
B C
ALL + ONEA
B C
QUORUM + QUORUM
Ippon Technologies © 2014
Noeuds KO - Consistency Level
Et si un noeud ou 2 noeuds tombent ?
DEMOScénario● 3 noeuds, RF=3● read & upsert en continu
○ Consistency level = QUORUM
A
B C
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
Ippon Technologies © 2014
Conclusion
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
Ippon Technologies © 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 [email protected]