PT. INDONESIA SUPER CORRIDOR - centros de datos tiene que demostrar si la capacidad de centro de datos comercializada puede sobrevivir a las restricciones de energía y operadores

Resumen

• PT. INDONESIA SUPER CORRIDOR - centros de datos tiene señales públicas inusualmente concretas para este lote: elsitio de ISCcomercializa un centro de datos Tier IV ISC MPR de 550 racks en Mampang Prapatan, lapágina "Acerca de" de ISCdice que la empresa construyó capacidad de red y centro de datos en Cyber 1, y lapágina de cliente de Uptime Instituteenumera premios emitidos para ISC centros de datos DPR, ISC centros de datos Cyber-1 Building CBR Level 9 y centros de datos ISC MPR.
• La huella de enrutamiento es real pero estrecha.APNIC RDAPnombra a AS142379 como ISC-DC-AS-ID para PT. INDONESIA SUPER CORRIDOR - centros de datos, yRIPEstatmostró seis anuncios IPv4 /24 actuales con visibilidad IPv4 completa de RIS el 12 de julio de 2026, pero sin visibilidad IPv6 actual y solo un vecino AS observado.
• La principal brecha de diligencia no es si existe un negocio de centro de datos con la marca ISC. Es si las ofertas anunciadas de rack, nube y recuperación ante desastres tienen suficientes suministros de servicios públicos revelados, tiempo de funcionamiento del generador, redundancia de refrigeración, diversidad de puntos de encuentro, pruebas de conmutación por error del cliente y procedimientos de salida para soportar cargas de trabajo de producción cuando las condiciones de energía, operador o instalación se vuelven incómodas.

ISC es un caso más sólido que un marcador de posición de directorio

Algunos perfiles de infraestructura comienzan con una escueta entrada de registro y nunca avanzan mucho más. PT. INDONESIA SUPER CORRIDOR - centros de datos es diferente. La empresa es visible en eldirectorio BTW, en sus propias páginas de servicio público, en la base de datos de premios de Uptime Institute, en los registros de PeeringDB relacionados con su intercambio y organización, y en observaciones de enrutamiento en vivo. Eso no completa el caso operativo, pero cambia la pregunta. No se trata de buscar un edificio que podría no existir. Es una prueba de cuánta confianza se debe depositar en una plataforma de centro de datos comercializada cuyo historial público es más sólido en instalaciones y empaquetado de productos que en la recuperación medida del cliente.

Lapágina principal de ISCcomienza con una afirmación específica: "550 racks disponibles en el centro de datos Tier IV ISC MPR (5MW), Mampang Prapatan Raya, Yakarta, Indonesia". También anuncia 100 Mbps IIX y 10 Mbps IX, alimentación de 10A, una asignación de IP pública /29 y dos UTP más dos conexiones cruzadas de fibra para la oferta de rack completo. La misma página dice que la instalación es segura, está atendida las 24 horas, protegida por detección de movimiento CCTV y accesible mediante controles de PIN y tarjeta. Esos no son adjetivos vagos de la nube. Son afirmaciones sobre rack, potencia, conexiones cruzadas y acceso físico.

Lapágina "Acerca de"añade el contexto más antiguo de Cyber 1. ISC dice que comenzó construyendo su propia red y centro de datos en Cyber 1, Yakarta, y describe la propuesta original como una red gestionada confiable y multi-homed dentro de una instalación con alto tiempo de actividad. También dice que la empresa mantiene responsabilidades PCI DSS cuando almacena, procesa o transmite datos de titulares de tarjetas para los clientes. La misma página dice que ISC está ubicada en el centro del entorno de intercambio de Internet de Indonesia, afirma tener resiliencia de energía de fuente dual a través de un panel de distribución separado, y posiciona sus servicios en torno a la calidad de instalación de Nivel III. De nuevo, esta es una historia de infraestructura física: ubicación, distribución de energía, alcance de red y obligaciones de cumplimiento.

Uptime Institute da forma independiente a esa historia, aunque no un veredicto operativo completo. Supágina de cliente para PT Indonesia Super Corridorenumera tres sitios con premios emitidos: ISC centros de datos DPR en Denpasar, ISC centros de datos Cyber-1 Building CBR Level 9 en Yakarta, y centros de datos ISC MPR en Yakarta. Lalista de premios de Uptime por país para Indonesiacoloca a ISC junto a otras instalaciones indonesias certificadas. Un comprador aún debe leer cuidadosamente el tipo y alcance del premio, porque elpropio material de certificación de niveles de Uptimedistingue las certificaciones de diseño, instalación construida y operaciones. Pero la base de datos de premios sí respalda la premisa de que ISC tiene instalaciones que vale la pena evaluar, no simplemente una página de marca.

Esto hace que la cautela sobre el estado operativo de este análisis sea más útil, no menos. Cuando la evidencia pública es escasa, la respuesta a menudo es "no confíe en ello". Cuando la evidencia pública es concreta pero desigual, la mejor respuesta es "separe lo que existe de lo que puede sobrevivir". El registro público de ISC respalda la existencia de las instalaciones, el marketing de servicios, un rol de red orientado al intercambio y el enrutamiento IPv4 activo.

No prueba públicamente cada detalle crítico para el cliente detrás de la capacidad comercializada: racks realmente ocupados, energía reservada, contratos de combustible para generadores, diversas rutas de entrada de operadores, pruebas de conmutación por error de refrigeración, manejo histórico de incidentes, independencia de respaldo, o la diferencia entre la capacidad de nube vendida por ISC y los equipos del cliente simplemente alojados en el espacio de ISC.

El mapa de activos tiene tres instalaciones con nombre, no un cuarto de datos genérico

La propia navegación de ISC divide la historia del centro de datos en las páginas de CBR, MPR y recuperación ante desastres de Bali. Lapágina del Centro de Datos Tier III CBRcomercializa colocation por U, ofertas de medio rack y rack completo con una cifra de nivel de servicio del 99,982%, ancho de banda IIX e IX, asignación de IP, derechos de acceso, monitoreo de tráfico, soporte de manos inteligentes y cuentas DCIM. El paquete de rack completo en esa página anuncia 100 Mbps IIX, 10 Mbps IX, un rango de IP pública /29, cinco accesos de usuarios al centro de datos, dos puertos de conexión cruzada UTP y dos núcleos de fibra. Esta es la parte heredada orientada a Cyber 1 de la historia de ISC.

Lapágina del Centro de Datos Tier IV MPRlleva el argumento de mayor disponibilidad. Anuncia una cifra de nivel de servicio del 99,995% para paquetes de colocation por U, medio rack y rack completo, repite el lenguaje de IIX/IX y caché de contenido, y añade ofertas de nube empresarial y nube para empresas. Esos paquetes de nube afirman conectividad de 1 Gbps IIX, OIXP y Equinix IX, hasta 4 GB o 32 GB de memoria, hasta 80 GB o 640 GB de almacenamiento, una IP pública, un sistema operativo Linux, un puerto de 1 Gbps y hasta 30 Mbps de ancho de banda internacional. Ese paquete es importante porque convierte a ISC de una empresa solo de colocation en un proveedor de infraestructura alojada cuyos clientes pueden depender de la computación, red y almacenamiento operados por ISC, no solo de su propio equipo.

Lapágina DRC Tier III Balida el ángulo de recuperación. Enmarca la instalación de Denpasar como un centro de recuperación ante desastres, anuncia conceptos de RPO y RTO, describe conexiones de gigabit a múltiples intercambios, diseño de fibra óptica interconectada, energía resiliente de dos fuentes de voltaje diferentes y capacidad total de generador de respaldo, FM200 y detección de humo arriba y abajo del suelo elevado, CCTV 24/7, acceso con tarjeta y huella dactilar, y aire acondicionado de precisión con un sistema redundante. Estas son afirmaciones útiles porque identifican las rutas de falla que la empresa sabe que los clientes preguntarán: falla de infraestructura primaria, interrupción de fibra, interrupción de energía, incendio y refrigeración.

Los directorios de instalaciones de terceros respaldan la existencia de múltiples sitios de ISC, al mismo tiempo que introducen ruido de capacidad que los compradores no deben ignorar. Lapágina de empresa de ISC en Baxteldescribe a ISC como operando dos centros de datos en una región y enumera 6 MW, mientras que supágina de ISC Towerdescribe el sitio MPR como un centro de datos Tier IV en el sur de Yakarta con 550 racks y afirma tener verdadera resiliencia de doble ruta 2N UPS, generadores diésel y soporte IPv4/IPv6.Datacenters.comenumera tres ubicaciones en Indonesia para ISC, y supágina de MPRreporta 6.500 pies cuadrados, 1.791 pies cuadrados de suelo elevado y 16,0 MW de potencia. Esas cifras no coinciden exactamente con el titular de 5 MW del propio ISC o la señal de mercado estilo LinkedIn que describe hasta 8 MW de carga de TI. La inconsistencia no es prueba de declaración falsa; los directorios de terceros pueden estar desactualizados, estimar o mezclar la potencia del edificio con la carga de TI. Sin embargo, es exactamente por lo que los clientes deben solicitar un cronograma de capacidad fechado.

La conclusión útil es que ISC no debe reducirse a un solo activo. CBR, MPR y Bali DRC aparecen como partes distintas de la historia pública. El riesgo es que las páginas públicas difuminen sus límites operativos. ¿Qué racks están en Cyber 1? ¿Qué paquetes de nube se entregan desde MPR? ¿Qué cargas de trabajo realmente pueden conmutar por error a Bali? ¿Están disponibles las conexiones de intercambio anunciadas en cada sala o solo a través de la red más amplia de ISC?

Si un cliente compra un servicio "Tier IV", ¿cada dependencia en la ruta del servicio está dentro de ese alcance Tier IV, o los portales de gestión, sistemas de soporte, circuitos ascendentes, facturación y repositorios de respaldo se encuentran en otras salas? Estas preguntas definen la resiliencia utilizable.

La capacidad comercializada necesita un factor de conversión

El titular "550 racks disponibles" es poderoso porque da una escala tangible. Un comprador puede imaginar jaulas, armarios, conexiones cruzadas, cables de alimentación y despliegues de clientes. Pero la capacidad del centro de datos nunca es solo el número de racks. La capacidad útil es la cantidad de espacio, energía, refrigeración y traspaso de red que se puede vender sin que la sobreventa se convierta en riesgo de interrupción.

La propia página de MPR de ISC ayuda a ilustrar el problema de conversión. Una oferta de rack completo incluye una fuente de alimentación de 10A, una asignación de IP pública /29, monitoreo de tráfico, servicio de manos inteligentes, dos puertos UTP y dos núcleos de fibra. Eso es un paquete práctico para colocation empresarial, pero no equivale a una declaración de que cada uno de los 550 racks puede consumir 10A continuamente, que todos los racks tienen la misma densidad de potencia, o que existe suficiente refrigeración y ancho de banda ascendente para que cada rack funcione con cargas modernas de IA o almacenamiento denso.

Un rack empresarial tradicional con densidad modesta es muy diferente de un rack de GPU o almacenamiento de alto rendimiento. Las páginas públicas de ISC no publican límites de densidad, PUE, temperaturas de diseño de refrigeración, límites de uso de energía, políticas de interruptores o carga de TI vendible real por fase.

La misma precaución se aplica a los paquetes de nube. Las páginas de MPR y CBR anuncian "Cloud Business" y "Cloud Enterprise" con cifras de nivel de servicio del 99,9%, límites de memoria y almacenamiento, una IP pública, un sistema operativo Linux, lenguaje de puerto de 1 Gbps y hasta 30 Mbps de ancho de banda internacional. Esos términos suenan más pequeños que las ofertas de rack y pueden estar dirigidos a cargas de trabajo empresariales ordinarias en lugar de computación a gran escala.

Una VM en la nube se puede aprovisionar desde una instalación resiliente, pero la resiliencia del cliente depende de la agrupación de hosts, replicación de almacenamiento, ubicación de respaldos, capacidad de migración en vivo, exportación de instantáneas, política de mantenimiento y ruta de red. Las páginas públicas de productos muestran el empaquetado del servicio; no muestran la arquitectura debajo de las máquinas virtuales.

En el mercado actual de centros de datos, la energía es el factor de conversión más importante. Elinforme Energy and AI de la IEAproyecta que el consumo de electricidad de los centros de datos crecerá mucho más rápido que la demanda general de electricidad hasta 2030. La presión es global, pero aterriza localmente: cada edificio necesita una conexión de servicios públicos, aparamenta, capacidad de UPS, capacidad de refrigeración, soporte de generador, logística de combustible y permiso para expandirse. El titular de 5 MW de MPR de ISC es significativo en ese contexto, pero no es suficiente. Los clientes necesitan saber si ese número es la capacidad de los servicios públicos, la capacidad del edificio, la carga de TI, la capacidad de diseño futura o la capacidad comprometida actualmente vendible después de restar los clientes existentes, los márgenes de redundancia y el margen de mantenimiento.

ISC podría eliminar gran parte de la ambigüedad con una divulgación aburrida: capacidad total de alimentación de servicios públicos, carga de TI comprometida, carga vendible disponible, densidad de rack promedio y máxima, topología de UPS, tiempo de funcionamiento del generador, contratos de reabastecimiento de combustible, diseño de derivación de mantenimiento, redundancia de refrigeración y las suposiciones detrás de la cifra del 99,995% de MPR. Las páginas públicas anuncian energía de doble fuente y generadores de respaldo en varios lugares. Eso es un punto de partida.

No es lo mismo que un modelo de capacidad listo para el cliente que muestre lo que sucede cuando una fuente de servicios públicos, un módulo de UPS, una unidad de refrigeración o una ruta de entrega de combustible no están disponibles.

Es por esto que la tesis operativa debe actualizarse de "huella pública escasa" solo para la existencia, no para la resiliencia. ISC tiene una huella visible. La rebaja se sitúa en el punto donde la capacidad comercializada tiene que convertirse en capacidad auditada. Si un comprador está colocando equipos de colocation ordinarios con un consumo de energía modesto, la evidencia pública puede ser suficiente para justificar una visita al sitio y una solicitud de propuesta.

Si el comprador está colocando sistemas financieros sensibles a la latencia, cargas de trabajo del sector público, infraestructura de recuperación ante desastres o computación de alta densidad, la evidencia pública no es suficiente. Esos clientes necesitan una carta de capacidad, documentos de topología, evidencia de conmutación por error y lenguaje contractual que vincule los niveles de servicio a la sala, rack y rutas de red exactos que utilizarán.

La evidencia de red está activa, pero no es amplia

AS142379 es el ancla de enrutamiento para la entidad del directorio.APNIC RDAP para AS142379nombra al sistema autónomo "ISC-DC-AS-ID" y da el contexto del titular como PT. INDONESIA SUPER CORRIDOR - centros de datos en Indonesia. Sus datos de contacto administrativo y técnico apuntan a una dirección de correo electrónico de ISC, mientras que los datos de contacto de abuso utilizan la dirección de hostmaster de ISC en una ubicación de Cyber Building. Esa es una fuerte evidencia de identidad de registro.

El panorama de recursos IP muestra un límite de grupo CNI.APNIC RDAP para 103.91.24.0enumera el bloque 103.91.24.0 - 103.91.27.255 como CNI-ID, espacio de direcciones portátil asignado para PT Cyber Network Indonesia, un proveedor de servicios de Internet en Yakarta.APNIC RDAP para 123.253.248.0enumera de manera similar 123.253.248.0 - 123.253.251.255 como CNI-ID. Eso no debilita el caso operativo de ISC, porque los registros públicos y de terceros de ISC la sitúan repetidamente dentro de un contexto del Grupo CNI. Significa que los clientes deben entender qué entidad legal y operativa controla el espacio de direcciones, la instalación, el intercambio y el contrato con el cliente.

Ladescripción general de AS de RIPEstatreportó AS142379 como anunciado el 12 de julio de 2026 y nombró al titular como ISC-DC-AS-ID - PT. INDONESIA SUPER CORRIDOR - centros de datos. Elendpoint de prefijos anunciados de RIPEstatmostró seis /24 IPv4 actuales: 103.91.24.0/24, 103.91.25.0/24, 103.91.26.0/24, 103.91.27.0/24, 123.253.248.0/24 y 123.253.249.0/24. Losdatos de estado de enrutamiento de RIPEstatmostraron a los 325 pares IPv4 de RIS viendo el conjunto de rutas en el momento de la consulta, 1.536 direcciones IPv4 anunciadas y sin anuncios IPv6 actuales visibles para RIS.

Esa es una buena evidencia de accesibilidad, pero no es una historia completa de diversidad. Losdatos de vecinos ASN de RIPEstatmostraron un vecino observado: AS38496.APNIC RDAP para AS38496identifica ese AS como CNI-AS-ID para PT Cyber Network Indonesia. Esto parece una relación interna o de upstream/agregación adyacente al grupo en lugar de evidencia de que AS142379 tiene múltiples upstreams externos independientes visibles en el BGP global. Si un cliente de la instalación necesita diversidad de operadores, la pregunta no es "¿encamina ISC las direcciones?" La pregunta es "¿cuántas rutas de entrada físicas, conexiones cruzadas de operadores y políticas de upstream puede usar realmente mi servicio?".

La seguridad de enrutamiento es un punto más brillante. Lavalidación RPKI para 103.91.24.0/24de RIPEstat y lavalidación RPKI para 123.253.248.0/24devolvieron un estado válido para AS142379 en el momento de la consulta. La validez RPKI no evita interrupciones y no prueba la diversidad de la instalación, pero es una señal real de higiene de enrutamiento. Reduce una clase de riesgo de declaración errónea de origen y muestra que el entorno de direcciones CNI/ISC no es una superficie de enrutamiento completamente descuidada.

IPv6 es la señal más débil. Baxtel describe la ISC Tower como totalmente IPv4 y compatible con IPv6, e ISCX comercializa peering IPv4 e IPv6. Pero la vista actual de AS142379 de RIPEstat no mostró prefijos IPv6 visibles en el momento de la consulta. Eso puede significar que IPv6 se proporciona a través de otros ASN, a través de LAN de intercambio, a través de redes de clientes o que actualmente no es originado por AS142379. Para los compradores, el punto práctico es simple: no asuma un servicio de doble pila por la redacción de marketing.

Pregunte qué ASN origina el IPv6 del cliente, si los paquetes de nube incluyen IPv6, si RPKI lo cubre y si las rutas IPv6 tienen el mismo monitoreo y soporte que IPv4.

ISCX es estratégicamente útil, pero no prueba todas las rutas del cliente

La historia de intercambio de ISC es un activo real. Elsitio ISCXdescribe "Connectivity Internet Exchange Point with Tier IV centros de datos Support in Indonesia" y enumera acceso a IXP Manager, estado del tráfico, actualizaciones de dirección MAC y filtros IRR, paneles de monitoreo, soporte de servidor de ruta, looking glass, comunidades BGP, filtrado IRR y RPKI. Lapágina de ISCX en PeeringDBenumera ISCX Internet Exchange bajo PT. Indonesia Super Corridor en Yakarta, con el sitio webhttp://iscx.isc.id, campos de contacto técnico y una marca de tiempo de actualización de junio de 2025. Lapágina de organización de PT. Indonesia Super Corridor en PeeringDBda el contexto de la dirección de Cyber 1 e identifica a la organización detrás de los registros orientados al intercambio.

Para un operador de centro de datos, un intercambio puede importar tanto como el tránsito bruto. Puede reducir la latencia doméstica, mantener el tráfico local, atraer contenido y redes de acceso, y crear una razón comercial para que los operadores mantengan presencia en el edificio. Las páginas de ISC mencionan repetidamente IIX, OIXP y Equinix IX en los paquetes de servicios. Sus ofertas de nube afirman acceso de 1 Gbps a IIX, OIXP y Equinix IX, mientras que las páginas de colocation empaquetan ancho de banda IIX e IX en los planes de rack.

Estas afirmaciones se ajustan a una instalación que vende no solo espacio y energía, sino también proximidad a la interconexión indonesia.

La precaución es que la presencia en el intercambio y la redundancia del cliente son cosas diferentes. Un servidor de ruta, IXP Manager y looking glass ayudan a los miembros a gestionar el peering. No prueban por sí mismos que un cliente colocado tenga dos entradas de fibra, dos salas de encuentro, dos contratos de upstream, rutas de edificio aisladas o conmutación por error probada de un operador a otro. Un intercambio puede ser tanto un punto de concentración como una herramienta de resiliencia.

Si muchos clientes dependen del mismo tejido de conmutación, dominio de energía, sala de encuentro o ruta de agregación de upstream, el intercambio se convierte en parte del dominio de falla común.

PeeringDB también crea una división interesante. ISCX y la organización PT. Indonesia Super Corridor son visibles, y PeeringDB tiene una página de red para AS136825, un perfil relacionado de Indonesia Super Corridor con instalaciones de interconexión que incluyen CNI/ISC DC CBR, CNI DC MPR y CNI DC DPS. Pero una consulta directa a la API de PeeringDB para AS142379 no devolvió ningún perfil de red de AS142379 en el momento de la verificación. Esa ausencia no es un problema en sí misma; muchos operadores de instalaciones separan los ASN de instalación, intercambio y servicio.

Significa que los clientes deben preguntar qué AS, qué tejido de intercambio y qué puerto físico utiliza su servicio en particular.

La pregunta más fuerte del comprador es topológica: "Dibuje la ruta". Para un rack completo en MPR, muestre servicios públicos a UPS al rack, refrigeración al rack, conexión cruzada a la sala de encuentro, operador al upstream, puerto de intercambio al servidor de ruta, y red de respaldo a DRC si corresponde. Para una VM en la nube, muestre el hipervisor, almacenamiento, conmutador de la parte superior del rack, agregación, firewall, tránsito, peering, respaldo y portal de gestión. Para un cliente de recuperación ante desastres, muestre el sitio primario, ruta de replicación, medición de RPO/RTO y objetivo de restauración.

Sin ese dibujo, ISCX es una señal atractiva, pero no una garantía.

La propiedad y los límites operativos aún necesitan claridad a nivel contractual

La evidencia pública de ISC se superpone repetidamente con el entorno del grupo CNI. Las asignaciones de IP de APNIC revisadas aquí están asignadas a PT Cyber Network Indonesia. AS38496, el único vecino observado de AS142379 en la vista de RIPEstat, es CNI-AS-ID. Los perfiles de PeeringDB sitúan a PT. Indonesia Super Corridor, ISCX y los nombres de instalaciones con marca CNI en el mismo panorama práctico de interconexión. Los directorios de instalaciones de terceros describen a ISC como parte del contexto del Grupo CNI. Este patrón no es sospechoso.

Es normal que las empresas de centros de datos, intercambio e ISP compartan edificios, matrices corporativas, recursos de IP, equipos de operaciones y activos de red.

Pero el contexto compartido cambia la diligencia. Un cliente no debe detenerse en la marca de la página web. Debe identificar la entidad contratante, el operador de la instalación, el titular de los recursos IP, el operador del intercambio, el proveedor de manos remotas, la parte facturadora y la parte responsable de las comunicaciones de incidentes. Si una empresa es dueña del edificio, otra gestiona el intercambio, otra tiene el espacio de direcciones y otra firma la orden de servicio, el cliente necesita saber dónde se sitúan la responsabilidad y la escalación.

La misma pregunta se aplica dentro de la instalación: ¿un servicio en la nube es operado por ISC en equipos propiedad de ISC, por un afiliado de CNI, por equipos del cliente en un rack de ISC, o por un socio cuyo nombre no es visible en la página pública del producto?

La respuesta importa durante las fallas porque las interrupciones no respetan los límites de marketing. Un cliente puede tener un contrato de colocation con una entidad, una asignación de IP de otra, una conexión cruzada a través del equipo de intercambio, un ticket de soporte a través de un portal de cliente y una ruta de replicación DRC a través de un tercer servicio. Si esas funciones están operativamente integradas, el cliente se beneficia de un equipo de recuperación coordinado. Si están administrativamente separadas, la recuperación puede ralentizarse mientras los equipos deciden quién es el dueño del problema.

El registro público no permite que un lector externo resuelva ese límite.

Para la contratación, la evidencia más clara sería un cronograma de servicios que asigne cada dependencia a una parte responsable. Debería decir quién controla la sala, quién mantiene los UPS y generadores, quién opera la refrigeración, quién gestiona las conexiones cruzadas del cliente, quién es dueño de la plataforma en la nube, quién anuncia los prefijos del cliente, quién maneja el abuso, quién aprueba el acceso de emergencia y quién habla con los clientes durante un incidente. Esto no es trivialidad legal.

En un evento de energía, fuga de ruta, falla de tarjeta de acceso o activación de DRC, el límite determina qué tan rápido una persona real puede tomar una decisión.

La página de recuperación ante desastres hace las preguntas correctas y deja las respuestas difíciles abiertas

La página de Bali DRC es útil porque nombra explícitamente conceptos de recuperación. Menciona RPO, RTO, restauración universal, protección de aplicaciones empresariales, compresión, deduplicación, conectividad de múltiples intercambios, energía resiliente, protección contra incendios, monitoreo y aire acondicionado de precisión redundante. Ese vocabulario es exactamente lo que los compradores empresariales deben esperar de un proveedor de recuperación ante desastres.

La página no se limita a decir "datos seguros"; identifica el tiempo de recuperación, el punto de recuperación, la red, la energía, el incendio y la refrigeración como los componentes de la oferta.

Pero el lenguaje de recuperación se convierte en evidencia solo cuando está vinculado a pruebas. Una página pública de DRC no puede decirle a un banco, agencia gubernamental, operador de comercio electrónico o empresa SaaS si su carga de trabajo se reiniciará dentro de la ventana prometida. La respuesta depende del modo de replicación, consistencia del almacenamiento, dependencias de aplicaciones, corte de DNS y enrutamiento, sistemas de identidad, orden de escritura de la base de datos, inmutabilidad de respaldo, frecuencia de pruebas y acceso del personal del cliente.

"Conexión Gigabit a Múltiple Exchange" es una afirmación útil, pero no es lo mismo que el ancho de banda de replicación medido bajo carga. "Capacidad total del generador de respaldo" es alentador, pero no es lo mismo que el tiempo de funcionamiento del combustible durante una emergencia regional.

La página de DRC también plantea una cuestión de separación de instalaciones. Bali está físicamente distante de Yakarta, lo que puede ser valioso para la recuperación regional ante desastres. Pero la distancia aumenta la latencia, cambia la dependencia de la red y puede complicar los diseños de consistencia de datos. Para algunas cargas de trabajo, Bali puede ser excelente como respaldo o standby en caliente. Para sistemas transaccionales de baja latencia, puede requerir una replicación asíncrona cuidadosa y la aceptación de ventanas de pérdida de datos.

Los clientes necesitan saber si la oferta de DRC de ISC es de respaldo y restauración, luz piloto, standby en caliente, activo-activo o simplemente colocation en un segundo sitio. Cada patrón tiene un costo y un comportamiento de falla diferentes.

Esto importa porque "DRC" puede ser sobrevendido en el mercado. Una segunda sala con energía y refrigeración no es suficiente. Un centro de recuperación ante desastres debe ser ejercitado. Un cliente debe preguntar por la última fecha de prueba, el alcance de la prueba, el RPO y RTO logrados, las suposiciones de falla, la propiedad del runbook, el plan de personal, el proceso de notificación al cliente y la evidencia posterior a la prueba. Debe preguntar si la capacidad de restauración está reservada o es de mejor esfuerzo. Debe preguntar si las rutas de red de DRC pasan por los mismos puntos de concentración de Yakarta que fallaron.

Debe preguntar qué sucede cuando el desastre no es una interrupción del edificio sino un incidente cibernético, bloqueo de facturación, falla del controlador de la nube o eliminación accidental.

El material público de DRC de ISC es lo suficientemente sólido como para justificar esas preguntas, no lo suficientemente sólido como para responderlas. La empresa comercializa claramente los conceptos que importan. Tiene una instalación de Bali con nombre en la lista de clientes de Uptime y en directorios estilo Datacenters.com/DatacenterMap. Lo que falta públicamente es una prueba de recuperación de nivel de cliente. Eso no es inusual en colocation, porque muchos detalles se encuentran en propuestas y contratos. Pero significa que los lectores públicos no deben convertir los encabezados "RPO" y "RTO" en confianza sin pedir evidencia medida.

Quiénes resultan afectados si la plataforma falla

Las partes afectadas son más amplias que los inquilinos de rack. Un cliente tradicional de colocation puede perder el acceso a los equipos alojados si falla la energía, la refrigeración, el control de acceso o las manos inteligentes. Un cliente de la nube puede perder computación, almacenamiento, servicio de IP pública o acceso de gestión si falla la infraestructura virtual operada por ISC. Un participante del intercambio puede perder el peering o la visibilidad de la gestión del tráfico local si fallan ISCX o sus servicios de instalaciones de soporte.

Un cliente de DRC puede descubrir que su plan de recuperación existe en papel pero no puede ejecutarse a la velocidad requerida si fallan la replicación, el enrutamiento, el personal o la logística de combustible. El mismo edificio puede soportar varios perfiles de riesgo diferentes a la vez.

Los clientes más sensibles son aquellos que utilizan ISC para la localidad y continuidad indonesias. Las empresas nacionales, los proveedores del sector financiero, los sistemas adyacentes al gobierno, las plataformas de medios, las redes de contenido y los proveedores regionales de SaaS pueden preocuparse por la accesibilidad a Yakarta, el acceso al intercambio local, los canales de soporte indonesios y la confianza en la ubicación de los datos. Para ellos, la instalación no es solo un rack más barato. Es parte del límite del servicio que los clientes utilizan para cumplir con las expectativas de latencia, cumplimiento y continuidad.

El segundo grupo afectado son las redes y proveedores de contenido más pequeños que podrían usar ISCX o infraestructura alojada por ISC para el peering. Si falla un servidor de ruta, el tejido de conmutación o el dominio de energía de la instalación, el tráfico local puede redirigirse a rutas más largas o fallar para las redes sin peering de respaldo. Si falla un portal IXP o un sistema de monitoreo, los miembros pueden perder visibilidad operativa incluso si el reenvío de paquetes continúa.

El material público de ISCX anuncia paneles de monitoreo y funciones de servidor de ruta; los clientes deben preguntar si esos sistemas están fuera de banda, son redundantes y se operan independientemente del tejido de intercambio que monitorean.

El tercer grupo afectado son los clientes que compran nube en lugar de espacio. Los compradores de nube a menudo tienen menos visibilidad sobre dónde residen sus cargas de trabajo. Pueden ver un plan de VM, memoria, almacenamiento, IP pública y paquete de ancho de banda, pero no el clúster de hosts, la replicación del almacenamiento, la política de mantenimiento del hipervisor, el programa de respaldo o la ruta de escalación de soporte.

Si los servicios en la nube de ISC se construyen sobre un conjunto de recursos compacto, el riesgo práctico es la contención del vecino ruidoso, el mantenimiento del host, la falla del almacenamiento, el ancho de banda internacional limitado o el soporte lento durante un incidente en la instalación. Los planes públicos son útiles para el precio y el alcance; no son suficientes para la arquitectura de producción.

El cuarto grupo afectado son los revendedores o proveedores de servicios gestionados que podrían colocar sistemas de clientes dentro de ISC sin exponer a ISC como la dependencia. Cuando falla un servicio de marca blanca o alojado por un revendedor, el usuario final a menudo solo ve al proveedor inmediato. La falla subyacente del centro de datos puede ser invisible hasta que la recuperación se estanca. Para esas cadenas, la evidencia operativa de ISC importa incluso si el cliente final nunca firma directamente con ISC.

Las rutas de falla a probar son ordinarias e implacables

La primera ruta de falla es la energía de los servicios públicos. Las páginas de ISC mencionan energía de doble fuente, paneles de distribución separados, energía resiliente de dos fuentes de voltaje y generadores. Esos son los componentes correctos.

Los clientes aún deben verificar el diagrama unifilar, si ambas fuentes son alimentaciones de servicios públicos independientes o rutas de distribución internas, si la capacidad del generador soporta la carga total de TI y la refrigeración juntas, cuánto tiempo dura el combustible a la carga comprometida, si el reabastecimiento está contratado durante un evento en toda la ciudad, y si el mantenimiento se puede realizar sin mover las cargas del cliente a un estado de redundancia reducida.

La segunda ruta de falla es la refrigeración. La página de DRC de ISC menciona aire acondicionado de precisión con un sistema redundante y sus páginas de mantenimiento hacen referencia al trabajo del sistema de refrigeración. Eso es un buen comienzo. El riesgo es que las limitaciones de refrigeración y energía interactúen. Un rack puede venderse con 10A, pero los equipos densos pueden crear puntos calientes, y la redundancia de refrigeración debe soportar la carga real, no la carga promedio.

Los clientes deben preguntar por los detalles de contención de pasillo frío/caliente, rangos de temperatura y humedad, redundancia de la unidad de refrigeración, diseño del enfriador o DX, historial de mantenimiento y alarmas visibles a través de DCIM.

La tercera ruta de falla es la interrupción del punto de encuentro del operador. El material público de ISC comercializa conexiones cruzadas, ancho de banda IIX/IX, ISCX, servidores de ruta, OIXP, Equinix IX y lenguaje de intercambio múltiple. La vista BGP para AS142379 todavía muestra un vecino observado, AS38496, y ninguna ruta IPv6 actual desde ese AS. Eso no contradice la historia de intercambio, pero significa que la evidencia pública a nivel de AS no muestra una amplia diversidad de tránsito.

Los clientes deben solicitar una lista de operadores, declaración de diversidad de rutas, diseño de la sala de encuentro, SLA de conexión cruzada y prueba de que la conmutación por error se ha probado desde el rack o la red virtual del cliente.

La cuarta ruta de falla es el incendio, inundación o interrupción del acceso a la instalación. La página de Bali menciona FM200 y sensores de humo arriba y abajo del suelo elevado, CCTV y acceso al rack con tarjeta/huella dactilar. La página principal menciona seguridad tripulada y detectores de movimiento. Esos son controles físicos, pero los clientes deben preguntar sobre la entrada de agua, el riesgo de techo y drenaje, la carga del suelo, la separación de zonas de incendio, el acceso de emergencia, el acceso del cliente durante incidentes y si las limitaciones del seguro o la gestión del edificio podrían retrasar las reparaciones.

Un centro de datos puede tener buenos controles y aún así estar expuesto a dependencias ordinarias del edificio.

La quinta ruta de falla es la construcción o la falta de coincidencia de capacidad. El registro público contiene múltiples cifras de capacidad: el titular de 5 MW de MPR de ISC, el marcador de empresa de 6 MW de Baxtel, la cifra de 16,0 MW para MPR de Datacenters.com, y otras referencias del mercado de hasta 8 MW de carga de TI. La existencia de números diferentes no es alarmante en sí misma, pero es una advertencia contra la compra a partir de un número de diapositiva.

Los clientes deben preguntar qué número es el actual, si es capacidad de servicios públicos, bruta, crítica, de TI o planificada, y si su contrato reserva capacidad o simplemente les da acceso a la capacidad mientras esté disponible.

La sexta ruta de falla es administrativa. Las cuentas DCIM, los portales de clientes, las mesas de soporte, los sistemas de facturación y los permisos de acceso son parte de la infraestructura. Si un portal está caído, un cliente puede no ser capaz de monitorear el tráfico, abrir un ticket, aprovisionar capacidad en la nube, ajustar los filtros de red o verificar que se ha planificado un evento de mantenimiento. ISCX anuncia IXP Manager y paneles de monitoreo. ISC anuncia cuentas DCIM para clientes. Los compradores deben tratar esos sistemas como dependencias operativas y preguntar cómo se respaldan, monitorean y soportan.

Qué cambiaría la calificación

ISC puede mejorar la calificación de riesgo público sin publicar datos confidenciales de los clientes. Una página de red breve ayudaría: ASN utilizados para los servicios de instalación, nube e intercambio; prefijos IPv4 e IPv6 actuales; proveedores de upstream/tránsito; tejidos de intercambio; política del servidor de ruta; estado de RPKI; enlaces de looking-glass; registros de PeeringDB; contactos de abuso y NOC; y canales de notificación de mantenimiento. La empresa ya tiene suficiente material público para respaldar dicha página. Consolidarlo reduciría la ambigüedad.

Una página de capacidad de instalaciones ayudaría más. Debería distinguir CBR, MPR y Bali DRC; enumerar el nivel de diseño y el alcance del premio; indicar la potencia bruta, la carga de TI comprometida y la carga vendible disponible; explicar las bandas de densidad de rack; identificar las suposiciones de alimentación de servicios públicos y del generador; revelar la redundancia de refrigeración; y explicar si los servicios en la nube se ejecutan en uno o más sitios. No necesita exponer clientes individuales. Necesita hacer que la capacidad comercializada sea comprobable.

Una página de evidencia de recuperación sería aún más valiosa. Podría describir los patrones de recuperación ante desastres disponibles, publicar categorías de RPO/RTO de muestra, explicar la frecuencia de las pruebas de restauración, enumerar las opciones de respaldo y replicación, indicar si la capacidad de DRC está reservada o es de mejor esfuerzo, y proporcionar un canal de estado o historial de incidentes. Los clientes no necesitan perfección. Necesitan saber si la empresa ha practicado la falla contra la que vende protección.

Para la confianza en la red, AS142379 debería mostrar una diversidad pública más amplia si está destinado a servir directamente a clientes de producción. Múltiples upstreams visibles, un perfil de red de AS142379 en PeeringDB, IPv6 utilizable por el cliente actual, cobertura RPKI limpia en todos los prefijos visibles y un looking glass público aumentarían la confianza. Si AS142379 es simplemente un ASN interno o específico de la instalación mientras que la diversidad del cliente reside bajo AS136825, AS38496 u otros ASN de CNI/ISC, ISC debería decirlo claramente.

La ambigüedad obliga a los clientes a adivinar qué evidencia de ruta pública se aplica a su servicio.

Para la confianza en la contratación, ISC debería alinear las reclamaciones de capacidad del mercado. Un comprador que ve 5 MW, 6 MW, 8 MW y 16 MW en diferentes lugares públicos no puede saber qué cifra es la que cuenta. La respuesta puede ser simple: potencia del sitio, carga de TI, expansión planificada, capacidad del edificio o un error del directorio. Pero la falta de coincidencia pública crea fricción. En la compra de centros de datos, una declaración de capacidad limpia no es cosmética; determina si un cliente puede reservar espacio y energía durante tres a cinco años.

Calificación operativa

PT. INDONESIA SUPER CORRIDOR - centros de datos obtiene una calificación de evidencia de red y operación media con un componente sólido de existencia de instalaciones. La parte sólida es merecida: ISC tiene páginas oficiales de instalaciones, activos con nombre CBR/MPR/Bali, registros de premios emitidos por Uptime Institute, ofertas públicas de rack y nube, una superficie de intercambio ISCX, identidad de AS de APNIC, visibilidad IPv4 actual de RIPEstat y RPKI válido en prefijos visibles muestreados. Esto es mucho mejor que una cáscara inactiva o una marca de alojamiento no verificada.

La rebaja también es merecida. La evidencia pública aún no prueba la capacidad utilizable a la escala anunciada. No concilia las cifras de potencia en competencia. No muestra IPv6 actual para AS142379. Muestra un vecino BGP observado para ese AS. No publica listas de operadores, diagramas unifilares de servicios públicos, tiempo de funcionamiento del combustible, evidencia de pruebas de refrigeración, resultados de restauración de clientes, historial de estado, comunicaciones de incidentes, arquitectura de nube o reglas de conmutación por error específicas del sitio.

La empresa comercializa los ingredientes correctos, pero los clientes aún tienen que verificar la receta.

La conclusión práctica no es evitar a ISC. Es comprar con cuidado. Para colocation modesta, presencia adyacente al intercambio, localidad indonesia o una conversación de recuperación Yakarta/Bali, ISC pertenece a la lista de diligencia. Para cargas de trabajo de producción que dependen de energía ininterrumpida, diversas rutas de operadores y recuperación probada, los compradores deben exigir recorridos por el sitio, documentos de ingeniería, pruebas de ruta en vivo, simulacros de conmutación por error y lenguaje contractual que asigne el servicio comercializado a una instalación y ruta de dependencia específicas.

En los centros de datos, la diferencia entre "racks disponibles" y "capacidad superviviente" es donde reside el riesgo real.