Partager via

Prise en charge du démarrage à partir d’un réseau san (Storage Area Network)

  • Article

Cet article décrit la prise en charge de l’amorçage d’un serveur Windows à partir d’un réseau san (Storage Area Network).

Numéro de base de connaissances d’origine : 305547

Plus d’informations

Microsoft prend en charge le démarrage à partir d’un réseau san (Storage Area Network) si le fournisseur SAN prend en charge leur plateforme matérielle particulière qui démarre un serveur Windows. L’adaptateur de bus SAN et hôte (HBA) doit être configuré conformément aux instructions du fournisseur SAN et le fournisseur SAN doit agir comme point de contact principal pour les problèmes liés au démarrage. Cette exigence existe, car le démarrage à partir d’un san est complexe et le fournisseur doit prendre en charge la configuration particulière, car le fournisseur SAN fournit l’instruction de prise en charge du démarrage SAN. Il est important de noter que les informations incluses dans cet article ne sont pas destinées à être une liste complète des éléments requis pour démarrer à partir d’un san. Le fournisseur SAN doit fournir des étapes spécifiques, des pilotes, des révisions de microprogramme et des ressources sur la façon de rendre leur matériel (systèmes de stockage, commutateurs, adaptateurs de bus hôte, et ainsi de suite) fonctionnent correctement ensemble.

Configuration

Les problèmes suivants doivent être résolus afin que plusieurs ordinateurs puissent démarrer correctement à partir d’un réseau SAN :

  • Pour démarrer plusieurs ordinateurs à partir d’un réseau SAN, le san doit être configuré dans un environnement commuté, ou il doit être directement attaché de chaque hôte à l’un des ports Fibre Channel du sous-système de stockage. L’utilisation de Fibre Channel - Boucle arbitrated (FC-AL) n’est pas prise en charge lors du démarrage de plusieurs serveurs à partir du réseau SAN, car elle n’autorise pas les hôtes attachés au san à être correctement séparés les uns des autres. Un environnement commuté permet aux hôtes d’être séparés les uns des autres. Le démarrage vers un SAN avec une topologie de boucles Fibre Channel-Arbitrated n’est pris en charge que lors du démarrage d’un serveur unique à partir du réseau SAN.

  • L’hôte doit avoir un accès exclusif au disque à partir duquel il démarre. Aucun autre hôte sur le SAN ne doit être en mesure de détecter ou d’avoir accès au même disque logique. Cela peut être effectué à l’aide d’un type de gestion de numéro d’unité logique (LUN), comme le masquage, le zonage ou une combinaison de ces méthodes. La gestion des lun est normalement configurée au niveau du commutateur, du sous-système de stockage et/ou de l’adaptateur HBA (Host Bus Adapter) et non dans Windows. Windows ne fournit aucune capacité pour le mappage des numéros d’unité logique.

  • Les logiciels multi-chemins et plusieurs HBA améliorent vos chances de récupération à partir d’une défaillance de chemin d’accès. L’objectif d’avoir plusieurs HBA dans un seul hôte consiste à avoir une redondance et (éventuellement) un débit accru. Toutefois, si une défaillance se produit et qu’un chemin d’accès au san est perdu, il peut y avoir un certain temps où les lecteurs sur le SAN ne sont pas accessibles. Cet échec de chemin d’accès peut entraîner des problèmes avec le serveur Windows. Le comportement du logiciel multi-chemin varie considérablement entre les fournisseurs. Vérifiez le catalogue Windows (anciennement liste de compatibilité matérielle ou HCL) pour les systèmes stockage/RAID pour vous assurer que le pilote multi-chemin se trouve dans le catalogue Windows avec le système de stockage. Si vous ne trouvez pas le logiciel multi-chemin, contactez votre fournisseur SAN.

  • Si les hôtes attachés font partie d’une solution de cluster Windows 2000, vous devez utiliser un HBA pour le processus de démarrage et un HBA distinct pour le stockage partagé.

  • Si les hôtes attachés font partie d’une solution de cluster Windows 2000 et utilisent la fonctionnalité d’E/S multipath (MPIO) Microsoft, vous avez besoin de quatre HBA.

Dépannage

Cette section décrit plusieurs problèmes qui peuvent empêcher un serveur Windows de démarrer correctement à partir d’un san :

  • Un problème courant lors de la configuration d’un san est qu’il est possible que plusieurs hôtes aient accès au même disque logique. Cela se produit généralement parce que la gestion appropriée des LUN n’a pas été employée. Le comportement par défaut de Windows consiste à attacher et monter chaque unité logique qu’il détecte quand le pilote HBA se charge. Si plusieurs hôtes montent le même disque, les dommages du système de fichiers peuvent se produire. Il incombe à la configuration du san de s’assurer qu’un seul hôte peut accéder à un disque logique particulier à la fois. Les symptômes de plusieurs hôtes accédant au même disque logique sont les suivants :
    La gestion des disques affiche le même disque logique sur plusieurs hôtes. Plug-and-Play notification indiquant que le nouveau matériel est trouvé peut se produire sur plusieurs hôtes lorsque vous ajoutez ou configurez un nouveau disque logique. Lorsque vous essayez d’accéder à un disque logique à l’aide de Mon ordinateur ou de l’Explorateur Windows, vous pouvez recevoir un message d’erreur « Accès refusé », « Appareil non prêt » ou message d’erreur similaire qui peut indiquer que d’autres hôtes ont accès au même disque logique.

  • Votre ordinateur cesse de répondre (se bloque) ou a des temps de réponse lents. Cela peut indiquer qu’il existe une latence élevée dans le fichier page, et cela peut être accompagné d’événements dans le journal système, tels que :

    ID d’événement : 51
    Type d'événement : Avertissement
    Source d’événement : Disque
    Description : une erreur a été détectée sur l’appareil \Device\Harddisk0\DR0 lors d’une opération de pagination.

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

    ID d’événement : 9
    Source : %HBA_DRIVER_NAME%
    Description : L’appareil, \Device\ScsiPort0, n’a pas répondu pendant la période d’expiration.

    Si les messages d’erreur précédents se trouvent dans le journal système, il indique que Windows essayait d’accéder à un disque et qu’il y avait un problème. Si le disque référencé se trouve sur le réseau SAN, il peut indiquer un problème de latence. Si un ID d’événement 51 est affiché, cela indique que le Gestionnaire de mémoire tentait de copier des données vers ou à partir de la mémoire et avait un problème. Un autre indicateur de problèmes de latence de fichier de page est si le serveur Windows a une défaillance système et que l’un des messages d’erreur suivants s’affiche sur un écran bleu :

    0x00000050 PAGE_FAULT_IN_NONPAGED_AREA

    ou

    0x0000000A IRQL_NOT_LESS_OR_EQUAL

    Une résolution possible consiste à placer le fichier de pages sur le disque dur local de l’hôte. Windows a besoin d’un accès fiable au fichier de pages, car les données sont paginées en mémoire ou hors mémoire. Le fait d’avoir le fichier de page local sur l’hôte garantit que l’accès n’est pas influencé par d’autres appareils et hôtes sur le réseau SAN.

    Note

    Si le fichier page n’est pas sur la même partition que la partition de démarrage (généralement c :\Windows ou c :\WINNT), la création d’un fichier Memory.dmp ne se produit pas. Un fichier Memory.dmp est utilisé pour résoudre les problèmes d’un ordinateur Windows qui a une erreur STOP. Pour plus d’informations sur la configuration de votre ordinateur pour un crashdump, consultez l’aide de Windows.

Il existe plusieurs façons de résoudre les problèmes précédents. La première méthode consiste à essayer et à mettre en corrélation l’heure avec tous les événements qui se produisent sur le san. Par exemple, hostA effectuait une opération de copie volumineuse et HostB signale l’erreur 9s, cela peut impliquer que la gestion appropriée des LUN n’est pas en place. Un autre exemple est si HostB génère des erreurs chaque fois que HostA est redémarré. Cela peut indiquer que FC-AL est utilisé et HostB est affecté par des séquences LIP (Loop Initialization Primitive) de HostA. Elles peuvent souvent être corrigées en reconfigurant le réseau SAN, ce qui nécessite l’assistance du fournisseur de matériel. Tous les types de problèmes de latence peuvent être résolus en plaçant le fichier de page sur le disque dur local du serveur Windows, mais à nouveau, cela désactive la création d’un vidage de mémoire. Un point clé à comprendre est que le fournisseur de matériel du SAN aura le plus d’informations sur la configuration appropriée et doit être le premier point de contact pour toutes les questions et préoccupations de configuration.