[D34] Shared Nothingなのに、Active-Activeクラスタ? ~...
-
Upload
insight-technology-inc -
Category
Technology
-
view
1.983 -
download
5
description
Transcript of [D34] Shared Nothingなのに、Active-Activeクラスタ? ~...
© Hitachi, Ltd. 2013. All rights reserved.
Shared Nothingなのに、Active-Activeクラスタ?
~ 高いスケーラビリティを誇る日立国産DBMS「HiRDB」のクラスタ技術 ~
株式会社 日立製作所 情報・通信システム社 ITプラットフォーム事業本部 開発統括本部 ソフトウェア開発本部 DB設計部
2013/11/15
脇坂 彰人(わきざか あきと)
© Hitachi, Ltd. 2013. All rights reserved. 1
教 育 行 政
健康/医療 水
製造/流通 交 通
金 融 エネルギー
ビッグデータ利活用
高信頼クラウド
情報活用がリードする ビジネスと社会
スマート情報
セキュリティ
Hitachi
Advanced
Data Binder※
ストリーム
データ処理
インメモリ
データグリッド
並列DBMS
Hadoop
技術が支えるビジネスの価値創出
※『内閣府の最先端研究開発支援プログラム「超巨大データベース時代に向けた最高速データベースエンジンの開発と当該エンジンを核とする戦略的社会サービスの実証・評価」(中心研究者:喜連川 東大教授/国立情報学研究所所長)の成果を利用』
© Hitachi, Ltd. 2013. All rights reserved.
Contents
1.HiRDBは、「Shared Nothing」
2.Shared Nothingなのに、Active-Activeクラスタ?
3.Active-Activeクラスタの実力は?
2
© Hitachi, Ltd. 2013. All rights reserved.
1.HiRDBは、「Shared Nothing」
3
© Hitachi, Ltd. 2013. All rights reserved. 4
DBサーバ
ストレージ
■Shared Disk
DBサーバ
ストレージ
Shared Nothingは、データベースを分割し、 DBサーバが重複なく割り当てられたデータを
独立に処理するアーキテクチャ
並列処理
完全独立
パーティション(分割)表
■Shared Nothing
© Hitachi, Ltd. 2013. All rights reserved. 5
APサーバ
DBサーバ
ストレージ
・データの所在位置はFESで自動認識。 ・BESが受け持つデータを並列に処理。 ・BESの処理結果をFESが纏めて返却。
パーティション (分割)表
更新ログ
*1 : SQL受付サーバ (Front End Server)
FES
BES *2 : DBアクセスサーバ (Back End Server)
業務APは、 データの所在を意識しない
FES 1 FES 2
BES 1 BES 2
FES n
BES m
完全独立
業務AP
排他プール
DBバッファ
DBアクセスに必要なリソースが独立し、競合が無い
□DBをアクセスするBES(*2)が、分割されたデータを独立に処理する。 □FES(*1)がSQLを振り分け、業務APにデータの所在を意識させない。
Shared Nothingアーキテクチャ
© Hitachi, Ltd. 2013. All rights reserved.
2. Shared Nothingなのに、 Active-Activeクラスタ?
6
© Hitachi, Ltd. 2013. All rights reserved. 7
DBサーバの障害に備えるために 欠かせないクラスタ構成
障害
切り換え
ストレージ
DBサーバ
Shared Nothingで 構築するクラスタ構成は?
© Hitachi, Ltd. 2013. All rights reserved. 8
稼動中サーバごとに待機サーバを用意する Active-Stanbyでのクラスタ構成
ストレージ
障害
DBサーバ
パーティション(分割)表
クラウド、従量課金
投資リソースを活用したい
© Hitachi, Ltd. 2013. All rights reserved.
Active-Activeクラスタは どうなの?
9
© Hitachi, Ltd. 2013. All rights reserved. 10
障害サーバの処理を稼動中サーバで引き継ぐ Active-Activeでもクラスタ構成
DBサーバ
ストレージ
障害
障害サーバに割り当てられて いたデータの処理を引き継ぐ
■Shared Disk
DBサーバ
ストレージ
障害
パーティション(分割)表
■Shared Nothing
縮退
投資リソースの有効活用
□障害サーバが担当していたデータを,他の稼働中サーバが分担する
© Hitachi, Ltd. 2013. All rights reserved. 11
□ 完全独立しているのに、障害サーバの処理をどう引き継ぐの? □ 複数サーバの障害に対応はどうやるの?
Shared Nothingなのに、 Active-Activeクラスタ?
DBサーバ
ストレージ
障害
パーティション(分割)表
© Hitachi, Ltd. 2013. All rights reserved. 12
Active-Activeクラスタ構成
□BES単位で、稼動中サーバに切り替えて業務を継続。 □あらかじめ複数のBESを配置し、複数の稼働中サーバに負荷を分散できる。
DBサーバ 1
障害発生時 通常運用時
BES1
BES単位で 切り替え(移動) ⇒分散引継ぎ
DBサーバ 1 DBサーバ 3 DBサーバ 2 DBサーバ 3 DBサーバ 2
BES2
BES3
BES4
BES5
BES6
BES1
BES2
BES3
BES4
BES5
BES6
BES1 BES2 障害
DBサーバ2、DBサーバ3で 処理を分散して引き継ぐ。 サーバ間の負荷は平準化。
DB及びシステムログ引継ぎ&継続使用
© Hitachi, Ltd. 2013. All rights reserved. 13
2台目もダウンしたら?
DBサーバ 1
障害発生時 通常運用時
BES1
DBサーバ 1 DBサーバ 3 DBサーバ 2 DBサーバ 3 DBサーバ 2
BES2
BES3
BES4
BES5
BES6
BES1
BES2
BES3
BES4
BES5
BES6
BES1 BES2 障害
© Hitachi, Ltd. 2013. All rights reserved. 14
複数サーバでの障害発生にも対応
□多点障害でも、第2、第3の稼動中のDBサーバに処理を引き継げる。
DBサーバ 1
さらに2台目の障害発生時 1台目の障害発生時
BES1
DBサーバ 1 DBサーバ 3 DBサーバ 2 DBサーバ 3 DBサーバ 2
BES2
BES3
BES4
BES5
BES6
BES3
BES4
BES5
BES6
BES1 BES2 BES1 BES2
障害 BES3
BES4
BES1
DBサーバ2の障害発生時は、 DBサーバ3で処理を引き継ぐ。
© Hitachi, Ltd. 2013. All rights reserved. 15
DBバッファ DBバッファ DBバッファ
BES 1
BES 1
BES 1
BES 2
BES 2
BES 2
BES 3
BES 3
BES 3
BES 4
BES 4
BES 4
BES 5
BES 5
BES 5
BES 6
BES 6
BES 6
1 関東 3 関西 5 中部 2 東日本 4 西日本 6 海外
DBAREA1
1 関東
DBAREA3
3 関西
DBAREA5
5 中部
DBAREA2
2 東日本
DBAREA4
4 西日本
DBAREA6
6 海外
FES 2 FES 3
Active-Activeクラスタ構成を実現するからくり
FES 1
© Hitachi, Ltd. 2013. All rights reserved.
DBAREA1
1 関東
DBAREA3
3 関西
DBAREA5
5 中部
DBAREA2
2 東日本
DBAREA4
4 西日本
DBAREA6
6 海外
16
DBバッファ DBバッファ DBバッファ
BES 1
BES 1
BES 1
BES 2
BES 2
BES 2
BES 3
BES 3
BES 4
BES 4
BES 5
BES 5
BES 6
BES 6
1 関東 3 関西 5 中部 2 東日本 4 西日本 6 海外
FES 1 FES 2 FES 3
障害
BES 3
BES 4
BES 5
BES 6
障害が発生したら?
© Hitachi, Ltd. 2013. All rights reserved.
FES 1 FES 2 FES 3
DBAREA1
1 関東
DBAREA3
3 関西
DBAREA5
5 中部
DBAREA2
2 東日本
DBAREA4
4 西日本
DBAREA6
6 海外
17
DBバッファ DBバッファ DBバッファ
BES 1
BES 1
BES 1
BES 2
BES 2
BES 2
BES 3
BES 3
BES 4
BES 4
BES 5
BES 5
BES 6
BES 6
1 関東 3 関西 5 中部 2 東日本 4 西日本 6 海外
障害
1 関東 2 東日本
BES 1
BES 1
BES 2
BES 2
待機中プロセスが担当データを
成り変わって処理
DBバッファなどのリソースを共有
切り替え完了まで キューイング
□DBバッファの占有もできます
稼動中サーバのリソースを有効活用
□自動でアクセス先を切り替え □不足したプロセスは追加起動
© Hitachi, Ltd. 2013. All rights reserved.
DBサーバ 1 DBサーバ 3 DBサーバ 2
BES1
BES2
BES3
BES4
BES5
BES6
HAモニタ HAモニタ HAモニタ
BES* BES*
BES* BES* BES*
BES*
BES* BES* BES*
BES* BES1 BES2
BES3の 切り替えを指示
どのサーバの 受け入れも可能
18
Active-Activeクラスタの切り替え先制御
※Microsoft Failover ClusterやHP Serviceguardなどと組みあわせるには、HA Toolkit Extensionを使います。
障害
□日立のクラスタソフトウェア HAモニタ※と連携して、 Active-Activeクラスタを開発しました
□切り替え可能なサーバの情報を連携し、担当データの切り替え先を制御
© Hitachi, Ltd. 2013. All rights reserved.
3.Active-Activeクラスタの実力は?
19
© Hitachi, Ltd. 2013. All rights reserved. 20
切り替え時間ってどれくらい?
© Hitachi, Ltd. 2013. All rights reserved. 21
数秒です!
デモでご体感ください。
© Hitachi, Ltd. 2013. All rights reserved. 22
Active-Activeクラスタ デモンストレーション
□ 数秒オーダでの切り替え □ 多重障害への対応
障害
稼働中サーバに負荷分散し、 安定した業務継続
切り替え中でも新規 トランザクションを受付可能
DBサーバ2 DBサーバ3 DBサーバ1
DBサーバ CPU利用率
数秒オーダで 切り替え
全面ダウン 期間ゼロ
2台で稼動
DBサーバ全体スループット
3台で稼動
© Hitachi, Ltd. 2013. All rights reserved. 23
デモンストレーションで 数秒オーダの切り替えの様子を
ご覧ください。
© Hitachi, Ltd. 2013. All rights reserved. 24
HiRDB
HA モニタ
HA Booster Pack
HiRDB
HA モニタ
HA Booster Pack
障害
Alive監視
(a)素早く検知
(c)素早く回復
切替元 切替先
※ HAモニタ、HA Booster Pack : クラスタウェア
DB ログ
HiR
DB
Versio
n 7
□『検知・引継ぎ・回復』の3つのポイントの高速化で、 数秒オーダでの切り替えを実現。
(b)素早く引継ぎ
数秒での切り替えのからくり
HiR
DB
Versio
n 7
※1:障害発生~新規トランザクション受付開始までの時間。※2:トランザクション決着時間はシステムログ量に依存。
▼リソース切り替え ▼回復準備
▼DB回復▼トランザクション決着
数秒オーダ
※2▼障害検知
時間Active-Active
フェイルオーバ時間 ※1
© Hitachi, Ltd. 2013. All rights reserved.
DB ログ
HiRDB
HA モニタ
HA Booster Pack
HiRDB
HA モニタ
HA Booster Pack
Alive監視
切替元 切替先
25
・切替元のマシンダウンを、 切替先からのハートビートで検知。 ・切替先から切替元のマシンをリセット。
HiRDBのスローダウンを、生存監視機能(Time Stampの定期更新/定期参照)により、HAモニタが検知。
HiRDB障害
HiRDBスローダウン
マシンダウン
OSパニック
Time
Stamp
監視
申告
監視
通知
□マシンダウン □OSパニック □HiRDBダウン
クラスタウェア間でのAlive監視による検知 HA Booster Packでの通知による瞬時検知 HiRDB自らの申告によるゼロ秒検知
(a)素早く障害を検知する
© Hitachi, Ltd. 2013. All rights reserved.
DB ログ
DB ログ
DB ログ
DB ログ
26
HA モニタ
HA モニタ
切替元 切替先
HiRDB
HA Booster Pack
HiRDB
・・・
HA Booster Pack
・・・
□共有ディスクの数に依存しない、短時間でのディスク引継ぎ: ①HA Booster PackがHiRDBのI/Oに介在し、 切替元からのアクセスのみを許可。
②障害発生時、アクセス制御の変更のみで引継ぎを実現。
常時オンライン (活性)状態
①I/O介在での アクセス制御
(b)素早くリソースを引き継ぐ
© Hitachi, Ltd. 2013. All rights reserved.
DB ログ
DB ログ
DB ログ
DB ログ
27
HA モニタ
HA モニタ
HiRDB
HA Booster Pack
HiRDB
・・・
HA Booster Pack
・・・
②アクセス制御 の変更(引継ぎ)
共有ディスク数
切 替 時 間
HA Booster Packなし
共有ディスク数
切 替 時 間
HA Booster Packあり
アクセス
拒否
切替先 ディスク
切替元 ディスク
非活性化
一括処理
シーケンシャル処理
活性化
アクセス
許可
活性化
(b)素早くリソースを引き継ぐ
□共有ディスクの数に依存しない、短時間でのディスク引継ぎ: ①HA Booster PackがHiRDBのI/Oに介在し、 切替元からのアクセスのみを許可。
②障害発生時、アクセス制御の変更のみで引継ぎを実現。
切替元 切替先
© Hitachi, Ltd. 2013. All rights reserved.
□高速DB回復&稼動中のリソースの利用で早期サービス再開 - 高速DB回復
- 稼動中のリソースの利用
□Active-ActiveクラスタではDB回復を稼動中サーバに分散して実施
①ディスク毎の並列DB回復 ②新規トランザクションの早期受付開始
③DB処理プロセスの成り代わり
(c)素早くHiRDBを回復させる
切替先
DB回復 (ディスク1)
DB回復 (ディスク2)
時間
DB回復 (ディスク3)
DB回復 (ディスク4)
DB回復 トランザクションの 決着
HAモニタ
HA Booster Pack
②新規トランザクションの 早期受付開始
③DB処理プロセスの 成り代わり
HiRDB
稼働中
DB回復
回復トランザクション 新規トランザクション 稼働中のトランザクション
回復準備
HAモニタ
HA Booster Pack
HiRDB
稼働中 回復準備
DB回復
BES4 BES1
BES6 BES2
BES4
BES1
BES6
BES2
28
時間
切替指示
切替指示
BES5
BES3
BES3
BES5
①ディスク毎の 並列DB回復
稼動中HiRDBへの 切り替え
© Hitachi, Ltd. 2013. All rights reserved. 29
システムのSLAを維持する
□切り換えタイミングで割り当てCPUを活性化し、SLAを維持する
DBサーバ 3 DBサーバ 2
BES1
BES2
BES3
BES4
BES5
BES6
BES1 BES2 障害
CPU
CPU
CPU
CPU
CPU
CPU
CPU CPU
DBサーバ 1
障害サーバの担当データの処理性能を 確保するためにCPUを活性化
© Hitachi, Ltd. 2013. All rights reserved. 30
Shared Nothingなのに、 Active-Activeクラスタ?
□通常運用時、各DBサーバが担当データを独立に処理。
□障害発生時、障害サーバの担当データを稼動中のサーバが引き継ぐ。
□独立しているのに、オンデマンドにシェアするActive-Activeクラスタ。
DBサーバ 1
障害発生時 通常運用時
BES1
DBサーバ 1 DBサーバ 3 DBサーバ 2 DBサーバ 3 DBサーバ 2
BES2
BES3
BES4
BES5
BES6
BES1
BES2
BES3
BES4
BES5
BES6
BES1 BES2 障害
© Hitachi, Ltd. 2013. All rights reserved.
いかがでしたでしょうか?
『Shared Nothingなのに、Active-Activeクラスタ?』
Shared Nothingアーキテクチャでの
Active-Activeクラスタのからくりを
ご紹介しました。
31
© Hitachi, Ltd. 2013. All rights reserved. 32
これからも
Made in Japan DBMS, を
極めていきます。
今後も、日立のデータベースに
ご期待ください。
HiRDB:Highly Scalable Relational DataBase
© Hitachi, Ltd. 2013. All rights reserved.
株式会社 日立製作所 情報・通信システム社 ITプラットフォーム事業本部 開発統括本部 ソフトウェア開発本部 DB設計部
~ 高いスケーラビリティを誇る日立国産DBMS「HiRDB」のクラスタ技術 ~
Shared Nothingなのに、Active-Activeクラスタ?
2013/11/15
脇坂 彰人
END
33
© Hitachi, Ltd. 2013. All rights reserved.
他社所有名称等に関する表示
34
・ 製品の内容・仕様は、改良のために予告なしに変更する場合があります。 ・ Hadoop は,Apache Software Foundationの商標です。 ・ Microsoftは,米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。 ・ HP Serviceguardは,Hewlett-Packard Development Company, L.P.の商品名称です。 ・ 本資料に記載の会社名,製品名は,それぞれの会社の商標もしくは登録商標です。
35
© Hitachi, Ltd. 2013. All rights reserved.
付録
© Hitachi, Ltd. 2013. All rights reserved. 38
関東09
支店番号
~1999
支店番号
2000~2999
支店番号
3000~
<9月>
<関東地区> <関西地区> <その他地区>
関東08 <8月>
関東07 <7月>
DBAREA1 DBAREA2 DBAREA3
DBAREA4 DBAREA5 DBAREA6
DBAREA7 DBAREA8 DBAREA9
日付と支店番号でDBを分割した例
日付 地区 支店 支店番号 売上 ・・・
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
・・
支店売上管理表
第1次元 分割列
第2次元 分割列
関東 集計業務
関西 集計業務
その他 集計業務
関西09
関西08
関西07
他09
他08
他07
時間軸での 分割
空間軸での 分割
一定期間保管
BES 1 BES 2 BES 3
□月単位に支店グループを2次元分割
□独立したBESで並列に処理
© Hitachi, Ltd. 2013. All rights reserved.
DBAREA1 DBAREA2 DBAREA3
DBAREA4 DBAREA5 DBAREA6
DBAREA7 DBAREA8 DBAREA9
39
DB格納領域の簡単なローテーション運用
支店番号
~1999
支店番号
2000~2999
支店番号
3000~
<関東地区> <関西地区> <その他地区>
<9月>
<8月>
<7月>
<10月>
月別 ハッシュ 分割
<7月>
<10月>
DB格納領域の 削除・追加が大変
ローテーション運用を容易にする『月別ハッシュ分割』の利用
<9月>
<8月>
<7月>⇒<10月>
関東09
関東08
関東07
関西09
関西08
関西07
他09
他08
他07
関東10
■従来の運用
□DBの格納領域を、月次で簡単に再利用。
© Hitachi, Ltd. 2013. All rights reserved. 40
今や、ストレージ仮想化技術で対処できる時代
DBAREA1 DBAREA2 DBAREA3
ディスク追加
支店番号
~1999
支店番号
2000~2999
支店番号
3000~
<関東地区> <関西地区> <その他地区>
見積もり、設計が大変
・データ増加を予測した見積もり設計。 ・それに伴う拡張・運用設計の立案。 ・DBエリアのパンク回避のための余裕値設計。
DBAREA1 DBAREA2 DBAREA3
・仮想ディスクに最大サイズでDB エリアを確保でき、DB容量設計 が容易。 ・DBエリアの自動拡張に伴い、 オンデマンドでストレージを割り 当てられる。 ・ストレージプール全体で枯渇 監視でき、監視、拡張運用が容易。
ストレージプール
HDD
仮想Vol(ディスク)
予備 予備
監視、運用が大変
・個々のDBエリアの監視。 ・ディスク追加によるDBエリア拡張。
最大
オンデマンド
ストレージプールを活用した 資源共有により負担を軽減
□DB格納領域の見積もり、運用がどれだけ必要? 大変?
■従来の運用 ■ストレージ機能と連携した シン・プロビジョニングでの運用
© Hitachi, Ltd. 2013. All rights reserved. 41
マスタ表の効率的な共有アクセス
APサーバ
DBサーバ
ストレージ
BES 1
FES 1
特定BESへのアクセス 集中を回避できる
全BESから参照できる 『共用表』属性を利用
・全BESから参照できる表属性。 ・各BESのバッファで独立して参照できる。 ・複数のBESから参照する場合でも、 BES間での通信はおこなわない。 BES 2
FES 2
BES 3
FES 3
DBAREA1 DBAREA2 DBAREA3
DBAREA10
商品マスタ
関東 関西 他
関東 集計業務
関西 集計業務
その他 集計業務
DBバッファ DBバッファ DBバッファ
関東 マスタ
関西 マスタ
その他 マスタ
共用表属性
□マスタ系データの配置は?
© Hitachi, Ltd. 2013. All rights reserved. 42
・共用表の更新要求を全BESに配布。 ・バッファヒットしない場合はストレージから 読み込んでバッファを更新。 ・受け持ちBESだけがストレージ上の データを更新。 ・更新ログは全BESで出力。
更新
APサーバ
DBサーバ
ストレージ
BES 1 BES 2
FES 2
BES 3
FES 3
DBAREA1 DBAREA2 DBAREA3
DBAREA10
商品マスタ
関東 関西 他
関東 集計業務
関西 集計業務
その他 集計業務
DBバッファ DBバッファ DBバッファ
関東 マスタ
関西 マスタ
その他 マスタ
共用表属性
受け持ちBES
FES 1
じゃあ、「共用表」を更新したら、どうする?
DBサーバの独立性を 確保する
□更新要求をFESが受け、全BESに配布。バッファを更新。
□受け持ちBESだけがストレージ上のデータを更新。