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 la 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 mostró 13 prefijos IPv4, 2 prefijos IPv6, 66,816 direcciones IPv4, visibilidad completa de RIS observada para ambas familias de direcciones y 23 vecinos observados. La vista de prefijos anunciados listó prefijos activos que incluyen 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 contexto de sitio e interconexión más que una garantía de capacidad. Lista "Rackspace Hong Kong" para AS45187, una política abierta, recuentos indicativos de prefijos de 100 IPv4 y 10 IPv6, dos entradas de intercambio de 10G en Equinix Hong Kong y HKIX, y una entrada de instalación 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, alimentación dual de 11 kV y componentes de red redundantes; HKG5 se describe en Tseung Kwan O con 917 m² de espacio dedicado de centro de datos, una potencia eléctrica total de 13,5 MW, capacidad UPS de 7,2 MW, siete operadores de fibra, 10 Gbit/s por operador, optimización de rutas BGP multipath y una separación declarada donde los clientes retienen el control administrativo de los servidores arrendados mientras Rackspace controla el hardware de red.
  • El nivel de evidencia es Alto para la identidad de red pública y la evidencia operativa en Hong Kong, pero no es un cheque en blanco para todas las cargas de trabajo alojadas. Los clientes aún necesitan evidencia específica del servicio con respecto a la ubicación, redundancia, tiempos de restauración, escalado de tickets, exclusiones de mantenimiento, acceso a repuestos, estado de RPKI, límites contractuales y rutas de salida.

La pregunta útil ya no es si Rackspace existe en Hong Kong

Algunos perfiles de infraestructura comienzan con un nombre débil y un ASN débil. Ese no es el caso aquí. El registro público en torno a Rackspace IT Hosting AS IT Hosting Provider Hong Kong es lo suficientemente sólido como para cambiar la investigación de la existencia a la dependencia. Elregistro RDAP del sistema autónomode APNIC identifica a AS45187 como RACKSPACE-AP, con país HK y Rackspace.com Hong Kong Limited como organización titular. Lavisión general del ASde RIPEstat utiliza la etiqueta del titular "Rackspace IT Hosting AS IT Hosting Provider Hong Kong" y marca el ASN como anunciado. Esta combinación es más sólida que una entrada de directorio de hosting extraída o una página corporativa desactualizada.

La evidencia de enrutamiento también es lo suficientemente actual como para importar. Elestado de enrutamientode RIPEstat para AS45187 mostró 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 anunciadoslistó 15 líneas de prefijos actuales. Estas 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. Esta no es una red de vanidad de un solo prefijo.

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

Esta distinción es importante porque "Rackspace" es una gran marca, "Hong Kong" es una etiqueta de mercado, AS45187 es un borde de red y una carga de trabajo de cliente es un despliegue específico del contrato. Un comprador puede ver los recursos numéricos públicos y las afirmaciones de Rackspace sobre sus instalaciones, pero no puede inferir qué sala, qué rack, qué operador, qué VLAN, qué sistema de respaldo, qué equipo de soporte o qué programa de mantenimiento se aplica a su propio entorno. Una página de instalaciones bien documentada debería hacer que el escrutinio sea más estricto, no menos riguroso.

AS45187 es un borde operativo real, pero el registro no muestra todos los servicios

Los registros de APNIC y RIPEstat muestran una identidad coherente. El registro RDAP proporciona una fecha de registro de diciembre de 2014 y una fecha de último cambio de julio de 2020. Lavista derivada de 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 líneas históricas de política de importación y exportación que nombran a AS3491, AS1239 y AS2914, así como contactos de mantenedor de enrutamiento de Rackspace. Estos detalles son útiles porque vinculan el recurso numérico con la entidad de Rackspace en Hong Kong y con un registro de administración de enrutamiento de larga data.

Eso no es suficiente 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 diferentes maneras. Algunos sistemas de clientes pueden estar direccionados directamente desde AS45187. Otros pueden usar direcciones asignadas por el proveedor, interconexiones privadas, direcciones de proveedores de nube o rutas híbridas que no aparecen como orígenes visibles para el cliente. El registro puede decirle a un comprador dónde buscar.

No puede decirle qué producto exacto utiliza el borde de enrutamiento, qué entidad legal firma el contrato o qué proveedor es responsable de un incidente.

Por lo tanto, la evidencia del titular de APNIC debe leerse como un punto de partida para el mapa de responsabilidad. Si se le dice a un cliente que una carga de trabajo en Hong Kong se entrega desde la infraestructura de Rackspace, AS45187 le proporciona al cliente un borde de red concreto sobre el 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 de RPKI?

Estas no son preguntas académicas. Determinan si una fuga de ruta, un cambio de filtro, un evento de mitigación de DDoS o una interrupción del proveedor ascendente pueden afectar el servicio.

La primera advertencia se refiere a RPKI. La verificación de validación utilizada para este artículo en 119.9.64.0/19 a través delpunto final de validación RPKIde RIPEstat devolvió un estado desconocido en lugar de válido. El mismo estado apareció para el conjunto de prefijos verificado 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 activa de aprovisionamiento, porque las redes que aplican la validación de origen de ruta tratan las rutas válidas, inválidas y desconocidas de manera diferente. Para un cliente que depende de un borde estable en Hong Kong, "desconocido" debería llevar a una discusión sobre ROA, filtros de ruta, procedimientos de contacto y propiedad del control de cambios.

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

Las páginas de instalaciones de Rackspace en Hong Kong son inusualmente concretas en comparación con muchos perfiles regionales de hosting. HKG1, descrito enRackspace Technology Data Centers: Hong Kong (HKG1), está ubicado en Tsuen Wan. La página afirma que las instalaciones de Hong Kong cuentan con profesionales de ingeniería de sistemas que gestionan y mantienen los sistemas 24/7/365. 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 dual de 11 kV desde subestaciones HKE separadas, montantes de alimentación duales, múltiples generadores y una instalación neutral de operadores alimentada por conexiones de telecomunicaciones duales.

HKG5, descrito enRackspace Technology Data Centers: Hong Kong (HKG5), está ubicado en Tseung Kwan O y expone un conjunto diferente de especificidades. Lista 917 m² de espacio dedicado de centro de datos, una potencia eléctrica total de 13,5 MW, capacidad UPS de 7,2 MW, generadores diésel con una capacidad de 2,25 MW cada uno, tanques 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, enrutadores Cisco y Arista redundantes y optimización de rutas BGP multipath. También afirma que los clientes retienen el control administrativo de los servidores arrendados mientras Rackspace retiene el control del hardware de red.

Estas afirmaciones tienen significado operativo. Indican 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 evidencia específica del servicio. "HKG5 tiene siete operadores" no prueba por sí mismo que cada servicio del cliente tenga siete rutas activas, predeterminadas, pagadas y aprovisionadas. "Optimización de rutas 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 retienen 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 del generador, los recuentos de operadores y las familias de enrutadores son cosas reales que un comprador puede solicitar ver en un diseño de servicio. Las páginas son más débiles donde son necesariamente genéricas. No publican asignaciones de racks, colocación de clientes, paneles de conexión, mapas de VLAN privadas, topología de almacenamiento, geografía de respaldo, contenedores de repuestos ni la profundidad de la cola de técnicos que se llamaría durante un incidente.

La tarea de aprovisionamiento es cerrar esa brecha sin pretender que la página pública de instalaciones ya lo haya hecho.

PeeringDB confirma señales de interconexión, no la colocación del cliente

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

Losregistros netixlan de PeeringDBlistan dos entradas operativas frente a intercambios: 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 una entrada de instalación para la entidad 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 adjuntos de intercambio en Equinix Hong Kong y HKIX. No hay contradicción a menos que alguien intente que un solo registro diga más de lo que puede. PeeringDB puede describir una presencia de interconexión en lugar de la colocación de la computación del cliente. Las páginas de centros de datos de Rackspace pueden describir instalaciones de hosting en lugar de cada intercambio o ubicación de interconexión.

Un cliente necesita el mapa que conecta estas capas: dónde se encuentra el servidor, dónde se encuentra el enrutador de borde, dónde se realiza el peering en el intercambio, dónde entra el tránsito y dónde el cliente tiene derechos contractuales.

La lección operativa inmediata es que el recuento de instalaciones no es lo mismo que la redundancia. Una línea de instalación de PeeringDB puede coexistir con múltiples sitios operados o comercializados por Rackspace. Dos puertos orientados a intercambios pueden mejorar la accesibilidad a redes seleccionadas sin probar la diversidad completa de tránsito. Un puerto de intercambio de 10G puede ser útil para el peering, pero la ruta de supervivencia del cliente durante una interrupción puede depender de tránsito pago, interconexión privada, DNS, filtrado de seguridad, balanceadores de carga, replicación de almacenamiento y acceso de soporte.

El registro público de interconexión le 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 final de vecinos ASNde RIPEstat devolvió 23 vecinos observados. La lista incluía grandes redes globales como AS174, AS3257, AS3300, AS3491, AS4637, AS6453, AS6939 y AS7473 en el lado izquierdo, una línea derecha para AS58982 y varias líneas inciertas. El BGP público no puede decir si cada adyacencia es un proveedor ascendente pago, un peer, un cliente, una relación de servidor de rutas de intercambio, un artefacto temporal de fuga de rutas o un artefacto de clasificación del lado del colector. Solo puede decirnos que el borde de enrutamiento no es invisible.

Las líneas históricas de política whois de APNIC añaden otra capa. Listan importaciones de AS3491, AS1239 y AS2914 y exportaciones a esos AS. Esta es una pieza histórica útil de evidencia de administración de enrutamiento, pero no describe automáticamente la ingeniería de tráfico actual. La lista actual de vecinos 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 otra en las operaciones físicas. Una red puede tener muchos vecinos BGP en los datos públicos mientras múltiples rutas comparten el mismo edificio, la misma sala de reuniones, el mismo dominio de energía, el mismo conducto de fibra, el mismo par de enrutadores o la misma cola de soporte. Por el contrario, un servicio puede tener una 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 gráfico AS público con un diseño de recuperación de cliente probado.

Las mejores preguntas son específicas de la capa. ¿Qué prefijos de AS45187 se originan desde qué enrutadores de borde en Hong Kong? ¿Qué proveedores ascendentes transportan rutas predeterminadas para el servicio durante la operación normal? ¿Qué sesiones de intercambio son peering sin liquidación versus accesibilidad crítica? ¿Qué rutas son diversas a nivel de entrada de fibra y edificio? ¿Cuánto tráfico puede transportar la ruta restante en el pico después de la eliminación de un operador, intercambio, enrutador o dominio de instalación? El BGP público puede sugerir dónde hacer preguntas. No puede responder todo esto por sí mismo.

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 un lenguaje empresarial familiar: hosting gestionado dedicado, infraestructura dedicada de un solo inquilino, metal desnudo, 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 rendimiento, soporte y control sin poseer cada enrutador, alimentación eléctrica, bahía de almacenamiento, interconexión y proceso de mantenimiento.

Este intercambio tiene valor real, pero no elimina la economía subyacente. Laguía del cliente de colocaciónde Rackspace describe la facturación asignada por kilovatio para energía crítica redundante reservada, con cargos mensuales recurrentes separados para interconexiones y ancho de banda combinado cuando se compra. También se refiere a tarifas de configuración únicas, circuitos de alimentación, jaulas privadas, PDU en rack e interconexiones. Este es el vocabulario de la capacidad física. La factura de la nube aún se basa en la asignación de energía, el espacio en rack, la óptica, las manos remotas, los compromisos de ancho de banda y la mano de obra.

Las páginas de Hong Kong hacen visible esto. La afirmación de HKG5 de 13,5 MW de potencia eléctrica, sus 7,2 MW de capacidad UPS y sus siete operadores de fibra no son decoración de marketing. Son insumos de capacidad que pueden restringir o proteger a un cliente.

Si la densidad del rack aumenta, si un cliente necesita más interconexiones, si un enrutador de repuesto no está disponible, si una ruta de operador está congestionada o si una ventana de mantenimiento requiere trabajo en serie, el cliente siente el estado físico a través de la latencia, el retraso en los tickets, los límites de migración o los créditos posteriores a la interrupción. La capacidad alojada se compra como servicio, pero falla como una cadena de pasos físicos y administrativos.

Es por esto que uno debe 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, enrutadores, prefijos y personal de soporte. La capacidad utilizable es lo que queda para un cliente después de contabilizar las reservas normales, la sobresuscripción, el mantenimiento, el enrutamiento específico del cliente y los dominios de protección. La capacidad recuperable es aún más estrecha: la porción que puede restaurarse dentro del plazo requerido por el cliente después de una falla de 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 en HKG5 puede no ser la de megavatios o recuentos de operadores. La página afirma que los clientes retienen el control administrativo de los servidores arrendados mientras Rackspace retiene el control del hardware de red. Esta separación es exactamente lo que un cliente de hosting gestionado desea durante la operación normal: el cliente puede gestionar su carga de trabajo, mientras que el proveedor protege la capa de red compartida. Durante una falla, la misma separación se convierte en un borde que debe ensayarse.

Si un servidor arrendado está sano pero es inalcanzable, los derechos administrativos del cliente pueden no ser suficientes. Si un cliente puede llegar al servidor a través de VPN pero no puede acceder al servicio público, el límite 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 factor 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 evidencia pública limitada.

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

La guía de colocación de Rackspace refuerza el mismo límite. Describe gerentes de implementación, capacitación en el portal del cliente, solicitudes de manos remotas, creación automática de tickets, monitores de alerta y un runbook. Afirma que los clientes pueden interactuar creando tickets a través del portal del cliente de Rackspace y pueden llamar al equipo de soporte 24/7/365. También lista tareas de manos remotas como ciclo de encendido de dispositivos, verificación visual, pruebas de cables, reemplazo de hardware proporcionado por el cliente, montaje y desmontaje en rack, cableado de red en rack y destrucción de discos duros.

Estas son las acciones concretas que convierten la detección de fallas en reparación.

Para un comprador, la pregunta de 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 debe responderse antes de la producción. Debe 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 piezas suministradas por 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. Tanto HKG1 como HKG5 incluyen lenguaje de garantía para red, infraestructura y 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 afirma que el reemplazo o reparación del hardware o componentes proporcionados por Rackspace comenzará dentro de una hora de la identificación del problema, con créditos si no es así. La palabra "comenzar" es importante.

No es lo mismo que "completar" y no describe todos los componentes proporcionados por el cliente.

La tabla de manos remotas en la guía de colocación es más detallada operativamente. 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 encendido de un enrutador, servidor o conmutador, 60 minutos por cada tres cables para pruebas de soporte de cableado y 60 minutos para reemplazar un dispositivo proporcionado por el cliente que no es intercambiable en caliente. Lista una tarifa de mano remota de US$46.25 por incremento de 15 minutos más lista de materiales. Estos no son detalles triviales.

Muestran dónde el reloj de reparación puede pasar de una métrica abstracta de tiempo de actividad a mano de obra humana paga.

Por lo tanto, un cliente debe separar tres relojes. El tiempo de detección es el tiempo que tarda el monitoreo en notar y clasificar una falla. El tiempo de respuesta es el tiempo que tarda Rackspace o el cliente en aceptar la propiedad y comenzar la acción. El tiempo de ejecución es el tiempo que realmente toma la reparación, incluyendo piezas, acceso, cableado, reinicio, cambio de ruta, reconstrucción de almacenamiento y verificación. Los créditos posteriores a la interrupción son comercialmente importantes, pero no restauran la carga de trabajo.

El escrutinio de la resiliencia debe centrarse en la restauración medida, no solo en los créditos de servicio.

La misma lógica se aplica al mantenimiento. El lenguaje de garantía de Rackspace excluye el mantenimiento planificado o de emergencia. Esta exclusión es normal, pero importa en una revisión de capacidad alojada. Si una ruta o sitio no está disponible para mantenimiento, la verdadera resiliencia 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 escalamiento importan. Si un evento de mantenimiento de emergencia toca 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 papeleo auxiliar.

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

La degradación más obvia en la evidencia de red es el estado de RPKI. RIPEstat informó claramente la superficie de enrutamiento, y PeeringDB dio detalle de interconexión, pero las verificaciones de validación RPKI contra la lista de prefijos actual 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, cobertura de validador, tiempo o 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 alojado, esto importa porque la validación de origen ya no es exótica. RFC 6811 describe la validación de origen de ruta como una forma de utilizar la Infraestructura de Clave Pública de Recursos para determinar si un AS está autorizado para originar un prefijo. El propio material RPKI de APNIC explica la certificación de control de recursos en términos operativos. Un cliente que depende de la accesibilidad pública debería preocuparse si los prefijos de producción de su proveedor son válidos, desconocidos o inválidos, y si los propios prefijos enrutados del cliente tienen ROA correctos antes de la migración.

La pregunta práctica no es "¿Sabe Rackspace BGP?" El conjunto público de vecinos y las afirmaciones de las instalaciones sugieren operaciones de enrutamiento maduras. La pregunta más estrecha es: para los prefijos exactos que transportan el servicio del cliente, ¿se publican y prueban las autorizaciones de origen de ruta con los principales validadores? Si el cliente trae su propio espacio de direcciones, ¿quién crea y mantiene los ROA? Si Rackspace asigna el espacio de direcciones, ¿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?

Esta es una de las pocas verificaciones públicas donde la respuesta puede mejorarse sin revelar detalles privados de la instalación. Un ROA válido no prueba la resiliencia del cliente, pero elimina un modo de falla evitable. Una ruta desconocida aún puede funcionar en la mayoría de las redes; simplemente le da al comprador menos garantía a nivel de validación de origen. En un archivo de Rackspace Hong Kong por lo demás sólido, este es exactamente el tipo de pregunta específica y solucionable que no debe perderse bajo el peso de una gran marca.

La localidad de los datos no se resuelve con las letras HK

La región de asignación es HK, APNIC lista AS45187 con 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 localidad. Aún no prueban dónde se encuentran los datos del cliente, las copias de seguridad, los registros, los registros de soporte, el sistema de identidad, las instantáneas o las copias de recuperación. En los contratos de nube y hosting gestionado, la localidad es una matriz de colocación, no un código de país.

El regulador de privacidad de Hong Kong subraya este punto en su orientación pública. LaGuía sobre Computación en la Nubede la PCPD de enero de 2025 indica a los usuarios de datos que consideren la ubicación del almacenamiento de datos, las medidas de seguridad en el equipo, la integridad y competencia de las personas que tienen acceso, la transmisión segura, los contratos con subcontratistas, los controles de retención y las implicaciones de las transferencias transfronterizas. Unanota de caso de la PCPD sobre sistemas en la nube fuera de Hong Kongafirma 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 aún deben cumplir con la PDPO y los principios de protección de datos. Lascláusulas contractuales modelo recomendadasde la PCPD proporcionan un marco contractual para las transferencias transfronterizas.

Para los clientes de Rackspace Hong Kong, la consecuencia es práctica. El cliente debe 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 están involucradas y si una acción de soporte normal transfiere datos personales fuera de Hong Kong.

Un borde de enrutamiento en Hong Kong puede coexistir con herramientas de soporte fuera de Hong Kong, sistemas de identidad globales, copias de seguridad en el extranjero o interconexiones multinube. Nada de esto es necesariamente impropio. Simplemente necesita ser divulgado y probado contra las propias obligaciones regulatorias del cliente.

La localidad también interactúa con la recuperación. Una copia de seguridad fuera de Hong Kong puede mejorar la resiliencia pero alterar 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 dentro de 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.

La evidencia de salida es parte de la resiliencia

Un servicio alojado no es completamente resiliente hasta que el cliente pueda abandonarlo bajo presión. La documentación de Rackspace contiene signos útiles de que algunos servicios exponen rutas de exportación y migración. El manual de Rackspace Cloud sobre OpenStack Flex apunta a funciones para crear máquinas virtuales, almacenamiento en bloque, almacenamiento de objetos, exportar imágenes, importar imágenes y programar migración. Laguía de exportación de imágenesdescribe la exportación de instantáneas de instancias desde un proyecto de OpenStack Flex. Laguía de la API de Object Storageexplica que el acceso requiere credenciales de Rackspace Cloud, detalles del proyecto y llamadas 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 debe discutirse a nivel de artefacto. ¿Puede el cliente exportar imágenes de VM? ¿Puede exportar volúmenes en bloque? ¿Son portátiles las copias de seguridad? ¿Son exportables las configuraciones de red, las reglas de firewall, los ajustes del balanceador de carga, las zonas DNS, los certificados, los registros y el historial de monitoreo? ¿Funciona la exportación si el portal del cliente está degradado? ¿Requiere un compromiso de soporte pago?

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

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

Es el final honesto de una revisión de dependencia.

La infraestructura publicada de Rackspace es lo suficientemente sólida como para que muchos clientes elijan racionalmente no gestionar infraestructura equivalente ellos mismos. Ese es el punto económico del hosting gestionado. El peligro no está en usar un proveedor; está en usarlo sin preservar la evidencia necesaria para moverse, restaurar o verificar de forma independiente el servicio cuando algo sale mal.

El empaquetado corporativo ayuda, pero la evidencia local aún gana

El archivo corporativo más amplio de Rackspace Technology ayuda a explicar por qué este perfil de Hong Kong no debe tratarse como un pequeño hoster regional. Rackspace Technology, Inc. aparece en presentaciones SEC como una empresa que cotiza en Nasdaq bajo el símbolo RXT, y supresentación 10-K de 2025proporciona a los inversores el contexto empresarial y de riesgo más amplio en torno a sus operaciones de nube, hosting y servicios. Lapágina global de centros de datosde Rackspace presenta una huella de centros de datos multimercado y afirma que sus instalaciones utilizan redundancia en los dominios de seguridad, energía, refrigeración y red. Estos hechos reducen la incertidumbre de 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 evidencia local. Una empresa global aún puede tener una restricción local de instalaciones, una dependencia regional de proveedores, 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 difiere de la página pública de instalaciones. El 10-K también está escrito para inversores, no para un cliente de Hong Kong que intenta saber qué rack, qué ruta, qué sistema de respaldo y qué ingeniero decidirán una interrupción de sábado.

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

Este empaquetado corporativo cambia el método de garantía. Con un proveedor pequeño y 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 reales: la identidad AS45187 de APNIC, la evidencia de enrutamiento actual 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 asuma que todas las capas se aplican a su servicio de la misma manera.

Por lo tanto, el comprador debe pedir a Rackspace que produzca un cronograma de servicio local. Debe 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 localidad de datos y el proceso de salida. Una marca global puede hacer que ese cronograma sea más fácil de obtener. No puede reemplazar el cronograma.

Lo que los clientes deben probar antes de confiar en el borde de Hong Kong

La primera prueba es el mapeo. Pida a Rackspace que mapee el servicio a AS45187, la instalación o instalaciones, los prefijos de producción, las rutas de gestión, las rutas de respaldo y los sistemas de soporte. Verifique la respuesta del ASN con APNIC RDAP, los prefijos anunciados de RIPEstat, el registro de Rackspace Hong Kong en PeeringDB y las páginas HKG1/HKG5 de Rackspace. Si el servicio del cliente no usa AS45187, eso puede ser aceptable, pero debe establecerse claramente.

La segunda prueba es la falla. Elimine un proveedor ascendente, una ruta de intercambio, un enrutador, un componente de almacenamiento, un portal de soporte, una credencial de cliente y un dominio de mantenimiento en un ejercicio de mesa o en vivo. Registre lo que sucede con la accesibilidad, el acceso a la consola, DNS, monitoreo, copia de seguridad, facturación, tickets y exportación de datos. El resultado debe identificar qué porción del servicio es activo-activo, activo-pasivo, solo de respaldo o manual.

La tercera prueba es la seguridad del enrutamiento. Pregunte por el estado de RPKI en los prefijos de producción exactos, incluidos los prefijos propiedad del cliente. Pregunte cómo se cambian 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 público desconocido de RPKI no debe tratarse como un escándalo; debe tratarse como un elemento de control abierto.

La cuarta prueba es el soporte y la reparación. Use el vocabulario de manos remotas de la guía de colocación para hacer concreto el ejercicio. ¿Quién abre el ticket? ¿Quién puede llamar si falla el portal? ¿Qué tareas están incluidas, facturables 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 dentro de una hora de la identificación del problema, ¿quién identifica el problema y qué marca el inicio?

La quinta prueba es la localidad y la salida. Pregunte por la matriz de localidad de datos, incluidos primario, réplica, copia de seguridad, registros, registros de soporte e identidad. Pregunte por la evidencia de exportación y una prueba de restauración cronometrada. El material de la PCPD deja claro por qué estas preguntas pertenecen a una discusión de nube en Hong Kong: el cliente sigue siendo responsable del procesamiento de datos personales incluso cuando utiliza un proveedor de nube o subcontratista.

El nivel de evidencia

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

Rackspace publica las páginas HKG1 y HKG5 con afirmaciones concretas sobre instalaciones, energía, operadores, red y soporte.

El nivel no es más alto que esto porque la evidencia pública siempre se detiene en el límite del cliente. No divulga la asignación de rack del cliente, el recuento de servidores, la energía reservada, la topología de almacenamiento, la geografía de respaldo, el inventario de repuestos, la cola de soporte, las exclusiones contractuales, el programa de mantenimiento ni el tiempo de salida probado. También deja la autorización de origen de ruta como una pregunta abierta porque los prefijos actuales muestreados devolvieron un estado RPKI de desconocido en lugar de válido.

La conclusión práctica es estrecha y útil: esta no es una huella de hosting delgada en Hong Kong. Es una presencia real y bien documentada de red e instalaciones de Rackspace que aún requiere garantía específica del servicio. Los clientes no deben descartarla como no verificable. Tampoco deben permitir que el nombre de Rackspace, dos páginas de centros de datos en Hong Kong o la superficie de ruta visible de AS45187 sustituyan la evidencia de falla que realmente protege una carga de trabajo.

Quién siente la falla

Las personas que primero sienten una falla de AS45187 o una instalación en Hong Kong pueden ser propietarios de aplicaciones, operadores de revendedores, equipos de fintech, administradores de SaaS, minoristas en línea, propietarios de bases de datos, gerentes de cumplimiento o ingenieros de red que intentan mantener los servicios del cliente accesibles. El efecto downstream puede moverse 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 interrupción 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. Tiene operaciones globales de centros de datos, SLA publicados, instalaciones nombradas en Hong Kong, lenguaje de soporte maduro e interconexión visible. La escala también puede ocultar la dependencia específica del cliente. Un proveedor grande puede tener muchas rutas, pero el cliente aún depende de su propio diseño de servicio. Un proveedor grande 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 proveedor grande puede tener ingenieros globales, pero el cliente aún necesita una ruta de escalamiento local y contractual.

Es por eso que este artículo trata a Rackspace Hong Kong como una dependencia que entender en lugar de un misterio que resolver. La evidencia pública es buena. La infraestructura física está nombrada. La red es visible. El registro de interconexión tiene detalles útiles. El trabajo restante es probar cómo se comportan estos hechos cuando una carga de trabajo real pierde un rack, un proveedor 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 alojada solo es tan resiliente como la evidencia detrás de esas respuestas.