指定されたデータ・センターをデータ・ソースとして使用してクラスターへデータ・センターを追加する

指定されたデータ・センターをデータ・ソースとして使用してデータ・センターを既存のクラスターへ追加します。

指定されたデータ・センターをデータ・ソースとして使用してデータ・センターを既存のクラスターへ追加するには、次の手順を完了します。この手順では、新しいデータ・センターであるDC4が、既存のデータ・センターDC1、DC2、およびDC3がある既存のクラスターへ追加されます。

cassandra-rackdc.properties

cassandra-rackdc.propertiesファイルの場所は、インストールのタイプによって異なります。
パッケージ・インストール /etc/dse/cassandra/cassandra-rackdc.properties
tarボール・インストール installation_location/resources/cassandra/conf/cassandra-rackdc.properties

cassandra.yaml

cassandra.yamlファイルの場所は、インストールのタイプによって異なります。
パッケージ・インストール /etc/dse/cassandra/cassandra.yaml
tarボール・インストール installation_location/resources/cassandra/conf/cassandra.yaml

dse.yaml

dse.yamlファイルの場所は、インストールのタイプによって異なります。
パッケージ・インストール /etc/dse/dse.yaml
tarボール・インストール installation_location/resources/dse/conf/dse.yaml

system.log

system.logファイルの場所は:
  • /var/log/cassandra/system.log

cassandra-topology.properties

cassandra-topology.propertiesファイルの場所は、インストールのタイプによって異なります。
パッケージ・インストール /etc/dse/cassandra/cassandra-topology.properties
tarボール・インストール installation_location/resources/cassandra/conf/cassandra-topology.properties

始める前に

重要:DataStax Enterpriseクラスターの初期化」に記載する前提条件タスクを完了して環境を準備します。

手順

  1. 既存のデータ・センターで、SimpleStrategyレプリケーション・ストラテジが使用されている場合は、これをNetworkTopologyStrategyレプリケーション・ストラテジに変更します。
    1. 以下のキースペースについて、ALTER KEYSPACEを使用して、キースペースのレプリケーション・ストラテジをNetworkTopologyStrategyに変更します。
      ALTER KEYSPACE keyspace_name WITH REPLICATION = 
      {'class' : 'NetworkTopologyStrategy', 'DC1' : 3};
    2. DESCRIBE SCHEMAを使用して、クラスターのキースペースのレプリケーション・ストラテジを確認します。既存のすべてのキースペースでNetworkTopologyStrategyレプリケーション・ストラテジが使用されていることを確認します。
      DESCRIBE SCHEMA ;
      CREATE KEYSPACE dse_perf WITH replication = 
      {'class': 'NetworkTopologyStrategy, 'DC1': '3'}  AND durable_writes = true;
      ...
      
      CREATE KEYSPACE dse_leases WITH replication =
      {'class': 'NetworkTopologyStrategy, 'DC1': '3'}  AND durable_writes = true;
      ...
      
      CREATE KEYSPACE dsefs WITH replication =
      {'class': 'NetworkTopologyStrategy, 'DC1': '3'}  AND durable_writes = true;
      ...
      
      CREATE KEYSPACE dse_security WITH replication =
      {'class': 'NetworkTopologyStrategy, 'DC1': '3'}  AND durable_writes = true;
  2. OpsCenter Repair Service(リペア・サービス)を停止します(クラスターで実行されている場合)。「Repair Service(リペア・サービス)をオフにする」を参照してください。
  3. 新しいデータ・センターの各ノードにDSEをインストールします(「DSEのインストール」を参照)。サービスを開始したり、ノードを再起動しないでください。
    重要: クラスターのすべてのノードに同じバージョンのDSEを使用します。
  4. クラスター内の他のノードの構成に従って、新しい各ノードでcassandra.yaml のプロパティを構成します。
    ヒント: yaml_diff toolを使用して、cassandra.yaml およびdse.yaml 構成ファイルを確認し、必要な変更を加えます。
    1. 以下のようにノードプロパティを構成します。
      • -seeds:各シード・ノードのinternal_IP_address
        重要: 各データ・センターから1つ以上のシード・ノードを含めます。DataStaxでは、複数のラックで、データ・センターごとに複数のシード・ノードを持つことを推奨しています。データ・センターごとのシード・ノード数として最も一般的な数は3です。すべてのノードをシード・ノードにしないでください。
      • auto_bootstraptrue

        この設定はデフォルトの構成から削除されましたが、存在する場合は、trueに設定する必要があります。

      • listen_addressempty

        設定されていないと、DSEは、そのホスト名に関連付けられているローカル・アドレスについてシステムに尋ねます。DSEが正しいアドレスを生成しない場合は、listen_addressを指定する必要があります。

      • endpoint_snitchsnitch

        endpoint_snitchsnitchesを参照してください。

        重要: DseSimpleSnitchは使用しないでください。DseSimpleSnitch(デフォルト)は、単一のデータ・センターでのデプロイ(またはパブリック・クラウドの単一ゾーン)の場合にのみ使用し、データ・センターまたはラック情報を認識しません。
        スニッチ 構成ファイル
        GossipingPropertyFileSnitch cassandra-rackdc.propertiesファイル
        Amazon EC2シングルリージョン・スニッチ
        Amazon EC2マルチリージョン・スニッチ
        Google Cloud Platformスニッチ
        PropertyFileSnitch cassandra-topology.propertiesファイル
      • 以前のバージョンから、cassandra.yamlまたはdse.yamlファイルを使用している場合、削除された設定のアップグレード・ガイドを確認します。
    2. ノード・アーキテクチャーを構成します(データ・センター内のすべてのノードは同じ型を使用します)。

      仮想ノード(vnode)割り当てアルゴリズムの設定

      • num_tokensを8に設定します(推奨)。
      • allocate_tokens_for_local_replication_factorを新しいデータ・センターのキースペースのターゲット・レプリケーション係数に設定します。キースペースRFが変化したら、設定を交互に指定し、すべてのレプリケーション係数を使用します。
      • initial_tokenプロパティをコメントアウトします。
      注: 詳細については、「仮想ノード(vnode)の構成」を参照してください。

      単一トークン・アーキテクチャーの設定

  5. cassandra-rackdc.properties(GossipingPropertyFileSnitch)またはcassandra-topology.properties(PropertyFileSnitch)ファイルで、命名規則を使用してデータ・センターとラックの名前を各ノードのIPアドレスに割り当て、不明なノードにはデフォルトのデータ・センター名とラック名を割り当てます。
    注: 移行情報:ファイルが存在する場合、GossipingPropertyFileSnitchは常に、cassandra-topology.propertiesを読み込みます。新しいデータ・センター、またはPropertyFileSnitchから移行したデータ・センターの各ノードから、ファイルを削除します。
    # Transactional Node IP=Datacenter:Rack
    110.82.155.0=DC_Transactional:RAC1
    110.82.155.1=DC_Transactional:RAC1
    110.54.125.1=DC_Transactional:RAC2
    110.54.125.2=DC_Analytics:RAC1
    110.54.155.2=DC_Analytics:RAC2
    110.82.155.3=DC_Analytics:RAC1
    110.54.125.3=DC_Search:RAC1
    110.82.155.4=DC_Search:RAC2
    
    # default for unknown nodes
    default=DC1:RAC1
    注: 構成ファイルを変更したら、ノードを再起動して変更を有効にする必要があります。
  6. 既存のデータ・センターで以下の変化を行います。
    1. 既存のデータ・センターのノードで、新しいデータ・センターのシード・ノードを含めるように、-seedsプロパティ(cassandra.yaml 内で指定)を更新します。
    2. 新しいデータ・センター定義を、クラスターで使用されているタイプのスニッチのcassandra.yaml プロパティ・ファイルに追加します。スニッチを変更する場合は、「スニッチの切り替え」を参照してください。
  7. すべてのノードにDataStax Enterpriseをインストールして構成したら、シード・ノードを1つずつ起動した後で、残りのノードを起動します。
  8. 必要に応じて、新しいデータ・センターの各ノードにDataStaxエージェントをインストールして構成します。DataStaxエージェント6.7のインストール
  9. nodetool statusを実行して、新しいデータ・センターが稼働していることを確認します。
    nodetool status
    Datacenter: DC1
    ===============
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address         Load       Owns    Host ID                               Token                     Rack
    UN  10.200.175.11   474.23 KiB  ?       7297d21e-a04e-4bb1-91d9-8149b03fb60a  -9223372036854775808     rack1
    Datacenter: DC2
    ===============
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address         Load       Owns    Host ID                               Token                     Rack
    UN  10.200.175.113  518.36 KiB  ?       2ff7d46c-f084-477e-aa53-0f4791c71dbc  -9223372036854775798     rack1
    Datacenter: DC3
    ===============
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address         Load       Owns    Host ID                               Token                     Rack
    UN  10.200.175.111  961.56 KiB  ?       ac43e602-ef09-4d0d-a455-3311f444198c  -9223372036854775788     rack1
    Datacenter: DC4
    ===============
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address         Load       Owns    Host ID                               Token                     Rack
    UN  10.200.175.114  361.56 KiB  ?       ac43e602-ef09-4d0d-a455-3322f444198c  -9223372036854775688     rack1
  10. クラスターですべてのノードが実行中になり、クライアント・アプリケーションがデータ・センターで認識されたら、cqlshを使用してキースペースを変更し、ターゲット・レプリケーションを新しいデータ・センターに追加します。
    ALTER KEYSPACE keyspace_name WITH REPLICATION = 
    {'class' : 'NetworkTopologyStrategy', 'ExistingDC1' : 3, 'NewDC2' : 2};
    警告: DSE SearchやDSE Analyticsなどのクライアント・アプリケーションが適切に構成されていない場合、オンラインになる前に新しいデータ・センターに接続する可能性があります。構成が適切でない場合、接続の例外、タイムアウト、データの不整合の原因となります。
  11. 新しいデータ・センターの各ノードに対し、ソース・データ・センターの対応するデータ・センター/ラックを指定してnodetool rebuildを実行します。
    nodetool rebuild -dc source_datacenter_name:source_datacenter_rack_name
    次のコマンドは、既存のデータ・センターDC1のデータを、各DC2ノード上の新しいデータ・センターDC2にレプリケートします。ラック仕様は、DC1のラック仕様に対応します。
    DC2:RACK1ノードで実行するコマンド:
    nodetool rebuild -dc DC1:RACK1
    DC2:RACK2ノードで実行するコマンド:
    nodetool rebuild -dc DC1:RACK2
    DC2:RACK3ノードで実行するコマンド:
    nodetool rebuild -dc DC1:RACK3
    1. nodetool rebuild -dcは、1つ以上のノードで同時に使用します。ノードごとにnodetool rebuild -dcを実行すると、既存のクラスターに与える影響は減少します。
    2. または、クラスターが余分なI/Oとネットワーク負荷を処理可能な場合は、複数のノードで実行してください。
      リビルドは安全に並列実行できますが、パフォーマンスのトレードオフが生じる可能性があります。ソース・データ・センター内のノードではデータがストリーミングされるため、そのデータ・センターのデータに関連するアプリケーション・パフォーマンスに潜在的な影響があります。速度とパフォーマンスのバランスを最適に保つため、並列処理とストリーミング・スロットルのさまざまなレベルを調整することによって環境内でテストを実行します。
  12. nodetool netstatsを使用し、各ノードのサイズを検証して新しいデータ・センターのリビルドの進捗状況を監視します。
    nodetool rebuildコマンドは、DSEノードにJMX呼び出しを発行し、リビルドが終了するのを待ちます。その後、コマンドラインに戻ります。JMX呼び出しが起動されると、nodetool rebuildプロセスに関係なくサーバー上でリビルド・プロセスが継続されます(nodetoolが終了しても、リビルドの実行は継続します)。nodetool rebuildコマンド自体からは、特に重要な出力はありません。その代わり、nodetool netstatsを使用し、各ノードのデータ・サイズを調べてリビルドの進捗状況を監視してください。
    注: nodetool statusで表示されデータ負荷が更新されるのは、所定のソース・ノードがストリーミングを終了した後なので、ディスクについて報告されるバイト数と開きがあるように見えます(例:du)。ストリーミング・エラーが発生した場合、ERRORメッセージがsystem.log に記録され、リビルドが停止します。一時的な障害が発生した場合は、nodetool rebuildを再度実行できます。その際、既に正常にストリーミングされた範囲はスキップされます。
  13. ネットワーク・トラフィックを釣り合わせるため、ソース・データ・センターのストリーミング・スロットルを調整します。「nodetool setstreamthroughput」を参照してください。
  14. すべてのリビルドが成功したことを、finished rebuildを検索して確認します。これは、新しいデータ・センターの各ノードの system.log に記録されています。
    注: まれに、2つのストリーミング・ノード間の通信がハングし、データがストリーミングされることなくリビルド操作が有効な状態になる場合があります。nodetool netstatsを使用してストリーミングの進捗状況を監視してください。ストリームに何の進捗も見られない場合は、nodetool rebuildが実行されたノードを再起動し、当初使用したものと同じパラメーターを使用してnodetool rebuildを再実行してください。
  15. 必要に応じ、新しいデータ・センターの各ノードでDataStax Agentを起動します。
  16. 必要に応じてOpsCenter Repair Service(リペア・サービス)を起動します。「Repair Service(リペア・サービス)をオンにする」を参照してください。