3. Définition :
iFogSim est un simulateur d’environnements de Fog et d’IoT.C’est une
extension du simulateur d’environnements de Cloud : CloudSim.
iFogSim est conçu pour pouvoir évaluer des stratégies de gestion des
ressources applicables aux environnements de Fog et d’IoT en ce qui
concerne leur impact sur :
la latence
la consommation d’énergie
la congestion du réseau
les coûts opérationnels.
4. Principe de fonctionnement :
Afin de réaliser une simulation dans iFogSim, les utilisateurs spécifient:
l’infrastructure physique de système (i.e. capteurs, actionneurs, nœuds de Fog,
liens réseaux, etc.)
le scénario (i.e. services d’IoT, flux de données, etc.)
leurs stratégies de placement et/ou d’ordonnancement de services, et le temps
maximal de la simulation
iFogSim produit la simulation (selon les objectifs des utilisateurs).
6. Architecture iFogSim :
Les entités physiques : ce sont les modèles des équipements physiques trouvés
dans une infrastructure de Fog (ex. serveurs, capteurs, actionneurs etc.).
7. Architecture iFogSim :
FogDevice : cette entité modélise les nœuds de Fog (ex. les switchs, les routeurs, les stations
de base, les passerelles, etc). Elle spécifie les caractéristiques matériels d’un nœud fog
comme le modèle du processeur , la taille de la Ram , la capacité du stockage et la bande
passante
8. Architecture iFogSim :
Sensor (capteur) : cette entité modélise les différents capteurs déployés dans
l’infrastructure simulée, elle spécifie les attributs d’un capteur allant de sa connectivite
réseau jusqu’aux données capturées .
9. Architecture iFogSim :
Actuator (actionneur ) : cette entité modélise les actionneurs et les effets de leur actions
sur l’environnement simule. Elle spécifie les attributs d’un actionneur comme sa
connectivite,sa latence et la passerelle associée.
10. Architecture iFogSim :
Les Entités logiques : ce sont des modèles représentent les éléments logiques dans
un environnement informatique (exp données ,services , traitement, etc. ).
11. Architecture iFogSim :
Tuple : cette entité représente l’unité fondamentale des communications entre les entités
physiques. Un Tuple est caractérisé par son type ,le nœud source, le nœud destinataire, la
capacité du traitement de données demandes et la taille des donnes encapsulées.
12. Architecture iFogSim :
AppModule: cette entité représente les unités de traitement de scenario simule qui sont les
instances de services de l’IOT. Ces instances de services sont déployés dans les nœuds de
fog et les centres de données, Pour chaque donnée d’entrée (Tuple), une AppModule
s’occupe de son traitement et génère des données de sortie qui sont envoyées par la suite à
une ou à plusieurs AppModules
13. Architecture iFogSim :
AppEdge : cette entité représente les dépendances de données existantes entre deux
AppModules (producteur, consommateur de données). une AppEdge spécifie le mode de
production de données parmi les deux modes possibles ( périodique ou événementiel )
14. Architecture iFogSim :
Les entités de gestion de ressources : ce sont des modèles représentant les stratégies de
gestion de ressources physiques et logiques dans iFogSim (ex. allocation, ordonnancement,
migration, etc.).
15. Architecture iFogSim :
AppModule Placement : cette entité définit un ensemble de méthodes permettant de gérer
le placement des AppModules dans l’infrastructure simulée. Ainsi, les utilisateurs utilisent
ces méthodes pour définir leur stratégie de placement des AppModules afin d’optimiser un
ou plusieurs critères(la latence, la consommation d’énergie ,la congestion du réseau
,les coûts opérationnels)
16. Architecture iFogSim :
AppModule Scheduler : cette entité définit un ensemble de méthodes pour gérer
l’ordonnancement des AppModules dans un nœud de Fog ou un centre de données. Les
utilisateurs utilisent ces méthodes pour définir leur stratégie d’ordonnancement des
AppModules.
17. Architecture iFogSim :
AppModule Mapping : cette entité définit pour chaque instance de service d’IoT, le nœud
de Fog ou le centre de données qui l’héberge.
18. Les stratégies de placement:
Deux stratégies de placement de module d’application :
Placement uniquement dans le cloud
Placement dans le Fog
19. Les stratégies de placement:
1. Stratégie « cloud »:
La stratégie de placement Cloud est basée sur la mise en œuvre
traditionnelle d’applications dans le Cloud où tous les modules
d’une application s’exécutent dans des centres de données.
20. Les stratégies de placement:
2. Stratégie « Fog »:
La stratégie de placement Fog favorise le déploiement de modules
d’application a proximité du réseau.
les périphériques proches du réseau, tels que les routeurs et les points
d’accès, peuvent ne pas disposer d’une puissance de calcul suffisante
pour héberger tous les operateurs de l’application.
Dans cette situation, la stratégie parcourt les périphériques Fog
vers le Cloud et tente de placer les operateurs restants sur des
périphériques alternatifs.
. Ce simulateur est composé : (i) d’un ensemble d’entités permettant de modéliser les équipements physiques de l’infrastructure, (ii) un ensemble d’entités permettant de modéliser les éléments logiques du scénario simulé (ex. les données et les instances des services de l’IoT), et (iii) un ensemble d’entités permettant de gérer les ressources de traitement dans les nœuds de Fog et dans les centres de données,
L'algorithme de placement de périphérie parcourt tous les chemins de la feuille à la racine dans la topologie du réseau physique et place les modules sur chacun de ces chemins. Pour chaque chemin, l'algorithme itère de la feuille (périphérique le plus au sud) - périphérique typiquement en périphérie - à la racine (périphérique le plus au nord) - généralement le cloud - et place progressivement des modules sur eux. Pour chaque périphérique d'un chemin, les modules qui peuvent y être placés sont identifiés. Un module 𝜃 ne peut être placé sur un périphérique d que si tous les autres modules qui devraient être placés au sud de 𝜃 (prédécesseurs) sont déjà placés dans le chemin de la feuille à la racine.
Une fois les modules à placer identifiés, l'algorithme essaie de les placer un par un sur l'appareil. Considérons le cas du module 𝜃 placé sur l'appareil d. L'algorithme vérifie d'abord si une instance de 𝜃 est déjà placée sur d (car elle peut faire partie d'un autre chemin de la feuille à la racine). Si tel est le cas, ces instances sont fusionnées ensemble et placées sur d si elles peuvent accueillir les instances fusionnées. Sinon, l'algorithme recherche les périphériques au nord de d pour placer l'instance fusionnée. Cependant, si ni le périphérique d ni aucun périphérique au nord de d n'a une instance de 𝜃, le module est placé sur d. Dans le cas où un périphérique au nord de d avait une instance de 𝜃, il serait traité par les étapes précédentes de l'algorithme dans une itération ultérieure. Comme iFogSim suppose qu'un module m placé sur le périphérique d gérera tous les tuples entrants des périphériques situés au sud de d dans la hiérarchie, plusieurs instances d'un module sont fusionnées et migrées vers le nord par cette stratégie de placement (comme indiqué dans les paragraphes précédents). Considérez les périphériques dp et dc où dp est le parent de dc dans la topologie et les deux instances hôtes du même module m. Dans un tel cas, tout trafic entrant pour le module m sur dc y serait traité et non envoyé vers le nord.