目次


DB2 pureScale をクラウド環境で動かしてみよう

スケールアウトできる高可用性データベースをクラウド環境で試す

Comments

はじめに

リレーショナル・データベースにとって、システムをいかに大量の処理に対してスケールできるようデザインするかは、古くて新しい問題です。「大量のデータ」に対しては、シェアード・ナッシングのアーキテクチャでスケールアウトさせる手法が多くのソリューションで採用されており、IBM もアプライアンスである PureData やクラウドで提供するデータベース(DBaaS)である IBM dashDB for Analytics MPP を提供しています。ところが、「大量のトランザクション処理」に対しては、そのようなシェアード・ナッシングのアプローチではリレーショナル・データベースをうまくスケールアウトさせることはできません。NoSQL データベースで利用される分散データベース環境では、1 つのトランザクションが必要とするデータを特定のノードに限定して処理できるのに対して、リレーショナル・データベースでは SQL が要求する「リレーショナル」な照会を実現するために、他のノードが保持するデータを含めた「データ同士の関係性」をマッチングする処理が不可欠です。そのため、シェアード・ナッシングのリレーショナル・データベースで高負荷なオンライン・トランザクション処理を行うと、データ同士の関連性をマッチングする処理によってサーバー間の通信が多量に発生してボトルネックになり、サーバーを増やしても処理能力が向上しないという状況に陥ってしまいます。

ではどうやって大量のトランザクションへ対処するべきなのか?「リレーショナル・データベースはスケールアウトが難しい」という課題に対して、多くのソリューションでは「読み込み専用のレプリカ」を作成して参照トランザクションを分散させるなど、複数のサーバーで役割を分担することによって大量のトランザクションを処理しています。しかし、レプリケーションによって更新の伝搬を行うと、レプリカ側には直前に更新されたデータは到達していないかもしれません。アプリケーションは参照するデータの鮮度については一定の割り切りをしたり、アプリケーション側でチェックするロジックを盛り込んだりと、様々な工夫が必要になります。このあたりのトレードオフについては、データベースの「シャーディング(Sharding)」や「スケールアウト」といったキーワードで、様々なところで議論されているので、興味のある方は調べてみてください。

そのような、アプリケーション側での「割り切り」を必要とせず、どのサーバーにアクセスしてもデータ一貫性を持って更新や参照できたりするような、スケールアウト型のトランザクション処理向けデータベースはないでしょうか?あります。IBM の提供する DB2 pureScale は、まさにそのような要望を満たすために作られた高可用性と拡張性を実現したデータベースです。

本番環境で利用する DB2 pureScale は、求められる非常に高い可用性と拡張性を実現するために、ハードウェア・インフラの観点からも SAN ストレージや RDMA(Remote Direct Memory Access)による超高速ネットワーク通信経路が推奨されています。そのため、これまでは気軽に試してみる事が出来ませんでした。DB2 10.5 FP4 では、RDMA に代えて TCP/IP を利用できる「Lite モード」の pureScale が登場したことで、RDMA に対応した通信アダプターがなくても DB2 pureScale が構成できるようになりました。そこで、この記事では、だれでも利用できるクラウド環境上で、テストや評価の目的に特化した DB2 pureScale を構築する手順を説明していきます。

DB2 pureScale の機能についてもっと知りたい方は、「DB2 LUW V11.1 速習講座(ハンズオン付き)」をご覧になってください。pureScale だけではなく DB2 のいろいろな機能をご紹介しています。

この記事で利用する環境

この記事では、多くの人が利用できるテスト環境として、Amazon Web Services(AWS)を使用します。AWS 上に 5 台の仮想サーバー(EC2 インスタンス)を作成し、4 台を DB2 pureScale のサーバー(メンバーが 2 台、CF が 2 台)として、1 台を iSCSI のサーバーとして構成します。AWS が提供するブロックストレージである EBS は、複数の EC2 インスタンスにアタッチすることができないので、テスト環境として割り切ることを前提に 1 台の仮想サーバーを iSCSI のサービスを提供するサーバーとして構成して、共有ディスクとして利用します。

下の図に構築する環境の概要を示しています。AWS の東京リージョンにサブネットを作成し、そのサブネット内に 5 つの EC2 インスタンスを作成します。ここではデフォルトの VPC(Virtual Private Network)内に、インターネットからアクセス可能なパブリック・サブネットとして作成していますが、ご自身の環境に合わせて作成していただいて問題ありません。

この記事では Amazon Web Services を利用していますが、IBM が提供するパブリック・クラウド環境である IBM Bluemix Infrastructure(旧 SoftLayer)や、VMWare/VirtualBox のような仮想化環境を利用することも可能です。ご自身の環境を用意される場合は、IP アドレスなどの設定値は随時読み替えてください。

Amazon Web Services 上に仮想サーバーを作成する

それでは、DB2 pureScale を稼働させるために、まず AWS の環境を整備していきます。AWS 環境の整備は以下のステップで行います。

  1. AWS アカウントの作成
  2. テスト環境で利用するサブネットをデフォルト VPC 内に作成する
  3. 公開鍵認証で利用するキーペアを作成する
  4. 仮想ファイアーウオールとして利用するセキュリティグループを作成する
  5. テスト環境として使う仮想サーバー(EC2 インスタンス)を作成する
  6. 仮想サーバーに静的なホスト名を設定する
1

AWS アカウントの作成

AWS をまだ利用していない場合は、最初に AWS のアカウントを作成します。Amazon の Web ページのガイドに従って作成してください。作成が完了したら AWS のマネジメントコンソールにログインします。

2

テスト環境で利用するサブネットをデフォルト VPC 内に作成する

次に、今回の EC2 インスタンスが利用するサブネットを作成します。AWS マネジメントコンソールの左上に表示される「サービス」から「ネットワーキング & コンテンツ配信」セクションにある「VPC」を選択してください。

VPC ダッシュボードが表示されてから、左側のパネルに表示される「サブネット」を選択します。

右側のフレームが更新されるので、表示された画面から「サブネットの作成」ボタンをクリックします。

「サブネットの作成」パネルに必要な項目を入力します。ここでは、以下のような入力値を選択しました。既存の AWS 環境に作成する場合は、環境構成に合わせて修正してください。

表 1. サブネットの設定内容
項目設定値
ネームタグpureScale servers(任意の名前で OK)
VPCデフォルト VPC(変更せず)
アベイラビリティゾーンap-northeast-1b
CIDR ブロック172.31.32.0/24

作成ボタンをクリックすると、指定した CDIR を持つサブネットが作成されます。このサブネットの名前は EC2 インスタンスを作成するときに指定するため、覚えておいてください。

デフォルトでは、「自動割り当てパブリック IP」が無効になっているため、有効にします。ブラウザ画面の上の方にある「サブネットのアクション」から「自動割り当てパブリック IP の変更」を選択して、チェックボックスにチェックを入れ、保存ボタンをクリックしてください。

これでサブネットは作成できました。

3

公開鍵認証で利用するキーペアを作成する

次に、作成する仮想サーバーに SSH ログインするためのキーペアを作成します。このステップで作成するキーペアを EC2 インスタンスの作成時に指定することで、作成される仮想サーバーにこのキーペアを利用した公開鍵認証でリモートログインできるようになります。

ふたたびコンソール左上の「サービス」から今度は「EC2」を選択します。表示される EC2 ダッシュボードの左側パネルから「ネットワーク & セキュリティ」セクションにある「キーペア」を選択してください。

次に「キーペアの作成」ボタンをクリックして、新しいキーペアを作成します。

ここで指定するのはキーペアの名前だけです。名前は何でもかまいません、ここでは、わかりやすいように「db2pureScale_keypair」としておきます。

キーペアの作成が終わると鍵ファイルのダウンロード画面が出てきます。この鍵ファイルは仮想サーバーにアクセスするために必要なので、必ず端末上に保管しておいてください。

これでキーペアの作成は完了です。

4

仮想ファイアーウオールとして利用するセキュリティグループを作成する

最後にセキュリティグループを作成します。セキュリティグループとは、AWS 環境で利用できる仮想のファイアーウオールです。インターネットからアクセスできるサブネットに仮想サーバーを作成すると、インターネットから仮想サーバーにネットワークアクセスが可能になるため、セキュリティグループを適切に設定して、許可した通信のみが仮想サーバーに到達できるように構成する必要があります。

今回は、2 つのルールを作成します。

  1. 操作する端末にアサインされたグローバル IP からのみ SSH(ポート 22)のインバウンド通信を受け入る。
  2. サブネット内のプライベート・アドレス間ではすべてのポートへのインバウンド通信を許す。

アウトバウンド通信(仮想サーバーから外部への通信)については、セキュリティグループのデフォルト設定ですべて許可されるので、そのままにしておきます。今回は手順の紹介が主眼なので上記のような簡易的なセキュリティ設計を利用しますが、実際に作成する際は、利用される環境のセキュリティポリシーに沿った設計を行ってください。

先ほどと同じ「ネットワーク & セキュリティ」セクションにある「セキュリティグループ」を選択してください。そして、「セキュリティグループの作成」ボタンをクリックします。表示される「セキュリティグループの作成」画面に、必要事項を入力していきます。

下の画像のように、インバウンドに 2 つのルールを追加します。ひとつは SSH(ポート 22)で、「送信元」には「マイ IP」を選択してください。このルールはこの後のステップで作成する EC2 インスタンスへの SSH アクセスを許可するための設定です。AWS マネジメントコンソールが端末に割り振られたグローバル IP アドレスをセットしてくれます。他の IP アドレスからの通信を受け入れないように第 4 オクテットまで記述され、サブネットマスクは「/32」となっています。もうひとつのルールは pureScale のサーバー間での通信を許可するための設定で、前のステップで作成した「172.31.32.0/24」サブネット内でのみ、すべてのトラフィックを許可するようにしています。

入力が終わったら、作成ボタンをクリックして完了させます。セキュリティグループの一覧に、作成したセキュリティグループが表示されます。

5

テスト環境として使う仮想サーバー(EC2 インスタンス)を作成する

それでは、EC2 インスタンスの作成に入ります。iSCSI サーバー用を 1 台と、pureScale サーバー用を 4 台作成します。

pureScale は前提ソフトウェアの記述で Linux のディストリビューションとバージョンを指定しています。DB2 11.1 では Red Hat Enterprise Linux(以下、RHEL)の 6.7 もしくは 7.2 をサポートします。そのため、この記事では RHEL 7.2 を利用します。

(注:記事執筆当時の情報です。DB2 の前提ソフトウェアに関しては、必ず最新情報をご確認ください)

まず、これまでの手順と同じように AWS マネジメントコンソールの左側にあるパネルから「インスタンス」をクリックして、EC2 インスタンスの管理画面に遷移します。そして、「インスタンスの作成」ボタンをクリックします。

インスタンスの作成画面では、まず Amazon Machine Image(AMI)を選択します。AMI とは仮想サーバーで稼働させるためのソフトウェアを、OS や場合によってはミドルウェアまで含めてパッケージで提供するものです。ここでは、特定バージョンの RHEL を利用するために、「コミュニティ AMI」を選択し、「ami-0dd8f963」を検索します。

RHEL-7.2 の AMI が確認できたら選択ボタンをクリックして作成を進めます。

まずは iSCSI サーバーとして利用するサーバーを作成します。「ステップ 2: インスタンスタイプの選択」では、どのタイプのインスタンスを利用するかを選択します。インスタンスタイプによって利用できる CPU 能力やメモリーの量が異なります。iSCSI サーバーはそれほど多くのメモリーは必要としないので、vCPU 1、メモリー 1GB の「t2.micro」を選択します。

「ステップ 3:インスタンスの詳細の設定」では、「サブネット」に前のステップで作成したサブネット「pureScale servers」を選択します。それ以外の選択肢はデフォルトのままでかまいません。

「ステップ 4:ストレージの追加」では、pureScale のサーバーから利用するストレージを 2 つ追加します。「新しいボリュームの追加」ボタンで新しいエントリーが追加されます。1 つは pureScale インスタンスの共有領域に、もう一つは Tiebreaker DISK として利用します。ここでは、両方とも 10GB 程度のサイズにしておきます。

次に、EC2 インスタンスを識別するためのタグを指定します。ここでは、iSCSI サーバーであることがわかるように「pureScale iSCSI」とします。

最後に、セキュリティグループを選択します。「既存のセキュリティグループを選択する」を選ぶと、前のステップで作成したセキュリティグループが表示されます。セキュリティグループが選択できたら、「確認と作成」のボタンをクリックし、正しく作成できていることが確認できたあと「作成」ボタンをクリックします。

「確認」ボタンをクリックすると、仮想サーバーに配布するキーペアを選択するパネルが表示されます。前のステップで作成した「db2pureScale_keypair」を選択して、その下のチェックボックスにもチェックを入れた後に「インスタンスの作成」ボタンをクリックしてください。

これで、iSCSI サーバー用のインスタンスの作成ができました。

次に、pureScale サーバー用のインスタンスを 4 台作成します。手順は iSCSI サーバーとほとんど同じです。

「ステップ 1: Amazon マシンイメージ(AMI)」では、iSCSI サーバーと同じように「ami-0dd8f963」を選択します。

「ステップ 2: インスタンスタイプの選択」では、8GB のメモリーを持つ「t2.large」を選択します。

「ステップ 3: インスタンスの詳細の設定」では、iSCSI サーバーの時と同じサブネット「pureScale servers」を指定した上で、「インスタンス数」には 4 を指定します。この指定で 4 台のインスタンスが同時に作成されます。

「ステップ 4: ストレージの追加」では、追加のストレージは必要ありません。そのかわり、ルートボリュームのサイズを 30GB に変更します。これは、pureScale が必要とする空き容量を確保するためです。詳細についてはマニュアルの「表 2. ホストごとの空きディスク・スペースの最小量と推奨量」を参照してください。

「ステップ 5: Add Tags」では、pureScale のサーバーであることがわかるように「pureScale servers」をタグとして指定します。

ステップ 6 以降は iSCSI サーバーと同じ手順に沿ってください。セキュリティグループは、iSCSI サーバーと同様に「pureScale servers」を選択します。

作成を終わってインスタンスの管理画面に戻ってくると、インスタンスが作成中になっていることがわかります。しばらくすると「ステータスチェック」が完了になるので、後続のステップに進んでください。

まずは iSCSI サーバーをクリックして割り振られているパブリック IP アドレスを確認します。右下のパネルに「IPv4 Public IP」という項目で確認できます。ここで確認した IP アドレスはインターネットに公開されているので、ご自身の端末からアクセスできるはずです。

それでは、確認した IP アドレスへ SSH でログインを試みます。Tera Term Pro や PuTTyのようなターミナルソフトを起動して、接続先のホストに先ほど確認した iSCSI サーバーのパブリック IP を入力してください。接続先のポートは、SSH のデフォルトである 22 番で問題ありません。

ここでは、ターミナルソフトとして Tera term Pro を利用する場合の手順を例にします。

ユーザーには「ec2-user」を、パスフレーズには何も指定せずに、その代わりに「RSA/DSA/ECDSA/ED25519 鍵を使う」を選び、前のステップで端末に保存した鍵ファイルをフルパスで指定します。今回利用している RHEL 7.2 の AMI では、AWS で提供される他の AMI と同じようにパスワードによる SSH ログインは無効となっています。ダウンロードした鍵ファイルがないとアクセスできないので、注意してください。

宛先の IP アドレスと、鍵ファイルが正しく指定され、セキュリティグループの設定も正しい場合は、問題なくログインが完了するはずです。同様に、pureScale 用のサーバーへもログインできるか確認してください。

ログインしたサーバーで「/etc/redhat-release」ファイルと「uname -a」コマンドの出力を確認し、RHEL 7.2 が稼働しており、カーネルのバージョンが「3.10.0.327」であることを確認してください。

$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.2 (Maipo)
$ uname -a
Linux ip-172-31-32-239.ap-northeast-1.compute.internal 3.10.0-327.el7.x86_64 #1 SMP Thu Oct 29 17:29:29 EDT 2015 x86_64 x86_64 x86_64 GNU/Linux
6

仮想サーバーに静的なホスト名を設定する

EC2 のインスタンスには、起動時に「ec2-13-113-92-203.ap-northeast-1.compute.amazonaws.com」のような、IP アドレスをベースとしたドメイン名が自動的に付与されます。これらのドメイン名はインターネットからアクセス可能なパブリック IP に対しても、ユーザーの VPC 内だけで利用されるプライベート IP に対しても付与され、インスタンスが起動した時点で利用が可能です。とはいえ、IP アドレスをベースとしたドメイン名では記憶が難しく、サーバーが識別しづらいため、この記事では静的なホスト名を設定します。

なお、EC2 インスタンスに静的なホスト名を設定する手順は、AWS のドキュメントで解説されており、その手順に従っています。

対象サーバー: 5 台すべてのサーバー
実行ユーザー: ec2-user(sudo コマンドを利用して root 権限で実行)

まず、この設定で変更するファイルのバックアップを取得します。

sudo cp -pi /etc/hostname /etc/hostname.$(date +%Y%m%d.%H%M%S)
sudo cp -pi /etc/hosts /etc/hosts.$(date +%Y%m%d.%H%M%S)
sudo cp -pi /etc/sysconfig/network /etc/sysconfig/network.$(date +%Y%m%d.%H%M%S)
sudo cp -pi /etc/cloud/cloud.cfg /etc/cloud/cloud.cfg.$(date +%Y%m%d.%H%M%S)

そして、/etc/hostname に変更したいホスト名を設定します。下の例では「iscsi」となっています。pureScale の 4 台のサーバーでは、それぞれ「member0」、「member1」、「cf128」、「cf129」という、pureScale のクラスター内での役割を表す名前に置き換えて実行してください。今の時点では 4 台のサーバーに区別はないので、どのサーバーにどの名前を設定しても問題ありません。

sudo tee /etc/hostname <<EOF
iscsi
EOF

上のコマンドを実行したら、「hostname」コマンドを実行して、設定したホスト名が反映されていることを確認します。

[ec2-user@ip-172-31-32-95 ~]$ hostname
iscsi

次に、/etc/hosts を書き換えて、各サーバーのローカル IP アドレスを記述します。サーバーのローカル IP アドレスは環境によって異なるので、必ず AWS マネジメントコンソールで確認して、環境に合わせてコマンドを書き換えて実行してください。インスタンスの管理画面で確認できます。

sudo tee /etc/hosts <<EOF
127.0.0.1 localhost.localdomain localhost

172.31.32.250 member0
172.31.32.127 member1
172.31.32.177 cf128
172.31.32.63 cf129

172.31.32.95 iscsi
EOF

次に、/etc/sysconfig/network を書き換えて、ホスト名を設定します。

sudo tee /etc/sysconfig/network <<EOF
NETWORKING=yes
NETWORKING_IPV6=no
HOSTNAME=`hostname`
EOF

次に、/etc/cloud/cloud.cfg に、静的なホスト名を利用する旨の設定を追記します。ここでは定義ファイルに追記するため、「tee -a」コマンドを利用しています。

sudo tee -a /etc/cloud/cloud.cfg <<EOF
preserve_hostname: true
EOF

最後に、すべてのサーバーを再起動して、このステップでの設定変更を有効にします。

sudo reboot

サーバーが再起動してきたら、ssh でログインしてホスト名が意図したとおりに変わっていることを確認してください。下の例のように、ターミナルのプロンプトに設定したホスト名が含まれていれば成功です。

Last login: Wed Feb  8 01:43:52 2017 from 221x241x134x50.ap221.ftth.ucom.ne.jp
[ec2-user@member0 ~]$

また、各サーバーから iSCSI サーバーに ping を実行して、サブネット内の相互通信ができることも確認しておいてください。

ここまでの手順で下のような環境ができあがりました。5 台の EC2 インスタンスが起動し、共通のサブネット配下に存在しており、仮想サーバーへはインターネットからアクセスすることができています。それぞれのサーバーは OS 領域用の EBS ディスクを持ち、iSCSI サーバーにはそれ以外に 10GB のディスクが 2 つ割り当てられています。

iSCSI でテスト用の共有ストレージを構成する

前のステップで AWS の環境整備と EC2 インスタンス(仮想サーバー)の作成が完了したので、次は iSCSI を利用した共有ストレージの構成に移ります。

iSCSI では、iSCSI のサーバーとして共有ディスクを提供する側を iSCSI Target とよび、iSCSI のクライアントとして共有ディスクを利用する側を iSCSI Initiator と呼びます。前のステップでホスト名として「iscsi」を付けたサーバーが iSCSI Target になり、pureScale 用のサーバーが iSCSI Initiator となります。

1

iSCSI アクセス用のパッケージを iSCSI クライアント(iSCSI Initator)側にインストールする

対象サーバー: 4 台の pureScale 用サーバー
実行ユーザー: ec2-user(sudo コマンドを利用して root 権限で実行)

まず、iSCSI のクライアントとなる 4 台の pureScale サーバー側で作業を始めます。

yum を利用して、iSCSI クライアントとして利用するパッケージ「iscsi-initiator-utils」をインストールします。次に、iscsid.service が自動的に起動されるよう systemctl コマンドで設定します。

sudo yum install -y iscsi-initiator-utils
sudo systemctl enable iscsid.service
sudo systemctl start iscsid.service
sudo systemctl status iscsid.service

コマンドが正常に完了すると、下の例のように「active (runnning)」という出力が得られます。

[ec2-user@member0 ~]$ sudo systemctl enable iscsid.service
Created symlink from /etc/systemd/system/multi-user.target.wants/iscsid.service to /usr/lib/systemd/system/iscsid.service.
[ec2-user@member0 ~]$ sudo systemctl start iscsid.service
[ec2-user@member0 ~]$ sudo systemctl status iscsid.service
● iscsid.service - Open-iSCSI
   Loaded: loaded (/usr/lib/systemd/system/iscsid.service; enabled; vendor preset: disabled)
   Active: active (running) since Wed 2017-02-08 01:50:01 EST; 6s ago
     Docs: man:iscsid(8)
           man:iscsiadm(8)
  Process: 2139 ExecStart=/usr/sbin/iscsid (code=exited, status=0/SUCCESS)
 Main PID: 2141 (iscsid)
   CGroup: /system.slice/iscsid.service
           tq2140 /usr/sbin/iscsid
           mq2141 /usr/sbin/iscsid

次に、「/etc/iscsi/initiatorname.iscsi」ファイルの内容を参照して、iSCSI の ID である IQN(iSCSI Qualified Name)を確認します。この IQN は、iSCSI の接続時に互いを一意に特定するための ID として利用されます。iSCSI サーバーの設定時に使用するので、4 台の pureScale 用サーバーすべてで確認しておいてください。

[ec2-user@member0 ~]$ cat /etc/iscsi/initiatorname.iscsi
InitiatorName=iqn.1994-05.com.redhat:5231f734a866

ここでは、下のように 4 つの IQN が得られたと仮定して後続の構成手順を説明します。実際に構築する環境で得られた IQN に置き換えてください。

member0 サーバー		iqn.1994-05.com.redhat:5231f734a866
member1 サーバー		iqn.1994-05.com.redhat:7fe035651d5a
cf128 サーバー		iqn.1994-05.com.redhat:cd8744c92326
cf129 サーバー		iqn.1994-05.com.redhat:66d473a748a
2

iSCSI サーバー(iSCSI target)の構成

対象サーバー:iSCSI サーバー
実行ユーザー:ec2-user(sudo コマンドを利用して root 権限で実行)

次に、iSCSI サーバー側での作業を進めます。まず yum から「targetcli」パッケージをインストールし、systemctl コマンドを使用してサービスを有効化します。

sudo yum -y install targetcli
sudo systemctl enable target.service
sudo systemctl start target.service
sudo systemctl status target.service

「sudo systemctl status target.service」コマンドから「active (exited)」という出力が得られていれば成功です。

[ec2-user@iscsi ~]$ sudo systemctl status target.service
● target.service - Restore LIO kernel target configuration
   Loaded: loaded (/usr/lib/systemd/system/target.service; enabled; vendor preset: disabled)
   Active: active (exited) since Wed 2017-02-08 01:54:43 EST; 3s ago
  Process: 2055 ExecStart=/usr/bin/targetctl restore (code=exited, status=0/SUCCESS)
 Main PID: 2055 (code=exited, status=0/SUCCESS)

次に、「lsblk」コマンドで iSCSI サーバーにアサインされている EBS デバイスを確認します。

lsblk

iSCSI サーバーのインスタンス作成時に、EBS ストレージを 2 つ追加したことを思い出してください。ここでは、以下のように「xvdb」と「xvdc」という 2 つのデバイスが確認できました。この 2 つのデバイスを、iSCSI の共有ストレージとして構成していきます。

[ec2-user@iscsi ~]$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  10G  0 disk
tqxvda1 202:1    0   1M  0 part
mqxvda2 202:2    0  10G  0 part /
xvdb    202:16   0  10G  0 disk
xvdc    202:32   0  10G  0 disk

最初に、「targetcli」コマンドでディスクを LUN オブジェクトとして iSCSI ターゲットに登録します。「dev=」オプションには、「lsblk」コマンドで確認したデバイス名に「/dev/」を付けて置き換えてから実行してください。

sudo targetcli /backstores/block create name=lun0 dev=/dev/xvdb
sudo targetcli /backstores/block create name=lun1 dev=/dev/xvdc

コマンドが正常に完了すると、「Created block storage object…」というメッセージが出力されます。

[ec2-user@iscsi ~]$ sudo targetcli /backstores/block create name=lun0 dev=/dev/xvdb
Created block storage object lun0 using /dev/xvdb.
[ec2-user@iscsi ~]$ sudo targetcli /backstores/block create name=lun1 dev=/dev/xvdc
Created block storage object lun1 using /dev/xvdc.

2 つのコマンドを実行した後に「sudo targetcli ls /」コマンドを実行すると、「backstores/block」配下に lun0 と lun1 という 2 つのデバイスが登録されていることが確認できます。

sudo targetcli ls /

[ec2-user@iscsi ~]$ sudo targetcli ls /
o- / .................................................................................................. [...]
  o- backstores ....................................................................................... [...]
  | o- block ........................................................................... [Storage Objects: 2]
  | | o- lun0 .................................................. [/dev/xvdb (10.0GiB) write-thru deactivated]
  | | o- lun1 .................................................. [/dev/xvdc (10.0GiB) write-thru deactivated]
  | o- fileio .......................................................................... [Storage Objects: 0]
  | o- pscsi ........................................................................... [Storage Objects: 0]
  | o- ramdisk ......................................................................... [Storage Objects: 0]
  o- iscsi ..................................................................................... [Targets: 0]
  o- loopback .................................................................................. [Targets: 0]

次に、iSCSI サーバー側で、iSCSI クライアント側からの接続ターゲットとなる target オブジェクトを作成します。「iqn」で始まる文字列が target オブジェクトの名称を示します。ここでは「iqn.1994-05.com.redhat:pstgt01」とします。

sudo targetcli /iscsi create iqn.1994-05.com.redhat:pstgt01

コマンドが正常に実行されると、以下のようなメッセージが得られます。

[ec2-user@iscsi ~]$ sudo targetcli /iscsi create iqn.1994-05.com.redhat:pstgt01
Created target iqn.1994-05.com.redhat:pstgt01.
Created TPG 1.
Global pref auto_add_default_portal=true
Created default portal listening on all IPs (0.0.0.0), port 3260.

次に「sudo targetcli ls /」コマンドを実行すると、以下のようにコマンドで指定した Target オブジェクトが「iscsi」配下に登録されていることが確認できます。

[ec2-user@iscsi ~]$ sudo targetcli ls /
o- / ............................................................................... [...]
  o- backstores .................................................................... [...]
  | o- block ........................................................ [Storage Objects: 2]
  | | o- lun0 ............................... [/dev/xvdb (10.0GiB) write-thru deactivated]
  | | o- lun1 ............................... [/dev/xvdc (10.0GiB) write-thru deactivated]
  | o- fileio ....................................................... [Storage Objects: 0]
  | o- pscsi ........................................................ [Storage Objects: 0]
  | o- ramdisk ...................................................... [Storage Objects: 0]
  o- iscsi .................................................................. [Targets: 1]
  | o- iqn.1994-05.com.redhat:pstgt01 .......................................... [TPGs: 1]
  |   o- tpg1 ..................................................... [no-gen-acls, no-auth]
  |     o- acls ................................................................ [ACLs: 0]
  |     o- luns ................................................................ [LUNs: 0]
  |     o- portals .......................................................... [Portals: 1]
  |       o- 0.0.0.0:3260 ........................................................... [OK]
  o- loopback ............................................................... [Targets: 0]

次に、最初に作成した 2 つの LUN オブジェクトを、target オブジェクトに紐付けます。

sudo targetcli /iscsi/iqn.1994-05.com.redhat:pstgt01/tpg1/luns create /backstores/block/lun0
sudo targetcli /iscsi/iqn.1994-05.com.redhat:pstgt01/tpg1/luns create /backstores/block/lun1

コマンドが正常に実行されると、target オブジェクトの配下に lun0 と lun1 が追加されます。

[ec2-user@iscsi ~]$ sudo targetcli /iscsi/iqn.1994-05.com.redhat:pstgt01/tpg1/luns create /backstores/block/lun0
Created LUN 0.
[ec2-user@iscsi ~]$ sudo targetcli /iscsi/iqn.1994-05.com.redhat:pstgt01/tpg1/luns create /backstores/block/lun1
Created LUN 1.
[ec2-user@iscsi ~]$ sudo targetcli ls /
o- / ............................................................................... [...]
  o- backstores .................................................................... [...]
  | o- block ........................................................ [Storage Objects: 2]
  | | o- lun0 ................................. [/dev/xvdb (10.0GiB) write-thru activated]
  | | o- lun1 ................................. [/dev/xvdc (10.0GiB) write-thru activated]
  | o- fileio ....................................................... [Storage Objects: 0]
  | o- pscsi ........................................................ [Storage Objects: 0]
  | o- ramdisk ...................................................... [Storage Objects: 0]
  o- iscsi .................................................................. [Targets: 1]
  | o- iqn.1994-05.com.redhat:pstgt01 .......................................... [TPGs: 1]
  |   o- tpg1 ..................................................... [no-gen-acls, no-auth]
  |     o- acls ................................................................ [ACLs: 0]
  |     o- luns ................................................................ [LUNs: 2]
  |     | o- lun0 ............................................... [block/lun0 (/dev/xvdb)]
  |     | o- lun1 ............................................... [block/lun1 (/dev/xvdc)]
  |     o- portals .......................................................... [Portals: 1]
  |       o- 0.0.0.0:3260 ........................................................... [OK]
  o- loopback ............................................................... [Targets: 0]

最後に、target オブジェクトに対する iSCSI クライアント側からのアクセスを許可するために ACL を登録します。コマンドの末尾に指定している「iqn」で始まる文字列は iSCSI クライアント側(iSCSI Initiator)の IQN です。前のステップで 4 台の pureScale サーバーから取得した IQN に置き換えてください。

sudo targetcli /iscsi/iqn.1994-05.com.redhat:pstgt01/tpg1/acls create iqn.1994-05.com.redhat:9d23fc8037aa
sudo targetcli /iscsi/iqn.1994-05.com.redhat:pstgt01/tpg1/acls create iqn.1994-05.com.redhat:a75add99d1ac
sudo targetcli /iscsi/iqn.1994-05.com.redhat:pstgt01/tpg1/acls create iqn.1994-05.com.redhat:86d7a26e11b
sudo targetcli /iscsi/iqn.1994-05.com.redhat:pstgt01/tpg1/acls create iqn.1994-05.com.redhat:d1684e30a9e2

コマンドが正常に完了すると、以下のように LUN0 と LUN1 の 2 つが map されたというメッセージが得られます。

[ec2-user@iscsi ~]$ sudo targetcli /iscsi/iqn.1994-05.com.redhat:pstgt01/tpg1/acls create iqn.1994-05.com.redhat:9d23fc8037aa
Created Node ACL for iqn.1994-05.com.redhat:9d23fc8037aa
Created mapped LUN 1.
Created mapped LUN 0.

最終的な iSCSI 構成の内容は以下のようになります。

[ec2-user@iscsi ~]$ sudo targetcli ls /
o- / ............................................................................... [...]
  o- backstores .................................................................... [...]
  | o- block ........................................................ [Storage Objects: 2]
  | | o- lun0 ................................. [/dev/xvdb (10.0GiB) write-thru activated]
  | | o- lun1 ................................. [/dev/xvdc (10.0GiB) write-thru activated]
  | o- fileio ....................................................... [Storage Objects: 0]
  | o- pscsi ........................................................ [Storage Objects: 0]
  | o- ramdisk ...................................................... [Storage Objects: 0]
  o- iscsi .................................................................. [Targets: 1]
  | o- iqn.1994-05.com.redhat:pstgt01 .......................................... [TPGs: 1]
  |   o- tpg1 ..................................................... [no-gen-acls, no-auth]
  |     o- acls ................................................................ [ACLs: 4]
  |     | o- iqn.1994-05.com.redhat:86d7a26e11b ......................... [Mapped LUNs: 2]
  |     | | o- mapped_lun0 ........................................ [lun0 block/lun0 (rw)]
  |     | | o- mapped_lun1 ........................................ [lun1 block/lun1 (rw)]
  |     | o- iqn.1994-05.com.redhat:9d23fc8037aa ........................ [Mapped LUNs: 2]
  |     | | o- mapped_lun0 ........................................ [lun0 block/lun0 (rw)]
  |     | | o- mapped_lun1 ........................................ [lun1 block/lun1 (rw)]
  |     | o- iqn.1994-05.com.redhat:a75add99d1ac ........................ [Mapped LUNs: 2]
  |     | | o- mapped_lun0 ........................................ [lun0 block/lun0 (rw)]
  |     | | o- mapped_lun1 ........................................ [lun1 block/lun1 (rw)]
  |     | o- iqn.1994-05.com.redhat:d1684e30a9e2 ........................ [Mapped LUNs: 2]
  |     |   o- mapped_lun0 ........................................ [lun0 block/lun0 (rw)]
  |     |   o- mapped_lun1 ........................................ [lun1 block/lun1 (rw)]
  |     o- luns ................................................................ [LUNs: 2]
  |     | o- lun0 ............................................... [block/lun0 (/dev/xvdb)]
  |     | o- lun1 ............................................... [block/lun1 (/dev/xvdc)]
  |     o- portals .......................................................... [Portals: 1]
  |       o- 0.0.0.0:3260 ........................................................... [OK]
  o- loopback ............................................................... [Targets: 0]

上の出力と同じように構成できていることが確認できたら、構成を保存します。

sudo targetcli saveconfig
3

iSCSI クライアント側から公開された LUN を参照する

対象サーバー: 4 台の pureScale 用サーバー
実行ユーザー: ec2-user(sudo コマンドを利用して root 権限で実行)

iSCSI サーバー側の準備が整ったので、iSCSI クライアント側から公開された LUN を参照します。以下のコマンドを 4 台の pureScale 用サーバー側で実行すると、「iscsi」ホストの 3260 ポートに通信し、iSCSI Initiator がアクセスできる LUN の情報を取得します。

sudo iscsiadm -m discovery -t st -p iscsi:3260
sudo iscsiadm -m node -T iqn.1994-05.com.redhat:pstgt01 -p iscsi:3260 -l

正常に実行されると以下のようなメッセージが得られます。

[ec2-user@member0 ~]$ sudo iscsiadm -m discovery -t st -p iscsi:3260
172.31.32.53:3260,1 iqn.1994-05.com.redhat:pstgt01
[ec2-user@member0 ~]$ sudo iscsiadm -m node -T iqn.1994-05.com.redhat:pstgt01 -p iscsi:3260 -l
Logging in to [iface: default, target: iqn.1994-05.com.redhat:pstgt01, portal: 172.31.32.53,3260] (multiple)
Login to [iface: default, target: iqn.1994-05.com.redhat:pstgt01, portal: 172.31.32.53,3260] successful.

iscsiadm コマンドが完了したら、「lsblk -S」コマンドを実行して、iSCSI ディスクを認識しているかどうかを確認します。

lsblk -S

以下のように、「TRAN」が「iscsi」になっている lun0 と lun1 が認識されていれば成功です。第一カラムの「sda」や「sdb」が/dev 配下に作成されるデバイス名です。後続の pureScale のセットアップでは、「/dev/sda」や「/dev/sdb」といった形式で、ディスクを指定するために利用するのでメモしておいてください。

[ec2-user@member0 ~]$ lsblk -S
NAME HCTL       TYPE VENDOR   MODEL             REV TRAN
sda  2:0:0:0    disk LIO-ORG  lun0             4.0  iscsi
sdb  2:0:0:1    disk LIO-ORG  lun1             4.0  iscsi
表 2 iSCSI クライアント側で認識したデバイス名
LUN (MODEL)用途デバイス名(要記入)
lun0共有 SQLLIB 
lun1Tiebreaker ディスク 

ここまでの手順で、iSCSI サーバーが公開したディスクを pureScale 用のサーバーから共用してアクセスする構成ができあがりました。ここに pureScale をインストールしていきます。

DB2 pureScale の前提を満たすための設定

対象サーバー: 4 台の pureScale 用サーバー
実行ユーザー: ec2-user(sudo コマンドを利用して root 権限で実行)

DB2 pureScale をインストールする前に、前提を満たすための構成を行います。このステップの 1 から 4 までの手順は、4 台の pureScale 用サーバーすべてで実施する必要があります。なお、原稿執筆時点の DB2 11.1 FP1 では、日本語環境の OS へのインストール時に問題が発生する可能性があります。そのため、OS の言語環境は英語のままとしてください。

1

SSH 設定

pureScale のクラスターとして稼働させるサーバーでは、root ユーザーに相互の password-less SSH の構成をする必要があります。以下の手順に従って構成してください。

まず、root ユーザーの ssh 認証用のキーを生成します。ssh-keygen コマンドを実行すると、いくつかの応答を求められるので、いずれも空エンターで進んでください。

sudo ssh-keygen -t rsa

キーを生成し終わったら、root ユーザーの.ssh ディレクトリーを参照して、鍵ファイルが正しく作成されたことと、パーミッションが正しいことを確認してください。.ssh ディレクトリー、id_rsa ファイル、authorized_keys ファイルの 3 つはパーミッションが 600 に設定されている必要があります。異なるパーミッションであった場合は、600 に変更してください。

sudo ls -la /root/.ssh

[ec2-user@member0 ~]$ sudo ls -la /root/.ssh
total 16
drwx------. 2 root root   58 Feb  8 02:01 .
dr-xr-x---. 4 root root 4096 Feb  8 01:49 ..
-rw-------. 1 root root  559 Feb  8 01:28 authorized_keys
-rw-------. 1 root root 1675 Feb  8 02:01 id_rsa
-rw-r--r--. 1 root root  394 Feb  8 02:01 id_rsa.pub

次に、各サーバーで生成された公開鍵の内容を確認します。

sudo cat /root/.ssh/id_rsa.pub

出力された id_rsa.pub の内容を 4 サーバー分すべて集めて、root ユーザーの authorized_keys ファイルに追加します。

sudo tee -a /root/.ssh/authorized_keys <<EOF
ssh-rsa AAQeaC1yc2EdAAAADAQAAABAdQDkcdmddddmd...zCXssss root@member0
ssh-rsa ASANszcaC1dyc2EdAgAADAdQAsnBC1DKDKDKD...13ntttt root@member1
ssh-rsa DAA3dNdsdzaC1yc2EdgADdAjdQdAKDLbEK7hj...lzmuuuu root@cf128
ssh-rsa AAAAB3NzaC1yc2EddAdAdADAQdABDSE+g1Bdq...Sinwwww root@cf129
EOF

ここまでの手順で、root ユーザーによる相互の password-less ssh でのリモートログインが可能になったので、以下のようにログインできるかを確認してください。下の例では、member0 から member1 サーバーにパスワードなしの ssh でログインできることを確認しています。

sudo ssh member1

[ec2-user@member0 ~]$ sudo ssh member1
The authenticity of host 'member1 (172.31.32.127)' can't be established.
ECDSA key fingerprint is bb:8f:d8:a4:0e:45:61:4d:db:89:16:f9:9a:d6:b9:73.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'member1,172.31.32.127' (ECDSA) to the list of known hosts.
[root@member1 ~]# hostname
member1
[root@member1 ~]# exit
logout
Connection to member1 closed.
2

SE Linux の無効化

今回利用する RHEL7.2 の AMI では、SE Linux がデフォルトで有効になっています。pureScale のコンポーネントである Spectrum Scale(旧 GPFS)は SE Linux をサポートしないので、以下の手順で SE Linux を無効にしてください。

まず、現在の設定を「getenforce」コマンドで確認します。以下のように、「Enforcing」という出力が得られるはずです。これは、SE Linux が有効になっていることを表します。

getenforce

[ec2-user@member0 ~]$ getenforce
Enforcing

sudo コマンドを利用して root ユーザーにスイッチし、SE Linux の設定ファイルのバックアップを取得します。

sudo su -
cp -pi /etc/selinux/config /etc/selinux/config.bk

取得したバックアップ・ファイルを元に SE Linux の設定ファイルを書き換えます。

sed "s/^SELINUX=enforcing/SELINUX=disabled/" /etc/selinux/config.bk > /etc/selinux/config

書き換えた設定ファイルとバックアップを比較すると、もともと「Enforcing」であった設定値が「disabled」に変わっているはずです。

diff /etc/selinux/config /etc/selinux/config.bk

[root@member0 ~]# diff /etc/selinux/config /etc/selinux/config.bk
7c7
< SELINUX=disabled
---
> SELINUX=enforcing

設定ファイルの書き換えが終わったら、サーバーを再起動して設定変更を有効にします。

reboot

サーバーの再起動後にログインして、もういちど「getenforce」コマンドを実行すると、「disabled」という出力が得られるはずです。これで SE Linux が無効になりました。

Last login: Wed Feb  8 01:48:56 2017 from 221x241x134x50.ap221.ftth.ucom.ne.jp
[ec2-user@member0 ~]$ getenforce
Disabled
3

DB2 および pureScale の前提パッケージをインストールする

DB2 および pureScale を Linux サーバーで利用する場合には、前提となるパッケージをあらかじめ導入しておく必要があります。AWS が提供する RHEL の AMI は、Red Hat Network(RHN)のサブスクリプション登録が済んでいるので、ここまでのステップでも利用したように、システム登録を行わなくても yum コマンドからリポジトリが利用可能です。

IA-Linux で稼働する DB2 pureScale の前提パッケージは、DB2 のマニュアルに記載されています。

また、db2prereqcheck コマンドによって DB2 を稼働するサーバーに不足しているパッケージをチェックすることも可能です。

これらの記述を元に、今回利用する RHEL 7.2 の AMI に「DB2 11.1 pureScale MOD1 FP1」をインストールするために必要なパッケージを yum コマンドにまとめると以下のようになります。4 台の pureScale 用サーバーすべてで、以下の yum コマンドを実行してください。

sudo yum -y install gcc cpp gcc-c++ ntp ksh sg3_utils libstdc++.i686 libaio pam.i686 pam.x86_64  kernel-headers-3.10.0-327.el7.x86_64 kernel-devel-3.10.0-327.el7.x86_64
sudo yum -y install libibcm libibverbs librdmacm rdma dapl ibacm ibutils libcxgb3 libibmad libipathverbs libmlx4 libmlx5 libmthca libnes glibc.x86_64 glibc.i686 kernel-firmware ntpdate sg3_utils-libs binutils-devel m4 openssh libgcc file libgomp make patch perl-Sys-Syslog
4

DB2 インスタンス用のグループとユーザーを作成する

DB2 のインスタンスを作成する前に、DB2 が利用するグループとユーザーを作成する必要があります。この記事では、インスタンスユーザーとして db2psin を、分離ユーザーとして db2fenc を作成します。ユーザーを作成した後は、忘れずにパスワードも設定してください。ユーザー名やグループ名、UID および GID は、pureScale 用のすべてのサーバーで共通になっている必要があります。サーバーごとに UID を変えるような変更は避けてください。

sudo groupadd --g 2000 db2grp
sudo groupadd --g 2010 db2fgrp
sudo useradd --uid 2000 --gid db2grp db2psin
sudo passwd db2psin
sudo useradd --uid 2010 --gid db2fgrp db2fenc
sudo passwd db2fenc

DB2 pureScale の導入と構成を行う

対象サーバー: member0 サーバー
実行ユーザー: ec2-user および、必要に応じて db2psin ユーザーにスイッチ

ここからは DB2 pureScale のインストールと構成を行っていきます。このステップの手順はすべて member0 サーバーのみで行います。他のサーバーで作業する必要はありません。

1

DB2 の製品パッケージをダウンロードして member0 サーバーに配置する

まず、DB2 の製品パッケージを入手する必要があります。DB2 の製品パッケージは、IBM のウェブサイトからダウンロードが可能で、90 日間無償で評価できます。

DB2 の Fix Pack Download ページから、「DB2 11.1 Mod1 Fix Pack1」を選択して、Linux 64-bit (x86-64) on AMD64 and Intel EM64T の「DB2 Universal Fix Pack」をダウンロードしてください。

正常にダウンロードが完了すると「v11.1.1fp1_linuxx64_universal_fixpack.tar.gz」というファイルが端末に保存されます。このファイルを、member0 サーバーの/work ディレクトリーに配置してください。

/work ディレクトリーは初期状態では存在しないので、「ec2-user」ユーザーからあらかじめ作成しておいてください。

sudo mkdir -m 777 /work

サーバーへの転送には、WinSCP など、ssh による認証が可能なファイル転送ソフトウェアを利用します。WinSCP を利用する場合は、前のステップで利用した鍵ファイルを ppk 形式に変換して指定してください。鍵ファイルを設定するパスは「設定->SSH->認証->秘密鍵」です。

member0 サーバーへの転送が完了したら、DB2 の製品パッケージを展開しておきます。

cd /work
sudo tar -zxvf v11.1.1fp1_linuxx64_universal_fixpack.tar.gz
2

前提を満たしていることをチェックする

前のステップで必要なパッケージはインストールしているので、前提を満たしていることを確認するために member0 サーバー上で ec2-user から db2prereqcheck コマンドを実行してみます。

cd /work/universal

sudo ./db2prereqcheck -p -v 11.1.1.1

必要なパッケージが導入できていれば、標準出力に DBT3533I メッセージが出力されます。

[ec2-user@member0 /]$ cd /work/universal
[ec2-user@member0 universal]$ sudo ./db2prereqcheck -p -v 11.1.1.1
…
DBT3533I  The db2prereqcheck utility has confirmed that all installation prerequisites were met.
3

DB2 をインストールする

製品パッケージの展開がおわり、前提のチェックも完了したので、member0 サーバーに DB2 の製品パッケージをインストールします。インストールは member0 サーバーで 1 回のみ実行すればよく、他のサーバーへはインスタンス作成の中で自動的にインストールされます。

cd /work/universal
sudo ./db2_install -b /opt/ibm/db2/v11.1 -p SERVER -f PURESCALE -y

インストールが正常に完了すると、ログの最後に「The execution completed successfully.」というメッセージが出力されます。もしインストールがうまくいかない場合は、/tmp 配下に出力されるログファイルを参考に原因を調査してください。多くの場合は前提パッケージの不足や、サーバー間通信の不通、password-less SSH の構成不備など、ここまでの手順で実施してきた準備の漏れがエラーの原因となっています。

[ec2-user@member0 universal]$ sudo ./db2_install -b /opt/ibm/db2/v11.1 -p SERVER -f PURESCALE -y
DB2 installation is being initialized.
….
The execution completed successfully.

For more information see the DB2 installation log at
"/tmp/db2_install.log.14664".
4

DB2 インスタンスを作成する(1 member + 1 CF)

さて、いよいよ DB2 pureScale のインスタンスを作成します。pureScale では、最初にメンバーとサーバーを 1 台ずつ指定して、最小限の組み合わせでインスタンスを作成します。その後、メンバーもしくは CF としてサーバーを追加していき、必要な台数のクラスターを構成します。

インスタンスの作成は root ユーザーから行うので、ec2-user から sudo で実行します.メンバーとして member0 サーバーを、CF として cf128 サーバーを指定しています。「-instance_shared_dev /dev/sda」オプションは、/dev/sda をインスタンスの共有ディスクとして利用することを意味し、「-tbdev /dev/sdb」オプションは/dev/sdb をタイブレーカー用のディスクとして利用することを意味します。「表 2 iSCSI クライアント側で認識したデバイス名」でメモしたデバイス名に置き換えて実行してください。

sudo /opt/ibm/db2/v11.1/instance/db2icrt -d -m member0 -mnet member0 -cf cf128 -cfnet cf128 -instance_shared_dev /dev/sda -tbdev /dev/sdb -u db2fenc db2psin ; echo $? ; date

このコマンドを実行して、以下のように「The execution completed with warnings.」というメッセージが得られればインスタンスの作成は成功です。これで、1 メンバーと 1CF で構成された最小規模の pureScale インスタンスが作成されました。

[ec2-user@member0 universal]$ sudo /opt/ibm/db2/v11.1/instance/db2icrt -d -m member0 -mnet member0 -cf cf128 -cfnet cf128 -instance_shared_dev /dev/sda -tbdev /dev/sdb -u db2fenc db2psin ; echo $? ; date
DBI1446I  The db2icrt command is running.


DB2 installation is being initialized.

….
The execution completed with warnings.

For more information see the DB2 installation log at "/tmp/db2icrt.log.718".
DBI20182W  Program "db2icrt" completed successfully but with warnings.
0
Wed Feb  8 02:46:25 EST 2017
5

メンバーを追加する(2 member + 1 CF)

1 メンバーと 1CF ではインスタンスを起動できるぎりぎりの最小規模なので、通常の構成にするためにサーバーを追加していきます。次は、member1 サーバーをメンバーとして追加します。

今度はインスタンスを作成する db2icrt コマンドではなく、作成済みのインスタンスを更新する db2iupdt コマンドを使います。「-add」オプションは、既存の pureScale インスタンスに新たなサーバーを加えることを意味します。

sudo /opt/ibm/db2/v11.1/instance/db2iupdt -d -add -m member1 -mnet member1 db2psin ; echo $? ; date

このコマンドも、「The execution completed with warnings.」というメッセージで問題ありません。ログを確認すると、DBI20167W が出力されているはずです。

[ec2-user@member0 universal]$ sudo /opt/ibm/db2/v11.1/instance/db2iupdt -d -add -m member1 -mnet member1 db2psin ; echo $? ; date
DBI1446I  The db2iupdt command is running.

…

The execution completed with warnings.

For more information see the DB2 installation log at "/tmp/db2iupdt.log.25728".
DBI20182W  Program "db2iupdt" completed successfully but with warnings.
0
Wed Feb  8 03:03:04 EST 2017
6

CF を追加する(2 member + 2 CF)

これが最後のサーバー追加です。cf129 サーバーを CF として追加します。このコマンドが成功すると、CF サーバーが二重構成になるので、一方の CF サーバーに障害が発生しても継続して稼働できるようになります。

sudo /opt/ibm/db2/v11.1/instance/db2iupdt -d -add -cf cf129 -cfnet cf129 db2psin ; echo $? ; date


[ec2-user@member0 universal]$ sudo /opt/ibm/db2/v11.1/instance/db2iupdt -d -add -cf cf129 -cfnet cf129 db2psin ; echo $? ; date
DBI1446I  The db2iupdt command is running.


DB2 installation is being initialized.
…
The execution completed with warnings.

For more information see the DB2 installation log at "/tmp/db2iupdt.log.14680".
DBI20182W  Program "db2iupdt" completed successfully but with warnings.
0
Wed Feb  8 03:14:36 EST 2017
7

pureScale インスタンスを起動する

ここまでの手順で、メンバーが 2 台と CF が 2 台の DB2 pureScale クラスターが構成できました。SQL を処理するメンバーと共有キャッシュとして機能する CF がともに冗長化されており、pureScale の基本的な構成として多くのお客様で使用されているトポロジーです。

インスタンスの起動は db2psin ユーザーで行います。ec2-user から db2psin ユーザーにスイッチします。これ以降のコマンドは、特に断り書きがない限り db2psin ユーザーで実行してください。

sudo su - db2psin

まずは、「db2instance -list」コマンドを実行して、インスタンスの状態を見てみましょう。

db2instance -list

コマンドを実行すると、以下のように上下 2 つのセクションに分かれて 4 行ずつのエントリーが出力されます。上のセクションは pureScale を構成するメンバーや CF のステータスを表し、いまは停止状態(STOPPED)になっています。下のセクションは pureScale が稼働するサーバーのステータスを表し、いまは起動している(ACTIVE)ことを表しています。

[db2psin@member0 ~]$ db2instance -list
ID        TYPE             STATE                HOME_HOST
--        ----             -----                ---------
0       MEMBER           STOPPED                  member0
1       MEMBER           STOPPED                  member1
128     CF               STOPPED                    cf128
129     CF               STOPPED                    cf129

HOSTNAME                   STATE                INSTANCE_STOPPED
--------                   -----                ----------------
   cf129                  ACTIVE                              NO
   cf128                  ACTIVE                              NO
 member1                  ACTIVE                              NO
 member0                  ACTIVE                              NO

インスタンスを起動する前に、「10Gbps 未満の低速なネットワークを許容する」という設定をインスタンスにセットします。RDMA を利用しない Lite モードの pureScale でも、本番環境として利用する場合は 10Gbps のネットワークを想定しているため、この記事で利用しているテスト環境では設定する必要があります。

db2set コマンドを利用して設定をおこない、もういちど引数なしで db2set コマンドを実行して正常にセットされたことを確認します。もし、この手順の前にすでにインスタンスを起動している場合は、設定を有効にするためにインスタンスを再起動してください。

db2set DB2_SD_ALLOW_SLOW_NETWORK=ON
db2set

[db2psin@member0 ~]$ db2set DB2_SD_ALLOW_SLOW_NETWORK=ON
[db2psin@member0 ~]$ db2set
DB2_SD_ALLOW_SLOW_NETWORK=ON
DB2RSHCMD=/usr/bin/ssh
DB2COMM=TCPIP

それでは、db2start コマンドでインスタンスを起動します。db2psin ユーザーから実行します。

db2start

正常に起動されれば、以下のように「SQL1063N DB2START processing was successful.」のメッセージが 2 行出力されます。これのメッセージはメンバー数分だけ出力されるので、4 メンバーのシステムでは 4 行出力されます。CF も同時に起動されますが、メッセージは出力されません。

[db2psin@member0 ~]$ db2start
ADM12026W  The database server has detected that a valid license for the product "DB2 Enterprise Server Edition" has not been registered.
02/08/2017 03:20:11     0   0   SQL1063N  DB2START processing was successful.
02/08/2017 03:20:12     1   0   SQL1063N  DB2START processing was successful.
SQL1063N  DB2START processing was successful.

db2start コマンドが完了したら、もう一度 db2instance -list コマンドを実行してみましょう。

db2instance -list

こんどは member が STARTED に、CF が PRIMARY/CATCHUP になっているはずです。この状態が、pureScale が正常に起動した直後のステータスです。なお、データベースが活動化されているときは、cf129 サーバーのステータスは PEER に変わります。

[db2psin@member0 ~]$ db2instance -list
ID        TYPE             STATE                HOME_HOST
--        ----             -----                ---------
0       MEMBER           STARTED                  member0
1       MEMBER           STARTED                  member1
128     CF               PRIMARY                    cf128
129     CF               CATCHUP                    cf129

HOSTNAME                   STATE                INSTANCE_STOPPED
--------                   -----                ----------------
   cf129                  ACTIVE                              NO
   cf128                  ACTIVE                              NO
 member1                  ACTIVE                              NO
 member0                  ACTIVE                              NO
8

データベースを作成する

インスタンスは起動しましたが、まだデータを格納するためのデータベースがありません。以下のコマンドで SAMPLE という名前のデータベースを作成します。

db2 create database sample

[db2psin@member0 ~]$ db2 create database sample
DB20000I  The CREATE DATABASE command completed successfully.

データベースが作成されたら、ターミナルから接続してみます。いま作業しているターミナルは db2psin ユーザーで DB サーバーに認証されているので、コマンド中で認証情報を渡す必要はありません。

db2 connect to sample

[db2psin@member0 ~]$ db2 connect to sample

   Database Connection Information

 Database server        = DB2/LINUXX8664 11.1.1.1
 SQL authorization ID   = DB2PSIN
 Local database alias   = SAMPLE

できあがった環境を使ってみる

最後に、できあがった環境を使ってみます。クラスター・データベースである pureScale らしい動作を見ていきます。

1

複数のメンバーからデータを投入してみる

このステップでは、member0 サーバーと member1 サーバーそれぞれから、同じ T1 表にデータを投入して、お互いに参照できることを確認してみます。

下のように、データベースに接続し、T1 表を作成して 1 行のレコードを INSERT します。このコマンドでは自動コミットが有効になっているので、INSERT に応答が返った時点でコミットが完了しています。

db2 connect to sample
db2 "create table t1 (c1 timestamp, c2 char(20))"
db2 "insert into t1 values (current timestamp, 'from member0')"
db2 "select * from t1"


[db2psin@member0 ~]$ db2 connect to sample

   Database Connection Information

 Database server        = DB2/LINUXX8664 11.1.1.1
 SQL authorization ID   = DB2PSIN
 Local database alias   = SAMPLE

[db2psin@member0 ~]$ db2 "create table t1 (c1 timestamp, c2 char(20))"
DB20000I  The SQL command completed successfully.
[db2psin@member0 ~]$ db2 "insert into t1 values (current timestamp, 'from member0')"
DB20000I  The SQL command completed successfully.
[db2psin@member0 ~]$ db2 "select * from t1"

C1                         C2
-------------------------- --------------------
2017-02-08-03.32.25.825633 from member0

  1 record(s) selected.

次に、member1 サーバーにログインして db2psin ユーザーにスイッチしてから、同じ T1 表を参照します。

sudo su - db2psin
db2 connect to sample
db2 "select * from t1"

T1 表へ SELECT してみると、さきほど member0 で INSERT したレコードが表示されました。他のメンバーでの更新結果を、member1 サーバーで参照することができています。

[ec2-user@member1 ~]$ sudo su - db2psin
Last login: Wed Feb  8 03:13:00 EST 2017
[db2psin@member1 ~]$ db2 connect to sample

   Database Connection Information

 Database server        = DB2/LINUXX8664 11.1.1.1
 SQL authorization ID   = DB2PSIN
 Local database alias   = SAMPLE

[db2psin@member1 ~]$ db2 "select * from t1"

C1                         C2
-------------------------- --------------------
2017-02-08-03.32.25.825633 from member0

  1 record(s) selected.

今度は、member1 サーバーから同じ表にデータを INSERT してみます。

db2 "insert into t1 values (current timestamp, 'from member1')"

[db2psin@member1 ~]$ db2 "insert into t1 values (current timestamp, 'from member1')"
DB20000I  The SQL command completed successfully.

member1 での INSERT が完了した後に、member0 に戻って、もう一度 T1 表を SELECT してみます。

db2 "select * from t1"

先ほどは存在しなかった、もうひとつのレコード(C2=”from member1”)が増えていることがわかります。同じ表に対して別々のサーバーから INSERT したレコードを、意識せずに一貫性を持って参照することができました。

[db2psin@member0 ~]$ db2 "select * from t1"

C1                         C2
-------------------------- --------------------
2017-02-08-03.32.25.825633 from member0
2017-02-08-03.33.34.636182 from member1

  2 record(s) selected.

ちなみに、この手順では自動コミットが有効になっているため、INSERT したレコードはすぐにもうひとつのメンバーで参照できるようになります。では、INSERT は完了したけれど、参照の時点ではまだコミットされていないレコードはどうなるでしょうか?db2 +c “insert into xxxx”として、「+c」をつけることで自動コミットを無効にして「INSERT したけどまだコミットしていない」状態にできるので、是非試してみてください。

試してみると、まだコミットしていないレコードがある状態で SELECT すると、INSERT したレコードは出力されないはずです。

2

どのメンバーに接続しているかを確認する

ひとつ前のテストで、pureScale ではどのサーバーで SQL が処理されているかをアプリケーションが意識しなくてよいことが実感できたと思います。とはいえ、テストや管理のために、アプリケーションがどのメンバーに接続しているかを知りたいときもあります。

そんな時に便利なのが、「CURRENT MEMBER」という特殊レジスターです。特殊レジスターとはデータベースへの接続ごとに割り振られるプロパティのようなもので、データベースサーバーのシステム時刻を表す「CURRENT TIMESTAMP」や、ロック待機する時間を表す「CURRENT LOCK TIMEOUT」などがよく使われる特殊レジスターです。

特殊レジスターの内容は SQL に組み込んで実行することで取得できます。member0 サーバーにログインしたターミナルから以下の SQL を実行します。

db2 connect to sample
db2 "select current timestamp as timestamp, current member as memberID from sysibm.sysdummy1"

member0 サーバーで実行すると、以下のように「MEMBERID=0」のレコードが得られます。ここで得られるメンバーの ID は、「db2instance -list」コマンドで表示される「ID」と同じです。

[db2psin@member0 ~]$ db2 connect to sample

   Database Connection Information

 Database server        = DB2/LINUXX8664 11.1.1.1
 SQL authorization ID   = DB2PSIN
 Local database alias   = SAMPLE

[db2psin@member0 ~]$ db2 "select current timestamp as timestamp, current member as memberID from sysibm.sysdummy1"

TIMESTAMP                  MEMBERID
-------------------------- -----------
2017-03-02-05.28.20.142613           0

  1 record(s) selected.

同じ SQL を member1 サーバーで実行すると、「MEMBERID=1」のレコードが得られるので試してみてください。この SQL のように「CURRENT MEMBER」を「CURRENT TIMESTAMP」と組み合わせて使うと、「そのメンバーID を持つメンバーが、その時点で正常に SQL に応答した」ことがアプリケーションの観点で確認できます。そのため、たとえばサーバーの障害テストを行うときにこの SQL を繰り返し実行しておくと、「DB サーバーが正常に SQL に応答していた証拠」として利用できるので重宝します。

このステップではインストールした pureScale を使って「pureScale らしい」挙動の例を 2 点紹介しました。そのほかにも、IBM Redbook 「Delivering Continuity and Extreme Capacity with the IBM DB2 pureScale Feature」や、IBM developerWorks にあるトラブルシューティングの例を紹介した記事など、さまざまな操作を解説した記事があるので、興味がある方は参照してみてください。

まとめ

この記事では、DB2 for LUW のトランザクション処理向けのスケールアウト・ソリューションである DB2 pureScale を、誰でも使えるクラウド環境で動かしてみるための手順を紹介しました。AWS に限らず、Bluemix Infrastructure や VMWare など、Linux サーバー(RHEL もしくは SLES)を複数稼働させることができる環境であればどこでも動かすことができるので、ぜひお試しください。

この記事では動く環境を作ることにフォーカスしましたが、せっかく高可用性データベースを構築したので、サーバーに障害が起きたときにどうなるかも試してみたいところです。もし障害テストをやってみようと思う方は、テストの前に「DB2 pureScale Feature で SCSI-3 Persistent Reserve を使用可能にする」を実行しておいてください。高速なリカバリーのためにはこのステップが必要不可欠です。

おことわり

「はじめに」で、「テストや評価目的の DB2 pureScale を構築する手順」としているのは、DB2 pureScale が正式にサポートする稼働環境にはいくつかの前提があるためです。たとえば、この記事で利用しているクラウドベンダーが提供する仮想環境は、DB2 pureScale の前提とは必ずしも一致しません。そのため、この記事で紹介するのは「ある条件で DB2 pureScale のセットアップが完了し、稼働することが確認できた手順」であり、IBM の正式なテストを経た DB2 pureScale のサポート前提を満たす環境としてガイドするものではないことを、ご了承ください。

DB2 pureScale の前提については IBM Knowledge Center に最新の情報が掲載されています。


ダウンロード可能なリソース


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=ビジネス・アナリティクス, Information Management, Cloud computing
ArticleID=1044634
ArticleTitle=DB2 pureScale をクラウド環境で動かしてみよう
publish-date=04182017