Q&A
回答ありがとうございます。
SANアレイディスクについての記述大変参考になりました。
SANアレイディスクの話でコントローラの話がありましたが、コントローラはどのノードで動作しているのでしょうか？
別のノード（DBサーバではない管理用のPCなど）で動作しているのでしょうか。
「この方式の利点は、データベース自身に高可用性の機能がない場合でも、外部のミドルウエアで高可用性の機能を持たせることができることです。」
これが未だによくわかりません。
元記事は一体何を意図しているのでしょうか？
高可用性クラスターの一つの実装である「共有ディスクを利用したコールド・スタンバイ型」について質問です。
https://thinkit.co.jp/story/2010/10/05/1784?page=0%2C1
こちらのサイトを参考にしています。
コールド・スタンバイ型では、一つの共有ディスクがあって、現用サーバと予備サーバがあります。
そして、現用サーバがダウンした時に予備サーバが肩代わりをするというシステムです。
そして、以下のような記述があります。
「この方式の利点は、データベース自身に高可用性の機能がない場合でも、外部のミドルウエアで高可用性の機能を持たせることができることです。」
同じサイトにそもそもクラスターシステムはデータベースの提供する機能のうち、一つのサーバだけでは実現が難しい3つの代表的な機能（高可用性、並列処理、性能向上）を実現させるために、サーバを複数導入し、協同的に動作させることで、実現するというものだと書いているのですが、データベース自身に高可用性がない場合などあるのでしょうか？
例えば、RAID10構成などにすると、データベース自体は高可用性になると思います。
逆に、例えばRAID0などにすると、可用性が低いということになります。
そして、データベースのストレージにRAID0を導入して（データベース自体に高可用性の機能がない場合）、コールド・スタンバイ型にすると、高可用性の機能を持たせることができるとは思えないのです。
APサーバの方は複数あるので、高可用性だと思うのですが、データベースがSPOFになってしまい、結局は可用性が低いと思うのですが、どうなのでしょうか？
また、同じサイトにコールド・スタンバイ型のデメリットについて以下のような記述があります。
「デメリットは、データベース・サーバーのクラッシュを検出することや、共有ディスクの修復に、時間がかかってしまうことです。」
サーバのクラッシュがどのように検出されるかはわからないのですが、DBのクラッシュの検出はDBマネージャーがI/Oが成功したかどうかを監視していて、それが失敗した時（より正確にはある閾値を超えた時）、ディスクが壊れたと判断すると思います。それを考えると、データベースのクラッシュの検出というのはクラスターシステムがどうかというのは関係ないと思うのです。
同様に共用ディスクの修復もデータベースのストレージの話であって、クラスターシステムが関与しない木がするのですが、どうでしょうか？
以上、2点になりますが、よろしくおねがいします。
回答3件
0
「この方式の利点は、データベース自身に高可用性の機能がない場合でも、外部のミドルウエアで高可用性の機能を持たせることができることです。」
ここで言うデータベースの可用性はDMBSとして、サーバの冗長化により可用性を確保する機能のことを言っていると思います。例えば、マスタからスレーブにデータを複製する機能があれば、DBMS自身に高可用性の機能があるといえると思いますが、ちょっと昔のオープンソース製品では、そういう機能が無いものもありました。
最近では、オープンソース製品でもレプリケーション機能を持ってたりしますが、それなりに構築や運用も難しくなるので、コールドスタンバイでの可用性確保は、選択肢の一つになると思います。
APサーバの方は複数あるので、高可用性だと思うのですが、データベースがSPOFになってしまい、結局は可用性が低いと思うのですが、どうなのでしょうか？
もちろん、ストレージの可用性が高くないと、可用性を確保できません。bill さんの理解であっています。
ただし、一般的には、ストレージサーバと呼ばれるものは最低でも RAID5 ですし、EMC や NetApp などでは高度な仕組みで RAID 以上の可用性を確保していますので、単純にストレージサーバが SPOF であるとは言えないと思います。まあ、RAID の場合は、HDD単体の故障には耐えれますが、サーバ本体の故障には耐えられないので、やはり SPOF は残っているとは思います。このため、DRBD などのミラーディスクを使う場合もあります。
「デメリットは、データベース・サーバーのクラッシュを検出することや、共有ディスクの修復に、時間がかかってしまうことです。」
これは、論理的にというよりも、経験則的なものではないでしょうか。NASにしろ、SANにしろDBMSとストレージの間のプロトコルでは、障害の検出がむずかしかったり、排他制御が難しかったりします。NFSでは、ファイルにロックがかかったまま開放されないなどの理由でうまくフェールオーバできない場合もあります。また、処理途中のコミットがファイルに悪影響を与えて、データベースファイルが壊れてしまい、修復コマンドを実行しないと復旧できない場合などもあります（本来はトランザクションログを取っているので、自動的に短時間で修復できるべきなのですが、ネットワーク経由アクセスでハードウェア障害も発生している状況では難しいでしょう）。
DBMSのように、上位層で制御していれば、トランザクション単位で切り分けられるので、フェールオーバはそれほど難しくないでしょう。ということだと思います。
投稿2016/10/07 09:12
総合スコア3401
0
ベストアンサー
APサーバの方は複数あるので、高可用性だと思うのですが、データベースがSPOFになってしまい、結局は可用性が低いと思うのですが、どうなのでしょうか？
共有ディスク装置がSPOFになるかといえば、YESです。しかし、業務で共有ディスク装置として一般的に使われるSANディスクアレイと言われる製品は次のように部品レベルで可用性を確保しています。
- RAID10やRAID6など可用性が高いディスク構成が可能。ホットスペアやホットスワップもサポートし、単一ディスク故障による停止時間を0にする。
※ そもそもRAID0は、分散ストレージなど別方法冗長化していない限り、採用することはない。
- 冗長化されたコントローラー。故障時も即座に入れ替わり、運用が継続できる。(ただし、サーバ側に対応した特殊なドライバが必要)
- コントローラー毎の入出力インターフェース(FB、SAS、iSCSI用10GBASE-T等)が二重化されている。サーバとディスクアレイ間の経路が独立して二重になるように構成できる(光スイッチ等を置く場合は物理的に2台以上で構成する等)。
- その他、電源、ファン等は全て冗長化されており、ホットスワップ(停止せずに故障部品の交換ができることを言う)が可能。
- 前面パネルでステータス等を表示する液晶や電源ボタン等は冗長化されていない場合があるが、故障しても運用に差し支えないようになっている。また、他部品と同様にホットスワップできる物もある。
通常のPCサーバでCPUが故障した場合は、例え冗長化されていても再起動が必要であり、運用を継続することはできません。しかし、SANディスクアレイはコントローラーのCPUが故障しても、即座に別コントローラーに切り替わることで、運用が継続可能です。よって、部品レベルで見ればSPOFは存在しません。あえて言うのであれば、天災や事故等により筐体そのものが破壊された場合のSPOFは存在することになります。
同様に共用ディスクの修復もデータベースのストレージの話であって、クラスターシステムが関与しない気がするのですが、どうでしょうか？
物理障害と論理障害は区別して考える必要があります。「共有ディスクを利用したコールド・スタンバイ型」は物理障害について可用性を持ちますが、論理障害については可用性はありません。論理障害で一番単純なのは、操作ミス等によりDBを構成するファイルを消してしまった場合です(rm -rfしちゃったとか)。共有ディスクのファイルを消してしまっているので、バックアップから戻す以外に方法はありません。サーバやディスクが物理的に分かれているクラスタ構成のDBの場合は、ファイルが削除されるているのは1台だけですので、壊れた方を切り離してもう1台でそのまま運用することができます。
※ DB自体やクラスタシステム自体のバグ等で全ての分散化されたDBを論理的に壊してしまった場合は、どのようなクラスタであってもバックアップから復旧する以外に方法はありません。クラスタにすれば、いかなる障害も回避可能とか、バックアップが不要とか、そういうわけでは無いことに注意してください。
投稿2016/10/10 00:28
総合スコア21735
> SANアレイディスクの話でコントローラの話がありましたが、コントローラはどのノードで動作しているのでしょうか？
「共有ディスク」は物理的にサーバとは別の筐体で、一般的にはSANディスクアレイと言われてる装置を使います。SANディスクアレイではRAID管理やサーバとの通信(SANやiSCSIといった方式が使われます)を管理する必要があるため、コントローラーがついています。
イメージ的に言うと「共有ディスク」は二台以上のサーバから同時に使える凄いUSB外付けハードディスクのような物です。USB外付けハードディスクを分解するとパソコンに繋がるUSBのインターフェースと中にあるHDDに繋がるSATAのインターフェースの間に色々ついた基盤があります。この基盤部分がコントローラーです。SANディスクアレイはそれの凄い版が搭載されているような感じです。
> 「この方式の利点は、データベース自身に高可用性の機能がない場合でも、外部のミドルウエアで高可用性の機能を持たせることができることです。」
クラスタ機能があるOracle RACなど高価なデータベースを買わなくても、クラスタ機能が無い安価なDBでも高可用性を実現できると言うことです。ただ、そもそもミドルウェアが高価であること、オープンソースのMariaDBにクラスタ機能が搭載された事を考えると、現在はそれほどメリットがあるとは言えません。高価で高速なSANディスクアレイを1台で済ませされるぐらいでしょう。
ありがとうございます。
そもそもの質問なのですが、「外部のミドルウェア」って何を指しているのでしょう？
クエリを送ってくるアプリケーションに関するフレームワークでしょうか？
「外部のミドルウェア」とは下記のような製品です。
http://www.fujitsu.com/jp/products/software/infrastructure-software/infrastructure-software/primecluster/
http://jpn.nec.com/clusterpro/
現在は仮想環境を利用したクラウドが基本となりつつあるため、上のような製品も単純な「共有ディスクを利用したコールド・スタンバイ型」だけではなく、より複雑な高可用な環境を目指すようになっています。そのため、現在記載されているような製品説明だけではわかりにくいかも知れません。
当時の状況は下記の記事が参考になるかと思います。
※ 10年以上前の記事になりますので、現在とは各製品および市場の状況が異なることにご注意ください。
https://thinkit.co.jp/channel/cluster_software.html
回答ありがとうございました。
0
コールドスタンバイしている予備サーバがあるのでSPOFではありません。
適切に構成された共有ディスクを利用したコールドスタンバイ構成のRPOは障害発生時点となります。
RTOは障害検出後、コールドスタンバイしているDBが起動し、アプリケーションサーバがそれを認識するまでの時間となります。
高可用性という単語は曖昧です。要件を満たせば高可用かどうかはあまり重要ではないと考えています。
例えば、主系データベースがダウンした場合は15分以内に副系データベースに切り替える、とあればその15分を満たすように構成すれば良いと思います。
お客様に説明する際は、要件を十分に満たしていれば高可用性と伝えるようにしています。
高可用性という単語は曖昧ながら、例えばMySQL Communityは高可用性を満たしているとは思えません。
一例としてフェイルオーバーやフェイルバック機能は備えていません。
データベースクラスタの障害検出方法は決めの問題なので、関係ないとは思えないです。
例えばSELECT、UPDATEなどを定期的に実行し、失敗が3回連続すると障害とみなすことも決めです。
共有ディスクの修復も重要な問題です。また、クラスターシステムを構成する一つの要素です。
色々な考え方があるので、これが全てのケースにおいて正しいとは言いませんが、
ステイクホルダーの考えにある程度合わせるようにしています。
投稿2016/10/07 08:59
総合スコア6621
回答ありがとうございます。
>コールドスタンバイしている予備サーバがあるのでSPOFではありません。
私が質問であげた状況に対するコメントでしょうか？
そうでしたら、データベースはSPOFではないのでしょうか？
>データベースクラスタの障害検出方法は決めの問題
データベース・サーバの障害検出は私が質問で言ったような方法もあるが、システムごとで決めることができるという意味でしょうか？
また、共有ディスクの修復に時間がかかるのはなぜでしょうか？
> 私が質問であげた状況に対するコメントでしょうか？
> そうでしたら、データベースはSPOFではないのでしょうか？
現行サーバと予備サーバにそれぞれDBが乗っていればSPOFではないということです。
> データベース・サーバの障害検出は私が質問で言ったような方法もあるが、システムごとで決めることができるという意味でしょうか？
はい、その通りです。何が正しいということはありません。
> また、共有ディスクの修復に時間がかかるのはなぜでしょうか？
「時間がかかる」というのが具体的に何を指しているかわかりませんので、何ともいえませんが、、、
ディスクは電源モジュール、RAIDコントローラー、ディスクそのものが主な障害ポイントになると思います。
一番多いのはディスクそのものですが、リビルドにある程度の時間は要します。
参考までに実際にディスクが故障した場合、次のフローで運用していたことがあります。
自動通知でベンダーに通知、ベンダーからのエスカレーション（オンサイト対応連絡）、
ベンダーによるオンサイト対応（故障ディスク交換）、リビルドの完了確認。
ディスクの構成にもよりますが、実運用では半日〜一日強かかっていました。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
退会済みユーザー
2016/10/08 05:51