Lunanode Hosting Inc. vende capacidade hospedada que ainda depende de racks, trânsito e janelas de reparo

Resumo

• A Lunanode está visivelmente operacional: seu site atual oferece máquinas virtuais e armazenamento em Toronto, sua página de status registra incidentes e manutenções até 2026, e o AS394745 permanece anunciado com espaço IPv4 e IPv6 visível nos dados de roteamento públicos.
• A pegada de computação ativa parece concentrada em Toronto. A Lunanode fechou Montreal e Roubaix em 2023 após aumentos substanciais nos custos dos datacenters, enquanto alguns exemplos de API mais antigos ainda listam as três regiões e não devem ser interpretados como capacidade atual.
• A resiliência está disponível em camadas, não como uma propriedade automática. Volumes, snapshots, endereços IP flutuantes, balanceadores de carga, controles de afinidade e imagens para download ajudam os clientes a projetar a recuperação, mas a maioria desses controles permanece dentro do mesmo domínio de falha de Toronto, a menos que o cliente mantenha uma cópia independente em outro lugar.
• O nível de evidência é Médio. A Lunanode publica detalhes de incidentes excepcionalmente úteis e expõe registros de rede confiáveis, mas não divulga publicamente o número de racks, energia utilizável, capacidade total de computação instalada, topologia de armazenamento atual, objetivos contratuais de reparo, profundidade de peças sobressalentes ou uma segunda região de computação ativa.

Um painel de controle em nuvem não elimina o espaço físico por trás

A oferta da Lunanode é claramente um serviço de nuvem, não apenas um servidor alugado com um identificador. Apágina sobrea empresa descreve uma plataforma baseada em OpenStack e KVM, com máquinas virtuais, volumes de bloco, snapshots ao vivo, endereços IP flutuantes, redes virtuais, scripts de inicialização, monitoramento e uma API. Suapágina de máquinas virtuaisdivide o serviço em planos de uso geral, otimizados para memória e otimizados para computação, e afirma que as instâncias são cobradas por hora. Um cliente pode criar, redimensionar, hibernar, reinstalar, resgatar e excluir máquinas sem esperar por um pedido de servidor físico.

Essa abstração é real e valiosa. Ela permite que uma pequena empresa de software alugue uma fração de servidor, que um administrador converta uma compra de capital em despesa operacional, e que um projeto libere recursos computacionais quando não são mais necessários. Ela também torna fácil negligenciar a dependência física. Cada núcleo virtual corresponde a um soquete de processador em um chassi específico. Cada disco local corresponde a discos e um controlador. Cada volume de bloco depende dos nós de armazenamento e da rede que os conecta.

Cada endereço público depende de uma rota, um dispositivo de borda, um upstream e da energia elétrica da instalação. Cada reparo depende de uma pessoa, uma peça sobressalente e acesso ao rack.

O próprio registro público da Lunanode torna essa cadeia particularmente concreta. Apágina de localizaçõesatual nomeia Toronto, indica que a implantação está na instalação da Cogent em Toronto, e descreve uma rede de 10 gigabits por segundo, links uplink e sistemas de energia redundantes. Ela nomeia processadores Intel Xeon E5-2690 v2 duplos e SSD RAID10 nos nós host SSD. Apágina de infraestruturaassociada afirma que os clientes podem escolher entre discos SSD locais ou armazenamento em bloco distribuído, e que as VMs na mesma região se comunicam em uma rede privada de 10 gigabits por segundo.

Essas declarações identificam o tipo de maquinário por trás do serviço. Elas não divulgam quanto está instalado, quanto está livre, quantos racks ocupa, quanta energia é reservada, quantas gerações de hosts permanecem em serviço, ou se cada carga de trabalho recebe o mesmo caminho de armazenamento e rede. O processador nomeado na página de localizações data de uma geração de servidor anterior. Isso não o torna inutilizável; hardware antigo confiável pode ser economicamente razoável para hospedagem de baixo custo.

No entanto, isso significa que um comprador deve distinguir um tipo de host claramente especificado de uma frota continuamente renovada.

A nuvem, neste caso, é uma interface operacional útil sobre uma implantação finita em Toronto. A Lunanode controla sua plataforma de cliente, o agendamento de VMs, o serviço de armazenamento, a configuração de rede e as decisões de suporte. A Cogent controla importantes condições de instalação e upstream. Os fornecedores de hardware determinam a disponibilidade de peças. O cliente controla a arquitetura da aplicação, backups independentes e a decisão de manter capacidade em outro lugar. A confiabilidade emerge desses quatro limites, não apenas do painel de controle.

Toronto é o centro de gravidade operacional atual

O fato mais importante na história atual de infraestrutura da Lunanode é a concentração geográfica. As páginas de marketing atuais indicam que a plataforma de nuvem está em Toronto. Ainda mais decisivo, adocumentação da API de máquinas virtuaisespecifica que o parâmetro de região para criação de VM deve sertoronto. A documentação atual dos grupos de segurança também indica que um novo grupo deve estar na região Toronto. Esses são sinais atuais mais fortes do que uma lista antiga de nomes de lugares, pois descrevem o que a interface de provisionamento aceita agora.

Outras páginas da Lunanode mantêm vestígios históricos. Apágina da API de planos e regiõesinclui um exemplo de resposta com Montreal, Roubaix e Toronto. Apágina da API de redes virtuaistambém mostra esses três nomes. A página de snapshots ainda descreve a replicação entre locais de nuvem. Nenhuma dessas páginas, por si só, estabelece que os clientes podem provisionar nova capacidade de produção em Montreal ou Roubaix em julho de 2026.

Ohistórico de statusda Lunanode resolve o aparente conflito. No início de 2023, a empresa anunciou que estava abandonando Montreal e Roubaix devido a aumentos substanciais de custos impostos pelos datacenters que usava lá. Os clientes foram solicitados a migrar as máquinas virtuais e os volumes anexados para Toronto até 31 de janeiro de 2023, pedir ajuda ou solicitar reembolso se Toronto não fosse adequada. Uma entrada posterior indicava que as VMs restantes nos dois locais fechados seriam migradas para Toronto. As páginas de serviço atuais, apenas em Toronto, são consistentes com esse histórico; os exemplos de API de três regiões são melhor tratados como documentação obsoleta.

O fechamento é mais do que uma nota histórica. Ele revela um caminho de falha do contrato do fornecedor. A Lunanode não precisou de um incêndio, inundação ou colapso técnico para perder duas regiões. Um insumo comercial mudou: as instalações se tornaram significativamente mais caras. A empresa respondeu removendo a capacidade e consolidando as cargas de trabalho. É uma decisão comercial racional, mas ilustra por que a infraestrutura alugada nunca é independente de aluguéis, preços de energia, acordos de trânsito e da economia de manter capacidade subutilizada.

Para os clientes, o efeito depende da arquitetura. Uma aplicação sem estado com automação de configuração e uma cópia externa de seus dados pode ser movida. Uma VM de longa duração com disco local, endereço fixo, modificações de software não documentadas e nenhuma restauração testada pode se tornar um projeto de migração. Um cliente europeu que escolheu Roubaix por latência ou proximidade não poderia considerar Toronto como um substituto equivalente. Um cliente de Montreal poderia permanecer no Canadá, mas enfrentar latência, peering e geografia de desastre diferentes.

O fornecedor ofereceu assistência de migração e créditos, mas o cliente ainda arcou com o trabalho no nível da aplicação e a decisão de saber se Toronto atendia às suas necessidades.

A Lunanode pode vender e atender clientes em muitos países enquanto opera a plataforma de computação visível em uma única cidade. A presença global de vendas e uma infraestrutura multirregião são duas coisas diferentes.

Os preços baixos são produzidos pelo uso, normalização e limites

O apelo comercial da Lunanode é simples. Suapágina de preçosao vivo lista pequenas VMs de uso geral e orientadas a memória a partir de alguns dólares americanos por mês, configurações maiores e planos otimizados para computação com núcleos dedicados. Ela precifica o armazenamento em bloco e snapshots por gigabyte, endereços públicos adicionais por mês e largura de banda excedente por gigabyte. O serviço pode, portanto, ser adequado para projetos pessoais, pequenos sites, sistemas de desenvolvimento, aplicativos empresariais modestos e cargas de trabalho que não justificam um contrato de grande nuvem.

O preço de entrada baixo não é o custo de uma máquina física dedicada. É o preço de uma parte em um pool gerenciado. O fornecedor compra servidores, espaço em rack, portas de rede, endereços, mídia de armazenamento e tempo de pessoal, e então distribui esses custos fixos e semifixos entre os clientes. A lucratividade depende da ocupação e utilização: clientes suficientes devem pagar pela frota instalada, enquanto nem todos os clientes podem exigir cada recurso alocado em plena intensidade ao mesmo tempo, a menos que o plano e o design de capacidade permitam.

A Lunanode torna alguns desses controles visíveis. Os planos de uso geral e memória usam núcleos virtuais; os planos otimizados para computação anunciam núcleos dedicados. A largura de banda é compartilhada por conta e região, com tráfego de entrada e saída contabilizado. Ostermos de serviçoindicam que a largura de banda excedente é cobrada e que os clientes podem optar por desligar as VMs antes de exceder seu pool. A hibernação libera CPU e memória enquanto mantém armazenamento e endereços a um custo menor. Estes não são meros detalhes de faturamento. São mecanismos para converter equipamento finito em capacidade vendável de aparência elástica.

A capacidade instalada e a capacidade utilizável não são, portanto, as mesmas. Um rack pode conter uma soma nominal de núcleos de processador e terabytes, mas uma parte deve ser reservada para despesas gerais do sistema, replicação de armazenamento, dispositivos com falha, manutenção, desequilíbrio de hosts e margem de manobra do cliente. Um servidor em espera como peça sobressalente está instalado mas não gera receita normal. Um rack quase cheio pode ainda ter espaço unitário nominal, mas faltar margem de segurança elétrica.

Um cluster de armazenamento pode ter espaço em disco bruto que não está disponível para novos dados do cliente porque as reservas de replicação e recuperação o consomem. Um link de 10 gigabits é uma velocidade de porta, não uma garantia de que cada VM pode manter essa taxa para todos os destinos.

Nenhuma página pública da Lunanode quantifica essas margens. A página de preços ao vivo fornece um catálogo, não um estoque. O painel de controle pode mostrar a disponibilidade do plano para um usuário autenticado, mas os documentos públicos não dizem quantas instâncias de cada tipo podem ser criadas, como a capacidade é distribuída entre os hosts, ou qual limite desencadeia uma compra de hardware. Os compradores devem, portanto, considerar os preços como ofertas válidas no momento do pedido, e não como prova de expansão ilimitada.

Esse quadro econômico também explica a contração regional de 2023. Um pequeno provedor pode oferecer capacidade de baixo custo porque evita as despesas gerais de um parque hyperscale. A mesma disciplina pode tornar um local subutilizado ou que se tornou caro difícil de manter. A computação barata por hora e a geografia de contingência permanente puxam em direções opostas. Um cliente que precisa de ambos deve pagar por capacidade independente e testá-la, em vez de assumir que o preço básico da VM inclui um site secundário inativo.

O limite da instalação é visível, mas apenas parcialmente descrito

A Lunanode indica que sua localização em Toronto está em uma instalação da Cogent. Seus avisos de status identificam repetidamente a Cogent como o data center ou o upstream envolvido nos trabalhos de rede. Um aviso de junho de 2026 alertava sobre possível indisponibilidade de rede para atualizações de software nos roteadores de borda realizadas pelo data center. Um aviso de abril de 2026 descrevia uma manutenção similar. Um incidente de janeiro de 2026 indicava que o upstream parecia estar realizando manutenção planejada enquanto a Lunanode investigava uma interrupção em Toronto.

Essa divisão de responsabilidades é importante. A Lunanode pode manter os servidores e seu próprio equipamento de rede, mas não pode impedir independentemente uma atualização do roteador de borda da instalação ou restaurar um dispositivo upstream com falha. Em setembro de 2024, a Lunanode relatou que seus servidores e equipamentos de rede permaneciam ligados e funcionais enquanto a conectividade externa estava offline devido a um problema de energia da Cogent afetando o equipamento de rede. Os racks estavam vivos; o serviço estava inacessível. Um cliente monitorando apenas o status de energia da VM teria perdido a falha real.

Os documentos públicos apoiam as afirmações de links uplink e sistemas de energia redundantes no nível de design. Eles não documentam os caminhos físicos, transportadoras, domínios de disjuntor, comportamento de transferência automática ou o último teste de failover. Fontes de alimentação redundantes de servidor ainda podem alimentar o mesmo caminho de distribuição com falha. Dois links uplink ainda podem terminar em um único dispositivo ou atravessar um único domínio de manutenção. Um segundo roteador ainda pode depender da mesma sala ou do mesmo upstream.

A redundância só faz sentido quando seus componentes são suficientemente independentes para sobreviver à falha considerada.

O histórico de status mostra tanto o valor quanto os limites das peças sobressalentes. Em março de 2023, a Lunanode indicou que um hypervisor em Toronto sofreu uma falha de hardware no plano de disco e que o serviço foi restaurado após trocar discos em um servidor físico sobressalente. Em fevereiro de 2023, uma substituição de fonte de alimentação foi complicada porque a peça sobressalente em estoque não tinha o firmware compatível, então ambas as fontes tiveram que ser trocadas durante uma parada. Essas entradas são evidências concretas de capacidade de reparo prática.

Elas também mostram que possuir uma peça sobressalente não é o mesmo que ter um reparo imediatamente compatível.

Uma falha em Toronto em 2020 expõe um domínio de falha mais amplo. A Lunanode relatou uma sobretensão no data center da Cogent na 245 Consumers Road, reinicializações de servidores e uma unidade de distribuição de energia com falha em um rack. Três hypervisors e o sistema de armazenamento de volumes ficaram offline em um estágio. A empresa indicou que tinha dois servidores sobressalentes e não teria conseguido restaurar rapidamente os três sistemas com falha se nenhuma das máquinas afetadas tivesse iniciado. Ela então discutiu a melhoria do agrupamento de servidores Ceph e um monitoramento de rede mais amplo.

Esse nível de divulgação é útil porque nomeia o recurso finito por trás da recuperação: duas peças sobressalentes, três máquinas afetadas e um problema de quorum de armazenamento.

As evidências públicas não estabelecem que o mesmo número de peças sobressalentes, a disposição dos racks ou o agrupamento Ceph existem em 2026. Seria errado transformar um relatório de incidente de seis anos atrás em inventário atual. A lição duradoura é que a recuperação da Lunanode dependeu da topologia no local, peças compatíveis e do número de máquinas afetadas simultaneamente. Essas restrições permanecem relevantes para qualquer provedor, mesmo quando o equipamento exato muda.

AS394745 adiciona uma evidência de rede real, não um mapa de rota completo

A Lunanode não é apenas uma marca por trás do espaço de endereçamento anônimo de outra empresa. Os registros ARIN e apágina AS394745 no bgp.toolsidentificam a Lunanode Hosting Inc. como a detentora do sistema autônomo 394745. O registro data de dezembro de 2015, e o registro da organização data de 2014. Os dados de roteamento públicos consultados para 12 de julho de 2026 mostravam o AS anunciado.

A visão de roteamento é pequena, mas crível. Aresposta de prefixos anunciadosdo RIPEstat para AS394745 mostrava 172.81.176.0/21 e o prefixo IPv6 2602:ffb6::/36 nas duas semanas anteriores. Suaresposta de status de roteamentorelatava um prefixo IPv4, um prefixo IPv6 e nove vizinhos observados no momento da consulta. Os dados whois derivados do ARIN associam 172.81.176.0/21 à Lunanode, e o endereço de teste atual da Lunanode em Toronto está dentro desse bloco.

A rota IPv4 também ilustra o limite do provedor. Avisão geral do prefixodo RIPEstat para o endereço de teste de Toronto mostrava tanto AS174, Cogent, quanto AS394745, Lunanode, associados ao 172.81.176.0/21 no momento da consulta de 12 de julho. Uma verificação de autorização de origem de rota para AS394745 nesse /21 era válida. A visão de origem mista é consistente com uma rede que tem sua própria identidade, mas permanece estreitamente acoplada ao roteamento da Cogent. Não é uma prova de que todo o tráfego segue um caminho, nem revela sessões privadas ou condições comerciais.

O peering adiciona outra peça. O registroPeeringDBda Lunanode lista uma política de peering aberta, dois prefixos IPv4, um prefixo IPv6 e uma conexão operacional de 10 gigabits no Toronto Internet Exchange. Ele não divulga os níveis de tráfego ou o escopo geográfico, e não lista nenhuma instalação de interconexão para o perfil de rede. O PeeringDB coloca a porta TorIX na Cologix TOR1. Essa presença de troca pública pode encurtar caminhos para redes de entidades e reduzir parte da dependência de trânsito. Não deve ser confundida com um segundo site de computação. Uma porta de peering em uma instalação de troca pode ser alcançada por transporte a partir de servidores localizados em outro lugar na cidade.

Avisão bgp.toolsmostrava um conjunto de pares conhecidos incluindo Hurricane Electric, OVH, Cloudflare, TekSavvy e outros por volta da data da consulta. Essas listas demonstram adjacências de roteamento observadas; elas não estabelecem diversidade de trânsito pago, acessibilidade igual IPv4 e IPv6, capacidade contratada ou desempenho de failover. A mesma página mostrava apenas a alocação IPv6 como diretamente originada em um resumo, enquanto sua visão de política detalhada incluía pares para ambos os protocolos. O RIPEstat mostrava o IPv4 /21. As diferenças entre coletores de rotas, temporização e classificação são uma razão para usar múltiplas visões, não uma razão para declarar uma delas como topologia completa.

A conclusão pública sobre a rede é, portanto, moderada. A Lunanode tem seu próprio AS, recursos de endereço, verificações de origem de rota válidas, uma porta TorIX ativa e vários vizinhos observados. Isso é uma evidência mais forte do que um site de hospedagem sem identidade de rede visível. No entanto, o serviço orientado ao cliente de Toronto dependeu repetidamente da instalação da Cogent e do trabalho upstream, e os documentos públicos não divulgam a capacidade de trânsito contratada, a diversidade de caminhos físicos, a redundância de dispositivos de borda ou o failover medido.

As evidências de rede suportam a operação atual; elas não suportam uma afirmação de resiliência independente da cidade.

A escolha de armazenamento altera tanto o desempenho quanto o domínio de falha

A Lunanode oferece dois locais conceitualmente diferentes para o disco de uma VM: armazenamento local do host e volumes de bloco destacáveis. Adocumentação sobre volumesindica que um volume pode ser anexado ou desanexado, usado como dispositivo de inicialização, mantido após a exclusão de uma VM, convertido em imagem ou a partir de uma imagem, e snapshot. Os volumes HDD são precificados separadamente, enquanto os volumes SSD são descritos como apenas em Toronto. A página sobre indica que as VMs baseadas em volume podem usar o armazenamento distribuído Ceph RADOS e podem ser evacuadas automaticamente após uma falha de hardware.

O trade-off é importante. Um SSD local pode oferecer um caminho direto e econômico, mas a VM depende fortemente dos discos, controlador e sistema de arquivos de seu host. Mover a carga de trabalho pode exigir cópia ou transplante do armazenamento. Um volume distribuído pode separar os dados de um único host de computação e facilitar a inicialização da VM em outro lugar. Ele também introduz um plano de armazenamento compartilhado. Se nós de armazenamento, links de rede ou domínios de energia suficientes falharem juntos, muitas VMs baseadas em volume podem ser afetadas ao mesmo tempo.

O histórico de incidentes da Lunanode contém exemplos de ambos os modelos. O evento de corrente de julho de 2020 comprometeu o sistema de armazenamento de volumes enquanto vários servidores estavam offline. Uma falha em setembro de 2023 em um rack de Toronto afetou o armazenamento em bloco e as VMs naquele rack. Incidentes de disco local em novembro de 2024 e julho de 2025 levaram a longos períodos de reparo do sistema de arquivos e corrupção ou perda de dados do cliente em um pequeno número de VMs. Estas não são evidências de que uma escolha de armazenamento é sempre superior.

Eles mostram que designs locais e distribuídos falham de forma diferente.

A entrada de julho de 2025 é particularmente relevante para a responsabilidade do cliente. A Lunanode relatou uma indisponibilidade em um hypervisor SSD de Toronto, reparo prolongado do sistema de arquivos sem estimativa de restauração precoce, e eventualmente perda de dados em quatro máquinas virtuais devido a corrupção de disco. Ela ofereceu aos usuários afetados três meses de crédito pela indisponibilidade e doze meses de crédito pela perda de dados. Em novembro de 2024, um SSD com falha e corrupção do sistema de arquivos deixaram pelo menos cinco VMs com discos corrompidos após reparo prolongado.

Os créditos podem reconhecer o dano; eles não reconstroem os dados do cliente.

Os termos do fornecedor tornam o limite explícito: a funcionalidade de snapshot existe, mas a Lunanode não faz backup automático dos dados do cliente e se isenta de responsabilidade por perda de dados. Apágina de snapshotsindica que os snapshots podem ser tirados enquanto uma VM está online, usados para criar ou reinstalar VMs, e baixados do painel. Esta última capacidade é uma das funcionalidades de resiliência mais importantes, pois uma imagem baixada pode sair do domínio de falha imediato do fornecedor.

Um snapshot mantido apenas no mesmo ambiente de Toronto ainda está exposto a perda de conta, falha do plano de controle, falha da instalação e contração do fornecedor. A referência da página à replicação de snapshots entre locais de nuvem reflete o serviço multirregião anterior e não deve ser considerada como fornecendo separação geográfica atual. Um comprador deve verificar qual destino está disponível agora. Se Toronto é a única região ativa, um backup independente requer outro fornecedor de armazenamento, outro local ou mídia controlada pelo cliente.

Os snapshots também têm limitações da aplicação. Um snapshot de disco tirado enquanto um banco de dados está ocupado pode ser consistente com falha em vez de consistente transacional, a menos que a aplicação seja hibernada ou coordene seu próprio backup. Uma imagem para download pode ser inútil se ninguém testar a restauração, registrar as chaves de criptografia, capturar serviços externos ou souber como adaptar a configuração de rede em outro host. O painel de controle fornece primitivas úteis. O cliente deve transformá-las em um design de recuperação.

O registro de incidentes mostra os caminhos de falha reais

A página de status da Lunanode é uma das partes mais sólidas de suas evidências públicas. Ela identifica os trabalhos em andamento e planejados, nomeia os hypervisors afetados, descreve algumas causas e frequentemente registra o progresso da restauração. A página indica que entradas com mais de seis meses podem ser removidas, embora um histórico substancial permaneça visível. Não é um relatório de disponibilidade certificado, mas é mais informativo do que promessas genéricas de confiabilidade.

Os incidentes se dividem em várias categorias recorrentes.

Falha de instalação e rede upstream.Em maio de 2026, a Lunanode relatou perda de pacotes em Toronto e indicou que o upstream havia identificado a causa. Trabalhos planejados da Cogent em abril e junho de 2026 envolviam possível indisponibilidade. Em setembro de 2024, um problema de energia da Cogent deixou os servidores ligados da Lunanode desconectados do mundo exterior por horas. Em 2023, um rack de Toronto perdeu energia após um problema de disjuntor. Esses eventos afetam muitos clientes ao mesmo tempo e podem tornar VMs saudáveis inacessíveis.

Falha de hardware de hypervisor.O arquivo registra discos com falha, controladores RAID, fontes de alimentação, módulos de memória e erros anormais de host. Algumas indisponibilidades duraram alguns minutos; outras exigiram reparo prolongado. Uma plataforma de virtualização pode mover ou recriar uma VM apenas se seu armazenamento, escalonador, capacidade de computação de reposição e caminho de rede permanecerem disponíveis. Uma VM em disco local está particularmente vinculada ao host físico, a menos que os dados já tenham sido copiados para outro lugar.

Falha de armazenamento compartilhado.O evento de corrente de 2020 e a falha de rack de 2023 afetaram o armazenamento em bloco. O armazenamento distribuído reduz a dependência de um único disco ou host, mas um problema correlacionado de energia, rede ou agrupamento pode remover membros suficientes para interromper o serviço. Essa é a diferença entre redundância de componentes e independência do sistema.

Falha do plano de controle e serviços auxiliares.Uma suspensão de domínio em 2024 envolvendolndyn.cominterrompeu os serviços até que a Lunanode movesse os domínios para longe do registrador. Outro aviso de 2024 indicava que um bug de e-mail de monitoramento havia enviado a alguns usuários notificações destinadas a outros. A Lunanode também reconheceu que, quando a rede de Toronto estava offline, os alertas por e-mail não eram enviados porque seu servidor de e-mail estava em Toronto, e recomendou alertas SMS, de voz ou HTTP. Uma falha pode, portanto, comprometer o mecanismo usado para sinalizar a falha.

Corrupção de dados e reparo prolongado.Os incidentes de hypervisor SSD de 2024 e 2025 mostram que um servidor retornando a um estado online não garante que cada disco convidado esteja intacto. As verificações do sistema de arquivos podem levar várias horas, e os discos VM danificados podem exigir restauração pelo cliente. O tempo de recuperação e o ponto de recuperação são distintos: a energia pode retornar antes que os dados estejam utilizáveis, e um serviço restaurado pode ainda ter perdido escritas recentes.

Falha de local comercial.Montreal e Roubaix fecharam porque os custos das instalações aumentaram. Isso não é normalmente mostrado em um gráfico de status técnico, mas pode ter o maior efeito a longo prazo, pois um local inteiro desaparece. Os clientes tiveram aviso prévio e opções de migração, mas não podiam preservar a região simplesmente reiniciando.

O arquivo não deve ser convertido em uma taxa de falha simplista. Ele não fornece um denominador completo, o número de VMs ativas, o número de clientes afetados na maioria dos eventos, ou uma garantia de que cada incidente menor é publicado. Entradas mais antigas podem ser removidas. Alguns avisos contêm datas inconsistentes ou erros tipográficos. A seção atual, por exemplo, inclui um cabeçalho de rede Toronto datado de 18 de maio de 2026 com atualizações datadas de 13 de maio. Isso enfraquece a cronologia precisa, mas não a evidência mais ampla de que uma perda de pacotes e intervenção upstream ocorreram em maio.

A franqueza também não deve ser confundida com má operação. Pequenos provedores podem parecer mais propensos a falhas do que concorrentes silenciosos simplesmente porque descrevem o que aconteceu. As entradas da Lunanode mostram técnicos substituindo peças, movendo discos, monitorando reparos e oferecendo créditos. O uso correto do arquivo é identificar os mecanismos de falha e perguntar como eles são mitigados agora, não fingir que as contagens de incidentes públicas preveem sozinhas a próxima falha.

A redundância está disponível em camadas, principalmente em uma única cidade

A Lunanode dá aos clientes vários blocos de construção para resiliência. Afuncionalidade de endereço IP flutuantepermite mover um endereço externo entre VMs. Oserviço de balanceador de cargapode distribuir tráfego TCP, HTTP ou HTTPS entre várias máquinas e remover um membro com falha após detecção de problema pelo monitoramento. Os grupos de segurança e asredes privadassuportam aplicações em várias camadas. A API de VM expõe uma opção de grupo de afinidade, e sua resposta inclui um identificador de host físico, permitindo que os clientes busquem posicionamento em hypervisors distintos.

Cada funcionalidade responde a uma falha específica. Dois servidores de aplicação em hypervisors diferentes podem sobreviver a uma queda de host. Um endereço flutuante pode reduzir as mudanças de rede necessárias para ativar uma substituição. Um balanceador de carga pode parar de enviar requisições para um membro com falha. Uma inicialização baseada em volume pode separar dados de um host de computação com falha. O monitoramento pode notificar um operador antes que um usuário relate o problema.

Nenhuma sobrevive automaticamente à perda de Toronto. Duas VMs em hosts diferentes podem compartilhar o mesmo rack, a mesma distribuição elétrica, o mesmo cluster de armazenamento, o mesmo roteador de borda, a mesma instalação e o mesmo upstream. Um balanceador de carga na mesma região pode falhar com seus backends. Um endereço IP flutuante é útil apenas enquanto a rede regional ainda o roteia. Um volume pode sobreviver à exclusão de uma VM, mas permanecer indisponível durante uma falha do plano de armazenamento ou da instalação. A afinidade pode distribuir o posicionamento de computação sem criar separação geográfica.

Os clientes devem, portanto, adaptar o design à falha que os preocupa. Para um site de hobby, um snapshot e a capacidade de recriar uma VM podem ser suficientes. Para um site profissional, instâncias de aplicação separadas, um backup de banco de dados testado e um controle DNS externo podem ser apropriados. Para um serviço com requisitos rigorosos de continuidade, a segunda cópia deve estar em outro provedor ou em outro local operado independentemente, com capacidade suficiente reservada para iniciar a carga de trabalho.

A palavra 'redundante' deve sempre convidar a quatro perguntas: redundante contra o quê, localizado onde, controlado por quem e testado quando? A afirmação da Lunanode de links uplink redundantes pode proteger contra um link com falha. Pode não proteger contra manutenção da Cogent ou um problema de rede em toda a instalação. O RAID10 protege contra certas falhas de disco. Ele não substitui um backup e não impediu todos os eventos de corrupção no arquivo. A replicação Ceph protege contra certas falhas de nó. Ela ainda pode ser afetada quando a energia ou membros de armazenamento correlacionados falham.

A recuperação também depende da capacidade utilizável. A evacuação automática requer um host sobrevivente com CPU e memória suficientes. A restauração a partir de um snapshot requer armazenamento e tempo suficientes. Mover uma imagem grande para fora do site depende da largura de banda. Substituir um host com falha requer um inventário compatível. O registro público não diz qual margem a Lunanode mantém para essas operações, portanto, clientes com objetivos de recuperação rigorosos devem obter respostas específicas em vez de deduzi-las dos nomes das funcionalidades.

O suporte, faturamento e status da conta também são dependências de infraestrutura

A Lunanode direciona clientes com problemas de infraestrutura para abrir um ticket de suporte. Seuserviço de monitoramentosuporta verificações HTTP, expiração de certificado TLS, ICMP, TCP e DNS, com notificações por e-mail, SMS, telefone e webhook. São ferramentas práticas, especialmente quando o destino do alerta está fora do serviço de Toronto. O incidente de e-mail de 2024 demonstra por que um canal de alerta independente é importante.

As páginas públicas não definem um compromisso geral de tempo de resposta ou restauração para planos de nuvem comuns. A página de status frequentemente mostra trabalho ativo, mas não é um cronograma de nível de serviço contratual. Não há declaração pública de cobertura de pessoal 24 horas, níveis de escalonamento, disposições de mão remota, classes de prioridade ou janelas de substituição garantidas. Isso não significa que o suporte está ausente; as atualizações detalhadas de incidentes demonstram intervenção ativa. Significa que um comprador não pode derivar um objetivo de suporte firme dos documentos públicos.

O faturamento também pode interromper um serviço tecnicamente saudável. A Lunanode opera com crédito de conta. SuaAPI de faturamentoexpõe o saldo de crédito restante, enquanto os termos indicam que um e-mail de crédito baixo é enviado pelo menos 48 horas antes de o crédito chegar a zero e que os serviços são suspensos após o saldo se tornar negativo, com pelo menos sete dias de aviso antes da suspensão. Uma falha de pagamento, endereço de contato desatualizado ou notificação perdida pode, portanto, se tornar um evento de disponibilidade.

Os termos também reservam direitos amplos de suspensão e rescisão, descrevem o tratamento de reembolsos e estipulam que a rescisão libera os recursos alocados e exclui os dados associados. Os clientes devem entender essas disposições antes de colocar dados insubstituíveis em uma única conta. A separação operacional pode exigir mais do que duas VMs: pode exigir um backup fora do provedor, DNS e controle de domínio independentes, vários contatos de faturamento, crédito monitorado, recuperação de acesso documentada e um segundo local para operar.

A concentração do suporte é difícil de medir publicamente. Os registros ARIN e PeeringDB nomeiam um contato técnico, mas um contato de registro não revela o tamanho da equipe ou a cobertura de turnos. Nenhuma evidência pública confiável quantifica o quadro de funcionários da Lunanode, pessoal no local ou fila de suporte. A conclusão honesta não é que o suporte é necessariamente enxuto; é que a redundância de pessoal e a profundidade de escalonamento permanecem não verificadas.

A localidade canadense é útil, mas não é uma resposta completa à soberania

A hospedagem em Toronto pode ser atraente para clientes que desejam que seus discos e volumes de VM principais estejam no Canadá. A Lunanode é uma empresa canadense nos registros ARIN, e suas páginas de serviço ao vivo identificam Toronto como o local de computação atual. Isso dá a um comprador mais informações sobre localidade do que um serviço que apenas rotula uma região ampla.

Apolítica de privacidadeda empresa indica que os conteúdos das VMs, volumes e imagens dos clientes são armazenados como dados do usuário e descreve os limites de acesso e divulgação. Seuacordo de privacidade de dadosdescreve a Lunanode como um processador ou subprocessador nas circunstâncias relevantes, autoriza subprocessadores e indica que os clientes escolhem o país onde os dados são armazenados no momento da compra do serviço. Ambos os documentos datam de 2018. Eles permanecem publicados, mas sua idade e referências à escolha do país devem ser conciliadas com as evidências atuais de provisionamento apenas em Toronto.

A localização de dados tem vários níveis. O disco primário pode estar em Toronto enquanto mensagens de monitoramento, registros de pagamento, comunicações de suporte ou backups gerenciados pelo cliente usam outros provedores e jurisdições. Um cliente pode acessar dados hospedados em Toronto de qualquer lugar. Um subprocessador pode participar do fornecimento de parte do serviço. O registro de domínio, processamento de pagamentos, entrega de SMS e conectividade upstream têm seus próprios limites de operadora. O armazenamento canadense é, portanto, um fato significativo, não uma conclusão jurídica ou operacional completa.

Os fechamentos de 2023 também mostram por que a localidade deve ser monitorada ao longo do tempo. Roubaix oferecia antes um local francês; Montreal oferecia uma segunda cidade canadense. Quando ambos fecharam, os clientes tiveram que aceitar Toronto ou sair. Um contrato ou avaliação de conformidade deve identificar o local aprovado, as expectativas de notificação, o processo de exportação e a resposta exigida se esse local for retirado.

A portabilidade é comparativamente tangível na Lunanode. Snapshots podem ser baixados. Os clientes podem fazer upload de suas próprias imagens e mídias de instalação. Volumes podem ser convertidos em imagens. Endereços IP flutuantes podem ser desanexados dentro da plataforma, embora o endereço geralmente não possa seguir o cliente para um provedor não relacionado. Esses controles podem reduzir o aprisionamento se o cliente realmente os exercer.

Um formato de imagem, chave de criptografia, zona DNS, registro de configuração e um backup de dados independente e recente são mais úteis do que um botão de exportação teórico descoberto durante uma emergência.

Uma avaliação séria da localidade deve, portanto, perguntar onde reside cada classe de dados, quem pode acessá-los, quais condições legais se aplicam, como os backups saem de Toronto, com que rapidez o cliente pode recuperar uma cópia completa e se essa cópia inicia com sucesso em outro lugar. Os documentos públicos da Lunanode fornecem um ponto de partida. Eles não respondem a toda a avaliação para cada carga de trabalho.

O que aumentaria o nível de evidência

A pegada pública da Lunanode não está vazia. Ela é mais sólida do que sugere uma leitura rápida de sua modesta presença de marketing. A empresa tem páginas de produtos e preços ao vivo, instruções de provisionamento atuais para Toronto, avisos de status detalhados até 2026, espaço de endereçamento ativo, AS394745, anúncios IPv4 e IPv6, presença TorIX e uma superfície de controle de longa data. São sinais críveis de um pequeno provedor de nuvem em operação.

O nível para em Médio porque os fatos de resiliência mais importantes permanecem não divulgados. Os documentos públicos não indicam o número de racks ou hypervisors ativos, as gerações de servidores atuais na frota, a energia contratada, a margem de energia disponível, o número de nós de armazenamento, a disposição de replicação, o número de hosts de reposição, o inventário de peças sobressalentes, os contratos de trânsito, a diversidade de rotas físicas, a equipe de suporte, o número de clientes, a utilização, os objetivos de recuperação ou os resultados de testes de restauração.

Eles mostram uma cidade de computação ativa e nenhum segundo local verificado para failover do cliente.

As evidências que aumentariam o nível não precisam expor detalhes sensíveis. A Lunanode poderia publicar uma nota de arquitetura atual que distingue os domínios de falha da instalação, rack, host e armazenamento; confirmar se as cargas de trabalho dos clientes ocupam mais de um domínio de energia; identificar as classes de diversidade upstream; descrever como o posicionamento de afinidade se relaciona com os racks; descrever o comportamento atual de replicação e evacuação de volumes; e fornecer métricas globais de disponibilidade e incidentes.

Uma declaração atual de backup e localização de dados poderia substituir a ambiguidade deixada pelos documentos de 2018 e pelas instruções multirregião históricas.

Para um cliente, as perguntas imediatas são práticas. A VM está em disco local ou em volume? As réplicas estão em hosts e racks distintos? A aplicação sobrevive a uma falha de host? O backup está fora da Lunanode e fora de Toronto? Ele pode ser restaurado em outro hypervisor ou outro provedor? O monitoramento ainda alerta quando Toronto não pode enviar e-mail? Quem monitora o crédito da conta? O que acontece se uma região for retirada? Quanto de dados deve atravessar a rede durante a recuperação, e quanto tempo durou o último teste?

A proposta de valor da Lunanode não exige que ela se pareça com uma nuvem hyperscale. Um provedor canadense compacto pode ser uma boa escolha quando preço, simplicidade, faturamento por hora e localidade em Toronto são importantes. As evidências suportam essa proposta mais restrita. Elas não suportam tratar capacidade hospedada de baixo custo como sem localização ou autorreparável por padrão.

O fato central de infraestrutura é simples: a Lunanode vende uma interface flexível para máquinas reais em uma instalação real em Toronto. Sua própria história mostra reparos que dependiam de servidores sobressalentes, fontes de alimentação compatíveis, verificações de sistema de arquivos, quorum de armazenamento, técnicos upstream e migração de clientes. Os compradores podem usar snapshots, volumes, balanceadores de carga, endereços flutuantes e monitoramento da plataforma para construir resiliência.

A última camada ainda é deles: manter uma cópia independente, reservar outro local para operar e testar o caminho antes que um rack, rota, conta ou contrato comercial force a mudança.