Table of Contents: 表示
このドキュメントは GroundWork Monitor システムのバックアップ手順を自動化するための高度な構成設定について触れ、上記の目次でリストアップしたトピックを説明します。
RPM システムの初期インストールおよび多くのパッチは、それらを適用するための明確な手順と共にRPMパッケージで提供されます。何もない(地金の)状態からのシステムの基本的なインストレーションであれば、正確に繰り返すことができるでしょう。このレベルのリカバリを行うには、元媒体と特定の構成要素(IPアドレス、名前、DNS など)についての変更作業記録などが必要です。
データベース GroundWork Monitorは、構成、制御および監視ステータスとイベント保存のためのデータベースエンジンとして、MySQL Professional を利用しています。下記にいくつかのデータベースの名前を挙げますが、完全な一覧ではなく、より多くのプロジェクトを統合するのに合わせ、追加されるでしょう。これらのデータベースそれぞれは、GroundWork Monitor の機能に重要であり、バックアップやリカバリの方針に含まれている必要があります。
GWCollageDB - GroundWork Foundation のデータベース
Monarch - 構成データベース
Dashboard - インサイトと可用性レポートのデータベース
JBoss Portal - ユーザインタフェース、Web アプリケーション および パーミッションのデータベース
ファイル GroundWork Monitorは、製品インストールのための RPM に含まれたり、カスタマイズ中に追加されたりしたファイルを使用します。RPM パッケージは、それらのほとんどがリビルドできるので、チューニングや現地語化は、明確に RPM インストール後に行われる必要があります。つまり、これらのファイルについても認識し、バックアップとリカバリの方法で一緒に取り扱う必要があります。このようなファイル例として下記のものがあります:
/var/spool/cron/*
/etc/sysconfig/iptables/iptables.cfg
/usr/local/groundwork/common/etc/*
結論 バックアップとリカバリでうまく操作をするために、初期インストレーション、データベースおよび構成ファイルを異なる方法で扱う必要があります。
バックアップとリストアのために下記の方法を推奨します。データベースのサイズによっては、もっと頻繁にバックアップを行ても良いでしょう。
下記の例のような記述を用いて、 MySQL データベースの完全なバックアップを実施する 'cron' ジョブを実行します。これは、タイムスタンプの付いたひとつのバックアップファイルとして、その時の全データベースのイメージを生成します。下記の cron ジョブの例は、自動的に5日以上古いイメージのディレクトリを自動的に取り除きます。
0 */12 * * * date=`date -Iminutesf`; mysqldump -h 127.0.0.1 --user=admin --opt --all-databases --single-transaction | gzip -c > /backup/mysql/groundwork$date.sql.gz; find /backup/mysql -mtime +5 -exec /bin/rm -rf {} \;
一日に一度、変更が極端に少ない場合は変更の度毎に、'cron' ジョブから下記の一覧の重要なデータベースのバックアップを個別に実施します。この記述では、既存のファイルを上書きするので、それらのバックアップは保持されません。
0 1 * * * mysqldump -h 127.0.0.1 --user=admin --single-transaction monarch | gzip -c > /backup/mysql/monarch_backup_file.sql.gz
10 1 * * * mysqldump -h 127.0.0.1 --user=admin --single-transaction GWCollageDB | gzip -c > /backup/mysql/GWCollage_backup_file.sql.gz
20 1 * * * mysqldump -h 127.0.0.1 --user=admin --single-transaction dashboard | gzip -c > /backup/mysql/dashboard_backup_file.sql.gz
最後に、Monarch を使う通常の運用において Cmmit(コミット)を実施する前に必ずバックアップを行ってください。上述の cron ジョブで生成されるのと機能的に同等のバックアップが作成され(すべてのバックアップのリストを保持するのと同様)行われた全ての変更を管理する利点があります。例中のターゲットディレクトリの場所を決めることは重要です。それには以下の条件を満たす必要があるでしょう:
MySQL がバックアップを作るのを早く行うための高速アクセス
バックアップ対象のマシンとつながっていないこと
リムーバブル媒体に書き込むど、ダンプファイルからオフサイト・コピーを作ることを考慮するべきこと
貴社のデータ保存とリカバリ方針のガイドラインに従って、オフサイト媒体の定期ローテーションが決められていること
注意:
完全な mysqldump を作成する手順は数分かかり、そのデータベースバックアップの期間中は、モニタリングエンジンによる定常のアップデートができなくなるでしょう。そのため、モニタリングシステムが小さいか、動いていないか、あるいは、動かなくても良いと認められているとき以外は、そのようなバックアップを行うのは実用的ではありません。
バックアップとシステム使用の間の相互関係の影響を緩和することができます。バックアップを作る前に gwservices を停止してその後に再起動することで、データベース GWCollageDB はアップデートのためにオープンされません。フィーダは、静止し、バックアップ中に入ってくる全てのメッセージは未処理ログファイルのなかに保存され、後で取り出されます。これを行う選択判判断は、インストレーションでの経験を元にするべきでしょう。バックアップが行われる時に、MySQLへのコネクションが Refused(破棄)されているかどうか、ときどきログファイル (/usr/local/groundwork/foundation/container/logs)を見てください。
バックアップとシステム使用の間の相互関係の影響を緩和することができます。バックアップを作る前に gwservices を停止してその後に再起動することで、データベース GWCollageDB はアップデートのためにオープンされません。フィーダは、静止し、バックアップ中に入ってくる全てのメッセージは未処理ログファイルのなかに保存され、後で取り出されます。これを行う選択判判断は、インストレーションでの経験を元にするべきでしょう。バックアップが行われる時に、MySQLへのコネクション Refused(破棄)されているかどうか、ときどきログファイル (/usr/local/groundwork/foundation/container/logs)を見てください。 あなたの会社のデータ保存とリカバリ方針のガイドラインに従って、オフサイト媒体の定期ローテーションが決められていること、
代替案は MySQL のトランザクションロギングを使用することです - トランザクションロギングとは、データベースエンジンがトランザクションの終了時にすべてのトランザクションをログファイルに記録することです。この価値は、バックアップ操作のような、長いトランザクションが他の処理と同時に存在でき、データベースのリカバリはその時点までは行えて、システム障害の場合に役に立つということです。新のシステム全体バックアップ(mysqldump)と、そのバックアップが行われた後のログファイルの組み合わせによって、きれいなリカバリが行えるでしょう。
しかし、上述の代替案ではスペースを使用して性能が劣化するので、お客様が mysqld をトランザクションロギングモードで実行することは推奨はいたしません。その比率は全体の負荷の中で非常に多くのパーセンテージになるでしょう。
監視サーバ上のデータ欠落を起こしてしまうシステム障害の場合、結果として、稼動イメージと MySQL データベースのリカバリで妥協しなければならないことがあります。リカバリが失敗した場合、最も新しいバックアップイメージが使用されるでしょう。監視データ(ステータスや稼働率)の欠落や、Monarch 、ユーザ、ダッシュボードおよびポータルの構成変更の欠損は、最新のバックアップとリカバリが完了するまでの間の期間で発生することになります。
どのバックアップイメージを使用するかは、あなたがどのような問題に直面しているかによって変わります。状況を評価し、リカバリーのための作業が最も少なくなるイメージを選んでください。リカバリーの手順は下記の通りです
新しいサーバを立ち上げるか、正常なファイルシステムで MySQL の稼動中ポイントまでのリカバリを実施します。
新しいサーバを立ち上げるか、正常なファイルシステムで MySQL の稼動中ポイントまでのリカバリを実施します。
何らかのアプリケーション( gwservicesなど)が稼動していれば停止させます。
最新の mysqldump ファイルを適当なファイルの上で unzip(解凍)します。
下記を投入してリカバリを実施します。 xxx は、ダンプのファイル名です:
mysql < xxx
mysql エンジンと関連する GW サービスをリスタートします。
/usr/local/groundwork/ctlscript.sh restart mysqld
/usr/local/groundwork/ctlscript.sh restart gwservices
ブラウザを再起動した後、ブラウザのキャッシュをクリアする必要があります。
上記の置き換え文字 xxx があるステップで、リカバリーに関連する特定ファイルで行います。例: GWCollageDB そして、 xxx はダンプのファイル名です:
mysql GWColllageDB < xxx
MySQL エンジンと関連するGW サービスをリスタートします。
/usr/local/groundwork/ctlscript.sh restart mysqld
/usr/local/groundwork/ctlscript.sh restart gwservices
ブラウザを再起動した後、ブラウザのキャッシュをクリアする必要があります。
インストレーションには、事故やアップグレードのために欠落してしまう事象のために置き換えなければならない、構成ファイルやカスタマイズが含まれています。ここに、そのような事故やアップグレード後の構成ファイルとカスタマイズのリストアを支援する推奨手順があります。
最低限、単一の変更管理ファイルや、CF エンジンや CVS などの管理スキームにあるすべての構成ファイルを、パスと名前で特定します。安全なリソース上にこれらの変更されたファイルのバックアップを作り、同時に、将来のリカバリーのためにデータベースをバックアップします。定期的に保存ファイルの正しさの確認を実施し、定常的にアップデートをします。
下記に、非常に単純化した変更ファイル手法を使った、cron ジョブの例を示します(通常のプロジェクトを外れたより専門的な体制を作ることをお勧めします)。
0 1 * * * date=`date -Iminutes`; tar ?cT yyy | gzip -c > /backup/configs/groundwork-$date.gz; find /backup/configs -mtime +5 -exec /bin/rm -rf {} \;
yyy は変更したファイルのリストを含むファイルのパスと名前で置き換えます。そのバックアップファイルが、バックアップを行おうとしている装置の一部でないものの上のあることを確認してください。定期的にサイトのコピーを取ることを考慮してください。
復旧は、アップグレード中に上書きされた、あるいは、サーバ損傷後に最初からリビルドされた全体インストレーション内のいくつかのファイルの置き換えとなるでしょう。どちらの場合でも、上書きする前に最新のバックアップをテンポラリのファイルシステム(/tmp)に untar してリカバーしたファイルをひとつひとつ確認し、どれがどれと対応するかを比較することを推奨します。
長期間分析のための値が入った RRD ファイルがあります。これらのファイルは運用中に監視プロセスによって頻繁にアップデートされます。バックアップを成功させるにはファイルが一部が書き換え中でない時に変更を捕まえることが必要です。どのように変更を捕らえるかは要件定義で行う必要があります。
GroundWork Monitor がコントロールするアクティブやパッシブチェックは、RRD ファイルを生成します。これらをうまくバックアップするために、(Nagiosのための)ファイルベースのパフォーマンスデータ処理とバックアップを統合することを推奨します。これには最小限の Nagios の生成プロセス停止が必要です。この後にバックアップを行います。そして、しかるべきデーモンや cron ジョブをリスタートします。
バックアップを作るのと同様に、生成プロセスとリストア間の衝突を回避するための注意が必要です。デーモンを停止し、リストアを実施してからデーモンをリスタートします。