Hybrid Cloud Computing Elasticity

Transcription

1 Hybrid Cloud Computing Elasticity We need to enhance elasticity to improve multi-cloud elasticity. Thèse sur l Elasticité dans le Cloud Hybride Le Cloud Hybride Elastique permet aux entreprises d approvisionner de l agilité tout en conservant la maîtrise d une partie des traitements, de pouvoir utiliser dynamiquement des services de multiples clouds uniquement quand nécessaire. Ceci passe par une orchestration complète transverse et sans couture. Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013 Geneviève Ribot GeneGGGGGGGGGGGGGGGiève Mastère Spécialisé «Expert Cloud Ribot Computing Mastère et Spécialisé SaaS» ISEP «Expert FC Cloud Novembre Computing 2013 et SaaS» ISEP FC Novembre 2013

2 Remerciements Un besoin du marché Remerciements Tout d abord je remercie Jean-Pierre Perdu, Claude Kuhn, Christophe Delsaux, Jean-Pierre Albert et Nada Conan, qui m ont permis de réaliser ma thèse dans un environnement très favorable à SOGETI, et qui m ont soutenue par leurs lectures et leurs avis éclairés. Je remercie mes collègues de SOGETI, présents pour me soutenir. Je tiens également à remercier Claude Riousset d IBM et Sylvaine Dekeyrel qui ont pris sur leur temps pour relire avec soin ce document et m ont donné quelques conseils. Je remercie également mes contacts LinkedIn et Twitter, et tous les bloggeurs, qui m ont apportés des liens sur des articles intéressants, en particulier Olivier D., Yann M., Eric D., Michel T., Jean-Marc D.. Nous avons également eu des professeurs excellents et impartiaux à l ISEP que je remercie. Je remercie les responsables du partenariat IBM pour m avoir invitée à toutes leurs présentations et à des ateliers sur le cloud, ainsi qu Oracle, Microsoft, VMWare, Cisco, HP et EMC pour leurs invitations. Je terminerai par mon entourage qui a eu beaucoup de patience et toujours là pour soutenir l étudiante. 1 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

3 Sommaire Un besoin du marché Sommaire REMERCIEMENTS 1 SOMMAIRE 2 SOMMAIRE DETAILLE 5 NOTE DE SYNTHESE EN FRANÇAIS 12 ENGLISH SYNTHESIS 13 INTRODUCTION 14 Un besoin du marché 14 Des enjeux d agilité et d efficience 16 L objectif de ce document 17 La démarche 18 Le périmètre 19 PREMIERE PARTIE : LES FONDAMENTAUX DU CLOUD HYBRIDE ELASTIQUE 20 Chapitre 1 La définition de cloud hybride et d élasticité 20 Section 1 : Le Cloud Hybride 20 Section 2 : L élasticité 25 Chapitre 2 : L élasticité dans le cloud hybride 28 Section 1 : Les acteurs du cloud hybride élastique 28 Section 2 : Le Modèle de Référence du cloud hybride élastique 30 Chapitre 3 : Les cas d usage du Cloud Hybride Elastique 36 Section 1 : Les cas d usage 36 Section 2 : Les fonctions du cloud hybride élastique 38 Synthèse de la première partie 42 DEUXIEME PARTIE : LES EXIGENCES & LES SERVICES 43 Chapitre 1 : Les exigences des métiers et des responsables IT 43 Section 1 : Les exigences de l entreprise et de l utilisateur 44 Section 2 : Les besoins de l IT fournisseur de cloud hybride 46 Section 3 : L analyse des écarts entre la maturité du marché et les exigences 48 2 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

4 Sommaire Un besoin du marché Chapitre 2 : Le catalogue de service du multi-cloud 51 Section 1 : Le catalogue de service du multi-cloud 51 Section 2 : Les engagements contractuels et la conformité 56 Section 3 : La vue financière du modèle de service 58 Synthèse de la deuxième partie : Exigence et catalogue de Service 61 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE 62 Chapitre 1 Les processus 62 Section 1 : Les processus de mise à disposition 62 Section 2 : La capacité 71 Section 3 : La gestion financière 71 Section 4 : La Sécurité 72 Chapitre 2 L outillage de l infrastructure 76 Section 1 : L Infrastructure devient «Software Defined» 76 Section 2 : L automatisation est «Software Defined» 87 Section 3 : Les applications et les Business Process 97 Section 4 : Les passerelles API 99 Chapitre 3 L outillage spécifique 100 Section 1 : Les outils basiques de gestion du cloud hybride 100 Section 2 : Les outils de facturation 101 Section 3 : L adhérence des outils 102 Section 4 : La standardisation des outils 102 Chapitre 4 La sécurité 104 Section 1 : La gestion de la sécurité évolue 104 Section 2 : La sécurité par la gestion des accès et de l identité 105 Section 3 : Les protocoles et la cryptographie 108 Synthèse de la troisième partie : processus et outillages 109 QUATRIEME PARTIE : LA MISE EN ŒUVRE DE PROJET DE CLOUD HYBRIDE ELASTIQUE 110 Chapitre 1 Les étapes 110 Section 1 : L analyse de la stratégie de l entreprise 110 Section 2 : L étude de l existant 112 Section 3 : La définition des priorités 116 Section 4 : La validation des choix, du périmètre et impact 118 Section 5 : La mise en œuvre 119 Section 6 : Le cycle de vie et l amélioration continue 119 Chapitre 2 Les rôles et la gestion des compétences 121 Section 1 : Le rôle de la DSI, la gouvernance du Système d Information 121 Section 2 : Les compétences Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

5 Sommaire Un besoin du marché Chapitre 3 : La gestion du changement organisationnel 124 Section 1 : Impact sur les organisations 124 Section 2 : Réversibilité 126 Section 3 : Le respect de la législation et de la conformité 127 Section 4 : Analogie avec le «software defined» 128 Synthèse de la quatrième partie : La mise en œuvre de projet de Cloud hybride 129 CONCLUSION 130 Prospective 130 Evolution technologique 130 Un écosystème 131 Parallèle avec la finance 131 Le monde est et sera communicant 131 Comment l automatisation permet l élasticité 132 «Le monde qui vient» 132 Le reste à faire 134 Les challenges technologiques de l hybride élastique 134 La maturité des entreprises 135 Les clés du succès 136 BIBLIOGRAPHIE 137 FIGURES 139 DICTIONNAIRE 141 ANNEXE A : API 142 ANNEXE B : LE DEBORDEMENT, L EQUILIBRAGE DE CHARGE Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

6 Sommaire Détaillé Un besoin du marché Sommaire Détaillé REMERCIEMENTS 1 SOMMAIRE 2 SOMMAIRE DETAILLE 5 NOTE DE SYNTHESE EN FRANÇAIS 12 ENGLISH SYNTHESIS 13 INTRODUCTION 14 Un besoin du marché 14 Des enjeux d agilité et d efficience 16 L objectif de ce document 17 La démarche 18 Le périmètre 19 PREMIERE PARTIE : LES FONDAMENTAUX DU CLOUD HYBRIDE ELASTIQUE 20 Chapitre 1 La définition de cloud hybride et d élasticité 20 Section 1 : Le Cloud Hybride 20 1) Les modèles de déploiement ) Les modèles de déploiement du Cloud Hybride ) Le Cloud Hybride et virtualisation ) Les différentes formes de Cloud Hybride ) Les challenges technologiques du Cloud Hybride 22 2) Les modèles de service 24 Section 2 : L élasticité 25 1) La définition de l élasticité 25 2) L élasticité et la «Scalability» ) Des applications conçues pour la «scalability» ) La montée en puissance transverse 27 3) L élasticité et gestion de la capacité 27 Chapitre 2 : L élasticité dans le cloud hybride 28 Section 1 : Les acteurs du cloud hybride élastique 28 1) L évolution de l écosystème 28 2) Les acteurs 28 Section 2 : Le Modèle de Référence du cloud hybride élastique 30 1) Le management homogène ) Exemple : L «Hybrid Cloud» de VMWare, ) L exemple: Microsoft Hybrid IT 32 5 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

7 Sommaire Détaillé Un besoin du marché 2) Le management hétérogène ) Exemple 1 : IBM/Openstack ) Exemple 2 : HP/Openstack 35 Chapitre 3 : Les cas d usage du Cloud Hybride Elastique 36 Section 1 : Les cas d usage 36 1) Le portefeuille de service sur cloud public et privé ) La résilience ou la reprise d activité ) Le projet ponctuel ) Le traitement massif ou l analyse Big-Data ) Les pics de charge prévisibles sur données sensibles ) Les pics de charge sur application SaaS 37 2) Les applications multi-niveaux en cloud public et privé ) Les pics de charge prévisibles sur données non-sensibles ) Les pics de charge non-prévisibles sur données temps réel 38 3) De multiples environnements en cloud public et privé 38 Section 2 : Les fonctions du cloud hybride élastique 38 1) La montée en charge ) Deux cas de montée en charge ) La gestion de la capacité en montée en charge 39 2) L embarquement de charge de travail 40 3) Le débordement 41 4) L équilibrage de charge 41 5) L interopérabilité 41 Synthèse de la première partie 42 DEUXIEME PARTIE : LES EXIGENCES & LES SERVICES 43 Chapitre 1 : Les exigences des métiers et des responsables IT 43 Section 1 : Les exigences de l entreprise et de l utilisateur 44 1) La stratégie de l entreprise en cloud hybride 45 2) La conception des services 45 Section 2 : Les besoins de l IT fournisseur de cloud hybride 46 1) La mise en exploitation 47 2) La production 47 3) L amélioration continue 48 Section 3 : L analyse des écarts entre la maturité du marché et les exigences 48 1) Des challenges technologiques 48 2) Entre les exigences et les capacités technologiques actuelles 49 Chapitre 2 : Le catalogue de service du multi-cloud 51 Section 1 : Le catalogue de service du multi-cloud 51 1) Le contexte des services 51 2) Le contenu du catalogue de services multi-cloud 51 3) La description des services spécifiques ) L intégration : les passerelles ) Le design de l automatisation ) La configuration du réseau et des fonctions réseau inter-cloud ) Les fonctions du cloud hybride : débordement, embarquement, ) L administration de la gestion de l identité et de l accès 55 6 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

8 Sommaire Détaillé Un besoin du marché 2.6) La gestion de la demande et de la capacité 55 a) La gestion de la demande et la proximité métier 55 b) La gestion de la capacité 56 Section 2 : Les engagements contractuels et la conformité 56 1) Les engagements contractuels dans le cloud hybride ) La contractualisation des niveaux de services 56 a) La relation entre service et exigences métier 56 b) L enchaînement des SLA ) Le suivi par les métriques en cloud hybride 57 2) La conformité 57 Section 3 : La vue financière du modèle de service 58 1) Les modèles de facturation ) Les challenges du calcul des coûts 58 a) Les challenges 58 b) La répartition des frais de structure du cloud hybride 58 c) Les charges du cloud privé spécifiques en transverse ) Le modèle marketing et modèle coût de possession ) Les exemples de modèle financier 59 a) Un exemple de modèle financier fonction de la capacité 59 b) Un exemple de modèle financier fonction de la sécurité 60 2) Les modèles de gestion financière en interne 60 Synthèse de la deuxième partie : Exigence et catalogue de Service 61 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE 62 Chapitre 1 Les processus 62 Section 1 : Les processus de mise à disposition 62 1) L inventaire complet dynamique et la configuration. 62 2) Le déploiement et la mise à jour ) Le déploiement classique ) Le déplacement, la copie ou le redéploiement du service 63 a) Le service déplacé ou redéployé 64 b) Le Lancement du service 66 3) L automatisation, l orchestration ) Le processus d automatisation ) Les différents niveaux d orchestration 67 4) L orchestration de l hybride ) L Orchestration de l hybride 70 Section 2 : La capacité 71 1) Le processus de gestion de la demande 71 2) Les processus de gestion et de supervision de la capacité ) La mesure et le contrôle ) L analyse 71 Section 3 : La gestion financière 71 1) La délégation budgétaire 71 2) Le suivi de facturation centralisé 72 3) La comparaison de services 72 Section 4 : La Sécurité 72 1) La configuration de la sécurité 72 2) Les mouvements de données sécurisés 73 7 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

9 Sommaire Détaillé Un besoin du marché 3) La gestion des accès et des identités ) Un cas simple de gestion de l identité et des accès à un service ) L authentification 74 a) Echange de clés publiques, Certificat 74 b) Les API échangent des Token ) L autorisation ) Les challenges 75 Chapitre 2 L outillage de l infrastructure 76 Section 1 : L Infrastructure devient «Software Defined» 76 1) La puissance de traitement (processeur et mémoire) 77 2) La virtualisation du réseau ) Les différentes approches de virtualisation de réseau 79 a) Le S.D.N. 79 b) La virtualisation du réseau centrée sur le contrôleur défini par l OpendayLight. 80 c) La superposition ou encapsulation réseau 81 d) Le Virtual Network du projet OpenContrail ) L application en WAN du SDN ) Virtualisation de fonctions 83 3) Le stockage virtualisé 84 Section 2 : L automatisation est «Software Defined» 87 1) L inventaire et les liaisons 87 2) L automatisation de l infrastructure basique ) Provisionner et configurer ) Exemple d outil : OpenStack 89 3) L automatisation des systèmes, des services, des applications ) L automatisation de systèmes complexes d infrastructure ) L automatisation de systèmes complexes de services 93 3,3) Les standards de «Services Templates» et les outils de déploiement ) L intégration de l écosystème du cloud d accueil ) Exemple d outil d orchestration 96 4) Superviser ses ressources, mesurer 97 5) DevOps 97 Section 3 : Les applications et les Business Process 97 1) SaaS et les liens entre application par API ou connecteurs 97 2) BPaaS : La Conception de Workflow 98 Section 4 : Les passerelles API 99 Chapitre 3 L outillage spécifique 100 Section 1 : Les outils basiques de gestion du cloud hybride 100 1) Les différents outils de gestion de cloud hybride 100 2) Les qualités d un gestionnaire de cloud hybride 101 Section 2 : Les outils de facturation 101 Section 3 : L adhérence des outils 102 Section 4 : La standardisation des outils 102 1) Distributed Management Task Force (DMTF) 102 2) Open Grid Forum (OGF) 102 3) Storage Networking Industry Association (SNIA) 102 4) Advancing Open Standard for the Information Society OASIS 103 5) Format d échange Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

10 Sommaire Détaillé Un besoin du marché Chapitre 4 La sécurité 104 Section 1 : La gestion de la sécurité évolue 104 1) La sécurité ciblée 104 2) La sécurité par la conformité, la classification, l audit 104 Section 2 : La sécurité par la gestion des accès et de l identité 105 1) La gestion des accès et des identités (IAM : Identity Access Management) 105 2) La gestion des processus 106 3) La fédération d identité 107 Section 3 : Les protocoles et la cryptographie 108 Synthèse de la troisième partie : processus et outillages 109 QUATRIEME PARTIE : LA MISE EN ŒUVRE DE PROJET DE CLOUD HYBRIDE ELASTIQUE 110 Chapitre 1 Les étapes 110 Section 1 : L analyse de la stratégie de l entreprise 110 1) La stratégie Business 111 2) La stratégie sécurité 111 3) L analyse de la demande 111 Section 2 : L étude de l existant 112 1) La gestion de la maturité des processus clients ) La standardisation ) L automatisation ) L orchestration ) L orchestration du multi-cloud et des processus 114 2) La cartographie de l existant ) L étude des contrats fournisseurs ) La cartographie des produits existants 114 3) L étude des écarts entre l existant et les exigences ) La classification de l existant ) Le produit sur étagère ou le développement ) Le calcul de l effort pour répondre aux exigences 115 Section 3 : La définition des priorités 116 1) La taille du projet 116 2) Le retour sur investissement 116 3) Le périmètre des projets sélectionnés ) Le contexte et le catalogue de service ) Les fonctions 117 Section 4 : La validation des choix, du périmètre et impact 118 1) La validation du périmètre, du planning et du budget 118 2) L implication des acteurs 118 3) La validation de l architecture 118 Section 5 : La mise en œuvre 119 1) La description complète des services du catalogue de service 119 2) La conception de l automatisation 119 3) La gestion du changement 119 4) La mise en exploitation et le contrôle Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

11 Sommaire Détaillé Un besoin du marché Section 6 : Le cycle de vie et l amélioration continue 119 1) Le cycle de vie 119 2) L amélioration continue 120 Chapitre 2 Les rôles et la gestion des compétences 121 Section 1 : Le rôle de la DSI, la gouvernance du Système d Information 121 1) La gestion des fournisseurs 121 2) La supervision des performances et l anticipation de la demande par des tableaux de bord 121 3) La cohérence du SI en collaboration avec les métiers 121 4) La gestion du multi-cloud et du cloud privé 122 Section 2 : Les compétences 122 1) La simplification des processus 122 2) Le «software defined anything» 122 3) Le transverse 122 4) L intégration 123 5) La sécurité 123 Chapitre 3 : La gestion du changement organisationnel 124 Section 1 : Impact sur les organisations 124 1) Les entreprises nouvelles, les TPI 124 2) Les entreprises avec une infrastructure interne importante 124 3) Les courtiers 125 4) Les fournisseurs de matériel et de logiciel cloud 125 5) Les intégrateurs ) Les métiers ) Le marché 125 6) Les info-géreurs 126 7) Les hébergeurs 126 8) Les éditeurs de progiciel 126 Section 2 : Réversibilité 126 Section 3 : Le respect de la législation et de la conformité 127 1) Les données personnelles 127 2) D autres aspects 127 3) La localisation en cloud hybride 127 Section 4 : Analogie avec le «software defined» 128 Synthèse de la quatrième partie : La mise en œuvre de projet de Cloud hybride 129 CONCLUSION 130 Prospective 130 Evolution technologique 130 Un écosystème 131 Parallèle avec la finance 131 Le monde est et sera communicant 131 Comment l automatisation permet l élasticité 132 «Le monde qui vient» Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

12 Sommaire Détaillé Un besoin du marché Le reste à faire 134 Les challenges technologiques de l hybride élastique 134 La maturité des entreprises 135 Les clés du succès 136 BIBLIOGRAPHIE 137 FIGURES 139 DICTIONNAIRE 141 ANNEXE A : API 142 ANNEXE B : LE DEBORDEMENT, L EQUILIBRAGE DE CHARGE Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

13 Note de synthèse en français Un besoin du marché Note de synthèse en français Le cloud hybride élastique correspond à l évolution actuelle du marché du cloud pour toutes les entreprises qui souhaitent gagner en agilité, tout en maintenant une gouvernance sur leur choix de solution, et en capitalisant sur leur existant. Aller vers le cloud hybride est un projet de transformation de l entreprise. Ceci nécessite des compétences transverses. Cette thèse est traitée dans cet esprit, elle démontre qu il faut avoir une vision globale qui va de la gestion de la stratégie de l entreprise à la mise en œuvre, tout en passant par la maturité technologique de l automatisation, pilier de la faisabilité du cloud hybride élastique. Cette maturité technologique s appuie sur la mise en place de standards à tous les niveaux de l infrastructure à l applicatif. L approche transverse ne permet pas la granularité des approches focalisées sur un seul sujet, elle est pourtant indispensable à l intégration des différentes briques de l automatisation que sont le réseau, le traitement, le stockage, le développement, la production, les applications, les flux métiers, la supervision. La première partie définit ce qu est le cloud hybride élastique. Le cloud hybride élastique est le courtier de cloud interne, il permet de répondre à des pics de charge et des projets ponctuels par des solutions de débordement et d embarquement de services en externe. Il gère la gouvernance du multi-cloud, en particulier la capacité, la sécurité, la facturation, le respect des engagements, en s appuyant sur la gestion des règles, des politiques et des mesures. La deuxième partie traite des exigences de l entreprise et de l IT et du catalogue de service du cloud hybride élastique pour y répondre. L analyse des exigences est affinée par une vue sous l angle ITIL pour l entreprise et les services IT. L écart entre les exigences et la maturité de l offre de service cloud nous donne les opportunités et les faiblesses du cloud hybride élastique et nous permet de construire le catalogue de service. Les processus et les mécanismes qui sont essentiels pour réaliser les services du cloud hybride élastique, sont vus dans la troisième partie. Nous focalisons alors sur les processus d orchestration, de fédération, de facturation avant d étudier l outillage sans lesquels nous ne pourrions pas automatiser. Nous étudions les mécanismes en partant de l infrastructure et en remontant dans les couches applicatives. Et nous montrons comment cet outillage évolue pour permettre l automatisation de l infrastructure, l orchestration par le «Software Defined» qui consiste à séparer le traitement du contrôle, afin de pouvoir centraliser le contrôle et ainsi configurer les ressources à la volée. Enfin, connaître les exigences et la maturité technologique nécessaire ne suffisant pas pour réussir un cloud hybride élastique. La quatrième partie, traite donc de la mise en œuvre d un cloud hybride élastique, sous forme d étapes traitant entre autre de la maturité des processus, du retour sur investissement et de la gestion du changement organisationnel. Et nous terminons par la conclusion par une prospective, le reste à faire et les clés du succès. 12 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

14 English synthesis Un besoin du marché English synthesis The elastic hybrid cloud is the current evolution of the cloud market, for all companies wishing to increase their agility, while strengthening governance, and capitalizing on their legacy. Going toward the hybrid cloud is an enterprise transformation project. This requires cross-functional management skills. This thesis is addressed to do so; it shows that it s necessary to have a global view of transformation from managing the business strategy to implementation, while going through the technological maturity, which is the corner stone of elastic hybrid cloud automation. This technological maturity relies on the establishment of standards at all levels, from infrastructure to software. The transverse approach does not allow the granularity of single issue focused approaches. However you need an overview to integrate the different layers that are automating network, processing, storage, development, production, applications, business workflows and monitoring. The first part defines what the elastic hybrid cloud is. The elastic hybrid cloud is the internal cloud broker. It s an answer for peak loads and one-shot projects, with outside bursting and on-boarding services. It manages the governance of multi-cloud like capacity, security, billing, fulfillment of commitments driven by management rules, policies and measures. The second part deals with business and IT requirements and with the elastic hybrid cloud service catalog. The requirement analysis is refined by an ITIL process point of view for business and IT services. The difference between requirements and cloud services market maturity give us the opportunity and the weakness of the actual elastic hybrid cloud and help us to build the service catalog. The essential processes and mechanisms to achieve flexible hybrid cloud services are seen in the third part. The orchestrations, the federation and the billing process are studied before looking at tools, without which you can t automate. The end-to-end approach goes from the infrastructure to the application and business process mechanisms. We show how these tools evolve to enable the automation of infrastructure orchestration by "Software Defined" which consists of separating the data plane from the control plane, in order to centralize control and to configure resources on the fly. However, the requirements and the technological maturity only are not sufficient enough to deliver a flexible hybrid cloud. The fourth section therefore addresses the successful implementation of an elastic hybrid cloud, bringing steps to deal with other necessary processes like maturity, return on investment, and change management. Lastly, we conclude with prospective challenges and keys to success. 13 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

15 Introduction Un besoin du marché Introduction Un besoin du marché Des besoins Le contexte économique actuel ne permet pas de rester inactif. Il faut répondre vite aux demandes du marché et à moindre coût. Les entreprises doivent : - capitaliser sur leur existant, - maîtriser leurs dépenses, - être plus réactives, - améliorer leur Time To Market, pour des cycles de vie produit plus courts, - répondre à des besoins nouveaux comme l analyse Big Data, la convergence digitale, l internet des objets, - être compétitives. Elles sont soumises à des contraintes de sécurité et de conformité, légales et réglementaires. Certaines de leurs données sont sensibles, à caractère personnel, ou stratégiques, constituent l ADN de la société. D autres doivent pouvoir être auditées. Elles ne peuvent pas être externalisées sans respecter des conditions de localisation, de sécurité, d accessibilité, de réglementation. Remarque Le cloud hybride répond donc aux besoins d entreprises. Les TPI et PME ou des entreprises nouvelles sans ses exigences pourront lui préférer les courtiers de cloud. Important L entreprise doit toujours pouvoir approvisionner les services qui correspondent à ses exigences, en interne, mais aussi chez différents fournisseurs de cloud. Elle se doit de garder la liberté de choisir le meilleur du marché pour chaque besoin et de pouvoir adapter ses fournisseurs à son évolution. Un modèle de cloud hybride élastique permet de répondre à ses besoins. Le cloud c est la mise à disposition de services : en self-service, facturés ou mesurés à l usage, accessibles de partout, s appuyant sur des ressources mutualisées et rapidement élastiques (d après les 5 caractéristiques essentielles du cloud du NIST). Le cloud est caractérisé par ses modèles de déploiement : public, privé, communautaire et ses modèles de service : IaaS (Infrastructure as a Service), PaaS (Plateform as a Service), SaaS (Software as a Service), BaaS (Business as a Service) que nous reverrons dans «Les Fondamentaux». 14 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

16 Introduction Un besoin du marché Important Le cloud hybride permet la connexion de l entreprise à différents clouds privés, publics ou communautaires. Il faut qu il soit élastique car il doit permettre d approvisionner des ressources et de les libérer en fonction des besoins. Des chiffres confirment les besoins d élasticité L étude du marché du Cloud Index montre que la motivation principale des entreprises, devant la réduction de coût, est le besoin de flexibilité qui démontre bien l importance de l élasticité. La flexibilité permet à l entreprise d adapter ses ressources en fonction de ses besoins, rapidement et à moindre coût. Figure 1 : Les motivations principales pour recourir au Cloud Des évolutions portées par la dynamique de l écosystème : mobile, données, objets. La figure suivante : le «Hype Cycle» (Cycle de battage médiatique) de Gartner, caractérise l évolution dans le temps des attentes et déceptions engendrées par des nouvelles technologies. 15 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

17 Introduction Des enjeux d agilité et d efficience Figure 2 : Cycle de battage médiatique du Cloud-Computing - Gartner 2012 Il place le «Cloud Hybride» en août 2012 dans un cycle qui devrait atteindre son plateau de production dans 5 à 10 ans. Ceci n est pas étonnant étant donné la complexité et la multitude des outils, sujet que nous développerons plus loin, à mettre en place pour atteindre toutes les exigences des entreprises, mais ce cycle pourrait être raccourci par la synergie des acteurs pour apporter des solutions technologiques, afin de répondre aux attentes du marché, en terme de réactivité. Des enjeux d agilité et d efficience Les entreprises sont de plus en plus nombreuses à souhaiter faire du Cloud Hybride, en partie en interne, en partie en externe. Ce cloud doit être élastique, c'est-à-dire qu il doit répondre rapidement à des demandes de ressources supplémentaires et à leur libération dès qu elles ne sont plus utiles. L objectif de l élasticité est de diminuer les coûts, le principe pour le réaliser est d automatiser. L administration et l automatisation doivent être le plus simple possible, et le suivi des coûts doit permettre de suivre le retour sur investissement. Important Pour améliorer l efficacité et la disponibilité il faut réduire la complexité : automatiser, orchestrer, de façon transversale, de l infrastructure au logiciel, d un métier à l autre. 16 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

18 Introduction L objectif de ce document L objectif de ce document L objectif de ce document est de décrypter les meilleurs chemins pour réaliser de l élasticité dans le cloud hybride pour : Adapter l'infrastructure aux exigences et non l'inverse. => nous commencerons donc, juste après les définitions, par rechercher les exigences et les services Gagner du temps et de la fiabilité en automatisant des tâches répétitives et en orchestrant globalement. Améliorer la sécurité et la centralisation : nous verrons ce qui participe à l orchestration d un cloud hybride élastique. => nous verrons les mécanismes qui permettent de répondre aux exigences et leur maturité Réussir le changement par une démarche complète incluant la gestion du changement. => car bien connaître ces exigences et les technologies ne suffit pas, le dernier point abordé sera la mise en œuvre. 17 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

19 Introduction La démarche La démarche Important La démarche découle de ces objectifs et de la conviction, que le cloud hybride nécessite une vue transversale : - au niveau technologique : de l infrastructure à la gestion des processus, - au niveau projet : de l écoute des besoins à la mise en œuvre. C est d ailleurs pour cela que la formation de l ISEP FC est transversale. Nous commençons par définir ce qu est un cloud hybride et en quoi consiste l élasticité, dans la première partie. Ceci est suivi de cas d usages de cloud hybride élastiques permettant de voir plus concrètement la pertinence de ce modèle pour les entreprises. Ensuite, dans la deuxième partie nous étudions quelles sont les exigences des entreprises et de l IT pour y répondre. Afin de couvrir la majorité des clouds hybrides nous ne traitons pas d un cas d usage, mais restons global, en nous appuyant sur des séminaires, des articles, des retours d expérience de professionnels. De ses besoins découleront les services considérés majeurs dans la réalisation du cloud hybride élastique. Puis nous étudions dans la troisième partie, les processus et les mécanismes, qui sont essentiels pour répondre à ces exigences et réaliser les services du cloud hybride élastique. Nous focalisons alors sur les processus d orchestration, de fédération, de facturation avant d étudier l outillage sans lequel il serait impossible ou difficile d automatiser. Nous étudierons les mécanismes en partant de l infrastructure et en remontant dans les couches applicatives. Et nous essaierons de montrer comment cet outillage évolue pour permettre l automatisation de l infrastructure à l orchestration. Enfin, connaître les exigences et la maturité technologique nécessaire ne suffisant pas pour réussir un cloud hybride élastique. Nous abordons donc, la quatrième partie, la mise en œuvre d un cloud hybride élastique, en le déroulant sous forme d étape nous verrons : le retour sur investissement, la maturité nécessaire, l impact organisationnel. 18 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

20 Introduction Le périmètre Nous terminons par la conclusion avec une prospective sur l évolution potentielle de l écosystème du cloud hybride. Important L élasticité dans le cloud hybride demande une vue transverse qui part de la stratégie pour aboutir à la mise en œuvre et cette élasticité s appuie sur des «technologies» adaptées qui permettent le transfert des informations entre chaque niveau physique et applicatif. Le périmètre Le domaine du cloud est tellement vaste qu il est impossible de traiter l ensemble des domaines. Ce document s adresse à un public averti et ne détaillera pas toutes les technologies sous-jacentes au cloud computing. Ce document ne traitera pas non plus de manière significative des vendeurs de produits, services et technologies, que vous trouverez dans la documentation spécialisée des vendeurs, afin d avoir une vision indépendante de celle de fournisseurs. Nous ne pouvons pas traiter toutes les exigences, tous les services, tous les mécanismes. Nous focaliserons donc sur ceux qui sont essentiels à l élasticité en multi-cloud. Nous ne traiterons pas notamment des mécanismes spécifiques de domaines «particuliers» comme la messagerie, le big-data, la base de donnée, le développement et le PaaS, le Master Data Management ou le Virtual Desktop Infrastructure, Nous traiterons par contre les fondamentaux du cloud (traitement, stockage, réseau), les spécificités (automatisation, orchestration, mesures, règles ), la gestion, et aborderons certains aspects de la gestion des accès. Nous traiterons des besoins, services et mécanismes liés à la circulation des charges de travail d un cloud à un autre et des impacts prévisibles. Conseils pour une lecture transverse Dans un monde où il faut aller vite, un document d une centaine de page, peut être décourageant. Des petits carrés avec marqué «important» ou «synthèse» sont là pour vous donner un aperçu de ce document. 19 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

21 PREMIERE PARTIE : LES FONDAMENTAUX DU CLOUD HYBRIDE ELASTIQUE Chapitre 1 La définition de cloud hybride et d élasticité PREMIERE PARTIE : LES FONDAMENTAUX DU CLOUD HYBRIDE ELASTIQUE Nous commençons par définir ce qu est un cloud hybride et en quoi consiste l élasticité. Ceci est suivi de cas d usage de cloud hybride élastique permettant de voir plus concrètement la pertinence de ce modèle pour les entreprises. Chapitre 1 La définition de cloud hybride et d élasticité Dans ce chapitre nous verrons les modèles de déploiement et de service du cloud hybride, puis la définition de l élasticité par rapport à la «scalability». Section 1 : Le Cloud Hybride 1) Les modèles de déploiement 1.1) Les modèles de déploiement du Cloud Hybride 3 modèles de déploiement sont reconnus par la plupart des acteurs du cloud : public, privé et communautaire. Le modèle hybride est une gestion centralisée de différents modèles de déploiement. Le cloud hybride est la connexion de différents clouds, à différents niveaux, pour servir les besoins d une entreprise en permettant la portabilité des charges de travail ou données. L emploi de charge de travail est utilisé pour signifier qu il peut s agir d une partie d un service, ou d un service complet. L IT traditionnelle ou hors cloud n est pas exclue de la gestion du cloud hybride car : - le client consommateur souhaite avoir tous ses services accessibles d un même portail, - les services doivent pouvoir échanger des informations entre hors-cloud et dans le cloud, - le gestionnaire interne des services cloud a besoin de fédération de certaines informations, d identité, de sécurité, de monitoring, Les services qui ne sont pas mis dans le cloud, sont en règle générale gardés en interne pour des raisons : - technologiques (incompatibilité, performance, etc.), - de conformité à la législation, - de classification (propriété intellectuelle, confidentialité, informations stratégiques). Ces services peuvent avoir des interfaces avec les services gérés dans le cloud. Ces interfaces se basent en général sur les connecteurs des applications. 20 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

22 PREMIERE PARTIE : LES FONDAMENTAUX DU CLOUD HYBRIDE ELASTIQUE Chapitre 1 La définition de cloud hybride et d élasticité Figure 3 : Modèles de déploiement du Cloud Modèle de déploiement Privé Emplacement Privé sur site client. Non Privé managé. sur site client. Non Privé hosté et managé.hors site Ressources multi-entreprises Possible Communautaire hors site Possible Public Virtual Private Cloud hors site Non Public traditionnel hors site Oui Public à engagement hors site Oui L entreprise possède sa propre infrastructure de cloud en interne pour fournir à ses clients internes en général des services facturés à l utilisation (ou mesurés). Son service informatique gère l infrastructure à la livraison des services. L entreprise possède sa propre infrastructure de cloud ou la loue en interne pour fournir à ses clients des services facturés à l utilisation (ou mesurés). Le service informatique est géré par un prestataire externe qui est en charge de l infrastructure à la livraison des services. L entreprise possède sa propre infrastructure de cloud ou la loue, dans un site externe, pour fournir à ses clients des services facturés à l utilisation (ou mesurés). Le service informatique est géré par un prestataire externe qui est en charge de l infrastructure à la livraison des services. Plusieurs entreprises partagent une infrastructure de cloud. Elles partagent un besoin commun de service. Exemple : Amadeus. Le fournisseur de cloud fournit des services à son entreprise cliente, facturés à l utilisation et/ou à la réservation, mais le client réserve des ressources pour son organisation non-mutualisées, ainsi que des liens. Exemple : Virtual Private Cloud d AWS. A la limite entre du cloud privé et du cloud public car similaire au cloud privé hébergé et managé, mais hébergé dans des fournisseurs de cloud public. Le fournisseur de cloud fournit des services à ses entreprises clientes, facturés à l utilisation. Les ressources sont mutualisées, l isolation est assurée par des mécanismes adéquats. Exemple : AWS, Goggle Engine, Les ressources sont publiques mais le client s'engage mensuellement ou annuellement, ou le service souscrit l'engage par manque de possibilité de réversibilité. Figure 4 : Tableau des Modèles de déploiement Le mode de déploiement public du cloud hybride est le courtier de cloud, le «cloud broker». 1.2) Le Cloud Hybride et virtualisation La virtualisation permet de mettre une couche d abstraction entre le matériel et le logiciel. Elle permet de mettre plusieurs machines virtuelles sur un seul serveur ou sur un groupe de serveur, mais surtout d automatiser l approvisionnement de ressource et leur configuration. La virtualisation du réseau local et du stockage complète celle du traitement. La virtualisation simplifie beaucoup de mécanismes de configurations et permet de migrer certaines applications en fonctionnement dans des datacenters, sur des infrastructures compatibles. 21 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

23 PREMIERE PARTIE : LES FONDAMENTAUX DU CLOUD HYBRIDE ELASTIQUE Chapitre 1 La définition de cloud hybride et d élasticité Si la virtualisation à l avantage d abstraire les contraintes de compatibilité physique, certaines applications peuvent fonctionner en bare métal, sans hyperviseur, mais automatisées de façon à pouvoir déplacer la charge de travail d une ressource à une autre, en contournant les problèmes d adhérence par le déploiement à l aide de scénarios automatisés. Pour certaines applications, fonctionner directement sans virtualisation permet de savoir en permanence ou se situe l application, sur quels composants. Cela peut permettre également d optimiser la performance, par l absence de virtualisation. (Exemple : «Parallels Automation» permet de définir des modèles de déploiement et de facturation avec ou sans l hyperviseur «Virtuozzo Parallels Container»). 1.3) Les différentes formes de Cloud Hybride Le terme inter-cloud est plus réservé pour définir la connexion entre cloud qui sert à la gestion propre du cloud. Il s agit en général d une liaison pour la sauvegarde, le secours ou les mises à jour internes. En ce qui concerne notre définition du cloud hybride le terme le plus souvent employé est multi-cloud. Le cloud hybride peut faire référence à différentes formes «d hybridation» qui sont : - des ressources physiques et des virtuelles, - des clouds privés et publiques, - du cloud et du non-cloud, - différents fournisseurs de cloud, - du réseau privé et public, - du partagé et du privatif, - du sur-site et du hors-site. Le cloud hybride peut prendre ses différentes formes. Le principe du cloud hybride, ici étudié, est celui qui permet à l entreprise de pouvoir approvisionner des services dans de multiples clouds. Dans le cloud Hybride les services peuvent passer d un cloud à l autre de manière horizontale. Ils sont déployés sur chaque implémentation cloud, déplacés de l une à l autre, ou montent en charge de manière horizontale entre les deux implémentations. Le premier bénéfice de ce déploiement est la flexibilité, la gestion de la disponibilité et l élasticité. 1.4) Les challenges technologiques du Cloud Hybride Le cloud hybride s ouvre nécessairement, sur l assemblage de multiples clouds de technologies différentes, par le biais d interfaçage (API) (cf. Annexe API). Ce qui permet aux entreprises de rester libres d approvisionner les meilleurs services correspondants à leurs exigences métier. Si un cloud n assume pas une fonction ou l assume différemment d un autre, l interface ne suffira pas à avoir la fonction. Par exemple si le service gère quatre niveaux de rôles dans un cloud et que le deuxième cloud n en gère que trois, le service ne pourra pas être transféré. L intégration de ces interfaces et le maintien de la compatibilité, sont un challenge. 22 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

24 PREMIERE PARTIE : LES FONDAMENTAUX DU CLOUD HYBRIDE ELASTIQUE Chapitre 1 La définition de cloud hybride et d élasticité Faire intervenir de multiples éléments, multiplie le risque d indisponibilité, surtout s ils ne sont pas redondés. L outil central de gestion du cloud, l automatisation, le réseau internet font partie des éléments qui ne doivent pas devenir des Single Point Of Failure. Pour gérer la capacité, il faut remonter l information sur la capacité qui influe sur les besoins du service. Hors la capacité comme nous l avons vu précédemment peut concerner beaucoup d éléments, et donc remonter beaucoup d information ce qui est gourmand en ressource. De plus il faut que la donnée dont a besoin le service soit mesurée dans le cloud concerné. La sécurité des accès, et celle des mouvements de données comme vu dans le chapitre précédent sont un des challenges. En particulier la sécurité des APIs. Ces challenges vont se retrouver dans tous les niveaux du physique à l orchestration. Important Qui dit cloud hybride dit hétérogénéité et multiplicité des composants matériels et logiciels. L automatisation et l orchestration sont indispensables pour simplifier la complexité et réduire les coûts. Industrialiser permet aussi de réduire les erreurs dans la répétition des tâches, de gagner en agilité, en rapidité. Par contre il ne faut pas négliger l investissement et les compétences nécessaires pour automatiser la complexité. Une automatisation modulaire s appuyant sur des blocs de construction, des paramètres, des standards doit permettre de gagner en productivité. 23 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

25 PREMIERE PARTIE : LES FONDAMENTAUX DU CLOUD HYBRIDE ELASTIQUE Chapitre 1 La définition de cloud hybride et d élasticité 2) Les modèles de service Ci-dessous la figure 5 présente les différents modèles de service. En gris l environnement sous la responsabilité de l entreprise et en vert l environnement sous la responsabilité du fournisseur de service cloud. TRADITIONNEL IAAS PAAS SAAS BPAAS Monitoring Monitoring Monitoring Monitoring Monitoring Gestion des Process Gestion des Process Gestion des Process Gestion des Process Gestion des Process Application Application Application Application Application Services Business Services Business Services Business Services Business Services Business Services techniques Services techniques Services techniques Services techniques Services techniques Base de données Base de données Base de données Base de données Base de données Plateforme et Framework Plateforme et Framework Plateforme et Framework Plateforme et Framework Plateforme et Framework Middleware et Runtime Middleware et Runtime Middleware et Runtime Middleware et Runtime Middleware et Runtime Système d exploitation Système d exploitation Système d exploitation Système d exploitation Système d exploitation Virtualisation Virtualisation Virtualisation Virtualisation Virtualisation Serveur Serveur Serveur Serveur Serveur Stockage Stockage Stockage Stockage Stockage Réseau Réseau Réseau Réseau Réseau Figure 5 : Modèles de service du cloud hybride Dans le modèle IaaS ou Infrastructure as a Service, le traitement, le stockage, le réseau, la couche d abstraction et éventuellement le système d exploitation et des logiciels sont fournis sous forme de service. Le client consommateur peut partiellement configurer ces éléments. Il peut choisir d y installer les systèmes d exploitation, les logiciels qu il souhaite. Il est en charge de leurs mises à jour. Le PaaS ou Plateforme as a Service : met à disposition outre l infrastructure, des ensembles d outils de développement : structures, librairies, logiciels, systèmes de gestion de contenu et souvent des outils de roll-back, de gestion de version ou pour basculer d un environnement à l autre (développement, test, intégration, production). La politique de mise à jour des différents éléments dont l operating-system est à étudier, il devrait être à la charge du fournisseur de la plate-forme. Celui-ci doit au moins mettre à disposition des outils facilitant la mise à jour, le patching. Le SaaS ou Software as a Service : met à disposition une application sous forme de service, éventuellement paramétrable, souvent multi-tenant, c'est-à-dire qu une même application est partagée par plusieurs organisations, isolées entre elles par l application. Le BPaaS ou BaaS ou Business Process as a Service : s intègre au-dessus de l application les processus métiers sous forme d ensemble de circuit de validation ou d action, de flux de travail dans le but de 24 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

26 PREMIERE PARTIE : LES FONDAMENTAUX DU CLOUD HYBRIDE ELASTIQUE Chapitre 1 La définition de cloud hybride et d élasticité les rendre plus efficients, plus flexibles, en permettant le suivi et l analyse de ces flux et processus métier. Ce service est important pour l interne également car l automatisation et l orchestration nécessitent des flux d actions et la supervision de ces flux. Exemples de BPaaS : gestion des voyages, des délégations, des processus IT comme les tests logiciels. Important Le cloud hybride ne concerne pas que le IaaS, tous les niveaux sont importants. Dans la même lignée que la démarche «DevOps» (voir chapitre 2) ou «Software Defined», plus on attaque haut dans les couches, plus la démarche permet d éviter les silos, le verrouillage et de favoriser l automatisation. Le cloud hybride concerne chaque niveau : - Au niveau IaaS l approvisionnement de ressources dans des clouds différents. - Au niveau PaaS le déploiement ou le déplacement d environnement applicatif sur des clouds différents. - Au niveau SaaS : la possibilité d échanger des informations avec d autres cloud, même quand l application interfacée change de cloud. - Au niveau BPaaS : la possibilité d enchaîner un flux de travail, d un cloud à l autre. Section 2 : L élasticité 1) La définition de l élasticité L'élasticité économique mesure la variation d'un élément en fonction d'un autre élément. Par exemple si le prix baisse de 5% la demande augmente de 10%. L'élasticité en science est la qualité d'un matériau à être déformable tout en reprenant sa forme d'origine lorsque la contrainte qu'on lui applique disparaît. Il s agit aussi de résilience. Important L élasticité dans le domaine qui nous concerne, consiste à allouer dynamiquement des capacités (puissance de calcul, mémoire, stockage, réseau) lors d une montée en charge ou un besoin ponctuel assimilable à une contrainte et à libérer ces ressources dynamiquement lorsque la contrainte disparaît. 2) L élasticité et la «Scalability» Le terme de «scaling» que l on peut traduire par «montée en puissance» est couramment utilisé. On distingue : - «Scale up» : montée en charge sur une même ressource en mettant à jour ses capacités internes (mémoire, disque, ). 25 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

27 PREMIERE PARTIE : LES FONDAMENTAUX DU CLOUD HYBRIDE ELASTIQUE Chapitre 1 La définition de cloud hybride et d élasticité - «Scale out» : montée en charge par mutualisation de différentes ressources (cluster, pool, ) qui est plus souple, plus extensible. Figure 6 : Scale-Up versus Scale-Out Pour parler d élasticité il faut impérativement intégrer le «Scale down» c'est-à-dire la libération des ressources, à tous les niveaux : du physique jusqu aux services, ce qui n est pas toujours facile à mettre en place techniquement. Important 2.1) Des applications conçues pour la «scalability» Pour pouvoir bénéficier de scaling, les applications doivent le supporter ou mieux, avoir été conçues dans cet objectif. Elles doivent pouvoir le supporter, avoir un niveau d abstraction, c'est-à-dire pouvoir accéder à de la mémoire, de l espace disque, de la puissance de calcul mutualisée, ne pas avoir besoin d accès direct, physique. Si elles sont conçues pour la montée en puissance elles pourront par exemple être réparties sur plusieurs ressources, grâce à : - de la modularité, - des processus pré-intégrés, -de la gestion asynchrone facilitant certains processus - des communications sans-état (stateless), - de la sécurité adaptée, - la possibilité de diviser les données, - la possibilité de distribuer l information, le service. Dans le cas d un modèle d application classique sur trois niveaux : Web, Service d application et Base de données, les différents niveaux peuvent rester solidaires, sur un même cloud ou être distribués sur des clouds différents. Par exemple la base et l application sont mises en interne et les frontaux web sont sur un cloud externe. Le challenge est alors de maintenir la connexion réseau et qu elle ait les performances requises. 26 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

28 PREMIERE PARTIE : LES FONDAMENTAUX DU CLOUD HYBRIDE ELASTIQUE Chapitre 1 La définition de cloud hybride et d élasticité 2.2) La montée en puissance transverse La bascule de charge est réalisable par des mécanismes de redirection de flux, qui s appuient sur les DNS par exemple. Les mécanismes de montée en charge doivent être contrôlés et automatisés par des applicatifs centralisés, des outils de gestion de cloud, pour pouvoir déplacer la charge de travail entre cloud. Le déplacement de charge de travail pour un utilisateur précis, en cours de traitement peut se heurter à des problèmes de compatibilité, de sécurité, de bande passante et de latence. Pour la compatibilité il faut avancer sur la standardisation et les interfaces. Pour la sécurité, la gestion des mécanismes d accès, les protocoles, la cryptographie existent et seront renforcés. Pour la bande passante et la latence des liens spécifiques (comme Direct Connect d AWS), la compression, les éléments réseaux et les protocoles sont clés. 3) L élasticité et gestion de la capacité Le terme de capacité dans le cloud inclut la puissance de traitement, la mémoire, la capacité de cycle de lecture, d écriture, la bande passante et la quantité de stockage. Il s agit au final de la capacité à effectuer le service demandé, dans le temps demandé. L élasticité est indispensable pour ajuster la capacité à la demande. La mutualisation des ressources permet en effet dans la limite ou tout le monde n a pas besoin des mêmes ressources au même moment de baisser les charges en disposant des ressources nécessaires au moment voulu. Figure 7 : Capacité et Niveau de Charge La gestion de la capacité est revue dans la première section du prochain chapitre. 27 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

29 PREMIERE PARTIE : LES FONDAMENTAUX DU CLOUD HYBRIDE ELASTIQUE Chapitre 2 : L élasticité dans le cloud hybride Chapitre 2 : L élasticité dans le cloud hybride Nous avons vu ce qu est le cloud hybride et ce qu est l élasticité, voyons maintenant l ensemble : le cloud hybride élastique : les challenges de gestion de capacité et d interopérabilité, ces acteurs, ces modèles de référence. Section 1 : Les acteurs du cloud hybride élastique 1) L évolution de l écosystème La classification des acteurs met en évidence la rupture d écosystème en cours. Les acteurs historiques : les fournisseurs de matériel et de service, de logiciel, d accès internet, les opérateurs, les hébergeurs sont challengés par de nouveaux entrants. Dans les nouveaux acteurs de fournisseurs de cloud certains ont commencé par le moteur de recherche comme Google, ou l e-commerce et sa logistique comme Amazon. La deuxième vague de fournisseurs de cloud est constituée principalement des hébergeurs, comme OVH ou Rackspace, ou d opérateurs, les transporteurs de cloud, qui deviennent aussi parfois des courtiers de cloud. Les auditeurs de cloud et les fournisseurs de composants du cloud sont des acteurs externes dont le rôle est important. 2) Les acteurs Ce modèle de référence de cloud privé inspiré du «NIST Cloud Computing Reference Architecture» (cf. Annexe Modèle d architecture) est très orienté sur les acteurs du cloud. Figure 8 : Modèle de référence du cloud privé 28 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

30 PREMIERE PARTIE : LES FONDAMENTAUX DU CLOUD HYBRIDE ELASTIQUE Chapitre 2 : L élasticité dans le cloud hybride Figure 9 : Acteurs du cloud hybride Le catalogue de service des consommateurs est créé et géré par les administrateurs de cloud, qui eux disposent du catalogue de service du fournisseur de cloud hybride. Ils ne partagent donc pas la même origine de création du catalogue de service, ils sont bien distincts. Les superviseurs peuvent être les administrateurs, mais il est important d apporter une vue différente, d évolution dans le temps et plus globale, il s agit bien de deux rôles différents. Le fournisseur de services de cloud hybride va fournir le catalogue pour les administrateurs, il fournit aussi des services de support, les services de déploiement métier (qui servent à créer le catalogue de service métier et le déploiement de ses services) et les services opérationnels. Les services IaaS, PaaS, SaaS et BPaaS sont orchestrés. Quant à la conformité, la sécurité et le contrôle ils sont transverses aux modèles de service. Les cloud brokers ou courtiers de cloud ne sont pas des propriétaires de cloud mais vont fournir des services correspondants à la demande en sélectionnant le meilleur cloud du marché, en apportant des services à valeur ajoutée, en intégrant de multiples clouds. Important Les courtiers de cloud sont fournisseurs de services de clouds hybrides externes en réalisant l agrégation, l intermédiation et l arbitrage. Certains courtiers de cloud deviennent d ailleurs éditeurs d outil de gestion de cloud hybride comme RightScale, Scalr, ScaleXtreme, Kaavo, Abiquo, Enstratus, Hotlink, ServiceMesh Les clouds carriers ou transporteurs de cloud vont gérer le WAN (Wide Area Network) et parfois avoir des fonctions de courtiers en gérant les CDN (Content Data Network), cache de données 29 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

31 PREMIERE PARTIE : LES FONDAMENTAUX DU CLOUD HYBRIDE ELASTIQUE Chapitre 2 : L élasticité dans le cloud hybride statiques local, ou d autre caches, d autres systèmes de compression, décompression et d optimisation des chemins L auditeur de cloud est une société externe chargée de vérifier la conformité, la sécurité et la performance. Dans notre étude nous ne le reprendrons pas car il n est pas central. Les vendeurs de composants cloud, sont gérés par le fournisseur de cloud ou le client en fonction du modèle de service (IaaS, PaaS, SaaS), donc ils ne sont pas dans le modèle de référence. Il faut pourtant les prendre en compte car ils interviennent souvent dans les contraintes du cloud (maintenance, licence, ), ou apportent de la valeur ajoutée (en performance, en sécurité, en fonctionnalités supplémentaires, ). L interconnexion et l orchestration multi-cloud, s appuient sur des outils d automatisation. Les fournisseurs en apportant des solutions interopérables (répondant à des standards), agiles et performantes vont rendre plus rapides, plus fiables et moins coûteuses les intégrations. Leur rôle est essentiel. Les composants sont importants. Important Les acteurs du cloud hybride importants pour notre étude sont donc : - le client, consommateur et administrateur, - le fournisseur de cloud privé ou courtier interne, - les fournisseurs de cloud externe, - le transporteur. La définition de ces acteurs va nous permettre de mieux définir le périmètre du modèle de référence du cloud hybride élastique. Section 2 : Le Modèle de Référence du cloud hybride élastique Des études démontrent que le business ne se développe que quand le modèle d architecture est mature (cf. Annexe Modèle d architecture). C est pourquoi nous essaierons de trouver un modèle de référence qui permet de présenter visuellement l élasticité du cloud hybride. Pour cela nous nous appuierons sur les références en architectures et des modèles connus. 30 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

32 PREMIERE PARTIE : LES FONDAMENTAUX DU CLOUD HYBRIDE ELASTIQUE Chapitre 2 : L élasticité dans le cloud hybride 1) Le management homogène Figure 10 : Modèle de référence de cloud hybride homogène Certains cloud hybrides sont gérés par le même outil de gestion centralisée. Les «Pour» : Puissant, Simple, une communauté d utilisateurs de la même solution limitant les erreurs. Possibilité de créer un cluster qui est sur les deux infrastructures et donc d ajouter des éléments au cluster pour supporter la montée en charge. Les «Contre» : Limités aux services du fournisseur (de cloud et de la solution) et en interne, donc ne répond pas à toutes les exigences. 1.1) Exemple : L «Hybrid Cloud» de VMWare, La gestion est centralisée par vcloud Suite, et permet d avoir un portail d accès pour gérer l approvisionnement et l automatisation (vcloud Automation Center), la supervision (vcloud Operation management System), la sécurité (vcloud Network & Security). La figure suivante nous permet de voir un exemple de débordement de cloud Privé sur du cloud Public, sur une application d e-commerce. La mise en cache et la réplication des bases sont gérées par VMWare vfabric SQLFire, le WAN par Global Traffic Manager de BIG IP, le LAN par Local Traffic Manager de BIG IP, F5i gère les règles. Le comportement de l application est mesuré en local, et les seuils de capacité définis. Quand les seuils de capacité sont atteints, les Templates de l application et les composants de l infrastructure virtuel pré-positionnée dans l infrastructure publique sont activés et clonés. Quand la capacité revient à un niveau bas prédéfini, les ressources supplémentaires sont libérées. 31 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

33 PREMIERE PARTIE : LES FONDAMENTAUX DU CLOUD HYBRIDE ELASTIQUE Chapitre 2 : L élasticité dans le cloud hybride La fonction qui contrôle les seuils est une fonction de icontrol de if5 (readytoburst()), d autres fonctions sont chargées de réaliser l activation des VM et vapp, et de contrôler si elles sont suffisantes, d en ajouter, d en libérer. Pour le transfert des fonctionnalités de VMWare sont utilisées comme Distributed Ressource Scheduling qui permet de surveiller les performances et de les comparer, et VMotion qui permet de déplacer une VM en fonctionnement. Figure 11 : Cloud hybride VMWare 1.2) L exemple: Microsoft Hybrid IT Figure 12 : Cloud Hybride Microsoft Dans ce modèle le choix avait été fait de répliquer l AD dans le cloud public et d y créer une base de fédération pour accueillir des connexions externes. Cette configuration est un support intéressant pour la mise en place d une reprise d activité en cas de sinistre. 32 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

34 PREMIERE PARTIE : LES FONDAMENTAUX DU CLOUD HYBRIDE ELASTIQUE Chapitre 2 : L élasticité dans le cloud hybride 2) Le management hétérogène Figure 13 : Modèle de référence de Cloud Hybride hétérogène Des clouds hybrides intègrent dans des passerelles qui s appuient souvent sur des interfaces ou Advanced Programing Interfaces (APIs) et du scripting pour effectuer la liaison. Les «pour» : ils sont ouverts, interopérables et permettent d approvisionner en fonction des exigences. Les «contre» : une intégration très importante est nécessaire, à ce jour, qui limite les possibilités, et apporte une charge importante de tests et de risques d erreurs que seule une standardisation peut améliorer. Des outils comme DeltaCloud d Apache (dans le cadre du projet de standardisation CIMI de DMTEF) ou LibCloud se développent, mettant à disposition des passerelles, des librairies pour se connecter aux API standards ou classiques telles que celles de CloudStack, OpenStack, Eucalyptus, AWS, RackSpace, 33 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

35 PREMIERE PARTIE : LES FONDAMENTAUX DU CLOUD HYBRIDE ELASTIQUE Chapitre 2 : L élasticité dans le cloud hybride 2.1) Exemple 1 : IBM/Openstack Figure 14 : Gestion de Cloud Hybride IBM ftp://public.dhe.ibm.com/software/fr/events/solutionconnect2013/pdf/solconnect_13_tiv05.pdf Dans cette version de SmartCloud Orchestrator IBM intègre les modules projet d Openstack pour approvisionner des ressources : Nova pour le traitement, Glance pour les images, Cinder pour le stockage mode bloc et Keystone pour gérer l identité. Les clouds compatibles OpenStack sont alors plus facilement intégrés car similaires en fonctionnalité. Des passerelles pour faire le lien avec le cloud Public AWS EC2 ont également été développées. Le standard OpenStack, à partir du moment où il est largement développé permet d intégrer plus facilement, plus rapidement. Les standards permettent d avoir une large communauté pour faire des avancées technologiques et répondre plus rapidement aux besoins du cloud. Pour l automatisation des approvisionnements système et applicatif, IBM s appuie sur le standard TOSCA d OASIS qui permet de faire des «blueprint» de déploiement d un système, d une application, d un service, associés à leur topologie. Ceci permet de rendre les scénarios de déploiement d applicatif ou «pattern» indépendants de la plate-forme sur laquelle ils seront déployés. 34 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

36 PREMIERE PARTIE : LES FONDAMENTAUX DU CLOUD HYBRIDE ELASTIQUE 2.2) Exemple 2 : HP/Openstack Figure 15 : Gestion de Cloud Hybride HP Séminaire HP du 11/10/2013 Paris «Osez passer au Cloud de nouvelle génération» HP a également intégré OpenStack pour l approvisionnement et la configuration de l infrastructure et s appuie sur TOSCA pour l automatisation. Ils ont développé des passerelles pour les fournisseurs de cloud Amazon Web Service, Azure et Numergy et peuvent intégrer d autres interfaces sur développement. Les services ou charges de travail peuvent être déplacés vers des clouds externes. 35 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

37 PREMIERE PARTIE : LES FONDAMENTAUX DU CLOUD HYBRIDE ELASTIQUE Chapitre 3 : Les cas d usage du Cloud Hybride Elastique Chapitre 3 : Les cas d usage du Cloud Hybride Elastique Après avoir bien défini le cloud hybride élastique, voyons des cas concrets d usage. Il y a plusieurs façons de combiner des infrastructures de cloud public et privé dans un cloud hybride, par exemple en déployant : - une partie du portefeuille dans le cloud publique et une autre dans le cloud privé et les bouger en raison de changement de charge, de coûts, - des tiers séparés, avec le tiers base de donnée sur une infrastructure privée et le tiers web dans le public, - l environnement de développement dans le cloud privé et celui de production dans le public ou l inverse, Figure 16 : Cas d'usage du cloud hybride élastique Section 1 : Les cas d usage 1) Le portefeuille de service sur cloud public et privé 1.1) La résilience ou la reprise d activité L entreprise peut déposer ses applications dans un cloud, disponibles mais non activées et en cas d indisponibilité de ses services effectuer une reprise d activité dans le cloud de manière partielle ou complète. (Exemples : PRA du Virtuel Private Cloud d AWS). L entreprise peut également faire de la continuité d activité en fonctionnant en actif-actif sur un cloud interne et un cloud externe (Exemple : PCA basé sur Site Recovery Manager et VNX VMware-EMC). 1.2) Le projet ponctuel Un projet ou avant-projet nécessite des ressources importantes et immédiatement disponibles. Elles sont provisionnées rapidement, en lien avec l infrastructure interne. Ce qui réduit considérablement les délais du projet. 36 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

38 PREMIERE PARTIE : LES FONDAMENTAUX DU CLOUD HYBRIDE ELASTIQUE Chapitre 3 : Les cas d usage du Cloud Hybride Elastique Les ressources du projet peuvent être rapatriées en interne quand le projet passe un stade défini, ou tout simplement libérées en fin de projet. 1.3) Le traitement massif ou l analyse Big-Data La transformation de documents d un format à un autre, la comparaison de chaîne d ADN, l analyse sémantique de données, le calcul scientifique et l indexation, peuvent être des traitements de volume massif de données. Actuellement les données sont parfois envoyées par transporteur quand leur volume n est pas réaliste par rapport aux capacités réseaux. L élasticité de la capacité réseau est encore un sujet d avenir. Les entreprises n ont souvent pas la capacité technique de gérer un besoin ponctuel de traitement massif de données, le cloud public leur permet alors de gérer ce traitement. Les données issues de ce traitement sont alors reprises en interne, en cloud privé, et les ressources en cloud public libérées. 1.4) Les pics de charge prévisibles sur données sensibles - Une entreprise dispose en interne d un cloud privé et anticipe un pic de charge sur son analyse financière en fin d année. Elle peut choisir de déplacer des traitements vers un cloud public, en déplaçant des applications moins stratégiques, pour libérer de la puissance en interne pour monter en charge. - Une entreprise, comme un hôpital, ne disposant pas provisoirement de ressources suffisantes en interne peut choisir d affecter une partie de ses traitements, non-nominatifs, en externe, dans un cloud publique, et de traiter les données personnelles, devant rester localisées sur le territoire national pour des raisons légales dans son cloud privé, un cloud communautaire ou un cloud souverain. 1.5) Les pics de charge sur application SaaS Une entreprise délivrant un logiciel de CRM, connaît des pics de charge saisonniers. Prenons l exemple d une base de données multi-tenant, conçue pour être divisée, par exemple sur un critère de géographie client. Celle-ci va pouvoir être distribuée sur deux clouds différents et en adéquation avec la localisation du client quand les capacités exigées pour un fonctionnement correct sont dépassées puis centralisée à nouveau, pour des raisons de coûts, quand le pic de charge est passé. C est complexe, il faut avoir mis en place des règles, des mesures et des processus de gestion du mécanisme. La gestion du mécanisme est composée de multiples blocs qui vont gérer la coordination de l ensemble des actions à réaliser et se connecter aux interfaces. D autant plus que le suivi doit parfois pouvoir être tracé et audité. 37 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

39 PREMIERE PARTIE : LES FONDAMENTAUX DU CLOUD HYBRIDE ELASTIQUE Chapitre 3 : Les cas d usage du Cloud Hybride Elastique 2) Les applications multi-niveaux en cloud public et privé 2.1) Les pics de charge prévisibles sur données non-sensibles Une entreprise de commerce en ligne a une activité saisonnière avec des pics de charge à la rentrée, à Noël, en période de solde. Elle peut décider de placer la partie web, d une application à trois niveaux web, application, base de données, pour qu il puisse monter en charge sans limite, dans un cloud public. 2.2) Les pics de charge non-prévisibles sur données temps réel Une entreprise gérant le trafic routier, ne peut pas toujours anticiper ses pics de charges, dus parfois à un accident ou à une météo défavorable par exemple. Par contre en cas de pic de charge elle doit pouvoir diffuser des informations en temps réel. Elle ne peut donc pas s appuyer sur des caches de type CDN (Content Data Network) car l information en cache ne serait pas à jour. Elle doit pouvoir étendre rapidement ses capacités de bande passante. Le besoin est ici d élasticité. Si la plateforme sur laquelle elle se trouve ne suffit pas, elle doit pouvoir basculer sur d autres plateformes. Elle peut décider de placer la tierce base de données, pour qu il puisse monter en charge sans limite, dans un cloud public. 3) De multiples environnements en cloud public et privé Une banque souhaite améliorer l efficience de son développement. Un projet de développement nécessite plusieurs environnements : développement, test, recette, intégration, production. Le passage d un environnement à l autre est automatisé pour améliorer l agilité. Chaque environnement est activé, stocké et désactivé, réactivé lors d un roll-back. Chaque environnement va avoir des exigences différentes en termes de performance, mais aussi de sécurité et de disponibilité et peut donc dépendre d infrastructures différentes : certaines dans le cloud public, d autres en cloud privé. Section 2 : Les fonctions du cloud hybride élastique Nous venons de voir les cas d usage, voyons maintenant les fonctions du cloud hybride qui apportent des solutions aux problématiques de ces cas d usage. Les infrastructures actuelles ne peuvent pas répondre à toutes les nouvelles demandes de possibilité technique, les pics de demandes requièrent une infrastructure onéreuse peu utilisée et le cloud public peut être plus économique. Donc les entreprises regardent vers le cloud hybride. Dès le début du cloud les clients ont utilisé leur portail interne pour donner accès à des ressources supplémentaires souvent provisoires, parfois urgentes : du stockage, du traitement, des plateformes de développement. Au départ ces ressources sont créées à l usage et si le besoin est récurent, un modèle est créé, qui sert à déployer l instance quand nécessaire plus rapidement. C est le début du cloud hybride élastique. 38 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

40 PREMIERE PARTIE : LES FONDAMENTAUX DU CLOUD HYBRIDE ELASTIQUE Chapitre 3 : Les cas d usage du Cloud Hybride Elastique 1) La montée en charge Un besoin souvent rencontré est la montée en charge. Comme le cloud externe est souvent plus mutualisé, il dispose plus facilement de ressources supplémentaires c est donc sur ce cloud externe que l on souhaite monter en charge. Il faut donc que ces mécanismes soient prévus 1.1) Deux cas de montée en charge La figure suivante représente deux cas d élasticité en cloud hybride élastique. Dans le premier cas le service est déplacé du cloud A vers le cloud B (ou plus souvent redéployé dans le cloud B), pour un pic de charge. Le cloud B gère la montée en charge. Quand la charge est standard le service est rapatrié en interne dans le cloud A. Figure 17 : Scale-out en cloud hybride élastique Dans le deuxième cas, il s agit d un service sur 3 niveaux, web, application, base de données, par exemple. Le frontal Web est dans le Cloud B, l application et la base sont dans le cloud A. Quand la charge monte, de la puissance est ajoutée au frontal Web, qui suit à la montée et à la baisse l évolution de la charge. 1.2) La gestion de la capacité en montée en charge Quand un seuil de capacité est atteint des ressources sont activées dans un cloud externe et les utilisateurs orientés vers ses services, ces ressources sont adaptées en permanence au besoin. 39 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

41 PREMIERE PARTIE : LES FONDAMENTAUX DU CLOUD HYBRIDE ELASTIQUE Chapitre 3 : Les cas d usage du Cloud Hybride Elastique Figure 18 : Montée en charge dynamique L affectation de ressources supplémentaires et leurs libérations, sont des mécanismes complexes gérés par des seuils et des algorithmes. L approvisionnement et le dé-provisionnement requiert des ressources systèmes et peuvent générer des latences, surtout entre deux clouds. Afin de ne pas créer d instabilité de l application, le système ne doit pas être trop réactif. En fonction des besoins du service, le système peut soit sur-provisionner légèrement, soit accepter de lèger sousprovisionnement. Le modèle le plus respectueux de l expérience utilisateur, ou de la capacité du service est un modèle dans lequel la performance du service est en permanence mesurée pour vérifier son adéquation par rapport à la demande. L idéal étant d inclure des mécanismes capables : d aller mesurer le temps de réponse du service sur le poste client et de savoir le type de poste client. Pour pouvoir faire ceci il faut tout d abord modéliser : - modéliser le déploiement des charges de travail ou services, - définir des seuils de capacité qui déclencheront la montée en charge et ceux qui sont appropriés à la baisse de charge, - définir des écarts, un comportement, des durées en prenant en compte les délais de déploiement et de transfert d information, afin de stabiliser le comportement, Puis automatiser, orchestrer : - automatiser les mesures, les retours de mesure, les déclenchements, - déployer des ressources supplémentaires, ou en libérer, Enfin il faut pouvoir superviser, c est à dire mesurer la capacité en fonction des besoins du service, afin de respecter les accords de service ou Service Level Agreement (SLA), dans le cloud de départ et celui de débordement. L automatisation s appuie donc sur une modélisation, une orchestration et une supervision qui ne seront réalisables que si les infrastructures matérielles et logicielles peuvent être déployées et configurées par programmation. 2) L embarquement de charge de travail Le premier besoin est l embarquement de charge de travail, pour un nouveau projet par exemple. Il faut alors déployer ce service dans le cloud externe. 40 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

42 PREMIERE PARTIE : LES FONDAMENTAUX DU CLOUD HYBRIDE ELASTIQUE Chapitre 3 : Les cas d usage du Cloud Hybride Elastique 3) Le débordement Certaines sociétés utilisent du cloud bursting, c'est-à-dire du débordement. En cas de pic de charge, les ressources sont déployées et lancées sur un cloud externe afin de répondre à un manque de capacité en interne. Le débordement ou bursting est un mécanisme automatisé d activation de ressources sur un cloud externe qui peut se faire directement à partir d'une valeur seuil par un flux de travail. En dessous du seuil, les ressources crées en externe sont libérées. Le service est facturé à l'usage. (cf. Annexe) 4) L équilibrage de charge L équilibrage de charge ou la bascule de charge, c'est-à-dire le déplacement d une charge de travail, n est pas évident. D une part il se situe sur les couches 4 à 7 du modèle OSI, et il est transporté par les couches réseaux qui sont des couches inférieures en 2 et 3. Des mécanismes permettent de déplacer une copie de la charge de travail, de geler le fonctionnement, et de transmettre les informations restantes avant de redémarrer. Le souci est ce temps d arrêt lié à la charge de travail et à la latence réseau, le temps de gel du au temps de synchronisation finale. (cf. Annexe) => Parenthèse Les processus de bascule de charge peuvent être lancé en préventif, lors d une opération de maintenance, pour relayer le fonctionnement interne ou pour ajouter de nouveaux services. La copie du service est alors présente mais dormante, sous forme de template. Mais cela peut demander un temps d arrêt de service, en fonction des applications, du service et de l infrastructure. C est le type de mécanisme utilisé par Hyper-V replicat de Microsoft pour faire du plan de reprise d activité. 5) L interopérabilité L élasticité entre cloud consiste à déplacer des charges de traitement d un cloud à l autre, cela demande donc une attention particulière sur l interopérabilité, la gestion de la sécurité, la continuité. Nous verrons plus loin l importance de l Open Source dans cette démarche d interopérabilité qui demande la création de standards et d interfaces. Important L élasticité dans le cloud hybride c est l allocation dynamique de charge de travail d un cloud vers un autre cloud. Les fonctions actuellement utilisées pour du cloud hybride sont généralement des fonctions de débordement, d embarquement de service, de montée en puissance et si la latence le permet d équilibrage de charge. Ces fonctionnalités sont bien celles attendues par le cloud hybride mais celui-ci doit aussi répondre à d autres besoins. Globalement le cloud hybride doit permettre de provisionner, de superviser, d anticiper les ressources et leurs capacités, de gérer la sécurité et le budget. Tout ceci de manière centralisée, et par étape en fonction des priorités. 41 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

43 PREMIERE PARTIE : LES FONDAMENTAUX DU CLOUD HYBRIDE ELASTIQUE Synthèse de la première partie Nous avons maintenant défini le modèle de déploiement du cloud hybride et comment tous les modèles de service sont concernés par le cloud hybride, en particulier le BPaaS, le Business Process as a Service, qui va gérer et superviser les flux d actions et de validations. Ces flux sont nécessaires pour les applications métiers et pour la gestion de l automatisation, l orchestration. Nous avons vu que l élasticité, c est du scale-out et du scale-down, et que cela permet de répondre à des pics de charge ou des projets ponctuels. Mais les mécanismes de gestion de l élasticité demandent des règles, des mesures et des algorithmes complexes, pour répondre aux besoins de capacité qui sont des besoins de puissance, de bande passante, de lecture, d écriture, de volume et surtout de temps de réponse du service. Nous avons ensuite vu les acteurs du cloud hybride parmi lesquels se trouvent le consommateur, l administrateur, le superviseur et le fournisseur de cloud hybride qui est le courtier interne. Nous avons complété en présentant des modèles de références et des solutions actuelles de cloud hybride, homogène ou hétérogène en outil de gestion. Nous avons terminé par des cas d usage et les solutions du cloud hybride élastique qui permettent d y répondre : le débordement, l embarquement, la montée en puissance, la bascule de charge. 42 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

44 DEUXIEME PARTIE : LES EXIGENCES & LES SERVICES Chapitre 1 : Les exigences des métiers et des responsables IT DEUXIEME PARTIE : LES EXIGENCES & LES SERVICES Suite à la présentation des fondamentaux, cette partie présente, les besoins du cloud hybride élastique, pour répondre aux exigences des entreprises. De ses besoins découleront les services considérés majeurs dans la réalisation du cloud hybride élastique En chapitre 1 nous verrons les exigences de l entreprise cliente et de ses utilisateurs, des métiers et celles des fournisseurs de service de cloud hybride, les responsables de l I.T. (Information Technology). Nous enchaînerons avec le catalogue de service du cloud hybride en chapitre 2. Chapitre 1 : Les exigences des métiers et des responsables IT Il faut toujours revenir aux «besoins» ou au «pourquoi?». Comme nous l avons vu dans l introduction il s agit d apporter de la valeur, de l agilité, de l efficience. C est le fil conducteur de cette étude. Ce qui va se traduire dans le cloud-computing à obtenir rapidement et simplement des services à un coût adapté. Pour faire le tour de la question il faut connaître les acteurs et leurs objectifs. Nous allons voir d abord les exigences métier qui concernent plus la stratégie et la conception, puis celles des responsables de l IT qui sont focalisées sur la mise en exploitation, la production et l amélioration continue. Des motivations différentes pour 3 types d acteurs Figure 19 : Focus sur les acteurs L entreprise prend de la commodité sur le marché des services de cloud. Mais tous les acteurs n ont pas les mêmes objectifs. Pour l entreprise, il faut apporter de la valeur de l innovation, de l agilité pour accélérer le Time-To- Market et de l efficience pour réduire les coûts et ainsi rester concurrentielle. Comme l indique la figure ci-dessus, l entreprise est centrée sur ses exigences d innovation, de rapidité, et d efficience. 43 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

45 DEUXIEME PARTIE : LES EXIGENCES & LES SERVICES Chapitre 1 : Les exigences des métiers et des responsables IT Les utilisateurs veulent des produits souples, simples et peu onéreux. Beaucoup de produits performants arrivent sur le marché offerts par des fournisseurs différents. Le fournisseur IT va chercher à se distinguer en apportant de la valeur aux entreprises tout en restant concurrentiel. Section 1 : Les exigences de l entreprise et de l utilisateur Il ne faut jamais perdre de vue l objectif. La solution doit toujours répondre aux exigences. Nous allons essayer de relever les points d attention spécifiques du cloud hybride élastique. Nous ne pouvons pas traiter de tous les cas d usage. Nous essaierons de rester le plus général possible. Nous traiterons donc des points d attention spécifique au multi-cloud pour répondre aux exigences connues, aux cas d usage les plus fréquemment rencontrés. Nous avons déjà vu (dans la première partie, chapitre 2, section 0) que les principaux usages du cloud hybride était le débordement, l embarquement, la montée en charge, le provisionnement, la supervision, l anticipation capacitaire, la gestion de la sécurité et du budget. Nous allons compléter cette vision. Les exigences de l entreprise viennent des métiers. L étude de la gestion des ressources IT doit se faire dans une perspective «métier». Chaque métier à des exigences particulières comme par exemple : - Des pics d activité prévisibles ou non (e-commerce, circulation, météo ) - Des informations sensibles (médicales, bancaires, stratégiques, réglementaires ) - Des temps de réponses (trading, 3s/3clics, ) - De la continuité, disponibilité (production, ) - Des informations largement distribuées. L IT doit d abord prendre en compte le respect de la stratégie business de l entreprise et de sa stratégie de sécurité, qui influent sur les exigences. L analyse des exigences va permettre de cerner ce qui peut aller dans un cloud et dans quel cloud. Elles sont à mettre en regard avec les garanties et possibilités apportées par les fournisseurs de cloud. Les écarts devant être analysés et éventuellement acceptés, couverts, ou refusés. Pour cette étude les processus ITIL ont servis de support à la réflexion, classés par étapes : la stratégie et la conception dans cette section, qui concerne les besoins de l entreprise et de ses utilisateurs. Ces exigences sont donc aussi celles des métiers. 44 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

46 DEUXIEME PARTIE : LES EXIGENCES & LES SERVICES Chapitre 1 : Les exigences des métiers et des responsables IT 1) La stratégie de l entreprise en cloud hybride STRATEGIE EXIGENCES DE L'ENTREPRISE A DEMANDER : POINTS D'ATTENTION SPECIFIQUES MULTI-CLOUD Les investissements cloud privés en internes sont souvent en capital alors que les dépenses sont opérationnelles, à la demande, dans les clouds externes. Les différents clouds ont des modèles de facturation tous différents et difficiles à comparer, et à centraliser.. Il faut superviser la gestion financière, mais sans enlever d agilité. Gestion financière Gestion de la demande Gestion du portefeuille de services Prévisions budgétaires, investissements et imputation des coûts Schémas de la capacité utilisée dans le temps, prévisions stratégiques Services en portefeuille et leurs contraintes dont les délais de mise à disposition Faire attention à gérer les priorités des investissements d automatisation et de centralisation en fonction des gains : la gestion de la complexité est source de coûts. Anticipation et compréhension des besoins de chaque métier qui pourront déclencher une externalisation et leur éligibilité. (Besoins ponctuels et continuité d activité) Faire attention à connaître la stratégie qui fera évoluer la demande et donc à rester interopérable. Prévision des utilisations ponctuelles, pour choisir les automatisations prioritaires, les interfaces (Advanced Programming Interface) avec des fournisseurs externes. (cf. Annexe API) Faire attention à garder un portefeuille réduit bien centré sur les demandes métier et à gérer le cycle de vie des services dans toutes les localisations. 2) La conception des services CONCEPTION EXIGENCES DE L'ENTREPRISE A DEMANDER : POINTS D'ATTENTION SPECIFIQUES MULTI-CLOUD Gestion fournisseur Gestion de la sécurité Exigences contractuelles et analyse des risques La classification des données/services, L analyse des risques et alignement avec la stratégie de sécurité Différents niveaux d'engagement pour différents services. Suivi des conformités dans le temps. Possibilité de gérer la conformité exigée par service ou type de service pour le choix du service cloud. Faire attention à suivre la conformité par rapport aux services quand ils sont déplacés d un cloud à l autre. La classification permet de savoir quelle donnée peut-être mise dans quel cloud. La conformité de l interconnexion doit être alignée aux exigences du service hébergé. Le multi-cloud multiplie les connexions entre clouds que ce soit des processus automatisés par l intermédiaire d application et d API ou des personnes, la sécurité doit être adaptée à ces nouveaux fonctionnements. La sécurité des accès et des identités entre clouds des personnes et des processus : authentification, autorisation, traçabilité et la compatibilité sont à contrôler. La sécurité des mouvements de données est à vérifier. 45 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

47 DEUXIEME PARTIE : LES EXIGENCES & LES SERVICES Chapitre 1 : Les exigences des métiers et des responsables IT Pour simplifier il faut prévoir un tableau de bord sécurité. Gestion du catalogue et niveau de service Gestion de la continuité Gestion de la disponibilité Gestion de la capacité Exigences par service à relier avec la sécurité, continuité, disponibilité, capacité. Exigences de continuité par service et risques associés Exigences de temps de réponse, de disponibilité et évaluation de l'impact Exigences actuelles, prédictions d'évolution et stratégie. Surveillance de cette évolution et seuil. La création du catalogue de service se fait en approvisionnant les services dans des clouds différents, le changement de cloud doit être transparent pour le consommateur. Les SLA du fournisseur de service ne sont souvent pas les SLA du service car le service dépend aussi de la connexion réseau et de tout autre composant rentrant dans la chaîne de livraison du service. Possibilité d utiliser du multi-cloud pour gérer la continuité pour les services par des mécanismes de redémarrage automatique, ou des services clonés en veilleuse avec multi-localisation. Faire attention à respecter les exigences de continuité d un service lors du choix de localisation. Multiplier les localisations peut diminuer les risques climatiques. Attention à l effet de la latence de passage vers un cloud sur la disponibilité du service Faire attention aux engagements de disponibilité, support compris, du fournisseur de cloud par service. Faire attention en multipliant les intermédiaires à ne pas multiplier les facteurs d indisponibilité. Gestion de la capacité par débordement dans le cloud sur un fournisseur adéquat. Centralisation de la supervision et de l optimisation Faire attention à anticiper le comportement de la demande capacitaire. Nécessite un retour centralisé des données pour pouvoir les analyser. PS : le «catalogue de service» correspond aux services «du portefeuille de service» qui sont mis à disposition des utilisateurs, conformément à la définition ITIL de ses termes. Parenthèse La conformité a une place majeure dans l entreprise. Elle doit être aussi prise en compte dans le choix et le suivi des fournisseurs. L entreprise imposera de moins en moins ses exigences dans un monde de standardisation, et qui bouge rapidement, l entreprise devra de plus en plus contrôler l adéquation entre ses exigences métier en conformité et celles proposées par les fournisseurs de cloud. Section 2 : Les besoins de l IT fournisseur de cloud hybride Après avoir géré l aspect interface client, nous allons voir les services nécessaires à l administration. Les deux étant extrêmement liés, puisque c est la stratégie métier qui donne la trajectoire de ce qui sera implémenté. Pour cette étude nous nous appuyons à nouveau sur les processus ITIL regroupés par étapes : la mise en exploitation, la production et l amélioration continue pour les besoins de l IT. Ces exigences sont celles de la production. 46 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

48 DEUXIEME PARTIE : LES EXIGENCES & LES SERVICES Chapitre 1 : Les exigences des métiers et des responsables IT 1) La mise en exploitation MISE EN EXPLOITATION EXIGENCES OPERATIONNELLES A DEMANDER POINTS D'ATTENTION SPECIFIQUES MULTI-CLOUD Gestion des actifs et des configurations Gestion des changements Gestion des mises à jour et déploiements, des tests et des validations. Gestion de la connaissance Exigences en termes de validation et de selfservice. Exigences de centralisation de gestion des ressources et configuration en hybride. Exigences actuelles et en hybride de centralisation des changements. Exigences actuelles et en hybride Exigences de documentation et responsables en hybride. Centralisation des requêtes de ressources et automatisation, orchestration de la mise en place. La gestion des mises à jour ou patching sur les applications en SaaS et en PaaS peut être gérée par le fournisseur. Le planning peut être imposé. Il faut faire attention aux relations entre applications en se basant sur la gestion des actifs et des configurations. L automatisation du déploiement et des mises à jour est un point essentiel du cloud hybride élastique pour réduire la complexité et gagner en élasticité, en disponibilité. Elle va s appuyer sur la gestion des actifs de service et des configurations. Le cloud permet de pouvoir facilement faire des retours arrière en facilitant la duplication d environnement. Attention aux mises à jour qui doivent se faire sur des services que ceux-ci soient en interne ou transférés provisoirement. Traçabilité de l emplacement 2) La production PRODUCTION EXIGENCES OPERATIONNELLES A DEMANDER POINTS D'ATTENTION SPECIFIQUES MULTI-CLOUD Gestion des accès Gestion des demandes Exigences en termes de fédération des accès, de traçabilité, de sécurité de ces données, par rapport aux possibilités des fournisseurs de cloud. Exigences de validation des demandes La gestion des accès et leur cycle de vie en interne et en externe est un point important de la gestion de la sécurité. D où la centralisation en interne au cloud hybride des identités et des autorisations associées. La gestion des demandes de ressources, dans un cloud externe, doit garder de l agilité. La délégation budgétaire est une des solutions à envisager. 47 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

49 DEUXIEME PARTIE : LES EXIGENCES & LES SERVICES Chapitre 1 : Les exigences des métiers et des responsables IT Gestion des événements, incidents et problèmes Exigences en termes de gestion des incidents, d'intégration d'outils et de processus. Les technologies sont virtualisées, la plupart des services sont automatisés et certains externalisés ce qui conduit à beaucoup de changements à anticiper aux niveaux des rôles et des compétences. Attention à la centralisation du support, en lien avec les exigences du service et les contraintes des fournisseurs de service. Cette fonction doit être réorganisée et les rôles et responsabilités doivent être définis. Une gestion des changements est essentielle. 3) L amélioration continue AMELIORATION CONTINUE EXIGENCES OPERATIONNELLES A DEMANDER POINTS D'ATTENTION SPECIFIQUES MULTI-CLOUD Gestion de l amélioration continue L amélioration continue passe par le suivi de mesures pertinentes, il faut donc savoir ce qui est essentiel pour l entreprise : coûts, disponibilité, sécurité, capacité, Faire attention à centraliser les retours d informations de tous les clouds pour pouvoir les analyser facilement et enclencher des processus de résilience automatiques. Attention à bien gérer le cycle de vie des données, en particulier au niveau des sauvegardes et des archivages délocalisés. Section 3 : L analyse des écarts entre la maturité du marché et les exigences 1) Des challenges technologiques Il faut prendre en compte les nouveaux challenges comme la notion d Any Time, Any Where, Any Device. L utilisateur doit pouvoir accéder, le plus simplement possible, n importe quand, de partout, avec n importe quel terminal. De plus il peut s agir d un utilisateur interne à l entreprise ou externe (partenaire, fournisseur, client) car l entreprise est de plus en plus collaborative. Les services aussi sont collaboratifs, un service pouvant appeler un autre service. D un autre côté les menaces sur la sécurité exigent des connexions de plus en plus sécurisées. Le CSA a classé en 2011 les menaces du cloud et il a conclu que les 3 incidents les plus fréquents étaient : - «Les interfaces et API non-sécurisées» avec 51 incidents représentant 29%. - «Les pertes et fuites de données» avec 43 incidents représentant 25% des menaces. - «Les pannes hardware» avec 18 incidents représentant 10% des menaces, mais s améliorant de même que la gestion des pics de charge. 48 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

50 DEUXIEME PARTIE : LES EXIGENCES & LES SERVICES Chapitre 1 : Les exigences des métiers et des responsables IT Cette étude nous montre qu il va falloir gérer les accès des personnes, des processus et des systèmes pour éviter les pertes et fuites de données, les interfaces et API non-sécurisées (API : Advanced Programming Interface cf. Annexe : API) 2) Entre les exigences et les capacités technologiques actuelles De cette analyse des exigences nous avons extrait, par rapport notre connaissance de la maturité des offres actuelles, les points à traiter plus particulièrement. Pour réaliser cette synthèse nous avons utilisé un SWOT (Strength, Weakness, Opportunity, Threat) ci-dessous. Nous verrons plus en détail la maturité de l offre dans la troisième partie dans l outillage. Figure 20 : Forces et Faiblesses du Cloud Hybride Elastique Pour traiter les faiblesses, il faut gérer les points suivants : - La gestion de la complexité va nécessiter une découverte et une centralisation des ressources, de leurs configurations et de leurs liens. - L automatisation, ressort comme un point essentiel de la réussite d une infrastructure de cloud hybride. Elle s appuie sur la gestion des actifs et des configurations et sur la gestion des mises à jour et des déploiements. - La gestion de la demande et des capacités est importante pour connaître les besoins, les budgets, définir une stratégie, afin d assurer une continuité de fonctionnement optimal par rapport aux exigences métier. - Les changements doivent être pris en compte dès le début du projet pour simplifier les processus et revoir l organisation. En ce qui concerne les risques externes nous verrons également le besoin de faire monter en maturité des offres actuelles en termes de sécurité, pour le cloud hybride : - La sécurité des accès des personnes, des processus et des systèmes, la gestion unifiée des identités et des autorisations sont centrales dans la gestion d un cloud hybride. 49 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

51 DEUXIEME PARTIE : LES EXIGENCES & LES SERVICES Chapitre 1 : Les exigences des métiers et des responsables IT - La sécurisation des données stockées, utilisées mais surtout en mouvement entre deux clouds sont des points sensibles. Il faut sécuriser et respecter la conformité, dans les deux clouds et entre les deux clouds par des protocoles et des cryptages ad-hoc. Ce besoin est porté par l évolution rapide des menaces : traitement massif possible du cryptage, des mots de passe, attaques distribuées comme celles de déni de service, Nous verrons en quoi les solutions open qui apportent l interopérabilité et la virtualisation de l infrastructure sont de réelles opportunités de : - pouvoir gagner en efficience, - développer plus rapidement des innovations technologiques, - pouvoir faire communiquer ensemble plus facilement des services ou solutions. Important Enfin la supervision est élément essentiel car il va porter l amélioration continue. Et n oublions pas l objectif : l agilité. Il faut éviter d introduire de nouveaux processus qui viendraient bloquer l agilité obtenue par l automatisation en créant des points de blocage, comme des processus de validation budgétaire ou de sécurité mal conçus. 50 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

52 DEUXIEME PARTIE : LES EXIGENCES & LES SERVICES Chapitre 2 : Le catalogue de service du multi-cloud Chapitre 2 : Le catalogue de service du multi-cloud Nous allons étudier ces besoins fonctionnels sous l angle du catalogue de service du multi-cloud ou cloud hybride Nous allons répondre aux exigences vues ci-dessus par un catalogue de service de gestion de cloud hybride, pour cela nous verrons le contexte et les services qui composent ce catalogue, puis nous ferons deux focus sur les engagements contractuels et la conformité en section 2, et sur le modèle de service financier en section 3. Section 1 : Le catalogue de service du multi-cloud 1) Le contexte des services L analyse du contexte par la visualisation des acteurs et des systèmes clés aide à cerner le périmètre couvert par le catalogue de service du cloud hybride élastique. Figure 21 : Acteurs et systèmes clés du Service de Cloud Hybride Elastique 2) Le contenu du catalogue de services multi-cloud Il faut toujours distinguer plusieurs «types» de catalogue de service, celui que le fournisseur de cloud hybride propose à son client et celui que le client propose aux consommateurs des services. Le fournisseur de cloud et le client peuvent appartenir à la même entreprise dans le cas du cloud privé. Comme nous venons de le voir dans le chapitre précédent : il faut automatiser. Pour connecter un cloud externe au cloud de l entreprise, il faut développer les passerelles correspondantes au catalogue d APIs, c est l intégration. Dans les clouds connectés, il faut pouvoir déployer, administrer et superviser des services. Pour cela il faut s appuyer sur des modèles, des buildings blocks, des programmes qui accepteront des paramètres afin de pouvoir réutiliser les développements et surtout déplacer facilement des charges de travail, c est le design de l automatisation qui crée des Services Templates et les utilise avec des règles, des seuils et des mesures 51 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

53 DEUXIEME PARTIE : LES EXIGENCES & LES SERVICES Chapitre 2 : Le catalogue de service du multi-cloud Figure 22 : Catalogue de Service du Cloud Hybride Elastique Nous nous intéressons au catalogue de service du fournisseur de service cloud, pour les acteurs ou administrateurs clients chargés : - de l intégration pour fournir un catalogue de passerelles, par api ou appliances, mises à disposition (APIs AWS EC2, S3, OpenStack, Salesforce, ), - du design de l automatisation de la configuration, l approvisionnement, le déploiement, le paramétrage de ressources que ce soit des ressources matérielles ou logicielles, de fonctions (bascule de charge, DNS, DHCP, Embarquement, Débordement ), de services, de flux, - de l administration : o de la configuration, l approvisionnement, le déploiement, le paramétrage de ressources, de fonctions (DNS, ), de services, de flux respectivement pour du IaaS (Stockage, Traitement, Bases), du PaaS, du SaaS ou du BPaaS, o du catalogue de service consommateur, et du portefeuille : la construction, la mise à disposition, o financière : affectation de budget, o de la capacité, o des accès et de la sécurité, o des fonctions multi-cloud : débordement, embarquement, - la supervision et l optimisation : o de la facturation et des contrats, o de l usage des services au catalogue, o de la capacité, o des performances, de la disponibilité, du respect des SLA, o de la sécurité, o des fonctions multi-cloud : débordement, embarquement, - la réalisation du support ou helpdesk, la partie alerte de la supervision, 52 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

54 DEUXIEME PARTIE : LES EXIGENCES & LES SERVICES Chapitre 2 : Le catalogue de service du multi-cloud - la configuration des règles (seuil, défaillance, analyse), La supervision du CLOUDaaS permet grâce aux remontées d information et de mesures, de comparer les performances des fournisseurs (capacité, disponibilité, rapidité, coût, sécurité ). Important En ce qui concerne le multi-cloud ces services doivent être centralisés, avec une interface standardisée. Les paramètres doivent être accessibles. La supervision doit permettre une vue d ensemble, même si l accès à chaque portail fournisseur peut rester accessible sous forme d onglet dans un navigateur. Le consommateur dispose d un portail unique extrait du catalogue de service construit par l administrateur du catalogue de service consommateur, et personnalisé à partir de ses autorisations, disponibles dans l annuaire. 3) La description des services spécifiques 2.1) L intégration : les passerelles Comme nous venons de le voir dans le chapitre précédent : il faut automatiser. Pour connecter un cloud externe au cloud de l entreprise, il faut développer les passerelles correspondantes aux APIs. Dans les clouds connectés, il faut pouvoir déployer, gérer et superviser des services. Pour cela il faut s appuyer sur des modèles, des buildings blocks, des programmes qui accepteront des paramètres afin de pouvoir réutiliser les développements et surtout déplacer facilement des charges de travail. Il faut intégrer des liens vers des clouds externes à l aide de catalogue d APIs (AWS EC2, S3, OpenStack, ). Les liens permettent d accéder via un standard RESTful (cf. Dictionnaire) aux fonctionnalités offertes par les fournisseurs de cloud. Le fournisseur de cloud hybride doit disposer d une interface ou passerelle lui permettant de faire le lien entre l interface qu il fournit à ses clients (internes ou externes), et les différents modules de compatibilité (APIs) proposés par les fournisseurs de cloud. Ces APIs sont de plus en plus disponibles via des «places de marché» (market place) ou des «magasins» (store), facturées ou offertes pour promouvoir le produit. Ces APIs sont susceptibles d évoluer, d où l importance de la standardisation, de l interopérabilité, pour simplifier le maintien. Les API(s) sont de différents types : - de calcul, - de stockage, - de réseau, - de fonctionnalités : répartition de charge, firewall, DNS, - d administration et d orchestration, automatisation : IaaS, PaaS, SaaS, BPaaS, financière, catalogue, - de supervision : permettant de récupérer des données pour analyse, - de gestion de l identité et des accès, - de support. 53 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

55 DEUXIEME PARTIE : LES EXIGENCES & LES SERVICES Chapitre 2 : Le catalogue de service du multi-cloud La passerelle du cloud hybride sert à intégrer les différentes librairies d API des clouds externes. L intégration consiste à faire le lien entre des fonctionnalités internes et externes. Les fonctions n ont pas toujours mêmes noms pour une même fonctionnalité, par exemple pour approvisionner une VM il serait possible de trouver approvm() ou appvm(), pour une fonctionnalité identique. Il peut y avoir un nombre de paramètres différents même entre deux versions comme par exemple le nombre de rôles entre la version Folsom et la version Grizzly de Keystone OpenStack. Mais surtout les fonctions peuvent être très différentes, avec des paramètres différents, des fonctionnalités différentes, des gestions de la sécurité différentes. Elles peuvent évoluer, des fonctionnalités supplémentaires peuvent être créées. 2.2) Le design de l automatisation Pour faciliter l interopérabilité du déploiement d un service quel que soit le cloud dans lequel il est déployé, il faut s appuyer sur un catalogue standardisé de «Service Template» ou «Blueprint de service». Les fonctions réseaux, stockage et calcul du fournisseur (bascule de charge, mappage, tiering), Ces fonctions existent dans le cloud, en général dans un environnement homogène au niveau des outils de gestion. Pour résoudre des soucis de bande passante il faut pouvoir grouper des réseaux (teaming). Pour répondre à des besoins de performance il faut créer des clusters de stockage ou de calcul. Dans tous les cas il faut pouvoir libérer ses ressources. Là aussi la virtualisation, le «software defined», et la standardisation de l automatisation, vont nous aider à pouvoir automatiser et donc configurer «à la volée» pour réaliser toutes ces actions dynamiquement. 2.3) La configuration du réseau et des fonctions réseau inter-cloud Il faut réussir à faire circuler des flux entrants et sortants à partir du cloud interne et du cloud externe, synchronisés. L administrateur de cloud hybride élastique doit pouvoir configurer des éléments réseaux pour affecter des adresses, choisir des protocoles, optimiser le chemin, faire de la QoS, gérer des listes de contrôles d accès, configurer des sous-réseaux, des firewalls. Ceci devient possible avec la virtualisation du réseau, le «software defined». Des routeurs virtuels et des outils de gestion type CNAM de CISCO installés dans une machine virtuelle peuvent être ajoutés chez le fournisseur de cloud externe pour réaliser une continuité opérationnelle de supervision. (Un projet d outillage open source du DNSaaS est envisagé par le groupe OpenStack.) 54 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

56 DEUXIEME PARTIE : LES EXIGENCES & LES SERVICES Chapitre 2 : Le catalogue de service du multi-cloud 2.4) Les fonctions du cloud hybride : débordement, embarquement, Pour réaliser du cloud hybride élastique il faut pouvoir déplacer des services basés sur des systèmes complexes, comme des applications «n-niveaux» (à plusieurs niveaux de type Web, Appli, Base par exemple) entre des environnements hétérogènes en termes de technologie, de fonctionnalité. Les fonctions du cloud hybride s appuient sur deux autres services du cloud hybride : le design de l automatisation et la configuration de la connexion réseau entre clouds. Les fonctions nécessitent de : - Configurer des conditions (seuil, défaillance, analyse), - Configurer des méthodes de bascule de charge (snapshot, clone, image, pattern, runbook, mappage) et les services templates associés. - Faire le suivi des fonctionnalités des liaisons existantes (interface, sauvegarde, etc ). 2.5) L administration de la gestion de l identité et de l accès La gestion de l identité et des accès, pour faire une continuité entre l interne et l externe, est intégrées dans les passerelles par des APIs spécifiques. L objectif est le Single Sign On, c est à dire que l utilisateur du service ne s authentifie une seule fois sur le portail d accès. Il est important cependant de continuer à savoir, qui fait quoi, et donc de pouvoir tracer l identité dans le cloud externe. Il faut donc mettre en place un mécanisme de confiance entre les clouds, par certificat, clés publiques, qui vont servir lors de l authentification par token et transmettre l identité de l utilisateur ou du processus automatisé. 2.6) La gestion de la demande et de la capacité La gestion de la capacité va s appuyer sur la connaissance des ressources. C est une exigence et donc un service majeur. Il entre dans la gestion du cycle de vie. a) La gestion de la demande et la proximité métier La capacité service et la capacité composants se déduisent des besoins de capacité business. Sur du cloud privé, en fonction de la taille du Datacenter, des limites de variation de capacité peuvent être nécessaires pour pouvoir répondre aux variations de charge. Tous les utilisateurs ne peuvent pas doubler en même temps leur capacité : pour limiter le risque il faut préconiser des tarifs heures de pointes et heures creuses, ou une gestion de règles de priorité platine, gold, silver peuvent aider à lisser la demande en automatisé. Il faut comprendre et anticiper les besoins de chaque métier qui pourront déclencher du débordement, un déplacement ou une demande de continuité et leur éligibilité à l externalisation : les pics de charge, les projets, les analyses massives de données, les services sensibles ou critiques. Ceci peut paraître simple mais demande une implication forte : des métiers dans l expression de leurs exigences, et des responsables IT pour le traduire en solutions, en services. 55 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

57 DEUXIEME PARTIE : LES EXIGENCES & LES SERVICES Chapitre 2 : Le catalogue de service du multi-cloud b) La gestion de la capacité En cloud hybride il faut récupérer les indicateurs des divers clouds, pour les gérer, les superviser, les améliorer. La gestion de la capacité en phase de transition et opérationnelle c est aussi automatiser, mesurer, auditer, analyser, pour optimiser les ressources, améliorer la fiabilité, la rapidité, la résilience et aider le respect des niveaux de service contractualisés (Cf. : Développement des processus dans la troisième partie). Section 2 : Les engagements contractuels et la conformité 1) Les engagements contractuels dans le cloud hybride 1.1) La contractualisation des niveaux de services Les S.L.A. ou Service Level Agreement sont une contractualisation sur des niveaux de service entre le fournisseur d infrastructure et son client. Les O.L.A. ou Operational Level Agreement sont la déclinaison de ces engagements, avec les acteurs internes ou sous-traitants qui contribuent au respect du contrat. Dans le cloud public cette donnée est souvent imposée par le fournisseur de cloud, car liée à son infrastructure. Le rôle du client est alors de comparer les exigences du service, les S.L.R. ou Service Level Request, avec celles accessibles en externe pour savoir s il externalise. a) La relation entre service et exigences métier L outil de gouvernance doit donc associer à chaque service en fonction de la classification du service ses caractéristiques de : - disponibilité (temps d indisponibilité maximum, temps de réponse, temps d accès), - sauvegarde (rétention, fraîcheur, point de restauration, planification), - capacité et performance de ces capacités (puissance, stockage, bande passante), - sécurité et conformité (traçabilité, auditabilité, localisation, logging, rapports), - facturation (historique, fréquence). Un service ne peut migrer d un cloud à l autre que si le service fourni reste conforme aux exigences. Nous avons donc un ensemble de règles par service à contrôler. b) L enchaînement des SLA Le SLA de disponibilité de 99,9 du fournisseur de cloud n est souvent pas celui du service, car il faut le multiplier par le SLA de la connexion internet. Il en est de même avec le cloud hybride, où les éléments de connexion et de gestion centralisée doivent être pris en compte dans la chaîne complète de la disponibilité. D où l importance de bien étudier la redondance et la résilience de TOUS les éléments de la chaîne, et ceci pour TOUS les engagements de service. Les engagements internes ou sous-traités 56 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

58 DEUXIEME PARTIE : LES EXIGENCES & LES SERVICES Chapitre 2 : Le catalogue de service du multi-cloud Dans un cloud hybride élastique, quand l entreprise s engage sur des SLA avec ses clients métiers, elle doit porter une attention particulière aux engagements opérationnels OLA, afin de vérifier la faisabilité de ses engagements. Important Ceci se traduit concrètement par l enregistrement dans les règles, du niveau de conformité souhaité par service. Il faut ensuite superviser les mesures ou métriques associés, afin de vérifier la continuité lors du déplacement du service d un cloud à l autre, et l évolution de la qualité de service dans le temps. 1.2) Le suivi par les métriques en cloud hybride Le suivi de cette contractualisation se fait par les Service Level Operationnal (S.L.O.), les mesures (métriques) et l évolution (Key Product Information). Le choix de métriques ou d indicateurs de performance clés sont fonction des possibilités offertes par le fournisseur de cloud. Important Ces indicateurs sont calqués sur les exigences du service de l entreprise. Leur ajouter des contrôles internes est essentiel : les indicateurs clés de disponibilité et de temps de réponse pour un service peuvent être mesurés par l ajout d applets au niveau du poste client, par exemple. Dans un cloud hybride le client doit pouvoir suivre le respect des exigences de service en disponibilité, continuité, sécurité, performance, par une fédération des remontées de métriques standardisés et par des mesures internes. Des outils sont donc indispensables, au niveau de l hyper-orchestration, pour assurer le suivi. 2) La conformité Le fournisseur de service peut être conforme à des recommandations, des réglementations, des lois, des normes, des standards. Cette conformité va s appliquer à l ensemble du cloud hybride, y compris par exemple le cloud sur lequel un fournisseur de cloud va transférer des sauvegardes, mais plus particulièrement pour un cloud hybride il faut assurer la conformité des fournisseurs de cloud et de la liaison qui nous relie à eux. Par exemple une connexion conforme PCI-DSS 3.0 de paiement carte bleue, doit respecter les prérequis y compris pour le transfert. Ceci nous oblige à engager nos fournisseurs à être transparents sur leur fonctionnement pour s assurer que les services confiés respectent bien les niveaux de conformités requis, les exigences du service. Et faire un suivi de l évolution des conformités 57 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

59 DEUXIEME PARTIE : LES EXIGENCES & LES SERVICES Chapitre 2 : Le catalogue de service du multi-cloud Exemples de conformités : CNIL, ISO , SSAE 16, SOC_2, ISO , ISO 27002, PCI DSS, SOX, Bâle, Cobit, SAS170, EAL4+ et (FISMA=0S). Section 3 : La vue financière du modèle de service 1) Les modèles de facturation 1.1) Les challenges du calcul des coûts a) Les challenges Les modèles de facturation se heurtent à plusieurs challenges : - le calcul des coûts en interne, leur répartition, - le suivi de la consommation en interne par des outils de charge back, - le suivi et l agrégation des coûts externes renvoyés par les outils de charge back externes, - les choix de facturation interne et de répartition. b) La répartition des frais de structure du cloud hybride Les charges du cloud hybride : hébergement, sauvegarde, réplication, infrastructure et logiciel, consommation, maintenance, support, sont à répartir logiquement sur le cloud privé et sur l approvisionnement externe. c) Les charges du cloud privé spécifiques en transverse Nous sommes sur le même modèle que la répartition des charges dans une copropriété ou une colocation. Les charges transverses doivent être réparties au prorata de l utilisation, et le copropriétaire ou colocataire, pour nous le service, doit pouvoir anticiper ses charges. Si vous voulez rajouter une prestation sur votre environnement, porte blindée, serrure 3 points, c est à la charge de l intéressé. De même pour le service si on doit ajouter de l isolation. Par contre l entretien de l ascenseur et des parties communes sont partagées. A ce niveau-là par contre sur les services, il peut y avoir une différence de facturation sur les flux entrants et/ou sortants, mais ce n est pas systématique. Il existe des immeubles de standing différents avec déjà différents niveaux de sécurisation : caméras, interphones avec des horaires de concierge différents qui influent sur le prix de location de l appartement et sur les charges. De même dans le cloud il faut trouver une répartition équitable des charges communes, qui est par contre inclus dans le prix de base de la location du service cloud. Les services cloud sont de différents niveaux : support, isolation, disponibilité et ceci se répercute sur le prix de mise à disposition d internet. L agrégation des informations servant à la facturation La tarification peut se comparer à celle du téléphone ou du parking : l instance peut être facturée dès que le mois, l heure est entamée ou sur le temps réellement utilisé, mais il ne faut pas oublier que plus l outil de mesure est précis, plus le flux d information prend des ressources. De plus il faut agréger pour en faire un tableau de bord simple et fonctionnel. 58 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

60 DEUXIEME PARTIE : LES EXIGENCES & LES SERVICES Chapitre 2 : Le catalogue de service du multi-cloud Les difficultés techniques Nous sommes sur les problématiques habituelles, comme par exemple la difficulté à répartir le coût d une vcpu, sachant qu il y a plusieurs vcpu pour une CPU, que beaucoup sont sous utilisées et que généralement c est la réservation de vcpu que l on facture et non son utilisation. Les charges élastiques Les charges élastiques externes sont facturées à l usage par le fournisseur de cloud. La mise à disposition des outils de gestion d alignement de la capacité sur les besoins, est également facturée (cf. CloudWatch d AWS, ). Les charges élastiques internes En général un moteur est intégré dans les instances pour mesurer tous les éléments qui serviront à l application de facturation qui dispose des paramètres des engagements financiers. 1.2) Le modèle marketing et modèle coût de possession Il existe globalement deux approches : marketing ou marché et TCO Le client a besoin d un retour sur investissement en valeur pour le métier ou par une baisse de coûts. Le fournisseur doit couvrir ses coûts. Il existe des produits d appels et des produits de forte consommation. La maîtrise des coûts pour le client est un aspect essentiel du cloud hybride élastique ouvert, elle va permettre au client de changer de fournisseur de service ou de type de service facilement en fonction de l évolution des prix, des performances, de la qualité de service de son fournisseur, de ses concurrents, de l évolution de sa consommation, de ses besoins. Elle lui permet aussi beaucoup plus d agilité et de ne payer que ce qu il consomme. Le modèle marketing va prendre en compte ses différents aspects. 1.3) Les exemples de modèle financier Le modèle financier va s adapter aux exigences. Dans un modèle de cloud hybride élastique les services sont approvisionnés en rapport d abord avec les exigences et ensuite au meilleur coût. Les exigences peuvent être de disponibilité, de sécurité, de capacité a) Un exemple de modèle financier fonction de la capacité La capacité peut-être de traitement, de stockage ou de réseau. Il est possible donc d implémenter un modèle de mesure pour paiement basé sur la consommation, de type CPU/heure, utilisateur/web conférence/heure, Transaction de base de données/go/mois. Le système de paiement peut aussi être basé, de façon complémentaire ou non, sur la prédictibilité de la demande ou l engagement. Ce qui permet de pouvoir mieux anticiper la capacité, il y a alors moins besoin de surcapacité prévisionnelle, ce qui baisse les coûts. C est moins vrai sur des clouds s appuyant sur des datacenters massifs. 59 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

61 DEUXIEME PARTIE : LES EXIGENCES & LES SERVICES Chapitre 2 : Le catalogue de service du multi-cloud Par exemple pour répondre aux besoins de capacités et à des montées en puissance : - Paiement à la demande : les ressources allouées à la demande sans pré allocation. Pour les besoins provisoires de ressources, utilisées ponctuellement, pour une courte durée, et jetées. - Réservé : 100 % des ressources sont réservées et garanties. Pour des applications à consommation stable et prévisible. Le tarif peut être moindre mais avec engagement. - Alloué : un pourcentage des ressources est réservé avec un engagement pour une surdemande. Pour des services avec une consommation de ressource qui monte en puissance et qui libère dynamiquement. Important Dans le cloud hybride ces règles doivent être écrites pour allouer dynamiquement les services. b) Un exemple de modèle financier fonction de la sécurité Pour faire de la sécurité des données ou des services : de l isolation, du cryptage, des sauvegardes, du stockage, augmenter la disponibilité, suivre les logs, prévoir la continuité de service il faut des outils et ses outils ont un coût. Le modèle financier doit donc les intégrer. Ces caractéristiques seront en fonction des clouds choisis soit de base, soit en option, soit nonfournies. 2) Les modèles de gestion financière en interne En interne le catalogue de service doit prendre en compte l administrateur financier. En effet après avoir créé de l agilité il ne faudrait pas la reperdre par des processus de validation fastidieux. De même qu il sera intéressant de déléguer des plages IP pour l attribution automatique, il est important de déléguer des budgets pour laisser de la souplesse d action aux métiers pour ne pas courir le risque de voir se développer de la «shadow IT». Le catalogue de service du cloud hybride doit donc inclure des services qui permettent au financier de déléguer, mais aussi de superviser, en liaison avec l usage, d analyser, de planifier. 60 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

62 DEUXIEME PARTIE : LES EXIGENCES & LES SERVICES Synthèse de la deuxième partie : Exigence et catalogue de Service Synthèse de la deuxième partie : Exigence et catalogue de Service Pour résumer cette partie, nous vous proposerons deux schémas : - Le premier bâti suite à une analyse basée sur les étapes ITIL : stratégie, conception, mise en exploitation, production, amélioration, résume les exigences essentielles du cloud hybride élastique. Le deuxième résume le catalogue de service du cloud hybride élastique : L importance de l automatisation/orchestration, de l intégration des APIs et de la sécurité sont ressortis comme centraux en ce qui concerne les mécanismes. La nécessité de gérer le changement en amont du projet est un élément capital de la mise en œuvre. 61 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

63 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 1 Les processus TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Nous étudions les processus en chapitre 1 et l outillage en chapitre 2. Nous nous intéressons à ceux qui sont essentiels pour réaliser les services du cloud hybride élastique, qui sont ressortis de notre analyse des exigences et des services du cloud hybride élastique. Chapitre 1 Les processus Nous focalisons sur les processus d automatisation et d orchestration. Puis nous aborderons les processus d accès, de supervision de la capacité et de centralisation de la facturation sans lesquels il serait impossible ou difficile d automatiser. Parenthèse Dans la définition ITIL un processus est un ensemble d activité structuré, conçu pour accomplir un objectif spécifique. Un processus à une ou plusieurs entrées définies, qu il transforme en une ou plusieurs sorties définies. Donc pour chaque processus nous regarderons les entrées, les sorties et les activités. Sans maturité des processus, impossible de faire du cloud efficient. Le cloud hybride élastique est encore plus exigent en terme de maturité. Nous avons vu dans la partie précédente que les processus importants pour la gestion du cloud hybride étaient : - la gestion des actifs de service et de leur déploiement, leur configuration, leur mise à jour, - la gestion de la capacité qui inclut la supervision, l analyse et l amélioration des performances, - la gestion financière, - la gestion de la sécurité. Section 1 : Les processus de mise à disposition Dans les processus de mise à disposition nous allons retrouver l inventaire, la configuration, le déploiement, le changement mais pour le cloud hybride élastique l important est l orchestration de l automatisation. 1) L inventaire complet dynamique et la configuration. Entrées /Sorties La complexité des systèmes ne permet plus de les gérer artisanalement. Ceci implique une mise à jour automatique par des moteurs des configurations et donc une normalisation, standardisation, des remontées de données : - Pour le matériel, par des mécanismes de plug and play avec des puces qui permettent de remonter les caractéristiques de la ressource. 62 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

64 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 1 Les processus - Pour tous les logiciels, dans les formats standards. Certaines des données sont alors stockées dans les bases du fournisseur de cloud qui doit pouvoir échanger des données avec celles du cloud hybride. Il est important de pouvoir échanger nonseulement les données, mais aussi leurs typologies, leurs schémas. La standardisation est importante pour simplifier l intégration. Certaines données sont remontées directement par les mécanismes de découvertes dans les bases du cloud hybride. Les données ainsi stockées dans des bases feront partie des entrées des processus d automatisation. Les activités du processus de découverte sont de : - répertorier les ressources, - historiser les configurations, - connaître les relations entre les composants, - mettre à jour. Les capacités et les possibilités de ses ressources sont les bases de l automatisation. 2) Le déploiement et la mise à jour 2.1) Le déploiement classique Entrées/Sorties Les ressources de traitement, de stockage, de réseau et applicatives une fois découvertes et placées dans des bases, doivent être configurées. Par exemple pour l infrastructure : - La puissance de traitement est groupée en cluster, pool, accueille un hyperviseur, un OS, outils, - Le stockage est groupé en cluster, le type de file system est choisi et appliqué au formatage, le stockage est attaché et partagé, des mécanismes de duplication, réplication, tiering, zonage sont mis en place, - Le réseau est groupé en teaming, le firewall est configuré par VM ou par groupe de VM pour isoler des multi-tenants, des sous-réseaux ou des VLAN sont créés, Et également pour la partie plateforme applicative et celle des business process : - L application ou l operating système sont installés et paramétrés, - Les flux d actions sont paramétrés, Donc le processus de déploiement consiste à : - configurer, regrouper et relier les ressources, - mettre à jour les versions. 2.2) Le déplacement, la copie ou le redéploiement du service Dans le cloud hybride élastique les charges de travail se déplacent et les copies sont reconfigurées à la volée. 63 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

65 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 1 Les processus Déplacer Pour Contre Clone de VM Temps de déploiement Rigide + Soucis de Compatibilité Blueprint, composants, topologie Souple Temps de déploiement Ce processus a donc en entrée un service qui doit être déplacé pour fonctionner dans un autre cloud. a) Le service déplacé ou redéployé La question qui se pose pour le déplacement est de savoir si on déplace un template, un clone, un snapshot, ou un blueprint de la machine virtuelle, ou du volume de stockage. Parenthèse Le template, ou exemple, de VM correspond à un master, une image qui va pouvoir servir à déployer plusieurs instances. Le clone, ou copie, de VM est une copie d une machine virtuelle existante déployée et paramétrée, il sert plus à sauvegarder un environnement, de développement par exemple, que l on est susceptible de reprendre. Le snapshot, ou instantané, de VM est plus utilisé pour faire une sauvegarde à un instant T, avant d effectuer des modifications, pour pouvoir faire un retour arrière si la modification ne convenait pas. Le blueprint de VM est une image à l état brut et d un ensemble composé d informations qui vont nous permettre de déployer une machine virtuelle. Le Service Template est composé de l ensemble des composants permettant de redéployer un service : comportement, topologie, Le service est un ensemble, il est souvent très complexe. Les services sont généralement composés d un ensemble de système et d un ensemble applicatif. Il s agit souvent d applications multi-niveaux (n-tiers). La figure ci-dessous est un exemple de ce que nous trouvons en entrée sous forme de composants, de topologie, de comportement et en sortie, sous forme d implémentation spécifique, d un processus de déploiement. 64 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

66 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 1 Les processus Figure 23 : Exemple de complexité de service multi-niveaux Déplacer un service c est donc déplacer et reconfigurer un ensemble constitué de machines virtuelles, de stockage (qui contiennent des données, des fichiers des bases de données, des applications), de réseau et de liens internes et externes, avec une topologie et ses contraintes, ses règles, ses politiques, ses conformités. Il est possible de déplacer un service en changeant ses paramètres, en fonction du cloud sur lequel il va se situer. Il est possible de déplacer un service en changeant sa topologie, par exemple si l on a un environnement de développement et que l on souhaite un environnement de production : le nombre de VM, l isolation, peuvent changer. Parenthèse : l interopérabilité Il faut transformer les images pour les rendre compatibles : enlever les outils propres à chaque cloud (moteur, outil de mesure, de facturation, ). Pour être compatible avec des clouds hétérogènes on utilise ce qu on appelle des images à l état brut de services, interopérables, les blueprints, sans les outils. Les outils propres à chaque fournisseur de cloud comme ceux de facturation, ou de lancement de tâches, sont souvent non-compatibles d un cloud à l autre ou d un standard différent. Des standards de Topologie type TOSCA, se développent et vont permettre de déployer des applications complexes quel que soit le cloud. Le service doit pouvoir se déplacer avec son environnement : sa politique de sauvegarde et de restauration, de sécurité, de configuration, et s adapter à son environnement d accueil : ses outils de sauvegarde, de facturation, d automatisation, C est en général plus long qu une copie, puisqu il faut redéployer. La technologie ne fera sans doute pas du temps réel de redéploiement pour la plupart des services. Les activités pour redéployer sont globalement : - d établir la liaison après choix du service cloud, - de faire la copie, et le rassemblement des composants dont la structure du service et son scénario de déploiement, - de copier ou déplacer tous les éléments, de dérouler le scénario (configuration, déploiement), 65 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

67 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 1 Les processus b) Le Lancement du service Nous séparons les deux processus : copie/déploiement et lancement. La copie est réalisée en amont du besoin et prête à être lancée. Ce processus de lancement de service est déclenché soit à la fin du déploiement, soit par un seuil sur la capacité ou à un moment planifié. Des critères doivent être établis pour libérer la ressource, soit sur la capacité, soit sur une durée de vie ou autre. Les activités de ce processus sont : - de vérifier les seuils ou demande, - de lancer le service. 3) L automatisation, l orchestration Le nombre exponentiel d opérations de service, la fréquence des changements et l augmentation du nombre de service externes démarrant à la demande requièrent une approche d automatisation / orchestration. 3.1) Le processus d automatisation Figure 24 : Exemple de processus d approvisionnement de service en hybride La principale entrée du service d automatisation est la demande d action : déploiement d un service, déplacement d un service d un cloud à l autre, libération de service Pour automatiser il faut d abord mettre par écrit les scénarios qui vont nous servir à définir la topologie du service et approvisionner tous les composants matériels et applicatifs. Ses scénarios sont contrôlés par : - des règles (what if), - des profils ou rôles, 66 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

68 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 1 Les processus - des seuils, des déclencheurs, - des exigences de disponibilité, conformité, sécurité, coût, SLA,, - des mesures, - des flux d approbations. L automatisation va enchaîner des instructions de travail, qui vont permettre de configurer et relier des composants des services. Les activités de l automatisation dépassent celles du déploiement et de la configuration : - configurer les ressources, - enchaîner les processus de configuration, - mettre à jour la base de ressources intégrées, - de superviser, analyser, corriger à partir des données de supervision remontées 3.2) Les différents niveaux d orchestration Important Figure 25 : Les niveaux d'orchestration du CLOUDaaS L orchestration va enchaîner des briques d automatisation. La nuance entre orchestration et automatisation n est pas toujours claire. Le mot «orchestration» est utilisé pour le niveau au-dessus qui permet un aspect transverse et intègre des règles complexes, des buts et objectifs plus larges, même s il s agit toujours bien d automatiser. En IaaS des scénarios de déploiement et de configuration d infrastructure (du matériel aux fonctions), en PaaS des scénarios de déploiement et de paramétrage d applications (middleware, application, base de données, framework, SDK ), en SaaS des scénarios de paramétrage logiciel couplés au profil utilisateur, en BPaaS des scénarios de paramétrage de flux de travail, d approbation. 67 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

69 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 1 Les processus L orchestration technique ou système : - flux d actions techniques, - modifier un firewall, - ajouter un middleware, - créer un serveur scripts, Figure 26 : Orchestrer, automatiser, gérer en hybride L orchestration les environnements : - déploiement d application (vapp), - déploiement de systèmes complexes (vsys), - déploiement de VApplication - gestion capacité, placement, élasticité L orchestration des applications, des services : - supervision, - interactions entre équipes, - approbations, - réservations & quotas, - mise en exploitation, - facturation, - mise à jour des bases CMDB, CMS, - intégration systèmes tiers. L orchestration de flux métier, de business processus : - flux d action, - flux d approbation - supervision des flux et amélioration. Pour les applications plus complexes les scénarios de déploiement et de configuration enchaînent les scénarios simples, et peuvent lier des scénarios de déploiement et de configuration d infrastructure et d application par exemple pour des applications n-tiers. 68 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

70 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 1 Les processus 1-Charge Consommateur de service cloud Firewall Agent de service de montée en charge Instances Serveur virtuel 2-Réplication Figure 27 : Exemple de processus de montée en charge Pour des fonctions de type équilibrage de charge, ou de montée en puissance n-niveaux, les scénarios enchaînent les actions de provisioning, de configuration, de paramétrage de ressources. Des outils de mesures remontent les données et des règles fixent les seuils de déclenchement des actions. Les scénarios peuvent être couplés à des flux d approbations, d actions ou d informations. Les scénarios d orchestration enchaînent des scénarios, IaaS, PaaS, SaaS et BPaaS, en dépassant les frontières des modèles de service. Les services d orchestration cloud sont composés d architecture (topologie, schémas, scénarios), d outils et de processus définis par des personnes, s appuient sur du matériel et du logiciel, connectent et automatisent des flux d actions technique, application, service, métier pour délivrer un service défini. C est eux qui permettent l élasticité du cloud hybride 4) L orchestration de l hybride Important Pour le «Cloud as a service» il s agit d abstraire la notion de cloud. Le consommateur de service doit approvisionner un service sans se soucier du cloud sur lequel ce service tourne. Pour les administrateurs c est un peu différent, ils ont besoin de visibilité. Avant de pouvoir administrer simplement il faut pouvoir automatiser à partir d une interface unifiée le déploiement de service sur de multiples cloud. C est une fonction essentielle de l outil de gestion de clouds. 69 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

71 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 1 Les processus 4.1) L Orchestration de l hybride Figure 28 : Orchestration du déploiement en hybride Il s agit d orchestrer un service de bout en bout, quel que soit son modèle de service et à travers des modèles de déploiement multiples : public, privé, communautaire et des modèles de services multiples : IaaS, PaaS, SaaS et BPaaS. L orchestration de l hybride doit être en mesure pour le provisionnement : - de transmettre des scénarios à l orchestrateur d un cloud externe, - de fournir des informations de démarrage, de déploiement ou de décommissionnement à de multiples clouds par des interfaces (API, matrice de compatibilité, ), - d assurer le déplacement de tous les composants des modèles de déploiement (Services Templates), des charges de travail, et d informations, en fonction de critères techniques ou métiers, - d assurer la sécurité des services et des informations déplacés, - de pouvoir maintenir les interfaçages des services déplacés, - de rendre «transverse-cloud» des flux d actions. Pour le contrôle : - de mesurer, superviser techniquement, - de mesurer, superviser la facturation et la consommation, Pour ceci il faut des interfaces, de la normalisation et une faisabilité technique. 70 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

72 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 1 Les processus Section 2 : La capacité 1) Le processus de gestion de la demande L entrée principale est le schéma dans le temps de la demande, et les prérequis des services, qui permettent d analyser la saisonnalité de la demande et de savoir la continuité, la capacité et la disponibilité exigées par le service. Il va servir à planifier la capacité, à anticiper les pics de charge qui peuvent conduire à une externalisation de service. 2) Les processus de gestion et de supervision de la capacité Les activités de supervision, de suivi des performances vont nous permettre d enclencher du support mais aussi de suivre les performances et les capacités. Dans le cloud hybride c est la supervision capacitaire qui permet d enclencher le débordement, l embarquement d une charge de travail dans un cloud externe. 2.1) La mesure et le contrôle Le suivi est indispensable pour l optimisation de la capacité utilisée, la performance, la continuité de service, et permet de gérer l efficacité, la base de connaissance, l amélioration continue Dans le processus d automatisation les valeurs mesurées sont comparées à des seuils et déclenchent des actions prévues dans un scénario. Dans le cloud hybride élastique c est un élément central de déclenchement de déploiement et de décommissionnement de ressources. 2.2) L analyse L historique des mesures et des déclenchements peuvent alimenter une base de connaissance pour améliorer le fonctionnement global. Dans le cloud hybride de Sogeti SkySight, des tableaux de bord sont disponibles pour les différents responsables : technique, exécutif, financier. Section 3 : La gestion financière Dans un esprit de service, détacher l administrateur financier des rôles d administrateur technique permet de mieux gérer son budget. L administrateur budgétaire client va pouvoir gérer des délégations budgétaires, effectuer le suivi de la facturation multi-cloud, comparer les prestations de services des différents fournisseurs cloud. 1) La délégation budgétaire Les utilisateurs doivent souvent recevoir une approbation pour utiliser un service. Parfois cette approbation est par type de service. Quand il s agit d approvisionner des ressources en externe le 71 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

73 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 1 Les processus suivi financier est capital et le risque est grand de bloquer l agilité acquise par l automatisation par des processus de validation budgétaire trop lourds. Il est intéressant de pouvoir affecter des budgets, par un mécanisme de délégation budgétaire. C est alors au portail du cloud hybride de fournir un tableau de bord au consommateur de service pour qu il puisse à la fois gérer ses demandes de budget, leur validation, l évolution de sa consommation et de son budget. C est une fonctionnalité intéressante que l on retrouve par exemple dans Enstratus, outil de gestion centralisé de cloud. 2) Le suivi de facturation centralisé La centralisation du suivi va permettre de gérer plus simplement la complexité. Elle permet de suivre en temps réel la facturation et de pouvoir mettre des seuils d alerte. Ce processus dispose en entrée des remontées de facturation des différents clouds, par un système d interfaçage, soit en temps réel soit sur abonnement en fonction du mode de facturation choisi. 3) La comparaison de services Il est possible de vouloir un processus de comparaison de tarifs de fournisseurs de services cloud, par simulation, pour des services standards de stockage ou de traitement, par exemple. Pour affichage sur un tableau de bord ou afin de pouvoir automatiser le choix du cloud le moins cher pour le même service. Il est intéressant de pouvoir analyser sa consommation dans le temps pour l optimiser, mais aussi de pouvoir vérifier l utilisation des ressources réservées. Section 4 : La Sécurité Nous ne traiterons pas de tous les aspects sécurité, qui comporte beaucoup d éléments pour nous concentrer sur les éléments vu dans l analyse des exigences et la définition du catalogue de service du multi-cloud : - la configuration de la sécurité, - les mouvements de donnée sécurisés, - la gestion des accès et des identités. 1) La configuration de la sécurité Pour pouvoir configurer la sécurité par : Access Control List, sous-réseaux, firewall, il faut le paramétrage en soit possible à la volée. C est le cas pour les composants réseaux virtuels grâce aux networks overlays ou superposition réseau, par exemple, comme nous le verrons dans le chapitre suivant. Le processus de configuration réseau peut alors être centralisé. Le processus de configuration réseau doit permettre également de travailler avec des protocoles sécurisés : https, SSL, IPSec. 72 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

74 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 1 Les processus 2) Les mouvements de données sécurisés L établissement de liaison sécurisée se fait par des mécanismes de tunnel et de cryptage. Les algorithmes de hachage pour la cryptographie, peuvent crypter les données. Pour le stockage les données sont sauvegardées cryptées. Pour effectuer des traitements sur les données il faut aussi pouvoir les décrypter dans le cloud externe. L autre point essentiel pour sécuriser les données est l authentification des accès, la vérification des autorisations et la traçabilité. 3) La gestion des accès et des identités Dans le cloud hybride les processus automatisés ont un rôle capital, nous allons étudier l aspect authentification d un processus automatisé et d un utilisateur. Nous étudierons également l aspect autorisation. 3.1) Un cas simple de gestion de l identité et des accès à un service Figure 29 : Modélisation du processus de gestion des accès et de l'identité Dans le cloud hybride l entreprise peut décider de conserver la base d authentification et d autorisation de ses utilisateurs. Elle n aura sans doute pas envie de dupliquer ces bases dans de multiple cloud ce qui l obligerait à en gérer la synchronisation et serait un peu difficile en terme de sécurité, tous les clouds étant différents dans leur niveau de sécurité. C est donc le cloud hybride de l entreprise qui s authentifie auprès du fournisseur de cloud, et cette connexion doit être sécurisée par des envois de clé et du cryptage. Par contre pour des raisons de traçabilité, l identité de l utilisateur doit parfois être transmise ainsi que ses autorisations dans le service. Une synchronisation régulière des autorisations de l utilisateur sur le service suffit à gérer toute modification des droits de l utilisateur. La figure ci-dessus représente une modélisation simplifiée du processus, sans décrire tous les échanges nécessaires à l établissement des clés, ni le processus d initialisation de l authentification entre cloud. 73 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

75 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 1 Les processus Ce modèle simplifié ne prétend pas correspondre à tous les cas d usage. Chaque cas nécessite une mise en place de sécurité adéquate. Cependant la gestion de l accès et de l identité est un réel challenge pour le cloud hybride élastique. D autres challenges accompagnent l évolution vers le cloud. Les services sont utilisés par des identités externes obligeant à séparer les ensembles d identités, tout en les fédérant. Tandis que les applications font de plus en plus souvent appel à d autres applications dans une structure différente il faut alors partager l identité entre différentes applications. 1.1) L authentification a) Echange de clés publiques, Certificat L entreprise s authentifie, c est elle qui s inscrit de manière automatisée. Quand un utilisateur de l entreprise s authentifie, il ne souhaite souvent pas s authentifier à nouveau, il s est déjà connecté sur son réseau d entreprise, c est le Singl Sign On, l authentification unique. C est un mécanisme conforme au SSO qui fait le lien et va transmettre qu il s agit d un acteur de confiance. Le cloud interne et le cloud externe s authentifient comme acteurs de confiance pour pouvoir échanger plus tard les Token. b) Les API échangent des Token Chaque API met à disposition des actions appelées par les programmes de la passerelle avec des paramètres de configuration et de sécurité. Les actions demandées dans le cloud hybride sont traduites dans le langage du fournisseur externe de cloud. Exemple: API AWS EC2, API AWS S3, API AWS Load-Balancing, API AWS CloudWatch. Les APIs sont sécurisées par des protocoles HTTPS, SSL, par des standards comme GSS-PCI de l IETF, le W3C pour les API-Web, par les signatures niveau 2 et 4 d AWS, par la gestion d identité Keystone et des Token pour les API OpenStack. Important Pour récupérer un jeton ou Token, qui permette de faire fonctionner les processus automatisés, l utilisateur dispose en général d une clé et d un code ou secret. Il est fortement conseillé que l envoi de ses informations soit sécurisé par des protocoles type SSL, du cryptage, que le jeton ait une durée limitée dans le temps et que ses droits soient délimités, pour éviter par exemple qu un processus soit détourné avec un jeton piraté. 1.2) L autorisation Par contre pour des raisons de traçabilité, il faut pouvoir savoir qui fait quoi dans un cloud donc son identité doit être transférée, de manière unique, il peut s agir d un numéro d identification, unique dans l entreprise, si la réglementation et la législation l autorisent, puisque la base faisant le lien sera 74 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

76 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 1 Les processus disponible dans l entreprise cliente. Donc c est l entreprise cliente qui s authentifie et fournit l identification de l utilisateur, par des mécanismes automatisés, donc par le biais d API. Il est important de fournir une identification pour la gestion des autorisations. Les API peuvent inclure un nombre de rôles différents. Par exemple entre la version Folsom de Keystone et la version Grizzly, le nombre de rôle est passé de 3 (user, tenant, project) à 4 niveaux de rôles. C est loin de permettre des sécurités très fines. La normalisation de rôle et leur transfert en paramètre, peuvent être une solution. Une autre solution est de partager une base d autorisations et d affecter à chaque processus une identité et des autorisations. De nouveaux challenges pour des mécanismes comme oauth et XACML, SDDL, les référentiels et les répertoires d identité de type LDAP (Lightweigth Directory Access Protocol) ou Active Directory. 1.3) Les challenges Dans le monde du cloud, voici trois challenges importants : - Authentifier et donner des autorisations à un utilisateur dans un service externe sans dupliquer les bases (XACML). - Créer des ensembles d identités : externes et internes. (SAML, OpenID, WS-FS) Pour gérer ce point des bases de fédération, d identité interne et externe, et la possibilité de s authentifier grâce à des acteurs externes connus (adresse de messagerie orange, gmail, outlook ou un fournisseur d identité OpenID) sont en cours de standardisation. - Partager des identités entre application (oauth). OAuth est un standard qui a pour but de standardiser un mécanisme d authentification qui permet à une application de s authentifier auprès d une autre application, sans avoir à demander à l utilisateur de s authentifier à nouveau. 75 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

77 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 2 L outillage de l infrastructure Chapitre 2 L outillage de l infrastructure Nous avons vu dans les processus, que le cœur du cloud hybride est l automatisation, l orchestration. Pour la réaliser il faut que les composants soient conçus dans cette optique. Nous allons voir comment l outillage évolue pour permettre cette automatisation. Nous commencerons par l étude des composants physiques de base de l infrastructure que sont les réseaux, les serveurs et le stockage dans la section 1. Nous verrons comment il faut extraire des fonctionnalités de ces éléments pour pouvoir automatiser, comment l infrastructure devient «software defined», c est à dire contrôlée par du logiciel centralisé. Puis dans la section 2 nous verrons les éléments logiciels de l automatisation et de l orchestration, des plus basiques, qui vont parler avec les interfaces matérielles, aux plus complexes, qui vont orchestrer des comportements de multiples composants et applicatifs. Nous verrons comment l automatisation est «software defined», c est à dire contrôlée par du logiciel centralisé. Section 1 : L Infrastructure devient «Software Defined» Important Figure 30 : L'infrastructure Stockage, Traitement et Réseau L infrastructure de traitement, de réseau et de stockage est de plus en plus configurable, «virtualisable» par logiciel, ce qui apporte de la visibilité et permet un meilleur contrôle. De plus en plus de fonctions liées à l infrastructure, sont réalisées dans la partie logique et de moins en moins dans la partie physique. Cela participe grandement à augmenter les possibilités d élasticité, puisque plus personne ne doit intervenir pour reconfigurer. Il devient possible d automatiser et de mettre des règles et des outils de mesure qui reconfigurent «à la volée». Cela contribue également à faciliter le cloud hybride, pour les mêmes raisons. Dans le «Software Defined Environment» ou «Software Defined DataCenter» l élément clé est la séparation du plan de contrôle et du plan de données. 76 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

78 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 2 L outillage de l infrastructure Figure 31 : L'Objectif est de centraliser l'administration La gestion centralisée du contrôle communique avec les fonctions de gestion centralisées d automatisation et de configuration de la sécurité, la capacité, la performance afin d appliquer les Fonctions Virtuelles de : - Réseau : firewall, bascule de charge, sous-réseau, réseau privé virtuel, - Stockage : compression ou déduplication, isolation de sécurité, réplication pour reprise après désastre, - Traitement : déplacement de charge de travail (clone, image, blueprint). 1) La puissance de traitement (processeur et mémoire) L outil principal de la virtualisation de traitement est l hyperviseur, qui permet une première virtualisation du processeur et de la mémoire. L hyperviseur placé sur une ressource ou un cluster de ressources permet de mutualiser de la puissance processeur ou mémoire et d optimiser l affectation en fonction des besoins par des techniques comme celle du ballooning pour la mémoire. 2) La virtualisation du réseau Le premier outil de la virtualisation réseau est aussi l hyperviseur. Les cartes réseaux virtuelles appelées parfois VNICs (Virtual Network Interface Component), et les commutateurs virtuels VSwitchs (Virtual Switchs) sont émulés, gérés, configurés et contrôlés, par l hyperviseur et reliés aux interfaces réseaux physiques. Pour pouvoir déplacer des charges de travail dynamiquement et automatiquement, il faut pouvoir automatiser tout l approvisionnement de ressources. Hors si la partie puissance est largement automatisée par des couches d abstraction, de virtualisation, beaucoup de processus de configuration réseau et stockage restent propriétaires ou manuels. C est le cas des interfaces réseaux physiques des ressources matérielles et de beaucoup de routeurs d entrée et de sortie des Datacenters, mais c est en évolution. Chaque ressource physique nécessitait une programmation manuelle, personnalisée et propriétaire. Ceci se traduisait par des processus d approvisionnement très longs et des automatisations impossibles. 77 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

79 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 2 L outillage de l infrastructure Figure 32 : L'existant en réseau et l'objectif (Inspiré par source Cisco) Face à ce souci des groupes de travail se sont créés, pour définir des mécanismes plus souples en créant une couche d abstraction pour des processus gérés jusque-là physiquement dans le matériel. Afin de pouvoir programmer l approvisionnement et le décommissionnement, placer une charge de travail et pouvoir la déplacer en appliquant des règles, gagner en efficience, pouvoir mutualiser ces ressources. Les différents objectifs Afin de relier l émulation réseau de chaque VM à la sortie physique et entre elles, sont apparus les premiers switchs ou commutateurs virtuels. Le cloud étant multi-tenant, pour isoler les clients entre eux il faut créer des sous-réseaux. Pour cela le VLAN a permis de gérer jusqu à 4096 adresses IP, basé sur un identifiant de 12 bits, qui ne suffit plus toujours. De plus des besoins apparaissent pour : - pouvoir gérer plus facilement les modifications de réseau, par exemple pour le loadbalancing, - pouvoir isoler les utilisateurs d une même organisation, - assurer la continuité des IP avec celles du client, - faire de la qualité de service (QoS), gérer des priorités, - administrer de la sécurité, des listes de contrôle d accès (ACL), - suivre et améliorer à la volée les performances réseaux, - étendre la plupart de ces fonctionnalités en WAN, pour le cloud hybride par exemple, - pouvoir automatiser les fonctions réseaux et gagner en élasticité ou agilité. 78 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

80 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 2 L outillage de l infrastructure 2.1) Les différentes approches de virtualisation de réseau Plusieurs approches de «virtualisation», «softwarisation» du réseau sont actuellement en cours d évolution : Important - Le Software Defined Network (S.D.N.) type OpenFlow basé sur un protocole et un contrôleur. - La virtualisation du réseau centrée sur l application d OpenDayLight. - Le Network Virtual Overlay ou la superposition virtuelle réseau basée sur l encapsulation. - Le Virtual Network. - Le composant réseau traditionnel géré par API. Nous allons les voir plus en détails. a) Le S.D.N. L architecture du SDN est globalement composée : - d un switch compatible OpenFlow, c'est-à-dire permettant le contrôle externe, - des interfaces permettant l accès aux composants (API Nord) - des interfaces permettant l accès au contrôle (API Sud) - du protocole OpenFlow de l ONF, - du contrôleur centralisé. Figure 33 : Du routeur classique au S.D.N. «dans l architecture SDN les plans de contrôle et des données sont découplés, l intelligence et l état du réseau sont logiquement centralisés, Source: C est ce que nous montre la figure ci-dessus. La couche de contrôle (Control Plane) et la couche de traitement ou de donnée (Data Plane) sont à l origine toutes les deux dans l élément réseau. Il faut donc communiquer avec le composant pour le configurer. 79 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

81 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 2 L outillage de l infrastructure Figure 34 : OpenFlow "L'OpenFlow permet l'accès direct et la manipulation du plan d'acheminement des périphériques réseaux tels que les commutateurs et les routeurs, qu'ils soient physiques ou virtuels (basés sur un hyperviseur)." Source : Open Networking Foundation ONF Une nouvelle architecture avec des switchs programmables et un contrôleur centralisé qui maintient la topologie réseau comme OpenFlow. Cette technologie permet de gérer les chemins réseau, mais elle ne permet pas la configuration du réseau nécessaire pour l élasticité, comme nous en avons besoin. C est à dire pouvoir contrôler de l extérieur le composant réseau pour lui donner sa configuration IP par exemple, mais aussi le grouper avec d autres cartes pour de la résilience ou de l augmentation de bande passante, ou encore lui appliquer des règles de firewalling en acceptant tel ou tel protocole sur tel ou tel port. De plus chaque fournisseur arrivait avec son contrôleur central, les interfaces ou API n étaient pas standardisées. b) La virtualisation du réseau centrée sur le contrôleur défini par l OpendayLight. Figure 35 : OpendayLight d'opendaylight.org L Opendaylight sous l égide de Linux Foundation travaille actuellement sur le contrôleur commun à tous les acteurs et des APIs compatibles pour simplifier l intégration, tout en autorisant chaque fournisseur à intégrer des éléments additionnels sans enlever de compatibilité. Il vient de sortir la première version de se contrôleur centralisé, en novembre. Il reste centré sur la gestion du cheminement des flux. Remarque : Cisco, qui est acteur du projet OpenDaylight sort en parallèle du contrôleur et gestionnaire centralisé open d OpenDaylight, sa version à valeur ajouté l ACI (Application Centric Infrastructure) qui va gérer des SLA, de la sécurité, de la QoS et de l affectation de largeur de bande, de la montée en charge et le suivi et la réduction de la latence en s appuyant sur l overlay. 80 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

82 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 2 L outillage de l infrastructure c) La superposition ou encapsulation réseau Elle s appuie sur l encapsulation, la «tunnelisation», la superposition de réseau. Les réseaux superposés ou «Networks Overlays» sont des tunnels entre les switchs virtuels des hyperviseurs. Cette configuration doit permettre de minimiser les changements et les mises à jour des éléments physiques des réseaux. Cette technologie permet la configuration à la volée des éléments réseaux. L ajout d un identifiant en superposition à l adresse IP permet de créer des sous-réseaux, par exemple. Un sous-réseau peut-être dans le cloud interne et en continuité dans le cloud externe. Des contrôleurs gèrent le chemin, l encapsulation. Les protocoles s appellent entre autre VXLAN, GRE, NVGRE, DOVE,. VXLAN et NVGRE utilisent 24 bits dans le datagramme pour identifier le destinataire, ce qui permet 16 million de réseaux virtuels au lieu de 4096 en VLAN. d) Le Virtual Network du projet OpenContrail. Son objectif est de : Faire fonctionner du réseau bas-niveau sur des serveurs de commodité, Optimiser l usage des serveurs, Simplifier la gestion réseau. Le projet est basé sur des protocoles standards et doit apporter tous les éléments nécessaires à la virtualisation réseau : contrôleur, routeur virtuel, moteur analytique et APIs (northbound). Le contrôle d accès et la connectivité sont définis par des règles. Les chemins inter-réseaux sont définis au niveau de l hôte pour diminuer la latence du trafic traversant les réseaux virtuels. Il faut simplifier les passerelles pour améliorer la résilience. Il utilise un modèle de données clair et complet pour définir la configuration réseau ce qui facilite l automatisation et donc l élasticité. Le moteur analytique permet de gérer une grande quantité de données de format structuré ou non et un outil de requête permettant d accéder aux données temps réel et historique. Juniper contribue avec OpenContrail à OpenDaylight. D autre produits comme NSX de VMWare, Nuage d Alcatel, PLUMGrid ou Midokura sont basés sur du virtual Network. Le composant traditionnel géré par API : permet de gérer la transition, en intégrant les éléments de réseau existants non-sdn. Important La flexibilité du réseau est essentielle pour rendre élastique le cloud hybride. Différentes approches sont encore en cours : l OpenFlow qui permet de définir le chemin, l Overlay qui s attache à la configuration à la volée et le virtual network qui cherche à optimiser l usage des serveurs. Des 81 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

83 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 2 L outillage de l infrastructure solutions vont émerger rassemblant sans doute le meilleur de chaque proposition, pour permettre l automatisation globale transverse cloud. 2.2) L application en WAN du SDN Notre sujet d étude est le cloud hybride, et celui-ci ne s arrête pas au LAN. Afin de gérer l élasticité du cloud hybride il faut pouvoir optimiser et contrôler le réseau WAN, pour gérer de la qualité de service de bout en bout. Etant plus facile de modifier des commutateurs virtuels que physiques, des switchs internes que ceux de multiples opérateurs, la virtualisation réseau était d abord LAN. C est en cours d évolution pour pouvoir superviser le MAN, le WAN. BIG-IP F5 propose trois éléments pour connecter deux clouds : le pont, le courtier, la passerelle. - Le pont symétrique si même technologie aux points d accès, asymétrique sinon avec dans ce cas un manque de contrôle sur le point d accès du cloud accédé. Des possibilités de superposition réseaux (network overlay) permettent d encapsuler dans un tunnel les couches de niveau 2 et 3. L identifiant client étant intégré dans la trame Ethernet. Figure 36 : Connecter deux clouds par tunnel - le courtier d identité, va maintenir la synchronisation entre le cloud externe et interne. Le fournisseur de cloud externe maintenant souvent sa propre base non à jour au niveau des autorisations par manque d intégration. S il s agit d authentification par Token, ou s il s agit de mettre à jour les identités le broker est alors authentifié comme «de confiance». Dans le cas du cloud hybride le but est d être à terme le courtier d identité. Le courtier d accès gère plus les règles «corporate» d accès. Le fournisseur établi un tunnel de type VPN (full-proxy), ou autorise et établi une autre liaison direct cloud-consommateur (half-proxy). De même le cloud hybride doit établir le lien par le catalogue de service. Le cloud hybride doit également remplir les fonctions du courtier, en choisissant les clouds externes en fonction des exigences métier par rapport au service en performance, disponibilité, localisation, sécurité, coût. - la passerelle du cloud hybride doit permettre de connecter le cloud interne au cloud externe en réalisant l intégration des API au niveau exigé : stockage, traitement, IaaS, PaaS, SaaS ou BPaaS Elle 82 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

84 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 2 L outillage de l infrastructure doit comprendre ou être complétée par toutes les fonctionnalités actuellement couvertes par des courtiers, en fonction des besoins, et sans inclure des dysfonctionnements ou des adhérences supplémentaires. Comme vu dans le chapitre 2, management homogène, le cloud hybrid de VMware est composé de trois modules de gestion pour le WAN par Global Traffic Manager de BIG IP, le LAN par Local Traffic Manager de BIG IP et les règles par F5i software installé dans une machine virtuelle. Exemple d utilisation : le VXLAN permet une continuité de sous-réseau entre l interne et l externe, le virtual network permet de pouvoir installer des routeurs virtuels qui couplés à des outils de gestion installés dans une autre machine permettent de gérer la supervision, l opérationnel, l expérience client, et l OpenFlow aide pour la gestion du flux de cheminement. (Google a déjà réalisé un WAN entre ses clouds pour la gestion interne en développant ses propres interfaces SDN/MPLS, à priori). Important Une solution de plus en plus employée pour le WAN est gérée par les techniques de network overlay pour la gestion de la sécurité et de QoS, par des techniques de type OpenFlow pour la gestion du chemin, sur du SSL ou du VPN et par du virtual network pour la création en live de composants réseaux additionnels. 2.3) Virtualisation de fonctions Les fonctions deviennent virtualisables grâce à la possibilité de configuration des composants matériels : Voice, Vidéo, Wireless, LAN networking, IP Addressing, Public Key Infrastructure (PKI), Firewall, VLANs, Access Control Lists (ACLs) peuvent être automatisés. Important En plus du SDN (Software Defined Network), beaucoup d articles font référence au NFV (Network Function Virtualization), la virtualisation des fonctions réseaux dans lesquelles se trouvent par exemple le firewall, le NAT, le VLAN, les ACLs, le load-balancing, etc et qui sont possibles grâce à la virtualisation réseau. Il est peut-être plus simple de parler de virtualisation de fonction ou Function Virtualization, car si le Firewall est une fonction à l origine dans les équipements réseaux, le débordement, le déplacement de charge de travail ou la répartition de charge ne concernent pas que le réseau. Les besoins du cloud hybride élastique sont donc plus larges. Il s agit donc plutôt de xfv (Anything Function Virtualization) ou Fonction de Virtualisation qui vont intégrer le réseau, le stockage et le traitement, mais aussi des couches logicielles. 83 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

85 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 2 L outillage de l infrastructure 3) Le stockage virtualisé Figure 37 : Deux circuits dans la virtualisation du stockage Toujours le même objectif : rendre élastique et pour cela virtualiser, séparer la partie donnée de la partie contrôle. Dans les configurations «out-band», les chemins aussi sont séparés, pour optimiser les performances. Important Le but est de déplacer le contrôle, en dehors des baies, dans des contrôleurs externes. Pour cela les fournisseurs de stockage doivent standardiser le contrôleur et les APIs, pour sortir la couche de contrôle des baies, comme pour le réseau, afin qu elles puissent intégrer facilement des baies hétérogènes de multiples constructeurs. Les systèmes RAID, le stockage en mode objet sont déjà des éléments qui mettent une couche d abstraction entre les données et le support physique. Cependant pour pouvoir configurer à la volée, libérer des ressources de stockage, mesurer des performances, détecter des éléments de blocages dans une baie, isoler, répliquer après désastre, exige que toutes les formes de stockage soit contrôlées, supervisées. Le stockage doit être vu comme un service de stockage dynamique, mutualisé, ouvert pour pouvoir gérer de manière centralisée de l hétérogène. Il existe beaucoup de formes de stockage : en mémoire ou flash (SSD), en bloc dans un SAN (Storage Area Network), en NAS (Network Access Server). Il existe différents mode de gestion : objet ou blob (binary large object), en mode bloc, ou en mode fichier (cf. Annexe OpenStack). On peut gérer des bases de données structurées ou attaquer directement les données en clé-valeur. Le stockage est souvent valorisé au kilo Octet ou au giga Octet, mais il doit aussi être vu en termes de rapidité de lecture, ou d écriture qui constituent les principaux points de blocage des performances. En stockage la rapidité est classée par les Tiers ou niveaux. L arrivée de mémoire Flash (Tiers 0) permet d évacuer des goulets d étranglements au niveau des I/O. Le tiering permet de classer les éléments accédés moins souvent sur des stockages moins rapides, de Tiers supérieurs. La 84 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

86 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 2 L outillage de l infrastructure compression permet de libérer de l espace en collaboration avec des bases en mode colonne plus facilement compressées. Figure 38 : Les fonctions internes du stockage Tout ceci existe mais surtout au niveau de baies homogènes. Dynamique Les éléments de stockage et leurs connexions réseaux doivent être reconnus en plug & play par les systèmes de gestion pour pouvoir être affectés. Ils sont alors visibles comme des services avec leurs exigences, les règles : rapidité de lecture, d écriture, de bande passante, de coût, de surface. Mutualisé Ils peuvent être mutualisés sous forme de pool ou de cluster, sécurisés (réplication, sauvegarde, miroir). Pour cela il faut une couche d abstraction qui sépare la partie contrôle de la partie donnée. La partie contrôle est alors logicielle et fait la liaison avec le physique, permettant de créer des volumes virtuels dynamiques au-dessus de ressources physiques qui peuvent être mutualisées. Ouverte En interne, l architecture est hétérogène, mais surtout le cloud hybride élastique doit permettre d approvisionner du stockage en externe dans des clouds publics ou privés par les interfaces standardisées (API REST : AWS, OpenStack), reliées à une puissance de traitement interne, du cloud de l entreprise, ou externe. Des données hybrides Permettre de gérer des données de format multiples : vidéo, audio, et pouvoir laisser le traitement sur le système de stockage pour les gros volumes comme avec des systèmes de fichiers HDFS (Hadoop Distributed File System), adresser directement les données par un nom unique, ou les ranger en système clé-valeur sont des nouvelles possibilités. Pouvoir se connecter à des services spécialisés dans le traitement ou la sauvegarde des données, de basculer dynamiquement son niveau de données (ou Tier) dans un niveau moins rapide si peu d accès en appliquant une supervision centralisée qui s appuie sur des politiques pour répondre aux exigences du service, c est l évolution dont a besoin le cloud hybride élastique. Automatisé : par des règles, des mesures, des scénarios. 85 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

87 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 2 L outillage de l infrastructure Cet ensemble de caractéristiques permet d optimiser le placement des données à partir de mesures pour respecter les règles de performance, de capacité, de sécurité, au coût approprié aux exigences du service. Parenthèse Pouvoir changer dynamiquement les configurations et libérer des ressources sont des points essentiels pour une architecture agile et efficiente, et donc pour le cloud hybride élastique. Par contre ce sont des points qui ne sont pas encore techniquement complétement matures au niveau des composants : traitement, stockage, réseau, et donc sur lesquels les efforts sont en cours, comme nous le verrons dans l étude des composants de l agilité. 86 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

88 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 2 L outillage de l infrastructure Section 2 : L automatisation est «Software Defined» Figure 39 : Les niveaux applicatifs du "Software Defined" Important Le deuxième élément essentiel au cloud Hybride Elastique est le développement de briques d automatisation qui effectuent toutes les actions nécessaires au déploiement de l ensemble traitement/stockage/réseau, mais aussi des composants logiciels et applications. Cette automatisation est facilitée par le «Software Defined» de l infrastructure, vu précédemment. Ceci nécessite la maîtrise des ressources, des liaisons, de règles, de profil, de mesures, de planning, de structure, de comportement Il s agit à nouveau de «Software Defined» car tout est rendu modulaire et «paramétrable» afin de pouvoir être déployé et configuré à la volée. 1) L inventaire et les liaisons Les bases principales : - CMDB (Change Management DataBase) - CMS (Change Management System) - DCIM (Datacenter Infrastructure Management) Les bases de ressources (infrastructure, application et service opérationnels du cloud), leurs configurations, leurs relations, leurs changements et l interdépendance entre les éléments sont importants pour la rapidité de résolution d incident, l anticipation de changement, de maintenance, l optimisation des coûts. Les éléments sont de plus en plus souvent auto-découverts par les outils de management, grâce à des mécanismes et des informations au niveau des éléments au format standardisé. Ce qui évite les oublis de mise à jour. A terme cela pourrait rendre optionnel l utilisation de base. Les éléments et leurs dépendances seront détectables à la volée, logiciel et services compris. 87 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

89 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 2 L outillage de l infrastructure Dans du multi-clouds ses données peuvent être remontées par les outils de gestion aux outils de multi-orchestration, en fonction de la granularité nécessaire au bon fonctionnement. Dans le cloud hybride élastique, différentes bases : - Le cloud privé : inventaire complet. - Le cloud public : o interfaces possibles ou non des composants. o choix du niveau des composants à gérer, du niveau d interfaçage, pour pouvoir mener à bien les tâches de déploiement multi-cloud et le support,. Tout scénario de déploiement à besoin de connaître les ressources disponibles et d avoir des scénarios capables de faire des choix pour optimiser et rationaliser l affectation de ressources. Dans le cloud hybride cette connaissance doit être transverse. Il est important de connaître la localisation d un service ou d une charge de travail et son historique de fonctionnement, pour des raisons de conformité, traçabilité mais surtout de support, de maintenance et d optimisation du fonctionnement. Entre le cloud public et le cloud privé le niveau de gestion n est pas le même. Une partie de la gestion est confiée au fournisseur de l infrastructure, de la plateforme, de l application. Le support et l optimisation s arrête-t-il alors au niveau de responsabilité? Le cloud hybride doit chasser toutes les zones grises dans lesquelles la responsabilité n est pas limpide et des cas d orchestration peuvent nécessiter une connaissance complémentaire des ressources sous la responsabilité du fournisseur. Si un besoin existe, le fournisseur peut être amené à fournir une interface avec sa base de ressources, afin que le cloud hybride puisse fonctionner correctement, en fonction du cas d usage. Un blueprint est un template qui décrit les composants logiciels de l application et l environnement cible, pour pouvoir aller sur tout type d infrastructure. 2) L automatisation de l infrastructure basique 2.1) Provisionner et configurer Ces briques d automatisation sont gérées par des moteurs, qui sont alimentés par des règles, des informations et des retours de mesures. Lors d une demande «self-service», le service est déployé automatiquement, pour cela il faut : - des topologies décrivant les besoins des applications en ressources, - des scénarios de déploiement et de configuration des ressources, - les paramètres, - les composants applicatifs. Déclenchés par des seuils de mesure et des règles, les runbooks de workflows orchestrent les patterns pour déployer de bas en haut, l architecture nécessaire. Des outils permettent ainsi de déployer des architectures multi-niveaux (n-tiers) ou de modifier le nombre des ressources utilisées par un des tiers comme la base de données, le service application, ou les frontaux web tout en orientant les utilisateurs vers chacun des frontaux. 88 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

90 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 2 L outillage de l infrastructure C est la même démarche qui sert à déployer de l élasticité dans le cloud hybride, avec un choix de fournisseur de cloud externe à faire en plus et la configuration du lien à établir. 2.2) Exemple d outil : OpenStack OpenStack est à l origine un outil d approvisionnement de ressources d infrastructure de base, initié par Rackspace et la NASA en Avec les nouvelles versions ses fonctionnalités s élargissent vers l orchestration. (Cf. Annexe OpenStack) L approvisionnement de base des composants d infrastructure dont la configuration peut-être maintenant contrôlée par logiciel, va ouvrir des possibilités supérieures, indispensables pour les montées en charge et pour le cloud hybride élastique. Afin de pouvoir être plus concret prenons en exemple OpenStack version Havana : Figure 40 : Les projets OpenStack Un ensemble de modules logiciels viennent s appuyer sur les couches d abstraction pour gérer les composants d infrastructure afin de faciliter l approvisionnement et la libération de ressources à la volée. Le module Nova gère la partie approvisionnement de puissance de traitement, il va aider à choisir l hyperviseur suivant des règles préétablies (nova-scheduler) : le moins chargé, au hasard ou dans une zone donnée, mais aussi lui affecter une adresse réseau (nova-network), et le lier à du stockage (nova-volume) qui peut être interne ou externe sur AWS S3 par exemple. Notons que la passerelle ou l intégration ce fait dans ce cas, à ce niveau entre des APIs OpenStack Nova et des APIs AWS S3, mais elle doit être complétée par d autres APIs pour gérer la mesure, la facturation, La figure suivante nous montre que les composants logiciels de gestion de l approvisionnement de ressource de traitement, Nova, vont se situer différemment dans la pile logicielle en fonction de l hyperviseur, soit comme un agent au-dessus de l OS, soit comme agent dans une VM, soit comme un agent s adressant à l outil de gestion centralisé dans le cas d un cluster. 89 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

91 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 2 L outillage de l infrastructure Figure 41 : Place d'un agent OpenStack en fonction de l'hyperviseur key/communityserver-blogs-componentsweblogfiles/ /2744.openstack1.png Parenthèse EGO d IBM est un outil de gestion centralisé de cloud hybride qui envoie des règles, politiques, contraintes à l outil OpenStack Nova Control, pour provisionner les VM. On peut imaginer que s il existait un hyperviseur pour cluster de cloud on pourrait faire dialoguer l agent Nova avec l outil d administration centralisé du cluster de cloud. Figure 42 : Outil de management de politique d'approvisionnement Multi-cloud La figure suivante explicite le fonctionnement : les modules discutent entre eux par des ensembles logiciels, des ensembles d API en s appuyant sur des files d attente ou AMQ (Queue) et des bases. 90 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

92 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 2 L outillage de l infrastructure C est cette modularité qui permet de s adapter à moindre coût à des infrastructures hétérogènes ou nouvelles. Figure 43 : Extrait d'architecture OpenStack Les modules Swift et Cinder permettent spécifiquement d approvisionner le stockage, en mode objet ou block respectivement. Il est plus complet que nova-volume. Le module Neutron va permettre de configurer, d approvisionner du réseau, les dernières versions sont adaptées pour gérer du Software Defined Network. Il est plus complet que nova-network. Le module Glance va permettre de gérer une base de données d image. Le module Keystone permet de gérer l identité sur plusieurs niveaux : user, projet,. avec un système de gestion de Token. Horizon sert d interface homme-machine, de tableau de bord. Avec la version Havana d OpenStack sont arrivés des outils Heat et Ceilometer, qui sont respectivement des outils d orchestration et de mesure. OpenStack passe de l automatisation des composants basiques de l approvisionnement d infrastructure pour apporter de la supervision et de l automatisation plus complète mais aussi plus complexe. L outil d orchestration s appuie sur des Services Template compatibles CloudFormation d Amazon Web Services (AWS). L outil de mesure est la base de la supervision mais aussi de la facturation. Ce fonctionnement est similaire globalement au fonctionnement d autres outils comme CloudStack ou ceux utilisés par AWS ou d autres acteurs du marché. L avantage avec l OpenSource est la transparence de l information, le nombre de documentations partagées, plus techniques et moins marketing, qui permettent de mieux comprendre le fonctionnement. Cette base d outillage permet de créer au-dessus des outils supplémentaires gérant les processus basés sur ITIL, le cycle de vie des processus. De nouveaux projets pour l automatisation et la gestion de la base de données sont en cours pour la prochaine version IceHouse, dans six mois. L intégration de modules OpenStack est complexe. Les versions changent tous les six mois, et seuls des outils de 91 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

93 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 2 L outillage de l infrastructure montée d une version sont fournis. Pour éviter différentes intégrations d OpenStack entraînant des modifications sur la compatibilité, les responsables d OpenStack réfléchissent à la mise en place de certification. 3) L automatisation des systèmes, des services, des applications 3.1) L automatisation de systèmes complexes d infrastructure Les systèmes complexes sont mis en place pour répondre à la mise en place d un service complexe. Figure 44 : Scénario de déploiement n-niveaux Les applications n-niveaux doivent pouvoir se déplacer d un cloud à l autre. Plusieurs scénarios de migration Par exemple pour une application 3 niveaux classique : Web, Appli, Base qui a besoin de conserver ses liens, mais peut être déployée différemment suivant s il s agit d un environnement de développement, de test ou de production, il existe plusieurs scénarios de migration, comme par exemple : - la migration complète, - la migration d un niveau ou tiers : c'est-à-dire la copie d une instance ou la mise en service du template du tiers, le déploiement, le paramétrage. L établissement des liaisons clients par le DNS, et la continuité des liaisons entre tiers sont pris en compte. - la multiplication d un niveau -> base de données On peut ne vouloir migrer qu une partie de la base multi-tenant en la séparant par tenant, par exemple, ou la cloner plus simplement. Il faut adresser des opérations de gestion de la base de données, s occuper de la mise à jour par des mécanismes de standby pour la mise à jour de la base supplémentaire. -> web Si on fait le choix d une redirection d une partie des clients vers un deuxième cloud, comme avec un CDN (Content Data Network) vers une autre adresse de serveur frontal, pour certaine adresses web. 92 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

94 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 2 L outillage de l infrastructure Le gestionnaire système affecte des nouvelles ressources et les configure, ces actions sont automatisées. Il ne s agit jamais de créer de la complexité sans raison, ce type de fonctionnement doit trouver sa source dans les exigences et être itératif pour justifier son design et son intégration. 3.2) L automatisation de systèmes complexes de services Figure 45 : Les drivers de l'élasticité La mise en place de cette plateforme technique et de sa configuration stockage et réseau compris, ne serai pas complète sans la partie applicative. Les scénarios de déploiement d infrastructure ou système, s accompagnent du déploiement des logiciels associés et de leurs configurations. Une fois que la plateforme serveur web, serveur d application et base de données est installée et configurée, le service doit être déployé et configuré également. La mise en place d une automatisation nécessite la création d'un «blueprint», ou «service template». Le service template est idéal car il permet d être indépendant de l écosystème cloud sur lequel est déployée l application. Le scénario étant modulaire son paramétrage, son intégration, ses modifications sont facilités. Des outils de déploiement comme Puppet, Chef permettent de déployer les scénarios avec leur paramétrage. Important Nous sommes toujours dans la démarche de «Software Defined Anything» ou SDx, la couche de données est séparée de la couche de contrôle. En l occurrence les composants qui font fonctionner l application sont séparés des composants servant au déploiement et à la montée en charge de l application. Les scénarios d automatisation des fonctions virtualisées : load-balancing, configuration de sousréseau, de firewall, de sauvegarde, de réplication peuvent répondre au même schéma. 93 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

95 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 2 L outillage de l infrastructure 3,3) Les standards de «Services Templates» et les outils de déploiement Le standard OVF de DMTF permet une standardisation des images et leur déplacement pour de l embarquement, mais reste compliqué pour la mise à jour des patchs. L orientation technique semble aller vers des outils permettant de capturer les opérations de déploiement, l environnement d exécution, et le comportement ce qui permet l autonomie et la portabilité. Les modélisations de service template les plus connus sont entre autres : CloudFormation (AWS), TOSCA (OASIS), IMOD (Kaavo). Figure 46 : Service Template Tosca TOSCA Topology and Orchestration Specification for Cloud Applications basé sur du XML, capture le déploiement et les infos de gestion. TOSCA utilise le Business Process Execution Langage pour définir le comportement. Avec Tosca un service est décrit par un «service template» qui correspond à : - une topologie (structure) - une orchestration (comportement de gestion et invocation). Ceci aide à la création et la gestion automatique de service, indépendamment du fournisseur de cloud et des technologies sous-jacentes. Le service est créé une fois et sert à de multiples utilisations, pour de multiples environnements. Les services sont provisionnés dans une infrastructure IT et leur comportement de gestion est orchestré en accord avec les contraintes et règles qui pèsent dessus, pour respecter les niveaux de services, par exemple 94 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

96 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 2 L outillage de l infrastructure L automatisation devient complexe. Pour la simplifier il faut la gérer par plan. Chaque niveau fournit des «blocs élémentaires» (building bloc), enchaînés dans le plan supérieur. C est dans cet esprit que se situe Tosca, standard d OASIS. Avec Tosca un service est décrit par un «service template» qui correspond à une topologie (structure) et une orchestration (comportement de gestion et invocation). Ceci aide à la création et la gestion automatique de service, indépendamment du fournisseur de cloud et des technologies sous-jacentes. Le service est créé une fois et sert à de multiples utilisations, pour de multiples environnements. Les services sont provisionnés dans une infrastructure IT et leur comportement de gestion est orchestré en accord avec les contraintes et règles qui pèsent dessus, pour respecter les niveaux de services, par exemple. Figure 47 : Service Template= Structure, propriété et comportement La description de services afin de s'assurer de leur échange. Les aspects «runtime» sont pris en considération en fournissant un conteneur pour des modèles de plans à l'appui de la gestion des instances de services. La bibliothèque fournit des mécanismes d'extension qui peuvent être utilisés pour étendre les définitions : à des ajouts supplémentaires spécifiques au fournisseur ou à un domaine d informations spécifiques. Les services sont des entités modélisables (TOSCA) Standardiser les modèles de service permet de créer un marché de services IT hébergés. Un standard qui spécifie la modélisation des typologies (ensemble des composants et dépendances mutuelles) et permet la définition de l interopérabilité de la structure des services. Le modèle de service ou Service Template peut-être publié dans les catalogues de fournisseurs de service qui fera le lien avec son infrastructure pour supporter des instances réelles de service et les adapter à ses plans de gestion. Plan de gestion de l instanciation (build plan) Faire une instance concrète d un «modèle de topologie» peut se faire en lançant le «Build Plan» correspondant. Le Build Plan peut-être adapté à un environnement réel d un service de fournisseur. 95 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

97 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 2 L outillage de l infrastructure D autres «Plans» utiles pour des actions de tout le cycle de vie du service peuvent être spécifiés comme élément du «Modèle de Service». Similaires aux «Plans de gestion» ces «Plans» peuvent être adaptés à l environnement réel du fournisseur de service. Ces Plans décrivent comment les instances d un service sont créées et gérées. Définir un set de «Plan de gestion» pour un service réduit significativement le coût d hébergement d un service en produisant une connaissance réutilisable de bonnes pratiques pour gérer chaque service. Le constructeur des «modèles de service ou de plan» cache la complexité du comportement à l utilisateur qui doit simplement l invoquer. Parenthèse Un artefact représente le contenu nécessaire pour réaliser un déploiement : - exécutable (script, image) - fichier de données pour configuration (paramètre) - bibliothèque (d autres exécutables) Il est fourni avec des métadonnées descriptives de l environnement et est généralement en Python ou EJB. Exemple pour une opération REST de stockage d image : le WAR est l artefact d implémentation et l image est l artefact de déploiement. Le WAR est un fichier archive servant au déploiement par un serveur d application et contenant des JavaServer Pages, des servlets, des classes Java, des fichiers XML, des pages web statiques (HTML, JavaScript ), le tout constituant une application web. Kavoo utilise des Workflows d actions séquencés en réponse à un événement ce qui facilite les intégrations d actions en ligne de commande. Des outils de déploiement comme Puppet, Chef, Crowbar(Dell), RightScript (RightScale) permettent de déployer les scénarios avec leur paramétrage. Ils peuvent déployer les «Services Templates», les scripts. 3.4) L intégration de l écosystème du cloud d accueil La dernière étape du déploiement avant test est l intégration des outils du cloud d accueil : outils de facturation, de mesures, de librairies qui doivent s installer dans les virtuelles machines qui composent le service pour permettre de mesurer les performances, de lancer des runtime, de mesurer les consommations pour facturation. 3.5) Exemple d outil d orchestration Les éditeurs de logiciel d Orchestration proposent soit des outils basés sur tout ou partie des modules OpenStack, soit développés entièrement en interne ou par intégration de rachat. Système Center Orchestrator de Microsoft et VCloud Suite, sont des outils développés par respectivement Microsoft et VMWare. SmartCloud Orchestrator et HP Operation Orchestration sont des outils basés sur des modules OpenStack d IBM et de HP. Les outils d orchestration d HP et d IBM sont basés sur la modélisation de Services Templates TOSCA. 96 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

98 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 2 L outillage de l infrastructure SmartCloud Orchestrator prend en charge l'importation, le déploiement et l'exportation des modèles de service conformément à la spécification OASIS TOSCA. Cela permet de consommer un contenu tiers fourni dans un format normalisé. L outil d automatisation de Microsoft se base sur le déploiement de script PowerShell. Heat, l outil d orchestration d OpenStack utilise les «Services Templates», CloudFormation dans la version Havana. Les outils de gestion de cloud sont vus chapitre 3. 4) Superviser ses ressources, mesurer Le cycle de vie d une ressource consiste notamment à abstraire, modéliser, intégrer, authentifier, donner les autorisations, provisionner, déployer, lancer, configurer, mesurer, superviser, historiser, supprimer. Pour superviser les ressources il faut : - mesurer - définir des seuils de déclenchement d alerte, ou de bascule automatique 5) DevOps La démarche de DevOps au-delà de rapprocher les équipes de développement, des équipes de mise en production et d exploitation, a pour objectif également une intégration des processus de déploiement dès le développement. Les processus de déploiement d infrastructure sont modélisés (typologie, configuration) et scriptés pour pouvoir être lancés par les applications. La résolution des incidents est anticipée dans cette démarche. Cela implique un dialogue important entre les développeurs et les responsables des opérations. Le but est d éviter les tâches répétitives, les erreurs humaines, de pouvoir accélérer les mises en production et ainsi de pouvoir améliorer la disponibilité. Section 3 : Les applications et les Business Process 1) SaaS et les liens entre application par API ou connecteurs La synergie multi-cloud consiste globalement à fournir un portail qui va fédérer la gestion des identités et rassembler l accès aux applications, simplifier la facturation pour chacune des applications accédées. Une application SaaS ne va pas nécessiter de passage d un cloud à l autre puisque la problématique de montée en charge est généralement gérée par le fournisseur de l application. Sauf si notre client est fournisseur d application SaaS pour les métiers de son entreprise, nous ne verrons pas ce cas dans cette étude. Nous ne traiterons pas non plus le cas du référentiel et du Master Data Management, qui pourtant sont des questions qu il faudra étudier. 97 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

99 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 2 L outillage de l infrastructure 2) BPaaS : La Conception de Workflow Figure 48 : Exemple de Workflow d'automatisation La virtualisation des flux d action et d approbation : un défi pour la migration des applications de développement et de tests entre autre, mais surtout pour l élasticité du cloud hybride. Les librairies d outils pour la virtualisation fournissent la couche d abstraction pour se relier à l hyperviseur. Important La gestion d un cloud hybride élastique nécessite des actions multiples, interdépendantes, ordonnées : provisionner des serveurs en multi-niveaux, lancer des instances, connecter des bascules de charge, attacher du stockage, installer des applications, configurer des services, mettre en place la supervision, maintenir, contrôler la conformité. La conception et la gestion de Workflows complexes et automatisés font partie du cloud hybride élastique. 98 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

100 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 2 L outillage de l infrastructure Section 4 : Les passerelles API Figure 49 : Les Passerelles ou librairies d APIs Les principales API du marché sont OpenStack, CloudStack, Eucalyptus, AWS, La bourse d échange de cloud allemande : Deutsche Börse Cloud Exchange devrait s appuyer sur des APIs ouvertes de Zimory. Des fournisseurs de librairies d API Cloud existent : DeltaCloud, Apache LibCloud. Les fonctionnalités de ce service sont fonction des actions et paramètres mis à disposition par le fournisseur de cloud. Similaire à la démarche d API Cross-Platform, comme SimpleCloud pour les programmes PHP, ils intègrent les API de multiples Cloud avec des fonctionnalités identiques pour fournir une même interface au cloud interne. C est un produit sur étagère qui peut simplifier des démarches d intégration classiques du marché, simplifiant l intégration et les mises à jour éventuelles. Cette partie intégration s appuie sur des API, des SDK. Les APIs peuvent se standardiser sur des fonctions basiques comme l approvisionnement d une VM, mais elles continueront d évoluer de proposer des fonctions additionnelles. C est pourquoi il faut rester sur des démarches centrées sur le déploiement applicatif modulaire, qui permet de gérer les évolutions. 99 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

101 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 3 L outillage spécifique Chapitre 3 L outillage spécifique Section 1 : Les outils basiques de gestion du cloud hybride 1) Les différents outils de gestion de cloud hybride En plus des outils de gestion de cloud d HP, IBM, Microsoft, Oracle, VMWare, Citrix, BMC, CA, émergent des nouveaux éditeurs d outils de gestion de cloud. En général développés à la base pour un usage interne tel que Scalr, RightScale, ScaleXtreme, Enstratus, Kaavo, Abiquo, ServiceMesh, Hotlink, EcManaged sont des outils de gestion de cloud permettant de faire du multi-cloud et de déployer leur outil sur site. Gestion de cloud Hybride Automatisation VMWare Hybrid Cloud vcloud Director vcloud Suite vcac & vcops IBM SmartCloud Orchestrator & Cast Iron Cloud Automation Microsoft System Center Orchestrator SCCM & DataCenter Automation HP Operation Orchestrator & Converged Cloud CSA Cisco Cisco Intelligent Automation for Cloud CA Automation Suite & CloudMinder BMC Atrium Orchestrator Blade Logic Citrix Cloud Portal Business Manager Cloud Service Automation Oracle Entreprise Manager Cloud Control Entreprise Manager Ops Center Entreprise Deployement Blueprint DELL Enstratus Crowbar SCS ServiceMesh RighScale RightScale ScaleXtreme ScaleXtreme Kaavo Kaavo IMOD OpenStack Heat, Horizon, Nova TripleO Capgemini SkySight Figure 50 : Outils de gestion de cloud hybride Les principales caractéristiques des outils de déploiement de cloud sont ceux vus dans le catalogue de service (cf. figure 22, page 52) : - une console d administration centralisée pour l approvisionnement de ressources et leurs configurations, dans de multiple clouds, mais aussi pour la gestion de la capacité, de la facturation, 100 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

102 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 3 L outillage spécifique de la sécurité et des accès, du catalogue de service, des fonctions multi-clouds(embarquement, débordement, ) - une passerelle qui intègre les APIs de fournisseurs de clouds majeurs du marché (parmi Amazon Web Service, Google Compute Engine, Windows Azure, Rackspace, TerreMark, ) et des standards (OpenStack, CloudStack, ). - des outils facilitant l intégration d autres clouds, d autres fonctions, par APIs et scripting, avec un catalogue d APIs, de package, de librairies. - des outils de conception de l automatisation et des catalogues de Service Template. - de la supervision centralisée : des performances et des engagements de niveaux de service, des budgets et de la facturation, de l usage des services, de la sécurité et des accès, des fonctions multicloud (embarquement, débordement, mesure de l expérience utilisateur...). - des outils de gestion des règles, politiques. - des outils pour le support et la gestion du cycle de vie des services. 2) Les qualités d un gestionnaire de cloud hybride L outil de gestion de cloud hybride est le chef d orchestre. - Il possède une interface unifiée pour l approvisionnement, la configuration, la supervision des ressources de l infrastructure aux business process. - Il permet de suivre la conformité, les engagements contractuels, la sécurité, les budgets, les performances. - Il dispose d atelier de conception de l automatisation visuels et clairs, permettant la collaboration, disposants de bibliothèques de composants, facilitant les tests par du pas à pas et les retours arrière et d un magasin de packages d automatisation modifiables. - Il permet d intégrer facilement de nouvelles API et propose un magasin fourni de packages d intégration déjà testées. - Il a des outils de gestion de politiques, de règles, de circuit d approbation ou d action, d alerte et de notifications. - Il peut s intégrer facilement avec des outils externes de supervision, de sécurité, de support. Section 2 : Les outils de facturation Comme nous l avons vu précédemment pour facturer à l utilisation il faut d abord mesurer. L administrateur des budgets dans l application Enstratus est différent de l administrateur de ressources. Il va pouvoir déléguer des budgets, ce qui donne de l agilité dans le processus d approvisionnement. RightScale quand à lui intègre un nouvel outil analytique pour gérer le suivi financier et de l usage. 101 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

103 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 3 L outillage spécifique Section 3 : L adhérence des outils Afin de pouvoir gérer certains outils, des agents ou moteurs sont parfois installés dans les VMs. Ces agents sont importants à prendre en compte si les VM se déplacent d environnement (élasticité, réversibilité). Il faut pouvoir les installer, il faut pouvoir les intégrer pour agréger des informations de facturation, de performance, Si on veut déplacer l image ou le clone d une instance il faut pouvoir les désinstaller proprement afin d éviter les erreurs, les lourdeurs, les conflits. Le redéploiement à partir de template ou blueprint, et des modèles de déploiement permet une indépendance plus grande, mais demande un temps plus long, en général. Section 4 : La standardisation des outils Nous nous intéressons essentiellement aux outils et nous retrouvons souvent des standards pour développer ses outils issus de différentes communautés. Pour la définition du cloud il y a le NIST, pour la sécurité le Cloud Security Alliance et l ENISA, l Object Management Group(OMG), l Internet Engineering Task Force (IETF), 1) Distributed Management Task Force (DMTF) Un groupe du DMTF sur l Open Software Defined Data Center (OSDDC) travaille pour développer une architecture et des définitions standardisées pour décrire les technologies émergentes de l infrastructure IT. DMTF CIMI : Cloud Infrastructure Management Interface définit un standard qui permet par exemple de passer des instances au format standard OVF d un cloud à un autre. DMTF CIM : Common Information Model DMTF OVF : Format de package d image virtuelle pour les déployer sur des hyperviseurs. 2) Open Grid Forum (OGF) L Open Cloud Computing Interface (OCCI) développe des spécifications et des API open pour les offres cloud pour le IaaS extensible au PaaS. 3) Storage Networking Industry Association (SNIA) Le Cloud Data Management Interface (CDMI) est un standard SNIA qui spécifie un protocole de selfprovisioning, d administration et d accès au stockage cloud. CDMI définit des opérations HTTP RESTful pour permettre au stockage cloud d allouer et d accéder à des conteneurs et des objets, gérer des utilisateurs et des groupes, implémenter des contrôles d accès, attacher des métadonnées, faire des arbitrages, utiliser des files d action, spécifier des 102 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

104 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 3 L outillage spécifique intervalles de rétention en accord avec les règles de conformité, en utilisant des fonctionnalités de connexion, facturation, déplacement de données entre cloud, et de l exportation de données via d autres protocoles tel que l iscsi et NFS. La sécurité du transport est obtenue par TLS. 4) Advancing Open Standard for the Information Society OASIS OASIS TOSCA permet l assemblage et l orchestration d images virtuelles et d entités physiques dans des structures plus larges : service ou application. Tosca supporte les opérations du cycle de vie mais aussi de montée en charge, de patch. TOSCA a un haut niveau d abstraction pour décrire les composants applicatifs et d infrastructure, pour l orchestration. TOSCA supporte un haut niveau de relation pour décrire les topologies des applications cloud, comme "deployed on", "licensed by" et «data locality constraint". TOSCA orchestre le comportement des opérations de cycle de vie qui peuvent intelligemment conduire et aligner la gestion premier-niveau de l infrastructure de service cloud par des interfaces telles que celles définies par CIMI (DMTF) et OCCI(OGF). OASIS SCA : Service Component Architecte est un ensemble de spécifications qui décrivent un modèle pour construire des applications et service SOA (Service-Oriented Architecture). SCA complète les approches précédentes d implémentation de services. TOSCA étends les capacités de SCA en fournissant topologies et services d orchestration qui lie les applications SCA et l infrastructure cloud. REST : Représentation State Transfert, ensemble de principes alternative au protocole de service web basé SOAP. SOAP : protocole d accès basé sur le protocole RPC et XML. RESTful : respectant les principes REST. 5) Format d échange Les bus de traitement facilitent les échanges asynchrones et «sans état» diminuant l adhérence et créant des zones d échange. Exemple : AMQ (Rabbit MQ). 103 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

105 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 4 La sécurité Chapitre 4 La sécurité Figure 51 : Architecture Sécurité Cloud Security Alliance Section 1 : La gestion de la sécurité évolue 1) La sécurité ciblée Les efforts de sécurité dépassent les frontières du data center, car élastique et transitoire, la sécurité doit être repensée. La sécurité en lisière ne suffit plus, elle doit être à chaque point d accès et doit être prise en compte dès l amorce du projet. La sécurité péri métrique, n est plus le modèle d actualité. L accès devant être mobile, les points d accès de plus en plus divers, et l entreprise de plus en plus ouverte vers les clients, les partenaires, cette sécurité répond de moins en moins aux exigences. Pour répondre à ces challenges la gestion de la sécurité change. Elle s appuie aussi sur de la confiance et de l analyse comportementale, facilitée par l analyse de données non-structurées. Elle exige des sécurités ciblées et adaptées et donc des classifications, des services internes, des données, des services externes. La sécurité est souvent liée aux comportements et les utilisateurs doivent être formés, l outil principal est donc la formation. Des analyses comportementales en ligne, viennent de plus en plus renforcer la sécurité, les outils sont alors des bases et des algorithmes d analyse. 2) La sécurité par la conformité, la classification, l audit Sécurité des données, sécurité des services, sécurité des accès physiques, sécurité des accès numériques, la sécurité doit garantir la confidentialité, l intégrité, la disponibilité et la traçabilité en fonction des besoins et comme la sécurité a un coût non-négligeable, elle doit être ciblée. Elle passe dans le cloud hybride par les garanties fournies par les fournisseurs de cloud dans les engagements contractuels. Un des outils de la sécurité est lié au contrat, à la conformité de l entreprise aux standards de sécurité.et à la validité des audits effectués par des tiers habilités. Chaque service peut aller dans un cloud qui respecte le niveau d exigence du service et le transfert entre les clouds doit respecter ce niveau d exigence. 104 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

106 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 4 La sécurité Section 2 : La sécurité par la gestion des accès et de l identité 1) La gestion des accès et des identités (IAM : Identity Access Management) Accès de l intérieur, de l extérieur de l entreprise, accès par un employé, par un fournisseur, accès sur site, accès au cloud public de multiples types d accès existent. "Qui accède?", "qui a le droit d accéder à», «qui peut gérer quoi?", "qui a donné le droit à qui?". Le suivi d'une identité, de son authentification, de ses habilitations, de sa révocation est un élément essentiel de la sécurité. En environnement de cloud hybride élastique se posent plusieurs défis : - La protection des identités et de leur authentification : Quelle serait la protection et la fraîcheur d information de multiples copies d un annuaire dans des clouds divers? - Quelle est la protection du login lors du passage sur internet? - La protection des accès en multi-cloud : Comment contrôler les habilitations et l authentification dans chaque cloud? - La simplification des accès : Peut-on s authentifier une seule fois pour toutes les applications (Single Sign On)? - La fourniture de rapports d'audit de traçabilité pour la conformité légale et réglementaire : Sarbanes-Oxley, Bâle III, Solvency II, LSF... - L hétérogénéité des technologies d authentification acceptées par chaque fournisseur de cloud. Plusieurs standards se développent pour répondre aux nouveaux défis comme : - OpenID : single sign-on des consommateurs. - SAML : single sign-on des utilisateurs des entreprises. - OAuth : API autorisation entre applications. Typiquement dans la gestion de l identité nous allons considérer qu il faut pouvoir répondre aux AAA : Authentification, Autorisation, Accountable (traçabilité). Les mots de passe et certains cryptages sont de moins en moins sécurisés en raison notamment des puissances de calcul actuellement disponibles. Il faut donc pouvoir gérer des authentifications fortes à plusieurs niveaux, pour l interne (exemple : identifiant, mot de passe et badge) comme pour l externe (identifiant de type adresse de messagerie, mot de passe et SMS). Ces niveaux doivent être adaptés aux exigences. Pour l authentification : Nous partons du principe que l utilisateur : consommateur ou administrateur s authentifie au niveau du portail d accès du cloud hybride. C est le cloud hybride qui gère l authentification aux clouds externes. Pour des raisons de sécurité la duplication de l annuaire d authentification au niveau de tous les fournisseurs de service, n est pas envisagée dans cette étude, la synchronisation et la dispersion des bases d authentification ne sont pas souhaitables. 105 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

107 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 4 La sécurité Pour des raisons de traçabilité, parfois pour la gestion de rôles dans l application, il est important de pouvoir disposer de l identité dans un cloud hybride. Pour des raisons de simplicité et de sécurité, il est intéressant que l utilisateur ne s authentifie qu une seule fois, le Single Sign On, au niveau du premier portail d accès, celui fournit par le cloud hybride. Important Le cloud interne est authentifié par le cloud externe par des mécanismes de certificat, de clé public (Public Key Infrastructure). Un processus automatisé transfert des Token par les API pour prouver son identité, pour sécuriser les API, des standards sont développés. Basée sur l annuaire, LDAP ou l Active Directory, qui envoie des demandes sous forme de Token ou de Cookies. L autorisation : Le contrôle d accès basé sur les rôles (Role Base Access Control) L administrateur et ses droits d approvisionnement ou de décommissionnement de ressource, de déploiement, de paramétrage, d interconnexion, de gestion de flux sont gérés par le cloud hybride qui transmet au cloud accédé par les API mises à disposition pour la gestion de l identité par le fournisseur de cloud externe. La gestion du cycle de vie des rôles étant plus facile à gérer si elle n est pas dispatchée dans les applications, beaucoup d applications s appuient sur des autorisations données par des bases. Des bases d autorisation peuvent devenir nécessaires, en fonction de la complexité des autorisations. Il faut donc pouvoir associer à une identité un ou plusieurs rôles, ses rôles étant associés à des droits dans les applications. Il faut donc pouvoir authentifier un utilisateur mais aussi transmettre ses autorisations pour l application concernées. XACML: extensible Access Control Markup Language is a declarative access control policy language implemented in XML. 2) La gestion des processus L authentification Token de l API Qu il s agisse d un utilisateur ou d un processus le mécanisme d authentification est similaire, le cloud interne peut échanger des clés publiques avec le cloud externe. Des identités sont associées aux systèmes, aux processus automatisés qui peuvent être identifiés, tracés et historisés. Cette authentification passe par les API. Ils s appuient sur des standards et travaux existants sur internet comme : REST, WAM (Web Authentication Management). Autorisation de runtime Le lancement de processus doit être autorisé sur le cloud externe. 106 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

108 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 4 La sécurité Les processus automatisés vont aussi devoir bénéficier de droits pour automatiser un approvisionnement ou un décommissionnement de ressource, un déploiement, une interconnexion, Ce processus doit d abord transmettre par l interface ses accréditations. Exemple 1 : Processus d accès de Keystone Exemple 2 : La signature d API d AWS Figure 52 : Processus de gestion d'identité Keystone La requête de signature AWS niveau 4 est composée des éléments suivants : - Le point d entrée du service : une adresse URL, le nom DNS. - Le nom de l API qui correspond à l action - Les paramètres de l action. - La date et l heure de requête : pour protéger l API. - Les paramètres d autorisation : - l algorithme de hachage. (Exemple SHA-256) - le «credential» c'est-à-dire l identifiant de la clé d accès composé du périmètre des composants (date, région AWS, nom du service, chaîne spéciale de caractère donnée par AWS). (cf. Annexe API) 3) La fédération d identité Les outils du cloud hybride viennent fédérer les clouds comme on fédère des Datacenters lors d une fusion d entreprise, quand les outils de gestion sont hétérogènes. Définir des structures (frameworks) c est définir un ensemble de composants réutilisables lors de la création d applications. L authentification s appuie sur des bases comme l Active Directory, ou l annuaire LDAP, qui peuvent être complétées par des bases de Fédération d Identité comme AD FS,. 107 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

109 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Chapitre 4 La sécurité Les patterns de design sécurité sont des blueprints et des instructions pour résoudre les challenges techniques usuels : authentification, autorisation, supervision des logs, single sign-on, etc. Section 3 : Les protocoles et la cryptographie L hétérogénéité des technologies d authentification acceptées par chaque fournisseur de cloud, peuvent poser problèmes. Les fournisseurs de cloud externe doivent fournir des protocoles sécurisés de type SSL/TLS. Ils doivent aussi supporter des mécanismes de cryptographie standards. Exemple : KMIP d OASIS. Figure 53 : Exemple KMIP OASIS travaille sur le Key Management Interoperability Protocol (KMIP) qui standardise la communication entre les clients de cryptographie qui ont besoin de clés et le système de gestion de clés chargé de créer et de gérer les clés. En utilisant un protocole bas niveau qui peut demander et fournir les clés entre n importe quel gestionnaire de clé et n importe quel client de cryptographie, KMIP est un gestionnaire de clé complétement interopérable. A travers cette interopérabilité les entreprises seront capables de déployer une seule infrastructure de gestion de clés pour toutes les applications, composants et systèmes pour une entreprise qui requiert des clés symétriques, des paires de clés asymétriques, des certificats numériques, ou d autres composants de cryptographie. KMIP respecte le cycle de vie des clés spécifié dans la publication du NIST pour définir les attributs reliés aux états. KMIP s appuie sur les mécanismes de sécurité du réseau comme SSL/TLS et HTTPS pour établir une communication authentifiée entre le gestionnaire et le client. KMIP s appuie sur les standards existants d algorithmes d encryptions, la clé de dérivation et beaucoup d autres aspects de solution de cryptographie centré sur l interopérabilité entre client et gestionnaire de cryptographie. 108 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

110 TROISIEME PARTIE : LES PROCESSUS & L OUTILLAGE Synthèse de la troisième partie : processus et outillages Synthèse de la troisième partie : processus et outillages Les principaux processus d approvisionnement et de configuration de ressources matérielles et applicatives sont à automatiser. Tout devient «Software Defined» ou «Application Centric» pour permettre l orchestration, la supervision financière et capacitaire, la mise en place de sécurité, et ainsi améliorer l efficience, la résilience, l agilité. Des niveaux infrastructure jusqu au niveau de supervision des processus, les blocs de construction s améliorent pour pouvoir fournir l agilité qui conduit à l industrialisation de l informatique. Les standards sont essentiels pour gagner en interopérabilité, nous avons ainsi vu des développements Open-Source comme OpenStack, pour l approvisionnement de ressource et des standards comme Tosca d Oasis, pour l interopérabilité des déploiements. Les projets Open, permettent de mutualiser les connaissances et d avancer plus vite au niveau de l automatisation, et de la sécurité. Des standards de fait s imposent également. La sécurité de cette automatisation est clé. Elle passe par des mécanismes classiques de clé publique et de certificat, puis par des mécanismes de Token, transmis par les fonctions définies par les APIs. 109 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

111 QUATRIEME PARTIE : LA MISE EN ŒUVRE DE PROJET DE CLOUD HYBRIDE ELASTIQUE Chapitre 1 Les étapes QUATRIEME PARTIE : LA MISE EN ŒUVRE DE PROJET DE CLOUD HYBRIDE ELASTIQUE Ceux qui auront choisi des technologies interopérables pour leur cloud privé pourront plus facilement évoluer vers l intégration, le cloud hybride. La mise en œuvre d un cloud hybride : les étapes, les rôles et la gestion des compétences et les changements organisationnels. Chapitre 1 Les étapes Dès maintenant beaucoup de projet se heurtent à des difficultés. Il ne s agit pas de livrer des projets d intégration complexe de cloud comme on livre de la «commodité». Les projets qui incluent du cloud computing hybride et élastique sont en général des vrais projets de transformation de l entreprise. Ils s anticipent, se structurent, se planifient par phase ou en itératif pour pas à pas augmenter l efficience des services. Section 1 : L analyse de la stratégie de l entreprise Pas de démarrage de projet sans prise en compte de la Stratégie Business et de la Stratégie Sécurité de l entreprise. 110 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

112 QUATRIEME PARTIE : LA MISE EN ŒUVRE DE PROJET DE CLOUD HYBRIDE ELASTIQUE Chapitre 1 Les étapes 1) La stratégie Business Connaître la stratégie de l entreprise Le domaine dans lequel elle évolue comme : - la rapidité et l importance de l innovation, - ses objectifs : fusion, acquisition, entrée en bourse, synergie, communauté, - ses compétiteurs, ses clients, - ses partenaires et les contrats existants, - les segments du marché ciblés et leurs prérequis, - ses compétences internes, sa culture d entreprise, - sa valeur ajoutée, son ADN, ses valeurs sociales, environnementales. Afin de pouvoir en déduire les facteurs clés de succès, sur lesquels le système d information va avoir un rôle clé. Ainsi il sera plus facile de savoir quelle valeur ajoutée et quel budget, sur quelle échéance. Les facteurs clés du succès nous aideront à définir les métriques et le KPI, que les outils de supervision remonteront dans les tableaux de bord de la gouvernance. Pour suivre la règle émise par le Pareto 20% des fonctionnalités vont recouvrir 80% des besoins. Il faut cerner les priorités conduites par le business. Elles nous aideront à voir si l externalisation de services peut apporter des bénéfices, mais aussi quels services et comment cette externalisation devra être faite pour couvrir le besoin, dans quels délais. 2) La stratégie sécurité Cette fois-ci on s intéresse à la valeur des informations et des traitements de la société. A ce qui se passerait si les données étaient corrompues ou perdues, perdaient leur confidentialité, n étaient momentanément pas accessibles. De la même façon, quel serait l impact d un arrêt des traitements, d un dysfonctionnement, d une non-conformité? En face sont alignés les coûts et les risques pénaux, juridiques, ou de perte d image. Et comme la sécurité à un coût et qu il faut gérer des priorités, il faut pondérer par la probabilité de survenu du dysfonctionnement. Ensuite dans un cloud hybride il faudra savoir si les aspects sécurité sont mieux gérés en interne ou en externe, et à quel coût dans chacun des cas. Et si le passage d un cloud à l autre respecte la stratégie de sécurité et toujours à quel coût (VPN, lien privé, redondance). Les problèmes de l IT traditionnelle se retrouvent dans le cloud hybride élastique, et loin de les résoudre, s ils ne sont pas traités correctement, le risque est grand d amplifier leur impact. Une classification des données, des services et une analyse des risques sont impératives, pour savoir quelles données peuvent basculer sur le cloud, sur quel cloud et comment. 3) L analyse de la demande Une gestion de la demande doit permettre d anticiper, quand et combien de capacité doivent être approvisionnées en externe et pour combien de temps. 111 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

113 QUATRIEME PARTIE : LA MISE EN ŒUVRE DE PROJET DE CLOUD HYBRIDE ELASTIQUE Chapitre 1 Les étapes Cette stratégie de la demande est particulièrement importante car suite à son analyse on prévoit les montées en charge et donc on anticipe l externalisation, le scale out, le scale down. Section 2 : L étude de l existant 1) La gestion de la maturité des processus clients Niveau de Maturité Maturité "Cloud" Description 1- Géré Standardisé 2-Défini 3-Piloté 4-Gouverné Automatisé Orchestré Hyper-Orchestré - orientation métier - orientation service - process opérationnels basiques adaptés - process manuels - business process manuels - réactif - proximité métier - catalogue de service - process complexes en cours de standardisation, règles manuelles - process opérationnels automatisés, orchestration manuelle - business process manuels - actif - piloté avec les métiers, mesuré, controlé - portefeuille de service - process complexes standardisés, règles écrites - process opérationnels automatisés, complexes orchestrés - business process manuels ou en cours d'orchestration - proactif - anticipé et piloté avec les métiers - portefeuille de service maintenu - gestion centralisée des services en cloud hybride - process opérationnels orchestrés par des règles dynamiquement - business process hyper-orchestrés - innovant Figure 54 : Maturité «Cloud» des processus Nous n avons pas détaillé la phase 0, le chaos, celle ou rien n était géré, car il est difficile d y automatiser. 1.1) La standardisation Standardiser les processus Standardiser c est aussi simplifier les processus, ou pourvoir réutiliser des morceaux de processus pour un autre processus, en travaillant toujours de la même façon, avec les mêmes bibliothèques, les mêmes versions, de même produit et de manière modulaire, à chaque fois que c est possible et que l effort est justifié. 112 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

114 QUATRIEME PARTIE : LA MISE EN ŒUVRE DE PROJET DE CLOUD HYBRIDE ELASTIQUE Chapitre 1 Les étapes Il faut étudier les processus et mesurer les écarts avec l objectif. Par exemple pour le cloud hybride, il faut étudier comment sont gérer les approvisionnements des clouds externes, pour étudier une mise en place de cloud hybride afin de voir ce qui peut être automatisé. Ne pas négliger les résistances aux changements La standardisation passe souvent par la mise en place de «Best Practice». La mise en place d outil n a jamais résolu seule des soucis d efficience ou de délais, l automatisation ne peut que venir accompagner des changements structurels. Par exemple s il faut dix jours pour obtenir une adresse IP et que le processus reste manuel sans délégation de plage IP disponible, cela constituera un goulet d étranglement. L automatisation va s accompagner de délégation de pouvoir et de transfert de compétence. Standardiser la technique Une entreprise ne peut pas aller vers l automatisation et encore moins vers l orchestration d un cloud hybride si elle n a pas passé le premier stade de la standardisation. Ce n est pas évident, les fusions, acquisitions sont des challenges réguliers de standardisation. Après une première standardisation les entreprises se retrouvent souvent avec beaucoup d applications en double incompatibles entre elles et des difficultés à consolider les chiffres, la collaboration, les échanges. Important Il faut donc standardiser car en diminuant le nombre de composants, (comme le nombre d OS et leurs versions, le nombre de version d applicatif métier ou de développement, de test) l automatisation se simplifie, les efforts sont moins importants, les buildings blocs sont plus facilement réutilisables. Cette étape n est pas facile car elle engendre souvent des pertes de fonctionnalités existantes et une partie des équipes doit abandonner ses compétences sur un produit pour en acquérir de nouvelles. Mais cela permet de renforcer l agilité intellectuelle, indispensable. La standardisation n est pas évidente. Certaines standardisations n aboutissent pas pour de multiples raisons. Le cloud hybride est un réel besoin du marché et nécessite de la standardisation. Dans le cloud hybride, il faut standardiser la connexion : protocoles, cryptage, 1.2) L automatisation Le «Software Defined Anything» qui est en cours va aider à automatiser les déploiements et les mises à jour systèmes et applicatifs. L automatisation actuelle demande encore beaucoup d intégration, les buildings blocks standardisés de cette automatisation modulaires seront de plus en plus faciles à trouver sur le marché. Le rôle de standard comme Tosca pour la définition des «templates de service» ou Eucalyptus, CloudStack, OpenStack pour l approvisionnement de ressource, vont aider. A fonctionnalité équivalente le produit le plus standard sera favorisé, car plus rapide à intégrer et donc à moindre coût. 113 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

115 QUATRIEME PARTIE : LA MISE EN ŒUVRE DE PROJET DE CLOUD HYBRIDE ELASTIQUE Chapitre 1 Les étapes 1.3) L orchestration Le niveau au-dessus l orchestration permet d intégrer la complexité mais aussi des fonctions supplémentaires de montée en charge ou de réduction de charge, de résilience, de sécurité, d application de règles 1.4) L orchestration du multi-cloud et des processus Dans un niveau non-géré, beaucoup d entreprises utilisent déjà du cloud hybride : des services dans son data-center et des services en externe, mais sans véritable gouvernance. Tant que l utilisation est faible cela peut sembler gérable. Sachant qu il faut appliquer à ces services les politiques de sécurité, la conformité aux règles et législation, la maîtrise de coûts,. La multiplicité des réponses externes à des besoins internes risque de devenir vite ingouvernable. Un autre challenge du multi-cloud est la compatibilité des architectures. Ce n est pas parce que nous aurons deux API-compatibles qui transmettront des fonctionnalités, des paramètres, que ces fonctionnalités seront gérées de la même façon, avec les mêmes paramètres dans chaque cloud. 2) La cartographie de l existant L existant doit être pris en compte sauf pour une entreprise nouvelle, les aspects coûts, risque et temps, ne permettent pas en général de faire un «big-bang» cloud 2.1) L étude des contrats fournisseurs Les fournisseurs de tierce maintenance, de licence ou de maintenance sont des points potentiels de blocage ou de surcoûts projets. Ils ont été abordés dans l étude de stratégie et peuvent influer sur la priorité d un projet. Dans cette phase ils peuvent être étudiés dans un niveau granulaire plus précis pour en estimer l impact. 2.2) La cartographie des produits existants L étude peut se faire par niveau : réseau, stockage, traitement, gestion des applications Figure 55 : Cartographie de l'existant 114 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

116 QUATRIEME PARTIE : LA MISE EN ŒUVRE DE PROJET DE CLOUD HYBRIDE ELASTIQUE Chapitre 1 Les étapes 3) L étude des écarts entre l existant et les exigences 2.1) La classification de l existant Les exigences ont été classifiées dans l étude de la stratégie business, sécurité et demande. Par rapport à ses exigences, il est possible de classer l existant : obsolète, conforme sans plus ou entièrement satisfaisant, ou inutile. Il faut étudier en isolé mais aussi dans l écosystème si leur intégration est judicieuse ou si un remplacement peut-être moins coûteux sur le long ou court terme. L objectif est aussi de simplifier, de diminuer le nombre de composants pour simplifier l intégration, l automatisation, les montées en charge, les déplacements de service. 2.2) Le produit sur étagère ou le développement Pour gagner en efficience informatique chaque cas d usage client doit être traité en favorisant la standardisation. Pour les cas d usage où les produits standards ne semblent pas être le plus efficace au niveau métier, un calcul des gains sur les gains métier (efficience, impact du risque potentiel) mis en parallèle avec le coût informatique de développement et de maintien d un développement spécifique doit être effectué. Il faut connaître et intégrer, interfacer des solutions existantes en connaissant les risques pris, les coûts et économies générés. Le multi-cloud en est un exemple. L intégrateur Dans un marché en pleine évolution il faut savoir s appuyer sur ses forces pour garder et gagner des parts de marché. Le rôle de l intégrateur est de connaître les solutions du marché et d aider le client à trouver la solution qui lui convient et les compétences pour l intégrer. Sa force c est de pouvoir approvisionner sans a priori technique, sur tous les catalogues du marché. La construction d une infrastructure de cloud hybride gouverné est hautement complexe à intégrer et à maintenir et requiert des compétences importantes Les étapes à franchir sont importantes Dans sa démarche il ne faut jamais perdre de vue que le cloud évoluera dans un esprit d amélioration continue. Il faut donc dans le cadre d une vision long terme, le garder ouvert, modulaire, interopérable. 2.3) Le calcul de l effort pour répondre aux exigences Réussir à faire correspondre l existant, les exigences et les solutions potentielles, est un nouveau challenge. Que faut-il faire pour répondre aux exigences et quel serai l effort : changements, délais, coûts? 115 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

117 QUATRIEME PARTIE : LA MISE EN ŒUVRE DE PROJET DE CLOUD HYBRIDE ELASTIQUE Chapitre 1 Les étapes Section 3 : La définition des priorités 1) La taille du projet Préférer des projets courts et des pilotes Dans une démarche agile, il est démontré que de favoriser des projets rapidement mis en place, de 3 à 6 mois, et avec un retour rapide sur investissement est un facteur favorisant la réussite. De même il vaut mieux favoriser un pilote qui aura une utilité immédiate avec une capacité opérationnelle, qu un Proof Of Concept ne servant que de démo et manquant souvent de pertinence. La mise en place d un cloud hybride demande encore beaucoup d intégration en raison de la maturité du marché. Il faut donc focaliser sur des intégrations simples, mais indispensables. Analyse du risque L analyse des risques : impacts et probabilité est indispensable. Elle doit prendre en compte l analyse financière des fournisseurs de cloud, la répartition géographique des clouds internes et externes, 2) Le retour sur investissement Le vrai ROI n est pas simple à calculer car il comprend : le coût, la qualité, les délais, la compétitivité. Le ROI est souvent calculé à partir des coûts du TCO : - Matériel, Licences, Middleware, Plateforme, Maintenance Editeur, Maintenance Matériel, - TMA et support client et administration. Auxquels viennent s ajouter : coût de la surface et annexes (électricité, climatisation, sécurité ), migrations. Hors la qualité va influer directement les coûts de l IT, mais surtout la productivité métier, la relation client, l image. Le temps ou délais de mise en place d un projet, d une solution logicielle vont directement jouer sur la capacité d innovation, le Time-To-Market, l image de l entreprise. Les coûts internes du temps passé par les métiers à effectuer des relances et le manque de compétitivité liés aux délais, ne sont pas faciles à appréhender et ne sont donc souvent pas pris en compte dans le retour sur investissement. Important Le vrai ROI doit prendre en compte l agilité apportée par la possibilité d approvisionner rapidement en externe la bonne ressource : améliorer l efficience métier. Il faut aussi pour cela bien connaître les besoins métier, et se prendre en main l alignement entre l IT et les lignes métier et surtout le client. Un retour sur investissement se calcule au niveau financier mais également au niveau compétitivité. 116 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

118 QUATRIEME PARTIE : LA MISE EN ŒUVRE DE PROJET DE CLOUD HYBRIDE ELASTIQUE Chapitre 1 Les étapes Le cloud hybride élastique offre des possibilités de réduction des coûts Dans le cloud hybride il est possible de mettre des règles sur le coût, la sécurité, la disponibilité, la performance, mais également de n approvisionner que la ressource nécessaire, pour la durée nécessaire, au meilleur coût. 3) Le périmètre des projets sélectionnés Une analyse granulaire permet de mieux estimer le périmètre 3.1) Le contexte et le catalogue de service Les études du contexte (les acteurs, les systèmes et leurs actions) du processus impacté et du catalogue de service associé vont permettre d affiner un périmètre réaliste. Il ne faut pas vouloir décrocher le produit de ses rêves. Mais travailler par phase, pour atteindre rapidement un premier objectif exploitable, une valeur ajoutée business. 3.2) Les fonctions L étude du fonctionnement du processus et de ses relations avec d autres processus permettent aussi de mieux cerner le périmètre. 117 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

119 QUATRIEME PARTIE : LA MISE EN ŒUVRE DE PROJET DE CLOUD HYBRIDE ELASTIQUE Chapitre 1 Les étapes Section 4 : La validation des choix, du périmètre et impact 1) La validation du périmètre, du planning et du budget La validation du périmètre permet d affiner le planning. 2) L implication des acteurs Le choix des priorités est clairement défini, toute décision doit être systématiquement validée. Les rôles des acteurs du projet, leur implication dans le projet et l organisation de la communication sont des éléments essentiels. Les acteurs du projet doivent remplir deux rôles complémentaires à la gestion projet, certains doivent avoir suffisamment de pouvoir pour aider à passer les obstacles qui peuvent se présenter budgétaires ou humains, d autres directement impactés par les changements apportent leur vision pragmatique et préparent le changement. Le choix des fournisseurs externes de cloud est un élément important à valider dans un projet de cloud hybride élastique 3) La validation de l architecture Figure 56 : Modèle de référence Par rapport aux étapes précédentes qui recherchait la granularité cette étape est une étape de prise de recul, pour vérifier la cohérence des choix, les valider. Il s agit alors de regarder, au-dessus du modèle de référence qui définit les services, les produits qui viennent remplir ces fonctions dans un modèle d architecture. 118 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

120 QUATRIEME PARTIE : LA MISE EN ŒUVRE DE PROJET DE CLOUD HYBRIDE ELASTIQUE Chapitre 1 Les étapes Section 5 : La mise en œuvre A chaque étape la correspondance avec les exigences business est validée. Si les exigences n ont pas changé au point de remettre en cause le projet, alors nous passons à la réalisation des objectifs. Dans le respect du planning les commandes sont passées, les compétences sont réservées, la communication planifiée, 1) La description complète des services du catalogue de service La conformité de chaque service par rapport aux exigences est respectée. Les SLA et les métriques correspondants, sont validés, en accord avec ce qu il est possible de faire avec les fournisseurs de cloud et les outils disponibles. Les métriques du cloud hybride élastique doivent mesurer la satisfaction client, et permettre de distinguer les responsabilités entre opérateur, fournisseur de cloud et cloud interne hybride. 2) La conception de l automatisation L automatisation va permettre les gains, si les processus sont corrects. Elle doit être modulaire et standardisée pour pouvoir intégrer les évolutions sans tout remettre en cause. 3) La gestion du changement Anticipée depuis le départ la gestion des changements s inscrit dans le processus de transformation de l entreprise et s élabore en collaboration avec les équipes concernées de façon à rationaliser les processus, standardiser les outils mais surtout anticiper les changements organisationnels, les formations. Les pertes de pouvoir sont compensées par un travail plus valorisant, car apportant plus de valeurs à l entreprise. 4) La mise en exploitation et le contrôle Dans une démarche de DevOps, l automatisation et la mise en exploitation sont intégrés dans le développement. Les retours se font donc toujours en collaboration avec l amont : les développeurs et l aval, la production. Les métriques sont mises en place et leur pertinence est remise en cause régulièrement. Section 6 : Le cycle de vie et l amélioration continue 1) Le cycle de vie La gestion du cycle de vie des composants du cloud hybride va concerner les composants internes, la passerelle, les composants externes. La gestion du cycle de vie sans outil est difficile. Sur une petite infrastructure il peut s agir de fichier Excel. Quand les architectures se complexifient et se massifient, il devient indispensable d outiller, pour gagner en clarté, en sécurité, en suivi financier, en conformité. 119 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

121 QUATRIEME PARTIE : LA MISE EN ŒUVRE DE PROJET DE CLOUD HYBRIDE ELASTIQUE Chapitre 1 Les étapes Certaines données dont les données à caractère personnel doivent être effacées pour respecter la législation, par exemple. Des serveurs physique ou virtuels, des stockages sous utilisés ou non-utilisés coûtent cher. L archivage est moins cher que la sauvegarde. Certains logiciels de stockage, le font automatiquement, il s agit du tiering, dans le cloud hybride il faut pouvoir centraliser l information ou le gérer différemment. 2) L amélioration continue En s appuyant sur la roue de Demming (Plan/Do/Check/Act) ou le DMAIC (Define, Mesure, Analyze, Improve, Control) un processus d amélioration des automatisations doit être mis en place. D autre part la mise en œuvre d un projet de transformation incluant du cloud hybride élastique doit s effectuer par phase, en repartant des exigences qui évoluent sans cesse il faut dérouler régulièrement toutes ses étapes pour intégrer de nouveaux processus ou services. L amélioration continue nécessite la gestion des retours d expérience et des connaissances. 120 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

122 QUATRIEME PARTIE : LA MISE EN ŒUVRE DE PROJET DE CLOUD HYBRIDE ELASTIQUE compétences Chapitre 2 Les rôles et la gestion des Chapitre 2 Les rôles et la gestion des compétences Section 1 : Le rôle de la DSI, la gouvernance du Système d Information Pour gérer le cloud hybride, la DSI devra œuvrer sur plusieurs axes, pour lesquels elle disposera d outils. 1) La gestion des fournisseurs Comme auparavant avec la Tierce Maintenance Applicative, l hébergement, les services managés, ou la sous-traitance, le DSI devra gérer le partenariat avec les métiers et le juridique pour contribuer : - à la validation de contrat avec des fournisseurs de service, - à la vérification et au suivi de leur conformité par rapport aux exigences du service fourni. 2) La supervision des performances et l anticipation de la demande par des tableaux de bord L anticipation de la capacité nécessaire aux services métier est un élément essentiel pour éviter les dysfonctionnements. Cela passe par une analyse des données existantes et une prévision en lien étroit avec les métiers, avec l aide d outils de supervision et d analyse prédictive. Exemple VMWare vcops Par exemple le monitoring de capacité intégré à vcops de VMWare, basé sur un outil analytique d auto-apprentissage comportemental, permet de gérer les capacités. Après une première étude du comportement pendant trois mois du service, et grâce à des algorithmes prenant en compte l expérience précédente de multiples clients, il peut donner des axes d amélioration et des prévisions de besoin de capacité. 3) La cohérence du SI en collaboration avec les métiers Les métiers seront de plus en plus utilisateurs de numérique et sont souvent les mieux placés pour choisir une solution qui correspond à leurs besoins : achat, logistique, finance, comptabilité, gestion des talents, communication, maintenance, marketing, cœur métier (édition, fabrication, inspection, conseil, ). La DSI peut être force de proposition, mais surtout elle doit toujours assurer la cohérence du système d information de l entreprise, définir les interfaces surtout entre les métiers, les référentiels, le respect de la stratégie, de la conformité. A quoi sert une base fournisseur à la comptabilité si elle n est pas cohérente avec celle des achats? La base CRM mise à jour par les commerciaux doit être accessible par le marketing. Toutes les dépenses : achats, paies doivent entrer dans le système financier. 121 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

123 QUATRIEME PARTIE : LA MISE EN ŒUVRE DE PROJET DE CLOUD HYBRIDE ELASTIQUE compétences Chapitre 2 Les rôles et la gestion des 4) La gestion du multi-cloud et du cloud privé Pour gérer plus de complexité et gagner en agilité, il faut automatiser et pour cela il faut : - faire progresser la maturité et l agilité des processus, - définir les automatisations à mettre en priorité, en accord avec la valeur apportée au business, la stratégie de l entreprise, - intégrer des clouds externes, - veiller à la disponibilité, la sécurité, la conformité. Section 2 : Les compétences La complexité des infrastructures de cloud hybride et l automatisation font apparaître des changements de rôles, voire de nouveaux rôles. 1) La simplification des processus Un mauvais processus automatisé reste un mauvais processus. Le passage aux nouveaux écosystèmes ne peut se faire sans d abord rationaliser le fonctionnement, déléguer des pouvoirs, faire évoluer les compétences. Les compétences en rationalisation, simplification des processus sont alors nécessaires. L approche reste orientée service mais cherche un peu d agilité. 2) Le «software defined anything» Les vocabulaires à la mode («Buzz words») sont «Software Defined» ou «Application Centric». Que l on préfère le premier ou le deuxième, tout tourne bien autour du logiciel ou de l applicatif. Les objets matériel ou applicatif sont de plus en plus modulaires et paramétrables, donc l intégration change : les tâches répétitives sont automatisées, l intégration demande plus de compétences «software». Naturellement sur des logiciels récents : Java, Phyton, Ruby, C est particulièrement disruptif pour le réseau et le stockage. Pour réaliser ses automatisations il faut savoir modéliser et scripter. Pour gérer un projet il faut en comprendre le vocabulaire, le fonctionnement, les composants. Il faut savoir modéliser pour réaliser le design des Services Templates, mais aussi pour programmer ou scripter en modulaire afin de pouvoir capitaliser, réutiliser des «buildings blocks», ou pour modéliser les applications, le cycle de vie des applications, le déploiement, les services, les workflows, les architectures. Il faut savoir scripter pour faire le liant, intégrer. Les compétences en virtualisation et en consolidation sont complémentaires de ces compétences de modélisation et de programmation. 3) Le transverse Les frontières entre le réseau, le stockage, le traitement mais aussi avec le développement et l exploitation sont de moins en moins franches. D ailleurs, la démarche de DevOps vise à rapprocher 122 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

124 QUATRIEME PARTIE : LA MISE EN ŒUVRE DE PROJET DE CLOUD HYBRIDE ELASTIQUE compétences Chapitre 2 Les rôles et la gestion des les équipes de développement des équipes opérationnelles et à leur faire effectuer des tâches autrefois attribuées à leurs collègues. Les fonctions de débordement, de montée en charge font appel à différents éléments réseau, stockage, traitement, applicatif, ce qui demande une connaissance des différents «silos». De plus il faut gérer des fonctions complexes qui font appel à de multiples compétences. Il faut donc des compétences transversales, qui s appuient sur de la modélisation. 4) L intégration Comme toujours une bonne connaissance des produits existants du marché et de leur capacité d intégration est nécessaire. Suite à cette étude nous focaliserons sur les logiciels d automatisation et d orchestration mais aussi de virtualisation, d administration, de supervision, de la sécurité. 5) La sécurité La gestion du risque est essentielle. Elle demande une vue globale : de la formation des personnes, en passant par la gestion de la conformité et jusqu à la mise en place de systèmes adaptés. Elle complète le péri métrique standard : classification, cryptage, tunnel, détection d intrusion, analyse comportementale. La connaissance des produits du marché comme ceux : de la gestion de l identité et des accès, des API, de protocoles et de cryptages est importante pour la gestion du cloud hybride. Important En conclusion de cette section sur les compétences nous pourrons conclure que la compétence principale à avoir est la capacité d apprentissage, d évolution qui va permettre une souplesse d adaptation. Il ne faudra pas l oublier dans les matrices de compétences. De plus il faudra multiplier les sources de connaissance et donc utiliser tous les nouveaux canaux d apprentissage, en particulier le partage collaboratif interne et externe. 123 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

125 QUATRIEME PARTIE : LA MISE EN ŒUVRE DE PROJET DE CLOUD HYBRIDE ELASTIQUE organisationnel Chapitre 3 : La gestion du changement Chapitre 3 : La gestion du changement organisationnel L évolution de l écosystème est une rupture qui rend obsolète les modèles économiques et organisationnels précédents, et amène l émergence de nouvelles organisations, de nouveaux acteurs, de nouvelles technologies. - Il faut devenir plus agile, plus innovant en maîtrisant le risque. - Il faut passer du sur mesure à la sélection de services adéquats : conseil pour l intégration, prise en compte du réglementaire. - Les données deviennent une partie du business, leur valorisation, et protection sont capitales. Mais il faut garder la gouvernance, et sans centralisation c est un travail d équilibriste. Pour garder la gouvernance des organisations doivent équilibrer les pouvoirs, simplifier et clarifier les processus de validation et savoir garder les compétences. Section 1 : Impact sur les organisations Les frontières s étant déplacées, beaucoup d acteurs du marché : hébergeurs, opérateurs, intégrateurs sont devenus, en plus de leurs compétences traditionnelles, fournisseurs de services cloud. Cette transformation n est pas évidente, car elle demande la création d une offre compétitive correspondant aux exigences sur un marché cloud plutôt saturé entre l offre et la demande. De plus elles se heurtent à des sociétés qui par des mécanismes d optimisation fiscales ont des capacités d investissement nettement supérieures. 1) Les entreprises nouvelles, les TPI Plus d infrastructure interne à mettre en place, elles sont cloud à 100% et si elles centralisent leurs services ce sera chez un broker de cloud. Des fournisseurs de cloud donnent de plus en plus de garanties sur la sécurité et des possibilités de liaisons sécurisées et de cryptage, mais cela a un coût. La gestion de l informatique consiste à comprendre les métiers, gérer le budget, l aspect contractuel, les conformités et le juridique, la sécurité, l anticipation, en s appuyant sur des experts externes. 2) Les entreprises avec une infrastructure interne importante Débordées par la Shadow It, souvent moins cher et plus agile car moins sécurisée, moins maîtrisée, elles s organisent en rédigeant des chartes pour leurs employés et en offrants des services équivalents, agiles, en interne plus sécurisés. Elles ont de plus en plus d hybride, mais quand les cloud externes se multiplient il faut soit faire appel à un courtier de cloud, soit réaliser des solutions d intégration internes. La gestion de l informatique consiste à comprendre les métiers, gérer le budget, l aspect contractuel, les conformités et le juridique, la sécurité, l anticipation, en s appuyant sur des experts internes et externes. Mais surtout elle est le centre de rationalisation et de standardisation. Elle doit avoir un 124 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

126 QUATRIEME PARTIE : LA MISE EN ŒUVRE DE PROJET DE CLOUD HYBRIDE ELASTIQUE organisationnel Chapitre 3 : La gestion du changement appui fort de la direction, par rapport à tous les métiers, y compris la finance, le marketing, qui perdent en budget, en personnalisation des outils, pour anticiper l avenir en apportant de l agilité et des baisses de coûts. Elle est au cœur de la stratégie, comme le marketing. 3) Les courtiers Ce sont déjà les principaux intégrateurs de clouds hybrides. Ils ont besoin de connecter leurs clients à différents fournisseurs de cloud hybride. Pas étonnant de retrouver des prémices de solutions de cloud hybride chez certains Ils deviennent alors éditeurs, mais ce n est pas facile car c est un autre métier, il faut gérer les contrats de maintenance, l ajout de fonctionnalité, les nouvelles versions, les relations avec les éditeurs et fournisseurs de matériel, pour les compatibilités 4) Les fournisseurs de matériel et de logiciel cloud Les fournisseurs de matériel et de logiciel changent de client, le marché se déplace de plus en plus vers l intégrateur de cloud privé mais surtout vers les fournisseurs de cloud qui parfois conçoivent eux-mêmes leurs infrastructures ou leurs logiciels de gestion. Les grands acteurs du logiciel intégreront de plus en plus de fonctionnalités dans leurs produits et seront certainement les principales places de marchés des «Service Template» ou Pattern, des API, des passerelles. Avec les clouds privés, ils ont encore un marché devant eux et seul l avenir nous dira si l informatique deviendra finalement une commodité comme l électricité. 5) Les intégrateurs 5.1) Les métiers Les intégrateurs doivent toujours connaître les outils du marché, qui évoluent. Les applications SaaS ne demanderont plus beaucoup d intégration. Au début l intégration est basique comme avec OpenStack, puis les packages, les outils se mettent en place, il faut intégrer le niveau supérieur. Ce qui limite les possibilités de capitalisation interne en IP, la propriété interne étant plus sur le vivier de compétences, ses capacités à s adapter. Par contre celui qui a intégrer OpenStack à la main, maîtrise parfaitement le système et sera plus à même d intégrer le niveau supérieur. Il est possible de distribuer ses travaux modulaires sur des stores, mais rapidement avec une date de «fraîcheur». 5.2) Le marché Même soucis que les fournisseurs de matériels et de logiciels, si le marché devient commodité et que le nombre d acheteurs se réduit la pression risque d être encore plus forte sur les prix. En attendant un intégrateur qui a les compétences demandées par le marché devrait avoir beaucoup de travail, a lui de favoriser les bonnes formations. 125 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

127 QUATRIEME PARTIE : LA MISE EN ŒUVRE DE PROJET DE CLOUD HYBRIDE ELASTIQUE organisationnel Chapitre 3 : La gestion du changement L intégration actuelle ne sera pas forcément réutilisable, les fournisseurs de logiciel étant déjà sur ce type de problématique avec la gestion de drivers et de firmwares. 6) Les info-géreurs Les métiers changent surtout pour l infogérance de tâches basiques et répétitives, les plus faciles à automatiser. Si le nombre d acheteurs se réduit la pression risque d être encore plus forte sur les prix. Ils doivent être des professionnels de l intégration de passerelles, de l automatisation pour en gérer le support. Ils doivent rendre plus convivial la supervision et proposer les tableaux de bord. 7) Les hébergeurs Ils se mettent au cloud progressivement. Ils doivent proposer de la valeur par rapport aux mastodontes du marché : de la localisation, de la transparence, de la visibilité, de l hébergement de fournisseur SaaS, des services de sécurité, de courtiers,... tout en sachant que s il le peut le mastodonte le proposera également. 8) Les éditeurs de progiciel Pour des éditeurs de progiciels d administration ou de comptabilité française avec des spécificités très nationales, il reste encore un créneau de passage dans des solutions progressivement hébergées puis SaaS. Pour la majorité la concurrence sera rude et le virage doit être pris. Des partenariats se développent entre les majeurs du marché pour proposer des solutions optimisées, infrastructure et logiciel. Il éditeurs doivent développer des nouveaux logiciels, ceux-ci devant être adaptés au nouveaux fonctionnement : asynchrone, sans état, gestion de files, multi-locataire, modulaires, Par exemple SAP qui a créé HANA. Section 2 : Réversibilité Comme pour la sécurité il faut comparer avec la situation actuelle pour voir si l évolution permet de gagner ou non en liberté de choix. Les projets de migration d un ERP à un autre, d une Tierce- Maintenance à une autre, peuvent être longs et coûteux. La différence entre une migration sur site et une hors site est essentiellement sur le coût et les formalités de la récupération des données par internet, et l accessibilité en cas de défaillance du fournisseur. Le cas s est déjà produit en Angleterre avec une société qui demandait de l argent pour restituer les données suite à une faillite, elles peuvent aussi devenir inaccessibles. En ce qui concerne le format des données et les procédures de réversibilité, il n y a pas de grandes différences avec un engagement sur site. Il est tentant pour un prix séduisant, des fonctionnalités tentantes, de s engager sur des offres contractuellement ou technologiquement moins intéressantes sur du long terme. Pour une bonne 126 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

128 QUATRIEME PARTIE : LA MISE EN ŒUVRE DE PROJET DE CLOUD HYBRIDE ELASTIQUE organisationnel Chapitre 3 : La gestion du changement gouvernance, les processus internes doivent être mis en place sur ce sujet avant que le problème ne se pose, en collaboration avec les services juridiques. Une analyse des risques doit être faite. Important Comme nous l avons vu précédemment, si les processus d automatisation sont basés sur des produits standards du marché, en briques modulaires et avec une bonne interopérabilité, la migration et l intégration seront simplifiées. Section 3 : Le respect de la législation et de la conformité Le «shadow IT» conduit à des risques internes en fonction de la sensibilité des données mais aussi à des risques légaux et de non-conformité aux réglementations. 1) Les données personnelles Les données personnelles médicales ne doivent pas sortir de territoire français. Les données personnelles permettant d identifier une personne, nom, prénom et date de naissance par exemple, ne doivent pas quitter l Europe à l exception des zones ayant signé un accord de «Safe Harbor». (Loi du 6 janvier 1978 modifiée, chapitre 12, article 68, 69,70) Le Safe Harbor permet à une entreprise de certifier qu'elle respecte la législation de l Espace Européen Economique. Le pays doit également avoir signé des accords avec l EEE. Le transfert des données personnelles de l'eee est alors autorisé par l EEE conformément à la directive 95/46/CE. Il s agit d une obligation de moyen. C est donc un engagement très limité. Les données ne doivent être gardées que si elles sont nécessaires et ne doivent pas être conservées quand elles ne sont plus utiles. (Loi du 6 janvier 1978 modifiée, chapitre 2, article 6,7 ) Les risques encourus sont des peines de prison et des amendes. (Exemple Loi du 6 janvier 1978 modifiée, section 5, article à 24 : 5 ans d emprisonnement et ) Ce sont les lois françaises, les lois allemandes sont plus restrictives au niveau des données personnelles. Plus largement la législation de chaque pays est différente ce qui complexifie le fonctionnement multinational du cloud computing. 2) D autres aspects Pour des règles comme le PCI-DSS sur les paiements bancaires, par exemple, il faut également assurer la conformité du transfert des données. 3) La localisation en cloud hybride En cloud hybride, il faut savoir où seront localisées les données, mais surtout où elles seront sauvegardées pour le Plan de Reprise d Activité ou de Continuité d Activité du fournisseur de cloud par exemple, et quelle est la politique d effacement ou de résilience des données. 127 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

129 QUATRIEME PARTIE : LA MISE EN ŒUVRE DE PROJET DE CLOUD HYBRIDE ELASTIQUE organisationnel Chapitre 3 : La gestion du changement Ensuite il faut vérifier les risques légaux et réglementaires, en fonction du pays et des données. Les responsables de l IT doivent donc travailler avec le juridique. Et en ce qui concerne les métiers ils doivent travailler en collaboration avec les responsables de l IT et le juridique pour mieux maîtriser les risques. Des métiers de responsable du suivi de la conformité et de la légalité sont parfois nécessaires dans la continuité des Correspondants Informatique et Liberté. Section 4 : Analogie avec le «software defined» Reprenons notre exercice de la 3 ème partie «Les processus et l outillage», transportons-nous dans une société «multi-sites» et essayons l exercice de style de faire du «software defined» organisationnel. Nous avons les silos infrastructure, applications et production. Nous leur appliquons déjà la philosophie de DevOps, c'est-à-dire que les développeurs intègrent les notions de mise en exploitation et de production. Ce qui conduit par exemple un développeur à préparer des scénarios de recette, afin qu il intègre les notions de déploiement et de support. Si nous suivons le schéma «Software Defined», nous faisons une abstraction entre la partie traitement et la partie contrôle, pour centraliser le contrôle qui doit gérer la configuration et l approvisionnement des ressources. Les ressources sont les composants matériels. Les experts des domaines infrastructure (réseaux, stockage, traitement), applicatif (développement, production) et métier les contrôle de manière centralisée à un niveau transverse, central et collaboratif. Ils permettent la mise en musique, l orchestration. Ce qui va nous permettre d effectuer des fonctions multi-domaines d expertises : de l équilibrage de charge, du débordement, de l embarquement en respectant des politiques, des règles, financières, de sécurité, de conformité. La supervision de l automatisation, la définition des politiques et des règles reste l humain. Naturellement grâce à des outils de mesure et de l analytique qui s appuie sur les données massives, la supervision gérée par logiciel crée les tableaux de bord ciblés métier, technique, exécutif ou financier. Nous sommes aussi ne l oublions pas sur de «l Application Centric», nous gérons le déploiement des ressources à l aide d outils qui intègrent des scénarios complexes. Le niveau transverse, central et collaboratif est aussi géré par logiciel. 128 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

130 QUATRIEME PARTIE : LA MISE EN ŒUVRE DE PROJET DE CLOUD HYBRIDE ELASTIQUE œuvre de projet de Cloud hybride Synthèse de la quatrième partie : La mise en Synthèse de la quatrième partie : La mise en œuvre de projet de Cloud hybride Les mises en œuvre de projet de cloud hybride nécessitent de connaître la stratégie de l entreprise et des métiers, de connaître les écarts entre l existant et les exigences pour mettre en place des solutions avec un retour rapide sur investissement. Il faut également mesurer la maturité des processus de l entreprise, pour passer au stade supérieur et gérer les priorités en fonction des budgets. Ensuite en fonction des outils existants il faut valider le périmètre, l architecture et les plannings, et s assurer de l implication des acteurs. Après avoir fait des choix d intégration en privilégiant les produits sur étagère interopérables, il faut mettre en œuvre. Les nouvelles compétences doivent permettre à la fois de travailler en modulaire pour gérer la complexité et en transverse pour intégrer les exigences métier. Les différents composants de l infrastructure à la supervision des business process, prennent en charge les aspects de conformités légales et réglementaires, sans oublier la sécurité et l interopérabilité. Mais il n y aura pas de bénéfice si le projet n est pas pris dans son ensemble, il s agit de projets de transformation qui nécessitent une gestion du changement. Nous avons regardé globalement les changements organisationnels en fonction du rôle de l entreprise dans le marché de l IT, qui vont nécessiter une maîtrise de l automatisation et de l intégration mais surtout plus de transverse, de collaboratif. 129 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

131 CONCLUSION Prospective CONCLUSION Vers une hyper-orchestration sans-couture entre clouds. Prospective Evolution technologique Figure 57 : L'évolution d'infrastructure vue par Intel La figure ci-dessus montre une agrégation de la mémoire et du traitement, des ensembles mémoire, cache, stockage. Le rassemblement de composants dans une infrastructure pour gagner en performance est intéressant si l on ne perd pas en évolutivité, compatibilité, interopérabilité, souplesse, agilité. Pour les configurations matérielles et logicielles les plus fréquentes des blocs optimisés sont créés. Il ne faut pas d opposition entre pré-intégrer, optimisé et évolutivité. Les solutions doivent rester interopérables simplement pour s adapter à moindre coûts à la forte évolution en cours. Les évolutions réseau, stockage, mémoire vont être accompagnées d évolutions applicatives, fonctionnelles, chacun tirant l autre vers le haut. La concentration appelle une densification des composants qui se réorganisent. La modularité est importante pour l évolution. La démarche actuelle qui diminue l adhérence et assouplit l automatisation va vers une externalisation du contrôle. Pour limiter les effets sur la bande passante, ce contrôle est hiérarchisé. Grâce aux interfaces standardisées les environnements hétérogènes seront plus faciles à intégrer, à centraliser. D un autre côté les tâches qui n ont pas besoin de configuration centrale seront traitées au niveau du composant pour améliorer les rapidités de traitement et ne pas occuper de bande passante. 130 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

132 CONCLUSION Prospective Un écosystème Les innovations fonctionnelles, comme l i-tunes, le smart-phone, l internet ont du succès quand elles répondent à un besoin, et qu elles sont simples et agréables et abordable. L intégration et l automatisation en s appuyant sur du modulaire doit donc être simple, agréable et si pas chère. Il faut essayer, progressivement, d arriver aux «3 clics» de l e-commerce. La créativité peut-être dans la simplification. Les écosystèmes en cours qui évoluent beaucoup sont : l analyse big data, l internet des objets, la réalité augmentée, la convergence numérique, le multi-devices, l impression 3D. L innovation est dans l intégration de ces nouveautés entre elles ou avec de l existant comme par exemple le Near Field Communication ou le RFID pour répondre à un besoin spécifique. La biotechnologie, les robots devraient aussi apporter un champ d innovation. Comment savoir à l époque des voitures à cheval que celles-ci seraient un jour tractées par des moteurs à essence? On peut imaginer facilement des datacenters entièrement gérés par des robots plongés dans des fluides bio Tech pour le refroidissement, c est déjà réalisable. Il ne faut pas oublier que les clouds vont devoir réduire leur consommation d énergie, car le prix de l énergie devrait monter drastiquement. Il ne faut pas tout réinventer, il faut assembler des produits sur étagères, des buildings blocks et donc travailler à plusieurs entreprises sur les projets. Parallèle avec la finance Le vocabulaire du cloud fait parfois référence à la finance, comme pour ces trois étapes de maturité du cloud : - le courtier de cloud ou cloud broker, - la place de marché ou market place : des magasins d API et de package d intégration, de - la bourse d échange de cloud : le surplus de puissance est proposé sur le marché à un prix qui varie en fonction de l offre et de la demande. Ce changement n arrive pas avec un modèle unique. Dans l entreprise déjà des entités sont courtiers de cloud pour d autres entités. Le monde est et sera communicant Les services font appel à d autres services, pour donner de la valeur ajoutée. Les services sont donc inter-facturables, ou trouvent un modèle de rémunération en récupérant de l information monnayable. L internet des objets, avec toutes ses capteurs, va transformer peu à peu notre vie, avec la possibilité de récupérer des informations à distance, et de les sélectionner à l aide d algorithmes reliés au big data. L analytique est vraiment un accélérateur d innovation, elle va aider d ailleurs à gouverner le cloud hybride élastique. 131 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

133 CONCLUSION «Le monde qui vient» Des formations en ligne comme les MOOCs se multiplient. Les outils de collaboration se simplifient et deviennent de plus en plus intuitifs. Comment l automatisation permet l élasticité Le «Software Defined Anything», concept qui sépare la couche de contrôle de la couche de traitement est l élément central qui permet l orchestration de l élasticité en cloud hybride. L automatisation d abord possible au niveau d une baie, d un cluster de serveur, devient possible au niveau d un datacenter puis de multiples clouds. Pour ceci il faut extraire la couche de contrôle de chaque composant pour la centraliser grâce au «software». Pour la centraliser sans effort il faut que les APIs soient standardisées, mais modulaires pour pouvoir continuer à ajouter de la valeur, par des modules, sans compromettre la compatibilité. A terme les contrôleurs centraux doivent aussi répondre à des standards. Ces contrôleurs centraux, hiérarchisés, permettent de gérer les Fonctions Virtualisées ou xfv (Anything Fonction Virtualization), qui sont des fonctions faisant appel à différents composants du cloud : réseau, stockage, traitement, applicatif et flux pour gérer le débordement, la sécurité, les priorités du service... Les outils d approvisionnement de ressource comme OpenStack, les outils d automatisation, d orchestration ou de gestion de cloud, les «Services Templates» comme TOSCA, permettent d intégrer et de rendre interopérables le multi-cloud. La virtualisation du réseau permet de configurer des éléments physiques : il devient plus facile de leur faire accepter de nouveaux flux en entrée et en sortie de cloud par exemple et d optimiser, de contrôler le chemin. La virtualisation du réseau permet d ajouter des éléments réseaux dans une machine virtuelle. La virtualisation permet de gérer de la sécurité (VxLAN, Firewall, ). Il s agit d un élément essentiel pour faire de l élasticité. «Le monde qui vient» Pour faire référence à Michel Serres Le Monde qui vient est différent. Comme l arrivée de l imprimerie a révolutionné l acquisition et l utilisation des connaissances, la profusion d information, amenée par les capacités de stockage, sa diffusion instantanée portée par la bande passante, les contacts «numériques» aidés par les réseaux sociaux, les capacités d analyse massive, la géo localisation, la réalité augmentée, l internet des objets, vont changer notre monde. De «DevOps» à l «Holacratie» (cf. Bibliographie : Holacratie), le management en sera impacté. Le cadre qui améliore l efficacité et la qualité montre ses limites. Le monde va vite, le récurent ne se traite pas comme l innovation, il faut inventer des systèmes simples, souples, collaboratifs et créatifs. L élasticité du cloud hybride est un focus, sur une évolution technique parmi d autres qui permet d améliorer la collaboration, tout en favorisant la liberté source d agilité. Les outils pour gérer de 132 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

134 CONCLUSION «Le monde qui vient» façon simple ces environnements complexes vont se multiplier, certains disparaîtront d autres deviendront des standards de facto. Globalement ces outils s appuient sur la capacité de traiter des informations en masse et de les analyser, apportant ainsi des capacités d auto-apprentissage, afin d améliorer une automatisation conduite par des règles, des mesures, des profils. Ils sont basés sur des scénarios qui vont masquer la complexité. Tout est basé sur des éléments modulaires, qui s imbriquent, se paramètrent. John McCarthy a écrit en 1955 pour une conférence sur l Intelligence Artificielle : "L étude se base sur l hypothèse selon laquelle chaque aspect de l apprentissage ou de tout autre caractéristique de l intelligence peut en principe être si précisément décrit qu une machine peut être construite pour le simuler» (1). (1) "The study is to proceed on the basis of the conjecture that every aspect of learning or any other feature of intelligence can in principle be so precisely described that a machine can be made to simulate it." C est ce que fait l automatisation, l orchestration mais aussi l analyse du big-data. La machine vient aider l homme. Les changements semblent révolutionnaires pour certains, lents pour d autres. Ils s inscrivent dans une transformation, de la technique, des services, de l entreprise, de notre monde. Il ne s agit pas de savoir s il faut avancer, mais plutôt de comment nous allons le faire. 133 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013

135 CONCLUSION Le reste à faire Le reste à faire Les challenges technologiques de l hybride élastique Figure 58 : Challenges de l'hybride élastique Dans l hybride élastique beaucoup de services existent mais il reste du travail pour simplifier l interopérabilité et l intégration afin de fournir des solutions répondants à toutes les exigences métier. Tout n est pas encore complétement«software Defined», qu il s agisse de l infrastructure dont le stockage, de l applicatif ou des flux. La centralisation et l externalisation du contrôle des composants du cloud doit être maîtrisée : elle ne doit pas apporter des points de faiblesses de type S.P.O.F. (Single Point Of Failure) ou des failles de sécurité. Le cloud hybride élastique est là, maintenant il faut le gérer. Des solutions existent déjà de débordement sur des capacités de traitement ou de stockage (comme celles d AWS EC2 ou S3). Elles montent progressivement en fonctionnalités. Ce n est pas évident car : - c est un marché qui bouge vite, il faut s adapter, cela demande une transformation interne, - les produits intégrés sont rares, il faut beaucoup d investissements, et quand la maturité avance, il faut savoir se débarrasser de ses premières intégrations pour s approvisionner dans les nouveaux standards, les nouveaux produits sur étagères, les nouveaux fournisseurs de cloud. Mais cela permet une montée progressive en maturité des processus et en compétences. 134 Geneviève Ribot Mastère Spécialisé «Expert Cloud Computing et SaaS» ISEP FC Novembre 2013