ユニバーサル仮想化、コンテナアーキテクチャの収束と成功をきっかけに、パッチの適用はいくぶん初歩的に見え始めています。 コンテナを再度作成して作成できるのに、なぜアップデートをインストールして再起動するのですか？ そして、これは、ユーザーアプリケーションとサービス、開発とテストに関して言えます。 しかし、実践が示すように、すべてが基盤となるインフラストラクチャには、まったく異なるアプローチが必要です。 データベースなどの重いサービスの安定性と継続的な可用性により、マイクロサービスはいつでも開始し、任意のデータを使用できます。
起動して長時間暖かくなるシステムはあまり頻繁にリブートしないことは誰にとっても明らかですが、何よりも、決してリブートしないことです。 また、システムが強力になり、マイクロサービスがシステムに依存するほど、リブートするための操作のシャットダウンによる収益性が低下します。 この問題を解決する1つの例として、ReadyKernelテクノロジーがあります。これにより、LinuxホストOSに更新プログラムをインストールし、多くの仮想マシンとコンテナーを再起動せずに実行できます。 さまざまなサービスのダウンタイムを削減する別のソリューションが、CRIUプロジェクトによって提供されています。
CRIUが標準になります
このオープンソースツールの形成段階でCRIUが出会ったことに疑問を抱いています（ただし、タブレットと最初に話したゲイツも笑われました）が、今日CRIUはOpenVZ、Docker、LXC、CoreOSコンテナーに統合されています。 LinuxディストリビューションのUbuntu、Debian、OpenSUSE、Altlinuxなどに含まれており、IBMを含むさまざまな企業の開発者もサポートしています。 ちなみに、CRIUに最大の貢献をしたのはBlue Giantだったのが不思議です-今日、このツールは複数のプラットフォーム（x86_64、ARM、aarch64、PPC64、s390）で同時に動作します。 そして、そのうちの2つ（PowerPC64とs390）はIBMの発案です。 最後のツールのサポートは、2017年の夏に文字通り発表されました。
ハードウェアプラットフォームとソフトウェアの開発分野で最大の企業がこのようなツールを必要とする理由を説明するには、プロジェクトの本質について少し洞察する必要があります。 CRIUを使用すると、アプリケーションを「フリーズ」して、別のホストまたは別のコンテナで起動できるようになります。 このツールを正しく使用することで、アプリケーションは、何も起こらなかったかのように、作業を続けながら移動したと推測することさえできません。 既に述べたように、マイクロサービスはこれをまったく必要としませんが、メインフレームを含む解決されたタスクに非常に役立つことが判明しました。
高性能s390サーバーのマイクロプロセッサアーキテクチャは独特で、IBMはメインフレームラインアップで開発しています。 マルチプロセッサおよびマルチスレッドシステムにより、膨大な量のデータを操作できます。これにより、OSおよびアプリケーションのアーキテクチャに独自の特性が課せられます。 2017年の夏に、IBM開発者からのパッチがCRIUに届き、s390でCRIUを使用できるようになりました。 実際、CRIUは低レベルのツールであり、そのコードはカーネルコードに近いため、新しいアーキテクチャへの適応が必要です。 CRIUが動作を開始するには、プラットフォーム固有の機能のサポートを実装する必要がありました。 IBMの開発者は、単純なものから複雑なものまで、システムコール、独自のデータ型、プロセスの仮想アドレス空間の記述子をサポートし、必要なコンパイラー設定、レジスターのイメージ、偽のコードに必要なジャンプを追加しました。 TLS / GOTタイプの詳細。 ここで行われた作業の内容を知ることができます ：
#include "common/asm/linkage.h"
.section .head.text, "ax"
/*
* Entry point for parasite_service()
*
* Addresses of symbols are exported in auto-generated criu/pie/parasite-blob.h
*
* Function is called via parasite_run(). The command for parasite_service()
* is stored in global variable __export_parasite_cmd.
*
* Load parameters for parasite_service(unsigned int cmd, void *args):
*
* - Parameter 1 (cmd) : %r2 = *(uint32 *)(__export_parasite_cmd + pc)
* - Parameter 2 (args): %r3 = __export_parasite_args + pc
*/
ENTRY(__export_parasite_head_start)
larl %r14,__export_parasite_cmd
llgf %r2,0(%r14)
larl %r3,__export_parasite_args
brasl %r14,parasite_service
.long 0x00010001 /* S390_BREAKPOINT_U16: Generates SIGTRAP */
__export_parasite_cmd:
.long 0
END(__export_parasite_head_start)
s390に偽のコードを導入するための踏み台
IBMプラットフォームのユーザーは、十分な数のソフトウェアに直面しているため、「キル、再作成」を操作するのは非常に困難です。 大規模なアプリケーションでは、たとえば、電力が失われた場合に作業を迅速に復元するために、サービスの状態を維持する方がはるかに便利です。 「ライブ」状態のコンテナを移行する機能により、メンテナンスや負荷分散などのためにサーバーを解放できます。
そして、これはメインフレームだけに当てはまりません。 IBMのCRIUプロジェクトへの関与は、s390アーキテクチャーに限定されません。 数年前、IBMからPPC64をサポートするパッチを受け取りました。 これらのIBMソリューションは、メインフレームではなく、ワークステーションおよび単純なサーバー向けに設計されています。 しかし、IBM開発者がCRIUプロジェクトに対して行った最も興味深い貢献は、遅延移行テクノロジーです。
これは次のように発生します。コンテナは、メモリの内容なしでホスト間を移動します。 このアプローチにより、イメージのサイズを1桁減らすことができ、メモリに大量のデータを保持するアプリケーションに非常に効果的です。 たとえば、JVMについて話している場合、その完全なイメージは数十メガバイトを占有する可能性があります（そして、これで実行されるプログラムがそれ自体に割り当てるメモリを考慮しません）が、メモリの内容がないサイズは数十キロバイトになります。 これにより、移行が何倍も速くなり、作業の一時停止が減少します。 IBMアドオンが行うことの本質は、必要に応じてメモリへのリモートアクセスとその非同期移行を提供する機能です。
それでも、システムを再起動する必要がある場合は、多くのタスクがあります。 また、ここでは、アプリケーションを停止する機能も役立ちます。 CRIUを使用すると、コンテナを停止し、システムを再起動して、その中のコンテナを再起動できます。 したがって、再起動せずにシステムを更新することができない困難な状況でのパッチ適用の問題を解決します。
おわりに
CRIUプロジェクトの広範なサポートにより、今日ではすべての開発者が5つの異なるアーキテクチャ上のアプリケーションを「フリーズ」および「ライブマイグレーション」する機能を使用できると言えます。 プロジェクトの開発に対するIBMの貢献により、PPC64マイフレームとサーバーでCRIUの機能を使用できるだけでなく、他のプラットフォームで「遅延移行」メカニズムを使用することも可能になりました。
さらに、発生した変更により、偽のコードをプロセスに感染させ、特定の命令を強制的に実行できる個別のCompelライブラリを作成することが推奨されています。 現在、CompelはCRIUプロジェクトおよび新しいライブアプリケーションパッチシステムで使用されています。 次の投稿で、それとCompelライブラリ自体について説明します。