Tempest Hosting, LLC は、ラック、トランジット、修理期間に依存するホスティング容量を提供

要約

• Tempest Hosting, LLC は実際の公開運用面を持つ: AS36231 がアナウンスされ、PeeringDB には Tempest が 1-5 Tbps のトラフィックを有するグローバルコンテンツネットワークとしてリストされ、8つの施設プレゼンスと AS セットがある。RIPEstat の 2026-07-15 スナップショットでは 19 の IPv4 プレフィックスと 20 の IPv6 プレフィックスが観測された。
• より有用なリスクの問いは、Tempest が存在するかどうかではなく、アムステルダム、ダラス、ロンドン、フランクフルト、マイアミ、シカゴ、シドニーなどのサイトが弱点となった場合に、どの顧客ワークロードがどのラック、ルーター、ローカルスペアプール、アップストリームキャリア、サポートハンドオフに依存するかである。
• 公開されているメンテナンス記録とインシデント記録はここでは異常に有用である: Tempest はロンドンのコアルーター移行、ダラスのキャビネットおよびルーティング機器のアップグレード、ダラスのアップストリームキャリア障害、フランクフルトの IP 問題、コアスイッチ障害とスペア調達の遅延に関連するアムステルダムの停止を開示している。
• 証拠は強力なネットワークフットプリントの評価を支持するが、無制限の容量主張は支持しない。インストールされたプレフィックス、PeeringDB のトラフィック帯域、テストファイル、施設リストは、顧客利用可能な余裕、契約上の電力権、在庫された交換ハードウェア、または保証された移行時間を証明するものではない。

ホスティング企業は実在するが、運用層では依然不透明である

Tempest Hosting, LLC は、その公開トレースが小さなウェブホスティングのパンフレットよりもはるかに大きく見えるが、最も高額な質問を公開の視界の外に残している種類のプロバイダーである。公開アイデンティティは、BTW ディレクトリの企業ページから始まるが、インフラストラクチャテストは AS36231 から始まる。RIPEstat のAS 概要は、保有者を TEMPEST-HOSTING - Tempest Hosting, LLC と識別し、自律システムが 2026-07-15 のクエリウィンドウでアナウンスされているとマークする。RIPEstat のWHOIS ビューを通じてレンダリングされた ARIN 派生 WHOIS データは、AS 名 TEMPEST、2020年5月の登録日、および tempest.net を指すコメントを提供する。これらの事実だけでは製品を説明するものではないが、販売用語とは独立して測定可能な番号付きルーティング境界を確立する。

その境界は空ではない。RIPEstat のアナウンス済みプレフィックスビューは、ここで使用したスナップショットで 40 のプレフィックスタイムラインエントリを返した。そのルーティングステータスビューは、それを 19 の IPv4 プレフィックス、4,864 の IPv4 アドレス、20 の IPv6 プレフィックス、65,538 の可視 /48 相当 IPv6 ユニットに分割し、326 の IPv4 RIS ピアのうち 326、322 の IPv6 RIS ピアのうち 322 から完全な可視性を示した。RIPEstat のネイバービューは、4 つの左側関係と 1 つの右側関係を含む 5 つの観測されたネイバーを示した。104.152.143.0/24 の代表的な RPKI チェックは、有効なルートオリジン結果を返した。総合すると、これらの記録は Tempest がアクティブなパブリックルーティングエッジを持つことを示している。各エッジの背後にどれだけの顧客がいるか、どのサービスがプロバイダー割り当てアドレスを使用するか、プレフィックス数がサーバー在庫にきれいにマッピングされるかは示していない。

相互接続記録が次の層を提供する。PeeringDB はTempest Hosting, LLCを AS36231 としてリストし、ウェブサイトhttps://tempest.net、IRR セット AS-TEMPEST、タイプ Content、グローバルスコープ、バランス比率、オープンピアリングポリシー、1-5 Tbps のトラフィック帯域を挙げている。PeeringDB のネットワーク APIはプロファイル内に 26 の IPv4 プレフィックスと 30 の IPv6 プレフィックスを返し、施設 APIは 8 つの施設をリストした: Telehouse London Docklands North、NTT Frankfurt 1、Iron Mountain Amsterdam AMS-1、CoreSite Miami MI1、Equinix SY3 Sydney、ColoCrossing CHI1、IP House London、365 Data Centers Richardson TX1。対応する交換接続 APIは、その PeeringDB ネットワークオブジェクトに対してゼロのパブリック IX LAN エントリを返した。この組み合わせは示唆的である: Tempest はマルチ施設フットプリントを提示するが、公開リストされた相互接続面は交換ポートが多いというより施設に重い。

購入者にとって、この区別は重要である。施設エントリは、ルーター、サーバーキャビネット、トランスポートハンドオフ、顧客向けサービスノード、または保留中のプレゼンスを意味し得る。PeeringDB のトラフィック帯域は自己申告であり、意図的に粗い。プレフィックス数には、管理、エニーキャスト、ゲームサーバー、顧客、予約スペースが含まれ得る。正しい質問は「Tempest にはグローバルインフラがあるか」ではない。公開証拠はそれを支持する。正しい質問は「どの物理的および契約的部分が、支払われたサーバーを顧客が購入している正確な市場で使用可能で復元可能な容量に変えるのか」である。

可視フットプリントはグローバルだが、運用面はローカルである

Tempest 自身のステータスページは異常に具体的である。現在のステータスページは、2026-07-15 にロンドン、フランクフルト、アムステルダム、シカゴ、マイアミ、ダラス、シドニーを運用中と表示し、ヨーロッパ、北米、オセアニアにわたってグループ化されていた。また、30日間の稼働率も表示: ロンドン、シカゴ、マイアミ、シドニーが 100.0%、ダラスが 99.4%、フランクフルトが 97.4%、アムステルダムが 84.6%。これらは正式な監査済み可用性数値ではなく、そのページに表示されているプラットフォームコンポーネントのみをカバーする。それでも、サービスの地理を一般的なホスティングブランドよりも具体的にする。

Tempest のルッキンググラスは、第二の具体的なポイントを追加する。これはポイントオブプレゼンスからのライブ診断を公開し、キャプチャされたページでは、テスト IPv4 104.152.143.215 とデータセンター Equinix DA1 を持つダラスのテストロケーションをリストしていた。また、100 MB、1 GB、5 GB、10 GB のテストファイルも公開していた。ルッキンググラスの証拠は、外部測定を促すため有用であるが、狭い: テストファイルは、1 つの診断エンドポイントが存在し、ユーザーがテストする場所から到達可能であることを証明する。それは、顧客の全資産が同じ施設にあること、すべての製品が同じキャリアパスを持つこと、または別の都市で注文されたサーバーがダラスの診断ルートを継承することを証明するものではない。

PeeringDB の施設リストは、ルッキンググラスよりも地理を広くする。Telehouse London Docklands North はキャリア密度の高いロンドンサイトである。NTT のフランクフルト 1 データセンターは、NTT によって70.1 MW のクリティカル IT 負荷と DE-CIX アクセスを持つ大規模キャンパスとして提示されている。Iron Mountain のアムステルダム AMS-1は、現在の電力と計画拡張を備えたハールレムキャンパスとして説明されている。CoreSite のマイアミ MI1は、MI2 にライトファイバーで接続された専用のマイアミ施設である。Tempest ページ自体は、シドニー、シカゴ、ダラスを運用拠点としてリストしている。これらの施設の事実は、電力、冷却、ミートミールーム、クロスコネクト、ローカルアクセスの制約がサービスのどこに影響するかを説明するのに役立つ。しかし、Tempest の正確なケージサイズ、予約電力、キャビネット密度、または任意のサイトでのリモートハンド契約を証明するものではない。

これが繰り返し発生する容量問題である。インストール済み容量は、ネットワークまたは施設が理論的にサポートできるものである。使用可能容量は、アップストリーム、ラック、電力、サポート、またはハードウェア在庫の制約に違反することなく販売、電力供給、冷却、パッチ、監視、請求、回復できるものである。グローバルな PeeringDB スコープと 8 つの施設エントリは、プロバイダーをシングルサイトホストよりも回復力のあるものにするかもしれない。また、顧客がサイト固有の質問をしなければならない場所を増やす。どの都市がプライマリサーバーをホストしているか？どの都市がバックアップをホストしているか？移行はコールド、ウォーム、または自動か？パブリック IP は Tempest の拠点間でポータブルか？ダラスのアップストリームキャリアが障害を起こした場合、トラフィックは別のダラスパス、別の北米都市、またはセッション影響を伴う一時的な再ルートに移動するか？

ロンドンの移行は、回復力が実際に何を要するかを示す

Tempest の物理的依存関係の最も明確な公開例は、完了したロンドンネットワークアップグレードである。Tempest は、Telehouse London データセンターキャンパスへの拡張と、そこへのコアルーティングインフラの移行を計画していると述べた。また、この作業には、既存のエッジルーターからの BGP アナウンスの引き上げ、新しい Telehouse ルーターのオンライン化、IP アドレス空間のアナウンス、およびアップストリームプロバイダーとピアにわたるルーティングの検証が必要であると述べた。顧客には、ルーティングが伝播しテストが実行される間、接続低下、パケットロス、および短時間の中断が発生する可能性があると警告された。

このメンテナンス通知は、依存関係グラフの隠れた部分を示すため、通常の稼働時間メッセージよりも重要である。可視の製品は、専用サーバー、仮想専用サーバー、ゲームサーバー、またはコロケーションサービスかもしれない。しかし、重要な変更は、キャリアニュートラルキャンパスでのルーター移動である。障害モードは「サーバーがダウンする」だけではない。「インターネットの残りがサーバーに到達する経路が意図的に引き上げられ、再アナウンスされ、検証される」である。CPU、RAM、月間帯域幅だけを尋ねる購入者は、実際にワークロードを到達可能にする経路を見逃している。

同じ通知は、冗長性の主張と冗長性の証明の違いも説明している。Tempest は、改善された回復力、より強固な接続性、低レイテンシ、および将来の成長のためのより良い基盤などの利点を説明した。これらは Telehouse プレゼンスの妥当な利点であり、特にロンドン ドックランズは欧州の主要な相互接続ゾーンの一つである。しかし、メンテナンス通知は、顧客が障害時の挙動を確認できるまでは仮説に過ぎない。ロンドンサイトには複数のアップストリームがあるか？ルートポリシーは変更ウィンドウの前にテストされているか？手動検証と自動フェイルオーバーのバランスは？カスタマーサポートはどのプレフィックスまたは製品が影響を受けるか把握しているか？古いエッジが引き上げられた後に新しいルーターが障害を起こした場合の復旧目標は何か？

答えは優秀かもしれないが、公開記録はそのすべてを開示していない。しかし公開記録は、漠然としたマーケティングよりも顧客を良い立場に置く。顧客はBGP.toolsで AS36231 を追跡し、公開ルート変更を RIPEstat のルーティングステータスと比較し、主要メンテナンスウィンドウの前後でプレフィックスセットやネイバーセットが変化するかを監視できる。これらのテストは契約の代替にはならないが、プロバイダーが移行によって回復力が向上すると主張する場合に独立した証拠を生み出す。

ダラスはラック、キャビネット、アップストリーム層を露出する

完了したダラスの計画ネットワークアップグレードは、BGP だけではないという点で第二の有用な記録である。Tempest は、新しいルーティング機器を追加し、新しい機器をラックに収容できるようにキャビネットスペースを集約すると述べた。一部の顧客のマシンは電源が切られ、他のラック場所に移動され、エンタープライズ専用顧客は少なくとも3時間、バジェットまたはブレードサーバーは少なくとも5時間の停止が見込まれると予想された。ウィンドウ中、顧客はチームがキャビネット内またはその周辺で作業している間、定期的なネットワークドロップも経験する可能性があった。

これは、ホスティング容量が建物の上に浮かぶソフトウェアではないことを示す最も具体的な公開リマインダーである。それはキャビネットにボルトで固定され、トップオブラックまたは集約機器に配線され、施設供給によって電力供給され、部屋設計によって冷却され、物理的アクセスを持つ人々によって扱われる。スペースの集約はインフラ行為である。それは、プロバイダーが成長、ハードウェア交換、またはネットワークアップグレードのためのスペースを確保するためにキャビネットレイアウトを変更していることを意味する。将来の容量を改善できるが、サービスがマシンの移動、ケーブル規律、電源シーケンス、ラベリング、および移動後の検証に依存する短期間の障害経路を生み出す。

ダラスのルーティングインシデントはキャリア層を追加する。Tempest は、ダラスネットワークのルーティング問題を特定し、障害がそのキャリアのネットワーク内にあったためアップストリームキャリアに関与し、サービスをオンラインに戻すために一時的にトラフィックを再ルートし、後に通常の接続経路にトラフィックを戻したと述べた。更新では、一部のプレイヤーが移行中に短時間の切断を経験した可能性があることも指摘した。この表現は、レイテンシとセッション継続性を気にする顧客グループ、つまりゲームサーバーユーザーまたは他のリアルタイムワークロードを指している。彼らにとって、「サーバーが電源オン状態を維持した」だけでは不十分であり、ルートがセッションをリセットしたり、レイテンシをユーザーエクスペリエンスを変えるパスにシフトさせたりする場合がある。

したがって、ダラスは2つの異なるリスクを示している。計画リスクはキャビネットと機器の変更であり、顧客はメンテナンスウィンドウを知ってダウンタイムに備えることができる。計画外リスクはアップストリーム障害であり、プロバイダーは所有権を診断し、キャリアに関与し、トラフィックを再ルートし、後で顧客影響を悪化させることなく通常ルーティングを復元しなければならない。両方とも回復可能であり、両方とも顧客に可視的である。深刻な購入者は、両方に対応するエスカレーションパス（緊急再ルートを承認できる者、施設に入ることができる者、マシン移設を担当する者、プロバイダーが広範な都市レベルのステータスではなく製品固有の影響をどれだけ迅速に伝達できるか）を尋ねるべきである。

アムステルダムはスペアパーツの教訓である

Tempest のアムステルダム停止は記録の中で最も厳しい公開証拠である。なぜなら、それは非常に具体的な制約を名指ししているからである。インシデントはアムステルダムに影響し、停止調査として始まり、後にコアスイッチ障害と特定された。Tempest は、アムステルダムはまだスペアを発送する機会がなかったサイトであり、代替品を調達するために地元ベンダーに関与していると述べた。接続は後に復旧され監視された。

この開示は運用上価値がある。それは漠然とした「ハードウェア障害」というフレーズを、コアスイッチ、サイトにまだ存在しないスペア、および地元ベンダー調達という実行可能な依存関係に変える。アムステルダムに本番環境を置くかどうかを決定する顧客にとって、教訓は単にプロバイダーに停止があったということではない。停止は起こる。教訓は、マルチサイトフットプリントでもサイトごとの成熟度の違いが存在するということである。サイトはリストされ、アナウンスされ、運用中であっても、そのスペアプールはより確立された場所よりも不完全であり得る。プロバイダーはサービスを復旧できるが、復旧経路は棚にある交換品ではなく地元調達に依存する可能性がある。

ここで、インストール済み容量と使用可能容量が回復力の問題になる。キャビネットにスペースがある。施設に電力がある。プレフィックスがアナウンスされている。これらの事実はいずれも、スイッチ障害後に必要な交換部品が正しい都市に既にあることを保証しない。使用可能容量には、サービスが障害を乗り切るための退屈な在庫（スペアスイッチ、オプティクス、電源、ディスク、ケーブル、互換ルーターカード）が含まれる。これにはリモートハンド権、ベンダー納品ウィンドウ、および国境を越えて迅速に発送する能力が含まれる。アムステルダムでは、Tempest 自身の公開インシデント文言は、その時点でスペア配置が完了していなかったことを示している。

それはアムステルダムサイトを使用不可にするものではない。それはデューデリジェンスの質問をより鋭くする。購入者は、不足していたスペアが一度きりの初期段階の問題だったのか、サイトに現在在庫された交換品があるのか、他の新しい都市にも同様のギャップがあるのかを尋ねることができる。購入者はまた、サービスが都市ごとにどのように分割されているかも尋ねることができる。アムステルダムノードが障害を起こした場合、顧客はアプリケーションアーキテクチャを変更せずにロンドン、フランクフルト、または他の Tempest リージョンに移動できるか？バックアップは既にサイト外にあるか？IP アドレスはポータブルか、それともデータのみか？顧客はスナップショットから復元できるか？できる場合、都市全体に障害が発生したときのキューはどのくらい長くなるか？

ステータスページが稼働時間をエンジニアリング証拠に変える

Tempest のステータス記録は、可用性をブランド約束ではなく日付付きの運用履歴に変えるため価値がある。ステータスページは、単に企業にグローバル拠点があると言うだけではなかった。ロンドン、フランクフルト、アムステルダム、シカゴ、マイアミ、ダラス、シドニーに別々のサービスエリアを表示し、ここでレビューした時点でそれらの間で非常に異なる30日間の数値を示していた。ロンドン、シカゴ、マイアミ、シドニーは 100.0% を示した。ダラスは 99.4% を示した。フランクフルトは 97.4% を示した。アムステルダムは 84.6% を示した。これらの数値は監査済みサービスレベルパフォーマンスとして扱われるべきではない。なぜなら、公開ステータスページはプロバイダーによって維持され、独自の監視コンポーネントを定義するからである。それでも、フットプリントが単一のスムーズなクラウドとして読まれるのを防ぐため、有用である。各都市には独自のメンテナンス履歴、障害履歴、復旧挙動がある。

これは特に拠点を比較する購入者にとって重要である。プロバイダーに7つの都市がある場合、顧客は都市が交換可能であると想定するかもしれない。Tempest の公開記録はその想定に反論する。アムステルダムの30日間の数値は、開示されたコアスイッチ障害と交換調達問題によって低下した。ダラスは計画されたキャビネット/ルーティング機器アップグレードとアップストリームキャリアインシデントの両方を抱えていた。フランクフルトは IP 問題を抱えていた。ロンドンは Telehouse キャンパスへの計画されたコアルーター移行を抱えていた。シドニー、マイアミ、シカゴは同じステータスウィンドウで静かだったが、公開の静けさは同一のスペア在庫、同一のアップストリームトポロジ、または同一の製品可用性の証明ではない。それは、レビューされた公開ステータス記録がそれらの場所に対して同じ混乱を示していなかったことを意味する。

ステータス履歴はまた、計画リスクと計画外リスクを分離する。計画メンテナンスは単なる事前通知のあるダウンタイムではない。それはサービスの背後でどれだけの物理的変更が行われているかの指標である。ロンドンの通知は、ルート引き上げ、ルーター起動、アップストリーム検証を示している。ダラスの計画アップグレードは、マシン移動、キャビネット集約、新しいルーティング機器を示している。これらは投資の兆候であるが、使用可能容量が時としてサービス中断を必要とする兆候でもある。プロバイダーはルーター、ケーブル、キャビネット、マシンに触れることによってのみ容量を拡張できる。したがって、顧客は拡張作業が都市ごとにスケジュールされているか、メンテナンスがすべての製品または特定の製品ファミリーに影響するか、通知が計画を立てるのに十分な精度で IP 範囲または顧客グループを特定しているかを尋ねるべきである。

計画外インシデントはシステムの異なる部分をテストする。ダラスのキャリア障害では、Tempest はアップストリームプロバイダーに関与し、トラフィックを再ルートする必要があった。アムステルダムの障害では、地元交換品の調達が必要だった。両方のケースで、顧客体験は Tempest が責任層を特定し、正しい復旧経路に移動する速さに依存していた。ラック電力障害、コアスイッチ障害、アップストリームルーティング障害はすべて顧客には「サーバーに到達できない」ように見えるかもしれない。それらには異なる対応者が必要である。プロバイダーは、リモートハンドを派遣するか、キャリアチケットを開くか、BGP ポリシーを変更するか、ハードウェアを交換するか、顧客に他の場所で復元するよう指示するかを知らなければならない。

そのため、ステータスの文言は有用なデューデリジェンスオブジェクトになる。顧客は、将来のインシデントが場所、製品ファミリー、層、回避策、最終復旧を特定しているかどうかを確認すべきである。都市レベルの「運用中」マークは良い知らせだが、良いインシデントレポートは多くの場合、緑のバッジよりも有益である。それは、プロバイダーが自身の依存関係スタックを理解しているかどうか、顧客がダウンストリームコミュニケーションに使用できる言語を受け取るかどうかを明らかにする。Tempest の公開通知はいくつかのケースで具体的な層を名指ししており、分析を強化している。残りのギャップは顧客固有である。公開ステータスページは、個々の購入者に対して、その正確なサーバー、アドレスブロック、バックアップ、サポート層が表示されたコンポーネントによってカバーされているかどうかをほとんど伝えない。

フランクフルトとマイアミは、施設の品質がプロバイダーの証明ではない理由を示す

フランクフルトは、公開記録に2種類の異なる証拠があるため有用である。PeeringDB は NTT フランクフルト 1 を Tempest の施設プレゼンスとしてリストし、NTT の施設ページは大規模なキャンパスをキャリアニュートラル接続性、DE-CIX アクセス、冗長キャリアミートミールーム、主要な電力エンベロープを備えて説明している。別途、Tempest のフランクフルトインシデントは、IP 問題がフランクフルト拠点に影響し、後に解決されたと述べている。施設は大きく、よく接続されているかもしれないが、顧客のサービスは依然として Tempest 自身の機器、アドレス計画、アップストリームの選択、およびその施設内またはその周辺でのサポート対応に依存している。

同じ論理がマイアミにも当てはまる。CoreSite の MI1 ページは、ダウンタウンマイアミの専用データセンターで、ライトファイバーで MI2 に接続され、厳しい嵐の条件向けに設計されていると説明している。これは貴重な物理的コンテキストである。なぜマイアミがコンテンツ、ゲーム、または南北アメリカ向けトラフィックに賢明な場所であるかを教えてくれる。また、Tempest の正確なキャビネット割り当て、クロスコネクト、電力消費、顧客移行経路については何も教えてくれない。強い施設は弱いデプロイメントをホストする可能性があり、控えめな施設は注意深くエンジニアリングされたデプロイメントをホストする可能性がある。公開施設ページは物理的エンベロープを設定するものであり、プロバイダーの実行力を設定するものではない。

この区別は、顧客がしばしば建物ではなくブランドを購入するため、特に重要である。Tempest の顧客がダラスでサーバーを注文した場合、彼らは Tempest 製品を購入したと思うかもしれない。運用上、彼らは複合体を購入している: Tempest のハードウェア、Tempest のルーターポリシー、施設運営者の電力とアクセス体制、1つ以上のキャリア、リモートハンドまたは現地スタッフ、サポートキュー、請求システム、移行ルール。何かが壊れたとき、顧客は最も遅い責任ある部分を経験する。公開インシデント記録は、それらの部分が実際のイベントで表面化したことを教えてくれるため、有用である。

実用的なデューデリジェンスのステップは、サービスを層に分割することである。企業層は Tempest Hosting, LLC である。ルーティング層は AS36231 とその観測されたネイバーである。施設層は PeeringDB と Tempest のステータスページに記載された名前のサイトである。製品層は専用、バジェット、ブレード、仮想専用、またはコロケーション容量である。復旧層は、製品と施設層が一致しないときに何が起こるか（コアスイッチ障害、キャリア障害、機器の物理的移動）である。顧客はすべての層で答えを必要とする。なぜなら、障害は見積もりのきれいな境界をめったに尊重しないからである。

ルート多様性は可視的だが、物理的多様性はそうではない

公開ルーティング証拠は、このケースのより良い部分の一つである。RIPEstat は AS36231 のスナップショットで完全な可視性を確認し、CAIDA のAS Rank ページは Tempest Hosting, LLC、米国、小さなカスタマーコーン、限定された AS 次数を識別した。IPinfo のAS36231 ページ、Hurricane Electric のBGP ビュー、および BGP.tools はすべて、ネットワーク ID とプレフィックスの独立したクロスチェックを提供する。これらのサービスのいずれも完全な契約上の真実を見ることはできないが、ネットワークが単に名目的である可能性を減らす。

限界も同様に重要である。RIPEstat のネイバーデータは 5 つの観測されたネイバーを示した。これは有用であるが、公開 BGP 隣接関係は、2つのセッションが同じメトロファイバー、同じ建物ミートミールーム、同じキャリアダクト、または同じアップストリームメンテナンスチームを共有しているかどうかを明らかにしない。1つのネイバーから学習されたルートがすべてのトラフィックに優先されるか、バックアップパスにピーク負荷を処理するのに十分な容量があるか、ゲームサーバーワークロードがパケット配信が戻った後でもレイテンシのシフトに耐えられるかどうかを明らかにしない。ルーティング多様性は必要な手がかりである。物理的経路多様性は別の証明である。

Tempest ネットワークオブジェクトの PeeringDB のゼロ公開交換アタッチメントも注意深い扱いを必要とする。それは Tempest に相互接続がないことを意味するわけではなく、マルチ施設ネットワークと矛盾しない。PeeringDB への参加は任意であり、ネットワーク記録はプライベート相互接続、トランジット、ルートサーバーセッション、または顧客固有の取り決めを省略できる。それが言うことは、公開プロファイルが現在、一部の欧州ネットワークのように豊富な交換ポートリストを提供していないということである。したがって、顧客はトランジットプロバイダー、プライベートピア、バックアップポート、各都市が独立したデフォルト対応パスを持っているかについて直接質問すべきである。

ロンドンとダラスの記録はこれが重要である理由を示している。ロンドン移行中、Tempest はアップストリームとピアを検証しながら BGP ルートを引き上げて再アナウンスする計画を立てた。ダラスのインシデント中、アップストリームキャリアのネットワーク内の障害により一時的な再ルートが強制された。両方のケースで、顧客向けの影響は AS36231 がどこかに可視かどうかだけでなく、その瞬間に影響を受けたサービスをどのパスが処理していたかに依存していた。深刻な回復力レビューには、顧客市場からのトレースルート、ルートオリジン認証のレビュー、プレフィックス監視、キャリア障害中に何が変化するかのプロバイダー説明を含めるべきである。

製品クラスは異なる方法で障害を起こす

公開 Tempest 通知は、異なる顧客クラスを識別するためにも有用である。ダラスの計画アップグレードは、エンタープライズ専用顧客、バジェットまたはブレードサーバー、およびチームがキャビネット周辺で作業中の定期的なネットワークドロップに言及した。ダラスのルーティングインシデントは、短時間の切断を経験した可能性のあるプレイヤーについて言及した。ステータスページ自体は、仮想専用サーバー、専用サーバー、ゲームサーバー、コロケーションを製品カテゴリとして指している。これらのラベルは重要である。なぜなら、同じ施設イベントが製品タイプごとに異なる復旧タスクを生み出す可能性があるからである。

専用サーバー顧客は、マシンを個別の資産として気にする。キャビネットが集約されている場合、彼らは自分のサーバーが電源オフされるか、物理的に移動されるか、再配線されるか、そのまま残されるかを知る必要がある。ディスク、電源、またはマザーボードが障害を起こした場合、互換性のあるスペアが同じ都市にあるか、データが保存できるか、誰が実地作業を承認するかを知る必要がある。ダラスのアップグレード通知は具体的である。なぜなら、一部のマシンが電源オフされて再配置される可能性があることを顧客に伝えているからである。また、プロバイダーの成長計画がソフトウェアプロビジョニングコンポーネントだけでなく物理的レイアウトコンポーネントを持っていることを示唆している。

仮想専用サーバー顧客は異なる依存関係を持つ。彼らは、ホスト、ストレージプール、またはネットワーク集約要素が障害を起こすまで、どの個別シャーシが仮想マシンをホストしているか気にしないかもしれない。彼らの復旧は、ハイパーバイザーの健全性、ストレージレプリケーション、利用可能なスペアホスト容量、バックアップの鮮度、移行ツールに依存する。公開 Tempest 記録は、それらの製品の背後にある仮想化またはストレージアーキテクチャを開示していない。しかし、それは顧客が VDS がホスト間または都市間で移動できるかどうか、バックアップが同一サイトかクロスサイトか、IP アドレスが復旧中にワークロードに追随するかどうかを尋ねるべき理由を示している。

ゲームサーバー顧客は、到達可能性と同じくらいタイミングを気にする。接続を復元する一時的な再ルートでも、レイテンシ、ジッタ、またはセッション継続性を変更する可能性がある。したがって、ダラスのインシデント文言におけるプレイヤー切断の可能性への言及は重要である。それは、技術的にサービスがオンラインに戻った後でも、ネットワーク回避策がユーザー向けの影響を与える可能性があることを認識している。ゲームおよび他のリアルタイムワークロードの場合、顧客はプレイヤーベースがどこにあるか、どの Tempest 都市が使用されているか、通常のレイテンシパスは何か、DDoS およびアップストリームフェイルオーバーパスは何か、ルート変更がプロバイダー自身の監視ポイントからだけでなくプレイヤーの市場からテストされているかを尋ねるべきである。

コロケーション顧客はさらに別のケースである。コロケーションデバイスは、スペース、電力、ネットワーク、リモートハンド、クロスコネクト調整について Tempest に依存する可能性があるが、顧客はサーバーソフトウェアと時にはハードウェアを所有する。アップストリームルートが変更された場合、Tempest が行動する。顧客デバイスが障害を起こした場合、リモートハンドとアクセスポリシーが重要である。施設イベントが発生した場合、両当事者が調整する必要があるかもしれない。PeeringDB の施設リストは、可能性のある物理的会場を名前付けるため有用であるが、会場名だけでは誰が何に触れられるか、どれだけ迅速に、どの承認プロセスの下で定義されない。その境界は停止前に文書化されるべきである。

この製品の区別は、ホスティング容量経済の核心である。同じラック、ルーター、サポートチームが多くの製品ラインにサービスを提供でき、効率を生み出す。また、共有インシデント中に競合を生み出す。コアスイッチ障害、キャリア障害、またはキャビネット移動は、多くの顧客を同じサポートおよび修理キューに送る可能性がある。公開証拠は層が存在することを証明する。キューの容量を証明するものではない。最も安全な顧客の姿勢は、一般的なインフラ記述に依存するのではなく、Tempest に製品固有の復旧文言を求めることである。

同じ区別が監視を形作るべきである。専用サーバー顧客は、電力イベント、インターフェイスカウンター、ディスク健全性、アウトオブバンドアクセスを監視するかもしれない。VDS 顧客は、スナップショット経過時間、ホストメンテナンス通知、ストレージレイテンシを監視するかもしれない。ゲームサーバー顧客は、プレイヤーリージョンのレイテンシとジッタを監視するかもしれない。なぜなら、ダラスのルーティングインシデントは、回復したルートでもセッションを中断できることを示しているからである。コロケーション顧客は、クロスコネクトステータス、キャビネット電力、リモートハンド応答、アップストリームルート変更を監視するかもしれない。AS36231 周辺の公開ツールはその作業の一部にしか役立たない。それらはインターネット向けエッジを示す。顧客自身の復旧前提が実際に購入された製品クラスと一致するかどうかを示さない。

顧客影響は可用性だけでなくワークロードに依存する

Tempest のステータス文言は、いくつかの顧客クラスを示唆している: エンタープライズ専用顧客、バジェットまたはブレードサーバーユーザー、仮想専用サーバーユーザー、コロケーション顧客、ゲームワークロードに接続されたプレイヤー。これらのグループは同じインフライベントを異なる方法で経験する。3時間の計画停電はテストサーバーには許容可能であり、本番データベースには許容できないかもしれない。短時間のルート遷移は静的ウェブサイトには無害であり、ゲームセッションには破壊的かもしれない。コアスイッチ障害はあるテナントにとっては一時的な停止であり、ダウンストリーム顧客を持つリセラーにとっては評判イベントかもしれない。

そのため、影響を受ける当事者は単に「Tempest 顧客」ではない。それにはゲームコミュニティ、専用マシンをメインサーバーとして使用する小規模企業、顧客が Tempest を下流に知らないリセラー、レイテンシのために都市を選んだ開発者、グローバルプロバイダーがサイト間で迅速に移動できると想定した企業が含まれる。また、ルート変更がトラフィックを代替パスに移動させるときのピアやアップストリームも含まれる。停止を見る顧客は、多くの場合、障害を起こした物理的部分から数層離れている。

データローカリティは別の結果を追加する。グローバルサービスエリアは、どの管轄区域がデータを保持するか、どの裁判所プロセスが適用されるか、サポートがローカルに行動できるかを顧客に教えない。ワークロードがアムステルダムにある場合、アカウントが米国またはドバイ向けの商用インターフェースを通じて管理されていても、データとハードウェアはオランダにあるかもしれない。顧客がロンドンまたはダラスに復旧する場合、法的およびレイテンシプロファイルが変更される。公開記録は可能性のあるサイトを識別できるが、特定のワークロードがどこにあるかを証明できるのはプロバイダーの文書と顧客アカウント設定のみである。

したがって、移行は必要になる前にテストされるべきである。顧客は、スナップショットが Tempest の拠点間でポータブルか、パブリックアドレスが保存できるか、クロスリージョンバックアップが含まれているかオプションか、プロバイダーが緊急移転の文書化されたプロセスを持っているかを尋ねるべきである。公開ステータス記録は、Tempest が計画されたネットワーク移動と緊急再ルートを実行できることを示しているが、データ、コンピュート、IP アドレス継続性、またはリージョナルイベント中のサポートキュー容量の顧客レベルの復旧時間を示していない。

容量主張をより強固にするにはどのような証拠が必要か

Tempest は既に最初の証拠ハードルをクリアしている。AS36231 はアクティブであり、プレフィックスセットは可視であり、PeeringDB プロファイルは維持され、ステータスページは拠点とインシデントを名指しし、ルッキンググラスは実際のテストエンドポイントを公開している。より強力な証拠は顧客契約に近い位置にある。どの製品がどの都市で利用可能か、どの施設がどの製品をホストするか、各都市にどのアップストリームが存在するか、ルート多様性がメトロ多様か、新しい場所に現在どのスペアハードウェアが在庫されているかを示すであろう。

プロバイダーはすべての運用詳細をオープンインターネットに公開する必要はない。一部の詳細はセキュリティ上または商業上機密である。しかし、顧客は依然としてプライベートアーキテクチャノート、サポートエスカレーションマトリックス、現在の可用性レポート、自社のサービスクラスに影響するメンテナンスウィンドウのリスト、復旧テストを求めることができる。また、PeeringDB の 1-5 Tbps トラフィック帯域が顧客利用可能な余裕にどのようにマッピングされるかの説明も求めることができる。粗いトラフィック帯域は容量の約束ではない。それはピークまたは平均的な総ネットワーク規模を説明する可能性があり、障害中に1人の顧客が実際に使用できる帯域幅量ではない。

同じことが施設電力にも当てはまる。NTT フランクフルト、Iron Mountain アムステルダム、CoreSite マイアミ、その他の施設運営者は印象的な電力と接続性特性を公開している。Tempest 顧客は依然として、Tempest のコミット電力、冗長性レベル、ラック密度、サイト内のリモートハンド手順を知る必要がある。施設に予備メガワットがあっても、特定のケージに即時のスペースがないか、互換性のある電力ホイップがない可能性がある。施設に多くのキャリアがあっても、顧客の製品が1つのデフォルトルートを使用する可能性がある。データホールが安全でも、バックアップが影響を受けた都市の外になかったため顧客復旧が失敗する可能性がある。

これが購入者の証拠のはしごである。第一に、企業がアクティブなネットワークに結びついていることを証明する。第二に、製品が実際にそのネットワークを使用していることを証明する。第三に、製品の都市、ラック、電力、アップストリーム、サポート依存関係を証明する。第四に、それを実行することによって復旧経路を証明する。Tempest の公開記録は第一歩で強力であり、インシデント開示のおかげで第三歩でも意味がある。それは第二歩と第四歩では、個々の顧客が製品固有の確認を得るまで不完全である。

狭い評決

Tempest Hosting, LLC は、純粋に薄いフットプリントではなく、測定可能な公開ネットワークを持つ現実のインフラ事業者として扱われるべきである。証拠はプライベートホスティングプロバイダーとしては異常に有用である: AS36231 は可視、RIPEstat は現在の IPv4 および IPv6 スペースを示し、PeeringDB はグローバルプロファイル、1-5 Tbps トラフィック帯域、8 つの施設をリストし、ステータスページは複数の運用都市を名指し、インシデント記録はルーター、アップストリームキャリア、キャビネット、スペアハードウェアにおける具体的な障害経路を公開している。これでプロバイダーをインフラとして分析するには十分である。

しかし、広告または暗示されたすべての容量単位を障害下で既に使用可能として扱うには十分ではない。公開資料は、正確なラック数、電力予約、都市別顧客分布、アムステルダム障害後のスペア在庫、または顧客がデータとアドレスを拠点間で移動できるかどうかを決定する契約条件を開示していない。最も重要な教訓は、Tempest の公開記録が到達範囲と摩擦の両方を示していることである。到達範囲はグローバルプレフィックスと施設フットプリントから来る。摩擦は、メンテナンスウィンドウとインシデントがサービスの背後にある手、部品、キャリア、ローカル決定を明らかにする方法から来る。

顧客にとって、実用的テストは述べるのは簡単で満たすのは難しい: Tempest に、購入している正確な製品を都市、施設、アップストリームパス、サポートキュー、スペアプール、移行計画にマッピングするよう依頼すること。次に、その回答を RIPEstat、PeeringDB、BGP.tools、Tempest ステータスページからの公開ルート証拠と比較すること。回答が一貫しており、復旧手順がテストされている場合、Tempest のフットプリントは本格的なワークロードをサポートできる。回答が一般的なままの場合、購入者はサーバーアカウントが依然としてサイト固有のラック、ルーティング変更、ベンダー納品、修理ウィンドウに依存しており、それらは何かが障害を起こしたときにのみ可視化される可能性があると想定すべきである。