Краткое содержание

  • Самые сильные публичные доказательства указывают на классическую инфраструктурную локацию IBM Cloud в Сингапуре, а не на отдельно продаваемый объект. Собственная документация IBM по диапазонам IP-адресов указываетsng01в Джуронг-Ист, а таблицы локаций Kubernetes и OpenShift IBM перечисляют Сингапур как классический регион с одним ЦОД и зонойsng01; см. https://cloud.ibm.com/docs/infrastructure-hub?topic=infrastructure-hub-ibm-cloud-ip-ranges, https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zones и https://cloud.ibm.com/docs/openshift?topic=openshift-regions-and-zones.
  • Физические доказательства сконцентрированы вокруг кампуса Digital Realty по адресу 29A International Business Park в Джуронг-Ист. Текущая страница SIN10 компании Digital Realty содержит адрес и масштаб здания по ссылке https://www.digitalrealty.com/data-centers/asia-pacific/singapore/sin10, а более ранние объявления об аренде Digital Realty/SoftLayer и IBM связывают расширение облачного, выделенного и управляемого хостинга именно с этой площадкой.
  • Сетевые доказательства обширны на уровне IBM Cloud, но ограничены на уровне конкретной серверной фермы в Сингапуре. PeeringDB идентифицирует AS36351 как SoftLayer Technologies, Inc. (an IBM Company), также известную как IBM Cloud, с 1800 префиксами IPv4, 450 префиксами IPv6 и трафиком 1–5 Тбит/с; BGP.tools показывает пиринг AS36351 в Сингапуре на BBIX Singapore. Это полезные глобальные сигналы, но не доказательство точного размещения клиентов вsng01.
  • Основной операционный риск не в том, существует ли IBM Cloud в Сингапуре, а в том, привязана ли услуга конкретного клиента к одному классическому ЦОД, одному каналу Direct Link, одному пулу аппаратного обеспечения, одной очереди поддержки, одной схеме резервного копирования или одному пути миграции. Собственная документация IBM по Direct Link прямо говорит, что Direct Link не является резервируемым по умолчанию и что клиенты обязаны разворачивать резервирование.
  • Уровень доказательств — средний. Открытые данные подтверждают реальное присутствие хостинга IBM Cloud в Сингапуре, но не раскрывают текущее количество стоек, размещение клиентских нагрузок, глубину запаса запчастей, срок аренды площадки, частные процедуры ремонта или проверенное аварийное переключение между Сингапуром и другими локациями IBM Cloud.

Продаётся облако, но зависимость по-прежнему в серверной в Сингапуре

Название IBM-SG-AP IBM Sinapore Server Farm звучит неуклюже, но стоящий за ним операционный вопрос обычен и важен: когда клиент покупает арендуемые мощности IBM Cloud в Сингапуре, от какой физической и договорной системы он на самом деле зависит? IBM продвигает глобальную облачную платформу, выделенные серверы, частные подключения, объектное хранилище, сервисы VPC и шаблоны высокой доступности. Покупатель видит эти услуги через консоль, API, прайс-лист, страницу статуса сервиса и обращение в поддержку. Однако у отказа всё равно есть материальное воплощение.

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

Публичных данных достаточно, чтобы утверждать, что Сингапур — реальная инфраструктурная локация IBM Cloud. Документация IBM по диапазонам IP-адресов классической инфраструктуры по адресу https://cloud.ibm.com/docs/infrastructure-hub?topic=infrastructure-hub-ibm-cloud-ip-ranges указываетsng01в Джуронг-Ист и показывает диапазоны адресов балансировщиков нагрузки и частных сетей, связанные с этой локацией. Страница локаций IBM по ссылке https://cloud.ibm.com/docs/overview?topic=overview-locations объясняет, что клиенты классической инфраструктуры могут выбирать отдельные ЦОД, и отличает классические ЦОД от мультизональных регионов. Таблица локаций IBM Kubernetes Service по адресу https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zones перечисляет Азиатско-Тихоокеанский регион, Сингапур, Сингапур, метроsng-mtr, зонуsng01, управляется из AP North. Таблица локаций IBM OpenShift по ссылке https://cloud.ibm.com/docs/openshift?topic=openshift-regions-and-zones повторяет ту же строку классического региона с одним ЦОД в Сингапуре.

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

Физические данные указывают на Джуронг-Ист. Страница Digital Realty SIN10 по адресу https://www.digitalrealty.com/data-centers/asia-pacific/singapore/sin10 называет адрес 29A International Business Park, Jurong East, Singapore 609934 и описывает семиэтажное здание площадью 377 000 квадратных футов. Сингапурская страница Digital Realty по ссылке https://www.digitalrealty.com/data-centers/asia-pacific/singapore включает SIN10 в число своих площадок и рекламирует локальную экосистему из более чем 65 облачных и сетевых провайдеров.

Запись Дата-центр Map об IBM SNG01 по адресу https://www.datacentermap.com/singapore/singapore/softlayer-sng01/ размещает IBM SNG01 по адресу 29A International Business Park. Datacenters.com по ссылке https://www.datacenters.com/ibm-cloud-sng01-singapore даёт тот же адрес International Business Park, отмечая при этом, что публичные данные о площади и мощности для этой записи IBM Cloud недоступны.

История также необычно полезна. Перепечатка ACN Newswire анонса Digital Realty о SoftLayer по адресу https://www.acnnewswire.com/press-release/english/7770/digital-realty-signs-softlayer-to-data-centre-lease-in-singapore сообщает, что SoftLayer арендовала 48 000 квадратных футов на площадке Digital Realty по адресу 29A International Business Park во втором квартале 2011 года для предоставления облачного, выделенного и управляемого хостинга в Азиатско-Тихоокеанском регионе.

Анонс Digital Realty на PR Newswire по ссылке https://www.prnewswire.com/news-releases/ibm-signs-turn-key-datacentre-lease-with-digital-realty-in-singapore-132661203.html сообщает, что IBM также подписала договор аренды готового ЦОД с Digital Realty в Сингапуре в 2011 году. Материал Дата-центр Knowledge о SoftLayer по адресу https://www.datacenterknowledge.com/business/softlayer-opens-singapore-data-center сообщает, что SoftLayer открыла ЦОД в Сингапуре, получив собственный этаж в том же здании Digital Realty.

Позднее поглощение IBM компании SoftLayer, подтверждённое FAQ по приобретению на странице https://www.ibm.com/cloud-computing/SoftLayer_Acquisition_Announcement_FAQs.pdf и анонсом закрытия сделки по ссылке https://www.prnewswire.com/news-releases/ibm-closes-acquisition-of-softlayer-technologies-214589711.html, объясняет, почему данные о хостинге эпохи SoftLayer по-прежнему относятся к анализу IBM Cloud.

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

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

Классическая инфраструктура IBM Cloud делает закупку инфраструктуры простой. Документация IBM по bare metal-серверам по адресу https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bm определяет bare metal-сервер IBM Cloud как почасовой или помесячный однотенантный сервер, выделенный клиенту и развёрнутый в одном или нескольких ЦОД. Начальная страница IBM по ссылке https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-getting-started сообщает, что bare metal-серверы можно разворачивать на классической инфраструктуре IBM Cloud или инфраструктуре IBM Cloud VPC.

Страница продукта IBM по адресу https://www.ibm.com/products/bare-metal-servers утверждает, что развёртывания на классической и VPC-инфраструктуре являются выделенными, и позиционирует классическую инфраструктуру для крупных, стабильных и предсказуемых операций. Страница выделенного облака IBM по ссылке https://www.ibm.com/products/bare-metal-servers/dedicated-cloud рекламирует более 11 миллионов комбинаций конфигураций, гибкость биллинга и глобальные варианты развёртывания.

Это сильное коммерческое предложение. Это также напоминание о том, что классический хостинг — не магия. Однотенантный сервер по-прежнему состоит из шасси, платы, процессора, памяти, набора дисков, блока питания, сетевого интерфейса, канала внеполосного управления и порта в стойке. Документация IBM по bare metal сообщает, что при заказе сервера может выполняться расширенное аппаратное тестирование, а стресс-тесты могут увеличить время подготовки. Это разумный контроль качества.

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

Вопрос единственного ЦОД острее для классических сервисов, чем для мультизонального облачного региона. Документация IBM по Kubernetes и OpenShift перечисляет Сингапур как классический регион с одним ЦОД. Страница локаций IBM Transit Gateway по адресу https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-tg-locations включает СингапурSNG01в число классических ЦОД, которые могут подключать классическую инфраструктуру к ресурсам VPC. Это полезно, поскольку показывает, что у IBM есть поддерживаемый мост между классическими ресурсами и более новыми сетевыми схемами VPC. Это также подтверждает, что клиенту предстоит проектная работа. Совместимость с Transit Gateway не размещает нагрузку автоматически в нескольких физических локациях. Она даёт способ соединить ресурсы; клиент всё равно должен выбрать, где будет жить вторая копия, резервная копия, маршрут или запасной сервер.

Это различие — центральное для заголовка статьи. IBM продаёт арендуемые мощности, которые зависят от стоек, транзитных соединений и сроков ремонта, потому что у каждого уровня свой путь отказа. Если клиент покупает один bare metal-сервер вsng01, провайдер может поддерживать сеть и площадку в рабочем состоянии, пока собственное приложение клиента остаётся хрупким из-за отсутствия второго узла. Если клиент подключает Direct Link в Сингапур, но не второй Direct Link, частный доступ может отказать, даже если сервер и публичная сеть исправны. Если клиент полагается на IBM Cloud Backup for Classic, но не тестирует восстановление bare metal, сервис резервного копирования может существовать, а восстановление оставаться неопределённым. Если клиент хранит шаблон образа, но не секреты, DNS, правила брандмауэра и подключённые данные, миграция может быть технически возможной, но операционно неполной.

IBM публикует материалы о миграции и переносимости и возлагает ответственность в правильное место. Обзор миграции классической инфраструктуры по адресу https://cloud.ibm.com/docs/infrastructure-hub?topic=infrastructure-hub-about-migration-infra сообщает, что пользовательские шаблоны образов могут захватывать образ классического bare metal-сервера для заказа дополнительных классических bare metal-серверов с теми же конфигурациями.

Обзор миграции классических bare metal-серверов IBM по ссылке https://cloud.ibm.com/docs/infrastructure-hub?topic=infrastructure-hub-p-p-migration-bare-metal-overview говорит, что миграция может использовать публичные или частные интерфейсы, а миграция через частный интерфейс использует сеть IBM. Страница переносимости данных VPC по адресу https://cloud.ibm.com/docs/vpc?topic=vpc-data-portability объясняет экспорт образов в IBM Cloud Object Storage для пользовательских образов.

Но страница переносимости данных классических bare metal-серверов IBM по ссылке https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-data-portability откровенна: bare metal-серверы полностью управляются клиентом, и клиент отвечает за выбор собственного решения для экспорта данных.

Это предложение — практический центр риска. Провайдер может предложить помещение, сеть, оборудование, частную сеть и канал поддержки. Он не может задним числом создать пригодный экспорт, если клиент его не спроектировал. Для клиентов в Сингапуре это означает, что вопрос закупки никогда не должен останавливаться на «Могу ли я развернуться в Сингапуре?». Следует спросить: смогу ли я пересобрать систему в другой локации IBM рядом с Сингапуром или у другого провайдера, если ресурсsng01недоступен? Смогу ли я вывезти пользовательский образ? Смогу ли я восстановить состояние из бакета, размещение и долговечность которого я понимаю? Смогу ли я переключить DNS и связность до того, как окно технического обслуживания превратится в простой? Сможет ли моя команда управлять целевой средой без того же единственного разрешения консоли, прыжкового хоста или частного канала, которые отказали?

Direct Link улучшает частный доступ, но не отменяет проектирование путей

IBM Cloud Direct Link важен, потому что это вероятный корпоративный путь в такого рода арендуемые мощности. Обзор IBM Direct Link по адресу https://cloud.ibm.com/docs/dl?topic=dl-dl-about описывает подключение из внешнего источника в частную сеть IBM Cloud клиента как альтернативу традиционному site-to-site VPN для клиентов, которым нужна более стабильная и высокопроизводительная связь.

Страница продукта Direct Link по ссылке https://www.ibm.com/products/direct-link описывает сценарии использования, включая передачу данных, репликацию для непрерывности бизнеса, аварийное восстановление, резервное копирование и доступ из частной инфраструктуры. Страница локаций по адресу https://cloud.ibm.com/docs/dl?topic=dl-locations перечисляет локации провайдеров Direct Link Connect в Азиатско-Тихоокеанском регионе, включая Digital Realty Singapore 1 и Equinix Singapore 2. Страница сравнения по ссылке https://cloud.ibm.com/docs/dl?topic=dl-dl-comparison-locations включает Singapore 1 и Singapore 2 в набор локаций Direct Link.

Эти факты говорят клиентам о двух вещах. Во-первых, Сингапур — не только вычислительная локация, но и рынок частной связности в продуктовой карте IBM Cloud. Во-вторых, есть разница между покупкой одной услуги доступа и проектированием резервирования. Страница ответственности IBM по адресу https://cloud.ibm.com/docs/dl?topic=dl-dl-responsibilities сообщает, что IBM предоставляет разнообразные сетевые опции, а клиент должен обеспечить развёртывание резервирования Direct Link.

На той же странице сказано, что Direct Link не является резервируемой услугой и что аварийное переключение должно быть встроено в BGP-конфигурацию клиента между несколькими Direct Link. FAQ IBM по Direct Link по ссылке https://cloud.ibm.com/docs/direct-link?topic=direct-link-faqs сообщает, что Direct Link может предоставлять разнообразные соединения, но не является резервируемым по своей природе. Начальное руководство IBM по адресу https://cloud.ibm.com/docs/dl?topic=dl-get-started-with-ibm-cloud-dl рекомендует устанавливать второй, разнообразный Direct Link для предотвращения простоев, как плановых, так и внеплановых.

Это необычно ясный язык провайдера. Он избегает ловушки, в которой частное облачное подключение по умолчанию рекламируется как устойчивость. В реальности Direct Link может снизить зависимость от публичного интернета и улучшить предсказуемость пропускной способности, но он создаёт собственную поверхность зависимостей: облачная локация, маршрутизатор клиента, порт провайдера, кроссировка, ткань обмена или путь оператора, BGP-конфигурация, фильтры маршрутов, окна обслуживания и состояние биллинга. Когда клиент подключается к Singapore 1 или Singapore 2, недостаточно спросить, поднят ли порт.

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

Сингапурские данные полезны, но неполны. IBM перечисляет Digital Realty Singapore 1 и Equinix Singapore 2 как опции Direct Link Connect. BGP.tools по адресу https://bgp.tools/as/36351 показывает пиринг AS36351 на BBIX Singapore с записью 10 Гбит/с в публичном виде. Страница AS36351 на PeeringDB по ссылке https://www.peeringdb.com/net/1613 идентифицирует SoftLayer Technologies, Inc. (an IBM Company), также известную как IBM Cloud, и указывает трафик 1–5 Тбит/с с большим числом глобальных префиксов. Cloudflare Radar по адресу https://radar.cloudflare.com/routing/as36351 отслеживает AS36351 как SOFTLAYER -- IBM Cloud.

Эти сторонние источники подтверждают, что IBM Cloud — значительная маршрутизируемая сеть с присутствием в Азиатско-Тихоокеанском регионе. Они не показывают, как конкретный сингапурский хостинговый клиент передаётся от своей стойки к глобальному краю AS36351.

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

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

Поэтому сингапурский хостинговый след следует оценивать как цепочку зависимостей, а не как одно название площадки. Арендуемые вычисления, частный канал, публичный интернет-путь, резервное хранилище, DNS и поддержка — отдельные уровни. Direct Link делает один уровень сильнее при грамотном проектировании. Он также может сделать зависимость менее заметной, если команды считают, что «частный» означает «устойчивый». Документация IBM открыто возлагает проектную нагрузку на покупателя. Покупателям стоит использовать эту ясность.

Объектное хранилище IBM Cloud и параметры резервного копирования помогают только при осознанном размещении

Резервное копирование и переносимость данных — это точка, где многие отказы арендуемых мощностей перестают быть техническими неожиданностями и становятся управленческими провалами. Объектное хранилище IBM Cloud имеет более сильную публичную историю устойчивости, чем один классический сервер. Документация по конечным точкам и локациям хранения по адресу https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-endpoints сообщает, что региональные бакеты распределяют данные по трём ЦОД в пределах метрополии, а межрегиональный доступ имеет другой профиль производительности и устойчивости.

Устаревшая документация IBM по конечным точкам по ссылке https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-remap-endpoints говорит, что региональная конечная точка распределяет данные по трём ЦОД, и любой из них может пострадать от простоя или даже разрушения без влияния на доступность. Страница устойчивости Object Storage IBM по адресу https://www.ibm.com/products/cloud-object-storage/resiliency описывает межрегиональные, региональные и однодатацентровые варианты.

Это мощно, если клиент выбирает правильный класс хранения и тестирует восстановление, но не является универсальным решением зависимости отsng01. Размещение бакета Object Storage должно соответствовать цели восстановления. Бакет в одном ЦОД может подходить по задержке или стоимости, но не решает проблему отказа масштаба ЦОД. Региональный бакет может обеспечить распределение на уровне метрополии, если услуга доступна в соответствующей географии, но клиенту всё равно нужно знать, сможет ли он пересобрать вычисления и сеть в целевой локации. Межрегиональный бакет может помочь при более широком аварийном восстановлении, но может создать вопросы задержки, суверенитета и стоимости передачи. Для сингапурской нагрузки фраза «данные остаются в Сингапуре» может конфликтовать с фразой «переживают сингапурскую проблему обслуживания», если клиент не делает осознанный выбор.

IBM Cloud Backup for Classic закрывает другую потребность. Начальное руководство по адресу https://cloud.ibm.com/docs/Backup?topic=Backup-getting-started описывает IBM Cloud Backup for Classic как агентскую систему защиты данных на серверах с расписаниями и плагинами. Страница резервного копирования виртуальных серверов по ссылке https://cloud.ibm.com/docs/virtual-servers?topic=virtual-servers-backup-services сообщает, что администраторы могут задавать почасовые, ежедневные, еженедельные или пользовательские расписания для полных систем, каталогов или файлов.

Руководство по восстановлению bare metal по адресу https://cloud.ibm.com/docs/Backup?topic=Backup-configureBMR описывает портал Cloud Backup и задания восстановления bare metal. Эти страницы показывают, что IBM предлагает инструменты резервного копирования для классической инфраструктуры. Они также показывают, что резервное копирование — это настраиваемая услуга, а не автоматическое свойство наличия сервера.

Путь отказа легко представить. Клиент покупает bare metal-сервер в Сингапуре, потому что хочет низкой задержки и выделенных ресурсов. Он добавляет Direct Link, потому что хочет стабильного частного доступа. Он использует сервис резервного копирования, но хранит документацию по восстановлению во внутренней системе, доступной только через тот же Direct Link.

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

Переносимость имеет похожую форму. IBM документирует пользовательские шаблоны образов и экспорт образов VPC. Эти механизмы могут снизить трение при уходе или пересборке, но не устраняют задачи лицензирования, идентификации, секретов, сетевой адресации, брандмауэра, DNS и синхронизации данных. Пользовательский образ полезен, когда приложение дружелюбно к образам. Он менее полезен, когда важное состояние находится на подключённых томах, в базе данных, в сетевом хранилище NAS, в журналах приложений, в вручную исправленных файлах конфигурации или в частной интеграции, которую никто не пересобирал в другом месте. Для клиента, работающего в Сингапуре, тест переносимости должен быть живым и измеримым. Может ли команда запустить замену внеsng01? Может ли восстановить данные там? Могут ли пользователи достучаться до неё? Может ли она сохранить достаточно гарантий соответствия и задержки, чтобы работать во время события?

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

Рынок площадок вокруг Джуронг-Ист поднимает вопросы энергоснабжения и аренды

Сингапур — ценный рынок ЦОД именно потому, что земля, энергия, охлаждение и связность дефицитны. Сингапурский след IBM находится внутри этого более широкого ограничения. Дорожная карта зелёных ЦОД IMDA по адресу https://www.imda.gov.sg/how-we-can-help/green-dc-roadmap сообщает, что Сингапур намерен предоставить не менее 300 МВт дополнительной мощности в ближайшей перспективе, а больше возможно за счёт внедрения зелёной энергии.

Анонс IMDA 2023 года по ссылке https://www.imda.gov.sg/resources/press-releases-factsheets-and-speeches/press-releases/2023/four-data-centre-proposals-selected-as-part-of-pilot-data-centre-call-for-application сообщает, что временная пауза в росте ЦОД была снята в 2022 году, а пилотный конкурс отобрал четыре предложения.

Сводка Совета экономического развития Сингапура по адресу https://www.edb.gov.sg/en/business-insights/insights/singapore-to-expand-data-centre-capacity-by-at-least-one-third-pushes-for-green-energy-use.html описывает не менее 300 МВт дополнительной мощности ЦОД и возможные ещё 200 МВт для операторов, использующих зелёную энергию.

Эти официальные источники не специфичны для IBM, но напрямую относятся к IBM-SG-AP IBM Sinapore Server Farm, поскольку арендуемые мощности в Сингапуре ограничены теми же входными рынками. Облачный провайдер может обновлять серверы и продавать новые конфигурации только при наличии пространства, энергии, охлаждения, сетевых портов, цепочки поставок и разрешения на работу. Если сингапурские мощности ограничены, клиентам следует спросить, доступен ли желаемый профиль сервера вsng01, требуют ли более крупные конфигурации другой локации IBM Cloud, возможно ли резервирование мощности и сколько времени займёт замена оборудования во время регионального всплеска спроса.

История площадки Digital Realty по адресу 29A International Business Park придаёт этому вопросу конкретную форму. Анонс Digital Realty/SoftLayer 2011 года сообщал, что объект площадью 370 500 квадратных футов в Джуронг-Ист имел до 30 МВт мощности ИБП 2N и более 4,5 МВт ИТ-нагрузки на каждом из шести этажей ЦОД. Материал Дата-центр Knowledge о приобретении Digital Realty по адресу https://www.datacenterknowledge.com/next-gen-data-centers/digital-realty-buys-singapore-data-center описывал ту же площадку как готовую к заселению клиентами в 2011 году с более чем 4,5 МВт ИТ-нагрузки на каждом из шести этажей и непрерывным охлаждением N+2.

Текущая страница Digital Realty SIN10 даёт близкий текущий размер здания, а текущая сингапурская страница перечисляет сертификации и заявления об экосистеме рынка.

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

Тот же вопрос возникает в поддержке и обслуживании. Страница статуса IBM Cloud по адресу https://cloud.ibm.com/status и история статусов по ссылке https://cloud.ibm.com/status/history дают клиентам публичный способ видеть уведомления платформы. Руководство по поддержке IBM по адресу https://cloud.ibm.com/docs/support?topic=support-viewing-status объясняет, как просматривать крупные инциденты, плановое обслуживание и бюллетени безопасности. Страница помощи по bare metal IBM по ссылке https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-bare-metal-help-and-support направляет пользователей к документации, статусу и ресурсам поддержки.

Страница серьёзности поддержки IBM по адресу https://cloud.ibm.com/docs/support?topic=support-support-case-severity объясняет серьёзность и цели времени реакции в зависимости от плана поддержки, а страница серьёзности корпоративной поддержки IBM по ссылке https://www.ibm.com/support/pages/ibm-enterprise-support-severity-definitions сообщает, что клиенты IBM Cloud должны регистрировать обращение Service Down в течение 24 часов с момента осознания критического влияния на бизнес.

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

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

AS36351 доказывает масштаб, а не восстановление конкретного клиента

Сетевые доказательства IBM Cloud значительны на уровне автономной системы. PeeringDB по адресу https://www.peeringdb.com/net/1613 идентифицирует AS36351 как SoftLayer Technologies, Inc. (an IBM Company), также известную как IBM Cloud, с переопределением сайта https://www.ibm.com/cloud, типом сети content, 1800 префиксами IPv4, 450 префиксами IPv6 и трафиком 1–5 Тбит/с. BGP.tools по ссылке https://bgp.tools/as/36351 называет IBM Cloud давно существующей критичной для интернета сетью с сотнями пиров и несколькими вышестоящими операторами и показывает сингапурскую запись пиринга на BBIX Singapore.

Страница Hurricane Electric по адресу https://bgp.he.net/as36351 перечисляет AS36351 как IBM Cloud и показывает множество сетевых записей IPv6, связанных с IBM Cloud и IBM Cloud International B.V. Cloudflare Radar по ссылке https://radar.cloudflare.com/routing/as36351 предоставляет независимую видимость маршрутизации для AS36351.

Это сильное доказательство того, что у IBM Cloud большая маршрутизируемая магистраль. Оно также слишком широкое, чтобы доказывать устойчивостьsng01. ASN может быть глобальным, а ресурс конкретного клиента — локальным. Глобальный набор префиксов может оставаться работоспособным, пока затронуты серверная, коммутатор доступа, система хранения, брандмауэр, частная VLAN или порт Direct Link. Сингапурская запись пиринга может улучшить задержку или достижимость, но не говорит, где выходит трафик каждого размещённого сервера, как отображаются частные VLAN клиентов и переживает ли путь событие на площадке.

Публичная политика пиринга IBM по адресу https://cloud.ibm.com/docs/overview?topic=overview-public-peering сообщает, что публичный пиринг происходит через общую сеть и что запросы на пиринг могут приниматься при наличии взаимно приемлемой операционной необходимости. Это нормальная позиция оператора. Это также означает, что публичное межсоединение — управляемое бизнес-решение, а не гарантия клиенту, что каждое назначение будет использовать желаемый локальный путь. Для предприятий релевантный вопрос не «Есть ли у IBM большой ASN?», а «Использует ли мой дизайн услуги сеть IBM так, чтобы пережить сбои, которые меня волнуют?»

Этот вопрос обостряется в Азиатско-Тихоокеанском регионе. Клиент, размещённый в Сингапуре, может обслуживать пользователей в Сингапуре, Малайзии, Индонезии, Индии, Австралии, Японии, Европе и Северной Америке. Он может полагаться на публичную интернет-маршрутизацию, Direct Link, VPN, CDN, IBM Cloud Internet Services или транзит клиента. У каждого пути свой операционный владелец. IBM Cloud Internet Services, описанные по адресу https://www.ibm.com/products/cloud-internet-services, могут добавить в дизайн производительность и безопасность на базе Cloudflare, но это сервис входной двери, а не замена устойчивости источника.

Direct Link может обеспечить частный доступ, но IBM говорит, что клиент должен проектировать резервирование. Object Storage может предложить разные варианты долговечности, но клиент должен выбрать размещение бакета. Bare metal может обеспечить однотенантность, но клиент должен спроектировать резервное копирование и переносимость.

Поэтому AS36351 следует использовать как контекст мониторинга, а не как доказательство безопасного восстановления. Мониторьте AS36351 и статус IBM Cloud. Следите за публичными аномалиями маршрутов. Отслеживайте уведомления Direct Link в Сингапуре. Но сопоставляйте услугу клиента с конкретными ресурсами: классический ЦОД, VLAN, идентификаторы серверов, шлюзы Direct Link, BGP-сессии, цели резервного копирования, бакеты объектного хранилища, DNS, идентификацию, план поддержки и альтернативную локацию развёртывания. Публичный управляющий уровень интернета — лишь один слой ответа.

Кто страдает при отказе сингапурской хостинговой поверхности

Непосредственно затронутая группа — не «пользователи IBM» в целом, а любой клиент, чья нагрузка, путь управления, частная связность или активы восстановления зависят от классического сингапурского следа. Сюда входят предприятия, разместившие bare metal-серверы вsng01ради низкой задержки; команды, держащие классические ресурсы Kubernetes или OpenShift в Сингапуре; клиенты, использующие классическую инфраструктуру, подключённую к ресурсам VPC через Transit Gateway; клиенты с Direct Link в Сингапур; организации, выбравшие Сингапур из-за локальности данных или доступа к Азиатско-Тихоокеанскому региону.

Радиус поражения зависит от дизайна. Клиент с одним сервером, одним публичным IP, отсутствием второй локации и ручным планом резервного копирования может полностью остановиться при небольшой аппаратной проблеме или проблеме на площадке. Клиент с несколькими серверами в одном ЦОД может пережить отказ одной машины, но не событие уровня площадки: питание, охлаждение, доступ, коммутатор или управляющий уровень. Клиент с вычислениями в Сингапуре и межрегиональным хранилищем может сохранить данные, но не иметь вычислительных мощностей в другом месте. Клиент с проверенной автоматизацией сборки, экспортом образов, межрегиональным хранилищем, вторым Direct Link и глобальным DNS может рассматриватьsng01как одну важную локацию, а не всю услугу.

Регуляторная группа шире. Локальность данных Сингапура часто привлекательна для финансовых услуг, структур, близких к правительству, здравоохранения, логистики и региональных штаб-квартир. Страница соответствия IBM Cloud по адресу https://cloud.ibm.com/docs/overview?topic=overview-compliance описывает сертификации, такие как ISO 27001, PCI и SOC2, и обсуждает IBM Cloud Framework for Financial Services. Эти сертификации и контроли важны для закупок, но сами по себе не отвечают, где находятся каждая резервная копия, артефакт поддержки, журнал, ключ шифрования или административное действие.

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

Важна и миграционная группа. Клиенты, работающие на старой классической инфраструктуре, со временем могут перейти на VPC, другой регион IBM или другого провайдера. IBM документирует миграцию с Classic на VPC для виртуальных серверов по адресу https://cloud.ibm.com/docs/vpc?topic=vpc-migrate-vsi-to-vpc и планирование пользовательских образов по ссылке https://cloud.ibm.com/docs/vpc?topic=vpc-planning-custom-images. Эти страницы показывают путь, но миграция редко бывает однонажатийным событием для продуктивных систем.

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

Экономическая группа включает клиентов, использующих выделенное оборудование ради предсказуемой производительности или контроля лицензирования. Предложение bare metal IBM привлекательно для SAP, VMware, высокопроизводительных нагрузок и однотенантного контроля. Но те же клиенты могут быть более чувствительны к доступности точного аппаратного профиля. Виртуальный ресурс может быть заменён из более широкого пула. Пользовательская конфигурация bare metal может быть заменена только при наличии соответствующего запаса в нужном месте.

Контракт и архитектура клиента должны определять, что произойдёт, если тот же процессор, ОЗУ, GPU, хранилище или сетевой профиль не будут немедленно доступны в Сингапуре.

Контрольные точки для покупателей и операторов

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

Вторая контрольная точка — резервирование Direct Link. Если частный доступ важен, одного Direct Link недостаточно. Документация IBM сообщает, что Direct Link не является резервируемым по своей природе, и рекомендует второй разнообразный канал. Клиент должен задокументировать, действительно ли Singapore 1 и Singapore 2 разнообразны для его набора провайдеров, автоматическое ли переключение BGP, проверены ли фильтры маршрутов, соответствуют ли локальные и глобальные варианты маршрутизации схеме восстановления, известны ли контакты поддержки как на стороне оператора, так и на стороне IBM.

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

Четвёртая контрольная точка — география резервного копирования. IBM Cloud Backup for Classic и Object Storage могут помочь, но только если цель резервного копирования и цель восстановления выбраны осознанно. Локальная резервная копия быстра, но зависит от площадки. Межрегиональный бакет повышает выживаемость, но может повлиять на суверенитет, задержку и стоимость. Пользовательский образ помогает пересборке, но может не включать всё состояние. Bare metal-сервер остаётся управляемым клиентом в части решений об экспорте.

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

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

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

Уровень доказательств: средний, с явным понижением для названного актива

Доказательства присутствия IBM Cloud в Сингапуре сильнее, чем доказательства существования отдельного бренда «IBM Sinapore Server Farm». Собственная документация IBM даётsng01, Джуронг-Ист, классическую инфраструктуру, строки локаций классических Kubernetes и OpenShift, совместимость с Transit Gateway, сингапурские локации Direct Link и описания услуг bare metal. Digital Realty, PR Newswire, ACN Newswire, Дата-центр Knowledge, Дата-центр Map и Datacenters.com предоставляют физический и исторический контекст вокруг 29A International Business Park. PeeringDB, BGP.tools, Hurricane Electric и Cloudflare Radar показывают более широкую сетевую поверхность AS36351.

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

Это правильный способ читать актив.

Для клиента действие практично. Относитесь к IBM-SG-AP IBM Sinapore Server Farm как к поверхности зависимостей IBM Cloud в Сингапуре, а не как к загадочному бренду и не как к полностью самовосстанавливающемуся облачному региону. Подтвердите точное размещениеsng01, если локальность важна. Постройте второй сетевой путь, если частный доступ важен. Храните резервные копии вне домена отказа, который они должны пережить. Тестируйте экспорт образов и восстановление до того, как обращение в поддержку станет срочным. Спрашивайте о запасе оборудования до заказа профиля, который трудно заменить. Мониторьте AS36351 и статус IBM Cloud, но не путайте глобальный масштаб сети с восстановлением конкретной нагрузки. Облачный заказ может быть цифровым; путь восстановления по-прежнему физический, договорной и разделён между IBM, операторами площадок, операторами связи и клиентом.