Souvenirs…Souvenirs…
Lors de mon précédent article sur le déménagement d’un datacenter, je vous avais présenté les enjeux d’un tel projet, la bonne démarche à adopter et les grandes stratégies de déménagement.
Voyons maintenant les éléments essentiels à la planification d’un déménagement.
Et zou ! En un week-end tout est bouclé ! …bah NON !
Lorsqu’on évoque le déménagement de l’infrastructure du SI, tout le monde a en tête le déplacement d’un point A vers un point B et nous avons tous entendu, au moins une fois en réunion préparatoire, une personne affirmer :
« C’est plutôt simple ! On coupe tout un week-end, on charge un camion, on réinstalle le tout, on redémarre et le tour est joué ».
Dans cette situation mon cœur se met à saigner et je me dis intérieurement qu’il y a (beaucoup !) de pain sur la planche.
Attention ! Danger !
En effet déménager toutes les infrastructures en une fois, c’est faire porter un risque élevé sur l’ensemble de son système d’information (SI) en cas d’incident lors de l’opération.
Aucun client n’aimerait apprendre le lundi matin que son SI est indisponible à la suite d’un accident du camion transportant ses infrastructures. De plus le temps d’interruption des services sera en grande partie proportionnel au nombre de composants à déménager et il risque fortement de ne pas être en phase avec le RTO souhaité par le métier.
Enfin certain les services d’infrastructure sont particulièrement complexes à déplacer. Par exemple, on ne déménage pas un bus applicatif ou une baie de stockage partagée (NAS ou SAN) comme des serveurs physiques ou virtuels.
Il est souvent préférable de lotir dans le temps le déménagement plutôt que de planifier tout le périmètre en une seule fois !
Il ne s’agit pas uniquement de boîtes et de câbles …
Quel que soit le type de point B (hébergement sec, cloud privé ou cloud public), il ne faut jamais oublier que ces infrastructures hébergent avant tout des applications et implicitement des services métiers.
Par conséquent, la planification du déménagement doit s’étudier selon deux axes :
Axe infrastructure
- Quelle méthode de déménagement appliquer pour chaque brique d’infrastructure ? (Réseau, stockage, serveurs physiques et virtuels, bases de données, serveur d’applications, serveurs Web, …)
Axe applicatif
- Quelles sont les contraintes métiers ? Disponibilité, performance, sécurisation, activités saisonnières, flux inter-applications, …
De nos jours les systèmes étant de plus en plus complexes, l’infrastructure ne peut pas être déménagée sans prendre en compte la couche applicative et inversement.
Mais au fait que doit-on déménager ?
Les éléments indispensables pour connaitre (et comprendre) le périmètre infrastructure et applicatif à déménager sont les référentiels (inventaire physique, inventaire applicatif, cartographie des flux, …).
Ils sont malheureusement très souvent négligés et pourtant absolument nécessaires pour réussir le déménagement
Prenons par exemple la vue physique de notre SI. Elle se compose généralement de châssis, de serveurs, d’équipements réseau, d’équipements de sécurité, de baies de stockage, de robotique de sauvegarde, …
Tout ceci est référencé généralement dans un inventaire porté au mieux dans un logiciel adapté de type DCIM, plus fréquemment simplement au format Excel.
Et dans le pire des cas l’inventaire n’existe pas ! Et cette situation est malheureusement relativement fréquente.
Un inventaire à jour c’est tellement mieux….
Dans ce dernier cas il faudra prévoir avec le client un référencement manuel complet de ses infrastructures (qui n’a jamais rêvé de passer plusieurs heures dans une salle serveur bercée par le ronronnement des ventilateurs et hyper climatisée à souhait !).
Dans le cas d’un inventaire existant, il faudra vérifier que celui-ci est à jour afin de connaitre très exactement ce qui est réellement hébergé, et où.
Il doit nous permettre également de déterminer l’obsolescence des composants et de réfléchir avec le client à la gestion de cette obsolescence. Plus le matériel est âgé plus le risque de dysfonctionnement après un déplacement augmente et la possibilité de pouvoir être réparé diminue.
Comme évoqué dans mon premier article, un déménagement est une excellente occasion pour le client de rénover son parc et de réfléchir à la stratégie de son SI.
Il n’est certainement pas nécessaire de tout déménager
Une fois que l’on dispose d’une vision exhaustive de l’infrastructure et du devenir des éléments obsolètes, il nous reste à déterminer ce que l’on déménage ou pas. L’inventaire est à jour mais doit-on déménager pour autant tous les équipements hors tension ?
Il est très fréquent qu’à la suite d’un projet le décommissionnement des infrastructures s’arrête à la mise hors tension de ceux-ci. Mais malheureusement il est encore plus fréquent que le décommissionnement reste une étape inachevée du projet.
Il faut donc passer en revue l’ensemble des infrastructures avec les équipes concernées pour déterminer leur réelle utilité.
Il est conseillé dans ces conditions d’ajouter un champ dans l’inventaire physique indiquant la destinée de chaque équipement et de mettre hors tension l’ensemble du matériel non utilisé pour des raisons économiques (un équipement éteint ne consomme pas d’énergie) mais aussi de planification de déménagement (si un tel équipement doit malgré tout être déplacé, il sera facilement identifié et utilisé pour compléter des vagues de migrations).
Au tour des applications
Maintenant intéressons-nous à la couche applicative en s’appuyant sur l’inventaire applicatif.
A l’instar de l’inventaire physique celui-ci n’existe pas toujours et devra, le cas échéant, faire l’objet d’un projet de référencement auprès des équipes métiers.
Comme pour la partie physique, cet inventaire devra nous permettre d’identifier le périmètre applicatif à migrer mais aussi de faire le lien avec la couche infrastructure.
Je ne pense pas enfoncer des portes ouvertes en vous disant que chaque application consomme différents services d’infrastructure.
L’analyse de cet inventaire applicatif va nous permettre de faire le lien entre la couche physique et la couche logique et ainsi de disposer d’une cartographie de votre SI avec une vision « bottom-up » ou « top-down ».
Inventaire physique [check]…inventaire applicatif [check] …. Au tour des flux inter-applicatifs !
A ce stade de notre étude nous disposons d’une vision plus complète du SI afin de planifier correctement notre déménagement.
Mais il manque encore des informations essentielles. En effet j’évoquais plus haut la complexité des SI actuels. Celle-ci se constate également sur les flux inter-applicatif de plus en plus nombreux et critiques, pour répondre à la demande toujours plus forte de continuité de service.
Les flux inter-applicatifs sont normalement identifiés dans un outil de cartographie mais trop souvent référencés uniquement dans les dossiers d’architecture technique de chaque application (rarement à jour) ou dans la tête des référents métier.
Une nouvelle fois, il faudra mener une étude auprès des sachants pour obtenir l’ensemble des flux, leur typologie, leur fréquence, leur niveau de criticité…
La connaissance des flux inter-applicatifs va nous permettre de planifier au mieux le déplacement d’une application ou d’un domaine applicatif cohérent tout en respectant les niveaux de service et simplifier le déménagement.
Et tout ceci dans le respect des niveaux de services !
De même la connaissance des niveaux de continuité de services et des plages de services nous permettra de positionner les phases de déménagement dans les conditions optimales (éviter par exemple de déménager le système de gestion de la paie en début ou fin de mois).
In fine nous devrions avoir suffisamment d’informations pour savoir que l’application A communique avec les applications B et C et s’appuie sur les composants d’infrastructure X, Y et Z.
Cette vision exhaustive de l’écosystème nous permettra de savoir si on peut déplacer une application seule ou obligatoirement avec d’autres applications satellites, identifier les flux à ouvrir ou à router pour maintenir l’activité et les plages de service au cours desquelles on pourra réaliser ces migrations.
Au final, un peu de flexibilité sera la bienvenue.
Attention à ne pas être jusqu’au-boutiste sur la complétude des référentiels cités plutôt dans cet article.
On souhaite bien évidemment disposer d’une vision suffisamment complète du SI pour minimiser les risques mais il ne faut pas non plus bloquer le déménagement pour cause d’inventaires non disponibles ou incomplets.
Il faudra alors partager les risques encourus et trouver des solutions pour les minimiser. Les délais de déménagement sont généralement suffisamment tendus. Il est bienvenu de ne pas perdre de temps inutilement sur des sujets que l’on sait être perdus d’avance.
Et maintenant, quelle est la suite ?
Désormais il nous reste à identifier la stratégie de migration du SI (« one shot », par vague,) et les moyens techniques à utiliser pour déménager les grands services d’infrastructures (stockage, hyperviseur, réseau, sauvegarde, systèmes d’échanges, …) mais ceci sera l’objet du prochain article.
Alors à très bientôt !
