DataStax Enterprise実装のためのハードウェアの選択
DataStax Enterpriseに合ったハードウェアを選択するには、メモリー、CPU、ディスク、ノード数、ネットワークを適切なバランスで選択する必要があります。
一般的なガイドライン
- 選択すべきハードウェアは、個々のユース・ケースにより異なります。メモリー、CPU、ディスク、ノード数、ネットワークの適切なバランスは、アクセス頻度の低い静的データを含む環境と、アクセス頻度の高い揮発性データを含む環境では大きく異なります。
- 推奨されるガイドラインは最小要件を示しています。場合によっては、推奨される最小値よりもメモリー、CPU、ディスクを増やす必要があります。
- SANストレージ、NASデバイス、およびNFSに関する重要な情報については、「DataStax Enterpriseのアンチパターン」を必ずお読みください。
- デプロイする前に構成を十分にテストしてください。
ストレス・テスト
- cassandra-stress
- 必要な構成で行うcassandra-stressツール。ブートストラップ、リペア、障害など、一般的な管理操作のテストを必ず行ってください。「プロダクション前のDataStax Enterpriseクラスターのテスト」を参照してください。
- DSE Searchストレス・デモ
- solr_stressデモは、反復のシーケンシャルな組み合わせを指定して、またはランダムな組み合わせで、DSE Searchクラスターのデータの読み取り/書き込みを行う要求の数をシミュレートするベンチマーク・ツールです。「MBeans検索デモ」を参照してください。
- パッケージ・インストール：/usr/share/dse/demos
- tarボール・インストール：installation_location/demos
メモリー
DataStax Enterpriseノードのメモリーを増やすと、読み取りパフォーマンスが向上します。また、RAMが多いとメモリー・テーブル（memtable）はより多くの最新の書き込みデータを保持できます。memtableが大きいと、ディスクにフラッシュされるSSTableが最小限になり、オペレーティング・システム・ページ・キャッシュに保持されるデータが多いほど、読み取り時にディスクからスキャンするファイルが少なくなります。RAMの最適容量は、ホット・データの予測サイズによって決まります。
| 実稼働 | ||
|---|---|---|
| ノードのタイプ | システム・メモリー | ヒープ |
| Transactionalのみ | 32 GB | 8 GB |
| DSE Analytics | 32 GB～512 GB |
|
| DSE Search 「DSE Searchの容量計画」も参照してください。 |
32 GB～512 GB | |
| DSE Graph | DSE SearchまたはDSE Analyticsの個々の組み合わせに2～4 GBを追加します。専用の大型グラフ・キャッシュの場合、さらにRAMを追加します。 | |
| 開発（非負荷テスト環境） | ||
| すべて | 8 GB | 4 GB |
| すべて | 16 GB | 8 GB |
CPU
データ挿入の多いワークロードの場合、DataStax Enterpriseではメモリーの限界に達する前にCPUの限界に達します（すべての書き込みはコミット・ログに記録されますが、データベースでの書き込みは非常に効率的であるためCPUが限界要因になります）。DSEは高並列で、可能な限り多くのCPUコアを使用します。推奨事項：
- 実稼働環境の専用ハードウェアの最小要件：16コアCPUプロセッサー（論理）。
- 非負荷テスト環境の開発専用ハードウェア：2コアCPUプロセッサー（論理）で十分です。
- DSE Graph：クエリーの最適化と結果セットの作成により、グラフ・クエリーがCPUボトルネックになる可能性があるため、やや大きいCPUの使用が推奨されます。
回転式ディスクと半導体ドライブ（ローカルのみ）
すべてのDataStax Enterpriseノードにおいて、SSDが推奨されます。SSDに搭載されているNANDフラッシュ・チップは、ランダム読み取り時に非常に低レイテンシーの応答時間を提供する一方で、コンパクション操作に対して十分なシーケンシャル書き込みパフォーマンスを提供します。近年、ドライブ・メーカーは全体的な耐久性を向上させてきましたが、これは主に予備の（表に出ない）容量と組み合わせることによって実現されています。さらに、PBW/DWPDレーティングは、ランダム書き込みワークロードなど、最悪ケースのシナリオに基づく確率的推定値であり、データベースは大規模なシーケンシャル書き込みしか行わないため、ドライブは耐久力レーティングを大幅に超えます。それでも、ドライブの障害発生に備えて計画を立てて、予備のドライブを準備しておくことが重要です。サーバーのベンダーやサードパーティのドライブ・メーカーがさまざまなSSDを販売しています。
- ドライブを簡単に交換できる場合は、必要なパフォーマンスを提供できる製品のうち価格が最も安いドライブを購入します。
- ドライブの交換が困難であるほど、耐久性の高いモデルの購入を検討します。ミッド・レンジから始めて、その最初のモデルの障害発生率に基づいて、耐久性のレベルに従い製品を選択します。
特定のデプロイとワークロードについてコスト効率の良い選択をするためのサポートが必要な場合は、DataStaxサービス・チームにお問い合わせください。
ディスク領域
ディスク領域は使い方によって異なります。したがって、メカニズムを理解することが重要です。データベースは、永続性のためにデータをコミット・ログに追加書き込みするとき、および永続的な格納のためにmemtableをSSTableにフラッシュするときに、データをディスクに書き込みます。コミット・ログに対するアクセス・パターン（読み取り/書き込み比率）は、SSTableのデータに対するパターンと異なります。これは、SSDよりも回転式ディスクで重要になります。
SSTableは、定期的にコンパクションされます。コンパクションは、データをマージして再度書き込み、古いデータを削除することにより、パフォーマンスを向上させます。ただし、コンパクションのタイプとサイズによっては、コンパクション時にディスク使用率とデータ・ディレクトリーのボリュームが一時的に増えることがあります。このため、ノード上に適切な量の空きディスク領域を確保する必要があります。
| コンパクション・ストラテジ | 最小要件 |
|---|---|
| SizeTieredCompactionStrategy（STCS） | コンパクションするSSTableの合計値が、残りのディスク容量よりも小さくなければなりません。 注: 最悪の条件：空きディスク領域の50%。このシナリオは手動のコンパクションですべてのSSTableを1つの大きなSSTableにマージする場合に生じる可能性があります。 |
| LeveledCompactionStrategy（LCS） | 通常、10%。最悪の条件：レベル0のバックログが32のSSTableを上回る場合は50%（LCSがレベル0にSTCSを使用）。 |
| TimeWindowCompactionStrategy（TWCS） | TWCSの要件はSTCSの要件と似ています。TWCSでは、前回作成されたバケットのSSTableの合計サイズのために約50%の追加ディスク領域が必要です。 適切なディスク領域を確保するには、これまでに生成されたバケットの中で最も大きいバケットのサイズを特定し、50%のディスク領域を追加します。 |
最小ディスク領域に関する推奨事項
solr_stressも使用してテストしてください。- ノードあたりの容量（ノード密度）
- ノード密度は環境によって大きく異なります。ノード密度の決定には、以下を含む多くの要因が影響します。
- データの変更が頻繁に行われているかどうか。
- アクセスの頻度。
- コンパクション・ストラテジ：ワークロードが書き込みが多いか、読み取りが多いか、時間に応じて異なるかによって、最適なコンパクション・ストラテジが異なります。上記の「ディスク容量」を参照してください。
- HDDまたはSSDの使用。
- ネットワーク・パフォーマンス：リモート・リンクを使用すると、ストレージ帯域幅が制限され、レイテンシーが増加する傾向があります。
- ストレージ速度と、ストレージがローカルかどうか。
- レプリケーション係数：「データ分散およびレプリケーションについて」を参照してください。
- SLA（サービス・レベル・アグリーメント）と機能停止時の処理能力。
- データが圧縮されているかどうか。
問題発生を回避するため、DataStaxではノードあたりのデータ量を1 TB以下に保つことを推奨しています。この値を上回ると、以下の影響が生じます。- 新しいノードのブートストラップによる読み込むに非常に時間（日数）がかかる。
- ノードの復旧、追加、交換など、メンテナンス（日常業務）に影響を及ぼす。
- リペア実行時の効率が低下する。
- 複数のデータ・センターを展開する際に大幅に時間がかかる。
- ノードあたりのコンパクションが相当増加する。
高容量のノードは静的データおよび低アクセス・レートで最適に機能します。
- Searchノードの容量
- 最適なパフォーマンスを得るには、検索インデックス専用のドライブを使用します。
- 容量とI/O
- ノードのディスクを選択するときは、容量（格納する予定のデータの量）とI/O（書き込み/読み取りのスループット速度）の両方を考慮してください。ワークロードによっては、低価格のSATAディスクを使用し、（より大きなRAMを持つ）ノードを追加してディスクの容量とI/Oを拡張する方が適切な場合があります。
- ディスクの台数 - SATA
- DataStax Enterpriseには、ノードごとに少なくとも2台のディスクが必要で、1台はコミット・ログ用、もう1台はデータ・ディレクトリー用です。最低でも、コミット・ログは専用のパーティションに配置する必要があります。
- コミット・ログ・ディスク - SATA
- ディスクは大容量である必要はありませんが、すべての書き込みを追加書き込み（シーケンシャルI/O）として受け取るために十分な速さが必要です。
- コミット・ログ・ディスク - SSD
- 回転式ディスクとは異なり、コミット・ログとSSTableを同じ場所に格納できます。
- DSE Search - SSD
- DSE Searchは極めてIOが多いため、トランザクション・データと検索データは別のSSDに配置する必要があります。それ以外の場合、SSDは両方のワークロードからオーバーランする可能性があります。
- データ・ディスク
- ノードごとに1台以上のディスクを使用して、データ量に対して十分な容量であることと、メモリーにキャッシュされない読み取りに対応しコンパクションに追従できる十分な速さであることを確認してください。
- データ・ディスク上のRAID
- 通常は、以下の理由からRAIDを使用する必要はありません。
- データは、選択したレプリケーション係数に基づいてクラスター全体でレプリケートされます。
- DataStax Enterpriseは、ディスク管理機能であるJBOD（Just a bunch of disks）を備えています。データベースは、影響を受けるノードを停止するか、故障したドライブをブラックリストに入れることで、指定されている可用性/整合性要件に沿ってディスク障害に対応するため、RAID 10を採用しなくても、大容量のディスク・アレイを持つノードをデプロイできます。可用性/整合性要件に沿って、影響を受けるノードを停止するか、またはそのドライブをブラックリストに入れるようにデータベースを構成することができます。「JBODを使用した単一ディスク障害からの復旧」も参照してください。
- コミット・ログ・ディスク上のRAID
- 通常、コミット・ログ・ディスクにRAIDは必要ありません。レプリケーションによって、データの損失を十分に回避できます。さらに冗長性が必要な場合は、RAID 1を使用してください。
- 拡張ファイル・システム
- DataStaxでは、XFSまたはext4上にデプロイすることを推奨しています。ext2またはext3では、64ビット・カーネルを使用していてもファイルの最大サイズは2 TBです。ext4では16 TBになります。
SizeTieredCompactionStrategyを使用する場合、データベースは1つのファイルでディスク領域のほぼ半分を使用することがあるので、大容量のディスクを使用する場合、特に32ビット・カーネルを使用する場合は、XFSを使用してください。XFSのファイル・サイズ制限は、32ビット・カーネルでは最大16 TBで、64ビットでは実質的に無制限です。
ネットワーク
推奨される最小帯域幅：1000 Mb/s（ギガビット）。
DataStax Enterpriseは、分散型のデータ・ストアであるため、読み取り/書き込み要求とノード間でのデータのレプリケーションを処理するためにネットワークに負荷をかけます。ネットワークで、ノード間のトラフィックをボトルネックなしに処理できることを確認してください。DataStaxでは、インターフェイスを別々のネットワーク・インターフェイス・カード（NIC）にバインドすることを推奨しています。要件に応じて、パブリックNICまたはプライベートNICを使用できます。
データベースは、コーディネーター・ノードに地理的に最も近いレプリカに要求を効率的にルーティングし、可能であれば同じラック内のレプリカを選択します。リモート・データ・センターにあるレプリカよりも、同じデータ・センターにあるレプリカが常に選択されます。
ファイアウォール
ファイアウォールを使用する場合は、クラスター内のノードが互いに通信できることを確認してください。DataStax Enterpriseポートのセキュリティ保護に関する表を参照してください。