Resumen
- El objeto de red pública preciso detrás del nombre del directorio no es actualmente un borde de ruta activo.El resumen de AS de RIPEstat para AS203301identifica al titular como centros de datos Cloud 9 Ltd., pero marca el ASN como no anunciado el 12 de julio de 2026, yel estado de enrutamiento de RIPEstatmuestra cero espacio IPv4 o IPv6 anunciado.
- La misma organización Cloud 9 Ltd. tiene una señal operativa activa mucho más fuerte a través de AS57814.El estado de enrutamiento de RIPEstat para AS57814muestra el ASN anunciado con 27 prefijos IPv4, 3 prefijos IPv6 y 12 vecinos observados, mientras queel texto del registro RIPEvincula AS57814 con ORG-CL434-RIPE, la organización Cloud 9 Ltd.
- El sitio público de Cloud9 comercializa un centro de datos neutral con respecto a los operadores ubicado en Tiflis, servicios de colocación, VPS, VDS, servidores dedicados, dominios y alojamiento compartido. Su propiapágina del centro de datosindica que la mayoría de los servicios se prestan desde sus instalaciones en Tiflis y enumera afirmaciones sobre energía, refrigeración, extinción de incendios, seguridad e interconexión.
- Las afirmaciones sobre la resiliencia física son inusualmente específicas, pero siguen siendo afirmaciones orientadas al comprador. Cloud9 dice que la instalación utiliza tres subestaciones eléctricas independientes, un generador diésel de 630 KVA, alimentación N+N para la zona de colocación, refrigeración DX, extinción de incendios Novec 1230, acceso programado a las instalaciones y cobertura de ingeniería 24/7; los clientes aún necesitan evidencia del historial de mantenimiento, autonomía del generador, conmutación por error de refrigeración y restauración.
- La calificación de la evidencia es Media. Existe evidencia real de las instalaciones de Cloud 9 Ltd. y del enrutamiento de AS57814, además de entradas en PeeringDB para Cloud9 Dinamo Arena e IXP.ge, pero el objeto AS203301 exacto está inactivo y el material público no prueba la capacidad auditada, la operación de doble alimentación activa, la diversidad de rutas de operadores, la capacidad de energía de reserva o los resultados de conmutación por error de los clientes.
La empresa es visible, pero el ASN de centro de datos asignado está inactivo
La primera prueba para centros de datos Cloud 9 Ltd. no es si la marca tiene un sitio web. Es si la identidad exacta de red pública asociada al objeto del directorio está funcionando hoy. En esa cuestión, la respuesta es negativa.El resumen de AS de RIPEstat para AS203301nombra al titular como centros de datos Cloud 9 Ltd. y muestra el ASN como asignado, pero también informa que el ASN no está anunciado.El estado de enrutamiento de RIPEstat para AS203301muestra cero prefijos IPv4 anunciados, cero prefijos IPv6 y ningún vecino observado en la vista del 12 de julio de 2026.
Eso no es una nota al pie menor. Si una ficha de directorio, una tabla de enrutamiento, un memorando de adquisiciones o una nota de cliente tratan a AS203301 como el borde público actual de un servicio de centro de datos, la evidencia actual no respalda ese tratamiento.Los prefijos anunciados de RIPEstat para AS203301devuelven una lista actual vacía.El historial de enrutamiento de RIPEstatmuestra que AS203301 originó previamente 185.139.56.0/22 desde 2016 hasta octubre de 2023, por lo que el ASN no siempre estuvo inactivo. Pero una ruta histórica no es capacidad utilizable para el cliente en 2026. Es evidencia de operación anterior, no de servicio presente.
El punto más interesante es que la inactividad de AS203301 no hace desaparecer a Cloud 9 Ltd. Obliga a una separación entre un ASN de centro de datos asignado y la red actual más amplia del operador.El resumen de AS de RIPEstat para AS57814identifica AS57814 como Cloud9 Cloud 9 Ltd. y lo marca como anunciado.El estado de enrutamiento de RIPEstat para AS57814informa 27 prefijos IPv4, 3 prefijos IPv6 y visibilidad completa del colector de rutas en la vista verificada.Los datos derivados del registro RIPE para AS57814vinculan el ASN a ORG-CL434-RIPE, el mismo identificador de organización de Cloud 9 Ltd. visible enel registro de organización de RIPE.
Por lo tanto, la lectura responsable no es ni el descarte ni la confianza ciega. AS203301 no debe tratarse como un borde activo sin evidencia reciente. AS57814 muestra que la operación de Cloud9 tiene una huella enrutada real. Un cliente que evalúe servicios de colocación, VPS o servidores dedicados debe preguntar qué ASN y prefijos transportan el servicio adquirido, si AS203301 ha sido retirado, reservado o reutilizado, y si algún servicio orientado al cliente todavía depende de su antiguo plan de ruta. La distinción importa porque la identidad de red no es la marca.
Es el camino por el cual los sistemas del cliente accesibles sobreviven a un fallo.
Las instalaciones comercializadas son un único ancla en Tiflis
La postura pública de Cloud9 es directa: supágina del centro de datospresenta a la empresa como un operador de centros de datos neutral con respecto a los operadores en Georgia y dice que la mayoría de los servicios de Cloud9 se prestan desde su centro de datos ubicado en Tiflis. El pie de página y lapágina de contactoindican que la ubicación operativa es 2 Akaki Tsereteli Avenue, Dinamo Stadium, Gate 5, Tiflis, Georgia 0112.El registro de instalación de PeeringDB para Cloud9 Dinamo Arenatambién ubica una instalación llamada Cloud9 Dinamo Arena en A. Tsereteli Ave 2, Tiflis, con Cloud9 LTD como organización y contactos de correo electrónico de soporte.
Eso es mejor que una vaga página en la nube sin ubicación. La huella pública le da al comprador una pregunta a nivel de edificio que hacer. El problema es que la dirección de un edificio no es lo mismo que un mapa completo de capacidad. Cloud9 puede señalar de forma creíble una instalación en Tiflis, pero el material público no revela el número de salas, armarios activos, armarios libres, consumo de energía, reserva de refrigeración, contratos de combustible, autonomía del generador bajo carga medida, diversidad de entrada de operadores o la cantidad de capacidad del cliente que permanece después de un fallo de un componente.
El sitio de Cloud9 también vincula varios servicios a este ancla física. Supágina de colocaciónvende configuraciones de 1U, 2U, servidor torre, medio rack, rack completo y jaula. Supágina de VPSvende servidores privados virtuales gestionados y autogestionados. Supágina de VDSvende porciones virtuales más grandes, y supágina de servidores dedicadosvende servidores físicos. Lostérminos de serviciode la empresa enumeran alojamiento, colocación, servicios de centro de datos, alquiler de racks, conexiones cruzadas, unidades de distribución de energía e interconexión con proveedores de Internet como servicios ofrecidos.
Esa amplitud de productos aumenta las apuestas. Un fallo en un único ancla de Tiflis puede afectar a los clientes de diferentes maneras: un cliente de colocación puede ser propietario del hardware que falla pero depender de Cloud9 para la energía, la refrigeración, el acceso y las conexiones cruzadas; un cliente de VPS puede depender de Cloud9 para el servidor, el almacenamiento, la plataforma de virtualización y las copias de seguridad; un cliente de servidor dedicado puede depender de Cloud9 para la sustitución del servidor, el acceso remoto y la continuidad de la red.
Por lo tanto, el mismo corte puede parecer un evento de energía, un evento de refrigeración, un evento de enrutamiento o un evento de soporte dependiendo del contrato del cliente.
La evidencia de ubicación es lo suficientemente sólida como para hacer el análisis concreto. No es suficiente para que el servicio sea resistente por sí mismo. El comprador aún necesita saber si la instalación de Tiflis es el único sitio de producción activo para el servicio adquirido, si las copias de seguridad salen del sitio, si la conmutación por error utiliza otra ubicación de Cloud9 o solo otro clúster en el mismo edificio, y si los contratos del cliente distinguen entre "disponible para la venta" y "utilizable después de un fallo".
Las afirmaciones sobre energía son específicas, pero el tiempo de funcionamiento sigue siendo la prueba
Las afirmaciones públicas sobre energía de Cloud9 son inusualmente específicas para un proveedor de alojamiento regional. Lapágina del centro de datosafirma que la instalación se alimenta de tres subestaciones eléctricas independientes y tiene un generador diésel de 630 KVA. La misma página dice que la zona de colocación utiliza alimentación redundante N+N con soporte de SAI. Lapágina de colocaciónrepite la promesa en términos orientados al cliente: los paquetes de rack enumeran alimentación dual A/B para servidores de 1U y 2U, mientras que el servicio de servidor torre se enumera con alimentación simple.
Esos detalles son útiles porque crean preguntas medibles. Tres subestaciones pueden reducir la concentración de la red eléctrica, pero la frase no revela si las alimentaciones están activas simultáneamente, si entran al edificio por caminos físicamente separados, si el equipo de conmutación tiene un único punto de fallo, si el mantenimiento se puede realizar sin exponer a los clientes, o si todos los armarios de colocación pueden consumir su carga contratada durante un evento de la red eléctrica. Un generador de 630 KVA es un equipo serio, pero el número relevante no es la potencia nominal.
Es la autonomía probada y el perfil de carga después de la transferencia del SAI, la entrega de combustible, la demanda de refrigeración y las cargas no informáticas del edificio.
La alimentación N+N también es una afirmación que necesita pruebas a nivel de armario. Si ambos lados de un armario de doble alimentación son realmente independientes, un fallo de una sola alimentación no debería apagar equipos de cliente con doble cableado.
Pero muchos fallos de clientes ocurren en el borde de un plan de energía bien diseñado: un dispositivo con un solo cable conectado a través de la unidad de distribución de energía incorrecta, un lado A sobrecargado durante el mantenimiento, un disparo del disyuntor causado por un pico de cliente, una prueba del generador que no incluye carga real, o una tarea de manos remotas que deja un cable en el camino incorrecto. El material público de Cloud9 no muestra con qué frecuencia se prueba la conmutación por error ni cómo reciben los clientes la evidencia.
El paquete de servidor torre importa porque utiliza abiertamente alimentación simple. Eso no es un defecto; es un nivel de servicio. Significa que los clientes no pueden inferir resiliencia energética en todo el centro de datos de un producto que puede usar una sola ruta eléctrica en el dispositivo. El comprador debe hacer coincidir la criticidad de la carga de trabajo con el diseño del equipo. Un servidor no crítico puede aceptar racionalmente una ruta de alimentación simple.
Un sistema de producción que debe sobrevivir a un fallo de alimentación necesita equipos con doble cableado, distribución A/B probada, suficiente margen de energía de reserva y un contrato que explique lo que Cloud9 hará durante el mantenimiento.
La mayor pregunta sobre energía no es si la página de marketing nombra componentes. Es si Cloud9 puede proporcionar evidencia reciente y relevante para el cliente: última prueba de carga completa del generador, fechas de pruebas de transferencia, ventanas de mantenimiento del SAI, acuerdo de suministro de combustible, densidad de rack máxima admitida, carga real del cliente e historial de incidentes. Sin esa evidencia, la instalación aún puede ser buena, pero el comprador confía en una promesa en lugar de un estado de fallo demostrado.
Refrigeración, protección contra incendios y seguridad reducen los posibles caminos de fallo
La página de la instalación ofrece un conjunto comparable de afirmaciones para refrigeración, protección contra incendios y seguridad física. Cloud9 dice que la temperatura y la humedad están controladas por un sistema de refrigeración DX. Dice que las salas de servidores no tienen ventanas ni paredes que den al exterior, y que la fontanería cercana se limita al sistema de extinción de incendios. También dice que el centro de datos utiliza detección temprana de temperatura, humo y fuego, además de un sistema de extinción de incendios Novec 1230.
Para el control de acceso, la página señala CCTV, controles biométricos, un edificio de estándar sísmico e instalaciones vigiladas.
Estas afirmaciones importan porque un corte de un centro de datos a menudo no es un corte de energía puro. La refrigeración puede convertirse en la limitación vinculante durante un evento de la red eléctrica, un evento del generador o un despliegue de armario de alta densidad. Si la capacidad de aire refrigerado, la gestión del flujo de aire o la redundancia del compresor son débiles, los servidores pueden quedarse sin margen térmico incluso cuando la energía sigue disponible.
La refrigeración DX puede ser una opción de diseño perfectamente válida, pero el cliente necesita saber el número de unidades, el patrón de redundancia, la práctica de mantenimiento, la disponibilidad de piezas de repuesto y la capacidad de eliminación de calor a la densidad de rack contratada.
La protección contra incendios también tiene un límite claro. La presencia de un sistema de extinción de incendios basado en gas es tranquilizadora solo si la detección, la zonificación, la retención de presión, la respuesta del personal y la comunicación con el cliente están actualizadas. Una descarga falsa puede interrumpir el servicio. Un incendio real puede hacer que el acceso sea imposible aunque el equipo no se destruya. El daño por humo o calor puede dejar el equipo del cliente en un estado incierto. La afirmación pública muestra una capa de protección prevista, no la ruta de recuperación probada después de una alarma.
La seguridad tiene una distinción similar. La biometría, el CCTV y los guardias reducen el riesgo de acceso no autorizado. No responden a quién puede entrar durante una emergencia, cómo se aprueba el acceso del cliente, con qué rapidez se puede realizar una tarea de manos remotas, o si el acceso a la instalación sigue disponible durante una interrupción en toda la ciudad. Laspreguntas frecuentes de colocaciónde Cloud9 dicen que las visitas de los clientes deben programarse y que los visitantes necesitan una identificación válida. Los términos dicen que los clientes de colocación pueden solicitar acceso 24/7 mediante acuerdo previo a través de la cuenta de cliente o por correo electrónico. Esas reglas son sensatas, pero también significan que el acceso está mediado por el personal de soporte e instalaciones de Cloud9.
Por eso la infraestructura física debe leerse como un sistema. La energía, la refrigeración, la protección contra incendios, el control de acceso y la mano de obra de soporte no son casillas de marketing independientes. Una unidad de refrigeración averiada puede requerir trabajos de energía. Un evento de energía puede aumentar la carga de refrigeración. Una alarma de incendio puede suspender el acceso. Una regla de seguridad puede ralentizar la reparación.
Un cliente debe preguntar a Cloud9 por el escenario combinado: ¿qué sucede si falla una alimentación eléctrica mientras un componente de refrigeración está en mantenimiento, o si un servidor del cliente necesita intervención manual durante una restricción de acceso a la instalación?
La neutralidad del operador debe significar más que una lista de operadores
Cloud9 utiliza la frase neutral con respecto al operador en supágina del centro de datosy dice que también es un operador de IXP. La misma página afirma que Cloud9 está conectada a los principales operadores de telecomunicaciones y a operadores ISP más pequeños a través de fibra oscura reservada con varias rutas alternativas y una capacidad total de interconexión de 250 Gbps. Lapágina de colocacióndice que las conexiones de fibra directa a los principales ISP locales ayudan a ofrecer una accesibilidad local de baja latencia.
La evidencia de enrutamiento apoya parcialmente la historia de interconexión.Los vecinos de ASN de RIPEstat para AS57814muestran 12 vecinos observados en la vista verificada, incluidas redes georgianas como Magticom, Caucasus Online, System Net, Silknet y Skytel, así como otras redes adyacentes e IXP.ge.El perfil de red de AS57814 en PeeringDBenumera Cloud9 como una red regional de servicios de red con soporte IPv6, política de peering abierta, una instalación y una presencia en el intercambio.La entrada netixlan de Cloud9 en PeeringDBmuestra una conexión de 10 Gbps en IXP.ge.
Esas son señales significativas. Tampoco son suficientes para probar la diversidad de rutas de operadores. Los colectores de rutas pueden mostrar ASN adyacentes, pero no pueden mostrar si los distintos operadores entran por conductos separados, si las conexiones cruzadas comparten una sala de encuentro, si un proveedor de tránsito domina la accesibilidad internacional, si los pares locales transportan tráfico de producción durante un fallo del proveedor de tránsito, o si los contratos de los clientes incluyen alguna garantía de diversidad de rutas. Una red puede tener varios vecinos lógicos y aún compartir una ruta física vulnerable.
La política de rutas pública de AS57814 enlos datos derivados del registro RIPEnombra varios ASN de tránsito o adyacentes en las declaraciones de importación y exportación. El registro exacto de AS203301 es más limitado:los datos derivados del registro RIPE para AS203301enumeran declaraciones de política que involucran a AS34797 y AS35076, mientras que el estado actual de la ruta no muestra anuncios activos. Esa diferencia es otra razón para preguntar qué plan de rutas se aplica a un servicio de cliente determinado.
Por lo tanto, la afirmación de neutralidad del operador es plausible pero incompleta. Un cliente debe preguntar por los proveedores de tránsito actuales, los acuerdos de peering público y privado, las opciones de conexiones cruzadas, las rutas físicas de la sala de encuentro, los compromisos de aviso de mantenimiento, las prácticas de seguridad de enrutamiento y los resultados de conmutación por error medidos. La frase "neutral con respecto al operador" debe significar que un cliente puede elegir realmente entre operadores y rutas.
No debe significar simplemente que la instalación está dispuesta a vender una conexión cruzada si el cliente puede conseguir una.
AS57814 muestra una amplitud que AS203301 no tiene
La evidencia de red actual más sólida es AS57814, no AS203301. En la vista de RIPEstat del 12 de julio de 2026, AS57814 tiene una huella amplia para un operador regional de alojamiento y centro de datos georgiano: 27 prefijos IPv4, 3 prefijos IPv6 y visibilidad completa de los pares RIPE RIS en ambas familias de direcciones.Los prefijos anunciados de RIPEstat para AS57814incluyen rutas IPv4 como 188.93.94.0/24, 185.139.56.0/24, 185.139.57.0/24, 185.139.58.0/24, 45.138.44.0/22 y varios otros /24s, además de espacio IPv6 que incluye 2a0d:8a00::/32.
Esa amplitud cambia la conclusión del artículo. Si solo existiera AS203301, la calificación de la evidencia sería débil o negativa para el enrutamiento actual. AS57814 lo impide. Muestra una red viva de Cloud 9 Ltd. con IPv4 e IPv6, múltiples vecinos y soporte de seguridad de enrutamiento actual.La validación RPKI de RIPEstat para 188.93.94.0/24 bajo AS57814devuelve válida, y lo mismo ocurre con los /24s de Cloud9 verificados, extraídos del espacio antiguo 185.139.56.0/22.
El contraste con AS203301 es marcado.El resumen de prefijo de RIPEstat para 185.139.56.0/22muestra que el agregado en sí no se anuncia, con /24s relacionados ahora visibles.La consistencia de enrutamiento de prefijo de RIPEstat para 185.139.56.0/22muestra 185.139.56.0/24, 185.139.57.0/24 y 185.139.58.0/24 en BGP activo bajo AS57814, mientras que el objeto de ruta /22 no está activo.La validación RPKI de RIPEstat para AS203301 y 185.139.56.0/22devuelve un resultado de ASN inválido porque la autorización de ruta en la vista verificada apunta a AS57814, no a AS203301.
Eso no significa que Cloud9 esté enrutando mal. Significa que la autoridad de ruta activa parece haberse movido a AS57814. Para un comprador, eso es un problema de documentación y un problema de resiliencia. Los contratos, las descripciones de servicios y los manuales de incidentes deben nombrar el ASN que realmente transporta el tráfico del servicio. Si AS203301 se conserva como un objeto de centro de datos inactivo o heredado, Cloud9 debe ser claro al respecto. Si se espera que regrese, la autorización de origen de ruta y la política de enrutamiento deben cambiarse antes de que el tráfico del cliente dependa de él.
IXP.ge mejora la situación local pero no elimina el riesgo internacional
La afirmación de interconexión de Cloud9 se ve respaldada por la evidencia de IXP.ge.El registro de IXP.ge en PeeringDBidentifica IXP.ge, también conocido como Geo-IX, en Tiflis y señala que el intercambio está disponible en Tiflis y Kutaisi.La página "Acerca de" de IXP.gedescribe el propósito de la asociación de intercambio como el intercambio directo de tráfico de Internet entre redes georgianas sin utilizar redes de terceros.La página de miembros de IXP.geenumera a Cloud9 entre los miembros de pleno derecho.
Esto es positivo para la accesibilidad local. Cuando los ISP locales, los proveedores de alojamiento y las redes de servicios intercambian tráfico localmente, el tráfico doméstico puede evitar desvíos innecesarios a través de tránsito extranjero. Una menor latencia y una menor dependencia de una única ruta extranjera pueden ser importantes para los clientes georgianos, el contenido, los servicios orientados al gobierno y las pequeñas empresas que atienden principalmente a usuarios dentro del país. También encaja con la afirmación de Cloud9 de que la conectividad local es un diferenciador.
La participación en el IXP no debe confundirse con redundancia total. El peering en un intercambio puede reducir la carga en el tránsito ascendente y mejorar las rutas locales, pero no protege automáticamente a un cliente de un fallo de energía en la instalación, un fallo del conmutador, un problema del servidor de rutas, una rotura de fibra, congestión internacional o cortes de DNS y capa de aplicación. PeeringDB enumera el puerto de IXP.ge de Cloud9 a 10 Gbps en el registro verificado; la propia página del centro de datos de Cloud9 anuncia por separado 250 Gbps de capacidad total de interconexión.
Ambas cifras pueden ser ciertas si esta última incluye conexiones cruzadas privadas, proveedores de tránsito y otra capacidad local. Los registros públicos no concilian la composición.
La pregunta más relevante es qué rutas transportan qué tráfico cuando algo se rompe. Si falla el proveedor de tránsito internacional principal, ¿cuánto tráfico se mueve a otros proveedores de tránsito y con qué calidad? Si falla el puerto del IXP, ¿los usuarios locales siguen siendo accesibles a través del tránsito? Si se daña una ruta de fibra hacia el Dinamo Arena, ¿las rutas alternativas son verdaderamente separadas? Si un cliente compra una conexión cruzada, ¿está en una ruta diversa de los enlaces de tránsito propios de Cloud9 o en el mismo haz físico?
El material público de Cloud9 le da al comprador suficiente para hacer buenas preguntas. No proporciona lo suficiente para tratar el peering local como recuperación ante desastres. La mejor versión del servicio combinaría un borde AS57814 activo, tráfico local de IXP.ge, varios proveedores de tránsito independientes, una higiene de seguridad de enrutamiento visible y opciones claras de ingeniería de tráfico para el cliente. El registro público respalda parte de esa imagen. Deja la ruta física y las pruebas de conmutación por error por demostrar.
Los paquetes de colocación revelan dónde puede reducirse la capacidad utilizable
El menú de colocación de Cloud9 es inusualmente transparente sobre el paquete básico. Lapágina de colocaciónenumera paquetes de rack de 1U y 2U con alimentación dual A/B, enlace de 1 Gbps y un enlace de gestión separado. También enumera una opción de servidor torre con alimentación simple. La página indica que cada cliente recibe conectividad de 1 Gbps sin medición a los ISP georgianos y 30 Mbps de conectividad global, y describe las opciones de medio rack, rack completo y jaula como acuerdos personalizados o empresariales.
Esas cifras no son solo precios. Definen la restricción visible para el cliente. La conectividad local puede ser abundante en relación con muchas cargas de trabajo pequeñas, mientras que la conectividad global por cliente básico de colocación está limitada. Un cliente georgiano que atiende principalmente a usuarios domésticos puede encontrar eso aceptable. Una empresa que atiende a usuarios internacionales, trabajadores remotos, API transfronterizas o copias de seguridad globales debe probar la ruta global cuidadosamente.
Treinta megabits por segundo pueden ser suficientes para la gestión, sitios pequeños o servicios de bajo tráfico, pero no es una afirmación general de capacidad en la nube.
La distinción entre capacidad instalada y utilizable es importante aquí. Una instalación puede anunciar una alta interconexión agregada mientras que los productos individuales se venden con asignaciones globales más reducidas. Un rack puede tener alimentación dual mientras que el servidor propio del cliente tiene una sola fuente de alimentación. Un enlace de gestión puede estar disponible mientras que un sistema operativo averiado aún requiere acción humana. Una jaula puede personalizarse mientras que los recursos compartidos de la instalación, la programación de acceso y la capacidad del generador siguen siendo comunes.
Las preguntas frecuentes de Cloud9 son útiles porque establecen límites. Para la colocación, el fallo del hardware sigue siendo responsabilidad del cliente, mientras que Cloud9 dice que ayudará con la reparación. Las visitas deben programarse. Las instalaciones de rack completo y jaula pueden llevar más tiempo que una instalación de un solo servidor. Estos son términos normales, pero significan que la recuperación es compartida. Un cliente no puede externalizar cada fallo simplemente colocando equipos en la instalación.
Por lo tanto, el cliente debe preguntar por una tabla de resiliencia producto por producto. Para el servicio de 1U y 2U, ¿qué sucede si falla una alimentación? Para el servicio de torre, ¿hay alguna redundancia de alimentación simple disponible a través de un conmutador de transferencia automática? Para los medios racks, ¿qué densidad de energía está incluida? Para las jaulas, ¿qué opciones de operadores son físicamente accesibles? Para todos los tipos de servicio, ¿cuánta capacidad global permanece disponible durante el mantenimiento o fallo del proveedor de tránsito?
Las tablas de paquetes públicos son un punto de partida útil, no la respuesta final.
VPS, VDS y servidores dedicados convierten las afirmaciones de la instalación en compromisos con el cliente
Los productos de servidores alojados añaden otra capa. Lapágina de VPSde Cloud9 ofrece paquetes gestionados y autogestionados con virtualización KVM, copias de seguridad diarias, opciones de panel de control y velocidades de red locales y globales anunciadas. Lapágina de VDSofrece servidores virtuales más grandes con recursos fijos. Lapágina de servidores dedicadosenumera paquetes gestionados y autogestionados, dice que los servidores se pueden configurar en un plazo de 24 a 48 horas cuando están disponibles en stock, y describe unidades de nivel empresarial, conexiones de red redundantes y fuentes de alimentación redundantes.
Estas afirmaciones trasladan el riesgo de una cuestión puramente de instalación a una cuestión de operaciones. Para los clientes de VPS y VDS, Cloud9 controla el host, el almacenamiento, la capa de virtualización, el sistema de copias de seguridad, la asignación de IP, el panel de control y el canal de soporte. Un cliente puede no saber qué servidor físico o rack soporta la carga de trabajo.
Por lo tanto, la prueba de resiliencia tiene que incluir pruebas de restauración de copias de seguridad, respuesta a fallos del host, aislamiento del almacenamiento, monitorización, comunicación con el cliente y la capacidad de mover un servidor virtual sin un corte prolongado.
Las copias de seguridad diarias son útiles, pero una afirmación de copia de seguridad no es una afirmación de recuperación hasta que se conoce el tiempo de restauración. Un sitio web pequeño puede tolerar una restauración al día siguiente. Un portal de negocios o un servicio transaccional puede que no. Las copias de seguridad también necesitan detalles de ubicación. Si las copias de seguridad se encuentran en la misma instalación, pueden proteger contra la eliminación de archivos y el fallo del servidor, pero no contra un incidente en toda la instalación.
Si las copias de seguridad salen de la instalación, el comprador necesita saber a dónde van, cómo se cifran, qué tan rápido se pueden restaurar y qué sucede cuando el cliente se va.
Los servidores dedicados crean una carga diferente. Cloud9 dice que la disponibilidad del procesador depende del stock, y los requisitos personalizados pueden añadir tiempo de instalación. Eso es normal, pero importa durante un fallo. Si falla un servidor dedicado, ¿hay un repuesto en caliente, un reemplazo en el mismo día, o solo el mejor esfuerzo en stock? Si falla un disco, ¿quién lo reemplaza y con qué rapidez? Si un cliente autogestiona el servidor, ¿dónde termina la responsabilidad de Cloud9? Si hay conexiones de alimentación y red redundantes, ¿están conectadas a rutas independientes de la instalación?
Por lo tanto, la pregunta central del artículo no es si Cloud9 vende productos alojados. Claramente lo hace. La pregunta es si la capacidad comercializada puede convertirse en un resultado de recuperación probado para cada producto. Los clientes de VPS, VDS, servidor dedicado y colocación compran diferentes partes de la pila. Deben recibir diferentes evidencias de resiliencia.
Los términos revelan un límite de mantenimiento y acceso
Lostérminos de servicio de Cloud9son importantes porque revelan partes del límite operativo que las páginas de marketing no muestran. Los términos nombran a Cloud 9 LLC, dan el número de identificación de empresa 405063755, indican una dirección legal georgiana y enumeran las categorías de productos ofrecidos a través del sitio y el portal de Cloud9. Definen los servicios de centro de datos para incluir el alquiler de racks de telecomunicaciones, conexiones cruzadas, unidades de distribución de energía, interconexión con proveedores de Internet y operadores móviles, y alquiler de direcciones IP.
Para la colocación, los términos dicen que los clientes deben reservar el acceso a la instalación a través de la cuenta de cliente o por correo electrónico, proporcionar los datos del visitante y seguir las reglas de conducta del centro de datos. También dicen que los clientes pueden solicitar acceso 24/7 mediante acuerdo previo y pueden solicitar servicio de manos remotas 24/7 para tareas como reinicio o sustitución de cables. Esos son compromisos valiosos, pero aún dependen de la disponibilidad del personal, la gestión de tickets y las condiciones de la instalación en el momento del incidente.
La declaración de mantenimiento más importante es que Cloud9 está autorizada a realizar trabajos técnicos planificados previamente para el servicio de colocación, con una duración no superior a ocho horas. Esa cláusula no debe leerse como una garantía de tiempo de actividad, pero es un límite operativo serio. Si un cliente necesita un servicio continuo, debe entender si el trabajo planificado puede afectar a una alimentación, un enrutador, una ruta de sala de encuentro, una jaula de cliente o el servicio completo.
También debe entender cuánto aviso se da, si los clientes redundantes pueden evitar el impacto y en qué se diferencian los trabajos de emergencia de los planificados.
Los términos también prometen soporte técnico 24/7 por correo electrónico, y lapágina de contactodice que el correo electrónico abre un ticket. Eso es útil para las operaciones de servicio, pero el soporte basado en correo electrónico puede ser frágil durante incidentes si el sistema de correo electrónico del cliente está alojado en el mismo proveedor o si el portal se ve afectado. Un cliente serio debe mantener una ruta de contacto fuera de banda y saber si el soporte puede actuar cuando la identidad del cliente, la facturación o el acceso al portal se ven afectados.
Los contratos a menudo contienen la respuesta real al riesgo de infraestructura. Las páginas de marketing describen lo que el operador quiere vender. Los términos describen dónde se comparte, limita o programa la responsabilidad. En el caso de Cloud9, los términos no socavan la historia del centro de datos; la hacen más concreta. Muestran que el acceso del cliente, las manos remotas, los trabajos planificados, las copias de seguridad y el soporte son parte del límite del servicio. El trabajo del comprador es convertir esas cláusulas en compromisos operativos medibles.
El panorama de seguridad de enrutamiento es mejor en el borde activo
La seguridad de enrutamiento es un área donde el borde activo de Cloud9 se ve mejor que el ASN inactivo.La validación RPKI de RIPEstat para 188.93.94.0/24 originado por AS57814devuelve válida. Los prefijos de Cloud9 verificados 185.139.56.0/24, 185.139.57.0/24, 185.139.58.0/24, 45.138.44.0/22 y 2a0d:8a00::/32 también devuelven válidos cuando se prueban contra AS57814. Esa es una señal positiva de higiene para las rutas que es más probable que los clientes vean hoy.
La imagen exacta de AS203301 es la opuesta. El antiguo agregado 185.139.56.0/22 no está activo como agregado en elresumen de prefijoverificado, y una verificación de validación de origen de AS203301 para ese agregado devuelve ASN inválido porque la autorización visible es para AS57814. Eso no debe sensacionalizarse. Simplemente refuerza que AS203301 no es el borde de enrutamiento actual para el bloque de direcciones antiguo.
Para un comprador de centro de datos, esto importa porque la validación del origen de ruta puede afectar la accesibilidad durante un cambio de ruta. Si un proveedor cambia un prefijo entre ASN, cambia de proveedor de tránsito, introduce un anuncio de respaldo o desagrega durante un incidente, la autorización de ruta debe coincidir. De lo contrario, las redes que filtran rutas no válidas pueden descartar el tráfico exactamente en el momento en que se necesita la resiliencia. La evidencia de AS57814 de Cloud9 es alentadora porque el borde activo valida.
AS203301 debe documentarse como inactivo a menos que se cambien la autorización y el plan de ruta.
La pregunta del comprador es simple: ¿qué prefijos utilizará mi servicio, cuál es su estado RPKI actual y quién puede cambiar las autorizaciones durante una emergencia? Para los clientes de colocación que traen sus propias direcciones, la pregunta se convierte en si Cloud9 admite objetos de ruta del cliente, ROA, sesiones BGP y cambios de ruta de emergencia con la suficiente rapidez. Para las direcciones proporcionadas por Cloud9, la empresa debería poder mostrar el estado de origen válido actual y explicar su plan de anuncio de respaldo.
La seguridad de enrutamiento no mantendrá un generador en funcionamiento ni una unidad de refrigeración en línea. Sin embargo, elimina un modo de fallo prevenible. En una instalación que vende neutralidad de operador y capacidad alojada, el plano de control de red debe estar tan bien documentado como la planta de energía.
La capacidad instalada no es lo mismo que la capacidad disponible
La cuestión de la capacidad debe dividirse en tres capas: lo que Cloud9 tiene instalado, lo que está dispuesto a vender y lo que permanece disponible después de un fallo o una solicitud de expansión. El sitio público es rico en categorías de servicio pero escaso en margen físico. Anuncia unidades de colocación, medios racks, racks completos y jaulas en lapágina de colocación, y anuncia requisitos de centro de datos personalizados en lapágina del centro de datos. No publica la disponibilidad de armarios activos, los límites de densidad de energía, el margen de refrigeración reservado, la capacidad de disyuntores de repuesto, el inventario de servidores de repuesto o el tiempo necesario para añadir una nueva ruta de operador.
Esa capa faltante importa porque la capacidad comercializada puede restringirse antes de que una sala esté llena. Un rack puede estar físicamente vacío pero no disponible a la densidad de energía que necesita un cliente. Un generador puede soportar la carga actual pero dejar poco margen para una nueva fila de alta densidad. Un diseño de refrigeración puede soportar racks de alojamiento estándar pero requerir cambios para computación densa. Una entrada de fibra puede soportar los proveedores actuales pero necesitar nuevas obras civiles para una ruta diversa solicitada.
En cada caso, la página de ventas puede ser cierta mientras que la capacidad utilizable para un cliente específico no está disponible de inmediato.
Las aprobaciones locales y las limitaciones del edificio también deben ser parte de la diligencia del comprador. Las páginas públicas de Cloud9 identifican la ubicación del Dinamo Stadium/Tsereteli Avenue y describen el centro de datos como construido y gestionado por Cloud9, pero no revelan los permisos de expansión, los compromisos de actualización de servicios públicos, las fases de construcción o las limitaciones del propietario y del sitio del estadio. Esa ausencia no es evidencia de un problema.
Es evidencia de que un cliente no debe tratar la capacidad futura de racks o jaulas como un activo terminado hasta que Cloud9 confirme la ruta de entrega, la ruta de energía, la ruta de refrigeración y la ruta de conexión cruzada por escrito.
La misma precaución se aplica a la declaración de instalación en 24 horas para algunos servicios de colocación y a la declaración de configuración en 24 a 48 horas para servidores dedicados. Esos plazos son útiles para pedidos estándar. No deben reutilizarse para un rack completo, una jaula, una construcción de operador, un despliegue de alta densidad o una migración de recuperación a menos que Cloud9 diga que la configuración exacta está disponible.
El camino del fallo en este artículo incluye el retraso en la construcción porque una promesa de expansión a menudo falla silenciosamente: el cliente firma antes de que el disyuntor, el rack, la ruta de parcheo, el stock de servidores o la ruta del operador estén realmente listos.
Por lo tanto, el comprador debe pedir una declaración de disponibilidad, no solo una cotización de precio. ¿Qué armarios están activos ahora? ¿Qué alimentaciones eléctricas ya están puestas en servicio? ¿Qué operadores ya están presentes en el punto de encuentro solicitado? ¿Qué rutas requieren nuevo trabajo? ¿Qué servidores están en stock? ¿Qué piezas se mantienen localmente? ¿Qué actualizaciones necesitan aprobación de servicios públicos, instalaciones o proveedores? Estas preguntas convierten una afirmación general de centro de datos en un compromiso de entrega.
Quién se ve afectado cuando falla el ancla de Tiflis
La base de clientes visible no se revela por completo, pero lapágina "Acerca de"de Cloud9 anuncia más de 1.200 clientes activos, más de 3.500 servicios activos, más de 5.000 dominios registrados y un 99,9 % de tiempo de actividad del sistema. Estas cifras son publicadas por el operador y deben tratarse como cifras de marketing a menos que estén documentadas contractualmente, pero muestran el tipo de dependencia en juego. No se trata simplemente de un ASN vacío sin promesa de cliente asociada. Es un negocio de alojamiento y centro de datos que se presenta como un proveedor de infraestructura local.
Si la instalación de Tiflis falla, diferentes clientes fallan de manera diferente. Los clientes de colocación pueden perder energía, refrigeración, acceso de gestión o capacidad de enlace ascendente sin dejar de ser propietarios del equipo. Los clientes de VPS pueden perder servidores virtuales, paneles de control, copias de seguridad o actualizaciones de DNS. Los clientes de servidores dedicados pueden esperar la reparación o sustitución del hardware. Los clientes de dominios y alojamiento pueden experimentar interrupciones en el correo electrónico, el sitio web y la cuenta.
Los clientes que utilizan Cloud9 para migración o soporte gestionado pueden necesitar acción del personal al mismo tiempo que todos los demás piden ayuda.
La localidad tiene dos caras. Un operador georgiano con soporte local puede ser valioso para el idioma, la jurisdicción, el pago, el acceso y el servicio doméstico de baja latencia. También puede crear concentración si muchas pequeñas empresas, desarrolladores y organizaciones georgianas dependen de un edificio en Tiflis y del soporte de un solo proveedor. El impacto de un corte no se mide solo por el recuento total de prefijos o la cuota de tráfico global. Se mide por los clientes que no tienen un segundo sitio, un segundo proveedor y una ruta de exportación probada.
La evidencia de ruta sugiere que Cloud9 tiene una red real más allá de un pequeño stub. El recuento actual de prefijos de AS57814, los vecinos y el soporte IPv6 son significativos. El registro de la instalación Cloud9 Dinamo Arena en PeeringDB añade una capa de interconexión física. La membresía en IXP.ge añade relevancia en el intercambio local. Pero el registro público no muestra los resultados de conmutación por error de los clientes.
No muestra cuántos clientes ejecutan servicios en un solo sitio, cuántos usan copias de seguridad fuera de la instalación, cuántos tienen servicio de doble operador o cuántos conocen la diferencia entre las asignaciones de ancho de banda local y global.
Esa incertidumbre es precisamente la razón por la que el título del artículo asignado es importante. La capacidad de centro de datos comercializada debe sobrevivir a las restricciones de energía y de operadores, no solo describirlas. La historia pública de Cloud9 es lo suficientemente creíble como para merecer escrutinio y lo suficientemente específica como para hacer que el escrutinio sea justo. La prueba faltante no es la identidad. Es la supervivencia probada.
Qué mejoraría la calificación de la evidencia
Cloud9 podría aumentar la confianza sin exponer detalles confidenciales de la instalación. Una página de red pública podría indicar el papel actual de AS203301, el papel activo de AS57814, el conjunto principal de AS, las opciones de BGP para el cliente, la política de seguridad de enrutamiento y la práctica de autorización de rutas.
Una página de instalación podría preservar la seguridad al tiempo que ofrece rangos para el número de armarios activos, la densidad de rack disponible, las densidades de energía admitidas, la autonomía del generador, la redundancia del SAI, la redundancia de refrigeración y los estándares de aviso de mantenimiento. Una página de estado podría separar los servicios de instalación, red, alojamiento, DNS, portal y correo electrónico.
Para la colocación empresarial, la evidencia más valiosa sería específica del cliente. Los compradores deben pedir un resumen reciente de la prueba de carga del generador, evidencia de mantenimiento del SAI, diseño de redundancia de refrigeración, objetivos de respuesta de manos remotas, ejemplos de comunicación de incidentes, evidencia de conmutación por error de ruta, opciones de diversidad de conexiones cruzadas, ubicación de copias de seguridad, evidencia de tiempo de restauración y una declaración clara de qué servicios son de un solo sitio. Si la respuesta varía según el producto, debe variar por escrito.
Un servidor torre, un servidor de 1U con doble alimentación, un rack completo y un VDS gestionado no comparten el mismo perfil de riesgo.
La evidencia actual respalda una calificación Media. AS203301 por sí solo no está activo y debe ser degradado. La operación más amplia de Cloud9 es visible a través de páginas oficiales de la instalación, términos legales, enrutamiento de AS57814, entradas de instalación e intercambio en PeeringDB, membresía en IXP.ge y verificaciones de origen de ruta válidas en prefijos activos.
Las lagunas restantes son las que suelen importar durante un corte: independencia real de la ruta de energía, resistencia del generador, conmutación por error de refrigeración, diversidad física de operadores, impacto del mantenimiento, hardware de repuesto, restauración de copias de seguridad y pruebas de migración de clientes.
La conclusión práctica es directa. Un comprador no debe rechazar a Cloud9 solo porque AS203301 está inactivo. No debe comprar capacidad crítica solo porque el sitio web dice centro de datos neutral con respecto al operador. El movimiento correcto es tratar a Cloud9 como un operador real de centro de datos y alojamiento georgiano cuya evidencia activa se concentra en AS57814 y la instalación de Tiflis, y luego exigir pruebas de que el servicio adquirido sigue funcionando cuando falla una alimentación, una ruta de refrigeración, una ruta de operador, un servidor host o un canal de soporte.