Lunanode Hosting Inc. vend une capacité hébergée qui dépend toujours des baies, du transit et des fenêtres de réparation

Résumé

• Lunanode est visiblement opérationnel: son site actuel propose des machines virtuelles et du stockage à Toronto, sa page de statut consigne les incidents et les maintenances jusqu'en 2026, et AS394745 reste annoncé avec de l'espace IPv4 et IPv6 visible dans les données de routage publiques.
• L'empreinte de calcul active semble concentrée à Toronto. Lunanode a fermé Montréal et Roubaix en 2023 après des augmentations substantielles des coûts des centres de données, tandis que certains exemples d'API plus anciens listent encore les trois régions et ne doivent pas être interprétés comme une capacité actuelle.
• La résilience est disponible en couches, pas comme une propriété automatique. Les volumes, les instantanés, les adresses IP flottantes, les équilibreurs de charge, les contrôles d'affinité et les images téléchargeables aident les clients à concevoir la reprise, mais la plupart de ces contrôles restent à l'intérieur du même domaine de défaillance de Toronto, sauf si le client conserve une copie indépendante ailleurs.
• Le niveau de preuve est Moyen. Lunanode publie des détails d'incidents exceptionnellement utiles et expose des enregistrements réseau crédibles, mais ne divulgue pas publiquement le nombre de baies, la puissance utilisable, la capacité de calcul totale installée, la topologie de stockage actuelle, les objectifs de réparation contractuels, la profondeur du matériel de rechange ou une deuxième région de calcul active.

Un panneau de contrôle cloud ne supprime pas l'espace physique derrière

L'offre de Lunanode est manifestement un service cloud plutôt qu'un simple serveur loué avec un identifiant. Lapage à proposde l'entreprise décrit une plateforme basée sur OpenStack et KVM, avec des machines virtuelles, des volumes de blocs, des instantanés en direct, des adresses IP flottantes, des réseaux virtuels, des scripts de démarrage, une surveillance et une API. Sapage de machines virtuellesdivise le service en plans généralistes, optimisés pour la mémoire et optimisés pour le calcul, et précise que les instances sont facturées à l'heure. Un client peut créer, redimensionner, mettre en veille, réinstaller, secourir et supprimer des machines sans attendre une commande de serveur physique.

Cette abstraction est réelle et précieuse. Elle permet à une petite entreprise de logiciels de louer une fraction de serveur, à un administrateur de convertir un achat en capital en dépense d'exploitation, et à un projet de libérer des ressources informatiques lorsqu'elles ne sont plus nécessaires. Elle rend également la dépendance physique facile à négliger. Chaque cœur virtuel correspond à un socket de processeur dans un châssis particulier. Chaque disque local correspond à des disques et à un contrôleur. Chaque volume de blocs dépend des nœuds de stockage et du réseau qui les relie.

Chaque adresse publique dépend d'une route, d'un périphérique de bordure, d'un amont et de l'alimentation électrique de l'installation. Chaque réparation dépend d'une personne, d'une pièce de rechange et d'un accès à la baie.

Le propre dossier public de Lunanode rend cette chaîne particulièrement concrète. Lapage des emplacementsactuelle nomme Toronto, indique que le déploiement se trouve dans l'installation Cogent de Toronto, et décrit un réseau de 10 gigabits par seconde, des liaisons montantes et des systèmes d'alimentation redondants. Elle nomme des processeurs Intel Xeon E5-2690 v2 doubles et du SSD RAID10 sur les nœuds hôtes SSD. Lapage d'infrastructureassociée indique que les clients peuvent choisir entre des disques SSD locaux ou un stockage par blocs distribué, et que les VM dans la même région communiquent sur un réseau privé de 10 gigabits par seconde.

Ces déclarations identifient le type de machinerie sous le service. Elles ne divulguent pas quelle quantité est installée, combien est libre, combien de baies elle occupe, combien d'énergie est réservée, combien de générations d'hôtes restent en service, ou si chaque charge de travail reçoit le même chemin de stockage et réseau. Le processeur nommé sur la page des emplacements date d'une génération de serveur antérieure. Cela ne le rend pas inutilisable; un matériel ancien fiable peut être économiquement raisonnable pour un hébergement à bas coût.

Cela signifie toutefois qu'un acheteur doit distinguer un type d'hôte clairement spécifié d'une flotte continuellement renouvelée.

Le cloud, dans ce cas, est une interface opérationnelle utile sur un déploiement fini à Toronto. Lunanode contrôle sa plateforme client, l'ordonnancement des VM, le service de stockage, la configuration réseau et les décisions de support. Cogent contrôle d'importantes conditions d'installation et d'amont. Les fournisseurs de matériel déterminent la disponibilité des pièces. Le client contrôle l'architecture applicative, les sauvegardes indépendantes et la décision de maintenir une capacité ailleurs. La fiabilité émerge de ces quatre limites, pas seulement du panneau de contrôle.

Toronto est le centre de gravité opérationnel actuel

Le fait le plus important dans l'histoire d'infrastructure actuelle de Lunanode est la concentration géographique. Les pages marketing actuelles indiquent que la plateforme cloud se trouve à Toronto. Plus décisif encore, ladocumentation de l'API de machines virtuellesprécise que le paramètre de région pour la création de VM doit êtretoronto. La documentation actuelle des groupes de sécurité indique également qu'un nouveau groupe doit être dans la région Toronto. Ce sont des signaux actuels plus forts qu'une ancienne liste de noms de lieux, car ils décrivent ce que l'interface de provisionnement accepte maintenant.

D'autres pages de Lunanode conservent des traces historiques. Lapage API des plans et régionsinclut un exemple de réponse avec Montréal, Roubaix et Toronto. Lapage API des réseaux virtuelsmontre également ces trois noms. La page des instantanés décrit toujours la réplication entre emplacements cloud. Aucune de ces pages, en soi, n'établit que les clients peuvent provisionner de nouvelles capacités de production à Montréal ou Roubaix en juillet 2026.

L'historique des statutsde Lunanode résout l'apparent conflit. Début 2023, l'entreprise a annoncé qu'elle abandonnait Montréal et Roubaix en raison d'augmentations substantielles des coûts imposées par les centres de données qu'elle y utilisait. Les clients ont été invités à migrer les machines virtuelles et les volumes attachés vers Toronto avant le 31 janvier 2023, à demander de l'aide, ou à demander un remboursement si Toronto ne convenait pas. Une entrée ultérieure indiquait que les VM restantes dans les deux emplacements fermés seraient migrées vers Toronto. Les pages de service actuelles, uniquement sur Toronto, sont cohérentes avec cet historique; les exemples API à trois régions sont mieux traités comme une documentation obsolète.

La fermeture est plus qu'une note historique. Elle révèle un chemin de défaillance du contrat fournisseur. Lunanode n'a pas eu besoin d'un incendie, d'une inondation ou d'un effondrement technique pour perdre deux régions. Un intrant commercial a changé: les installations sont devenues sensiblement plus chères. L'entreprise a répondu en retirant la capacité et en consolidant les charges de travail.

C'est une décision commerciale rationnelle, mais elle illustre pourquoi une infrastructure louée n'est jamais indépendante des baux, des prix de l'énergie, des accords de transit et de l'économie de la mise à disposition d'une capacité sous-utilisée.

Pour les clients, l'effet dépend de l'architecture. Une application sans état avec automatisation de la configuration et une copie externe de ses données peut être déplacée. Une VM de longue durée avec disque local, une adresse fixe, des modifications logicielles non documentées et aucune restauration testée peut devenir un projet de migration. Un client européen qui avait choisi Roubaix pour la latence ou la proximité ne pouvait pas considérer Toronto comme un substitut équivalent. Un client montréalais pourrait rester au Canada mais faire face à une latence, un peering et une géographie de sinistre différents.

Le fournisseur a offert une assistance à la migration et des crédits, mais le client a tout de même supporté le travail au niveau de l'application et la décision de savoir si Toronto répondait à ses besoins.

Lunanode peut vendre et servir des clients dans de nombreux pays tout en opérant la plateforme de calcul visible dans une seule ville. La surface de vente mondiale et une infrastructure multi-région sont deux choses différentes.

Les prix bas sont produits par l'utilisation, la normalisation et les limites

L'attrait commercial de Lunanode est simple. Sapage de tarificationen direct liste de petites VM généralistes et orientées mémoire à partir de quelques dollars américains par mois, des configurations plus grandes, et des plans optimisés pour le calcul avec des cœurs dédiés. Elle tarifie le stockage par blocs et les instantanés au gigaoctet, les adresses publiques supplémentaires au mois et la bande passante excédentaire au gigaoctet. Le service peut donc convenir à des projets personnels, de petits sites Web, des systèmes de développement, des applications professionnelles modestes et des charges de travail qui ne justifient pas un contrat de grand cloud.

Le prix d'entrée bas n'est pas le coût d'une machine physique dédiée. C'est le prix d'une part dans un pool géré. Le fournisseur achète des serveurs, de l'espace en baie, des ports réseau, des adresses, des supports de stockage et du temps de personnel, puis répartit ces coûts fixes et semi-fixes entre les clients. La rentabilité dépend de l'occupation et de l'utilisation: assez de clients doivent payer pour la flotte installée, tandis que tous les clients ne peuvent pas exiger chaque ressource allouée à pleine intensité au même instant, sauf si le plan et la conception de capacité le permettent.

Lunanode rend certains de ces contrôles visibles. Les plans généralistes et mémoire utilisent des cœurs virtuels; les plans optimisés pour le calcul annoncent des cœurs dédiés. La bande passante est mutualisée par compte et par région, le trafic entrant et sortant étant comptabilisé. Lesconditions de serviceindiquent que la bande passante excédentaire est facturée et que les clients peuvent choisir d'éteindre les VM avant de dépasser leur pool. La mise en veille libère le CPU et la mémoire tout en conservant le stockage et les adresses à moindre coût. Ce ne sont pas de simples détails de facturation. Ce sont des mécanismes pour convertir un équipement fini en capacité vendable d'apparence élastique.

La capacité installée et la capacité utilisable ne sont donc pas les mêmes. Une baie peut contenir une somme nominale de cœurs de processeur et de téraoctets, mais une partie doit être réservée pour les frais généraux du système, la réplication du stockage, les dispositifs défaillants, la maintenance, le déséquilibre des hôtes et la marge de manœuvre client. Un serveur en attente comme pièce de rechange est installé mais ne génère pas de revenu normal. Une baie presque pleine peut encore avoir de l'espace unitaire nominal tout en manquant de marge de sécurité électrique.

Un cluster de stockage peut avoir de l'espace disque brut qui n'est pas disponible pour de nouvelles données client car les réserves de réplication et de récupération le consomment. Un lien de 10 gigabits est une vitesse de port, pas une garantie que chaque VM peut maintenir ce débit vers toutes les destinations.

Aucune page publique de Lunanode ne quantifie ces marges. La page de tarification en direct fournit un catalogue, pas un état des stocks. Le panneau de contrôle peut montrer la disponibilité du plan à un utilisateur authentifié, mais les documents publics ne disent pas combien d'instances de chaque type peuvent être créées, comment la capacité est répartie entre les hôtes, ou quel seuil déclenche un achat de matériel. Les acheteurs doivent donc considérer les prix comme des offres valides au moment de la commande, et non comme une preuve d'expansion illimitée.

Ce cadre économique explique également la contraction régionale de 2023. Un petit fournisseur peut offrir une capacité peu coûteuse car il évite les frais généraux d'un parc hyperscale. La même discipline peut rendre un emplacement peu utilisé ou devenu coûteux difficile à maintenir. Le calcul bon marché à l'heure et la géographie de rechange permanente tirent dans des directions opposées. Un client qui a besoin des deux doit payer pour une capacité indépendante et la tester, plutôt que de supposer que le prix de base de la VM inclut un site secondaire inactif.

La limite de l'installation est visible mais seulement partiellement décrite

Lunanode indique que son emplacement de Toronto se trouve dans une installation Cogent. Ses avis de statut identifier à plusieurs reprises Cogent comme le centre de données ou la partie amont impliquée dans les travaux réseau. Un avis de juin 2026 prévenait d'une possible indisponibilité du réseau pour des mises à niveau logicielles sur les routeurs de bordure effectuées par le centre de données. Un avis d'avril 2026 décrivait une maintenance similaire. Un incident de janvier 2026 indiquait que l'amont semblait effectuer une maintenance planifiée pendant que Lunanode enquêtait sur une interruption à Toronto.

Cette division des responsabilités est importante. Lunanode peut maintenir les serveurs et son propre équipement réseau, mais ne peut pas empêcher indépendamment une mise à niveau du routeur de bordure de l'installation ou restaurer un dispositif amont défaillant. En septembre 2024, Lunanode a signalé que ses serveurs et équipements réseau restaient sous tension et fonctionnels alors que la connectivité externe était hors ligne en raison d'un problème d'alimentation Cogent affectant l'équipement réseau. Les baies étaient vivantes; le service était inaccessible.

Un client surveillant uniquement l'état d'alimentation de la VM aurait manqué la panne réelle.

Les documents publics soutiennent les affirmations de liaisons montantes et de systèmes d'alimentation redondants au niveau de la conception. Ils ne documentent pas les chemins physiques, les transporteurs, les domaines de disjoncteur, le comportement de transfert automatique ou le dernier test de basculement. Des alimentations redondantes de serveur peuvent toujours alimenter le même chemin de distribution défaillant. Deux liaisons montantes peuvent encore se terminer sur un seul dispositif ou traverser un seul domaine de maintenance. Un deuxième routeur peut toujours dépendre de la même salle ou du même amont.

La redondance n'a de sens que lorsque ses composants sont suffisamment indépendants pour survivre à la défaillance considérée.

L'historique des statuts montre à la fois la valeur et les limites des pièces de rechange. En mars 2023, Lunanode a indiqué qu'un hyperviseur de Toronto avait subi une panne matérielle du plan disque et que le service avait été restauré après avoir échangé des disques dans un serveur physique de rechange. En février 2023, un remplacement d'alimentation a été compliqué car la pièce de rechange en stock n'avait pas le micrologiciel compatible, donc les deux alimentations ont dû être changées lors d'un arrêt. Ces entrées sont une preuve concrète d'une capacité de réparation pratique.

Elles montrent également que posséder une pièce de rechange n'est pas la même chose qu'avoir une réparation immédiatement compatible.

Une panne à Toronto en 2020 expose un domaine de défaillance plus large. Lunanode a signalé une surtension au centre de données Cogent du 245 Consumers Road, des redémarrages de serveurs et une unité de distribution d'alimentation défaillante dans une baie. Trois hyperviseurs et le système de stockage de volumes étaient hors ligne à un stade. L'entreprise a indiqué qu'elle disposait de deux serveurs de rechange et n'aurait pas pu remettre en service rapidement les trois systèmes défaillants si aucune des machines affectées n'avait démarré.

Elle a ensuite discuté de l'amélioration du regroupement des serveurs Ceph et d'une surveillance réseau plus étendue. Ce niveau de divulgation est utile car il nomme la ressource finie derrière la récupération: deux pièces de rechange, trois machines affectées et un problème de quorum de stockage.

Les preuves publiques n'établissent pas que le même nombre de pièces de rechange, la disposition des baies ou le groupement Ceph existent en 2026. Il serait erroné de transformer un rapport d'incident vieux de six ans en inventaire actuel. La leçon durable est que la récupération de Lunanode a dépendu de la topologie sur site, des pièces compatibles et du nombre de machines affectées simultanément. Ces contraintes restent pertinentes pour tout fournisseur, même lorsque l'équipement exact change.

AS394745 ajoute une preuve réseau réelle, pas une carte d'itinéraire complète

Lunanode n'est pas seulement une marque derrière l'espace d'adressage anonyme d'une autre entreprise. Les enregistrements ARIN et lapage AS394745 sur bgp.toolsidentifient Lunanode Hosting Inc. comme le détenteur du système autonome 394745. L'enregistrement date de décembre 2015, et l'enregistrement de l'organisation date de 2014. Les données de routage publiques interrogées pour le 12 juillet 2026 montraient l'AS annoncé.

La vue de routage est petite mais crédible. Laréponse des préfixes annoncésde RIPEstat pour AS394745 montrait 172.81.176.0/21 et le préfixe IPv6 2602:ffb6::/36 sur les deux semaines précédentes. Saréponse d'état de routagerapportait un préfixe IPv4, un préfixe IPv6 et neuf voisins observés au moment de l'interrogation. Les données whois dérivées d'ARIN associent 172.81.176.0/21 à Lunanode, et l'adresse de test actuelle de Lunanode à Toronto se trouve à l'intérieur de ce bloc.

La route IPv4 illustre également la limite du fournisseur. Lavue d'ensemble du préfixede RIPEstat pour l'adresse de test de Toronto montrait à la fois AS174, Cogent, et AS394745, Lunanode, associés au 172.81.176.0/21 couvrant au moment de l'interrogation du 12 juillet. Une vérification d'autorisation d'origine de route pour AS394745 sur ce /21 était valide. La vue d'origine mixte est cohérente avec un réseau qui a sa propre identité tout en restant étroitement couplé au routage de Cogent. Ce n'est pas une preuve que tout le trafic suit un chemin, ni ne révèle de sessions privées ou de conditions commerciales.

Le peering ajoute une autre pièce. L'enregistrementPeeringDBde Lunanode liste une politique de peering ouverte, deux préfixes IPv4, un préfixe IPv6 et une connexion opérationnelle de 10 gigabits au Toronto Internet Exchange. Il ne divulgue pas les niveaux de trafic ou la portée géographique, et ne liste aucune installation d'interconnexion pour le profil réseau. PeeringDB place le port TorIX chez Cologix TOR1. Cette présence d'échange public peut raccourcir les chemins vers les réseaux entités et réduire une partie de la dépendance au transit. Elle ne doit pas être confondue avec un second site de calcul. Un port de peering dans une installation d'échange peut être atteint par transport depuis des serveurs situés ailleurs dans la ville.

Lavue bgp.toolsmontrait un ensemble de pairs connus incluant Hurricane Electric, OVH, Cloudflare, TekSavvy et d'autres autour de la date d'interrogation. Ces listes démontrent des adjacences de routage observées; elles n'établissent pas de diversité de transit payant, d'accessibilité égale IPv4 et IPv6, de capacité contractée ou de performance de basculement. La même page montrait seulement l'allocation IPv6 comme directement originaire dans un résumé tandis que sa vue de politique détaillée incluait des pairs pour les deux protocoles. RIPEstat montrait le IPv4 /21. Les différences entre les collecteurs de routes, le timing et la classification sont une raison d'utiliser plusieurs vues, pas une raison de déclarer l'une d'elles comme une topologie complète.

La conclusion publique sur le réseau est donc modérée. Lunanode a son propre AS, des ressources d'adresse, des contrôles d'origine de route valides, un port TorIX actif et plusieurs voisins observés. C'est une preuve plus forte qu'un site d'hébergement sans identité réseau visible. Pourtant, le service orienté client de Toronto a dépendu à plusieurs reprises de l'installation Cogent et du travail amont, et les documents publics ne divulguent pas la capacité de transit contractée, la diversité des chemins physiques, la redondance des périphériques de bordure ou le basculement mesuré.

Les preuves réseau soutiennent l'exploitation actuelle; elles ne soutiennent pas une affirmation de résilience indépendante de la ville.

Le choix de stockage modifie à la fois les performances et le domaine de défaillance

Lunanode propose deux emplacements conceptuellement différents pour le disque d'une VM: le stockage local de l'hôte et les volumes de blocs détachables. Ladocumentation sur les volumesindique qu'un volume peut être attaché ou détaché, utilisé comme dispositif de démarrage, conservé après la suppression d'une VM, converti en image ou à partir d'une image, et instantané. Les volumes HDD sont tarifés séparément, tandis que les volumes SSD sont décrits comme uniquement à Toronto. La page à propos indique que les VM basées sur volume peuvent utiliser le stockage distribué Ceph RADOS et peuvent être automatiquement évacuées après une panne matérielle.

Le compromis est important. Un SSD local peut offrir un chemin direct et économique, mais la VM dépend fortement des disques, du contrôleur et du système de fichiers de son hôte. Déplacer la charge de travail peut nécessiter la copie ou le transplantation du stockage. Un volume distribué peut séparer les données d'un seul hôte de calcul et faciliter le démarrage de la VM ailleurs. Il introduit également un plan de stockage partagé. Si suffisamment de nœuds de stockage, de liens réseau ou de domaines d'alimentation tombent en panne ensemble, de nombreuses VM basées sur volume peuvent être affectées à la fois.

L'historique des incidents de Lunanode contient des exemples des deux modèles. L'événement de courant de juillet 2020 a compromis le système de stockage de volumes alors que plusieurs serveurs étaient hors ligne. Une panne de septembre 2023 dans une baie de Toronto a affecté le stockage par blocs et les VM de cette baie. Des incidents de disque local en novembre 2024 et juillet 2025 ont conduit à de longues périodes de réparation du système de fichiers et à la corruption ou perte de données client sur un petit nombre de VM. Ce ne sont pas des preuves qu'un choix de stockage est toujours supérieur.

Ils montrent que les conceptions locales et distribuées échouent différemment.

L'entrée de juillet 2025 est particulièrement pertinente pour la responsabilité du client. Lunanode a signalé une indisponibilité sur un hyperviseur SSD de Toronto, une réparation prolongée du système de fichiers sans estimation de restauration précoce, et finalement la perte de données sur quatre machines virtuelles en raison d'une corruption de disque. Il a offert aux utilisateurs concernés trois mois de crédit pour l'indisponibilité et douze mois de crédit pour la perte de données.

En novembre 2024, un SSD défaillant et une corruption du système de fichiers ont laissé au moins cinq VM avec des disques corrompus après une réparation prolongée. Les crédits peuvent reconnaître le préjudice; ils ne reconstruisent pas les données client.

Les conditions du fournisseur rendent la limite explicite: la fonctionnalité d'instantané existe, mais Lunanode ne sauvegarde pas automatiquement les données client et décline toute responsabilité en cas de perte de données. Lapage des instantanésindique que les instantanés peuvent être pris tandis qu'une VM est en ligne, utilisés pour créer ou réinstaller des VM, et téléchargés depuis le panneau. Cette dernière capacité est l'une des fonctionnalités de résilience les plus importantes car une image téléchargée peut quitter le domaine de défaillance immédiat du fournisseur.

Un instantané conservé uniquement dans le même environnement de Toronto est toujours exposé à la perte de compte, à la défaillance du plan de contrôle, à la panne de l'installation et à la contraction du fournisseur. La référence de la page à la réplication des instantanés entre emplacements cloud reflète le service multi-région antérieur et ne doit pas être supposée fournir une séparation géographique actuelle. Un acheteur doit vérifier quelle destination est disponible maintenant. Si Toronto est la seule région active, une sauvegarde indépendante nécessite un autre fournisseur de stockage, un autre site ou un support contrôlé par le client.

Les instantanés ont également des limites applicatives. Un instantané de disque pris alors qu'une base de données est occupée peut être cohérent en cas de panne plutôt que cohérent en transaction, sauf si l'application est mise en veille ou coordonne sa propre sauvegarde. Une image téléchargeable peut être inutile si personne ne teste la restauration, n'enregistre les clés de chiffrement, ne capture les services externes ou ne sait comment adapter la configuration réseau sur un autre hôte. Le panneau de contrôle fournit des primitives utiles. Le client doit les transformer en une conception de récupération.

Le registre d'incidents montre les chemins de défaillance réels

La page de statut de Lunanode est l'une des parties les plus solides de ses preuves publiques. Elle identifie les travaux en cours et planifiés, nomme les hyperviseurs affectés, décrit certaines causes et enregistre souvent la progression de la restauration. La page indique que les entrées de plus de six mois peuvent être purgées, bien qu'un historique substantiel reste visible. Ce n'est pas un rapport de disponibilité certifié, mais il est plus informatif que des promesses génériques de fiabilité.

Les incidents se répartissent en plusieurs catégories récurrentes.

Panne d'installation et de réseau amont.En mai 2026, Lunanode a signalé une perte de paquets à Toronto et a indiqué que l'amont avait identifié la cause. Des travaux Cogent planifiés en avril et juin 2026 comportaient une indisponibilité possible. En septembre 2024, un problème d'alimentation Cogent a laissé les serveurs sous tension de Lunanode déconnectés du monde extérieur pendant des heures. En 2023, une baie de Toronto a perdu l'alimentation après un problème de disjoncteur. Ces événements affectent de nombreux clients à la fois et peuvent rendre des VM saines inaccessibles.

Panne matérielle d'hyperviseur.L'archive enregistre des disques défaillants, des contrôleurs RAID, des alimentations, des modules de mémoire et des erreurs d'hôte anormales. Certaines indisponibilités ont duré quelques minutes; d'autres ont nécessité une réparation prolongée. Une plateforme de virtualisation peut déplacer ou recréer une VM uniquement si son stockage, son ordonnanceur, sa capacité de calcul de rechange et son chemin réseau restent disponibles. Une VM sur disque local est particulièrement liée à l'hôte physique, sauf si les données ont déjà été copiées ailleurs.

Panne de stockage partagé.L'événement de courant de 2020 et la panne de baie de 2023 ont affecté le stockage par blocs. Le stockage distribué réduit la dépendance à un seul disque ou hôte, mais un problème corrélé d'alimentation, de réseau ou de groupement peut retirer suffisamment de membres pour interrompre le service. C'est la différence entre la redondance de composants et l'indépendance du système.

Panne du plan de contrôle et des services auxiliaires.Une suspension de domaine en 2024 impliquantlndyn.coma interrompu les services jusqu'à ce que Lunanode déplace les domaines loin du registraire. Un autre avis de 2024 indiquait qu'un bogue de courriel de surveillance avait envoyé à certains utilisateurs des notifications destinées à d'autres. Lunanode a également reconnu que lorsque le réseau de Toronto était hors ligne, les alertes par courriel n'étaient pas envoyées car son serveur de messagerie se trouvait à Toronto, et a recommandé des alertes SMS, vocales ou HTTP. Une panne peut donc compromettre le mécanisme utilisé pour signaler la panne.

Corruption de données et réparation prolongée.Les incidents d'hyperviseur SSD de 2024 et 2025 montrent qu'un serveur revenant à un état en ligne ne garantit pas que chaque disque invité est intact. Les vérifications du système de fichiers peuvent prendre plusieurs heures, et les disques VM endommagés peuvent nécessiter une restauration par le client. Le temps de récupération et le point de récupération sont distincts: l'alimentation peut revenir avant que les données ne soient utilisables, et un service restauré peut encore avoir perdu des écritures récentes.

Panne d'emplacement commercial.Montréal et Roubaix ont fermé parce que les coûts des installations ont augmenté. Cela n'est pas ordinairement montré sur un graphique de statut technique, mais cela peut avoir le plus grand effet à long terme car un emplacement entier disparaît. Les clients ont eu un préavis et des options de migration, mais ils ne pouvaient pas préserver la région simplement en redémarrant.

L'archive ne doit pas être convertie en un taux de panne simpliste. Elle ne fournit pas un dénominateur complet, le nombre de VM actives, le nombre de clients affectés pour la plupart des événements, ou une garantie que chaque incident mineur est publié. Les entrées plus anciennes peuvent être supprimées. Certains avis contiennent des dates incohérentes ou des erreurs typographiques. La section actuelle, par exemple, inclut un en-tête réseau Toronto daté du 18 mai 2026 avec des mises à jour datées du 13 mai.

Cela affaiblit la chronologie précise mais pas la preuve plus large qu'une perte de paquets et une intervention amont ont eu lieu en mai.

La franchise ne doit pas non plus être confondue avec une mauvaise exploitation. Les petits fournisseurs peuvent sembler plus sujets aux pannes que des concurrents silencieux simplement parce qu'ils décrivent ce qui s'est passé. Les entrées de Lunanode montrent des techniciens remplaçant des pièces, déplaçant des disques, surveillant les réparations et offrant des crédits. L'utilisation correcte de l'archive est d'identifier les mécanismes de défaillance et de demander comment ils sont atténués maintenant, pas de prétendre que les décomptes d'incidents publics prédisent seuls la prochaine panne.

La redondance est disponible en couches, principalement dans une seule ville

Lunanode donne aux clients plusieurs éléments de base pour la résilience. Lafonctionnalité d'adresse IP flottantepermet de déplacer une adresse externe entre VM. Leservice d'équilibreur de chargepeut distribuer le trafic TCP, HTTP ou HTTPS entre plusieurs machines et retirer un membre défaillant après détection de problème par la surveillance. Les groupes de sécurité et lesréseaux privésprennent en charge les applications à plusieurs niveaux. L'API VM expose une option de groupe d'affinité, et sa réponse inclut un identifiant d'hôte physique, permettant aux clients de rechercher un placement sur des hyperviseurs distincts.

Chaque fonctionnalité répond à une défaillance particulière. Deux serveurs d'application sur des hyperviseurs différents peuvent survivre à un crash d'hôte. Une adresse flottante peut réduire les changements réseau nécessaires pour activer un remplacement. Un équilibreur de charge peut cesser d'envoyer des requêtes à un membre défaillant. Un démarrage basé sur volume peut séparer les données d'un hôte de calcul défaillant. La surveillance peut notifier un opérateur avant qu'un utilisateur ne signale le problème.

Aucune ne survit automatiquement à la perte de Toronto. Deux VM sur des hôtes différents peuvent partager la même baie, la même distribution électrique, le même cluster de stockage, le même routeur de bordure, la même installation et le même amont. Un équilibreur de charge dans la même région peut tomber en panne avec ses backends. Une adresse IP flottante est utile uniquement tant que le réseau régional la route encore. Un volume peut survivre à la suppression d'une VM tout en restant indisponible pendant une panne du plan de stockage ou de l'installation. L'affinité peut répartir le placement de calcul sans créer de séparation géographique.

Les clients doivent donc adapter la conception à la défaillance qui les préoccupe. Pour un site de loisir, un instantané et la capacité de recréer une VM peuvent suffire. Pour un site professionnel, des instances applicatives séparées, une sauvegarde de base de données testée et un contrôle DNS externe peuvent être appropriés. Pour un service avec des exigences de continuité strictes, la deuxième copie devrait être chez un autre fournisseur ou dans un autre site exploité indépendamment, avec suffisamment de capacité réservée pour démarrer la charge de travail.

Le mot « redondant » devrait toujours inviter à quatre questions: redondant contre quoi, situé où, contrôlé par qui, et testé quand? L'affirmation de Lunanode de liaisons montantes redondantes peut protéger contre un lien défaillant. Elle peut ne pas protéger contre la maintenance Cogent ou un problème réseau à l'échelle de l'installation. Le RAID10 protège contre certaines défaillances de disque. Il ne remplace pas une sauvegarde et n'a pas empêché chaque événement de corruption dans l'archive. La réplication Ceph protège contre certaines défaillances de nœud.

Elle peut encore être affectée lorsque l'alimentation ou les membres de stockage corrélés tombent en panne.

La récupération dépend également de la capacité utilisable. L'évacuation automatique nécessite un hôte survivant avec suffisamment de CPU et de mémoire. La restauration à partir d'un instantané nécessite suffisamment de stockage et de temps. Le déplacement d'une grande image hors site dépend de la bande passante. Le remplacement d'un hôte défaillant nécessite un inventaire compatible. Le dossier public ne dit pas quelle marge Lunanode maintient pour ces opérations, donc les clients ayant des objectifs de récupération fermes devraient obtenir des réponses spécifiques plutôt que de les déduire des noms de fonctionnalités.

Le support, la facturation et l'état du compte sont également des dépendances d'infrastructure

Lunanode dirige les clients ayant des problèmes d'infrastructure vers l'ouverture d'un ticket de support. Sonservice de surveillanceprend en charge les vérifications HTTP, d'expiration de certificat TLS, ICMP, TCP et DNS, avec des notifications par courriel, SMS, téléphone et webhook. Ce sont des outils pratiques, en particulier lorsque la destination d'alerte est en dehors du service de Toronto. L'incident de courriel de 2024 démontre pourquoi un canal d'alerte indépendant est important.

Les pages publiques ne définissent pas d'engagement général de temps de réponse ou de restauration pour les plans cloud ordinaires. La page de statut montre souvent un travail actif, mais ce n'est pas un calendrier de niveau de service contractuel. Il n'y a pas de déclaration publique de couverture de personnel 24h/24, de niveaux d'escalade, de dispositions de main à distance, de classes de priorité ou de fenêtres de remplacement garanties. Cela ne signifie pas que le support est absent; les mises à jour d'incident détaillées démontrent une intervention active.

Cela signifie qu'un acheteur ne peut pas dériver un objectif de support ferme à partir des documents publics.

La facturation peut également arrêter un service techniquement sain. Lunanode fonctionne sur crédit de compte. SonAPI de facturationexpose le solde de crédit restant, tandis que les conditions indiquent qu'un courriel de crédit faible est envoyé au moins 48 heures avant que le crédit n'atteigne zéro et que les services sont suspendus après que le solde devient négatif, avec au moins sept jours de préavis avant la suspension. Un échec de paiement, une adresse de contact obsolète ou une notification manquée peut donc devenir un événement de disponibilité.

Les conditions réservent également des droits de suspension et de résiliation larges, décrivent le traitement des remboursements, et stipulent que la résiliation libère les ressources allouées et supprime les données associées. Les clients devraient comprendre ces dispositions avant de mettre des données irremplaçables dans un seul compte. La séparation opérationnelle peut nécessiter plus que deux VM: elle peut nécessiter une sauvegarde hors fournisseur, un DNS et un contrôle de domaine indépendants, plusieurs contacts de facturation, un crédit surveillé, une récupération d'accès documentée et un deuxième endroit pour fonctionner.

La concentration du support est difficile à mesurer publiquement. Les enregistrements ARIN et PeeringDB nomment un contact technique, mais un contact de registre ne révèle pas la taille de l'équipe ou la couverture des quarts. Aucune preuve publique fiable ne quantifie les effectifs de Lunanode, le personnel sur site ou la file d'attente de support. La conclusion honnête n'est pas que le support est nécessairement mince; c'est que la redondance du personnel et la profondeur d'escalade restent non vérifiées.

La localité canadienne est utile, mais ce n'est pas une réponse complète à la souveraineté

L'hébergement à Toronto peut être attractif pour les clients qui veulent que leurs disques et volumes VM primaires soient au Canada. Lunanode est une entreprise canadienne dans les registres ARIN, et ses pages de service en direct identifient Toronto comme l'emplacement de calcul actuel. Cela donne à un acheteur plus d'informations sur la localité qu'un service qui se contente d'étiqueter une région large.

Lapolitique de confidentialitéde l'entreprise indique que les contenus des VM, volumes et images des clients sont stockés en tant que données utilisateur et décrit les limites d'accès et de divulgation. Sonaccord de confidentialité des donnéesdécrit Lunanode comme un processeur ou sous-processeur dans les circonstances pertinentes, autorise les sous-processeurs, et indique que les clients choisissent le pays où les données sont stockées lors de l'achat du service. Les deux documents datent de 2018. Ils restent publiés, mais leur âge et leurs références au choix du pays doivent être conciliés avec les preuves actuelles de provisionnement uniquement à Toronto.

La localisation des données comporte plusieurs niveaux. Le disque primaire peut être à Toronto tandis que les messages de surveillance, les enregistrements de paiement, les communications de support ou les sauvegardes gérées par le client utilisent d'autres fournisseurs et juridictions. Un client peut accéder aux données hébergées à Toronto depuis n'importe où. Un sous-processeur peut participer à la fourniture d'une partie du service. L'enregistrement de domaine, le traitement des paiements, la livraison SMS et la connectivité amont ont leurs propres limites d'opérateur.

Le stockage canadien est donc un fait significatif, pas une conclusion juridique ou opérationnelle complète.

Les fermetures de 2023 montrent également pourquoi la localité doit être surveillée dans le temps. Roubaix offrait autrefois un emplacement français; Montréal offrait une deuxième ville canadienne. Lorsque les deux ont fermé, les clients ont dû accepter Toronto ou partir. Un contrat ou une évaluation de conformité devrait identifier l'emplacement approuvé, les attentes de notification, le processus d'exportation et la réponse requise si cet emplacement est retiré.

La portabilité est comparativement tangible sur Lunanode. Les instantanés peuvent être téléchargés. Les clients peuvent télécharger leurs propres images et médias d'installation. Les volumes peuvent être convertis en images. Les adresses IP flottantes peuvent être détachées à l'intérieur de la plateforme, bien que l'adresse ne puisse généralement pas suivre le client vers un fournisseur non lié. Ces contrôles peuvent réduire l'enfermement si le client les exerce réellement.

Un format d'image, une clé de chiffrement, une zone DNS, un enregistrement de configuration et une sauvegarde de données récente et indépendante sont plus utiles qu'un bouton d'exportation théorique découvert lors d'une urgence.

Une évaluation sérieuse de la localité doit donc demander où réside chaque classe de données, qui peut y accéder, quelles conditions juridiques s'appliquent, comment les sauvegardes quittent Toronto, à quelle vitesse le client peut récupérer une copie complète, et si cette copie démarre avec succès ailleurs. Les documents publics de Lunanode fournissent un point de départ. Ils ne répondent pas à l'ensemble de l'évaluation pour chaque charge de travail.

Ce qui augmenterait le niveau de preuve

L'empreinte publique de Lunanode n'est pas vide. Elle est plus solide que ne le suggère une lecture rapide de sa modeste présence marketing. L'entreprise a des pages de produits et de tarification en direct, des instructions de provisionnement actuelles pour Toronto, des avis de statut détaillés jusqu'en 2026, un espace d'adressage actif, AS394745, des annonces IPv4 et IPv6, une présence TorIX et une surface de contrôle de longue date. Ce sont des signes crédibles d'un petit fournisseur de cloud en activité.

Le niveau s'arrête à Moyen car les faits de résilience les plus importants restent non divulgués. Les documents publics n'indiquent pas le nombre de baies ou d'hyperviseurs actifs, les générations de serveurs actuelles dans la flotte, la puissance contractée, la marge de puissance disponible, le nombre de nœuds de stockage, la disposition de réplication, le nombre d'hôtes de rechange, l'inventaire des pièces de rechange, les contrats de transit, la diversité des routes physiques, le personnel de support, le nombre de clients, l'utilisation, les objectifs de récupération ou les résultats des tests de restauration.

Ils montrent une ville de calcul active et aucun second site vérifié pour le basculement client.

Les preuves qui augmenteraient le niveau n'ont pas besoin d'exposer des détails sensibles. Lunanode pourrait publier une note d'architecture actuelle qui distingue les domaines de défaillance de l'installation, de la baie, de l'hôte et du stockage; confirmer si les charges de travail clients occupent plus d'un domaine d'alimentation; identifier les classes de diversité amont; décrire comment le placement d'affinité se rapporte aux baies; décrire le comportement actuel de réplication et d'évacuation des volumes; et fournir des métriques globales de disponibilité et d'incidents.

Une déclaration actuelle de sauvegarde et de localisation des données pourrait remplacer l'ambiguïté laissée par les documents de 2018 et les instructions multi-région historiques.

Pour un client, les questions immédiates sont pratiques. La VM est-elle sur disque local ou sur volume? Les répliques sont-elles sur des hôtes et des baies distincts? L'application survit-elle à une panne d'hôte? La sauvegarde est-elle en dehors de Lunanode et en dehors de Toronto? Peut-elle être restaurée sur un autre hyperviseur ou un autre fournisseur? La surveillance alerte-t-elle toujours lorsque Toronto ne peut pas envoyer de courriel? Qui surveille le crédit du compte? Que se passe-t-il si une région est retirée? Quelle quantité de données doit traverser le réseau pendant la récupération, et combien de temps a duré le dernier test?

La proposition de valeur de Lunanode n'exige pas qu'elle ressemble à un cloud hyperscale. Un fournisseur canadien compact peut être un bon choix lorsque le prix, la simplicité, la facturation horaire et la localité torontoise importent. Les preuves soutiennent cette proposition plus étroite. Elles ne soutiennent pas le traitement d'une capacité hébergée à bas coût comme sans emplacement ou auto-réparatrice par défaut.

Le fait d'infrastructure central est simple: Lunanode vend une interface flexible à des machines réelles dans une installation réelle à Toronto. Sa propre histoire montre des réparations qui dépendaient de serveurs de rechange, d'alimentations compatibles, de vérifications de système de fichiers, de quorum de stockage, de techniciens amont et de migration client. Les acheteurs peuvent utiliser les instantanés, les volumes, les équilibreurs de charge, les adresses flottantes et la surveillance de la plateforme pour construire la résilience.

La dernière couche leur appartient encore: conserver une copie indépendante, réserver un autre endroit pour fonctionner, et tester le chemin avant qu'une baie, une route, un compte ou un contrat commercial ne force le déplacement.