Rackspace IT Hosting AS IT Hosting Provider Hong Kong Vende uma Capacidade Hospedada que Ainda Depende de Racks, Trânsito e Janelas de Reparo

Resumo

• Rackspace IT Hosting AS IT Hosting Provider Hong Kong corresponde ao AS45187 nos registros públicos da APNIC e do RIPEstat. O registro RDAP da APNIC nomeia a Rackspace.com Hong Kong Limited como a organização detentora, e o RIPEstat rotula o detentor como "RACKSPACE-AP - Rackspace IT Hosting AS IT Hosting Provider Hong Kong".
• A superfície de roteamento é materialmente visível. O snapshot do status de roteamento do RIPEstat para o AS45187 mostrou 13 prefixos IPv4, 2 prefixos IPv6, 66.816 endereços IPv4, visibilidade total no RIS observada para ambas as famílias de endereços e 23 vizinhos observados. A visualização de prefixos anunciados listou prefixos ativos incluindo 119.9.64.0/19, 119.9.96.0/19, 120.136.32.0/20, 180.150.128.0/19, 202.168.208.0/21, 203.60.0.0/17, 2401:1800::/32 e 2407:fa00::/32.
• O PeeringDB adiciona contexto de site e interconexão, em vez de uma garantia de capacidade. Ele lista "Rackspace Hong Kong" para o AS45187, uma política aberta, contagens de prefixos indicativas de 100 IPv4 e 10 IPv6, duas entradas de troca de 10G na Equinix Hong Kong e HKIX, e uma entrada de instalação no MEGA-i em Hong Kong.
• As páginas HKG1 e HKG5 da Rackspace tornam a dependência física visível. O HKG1 é descrito em Tsuen Wan com módulos UPS, alimentação dupla de 11 kV e componentes de rede redundantes; o HKG5 é descrito em Tseung Kwan O com 917 m² de espaço de data center dedicado, uma potência elétrica total de 13,5 MW, capacidade de UPS de 7,2 MW, sete operadoras de fibra, 10 Gbit/s por operadora, otimização de rotas BGP multipath e uma separação declarada onde os clientes mantêm o controle administrativo dos servidores alugados enquanto a Rackspace controla o hardware de rede.
• O nível de evidência é Alto para identidade de rede pública e evidência operacional em Hong Kong, mas não é um cheque em branco para todas as cargas de trabalho hospedadas. Os clientes ainda precisam de evidências específicas do serviço em relação a posicionamento, redundância, tempos de restauração, escalonamento de tickets, exclusões de manutenção, acesso a peças sobressalentes, status RPKI, limites contratuais e caminhos de saída.

A pergunta útil não é mais se a Rackspace existe em Hong Kong

Alguns perfis de infraestrutura começam com um nome fino e um ASN fraco. Não é o caso aqui. O registro público em torno da Rackspace IT Hosting AS IT Hosting Provider Hong Kong é espesso o suficiente para mudar a investigação da existência para a dependência. Oregistro RDAP do sistema autônomoda APNIC identifica o AS45187 como RACKSPACE-AP, com país HK e a Rackspace.com Hong Kong Limited como organização detentora. Avisão geral de ASdo RIPEstat usa o rótulo de detentor "Rackspace IT Hosting AS IT Hosting Provider Hong Kong" e marca o ASN como anunciado. Esse emparelhamento é mais forte do que uma entrada de diretório de hospedagem raspada ou uma página corporativa desatualizada.

A evidência de roteamento também é atual o suficiente para importar. Ostatus de roteamentodo RIPEstat para o AS45187 mostrou visibilidade IPv4 e IPv6 em todos os pares RIS observados no momento do snapshot, 13 prefixos IPv4, 2 prefixos IPv6 e 23 vizinhos observados. Oconjunto de dados de prefixos anunciadoslistou 15 linhas de prefixos atuais. Isso inclui dois grandes agregados IPv6, 2401:1800::/32 e 2407:fa00::/32, e rotas IPv4 como 119.9.64.0/19, 119.9.96.0/19, 120.136.32.0/20, 122.200.132.0/22, 180.150.128.0/19, 202.168.208.0/21 e 203.60.0.0/17. Isso não é uma rede de vaidade de prefixo único.

Os documentos de instalações públicas da Rackspace tornam o assunto ainda menos abstrato. Apágina do data center HKG1da Rackspace coloca uma instalação em Hong Kong em Tsuen Wan e descreve energia, resfriamento, segurança, conectividade e garantias. Suapágina do HKG5coloca outra instalação em Tseung Kwan O e vai além, listando 917 m² de espaço de data center dedicado, uma potência elétrica total de 13,5 MW, capacidade de UPS de 7,2 MW, sete operadoras de fibra para o local e otimização de rotas BGP multipath. A questão da existência está, portanto, suficientemente resolvida para o trabalho de aquisição. A questão em aberto é se o serviço hospedado de um determinado cliente tem a mesma resiliência que a pegada publicada sugere.

Essa distinção é importante porque "Rackspace" é uma grande marca, "Hong Kong" é um rótulo de mercado, o AS45187 é uma fronteira de rede e a carga de trabalho do cliente é uma implantação específica do contrato. Um comprador pode ver os recursos de números públicos e as reivindicações da Rackspace sobre suas instalações, mas não pode inferir qual sala, qual rack, qual operadora, qual VLAN, qual sistema de backup, qual equipe de suporte ou qual cronograma de manutenção se aplica ao seu próprio ambiente. Uma página de instalação bem fundamentada deve tornar o escrutínio mais rigoroso, não menos.

O AS45187 é uma borda operacional real, mas o registro não mostra todos os serviços

Os registros da APNIC e do RIPEstat mostram uma identidade consistente. O registro RDAP fornece uma data de registro de dezembro de 2014 e uma data de última alteração de julho de 2020. Avisualização derivada do whoisdo RIPEstat registra o aut-num como 45187, o as-name como RACKSPACE-AP, a descrição como Rackspace IT Hosting AS IT Hosting Provider Hong Kong e o país como HK. Também mostra linhas históricas de política de importação e exportação nomeando AS3491, AS1239 e AS2914, bem como contatos de mantenedor de roteamento da Rackspace. Esses detalhes são úteis porque vinculam o recurso de número à entidade Rackspace de Hong Kong e a um registro de administração de roteamento de longa data.

Isso não é suficiente para definir o produto. O AS45187 pode transportar nuvem pública, hospedagem gerenciada, servidor dedicado, colocation, armazenamento, monitoramento, plano de controle, suporte ou funções de backbone de maneiras diferentes. Alguns sistemas de clientes podem ser endereçados diretamente do AS45187. Outros podem usar endereços atribuídos pelo provedor, interconexões privadas, endereços de provedor de nuvem ou rotas híbridas que não aparecem como origens visíveis ao cliente. O registro pode dizer ao comprador onde procurar.

Ele não pode dizer qual produto exato usa a borda de roteamento, qual entidade legal assina o contrato ou qual provedor é responsável por um incidente.

As evidências do detentor da APNIC devem, portanto, ser lidas como um ponto de partida para o mapa de responsabilidades. Se for dito a um cliente que uma carga de trabalho de Hong Kong é entregue a partir da infraestrutura da Rackspace, o AS45187 fornece ao cliente uma fronteira de rede concreta sobre a qual fazer perguntas. Quais prefixos estão envolvidos? Quais são voltados para o cliente, apenas para gerenciamento, apenas para backup ou legados? Quais políticas de roteamento estão ativas e quais são históricas? Quais prefixos têm uma autorização de origem de rota e quais permanecem desconhecidos para os validadores RPKI?

Essas não são perguntas acadêmicas. Elas determinam se um vazamento de rota, uma alteração de filtro, um evento de mitigação de DDoS ou uma interrupção upstream pode afetar o serviço.

A primeira ressalva diz respeito ao RPKI. A verificação de validação usada para este artigo no 119.9.64.0/19 por meio doendpoint de validação RPKIdo RIPEstat retornou um status desconhecido em vez de válido. O mesmo status apareceu para o conjunto de prefixos verificado a partir da lista de prefixos anunciados. Desconhecido não é o mesmo que inválido e não significa que a rede está falhando. Significa que a autorização de origem de rota deve ser uma pergunta ativa de aquisição, porque as redes que aplicam a validação de origem de rota tratam rotas válidas, inválidas e desconhecidas de maneira diferente. Para um cliente que depende de uma borda estável em Hong Kong, "desconhecido" deve levar a uma discussão sobre ROAs, filtros de rota, procedimentos de contato e propriedade do controle de mudanças.

Rackspace publica dois tipos diferentes de evidências de instalações em Hong Kong

As páginas de instalações de Hong Kong da Rackspace são excepcionalmente concretas em comparação com muitos perfis de hospedagem regionais. O HKG1, descrito napágina de data centers da Rackspace Technology: Hong Kong (HKG1), está localizado em Tsuen Wan. A página afirma que as instalações de Hong Kong são equipadas com profissionais de engenharia de sistemas que gerenciam e mantêm os sistemas 24/7/365. As alegações físicas listadas para o HKG1 incluem módulos UPS de 400 KVA em configuração N+1, 30 minutos de autonomia de bateria, duas alimentações de 11 kV de subestações HKE separadas, risers de energia duplos, vários geradores e uma instalação neutra em relação à operadora, alimentada por duas conexões de telecomunicações.

O HKG5, descrito napágina de data centers da Rackspace Technology: Hong Kong (HKG5), está localizado em Tseung Kwan O e expõe um conjunto diferente de especificidades. Ele lista 917 m² de espaço de data center dedicado, uma potência elétrica total de 13,5 MW, capacidade de UPS de 7,2 MW, geradores a diesel com capacidade de 2,25 MW cada, tanques de combustível de 12.000 litros, mais de 1 MW de capacidade de resfriamento, sete operadoras fornecendo conectividade de fibra para o local, 10 Gigabit Ethernet por operadora, roteadores Cisco e Arista redundantes e otimização de rotas BGP multipath. Também afirma que os clientes mantêm o controle administrativo dos servidores alugados enquanto a Rackspace mantém o controle do hardware de rede.

Essas alegações têm significado operacional. Elas dizem que a Rackspace não está simplesmente revendendo uma região de nuvem anônima sob um rótulo de Hong Kong. Elas indicam uma instalação física, um design de rede, equipe de suporte e limites de controle. Mas elas ainda precisam ser convertidas em evidências específicas do serviço. "O HKG5 tem sete operadoras" não prova por si só que cada serviço do cliente tem sete caminhos ativos, prontos para o padrão, pagos e provisionados. "Otimização de rotas BGP multipath" não prova diversidade de rota até a aplicação, a camada de armazenamento ou o console de gerenciamento do cliente.

"Os clientes mantêm o controle administrativo" não prova que um cliente pode recuperar o serviço se o hardware de rede, o portal, a fila de suporte ou o status de faturamento bloquear o acesso.

As páginas de instalações são mais fortes onde mencionam insumos físicos. Alimentação de energia, capacidade de UPS, combustível do gerador, contagens de operadoras e famílias de roteadores são coisas reais que um comprador pode pedir para ver em um projeto de serviço. As páginas são mais fracas onde são necessariamente genéricas. Elas não publicam atribuições de rack, posicionamento do cliente, patch panels, mapas de VLAN privados, topologia de armazenamento, geografia de backup, caixas de peças sobressalentes ou a profundidade da fila de técnicos que seria chamada durante um incidente.

A tarefa de aquisição é preencher essa lacuna sem fingir que a página pública de instalações já o fez.

PeeringDB confirma sinais de interconexão, não posicionamento do cliente

OAPI de rede do PeeringDB para o ASN 45187lista uma entidade de rede chamada Rackspace Hong Kong. Os campos mostram uma política aberta geral, um conjunto AS-IRR de AS-RACKSPACE, contagens de prefixos indicativas de 100 IPv4 e 10 IPv6, suporte IPv6, uma contagem IX de 2 e uma contagem de instalações de 1. O PeeringDB é um diretório voluntário, portanto, nenhum desses campos é uma certificação. No entanto, a entrada é valiosa porque vincula o AS45187 a uma postura de interconexão que pode ser comparada com os coletores de rotas e declarações de instalações da Rackspace.

Osregistros netixlan do PeeringDBlistam duas entradas operacionais de troca: Equinix Hong Kong e HKIX: HKIX Peering LAN. Ambos mostram uma velocidade de 10.000 Mbit/s. A linha da Equinix Hong Kong lista o endereço IPv4 36.255.56.87 e o endereço IPv6 2001:de8:7::4:5187:2. A linha HKIX lista o endereço IPv4 123.255.90.101 e o endereço IPv6 2001:7fa:0:1::ca28:a065. Oregistro netfac do PeeringDBlista MEGA-i (iAdvantage Hong Kong) em Hong Kong como uma entrada de instalação para a entidade de rede.

Essas linhas criam uma tensão útil com as páginas HKG1 e HKG5 da Rackspace. A Rackspace publica páginas de instalações para Tsuen Wan e Tseung Kwan O, enquanto o PeeringDB expõe uma entrada de instalação de rede no MEGA-i e conexões de troca na Equinix Hong Kong e HKIX. Não há contradição, a menos que alguém tente fazer um único registro dizer mais do que pode. O PeeringDB pode descrever uma presença de interconexão em vez do posicionamento de computação do cliente. As páginas de data center da Rackspace podem descrever instalações de hospedagem em vez de todos os locais de troca ou interconexão.

Um cliente precisa do mapa que conecta essas camadas: onde o servidor fica, onde o roteador de borda fica, onde o peering de troca ocorre, onde o trânsito entra e onde o cliente tem direitos contratuais.

A lição operacional imediata é que a contagem de instalações não é o mesmo que redundância. Uma linha de instalação do PeeringDB pode coexistir com vários sites operados ou comercializados pela Rackspace. Duas portas de troca podem melhorar a acessibilidade a redes selecionadas sem provar diversidade total de trânsito. Uma porta de troca de 10G pode ser útil para peering, mas o caminho sobrevivente do cliente durante uma interrupção pode depender de trânsito pago, interconexão privada, DNS, filtragem de segurança, balanceadores de carga, replicação de armazenamento e acesso ao suporte.

O registro público de interconexão dá ao comprador nomes e endereços para testar, não um resultado de failover de ponta a ponta.

A superfície de roteamento é ampla, mas a diversidade ainda precisa ser provada duas vezes

O AS45187 tem um conjunto de vizinhos visível. Oendpoint de vizinhos ASNdo RIPEstat retornou 23 vizinhos observados. A lista incluía grandes redes globais como AS174, AS3257, AS3300, AS3491, AS4637, AS6453, AS6939 e AS7473 no lado esquerdo, uma linha direita para AS58982 e várias linhas incertas. O BGP público não pode dizer se cada adjacência é um upstream pago, um peer, um cliente, um relacionamento de roteador de troca, um artefato temporário de vazamento de rota ou um artefato de classificação do lado do coletor. Ele só pode nos dizer que a borda de roteamento não é invisível.

As linhas de política whois históricas da APNIC adicionam outra camada. Elas listam importações de AS3491, AS1239 e AS2914 e exportações para esses ASes. Esta é uma peça histórica útil de evidência de administração de roteamento, mas não descreve automaticamente a engenharia de tráfego atual. A lista de vizinhos atual do RIPEstat inclui indiretamente alguns desses nomes e mostra outros também. Um comprador deve perguntar à Rackspace sobre o design atual de trânsito e peering, em vez de confiar no texto estático da política whois.

A diversidade deve ser provada duas vezes: uma vez no roteamento e uma vez nas operações físicas. Uma rede pode ter muitos vizinhos BGP nos dados públicos enquanto vários caminhos compartilham o mesmo prédio, a mesma sala de meet-me, o mesmo domínio de energia, o mesmo conduíte de fibra, o mesmo par de roteadores ou a mesma fila de suporte. Por outro lado, um serviço pode ter uma forte resiliência privada ou do lado do provedor que é pouco visível no BGP público. O objetivo não é punir a Rackspace por ocultar detalhes operacionais; é evitar confundir um gráfico AS público com um design testado de recuperação do cliente.

As melhores perguntas são específicas da camada. Quais prefixos AS45187 são originados de quais roteadores de borda em Hong Kong? Quais upstreams transportam rotas padrão para o serviço durante a operação normal? Quais sessões de troca são peering sem custo versus acessibilidade crítica? Quais caminhos são diversos no nível de entrada de fibra e edifício? Quanto tráfego o caminho restante pode transportar no pico após a remoção de uma operadora, troca, roteador ou domínio de instalação? O BGP público pode sugerir onde fazer perguntas. Ele não pode responder a tudo isso sozinho.

Rackspace vende abstração, mas a economia de Hong Kong permanece física

Apágina de hospedagem gerenciadada Rackspace apresenta o produto em linguagem empresarial familiar: hospedagem dedicada gerenciada, infraestrutura dedicada de locatário único, bare metal, bancos de dados, rede, armazenamento, backup gerenciado, recuperação de desastres, RackConnect e nuvem privada. A promessa comercial é que a Rackspace converterá a complexidade física em um serviço. Os clientes compram desempenho, suporte e controle sem possuir cada roteador, alimentação de energia, compartimento de armazenamento, interconexão e processo de manutenção.

Essa troca tem valor real, mas não apaga a economia subjacente. Oguia do cliente de colocation da Rackspacedescreve o faturamento alocado em quilowatts para energia crítica redundante reservada, com cobranças recorrentes mensais separadas para interconexões e largura de banda combinada quando adquirida. Ele também se refere a taxas únicas de configuração, circuitos de energia, gaiolas privadas, PDUs no rack e interconexões. Este é o vocabulário da capacidade física. A conta da nuvem ainda depende de alocação de energia, espaço em rack, óptica, mãos remotas, compromissos de largura de banda e mão de obra.

As páginas de Hong Kong tornam isso visível. A alegação de 13,5 MW de potência elétrica do HKG5, seus 7,2 MW de capacidade de UPS e suas sete operadoras de fibra não são decoração de marketing. São insumos de capacidade que podem restringir ou proteger um cliente. Se a densidade do rack aumentar, se um cliente precisar de mais interconexões, se um roteador sobressalente não estiver disponível, se um caminho de operadora estiver congestionado ou se uma janela de manutenção exigir trabalho serializado, o cliente sente o estado físico por meio de latência, atraso no ticket, limites de migração ou créditos pós-interrupção.

A capacidade hospedada é comprada como um serviço, mas falha como uma cadeia de etapas físicas e administrativas.

É por isso que é preciso separar a capacidade "instalada" da capacidade "utilizável". Capacidade instalada é o que a pegada publicada parece incluir: instalações, geradores, sistemas UPS, conexões de operadora, roteadores, prefixos e equipe de suporte. Capacidade utilizável é o que resta para um cliente após contabilizar reservas normais, sobrecarga, manutenção, roteamento específico do cliente e domínios de proteção. A capacidade recuperável é ainda mais restrita: a parte que pode ser restaurada dentro do prazo exigido pelo cliente após uma falha de componente. As páginas públicas são boas para a capacidade instalada.

A garantia do cliente deve provar a capacidade utilizável e recuperável.

O controle é dividido por design

A linha mais importante no HKG5 pode não ser a sobre megawatts ou contagens de operadoras. A página afirma que os clientes mantêm o controle administrativo dos servidores alugados enquanto a Rackspace mantém o controle do hardware de rede. Essa separação é exatamente o que um cliente de hospedagem gerenciada deseja durante a operação normal: o cliente pode gerenciar sua carga de trabalho, enquanto o provedor protege a camada de rede compartilhada. Durante uma falha, a mesma separação se torna uma fronteira que deve ser ensaiada.

Se um servidor alugado estiver saudável, mas inacessível, os direitos administrativos do cliente podem não ser suficientes. Se um cliente pode acessar um servidor via VPN, mas não pode acessar o serviço público, a fronteira da rede é importante. Se um cliente precisa de uma alteração de rota, uma regra de firewall, um ticket de interconexão ou uma substituição de hardware, a autoridade e a fila da Rackspace se tornam o fator limitante. Se o cliente tem um backup, mas não pode mover dados suficientes pelo caminho disponível, o controle no nível do servidor é uma evidência pública limitada.

A responsabilidade compartilhada não é um slogan aqui; é a arquitetura operacional.

O guia de colocation da Rackspace reforça a mesma fronteira. Ele descreve gerentes de implementação, treinamento no portal do cliente, solicitações de mãos remotas, criação automática de tickets, monitores de alerta e um runbook. Ele afirma que os clientes podem interagir criando tickets através do portal do cliente da Rackspace e podem ligar para a equipe de suporte 24/7/365. Ele também lista tarefas de mãos remotas, como ciclo de energia do dispositivo, verificação visual, teste de cabos, substituição de hardware fornecido pelo cliente, montagem e desmontagem em rack, cabeamento de rede no rack e destruição de disco rígido.

Essas são as ações concretas que transformam a detecção de falhas em reparo.

Para um comprador, a pergunta de controle é simples: o que podemos fazer sem a Rackspace, o que a Rackspace pode fazer sem nós e o que exige que ambas as partes ajam na ordem certa? Essa pergunta deve ser respondida antes da produção. Deve ser escrita em etapas operacionais, não apenas em linguagem contratual. Quais usuários do portal têm autoridade? Qual número de telefone funciona se o portal estiver indisponível? Quais alterações de rota exigem um ticket? Quais ações de hardware estão incluídas? Quais tarefas são cobradas em incrementos de 15 minutos?

Quais tarefas dependem de peças fornecidas pelo cliente em vez de peças fornecidas pela Rackspace?

Janelas de reparo são uma característica do produto, não uma nota de rodapé

As páginas de data center da Rackspace publicam fortes garantias, mas os detalhes importam. Tanto o HKG1 quanto o HKG5 incluem linguagem de garantia para rede, infraestrutura e substituição de hardware. As seções de rede e infraestrutura falam em termos de disponibilidade e créditos, enquanto a garantia de substituição de hardware afirma que a substituição ou reparo de hardware ou componentes fornecidos pela Rackspace começará dentro de uma hora após a identificação do problema, com créditos se não o fizer. A palavra "começar" é importante. Não é o mesmo que "concluir" e não descreve todos os componentes fornecidos pelo cliente.

A tabela de mãos remotas no guia de colocation é mais granular operacionalmente. Ela mostra que o HKG1 tem um SLA de resposta de 1 hora e um SLA de execução de 24 horas para mãos remotas. O mesmo guia fornece tempos estimados para tarefas comuns, como 30 minutos para ciclar a energia de um roteador, servidor ou switch, 60 minutos por três cabos para teste de suporte de cabeamento e 60 minutos para substituir um dispositivo fornecido pelo cliente que não é hot-swappable. Ele lista uma taxa de mão remota de US$ 46,25 por incremento de 15 minutos, mais a lista de materiais. Esses não são detalhes triviais.

Eles mostram onde o relógio de reparo pode mudar de uma métrica de tempo de atividade abstrata para mão de obra humana paga.

Portanto, um cliente deve separar três relógios. O tempo de detecção é o tempo que o monitoramento leva para perceber e classificar uma falha. O tempo de resposta é o tempo que a Rackspace ou o cliente leva para aceitar a propriedade e iniciar a ação. O tempo de execução é o tempo que o reparo realmente leva, incluindo peças, acesso, cabeamento, reinicialização, alteração de rota, reconstrução de armazenamento e verificação. Os créditos pós-interrupção são comercialmente importantes, mas não restauram a carga de trabalho. O escrutínio de resiliência deve se concentrar na restauração medida, não apenas nos créditos de serviço.

A mesma lógica se aplica à manutenção. A linguagem de garantia da Rackspace exclui manutenção planejada ou de emergência. Essa exclusão é normal, mas é importante em uma revisão de capacidade hospedada. Se um caminho ou local estiver indisponível para manutenção, a verdadeira resiliência do cliente é a capacidade restante no caminho não sujeito à manutenção. Se um cliente precisa de uma alteração durante um congelamento de manutenção do provedor, as regras de escalonamento são importantes. Se um evento de manutenção de emergência tocar um componente de rede compartilhado, os direitos administrativos do cliente podem não ajudar.

As janelas de reparo e manutenção fazem parte do produto, não papelada acessória.

A segurança da origem da rota é o ponto fraco em uma pegada pública forte

A degradação mais óbvia na evidência de rede é o status RPKI. O RIPEstat relatou a superfície de roteamento claramente, e o PeeringDB deu detalhes de interconexão, mas as verificações de validação RPKI em relação à lista de prefixos atual retornaram um status desconhecido em vez de válido na amostragem usada aqui. O status desconhecido pode existir por muitas razões, incluindo a ausência de ROAs, cobertura do validador, tempo ou escolhas de gerenciamento de recursos. Isso não significa que o AS45187 está sequestrando rotas. Significa que a camada de autorização de origem não é tão forte publicamente quanto a camada de visibilidade BGP.

Para um cliente hospedado, isso é importante porque a validação de origem não é mais exótica. A RFC 6811 descreve a validação de origem de rota como uma forma de usar a Infraestrutura de Chave Pública de Recursos para determinar se um AS está autorizado a originar um prefixo. O próprio material RPKI da APNIC explica o controle de certificação de recursos em termos operacionais. Um cliente que depende de acessibilidade pública deve se preocupar se os prefixos de produção do seu provedor são válidos, desconhecidos ou inválidos, e se os próprios prefixos roteados do cliente têm ROAs corretos antes da migração.

A pergunta prática não é "A Rackspace conhece BGP?" O conjunto de vizinhos público e as alegações de instalações sugerem operações de roteamento maduras. A pergunta mais restrita é: para os prefixos exatos que transportam o serviço do cliente, as autorizações de origem de rota são publicadas e testadas com os principais validadores? Se o cliente traz seu próprio espaço de endereço, quem cria e mantém os ROAs? Se a Rackspace atribui o espaço de endereço, a Rackspace pode mostrar o status e o processo de controle de mudanças? Se um prefixo precisar ser movido durante um incidente, o que acontece com o estado do ROA e o filtro?

Esta é uma das poucas verificações públicas em que a resposta pode ser melhorada sem revelar detalhes privados da instalação. Um ROA válido não prova a resiliência do cliente, mas remove um modo de falha evitável. Uma rota desconhecida ainda pode funcionar na maioria das redes; ela simplesmente dá ao comprador menos garantia no nível de validação de origem. Em um arquivo forte da Rackspace Hong Kong, este é exatamente o tipo de pergunta específica e corrigível que não deve ser perdida sob o peso de uma grande marca.

A localidade dos dados não é definida pelas letras HK

A região de alocação é HK, a APNIC lista o AS45187 com país HK, a Rackspace publica instalações em Hong Kong e o registro do PeeringDB descreve uma interconexão em Hong Kong. Esses são bons sinais de localidade. Eles ainda não provam onde os dados, backups, logs, registros de suporte, sistema de identidade, snapshots ou cópias de recuperação de um cliente estão localizados. Em contratos de nuvem e hospedagem gerenciada, a localidade é uma matriz de posicionamento, não um código de país.

O regulador de privacidade de Hong Kong ressalta esse ponto em sua orientação pública. OGuia sobre Computação em Nuvemdo PCPD, de janeiro de 2025, diz aos usuários de dados para considerar a localização do armazenamento de dados, medidas de segurança no equipamento, a integridade e competência das pessoas que têm acesso, transmissão segura, contratos com subcontratados, controles de retenção e as implicações de transferências transfronteiriças. Umanota de caso do PCPD sobre sistemas em nuvem fora de Hong Kongafirma que a Portaria não proíbe o armazenamento de dados pessoais em um sistema de nuvem fora de Hong Kong, mas que os usuários de dados ainda devem cumprir a PDPO e os princípios de proteção de dados. Ascláusulas contratuais modelo recomendadaspelo PCPD fornecem uma estrutura contratual para transferências transfronteiriças.

Para clientes da Rackspace Hong Kong, a consequência é prática. O cliente deve perguntar onde os dados primários são armazenados, onde os snapshots são armazenados, onde os backups são armazenados, onde os logs de gerenciamento são armazenados, quais equipes de suporte podem acessar o ambiente, quais subcontratados ou nuvens parceiras estão envolvidos e se uma ação de suporte normal transfere dados pessoais para fora de Hong Kong. Uma borda de roteamento em Hong Kong pode coexistir com ferramentas de suporte não localizadas em Hong Kong, sistemas de identidade globais, cópias de backup offshore ou interconexões multinuvem.

Nada disso é necessariamente impróprio. Simplesmente precisa ser divulgado e testado em relação às próprias obrigações regulatórias do cliente.

A localidade também interage com a recuperação. Um backup fora de Hong Kong pode melhorar a resiliência, mas alterar a análise de transferência. Um backup apenas local pode satisfazer uma preferência de residência, mas falhar se a instalação local sofrer um evento regional. Um design multissite dentro de Hong Kong pode ser melhor para latência e jurisdição, mas mais caro e ainda dependente de provedores comuns. O comprador precisa do design, não do slogan.

Evidência de saída faz parte da resiliência

Um serviço hospedado não é totalmente resiliente até que o cliente possa deixá-lo sob pressão. A documentação da Rackspace contém sinais úteis de que alguns serviços expõem caminhos de exportação e migração. O manual do Rackspace Cloud sobre OpenStack Flex aponta para funções para criar máquinas virtuais, armazenamento em bloco, armazenamento de objetos, exportação de imagens, importação de imagens e agendamento de migração. Oguia de exportação de imagensdescreve a exportação de snapshots de instância de um projeto OpenStack Flex. Oguia da API de Armazenamento de Objetosexplica que o acesso requer credenciais do Rackspace Cloud, detalhes do projeto e chamadas de API.

Esses documentos não provam que todo cliente de hospedagem gerenciada em Hong Kong pode realizar uma saída de emergência completa. Eles provam que a saída deve ser discutida no nível do artefato. O cliente pode exportar imagens de VM? Ele pode exportar volumes de bloco? Os backups são portáteis? As configurações de rede, regras de firewall, configurações de balanceador de carga, zonas DNS, certificados, logs e histórico de monitoramento são exportáveis? A exportação funciona se o portal do cliente estiver degradado? Requer um engajamento de suporte pago? Pode ser testada sem acionar uma mudança de produção?

A camada física reaparece durante a saída. Grandes exportações consomem largura de banda e tempo. O faturamento de interconexão, os limites de trânsito, as taxas de leitura de armazenamento, as credenciais de armazenamento de objetos e os tickets de suporte fazem parte do caminho de migração. Um cliente que nunca mediu uma exportação completa pode descobrir durante um incidente que "podemos mover" na verdade significa "podemos iniciar uma longa transferência depois que o provedor aprovar a solicitação". O planejamento de saída não é hostilidade em relação à Rackspace. É o fim honesto de uma revisão de dependência.

A infraestrutura publicada da Rackspace é forte o suficiente para que muitos clientes escolham racionalmente não gerenciar uma infraestrutura equivalente por conta própria. Esse é o ponto econômico da hospedagem gerenciada. O perigo não está em usar um provedor; está em usar um sem preservar as evidências necessárias para mover, restaurar ou verificar independentemente o serviço quando algo der errado.

O empacotamento corporativo ajuda, mas a evidência local ainda vence

O arquivo corporativo mais amplo da Rackspace Technology ajuda a explicar por que este perfil de Hong Kong não deve ser tratado como um pequeno hoster regional. A Rackspace Technology, Inc. aparece em arquivamentos da SEC como uma empresa listada na Nasdaq sob o símbolo RXT, e seuarquivamento 10-K de 2025fornece aos investidores o contexto mais amplo de negócios e riscos em torno de suas operações de nuvem, hospedagem e serviços. Apágina global de data centersda Rackspace apresenta uma pegada de data center em vários mercados e afirma que suas instalações usam redundância nos domínios de segurança, energia, resfriamento e rede. Esses fatos reduzem a incerteza de identidade e tornam as páginas de instalações de Hong Kong mais credíveis do que uma página de destino isolada seria.

Eles não removem a necessidade de evidência local. Uma empresa global ainda pode ter uma restrição de instalação local, uma dependência de fornecedor regional, um caminho de depreciação específico do produto, um nível de suporte específico do cliente ou um design de nuvem privada que difere da página pública de instalações. O 10-K também é escrito para investidores, não para um cliente de Hong Kong tentando aprender qual rack, qual rota, qual sistema de backup e qual engenheiro decidirá uma interrupção de sábado.

A divulgação de empresa pública pode descrever riscos de negócios, segmentos de receita, dívida, concorrência e suposições operacionais. Ela não pode certificar o caminho de recuperação de uma carga de trabalho específica no AS45187.

Este empacotamento corporativo muda o método de garantia. Com um provedor pequeno e desconhecido, a primeira tarefa pode ser provar que a empresa e a rede existem. Com a Rackspace Hong Kong, a primeira tarefa é alinhar várias camadas públicas que são reais: a identidade AS45187 da APNIC, a evidência de roteamento atual do RIPEstat, as linhas de interconexão do PeeringDB, as páginas de instalações HKG1 e HKG5 da Rackspace, a documentação de hospedagem gerenciada e colocation da Rackspace e o próprio contrato do cliente. O risco não é que cada camada seja falsa.

O risco é que um cliente assuma que todas as camadas se aplicam ao seu serviço da mesma maneira.

O comprador deve, portanto, pedir à Rackspace para produzir um cronograma de serviço local. Ele deve nomear a instalação ou instalações, os ASNs e prefixos relevantes, o local de recuperação, a localização do backup, o modelo de suporte, exclusões de manutenção, o plano RPKI, controles de localidade de dados e o processo de saída. Uma marca global pode tornar esse cronograma mais fácil de obter. Ela não pode substituir o cronograma.

O que os clientes devem testar antes de confiar na borda de Hong Kong

O primeiro teste é o mapeamento. Peça à Rackspace para mapear o serviço para o AS45187, a instalação ou instalações, os prefixos de produção, os caminhos de gerenciamento, os caminhos de backup e os sistemas de suporte. Verifique a resposta do ASN com o RDAP da APNIC, os prefixos anunciados do RIPEstat, o registro Rackspace Hong Kong do PeeringDB e as páginas HKG1/HKG5 da Rackspace. Se o serviço do cliente não usar o AS45187, isso pode ser aceitável, mas deve ser claramente declarado.

O segundo teste é a falha. Remova um upstream, um caminho de troca, um roteador, um componente de armazenamento, um portal de suporte, uma credencial de cliente e um domínio de manutenção em um exercício de mesa ou ao vivo. Registre o que acontece com a acessibilidade, acesso ao console, DNS, monitoramento, backup, faturamento, tickets e exportação de dados. O resultado deve identificar qual parte do serviço é ativo-ativo, ativo-passivo, somente backup ou manual.

O terceiro teste é a segurança de roteamento. Pergunte sobre o status RPKI nos prefixos de produção exatos, incluindo quaisquer prefixos de propriedade do cliente. Pergunte como os ROAs são alterados durante a migração e quem aprova a alteração. Pergunte se os filtros de rota são mantidos para o AS45187 e os anúncios do cliente. O status RPKI público desconhecido não deve ser tratado como um escândalo; deve ser tratado como um item de controle em aberto.

O quarto teste é suporte e reparo. Use o vocabulário de mãos remotas do guia de colocation para tornar o exercício concreto. Quem abre o ticket? Quem pode ligar se o portal falhar? Quais tarefas estão incluídas, são faturáveis ou excluídas? Quais peças sobressalentes são fornecidas pela Rackspace, pelo cliente ou pelo fornecedor? Qual SLA de mãos remotas do HKG1 se aplica e qual é o equivalente para o serviço HKG5 exato? Se uma garantia de substituição de hardware começar dentro de uma hora após a identificação do problema, quem identifica o problema e o que marca o início?

O quinto teste é localidade e saída. Pergunte sobre a matriz de localidade de dados, incluindo primário, réplica, backup, logs, registros de suporte e identidade. Pergunte sobre evidência de exportação e um teste de restauração cronometrado. O material do PCPD deixa claro por que essas perguntas pertencem a uma discussão de nuvem de Hong Kong: o cliente permanece responsável pelo processamento de dados pessoais, mesmo ao usar um provedor de nuvem ou subcontratado.

O nível de evidência

Rackspace IT Hosting AS IT Hosting Provider Hong Kong recebe um nível Alto de evidência de rede pública. Esse nível reflete a identidade e a visibilidade operacional, não uma declaração ilimitada sobre todos os serviços da Rackspace. A APNIC vincula o AS45187 à Rackspace.com Hong Kong Limited. O RIPEstat mostra o AS45187 como anunciado, com 13 prefixos IPv4, 2 prefixos IPv6, visibilidade total do RIS observada no snapshot verificado e 23 vizinhos observados. O PeeringDB lista Rackspace Hong Kong com duas entradas de troca de 10G e uma linha de instalação em Hong Kong.

A Rackspace publica as páginas HKG1 e HKG5 com alegações concretas sobre instalações, energia, operadoras, rede e suporte.

O nível não é mais alto do que isso porque a evidência pública sempre para na fronteira do cliente. Ela não divulga a atribuição de rack de um cliente, contagem de servidores, energia reservada, topologia de armazenamento, geografia de backup, inventário de peças sobressalentes, fila de suporte, exclusões contratuais, cronograma de manutenção ou tempo de saída testado. Ela também deixa a autorização de origem de rota como uma questão em aberto, porque os prefixos atuais amostrados retornaram um status RPKI desconhecido em vez de válido.

A conclusão prática é restrita e útil: esta não é uma pegada de hospedagem fina em Hong Kong. É uma presença real e bem documentada de rede e instalações da Rackspace que ainda requer garantia específica do serviço. Os clientes não devem descartá-la como não verificável. Nem devem deixar que o nome Rackspace, duas páginas de data center de Hong Kong ou a superfície de rota visível do AS45187 substituam a evidência de falha que realmente protege uma carga de trabalho.

Quem sente a falha

As pessoas que primeiro sentem uma falha do AS45187 ou de uma instalação de Hong Kong podem ser proprietários de aplicativos, operadores de revenda, equipes de fintech, administradores de SaaS, varejistas online, proprietários de bancos de dados, gerentes de conformidade ou engenheiros de rede tentando manter os serviços do cliente acessíveis. O efeito downstream pode rapidamente passar da perda de pacotes para a perda de receita, de um alerta de armazenamento para uma obrigação regulatória perdida, de uma interrupção do portal para uma migração atrasada ou de uma disputa de faturamento para um bloqueio administrativo.

A escala da Rackspace pode reduzir alguns riscos. Ela tem operações globais de data center, SLAs publicados, instalações nomeadas em Hong Kong, linguagem de suporte madura e interconexão visível. A escala também pode ocultar a dependência específica do cliente. Um grande provedor pode ter muitas rotas, mas o cliente ainda depende do seu próprio design de serviço. Um grande provedor pode publicar garantias de substituição de hardware, mas o cliente ainda precisa saber se a peça com falha é fornecida pela Rackspace, fornecida pelo cliente ou controlada por outro fornecedor.

Um grande provedor pode ter engenheiros globais, mas o cliente ainda precisa de um caminho de escalonamento local e contratual.

É por isso que este artigo trata a Rackspace Hong Kong como uma dependência a ser entendida, e não um mistério a ser resolvido. A evidência pública é boa. A infraestrutura física é nomeada. A rede é visível. O registro de interconexão tem detalhes úteis. O trabalho restante é testar como esses fatos se comportam quando uma carga de trabalho real perde um rack, um upstream, um componente de hardware, um caminho de suporte, uma autorização de faturamento, uma janela de manutenção ou uma rota de migração. A capacidade hospedada é tão resiliente quanto as evidências por trás dessas respostas.