Prise en charge du démarrage à partir d'un SAN (Storage Area Network)

Traductions disponibles Traductions disponibles
Numéro d'article: 305547 - Voir les produits auxquels s'applique cet article
Agrandir tout | Réduire tout

Sommaire

Résumé

Cet article décrit les conditions de prise en charge du démarrage d'un serveur Windows à partir d'un SAN (Storage Area Network).

Plus d'informations

Microsoft prend en charge le démarrage à partir d'un SAN si le vendeur du SAN prend en charge le démarrage d'un serveur Windows à partir de sa plate-forme matérielle spécifique. Le SAN et la carte de bus hôte (HBA) doivent être configurés selon les instructions du vendeur du SAN et ce dernier doit être le principal point de contact pour les problèmes liés au démarrage. Ceci est nécessaire car le démarrage à partir d'un SAN est extrêmement complexe ; le vendeur du SAN doit prendre en charge cette configuration spécifique car c'est lui qui fournit la déclaration de prise en charge du démarrage à partir du SAN. Il est important de noter que les informations présentées dans cet article n'ont pas pour objectif de constituer une liste exhaustive des éléments nécessaires au démarrage à partir d'un SAN. Le vendeur du SAN doit fournir les procédures spécifiques, les pilotes, les mises à jour du microprocesseur et les ressources concernant la configuration correcte de l'ensemble de son matériel (systèmes de stockage, commutateurs, cartes de bus hôtes etc.).

Configuration

Les problèmes suivants doivent être résolus avant que plusieurs ordinateurs puissent démarrer à partir d'un SAN :
  • Le SAN doit être soit configuré dans un environnement commuté, soit directement connecté à partir de chaque hôte à l'un des ports Fibre Channel du sous-système de stockage. L'utilisation de Fibre Channel à boucle arbitrée (FC-AL) n'est pas prise en charge car elle ne permet pas de séparer correctement l'un de l'autre les hôtes connectés au SAN. Un environnement commuté permet aux hôtes d'être séparés l'un de l'autre.

  • L'hôte doit disposer d'un accès exclusif au disque à partir duquel il démarre. Aucun autre hôte du SAN ne doit être en mesure de détecter ou d'avoir accès à ce disque logique. Ceci peut être accompli à l'aide d'une méthode de gestion de numéro d'unité logique (LUN) telle que la segmentation ou le masquage du numéro LUN ou une combinaison de ces méthodes. La gestion de numéro LUN est normalement configurée au niveau du commutateur, du sous-système de stockage et/ou de la carte de bus hôte, et non à partir de Windows. Windows n'offre aucune fonctionnalité de mappage des numéros LUN.

  • L'utilisation de logiciels multichemins et de plusieurs cartes de bus hôte améliorent vos chances de restauration après un problème de perte de chemin d'accès. L'utilisation de plusieurs cartes de bus hôte dans un seul hôte permet d'assurer la redondance et (peut-être) d'augmenter le débit. Toutefois, si un problème survient entraînant la perte d'un chemin d'accès au SAN, il est possible que les lecteurs du SAN ne soient pas accessibles pendant une certaine période. Cette perte de chemin d'accès peut provoquer des problèmes sur le serveur Windows. Le comportement des logiciels multichemins est très variable selon le fabricant. Vérifiez les systèmes de stockage/RAID dans la liste de compatibilité matérielle (HCL) pour vous assurer que le pilote multichemin figure sur la liste HCL avec le système de stockage. Si le logiciel ne figure pas sur la liste, contactez votre vendeur de SAN.

    Pour afficher la liste de compatibilité matérielle pour le stockage/RAID, reportez-vous au site Web de Microsoft à l'adresse suivante :
    http://www.microsoft.com/whdc/hcl/default.mspx
  • Si les hôtes connectés font partie d'un cluster, reportez-vous à l'article suivant pour obtenir des informations sur l'utilisation de plusieurs clusters connectés au même SAN :
    304415 Prise en charge de plusieurs clusters connectés au même périphérique SAN

Dépannage

Cette section décrit plusieurs problèmes pouvant empêcher un serveur Windows de démarrer à partir d'un SAN :
  • Un problème très courant lors de la configuration d'un SAN est que plusieurs hôtes peuvent avoir accès au même disque logique. Ceci se produit généralement par faute d'un système de gestion de numéro LUN adéquat. Le comportement par défaut de Windows est de connecter et de monter chaque unité logique détectée lors du chargement du pilote de la carte de bus hôte. Si plusieurs hôtes montent le même disque, le système de fichiers peut être endommagé. Le SAN doit être configuré de sorte que seul un hôte puisse accéder à un disque logique spécifique à un moment donné. Les symptômes rencontrés lorsque plusieurs hôtes accèdent au même disque logique sont les suivants :
    Le composant Gestion des disques affiche le même disque logique sur plusieurs hôtes. La notification Plug-and-Play indiquant la détection de matériel nouveau peut s'afficher sur plusieurs hôtes lors de l'ajout ou de la configuration d'un nouveau disque logique. Lors de l'accès à un disque logique à l'aide du Poste de travail ou de l'Explorateur Windows, une erreur "Accès refusé", "Le périphérique n'est pas prêt" ou semblable, peut indiquer que d'autres hôtes ont accès au même disque logique.
  • Votre ordinateur cesse de répondre (se bloque) ou vous observez un temps de réponse plus long. Ceci peut indiquer une latence élevée du fichier d'échange, qui peut être accompagnée d'événements du Journal système semblables aux exemples suivants :
    ID de l'événement : 51
    Type d'événement : Avertissement
    Source de l'événement : Disque
    Description : Une erreur a été détectée sur le périphérique \Device\Harddisk0\DR0 au cours d'une opération de pagination.

    ID de l'événement : 11
    Source : %HBA_DRIVER_NAME%
    Description : Le pilote a détecté une erreur du contrôleur sur Device\ScsiPort0.

    ID de l'événement : 9
    Source : %HBA_DRIVER_NAME%
    Description : Le périphérique \Device\ScsiPort0 n'a pas répondu dans le délai imparti.
    Si les messages d'erreur ci-dessus apparaissent dans le Journal système, ils indiquent que Windows a rencontré un problème lors de l'accès à un disque. Si le disque auquel le message fait référence est sur le SAN, le message peut indiquer un problème de latence. Si un ID d'événement 51 est affiché, il indique que le gestionnaire de mémoire a rencontré un problème lors de la copie de données vers ou à partir de la mémoire. Un problème de latence du fichier d'échange peut également être indiqué par une panne du système du serveur Windows et l'affichage de l'un des messages d'erreur suivants sur un écran bleu :
    0x00000050 PAGE_FAULT_IN_NONPAGED_AREA

    ou

    0x0000000A IRQL_NOT_LESS_OR_EQUAL

    Ce problème peut être résolu en plaçant le fichier d'échange sur le disque dur local de l'hôte. Windows nécessite un accès fiable au fichier d'échange pour paginer les données vers ou à partir de la mémoire. Le déplacement du fichier d'échange sur l'hôte local permet d'assurer que l'accès n'est pas influencé par d'autres périphériques et hôtes sur le SAN.

    REMARQUE : si le fichier d'échange n'est pas situé sur la même partition que la partition de démarrage (généralement c:\Windows ou c:\WINNT), le fichier Memory.dmp ne sera pas créé. Memory.dmp est utilisé pour dépanner un ordinateur Windows affichant une erreur STOP. Pour obtenir des informations sur la configuration de votre ordinateur pour un vidage sur incident, consultez l'Aide de Windows.
Il existe plusieurs manières de résoudre les problèmes ci-dessus. La première est de tenter de corréler l'heure avec des événements qui se produisent sur le SAN. Par exemple, si Hôte_A effectuait une opération de copie de grande ampleur lorsque Hôte_B a affiché l'erreur 9s, ceci peut indiquer qu'aucun système de gestion de numéro LUN adéquat n'est en place. Un autre exemple est si Hôte_B affiche des erreurs à chaque redémarrage de Hôte_A. Ceci peut indiquer que le Fibre Channel à boucle arbitrée est utilisé et que Hôte_B est affecté par des séquences LIP (Loop Initialization Primitive) de Hôte_A. Ces problèmes peuvent souvent être corrigés en reconfigurant le SAN, mais ceci nécessite l'assistance du vendeur du matériel. Tout type de problème de latence peut être résolu en plaçant le fichier d'échange sur le disque dur local du serveur Windows, mais là encore cette procédure désactive la création d'un fichier de vidage de mémoire. Il est important de comprendre que le vendeur de matériel du SAN dispose des informations nécessaires à la configuration correcte et doit être le premier point de contact pour toute question et tout problème de configuration.

Pour plus d'informations sur les clusters de serveurs Windows dans un environnement SAN, cliquez sur les numéros ci-dessous pour afficher les articles correspondants dans la Base de connaissances Microsoft :
304415 Prise en charge de plusieurs clusters connectés au même périphérique SAN
280743 Windows Clustering et sites séparés géographiquement

Propriétés

Numéro d'article: 305547 - Dernière mise à jour: lundi 6 août 2007 - Version: 2.3
Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • Microsoft Windows 2000 Server
  • Microsoft Windows 2000 Advanced Server
  • Microsoft Windows 2000 Datacenter Server
Mots-clés : 
kbinfo kbenv kbnetwork KB305547
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.

Envoyer des commentaires

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com