要約
- Serverwala は 6 大陸で 50 以上のデータセンター、インドの数十の都市でコロケーションを販売しているが、そのロケーションページは他のデータセンター事業者とのパートナーシップや長期契約について説明している。公開証拠はホスティングおよびネットワーク事業者としてパートナーエステートを持つことを示しており、それらの建物の所有権を確立するものではない。
- AS149573 は現在のネットワーク運用の強力な証拠を提供する。2026 年 7 月 12 日の RIPE RIS スナップショットでは、17 のオリジネートされた IPv4 /24 プレフィックス、325 の IPv4 コレクターピア間での完全な可視性、ポートフォリオ全体で 4 つの可視の商用アップストリーム、および可視の IPv6 ルートなしが示された。
- ポートフォリオレベルのキャリア選択は個々の顧客にとっての回復力と同じではない。公開ルートパスでは、各現在のプレフィックスは 1 つの直近アップストリームによって支配されていた。8 つは TeleIndia Networks、6 つは Primesoftex、2 つは CtrlS、1 つは Yotta Network Services であった。
- 同じチェックで 15 の現在のプレフィックスが RPKI 有効であったが、151.242.51.0/24 と 193.151.181.0/24 は、公開されたルート認証が AS834 を指定しており、Serverwala の AS149573 ではなかったため無効であった。この不一致は無効なルートを拒否するネットワークを介した到達可能性に影響を与える可能性がある。
- 証拠グレードは現在のネットワーク運用については中程度、施設レベルの回復力については弱い。購入者は名前付きサイト、認定トポロジ、ユーティリティおよび発電機の証拠、キャリア経路マップ、テスト済みフェイルオーバー結果、正確なラックまたはサーバーの場所に結び付けられた契約条件を必要とする。
別の場所を指し示すコルカタのオファー
あるページが中心的な問題を特にうまく捉えている。Serverwala のコルカタコロケーションオファーは、同社がインドのデータセンターと 5 年から 10 年の契約を結んでおり、冗長グリッド、無停電電源装置、発電機、冷却、24 時間体制のリモートハンズを約束している。しかし、同じコルカタページの仕様表にはドイツの場所の電気と空調の料金が記載され、リモートハンズの価格はユーロ表示され、サブネット料金もユーロ建てとなっている。このページは異なる市場向けの商用モジュールを組み合わせた可能性がある。説明はともかく、これはコルカタの 1 施設の明確なエンジニアリング仕様として読むことはできない。
この矛盾は単なる無関係な通貨記号以上に重要である。コロケーションを選ぶ顧客はコルカタという概念を購入するのではない。特定の建物のキャビネット、特定の配電盤、発電機、チラー、ファイバーエントランス、運用チームに接続されたものを購入するのである。販売ページが都市のオファーと他国の施設の経済性を混ぜ合わせている場合、顧客はどの記述が自社の機器が実際に設置される場所を説明しているのか判断できない。
Serverwala のノイダページも同じ広範な構造である。1 ラックユニットからフル 40U キャビネットまでのプランを提供し、複数の電源、UPS システム、バックアップ発電機、複数のネットワークリンクを説明し、その後アクセスは他のデータセンターとの提携を通じて行われると説明している。ページは各プランの背後にある建物、ユーティリティ接続、発電機構成、キャリアエントランス、施設運営者を明記していない。購入可能な製品を提供しているが、基礎となる障害ドメインを明らかにしていない。
これはサービスが利用できないことの証明ではない。可用性は注文レベルで確立されるべきであり、ロケーション名から推測されるべきではないことを示す証拠である。仲介業者は規律ある契約と有能なパートナーを通じて優れたインフラを提供できる。また、より長い復旧チェーン（顧客から Serverwala、Serverwala から施設、施設からユーティリティまたはキャリア、そして戻ってくる）を生み出す可能性もある。そのチェーンの質は、ロケーションカタログには示されていない権利、エスカレーション時間、テストされた連携に依存する。
会社の境界は世界地図よりも狭い
法的および商業的アイデンティティはインド側ではかなり明確である。Serverwala のウェブサイトは国内請求エンティティを Serverwala Cloud Datacenters Private Limited と特定し、法人番号U72501RJ2020PTC069177を提供している。公開会社情報では、2020 年 6 月 18 日にジャイプールで設立されたと記録されている。同社の連絡先ページにはジャイプール、スーラト、ナシク、ムンバイのオフィスがリストされ、アバウトページではブランドは 2015 年に始まりドバイ支店があると述べられている。
これらの日付は共存可能である：ブランドまたはそれ以前の事業が現在の会社に先行する可能性がある。これらを、この特定の 2020 年エンティティが 2015 年からグローバルな施設ポートフォリオを所有していたという主張にまとめるべきではない。インドの顧客にとって有用な境界は、請求書と契約に記載されたエンティティである。Serverwala の利用規約は、インドの顧客はインドの民間会社と契約し、国際顧客はアラブ首長国連邦の Serverwala InfraNet FZ-LLC を使用すると述べている。同じページの後の条項はまだ別の Serverwala の企業形態に言及しており、署名された注文書と明示的な優先条項が一般的なウェブサイトのテキストよりも重要であることを示している。
世界地図ははるかに広い。ホームページは 6 大陸で 50 以上のデータセンター、8,500 以上の専用サーバー、6,800 のクラウドサーバー、1,500 の GPU サーバー、14,000 のビジネス顧客を宣伝している。インドの多くの都市や国際市場への展開を提供している。これらの数字は会社の主張である。それらには建物名、運営者名、委託メガワット、占有ラック、監査日、認証識別子を伴った公開のサイト別在庫は存在しない。
Serverwala 自身の表現がビジネスモデルを示している。ノイダページはインド全土のデータセンターとのパートナーシップに言及している。コルカタページは現地ベンダーやテクノロジー企業との長期契約および直接契約に言及している。米国コロケーションページも同様にデータセンターパートナーとの 5 年から 10 年の契約を説明している。一貫した解釈は、Serverwala がサプライヤーネットワーク全体で容量、サポート、接続性をパッケージ化しているというものである。これは正当なビジネスモデルであるが、販売ページの「当社のデータセンター」という言葉は不動産登録として扱われるべきではない。
所有権だけが問題ではない。運用権限も同様に重要である。誰が緊急アクセスを承認できるのか？ UPS および発電機の保守契約を誰が所有するのか？ エッジルーターを誰が制御するのか？ 切断中に顧客を別のキャリアに移動できるのは誰か？ 故障したディスク、電源、クロスコネクトを午前 2 時に交換することを決定するのは誰か？ 再販業者はこれらの権利の一部を保持し、他を委任することができる。購入者は自社のサイトについてその区分を文書化してもらう必要がある。
AS149573 は実際の運用ネットワークの証拠である
公開ネットワーク記録は施設カタログよりも具体的である。APNIC の RDAP 記録は AS149573 がアクティブで、2022 年 5 月 12 日に登録され、管理連絡先および技術連絡先が Serverwala とそのジャイプールの登録事務所住所に結び付けられていることを示している。RIPEstat の AS 概要は保持者を Serverwala Cloud Datacenters Private Limited と名付け、自律システムが 2026 年 7 月 12 日にアナウンスされたことを示した。
RIPEstat のルーティングステータスビューは規模を追加する。4,352 アドレスを含む 17 の IPv4 プレフィックスと、スナップショット内のすべての 325 の IPv4 RIS ピアからの可視性を記録した。最初に観測された Serverwala ルートは 2022 年 8 月の103.183.157.0/24であった。同じビューでは IPv6 アナウンスは見つからなかった。Serverwala の公開利用規約も、サーバーは通常 IPv6 を含まず、ページに記載された場所固有の例外に従うと述べており、ルーティングと商業的記述はおおむね一致している。
17 のルーティングされた/24は些細なものではない。Serverwala が単なるホスティングページに付随する会社名ではないことを確立している。ネットワークはグローバルに可視であり、複数の場所で使用されるアドレス空間をオリジネートし、複数のアップストリーム関係を持っていた。IPinfo の AS149573 ビューは、ムンバイ、バンガロール、アーメダバード、ハイデラバード、コルカタで応答するインフラを特定し、キャプチャ時におよそ 1,800 のホストされたドメインを 100 アドレスにわたってリストした。地理位置情報はおおよそのものであり、応答するルーターがラックアドレスの証明ではないが、その広がりはアクティブなマルチシティのインドサービス表面を支持している。
それでも結果には規律が必要である。自律システムはルーティングポリシーの境界であり、建物のリストではない。1 つの ASN はパートナー施設内の機器をアナウンスしたり、リースされたアドレス空間を運んだり、別のネットワークにトランジットを提供したり、サーバーが顧客に属するサービスを前面に出すことができる。逆に、顧客は施設やアップストリームから AS149573 ではなくアドレスを受け取る可能性がある。ASN はネットワーク運用を証明するが、Serverwala がトラフィックに関連するすべてのラック、冷却プラント、ファイバールートを所有していることを証明するものではない。
アドレスポートフォリオも変化する。アナウンスドプレフィックス履歴は、2 つの現在アクティブなブロック103.131.26.0/24と103.183.156.0/24が、再出現する前の直前の 2 週間の一部で欠落していたことを示した。他のブロックはその期間の後半にのみ出現した。ルートコレクターのタイムラインだけでは、メンテナンス、移行、ポリシー変更、測定効果、顧客への影響を区別できない。年間のスクリーンショットでは不十分であり、到達可能性は継続的に監視され、サービスのインシデントと相関される必要があることを示している。
4 つのアップストリームはすべてのサーバーに 4 つの出口を与えるわけではない
ASN レベルでは、キャリアの状況は有望に見える。RIPEstat のネイバービューは、アップストリーム側に Yotta Network Services、TeleIndia Networks、Primesoftex、CtrlS を、ダウンストリームとして Dynowave Technologies を観測した。IPinfo も同じ 4 つのアップストリームを独立してリストした。これらの関係は Serverwala のルートを複数のインドネットワークに分散させ、ポートフォリオレベルで 1 つのサプライヤーへの依存を減らす。
プレフィックスビューは冗長性が低い。17 の現在のプレフィックスについて公開 RIPE RIS パス内の支配的な直近アップストリームを数えると、8 つは主に TeleIndia Networks を介して、6 つは Primesoftex を介して、2 つは CtrlS を介して、1 つは Yotta を介して広いインターネットに到達した。例えば、103.183.156.0/24の looking-glass ルートは、圧倒的に AS150609 を AS149573 の直前に配置した。103.131.24.0/24は圧倒的に AS17426 の背後にあり、151.243.12.0/24は AS18229 の背後に、103.131.25.0/24は AS140641 の背後にあった。
一部のパスは、第 2 のネイバーを介した少数の観測を示した。これはバックアップ、移行、またはコレクター固有の伝搬を反映している可能性がある。残りのパスが完全な顧客負荷を運べること、フェイルオーバーが自動であること、またはファイバーが物理的に分離されていることを結論付けるには不十分である。支配的なパターンは、ポートフォリオ全体としては 4 つあるにもかかわらず、プレフィックスごとに 1 つの直近アップストリームである。
この区別はキャリア回復力の核心である。会社は複数のキャリアと協力していると真実に言える一方で、特定のラックは 1 つのクロスコネクト、1 つのルーター、1 つのローカルループ、または 1 つのアクティブアップストリームに接続されている可能性がある。また、同じダクトに入り、同じラインカードで終端し、または同じミートミールームに依存する 2 つの論理セッションを持つこともできる。BGP 多様性、キャリア多様性、建物入口多様性、容量多様性は別々の特性である。
Serverwala のホスト帯域幅ページは、ミートミールームを介したマルチキャリアアクセス、動的パス選択、保証帯域幅、バースト可能オプションを約束している。購入者はこれらの記述をプレフィックス固有の設計に変換すべきである。注文された場所にサービスを提供する 2 つのキャリアはどれか？ 各々からどのルートが受け入れられているか？ 両方のセッションがアクティブか？ それらは別々のルーターと電源フィードで終端しているか？ 生存リンク上のコミットされたレートはどれか？ ミートミールーム自体が共通の依存関係か？ 公開ルートテーブルはこれらの質問に答えることができない。
また、確認時点でPeeringDB APIには AS149573 の公開ネットワークプロファイルはなかった。任意のデータベースへの欠如は欠陥ではない。そこに交換ポイント、施設、相互接続ポリシー、トラフィックスケール、または広範なミートミールームの主張を裏付ける可能性のあるネットワーク連絡先の運営者管理の公開リストがないことを意味する。プライベートな相互接続インベントリが存在する可能性があるが、購入者はそれを要求する必要がある。
2 つのルート認証の競合は直ちに対処すべきである
Route Origin Authorisation は狭いながらも価値のある制御を提供する。アドレス保持者がどの自律システムがプレフィックスを発信できるかを指定できるようにする。Route Origin Validation を実行するネットワークは、観測された発信元が公開された認証と競合する場合にアナウンスを拒否できる。これはすべてのハイジャックやルーティングエラーを防ぐわけではないが、到達可能性障害の 1 つの回避可能な原因を減らす。
Serverwala の 17 の現在のプレフィックスのうち 15 は 7 月 12 日のチェックで有効であった。2 つはそうではなかった。151.242.51.0/24と193.151.181.0/24の RIPEstat の検証はinvalid_asnを返した。どちらの場合も、カバーする認証は IPXO が運営する AS834 を指定していたが、公開ルートは Serverwala の AS149573 から発信されていた。
その観測は競合がなぜ存在するかを確立しない。アドレス空間はリース、再割り当て、移行、または BGP で可視ではない取り決めの下で一時的にアナウンスされる可能性がある。運用上の影響は商業的説明よりも明確である：無効な発信元を拒否するネットワークは、他のネットワークが受け入れ続けている間でも、これら 2 つの Serverwala アナウンスをドロップする可能性がある。影響を受けるプレフィックスの顧客は、ソースネットワークによって異なる到達可能性を見る可能性がある。
救済策は測定可能である。ルート認証を制御する当事者は、意図された取り決めに応じて、AS149573 の有効なレコードを公開するか、Serverwala が認証された ASN を介して発信することができる。修正は複数のバリデーターとアップストリームネットワークから観測されるべきである。それが起こるまで、これらのプレフィックスは、独立したパスなしで顧客の唯一の管理アドレス、バックアップエンドポイント、または公開サービスをホストすべきではない。
RPKI の有効性は一般的な回復力の証明書ではない。有効なルートでも、電源の入っていないラック、飽和リンク、または故障したファイアウォールに導かれる可能性がある。ここでは、Serverwala が現在のポートフォリオのほとんどについて制御を正しく完了しているため重要である。2 つの例外は可視的で、具体的で、修正可能である。
電力の主張には名前付きの電気チェーンが必要
同社のコロケーションページは安心できるコンポーネントを使用している：複数の電源、UPS システム、バックアップ発電機、一部のページでは冗長電力グリッド。これらは正しいカテゴリである。まだ設計ではない。購入者は、電気がユーティリティ接続から自社の機器に給電する正確な A および B コンセントまでどのように移動するか、およびどの要素が負荷を中断せずに取り外せるかを知る必要がある。
「複数の電源」は非常に異なるシステムを説明できる。2 つのユーティリティフィードが 1 つの変電所から来る場合がある。2 つの変圧器が上流の開閉装置を共有する場合がある。2 つの UPS モジュールが 1 つの配電経路に配置される場合がある。デュアルコードサーバーは両方のコードが同じ配電ユニットに接続されている場合がある。発電機は適切な定格電力を持っていても、長期の停電に備えた十分な燃料、冷却、または起動信頼性がない場合がある。有用な証拠は、現在の単線結線図、保護装置の協調、保守履歴、負荷バンクテスト結果、および転送テスト記録である。
Serverwala の公開ページは、名前付きのインド施設についてこれらの詳細を提供していない。測定された臨界負荷での発電機運転時間、オンサイト燃料量、燃料補給優先順位、UPS バッテリー自律時間、ユーティリティフィーダー元、ラック電力密度、各コンポーネントの保守状態を明記していない。会社はパートナーを通じてそれらの情報のすべてを非公開で保持している可能性がある。それなしでは、無停電電源の約束は、建物に結び付けられた監査可能な能力ではなく、都市に結び付けられたマーケティングクレームのままである。
「Tier」という言葉も同じ精度を必要とする。一部の Serverwala ページは Tier III コロケーションを説明している。Uptime Institute の Tier 定義は、Tier III を同時保守可能性の周りで定義している：容量コンポーネントと配電経路は、重要負荷をシャットダウンせずに計画作業のために取り外せる。Tier 認証はサイト固有であり、設計、建設施設、運用を区別する。サービスが Tier III であるという一般的な記述は、どの施設がどの段階で、どのバージョンに対して認証されたか、または証明書が現在も有効かを特定しない。
発電機の耐久性は、プロバイダーがパートナーサイトに依存する場合に特に重要である。Uptime Institute は、Tier 定義施設の開始要件として、サイトの規定設計負荷で 12 時間のオンサイト燃料を説明しているが、燃料システムの信頼性も強調している。12 時間は、地域の緊急時に道路、サプライヤー、契約が燃料を届け続けることを保証するものではない。Serverwala は、発電機が存在するというだけでなく、注文されたサイトのテスト済み運転時間と補充計画を述べることができるべきである。
（翻訳は続く…）