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 les périphériques ReadZilla dans un cluster actif-passif conformément auChapter 5, 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.

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'un JBOD unique et par conséquent une perte de disponibilité. L'inconvénient de cette approche tient à ce que les configurations sans point de panne unique requièrent un plus grand nombre de JBOD que de configurations avec point de panne unique. Lorsque la capacité requise est très faible, l'installation d'un nombre suffisant de JBOD pour les configurations sans point de panne unique sur le niveau RAID de votre choix n'est pas forcément très économique.