• iSCSI reconnecting suite à un reboot

    J’ai rencontré un problème assez pénalisant en utilisant mes VMs Cluster sous Hyper-V :

    Lors de chaque redémarrage de mes guest Windows 2008 pour faire des clusters virtuels, les connexions iSCSI restaient en état reconnecting. Je devais alors reconfigurer tous les initiators afin qu’ils puissent être de nouveau fonctionnel avec mon iSCSI Target.

    J’ai utilisé une solution de contournement avec la clef de registre EnablePMTUDiscovery = 1 dans HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

    Maintenant, mes VMs se reconnectent correctement suite à leur reboot.

    Note : Cette solution de contournement peut affecter les performances TCP et n’est valable que dans le cadre de testing…

    Lien Technet

    http://technet.microsoft.com/en-us/library/cc957539.aspx

    La liste suivante décrit les paramètres que vous pouvez utiliser avec cette valeur du registre :

    1 : Lorsque vous définissez EnablePMTUDiscovery sur 1, TCP tente de découvrir la taille de l'unité MTU (Maximum Transmission Unit ) ou la taille de paquet la plus élevée sur le chemin d'accès à un hôte distant. TCP peut éliminer la fragmentation sur les routeurs sur le chemin d'accès qui connecte des réseaux à différentes unités MTU, en découvrant l'unité MTU du chemin et en limitant les segments TCP à cette taille. Inversement, la fragmentation affecte le débit TCP.

    0 : Nous vous recommandons de définir EnablePMTUDiscovery sur 0. Ainsi, une unité MTU de 576 octets est utilisée pour toutes les connexions qui ne sont pas des hôtes sur le sous-réseau local. Si vous ne définissez pas cette valeur sur 0, un attaquant peut forcer la valeur de l'unité MTU à une très petite valeur et ainsi surmener la pile.

    Lionel

    Windows Core Support Escalation Engineer

  • Faites le bon choix pour votre plateforme de virtualisation #2 : translation des adresses mémoire

    Le premier bulletin de cette série traitera de la gestion de la mémoire.

    La gestion de la mémoire est un facteur crucial au sein d’un système d’exploitable.

    Dans le monde de la virtualisation, le mécanisme visant à gérer les allocations mémoire est d’autant plus complexe et coûteux qu’il faut prendre en compte deux niveaux de mémoire alors qu’un système traditionnel n’en a qu’un seul (d’un point de vue très simplifié).

     

     

    Gestion de la mémoire sur un système classique

     

     

    Sur un système Windows classique, il y a une notion de mémoire physique et une notion de mémoire virtuelle.

    Le système alloue un espace mémoire au kernel et un espace mémoire au mode user dans ce que l’on appelle la mémoire virtuelle. Cette mémoire virtuelle est adressée dans la mémoire physique et la mémoire paginée (le pagefile).

    Sur un système 32 bit, cet espace mémoire virtuel alloue par défaut 2GB au kernel et 2GB au mode user (avec le /3GB : 1GB pour le kernel et 3GB pour le mode user).

    Sur un système 64 bit, la répartition est de 8TB pour le kernel et 8TB pour le mode user.

    Dans les deux cas, même si la mémoire physique disponible est inférieure à 4GB.

     

     

    Une partie du travail du Memory Manager est donc de traduire les adresses virtuelles en adresses physiques (qui se trouvent soit en mémoire physique soit dans le pagefile).

     

    image

     

     

    Gestion de la mémoire sur un système virtualisé

     

     

    Sur un système où un hypervisor s’exécute, on retrouve un niveau de mémoire supplémentaire : la mémoire allouée aux machines virtuelles et vue par celles-ci comme de la mémoire physique.

    image

    Et c’est là où ça se complique un peu et où il est nécessaire d’utiliser tout un jeu d’acronymes barbares pour comprendre ce que doit assumer l’hypervisor:

    • SPA (System Physical Address Space) : l’espace d’adressage physique réel (en gros dans les barrettes de RAM)
    • GPA (Guest Physical Address Space) : l’espace d’adressage physique vu d’une machine virtuelle (dans la représentation qu’a la machine virtuelle de la mémoire physique qui lui est présentée par l’hypervisor)
    • GVA (Guest Virtual Address Space) : l’espace d’adressage virtuel d’une machine virtuelle (ou de l’hôte)

     

     

    Ces espaces sont représentés d’une autre manière dans le schéma ci-dessous :

     

    image

     

     

    Dans cette situation, le système d’exploitation s’exécutant dans la machine virtuelle traduit les adresses mémoires virtuelles (GVA) en adresses mémoires “physiques” (GPA) et l’hypervisor va traduit les adresses “physiques” des pages mémoires (GPA) de la machine virtuelle en adresses physiques réelles (SPA).

     

     

    Ce qui correspond au schéma ci-dessous :

     

    image

     

     

    La translation d’adresse GPA vers SPA est donc prise en charge par l’hypervisor. C’est une solution de translation d’adresse logicielle.

    Dans le détail, le processeur maintient une liste de correspondance des adresses de la mémoire virtuelle (GVA) utilisées par les machines virtuelles avec la mémoire physique (SPA) dans ce qu’on appelle un Translation Looksaside Buffer (TLB). Lorsque la machine virtuelle tente d’accéder à une donnée ou une fonction qui est référencée par une adresse virtuelle mais que cette adresse virtuelle ne correspond à aucun contenu cela résulte en une faute de page (Page Fault). Cette faute de page est interceptée par l’hypervisor qui charge en mémoire la donnée ou la fonction et établit la translation d’adresse en spécifiant l’adresse physique dans la page TLB.

    Comme on peut le comprendre, comme toute opération traitée par du logiciel, cette tâche de translation d’adresse est consommatrice en temps CPU. Bien plus que par du microcode embarqué dans du silicium.

    C’est ce que nous appellons Second Level Address Translation (SLAT).

     

     

    Prise en charge de la translation d’adresse par le CPU

     

     

    J’en viens alors au premier avantage qu’apportent les nouvelles fonctionnalités d’AMD et d’Intel® : le déport de cette mécanique de l’hypervisor vers le CPU.

    • Pour Intel®, cette tâche est assurée par la technologie Intel VT Extended Page Tables
    • Pour AMD, c’est la technologie Rapid Virtualization Indexing (ou Nested Page Tables) qui assume ce rôle

     

     

    Les deux fondeurs utilisent une terminologie différente mais le principe est le même, et cela permet de libérer l’hypervisor de cette tâche lui donnant plus de temps pour effectuer des actions plus importantes sinon plus utiles.

     

    image

     

    Cette fonctionnalité mise en oeuvre par les CPUs est supporté par Hyper-V v2 disponible avec Windows Server 2008 R2.

     

     

    Ressources

     

     

    KB555223 - RAM, Virtual Memory, Pagefile and all that stuff

    Virtual Address Space

    (WO/2007/073624) VIRTUAL TRANSLATION LOOKASIDE BUFFER (World Intellectual Property Organisation, en Anglais)

    The very first independent Nested Paging Virtualization tests (Anandtech - AMD Nested Pagaing benchmark)

    Intel® 64 and IA-32 Architectures Software Developer's Manual Volume 3B: System Programming Guide, Part 2 (en Anglais) – Extended Page Tables, chapitre 25.2

    AMD-V™ Nested Paging

    Rapid Virtualization Indexing with Windows Server 2008 R2 Hyper-V

    Guest Post: Intel Inside for Hyper-V Virtualization

    PDC 2008: Virtualization, An overview of the hardware features that give rise to world-class virtualization and cloud computing

     

     

    Guillaume

    Windows Core Support Escalation Engineer

  • Cluster Checkpoint registry (Windows 2003)

    Objectif:

    Nativement, le service Cluster maintient sa configuration en copiant sur tous les nœuds du Cluster la Hive Cluster. Cette Hive (une ruche en anglais) se situe dans HKLM\Cluster et contient tous les paramètres des ressources du Cluster. C'est-à-dire que les ressources utilisées dans le Cluster stockent leurs paramètres et propriétés dans cette Hive (@IP, nom du Network Name, chemin d’un File share , etc).  On retrouve également une copie de cette Hive sur le disque du Quorum (Q:\MSCS) sous la forme d’un fichier CHKxxx.tmp.

    Mais si une application clusterisée n’utilise pas la section HKLM\Cluster pour y stocker ses données, comment les autres nœuds peuvent recevoir ce contenu ?

    Le registry Checkpointing dans un cluster a pour objectif de propager le contenu d’un bout de base de registre qui ne serait pas localisée dans  HKLM\Cluster mais dans HKLM\Software, là où les applications enregistrent généralement leurs données.

    Des fichiers 0000000x.CPT présents sur le disque du  quorum représentent le contenu de base de registre qui sont à sauvegarder et donc a propager lorsque ces ressources basculent d’un nœud à un autre.  Ils sont organisés comme suit :

    ü  0000000x.CPT représente un checkpoint registry pour une ressource.

    ü  Il sont stockés sur le disque du Quorum comme ceci : Q:\MSCS\<GUID>\

    Q : étant le disque du Quorum et MSCS le répertoire par défaut

    <GUID> est le GUID de la ressource nécessitant un checkpoint registry et que nous retrouvons dans HKLM\Cluster\GUID.

    Ce principe est utilisé par SQL ou des applications génériques par exemple.

    Ressources en ligne:

    How a Server Cluster Works: http://technet2.microsoft.com/WindowsServer/en/library/4aa0be73-ef61-4f9c-a071-b390278b47731033.mspx?mfr=true

    Checkpointing  http://msdn2.microsoft.com/en-us/library/aa367195.aspx

    ClusterRecovery tool: http://www.microsoft.com/downloads/details.aspx?familyid=2BE7EBF0-A408-4232-9353-64AAFD65306D&displaylang=en

    Knowledge Base:

    Restore registry check points stop working after you restore a server cluster

    http://support.microsoft.com/default.aspx?scid=kb;EN-US;307469

    174070  Registry replication in Microsoft Cluster Server

    http://support.microsoft.com/default.aspx?scid=kb;EN-US;174070

     

    Règles relatives au checkpoint Registry

    1. Lors de tout changement sur la clé de registre ‘Checkpointée’ et lorsque la ressource est en ligne, le service cluster stocke une copie de ce registre sur la ressource quorum.
    2. Un changement fait sur une clé de registre ‘Checkpointée’ pendant que la ressource se trouve ‘Offline’ sera ré-écrasé par la précédente valeur stockée lorsque l’application passera ‘Online’
    3. Si les ressources basculent sur un autre nœud, le service cluster restaure les valeurs de registre depuis les fichiers stockées sur le quorum vers le nouveau nœud avant de mettre en ligne la ressource concernée par le Checkpoint.
    4. Si une ressource est supprimée, le Checkpoint est aussi supprimé mais pas les informations contenu dans le registre local.
    5. Les Checkpoints sont inclus dans les backup créés par la function  BackupClusterDatabase
      Plusieurs instances de ressources sur différents nœuds doivent être manipulées avec attention. Par exemple, une ressource A[0] stocke une valeur data[0] dans un Checkpoint A sur le nœud 0. Une ressource A[1] stocke une valeur data[1] dans un Checkpoint A sur le nœud 1. Si la ressource A[1] basculent sur le nœud 0, le service Cluster remplacera data[0] par data[1] pour le checkpoint A. Si la ressource A[0] dépend de data[0], elle sera aussi en échec. Une solution à ce problème consiste à donner des noms différents de clef ‘Checkpointé’ sur les différents nœuds.
       

    Lister les Checkpoints actuels du Cluster:

    cluster . /checkpoints

    Ajouter un Checkpoint au Cluster

    cluster . resource "< Nom de la ressource >" /addcheckpoints:"\Software\...”

    Supprimer un Checkpoint au Cluster

    cluster . resource "< Nom de la ressource >" /removecheck :"\Software\...”

    Mise en situation :

    Imaginons que nous avons créé une application Client/Serveur ‘Onyone’ dont les données de registre sont stockées sous HKLM\Software\Onyone et HKLM\Software\Onyone2. Nous souhaitons la mettre dans un cluster sous forme d’application générique afin d’offrir aux utilisateurs une haute disponibilité.
    Pour assurer la copie des clefs précédentes, nous allons ajouter à l’aide de la commande CLUSTER.EXE, deux checkpoints sur la ressource Network Name ‘Network Name DATA’ de cette application.

    C:\>cluster resource "Network Name DATA" /addcheckpoints:"SOFTWARE\Microsoft\onyone"
    Adding registry checkpoint 'SOFTWARE\Microsoft\onyone' for resource 'Network Name DATA'...

    C:\>cluster resource "Network Name DATA" /addcheckpoints:"SOFTWARE\Microsoft\onyone2"
    Adding registry checkpoint 'SOFTWARE\Microsoft\onyone2' for resource 'Network Name DATA'...

    Regardons maintenant la prise en compte de ces commandes :

    C:\>Cluster . resource /checkpoints
    No resource name specified.

    Listing registry checkpoints for all resources...

    Resource             Registry Checkpoint
    -------------------- --------------------------------------------------------
    Quorum Disk          None

    Cluster IP Address   None

    Cluster Name         None

    Disk P:              None

    IP File Share        None

    Network Name DATA    'SOFTWARE\Microsoft\onyone'

    Network Name DATA    'SOFTWARE\Microsoft\onyone2'

    File Share           None

    Sur le disque du quorum, nous retrouvons dans le répertoire \MSCS (par défaut), un nouveau répertoire qui a été créé et ayant le GUID de la ressource concernée et contenant deux fichiers CPT :

    image

    Ce GUID est peut être retrouvé dans la clef HKLM\Cluster.

     

    clip_image002

    Lionel

    Windows Core Support Escalation Engineer

  • Liens vers HCL/WSC et matrice de compatibilité Cluster

    La HCL , WSC ou matrice de compatibilité Cluster, ça vous dit quelque chose?

    Mais si, ce sont ces fameuses listes qui répertorie l'ensemble des élements composant une solution Cluster 2000/2003. L'ennui est qu'il est difficile de trouver sa configuraiton et  les matériels et logiciels évoluant, elle n'est pas forcement à jour. C'est pour cela que je vous ai regroupé différents pointeurs vers les OEM les plus connus pour limiter les spectres de vos recherches. Si vous avez un doute sur la compatibilité de votre matériel avec le MSCS, il est facile de demander à votre OEM le lien vers vers votre solution en place.

    Et pour Failover Cluster 2008 et 2008 R2? et bien, c'est beaucoup plus simple : il suffit que vos composants (hosts, HBA, SAN et softtware) aient reçus le logo Certified for Windows Server 2008 ou Certified for Windows Server 2008 R2 et que les tests de Validate passent avec succès. That's All!

    The Microsoft Support Policy for Windows Server 2008 Failover Clusters : http://support.microsoft.com/kb/943984

    Lionel

    Windows Core Support Escalation Engineer