ラベル FMS の投稿を表示しています。 すべての投稿を表示
ラベル FMS の投稿を表示しています。 すべての投稿を表示

2017-06-09

WebDirect 16 ワーカマシン構成による500+スレッド 同時接続テスト


  FileMaker Server 15 の WebDirect (WebDirect 15)では、最大同時接続数は 100、構成サーバは最大2台まででしたが、FileMaker Server 16 の WebDirect (WebDirect 16)では最大同時接続数が500、構成サーバは最大5台までとなりました。

 前稿では Apache JMeter を使用し、WebDirect 16 に対して25セッションでレコードを作成するテストを行いました。結果、旧版 WebDirect に比べパフォーマンスが向上し、エラー(レコードの作成失敗)が発生しないことを確認しました。 WebDirect 16 が実用段階に近づいていることを実感しました。

 今回は前回と同じく JMeter を使用し10~500+ のスレッドからレコードを作成するテストを実施しました。 

WebDirect 16 で 500 同時接続を実現するためのワーカマシン構成

 最初にインストールについて少しだけ触れます。WebDirect 16 では、1台のマスタマシンと 最大4 台迄のワーカマシンを構成できます。インストール自体は、下図のようにマスタマシンかワーカマシンを選択するだけなのでとてもシンプルです。 

マスタマシンかワーカマシンかをインストール時に選択すればよい

 ワーカマシン展開の詳細は、FileMaker 16 WebDirect ガイドの『展開オプション』の項をご覧ください(p20~30) 。以下の抜粋イメージが参考になると思います。


FileMaker® Server16インストールおよび構成ガイド『第 3 章 複数のマシンでの FileMaker Server の展開』(P.22)より

 

サーバ構成

 今回のテストでは、 Hyper-Vを 搭載する2台の物理マシンを用意し、1台に3つの仮想サーバ(ワーカマシン 1~3)、もう1台に2つの仮想サーバ(ワーカーマシン 4 と 5)を入れています。

  • マスタマシン(兼ワーカマシン1):
       CPU: 3.0Ghz
       コア数/メモリ: 4core 8GB RAM(FileMaker社推奨構成)
       Windows Server 2012 R2 (64bit)
  • ワーカマシン2:
       CPU: 3.0Ghz
       コア数/メモリ: 4core 8GB RAM
       Windows Server 2012 R2 (64bit)
  • ワーカマシン3:
       CPU: 3.0Ghz
       コア数/メモリ: 4core 8GB RAM)
       Windows Server 2012 R2(64bit)
  • ワーカマシン4:
       CPU: 2.93Ghz
       コア数/メモリ: 4core 8GB RAM
       Windows Server 2016 (64bit)
  • ワーカマシン5:
       CPU: 2.93Ghz
       コア数/メモリ: 4core 8GB RAM
       Windows Server 2016 (64bit)

WebDirect のロードバランス

 JMeter によるテストに入るまえに、異なる 5 台のクライアントマシンの Web ブラウザから WebDirect 16に同時アクセスし、WebDirect がどのようにロードバランスを行うのか ― どのようにマスタ機が接続をワーカマシンに割り振るのか ― を観察してみました。
 JMeter のような負荷テストツールではなく、実際のブラウザで WebDirect のリアルな動きを確認しておくことは、意味があると思われます。
 結果として、マスタマシン(兼ワーカマシン1)にクライアント接続が割り当てられることはなく、ワーカマシン ワーカマシン2 に 2 接続、ワーカ3、4、5 にそれぞれ 1 接続ずつ割り当てられました。
5台のクライアント PC から WebDirect にアクセスしたときのサーバ割り当て状況

 また、ひとつのWebクライアントが複数の 5つのブラウザタブを開いた状態で、WebDirect にアクセスした場合にも、ワーカマシン2 に  2 接続、ワーカマシン3、4、5 にそれぞれ 1 接続が割り当てられましたが、この時もワーカマシン1 に割り当てられることはありませんでした。
1台のクライアント PC の Web ブラウザで 5 つのタブから同時接続したときのサーバ割り当て状況
 このように、WebDirect は基本的に、接続先のワーカマシンの負荷状態を判断し、より負荷の低いワーカにルートします。
 ※ワーカマシン1(マスタ) はデータベースサーバおよび管理ツールが稼働しており、他のワーカマシンに比べると負荷が高いため、WebDirect 割当先になりにくいと考えられます。もちろん、マスタ1台の構成では、 このマシンがWebDirect の処理も併せて行います。

 

JMeterシナリオ

 JMeter を使用しセッションを10~500+作成、各セッションから FileMaker のスクリプトを実行して出庫伝票(ヘッダレコード1、明細レコード1)するシナリオを作成しました。
 

1 台構成でのテストと結果

 さて、JMeterによるテストを見ていきます。最初にマスタ1台だけの構成で上記のJMeterシナリオを実行してテストを行いました。結果は下表のとおりです。表中、Ramp(秒) はすべてのスレッドを送信し終わるまでの所要秒数を示しています。

 表の見方 を テストNo 4(スレッド=100)を例に説明します。No.4 は、0.5秒間に100のスレッドを作成し、開始から終了までに 6.4 秒かかっていることを示しています。失敗数は作成されなかったレコード数(エラー)で、No.4は 100 すべてのスレッドが成功し、100 件の出庫伝票が作成されました。  尚、各テストは特に記載が無ければ 5 回ずつ実施し、所要時間と失敗数はその平均値をとっています。
【表1】
No ワーカ数 スレッド ループ Ramp
(秒)
 
所要時間(秒) 失敗数 1Recの平均作成時間(秒) 備考
1 1 10 1 0.5 1 0 0.100 
2 1 20 1 0.5 1.2 0 0.060 
3 1 50 1 0.5 3.4 0 0.068 
4 1 100 1 0.5 6.4 0 0.064 
5 1 200 1 0.5 14 0 0.070  2回計測
6 1 300 1 0.5 23 0 0.077  1回計測
7 1 350 1 0.5 19 76 0.054  1回計測
8 1 400 1 0.5 17 142 0.043  1回計測
イタリック(斜体)部分は1回または2回のみテストを実施

  FileMaker社はマスタ1台構成下での最大接続数 を100 としているだけあり、スレッド数 10 ~ 100 は安定して動作しました。
 さらにスレッド数 100超のテストも行いました。 その結果が No.5以降ですが、100 を超過しても同時接続ライセンスがあれば接続を受け付けるしくみになっているようです。
 300 スレッドまでは接続、レコード作成ともに成功しましたが、350を超えるとサーバが高負荷状態となり、接続の失敗が目立つようになっていることがわかります。

マスタマシン 1 台 + ワーカマシン 4 台構成でのテスト

 つづいて FileMaker Server を 5 台構成のテスト展開してテストを実行しました。

【サーバ5台構成のイメージ】
本テストはプレビュー(ETS)版(詳細はTechNet)を使用して行いました

 テスト内容と結果は以下のとおりです。

【表2】
No ワーカ数 スレッド ループ Ramp
(秒)
 
所要時間(秒) 失敗数 1Recの平均作成時間(秒) 備考
50 5 10 1 0.5 4.6 0 0.460 
51 5 20 1 0.5 4.2 0 0.210 
52 5 50 1 0.5 6.2 0 0.124 
53 5 100 1 0.5 13.4 0 0.134 
54 5 100 1 10 11 0 0.110  1回計測
55 5 200 1 未実施
56 5 300 1
57 5 400 1
58 5 500 1 0.5 46 128 0.092  1回計測
59 5 500 1 2 58.5 1.5 0.117  2回計測
60 5 500 1 5 60 0 0.120  1回計測
61 5 500 1 7 49 0 0.098  1回計測
62 5 500 1 10 63 0 0.126  1回計測
63 5 500 1 30 48 0 0.096  1回計測
64 5 500 1 40 48 0 0.096  1回計測
65 5 500 1 7 54 0 0.108 
66 5 600 1 40 59 0 0.098  1回計測
67 5 1000 1 55 98 130 0.098  1回計測
イタリック(斜体)部分は1回または2回のみテストを実施

考察


 以下、今回行ったテストからの考察となります。

高い処理能力

 表1 のテストNo.6 は、1台構成(マスタのみ)環境下で、0.5 秒間に 300 スレッドからクエリを発行し、エラーを出すことなく、23 秒の間に 300 の出庫伝票の作成に成功しています。中規模程度の環境であれば、パフォーマンス的に WebDirect 16 は Webアプリケーション構築の選択肢になると思われます。

適切なワーカマシン数

 表1のテストNo.6 と表2 のテストNo.53 を見てください。他の条件は同じで、ワーカ数が 1 から 5 に増えているにもかかわらず、所要時間はマスタ 1 台の構成のほうが速くなっています。このテストに関しては、おそらくマスタがロードバランスに費やすオーバーヘッドが高いため、ロードバランスを行わない 1 台構成が有利になるものと思われます。

 本テストは短い時間に多くのスレッドから1回のみリクエストを発行するというもので、すべての運用環境に適用できるものではありませんが、単純にワーカマシンを増やせば実行速度が上がるわけではないという可能性を示しています。幸い、ワーカマシンの増設は簡単に行えるので、業務状況やユーザの意見を参考に、ワーカマシンを適時増設していくことも可能と思います。


 ワーカマシンの接続On/Offについて


 ワーカマシンの接続On/Offは、FileMaker Server 16 の Admin Console ページで簡単に行えます。

 下図は、ワーカマシン 2 および 3 の接続を停止したときの様子です。

WebDirect ワーカマシン 2 および 3 の接続を停止したときの様子

  ワーカマシン 2~5 は接続をOn/Offすることのほかに、ゴミ箱アイコンをクリックすることにより、マスタマシンとの接続設定を消去することもできます。
 これに対し、ワーカマシン 1 はマスタサーバ兼用のため、WebDirect ワーカマシンとしての接続停止はできますが、削除はできないようになっています。



短い時間内で大量のクエリが実行された場合のエラー

 上表で赤字の部分は出庫伝票の作成に失敗した件数を示しています。短い時間に多くのクエリが発行されると、エラーが発生しやすくなります。下図は高負荷状態の時に商品画面にアクセスしたのですが、フィールドに < File Missing > が表示されるエラーが発生しました。



 また、サーバが高負荷状態になると、Admin Console が以下のように無応答状態になることがあります。




 さらにアクセスが集中すると、Web サーバ上側でエラー 503 (Service Temporarily Unavailable) が発生し、接続を受け付けなくなることもあります。
 よって、WebDirect の運用を始める前に、最大接続ユーザ数の見積やピーク時の負荷を想定してのテストはやっておくに越したことはありませんね!

ロードバランス

 記事が長くなってまいりましたので、WebDirect 16 のロードバランスについては、別稿を設けたいと思います。



 アプリケーションを高速に開発できる FileMaker。 WebDirect 16 の登場によって Web上の500 ユーザがブラウザから同時接続できるようになりました。 WebDirect は Webアプリケーションの開発において、新たな選択肢を提供する段階に入ったように思います。



 土屋企画では WebDirect の受託開発及び導入支援コンサルティングを請けたまわっております。 WebDirect の導入を検討されているお客様は、こちらよりご相談いただければと思います。



(亀)

2017-05-24

WebDirect は 16 で実用段階に近づくか? ― JMeter による WebDirect 14/15/16 比較

 FileMaker 16 が 2017 年 5 月 10 日にリリースされました。 この新バージョンで小社が注目しているのは

   1.WebDirect 16 の実行速度と安定性の向上
   2.FileMaker  のSQLデータソース用帳票ツールとしての利用

の2点です。今回は上記1について調べてみました。

 FileMaker Server 13 で搭載された WebDirect (WD)は、当初はサークルアイコンが出っ放しになった末に無応答になるなど、導入を躊躇させる機能でしたが、リリースを重ねるごとに安定性が向上しているという感じはします。 そこで、今回は若干の期待をしながら FileMaker Server 16 の WebDirect のパフォーマンステストを行いました。


 前回の WebDirect のパフォーマンスに関する記事は、こちらをご参照ください。


 今回も、前回と同様に Apache JMeter (以下、JMeter)というパフォーマンステストツールを使用し、WebDirect (WD)16 のパフォーマンスを調べました。
 以下にその内容をレポートします。前回の実験で使用した WD14 および WD15 のデータもともに掲載してありますので、WD の採用を検討されている方の参考になれば幸いです。

テスト内容と結果


 今回のテストでは、小社製品「FMEasy在庫 IWP/WD R1.5」を使用し、出庫伝票を作成するスクリプトを作成。JMeter によりこのスクリプトを 25 のセッションで 10 回ずつ実行し、その所要時間を測定するとともに、CPUの占有状態を観察しました。 また、このテストは  WD 16 で行うとともに、サーバのリソース(コア数とメモリ)を増やすことにより、パフォーマンスがどの程度改善するかも測定しました。

仮想サーバ構成


 CPU: 3.0Ghz
 コア数/メモリ: 1core/2GB、2core/4GB、4core/8GB の3パターン
 Windows Server 2012 R2 (64bit)

JMeterシナリオ


 JMeter により、「FMEasy在庫 IWP/WD R1.5」の出庫伝票を1つ作成後にログアウトするスクリプトを以下のシナリオに基づき実行。 

 Threads: 25
 Loops:10
 Ramp-up:1sec
 Pause: 1sec or 1.5 sec


注:
  • WebDirect 14 および WebDirect 15 のテストデータは前回計測時のものを使用しています。
  • Pause を設けずにシナリオを実行すると、ログアウトを待たずに次々にセッションが実行され、最大同時接続数25を超過するエラーが発生して伝票作成に失敗するため、WD15/WD16 では 1 秒、WD14 では 1.5 秒 の Pause 時間を設けました。両者で 0.5 秒の差があるのは、WD14 を 1 秒で設定すると、同様のエラーが多数したためです。
  • シナリオ実行後は出庫伝票が 250 個作成されていることを目視で確認しています。未作成レコードがある場合、その数を下表の「Fails」列に記載しています。

テスト結果と考察

WD 14、WD15 及び WD16 出庫レコード作成時のパフォーマンス(Fails は作成に失敗したレコード数)

 過去の計測では、エラーによりレコードが作成されないことがありましたが、WebDirect 16 では連続アクセスを行ってもエラーの発生はありませんでした

Peformance comparison graph on CPU cores and memory

※総評

 WD16 は WD15 に比し、2%~35%、実行速度が向上しています。サーバリソースの割り当てを増やすと、その差は顕著になります。
1core/2GBでは WD16 と WD15 間で実行速度の差は 2% とほとんど改善は見られませんでしたが、1core/2GB から 2core/4GB に増やすと 24%、 2core/4GB から 4core/8GB に増やすと35%改善しました。 コア数/メモリの割り当てがチューニングのキーとなる可能性があります。
 ただ、前回テスト時と同様に、リソース割り当てを増やすに従って、その改善率は徐々に鈍化するものと推定されます。
 
※ CPUの占有率

 以下の図は JMeter 実行時の CPU 占有率です。 1コアの場合、CPU を使い切ってしまうことが多々ありました。やはり、CPU 占有率が 100%になるような状況は避けたいです。リソースを増やすに従い、CPU の使用率は下がります。



WebDirect 16


1 Core / 2 GB RAM
WD16 のときと同様に、CPU 占有率が 100% に達する状態が続く。しかも長い。よって同時アクセスユーザが集中する可能性のあるサーバは要注意

2 Core / 4GB RAM
WD15 に比しCPU占有率が高くなっているが、その分占有時間は短くなっている


4 Core / 8GB RAM

WD15に比しCPU占有率が高いが、その分占有時間は短くなっている



WebDirect 15


1 Core / 2 GB RAM
CPU 占有率が 100% に達する状態が続く。同時アクセスユーザが集中する可能性のあるサーバは要注意

2 Core / 4GB RAM


4 Core / 8GB RAM



WebDirect 14

1 Core / 2 GB RAM
長時間にわたり高負荷状態が発生。WD15 や WD16 に比べると処理により多くのサーバリソースを消費することがわかる。

2 Core / 4GB RAM


4 Core / 8GB RAM


まとめ

FileMaker Server 13 がリリースされた頃の WebDirect は動作が不安定で、とても実用に耐えないと評価しましたが、今回は25台の仮想マシンから計250のレコードを一斉作成するテストを5回実行しても一度もエラーが発生しませんでした。 WebDirect は運用に耐えうるレベルに達しつつあるというのが今回の実感です。
 また、WebDirect からの PDF 出力も可能となりましたので、 FileMaker Pro クライアントの代わりに WebDirect を導入するという選択肢も視野に入ってきたように思います。

 ただし WebDirect と数多あるブラウザとの互換性の問題は依然存在しますし、ページをリロードすると画面が初期状態に戻ってしまうという現象も依然として発生します。
 また、WebDirect には不向きな処理(例:バッチ処理)を実行した場合に無応答状態になる可能性も解消したとは言い切れません。 WebDirect の設計に当たっては、通常処理とサーバサイドスクリプトに割り当てる処理の切り分けが重要になるかも知れません。
 WebDirect のクリティカルなシステムへの適用は、十分な設計とテストが必要と思います。

補足情報:拡張アクセス権限の変更について

 FileMaker Server 16 の WebDirect 環境で、 URL にスクリプトを指定して実行する場合は、当該のアカウントの拡張アクセス権限で「FileMaker WebDirect によるアクセス(fmwebdirect)」に加え、 「URL による FileMaker スクリプトの実行を許可(fmurlscript)」を有効にする必要があります。


 このオプションが有効になっていないと、実行時に以下のような権限不足エラーが発生します。


 不特定ユーザが使用する環境においては、この辺りのセキュリティに配慮してプログラムしないといけませんね。



(亀)

2015-12-11

iSCSI を利用したFileMaker Server の冗長構成を考える

 先日の記事で、FileMaker Server 14 オリジナルのスタンバイサーバ機能のテスト環境構築方法についてご紹介しましたが、このスタンバイサーバ機能には、以下のような問題点があります。

  1. プライマリからスタンバイサーバへの切り替えはコマンドライン入力が必要で面倒で、誤操作が発生する可能性がある
  2. 前回保存以降(0~99分間)のデータが失われる

 そこで今回は、上記のスタンバイサーバ機能の代わりに、プライマリ/スタンバイサーバでiSCSIディスクを共有するように設定し、障害時にはサーバ切替を行う冗長構成を考えてみました。

尚、本稿でもプライマリサーバの代替機という意味でスタンバイサーバという言葉を使用しています。 前稿のFileMaker Server 14 オリジナルのスタンバイサーバ機能と混乱しないようにご注意ください。


注意点:

 本記事でご紹介する操作は、動作を保証するものではありません。
 実運用前に社内で入念な動作検証を行い、お客様の責任で導入をお願いします。


 前回構築した仮想マシン二台を流用した iSCSI ドライブ共有モデルがこちらになります。
iSCSI ドライブの共有によるデータベース公開モデル
平常時はスタンバイサーバはiSCSIドライブには接続せず、プライマリサーバがダウンした時にのみ接続する
iSCSI ターゲットに配置されたデータベースファイルを FileMaker Server で公開することによって、緊急時にはスタンバイサーバから同じデータベースファイルにアクセスできるようにします。
 ※スタンバイサーバ側は、初回導入時にプライマリサーバと同様に iSCSI ドライブ内のデータベースを公開できるように設定します。設定後に iSCSI ドライブを切断するため、上図では接続状態を黄色の矢印で示してあります。

プライマリサーバの設定:

 iSCSIターゲット上でデータベース専用ドライブを作成し、プライマリサーバ上にマウントします(下図のEドライブ)。

 このとき、FileMaker Server 14 アプリケーションはCドライブにインストールし、データベースファイルはすべて iSCSI ドライブ(Eドライブ)に配置します。

 たとえば、下図のように iSCSI ドライブを E: ドライブとしてマウント。その中に FmData フォルダを作成して、この中に FileMaker データベースファイル群を配置します。



次に FileMaker Server Admin Console を使用し、上記で作成したデータフォルダが公開されるようにそのフォルダのパスを指定します。

 下図では、filewin:/E:/FmData/ が公開されるように設定しています。
 また、データベースファイル破損時に備えて、バックアップはローカルディスク上に取っておきます。




スタンバイサーバーの設定:

 プライマリサーバで iSCSI を切断し、FileMaker Server を停止させます。
 プライマリサーバの設定内容と同様にスタンバイサーバの設定を行います。

 ※ プライマリサーバの FileMaker Server の動作競合や、iSCSI ディスクへの書き込みエラーを防止するために、スタンバイサーバの設定が終わったら FileMaker Server を停止させて iSCSI 接続を切断しておきます。
 iSCSI の切断後は、スタンバイサーバをシャットダウンします。

正常時の操作


 普段はプライマリサーバのみ稼働させておきます。

プライマリサーバ稼働時の iSCSI 接続状態


緊急時の操作


 プライマリサーバのメンテナンスが必要になったり、プライマリサーバに障害が発生したりした場合は、FileMaker Server を停止させて iSCSI ドライブへの接続を切断します。

 そして、スタンバイサーバから iSCSI ドライブへ接続後に、FileMaker Server を起動します。

スタンバイサーバ稼働時の iSCSI 接続状態

ポイント:
 ― FileMaker Server 14 のサーバ切替コマンド操作が不要な分、サーバのダウンタイムは短縮できますが、プライマリサーバの iSCSI 切断、スタンバイサーバの iSCSI 接続と FileMaker Server 起動までの操作は手動作業になります。

 ― スタンバイサーバはプライマリで運用していたファイルを直接引き続くため復旧時にデータロスは発生しませんが、iSCSIターゲット(ディバイス)の堅牢性が要求されます。RAID6やRAID10などの採用を検討してください。

 ― FileMaker Server 14 以前の FileMaker Server にも応用できます。


とっても重要:

 フルバックアップ及びプログレッシブバックアップにより作成されるバックアップファイルは iSCSI ディスク上ではなく、ローカルディスク及び外部メディアに取ることをおすすめします。

 これにより、iSCSI ターゲット自体が故障した場合に、ローカルディスクにあるバックアップから復旧作業を行えます。
 また、ローカルディスクも同時に損傷しまった場合にも、外部メディアから復旧する手段が残ることになります。






(亀)



2014-05-15

FileMaker Server のプログレッシブバックアップ機能の考え方と使い方

通常バックアップとプログレッシブバックアップの違い


 FileMaker Server の通常バックアップ機能のしくみは、以下のとおりです。



 この場合は 8 時間おき、つまり一日 3 回、データベース全体がバックアップされます。
 この全体のバックアップを取ることをフルバックアップと呼びます。

 上記のように定期的にフルバックアップを取っておけば、たとえばバックアップ 1 を取り終えたあとに重大なデータベース障害が発生したとしても、データベースをバックアップ 1 の状態に戻せば業務を再開できます。

 ただし、この場合、バックアップは最長約 8 時間前の状態に戻ってしまいます。
 このうな場合はその約 8 時間分のデータベース作業を丸ごとやり直さなければならないことになります。

 一日の更新データ量が膨大になる業務の場合、この復旧作業は大変な労力と時間を費やすことになりますし、そもそもデータがもと通りになる保証はありません。
 かと言って、フルバックアップを1時間とか数分に1度実行するように設定すれば、パフォーマンスが低下することは明らかです。

 このような欠陥を補うため、FileMaker Server 12/13 にはプログレッシブバックアップ(Progressive Backup)という機能が搭載されています。

 プログレッシブバックアップを図解すると、次のようになります。



  プログレッシブバックアップでは、データベース全体ではなく更新分のみをバックアップします。これにより、短い時間でバックアップを終了するので、システムのパフォーマンス低下を短い時間に抑えます。上図の例では通常バックアップとは別に60 分おきにプログレッシブバックアップを行っています。


 データベースが損傷しデータベースがダウンした場合、プログレッシブバックアップにより最大 60 分前の状態に戻ってデータベース業務を再開できるようになります。

 ちなみに、プログレッシブバックアップの間隔は 1 分~99分の間で設定できます。


 それでは、プログレッシブバックアップの設定方法と動作確認、データベースの復旧方法について見ていくことにします。


 通常バックアップのスケジュールの考え方と設定方法については、以下の記事をご覧ください。
 前回の記事: データベースのバックアップ方法


本記事の内容は、当方の動作検証結果にもとづくものになっております。
プログレッシブバックアップ機能を検討されている場合は、事前に動作テストを十分に行い、お客様の自己責任で導入していただけますよう、お願いいたします。

プログレッシブ・バックアップの設定方法


 今回は、FileMaker Server 13 を使ったプログレッシブバックアップ機能をご紹介します。
 FileMaker Server 12 でも基本機能は同じですので、設定画面の情報を読み替えてご利用いただけると思います。

 FileMaker 社で公開されているプログレッシブバックアップの日本語ヘルプには誤訳が含まれているため、英語ヘルプをもとに解説していきます。

1.  FileMaker Server Admin Console にログインし、左ペインの「データベースサーバー」をクリックして「フォルダ」タブを選択します。

 そして、画面下部の「プログレッシブバックアップを有効にする」チェックボックスにチェックを付けると、次のようなメッセージが表示されます。



2. 「保存間隔」と、バックアップフォルダへの「パス」を指定します。

 社内の業務方針に応じて妥当な保存間隔を決定する必要がありますが、とりあえず今回は 60 分を設定しておきます。

 プログレッシブバックアップフォルダは、ここでは G: ドライブのバックアップ用フォルダへのパスを設定してみることにします。

 以下が、これらの条件を設定しおわったところです。



データベース運用中のディスクドライブと、プログレッシブバックアップ用のディスクドライブを分散させることにより、FileMaker Server のパフォーマンスが向上します。


3. “保存”ボタンをクリックした直後は、プログレッシブバックアップ用のフォルダには、以下の 3 つのフォルダが自動生成されます。


  • Changes_FMS ― 変更点が記述された .flx 形式のファイル
  • Copies_FMS ― 前回のプログレッシブバックアップ実行時点のデータベースのコピー
  • InProgress_FMS ― 蓄積された更新点が反映されるまで使用される暫定的なデータベースのコピー
重要:これらの 3 つのフォルダは、ユーザには直接無関係のフォルダとなりますので、中身を変更したり、消去したりしないようにしてください。

 設定後しばらくの間は、公開中のすべてのデータベースがこのプログレッシブバックアップ用フォルダの中にバックアップされますので、公開データベースの数や容量によっては、準備が整うまで時間がかかることがあります。


 InProgress_FMS フォルダは、初回のプログレッシブバックアップに成功すると消去され、その代わりに、タイムスタンプ付きの二種類のフォルダが生成されます。



FileMaker Server のプログレッシブバックアップでは、これらの二種類のバックアップコピーが生成されますので、必要に応じてどちらかの状態に復旧させることができます。


 上記では、スクリーンショットを撮る目的でバックアップの間隔を 1分に変更してフォルダを作成したために、05-15-14-37 と 05-15-14-38 という 1 分間の開きがあるフォルダが作成されていますが、間隔を 60 分にすれば、一時間の開きのあるフォルダが作成されることになります。


プログレッシブ・バックアップからのデータベース復旧方法

1. FileMaker Server Admin Console を使って、復旧させたいデータべ―スを閉じます。
 データベースの閉じ方は、以下の画像をご覧ください。



2. 1. で閉じたデータベースを消去します。



3. 前述の「プログレッシブバックアップの設定方法」の手順 3. で作成された、タイムスタンプ付きのフォルダのうち、復旧させたい時点のフォルダを開き、その中から対象となるデータベースファイルを特定して、FileMaker Server の公開データベースフォルダにコピーします。



 上記は、タイムスタンプが 2014-05-15-1511 のフォルダから、FMServer_Sample.fmp12 ファイルを特定したところです。


このフォルダは、定期的に FileMaker Server からアクセスされる性質のものですので、ファイルを特定したら、そのファイルをすぐにデータベースサーバの方にコピーしてください。

IncrementalBackup フォルダの中では、絶対に直接ファイルを開かないようにしてください。

4. 3. でデータベース公開用フォルダに配置したファイルを開きます。



 復旧操作は以上です。
 これによって、データベースファイルの状態が、2014-05-15-1511 時点でのプログレッシブバックアップ状態に戻りました。


【参照データのみ保存しているオブジェクトフィールドのデータはどうなるのか】

 英語版のヘルプによると、オブジェクトフィールドのデータ格納オプションより、「ファイルの参照データのみ保存」で参照先のみを保存している場合は、その実データは、タイムスタンプ付のフォルダの中に生成される RC_Data_FMS というサブフォルダの中にバックアップされるそうですが、当方の実験ではバックアップされていないようです。

 この点については、日を改めて検証したいと思います。


以上

(亀)



関連記事:
データベースのバックアップ方法


参考記事:
プログレッシブバックアップの設定とバックアップからの復元
Setting up, and restoring from, progressive backup (英語)



【関連する土屋企画の講習】
FileMaker Server とバックアップ(対象者:中級、5時間×1日)

2014-05-13

データベースのバックアップ方法


バックアップの重要性


 FileMakerにかぎらず、データベースを運用するうえで日々のバックアップ作業はとてもとても重要です。理由はデータベースが以下のような状況で破損するからです。

 データベースはいつかは必ず破損する!壊れる!ものと思ってバックアップ道に精進しましょう。

  • ユーザによる強制シャットダウン、システム稼働中の電源コード抜き
  • ハードディスクの寿命・故障
  • 電源障害、停電
  • 落雷、地震
  • 怪奇現象(なんの前触れもなく突然壊れる)

 戦略的、かつ定期的にバックアップを行うことにより、データベース破壊時にも最小限のコストで業務を再開できます。

※本稿で使用しているバックアップソフトウェアは FileMaker Server です。 


バックアップスケジュールの考え方


 データベースが破損すると、そのデータベースが関連するすべての社内業務はストップしてしまいます。
 このため、バックアップは最低毎日1回はお取り下さい。バックアップはデータベース管理に関わる者の責務です。

 バックアップがあれば、たとえば火曜日にデータベースが破損しても、月曜日のバックアップを使用し、月曜~火曜の間に更新したデータを再入力することにより業務を再開できるようになります。
 データの一部は再入力できないかもしれませんが、全データを失うよりは遥かにマシです。

 それでは以下の順に作業を進めていきます。


1. バックアップ用のディスクを用意します。

 FileMakerのデータベースファイルが保存されているディスクとは別の物理ディスクを用意してください。
 同一のディスクを使用すると、ディスクが物理的に破損したときにバックアップも一緒に破損してしまうからです。

 バックアップディスクには、外付のハードディスクを使用するのが良いと思いますが、 iSCSIドライブを使用するのも手です。iSCSIドライブであればサーバが起動できなくなっても、他のサーバでiSCSIディスクをマウントできます。 iSCSIドライブとスタンバイサーバがあれば、サーバがデータセンターにあるような場合、管理者はサーバ所在地に行かなくても復旧を行うことができます。

注:
  • FileMaker Serverスケジュールでは、NAS などのネットワークドライブにはバックアップを取れません。 
  • ネットワークドライブにバックアップを取るには、FileMaker Server でローカルディスクに一旦バックアップを行い、その後タスクスケジューラ等で NAS にバックアップを行うバッチを実行させると良いです。

 ここでは、外付けハードディスクにドライブレター F: を割り当てたものを想定します。


2. 日々のバックアップ戦略を考えます。

 バックアップを考えるにあたり、まず以下の2点を考えます。
  1. 頻度
  2. 上書 or 追記

 データ復旧性のことだけ考えるのであれば、1分に1回、常に追記する(以前のバックアップを上書きしない)のが最良でしょうが、頻繁なフルバックアップは実行速度の低下や停止を招きますし、また毎回追記していてはディスク等のバックアップメディアの費用もかかさみます。

 データ復旧性、システムパフォーマンスへの影響、金銭的コストなど、バックアップに関わる様々な事項を検討して、その企業における最適解を得るのがバックアップ戦略です。

 以下、バックアップ戦略の一例です。

  • バックアップは月曜日~日曜日まで毎日個別のバックアップ用ディレクトリに取る
  • 月曜~土曜は前週同曜日分を上書きバックアップする
  • 日曜日は永久保存用に 追記バックアップする(上書しない)


 これを1カ月の表にすると、次のようになります。

上書上書上書上書上書上書永久
上書上書上書上書上書上書永久
上書上書上書上書上書上書永久
上書上書上書上書上書上書永久



【日次バックアップのスケジュール】

 上記のバックアップ戦略に基づき、外付ディスク(F:)に月~土曜用のバックアップフォルダを作成します。



A. 手動による日次バックアップ


 FileMaker Server をお持ちでない方は、毎日の業務終了後に FileMaker データベースを完全に終了させてから、FileMaker データベースの入っているフォルダをそれぞれの正しいバックアップフォルダに正確にコピーしてください。


B. FileMaker Server を使った日次バックアップ

以下では、FileMaker Server 12 を使用し、これらフォルダに対して月~土曜用の上書きバックアップを設定していきます。

 スケジュールアシスタントの、1. タスクの選択~ 3. データベース選択までの操作はここでは省略しますが、業務に合った内容のものを選択してください。


1. たとえば、月曜日のバックアップフォルダ設定は次のとおりとなります。

FileMaker Server の仕様上、ネットワークドライブをバックアップ先に指定することはできません。

 一週間に一度上書きバックアップさせるため、フォルダに保持させるバックアップ数を 1 つに設定しているところに注目してください。



2. バックアップスケジュールを設定します。
 
 月曜日のフォルダに毎週バックアップさせるために、頻度を毎週にします。
 スケジュールは月曜日ですね。

 この例では、一日一回バックアップを取るようにしています。
 バックアップの開始時刻は業務条件によりますが、毎日の終業時間後に取るようにすると、翌日トラブルに見舞われてデータベースが使えなくなったときにも作業を再開しやすいかもしれません。


【応用編】

 日々大量のデータを扱う業務の場合は、朝、昼、晩と 3 回バックアップを取った方が、万が一のデータロスが少なくてすみますので、頻度を決めてバックアップを取るようにするとよいでしょう。
 たとえば以下のように設定すると、7 時間おきにバックアップを取るようにするため、一日で 3 回バックアップが実行されます。



 このような場合は、前の画面に戻り、バックアップの保持数を 3 に変更しておけば、朝、昼、晩と 3 種類のバックアップが 3 種類のフォルダに作成されます。


#ユーザから文句を言われたくなければ、システムがフル稼働する時間帯にバックアップを実行するのは止めましょう。 早朝、昼休、深夜、おやつの時間など、システムの稼働率が低い時間帯を見計らって、こっそりバックアップしましょう。


3. この要領で、月曜日~土曜日までの 6 日分のバックアップ設定をすると、以下のようなリストになります。




 これでバックアップスケジュールを有効にすれば、月~土曜の毎日、バックアップが定時に実行されるようになります。


【永久バックアップのスケジュール】

 日曜日のデータを永久バックアップする方法をご紹介します。

1. 永久バックアップ用には、月~土曜のバックアップディスク(F:)とは別に外部ハードディスクドライブ(または iSCISI)ディスクを用意し、ドライブレターに G: を割り当てました。

 月~土曜と日曜日のバックアップで、2つの外部ディスクを用意するのは、ディスク障害のリスクを分散するためです。


2. G: ドライブの中に日曜日永久バックアップ用のフォルダを一つ作成します。
 たとえば、以下のようになります。



A. 手動による永久バックアップ


 FileMaker Server をお持ちでない方は、日曜日の業務終了後に FileMaker データベースを完全に終了させてから、FileMaker データベースの入っているフォルダを永久バックアップ用のドライブ(例: G: ドライブ)の正しい永久バックアップフォルダに正確にコピーし、フォルダ名に日付を追加してください(例:俺のバックアップ150706、俺のバックアップ150713、俺のバックアップ150720.…)。

 このようにすることにより、日曜日の日付のついたバックアップフォルダを、ディスク容量が一杯になるまで永続的に蓄積していきます。

B. FileMaker Server を使った永久バックアップ


 次に、Windows 版の FileMaker Server 12 を使ってバックアップスケジュールを設定する方法をご紹介します。

スケジュールアシスタントの、1. タスクの選択~ 3. データベース選択までの操作はここでは省略しますが、業務に合った内容のものを選択してください。


1. 日曜日の永久バックアップフォルダ設定は、たとえば次のとおりとなります。

FileMaker Server の仕様上、ネットワークドライブをバックアップ先に指定することはできません。


 バックアップフォルダが G: ドライブの 7日(永久)になっていますね。
 また、永久バックアップは追記型で増やしていきますので、「保持するバックアップの最大値」を最大の 99 に設定します。




 これにより、99 個のバックアップまでは追記型でバックアップフォルダが自動生成されます。

追記できるのが 99 回までなら、その後はどうすんの?

 100回目以降は古いバックアップフォルダから順次上書きされてしまいますから、99 週≒約 2 年を一区切りとして、その後はどうするのか検討しておく必要があります。

 99週を過ぎると、古いバックアップフォルダから順に上書きされていきますから、当然上書きされた分は使用できなくなります。
 そのときは、バックアップディレクトリを変更するか、ハードディスクを交換します。

 ハードディスクは2年壊れず使えればラッキー!と考え、99回を区切りに新しいものに交換するのは、とても良いと思います。


ディスク容量とデータ増も考慮せよ

 データベースの容量は把握していますか?
 1月にデータがどのくらい増えるか把握していますか?
 そのハードディスクで2年間、週1回の追記バックアップ99回分を保持できますか?



2. バックアップスケジュールを設定します。

 スケジュールの指定方法は、日次バックアップと同様ですが、バックアップの頻度は 1 回にします。
 これにより、日曜日(永久)のバックアップは、一週間に一度追記作成されるようになります。


C. FileMaker Server と外部プログラムを併用した永久バックアップ


 FileMaker Server によって毎週作成される日曜日のバックアップフォルダを、外部メディアやネットワークディレクトリに自動コピーするには、以下の方法があります。

  •  指定フォルダをバックアップできるソフトウェアを使い、毎週日曜日の深夜に外部メディアに追記型で世代管理できるようにスケジュールを組む。
  •  コマンドバッチファイル、vbs などのスクリプトを使って永久バックアップフォルダの外部メディアへのコピー条件を指定し、タスクスケジューラに登録して毎週日曜日の深夜に実行されるように設定する。


最後に… 上記で管理者のバックアップは作業は終わりでしょうか? とんでもありません。 管理者は1日1回、設定したバックアップスケジュールが正しく実行されているかどうか、FileMaker Server のコンソール画面等で確認してください。 また、週に一度位は、作成されたバックアップが実際に起動できるか試してみてください。 この確認作業は、バックアップ戦略策定や設定作業以上に重要です。 なぜって、バックアップが実際にできていなければ、立派なバックアップ戦略も無意味ですから。


(亀)


<おまけ> 地震、雷、火事、オヤジ、太陽フレアは?

 建物が被雷した場合、電源の入っているすべてのハードディスクやストレージデバイスが破壊される可能性があります。
 地震、火事、テロではオフィス内のすべてのディスク、オフラインのメディアも焼失/消失する可能性があります。

 定期的にクラウドなどの遠隔地のストレージへのバックアップや、支店支社・銀行貸金庫へのデータの保管を検討してください。

 少し前になりますが、大規模な太陽フレアが起こる、との風説があり(NASAも言っていたので風説ではないかも)、筆者も結構マジメに悩んだことがあります。
 調べてみると、他にも悩んでる人はいました。
 太陽フレア対策として、週に1度、ディスクやメディアにバックアップして、それを電磁波シールド袋で包み金庫に保管とか、本気で考えてる人もいます。

 まぁ、そいつの出番が来る時は、業務継続以前に、現代文明全体が危機に陥っていると思いますが……


関連記事:
FileMaker Server のプログレッシブバックアップ機能の考え方と使い方


【関連する土屋企画の講習】
FileMaker Server とバックアップ(対象者:中級、5時間×1日)