Resumo

  • A evidência pública mais sólida aponta para uma localização de infraestrutura clássica da IBM Cloud em Singapura, em vez de uma instalação comercializada separadamente. A própria documentação de faixas de IP da IBM listasng01em Jurong East, e as tabelas de localizações do Kubernetes e OpenShift da IBM listam Singapura como uma região clássica de único data center com a zonasng01; consultehttps://cloud.ibm.com/docs/infrastructure-hub?topic=infrastructure-hub-ibm-cloud-ip-ranges,https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zonesehttps://cloud.ibm.com/docs/openshift?topic=openshift-regions-and-zones.
  • A evidência do local físico se concentra ao redor do campus da Digital Realty na 29A International Business Park em Jurong East. A página atual do SIN10 da Digital Realty fornece o endereço e o tamanho do edifício emhttps://www.digitalrealty.com/data-centers/asia-pacific/singapore/sin10, enquanto os anúncios de locação anteriores da Digital Realty/SoftLayer e da IBM vinculam a expansão de hospedagem em nuvem, dedicada e gerenciada à essa mesma propriedade.
  • A evidência de rede é ampla no nível da IBM Cloud, mas escassa no nível da fazenda de servidores de Singapura. O PeeringDB identifica o AS36351 como SoftLayer Technologies, Inc. (uma empresa da IBM), também conhecido como IBM Cloud, com 1800 prefixos IPv4, 450 prefixos IPv6 e tráfego de 1 a 5 Tbps; o BGP.tools mostra interconexão do AS36351 em Singapura na BBIX Singapore. Esses são sinais globais úteis, não uma prova da colocação exata do cliente emsng01.
  • O principal risco operacional não é se a IBM Cloud existe em Singapura. É se o serviço de um determinado cliente está vinculado a um data center clássico, a uma rota Direct Link, a um pool de estoque de hardware, a uma fila de suporte, a um design de backup ou a uma rota de migração. Os próprios documentos do Direct Link da IBM afirmam que o Direct Link não é inerentemente redundante e que os clientes devem implementar diversidade.
  • O nível de evidência é Médio. Os registros públicos apoiam uma superfície de hospedagem real da IBM Cloud Singapura, mas não revelam a contagem atual de racks, a localização das cargas de trabalho dos clientes, a profundidade das peças de reposição, o prazo de locação da instalação, os procedimentos privados de reparo nem o failover testado entre Singapura e outras localizações da IBM Cloud.

O que se vende é nuvem; a dependência ainda é uma sala em Singapura

O nome IBM-SG-AP IBM Sinapore Server Farm é estranho, mas a pergunta operacional por trás dele é comum e importante: quando um cliente compra capacidade da IBM Cloud hospedada em Singapura, de qual sistema físico e contratual ele realmente depende? A IBM comercializa uma plataforma de nuvem global, servidores de metal nu, conectividade privada, armazenamento de objetos, serviços VPC e padrões de design de alta disponibilidade. O comprador experimenta esses serviços através de um console, uma API, uma tabela de preços, uma página de status do serviço e um caso de suporte. No entanto, a falha ainda tem um corpo.

Pode ser um rack que perde uma fonte de alimentação, um pedido de conexão cruzada atrasado pelo operador da instalação, uma configuração de servidor de reposição não disponível na cidade correta, um evento de manutenção do roteador, uma falha de sessão BGP, um backup do cliente que nunca saiu do local afetado ou um caso de suporte que perde o momento em que um operador ainda pode mover uma carga de trabalho de forma limpa.

O registro público é bom o suficiente para dizer que Singapura é uma localização real de infraestrutura da IBM Cloud. A documentação da IBM para faixas de IP de infraestrutura clássica emhttps://cloud.ibm.com/docs/infrastructure-hub?topic=infrastructure-hub-ibm-cloud-ip-rangeslistasng01em Jurong East e mostra faixas de endereços de balanceador de carga e rede privada associados a essa localização. A página de localizações da IBM emhttps://cloud.ibm.com/docs/overview?topic=overview-locationsexplica que clientes de infraestrutura clássica podem selecionar datacenters individuais e distingue datacenters clássicos de regiões multizona. A tabela de localizações do serviço Kubernetes da IBM emhttps://cloud.ibm.com/docs/containers?topic=containers-regions-and-zoneslista Ásia-Pacífico, Singapura, Singapura, metrôsng-mtr, zonasng01, gerenciado a partir do AP Norte. A tabela de localizações do OpenShift da IBM emhttps://cloud.ibm.com/docs/openshift?topic=openshift-regions-and-zonesrepete a mesma linha clássica de data center único de Singapura.

Esses documentos da IBM são importantes porque ancoram o ativo no vocabulário de serviço atual. Eles também estabelecem o limite da afirmação. Uma linha clássica de data center único não é o mesmo que uma região de Singapura tolerante a falhas com três zonas de disponibilidade independentes. A documentação mais ampla de localizações da IBM explica regiões multizona como uma forma de distribuir recursos entre localizações físicas, e regiões multizona de campus único como designs onde algumas dependências podem ser compartilhadas. A lista clássica desng01de Singapura não é apresentada nessas tabelas como uma região multizona de Singapura. Para um comprador, isso significa que um servidor colocado em Singapura pode atender aos requisitos de latência, jurisdição ou acesso local, mas não deve ser tratado como um design de resiliência completo por si só.

O registro físico aponta para Jurong East. A página SIN10 da Digital Realty emhttps://www.digitalrealty.com/data-centers/asia-pacific/singapore/sin10identifica 29A International Business Park, Jurong East, Singapura 609934, e descreve um edifício de sete andares e 377.000 pés quadrados. A página de mercado de Singapura da Digital Realty emhttps://www.digitalrealty.com/data-centers/asia-pacific/singaporelista SIN10 entre seus sites em Singapura e promove um ecossistema local de mais de 65 provedores de serviços em nuvem e rede. A entrada IBM SNG01 no datacentermap.com emhttps://www.datacentermap.com/singapore/singapore/softlayer-sng01/situa IBM SNG01 na 29A International Business Park. O Datacenters.com emhttps://www.datacenters.com/ibm-cloud-sng01-singaporefornece o mesmo endereço do International Business Park, embora também aponte que os detalhes públicos de espaço bruto e energia não estão disponíveis para essa entrada da IBM Cloud.

A história também é incomumente útil. A republicação da ACN Newswire do anúncio da Digital Realty sobre a SoftLayer emhttps://www.acnnewswire.com/press-release/english/7770/digital-realty-signs-softlayer-to-data-centre-lease-in-singaporediz que a SoftLayer alugou 48.000 pés quadrados na propriedade da Digital Realty na 29A International Business Park no segundo trimestre de 2011 para oferecer hospedagem em nuvem, dedicada e gerenciada na Ásia-Pacífico. O anúncio da Digital Realty no PR Newswire emhttps://www.prnewswire.com/news-releases/ibm-signs-turn-key-datacentre-lease-with-digital-realty-in-singapore-132661203.htmldiz que a IBM também assinou um contrato de locação turnkey de data center com a Digital Realty em Singapura em 2011. A história da SoftLayer no Data Center Knowledge emhttps://www.datacenterknowledge.com/business/softlayer-opens-singapore-data-centerinforma que a SoftLayer abriu um data center em Singapura com seu próprio andar dentro da mesma propriedade da Digital Realty. A subsequente aquisição da SoftLayer pela IBM, documentada pelas FAQs de aquisição da IBM emhttps://www.ibm.com/cloud-computing/SoftLayer_Acquisition_Announcement_FAQs.pdfe pelo anúncio de fechamento da IBM emhttps://www.prnewswire.com/news-releases/ibm-closes-acquisition-of-softlayer-technologies-214589711.html, explica por que a evidência de hospedagem da era SoftLayer ainda pertence à análise da IBM Cloud.

Isso é suficiente para tratar a superfície de hospedagem de Singapura como real. Não é suficiente para saber quais racks, salas, gaiolas ou dispositivos de cliente estão atualmente ativos. Anúncios de locação antigos não comprovam o prazo de locação atual. Uma página do site da Digital Realty não comprova a planta baixa atual da IBM. Uma listagem de data center de terceiros pode estar desatualizada. Os próprios documentos da IBM sobresng01mostram que a localização ainda faz parte do vocabulário do serviço, mas não publicam o número de servidores instalados, o número de gabinetes vazios, a reserva de energia, a política de peças de reposição ou a combinação atual de clientes. Portanto, a postura correta não é nem desdenhosa nem romântica: a capacidade hospedada é fundamentada, mas a borda visível publicamente não é um manual de operações completo.

A infraestrutura clássica é conveniente precisamente porque os clientes não veem cada dependência

A infraestrutura clássica da IBM Cloud torna a aquisição de infraestrutura aparentemente simples. A documentação de servidores de metal nu da IBM emhttps://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bmdiz que um servidor de metal nu da IBM Cloud é um servidor de único inquilino por hora ou por mês dedicado ao cliente e implementado em um ou mais datacenters. A página de introdução emhttps://cloud.ibm.com/docs/bare-metal?topic=bare-metal-getting-starteddiz que servidores de metal nu podem ser implementados na infraestrutura clássica da IBM Cloud ou na infraestrutura VPC da IBM Cloud. A página do produto emhttps://www.ibm.com/products/bare-metal-serversdiz que tanto as implementações clássicas quanto VPC são dedicadas e posiciona a infraestrutura clássica para operações grandes, de estado estável e previsíveis. A página de nuvem dedicada emhttps://www.ibm.com/products/bare-metal-servers/dedicated-cloudpromove mais de 11 milhões de combinações de configuração, flexibilidade de faturamento e opções de implementação global.

Essa é uma oferta comercial sólida. Também é um lembrete de que a hospedagem clássica não é mágica. Um servidor de único inquilino ainda é um chassi, placa, processador, memória, conjunto de discos, fonte de alimentação, interface de rede, caminho de gerenciamento fora da banda e porta de rack. A documentação de metal nu da IBM diz que testes de hardware estendidos podem ser executados quando um servidor é solicitado, e que testes de estresse podem prolongar o tempo de provisionamento. Isso é um controle de qualidade sensato.

Também expõe a compensação econômica: os clientes podem pagar pela abstração limpa de um servidor pronto, mas o provisionamento ainda depende do hardware e dos testes no local escolhido. Se uma configuração é escassa em Singapura, a experiência do console não pode fabricar peças em Jurong East.

O problema do data center único é mais grave para serviços clássicos do que para uma região de nuvem multizona. Os documentos do Kubernetes e OpenShift da IBM listam Singapura como uma região clássica de data center único. A página de localizações do Transit Gateway da IBM emhttps://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-tg-locationslista SingapuraSNG01entre os datacenters clássicos que podem conectar a infraestrutura clássica com recursos VPC. Isso é útil porque mostra que a IBM tem uma ponte compatível entre recursos clássicos e designs de rede VPC mais novos. Também confirma que o cliente tem trabalho de design a fazer. A compatibilidade com o Transit Gateway não coloca automaticamente uma carga de trabalho em múltiplas localizações físicas. Ela fornece uma forma de conectar recursos; o cliente ainda deve escolher onde a segunda cópia, backup, rota ou servidor de reposição reside.

Essa distinção é central para o título do artigo. A IBM vende capacidade hospedada que depende de racks, trânsito e janelas de reparo porque cada camada tem um caminho de falha diferente. Se o cliente compra um servidor de metal nu emsng01, o provedor pode manter a rede e a instalação saudáveis enquanto a própria aplicação do cliente ainda é frágil porque não tem um segundo nó. Se o cliente compra Direct Link para Singapura, mas não um segundo Direct Link, o acesso privado pode falhar mesmo enquanto o servidor e a rede pública permanecem saudáveis. Se o cliente confia no IBM Cloud Backup for Classic, mas não testa uma restauração bare-metal, o serviço de backup pode existir enquanto a recuperação ainda é incerta. Se o cliente armazena um modelo de imagem, mas não seus segredos, DNS, regras de firewall ou anexos, a migração pode ser tecnicamente possível e operacionalmente incompleta.

A IBM publica algum material de migração e portabilidade e coloca a responsabilidade no lugar certo. A visão geral de migração de infraestrutura clássica emhttps://cloud.ibm.com/docs/infrastructure-hub?topic=infrastructure-hub-about-migration-infradiz que modelos de imagem personalizados podem capturar uma imagem de metal nu clássica para solicitar mais servidores de metal nu clássicos com as mesmas configurações. A visão geral de migração de metal nu clássico da IBM emhttps://cloud.ibm.com/docs/infrastructure-hub?topic=infrastructure-hub-p-p-migration-bare-metal-overviewdiz que a migração pode usar interfaces públicas ou privadas e que a migração por interface privada utiliza a rede da IBM. A página de portabilidade de dados VPC emhttps://cloud.ibm.com/docs/vpc?topic=vpc-data-portabilityexplica a exportação de imagens para o IBM Cloud Object Storage para imagens personalizadas. Mas a página de portabilidade de dados de metal nu clássico da IBM emhttps://cloud.ibm.com/docs/bare-metal?topic=bare-metal-data-portabilityé contundente: servidores de metal nu são totalmente gerenciados pelo cliente, e o cliente é responsável por determinar sua própria solução de exportação de dados.

Essa frase é o centro prático do risco. Um provedor pode oferecer a sala, a rede, o hardware, a rede privada e o canal de suporte. Ele não pode criar retroativamente uma exportação utilizável se o cliente nunca projetou uma. Para clientes em Singapura, isso significa que a pergunta de aquisição nunca deve parar em "Posso implementar em Singapura?" Ela deve perguntar: posso reconstruir em outra localização próxima da IBM em Singapura ou em outro provedor se o recursosng01não estiver disponível? Posso mover uma imagem personalizada? Posso restaurar o estado a partir de um bucket cuja localização e durabilidade eu entendo? Posso alterar DNS e conectividade antes que a janela de manutenção se torne uma interrupção? Minha equipe pode operar o ambiente alvo sem a mesma permissão de console, host de salto ou link privado que falhou?

Direct Link melhora o acesso privado, mas não elimina o design da rota

O IBM Cloud Direct Link é importante porque é provavelmente a rota empresarial para esse tipo de capacidade hospedada. A visão geral do Direct Link da IBM emhttps://cloud.ibm.com/docs/dl?topic=dl-dl-aboutdescreve a conectividade de uma fonte externa para a rede privada da IBM Cloud de um cliente, como alternativa à VPN site a site tradicional para clientes que precisam de conectividade mais consistente e de maior desempenho. A página do produto Direct Link emhttps://www.ibm.com/products/direct-linkdescreve casos de uso que incluem transferência de dados, replicação para continuidade de negócios, recuperação de desastres, backup e acesso a partir de infraestrutura privada. A página de localizações emhttps://cloud.ibm.com/docs/dl?topic=dl-locationslista as localizações de provedores Direct Link Connect na APAC, incluindo Digital Realty Singapore 1 e Equinix Singapore 2. A página de comparação emhttps://cloud.ibm.com/docs/dl?topic=dl-dl-comparison-locationslista Singapura 1 e Singapura 2 no conjunto de localizações do Direct Link.

Esses fatos dizem duas coisas aos clientes. Primeiro, Singapura não é apenas uma localização de computação. É também um mercado de conectividade privada no mapa de produtos da IBM Cloud. Segundo, há uma diferença entre comprar um serviço de acesso e projetar redundância. A página de responsabilidades da IBM emhttps://cloud.ibm.com/docs/dl?topic=dl-dl-responsibilitiesdiz que a IBM fornece opções de rede diversas, enquanto o cliente deve garantir que a diversidade do Direct Link seja implementada. A mesma página diz que o Direct Link não é um serviço redundante, e que o failover deve ser construído no design BGP do cliente entre múltiplos Direct Links. As FAQs do Direct Link emhttps://cloud.ibm.com/docs/direct-link?topic=direct-link-faqsdizem que o Direct Link pode fornecer conexões diversas, mas não é inerentemente redundante. O guia de introdução emhttps://cloud.ibm.com/docs/dl?topic=dl-get-started-with-ibm-cloud-dlrecomenda estabelecer um segundo Direct Link diverso para evitar interrupções, sejam planejadas ou não.

Essa é uma linguagem de provedor incomumente clara. Ela evita a armadilha em que uma conexão de nuvem privada é comercializada como resiliência por padrão. Na realidade, o Direct Link pode reduzir a exposição à internet pública e melhorar a previsibilidade de desempenho, mas cria sua própria superfície de dependência: a localização da nuvem, o roteador do cliente, a porta do provedor, o cross connect, a malha de troca ou a rota da operadora, a configuração BGP, os filtros de rota, as janelas de manutenção e o status de faturamento. Quando um cliente se conecta a Singapura 1 ou Singapura 2, não é suficiente perguntar se a porta está ativa.

O cliente deve perguntar se as duas rotas compartilham uma instalação, uma operadora, um roteador, um contrato, uma entrada física, uma equipe de operações ou um calendário de manutenção.

A evidência de Singapura é útil, mas incompleta. A IBM lista Digital Realty Singapore 1 e Equinix Singapore 2 como opções do Direct Link Connect. O BGP.tools emhttps://bgp.tools/as/36351mostra interconexão do AS36351 na BBIX Singapore com uma entrada de 10 Gbit/s em sua visão pública. A página do AS36351 no PeeringDB emhttps://www.peeringdb.com/net/1613identifica SoftLayer Technologies, Inc. (uma empresa da IBM), também conhecido como IBM Cloud, e lista tráfego de 1 a 5 Tbps com uma grande contagem de prefixos globais. O Cloudflare Radar emhttps://radar.cloudflare.com/routing/as36351rastreia AS36351 como SOFTLAYER -- IBM Cloud. Essas fontes de terceiros apoiam a ideia de que a IBM Cloud é uma rede roteada substancial com presença na Ásia-Pacífico. Elas não mostram como um cliente hospedado específico de Singapura é transportado de seu rack para a borda global do AS36351.

Essa distinção importa durante a manutenção. Uma atualização planejada de um roteador pode ser inofensiva se o tráfego é movido através de uma segunda rota testada. O mesmo evento pode se tornar visível para o cliente se ambos os Direct Links aterrissam em domínios de falha compartilhados ou se o cliente anuncia apenas um conjunto de prefixos. Um atraso no cross connect da instalação pode ser trivial se o cliente já tem um link de backup. Pode ser grave se o segundo link foi solicitado apenas após o primeiro começar a falhar. Um filtro de rota BGP pode ser uma correção rápida se ambas as equipes têm objetos de rota e contatos documentados.

Pode consumir horas se o pessoal de rede do cliente, o pessoal de suporte da IBM e a operadora veem apenas seu próprio lado do caso.

Por esta razão, a pegada de hospedagem de Singapura deve ser avaliada como uma cadeia de dependências, não como um único nome de instalação. A computação hospedada, o link privado, a rota de internet pública, o armazenamento de backup, DNS e o suporte são camadas separadas. O Direct Link torna uma camada mais forte quando bem projetado. Também pode tornar uma dependência menos visível se as equipes assumem que "privado" significa "resiliente". Os documentos da IBM colocam o ônus do design à vista. Os compradores devem usar essa clareza.

IBM Cloud Object Storage e as opções de backup só ajudam quando a localização é deliberada

Backup e portabilidade de dados são onde muitas falhas de capacidade hospedada deixam de ser surpresas técnicas e se tornam falhas de gerenciamento. O IBM Cloud Object Storage tem uma história de resiliência pública mais sólida do que um único servidor clássico. A documentação de endpoints e localizações de armazenamento emhttps://cloud.ibm.com/docs/cloud-entidade-storage?topic=cloud-entidade-storage-endpointsdiz que buckets regionais distribuem dados em três datacenters em uma área metropolitana, e que o acesso entre regiões tem um perfil de desempenho e resiliência diferente. A documentação de endpoints legados emhttps://cloud.ibm.com/docs/cloud-entidade-storage?topic=cloud-entidade-storage-remap-endpointsdiz que um endpoint regional distribui dados em três datacenters, e qualquer um desses datacenters pode sofrer uma interrupção ou mesmo destruição sem afetar a disponibilidade. A página de resiliência do Object Storage emhttps://www.ibm.com/products/cloud-entidade-storage/resiliencydescreve opções entre regiões, regionais e de data center único.

Isso é poderoso se o cliente escolhe a classe de armazenamento correta e testa as restaurações. Não é uma solução universal para a dependência desng01. A localização do bucket do Object Storage deve corresponder ao objetivo de recuperação. Um bucket de data center único pode ser adequado por latência ou custo, mas não resolve uma interrupção em escala de data center. Um bucket regional pode fornecer distribuição em nível metropolitano se o serviço estiver disponível na geografia relevante, mas o cliente ainda precisa saber se pode reconstruir a computação e a rede na localização alvo. Um bucket entre regiões pode ajudar na recuperação de desastres mais ampla, mas pode introduzir problemas de latência, soberania e custo de transferência. Para uma carga de trabalho em Singapura, a frase "os dados permanecem em Singapura" pode entrar em conflito com a frase "sobrevive a um problema de serviço em toda Singapura" a menos que o cliente faça uma compensação consciente.

O IBM Cloud Backup for Classic atende a uma necessidade diferente. O guia de introdução emhttps://cloud.ibm.com/docs/Backup?topic=Backup-getting-starteddescreve o IBM Cloud Backup for Classic como um sistema baseado em agente para proteger dados em servidores com agendamentos e complementos. A página de backup de servidores virtuais emhttps://cloud.ibm.com/docs/virtual-servers?topic=virtual-servers-backup-servicesdiz que administradores podem definir agendamentos por hora, diários, semanais ou personalizados para sistemas completos, diretórios ou arquivos. O guia de restauração bare-metal emhttps://cloud.ibm.com/docs/Backup?topic=Backup-configureBMRdescreve o portal Cloud Backup e os trabalhos de restauração bare-metal. Essas páginas mostram que a IBM oferece ferramentas de backup para infraestrutura clássica. Também mostram que o backup é um serviço configurado, não uma propriedade automática de ter um servidor.

O caminho de falha é fácil de imaginar. Um cliente compra um servidor de metal nu em Singapura porque quer latência local e recursos dedicados. Ele adiciona um Direct Link porque quer acesso privado estável. Ele usa um serviço de backup, mas armazena a documentação de restauração em um sistema interno acessível apenas através do mesmo Direct Link.

Durante um incidente, o servidor está inativo, a rota privada está degradada, o caso de suporte está aberto e a equipe percebe que os backups estão presentes, mas não são rápidos o suficiente, não são consistentes com a aplicação, não podem ser restaurados em outra cidade, ou não estão documentados para um membro da equipe fora do grupo de administração normal. Nada nesse cenário contradiz a documentação pública da IBM. É precisamente por isso que a responsabilidade do cliente importa.

A portabilidade tem uma forma similar. A IBM documenta modelos de imagem personalizados e exportação de imagem VPC. Esses mecanismos podem reduzir o atrito de sair ou reconstruir, mas não eliminam as tarefas de licenciamento, identidade, segredos, endereçamento de rede, firewall, DNS e sincronização de dados. Uma imagem personalizada é útil quando a aplicação é amigável a imagens. É menos útil quando o estado importante reside em volumes anexados, em um banco de dados, em um compartilhamento NAS, em logs de aplicação, em arquivos de configuração corrigidos manualmente ou em uma integração privada que ninguém reconstruiu em outro lugar. Para um cliente operando em Singapura, o teste de portabilidade deve ser ao vivo e medido. A equipe pode lançar uma substituição fora desng01? Pode restaurar dados lá? Os usuários podem alcançá-lo? Pode manter garantias suficientes de conformidade e latência para operar durante o evento?

A melhor evidência seria específica do cliente: localização alvo de backup, resultados de testes de tempo de restauração, logs de exportação de imagem, notas de construção do segundo site, teste de failover do Direct Link, contatos de escalonamento de suporte e manuais de operação da aplicação. Esses não são públicos, e este artigo não deve fingir que são. O registro público diz que a IBM fornece ferramentas. Também diz que a responsabilidade permanece compartilhada e específica do serviço.

O mercado de instalações ao redor de Jurong East levanta questões sobre energia e locação

Singapura é um mercado de datacenters de alto valor precisamente porque terra, energia, resfriamento e conectividade são escassos. A pegada da IBM em Singapura está dentro dessa restrição mais ampla. O Roteiro de Datacenters Verdes da IMDA emhttps://www.imda.gov.sg/how-we-can-help/green-dc-roadmapdiz que Singapura visa fornecer pelo menos 300 MW de capacidade adicional a curto prazo, com mais possível através de implementações de energia verde. O anúncio da IMDA de 2023 emhttps://www.imda.gov.sg/resources/press-releases-factsheets-and-speeches/press-releases/2023/four-data-centre-proposals-selected-as-part-of-pilot-data-centre-call-for-applicationdiz que a pausa temporária no crescimento de datacenters foi suspensa em 2022 e que uma chamada piloto selecionou quatro propostas. O resumo do Conselho de Desenvolvimento Econômico de Singapura emhttps://www.edb.gov.sg/en/business-insights/insights/singapore-to-expand-data-centre-capacity-by-at-least-one-third-pushes-for-green-energy-use.htmldescreve pelo menos 300 MW de capacidade adicional de data center e possivelmente outros 200 MW para operadores que usam opções de energia verde.

Essas fontes oficiais não são específicas da IBM, mas são diretamente relevantes para o IBM-SG-AP IBM Sinapore Server Farm porque a capacidade hospedada em Singapura é limitada pelos mesmos mercados de insumos. Um provedor de nuvem pode renovar servidores e vender novas configurações apenas quando tem espaço, energia, resfriamento, portas de rede, cadeia de suprimentos e permissão para operar. Se a capacidade de Singapura é limitada, os clientes devem perguntar se um perfil de servidor desejado está disponível emsng01, se configurações maiores exigem outra localização da IBM Cloud, se capacidade reservada é possível e quanto tempo leva a substituição de hardware durante um aumento regional na demanda.

A história da Digital Realty na 29A International Business Park dá a essa pergunta uma forma concreta. O anúncio da Digital Realty/SoftLayer de 2011 dizia que a propriedade era uma instalação de 370.500 pés quadrados em Jurong East, com até 30 MW de capacidade UPS 2N e mais de 4,5 MW de carga de TI em cada um dos seis andares do data center. A história de aquisição da Digital Realty pelo Data Center Knowledge emhttps://www.datacenterknowledge.com/next-gen-data-centers/digital-realty-buys-singapore-data-centerdescreveu o mesmo local como pronto para ocupação do cliente em 2011 com mais de 4,5 MW de carga de TI em cada um dos seis andares e resfriamento contínuo N+2. A página atual SIN10 da Digital Realty fornece um tamanho de edifício atual próximo, enquanto a página atual de Singapura lista certificações e afirmações do ecossistema para o mercado.

A lacuna de evidência é o que importa. Os documentos públicos não dizem quanto da antiga pegada da IBM ou SoftLayer permanece alugada, quanto mudou após a IBM adquirir a SoftLayer, como a IBM aloca os produtossng01no espaço atual, ou se há capacidade mantida em reserva. Também não divulgam os limites atuais de densidade de energia para os racks da IBM nesse local. Um cliente que compra um servidor normal pode não precisar desses detalhes. Um cliente que planeja uma grande expansão em Singapura, uma carga de trabalho regulada, uma atualização de dispositivo ou uma grande frota de metal nu precisa. Sem essa evidência, um contrato pode prometer um serviço enquanto o próprio plano de expansão do cliente ainda depende de uma questão de capacidade em nível de instalação.

O mesmo problema aparece no suporte e manutenção. A página de status da IBM Cloud emhttps://cloud.ibm.com/statuse o histórico de status emhttps://cloud.ibm.com/status/historyfornecem aos clientes uma forma pública de ver os avisos da plataforma. O guia de suporte da IBM emhttps://cloud.ibm.com/docs/support?topic=support-viewing-statusexplica como visualizar incidentes importantes, manutenção planejada e boletins de segurança. A página de ajuda de metal nu emhttps://cloud.ibm.com/docs/bare-metal?topic=bare-metal-bare-metal-help-and-supportdireciona os usuários para documentação, status e recursos de suporte. A página de gravidade de suporte emhttps://cloud.ibm.com/docs/support?topic=support-support-case-severityexplica a gravidade e os objetivos de resposta de acordo com o plano de suporte, enquanto a página de gravidade de suporte empresarial emhttps://www.ibm.com/support/pages/ibm-enterprise-support-severity-definitionsdiz que os clientes da IBM Cloud devem registrar um caso de serviço interrompido dentro de 24 horas após terem conhecimento do impacto crítico nos negócios.

Esses processos são valiosos, mas não são o mesmo que reparo. Uma página de status pode confirmar que a IBM vê um problema. Um caso de suporte pode colocar o cliente na fila. Uma definição de gravidade pode definir expectativas. O reparo ainda depende de qual camada falhou e quem tem autoridade para agir. Se o problema é um disco com falha em um servidor dedicado, o acesso ao hardware e as peças de reposição importam. Se o problema é Direct Link, importam BGP, cross connect ou coordenação da operadora. Se o problema é um incidente em nível de plataforma, importa a arquitetura do cliente.

Se o problema é faturamento ou acesso à conta, importam a autoridade operacional e os controles de identidade. Os clientes precisam de um manual que atribua cada falha ao canal correto da IBM e ao proprietário interno correto.

AS36351 demonstra escala, não recuperação por cliente

A evidência de rede para a IBM Cloud é substancial em nível de sistema autônomo. O PeeringDB emhttps://www.peeringdb.com/net/1613identifica o AS36351 como SoftLayer Technologies, Inc. (uma empresa da IBM), também conhecido como IBM Cloud, com anulação do site webhttps://www.ibm.com/cloud, tipo de rede conteúdo, 1800 prefixos IPv4, 450 prefixos IPv6 e tráfego de 1 a 5 Tbps. O BGP.tools emhttps://bgp.tools/as/36351chama a IBM Cloud de uma rede crítica de Internet de longa duração, com centenas de pares e múltiplos operadores upstream, e mostra uma entrada de interconexão em Singapura na BBIX Singapore. A página do Hurricane Electric emhttps://bgp.he.net/as36351lista o AS36351 como IBM Cloud e mostra muitas entradas de rede IPv6 associadas à IBM Cloud e à IBM Cloud International B.V. O Cloudflare Radar emhttps://radar.cloudflare.com/routing/as36351fornece visibilidade de roteamento independente para o AS36351.

Isso é evidência sólida de que a IBM Cloud tem uma grande espinha dorsal roteada. Também é muito ampla para provar a resiliência desng01. Um ASN pode ser global enquanto um recurso de cliente dado é local. Um conjunto de prefixos global pode permanecer saudável enquanto uma sala de data center, um switch de acesso, um sistema de armazenamento, um firewall, uma VLAN privada ou uma porta Direct Link são afetados. Uma entrada de interconexão em Singapura pode melhorar a latência ou a acessibilidade, mas não diz por onde o tráfego de cada servidor hospedado sai, como as VLANs privadas do cliente são alocadas, ou se a rota sobrevive a um evento no local.

A política de interconexão pública da IBM emhttps://cloud.ibm.com/docs/overview?topic=overview-public-peeringdiz que a interconexão pública ocorre através de uma rede compartilhada e que solicitações de interconexão podem ser aceitas quando existe uma necessidade operacional mutuamente acordada. Essa é uma postura operacional normal. Também significa que a interconexão pública é uma decisão comercial gerenciada, não uma garantia para o cliente de que cada destino usará uma rota local desejada. Para as empresas, a pergunta relevante não é "A IBM tem um ASN grande?" É "Meu design de serviço usa a rede da IBM de uma forma que sobrevive às falhas que me importam?"

Essa pergunta se torna crítica na Ásia-Pacífico. Um cliente hospedado em Singapura pode atender usuários em Singapura, Malásia, Indonésia, Índia, Austrália, Japão, Europa e América do Norte. Pode depender de roteamento de internet pública, Direct Link, VPN, CDN, IBM Cloud Internet Services ou trânsito do cliente. Cada rota tem um proprietário operacional diferente. O IBM Cloud Internet Services, descrito emhttps://www.ibm.com/products/cloud-internet-services, pode trazer serviços de desempenho e segurança impulsionados pela Cloudflare para o design, mas é um serviço de gateway, não um substituto para a resiliência da origem. O Direct Link pode fornecer acesso privado, mas a IBM diz que o cliente deve projetar a redundância. O Object Storage pode oferecer diferentes opções de durabilidade, mas o cliente deve escolher a localização do bucket. O metal nu pode fornecer único inquilino, mas o cliente deve projetar o backup e a portabilidade.

Por esta razão, o AS36351 deve ser usado como contexto de monitoramento, não como prova de recuperação segura. Monitore o AS36351 e o status da IBM Cloud. Observe anomalias de rota pública. Acompanhe os avisos do Direct Link em Singapura. Mas atribua o serviço do cliente a recursos exatos: data center clássico, VLAN, ID de servidor, gateways do Direct Link, sessões BGP, alvos de backup, buckets do Object Storage, DNS, identidade, plano de suporte e localização de implementação alternativa. O plano de controle da internet pública é uma camada da resposta.

Quem é afetado quando a superfície de hospedagem de Singapura falha?

O grupo imediatamente afetado não são os "usuários da IBM" em geral. É qualquer cliente cuja carga de trabalho, caminho de gerenciamento, conectividade privada ou ativos de recuperação dependem da pegada clássica de Singapura. Isso inclui empresas que colocaram servidores de metal nu emsng01para baixa latência; equipes que mantiveram recursos clássicos do Kubernetes ou OpenShift em Singapura; clientes usando infraestrutura clássica conectada a recursos VPC através do Transit Gateway; clientes com Direct Link para Singapura; e organizações que selecionaram Singapura por localidade de dados ou acesso à Ásia-Pacífico.

O raio de explosão depende do design. Um cliente com um servidor, um IP público, nenhuma segunda localização e um plano de backup manual pode estar completamente inativo quando um pequeno problema de hardware ou instalação afeta esse ativo. Um cliente com vários servidores no mesmo data center pode sobreviver a uma falha de máquina única, mas não a um evento de energia, resfriamento, acesso, switch ou plano de controle em nível de site. Um cliente com computação em Singapura e armazenamento entre regiões pode preservar os dados, mas ainda carecer de capacidade de computação em outro lugar. Um cliente com automação de build testada, exportações de imagem, armazenamento entre regiões, um segundo Direct Link e DNS global pode tratarsng01como uma localização importante em vez de todo o serviço.

O grupo regulatório é mais amplo. A localidade de dados de Singapura é frequentemente atraente para cargas de trabalho de serviços financeiros, governo, saúde, logística e sedes regionais. A página de conformidade da IBM Cloud emhttps://cloud.ibm.com/docs/overview?topic=overview-compliancedescreve certificações como ISO 27001, PCI e SOC2 e discute a Estrutura da IBM Cloud para Serviços Financeiros. Essas certificações e controles são importantes para a aquisição. Elas não respondem por si mesmas onde cada backup, artefato de suporte, log, chave de criptografia ou ação administrativa reside. Um cliente regulado deve traduzir "implementação em Singapura" em um mapa de dados completo: computação primária, armazenamento, backup, monitoramento, logs, tickets de suporte, papéis de acesso, exposição de subprocessadores e localização de restauração de emergência.

O grupo de migração também é importante. Clientes executando infraestrutura clássica mais antiga podem eventualmente precisar migrar para VPC, outra região da IBM ou outro provedor. A IBM documenta a migração de Clássico para VPC para servidores virtuais emhttps://cloud.ibm.com/docs/vpc?topic=vpc-migrate-vsi-to-vpce o planejamento de imagens personalizadas emhttps://cloud.ibm.com/docs/vpc?topic=vpc-planning-custom-images. Essas páginas mostram um caminho, mas a migração raramente é um evento de um botão para sistemas de produção. O cliente tem que lidar com mudanças de IP, diferenças de firewall, balanceadores de carga, permissões de identidade, exportações de armazenamento, compatibilidade de aplicações, monitoramento, DNS, comunicação com o usuário e reversão. Um incidente em Singapura pode expor se esse trabalho foi feito cedo ou deixado para a primeira noite ruim.

O grupo econômico inclui clientes que usam hardware dedicado porque querem desempenho previsível ou controle de licenciamento. A oferta de metal nu da IBM é atraente para SAP, VMware, cargas de trabalho de alto desempenho e controle de único inquilino. Mas esses mesmos clientes podem ser mais sensíveis à disponibilidade exata do perfil de hardware. Um recurso virtual pode ser substituível a partir de um pool mais amplo. Uma configuração de metal nu personalizada pode ser substituível apenas se houver estoque correspondente no local certo.

O contrato e a arquitetura do cliente devem dizer o que acontece quando o mesmo processador, RAM, GPU, armazenamento ou perfil de rede não está disponível imediatamente em Singapura.

Pontos de vigilância para compradores e operadores

O primeiro ponto de vigilância é a localização exata. Peça à IBM para identificar se o serviço está emsng01, outra localização de Singapura, uma região multizona VPC em outro lugar, ou um serviço gerenciado cujo armazenamento e plano de controle têm sua própria localização. Não assuma que um rótulo de Singapura, endereço de faturamento de Singapura ou área de serviço da Ásia-Pacífico significa a mesma dependência física. Os próprios documentos da IBM distinguem datacenters clássicos, regiões, designs de campus único e regiões multizona. Use esses termos com cuidado.

O segundo ponto de vigilância é a diversidade do Direct Link. Se o acesso privado é importante, um único Direct Link não é suficiente. Os documentos da IBM dizem que o Direct Link não é inerentemente redundante e recomendam um segundo link diverso. O cliente deve documentar se Singapura 1 e Singapura 2 são verdadeiramente diversos para sua combinação de provedores, se o failover BGP é automático, se os filtros de rota são testados, se as escolhas de roteamento local e global correspondem ao design de recuperação, e se os contatos de suporte são conhecidos tanto no lado da operadora quanto no da IBM.

O terceiro ponto de vigilância é o hardware de reposição e o tempo de reconstrução. As páginas públicas da IBM não revelam a profundidade de reposição desng01. Clientes com servidores dedicados devem perguntar como componentes com falha são substituídos, se existem sistemas de reposição correspondentes, como testes de hardware estendidos afetam o provisionamento urgente, se um perfil equivalente pode ser substituído, e se a aplicação pode tolerar uma realocação para outra localização. Para cargas de trabalho com GPU, alta memória ou licenciadas, a resposta pode decidir se o serviço simplesmente não está disponível ou está comercialmente travado.

O quarto ponto de vigilância é a geografia do backup. O IBM Cloud Backup for Classic e o Object Storage podem ajudar, mas apenas se o alvo de backup e o alvo de restauração são escolhidos deliberadamente. Um backup local pode ser rápido, mas dependente do local. Um bucket entre regiões pode melhorar a sobrevivência, mas pode afetar soberania, latência e custo. Uma imagem personalizada pode ajudar a reconstruir, mas pode não incluir todo o estado. Um servidor de metal nu ainda é gerenciado pelo cliente para decisões de exportação.

O quinto ponto de vigilância são os pontos cegos do status público. As páginas de status da IBM Cloud são úteis, mas muitas falhas de clientes não são incidentes globais. Um anúncio BGP mal configurado, uma falha de Direct Link único, um problema de permissões de conta, um problema de VLAN privada, um disco com falha, um erro de firewall do cliente ou um certificado expirado podem não aparecer como um incidente público amplo. Os clientes precisam de seu próprio monitoramento de fora da IBM Cloud, de dentro da IBM Cloud, através do Direct Link e das geografias dos usuários.

O sexto ponto de vigilância é a opacidade da locação e das instalações. A história da Digital Realty e da SoftLayer apoia firmemente a âncora física de Singapura, mas a evidência pública não revela o espaço atual da IBM, o prazo de locação, a sala exata, a contagem de racks ou a reserva de energia. Clientes grandes devem buscar confirmações atuais de instalações e capacidade através de aquisições, especialmente quando planejam expansões que precisam de hardware reservado, residência de dados de longo prazo ou cobertura de suporte especial.

O sétimo ponto de vigilância é o custo de saída. A IBM Cloud pode fornecer mecanismos de portabilidade, mas mover uma carga de trabalho de Singapura ainda pode ser lento se o cliente depende de endereços IP locais, links privados, automação proprietária, imagens manuais ou volumes de dados difíceis de exportar. Um plano de saída genuíno inclui um teste de restauração recente, não apenas um documento dizendo que a exportação é possível.

Nível de evidência: Médio, com uma clara degradação para o ativo nomeado

A evidência da IBM Cloud em Singapura é mais forte do que a evidência de uma "IBM Sinapore Server Farm" com marca separada. A própria documentação da IBM fornecesng01, Jurong East, infraestrutura clássica, linhas de localização do Kubernetes e OpenShift clássicos, compatibilidade com Transit Gateway, localizações do Direct Link em Singapura e descrições de serviços de metal nu. A Digital Realty, PR Newswire, ACN Newswire, Data Center Knowledge, Datacentermap.com e Datacenters.com fornecem contexto físico e histórico em torno da 29A International Business Park. O PeeringDB, BGP.tools, Hurricane Electric e Cloudflare Radar mostram a superfície de rede mais ampla do AS36351.

A evidência ainda não é forte o suficiente para declarar a capacidade instalada versus capacidade utilizável, disposição dos racks, colocação dos clientes, failover multissite, profundidade das peças de reposição, status atual da locação ou autoridade de reparo exata. Também não é forte o suficiente para dizer que a hospedagem clássica de Singapura oferece o mesmo perfil de resiliência que uma região multizona da IBM Cloud.

Os próprios documentos da IBM empurram o cliente para um design explícito: diversidade do Direct Link, configuração de backup, exportação de imagem, gravidade do suporte, monitoramento de status do serviço e escolha de localização. Essa é a forma correta de ler o ativo.

Para um cliente, a ação é prática. Trate o IBM-SG-AP IBM Sinapore Server Farm como uma superfície de dependência da IBM Cloud em Singapura, não como uma marca misteriosa e não como uma região de nuvem totalmente auto-curativa. Confirme a localização exata desng01se a localidade é importante. Construa uma segunda rota de rede se o acesso privado é importante. Mantenha backups fora do domínio de falha que eles devem sobreviver. Teste a exportação e restauração de imagem antes que o caso de suporte seja urgente. Pergunte sobre o estoque de hardware antes de pedir um perfil que não pode ser facilmente substituído. Monitore o AS36351 e o status da IBM Cloud, mas não confunda escala de rede global com recuperação por carga de trabalho. O pedido da nuvem pode ser digital; o caminho de restauração ainda é físico, contratual e compartilhado entre a IBM, operadores de instalações, operadores de rede e o cliente.