Rackspace IT Hosting AS IT Hosting Provider Hong Kong продаёт размещённые мощности, всё ещё зависящие от стоек, транзита и окон ремонта

Кратко

• Rackspace IT Hosting AS IT Hosting Provider Hong Kong сопоставляется с AS45187 в публичных записях APNIC и RIPEstat. В записи RDAP APNIC организацией-регистрантом указана Rackspace.com Hong Kong Limited, а RIPEstat обозначает владельца как «RACKSPACE-AP — Rackspace IT Hosting AS IT Hosting Provider Hong Kong».
• Маршрутная поверхность хорошо видна. Снимок статуса маршрутизации RIPEstat для AS45187 показал 13 префиксов IPv4, 2 префикса IPv6, 66 816 адресов IPv4, полную наблюдаемую видимость RIS по обоим адресным семействам и 23 наблюдаемых соседа. Представление анонсированных префиксов перечисляло активные префиксы, включая 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 и 2407:fa00::/32.
• PeeringDB добавляет контекст площадок и соединений, а не гарантию мощности. Для AS45187 там указан «Rackspace Hong Kong», открытая политика, информационные счётчики на 100 префиксов IPv4 и 10 префиксов IPv6, две точки обмена по 10G — Equinix Hong Kong и HKIX — и одна площадка — MEGA-i в Гонконге.
• Собственные страницы Rackspace HKG1 и HKG5 делают физическую зависимость наглядной. HKG1 описан в Чхюньване: модули ИБП, два ввода 11 кВ и резервированные сетевые компоненты. HKG5 описан в Чхёнкуаньоу: 917 кв. м выделенных площадей дата-центра, 13,5 МВт мощности от сетей, 7,2 МВт мощности ИБП, семь операторов связи, 10G на каждого оператора, оптимизация маршрутов BGP multipath и заявленное разделение: клиенты сохраняют административный контроль над арендованными серверами, а Rackspace управляет сетевым оборудованием.
• Оценка доказательств — сильная (Strong) для публичной сетевой идентичности и подтверждения работы в Гонконге, но это не карт-бланш для любой размещённой нагрузки. Клиентам по-прежнему нужны доказательства размещения, резервирования, сроков восстановления, эскалации заявок, исключений из обслуживания, доступа к запчастям, статуса RPKI, договорных границ и путей выхода применительно к конкретной услуге.

Полезный вопрос больше не в том, существует ли Rackspace в Гонконге

Некоторые профили инфраструктуры начинаются с тонкого имени и едва заметного ASN. Этот — нет. Публичные записи вокруг Rackspace IT Hosting AS IT Hosting Provider Hong Kong достаточно плотные, чтобы перевести исследование от вопроса о существовании к вопросу о зависимостях.Запись RDAP APNIC об автономной системеидентифицирует AS45187 как RACKSPACE-AP, со страной HK и организацией-регистрантом Rackspace.com Hong Kong Limited. RIPEstat вобзоре ASиспользует метку владельца «Rackspace IT Hosting AS IT Hosting Provider Hong Kong» и помечает ASN как анонсируемый. Такая связка прочнее, чем автоматически собранная запись каталога хостинга или устаревшая страница компании.

Данные о маршрутах тоже достаточно свежие, чтобы иметь значение. Встатусе маршрутизации RIPEstatдля AS45187 на момент снимка были видны IPv4 и IPv6 у всех наблюдаемых пиров RIS, 13 префиксов IPv4, 2 префикса IPv6 и 23 наблюдаемых соседа. Наборannounced-prefixesперечислял 15 текущих строк префиксов, включая две крупные агрегации IPv6 — 2401:1800::/32 и 2407:fa00::/32 — и маршруты IPv4 вроде 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 и 203.60.0.0/17. Это не сеть-витрина с одним префиксом.

Публичные материалы Rackspace о площадках делают предмет ещё менее абстрактным. Страница дата-центраHKG1размещает одну гонконгскую площадку в Чхюньване и описывает электропитание, охлаждение, безопасность, связь и гарантии. СтраницаHKG5размещает другую в Чхёнкуаньоу и идёт дальше: 917 кв. м выделенных площадей дата-центра, 13,5 МВт суммарной мощности от сетей, 7,2 МВт мощности ИБП, семь операторов связи до площадки и оптимизация маршрутов BGP multipath. Вопрос существования поэтому можно считать закрытым для закупочной работы. Открытым остаётся вопрос, обладает ли конкретная хостинговая услуга клиента той же устойчивостью, которую предполагает опубликованный след.

Это различие важно, потому что «Rackspace» — крупный бренд, «Hong Kong» — рыночная метка, AS45187 — граница сети, а рабочая нагрузка клиента — развёртывание, определяемое договором. Покупатель видит публичные номерные ресурсы и заявления Rackspace о площадках, но не может вывести из них, какой зал, стойка, оператор, VLAN, система резервного копирования, команда поддержки или календарь обслуживания относятся к его среде. Хорошо проработанная страница площадки должна ужесточать проверку, а не ослаблять её.

AS45187 — реальный сетевой рубеж, но реестр показывает не все услуги

Записи APNIC и RIPEstat показывают целостную идентичность. Запись RDAP содержит дату регистрации в декабре 2014 года и дату последнего изменения в июле 2020 года. Впредставлении RIPEstat на основе whoisзафиксированы aut-num 45187, as-name RACKSPACE-AP, описание Rackspace IT Hosting AS IT Hosting Provider Hong Kong и страна HK. Там же видны более старые строки политик импорта и экспорта с AS3491, AS1239 и AS2914, а также контакты Rackspace по обслуживанию маршрутов. Эти детали полезны: они связывают номерной ресурс с гонконгским юрлицом Rackspace и с многолетней записью администрирования маршрутизации.

Но их недостаточно, чтобы определить продукт. AS45187 может нести функции публичного облака, управляемого хостинга, выделенных серверов, колокации, хранения, мониторинга, плоскости управления, поддержки или магистрали — в разных комбинациях. Одни клиентские системы могут напрямую адресоваться из AS45187. Другие могут использовать адреса, назначенные провайдером, частные стыки, адреса облачного провайдера или гибридные маршруты, которые не видны как источники клиенту. Реестр подсказывает покупателю, куда смотреть.

Он не может сказать, какой именно продукт использует сетевой рубеж, какое юрлицо подписывает договор и какой поставщик отвечает за инцидент.

Свидетельство о владельце в APNIC поэтому лучше читать как отправную точку карты ответственности. Если клиенту говорят, что гонконгская нагрузка обслуживается из инфраструктуры Rackspace, AS45187 даёт клиенту конкретную сетевую границу, о которой можно спрашивать. Какие префиксы входят в объём? Какие обслуживают клиентов, какие — только управление, резервное копирование или legacy? Какие политики маршрутизации действуют, а какие исторические? Для каких префиксов есть авторизация происхождения маршрута и какие остаются неизвестными для валидаторов RPKI? Это не академические вопросы.

От них зависит, сможет ли утечка маршрута, изменение фильтров, событие по DDoS-защите или сбой апстрима затронуть услугу.

Первое предостережение — RPKI. Проверка валидации, выполненная для этой статьи для 119.9.64.0/19 черезконечную точку валидации RPKIв RIPEstat, вернула статус unknown, а не valid. Тот же статус появился для набора префиксов из списка анонсированных. Unknown — не то же самое, что invalid, и это не значит, что сеть сбоит. Но это значит, что авторизация происхождения маршрута должна быть живым закупочным вопросом: сети, применяющие проверку происхождения маршрута (Route Origin Validation), по-разному обращаются с маршрутами valid, invalid и unknown. Для клиента, который зависит от стабильного гонконгского рубежа, статус «unknown» должен вести к разговору о ROA, фильтрах маршрутов, процедурах контактов и владельце процесса изменений.

Rackspace публикует два разных типа доказательств по гонконгским площадкам

Страницы гонконгских площадок Rackspace необычно конкретны по сравнению со многими региональными хостинг-профилями. HKG1, описанный на страницеRackspace Technology Data Centers: Hong Kong (HKG1), расположен в Чхюньване. Страница утверждает, что гонконгские площадки обслуживают инженеры систем, которые управляют системами и обслуживают их 24x7x365. Физические заявления HKG1 включают модули ИБП 400 кВА в конфигурации N+1, 30 минут резерва от батарей, два ввода электропитания 11 кВ от отдельных районных подстанций HKE, два стояка питания, несколько дизель-генераторов и нейтральную к операторам площадку с двумя телекоммуникационными вводами.

HKG5, описанный на страницеRackspace Technology Data Centers: Hong Kong (HKG5), расположен в Чхёнкуаньоу и раскрывает другой набор конкретики: 917 кв. м выделенных площадей дата-центра, 13,5 МВт суммарной мощности от сетей, 7,2 МВт мощности ИБП, дизель-генераторы по 2,25 МВт каждый, топливные баки на 12 000 литров, более 1 МВт мощности охлаждения, семь операторов связи до площадки, 10-гигабитный Ethernet от каждого оператора, резервированные маршрутизаторы Cisco и Arista, а также оптимизацию маршрутов BGP multipath. Там же сказано, что клиенты сохраняют административный контроль над арендованными серверами, а Rackspace — над сетевым оборудованием.

Эти заявления имеют операционный смысл. Они говорят, что Rackspace не просто перепродаёт анонимный облачный регион под гонконгской меткой. Они указывают на физическую инфраструктуру, проектирование сети, штат поддержки и границы контроля. Но их всё равно нужно превращать в доказательства применительно к конкретной услуге. «У HKG5 семь операторов» само по себе не доказывает, что у каждой клиентской услуги есть семь активных, способных нести дефолтный трафик, оплаченных и подготовленных путей. «Оптимизация маршрутов BGP multipath» не доказывает разнообразия маршрутов вплоть до приложения, уровня хранения или консоли управления клиента.

«Клиенты сохраняют административный контроль» не доказывает, что клиент сможет восстановить услугу, если сетевое оборудование, портал, очередь поддержки или состояние биллинга заблокируют доступ.

Страницы площадок сильнее всего там, где называют физические вводы. Вводы питания, мощность ИБП, топливо генераторов, число операторов и семейства маршрутизаторов — реальные вещи, которые покупатель может попросить показать в проекте услуги. Слабее всего страницы там, где они неизбежно обобщают. Они не публикуют назначение шкафов, размещение клиентов, патч-панели, карты частных VLAN, топологию хранения, географию резервных копий, запасы запчастей или глубину очереди техников, которых вызовут при инциденте. Задача закупки — закрыть этот разрыв, не делая вид, что публичная страница площадки уже закрыла его.

PeeringDB подтверждает сигналы соединений, а не размещение клиентов

Сетевой API PeeringDBдля ASN 45187перечисляет один объект сети с именем Rackspace Hong Kong. Поля показывают открытую общую политику, AS-набор IRR вида AS-RACKSPACE, информационные счётчики на 100 префиксов IPv4 и 10 префиксов IPv6, поддержку IPv6, число точек обмена 2 и число площадок 1. PeeringDB — добровольный каталог, поэтому ни одно из этих полей не является сертификатом. Тем не менее запись ценна: она связывает AS45187 с позицией по соединениям, которую можно сравнить с коллекторами маршрутов и заявлениями Rackspace о площадках.

Записиnetixlan в PeeringDBперечисляют две действующие точки обмена: Equinix Hong Kong и HKIX: HKIX Peering LAN. Обе показывают скорость 10 000 Мбит/с. Строка Equinix Hong Kong содержит адрес IPv4 36.255.56.87 и адрес IPv6 2001:de8:7::4:5187:2. Строка HKIX содержит адрес IPv4 123.255.90.101 и адрес IPv6 2001:7fa:0:1::ca28:a065. Записьnetfac в PeeringDBуказывает MEGA-i (iAdvantage Hong Kong) в Гонконге как площадку для этого объекта сети.

Эти строки создают полезное напряжение со страницами HKG1 и HKG5 самого Rackspace. Rackspace публикует страницы площадок в Чхюньване и Чхёнкуаньоу, а PeeringDB показывает одну запись площадки в MEGA-i и подключения к точкам обмена Equinix Hong Kong и HKIX. Противоречия нет, если кто-то не пытается заставить одну запись делать больше, чем она может. PeeringDB может описывать присутствие в соединениях, а не размещение клиентских вычислений. Страницы дата-центров Rackspace могут описывать хостинговые площадки, а не каждую точку обмена или кросс-коннект.

Клиенту нужна карта, связывающая эти уровни: где стоит сервер, где стоит граничный маршрутизатор, где происходит пиринг в точке обмена, где входит транзит и где у клиента договорные права.

Непосредственный операционный урок: число площадок — не то же самое, что резервирование. Одна строка площадки в PeeringDB может соседствовать с несколькими площадками, которыми управляет или которые продвигает Rackspace. Два порта в точках обмена могут улучшить достижимость отдельных сетей, не доказывая полного разнообразия транзита. Порт 10G в точке обмена полезен для пиринга, но путь клиента, переживающий сбой, может зависеть от платного транзита, частного стыка, DNS, фильтрации безопасности, балансировщиков нагрузки, репликации хранилища и доступа к поддержке.

Публичная запись о соединениях даёт покупателю имена и адреса для проверки, а не результат сквозного переключения при отказе.

Маршрутная поверхность широкая, но разнообразие путей нужно доказывать дважды

У AS45187 видимый набор соседей. Конечная точкаASN-neighboursв RIPEstat вернула 23 наблюдаемых соседа. В список входили крупные глобальные сети вроде AS174, AS3257, AS3300, AS3491, AS4637, AS6453, AS6939 и AS7473 в левой части, одна строка справа — AS58982 — и несколько неопределённых строк. Публичный BGP не может сказать, является ли каждый стык платным апстримом, пиром, клиентом, отношением с route-сервером точки обмена, временным артефактом утечки маршрута или артефактом классификации на стороне коллектора. Он может сказать только, что сетевой рубеж не невидим.

Более старые строки политик в whois APNIC добавляют ещё один слой. Они перечисляют импорт из AS3491, AS1239 и AS2914 и экспорт в эти ASN. Это полезное историческое свидетельство администрирования маршрутизации, но оно не описывает автоматически текущий трафик-инжиниринг. Текущий список соседей в RIPEstat включает часть этих имён косвенно и показывает другие. Покупателю стоит запросить у Rackspace текущую схему транзита и пиринга, а не полагаться на статичный текст политик whois.

Разнообразие нужно доказывать дважды: один раз на уровне маршрутизации и один раз на уровне физической эксплуатации. В публичных данных у сети может быть несколько соседей BGP, при этом несколько путей делят одно здание, комнату встречи операторов (meet-me room), домен питания, кабельный канал, пару маршрутизаторов или очередь поддержки. И наоборот: услуга может иметь сильную частную или поставщиковую устойчивость, которая почти не видна в публичном BGP. Цель не в том, чтобы наказать Rackspace за скрытие операционных деталей; цель — не принять публичный граф AS за проверенную схему восстановления клиента.

Лучшие вопросы задаются по уровням. Какие префиксы AS45187 анонсируются с каких гонконгских граничных маршрутизаторов? Какие апстримы несут дефолтные маршруты услуги в обычной работе? Какие сессии в точках обмена — это бесплатный пиринг, а какие — критичная достижимость? Какие пути разнесены на уровне ввода волокна и здания? Какой трафик сможет пропустить оставшийся путь на пике после удаления одного провайдера, одной точки обмена, одного маршрутизатора или одной площадки? Публичный BGP подсказывает, где спрашивать. Ответить на всё это сам он не может.

Rackspace продаёт абстракцию, но экономика Гонконга остаётся физической

Страницауправляемого хостингаRackspace описывает продукт привычным корпоративным языком: управляемый выделенный хостинг, одноклиентская выделенная инфраструктура, bare metal, базы данных, сети, хранилища, управляемое резервное копирование, аварийное восстановление, RackConnect и частное облако. Коммерческое обещание: Rackspace превращает физическую сложность в услугу. Клиенты покупают производительность, поддержку и контроль, не владея каждым маршрутизатором, вводом питания, массивом хранения, кросс-коннектом и процессом обслуживания.

Эта сделка имеет реальную ценность, но не отменяет базовую экономику. Руководство по колокации Rackspace(colocation customer guide)описывает биллинг по выделенным киловаттам за резервированную критичную мощность, отдельные ежемесячные платежи за кросс-коннекты и смешанную полосу пропускания там, где она куплена. Там также упоминаются разовые платежи за установку, силовые цепи, частные клетки, PDU в стойках и кросс-коннекты. Это лексика физических мощностей. Облачный счёт по-прежнему опирается на выделение мощности, пространство в шкафах, оптику, услуги remote hands, обязательства по полосе и труд.

Страницы о Гонконге делают это наглядным. Заявление HKG5 о 13,5 МВт от сетей, 7,2 МВт ИБП и семь операторов связи — не маркетинговый декор. Это входы мощности, которые могут ограничивать клиента или защищать его. Если плотность стоек растёт, клиенту нужно больше кросс-коннектов, запасной маршрутизатор недоступен, путь оператора перегружен или окно обслуживания требует последовательных работ — клиент ощущает физическую инфраструктуру через задержки, медленную обработку заявок, ограничения миграции или кредиты после простоя. Размещённая мощность покупается как услуга, а отказывает она как цепочка физических и административных шагов.

Именно поэтому нужно разделять «установленную» и «доступную» мощность. Установленная мощность — это то, что опубликованный след, судя по всему, включает: площадки, генераторы, ИБП, подключения операторов, маршрутизаторы, префиксы и персонал поддержки. Доступная мощность — это то, что остаётся клиенту после учёта обычных резервирований, оверсабскрипшена, обслуживания, специфичной для клиента маршрутизации и защитных доменов. Восстанавливаемая мощность ещё уже: часть, которую можно вернуть в требуемое клиентом время после отказа компонента. Публичные страницы хороши для установленной мощности.

Доказательства клиента должны подтверждать доступную и восстанавливаемую мощность.

Контроль разделён по замыслу

Самая важная строка HKG5, возможно, не про мегаватты и число операторов. Страница говорит: клиенты сохраняют административный контроль над арендованными серверами, а Rackspace — над сетевым оборудованием. В обычной работе это разделение — ровно то, чего хочет клиент управляемого хостинга: клиент управляет своей нагрузкой, а провайдер защищает общий сетевой уровень. При сбое то же разделение становится границей, которую нужно отрабатывать.

Если арендованный сервер здоров, но недоступен, административных прав клиента может не хватить. Если клиент входит на сервер по VPN, но не может достучаться до публичной услуги — значение имеет сетевая граница. Если клиенту нужно изменение маршрута, правило файрвола, заявка на кросс-коннект или замена оборудования, полномочия и очередь Rackspace становятся определяющим фактором темпа. Если у клиента есть резервная копия, но он не может перекачать достаточно данных по доступному пути, контроля на уровне сервера недостаточно. Совместная ответственность здесь не лозунг, а операционная архитектура.

Руководство по колокации Rackspace закрепляет ту же границу. В нём описаны лидеры внедрения, обучение работе с порталом клиента, запросы smart hands, автоматическое создание заявок, мониторы оповещений и регламент действий (runbook). Там сказано, что клиенты могут взаимодействовать, создавая заявки через портал клиента Rackspace (Rackspace Customer Portal), и могут звонить в службу поддержки 24x7x365.

Там же перечислены задачи smart hands: перезагрузка устройств, визуальная проверка, тестирование кабелей, замена оборудования, предоставленного клиентом, установка и снятие оборудования со стоек, кабельные работы внутри шкафа и уничтожение жёстких дисков. Это конкретные действия, которые превращают обнаружение сбоя в ремонт.

Для покупателя вопрос контроля прост: что мы можем сделать без Rackspace, что Rackspace может сделать без нас и что требует от обеих сторон действий в правильном порядке? На этот вопрос нужно ответить до начала продакшена. Он должен быть записан операционными шагами, а не только языком договора. Какие пользователи портала имеют полномочия? Какой номер телефона работает, если портал недоступен? Какие изменения маршрутов требуют заявки? Какие аппаратные действия включены? Какие задачи тарифицируются с шагом в 15 минут? Какие задачи зависят от деталей, которые поставляет клиент, а не Rackspace?

Окна ремонта — часть продукта, а не примечание

Страницы дата-центров Rackspace публикуют сильные гарантии, но важны детали. HKG1 и HKG5 включают формулировки гарантий по сети, инфраструктуре и замене оборудования. Разделы о сети и инфраструктуре говорят на языке доступности и кредитов, а гарантия замены оборудования говорит, что замена или ремонт оборудования или компонентов, предоставленных Rackspace, начнётся в течение одного часа с момента выявления проблемы, иначе начисляются кредиты. Формулировка «начнётся» важна. Это не то же самое, что «завершится», и она не распространяется на каждый компонент, предоставленный клиентом.

Таблица smart hands в руководстве по колокации операционно более детальна. Для HKG1 она показывает и 1-часовой SLA на отклик, и 24-часовой SLA на выполнение для smart hands. В том же руководстве приводятся ориентировочные сроки типовых задач: 30 минут на перезагрузку маршрутизатора, сервера или коммутатора, 60 минут за каждые три кабеля на тестирование кабельной среды и 60 минут на замену предоставленного клиентом устройства, если оно не поддерживает горячую замену. Ставка smart hands указана как 46,25 доллара США за 15 минут плюс стоимость материалов. Это не мелочи.

Они показывают, где часы ремонта переходят от абстрактного аптайма к оплачиваемой человеческой работе.

Поэтому клиенту стоит различать три отсчёта времени. Время обнаружения — сколько нужно мониторингу, чтобы заметить и классифицировать отказ. Время отклика — сколько нужно Rackspace или клиенту, чтобы принять ответственность и начать действовать. Время выполнения — сколько реально занимает ремонт, включая детали, доступ, кабели, перезагрузку, изменение маршрута, пересборку хранилища и проверку. Кредиты после простоя коммерчески важны, но они не восстанавливают нагрузку. Оценка устойчивости должна фокусироваться на измеренном восстановлении, а не только на сервисных кредитах.

Та же логика применима к обслуживанию. Формулировки гарантий Rackspace исключают плановое и аварийное обслуживание. Это исключение нормально, но важно в обзоре размещённых мощностей. Если один путь или площадка выведены на обслуживание, реальная устойчивость клиента — это мощность, оставшаяся на необслуживаемом пути. Если клиенту нужно изменение во время заморозки изменений у провайдера, важны правила эскалации. Если аварийное обслуживание затрагивает общий сетевой компонент, административные права клиента могут не помочь. Окна ремонта и окна обслуживания — часть продукта, а не прилагаемые бумаги.

Безопасность происхождения маршрутов — слабое место в остальном сильной публичной картине

Самое очевидное понижение в сетевых доказательствах — статус RPKI. RIPEstat чётко показал маршрутную поверхность, а PeeringDB дал детали соединений, но проверки валидации RPKI по текущему списку префиксов в использованной здесь выборке вернули unknown, а не valid. Статус unknown может существовать по многим причинам: отсутствие ROA, покрытие валидаторов, тайминги или решения об управлении ресурсами. Это не значит, что AS45187 угоняет маршруты. Это значит, что уровень авторизации происхождения не так силён публично, как уровень видимости BGP.

Для размещённого клиента это важно, потому что проверка происхождения уже не экзотика. RFC 6811 описывает проверку происхождения маршрута как способ использовать инфраструктуру публичных ключей ресурсов (RPKI), чтобы определять, уполномочена ли AS анонсировать префикс. Собственные материалы APNIC по RPKI объясняют контроль сертификации ресурсов на операционном языке. Клиент, зависящий от публичной достижимости, должен знать, являются ли продакшен-префиксы его провайдера valid, unknown или invalid, и есть ли для клиентских маршрутов корректные ROA до миграции.

Практический вопрос не в том, «понимает ли Rackspace BGP». Публичный набор соседей и заявления о площадках говорят о зрелой работе с маршрутизацией. Вопрос уже: для тех самых префиксов, которые несут услугу клиента, опубликованы ли авторизации происхождения маршрута и проверены ли они крупными валидаторами? Если клиент приносит собственное адресное пространство — кто создаёт и поддерживает ROA? Если адресное пространство назначает Rackspace — может ли Rackspace показать статус и процесс изменений? Если во время инцидента префикс нужно перенести — что происходит с ROA и состоянием фильтров?

Это одна из немногих публичных проверок, где ответ можно улучшить, не раскрывая частных деталей площадки. Действительная ROA не доказывает устойчивость клиента, но убирает один избегаемый режим отказа. Неизвестный маршрут может работать в большинстве сетей; он просто даёт покупателю меньше уверенности на уровне проверки происхождения. В остальном сильной записи Rackspace в Гонконге это ровно тот конкретный, исправимый вопрос, который не должен утонуть под весом большого бренда.

Локализация данных не решается буквами «HK»

В задании регион HK, APNIC перечисляет AS45187 со страной HK, Rackspace публикует гонконгские площадки, а запись PeeringDB описывает соединения в Гонконге. Это хорошие сигналы локализации. Но они не доказывают, где лежат данные клиента, резервные копии, логи, записи поддержки, система идентификации, снапшоты или копии для восстановления. В облачных и хостинговых договорах локализация — это матрица размещения, а не код страны.

Регулятор приватности Гонконга делает эту мысль в публичных рекомендациях. В опубликованном в январе 2025 года«Руководстве по облачным вычислениям» PCPDпользователям данных предлагается учитывать, где хранятся данные, меры безопасности оборудования, добросовестность и компетентность людей, имеющих доступ, безопасность передачи, договоры с обработчиками, контроль сроков хранения и последствия трансграничной передачи. Всправке PCPD по делу об облачных системах за пределами Гонконгасказано: постановление не запрещает хранить персональные данные в облачной системе за пределами Гонконга, но пользователи данных по-прежнему обязаны соблюдать PDPO и Принципы защиты данных. Рекомендуемые PCPDтиповые договорные положениядают договорную основу для трансграничных передач.

Для клиентов Rackspace в Гонконге последствие практическое. Клиенту стоит спросить, где хранятся первичные данные, где хранятся снапшоты, где резервные копии, где логи управления, какие команды поддержки могут получить доступ к среде, какие субподрядчики или партнёрские облака участвуют и выводит ли какое-либо обычное действие поддержки персональные данные за пределы Гонконга. Гонконгский сетевой рубеж может сосуществовать с не-гонконгскими инструментами поддержки, глобальными системами идентификации, зарубежными резервными копиями или стыками в мультиоблако. Всё это не обязательно неправильно.

Это просто нужно раскрывать и проверять на соответствие регуляторным обязанностям самого клиента.

Локализация также взаимодействует с восстановлением. Резервная копия за пределами Гонконга может улучшить устойчивость, но изменить анализ передачи. Локальная резервная копия может удовлетворить предпочтение по месту хранения, но подвести, если местная площадка пострадает от события регионального масштаба. Многоплощадочная схема в Гонконге может быть лучше по задержке и юрисдикции, но дороже и всё равно зависит от общих поставщиков. Покупателю нужен проект, а не лозунг.

Доказательства выхода — часть устойчивости

Размещённая услуга не является полностью устойчивой, пока клиент не может уйти из неё под давлением обстоятельств. В документации Rackspace есть полезные признаки того, что некоторые услуги раскрывают пути экспорта и миграции. Справочник Rackspace Cloud на OpenStack Flex ссылается на функции создания виртуальных машин, блочного хранилища, объектного хранилища, экспорта образов, импорта образов и планирования миграции.Руководство по экспорту образовописывает экспорт снапшотов инстансов из проекта OpenStack Flex.Руководство по API объектного хранилищаобъясняет, что для доступа нужны учётные данные Rackspace Cloud, данные проекта и вызовы API.

Эти документы не доказывают, что каждый клиент управляемого хостинга в Гонконге сможет выполнить полный аварийный выход. Они доказывают, что выход нужно обсуждать на уровне артефактов. Может ли клиент экспортировать образы виртуальных машин? Может ли он экспортировать блочные тома? Переносимы ли резервные копии? Можно ли экспортировать конфигурации сетей, правила файрволов, настройки балансировщиков, зоны DNS, сертификаты, логи и историю мониторинга? Работает ли экспорт, если портал клиента деградировал? Требует ли он платного обращения в поддержку? Можно ли его протестировать, не вызывая изменения в продакшене?

Физический слой снова появляется при выходе. Крупные экспорты потребляют полосу и время. Биллинг кросс-коннектов, лимиты транзита, скорости чтения хранилища, учётные данные объектного хранилища и заявки в поддержку становятся частью пути миграции. Клиент, который ни разу не измерял полный экспорт, может обнаружить во время инцидента, что «мы можем переехать» на самом деле означает «мы можем начать длинную передачу после того, как провайдер одобрит запрос». Планирование выхода — не враждебность к Rackspace. Это честный финал проверки зависимостей.

Опубликованная инфраструктура Rackspace достаточно сильна, чтобы многие клиенты рационально решили не строить аналогичную инфраструктуру сами. В этом экономический смысл управляемого хостинга. Опасность не в использовании провайдера, а в его использовании без сохранения доказательств, нужных для переезда, восстановления или независимой проверки услуги, когда что-то идёт не так.

Корпоративная оболочка полезна, но локальные доказательства важнее

Более широкий корпоративный след Rackspace Technology помогает понять, почему этот гонконгский профиль не стоит рассматривать как крошечного регионального хостера. Rackspace Technology, Inc. фигурирует в материалах SEC как компания, торгующаяся на Nasdaq под тикером RXT, а еёформа 10-K за 2025 годдаёт инвесторам более широкий деловой и рисковый контекст её операций в облаке, хостинге и услугах. Собственнаяглобальная страница дата-центровRackspace представляет след на нескольких рынках и говорит, что площадки используют резервирование по безопасности, питанию, охлаждению и сетям. Эти факты снижают неопределённость идентичности и делают страницы гонконгских площадок убедительнее, чем была бы отдельная посадочная страница.

Но они не снимают потребность в локальных доказательствах. У глобальной компании всё равно могут быть локальное ограничение площадки, региональная зависимость от поставщика, путь вывода конкретного продукта, специфичный для клиента уровень поддержки или схема частного облака, отличающаяся от публичной страницы площадки. Форма 10-K тоже написана для инвесторов, а не для клиента в Гонконге, который хочет знать, какой шкаф, маршрут, система резервного копирования и инженер определят исход субботнего сбоя. Раскрытия публичной компании могут описывать бизнес-риски, сегменты выручки, долг, конкуренцию и операционные допущения.

Они не могут сертифицировать путь восстановления конкретной нагрузки на AS45187.

Корпоративная оболочка меняет метод проверки. С маленьким неизвестным провайдером первая задача может состоять в доказательстве того, что компания и сеть существуют. С Rackspace Hong Kong первая задача — выровнять несколько публичных слоёв, каждый из которых реален: идентичность AS45187 в APNIC, текущие маршрутные данные RIPEstat, строки соединений PeeringDB, страницы площадок HKG1 и HKG5, документацию Rackspace по управляемому хостингу и колокации, а также договор самого клиента. Риск не в том, что каждый слой фальшив. Риск в том, что клиент предполагает, будто все слои одинаково относятся к его услуге.

Поэтому покупателю стоит попросить Rackspace подготовить локальное приложение к договору об услуге. В нём должны быть названы площадка или площадки, релевантные ASN и префиксы, площадка восстановления, место хранения резервных копий, модель поддержки, исключения из обслуживания, план RPKI, меры контроля размещения данных и процесс выхода. Глобальный бренд может упростить получение такого приложения. Заменить его он не может.

Что клиентам стоит проверить, прежде чем доверять гонконгскому рубежу

Первый тест — составление карты. Попросите Rackspace сопоставить услугу с AS45187, площадкой или площадками, продакшен-префиксами, путями управления, путями резервного копирования и системами поддержки. Сравните ответ по ASN с RDAP APNIC, анонсированными префиксами RIPEstat, записью Rackspace Hong Kong в PeeringDB и страницами HKG1/HKG5. Если услуга клиента не использует AS45187, это может быть нормально, но об этом нужно сказать прямо.

Второй тест — отказ. В настольном упражнении или вживую уберите один апстрим, один путь через точку обмена, один маршрутизатор, один компонент хранения, один портал поддержки, одни учётные данные клиента и одну область обслуживания. Зафиксируйте, что происходит с достижимостью, доступом к консоли, DNS, мониторингом, резервным копированием, биллингом, заявками и экспортом данных. Результат должен показать, какая часть услуги работает в режиме active-active, active-standby, только резервном или ручном.

Третий тест — безопасность маршрутов. Спросите о статусе RPKI для точных продакшен-префиксов, включая префиксы, принадлежащие клиенту. Спросите, как меняются ROA при миграции и кто одобряет изменение. Спросите, поддерживаются ли фильтры маршрутов для AS45187 и клиентских анонсов. Публичный статус RPKI unknown не стоит превращать в скандал; его стоит рассматривать как открытый пункт контроля.

Четвёртый тест — поддержка и ремонт. Используйте словарь smart hands из руководства по колокации, чтобы сделать упражнение конкретным. Кто открывает заявку? Кто может позвонить, если портал не работает? Какие задачи включены, тарифицируются или исключены? Какие запчасти предоставляет Rackspace, какие клиент, а какие вендор? Какой SLA smart hands HKG1 применяется и какой эквивалент действует для конкретной услуги HKG5? Если гарантия замены оборудования начинает действовать в течение часа с момента выявления проблемы, кто выявляет проблему и что отмечает старт?

Пятый тест — локализация и выход. Спросите о матрице размещения данных: первичные данные, реплики, резервные копии, логи, записи поддержки и идентичность. Спросите о доказательствах экспорта и о тесте восстановления с замером времени. Материалы PCPD ясно показывают, почему эти вопросы относятся к гонконгскому облачному обсуждению: клиент остаётся ответственным за обработку персональных данных, даже когда использует облачного провайдера или обработчика.

Оценка доказательств

Rackspace IT Hosting AS IT Hosting Provider Hong Kong получает сильную (Strong) оценку публичных сетевых доказательств. Эта оценка отражает видимость идентичности и работы, а не безграничное утверждение о каждой услуге Rackspace. APNIC связывает AS45187 с Rackspace.com Hong Kong Limited. RIPEstat показывает AS45187 как анонсируемый, с 13 префиксами IPv4, 2 префиксами IPv6, полной наблюдаемой видимостью RIS на проверенном снимке и 23 наблюдаемыми соседями. PeeringDB перечисляет Rackspace Hong Kong с двумя портами 10G в точках обмена и строкой площадки в Гонконге.

Rackspace публикует страницы HKG1 и HKG5 с конкретными заявлениями о площадке, питании, операторах, сети и поддержке.

Оценка не выше, потому что публичные доказательства останавливаются на границе клиента. Они не раскрывают назначение стойки клиента, число серверов, зарезервированную мощность, топологию хранения, географию резервных копий, склад запчастей, очередь поддержки, исключения договора, календарь обслуживания или проверенное время выхода. Они также оставляют авторизацию происхождения маршрутов открытым вопросом: выбранные текущие префиксы вернули статус RPKI unknown, а не valid.

Практический вывод узкий и полезный: это не тонкий гонконгский хостинговый след. Это реальное, хорошо задокументированное сетевое и площадочное присутствие Rackspace, которое всё равно требует проверки применительно к услуге. Клиентам не стоит отмахиваться от него как от непроверяемого. Им также не стоит позволять имени Rackspace, двум страницам гонконгских дата-центров или видимой маршрутной поверхности AS45187 заменять доказательства отказоустойчивости, которые реально защищают нагрузку.

Кто ощущает сбой

Первыми сбой AS45187 или гонконгской площадки могут ощутить владельцы приложений, операторы реселлеров, команды финансовых технологий, администраторы SaaS, интернет-ритейлеры, владельцы баз данных, сотрудники комплаенса или сетевые инженеры, пытающиеся удержать услуги клиентов доступными. Последствия могут быстро перейти от потери пакетов к потере выручки, от оповещения о хранилище к пропущенной регуляторной обязанности, от сбоя портала к задержанной миграции или от биллингового спора к административной блокировке.

Масштаб Rackspace может снизить часть рисков. У компании глобальные операции дата-центров, опубликованные SLA, названные гонконгские площадки, зрелый язык поддержки и видимые соединения. Масштаб может также скрыть зависимость, специфичную для клиента. У крупного провайдера может быть много маршрутов, но клиент всё равно зависит от собственного проекта услуги. Крупный провайдер может публиковать гарантии замены оборудования, но клиенту всё равно нужно знать, предоставлен ли отказавший компонент Rackspace, клиентом или контролируется другим поставщиком.

У крупного провайдера могут быть глобальные инженеры, но клиенту всё равно нужен локальный и договорной путь эскалации.

Именно поэтому эта статья рассматривает Rackspace Hong Kong как зависимость, которую нужно понять, а не тайну, которую нужно разгадать. Публичные доказательства хорошие. Физическая инфраструктура названа. Сеть видима. Запись о соединениях содержит полезные детали. Оставшаяся работа — проверить, как эти факты ведут себя, когда реальная нагрузка теряет стойку, апстрим, аппаратный компонент, путь поддержки, биллинговое разрешение, окно обслуживания или маршрут миграции. Размещённая мощность настолько устойчива, насколько прочны доказательства за этими ответами.