概要

  • IBM Cloud は、クラウド市場で最も有用なロケーション公開マップの 1 つを公開している。完全なマルチゾーンリージョン、シングルキャンパスマルチゾーンリージョン、従来のデータセンターコード、ユニバーサルゾーン名、PoP コードなどである。このマップにより、顧客はリージョン名を単なるソフトウェアとして扱うのではなく、地域選択を物理的なデータセンターグループに結びつけることができる。
  • 同様の証拠は、ハードなリカバリーケースを決定する事実までには及んでいない。公開文書では、正確な施設所有権、サイトレベルの MW、現在のラック負荷、ユーティリティトポロジー、ダークファイバールート、ライブバックボーン利用率、Direct Link キャリアの多様性、または空き交換容量は開示されていない。
  • IBM 自身の文書は、一部のマーケティングクレームを狭めている。ハードウェア依存プロファイルはどこでも利用できるわけではなく、従来の仮想サーバーリクエストは容量不足に陥る可能性があり、ベアメタル在庫はデータセンターごとに動的であり、Direct Link は自動的に冗長化されているわけではなく、VPC ゾーンリソースはゾーン全体が障害を起こした場合に別のゾーンに移動しない。
  • IBM のインシデント、移行、クローズマテリアルは、インフラストラクチャのポイントを具体化している。グリッド障害、冷却電源障害、火災、施設ネットワーク障害、計画された CHE01 のクローズは、クラウドの地理が単なるコンプライアンスの選択ではなく、実際の建物、オペレーター、キャリア、メンテナンスウィンドウ、データ移動容量への依存であることを示している。

リージョンラベルは物理的な選択

IBM Cloud のロケーション文書で最も有用な点は、顧客を完全に抽象的なリージョンリストだけに残さないことである。完全なマルチゾーンリージョン、シングルキャンパスマルチゾーンリージョン、そして従来のデータセンターがあることを説明している。ツールやコンソールのワークフローに表示されるリージョン名は、物理的なデータセンターグループにマッピングされる。ダラス、サンパウロ、トロント、ワシントン DC、フランクフルト、ロンドン、マドリッド、シドニー、東京は単なる販売地域ではない。これらはリージョン選択であり、その VPC ゾーンはユニバーサルゾーン名にマッピングされ、それらのユニバーサル名は DAL10、FRA05、LON06、SYD04、TOK05 などの基礎となるデータセンターコードを識別する。

これにより、IBM Cloud は公開マップが都市ラベルで止まるプロバイダーよりも監査可能になる。顧客は、論理ゾーン内の VPC リソースが名前のないクラウドに浮かんでいるのではないことを確認できる。それはアカウント固有のゾーンマッピングと物理ロケーションコードに関連付けられている。従来のインフラストラクチャと Power Virtual Server リソースはさらに直接的で、ロケーションはリージョン抽象化ではなくデータセンターコードで指定される。IBM はまた、南北アメリカ、ヨーロッパ、アジア太平洋全体で 42 の従来のデータセンターコードをリストしている。そのインベントリには、DAL08、AMS03、FRA05、LON02、CHE01、SNG01、TOK05 などの長年にわたる名前が含まれている。

しかし、証拠はそのまま読むべきである。データセンターコードは、住所、電力契約、地主の開示、キャリアのダクトマップ、在庫報告ではない。これは IBM のクラウド運用モデル内の物理ロケーション識別子である。それはクラウド製品が実質的な場所を持つという結論を支持する。しかし、その場所に十分な未コミットサーバー、十分な予備電力容量、2つの独立したファイバー入口、独立した燃料ロジスティクス、またはテスト済みの顧客フェイルオーバー容量があるという結論を単独で支持することはできない。

この区別が重要なのは、クラウド購入者がしばしばリージョンをコンプライアンスとレイテンシの対象として購入し、設計またはリカバリー中にそれが在庫対象でもあることを発見するからである。顧客が特定のベアメタルプロファイル、GPU 搭載従来サーバー、Direct Link PoP、ローカルオブジェクトストレージクラス、または障害発生ワークロードを吸収できる代替ゾーンを必要とする場合、名前付きリージョンは最初のフィルターにすぎない。本当の問題は、要求されたサービス、プロファイル、回線、リカバリターゲットが、アカウントが使用できる IBM Cloud の物理的部分で利用可能かどうかである。

SoftLayer はホスティング資産を残し、無限に伸縮可能なプールではない

IBM Cloud の現在のインフラストラクチャ資産は、ホスティングビジネスの形状を今も保持している。2013 年の IBM Form 10-Q は、IBM が SoftLayer を 19 億 7700 万ドルで買収したことを記録している。IBM の歴史的な SoftLayer 買収 FAQ は、ダラスを拠点とし大規模な顧客基盤を持つ専用・仮想インフラストラクチャビジネスを説明している。この起源が重要なのは、SoftLayer がリージョン限定のハイパースケール抽象化として生まれたわけではないからである。それは、データセンター、ベアメタル在庫、VLAN、プライベートネットワーキング、顧客固有のサーバー、名前付き施設に関する運用手順から構築されたホスティングプラットフォームであった。

現代の IBM Cloud プラットフォームは、その資産の上に VPC、マネージドサービス、オブジェクトストレージ、Kubernetes、OpenShift、グローバルプラットフォームサービスを重ねている。しかし、従来のデータセンターリストは依然として存在し、一部の移行・ライフサイクル通知は直接データセンターコードを参照する。ロケーション文書は、従来のデータセンターが電源、冷却、コンピュート、ネットワーク、ストレージリソースをホストし、POD アーキテクチャを使用すると述べている。POD はマーケティング形容詞ではない。それはラック、サーバー、ネットワーク、ストレージ、バックアップ発電機で構成される容量単位である。POD を追加すると、販売可能なものが変わる。サーバー、ルーター、ストレージタイプ、電気的エンベロープが不足すると、プロビジョニング可能なものが変わる。

そのため、IBM のダラス DAL14 VPC 拡張発表などの拡張の歴史は、無制限の容量証明として読むべきではない。発表では、追加されたダラスのアベイラビリティゾーン施設を特定し、なぜ IBM がより多くのダラス容量を望んだのかを説明している。設置メガワット、サーバー数、現在の使用率、リース条件、機器バッチ、顧客コミットメントは開示されていない。IBM がリージョンにサービスを提供するために物理的なデータセンターのロケーションを追加していたという有用な証拠である。後の顧客注文がすべてのダラスプロファイルで開かれた在庫を仮定できるという証拠ではない。

逆もまた同様であり、施設は時代とともに廃止される。IBM の CHE01 クローズ通知は、チェンナイ 01 の運用が 2027 年 6 月 10 日に終了すると述べている。通知は、市場終了管理、新規デプロイメント削除、ネットワークメンテナンス中断ウィンドウ、移行支援終了、PaaS および IaaS 移行ウィンドウの最終期限を設定する。クローズ通知は、コンソールの背後に通常隠されているインフラストラクチャの真実を露呈するため、まれなクラウド文書である：クラウドサイトにはライフサイクルがある。追加、制限、近代化、統合、閉鎖が可能である。CHE01 を耐久性のある配置として扱っていた顧客は、今やロケーション決定を移行プロジェクトに変える必要がある。

フル MZR とシングルキャンパス MZR は異なる障害地理

IBM が公開しているマルチゾーンリージョンとシングルキャンパスマルチゾーンリージョンの区別は、リージョンラベルが快適になりすぎるのを防ぐため、価値がある。フル MZR は、メトロエリア内の別々のデータセンターロケーションにまたがる複数のゾーンを使用する。ロケーションページはゾーンを障害ドメインとして説明し、フル MZR モデルは 3 つ以上のデータセンターを使用すると述べている。また、ゾーン間の正確な距離は地域によって異なり、最小分離距離を示している。これは有用な地理である。ダラスやロンドンのリージョンが単なる 3 つのソフトウェアラベルが付いた 1 つの部屋ではないことを示している。

シングルキャンパス MZR は異なる種類の真実を持つ。同じ IBM 文書は、チェンナイ (Airtel)、モントリオール、ムンバイ (Airtel)、大阪をシングルキャンパス MZR としてリストしている。IBM は、これらのゾーンが同じ建物の異なるセクションまたはキャンパス内の複数の建物にあり、電力、冷却、ネットワーキング、物理的セキュリティの依存関係が重複する可能性があると述べている。これは小さな注意事項ではない。障害モデルを変える。シングルキャンパスリージョン内の 3 つのゾーンにリソースを分散する顧客は、多くの機器やメンテナンスの故障に対してローカルの可用性を向上させる可能性があるが、地理は 3 つの分離されたメトロサイトと同じではない。

IBM の VPC 高可用性およびディザスタリカバリガイダンスは、違いをさらに明確にしている。ゾーン全体の障害により、そのゾーン内のゾーンリソースが利用できなくなり、影響を受けるゾーンの仮想サーバーインスタンスは自動的に他の健全なゾーンに移動されない。また、シングルキャンパス MZR でのデータセンター災害は、ゾーンがより密接に関連しているため、リージョン全体に影響を与える可能性があり、別の MZR へのバックアップおよびリカバリ戦略を使用する必要がある。これらの行は重要である。マップからアーキテクチャに責任を戻すからである。顧客は MZR 名を購入して、すべてのリソースがリージョナルになったと想定することはできない。

実際の影響は単純である。リージョナルサービスは、ゾーン間でデータプレーンを分散し、リージョン内でリクエストを再ルーティングする可能性がある。ゾーン仮想サーバー、サブネット、ゲートウェイ、ボリュームはゾーンに結びついたままである。単一ホストの障害は、ゾーン全体の損失とは異なる処理が可能である。完全なリージョナル災害はまた異なる。各層は異なる容量の質問をする：残りのゾーンは健全か、リージョナルコントロールプレーンは利用可能か、ターゲットリージョンは在庫があるか、スナップショットはコピーされたか、DNS とアプリケーションはフェイルオーバーに耐えられるか、顧客はその移動をテストしたか。

調達にとって、これは購入者がゾーンの多様性を物理的多様性として扱う前に、アカウントのゾーンマッピングを尋ねるべきであることを意味する。IBM によると、アカウントの論理ゾーンマッピングは、リージョンで最初の VPC リソースが作成されたときに確立される。2 つのチームが「ゾーン 1」と言うとき、それはアカウントローカルの論理識別子を指しており、自動的に同じユニバーサルデータセンターコードではない。ユニバーサルゾーン名はより強力な証拠である。それなしでは、レジリエンス図は実際よりも物理的に正確に見える可能性がある。

（以下続く）