Architecture Cloud: Conception une Infrastructure Cloud

La définition du Cloud Computing diffère d’une personne à une autre ou du moins d’un Monde à un autre. Personnellement, je trouve que la définition du NIST est la plus approprié et en corrélation avec « The real world, the world of IT »: Le Cloud est un environnement dans lequel des ressources, telles que le compute, le réseau, le stockage et les applications, peuvent être rapidement provisionnées par les consommateurs avec peu ou pas d’interaction de la part du fournisseur du Cloud. Ces ressources sont accessibles à travers le réseau et sont extraites des pools centraux selon les besoins, puis renvoyées à ces pools lorsqu’elles ne sont plus nécessaires.

A partir de cette définition, on retient ce qui a été souligné en gras, les cinq caractéristiques du Cloud:

• Self service: Le consommateur est capable de provisionner des ressources ou des services sans l’intervention du Cloud provider
• Accès réseau: Le consommateur est capable d’accéder à ces ressources ou ces services à travers un réseau
• Pool de ressources: Les ressources sont partagées par tout les consommateurs et peuvent être séparées en se basant sur le modèle multi-tenant
• Elasticité: Les ressources sont provisionnées en demande automatiquement (Provisionnement ou décommissionnent) . Les ressources aux yeux du consommateur doivent paraître illimité et disponible à n’importe quel moment.
• Mesure du service: Mettre en place un mécanisme de monitoring et de reporting qui permet d’afficher la consommation des ressources des utilisateurs et le coût associé.

Ce sont ces caractéristiques qui font la différence entre une conception d’une infrastructure Cloud à une autre.

Maintenant que nous nous sommes mis d’accord sur la définition et les caractéristiques du Cloud, nous allons citer ci-dessous les éléments que nous prenons en considération pour concevoir une infrastructure Cloud. Premièrement, le modèles de déploiement Cloud: Le Cloud privé, le Cloud public, le Cloud hybrid ou le Cloud communautaire (qu’on entend très peu parler), le modèles de service Cloud: IaaS, PaaS ou SaaS, le type de Workload à exécuter sur le Cloud: Workload traditionnel (monolithique), workloads Cloud Native (modulaire), l’infrastructure: traditionnelle, convergé ou hyperconvergé, s’il s’agit d’un greenfield ou brownfield, le changement organisationnel (Dev, utilisateurs, Admin, GRC, etc…)

L’approche à adopter se définit comme suit: utilisation de framework et méthodologie (ex: TOGAF), définition des objectifs et du périmètre, audit (organisation et assests), solutions techniques, communiquer (présenter et former), documenter.

Une fois que les informations requises ont été collectées et le processus de conception définie, la phase suivante consiste à la conception et la mise en place d’un CMP (Cloud Management Platform). On peut citer quelques composants d’un CMP: le portail, le service catalogue, l’orchestration, le contrôleur software defined, authentification, monitoring, etc…). La sélection d’un CMP dépend du besoin des métier. Les prérequis collectés précédemment suite à l’audit, nous aidera à choisir le CMP à mettre en place tout en tenant compte l’intégration de l’infrastructure et les contraintes organisationnelle (licence agreements, expertise des staffs, etc…). Sur le marché, on y trouve des CMP propriétaire (VMware, Microsoft) ou Open Source (Openstack, CloudStack). Les CMP diffèrent l’un de l’autre et les services supportés de chaque CMP également (IaaS par ex.). Une organisation a cependant la capacité de déployer plusieurs service catalogue et les déployer sur un portail centralisé. Il existe plusieurs solutions de Cloud management dont certains offrent uniquement une interface et l’orchestration et d’autres un peu plus poussées (personnalisation) avec un plus de composants intégrés et qui vont au delà des fonctionnalités de l’IaaS. D’autre fonctionnalités qui sont susceptible d’influencer le choix du CMP sont le support de la multi-tenancy, Role based Acces et les API.

Le choix de l’infrastructure dépendra du CMP. L’infrastructure peut être physique (ex: chaque composant d’Openstack installé sur un noeud physique) ou virtuelle (VMware: vCenter, vROps, vRO, vRA, NSX, vSAN). Le sizing de l’infrastructure se base sur le nombres d’utilisateurs, de services, type de service, redondance des composants, HA. Le choix de la connectivité également: localisation de l’utilisateur, type de device, protocoles, etc…Cependant, il faut tenir compte de la bande passante, nombre de LB, la configuration des parefeu et CDN et définir si le réseau sera accessible publiquement ou isolé. La zone de sécurité (zone de trust des utilisateurs, serveurs, applications, etc…) doit être aussi définit. Si elle doit partager le même mécanismes d’authentification et d’autorisation. les zones de contrôle physique ou logique sont placées afin de restreindre les accès non autorisé. Le CMP est le premier point d’entré de l’infrastructure Cloud. La première chose à prendre en considération est de mettre en place une authentification fiable utilisant des protocoles sécurisé tels que HTTPS et LDAP. Mettre en place des solution PKI, utilisé pour crypter le trafic. IPS, antivirus et patch du SE pour protéger les serveurs. Le CMP doit être équipé d’un système de logging afin de collecter les logs des différents parties tels que le portail, le serveur d’authentification, les erreurs d’infrastructure. Le CMP a la capacité de provisionner des ressources sur le cloud, il est donc nécessaire de comprendre quel hyperviseur ou cloud public sont supportés pour le provisionnement (ex: le endpoint VMware se connecte sur vCenter, le endpoint AWS se connecte sur le l’API Amazon, etc…)

L’implémentation des ressources tels que le compute, réseaux et stockage représentent un défi. Le choix se basera également sur les besoins des métiers. Pour former un pool de ressource, on s’appuie sur les ressources compute. Il faut donc comprendre les prérequis de chaque composant du compute tel que la capacité, performance, virtualisation, disponibilité, coût et sécurité. On peut mettre en place un ou plusieurs pool de ressources selon le besoin. Ces pools seront définis selon leur performance, sécurité, isolation et localisation. Pour certains cas, on choisi de séparer les données et les services d’une infrastructure à une autre et pour d’autres cas, l’implémentation DMZ afin d’exposer certains services au réseau public. Format des serveur (P ou V), consistance, compatibilité, caractéristiques (CPU+RAM) sont les élément à prendre en considération pour calculer la capacité de compute dont on a besoin. L’équation est simple, il suffit de calculer l’overcommitment (ratio vCPU au CPU, mémoire partagé), les service (nombres, taille), disponibilité (tolérance au pannes, maintenance), l’isolation (DMZ), les contraintes organisationnelles (préférence pour certains fabricants, prix). Les besoins changent et ne cessent d’augmenter. Il est donc important de disposer d’une infrastructure dynamique qui a la capacité d’expansion à la demande. On la possibilité de scaler une infrastructure en augmentant les ressources des serveurs (CPU, RAM, Stockage) ou en y ajoutant des nœuds au fur et à mesure de la demande. Des standards et documentation doivent être mis en place afin de décrire le processus d’expansion. Il existe plusieurs Hyperviseur sur le marché (VMware ESXi, KVM, Hyper-V, Suse, Redhat ) qui permet l’abstraction hardware (CPU, RAM) des serveurs. L’hyperviseur n’est un pas prérequis pour la mise en place d’une infrastructure cloud mais permet de fournir une meilleur efficacité de partage de ressource, rapidité d’expansion et le contrôle des coûts. Le choix de l’hyperviseur repose sur la compatibilité du CMP et des serveurs physique, des fonctionnalités que peut nous offrir, des licences et de l’expertise de l’organisation. L’implémentation de multiples hyperviseurs peut représenter certains inconvénient tel que le management, flexibilité, PRA, coût et compatibilité. Cela concerne également les conteneurs. Le choix du système d’exploitation dépendra de la compatibilité de l’hyperviseur, du serveur physique et de la solution de conteneurisation à adopter qui supportera les conteneurs. Il est possible de mettre en place un seul ou plusieurs clusters pour tirer certains avantages tel que les fonctionnalités VMware (HA, DRS, …). Ce qui n’est pas forcément le cas du cloud public d’où la disponibilité est configurée au niveau de la couche applicatif: d’où le choix d’un cluster unique. Il existe plusieurs types de disponibilités tel que la disponibilité d’hyperviseur (redémarrage des VMs, déploiement simple), SE (mise en place complexe, limitation de cluster, configuration du failback) et applicatif (mise en place de load balacing). L’accès à l’infrastructure doit être étudier afin de définir les privilèges pour les admins (l’accès à l’interface de management: admin, stockage,…) et les utilisateurs qui consommeront les services offerts depuis le CMP tout en considérant les trust zones (utilisation du chiffrement). La mise en place d’une documentation afin de permettre la mise à jour des hyperviseurs et des SE (test, application, validation des MAJ, roollback en cas de problème). L’utilisation des outils de management des MAJ nous permets d’assurer la consistance des upgrades et nous alerter en cas de change.

Les prérequis en stockage se définissent comme suit: Capacité, performance, type (file, block, objet), disponibilité, scalabilité, sécurité, interopérabilité (avec l’hyperviseur), coût et intégrité des données. Les pools de stockage peuvent être constituer par différentes architectures physique (Stockage local, distribué ou centralisé). Tenir compte de l’approvisionnement: Thick pour les applications qui ne tolèrent aucune variation de performance et Thin pour une meilleur économie et optimisation du stockage. La classification du stockage en catégorie grâce au tiering selon les caractéristique de performance (high pour SSD par ex., moderate pour SAS ou slow pour NL-SAS). La méthode de tiering peut être manuelle (donner le contrôle au consommateur ou l’admin) ou automatique (selon les prérequis de l’organisation). Prendre en considération l’Intra-Array Tiering ou l’Inter-array tiering. Comme mentionné précédemment, il existe plusieurs types de stockage (file, block, objet), il est donc important de définir l’accès et la multi-tenancy pour chaque type de stockage et considérer des solutions de stockage multiprotocole, divisés en plusieurs domaines de pannes. Le SDS permet une gestion centralisé, abstraction du plan de contrôle et agile et une certaines flexibilité à travers des API. Prendre conscience de l’avantage que peuvent nous offrir les fonctionnalités tel que le snapshot, clone, réplication et le chiffrement.

Les prérequis en réseau se définissent comme suit: Connectivité, bande passante, latence, disponibilité (NIC teaming, connexion du nœuds vers multiples switchs, composants redondants) coût et sécurité. Il est essentiel de comprendre le type de réseau qui sera capable de supporter l’infrastructure Cloud. L’infrastructure réseau doit être modulaire afin d’être capable de s’étendre en fonction des ressources compute qui seront ajouter au fur et à mesure, avec la bande passante adéquat et la redondance des chemins et matérielles. L’environnement du Cloud ne cesse d’augmenter, l’automatisation des configuration et les services de déploiement réseau doivent être pris en considération afin de réduire les erreurs et assurer un déploiement rapide en fonction de la demande. Considérer des solutions tels que SDN (management centralisé, abstraction du plan de contrôle, agile, API) et NFV sont des éléments importants lors de la conception de l’infrastructure Cloud. Concernant le réseau physique, déterminer si les ports doivent être trunker ou s’il s’agit des ports d’accès, minimiser le STP (éviter la liaison des switchs d’accès entre eux) afin de minimiser la complexité, utilisation des switchs et des liens d’agrégation afin de favoriser la redondance et amélioration de la bande passante. La mise en place que ce soit de LB physique ou virtuelle pour une meilleur gestion de trafic (une IP public pour de multiples applications). Définir les pools de réseau avec des VLANs ou des technologies overlay afin de favoriser la communications entre les VMs, définir l’isolation via des firewalls et NAT. Comme le tiering pour le stockage, le QoS est mis en place afin déterminer les flux selon leur importance (stockage, management) et ainsi offrir les services selon leur importance (ex. la performance-TCP offload, Jumbo frames, SSL offload). Concernant la sécurité, elle se définit par l’isolation réseau, parefeu, chiffrement de trafic, l’accès VPN et IDS/IPS. Le réseau c’est aussi le réseau de stockage via des protocole tel que FC, FCoE, iSCSI (block), NFS et SMB (File) et HTTPS (objet). Il est important de comprendre l’impact des protocole de stockage sur la conception de l’infrastructure du Cloud (support de l’hôte et VM, isolation, chiffrement, performance).

L’élasticité d’une application représente un élément essentiel dans le cloud. Définir les ressources et les composants du CMP qui permettront de le réaliser est indispensable. L’élasticité d’une application peut être automatique (au moment où la consommation CPU monitorée atteint un certains seuil, déclenche une augmentation à l’aide des capacités d’orchestration ou depuis l’accès API par exemple) ou manuelle (à travers le service catalogue. Par exemple l’utilisateur augmente le nombre d’instance d’un serveur Web).

On l’a vu précédemment, monitorer une infrastructure jour un rôle crucial. Il permet de déterminer la disponibilité et la performance d’un service et de l’infrastructure, vérifier le respect des SLA, le capacity planning, problème de sécurité. Il est donc indispensable de monitorer les composants du Cloud management, les composants de l’infrastructure, le compute, stockage et réseau et la consommation de l’application et de les remonter à travers de mails ou SMS. Mettre en place des outils de moteur d’analyses afin d’éviter les fausses alertes. Le placement de l’outil de monitoring est aussi important. Il doit être localisé sur le l’infrastructure de gestion Cloud, accès à tout les composants, accès sécurisé et accès au système d’envoi de message. Il peut être offert en SaaS par des fabricants tiers. Prendre en compte le dimensionnement de l’outil de monitoring en se basant sur les activités et les volumes, suivre les recommandations du revendeur, définir les indicateurs, la rétention, et l’expansion à venir. On distingue deux types d’accès à l’outil de monitoring: le fournisseur (infrastructure) et le consommateur (services).

Mesurer et enregistrer l’usage des services et des ressources en utilisant des outils tel que chargeback afin d’afficher les informations sur les coûts de la consommation de service et de facturer le service consommé et showback afin d’afficher uniquement la consommation du service.

Vous l’avez remarqué, la conception d’une infrastructure Cloud est un travail colossale d’où plusieurs éléments doivent être pris en considération. Ceci demande beaucoup de connaissance et d’expérience sur tout les domaines de l’infrastructure (compute, réseaux, stockage,…). J’ai essayé, depuis cet article de définir les grandes lignes sur les éléments à prendre en considération pour concevoir une infrastructure Cloud (sans entrer dans le détail) en me basant sur mes connaissances et mon expérience. La conception d’un service Cloud est un autre sujet, que j’espère avoir le temps d’aborder.