ワークロードの種類別に複数のデータ・センターを初期化する
ノードのタイプごとに、1つ以上のデータ・センターを持つ混在ワークロード・クラスターでノードを構成するための手順。
このシナリオでは、混在ワークロード・クラスター内にノードの種類ごとに複数のデータ・センターがあります。たとえば、クラスターに4つのAnalyticsノード、4つのトランザクション・ノード、2つのDSE Searchノードがある場合、このクラスターは5つのデータ・センターを持つ場合があります。Analyticsノード用に2つのデータ・センター、トランザクション・ノード用に2つのデータ・センター、DSE Searchノード用に1つのデータ・センター。単一データ・センター・クラスターの場合、データ・センターはノードの種類ごとに1つだけです。
大半の状況において、検索、分析、ならびにトランザクションなどの各ワークロードタイプは、異なる仮想データ・センター内に編成されます。ワークロード分離により、リソースの競合を回避します。ただし、分析に対して大きな需要が存在しない場合、ワークロードはSearchAnalyticsノードに組み合わせることができます。一般に、トランザクション(OLTP)と分析(OLAP)ワークロードを組み合わせると、パフォーマンスが低下します。クエリーしたいノードのDSE Graphのみ、有効にします。
CQLを使用してキースペースを作成すると、1つのノードのクラスターであっても、DataStax Enterpriseではクラスターの仮想データ・センターが自動的に作成されます。同じ種類のワークロードを実行するノードを同じデータ・センターに割り当てます。異なる種類のノードを対象とした異なる仮想データ・センターは、こうしたノードからDSE Searchを実行するワークロードと他の種類のワークロードを実行するワークロードを分離します。
- データ・センター間のネットワーク接続や停電など、障害が発生した外部インフラストラクチャーからのレプリカの切り離し
- 地理的に分散した複数のノード間の分散データのレプリケーション
- 物理データ・センターの異なる物理的ラック間。
- 一般のクラウド・プロバイダーとオンプレミス管理型データ・センター間。
- 生データに対して分析ジョブを実行する開発クラスターによってリアルタイムの分析クラスターの速度が低下するのを防ぎます。
- 特に1よりも大きい整合性レベルを使用しているときに、特定のデータ・センターからの読み取りが要求に対してローカルであるようにするには、物理データ・センターで仮想データ・センターを使用します。このストラテジにより、ニューヨークのノードやロサンゼルスのノードからの読み取りが防げるため、レイテンシーを低く抑えることができます。
始める前に
- データベースの仕組みをよく理解する。少なくとも、データベース・アーキテクチャーの理解とデータ・レプリケーションを必ずお読みください。
- 環境が、ユース・ケースとワークロードに適していることを確認してください。
- 実稼働環境での推奨設定を確認します。
- クラスターの名前を選択する。
- 混在ワークロードのクラスターの場合は、各ノードの目的を決定する。
- スニッチおよびレプリケーション・ストラテジを決定する。実稼働環境には、GossipingPropertyFileSnitchおよびNetworkTopologyStrategyを推奨します。
- 各ノードのIPアドレス。
- DataStax Enterpriseが、各ノードにインストールされていることを確認します。
- どのノードをシード・ノードにするかを決定する。すべてのノードをシード・ノードにしないでください。
シード・ノードは、DSE Searchデータ・センターでは不要です。ノード間のコミュニケーション(ゴシップ)を参照してください。
- 内容を確認し、cassandra-rackdc.propertiesなど他のプロパティ・ファイルに必要な変更を加えます。
- データ・センターの種類に合わせて正しく仮想ノードを設定する。「Virtual nodes」を参照してください。
手順
この構成では、2つのデータ・センターにまたがる6つのノードで構成されるクラスターをインストールする方法を説明しています。デフォルトの整合性レベルはQUORUMです。
-
これらのノードにDataStax Enterpriseをインストールするとします。
- node0 10.168.66.41 (seed1)
- node1 10.176.43.66
- node2 10.168.247.41
- node3 10.176.170.59 (seed2)
- node4 10.169.61.170
- node5 10.169.30.138
- ノードがファイアウォールの背後にある場合は、内外で通信するために、必要なポートを開きます。
-
DataStax Enterpriseが実行されている場合は、ノードを停止してデータを消去します。
- パッケージおよびInstaller-Servicesのインストール:
$ sudo service dse stop $ sudo rm -rf /var/lib/cassandra/* ## Remove data from the default directories
- tarボールおよびInstaller-No Servicesのインストール:
$ cd installation_location $ sudo rm -rf data/* commitlog/* saved_caches/* hints/* ## Remove all data
installation_locationが次のいずれかの場合。- /var/lib/cassandra/data
- DataStax Enterpriseをインストールしたディレクトリー。
- パッケージおよびInstaller-Servicesのインストール:
-
各ノードについてcassandra.yamlファイル内のプロパティを設定します。
注: yaml_diff toolを使用して確認し、cassandra.yaml構成ファイルとdse.yaml構成ファイルに必要な変更を加えます。
ディスクのレイアウト、共有ライブラリなどに関してクラスター内の各ノードが同じ場合は、すべてのノードでcassandra.yamlファイルの同じコピーを使用できます。
num_tokens
: 「vnodeの推奨事項」を参照してください。-seeds
: 各シード・ノードのinternal_IP_address重要: 各データ・センターから1つ以上のシード・ノードを含める必要があります。DataStaxでは、データ・センターごとに1つ以上のシード・ノードを持つことを推奨しています。すべてのノードをシード・ノードにしないでください。listen_address
: 空設定されていないと、DataStax Enterprise(DSE)は、そのホスト名に関連付けられているローカル・アドレスについてシステムに尋ねます。DSEが正しいアドレスを生成しない場合は、listen_addressを指定する必要があります。
endpoint_snitch
: スニッチendpoint_snitchとsnitchesを参照してください。スニッチを変更する場合は、「スニッチの切り替え」を参照してください。
auto_bootstrap
: falsebootstrap(この設定は、データなしで新しいクラスターを初期化する場合にのみ追加してください。)
- 以前のバージョンから、cassandra.yamlまたはdse.yamlファイルを使用している場合、必ず削除された設定のアップグレード・ガイドを確認してください。
cassandra.yamlファイルの場所は、インストールのタイプによって異なります。パッケージ・インストールInstaller-Servicesインストール
/etc/dse/cassandra/cassandra.yaml tarボール・インストールInstaller-No Servicesインストール
installation_location/resources/cassandra/conf/cassandra.yaml cluster_name: 'MyDemoCluster' num_tokens: 256 seed_provider: - class_name: org.apache.cassandra.locator.SimpleSeedProvider parameters: - seeds: "10.168.66.41,10.176.170.59" listen_address: endpoint_snitch: GossipingPropertyFileSnitch
- ユース・ケースの要件に応じてdse.yamlファイルのプロパティを設定します。
-
cassandra-rackdc.properties (GossipingPropertyFileSnitch)またはcassandra-topology.properties(PropertyFileSnitch)ファイルで、命名規則を使用してデータ・センターとラックの名前を各ノードのIPアドレスに割り当て、不明なノードにはデフォルトのデータ・センター名とラック名を割り当てます。
注: 移行情報:ファイルが存在する場合、GossipingPropertyFileSnitchは常に、cassandra-topology.propertiesを読み込みます。新しいクラスター、またはPropertyFileSnitchから移行したクラスターの各ノードから、ファイルを削除します。cassandra-topology.propertiesファイルの場所は、インストールのタイプによって異なります。
パッケージ・インストールInstaller-Servicesインストール
/etc/dse/cassandra/cassandra-topology.properties tarボール・インストールInstaller-No Servicesインストール
installation_location/resources/cassandra/conf/cassandra-topology.properties cassandra-rackdc.propertiesファイルの場所は、インストールのタイプによって異なります。パッケージ・インストールInstaller-Servicesインストール
/etc/dse/cassandra/cassandra-rackdc.properties tarボール・インストールInstaller-No Servicesインストール
installation_location/resources/cassandra/conf/cassandra-rackdc.properties 例:
# Transactional Node IP=Datacenter:Rack 10.168.66.41=DC1:RAC1 10.176.43.66=DC2:RAC1 10.168.247.41=DC1:RAC1 10.176.170.59=DC2:RAC1 10.169.61.170=DC1:RAC1 10.169.30.138=DC2:RAC1 # default for unknown nodes default=DC1:RAC1
-
すべてのノードにDataStax Enterpriseをインストールして構成したら、シード・ノードを1つずつ起動した後で、残りのノードを起動します。
- tarボールおよびInstaller-No Servicesのインストール: DataStax Enterpriseをサービスとして起動
- パッケージおよびInstaller-Servicesのインストール: DataStax Enterpriseをスタンドアローン・プロセスとして起動
-
自分のクラスターが起動して稼働していることを確認します。
$ nodetool status
tarボールおよびInstaller-No Servicesのパス:installation_location/bin
タスクの結果
Datacenter: DC1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID Rack
UN 10.168.66.41 45.96 KB 256 27.4% c885aac7-f2c0-... RAC1
UN 10.168.247.41 66.34 KB 256 36.6% fa31416c-db22-... RAC1
UN 10.169.61.170 55.72 KB 256 33.0% f488367f-c14f-... RAC1
Datacenter: DC2
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID Rack
UN 10.176.43.66 45.96 KB 256 27.4% f9fa31c7-f3c0-... RAC1
UN 10.176.170.59 66.34 KB 256 36.6% a5bb526c-db51-... RAC1
UN 10.169.30.138 55.72 KB 256 33.0% b836478f-c49f-... RAC1