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]