高可用性のサポート
可用性の高い環境での Zen の使用
この章では、以下の項目について説明します。
技術の概要
Zen は、物理環境および仮想環境において稼働時間を最大化する数々のソリューションと互換性があります。そのようなソリューションは絶えず進化し続けていますが、通常、そのタイプは高可用性、フォールト トレランスおよび障害回復に分類されます。
高可用性
高可用性」の定義は、高可用性ソリューションを提供するソフトウェア ベンダーによって異なる可能性があります。一般的には、ハードウェア障害やソフトウェア障害、または必要なメンテナンスの発生にかかわらず、稼働し続ける時間の基準レベルに対するシステム設計手法を指します。
物理環境において高可用性を保証するための一般的な手法はフェールオーバー クラスタリングです。仮想マシン環境において高可用性を保証するための一般的な手法はマイグレーション(移行)です。
フェールオーバー クラスタリング
Zen はフェールオーバー クラスター環境のリソースとして機能するよう設計されています。この環境では一度に 1 つのサーバー ノードのみが共有記憶域サブシステムにアクセスします。プライマリ ノードがエラーになった場合は、セカンダリ ノードへのフェールオーバー(切り替え)が発生します。フェールオーバー クラスタリングを使用すると、ソフトウェアのアップグレードやハードウェアのメンテナンスの実行時にもシステムを利用可能な状態にしておくことができます。
Zen は Microsoft フェールオーバー クラスター サービスおよび Linux Heartbeat と互換性があります。フェールオーバー クラスタリングの定義および実装については、各ベンダーのドキュメントを参照してください。Zen Enterprise Server と Cloud Server はフェールオーバー クラスタリングに推奨されるエディションです。
フェールオーバー クラスタリングを参照してください。
マイグレーション
一般論として、マイグレーションとは、実行している仮想マシンまたはアプリケーションを、クライアントやアプリケーションを切断することなく異なる物理マシン間で移動させることです。通常は、仮想マシンのメモリ、記憶域およびネットワーク接続が移行先に移行されます。
Zen は Microsoft Hyper-V、VMware vSphere および Citrix XenServer で提供されるマイグレーション機能と互換性があります。ホスト名が仮想マシンの移動後も同じままであれば、Zen は正常に動作し続けます。マイグレーションの定義および実装については、各ベンダーのドキュメントを参照してください。
マイグレーションを参照してください。
フォールト トレランス
高可用性が稼働時間の予測可能な基準レベルを目指すのに対し、フォールト トレランスはコンポーネントに障害が発生してもシステムを中断することなく稼働させることを目的としています。フォールト トレランスでは同期された共有記憶域が必要です。仮想化環境では、障害が発生した仮想マシンと、置き換わる仮想マシンは異なる物理ホスト上に存在している必要があります。
フォールト トレランスは物理マシンのみを使用して実現します。ただし、仮想環境は、互いに足並みを揃えた仮想サーバーを保持することが容易であるため、物理環境のみという状況は次第に少なくなっています。Zen サーバーは物理環境のみでのフォールト トレランス機能と互換性があります。
仮想環境の場合、Zen は VMware vSphere や Citrix XenServer で提供されるフォールト トレランス機能と互換性があります。フォールト トレランスの定義および実装については、各ベンダーのドキュメントを参照してください。
フォールト トレランスを参照してください。
障害回復
障害回復では、大きな障害の発生後にコンピューター操作の復元が必要となります。通常、これには日常的なオフサイトのデータ バックアップや新しい場所で主要な情報システムをアクティブ化する手続きが含まれます。
Zen は、バックアップ物理マシンまたは仮想マシンを初期化する障害回復技術をサポートする主要なハイパーバイザーと互換性があります。すべてのホスト名が仮想マシンの移動後も同じままであれば、Zen は正常に動作し続けます。これにより、短時間でのサーバー置換および回復が可能です。
障害回復の定義および実装については、各ハイパーバイザー ベンダーのドキュメントを参照してください。
障害回復を参照してください。
ハードウェア要件
このセクションで述べているすべての技術を利用する場合、ベンダーが提供するハードウェア互換性リストで挙げられているサーバー、ディスク サブシステムおよびネットワーク コンポーネントを選択することをお勧めします。弊社でも、ベンダーの製品との互換性テストを行う際にはこの同じハードウェア要件に従っています。
フェールオーバー クラスタリング
フェールオーバー クラスタリングでは、それぞれが独立したサーバー ノードのグループを提供します。それらのノードはすべて共有データ ファイルまたはボリュームの共有システムにアクセスできます。このフェールオーバー サービスでは、一度に 1 つのサーバーだけがデータ ファイルまたは記憶域ボリュームを制御します。現在アクティブなサーバーで障害が発生した場合は、自動的にクラスター内の次のノードに制御が渡され、そのノードのサーバーが制御を引き受けます。
Zen では、1 つのデータベース エンジンだけがデータにアクセスできます。クラスター内では、すべてのノードに Zen エンジンがインストールされるので、それらのエンジンを、そのまま複数のエンジンではなく、1 つのエンジンとして見えるよう構成する必要があります。
各 Zen エンジンは、クラスター ノード単位で個別にライセンスされている必要があります。これはそのノードが物理マシンまたは仮想マシンのどちらでも同じです。ノードごとに Enterprise Server - Active-Passive(アクティブ/パッシブ)ライセンスが必要です。
ここでは、以下の項目について説明します。
Windows Server 用 Microsoft フェールオーバー クラスター
ここでは、Microsoft フェールオーバー クラスターへの Zen エンジン サービスの追加について説明します。これは次のことを前提とします。
一般的な手順
Zen エンジンを含む Windows フェールオーバー クラスターを作成する手順は次のとおりです。
1
クラスターに Windows サーバーをセットアップしてから、Zen エンジンを追加する前に、フェールオーバーが正常に動作することを確認する必要があります。たとえば、フェールオーバーが完了し、すべてのリソースが引き続き利用できることを確認したら、次にフェールオーバーを元のノードへ戻して同様の確認を再度行います。サーバー マネージャー ダッシュボードやフェールオーバー クラスター マネージャーを使用してフェールオーバー クラスタリングをセットアップおよび検証する方法については、Microsoft のドキュメントを参照してください。
2
Zen エンジンをインストールしたら、この共有データの場所を使用するためにそれらのエンジンを設定します。
3
下の表にある手順をご確認ください。次の手順に進む前に、すべての Zen エンジンをインストールしてください。
4
下の表の手順に進みます。
Windows フェールオーバー クラスターへ Zen をインストールし設定する
次の表では、Windows Server のフェールオーバー クラスターに Zen を追加する際の推奨手順を説明しています。
ファイル共有を Zen エンジン サービスの依存関係として設定します。[ネットワーク名をコンピューター名として使う]オプションを選択します。
ディレクトリに関するエンジン プロパティを設定します。エンジンを再起動するよう指示されたら[いいえ]をクリックします。
トランザクション ログのディレクトリ]には、Transaction Logs ディレクトリをコピーする共有ディスク上の場所を入力します。
DBNames 設定ファイルのディレクトリ]には、dbnames.cfg ファイルをコピーする共有ディスク上の場所を入力します。
DEFAULTDB プロパティの[ディレクトリ]では、[辞書のロケーション]と[データ ディレクトリ]に、Defaultdb ディレクトリをコピーする共有ディスク上の場所を設定します。
DEMODATA プロパティの[ディレクトリ]では、[辞書のロケーション]と[データ ディレクトリ]に、Demodata ディレクトリをコピーする共有ディスク上の場所を設定します。
TEMPDB プロパティの[ディレクトリ]では、[辞書のロケーション]と[データ ディレクトリ]に、Tempdb ディレクトリをコピーする共有ディスク上の場所を設定します。
これで、 フェールオーバー クラスターの設定が完了しました。フェールオーバーが発生したときには、クライアント接続も失敗し、クライアント アプリケーションを再起動する必要があるかもしれないので注意してください。
メモ:クラスター環境の Zen サーバーにパッチを適用する場合は、弊社のサポート FAQ ページの「バージョンアップ関連」を参照してください。
Linux Heartbeat
Heartbeat プログラムは Linux-HA(High-Availability Linux Linux)プロジェクトの中心的なコンポーネントの 1 つです。Heartbeat はあらゆる Linux プラットフォームで動作し、1 つのプロセスで停止ノードの検出、通信およびクラスター管理を行います。
ここでは、Linux Heartbeat への Zen エンジン サービスの追加について説明します。これは次のことを前提とします。
事前要件
Zen をクラスターに追加する前に、Linux Heartbeat が正常に機能していることが必須です。Heartbeat のインストール、動作確認、タスクの実行方法については、「The High Availability Linux プロジェクト」(http://www.linux-ha.org/ja/HomePage_ja)ドキュメントを参照してください。
ほかのアプリケーションの場合と同様に、Zen を追加する前には必須のクラスター コンポーネントを設定します。
Linux Heartbeat フェールオーバー クラスターへ Zen をインストールし設定する
次の表では、Linux Heartbeat に Zen を追加する際の推奨手順を説明しています。
共有記憶域上で、データベースを配置する場所を作成します。この場所は自由に選択できます。ユーザー zen-svc がその場所に対して読み取り、書き込み、および実行権限を持っていることを確認してください。
zen-data グループおよび zen-adm グループはそれぞれ、クラスター ノード上の zen-data グループ ID および zen-adm グループ ID と一致している必要があります。
ユーザー zen-svc は、クラスター ノード上の zen-svc ユーザー ID と一致している必要があります。
クラスター ノードごとに、ユーザー zen-svc としてログインし、共有記憶域へマウントされるディレクトリを作成します。ユーザー zen-svc にはパスワードがありません。su コマンドを使用した root アカウントによるアクセスのみを行うことができます。ディレクトリ名は自由に選択できます。
Zen データベース エンジンを制御するノードごとに Heartbeat サーバーを構成します。次のような構成を行います。
スタートアップ。Heartbeat サーバーの起動のタイミングについての設定を指定します。これをオンに設定すると、Heartbeat サーバーはブート時に起動するようになります。
Heartbeat Management Client で、新しい native 項目を追加します。[Belong to group]には、Zen 用に追加したグループを選択します。[Type]には IPaddr を選択します。
追加したリソースで、IPに対してクラスターの IP アドレスを指定します。Linux Heartbeat がインストールされ構成されたときには、(ノードではなく)クラスターに割り当てられた IP アドレスを使用します。
新しい native 項目をもう 1 つ追加します。[Belong to group]には、Zen 用に追加したグループを選択します。
Type]には Filesystem を選択し、fstype というパラメーターを削除します。新しいパラメーターを追加し、[Name]には "device" を選択します。[Value]には、共有記憶域のデバイス名、コロン、共有マウントの場所を指定します。
新しいパラメーターをもう 1 つ追加し、[Name]には "directory" を選択します。[Value]には、NFS マウントで使用するディレクトリを指定します。
新しい native 項目をもう 1 つ追加します。[Belong to group]には、Zen 用に追加したグループを選択します。[Type]では、[Description]フィールドに "Zen OCF Resource Agent" の記載がある zen-svc エントリをクリックします。この他に設定は必要ありません。
Filesystem リソースを追加できた場合は、クラスター サーバーと共有記憶域間にマウントが存在するようになります。クラスター ノードの 1 つに、ユーザー zen-svc としてログインします。共有記憶域マウントで、"log" と "etc" という名前のディレクトリを作成します。
ZenCC を実行するノード以外のすべてのクラスター ノードを代替モードにします。zen-svc ユーザーとして、1 つのアクティブ ノードで、あるいはアクティブ ノードにアクセスできるクライアントから ZenCC を実行します。
Zen エクスプローラーで、新しいサーバーを追加し、クラスターの名前(または IP アドレス)を指定します。
追加したサーバーのプロパティにアクセスします。ログインを指示された場合は、admin ユーザーとしてログインします。パスワードは空のままにします。[ディレクトリ]プロパティにアクセスします。[トランザクション ログのディレクトリ]には、"log" ロケーション用に作成したディレクトリを指定します。[DBNames 設定ファイルのディレクトリ]には、"etc" ロケーション用に作成したディレクトリを指定します。マウントされた共有記憶域上にサブディレクトリを作成するを参照してください。
クラスター ノードのうち 1 つのノードのオペレーティング システムから、ユーザー zen-svc としてログオンし、データベースを置くファイル システム共有下にディレクトリを作成します(ユーザー root としてディレクトリを作成する場合、ユーザー zen-svc はそのディレクトリに対して読み取り、書き込み、および実行権限を持っていることを確認してください)。
zen-svc ユーザーとして、1 つのアクティブ ノードで、あるいはアクティブ ノードにアクセスできるクライアントから ZenCC を実行します。ZenCC でクラスター サーバーを構成するで追加したサーバーに新しいデータベースを作成します。[場所]には、データベースを置くディレクトリを指定します。必要に応じてその他のデータベース オプションを指定します。
クラスター環境における Zen の管理
フェールオーバー クラスター環境に Zen をインストールすると、リソースとして管理できます。ここでは、一般的な管理の内容について説明します。
Zen ライセンスおよびノードのメンテナンス
通常の Zen ライセンスやマシンのメンテナンスに関する手順は、フェールオーバー クラスター環境のノードにも同様に適用されます。データベース エンジンがインストールされた物理マシンまたは仮想マシンの構成を変更する前には Zen 製品キーを認証解除してください。構成の変更が完了したら再度認証してください。
Zen User's Guide』のキーを認証解除するにはおよびキーを認証するにはを参照してください。
Zen 停止時の動作
クラスター ノードでエラーが発生した場合、Zen クライアントはスタンバイ ノード上の Zen エンジンに自動的に再接続しません。アプリケーションでクライアントを Zen データベースに再接続するか、アプリケーションを再起動する必要があります。データベース エンジンで[自動再接続の有効化]がオンに設定されていたとしても同様の対処が必要です。
トランザクション一貫性保持がオフで、トランザクションが完了する前にエラーが発生した場合には、自動的にトランザクションを開始する前の状態にロール バックされます。つまり、すぐ前の完了済みチェック ポイントへ戻るということです。ロール バックは、アクティブ サーバーがデータ ファイルへのアクセスを要求した時点で発生します。
トランザクション一貫性保持を設定している場合、クラスター ノードに障害が発生した時点と最後のチェック ポイントの時点との間に発生した完了済みの変更は回復させることができます。トランザクション一貫性保持はすべてのノードで同じように構成される必要があります。また、トランザクション ログは共有記憶域に置かれます。ただし、トランザクション一貫性保持が有効だった場合でも、クラスターの障害が発生した時点で完了していないトランザクションは失われます。
Actian Zen エンジン サービスの停止と再起動
オペレーティング システムから Zen データベース エンジン サービスを手動で停止すると、アクティブ ノードからクラスターのフェールオーバーが発生します。サービス ノードのメンテナンスを実行しており、そのようなフェールオーバーを回避したい場合は、サービスをクラスター ユーティリティから停止します。
Zen 設定の変更
変更する設定によってはデータベース エンジンを再起動する必要があります。設定リファレンスを参照してください。
Windows クラスター アドミニストレーターで、次の手順を記載されている順序で実行します。
1
Actian Zen エンジン サービスを右クリックして、[このリソースをオフラインにする]をクリックします。
2
Actian Zen エンジン サービスを右クリックして、[このリソースをオンラインにする]をクリックします。
ソフトウェアのパッチ
ある時点で、Zen またはフェールオーバー クラスター ソフトウェアにパッチを適用する必要があるかもしれません。この実行をサポートするために、弊社ではバージョンアップ関連のサポート資料を提供しています。
マイグレーション
マイグレーションでは、Zen を実行している仮想マシンを、ある物理ホストから別のホストへ移動します。通常は、仮想マシンのメモリ、記憶域およびネットワーク接続が移行先に移行されます。ハイパーバイザーによって、マイグレーションは "ライブ" マイグレーションまたは "ホット" マイグレーションと呼ばれます。
"ライブ" マイグレーションまたは "ホット" マイグレーションでは、クライアントから Zen への接続がそのまま維持されます。これにより、ハードウェア バランスまたはリソース バランスの変更が可能です。"コールド" マイグレーションでは、仮想マシンを一時停止する必要があるため、ネットワーク接続が中断されます。クライアントから Zen への接続を再確立する必要があります。
マイグレーション環境には、実行中の Zen のインスタンスが 1 つだけあります。これにより、ホスト マシンがクラッシュした、またはホスト マシンを直ちにオフラインにする必要がある場合、その環境はやや脆弱になります。また、共有記憶域にエラーが生じた場合、データベース エンジンは物理記憶域に対する読み込みまたは書き込みを処理することができません。ハイパーバイザーによっては、共有記憶域を使用しないマイグレーション ソリューションを提供しています。
ホスト名が仮想マシンの移行後も同じままであれば、Zen は正常に動作し続けます。製品キーの状態は "アクティブ" のままです。
マイグレーション環境で Zen をインストールまたは構成する際、特別な手順は必要ありません。ハイパーバイザーのドキュメントを参照してください。
フォールト トレランス
フォールト トレラント環境はマイグレーション環境と似ていますが、さらにコンポーネントがエラーになっても動作が中断されないようする機能も備えています。フォールト トレラント環境では、ネットワーク接続、継続的なサービスおよび同期された共有記憶域を介したデータ アクセスが確保されます。コンポーネントの切り替えが起こっても、クライアント マシンおよびアプリケーションは正常に機能し続け、データベース エンジンは中断されません。
フォールト トレラント環境で Zen をインストールまたは構成する際、特別な手順は必要ありません。ハイパーバイザーのドキュメントを参照してください。
障害回復
障害回復にはデータの回復やサイトの回復が含まれています。データの回復はデータを保護および復元する方法です。サイトの回復は、データを含むサイト全体を保護および復元する方法です。
データの回復は、ハイパーバイザーの共有記憶域および Zen のトランザクション ログとトランザクション一貫性保持によって容易に行うことができます。トランザクション ログおよびトランザクション一貫性保持を参照してください。Zen Enterprise Server および Cloud Server ではトランザクション ログとトランザクション一貫性保持を使用できます。
サイトの回復は物理マシンと仮想マシンのどちらでも実行できます。回復されたサイトでホスト名が同じままであれば、Zen は正常に動作します。これは一般に仮想マシンの場合です。物理マシンを回復する場合、回復したサイトでホスト名が回復前と異なっていると、Zen の起動時に Zen 製品キーの状態が検証失敗に変わります。Zen は検証失敗の状態でもしばらくの間は正常に動作し続けます。その間にキーを修復するか、元のサイトへ戻すことができます。
障害回復環境で Zen をインストールまたは構成する際、特別な手順は必要ありません。ハイパーバイザーのドキュメントを参照してください。