WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Les réseaux SAN comme solution de stockage et de protection des données


par Marlise MBEGANG MIMBE
Ecole Supérieure Multinationale des Télécommunications - Licence Professionelle en Technologies de l'Information et de la Communication 2009
  

précédent sommaire suivant

IV-3 LES SERVEURS DE DOMAINE VIRTUELS

Avec cette solution, la virtualisation est confiée à un serveur de stockage. Généralement, le serveur de domaine s'intercale entre le SAN et les unités de stockage. Là, il gère les translations physique/logique pour les serveurs hôtes. Mais, il peut dans certains cas être intégré dans les commutateurs et les routeurs fibre channel. Le serveur de domaines/ virtualisation constitue le coeur du SAN : toutes les informations, quelque soit leur nature (données, commandes) transitent obligatoirement par ce serveur de virtualisation.

Cette solution a le mérite de simplifier l'administration du système. En effet, il n'a qu'un seul point d'entrée et ne nécessite pas l'implantation d'agent coté hôte puisque les signaux de données et de commandes transitent par le même chemin. Une telle architecture est dite symétrique.

En revanche, l'écoulement des flux de données devient alors critique. De même, l'efficacité des caches et des files d'attentes doit, être considérée comme un point clé de l'architecture. Comme pour les réseaux SAN in a BOX, cette solution peut avoir des difficultés pour répondre aux exigences de la haute disponibilité. Néanmoins, elle dispose d'un atout non négligeable : elle prend en charge d'anciennes technologies qui, sans elle, seraient restées en marge du SAN, obligeant ainsi les entreprises à réinvestir dans de nouveaux équipements pour la mise en place de leurs réseaux de stockage.

IV-4 LES METASERVEURS

Dans cette approche, la rupture avec les deux solutions précédentes est marquée. En effet, les chemins empruntés par les données et celui emprunté par les commandes sont différents : on parle alors d'architecture asymétrique.

Le méta-serveur de virtualisation est toujours connecté au réseau commuté FC, seulement, comme cette équipement ne constitue plus le point de passage obligé de tous les

flux, l'installation d'un méta-serveur nécessite en outre le déploiement d'agents sur les serveurs d'application. Ces agents sont installés afin de donner les informations indispensables aux serveurs d'applications, comme l'espace de stockage disponible par exemple. En revanche, les transferts s'effectuent directement entre les serveurs d'applications et les espaces de stockage.

Figure 18: Prototype d'un Méta-Serveur SAN

Les méta-serveurs peuvent aussi bien être implémentés sur des plateformes standards que sur des commutateurs et des routeurs. Cette architecture différente du modèle symétrique offre une manipulation de volumes virtuels très souple. Les problèmes de zoning sont généralement simplifiés. En effet, le serveur n'accède qu'au volume qui lui a été attribué par le méta serveur. Enfin les opérations de restauration sont plus simples puisque les serveurs d'applications gèrent leur volume de disque comme si la virtualisation n'était pas présente.

En revanche, l'installation d'agents coté serveur d'applications est une nécessité. Il faut disposer de tels composants sur chaque serveur d'application, quel qu'il soit.

L'éditeur ou le constructeur qui propose une telle solution doit obligatoirement tenir sa base à jour. De son coté le client se doit de suivre sa base d'agents parallèlement aux versions de serveurs d'application. Si telle n'est pas le cas, des décalages peuvent très vite survenir entre les deux solutions logicielles. De plus, cette mise à niveau peut, sur une longue période, se révéler coûteuse.

précédent sommaire suivant