Configuration du basculement et du pool de secours : guide pratique

Un pool de secours est la différence entre un bref hoquet stratum et des heures de hashrate mort. Ce guide montre comment ordonner les pools primaire, secondaire et tertiaire, en quoi le basculement diffère de l’équilibrage par quota, quels choix de redondance respectueux des marques ont du sens, et exactement où le configurer sur le micrologiciel stock de Bitmain, BraiinsOS+ et AxeOS — plus comment repérer un basculement silencieux avant qu’il ne vous coûte cher.

Chaque mineur rencontre tôt ou tard un pool qui s’éteint. Un serveur stratum redémarre, un point d’accès régional tombe, un enregistrement DNS devient périmé, votre FAI a un hoquet, ou le pool planifie une maintenance au pire moment possible. Si votre rig pointe vers une seule URL, cet événement signifie zéro part acceptée jusqu’à ce que vous le remarquiez et interveniez. Un pool de secours correctement ordonné transforme le même événement en quelques secondes de reconnexion que vous pourriez même ne pas voir dans les chiffres quotidiens.

Ceci est un guide de configuration, pas de dépannage. Si votre basculement se comporte déjà mal — battant entre les pools, bouclant, ou ne revenant jamais — commencez par le diagnostic de boucle de bascule instantanée compagnon et revenez ici une fois le rig stable.

Pourquoi un seul pool est un point unique de défaillance

Stratum est une connexion TCP de longue durée. Quand cette connexion se rompt et ne peut être rétablie, le mineur n’a nulle part où envoyer du travail et vos hashboards continuent de brûler des watts en ne produisant rien de payable. Les pools sont remarquablement fiables, mais « fiable » n’est pas « jamais », et les modes de défaillance ne sont pas tous la faute du pool :

• Côté pool : maintenance de serveur, un événement DDoS, un nœud stratum surchargé, ou une région mise hors ligne.
• Côté réseau : votre FAI, un changement de routage, un commutateur capricieux, ou du Wi-Fi sur un appareil qui devrait être câblé.
• Côté config : un nom d’hôte de point d’accès expiré ou changé, une faute de frappe, ou un nom de worker que le pool ne reconnaît plus.

Un pool de secours couvre proprement les deux premiers et vous gagne du temps sur le troisième. Le coût est de quelques minutes de configuration. Le protocole lui-même est bâti pour cela : Stratum définit même un message client.reconnect qu’un pool peut envoyer pour migrer un mineur gracieusement, mais le basculement est le filet de sécurité pour quand le pool ne peut rien dire du tout. Pour les mécaniques de protocole plus profondes, voyez l’entrée du glossaire Stratum.

Comment fonctionne réellement le basculement

Le modèle standard est une liste ordonnée d’emplacements de pool, essayés de haut en bas :

• Primaire (Pool 1) : où vous voulez que chaque part aille en conditions normales.
• Secondaire (Pool 2) : un secours réellement indépendant — idéalement un opérateur de pool différent, ou au minimum un point d’accès stratum différent.
• Tertiaire (Pool 3) : un dernier recours. Beaucoup d’opérateurs le règlent sur une région différente du primaire, ou sur un point d’accès solo qui gardera le matériel occupé quoi qu’il arrive.

Quand la connexion primaire tombe et que les tentatives de reconnexion échouent, le mineur descend la liste vers le prochain pool vivant et y reprend le hachage. Le comportement qui surprend les gens est le retour (failback) — le mineur revient-il au primaire une fois qu’il récupère. Cela dépend du micrologiciel et de la version, alors traitez-le comme quelque chose à vérifier sur votre build exact plutôt qu’à supposer :

• Certains micrologiciels re-sondent périodiquement le primaire et y reviennent automatiquement quand il revient.
• Les builds stock de Bitmain ont historiquement tendance à rester sur le secours fonctionnel jusqu’à ce que le mineur soit redémarré ou repointé manuellement. Si le retour au primaire vous importe, vérifiez le mineur après toute panne.

Une astuce propre : faire du Pool 2 une copie identique du Pool 1 (même pool, mêmes identifiants, peut-être un nom d’hôte régional différent) garantit que le rig reprend sur le pool voulu après un pépin d’un seul point d’accès, et n’escalade vers un opérateur vraiment différent qu’au Pool 3.

Mode basculement vs mode quota / équilibrage de charge

Il vaut la peine d’être précis, car les deux sont souvent confondus. Le basculement envoie 100 % de votre hashrate au pool de plus haute priorité qui est vivant, et n’utilise les autres que lorsque celui-là est en panne. L’équilibrage de charge (parfois appelé mode quota ou de distribution de hash) répartit délibérément votre hashrate entre plusieurs pools en même temps, selon des poids que vous fixez.

Pour l’écrasante majorité des lecteurs, vous voulez le basculement pur. L’équilibrage de charge ne gagne sa place que si vous diversifiez intentionnellement quel pool trouve vos blocs, et il complique la surveillance parce qu’« une partie » de votre hashrate sur un pool est plus difficile à alarmer que « tout ou rien ». Gardez ça simple sauf raison précise du contraire.

Choisir des pools de secours respectueux des marques

Un secours n’est utile que s’il est réellement indépendant du primaire. Mettre deux points d’accès du même pool dans les trois emplacements vous protège d’un serveur unique qui meurt, mais pas de cet opérateur ayant une mauvaise journée. L’écosystème du minage Bitcoin vous donne plusieurs options bien considérées et résistantes à la censure à combiner — chacune bâtie sur les épaules des opérateurs et développeurs qui l’ont précédée. Vérifiez les points d’accès actuels dans la documentation de chaque projet avant de déployer ; les ports et noms d’hôtes changent.

Quelques notes qui comptent quand ceux-ci deviennent votre secours, pas votre primaire :

• Les modèles de récompense diffèrent. Un pool partagé paie des récompenses régulières et lissées ; un pool solo ne paie rien jusqu’à ce que vous trouviez (improbablement) un bloc entier, puis tout. Si votre secours est un point d’accès solo, comprenez qu’un long séjour dessus signifie une longue période de zéro paiement même si le matériel « travaille ». C’est souvent un compromis acceptable pour ne jamais s’éteindre complètement — allez-y juste les yeux ouverts.
• Les identifiants diffèrent. Les points d’accès solo (CKPool, Public Pool) prennent votre adresse BTC en chaîne comme nom d’utilisateur. Les pools partagés (Braiins, OCEAN) peuvent prendre un nom de compte de pool. Un emplacement de secours rempli du mauvais format de nom d’utilisateur mine silencieusement nulle part d’utile. Testez-le.
• L’auto-hébergement est le secours le plus solide. Public Pool est open-source et tourne contre votre propre nœud — une instance auto-hébergée sur votre réseau local est à peu près le tertiaire le plus résilient et souverain que vous puissiez bâtir, parce qu’il ne dépend de la disponibilité de personne d’autre. Voyez le guide du minage solo pour le portrait plus large.

Pour une comparaison structurée des opérateurs, frais et politiques, la comparaison des pools de minage et le pôle des pools de minage plus large sont les bons points de départ.

Configurer le basculement selon le micrologiciel

Le concept est universel ; les noms de champs et le nombre d’emplacements ne le sont pas. Entrez toujours les mêmes identifiants de paiement corrects dans chaque emplacement, puis enregistrez et redémarrez si le micrologiciel le demande. Les trois configurations sanctionnées ci-dessous couvrent la grande majorité du matériel de classe Antminer et la famille Bitaxe open-source.

Micrologiciel stock de Bitmain

L’interface web Antminer vous donne trois emplacements de pool — Pool 1, Pool 2, Pool 3 — chacun avec un champ URL, worker et mot de passe. Entrez votre primaire dans le Pool 1 et des secours indépendants dans les Pool 2 et Pool 3. Ces emplacements sont strictement de basculement : le mineur utilise le pool vivant de plus haute priorité et ne répartit pas le hashrate. Entrez l’hôte comme le pool le documente ; la plupart des builds Bitmain acceptent soit un host:port nu, soit un préfixe stratum+tcp://. Après avoir enregistré, ouvrez la page de statut du mineur et confirmez que le Pool 1 s’affiche comme Alive (vivant) avec un compte de parts acceptées non nul. Souvenez-vous de la mise en garde sur le retour ci-dessus : après une panne, vérifiez que le rig est revenu au Pool 1 plutôt que de camper sur le Pool 2.

BraiinsOS+

BraiinsOS+ (la lignée successeure de la pile de minage Braiins/Slush originale) est plus capable ici. Il organise les pools en groupes de pools. Au sein d’un même groupe, les pools listés se comportent en basculement ordonné — exactement le modèle primaire/secondaire/tertiaire. Entre plusieurs groupes, vous pouvez assigner un quota à chaque groupe pour répartir le hashrate (équilibrage de charge). Pour une redondance simple, utilisez un groupe contenant votre primaire et vos secours par ordre de priorité et ignorez entièrement les quotas. BraiinsOS+ prend en charge Stratum V1 (stratum+tcp://) et Stratum V2 (stratum2+tcp://host:3336/<public-key>, où la clé publique authentifie le point d’accès et bloque le détournement de hashrate). Un motif pragmatique du début de la V2 est un primaire V2 avec un point d’accès V1 comme tertiaire, pour qu’un problème propre à la V2 ne vous fasse jamais tomber à zéro. Tirez le point d’accès et la clé V2 actuels de la documentation de Braiins au moment du déploiement — ils publient maintenant une seule URL globale géo-routée plutôt que des noms d’hôtes régionaux. Pour le contexte du protocole, voyez notre explication de Stratum V2, et comparez les capacités sur la matrice des fonctionnalités de micrologiciels.

AxeOS (Bitaxe)

AxeOS — le micrologiciel open-source de la communauté Bitaxe — expose une config stratum primaire plus une config stratum de secours. Dans l’interface web, vous remplissez Stratum Host, Stratum Port et Stratum User pour le primaire, et les Fallback Stratum Host / Port / User correspondants pour le secours. Entrez l’hôte sans le préfixe stratum+tcp://. Si le primaire devient injoignable (les builds communautaires basculent typiquement après quelques tentatives échouées), AxeOS passe au secours automatiquement et réessaie périodiquement le primaire, y revenant quand il revient. Parce qu’un Bitaxe fait habituellement du minage solo, un appariement sensé est un pool solo comme primaire et un second point d’accès solo indépendant comme secours pour qu’un bloc reste possible sur l’un ou l’autre.

D’autres micrologiciels du paysage (comme VNish, LuxOS ou les builds ePIC) implémentent aussi leur propre basculement ; les principes de ce guide se reportent, mais configurez toujours selon la documentation actuelle de ce micrologiciel.

Redondance géographique et de point d’accès

Le basculement n’est aussi indépendant que les points d’accès que vous choisissez. Pointer les trois emplacements vers la même région physique défait l’objectif si c’est cette région qui tombe. La plupart des pools sérieux publient plusieurs points d’accès stratum géographiques — par exemple CKPool offre des noms d’hôtes régionaux comme eusolo.ckpool.org, sgsolo.ckpool.org et ausolo.ckpool.org à côté du défaut. Utilisez-les délibérément :

• Primaire : le point d’accès géographiquement le plus proche de votre hashcenter, pour la plus faible latence stratum et le moins de parts périmées.
• Secondaire : une seconde région du même pool, ou un opérateur différent à proximité.
• Tertiaire : un secours lointain ou une instance auto-hébergée qui ne partage pas d’infrastructure avec les deux premiers.

Surveillez la latence quand vous basculez vers une région lointaine : un temps d’aller-retour plus élevé augmente votre taux de parts périmées/rejetées, rognant discrètement le hashrate effectif même si le mineur rapporte « connecté ». Acceptable comme secours temporaire ; un mauvais foyer permanent.

Détecter un basculement silencieux

Le piège d’un bon basculement est qu’il fonctionne trop discrètement. Votre rig continue de hacher, les voyants restent verts, et vous ne réalisez jamais que vous avez passé trois jours sur un pool de secours — possiblement un point d’accès solo au profil de paiement très différent, ou un emplacement avec un nom de worker périmé. Bâtissez une habitude et un signal pour que le basculement soit quelque chose que vous observez, pas quelque chose que vous découvrez le jour du paiement.

• Vérifiez quel pool est actif, pas seulement qu’il y en a un. Les pages de statut stock Bitmain marquent chaque pool Alive ou Dead et montrent les parts acceptées par pool. AxeOS montre le pool connecté dans son tableau de bord. BraiinsOS+ montre le pool actif et expose des métriques à récolter.
• Interrogez l’API du mineur. La plupart des micrologiciels de classe Antminer répondent à la commande API de style cgminer pools, qui rapporte le statut de chaque pool et lequel est « Stratum Active ». AxeOS sert un point de terminaison JSON d’info système. Un petit script qui lit ceci sur un horaire et alerte quand le pool actif n’est pas le Pool 1 attrape un basculement silencieux en quelques minutes.
• Utilisez les alertes de worker côté pool. La plupart des pools peuvent vous envoyer un courriel ou un message quand un worker se déconnecte. Activez cela sur votre primaire — si le primaire perd votre worker mais que le matériel tourne manifestement encore, vous avez basculé sans le savoir.
• Surveillez les tableaux de bord de hashrate par pool. Une chute à zéro sur le tableau de bord du primaire tandis que votre rig local rapporte encore le plein hashrate est la signature indubitable d’un basculement en direct.

Enfin, testez le basculement avant de vous y fier. Cassez temporairement le primaire (bloquez son port à votre pare-feu, ou réglez un port primaire intentionnellement erroné) et confirmez que le rig atterrit sur le secours, avec votre adresse correcte, produisant des parts acceptées — puis rétablissez le primaire et confirmez le comportement de retour sur votre micrologiciel précis. Un pool de secours que vous n’avez jamais exercé est un espoir, pas un plan. Gardez vos habitudes de surveillance affûtées, et si un basculement révèle jamais une panne matérielle sur une carte, les ressources de réparation ASIC sont l’étape suivante.

Un ordre par défaut sensé

Si vous voulez simplement une recette éprouvée, ceci couvre la plupart des montages domestiques et de petit hashcenter :

1. Pool 1 (primaire) : votre pool choisi, le point d’accès régional le plus proche, les identifiants corrects.
2. Pool 2 (secondaire) : le même pool, un point d’accès régional différent — survit à une panne de serveur unique et reprend sur l’opérateur voulu.
3. Pool 3 (tertiaire) : un opérateur entièrement indépendant, ou un point d’accès solo auto-hébergé, pour que le matériel ne reste jamais complètement inactif.

Réglez-le, testez-le, alarmez dessus. Puis oubliez-le — ce qui est exactement le but.

Foire aux questions

Combien de pools de secours devrais-je configurer ?

Au moins un, idéalement deux. Deux pools (primaire plus un secours indépendant) couvrent le cas courant d’un opérateur ou point d’accès unique qui tombe. Un troisième emplacement — une région différente ou un point d’accès solo auto-hébergé — est une assurance bon marché contre une mauvaise journée à vos deux premiers choix. Stock Bitmain et BraiinsOS+ vous donnent trois emplacements ou plus ; AxeOS vous donne un primaire plus un secours.

Mon mineur revient-il automatiquement au pool primaire ?

Cela dépend du micrologiciel et de la version. AxeOS réessaie périodiquement le primaire et y revient quand il récupère. Les builds stock de Bitmain restent souvent sur le secours fonctionnel jusqu’à ce que le mineur soit redémarré ou repointé manuellement. Ne supposez pas — testez une panne sur votre micrologiciel exact et observez ce qu’il fait, puis bâtissez une alerte de surveillance pour savoir quel pool est actif.

Configurer un pool de secours est-il la même chose que l’équilibrage de charge ?

Non. Le basculement envoie tout votre hashrate au pool de plus haute priorité qui est en ligne et n’utilise les secours que lorsqu’il est en panne. L’équilibrage de charge (mode quota, disponible sur BraiinsOS+ entre groupes de pools) répartit délibérément le hashrate entre plusieurs pools à la fois. Pour une pure redondance, vous voulez le basculement, pas l’équilibrage — il est plus simple à exploiter et bien plus facile à surveiller.

Puis-je mélanger un pool solo et un pool partagé dans ma liste de basculement ?

Oui, et c’est un motif courant — mais comprenez la différence de paiement. Un pool partagé paie des récompenses lissées et fréquentes ; un point d’accès solo ne paie rien jusqu’à ce que vous trouviez un bloc entier. Un long séjour sur un secours solo signifie une longue période de zéro paiement même si le matériel est occupé. Confirmez aussi que le format de nom d’utilisateur correspond à chaque pool (adresse BTC en chaîne pour le solo, nom de compte pour beaucoup de pools partagés).

Pourquoi mon hashrate a-t-il chuté après avoir basculé vers un pool de secours ?

Presque toujours la latence. Un secours dans une région géographique lointaine a un temps d’aller-retour plus élevé, ce qui augmente les parts périmées et rejetées et rogne le hashrate effectif même si le mineur affiche « connecté ». C’est correct comme secours temporaire ; choisissez le point d’accès le plus proche comme primaire et n’utilisez les régions lointaines que comme secours plus profonds.

Comment savoir si mon rig a basculé silencieusement ?

Vérifiez quel pool est actif, pas seulement qu’il y en a un. Lisez la page de statut du mineur ou son API (la commande de style cgminer pools, ou le point de terminaison JSON d’AxeOS), activez les alertes de worker hors ligne sur votre pool primaire, et surveillez le tableau de bord de hashrate du primaire pour une chute inexpliquée à zéro tandis que votre rig local rapporte encore le plein hashrate. N’importe lequel de ceux-ci est la signature d’un basculement en direct.

The Bitaxe 184.99 $  –  224.99 $Plage de prix : 184.99 $ à 224.99 $ CAD

Acheter le Bitaxe →