Rackspace IT Hosting AS IT Hosting Provider Hong Kong vende una capacidad hospedada que aún depende de los racks, el tránsito y las ventanas de reparación

Resumen

• Rackspace IT Hosting AS IT Hosting Provider Hong Kong corresponde a AS45187 en los registros públicos de APNIC y RIPEstat. El registro RDAP de APNIC nombra a Rackspace.com Hong Kong Limited como organización titular, y RIPEstat etiqueta al titular como «RACKSPACE-AP - Rackspace IT Hosting AS IT Hosting Provider Hong Kong».
• La superficie de enrutamiento es materialmente visible. La instantánea del estado de enrutamiento de RIPEstat para AS45187 mostraba 13 prefijos IPv4, 2 prefijos IPv6, 66 816 direcciones IPv4, una visibilidad completa de RIS observada para ambas familias de direcciones, y 23 vecinos observados. La vista de los prefijos anunciados listaba los prefijos activos, incluyendo 119.9.64.0/19, 119.9.96.0/19, 120.136.32.0/20, 180.150.128.0/19, 202.168.208.0/21, 203.60.0.0/17, 2401:1800::/32 y 2407:fa00::/32.
• PeeringDB añade un contexto de sitio e interconexión más que una garantía de capacidad. Lista «Rackspace Hong Kong» para AS45187, una política abierta, cuentas de prefijos indicativas de 100 IPv4 y 10 IPv6, dos entradas de intercambio a 10G en Equinix Hong Kong y HKIX, y una entrada de sitio en MEGA-i en Hong Kong.
• Las páginas HKG1 y HKG5 de Rackspace hacen visible la dependencia física. HKG1 se describe en Tsuen Wan con módulos UPS, alimentaciones dobles de 11 kV y componentes de red redundantes; HKG5 se describe en Tseung Kwan O con 917 m² de espacio de centro de datos dedicado, una potencia eléctrica total de 13,5 MW, una capacidad UPS de 7,2 MW, siete operadores de fibra, 10 Gbit/s por operador, optimización de enrutamiento BGP multipath y una separación declarada donde los clientes conservan el control administrativo de los servidores alquilados mientras Rackspace controla el hardware de red.
• El nivel de evidencia es Alto para la identidad de red pública y las pruebas de operación en Hong Kong, pero no es un cheque en blanco para todas las cargas de trabajo hospedadas. Los clientes siempre necesitan pruebas específicas del servicio en cuanto a la ubicación, la redundancia, los tiempos de restauración, la escalada de tickets, las exclusiones de mantenimiento, el acceso a repuestos, el estado RPKI, los límites contractuales y las rutas de salida.

La cuestión ya no es si Rackspace existe en Hong Kong

Algunos perfiles de infraestructura comienzan con un nombre escueto y un ASN débil. No es el caso aquí. El registro público alrededor de Rackspace IT Hosting AS IT Hosting Provider Hong Kong es lo suficientemente denso como para llevar la investigación de la existencia a la dependencia. Elregistro RDAP del sistema autónomode APNIC identifica AS45187 como RACKSPACE-AP, con el país HK y Rackspace.com Hong Kong Limited como organización titular. Lavisión general ASde RIPEstat utiliza la etiqueta de titular «Rackspace IT Hosting AS IT Hosting Provider Hong Kong» y marca el ASN como anunciado. Esta coincidencia es más sólida que una entrada de directorio de hosting recuperada o una página corporativa obsoleta.

Las pruebas de enrutamiento también son lo suficientemente actuales como para importar. Elestado de enrutamientode RIPEstat para AS45187 mostraba visibilidad IPv4 e IPv6 en todos los pares RIS observados en el momento de la instantánea, 13 prefijos IPv4, 2 prefijos IPv6 y 23 vecinos observados. Elconjunto de datos de prefijos anunciadoslistaba 15 líneas de prefijos actuales. Incluyen dos grandes agregados IPv6, 2401:1800::/32 y 2407:fa00::/32, y rutas IPv4 como 119.9.64.0/19, 119.9.96.0/19, 120.136.32.0/20, 122.200.132.0/22, 180.150.128.0/19, 202.168.208.0/21 y 203.60.0.0/17. No es una red de vanidad con un solo prefijo.

Los documentos públicos de los sitios de Rackspace hacen el tema aún menos abstracto. Lapágina del centro de datos HKG1de Rackspace ubica una instalación en Hong Kong en Tsuen Wan y describe la alimentación eléctrica, la refrigeración, la seguridad, la conectividad y las garantías. Supágina HKG5ubica otra instalación en Tseung Kwan O y va más allá, listando 917 m² de espacio de centro de datos dedicado, una potencia eléctrica total de 13,5 MW, una capacidad UPS de 7,2 MW, siete operadores de fibra hasta el sitio y la optimización de enrutamiento BGP multipath. La cuestión de la existencia, por tanto, está suficientemente resuelta para el trabajo de aprovisionamiento. La cuestión abierta es si el servicio hospedado de un cliente particular tiene la misma resiliencia que la huella publicada sugiere.

Esta distinción importa porque «Rackspace» es una gran marca, «Hong Kong» es una etiqueta de mercado, AS45187 es una frontera de red, y una carga de trabajo de un cliente es un despliegue específico del contrato. Un comprador puede ver los recursos de numeración públicos y las afirmaciones de las instalaciones de Rackspace, pero no puede deducir qué sala, qué rack, qué operador, qué VLAN, qué sistema de respaldo, qué equipo de soporte o qué calendario de mantenimiento se aplica a su propio entorno. Una página de instalación bien documentada debería hacer el escrutinio más riguroso, no menos.

AS45187 es una periferia operativa real, pero el registro no muestra todos los servicios

Los registros de APNIC y RIPEstat muestran una identidad coherente. El registro RDAP da una fecha de registro en diciembre de 2014 y una fecha de última modificación en julio de 2020. Lavista derivada del whoisde RIPEstat registra el aut-num como 45187, el as-name como RACKSPACE-AP, la descripción como Rackspace IT Hosting AS IT Hosting Provider Hong Kong, y el país como HK. También muestra antiguas líneas de política de importación y exportación que nombran AS3491, AS1239 y AS2914, así como contactos de mantenimiento de enrutamiento de Rackspace. Estos detalles son útiles porque vinculan el recurso de numeración con la entidad Rackspace de Hong Kong y un antiguo registro de administración de enrutamiento.

Esto no basta para definir el producto. AS45187 puede transportar funciones de nube pública, hosting gestionado, servidor dedicado, colocación, almacenamiento, monitoreo, plano de control, soporte o backbone de varias maneras. Algunos sistemas de clientes pueden estar directamente direccionados desde AS45187. Otros pueden usar direcciones asignadas por el proveedor, interconexiones privadas, direcciones de proveedor de nube, o rutas híbridas que no aparecen como orígenes visibles para el cliente. El registro puede indicar a un comprador dónde buscar.

No puede decirle qué producto exacto usa la periferia de enrutamiento, qué entidad legal firma el contrato o qué proveedor es responsable en un incidente.

Por tanto, la evidencia del titular de APNIC debe leerse como un punto de partida del mapa de responsabilidad. Si se le dice a un cliente que una carga de trabajo en Hong Kong se suministra desde la infraestructura de Rackspace, AS45187 le da al cliente una frontera de red concreta sobre la cual hacer preguntas. ¿Qué prefijos están involucrados? ¿Cuáles son orientados al cliente, solo de gestión, solo de respaldo, o heredados? ¿Qué políticas de enrutamiento están activas, y cuáles son históricas? ¿Qué prefijos tienen una autorización de origen de ruta, y cuáles permanecen desconocidos para los validadores RPKI? No son preguntas académicas.

Determinan si una fuga de ruta, un cambio de filtro, un evento de mitigación de DDoS o una caída de un ascendente puede afectar al servicio.

La primera advertencia concierne a RPKI. La verificación de validación utilizada para este artículo sobre 119.9.64.0/19 a través delpunto de terminación de validación RPKIde RIPEstat devolvió un estatus desconocido en lugar de válido. El mismo estatus apareció para el conjunto de prefijos comprobado de la lista de prefijos anunciados. Desconocido no es lo mismo que inválido, y no significa que la red esté fallando. Significa que la autorización de origen de ruta debería ser una pregunta de aprovisionamiento activa, porque las redes que aplican la validación de origen de ruta tratan de forma diferente las rutas válidas, inválidas y desconocidas. Para un cliente que depende de una periferia estable en Hong Kong, «desconocido» debería conducir a una discusión sobre los ROA, los filtros de ruta, los procedimientos de contacto y la propiedad del control de cambios.

Rackspace publica dos tipos diferentes de evidencias de instalaciones en Hong Kong

Las páginas de instalaciones de Rackspace en Hong Kong son inusualmente concretas en comparación con muchos perfiles de hosting regionales. HKG1, descrita enRackspace Technology Data Centers: Hong Kong (HKG1), se encuentra en Tsuen Wan. La página indica que las instalaciones de Hong Kong cuentan con profesionales de ingeniería de sistemas que gestionan y mantienen los sistemas 24 horas al día, 7 días a la semana, 365 días al año. Las afirmaciones físicas listadas para HKG1 incluyen módulos UPS de 400 KVA en configuración N+1, 30 minutos de autonomía de batería, alimentación eléctrica dual de 11 kV procedente de subestaciones separadas de HKE, conductos de alimentación dobles, múltiples generadores y una instalación neutral respecto al operador alimentada por conexiones duales de telecomunicaciones.

HKG5, descrita enRackspace Technology Data Centers: Hong Kong (HKG5), se encuentra en Tseung Kwan O y expone un conjunto diferente de especificidades. Lista 917 m² de espacio de centro de datos dedicado, una potencia eléctrica total de 13,5 MW, una capacidad UPS de 7,2 MW, generadores diésel con una capacidad de 2,25 MW cada uno, depósitos de combustible de 12 000 litros, más de 1 MW de capacidad de refrigeración, siete operadores que proporcionan conectividad de fibra al sitio, 10 Gigabit Ethernet por operador, routers Cisco y Arista redundantes, y optimización de enrutamiento BGP multipath. También indica que los clientes conservan el control administrativo de los servidores alquilados mientras Rackspace conserva el control del hardware de red.

Estas afirmaciones tienen un significado operativo. Dicen que Rackspace no se limita a revender una región de nube anónima bajo una etiqueta de Hong Kong. Indican una instalación física, un diseño de red, personal de soporte y límites de control. Pero aún deben convertirse en evidencias específicas del servicio. «HKG5 tiene siete operadores» no prueba por sí mismo que cada servicio del cliente disponga de siete rutas activas, capaces por defecto, pagadas y aprovisionadas. «Optimización de enrutamiento BGP multipath» no prueba la diversidad de rutas hasta la aplicación, el nivel de almacenamiento o la consola de gestión del cliente.

«Los clientes conservan el control administrativo» no prueba que un cliente pueda recuperar el servicio si el hardware de red, el portal, la cola de soporte o el estado de facturación bloquean el acceso.

Las páginas de instalaciones son más sólidas donde nombran las entradas físicas. Las alimentaciones eléctricas, la capacidad UPS, el combustible de los generadores, el número de operadores y las familias de routers son todas cosas reales que un comprador puede pedir ver en un diseño de servicio. Las páginas son más débiles donde son necesariamente generales. No publican las asignaciones de racks, la ubicación de los clientes, los paneles de conexión, los mapas de VLAN privadas, la topología de almacenamiento, la geografía de los respaldos, los armarios de repuestos o la profundidad de la cola de técnicos que se llamarían durante un incidente.

La tarea de aprovisionamiento consiste en cerrar esa brecha sin pretender que la página de instalación pública ya lo haya hecho.

PeeringDB confirma las señales de interconexión, no la ubicación de los clientes

LaAPI de red de PeeringDB para ASN 45187lista un objeto de red llamado Rackspace Hong Kong. Los campos muestran una política general abierta, un conjunto AS IRR de AS-RACKSPACE, cuentas de prefijos indicativas de 100 IPv4 y 10 IPv6, soporte IPv6, un recuento IX de 2 y un recuento de instalaciones de 1. PeeringDB es un directorio voluntario, por lo que ninguno de estos campos constituye una certificación. No obstante, la entrada es valiosa porque vincula AS45187 con una postura de interconexión que se puede comparar con los colectores de rutas y las declaraciones de instalaciones de Rackspace.

Losregistros netixlan de PeeringDBlistan dos entradas operativas orientadas al intercambio: Equinix Hong Kong y HKIX: HKIX Peering LAN. Ambas muestran una velocidad de 10 000 Mbit/s. La línea de Equinix Hong Kong lista la dirección IPv4 36.255.56.87 y la dirección IPv6 2001:de8:7::4:5187:2. La línea de HKIX lista la dirección IPv4 123.255.90.101 y la dirección IPv6 2001:7fa:0:1::ca28:a065. Elregistro netfac de PeeringDBlista MEGA-i (iAdvantage Hong Kong) en Hong Kong como entrada de instalación para el objeto de red.

Estas líneas crean una tensión útil con las páginas HKG1 y HKG5 de Rackspace. Rackspace publica páginas de instalaciones para Tsuen Wan y Tseung Kwan O, mientras que PeeringDB expone una entrada de instalación de red en MEGA-i y conexiones de intercambio en Equinix Hong Kong y HKIX. No hay contradicción a menos que alguien intente hacer que un solo registro diga más de lo que puede. PeeringDB puede describir una presencia de interconexión más que la ubicación de cálculo de los clientes. Las páginas de centros de datos de Rackspace pueden describir instalaciones de hosting más que cada ubicación de intercambio o interconexión.

Un cliente necesita el mapa que vincule estas capas: dónde está el servidor, dónde está el router de borde, dónde ocurre el peering de intercambio, por dónde entra el tránsito, y dónde tiene el cliente derechos contractuales.

La lección operativa inmediata es que el recuento de instalaciones no equivale a la redundancia. Una línea de instalación de PeeringDB puede coexistir con múltiples sitios operados o comercializados por Rackspace. Dos puertos orientados al intercambio pueden mejorar la accesibilidad a redes seleccionadas sin probar una diversidad de tránsito completa.

Un puerto de intercambio de 10G puede ser útil para el peering, pero el camino de supervivencia del cliente durante una caída puede depender del tránsito de pago, la interconexión privada, el DNS, el filtrado de seguridad, los balanceadores de carga, la replicación del almacenamiento y el acceso al soporte. El registro de interconexión pública da al comprador nombres y direcciones para probar, no un resultado de conmutación por error de extremo a extremo.

La superficie de enrutamiento es amplia, pero la diversidad aún debe probarse dos veces

AS45187 tiene un conjunto de vecinos visible. Elpunto de terminación ASN-neighboursde RIPEstat devolvió 23 vecinos observados. La lista incluía grandes redes mundiales como AS174, AS3257, AS3300, AS3491, AS4637, AS6453, AS6939 y AS7473 en el lateral izquierdo, una línea derecha para AS58982, y varias líneas inciertas. El BGP público no puede decir si cada adyacencia es un ascendente de pago, un par, un cliente, una relación de servidor de ruta de intercambio, un artefacto temporal de fuga de ruta o un artefacto de clasificación del lado del colector. Solo puede decirnos que la periferia de enrutamiento no es invisible.

Las antiguas líneas de política whois de APNIC añaden otra capa. Listan importaciones desde AS3491, AS1239 y AS2914 y exportaciones hacia esos AS. Es una evidencia histórica útil de administración de enrutamiento, pero no describe automáticamente la ingeniería de tráfico actual. La lista de vecinos actual de RIPEstat incluye indirectamente algunos de esos nombres y también muestra otros. Un comprador debería preguntar a Rackspace por el diseño actual de tránsito y peering en lugar de confiar en el texto estático de la política whois.

La diversidad debe probarse dos veces: una en el enrutamiento, y una en las operaciones físicas. Una red puede tener varios vecinos BGP en los datos públicos mientras que varias rutas comparten el mismo edificio, la misma sala de reunión, el mismo dominio de alimentación, el mismo conducto de fibra, el mismo par de routers o la misma cola de soporte. Inversamente, un servicio puede tener una fuerte resiliencia privada o del lado del proveedor que apenas es visible en el BGP público. El objetivo no es castigar a Rackspace por ocultar detalles operativos; es evitar confundir un grafo AS público con un diseño de recuperación del cliente probado.

Las mejores preguntas son específicas de la capa. ¿Qué prefijos de AS45187 se originan en qué routers de borde en Hong Kong? ¿Qué ascendentes transportan las rutas por defecto para el servicio en funcionamiento normal? ¿Qué sesiones de intercambio son de peering gratuito frente a accesibilidad crítica? ¿Qué rutas están diversificadas a nivel de entrada de fibra y edificio? ¿Cuánto tráfico puede transportar la ruta restante en hora punta tras la eliminación de un proveedor, un intercambio, un router o un dominio de instalación? El BGP público puede sugerir dónde hacer preguntas. No puede responder a todo eso por sí solo.

Rackspace vende abstracción, pero la economía de Hong Kong sigue siendo física

Lapágina de hosting gestionadode Rackspace presenta el producto en el lenguaje familiar de las empresas: hosting dedicado gestionado, infraestructura dedicada de inquilino único, bare metal, bases de datos, redes, almacenamiento, copia de seguridad gestionada, recuperación ante desastres, RackConnect y nube privada. La promesa comercial es que Rackspace convertirá la complejidad física en un servicio. Los clientes compran el rendimiento, el soporte y el control sin poseer cada router, alimentación, armario de almacenamiento, interconexión y proceso de mantenimiento.

Ese intercambio tiene un valor real, pero no borra la economía subyacente. Laguía de colocación del clientede Rackspace describe una facturación asignada por kilovatio para la alimentación crítica redundante reservada, con costes mensuales recurrentes separados para las interconexiones y el ancho de banda mixto cuando se compra. También hace referencia a las tarifas de instalación únicas, los circuitos de alimentación, las jaulas privadas, las PDU en rack y las interconexiones. Este es el vocabulario de la capacidad física. La factura de la nube sigue dependiendo de la asignación de energía, el espacio en rack, las ópticas, las manos remotas, los compromisos de ancho de banda y la mano de obra.

Las páginas de Hong Kong lo hacen visible. La afirmación de 13,5 MW de potencia eléctrica de HKG5, su capacidad UPS de 7,2 MW y sus siete operadores de fibra no son decoración de marketing. Son entradas de capacidad que pueden limitar o proteger a un cliente. Si la densidad de rack aumenta, si un cliente necesita más interconexiones, si un router de repuesto no está disponible, si una ruta de operador está congestionada, o si una ventana de mantenimiento requiere un trabajo en serie, el cliente siente el estado físico a través de la latencia, el retraso del ticket, los límites de migración o los créditos tras una caída.

La capacidad hospedada se compra como un servicio, pero falla como una cadena de pasos físicos y administrativos.

Por eso hay que separar la capacidad «instalada» de la capacidad «utilizable». La capacidad instalada es lo que la huella publicada parece incluir: instalaciones, generadores, sistemas UPS, conexiones de operadores, routers, prefijos y personal de soporte. La capacidad utilizable es lo que queda para un cliente después de tener en cuenta las reservas normales, el overbooking, el mantenimiento, el enrutamiento específico del cliente y los dominios de protección. La capacidad recuperable es aún más estrecha: la parte que se puede restaurar en el plazo requerido por el cliente tras el fallo de un componente.

Las páginas públicas son buenas para la capacidad instalada. La garantía del cliente debe probar la capacidad utilizable y recuperable.

El control está dividido por diseño

La línea más importante de HKG5 quizás no sea la de los megavatios o el número de operadores. La página indica que los clientes conservan el control administrativo de los servidores alquilados mientras Rackspace conserva el control del hardware de red. Esta separación es exactamente lo que un cliente de hosting gestionado desea en funcionamiento normal: el cliente puede gestionar su carga de trabajo, mientras que el proveedor protege la capa de red compartida. En caso de fallo, la misma separación se convierte en una frontera que debe ser recorrida.

Si un servidor alquilado está sano pero inaccesible, los derechos administrativos del cliente pueden no ser suficientes. Si un cliente puede conectarse a un servidor a través de una VPN pero no puede alcanzar el servicio público, la frontera de red importa. Si un cliente necesita un cambio de ruta, una regla de firewall, un ticket de interconexión o un reemplazo de hardware, la autoridad y la cola de Rackspace se convierten en el elemento limitante. Si el cliente tiene una copia de seguridad pero no puede mover suficientes datos a través de la ruta disponible, el control a nivel de servidor es insuficiente.

La responsabilidad compartida no es aquí un eslogan; es la arquitectura operativa.

La guía de colocación de Rackspace refuerza la misma frontera. Describe los responsables de implementación, la formación en el portal del cliente, las solicitudes de manos remotas, la creación automática de tickets, los monitores de alerta y un runbook. Indica que los clientes pueden interactuar creando tickets a través del portal de clientes de Rackspace y pueden llamar al equipo de soporte 24 horas al día, 7 días a la semana, 365 días al año.

También lista tareas de manos remotas como el ciclo de alimentación de dispositivos, la comprobación visual, la prueba de cables, el reemplazo de hardware suministrado por el cliente, el montaje y desmontaje en rack, el cableado de red en rack y la destrucción del disco duro. Estas son las acciones concretas que convierten la detección de fallos en reparación.

Para un comprador, la pregunta sobre el control es simple: ¿qué podemos hacer sin Rackspace, qué puede hacer Rackspace sin nosotros, y qué requiere que ambas partes actúen en el orden correcto? Esta pregunta debería responderse antes de la puesta en producción. Debería escribirse en pasos operativos, no solo en lenguaje contractual. ¿Qué usuarios del portal tienen autoridad? ¿Qué número de teléfono funciona si el portal no está disponible? ¿Qué cambios de ruta requieren un ticket? ¿Qué acciones de hardware están incluidas? ¿Qué tareas se facturan en incrementos de 15 minutos?

¿Qué tareas dependen de piezas suministradas por el cliente en lugar de Rackspace?

Las ventanas de reparación son una característica del producto, no una nota al pie

Las páginas de centros de datos de Rackspace publican garantías sólidas, pero los detalles importan. HKG1 y HKG5 incluyen ambas una redacción de garantía para la red, la infraestructura y el reemplazo de hardware. Las secciones de red e infraestructura hablan en términos de disponibilidad y créditos, mientras que la garantía de reemplazo de hardware indica que el reemplazo o reparación del hardware o los componentes suministrados por Rackspace comenzará en el plazo de una hora desde la identificación del problema, con créditos si no es así. El término «comenzar» es importante.

No es lo mismo que «terminar», y no describe todos los componentes suministrados por el cliente.

La tabla de manos remotas de la guía de colocación es más granular desde el punto de vista operativo. Muestra que HKG1 tiene tanto un SLA de respuesta de 1 hora como un SLA de ejecución de 24 horas para manos remotas. La misma guía da tiempos estimados para tareas comunes, como 30 minutos para el ciclo de alimentación de un router, servidor o switch, 60 minutos por cada tres cables para la prueba de soporte de cableado, y 60 minutos para el reemplazo de un dispositivo suministrado por el cliente que no es reemplazable en caliente. Lista una tarifa de manos remotas de 46,25 $ US por incremento de 15 minutos más la lista de materiales.

No son detalles triviales. Muestran dónde el reloj de reparación puede pasar de un tiempo de actividad abstracto a un trabajo humano pagado.

Un cliente debería, por tanto, separar tres relojes. El tiempo de detección es el tiempo que tarda la monitorización en notar y clasificar un fallo. El tiempo de respuesta es el tiempo que tardan Rackspace o el cliente en aceptar la propiedad y comenzar la acción. El tiempo de ejecución es el tiempo que tarda realmente la reparación, incluidas las piezas, el acceso, el cableado, el reinicio, el cambio de ruta, la reconstrucción del almacenamiento y la verificación. Los créditos tras una caída son comercialmente importantes, pero no restauran la carga de trabajo.

El examen de la resiliencia debería centrarse en la restauración medida, no solo en los créditos de servicio.

La misma lógica se aplica al mantenimiento. Las redacciones de garantía de Rackspace excluyen el mantenimiento programado o de emergencia. Esta exclusión es normal, pero importa en un examen de capacidad hospedada. Si una ruta o un sitio no está disponible por mantenimiento, la resiliencia real del cliente es la capacidad restante en la ruta sin mantenimiento. Si un cliente necesita un cambio durante una congelación de mantenimiento del proveedor, las reglas de escalada importan. Si un evento de mantenimiento de emergencia afecta a un componente de red compartido, los derechos administrativos del cliente pueden no ayudar.

Las ventanas de reparación y las ventanas de mantenimiento son parte del producto, no del papeleo anexo.

La seguridad del origen de ruta es el punto débil de una huella pública por lo demás sólida

La degradación más obvia en la evidencia de red es el estado RPKI. RIPEstat informó claramente de la superficie de enrutamiento, y PeeringDB dio detalles de interconexión, pero las verificaciones de validación RPKI frente a la lista de prefijos actuales devolvieron un estado desconocido en lugar de válido en el muestreo utilizado aquí. El estado desconocido puede existir por muchas razones, incluyendo la ausencia de ROA, la cobertura de los validadores, el tiempo o las elecciones de gestión de recursos. No significa que AS45187 esté secuestrando rutas.

Significa que la capa de autorización de origen no es tan sólida públicamente como la capa de visibilidad BGP.

Para un cliente hospedado, esto importa porque la validación de origen ya no es exótica. El RFC 6811 describe la validación de origen de ruta como un medio para utilizar la infraestructura de clave pública de recursos para determinar si un AS está autorizado a originar un prefijo. El propio material RPKI de APNIC explica el control de certificación de recursos en términos operativos. Un cliente que depende de la accesibilidad pública debería preocuparse por si los prefijos de producción de su proveedor son válidos, desconocidos o inválidos, y si los prefijos enrutados por el cliente tienen ROA correctos antes de la migración.

La pregunta práctica no es «¿Conoce Rackspace el BGP?». El conjunto de vecinos públicos y las afirmaciones sobre las instalaciones sugieren operaciones de enrutamiento maduras. La pregunta es más estrecha: para los prefijos exactos que transportan el servicio del cliente, ¿están publicadas y probadas con los validadores principales las autorizaciones de origen de ruta? Si el cliente trae su propio espacio de direccionamiento, ¿quién crea y mantiene los ROA? Si Rackspace asigna el espacio de direccionamiento, ¿puede Rackspace mostrar el estado y el proceso de control de cambios?

Si un prefijo debe moverse durante un incidente, ¿qué sucede con el estado del ROA y el filtro?

Este es uno de los pocos controles públicos donde la respuesta se puede mejorar sin revelar detalles privados de las instalaciones. Un ROA válido no prueba la resiliencia del cliente, pero elimina un modo de fallo evitable. Una ruta desconocida puede seguir funcionando en la mayoría de las redes; simplemente da al comprador menos seguridad a nivel de validación de origen. En un dossier de Rackspace Hong Kong por lo demás sólido, este es exactamente el tipo de pregunta específica y reparable que no debería perderse bajo el peso de una gran marca.

La localización de los datos no se resuelve con las letras HK

La región de la asignación es HK, APNIC lista AS45187 con el país HK, Rackspace publica instalaciones en Hong Kong, y el registro de PeeringDB describe una interconexión en Hong Kong. Estas son buenas señales de localización. Sin embargo, no prueban dónde se encuentran los datos, las copias de seguridad, los registros, los registros de soporte, el sistema de identidad, las instantáneas o las copias de recuperación de un cliente. En los contratos de nube y hosting gestionado, la localización es una matriz de ubicación, no un código de país.

El regulador de privacidad de Hong Kong subraya este punto en sus orientaciones públicas. LaGuía sobre computación en la nubedel PCPD de enero de 2025 indica a los usuarios de datos que tengan en cuenta la ubicación de almacenamiento de los datos, las medidas de seguridad en los equipos, la integridad y competencia de las personas que acceden a ellos, la transmisión segura, los contratos con los subcontratistas, los controles de conservación y las implicaciones de las transferencias transfronterizas. Unanota de caso del PCPD sobre sistemas en la nube fuera de Hong Kongindica que la ordenanza no prohíbe el almacenamiento de datos personales en un sistema en la nube fuera de Hong Kong, pero que los usuarios de datos deben cumplir igualmente con la PDPO y los principios de protección de datos. Lascláusulas contractuales modelo recomendadasdel PCPD proporcionan un marco contractual para las transferencias transfronterizas.

Para los clientes de Rackspace en Hong Kong, la consecuencia es práctica. El cliente debería preguntar dónde se almacenan los datos primarios, dónde se almacenan las instantáneas, dónde se almacenan las copias de seguridad, dónde se almacenan los registros de gestión, qué equipos de soporte pueden acceder al entorno, qué subcontratistas o nubes asociadas participan, y si una acción de soporte normal transfiere datos personales fuera de Hong Kong.

Una periferia de enrutamiento en Hong Kong puede coexistir con herramientas de soporte no hongkonesas, sistemas de identidad globales, copias de seguridad en el extranjero o interconexiones multinube. Nada de esto es necesariamente inapropiado. Simplemente debe ser divulgado y probado frente a las propias obligaciones regulatorias del cliente.

La localización también interactúa con la recuperación. Una copia de seguridad fuera de Hong Kong puede mejorar la resiliencia pero modificar el análisis de transferencia. Una copia de seguridad solo local puede satisfacer una preferencia de residencia pero fallar si la instalación local sufre un evento regional. Un diseño multisitio en Hong Kong puede ser mejor para la latencia y la jurisdicción pero más costoso y aún dependiente de proveedores comunes. El comprador necesita el diseño, no el eslogan.

Las pruebas de salida forman parte de la resiliencia

Un servicio hospedado no es completamente resiliente hasta que el cliente puede salir de él bajo presión. La documentación de Rackspace contiene indicios útiles de que ciertos servicios exponen rutas de exportación y migración. El manual de Rackspace Cloud sobre OpenStack Flex hace referencia a funciones de creación de máquinas virtuales, almacenamiento en bloque, almacenamiento de objetos, exportación de imágenes, importación de imágenes y planificación de migración. Laguía de exportación de imágenesdescribe la exportación de instantáneas de instancia desde un proyecto OpenStack Flex. Laguía de la API de Object Storageexplica que el acceso requiere credenciales de Rackspace Cloud, detalles del proyecto y llamadas a la API.

Estos documentos no prueban que cada cliente de hosting gestionado en Hong Kong pueda realizar una salida de emergencia completa. Prueban que la salida debería discutirse a nivel de artefactos. ¿Puede el cliente exportar imágenes de VM? ¿Puede exportar volúmenes en bloque? ¿Son portables las copias de seguridad? ¿Se pueden exportar las configuraciones de red, las reglas de firewall, los parámetros del balanceador de carga, las zonas DNS, los certificados, los registros y el historial de monitorización? ¿Funciona la exportación si el portal del cliente está degradado? ¿Requiere un compromiso de soporte de pago?

¿Se puede probar sin desencadenar un cambio en producción?

La capa física reaparece en la salida. Las exportaciones voluminosas consumen ancho de banda y tiempo. La facturación de las interconexiones, los límites de tránsito, las tasas de lectura del almacenamiento, las credenciales de almacenamiento de objetos y los tickets de soporte son todos parte de la ruta de migración. Un cliente que nunca ha medido una exportación completa puede descubrir durante un incidente que «podemos mudarnos» significa en realidad «podemos comenzar una larga transferencia después de que el proveedor haya aprobado la solicitud». La planificación de la salida no es una hostilidad hacia Rackspace.

Es el final honesto de un examen de dependencia.

La infraestructura publicada de Rackspace es lo suficientemente sólida como para que muchos clientes elijan racionalmente no gestionar una infraestructura equivalente por sí mismos. Ese es el interés económico del hosting gestionado. El peligro no es usar un proveedor; es usar uno sin preservar las pruebas necesarias para mudarse, restaurar o verificar de forma independiente el servicio cuando algo va mal.

El envoltorio corporativo es útil, pero la prueba local siempre prevalece

El dossier corporativo más amplio de Rackspace Technology ayuda a explicar por qué este perfil de Hong Kong no debería tratarse como un pequeño proveedor de hosting regional. Rackspace Technology, Inc. aparece en las presentaciones ante la SEC como una empresa que cotiza en el Nasdaq bajo el símbolo RXT, y suformulario 10-K 2025proporciona a los inversores el contexto comercial y de riesgo más amplio en torno a sus operaciones de nube, hosting y servicios. Lapágina mundial de centros de datosde Rackspace presenta una huella de centros de datos multimercado e indica que sus instalaciones utilizan redundancia en los ámbitos de la seguridad, la alimentación, la refrigeración y las redes. Estos hechos reducen la incertidumbre sobre la identidad y hacen que las páginas de instalaciones de Hong Kong sean más creíbles de lo que sería una página de aterrizaje independiente.

No eliminan la necesidad de pruebas locales. Una empresa mundial aún puede tener una restricción de instalación local, una dependencia de un proveedor regional, una ruta de depreciación específica del producto, un nivel de soporte específico del cliente o un diseño de nube privada que difiera de la página de instalación pública. El 10-K también está redactado para inversores, no para un cliente de Hong Kong que intenta saber qué rack, qué ruta, qué sistema de copia de seguridad y qué ingeniero decidirán una caída un sábado.

La divulgación de una empresa pública puede describir los riesgos comerciales, los segmentos de ingresos, la deuda, la competencia y las hipótesis de explotación. No puede certificar la ruta de recuperación de una carga de trabajo particular en AS45187.

Este envoltorio corporativo cambia el método de aseguramiento. Con un pequeño proveedor desconocido, la primera tarea podría ser probar que la empresa y la red existen. Con Rackspace Hong Kong, la primera tarea es alinear múltiples capas públicas que son cada una reales: la identidad AS45187 de APNIC, las pruebas de enrutamiento actuales de RIPEstat, las líneas de interconexión de PeeringDB, las páginas de instalaciones HKG1 y HKG5 de Rackspace, la documentación de hosting gestionado y colocación de Rackspace, y el propio contrato del cliente. El riesgo no es que cada capa sea falsa.

El riesgo es que un cliente suponga que todas las capas se aplican a su servicio de la misma manera.

El comprador debería, por tanto, pedir a Rackspace que produzca un anexo de servicio local. Debería nombrar la instalación o instalaciones, los ASN y prefijos relevantes, el sitio de recuperación, la ubicación de la copia de seguridad, el modelo de soporte, las exclusiones de mantenimiento, el plan RPKI, los controles de localización de datos y el proceso de salida. Una marca mundial puede hacer que este anexo sea más fácil de obtener. No puede reemplazar el anexo.

Lo que los clientes deberían probar antes de confiar en la periferia de Hong Kong

La primera prueba es la cartografía. Pida a Rackspace que mapee el servicio hacia AS45187, la instalación o instalaciones, los prefijos de producción, las rutas de gestión, las rutas de copia de seguridad y los sistemas de soporte. Compare la respuesta sobre el ASN con el RDAP de APNIC, los prefijos anunciados de RIPEstat, el registro de Rackspace Hong Kong de PeeringDB y las páginas HKG1/HKG5 de Rackspace. Si el servicio del cliente no utiliza AS45187, puede ser aceptable, pero debería indicarse claramente.

La segunda prueba es el fallo. Elimine un ascendente, una ruta de intercambio, un router, un componente de almacenamiento, un portal de soporte, una credencial de cliente y un dominio de mantenimiento en un ejercicio sobre mesa o en vivo. Registre lo que sucede con la accesibilidad, el acceso a la consola, el DNS, la monitorización, la copia de seguridad, la facturación, los tickets y la exportación de datos. El resultado debería identificar qué parte del servicio es activo-activo, activo-pasivo, solo de copia de seguridad o manual.

La tercera prueba es la seguridad del enrutamiento. Pregunte por el estado RPKI en los prefijos de producción exactos, incluidos los prefijos propiedad del cliente. Pregunte cómo se modifican los ROA durante la migración y quién aprueba el cambio. Pregunte si se mantienen filtros de ruta para AS45187 y los anuncios del cliente. El estado RPKI público desconocido no debería tratarse como un escándalo; debería tratarse como un elemento de control abierto.

La cuarta prueba es el soporte y la reparación. Utilice el vocabulario de las manos remotas de la guía de colocación para hacer el ejercicio concreto. ¿Quién abre el ticket? ¿A quién se puede llamar si el portal se cae? ¿Qué tareas están incluidas, facturadas o excluidas? ¿Qué repuestos son suministrados por Rackspace, por el cliente o por el proveedor? ¿Qué SLA de manos remotas de HKG1 se aplica, y cuál es el equivalente para el servicio exacto de HKG5? Si una garantía de reemplazo de hardware comienza en el plazo de una hora desde la identificación del problema, ¿quién identifica el problema y qué marca el inicio?

La quinta prueba es la localización y la salida. Pregunte por la matriz de localización de datos, incluyendo primario, réplica, copia de seguridad, registros, registros de soporte e identidad. Pida pruebas de exportación y una prueba de restauración cronometrada. El material del PCPD explica claramente por qué estas preguntas pertenecen a una discusión sobre la nube en Hong Kong: el cliente sigue siendo responsable del tratamiento de los datos personales incluso cuando utiliza un proveedor o subcontratista de nube.

El nivel de evidencia

Rackspace IT Hosting AS IT Hosting Provider Hong Kong obtiene un nivel de evidencia de red pública Alto. Este nivel refleja la identidad y la visibilidad operativa, no una declaración ilimitada sobre todos los servicios de Rackspace. APNIC vincula AS45187 a Rackspace.com Hong Kong Limited. RIPEstat muestra AS45187 como anunciado, con 13 prefijos IPv4, 2 prefijos IPv6, una visibilidad RIS completa observada en la instantánea verificada y 23 vecinos observados. PeeringDB lista Rackspace Hong Kong con dos entradas 10G orientadas al intercambio y una línea de instalación en Hong Kong.

Rackspace publica las páginas HKG1 y HKG5 con afirmaciones concretas sobre las instalaciones, la alimentación, los operadores, la red y el soporte.

El nivel no es más alto porque las pruebas públicas siempre se detienen en la frontera del cliente. No revelan la asignación de rack de un cliente, el número de servidores, la potencia reservada, la topología de almacenamiento, la geografía de las copias de seguridad, el inventario de repuestos, la cola de soporte, las exclusiones contractuales, el calendario de mantenimiento o el tiempo de salida probado. También dejan la autorización de origen de ruta como una cuestión abierta porque los prefijos actuales muestreados devolvieron un estado RPKI desconocido en lugar de válido.

La conclusión práctica es estrecha y útil: no se trata de una huella de hosting ligera en Hong Kong. Es una presencia de red y de instalaciones de Rackspace real y bien documentada que aún requiere una garantía específica del servicio. Los clientes no deberían descartarla como inverificable. Tampoco deberían dejar que el nombre de Rackspace, dos páginas de centro de datos en Hong Kong, o la superficie de ruta visible de AS45187 sustituyan las pruebas de fallo que realmente protegen una carga de trabajo.

Quién siente el fallo

Las personas que sienten primero un fallo de AS45187 o de una instalación de Hong Kong pueden ser los propietarios de aplicaciones, los operadores revendedores, los equipos de tecnología financiera, los administradores de SaaS, los minoristas en línea, los propietarios de bases de datos, los responsables de cumplimiento o los ingenieros de red que intentan mantener accesibles los servicios a los clientes.

El efecto en cascada puede pasar rápidamente de la pérdida de paquetes a la pérdida de ingresos, de una alerta de almacenamiento a una obligación regulatoria incumplida, de una caída del portal a una migración retrasada, o de una disputa de facturación a un bloqueo administrativo.

La escala de Rackspace puede reducir algunos riesgos. Cuenta con operaciones de centros de datos mundiales, SLA publicados, instalaciones nombradas en Hong Kong, un lenguaje de soporte maduro y una interconexión visible. La escala también puede ocultar una dependencia específica del cliente. Un gran proveedor puede tener muchas rutas, pero el cliente sigue dependiendo de su propio diseño de servicio. Un gran proveedor puede publicar garantías de reemplazo de hardware, pero el cliente aún necesita saber si la pieza que falla es suministrada por Rackspace, por el cliente o controlada por otro proveedor.

Un gran proveedor puede tener ingenieros globales, pero el cliente aún necesita una ruta de escalada local y contractual.

Por eso este artículo trata a Rackspace Hong Kong como una dependencia que debe entenderse y no como un misterio que resolver. Las pruebas públicas son buenas. La infraestructura física está nombrada. La red es visible. El registro de interconexión tiene detalles útiles. El trabajo restante consiste en probar cómo se comportan estos hechos cuando una carga de trabajo real pierde un rack, un ascendente, un componente de hardware, una ruta de soporte, una autorización de facturación, una ventana de mantenimiento o una ruta de migración. La capacidad hospedada es tan resiliente como la evidencia detrás de esas respuestas.