PMさて、先日まででロードバランサ(負荷分散)の設定が完了しました。S/W)が発生した場合、Webアプリケーションを利用するエンドユーザは再度ログインからしなければなりません。そこで、今日は単一ノードの障害が発生した場合でも継続してWebアプリケーションを利用できるように、セッション情報を共有し高可用性を実現できる環境を構築しましょう。9.1では高可用性を実現する為の手段として下記の2通り存在します。(HADB:高可用性データベース)について説明します。HADBとはそもそも何なんだ?何故エンタープライズ用にHADBが組み込まれているんだ?そんな疑問に答えるためにHADBについて下記にまとめてみたいと思います。セッションデータを格納します。高パフォーマンスーHADBのデータベースノードを追加すればするだけ線形的にパフォーマンスが向上(スケール)するー並列処理を行う高パフォーマンスなデータベース99.999%の高可用性HADBはデータベースのデータにアクセスする際に、99.999%の非常に高い可用性を実現します。それは年間のダウンタイムとして計算するならば、1年間に5分以下しか停止しない事を意味しています。これは、高い高可用性を実現する為に、特別に開発した、並行データベースで現在提供されている一般的なH/Wシステム、ネットワーク回線で実現可能です。Paperメンテナンス性システム管理者は、H/W機器の増強(メモリ・CPU等)、ソフトウェアの追加、OSの保守(パッチ適用等)、HADB自身のバージョンアップ等、様々な作業を行う必要があります。このような作業を行う際もHADBではサービスを停止する事なく作業を行う事ができます。パフォーマンスHADBはリアルタイムの応答を返します。以下で処理が終了します。10,000以上のトランザクションを完了しました。keyに対する操作を実行)また、スケーラビリティに関して、HADBを構成するノードを追加する毎に線形的にパフォーマンスが向上します。1度構成を組んだ後、パフォーマンスの改善が必要と考えられる場合、システム管理者はノードを追加する事でパフォーマンスを改善する事ができるようになります。HADBを使用する場合、セッションサイズがパフォーマンスに大きく影響します。プログラムのセッションサイズを小さくするようにプログラムを作って下さい。上記パフォーマンスデータは過去にUSで行われた検証結果に基づき報告しています。HADBの概要紹介はこの位にしておいて、実際にどのような動きをするデータベースなのか、より詳細に説明してみたいと思います。HADBの詳細:HADBは、データのフラグメント(断片化)とレプリケーション(複製)を通してデータの高可用性を実現します。下記の図のようにデータベース内に存在するすべてのテーブルは分割され、フラグメント(断片化)と呼ばれる、ほぼ同サイズのレプリカ(複製)が作成されます。断片化は、ハッシュ関数に基づいて行われ、HADBの各ノード間にデータを均等に分散させる為に行われます。上記で説明した各フラグメントは、それぞれ異なるDRU中に存在するノードに対して2回保存されます。一つは、「プライマリ」として使用され、そしてもう一つは「ホットスタンバイ」として使用されます。「ホットスタンバイ」用のフラグメントレプリカが赤色で示されています。F1R0はフラグメント番号:1、レプリカ番号:0を表しDRU0に所属します。F1R1はフラグメント番号:1、レプリカ番号:1を表しDRU1に所属します。このように、データベース中に存在するデータの完全なコピーをそれぞれのDRUが保持し、単一ノードHADBノード障害に対する耐障害性や、データの早急な復旧が保証されています。仮に、プライマリのフラグメントレプリカ(F1R0)に対して内容が更新された場合は、データベースのトランザクション処理の一部として更新ログがホットスタンバイフラグメントレプリカ(F1R1)に対して送られ、ホットスタンバイフラグメントレプリカ上でも更新されるようになります。Serverになります)は下記の図に示すようにHADB中に含まれるどのノードに対しても接続が可能です。言い換えれば、クライアントはHADBのノードAかノードBか、さらにはHADB中に含まれるどのノードに接続するかを気にする必要はありません。どのDRU中に存在するかも気にしなくてよいのです。transparency)を提供しているためで、クライアントは実際にデータがどのノードに保存されているのかを知る必要はなく、データベースが自動的に保存されている場所を検索してくれます。Server)が複数存在する場合は、クライアント毎に接続先のHADBノードを変更する事でワークロードがより均等になり推奨されます。耐障害性について各HADBノードは必ず1つのミラーノードを持っています。4とNode5」の組み合わせになっています。これらのHADBノードが何らかの理由により障害発生した場合、ケースに応じて異なる動作を行います。その動作の違いについて下記に説明します。0)がサービスを提供するようになります。0の一番上のノードのフラグメントレプリカが両方とも白色になっています。1)ではノードの自己復旧を試みるため、メモリもしくはハードディスクから再起動を試みます。1)で保持している障害発生時のデータと一致していない可能性があります。0)から更新ログを受け取りデータの同期を試みます。records)仮に更新ログの内容がデータの同期を行うために十分な情報を持っていない場合、ノードの復旧処理は失敗します。そのような場合、次はノード修理という操作が行われます。1)の再構築を行います。上記の操作は、ノード間のデータが同期されるまで行われます。最後に、全てのデータが同期された後、障害発生前の状態に戻します。resumes)障害発生ケース2(ノードの自己復旧失敗の場合):上記のケースと異なり、自己復旧やノードの修理ができないような場合は、(例:物理的なH/Wシステム障害等)異なる動作を行います。1)が持つ役割を全て引き継ぐようになります。7)を構築し初めます。2,3,4,5,6)に対してノードのペアが変更された事を通知します。Overが実施され2つのプライマリフラグメントレプリカを保持しています。1」が自己復旧を試みますが、失敗します。7」に対してコピーされます。7」の組み合わせで通常のサービスが提供されています。1におけるスペアノードとして稼働します。以上でHADBの全体的な動作概要を説明しました。説明がたりない点もありますが、HADBの動作について理解いただけましたか?上記のように、HADBは提供するDBサービスをH/W障害等が発生した場合でも継続して提供できるように、自己回復機能やスペアノードを利用する等して実現しています。結果として、HADBを複数台のノードから構成する事で99.999%の高可用性を実現できるようになっています。インメモリリプリケーションではHADBに比べ高可用性率は若干低下します。そこで、ミッションクリティカルのシステムでは是非HADBの御使用を御検討ください。使用に同意したとみなされます。ポリシー%d人のブロガーが「いいね」をつけました。