メインコンテンツにスキップ
バージョン: 3.1

リファレンス・アーキテクチャ

デプロイメントのスケーリング​

CubeCOSは、インフラストラクチャのニーズの拡大に合わせて効率的に拡張できるよう設計されています。 稼働中のサービスを中断することなく、コンピューティング、ストレージ、または管理リソースを追加または削除できます。 • すべてのノードロールにわたる水平スケーリングに対応 • コンピューティングおよびストレージ容量のダウンタイムなしでの拡張が可能 • 柔軟なノード構成により、変化するワークロードに対応

この柔軟性により、クラスターは常に高い応答性と効率性を維持し、変化する運用要件に対応し続けることができます。

CubeCOS クラスタのスケーリング​

CubeCOSインフラストラクチャを拡張することで、ダウンタイムを発生させることなく、変化するワークロードの需要に環境を適応させることができます。 CubeCOSは、コンピューティング、ストレージ、および制御サービスにおいて、システムを停止させることなく水平スケーリングを行うことをサポートしています。 このセクションでは、展開を拡大する際の主な考慮事項を概説し、ベストプラクティスを分かりやすく示す図を掲載しています。

スケーリングに関する注意点​

CubeCOSインフラストラクチャを拡張することで、ダウンタイムを発生させることなく、変化するワークロードの需要に環境を適応させることができます。 CubeCOSは、コンピューティング、ストレージ、および制御サービスにおいて、システムを停止させることなく水平スケーリングを行うことをサポートしています。 このセクションでは、展開を拡大する際の主な考慮事項を概説し、ベストプラクティスを分かりやすく示す図を掲載しています。

同じCPU世代のコンピュートノードまたはコンピュート・ウィズ・ストレージノードを追加する​

既存のノードと同じCPUモデルを持つノードを追加するのが、最も簡単な方法です。 完全な互換性を確保し、シンプルで段階的な拡張を可能にします。 • CPU命令セットの不一致による問題を回避 • シングルノードでの拡張に対応 • ワークロードのバランスと高可用性を維持

異なるCPU世代のコンピュートノードまたはコンピュート・ウィズ・ストレージノードを追加する​

新しい世代のCPUを使用する場合は、少なくとも2つのノードを展開し、それらを別々にグループ化することをお勧めします。 このアプローチにより、高可用性（HA）が確保され、世代間のCPUの問題を回避できます。 • 新しいノード間で高可用性（HA）を実現します • 既存のノードと新しいノードは、別々のアベイラビリティゾーンに配置する必要があります • ワークロードのスケジューリング互換性を確保し、CPU命令の相違による影響を隔離します

専用ストレージノードの追加​

専用のストレージノードを追加することで、ストレージ容量を拡張できます。 ただし、ストレージプールの設計においては、冗長性と耐障害性を考慮しなければならない。 • 互換性のあるハードウェアにより、既存のストレージプールをシームレスに拡張できます • 2ノードのプールもサポートされていますが、データレプリカは2つしか提供されません • 完全なフォールトトレランスとデータ可用性を確保するには、3ノードのプールが推奨されます

既存のAIOデプロイメントのスケーリング​

オールインワン（AIO）展開は、3つの制御統合ノードで構成される、CubeCOSクラスタ構成の中で最も小規模なものです。 これらのノードは、単一の筐体内で制御、演算、ストレージ、およびネットワーク機能を処理します。

リソース需要の増加に伴い、AIOクラスターは、必要な拡張の種類に応じて、ストレージ付きコンピュートノードまたはコンピュート専用ノードを追加することで、サービスを中断することなくスケールアップできます。

シナリオ 1: ストレージ付きコンピュートノードによる拡張​

このオプションにより、クラスターは演算能力とストレージ容量の両方を拡張できるため、リソースのバランスのとれた拡張を必要とするワークロードに適しています。 • クラスターに演算能力と追加のストレージを提供します • 既存のリソースプールに自動的に統合されます • VM やコンテナのワークロード、およびストレージ使用量が増加している環境に最適です • 高可用性（HA）機能の継続的な利用をサポートします

シナリオ 2: 演算専用ノードによる拡張​

CPUやメモリの増強が必要だが、現在のストレージ容量には問題がない場合は、演算専用ノードを追加することができます。 • ストレージを増設することなく、コンピューティングリソースを追加できます • 新規ノードは既存のストレージインフラストラクチャを利用します • I/O要件が低い仮想マシン、コンテナ、またはアプリケーションのスケーリングに適しています • ストレージの過剰なプロビジョニングを回避しつつ、リソースの割り当てを最適化できます

既存のHCI環境の拡張​

HCI（ハイパーコンバージド・インフラストラクチャ）の導入構成は、通常、3つの制御ノードと、2～3つのストレージ付きコンピュートノードで構成されます。 この構成は、コンピューティング、ストレージ、および管理サービスのためのバランスのとれた基盤を提供します。

需要の増加に伴い、HCIクラスタは、具体的なワークロードの要件に応じて、ストレージ付きコンピュートノード、コンピュート専用ノード、または専用ストレージノードを追加して拡張することができます。

クラスタに新しいノードを追加することで、既存のノードからワークロードやホストをライブマイグレーションできるようになり、スケーリング時のサービス停止時間を最小限に抑えるか、あるいは完全に排除することができます。

スケーリングのオプション

  1. ストレージノード付きのComputeノードを追加する

1つの手順で、演算能力とストレージ容量の両方を拡張します。 • 汎用ワークロードの拡張に適しています • 仮想マシン、コンテナ、永続ストレージの既存プールに新しいリソースを追加します • コンピューティングとストレージのバランスを確実に保ちます

  1. 「演算専用ノード」を追加する

ストレージに影響を与えることなく、CPUとメモリのリソースを増加させます。 • ストレージ要件よりもコンピューティング需要の増加が速い場合に最適です • 新しいコンピューティングノードは、既存の共有ストレージプールを利用します • 既存のストレージ投資を最適化することでコストを削減します

  1. 専用ストレージノードを追加する

演算能力を維持したまま、ストレージ容量全体を拡大します。 • バックアップ、アーカイブ、または高スループットアプリケーションなど、ストレージを多用するワークロードに推奨されます • ハードウェアの種類に応じて、既存のストレージプールを拡張したり、新しいプールを作成したりできます • 最適なデータ保護と耐障害性を実現するために、3ノードのストレージプールを使用してください

既存のWebスケール展開のスケーリング​

Webスケールの展開では、演算、ストレージ、および制御の各役割が専用のノードに分離されます。 このロールベースの分離により、大規模な環境においても効率的なリソース管理とワークロードの分離が可能になります。

増大するインフラ需要に対応するため、演算能力とストレージ容量は個別に拡張可能です。 この柔軟性により、プライベート／ハイブリッドクラウド、AI／ML、コンテナオーケストレーション環境など、大規模なワークロードに対応できます。

スケーリングオプション​

  1. コンピュートノードを追加する

ストレージや管理サービスに影響を与えることなく、クラスタの処理能力を拡張します。 • VM密度の向上やコンテナワークロードのスケーリングに対応 • AI、GPUを多用するタスク、または高性能コンピューティングタスクに最適 • 新しいコンピュートノードは、既存の制御およびストレージサービスと統合されます

  1. ストレージノードを追加する

ステートフルなワークロードや高スループットのデータ処理向けに、永続ストレージの容量を拡張します。 • データ量の多いアプリケーションや、大規模なオブジェクト/ブロックストレージの利用に最適 • 新しいノードを追加することで、既存のストレージプールを拡張したり、新しいストレージプールを作成したりできます • 高可用性とデータの冗長性を確保するため、ストレージプールごとに最低3つのノードを維持してください

導入に関する注意事項​

このセクションでは、CubeCOSクラスタを構築するためのハードウェア要件とベストプラクティスについて概説します。 適切なサイジングは、パフォーマンス、可用性、および将来の拡張性にとって不可欠です。

CubeCOSは、各ノードの役割に対するリソース予約量を推定するためのクラスタサイジングツールキットを提供しています。 このツールは、ワークロードの要件に基づいて、必要なCPU、メモリ、およびストレージ容量を算出するのに役立ちます。

プロセッサ（CPU）​

プロセッサの選定は、各ノードの役割に応じた想定される計算負荷に見合うものでなければなりません。 CPU要件は、展開タイプや各ノードで実行されるサービスによって異なります。

  • 想定されるワークロードの規模と仮想化密度に適したCPUを使用してください
  • ノード間でCPUモデルを統一し、互換性の問題を回避する
  • 推奨される最小CPU仕様については、ハードウェア仕様のセクションを参照してください
  • 高可用性（HA）を実現するには、コンピュートノードのハードウェア仕様が同一であることを確認し、ハードウェア支援型仮想化に対応していることを確認してください

メモリ​

メモリは、インフラストラクチャのオーバーヘッドとワークロード固有の要件の両方を満たす必要があります。 ストレージ関連のサービスやクラスタの運用には、追加のメモリ予約が必要になる場合があります。

  • OS、コントロールプレーン、およびSDS機能をサポートするために、最低限のメモリが必要です
  • Ceph OSDのパフォーマンスを最適化するには、ストレージデバイスごとに4 GBのメモリを確保してください
  • 仮想マシン、コンテナ、およびサービスの数によっては、追加のメモリが必要になる場合があります
  • Intel Optane Memory モジュールはサポートされていません

ストレージ​

CubeCOSは、ソフトウェア定義の分散型ストレージとしてCephを採用しています。 信頼性の高いストレージ性能を実現するには、適切なコントローラとメディアの選択が不可欠です。

  • 標準的なストレージ構成では、HBA（ホストバスアダプタ）モードを使用してください
  • 複雑さを軽減するため、混合モードコントローラ（RAID + パススルー）は避けてください
  • NVMeドライブはコントローラーを必要とせず、ネイティブでサポートされています
  • 対応メディア形式：
  • NVMe（U.2、M.2）
  • NL-SAS
  • SAS SSD/HDD
  • SATA SSD/HDD
  • 高速フラッシュメディアをキャッシュ用、回転ディスクを大容量用として使用するハイブリッドストレージ構成がサポートされています
  • 推奨キャッシュ対ストレージ比率：1:10（実容量）
  • ブートディスクには、Dell BOSS や HPE NVMe ホットプラグなどの、サポートされている冗長ブートソリューションを使用してください。

ネットワーク​

信頼性が高く、高スループットなネットワークは、CubeCOSクラスタの健全性とパフォーマンスにとって不可欠です。 これには、内部トラフィックとユーザー向けのワークロードの両方が含まれます。

  • リンクアグリゲーションには、高速レートとレイヤー3+4ハッシュを使用したLACP（802.3ad）を採用する
  • 推奨されるネットワークインターフェースの速度は、ワークロードやストレージのパフォーマンスによって異なります
  • NVMe環境では25 Gbps以上
  • 大規模なNVMe環境やレイテンシに敏感なNVMeのユースケースでは、100 Gbpsが推奨されます
  • 小規模な環境では、すべてのトラフィックをデュアルポートの10 Gbps NIC経由で処理できます
  • 高スループットの環境では、以下の方法を用いてトラフィックの種類を区別します：
  • VLANトランキング（単一インターフェース）
  • 専用の物理インターフェース（コンプライアンスや分離のため）
  • 推奨される航路分離：
  • 経営
  • ユーザーアクセス
  • データのクラスタリング
  • ストレージバックエンド
  • ネットワーク構成を、社内トポロジーやコンプライアンス要件に合わせて調整する