Ippevent - Regarde les instances tomber - 20 mai 2014

Regarde les instances tomber20 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 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

A

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

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

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



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

Reads

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

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


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 ?

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

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


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

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

A

B C

ONE + ALLA

B C

ALL + ONEA

B C

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

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 [email protected]

Technology

Ippevent - Regarde les instances tomber - 20 mai 2014