SlideShare une entreprise Scribd logo
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é
● 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 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.
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
● 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 ?
DEMO
Scé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 voters
Possibilité de veto même par les non-voters
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));
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
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
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
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-datacenter
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
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
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
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'
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 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
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 ?
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ée.
Cependant, Cassandra dispose de plusieurs mécanismes pour
assurer une cohérence “à terme” (eventually consistent)
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
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
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
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 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 > 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
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=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 contact@ippon.fr

Contenu connexe

En vedette

Atelier TDD (Test Driven Development)
Atelier TDD (Test Driven Development)Atelier TDD (Test Driven Development)
Atelier TDD (Test Driven Development)
Ippon
 
Realtime Web avec Akka, Kafka, Spark et Mesos - Devoxx Paris 2014
Realtime Web avec Akka, Kafka, Spark et Mesos - Devoxx Paris 2014Realtime Web avec Akka, Kafka, Spark et Mesos - Devoxx Paris 2014
Realtime Web avec Akka, Kafka, Spark et Mesos - Devoxx Paris 2014
Ippon
 
One Web (API?) – Alexandre Bertails - Ippevent 10 juin 2014
One Web (API?) – Alexandre Bertails - Ippevent 10 juin 2014One Web (API?) – Alexandre Bertails - Ippevent 10 juin 2014
One Web (API?) – Alexandre Bertails - Ippevent 10 juin 2014
Ippon
 
Multi criteria queries on a cassandra application
Multi criteria queries on a cassandra applicationMulti criteria queries on a cassandra application
Multi criteria queries on a cassandra application
Ippon
 
Quoi de neuf pour JHipster en 2016
Quoi de neuf pour JHipster en 2016Quoi de neuf pour JHipster en 2016
Quoi de neuf pour JHipster en 2016
Ippon
 
Agilité, n’oublions pas les valeurs
Agilité, n’oublions pas les valeursAgilité, n’oublions pas les valeurs
Agilité, n’oublions pas les valeurs
Ippon
 
Système d’Information à l’Apec : un nouveau coeur de métier mis en place avec...
Système d’Information à l’Apec : un nouveau coeur de métier mis en place avec...Système d’Information à l’Apec : un nouveau coeur de métier mis en place avec...
Système d’Information à l’Apec : un nouveau coeur de métier mis en place avec...
Ippon
 
Démystifions le machine learning avec spark par David Martin pour le Salon B...
Démystifions le machine learning avec spark par David Martin pour le Salon B...Démystifions le machine learning avec spark par David Martin pour le Salon B...
Démystifions le machine learning avec spark par David Martin pour le Salon B...
Ippon
 
Offre 2015 numeriq_ippon
Offre 2015 numeriq_ipponOffre 2015 numeriq_ippon
Offre 2015 numeriq_ippon
Ippon
 
Stateful is beautiful
Stateful is beautifulStateful is beautiful
Stateful is beautiful
Ippon
 
Présentation Ippon DGA Liferay Symposium 2011
Présentation Ippon DGA Liferay Symposium 2011Présentation Ippon DGA Liferay Symposium 2011
Présentation Ippon DGA Liferay Symposium 2011
Ippon
 
Mule ESB Summit 2010 avec Ippon
Mule ESB Summit 2010 avec IpponMule ESB Summit 2010 avec Ippon
Mule ESB Summit 2010 avec Ippon
Ippon
 
JPA avec Cassandra, grâce à Achilles
JPA avec Cassandra, grâce à AchillesJPA avec Cassandra, grâce à Achilles
JPA avec Cassandra, grâce à Achilles
Ippon
 
Nouveau look pour une nouvelle vie : HTML5, Spring, NoSQL et Mobile
Nouveau look pour une nouvelle vie : HTML5, Spring, NoSQL et MobileNouveau look pour une nouvelle vie : HTML5, Spring, NoSQL et Mobile
Nouveau look pour une nouvelle vie : HTML5, Spring, NoSQL et Mobile
Ippon
 
Hibernate vs le_cloud_computing
Hibernate vs le_cloud_computingHibernate vs le_cloud_computing
Hibernate vs le_cloud_computing
Ippon
 
CDI par la pratique
CDI par la pratiqueCDI par la pratique
CDI par la pratique
Ippon
 
Seminaire Portail Open Source
Seminaire Portail Open SourceSeminaire Portail Open Source
Seminaire Portail Open Source
Ippon
 
Présentation Rex GWT 2.0
Présentation Rex GWT 2.0Présentation Rex GWT 2.0
Présentation Rex GWT 2.0
Ippon
 
Présentation du retour d'expérience sur Git
Présentation du retour d'expérience sur GitPrésentation du retour d'expérience sur Git
Présentation du retour d'expérience sur Git
Ippon
 
Scrum et forfait
Scrum et forfaitScrum et forfait
Scrum et forfait
Ippon
 

En vedette (20)

Atelier TDD (Test Driven Development)
Atelier TDD (Test Driven Development)Atelier TDD (Test Driven Development)
Atelier TDD (Test Driven Development)
 
Realtime Web avec Akka, Kafka, Spark et Mesos - Devoxx Paris 2014
Realtime Web avec Akka, Kafka, Spark et Mesos - Devoxx Paris 2014Realtime Web avec Akka, Kafka, Spark et Mesos - Devoxx Paris 2014
Realtime Web avec Akka, Kafka, Spark et Mesos - Devoxx Paris 2014
 
One Web (API?) – Alexandre Bertails - Ippevent 10 juin 2014
One Web (API?) – Alexandre Bertails - Ippevent 10 juin 2014One Web (API?) – Alexandre Bertails - Ippevent 10 juin 2014
One Web (API?) – Alexandre Bertails - Ippevent 10 juin 2014
 
Multi criteria queries on a cassandra application
Multi criteria queries on a cassandra applicationMulti criteria queries on a cassandra application
Multi criteria queries on a cassandra application
 
Quoi de neuf pour JHipster en 2016
Quoi de neuf pour JHipster en 2016Quoi de neuf pour JHipster en 2016
Quoi de neuf pour JHipster en 2016
 
Agilité, n’oublions pas les valeurs
Agilité, n’oublions pas les valeursAgilité, n’oublions pas les valeurs
Agilité, n’oublions pas les valeurs
 
Système d’Information à l’Apec : un nouveau coeur de métier mis en place avec...
Système d’Information à l’Apec : un nouveau coeur de métier mis en place avec...Système d’Information à l’Apec : un nouveau coeur de métier mis en place avec...
Système d’Information à l’Apec : un nouveau coeur de métier mis en place avec...
 
Démystifions le machine learning avec spark par David Martin pour le Salon B...
Démystifions le machine learning avec spark par David Martin pour le Salon B...Démystifions le machine learning avec spark par David Martin pour le Salon B...
Démystifions le machine learning avec spark par David Martin pour le Salon B...
 
Offre 2015 numeriq_ippon
Offre 2015 numeriq_ipponOffre 2015 numeriq_ippon
Offre 2015 numeriq_ippon
 
Stateful is beautiful
Stateful is beautifulStateful is beautiful
Stateful is beautiful
 
Présentation Ippon DGA Liferay Symposium 2011
Présentation Ippon DGA Liferay Symposium 2011Présentation Ippon DGA Liferay Symposium 2011
Présentation Ippon DGA Liferay Symposium 2011
 
Mule ESB Summit 2010 avec Ippon
Mule ESB Summit 2010 avec IpponMule ESB Summit 2010 avec Ippon
Mule ESB Summit 2010 avec Ippon
 
JPA avec Cassandra, grâce à Achilles
JPA avec Cassandra, grâce à AchillesJPA avec Cassandra, grâce à Achilles
JPA avec Cassandra, grâce à Achilles
 
Nouveau look pour une nouvelle vie : HTML5, Spring, NoSQL et Mobile
Nouveau look pour une nouvelle vie : HTML5, Spring, NoSQL et MobileNouveau look pour une nouvelle vie : HTML5, Spring, NoSQL et Mobile
Nouveau look pour une nouvelle vie : HTML5, Spring, NoSQL et Mobile
 
Hibernate vs le_cloud_computing
Hibernate vs le_cloud_computingHibernate vs le_cloud_computing
Hibernate vs le_cloud_computing
 
CDI par la pratique
CDI par la pratiqueCDI par la pratique
CDI par la pratique
 
Seminaire Portail Open Source
Seminaire Portail Open SourceSeminaire Portail Open Source
Seminaire Portail Open Source
 
Présentation Rex GWT 2.0
Présentation Rex GWT 2.0Présentation Rex GWT 2.0
Présentation Rex GWT 2.0
 
Présentation du retour d'expérience sur Git
Présentation du retour d'expérience sur GitPrésentation du retour d'expérience sur Git
Présentation du retour d'expérience sur Git
 
Scrum et forfait
Scrum et forfaitScrum et forfait
Scrum et forfait
 

NoSQL – Regarde les instances tomber ! par Vincent Beretti

  • 1. Regarde les instances tomber 20 mai 2014 Vincent Beretti
  • 2. Ippon Technologies © 2014 Sommaire ● Théorie ● MongoDB ● Cassandra ● Conclusion
  • 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. Ippon Technologies © 2014 Théorie
  • 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.
  • 7. Ippon Technologies © 2014 Theorème CAP A C P MongoDB CassandraRDBMS
  • 8. Ippon Technologies © 2014 MongoDB
  • 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
  • 22. Ippon Technologies © 2014 Primary - KO - Primary Preferred Reads Writes
  • 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'
  • 29. Ippon Technologies © 2014 Cassandra
  • 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
  • 34. Ippon Technologies © 2014 Noeuds KO Et si 2 noeuds tombent ? 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
  • 42. Ippon Technologies © 2014 R + W > N A B C ONE + ALL A B C ALL + ONE A B C QUORUM + QUORUM
  • 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
  • 45. Ippon Technologies © 2014 Conclusion
  • 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