Tolérance au panne dans le Cloud

Beaucoup de travail a été fait dans le domaine de la tolérance aux pannes pour le cloud computing. Mais en raison de son service basé sur la virtualisation et Internet fournissant un comportement de tolérance de panne dans le cloud computing est encore un grand défi. De nombreux chercheurs ont donné diverses techniques et stratégies de tolérance de panne dans différents articles.

Figure2.png

Figue. 1. les différentes couches dans un Cloud

Comme la montre la figure 1, le Cloud compose de différentes couches qui peuvent être affectées à différents types de défauts. Donc, ces couches nécessite différents niveaux de tolérance au pannes techniques afin de fournir un service sans faille. Les défaillances qui se produisent dans le Cloud Computing peuvent être classés en deux catégories à savoir :

  1. Pannes de données: Ce type implique des échecs en raison de la corruption des données, les données manquantes à la source et d’autres failles dans les données.
  2. Les échecs de Calcul: Il implique tous les types de défaillances matérielles ou d’infrastructure comme défectueux ou lente machines virtuelles, l’accès exception de stockage, etc.

La plupart des applications hébergées par le Cloud sont en temps réel Calcul Haute Performance (HPC) systèmes qui nécessitent plus haut niveau de tolérance aux pannes, la plupart des défauts dans les Clouds ​​se produisent en raison de pannes matérielles, principalement dans les processeurs, disque dur, les prises de circuits intégrés, et de la mémoire. Autre que les pannes matérielles, il y a d’autres défauts tels que des défauts de logiciel causant un échec de l’application et de réseau dus à une surcharge du serveur, la congestion du réseau, etc.

Dans un réseau Cloud, la gestion des pannes dépend de deux paramètres importants à savoir Recovery Point Objective (RPO) et Recovery Time Objective (RTO) [1]. Le RPO métrique définit le montant de la perte de données au cours d’une faute alors que RTO détermine le minimum de temps pour récupérer de défauts. Un Cloud sain aura des valeur minimale pour les deux  paramétres RPO et RTO.

Il y a principalement deux politiques standards Fault Tolerant (FT) disponibles pour des applications en temps réel hébergées dans le Cloud savoir Politique de tolérance aux pannes proactive et Politique de tolérance aux pannes réactive. Basé sur ces politiques de tolérance de pannes, différentes techniques sont utilisées pour fournir la tolérance de panne.

Tolérance aux pannes réactive

Les politiques de tolérance de panne réactifs est de réduire l’effet des défaillances sur l’exécution de l’application lorsque la panne survient efficacement. Il existe différentes techniques qui sont basés sur ces politiques comme points de reprise et le redémarrage (Checkpointing/Restart), Replication, Re-soumission (Task Resubmission)

Tolérance aux pannes proactive

Le principe de politiques de tolérance de panne proactives est d’éviter la reprise de défauts, les erreurs et les échecs en prédisant et de remplacer de manière proactive les composants suspects avec d’autres composants qui fonction. Certaines des techniques qui sont basées sur les politiques de tolérance aux pannes proactive sont Fault Tolerance proactive en utilisant la migration préemptive (Preemeptive Migration), rajeunissement de logiciel (Software Rejuvenation), l’équilibrage de charge, etc.

La gestion des ressources dans le Cloud (ordonnancement/planification)

Dans cette section on découvre la nécessité d’une planification efficace à haute tolérance de panne pour les tâches en temps réel dans les Cloud.

Le Cloud en pay-as-you-go offre aux utilisateurs l’illusion de ressources informatiques illimités dont l’approvisionnement est élastique selon la demande des utilisateurs [2]. la problématique est de défaillance des ressources élevé en raison de la fonctionnalité et la complexité croissantes des grands systèmes. Sensiblement, de nombreuses applications, par exemple, les transactions financières et le calcul scientifique, sont avec la nature en temps réel, où l’exactitude ne dépend pas seulement sur les résultats de calcul, mais aussi sur les instants où ils deviennent disponibles.

L’ordonnancement est une approche efficace pour atteindre la tolérance de panne en allouant des copies multiples de tâches sur les différents cas de calcul. Parmi les recherches sur la planification à tolérance de panne, le modèle primaire sauvegarde primary-backup (PB) qui est un régime populaire dans laquelle chaque tâche dispose de deux exemplaires, à savoir le primaire et la sauvegarde, l’exécution sur deux instances de calcul différentes pour la tolérance de panne [2]. En conséquence, il est difficile pour les algorithmes existants de planification à tolérance de pannes de profiter pleinement de Cloud [2].

Dans l’article [2] le Cloud est caractérisé par un ensemble infini d’hôtes avec différentes puissance de traitement qui est mesurée par million d’instructions par seconde MIPS. Notez que y a des hôtes dans le Cloud est actif et les autres inactif, et sur chaque hôte contient plusieurs machines virtuelles.

Figure4.png

Figure 2: Architecture d’ordonnancement

L’ordonnanceur est constitué d’un dispositif de commande de copie de sauvegarde, un dispositif de commande en temps réel, et un contrôleur de ressources.

Lorsqu’une tâche arrive, sa copie de sauvegarde est produit par le dispositif de commande de copie de sauvegarde. Ensuite, le contrôleur de copie de sauvegarde fournit les deux copies de la tâche au contrôleur en temps réel qui est chargé de déterminer si les deux copies peuvent être terminées avant son échéance. Dans le cas contraire, le dispositif de commande en temps réel en informe le contrôleur de ressources pour ajouter de nouvelles ressources. En outre, le contrôleur de ressources surveille l’état des ressources. Lorsque le système est en lightworkload où certaines machines virtuelles garder inactif pendant une longue période, le contrôleur de ressources décide si certaines machines virtuelles doit être annulée pour améliorer l’utilisation des ressources.

Si le primaire d’une tâche se termine avec succès, les informations le succès sera envoyé au contrôleur de copie de sauvegarde. Ensuite, le contrôleur de copie de sauvegarde informe la VM où la sauvegarde de la tâche est attribuée à annuler l’exécution de la sauvegarde. D’autre part, quand un hôte échoue le mécanisme de détection de défaut permet de détecter la défaillance dont les informations seront ensuite signalé au contrôleur de copie de sauvegarde. Dans cette situation, le contrôleur de copie de sauvegarde n’a pas informé la VM pour annuler l’exécution de sauvegardes.

L’objectif principal de cette étude dans l’article [2] est d’accueillir autant de tâches que possible, et d’améliorer l’utilisation des ressources du système, tout en adoptant le modèle à tolérance de pannes PB.

FESTAL “Fault-Tolerant Elastic Scheduling Algorithm” qui est un mécanisme de provisionnement des ressources élastique dans le contexte de la tolérance aux pannes. C’est un mécanisme de provisionnement des ressources élastique qui est capable d’ajuster de façon dynamique la fourniture de ressources sur la base de la demande de ressource.

Références

[1] Ganesh, A. and Sandhya, M. and Shankar, S. (2014)
A study on fault tolerance methods in Cloud Computing,
Advance Computing Conference (IACC), 2014 IEEE International 844-849

[2] Ji Wang and Weidong Bao and Xiaomin Zhu and Yang, L.T. and Yang Xiang (2015)
FESTAL : Fault-Tolerant Elastic Scheduling Algorithm for Real-Time Tasks in Virtualized Clouds,
Computers, IEEE Transactions on, 2545-2558

Par défaut

Votre commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l’aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s