hepiacloud : Architecture

Transcription

1 hepiacloud : Architecture Février 2015 Khaled Basbous, Nabil Abdennadher Ce document décrit l architecture matérielle de la plateforme hepiacloud. Il détaille aussi les différents logiciels utilisés pour la mise en place et le monitoring de hepiacloud. hepiacloud est un cloud privé académique basé sur la solution OpenStack. Cette infrastructure est utilisée par les étudiants et assistants de hepia et de la HES-SO pour des besoins de pédagogie et de recherche OpenStack OpenStack est une solution de cloud-computing qui permet de mettre en place une Infrastructure as a Service (IaaS). Son développement a débuté en juillet 2010 conjointement par Rackspace Hosting et la NASA. Cette solution cloud open source est délivrée sous une licence Apache 2.0. Elle est capable de gérer un grand nombre d hyperviseurs, de nœuds de stockage et de nœuds réseau. Les sorties de nouvelles versions sont synchronisées avec les sorties des distributions Ubuntu Versions d OpenStack et leurs composants Plusieurs versions de OpenStack ont vu le jour depuis sa première apparition. Le tableau 1 montre les différents services ajoutés au fur et à mesure de l apparition des versions de OpenStack : Nom version Date sortie Composants inclus Austin October 2010 Nova, Swift Bexar February 2011 Nova, Glance, Swift Cactus April 2011 Nova, Glance, Swift Diablo September 2011 Nova, Glance, Swift Essex April 2012 Nova, Glance, Swift,, Keystone Folsom September 2012 Nova, Glance, Swift,, Keystone, Quantum, Cinder Grizzly April 2013 Nova, Glance, Swift,, Keystone, Quantum, Cinder Havana October 2013 Nova, Glance, Swift,, Keystone, Neutron, Cinder, Heat, Ceilometer Icehouse October 2014 Security supported Juno Feb Les composants de Havana + Sahara Tableau 1 : Les versions de OpenStack 1 1 Release history - 1

2 Descriptif des principaux services d OpenStack 2 (Nova) : OpenStack (Nova) est le service qui permet de gérer les différents types d hyperviseurs de virtualisation. Ce support est rendu possible en grande partie grâce à l utilisation de la librairie libvirt. Cette librairie est capable de contrôler plusieurs types d hyperviseurs (KVM, Xen, Hyper-V etc.). Nova compute est installé sur les nœuds qui hébergent les instances. Nova-API permet de communiquer avec les services compute via des messages AMQP (Advanced Message Queuing Protocol) pour demander, par exemple, la création d instances. Dashboard () : OpenStack Dashboard () est une interface web qui permet aux administrateurs et aux utilisateurs de gérer et interagir avec les instances et les ressources du cloud. Ce dashboard est extensible : il est conçu pour pouvoir intégrer des services tiers comme la facturation, le monitoring etc. Image Service (Glance) : OpenStack Image Service (Glance) permet de faire des images disque et de les utiliser comme des templates. Glance API est une interface REST qui permet de demander des informations sur les images disques et de créer des nouvelles. Identity Service (Keystone) : OpenStack Identity (Keystone) gère la création et l accès «utilisateurs» aux services d OpenStack. Il supporte plusieurs types d authentification comme le nom d utilisateur avec mot de passe, les systèmes basés sur des jetons ou encore l authentification à la façon des services web d Amazon. Une API proposé par OpenStack permet se solliciter les services du système Keystone. Networking (Neutron) : OpenStack Networking (Neutron ou Quantum) est un service qui fournit la fonctionnalité de «security group», gère les réseaux (VLAN, réseaux plats, SDN), les adresses IP fournies aux instances, la déviation de trafic pour les tâches de maintenance. Neutron est conçu pour pouvoir accueillir des extensions qui pourraient gérer, par exemple, un système de détection d intrusions (IDS), un système de répartition de charges, un système qui met en place des VPN. OpenStack Block Storage (Cinder) : OpenStack Block Storage (Cinder) permet de fournir des disques virtuels persistants qui peuvent êtres attachés plus tard à des instances (VMs). Cinder-API permet de faire des opérations de gestion CRUD (Create, Read, Update, Delete) sur les disques virtuels sans avoir à connaître le type et/ou l emplacement des disques. OpenStack Object Storage (Swift) : OpenStack Object Store (Swift) permet de stocker et d extraire des objets (fichiers) non structurés via un API simple utilisé au niveau du code applicatif. Cette architecture gère les données comme si elles étaient des objets. L utilisateur n a plus qu à demander à stocker, supprimer, etc. un fichier (objet) via des appels à l API. Cette méthode d utilisation libère l utilisateur des tâches de gestion de l espace de stockage. En effet, contrairement à un disque standard, il n a plus besoin de le formater, de lui fixer un point de montage dans l instance et de s occuper de la réplication de ces données par exemple hepiacloud hepiacloud utilise la plateforme OpenStack pour fournir un service IaaS. Elle a été migrée vers la version Havana d OpenStack en D autres composants et services ont été ajoutées pour garantir la disponibilité et le monitoring des ressources de hepiacloud. 2 Components - 2

3 Il est prévu de migrer à la version Juno en Avril Infrastructure et réseau à disposition La plateforme hepiacloud est installée dans les locaux de hepia situés à la rue Prairie 4, 1202 Genève. Deux matériels différents sont utilisés : PCs HP de type desktop et serveurs en rack. Les nœuds utilisent la distribution Ubuntu LTS (Long Term Support) de Linux Debian. À l heure d écriture de ces lignes (Février 2015), les racks sont placés au centre de calcul dans le bâtiment B, alors que les PCs sont dans les salles A402 et A425 du bâtiment A. Dans chaque salle du bâtiment A, il y a une machine Gateway et une machine OpenStack Controller. Comme indiqué dans la figure 1, l accès à hepiacloud se fait uniquement à travers l un des deux Gateways. Chaque Gateway dispose de deux cartes réseau, une reliée au réseau public ( /22) et l autre reliée au réseau privé ( /21). Il y a 42 nœuds. Le réseau privé dessiné en vert fournit les IP privées aux VMs (instances). Les services d OpenStack sont installés sur les deux contrôleurs (Controllers dans la figure 1). Gateway 1 Controller 1 18 x x A401 Internet / / x apache lsds- rg.org Centre de Calcul A425 Gateway 2 Controller 2 18 x UniGE HEPIA Figure 1 : Topologie réseau de hepiacloud hepiacloud peut-être accédée par l intermédiaire de l interface Web, via l utilisation des API OpenStack ou encore par l API d Amazon EC2. Les services d administration, représentés en rouge et en jaune dans la figure 2, sont tous installés sur les nœuds Controller, à l exception du service nova compute et nova network. A ce jour (Février 2015), hepiacloud ne supporte pas la totalité des services OpenStack. A titre d exemple, le service Cinder n est pas installé. Dans la figure 2, les services de monitoring sont représentés avec une couleur verte, les services de haute disponibilité et équilibrage de charge sont représentés avec une couleur bleue, en noir le service de filtrage réseau et en violet le service de stockage répliqué pour les images utilisées durant la création d instances. Ces 3

4 services qui ne sont pas offerts par OpenStack, permettent d optimiser la fiabilité et la disponibilité de hepiacloud. Seul les services en rouge appartiennent à OpenStack. GlusterFS HAproxy Galera MySQL Keystone Nova Cert Glance API Keepalive RabbitMQ Nova Consoleauth Nova Conductor Nova Scheduler Graphsky Stack graphite Graylog2 server Nova network Nova compute special (LSDServer1) Nova API Glance Registry Iptable NoVNCProxy Nova network Nova compute Gateway Controller Figure 2 : Services installés sur les nœuds de hepiacloud Figure 3 : Dashboard OpenStack Hyperviseurs disponibles La redondance des gateways et des controllers permet de garantir une certaine disponibilité. A un instant donnée, une gateway (resp. controller) joue le rôle de gateway (resp. controller) primaire. L autre machine reste en stand by au cas où la machine primaire tombe en panne. Le tableau 2 précise les adresses des nœuds. Les Gateways et les Controllers possèdent des Virtual IP (VIP), essentielles pour basculer de la machine primaire à la machine secondaire en cas de panne. À un instant donné, un seul Gateway (resp. Controller) possède la VIP publique et la VIP privée (resp ). Les requêtes envoyées vers cette adresse sont récupérées par la Gateway primaire qui possède cette VIP. On peut donc considérer les deux machines Gateway comme une seule machine qui écoute l IP (interface WAN) et l IP (interface LAN). Le même raisonnement est valable pour les deux Controllers. 4

5 Type de nœud Gateway 1 Gateway 2 Controller 1 Controller 2 Hosts A425 Hosts A401 Hosts BXXX Salle serveur Switch NetGear A401 Nom d hôte A A A A A425-03! A A401-23! A IP publique WAN IP privée LAN VIP publique WAN VIP privée LAN LSDServer Tableau 2 : Adressage des nœuds infrastructure Gateway - Fonction de pare-feu et de routage Comme précisé auparavant, le trafic provenant depuis internet est acheminé par les Gateway vers les Controllers ou vers le nœud LSDServer1. Ce dernier remplit la fonction de «serveur de monitoring». La redirection du trafic est réalisée par le service iptables de linux. La figure 4 montre un résumé des règles de redirection installées sur les Gateway. Par exemple, lorsque l utilisateur envoie une requête vers l IP virtuelle publique de la Gateway ( ), iptables intercepte le paquet et analyse le port de destination du paquet. Selon, ce numéro de port et les règles iptables fixées, le gateway transfère le paquet au nœud qui héberge le service concerné en modifiant l IP destination du packet (DNAT). Par exemple, lorsqu un utilisateur désire accéder au Dashboard d OpenStack de hepiacloud, la résolution DNS de le dirigera vers l IP de la Gateway Comme l utilisateur envoie une requête HTTP (destination port = 80) vers le Gateway depuis Internet, iptables retransmet la requête vers le nœud Controller qui héberge l application web. 5

6 l 6080 NoVNCProxy DNAT l 6080 NoVNCProxy l 8773 EC2 API l 8773 EC2 API l 9292 Glance API l 9292 Glance API l 8774 API l 8774 API Internet l 5000 l 80 l l 22 Keystone VMs-SSH SSH l 5000 l 80 Port Controller Keystone l 9000 Graylog2 Port SNAT Gateway l 22 VMs subnet l 9000 Graylog2 UNIGE NET / 22 Port LSDServer1 Figure 4 : Redirection réalisée par l iptables installé sur les Gateway PRIVATE NETWORK /21 Une règle de routage a été réalisée pour permettre aux utilisateurs de se connecter en SSH aux VMs du cloud depuis internet. Les VMs ont des IP privées dans la plage xxx. Par exemple, pour se connecter en SSH sur une VM avec comme IP , il faut utiliser comme IP destination celle de la Gateway et comme port de destination le port La Gateway détermine ainsi qu elle doit rediriger les paquets SSH vers une VM dans la plage d adresse xxx car le port vaut 10xxx et vers la machine car xxx vaut 100. Pour se connecter sur une VM dans la plage IP xxx il faut lancer la connexion vers le port 20xxx. Les instances de hepiacloud ont accès à Internet car ils ont comme default gateway l IP Celle-ci réalise du source NAT pour pouvoir acheminer les réponses aux paquets envoyés Haute disponibilité et équilibrage de charges Un des moyens efficaces pour garantir la haute disponibilité est de procéder à une redondance des ressources. Deux nœuds Gateway et deux nœuds Controller sont utilisés à cet effet. En cas de panne logicielle ou matérielle de l un des nœuds, l autre nœud peut prendre la relève. Cette fonctionnalité est garantie par le logiciel Keepalive. Keepalive est un logiciel qui gère l attribution d une IP virtuelle (VIP) à un ensemble de nœuds. Ce logiciel est composé de deux modules. Le premier module teste la disponibilité d un nœud et de ces services. Le second, appelé failover, permet d'assurer la migration de l IP vers le second nœud. Avec keepalive, il est possible de réaliser de la haute disponibilité active/passive : un des nœuds Gateway est primaire (possède la VIP) alors que l autre reste en stand-by (secondaire) au cas où le nœud primaire ne peut plus assurer ces fonctions. Dans la figure 5, chacun des nœuds Controller et Gateway possède un Keepalive qui gère les VIP. Les VIP sont représentés à mi-chemin entre deux interfaces réseau pour montrer qu elles sont attribuées à l une des deux interfaces. 6

7 HAProxy Nova API Gateway Controller 1... VRRP VIP VRRP VIP VRRP VIP HAProxy Nova API Gateway Controller 2... Figure 5 : Haute disponibilité des nœuds Controller et Gateway et répartition de charges sur les API OpenStack Un second logiciel est installé sur les controllers : HAProxy. Ce dernier gère l équilibrage de charges http. Ce logiciel est capable de transmettre les requêtes http vers des serveurs Web, selon une logique de répartition. Les services OpenStack déployés (API) sont de type REST/http, stateless. Ceci signifie que les requêtes des clients peuvent être traitées indifféremment par l un des nœuds Controller. HAProxy est donc utilisé pour renvoyer les requêtes des clients vers les services API de l un des Controllers selon leur charge. A titre d exemple, lorsque la machine Gateway primaire transmet la requête du HTTP du client vers le port 80 du Contrôller primaire, son HAProxy intercepte la requête et décide de l envoyer vers le service de l un des Controllers :1 ou 2 (flèches oranges dans la figure 5). Dans notre cas, la répartition se fait selon une répartition round-robin. Les types de répartition réalisés pour les services installés sur les Controller sont détaillés au tableau 3. Le controller primaire est responsable de redistribuer les requêtes à l aide de son HAProxy. Le HAProxy du controller secondaire reste en stand-by. Dans le cas où le HAProxy du contrôleur Maître tombe en panne, le module test de Keepalive détecte la panne et va donc demander de transférer la VIP au contrôleur secondaire qui deviendra le nouveau contrôleur primaire. 7