リアルタイム制御システムでの永続プロセスの実装の問題（パート3）

記事の終わり。



パート1に進む

パート2に進む



4.システムサービスと動作環境



フォールトトレラントなクラスター化された仮想化環境を実装した後、1レベル上に移動し、オペレーティング環境を直接利用して、仮想マシン内でアプリケーションを実行します。







ここには根本的な問題はありません。メインハイパーバイザーは、ほぼすべての最新のオペレーティングシステムの制御下で仮想マシンの動作を提供します。 Linuxはサーバータスクの最も一般的なプラットフォームであるため、このファミリのオペレーティングシステムに焦点を当てるのが最も簡単です。



仮想マシン内に、それをサポートするホストシステム（たとえば、SLESまたはRHEL）と同じバージョンのLinuxをインストールすることは、自然なステップのように思えるかもしれません。 これには、機能を考慮して1つの製品のみの更新ポリシーを維持する必要があり、物理サーバーとその仮想マシンに共通のライセンスを使用できるという利点があります。 ただし、SLESとRHELは、開発者よりも標準アプリケーションを管理する管理者に焦点を当てたディストリビューションであり、開発ツールの最新バージョンで受け取ったプログラムを実行するための環境をサポートするため、このアプローチには重大な欠点があります、システムおよび外部パッケージの構成を管理するためにかなりの追加作業が必要になる場合があります。



したがって、私たちの観点からは、ホストと仮想マシンの間の動作環境の統一を追いかけることはあまり意味がなく、VM OSとして開発に使用しているLinuxディストリビューションを使用する方がはるかに便利です。





もちろん、VM OSは物理マシンのOSに劣らず、クラッシュや障害が発生する可能性があります。 クラスタリングによって物理レベルで解決されるコンピューティングプラットフォームの冗長性の問題は、相互の作業を制御する相互接続された複数の仮想マシンにシステム機能を実装することにより、仮想レベルで解決されます。 ウォッチドッグタイマーによって物理レベルで解決されるヘルスモニタリングタスクは、同じ方法で（ウォッチドッグ仮想デバイスによって）仮想レベルで解決できますが、クラスターにコマンドを発行して制御対象の仮想マシンを再起動する方がはるかに簡単で機能的です（もちろん、制御が必要です）クロス）。 仮想マシンのイメージは、ロールバックおよび災害復旧ポイントを作成するために簡単に保存できます。



5.計算プロセス



最後に、すべてが開始されたポイント、つまりリアルタイム制御システムの非常に永続的なプロセスに到達しました。



そのため、上記の記事で説明した対策を実装することで、外部リソース、それらとの通信環境、ハードウェアと組み込みプログラム、ホストオペレーティングシステム、システムサービス、オペレーティング環境のレベルで永続性プロパティを確保できました。 小さなことは、私たちのプロセス自体が提供する安定したコンピューティング環境で安定して実行されることを保証することです。



制御の持続可能性にとって最も重要な制御ループの適用ロジックの適切な実装の問題は、この記事の範囲外です。 ここでは、システムレベルでのプロセスの永続性を確保するという2つの問題-再起動に対する復元力と緊急シャットダウンに対する復元力-の検討に限定しています。



上記の多数のフォールトトレランス機能により、コンピューティング環境の可用性を復元できますが、場合によっては個々のコンピューティングプロセスの再起動につながる可能性があります。 これらの条件下で、相互作用が発生するプロセス自体とその近隣プロセスを再起動するプロセスの安定性は非常に重要です。 このような安定性は、マクロステートコンピューティングプロセスの欠如によって実現できます。 セクション2で既に述べたように、プロセス間で長期的な接続を確立することは非常に望ましくなく、一方の端で緊急事態を解決することでいつでも中断できます。 プロセス間の制御信号の交換は、短いトランザクションに減らす必要があります。それぞれの場合、失敗と繰り返しの可能性またはこの場合の受け流しを提供する必要があります。 最も単純なケースでは、そのようなトランザクションは単一のパケットを送信することになります。 さらに、各プロセスは、自身の再起動時に最も実用的なチェックポイントから操作を復元するのに十分な情報を定期的に不揮発性メモリ（つまり、仮想ディスク）に保存する必要があります。



プロセスとDBMSとの相互作用には特に注意を払う必要があります。 プロジェクトでDBMSを使用する場合、データ組織自体の意味のあるトランザクション構造と、DBMSサーバーへのクライアントのネットワーク接続のトランザクション特性の両方を実装する必要があります。 クライアント/サーバー接続は、いずれかの異常な再起動時に復元できる必要があります。これは、トランザクションを短縮し、各トランザクションを短時間で開始、実行、および切断する個別のネットワーク接続に変えることで最も簡単に達成できます。



もちろん、私たちは自分の申請プロセスのエラーに対して完全に保証することはできません。 凍結およびブロックプロセスのレベルでは、前のセクションで説明したヘルスの監視とVMの再起動と同じ手段で問題が解決されます。 緊急シャットダウンレベルでは、次の形式の簡単なスクリプトにより、開発者の多くの血液を節約できます。



while [1]

do

my_executable_module

done









制御プログラムのロジックを実装する直接実行可能モジュールへの呼び出しがラップされます。



結論として、考慮された各レベルの最も正確でエラーのない実装であっても、開発者がそれらの間の不明な相互作用に関連する問題を保証するものではないことに注意してください。 したがって、必要な信頼性インジケータにフォールトトレラントシステムを組み込むにはかなりの時間がかかり、各レベルでフェールオーバーするためにシステムのすべてのレベルの機能を完全にテストする必要があります。