Problématique de sûreté de fonctionnement dans les clouds

Problématique de sûreté de fonctionnement dans les clouds 

Le monde de l’informatique de nos jours est caractérisé par la rapidité de développement, le parallélisme et de la diversité des tâches à effectuer par les applications et services. Comme tout système informatique, le cloud n’est pas exempt des problématiques de sûreté de fonctionnement qu’il est nécessaire de traiter. Nous présentons dans cette partie les termes et concepts du domaine de la sûreté de fonctionnement tels que définis dans par [Laprie 1995]. Nous citons plus particulièrement les attributs, les entraves et les moyens de la sûreté de fonctionnement. Nous décrivons également la problématique de sûreté de fonctionnement et plus particulièrement de détection d’erreurs ou d’autres anomalies dans un cloud.

La sûreté de fonctionnement 

La sûreté de fonctionnement d’un système est la propriété qui permet à ses utilisateurs de placer une confiance justifiée dans le service qu’il leur délivre (qui peut être également un service cloud). Le service délivré par un système est son comportement tel que perçu par son, ou ses utilisateurs ; un utilisateur est un autre système (humain ou physique) qui interagit avec le système considéré. L’exécution d’un système est perçue par son, ou ses utilisateurs comme une alternance entre deux états du service par rapport à l’accomplissement de la fonction du système : service correct (la fonction du système est accomplie) et service incorrect (la fonction du système n’est pas accomplie). D’autres définitions de base vont avec les termes qui viennent d’être définis. Il est important de définir que le service délivré est le comportement du système tel que perçu par un utilisateur. Le comportement du système est ce que le système fait. Ce qui lui permet de faire ce qu’il fait est sa structure. Le comportement d’un système et sa structure peuvent avoir des états. Un état est une condition d’être par rapport à un ensemble de circonstances. Les autres systèmes ayant interagi ou interféré, interagissant ou interférant, ou susceptibles d’interagir ou d’interférer avec le système considéré composent l’environnement du système. Finalement, la sûreté de fonctionnement est régie selon trois notions : ses attributs définissent un fonctionnement sûr, les entraves décrivent les circonstances indésirables (correspondent aux causes ou résultats de la non sûreté de fonctionnement du système), et les moyens contribuent à assurer un fonctionnement sûr en dépit des entraves.

Attributs de la sûreté de fonctionnement

La sûreté de fonctionnement peut être vue selon des propriétés différentes mais complémentaires qui définissent ses attributs :
— le fait d’être prêt à l’utilisation conduit à la disponibilité,
— la continuité du service délivré conduit à la fiabilité,
— le fait d’être sans danger pour l’environnement conduit à la sécuritéinnocuité,
— la non-occurrence de divulgations non-autorisées de l’information à des personnes non-autorisées conduit à la confidentialité,
— la non-occurrence d’altérations inappropriées de l’information conduit à l’intégrité,
— l’aptitude aux réparations et aux évolutions conduit à la maintenabilité. La disponibilité, la confidentialité, et l’intégrité vis-à-vis des actions autorisées constituent la sécurité-immunité.

Entraves à la sûreté de fonctionnement 

On distingue trois types d’entraves : les défaillances, les erreurs et les fautes. Une défaillance survient lorsqu’un service délivré dévie de l’accomplissement de sa fonction. Lorsqu’un service délivré dévie de l’accomplissement de sa fonction, il y a défaillance du système (ou défaillance). Une erreur est la partie de l’état d’un système qui est susceptible d’entrainer une défaillance. Par propagation, plusieurs erreurs peuvent être créées avant qu’une défaillance ne survienne. La cause adjugée ou supposée d’une erreur est une faute. Les sources des fautes sont extrêmement diverses. Elles peuvent être classées selon cinq points de vue : leur cause phénoménologique, leur nature, leur phase de création ou d’occurrence, leur situation par rapport aux frontières du système et leur persistance. Nous ne décrivons pas ici les fautes qu’il est possible de distinguer dans chacun de ces points de vue. La considération simultanée des points de vue donne des fautes combinées. Un exemple de faute combinée est le suivant : une faute peut être due à l’homme, accidentelle (non intentionnelle), introduite lors du développement du système, interne (qui ne résulte pas des interactions du système avec son environnement) et temporaire (liée à des conditions internes ou externes ponctuelles, et donc présente pour une durée limitée). Certaines combinaisons ne sont toutefois pas vraisemblables (par exemple, une faute ne peut pas être physique et intentionnelle). Cinq étiquettes permettent de regrouper l’ensemble des fautes combinées vraisemblables : les fautes physiques, les fautes de conception, les fautes d’interaction, les fautes logiques malignes et les intrusions.

Moyens pour la sûreté de fonctionnement

Afin qu’un système soit sûr de fonctionnement en dépit des potentielles entraves, des moyens pour la sûreté de fonctionnement doivent être mis en œuvre et utilisés de manière combinée. Ils sont au nombre de quatre. Tout d’abord la prévention des fautes qui vise à empêcher l’occurrence ou l’introduction de fautes dans un système. Elle relève de l’ingénierie générale des systèmes. Ensuite la tolérance aux fautes qui permet à un système de délivrer sa fonction en dépit des fautes existantes. La tolérance aux fautes est mise en œuvre par le traitement d’erreur et par le traitement de fautes. Le traitement d’erreur est destiné à éliminer les erreurs, si possible avant qu’une défaillance ne survienne. Le traitement de faute est destiné à éviter qu’une ou plusieurs fautes ne soient activées à nouveau. L’élimination des fautes œuvre à réduire la présence des fautes aussi bien en nombre qu’en sévérité de leurs impacts potentiels sur le fonctionnement du système. Enfin, la prévision des fautes vise à estimer la présence, la création et les conséquences des fautes. Nos travaux considèrent en particulier la tolérance aux fautes par traitement d’erreur. Ce traitement fait appel à trois primitives qui sont la détection d’erreur qui vise à déceler un état erroné d’un système, le diagnostic qui estime les dommages créés par les erreurs détectées, et le recouvrement d’erreur qui substitue un état exempt d’erreur à l’état erroné. Nous focalisons principalement nos travaux sur la détection d’erreur. Dans les systèmes ou applications complexes, la constatation de défaillance par l’administrateur du système n’est pas directe. Elle peut nécessiter plusieurs analyses concernant la caractérisation du comportement du système. Ainsi nous travaillons en particulier à détecter des erreurs mais aussi les manifestations de défaillances dans des données liées au système étudié (par exemple dans des compteurs de performance système caractérisant l’utilisation des différentes ressources du système). Nous appelons cette détection détection d’anomalie. Une anomalie se traduit par une variation significative de ces données par rapport à une situation de fonctionnement normal.

Détection d’anomalie dans les services clouds

Parmi les nombreuses problématiques issues du domaine de la sûreté de fonctionnement des clouds, nous traitons dans ce manuscrit une problématique liée aux attributs de disponibilité et de fiabilité. Ces propriétés sont en effet primordiales pour les fournisseurs de services cloud, notamment de par leur engagement de service à la demande. Assurer ces deux propriétés pour des services à la fois différents, en allocation dynamique et pour des utilisateurs aux demandes hétérogènes (ils peuvent avoir différentes attentes de disponibilité ou bien différents besoins en termes de ressources) représente un défi pour les fournisseurs. Ce défi est d’autant plus important que les utilisateurs demandent à ce que les services rendus soient au moins aussi sûrs de fonctionnement que le déploiement local d’applications traditionnelles le serait.

Caractéristiques de la détection d’anomalies dans les services cloud

Nous identifions trois caractéristiques au défi de la détection d’anomalies dans des services cloud :
— le type d’anomalies à détecter,
— le type de données traitées,
— les moyens humains et financiers mis en œuvre.

Type d’anomalie à détecter. À l’heure des services cloud toujours plus variés, il est difficile d’assurer qu’un service est exempt de faute. La concurrence mondiale dans le domaine amène à des services mis sur le marché alors que les phases de tests n’ont pas nécessairement pu tester toutes les fonctions à délivrer ou bien tester la compatibilité des services avec le matériel (dans le cas d’un matériel virtualisé, la compatibilité à assurer est la même que dans le cas où il ne l’est pas). Des défaillances peuvent donc potentiellement survenir. Ces défaillances peuvent avoir pour cause des fautes aussi diverses que les fautes rencontrées dans les systèmes traditionnels mais également des fautes liées à la virtualisation des services et à l’orchestration de ces services.

Données traitées. La détection d’anomalies dans un système informatique peut être menée par exemple par l’analyse de la mémoire du système, l’introspection de données reçues ou émises (sur un réseau ou sur un bus par exemple), l’étude des processus actifs ou l’analyse de données de surveillance système obtenues par le biais de sondes ou de logs. En particulier, le traitement de ces données peut permettre de détecter la présence d’anomalies dans des clouds. Du point de vue fournisseur, ces données sont disponibles en masse pour tous les services de leur centre de données. L’ère des masses de données n’est pas nouvelle, mais de nos jours, elle relève surtout de la numérisation de chacune des données disponibles d’un système et de ses sous-systèmes, ainsi que des nouvelles techniques de traitement de ces données [Schroeck 2012]. Nous citons ici quelques exemples de domaines divers collectant quotidiennement des masses de données de type différents dont les applications peuvent être hébergées par des services cloud : les entreprises de télécommunication collectent des millions de logs d’appels par jour et les conservent plusieurs mois ; les grandes plateformes de vente en ligne traitent des milliers de connexions par jour de clients différents ; les sites de réseaux sociaux publient des millions de messages par jour ; les météorologistes fondent leurs travaux sur l’information de milliers de capteurs météorologiques de tout type qu’ils analysent par la suite ; les centres financiers réalisent des millions d’opérations par minute basées sur l’analyse de milliers d’indicateurs financiers, etc.

Table des matières

INTRODUCTION
1 Contexte et concepts fondamentaux
1.1 Le cloud computing
1.1.1 Définition et caractéristiques
1.1.2 La virtualisation
1.2 Problématique de sûreté de fonctionnement dans les clouds
1.2.1 La sûreté de fonctionnement
1.2.1.1 Attributs de la sûreté de fonctionnement
1.2.1.2 Entraves à la sûreté de fonctionnement
1.2.1.3 Moyens pour la sûreté de fonctionnement
1.2.2 Détection d’anomalie dans les services clouds
1.2.2.1 Caractéristiques de la détection d’anomalies dans les services cloud
1.2.2.2 Critères pour la sélection d’une technique de détection d’anomalies
1.3 Conclusion
2 Détection d’anomalie par apprentissage – État de l’art
2.1 Détection d’anomalie
2.1.1 Différents types de données
2.1.2 Techniques basées sur les statistiques, les théories des probabilités et de l’information
2.1.3 Techniques de détection basées sur l’apprentissage automatique
2.1.3.1 Détection par apprentissage supervisé
2.1.3.2 Détection par apprentissage non supervisé
2.1.3.3 Discussion sur les besoins de détection
2.2 Évaluation expérimentale de performances de détection
2.2.1 Injection de fautes
2.2.2 Métriques d’évaluation
2.3 Conclusion
3 Présentation générale de la stratégie de détection
3.1 Cadre conceptuel
3.1.1 Contexte
3.1.2 Hypothèse sur la manifestation d’une anomalie
3.2 Entité de monitoring
3.2.1 Différentes sources de monitoring
3.2.2 Groupement des compteurs de performance
3.2.2.1 Groupement par-VM
3.2.2.2 Groupement par-ressource
3.2.2.3 Discussion sur le diagnostic
3.3 Entité de détection
3.3.1 Niveau de détection
3.3.2 Type de détection
3.3.3 Détection par apprentissage supervisé
3.3.3.1 Fonctionnement en deux phases
3.3.3.2 Groupement des données
3.3.4 Détection DESC
3.3.4.1 Analyse des données de monitoring et hypothèses sur les clusters
3.3.4.2 Groupement des données
3.3.4.3 Phase de caractérisation de comportement
3.3.4.4 Test et discussion à propos de la caractérisation de comportement
3.3.4.5 Phase d’analyse de comportement
3.3.4.6 Présentation de la technique en pseudo-code
3.3.4.7 Choix des paramètres de clustering
3.4 Conclusion
4 Mise en œuvre
4.1 Plateforme d’expérimentation
4.2 Module de monitoring
4.2.1 Outils de monitoring
4.2.2 Compteurs de performance
4.2.3 Période de monitoring
4.3 Module de charge de travail
4.4 Module d’injection de fautes
4.4.1 Erreurs injectées
4.4.1.1 Causes émulées et moyens utilisés
4.4.1.2 Réflexion sur le diagnostic
4.4.2 Campagne d’injection
4.4.2.1 Description
4.4.2.2 Intensité d’injection
4.4.2.3 Durée d’injection
4.4.2.4 Temps de pause
4.4.3 Autres types de perturbations
4.5 Module de détection
4.5.1 Mise en œuvre des différents types de détection
4.5.2 Détection par apprentissage supervisé
4.5.3 Détection DESC
4.6 Évaluation
4.6.1 Exploitation des données
4.6.2 Évaluation des performances
4.6.3 Analyse de compteurs de performance
4.7 Conclusion
CONCLUSION

Lire le rapport complet