Resumo
- A PT Semarang Data Center é atualmente melhor documentada como operadora de um site de interconexão compacto em Semarang e do PANDA-IX, e não como um grande salão de dados divulgado. Sua oferta comercial pública é voltada para colocation de 1U, 2U e 4U para equipamentos de rede, e sua instalação listada é a sala 214 no segundo andar do Hotel Pandanaran.
- O PANDA-IX possui evidências operacionais atuais: o PeeringDB lista um único site em Semarang, 14 pares, 15 conexões e 138 G de capacidade de porta nominal, enquanto o looking glass público do route-server exibia 362 dias de disponibilidade em 13 de julho de 2026 com várias sessões BGP IPv4 e IPv6 estabelecidas.
- As evidências do site ainda não demonstram uma capacidade resiliente utilizável. Os documentos públicos não divulgam a potência total de projeto, a carga de TI instalada, o número de racks, a topologia do UPS, a autonomia do gerador, as disposições de combustível, a redundância de resfriamento, as entradas de fibra separadas, as alimentações duplas, os caminhos de entrega das operadoras ou os testes de failover dos clientes.
- O AS154034 atualmente não tem visibilidade global no RIS, mas isso não é por si só um veredito de falha. Um ASN de route-server pode sustentar uma estrutura de troca local sem anunciar prefixos globalmente acessíveis; o teste correto é se as sessões locais, os caminhos dos clientes e a acessibilidade externa sobrevivem a falhas específicas.
Uma sala compacta deve sustentar uma reivindicação urbana
A história pública do Semarang Data Center começa com uma ideia regional útil. As redes de Java Central não deveriam ser obrigadas a enviar cada troca local de tráfego via Jacarta ou outro hub maior quando uma entrega local é possível. Um pequeno site de interconexão em Semarang pode encurtar os caminhos entre operadoras vizinhas, reduzir o uso de trânsito evitável e oferecer aos provedores regionais um lugar para estabelecer peering sem se comprometer com um rack completo em um data center distante. É uma reivindicação prática, e as evidências públicas mostram que ela ultrapassou o estágio de prospecto.
O PANDA-IX tem um exchange listado, uma visão de route-server ao vivo e um conjunto de entidades de rede.
As mesmas evidências também reduzem a reivindicação. A PT Semarang Data Center indica em seupróprio siteque foi estabelecida em fevereiro de 2025 e opera na indústria de colocation de data centers para Java Central. A oferta comercial é pequena e específica: pacotes de 1U, 2U e 4U, cada um descrito para equipamentos de rede. A empresa também apresenta o Panda Internet Exchange, ou PANDA-IX, como o local onde os clientes podem trocar tráfego. Essa combinação aponta para uma instalação focada em interconexão: roteadores, switches, cross-connects e sessões BGP locais são o centro de gravidade público.
O endereço físico torna a questão de infraestrutura mais precisa. O site da operadora informa a localização do data center como Hotel Pandanaran, segundo andar, Jalan Pandanaran No.58 em Semarang. Aentrada do PeeringDB da instalaçãoé mais restrita: SDCT Data Center, sala 214, segundo andar, Hotel Pandanaran, com 13 redes listadas, um exchange local, serviço de 400 VCA e nenhuma subestação diversificada divulgada. Osite do hotelconfirma a propriedade e o endereço do Hotel Pandanaran. Não é um campus remoto com uma concessionária pública e um plano de campus de data center publicado. É, com base nos documentos públicos, um nó de infraestrutura em escala de sala dentro de um prédio de hotel em operação.
Isso não torna o site irrelevante. Muitas instalações de Internet úteis começam como pequenas salas onde boas redes se encontram. Um exchange modesto pode ser mais importante para uma cidade do que um campus maior, porém distante, se oferecer aos operadores locais um local funcional para trocar tráfego. A questão não é a escala. A questão é a evidência.
Um cliente que compra uma unidade de rack em um exchange regional está adquirindo uma cadeia de dependências: alimentação do prédio, distribuição, armazenamento de energia, gerador, combustível, refrigeração, detecção de incêndio, supressão, controle de acesso, entrada de fibra, matriz de comutação, route-servers, acessibilidade upstream e resposta humana. O elo mais curto visível dessa cadeia é o espaço no rack. Os elos mais importantes geralmente estão fora do rack.
O teste central do artigo, portanto, não é se o Semarang Data Center pode se chamar de data center. O teste é se o registro público permite que um operador de rede distinga o serviço anunciado, o equipamento instalado, as sessões de troca ativas, os sistemas da instalação energizados, a capacidade operacional do exchange e a capacidade utilizável em caso de falha. Atualmente, esses estados são desiguais. A superfície do exchange é visível. A superfície dos sistemas do prédio geralmente não o é.
A identidade da empresa é mais clara do que os limites da instalação
A empresa em si não é difícil de identificar. Os registros da APNIC paraAS154034,165.101.31.0/24e2001:df5:c140::/48vinculam o sistema autônomo e os recursos de endereço à PT Semarang Data Center. A APNIC explica que os registros Whois identificam as organizações responsáveis pelos recursos de endereço e ASN; não são testes de carga, testes de energia ou medidores de tráfego. Eles estabelecem a responsabilidade pelos recursos numéricos, não a resistência de uma sala em um edifício.
As evidências de endereço separam as superfícies legal e física. O site da operadora fornece o endereço de contato da PT Semarang Data Center como Jalan Sumbawa II No.3, enquanto o endereço do data center é Hotel Pandanaran, segundo andar. A associação à APJII e os espelhos de diretórios de empresas também apontam para o contexto do escritório da Jalan Sumbawa. O PeeringDB e o site da operadora apontam para o Hotel Pandanaran para a instalação. Esses dois endereços não devem ser fundidos em um único ativo. O escritório ajuda a confirmar a identidade da empresa. O quarto de hotel é o local de infraestrutura que os leitores precisam entender.
Essa distinção é importante porque o controle é diferente em cada limite. A PT Semarang Data Center pode controlar a política de troca, a configuração do route-server, a comunicação com o cliente e o equipamento que possui ou gerencia. O proprietário do hotel ou o operador do prédio controla pelo menos alguns sistemas da propriedade. A PLN controla o fornecimento de eletricidade pública fora do prédio. Os provedores de fibra controlam suas rotas externas, dutos, postes, caixas de passagem e equipamentos de entrega. As autoridades locais controlam as condições de construção, incêndio, estradas e emergências ao redor do local.
Um exchange regional é tão resiliente quanto a dependência comum mais fraca entre esses proprietários.
O registro público ainda não mostra se a SDCT possui a sala 214, a aluga diretamente, usa serviços prediais gerenciados ou compartilha sistemas elétricos e de refrigeração com o hotel. Não mostra quem possui os painéis elétricos, os equipamentos de transferência, os sistemas UPS, a capacidade do gerador, a supressão de incêndio, a central de refrigeração, os dutos de fibra ou os pontos de acesso controlados. Também não mostra quem tem autoridade para entrar na sala durante um incidente no hotel ou uma emergência em toda a cidade. Não são questões burocráticas.
Elas determinam quem pode autorizar a manutenção, quem pode priorizar cargas durante um evento de gerador, quem pode reabastecer, quem pode isolar um sistema de incêndio, quem pode reabrir o acesso após uma evacuação e quem paga quando uma falha predial compartilhada interrompe o serviço de rede.
A melhor conclusão pública é, portanto, limitada. A PT Semarang Data Center é a empresa responsável pelo exchange nomeado e pelos recursos numéricos. O limite público da instalação é uma sala no segundo andar do Hotel Pandanaran. O limite de propriedade e operação entre a PT Semarang Data Center, o hotel, os fornecedores de serviços públicos e os provedores de rede permanece apenas parcialmente visível.
O PANDA-IX é a evidência operacional mais forte
A evidência mais forte atualmente está na LAN de peering. Apágina de exchange do PeeringDBlista o PANDA-IX em Semarang com 14 pares, 15 conexões, 13 pares abertos, 138 G de capacidade nominal total e uma instalação local, SDCT Data Center. Ela registra a LAN IPv4 como 165.101.31.0/24 e a LAN IPv6 como 2001:df5:c140::/48. As notas do exchange também apontam para a política de route-server BIRD, estatísticas públicas e um looking glass público.
As páginas ao vivo do route-server tornam essa lista mais do que uma simples entrada de catálogo estática. Em 13 de julho de 2026, olooking glass IPv4 do PANDA-IXidentificava "PANDA-IX RouteServer v4 (RS1 Semarang)" com o ID do roteador 165.101.31.1, 362 dias de disponibilidade e um carimbo de data/hora da última reconfiguração em 23 de janeiro de 2026. Ele mostrava um conjunto de vizinhos configurados, incluindo várias sessões BGP IPv4 estabelecidas com contagens de rotas recebidas e exportadas, e alguns vizinhos nos estados Active, Idle ou Connect. Essa diferença é importante. Um vizinho configurado não é a mesma coisa que uma sessão estabelecida, e uma sessão estabelecida não é a mesma coisa que um caminho de tráfego de alto volume.
Olooking glass IPv6mostrava a mesma identidade de route-server RS1 Semarang e disponibilidade, mas com uma superfície de entidades IPv6 ativas menor. Sessões IPv6 estabelecidas eram visíveis para um conjunto mais restrito de ASN do que para IPv4. Os registros de portas do PeeringDB também mostram endereços IPv6 em apenas uma minoria das 15 linhas de conexão. O IPv6 é, portanto, real no PANDA-IX, mas não se deve presumir que ele reflita a cobertura IPv4 em cada entidade.
Essa combinação sustenta uma reivindicação operacional precisa: o PANDA-IX é observável como uma estrutura de troca local funcional com uma operação de route-server ao vivo. Ela não sustenta uma reivindicação mais ampla de que cada par listado troca tráfego útil a todo momento, que cada caminho de cliente é resiliente ou que o exchange possui redundância no nível do site. O route-server pode estar íntegro enquanto uma sessão de cliente está inativa. Ele pode exportar rotas enquanto o backhaul está restrito. Ele pode funcionar por 362 dias enquanto as disposições de energia e refrigeração do prédio permanecem não divulgadas.
Essa distinção protege a empresa de um falso negativo e os leitores de um falso positivo. A ausência de anúncio global do AS154034 não apaga a evidência de troca local ao vivo. Ao mesmo tempo, sessões BGP ao vivo não comprovam uma instalação de data center resiliente. O PANDA-IX é um nó local operacional; seu comportamento completo em caso de falha permanece não comprovado no registro público.
O produto comercial é mais restrito do que uma etiqueta genérica de data center
A linguagem de produto público da operadora é excepcionalmente concreta. Apágina de colocationoferece pacotes de 1U, 2U e 4U, cada um limitado a equipamentos de rede, com instalação e interconexão inclusas. Não há oferta pública de rack completo, número de racks publicado, alocação de energia por unidade de rack, tarifa de eletricidade medida, carga de piso, tabela de nível de serviço remoto, cronograma de cross-connect, inventário de racks disponíveis ou carga de TI divulgada. A oferta se assemelha mais a uma sala de encontro ou sala de troca regional do que a um salão de dados empresarial genérico.
Essa interpretação mais restrita não é uma crítica. Um ISP regional pode precisar exatamente de um roteador em Semarang. Uma rede de conteúdo ou acesso pode querer uma porta pequena e uma sessão de route-server local em vez de um rack completo. Um exchange novo pode reduzir o limiar econômico para peering vendendo pequenas unidades. Se a instalação for bem-sucedida, ela pode tornar o tráfego de rede local menos dependente de hubs distantes.
O problema aparece quando a etiqueta de data center é permitida a carregar mais do que a evidência. Um leitor de data center pode esperar uma densidade de energia publicada, caminhos de serviços públicos independentes, sistemas mecânicos redundantes, documentação de zona de incêndio, histórico de nível de serviço e avaliações de terceiros. O registro público da SDCT ainda não fornece isso. O produto de sala de troca pode ser útil sem essas divulgações, mas a avaliação de riscos deve permanecer fiel ao produto realmente mostrado.
O PeeringDB reforça a leitura restrita. Oregistro da instalaçãolista 13 redes e um exchange, mas nenhuma operadora no campo de carrier. Ele fornece um endereço de hotel no nível do quarto, uma tensão de 400 VCA e nenhuma subestação diversificada divulgada. Não publica o número de racks, a área útil, a potência bruta, a potência disponível, a capacidade de refrigeração, a certificação do edifício ou os detalhes da sala de encontro neutra. O PeeringDB não é uma auditoria técnica, mas seus campos estruturados identificam o que é visível e o que não é.
Outros catálogos acrescentam pouco peso independente. A página de mercado do Semarang Data Center do Data Center Map foi usada como verificação de descoberta de mercado, mas as omissões do catálogo não podem provar que uma instalação não está operacional. Uma listagem derivada, como apágina da SDCT no PQ.Hosting, repete os detalhes de quarto, tensão, rede e exchange que parecem seguir os campos do estilo PeeringDB. São sinais de corroboração úteis para a mesma presença pública, não uma evidência independente de resiliência técnica.
A descrição pública apropriada é, portanto, compacta e restrita. O Semarang Data Center oferece publicamente uma pequena colocation de equipamentos de rede e opera um exchange local a partir do Hotel Pandanaran. Ainda não está publicamente comprovado como um grande salão de dados polivalente com capacidade de projeto, capacidade energizada, capacidade de refrigeração ou capacidade em modo de falha divulgadas.
A capacidade deve ser mantida em camadas
O erro mais comum na avaliação de um pequeno exchange é somar os números visíveis e chamar o resultado de capacidade. O PANDA-IX tem pelo menos quatro superfícies de capacidade diferentes, e apenas algumas são públicas.
A primeira é o tamanho unitário comercial. A SDCT vende pacotes de 1U, 2U e 4U. É uma unidade de espaço, não uma declaração de capacidade total da sala. Ela não divulga quantos racks existem, quantas unidades estão ocupadas, quantas permanecem disponíveis, quanta potência é atribuída a cada unidade, quanto calor a sala pode dissipar ou quantos clientes adicionais podem ser adicionados antes que a redundância seja perdida.
A segunda é a capacidade de porta nominal. Apágina de exchangedo PeeringDB e os dados da netixlan listam 15 conexões cujas velocidades declaradas totalizam 138 G. É uma capacidade de porta instalada ou listada na borda, não uma vazão garantida. Um total de porta não prova uma matriz de comutação não bloqueante, um uplink/backhaul suficiente, potência e refrigeração suficientes em plena carga ou capacidade de reserva suficiente após a falha do maior switch, componente de alimentação ou entrega de operadora. É um número de inventário útil, mas não um número de resiliência.
A terceira é a capacidade ao vivo do route-server. Os looking glasses IPv4 e IPv6 mostram processos de route-server ativos, estados de vizinhos e contagens de rotas. Isso é mais forte do que uma declaração de marketing, pois mostra uma operação lógica atual. Ainda assim, mede o estado do plano de controle BGP, não a vazão de dados de ponta a ponta do cliente. Uma sessão de route-server pode estar estabelecida enquanto os volumes de tráfego reais são baixos, assimétricos, restritos por um link downstream ou vulneráveis a um switch ou duto compartilhado.
A quarta é a capacidade da instalação. É a camada menos visível. O PeeringDB lista 400 VCA como serviço de tensão, mas tensão não é carga disponível. Os documentos públicos não identificam a potência de projeto, a saída dos UPS instalados, a autonomia da bateria, a potência do gerador, a reserva de combustível, a capacidade de refrigeração em toneladas, a carga térmica, as unidades de rack sobressalentes, os watts contratados ou o limite de expansão da instalação. Nenhuma fonte pública especifica se a SDCT pode manter a carga contratada total após uma falha da concessionária, falha de refrigeração, falha do gerador ou falha do switch.
A capacidade utilizável em caso de falha, portanto, não está estabelecida.
Essa estratificação é importante porque uma falha do cliente ocorre através das camadas. Uma rede pode ter uma porta de 10 Gbps que permanece administrativamente ativa, mas se a sala estiver termicamente limitada após a falha de uma unidade de refrigeração, a capacidade utilizável pode cair para uma fração desse número. Um cliente pode ter uma sessão de route-server ativa, mas se seu único caminho de fibra entrar por um duto compartilhado do hotel, a rota desaparece com um evento no prédio.
Uma instalação pode ter potência normal suficiente para operar cada roteador instalado, mas não potência de backup suficiente para manter a mesma carga online após uma falha da rede pública.
A linguagem correta é disciplinada. O PANDA-IX tem 138 G de capacidade de porta nominal listada. Ele tem uma operação BGP ao vivo visível. A SDCT oferece uma pequena colocation de equipamentos de rede. A capacidade da instalação nos níveis de projeto, instalada, energizada, ligada, operacional e utilizável em caso de falha não são a mesma coisa, e a maior parte da capacidade da instalação permanece não divulgada.
A eletricidade é a primeira dependência não resolvida
A eletricidade é a superfície faltante mais importante, pois todas as outras afirmações dependem dela. A operadora diz que seu espaço de colocation possui alimentação totalmente redundante. O PeeringDB lista 400 VCA e nenhuma subestação diversificada divulgada.
As fontes públicas não identificam o número de alimentações elétricas, as rotas de alimentação, a capacidade de serviço, o layout dos transformadores, os painéis de distribuição, os equipamentos de transferência automática, a topologia do UPS, a autonomia da bateria, a potência do gerador, o armazenamento de combustível, o plano de reabastecimento, o teste de banco de carga ou o teste integrado de perda da concessionária.
A diferença entre "ter uma alimentação de reserva" e "pode manter o serviço utilizável" é substancial. Um UPS pode suprir uma curta interrupção, mas não uma longa. Um gerador pode dar partida, mas não suportar tanto a carga de TI quanto de refrigeração. Um gerador pode atender ao hotel como um todo, com regras de prioridade e corte de carga que não são visíveis para os clientes do exchange. Um estoque de combustível pode durar algumas horas em carga parcial, mas menos em plena demanda de refrigeração. O retorno à rede pública pode falhar após a interrupção já ter sido superada.
Nenhum desses riscos é incomum; são dependências normais de data centers. Eles se tornam arriscados quando os clientes não conseguem ver o limite.
O contexto mais amplo da eletricidade indonésia não é suficiente. A PLN declarou em 2023 que atendia94 clientes de data centers com 727,1 MVAe previa crescimento nas conexões de data centers até 2027. Esse número nacional é útil para o contexto, mas não diz a um cliente de Semarang se a sala 214 tem duas alimentações, uma única, um gerador compartilhado, um gerador dedicado ou um caminho de transferência testado. A capacidade da rede, a distribuição local, o quadro elétrico do prédio e a continuidade no nível da sala são camadas diferentes.
As evidências da indústria mantêm a eletricidade perto do topo da lista de riscos. Aanálise de interrupções de 2025 da Uptime Intelligencecoloca novamente a eletricidade entre as principais causas de impacto sério em interrupções de data centers. Avisão geral dos Tiers da Uptimetambém mostra por que a linguagem de redundância precisa ser específica: componentes redundantes, caminhos de distribuição redundantes, capacidade de manutenção simultânea e tolerância a falhas não são intercambiáveis. Não há evidência pública de que a SDCT tenha certificação Tier do Uptime Institute, e o artigo não atribui nenhum nível. O ponto é mais restrito: uma afirmação de resiliência deve nomear o caminho de falha ao qual sobrevive.
Para a SDCT, uma divulgação útil seria modesta. Ela indicaria o número de concessionárias, se compartilham uma subestação ou rota, a configuração do UPS, a autonomia da bateria na carga atual e máxima contratada, a capacidade do gerador, a partida e disposição de transferência do gerador, a autonomia de combustível, o plano de reabastecimento e a data do último teste integrado. O teste deveria mostrar os route-servers, o switch de exchange, o monitoramento e a refrigeração permanecendo em operação durante a perda da rede pública, a aceitação do gerador e o retorno à rede.
Sem isso, "alimentação totalmente redundante" permanece uma afirmação, não um estado de capacidade demonstrado.
O resfriamento e o combate a incêndio são questões prediais
Uma sala de rede compacta pode superaquecer rapidamente. Roteadores, switches e equipamentos ópticos convertem energia elétrica em calor, e uma sala pequena tem menos massa térmica do que um grande salão. Uma falha de refrigeração pode começar silenciosamente: um compressor falha, um ventilador do condensador para, um controlador trava, um dreno entope ou uma unidade externa perde energia. Os pacotes podem continuar a circular enquanto a temperatura da sala aumenta. Quando as sessões caem, a janela de recuperação já pode ser curta.
A SDCT indica que sua instalação possui refrigeração, monitoramento de temperatura e umidade, controle de acesso rigoroso e supressão automática de incêndio. Esses são elementos importantes, mas o registro público não descreve seus limites técnicos. Não especifica o método de refrigeração, o número de unidades de refrigeração, a carga térmica, o status de N+1, os limites de alarme, as etapas de isolamento para manutenção, a fonte de energia para refrigeração, o agente de supressão, a integração do alarme de incêndio, o status das inspeções ou o plano de reinicialização após descarga.
O ambiente hoteleiro transforma essas questões em questões prediais. Uma sala de dados no segundo andar pode depender de condensadores, tubulações, drenos, painéis elétricos, dutos e corredores de acesso em outras partes do prédio. Duas unidades de refrigeração não são independentes se compartilharem um condensador, um disjuntor, um controlador ou um caminho externo. Um sistema de supressão de incêndio no nível da sala não resolve o que acontece se um alarme de incêndio em todo o hotel forçar uma evacuação, isolar a energia, abrir portas, restringir o acesso ou acionar os procedimentos dos bombeiros.
Uma sala de equipamentos seca sempre depende de sistemas prediais que podem estar fora do controle direto da operadora.
As normas pertinentes mostram a amplitude de uma divulgação completa da instalação. AANSI/TIA-942-Ccobre telecomunicações, energia, refrigeração, arquitetura, proteção contra incêndio, segurança, proteção e monitoramento para data centers e salas de informática. O catálogo de normas indonésio inclui aSNI 8799-1:2023para especificação técnica de data centers e aSNI 8799-2:2023para sistemas de gestão de data centers. O registro público da SDCT não reivindica certificação de acordo com essas normas. Elas são usadas aqui apenas para definir os tipos de sistemas que uma divulgação séria no nível da sala deveria cobrir.
O teste prático não é se a sala tem refrigeração ou supressão de incêndio em operação normal. É se o serviço permanece seguro e utilizável após a falha de um componente de refrigeração, após o prédio mudar o estado de energia, após um alarme de incêndio isolar o acesso ou após uma descarga de supressão. Um cliente não precisa de todos os desenhos proprietários. Ele precisa de informações suficientes para saber se seu roteador está protegido por sistemas independentes ou por serviços prediais compartilhados com regras de prioridade desconhecidas.
A diversidade de rede não é a mesma coisa que diversidade de fibra
A lista de entidades do PANDA-IX é valiosa. O PeeringDB lista 14 pares e 15 conexões. A API netfac retornou 13 registros rede-instalação no SDCT Data Center. O looking glass ao vivo mostra sessões de route-server estabelecidas com vários ASNs indonésios. Um exchange regional se torna útil justamente por essa concentração: as redes colocam roteadores no mesmo local para que o tráfego local permaneça local.
A concentração também cria um domínio de falha compartilhado. O PeeringDB não lista nenhuma operadora no campo de carrier da instalação. Isso não prova que não há entregas de operadoras, pois uma rede pode estar presente como membro, cliente ou par sem ser cadastrada como fornecedora de transporte. Significa que o registro público não revela a diversidade de acesso ao prédio. Vários ASNs podem compartilhar a mesma entrada de fibra, duto, conduto, posteação, caixa de passagem, travessia de estrada, extensão de provedor ou entrega upstream. No nível de pacote, são redes diferentes. No nível de engenharia civil, podem falhar juntas.
A política de roteamento da APNIC da operadora para o AS154034 faz referência ao AS24521, PT Data Utama Dinamika, como import, export e default. O AS24521 também está listado como entidade do PANDA-IX. Isso sustenta uma relação de roteamento, mas não mostra se o AS24521 fornece um caminho de trânsito independente, se a entrega está na mesma sala, se o caminho sai do prédio por uma rota separada ou se a rota hoje carrega um serviço da SDCT anunciado globalmente.
A boa evidência de roteamento tem três níveis. O primeiro é lógico: upstreams, pares, política de route-server, prefixos aceitos, política de exportação e preferências de failover. O PANDA-IX expõe parte disso por meio de seu looking glass público e suas notas de política. O segundo é óptico e no nível de serviço: qual provedor de fibra ou serviço Ethernet chega à sala, qual entrega existe, qual termo de restauração se aplica e onde fica o primeiro ponto de agregação upstream. O terceiro é físico: entradas do prédio, dutos, condutos, rotas de rua, pontes ou travessias e o ponto em que os caminhos se tornam realmente separados.
O registro público é forte no primeiro nível e fraco no segundo e terceiro.
Essa lacuna determina o modo de falha. Um corte de rota fora do hotel poderia interromper várias operadoras lógicas se compartilharem um conduto. Uma reforma no hotel poderia perturbar um duto. Um switch, painel de distribuição ou alimentação compartilhada poderia derrubar sessões que de outra forma seriam distintas. Um único evento de incêndio ou acesso poderia tirar a sala de serviço. Nenhum desses cenários prova que a instalação é frágil; eles mostram por que "vários ASNs" não é o mesmo que "vários caminhos físicos".
A ausência de rota global deve ser interpretada com cuidado
Os observadores de roteamento independentes mostram um fato marcante: o AS154034 atualmente não é visível como origem global. Apágina do AS154034 da Hurricane Electricnão mostrou nenhum prefixo global atual. AAPI de status de roteamento do RIPEstatreportou zero pares IPv4 e zero pares IPv6 no RIS vendo o AS154034 em 13 de julho de 2026, zero espaço IPv4 e IPv6 anunciado e zero vizinho observado. AAPI de prefixos anunciados do RIPEstatretornou uma lista de prefixos vazia para a janela de consulta de duas semanas encerrada em 13 de julho de 2026.
Para um ISP de acesso normal, isso seria um forte aviso de que a rede não tem superfície de serviço global visível. Para um ASN de route-server de exchange, isso exige um tratamento mais cuidadoso. O AS154034 é descrito noPeeringDBcomo "SDCT IX Route Server". A página de política PANDA-IX da operadora usa 165.101.31.0/24 e 2001:df5:c140::/48 como recursos da LAN do exchange. Uma LAN de exchange pode estar intencionalmente ausente do roteamento global enquanto as entidades trocam rotas localmente. Nesse contexto, a ausência global não significa uma falha local.
O looking glass ao vivo é, portanto, mais informativo para a operação local do que uma pontuação de origem global. Ele mostra o RS1 Semarang funcionando e trocando rotas com vizinhos locais. A ausência global ainda é importante, mas para uma pergunta diferente: qual é o projeto de serviço externo da SDCT? Se o AS154034 for apenas uma identidade de route-server, então a invisibilidade global deve ser esperada e declarada publicamente. Se a SDCT também pretende hospedar serviços de clientes, pontos de terminação de gestão ou prefixos anunciados via trânsito por meio de seu próprio ASN, então a ausência de anúncios globais precisa de explicação.
O impacto no cliente depende do produto testado. Uma entidade do PANDA-IX pode alcançar pares locais mesmo quando o AS154034 não tem origem global. Um equipamento hospedado que precisa de acesso externo pode depender do próprio ASN do cliente, de outro upstream ou do AS24521. Um sistema de monitoramento pode ser acessível por um caminho separado. Essas são superfícies de disponibilidade diferentes. Um único rótulo "ativo" ou "inativo" oculta a questão técnica.
O teste adequado é estratificado. Primeiro, as entidades conseguem alcançar os route-servers PANDA-IX em IPv4 e IPv6? Segundo, as sessões do route-server trocam os prefixos esperados? Terceiro, os caminhos de membro para membro transportam tráfego representativo sem desvios inesperados? Quarto, os serviços hospedados ou de gestão podem ser alcançados de fora de Semarang por mais de um caminho upstream ou de cliente? Quinto, o que permanece acessível quando toda a sala, não apenas uma sessão, fica indisponível? O registro público atual responde melhor às duas primeiras do que às três últimas.
O caminho de falha um começa com uma perda de energia elétrica
Uma queda de energia prolongada no centro de Semarang é o teste de instalação mais simples. O switch do exchange, o route-server, os roteadores dos clientes, o monitoramento e a refrigeração deveriam sobreviver ao evento inicial. Se o UPS e o gerador forem dedicados à SDCT, o teste está dentro da instalação da operadora. Se forem compartilhados com o hotel, o teste inclui a prioridade de carga do hotel, os comandos do gerador, o uso de combustível, a exaustão, o reabastecimento e a decisão sobre quais circuitos permanecem alimentados.
O primeiro intervalo vulnerável é muito curto. O UPS deve manter a tensão e a frequência dentro da tolerância do equipamento quando a energia elétrica desaparece. O segundo intervalo é de alguns segundos a minutos. Um gerador deve dar partida, sincronizar e aceitar tanto as cargas de TI quanto de refrigeração. O terceiro intervalo é de várias horas. O combustível, a ventilação, o estado de manutenção e a logística de reabastecimento determinam se o local sobrevive a um evento urbano mais longo.
O quarto intervalo é o retorno à rede pública, quando erros de transferência ou problemas de qualidade de energia podem interromper o equipamento depois que a falha parece ter terminado.
Para uma entidade do PANDA-IX, o resultado não é uniforme. Uma rede com outro local em Semarang ou um caminho upstream robusto pode redirecionar e pagar principalmente em latência ou custo de trânsito. Um provedor menor cujo único roteador de exchange local esteja na sala 214 pode perder totalmente o peering local. Um cache de conteúdo ou serviço corporativo por trás de uma dessas redes pode permanecer acessível da Internet mais ampla, mas tornar-se mais lento para os usuários regionais. Um equipamento de cliente hospedado apenas na SDCT pode desaparecer se a energia ou refrigeração não puderem ser mantidas.
A boa evidência seria um teste integrado de perda da rede pública com carga representativa. Deveria registrar a hora da perda da rede, a transferência do UPS, a aceitação do gerador, a continuidade da refrigeração, a estabilidade do route-server, o estado do switch, o estado da porta do cliente, a alcançabilidade do monitoramento e o retorno à rede. Deveria declarar qual carga foi testada e quanta margem de reserva restou. Sem isso, uma reivindicação de redundância não pode ser convertida em capacidade utilizável energizada.
O caminho de falha dois começa com uma perda de refrigeração
A falha de refrigeração é mais sutil do que a queda de energia, pois a rede pode continuar a transferir pacotes enquanto a sala se torna perigosa. Se um componente de refrigeração parar, o sistema restante deve dissipar o calor dos roteadores, switches, ópticos e equipamentos de conversão de energia. Se o sistema restante não conseguir manter a temperatura, os operadores podem precisar reduzir a carga, desligar dispositivos não críticos, abrir portas, implantar refrigeração temporária ou aceitar um desligamento térmico.
Instalações em escala de sala podem ser reativas, pois a equipe e os clientes podem conhecer os equipamentos e o layout exato. Também podem ser frágeis, pois pode haver menos componentes redundantes e menos separação entre os sistemas. Os documentos públicos não mostram qual caso se aplica à SDCT. A operadora reivindica monitoramento e refrigeração, mas não há valor de carga térmica pública, topologia de refrigeração, capacidade em modo de falha, método de manutenção ou procedimento de escalonamento de alarme.
O ambiente hoteleiro adiciona uma dependência de acesso. Uma unidade de refrigeração pode ser acessível apenas pelas áreas de serviço do prédio. Os condensadores externos podem estar em um telhado, fachada ou pátio de serviço. Os drenos podem passar por espaços do hotel. Um alarme predial ou um evento de segurança pública pode impedir o acesso imediato para reparo. Uma sala no segundo andar protege o equipamento de algumas exposições à água no nível do solo, mas não protege a alimentação do condensador, as tubulações externas, os quadros elétricos, a casa do gerador ou as câmaras de fibra, se estiverem em outro lugar.
A questão operacional não é se a SDCT pode manter a sala fria em um dia comum. É por quanto tempo o exchange permanece utilizável após a falha do maior componente de refrigeração na carga contratada mais alta, e se os clientes recebem aviso suficiente para mover o tráfego antes de uma parada brusca. Um resultado público útil mostraria os limites de alarme, os limites de tempo-temperatura, a capacidade de refrigeração restante, o isolamento para manutenção e o cronograma de notificação ao cliente. Até lá, a refrigeração é um sistema de suporte afirmado, em vez de um caminho de falha verificado.
O caminho de falha três é a própria sala de encontro
O PANDA-IX cria valor ao colocar várias redes no mesmo local. O mesmo projeto faz da sala de encontro um ponto de falha comum. Um defeito no switch, um erro no painel de distribuição, um problema de software, uma reinicialização do route-server, uma configuração incorreta, um corte no duto de fibra, um evento de energia no prédio ou uma restrição de acesso pode afetar muitas entidades de uma só vez.
Algumas falhas são lógicas. Um problema de software no route-server pode interromper o peering multilateral enquanto as sessões bilaterais continuam. Um erro de filtro de rota pode impedir a exportação de certos prefixos enquanto a porta permanece ativa. Um cliente pode estar estabelecido, mas receber zero rotas. Essas falhas são visíveis na telemetria do route-server e muitas vezes podem ser corrigidas por configuração.
Outras falhas são físicas. Um switch perde energia. Um painel de cross-connect compartilhado é perturbado. Um único duto falha. Um cabo de conexão é deslocado. Um evento de refrigeração compartilhada na sala exige o desligamento do equipamento. Essas falhas não são resolvidas tendo vários ASNs no mesmo local. Elas são resolvidas por comutação independente, alimentação independente, gerenciamento claro dos cabos, separação física, caminhos de substituição fora do local ou projetos de cliente que não exijam que a sala esteja disponível para todo o tráfego.
O registro público do PANDA-IX mostra o RS1 Semarang. Ele não prova um segundo route-server independente, um caminho de switch independente ou um segundo local de exchange. O PeeringDB lista uma única instalação local para o PANDA-IX. Um segundo switch no mesmo rack reduziria alguns riscos de componente, mas não um risco de sala ou prédio. Um segundo local de exchange em um caminho de rede elétrica e fibra diferente abordaria mais riscos no nível do site, mas não há evidência pública de tal local.
Isso é aceitável se o serviço for tarifado e descrito como um exchange de local único. Muitos IXPs jovens começam assim. O risco aparece quando o serviço de local único é interpretado como resiliência regional. O conselho de projeto honesto é simples: o PANDA-IX pode melhorar a economia do tráfego local, mas os membros que precisam de continuidade devem manter trânsito externo e, se possível, caminhos de peering ou hospedagem alternativos fora da sala 214.
O caminho de falha quatro é a superfície de risco mais ampla de Semarang
O cenário físico de Semarang não é apenas um pano de fundo. Oconjunto de dados de risco de inundação de Semarang do Banco Mundialidentifica a exposição da cidade a inundações de maré relacionadas à subsidência e a inundações locais ou fluviais após fortes tempestades. Umaavaliação de projeto do Banco Mundialdescreve os riscos de inundação costeira, fluvial e pluvial, as restrições de drenagem, os rios e o contexto de subsidência do solo. A agência de gestão de desastres de Semarang publicou ummapa de risco de inundação de 2025, e a cidade emitiu umdecreto de alerta de emergênciapara inundações, deslizamentos de terra e condições meteorológicas extremas em janeiro de 2025.
Essas fontes devem ser usadas com cautela. Elas não provam que o Hotel Pandanaran está em uma faixa de risco de inundação específica e não provam que a SDCT sofreu danos por inundação. Uma avaliação no nível da parcela exigiria a altitude do local, a drenagem, a localização dos equipamentos, os níveis históricos de água, as localizações das salas técnicas e o acesso à rua. O artigo público não deve implicar mais do que os mapas sustentam.
O risco ainda importa, pois uma sala no segundo andar depende dos sistemas abaixo e ao seu redor. Os racks podem estar acima de uma água rasa, enquanto a entrada do prédio, o equipamento do subsolo, os quadros elétricos externos, o gerador, a entrega de combustível, o conduto da rua, a câmara de fibra ou o caminho de acesso do técnico não estão. As inundações também podem causar queda de energia, restrição de acesso, perturbação do tráfego e atraso no reparo, mesmo que a sala permaneça seca. Um exchange local não precisa estar submerso para ficar indisponível.
O incêndio é semelhante. Um sistema de supressão no nível da sala pode proteger o equipamento dentro da sala 214, mas um incêndio em outro lugar do hotel poderia desencadear uma evacuação, corte de energia, propagação de fumaça, ação da água, acesso restrito ou atrasos na inspeção. Os clientes devem saber quem pode entrar, quem pode reiniciar o equipamento, como a exposição à fumaça ou à supressão é avaliada e como o tráfego é movido enquanto o prédio estiver indisponível.
A reivindicação de resiliência correta não é que Semarang seja arriscado demais para infraestrutura. A infraestrutura regional deve ser construída onde estão os usuários regionais. A reivindicação é que as evidências de risco devem levar a operadora a divulgações claras de posicionamento e recuperação: altitude do equipamento, entrada de fibra protegida, localização das salas elétricas, posicionamento do gerador, detecção de água, classificação de resistência ao fogo, procedimentos de acesso e opções de recuperação fora do local.
As pessoas afetadas não são apenas os pares listados
Os clientes visíveis do PANDA-IX são redes. Seus usuários afetados são mais amplos. Quando um exchange local falha, a perda imediata pode ser uma sessão BGP entre operadoras, mas o efeito sentido pode ser páginas mais lentas, caminhos de voz mais longos, jitter de jogos, maior custo de trânsito, entrega de conteúdo instável ou um serviço corporativo que toma uma rota mais longa. Os usuários finais não precisam saber da existência do exchange para sentir sua ausência.
O impacto varia conforme o projeto do membro. Uma rede maior com vários provedores de trânsito e outro local de interconexão pode manter o serviço em operação, embora possa deslocar o tráfego para um caminho mais longo ou caro. Um ISP menor com um único roteador na SDCT pode perder uma entrega local e depender de um único upstream. Um cliente que hospeda equipamento na sala pode perder a conectividade se seu próprio dispositivo perder energia, refrigeração, estado da porta ou caminho upstream. Uma implantação de conteúdo ou cache pode continuar a atender algumas redes, mas não outras.
É por isso que a disponibilidade deve ser medida por tráfego representativo, não apenas por um processo de route-server. Um route-server pode estar ativo enquanto alguns membros não recebem nenhum prefixo. Um switch pode estar ativo enquanto um caminho upstream congestionado altera a experiência do usuário. Uma sala pode estar energizada enquanto os limites de refrigeração forçam o desvio de tráfego. Inversamente, uma reinicialização do route-server pode ter pouco efeito para o usuário se os membros mantiverem sessões bilaterais.
A SDCT poderia tornar esse impacto legível publicando resultados de exercícios agregados. Os membros poderiam testar a reinicialização do route-server, a manutenção do switch, a perda de porta, uma falha de upstream, a transferência por perda da rede pública, o alarme de refrigeração e a indisponibilidade total da sala. Os resultados poderiam mostrar o tempo de convergência, a perda de pacotes, a mudança de latência e a capacidade restante utilizável sem nomear o tráfego do cliente. Esses testes transformariam um pequeno exchange regional de uma promessa em uma dependência medida.
O que as evidências atuais comprovam
As evidências atuais comprovam várias coisas importantes. A PT Semarang Data Center é a empresa vinculada à identidade SDCT e AS154034. A empresa oferece publicamente pequenos pacotes de colocation para equipamentos de rede em Semarang. O endereço do data center é Hotel Pandanaran, segundo andar, e o PeeringDB reduz a instalação à sala 214. O PANDA-IX está listado como um exchange de Semarang nessa instalação. Ele tem 14 pares, 15 conexões listadas e 138 G de capacidade de porta nominal no PeeringDB. Seu looking glass público mostra uma operação ao vivo do RS1 Semarang, incluindo sessões BGP IPv4 e IPv6.
As evidências também comprovam o que não deveria ser reivindicado. O registro público não mostra que a SDCT possui os sistemas prediais que sustentam a sala 214. Não mostra alimentações elétricas duplas, subestações diversificadas, caminhos de alimentação independentes, capacidade de UPS, autonomia do gerador, reserva de combustível, redundância de refrigeração, integração de incêndio, diversidade de entrada de operadoras, múltiplos route-servers em infraestrutura independente, um segundo local de exchange, volume de tráfego ao vivo, histórico de failover de clientes ou capacidade utilizável após uma falha.
A ausência dessas divulgações não é prova de que os sistemas não existem. É a prova de que uma avaliação pública de resiliência não pode se basear nelas.
A evidência de rota global também é limitada. O RIPEstat e a Hurricane Electric não mostram nenhum anúncio global atual para o AS154034. Isso deve ser registrado, pois importa para a acessibilidade externa. Não deve ser interpretado como prova de que o PANDA-IX está fora do ar, pois a superfície do route-server é visível localmente. A questão não resolvida é o que se espera que o AS154034 faça fora da LAN do exchange.
Cinco fatos mudariam rapidamente a avaliação. Primeiro, um mapa de responsabilidade física mostrando o que a SDCT controla e o que o hotel controla. Segundo, uma topologia elétrica e de refrigeração simplificada com capacidade em modo de falha testada. Terceiro, um mapa das operadoras e entradas de fibra identificando onde os caminhos se tornam fisicamente separados. Quarto, uma tabela de capacidade separando as unidades de rack, os watts contratados, as velocidades de porta instaladas, o tráfego medido e a margem em modo de falha.
Quinto, exercícios de failover datados cobrindo a perda da rede pública, perda de refrigeração, reinicialização do route-server, falha do switch, falha de entrada de fibra e indisponibilidade total da sala.
Até lá, o Semarang Data Center deve ser tratado como um operador de exchange local confiável, com um caso de resiliência de instalação não resolvido. É um julgamento mais restrito do que um perfil promocional de data center, e mais justo do que rejeitar o exchange porque seu ASN de route-server não é globalmente visível. A empresa tornou o nó local observável. O próximo passo é tornar as dependências ao redor do nó igualmente observáveis.
Um exchange regional ganha confiança ao mostrar suas restrições
A contribuição mais forte do Semarang Data Center é local. Ele dá às redes de Java Central um local visível para se encontrarem, e a evidência ao vivo do route-server mostra que o exchange não é apenas uma ideia anunciada. Para um mercado regional, isso importa. Um pequeno número de portas locais pode mudar a forma como o tráfego se move, especialmente quando a alternativa é uma longa viagem até um hub maior.
Sua superfície pública mais fraca também é local. O exchange fica em uma sala dentro de um hotel, e os sistemas ao redor dessa sala não são totalmente divulgados. A energia, refrigeração, controle de incêndio, acesso e rotas de fibra são a infraestrutura sob as sessões BGP. Se falharem juntos, a diversidade lógica do exchange desaparece. Se forem independentes e testados, o local pode ganhar mais confiança do que sua pequena presença sugere.
A empresa não precisa fingir que a sala 214 é um campus hyperscale. Ela precisa definir o que a sala é, o que não é, qual capacidade está realmente instalada, qual capacidade está realmente ligada, qual capacidade está realmente energizada, qual capacidade está disponível para venda e qual capacidade permanece utilizável após uma falha plausível. Essa linguagem é mais valiosa do que uma série de títulos chamativos. Ela permite que os clientes decidam quais riscos podem aceitar e contra quais devem se proteger.
A conclusão atual é, portanto, deliberadamente contida. O PANDA-IX é uma superfície de troca local funcional com evidências públicas atuais de route-server. O Semarang Data Center é a empresa e a identidade da instalação por trás dessa superfície. A reivindicação mais ampla de resiliência de data center permanece uma questão técnica até que a operadora mostre os caminhos físicos de energia, refrigeração, acesso e backhaul que mantêm a sala viva quando as condições normais desaparecem.

