Together-Communications-LTD-CLOUD-NETWORK Together Communication LTD はラック、経路、修理窓口に依存したホスティング容量を販売する

概況

• Together Communication は、Together Cloud、共有ホスティング、VPS、専用サーバーホスティング、コロケーション、固定アドレス、保護サービスを公的に販売している。顧客の機器を同社のデータセンターに設置できるとしているが、その提供の裏付けとなる拠点、電源設計、ラック在庫、ストレージアーキテクチャ、復旧目標、標準サービスレベルを公開していない。
• AS34008 は正確な登録名Together-Communications-LTD-CLOUD-NETWORKを持ち、Together Communication LTD の RIPE 組織に属している。RIPEstat は 2026年7月12日時点でこれを未アナウンスとし、現在のプレフィックスや観測された隣接を持つものはない。最後に広く観測された経路は 2019年1月15日に発信された。
• 同じ登録組織は、別のアクティブなネットワークである AS42013 も保有している。RIPEstat は 13 の IPv4 プレフィックス、1 つの IPv6 プレフィックス、5,120 の IPv4 アドレス、報告ピア間での完全な可視性、および 4 つの現在の隣接を観測した。これは Together が稼働中の地域ネットワークを運営している強力な証拠だが、すべての Together Cloud ワークロードが AS42013 上で、あるいは特定の施設内で稼働していることを証明するものではない。
• PeeringDB と Palestine Internet Exchange は、AS42013 がラマッラの MTIT Building 01 にある PSIX に 1 Gbps ポートで接続されていることを示している。公開経路観測は、AS8551 および AS1680 経由のパスも示している。これらの事実は稼働中の接続性を支持するが、多様なデータセンターサイト、物理的に分離されたファイバー入口、あるいはホスティング顧客にとって十分なフェイルオーバー容量を確立するものではない。
• Together Communication 全体のネットワーク運用証拠は中程度である。割り当てられた AS34008 クラウドネットワーク面の証拠は否定的であり、顧客向けクラウドの回復力に対する信頼性は弱い。購入者は、単に到達可能ではなく回復可能なサービスとして扱う前に、施設の場所の明示、資産所有権、電源とキャリアの分離、テスト済みリストア、サポートエスカレーション、エクスポート条件を必要とする。

提供内容は具体的だが、障害ドメインはそうではない

Together Communication のビジネスサービスページは、企業に購入させたい製品について異常なほど直接的である。そこには Together Cloud、共有ホスティング、仮想プライベートサーバー、専用サーバー、コロケーション、固定 IP アドレス、保護サービス、通信システム、SMS 接続が列挙されている。共有ホスティングは DirectAdmin と共に提示され、クラウドの説明には "NOD Controllers" および "VM NSX" という名称が使われている。コロケーションの提案では、顧客は自社の機器を同社のデータセンター内に設置するためのスペースを借り、高速接続とパブリックアドレスを受け取ることができるとしている。

これは実際のインフラ提案を特定するのに十分である。デジタルトランスフォーメーションを約束するだけの一般的なコンサルティングページではない。共有ホスティングにはウェブおよびメールソフトウェア、ストレージ、ネームサービス、証明書、アカウント管理が必要である。VPS には仮想化ホスト、メモリ、CPU スケジューリング、ネットワークインターフェース、永続ディスクが必要である。専用サーバーには物理シャーシと、コンポーネント障害時の交換経路が必要である。コロケーションにはラックユニット、配電、冷却、アクセス制御、クロスコネクト、顧客のマシンに触れる権限を持つスタッフが必要である。固定アドレスにはアドレス管理と継続的な経路可用性が必要である。

そのページは、これらの製品の背後にある物理的な構造を開示していない。複数形で "データセンター" と記しているが、名称は挙げていない。施設が自社所有か賃貸か、あるいは他の事業者から提供されたものかは述べていない。ラック、給電、発電機、バッテリー、キャリアの引込み口、利用可能なサーバー在庫の数は公表されていない。プライマリサイトとリカバリサイトの区別も示されていない。また、"信頼できる" を測定可能な可用性目標、応答時間、救済策に変える、公開されたサービスレベルスケジュールも存在しない。

このギャップは、サービスが失敗しているという評決ではない。サービスをボトムアップで評価しなければならない理由である。顧客はクラウドという言葉を指差しても、クラウド停止から復旧できない。復旧には、生き残ったデータのコピー、互換性のある計算リソース、到達可能な経路、機能する認証情報、十分な予備容量、そして変更を実施できるスタッフが必要である。Together はこれらの能力を備えているかもしれない。公開ページはそれを実証していない。

この区別は、地域プロバイダにとって特に重要である。地元の事業者は、アラビア語サポート、近隣のエンジニア、地元の商習慣、短いエスカレーションパス、ワークロードをユーザーの近くに維持できる可能性といった貴重な利点を提供できる。これらの強みは、遠隔のハイパースケールサービスの長いカタログよりも、パレスチナの中小企業にとって有用であり得る。しかし、近接性は、プライマリプラットフォーム、バックアップコピー、トランジットハンドオフ、サポートチームが同じ都市、同じ建物、あるいは同じプロバイダ契約を共有している場合、リスクを集中させることにもなる。

2つの ASN が異なる運用面を描く

最も明らかな公開証拠は、一見矛盾するところから始まる。割り当てられた企業名にはCLOUD-NETWORKが含まれており、AS34008 の登録記録は、その正確な名前を Together Communication LTD に結びつけている。その記録は、企業組織をORG-TCL42-RIPEとし、国をパレスチナとして、ASN が 2015年5月から割り当てられたことを示している。しかし、同じページでは IPv4 および IPv6 のルートがゼロと報告されている。

RIPEstat はより正確な現在の状況を提供している。そのAS34008 概要は、2026年7月12日時点でネットワークがアナウンスされていないとした。アナウンスプレフィックス表示は、過去2週間のプレフィックスを返さなかった。ルーティングステータス表示は、アナウンスされたアドレス空間、観測された隣接ネットワーク、報告する IPv4 または IPv6 ピアからの可視性がないことを示した。最後に広く観測された経路は 2019年1月15日の 185.99.44.0/22 であった。

過去のデータは、AS34008 がかつて運用上有意味であったことを示している。RIPEstat の長期プレフィックス履歴は、2015年5月から2019年1月にかけて Together 関連のプレフィックスが出現していたことを記録している。これらには 185.99.44.0/22 の一部、およびある期間の 185.61.20.0/22 が含まれていた。したがって、この記録は、単に予約されて一度も使用されなかった ASN ではなく、退役したか休眠中のルーティング面のように見える。

AS34008 の登録ルーティングポリシーは、いくつかの意図された接続先も指定している。AS42013 を含むパレスチナおよびイスラエルのネットワークに関するインポートおよびエクスポート文が含まれている。これらの文はライブセッションではなく、ポリシーオブジェクトを記述している。最終的に実質的な更新が行われたのは公開の何年も前であり、可視経路が存在しないことと矛盾する。購入者は、現在の経路観測または事業者テストによって確認されるまで、リストされたポリシーを利用可能なパスと見なすべきではない。

Together は別の ASN も保有している。RIPE メンバーシップエントリは、ラマッラに所在する Together Communication LTD を挙げ、サービスエリアとしてパレスチナを記載している。同じ組織ハンドルが AS42013 に現れており、これはより簡潔な名前Together-Communication-LTDで登録されている。7月12日、RIPEstat のAS42013 概要は、そのネットワークがアナウンスされているとした。

対照は鮮明である。AS34008 には現在の経路がなかった。AS42013 のルーティングステータスは、5,120 アドレスをカバーする 13 の IPv4 プレフィックス、1 つの IPv6 プレフィックス、および計測時点で報告するすべての IPv4 および IPv6 RIPE RIS ピアからの可視性を示した。そのアナウンスプレフィックスリストには、2.58.132.0/22、185.61.20.0/22、185.99.44.0/22、185.209.108.0/22、91.229.247.0/24、194.5.235.0/24、212.47.82.0/23、2a0b:4d40::/29 と、より詳細な経路が含まれていた。

これは Together Communication が稼働中のネットワークを運営している強力な証拠である。しかし、2つの ASN の区別を消し去る許可にはならない。ASN は製品、ルーティングポリシー、時代、または管理機能を分離することができる。かつて AS34008 が発信していたアドレス空間は、後にすべてのサーバーが移動することなく AS42013 を通じて発信される可能性がある。クラウドブランドは、公開記録に古い ASN 名を保持したまま、アクティブなネットワークを使用できる。サードパーティのインフラに依存することもできる。公開 BGP 観測では、これらの説明の中から選択することはできない。

正しい結論は限定的である。割り当てられたエンティティの背後にある組織は、別の ASN を通じて依然として可視的に活動している一方、正確な AS34008 面はグローバルルーティングテーブルにおいて休眠状態にある。顧客は Together に対し、現在どの ASN が Together Cloud を担っているか、どのプレフィックスにホストされたワークロードが含まれているか、AS34008 が将来の使用、レガシー管理、または別の目的で保持されているのかを尋ねるべきである。明確な回答は、ルーティングデータだけでは解決できない曖昧さを解消するだろう。

稼働中の企業ウェブサイトは運用シグナルであり、クラウド監査ではない

Together の公開ドメインはもう一つの証拠を追加する。公開時点で、together.psは 185.209.108.171 に解決され、together-pal.comは 185.209.108.18 に解決された。両方のアドレスは AS42013 が発信するブロックの一つである 185.209.108.0/22 内にある。したがって、公開ウェブサイトは Together がルーティングするアドレス空間を使用している。これはアクティブなネットワークが少なくとも1つの企業サービスを担っている直接的な兆候である。

このシグナルには限界がある。ウェブサイトのアドレスは、顧客の VPS インスタンスが同じプラットフォームを使用しているかどうかを明らかにしない。ウェブサーバーが物理的か仮想的か、Together のラックかサプライヤーのラックか、あるいはサイトにレプリカがあるかどうかを示さない。有料ホスティング顧客の数やそのバックアップの状態についても何も語らない。これは公開エンドポイントの到達可能性を証明するものであり、商用クラウドの設計を証明するものではない。

ウェブサイトは、小さな運用詳細がなぜ重要なのかも示した。7月12日、その HTTPS エンドポイントは、*.together.ps用のワイルドカード証明書を提示したが、その記載有効期限は 2026年6月24日で終了していた。証明書がもはや有効でないため、標準的なクライアントは接続を拒否した。ただし、証明書チェックをバイパスすると、ウェブサーバーは依然としてサイトを返した。これは時限的な観測であり、いつでも修正可能である。プラットフォーム全体に対する判断に拡大解釈すべきではない。

それでも無関係ではない。証明書の更新は、控えめだが実際の信頼性タスクである。期限切れの証明書は、稼働中のサービスをユーザーや自動化クライアントから利用不可に見せることがある。支払いページ、管理ポータル、監視コールバック、ソフトウェア統合を中断させる可能性がある。この事象はラックの故障やファイバー切断を必要とせず、定期的な保守義務における所有権のギャップを必要とする。

ホスティング購入者にとって、実際的な問題は、一つの公開証明書が期限切れになったかどうかではない。顧客サービス全体で、有効期限、ドメイン更新、ネームサービス、アプリケーションシークレットがどのように監視されているかである。警告は一人のメールボックスではなく、有人のキューに送信されているか？別のエンジニアが証明書を更新できるか？インシデント発生時に認証情報は利用可能か？サービスはそのコミットメントにおいて、インフラの可用性とアプリケーションの可用性を区別しているか？ラックに電力が供給され、経路が健全であっても、顧客が依然として安全な接続を完了できないことがある。

ラマッラは可視だが、クラウドの物理的配置は不可視

複数の情報源が Together の運営拠点としてラマッラを指している。RIPE はラマッラの Neleen Main Street を挙げている。Together のお問い合わせページはラマッラの Al-Ramouni Building を記載している。その会社沿革によれば、事業はラマッラ西部の村々にサービスを提供するイニシアチブとして始まり、Al-Midya を主要ハブとして使用し、その後さらに多くの地域に光ファイバーと無線カバレッジを拡大したとしている。

最も明確な独立した施設の関連付けは、AS42013 のエクスチェンジ接続に属する。PeeringDBは、Together が PSIX（Palestine Internet Exchange）に 1 Gbps ポートで接続しており、IPv4 アドレス 185.153.162.4、IPv6 アドレス 2a07:8780:ffff:1::4 を使用していると記載している。その接続はラマッラの MTIT Building 01 に設置されているとしている。PSIX メンバーリストも、AS42013 と同一のエクスチェンジアドレス、1 Gbps 容量を独立して示している。

これは、名前付きの相互接続地点におけるネットワークプレゼンスを確立する。しかし、Together の顧客サーバーがその建物内にあることを確立するものではない。エクスチェンジポートは、施設内の機器から直接、または別のサイトからのトランスポートを通じて到達可能である。ネットワークは、ある建物でピアリングしながら、別の場所でコンピュートをホストすることができる。逆に、企業はルーティングとコンピュートの両方を同じ施設に配置することも可能である。公開記録は、どの配置が適用されるかを述べていない。

この区別が重要なのは、場所の名前が障害ドメインマップではないからである。クラウドプラットフォームと PSIX 接続が同じ建物内にあれば、電源、冷却、アクセス、または建物のインシデントがローカルホスティングとローカル相互接続の両方に影響を及ぼす可能性がある。光ファイバーで接続された別々のサイトにある場合、ファイバーパスとトランスポート機器が依存関係となる。バックアップが同じ建物の別の部屋にある場合、ディスク障害に対しては保護するが、サイトの喪失に対しては保護しない。

Internet Society の IXP トラッカーは、2026年5月に PSIX メンバー20社、総メンバー容量 56 Gbps と報告した。これは、孤立した2ネットワーク間リンクではなく、意味のあるローカルエクスチェンジを示している。ローカルピアリングは、適切なトラフィックをパレスチナ国内に留め、それらの宛先における国際トランジットへの依存を減らし、レイテンシを改善することができる。同省も、PSIX をローカルネットワークをより直接的に接続し、国際回線コストを削減する方法と説明している。

エクスチェンジはインターネット全体の緊急代替手段ではない。顧客のウェブサイトは、ローカルでピアリングしないユーザーやサービスへの経路を依然として必要とする。ソフトウェアリポジトリ、リモートバックアップ先、決済プロバイダ、証明書サービス、グローバルな顧客はすべて、上流トランジットを必要とする可能性がある。PSIX はローカルパスを改善できるが、国際接続は依然として別個の依存関係である。

したがって、Together は2つのロケーション質問に別々に答えられるべきである。本番コンピュートとプライマリストレージはどこで稼働しているのか？ルーティングとエクスチェンジハンドオフはどこで実行されているのか？その回答には、プライマリラックだけでなくリカバリーコピーも含めるべきである。その地図なしでは、「ローカルにホスト」という表現は、単一の物理的障害ドメインを隠しながら法的な地理を説明している可能性がある。

トランジットの多様性はルーティング層では可視だが、管路層では不可視

RIPEstat のAS42013 隣接ネットワーク表示は、7月12日に4つの観測された隣接を示した。AS8551 と AS1680 がパスのプロバイダ側に現れ、AS12975 と AS47546 が顧客側に現れた。登録された AS42013 ポリシーも、ルートを受け入れるネットワークとして AS8551 と AS1680 を指定している。これは BGP 層において複数の外部パスが存在することを支持する。

可視化された2つのプロバイダネットワークは、それぞれ Bezeq International と Cellcom Fixed Line Communication によって運営されている。これらの存在が重要なのは、パレスチナのインターネット接続が長年にわたり、地理的および規制上の制約の下で運営されてきたからである。世界銀行のパレスチナデジタル経済評価は、機器輸入、周波数、インフラ展開に影響を与える制限について述べている。これらの状況は、ハードウェアの調達リードタイム、経路オプション、損傷または旧式化した機器の交換速度に影響を与える可能性がある。

2つのプロバイダ ASN が自動的に回復力のあるトランジットを意味するわけではない。それらは同じ管路を通って同じ建物に入る可能性がある。長距離区間を共有することもあり得る。両方のセッションが1台のエッジルーター、1台のスイッチ、または1つの電源系統に終端する可能性もある。1つのパスが通常の需要を吸収できない低容量のバックアップである可能性もある。また、ルーティングポリシーが一方のプロバイダを極めて強く優先するあまり、フェイルオーバーがアウトバウンドでは機能するがインバウンドでは機能しないこともあり得る。

PeeringDB の Together エントリは、ネットワーク全体の自己申告トラフィックレベルを 10-20 Gbps とし、そのトラフィックはバランスが取れているとしている。また、5,000 の IPv4 プレフィックスと 500 の IPv6 プレフィックスを挙げているが、これらの数値は観測されたルーティングとは自然に整合せず、グローバルにアナウンスされたプレフィックスとは異なる意味で使用されているように見える。ページの一般的なネットワーク詳細は2022年に最終更新され、ピアリング情報の一部は2023年に更新された。これらのフィールドは事業者から提供されたプロフィールデータとして扱うべきであり、現在の監査済み容量ではない。

1 Gbps の PSIX ポートはより具体的だが、それは1つのエクスチェンジにおける1つのポートに過ぎない。それだけで 10-20 Gbps を運ぶことはできない。大部分のトラフィックが有料トランジットを使用し、ローカルトラフィックのみが PSIX を使用するのであれば、それは矛盾ではない。これは、容量がパスごとに測定されなければならない理由を示している。総トラフィック帯域は、1つのアップストリーム、ルーター、クロスコネクト、またはエクスチェンジポートが故障したときに何が依然として使用可能かについてほとんど語らない。

信頼できるトランジットレビューでは、各ハンドオフの確約速度と物理速度、通常時およびピーク時の使用率、予想される再収束時間、前回のフェイルオーバー演習の結果を求めるだろう。キャリアが独立した引込み口を使用しているか、建物を超えた先でも独立性が維持されているかを問うだろう。また、顧客トラフィックが中断されたときに、サポートおよび監視が別個の管理パスを通じてプラットフォームに到達できるかも問うだろう。

ルーティングセキュリティも同様に限定して解釈する必要がある。AS42013 のいくつかのプレフィックスには有効な Route Origin Authorisation があり、アクティブな IPv6 経路は広く可視化されている。RPKI 検証は、参加ネットワークが不正な発信元を拒否するのに役立つ。しかし、正しく認可されたルーターが誤ったより詳細な経路を広告することを防ぐことはできないし、電源が切れたエッジをオンラインに保つこともできない。これはルート層における1つの制御であり、サーバー、ストレージ、人員に関する声明ではない。

「容量」には単位、場所、障害条件が必要

Together の会社概要ページは、同社が 30 メガバイトのデータサービスから 100 ギガバイトを超える「データ容量」へと成長したと述べている。この表現は、速度、量、期間内のトラフィック、またはその他のものを意味するのかを特定していない。ページはまた、77 以上のタワー、30 万人以上のユーザー、89 社以上の企業、17 都市でのサービス提供といった主張も表示している。

これらの数字はアクセス事業における野心と規模を示している。ホスト型コンピュートの利用可能な尺度を提供するものではない。VPS 顧客は、利用可能な CPU、メモリ、ストレージパフォーマンス、ネットワークスループットを知る必要がある。コロケーション顧客は、ラックあたりの電力、許容熱負荷、クロスコネクトの可用性、拡張スペースを必要とする。バックアップ顧客は、保持容量、コピー頻度、リストア帯域幅を必要とする。単位と障害条件のない数字では、これらの質問のいずれにも答えられない。

設置容量と利用可能容量は異なる。プラットフォームは 100 の物理コアを持っていても、ホスト、レプリケーション、フェイルオーバーのために一部を予約するかもしれない。ストレージアレイは大きな未フォーマット容量を持っていても、ミラーリング、パリティ、スナップショット、空き容量要件によって相当なスペースを失う。10 Gbps のアップリンクは多くのテナントで共有され、上流の確約容量によって制限されたり、ファイアウォールでボトルネックになったりするかもしれない。第2サイトが存在しても、プライマリサイトを吸収するには予備のコンピュートが少なすぎるかもしれない。

最も有用な容量の数値は、想定し得る最大の障害の後でも提供できるものである。1 台のホストに障害が発生した場合、影響を受けるすべての VPS は、他のワークロードを追い出すことなく別の場所で再起動できるか？ストレージコントローラに障害が発生した場合、生き残ったコントローラが必要な入出力レートを維持できるか？最も混雑する時間帯にトランジットプロバイダが1つ利用不能になった場合、残りのリンクで本番およびレプリケーショントラフィックを運べるか？プライマリサイトが利用不能になった場合、どのサービスが最初に復旧され、どのサービスがハードウェアを待つのか？

ここでホスティングの経済性が物理的なものになる。予備のサーバー、ディスク、電源、光学部品をアイドル状態で維持するにはコストがかかる。フェイルオーバー容量を確保すると平均使用率が低下する。第2サイトは賃料、電力、トランジット、スタッフアクセスを追加する。したがって、多くのプロバイダは、一般的なコンポーネント障害から保護する基本サービスを販売し、より強力な復旧には別途料金を請求する。境界が明示されていれば、これは理にかなっている。顧客が「クラウド」に価格が決して資金提供していないサイトレベルの継続性が含まれると想定すると、危険になる。

Together は、標準的なインスタンスカタログ、オーバーサブスクリプションポリシー、復旧ティアを公表していない。顧客は価格を比較する前にこれらの条件を尋ねるべきである。最も安価な月額 VPS は、交換可能なウェブフロントエンドには適切かもしれない。しかし、会計システム、患者記録、自治体サービス、小売業者の注文履歴の唯一のコピーに自動的に適しているわけではない。

ラックはソフトウェアの約束を修理義務に変える

すべての Together Cloud 製品は、最終的には物理コンポーネントに辿り着く。仮想マシンはプロセッサとメモリ上で動作する。そのディスクはストレージデバイスとコントローラに依存する。ネットワークトラフィックはインターフェースカード、スイッチ、光学部品、ルーターを通過する。それらのデバイスはすべて、電源、冷却、ファームウェアに依存している。仮想化はリソースの割り当て方法を変えるが、ハードウェア障害を排除するものではない。

同社はハードウェアの在庫やスペアポリシーを公開していない。各製品について実務的な疑問が残る。共有ホスティングでは、アカウントを別のサーバーで復旧でき、それにはどのくらいの時間がかかるのか？VPS では、高可用性がマシンを別のホストで自動的に再起動するのか、それとも手動で交換するのか？専用サーバーでは、一致するスペアシャーシがあるのか、それともコンポーネントを注文しなければならないのか？コロケーションでは、Together はネットワーク部品のみを在庫し、サーバーハードウェアについては顧客の責任となるのか？

輸入状況は、これを単なる理論上の調達問題以上のものにしている。世界銀行は、ICT 機器への制限がパレスチナのデジタルインフラに対する制約であると繰り返し指摘してきた。故障したドライブや電源は、承認済みのスペアが棚にあれば短いインシデントで済む。しかし、部品が制約のあるサプライチェーンを通過しなければならない場合、正確なモデルが入手不可能な場合、交換にメンテナンスウィンドウと顧客の承認が必要な場合には、はるかに長い停止となる可能性がある。

スペア在庫も老朽化する。長期間保管されたドライブは、アレイのファームウェアや容量に適合しないかもしれない。交換用マザーボードは、異なるプロセッサリビジョンを必要とするかもしれない。機械的には適合する光学部品でも、スイッチに受け入れられないことがある。したがって、優れた事業者は互換性を追跡し、在庫をテストし、機器のサポートが困難になる前にライフサイクル交換を計画する。

リモートハンズはラックの人間的な半分である。誰かが正しいシャーシを特定し、アクセスルールに従い、隣接するテナントを妨害せずにケーブルを移動し、変更を記録しなければならない。小規模な地域オペレーションでは、少数の経験豊富なエンジニアがその知識の多くを保持しているかもしれない。ラックマップ、ラベル、コンソールアクセス、変更記録があれば、別の権限者が安全に行動できる場合、サービスはより強固になる。

Uptime Institute の2024 年障害分析では、電力が重大および深刻なデータセンター障害の最も一般的な原因であり続けている一方、ネットワーク問題が IT サービス障害の最大の単一要因であることが判明した。また、多くの深刻なインシデントは、より良い管理、手順、構成によって防止できたと報告している。これらの世界的な調査結果は Together を特別に説明するものではない。これらは、ホスティングレビューが機器の台数と共に保守と人をカバーしなければならない理由を示している。

電源冗長性は、単なるユーティリティの中断だけでなく、メンテナンスを乗り越えなければならない

Together の公開ページは、ユーティリティフィード、無停電電源装置、バッテリー、発電機、燃料について記述していない。記述がないからといって、これらのシステムが存在しないことを意味するわけではない。顧客は、サービスがどの電源イベントを乗り越えるよう設計されているかを知ることができない。

単一の UPS は短時間の中断を橋渡しできるが、依然として単一障害点となり得る。2 台の UPS は、それぞれが必要な負荷を担うことができ、下流の配電が分離されたままである場合にのみ役立つ。発電機は、起動し、使用可能な燃料があり、地域の条件下で給油でき、故障した開閉装置の経路を共有しない場合にのみ、より長い自立運転を提供する。サーバー内の二重化電源は、両方が1つの分配ユニットに接続されている場合はほとんど役に立たない。

メンテナンスこそが実態を明らかにする条件である。UPS、発電機、ブレーカーパネル、冷却ユニットを、顧客ラックを停止させることなくサービスから外せるか？メンテナンスは告知され、顧客は冗長性が一時的に低下するかどうかを知っているか？バッテリーの負荷テストは行われているか？発電機は無負荷での起動だけでなく、実際の施設負荷を担ったことがあるか？

冷却も同じ構造を持つ。部屋に複数の空調ユニットがあっても、1台が停止した後の容量が不十分な場合がある。エアフローの経路が塞がると、室温が許容範囲に見えても1つのラックが過熱することがある。高密度のコンピュートやストレージは、旧式の部屋の設計想定を超えることがある。温度および湿度のアラームには、営業時間外でも機能する応答経路が必要である。

コロケーション顧客にとって、電力の境界は注文書に明記されるべきである。プロバイダは施設の供給と分配を管理し、顧客は機器の電源とラック内レイアウトを管理する可能性がある。契約には、提供される電力、許容ピーク、冗長性レベル、メンテナンス通知、救済策を明記すべきである。これらの詳細がなければ、「ラックスペース」はラックがオンラインを維持し続けるかどうかを最も決定づけるリソースを隠蔽してしまう。

バックアップはワークロードが復旧されるまでリカバリーではない

Together の公開ビジネスページはストレージとホスティングについて説明しているが、バックアップ設計を公開していない。VPS にスナップショットが含まれるかどうか、共有ホスティングアカウントがオフサイトコピーを受け取るかどうか、コピーがどのくらい保持されるか、バックアップが不変かどうか、顧客がリストアをどのように要求するかについて述べていない。公開された復旧時点目標や復旧時間目標は存在しない。

この省略は、すべてのサービスの解釈に影響を与える。同じアレイ上のスナップショットは誤った変更を元に戻すのに役立つが、アレイと共に消える可能性がある。レプリケーションは2つ目のコピーを最新に保つことができるが、削除、破損、ランサムウェアも複製し得る。オフサイトバックアップは、2つ目の場所が独立しており到達可能である場合にのみ、プライマリ施設の損失から保護する。顧客保持のコピーはプロバイダ離脱時の回復力を向上させるが、暗号化、鍵管理、定期的なテストを必要とする。

CISA のランサムウェアガイダンスは、オフラインの暗号化バックアップ、定期的なリストアテスト、クラウドプロバイダの責任への注意を推奨している。また、分離された環境と保持されたシステムイメージの価値にも言及している。これは一般的なガイダンスであり、Together の管理策の証拠ではない。顧客が何を尋ねるべきかの有用なベンチマークを提供する。

リストアパスは適切な規模でテストされるべきである。1つの小さなファイルを復旧しても、リポジトリが1つのオブジェクトを返せることを証明するだけである。データベースが一貫性を保って復旧できること、完全な VPS が起動できること、ネットワークルールが再構築できること、すべての重要なシステムが約束された時間内に復帰できることを証明するものではない。サイトレベルの演習には、アイデンティティ、ネームサービス、証明書、ファイアウォール設定、アプリケーションの依存関係、データ移動に十分な帯域幅を含めるべきである。

顧客は誰がリストアを開始するのかも知る必要がある。ポータルが利用不可の場合、電話のエスカレーションはあるのか？攻撃者が破壊的なロールバックを命じられないように、リクエストはどのように認証されるのか？どの時点が安全かを誰が決定するのか？リストアは唯一生き残ったコピーを上書きするのか？これらは運用上の質問であり、プレミアム機能ではない。

説得力のある Together のリカバリーに関する主張には、各コピーの場所と隔離、最新の使用可能なバックアップの経過時間、前回のフルリストアにかかった時間、リカバリーサイトで利用可能な容量が含まれるべきである。これらの事実が提供されるまで、バックアップはクラウドの当然の特性ではなく、未検証のオプションとして扱うべきである。

ローカルホスティングは主権を向上させるが、集中度も高める

データのローカリティは Together を選択するもっともな理由である。パレスチナの企業は、ローカルユーザーへの低レイテンシ、地元サポート、馴染みのある契約、記録がどこに保管されているかについての明確な回答を望むかもしれない。公的機関や規制対象組織は、一次データをパレスチナの管轄内に維持することに特に価値を置くかもしれない。

政策文脈はその関心を強化する。世界銀行の評価は、パレスチナ政府がデータを国境内に保持し、ディザスタリカバリ拠点を海外に置く可能性のあるプライベートクラウドを選好していると述べた。より最近の政府のクラウド戦略通知は、データ主権と運用レジリエンスを統合ホスティング戦略の目標に含めている。これらは公共部門の計画であり、Together に課された要件でも、そのサービスがそれらを満たしていることの証明でもない。

ローカリティはコンポーネントごとに定義されなければならない。本番ディスクはローカルだが、バックアップは海外にあるかもしれない。ログは海外のセキュリティサービスに送信されるかもしれない。メールフィルタリング、ドメインネームサービス、ソフトウェア更新、監視、サポートシステムは国境を越えるかもしれない。プロバイダは他の場所でホストされているサービスを通じてローカルサーバーを管理するかもしれない。したがって、「データはパレスチナにとどまる」という言葉は、契約が本番データ、レプリカ、バックアップ、メタデータ、サポートアクセス、削除コピーを特定する場合にのみ意味を持つ。

ローカリティはリスクの集中を高めることもある。厳格な場所の選好を満たすために本番とバックアップが近接して保持されている場合、同じ地域の電力、接続、アクセスの事象が両方に影響を及ぼす可能性がある。遠隔コピーはディザスタリカバリを改善するが、別の法的およびサプライヤーの境界を生み出す。普遍的な答えはない。どのデータが、どのような暗号化と管理の下で外部に出ることができ、どの障害が最も重要かを顧客が決定しなければならない。

公開されたサイト名がないことは、この決定をより困難にする。Together は、必要であれば機密保持の下で、少なくとも本番、バックアップ、管理場所の国と都市を開示すべきである。顧客コンテンツを保存またはアクセスできる下請業者を特定すべきである。また、終了後にアクティブなシステム、バックアップ、廃棄されたメディアからデータがどのように消去されるかも明記すべきである。

サポートの深さは利用可能容量の一部である

Together は自らをネットワークオペレータとサービスプロバイダの両方として提示している。これにより、同じ組織がホストされたサーバーとそれを運ぶ経路の両方を確認できるため、エスカレーションが簡素化される可能性がある。また、複数の責任を同じエンジニアに課すこともある。広範なアクセス障害は、ネットワークスタッフが最も忙しいときに、住宅用、ビジネス用、ホスティング、コロケーションの顧客から同時に電話を発生させる可能性がある。

お問い合わせページは、営業担当の連絡先詳細、ウェブフォーム、公開電話番号を提供している。PeeringDB は AS42013 のネットワーク運用メールアドレスを公開している。これらは到達可能なサポートチャネルの兆候である。時間帯、重大度レベル、応答目標、指名されたエスカレーション役割、夜間や休日の人員配置については説明していない。

サポートの約束は、応答と修理を区別すべきである。15分以内の受領確認は、故障したサーバーが15分で復旧することを意味しない。修理時間は、診断、サイトアクセス、スペアパーツ、バックアップの状態、行動権限に依存する。顧客は、クロックがいつ開始するか、どのようなイベントで停止するか、目標を達成できなかった場合の救済策は何かを尋ねるべきである。

知識の集中も別のリスクである。誰がハイパーバイザー、ストレージ、ルーター、バックアップシステム、施設にアクセスできるのか？各重要なタスクに少なくとも2人が権限を持っているか？緊急用の認証情報は保護されているが利用可能か？別のエンジニアが文書化された設定からテナントネットワークを再構築できるか？適切な場合、顧客は自身の管理者認証情報と暗号鍵を保持しているか？

最も強固なサポート設計は、独立した通信経路も提供する。Together の接続がダウンした場合、同じネットワーク上にホストされたステータスページやホットラインも一緒に消失する可能性がある。顧客は、プライマリプラットフォームが利用できないときにも到達可能な番号、外部ステータスチャネル、指名されたエスカレーションを必要とする。

課金とプロバイダ契約は、ハードウェア故障がなくても停止を引き起こし得る

物理スタックは商流スタックの内部に位置する。Together は一部の機器を所有し、ラックスペースを賃借し、トランジットを購入し、仮想化およびコントロールパネルソフトウェアのライセンスを受け、ドメインや証明書を他のサプライヤーから取得している可能性がある。更新の失念、請求の紛争、契約の終了は、すべてのサーバーが健全であってもサービスを中断させる可能性がある。

顧客はどの依存関係がワークロードを停止させる可能性があるかを知る必要がある。VPS は支払いが遅れた直後に停止するのか、猶予期間中はデータが保持されるのか？ソフトウェアライセンスの不具合が管理を妨げるのか、新しいプロビジョニングだけを妨げるのか？Together は施設間でワークロードを移動する権利を持っているのか？製品が廃止されたりサプライヤーが変更されたりする前にどのような通知が行われるのか？

同社の公開ページは、標準的なクラウド利用条件、サービスレベル契約、または移行スケジュールを提供していない。そのため、個別の契約レビューが不可欠である。契約は、データ所有権、許容される利用、停止権、違反通知、バックアップ責任、サポート時間、保守、責任、救済策、終了支援を特定すべきである。

コロケーションは特別な分離を追加する。Together はスペース、電力、ネットワークを提供し、顧客がサーバーを所有する可能性がある。顧客が支払いを停止した場合、誰が施設に入り機器を回収できるのか？Together が施設を変更した場合、移行とダウンタイムの費用は誰が負担するのか？ドライブが故障した場合、Together が交換してよいのか、それは誰の在庫からか？これらの質問は、所有権が復旧に役立つのか、単に責任を再配置するだけなのかを決定する。

ポータビリティが最後のレジリエンステストである

ホストされたサービスは、唯一のコピーが現在のプロバイダの管理下でのみ実行可能である場合、完全に復旧可能とは言えない。NIST のクラウド推奨事項は、ワークロードのポータビリティと標準インターフェースを、プロバイダ依存の重要な制限として扱っている。Together の顧客にとって、ポータビリティは終了時ではなく、インシデント前にテストされるべきである。

共有ホスティングは、ウェブサイトファイル、データベース、メールボックス、DNS レコードとしてポータブルかもしれないが、コントロールパネルのフォーマットが移行を複雑にする可能性がある。VPS は仮想ディスクイメージとしてエクスポート可能かもしれないが、そのイメージは別の場所では異なるドライバ、ファームウェア、ネットワーク設定を必要とするかもしれない。専用サーバーは通常のデータを保持しているかもしれないが、そのハードウェアにバインドされたライセンスアプリケーションに依存しているかもしれない。コロケーション機器は物理的にポータブルだが、次のプロバイダに移行できないアドレスを使用しているかもしれない。

移行計画は、フォーマット、時間、コストを指定すべきである。顧客はサポートチケットを開かずに現在のコピーをダウンロードできるか？エグレス料金や帯域幅制限はあるか？Together はデータベースの一貫性と最終デルタ転送を提供するか？退去後、データとバックアップはどのくらい保持されるか？顧客はアドレスを維持できるか、それとも DNS とファイアウォールルールを変更しなければならないか？

休眠中の AS34008 はこの疑問を具体的なものにする。Together のネットワーク構成は以前にも変更されている。2019年1月まで AS34008 から可視であったプレフィックスは、現在ではアクティブな AS42013 面に関連付けられている。それは円滑なルーティング移行だったかもしれない。それでも、会社が存続する間に識別子と発信元パスが変更され得ることを示している。顧客のシステムは、文書化されていない履歴に依存せずに、次の変更を乗り切れるべきである。

良い移行演習は小規模でも可能である。代表的な VPS を1つエクスポートし、独立した環境で復旧し、テスト DNS 名を更新してアプリケーションが動作することを確認する。共有ホスティングアカウントを元のコントロールパネルなしで復旧する。顧客保持の認証情報を使用してバックアップを取得する。時間と欠落している依存関係を記録する。この演習はポータビリティを契約上の文言から証拠に変える。

現在の証拠が支持できることとできないこと

Together Communication は不可視ではない。最新の公開ウェブサイトを維持し、具体的なホスティングおよびコロケーションの提案を説明し、RIPE メンバーシップを保持し、AS42013 を通じて相当量の IPv4 および IPv6 空間を発信し、ルートコレクタに広く出現し、ラマッラの名前付き施設で PSIX に接続している。これらは稼働中の地域ネットワーク事業の意味のある兆候である。

割り当てられたクラウドネットワーク ASN は別問題である。AS34008 は同じ組織に登録されたままであるが、現在のグローバルに可視な経路はなく、2019年1月以降、広く観測された経路を発信していない。古いポリシー記述と過去のプレフィックスは過去の運用の証拠であり、現在のクラウド到達可能性の証拠ではない。その狭い面において、運用証拠は否定的である。

アクティブな AS42013 は、より大きなクラウドの疑問に答えることはできない。公開証拠は、どの施設が Together Cloud をホストしているか、複数の本番サイトが存在するか、バックアップがどこに存在するか、ストレージがどのように複製されているか、どの電源が生き残るか、どれだけの予備コンピュートが存在するか、どのサポート時間が適用されるか、顧客がどのように退去するかを確立しない。稼働中のネットワークは、レジリエントなクラウドと同様に脆弱なクラウドを運ぶことができる。

これにより3つの別々の判断が生じる。Together Communication の企業およびネットワークの継続性は支持される。AS34008 の現在の運用は支持されない。ホストされたプラットフォームの回復力はまだ弱い証拠に支えられている。これらの判断を分離することで、不当な却下と不当な信頼の両方を避けることができる。

デューデリジェンスリクエストは1ページに収まるべき

将来の顧客は、この証拠上の立場を改善するために、機密の図面やすべてのラックの見学を必要としない。Together は、コンパクトなサービススケジュールで主要な質問に答えることができる。

第一に、運用境界を明示すること。どの法人が顧客と契約するか、どの ASN がサービスを運ぶか、どの当事者がサーバーを所有するか、どのサプライヤーが施設とトランジットを提供するか。第二に、本番、レプリカ、バックアップコピーの都市と障害ドメインを特定すること。第三に、製品に関連する単位で、設置容量とフェイルオーバー容量を記載すること。コンピュート、メモリ、ストレージ、ラック電力、ネットワークスループット。

第四に、保守性のレベルで電源と冷却を説明すること。独立フィード、UPS パス、発電機の自立時間、給油、冷却余力、前回の負荷テスト。第五に、ネットワークの多様性を説明すること。キャリア、物理的引込み口、エッジデバイス、PSIX の使用状況、通常時の使用率、1つのパスが故障した後の容量。第六に、ホスト、ストレージ、スイッチ、光学部品のハードウェアスペアおよび交換ポリシーを明記すること。

第七に、復旧目標と前回のフルリストアの結果を公開すること。第八に、ネットワーク停止中も利用可能なサポート時間、重大度定義、エスカレーションチャネルを明示すること。第九に、保守、停止、セキュリティインシデント、救済策をカバーする標準契約を提供すること。第十に、代表的なワークロードと顧客データセットのエクスポートを実証すること。

これらの要求のいずれも、Together がハイパースケーラーを模倣しなければならないと仮定していない。地域クラウドは、より小規模で、よりパーソナルで、より地元に有用であり得る。その利点は、責任を持つ人と資産の連鎖が短いことでなければならない。その利点を信頼できるものにするためには、最初のリンクが故障したときに何が起こるかを顧客が知ることができるほど、連鎖が十分に見えていなければならない。

現在の証拠は、慎重な委託決定を支持する。Together Communication は実際のネットワークを運用し、実際のホスティングカテゴリを公に販売している。その正確なクラウドネットワーク ASN は休眠状態であり、商用クラウドの背後にある物理設計は開示されていない。顧客は、サイト、プロバイダ、または復旧の障害に耐えられないワークロードに対しては、サービスが潜在的に有用ではあるがまだ証明されていないものとして扱うべきである。その結論を変える証拠は明白である。現在のサービスマッピング、分離された障害ドメイン、測定されたフェイルオーバー容量、テスト済みリストア、実行可能な移行経路である。