ワークロードの種類別に単一データ・センターを初期化する

ワークロードのタイプごとに、データ・センターを1つだけ持つ混在ワークロード・クラスターでノードを構成します。

1. 以下の手順を実行して、クライアント・アプリケーションが新しいデータ・センターに先に接続しないようにし、読み取りまたは書き込みの整合性レベルによって新しいデータ・センターに対してクエリーが実行されないようにするには、以下の手順を実行します。
   警告: DSE SearchやDSE Analyticsなどのクライアント・アプリケーションが適切に構成されていない場合、オンラインになる前に新しいデータ・センターに接続する可能性があります。構成が適切でない場合、接続の例外、タイムアウト、データの不整合の原因となります。
   1. DCAwareRoundRobinPolicyを使用するようクライアント・アプリケーションを構成します。
   2. クライアントを既存のデータ・センターに誘導します。そうしないと、クライアントは、まったくデータが存在しない可能性がある新しいデータ・センターにアクセスを試行する可能性があります。
   3. QUORUM整合性レベルを使用する場合は、LOCAL_QUORUMに変更します。
   4. ONE整合性レベルを使用する場合は、LOCAL_ONEに変更します。

   ドライバーのプログラミング手順を参照します。

2. 既存のデータ・センターで、SimpleStrategyレプリケーション・ストラテジが使用されている場合は、これをNetworkTopologyStrategyレプリケーション・ストラテジに変更します。
   1. 以下のキースペースについて、ALTER KEYSPACEを使用して、キースペースのレプリケーション・ストラテジをNetworkTopologyStrategyに変更します。

      ALTER KEYSPACE keyspace_name WITH REPLICATION = 
      {'class' : 'NetworkTopologyStrategy', 'DC1' : 3};

      • DSEセキュリティ：system_auth、dse_security
      • DSEパフォーマンス：dse_perf
      • DSE分析：dse_leases、dsefs
      • システム・リソース：system_traces、system_distributed
      • OpsCenter（インストールされている場合）
      • ユーザーが作成したすべてのキースペース
   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;

3. 新しいデータ・センターの各ノードにDSEをインストールします（「DSEのインストール」を参照）。サービスを開始したり、ノードを再起動しないでください。
   重要: クラスターのすべてのノードに同じバージョンのDSEを使用します。
4. クラスター内の他のノードの構成に従って、新しい各ノードでcassandra.yaml のプロパティを構成します。
   ヒント: yaml_diff toolを使用して、cassandra.yaml およびdse.yaml 構成ファイルを確認し、必要な変更を加えます。
   1. 以下のようにノードプロパティを構成します。
      • -seeds：各シード・ノードのinternal_IP_address
        重要: 各データ・センターから1つ以上のシード・ノードを含めます。DataStaxでは、複数のラックで、データ・センターごとに複数のシード・ノードを持つことを推奨しています。データ・センターごとのシード・ノード数として最も一般的な数は3です。すべてのノードをシード・ノードにしないでください。
      • auto_bootstrap：true

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

      • listen_address：empty

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

      • endpoint_snitch：snitch

        endpoint_snitchとsnitchesを参照してください。

        重要: 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）の構成」を参照してください。

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

      • ノードごとに初期トークンを生成して、その値をinitial_tokenプロパティに設定します。

        詳細については、「単一トークンのノードの追加または置き換え」を参照してください。

      • num_tokensとallocate_tokens_for_local_replication_factorの両方をコメントアウトします。
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つずつ起動した後で、残りのノードを起動します。
   • パッケージ・インストール： DataStax Enterpriseをサービスとして起動
   • tarボール・インストール： DataStax Enterpriseをスタンドアローン・プロセスとして起動
8. すべてのノードが起動するまでラックからのDSEの起動をローテーションします。
9. クラスターですべてのノードが実行中になり、クライアント・アプリケーションがデータ・センターで認識されたら、cqlshを使用してキースペースを変更し、ターゲット・レプリケーションを新しいデータ・センターに追加します。

   ALTER KEYSPACE keyspace_name WITH REPLICATION = 
   {'class' : 'NetworkTopologyStrategy', 'ExistingDC1' : 3, 'NewDC2' : 2};

   警告: DSE SearchやDSE Analyticsなどのクライアント・アプリケーションが適切に構成されていない場合、オンラインになる前に新しいデータ・センターに接続する可能性があります。構成が適切でない場合、接続の例外、タイムアウト、データの不整合の原因となります。
10. 再構築するデータ・センターを指定して、新しいデータ・センターの各ノードでnodetool rebuildを実行します。この手順によって、データがクラスターの新しいデータ・センターに複製されます。

    nodetool rebuild -- datacenter_name

    注意: コマンドラインに既存のデータ・センターを指定する必要があります。そうしないと、新しいノードはあたかもリビルドが成功したかのように見えますが、想定されたすべてのデータが含まれていない可能性があります。

    新しいデータ・センターへ整合性レベルLOCAL_ONEまたはONEを指定して要求を発行した場合は、既存のデータ・センターが完全に同期していないと失敗する可能性があります。

    1. 複数のノードで同時にnodetool rebuildを実行します。ノードごとにnodetool rebuildを実行すると、既存のクラスターに与える影響は減少します。
    2. または、クラスターが余分なI/Oとネットワーク負荷を処理可能な場合は、複数のノードで実行してください。
11. 新しいクラスターが起動して稼働していることを確認します。

    dsetool status

    注: DSEを起動するのに問題がある場合、「DSEの起動およびインストールのトラブルシューティング」を参照してください。
12. 3～11を完了して3番目のデータ・センター（DC3）をクラスターに追加します。

DC: Cassandra   Workload: Cassandra  Graph: no
==============================================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address         Load        Tokens    Owns    Host ID             Rack
UN 110.82.155.0    21.33 KB    256       33.3%   a9fa31c7-f3c0-...   RAC1
UN 110.82.155.1    21.33 KB    256       33.3%   f5bb416c-db51-...   RAC1
UN 110.54.125.1    21.33 KB    256       16.7%   b836748f-c94f-...   RAC2

DC: Analytics
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address         Load        Owns      Host ID               Tokens         Rack
UN 110.54.125.2    28.44 KB    13.0.%    e2451cdf-f070- ...    -922337....    RAC1
UN 110.82.155.2    44.47 KB    16.7%     f9fa427c-a2c5- ...    30745512...    RAC2 
UN 110.82.155.3    54.33 KB    23.6%     b9fc31c7-3bc0- ..-    45674488...    RAC1

DC: Solr 
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address         Load        Owns      Host ID               Tokens         Rack
UN 110.54.125.3    15.44 KB    50.2.%    e2451cdf-f070- ...    9243578....    RAC1
UN 110.82.155.4    18.78 KB    49.8.%    e2451cdf-f070- ...    10000          RAC2