Кратко

  • Global Cloud Ltd — реальный сетевой оператор, видимый в RIPE, а не просто имя из справочника.Объект организации RIPE для ORG-GCL12-RIPEназывает Global Cloud Ltd, указывает израильский регистрационный номер514919729, отмечает тип организации какLIRи перечисляет адрес: ул. Ха-Масик, 4, Эмек-Хефер, Израиль, с тем же номером телефона, что и на сайте компании.
  • Компания связана с AS61365:обзор AS в RIPEstatуказывает владельцаGC-5222 Global Cloud Ltdи на момент запроса 2026-07-11 показывал AS как анонсируемую.Представление routing-status в RIPEstatпоказало четыре префикса IPv4, 1024 видимых адреса IPv4, ни одного видимого префикса IPv6 и двух наблюдаемых соседей.
  • Адресное пространство компании — не случайный сторонний блок.Запись префикса в RIPE RDAP для 185.184.16.0/22ипредставление whois в RIPEstatидентифицируютIL-GLOBAL-20170102, страну IL, организациюORG-GCL12-RIPE, статусALLOCATED PAи геофид наgeofeed.xprsit.net, который относит /22 и каждый /24 к Эмек-Хеферу.
  • Гарантия источника маршрута лучше, чем у многих небольших хостинговых инфраструктур. Ответы RPKI-валидации RIPEstat для185.184.16.0/24,185.184.17.0/24,185.184.18.0/24и185.184.19.0/24— все вернулиvalidпо ROA для 185.184.16.0/22 с максимальной длиной 24.
  • Картина с вышестоящими операторами всё ещё требует проверки заказчиком.Объект aut-num в RIPEперечисляет политику для AS1680, AS212616 и AS8551, тогда какпредставление ASN-neighbours в RIPEstatпоказало AS1680 и AS212616 как наблюдаемых соседей, а егопредставление AS-routing consistency— AS8551 в политике whois, но не в BGP на момент запроса.
  • Степень доказательности — средняя. Открытые источники убедительно подтверждают юридическую идентичность, контроль над сетевыми ресурсами, текущую доступность IPv4 и валидацию источника маршрута. Они не доказывают количество стоек, право собственности на площадку, глубину резервного оборудования, проверенное восстановление на нескольких площадках, реальный состав клиентских нагрузок, договорные сроки реакции поддержки или ограничения переносимости данных.

Публичный след конкретен, но облачные мощности ещё предстоит подтвердить

Global Cloud Ltd заслуживает иного отношения, чем пустые хостинговые имена, которые встречаются только в собранных скрейпером списках. У компании есть публичная сетевая идентичность, официальный сайт, статус LIR в RIPE, израильский регистрационный номер в объекте организации RIPE, действующая автономная система и зарегистрированное выделение IPv4.Запись aut-num в RIPE RDAP для AS61365называет ASGC-5222, указывает Global Cloud Ltd как организацию и повторяет адрес: ул. Ха-Масик, 4, Эмек-Хефер, Израиль.Английская домашняя страница компанииуказывает контактный адрес «Хамасек, 4, промышленный парк Эмек-Хефер», публикует номер телефона 072-274-3030 и описывает услуги в области разработки, хранения и безопасности.

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

Публичный интернет может показать, что AS61365 доступна; он не может показать, восстановится ли конкретная клиентская нагрузка после отказа полки хранения, спора с поставщиком, сбоя электропитания или изменения маршрутизации.

Поэтому Global Cloud полезнее всего читать как инфраструктуру среднего размера: открытых данных достаточно, чтобы избегать спекуляций, а недостающих операционных деталей — чтобы требовать должной проверки.Английская страница облачных услугкомпании утверждает, что она предлагает услуги дата-центров и облака, DaaS, PaaS, инфраструктуру как услугу (IaaS), сервис совместной работы, ИТ-услуги и программные услуги. Там также сказано, что команда поддержки работает 24/7 и что Global Cloud уделяет особое внимание безопасности и живучести. Это уместные заявления об услугах. Но это не то же самое, что тест на восстановимость.

В доказательствах есть и небольшая, но показательная редакционная деталь. Части английской облачной страницы упоминают «Xpress Technologies», тогда как домен, записи RIPE и подвал сайта ссылаются на Global Cloud. Это может быть устаревший текст, остаток шаблона, смежный бренд или артефакт перевода; открытые данные этого не проясняют. Риск для заказчика не в том, что несовпадение названий доказывает что-то плохое. А в том, что широкие облачные заявления следует сверять с текущими сервисными контрактами, актуальными схемами платформы и реальными границами поддержки, а не выводить из старого или противоречивого текста сайта.

Рабочий тезис этой статьи прост: у Global Cloud Ltd есть реальная израильская сетевая инфраструктура и публичный каталог услуг, достаточно широкий, чтобы создать зависимость заказчика. Задача покупателя — проверить, какая часть этого каталога реально установлена, где физически размещены мощности, как переключаются маршруты, как персонал реагирует в нерабочее время и как рабочие нагрузки покидают провайдера, если сервис перестаёт подходить.

AS61365 даёт Global Cloud измеримое преимущество

Самое сильное доказательство, относящееся именно к компании, начинается с AS61365.Обзор AS в RIPEstatуказывает владельцаGC-5222 Global Cloud Ltdи показывал AS как анонсируемую в 08:00 UTC 11 июля 2026 года.Конечная точка routing-status в RIPEstatпоказала четыре префикса IPv4, 1024 адреса IPv4, ни одного префикса IPv6: маршрут видели 326 из 327 пиров IPv4 с полными таблицами RIS, а видимость IPv6 — нулевая. Четыре текущих анонсируемых префикса вответе announced-prefixes: 185.184.16.0/24, 185.184.17.0/24, 185.184.18.0/24 и 185.184.19.0/24.

Это значимый маршрутизируемый ресурс. Но это и не гипермасштабная инфраструктура. Блок /22, разбитый на четыре объявления /24, может обеспечивать клиентские сервисы, размещённые платформы, VPN, почту, службы рабочих столов, управляющие сети, клиентов со статическими адресами или смешанные сценарии. Сам по себе он не доказывает наличие крупного публичного облака. Количество анонсируемых адресов IPv4 — это не количество серверов, виртуальных машин, арендаторов, репозиториев резервных копий или целей восстановления.

Отсутствие видимости IPv6 в RIPEstat тоже важно: готовность к IPv6 уже входит в сетевые планы многих заказчиков, даже если текущий сервис может работать поверх IPv4.

Конечная точка prefix-count в RIPEstatдобавляет полезную историю. Она показывает нынешнюю картину Global Cloud из четырёх префиксов IPv4 после более ранних изменений видимости и нулевое число префиксов IPv6 на всём окне запроса до 2026-07-11.Конечная точка routing-historyпоказывает более раннюю видимость AS61365 для 94.30.220.0/24 в 2012–2014 годах, а затем семейство 185.184.16.0/22 с 2017 года. Эта история — положительный сигнал на уровне маршрутизации: AS61365 — не эксперимент на одну неделю.

Но непрерывность маршрутов — это не непрерывность сервиса. Переход от старой истории с 94.30.220.0/24 к семейству 185.184.16.0/22 может отражать смену провайдера, изменение сервиса, приобретение адресного ресурса, смену клиента или просто видимую запись других префиксов. Публичный BGP не объясняет деловую причину. Он лишь показывает, что у AS были наблюдаемые маршруты в разные периоды и что текущая маршрутизируемая инфраструктура — это четыре /24 в составе 185.184.16.0/22.

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

Если продаётся IaaS — нужно знать, какая часть стека автоматизирована, а какая представляет собой хостинг с ручной поддержкой.

Выделение /22 подтверждает контроль, а не безграничный масштаб

Доказательства по адресному пространству необычно полезны: они связывают маршрутизируемые префиксы именно с Global Cloud, а не со сторонним арендодателем адресов.Запись префикса в RIPE RDAPдля 185.184.16.0/22 показывает хэндл185.184.16.0 - 185.184.19.255, имяIL-GLOBAL-20170102, типALLOCATED PA, страну IL и организацию Global Cloud.Объект inetnum в RIPE RESTповторяет то же выделение и добавляет URL геофида.Объект организациипоказывает Global Cloud Ltd как LIR. Это важно: такая идентичность сильнее, чем у мелкого провайдера, который просто анонсирует чужой блок.

Более точные метки реестра добавляют красок, но не доказывают клиентское использование.Ответ address-space hierarchy в RIPEstatперечисляет 185.184.16.0/24 какSHVDOM-1-Subnet, 185.184.17.0/24 какSHVDOM-Core-Subnet, 185.184.18.0/24 какLNS-Static-Subentи 185.184.19.0/24 какSHVDOM-Subnet. Эти имена говорят о внутренней сегментации и как минимум одной метке статического доступа или сетевого сервиса. Они не доказывают, какие продукты продаются из каждой подсети, какие клиенты их используют и являются ли метки актуальными операционными описаниями, а не административными именами.

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

Публичный сайт компании иллюстрирует эту мысль. Простой DNS-запрос в ходе исследования показал, что globalcloud.me и www.globalcloud.me резолвятся в 212.29.210.119, апредставление whois в RIPEstat для 212.29.210.119помещает этот адрес внутриIL-NETVISION-980831, а не в выделение Global Cloud 185.184.16.0/22. Это не редкость: многие провайдеры размещают маркетинговый сайт у другого оператора или на чужой платформе. Смысл лишь в том, что конечную точку сайта нельзя считать доказательством того, где живут клиентские облачные нагрузки.

Поэтому правильный вопрос для заказчика — не «есть ли у Global Cloud адреса?». Они есть. Лучший вопрос — как эти адреса распределены по сервисам, переносимы ли клиентские IP-назначения, как устроены обратный DNS и репутация, как прошла бы перенумерация и получит ли покупатель достаточное уведомление, если Global Cloud сменит апстримы, назначения подсетей или сервисные платформы.

RPKI — реальное преимущество в текущих открытых данных

Валидация источника маршрута — один из немногих публичных механизмов, где инфраструктура Global Cloud выглядит сильнее, чем у слабо документированных аналогов. Конечная точка RPKI-валидации RIPEstat вернулаvalidдля 185.184.16.0/24, 185.184.17.0/24, 185.184.18.0/24 и 185.184.19.0/24 при запросе к AS61365. Каждый ответ указывал на валидирующую ROA для 185.184.16.0/22 с источником AS61365 и максимальной длиной 24. Значит, четыре текущих объявления /24 соответствуют опубликованному разрешению источника маршрута на момент запроса.

Техническая ценность узкая, но реальная.RFC 6811описывает валидацию источника префикса BGP как способ маршрутизатора определить, уполномочен ли AS, заявляющий о происхождении префикса, владельцем префикса. RPKI не шифрует пакеты, не предотвращает все утечки маршрутов, не доказывает оптимальность пути, не доказывает устойчивость дата-центра и не решает вопросы безопасности приложений. Но она снижает целый класс рисков ложного анонса источника, когда сети применяют политики валидации.

Для Global Cloud это важно, потому что маршрутизируемая инфраструктура компактна. Если у провайдера четыре видимых /24 и нет видимого IPv6, ошибки источника маршрута могут затронуть большую часть публичной сервисной поверхности. Действующие ROA для текущих объявлений /24 дают заказчикам лучшую стартовую позицию, чем результатunknownилиinvalid. Они также показывают, что в отношении между владельцем адресов и источником маршрута действует как минимум один современный механизм безопасности маршрутизации.

Оговорка в том, что RPKI — это не SLA для заказчика. Она не говорит, что у AS1680, AS212616 или любого другого транзитного пути достаточно ёмкости, чтобы пропустить трафик после сбоя. Она не говорит, что маршрутизаторы зарезервированы. Она не говорит, что DDoS-фильтрация активна. Она не говорит, что клиентские резервные копии восстановимы. Она даже не говорит, что каждый операционный route-объект в порядке.Ответ prefix-routing-consistency в RIPEstatпоказал агрегированный route-объект 185.184.16.0/22 в whois, 185.184.19.0/24 одновременно в BGP и whois, а объявления 185.184.16.0/24, 185.184.17.0/24 и 185.184.18.0/24 — в BGP без соответствующих route-объектов в whois в этом конкретном представлении консистентности.Ответ AS-routing consistency в RIPEstatпоказывает то же расхождение.

Это расхождение — не кризис: состояние RPKI валидно, и агрегированный route-объект существует. Но это полезное операционное свидетельство. Заказчикам стоит спросить, сознательно ли Global Cloud полагается на агрегированный route-объект плюс RPKI для /24, принимают ли фильтры IRR, используемые апстримами, текущие объявления и какой процесс контроля изменений защищает обновления ROA и route-объектов. Небольшое расхождение в представлении реестра может превратиться в крупный инцидент, если фильтр апстрима, route-сервер или транзитный оператор истолкуют его иначе во время обслуживания.

Коротко: RPKI — это преимущество. Его стоит похвалить как действующий механизм контроля — и вернуть на своё место.

Диверсификация транзита видна, но история с отказоустойчивостью не завершена

Самый важный операционный вопрос — не сколько имён провайдеров перечислено в объекте политики. А какие пути смогут пропускать трафик, когда откажет один путь, маршрутизатор, кросс-коннект или коммерческий контракт. Публичных записей Global Cloud достаточно, чтобы задать этот вопрос точно.

Объект aut-num в RIPE для AS61365включает записи политики для AS1680, AS212616 и AS8551. RIPEstat идентифицируетAS1680как Cellcom Fixed Line Communication L.P,AS212616как K.M.A ADVANCED TECHNOLOGIES LTD иAS8551как Bezeq International Ltd. Это серьёзные израильские сетевые имена. Однакоконечная точка ASN-neighboursна момент последнего доступного запроса показала двух наблюдаемых соседей: AS1680 и AS212616. Конечная точка AS-routing consistency показала AS1680 и AS212616 одновременно в BGP и whois, тогда как AS8551 в тот момент присутствовал в whois, но не в BGP.

Выборки путей проясняют картину. Для 185.184.16.0/24 выборочные пути BGP заканчивались цепочкой AS1680 AS61365. Для 185.184.17.0/24 и 185.184.18.0/24 доминирующий видимый паттерн последнего перехода также заканчивался AS1680 AS61365. Для 185.184.19.0/24 видимый паттерн заканчивался AS1680 AS212616 AS61365. Это не полная карта операторов, и публичные коллекторы могут не видеть частные или малозаметные сессии. Но это полезная подсказка: разные /24 могут идти разными соседними или почти соседними путями, и AS212616 виден в пути маршрута как минимум в представлении 185.184.19.0/24.

Заказчикам не стоит читать это ни как «одиночное подключение», ни как «полное резервирование» без дополнительных данных. Лучше читать это как «частично видимый мультихомиинг или сложность провайдерской политики». Заказчику стоит спросить, какие ASN являются активными производственными транзитами, какие — резервными, какие — историческими и какие обслуживают специфические клиентские сервисы. Ответ должен включать гарантированную полосу, разнообразие маршрутизаторов, физическое разнообразие кросс-коннектов, окна обслуживания, обработку DDoS, контакты эскалации и недавние тесты переключения.

Сценарий отказа конкретен. Если у AS1680 региональный инцидент или проблема с фильтром маршрутизации, смогут ли все четыре /24 продолжать работу через AS212616 или другой путь? Если AS212616 участвует в пути 185.184.19.0/24, какой клиентский сервис зависит от этого /24? Если AS8551 есть в объекте политики, но сейчас не виден в BGP, это резервная сессия, неактивная историческая договорённость, запланированный путь или артефакт политики? Если после сбоя трафик переключится, хватит ли провайдеру полосы апстримов и корректных предпочтений маршрутов, чтобы избежать потери пакетов?

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

Эмек-Хефер — сильный сигнал локации, а не сертификат на стойки

У Global Cloud несколько пересекающихся израильских сигналов локации.Объект организации в RIPEперечисляет: ул. Ха-Масик, 4, 3877701, Эмек-Хефер, Израиль.Сущность aut-num в RDAPповторяет этот адрес.Домашняя страница Global Cloudуказывает «Хамасек, 4, промышленный парк Эмек-Хефер» и тот же номер телефона.Файл геофида, указанный в объекте inetnum RIPE, относит 185.184.16.0/22 и каждый из четырёх /24 к кодуIL, IL-HA, Emek Hefer.

Этого достаточно, чтобы обсуждать Израиль и Эмек-Хефер как доминирующий публичный сигнал локации для компании и её адресного пространства. Но этого недостаточно, чтобы утверждать, что каждая клиентская нагрузка, резервная копия, лог, сессия администратора или копия для аварийного восстановления физически находится в Эмек-Хефере. Адрес в реестре IP, локация из геофида и контактные данные офиса — это не аудит площадки.

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

Геолокационные данные тоже показывают, почему нужна осторожность.Представление geoloc в RIPEstatипредставление MaxMind GeoLiteпоместили /22 в Израиль, но в Ар-Рейну, а не в Эмек-Хефер. Это противоречие не опровергает геофид. Базы геолокации по IP часто расходятся, а данные геофида могут отражать намерение оператора или самостоятельно опубликованную локацию. Но это доказывает, что покупателям не стоит использовать геолокацию по IP как гарантию физического размещения.

Вопрос локации важен, потому что каталог Global Cloud включает услуги дата-центров, облака, рабочих столов, платформ, ПО и сервисы, похожие на резервное копирование. На официальнойстранице Управления по защите приватности Израиля о безопасности данныхописаны требования к безопасности данных, действующие в частном и государственном секторах, и организационные механизмы вокруг безопасности баз данных. На том же правительственном портале опубликованыматериалы о регулировании приватности при передаче данных в Израиль из Европейской экономической зоны. Эти официальные страницы не сообщают, какие заказчики Global Cloud обрабатывают персональные данные и является ли Global Cloud обработчиком в каком-либо конкретном контракте. Они объясняют, почему покупатель не может оставлять локализацию данных маркетинговой фразой.

Для заказчика практические вопросы просты. Где размещены основные нагрузки? Где хранятся резервные копии? Зашифрованы ли они и проверены ли? Кто из сотрудников, подрядчиков или вендоров может получать доступ к системам из-за пределов Израиля? Обрабатываются ли логи, потоки мониторинга, тикеты поддержки или системы идентификации на зарубежных платформах? Если заказчик обязан подтверждать израильские, европейские (ЕЭЗ) или отраслевые требования к обработке данных, какие договорные приложения и технические меры предоставит Global Cloud?

Публичные данные Global Cloud подтверждают актуальность темы суверенитета и локализации данных: у компании есть израильские сетевые ресурсы, офис и продажа облачных сервисов. Но они не подтверждают общее заявление о соответствии требованиям.

Каталог услуг достаточно широк, чтобы создать серьёзную зависимость заказчика

Английская облачная страница Global Cloudне ограничивается простым предложением веб-хостинга. Она описывает услуги дата-центров и облака, интеграцию корпоративных систем и терминалов, постоянный мониторинг и обслуживание, виртуализацию на платформах типа VMware и KVM/XEN/Hyper-V, защищённое интернет-соединение, защищённое хранилище, DaaS, PaaS, инфраструктуру как услугу (IaaS), сервис совместной работы, ИТ как услугу (ITaaS) и ПО как услугу (SaaS).Английская страница хостингаповторяет тему дата-центров и облака и перечисляет хостинг, DaaS и телефонные услуги.Страница «О компании»на иврите сообщает, что Global Cloud Ltd основана в 2013 году, и позиционирует компанию вокруг персонального обслуживания местными специалистами.

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

Публичная сетевая инфраструктура может обеспечивать такие сервисы, но не раскрывает их установленную глубину. Четыре видимых /24 могут нести заметную региональную платформу — особенно для сфокусированного израильского провайдера. Но они могут и скрывать гораздо меньший парк, если сервисы поставляются через сторонние платформы или арендованные мощности.

Заявления сайта о безопасности, живучести и поддержке 24/7 стоит перевести в измеримые обязательства: каналы поддержки, время реакции, уведомление об инцидентах, частоту резервного копирования, время восстановления, точку восстановления, экспорт данных, переключение на стороне заказчика и помощь при расторжении.

Одно практическое противоречие в материалах сайта касается времени поддержки. В шапке английской домашней страницы указаны часы работы офиса: воскресенье–четверг, 09:00–18:00, пятница и суббота — выходные. Облачная страница говорит, что команда поддержки работает 24/7. Возможно, объяснение простое: часы продаж отличаются от покрытия технической поддержки. Покупателю стоит зафиксировать это различие в контракте. Что обслуживается 24/7? Что работает по вызову? Для какого уровня критичности предусмотрен немедленный ответ? Какой канал связи работает при сетевом сбое? Размещён ли портал поддержки вне затронутой среды?

Кто может согласовать аварийные изменения в нерабочее время?

Каталог услуг создаёт также зависимость от лицензий и платформ. Облачная страница упоминает поддержку инфраструктуры VMware, XEN и похожей на Microsoft. Заказчику стоит спросить, выделен ли его сервис, является ли он мультитенантным или субподрядным; включены ли лицензии платформы; переносимы ли снимки; можно ли экспортировать образы виртуальных машин в стандартных форматах; и можно ли мигрировать данные идентификации, телефонии или совместной работы без долгого ручного проекта.

Главный урок о рисках для заказчика: публичным данным Global Cloud достаточно верить, чтобы относиться к ним серьёзно. Но они также достаточно широки, чтобы покупатель не принимал одно общее облачное заверение. У каждой услуги в каталоге свой сценарий отказа.

Установленная и доступная мощность могут быстро разойтись

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

В /22 содержится 1024 адреса IPv4. Публичный IPv4 дефицитен, и контроль над /22 ценен для регионального хостингового провайдера. Но количество адресов — это не количество вычислений. Если часть адресов занята инфраструктурой, статическим доступом клиентов, NAT, управлением, почтой, VPN, шлюзами рабочих столов или сетевым оборудованием, публичный пул адресов для новых размещённых сервисов может оказаться меньше, чем кажется по «сырому» числу. Если часть сервисов использует приватные адреса за шлюзами, публичный пул может, наоборот, занижать вычислительную ёмкость. Один только публичный BGP это не прояснит.

Более точные метки подсетей усиливают вопрос.SHVDOM-Core-Subnetзвучит как ядро инфраструктуры;LNS-Static-Subentнамекает на статического абонента или функцию доступа;SHVDOM-SubnetиSHVDOM-1-Subnet— на сегментацию под сервисы. Это лишь метки реестра, но они должны подтолкнуть покупателя сопоставить купленный сервис с реальной зависимостью. Обслуживается ли заказчик DaaS из фермы рабочих столов в одном /24? Связана ли функция статического доступа или LNS с клиентской связностью? Разделены ли облачное управление и клиентские нагрузки? Видны ли резервные сети или они приватные?

Доступная мощность зависит и от запаса оборудования. Если сервер выходит из строя, может ли Global Cloud заменить его локально, или ремонт зависит от складских запасов вендора и сроков поставки? Если откажет маршрутизатор или межсетевой экран, есть ли на площадке запасной с актуальной конфигурацией? Если деградирует массив хранения, хватит ли запаса, чтобы пересобрать его без обвала производительности? Если кластер гипервизоров теряет узел, рассчитаны ли оставшиеся хосты по схеме N+1 или только на среднюю нагрузку?

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

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

Главный сценарий отказа, рассматриваемый в этом материале, не теоретический. Для Global Cloud наиболее правдоподобные публичные сценарии отказа — перебой в стойке или на площадке, проблемы с апстримом или фильтрами маршрутов, нехватка оборудования, сбой эскалации поддержки, трения по биллингу или контракту с провайдером и ограничения миграции.

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

Заказчику стоит запросить список площадок под соглашение о конфиденциальности, если нужно, но ответ всё равно должен показать, делят ли основная, резервная и управляющая системы единую зону отказа.

Сбой апстрима проверил бы зависимость от AS1680 и AS212616. Публичные записи соседей и консистентности показывают двух наблюдаемых пиров, тогда как AS8551 есть в политике, но не виден в BGP на момент запроса. Заказчику стоит спросить, есть ли у каждого маршрутизируемого /24 как минимум два активных пути, заходят ли эти пути в разные маршрутизаторы и здания, рассчитаны ли все пути на переключение и не зависит ли защита от DDoS от одного оператора. Ответом должна быть актуальная сетевая схема, а не только объект реестра.

Отказ из-за нехватки оборудования проверил бы экономику сервиса. Небольшие провайдеры могут отлично работать при продуманном локальном запасе и понятном вендорском покрытии. Но они могут и застрять, если отказавший диск, блок питания, модуль маршрутизатора или межсетевой экран приходится заказывать уже после начала инцидента. Заказчику стоит запросить целевые сроки замены по типам сервиса: виртуальный хост, выделенный сервер, полка хранения, коммутатор top-of-rack, граничный маршрутизатор, межсетевой экран, устройство резервного копирования и клиентское оборудование, если оно есть.

Сбой поддержки проверил бы разницу между формулировкой 24/7 и живой эскалацией. Заявление сайта о поддержке 24/7 полезно, но заказчикам стоит определить уровни критичности, каналы тикетов, телефонную эскалацию, языковое покрытие, полномочия в нерабочее время и коммуникацию об инцидентах. Если портал поддержки или почта зависят от той же сети провайдера, заказчик должен знать внеполосный канал связи.

Сбой по биллингу или контракту с провайдером менее драматичен, чем отключение электричества, но может быть не менее разрушительным. Поскольку Global Cloud — LIR с собственным адресным пространством, зависимость от адресных ресурсов выглядит более контролируемой, чем у провайдеров, анонсирующих арендованные блоки. Тем не менее транзит, лицензии на ПО, аренда дата-центров, резервные сервисы и услуги, связанные с Microsoft, могут создавать договорные зависимости. Заказчикам стоит спросить, какой срок уведомления действует до того, как на них повлияют изменения цен, IP, платформы или поставщиков.

Сбой миграции — самый тихий риск. Если заказчик хочет уйти, сможет ли он экспортировать образы виртуальных машин, профили рабочих столов, почтовые данные, базы данных ПО, конфигурацию телефонии, политику межсетевого экрана, DNS-зоны, логи и резервные копии в пригодных форматах? Предоставляет ли Global Cloud оплачиваемое окно параллельной работы? Могут ли переехать клиентские IP-адреса или только DNS-имена? Правильное время отвечать на эти вопросы — до того, как сервис станет критичным.

Кто страдает при сбое такого провайдера

Пострадавшие пользователи — это, скорее всего, не абстрактные гипермасштабные заказчики. Сайт Global Cloud обращён к бизнесам, которым нужны интеграция, виртуальные рабочие столы, программные системы, телефония, совместная работа, хостинг и управляемый ИТ. Это указывает на малые и средние организации, кол-центры, команды разработки, ритейлеров, профессиональные сервисные фирмы и местные предприятия, которые не хотят эксплуатировать собственную инфраструктуру. Для таких заказчиков провайдер — не просто вендор.

Это место, куда сотрудники входят каждое утро, где работают приложения, где лежат резервные копии или где телефония и инструменты совместной работы зависят от идентификации и сетевого доступа.

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

Именно поэтому широкий каталог Global Cloud повышает нагрузку по проверке. Провайдера, продающего только статический веб-хостинг, можно оценить одним набором проверок. Провайдеру, продающему услуги дата-центров, облако, рабочие столы, платформы, ПО, совместную работу и ИТ-услуги, нужна карта рисков по каждому сервису. Одна и та же граница AS61365 может относиться к нескольким продуктам, но у каждого продукта свои требования к состоянию данных, восстановлению и миграции.

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

Global Cloud может быть практичным региональным провайдером для заказчиков, которым нужна локальная поддержка и израильская маршрутизация. Публичные данные подтверждают такую возможность. Но они не снимают необходимость проверить сценарии отказа до того, как провайдер станет единственной точкой непрерывности бизнеса.

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

Текущие открытые данные заслуживают средней оценки: слой сетевых ресурсов силён, а слой сервисной мощности задокументирован слабо. Оценка повысилась бы, если бы Global Cloud опубликовала или предоставила несколько видов проверяемых операционных данных.

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

Во-вторых, компания могла бы предоставить актуальную сводку по маршрутизации и транзиту. AS1680 и AS212616 видны в BGP; AS8551 есть в политике. Провайдер мог бы сказать, какие из них активные, резервные или исторические; есть ли у каждого /24 активное разнообразие маршрутов; проверено ли переключение; и чего ждать заказчикам во время обслуживания. Компания могла бы также опубликовать профиль в PeeringDB.API-запрос PeeringDB для ASN 61365на момент исследования вернул ответ 404 Субъект-not-found, то есть через этот API-запрос публичного сетевого профиля PeeringDB не было. PeeringDB — добровольный сервис, так что отсутствие не является доказательством отсутствия. Но это всё же упущенная возможность раскрыть информацию о соединениях, площадках и контактах.

В-третьих, компания могла бы задокументировать цели резервного копирования и восстановления для каждого продукта. DaaS, IaaS, хостинг, ПО и телефония не должны делить одно общее обещание о резервных копиях. У каждого должны быть дата последнего проверенного восстановления, целевое время восстановления, целевая точка восстановления, исключения и обязанности заказчика. Если восстановление зависит от дополнительно купленных опций резервного копирования, это должно быть явно указано.

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

В-пятых, компания могла бы привести публичные описания услуг в порядок. Английская страница услуг пригодна для чтения, но смешение формулировок Global Cloud и Xpress Technologies, опечатки и частично переведённый контент мешают стороннему наблюдателю понять, какие заявления актуальны. Более аккуратный каталог услуг не доказал бы живучесть, но снизил бы неоднозначность.

Эти улучшения не косметические. Они превратили бы заслуживающую доверия маршрутизируемую инфраструктуру в более проверяемую зависимость для заказчика.

Практические вопросы для заказчика

Заказчику, рассматривающему Global Cloud, стоит начать с фактов, которые уже хороши. Попросите компанию подтвердить, что AS61365 и 185.184.16.0/22 — текущая производственная граница для покупаемого сервиса. Спросите, какие из 185.184.16.0/24, 185.184.17.0/24, 185.184.18.0/24 и 185.184.19.0/24 используются для сервиса. Спросите, остаются ли ROA RPKI валидными и кто утверждает изменения маршрутов. Спросите, достаточно ли состояния route-объектов и IRR для всех фильтров апстримов.

Затем задайте физические вопросы. Где размещён основной сервис? Стойка, клетка или зал дата-центра — собственность, аренда или субподряд? Какие линии питания, ИБП, генераторы, системы охлаждения и процессы удалённых рук задействованы? Какой запас оборудования есть на площадке? Кто может войти в нерабочее время? Какие сервисы делят одно здание, а какие разделены?

Затем задайте сетевые вопросы. Какие апстримы сегодня несут производственный трафик? Какие находятся в резерве? Может ли AS1680 или AS212616 самостоятельно выдержать полную нагрузку? Какова текущая роль AS8551? Есть ли отдельные маршрутизаторы и кросс-коннекты? Зависят ли меры защиты от DDoS от конкретного оператора? Проходят ли изменения BGP коллегиальное рецензирование и тесты?

Затем задайте вопросы о поддержке. Что означает 24/7 на практике? Покрывает ли это телефонную поддержку, реакцию инженеров, мониторинг, аварийные изменения и коммуникацию с заказчиками? Что происходит в пятницу или субботу, когда публичная линия в часы офиса объявляет о закрытии? Каков внеполосный путь связи, если сеть самого провайдера повреждена?

Затем задайте вопросы о данных. Где хранятся основные данные, резервные копии, логи и данные тикетов поддержки? Какие платформы обрабатывают данные идентификации, почты, мониторинга или совместной работы? Какие нормативные требования должен выполнять заказчик и какие доказательства может предоставить Global Cloud? Как шифруются, восстанавливаются и удаляются резервные копии?

Наконец, задайте вопросы о выходе. Как заказчик может экспортировать системы, данные и конфигурацию? Может ли он сохранить IP-адреса или придётся перенумеровываться? Какова длительность окна параллельной работы? Какая помощь включена? Что произойдёт, если расторжение последует после спора об оплате, инцидента с сервисом или смены поставщика?

Эти вопросы не предполагают, что Global Cloud слаба. Они исходят из того, что размещённые мощности физичны, договорны и операционны, даже когда продаются как облако.

Вывод: сеть вызывает доверие, но восстановимость доказана не полностью

Global Cloud Ltd в публичных записях выглядит более весомой, чем предполагала исходная гипотеза о малой инфраструктуре. У компании есть объект организации LIR в RIPE, действующий AS, понятное выделение IPv4, четыре текущих видимых объявления /24, валидное покрытие RPKI источника маршрута, израильские сигналы локации и официальный каталог услуг вокруг облака, хостинга, рабочих столов, ПО, совместной работы и управляемого ИТ. Этого достаточно, чтобы считать её заслуживающим доверия субъектом инфраструктурной компании.

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

Именно поэтому заголовок статьи намеренно физичен. Global Cloud продаёт размещённые мощности, но ценность этих мощностей по-прежнему зависит от стоек, транзита и ремонтных окон. AS61365 может быть видимой, пока заказчик всё ещё сталкивается с проблемой восстановления. /22 может быть аккуратно зарегистрирован, пока покупателю всё ещё нужны доказательства наличия запасного оборудования. Валидная ROA может защищать валидацию источника, пока инцидент у апстрима всё ещё испытывает переключение. Заявление о поддержке 24/7 может быть правдивым, пока заказчику всё ещё нужны детали эскалации.

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