弊社ではアマゾンウェブサービス(以下、AWS)のサービスを利用して、
クラウド上でClaris FileMaker Serverを運用しております。

サーバーを運用していると、トラブル対応や各種検証の為にサーバーの復元を行うことがあります。

AWSでサーバーを復元する方法はいくつか考えられますが、
Amazonマシンイメージ(以下、AMI)を取得して復元サーバーを構築した際、
以下のようなトラブルに遭遇しました。

・ホストされているはずのデータベースに接続できない
・Admin Consoleで状況を確認しようとすると
　「データベースサーバーが実行されていません」
　と表示されて操作できない
・データベースサーバーを起動させようとしても失敗する

そこで今回は、実際に発生したトラブルの様子と、
それに対してどのような対応を行ったかをご紹介したいと思います。

0.前提

・AWSのElastic Compute Cloud(以下、EC2)でサーバーを構築し運用中

・サーバーのOSはWindows Server 2019

・Claris FileMaker Serverのバージョンは19.5

・カスタムSSL証明書をインポートして利用中

・サーバーのAMIを予め取得済み

・AMIから新しくEC2インスタンスを構築することでサーバー復元

1.事象

AMIから復元したEC2インスタンスにClaris FileMaker Proからアクセスしたところ、
接続することができませんでした。

Claris FileMaker Server Admin Console(以下、Admin Console)にアクセスしてみると、
Admin Consoleのサインインページは正常に開きます。

しかし、管理者アカウントでサインインしたところ、
「データベースサーバーが実行されていません。」
というエラーメッセージが表示されてしまいました。
また、ここで「データベースサーバーの起動」をクリックしても一向に変化がありません。

「データベースサーバー」はデータベースをホストする役割のプロセスです。
こちらが何らかの原因で正常に起動できないため
データベースがホストされず、Admin Consoleの操作もできないようです。

サーバーにリモートデスクトップ接続を行い、状況を確認してみます。
Claris FileMaker Serverの「Event.log」を確認したところ、
サーバーが復元された後、自動でサービスが起動する時や、
Admin Consoleサインイン後の「データベースサーバーの起動」をクリックした時に、
以下のエラーログが検出されていました。

　エラー　701　Database Server プロセスは異常終了しました。

サービスの状況を確認したところ、サービスとしての「FileMaker Server」は実行中でした。

しかし、タスクマネージャーで実行されているプロセスを確認すると、
データベースサーバープロセスである「FileMaker Server」プロセスが見つかりません。

2.対応

データベースサーバーをエラー無く正常に起動できないか、検証してみました。

「FileMaker Server」サービスの再起動を行ってみましたが、特に状況は変わりませんでした。
また、サーバー自体の再起動も行いましたが、やはり状況は変わりません。

ここで、何かがデータベースサーバープロセスの起動を邪魔しているのではないかと考え、
Claris FileMaker Serverに関するファイルを退避してサービスを再起動したところ、
「serverCustom.pem」というファイルを退避した場合に正常にプロセスが起動するようになりました。

詳細な手順を以下に記載します。

「FileMaker Server」サービスを停止させます。

Claris FileMaker Serverをインストールしているディレクトリの「CStore」フォルダを開きます。
(Claris FileMaker Serverをデフォルトの場所にインストールしていた場合のパスは
“C:\Program Files\FileMaker\FileMaker Server\CStore”　です。)
この中の「serverCustom.pem」というファイルを別の場所に移動し退避させます。

「serverCustom.pem」が「CStore」フォルダに存在しない状態で、
「FileMaker Server」サービスを開始します。

タスクマネージャーを見てみると、「FileMaker Server」プロセスが実行されるようになりました。
また、データベースが開かれていないと意味が無いため気にしていませんでしたが、

サーバー側でスクリプトを実行するための「FileMaker Script Engine」や、
ODBC/JDBCのデータソースとして使用するための「FileMaker xDBC Listener」といった、
実行されていなかった他のプロセスも動くようになりました。

この状態でAdmin Consoleを開き管理者アカウントでサインインしたところ、
ダッシュボードが正常に開き操作できることが確認できました。

「serverCustom.pem」はカスタムSSL証明書のファイルのため、
退避したことによりカスタムSSL証明書の設定が解除され、Clarisデフォルト証明書が設定されています。

カスタムSSL証明書を再インポートします。
念のため一度「ファイルを削除」をクリックして、余計なファイルが無い状態にします。

利用していたカスタムSSL証明書やプライベートキーファイル、中間証明書ファイルを用意して、
「カスタム証明書のインポート」をクリックします。

用意した各ファイルを指定してパスワードを入力し、「インポート」をクリックします。

証明書が正常にインポートされた表示が出たら「OK」をクリックし、Admin Consoleを閉じます。

「FileMaker Server」サービスの再起動を行います。

サービスの再起動が完了したら、Claris FileMaker Proでアクセスができるか、
Admin Consoleを開いて操作できるか等の動作確認を行います。
正常動作が確認できたら対応完了です。

なお、SSL証明書を正常に再インポートできたら、
退避していた「serverCustom.pem」は削除してしまって大丈夫です。

3.まとめ

今回のトラブルが発生する詳細な原因は現在判明しておりません。

ただ、まずは対処方法がわかったので、AWSのAMIからサーバーを復元する際には、
カスタムSSL証明書の再インポート作業が発生することを念頭に置き、
いざトラブルが起きても焦らず対処できるように備えようと思います。

今回の事象や対応の紹介が、少しでも何かお困りの方の参考になれば幸いです。