2.3. ノードのハードウェア構成の計画

Acronis Cyber Infrastructureは市販のハードウェアで動作するため、通常のサーバー、ディスク、ネットワークカードからクラスターを構築できます。ただし、パフォーマンスを最大限に高めるためにはいくつかの要件を満たし、推奨事項に従う必要があります。

注釈

どのハードウェアを選んだらよいかわからない場合は、営業担当者にご相談ください。オンラインのハードウェア計算ツールを使用することもできます。ハードウェアおよび/またはソフトウェアのテスト、インストール、構成の手間を省きたい場合は、Acronisアプライアンスの使用をご検討ください。追加設定なしで、エンタープライズレベルでフォールトトレラントな、3Uフォームファクターで実行される優れたストレージパフォーマンスを備えた5ノードのインフラストラクチャソリューションを取得できます。

2.3.1. ハードウェアの制限事項

次の表は、Acronis Cyber Infrastructureサーバーの現在のハードウェア制限事項の一覧です。

表 2.3.1.1 サーバーハードウェアの制限事項
ハードウェア 理論上 認定
RAM 64TB 1TB
CPU 5120個の論理CPU 384個の論理CPU

論理CPUはマルチコア(マルチスレッド)プロセッサのコア(スレッド)です。

2.3.2. ハードウェア要件

次の表に、ディスクロールに応じた最小および推奨のディスク要件を示します(ストレージアーキテクチャの概要を参照してください)。

表 2.3.2.1 ディスク要件
ディスクロール 数量 最小 推奨
システム ノードごとに1つのディスク 100GB SATA/SAS HDD 250GB SATA/SAS SSD
メタデータ

ノードごとに1つのディスク

1つのクラスターに5つのディスクを推奨

電力損失保護を備えた耐久性1DWPD以上の100GBのエンタープライズクラスSSD
キャッシュ

オプション

HDD4~12基ごとに1つのSSDディスク

電力損失保護を備えた100GB以上のエンタープライズクラスSSD、およびサービス対象のHDDごとに75MB/秒のシーケンシャル書き込みパフォーマンス、耐久性1DWPD以上(推奨値10DWPD)
ストレージ

オプション

クラスターごとに少なくとも1つ

100GB以上、16 TB以下を推奨

SATA/SAS HDDまたはSATA/SAS/NVMe SSD(電力損失保護を備えたエンタープライズクラス、耐久性1DWPD以上)

次の表は、使用するサービスに応じた、1つのノードで確保されるRAMとCPUコアの量を示しています。

表 2.3.2.2 CPUとRAMの要件
サービス RAM CPUコア*
システム 6GB 2コア
ストレージサービス: ストレージロールまたはキャッシュロール(任意のサイズ)を持つ各ディスク** 1GB 0.2コア
計算サービス*** 8GB 3コア
ロードバランササービス*** 1GB 1コア
Kubernetesサービス*** 2 GB 2コア
S3 4.5GB 3コア
Backup Gateway**** 1GB 2コア
NFS サービス 4GB 2コア
各共有 0.5GB 0.5コア
iSCSI サービス 1GB 1コア
各ボリューム 0.1GB 0.5コア

* 64ビットx86 AMD-VまたはIntel VTプロセッサー、ハードウェア仮想環境拡張機能が有効なもの。Intelプロセッサーの場合、BIOSで「Unrestricted Guest」とVT-x with Extended Page Tablesを有効にしたもの。各ノードで同じCPUモデルを使用して、VMの稼働中の移行に関する問題を回避することをお勧めします。この場合のCPUコアは、マルチコアプロセッサーの物理コアです(ハイパースレッディングは考慮されていません)。

**物理領域が1PBを超えるクラスターの場合は、メタデータサービスごとに0.5GBのRAMを追加してください。

***計算、ロードバランサ、およびKubernetesのサービス要件は管理ノードのみを参照します。

****パブリッククラウドとNFSを使用する場合、Backup Gatewayはローカルストレージと同じ量のRAMとCPUを消費します。

ネットワークに関しては、2 x 10GbE以上のインターフェースが推奨されています。内部トラフィックと外部トラフィックには25GbE、40GbE、および100GbEがお勧めです。ボンディングを推奨。外部トラフィックに関しては、1GbEリンクからスタートすることはできますが、最先端の負荷機能でクラスターのスループットが制限される可能性があります。

いくつかの例を検討し、特定のケースの要件を算出してみましょう。

  • 1つのノード(1つのシステムディスクと4基のストレージディスク)があり、それをBackup Gatewayに使用する場合は、以下の計算表を参照してください。

    表 2.3.2.3 例:ノードが1つのBackup Gateway
    サービス 各ノード
    システム 6GB、2コア
    ストレージサービス 1GBと0.2コアの4基のストレージディスク、つまり4GBと0.8コア
    バックアップゲートウェイ 1GB、2コア
    合計 11GBのRAMと4.8コア
  • 3つのノード(1つのシステムディスクと4基のストレージディスク)があり、それを計算サービスに使用する場合は、以下の計算表を参照してください。

    表 2.3.2.4 例:ノードが3つの計算サービス
    サービス 管理ノード 各セカンダリノード
    システム 6GB、2コア 6GB、2コア
    ストレージサービス 1GBと0.2コアの4基のストレージディスク、つまり4GBと0.8コア 1GBと0.2コアの4基のストレージディスク、つまり4GBと0.8コア
    計算 8GB、3コア  
    ロードバランサ 1GB、1コア  
    Kubernetes 2GB、2コア  
    合計 21GBのRAMと8.8コア 10GBのRAMと2.8コア
  • 5つのノード(1基のシステム+ストレージディスクと10基のストレージディスク)があり、それをBackup Gatewayに使用する場合は、以下の計算表を参照してください。計算クラスターがデプロイされていない場合は、管理やセカンダリノードと同じ要件になります。

    表 2.3.2.5 例:ノード5つのBackup Gateway
    サービス 各ノード
    システム 6GB、2コア
    ストレージサービス 1GBと0.2コアの11基のストレージディスク、つまり11GBと2コア
    バックアップゲートウェイ 1GB、2コア
    合計 18GBのRAMと6コア
  • 10個のノード(1基のシステムディスク、1基のキャッシュディスク、3基のストレージディスク)があり、それを計算サービスに使用する場合は、以下の計算表を参照してください。3つのノードは管理ノードの高可用性に使用されるため、各ノードが管理ノードの要件を満たしている必要があります。

    表 2.3.2.6 例:ノードが10個の管理ノードHAを使用する計算サービス
    サービス 各管理ノード 各セカンダリノード
    システム 6GB、2コア 6GB、2コア
    ストレージサービス 1GBと0.2コアの3基のストレージディスク+1基のキャッシュディスク、つまり4GBと0.8コア 1GBと0.2コアの3基のストレージディスク+1基のキャッシュディスク、つまり4GBと0.8コア
    計算 8GB、3コア  
    ロードバランサ 1GB、1コア  
    Kubernetes 2GB、2コア  
    合計 21GBのRAMと8.8コア 10GBのRAMと2.8コア

通常、クラスターに提供するリソースが多いほど、動作が向上します。追加のRAMはすべて、ディスク読み取りのキャッシュに使用されます。さらに、CPUコアを追加するとパフォーマンスが向上し、待機時間が短縮されます。

2.3.3. ハードウェアの推奨事項

通常、Acronis Cyber Infrastructureは、AMD EPYCプロセッサーを含むRed Hat Enterprise Linux 7に推奨されるのと同じハードウェア(サーバーコンポーネント)で動作します。

次の推奨事項では、ハードウェア要件の表に記載されている特定のハードウェアを使用することで得られる利点についてさらに詳しく説明します。これらのハードウェアを使用して、クラスターを最適な方法で構成してください。

2.3.3.1. ストレージクラスターの構成の推奨事項

効率的なストレージクラスターを設計しようとすると、目的に合ったパフォーマンスとコストを実現するためにパフォーマンスとコストの間で折り合いをつける必要があります。このため、ノード数が多く、ノードごとのディスク数が少ないクラスターでは高いパフォーマンスを得られる一方、ノード数が最小(3)で、ノードごとのディスク数が多いクラスターの方がコストが低いことを念頭に置いて計画してください。詳細については、次の表を参照してください。

表 2.3.3.1.1 クラスター構成の推奨事項
設計に関する考慮事項 最小数のノード(3)、ノードごとのディスクは多い 多数のディスク、ノードごとのディスクは少ない(オールフラッシュ構成)
最適化 低コスト。 高パフォーマンス。
確保する空きディスク領域 ノードに障害が発生した場合、そのノードのデータを保存できる正常なノードの数が少ないため、クラスターの再構築用に多くの領域を確保する必要がある。 ノードに障害が発生した場合、そのノードのデータを保存できる正常なノードの数が多いため、クラスターの再構築用に確保する必要がある領域は少ない。
冗長性 イレージャーコーディングの選択肢が少ない。 イレージャーコーディングの選択肢が多い。
クラスターのバランスと再構築のパフォーマンス バランスは悪く、再構築は遅い。 バランスは良く、再構築は速い。
ネットワーク容量 再構築中にクラスターのパフォーマンスを維持するために必要なネットワークの帯域幅は大きい。 再構築中にクラスターのパフォーマンスを維持するために必要なネットワークの帯域幅は小さい。
望ましいデータの種類 コールドデータ(たとえば、バックアップ)。 ホットデータ(たとえば、仮想環境)。
サーバー構成の例 Supermicro SSG-6047R-E1R36L(Intel Xeon E5-2620 v1/v2 CPU、32GB RAM、36 x 12TB HDD、500GBシステムディスク)。 Supermicro SYS-2028TP-HC0R-SIOM(4 x Intel E5-2620 v4 CPU、4 x 16GB RAM、24 x 1.9TB Samsung PM1643 SSD)。

以下の点に注意してください。

  1. これらの考慮事項は、障害のあるドメインがホストの場合にのみ当てはまります。
  2. レプリケーションモードでの再構築の速度は、クラスター内のノード数の影響を受けません。
  3. Acronis Cyber Infrastructureでは、1つのノードにつき数百個のディスクをサポートしています。1つのノードにつき36基以上のディスクを使用する予定の場合は、セールスエンジニアにご相談ください。より効率的なクラスターの設計をサポートします。

2.3.3.2. ハードウェアの一般的な推奨事項

  • 本番環境には少なくとも5つのノードが必要です。これにより、2つのノードで障害が発生しても、クラスターはデータの損失なく耐えられます。
  • Acronis Cyber Infrastructureで最も強力な機能の1つは拡張性です。クラスターが大きくなるほど、Acronis Cyber Infrastructureのパフォーマンスは向上します。本番環境のシナリオで障害回復力、パフォーマンス、およびフォールトトレランスを向上させるために、少なくとも10個のノードで構成される本番クラスターを構築することをお勧めします。
  • クラスターはさまざまなハードウェア上に構築できますが、各ノードで同じようなハードウェアを使用することで、クラスターのパフォーマンス、容量、および全体のバランスを向上させることができます。
  • クラスターのインフラストラクチャは、本番環境に配置する前に広範囲にわたりテストする必要があります。SSDドライブ、ネットワークアダプタのボンドなどの一般的な障害点は、十分に検証する必要があります。
  • 本番環境で、独自の冗長性メカニズムが搭載されたSAN/NASハードウェア上でAcronis Cyber Infrastructureを実行することは推奨しません。そうすると、パフォーマンスとデータの可用性に悪影響が出る可能性があります。
  • 最適なパフォーマンスを実現するために、クラスターの空き容量を20%以上で維持してください。
  • ディザスタリカバリ中、レプリケーションのためにAcronis Cyber Infrastructureに追加のディスク領域が必要になる場合があります。少なくとも1つのストレージノードと同等の領域を確保しておいてください。
  • 各ノードで同じCPUモデルを使用して、VMの稼働中の移行に関する問題を回避することをお勧めします。詳細については、:doc:『管理者コマンドラインガイド<admins_cmd_guide:index>』を参照してください。
  • Backup Gatewayを使用してバックアップをクラウドに保存する計画がある場合は、ローカルストレージクラスターにステージング用の論理領域(バックアップをクラウドに送信する前にローカルで保管するための領域)を十分に用意してください。たとえば、毎日バックアップを実行する場合、少なくとも1.5日分のバックアップを保存するのに十分な領域を確保してください。詳細については、:doc:『管理者ガイド<admins_guide:index>』を参照してください。
  • ハードウェアでサポートされている場合、BIOSではなくUEFIを使用することをお勧めします。NVMeドライブを使用する場合には、特にUEFIの使用をお勧めします。

2.3.3.3. ストレージハードウェアの推奨事項

  • 同じクラスター内でさまざまなサイズのディスクを使用することができます。ただし、IOPSが同じ場合、大きいディスクよりも小さいディスクの方が1テラバイトあたりのデータのパフォーマンスが高くなることを覚えておいてください。1テラバイトあたりのIOPSが同じディスクを同じティアにグループ化することをお勧めします。
  • 推奨のSSDモデルを使用すると、データの損失を回避するのに役立つ可能性があります。一部のSSDドライブではエンタープライズワークロードに対応できず、最初の数ヵ月の運用で故障する可能性があります。その結果、TCOが急増します。
    • SSDのメモリセルで対応できる再書き込みの回数には制限があります。SSDドライブは一定期間が経過したら交換する必要がある消耗品と考えてください。一般消費者向けのSSDドライブで対応できる再書き込みの回数は非常に少ないです(数値は技術仕様書には記載されていませんが、低いです)。ストレージクラスターに使用するSSDドライブには少なくとも1DWPDの耐久性が備わっている必要があります(推奨は10DWPD)。耐久性が高くなるほど、SSDの交換頻度が低くなるため、TCOが向上します。
    • 一般消費者向けのSSDドライブの多くでは、ディスクフラッシュを無視し、データが実際には書き込まれていないのにデータが書き込まれたとオペレーティングシステムに間違って報告する可能性があります。このようなドライブには、OCZ Vertex 3、Intel 520、Intel X25-E、Intel X-25-M G2などがあります。これらのドライブは、データコミットの観点から安全でないことがわかっているため、データベースに使用しないでください。電源の障害が発生した場合、これらのドライブが原因でファイルシステムが簡単に壊れる可能性があります。このような理由から、フラッシュルールに従ったエンタープライズクラスのSSDドライブを使用してください(詳細については、http://www.postgresql.org/docs/current/static/wal-reliability.htmlを参照してください)。適切に動作するエンタープライズクラスのSSDドライブには、通常、技術仕様書に電力損失保護特性が記載されています。この技術は市場では、Enhanced Power Loss Data Protection(Intel)、Cache Power Protection(Samsung)、Power-Failure Support(Kingston)、およびComplete Power Fail Protection(OCZ)などと呼ばれています。
    • ディスクのデータフラッシュ機能の確認で説明しているとおりに、ディスクのデータフラッシュ機能を確認することを強くお勧めします。
    • 一般消費者向けのSSDドライブのパフォーマンスは一般的に不安定であるため、持続性のあるエンタープライズワークロードには適していません。このため、SSDを選択する際は持続可能な負荷テストをしっかり行ってください。
    • SSDディスクのパフォーマンスはサイズによって異なる可能性があります。低容量ドライブ(100~400GB)の速度は高容量ドライブ(1.9~3.8TB)よりも遅い(場合によっては、最大10倍遅い)可能性があります。ハードウェアを購入する前に、ドライブのパフォーマンスと耐久性の仕様をチェックしてください。
  • 書き込みキャッシュにNVMeまたはSAS SSDを使用するとランダムI/Oのパフォーマンスが向上します。iSCSIボリュームなど、ランダムアクセスの多いすべてのワークロードにNVMeまたはSAS SSDを使用することを強くお勧めします。SATAディスクは、書き込みキャッシュを行わないSSDのみの構成に最適です。
  • シングル磁気記録方式(SMR)HDDは使用しないことを強くお勧めします。バックアップシナリオにも使用しないようにしてください。このディスクでは予測できない遅延が発生するため、想定外の一時的なサービス停止が発生したり、パフォーマンスが突然低下したりする可能性があります。
  • SSDでメタデータサービスを実行すると、クラスターのパフォーマンスが向上します。資本支出を最小限に抑えるために、書き込みキャッシュに同じSSDを使用できます。
  • 容量が主な目的で、アクセス頻度の低いデータを保存する必要がある場合は、SASディスクではなくSATAディスクを選択してください。パフォーマンスが主な目的の場合、SATAディスクではなくNVMeまたはSASディスクを選択してください。
  • ノードごとのディスク数を多くすると、設備投資を抑えることができます。たとえば、各ノードに2つのディスクが配置された10個のノードで構成されるクラスターは、各ノードに1つのディスクが配置された20個のノードで構成されるクラスターよりもコストが低くなります。
  • SATA HDDとキャッシュに1つのSSDを使用すると、SSDを使用せずにSAS HDDのみを使用する場合よりもコスト効率が高くなります。
  • それぞれRAIDコントローラまたはHBAコントローラを使用して、システムディスクにハードウェアまたはソフトウェアのRAID1ボリュームを作成し、高いパフォーマンスと可用性を実現します。
  • HBAコントローラーはRAIDコントローラーよりもコストが低く、管理しやすいため、HBAコントローラーを使用します。
  • SSDドライブではRAIDコントローラのすべてのキャッシュを無効にします。最新のSSDには優れたパフォーマンスが備わっていますが、RAIDコントローラの読み書きキャッシュによってパフォーマンスが低下する可能性があります。SSDドライブのキャッシュは無効にし、HDDドライブのキャッシュのみ有効にしておくことをお勧めします。
  • RAIDコントローラを使用する場合、ストレージ用のHDDからRAIDボリュームを作成しないでください。各ストレージHDDは、Acronis Cyber Infrastructureによって個別のデバイスとして認識される必要があります。
  • RAIDコントローラーとキャッシュを使用する場合、コントローラーにバッテリーバックアップ装置(BBU)を搭載し、停電中にキャッシュが失われないようにします。
  • ディスクブロックのサイズ(512b、4Kなど)は重要ではなく、パフォーマンスに影響がありません。

2.3.3.4. ネットワークハードウェアの推奨事項

  • 内部トラフィックとパブリックトラフィックには個別のネットワーク(最適動作のためには任意で個別のネットワークアダプタ)を使用します。そうすることで、パブリックトラフィックがクラスターのI/Oパフォーマンスの影響を受けないようにしたり、外部からのDoS攻撃を阻止したりできます。
  • ネットワークの遅延によってクラスターのパフォーマンスは大幅に低下します。低遅延リンクを備えた高品質のネットワーク機器を使用します。一般消費者向けのネットワークスイッチは使用しないでください。
  • Intel EXPI9301CTBLK、Realtek 8129などのデスクトップネットワークアダプタは、高い負荷に対応するように設計されておらず、全二重リンクをサポートしていない可能性があるため、使用しないでください。また、ノンブロッキングイーサネットスイッチは使用しないでください。
  • 侵入を阻止するために、Acronis Cyber Infrastructureは外部からアクセスできない専用の内部ネットワークに配置する必要があります。
  • ノード上の2つのHDDごとに1つの1Gbit/秒リンクを使用してください(切り上げ)。ノード上の1つまたは2つのHDDごとに、2つのボンド接続されたネットワークインターフェースを使用して、ネットワークの可用性を高めることをお勧めします。これを推奨する理由は、1Gbit/秒のイーサネットネットワークでは110~120MB/秒のスループットを実現できるためです。このスループットは、1つのディスクのシーケンシャルI/Oのパフォーマンスに近い数値です。サーバー上の一部のディスクでは単一の1Gbit/秒イーサネットリンクよりも高いスループットを実現できるため、ネットワークがボトルネックになる可能性があります。
  • シーケンシャルI/Oのパフォーマンスを最大限に高めるために、ハードドライブごとに1つの1Gbit/秒リンクを使用するか、ノードごとに1つの10Gbit/秒リンクを使用します。実際のシナリオではほとんどの場合、I/O操作はランダムですが、シーケンシャルI/Oはバックアップシナリオで重要です。
  • 全体のパフォーマンスを最大限に高めるために、ノードごとに1つの10Gbit/秒リンク(または、ネットワークの可用性を高めるために2つのボンド接続)を使用します。
  • デフォルト値以外のMTU(9000バイトのジャンボフレームなど)を使用するように1Gbit/秒のネットワークアダプタを設定することは推奨されていません。このような設定には、スイッチの追加構成が必要になり、多くの場合、ヒューマンエラーを引き起こします。一方で、パフォーマンスを最大限に高めるためにはジャンボフレームを使用するように10Gbit/秒以上のネットワークアダプタを設定する必要があります。
  • 現在サポートされているファイバーチャネルホストバスアダプタ(HBA)はQLogic QLE2562-CKおよびQLogic ISP2532です。
  • Mellanox ConnectX-4とConnectX-5 InfiniBandアダプタを使用することをお勧めします。Mellanox ConnectX-2とConnectX-3カードはサポートされていません。
  • BNX2Xドライバを使用するアダプタ(Broadcom Limited BCM57840 NetXtreme II 10/20ギガビットイーサネット / HPE FlexFabric 10Gb 2ポート536FLBアダプタ等)は推奨されません。これらはMTUの上限が3616に制限されており、クラスターのパフォーマンスに影響が出ます。

2.3.4. ハードウェアとソフトウェアの制限事項

ハードウェアの制限事項:

  • 各管理ノードには少なくとも2基のディスクが必要です(システムとメタデータ用に1基、ストレージ用に1基)。
  • 各セカンダリノードには少なくとも3基のディスクが必要です(システム用に1基、メタデータ用に1基、ストレージ用に1基)。
  • 3つのサーバーで製品のすべての機能をテストする必要があります。
  • システムディスクには少なくとも100GBの空き領域が必要です。
  • 管理者パネルを正しく表示するためにはフルHDモニタが必要です。
  • サポートされる物理パーティションの最大サイズは254TiBです。

ソフトウェアの制限事項:

  • 1つのノードは1つのクラスターにのみ追加できます。
  • ストレージクラスターには1つのS3クラスターしか作成できません。
  • 管理者パネルでは事前定義済みの冗長性モードのみを使用できます。
  • シンプロビジョニングはすべてのデータに対して必ず有効にします。そうしない場合、設定できません。
  • 管理者パネルの動作は、1280x720以上の解像度において、Firefox、Chrome、およびSafariのWebブラウザの最新版でテストされました。

ネットワークの制限事項については、ネットワークの制限事項を参照してください。

2.3.5. 最小ストレージ構成

次の表にある最小ストレージ構成で、ストレージクラスターの機能を評価できます。本番環境用ではありません。

表 2.3.5.1 最小クラスター構成
ノード番号 最初のディスクロール 2番目のディスクロール 3番目のディスクロール アクセスポイント
1 システム メタデータ ストレージ iSCSI、S3プライベート、S3パブリック、NFS、Backup Gateway
2 システム メタデータ ストレージ iSCSI、S3プライベート、S3パブリック、NFS、Backup Gateway
3 システム メタデータ ストレージ iSCSI、S3プライベート、S3パブリック、NFS、Backup Gateway
合計で3つのノード   合計で3つのMDS 合計で3つ以上のCS アクセスポイントサービスは合計で3つのノードで実行されます。

注釈

SSDディスクにシステムメタデータ、およびキャッシュのロールを同時に割り当て、ストレージロールにより多くのディスクを確保することができます。

最小構成の推奨ノード数は3ですが、1つのノードでAcronis Cyber Infrastructureの評価を開始し、後からノードを追加することもできます。少なくとも、ストレージクラスターでは1つのメタデータサービスと1つのチャンクサービスを実行する必要があります。単一ノードのインストール環境では、iSCSI、Backup Gatewayなどのサービスを評価できます。ただし、このような構成には次の2つの制限事項があります。

  1. 1つのMDSが単一障害点になります。このサービスで障害が発生した場合、クラスター全体の動作が停止します。
  2. 1つのCSでは1つのチャンクレプリカのみを保存できます。このサービスで障害が発生した場合、データは失われます。

重要

Acronis Cyber Infrastructureを1つのノードにデプロイする場合は、データ損失を回避するためにストレージの永続性と冗長性を確保する必要があります。ノードが物理ノードの場合、ディスク間でデータをレプリケートできるように複数のディスクを用意する必要があります。ノードが仮想マシンの場合、このVMが動作しているソリューションによってこのVMが高可用性になっていることを確認します。

注釈

Backup Gatewayはステージングモードでローカルのオブジェクトストレージとやり取りします。つまり、パブリッククラウドにレプリケート、移行、またはアップロードされるデータは最初にローカルに保存された後で、目的地に送信されます。ローカルデータが失われないように、ローカルのオブジェクトストレージの永続性と冗長性を確保することが重要です。ローカルストレージの永続性と冗長性を確保する方法は複数あります。Backup Gatewayを複数のノードに配置して、優れた冗長性モードを選択できます。ゲートウェイをAcronis Cyber Infrastructure内の単一ノードに配置する場合、複数のローカルディスク間でストレージをレプリケートすることでストレージを冗長化できます。ゲートウェイを作成する目的でのみ1つの仮想マシン内にAcronis Cyber Infrastructureインストール環境全体を配置する場合、このVMが動作しているソリューションによってこのVMが高可用性になっていることを確認します。

2.3.7. RAWディスク領域の考慮事項

インフラストラクチャを計画するときは、次の点に注意して混乱しないようにしてください。

  • HDDとSSDの容量は、2進接頭辞ではなく、10進法で測定および記載されるため、ディスクの仕様書の「TB」は通常、「テラバイト」を意味します。ただし、オペレーティングシステムでは、2進接頭辞を使用してドライブの容量を表すため、「TB」は「テビバイト」を意味し、著しく大きい数値になります。このため、ベンダーが販売時に示した数値よりも小さいディスク容量が示される場合があります。たとえば、仕様書に6TBと記載されているディスクの場合、Acronis Cyber Infrastructureでは実際のディスク領域が5.45TBであると示される可能性があります。
  • 5%のディスク領域は緊急時のために確保されています。

このため、6TBのディスクをクラスターに追加した場合、使用できる物理的な領域は約5.2TB増えるはずです。

2.3.8. ディスクのデータフラッシュ機能の確認

クラスターに追加する予定のすべてのストレージドライブに、想定外の停電が発生した場合にキャッシュからディスクにデータをフラッシュできる機能が備わっているかどうかを確認することを強くお勧めします。確認することで、電源の障害が発生した場合にデータが失われる可能性があるデバイスを見つけることができます。

Acronis Cyber Infrastructureには、ストレージドライブで緊急時にデータをどのようにディスクにフラッシュするのかを確認するvstorage-hwflush-checkツールが付属しています。このツールはクライアント/サーバーユーティリティとして実装されています。

  • クライアントは、データのブロックを継続的にストレージドライブに書き込みます。データのブロックが書き込まれると、クライアントは特別なカウンタの値を増やし、カウンタを保管するサーバーに送信します。
  • サーバーはクライアントから送信されたカウンタを記録し、カウンタの次の数値を常に認識しています。サーバーがその数値よりも小さいカウンタを受け取った場合(電源に障害が発生してストレージドライブがキャッシュデータをディスクにフラッシュしなかったためなど)、サーバーはエラーを報告します。

電源に障害が発生したときにストレージドライブでデータをディスクに適切にフラッシュできるかどうかを確認するには、次の手順を実行します。

  1. 1つのノードでサーバーを実行します。

    # vstorage-hwflush-check -l
    
  2. テストするストレージドライブをホストする別のノードで、次のようにクライアントを実行します。例:

    # vstorage-hwflush-check -s vstorage1.example.com -d /vstorage/stor1-ssd/test -t 50
    

    ここで、

    • vstorage1.example.comはサーバーのホスト名です。
    • /vstorage/stor1-ssd/testはデータフラッシュテストに使用するディレクトリです。実行中、クライアントによってこのディレクトリにファイルが作成され、データブロックがそのファイルに書き込まれます。
    • 50は、クライアントがデータをディスクに書き込むスレッドの数です。各スレッドには独自のファイルとカウンタがあります。より負荷の高い状態でシステムをテストするためにスレッドの数を(最大200まで)増やすことができます。また、クライアントを実行しているときに他のオプションを指定できます。使用できるオプションの詳細については、vstorage-hwflush-checkのマニュアルを参照してください。
  3. 10~15秒程度待ってから、クライアントノードの電源を切断し([電源] ボタンを押すか、電源コードを抜く)、再び電源を入れます。

  4. クライアントを再起動します。

    # vstorage-hwflush-check -s vstorage1.example.com -d /vstorlage/stor1-ssd/test -t 50
    

起動したら、クライアントは以前に書き込まれたすべてのデータを読み取り、ディスク上のデータのバージョンを確認し、最後の有効なカウンタからテストを再開します。その後この有効なカウンタをサーバーに送信し、サーバーはそのカウンタをサーバー上の最新のカウンタと比較します。次のような出力が表示されます。

id<N>:<counter_on_disk> -> <counter_on_server>

これは次のいずれかであることを意味します。

  • ディスク上のカウンタがサーバー上のカウンタよりも小さい場合、ストレージドライブはデータをディスクにフラッシュできなかったことを意味します。データを失う可能性があるため、特にCSやジャーナルには本番環境でこのストレージドライブを使用しないようにします。
  • ディスク上のカウンタがサーバー上のカウンタよりも大きい場合、ストレージドライブはデータをディスクにフラッシュしたが、クライアントがサーバーに報告できなかったことを意味します。ネットワークが遅すぎるか、設定した負荷スレッドの数ではストレージドライブが速すぎる可能性があるため、負荷スレッドの数を増やすことを検討してください。このストレージドライブは本番環境で使用できます。
  • 両方のカウンタが等しい場合、ストレージドライブはデータをディスクにフラッシュし、クライアントはサーバーに報告したことを意味します。このストレージドライブは本番環境で使用できます。

念のため、この手順を複数回繰り返します。最初のストレージドライブを確認したら、クラスターで使用する予定の残りのすべてのデバイスでこの手順を実行します。クラスターで使用する予定のすべてのデバイスをテストする必要があります。それには、CSジャーナリングに使用するSSDディスク、MDSジャーナルとチャンクサーバーに使用するディスクが含まれます。