Deployment Topologies FR

🇬🇧 English · 🇫🇷 Français

Topologies de déploiement

S'applique à Hydranos 4.4.

Cette page est pour vous si vous décidez comment organiser Hydranos : une instance, une instance avec plus de moteurs, ou plusieurs instances sur plusieurs machines. À la fin, vous saurez ce que chaque forme vous apporte, ce qu'elle ne vous apporte pas, comment joindre l'interface web depuis l'extérieur, et ce que le projet a mesuré pour un gros catalogue.

Chaque forme est construite à partir de la même brique : un processus hydranos avec son fichier de configuration, son store (base principale) et au moins deux moteurs. Il n'existe pas de « version contrôleur » ni de « version sans interface » ; un nœud est simplement une autre instance complète.

Une instance

C'est ce que vous donne toute installation : un processus, deux moteurs (race et hoard), une écoute HTTP sur le port 8199 pour l'interface web, l'API REST, le shim qBittorrent et le serveur MCP. Chaque moteur a son propre port d'écoute : 16171 (race) et 16172 (hoard), TCP pour les pairs et UDP pour l'uTP sur le même numéro. Le tableau complet des ports est sur Installation & premier démarrage.

flowchart LR
    users["Navigateur, Sonarr/Radarr, autobrr, scripts"] -->|"HTTP, port 8199"| api
    subgraph inst["instance hydranos"]
        api["écoute HTTP<br/>UI, /api, /api/v2, /mcp"]
        race["moteur race<br/>port 16171 TCP+UDP"]
        hoard["moteur hoard<br/>port 16172 TCP+UDP"]
        store[("store hydra.db")]
        api --> race
        api --> hoard
        api --> store
    end
    race <-->|"pairs"| swarm["Pairs BitTorrent"]
    hoard <-->|"pairs"| swarm
    race -->|"annonces"| trackers["Trackers"]
    hoard -->|"annonces"| trackers

Loading

Le Mode d'une catégorie décide dans lequel des deux moteurs atterrit un torrent (règle sur Catégories & routage) ; les différences de rôle sont sur Moteurs : race & hoard.

Une instance suffit quand :

• une seule machine contient les données que vous seedez, et
• une seule sortie réseau convient pour l'ensemble, et
• vous voulez que toutes les fonctions marchent : le shim, les workflows, MCP, les totaux de l'en-tête et chaque action du menu contextuel n'agissent jamais que sur l'instance où ils tournent.

Commencez ici. Passer plus tard à une autre forme ne demande pas de réinstaller.

Une instance, plus de moteurs

Vous pouvez ajouter des moteurs à côté de race et hoard dans le même processus : onglet Nodes › This node › + Add an engine (champs Id, Rôle (Role), Listen port, Interface), ou POST /api/engines. Dans les deux cas, Hydranos écrit un bloc engine (tableau de tables TOML) dans default.toml, et le moteur démarre au prochain redémarrage :

[[engine]]
name = "vpn1"
role = "hoard"
engine_id = "vpn1"
  [engine.session]
  listen_port = 16473
  bind_interface = "wg1"

Les raisons habituelles sont un port d'écoute séparé pour une partie du catalogue, ou une sortie réseau séparée pour ce moteur : une interface que vous avez montée vous-même (par exemple une interface WireGuard wg1, Linux uniquement), ou un tunnel qu'Hydranos monte pour lui en mode WireGuard, managed by Hydranos (WireGuard géré). Le champ Interface n'accepte qu'une interface dont /sys/class/net/<name>/operstate vaut exactement up ; les interfaces de tunnel signalent souvent unknown (constaté sur un périphérique tun ; non vérifié sur une interface wg-quick) et sont alors refusées avec no interface named … is up. Dans ce cas, écrivez le bloc ci-dessus à la main dans default.toml et redémarrez.

flowchart LR
    users["Navigateur, Sonarr/Radarr, scripts"] -->|"HTTP, port 8199"| api
    subgraph inst["instance hydranos (Linux)"]
        api["écoute HTTP"]
        race["moteur race<br/>sans interface"]
        hoard["moteur hoard<br/>sans interface"]
        vpn1["moteur vpn1, rôle hoard<br/>bind_interface = wg1"]
        daemon["requêtes propres du démon<br/>listes, vérification de mise à jour, webhooks"]
        api --> race
        api --> hoard
        api --> vpn1
    end
    vpn1 -->|"écoute, uTP, connexions sortantes, annonces,<br/>DHT, LSD, webseeds"| wg1["tunnel wg1"]
    race -->|"tout son trafic"| defroute["route par défaut"]
    hoard -->|"tout son trafic"| defroute
    daemon -->|"[daemon] egress, ici la route par défaut"| defroute

Loading

Ce que cela coûte et ce que cela ne vous apporte pas :

• Sous Linux, c'est une sortie séparée pour tout ce que fait le moteur. bind_interface épingle toutes les sockets du moteur : son écoute et son uTP, sa propre file de connexions sortantes, les annonces HTTP et UDP, la DHT, LSD, les webseeds et les scrapes. Si l'interface est absente, le moteur ne joint personne au lieu de se rabattre sur la route par défaut. Deux choses ne la suivent pas : les noms des trackers sont résolus par le résolveur de l'hôte quand l'interface n'est pas un tunnel créé par Hydranos, et les requêtes propres du démon (listes de trackers, listes du filtre IP, vérification de mise à jour, webhooks) sortent comme le dit [daemon] egress. Lisez VPN & sortie réseau avant de compter dessus.
• bind_interface est réservé à Linux. Sous Windows et macOS, l'API et l'onglet Réseau le refusent, et un moteur dont le fichier le contient encore reste hors du réseau. Détails sur Réseau : ports & redirection.
• Chaque moteur est une session BitTorrent complète (sa propre écoute des pairs, son port uTP, son nœud DHT s'il est activé, son planificateur d'annonces, son état de reprise sous <config dir>/<engine id>). Les moteurs supplémentaires héritent des réglages [race] ou [hoard] de leur rôle, puis appliquent leurs propres surcharges, sauf quatre clés qui n'existent qu'une fois par hôte ou par décision : listen_port_proxy_v2, gluetun_port_forward, wireguard_enabled et allow_direct. Un moteur supplémentaire ne les reçoit qu'en les nommant dans son propre bloc. Il hérite quand même du reste, y compris le proxy SOCKS5 et le bind_interface de son rôle : ce que le kill switch fait d'un nouveau moteur supplémentaire dépend donc du mode. En mode WireGuard, managed by Hydranos, il est tenu hors du réseau tant qu'on ne lui donne pas un tunnel ou Direct (interface par défaut) (Direct (default interface)). En modes Proxy SOCKS5 (SOCKS5 proxy) et Proxy SOCKS5 + relais PROXY-v2 (SOCKS5 + PROXY-v2 relay), il est couvert si son rôle a un proxy ou une interface (sinon il lui en faut un, ou allow_direct = true). En mode Gluetun, il est couvert sauf s'il hérite d'une autre interface que celle de gluetun.
• Les moteurs sont construits au démarrage : en ajouter ou en retirer un demande un redémarrage. Sous Docker, publiez vous-même le port du nouveau moteur (le compose livré ne publie que 16171 et 16172).
• Les catégories ne placent les torrents que dans race ou hoard. Pour en mettre un sur vpn1, utilisez Move to engine › local-vpn1 (ou Duplicate to engine ›) dans le menu contextuel, ou nommez le moteur via l'API REST (champ engine de POST /api/torrents/upload, ou POST /api/torrents/:info_hash/engine). Le groupe Node du menu contextuel apparaît dès que ce nœud a plus d'un moteur (toute installation par défaut a race et hoard) ou qu'un nœud est déclaré ; il liste les moteurs de ce nœud comme les nœuds déclarés. Voir Mettre des torrents sur un moteur supplémentaire sur Moteurs : race & hoard.
• La visibilité est presque complète : l'onglet Race liste tous les moteurs de rôle race et la liste Hoard tous les moteurs de rôle hoard, le shim qBittorrent liste les torrents de tous les moteurs locaux (chaque hash une fois), chaque moteur supplémentaire a sa carte Engine {id} sur Vue d'ensemble (Overview), ses courbes et ses cartes en direct sur Performances (Benchmark), ses lignes dans la santé des trackers et ses séries /metrics. Encore liés à race et hoard : la comparaison A / B, les cartes d'annonces hoard, Pic de sources actives (Peak live seeds) et la chronologie race. Voir Supervision & journaux et Limites connues de la 4.4.

Choisissez cette forme quand vous avez besoin d'un second port d'écoute ou d'une seconde sortie réseau sur la même machine et que vous pouvez piloter le placement depuis le menu contextuel ou l'API REST. Hors Linux, ou quand l'interface web, le shim et les requêtes propres du démon doivent eux aussi se trouver derrière cette sortie, faites plutôt tourner une seconde instance dans cette sortie (section suivante, ou Configuration 1 sur VPN & sortie réseau).

Plusieurs instances (nœuds)

Un nœud est une autre instance Hydranos complète que vous enrôlez (+ Enrol a machine) ou déclarez (+ Declare an existing one) dans l'onglet Nodes de l'instance que vous utilisez, que ce wiki appelle le contrôleur. Le contrôleur enregistre le nom, l'URL et la clé API du nœud dans son propre store et appelle l'API HTTP normale du nœud avec cette clé. La relation est à sens unique : le nœud n'appelle jamais l'API du contrôleur et n'a pas besoin de savoir qu'il existe.

flowchart LR
    browser["Navigateur"] -->|"HTTP, port 8199"| ctl
    subgraph ctlbox["instance contrôleur"]
        ctl["écoute HTTP"]
        cr["race"]
        ch["hoard"]
    end
    subgraph nabox["instance nœud A"]
        na["écoute HTTP"]
        nar["race"]
        nah["hoard"]
    end
    subgraph nbbox["instance nœud B"]
        nb["écoute HTTP"]
        nbr["race"]
        nbh["hoard"]
    end
    ctl -->|"HTTP + clé API du nœud A"| na
    ctl -->|"HTTP + clé API du nœud B"| nb
    ch <-.->|"BitTorrent, seulement pendant un handoff ou un rapatriement"| nah
    cr <-->|"pairs"| swarm["Pairs BitTorrent et trackers"]
    ch <--> swarm
    nar <--> swarm
    nah <--> swarm
    nbr <--> swarm
    nbh <--> swarm

Loading

Ce que vous y gagnez :

• Une seule liste Hoard pour toutes les machines. La liste Hoard du contrôleur fusionne les lignes de chaque nœud (un nœud qui ne répond pas en 4 s n'apporte rien à cette page ; la page est quand même servie). La colonne Emplacement (Location) indique où vit une ligne.
• L'état de santé d'un coup d'œil. L'onglet Nodes interroge chaque nœud en direct (version, moteurs, nombre de torrents, état) et Open vous emmène dans l'interface propre d'un nœud, déjà connecté.
• Handoff et rapatriement. Duplicate to engine › / Move to engine › poussent un torrent local vers le moteur d'un nœud (handoff, transfert vers un nœud) ; bring it here en rapatrie un depuis un nœud (fetch). Seul le .torrent transite par HTTP ; les données transitent en BitTorrent entre les moteurs des deux instances et sont vérifiées par hachage comme tout téléchargement.

Ce qui reste propre à chaque instance :

• L'ajout de torrents (onglet d'ajout, shim qBittorrent, dossiers surveillés, MCP) vise toujours l'instance à laquelle vous l'envoyez. Pointez Sonarr/Radarr vers l'instance qui doit détenir les données.
• Les catégories, les workflows, le shim qBittorrent, l'onglet Race et les totaux de l'en-tête sont locaux. Le serveur MCP est mi-figue mi-raisin : ses outils de lecture listent les lignes fusionnées de tous les nœuds, ses outils d'écriture n'agissent que sur les torrents locaux (Serveur MCP). Un handoff exige que la catégorie du torrent existe sur le nœud quand celui-ci a des catégories.
• La plupart des actions par torrent sur une ligne distante échouent depuis le contrôleur (arrêter/démarrer, réannonce, revérification, suppression, catégorie, tags ; le déplacement des données agit sur une copie locale). Gérez ces torrents sur le nœud lui-même avec Open. La matrice complète des actions est sur Nœuds & plusieurs machines.

Les nœuds sont des instances indépendantes. Si le contrôleur s'arrête, chaque nœud continue de seeder et d'annoncer de son côté ; si un nœud s'arrête, il manque simplement ses lignes dans les listes du contrôleur jusqu'à son retour.

Prérequis réseau :

• Le contrôleur doit joindre l'URL de chaque nœud (port 8199 par défaut). L'enrôlement écrit une URL http:// simple ; gardez ce trafic sur un réseau local ou dans un tunnel privé.
• Open redirige votre navigateur vers l'URL enregistrée du nœud : votre navigateur doit donc la joindre lui aussi.
• Pour un handoff, le nœud se connecte au port de moteur du contrôleur, à l'adresse d'où provenait la requête HTTP du contrôleur ; pour un rapatriement, le contrôleur se connecte au port de moteur du nœud. Ces ports de moteur doivent être joignables entre les machines.
• L'enrôlement (install.sh) est réservé à Linux. Une instance Windows ou macOS peut toujours être déclarée à la main.

Choisissez cette forme quand les données sont sur des machines différentes, ou quand vous voulez une instance avec une sortie réseau complètement différente (par exemple une instance entière dans un VPN), et que gérer les torrents de chaque nœud depuis sa propre interface vous convient.

Une sortie VPN par moteur

Sous Linux, un seul processus peut donner à chaque moteur sa propre sortie VPN en 4.4, de deux façons :

• Mode WireGuard, managed by Hydranos : envoyez un .conf de fournisseur par moteur, et Hydranos monte un tunnel wg-<engine> pour chacun, y épingle le moteur et demande au fournisseur son port entrant quand le fournisseur en propose un. Il faut la capacité NET_ADMIN. Voir WireGuard géré.
• Mode Direct avec une interface par moteur que vous montez vous-même (bind_interface, voir Une instance, plus de moteurs ci-dessus).

Dans les deux cas, tout le trafic de pairs et de trackers d'un moteur suit sa propre sortie. Le mode réseau est unique par instance : gluetun ne peut donc pas être la sortie d'un moteur à côté d'un tunnel géré ou d'un moteur en direct dans le même processus ; donnez à la sortie gluetun sa propre instance, comme ci-dessous. L'autre façon est une instance par sortie. Utilisez-la hors Linux, quand Hydranos ne peut pas avoir NET_ADMIN et que vous ne pouvez pas monter les interfaces vous-même, ou quand chaque sortie doit aussi porter sa propre interface web, son shim et les requêtes du démon. Faites tourner plusieurs instances Hydranos (plusieurs conteneurs, ou plusieurs services sur un même hôte), placez chacune entièrement dans son propre VPN (Configuration 1 sur VPN & sortie réseau, par exemple un conteneur gluetun par instance), et, si vous voulez une seule liste Hoard fusionnée, déclarez-les comme nœuds sur l'instance qui vous sert de contrôleur.

flowchart LR
    browser["Navigateur"] -->|"HTTP"| c1
    subgraph v1["Sortie VPN 1"]
        c1["instance 1 (contrôleur)<br/>race + hoard"]
    end
    subgraph v2["Sortie VPN 2"]
        n2["instance 2 (nœud)<br/>race + hoard"]
    end
    subgraph v3["Sortie VPN 3"]
        n3["instance 3 (nœud)<br/>race + hoard"]
    end
    c1 -.->|"facultatif : nœud déclaré, HTTP + clé API"| n2
    c1 -.->|"facultatif : nœud déclaré, HTTP + clé API"| n3
    c1 --> t1["trackers et pairs"]
    n2 --> t1
    n3 --> t1

Loading

Chaque instance a son propre dossier de configuration, son store, sa clé API et ses ports publiés (deux instances sur un même hôte ne peuvent pas publier toutes les deux 8199, 16171 et 16172). Le coût s'additionne par sortie : N sorties, c'est N shims qBittorrent à configurer dans Sonarr/Radarr/autobrr, N jeux de workflows et de catégories, N jeux de totaux d'en-tête et de statistiques de trackers, et des actions par torrent faites dans l'interface propre de chaque instance. Les nœuds déclarés du contrôleur ne traversent pas les tunnels à votre place : il doit pouvoir joindre le port 8199 de chaque nœud, ce qui, avec un conteneur VPN, veut généralement dire publier ce port côté hôte ou réseau local.

Accès à distance

Hydranos sert du HTTP simple sur le port 8199 et n'a pas de TLS propre. Pour le joindre depuis l'extérieur de votre réseau local, placez un proxy inverse (ou un VPN privé) devant le port 8199. À savoir :

• Créez le compte admin avant d'exposer quoi que ce soit. Tant qu'il n'existe pas, le premier appelant venant d'une adresse de boucle locale, privée ou lien-local peut s'approprier l'instance. Une adresse publique reçoit 403 quand elle joint Hydranos directement (ou via un proxy qui a lui-même une adresse publique), ou via un proxy dont le X-Forwarded-For commence par la vraie adresse du client (Hydranos lit la première entrée ; un proxy qui ajoute à un en-tête envoyé par le client laisse le client la choisir). Un reverse proxy sur une adresse privée qui n'envoie pas de X-Forwarded-For fait paraître local chaque appelant. Détails et modèle d'authentification complet sur Sécurité & accès.
• Servez Hydranos à la racine de son propre nom d'hôte (par exemple https://hydranos.example.org/). L'interface charge /static/… et appelle /api/… avec des chemins absolus : un sous-chemin comme /hydranos/ ne fonctionne pas.
• L'interface garde ouverts des flux server-sent events (/api/events, et /api/logs/stream pour l'onglet Journaux (Logs)) : désactivez la mise en tampon des réponses pour ces chemins dans votre proxy.
• Sonarr/Radarr, autobrr et les clients MCP utilisent la même écoute et la même clé API ; ils peuvent passer par le proxy ou rester sur l'adresse du réseau local.
• Si le proxy tourne sur le même hôte, cessez de publier 8199 sur toutes les interfaces. Sous Docker, publiez-le sur la boucle locale uniquement :

    ports:
      - "127.0.0.1:8199:8199"
      - "16171:16171/tcp"
      - "16171:16171/udp"
      - "16172:16172/tcp"
      - "16172:16172/udp"

Les ports des moteurs (16171, 16172 et le port de tout moteur supplémentaire) sont du BitTorrent, pas du HTTP : ne les mettez jamais derrière le proxy inverse.

Choisir

Votre situation	Forme	Pourquoi
Une machine, une sortie réseau	Une instance	Toutes les fonctions marchent ; rien à coordonner.
Une machine, besoin d'un port d'écoute ou d'une interface séparés pour une partie du catalogue (Linux)	Une instance, plus de moteurs	Même processus, même store ; placement depuis le menu contextuel ou l'API REST. L'interface porte tout le trafic de ce moteur.
Tout doit sortir par un VPN	Une instance dans le VPN, ou (Linux) un tunnel WireGuard géré pour chaque moteur	Une instance entière dans le tunnel couvre tout, requêtes propres du démon comprises (Configuration 1 sur VPN & sortie réseau). Des tunnels par moteur couvrent les moteurs ; le kill switch tient hors du réseau un moteur sans tunnel.
Une partie du catalogue doit sortir par un VPN, le reste depuis chez vous	Linux : une instance, un moteur supplémentaire sur l'interface ou le tunnel du VPN. Ailleurs : deux instances, une dans le VPN, déclarée comme nœud	Les annonces, la DHT et les connexions sortantes de chaque moteur (ou instance) suivent sa propre sortie.
Données sur plusieurs machines	Une instance par machine, déclarées comme nœuds	Les données restent où elles sont ; une seule liste Hoard fusionnée ; handoff/rapatriement entre machines.
Chaque moteur a besoin de sa propre sortie VPN	Linux : une instance, un tunnel WireGuard géré (ou une interface) par moteur. Ailleurs : une instance par sortie, éventuellement déclarées comme nœuds	Voir Une sortie VPN par moteur ci-dessus.
Vous avez besoin que Sonarr/Radarr, les workflows ou les actions MCP couvrent tout à la fois	Une instance (avec plus de moteurs si besoin)	Le shim et les workflows ne regardent jamais au-delà de l'instance ; les lectures MCP, si, les écritures MCP restent locales.

Dimensionnement

Tous les chiffres ci-dessous proviennent de la mesure du projet lui-même, docs/scale-290k.md : Hydranos 4.2, production, 21–24 septembre 2026, une machine, environ 293 000 torrents plus le moteur race, six vrais trackers. Le document les qualifie d'« exécutions uniques et séquentielles contre de vrais trackers : à lire comme des ordres de grandeur, pas des décimales ». Le document porte sur Hydranos 4.2 ; aucun chiffre 4.3 ou 4.4 n'est publié, et aucune mesure d'un catalogue plus grand n'a été publiée.

Mesure (Hydranos 4.2, 21–24 sept. 2026)	Valeur
Torrents	~293 000 + race
Démarrage à froid jusqu'à l'API	95–125 s
Mémoire résidente après chargement	2,8 GiB (environ 10 KiB par torrent)
CPU après chargement	3,4–3,7 cœurs (hoard + race), pour environ 5 TB envoyés par jour
Annonces par seconde	146–155

Le même document indique que « le chiffre qui compte le plus à cette taille est le rythme d'annonces » : un catalogue de 293 000 torrents avec un intervalle de 30 minutes « demande environ 163 annonces par seconde pour que chaque torrent reste visible de son tracker ». Les 146–155 par seconde mesurées sont un peu en dessous de ce chiffre ; le document ne dit pas si certains torrents ont été annoncés en retard, et aucun rythme soutenu plus élevé n'a été publié. Le rythme nécessaire à un catalogue croît proportionnellement à sa taille : considérez donc comme non testé tout ce qui dépasse nettement 293 000 torrents sur une instance ; rien de publié ne dit si la mémoire, le démarrage à froid ou le rythme d'annonces évoluent linéairement au-delà.

La phrase du README « Holding 290,000 torrents takes 2.8 GiB of RAM (about 10 KiB per torrent) » correspond à cette même mesure. Le README dit aussi qu'Hydranos « runs over a million torrents in a single instance in production today » ; aucun chiffre de mémoire, de démarrage, de rythme d'annonces ni d'arrêt n'est publié pour cette taille.

Un million de torrents : non mesuré. Rien de publié ne donne la mémoire, le démarrage à froid, la durée du vidage à l'arrêt ni le rythme d'annonces d'un catalogue de cette taille, d'un moteur supplémentaire ou d'un torrent détenu par deux moteurs. Ce que fixe le code : le rythme d'annonces nécessaire est publié par moteur sous hydra_announce_needed_per_second (il croît avec le catalogue et décroît avec des intervalles de tracker plus longs) ; le planificateur de chaque moteur autorise au plus 4096 annonces en vol (2048 par hôte de tracker), si bien que plusieurs moteurs ont chacun leur propre plafond ; le quota d'admission étale les premières annonces après un démarrage sur environ 30 minutes ; à un arrêt propre, seul ce qui part en 5 s reçoit son stopped. Surveillez hydra_announce_late, hydra_announce_needed_per_second face à rate(hydra_announces_total[5m]), et hydra_memory_resident_bytes (Métriques Prometheus) à mesure que le catalogue grandit.

Règles pratiques de dimensionnement (tirées du code, pas d'un banc d'essai) :

• Threads de travail. Le runtime utilise autant de threads de travail que la machine a de cœurs, plafonné à 32. Définissez HYDRANOS_WORKER_THREADS (un entier supérieur à 0) pour choisir un autre nombre, par exemple sur un hôte partagé. Voir Config : environnement, CLI & signaux.
• Gardez le dossier de configuration et le dossier de données sur un disque local, idéalement un SSD. Le store (hydra.db) et l'état de reprise de chaque moteur (state.db) sont des fichiers SQLite. Sur un système de fichiers réseau ou FUSE (NFS, SMB/CIFS, mergerfs, partages utilisateur Unraid), Hydranos n'utilise pas le mode WAL pour le store (journal de rollback à la place). Les données des torrents peuvent être où vous voulez. Les emplacements des fichiers sont sur Architecture.
• Descripteurs de fichiers. Le compose livré et packaging/hydranos.service fixent la limite de fichiers ouverts à 1048576 ; l'unité système qu'écrit install.sh la fixe à 1000000, et son unité par utilisateur n'en fixe aucune (elle relève la limite souple au niveau de la limite dure). Gardez une limite similaire si vous écrivez votre propre service.
• Croissance du journal. hydranos.log (à côté de default.toml) reçoit une ligne par connexion entrante de pair. Hydranos le fait tourner à 128 MiB et garde quatre anciens fichiers (hydranos.log.1 … .4) : prévoyez environ 640 MiB pour lui ; voir Supervision & journaux.
• Durée d'arrêt. Un gros catalogue a besoin de temps pour enregistrer les données de reprise à l'arrêt ; donnez au service ou au conteneur un délai d'arrêt suffisant. Aucune durée de vidage n'est publiée pour aucune taille de catalogue : lisez la vôtre dans le journal après un arrêt. Voir Exploiter Hydranos.

Étape suivante

• Installer la première instance : Installation & premier démarrage.
• Ajouter des moteurs : Moteurs : race & hoard.
• Ajouter des machines : Nœuds & plusieurs machines.
• Faire passer le trafic par un VPN : VPN & sortie réseau.