概要
- 最も強い公開証拠は、IBM Cloud シンガポールのクラシックインフラストラクチャロケーションを指しており、別途販売される施設ではない。IBM 自身の IP 範囲ドキュメントにはジュロンイーストのsng01がリストされ、IBM の Kubernetes および OpenShift のロケーションテーブルでは、シンガポールがゾーン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 キャンパスに集中している。Digital Realty の現在の SIN10 ページはhttps://www.digitalrealty.com/data-centers/asia-pacific/singapore/sin10で住所と建物規模を示しており、古い Digital Realty/SoftLayer および IBM のリース発表は、クラウド、専用、マネージドホスティングの拡張を同じ物件に結びつけている。
- ネットワーク証拠は IBM Cloud レベルでは広範囲だが、シンガポールサーバーファームレベルでは薄い。PeeringDB は AS36351 を SoftLayer Technologies, Inc.（IBM の子会社）、別名 IBM Cloud として識別し、1,800の IPv4 プレフィックス、450の IPv6 プレフィックス、1-5 Tbps のトラフィックを示している。BGP.tools はシンガポールで AS36351 が BBIX Singapore とピアリングしていることを示している。これらは有用なグローバルシグナルであり、正確なsng01への顧客配置の証明ではない。
- 主な運用リスクは、IBM Cloud がシンガポールに存在するかどうかではない。顧客のサービスが1つのクラシックデータセンター、1つの Direct Link パス、1つのハードウェア在庫プール、1つのサポートキュー、1つのバックアップ設計、または1つの移行パスに結びついているかどうかである。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 ドキュメントは、資産を現在のサービス語彙に位置づけるため重要である。また、主張の限界も設定する。クラシック単一データセンターの行は、3つの独立したアベイラビリティゾーンを持つ耐障害性のあるシンガポールリージョンと同じではない。IBM の広範なロケーションドキュメントでは、マルチゾーンリージョンは物理ロケーション全体にリソースを分散する方法として説明され、シングルキャンパスマルチゾーンリージョンは一部の依存関係が共有される可能性がある設計として説明されている。シンガポールのクラシックsng01リストは、これらのテーブルでシンガポールマルチゾーンリージョンとして提示されていない。購入者にとって、シンガポールに配置されたサーバーはレイテンシ、管轄、またはローカルアクセスの要件を満たすかもしれないが、それ自体を完全な耐障害性設計として扱うべきではない。
物理的な記録はジュロンイーストを指している。Digital Realty の SIN10 ページ（https://www.digitalrealty.com/data-centers/asia-pacific/singapore/sin10）は、29A International Business Park, Jurong East, Singapore 609934を特定し、7階建て、377,000平方フィートの建物を示している。Digital Realty のシンガポール市場ページ（https://www.digitalrealty.com/data-centers/asia-pacific/singapore）は SIN10 をシンガポールサイトの1つとしてリストし、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 が2011年第2四半期に Digital Realty の29A International Business Park 物件で48,000平方フィートをリースし、アジア太平洋でクラウド、専用、マネージドホスティングを提供したと述べている。PR Newswire の Digital Realty 発表（https://www.prnewswire.com/news-releases/ibm-signs-turn-key-datacentre-lease-with-digital-realty-in-singapore-132661203.html）は、IBM も2011年に Digital Realty とシンガポールでターンキーデータセンターリースを締結したと述べている。データセンター Knowledge の SoftLayer 記事（https://www.datacenterknowledge.com/business/softlayer-opens-singapore-data-center）は、SoftLayer が同じ Digital Realty 物件内に自社フロアを持つシンガポールデータセンターを開設したと報告している。IBM によるその後の SoftLayer 買収は、IBM の買収 FAQ（https://www.ibm.com/cloud-computing/SoftLayer_Acquisition_Announcement_FAQs.pdf）および IBM の締結発表（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 のベアメタルサーバードキュメント（https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bm）は、IBM Cloud ベアメタルサーバーは時間単位または月単位のシングルテナントサーバーで、顧客専用であり、1つ以上のデータセンターに展開されると述べている。IBM の入門ページ（https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-getting-started）は、ベアメタルサーバーを IBM Cloud Classic インフラストラクチャまたは IBM Cloud VPC インフラストラクチャに展開できると述べている。IBM の製品ページ（https://www.ibm.com/products/bare-metal-servers）は、クラシックと VPC の両方の展開が専用であり、大規模で安定した予測可能な運用にクラシックインフラストラクチャを位置づけている。IBM の専用クラウドページ（https://www.ibm.com/products/bare-metal-servers/dedicated-cloud）は、1,100万以上の構成組み合わせ、課金の柔軟性、グローバル展開オプションを宣伝している。
これは強力な商用オファーである。同時に、クラシックホスティングは魔法ではないという注意でもある。シングルテナントサーバーは依然としてシャーシ、基板、プロセッサ、メモリ、ドライブセット、電源、ネットワークインターフェース、アウトオブバンド管理パス、ラックポートである。IBM のベアメタルドキュメントは、サーバーが注文されたときに拡張ハードウェアテストが実行可能であり、ストレステストがプロビジョニング時間を延長する可能性があると述べている。これは賢明な品質管理である。また、経済的トレードオフを明らかにする。顧客は準備されたサーバーのクリーンな抽象化に対して支払うことができるが、プロビジョニングは依然として選択されたロケーションのハードウェアとテストに依存する。構成がシンガポールで希少な場合、コンソール体験はジュロンイーストで部品を製造できない。
単一データセンター問題は、マルチゾーンクラウドリージョンよりもクラシックサービスで鋭い。IBM の Kubernetes および OpenShift ドキュメントは、シンガポールをクラシック単一データセンターリージョンとしてリストしている。IBM の Transit Gateway ロケーションページ（https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-tg-locations）は、クラシックインフラストラクチャを VPC リソースに接続できるクラシックデータセンターの中にシンガポールSNG01をリストしている。これは、IBM がクラシックリソースと新しい VPC ネットワーク設計の間に対応するブリッジを持っていることを示すため有用である。また、顧客が設計作業を行う必要があることを確認する。Transit Gateway の互換性は、ワークロードを自動的に複数の物理ロケーションに配置しない。リソースを接続する方法を提供する。顧客は依然として、2番目のコピー、バックアップ、ルート、または代替サーバーがどこに存在するかを選択しなければならない。
この区別は記事のタイトルにとって中心的である。IBM は、ラック、トランジット、修理ウィンドウに依存するホスティング容量を販売する。なぜなら、各層には異なる障害経路があるからである。顧客がsng01で1台のベアメタルサーバーを購入した場合、プロバイダーはネットワークと施設を健全に保つかもしれないが、顧客自身のアプリケーションは2番目のノードがないため脆弱なままである。顧客が Direct Link をシンガポールに購入したが2番目の Direct Link がない場合、サーバーとパブリックネットワークが健全でもプライベートアクセスが失敗する可能性がある。顧客が IBM Cloud Backup for Classic に依存しているがベアメタルリストアをテストしていない場合、バックアップサービスは存在するが復旧は不確かなままである。顧客がイメージテンプレートを保存したがそのシークレット、DNS、ファイアウォールルール、または添付データを保存していない場合、移行は技術的に可能でも運用上不完全であり得る。
IBM はいくつかの移行および移植性に関する資料を公開しており、責任を適切な場所に置いている。クラシックインフラストラクチャ移行の概要（https://cloud.ibm.com/docs/infrastructure-hub?topic=infrastructure-hub-about-migration-infra）は、カスタムイメージテンプレートを使用してクラシックベアメタルイメージをキャプチャし、同じ構成のクラシックベアメタルサーバーをさらに注文できると述べている。IBM のクラシックベアメタル移行の概要（https://cloud.ibm.com/docs/infrastructure-hub?topic=infrastructure-hub-p-p-migration-bare-metal-overview）は、移行にパブリックまたはプライベートインターフェースを使用でき、プライベートインターフェース移行は IBM のネットワークを使用すると述べている。IBM の VPC データポータビリティページ（https://cloud.ibm.com/docs/vpc?topic=vpc-data-portability）は、カスタムイメージの IBM Cloud Object Storage へのイメージエクスポートを説明している。しかし、IBM のクラシックベアメタルデータポータビリティページ（https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-data-portability）は率直である。ベアメタルサーバーは完全に顧客管理であり、顧客は独自のデータエクスポートソリューションを決定する責任がある。
その文がリスクの実質的中心である。プロバイダーは部屋、ネットワーク、ハードウェア、プライベートネットワーク、サポートチャネルを提供できる。顧客が決して設計しなかった場合、遡及的に使用可能なエクスポートを作成できない。シンガポールの顧客にとって、調達の質問は「シンガポールに展開できるか？」で止まるべきではない。それは、sng01リソースが利用できない場合、別のシンガポール近隣の IBM ロケーションまたは別のプロバイダーで再構築できるか？カスタムイメージを外部に移動できるか？配置と耐久性を理解しているバケットから状態を復元できるか？メンテナンスウィンドウが障害になる前に DNS と接続をシフトできるか？チームは、同じ単一コンソール権限、ジャンプホスト、または失敗したプライベートリンクなしでターゲット環境を運用できるか？と問うべきである。
Direct Link はプライベートアクセスを改善するが、経路設計を排除しない
IBM Cloud Direct Link は重要である。なぜなら、この種のホスティング容量へのエンタープライズパスとなる可能性が高いからである。IBM の Direct Link 概要（https://cloud.ibm.com/docs/dl?topic=dl-dl-about）は、従来のサイト間 VPN の代替として、一貫性が高くスループットの高い接続を必要とする顧客向けに、外部ソースから顧客の IBM Cloud プライベートネットワークへの接続を説明している。IBM の Direct Link 製品ページ（https://www.ibm.com/products/direct-link）は、データ転送、ビジネス継続性のためのレプリケーション、ディザスタリカバリ、バックアップ、プライベートインフラストラクチャからのアクセスなどのユースケースを説明している。IBM のロケーションページ（https://cloud.ibm.com/docs/dl?topic=dl-locations）は、APAC Direct Link Connect プロバイダーロケーションをリストしており、Digital Realty Singapore 1および Equinix Singapore 2を含む。比較ページ（https://cloud.ibm.com/docs/dl?topic=dl-dl-comparison-locations）は、Direct Link ロケーションセットにシンガポール1およびシンガポール2をリストしている。
これらの事実は顧客に2つのことを伝える。第一に、シンガポールは計算ロケーションだけでなく、IBM Cloud の製品マップにおけるプライベート接続市場でもある。第二に、1つのアクセスサービスを購入することと冗長性を設計することには違いがある。IBM の責任ページ（https://cloud.ibm.com/docs/dl?topic=dl-dl-responsibilities）は、IBM が多様なネットワークオプションを提供する一方、顧客は Direct Link の多様性が展開されることを確認する必要があると述べている。同じページは、Direct Link は冗長サービスではなく、複数の Direct Link 間でフェイルオーバーを顧客の BGP 設計に組み込む必要があると述べている。IBM の Direct Link FAQ（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）は、計画的または計画外の障害を防ぐために、2番目の多様な Direct Link を確立することを推奨している。
これは異常に明確なプロバイダー言語である。プライベートクラウド接続がデフォルトでレジリエンスとしてマーケティングされる罠を回避している。実際には、Direct Link はパブリックインターネットへの露出を減らし、スループットの予測可能性を向上させることができるが、独自の依存関係面を作り出す：クラウドロケーション、顧客ルーター、プロバイダーポート、クロスコネクト、交換ファブリックまたはキャリアパス、BGP 設定、ルートフィルター、メンテナンスウィンドウ、課金状態。顧客がシンガポール1またはシンガポール2に接続するとき、ポートが動作しているかを尋ねるだけでは不十分である。顧客は、2つのパスが施設、キャリア、ルーター、契約、物理的入口、運用チーム、またはメンテナンスカレンダーを共有していないかどうかを尋ねなければならない。
シンガポールの証拠は有用だが不完全である。IBM は Digital Realty Singapore 1と Equinix Singapore 2を Direct Link Connect オプションとしてリストしている。BGP.tools（https://bgp.tools/as/36351）は、AS36351 が BBIX Singapore で公開ビューに10 Gbit/s エントリを持ってピアリングしていることを示している。PeeringDB の AS36351 ページ（https://www.peeringdb.com/net/1613）は、SoftLayer Technologies, Inc.（IBM の子会社）、別名 IBM Cloud を識別し、1-5 Tbps のトラフィックと大きなグローバルプレフィックスカウントをリストしている。Cloudflare Radar（https://radar.cloudflare.com/routing/as36351）は、AS36351 を SOFTLAYER -- IBM Cloud として追跡している。これらのサードパーティソースは、IBM Cloud がアジア太平洋プレゼンスを持つ実質的なルーテッドネットワークであるという考えを支持している。しかし、特定のシンガポールホスティング顧客がそのラックから AS36351 のグローバルエッジまでどのように運ばれるかを示していない。
その区別はメンテナンス中に重要である。計画されたルーターアップグレードは、トラフィックがテスト済みの2番目のパスを移動する場合は無害であり得る。両方の Direct Link が共有障害ドメインに着地するか、顧客が1つのプレフィックスセットのみをアナウンスする場合、同じイベントが顧客に可視になり得る。施設のクロスコネクト遅延は、顧客がすでにバックアップリンクを持っていれば些細であり得る。2番目のリンクが最初のリンクが故障し始めた後にのみ注文された場合、深刻であり得る。BGP ルートフィルターは、両方のチームがルートオブジェクトと連絡先を文書化していれば迅速な修正であり得る。顧客のネットワークスタッフ、IBM サポートスタッフ、キャリアがそれぞれケースの自側のみを見る場合、数時間を消費する可能性がある。
このため、シンガポールのホスティングフットプリントは、単一の施設名ではなく依存関係チェーンとして評価されるべきである。ホストされたコンピュート、プライベートリンク、パブリックインターネットパス、バックアップストレージ、DNS、サポートは別々の層である。Direct Link は適切に設計されたときに1つの層を強化する。また、チームが「プライベート」は「レジリエント」を意味すると想定する場合、依存関係をより見えにくくすることもできる。IBM のドキュメントは設計の負担を公開している。購入者はその明確さを活用すべきである。
IBM Cloud Object Storage とバックアップオプションは、配置が意図的である場合にのみ役立つ
バックアップとデータポータビリティは、多くのホスティング容量障害が技術的な驚きから管理上の失敗に変わる場所である。IBM Cloud Object Storage は、単一のクラシックサーバーよりも強い公開レジリエンスストーリーを持つ。エンドポイントとストレージロケーションのドキュメント（https://cloud.ibm.com/docs/cloud-エンティティ-storage?topic=cloud-エンティティ-storage-endpoints）は、リージョナルバケットがメトロエリア内の3つのデータセンターにデータを分散し、クロスリージョンアクセスは異なるパフォーマンスとレジリエンスプロファイルを持つと述べている。IBM のレガシーエンドポイントドキュメント（https://cloud.ibm.com/docs/cloud-エンティティ-storage?topic=cloud-エンティティ-storage-remap-endpoints）は、リージョナルエンドポイントが3つのデータセンターにデータを分散し、それらのデータセンターのいずれかが障害や破壊を受けても可用性に影響しないと述べている。IBM の Object Storage レジリエンシページ（https://www.ibm.com/products/cloud-エンティティ-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）は、管理者がフルシステム、ディレクトリ、またはファイルに対して時間単位、日次、週次、またはカスタムスケジュールを設定できると述べている。ベアメタルリストアガイド（https://cloud.ibm.com/docs/Backup?topic=Backup-configureBMR）は、Cloud Backup ポータルとベアメタルリストアジョブを説明している。これらのページは、IBM がクラシックインフラストラクチャ向けのバックアップツールを提供していることを示している。また、バックアップは設定されたサービスであり、サーバーを持つことの自動プロパティではないことも示している。
障害経路は想像しやすい。顧客は、ローカルレイテンシと専用リソースを求めてシンガポールのベアメタルサーバーを購入する。安定したプライベートアクセスを求めて Direct Link を追加する。バックアップサービスを使用するが、リストアドキュメントを同じ Direct Link を通じてのみ到達可能な内部システムに保存する。インシデント中、サーバーはダウンし、プライベートパスは劣化し、サポートケースは開かれ、チームはバックアップが存在するが、十分に速くない、アプリケーション一貫性がない、別の都市にリストアできない、または通常の管理者グループ外のチームメンバーに文書化されていないことに気づく。そのシナリオの何も IBM の公開ドキュメントと矛盾しない。まさにそれが顧客の責任が重要である理由である。
ポータビリティも同様の形状を持つ。IBM はカスタムイメージテンプレートと VPC イメージエクスポートを文書化している。これらのメカニズムは退出または再構築の摩擦を減らすことができるが、ライセンス、アイデンティティ、シークレット、ネットワークアドレス指定、ファイアウォール、DNS、データ同期のタスクを排除しない。カスタムイメージはアプリケーションがイメージフレンドリーである場合に有用である。重要な状態がアタッチされたボリューム、データベース、NAS 共有、アプリケーションログ、手動でパッチ適用された設定ファイル、または他の場所で誰も再構築していないプライベート統合にある場合、あまり有用ではない。シンガポールで運用している顧客にとって、ポータビリティテストはライブかつ測定可能であるべきである。チームはsng01外で代替を起動できるか？そこにデータをリストアできるか？ユーザーは到達できるか？イベント中に運用するのに十分なコンプライアンスとレイテンシの保証を維持できるか？
最良の証拠は顧客固有のものである：バックアップターゲットロケーション、リストア時間テスト結果、イメージエクスポートログ、セカンドサイト構築ノート、Direct Link フェイルオーバー証明、サポートエスカレーション連絡先、アプリケーションランブック。これらは公開されておらず、この記事がそうであるふりをするべきではない。公開記録は IBM がツールを提供すると述べている。また、責任は依然として共有され、サービス固有であるとも述べている。
ジュロンイースト周辺の施設市場は電力とリースの疑問を提起する
シンガポールは、土地、電力、冷却、接続が希少であるため、まさに高価値のデータセンター市場である。IBM シンガポールフットプリントはその広範な制約内にある。IMDA のグリーンデータセンターロードマップ（https://www.imda.gov.sg/how-we-can-help/green-dc-roadmap）は、シンガポールが短期間に少なくとも300 MW の追加容量を提供し、グリーンエネルギー展開を通じてさらに可能性があると述べている。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年に解除され、パイロット募集が4つの提案を選択したと述べている。シンガポール経済開発庁の概要（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 MW の追加データセンター容量と、グリーンエネルギーオプションを使用する事業者向けにさらに200 MW の可能性を説明している。
これらの公式ソースは IBM 固有ではないが、IBM-SG-AP IBM Sinapore Server Farm に直接関連する。なぜなら、シンガポールのホスティング容量は同じ投入市場によって制約されるからである。クラウドプロバイダーは、スペース、電力、冷却、ネットワークポート、サプライチェーン、運用許可がある場合にのみ、サーバーをリフレッシュし、新しい構成を販売できる。シンガポールの容量が逼迫している場合、顧客は希望するサーバープロファイルがsng01で利用可能か、大規模構成には別の IBM Cloud ロケーションが必要か、予約容量が可能か、地域的な需要の急増時にハードウェア交換にどのくらい時間がかかるかを尋ねるべきである。
Digital Realty の29A International Business Park の歴史は、この質問に具体的な形を与える。2011年の Digital Realty/SoftLayer 発表は、その物件がジュロンイーストの370,500平方フィートの施設であり、最大30 MW の2N UPS 容量と6つのデータセンターフロアの各フロアに4.5 MW 以上の IT 負荷を持つと述べていた。データセンター Knowledge の Digital Realty 買収記事（https://www.datacenterknowledge.com/next-gen-data-centers/digital-realty-buys-singapore-data-center）は、同じサイトが2011年に顧客占有可能であり、6つのフロアの各フロアに4.5 MW 以上の IT 負荷と N+2 連続冷却を備えていたと説明している。Digital Realty の現在の SIN10 ページは近くの現在の建物サイズを示しており、現在のシンガポールページは市場の認証とエコシステムの主張をリストしている。
証拠のギャップが重要である。公開文書は、古い IBM または SoftLayer フットプリントのうちどれだけがリースされ続けているか、IBM が SoftLayer を買収した後にどれだけが変更されたか、IBM がsng01製品を現在のスペースにどのようにマッピングしているか、または予備容量があるかどうかを述べていない。また、そのサイトでの IBM ラックの現在の電力密度制限も開示していない。通常のサーバーを購入する顧客はそれらの詳細を必要としないかもしれない。大規模なシンガポール拡張、規制ワークロード、アプライアンスリフレッシュ、または大規模ベアメタルフリートを計画している顧客は必要とする。その証拠がなければ、契約はサービスを約束できるが、顧客自身の拡張計画は依然としてロケーションレベルの容量問題に依存する。
同じ問題がサポートとメンテナンスに現れる。IBM Cloud のステータスページ（https://cloud.ibm.com/status）およびステータス履歴（https://cloud.ibm.com/status/history）は、顧客にプラットフォーム通知を確認する公開方法を提供する。IBM のサポートガイド（https://cloud.ibm.com/docs/support?topic=support-viewing-status）は、主要インシデント、計画メンテナンス、セキュリティ速報の表示方法を説明している。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 顧客は重要なビジネス影響に最初に気づいてから24時間以内に Service Down ケースを記録しなければならないと述べている。
これらのプロセスは価値があるが、修理と同じではない。ステータスページは IBM が問題を認識していることを確認できる。サポートケースは顧客をキューに入れることができる。重大度定義は期待を設定できる。修理は依然としてどの層が故障し、誰が行動する権限を持っているかに依存する。問題が専用サーバーのディスク障害の場合、ハードウェアアクセスとスペアが重要である。問題が Direct Link の場合、BGP、クロスコネクト、またはキャリア調整が重要である。問題がプラットフォームレベルのインシデントの場合、顧客アーキテクチャが重要である。問題が課金またはアカウントアクセスの場合、運用権限とアイデンティティ管理が重要である。顧客は各障害を適切な IBM チャネルと適切な内部所有者にマッピングするプレイブックを必要とする。
AS36351 は規模を証明するが、顧客ごとの復旧を証明しない
IBM Cloud のネットワーク証拠は自律システムレベルでは実質的である。PeeringDB（https://www.peeringdb.com/net/1613）は、AS36351 を SoftLayer Technologies, Inc.（IBM の子会社）、別名 IBM Cloud として識別し、ウェブサイトオーバーライドhttps://www.ibm.com/cloud、ネットワークタイプコンテンツ、1,800 IPv4 プレフィックス、450 IPv6 プレフィックス、1-5 Tbps トラフィックをリストしている。BGP.tools（https://bgp.tools/as/36351）は、IBM Cloud を長年にわたるインターネットクリティカルネットワークと呼び、数百のピアと複数のアップストリームキャリアを持ち、シンガポールのピアリングエントリを BBIX Singapore で示している。Hurricane Electric のページ（https://bgp.he.net/as36351）は、AS36351 を IBM Cloud としてリストし、IBM Cloud および IBM Cloud International B.V.に関連する多くの IPv6 ネットワークエントリを示している。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 は異なる耐久性の選択肢を提供できるが、顧客はバケットの配置を選択しなければならない。ベアメタルはシングルテナンシーを提供できるが、顧客はバックアップとポータビリティを設計しなければならない。
これが、AS36351 を監視コンテキストとして使用すべきであり、安全な復旧の証明として使用すべきではない理由である。AS36351 と IBM Cloud のステータスを監視する。公開ルートの異常を監視する。シンガポールの Direct Link 通知を追跡する。しかし、顧客サービスを正確なリソースにマッピングする：クラシックデータセンター、VLAN、サーバーID、Direct Link ゲートウェイ、BGP セッション、バックアップターゲット、オブジェクトストレージバケット、DNS、アイデンティティ、サポートプラン、代替展開ロケーション。公開インターネットコントロールプレーンは答えの1つの層である。
シンガポールのホスティング面が故障した場合、誰が影響を受けるか
即座の影響を受けるグループは、一般的な「IBM ユーザー」ではない。それは、シンガポールのクラシックフットプリントにワークロード、管理パス、プライベート接続、または復旧資産が依存している顧客である。これには、低レイテンシのためにsng01にベアメタルサーバーを配置したエンタープライズ、クラシック Kubernetes または OpenShift リソースをシンガポールに維持したチーム、Transit Gateway を介して VPC リソースに接続されたクラシックインフラストラクチャを使用する顧客、シンガポールに Direct Link を持つ顧客、データローカリティまたはアジア太平洋アクセスのためにシンガポールを選択した組織が含まれる。
爆発半径は設計に依存する。1台のサーバー、1つの公開 IP、2番目のロケーションなし、手動バックアップ計画を持つ顧客は、小さなハードウェアまたは施設の問題がその資産に影響するときに完全にダウンする可能性がある。同じデータセンターに複数のサーバーを持つ顧客は、単一マシン障害を生き残るかもしれないが、サイトレベルの電力、冷却、アクセス、スイッチ、またはコントロールプレーンイベントは生き残れない。シンガポールコンピュートとクロスリージョンストレージを持つ顧客はデータを保存できるかもしれないが、他の場所にコンピュート容量がない。テスト済みビルド自動化、イメージエクスポート、クロスリージョンストレージ、2番目の Direct Link、グローバル DNS を持つ顧客は、sng01をサービス全体ではなく1つの重要なロケーションとして扱うことができる。
規制グループはより広い。シンガポールのデータローカリティは、金融サービス、政府関連、医療、物流、地域本社のワークロードにとってしばしば魅力的である。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、ユーザーコミュニケーション、ロールバックを処理しなければならない。シンガポールのインシデントは、その作業が早期に行われたか、最初の悪い夜に残されたかを明らかにする可能性がある。
経済グループには、予測可能なパフォーマンスやライセンス管理のために専用ハードウェアを使用する顧客が含まれる。IBM のベアメタルオファーは、SAP、VMware、ハイパフォーマンスワークロード、シングルテナント管理にとって魅力的である。しかし、同じ顧客は正確なハードウェアプロファイルの可用性により敏感であり得る。仮想リソースはより広いプールから交換可能かもしれない。カスタムベアメタル構成は、適切な場所にマッチング在庫が存在する場合にのみ交換可能である。顧客の契約とアーキテクチャは、同じプロセッサ、RAM、GPU、ストレージ、またはネットワークプロファイルがシンガポールで即座に利用できない場合に何が起こるかを述べるべきである。
購入者と運用者向けのウォッチポイント
最初のウォッチポイントは正確な配置である。IBM に、サービスがsng01、別のシンガポールロケーション、他の場所の VPC マルチゾーンリージョン、またはストレージとコントロールプレーンが独自の配置を持つマネージドサービスのいずれにあるかを特定するよう依頼する。シンガポールのラベル、シンガポールの請求先住所、またはアジア太平洋サービスエリアが同じ物理的依存を意味すると想定しない。IBM 自身のドキュメントは、クラシックデータセンター、リージョン、シングルキャンパス設計、マルチゾーンリージョンを区別している。それらの用語を慎重に使用する。
2番目のウォッチポイントは Direct Link の多様性である。プライベートアクセスが重要な場合、1つの Direct Link では不十分である。IBM のドキュメントは、Direct Link は本質的に冗長ではなく、2番目の多様なリンクを推奨している。顧客は、シンガポール1とシンガポール2がそのプロバイダーミックスにとって真に多様であるか、BGP フェイルオーバーが自動であるか、ルートフィルターがテストされているか、ローカルおよびグローバルルーティングの選択が復旧設計に一致するか、サポート連絡先がキャリア側と IBM 側の両方で既知であるかを文書化するべきである。
3番目のウォッチポイントはスペアハードウェアと再構築時間である。IBM の公開ページはsng01のスペア深度を開示していない。専用サーバーを持つ顧客は、故障したコンポーネントがどのように交換されるか、マッチングスペアシステムが存在するか、拡張ハードウェアテストが緊急プロビジョニングにどのように影響するか、同等のプロファイルが代替可能か、アプリケーションが別のロケーションへの移動に耐えられるかを尋ねるべきである。GPU、高メモリ、またはライセンスワークロードの場合、答えがサービスが単に利用不可か商業的に行き詰まるかを決定する可能性がある。
4番目のウォッチポイントはバックアップの地理である。IBM Cloud Backup for Classic と Object Storage は両方とも役立つが、バックアップターゲットとリストアターゲットが意図的に選択されている場合のみである。ローカルバックアップは高速だがサイト依存であり得る。クロスリージョンバケットは生存性を改善できるが、主権、レイテンシ、コストに影響を与える可能性がある。カスタムイメージは再構築に役立つが、すべての状態を含まない場合がある。ベアメタルサーバーはエクスポート決定について顧客管理のままである。
5番目のウォッチポイントは公開ステータスの盲点である。IBM Cloud ステータスページは有用だが、多くの顧客障害はグローバルインシデントではない。誤設定された BGP アナウンス、単一の Direct Link 障害、アカウント権限の問題、プライベート VLAN の問題、ディスク障害、顧客ファイアウォールエラー、または期限切れ証明書は、広範な公開インシデントとして表示されない場合がある。顧客は、IBM Cloud の外部、IBM Cloud 内部、Direct Link 経由、ユーザー地理からの独自の監視を必要とする。
6番目のウォッチポイントはリースと施設の不透明性である。Digital Realty と SoftLayer の歴史はシンガポールの物理的アンカーを強く支持するが、公開証拠は現在の IBM スペース、リース期間、正確な部屋、ラック数、または電力予約を開示していない。大規模顧客は、特に予約ハードウェア、長期データ居住、または特別サポートカバレッジを必要とする拡張を計画する場合、調達を通じて現在の施設と容量の確認を求めるべきである。
7番目のウォッチポイントは退出コストである。IBM Cloud はポータビリティメカニズムを提供できるが、シンガポールのワークロードを移動することは、顧客がローカル IP アドレス、プライベートリンク、独自の自動化、手動イメージ、またはエクスポートが困難なデータボリュームに依存している場合、依然として遅い可能性がある。真の退出計画には、エクスポートが可能であると言う文書だけでなく、最近のリストアテストが含まれる。
証拠グレード：中程度、指名資産では明確な格下げ
シンガポールの IBM Cloud の証拠は、別途ブランド化された「IBM Sinapore Server Farm」の証拠よりも強い。IBM 自身のドキュメントは、sng01、ジュロンイースト、クラシックインフラストラクチャ、クラシック Kubernetes および OpenShift のロケーション行、Transit Gateway 互換性、Direct Link シンガポールロケーション、ベアメタルサービスの説明を提供している。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配置を確認する。プライベートアクセスが重要な場合、2番目のネットワークパスを構築する。バックアップを、それが生き残ることを意図した障害ドメインの外部に維持する。サポートケースが緊急になる前に、イメージエクスポートとリストアをテストする。簡単に交換できないプロファイルを注文する前に、ハードウェア在庫について尋ねる。AS36351 と IBM Cloud ステータスを監視するが、グローバルネットワーク規模とワークロードごとの復旧を混同しない。クラウド注文はデジタルかもしれないが、復旧パスは依然として物理的、契約的であり、IBM、施設事業者、キャリア、顧客の間で共有される。