Guides Essentiels
Voir tous les articles de ce guide
Conseil
Cet article fait partie de notre guide: Bien comprendre les Infrastructures Programmables et le Software Defined Datacenter

Que faut-il prendre en compte dans une migration vers un datacenter programmable

Déployer un datacenter programmable (Software-Defined Datacenter) à votre équipement en place peut être risqué et nécessite une étude précise du projet. Voici quelques méthodes à prendre à compte pour y parvenir.

Russ White
par
Publié le: 09 mars 2017

Vous avez enfin pris la décision de vous orienter vers un datacenter programmable et d’amorcer ainsi une transition vers le SDDC (Software-Defined Datacenter).  Toutefois, ce n’est que le point de départ : tirer un trait sur votre équipement en place peut s’avérer à ce stade très frustrant. Que faire avec vos installations en place et que faire des applications ? La réponse n’est évidemment pas si simple. Et comme souvent dans l’IT, elle se résume à un : « ça dépend ».

Il existe en fait deux modèles de transition : faire fonctionner les deux datacenters - le nouveau et l’ancien - en parallèle durant la phase de transition, ou intégrer votre équipement en place à votre nouveau SDDC. Cette seconde approche correspond en fait à deux types de réponses possibles : intégrer un niveau de Pods ou faire tourner le SDDC au-dessus de l’existant.

La première solution, qui consiste à exécuter de concert les deux datacenters, peut sembler plus simple. Mais cela pose toutefois quelques problèmes : celle de la migration des workloads entre les deux datacenters. Comment mettre cela en place ? Une grande partie de la réponse se trouve dans les applications, évidemment. A ce stade, plusieurs interrogations se posent :

Dans quelle mesure la nouvelle fabric répond aux besoins de chacune des applications ? Il est primordial de prendre en considération les points les plus connus, comme l’utilisation de la bande passante ou la latence, par exemple. Mais il est également important de prendre en compte certains services, comme le domain name system, la gestion dynamique des flux massifs (Que l’on appelle « Elephant flows »), la création de zones de sécurité, les overlays réseau et bien d’autres facteurs.

Même si une grande partie de ces problèmes peut être évitée au stade de la conception même, difficile de tous les éviter. Car au final, les équipes en charge de l’exploitation ne connaissent que rarement la nature des services utilisés par les applications.  Cela risque donc de ne reposer que sur des suppositions - non fondées, donc- si l’on dresse un éventuel inventaire. Dans ce cas, il est nécessaire de mettre en place un plan d’action de migration dès le jour 1.

Il est certes facile de penser que tous les services peuvent être apportés par la nouvelle fabric. Mais avec cette approche, on obtient généralement de très mauvais résultats. Il est préférable de prendre en considération dès le départ le fait que le propriétaire de l’application puisse à un moment donné modifier ou mettre à jour son application.  Il serait contre-productif d’en rejeter l’entière responsabilité sur l’équipe d’ingénieurs réseau.

Les applications déterminent les liens entre datacenters

data center migration
Using the pod level to mesh legacy and SDDC equipment

Quand les deux datacenters ont exécutés en parallèle, la connectivité entre les deux – une DCI (Datacenter interconnect) est primordiale. Les contraintes de chaque application déterminent justement la nature de cette interconnexion, s’il faut une connexion Ethernet-on-top ou une connexion IP plus simple à maintenir, par exemple. Comme finalement toutes les décisions que l’on a à prendre en matière d’interconnexions.

La seconde solution, celle portant sur l’intégration d’un niveau de pods, présente d’autres difficultés. Le principe est illustré ci-dessous :

S’il n’est pas nécessaire d’interconnecter les fabrics – ce qui est peu probable dans la plupart des réseaux modernes -, on peut ôter un problème majeur de la liste : le DCI. L’autre avantage est que cela permet d’avoir recours à de la simulation pour tester le modèle de conception de votre SDDC sur chaque application, et ce, sur la durée. Dans ce cas, cela implique d’exécuter les deux infrastructures en parallèle, de déplacer les applications du Legacy vers le SDDC pour les évaluer et de les y laisser si elles fonctionnent correctement dans leur nouvel environnement. C’est en fait ce que font les opérateurs d’infrastructures.

Toutefois, cela complique quelque peu le procédé : comment le               plan de contrôle du SDDC fonctionne avec celui déjà en place ? Le trafic doit en effet être tiré du nouvel SDDC vers l’équipement en place, et vice-versa. Si peu de politiques de sécurité ou de gestion de trafic sont déjà en place, cela peut être aussi simple que de redistribuer les informations de routage vers les deux consoles. Si en revanche, cela implique la mise en place de zones de sécurité entre les deux domaines, cela peut être plus compliqué. La solution la plus probable est alors de combiner la redistribution avec un tuning manuel ou automatique entre les deux zones.

Cela permet de démarrer simplement, mais se compliquer avec le temps et consommer plus de ressources que prévu. Si c’est ce chemin de migration qui est choisi, il est préférable de pousser les applications d’un environnement vers l’autre, sous la forme d’un groupe. Cette méthode réduit la surface d’interaction entre les deux environnements.

Faire tourner le SDDC comme un overlay

La dernière option est d’exécuter le SDDC comme un overlay au-dessus de l’équipement en place. C’est certainement la solution la plus mise en avant par les fournisseurs de SDDC. Cela peut sembler être la solution la plus simple, mais peut très vite s’avérer être aussi la plus complexe.

data center move
Using an overlay can be a good option, but network operators must ensure compatibility

L’idée de base est d’utiliser la puissance du SDDC pour remplacer l’équipement Legacy avec le nouvel équipement, mais en exploitant l’infrastructure en place pour servir de couche physique au SDDC. Sur la durée, cela ne devrait pas être différent qu’un cycle de vie normal. Ainsi, les mêmes outils et processus sont applicables dès le premier jour et jusqu’à ce que l’équipement legacy soit finalement plus en service. Reste toutefois un problème : l’équipement en place ne sera jamais aussi performant que le dernier modèle de SDDC.

Sur la couche physique, par exemple, l’équipement va-t-il supporter les interfaces southbound indispensables au SDDC ? Si le SDDC nécessite le support l’Openflow (à un certain niveau) pour opérer convenablement, l’équipement Legacy est-il capable de supporter ce niveau d’opération ? Si ce support est revendiqué par le fournisseur, a-t-il été testé ? Pour en être sûr, tous les équipements en place doivent subir de nouvelles validations dans le nouvel environnement.

Au niveau du plan de contrôle, comment le SDDC en overlay interagit avec ceux déjà en place ? Tous les plans de routage existants peuvent-ils être intégrés dans le SDDC ?

L’administration ajoute de la complexité

Et le problème s’accentue avec l’administration. Chaque point du réseau est conçu pour être géré spécifiquement. Certains peuvent donc disposer d’interfaces types, d’autres seulement proposer des CLI ; d’autres encore des interfaces RESTFul. D’autres peuvent être encore administrés par une interface gRPC.

Le SDDC peut-il récupérer l’information, ou pousser une configuration, vers l’ensemble de ces interfaces ? Quelles métriques perdrez-vous en chemin ? Cela nécessite des tests intensifs.

L’autre problème porte sur la capacité à résoudre rapidement des incidents. La télémétrie vous permet d’observer les conditions du réseau, et de résoudre les problèmes avant que cela n’affecte les opérations. Il est primordial d’examiner les processus en place pour restaurer rapidement les services et de comparer cela avec les capacités du SDDC pour déterminer s’il y a une différence.

Mais au final, la partie du Legacy qui sera la plus difficile à gérer dans une transition vers le SDDC est le firewall. Mettre en overlay un SDDC au-dessus d’un équipement en place constitue un vrai problème pour lui, en termes de tunneling ou de politiques dynamiques, par exemple. Dans un modèle bâti sur les overlays, la sécurité doit être repensée entièrement (les zones de sécurité doivent être migrées de l’appliance vers le SDDC).

Cette transition vers le SDDC peut conduire à un réseau plus optimisé sur la durée, avec d’autres options pour bâtir et maintenir un réseau adapté aux besoins métier. L’étape intermédiaire peut toutefois être compliquée. Cela implique d’être prudent et minutieux.

 

Pour approfondir sur Administration et supervision du Cloud