Resumo

  • O objeto de rede pública preciso por trás do nome do diretório não é atualmente uma borda de rota ativa.A visão geral de AS do RIPEstat para AS203301identifica o titular como Cloud 9 Ltd. Data Center, mas marca o ASN como não anunciado em 12 de julho de 2026, eo status de roteamento do RIPEstatmostra zero espaço anunciado IPv4 ou IPv6.
  • A mesma organização Cloud 9 Ltd. tem um sinal operacional ativo muito mais forte através de AS57814.O status de roteamento do RIPEstat para AS57814mostra o ASN anunciado com 27 prefixos IPv4, 3 prefixos IPv6 e 12 vizinhos observados, enquantoo texto do registro RIPEvincula AS57814 a ORG-CL434-RIPE, a organização Cloud 9 Ltd.
  • O site público da Cloud9 comercializa um data center neutro em relação a operadoras em Tbilisi, colocation, VPS, VDS, servidores dedicados, domínios e hospedagem compartilhada. Sua própriapágina de data centerafirma que a maioria dos serviços é entregue a partir de sua instalação em Tbilisi e lista alegações sobre energia, refrigeração, extinção de incêndios, segurança e interconexão.
  • As alegações de resiliência física são incomumente específicas, mas ainda são alegações orientadas ao comprador. A Cloud9 diz que a instalação utiliza três subestações elétricas independentes, um gerador a diesel de 630 KVA, alimentação N+N para a zona de colocation, refrigeração DX, extinção de incêndios Novec 1230, acesso programado à instalação e cobertura de engenharia 24/7; os clientes ainda precisam de histórico de manutenção, tempo de funcionamento do gerador, evidência de failover de refrigeração e restauração.
  • O grau de evidência é Médio. Existe evidência real da instalação da Cloud 9 Ltd. e roteamento de AS57814, além de entradas do PeeringDB para Cloud9 Dinamo Arena e IXP.ge, mas o objeto exato AS203301 está inativo e o material público não demonstra capacidade auditada, operação de serviços públicos duais ativa, diversidade de rotas de operadoras, margem de energia excedente ou resultados de failover de clientes.

A empresa é visível, mas o ASN do data center atribuído está inativo

O primeiro teste para o Cloud 9 Ltd. Data Center não é se a marca tem um site. É se a identidade de rede pública exata anexada ao assunto do diretório está realizando trabalho hoje. Nessa questão, a resposta é uma degradação.A visão geral de AS do RIPEstat para AS203301nomeia o titular como Cloud 9 Ltd. Data Center e mostra o ASN como atribuído, mas também informa que o ASN não está anunciado.O status de roteamento do RIPEstat para AS203301não mostra prefixos IPv4 anunciados, nem prefixos IPv6 anunciados nem vizinhos observados na visualização de 12 de julho de 2026.

Isso não é uma nota de rodapé menor. Se um cartão de diretório, tabela de roteamento, memorando de aquisições ou nota de cliente trata AS203301 como a borda pública atual de um serviço de data center, a evidência atual não suporta esse tratamento.Os prefixos anunciados do RIPEstat para AS203301retornam uma lista atual vazia.O histórico de roteamento do RIPEstatmostra que AS203301 originou anteriormente 185.139.56.0/22 de 2016 até outubro de 2023, então o ASN nem sempre esteve inerte. Mas uma rota histórica não é capacidade de cliente utilizável em 2026. É evidência de operação anterior, não de serviço presente.

O ponto mais interessante é que o AS203301 inativo não faz desaparecer a Cloud 9 Ltd. Ele obriga a uma separação entre um ASN de data center atribuído e a rede atual mais ampla da operadora.A visão geral de AS do RIPEstat para AS57814identifica AS57814 como Cloud9 Cloud 9 Ltd. e o marca como anunciado.O status de roteamento do RIPEstat para AS57814relata 27 prefixos IPv4, 3 prefixos IPv6 e visibilidade completa do coletor de rotas na visualização verificada.Os dados derivados do registro RIPE para AS57814vinculam o ASN a ORG-CL434-RIPE, o mesmo identificador de organização da Cloud 9 Ltd. visível emo registro de organização do RIPE.

A leitura responsável é, portanto, nem demissão nem confiança cega. AS203301 não deve ser tratado como uma borda ativa sem evidência fresca. AS57814 mostra que a operação da Cloud9 tem uma pegada roteada real. Um cliente que avalia colocation, VPS ou servidores dedicados deve perguntar qual ASN e prefixos transportam o serviço adquirido, se AS203301 foi retirado, reservado ou reutilizado, e se algum serviço orientado ao cliente ainda depende de seu antigo plano de rota. A distinção importa porque a identidade de rede não é marca. É o caminho através do qual os sistemas de clientes alcançáveis sobrevivem a uma falha.

A instalação comercializada é uma âncora única em Tbilisi

A posição pública da Cloud9 é direta: suapágina de data centerapresenta a empresa como uma operadora de data center neutra em relação a operadoras na Geórgia e diz que a maioria dos serviços da Cloud9 é entregue a partir de seu data center em Tbilisi. O rodapé e apágina de contatofornecem a localização operacional como 2 Akaki Tsereteli Avenue, Dinamo Stadium, Gate 5, Tbilisi, Georgia 0112.O registro de instalação do PeeringDB para Cloud9 Dinamo Arenatambém coloca uma instalação chamada Cloud9 Dinamo Arena na A. Tsereteli Ave 2 em Tbilisi, com Cloud9 LTD como a organização e contatos de e-mail de suporte.

Isso é melhor do que uma página vaga na nuvem sem um local anexado. A pegada pública dá ao comprador uma pergunta no nível do edifício a fazer. O problema é que um endereço de edifício não é o mesmo que um mapa de capacidade completo. A Cloud9 pode apontar de forma crível para uma instalação em Tbilisi, mas o material público não revela o número de salas, gabinetes ativos, gabinetes de reposição, consumo de energia, reserva de refrigeração, contratos de combustível, tempo de funcionamento do gerador sob carga medida, diversidade de entrada de operadoras ou a quantidade de capacidade do cliente que permanece após a falha de um componente.

O site da Cloud9 também vincula vários serviços a esta âncora física. Suapágina de colocationvende arranjos de 1U, 2U, servidor torre, meio rack, rack completo e gaiola. Suapágina de VPSvende servidores privados virtuais gerenciados e autogerenciados. Suapágina de VDSvende porções virtuais maiores, e suapágina de servidor dedicadovende servidores físicos. Ostermos de serviçoda empresa listam serviços de hospedagem, colocation, data center, aluguel de racks, conexões cruzadas, unidades de distribuição de energia e interconexão de provedores de Internet como serviços oferecidos.

Essa amplitude de produtos aumenta as apostas. Uma falha em uma âncora em Tbilisi pode afetar os clientes de diferentes maneiras: um cliente de colocation pode ser proprietário do hardware que falha, mas depende da Cloud9 para energia, refrigeração, acesso e conexões cruzadas; um cliente de VPS pode depender da Cloud9 para servidor, armazenamento, plataforma de virtualização e backups; um cliente de servidor dedicado pode depender da Cloud9 para substituição do servidor, acesso remoto e continuidade de rede.

Portanto, a mesma interrupção pode parecer um evento de energia, um evento de refrigeração, um evento de roteamento ou um evento de suporte, dependendo do contrato do cliente.

A evidência de localização é suficientemente sólida para tornar a análise concreta. Não é suficiente para que o serviço seja resiliente por si só. O comprador ainda precisa saber se a instalação em Tbilisi é o único site de produção ativo para o serviço adquirido, se os backups saem do local, se o failover utiliza outra localização da Cloud9 ou apenas outro cluster no mesmo edifício, e se os contratos dos clientes distinguem entre "disponível para venda" e "utilizável após uma falha".

As alegações de energia são específicas, mas o tempo de funcionamento ainda é o teste

As alegações públicas de energia da Cloud9 são incomumente específicas para um provedor de hospedagem regional. Apágina de data centerafirma que a instalação é alimentada por três subestações elétricas independentes e tem um gerador a diesel de 630 KVA. A mesma página diz que a zona de colocation utiliza alimentação redundante N+N com suporte UPS. Apágina de colocationrepete a promessa em termos orientados ao cliente: os pacotes de rack listam alimentação dupla A/B para servidores 1U e 2U, enquanto o serviço de servidor torre é listado com alimentação única.

Esses detalhes são úteis porque criam perguntas mensuráveis. Três subestações podem reduzir a concentração de serviços públicos, mas a frase não revela se as alimentações estão simultaneamente ativas, se entram no edifício por caminhos fisicamente separados, se o equipamento de comutação tem um único ponto de falha, se a manutenção pode ser realizada sem expor os clientes, ou se todos os gabinetes de colocation podem consumir sua carga contratada durante um evento de serviços públicos. Um gerador de 630 KVA é um equipamento sério, mas o número relevante não é a classificação da placa.

É o tempo de funcionamento testado e o perfil de carga após a transferência UPS, a entrega de combustível, a demanda de refrigeração e as cargas do edifício não relacionadas à TI.

A energia N+N também é uma alegação que precisa de prova no nível do gabinete. Se ambos os lados de um gabinete de alimentação dupla são genuinamente independentes, uma falha de alimentação única não deve desligar o equipamento do cliente com cabeamento duplo.

Mas muitas falhas de cliente ocorrem na borda de um plano de energia bem projetado: um dispositivo com um único cabo conectado através da unidade de distribuição de energia errada, um lado A sobrecarregado durante a manutenção, um desarme de disjuntor causado por um pico do cliente, um teste de gerador que não inclui carga real, ou uma tarefa de mãos remotas que deixa um cabo na rota errada. O material público da Cloud9 não mostra com que frequência o failover é testado ou como os clientes recebem evidências.

O pacote de servidor torre importa porque utiliza abertamente alimentação única. Isso não é um defeito; é um nível de serviço. Significa que os clientes não podem inferir a resiliência energética de todo o data center a partir de um produto que pode usar uma rota elétrica no dispositivo. O comprador deve combinar a criticidade da carga de trabalho com o design do equipamento. Um servidor não crítico pode racionalmente aceitar uma única rota de alimentação.

Um sistema de produção que deve sobreviver a uma falha de alimentação precisa de equipamento com cabeamento duplo, distribuição A/B testada, margem de energia excedente suficiente e um contrato que explique o que a Cloud9 fará durante a manutenção.

A pergunta mais importante sobre energia não é se a página de marketing nomeia componentes. É se a Cloud9 pode fornecer evidências recentes e relevantes para o cliente: último teste de carga completa do gerador, datas de teste de transferência, janelas de manutenção de UPS, acordo de fornecimento de combustível, densidade máxima de rack suportada, carga real do cliente e histórico de incidentes. Sem essas evidências, a instalação pode ainda ser boa, mas o comprador está confiando em uma promessa em vez de um estado de falha demonstrado.

A refrigeração, proteção contra incêndios e segurança reduzem os possíveis caminhos de falha

A página da instalação oferece um conjunto comparável de alegações para refrigeração, proteção contra incêndios e segurança física. A Cloud9 diz que a temperatura e a umidade são controladas por um sistema de refrigeração DX. Diz que as salas de servidores não têm janelas nem paredes externas, e que o encanamento próximo é limitado ao sistema de extinção de incêndios. Também diz que o data center utiliza detecção precoce de temperatura, fumaça e fogo, além de um sistema de extinção de incêndios Novec 1230. Para o controle de acesso, a página aponta CCTV, controles biométricos, um edifício com padrão sísmico e instalações vigiadas.

Essas alegações importam porque uma interrupção do data center muitas vezes não é uma interrupção pura de energia. A refrigeração pode se tornar a restrição vinculante durante um evento de rede elétrica, um evento do gerador ou uma implantação de gabinete de alta densidade. Se a capacidade de ar resfriado, o gerenciamento do fluxo de ar ou a redundância do compressor são fracos, os servidores podem ficar sem margem térmica mesmo quando a energia ainda está disponível.

A refrigeração DX pode ser uma opção de design perfeitamente válida, mas o cliente precisa conhecer o número de unidades, o padrão de redundância, a prática de manutenção, a disponibilidade de peças de reposição e a capacidade de remoção de calor na densidade de rack contratada.

A proteção contra incêndios também tem um limite estrito. A presença de um sistema de extinção de incêndios baseado em gás é reconfortante apenas se a detecção, zoneamento, retenção de pressão, resposta da equipe e comunicação com o cliente estiverem atualizadas. Uma descarga falsa pode interromper o serviço. Um incêndio real pode tornar o acesso impossível mesmo que o equipamento não seja destruído. A fumaça ou danos por calor podem deixar o equipamento do cliente em um estado incerto. A alegação pública mostra uma camada de proteção pretendida, não a rota de recuperação testada após um alarme.

A segurança tem uma distinção semelhante. Os controles biométricos, CCTV e guardas reduzem o risco de acesso não autorizado. Eles não respondem quem pode entrar durante uma emergência, como o acesso do cliente é aprovado, quão rápido uma tarefa de mãos remotas pode ser realizada, ou se o acesso à instalação permanece disponível durante uma interrupção em toda a cidade. AsFAQs de colocationda Cloud9 dizem que as visitas de clientes devem ser agendadas e que os visitantes precisam de identificação válida. Os termos dizem que os clientes de colocation podem solicitar acesso 24/7 mediante acordo prévio através da conta de cliente ou e-mail. Essas regras são sensatas, mas também significam que o acesso é mediado pela equipe de suporte e instalações da Cloud9.

Por isso, a infraestrutura física deve ser lida como um sistema. Energia, refrigeração, proteção contra incêndios, controle de acesso e mão de obra de suporte não são caixas de marketing independentes. Uma unidade de refrigeração com falha pode exigir trabalho elétrico. Um evento de energia pode aumentar a carga de refrigeração. Um alarme de incêndio pode suspender o acesso. Uma regra de segurança pode desacelerar o reparo.

Um cliente deve perguntar à Cloud9 sobre o cenário combinado: o que acontece se uma alimentação falhar enquanto um componente de refrigeração está em manutenção, ou se um servidor de cliente precisar de trabalho manual durante uma restrição de acesso à instalação?

A neutralidade de operadora deve significar mais do que uma lista de operadoras

A Cloud9 usa a frase neutro em relação a operadoras em suapágina de data centere diz que também é uma operadora de IXP. A mesma página afirma que a Cloud9 está conectada a operadoras de telecomunicações líderes e operadoras ISP menores através de fibra escura reservada com várias rotas alternativas e capacidade total de interconexão de 250 Gbps. Apágina de colocationdiz que as conexões de fibra direta para as principais ISPs locais ajudam a oferecer baixa latência de alcance local.

A evidência de roteamento suporta parcialmente a história de interconexão.Os vizinhos ASN do RIPEstat para AS57814mostram 12 vizinhos observados na visualização verificada, incluindo redes georgianas como Magticom, Caucasus Online, System Net, Silknet e Skytel, bem como outras redes adjacentes e IXP.ge.O perfil de rede do PeeringDB para AS57814lista a Cloud9 como uma rede de serviços de rede regional com suporte IPv6, política de peering aberta, uma instalação e uma presença de troca.A entrada netixlan do PeeringDB para Cloud9mostra uma conexão de 10 Gbps no IXP.ge.

Esses são sinais significativos. Tampouco são suficientes para provar a diversidade de rotas de operadoras. Os coletores de rotas podem mostrar ASNs adjacentes, mas não podem mostrar se operadoras separadas entram por dutos separados, se as conexões cruzadas compartilham uma sala de meet-me, se um upstream domina a acessibilidade internacional, se os pares locais transportam tráfego de produção durante uma falha de upstream, ou se os contratos dos clientes incluem alguma garantia de diversidade de rotas. Uma rede pode ter vários vizinhos lógicos e ainda assim compartilhar uma rota física vulnerável.

A política de rota pública de AS57814 emos dados derivados do registro RIPEnomeia vários ASNs upstream ou adjacentes em declarações de importação e exportação. O registro exato de AS203301 é mais estreito:os dados derivados do registro RIPE para AS203301listam declarações de política envolvendo AS34797 e AS35076, enquanto o status de rota atual não mostra anúncios ativos. Essa diferença é outra razão para perguntar qual plano de rota se aplica a um determinado serviço de cliente.

A alegação de neutralidade de operadora é, portanto, plausível, mas incompleta. Um cliente deve perguntar sobre os upstreams atuais, acordos de peering públicos e privados, opções de conexão cruzada, rotas físicas do meet-me, compromissos de notificação de manutenção, práticas de segurança de rota e resultados medidos de failover. A frase "neutro em relação a operadoras" deve significar que um cliente pode tomar decisões reais entre operadoras e rotas. Não deve significar simplesmente que a instalação está disposta a vender uma conexão cruzada se o cliente puder organizar uma.

AS57814 mostra amplitude que AS203301 não tem

A evidência de rede atual mais forte é AS57814, não AS203301. Na visualização do RIPEstat de 12 de julho de 2026, AS57814 tem uma pegada ampla para uma operadora regional de hospedagem e data center georgiana: 27 prefixos IPv4, 3 prefixos IPv6 e visibilidade completa dos peers do RIPE RIS em ambas as famílias de endereços.Os prefixos anunciados do RIPEstat para AS57814incluem rotas IPv4 como 188.93.94.0/24, 185.139.56.0/24, 185.139.57.0/24, 185.139.58.0/24, 45.138.44.0/22 e vários outros /24, além de espaço IPv6 incluindo 2a0d:8a00::/32.

Essa amplitude muda a conclusão do artigo. Se apenas AS203301 existisse, o grau de evidência seria fraco ou negativo para o roteamento presente. AS57814 evita isso. Mostra uma rede ativa da Cloud 9 Ltd. com IPv4 e IPv6, múltiplos vizinhos e suporte atual de segurança de roteamento.A validação RPKI do RIPEstat para 188.93.94.0/24 sob AS57814retorna válido, e o mesmo é verdade para os /24 da Cloud9 verificados extraídos do espaço 185.139.56.0/22 mais antigo.

O contraste com AS203301 é acentuado.A visão geral de prefixo do RIPEstat para 185.139.56.0/22mostra que o agregado em si não está anunciado, com /24 relacionados agora visíveis.A consistência de roteamento de prefixo do RIPEstat para 185.139.56.0/22mostra 185.139.56.0/24, 185.139.57.0/24 e 185.139.58.0/24 em BGP ativo sob AS57814, enquanto o objeto de rota /22 não está ativo.A validação RPKI do RIPEstat para AS203301 e 185.139.56.0/22retorna um resultado de ASN inválido porque a autorização de rota na visualização verificada aponta para AS57814, não para AS203301.

Isso não significa que a Cloud9 esteja roteando incorretamente. Significa que a autoridade de rota ativa parece ter se movido para AS57814. Para um comprador, isso é um problema de documentação e um problema de resiliência. Contratos, descrições de serviço e manuais de incidentes devem nomear o ASN que realmente transporta o tráfego do serviço. Se AS203301 é mantido como um objeto de data center inativo ou herdado, a Cloud9 deve ser clara sobre isso. Se espera-se que ele retorne, a autorização de origem de rota e a política de rota devem ser alteradas antes que o tráfego do cliente dependa dele.

IXP.ge melhora a história local, mas não elimina o risco internacional

A alegação de interconexão da Cloud9 é favorecida pela evidência do IXP.ge.O registro do PeeringDB para IXP.geidentifica IXP.ge, também conhecido como Geo-IX, em Tbilisi e observa que o exchange está disponível em Tbilisi e Kutaisi.A própria página do IXP.gedescreve o propósito da associação de exchange como a troca direta de tráfego de Internet entre redes georgianas sem usar redes de terceiros.A página de membros do IXP.gelista a Cloud9 entre os membros completos.

Isso é positivo para a acessibilidade local. Quando ISPs locais, provedores de hospedagem e redes de serviço trocam tráfego localmente, o tráfego doméstico pode evitar desvios desnecessários através de trânsito estrangeiro. Menor latência e menos dependência de uma única rota estrangeira podem importar para clientes georgianos, conteúdo, serviços governamentais e pequenas empresas que atendem principalmente usuários dentro do país. Também se encaixa com a alegação da Cloud9 de que a conectividade local é um diferencial.

A participação no IXP não deve ser confundida com redundância total. O peering em um exchange pode reduzir a carga no trânsito upstream e melhorar as rotas locais, mas não protege automaticamente um cliente contra uma falha de energia na instalação, falha de switch, problema no servidor de rota, ruptura de fibra, congestionamento internacional ou interrupções de DNS e camada de aplicação. O PeeringDB lista a porta IXP.ge da Cloud9 a 10 Gbps no registro verificado; a própria página de data center da Cloud9 anuncia separadamente 250 Gbps de capacidade total de interconexão.

Esses dois números podem ser ambos verdadeiros se o último incluir conexões cruzadas privadas, upstreams e outra capacidade local. Os registros públicos não reconciliam a composição.

A pergunta mais relevante é quais rotas transportam qual tráfego quando algo quebra. Se o upstream internacional principal falhar, quanto tráfego é movido para outros upstreams e com que qualidade? Se a porta IXP falhar, os usuários locais ainda são acessíveis através de trânsito? Se uma rota de fibra para o Dinamo Arena for danificada, as rotas alternativas são realmente separadas? Se um cliente compra uma conexão cruzada, ela está em uma rota diversa dos links upstream da Cloud9 ou no mesmo feixe físico?

O material público da Cloud9 dá ao comprador o suficiente para fazer boas perguntas. Não fornece o suficiente para tratar o peering local como recuperação de desastres. A melhor versão do serviço combinaria uma borda AS57814 ativa, tráfego local do IXP.ge, vários upstreams independentes, higiene de segurança de rota visível e opções claras de engenharia de tráfego para o cliente. O registro público suporta parte dessa imagem. Deixa a rota física e os testes de failover para serem provados.

Os pacotes de colocation revelam onde a capacidade utilizável pode ser reduzida

O menu de colocation da Cloud9 é incomumente transparente sobre o pacote base. Apágina de colocationlista pacotes de rack 1U e 2U com alimentação dupla A/B, link de 1 Gbps e um link de gerenciamento separado. Também lista uma opção de servidor torre com alimentação única. A página afirma que cada cliente recebe conectividade sem medição de 1 Gbps para ISPs georgianos e 30 Mbps de conectividade global, e descreve opções de meio rack, rack completo e gaiola como arranjos personalizados ou empresariais.

Esses números não são apenas preços. Eles definem a restrição visível para o cliente. A conectividade local pode ser abundante em relação a muitas cargas de trabalho pequenas, enquanto a conectividade global por cliente de colocation básico é limitada. Um cliente georgiano que atende principalmente usuários domésticos pode achar isso aceitável. Uma empresa que atende usuários internacionais, trabalhadores remotos, APIs transfronteiriças ou backups globais deve testar a rota global cuidadosamente.

Trinta megabits por segundo podem ser suficientes para gerenciamento, sites pequenos ou serviços de baixo tráfego, mas não é uma alegação de capacidade de nuvem geral.

A distinção entre capacidade instalada e utilizável importa aqui. Uma instalação pode anunciar alta agregação de interconexão enquanto produtos individuais são vendidos com alocações globais mais estreitas. Um rack pode ter alimentação dupla enquanto o próprio servidor do cliente tem uma única fonte de alimentação. Um link de gerenciamento pode estar disponível enquanto um sistema operacional com falha ainda requer ação humana. Uma gaiola pode ser personalizada enquanto os recursos compartilhados da instalação, o agendamento de acesso e a capacidade do gerador permanecem comuns.

As FAQs da Cloud9 são úteis porque estabelecem limites. Para colocation, a falha de hardware continua sendo responsabilidade do cliente, enquanto a Cloud9 diz que auxiliará com o reparo. As visitas devem ser agendadas. As instalações de rack completo e gaiola podem levar mais tempo do que uma instalação de servidor único. Esses são termos normais, mas significam que a recuperação é compartilhada. Um cliente não pode terceirizar cada falha simplesmente colocando equipamento na instalação.

Portanto, o cliente deve solicitar uma tabela de resiliência por produto. Para o serviço 1U e 2U, o que acontece se uma alimentação falhar? Para o serviço torre, há alguma redundância de alimentação única disponível através de um interruptor de transferência automática? Para meios racks, qual densidade de energia está incluída? Para gaiolas, quais opções de operadora são fisicamente alcançáveis? Para todos os tipos de serviço, quanta capacidade global permanece disponível durante a manutenção ou falha do upstream? As tabelas de pacotes públicas são um ponto de partida útil, não a resposta final.

Os servidores VPS, VDS e dedicados convertem as alegações da instalação em compromissos com o cliente

Os produtos de servidor hospedado adicionam outra camada. Apágina de VPSda Cloud9 oferece pacotes gerenciados e autogerenciados com virtualização KVM, backups diários, opções de painel de controle e velocidades de rede local e global anunciadas. Apágina de VDSoferece servidores virtuais de recursos fixos maiores. Apágina de servidor dedicadolista pacotes gerenciados e autogerenciados, diz que os servidores podem ser configurados dentro de 24 a 48 horas quando disponíveis em estoque, e descreve unidades de nível empresarial, conexões de rede redundantes e fontes de alimentação redundantes.

Essas alegações movem o risco de uma pergunta pura de instalação para uma pergunta de operações. Para clientes de VPS e VDS, a Cloud9 controla o host, armazenamento, camada de virtualização, sistema de backup, alocação de IP, painel de controle e canal de suporte. Um cliente pode não saber qual servidor físico ou rack transporta a carga de trabalho. Portanto, o teste de resiliência deve incluir testes de restauração de backups, resposta a falhas do host, isolamento de armazenamento, monitoramento, comunicação com o cliente e a capacidade de mover um servidor virtual sem uma interrupção prolongada.

Os backups diários são úteis, mas uma alegação de backup não é uma alegação de recuperação até que o tempo de restauração seja conhecido. Um site pequeno pode tolerar uma restauração no dia seguinte. Um portal comercial ou serviço transacional pode não tolerar. Os backups também precisam de detalhes de localização. Se os backups residem na mesma instalação, eles podem proteger contra exclusão de arquivos e falhas de servidor, mas não contra um incidente em toda a instalação.

Se os backups saírem da instalação, o comprador precisa saber para onde vão, como estão criptografados, quão rápido podem ser restaurados e o que acontece quando o cliente sai.

Os servidores dedicados criam uma carga diferente. A Cloud9 diz que a disponibilidade do processador depende do estoque, e requisitos personalizados podem adicionar tempo de instalação. Isso é normal, mas importa durante uma falha. Se um servidor dedicado falhar, há um hot spare, uma substituição no mesmo dia, ou apenas estoque de melhor esforço? Se um disco falhar, quem o substitui e quão rápido? Se o cliente autogerencia o servidor, onde termina a responsabilidade da Cloud9? Se as conexões de rede e energia redundantes estão presentes, elas estão conectadas a rotas de instalação independentes?

Portanto, a pergunta central do artigo não é se a Cloud9 vende produtos hospedados. Claramente ela vende. A pergunta é se a capacidade comercializada pode se tornar um resultado de recuperação testado para cada produto. Clientes de VPS, VDS, servidor dedicado e colocation compram diferentes partes da pilha. Eles devem receber diferentes evidências de resiliência.

Os termos revelam um limite de manutenção e acesso

Ostermos de serviço da Cloud9são importantes porque revelam partes do limite operacional que as páginas de marketing não revelam. Os termos nomeiam Cloud 9 LLC, fornecem o ID da empresa 405063755, indicam um endereço legal georgiano e listam as categorias de produtos oferecidos através do site e portal da Cloud9. Eles definem serviços de data center para incluir aluguel de racks de telecomunicações, conexões cruzadas, unidades de distribuição de energia, interconexão de provedores de Internet e operadoras móveis, e aluguel de endereços IP.

Para colocation, os termos dizem que os clientes devem reservar o acesso à instalação através da conta de cliente ou e-mail, fornecer detalhes do visitante e seguir as regras de conduta do data center. Também dizem que os clientes podem solicitar acesso 24/7 mediante acordo prévio e podem solicitar serviço de mãos remotas 24/7 para tarefas como reinicialização ou substituição de cabos. Esses são compromissos valiosos, mas ainda dependem da disponibilidade da equipe, do gerenciamento de tickets e das condições da instalação no momento do incidente.

A declaração de manutenção mais importante é que a Cloud9 está autorizada a realizar trabalhos técnicos planejados para o serviço de colocation, com duração não superior a oito horas. Essa cláusula não deve ser lida como uma garantia de interrupção, mas é um limite operacional sério. Se um cliente precisa de serviço contínuo, ele deve entender se o trabalho planejado pode afetar uma alimentação, um roteador, uma rota de meet-me, uma gaiola de cliente ou o serviço completo. Também deve entender quanto aviso é dado, se clientes redundantes podem evitar o impacto e como os trabalhos de emergência diferem dos trabalhos planejados.

Os termos também prometem suporte técnico 24/7 por e-mail, e apágina de contatodiz que o e-mail abre um ticket. Isso é útil para operações de serviço, mas o suporte baseado em e-mail pode ser frágil durante incidentes se o sistema de e-mail do cliente estiver hospedado no mesmo provedor ou se o portal for afetado. Um cliente sério deve manter uma rota de contato fora de banda e saber se o suporte pode agir quando a identidade do cliente, faturamento ou acesso ao portal estiverem afetados.

Os contratos geralmente contêm a resposta real ao risco de infraestrutura. As páginas de marketing descrevem o que a operadora quer vender. Os termos descrevem onde a responsabilidade é compartilhada, limitada ou programada. No caso da Cloud9, os termos não prejudicam a história do data center; eles a tornam mais concreta. Mostram que o acesso do cliente, mãos remotas, trabalhos planejados, backups e suporte fazem parte do limite do serviço. O trabalho do comprador é converter essas cláusulas em compromissos operacionais mensuráveis.

A imagem de segurança de rota é melhor na borda ativa

A segurança de rota é uma área onde a borda ativa da Cloud9 parece melhor do que o ASN inativo.A validação RPKI do RIPEstat para 188.93.94.0/24 originado por AS57814retorna válido. Os prefixos verificados da Cloud9 185.139.56.0/24, 185.139.57.0/24, 185.139.58.0/24, 45.138.44.0/22 e 2a0d:8a00::/32 também retornam válido quando testados contra AS57814. Esse é um sinal de higiene positiva para as rotas que os clientes têm mais probabilidade de ver hoje.

A imagem exata de AS203301 é o oposto. O agregado antigo 185.139.56.0/22 não está ativo como agregado navisão geral de prefixoverificada, e uma verificação de validação de origem de AS203301 para esse agregado retorna ASN inválido porque a autorização visível é para AS57814. Isso não deve ser sensacionalizado. Simplesmente reforça que AS203301 não é a borda de rota atual para o bloco de endereços antigo.

Para um comprador de data center, isso importa porque a validação de origem de rota pode afetar a acessibilidade durante uma mudança de rota. Se um provedor move um prefixo entre ASNs, muda upstreams, introduz um anúncio de backup ou desagrega durante um incidente, a autorização de rota deve corresponder. Caso contrário, as redes que filtram rotas inválidas podem derrubar o tráfego exatamente no momento em que a resiliência é necessária. A evidência da Cloud9 em AS57814 é encorajadora porque a borda ativa valida. AS203301 deve ser documentado como inativo a menos que e até que a autorização e o plano de rota sejam alterados.

A pergunta do comprador é simples: quais prefixos meu serviço usará, qual é o status RPKI atual deles e quem pode alterar as autorizações durante uma emergência? Para clientes de colocation que trazem seus próprios endereços, a pergunta é se a Cloud9 suporta objetos de rota de clientes, ROAs, sessões BGP e mudanças de rota de emergência com rapidez suficiente. Para endereços fornecidos pela Cloud9, a empresa deve ser capaz de mostrar o status de origem válido atual e explicar seu plano de anúncio de backup.

A segurança de rota não manterá um gerador funcionando nem uma unidade de refrigeração online. No entanto, elimina um modo de falha evitável. Em uma instalação que vende neutralidade de operadora e capacidade hospedada, o plano de controle da rede deve estar tão bem documentado quanto a planta de energia.

A capacidade instalada não é o mesmo que capacidade pronta

A questão de capacidade deve ser dividida em três camadas: o que a Cloud9 tem instalado, o que está disposta a vender e o que permanece pronto após uma falha ou solicitação de expansão. O site público é rico em categorias de serviço, mas escasso em margem física. Anuncia unidades de colocation, meios racks, racks completos e gaiolas napágina de colocation, e anuncia requisitos personalizados de data center napágina de data center. Não publica disponibilidade de gabinetes ao vivo, limites de densidade de energia, margem de refrigeração reservada, capacidade de disjuntor excedente, inventário de servidores de reposição ou o tempo necessário para adicionar uma nova rota de operadora.

Essa camada ausente importa porque a capacidade comercializada pode se tornar limitada antes que uma sala esteja cheia. Um rack pode estar fisicamente vazio, mas não disponível na densidade de energia que um cliente precisa. Um gerador pode suportar a carga atual, mas deixar pouca margem para uma nova fileira de alta densidade. Um design de refrigeração pode suportar racks de hospedagem padrão, mas exigir mudanças para computação densa. Uma entrada de fibra pode suportar provedores atuais, mas precisar de novo trabalho civil para uma rota diversa solicitada.

Em cada caso, a página de vendas pode ser verdadeira enquanto a capacidade utilizável para um cliente específico não está imediatamente pronta.

As aprovações locais e restrições de construção também devem fazer parte da diligência do comprador. As páginas públicas da Cloud9 identificam a localização do Dinamo Stadium/Tsereteli Avenue e descrevem o data center como construído e gerenciado pela Cloud9, mas não revelam licenças de expansão, compromissos de atualização de serviços públicos, fases de construção ou restrições do proprietário e do local do estádio. Essa ausência não é evidência de um problema.

É evidência de que um cliente não deve tratar a capacidade futura de rack ou gaiola como um ativo finalizado até que a Cloud9 confirme a rota de entrega, a rota de energia, a rota de refrigeração e a rota de conexão cruzada por escrito.

A mesma precaução se aplica à declaração de instalação em 24 horas para alguns serviços de colocation e à declaração de configuração em 24 a 48 horas para servidores dedicados. Esses prazos são úteis para pedidos padrão. Não devem ser reutilizados para um rack completo, uma gaiola, uma construção de operadora, uma implantação de alta densidade ou uma migração de recuperação, a menos que a Cloud9 diga que a configuração exata está disponível.

O caminho de falha neste artigo inclui atraso na construção porque uma promessa de expansão muitas vezes falha silenciosamente: o cliente assina antes que o disjuntor, rack, caminho de cabeamento, estoque de servidor ou rota de operadora estejam realmente prontos.

Portanto, o comprador deve solicitar uma declaração de prontidão, não apenas um orçamento. Quais gabinetes estão ativos agora? Quais alimentações elétricas já estão comissionadas? Quais operadoras já estão presentes no meet-me solicitado? Quais rotas requerem novo trabalho? Quais servidores estão em estoque? Quais peças são mantidas localmente? Quais atualizações precisam de aprovação de serviços públicos, instalações ou fornecedores? Essas perguntas transformam uma alegação ampla de data center em um compromisso de entrega.

Quem é afetado quando a âncora de Tbilisi falha

A base de clientes visível não está completamente divulgada, mas apágina sobreda Cloud9 anuncia mais de 1.200 clientes ativos, mais de 3.500 serviços ativos, mais de 5.000 domínios registrados e 99,9 por cento de tempo de atividade do sistema. Esses números são publicados pela operadora e devem ser tratados como números de marketing, a menos que estejam documentados contratualmente, mas mostram o tipo de dependência em jogo. Isso não é meramente um ASN vazio sem promessa de cliente anexada. É um negócio de hospedagem e data center que se apresenta como um provedor de infraestrutura local.

Se a instalação de Tbilisi falhar, diferentes clientes falham de maneira diferente. Clientes de colocation podem perder energia, refrigeração, acesso de gerenciamento ou capacidade de link upstream enquanto ainda são proprietários do equipamento. Clientes de VPS podem perder servidores virtuais, painéis de controle, backups ou atualizações de DNS. Clientes de servidor dedicado podem esperar reparo ou substituição de hardware. Clientes de domínio e hospedagem podem experimentar interrupções de e-mail, site e conta.

Clientes que usam a Cloud9 para migração ou suporte gerenciado podem precisar de ação da equipe ao mesmo tempo que todos os outros pedem ajuda.

A localidade tem dois lados. Uma operadora georgiana com suporte local pode ser valiosa por idioma, jurisdição, pagamento, acesso e serviço doméstico de baixa latência. Também pode criar concentração se muitas pequenas empresas, desenvolvedores e organizações georgianas dependem de um único edifício em Tbilisi e do desk de suporte de um único provedor. O impacto de uma interrupção não é medido apenas pela contagem total de prefixos ou pela parcela de tráfego global. É medido pelos clientes que não têm um segundo site, um segundo provedor ou uma rota de exportação testada.

A evidência de rota sugere que a Cloud9 tem uma rede real além de um pequeno stub. A contagem atual de prefixos, vizinhos e suporte IPv6 da AS57814 são significativos. O registro de instalação do PeeringDB para Cloud9 Dinamo Arena adiciona uma camada de interconexão física. A filiação ao IXP.ge adiciona relevância de exchange local. Mas o registro público não mostra resultados de failover de clientes. Não mostra quantos clientes executam serviços de site único, quantos usam backups fora da instalação, quantos têm serviço de operadora dupla, ou quantos conhecem a diferença entre as alocações de largura de banda local e global.

Essa incerteza é precisamente por que o título do artigo atribuído importa. A capacidade comercializada do data center tem que sobreviver às restrições de energia e operadora, não apenas descrevê-las. A história pública da Cloud9 é suficientemente crível para merecer escrutínio e suficientemente específica para tornar o escrutínio justo. A prova faltante não é identidade. É sobrevivência comprovada.

O que elevaria o grau de evidência

A Cloud9 poderia aumentar a confiança sem expor detalhes sensíveis da instalação. Uma página de rede pública poderia estabelecer o papel atual de AS203301, o papel ativo de AS57814, o conjunto principal de AS, opções BGP de clientes, política de segurança de rota e prática de autorização de rota. Uma página de instalação poderia preservar a segurança enquanto fornece intervalos para a contagem de gabinetes ativos, densidade de rack disponível, densidades de energia suportadas, tempo de funcionamento do gerador, redundância UPS, redundância de refrigeração e padrões de aviso de manutenção.

Uma página de status poderia separar os serviços de instalação, rede, hospedagem, DNS, portal e e-mail.

Para colocation empresarial, a evidência mais valiosa seria específica do cliente. Os compradores devem solicitar um resumo recente de teste de carga do gerador, evidência de manutenção de UPS, design de redundância de refrigeração, objetivos de resposta de mãos remotas, amostras de comunicação de incidentes, evidência de failover de rota, opções de diversidade de conexão cruzada, localização de backups, evidência de tempo de restauração e uma declaração clara de quais serviços são de site único. Se a resposta varia por produto, deve variar por escrito.

Um servidor torre, um servidor 1U de alimentação dupla, um rack completo e um VDS gerenciado não compartilham o mesmo perfil de risco.

A evidência atual suporta um grau Médio. AS203301 sozinho não está ativo e deve ser rebaixado. A operação mais ampla da Cloud9 é visível através de páginas oficiais de instalações, termos legais, roteamento de AS57814, entradas de instalação e exchange do PeeringDB, filiação ao IXP.ge e verificações de origem de rota válidas em prefixos ativos.

As lacunas restantes são aquelas que geralmente importam durante uma interrupção: independência real da rota de energia, resistência do gerador, failover de refrigeração, diversidade física de operadoras, impacto de manutenção, hardware de reposição, restauração de backups e teste de migração de clientes.

A conclusão prática é direta. Um comprador não deve rejeitar a Cloud9 apenas porque AS203301 está inativo. Não deve comprar capacidade crítica apenas porque o site diz data center neutro em relação a operadoras. O movimento correto é tratar a Cloud9 como uma operadora real de data center e hospedagem georgiana cuja evidência ativa se concentra em AS57814 e na instalação de Tbilisi, depois exigir prova de que o serviço adquirido continua funcionando quando uma alimentação, uma rota de refrigeração, uma rota de operadora, um host de servidor ou um canal de suporte falha.