La haute disponibilité, autrefois réservée aux centres de données, est désormais un élément incontournable des plans de continuité d'activité. Les petites entreprises et les sites périphériques utilisent aujourd'hui des systèmes de point de vente, de vidéosurveillance et de stockage partagé, dont chaque minute d'indisponibilité engendre des coûts. Or, la solution classique, une baie de stockage d'entreprise à double contrôleur, est dimensionnée et tarifée pour les centres de données, et non pour les petites salles informatiques ou les baies murales. Ce décalage laisse les petites équipes informatiques avec des sauvegardes et des instantanés pour la protection des données, mais sans solution de continuité d'activité : un NAS à contrôleur unique, aussi bien conçu soit-il, reste un point de défaillance unique.
La haute disponibilité n'est pas une nouveauté pour QNAP, qui propose déjà des solutions matérielles à double contrôleur et des méthodes de récupération par réplication. La nouveauté du QuTS hero h6.0 réside dans l'efficacité. Le nouveau gestionnaire de haute disponibilité intègre le clustering au système d'exploitation sur du matériel standard, permettant à deux NAS identiques de former un cluster actif-passif derrière une seule adresse IP. Ainsi, en cas de panne de l'un, l'autre prend le relais et les clients ne s'en aperçoivent quasiment pas. Pour une entreprise cherchant à optimiser son investissement informatique, c'est la garantie d'une haute disponibilité au prix d'un second NAS, sans avoir à investir dans une infrastructure supplémentaire.
Voici le principe : pour tester sa robustesse en pratique, nous avons créé un cluster haute disponibilité en laboratoire à partir de deux systèmes QNAP TS-h765eU équipés de disques durs Seagate IronWolf Pro et de SSD QNAP E1.S pour le cache. Nous avons ensuite reproduit les pannes rencontrées sur les sites périphériques. Nous avons coupé l'alimentation du nœud actif en plein transfert. Nous avons interrompu sa connexion réseau tout en maintenant la fonction de pulsation. Dans les deux cas, la question était la même : le transfert de fichiers est-il maintenu et comment se déroule la récupération lorsque le nœud défaillant redémarre ?
Présentation du QNAP TS-h765eU
Le TS-h765eU est un choix intéressant comme composant d'une infrastructure haute disponibilité, notamment grâce à sa relative simplicité matérielle. Ce NAS rackable 1U à faible profondeur (seulement 292.1 mm) est conçu pour les petites baies multimédias, les racks réseau muraux et les déploiements en périphérie où un châssis standard ne peut être installé. Chaque unité offre quatre baies pour disques SATA 3.5 pouces en façade, ainsi que trois emplacements PCIe NVMe E1.S/M.2 à l'arrière, lui conférant une capacité de stockage hybride : disques durs pour la capacité de stockage, mémoire flash pour la mise en cache ou les accès rapides.
QNAP l'a également désigné comme un modèle d'approvisionnement à long terme avec une disponibilité garantie jusqu'en 2031, ce qui est important pour les organisations qui standardisent une plateforme sur plusieurs sites.
À l'intérieur, le TS-h765eU embarque un processeur Intel Atom x7405C quadricœur cadencé jusqu'à 3.4 GHz, associé à 8 Go de mémoire DDR5 (extensible à 16 Go) avec correction d'erreurs intégrée. La connectivité réseau comprend deux ports 2.5 GbE, et une connectivité 10 GbE est disponible en remplaçant un emplacement E1.S par le module QXG-ES10G1T de QNAP.
| Spécifications | QNAP TS-h765eU |
|---|---|
| Processeur | Processeur quadricœur Intel Atom x7405C, jusqu'à 3.4 GHz |
| Mémoire | 8 Go de mémoire DDR5, extensible à 16 Go (ECC intégrée) |
| Baies de disques | 4 disques SATA 3.5 pouces |
| Emplacements Flash | 3 x E1.S / M.2 PCIe NVMe |
| Networking | 2 ports 2.5 GbE, 10 GbE via module E1.S QXG-ES10G1T optionnel |
| Facteur de forme | Boîtier rack 1U à faible profondeur, 292.1 mm (12 pouces) de profondeur. |
| Système d'exploitation | QuTS hero h6.0 (basé sur ZFS) |
| Disponibilité | Modèle d'approvisionnement à long terme jusqu'en 2031 |
Pour cette évaluation, chaque nœud était équipé de quatre disques durs Seagate IronWolf Pro de 30 To (ST30000NT011) en RAID 5, ainsi que de deux disques SSD QNAP SSD700 E1.S de 3.84 To (SSD700D1-003T84) en RAID 0 servant de cache. Les deux systèmes exécutaient QuTS hero h6.0.0.3500 avec High Availability Manager 2.0.421.
QuTS hero h6.0 et l'architecture du gestionnaire HA
Le gestionnaire de haute disponibilité est la fonctionnalité phare de QuTS hero h6.0, reposant sur une architecture active-passive classique. Un NAS, le nœud actif, gère l'ensemble des données et des services. Le second NAS, le nœud passif, se synchronise en permanence avec le nœud actif via une connexion de pulsation dédiée et est prêt à prendre le relais. Les clients ne communiquent jamais directement avec les nœuds ; le cluster présente une adresse IP et un nom d'hôte uniques, auxquels répond le nœud actif. En cas de basculement, l'adresse IP du cluster redirige le trafic côté serveur, évitant ainsi la reconfiguration des lecteurs réseau mappés, des initiateurs iSCSI et des tâches de sauvegarde.
La liaison de pulsation est essentielle à l'architecture. QNAP exige une connexion directe entre les deux unités, sans commutateur intermédiaire, et assure à la fois le trafic de contrôle d'intégrité et la synchronisation des données au niveau bloc entre les nœuds. Une connexion de cluster distincte gère le trafic client via le réseau principal. Un serveur de quorum, troisième témoin sur le réseau, complète la protection contre le split-brain en aidant un nœud à déterminer s'il doit se promouvoir lorsque le signal de pulsation cesse. Nous aborderons plus en détail le split-brain et la topologie de déploiement permettant de le prévenir ultérieurement dans cet article.
QNAP affirme que plus de 90 % des services NAS sont compatibles avec la haute disponibilité (HA) sous Windows 6.0, et que le cluster peut étendre sa capacité grâce à des boîtiers d'extension JBOD. Cependant, certaines limitations subsistent. Les snapshots immuables, autre fonctionnalité phare de Windows 6.0, ne sont actuellement pas pris en charge au sein d'un cluster HA. Les administrateurs devront donc choisir entre les deux options de protection pour le moment. Par ailleurs, la HA requiert deux systèmes identiques (même modèle et même firmware), une condition vérifiée par l'assistant d'appairage avant toute configuration.
Création du cluster QNAP HA
La création d'un cluster commence avec deux unités TS-h765eU configurées indépendamment et dotées d'un matériel identique. À partir du nœud actif désigné, l'assistant Gestionnaire de haute disponibilité effectue une brève procédure d'appairage. L'assistant détecte le nœud passif via la liaison de pulsation, puis vous invite à attribuer des rôles à vos interfaces réseau : une connexion de cluster servant de canal de communication pour l'accès au cluster, et la connexion de pulsation, dédiée à la synchronisation des données et qui doit être une liaison directe entre les appareils, comme l'indique QNAP. Dans notre configuration, l'assistant a attribué la liaison de pulsation à l'adaptateur 1 et la connexion de cluster à l'adaptateur 2.
Vient ensuite l'identification du cluster. Vous lui attribuez un nom d'hôte et une adresse IP, qui deviendront l'adresse unique utilisée par les clients par la suite. Notre cluster, nommé SR-Test (176.16.248.34), était placé devant les nœuds QNAP-HA1 (176.16.248.33) et QNAP-HA2 (176.16.254.157), ces deux nœuds appartenant à des sous-réseaux /24 différents du réseau du laboratoire ; l'assistant les a appariés sans problème.
Une fois les paramètres confirmés, l'assistant lance une configuration en cinq étapes : établissement de la connexion de pulsation, configuration de l'environnement, arrêt des services, configuration des paramètres système et redémarrage des services. L'interface utilisateur précise qu'aucun appareil ne doit être mis hors tension pendant cette opération. Sur nos systèmes, la configuration s'est achevée en environ cinq minutes et demie. HA Manager a ensuite signalé la création du cluster et nous a redirigés vers son adresse IP. Au total, la conversion de deux NAS autonomes en un cluster de serveurs a pris moins de dix minutes grâce à l'assistant.
L'étape la plus complexe est la synchronisation initiale, durant laquelle le nœud actif réplique son pool de stockage sur le nœud passif, bloc par bloc. HA Manager l'indique clairement à l'aide d'une barre de progression, du nombre d'éléments et d'une estimation du temps restant en haut du tableau de bord, ainsi que d'un avertissement précisant que le basculement et les mises à jour du firmware sont indisponibles jusqu'à la fin de la synchronisation. Le suivi des statistiques de synchronisation pendant cette phase a été l'un des aspects les plus impressionnants du processus : les vitesses de transfert ont oscillé entre 900 Mo/s et 1.2 Go/s environ, avec une latence de l'ordre de la centaine de microsecondes, incluant une mesure représentative de 1 Go/s à 232 microsecondes. Notre synchronisation initiale s'est achevée en une dizaine de minutes, soit exactement la durée estimée de neuf minutes affichée par le tableau de bord.
Une fois la synchronisation terminée, le tableau de bord affiche un état « Bon » : cluster sain, signal de présence actif, les deux nœuds visibles avec les statistiques en temps réel du processeur, de la mémoire, du débit disque et du réseau affichées côte à côte, et l’état de synchronisation de chaque pool en dessous. C’est une vue claire et riche en informations qui répond aux deux questions essentielles d’un administrateur : le cluster est-il sain et mes données sont-elles synchronisées ?
Test de basculement 1 : Coupure de courant sur le nœud actif
Notre premier scénario de panne est le plus brutal : une coupure de courant totale sur le nœud actif. Nous avons lancé une copie de fichiers Windows depuis un client vers un partage SMB sur l’adresse IP du cluster ; il s’agissait d’un lot de six fichiers de 41.1 Go comprenant des images ISO de Windows 11 et de Rocky Linux, ainsi que deux archives de machines virtuelles Kali Linux. L’alimentation du QNAP-HA1 a ensuite été coupée en plein transfert.
Du point de vue du client, la copie s'est interrompue pendant un peu moins d'une minute, environ 50 secondes, entre la coupure de courant et la reprise du transfert des données. L'explorateur n'a signalé aucune erreur ; la boîte de dialogue de transfert a conservé sa progression, puis a repris lorsque QNAP-HA2 est devenu actif. HA Manager a brièvement indiqué le basculement du rôle de nœud actif en cours, puis a affiché un avertissement : impossible de détecter le nœud passif QNAP-HA1, avec la suggestion de vérifier que ce nœud est allumé et connecté au réseau. Le transfert s'est poursuivi à pleine vitesse vers la même adresse IP du cluster, même lorsque celui-ci fonctionnait sur un seul nœud, ce qui correspond exactement à l'état dégradé mais opérationnel promis par la haute disponibilité.
Le rétablissement de l'alimentation du QNAP-HA1 a automatiquement déclenché le processus inverse. Le nœud a redémarré et a rejoint le cluster en tant que membre passif environ dix minutes après la coupure de courant. HA Manager a alors commencé la synchronisation des données du nœud actif QNAP-HA2 vers QNAP-HA1, la progression et les estimations de temps étant affichées sur le tableau de bord, tandis que la copie de nos fichiers se poursuivait sans interruption. Le retour en arrière s'est fait sans intervention : une fois la resynchronisation terminée, le cluster a suspendu le transfert pendant environ 35 secondes pour redonner le rôle actif à QNAP-HA1, puis a laissé la copie s'exécuter jusqu'à son terme. À la fin de l'opération, le cluster était de nouveau opérationnel (état « Bon ») avec un transfert à 100 %, ayant ainsi résisté à une coupure de courant, une période de fonctionnement sur un seul nœud, une restauration de nœud et un retour en arrière au cours d'une seule tâche de copie.
Test de basculement 2 : Perte de réseau avec signal de présence intact
Le second scénario est plus subtil et sans doute plus fréquent en pratique : le nœud actif perd sa connexion réseau avec le client (panne de port de commutateur, câble débranché ou émetteur-récepteur défectueux), tandis que le nœud lui-même continue de fonctionner et que la liaison de pulsation reste active. C’est dans ce cas que la protection contre le split-brain est cruciale, car les deux nœuds sont opérationnels et peuvent communiquer entre eux, et le cluster doit déterminer quel nœud doit gérer l’adresse IP du cluster.
Nous avons répété la même copie de fichier Windows sur l'adresse IP du cluster et déconnecté l'interface réseau du cluster sur le nœud actif. Le transfert s'est interrompu pendant environ 45 secondes, le temps que le cluster déplace les services vers l'autre nœud, puis a repris sans incident. HA Manager a signalé précisément l'erreur, indiquant que l'adaptateur réseau 2 du cluster était déconnecté sur le nœud et suggérant de vérifier la connexion du commutateur. Il a ensuite précisé que le nœud déconnecté ne pouvait plus accéder au serveur de quorum via cette interface. Cette précision, mentionnant l'interface, le nœud et la conséquence exacts, est bien plus informative que le simple signalement de dégradation générique utilisé par certaines implémentations HA.
La reconnexion au réseau a réintégré le nœud au cluster, et le retour au cluster s'est effectué automatiquement en moins d'une minute : une brève pause d'environ 30 secondes, le temps que le rôle actif revienne à QNAP-HA1, a été le seul signe visible pour le client qu'un incident s'était produit. La même tâche de copie a résisté à deux basculements consécutifs sans qu'aucun fichier ne soit corrompu. Pour quiconque a déjà vu une session SMB s'interrompre pour bien moins que cela, c'est là le principal enseignement de cet exercice.
Déploiement optimal de la haute disponibilité : architecture split-brain et topologie réseau
Nos tests de basculement prouvent le bon fonctionnement du cluster, mais la fiabilité d'une paire HA en production dépend autant du réseau environnant que des unités NAS elles-mêmes. Les scénarios pour lesquels HA Manager est conçu (un nœud défaillant, un port de commutateur hors service, une liaison montante déconnectée) reposent tous sur une hypothèse : au moins un chemin de communication entre les deux nœuds reste opérationnel en cas de panne. Garantir cette hypothèse est la décision la plus importante lors du déploiement d'une solution HA, car l'alternative est précisément ce que toute architecture haute disponibilité cherche à éviter : le split-brain.
QNAP documente ce scénario. Le phénomène de « split-brain » survient lorsque deux nœuds perdent la communication entre eux tout en restant opérationnels indépendamment, chacun assumant le rôle actif. Deux nœuds, chacun se croyant propriétaire du cluster et disposé à accepter des écritures, constituent un terreau fertile pour l'incohérence des données ou la corruption du stockage, car chacun peut tenter de contrôler simultanément des ressources partagées. Les causes documentées sont conformes aux attentes : déconnexions réseau entre les nœuds, défaillances du signal de présence et instabilité des chemins réseau. Il est important de noter leur point commun : le « split-brain » n'est pas déclenché par la défaillance d'un seul nœud ; il survient lorsque tous les chemins entre deux nœuds sains tombent en panne simultanément. Il s'agit d'un problème de topologie, qui a une solution topologique.
Les règles de déploiement se déroulent comme prévu :
Établissez la liaison de signal de présence via un câble direct entre les deux nœuds. QNAP exige une liaison directe pour ce signal, et voici pourquoi. Sans commutateur, sans émetteur-récepteur et sans infrastructure partagée sur le chemin, seul un nœud peut interrompre le signal de présence ; c'est précisément le cas pour lequel le basculement est conçu. Dans un déploiement au sein d'une même baie, où ces unités TS-h765eU compactes sont généralement installées côte à côte, il n'y a aucune raison de procéder autrement.
Si les nœuds sont séparés, assurez-vous que le trafic de pulsation et le trafic client empruntent des chemins physiquement indépendants. Lorsqu'un câble direct est impossible, faites transiter le trafic de pulsation par des commutateurs différents de ceux utilisés pour la connexion au cluster. Dès que les deux connexions passent par le même commutateur, celui-ci devient un point de défaillance unique susceptible d'interrompre simultanément toutes les liaisons entre les nœuds, transformant une panne de commutateur classique en un potentiel incident de type « split-brain ». L'intérêt même d'acquérir deux unités NAS est compromis si un élément d'infrastructure partagée peut les isoler l'une de l'autre. C'est le principe de notre méthodologie de test de basculement réseau : débrancher le câble côté client tout en maintenant la connexion du trafic de pulsation simule la panne de commutateur ou de câblage qu'une topologie correctement séparée subirait réellement, le trafic de pulsation restant opérationnel pour assurer une transition fluide.
Activez le serveur de quorum. La troisième mesure de sécurité de QNAP consiste en un témoin sur le réseau, configurable dans High Availability Manager > Paramètres > Stratégie de basculement > Serveur de quorum. Si les nœuds perdent leur connexion directe mais restent accessibles au réseau, le serveur de quorum continue de les surveiller et de relayer leur état, offrant ainsi à chaque nœud un critère de départage indépendant avant de prendre la priorité. L'état de la connexion du serveur de quorum est affiché en permanence sur le tableau de bord de HA Manager, à côté du signal de présence, permettant ainsi de visualiser son état de fonctionnement en un coup d'œil.
Si le pire devait se produire, QuTS Hero gère le split-brain de manière défensive. Une fois la connectivité rétablie et les nœuds de nouveau opérationnels, ils échangent des informations d'état, reconnaissent que les deux nœuds ont occupé le rôle actif et arrêtent délibérément la plupart des services, notamment SMB et iSCSI, afin d'éviter la fusion de deux ensembles de données divergents. HA Manager propose alors un assistant de récupération après un split-brain avec deux options. La première option préserve les données sur un seul nœud sélectionné ; l'autre nœud est effacé, réinitialisé en tant que membre passif et resynchronisé. C'est la solution la plus rapide si vous savez quel nœud contient les données correctes. La seconde option préserve les données sur les deux nœuds en reprenant les services sur un nœud tout en retirant complètement l'autre du cluster, ce qui vous permet de vérifier et de réconcilier les données avant de les réintégrer manuellement. C'est un modèle de récupération raisonnable, mais la récupération implique tout de même une interruption de service et une resynchronisation complète. Le split-brain est une situation que l'on prévient dès la conception du déploiement, et non une situation dont on prévoit de se remettre. Les trois règles décrites ci-dessus ne coûtent rien d'autre qu'un câble et cinq minutes dans un panneau de configuration.
Suivi et gestion
Les opérations du deuxième jour sont gérées par l'application HA Manager, qui centralise l'état du cluster, l'utilisation des ressources par nœud, les journaux d'événements et la gestion des nœuds, y compris le basculement manuel, sur une interface unique. Lors de nos tests, les bannières d'avertissement du tableau de bord se sont révélées suffisamment précises pour permettre un diagnostic, en identifiant clairement l'interface et le nœud défaillants plutôt qu'en affichant un simple indicateur de dégradation.
QNAP a également intégré la haute disponibilité directement dans le matériel. Dans un cluster HA, l'écran LCD de chaque NAS affiche le nom du cluster, le rôle actuel du nœud et l'adresse IP du cluster. La LED d'état indique l'état de la haute disponibilité en un coup d'œil : verte fixe pour le nœud actif, verte clignotante pour le nœud passif et rouge fixe en cas d'erreur de haute disponibilité. Dans une baie composée d'unités compactes identiques, la possibilité d'identifier le nœud actif sans ouvrir de navigateur est un petit détail que les techniciens apprécieront. Pour les déploiements à grande échelle, AMIZcloud ajoute une supervision cloud centralisée des groupes HA, fournissant des informations sur l'état du cluster, la latence et les alertes sur l'ensemble des sites.
Réflexions finales
Le gestionnaire de haute disponibilité a parfaitement rempli sa promesse face aux deux types de pannes que nous lui avons fait subir. Une coupure de courant sur le nœud actif a entraîné une interruption d'environ 50 secondes de la copie de nos fichiers Windows, sans perte de fichiers ; une interruption de la connexion réseau d'un client a quant à elle provoqué une interruption d'environ 45 secondes. Dans les deux cas, la copie a ensuite pu reprendre sans encombre grâce à la restauration du nœud et au basculement automatique, avec une interruption maximale d'une seconde, inférieure à une minute. Les clients n'ont eu aucune intervention manuelle. Les applications, les partages de fichiers et les flux de travail des utilisateurs ont continué de fonctionner avec une seule adresse IP et un seul nom d'hôte avant, pendant et après le basculement. La configuration est également très simple : deux unités autonomes ont été transformées en un cluster de serveurs en moins de dix minutes grâce à l'assistant de configuration, auxquelles s'ajoutent dix minutes de synchronisation initiale. Le tableau de bord nous a indiqué précisément l'interface, le nœud et la connexion concernés à chaque incident.
L'ensemble du système HA : deux unités TS-h765eU et les disques IronWolf Pro qui les remplissaient.
Il ne faut toutefois pas négliger les coûts liés à la haute disponibilité. Tout est en double, et le nœud passif représente une capacité inutilisée jusqu'à sa mise en service. Les snapshots immuables, autre atout majeur de la version 6.0, ne sont plus disponibles au sein d'un cluster haute disponibilité ; les administrateurs doivent donc choisir entre les deux solutions. De plus, l'exigence d'un matériel identique implique que les mises à niveau s'effectuent par paires, ce qui peut impacter les budgets.
Au final, tout dépend du dimensionnement, et c'est aux petites entreprises et aux déploiements en périphérie de réseau que HA Manager excelle. Face aux baies d'entreprise à double contrôleur, une paire d'unités TS-h765eU compactes offre une tout autre perspective financière, tout en couvrant le scénario de panne (perte de contrôleur) qui motive la plupart des achats de baies à double contrôleur par les PME. Comparé aux solutions de réplication maison, à la distribution de snapshots, aux tâches rsync et à la sauvegarde-restauration, la différence réside dans le temps de récupération : ces solutions protègent les données, mais vous obligent à rétablir les connexions client pendant des heures, tandis que le pire incident visible côté client lors de nos tests avec HA Manager s'est limité à une pause d'une minute. Plus important encore, la panne qu'il ne peut absorber (la défaillance simultanée de tous les chemins inter-nœuds) est évitable grâce à un câble de présence direct, des chemins réseau séparés et un serveur de quorum activé : une configuration qui ne nécessite qu'un câble et cinq minutes de paramétrage.
Un dernier point spécifique à une architecture à deux nœuds : la période la plus critique du cluster est la resynchronisation, lorsque l’un des nœuds détient la seule copie valide de vos données et que les disques sous-jacents sont fortement sollicités. C’est pourquoi le choix des disques est crucial dans une configuration haute disponibilité, et c’est aussi pourquoi les disques NAS, comme les Seagate IronWolf Pro 30 To de notre configuration, sont plus importants ici que dans un système autonome : leur rôle est de garantir un fonctionnement optimal durant cette période.
Les routeurs QNAP TS-h765eU et QuTS hero h6.0 sont disponibles dès maintenant. Pour plus d'informations, consultez la page produit du QNAP TS-h765eU.
Ce rapport est commandité par QNAP. Tous les points de vue et opinions exprimés dans ce rapport sont fondés sur notre évaluation impartiale du ou des produits étudiés.
Amazon