PostgreSQL9.1でつくる高可用性にまつわるエトセトラ

Copyright © 2012 NTT DATA Corporation
２０１２年１１月３０日
株式会社ＮＴＴデータ基盤システム事業本部
海浦隆一
PostgreSQL 9.1 でつくる
高可用システムにまつわるエトセトラ

2Copyright © 2012 NTT DATA Corporation
本日お話しすること
 ＮＴＴデータでのＯＳＳの取り組み
 ＰｏｓｔｇｒｅＳＱＬ９．１の商用システム適用
 商用システム適用時の勘所
 高可用性を実現したＤＢアプライアンス

Copyright © 2012 NTT DATA Corporation 3
ＮＴＴデータでのＯＳＳの取り組み

ＮＴＴデータとＯＳＳ
ＯＳＳは既にステージへ！
フルＯＳＳモデルのスタック
- ＰＲＯＲＩＺＥフルＯＳＳモデル -
ＯＳＳの統合管理ツール
- Ｈｉｎｅｍｏｓ -
ＯＳＳで新たなの領域へ！
分散処理フレームワーク
- Ｈａｄｏｏｐ -
ＯＳＳでをカバーする！
ＯＳＳ-ＤＢＭＳ
- ＰｏｓｔｇｒｅＳＱＬ -
ＯＳＳを組み合わせてを構築する！
フルオープン仮想化基盤構築ソリューション
- ＯｐｅｎＳｔａｃｋ + ＯｐｅｎＦｌｏｗ -

基盤構築ソリューション
ＰＲＯＲＩＺＥ（プロライズ）
Web3層
モデル
SOA
モデル
PRORIZE 検証済システム基盤構成
フルOSS Webモデル
Webモデル（IAサーバ）
Webモデル（UNIXサーバ）
SOA基盤モデル（BPM）
SOA基盤モデル（ESB）
SOA基盤モデル（ハードウェアESB）
スタックモデルの中でも、ＯＳＳモデルは最も採用数が多い。
様々なサービス基盤でＯＳＳモデルが稼動中！
検証済システム基盤構成＋設計済開発テンプレート
IAも。UNIXも。OSSも。
SOAも。仮想化も。

Ｈｉｎｅｍｏｓでシステム監視とジョブ管理
オープンソースの統合管理システム
パートナービジネスの展開
監視からジョブまで統合管理できる唯一のＯＳＳ
仮想環境/クラウド環境にも対応
先進的な機能
商用製品の代替ではない、Ｈｉｎｅｍｏｓ/ＯＳＳらしさで多くの
パートナーと付加価値を伴いシステムの重要部を担う！

お客様規模など
経済産業省様 100台
リクルート様 120台規模
国立図書館様 40台規模
国立研究機関様 70台規模
日本最大級のＨａｄｏｏｐクラスタ(※当社調べ)の構築・運用
従来では予想もつかなかった領域のサービスをＯＳＳで実現！
1000台超の規模
加速するＨａｄｏｏｐ
＋
急激に増加する様々な分野からのニーズ
社と戦略的な協業
Ｈａｄｏｏｐディストリビューション「ＣＤＨ」のサブスクリプション販売
より高度なサービスを提供できる体制を実現
ビッグデータ分野を切り拓くＨａｄｏｏｐ

ＯｐｅｎＳｔａｃｋやＯｐｅｎＦｌｏｗなどのオープンな技術を活用し、
災害に強く、省電力で運用できる仮想化基盤を構築！
統合マネージメント
リーンスタートアップ
ディザスタリカバリ
環境の配慮
電気代の高騰
運用管理の問題
急速なビジネス変化
無駄のない投資
予期せぬ災害
大規模障害
アイドリングストップ
課題ソリューション
ITpro EXPO2012 AWARD
優秀賞受賞！！
フルオープン仮想化基盤構築ソリューション

ＤＢ規模
処
理
性
能
（万
件
／
時
）
5
40
10
20
10GB 100GB 1TB
60
10TB
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
ＰｏｓｔｇｒｅＳＱＬで
サービス中
ＰｏｓｔｇｒｅＳＱＬの次のターゲット
100TB 1PB
80
■
■
■
■
■
■
■
●ＰｏｓｔｇｒｅＳＱＬ
■商用ＤＢ
クラウド移行
●
出典:当社社内システム及び当社にてご提供中の商用システムをＤＢ規模と処理性能で整理
ＰｏｓｔｇｒｅＳＱＬで
準ＭＣ/ＭＣ領域を目指す！
ＭＣ領域をカバーするＰｏｓｔｇｒｅＳＱＬ

サポート体制
•長期にわたるＰｏｓｔｇｒｅＳＱＬ等のＯＳＳサポート
•さまざまな場面（検証・設計から運用トラブルまで)の手厚いサポート
技術開発/検証
•ＭＣ要件を満たす機能、ノウハウ蓄積
•信頼性（ノンストップ・データロスなし）・運用性（導入・運用・解析の容易さ)
技術者育成
•ＯＳＳを扱えるだけでなく、中身を知ってサポート/コア開発ができる
•緻密なサポートと自社ニーズを満たす機能の実現
課題となる３つの柱
ＰｏｓｔｇｒｅＳＱＬのＭＣ適用に向けて

ＰｏｓｔｇｒｅＳＱＬ９．１の商用システム適用

高可用ＤＢサーバの商用システム適用
クラスタ
Ｍａｓｔｅｒ
同期レプリケーション
Ｂａｃｋｕｐ
Ｓｌａｖｅ
ＰｏｓｔｇｒｅＳＱＬ：９．１
Ｐａｃｅｍａｋｅｒ：１．４
Ｃｏｒｏｓｙｎｃ：１．０
 ＮＴＴデータでは、同期レプリケーションを利用した高可用ＤＢ
サーバを提供し、商用システムに適用しています。
この組み合わせの商用
システムへの適用は、
（少なくとも当社としては）
初の試み！
構想構築事前検証検証
２０１１年春２０１１年夏２０１１年夏～秋２０１１年冬～２０１２年春
９．１Ｂｅｔａで
構築・検証開始
９．１
Ｒｅｌｅａｓｅ！
適用までの取り組み

物件管理
情報システム
物件情報参照
現地調整結果入力
営業担当者
商用システム概要
システム概要と目的利用状況
• 地図上で物件管理情報の表示・
編集を行う
• 効率的なマーケティングを支援
• ユーザ数：数万人
• データ容量：5～10TB
• 運転時間帯：5時～24時
サービス概要図
運用者
お客様システム
管理物件
用地管理物件管理設備管理
現地調整の
結果整理
物件管理DB
決裁者
連携
地図上に
物件管理情報を
プロットできる
訪問履歴や競合情報が
地図情報と併せて
管理できる

ＤＢサーバの構成
 ＤＢサーバは、物理マシン２台で共有ディスクレスの構成です。
同期レプリケーションによりそれぞれのマシンのローカルディス
クにデータを保持します。
Ｍａｓｔｅｒ（主系）Ｓｌａｖｅ（副系）
故障
発生
Ｍａｓｔｅｒ（主系）
フェイル
オーバー
レプリケーション
旧Ｍａｓｔｅｒを切り離し、
サービス継続
ＤａｔａＤａｔａＤａｔａＤａｔａ
ＨＡクラスタソフト
で管理

ＨＡクラスタとは？
 ＨＡ（ＨｉｇｈＡｖａｉｌａｂｉｌｉｔｙ）クラスタとは、
コンピュータシステムの可用性（Ａｖａｉｌａｂｉｌｉｔｙ）を高めることを
目的とした、複数台のコンピュータによる連携構成（クラスタ）
のことを指します。
• ＨＡクラスタの管理を行うソフトウェアを、ＨＡクラスタソフトとします。
ＨＡクラスタソフトの代表例をいくつか列挙します。
ＨＡクラスタソフト分類
ＣｌｕｓｔｅｒＰｒｏ商用
ＬｉｆｅＫｅｅｐｅｒ商用
ＰＲＩＭＥＣＬＵＳＴＥＲ商用
ＨｅａｒｔＢｅａｔＯＳＳ
ＰａｃｅｍａｋｅｒＯＳＳ
採用

なぜＨＡクラスタソフトが必要？
 ＰｏｓｔｇｒｅＳＱＬには、フェイルオーバーを自動的に行う機能
がありません。故障発生を検知して、各種処理を実施する
ＨＡクラスタソフトと組み合わせる必要があります。
ＰｏｓｔｇｒｅＳＱＬ単体だと・・・ＰｏｓｔｇｒｅＳＱＬとＰａｃｅｍａｋｅｒを
組み合わせると・・・
リソース
ＨＡクラスタ
ＯＫ
リソースエージェントリソースエージェント
状態確認
リソース
ＨＡクラスタ
ＰｏｓｔｇｒｅＳＱＬＰｏｓｔｇｒｅＳＱＬ
何をしたらよいか
わからない
切断された？
Ｍａｓｔｅｒから切断されたことは検知する
が、そのまま待機する。
互いに状態を確認し、問題が発生したら
定義された適切な処理を行う。
状態
確認
ＯＫ

商用システム適用時の勘所

商用システム適用にあたっての５箇条
 ＰｏｓｔｇｒｅＳＱＬ９．１の高可用商用システム適用にあたり、
特に意識しておくとよい点は、下記の５つです。
検証は大事
サイジングは柔軟に
－構成の決定は重要。柔軟な対応も必要－
商用システムは運用が要
－切り替えは１００％成功かつ即座の切り替えー
備えあれば憂いなし
監視で安心

５箇条その１：検証は大事
 検証および試験時に、全てのエラー項目、運用ミスなどは
だしきり、運用を整理しましょう。
たとえば、今回実施したＨＡクラスタ（信頼性）の検証項目抽出の条件・・・
１正常系試験想定している運用操作を抽出し、各操作が正常に実行できることを確認する。
２異常系試験
ハードウェア構成とリソース構成を考慮し、発生しうる故障種別を網羅した
単一故障試験項目と、その組み合わせによる多重故障試験項目を抽出する。
例：現用系サービスＬＡＮ故障 × レプリケーションＬＡＮ現用・予備系が同時故障
３長期安定試験
Ｐａｃｅｍａｋｅｒサービス起動後、ＤＢに対し背景負荷をかけた状態で、一定時間
連続走行させる。走行中に各サービスが停止しないこと、メモリリークが発生して
いないことを確認する。
４切替性能試験
ピーク負荷時だけでなく、ＤＢ（ＰｏｓｔｇｒｅＳＱＬ）で実施されるＶＡＣＵＵＭをはじめと
するメンテナンスやバックアップ中に切り替えが発生した場合の時間も調査する。
また想定故障箇所については、その仕組み上、最も切替が遅くなるものを重点的に
調査し、最悪のシナリオでどれくらいの切替時間となるかを見定める。

検証中に発生した問題
 案の定たくさんの課題・問題に直面しました。
９．１未対応のモジュール利用時に、コンパイルが通らない？
ＲＡどうしましょう？
切り戻し手順がよくわからない？
クラスタ組んだけど切り替わらない？
スプリットブレイン発生？
．．．ｅｔｃ

Node Attributes:
* Node db02:
+ master-postgresql:1 : 1000
+ pgsql-data-status : LATEST
+ pgsql-status : PRI
発生事象
検証中に発生した問題：切り戻し失敗
 フェイルオーバーが起こったあとクラスタの再構成（切り戻し）
をしようと思ったけど、うまくできない。
Ｍａｓｔｅｒ
フェイル
オーバー
旧Ｍａｓｔｅｒ
レプリケーション構成となっている状態で、
フェイルオーバーが発生。
正常に切り替わり、Ｍａｓｔｅｒとして起動
Ｍａｓｔｅｒ旧Ｍａｓｔｅｒ
旧Ｍａｓｔｅｒをクラスタに再度組み込
み、レプリケーション構成を構築しよう
としたが、Ｓｌａｖｅとして動作しない！
Ｐｒｏｍｏｔｅ
Ｓｌａｖｅ
Pacemaker 起動
Pacemaker
status

原因①
Ｍａｓｔｅｒ旧Ｍａｓｔｅｒ
Ｓｌａｖｅ
Node Attributes:
* Node db01:
+ master-postgresql:0 : -INFINITY
+ pgsql-data-status : DISCONNECT
+ pgsql-status : STOP
* Node db02:
Pacemaker
status
・プロセスが起動していない。
・ｐｉｄファイルが存在しない。
$PGDATA/postmaster.pid
ＰｏｓｔｇｒｅＳＱＬが起動していない。ＰＧＳＱＬ．lｏｃｋファイルを削除する。
ＰＧＳＱＬ．ｌｏｃｋファイルが存在している
ため、ＰｏｓｔｇｒｅＳＱＬは起動に失敗。
対処①
Postgre
SQL pid
ＰｏｓｔｇｒｅＳＱＬ起動！
でもレプリケーションができていない。。。
Pacemaker 起動
作成者
作成
削除
：ＰａｃｅｍａｋｅｒのＰｏｓｔｇｒｅＳＱＬＲＡ
：Ｍａｓｔｅｒが起動したとき
：正しい手順でＭａｓｔｅｒが停止されたとき
※ Ｓｌａｖｅのマシンが存在しない状態で、
Ｍａｓｔｅｒが停止したとき
PGSQL.lock ファイル
・・・Ｍａｓｔｅｒ、Ｓｌａｖｅのサーバ間で、データ不整合を
避けるために作成。本ファイルが存在すると、
ＰｏｓｔｇｒｅＳＱＬは起動できない。

レプリケーションが始まっていない。
Node Attributes:
* Node db01:
+ master-postgresql:0 : -INFINITY
+ pgsql-data-status : DISCONNECT
+ pgsql-status : HS:alone
* Node db02:
原因②
ＭａｓｔｅｒＳｌａｖｅ
対処②
タイムラインＩＤを合わせるために、再組
込みの前にデータを手動で同期させる。
Pacemaker
status
変更者
変更
：ＰｏｓｔｇｒｅＳＱＬ
：Ｍａｓｔｅｒが起動したとき。
※ ＰａｃｅｍａｋｅｒのＲＡは、マシンをいったん
【Ｓｌａｖｅ】として起動する。（※1）
その後、【Ｍａｓｔｅｒ】に昇格（promote）する。
タイムラインＩＤ
・・・Ｍａｓｔｅｒ／Ｓｌａｖｅのデータ整合性チェックに利用する。
ＳｌａｖｅがＭａｓｔｅｒと一致していなければ、データの
整合性に問題がある可能性があるため、レプリケー
ションは開始されない。
（※1）挙動の詳細については本講演では割愛します。
本日後半の講演やＬｉｎｕｘ-ＨＡの公開資料などを参照してください。
同期レプリケーション再開！タイムラインＩＤの不一致が発生している
ため、レプリケーションが開始できない。

５箇条その２：サイジングは柔軟に
 適切なサイジングを行うことは、システムの安定運用に繋がり
ます。技術的に理想である構成はありますが、実現可能な案
に柔軟に対応することも必要です。
たとえば、スイッチ設置数、ポート数を考慮したネットワーク設計・・・
業務
ＬＡＮ
運用
ＬＡＮ
レプリ
ケーション
ＬＡＮ
インター
コネクト
ＬＡＮ
業務
ＬＡＮ
運用
ＬＡＮ
インター
コネクト
ＬＡＮ
レプリ
ケーション
ＬＡＮ
理想現実それぞれｂｏｎｄｉｎｇして
４つのネットワークを構築
それぞれｂｏｎｄｉｎｇはするけれど
環境都合でネットワークは３つに

５箇条その３：商用システムは運用が要
 商用システムでは運用が重要です。
いかに効率良く運用し、問題を発生させない、または発生し
た問題を早急に収束させることがポイントです。
たとえば、切替時間短縮を目的とした同期レプリケーション構成・・・
故障
検知
クラスタ
制御
チェック
ポイント
切替
完了
PG
Promote
FS/VIP
起動
sfex
起動
クラスタ
制御
故障
検知
PG
起動
REDO
チェック
ポイント
切替
完了
約６０％短縮！
切替時間
切替時間
同期
Active
Standby
（共有ディスク）
※当社検証環境において、もっとも時間がかかると想定される電源故障時の切替時間を計測

５箇条その４：備えあれば憂いなし
 トラブルが発生しないように準備しておくことは当然です。
トラブルが発生した場合の対処も検討しておくことが重要です。
たとえば、故障発生時のログ収集を効率よく行うためのしくみ・・・
report
コマンドで一つで必要なログを全て取得
できる sosreport を利用します。
スクリプト化など一括で取得するしくみを
準備しておくことで、利便性の向上と取得
時間の短縮を図ります。
デフォルトでは取得できないＰｏｓｔｇｒｅＳＱＬ
の稼働情報、ログ等々の取得もできるよう、
機能追加しました。
boot
loader
general hard
ware
kernel
netwo
rking
system
tap
rpm
process
memory
Postgre
SQL
system

５箇条その５：監視で安心
 ハードウェアの状態やプロセスのリアルタイム監視を行います。
加えて、過去の性能情報等も記録し、プロアクティブな対策
の検討ができるようにしておくとさらに安心です。
たとえば、アクセス情報を記録してピーク時の対応を検討・・・
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
図：例（とある１日のアクセス数）
プロモーションを
午後に実施通常繁忙日の
ピーク時
プロモーションなど、特定のイベント後の
局所的なアクセス増加と成長率を考慮
して、スケールアウトの検討を行います。
システム要件（最大値）に到達する時期
の再計算ができ、システムライフサイクル
の見直し等を行います。

おわりに

商用システムへの適用にあたって
異常時の運用フローの整理・検討は徹底的に
⇒ 商用システムの肝はやはり運用！
Ｐａｃｅｍａｋｅｒの商用システム適用は積極的に
⇒ サービス開始後、異常な挙動は０！
同期レプリケーションは切替時間短縮の選択肢として有効
⇒ 性能への影響もありますので、考慮が必要です
タイムラインＩＤの扱いについては、今後に期待
⇒ 柔軟な運用、クラスタ再組込み時間の短縮できませんか
ＪＰＵＧ、コミュニティからの情報が頼り（何か見つけたらすぐ連絡します）
⇒ ＰｏｓｔｇｒｅＳＱＬマニュアルの誤りを修正し、投稿しました
 ＰｏｓｔｇｒｅＳＱＬ９．１を商用システムに適用し、
安定運用の実績を作りました。

高可用性を実現したＤＢアプライアンス

高可用性システム構築の敷居：高
 高可用な商用システム構築の５箇条は大事です。しかし、
全てを充分に実施する場合は、システム構築に対する
敷居が高くなってしまいます。
検証は大事
サイジングは柔軟に
商用システムは運用が要
備えあれば憂いなし
監視で安心
検証マシンの調達、検証項目作成、検証実施．．．
案件適性やＳＬＡの確認、諸元からのサイジング．．．
運用手順の整理、運用手順書の作成．．．
都度スクリプトの作りこみ、情報取得範囲の検討．．．
監視パラメータの調査、設定、検証．．．

高可用性システム構築の敷居：高
 有識者がしっかり手順を踏むことで、ＨＡ構成の高可用ＤＢ
サーバ（ＰｏｓｔｇｒｅＳＱＬ）の構築・運用はできます。
その分、多くのコストと時間が必要です。
Ｍａｓｔｅｒ
Ｂａｃｋｕｐ
Ｓｌａｖｅ
バックアップ設計
切り替え・監視
時間の設定
クラスタ再構成の
手順
運用・サポート構築コスト問題
今回の事例システムの構築（ＤＢ）に必要なタスクの一部

そこで
はじめました
高可用性を実現したＤＢアプライアンス

ＧｒｅｓＣｕｂｅのいま
 高可用なシステムを、すぐにご利用でき、簡単な操作での
運用が可能でかつ安心のサポート込み。さらに低価格で
ご提供します。
Ｍａｓｔｅｒ
Ｂａｃｋｕｐ
Ｓｌａｖｅ
バックアップ設計
切り替え・監視
時間の設定
クラスタ再構成の
手順
運用・サポート構築コスト問題
今回の事例システムの構築（ＤＢ）に必要なタスクは当然、実施済でご提供

ＧｒｅｓＣｕｂｅのこのさき
 最新バージョンのＰｏｓｔｇｒｅＳＱＬを利用することにより、
高性能化、高機能化を検討しています。最近ご要望を多く
いただいている、ディザスタリカバリ機能もご提供いたします。
Ｍａｓｔｅｒ
Ｂａｃｋｕｐ
Ｓｌａｖｅ
Ｓｌａｖｅ／ＤＲ
カスケード
性能ＵＰ！
スタンバイ
バックアップ
ｂｏｏｔｈ
ｔｉｃｋｅｔ
最新をｗａｔｃｈして、最適な機能を採用！

まとめ
 ＧｒｅｓＣｕｂｅとは・・・
次の領域へどんどん拡大していく
ＧｒｅｓＣｕｂｅの今後にご注目ください
新機能開発を継続して実施します

記載されている会社名、商品名、またはサービス名は、各社の商標または登録商標です。
本資料には、当社の秘密情報が含まれております。当社の許可なく第三者へ開示することはご遠慮ください。

PostgreSQL9.1でつくる高可用性にまつわるエトセトラ

More Related Content

What's hot

Viewers also liked

Similar to PostgreSQL9.1でつくる高可用性にまつわるエトセトラ

More from NTT DATA OSS Professional Services

Recently uploaded

PostgreSQL9.1でつくる高可用性にまつわるエトセトラ