Considérations relatives au clustering pour le stockage

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.

Notez que, dans les deux configurations, un périphérique ReadZilla peut être utilisé uniquement lorsque le pool auquel il est assigné est importé sur la tête à laquelle la propriété de ce pool a été attribuée. Ainsi, lorsqu'un pool fait l'objet d'un relais en cas de défaillance d'une tête, la mise en cache des opérations de lecture est impossible pour ce pool, même si la tête qui l'a importé possède également des périphériques ReadZilla non utilisés. Il est donc conseillé de configurer ReadZilla dans un cluster actif-passif conformément à la documentation Configuration de stockage. Cette recommandation ne s'applique pas aux périphériques LogZilla, situés dans la topologie Fabric de stockage, qui restent accessibles à toutes les têtes ayant importé le pool.

Table 2-38 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.

Ignorer les liens de navigation
Quitter la vue de l'impression
	Guide d'administration des systèmes Oracle^® ZFS Storage Appliance, version 2013.1.3.0