IBM Cloud продаёт выбор региона, ограниченный физикой дата-центров и транзита

Кратко

• IBM Cloud публикует одну из самых полезных публичных карт расположения на облачном рынке: полные мультизонные регионы, мультизонные регионы на одной площадке, коды классических дата-центров, универсальные имена зон и коды PoP. Такая карта позволяет клиенту связать выбор региона с физическими группами дата-центров, а не считать имя региона чисто программной абстракцией.
• Эти же материалы не дают фактов, которые решают исход жёсткого сценария восстановления. Публичная документация не раскрывает точное владение площадками, мегаватты по каждому объекту, текущую загрузку стоек, топологию электроснабжения, маршруты тёмного волокна, фактическую загрузку магистрали, разнообразие операторов связи в Direct Link или свободную резервную ёмкость.
• Собственные документы IBM сужают часть маркетинговых обещаний. Зависящие от оборудования профили доступны не везде, запросы на классические виртуальные серверы могут упираться в нехватку ёмкости, наличие bare-metal меняется по дата-центрам, Direct Link не резервируется автоматически, а зональные ресурсы VPC не переносятся в другую зону при полном отказе зоны.
• Материалы IBM об инцидентах, миграциях и закрытии площадок делают инфраструктурный тезис конкретным. Отключения сети, отказы питания систем охлаждения, пожары, сбои внутренних сетей объектов и запланированное закрытие CHE01 показывают, что география облака — это не только вопрос соответствия требованиям; это зависимость от реальных зданий, эксплуатирующих организаций, операторов связи, окон обслуживания и ёмкости переноса данных.

Метка региона — это физический выбор

Самое полезное вдокументации IBM Cloud о расположении— то, что она не оставляет клиента с чисто абстрактным списком регионов. В ней объясняется, что IBM Cloud использует полные мультизонные регионы, мультизонные регионы на одной площадке и классические дата-центры. Имена регионов, которые появляются в инструментах и сценариях консоли, соответствуют физическим группам дата-центров. Даллас, Сан-Паулу, Торонто, Вашингтон, Франкфурт, Лондон, Мадрид, Сидней и Токио — это не только география продаж. Это выбор регионов, чьи зоны VPC сопоставляются с универсальными именами зон, а эти универсальные имена указывают на коды лежащих в основе дата-центров, например DAL10, FRA05, LON06, SYD04 или TOK05.

Это делает IBM Cloud более проверяемым, чем провайдер, у которого публичная карта заканчивается на названии города. Клиент видит, что ресурс VPC в логической зоне не висит в безымянном облаке. Он привязан к сопоставлению зон для конкретного аккаунта и к коду физического расположения. Классическая инфраструктура и ресурсы Power Virtual Server ещё прямее: местоположение задаётся кодом дата-центра, а не абстракцией региона. IBM также перечисляет 42 кода классических дата-центров в Северной и Южной Америке, Европе и Азиатско-Тихоокеанском регионе. В этом списке есть давно живущие имена: DAL08, AMS03, FRA05, LON02, CHE01, SNG01 и TOK05.

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

Это различие важно, потому что покупатели облачных услуг часто выбирают регион как объект соответствия требованиям и задержек, а потом при проектировании или восстановлении обнаруживают, что это ещё и складской объект. Если клиенту нужен конкретный профиль bare-metal, классический сервер с GPU, PoP Direct Link, локальный класс Object Storage или резервная зона, способная принять отказавшую нагрузку, имя региона — лишь первый фильтр. Настоящий вопрос в том, доступны ли нужные сервис, профиль, канал и цель восстановления в той физической части IBM Cloud, которой может воспользоваться аккаунт.

SoftLayer оставила хостинговую инфраструктуру, а не бесконечно эластичный пул

Нынешняя инфраструктурная база IBM Cloud до сих пор несёт форму хостингового бизнеса. Вформе 10-Q IBM за 2013 годуказано приобретение SoftLayer за 1,977 млрд долларов. Висторическом FAQ IBM о приобретении SoftLayerописывался бизнес выделенной и виртуальной инфраструктуры с базой в Далласе и большой клиентской базой. Это происхождение важно, потому что SoftLayer родилась не как чисто региональная гипермасштабная абстракция. Это была хостинговая платформа, построенная на дата-центрах, запасах bare-metal, VLAN, частных сетях, серверах под конкретного клиента и операционных процедурах вокруг именованных объектов.

Современная платформа IBM Cloud наслоила VPC, управляемые сервисы, Object Storage, Kubernetes, OpenShift и глобальные платформенные сервисы поверх этой базы. Однако список классических дата-центров до сих пор существует, а некоторые уведомления о миграции и жизненном цикле прямо ссылаются на коды дата-центров. В документе о расположении говорится, что классические дата-центры размещают ресурсы электропитания, охлаждения, вычислений, сети и хранения и используют архитектуру POD. POD — это не маркетинговый эпитет. Это единица ёмкости из стоек, серверов, сетей, хранилищ и резервных генераторов. Добавление POD меняет то, что можно продавать.

Исчерпание сервера, маршрутизатора, типа хранилища или электрического лимита меняет то, что можно предоставить.

Поэтому анонсы расширения, например объявление IBM о расширении VPC в Далласе (DAL14), не стоит читать как доказательство безграничной ёмкости. В объявлении названа добавленная площадка зоны доступности в Далласе и объясняется, зачем IBM нужно было больше мощностей в Далласе. В нём не раскрываются установленные мегаватты, количество серверов, текущая загрузка, условия аренды, партии оборудования или обязательства клиентов. Это полезное свидетельство того, что IBM добавляла физическую площадку дата-центра для обслуживания региона.

Но это не доказательство того, что любой более поздний заказ клиента может рассчитывать на свободный запас по каждому профилю в Далласе.

То же самое верно в обратную сторону для площадок, которые выходят из эксплуатации. Вуведомлении IBM о закрытии CHE01говорится, что работа Chennai 01 будет прекращена 10 июня 2027 года. В уведомлении установлены сроки прекращения приёма заказов, удаления возможности новых развёртываний, окна планового отключения сети, окончания приёма заявок на помощь с миграцией и финальных окон миграции PaaS и IaaS. Уведомление о закрытии — редкий облачный документ, потому что он вскрывает инфраструктурную правду, обычно скрытую за консолью: у облачных площадок есть жизненный цикл. Их можно добавлять, ограничивать, модернизировать, консолидировать и закрывать. Клиент, который считал CHE01 постоянным размещением, теперь должен превратить решение о локации в проект миграции.

Полные MZR и MZR на одной площадке — это разная география отказов

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

MZR на одной площадке несут другую правду. Та же документация IBM относит Chennai — Airtel, Montreal, Mumbai — Airtel и Osaka к MZR на одной площадке. IBM говорит, что их зоны находятся в разных секциях одного здания или в нескольких зданиях на одной территории, и что зависимости по электроэнергии, охлаждению, сети и физической безопасности могут пересекаться. Это не мелкая оговорка. Это меняет модель отказов.

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

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

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

Для закупок это означает: покупатель должен запросить сопоставление зон своего аккаунта, прежде чем считать разнообразие зон физическим разнообразием. IBM говорит, что логическое сопоставление зон аккаунта устанавливается при создании первого ресурса VPC в регионе. Две команды, говорящие «зона 1», могут иметь в виду локальный логический идентификатор аккаунта, а не автоматически один и тот же универсальный код дата-центра. Универсальное имя зоны — более сильное свидетельство. Без него диаграмма отказоустойчивости может выглядеть физически точнее, чем она есть.

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

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

Вторая граница — наличие в реальном времени. На странице устранения неполадок классических виртуальных серверов IBM описан сценарий ошибки «недостаточно ёмкости», когда у маршрутизатора или дата-центра нет ресурсов для выполнения запроса. Рекомендации IBM показательны для операционной практики: попробуйте другой маршрутизатор, не указывайте маршрутизатор, используйте другой дата-центр, запросите меньше экземпляров, выберите меньшие размеры или измените тип хранилища. Это не проблема облачной теории. Это проблема размещения ресурсов.

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

Третья граница — привязка оборудования к локации. На той же странице устранения неполадок предоставление GPU ограничено перечисленными классическими дата-центрами. Сам список напоминает, что специализированное оборудование не размазано равномерно по карте. Клиент, проектирующий ИИ-инференс, графические нагрузки или восстановление на ускорителях, не может считать все регионы IBM Cloud равноценными. Тот же принцип виден в документации по bare-metal.

Bare-metal-серверы — это выделенные физические машины, запас для быстрого предоставления предварительно сконфигурирован, кастомные серверы зависят от сложности и объёма, а процесс предоставления показывает динамическое наличие по дата-центрам. IBM также описывает стресс-тестирование, которое может увеличить сроки, а часть улучшений серверов зависит от конфигурации.

Это делает ёмкость более понятной, но и более хрупкой. Динамический показ наличия помогает покупателю избежать фантазийного планирования, но данные меняются непрерывно. Предварительно сконфигурированный сервер, который виден при проектировании, может исчезнуть к началу учений по аварийному восстановлению. Резервирование VPC может закрепить выделенную зональную вычислительную ёмкость, но оно не резервирует каждую зависимость по хранилищу, сети, резервному копированию, Object Storage, Direct Link, поддержке или целевому региону. В регионе с доступными виртуальными серверами может не оказаться нужного профиля bare-metal.

В регионе с подходящим сервером может не оказаться частного канала клиента в нужном PoP.

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

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

Электропитание и охлаждение лежат ниже облачного контракта

В документации IBM по отказоустойчивости сказано, что дата-центры используют несколько вводов электропитания, волоконно-оптические линии, собственные генераторы и резервные батареи. На маркетинговой странице глобальных дата-центров IBM описаны резервирование электропитания и охлаждения N+1, безопасность и оптимизация пространства, мощности, сети и персонала. Корпоративные экологические раскрытия добавляют агрегированные данные о PUE дата-центров, закупках возобновляемой электроэнергии и роли поставщиков или арендодателей в снабжении электроэнергией.

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

Но эти материалы — не проверка электроснабжения на уровне площадки. В них не сказано, сколько сетевой мощности выделено для FRA05, DAL14, SAO01, CHE01 или TOK05. Не раскрыты контракты на топливо, время работы генераторов, длительность работы батарей по залам, резервирование трансформаторов, схема охлаждения, риски затопления, обязательства арендодателя, окна обслуживания, возраст распределительных устройств или нагрузка в момент жары и сбоя сети.

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

В собственном руководстве IBM по высокой доступности есть небольшая, но важная оговорка об оборудовании: на некоторых давно работающих площадках стоят серверные шасси 1U с одним процессором, которые могут не поддерживать двойной ввод питания. Эту деталь не стоит раздувать в общее обвинение IBM Cloud. Она полезна, потому что показывает, как старое оборудование и схемы на объектах могут пробить широкое заявление о резервировании. Дата-центр может иметь несколько вводов питания, а конкретное шасси или конфигурация клиента всё равно оставаться без защиты двойным вводом. Надёжность живёт на самом нижнем значимом уровне.

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

Внутренняя сеть объекта может нарушить сервисы, даже если клиент не менял код приложения.

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

Магистраль обширна, но частный вход — отдельная история

Сетевая картина IBM Cloud сильна на уровне платформы. IBM описывает трафик между дата-центрами как остающийся в её магистрали и внутри её ASN для частной связности. В документации по отказоустойчивости описаны провайдеры тёмного волокна, соединяющие граничные площадки с региональными вычислительными объектами, резервная магистральная связность с другими регионами и пиринг с несколькими провайдерами напрямую и через локальные точки обмена.Запись AS36351 в PeeringDBдобавляет рыночный сигнал: SoftLayer/IBM Cloud имеет международное присутствие в точках обмена и публично видимую сетевую идентичность.

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

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

Граница ещё яснее сIBM Cloud Direct Link. Direct Link — это частный вход уровня 3 из сети клиента в IBM Cloud.Страница предварительных требований IBMнеобычно прямо говорит о разделении ответственности. Клиент должен организовать и оплатить путь до PoP, кросс-коннекты и канал провайдера. Один путь обслуживания Direct Link не защищён. Для резервирования нужно больше одного соединения, отдельные маршрутизаторы на стороне IBM или географически разнесённые PoP, а также настройка маршрутизации клиентом. IBM также говорит, что не размещает оборудование клиентов в сетевых PoP IBM.

Это значит, что отказоустойчивость частного облачного подключения создаётся совместно. IBM управляет точкой окончания сервиса и облачной сетью на своей стороне. Клиент и его оператор связи управляют маршрутом до PoP, заказом кросс-коннекта, абонентской линией, парой маршрутизаторов, политикой BGP и разнообразием магистрального пути. Руководство IBM по разнообразию Direct Link и FAQ могут показать правильный архитектурный шаблон, но диаграмма — не доказательство того, что два канала идут по разным физическим маршрутам.

Пути с равной стоимостью могут сойтись на общем маршрутизаторе или общей внешней кабельной инфраструктуре, если реализация плохая.

Практический путь отказа часто зауряден. Клиент покупает два канала, видит две BGP-сессии и называет результат резервированием. А затем комната встречи операторов в здании, передача оператору, траншея на последней миле, политика маршрутизации, приостановка из-за оплаты, обслуживание маршрутизатора или ошибочная миграция VRF создают единую точку отказа. В документации IBM даже отмечено, что Direct Link может быть приостановлен по причинам, связанным с выставлением счетов.

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

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

Документация IBM по VPC разделяет панель управления и панель данных, и это разделение важно. Если у панели управления проблемы, уже предоставленные ресурсы могут продолжать работать. Если панель данных в зоне выходит из строя, региональные или другие зональные средства управления могут продолжать управлять здоровыми зонами. Это архитектура, которая может сделать облако более устойчивым, чем единый хостинговый объект. Но она же создаёт распространённое заблуждение: если консоль доступна и панель управления может создавать ресурсы в другом месте, клиенты могут предположить, что нагрузку можно восстановить без физического трения.

Руководство по аварийному восстановлению VPC говорит об обратном. При полном отказе зоны зональные ресурсы недоступны, а экземпляры виртуальных серверов в отказавшей зоне не переносятся автоматически в здоровую зону. Клиент должен спроектировать высокую доступность приложения между зонами или восстанавливаться в доступное местоположение. Для регионального аварийного восстановления IBM указывает на скрипты, Terraform, Object Storage, Schematics и развёртываемые архитектуры. Клиент должен поддерживать внешний источник истины для конфигурации VPC, хранить копии данных и тестировать план.

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

Именно здесь ёмкость и восстановление становятся одной задачей. Снапшот, который существует только в отказавшем регионе, — не актив для удалённого восстановления. Конфигурационный файл, который ни разу не применялся в другом регионе, — не протестированное переключение. Балансировщик на уровне зоны не спасёт нагрузку, которая не была спроектирована для горизонтального масштабирования. Bare-metal-сервер с локальными дисками — это другая задача восстановления, чем виртуальный сервер с удалёнными блочными снапшотами. В документации IBM по восстановлению bare-metal сказано, что IBM не создаёт резервные копии устройств клиента автоматически.

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

Документация по снапшотам блочного хранилищадобавляет к восстановлению физическое измерение. Снапшоты и межрегиональные копии полезны, но удалённые копии требуют времени и создают расходы на передачу и хранение. В примере IBM полная удалённая копия объёмом 3 ТБ занимает часы, а не секунды. Клоны быстрого восстановления могут помочь, но их нужно включить и оплатить готовность внутри зоны. Само по себе это не слабость. Так работает перенос данных. Риск возникает, когда покупатель относится к существованию снапшота так, будто это уже восстановленные вычисления в другом регионе.

Object Storage несёт похожий урок. В FAQ по Object Storage IBM различает межрегиональную, региональную и однообъектную отказоустойчивость и говорит, что смена расположения бакета требует создания нового бакета и переноса данных. Руководство по переносу бакетов обсуждает копирование, проверку целостности, выбор конечной точки, размещение вычислений и конфигурацию, которую придётся воссоздать. Бакет может быть доступен по всему миру, но его класс отказоустойчивости и физическое расположение по-прежнему важны. Переносить его во время стрессового события — не то же самое, что выбрать правильный класс заранее.

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

Материалы IBM Cloud о размещении данных дают клиентам повод заботиться о выборе региона помимо задержек. Для региональных и зональных сервисов IBM говорит, что клиентский контент хранится и обрабатывается в выбранном регионе с учётом поведения и условий соответствующего сервиса. Настройка аккаунта с поддержкой ЕС добавляет ещё один слой: обычная поддержка для подходящих сервисов может направляться командам в ЕС, при этом ограниченный по времени доступ специалистов из-за пределов ЕС возможен в рассмотренных нерешённых случаях.

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

Это полезно, потому что пресекает распространённый упрощённый подход. Клиент не может просто спросить, находятся ли данные во Франкфурте, Лондоне, Мадриде или Торонто, и объявить операционный риск закрытым. Регион контролирует большую часть физического размещения, но сервис может по-прежнему зависеть от глобальных платформенных функций для идентификации, выставления счетов, каталога, поддержки, учёта использования, управления публичными IP, DNS, управления Direct Link, предоставления Object Storage или других задач управления.

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

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

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

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

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

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

Инциденты превращают архитектуру в доказательства

Документы по облачной архитектуре описывают, что должно происходить. Записи об инцидентах показывают, какие части системы действительно испытывали нагрузку. Отчёты об инцидентах и история статусов IBM Cloud важны не потому, что выставляют IBM исключительно хрупкой, а потому, что вскрывают обычные классы инфраструктуры, которые важны в любом облаке: сетевое электроснабжение, пожар, питание охлаждения, внутренняя сеть объекта, доступ к сервисам и мультирегиональные пути управления.

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

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

Урок для клиента — сопоставлять инциденты с архитектурой. Если нагрузка спроектирована по трём зонам полного MZR, событие на объекте в одной зоне не должно создавать такой же отказ, как одноединичная схема. Если система построена в одной зоне с одним Direct Link и одной локальной резервной копией, то же событие может превратиться в прерывание сервиса, упражнение по восстановлению данных и эскалацию в поддержку. Документы IBM по SLO и SLA могут определять компенсации и цели, но компенсации не переносят данные, не пересобирают серверы и не открывают канал заново. Они распределяют коммерческое возмещение задним числом.

Свидетельства об инцидентах должны также изменить то, как клиенты читают формулировку «где возможно» в языке о разнообразии магистрали. IBM говорит, что использует разных провайдеров и резервную связность в своей сети. Это полезно, но документация самого оператора не доказывает каждый клиентский путь и каждое локальное граничное условие. Настоящая отказоустойчивость требует сопоставления архитектурного слоя с уровнем отказа. Магистраль с разнообразием провайдеров не спасёт клиента, если единственный частный вход — один незащищённый Direct Link.

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

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

Уведомления о закрытии превращают миграцию в задачу о ёмкости

Уведомление о закрытии CHE01 — особенно полезный документ, потому что показывает модернизацию инфраструктуры со стороны клиента. IBM сообщает, что CHE01 прекратит работу 10 июня 2027 года, и устанавливает график, начавшийся с объявления о прекращении продаж в июне 2026 года. В нём ограничивается предоставление, на более позднем этапе удаляется возможность новых развёртываний для всех аккаунтов, назначается окно обслуживания сети в апреле 2027 года, закрывается приём заявок на помощь с миграцией, а затем завершаются окна миграции PaaS и IaaS перед окончательным прекращением. IBM также говорит, что продления срока не будет.

Этот график меняет смысл ёмкости в Ченнаи. До закрытия CHE01 был кодом дата-центра в составе IBM Cloud. В процессе закрытия он становится сужающейся границей сервиса. Существующим аккаунтам может быть разрешено работать какое-то время, новое предоставление ограничивается или убирается, обслуживание сети создаёт запланированное прерывание, и клиенты должны выбрать целевые локации. IBM говорит, что новые площадки в Ченнаи и Мумбаи предлагают более полный технологический стек и улучшенную связность в рамках операций MZR. Это может быть хорошо для долгосрочной архитектуры. Но это не делает миграцию автоматической.

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

Материалы по переносу данных показывают, что на время передачи влияют объём и количество файлов. Перенос Object Storage требует новых бакетов и конфигурации. Копии блочных снапшотов для больших томов могут занимать часы.

Тогда у вопроса о ёмкости две стороны. Уходящая площадка должна сохранять достаточно стабильности, чтобы работать до ухода клиента. Целевой регион должен располагать достаточной доступной ёмкостью, подходящими профилями, сетевым доступом, функциями хранилища и готовностью поддержки, чтобы принять нагрузку. Публичные документы IBM не показывают, сколько целевой ёмкости зарезервировано для миграций из CHE01 и как расставляются приоритеты отдельных клиентов. Такая информация может существовать в коммуникациях с конкретным аккаунтом, но её нет в открытых материалах.

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

Что стоит проверить серьёзному покупателю

IBM Cloud даёт покупателю лучшую отправную точку, чем многие провайдеры, потому что публичные документы вскрывают механику. Поэтому проверка должна быть конкретной. Во-первых, покупатель должен выяснить, к каким универсальным именам зон привязан его аккаунт, а не только какие логические метки зон видны в Terraform или консоли. Если нагрузка сочетает VPC, классическую инфраструктуру и Power Virtual Server, коды дата-центров важны, потому что совместное размещение, задержки и корреляция отказов зависят от физического сопоставления.

Во-вторых, покупатель должен отделять доступность региона от доступности продукта. Политика развёртывания сервисов и страницы устранения неполадок ясно показывают, что не каждый сервис, профиль, GPU, конфигурация bare-metal или рыночная функция присутствуют в каждом регионе. Если нагрузка зависит от профиля оборудования, клиенту стоит проверить наличие и альтернативы в основном и резервном регионах. Если план восстановления предполагает новое предоставление после аварии, его нужно тестировать в реалистичных условиях квот, наличия и поддержки.

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

В-третьих, покупатель должен относиться к частной связности как к отдельной системе. Отказоустойчивость Direct Link требует как минимум двух соединений, отдельных маршрутизаторов на стороне IBM или разнесённых PoP, по возможности разных маршрутов операторов, собственной политики BGP и подтверждения, что внешняя кабельная инфраструктура не сходится до подхода к IBM. Две сессии — это не две кабельные трассы. Два провайдера — не автоматически два физических маршрута. Нужно проверить заказ канала, LOA/CFA, кросс-коннект, маршрутизатор, политику маршрутизации и путь оператора.

В-четвёртых, покупатель должен ставить восстановление данных рядом с восстановлением вычислений. Снапшоты VPC, репликация Object Storage, копии бакетов, репликация файловых ресурсов и продукты резервного копирования bare-metal решают разные задачи. Снапшот в другом регионе полезнее после того, как он стабилизировался. Клон быстрого восстановления полезнее, если он существует до инцидента. Бакет с неправильным классом отказоустойчивости может потребовать копирования под давлением. Локальные диски bare-metal требуют резервного копирования под управлением клиента. DNS и состояние приложения должны быть включены в план, а не считаться мелочью.

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

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

Полезный вывод уже маркетинговой карты

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

Материалы не подтверждают более сильное утверждение, что выбранный регион IBM Cloud автоматически предоставляет нужную клиенту ёмкость, физическое разнообразие путей или результат восстановления. Ёмкость зависит от профиля и меняется со временем. Часть сервисов рыночные. Специализированное оборудование локально. Запас bare-metal динамичен. Предоставление классических виртуальных серверов может не сработать, потому что у маршрутизатора или дата-центра нет ресурсов. Direct Link — отдельный путь в облако, и без осознанного дублирования он не резервируется. Зональные ресурсы VPC не переезжают сами после полного отказа зоны.

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

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

Какие устаревшие площадки приближаются к закрытию?

Ответы на эти вопросы и есть тот инфраструктурный продукт, который клиент на самом деле покупает. Имя региона — только входная дверь.