Skip to Content
Author's profile photo Former Member
Former Member
December 20, 2016

SAP HANA (5) MDC(Japanese)

SAP HANAシステム管理の基礎(5)〜マルチテナントデータベースコンテナー

マルチテナントデータベースコンテナー(以降、MDC)は、SAP HANA 1.0 SPS09からサポートされた機能です。この機能が登場するまでは、HANAインスタンス１つがデータベース１つを運用する形式で、これをシングルテナントシステムと呼んでいます。MDCにより、１つのHANAインスタンスが複数のデータベースを運用することができるようになりました。
このブログは、シングルテナントとの違いや運用上の考慮点をまとめたものです。

コンテナーとは何か？
MDCを使用すると、アプリケーションレベルでは専用のデータベースが提供されているように見えます。データベースサービスは利用できますが、このレベルではシングルテナントなのか、MDCなのかはわかりません。

しかし、HANAインスタンスの運用レベルで見ると、インスタンスは１つで、その中で複数のテナントDBが存在し、それぞれ独立したプロセスとファイルが用意されているのがわかります。
つまりコンテナーとは、ユーザーDBたるテナントDBを作成し運用するために必要なリソース一式を意味し、その実体はindexserverとこれに属するデータボリューム、ログボリュームなどです。


マルチコンテナーの意義
テナントDBをホストするindexserverは各プロセスごとにSQLポートが割り当てられています。クライアントからの接続はこのポートにより分離されることになります。
また、各テナントDBの管理者はHANAインスタンスレベルだけではなく、OSレベルでも設定可能です。これは、各テナントDBの管理ユーザーを分けるという意味だけではありません。各indexserverプロセスのオーナーに別々のLinuxユーザーを割り当てることにより、あるindexserverプロセスが他所のデータボリューム/ログボリュームにアクセスできなくするという、OSレベルでのアクセスコントロールができるということを意味します。
リソースがテナントDBごとに分かれていると、ファイル破壊などの障害を特定のテナントDBに封じ込めるという障害対応的な効果もあります。
このようにSAP HANAのマルチコンテナーは、コスト削減だけを目指したマルチテナント実装だけではなく、クラウド時代のデータベースとして必要なセキュリティや障害対応の要件を満たす実践的な実装も考慮されています。

尚、MDC導入と同時にインスタンス全体を管理する情報はsystemdbという特別なデータベースの中で管理されることとなり、nameserverとこれに属するデータボリューム、ログボリュームなどのリソースによりsystemdbが運用されることになります。

プロセスとファイル
プロセス
インストール直後のMDC環境にはテナントDBが存在しません。したがって、この時のプロセス構成は以下のHDB infoの出力のようになります。

  • nameserverがsystemdb用に起動される
  • 他のプロセスは、systemdb及び全てのテナントDBのために働く

テナントDBを作成すると以下のように（下から２行目）、indexserverプロセス(hdbindexserver)が起動されるのがわかります。

  • indexserverがテナントDBごとに起動される
  • テナントDBごとに異なるポート番号が与えられる

ファイル
データボリュームは、/hana/data/<sid>ディレクトリ（規定値）にファイルが展開されます。以下は、テナントDBが２つさくさ制されている状態です。

  • インストール直後は、systemdbだけが存在するため、mnt00001/hdb00001ディレクトリ下にデータボリュームファイルが作成される。
  • テナントDBを作成した時に、mnt00001/hdb00002.nnnnnディレクトリ下にデータボリュームファイルができる
    • nnnnnは、00003からの連番。
    • 例えば、2番目のテナントDBは、mnt00001/hdb00002.00004

ログボリュームのファイルの展開は基本的にデータボリュームと同じです。

システムビュー
M_DATABASES
MDC対応に伴い追加されたビューです。データベース毎の名前、ステータス、OSレベルのユーザー、パスワードなどの情報が入ります。
systemdbの場合、スコープがシステム全体になるので全てのテナントDBに関するローが見えますが、各テナントDBの場合、スコープがデータベースレベルになるために自身のローだけが見えることになります。

M_DATABASE
こちらも、MDC対応に伴い追加されたビューです。
接続しているデータベースの名前、ホスト、スタート時間などの情報が見えます。

M_SERVICES
既存のビューですが、MDC環境下では、M_DATABASESのように接続中のデータベースにより見え方が変わります。
systemdbにおいては、テナントDB関連の情報、即ちindexseverのローが見えません。（下記）

また、テナントDBにおいては、自身のindexserverとnameserverを含む全ての共有サービスの情報が見えますが、他のテナントDBの情報は見えません。これは、M_SERVICE_STATISTICSについても同様であり、統計情報や状態に関する情報を得たい場合、どこのDBに接続しているかは意識する必要があります。

SYS_DATABASESスキーマ
上記システムビューは、SYSスキーマ下に配置されていますが、MDC対応に伴いSYS_DATABASESスキーマが新設され、この下に配置されたビューから、全てのデータベースのサマリー情報が得られます。
例えば、以下の図はSYS.M_BACKUP_CATALOGですが、接続しているDB1データベースのバックアップカタログの情報が得られます。

一方、SYS_DATABASES.M_BACKUP_CATALOG（下図）には、systemdbを含む全てのデータベースのバックアップカタログ情報が集約されています。このため、DATABASE_NAMEというから無名が追加されてどのデータベースの情報化がわかるようになっています。

クライアントからの接続
MDCにおけるクライント接続は、基本的にはシングルテナントと同じメカニズムを取りながら、MDC固有の動きや接続先のポート番号の割り当ての違いがあります。
ポート番号の割り当て
シングルテナントの場合、indexserverのSQLポート3xx15(xxはsid。デフォルト)をクライアント接続に使用していましたが、MDCの場合以下のような割り当てがされます。

ポート用途 テナントDB 1 テナントDB 2  … テナントDB 20
Internal 3xx40 3xx43 3xx97
SQL 3xx41 3xx44 3xx98
Http 3xx42 3xx45 3xx99
  •  Internal : サービスプロセス間の通信用
  • SQL : クライアント接続用
  • Http : 組み込みXS用

デフォルトではポート割り当てにプールされている範囲は、3xx40 – 3xx99です。1つのindexserverに3ポートを割り当てるので最大20テナントDBを持てることになります。それ以上の数のテナントDBを持つには、以下の設定で割り当てられるポート番号の範囲を広げます。

global.ini[multidb]reserved_instance_number=n (n: 0,1,2,,,)
  • 0(デフォルト)：3xx40-3xx99
  • 1：3xx40-3x199
  • 2：3xx40-3x299
  • ,,,

接続文字列
基本的に、ホスト名(またはIPアドレス)、ポート番号を指定するとテナントDBが特定されるので、点はシングルテナントと同様です。

hostname:indexserver_port
(説明の便宜上の仮想的なURL表現です)

MDC固有な機能としては、接続したいデータベース名を引数にしてnameserverに接続するとHANAが自動的に適切なindexserverに接続してくれる機能があります。

hostname:nameserver_port/databasename=db1
(説明の便宜上の仮想的なURL表現です)

この方法を使用すると、ポート番号は30013(デフォルト値の場合)に固定され、使い勝手としては、nameserverにデータベースの在り処を問い合わせるような感じになります。

特に、スケールアウト構成でMDCを組む場合、テナントDBが移動したり、フェールオーバーする場合にも接続先が透過的になりますので、便利な指定方式と言えます。
hdbsql、ODBC、JDBC等それぞれの指定方法については、Client connection to SAP HANA(Japanese)をご覧ください。
バックアップ＆リストア
シングルテナントの場合は、BACKUP DATAコマンドを一回実行すると、nameserver、indexserver、xsengineなどのデータボリューム・ログボリュームを一括してバックアップしていましたが、MDCにおいてはsystemdbと個々のテナントDBのバックアップを個別にとります。

BACKUP DATA FOR database_name  USING FILE('file_base_name');
BACKUP DATA INCREMENTAL FOR database_name  USING FILE('file_base_name');
BACKUP DATA DIFFERENTIAL FOR database_name  USING FILE('file_base_name');

そのため、

  • それぞれのバックアップは、いつの時点のものか？
  • テナントDBバックアップとそのテナントDB作成後のsystemdbバッックアップが対で存在するか。
  • 障害の範囲（systemdbか、テナントDBか？）

を意識する必要があります。MDCにおけるバックアップ＆リストアの特徴は以下の通りです。

  • Ÿバックアップ/リストアはDB単位。
  • テナントDBのみのリカバリー可能
  • systemdbのリカバリーはテナントDBのリカバリーを伴う
  • ŸテナントDBのリカバリー中、他のテナントDBにはアクセス可能
  • Ÿsystemdbのリカバリー中、テナントDBにはアクセス不可能
  • Ÿシングルテナントのバックアップは、MDC環境にリストアできない（SPS12現在）

HANA CockpitからテナントDBへの接続

通常は、以下のURLに接続するとHANA Cockpitを使用できますが、

https://<host>:43<instance>/sap/hana/admin/cockpit
 または、
http://<host>:80<instance>/sap/hana/admin/cockpit

インストール直後の状態では、systemdbにしか接続できません。HANA Studio等のクライアントアプリケーションのようにデータベース名やシステム番号 、ポート番号を指定して特定のテナントDBに接続する手段が提供されていないというわけです。
そのために以下のような設定が必要になります。

  1. 仮想ホスト名をDNSなどのネームサービスに登録する。つまり、IPアドレスに対するホスト名を１つ追加するイメージです。
  2. HANAインスタンスに、仮想ホストとテナントDBの関係を登録する

つまり、systemdbに接続するときと同じホスト、同じポート番号なのですが、URLを受け取ったwebdispatcherというプロセスは仮想ホスト名が使われている時はテナントDBをホストするindexserverのHTTPポートに接続をフォワードするという仕組みになっています。
実際の手順は、以下のようになります。

ネームサービスに仮想ホストを登録
以下の例は、ブラウザを使うコンピューターの/etc/hostsで対応しようとしています。赤線で囲まれた部分が仮装ホスト、その直前の（モザイクかけられた）ホスト名がHANAのインストール時に使用されたホスト名です。
仮想ホストとテナントDBの関係を登録
xsengine.ini[database]テナントDB名に対して仮想ホスト名を用いたURLを与えることにより、関係が定義されます。

登録したURLでアクセス
この例では、http://host2db1:8000/sap/hana/admin/cockpit にアクセスすると以下のようなテナントDB管理用HANA Cockpitのログイン画面が現れます。

権限の自動追加
必要な権限が自動追加される旨、通知されます。
テナントDB管理画面
（以下は、バックアップに関するロールを追加したため、Data Backupタイルも表示されています。）

余談ですが、HANA CockpitではこのようにテナントDBに接続してバックアップを実行できますが、HANA Studioでは、systemdbへの接続でなければバックアップメニューが現れません。
また、SQLによるバックアップもsystemdbへのセッション上で行う必要があります。
この辺りは、仕様が統一されてない感がありますが、今後ツールの機能拡張はHANA Cockpitに対して行われる方針ですので将来的には改善されると思われます。
データベースの独立性(Database isolation)
テナントDBにはデータベース独立性のレベル（High/Low）があります。インストールの時に決めることができますが、運用中に変更することも可能です。
データベース独立性は、テナントDBを運用する上でのセキュリティレベルを決定します。インストール時のデフォルトは”Low”で、OSレベルでは<sid>admユーザーが全てのテナントDBを運用します。
”High”に設定すると、<sid>admの代わりに、テナントDBごとに異なるユーザー/グループを設定できます。データボリュームを始めとするファイルのアクセス権やindexserverプロセスのオーナーが異なるため、OSレベルでのセキュリティレベルが上がることになります。
「マルチコンテナーの意義」の部分で述べたように、この仕様はクラウドに採用されるデータベースにとって不可欠な機能といえるでしょう。
データベースの複製/移動
MDCを設定するとインスタンス間でテナントDBの複製/移動ができるようになります。
例えば、下図で左側のインスタンスが複製元、右側が複製先だとします。
まず、複製先のsystemdbで以下を実行します。

CREATE DATABASE new_db_name
AS REPLICA OF source_db_name AT 'host:port';

そうすると、複製元でスナップショットが作成され複製先へと転送されます。続いて、ログバックアップが実行され複製先に転送されます。スナップショットとログバックアップからデータベースの複製が作成されます。（この時点では、複製です。）
次にファイナライズを行います。移動の場合、

ALTER DATABSE new_db_name
FINALIZE REPLICA
DROP SOURCE DATABASE;

を実行すると複製元のデータベースが削除され結果として移動したことになります。

また、複製の場合、

ALTER DATABASE new_db_name
FINALIZE REPLICA;

を実行すると、複製先は残り、結果として複製になります。
ただ実際は、準備作業として

  • データベース独立性として”High”を設定する
  • 公開鍵認証の設定をする

のどちらかを行う必要があります。HANAには公開鍵認証のためにSystemPKIという基盤が組み込まれています。SPS12現在では、多少面倒な設定ですが、以下のブログに手順をまとめてありますのでトライする場合は参考にしてください。
SAP HANAマルチテナントデータベースコンテナーインスタンス間のデータベースの複製・移動

以上
（内容はHANA 1.0 SPS12に基づいています。）

花木敏久
toshihisa.hanaki@sap.com

Assigned Tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.