introduction
analyse de l'échec du vol inaugural d'Ariane 5
ariane5.pdf
gestion des pannes
tout peut tomber en panne
matériel/logiciel
réseau
causes
usure
bugs
système mal testé
précipitation dans mise sur le marché
humaines
environnementales
pannes inévitables
nombreux sous-systèmes indépendants
deux aspects
tolérance aux pannes
éviter les comportements incorrects
transactions
haute disponibilité
éviter les interruptions de service
importance de la détection rapide des pannes
modèles de pannes
panne-arrêt
assez facile à gérer
pas réaliste
ralentissement
quelques algorithmes existent
pannes bizantines
très difficiles à gérer
permanence des effets
permanentes
disponibilité
MTBF/(MTBF+MTTR)
transitoires
dans circonstances peu probables
relacer la machine/le service
traitement
actions
détection
confinement
masquage
vue en couches
panne = comportement exceptionnel dans une couche
transformer en événement attendu pour couche supérieure
rendre invisible pour autres couches
technique matérielle
redondance triple modulaire
vote sur 3 systèmes
protéger le système de vote
le + simple possible
sur machine fiabilisée
réplication
reprise après panne
après panne et réparation
récupération état
techniques
points de passage
enregistrement stable de l'état
journalisation
enregistrement stable des messages reçus
retour en arrière
des autres
pour revenir à un état consistant
ligne de reprise
problèmes
existence d'une ligne de reprise
points de passage
retrouver la meilleure
retour en arrière
difficultés
messages
orphelins
dupliqués
retours en arrière en cascade
bégaiement
choix
journaliser ou non les messages reçus
flexibilité pendant récupération
coût de stockage
déterminisme des processus nécessaire
coordination de l'enregistrement de l'état
algorithmes
checkpoint sans coordination
pas de garantie
espoir que les retours en arrières seront
peu fréquents
limités
checkpoint avec coordination
possibilité de panne pendant enregistrement
ramasse-miette
matrices d'estampilles
checkpoint incrémental
journalisation synchrone
avec coordination
enregistrement messages avant délivrance
récupération = rejouer les messages
délais peuvent être inacceptables
journalisation asynchrone
sans coordination
journalisation n'importe quand
questions
trouver ligne de reprise
quand peut-on effacer vieux messages ?
seuls messages permettant récupération doivent être enregistré
journalisation adaptative
réplication
services
état ?
modélisation avec machine à états
indépendance au temps
tolérance à n pannes
n+1 répliques
reçoivent toutes
mêmes entrées
dans même ordre
+ vote
doit être fiable
respecter au moins causalité
+
modèle conceptuel
masque vote
indiscernable d'une seule machine
-
trop coûteux
primaire/secours
principe
communication avec primaire
secours prend relai en cas de panne
+
simplicité
performance
-
que faire si primaire donne un mauvais résultat ?
des requêtes peuvent être perdues
protocoles
nécessités
1 seul primaire à un moment donné
1 seul primaire pour chaque client
interruptions de service bornées
requêtes traitées seulement sur primaire
battements de coeur
Pacemaker
ressources
lesquelles ?
mémoire
fichiers
bases de données
options de gestion
lecture
d'un serveur primaire
de n'importe que serveur
d'un quorum
écriture
sur le primaire
sur tous
mis à jour atomique
sur tous les disponibles
sur un quorum
propagation lente
stratégies de réplication
lit d'un / écrit sur tous
sérialisation
pas de concurrence
lit d'un / écrit sur tous les disponibles
plus de sérialisation
en cas de panne
lit d'un quorum / écrit sur un quorum
bon compromis
lit d'un / propagation lente
haute disponibilité
en cas de probabilité de pannes élevée
utiliser des vecteurs d'estampilles pour garantir causalité
options avec migration
possibilités lecture/écriture
accès distant
migration
réplication
stratégies
serveur distant
accés distant en lecture et en écriture
serveur dynamique
migration en lecture et en écriture
lecture réplication / écriture migration
choix populaire
sémantique claire
consistence forte
lecture réplication / écriture réplication
consistence forte difficile
possibilité d'utiliser validation à deux phases