Amazon EC2クラスターの計画 

実稼働のCassandraクラスターまたはDataStax EnterpriseクラスターをAmazon EC2にデプロイするための重要な情報。

Amazon EC2クラスターを計画する前に、「Amazon EC2 - Virtual Server Hosting」をお読みください。

DataStax AMIのデプロイ 

DataStax AMIは、DataStax Enterprise 4.8以前およびApache Cassandra™ 2.1以前のみで使用できます。それより後のバージョンをインストールするには、お使いのプラットフォームの信頼できるAMIおよび適切なインストール方法を使用してください。

DataStax AMIは、1つのリージョンおよびアベイラビリティー・ゾーンのみに使用されます。複数のリージョンおよびアベイラビリティー・ゾーンにまたがるEC2クラスターについては、「複数のリージョンおよびアベイラビリティー・ゾーンにまたがるEC2クラスター」を参照してください。

信頼できる入手先からのAMIを使用 

信頼できる入手先からのAMIのみを使用してください。任意に入手したAMIはセキュリティ上のリスクをもたらし、EC2インストールの構成方法に起因して、予期しているよりもパフォーマンスが低い可能性があります。以下は、信頼できるAMIの例です。

より新しいバージョンのDataStax EnterpriseとApache Cassandraまたは複数のリージョン/アベイラビリティー・ゾーンに対するEC2デプロイ 

このようなデプロイには、DataStax EnterpriseまたはCassandraでサポートされている任意のプラットフォームを使用して、各ノードにインストールします。
  • DataStax Enterpriseインストール: 4.6, 4.7, 4.8, 5.0
  • Cassandraインストール: 2.1, 3.0, 3.x

すべてのノードに同じプラットフォームを使用するのがベスト・プラクティスです。DataStax AMIを使用してクラスターがインスタンス化されている場合は、追加ノードとしてUbuntuを使用してください。Ec2MultiRegionSnitchを使用して複数データ・センター・クラスターとしてクラスターを構成します。

EC2上の実稼働クラスター 

EC2上の実稼働クラスターの場合は、以下のガイドラインに従ってインスタンスの種類を選択します。

  • Development and light production:m3.large
  • Moderate production:m3.xlarge
  • SSD production with light data:c3.2xlarge
  • Largest heavy production:m3.2xlarge (PV)またはi2.2xlarge (HVM)
  • 極小、小、および中タイプはサポートされません。

実稼働環境に推奨されるEBSボリューム 

実稼働環境のワークロードには、SSDベースの汎用ボリューム(GP2)またはプロビジョンされたIOPSボリューム(PIOPS)が適しています。これらのボリューム・タイプは、一貫性のある低遅延パフォーマンスを発揮するように設計されています。
GP2 PIOPS
  • ほとんどのワークロードにとって、最善の選択。3.5 TBを超えるボリュームがインスタンスに接続されているときに、10,000件のIOPSが保証されるという利点があります。
  • 遅延が1桁のミリ秒台に収まるように設計されています。
  • 時間の99.0%で、プロビジョンされたパフォーマンスを発揮するように設計されています。
  • 遅延が1桁のミリ秒台に収まるように設計されています。
  • 時間の99.9%で、プロビジョンされたパフォーマンスを発揮するように設計されています。

EBSマグネティック・ボリュームが推奨されない理由 

EBSマグネティック・ボリュームは、以下の理由でCassandraデータ・ストレージ・ボリュームに推奨されません。

  • EBSマグネティック・ボリュームは標準パケットとネットワーク・スループットをめぐって直接競合します。この競合のため、ネットワーク・リンクが飽和状態になると、EBSスループットで障害が発生する可能性が高くなります。
  • EBSマグネティック・ボリュームのパフォーマンスは不確かです。I/Oパフォーマンスが極めて遅く、全クラスターが応答不能になるまでシステムが読み取りおよび書き込みが滞る原因となります。
  • ホストあたりのEBSボリュームの数を増やすことにより容量を追加してもスケールは確保できません。効率的なバッファ・キャッシュを維持し、管理する必要があるデータのすべてに対する要求に同時に応えるためのシステムの能力を簡単に上回ってしまいます。
注: Cassandraデータ・ストレージには、エフェメラルinstance-storeまたは推奨されるEBSボリューム・タイプのみを使用してください。

エフェメラルのパフォーマンスとEBSのパフォーマンスの対比に関連する情報およびグラフについては、「Systematic Look at EC2 I/O」を参照してください。

ディスク・パフォーマンスの最適化 

マウントされているドライブの高ディスク・パフォーマンスを確保するには、実稼働環境で使用する前にすべてのドライブの場所にデータを1回書き込むことによりドライブをウォーミングアップしておくことを推奨します。EC2の状態によっては、かなりのスループット向上を期待できます。「Optimizing Disk Performance」(Amazon Elastic Compute Cloudドキュメント)を参照してください。

Amazon EC2デプロイのその他のリソース

ストレージに関する推奨事項 

CassandraはJBOD(just a bunch of disks)をサポートしています。JBODは、ディスク・アレイの部分的障害に対する耐性に優れています。cassandra.yamlファイルの中でdisk_failure_policyを使用して構成してください。追加情報は、「Handling Disk Failures In Cassandra 1.2」ブログと「Recovering using JBOD」にあります。
注: Cassandra JBODのサポートにより、標準ディスクを使用できます。ただし、RAID0は、各ブロックを別のデバイスに振り分けるため、RAID0の方がより良いスループットを提供できる場合があります。なぜなら、書き込みがディスクに対してシーケンシャルに行われるのではなく並行して行われるからです。
disk_failure_policy
Apache Cassandraバージョン 対応するDataStax Enterpriseバージョン
2.1 4.7, 4.8
3.0 Linux 5.0
3.x Linux  
3.0 Windows  
3.x Windows  
JBODを使用した復旧
Apache Cassandraバージョン 対応するDataStax Enterpriseバージョン
2.1 4.7, 4.8
3.0 Linux 5.0
3.x Linux  
3.0 Windows  
3.x Windows  
Ec2MultiRegionSnitch
Apache Cassandraバージョン 対応するDataStax Enterpriseバージョン
2.1 4.7, 4.8
3.0 Linux 5.0
3.x Linux  
3.0 Windows  
3.x Windows  
複数のデータ・センター・クラスター
Apache Cassandra DataStax Enterprise
2.1 4.7
3.0 Linux 4.8
3.x Linux 5.0
3.0 Windows  
3.x Windows  
インストール
Apache Cassandraバージョン DataStax Enterprise
2.1 4.7
3.0 Linux 4.8
3.x Linux 5.0
3.0 Windows  
3.x Windows