Дата-центр Cloud 9 Ltd. должен доказать, что заявленные мощности дата-центра переживут сбои питания и ограничения операторов связи

Кратко

• Конкретный публичный сетевой объект, стоящий за названием в справочнике, сейчас не является активным сетевым рубежом.Обзор ASN для AS203301 в RIPEstatуказывает владельца — Дата-центр Cloud 9 Ltd., но помечает ASN как неанонсируемый на 12 июля 2026 года, астатус маршрутизации в RIPEstatпоказывает ноль анонсированных IPv4- и IPv6-пространств.
• Та же организация Cloud 9 Ltd. имеет гораздо более сильный живой операционный сигнал через AS57814.Статус маршрутизации AS57814 в RIPEstatпоказывает анонсируемый ASN с 27 префиксами IPv4, 3 префиксами IPv6 и 12 наблюдаемыми соседями, атекст реестра RIPEсвязывает AS57814 с ORG-CL434-RIPE — организацией Cloud 9 Ltd.
• Публичный сайт Cloud9 продаёт нейтральный к операторам дата-центр в Тбилиси, колокацию, VPS, VDS, выделенные серверы, домены и общий хостинг. На собственнойстранице дата-центрауказано, что большинство услуг предоставляется из тбилисской площадки, и перечислены заявления об электропитании, охлаждении, пожаротушении, безопасности и межсетевых соединениях.
• Заявления о физической отказоустойчивости необычно конкретны, но остаются заявлениями для покупателей. Cloud9 сообщает, что площадка использует три независимые подстанции, дизель-генератор мощностью 630 кВА, резервирование питания N+N для зоны колокации, охлаждение DX, пожаротушение Novec 1230, плановый доступ на объект и круглосуточное присутствие инженеров; клиентам всё равно нужны доказательства: история обслуживания, наработка генератора, переключение охлаждения и восстановление.
• Уровень доказательности — средний. Есть реальные данные о площадке Cloud 9 Ltd. и маршрутизации AS57814, а также записи PeeringDB для Cloud9 Dinamo Arena и IXP.ge, но конкретный объект AS203301 молчит, а публичные материалы не доказывают аудированные мощности, одновременную работу двух вводов от энергосетей, разнообразие путей операторов, запас мощности или результаты переключения клиентов.

Компания видна, но закреплённый за дата-центром ASN молчит

Первый тест для Дата-центр Cloud 9 Ltd. — не наличие у бренда сайта. А работает ли сегодня конкретный публичный сетевой идентификатор, закреплённый за объектом справочника. Ответ здесь — понижение.Обзор ASN для AS203301 в RIPEstatназывает владельцем Дата-центр Cloud 9 Ltd. и показывает ASN как выделенный, но также сообщает, что ASN не анонсируется.Статус маршрутизации AS203301 в RIPEstatне показывает анонсированных префиксов IPv4, анонсированных префиксов IPv6 и наблюдаемых соседей по данным на 12 июля 2026 года.

Это не мелкая сноска. Если карточка в справочнике, таблица маршрутизации, служебная записка о закупке или заметка клиента рассматривает AS203301 как текущий публичный рубеж сервиса дата-центра, текущие данные эту трактовку не поддерживают.Анонсируемые префиксы AS203301 в RIPEstatвозвращают пустой текущий список.История маршрутизации в RIPEstatпоказывает, что ранее AS203301 анонсировал 185.139.56.0/22 с 2016 года до октября 2023 года, так что ASN не всегда был инертным. Но исторический маршрут — не пригодная для клиентов мощность в 2026 году. Это свидетельство прежней работы, а не текущего сервиса.

Интереснее то, что молчащий AS203301 не заставляет Cloud 9 Ltd. исчезнуть. Он вынуждает разделять выделенный ASN дата-центра и более широкую текущую сеть оператора.Обзор ASN для AS57814 в RIPEstatидентифицирует AS57814 как Cloud9 Cloud 9 Ltd. и помечает его как анонсируемый.Статус маршрутизации AS57814 в RIPEstatсообщает о 27 префиксах IPv4, 3 префиксах IPv6 и полной видимости роут-коллекторами в проверенном представлении.Данные реестра RIPE для AS57814связывают ASN с ORG-CL434-RIPE — тем же идентификатором организации Cloud 9 Ltd., который виден взаписи об организации в RIPE.

Ответственное прочтение — это ни отказ, ни слепая уверенность. AS203301 не следует считать живым рубежом без свежих данных. AS57814 показывает, что у операции Cloud9 есть реальный маршрутизируемый след. Клиент, оценивающий колокацию, VPS или выделенные серверы, должен спросить, какой ASN и какие префиксы несут приобретаемый сервис, выведен ли AS203301 из эксплуатации, зарезервирован или перепрофилирован, и зависит ли какой-либо клиентский сервис от его старого плана маршрутов. Различие важно, потому что сетевой идентификатор — это не брендинг. Это путь, по которому доступные клиентские системы переживают сбой.

Заявленная площадка — единственный якорь в Тбилиси

Публичная позиция Cloud9 прямая: еёстраница дата-центрапредставляет компанию как нейтрального к операторам оператора дата-центра в Грузии и сообщает, что большинство сервисов Cloud9 предоставляется из её дата-центра в Тбилиси. В подвале сайта и настранице контактовуказан адрес: проспект Акакия Церетели, 2, стадион «Динамо», вход 5, Тбилиси, Грузия, 0112.Запись о площадке Cloud9 Dinamo Arena в PeeringDBтакже размещает объект Cloud9 Dinamo Arena по адресу проспект Церетели, 2, в Тбилиси, с организацией Cloud9 LTD и контактами поддержки по электронной почте.

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

Сайт Cloud9 также привязывает несколько сервисов к этому физическому якорю. Настранице колокациипродаются стойки 1U, 2U, tower-серверы, полстойки, целые стойки и клетки (cage). Настранице VPSпродаются управляемые и самостоятельно управляемые виртуальные частные серверы. Настранице VDS— более крупные виртуальные сегменты, а настранице выделенных серверов— физические серверы. Вусловиях обслуживаниякомпании перечислены хостинг, колокация, услуги дата-центра, аренда стоек, кросс-коннекты, блоки распределения питания и межсоединения с интернет-провайдерами как предлагаемые услуги.

Такая широта продуктов повышает ставки. Отказ на единственном тбилисском якоре может затронуть клиентов по-разному: клиент колокации может владеть отказавшим оборудованием, но полагаться на Cloud9 в вопросах питания, охлаждения, доступа и кросс-коннектов; клиент VPS может полагаться на Cloud9 в отношении сервера, хранилища, платформы виртуализации и резервных копий; клиент выделенного сервера — на замену сервера, удалённый доступ и непрерывность сети. Поэтому один и тот же сбой может выглядеть как событие питания, охлаждения, маршрутизации или поддержки в зависимости от контракта клиента.

Данные о местоположении достаточно надёжны, чтобы сделать анализ конкретным. Но сами по себе они не делают сервис отказоустойчивым. Покупателю по-прежнему нужно знать, является ли тбилисская площадка единственным действующим производственным узлом для приобретаемого сервиса, вывозятся ли резервные копии за пределы площадки, используется ли при переключении другая локация Cloud9 или только другой кластер в том же здании, и различают ли клиентские контракты «доступно к продаже» и «пригодно после отказа».

Заявления об электропитании конкретны, но решает время работы под нагрузкой

Публичные заявления Cloud9 об электропитании необычно конкретны для регионального хостинг-провайдера. Настранице дата-центрасказано, что объект питается от трёх независимых подстанций и оснащён дизель-генератором мощностью 630 кВА. Там же указано, что зона колокации использует резервирование питания N+N с поддержкой ИБП.Страница колокацииповторяет обещание на клиентском языке: в пакетах стоек для серверов 1U и 2U указано двухвводное питание A/B, а для tower-серверов — одно питание.

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

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

Резервирование N+N — тоже утверждение, которое требует доказательств на уровне шкафа. Если обе стороны шкафа с двухвводным питанием действительно независимы, отказ одного ввода не должен отключать клиентское оборудование с двумя блоками питания. Но многие клиентские отказы происходят на границе хорошо продуманной схемы питания: одноблочное устройство, подключённое не к тому блоку распределения питания; перегруженная сторона A во время обслуживания; срабатывание автомата из-за всплеска нагрузки клиента; испытание генератора без реальной нагрузки; задача remote hands, оставившая кабель не в той трассе.

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

Пакет tower-сервера важен, потому что в нём открыто используется одно питание. Это не недостаток, а уровень услуги. Но это означает, что клиенты не могут делать вывод об отказоустойчивости всего дата-центра на основании продукта, у которого на устройстве может быть один электрический путь. Покупатель должен сопоставлять критичность нагрузки с конструкцией оборудования. Некритичный сервер может разумно обходиться одним путём питания.

Продакшн-система, которая должна пережить отказ ввода, требует оборудования с двумя блоками питания, проверенного распределения A/B, достаточного запаса по мощности и контракта, объясняющего, что Cloud9 будет делать во время обслуживания.

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

Охлаждение, пожаротушение и безопасность сужают возможные сценарии отказов

Страница объекта содержит сопоставимый набор утверждений об охлаждении, противопожарной защите и физической безопасности. Cloud9 сообщает, что температура и влажность поддерживаются системой охлаждения DX. Утверждается, что серверные помещения не имеют окон и наружных стен, а ближайшие инженерные коммуникации ограничены системой пожаротушения. Также указано, что в дата-центре используется раннее обнаружение температуры, дыма и огня, а также система пожаротушения Novec 1230. Что касается контроля доступа, на странице упомянуты CCTV, биометрический контроль, здание, соответствующее сейсмическим нормам, и охраняемая территория.

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

У противопожарной защиты тоже есть жёсткая граница. Наличие газовой системы пожаротушения успокаивает, только если обнаружение, зонирование, удержание давления, реакция персонала и информирование клиентов актуальны. Ложный пуск может прервать сервис. Настоящий пожар может сделать доступ невозможным, даже если оборудование не уничтожено. Дым или тепловое повреждение могут оставить клиентское оборудование в неопределённом состоянии. Публичное заявление показывает предусмотренный защитный слой, а не проверенный путь восстановления после тревоги.

У безопасности аналогичное различие. Биометрия, CCTV и охрана снижают риск несанкционированного доступа. Но они не отвечают на вопросы: кто может войти в чрезвычайной ситуации, как одобряется доступ клиентов, как быстро выполняется задача remote hands и сохраняется ли доступ к объекту при общегородском сбое. ВFAQ по колокацииCloud9 сказано, что визиты клиентов должны планироваться заранее, а посетителям нужен действительный документ. В условиях сказано, что клиенты колокации могут запросить круглосуточный доступ по предварительной договорённости через клиентский аккаунт или электронную почту. Эти правила разумны, но они также означают, что доступ опосредован службой поддержки и персоналом объекта Cloud9.

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

Нейтральность операторов должна значить больше, чем список операторов

Cloud9 использует словосочетание «нейтральный к операторам» настранице дата-центраи сообщает, что также является оператором IXP. На той же странице указано, что Cloud9 подключён к ведущим телекоммуникационным операторам и небольшим ISP через зарезервированное тёмное волокно с несколькими альтернативными маршрутами и суммарной ёмкостью межсоединений 250 Гбит/с. Настранице колокациисказано, что прямые волоконно-оптические соединения с крупными местными ISP обеспечивают низкую задержку локальной доступности.

Данные о маршрутизации частично поддерживают историю о межсоединениях.Соседи ASN для AS57814 в RIPEstatпоказывают 12 наблюдаемых соседей в проверенном представлении, включая грузинские сети, такие как Magticom, Caucasus Online, System Net, Silknet и Skytel, а также другие соседние сети и IXP.ge.Сетевой профиль AS57814 в PeeringDBперечисляет Cloud9 как региональную сеть сетевых услуг с поддержкой IPv6, открытой политикой пиринга, одной площадкой и одним присутствием на бирже.Запись netixlan Cloud9 в PeeringDBпоказывает подключение 10 Гбит/с на IXP.ge.

Это значимые сигналы. Но их недостаточно, чтобы доказать разнообразие путей операторов. Роут-коллекторы могут показывать соседние ASN, но не могут показать, входят ли разные операторы через разные канализации, разделяют ли кросс-коннекты общую точку встречи (meet-me room), доминирует ли один апстрим в международной доступности, переносят ли локальные пиры продакшн-трафик при отказе апстрима и содержат ли клиентские контракты гарантию разнообразия маршрутов. У сети может быть несколько логических соседей и при этом общий уязвимый физический путь.

Публичная политика маршрутов AS57814 вданных реестра RIPEназывает несколько апстримов или смежных ASN в правилах импорта и экспорта. Запись AS203301 уже: вданных реестра RIPE для AS203301перечислены политики с участием AS34797 и AS35076, тогда как текущий статус маршрутов не показывает живых анонсов. Это ещё одна причина спросить, какой план маршрутов применяется к конкретному клиентскому сервису.

Таким образом, утверждение о нейтральности к операторам правдоподобно, но неполно. Клиент должен запросить текущих апстримов, соглашения о публичном и частном пиринге, варианты кросс-коннектов, физические пути в точке встречи, обязательства по уведомлению об обслуживании, практики безопасности маршрутизации и измеренные результаты переключения. Фраза «нейтральный к операторам» должна означать, что клиент может реально выбирать между операторами и маршрутами. Она не должна означать лишь готовность площадки продать кросс-коннект, если клиент сможет его организовать.

AS57814 показывает масштаб, которого нет у AS203301

Самое сильное текущее сетевое свидетельство — AS57814, а не AS203301. В представлении RIPEstat от 12 июля 2026 года у AS57814 широкий след для грузинского регионального хостингового оператора и оператора дата-центра: 27 префиксов IPv4, 3 префикса IPv6 и полная видимость у пиров RIPE RIS в обеих адресных семействах.Анонсируемые префиксы AS57814 в RIPEstatвключают IPv4-маршруты, такие как 188.93.94.0/24, 185.139.56.0/24, 185.139.57.0/24, 185.139.58.0/24, 45.138.44.0/22 и несколько других /24, а также IPv6-пространство, включая 2a0d:8a00::/32.

Этот масштаб меняет вывод статьи. Если бы существовал только AS203301, уровень доказательности текущей маршрутизации был бы слабым или негативным. AS57814 этого не допускает. Он показывает живую сеть Cloud 9 Ltd. с IPv4 и IPv6, несколькими соседями и текущей поддержкой безопасности маршрутизации.Проверка RPKI для 188.93.94.0/24 под AS57814 в RIPEstatвозвращает валидный результат, и то же верно для проверенных Cloud9-диапазонов /24, выделенных из более старого блока 185.139.56.0/22.

Контраст с AS203301 резкий.Обзор префикса 185.139.56.0/22 в RIPEstatпоказывает, что сам агрегат не анонсируется, а связанные /24 теперь видны.Согласованность маршрутизации префикса 185.139.56.0/22 в RIPEstatпоказывает 185.139.56.0/24, 185.139.57.0/24 и 185.139.58.0/24 в живом BGP под AS57814, тогда как объект маршрута /22 не жив.Проверка RPKI для AS203301 и 185.139.56.0/22 в RIPEstatвозвращает результат invalid-asn, потому что авторизация маршрута в проверенном представлении указывает на AS57814, а не на AS203301.

Это не означает, что Cloud9 неправильно маршрутизирует. Это означает, что действующая авторизация маршрутов, судя по всему, перешла к AS57814. Для покупателя это вопрос документации и отказоустойчивости. Контракты, описания услуг и плейбуки инцидентов должны называть ASN, который фактически несёт сервисный трафик. Если AS203301 сохраняется как спящий или унаследованный объект дата-центра, Cloud9 должна чётко это обозначить. Если ожидается его возвращение, авторизацию происхождения маршрутов и политику маршрутизации следует изменить до того, как клиентский трафик начнёт от него зависеть.

IXP.ge улучшает локальную картину, но не убирает международные риски

Заявлению Cloud9 о межсоединениях помогает свидетельство IXP.ge.Запись IXP.ge в PeeringDBидентифицирует IXP.ge, также известную как Geo-IX, в Тбилиси и отмечает, что биржа доступна в Тбилиси и Кутаиси. Насобственной странице IXP.ge «О нас»цель ассоциации биржи описана как прямой обмен интернет-трафиком между грузинскими сетями без использования сторонних сетей.Страница участников IXP.geперечисляет Cloud9 среди полноправных участников.

Это позитивно для локальной доступности. Когда местные ISP, хостинг-провайдеры и сервисные сети обмениваются трафиком локально, внутренний трафик может избегать лишних обходов через зарубежный транзит. Более низкая задержка и меньшая зависимость от единственного зарубежного пути могут быть важны для грузинских клиентов, контента, государственных сервисов и малого бизнеса, который в основном обслуживает пользователей внутри страны. Это также согласуется с утверждением Cloud9, что локальная связность является отличительной чертой.

Участие в IXP не следует путать с полным резервированием. Пиринг на бирже может снизить нагрузку на транзит и улучшить локальные пути, но автоматически не защищает клиента от отказа питания на объекте, отказа коммутатора, проблем с роут-сервером, обрыва волокна, международных заторов или сбоев DNS и прикладного уровня. PeeringDB в проверенной записи указывает порт Cloud9 на IXP.ge на 10 Гбит/с; собственная страница дата-центра Cloud9 отдельно заявляет 250 Гбит/с суммарной ёмкости межсоединений. Обе цифры могут быть верными, если вторая включает частные кросс-коннекты, апстримы и другие локальные мощности.

Публичные записи не увязывают состав этих цифр.

Более актуальный вопрос — какие пути несут какой трафик при сбое. Если основной международный апстрим откажет, какой объём трафика перейдёт на другие апстримы и с каким качеством? Если порт IXP откажет, останутся ли локальные пользователи доступными через транзит? Если волоконный маршрут до стадиона «Динамо» повреждён, действительно ли альтернативные маршруты раздельны? Если клиент покупает кросс-коннект, идёт ли он по пути, отличному от собственных апстрим-каналов Cloud9, или в одном физическом пучке?

Публичные материалы Cloud9 дают покупателю достаточно, чтобы задать хорошие вопросы. Их недостаточно, чтобы рассматривать локальный пиринг как аварийное восстановление. Лучшая версия сервиса сочетала бы живой рубеж AS57814, локальный трафик IXP.ge, несколько независимых апстримов, видимую гигиену безопасности маршрутизации и понятные клиенту возможности управления трафиком. Публичные записи поддерживают лишь часть этой картины. Физический путь и тесты переключения остаются предметом доказательства.

Пакеты колокации показывают, где может сократиться полезная мощность

Меню колокации Cloud9 необычно прозрачно в отношении базового пакета. Настранице колокацииперечислены пакеты стоек 1U и 2U с двухвводным питанием A/B, каналом 1 Гбит/с и отдельным управляющим каналом. Также указан вариант tower-сервера с одним питанием. На странице сказано, что каждый клиент получает безлимитное подключение 1 Гбит/с к грузинским ISP и глобальное подключение 30 Мбит/с, а варианты полстойки, полной стойки и клетки описаны как индивидуальные или корпоративные решения.

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

Различие между установленной и полезной мощностью здесь важно. Объект может рекламировать высокую суммарную связность, тогда как отдельные продукты продаются с более узкими глобальными лимитами. У стойки может быть двойное питание, а у собственного сервера клиента — один блок питания. Управляющий канал может быть доступен, тогда как отказавшая операционная система всё равно требует действий человека. Клетка может быть индивидуальной, тогда как общие ресурсы объекта, планирование доступа и мощность генератора остаются общими.

FAQ Cloud9 полезен, потому что обозначает границы. При колокации отказ оборудования остаётся ответственностью клиента, тогда как Cloud9 сообщает, что поможет с ремонтом. Визиты нужно планировать. Установка полной стойки или клетки может занять больше времени, чем установка одного сервера. Это обычные условия, но они означают, что восстановление — общее. Клиент не может передать на аутсорсинг любой отказ, просто разместив оборудование в объекте.

Поэтому клиенту следует запросить таблицу отказоустойчивости по каждому продукту. Для сервиса 1U и 2U — что произойдёт при отказе одного ввода? Для tower-сервиса — доступно ли резервирование одиночного питания через автоматический ввод резерва? Для полстоек — какая плотность мощности включена? Для клеток — какие варианты операторов физически доступны? Для всех типов сервиса — какой объём глобальной ёмкости остаётся доступным при обслуживании или отказе апстрима? Публичные таблицы пакетов — полезная отправная точка, а не окончательный ответ.

VPS, VDS и выделенные серверы превращают заявления о площадке в обязательства перед клиентами

Продукты с размещёнными серверами добавляют ещё один слой. Настранице VPSCloud9 предлагает управляемые и самостоятельно управляемые пакеты с виртуализацией KVM, ежедневными резервными копиями, вариантами панели управления и заявленными локальной и глобальной сетевыми скоростями. Настранице VDSпредлагаются более крупные виртуальные серверы с фиксированными ресурсами. Настранице выделенных серверовперечислены управляемые и самостоятельно управляемые пакеты, сказано, что серверы могут быть настроены в течение 24–48 часов при наличии на складе, и описаны накопители корпоративного класса, резервируемые сетевые подключения и резервируемые блоки питания.

Эти заявления переносят риск из чисто инфраструктурного вопроса в операционный. Для клиентов VPS и VDS Cloud9 управляет хостом, хранилищем, слоем виртуализации, системой резервного копирования, выделением IP, панелью управления и каналом поддержки. Клиент может не знать, на каком физическом сервере или стойке выполняется нагрузка. Поэтому доказательство отказоустойчивости должно включать тесты восстановления из резервных копий, реакцию на отказ хоста, изоляцию хранилища, мониторинг, информирование клиентов и возможность переноса виртуального сервера без длительного простоя.

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

Выделенные серверы создают иную нагрузку. Cloud9 сообщает, что наличие процессоров зависит от складских запасов, а индивидуальные требования могут увеличить время установки. Это нормально, но важно при отказе. Если выделенный сервер откажет, есть ли горячий резерв, замена в тот же день или только работа по наличию? Если откажет диск, кто его заменит и как быстро? Если клиент самостоятельно управляет сервером, где заканчивается ответственность Cloud9? Если резервируемые питание и сетевые подключения присутствуют, подключены ли они к независимым путям объекта?

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

Условия раскрывают границы обслуживания и доступа

Условия обслуживания Cloud9важны, потому что раскрывают части операционных границ, которых нет на маркетинговых страницах. В условиях названо ООО Cloud 9, указан идентификатор компании 405063755, грузинский юридический адрес и перечислены категории продуктов, предлагаемых через сайт и портал Cloud9. Услуги дата-центра определены как включающие аренду телекоммуникационных стоек, кросс-коннекты, блоки распределения питания, межсоединения с интернет-провайдерами и мобильными операторами, а также аренду IP-адресов.

Для колокации в условиях сказано, что клиенты должны бронировать доступ на объект через клиентский аккаунт или электронную почту, предоставлять данные посетителей и соблюдать правила поведения в дата-центре. Также указано, что клиенты могут запросить круглосуточный доступ по предварительной договорённости и круглосуточный сервис remote hands для таких задач, как перезагрузка или замена кабеля. Это ценные обязательства, но они всё равно зависят от наличия персонала, обработки заявок и состояния объекта в момент инцидента.

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

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

Контракты часто несут реальный ответ на инфраструктурный риск. Маркетинговые страницы описывают, что оператор хочет продать. Условия описывают, где ответственность разделена, ограничена или регламентирована. В случае Cloud9 условия не подрывают историю о дата-центре; они делают её конкретнее. Они показывают, что доступ клиента, remote hands, плановые работы, резервные копии и поддержка входят в границы сервиса. Задача покупателя — превратить эти пункты в измеримые операционные обязательства.

С защитой маршрутизации на активном рубеже ситуация лучше

Безопасность маршрутизации — одна из областей, где активный рубеж Cloud9 выглядит лучше, чем спящий ASN.Проверка RPKI для 188.93.94.0/24, анонсируемого AS57814, в RIPEstatвозвращает валидный результат. Проверенные префиксы Cloud9 185.139.56.0/24, 185.139.57.0/24, 185.139.58.0/24, 45.138.44.0/22 и 2a0d:8a00::/32 также возвращают валидный результат при проверке против AS57814. Это положительный сигнал гигиены для маршрутов, которые клиенты с большей вероятностью видят сегодня.

Картина по самому AS203301 противоположная. Старый агрегат 185.139.56.0/22 в проверенном обзоре префикса не жив как агрегат, а проверка происхождения этого агрегата от AS203301 возвращает invalid-asn, поскольку видимая авторизация выдана для AS57814. Это не стоит сенсационализировать. Это просто подтверждает, что AS203301 не является текущим маршрутным рубежом для старого адресного блока.

Для покупателя дата-центра это важно, потому что проверка происхождения маршрута может влиять на доступность при изменении маршрута. Если провайдер переносит префикс между ASN, меняет апстримов, вводит резервный анонс или деагрегирует во время инцидента, авторизация маршрута должна совпадать. Иначе сети, фильтрующие невалидные маршруты, могут сбросить трафик именно в тот момент, когда нужна отказоустойчивость. Свидетельство AS57814 у Cloud9 обнадёживает, потому что активный рубеж проходит проверку. AS203301 следует документировать как молчащий, пока авторизация и план маршрутов не будут изменены.

Вопрос покупателя прост: какие префиксы будет использовать мой сервис, каково их текущее состояние RPKI и кто может изменить авторизации в чрезвычайной ситуации? Для клиентов колокации, приносящих собственные адреса, вопрос становится таким: поддерживает ли Cloud9 клиентские объекты маршрутов, ROA, BGP-сессии и срочные изменения маршрутов достаточно быстро? Для адресов, предоставляемых Cloud9, компания должна уметь показать текущее валидное состояние происхождения и объяснить план резервных анонсов.

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

Установленная мощность — не то же самое, что готовая мощность

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

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

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

Местные разрешения и ограничения здания также должны входить в проверку покупателя. Публичные страницы Cloud9 указывают местоположение у стадиона «Динамо» на проспекте Церетели и описывают дата-центр как построенный и управляемый Cloud9, но не раскрывают разрешения на расширение, обязательства по модернизации инженерных сетей, этапы строительства или ограничения арендодателя и площадки стадиона. Это отсутствие — не свидетельство проблемы. Это указание на то, что клиенту не следует считать будущую стойку или клетку готовым активом, пока Cloud9 письменно не подтвердит путь доставки, путь питания, путь охлаждения и путь кросс-коннекта.

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

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

Кто пострадает при отказе тбилисской площадки

Видимая клиентская база раскрыта не полностью, но настранице «О компании»Cloud9 заявляет более 1 200 активных клиентов, более 3 500 активных услуг, более 5 000 зарегистрированных доменов и 99,9 % аптайма систем. Эти цифры опубликованы оператором, и к ним следует относиться как к маркетинговым, если они не закреплены в контракте, но они показывают тип зависимости, о которой идёт речь. Это не просто пустой ASN без клиентских обещаний. Это хостинговый и дата-центровый бизнес, позиционирующий себя как местный инфраструктурный провайдер.

Если тбилисская площадка откажет, разные клиенты пострадают по-разному. Клиенты колокации могут потерять питание, охлаждение, управляющий доступ или аплинк, оставаясь владельцами оборудования. Клиенты VPS могут потерять виртуальные серверы, панели управления, резервные копии или обновления DNS. Клиенты выделенных серверов могут ждать ремонта или замены оборудования. Клиенты доменов и хостинга могут столкнуться со сбоями почты, сайтов и аккаунтов. Клиентам, использующим Cloud9 для миграции или управляемой поддержки, может понадобиться действие персонала в тот же момент, когда все остальные просят о помощи.

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

Данные о маршрутизации свидетельствуют, что у Cloud9 есть реальная сеть, а не маленький тупиковый сегмент. Текущее число префиксов, соседи и поддержка IPv6 у AS57814 значимы. Запись о площадке Cloud9 Dinamo Arena в PeeringDB добавляет физический слой межсоединений. Членство в IXP.ge добавляет значимость локальной биржи. Но публичные записи не показывают результаты переключения клиентов.

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

Именно эта неопределённость делает заголовок статьи важным. Заявленная мощность дата-центра должна переживать сбои питания и ограничения операторов, а не просто описывать их. Публичная история Cloud9 достаточно правдоподобна, чтобы заслуживать проверки, и достаточно конкретна, чтобы проверка была справедливой. Отсутствует не идентичность. Отсутствует проверенная живучесть.

Что повысило бы уровень доказательности

Cloud9 могла бы повысить доверие, не раскрывая чувствительные детали объекта. На публичной странице сети можно было бы указать текущую роль AS203301, активную роль AS57814, основной набор AS, варианты BGP для клиентов, политику безопасности маршрутизации и практику авторизации маршрутов. Страница объекта могла бы, сохраняя безопасность, приводить диапазоны: количество действующих шкафов, доступную плотность стоек, поддерживаемые плотности мощности, наработку генератора, резервирование ИБП, резервирование охлаждения и стандарты уведомлений об обслуживании.

Страница статуса могла бы разделять услуги объекта, сети, хостинга, DNS, портала и электронной почты.

Для корпоративной колокации самым ценным было бы доказательство, специфичное для клиента. Покупатели должны запросить сводку последнего испытания генератора под нагрузкой, подтверждение обслуживания ИБП, схему резервирования охлаждения, целевые сроки реакции remote hands, образцы информирования об инцидентах, доказательства переключения маршрутов, варианты разнообразия кросс-коннектов, размещение резервных копий, данные о времени восстановления и чёткое заявление о том, какие сервисы размещены на единственной площадке. Если ответ различается по продуктам, он должен различаться в письменном виде.

Tower-сервер, сервер 1U с двумя блоками питания, полная стойка и управляемый VDS имеют разные профили риска.

Текущие данные поддерживают средний уровень доказательности. Один AS203301 не жив и должен быть понижен. Более широкая деятельность Cloud9 видна через официальные страницы объекта, правовые условия, маршрутизацию AS57814, записи PeeringDB об объекте и бирже, членство в IXP.ge и валидные проверки происхождения активных префиксов. Оставшиеся пробелы — это те, которые обычно важны при сбое: реальная независимость путей питания, выносливость генератора, переключение охлаждения, физическое разнообразие операторов, влияние обслуживания, запасное оборудование, восстановление из резервных копий и подтверждение миграции клиента.

Практический вывод прямой. Покупателю не следует отвергать Cloud9 только из-за молчащего AS203301. Но и покупать критически важную мощность только потому, что на сайте написано «нейтральный к операторам дата-центр», не стоит. Правильный шаг — рассматривать Cloud9 как реального грузинского оператора дата-центра и хостинга, чьи живые свидетельства сосредоточены в AS57814 и тбилисской площадке, а затем потребовать доказательств, что приобретённый сервис продолжает работать, когда отказывают один ввод питания, один путь охлаждения, один путь оператора, один серверный хост или один канал поддержки.