このセクションでは、オリジナルのインスタンスがTCOMMITの後で失敗する例を使用して、システムが応答を生成してクライアントに送信する前に、うまく設計されたメッセージング・システムがアプリケーションのアーキテクチャーをより切り詰めにする方法を説明します。

前のセクションで説明したように、オリジナルのインスタンスのアプリケーション・サーバーは、階層環境でのオンライン操作のためにネットワーク経由で配信されたクライアントからのメッセージに応答します。各クライアントメッセージは、サーバー上でゼロ（照会）または更新トランザクションを発生します。ネットワーク配信メッセージは堅牢でなければならない。つまり、各メッセージは、オリジナルのインスタンスのアプリケーション・サーバーに正確に1回配信されるか、配信失敗のクライアント通知になります。メッセージング・システムは、クライアントがメッセージを送信した後、オリジナルのインスタンスがメッセージを受信する前に、オリジナルのインスタンスでの障害などの状況を処理する必要があります。インスタンスがオリジナルのインスタンスであるか、またはインスタンスを複製しているかをいつでも決定する論理にメッセージ配信システムを統合することにより、リスクが軽減され、時間の経過とともに切り替わります。

アプリケーションロジックは通常、トランザクションのTCOMMITの直後に生成された応答でクライアントメッセージに応答します。アプリケーションとメッセージアーキテクチャは、TCOMMITの後で、システムが応答を生成してクライアントに送信する前に、オリジナルのシステムが失敗するシナリオを処理する必要があります。このようなシナリオでは、クライアントは応答を待って最終的にタイムアウトし、メッセージを再試行します。

LMSアプリケーションは、メッセージ構造に一意のメッセージ識別子（MSGID）を設定し、アプリケーションがTCOMMITの一部としてデータベースにMSGIDを含めるように設計することで、この状況を処理できます。

もしオリジナルのインスタンスがトランザクションをコミットした後にクラッシュすると、オリジナルのレプリケートインスタンスが新しいオリジナルのインスタンスになります。この新しいオリジナルのインスタンスは、クライアントから同じMSGIDを持つ再試行されたメッセージを受け取ります。この場合、次のいずれかが発生する可能性があります：

GT.Mは、インスタンスの生成操作または複製操作に関する決定を行いません。アプリケーションの起動時にインスタンスを現行のオリジナルのインスタンスとして識別するには、明示的に -ROOTPRIMARYを指定する必要があります。

継続的に利用可能な堅牢なアプリケーションを実装するには、各アプリケーション・インスタンスが正しい状態になる必要があります。具体的には、任意の時点で1つの発信インスタンス（-ROOTPRIMARY）が正確に存在する必要があります。レプリケートされたデータベースに対するすべてのデータベース更新操作は、オリジナルのインスタンスで行われなければなりません。LMSは、オリジナルのインスタンス以外のインスタンスで独立した論理データベースの更新を禁止します。

	注意
	MUPIP BACKUP -ONLINE および MUPIP REORG -ONLINE は、論理データベースの内容ではなく、制御情報または物理的表現を更新し、複製インスタンスで自由に動作できます。

TLSを使用するには、通信相手が互いに認証する必要があります。もし認証が成功すると、通信相手相互は後続の通信を暗号化する。TLS認証は、認証局（CA）によって署名された証明書を使用します。認証局の証明書自体は、最終的に自身の証明書に自己署名するルートCAにつながる他のCAによって署名（および信頼）されます。OpenSSLなどの証明書のトピックやソフトウェアの使用は、GT.Mのドキュメントの範囲をはるかに超えていますが、以下の手順では、自己署名付きルートCA証明書を使用したソースとレシーバーの証明書を使用したテスト環境のクイックスタート作成を示します。

ルート認証局を作成するには、3つの手順が必要です。

この時点で、ca.crt は、他の証明書（中間の証明機関を含む）に署名するために使用できるルート証明書です。ルート証明書の秘密鍵は、不正アクセスから保護する必要があります。

ルート証明書は、通常のリーフレベルの証明書に署名するために使用されます。以下は、GT.Mレシーバ・サーバでGT.Mソース・サーバを認証するために使用される証明書の作成（およびその逆）を示す手順です。

	重要
	自己署名入りのルート証明機関とリーフレベルの証明書は安全な場所に保管してください。許可されていないユーザーがアクセスできないように、0500のパーミッションと0400のパーミッションを持つ個々のファイルでディレクトリを保護します。

中間CA、Diffie-Hellmanパラメータ、証明書失効リストなどを作成する方法については、OpenSSLドキュメント http://www.openssl.org/docs/ を参照してください。

構成ファイルは、データベース暗号化セクションとTLSセクションの2つのセクションに分かれています。データベース暗号化セクションには、データベースファイルと対応するキーファイルのリストが含まれ、TLSセクションには、PEM形式のルート証明機関証明書と対応する秘密キーファイルを含むリーフレベル証明書の場所を示すTLSIDラベルが含まれます。gtmcrypt_config 環境変数を使用するには、libconfigライブラリをインストールする必要があります。

自己署名付きルート証明書によって署名されたリーフレベル証明書を作成した後、以下の形式で構成ファイル（ソース用とレシーバー用）を作成します。

tls: {
     verify-depth: 7;
     CAfile: "/path/to/ca.crt";
     tls : {
           format: "PEM";
           cert: "/path/to/client.crt";
           key: "/path/to/client.key";
     };
};

tls は、ソース / レシーバー・サーバーの起動に使用されるTLSIDを指定し、 CAfile はルート証明機関へのパスを指定し、 cert はリーフレベル証明書へのパスを指定し、 key は秘密キーファイルへのパスを指定します。

環境変数 gtmcrypt_config を設定ファイルへのパスを指すように設定します。環境変数 gtmtls_passwd_ <tlsid> は、クライアントの秘密鍵の難読化されたバージョンのパスワードを指定する必要があります。GT.Mディストリビューションで提供されている maskpassユーティリティを使用して、難読化されたパスワードを作成します。

サンプル構成ファイルは次のとおりです：

/* Database encryption section */
 
database: {
      keys: (
            {
                  dat: "/tmp/mumps.dat";  /* Encrypted database file. */
                  key: "/tmp/mumps.key";  /* Encrypted symmetric key. */
            },
            {
                  dat: "/tmp/a.dat";
                  key: "/tmp/a.key";
            },
            ...
      );
}
 
/* TLS section */
 
tls: {
      /* Certificate Authority (CA) verify depth provides an upper limit on the number of CAs to look up for verifying a given
       * certificate. The depth count is described as ''level 0:peer certificate'', ''level 1: CA certificate'',
       * ''level 2: higher level CA certificate'', and so on. The default verification depth is 9.
       */
      verify-depth: 7;
 
      /* CAfile: points to a file, in PEM format, describing the trusted CAs. The file can contain several CA certificates identified by:
       * -----BEGIN CERTIFICATE-----
       * ... (CA certificate in base64 encoding) ...
       * -----END CERTIFICATE-----
       * sequences.
       */
      CAfile: "/home/jdoe/current/tls/certs/CA/gtmCA.crt";
 
      /* CApath: points to a directory containing CA certificates in PEM format. The files each contain one CA certificate. The files are
       * looked up by the CA subject name hash value, which must hence be available. If more than once certificate with the same
       * name hash value exists, the extension must be different (e.g. 9d66eef0.0, 9d66eef0.1 etc). The directory is typically
       * created by the OpenSSL tool 'c_rehash'.
       */
      CApath: "/home/jdoe/current/tls/certs/CA/";
      
      /* Diffie-Hellman parameters used for key-exchange. Either none or both have to be specified. If neither is specified, then
       * then the data is encrypted with the same keys that are used for authentication.
       */
      dh512: "/home/jdoe/current/tls/dh512.pem";
      dh1024: "/home/jdoe/current/tls/dh1024.pem";
 
      /* crl: points to a file containing list of revoked certificates. This file is created by the openssl utility. */
      crl: "/home/jdoe/current/tls/revocation.crl";
 
      /* Timeout (in seconds) for a given session. If a connection disconnects and resumes within this time interval, the session
       * is reused to speed up the TLS handshake. A value of 0 forces sessions to not be reused. The default value is 1 hour.
       */
      session-timeout: 600;
 
      /* List of certificate/key pairs specified by identifiers. */
      PRODUCTION: {
            /* Format of the certificate and private key pair. Currently, the GT.M TLS plug-in only supports PEM format. */
            format: "PEM";
            /* Path to the certificate. */
            cert: "/home/jdoe/current/tls/certs/Malvern.crt";
            /* Path to the private key. If the private key is protected by a passphrase, an obfuscated version of the password
             * should be specified in the environment variable which takes the form gtmtls_passwd_<identifier>. For instance,
             * for the below key, the environment variable should be 'gtmtls_passwd_PRODUCTION'.
             * Currently, the GT.M TLS plug-in only supports RSA private keys.
             */
            key: "/home/jdoe/current/tls/certs/Malvern.key";
      };
 
      DEVELOPMENT: {
            format: "PEM";
            cert: "/home/jdoe/current/tls/certs/BrynMawr.crt";
            key: "/home/jdoe/current/tls/certs/BrynMawr.key";
      };
};

もし 環境変数 gtm_dbkeys を使用してデータベース暗号化用のマスター・キー・ファイルを指している場合は、できるだけ早く$gtmcrypt_config 環境変数が指すように libconfig 設定ファイル形式に変換してください。効果的なV6.1-000では、gtm_dbkeys環境変数とそれが指すマスター・キー・ファイルは、gtmencrypt_config環境変数を使用して非推奨になりました。V6.1-000はデータベースの暗号化に $gtm_dbkeysの使用をサポートしていますが、FISは近い将来にサポートを中止する予定です。マスター・キー・ファイルを libconfig 形式の設定ファイルに変換するには、CONVDBKEYS.mのダウンロードをクリック して、CONVDBKEYS.mプログラムをダウンロードし、プログラムファイルの先頭にあるコメントの指示に従ってください。http://tinco.pair.com/bhaskar/gtm/doc/articles/downloadables/CONVDBKEYS.m からCONVDBKEYS.mをダウンロードすることもできます。

インスタンスが停止すると、その回復は少なくとも2つのステップから構成されます： インスタンス自体のリカバリ：ハードウェア、OS、ファイルシステムなど - t_sys と呼ぶ。 t_sys はGT.Mジャーナリングのタイプとはほぼ完全に独立しています^[4] 。

データベース回復の場合：

t_bck は t_fwd よりも小さいため、 t_sys+t_bck は t_sys+t_fwd より小さいです。だいたいの概数で、t_sys は数分から数十分で、t_fwdは数十分で、tbckは数秒から数分です。したがって、BEFORE_IMAGEジャーナリングでNOBEFORE_IMAGEジャーナリングよりもインスタンスAを回復することは（粗い最初の近似に）半分程度速くなる可能性があります。2つの展開構成を検討してください。

	注意
	今後のLMX機能を利用できるアプリケーションは、適切なフロント・エンド・ネットワークで使用すると、基本的に tswch をゼロにします。