• Like
[D34] Shared Nothingなのに、Active-Activeクラスタ? ~ 高いスケーラビリティを誇る日立国産DBMS「HiRDB」のクラスタ技術 ~ by Akito Wakisaka
Upcoming SlideShare
Loading in...5
×

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

  • 1,461 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,461
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
11
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

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