Connexion
Abonnez-vous

QNAP lance la haute disponibilité, en bêta

Le 02 mai à 13h58

La fonction était attendue depuis longtemps, elle est enfin là, en bêta, via l’application High Availability Manager. Le fonctionnement est classique pour ce genre de service. Un tuto a aussi été mis en ligne.

Actif-passif sur deux NAS identiques (avec 8 Go minimum)

Il faut commencer par créer un cluster HA (High Availability ou Haute disponibilité) avec deux NAS QNAP : un actif et l'autre passif. « Si une panne ou un problème inattendu avec le serveur actif se déclare, le serveur passif fournit une protection immédiate avec basculement automatique ».

Il y a plusieurs restrictions. Tout d’abord, les NAS « doivent être identiques », avec au moins 8 Go de mémoire. Ensuite, il faut disposer de QuTS hero h5.3 minimum sur les deux NAS. Le fabricant annonce que « le serveur de secours (Passif) prend automatiquement en charge tous les services en une minute (RTO < 60 secondes) ».

Heartbeat à la manœuvre

Pour surveiller la connexion, QNAP utilise le logiciel Heartbeat. « Heartbeat est un sous-système d'échange de messages liés à la haute disponibilité, qui met en œuvre des contrôles "battements de cœur" par UDP, port série et PPP/UDP. C'est l'une des couches d'échange de messages gérées par le gestionnaire de ressource de grappe Pacemaker », rappelle Debian.

Attention, certaines fonctionnalités de QuTS hero ne sont pas encore prises en charge, comme indiqué sur cette page. Une liste des applications compatibles se trouve par là.

Voici enfin la liste des NAS compatibles : TVS-h874(T), TVS-h674(T), VS-h474, TBS-h574TX, TS-h3077AFU, TS-h1677AXU-RP, TS-h1277AXU-RP, TS-h1277AFX, TS-h3087XU-RP, TS-h2287XU-RP, TS-h1887XU-RP, TS-h987XU-RP, TVS-h1688X, TVS-h1288X, TDS-h2489FU (R2), TS-h2490FU, TS-h1090FU, TS-h1290FX, TVS-675, TS-h1886XU-RP R2 et TS-h886.

Le 02 mai à 13h58

Commentaires (14)

votre avatar
Sympaaaaa :)
votre avatar
Faut des disques certifiés QNAP pour que ça fonctionne ? :-D
votre avatar
un heartbeat en UDP me semble bizarre car on veut qu'il arrive correctement vu que sinon l'autre machine prends le relai mais on ne veut pas switcher si le message s'est perdu ou arrive incorrect donc il faudrait plutôt du TCP ou autre mais pas UDP non ?
votre avatar
Généralement, dans ce genre d'approche, les "battements" sont générés à intervalle régulier (par ex. toutes les 2s) par le système surveillé.

Ensuite, le système qui surveille se déclenche non pas au premier battement qui manque, mais au bout d'un certain temps sans battement (par ex. 1min, soit 30 battements manquant d'affilé dans mon exemple).

Qui plus est, rien n'indique que le protocole utilisé par heartbeat n'implémente pas son propre protocole de vérification d'intégrité. On peut tout à fait le faire en UDP, c'est juste qu'il faut le faire soi-même au niveau applicatif au lieu de se reposer sur le protocole réseau lui-même.
votre avatar
pourquoi ne pas utiliser le bon protocole réseau de base et réinventer la semoule au risque de faire des failles de sécurité avec un truc maison ?
votre avatar
Dans l’article rien n’indique qu’ils font un truc maison.
Le mode tcp pourrait justement masquer des erreurs réseaux sur l’un des NAS et ne pas déclencher de bascule alors que cela pourrait être favorable.

Je ne sais ce qu’il en est dans le cas de QNAP mais généralement il est conseillé d’utiliser des interfaces réseaux dédiées et une connexion directe entre les NAS.

Comme déjà dis les bascules se déclenchent normalement sur un certain nombre d’erreurs dans une plage définie. La bascules peut être déclenchée sur un plantage du NAS mais aussi sur des pb réseaux suffisamment importants (et manuellement pour de la maintenance )

UDP a aussi l’avantage d’être plus léger et rapide.

UDP me semble plutôt un bon choix du coup
votre avatar
Pourquoi n'est-ce pas un bon protocole ? Est-ce que la perte d'un paquet est préjudiciable ? Non. Il faut la rupture de toute communication pendant un certains temps.

Est-ce que la charge utile doit être protégée contre la correction ? Pas certain. La charge utile, c'est la présence même du message, pas le contenu du message en lui-même.
votre avatar
J'ajouterai que quand on parle de monitoring, on ne déclenche pas l'alerte ou le failover à la première erreur trouvée mais après confirmation de celle-ci. L'UDP est d'ailleurs assez fréquent dans le domaine des heartbeats basiques.

À ne pas confondre avec des messages de supervision type événementiel où là, la payload est utile.
votre avatar
pourquoi ne pas utiliser le bon protocole réseau de base et réinventer la semoule au risque de faire des failles de sécurité avec un truc maison ?
En l'occurrence, UDP c'est le "bon" protocole pour ce type d'utilisation comparé à TCP.

Quel intérêt d'établir une session TCP permanente ? Que faire quand elle se coupe ?
Quel intérêt d'établir/couper une session TCP à chaque heartbeat ?
Quel intérêt de laisser TCP tenter de réémettre un heartbeat qui n'a pas été délivré ?
etc.
votre avatar
sans avoir toutes les info du protocoles c'est dur de dire. S'il envoie 1 heartbeat toutes les min alors la perte du heartbeat démarre le second server.
Un hacker peut s'en servir facilement pour empêcher le démarrage du 2nd server et ddos le 1er etc. il y a plein de possibilités.
votre avatar
En UDP entre deux serveurs côte à côte sans routeur entre les deux, tu as environ 0.00% de taux de perte. TCP tourne au dessus d’IP (avec pertes) + timeout ; si tu fais ton protocole sur UDP avec un timeout, c’est équivalent.
votre avatar
Qnap a t'il réinventé le clustering ?
(Facilement administrable avec Webmin depuis des années) :-/
votre avatar
Quelque chose m'échape.
Il faut que les 2 QNAP restent dans le même réseau local ou bien ça peut se faire entre 2 sites distants via internet ?
votre avatar
Au vu de la procédure et des prérequis réseau, c'est pour du LAN.

QNAP lance la haute disponibilité, en bêta

  • Actif-passif sur deux NAS identiques (avec 8 Go minimum)

  • Heartbeat à la manœuvre

Fermer