DBシステムの高可用性構成概要(Active/Standby) その2
Active / Standby構成の特徴について、もう少し詳しく見ていきましょう。
1.可用性レベル
この構成は、よく”HA(High Availability)構成”と呼ばれます。
直訳すると、”高可用性構成”。
ですから、可用性レベルは高いわけですね。
ただ最高レベル、とまではいきません。
この構成の最大の特徴は、メインのマシンが Active、待機しているマシンが Standbyとなっている点です。
つまり、メインマシン → 待機マシンへの切替に若干の時間がかかってしまうというデメリットがあります。
ざっくりと切替には以下の手順が必要となります。
1) メインマシンより共有DISK領域を切り離す
2) メインマシンの停止
3) 待機マシンの起動(起動だけしてるケースも多いですが)
4) 共有DISK領域の認識(mountやvarryon等)
5) 待機マシンのDBソフトウェアの起動
これにどれぐらいかかるか、は一概には言えませんが、30分程度は見ておくのが一般的(※)です。
この30分、を許容できるかどうかが、この構成を採用するかどうかの1つの条件になってきます。
※
最新のハードウェア構成であれば、数十秒単位レベルで切替が出来るそうですが、僕はまだそれを”目の当たり”にしたことはありません
2.費用
次にこの構成を組むために必要となる費用を考えてみましょう。
単純に考えてみると良いかと思いますが、この構成ではハードウェアが2台になっており、普通の倍必要となります。ハードウェア同様、そのハードウェアの上で動作するソフトウェア(例えばORACLEとか、DB2とか)も当然、倍必要です。
ただハードウェア購入費用は単純に倍になりますが、ソフトウェア購入費用は倍とならないケースがあります。
これは2台のうち、常に1台しかソフトウェアは稼動していないからです。
ハードウェアとしては物理的に2台分納入する必要があるため、費用も倍ですが、ソフトウェアは同時使用する単位で費用がかかるものも多く、そのようなソフトウェアであればこの構成でも費用は倍必要ではありません。
一方、共有DISK領域は、巨大なハードディスクみたいなもので、これは1つで問題ありません。高速コピー機能や遠隔地コピー機能を使ってない限りは。
よってハードウェア分やその周辺(回線や設置等々)、及び一部のソフトウェア分の費用が通常よりも余分にかかってしまうことになります。
3.切替設定について
可用性レベルのところとも関連しますが、この構成をとる以上、必ず”切替”を予め意識しておく必要があります。
簡略化すると、以下の2点は最低でも意識しておいた方が良いでしょう。
1) 切替のタイミング
何があったら、どういう状況だったら、誰がどうやって切替をするのか。
これを決めておく必要があります。
例えばあるアプリケーションを監視しておき、それが止まれば切り替える。切替はクラスタウェアを使って自動で行い、人の手で切替は行わない、といったようなルールが必要というわけです。
このルールは僕が知る限りでは、お客様によってバラバラですが、1つだけ認識しておいた方が良い点は、
切替処理は自動化しても良いが、切り替えるべきかどうかの判断の完全な自動化は難しい
というところです。
切替処理は約30分かかるため、一刻も早く切替るためにも自動化しておきたいところではあるのですが、そもそも何の問題で切替をしなければならないのかが明らかになっていないと、切替てももしかしたら待機マシンで処理が継続できない可能性だって有り得るわけです。
賢明な運用管理者の方々はこの点をよく理解されており、切替は自分達で判断して実施するというケースが多いですが、賢明ではない運用管理者の方々はこの点を理解しておらず、完全自動化を望まれるケースが多い気がします。
2) 切替後の設定
切替をしました。でもDBシステムとしては稼動していないのですが、なぜですか?
という質問を何度か頂いたことがあります。
信じられないことではありますが、こういった質問をしてくる方々はこの構成の趣旨を理解されておらず、切替た後に何をすべきかがわからず、切替テストも実施されていないケースが多いのです。
この点は書き出すとキリがないので、またいつか書きたいと思いますが、とりあえず最低でも以下は意識しておく必要があるでしょう。
・IPアドレス(物理、仮想)
・ホスト名
・他システムとの連携
切替た後に上記項目について、どうしておくかは必ず考えておきましょう。
■可用性まとめ
可用性とは
DBシステムで可用性が低い理由
可用性と予算の関係性
DBシステムの高可用性構成概要(Active/Standby) その1
DBシステムの高可用性構成概要(Active/Standby) その2
DBシステムの高可用性構成概要(Active/Active) その1
DBシステムの高可用性構成概要(Active/Active) その2
DBシステムの高可用性構成概要(Active/Standby) その1
DBシステムの高可用性構成についてはいくつかの構成があります。
一般の方でもわかりやすくいえば、高可用性を維持するためには1箇所、1部分が壊れても、残りの箇所でシステムを稼動させる必要があります。
ここで想像してみてください。
DBシステムを構成するDBサーバというものがあります。
(まぁ1台のちょっと高性能なパソコンだと思ってください)
このDBサーバがブッ壊れてしまうと、システムが停止してしまうわけです。
そこでこう考えた人がいました。
それだったら、もう1台同じマシンを用意しておけば良いのでは?と。
つまり1台を本番系として稼動させておき、万が一本番系のマシンに何らかの障害が発生した場合は、もう1台用意しているマシンを使えばいいじゃないか、と。
確かにそうなんですが、DBサーバはそんなに単純ではありません。
例えば、本番系マシンをAさん、もう1台の待機系マシンをBさんとします。
Aさんがブッ倒れたら、Bさんが起動して処理を継続していくわけですが、ここで1つ問題が発生します。
Aさんが抱えていたデータが見れないことには、Bさんは何も出来ない。
つまりAさんがブッ倒れる直前まで保持しているデータは、Aさんがブッ倒れた後にBさんが見れる状況にある必要性があるわけです。
そのため、Aさんに全てのデータを保持させるのではなく、AさんもBさんもアクセスすることが出来る場所にデータを保持しておくアーキテクチャが採用されました。このAさんもBさんも見れるデータ領域を、共有DISK領域と一般的に呼ばれます。
アクティブ機がAさん、スタンバイ機がBさん、真ん中下の筒の部分が共有DISK領域です。
まぁかなり大雑把にいえば、巨大なUSBメモリスティックみたいなものです(無茶苦茶なたとえですが・・・)。
Aさんがダウンすれば、その時点でBさんが共有DISK領域を見れる状態にし(マウントとか言います)、DBとして稼動するわけです。
この構成だと、Aさんがブッ倒れたらBさんが起き上がってくれるので、可用性としてはそれなりに高いといえるわけです。
こういう構成をこの業界では、
・HA構成(High Availablity構成)
・Active / Standby構成
とか言ったりします。
ちなみにこの構成のメリット、デメリットは何でしょう?
それはまとめると以下のような感じになります。
(メリット)
・可用性が高い
・ライセンス費が浮く
(デメリット)
・可用性が高いけど、切替に時間がかかる
・ハードウェアが2台分必要で費用がかかる
といったところでしょうか。
この詳細はまた次回に !
■可用性まとめ
可用性とは
DBシステムで可用性が低い理由
可用性と予算の関係性
DBシステムの高可用性構成概要(Active/Standby) その1
DBシステムの高可用性構成概要(Active/Standby) その2
DBシステムの高可用性構成概要(Active/Active) その1
DBシステムの高可用性構成概要(Active/Active) その2
可用性と予算の関係性
今回は、可用性と予算の関係についてまとめてみたいと思います。
企業が何かに投資をする場合、ざっくりと
・投資により将来に渡り生み出す収益
を予め考慮し、投資額を決定するのが一般的には常識ですよね。
例えば工場を建設する場合は、その工場で生産された製品がいくらで売れて、それによってどの程度の収益を得られるか、コンビニのオーナーになるなら開店する事でどの程度の収益を得られるか、株を買ったらどの程度の収益を得られるか、を普通は予想しますよね。
もちろん全ての投資がこうあるべきとは思いませんが、何かに投資をする場合は、通常「期待される収益」を予測するはずです。
ではIT業界、とりわけDB周辺を含むシステムへの投資をする場合はどうでしょうか?
僕が知る限り、ASP事業やECサイトといった直接商品やお金のやりとりが行われるシステムや、厳密な工場系生産ラインシステム、停止することが全く許されないシステム以外では、収益の予測やそのシステムの価値を綿密に計算してるケースはほとんどありません。
買う側(システムを発注する人)はコスト意識と上から下りてきた予算を強く意識するだけですし、売る側(システムを構築する側の人)の営業マンは技術的優位性と低価格を語るだけです。
もしかしたら、
システム構築 = 投資
という等式を意識してる人が少ないのかもしれません。
確かに収益予測が難しいようなシステムが多いのは事実です。社内のイントラネットの価値や人事情報を管理するシステムは、直接的に収益を生むものではありませんから、将来の収益を予測することも困難です。
実は可用性が低いシステムが多いという点の根本的な原因はここにあるのです。
構築しようとしているシステムの価値を正確に予測、判断ができないために、どの程度の額をシステムに投資すべきかが曖昧になってしまうのです。
曖昧な予算の中で、可用性を最大化する施策を採用するわけです。
本当は24時間365日停止をさせてはいけないシステムであったとしても、予算上どうしようもないために諦めざるを得なかったり、表面的には24時間365日稼動が出来るものの、実際には長期運用には耐えれないままシステムをリリースしたりしてしまうことがたくさん起きているのです。
可用性を高めるためには、ハードウェアやソフトウェアへの投資が欠かせませんし、それらを構築する人たちも有能な方々でしょうからそれなりの費用がかかります。
適切な収益予測、システム価値の認識が出来ていない事が多いため、曖昧な予算で可用性を高めていかねばなりません。
しかも、仮にシステム投資額が相当大きくても、可用性とシステム構築費用の関係は以下のように、可用性が逓減していく形となってしまいます。これは後日説明していきますが、いくらお金をかけても100%の可用性を得ることはできないからです。
つまり、限られた曖昧な予算内で如何にして可用性を最大化するか、
これが現在のDBシステムにおける最大の命題なのではないでしょうか。
(注釈)
ITシステム投資といった言葉が一昔前に流行り、そこでシステムが持つ価値を適切に定めるといった流れがありました。一部企業を除いて、結局価値判断が困難なことが多いためか、最近あまり聞かなくなりましたね・・・
■可用性まとめ
可用性とは
DBシステムで可用性が低い理由
可用性と予算の関係性
DBシステムの高可用性構成概要(Active/Standby) その1
DBシステムの高可用性構成概要(Active/Standby) その2
DBシステムの高可用性構成概要(Active/Active) その1
DBシステムの高可用性構成概要(Active/Active) その2

