2 ハードウェア要件と推奨事項 #
Cephのハードウェア要件は、IOワークロードに大きく依存します。次のハードウェア要件と推奨事項は、詳細な計画を立てる際の起点と考えてください。
一般的に、このセクションで説明する推奨事項はプロセスごとの推奨事項です。同じマシンに複数のプロセスがある場合は、CPU、RAM、ディスク、およびネットワークの各要件を追加する必要があります。
2.1 ネットワーク概要 #
Cephには次のような論理ネットワークが含まれます。
パブリックネットワークと呼ばれるフロントエンドのネットワーククラスタネットワークと呼ばれる、バックエンドの信頼済み内部ネットワークこれは必要な場合のみ指定してください。1つ以上のゲートウェイ用クライアントネットワーク。これは必要な場合のみ指定してください。また、この章では扱いません。
パブリックネットワークはCephデーモンが他のCephデーモンやクライアントと通信するネットワークです。つまり、クラスタネットワークが構成されている場合を除き、すべてのCephクラスタのトラフィックはこのパブリックネットワークを通ります。
クラスタネットワークはOSDノード間のバックエンドネットワークであり、レプリケーション、再バランシング、リカバリに使用されます。このオプションのネットワークを構成した場合、理論上、デフォルトの3方向レプリケーションを使用するパブリックネットワークの2倍の帯域幅が生まれます。これは、プライマリOSDが2つのコピーを他のOSDに送る際に、このネットワークを使用するためです。一方、パブリックネットワークはクライアントとゲートウェイ間のネットワークであり、Monitor、マネージャ、MDSノード、OSDノードとの通信に使用されます。パブリックネットワークはMonitor、マネージャ、MDSノードがOSDノードと通信する際にも使用されます。
2.1.1 ネットワーク推奨事項 #
十分に要件を満たせるような帯域幅を備えた、フォールトトレラントな単一のネットワークをお勧めします。Cephパブリックネットワーク環境では、802.3ad (LACP)を使用してボンディングされた2つの25GbE (またはそれ以上)のネットワークインターフェイスをお勧めします。この環境がCephの最小セットアップとみなされます。クラスタネットワークを使用する場合、25GbEのネットワークインターフェイスを4つボンディングすることをお勧めします。2つ以上のネットワークインターフェイスをボンディングすることで、リンクアグリゲーションによりスループットが改善されます。さらに、リンクとスイッチに冗長性が与えられるため、耐障害性と保守性が向上します。
VLANを作成することで、ボンディングした機器を通過する異なるタイプのトラフィックを分離することもできます。たとえば、1つはパブリックネットワーク用、もう1つはクラスタネットワーク用として、計2つのVLANインターフェイスを提供するようにボンディングを設定できます。しかしながら、これはCephネットワークを構成する際の必須事項ではありません。ネットワークインターフェイスのボンディングの詳細については、https://documentation.suse.com/sles/15-SP3/html/SLES-all/cha-network.html#sec-network-iface-bondingを参照してください。
耐障害性はコンポーネントを障害ドメインに隔離することで強化できます。ネットワークの耐障害性を改善する目的で、別々のネットワークインターフェイスカード(NIC)2枚を1つのインターフェイスにボンディングすると、単一のNICの障害に対する保護が提供されます。同様に、2つのスイッチをボンディングすると、単一のスイッチの障害に対する保護が提供されます。必要なレベルの耐障害性を構築するために、ネットワーク機器のベンダーに相談することをお勧めします。
管理ネットワークのセットアップ(たとえば、分離されたSSH、Salt、またはDNSのネットワーク形成を可能とするもの)の追加はテストされておらず、サポート対象外です。
ストレージノードがDHCP経由で設定されている場合、さまざまCephデーモンが起動する前にネットワークを正しく設定するのにデフォルトのタイムアウトでは十分でないことがあります。この場合、CephのMONとOSDを正常に起動できません(systemctl status ceph\*を実行すると「unable to bind」エラーになります)。この問題を回避するには、ストレージクラスタの各ノードでDHCPクライアントのタイムアウト時間を少なくとも30秒まで延ばすことをお勧めします。このためには、各ノードで以下の設定を変更します。
/etc/sysconfig/network/dhcpで、以下を設定します。
DHCLIENT_WAIT_AT_BOOT="30"
/etc/sysconfig/network/configで、以下を設定します。
WAIT_FOR_INTERFACES="60"
2.1.1.1 実行中のクラスタにプライベートネットワークを追加 #
Cephの展開中にクラスタネットワークを指定しない場合、単一のパブリックネットワーク環境と想定されます。Cephはパブリックネットワークで問題なく動作しますが、2つ目のプライベートクラスタネットワークを設定すると、パフォーマンスとセキュリティが向上します。2つのネットワークをサポートするには、各Cephノードに少なくとも2つのネットワークカードが必要です。
各Cephノードに以下の変更を適用する必要があります。これらの変更は、小規模なクラスタの場合は比較的短時間で済みますが、数百または数千のノードで構成されるクラスタの場合は非常に時間がかかる可能性があります。
次のコマンドを使用して、クラスタネットワークを設定します。
#ceph config set global cluster_network MY_NETWORKOSDを再起動し、指定したクラスタネットワークにバインドします。
#systemctl restart ceph-*@osd.*.serviceプライベートクラスタネットワークがOSレベルで想定どおりに動作していることを確認します。
2.1.1.2 異なるサブネット上のモニタノード #
モニタノードが複数のサブネット上に存在する場合(たとえば、別の部屋に配置されていたり、別のスイッチによってサービスを提供されていたりする場合)、CIDR表記でパブリックネットワークアドレスを指定する必要があります。
cephuser@adm > ceph config set mon public_network "MON_NETWORK_1, MON_NETWORK_2, MON_NETWORK_N以下に例を示します。
cephuser@adm > ceph config set mon public_network "192.168.1.0/24, 10.10.0.0/16"
このセクションで説明するように、パブリックネットワーク(またはクラスタネットワーク)用に複数のネットワークセグメントを指定する場合、これらのサブネットはいずれも他のすべてのサブネットにルーティングできる必要があります。さもなければ、異なるネットワークセグメント上に存在するMONなどのCephデーモンが通信できず、クラスタが分割されてしまいます。また、ファイアウォールを使用している場合、必要に応じて、iptablesに各IPアドレスやサブネットを含め、すべてのノードでこれらのアドレスに対してポートを開放したかを確認してください。
2.2 複数のアーキテクチャの設定 #
SUSE Enterprise Storageでは、x86とArmの両方のアーキテクチャをサポートしています。各アーキテクチャを検討する際は、OSDあたりのコア数、周波数、およびRAMの観点から見ると、サイジングに関して、CPUアーキテクチャ間に実質的な差異はないことに注意することが重要です。
小型のx86プロセッサ(サーバ以外)と同様に、パフォーマンスの低いArmベースのコアは、特にイレージャコーディングプールに使用する場合は最適なエクスペリエンスを提供できない可能性があります。
このドキュメントでは、x86やArmと書く代わりにSYSTEM-ARCHと表記します。
2.3 ハードウェア設定 #
最高のプロダクトエクスペリエンスのために、推奨されるクラスタ構成から始めることをお勧めします。テスト用クラスタや、それほどパフォーマンスが要求されないクラスタのために、サポートされる最小限のクラスタ設定を記載しています。
2.3.1 最小クラスタ構成 #
最小限の運用クラスタは、次のような構成です。
サービスを共同配置した、最低でも4つの物理ノード(OSDノード)
ボンディングされたネットワークを構成する、デュアルポート10Gb Ethernet
分離された管理ノード(外部ノードに仮想化してもよい)
詳細な構成は以下の通りです。
4GBのRAM、4コア、1TBのストレージ容量を備えた別個の管理ノード。これは通常、Salt Masterノードです。Ceph Monitor、メタデータサーバ、Ceph OSD、Object Gateway、NFS GaneshaなどのCephサービスとゲートウェイは管理ノードではサポートされません。これは、管理ノードがクラスタの更新をオーケストレートし、個別にプロセスをアップグレードする必要があるためです。
それぞれ8つのOSDディスクを備えた、最低でも4つの物理OSDノード。要件は2.4.1項 「Minimum requirements」を参照してください。
クラスタの合計容量は、1つのノードが使用不能になることを想定したサイズとする必要があります。また、使用済み容量(冗長分を含む)の合計が80%を超えないようにする必要があります。
3つのCeph MonitorインスタンスMonitorはレイテンシの問題からHDDではなくSSD/NVMeストレージから実行する必要があります。
Monitor、メタデータサーバ、ゲートウェイは同じOSDノードに配置できます。Monitorの共同配置については、2.12項 「OSDとモニタでの1台のサーバの共有」を参照してください。サービスを共同配置する場合、メモリとCPUの要件を積み増す必要があります。
iSCSI Gateway、Object Gateway、メタデータサーバは最低でも4GBのRAMと4コアの追加が必要です。
CephFS、S3/Swift、iSCSIを使用する場合、冗長性と可用性を確保するため、それに応じた役割のインスタンス(メタデータサーバ、Object Gateway、iSCSI)が最低でも2つ必要です。
ノードはSUSE Enterprise Storage専用とし、他のいかなる物理的ワークロード、コンテナ化ワークロード、仮想化ワークロードにも使用しないでください。
VM上になんらかのゲートウェイ(iSCSI、Object Gateway、NFS Ganesha、メタデータサーバなど)が展開される場合、こうしたVMをクラスタの他の役割を担う物理マシンにホストしないでください(ゲートウェイは共同配置サービスとしてサポートされているため、これは不要です)。
コアとなる物理クラスタの外のハイパーバイザでサービスをVMとして展開する場合、障害ドメインは冗長性の確保を考慮する必要があります。
たとえば、同じハイパーバイザに同じタイプの複数の役割(複数のMONやMDSインスタンスなど)を展開しないでください。
VM上に展開する場合、優れたネットワーク接続性と上手く動作する時刻同期機能をノードに持たせることがきわめて重要です。
ハイパーバイザノードは、他のワークロードがCPU、RAM、ネットワーク、ストレージなどのリソースを消費することによる干渉を避けるため、適切なサイズにする必要があります。
2.3.2 運用クラスタの推奨設定 #
クラスタを拡張した場合、耐障害性を高めるため、Ceph Monitor、メタデータサーバ、ゲートウェイを別々のノードに再配置することをお勧めします。
7つのオブジェクトストレージノード
1つのノードが最大で合計ストレージの15%を超えないこと。
クラスタの合計容量は、1つのノードが使用不能になることを想定したサイズとする必要があります。また、使用済み容量(冗長分を含む)の合計が80%を超えないようにする必要があります。
内部クラスタと外部パブリックネットワークをそれぞれボンディングする、25Gb Ethernet(またはそれ以上)。
Storage Clusterあたり56以上のOSD
推奨設定の詳細については2.4.1項 「Minimum requirements」を参照してください。
専用の物理インフラストラクチャノード
3つのCeph Monitorノード: 4GBのRAM、4コアプロセッサ、ディスク用のRAID 1 SSD。
推奨設定の詳細については2.5項 「Monitorノード」を参照してください。
Object Gatewayノード: 32GBのRAM、8コアプロセッサ、ディスク用のRAID 1 SSD。
推奨設定の詳細については2.6項 「Object Gatewayノード」を参照してください。
iSCSI Gatewayノード: 16GBのRAM、8コアプロセッサ、ディスク用のRAID 1 SSD。
推奨設定の詳細については2.9項 「iSCSI Gatewayノード」を参照してください。
メタデータサーバノード(アクティブ x 1/ホットスタンバイ x 1): 32GBのRAM、8コアプロセッサ、ディスク用のRAID 1 SSD。
推奨設定の詳細については2.7項 「メタデータサーバノード」を参照してください。
1つのSES管理ノード: 4GBのRAM、4コアプロセッサ、ディスク用のRAID1 SSD。
2.3.3 マルチパス設定 #
マルチパスハードウェアを使用したい場合、設定ファイルのdevicesセクションでLVMがmultipath_component_detection = 1を認識するようにしてください。この設定は、lvm configコマンドで確認できます。
もしくは、LVMのフィルタ設定により、LVMがデバイスのmpathコンポーネントをフィルタするようにしてください。これはホスト固有です。
この方法はお勧めしません。multipath_component_detection = 1を設定できない場合にのみ検討する必要があります。
マルチパス設定の詳細については、https://documentation.suse.com/sles/15-SP3/html/SLES-all/cha-multipath.html#sec-multipath-lvmを参照してください。
2.4 オブジェクトストレージノード #
2.4.1 Minimum requirements #
次のCPUの推奨事項は、Cephによる使用とは関係なくデバイスを考慮しています。
スピナあたり1つの2GHz CPUスレッド
SSDあたり2つの2GHz CPUスレッド
MVMeあたり4つの2GHz CPUスレッド
独立した10GbEネットワーク(パブリック/クライアントおよび内部)。4つの10GbEが必須、2つの25GbEを推奨。
必要なRAMの合計 = OSDの数 x (1GB +
osd_memory_target) + 16GBosd_memory_targetの詳細については、28.4.1項 「自動キャッシュサイズ調整の設定」を参照してください。JBOD設定または個々のRAID-0設定のOSDディスク。
OSDジャーナルはOSDディスクに配置可能。
OSDディスクはSUSE Enterprise Storage専用である必要があります。
オペレーティングシステム専用のディスクおよびSSD(できればRAID 1設定)。
このOSDホストがキャッシュ階層化用のキャッシュプールの一部をホストする場合、最低でも4GBのRAMを追加で割り当て。
Ceph Monitor、ゲートウェイ、およびメタデータサーバはオブジェクトストレージノードに配置可能。
ディスク性能の理由から、OSDノードはベアメタルノードです。Ceph MonitorとCeph Managerの最小セットアップを除き、OSDノードで他のワークロードを実行しないでください。
ジャーナル用のSSD(SSDジャーナルとOSDの比率は6:1)。
OSDノードにiSCSIやRADOS Block Deviceなどのネットワークブロックデバイスがマッピングされていないことを確認してください。
2.4.2 最小ディスクサイズ #
OSD上で実行する必要があるディスク領域には2つのタイプがあります。WAL/DBデバイス用の領域と、保存データ用のプライマリ領域です。WAL/DBの最小値(デフォルト値)は6GBです。データ用の最小領域は5GBです。これは、5GB未満のパーティションには自動的に重み0が割り当てられるためです。
したがって、OSDの最小ディスク領域は11GBになりますが、テスト目的であっても20GB未満のディスクはお勧めしません。
2.4.3 BlueStoreのWALおよびDBデバイスの推奨サイズ #
WALデバイス用に4GBを予約することをお勧めします。RBDのみのワークロードの最小DBサイズは64GBですが、Object GatewayおよびCephFSワークロードの推奨DBサイズは、メインデバイス容量の2%です(ただし、少なくとも196GB)。
重要高負荷な展開では、DB容量をさらに大きくすることをお勧めします。特に、RGWやCephFSの使用量が高い場合必要に応じて、DB領域拡張用のハードウェアを設置する収容能力(スロット)をある程度確保してください。
WALとDBデバイスを同じディスクに配置する予定の場合は、それぞれに別個のパーティションを設けるのではなく、両方のデバイスに対して単一のパーティションを使用することをお勧めします。これにより、CephはDBデバイスをWAL操作にも使用できます。Cephは必要時にのみDBパーティションをWALに使用するので、ディスク領域の管理が効率化します。もう1つの利点は、WALパーティションがいっぱいになる可能性は極めて低く、完全に使い切っていなければ、その領域が無駄になることはなく、DB操作に使用されることです。
DBデバイスをWALと共有するには、WALデバイスを「指定しない」で、DBデバイスのみを指定します。
OSDレイアウトを指定する方法の詳細については、13.4.3項 「DriveGroups仕様を用いたOSDの追加」を参照してください。
2.4.4 WAL/DBパーティション用SSD #
SSD (ソリッドステートドライブ)には可動部品がありません。これは、ランダムアクセス時間と読み込みレイテンシを短縮すると同時に、データスループットを加速します。SSDの1MBあたりの価格は回転型ハードディスクの価格より大幅に高いため、SSDは小容量のストレージにのみ適しています。
WAL/DBパーティションをSSDに保存し、オブジェクトデータは別個のハードディスクに保存することで、OSDのパフォーマンスを大幅に向上させることができます。
WAL/DBパーティションは比較的小さい領域しか占有しないため、1つのSSDディスクを複数のWAL/DBパーティションで共有できます。WAL/DBパーティションを増やすほど、SSDディスクのパフォーマンスが低下することに注意してください。同じSSDディスクでWAL/DBパーティションを7つ以上共有することはお勧めしません。NVMeディスクの場合、13個以上の共有はお勧めしません。
2.4.5 推奨されるディスクの最大数 #
1台のサーバで、そのサーバで使用できる数だけのディスクを使用できます。サーバあたりのディスク数を計画する際には、考慮すべき点がいくつかあります。
「ネットワーク帯域幅」サーバのディスクが増えるほど、ディスク書き込み操作のためにネットワークカード経由で転送しなければならないデータが増えます。
「メモリ」2GBを超えるRAMは、BlueStoreキャッシュに使用されます。
osd_memory_targetのデフォルトである4GBを使用すると、回転型メディアに適したキャッシュ開始サイズがシステムに設定されます。SSDまたはNVMEを使用する場合は、OSDあたりのキャッシュサイズとRAM割り当てを増やすことを検討します。「耐障害性」サーバ全体に障害が発生した場合、搭載ディスクの数が多いほど、クラスタが一時的に失うOSDが増えます。さらに、レプリケーションルールを実行し続けるために、障害が発生したサーバからクラスタ内のほかのノードにすべてのデータをコピーする必要があります。
2.5 Monitorノード #
少なくとも3つのMONノードが必要です。モニタの数は常に奇数(1+2n)である必要があります。
4GBのRAM。
4つの論理コアを持つプロセッサ。
特に各モニタノードの
/var/lib/cephパスには、SSDか、その他の十分高速なストレージタイプを強くお勧めします。ディスクのレイテンシが大きいと、クォーラムが不安定になる可能性があるためです。冗長性を確保するには、RAID 1設定で2台のディスクを使用することをお勧めします。モニタが利用可能なディスク領域をログファイルの増大などから保護するため、モニタプロセスには、別個のディスク、または少なくとも別個のディスクパーティションを使用することをお勧めします。各ノードのモニタプロセスは1つだけにする必要があります。
OSDノード、MON、またはObject Gatewayノードを混在させることは、十分なハードウェアリソースが利用可能な場合にのみサポートされます。つまり、すべてのサービスの要件を合計する必要があります。
複数のスイッチにボンディングされた2つのネットワークインタフェース。
2.6 Object Gatewayノード #
Object Gatewayノードには最低でも6コアCPUと32GBのRAMを使用する必要があります。同じマシンに他のプロセスも配置されている場合、それらの要件を合計する必要があります。
2.7 メタデータサーバノード #
メタデータサーバノードの適切なサイズは、具体的な使用事例によって異なります。一般的には、メタデータサーバが処理する開いているファイルが多いほど、より多くのCPUとRAMが必要になります。最小要件は次のとおりです。
各メタデータサーバドメインに対して4GBのRAM。
ボンディングされた2つのネットワークインタフェース。
2個以上のコアを持つ2.5GHzのCPU。
2.8 管理ノード #
少なくとも4GBのRAMとクアッドコアCPUが必要です。これには、管理ノードにおけるSalt Masterの実行が含まれます。数百のノードで構成される大規模クラスタでは、6GBのRAMをお勧めします。
2.9 iSCSI Gatewayノード #
iSCSI Gatewayノードには最低でも6コアCPUと16GBのRAMを使用するべきです。
2.10 SESおよび、その他のSUSE製品 #
このセクションには、SESと他のSUSE製品の統合に関する重要な情報が記載されています。
2.10.1 SUSE Manager #
SUSE ManagerとSUSE Enterprise Storageは統合されていません。そのため、現在のところSUSE ManagerでSESクラスタを管理することはできません。
2.11 名前の制限 #
一般的に、Cephは、設定ファイル、プール名、ユーザ名などでASCII以外の文字をサポートしません。Cephクラスタを設定する場合、すべてのCephオブジェクト名/設定名で単純な英数字の文字(A～Z、a～z、0～9)と、最小限の句読点(「.」「-」「_」)のみを使用することをお勧めします。
2.12 OSDとモニタでの1台のサーバの共有 #
テスト環境ではOSDとMONを同じサーバで実行することは技術的に可能ですが、運用ではモニタノードごとに別個のサーバを用意することを強くお勧めします。その主な理由はパフォーマンスです。クラスタのOSDが増えるほど、MONノードが実行しなければならないI/O操作が増えます。さらに、1台のサーバをMONノードとOSDで共有する場合、OSDのI/O操作がモニタノードにとって制限要因になります。
考慮すべきもう1つの点は、サーバ上のOSD、MONノード、およびオペレーティングシステムでディスクを共有するかどうかです。答えは単純です。可能であれば、OSDには別個の専用ディスクを使用し、モニタノードには別個の専用サーバを使用します。
CephはディレクトリベースのOSDをサポートしますが、OSDには、常にオペレーティングシステムのディスクではなく専用ディスクを使用する必要があります。
OSDとMONノードをどうしても同じサーバで実行する必要がある場合は、MONを別個のディスクで実行し、そのディスクを/var/lib/ceph/monディレクトリにマウントすることで、少しでもパフォーマンスを向上させます。