要約
- LIVEHOSTING データセンター SRL は、ティミショアラのデータセンターの運営者であり、AS41635 の保有者であることを公に表明しています。現在の販売ページでは、ウェブホスティング、仮想サーバー、専用サーバー、サーバー管理、1U～3U のコロケーションを提供しています。
- パブリックネットワークエッジはアクティブであり、単なる登録ではありません。RIPEstat は、2026年7月12日に AS41635 から 89.38.208.0/22 を観測し、ルーティングステータスのスナップショットで報告しているすべての 326 の IPv4 ピアに可視であり、AS12302 と AS39737 が観測された隣接ネットワークです。
- 物理的な証拠はあまり新しいものではありません。2012 年のルーマニアの業界ガイドでは、30 平方メートルのデータルーム、2 つの 50 kW 三相電源、100 kW ディーゼル発電機、4 台の 40 kW UPS ユニットが報告されていました。これらの数値は有用な歴史ですが、2026 年に利用可能な機器、負荷、ランタイム、冗長性を確定するものではありません。
- コロケーションページには、2 つの電源、UPS、発電機、DDoS 保護、1 Gbps インターネットポートがリストされています。A/B 回路分離、発電機の燃料持続時間、冷却冗長性、ファイバー入口、キャリアコミット、メンテナンステスト結果、セカンドリカバリサイトは公開されていません。
- ネットワーク証拠グレードは中程度です。現在のサービスとルーティングされた運用面について確かな証拠がありますが、販売された容量を同時に維持可能であるか、または施設やキャリアの障害後に回復可能であることを示す、現在の独立した証拠は十分ではありません。
主張は検証可能なほど具体的です
LIVEHOSTING データセンター SRL は曖昧なクラウドラベルの背後に隠れていません。現在のお問い合わせページでは、ルーマニアの法人名、登録番号 J35/815/2010、税コード RO26963713 を記載し、AS41635 を特定し、ティミショアラで自社データセンターを運営していると述べています。そのコロケーション提供は、顧客機器をその施設に配置し、UPS と発電機の保護をリストしています。これは、サイトやネットワークを特定しないリセラーよりも具体的です。
具体性は有用な立証責任を生み出します。プロバイダーが顧客のワークロードの背後にある建物レベルのインフラを運営していると述べた場合、関連する単位は価格ページに表示される仮想サーバーではありません。ユーティリティ取入口から UPS、発電機、配電、冷却、ラック、スイッチ、エッジルーター、キャリアパス、技術者までの完全なチェーンです。すべてのリンクが、障害時に顧客が実際に使用できる容量を減らす可能性があります。
同社の公的資産は、いくつかの依存タイプにわたっています。そのホームページでは、Windows および Linux ホスティング、仮想サーバー、専用サーバー、コロケーション、サーバー管理を販売しています。共有ホスティングの顧客は、プロバイダーが制御するプラットフォームに依存します。仮想サーバーの顧客は、直接検査できないホストおよびストレージ設計に依存します。専用サーバーの顧客は、ハードウェア、スイッチング、リモートアクセスに依存します。コロケーションの顧客は、サーバーの多くを所有しますが、施設とネットワークに依然として依存します。共通の電源またはキャリアレイヤーの障害は、請求書レイヤーでは別々に見える製品に影響を与える可能性があります。
重要な違いは、運用の証明と復元力の証明の間です。AS41635 と現在の製品カタログは、LiveHosting が運用中であることを説得力を持って示しています。しかし、それ自体では、1 つのユーティリティパス、1 つの UPS ストリング、1 つの冷却ユニット、1 つのエッジルーター、または 1 つのファイバー入口の喪失にどれだけの負荷が耐えられるかを示していません。この 2 番目の質問が、ティミショアラの小規模データセンターが通常の日に単に利用可能であるのか、それとも困難な日に回復可能であるのかを決定します。
現在のサービスは小さなパブリックフットプリントの背後にあります
公開証拠は、実際の運用ビジネスを支持しています。LiveHosting は、仮想サーバー、専用サーバー、コロケーションの価格を公開し、顧客アカウントと注文ページを維持し、ネットワーク乱用連絡先を公開しています。そのSSD 仮想サーバーページでは 6 つの構成をリストし、NVMe ページではさらに 6 つをリストしています。専用サーバーページでは、HP ProLiant DL360 G7およびG8システムをデュアルホットスワップ電源と複数のネットワークインターフェースで宣伝しています。
これらのページは販売面を確立しますが、在庫数ではありません。物理ホストの設置台数、即時提供可能な台数、CPU とメモリのコミット割合、交換用システムとドライブがサイトに保管されているかどうかは示していません。最後の適切なシャーシが使用中、スペアが修理中、または新しい電力がラックに割り当てられない場合でも、構成は注文可能なままです。したがって、購入者はリストされた構成を、監査された設置容量ではなく、販売されるサービスクラスとして扱うべきです。
公的企業フットプリントも小さく見えます。Termene.ro の企業プロフィール（ルーマニアの企業情報アグリゲーター）は、2024 年の売上高 RON736,213、純利益 RON286,410、平均従業員数 1 人を報告しています。対照的に、LinkedIn は同社を 2～10 人の従業員帯に分類し、2006 年以来 4,000 人以上の顧客にサービスを提供していると述べています。どちらの情報源も、夜間のインシデントに利用可能な現在のエンジニア数を証明するものではありません。請負業者、関連スタッフ、キャリア技術者、建物担当者は、すべて法定平均またはソーシャルメディアの範囲外にある可能性があります。
その不確実性は重要ですが、小規模チームが能力がないことを意味するわけではありません。小規模事業者は技術的に規律正しく、対応が速い場合があります。また、1 人の管理者の知識と、応答時間が顧客の契約外にあるサプライヤーに大きく依存する場合もあります。関連する証拠は、現在の勤務表、エスカレーション体制、アクセスリスト、サプライヤーサポート権限です。公開されている人員数のシグナルは、単にこれらの質問をより重要にします。
ティミショアラはサービス場所ですが、完全なサイトマップではありません
LiveHosting は、ティミショアラで自社データセンターを運営していると繰り返し述べています。法的連絡先情報は、登記上の事務所を市郊外の Dumbravita に置いている一方、コロケーションページはサービス場所を「LiveHosting データセンター Timisoara」と述べています。これらは互換性のある声明ですが、登記上の事務所、データルーム、宣伝されているすべてのサーバーが同じ住所にあることを証明するものではありません。
データセンター Map の施設エントリーは、ティミショアラ市内中心部から 2 キロメートル以内に 1 つの LiveHosting 施設があると説明し、正確な場所は公開されていないと述べています。そのエコシステムページは、サイトのネットワークまたはサービスプロバイダーデータを報告していません。データセンター Map はエンジニアリング監査ではなく商業ディレクトリですが、公開正確住所がないことは重要な境界を強化します。都市は支持されていますが、建物の身元と所有権構造は支持されていません。
「自社データセンター」は、いくつかの取り決めを説明できます。会社が不動産とすべての機械・電気プラントを所有している場合があります。賃貸建物内の IT ルームを所有している場合があります。家主がユーティリティ取入口、火災システム、または冷却を管理している場合があります。発電機のメンテナンスや遠隔セキュリティを委託している場合があります。これらのモデルのいずれも本質的に欠陥があるわけではありません。それらは異なる復旧権と異なるペーシングサプライヤーを生み出します。
コロケーションを評価する顧客は、責任マトリックスを求めるべきです。建物の所有者、各電気段階の運営者、冷却の保守者、物理アクセスの管理者、発電機燃料契約の保有者、外部ファイバーの所有者、緊急作業を許可できる者を特定する必要があります。また、法的登記事務所と施設住所、およびバックアップ場所を区別する必要があります。そのマップがなければ、「自社データセンター」というフレーズは有用ですが不完全です。
サービスエリアはネットワークレベルで最も明確です。AS41635 はルーマニアに登録され、製品はルーマニア語で販売され、IPinfo のトレースルートは、2026 年 6 月に Prime Telecom を介して発信ブロック内のアドレスに到達し、ティミショアラとラベル付けされた宛先に到達しました。これはルーマニアでの配信を支持します。すべてのバックアップ、制御サービス、監視プローブ、または顧客コピーがルーマニアに残っていることを証明するものではありません。
詳細な 2012 年のスナップショットは 2026 年のプラントを認定できません
物理プラントの最も具体的な公開説明は、Market Watch のデータセンター 2012 ガイドに掲載されています。このガイドは、30 平方メートルのデータルーム、それぞれ 50 kW の 2 つの三相変圧器供給（1 つは Electrica から、もう 1 つは CET からと記載）、100 kW ディーゼル発電機、それぞれ 40 kW の 4 つの UPS ユニットを報告しました。また、1 Gbps 通信、Dell サーバー、ストレージ、ネットワーキング、PRTG と DRAC による監視、ISO 9001 および ISO 27001 認定をリストしました。
これは、現在のウェブサイトでは提供されていないスケールとトポロジーの主張を提供するため、貴重な歴史的証拠です。また、14 年前のものです。機器は老朽化し、バッテリーは交換され、冷却は拡張され、配線は配線し直され、キャリア契約は変更され、施設は移転します。このガイドは、プロバイダーの当時の説明を正確に捉えていたかもしれませんが、現在顧客にサービスを提供しているプラントについてはほとんど語っていません。
数値も解釈が必要です。2 つの公称 50 kW 供給が、必ずしも 100 kW の回復力のある IT 負荷に等しいわけではありません。どちらかの供給が部屋全体を支えられなければならない場合、回復力のあるユーティリティ容量は、損失と非 IT 負荷後の小さい方の経路の使用可能定格に近くなる可能性があります。100 kW の発電機は、冷却、UPS 損失、照明、ポンプ、起動電流を含めた後にサポートできる IT 負荷を確定するものではありません。4 つの 40 kW UPS ユニットは、N、N+1、2N、または異なる負荷をサポートする別個のシステムとして構成されたかどうかを明らかにしません。
したがって、現在のウェブサイトは、2012 年のガイドと統合するのではなく、それに沿って読むべきです。現在のページは、コロケーションとサーバー製品が引き続き販売されていることを証明しています。古いガイドは、会社がかつて開示したものを示しています。ここでレビューされた公開文書は、歴史的な定格を現在の単線電気図、試運転記録、負荷テスト、バッテリー状態レポート、または燃料ランタイムテストに結び付けていません。これらが現れるまで、歴史的数値は質問のベースラインであり、現在の容量証明書ではありません。
2 つのサーバー電源が 2 つの独立した電源パスを証明するわけではありません
現在のコロケーションテーブルは、1U、2U、3U プランの電源として「2」をリストしています。専用サーバーページも同様に、デュアルホットスワップ 750 W 電源を宣伝しています。これは優れたコンポーネントレベルの設計です。1 つの電源モジュールが故障しても、もう 1 つのモジュールとその入力が健全であれば、サーバーは継続できます。ただし、復元力は 2 本のコードがどこにつながるかに依存します。
両方のサーバー電源が同じラック PDU に接続されている場合、PDU は単一障害点のままです。2 つの PDU が同じ UPS 出力またはスイッチボードに接続されている場合、上流の電気パスは共有されたままです。別個の UPS システムが 1 つの転送スイッチまたは 1 つの発電機に依存する場合、その障害は両方の見かけのフィードを取り除く可能性があります。物理的に別個のユーティリティ接続でさえ、建物外の変電所、ケーブル経路、または保護方式を共有する場合があります。
これが、Uptime Institute の Tier トポロジーの説明が、冗長コンポーネントと同時保守性およびフォールトトレランスを区別する理由です。2 番目のコンポーネントは、2 番目の配信パスと同じではありません。この記事は、LiveHosting に Tier レベルを割り当てていません。レビューされた会社ページは 1 つも主張しておらず、2012 年のガイドも Uptime 分類を提供していません。このフレームワークは、より強力な文言を支持する証拠を明確にするためにのみ有用です。
デュアルフィードとして販売される各ラックについて、LiveHosting はユーティリティまたは発電機からスイッチギア、UPS、配電、PDU までの A パスと B パスを示すことができるべきです。どのデバイスがシングルコードのままであり、転送スイッチが使用されているかを述べるべきです。最大ラック消費、ブレーカー定格、許容定常負荷、計量方法を公開するべきです。コロケーションページは電力消費が含まれていると述べていますが、電力許容量を定量化していません。その省略により、1U、2U、または 3U のスペースを安全で商業的に執行可能な電力コミットメントに変換することが困難になります。
最も重要なテストは図だけではありません。現実的な負荷で顧客機器がオンラインのまま制御された転送を行い、その後バッテリー、発電機、冷却、ネットワーク機器が意図したとおりに動作したという証拠を提示することです。
発電機の存在は発電機の持続時間と同じではありません
現在の販売ページは発電機をリストし、2012 年のガイドは 100 kW ディーゼルユニットを報告しました。発電機は、長いユーティリティ中断を橋渡しできますが、それは自動検出、始動バッテリー、転送機器、燃料、冷却、排気、メンテナンス、負荷受入、燃料補給アクセスなどのサポートシステム全体が機能する場合に限ります。「発電機」という言葉は、これらの条件のいずれも開示しません。
ランタイムは最初に欠けている数値です。タンクは部分負荷で数時間をサポートするかもしれませんが、設計負荷でははるかに少なくなります。燃料消費は電気需要とともに変化し、施設の需要にはサーバー以上のものが含まれます。冷却はグリッド損失中も継続しなければなりません。そうでなければ、発電機は IT 機器に電力を供給し続ける一方で、室温が強制シャットダウンに向かって上昇する可能性があります。したがって、公開ランタイムは、サポートされる重要負荷、最低オンサイト燃料、燃料補給契約、冷却の前提条件を記載するべきです。
Uptime Institute の燃料システムガイダンスは、Tier トポロジーにおける施設の表明された N 負荷での 12 時間の最小貯蔵期待値を説明しています。これは参照点であり、LiveHosting がそれを満たしているか、その正確な設計を採用する必要があるという証拠ではありません。小規模プロバイダーは異なるリスク目標を選択できます。重要なのは、顧客が目標を知り、それを自身の復旧ニーズと比較できることです。
テストはタンクサイズと同じくらい重要です。無負荷の月次始動は、発電機と転送システムが暑い日に部屋を支えることを証明しません。意味のある記録には、負荷転送テスト、持続時間、負荷率、燃料品質、アラーム、失敗した始動、是正措置が含まれます。また、ユーティリティ電源が取り外されたときに、両方の現在のキャリアパスと外部監視が利用可能なままであるかどうかも示すべきです。
顧客への影響は直接的です。短い中断は UPS バッテリーで吸収されるかもしれません。より長い停止は発電機と燃料イベントになります。発電機が故障するか、冷却をサポートできない場合、部屋内のすべての製品は、その上に存在する仮想マシン、RAID セット、サーバー電源の数に関係なく、同じシャットダウン期限に収束する可能性があります。
冷却により、使用可能な電気容量が決まります
ここでレビューされた公開資料は、現在の冷却設計、設置冷却容量、冗長レベル、封じ込めレイアウト、環境動作範囲を提供していません。この欠如により、読者は歴史的な電気定格を使用可能な IT 容量に変換することができません。IT 機器が消費するほぼすべてのワットは除去すべき熱になり、部屋は銘板の電気制限に達する前に冷却によって制約される可能性があります。
2012 年に報告された 30 平方メートルという数値も、現在のラック密度については何も述べていません。負荷の軽いラックを備えた小さな部屋は安定しています。同じ部屋にデュアルプロセッササーバー、高密度ストレージ、または高速スイッチングが満たされると、総建物電力が公称制限内に留まっていても、ホットスポットが発生する可能性があります。専用サーバーカタログには、複数のドライブとデュアルプロセッサを備えたシステムが含まれており、顧客のコロケーション機器は予測可能性が低くなります。容量割り当ては、平均熱と局所的な集中の両方を考慮しなければなりません。
冷却冗長性にはいくつかの層があります。冷却ユニット、コンプレッサーまたは冷水ソース、ポンプとファン、制御システム、電源、放熱パスです。「N+1 冷却」でも、共通の配管、制御、または電気依存関係を隠すことができます。メンテナンスは、障害よりも明らかにすることがあります。暑い日に冷却ユニットを隔離してサービスできず、部屋をコミットされた負荷以下に減らさなければならない場合、設置容量は同時に使用可能な容量を超えます。
購入者は、サーバー吸気口の温度と湿度範囲、センサー配置、アラームしきい値、傾向記録、暑い日の余裕、冷却ユニット喪失テストの結果を尋ねるべきです。応答は、温度が上昇した場合の自動シャットダウンポリシーと顧客通知を説明するべきです。また、発電機容量がコミットされた IT 負荷に必要なすべての冷却を含むかどうかを述べるべきです。
火災と水の影響も続きます。結露、屋根、または配管の漏れは、コンパクトな部屋に急速に影響を与える可能性があります。火災検知と抑制は、占有スペースおよび通電中の電気機器と互換性がなければなりません。公開資料は歴史的な物理セキュリティと監視に言及していますが、現在の防火区画、漏れ検知、抑制、または洪水ゾーンの証拠を提供していません。顧客はこれらの制御をデータセンターラベルだけで推測すべきではありません。
設置容量、販売可能容量、回復可能容量は異なる数値です
プロバイダーは、機器が設置されていることを正直に主張できますが、新規顧客に利用可能な容量は少なく、障害時に利用可能な容量はさらに少なくなります。設置容量は、銘板と設定リソースの合計です。販売可能容量は、予約とオーバーサブスクリプション後に商業およびエンジニアリングルールが許可するものです。回復可能容量は、定義されたコンポーネントが故障した後に残るか、時間内に復元できるものです。
LiveHosting の公開ページは、サーバー CPU、メモリ、SSD または NVMe ストレージ、「無制限」のトラフィックを宣伝しています。これらの仕様は、権利または製品構成を説明しています。ホスト占有率、ストレージレプリケーション、アップリンク競合、バックアップスループットを示していません。「無制限」のトラフィックは特に誤解されやすいです。量ベースの課金がないことを意味するかもしれませんが、すべてのパケットは依然として有限のポート、エッジ、およびトランジットコミットを共有します。
コロケーションスペースも、電力とネットワークの余裕がなければ同様に不完全です。3 人の 1U 顧客は、ハードウェアに応じて 1 人の 3U 顧客よりも少ない電力を消費する場合もあれば、はるかに多い場合もあります。1 Gbps ポートはインターフェースレートであり、攻撃下または 1 つのキャリアが故障した後の保証されたインターネットスループットではありません。発電機の銘板は顧客容量コミットメントではありません。UPS 定格はランタイム保証ではありません。
重要な運用指標は、障害状態の予算です。1 つの電源パスが隔離された場合、何キロワットが残りますか？1 つの冷却ユニットが失われた後、どの室温を維持できますか？Prime Telecom または Vodafone が利用できなくなった場合、どのインターネット容量が残りますか？バックアップから同時に再起動できる仮想サーバーはいくつですか？同時のハードウェア、ネットワーク、および顧客インシデントを処理できるエンジニアは何人ですか？
これらの数値は、顧客クラスに関連付けるべきです。共有ホスティングは、公共部門のウェブサイト、トランザクションアプリケーション、メールサーバー、またはコロケーションされたエンタープライズシステムとは異なる復旧時間に耐える場合があります。小規模施設は、ハイパースケール容量を必要とせずに有用であることができます。実際の冗長性に適合したコミットメントと、障害状態のエンベロープを超えて販売しないという明確な拒否が必要です。
AS41635 は稼働中で、グローバルに可視です
ネットワーク証拠は、公的記録の中で最も強力な部分です。RIPE RDAPは AS41635 をアクティブとしてリストし、LIVEHOSTING-AS と命名しています。RIPEstat AS 概要は、保有者を LIVEHOSTING データセンター SRL として特定し、ASN がアナウンスされていることを示しています。これは、会社自身のお問い合わせページと一致します。
2026 年 7 月 12 日、RIPEstat ルーティングステータスは、1,024 アドレスを含む 1 つの発信 IPv4 プレフィックスと、発信 IPv6 プレフィックスなしを示しました。IPv4 ルートは、そのスナップショットで報告しているすべての 326 の IPv4 ピアに可視でした。RIPEstat のアナウンスされたプレフィックスビューは、89.38.208.0/22 を現在のアナウンスとして特定しました。ルーティング履歴ビューは、LiveHosting が発信するアドレス空間を 2006 年まで遡ってトレースしますが、アグリゲートは時間とともに /21 から現在の /22 に変更されました。
これは意味のある運用証拠です。長年にわたって維持されている広く可視なルートは、単なる装飾的な ASN 登録とは矛盾します。プレフィックスは、会社自身のウェブサイトと公開サーバー名をホストし、独立したアグリゲーターもそれを特定します。Hurricane Electric の BGP Toolkitは、1 つの IPv4 プレフィックス、1,024 の発信 IPv4 アドレス、2 つの観測された IPv4 ピア、IPv6 発信なしを報告しました。IPinfoは ASN をホスティングとして分類し、2026 年 6 月に AS39737 を介してブロックに到達するパスを示しています。
ルートは RPKI 検証も有効です。RIPEstat 検証は、AS41635 が 89.38.208.0/22 を最大長 /22 で発信する有効な許可を見つけました。RIPE NCC が説明するように、発信元検証は、正当なリソース保有者が特定のプレフィックスと発信元の組み合わせを許可したかどうかを回答します。AS パスの残りを検証したり、物理的な復元力を証明したりするものではありません。
結論は狭くすべきです。LiveHosting は、現在有効で非常に可視な IPv4 発信元を持っています。これはマーケティングマップよりも強力です。それでも、ルーターが二重化されているか、キャリアが別々のダクトから入っているか、生存パスが故障後に顧客需要を運べるかを示すことはできません。
2 つの可視キャリアパスには依然として物理的な証明が必要です
RIPEstat のASN 隣接ビューは、2026 年 7 月 12 日に 2 つの隣接ネットワークを観測しました。AS12302（Vodafone Romania）と AS39737（Prime Telecom）です。BGP 状態スナップショットは、サンプリングされたパスの大部分が Prime Telecom を介し、少数が Vodafone を介していました。Hurricane Electric は独立して同じ 2 つのピアをリストしました。
2 つの観測された隣接は、潜在的なルート代替手段を提供するため、1 つよりも優れています。契約とサイトの証拠なしに、2 つの独立したキャリアとして呼ぶべきではありません。ルートコレクターは AS パスを観測しますが、ファイバー所有権、建物入口、クロスコネクト、または有料容量は観測しません。1 つのキャリアが別のキャリアを再販する場合があります。2 つの回線は、メトロダクト、マンホール、道路横断、パッチパネル、または同じ外部電源機器を共有する場合があります。
RIPE レジストリオブジェクトは、別の注意理由を追加します。そのインポートポリシーは、2021 年に最後に変更され、AS6830 と AS34279 を指定していますが、現在のコレクターは AS12302 と AS39737 を見ています。この違いは、通常のキャリア変更後の古いレジストリポリシーを反映している可能性があります。これは、レジストリ宣言が現在の観測または現在のキャリアスケジュールを置き換えるべきではないことを示しています。
障害後の容量は次の問題です。プライマリパスがほとんどのトラフィックを運ぶ場合、セカンダリはそれを吸収するのに十分なコミット済みおよびバースト容量を持たなければなりません。BGP は正常に再収束するかもしれませんが、残りの回線が輻輳しているためアプリケーションが使用できなくなる可能性があります。DDoS 保護は別の依存関係を追加します。プロバイダーは、フィルタリングがどこで行われるか、両方のアップストリームがそれをサポートするか、ルートがどのように迂回されるか、保護イベントがクリーン容量を減らすかどうかを説明する必要があります。
必要な証拠は実用的です。LiveHosting は、2 つの契約プロバイダー、ポートとコミットサイズ、物理的な境界、入口パス、エッジルーター、電源ドメインを特定する必要があります。各アップストリームをビジー負荷で個別に引き離した最近のテストを示し、収束とパケット損失を記録し、監視と顧客通信が到達可能であったことを確認する必要があります。
PeeringDB プロフィールがないため、公開チェック可能な範囲が狭まります
このレビュー中にPeeringDB APIへのクエリは、AS41635 のネットワークエンティティを返しませんでした。これはネットワーク障害の証拠ではありません。PeeringDB への参加は任意であり、小規模ホスティングネットワークは公開相互接続プロフィールを維持せずにトランジットを購入できます。欠如は、施設、交換、トラフィックレベル、ピアリングポリシー、ネットワーク連絡先への公開視認性を低下させます。
現在の形状は、交換主導ではなくトランジット主導に見えます。公開コレクターは 2 つの隣接ネットワークを公開しますが、公開 PeeringDB レコードはインターネット交換または施設アタッチメントを特定しません。したがって、顧客はネットワークが直接ピアリング、多様な交換ルート、またはキャリアニュートラルなミーティングルームを持つと想定すべきではありません。これらの機能は存在するかもしれません。ここでレビューされた公的記録はそれらを確立していません。
これは障害分離にとって重要です。すべての外部パスが 1 つの建物内の少数のトランジットハンドオフに依存する場合、ローカルキャリアミーティングは、グローバルルートテーブルが 2 つのアップストリーム ASN を示していても、共通の障害点になる可能性があります。1 つの回線が敷地外で終端し、共有ローカルテールを介してデータルームに到達する場合、論理的多様性は最後のキロメートルで消える可能性があります。
プロバイダーは、機密詳細を公開せずにこの不確実性の多くを解決できます。別々の入口、別々のエッジデバイス、キャラー ID、ポート容量、フェイルオーバーポリシーを示す施設ニュートラルなネットワーク図を公開できます。適切な場合、現在の PeeringDB プロフィールを維持できます。ルッキンググラスまたは外部ホスト型ステータスサービスを提供できます。これらはすべてのダクトを証明するわけではありませんが、ネットワークの運用モデルを検証しやすくします。
欠如している IPv6 発信元には直接的な回答が必要です
LiveHosting のコロケーションページは、各パッケージに /56 IPv6 サブネットが含まれると述べています。しかし、RIPEstat と Hurricane Electric は、2026 年 7 月のスナップショットで AS41635 が発信する IPv6 プレフィックスをゼロと示しました。フランスの規制機関 ARCEP も、2025 年のホスティングプロバイダー測定で、AS41635 の IPv6 露出をゼロとリストしました。これらの観測は、顧客が IPv6 サービスを受信していないことを証明するものではありません。
宣伝された /56 は、アップストリームプロバイダーのアドレス空間からのものであり、AS41635 が IPv6 プレフィックスを発信せずに LiveHosting にルーティングされる可能性があります。リクエストに応じてのみ利用可能かもしれません。サンプリングされた公開データには表示されないが、施設内で構成されている可能性があります。各説明には異なる復元力の結果があります。
プロバイダー割り当ての IPv6 はうまく機能しますが、フェイルオーバーは割り当て元のアップストリームに依存する場合があります。/56 が 1 つのキャリアに属し、そのキャリアが故障した場合、LiveHosting は別のパスを介して同じ顧客サブネットをアナウンスできない可能性があります。インシデント中のサーバーエステートの再番号付けは、BGP フェイルオーバーと同等ではありません。DNS、ファイアウォールルール、アクセスリスト、顧客ソフトウェアはすべて古いアドレスを保持する可能性があります。
購入者は、/56 を含むアグリゲート、それを発信する ASN、両方の可視アップストリームを介して到達可能かどうか、ルート発信元認証が意図された発信元をカバーしているかどうかを尋ねるべきです。また、1 Gbps ポートと DDoS 保護が IPv4 と IPv6 に等しく適用されるかどうかを尋ねるべきです。デュアルスタックサービスは、アプリケーションと DNS が両方を公開する場合、テストされていないスタックと同じくらいしか復元力がありません。
このギャップは重要です。IPv6 は装飾的な機能ではありません。コロケーションページはそれを含まれる容量として提示しています。公開ルート証拠は IPv4 運用面を明確にします。同等の IPv6 証拠は、/56 を販売ラインから検証可能なネットワークサービスに変えるでしょう。
品質誓約は施設保証よりも狭いです
LiveHosting の品質コミットメントは、Standard、Business、Reseller の Windows または Linux ウェブホスティングパッケージに適用されます。アップタイムを、中立な場所から HTTP 経由で顧客のウェブサイトが利用可能な月間割合と定義しています。このページは、LiveHosting がデータセンター内および他のルーマニアおよび外国のデータセンターで PRTG システムを使用して可用性を測定すると述べています。
クレジットスケジュールは、アップタイムが 98% から 99.5% の間で 50%、95% から 97.9% で 75%、94.9% 以下で 100% を返します。サービス クレジットは商業的に有用ですが、失われた売上、データ、評判に対する補償ではありません。さらに重要なことに、述べられた範囲は自動的に仮想サーバー、専用サーバー、またはコロケーションをカバーしません。これらのカテゴリーの購入者は、独自のサービス条件が必要です。
除外事項は広範囲にわたります。このページは、とりわけ、通信の中断、火災、洪水、自然災害、ウイルス、攻撃者、サードパーティソフトウェア、告知済みまたは重要なメンテナンス、サーバーアップグレード、LiveHosting の制御外の DNS、およびいくつかのアクセスプロトコルを除外しています。一部の除外事項は、データセンターの顧客が最も理解する必要がある障害パスを正確に説明しています。クレジットからそれらを除外することは、それらが起こりにくいことを意味するのではなく、経済的コストを顧客に移すものです。
測定定義も HTTP 到達可能性に焦点を当てています。ウェブサイトは応答するかもしれませんが、電子メール、データベース接続、ストレージ、コントロールパネル、VPN アクセス、または 1 つのキャリアパスが劣化している場合があります。逆に、アプリケーション障害により HTTP が失敗する一方で、施設の電力とネットワークは健全なままである場合があります。顧客は、施設、ネットワーク、コンピュート、ストレージ、アプリケーション原因を分離するコンポーネントレベルの測定とインシデント記録を必要とします。
より強力な保証パッケージは、製品別の過去のサービスパフォーマンス、メンテナンス時間、インシデント原因、復旧時間を公開するでしょう。どの監視場所が AS41635 から独立しているか、ステータスチャネルが完全な施設またはルート停止中に到達可能なままであるかを述べるでしょう。
応答時間は復旧時間ではありません
品質ページは、月曜日から金曜日の 10:00～18:00 の間に最大 24 時間のテクニカルサポート応答時間を約束しています。現在のお問い合わせページは、月曜日から金曜日の 10:00～17:00 のテクニカルサポートをリストしています。これらのページは異なるチャネルを説明しているか、単に調整が取れていない可能性があります。いずれにせよ、どちらの声明も 24 時間以内のサービス復旧を約束するものではありません。
サーバー管理ページは、より詳細な商業的区別を追加します。基本管理には月 2 時間と平日の可用性が含まれます。プレミアムには月 4 時間が含まれ、月曜日から日曜日、24 時間の可用性を述べています。公開サービス契約は、管理作業は購入されたサブスクリプションの時間に制限され、追加作業は有料であり、アプリケーションの可用性やパフォーマンスは管理サービスによって保証されないと述べています。
これにより、管理対象外の専用サーバーおよびコロケーションの顧客に対していくつかの質問が残ります。サーバー管理が行われていない場合でも、施設の緊急対応は継続的ですか？誰が午前 3 時に電力、冷却、またはネットワークアラームを認識しますか？リモートハンズは常時利用可能ですか？到着目標は何ですか？コロケーションページは、リモートハンズを 1 時間あたり 25 ユーロと価格設定していますが、24 時間対応のコミットメントは公開していません。
この区別は小規模運用において重要です。検出は自動化できますが、診断と承認は担当者に依存する場合があります。キャリアは顧客の指名連絡先を必要とする場合があります。建物は時間外アクセスを制限する場合があります。故障したサーバーはデュアル電源を持つかもしれませんが、それでもローカルディスクまたはケーブルの交換が必要です。各ハンドオフは、復旧が始まる前に時間を追加します。
顧客は、別々の 4 つの時計を求めるべきです。アラームから認識まで、認識から適格な診断まで、診断からサイト介入まで、介入から復旧まで。各時計を誰が所有するか、2 つのインシデントが同時に発生した場合に何が起こるかを尋ねるべきです。電話番号とチケットの約束は有用なエントリーポイントですが、復旧計画ではありません。
メンテナンスは突然の障害よりも多くのリスクを露呈する可能性があります
冗長性は、すべてが健全なときに最も強く見え、1 つのコンポーネントがサービスのために意図的に取り外されたときに最も弱くなります。UPS バッテリーは交換が必要で、発電機は負荷テストが必要で、冷却機器は清掃が必要で、スイッチはアップグレードが必要で、キャリアはメンテナンスウィンドウが必要です。これらの期間中、残りのパスはスペアなしで全負荷を運ぶ可能性があります。
品質コミットメントは、告知済みメンテナンス、重要な作業、サーバーアップグレードをクレジットから除外しています。これはホスティング契約では一般的ですが、実際のリスクはメンテナンスの設計方法に依存します。顧客は、施設が IT 負荷をシャットダウンせずに各重要なコンポーネントを維持できるか、複数のサプライヤーが同時に作業する可能性があるか、ロールバックがどのように処理されるかを知る必要があります。
電力の場合、メンテナンス証拠には、部屋全体を生のユーティリティに置かないバイパスパスと手順を含めるべきです。冷却の場合、1 つのユニットが隔離されたときの最大安全負荷を述べるべきです。ネットワーク作業の場合、顧客ルートが他のルーターとキャリアを通じて安定していることを示すべきです。ストレージまたは仮想化の場合、メンテナンス前にどれだけのワークロードを移動できるか、その移動にどれだけ時間がかかるかを定量化するべきです。
変更の集中は別の懸念事項です。小規模プロバイダーは、混乱を減らすために 1 つのウィンドウでいくつかのタスクを合理的にスケジュールするかもしれませんが、電力、ネットワーク、ホストの変更を結合すると、独立した復旧オプションが削除されます。顧客は、変更承認が共通の依存関係を考慮しているかどうか、外部から到達可能な通信チャネルが影響を受けるシステムの外に保たれているかどうかを尋ねるべきです。
問題を解決する証拠は、通常の運用資料です。編集された年間メンテナンスカレンダー、最近のウィンドウからの通知、メンテナンス後のレポート、失敗したテストのアクション、顧客に可視な影響です。これは、冗長性が意図的に削減される期間をオペレーターがどのように管理するかを示すため、一般的なアップタイム目標よりも説得力があります。
火災、洪水、ユーティリティ損失は顧客データに収束します
品質コミットメントは、不可抗力の除外事項の中に火災と洪水を明示的に言及しています。これは契約上の割り当てであり、施設が露出しているか保護されていないという証拠ではありません。ここでレビューされた公開ページは、現在の火災検知および抑制システム、区画定格、漏れ検知、洪水評価、水および燃料危険からの距離を述べていません。
これらの質問は、多くのサービスレイヤーが 1 つのサイトを占めるときにより重要です。共有ホスティング、VPS、専用サーバー、コロケーション、DNS、電子メール、顧客ポータルはすべて同じ部屋に依存する可能性があります。プライマリデータ、バックアップ、制御システムが施設を共有する場合、建物イベントは生産サービスとそれを復元する手段の両方を削除する可能性があります。
公開サービス契約は、顧客にかなりの責任を課し、保証を制限します。また、未払いの場合はサービスの停止または削除を許可し、サービスを変更または中断する広範な権利を留保します。これらの条件は、物理的なインシデントがなくても、独立したバックアップとテスト済みのエクスポート手順を商業的に重要にします。
顧客は、各コピーがどこにあるか、その資格情報を誰が管理するか、どのくらいの頻度でテストされるか、LiveHosting 自身のアカウントポータルまたはネットワークが利用できない場合に復旧がどのように機能するかを特定する必要があります。同じ部屋の別のサーバー上のバックアップは、一部のハードウェア障害から保護しますが、部屋全体の電力、冷却、火災、洪水イベントからは保護しません。別の建物にあるが、同じアクセスできない ID システムを通じて管理されるコピーも、使用が難しい場合があります。
コロケーション顧客の場合、質問は機器の復旧にまで及びます。インシデント後、誰が入場できますか？顧客のハードウェアは、プロバイダー、建物運営者、または顧客によって保険がかけられていますか？顧客は、長期のユーティリティまたはアクセス閉鎖中に機器を回収できますか？回答は個別の契約にあるかもしれませんが、公開計画ページによって確立されていません。
障害は顧客ごとに異なる影響を与えます
共有ホスティングの顧客は、共通のプラットフォーム障害を、アクセスできないウェブサイト、電子メール、またはコントロールパネルとして最初に感じる可能性があります。どの物理サーバー、スイッチ、またはストレージシステムが故障したかについての可視性はほとんどありません。リセラーは、1 つのアカウントが多くの下流サイトとサポート義務を代表する可能性があるため、影響を増幅する可能性があります。
仮想サーバーの顧客は、オペレーティングシステムをより制御できますが、ハイパーバイザー容量、ストレージ、プロバイダーのローカルネットワークに依然として依存します。ホスト障害は、ワークロードが他の場所で再起動できれば回復可能かもしれませんが、公開製品ページはライブマイグレーション、レプリケートされたストレージ、または復旧クラスタを約束していません。SSD または NVMe の存在は、コピーの数と場所については何も述べていません。
専用サーバーの顧客は、いくつかの共有コンピュートリスクを回避します。それでも、ラック、両方の電源パス、スイッチング、キャリアトランジット、リモートハンズに依存します。デュアル電源と RAID は、選択されたコンポーネント障害を吸収できますが、部屋全体の停止または共有ネットワークエッジ障害には耐えられません。公開専用サーバーリストは、古い G7 および G8 世代も示しています。これは経済的な提供かもしれませんが、購入者はスペアシステムとコンポーネントの可用性について尋ねるべきです。
コロケーション顧客は、自身の機器を所有し、製品ページが BGP アナウンスを許可するように、自身のアドレス空間をアナウンスする場合があります。LiveHosting への依存は物理的です。アクセス、電力、冷却、クロスコネクト、ルーティング、修理支援が必要です。施設の停止は、完全に顧客管理されている機器を停止させる可能性があります。
公共部門、医療、金融、または産業ユーザーは、アップタイムを超えた義務を負う場合もあります。場所、インシデント通知、証拠保存、サプライヤーの継続性が重要になる場合があります。この記事は、そのような LiveHosting 顧客を特定していません。同じ施設の主張が、そこに置かれたワークロードに応じて非常に異なる結果をもたらす可能性があることを強調しています。
したがって、プロバイダーは 1 つの普遍的な復元力ステートメントに抵抗すべきです。各サービスに適用される保護、顧客が提供しなければならないもの、すべての製品ラインにわたる共有依存関係を開示するべきです。
意味のあるフェイルオーバーデモンストレーションは実際の依存関係を削除しなければなりません
現在の復元力を確立する最善の方法は、ラベルを蓄積するのではなく、定義された障害をテストすることです。LiveHosting の場合、5 つの演習がほとんどの未解決の質問に答えるでしょう。
1 つ目は、代表的な生産負荷で通常のユーティリティ電源を削除します。UPS 転送、発電機起動、冷却継続性、燃料消費、アラーム、顧客への影響を記録します。公開されたランタイム目標を実証するのに十分な長さ継続し、その後負荷を落とさずにユーティリティを復旧します。
2 つ目は、各配電パスと UPS セクションを順番に隔離します。デュアルコードの顧客デバイスがオンラインのままであることを確認し、転送デバイスを必要とするシングルコード機器を特定します。成功した発電機テストは、この内部配電テストを置き換えません。
3 つ目は、厳しい周囲期間中に 1 つの冷却ユニットまたは冷却パスを削除します。サーバー吸気温度を追跡し、施設の表明された環境制限内にどれだけの負荷が残るかを確認します。これは冷却冗長性の主張を使用可能容量の証拠に変換します。
4 つ目は、ネットワークがビジーな状態で Vodafone と Prime Telecom を個別に引き離します。BGP 収束、パケット損失、遅延、IPv4 と宣伝された IPv6 サービスの両方での生存スループットを測定します。DDoS 保護、監視、DNS、顧客通信が残りのパスで機能することを確認します。
5 つ目は、プライマリ障害ドメイン外のコピーから、代表的な共有ホスティングアカウント、仮想サーバー、制御サービスを復元します。復旧時間とデータ損失を測定し、通常の顧客ポータルが利用できない場合を含めます。
結果は完璧である必要はありません。開示された弱点とそれに続く是正措置は、テストされていない完全な可用性の主張よりも強力な証拠です。顧客は、実証された復旧が自身の許容範囲と一致するかどうか、独立したセカンドサイトが必要かどうかを判断できます。
電力成長と許可は仮定ではなく制約として扱うべきです
欧州のデータセンター市場は、電源可用性を開発制約としてますます扱っています。欧州委員会のエネルギーパフォーマンスページは、増加する電力需要、冷却と水の影響、関連するしきい値を超える施設の報告義務について説明しています。ここでレビューされた公開証拠は、LiveHosting が 500 kW の報告しきい値を超えることを確立していません。歴史的な数値は、はるかに小さい設置を示唆しています。
小規模であっても、電源管理の必要性がなくなるわけではありません。問題が変わります。コンパクトなサイトは総需要が低いかもしれませんが、スイッチギア、冷却、バッテリー、排気、燃料貯蔵を追加する余地が少なくなります。都市部または都市近郊の建物は、騒音、排出ガス、防火、建設の制約に直面する可能性があります。ユーティリティ接続は現在の負荷には十分かもしれませんが、拡張を遅くまたは高価にする可能性があります。
現在のサイトは、計画された拡張、新しい建物、または電力申請を公開していません。購入者はそれを推測すべきではありません。LiveHosting が新しい高密度容量を販売する場合、証拠は、それが改善された効率、廃止された古い機器、より大きなユーティリティ割り当て、新しい冷却、または別のサイトから来るかどうかを特定するべきです。「利用可能」という言葉は、電力、冷却、ネットワークがすべて試運転されていることを意味するべきであり、単にラックスペースが空であることではありません。
許可も復旧に影響します。発電機の交換、燃料貯蔵の追加、電気サービスの変更、火災システムの変更には、承認とサプライヤーのリードタイムが必要になる場合があります。顧客は、すべての許可番号を公開で必要とするわけではありません。設置された機器が許可され、保守され、サポートされていること、計画された成長が既存の部屋を長期にわたって冗長性が低下した状態に置かないことの保証が必要です。
正しい商業指標は、定義された障害に備えた容量であり、別のサーバーのための理論上の余地ではありません。
信頼性を高めるもの
LiveHosting は、コンパクトな開示パッケージで証拠グレードを引き上げることができます。まず、オペレーターによって日付とバージョンが付けられた現在の施設ファクトシートから始めるべきです。ファクトシートは、適切なレベルのサービスアドレス、オペレーターと家主の境界、データルーム面積、試運転された IT 負荷、現在の測定されたピーク、ラック電力制限、冷却トポロジー、防火制御を記載するべきです。
電力セクションは、ユーティリティ入力、UPS トポロジー、発電機定格、コミットされた重要負荷での最小ランタイム、燃料手配、最後の負荷転送テストの日付と結果を示すべきです。総設置定格と、N、メンテナンス状態、障害状態の容量を区別するべきです。
ネットワークセクションは、現在の Vodafone および Prime Telecom の観測を古い RIPE ポリシーオブジェクトと調整するべきです。契約ポートおよびコミット容量、エッジルーターの多様性、物理的な入口分離、DDoS 手配、宣伝された IPv6 /56 の発信元を開示するべきです。現在の PeeringDB エントリまたはルッキンググラスは外部可視性を向上させますが、物理的な文書を置き換えるものではありません。
運用セクションは、継続的なアラーム所有権、施設応答目標、リモートハンズカバレッジ、スペア在庫、サプライヤーエスカレーションを記載するべきです。10:00～17:00 と 10:00～18:00 のサポートステートメントを調整し、プレミアム 24/7 可用性が応答と復旧にとって何を意味するかを明確にするべきです。
最後に、オペレーターは匿名化されたテストとインシデント証拠を公開するべきです。ユーティリティ転送、冷却ユニット喪失、キャリアフェイルオーバー、復旧演習、重要なメンテナンス、適用された教訓です。独立した認証は、範囲と現在の有効性が明確な場合にパッケージを強化できます。2012 年の認証名は、証明書、サイト、標準、有効期限がなければ現在のものとして扱うべきではありません。
このレベルの開示は、顧客データや機密のフロアプランを公開しません。これにより、購入者は、テストされた制限のある機能する小規模データセンターと、復元力が主に製品ラベルから推測されるものとを区別できるようになります。
証拠グレードは中程度
LIVEHOSTING データセンター SRL は、中程度のネットワークおよびインフラストラクチャ証拠グレードを獲得しています。会社固有の運用証拠は十分です。現在のルーマニアの販売サイト、指名された法人、明示的なティミショアラのコロケーション提供、AS41635、グローバルに可視な IPv4 ルート、2 つの観測された隣接ネットワーク、有効なルート発信元認証、長年のルーティング履歴があります。これは、プロバイダーの存在または基本的なネットワーク運用が単一のディレクトリリストに依存しているケースではありません。
グレードが中程度で止まるのは、復元力の主張が現在の物理的証明によって裏付けられていないためです。UPS と発電機はリストされていますが、トポロジーとランタイムはありません。2 つのサーバー電源はリストされていますが、A/B 分離はありません。2012 年のガイドは詳細な定格を提供しますが、現在の試運転または負荷証拠はそれらの数値を 2026 年のプラントに結び付けていません。冷却、火災、洪水、ファイバー入口、キャリアコミット、メンテナンスパフォーマンス、外部復旧、顧客フェイルオーバー結果は、レビューされた情報源では開示されていません。
現在の 2 つの BGP 隣接は論理的なパス多様性を支持しますが、物理的なルート証拠の欠如はより強い結論を防ぎます。有効な IPv4 ルートは発信元リスクを減らしますが、AS41635 の IPv6 発信元がないため、宣伝された /56 の取り決めは未解決のままです。品質誓約は顧客に測定とクレジットメカニズムを提供しますが、その製品範囲と除外事項は、施設全体の復旧について言えることを制限します。
このグレードはサービス品質の評決ではありません。観察できるものとまだ実証されなければならないものとの間の距離についての声明です。LiveHosting は公開するよりも強力な現在のエンジニアリング記録を所有している可能性があります。購入者は、サービスクレジットの価値を超える停止コストのワークロードを配置する前に、それらを見るよう求めるべきです。
狭い結論は、販売された容量はライブサービスとしては信頼できるが、障害状態の容量としてはまだ証明されていないということです。次に有用な証拠は、別のサーバー構成ではありません。共通の依存関係の 1 つが意図的に削除されたときに何がオンラインのままかを示す、現在の電力、冷却、キャリアテストです。