次の方法で共有

Azure NetApp Files のアプリケーションの回復性に関する FAQ

  • [アーティクル]

この記事では、Azure NetApp Files のアプリケーションの回復性についてのよくあるご質問 (FAQ) に回答します。

ストレージ サービスのメンテナンス イベントによって発生する可能性のあるアプリケーションの中断に対処するために推奨されることは何ですか?

Azure NetApp Files では、時々、計画メンテナンス (プラットフォームの更新、サービスやソフトウェアのアップグレードなど) が行われることがあります。 ファイル プロトコル (NFS/SMB) の観点からは、これらのイベント中に一時的に発生する可能性がある IO の一時停止をアプリケーションで処理できる限り、メンテナンス操作による中断はありません。 I/O の一時停止は通常、数秒から 30 秒程度の短い時間です。 NFS プロトコルは特に堅牢で、クライアントとサーバー間のファイル操作は通常通り行われます。 一部のアプリケーションでは、30 秒から 45 秒程の IO の一時停止に対応するためのチューニングが必要な場合があります。 そのため、ストレージ サービスのメンテナンス イベントに対処するために、アプリケーションの回復性設定を確認するようにしてください。 SMB プロトコルを利用する、ユーザー介入型のアプリケーションの場合は、通常、標準のプロトコル設定で十分です。

重要

回復性の高いアーキテクチャを確保するには、クラウドが "共有責任" モデルで運用されていることを認識することが重要です。 このモデルには、Azure クラウド プラットフォーム、そのインフラストラクチャ サービス、OS レイヤー、アプリケーション ベンダーが含まれます。 これらの各コンポーネントは、ストレージ サービスのメンテナンス イベント中に発生する可能性のある潜在的なアプリケーションの中断を適切に処理する上で重要な役割を果たします。

SMB ベースのアプリケーションには、特別な予防措置を講じる必要がありますか?

はい。特定の SMB ベースのアプリケーションでは、SMB 透過フェールオーバーが必要です。 SMB 透過フェールオーバーを使用すると、SMB ボリュームにデータを格納してアクセスするサーバー アプリケーションへの接続を中断することなく、Azure NetApp Files サービスでメンテナンス操作を行うことができます。 特定のアプリケーションの SMB 透過フェールオーバーをサポートするために、Azure NetApp Files では、SMB 継続的可用性共有オプションがサポートされるようになりました。 SMB 継続的可用性の使用は、次を使用するワークロードでのみサポートされます。

注意事項

カスタム アプリケーションは SMB 継続的可用性ではサポートされておらず、SMB 継続的可用性が有効なボリュームでは使用できません。

IBM MQ を Azure NetApp Files で実行しています。 NFS プロトコルを使用しているにもかかわらずストレージ サービスのメンテナンス イベントによって発生する中断を回避するには、どのような予防措置を講じることができますか?

IBM MQ アプリケーションを共有ファイル構成で実行しており、IBM MQ データとログが Azure NetApp Files ボリュームに保存されている場合、ストレージ サービスのメンテナンス イベント時の回復力を高めるために、以下の考慮事項が推奨されます。

Note

各 MQ マルチインスタンス ペアが処理する必要があるメッセージの数は、ユーザーごとの特定の環境に大きく依存します。 ユーザーは、必要な MQ マルチインスタンス ペアの数や、スケールアップまたはスケールダウン ルールの内容を決定する必要があります。

スケールアウト アーキテクチャでは、Azure Load Balancer の背後に複数の IBM MQ マルチインスタンス ペアがデプロイされています。 IBM MQ と通信するように構成されたアプリケーションは、Azure Load Balancer を介して IBM MQ インスタンスと通信するように構成されます。 共有 NFS ボリューム上の IBM MQ に関連するサポートについては、IBM でベンダー サポートを受け取る必要があります。

LevelDB または KahaDB を使用して Apache ActiveMQ を Azure NetApp Files で実行しています。 NFS プロトコルを使用しているにもかかわらずストレージ サービスのメンテナンス イベントによって発生する中断を回避するには、どのような予防措置を講じることができますか?

Apache ActiveMQ を実行している場合は、Pluggable Storage Locker 付きの ActiveMQ High Availability を導入することをお勧めします。

ActiveMQ の高可用性 (HA) モデルを使用すると、ブローカー インスタンスが常にオンラインで、メッセージ トラフィックを処理できることが保証されます。 ActiveMQ の HA モデルで最も一般的なものは、ネットワーク上でファイルシステムを共有するものです。 これは、アクティブおよびパッシブなブローカー インスタンスに、LevelDB または KahaDB のいずれかを提供することが目的です。 これらの HA モデルでは、LevelDB または KahaDB ディレクトリ内のファイルに対して、"ロック" と呼ばれる OS レベルのロックを取得して維持する必要があります。この ActiveMQ HA モデルには、いくつかの問題があります。 まず、レプリカがファイルをロックできることを認識していない、"マスター不在" の状況になる可能性があります。 また、インデックスやジャーナルが破損し、最終的にメッセージが失われてしまう "マスターマスター" 構成につながる可能性もあります。 これらの問題の多くは、ActiveMQ の制御外の要因に起因します。 例えば、NFS クライアントの最適化が不十分だと、負荷がかかったときにロックされたデータが古くなり、フェールオーバー時に "マスターなし" のダウンタイムが発生する可能性があります。

この HA ソリューションに関する問題の大部分は、OS レベルの不正確なファイル ロックに起因しているため、ActiveMQ コミュニティにより、ブローカーのバージョン 5.7 で Pluggable Storage Locker という概念が導入されました。 この方法を使用すると、ユーザーは OS レベルのファイルシステム ロックではなく、行レベルの JDBC データベース ロックを使用することで、異なる共有ロックの手段を利用することができます。 ActiveMQ の HA アーキテクチャやデプロイに関するサポートやコンサルティングについては、Perforce が提供する OpenLogic にお問い合わせください。

LevelDB または KahaDB を使用して Apache ActiveMQ を Azure NetApp Files で実行しています。 SMB プロトコルを使用しているにもかかわらずストレージ サービスのメンテナンス イベントによって発生する中断を回避するには、どのような予防措置を講じることができますか?

業界での一般的な推奨事項は、CIFS [Common Internet File System]/SMB 上で KahaDB 共有ストレージを実行しないことです。 正確なロック状態の維持に問題がある場合は、より信頼性の高いロック メカニズムを提供する JDBC Pluggable Storage Locker をチェックしてください。 ActiveMQ の HA アーキテクチャやデプロイに関するサポートやコンサルティングについては、Perforce が提供する OpenLogic にお問い合わせください。

Boomi を Azure NetApp Files で実行しています。 ストレージ サービスのメンテナンス イベントが原因で発生する中断を回避するには、どのような予防措置を講じることができますか?

Boomi を実行している場合は、実行時の高可用性とディザスター リカバリーに関する Boomi のベスト プラクティスに従うことをお勧めします。

Boomi では、Boomi Atom の高可用性を実装するために Boomi Molecule を使用することをお勧めします。 Boomi Molecule のシステム要件には、NFS ロックが有効になっている NFS (NLM サポート) または SMB ファイル共有のいずれかを使用できると記載されています。 Azure NetApp Files のコンテキストでは、NFSv4.1 ボリュームで NLM がサポートされています。

Boomi では、SMB ファイル共有を Windows VM で使用することをお勧めします。NFS の場合、Boomi では Linux VM をお勧めします。

Note

Azure NetApp Files の継続的可用性共有は Boomi ではサポートされていません。

次のステップ