Bibliographie du projet » Historique » Version 3
Yanick Delarbre, 28/01/2012 15:16
1 | 1 | Yanick Delarbre | h1. Bibliographie du projet |
---|---|---|---|
2 | 1 | Yanick Delarbre | |
3 | 1 | Yanick Delarbre | http://framapad.org/1OuW0Br2vr |
4 | 2 | Yanick Delarbre | |
5 | 2 | Yanick Delarbre | |
6 | 3 | Yanick Delarbre | h2. Agrégation en général |
7 | 3 | Yanick Delarbre | |
8 | 2 | Yanick Delarbre | Deux objectifs : |
9 | 2 | Yanick Delarbre | augmenter la bande passante |
10 | 2 | Yanick Delarbre | redondance (failover) |
11 | 2 | Yanick Delarbre | |
12 | 2 | Yanick Delarbre | Enjeux : |
13 | 2 | Yanick Delarbre | répartition efficace (utiliser au mieux la capacité totale) |
14 | 1 | Yanick Delarbre | résilience rapide et transparente en cas de panne (failover) |
15 | 1 | Yanick Delarbre | |
16 | 3 | Yanick Delarbre | h2. Agrégation locale |
17 | 3 | Yanick Delarbre | |
18 | 2 | Yanick Delarbre | Fonctionement master/slave : |
19 | 2 | Yanick Delarbre | les slaves sont les liens physiques (les différents points de sortie) |
20 | 2 | Yanick Delarbre | le master décide de la répartition du trafic entre les slaves |
21 | 2 | Yanick Delarbre | |
22 | 2 | Yanick Delarbre | Peut s'opérer à plusieurs niveaux : |
23 | 2 | Yanick Delarbre | niveau 1 : ex: utiliser plusieurs cannaux wifi ex: MiMo (hors-contexte pour nous) |
24 | 2 | Yanick Delarbre | niveau 2 "Bonding", norme IEEE http://en.wikipedia.org/wiki/802.1AX-2008 |
25 | 2 | Yanick Delarbre | niveau ?? MLPP |
26 | 2 | Yanick Delarbre | IPtables mark random |
27 | 2 | Yanick Delarbre | |
28 | 2 | Yanick Delarbre | Approches logicielles : |
29 | 2 | Yanick Delarbre | Agrego http://code.google.com/p/agrego/ |
30 | 2 | Yanick Delarbre | |
31 | 2 | Yanick Delarbre | Agrégation via un TUN : tout ce qui est écrit dans l'interface tun est gérée par agrego |
32 | 2 | Yanick Delarbre | |
33 | 2 | Yanick Delarbre | Agrégation |
34 | 2 | Yanick Delarbre | |
35 | 2 | Yanick Delarbre | |
36 | 2 | Yanick Delarbre | |
37 | 1 | Yanick Delarbre | |
38 | 2 | Yanick Delarbre | h3. Le chanel bonding |
39 | 3 | Yanick Delarbre | |
40 | 2 | Yanick Delarbre | http://downloads.sourceforge.net/project/bonding/Documentation/12%20November%202007/bonding.txt?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fbonding%2Ffiles%2FDocumentation%2F12%2520November%25202007%2F&ts=1317896490&use_mirror=heanet |
41 | 3 | Yanick Delarbre | |
42 | 2 | Yanick Delarbre | Il s'agit sous linux du module "bonding". Une interface virtuelle est présentée au système, elle utilise de manière sous-jacente N interfaces physiques, soit en load-balancing, soit en fallback. Il faut bien être conscient que l'agrégation doit-être mise en place des 2 côtés. |
43 | 1 | Yanick Delarbre | |
44 | 1 | Yanick Delarbre | |
45 | 1 | Yanick Delarbre | |
46 | 1 | Yanick Delarbre | Soit : |
47 | 2 | Yanick Delarbre | Fallback (mode 2) : une seule interface est utilisée, avec basculement en cas de panne ; |
48 | 2 | Yanick Delarbre | Load-balancing (inclut de base la redondance) |
49 | 3 | Yanick Delarbre | * mode 0 : round-robin |
50 | 3 | Yanick Delarbre | * mode 2 : toute communication avec un hôte pair (= adresse MAC du correspondant) utilisera une et une seule interface (choisie de manière déterministe par XOR). Les cartes utilisent leurs adresses MAC physiques (2 différentes). |
51 | 3 | Yanick Delarbre | * mode 3 : broadcast (inintéressant) |
52 | 3 | Yanick Delarbre | * mode 4 (802.3ad) load-balancing intelligent : prend en compte dynamiquement la capacité des liens et leur duplex (intéressant pour les liens sans-fil). Le switch doit supporter le mode 802.3ad. Nécessite un switch compatible |
53 | 3 | Yanick Delarbre | * mode 5 : une seule addr. MAC, on envoie en round-robbin, on ne reçoit que sur une carte |
54 | 3 | Yanick Delarbre | * mode 6 : 2 addr. MAC différentes : l-b en émission (idem que 5) et réception aussi, en émettant des réponses ARP pour assigner tel ou tel pair à telle ou telle interface |
55 | 3 | Yanick Delarbre | * Fallback simple : |
56 | 3 | Yanick Delarbre | * mode 1 |
57 | 2 | Yanick Delarbre | |
58 | 2 | Yanick Delarbre | La détection de panne se fait par le module de bonding, de deux manières différentes : |
59 | 2 | Yanick Delarbre | vérifier que la liaison de niveau 1 est "branchée" (MII), passif, ne génère pas de trafic réseau ; |
60 | 2 | Yanick Delarbre | vérifier que la passerelle répond (via une requête ARP) (actif, consomme de la BP). En mode 0 ou 2, les réponses ARP n'arrivent que sur un des esclaves si le switch ne prend pas soin de distribuer les réponses ARP sur tous les liens. |
61 | 1 | Yanick Delarbre | |
62 | 1 | Yanick Delarbre | |
63 | 2 | Yanick Delarbre | /!\ Il y aurait problème à utiliser du bonding avec DHCP (car correspondances MAC/IP instables ?, cf doc) (pas très grave, le DHCP ne se pose que pour les clients finaux). |
64 | 2 | Yanick Delarbre | |
65 | 2 | Yanick Delarbre | |
66 | 1 | Yanick Delarbre | |
67 | 2 | Yanick Delarbre | Les deux problématiques évoquées plus tôt nécessitent l'usage d'un protocole pour que les liens communiquent entre eux (s'informer de leur état, éventuellement de leur débitâ¦). |
68 | 2 | Yanick Delarbre | -> LACP (ieee, normalisé) PaGP (cisco, proprio). |
69 | 1 | Yanick Delarbre | |
70 | 1 | Yanick Delarbre | |
71 | 2 | Yanick Delarbre | |
72 | 3 | Yanick Delarbre | h2. Agrégation distante |
73 | 3 | Yanick Delarbre | |
74 | 2 | Yanick Delarbre | Métriques |
75 | 2 | Yanick Delarbre | propagation des métriques |
76 | 2 | Yanick Delarbre | répartition (paquet par paquet, destination/destination⦠?) |
77 | 2 | Yanick Delarbre | |
78 | 3 | Yanick Delarbre | h2. Point technique |
79 | 2 | Yanick Delarbre | |
80 | 2 | Yanick Delarbre | Tun et tap sont des cartes réseaux virtuelles. TAP opère au niveaux deux. TUN opère au niveaux 3. TAP est utiliser pour créer un réseau bridgé alors que TUN est utilisé pour le routage. |
81 | 1 | Yanick Delarbre | Source: http://en.wikipedia.org/wiki/TUN/TAP |
82 | 2 | Yanick Delarbre | |
83 | 3 | Yanick Delarbre | h3. Implémentation technique |
84 | 3 | Yanick Delarbre | |
85 | 2 | Yanick Delarbre | Utilisation d'IPTables pour router (détermine le next-hop à l'aide de la pondération). |
86 | 1 | Yanick Delarbre | Utilisation d'IPv6 et de sa gestion native d'aggrégation (à approfondir) |
87 | 1 | Yanick Delarbre | |
88 | 3 | Yanick Delarbre | h2. métrologie |
89 | 1 | Yanick Delarbre | |
90 | 2 | Yanick Delarbre | Que mesurer ? |
91 | 2 | Yanick Delarbre | On mesure au niveau du paquet. (et non d'un flot). Le paquet étant l'unité élémentaire traitée par la couche « réseau ». |
92 | 1 | Yanick Delarbre | Bande passante ? |
93 | 1 | Yanick Delarbre | Ping ? |
94 | 2 | Yanick Delarbre | Jitter ? //Variation du délai du transfert de l'information |
95 | 1 | Yanick Delarbre | |
96 | 2 | Yanick Delarbre | h2. Source |
97 | 3 | Yanick Delarbre | |
98 | 2 | Yanick Delarbre | http://igm.univ-mlv.fr/~dr/XPOSE2006/PICARD/definitions.htm |
99 | 2 | Yanick Delarbre | |
100 | 2 | Yanick Delarbre | |
101 | 2 | Yanick Delarbre | h2.Pourquoi mesurer la capacité et la charge des liens ? |
102 | 3 | Yanick Delarbre | |
103 | 2 | Yanick Delarbre | Le but est de pouvoir hiérarchiser les routes vers internet en fonction de leur capacité. Une mesure ultra-précise n'a pas forcément d'intérêt, en revanche, |
104 | 2 | Yanick Delarbre | |
105 | 2 | Yanick Delarbre | Deux choses : |
106 | 3 | Yanick Delarbre | * mesurer la capacité du lien: |
107 | 3 | Yanick Delarbre | * La bande passante du lien |
108 | 3 | Yanick Delarbre | * mesurer la charge du lien: |
109 | 3 | Yanick Delarbre | * La bande passante utilisé à l'instant t |
110 | 2 | Yanick Delarbre | |
111 | 2 | Yanick Delarbre | Il n'est pas dit que la prise en compte de la charge du lien soit pertinente : si le système a autorité sur la répartition de charge, la charge devrait être distribuée proportionellement à la capacité⦠|
112 | 2 | Yanick Delarbre | |
113 | 3 | Yanick Delarbre | h3. mesure de la capacité du lien |
114 | 3 | Yanick Delarbre | |
115 | 2 | Yanick Delarbre | *Passif naïf *, on se fie à ce que donne le driver (informations reportées par iwconfig, ou dans sysfs), à quelle vitesse se fait la synchro en somme. Problème, c'est très approximatif et c'est plus une borne supérieure qu'autre chose⦠|
116 | 3 | Yanick Delarbre | |
117 | 2 | Yanick Delarbre | *Passif estimé* on peut certainement prendre en compte le SNR d'une liaison, des articles sur le sujet : |
118 | 1 | Yanick Delarbre | http://citeseer.ist.psu.edu/viewdoc/download;jsessionid=D8D74970F81D4957F250F4357BB6CCC9?doi=10.1.1.15.5673&rep=rep1&type=pdf (dont approche adaptative) |
119 | 2 | Yanick Delarbre | |
120 | 2 | Yanick Delarbre | |
121 | 2 | Yanick Delarbre | -> Quel modèle utilisent les protocoles de routage mesh de type BATMAN/OLSR ? |
122 | 2 | Yanick Delarbre | |
123 | 2 | Yanick Delarbre | Une comparaison de l'efficacité des différentes méthodes : http://www.thlab.net/~thsalon/papers/wons09.pdf |
124 | 2 | Yanick Delarbre | |
125 | 2 | Yanick Delarbre | |
126 | 2 | Yanick Delarbre | |
127 | 2 | Yanick Delarbre | h1. Hypothèse de travail |
128 | 3 | Yanick Delarbre | |
129 | 2 | Yanick Delarbre | Tous les clients/bornes ont une IP public |
130 | 1 | Yanick Delarbre | La répartition de charge se fait de manière aléaloitre distribué de manière équiprobable. |
131 | 2 | Yanick Delarbre | La pondération (métrique), s'effectue sur la capacité total d'un lien (et non la capacité disponible d'un lien) |
132 | 2 | Yanick Delarbre | |
133 | 2 | Yanick Delarbre | h1. Fonctionnement général |
134 | 3 | Yanick Delarbre | |
135 | 2 | Yanick Delarbre | Simple: Sorties Internet de Rhizome relié par tunnel PPP (couche 2) vers une machine de Tetaneutral.net. La machine tetaneutral fait du routage BGP. Donc annonce BGP. |
136 | 2 | Yanick Delarbre | Réel: tunnel transporte IP(passerelle dans le coeur tetaneutral)+UDP/TCP+IP(paquet original). Machine fait toujours du BGP. |
137 | 2 | Yanick Delarbre | |
138 | 2 | Yanick Delarbre | h1. Réseau de test |
139 | 3 | Yanick Delarbre | |
140 | 2 | Yanick Delarbre | Réseau N: 192.168.0./24& |
141 | 2 | Yanick Delarbre | |
142 | 2 | Yanick Delarbre | |
143 | 2 | Yanick Delarbre | ToDo: regarder comment fonctionne BATMAN |
144 | 2 | Yanick Delarbre | Questions auxquelles il nous faut répondre concernant BATMAN: |
145 | 2 | Yanick Delarbre | De quelle manière BATMAN pondère-t-il les liens radio ? |
146 | 2 | Yanick Delarbre | BATMAN conserve-t-il une liste des routes possibles vers une adresse (ce qui nous serait utile pour faire du load-balancing) ou seulement la meilleure ? |
147 | 2 | Yanick Delarbre | BATMAN fait-il du load-balancing (pas à ma connaissance mais à creuser) |
148 | 2 | Yanick Delarbre | Comment fonctionne le routage LAN (radio/filaire) -> WAN (sachant que BATMAN a une gestion de l'annonce des points de sortie vers internet) ? Les liens vers internet (ex: xDSL) sont-ils pondérés en eux-même ou seul le réseau radio est pris en compte pour trouver le meilleur point de sortie vers internet ? |
149 | 2 | Yanick Delarbre | |
150 | 2 | Yanick Delarbre | h1. Annexe : différents liens sur le fonctionnement 802.11x |
151 | 3 | Yanick Delarbre | |
152 | 1 | Yanick Delarbre | Des vitesses de synchro et de restransmission, cas pratique : http://mobilesociety.typepad.com/mobile_life/2008/05/sniffing-wifi-p.html |