Windows サービス — 高可用性シナリオと設計アプローチ

Question

Windows サーバー マシンでスタンドアロンの Windows サービスを実行しているとします。可用性が高いことを確認するにはどうすればよいですか?

1)。提案できるデザインレベルのガイドラインは何ですか?

2)。プライマリ/セカンダリのように可用性を高める方法 (現在市場で入手可能なクラスタリング ソリューションなど)

3)。フェイルオーバーシナリオが発生した場合に、横断的な問題に対処する方法

他に思い当たるものがあれば、ここに追加してください。

注記：この質問は Windows と Windows サービスにのみ関連しています。このルールに従うようにしてください:)

Answer 1

サービスを少なくとも実行し続けるために、サービスがクラッシュした場合に Windows サービス マネージャーが自動的に再起動するように設定できます (サービス プロパティの [回復] タブを参照)。これらのプロパティを設定するバッチ スクリプトなど、詳細については、ここで参照できます。 Windows サービスがクラッシュした場合は再起動する

高可用性は、単に外部からサービスを稼働し続けるだけではありません。サービス自体は高可用性を念頭に置いて構築される必要があります (例:全体を通して適切なプログラミング手法を使用し、適切なデータ構造、リソースの取得と解放のペアを使用し、予想される負荷の下でも動作し続けることを確認するために全体のストレス テストを実施します。

冪等コマンドの場合、コマンドを一定回数再起動することで、断続的な障害 (リソースのロックなど) を許容できます。これにより、サービスはクライアントを障害から保護できます (ある程度まで)。クライアントも障害を予測するようにコード化する必要があります。クライアントは、いくつかの方法でサービスの失敗を処理できます。ログに記録する、ユーザーにプロンプ​​トを表示する、X 回再試行する、致命的なエラーをログに記録する、終了するなどのすべての方法が考えられます。どれが適切かは要件によって異なります。サービスに「会話状態」がある場合、サービスが激しく失敗したとき (つまり、プロセスが再起動される場合)、これは通常、現在の会話状態が失われたことを意味するため、クライアントはこの状況を認識して対処する必要があります。

単一のマシンはハードウェア障害に対して脆弱であるため、単一のマシンを使用する場合は、そのマシンに冗長コンポーネントがあることを確認してください。HDD は特に障害が発生しやすいため、少なくともミラーリングされたドライブ、または RAID アレイを搭載します。PSU が次の弱点であるため、UPS と同様に冗長 PSU も価値があります。

クラスタリングに関しては、Windows はサービス クラスタリングをサポートし、個々のコンピュータ名ではなくネットワーク名を使用してサービスを管理します。これにより、クライアントは、ハードコードされた名前ではなく、サービスを実行している任意のマシンに接続できるようになります。ただし、追加の措置を講じない限り、これはリソース フェイルオーバーであり、サービスのあるインスタンスから別のインスタンスにリクエストが送信されます。通常、会話状態は失われます。サービスがデータベースに書き込む場合は、信頼性を確保し、ローカル ノードだけでなくクラスター全体で変更を利用できるようにするために、データベースもクラスター化する必要があります。

これは実際には氷山の一角にすぎませんが、さらなる研究を始めるためのアイデアになれば幸いです。

Microsoft クラスタリング サービス (MSCS)

Answer 2

解決しようとしている問題を分解してみると、おそらく自分自身でいくつかの答えが見つかると思います。ジャスティンがコメントで述べたように、唯一の答えはありません。それは、サービスが何を行うか、そしてクライアントがそれをどのように使用するかによって完全に異なります。また、クライアントとサーバーの対話性に関する詳細も指定しません。HTTP?TCP?UDP?他の？

始めるにあたって考慮すべき点がいくつかあります。

1) サービスまたはサーバーがダウンしたらどうしますか?

• サービスの複数のインスタンスを別々のサーバーで実行してみてはどうでしょうか?

2) わかりましたが、クライアントはどのようにして複数のサービスについて知るのでしょうか?

• 各クライアントにリストをハードコーディングできます (推奨されません)。
• DNS ラウンドロビンを使用して、すべてのリクエストをバウンスできます。
• 負荷分散デバイスを使用できます。
• 他のすべてのサービスを認識し、クライアントを利用可能なサービスに誘導できる別のサービスを用意できます。

3) では、1 つのサービスがダウンしたらどうなるでしょうか?

• クライアント アプリケーションは、接続しているサービスがダウンした場合に何をすべきかを知っていますか?そうでない場合は、その状況に対処するために更新する必要があります。

これにより、高可用性を開始する方法についての基本的な考え方を理解できるようになります。アーキテクチャに関する具体的な詳細を提供すると、おそらくはるかに良い応答が得られるでしょう。

Answer 3

サービスがクライアント接続用のインターフェイスを公開していない場合は、次のようにすることができます。

• 「私は生きています」メッセージをブロードキャストまたは公開するか、データベース/レジストリ/TCP/その他のものにあなたが生きていることを知らせます

• これらの「生きています」シグナルをチェックする 2 番目のサービス (モニター) を用意し、サービスがダウンした場合には再起動を試みます。

ただし、namedpipes/tcp/etc 経由でこのサービスに接続しているクライアントがある場合、クライアントはデータベース内で実行されているサービスを使用してマシンのアドレスを確認するか、トラフィックをリダイレクトするためのインテリジェント スイッチなどのより高度なものを用意する必要があります。