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-06-02

大容量のSQLテーブルもOK! ― FileMaker 16 を帳票作成ツールとして使う

 FileMaker Server 16 (以下、FMS16)ではPDF出力をサポートするようになりました。FileMaker Pro はもともと帳票/レポートを簡単に作成できるツールして利用されてきましたが、サーバサイドでPDFが作成できるようになり、面倒なWeb帳票の設計・実装が実に簡単、且つ短時間のうちに行えるようになりました。 データベースは FileMaker でも SQL/XMLデータベースでもOKです。 本稿では MySQL の1500万件のテーブルからデータを抽出し、遅延無くPDFを出力する方法の概要を記します。

開発・運用環境

FileMaker Pro (Advanced) 16 ― 帳票作成ツール*1
FileMaker Server 16/IIS/PHP ― サーバ*2

 *1 帳票を作り、簡単なスクリプトを書くだけであればFileMaker Pro 16(¥4万前後)で事足りますが、複雑なスクリプトを書くには開発用(デバッガ付)の FileMaker Pro Advanced (¥7万前後)が必要です。
 *2 FileMaker Server 16 はFM社直売で¥99,000 (税抜)です。

 FileMaker Server 16 (の カスタムWeb公開 =CWP)の理論上の最大接続数は 2,000、検証接続数は500 ですので(詳細はこちら)、¥20万弱で本格的な帳票開発・運用環境が構築できる可能性があります。

本稿の目的と概要図

Webブラウザ上でから 入出庫システム(バックエンドはMySQL)にアクセスし、入庫伝票をPDF形式で作成・表示することを目的とします。 帳票を構成するテーブルに1000万件単位レコードが存在する場合にも、ユーザにストレスを与えない程度の実行速度で、入庫伝票PDFを表示することも目指します。以下が実装手法の概要図となります。



実装手法

入出庫明細テーブルには 約1500万のレコードがあります。 FileMaker で数十万件を超すテーブルからデータを抽出してPDF帳票を遅延無く作成するには、上図の FMS ⇔ MySQL 間の設計がキモとなります。今回は一般的な FileMaker ESS(External SQL Source 機能)を使う手法 と、原始的な ODBC データ取込を使う2つの手法を実装・テストしました。

実装手法1 ―  FileMaker ESS を使用  データ件数が多くなると低速化する

  1. 本手法では ESS を使用し、MySQLのテーブルを FileMaker のファイル内に直接配置します。下図の「_入庫」や「_取引先_入庫」などがそれに相当し、これらはシャドウテーブルとも呼ばれます。
    ESSは FileMaker 内から直接 MySQL のテーブルを読み書きでき便利なのですが、数十万行を超す大きなテーブルを扱う時には速度が低下するなどの問題があります。ESSの問題点については、古い記事になりますがこちらを参考にしてください。

  1. 入庫伝票レイアウトの開発は FileMaker Pro (Advanced) のGUIを利用し、テーブル内のフィールドや罫線、テキストなどのオブジェクトを配置しながら作成すると、慣れた人なら 短時間で完成すると思います。  
FileMaker Pro により作成した入庫伝票イメージ

  1. 次に FileMaker のスクリプトメーカーで、PHP から渡ってきた入庫No による検索、入庫伝票レイアウトの選択、PDF保存などを行うスクリプト(「実装手法概要図」の「特定のスクリプト」)を作成します。
  2. 最後に PHPファイルからそのスクリプトを実行するように指定します。

実装手法2 ― ODBCデータ取込 を使用 データ件数にかかわらず高速

  1. 本手法では独立した FileMaker ファイルを一つ用意し、その中に FileMaker のテーブル(vw入庫伝票、下図参照)を用意します。

    このテーブルに MySQL から必要最低限のデータを取り込み、そのデータを FileMaker レイアウトを使用してPDF形式で出力します。

    注:ESS は使用せず、したがって MySQL のシャドウテーブルも配置しません。
  2. MySQL側に入庫伝票に必要なテーブル(本例では、入出庫明細、取引先、入庫、商品の4テーブル)を結合した入庫伝票用ビューを作成します。

    ビューの作成は必須ではありませんが、ビューが無いとFileMaker内に4つのテーブルを用意し、4回SELECTクエリを発行して用意したテーブルに対応するMySQLのテーブルデータを取り込む必要があります。ビューを使用すれば、テーブル、クエリー、取込とも1つ/1回で済むので、実行速度的にも有利です。特別な事情がなければ、ビューを使用しましょう。

  3. FileMaker を使用して入庫伝票レイアウトの作成します。テーブル構成が異なるので実装手法1とはその作成方法は異なりますが、FM開発者にとっては容易な作業と思います。
  4. 次にPHPから渡ってきた 入庫No を使用し、 ビューに対して SELCTクエリーを発行し、結果を vw入庫伝票テーブルに取り込み、入庫伝票レイアウトを選択して、PDFを保存するスクリプトを作成します。
  5. PHPからこの FileMaker スクリプトを実行して、PDFを作成・表示する部分は実行手法1と同様です。

テスト結果

上記2つの手法による実装をブラウザからテストしてみました。HTTPリクエストからPDFが表示されるまでの時間は以下の通りです(テストは各5回ずつ実行し、その平均値を記載しています)。

実装手法1: 77秒
実装手法2: 1.2秒 

 その差は圧倒的でした。シャドウテーブルを配置するESSは、SQLクエリーの発行を FileMaker がすべてやってくれるので便利な反面、膨大なクエリーを発行するため速度低下を招きます。 その点、 ファイル内にESSシャドウテーブルを配置せず、SQL SELECT文を自身で指定し、その結果を FileMaker テーブルに取り込む ODBCデータ取込は大きなSQLテーブルに対しては圧倒的に有利です。

思ったこと

実装手法2であれば、数千万件のデータを持つSQLデータベースの帳票作成環境として、その使用に耐えそうです。 実装手法1は10万~20万件程度のテーブルであれば利用可能と思われます。

本稿では SQLデータベースを取り上げましたが、旧FileMaker Server の Webシステムを温存しつつ、下図のように FMS16 を併行運用し、FMS 16 は PDF出力用サーバとして使用する方法も考えられます。

PDF出力をしたいが、 FM16へのアップグレードはできない場合、検討の価値はあるかと思います。





(土屋)




2017-06-01

MySQL ODBC ドライバインストール時のエラー1918

Windows 2012/2016 にMySQLのODBCドライバ5.3.8をインストールしようとすると、
Error 1918.Error installing ODBC  driver MySQL ODBC 5.3 ANSI Driver...
というエラーが表示される。
対策はVC++ラインタイムをインストールすることだが、Windows のバージョンによって、インストールするバージョンが違うらしい。

Windows Server 2012 の場合→VC++2010ランタイム

Windows Server 2016 の場合→VC++2013ランタイム


参考サイト:


(土屋)

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)」を有効にする必要があります。


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


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



(亀)

2017-04-25

太古の FileMaker システムを延命させる!

 小社では 「売上猫くん 4.0」という自社製パッケージ製品(一部改変)をもう20年程、社内の見積・売上・請求管理システムとして使用しています。 「売上猫くん」は初期には FileMaker 3/4 により開発されたものです。 この太古のシステムは現在、  仮想マシン(Windows Server 2008)上のFileMaker Server 5.5 で公開され、Windows 10 を含む最新のWindows 機上のFileMaker Pro 5.5/6 から毎日アクセスされて使用されています。
 小社同様、FileMaker 5.x/6.0 でシステムを運用している企業・組織は一定数あり、当方の客先にも何社かはそのようなところがあります。
 このような FileMaker のレガシーシステムを運用する場合、まずネックとなるのがハードウェアの老巧化や故障によるリプレイスです。 本稿では「FileMaker レガシーシステムの仮想化による延命方法」を小社の客先である某社を例にご紹介します。

1. 某社の状況

1998年: 某社より生産・購買・販売・在庫管理システムの開発業務を受注。FileMaker 4 により開発を開始。数ヶ月後に首尾よくリリースに漕ぎ着ける。某社本社の Macintosh 上に FileMaker Server 5.5 を配置し、NTTの専用線  Digital Access による WAN を介して複数拠点で運用を開始。

2001年: FileMaker 5.5 へアップグレード。fmj から  fp5 へのファイル構造の変換が伴うアップグレードにも関わらず、難なく終了。 この際、サーバを Windows Server 2000 に変更。

2008年*1: Windows Terminal Service (後のRemote Desktop Service)を導入し、FileMaker Pro 5.5 をインストール。拠点のユーザはこのサーバ上の FileMaker クライアントを実行することにより、アプリの実行速度を改善。この際、FileMaker Serverを運用するサーバ機も Windows Server 2008 に変更(参考記事)。さらに、ネットワークの高速化とコスト低減を目的に Digital Access から インターネットVPN へ変更。  インターネットVPNへの変更に伴うセキュリティ上のリスクへの備えとして、SonicWALL による IPS 、Gateway Antiviurs 等も併せて導入。

導入以来、数多の仕様変更を繰り返しながら、現在もFileMaker 5.5 の環境で運用中。

*1
2008年当時、小社内で Windows Server 2008 と FileMaker Server 5.5 の組み合わせによる運用実績はあったのですが、このようなレガシーシステムの運用はベンダーによる動作保証の対象外となることを事前に客先に十分説明しなければなりません。 レガシーシステムの延命は客先のリスクに関する理解と許容が重要だと思います。

2. さらなる延命へ

2008年に導入した RDSサーバですが、経年劣化によるリプレイスを検討するように、客先に数年前からお願いしていたところ、先ごろ、ようやくリプレイス案を出すように求められました。 ただ、運用実績のある Windows Server 2008 は既に発売中止になっていました。そこで以下のような図と共に提案書を客先に提出しました。

仮想環境はWindows Server 2012/2016 Standard 付属のHyper-V(ゲストOSが2ライセンス付属)

A案は単純リプレイス型ですが、新サーバを導入し、そこに現行のOS(Windows Server 2008)をインストールし、RDTアカウントやFileMakerが動作する環境を新たに構築し直す、というものです。 問題となるのは、前述のように Windows Server 2008 に公式対応するサーバ機が2017年現在ほとんど存在しないので、それを覚悟の上での実装となります(参考:Microsoft社のサポート期限一覧)。

B案は現行サーバを P2V (Physical to Virutal)し、これを Hyper-V 2.0 で運用するというものです。これが上手くいくと 旧サーバのハードディスク情報をそのまま仮想マシン化でき、OSやアカウント情報の再構築・再設定が不要になるので、大変便利です。 半面、まったく異なるハードウェア環境へ移動することになるので、各種ドライバでエラーが発生したり、悪くすると初回起動時にブルースクリーンが表示されたりします。 安定運用期に入るまで気をぬけません。

C案は 新規にWindowsサーバを導入、ゲストOS も新たに作成し、その上にRDTアカウント等の再度設定しなおすものです。ゲストOS上での作業はほとんどA案と同様になります。P2Vに比べハードウェアの差異によるエラーやブルースクリーンやらの可能性はほぼなくなりますが、すべて一からの作業となります。

 提案書と概算見積をご提示した後に打ち合わせをしました。結果、サーバ故障時やリプレイス時に仮想マシンであれば迅速に復旧可能であることも勘案し、Windows Server 2016 を使用したB案で進行することになりました。ただ前述のように P2Vが失敗するリスクがあることをご説明し、B案不首尾の場合は、A案、C案、さらには Windows Server 2016 の 2012 へのダウングレード(D案*2) もバックアップとしてご提示しました。

*2
D案の提案理由は  SATO のあるラベルプリンタが Windows Server 2012 へは公式対応している一方、Windows 2016 に非対応であることによります。重要な周辺機器との互換性もレガシーシステムの延命を行うときには“要注意”となります。

3. テスト環境での実装

新しいサーバ機の納品までしばらく時間があるため、客先の旧サーバを予め P2V してVHD(X)にし、当方の Windows Server 2016 の Hyper-V に入れ、事前にテストを行いました。仮想マシンを起動するとエラーイベントが複数発生していたので、一つ一つ潰していきました。 次に FileMaker Pro 5.5 (以下、FM5.5)を起動してテストを実施。 下図のようにクライアントPCから仮想サーバにRD接続。 FM5.5 を使用し FileMaker Server 5.5 (以下、FMS)上の12万件のデータが入った郵便番号ファイルを開き、ソートを実行・・・ 「ん? 」、なんかかなり遅い感じ。

確認のため、仮想サーバではなく、別の物理マシンのRDS から郵便番号ファイルにアクセス(クライアントPC→物理マシンRDS+FMP→FMS)すると、なんと3倍!速い。 クライアントPC→Win Server 2016 RDS+FMP→FMSで実行してもやはり3倍速い。

 ならば、仮想サーバ上に郵便番号.fp5 を配置して、ネットワークを介さずローカルで実行するとどうか? 一瞬 = 数秒~10秒程度!で終了してしまいます。 ということで、仮想サーバの通信速度(上図の「FMP⇔FMS接続」)に問題があることが判りました。 実はここからがすごく大変で、 「Hyper-V ゲストOS 遅い」や「Hyper-V Guest OS slow」などをキーワードに、数日間、ググって試す、ググって試すを繰り返しました。 ググってまず最初に出てくるのが、NICの仮想マシンキュー(VMQ、Virtual Machine Queue)を オフ にせよ、というもの。これは内外のいろいろなところで書かれており、小社の別のHyper-V環境下のゲストOSでは劇的な効果があったのですが、今回の仮想マシンについては全く効果無しでした。 NICの「IPV4チェックサムオフロード」をオフにしろ、という記事も多く見かけましたがこれもダメ。
NICの設定は、ホスト側からだけではなく、仮想マシンからもいじってみましたがうまくいかず。
万策尽きたか、と思ったところで、突然光明が差しました。 それは、「レガシーネットワークアダプタ」の使用(下図)。



 仮想マシンのネットワークアダプタを作成する際、「ハードウェアの追加」を選択。この時、通常は「ネットワークアダプタ」が推奨されますが、ここで「レガシ ネットワーク アダプター」を図のように選んで“追加”します。 これを行うことにより、

ping -l 60000 hostname

の応答時間も劇的に改善し、12万件の郵便番号ソートも劇的に速くなりました。

 今回のゲストOSは Windows Server 2008 で、このOSは Hyper-V の「統合サービス」に対応しているので、上図では「ネットワーク アダプター」を選択するのがセオリーだと思うのですが、、、
ネットで調べてもレガシはオバーヘッドが多いので、「ネットワークアダプター」を使いなさいという記事しか見当たらりませんでしたが、レガシーのままテストを続行することにしました。

尚、上記の記事に関する後日談はこちらをご覧ください。


(土屋)


追記
「売上猫くん3.0」は1997年に FileMaker Pro 3 により開発されたものですが、 いまだにご愛用頂いているお客様がいらっしゃいます。 ただ、ハードウェアの老巧化の問題があるのでできる限り新バージョンへのアップグレードをお勧めしてます。 それはそれとして、 FileMaker Pro 3/4 のシステムを Windows NT 4.0 の仮想マシンで運用するというのは、実際やったことはありませんが、チャレンジしてみたい気もします。


■ FileMaker 5/6等レガシーシステム関連記事

まだまだいける FileMaker 5.5/6 ― レガシーFileMaker の延命 2021 ―(21/07/24投稿)
レガシーFileMaker とOSの互換性、移行時の留意点について

IIS6 + FileMaker Web コンパニオン構成の Web サーバ機で TLS1.2 が動作するようにリバースプロキシを設定する (20/07/06投稿)
TLS1.2 非対応の IIS6 に Web ブラウザアクセス時に警告メッセージが出ないようにする

太古の FileMaker システムを延命させる! ― 後日談FileMaker(17/09/07投稿)
下記記事のレガシー延命スキームの実施と結果について。

太古の FileMaker システムを延命させる!(17/04/25投稿)
Remote Desktop Server/FileMaker Pro 5.5 搭載の Windows Server 2008 物理マシンを P2Vし、Hyper-Vに移行することにより、レガシーシステムの延命を図る。

FileMaker 5.5/6 をモバイルで使う(16/05/25投稿)
Android/iOS に Remote Desktop Client を載せて、FileMaker Go のようなことをしてみます。

今なお輝くFileMaker 5.5/6(16/05/23投稿)
レガシーFileMaker の意外な利点。


参考リンク:
物理マシンを Hyper-V 仮想マシンに移行する(P2V)
Performance Tuning for Hyper-V Servers
Hyper-V network adapter differences
Windows Server 2012 Hyper-V の SR-IOV 構築手順 (1)

2017-01-23

Google サイト(Google Sites)をバックアップする方法

 Google サイトを使っていらっしゃる方は、サイトのバックアップをどうするか悩むところかと思います。

google-sites-liberation で公開されているツールは動かない


  ツールの最新版は、2011/04/27 で google-sites-liberation-1.0.4.jar  の公開が終わっています。

google-sites-liberation で公開されているツールの一覧

  しかしながら、google-sites-liberation-1.0.4.jar を実行すると、以下の認証エラーが出ます。

google-sites-liberation-1.0.4.jar を実行すると表示される認証エラー

GitHub からツールの最新版をダウンロードしてバックアップする


  google-sites-liberation - issue #107 (ソースは英語)を確認すると、https://github.com/sih4sing5hong5/google-sites-liberation の方で開発が続行しているので、そちらを確認します。


 操作手順は次のとおりです。

 1. Google Sites Import/Export Tool のセクションからツールをダウンロードします。
 最新バージョンは 1.0.6 です(2017/01/23 現在)。

Google Sites Import/Export Tool のダウンロード

 2. google-sites-liberation-1.0.6-jar-with-dependencies.jar がダウンロードされますので、ダブルクリックで実行します。
 実行にあたっては事前に Java をインストールしておく必要があります。

 
Google Sites Import/Exportツール


 3. 必要事項を入力してから、“Get a token from browser” をクリックします。
 すると、google がユーザ許可を求めるページが表示されますので、“許可”ボタンをクリックします。
 ※事前に Google アカウントにログインしておく必要があります。


google-sites-liberation のアクセスを許可する

 4. トークンが発行されますので、クリップボードにコピーします。

表示されたトークンをクリップボードにコピー

 5. コピーしたトークンをツールに貼りつけてから、“Export from Sites” をクリックすると、バックアップが始まります。


 ※当然のことながら、トークンには有効期限があります。トークンが無効になった場合は、“Get a token from brower”をクリックすることによって、トークンを取得しなおしてください。

 6. Export Complete が表示されたらバックアップ完了です。



 その他のバックアップツールとして、弊社では WinHTTTrack を使用していますが、このツールの使い方については、また機会をあらためてご紹介したいと思います。