Ce projet est réalisé dans le cadre de la mineure SDCI en dernière année de l'école d'ingénieur INSA en spécialité systèmes distribués et big data.
- Déployer dynamiquement et de façon transparente des fonctions de réseau virtuelles (VNF) permettant de répondre aux besoins fonctionnels et/ou non fonctionnels d’applications distribuées relevant d’une activité de l’Internet des objets (IoT) en appliquant les concepts et techniques relevant de la virtualisation de fonctions de réseau (NFV) et des réseaux pilotables par le logiciel (SDN)
- Développer une approche de gestion autonome de la mise en œuvre des VNF ciblées via le concept de l’Autonomic Computing (AC)
Nous ciblons une activité de supervision/intervention à distance sur différentes zones dotées de capteurs / actionneurs, par le biais d’applications
En cas d'incident dans une zone du trafic supplémentaire est généré par ses capteurs / actionneurs. Ceci peut entrainer la saturation de la gateway intermédiaire (GI) générant ainsi une baisse de performances incompatible avec les besoins en QoS des applications
Une phase d'adaptation est alors nécessaire pour rétablir les performances. Plusieurs stratégies peuvent être adoptées :
- Déployer une seconde gateway sous forme de VNF et rediriger le trafic provenant de la zone 1 (ou des zones 2 et 3) vers cette gateway.
- Déployer une VNF d'ordonnancement différencié priorisant le trafic issu de GF1.
- Supprimer les flux de données en provenance de la zone 2 et 3.
- Déployer d'un loadbalancer sous forme de VNF.
Hypothèse sur l'infrastructure IT
- GI, GF et DC sont connectés via un réseau grande distance (WAN) géré par un opérateur dont la portée d’action inclut : les nœuds internes du réseau (switch), les nœuds midlleware (GI et GF) et le DC
- Un orchestrateur de VNF (VNF-ORCH) est connecté au WAN : il permet de déployer des VNF sur le DC et de gérer leur cycle de vie.
- Le WAN est doté de capacités SDN :
- Ses nœuds internes sont des switch SDN programmables via Open Flow
- Il inclut un contrôleur SDN interagissant avec les switch SDN via Open Flow
- Plateforme d’émulation de réseau : ContainerNet
- Contrôleur SDN : RYU
- MANO standardisé ETSI NFV : OSM
- Middleware IoT/M2M en NodeJS (see Middelware)
Mettre en place l'adaptation requise lorsque la gateway intermédiaire est saturée, suivant le cadre de l’Autonomic Computing
Notre groupe avait pour mission de monitorer la gateway intermédiaire pour surveiller sa charge à partir de métriques systèmes telles que la charge du CPU.
Nous devions ensuite, en cas de dégradation des performances, déployer une nouvelle gateway et rediriger le trafic en provenance de la zone 1 vers cette dernière. Le trafic de la zone 2 et 3 continuant d'utiliser la gateway initiale.
Nous disposons d'un Mano qui nous expose un service permettant de déployer et d'arrêter des VNF dans un datacenter via des requêtes sur son API REST.
Nous avons également un contrôleur SDN qui nous permet de mettre à jour les tables SDN des différents switch de notre réseau via son API REST.
Les interactions entre notre general controller, le MANO et le SND controller sont résumés dans le diagramme de structure composite suivant
Diagramme de structure composite
Pour le monitoring nous proposons de déployer la VNF de monitoring au démarage du general controller. Une fois que celui ci à eu la confirmation que la VNF est correctement déployé, il l'interooge periodiquement pour recupérer les informations système de la gateway intermediaire. Il verifie à chaque iteration que le système n'est pas en surcharge.
Diagramme de séquence du monitoring
Pour l'adaptation, notre general controller devra demander le déploiment d'une nouvelle gateway dans le datacenter via l'API du MANO. Si ce deploiment s'est bien déroulé, il demande la redirection du trafic de la zone 1 en direction de cette VNF grace à l'API du controlleur SDN.
Diagramme de séquence de l'adpatation
Nous avons choisi de déployer le réseau suivant
Le réseau bleu est le réseau émulé mininet. Nous avons choisi de représenter les différentes zones avec un switch simulant un LAN.
Le réseau vert représente le réseau VLAN Docker reliant tous nos containers. Il est utilisé pour assurer la communication entre :
- les nœuds middleware et le metadata serveur
- le GC, le Mano, le contrôleur SDN et les VNFs
Pour le déploiement des différents nœuds middleware, nous avons créé un unique Dockerfile permettant de créer l'image associée au nœud. Celui-ci récupère d'identifiant de l'instance à déployer en variable d'environnement et lance un script de démarrage spécifique en fonction du type d'instance lorsque le container est lancé.
FROM ubuntu:trusty
ARG SCRIPT
ARG NODE_VERSION=14
ENV INSTANCE_ID=''
...
ADD $SCRIPT .
...
ENTRYPOINT sh /componnent/$SCRIPT && /bin/shExtrait du Dockerfile
Le scrpit de démarrage est chargé de récupérer la configuration de l'instance sur le matadata serveur pour pouvoir lancer le service avec les bons paramètres.
curl -o conf.json metadata_server/$INSTANCE_ID
LOCAL_NAME=`cat conf.json | jq '.local_name'`
LOCAL_PORT=`cat conf.json | jq -r '.local_port'`
LOCAL_IP=`cat conf.json | jq '.local_ip'`
FILE_URL=`cat conf.json | jq -r '.file_URL'`
curl -LO $FILE_URL
node server.js --local_ip $LOCAL_IP --local_port $LOCAL_PORT --local_name $LOCAL_NAMEExemple de script de démarrage pour le serveur start_server.sh
Nous avons réalisé le metadata serveur en Node.js. Il renvoie la configuration de l'instance à déployer suite à une requête GET sur l'identifiant de l'instance souhaitée.
app.get('/:id', function(req, res) {
var id = req.params.id;
var conf_instance = config[id];
if (conf_instance)
res.status(E_OK).send(JSON.stringify(conf_instance));
else
res.sendStatus(E_NOT_FOUND);
});Extrait de metadata_server.js
L'ensemble des configurations est stocké dans un fichier général de configuration json.
{
...
"gwf_1": {
"local_ip": "10.1.0.11",
"local_port": 8282,
"local_name": "gwf_1",
"remote_ip": "10.1.0.10",
"remote_port": 8181,
"remote_name": "gwi",
"file_URL":"https://homepages.laas.fr/smedjiah/tmp/mw/gateway.js"
},
...
}Extarit de config.json
Nous avons choisi de ne pas utiliser le squelette de general controller fourni, mais de développer nous-mêmes un prototype plus simple en Python afin de nous faciliter le développement et les tests.
Notre stratégie de monitoring est pour l'instant assez simple. Lorsque notre VNF reçoit une requête GET de la part du general controller, elle interroge la gateway sur son endpoint /health et retourne la réponse reçue au GC. Cette stratégie nous permet de déplacer le traitement de la réponse au niveau du GC celui-ci peut donc choisir à quel rythme monitorer, ce qui peut potentiellement réduire la charge sur la gateway.
app.get('/monitor', function(req, res) {
request({method: 'GET', uri: `http://10.1.0.10:8181/health`}, (error, response, body) => {
if (!error && response.statusCode == 200){
res.send(body);
} else {
res.send(error);
}
});
});Extarit de monitor.js
Pour deployer la VNF, nous utilsons l'API REST de vim-emu
def start_monitoring():
# URL to add new vnf
url = 'http://127.0.0.1:5001/restapi/compute/dc1/vnf_monitor'
headers = {'Content-type': 'application/json'}
d = {"image":"vnf_monitor:0.2", "network":"(id=vnf_monitor,ip=10.1.0.100/24)"}
r = requests.put(url, headers = headers, data = json.dumps(d))
return r.status_code, r.json()Extarit de controller.py
Nous avons choisi de baser notre monitoring sur la métrique currentLoadSystem car c'est celle qui variait le plus rapidement lorsque nous simulions une charge sur la gateway durant nos tests. Lorque celle-ci dépasse le seuil fixé, nous devons déployer notre VNF d'adaptation.
La première étape de l'adaptation est de déployer une nouvelle gateway intermédiaire dans le datacenter en utilisant l'API REST de vim-emu. L'image de la gateway intermédiaire précédemment construite a dû être légèrement modifiée pour qu'elle convienne aux exigences de vim-emu :
- Le serveur node.js doit tourner en background
- Les srcipts de démarage et d'arrêt de la VNF doivent être passés en variable d'environnement dans le Dockerfile.
Nous devons ensuite rediriger le trafic de la gateway final de la zone 1 en direction de la gateway intermédiaire vers notre VNF.
Nous avons pris la décision d'identité ces flux avec uniquement les adresses IP source et destination. En effet, le seul trafic circulant sur notre réseau entre ces instances est le trafic applicatif que nous souhaitons rediriger. Si ce n'était pas le cas, nous aurions également dû utiliser les numéros de port pour identifier ces flux.
Nous devons donc :
- modifier l'addresse IP destination des paquet provennat de
GF1en direction deGI(aller) - modifier d'addresse IP srouce des paquets provennant de la
GI_VNFen direction en direction deGF1(retour)
Cela est réalisé en ajoutant des flow dans la table SDN du switch 2 à l'aide de l'API de controller SDN de la façon suivante (pour l'aller)
curl -X POST -d '{
"dpid": 2,
"table_id":0,
"priority":11111,
"match":{
"nw_src": "10.1.0.11",
"nw_dst": "10.1.0.10",
"dl_type": "2048",
},
"actions":[
{
"type": "SET_FIELD",
"field": "ipv4_dst",
"value": "10.1.0.60"
},
{
"type": "OUTPUT",
"port": "NORMAL"
}
]
}' http://localhost:8080/stats/flowentry/addExtrait de redirect_gwi_to_vnf.sh
Pour notre démonstration, nous souhaitons
- Lancer notre topologie avec mininet
- Tester la communication entre la gateway finale 1 et la gateway intermédiaire
- Démarrer notre general controller et voir que le monitoring se lance.
- Générer un fort trafic depuis la gateway finale 1 vers la gateway intermédiaire
- Observer que le general controller détecte une dégradation des performances sur la gateway et lance une nouvelle gateway intermédiaire dans le data center.
- Observer que le trafic généré est redirigé et n'arrive plus à la gateway intermédiaire, mais à la VNF.
- Vérifier que ces opérations ont été transparentes au niveau applicatif.
démo pour les points 4, 5, 6 et 7
- Actuellement, lors de la redirection du trafic, le trafic de retour entre la VNF gateway intermédiaire et la gateway finale est addresé à la gateway intermédiaire au niveau MAC. Nous n'avons pas pu debuger ce problème qui fait que la GWI reste saturée même après la redirection de trafic effectuée.
- Il nous faudrait ensuite ajouter une stratégie pour revenir au cas nominal en supprimant la VNF déployée une fois que le trafic redevient normal.
- Il pourrait également être intéressant de monitorer la VNF déployer pour s'assurer que celle-ci ne soit pas non plus en surcharge et possiblement déployer une nouvelle gateway intermédiaire avec un load balancer en cas de problème.
Ce projet a été l'occasion de nous familiariser avec les concepts de l'autonomus computing dans un contexte IoT où les applications ont des besoins en QoS et génèrent un trafic variable. Nous avons pu développer et déployer dynamiquement des VNFs en charge de surveiller l'état d'instances sur le réseau et d'assurer des performances suffisantes aux applications. Grâce à SDN, nous avons pu dynamiquement modifier le routage au sein de notre réseau de manière transparente pour les applications.
Nous aurions cependant aimé pouvoir approfondir la partie SDN pour pouvoir définir plus finement les flux de communications et aller plus loin dans les stratégies mise en œuvre pour s'adapter à la dégradation de l'état du middleware.