Considérations relatives au clustering pour le stockage

Langue :

Lorsque vous redimensionnez un système de la série Oracle ZFS Storage Appliance pour l'utiliser dans un cluster, deux considérations supplémentaires ont leur importance. La décision la plus importante consiste certainement à décider d'attribuer la propriété à tous les pools de stockage ou à la diviser entre ces derniers. Plusieurs répartitions sont possibles, comme indiqué dans le tableau ci-dessous. Généralement, les pools doivent être configurés sur une seule tête, sauf en cas d'optimisation du débit durant l'opération nominale ou lorsque les performances de basculement ne sont pas prises en compte. En état de basculement, les modifications exactes des caractéristiques des performances dépendent largement de la nature et de la taille de la charge de travail. En général, plus une tête est proche de fournir des performances maximales sur un axe particulier et plus la dégradation des performances est importante le long de l'axe lorsque la charge de travail est reprise par le pair de la tête. En cas de pools multiples, cette dégradation s'applique aux deux charges de travail.

Les périphériques ReadZilla ne suivent pas les pools de données dans les situations de reprise ou de rétablissement. Un périphérique ReadZilla n'est actif que dans un noeud de cluster particulier lorsqu'un le pool assigné au périphérique de mise en cache des opérations de lecture est importé sur le noeud sur lequel se trouve ReadZilla. En l'absence d'étapes de configuration supplémentaires, la mise en cache des opérations de lecture ne sera pas disponible pour un pool qui a migré en raison d'un événement de basculement. Afin d'activer un périphérique ReadZilla pour un pool qui n'appartient pas à un pair de cluster, reprenez le pool sur le noeud sans appartenance, puis ajoutez du stockage et sélectionnez les périphériques de mise en cache pour la configuration. Il est donc conseillé de configurer les périphériques ReadZilla dans un noeud de cluster conformément à la documentation Storage Configuration. Les périphériques LogZilla, contrairement aux périphériques ReadZilla, sont situés dans la topologie Fabric de stockage et restent accessibles à toutes les têtes ayant importé le pool.

Table 2-37 Considérations relatives au clustering pour le stockage

Variable	Propriété mononoeud	Pools multiples possédés par des têtes différentes
Débit total (opération nominale)	Jusqu'à 50 % des ressources de CPU totales, 50 % de la DRAM et 50 % de la connectivité réseau totale peuvent être utilisés pour fournir le service à un moment précis. C'est simple : une seule tête traite les requêtes du client, l'autre est inactive.	Toutes les ressources de CPU et de DRAM peuvent être utilisées pour fournir le service à tout moment. Jusqu'à 50 % de la connectivité réseau peut être utilisée à tout moment (des périphériques réseau invisibles sont requis sur chaque tête pour prendre en charge le basculement).
Débit total (basculement)	Aucune modification du débit par rapport à l'opération nominale.	100 % des ressources de tête encore fonctionnelles sont utilisées pour fournir le service. Le débit total relatif à l'opération nominale est compris entre environ 40 et 100 %, en fonction de l'utilisation durant l'opération nominale.
Temps d'attente d'E/S (basculement)	ReadZilla n'est pas disponible durant une opération de basculement, ce qui peut considérablement augmenter les temps d'attente pour les charges de travail intégrées au cache de lecture disponible. Le temps d'attente des opérations d'écriture n'est pas concerné.	ReadZilla n'est pas disponible durant une opération de basculement, ce qui peut considérablement augmenter les temps d'attente pour les charges de travail intégrées au cache de lecture disponible. Le temps d'attente des opérations de lecture et d'écriture peut être augmenté en raison des conflits importants en matière d'utilisation des ressources de tête résultant de l'exécution de deux charges de travail sur la tête encore fonctionnelle à la place de la tête habituelle. Lorsque les charges de travail nominales de chaque tête atteignent les capacités maximales de la tête, les temps d'attente dans l'état de basculement peuvent être extrêmement longs.
Flexibilité du stockage	Les partages et les LUN peuvent tirer parti de toutes les unités de stockage physiques disponibles.	Les partages et les LUN d'un pool peuvent utiliser uniquement le stockage alloué à ce pool. Le stockage n'est pas partagé entre les pools. Si un pool est saturé tandis que l'autre possède de l'espace libre, de l'espace de stockage risque donc d'être gaspillé.
Connectivité réseau	Tous les périphériques réseau de chaque tête peuvent être utilisés tandis que la tête est en service.	Seule la moitié de l'ensemble des périphériques réseau de chaque tête peut être utilisée lorsque la tête est en service. Chaque pool peut donc être connecté à seulement la moitié des réseaux physiquement disjoints.

Une deuxième considération importante relative au stockage a trait à l'utilisation des configurations de pool sans point de panne unique. Etant donné que l'utilisation du clustering implique que l'application donne une importance significative à la disponibilité, il existe rarement une bonne raison de configurer des pools de stockage d'une manière autorisant l'échec d'une étagère de disques unique et par conséquent une perte de disponibilité. L'inconvénient de cette approche est que les configurations NSPF nécessitent un plus grand nombre d'étagères de disques que les configurations ayant un point de panne unique. Lorsque la capacité requise est très faible, l'installation d'un nombre suffisant d'étagères de disques pour autoriser la configuration NSPF au niveau RAID voulu peut ne pas être économique.