Passer au contenu

3. Un audit applicatif et des architectes système

Le SAN n’est pas toujours la meilleure des solutions. La phase d’audit et d’analyse des besoins reste prépondérante avant de faire un choix.

La mise en place d’une solution de stockage en réseau constitue un projet à part entière. Avec ce type d’architecture, le stockage ne se résume plus à un ensemble d’éléments épars, disséminés dans l’entreprise. Donc, qui dit projet SAN dit audit, conception, appels d’offres, tests, paramétrage des configurations et optimisation des performances, comme pour n’importe quel autre projet. Et même s’il n’existe pas de méthode universelle de mise en place d’un SAN, certaines étapes s’imposent.
En premier lieu, même si cela peut paraître évident, il est essentiel de rappeler qu’un audit applicatif s’impose. En effet, le concept de SAN est souvent présenté, à tort, comme la solution idéale pour consolider ou mutualiser les données de l’entreprise. Or, les applications concernées au premier chef ne regardent qu’une partie des données de l’entreprise : celles exploitées dans un cadre applicatif bien précis (datawarehouse, back up de progiciel de gestion intégré, consolidation de données bureautiques, etc. ). Il faudra donc absolument établir une cartographie des applications concernées par le SAN, mais sans se contenter de les recenser. Il faudra identifier l’ensemble des données sur lesquelles l’implantation du SAN aura un impact. Pour un PGI, on tiendra compte de telle ou telle base de données, des éléments inhérents à tel ou tel module, du back up. Pour la bureautique, on regardera les serveurs web, les serveurs de groupware. Malheureusement, il n’existe aucune méthode miracle pour réaliser de telles mesures puisqu’elles dépendent de l’environnement concerné. Reste la solution de recourir à un consultant externe. Cela impliquera la perte de la maîtrise complète du projet.

Même non retenu, le SAN doit être intégré à la réflexion

L’audit permet aussi, tout simplement, de valider l’option SAN. Pour des parcs ne comportant que quelques serveurs NT manipulant entre 100 et 200 Go, par exemple, la mise en ?”uvre d’une telle solution ne se justifie pas vraiment. Mais, même si elle n’est pas retenue, il est conseillé d’en tenir compte dans un projet à plus long terme et de sélectionner des équipements susceptibles de rester compatibles avec les infrastructures futures : intégration de l’existant via des passerelles ou complète migration des données, moyens de ne pas arrêter la production lors de la phase de migration, commutation Fibre Channel immédiate ou réservation de cette technologie à une phase de développement ultérieure. . .
S’il impose un audit, le projet à part entière que représente le SAN implique également de choisir judicieusement l’équipe qui le mènera à bien. Et même si les objectifs initiaux restent modestes, il demeure risqué de laisser l’ingénierie SAN et son lot de concepts architecturaux d’avant-garde à la seule responsabilité d’exploitants systèmes. Ces derniers se situent davantage dans une logique d’administration au jour le jour que dans celle d’un projet d’infrastructure à moyen ou long terme. Une telle démarche relève de la compétence et de la disponibilité des architectes systèmes et réseaux.

🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.


Thierry Jacquot