[D34] Shared Nothingなのに、Active-Activeクラスタ？～高いスケーラビリティを誇る日立国産DBMS「HiRDB」のクラスタ技術～ by Akito Wakisaka

© Hitachi, Ltd. 2013. All rights reserved.

Shared Nothingなのに、Active-Activeクラスタ？

～高いスケーラビリティを誇る日立国産ＤＢＭＳ「ＨｉＲＤＢ」のクラスタ技術～

株式会社日立製作所情報・通信システム社 ITプラットフォーム事業本部開発統括本部ソフトウェア開発本部 DB設計部

2013/11/15

脇坂彰人（わきざかあきと）

© Hitachi, Ltd. 2013. All rights reserved. 1

教育行政

健康／医療水

製造／流通交通

金融エネルギー

ビッグデータ利活用

高信頼クラウド

情報活用がリードするビジネスと社会

スマート情報

セキュリティ

Hitachi

Advanced

Data Binder※

ストリーム

データ処理

インメモリ

データグリッド

並列DBMS

Hadoop

技術が支えるビジネスの価値創出

※『内閣府の最先端研究開発支援プログラム「超巨大データベース時代に向けた最高速データベースエンジンの開発と当該エンジンを核とする戦略的社会サービスの実証・評価」（中心研究者：喜連川東大教授／国立情報学研究所所長）の成果を利用』


Ｃｏｎｔｅｎｔｓ

１．ＨｉＲＤＢは、「ＳｈａｒｅｄＮｏｔｈｉｎｇ」

２．ＳｈａｒｅｄＮｏｔｈｉｎｇなのに、Ａｃｔｉｖｅ-Ａｃｔｉｖｅクラスタ？

３．Ａｃｔｉｖｅ-Ａｃｔｉｖｅクラスタの実力は？

2


１．ＨｉＲＤＢは、「ＳｈａｒｅｄＮｏｔｈｉｎｇ」

3


ＤＢサーバ

ストレージ

■Shared Disk

ＤＢサーバ

ストレージ

ＳｈａｒｅｄＮｏｔｈｉｎｇは、データベースを分割し、ＤＢサーバが重複なく割り当てられたデータを

独立に処理するアーキテクチャ

並列処理

完全独立

パーティション（分割）表

■Shared Nothing


ＡＰサーバ

ＤＢサーバ

ストレージ

・データの所在位置はＦＥＳで自動認識。・ＢＥＳが受け持つデータを並列に処理。・ＢＥＳの処理結果をＦＥＳが纏めて返却。


更新ログ

*1 : ＳＱＬ受付サーバ (Front End Server)

ＦＥＳ

ＢＥＳ *2 : ＤＢアクセスサーバ (Back End Server)

業務ＡＰは、データの所在を意識しない

ＦＥＳ１ＦＥＳ２

ＢＥＳ１ＢＥＳ２

ＦＥＳｎ

ＢＥＳｍ

完全独立

業務ＡＰ

排他プール

ＤＢバッファ

ＤＢアクセスに必要なリソースが独立し、競合が無い

□ＤＢをアクセスするＢＥＳ(*２)が、分割されたデータを独立に処理する。 □ＦＥＳ(*１)がＳＱＬを振り分け、業務ＡＰにデータの所在を意識させない。

ＳｈａｒｅｄＮｏｔｈｉｎｇアーキテクチャ


２．ＳｈａｒｅｄＮｏｔｈｉｎｇなのに、Ａｃｔｉｖｅ-Ａｃｔｉｖｅクラスタ？

6


ＤＢサーバの障害に備えるために欠かせないクラスタ構成

障害

切り換え

ストレージ

ＤＢサーバ

ＳｈａｒｅｄＮｏｔｈｉｎｇで構築するクラスタ構成は？


稼動中サーバごとに待機サーバを用意するＡｃｔｉｖｅ-Ｓｔａｎｂｙでのクラスタ構成

ストレージ

障害

ＤＢサーバ


クラウド、従量課金

投資リソースを活用したい


Ａｃｔｉｖｅ-Ａｃｔｉｖｅクラスタはどうなの？

9


障害サーバの処理を稼動中サーバで引き継ぐＡｃｔｉｖｅ-Ａｃｔｉｖｅでもクラスタ構成

ＤＢサーバ

ストレージ

障害

障害サーバに割り当てられていたデータの処理を引き継ぐ

■Shared Disk

ＤＢサーバ

ストレージ

障害


■Shared Nothing

縮退

投資リソースの有効活用

□障害サーバが担当していたデータを，他の稼働中サーバが分担する


□ 完全独立しているのに、障害サーバの処理をどう引き継ぐの？ □ 複数サーバの障害に対応はどうやるの？

ＳｈａｒｅｄＮｏｔｈｉｎｇなのに、Ａｃｔｉｖｅ-Ａｃｔｉｖｅクラスタ？

ＤＢサーバ

ストレージ

障害



Ａｃｔｉｖｅ-Ａｃｔｉｖｅクラスタ構成

□ＢＥＳ単位で、稼動中サーバに切り替えて業務を継続。 □あらかじめ複数のＢＥＳを配置し、複数の稼働中サーバに負荷を分散できる。

ＤＢサーバ１

障害発生時通常運用時

ＢＥＳ１

ＢＥＳ単位で切り替え(移動) ⇒分散引継ぎ

ＤＢサーバ１ＤＢサーバ３ＤＢサーバ２ＤＢサーバ３ＤＢサーバ２

ＢＥＳ２

ＢＥＳ３

ＢＥＳ４

ＢＥＳ５

ＢＥＳ６

ＢＥＳ１

ＢＥＳ２

ＢＥＳ３

ＢＥＳ４

ＢＥＳ５

ＢＥＳ６

ＢＥＳ１ＢＥＳ２障害

ＤＢサーバ２、ＤＢサーバ３で処理を分散して引き継ぐ。サーバ間の負荷は平準化。

ＤＢ及びシステムログ引継ぎ＆継続使用


２台目もダウンしたら？

ＤＢサーバ１


ＢＥＳ１


ＢＥＳ２

ＢＥＳ３

ＢＥＳ４

ＢＥＳ５

ＢＥＳ６

ＢＥＳ１

ＢＥＳ２

ＢＥＳ３

ＢＥＳ４

ＢＥＳ５

ＢＥＳ６



複数サーバでの障害発生にも対応

□多点障害でも、第２、第３の稼動中のＤＢサーバに処理を引き継げる。

ＤＢサーバ１

さらに２台目の障害発生時１台目の障害発生時

ＢＥＳ１


ＢＥＳ２

ＢＥＳ３

ＢＥＳ４

ＢＥＳ５

ＢＥＳ６

ＢＥＳ３

ＢＥＳ４

ＢＥＳ５

ＢＥＳ６

ＢＥＳ１ＢＥＳ２ＢＥＳ１ＢＥＳ２

障害ＢＥＳ３

ＢＥＳ４

ＢＥＳ１

ＤＢサーバ２の障害発生時は、ＤＢサーバ３で処理を引き継ぐ。


ＤＢバッファＤＢバッファＤＢバッファ

ＢＥＳ１

ＢＥＳ１

ＢＥＳ１

ＢＥＳ２

ＢＥＳ２

ＢＥＳ２

ＢＥＳ３

ＢＥＳ３

ＢＥＳ３

ＢＥＳ４

ＢＥＳ４

ＢＥＳ４

ＢＥＳ５

ＢＥＳ５

ＢＥＳ５

ＢＥＳ６

ＢＥＳ６

ＢＥＳ６

１関東３関西５中部２東日本４西日本６海外

DBAREA1

１関東

DBAREA3

３関西

DBAREA5

５中部

DBAREA2

２東日本

DBAREA4

４西日本

DBAREA6

６海外

ＦＥＳ２ＦＥＳ３

Ａｃｔｉｖｅ-Ａｃｔｉｖｅクラスタ構成を実現するからくり

ＦＥＳ１


DBAREA1

１関東

DBAREA3

３関西

DBAREA5

５中部

DBAREA2

２東日本

DBAREA4

４西日本

DBAREA6

６海外

16


ＢＥＳ１

ＢＥＳ１

ＢＥＳ１

ＢＥＳ２

ＢＥＳ２

ＢＥＳ２

ＢＥＳ３

ＢＥＳ３

ＢＥＳ４

ＢＥＳ４

ＢＥＳ５

ＢＥＳ５

ＢＥＳ６

ＢＥＳ６


ＦＥＳ１ＦＥＳ２ＦＥＳ３

障害

ＢＥＳ３

ＢＥＳ４

ＢＥＳ５

ＢＥＳ６

障害が発生したら？


ＦＥＳ１ＦＥＳ２ＦＥＳ３

DBAREA1

１関東

DBAREA3

３関西

DBAREA5

５中部

DBAREA2

２東日本

DBAREA4

４西日本

DBAREA6

６海外

17


ＢＥＳ１

ＢＥＳ１

ＢＥＳ１

ＢＥＳ２

ＢＥＳ２

ＢＥＳ２

ＢＥＳ３

ＢＥＳ３

ＢＥＳ４

ＢＥＳ４

ＢＥＳ５

ＢＥＳ５

ＢＥＳ６

ＢＥＳ６


障害

１関東２東日本

ＢＥＳ１

ＢＥＳ１

ＢＥＳ２

ＢＥＳ２

待機中プロセスが担当データを

成り変わって処理

ＤＢバッファなどのリソースを共有

切り替え完了までキューイング

□ＤＢバッファの占有もできます

稼動中サーバのリソースを有効活用

□自動でアクセス先を切り替え □不足したプロセスは追加起動


ＤＢサーバ１ＤＢサーバ３ＤＢサーバ２

ＢＥＳ１

ＢＥＳ２

ＢＥＳ３

ＢＥＳ４

ＢＥＳ５

ＢＥＳ６

ＨＡモニタＨＡモニタＨＡモニタ

ＢＥＳ＊ＢＥＳ＊

ＢＥＳ＊ＢＥＳ＊ＢＥＳ＊

ＢＥＳ＊

ＢＥＳ＊ＢＥＳ＊ＢＥＳ＊

ＢＥＳ＊ＢＥＳ１ＢＥＳ２

ＢＥＳ3の切り替えを指示

どのサーバの受け入れも可能

18

Ａｃｔｉｖｅ-Ａｃｔｉｖｅクラスタの切り替え先制御

※Microsoft Failover ClusterやHP Serviceguardなどと組みあわせるには、HA Toolkit Extensionを使います。

障害

□日立のクラスタソフトウェアＨＡモニタ※と連携して、Ａｃｔｉｖｅ-Ａｃｔｉｖｅクラスタを開発しました

□切り替え可能なサーバの情報を連携し、担当データの切り替え先を制御


３．Ａｃｔｉｖｅ-Ａｃｔｉｖｅクラスタの実力は？

19


切り替え時間ってどれくらい？


数秒です！

デモでご体感ください。


Ａｃｔｉｖｅ-Ａｃｔｉｖｅクラスタデモンストレーション

□ 数秒オーダでの切り替え □ 多重障害への対応

障害

稼働中サーバに負荷分散し、安定した業務継続

切り替え中でも新規トランザクションを受付可能

DBサーバ2 DBサーバ3 DBサーバ1

DBサーバ CPU利用率

数秒オーダで切り替え

全面ダウン期間ゼロ

2台で稼動

DBサーバ全体スループット

3台で稼動


デモンストレーションで数秒オーダの切り替えの様子を

ご覧ください。


ＨｉＲＤＢ

ＨＡモニタ

ＨＡＢｏｏｓｔｅｒＰａｃｋ

ＨｉＲＤＢ

ＨＡモニタ


障害

Ａｌｉｖｅ監視

（ａ）素早く検知

（ｃ）素早く回復

切替元切替先

※ ＨＡモニタ、ＨＡＢｏｏｓｔｅｒＰａｃｋ：クラスタウェア

ＤＢログ

HiR

DB

Versio

n 7

□『検知・引継ぎ・回復』の３つのポイントの高速化で、数秒オーダでの切り替えを実現。

（ｂ）素早く引継ぎ

数秒での切り替えのからくり

HiR

DB

Versio

n 7

※1：障害発生～新規トランザクション受付開始までの時間。※2：トランザクション決着時間はシステムログ量に依存。

▼リソース切り替え ▼回復準備

▼ＤＢ回復▼トランザクション決着

数秒オーダ

※2▼障害検知

時間Active-Active

フェイルオーバ時間 ※1


ＤＢログ

ＨｉＲＤＢ

ＨＡモニタ


ＨｉＲＤＢ

ＨＡモニタ


Ａｌｉｖｅ監視

切替元切替先

25

・切替元のマシンダウンを、切替先からのハートビートで検知。・切替先から切替元のマシンをリセット。

ＨｉＲＤＢのスローダウンを、生存監視機能（Time Stampの定期更新/定期参照）により、ＨＡモニタが検知。

ＨｉＲＤＢ障害

ＨｉＲＤＢスローダウン

マシンダウン

ＯＳパニック

Time

Stamp

監視

申告

監視

通知

□マシンダウン □ＯＳパニック □ＨｉＲＤＢダウン

クラスタウェア間でのＡｌｉｖｅ監視による検知ＨＡＢｏｏｓｔｅｒＰａｃｋでの通知による瞬時検知ＨｉＲＤＢ自らの申告によるゼロ秒検知

（ａ）素早く障害を検知する


ＤＢログ

ＤＢログ

ＤＢログ

ＤＢログ

26

ＨＡモニタ

ＨＡモニタ

切替元切替先

ＨｉＲＤＢ


ＨｉＲＤＢ

・・・


・・・

□共有ディスクの数に依存しない、短時間でのディスク引継ぎ： ①ＨＡＢｏｏｓｔｅｒＰａｃｋがＨｉＲＤＢのＩ/Oに介在し、切替元からのアクセスのみを許可。

②障害発生時、アクセス制御の変更のみで引継ぎを実現。

常時オンライン（活性）状態

①I/O介在でのアクセス制御

（ｂ）素早くリソースを引き継ぐ


ＤＢログ

ＤＢログ

ＤＢログ

ＤＢログ

27

ＨＡモニタ

ＨＡモニタ

ＨｉＲＤＢ


ＨｉＲＤＢ

・・・


・・・

②アクセス制御の変更（引継ぎ）

共有ディスク数

切替時間

HA Booster Packなし

共有ディスク数

切替時間

HA Booster Packあり

アクセス

拒否

切替先ディスク

切替元ディスク

非活性化

一括処理

シーケンシャル処理

活性化

アクセス

許可

活性化

（ｂ）素早くリソースを引き継ぐ

□共有ディスクの数に依存しない、短時間でのディスク引継ぎ： ①ＨＡＢｏｏｓｔｅｒＰａｃｋがＨｉＲＤＢのＩ/Oに介在し、切替元からのアクセスのみを許可。

②障害発生時、アクセス制御の変更のみで引継ぎを実現。

切替元切替先


□高速ＤＢ回復＆稼動中のリソースの利用で早期サービス再開 - 高速ＤＢ回復

- 稼動中のリソースの利用

□Ａｃｔｉｖｅ-ＡｃｔｉｖｅクラスタではＤＢ回復を稼動中サーバに分散して実施

①ディスク毎の並列ＤＢ回復 ②新規トランザクションの早期受付開始

③ＤＢ処理プロセスの成り代わり

（ｃ）素早くＨｉＲＤＢを回復させる

切替先

ＤＢ回復（ディスク１）

ＤＢ回復（ディスク２）

時間

ＤＢ回復（ディスク３）

ＤＢ回復（ディスク４）

ＤＢ回復トランザクションの決着

ＨＡモニタ


②新規トランザクションの早期受付開始

③ＤＢ処理プロセスの成り代わり

ＨｉＲＤＢ

稼働中

ＤＢ回復

回復トランザクション新規トランザクション稼働中のトランザクション

回復準備

ＨＡモニタ


ＨｉＲＤＢ

稼働中回復準備

ＤＢ回復

ＢＥＳ４ＢＥＳ１

ＢＥＳ６ＢＥＳ２

ＢＥＳ４

ＢＥＳ１

ＢＥＳ６

ＢＥＳ２

28

時間

切替指示

切替指示

ＢＥＳ５

ＢＥＳ３

ＢＥＳ３

ＢＥＳ５

①ディスク毎の並列ＤＢ回復

稼動中HiRDBへの切り替え


システムのＳＬＡを維持する

□切り換えタイミングで割り当てCPUを活性化し、ＳＬＡを維持する

ＤＢサーバ３ＤＢサーバ２

ＢＥＳ１

ＢＥＳ２

ＢＥＳ３

ＢＥＳ４

ＢＥＳ５

ＢＥＳ６


CPU

CPU

CPU

CPU

CPU

CPU

CPU CPU

ＤＢサーバ１

障害サーバの担当データの処理性能を確保するためにＣＰＵを活性化


ＳｈａｒｅｄＮｏｔｈｉｎｇなのに、Ａｃｔｉｖｅ-Ａｃｔｉｖｅクラスタ？

□通常運用時、各ＤＢサーバが担当データを独立に処理。

□障害発生時、障害サーバの担当データを稼動中のサーバが引き継ぐ。

□独立しているのに、オンデマンドにシェアするＡｃｔｉｖｅ-Ａｃｔｉｖｅクラスタ。

ＤＢサーバ１


ＢＥＳ１


ＢＥＳ２

ＢＥＳ３

ＢＥＳ４

ＢＥＳ５

ＢＥＳ６

ＢＥＳ１

ＢＥＳ２

ＢＥＳ３

ＢＥＳ４

ＢＥＳ５

ＢＥＳ６



いかがでしたでしょうか？

『ＳｈａｒｅｄＮｏｔｈｉｎｇなのに、Ａｃｔｉｖｅ-Ａｃｔｉｖｅクラスタ？』

ＳｈａｒｅｄＮｏｔｈｉｎｇアーキテクチャでの

Ａｃｔｉｖｅ-Ａｃｔｉｖｅクラスタのからくりを

ご紹介しました。

31


これからも

Made in Japan DBMS, を

極めていきます。

今後も、日立のデータベースに

ご期待ください。

HiRDB:Highly Scalable Relational DataBase


株式会社日立製作所情報・通信システム社 ITプラットフォーム事業本部開発統括本部ソフトウェア開発本部 DB設計部

～高いスケーラビリティを誇る日立国産DBMS「HiRDB」のクラスタ技術～

Shared Nothingなのに、Active-Activeクラスタ？

2013/11/15

脇坂彰人

END

33


他社所有名称等に関する表示

34

・製品の内容・仕様は、改良のために予告なしに変更する場合があります。・ Hadoop は，Apache Software Foundationの商標です。・ Microsoftは，米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。・ HP Serviceguardは，Hewlett-Packard Development Company, L.P.の商品名称です。・本資料に記載の会社名，製品名は，それぞれの会社の商標もしくは登録商標です。

35


付録


関東09

支店番号

～1999

支店番号

2000～2999

支店番号

3000～

＜９月＞

＜関東地区＞＜関西地区＞＜その他地区＞

関東08 ＜８月＞

関東07 ＜７月＞

DBAREA1 DBAREA2 DBAREA3



日付と支店番号でＤＢを分割した例

日付地区支店支店番号売上・・・

2011-07-30 関東東京 1001

2011-07-30 関西大阪 2001

2011-07-30 九州福岡 3010

・・

2011-08-30 関東横浜 1010

2011-08-30 東北仙台 4001

2011-08-30 関西京都 2008

・・

2011-09-30 関東東京 1001

2011-09-30 関西神戸 2015

・・

支店売上管理表

第１次元分割列

第２次元分割列

関東集計業務

関西集計業務

その他集計業務

関西09

関西08

関西07

他09

他08

他07

時間軸での分割

空間軸での分割

一定期間保管

ＢＥＳ１ＢＥＳ２ＢＥＳ３

□月単位に支店グループを２次元分割

□独立したＢＥＳで並列に処理





39

ＤＢ格納領域の簡単なローテーション運用

支店番号

～1999

支店番号

2000～2999

支店番号

3000～


＜９月＞

＜８月＞

＜７月＞

＜１０月＞

月別ハッシュ分割

＜７月＞

＜１０月＞

ＤＢ格納領域の削除・追加が大変

ローテーション運用を容易にする『月別ハッシュ分割』の利用

＜９月＞

＜８月＞

＜７月＞⇒＜１０月＞

関東09

関東08

関東07

関西09

関西08

関西07

他09

他08

他07

関東10

■従来の運用

□ＤＢの格納領域を、月次で簡単に再利用。


今や、ストレージ仮想化技術で対処できる時代


ディスク追加

支店番号

～1999

支店番号

2000～2999

支店番号

3000～


見積もり、設計が大変

・データ増加を予測した見積もり設計。・それに伴う拡張・運用設計の立案。・ＤＢエリアのパンク回避のための余裕値設計。


・仮想ディスクに最大サイズでＤＢエリアを確保でき、ＤＢ容量設計が容易。・ＤＢエリアの自動拡張に伴い、オンデマンドでストレージを割り当てられる。・ストレージプール全体で枯渇監視でき、監視、拡張運用が容易。

ストレージプール

ＨＤＤ

仮想Voｌ(ディスク)

予備予備

監視、運用が大変

・個々のＤＢエリアの監視。・ディスク追加によるＤＢエリア拡張。

最大

オンデマンド

ストレージプールを活用した資源共有により負担を軽減

□ＤＢ格納領域の見積もり、運用がどれだけ必要？大変？

■従来の運用 ■ストレージ機能と連携したシン・プロビジョニングでの運用


マスタ表の効率的な共有アクセス

ＡＰサーバ

ＤＢサーバ

ストレージ

ＢＥＳ１

ＦＥＳ１

特定ＢＥＳへのアクセス集中を回避できる

全ＢＥＳから参照できる『共用表』属性を利用

・全ＢＥＳから参照できる表属性。・各ＢＥＳのバッファで独立して参照できる。・複数のＢＥＳから参照する場合でも、ＢＥＳ間での通信はおこなわない。ＢＥＳ２

ＦＥＳ２

ＢＥＳ３

ＦＥＳ３


DBAREA10

商品マスタ

関東関西他

関東集計業務

関西集計業務



関東マスタ

関西マスタ

その他マスタ

共用表属性

□マスタ系データの配置は？


・共用表の更新要求を全ＢＥＳに配布。・バッファヒットしない場合はストレージから読み込んでバッファを更新。・受け持ちＢＥＳだけがストレージ上のデータを更新。・更新ログは全ＢＥＳで出力。

更新

ＡＰサーバ

ＤＢサーバ

ストレージ

ＢＥＳ１ＢＥＳ２

ＦＥＳ２

ＢＥＳ３

ＦＥＳ３


DBAREA10

商品マスタ

関東関西他

関東集計業務

関西集計業務



関東マスタ

関西マスタ

その他マスタ

共用表属性

受け持ちＢＥＳ

ＦＥＳ１

じゃあ、「共用表」を更新したら、どうする？

ＤＢサーバの独立性を確保する

□更新要求をＦＥＳが受け、全ＢＥＳに配布。バッファを更新。

□受け持ちＢＥＳだけがストレージ上のデータを更新。

Technology

[D34] Shared Nothingなのに、Active-Activeクラスタ？ ～ 高いスケーラビリティを誇る日立国産DBMS「HiRDB」のクラスタ技術 ～ by Akito Wakisaka

[D34] Shared Nothingなのに、Active-Activeクラスタ？～高いスケーラビリティを誇る日立国産DBMS「HiRDB」のクラスタ技術～ by Akito Wakisaka