NFS ストレージを使用した Google Kubernetes Engine への IBM Db2 Warehouse のデプロイ

このチュートリアルでは、ストレージ層としてネットワーク ファイル システム（NFS）ボリュームを使用して、Google Kubernetes Engine（GKE）上に IBM Db2 Warehouse クラスタを作成する方法を説明します。共有ストレージ ソリューション用の NFS バックエンドとして Filestore を使用します。ただし、クラウド デプロイ可能な他の NFS ソリューションを選択することもできます。

このチュートリアルは、システム管理者、デベロッパー、エンジニア、データベース管理者が、Google Cloud 上に IBM Db2 Warehouse クラスタをデプロイする場合に役立ちます。

IBM Db2 Warehouse と Google Cloud 上でのデプロイ オプションの概要については、シリーズの概要をご覧ください。

このチュートリアルでは、次のソフトウェアを使用します。

• Ubuntu-server 16.04
• IBM Db2 Warehouse Enterprise Edition
• IBM Db2 Warehouse クライアント

目標

• Docker Store にある IBM Db2 Warehouse Docker イメージにアクセスします。
• Filestore インスタンスを作成します。
• GKE クラスタを起動します。
• クラスタが実行中であることを検証します。
• GKE クラスタで Docker Store 認証を初期化します。
• クラスタに NFS クライアント プロビジョナーをデプロイして実行します。
• クラスタに IBM Db2 Warehouse コンテナをデプロイして実行します。
• IBM Db2 Warehouse でサンプルデータをアップロードします。
• IBM Db2 管理コンソールに接続します。

料金

このチュートリアルでは、Google Cloud の課金対象となる以下のコンポーネントを使用します。

• GKE
• Filestore
• ネットワーキング

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを作成できます。

始める前に

1. Google Cloud アカウントにログインします。Google Cloud を初めて使用する場合は、アカウントを作成して、実際のシナリオでの Google プロダクトのパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。

2. Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

   注: この手順で作成するリソースをそのまま保持する予定でない場合、既存のプロジェクトを選択するのではなく、新しいプロジェクトを作成してください。チュートリアルの終了後にそのプロジェクトを削除すれば、プロジェクトに関連するすべてのリソースを削除できます。

   プロジェクト セレクタに移動

3. Cloud プロジェクトに対して課金が有効になっていることを確認します。詳しくは、プロジェクトで課金が有効になっているかどうかを確認する方法をご覧ください。

4. GKE and Filestore API を有効にします。

   API を有効にする

5. Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

   注: この手順で作成するリソースをそのまま保持する予定でない場合、既存のプロジェクトを選択するのではなく、新しいプロジェクトを作成してください。チュートリアルの終了後にそのプロジェクトを削除すれば、プロジェクトに関連するすべてのリソースを削除できます。

   プロジェクト セレクタに移動

6. Cloud プロジェクトに対して課金が有効になっていることを確認します。詳しくは、プロジェクトで課金が有効になっているかどうかを確認する方法をご覧ください。

7. GKE and Filestore API を有効にします。

   API を有効にする

8. Docker ID をお持ちでない場合は、Docker Store で作成してください。

このチュートリアルでは、IBM Db2 Warehouse Enterprise Edition を使用します。このソフトウェアのライセンスをまだお持ちでない場合は、無料の試用版をこのチュートリアルで使用できます。

このチュートリアルを終了した後、作成したリソースを削除すると、それ以上の請求は発生しません。詳細については、クリーンアップをご覧ください。

アーキテクチャ

このチュートリアルでは、3 つの異なる Google Cloud ゾーンに GKE を使用して Kubernetes クラスタをデプロイします。クラスタでは、IBM Db2 Warehouse の 3 つのインスタンスをデプロイします。

• db2wh-1 という名前のインスタンスが、最初にヘッドノードとして指定されています。
• db2wh-2 および db2wh-3 という名前のインスタンスが、最初にデータノードとして指定されています。

ヘッドノードがフェイルオーバーすると、個々のインスタンスのロール（ヘッドノードまたはデータノード）が変わる可能性があります。

また、db2wh-data-nfs という名前の Filestore インスタンスもデプロイします。これはクラスタノードの共有ストレージとして機能します。

次の図にアーキテクチャを示します。

IBM Db2 Warehouse Edition の Docker イメージにアクセスする

このチュートリアルでは、Docker Store アカウントを使用して Docker Store から無料の試用版 IBM Db2 Warehouse Edition をダウンロードします。これには、サーバーとクライアントの 2 つの別個のイメージをダウンロードすることが含まれます。

1. ブラウザで、IBM Db2 Warehouse EE Docker イメージに移動します。

2. Docker のユーザー名とパスワードを使ってログインします。

3. [Proceed to checkout] をクリックします。

4. 詳細を記入します。

5. 利用規約に同意する場合は、右側の [I agree ...] と [I acknowledge ...] のチェックボックスをオンにします。

6. [Get Content] をクリックします。

   自動的に [Setup] ページに移動します。このページの手順はチュートリアルの後半で行うので、現時点で行う必要はありません。

7. IBM Db2 Warehouse クライアント イメージについても同じプロセスを繰り返します。

環境の準備

このチュートリアルでは、デフォルト リージョンとして us-central1 を使用し、デフォルト ゾーンとして us-central1-b を使用します。リージョンとゾーンをデフォルトに設定しておくと、Google Cloud CLI で Compute Engine ゾーン オプションを入力する時間を節約できます。

このチュートリアルのほとんどの手順は、Cloud Shell で実行します。また、Cloud Shell を開くと、このチュートリアルに関連する GitHub リポジトリのクローンを自動的に作成することもできます。

1. Cloud Shell を開きます。

   Cloud Shell を開く

2. デフォルトのリージョンとゾーンを設定します。

   gcloud config set compute/region us-central1
   gcloud config set compute/zone us-central1-b
   

Filestore インスタンスの作成

次のステップでは、Filestore データベース インスタンスを作成します。

• Cloud Shell で、Filestore インスタンスを作成します。

  gcloud beta filestore instances create db2wh-data-nfs \
      --location=us-central1-c \
      --tier=STANDARD \
      --file-share=name="db2whdata",capacity=1TB \
      --network=name="default",reserved-ip-range="10.0.0.0/29"
  

  これにより、1 TB の容量を持つ db2wh-data-nfs という名前のスタンダード ティアの Filestore インスタンスと、db2whdata という名前のマウント ポイントが作成されます。

GKE クラスタを管理するためのサービス アカウントのプロビジョニング

このチュートリアル用に、GKE クラスタで Compute Engine インスタンスを管理するためのサービス アカウントを作成します。GKE クラスタノードは、デフォルトのサービス アカウントの代わりにこのサービス アカウントを使用します。ベスト プラクティスとして、サービス アカウントの権限をアプリケーションの実行に必要なロールとアクセス許可だけにすることをおすすめします。

サービス アカウントに必要なロールは、Compute 管理者のロール（roles/compute.admin）のみです。このロールによって、すべての Compute Engine リソースを完全に制御できます。サービス アカウントは、GKE クラスタノードを管理するためにこのロールを必要とします。

1. Cloud Shell で、サービス アカウント名を格納する環境変数を作成します。

   export GKE_SERVICE_ACCOUNT_NAME=db2dw-gke-service-account
   

2. サービス アカウントを作成します。

   gcloud iam service-accounts create $GKE_SERVICE_ACCOUNT_NAME \
       --display-name=$GKE_SERVICE_ACCOUNT_NAME
   

3. サービス アカウントのメール アカウント名を格納する環境変数を作成します。

   export GKE_SERVICE_ACCOUNT_EMAIL=$(gcloud iam service-accounts list \
       --format='value(email)' \
       --filter=displayName:"$GKE_SERVICE_ACCOUNT_NAME")
   

4. サービス アカウントに compute.admin ロールをバインドします。

   gcloud projects add-iam-policy-binding \
       $(gcloud config get-value project 2> /dev/null) \
       --member serviceAccount:$GKE_SERVICE_ACCOUNT_EMAIL \
       --role roles/compute.admin
   

GKE クラスタの準備

このセクションでは、GKE クラスタを起動し、権限を付与して、クラスタ構成を終了します。

GKE クラスタを起動する

ここで、GKE クラスタを作成して起動できます。

• Cloud Shell で、ゾーンごとに単一のノードを持つ、リージョンの GKE クラスタを作成します。

  gcloud container clusters create ibm-db2dw-demo \
      --enable-ip-alias \
      --image-type=ubuntu \
      --machine-type=n1-standard-16 \
      --metadata disable-legacy-endpoints=true \
      --node-labels=app=db2wh \
      --node-locations us-central1-a,us-central1-b,us-central1-c \
      --no-enable-basic-auth \
      --no-issue-client-certificate \
      --num-nodes=1 \
      --region us-central1 \
      --service-account=$GKE_SERVICE_ACCOUNT_EMAIL
  

  これにより、ibm-db2dw-demo という名前のクラスタが作成されます。

1 つのノードプール（デフォルト ノードプール）だけでこのクラスタを作成しているので、このクラスタのすべてのノードが IBM Db2 Warehouse ワークロードを実行できます（ラベル付きノードのみが IBM Db2 Warehouse ポッドをホストできます）。さらに分離する必要がある場合（たとえば IBM Db2 Warehouse 専用のノードが必要な場合）には、新しいノードプールまたは専用クラスタのいずれかを作成できます。

Docker Store 認証を管理する

このチュートリアルでは、Docker Store 認証情報を格納するためのシークレットを作成して、GKE クラスタが Docker Store から IBM Db2 Warehouse Docker イメージをダウンロードできるようにします。詳細については、Kubernetes ドキュメントの該当するセクションをご覧ください。この方法は、プライベート Docker レジストリ インスタンスにも有効です。

1. Cloud Shell で、Docker Store（これから使用する Docker レジストリ インスタンス）にログインします。

   docker login
   

2. Docker Store の認証情報を使用して Kubernetes シークレットを作成します。

   kubectl create secret generic dockerstore \
       --type=kubernetes.io/dockerconfigjson \
       --from-file=.dockerconfigjson="$HOME"/.docker/config.json
   

ユーザーにクラスタ管理者権限を付与する

GKE ドキュメントで説明されているように、GKE で新しい役割を作成する権限をユーザーに与える必要があります。

• Cloud Shell で、ユーザーに新しい役割を作成する権限を付与します。

  kubectl create clusterrolebinding cluster-admin-binding \
      --clusterrole cluster-admin \
      --user $(gcloud config list \
      --format 'value(core.account)')
  

NFS クライアント プロビジョナーをデプロイする

このチュートリアルでは、クラスタに NFS クライアント プロビジョナーをデプロイします。このプロビジョナーは、PersistentVolumeClaims をサポートするために Filestore インスタンスで PersistentVolumes を初期化します。

1. Cloud Shell で、NFS リソースを管理するためのサービス アカウントを作成します。

   kubectl apply -f solutions-db2wh/nfs/rbac.yaml
   

2. NFS クライアント プロビジョナーをデプロイします。

   kubectl apply -f solutions-db2wh/nfs/deployment.yaml
   

3. NFS ボリュームで PersistentVolumeClaim をサポートするための StorageClass を作成します。

   kubectl apply -f solutions-db2wh/nfs/class.yaml
   

4. NFS クライアント プロビジョナー ポッドが Running として報告されるのを待ちます。

   kubectl get pods --watch
   

   実行中の場合、出力に Running が表示されます。

   nfs-client-provisioner   1/1       Running   0         10s
   

ノードファイルを作成する

次に、各インスタンスをブートストラップするために IBM Db2 Warehouse で必要となる構成ファイルを作成できます。

1. Cloud Shell で、nodes ファイルを作成します。

   kubectl get nodes -o=jsonpath="{range \
   .items[?(@.metadata.labels.app=='db2wh')]}\
   {.metadata.name}{':'}{.status.addresses[?(@.type=='InternalIP')]\
   .address}{\"\n\"}{end}" | sed '1s/^/head_node=/' | \
   sed -e '2,$ s/^/data_node=/' > nodes
   

2. nodes ファイルを格納する ConfigMap を作成します。

   kubectl create configmap db2wh-nodes --from-file=nodes
   

注: 現在のバージョンの IBM Db2 Warehouse の既知の要件として、ネットワーク トポロジを変更する場合（スケールアップする場合など）は必ず、すべてのインスタンスを停止し、nodes ファイルを更新してから、インスタンスを再起動する必要があります。通常、Kubernetes Pod が再スケジュールされると、ネットワーク トポロジも変わります。デプロイでは、以下のようにしてこれを回避できます。

• ノード アフィニティを使用する。IBM Db2 Warehouse Pod は、app=db2wh ラベルが付いたノードでのみスケジュールされます。
• Pod の反アフィニティを使用する。ノードごとに存在できる IBM Db2 Warehouse Pod は 1 つだけです。
• Pod を再スケジュールするたびに StatefulSet 内のすべての Pod を停止 / 再開するのを回避するために、IBM Db2 Warehouse Pod にホスト ネットワーキングを使用する。

IBM Db2 Warehouse ポッドのデプロイ

ここでは、IBM Db2 Warehouse を実行するのに必要なすべての GKE ポッドを作成します。

1. Cloud Shell で、PersistentVolumeClaim を作成します。PersistentVolumeClaim オブジェクトを使用すると、クラスタは複数のポッドで同時に NFS ストレージを PersistentVolume としてマウントできます。

   kubectl apply -f solutions-db2wh/persistent-volume-claim.yaml
   

2. NFS ボリューム内の nodes ファイルをコピーする Job を実行します。

   kubectl apply -f solutions-db2wh/nodes-file-deploy-job.yaml
   

3. nodes ファイル デプロイジョブが実行されたことを確認します。

   kubectl get jobs --watch
   

   nodes-config が Successful として報告されると、Job は実行されています。

   NAME           DESIRED   SUCCESSFUL   AGE
   nodes-config   1         1            19s
   

4. LoadBalancer Service をデプロイして、IBM Db2 Warehouse 管理コンソールへのアクセスを許可します。

   kubectl apply -f solutions-db2wh/service.yaml
   

5. db2wh-ext という名前の LoadBalancer Service に外部 IP アドレスが割り当てられるまで待ちます。

   kubectl get services --watch
   

   出力に、CLUSTER-IP と EXTERNAL-IP の IP アドレスが表示されます。

   NAME       TYPE         CLUSTER-IP   EXTERNAL-IP  PORT(S)                         AGE
   db2wh-ext  LoadBalancer yy.yy.yy.yy  xx.xx.xx.xx  8443:30973/TCP,50000:30613/TCP  7s
   

6. StatefulSet をデプロイして IBM Db2 Warehouse Pod を起動します。

   kubectl apply -f solutions-db2wh/statefulset.yaml
   

7. IBM Db2 Warehouse Pod（db2wh-0、db2wh-1、db2wh-2）が実行されていることを確認します。

   kubectl get pods --watch
   

   登録には数分かかることがあります。

   すべての Pod のステータスが Running になると、Pod は実行されています。

   db2wh-1   0/1       Running   0         3m
   db2wh-2   0/1       Running   0         3m
   db2wh-0   0/1       Running   0         3m
   

8. IBM Db2 Warehouse ヘッドノードを実行しているノードの IP アドレスを格納する環境変数を作成します。

   HEAD_NODE_IP=$(grep "head_node" nodes | awk -F ':' '{print $2}')
   

9. ヘッドノード ポッド名を格納する環境変数を作成します。

   HEAD_NODE_POD_NAME=$(kubectl get pods \
   --field-selector=status.phase=Running -o=jsonpath="{range \
   .items[?(@.metadata.labels.app=='db2wh')]} \
   {.metadata.name}{':'}{.status.\
   hostIP}{'\n'}{end}" | grep $HEAD_NODE_IP | awk -F ':' '{print $1}')
   

10. いずれかのポッドのログを調べて、ブートストラップ プロセスが問題なく実行されていることを確認します。

    kubectl exec -it $HEAD_NODE_POD_NAME -- status --check-startup
    

    これには 40〜60 分かかることがあります。その間にエラーがいくつか検出されることもありますが、このチュートリアルでは無視してかまいません。

    出力に running successfully のステータスが表示されたら、プロセスは正しく実行されています。

    HA Management up and running successfully!
    Successfully started IBM Db2 Warehouse service stack!
    

11. 管理コンソールのパスワードを設定します。

    DB2_ADMIN_PASSWORD=$(openssl rand -hex 8)
    kubectl exec -it $HEAD_NODE_POD_NAME -- setpass ${DB2_ADMIN_PASSWORD}
    

注: ヘッドノードを実行している Pod のみが GKE によって Ready とマークされます。これは、その Pod のみが管理コンソールを実行しているためです。その他の Pod は、Ready とマークされていなくても、データノードをホストしています。

デプロイをテストする

ポッドの構成が完了したので、次はデプロイをテストできます。

IBM Db2 Warehouse クライアント コンテナをデプロイする

IBM Db2 Warehouse にデータをアップロードするために、クライアント コンテナをデプロイし、Kubernetes ConfigMap を使用してサンプルデータをそれにマッピングできます。

1. Cloud Shell で、サンプルデータを格納する ConfigMap を作成します。

   kubectl create configmap sample-data \
       --from-file=solutions-db2wh/sample-data/nyc-wifi-locs.csv \
       --from-file=solutions-db2wh/sample-data/sample-table.sql
   

2. Deployment を作成して IBM Db2 Warehouse クライアント コンテナを開始します。

   kubectl apply -f solutions-db2wh/client.yaml
   

3. IBM Db2 Warehouse クライアント ポッドが実行されていることを検証します。

   kubectl get pods --watch
   

   登録には数分かかることがあります。

   ステータスが Running と表示されたら、Pod は実行中です。

   db2wh-client-xxxxx-xxxx   1/1       Running   0         3m
   

サンプルデータをアップロードする

デプロイのテストの一環として、サンプルデータを IBM Db2 Warehouse サーバーにアップロードします。

1. Cloud Shell で、以前に作成したパスワードを表示します。

   echo $DB2_ADMIN_PASSWORD
   

2. IBM Db2 Warehouse クライアントのコンテナ名を格納する環境変数を作成します。

   CLIENT_CONTAINER_NAME=$(kubectl get pods -l app=db2wh-client -o=jsonpath='{.items[0].metadata.name}')
   

3. クライアント コンテナでシェル ウィンドウを開きます。

   kubectl exec -it $CLIENT_CONTAINER_NAME -- cli
   

4. パスワードを格納する環境変数を作成します。[PASSWORD] は、先の手順で取得したパスワードにします。

   DB_PASSWORD=[PASSWORD]
   

5. データベース エイリアスを格納する環境変数を作成します。

   DB_ALIAS=BLUDB
   

   BLUDB は、IBM Db2 Warehouse のデフォルトのデータベース名です。

6. データベース ホスト名を格納する環境変数を作成します。

   DB_HOST=db2wh-ext.default.svc.cluster.local
   

7. データベース カタログを設定します。

   db_catalog --add $DB_HOST --alias $DB_ALIAS
   

8. IBM Db2 Warehouse サーバーにサンプルデータを保持するためのテーブルを作成します。

   dbsql -f /sample-table.sql -d $DB_ALIAS -h $DB_HOST -u bluadmin -W $DB_PASSWORD
   

9. データを IBM Db2 Warehouse サーバーにアップロードします。

   dbload -verbose -host $DB_HOST -u bluadmin \
   -pw $DB_PASSWORD -db $DB_ALIAS -schema BLUADMIN \
   -t NYC_FREE_PUBLIC_WIFI -df /nyc-wifi-locs.csv -delim ',' \
   -quotedValue DOUBLE -timeStyle 12HOUR -skipRows 1
   

10. IBM Db2 Warehouse クライアント シェルを閉じます。

    exit
    

管理コンソールを使用してデータを検証する

これで IBM Db2 Warehouse 管理コンソールに接続し、アップロードしたデータを検証できるようになりました。

1. Cloud Shell で、サービスの外部 IP アドレスを見つけます。

   kubectl get svc db2wh-ext
   

2. ブラウザを開き、次の URL にアクセスします。[EXTERNAL_IP] は、前の手順で取得した IP アドレスにします。

   https://[EXTERNAL_IP]:8443
   

   セキュリティ警告は無視できます。

3. 次の認証情報でログインします。

   • ユーザー名: bluadmin
   • パスワード: （前の手順で作成したパスワード）

4. IBM Db2 Warehouse EULA に同意する場合は、[Accept] をクリックします。

5. 左側のメニューを開き、[Administer] > [Tables] を選択します。

   

6. [Quick Tour] ポップアップを閉じます。

7. NYC_FREE_PUBLIC_WIFI をクリックします。

   

8. [Data Distribution] タブをクリックして、テーブルにデータが入力されていることを確認します。

   

   合計で 2,871 行あることがわかります。これはデータセット全体です。

9. [Generate SQL] クリックします。

10. [SELECT statement] を選択します。

11. [OK] をクリックします。

    [Generate SQL] タブが開き、自動生成された SELECT ステートメントが事前に入力されます。

12. 自動生成された SELECT ステートメントに LIMIT 句を追加して、結果を最初の 5 つのレコードに制限します。

    SELECT "THE_GEOM", "OBJECTID", "BORO", "TYPE", "PROVIDER", "NAME", "LOCATION",
           "LAT", "LON", "X", "Y", "LOCATION_T", "REMARKS", "CITY", "SSID",
           "SOURCEID", "ACTIVATED", "BOROCODE", "BORONAME", "NTACODE", "NTANAME",
           "COUNDIST", "POSTCODE", "BOROCD", "CT2010", "BOROCT2010", "BIN", "BBL", "DOITT_ID"
      FROM "BLUADMIN"."NYC_FREE_PUBLIC_WIFI"
      LIMIT 5;
    

13. [Run] をクリックしてから、[Run All] を実行します。

    レコードのリストが [Result Set] タブに表示され、サンプルデータが正常にアップロードされたことが示されます。

    

クリーンアップ

このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを維持して個々のリソースを削除します。

プロジェクトの削除

注意: プロジェクトを削除すると、次のような影響があります。
• プロジェクト内のすべてのものが削除されます。このチュートリアルで既存のプロジェクトを使用した場合、それを削除すると、そのプロジェクトで行った他の作業もすべて削除されます。
• カスタム プロジェクト ID が失われます。このプロジェクトを作成したときに、将来使用するカスタム プロジェクト ID を作成した可能性があります。そのプロジェクト ID を使用した URL（たとえば、appspot.com）を保持するには、プロジェクト全体ではなくプロジェクト内の選択したリソースだけを削除します。
1. コンソールで [リソースの管理] ページに移動します。

   [リソースの管理] に移動

2. プロジェクト リストで、削除するプロジェクトを選択し、[削除] をクリックします。
3. ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

次のステップ

• このシリーズの他のドキュメントを見る。
  • Google Cloud での IBM Db2 Warehouse デプロイ戦略（概要）
  • GlusterFS ストレージを使用した Google Kubernetes Engine への IBM Db2 Warehouse のデプロイ
  • NFS ストレージを使用した Compute Engine への IBM Db2 Warehouse のデプロイ
  • GlusterFS ストレージを使用した Compute Engine への IBM Db2 Warehouse のデプロイ
• IBM Db2 Warehouse のアーキテクチャを確認する。
• IBM Db2 Warehouse の要件をお読みください。
• Google Cloud に関するリファレンス アーキテクチャ、図、チュートリアル、ベスト プラクティスを確認する。Cloud Architecture Center を確認します。