nosql – regarde les instances tomber ! par vincent beretti

Regarde les instances tomber20 mai 2014

Vincent Beretti

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 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.

Théorème CAP

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

Theorème CAP

C PMongoDB

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 ?

DEMOScénario● 3 noeuds● read & upsert en continu

Secondary Secondary

Primary

WriteRead

ReplicationReplication

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

heartbeat

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

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

Primary + Secondary - KO

Et si le dernier noeud secondaire tombe ?

Primary Secondary

Primary

Client

heartbeat

Base totalement indisponible alors qu’il reste 1 noeud !

Secondary Secondary

Primary

Primary Secondary

Primary

heartbeat

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

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

Et si le noeud primaire tombe ?

DEMOScénario● 3 noeuds● read & upsert en continu● ReadPreferences

○ Primary preferred○ Secondary preferred

Secondary Secondary

PrimaryReplicationReplication

Primary - KO - Primary Preferred

Writes

Primary - KO - Secondary Preferred

Répartition de charge (au détriment de la cohérence)

Morcellement

MorcellementPartitionnement du réseau au sein du clusterCas déploiement multi-datacenter

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

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

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

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'

Cassandra

Cassandra● Base orientée colonnes● Modèle symétrique

○ n noeuds disponibles en lectures et ecriture● AP : Availability + network partition tolerance

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

CREATE KEYSPACE IF NOT EXISTS myKsp WITH REPLICATION = { 'class' : 'SimpleStrategy', 'replication_factor' : 3 }

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

cassandra

docker container

cassandra

docker container

Noeud KO

Et si un noeud tombe ?

DEMOScénario● 3 noeuds, RF=3● read & upsert en continu

Noeuds KO

Et si 2 noeuds tombent ?

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 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.

B CWrite 1

B CRepl. Write 1

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

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

ReadRepair

digest query

KO update value

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.

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

R + W > N

ONE + ALLA

ALL + ONEA

QUORUM + QUORUM

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

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

Noeuds KO - Consistency Level

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

CAP Theorem

Morcellement

Replication Factor

blog.ippon.frippon.fr ippon-hosting.com

@ippontech contact@ippon.fr

nosql – regarde les instances tomber ! par vincent beretti

Engineering

tomber dans bain des groupes d'échanges

révision des verbes français bi. les verbes er je regarde...

regarde...

présent: regarder je regarde tu regardes il regarde nous...

drippy regarde en bas et se dit: “j’aimerais bien tomber...

regarde cela, c’est tres important

tomber en amour.docx

ne regarde pas ta montre…

programme regarde voir !

je regarde. il regarde regarder puis cela jaime

tuto n°7 regarde le paysage

faire tomber les barrieres

faire tomber a partir d'un ramassement de jambe

automatique dieu me regarde dans le son de ta voix, dieu me...

anno scolastico 2019 / 2020 prof. paolo beretti i colori

ippevent - regarde les instances tomber - 20 mai 2014

une regarde pour haïti

l’union européenne ça me regarde

tomber en amour - akentrepot.fr

nous n’avons pas vu la nuit tomber