DARX

All + All -

DARX

analyse
- généralité
  - la criticité ne doit pas être un goulet informationnel
    - ex : critcité = nombre
- criticité
  - consequences_crash(a)=qof
    - cc(a)>cc(b) => criticité(a) > criticité(b)
- défaillance
  - de noeud
    - crash
    - omission
    - byzantin
  - de réseau
    - fiable
    - équitable
- grandeurs
  - défaillance
    - 1 toutes les 4mn pour 5000 machines
conception
- + - architecturale
  - en entrée
    - concepteur (offline)
    - utilisateur (offline)
    - observation (obs)
    - système (sys)
  - en interne
    - csq crash a ou A sur qof
    - proba de crash
  - en sortie
    - choix réplication
      - quel agent
      - quelle stratégie
- + - distribuer
  - analyse criticité
  - décision de réplication
- + - flux des informations
  - connecter des sources et des puits
  - connection/déconnection des sources et puits dynamiquement en fonction qof et ressources
  - pb : les puits doivent être capable de trouver des sources et inversement
    - sol
      - ontologie commune + yp déentralisé
  - pb : les puits doivent être capable de comprendre et d'intégrer diverses types d'information
  - sol:
    - comprendre = ontologie + langage commun ?
    - intégrer
- + - localisation du réplicateur
  - observateurs
    - pb:centré agent = vision locale/égoïste = trop de réplication
  - systèmes
    - pb : centré ressource = peu de réplication
  - population agents mobiles
    - maj B sur criticités et ressources
    - échange de B
      - contact direct
      - traces sur les sites
    - pb : relativité des B (points de vue)
    - pb : itinéraires
- qos
  - + - exemple
    - vitesse de résolution
    - quantité de services
    - précision de simulation
  - + - nconvénients
    - sol 1 : proba
      - P(QOF)>p, p fixée par user
      - si not QOF, que faire ?
    - sol 2 : satisfaction
      - sat(qof) in [0,1]
      - maximiser la satisfaction
    - mélanger ?
      - garantir une espérance de satisfaction
    - ex : qof = vitesse x qualité_solution
      - P(qof)>=p
      - p ne peut être garanti
        baisse v
        
        baisse s
        
        baisse p
      - pb : choix user ?
        sat : Q x [0, 1] -> [0,1]
        
        qof x proba -> sat
        
        pb
        représenter fonction simplement
        
        trouver facilement qof et proba adaptée
  - + - agir
    - + - + replication
      - + cohérence
      - - réseau
      - - proc
      - - vitesse
      - + fiabilité
      - ? disque
    - + - + déplacement
      - + proc
      - + vitesse
      - + réseau
      - + fiabilité
    - + - + détection (heartbeat)
      - + cohérence
        plus tôt
      - - réseau
        heartbeat
    - + - + ordonnancement tâches
      - pb
        très lié à l'appli
        
        K supplémentaire
    - + - + estimation qof (fine)
      - - proc
      - - réseau
      - + réalisme
    - + - déplacement agent
      - +- fiabilité
      - +- volume réseau
      - +- débit réseau
      - +- vitesse
    - + - stratégie réplication
      - +- trafic réseau
      - +- trafic disque
      - +- cohérence
      - coût du changement
    - + - action simple
      - qualitatif : +x => +y, apprendre quel x choisir et de combien le modifier
  - estimer
    - sources d'information
      - agents système
      - agents observateurs
      - concepteur système
      - utilisateur
    - quoi
      - criticité (=csq crash)
      - ressources disponibles
    - probabilité de crash
      - dans les t secondes à venir (t=période remise en cause réplication)
        P(a crash/s)xtps processus
      - F(q)=P(qos>q)
        caractéristiques
        F(0)=1
        
        F(qmax)=0
        
        F décroissante
        
        modélisée/approximée
        qmoy, variance q, pmoy
        
        simple pour computable, plus naturelle pour expert
        
        sat(q,p) ne suffit pas, car que faire si impossible à tenir ?
        
        solution exacte : satisfaction pour toutes les fonctions F possibles
      - P(k fautes)=Cnk alpha^k (1-alpha)^(n-k)
  - exemple
    - simulation grille de calcul
- estimer la conséquence globale (qof) d'un crash local ?
  - diffusion progressive de l'information
    - principe : global = voisinage qui diffuse
    - b -> a : si tu crashes, csqs pour moi
    - propagation avec a b c
    - init
      - impact absolu = valeur moyenne attribut / nb agents
      - impact relatif = impact absolu / impact max (ou moy)
    - diffusion de l'impact relatif = homogénéisation de l'impact relatif
  - dépend de ce qu'on fait en cas de crash
    - remplacement
      - état moyen (simulation physique)
        perte précision (simulation)
      - état aléatoire (jeu de la vie)
      - recommence
        répliquer les plus risqués
        processeur + risqué
        
        un processus qui dure longtemps
    - continue sans
      - nouvelles interactions / réorganisation
- + - qualité de détection
  - complétude
    - tps de détection
  - justesse
    - tps entre 2 fausses suspiscions
    - durée des fausses suspiscions
  - adaptation
    - modération
      - adaptateur -> base
    - négociation
      - base -> adaptateur
  - pb: repose sur des modèles de bon /mauvais fonctionnement
  - quels processus surveiller
    - tous
    - les plus critiques
    - ceux qui le demandent
+ - implémentation
- fixer les paramètres
  - définir des plans de test
+ - information
- puits/sources
- comprendre et intégrer les sources
- dynamique
- irrégulier
- confiance
question
- améliorer le système sans perte ?
  - processeur non utilisé
- comportement système
  - modèle de comportement global, à ajuster
  - ou hypothèse que tout va continuer comme maintenant
- avec réplication
  - tps de calcul modifié
  - pour chaque config C
    - tester effet de chaque panne sur chaque proc
      - soit on recommence (réplication insufisante)
      - soit on continue (avec quelle réplication ?)
  - hypothèse : 1 seule panne pendant tout le calcul
- remplace sat par classement des fonctions F
- hypothèse : optimisation tt processus = somme des optimisations locales
  - heuristique en cas d'absence de K supp
  - ex hyp fausse:
    - taches plus ou moins longues
- tps de calcul en simulation
  - dint=0
  - t=l²/v+ldext
  - a=pl²
  - l²=a/p
  - t=a²/(p²v)+sqrt(a/p)dext
  - erreur=x=1/|V|SommeV xz
  - estimation erreur : calcul k pas avec faute/ calcul k pas sans faute
  - garder la trace faute x -> qos y
- qos
  - estimation
    - continu
      - ex : SMA fournisseur de service
      - sempiternelle
    - ponctuelle
      - Exist t / qos(t)=qostot
      - Hyp:qostot=Int{Dt}qos(Dt)=>optimisation locale sur Dt
        Ex Hyp fausse
- sous-cas
  - modélisation diagramme de Gantt Go
  - algo de répartition optimale
  - calcul Fqos en fonction proba crash proc et mesures en cas de crash
  - Forall R, GR=Go+réplication des tâches de R
- il faut
  - ex d'optimisation locale (espace)
    - large échelle
    - ex:grille de simulation
  - ex d'optimisation Dt (temps)
    - SMA dynamique, autonome
- amortir le coût de la migration/duplication sur quel terme : Dt, tout processus ?
- architecture
  - agents
    - Meta
      - info indep ressources-> DRH
        ex info : qos fct du nb d'instructions, pas du temps
      - info pour qos qd pas de crash, 1 crash, +1 réplicat, -1 réplicat, migration, ...
      - quand revoir ces données
    - DRH
      - crash a => Dqos
      - Fqos(C), C=configuration(placement+réplication)
        ss crash
        nb d'instructions
        
        précisions
        
        1 crash
      - choisir les k config les plus intéressantes
    - Sys
      - proba crash, ressources dispo (CPU, réseau, mem)-> DRH
  - 1 DRH gère 1 zone
    - évaluation des csqs sur la zone
      pb : fusionner les évaluations, au moins dans le voisinage
      pb : le site de réplication impacte la qos, donc on ne peut pas comparer les impacts de réplication, choisir le plus important, PUIS décider où répliquer
      sol minimale : on compare les impacts de réplication en faisant l'hypothèse que faire plusieurs réplications ne change pas le choix fait
      hyp : Dqos1&2 = Dqos1 + Dqos2 (additif)
- réplicateur
  - reçoit info sur qos zone
  - compare avec info qos autres zones
  - décide avec autres R qui et où répliquer
  - reçoit info sur ressources de sa zone
  - compare ces infos
  - propose migration/réplication aux agents
- idée : considérer puissance de calcul des proc comme des vitesses d'écoulement du temps