Il est primordial de comprendre la portée de l'implémentation du clustering de la série Oracle ZFS Storage Appliance. Dans le secteur, le terme "cluster" fait référence à de nombreuses technologies et à des buts très divers. Dans la présente documentation, il fait référence à un métasystème composé de deux contrôleurs d'appareil et d'un système de stockage partagé permettant une meilleure disponibilité au cas où l'un des contrôleurs subirait des pannes matérielles ou logicielles. Un cluster contient exactement deux appareils ou contrôleurs de stockage, ci-après dénommés contrôleurs pour des raisons de concision. Il est possible d'attribuer à chaque contrôleur un ensemble de stockage, une mise en réseau et d'autres ressources issues de l'ensemble disponible sur le cluster qui permettent la construction de l'une des deux topologies majeures. De nombreuses personnes utilisent le terme actif-actif pour décrire un cluster contenant aux moins deux pools de stockage, dont l'un est attribué à chaque contrôleur avec les ressources réseau utilisées par les clients pour atteindre les données stockées dans ce pool, et actif-passif pour désigner le pool de stockage unique auquel le contrôleur désigné comme actif ainsi que ses interfaces réseau associées sont attribuées. Les deux topologies sont prises en charge par le système Oracle ZFS Storage Appliance. La distinction entre ces topologies est artificielle. Il n'existe aucune différence logicielle ou matérielle ente les deux et vous pouvez passer de l'une à l'autre quand vous le souhaitez en ajoutant ou en détruisant un pool de stockage. Dans les deux cas, si un contrôleur échoue, l'autre (son pair) prend le contrôle de toutes les ressources connues et fournit les services associés à celles-ci.
Pour pallier aux heures ou aux jours d'inactivité requis pendant la réparation du contrôleur, le clustering fournit un pair qui distribue le service durant la réparation ou le remplacement. En outre, les clusters prennent en charge la mise à niveau non simultanée de logiciels qui permet de réduire les interruptions d'activité associées à la migration vers de nouveaux logiciels. Certaines technologies de clustering sont dotées de fonctionnalités supplémentaires allant au-delà l'amélioration de la disponibilité. Mais le sous-système de clustering de la série Oracle ZFS Storage Appliance n'a pas été conçu pour cela. En particulier, il ne permet pas l'équilibrage de charge sur plusieurs contrôleurs, n'améliore pas la disponibilité en cas de panne de stockage, n'offre pas aux clients l'espace de noms du système de fichiers unifié entre plusieurs appareils ni ne divise la responsabilité du service au sein d'une zone géographique étendue en cas de récupération après sinistre. Ces fonctions sont également hors de portée du présent document. Néanmoins, Oracle ZFS Storage Appliance et les protocoles de données qu'il fournit prennent en charge de nombreuses fonctions et stratégies permettant d'améliorer la disponibilité :
La réplication de données, qui peut être utilisée pour la récupération après sinistre depuis un ou plusieurs sites éloignés géographiquement.
La mise en miroir des données côté client peut être effectuée à l'aide des LUN iSCSI fournies par plusieurs serveurs de stockage localisés de façon arbitraire.
L'équilibrage de charge est intégré au protocole NFS et peut être fourni pour certains autres protocoles via un matériel ou un logiciel externe (s'applique aux données en lecture seule).
Les composants matériels redondants incluent les alimentations, les périphériques réseau et les contrôleurs de stockage.
Le logiciel de gestion des pannes permet d'identifier les composants défectueux, de les supprimer du service et de guider les techniciens dans la réparation ou le remplacement par du matériel correct.
La redondance de la topologie Fabric réseau, permise par les fonctionnalités LACP et IPMP.
Les périphériques de stockage redondants (RAID)
Des informations supplémentaires relatives aux autres fonctions de disponibilité sont disponibles dans les sections appropriées du présent document.
Avant de vous décider entre une configuration en cluster ou autonome de la série Oracle ZFS Storage Appliance, il est important de peser le pour et le contre. Dans le secteur des technologies de l'information, il est courant de considérer le clustering comme un choix d'architecture automatique, bien que cette approche reflète une vision idéalisée des risques et des avantages du clustering promulguée par certains vendeurs du secteur. En plus de l'avancée incontestable, des coûts de matériel et de support induits associés au marché du second contrôleur, le clustering présente également des risques techniques et opérationnels supplémentaires. Certains de ces risques peuvent être atténués en s'assurant que la totalité du personnel est parfaitement formé aux opérations du cluster, les autres étant intrinsèques au fonctionnement en cluster. Les risques sont les suivants :
Intolérance potentielle de l'application aux comportements dépendant du protocole durant la reprise
Possibilité que le logiciel de cluster tombe lui-même en panne ou qu'il induise une panne dans un autre sous-système qui n'aurait pas eu lieu dans une opération autonome
Plus grande complexité de gestion et plus forte probabilité que des erreurs opérateur surviennent lors de l'exécution de tâches de gestion
Possibilité que plusieurs erreurs ou une erreur opérateur grave induise une perte ou une altération des données qui n'aurait pas lieu dans une configuration autonome
Plus grande difficulté de récupération à partir des états logiciels et/ou matériels non anticipés.
Ces coûts et ces risques sont fondamentaux et s'appliquent d'une manière ou d'une autre à tous les produits clustérisés ou compatibles avec le clustering du marché (y compris la série Oracle ZFS Storage Appliance) et ne peuvent pas être entièrement éliminés ni limités. Les architectes de stockage doivent peser le pour et le contre par rapport à l'avantage principale du clustering : l'opportunité de transformer les heures ou jours d'indisponibilité en minutes, ou moins, dans le rare cas d'une panne matérielle ou logicielle catastrophique. Le fait que l'analyse coût/bénéfice favorise ou non l'utilisation du clustering dans un déploiement de la série Oracle ZFS Storage Appliance dépend de facteurs locaux tels que les termes du contrat de niveau de service, le personnel de support disponible et ses qualifications ainsi que les contraintes budgétaires, l'anticipation des différentes pannes potentielles et les autres stratégies d'amélioration de la disponibilité. Ces facteurs dépendent étroitement du site, de l'application et des activités et doivent être évalués au cas par cas. La compréhension de la documentation dans le reste de cette section vous aidera à prendre les bonnes décisions lors de la conception et l'implémentation de votre infrastructure de stockage unifié.
Rubriques connexes