Intelligence de placement (sécurisé)

Un des points importants dans la mise en œuvre d'une solution d'infrastructure de services à la demande (IaaS), c'est bien évidemment l'optimisation des ressources côté fournisseur et la puissance à la demande sécurisée côté client. Les 2 besoins ne peuvent être antagonistes. A vrai dire, le client doit pouvoir exprimer son niveau de service désiré d'un point de vue sureté (performance, disponibilité, choix de éléments de calcul, de stockage et de réseau, etc.) et sécurité (authentification forte, chiffrement des flux et des données, réseaux dédiés, etc.). Bien évidemment, il paiera en fonction du niveau de son exigence et obtiendra des dommages, si son niveau de services (SLA) n'est pas respecté dans la durée de son contrat. Du côté de l'opérateur, les ressources doivent être utilisées de façon optimum pour être bien évidement le plus rentable possible (business oblige!).

C'est à partir de ces 2 conditions que la logique de placement et d'optimisation rentre en ligne de compte. Les versions de Nova actuelles n'offrent pas de fonction intelligente pour traiter ce type de besoin. Ceci étant, l'architecture logicielle est ouverte afin que ceux qui le désirent réalise le code adéquat (non ou peu intrusif, vis-à-vis du reste de la distribution logicielle). Jusqu'à la release Cactus, il y avait 3 options (configurable via "nova.conf") pour sélectionner le mode de placement retenu. Elles sont les suivantes :

• mode simple: tentative pour trouver le host, le moins chargé,
• mode chance: choix aléatoire parmi les hosts disponibles. C'est la configuration par défaut,
• mode zone: sélection d'un host (à priori, le moins chargé, dans une zone disponible).

Bref, on s'aperçoit que cela est très restrictif. A vrai dire, cela n'était pas trop contraignant pour les premières releases de Nova qui ont permis de consolider la solution (ex: authentification, réseau, etc.), mais cela devient critique pour envisager, un minimum de solution opérationnelle. Une des évolutions de la release Diablo vis-à-vis de l'ordonnanceur (scheduler en anglais) est la mise en forme du code pour pouvoir intégrer, à sa guise, son propre algorithme de placement. De plus, une autre évolution toujours liée à Diablo est l'enrichissement d'un ordonnanceur distribué. Ceci est quasiment incontournable, dans un contexte multi-zones. Chaque ordonnanceur de zone aura sa propre persistance de données synchronisée avec la base centralisée de l'ordonnanceur maître, pour donner les informations nécessaires aux algos de placement.

J'imagine pour des releases à venir, les fonctionnalités offertes au client pour qu'il affine ou impose ses propres critères de placement (affinité, localisation, puissance de calcul sur une ou des période(s) déterminée(s), élasticité, etc.) liés à la sureté et à la sécurité. Reste à trouver, les puissants algorithmes orientés système expert qui vont prendre en compte ces exigences, tout en y associant d'autres critères liés à l'optimisation des ressources pour l'opérateur de services. Une fois, le calcul effectué donnant le placement adéquat, il faut pouvoir le mettre en œuvre. Pour cela, les mécanismes de live migration (à chaud, bien évidemment) rentrent en jeu pour les machines virtuelles (VM), voire aussi ceux relatifs aux espaces de données, ainsi que l'adaptation dynamique des configurations réseaux.

Je ne sais pas, si la couverture de ce type de besoin sera évoquée, voire traitée lors des prochains Design Summit d'Openstack, ou cela restera à la totale liberté (éléments différenciateurs) des entreprises qui implémenteront Nova.

A suivre.