JP7338481B2 - 設定変更方法および設定変更プログラム - Google Patents

設定変更方法および設定変更プログラム Download PDF

Info

Publication number
JP7338481B2
JP7338481B2 JP2020003666A JP2020003666A JP7338481B2 JP 7338481 B2 JP7338481 B2 JP 7338481B2 JP 2020003666 A JP2020003666 A JP 2020003666A JP 2020003666 A JP2020003666 A JP 2020003666A JP 7338481 B2 JP7338481 B2 JP 7338481B2
Authority
JP
Japan
Prior art keywords
setting change
change request
request packet
container
kernel
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2020003666A
Other languages
English (en)
Other versions
JP2021111197A (ja
Inventor
正明 野呂
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2020003666A priority Critical patent/JP7338481B2/ja
Priority to EP20208046.1A priority patent/EP3851988B1/en
Priority to US17/103,745 priority patent/US11722368B2/en
Publication of JP2021111197A publication Critical patent/JP2021111197A/ja
Application granted granted Critical
Publication of JP7338481B2 publication Critical patent/JP7338481B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • H04L12/1868—Measures taken after transmission, e.g. acknowledgments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H04L45/745—Address table lookup; Address filtering
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45595—Network integration; Enabling network access in virtual machine instances

Description

本発明は、設定変更方法および設定変更プログラムに関する。
従来、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）のカーネルを内部で分割して、他と隔離されたコンテナと呼ばれる実行環境を用意し、その上でアプリケーションを動作させる仮想化技術がある。例えば、コンテナは、ホストＯＳのプロセスのひとつとして動作し、ホストＯＳのリソースを全てのコンテナで共有する。
先行技術としては、例えば、マルチテナント型情報処理システムにおいて、テナントの仮想サーバの構成変更時に、設定変更項目と設定対象のＮＷ機器を特定するものがある。また、ライブマイグレーションにおけるサービスの中断時間を測定するネットワークサービスの評価システムがある。
特開２０１２－６５０１５号公報 特開２０１７－１６７８２２号公報
しかしながら、従来技術では、コンテナ上で動作するアプリケーションから、コンテナのカーネル設定の変更依頼があった場合に、対象となるコンテナが実行されているＯＳを特定するのに時間や手間がかかるという問題がある。
一つの側面では、本発明は、設定変更時に対象となるコンテナが、異なるホストや仮想化環境で動作しているＯＳのうち、どのＯＳ上で動作しているかを容易に特定することを目的とする。
一つの実施態様では、いずれかのＯＳで実行されているコンテナ上で動作するソフトウェアから、カーネルの設定変更依頼パケットを受信し、受信した前記設定変更依頼パケットから、前記設定変更依頼パケットを受信した通信モジュールの識別情報を取得し、ＯＳの識別情報と前記ＯＳの通信モジュールの識別情報との対応関係を示す情報を記憶する記憶部を参照して、取得した前記通信モジュールの識別情報に基づいて、前記コンテナが動作するＯＳを特定する、設定変更方法が提供される。
本発明の一側面によれば、設定変更時に対象となるコンテナが、異なるホストや仮想化環境で動作しているＯＳのうち、どのＯＳ上で動作しているかを容易に特定することができるという効果を奏する。
図１は、実施の形態１にかかる情報処理システム１００のシステム構成例を示す説明図である。 図２は、実施の形態１にかかる情報処理システム１００の動作例を示す説明図（その１）である。 図３は、実施の形態１にかかる情報処理システム１００の動作例を示す説明図（その２）である。 図４は、実施の形態１にかかる情報処理システム１００の動作例を示す説明図（その３）である。 図５は、実施の形態１にかかる情報処理システム１００の動作例を示す説明図（その４）である。 図６は、仮想ＮＩＣ／ＯＳ対応表２００の記憶内容の一例を示す説明図である。 図７は、加工モジュールの配置例を示す説明図である。 図８は、設定管理サーバ１０１のハードウェア構成例を示すブロック図である。 図９は、設定管理サーバ１０１の機能的構成例を示すブロック図である。 図１０は、設定変更依頼パケットへの第１の書き込み例を示す説明図である。 図１１は、設定変更依頼パケットへの第２の書き込み例を示す説明図である。 図１２は、設定変更依頼パケットの送信例を示す説明図である。 図１３は、設定変更依頼パケットの送信先の書換例を示す説明図である。 図１４は、実施の形態１にかかる加工モジュールｐｍの第１の転送処理手順の一例を示すフローチャートである。 図１５は、実施の形態１にかかる加工モジュールｐｍの第２の転送処理手順の一例を示すフローチャートである。 図１６は、実施の形態１にかかるカーネル制御部ｋｃの設定変更処理手順の一例を示すフローチャートである。 図１７は、実施の形態２にかかる情報処理システム１７００のシステム構成例を示す説明図である。 図１８は、設定変更依頼パケットの廃棄例を示す説明図である。 図１９は、コンテナの再配置例を示す説明図である。 図２０は、実施の形態２にかかるカーネル制御部ｋｃの動作例を示す説明図（その１）である。 図２１は、実施の形態２にかかるカーネル制御部ｋｃの動作例を示す説明図（その２）である。 図２２は、実施の形態２にかかるカーネル制御部ｋｃの動作例を示す説明図（その３）である。 図２３は、実施の形態２にかかるカーネル制御部ｋｃの動作例を示す説明図（その４）である。 図２４は、依頼管理テーブル２４００の記憶内容の一例を示す説明図である。 図２５は、実施の形態２にかかる検査モジュールｓｍの検査処理手順の一例を示すフローチャートである。 図２６は、実施の形態２にかかる変更依頼モジュールｒｍの変更依頼処理手順の一例を示すフローチャートである。 図２７は、実施の形態２にかかるカーネル制御部ｋｃの第１の設定変更処理手順の一例を示すフローチャートである。 図２８は、実施の形態２にかかるカーネル制御部ｋｃの第２の設定変更処理手順の一例を示すフローチャートである。
以下に図面を参照して、本発明にかかる設定変更方法および設定変更プログラムの実施の形態を詳細に説明する。
（実施の形態１）
まず、実施の形態１にかかる情報処理システム１００のシステム構成例について説明する。情報処理システム１００は、例えば、アプリケーションの実行環境をユーザに貸し出すクラウドサービスを提供するコンピュータシステムに適用される。
図１は、実施の形態１にかかる情報処理システム１００のシステム構成例を示す説明図である。図１において、情報処理システム１００は、設定管理サーバ１０１と、複数の運用サーバ１０２とを含む。情報処理システム１００において、設定管理サーバ１０１および複数の運用サーバ１０２は、有線または無線のネットワーク１１０を介して接続される。ネットワーク１１０は、例えば、インターネット、ＬＡＮ、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）などである。
設定管理サーバ１０１は、いずれかのＯＳで実行されているコンテナｃｒ上で動作するソフトウェアから、設定変更依頼パケットを受け付けるコンピュータ（情報処理装置）である。ここで、設定変更依頼パケットは、カーネルの設定変更を依頼するものである。カーネルは、ＯＳの中核的な役割を担う部分であり、ＯＳの基本機能を実行するソフトウェアである。例えば、設定変更依頼パケットは、コンテナｃｒについてのカーネルの各種パラメータの設定変更を依頼するものである。
コンテナｃｒ（Ｃｏｎｔａｉｎｅｒ）は、ＯＳのカーネルを内部で分割して作成される、他と隔離されたユーザ空間に相当し、ＯＳのプロセスのひとつとして動作する。ユーザ空間は、ユーザがアプリケーションを実行するためのリソースをひとまとめにした実行環境である。
ＯＳのリソースは、論理的に分割されて、複数のコンテナｃｒで共有される。具体的には、例えば、各コンテナｃｒには、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスやホスト名が割り当てられる。また、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、メモリ、ディスクといったリソースもコンテナｃｒごとに論理的に分離される。
コンテナｃｒは、例えば、ＯＳカーネルが持つｎａｍｅｓｐａｃｅ（名前空間）機能とｃｇｒｏｕｐｓ（ｃｏｎｔｒｏｌｇｒｏｕｐｓ）機能により実装される。ｎａｍｅｓｐａｃｅ機能は、プロセスをグループ化して、他のグループから隔離する役割を担う機能であり。ｃｇｒｏｕｐｓ機能は、グループ化されたプロセスに対するリソースの割り当てを制御する機能である。
運用サーバ１０２は、コンテナｃｒを実行可能なコンピュータ（情報処理装置）である。また、運用サーバ１０２は、仮想マシンｖｍを実行可能であってもよい。仮想マシンｖｍ（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）は、物理的なコンピュータのハードウェア資源を分割して構築される実行環境で動作する仮想的なコンピュータである。仮想マシンｖｍは、例えば、ハイパーバイザによりハードウェア資源を仮想化することで実現される。
設定管理サーバ１０１および複数の運用サーバ１０２は、例えば、クラウドコンピューティングのサーバにより実現される。また、設定管理サーバ１０１は、例えば、複数の運用サーバ１０２のうちのいずれかの運用サーバ１０２により実現されてもよい。また、情報処理システム１００には、複数の設定管理サーバ１０１が含まれていてもよい。
ここで、仮想マシンｖｍでは内部でゲストＯＳが稼働するのに対して、コンテナｃｒにはＯＳが含まれない（ＯＳがインストールされない）。たとえ１台の物理サーバ上で複数のコンテナｃｒが起動したとしても、動作するＯＳは１つのため、仮想マシンｖｍに比べて、リソースの消費量や処理負荷が少ない。また、起動時間も仮想マシンｖｍに比べてコンテナｃｒのほうが短い。
一方で、仮想マシンｖｍの場合、ユーザの権限がカーネルまで及ぶため、ユーザがＯＳのカーネル設定（例えば、カーネルバージョン選択、パラメータチューニングなど）を自由に変更することができる。ところが、コンテナｃｒの場合、ユーザにカーネルの管理権限が与えられていない。
このため、カーネルの管理権限を有する者（例えば、システム管理者）に依頼して、コンテナｃｒのカーネルの設定変更を実施してもらうことがある。例えば、ユーザがシステム管理者に対して、あるコンテナｃｒが稼働しているＯＳのカーネルの設定変更を依頼したとする。この場合、システム管理者は、対象となるコンテナｃｒが、どのＯＳで実行されているかを調査して、カーネル設定を変更する。
しかしながら、従来手法では、対象となるコンテナｃｒが、どのＯＳで実行されているかを人手で調査する必要があり、実行場所の特定作業に時間や手間がかかる。例えば、システム管理者が、コンテナｃｒの実行場所を、コンテナ管理サーバやコンテナ運用サーバ（例えば、運用サーバ１０２）などに問い合わせて調査するといった面倒な作業が発生する。
また、コンテナｃｒを実行するサーバの負荷を考慮して、コンテナｃｒの実行場所を自動調整する仕組みの導入が進んでいる。しかし、コンテナｃｒの実行場所が、各サーバの負荷に応じて動的に変化することになると、コンテナｃｒの実行場所を常時監視することになり、運用コストの増大を招いてしまう。
そこで、本実施の形態では、設定変更時に対象となるコンテナｃｒが稼働しているＯＳを容易に特定可能にすることで、ＯＳの設定変更にかかる作業負荷および作業時間を削減する設定変更方法について説明する。まず、図２～図５を用いて、実施の形態１にかかる情報処理システム１００の動作例について説明する。
図２～図５は、実施の形態１にかかる情報処理システム１００の動作例を示す説明図である。図２において、情報処理システム１００内の設定管理サーバ１０１と運用サーバ１０２とが示されている。ここでは、運用サーバ１０２のホストＯＳ２１０上で、仮想マシンｖｍ１とコンテナｃｒ１～ｃｒ３とが稼働している。また、仮想マシンｖｍ１のゲストＯＳ２２０上でコンテナｃｒ４～ｃｒ６が稼働している。
ホストＯＳ２１０は、物理ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）２１１と、仮想ブリッジ２１２，２１３と、仮想ＮＩＣ２１４～２１６と、を含む。ゲストＯＳ２２０は、仮想ＮＩＣ２２１～２２４と、仮想ブリッジ２２５とを含む。物理ＮＩＣ２１１は、ネットワーク１１０に接続するための機器である。
仮想ブリッジ２１２，２１３，２２５は、データを中継する仮想的なブリッジである。仮想ＮＩＣ２１４～２１６，２２１～２２４は、仮想的なＮＩＣである。仮想ＮＩＣ２１４～２１６は、コンテナ・ホストＯＳ間の接続用の仮想ＮＩＣである。各仮想ＮＩＣ２１４～２１６は、各コンテナｃｒ１～ｃｒ３に対応する。
仮想ＮＩＣ２２１は、ゲストＯＳ・ホストＯＳ間の接続用の仮想ＮＩＣである。仮想ＮＩＣ２２２～２２４は、コンテナ・ゲストＯＳ間の接続用の仮想ＮＩＣである。各仮想ＮＩＣ２２２～２２４は、各コンテナｃｒ４～ｃｒ６に対応する。
ここで、設定管理サーバ１０１は、仮想ＮＩＣ／ＯＳ対応表２００を作成する。仮想ＮＩＣ／ＯＳ対応表２００は、ＯＳの識別情報と、当該ＯＳの仮想ＮＩＣの識別情報との対応関係を示す情報を記憶する。図２の例では、対象となる仮想ＮＩＣは、点線枠内の仮想ＮＩＣである。ただし、仮想ＮＩＣ／ＯＳ対応表２００は、予め作成されて設定管理サーバ１０１に記憶されていてもよい。
図６は、仮想ＮＩＣ／ＯＳ対応表２００の記憶内容の一例を示す説明図である。図６において、仮想ＮＩＣ／ＯＳ対応表２００は、仮想ＮＩＣ識別子およびＯＳ識別子のフィールドを有し、各フィールドに情報を設定することで、仮想ＮＩＣ情報（例えば、仮想ＮＩＣ情報６００－１～６００－３）をレコードとして記憶する。
ここで、仮想ＮＩＣ識別子は、仮想ＮＩＣを一意に識別する識別情報である。例えば、仮想ＮＩＣ識別子は、仮想ＮＩＣのＩＤである。ＯＳ識別子は、ＯＳ（ホストＯＳまたはゲストＯＳ）を一意に識別する識別情報である。例えば、ＯＳ識別子は、ＯＳのＩＤである。また、ＯＳ識別子は、ＯＳのカーネルの制御対象モジュールを特定する情報であってもよい。
例えば、仮想ＮＩＣ情報６００－１は、ＯＳ識別子「ａ」で識別されるＯＳの仮想ＮＩＣに割り当てられた仮想ＮＩＣ識別子「ａ－１」を示す。
図３において、アプリ３００は、設定管理サーバ１０１に対して、設定変更依頼パケット３１０を送信する。ここで、アプリ３００は、コンテナｃｒ６上で動作するユーザのアプリケーション（ソフトウェア）である。設定変更依頼パケット３１０は、コンテナｃｒ６が実行されているＯＳのカーネルの設定変更を依頼するものである。
設定変更依頼パケット３１０は、例えば、ユーザからの要求に応じて、アプリ３００から設定管理サーバ１０１に送信される。ただし、ユーザにはカーネルの管理権限がなく、設定変更依頼パケット３１０に、コンテナｃｒ６が実行されているＯＳを特定するＯＳ識別子などは含まれない。
図４において、加工モジュール４００は、コンテナｃｒ６に対応して設けられるモジュールである。加工モジュール４００は、例えば、プログラム（いわゆる、小型ＶＭ）により実現される。ここで、図７を用いて、加工モジュール４００の配置例について説明する。
図７は、加工モジュールの配置例を示す説明図である。図７において、加工モジュール４００は、仮想ＮＩＣ２２４と、プロトコルスタックｐｓとの間に配置される。プロトコルスタックｐｓは、コンピュータ上で通信を実現するための一連の通信プロトコル群を実装するモジュールである（図２～図５では不図示）。例えば、プロトコルスタックｐｓは、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）／ＩＰのプロトコルスタックである。仮想ＮＩＣ２２４は、設定管理サーバ１０１側から見えるコンテナ・ＯＳ間の接続用の仮想ＮＩＣであり、コンテナｃｒ６用の仮想ＮＩＣ７００（図２～図５では不図示）と１対１で対向接続される。
加工モジュール４００は、アプリ３００からの設定変更依頼パケット３１０を受信すると、設定変更依頼パケット３１０を受信した仮想ＮＩＣ２２４の識別情報（例えば、仮想ＮＩＣのＩＤ）を、設定変更依頼パケット３１０のヘッダに書き込む。仮想ＮＩＣ２２４は、コンテナｃｒ６用の仮想ＮＩＣ７００と対向接続された仮想ＮＩＣである。
加工モジュール４００は、仮想ＮＩＣ２２４の識別情報を書き込んだ設定変更依頼パケット３１０をプロトコルスタックｐｓに転送する。プロトコルスタックｐｓに転送された設定変更依頼パケット３１０は、ホストＯＳ２１０の物理ＮＩＣ２１１を介して設定管理サーバ１０１に送信される。
ここで、仮想ＮＩＣ２２４は、コンテナｃｒ６用の仮想ＮＩＣ７００と１対１で対向接続されている。このため、仮想ＮＩＣ２２４の識別情報は、コンテナｃｒ６用の仮想ＮＩＣ７００に対応しており、コンテナｃｒ６に対応しているといえる。
図５において、設定管理サーバ１０１は、設定変更依頼パケット３１０を受信すると、設定変更依頼パケット３１０から、設定変更依頼パケット３１０を受信した仮想ＮＩＣの識別情報を取得する。具体的には、例えば、設定管理サーバ１０１は、設定変更依頼パケット３１０のヘッダから、コンテナｃｒ６用の仮想ＮＩＣ７００と対向接続され、コンテナ・ＯＳ間の接続用の仮想ＮＩＣ２２４の識別情報を取得する。
つぎに、設定管理サーバ１０１は、例えば、図６に示した仮想ＮＩＣ／ＯＳ対応表２００を参照して、取得した仮想ＮＩＣ２２４の識別情報に基づいて、コンテナｃｒ６が実行されているＯＳを特定する。例えば、仮想ＮＩＣ２２４の識別情報を、仮想ＮＩＣ識別子「ａ－３」とする。
この場合、設定管理サーバ１０１は、仮想ＮＩＣ／ＯＳ対応表２００を参照して、仮想ＮＩＣ識別子「ａ－３」に対応するＯＳ識別子「ａ」を特定する。そして、設定管理サーバ１０１は、ＯＳ識別子「ａ」から、コンテナｃｒ６が動作するＯＳ、すなわち、コンテナｃｒ６が実行されているＯＳを特定する。ここでは、コンテナｃｒ６が実行されているＯＳとして、ＯＳ識別子「ａ」により識別されるＯＳが特定される。
これにより、コンテナｃｒ６上で動作しているアプリ３００からの設定変更依頼に応じて、対象となるコンテナｃｒ６が、異なるホストや仮想化環境で動作しているＯＳのうち、どのＯＳ（ＯＳ識別子「ａ」のＯＳ）上で動作しているかを自動で特定することができる。このため、コンテナｃｒ６の実行場所の特定にかかる面倒な作業をなくして、ひいては、ＯＳの設定変更にかかる作業負荷および作業時間を削減することができる。
なお、設定変更依頼パケット３１０に対するＯＳ（ＯＳ識別子「ａ」のＯＳ）の設定変更処理は、設定管理サーバ１０１で実行してもよく、また、設定管理サーバ１０１とは異なる他のコンピュータで実行してもよい。また、ＯＳ（ＯＳ識別子「ａ」のＯＳ）の設定変更処理は、システム管理者などによって人手で行われることにしてもよい。
（設定管理サーバ１０１のハードウェア構成例）
図８は、設定管理サーバ１０１のハードウェア構成例を示すブロック図である。図８において、設定管理サーバ１０１は、ＣＰＵ８０１と、メモリ８０２と、ディスクドライブ８０３と、ディスク８０４と、通信Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）８０５と、可搬型記録媒体Ｉ／Ｆ８０６と、可搬型記録媒体８０７と、を有する。また、各構成部は、バス８００によってそれぞれ接続される。
ここで、ＣＰＵ８０１は、設定管理サーバ１０１の全体の制御を司る。ＣＰＵ８０１は、複数のコアを有していてもよい。メモリ８０２は、例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）およびフラッシュＲＯＭなどを有する。具体的には、例えば、フラッシュＲＯＭがＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）のプログラムを記憶し、ＲＯＭがアプリケーションプログラムを記憶し、ＲＡＭがＣＰＵ８０１のワークエリアとして使用される。メモリ８０２に記憶されるプログラムは、ＣＰＵ８０１にロードされることで、コーディングされている処理をＣＰＵ８０１に実行させる。
ディスクドライブ８０３は、ＣＰＵ８０１の制御に従ってディスク８０４に対するデータのリード／ライトを制御する。ディスク８０４は、ディスクドライブ８０３の制御で書き込まれたデータを記憶する。ディスク８０４としては、例えば、磁気ディスク、光ディスクなどが挙げられる。
通信Ｉ／Ｆ８０５は、通信回線を通じてネットワーク１１０に接続され、ネットワーク１１０を介して外部のコンピュータ（例えば、図１に示した運用サーバ１０２）に接続される。そして、通信Ｉ／Ｆ８０５は、ネットワーク１１０と装置内部とのインターフェースを司り、外部のコンピュータからのデータの入出力を制御する。
可搬型記録媒体Ｉ／Ｆ８０６は、ＣＰＵ８０１の制御に従って可搬型記録媒体８０７に対するデータのリード／ライトを制御する。可搬型記録媒体８０７は、可搬型記録媒体Ｉ／Ｆ８０６の制御で書き込まれたデータを記憶する。可搬型記録媒体８０７としては、例えば、ＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｃ）－ＲＯＭ、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）メモリなどが挙げられる。
なお、設定管理サーバ１０１は、上述した構成部のほかに、例えば、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、入力装置、ディスプレイ等を有することにしてもよい。また、設定管理サーバ１０１は、上述した構成部のうち、例えば、ディスクドライブ８０３、ディスク８０４、可搬型記録媒体Ｉ／Ｆ８０６、可搬型記録媒体８０７を有していなくてもよい。
また、図１に示した運用サーバ１０２についても、設定管理サーバ１０１と同様のハードウェア構成により実現することができる。
（設定管理サーバ１０１の機能的構成例）
図９は、設定管理サーバ１０１の機能的構成例を示すブロック図である。図９において、設定管理サーバ１０１は、通信部９０１と、特定部９０２と、変更部９０３と、出力部９０４と、記憶部９１０と、を含む。通信部９０１～出力部９０４は、カーネル制御部ｋｃとなる機能であり、具体的には、例えば、図８に示したメモリ８０２、ディスク８０４、可搬型記録媒体８０７などの記憶装置に記憶されたプログラムをＣＰＵ８０１に実行させることにより、または、通信Ｉ／Ｆ８０５により、その機能を実現する。各機能部の処理結果は、例えば、メモリ８０２、ディスク８０４などの記憶装置に記憶される。また、記憶部９１０は、例えば、メモリ８０２、ディスク８０４などの記憶装置により実現される。具体的には、例えば、記憶部９１０は、図６に示した仮想ＮＩＣ／ＯＳ対応表２００を記憶する。
以下の説明では、情報処理システム１００内のいずれかのＯＳを「ＯＳ＃」と表記する場合がある。
通信部９０１は、いずれかのＯＳ＃で実行されているコンテナｃｒ上で動作するソフトウェアから、設定変更依頼パケットを受信する。ここで、設定変更依頼パケットは、コンテナｃｒについて、カーネルの設定変更を要求する情報である。変更対象となるカーネル設定としては、例えば、通信用のバッファの容量の設定、ファイアウォールの設定、ウェブアクセスを処理するためのコネクションの受付可能数の設定などがある。
カーネル設定の変更依頼内容は、例えば、設定変更依頼パケットのペイロード（データ本体）に含まれる。設定変更依頼パケットのヘッダには、設定変更依頼パケットを受信した通信モジュールの識別情報が含まれる。通信モジュールは、コンピュータネットワークに接続するためのモジュールであり、例えば、仮想ＮＩＣである。
具体的には、例えば、通信部９０１は、運用サーバ１０２で実行されているコンテナｃｒの変更依頼モジュールｒｍから送信される設定変更依頼パケットを、運用サーバ１０２から受信する。変更依頼モジュールｒｍは、例えば、コンテナｃｒ上で動作しているアプリケーション（例えば、図３に示したアプリ３００）により実現される。
特定部９０２は、受信された設定変更依頼パケットから、設定変更依頼パケットを受信した通信モジュールの識別情報を取得する。そして、特定部９０２は、記憶部９１０を参照して、取得した通信モジュールの識別情報に基づいて、コンテナｃｒが動作するＯＳ＃を特定する。記憶部９１０は、ＯＳの識別情報と、ＯＳの通信モジュールの識別情報との対応関係を示す情報を記憶する。
ここで、ＯＳの通信モジュールは、他のＯＳ、仮想マシン、コンテナなどと接続するためのモジュールであり、例えば、ＯＳの仮想ＮＩＣである。また、設定変更依頼パケットを受信した通信モジュールは、例えば、設定変更依頼パケットを受信した仮想ＮＩＣである。
より詳細に説明すると、例えば、設定変更依頼パケットを受信した仮想ＮＩＣは、コンテナｃｒ用の仮想ＮＩＣと対向接続されたコンテナ・ＯＳ間の接続用の仮想ＮＩＣである。コンテナｃｒ用の仮想ＮＩＣは、例えば、図７に示した仮想ＮＩＣ７００である。また、コンテナｃｒ用の仮想ＮＩＣと対向接続されたコンテナ・ＯＳ間の接続用の仮想ＮＩＣは、例えば、図７に示した仮想ＮＩＣ２２４である。
具体的には、例えば、特定部９０２は、受信された設定変更依頼パケットのヘッダから、設定変更依頼パケットを受信した仮想ＮＩＣのＩＤ（仮想ＮＩＣ識別子）を取得する。なお、設定変更依頼パケットを受信した通信モジュールの識別情報は、例えば、ＯＳ＃内のコンテナｃｒに対応する加工モジュールｐｍによって設定変更依頼パケットのヘッダに書き込まれる。
つぎに、特定部９０２は、例えば、図６に示した仮想ＮＩＣ／ＯＳ対応表２００を参照して、取得した仮想ＮＩＣのＩＤ（仮想ＮＩＣ識別子）に対応するＯＳ識別子を特定する。そして、特定部９０２は、特定したＯＳ識別子により識別されるＯＳを、コンテナｃｒが動作するＯＳ＃、すなわち、依頼元のコンテナｃｒが実行されているＯＳ＃として特定する。
変更部９０３は、設定変更要求パケットから特定される変更依頼内容に基づいて、特定されたＯＳ＃のカーネルの設定を変更する。具体的には、例えば、変更部９０３は、設定変更要求パケットのペイロードを参照して、カーネル設定の変更依頼内容を特定する。そして、変更部９０３は、特定した変更依頼内容に従って、特定されたＯＳ＃のカーネルの設定を変更する。
より詳細に説明すると、例えば、変更部９０３は、対象となるコンテナｃｒについて、通信用のバッファの容量を変更したり、ファイアウォールの設定を変更したり、ウェブアクセスを処理するためのコネクションの受付可能数を変更したりする。対象となるコンテナｃｒは、依頼元のコンテナｃｒ、すなわち、設定変更依頼パケットの送信元のソフトウェアが動作しているコンテナｃｒである。
対象となるコンテナｃｒは、例えば、設定変更依頼パケットの送信元アドレスから特定されてもよい。また、対象となるコンテナｃｒのカーネルの制御対象モジュールは、仮想ＮＩＣ／ＯＳ対応表２００から特定されることにしてもよい。なお、変更部９０３は、例えば、依頼元であるユーザが有する使用権限を参照して、ＯＳ＃のカーネル設定の変更を許可するか否かを判断してもよい。
出力部９０４は、特定されたＯＳ＃の識別情報を出力する。具体的には、例えば、出力部９０４は、依頼元のコンテナｃｒの識別情報と対応付けて、特定されたＯＳ＃の識別情報を出力することにしてもよい。出力部９０４の出力形式としては、例えば、メモリ８０２、ディスク８０４などの記憶装置への記憶、通信Ｉ／Ｆ８０５による他のコンピュータへの送信、不図示のディスプレイへの表示などがある。
より詳細に説明すると、例えば、出力部９０４は、依頼元のコンテナｃｒの識別情報と、ＯＳ＃の識別情報と、カーネル設定の変更依頼内容とを含む設定変更情報を、システム管理者の情報処理端末に送信することにしてもよい。これにより、システム管理者は、設定変更情報を参照して、依頼元のコンテナｃｒが動作するＯＳ＃を容易に特定することができる。また、システム管理者は、カーネル設定の変更依頼内容を特定して、依頼元のコンテナｃｒについてのカーネル設定を変更することができる。この際、システム管理者は、例えば、依頼元であるユーザが有する使用権限を参照して、ＯＳ＃のカーネル設定の変更を許可するか否かを判断してもよい。
なお、設定管理サーバ１０１の各機能部は、情報処理システム１００内の他のコンピュータ（例えば、運用サーバ１０２）により実現されることにしてもよい。また、設定管理サーバ１０１の各機能部は、情報処理システム１００内の複数のコンピュータ（例えば、設定管理サーバ１０１と運用サーバ１０２）により実現されることにしてもよい。
（設定変更依頼パケットへの書き込み例）
つぎに、図１０および図１１を用いて、設定変更依頼パケットへの通信モジュールの識別情報の書き込み例について説明する。ここでは、通信モジュールの識別情報として、設定変更依頼パケットを受信した仮想ＮＩＣのＩＤ（仮想ＮＩＣ識別子）を書き込む場合を例に挙げて説明する。
図１０は、設定変更依頼パケットへの第１の書き込み例を示す説明図である。図１０において、設定変更依頼パケット１０００は、コンテナｃｒ上の変更依頼モジュールｒｍから送信される設定変更依頼パケットの一例である。設定変更依頼パケット１０００は、ＩＰヘッダ１００１と、オプションヘッダ１００２と、制御リクエスト１００３とを含む。
ＩＰヘッダ１００１には、送信元アドレス、宛先アドレスなどの情報が格納される。オプションヘッダ１００２は、コンテナｃｒ上の変更依頼モジュールｒｍによって付与されるオプションヘッダである。より詳細に説明すると、例えば、変更依頼モジュールｒｍは、設定変更依頼パケット１０００を送信する際に、変更依頼パケット送信用のソケットをオープンし、ソケットにオプションヘッダを付与するパラメータを設定する。
オプションヘッダ１００２としては、例えば、レコードルートオプションヘッダやタイムスタンプオプションヘッダを利用することができる。レコードルートオプションヘッダは、パケットが通過した装置のＩＰアドレスを記録するオプションヘッダである。タイムスタンプオプションヘッダは、パケットが通過した装置のＩＰアドレスと通過時刻を記録するオプションヘッダである。オプションヘッダ１００２は、初期状態では空である。制御リクエスト１００３には、カーネル設定の変更依頼内容が記録される。
加工モジュールｐｍは、設定変更依頼パケット１０００を受信すると、設定変更依頼パケット１０００のオプションヘッダ１００２に、設定変更依頼パケット１０００を受信した仮想ＮＩＣ１０１０のＩＤ（３２ｂｉｔ）を書き込む。仮想ＮＩＣ１０１０は、コンテナｃｒ用の仮想ＮＩＣと対向接続されたコンテナ・ＯＳ間の接続用の仮想ＮＩＣである。
なお、加工モジュールｐｍは、例えば、受信したパケットのＩＰヘッダを検査して、宛先情報（ＩＰアドレス、ポート番号など）から設定変更依頼パケットであるか否かを判断することができる。例えば、加工モジュールｐｍは、受信したパケットがカーネル制御部ｋｃ宛のパケットの場合、設定変更依頼パケットであると判断する。一方、受信したパケットがカーネル制御部ｋｃ宛のパケットではない場合には、加工モジュールｐｍは、設定変更依頼パケットではないと判断する。
カーネル制御部ｋｃは、設定変更依頼パケット１０００を受信すると、設定変更依頼パケット１０００のオプションヘッダ１００２から、設定変更依頼パケット１０００を受信した仮想ＮＩＣ１０１０のＩＤ（３２ｂｉｔ）を読み出す。
これにより、ＩＰパケットの利用可能なオプションヘッダを用いて、設定変更依頼パケットを受信した仮想ＮＩＣのＩＤ（仮想ＮＩＣ識別子）を記録することができる。
図１１は、設定変更依頼パケットへの第２の書き込み例を示す説明図である。図１１において、設定変更依頼パケット１１００は、コンテナｃｒ上の変更依頼モジュールｒｍから送信される設定変更依頼パケットの一例である。設定変更依頼パケット１１００は、オプションヘッダのない形式のパケットであり、ＩＰヘッダ１１０１と、制御リクエスト１１０２とを含む。
加工モジュールｐｍは、設定変更依頼パケット１１００を受信すると、設定変更依頼パケット１１００にオプションヘッダ１１０３を付加する。そして、加工モジュールｐｍは、設定変更依頼パケット１１００を受信した仮想ＮＩＣ１１１０のＩＤ（３２ｂｉｔ）を、付加したオプションヘッダ１１０３に書き込む。仮想ＮＩＣ１１１０は、コンテナｃｒ側の仮想ＮＩＣと対向接続されたコンテナ・ＯＳ間の接続用の仮想ＮＩＣである。
カーネル制御部ｋｃは、設定変更依頼パケット１１００を受信すると、設定変更依頼パケット１１００のオプションヘッダ１１０３から、設定変更依頼パケット１１００を受信した仮想ＮＩＣ１１１０のＩＤ（３２ｂｉｔ）を読み出す。
これにより、加工モジュールｐｍが、設定変更依頼パケットのパケット形式を変更し、オプションヘッダを付加した上で、設定変更依頼パケットを受信した仮想ＮＩＣのＩＤ（仮想ＮＩＣ識別子）を記録することができる。
（マルチキャストアドレスを利用）
つぎに、図１２を用いて、設定変更依頼パケットの送信先にマルチキャストアドレスを利用する場合について説明する。
図１２は、設定変更依頼パケットの送信例を示す説明図である。図１２において、設定変更依頼パケット１２００は、コンテナｃｒ上の変更依頼モジュールｒｍから送信される設定変更依頼パケットの一例である。設定変更依頼パケット１２００は、ＩＰヘッダ１２０１と、オプションヘッダ１２０２と、制御リクエスト１２０３とを含む。
変更依頼モジュールｒｍは、ＩＰヘッダ１２０１の宛先アドレスにマルチキャストアドレスを設定して、設定変更依頼パケット１２００を送信する。設定変更依頼用のマルチキャストアドレスは、例えば、変更依頼モジュールｒｍに予め設定されている。
加工モジュールｐｍは、設定変更依頼パケット１２００を受信すると、設定変更依頼パケット１２００のオプションヘッダ１２０２に、設定変更依頼パケット１２００を受信した仮想ＮＩＣ１２１０のＩＤを書き込む。仮想ＮＩＣ１２１０は、コンテナｃｒ用の仮想ＮＩＣと対向接続されたコンテナ・ＯＳ間の接続用の仮想ＮＩＣである。
なお、加工モジュールｐｍは、例えば、受信したパケットのＩＰヘッダを検査して、宛先アドレスにマルチキャストアドレスが設定されている場合、設定変更依頼パケットであると判断する。一方、宛先アドレスにマルチキャストアドレスが設定されていない場合には、加工モジュールｐｍは、設定変更依頼パケットではないと判断する。
カーネル制御部ｋｃは、設定変更依頼パケット１２００を受信すると、依頼元のコンテナｃｒ（送信元）が、自身が担当するコンテナｃｒであるか否かを判断する。なお、どの送信元の設定変更依頼パケットを処理するかは、例えば、カーネル制御部ｋｃに予め設定されている。
ここで、自身が担当するコンテナｃｒであれば、カーネル制御部ｋｃは、設定変更依頼パケット１２００のオプションヘッダ１２０２から、設定変更依頼パケット１２００を受信した仮想ＮＩＣ１２１０のＩＤを読み出す。一方、自身が担当するコンテナｃｒでなければ、カーネル制御部ｋｃは、設定変更依頼パケット１２００を廃棄する。
これにより、コンテナｃｒの実行場所が変更になっても、変更依頼モジュールｒｍ（コンテナｃｒ）における設定変更依頼パケットの宛先アドレスの設定変更を不要にすることができる。例えば、情報処理システム１００内に存在する複数のカーネル制御部ｋｃのうち、最寄りのカーネル制御部ｋｃに設定変更依頼パケットを送信する運用を行うとする。最寄りのカーネル制御部ｋｃとは、例えば、コンテナｃｒからの物理的な距離が最も近いカーネル制御部ｋｃである。この場合、設定変更依頼パケットの送信先としてマルチキャストアドレスを利用することで、コンテナｃｒの実行場所が変更になっても、送信先の設定変更を行うことなく、最寄りのカーネル制御部ｋｃに設定変更依頼パケットを送ることができる。
（送信先アドレスの書き換え）
つぎに、図１３を用いて、加工モジュールｐｍにおいて設定変更依頼パケットの送信先を書き換える場合について説明する。
図１３は、設定変更依頼パケットの送信先の書換例を示す説明図である。図１３において、設定変更依頼パケット１３００は、コンテナｃｒ上の変更依頼モジュールｒｍから送信される設定変更依頼パケットの一例である。設定変更依頼パケット１３００は、ＩＰヘッダ１３０１と、オプションヘッダ１３０２と、制御リクエスト１３０３とを含む。
変更依頼モジュールｒｍは、ＩＰヘッダ１３０１の宛先アドレスに特定のユニキャストアドレスを設定して、設定変更依頼パケット１３００を送信する。特定のユニキャストアドレスは、例えば、カーネル制御用の代表アドレスであり、変更依頼モジュールｒｍに予め設定されている。
加工モジュールｐｍは、設定変更依頼パケット１３００を受信すると、ＩＰヘッダ１３０１の宛先アドレスに、自モジュールに対応するカーネル制御部ｋｃのアドレスを設定して、設定変更依頼パケット１３００を送信する。カーネル制御部ｋｃのアドレスは、例えば、加工モジュールｐｍに設定されている。
また、設定変更依頼パケット１３００のオプションヘッダ１３０２に、設定変更依頼パケット１３００を受信した仮想ＮＩＣ１３１０のＩＤを書き込む。仮想ＮＩＣ１３１０は、コンテナｃｒ用の仮想ＮＩＣと対向接続されたコンテナ・ＯＳ間の接続用の仮想ＮＩＣである。
なお、加工モジュールｐｍは、例えば、受信したパケットのＩＰヘッダを検査して、宛先アドレスに特定のユニキャストアドレスが設定されている場合、設定変更依頼パケットであると判断する。一方、宛先アドレスに特定のユニキャストアドレスが設定されていない場合には、加工モジュールｐｍは、設定変更依頼パケットではないと判断する。
カーネル制御部ｋｃは、設定変更依頼パケット１３００を受信すると、設定変更依頼パケット１３００のオプションヘッダ１３０２から、設定変更依頼パケット１３００を受信した仮想ＮＩＣ１３１０のＩＤを読み出す。
これにより、コンテナｃｒの実行場所が変更になっても、変更依頼モジュールｒｍ（コンテナｃｒ）における設定変更依頼パケットの宛先アドレスの設定変更が不要となる。また、マルチキャストアドレスを利用する場合に比べて、設定変更依頼時の通信トラフィックを減らすことができる。
（情報処理システム１００の各種処理手順）
つぎに、実施の形態１にかかる情報処理システム１００の各種処理手順について説明する。まず、図１４を用いて、コンテナｃｒ発の設定変更依頼パケットの送信先として、カーネル制御部ｋｃのアドレスが設定されている場合を例に挙げて、加工モジュールｐｍの第１の転送処理手順について説明する。
図１４は、実施の形態１にかかる加工モジュールｐｍの第１の転送処理手順の一例を示すフローチャートである。図１４のフローチャートにおいて、まず、加工モジュールｐｍは、コンテナｃｒ発のパケットを受信したか否かを判断する（ステップＳ１４０１）。ここで、加工モジュールｐｍは、コンテナｃｒ発のパケットを受信するのを待つ（ステップＳ１４０１：Ｎｏ）。
そして、加工モジュールｐｍは、コンテナｃｒ発のパケットを受信した場合（ステップＳ１４０１：Ｙｅｓ）、受信したパケットの宛先がカーネル制御部ｋｃであるか否かを判断する（ステップＳ１４０２）。なお、カーネル制御部ｋｃのアドレスは、加工モジュールｐｍに予め記憶されている。
ここで、パケットの宛先がカーネル制御部ｋｃではない場合（ステップＳ１４０２：Ｎｏ）、加工モジュールｐｍは、ステップＳ１４０４に移行する。一方、パケットの宛先がカーネル制御部ｋｃの場合（ステップＳ１４０２：Ｙｅｓ）、加工モジュールｐｍは、パケットのオプションヘッダに、当該パケットを受信した仮想ＮＩＣのＩＤ（仮想ＮＩＣ識別子）を書き込む（ステップＳ１４０３）。
コンテナｃｒ発のパケットを受信した仮想ＮＩＣは、コンテナｃｒ用の仮想ＮＩＣと対向接続されたコンテナ・ＯＳ間の接続用の仮想ＮＩＣである。加工モジュールｐｍは、例えば、このコンテナ・ＯＳ間の接続用の仮想ＮＩＣと対応して設けられ、このコンテナ・ＯＳ間の接続用の仮想ＮＩＣと直接接続されている。なお、コンテナ・ＯＳ間の接続用の仮想ＮＩＣのＩＤは、例えば、加工モジュールｐｍに予め記憶されている。
そして、加工モジュールｐｍは、パケットを転送して（ステップＳ１４０４）、本フローチャートによる一連の処理を終了する。これにより、加工モジュールｐｍにおいて、設定変更依頼パケットを受信した際に、設定変更依頼パケットのオプションヘッダに、設定変更依頼パケットを受信した仮想ＮＩＣのＩＤを記録することができる。
つぎに、図１５を用いて、コンテナｃｒ発の設定変更依頼パケットの送信先として、カーネル制御用の代表アドレス（特定のユニキャストアドレス）が設定されている場合を例に挙げて、加工モジュールｐｍの第２の転送処理手順について説明する。
図１５は、実施の形態１にかかる加工モジュールｐｍの第２の転送処理手順の一例を示すフローチャートである。図１５のフローチャートにおいて、まず、加工モジュールｐｍは、コンテナｃｒ発のパケットを受信したか否かを判断する（ステップＳ１５０１）。ここで、加工モジュールｐｍは、コンテナｃｒ発のパケットを受信するのを待つ（ステップＳ１５０１：Ｎｏ）。
そして、加工モジュールｐｍは、コンテナｃｒ発のパケットを受信した場合（ステップＳ１５０１：Ｙｅｓ）、受信したパケットの宛先がカーネル制御用の代表アドレスであるか否かを判断する（ステップＳ１５０２）。なお、カーネル制御用の代表アドレスは、加工モジュールｐｍに予め記憶されている。
ここで、パケットの宛先がカーネル制御用の代表アドレスではない場合（ステップＳ１５０２：Ｎｏ）、加工モジュールｐｍは、ステップＳ１５０５に移行する。一方、パケットの宛先がカーネル制御用の代表アドレスの場合（ステップＳ１５０２：Ｙｅｓ）、加工モジュールｐｍは、パケットのオプションヘッダに、当該パケットを受信した仮想ＮＩＣのＩＤ（仮想ＮＩＣ識別子）を書き込む（ステップＳ１５０３）。
つぎに、加工モジュールｐｍは、パケットのＩＰヘッダの宛先アドレスを、カーネル制御部ｋｃのアドレスに書き換える（ステップＳ１５０４）。なお、カーネル制御部ｋｃのアドレスは、加工モジュールｐｍに予め記憶されている。そして、加工モジュールｐｍは、パケットを転送して（ステップＳ１５０５）、本フローチャートによる一連の処理を終了する。
これにより、加工モジュールｐｍにおいて、設定変更依頼パケットを受信した際に、設定変更依頼パケットのオプションヘッダに、設定変更依頼パケットを受信した仮想ＮＩＣのＩＤを記録することができる。また、加工モジュールｐｍにおいて、設定変更依頼パケットの宛先アドレスを実際のカーネル制御部ｋｃのアドレスに書き換えることができる。このため、たとえコンテナｃｒの実行場所が変更になっても、変更依頼モジュールｒｍにおける設定変更依頼パケットの宛先アドレスの設定変更が不要となる。
つぎに、図１６を用いて、実施の形態１にかかるカーネル制御部ｋｃの設定変更処理手順について説明する。
図１６は、実施の形態１にかかるカーネル制御部ｋｃの設定変更処理手順の一例を示すフローチャートである。図１６のフローチャートにおいて、まず、カーネル制御部ｋｃは、設定変更依頼パケットを受信したか否かを判断する（ステップＳ１６０１）。ここで、カーネル制御部ｋｃは、設定変更依頼パケットを受信するのを待つ（ステップＳ１６０１：Ｎｏ）。
そして、カーネル制御部ｋｃは、設定変更依頼パケットを受信した場合（ステップＳ１６０１：Ｙｅｓ）、受信した設定変更依頼パケットのオプションヘッダから、仮想ＮＩＣのＩＤを取得する（ステップＳ１６０２）。この仮想ＮＩＣのＩＤは、コンテナｃｒ用の仮想ＮＩＣと対向接続され、設定変更依頼パケットを受信した仮想ＮＩＣのＩＤ（仮想ＮＩＣ識別子）である。
つぎに、カーネル制御部ｋｃは、受信した設定変更依頼パケットのペイロードから、カーネル設定の変更依頼内容を特定する（ステップＳ１６０３）。そして、カーネル制御部ｋｃは、仮想ＮＩＣ／ＯＳ対応表２００を参照して、取得した仮想ＮＩＣのＩＤ（仮想ＮＩＣ識別子）に対応するＯＳ識別子を特定する（ステップＳ１６０４）。
つぎに、カーネル制御部ｋｃは、特定したＯＳ識別子により識別されるＯＳを、依頼元のコンテナｃｒが実行されているＯＳ＃として特定する（ステップＳ１６０５）。そして、カーネル制御部ｋｃは、特定したカーネル設定の変更依頼内容に基づいて、特定したＯＳ＃のカーネルの設定を変更して（ステップＳ１６０６）、本フローチャートによる一連の処理を終了する。
これにより、カーネルの設定変更依頼を受け付けた際に、仮想ＮＩＣのＩＤから制御対象のＯＳ＃を識別して、ＯＳ＃のカーネルの設定を変更することができる。
以上説明したように、実施の形態１にかかる情報処理システム１００によれば、カーネル制御部ｋｃは、いずれかのＯＳ＃で実行されているコンテナｃｒ上で動作する変更依頼モジュールｒｍから、カーネルの設定変更依頼パケットを受信する。また、カーネル制御部ｋｃは、受信した設定変更依頼パケットから、設定変更依頼パケットを受信した仮想ＮＩＣのＩＤ（仮想ＮＩＣ識別子）を取得する。設定変更依頼パケットを受信した仮想ＮＩＣは、コンテナｃｒ用の仮想ＮＩＣと対向接続され、コンテナｃｒとＯＳ＃との間の接続用の仮想ＮＩＣである。そして、カーネル制御部ｋｃは、記憶部９１０を参照して、取得した仮想ＮＩＣのＩＤ（仮想ＮＩＣ識別子）に基づいて、コンテナｃｒが動作するＯＳ＃を特定することができる。具体的には、例えば、カーネル制御部ｋｃは、仮想ＮＩＣ／ＯＳ対応表２００を参照して、取得したＩＤ（仮想ＮＩＣ識別子）に対応するＯＳ識別子を特定し、特定したＯＳ識別子により識別されるＯＳを、コンテナｃｒが動作するＯＳ＃として特定する。
これにより、カーネルの管理権限を有しないユーザからの設定変更依頼に応じて、対象となるコンテナｃｒが稼働しているＯＳ＃を特定することができる。具体的には、例えば、設定変更時に対象となるコンテナｃｒが、異なるホストや仮想化環境で動作しているＯＳのうち、どのＯＳ＃上で動作しているかを容易に特定することができ、設定変更時のＯＳ＃の特定にかかる作業負荷および作業時間を削減することができる。
また、情報処理システム１００によれば、カーネル制御部ｋｃは、設定変更依頼パケットから特定される変更依頼内容に基づいて、特定したＯＳ＃のカーネルの設定を変更することができる。
これにより、カーネルの管理権限を有しないユーザからの設定変更依頼に応じて、対象となるコンテナｃｒが稼働しているＯＳ＃のカーネル設定を自動で変更することができ、ＯＳの設定変更にかかる作業負荷および作業時間を削減することができる。
また、情報処理システム１００によれば、加工モジュールｐｍは、設定変更依頼パケットのオプションヘッダに、設定変更依頼パケットを受信した仮想ＮＩＣのＩＤ（仮想ＮＩＣ識別子）を書き込むことができる。加工モジュールｐｍは、コンテナｃｒ用の仮想ＮＩＣと対向接続される、コンテナｃｒとＯＳ＃との間の接続用の仮想ＮＩＣと、ＯＳ＃のプロトコルスタックとの間に配置されるモジュールである。
これにより、コンテナ用仮想ＮＩＣとコンテナ／ＯＳ間の接続用仮想ＮＩＣとが１対１で対向接続されることを利用して、コンテナ／ＯＳ間の接続用仮想ＮＩＣとプロトコルスタックとの間に配置されるプログラム（いわゆる、小型ＶＭ）により、ＯＳ＃を特定するための印（仮想ＮＩＣ識別子）をパケットに付与することができる。
また、情報処理システム１００によれば、変更依頼モジュールｒｍは、設定変更依頼パケットの宛先アドレスとして、設定変更依頼用のマルチキャストアドレスを設定することができる。
これにより、コンテナｃｒの実行場所が変更になっても、変更依頼モジュールｒｍ（コンテナｃｒ）における設定変更依頼パケットの宛先アドレスの設定変更が不要となる。
また、情報処理システム１００によれば、カーネル制御部ｋｃは、受信した設定変更依頼パケットのオプションヘッダから、設定変更依頼パケットを受信した仮想ＮＩＣのＩＤ（仮想ＮＩＣ識別子）を取得することができる。オプションヘッダは、例えば、レコードルートオプションヘッダ、または、タイムスタンプオプションヘッダである。
これにより、ＩＰパケットの利用可能なオプションヘッダを用いて、設定変更依頼パケットを受信した仮想ＮＩＣのＩＤ（仮想ＮＩＣ識別子）を記録することができる。
また、情報処理システム１００によれば、加工モジュールｐｍが、設定変更依頼パケットにオプションヘッダを付与することができる。
これにより、レコードルートオプションヘッダやタイムスタンプオプションヘッダなどのオプションヘッダを利用することなく、設定変更依頼パケットのパケット形式を変更して、仮想ＮＩＣのＩＤ（仮想ＮＩＣ識別子）を記録することができる。
また、情報処理システム１００によれば、加工モジュールｐｍは、設定変更依頼パケットの宛先アドレスにカーネル制御用の代表アドレスが設定されている場合、当該宛先アドレスを、自モジュールに対応するカーネル制御用の特定アドレスに書き換えることができる。
これにより、コンテナｃｒの実行場所が変更になっても、変更依頼モジュールｒｍ（コンテナｃｒ）における設定変更依頼パケットの宛先アドレスの設定変更が不要となる。また、マルチキャストアドレスを利用する場合に比べて、設定変更依頼時の通信トラフィックを減らすことができる。
（実施の形態２）
つぎに、実施の形態２にかかる設定変更方法について説明する。実施の形態２では、カーネル制御部ｋｃをＯＳ（ホストＯＳ、ゲストＯＳ）ごとに分散配置し、ＯＳ単位で仮想ＮＩＣのＩＤ管理を行う場合について説明する。なお、実施の形態１で説明した箇所と同様の箇所については、同一符号を付して図示および説明を省略する。
図１７は、実施の形態２にかかる情報処理システム１７００のシステム構成例を示す説明図である。図１７において、情報処理システム１７００は、ネットワーク１１０を介して接続される複数の運用サーバ１０２を含む。各運用サーバ１０２上では、コンテナｃｒや仮想マシンｖｍが起動される。
図１７の例では、ある運用サーバ１０２のホストＯＳ２１０上で、仮想マシンｖｍ１とコンテナｃｒ１～ｃｒ３とが稼働している。また、ホストＯＳ２１０のユーザ空間で、カーネル制御部ｋｃ１が実行されている。ホストＯＳ２１０は、物理ＮＩＣ２１１と、仮想ブリッジ２１２，２１３と、仮想ＮＩＣ２１４～２１６と、を含む。
また、仮想マシンｖｍ１のゲストＯＳ２２０上でコンテナｃｒ４～ｃｒ６が稼働している。また、仮想マシンｖｍ１のゲストＯＳ２２０のユーザ空間で、カーネル制御部ｋｃ２が実行されている。ゲストＯＳ２２０は、仮想ＮＩＣ２２１～２２４と、仮想ブリッジ２２５とを含む。
ここで、各カーネル制御部ｋｃ１，ｋｃ２は、仮想ＮＩＣ／ＯＳ対応表１７１０を作成する。仮想ＮＩＣ／ＯＳ対応表１７１０は、自ＯＳの識別情報と、当該自ＯＳの仮想ＮＩＣの識別情報との対応関係を示す情報を記憶する。ただし、仮想ＮＩＣ／ＯＳ対応表１７１０は、予め作成されて各カーネル制御部ｋｃ１，ｋｃ２に記憶されていてもよい。
例えば、カーネル制御部ｋｃ１の自ＯＳの識別情報をＯＳ識別子「ａ」とする。この場合、カーネル制御部ｋｃ１の仮想ＮＩＣ／ＯＳ対応表１７１０には、自ＯＳのＯＳ識別子「ａ」と、自ＯＳの仮想ＮＩＣの仮想ＮＩＣ識別子とを対応付けた仮想ＮＩＣ情報（例えば、図６に示した仮想ＮＩＣ情報６００－１～６００－３）のみが記憶される。なお、仮想ＮＩＣ／ＯＳ対応表１７１０には、例えば、各仮想ＮＩＣに対応する、カーネルの制御対象モジュールを特定する情報が含まれる。より詳細に説明すると、例えば、ＯＳ識別子は、自ＯＳのカーネルの制御対象モジュールを特定する情報であってもよい。
このように、情報処理システム１７００では、ＯＳ（例えば、ホストＯＳ２１０、ゲストＯＳ２２０）ごとにカーネル制御部ｋｃ（例えば、カーネル制御部ｋｃ１，ｋｃ２）が分散配置される。このため、各カーネル制御部ｋｃは、自ＯＳ（各カーネル制御部ｋｃを実行しているＯＳ）についての仮想ＮＩＣのＩＤ管理だけを行えばよい。また、各ＯＳの仮想ＮＩＣのＩＤの整合性をＯＳ間で取る手間を省略することができる。
（設定変更依頼パケットの廃棄）
つぎに、図１８を用いて、各ＯＳ（ホストＯＳ、ゲストＯＳ）の外部接続ＮＩＣで設定変更依頼パケットを廃棄する場合について説明する。
図１８は、設定変更依頼パケットの廃棄例を示す説明図である。図１８において、検査モジュールｓｍ１は、物理ＮＩＣ２１１に対応して設けられるモジュールである。また、検査モジュールｓｍ２は、仮想ＮＩＣ２２１に対応して設けられるモジュールである。各検査モジュールｓｍ１，ｓｍ２は、例えば、プログラム（いわゆる、小型ＶＭ）により実現される。
検査モジュールｓｍ１は、物理ＮＩＣ２１１を出入りするパケットを検査する。具体的には、例えば、検査モジュールｓｍ１は、外部（ネットワーク１１０側）から物理ＮＩＣ２１１が受信したパケットの宛先アドレスが、カーネル制御部ｋｃ１のアドレスの場合、そのパケットを廃棄する。これにより、外部からの制御リクエストを装った不正なパケットを外部接続ＮＩＣで廃棄することができる。
また、検査モジュールｓｍ１は、内部（仮想マシンｖｍ、コンテナｃｒ側）物理ＮＩＣ２１１が受信したパケットのオプションヘッダに印（仮想ＮＩＣのＩＤ）が記録されている場合、そのパケットを廃棄する。これにより、外部への制御リクエストを装った不正なパケットを外部接続ＮＩＣで廃棄することができる。
検査モジュールｓｍ２は、仮想ＮＩＣ２２１を出入りするパケットを検査する。具体的には、例えば、検査モジュールｓｍ２は、外部（ホストＯＳ２１０側）から仮想ＮＩＣ２２１が受信したパケットの宛先アドレスが、カーネル制御部ｋｃ２のアドレスの場合、そのパケットを廃棄する。これにより、外部からの制御リクエストを装った不正なパケットを外部接続ＮＩＣで廃棄することができる。
また、検査モジュールｓｍ２は、内部（コンテナｃｒ側）から仮想ＮＩＣ２２１が受信したパケットのオプションヘッダに印（仮想ＮＩＣのＩＤ）が記録されている場合、そのパケットを廃棄する。これにより、外部への制御リクエストを装った不正なパケットを外部接続ＮＩＣで廃棄することができる。
このように、各ＯＳ（ホストＯＳ、ゲストＯＳ）の外部接続ＮＩＣで不正なパケットを廃棄する機能（検査モジュールｓｍ１，ｓｍ２）を設けることで、ホスト間、仮想マシン間で連携を行うことなくセキュリティを向上させることができる。
（コンテナｃｒの再配置例）
ここで、運用サーバ１０２間でのコンテナｃｒの再配置例について説明する。
図１９は、コンテナの再配置例を示す説明図である。図１９において、３台の運用サーバ１０２として、運用サーバ１０２－１，１０２－２，１０２－３が示されている。コンテナ管理サーバ１９００は、各運用サーバ１０２－１，１０２－２，１０２－３の負荷を監視し、負荷に応じてコンテナｃｒの再配置を行うコンピュータである。
再配置前の状態では、運用サーバ１０２－１のホストＯＳ１９０１上でコンテナｃｒ１１が稼働している。仮想ＮＩＣ１９１１は、コンテナｃｒ１１との接続用の仮想ＮＩＣである。加工モジュール１９１２は、仮想ＮＩＣ１９１１に対応する加工モジュールｐｍである。
また、運用サーバ１０２－２のホストＯＳ１９０２上でコンテナｃｒ２１，ｃｒ２２が稼働している。仮想ＮＩＣ１９２１は、コンテナｃｒ２１との接続用の仮想ＮＩＣである。仮想ＮＩＣ１９２２は、コンテナｃｒ２２との接続用の仮想ＮＩＣである。加工モジュール１９２３は、仮想ＮＩＣ１９２１に対応する加工モジュールｐｍである。加工モジュール１９２４は、仮想ＮＩＣ１９２２に対応する加工モジュールｐｍである。
再配置前の状態では、運用サーバ１０２－３のホストＯＳ１９０３上では、いずれのコンテナｃｒも実行されていない。このため、運用サーバ１０２－１～１０２－３のうち、運用サーバ１０２－２が高負荷状態となり、運用サーバ１０２－３が低負荷状態となっているとする。
このため、コンテナ管理サーバ１９００により、運用サーバ１０２－２上で実行されていたコンテナｃｒ２２が、運用サーバ１０２－３のホストＯＳ１９０３上に移動されたとする。ホストＯＳ１９０３の仮想ＮＩＣ１９３１は、コンテナｃｒ２２との接続用の仮想ＮＩＣである。
この場合、運用サーバ１０２－２のホストＯＳ１９０２上に加工モジュール１９２４が残ってしまう。一方、運用サーバ１０２－３のホストＯＳ１９０３上には、仮想ＮＩＣ１９３１に対応する加工モジュールｐｍが存在しないことになる。
以下、図２０～図２３を用いて、運用サーバ１０２間でのコンテナｃｒの再配置などに応じて、自動で加工モジュールｐｍのメンテナンスを行う機能について説明する。
図２０～図２３は、実施の形態２にかかるカーネル制御部ｋｃの動作例を示す説明図である。図２０において、ホストＯＳ２０００上のコンテナｃｒ１００の変更依頼モジュールｒｍは、カーネル制御部ｋｃに対して、設定変更依頼パケットＰを送信する。具体的には、例えば、変更依頼モジュールｒｍは、一定時間ごとに、カーネル制御部ｋｃに対して、設定変更依頼パケットＰを定期的に送信する。
一定時間は、任意に設定可能であり、例えば、３０秒程度の時間に設定される。すなわち、変更依頼モジュールｒｍは、カーネル設定を変更しない場合であっても、カーネル制御部ｋｃに対して、設定変更依頼パケットＰを定期的に送信する。なお、カーネル設定を変更しない場合、設定変更依頼パケットＰのペイロードには、現在のカーネル設定が依頼内容として記録される。
変更依頼モジュールｒｍから送信された設定変更依頼パケットＰは、コンテナ用仮想ＮＩＣ２００１、コンテナ・ホスト間接続用仮想ＮＩＣ２００２を経由して、加工モジュールｐｍ１００に受信される。加工モジュールｐｍ１００は、設定変更依頼パケットＰを受信すると、コンテナ・ホスト間接続用仮想ＮＩＣ２００２のＩＤを、設定変更依頼パケットＰのヘッダに書き込んで転送する。
カーネル制御部ｋｃは、設定変更依頼パケットＰを受信すると、図２４に示すような依頼管理テーブル２４００に、依頼元ＩＤおよび依頼時刻を記録する。ここで、依頼管理テーブル２４００の記憶内容について説明する。
図２４は、依頼管理テーブル２４００の記憶内容の一例を示す説明図である。図２４において、依頼管理テーブル２４００は、依頼元ＩＤおよび依頼時刻のフィールドを有し、各フィールドに情報を設定することで、依頼管理情報（例えば、依頼管理情報２４００－１）をレコードとして記憶する。
ここで、依頼元ＩＤは、カーネルの設定変更の依頼元（設定変更依頼パケットの送信元）を一意に識別する識別子である。依頼元ＩＤとしては、例えば、設定変更依頼パケットの送信元アドレスなどの依頼元のコンテナｃｒを識別する識別子を用いることにしてもよい。依頼時刻は、カーネルの設定変更を依頼された日時を示す。
例えば、依頼管理情報２４００－１は、依頼元ＩＤ「ｃｒ１００」の依頼時刻「２０１９／１２／２０ １０：００：００」を示す。ここでは、依頼元ＩＤ「ｃｒ１００」は、コンテナｃｒ１００を識別する情報であるとする。
図２０の説明に戻り、また、カーネル制御部ｋｃは、設定変更依頼パケットＰを受信すると、設定変更依頼パケットＰのヘッダから、コンテナ・ホスト間接続用仮想ＮＩＣ２００２のＩＤを取得する。カーネル制御部ｋｃは、例えば、仮想ＮＩＣ／ＯＳ対応表１７１０を参照して、取得したＩＤ（仮想ＮＩＣ識別子）から、自ＯＳの仮想ＮＩＣであることを確認する。
また、カーネル制御部ｋｃは、例えば、仮想ＮＩＣ／ＯＳ対応表１７１０を参照して、取得したＩＤ（仮想ＮＩＣ識別子）から、カーネルの制御対象モジュール２０１０を特定する。また、カーネル制御部ｋｃは、設定変更依頼パケットＰのペイロードから、カーネル設定の変更依頼内容を取得する。そして、カーネル制御部ｋｃは、特定した変更依頼内容に基づいて、制御対象モジュール２０１０の設定を変更する。
図２１において、カーネル制御部ｋｃは、新たな設定変更依頼パケットＰを受信すると、依頼管理テーブル２４００を参照して、新たな設定変更依頼パケットＰと同一の依頼元ＩＤ「ｃｒ１００」に対応する依頼時刻を現在時刻に更新する。
図２２において、ホストＯＳ２０００上のコンテナｃｒ１００が引っ越しなどにより停止している。カーネル制御部ｋｃは、依頼管理テーブル２４００を参照して、依頼元ＩＤ「ｃｒ１００」に対応する依頼時刻から所定時間Ｔが経過したか否かを判断する。所定時間Ｔは、任意に設定可能であり、例えば、３分～５分程度の時間に設定される。ここで、依頼元ＩＤ「ｃｒ１００」に対応する依頼時刻から所定時間Ｔが経過した場合、カーネル制御部ｋｃは、依頼元ＩＤ「ｃｒ１００」に対応する制御依頼の有効期限切れを検出する。
図２３において、カーネル制御部ｋｃは、依頼元ＩＤ「ｃｒ１００」に対応する制御依頼の有効期限切れを検出した場合、依頼元ＩＤ「ｃｒ１００」により識別されるコンテナｃｒ１００の加工モジュールｐｍ１００を削除する。また、カーネル制御部ｋｃは、制御対象モジュール２０１０の設定を初期設定に変更する。
これにより、運用サーバ１０２間でのコンテナｃｒの再配置などに応じて、加工モジュールｐｍのメンテナンスを自動で行うことができる。
（情報処理システム１７００の各種処理手順）
つぎに、実施の形態２にかかる情報処理システム１７００の各種処理手順について説明する。まず、図２５を用いて、検査モジュールｓｍ（例えば、図１８に示した検査モジュールｓｍ１，ｓｍ２）の検査処理手順について説明する。ここでは、外部からの制御リクエストを装った不正なパケットを廃棄するための検査処理を例に挙げて説明する。
図２５は、実施の形態２にかかる検査モジュールｓｍの検査処理手順の一例を示すフローチャートである。図２５のフローチャートにおいて、まず、検査モジュールｓｍは、外部からのパケットを受信したか否かを判断する（ステップＳ２５０１）。ここで、検査モジュールｓｍは、パケットを受信するのを待つ（ステップＳ２５０１：Ｎｏ）。
そして、検査モジュールｓｍは、パケットを受信した場合（ステップＳ２５０１：Ｙｅｓ）、パケットの宛先アドレスが、カーネル制御部ｋｃのアドレスであるか否かを判断する（ステップＳ２５０２）。ここで、カーネル制御部ｋｃのアドレスではない場合（ステップＳ２５０２：Ｎｏ）、検査モジュールｓｍは、パケットを転送して（ステップＳ２５０３）、本フローチャートによる一連の処理を終了する。
一方、カーネル制御部ｋｃのアドレスの場合（ステップＳ２５０２：Ｙｅｓ）、検査モジュールｓｍは、パケットを廃棄して（ステップＳ２５０４）、本フローチャートによる一連の処理を終了する。これにより、外部からの制御リクエストを装った不正なパケットを外部接続ＮＩＣで廃棄することができる。
つぎに、図２６を用いて、実施の形態２にかかる変更依頼モジュールｒｍの変更依頼処理手順について説明する。
図２６は、実施の形態２にかかる変更依頼モジュールｒｍの変更依頼処理手順の一例を示すフローチャートである。図２６のフローチャートにおいて、まず、変更依頼モジュールｒｍは、カーネル制御部ｋｃに対して、設定変更依頼パケットを送信する（ステップＳ２６０１）。
つぎに、変更依頼モジュールｒｍは、設定変更依頼パケットを送信してから一定時間が経過したか否かを判断する（ステップＳ２６０２）。ここで、変更依頼モジュールｒｍは、一定時間が経過するのを待つ（ステップＳ２６０２：Ｎｏ）。そして、変更依頼モジュールｒｍは、一定時間が経過した場合（ステップＳ２６０２：Ｙｅｓ）、ステップＳ２６０１に戻る。
これにより、コンテナｃｒの変更依頼モジュールｒｍからカーネル制御部ｋｃに対して、設定変更依頼パケットＰを定期的に送信することができる。
つぎに、図２７および図２８を用いて、実施の形態２にかかるカーネル制御部ｋｃの設定変更処理手順について説明する。まず、図２７を用いて、カーネル制御部ｋｃの第１の設定変更処理手順について説明する。
図２７は、実施の形態２にかかるカーネル制御部ｋｃの第１の設定変更処理手順の一例を示すフローチャートである。図２７のフローチャートにおいて、まず、カーネル制御部ｋｃは、設定変更依頼パケットを受信したか否かを判断する（ステップＳ２７０１）。ここで、カーネル制御部ｋｃは、設定変更依頼パケットを受信するのを待つ（ステップＳ２７０１：Ｎｏ）。
そして、カーネル制御部ｋｃは、設定変更依頼パケットを受信した場合（ステップＳ２７０１：Ｙｅｓ）、受信した設定変更依頼パケットのオプションヘッダから、仮想ＮＩＣのＩＤを取得する（ステップＳ２７０２）。つぎに、カーネル制御部ｋｃは、受信した設定変更依頼パケットのペイロードから、カーネル設定の変更依頼内容を特定する（ステップＳ２７０３）。
そして、カーネル制御部ｋｃは、仮想ＮＩＣ／ＯＳ対応表１７１０などを参照して、取得した仮想ＮＩＣのＩＤから、カーネルの制御対象モジュールを特定する（ステップＳ２７０４）。つぎに、カーネル制御部ｋｃは、依頼管理テーブル２４００を参照して、依頼元に対応する依頼管理情報があるか否かを判断する（ステップＳ２７０５）。依頼元は、設定変更依頼パケットの送信元である。
ここで、依頼元に対応する依頼管理情報がない場合（ステップＳ２７０５：Ｎｏ）、カーネル制御部ｋｃは、依頼元に対応する依頼管理情報を新規登録して（ステップＳ２７０６）、ステップＳ２７０９に移行する。依頼管理情報には、依頼元の依頼元ＩＤと、依頼時刻（現在時刻）とが含まれる。
一方、依頼元に対応する依頼管理情報がある場合（ステップＳ２７０５：Ｙｅｓ）、カーネル制御部ｋｃは、依頼管理テーブル２４００内の依頼元に対応する依頼管理情報の依頼時刻を現在時刻に更新する（ステップＳ２７０７）。そして、カーネル制御部ｋｃは、変更依頼内容に変更があるか否かを判断する（ステップＳ２７０８）。
なお、変更の有無を判断するにあたり、カーネル制御部ｋｃは、例えば、今回の変更依頼内容と、現在のカーネル設定内容と比較して判断してもよい。また、前回の変更依頼内容が記録されている場合には、カーネル制御部ｋｃは、今回の変更依頼内容と、前回の変更依頼内容とを比較して、変更の有無を判断することにしてもよい。
ここで、変更依頼内容に変更がない場合（ステップＳ２７０８：Ｎｏ）、カーネル制御部ｋｃは、本フローチャートによる一連の処理を終了する。一方、変更依頼内容に変更がある場合（ステップＳ２７０８：Ｙｅｓ）、カーネル制御部ｋｃは、特定したカーネル設定の変更依頼内容に基づいて、特定した制御対象モジュールの設定を変更して（ステップＳ２７０９）、本フローチャートによる一連の処理を終了する。
これにより、カーネルの設定変更依頼を受け付けた際に、仮想ＮＩＣのＩＤから制御対象モジュールを識別して、カーネル設定を変更することができる。
つぎに、図２８を用いて、カーネル制御部ｋｃの第２の設定変更処理手順について説明する。第２の設定変更処理は、例えば、３０秒程度の一定時間ごとに実行される。
図２８は、実施の形態２にかかるカーネル制御部ｋｃの第２の設定変更処理手順の一例を示すフローチャートである。図２８のフローチャートにおいて、まず、カーネル制御部ｋｃは、依頼管理テーブル２４００から選択されていない未選択の依頼管理情報を選択する（ステップＳ２８０１）。
つぎに、カーネル制御部ｋｃは、選択した依頼管理情報の依頼時刻と現在時刻との差分Δｔを算出する（ステップＳ２８０２）。そして、カーネル制御部ｋｃは、算出した差分Δｔが所定時間Ｔより大きいか否かを判断する（ステップＳ２８０３）。ここで、差分Δｔが所定時間Ｔ以下の場合（ステップＳ２８０３：Ｎｏ）、カーネル制御部ｋｃは、ステップＳ２８０７に移行する。
一方、差分Δｔが所定時間Ｔより大きい場合（ステップＳ２８０３：Ｙｅｓ）、カーネル制御部ｋｃは、選択した依頼管理情報の依頼元ＩＤから特定される制御対象モジュールのカーネル設定をデフォルトに戻す（ステップＳ２８０４）。制御対象モジュールは、依頼元のコンテナｃｒに割り当てられているモジュールである。
つぎに、カーネル制御部ｋｃは、選択した依頼管理情報の依頼元ＩＤから特定されるコンテナｃｒに対応する加工モジュールｐｍを削除する（ステップＳ２８０５）。そして、カーネル制御部ｋｃは、選択した依頼管理情報を依頼管理テーブル２４００から削除する（ステップＳ２８０６）。
つぎに、カーネル制御部ｋｃは、依頼管理テーブル２４００から選択されていない未選択の依頼管理情報があるか否かを判断する（ステップＳ２８０７）。ここで、未選択の依頼管理情報がある場合（ステップＳ２８０７：Ｙｅｓ）、カーネル制御部ｋｃは、ステップＳ２８０１に戻る。
一方、未選択の依頼管理情報がない場合（ステップＳ２８０７：Ｎｏ）、カーネル制御部ｋｃは、本フローチャートによる一連の処理を終了する。これにより、コンテナｃｒの引っ越しなどに応じて、加工モジュールｐｍのメンテナンスを自動で行うことができる。
以上説明したように、実施の形態２にかかる情報処理システム１７００によれば、各カーネル制御部ｋｃにおいて自ＯＳについての仮想ＮＩＣのＩＤ管理だけを行えばよく、各ＯＳの仮想ＮＩＣのＩＤの整合性をＯＳ間で取る手間を省略することができる。
また、情報処理システム１７００によれば、各ＯＳ（ホストＯＳ、ゲストＯＳ）の外部接続ＮＩＣに対応する検査モジュールｓｍにおいて、制御リクエストを装った不正なパケットを廃棄することができる。
また、情報処理システム１７００によれば、運用サーバ１０２間でのコンテナｃｒの再配置などに応じて、加工モジュールｐｍのメンテナンスを自動で行うことができる。
なお、実施の形態１，２で説明した設定変更方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本設定変更プログラムは、ハードディスク、フレキシブルディスク、ＣＤ－ＲＯＭ、ＤＶＤ、ＵＳＢメモリ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また、本設定変更プログラムは、インターネット等のネットワークを介して配布してもよい。
また、実施の形態１，２で説明したカーネル制御部ｋｃは、スタンダードセルやストラクチャードＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）などの特定用途向けＩＣやＦＰＧＡなどのＰＬＤ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｄｅｖｉｃｅ）によっても実現することができる。
上述した実施の形態に関し、さらに以下の付記を開示する。
（付記１）いずれかのＯＳで実行されているコンテナ上で動作するソフトウェアから、カーネルの設定変更依頼パケットを受信し、
受信した前記設定変更依頼パケットから、前記設定変更依頼パケットを受信した通信モジュールの識別情報を取得し、
ＯＳの識別情報と前記ＯＳの通信モジュールの識別情報との対応関係を示す情報を記憶する記憶部を参照して、取得した前記通信モジュールの識別情報に基づいて、前記コンテナが動作するＯＳを特定する、
処理をコンピュータが実行することを特徴とする設定変更方法。
（付記２）前記設定変更依頼パケットから特定される変更依頼内容に基づいて、特定した前記ＯＳのカーネルの設定を変更する、
処理を前記コンピュータが実行することを特徴とする付記１に記載の設定変更方法。
（付記３）前記設定変更依頼パケットを受信した通信モジュールは、前記コンテナ用の通信モジュールと対向接続される、前記コンテナと前記いずれかのＯＳとの間の接続用の通信モジュールである、ことを特徴とする付記１または２に記載の設定変更方法。
（付記４）前記設定変更依頼パケットを受信した通信モジュールの識別情報は、前記設定変更依頼パケットのオプションヘッダに書き込まれる、ことを特徴とする付記１～３のいずれか一つに記載の設定変更方法。
（付記５）前記設定変更依頼パケットの宛先アドレスには、設定変更依頼用のマルチキャストアドレスが設定される、ことを特徴とする付記１～４のいずれか一つに記載の設定変更方法。
（付記６）前記設定変更依頼パケットを受信した通信モジュールの識別情報は、前記接続用の通信モジュールに対応して設けられる加工モジュールによって、前記設定変更依頼パケットのオプションヘッダに書き込まれる、ことを特徴とする付記３に記載の設定変更方法。
（付記７）前記設定変更依頼パケットの宛先アドレスは、当該宛先アドレスにカーネル制御用の代表アドレスが設定されている場合、前記加工モジュールによって、前記加工モジュールに対応するカーネル制御用の特定アドレスに書き換えられる、ことを特徴とする付記６に記載の設定変更方法。
（付記８）前記コンピュータは、ＯＳごとに配置され、
自ＯＳで実行されているコンテナ上で動作するソフトウェアから、カーネルの設定変更依頼パケットを受信し、
受信した前記設定変更依頼パケットから、前記設定変更依頼パケットを受信した通信モジュールの識別情報を取得し、
自ＯＳの識別情報と前記自ＯＳの通信モジュールの識別情報との対応関係を示す情報を記憶する記憶部を参照して、取得した前記通信モジュールの識別情報に基づいて、自ＯＳのカーネルの制御対象モジュールを特定する、
処理を前記コンピュータが実行することを特徴とする付記６に記載の設定変更方法。
（付記９）前記設定変更依頼パケットから特定される変更依頼内容に基づいて、特定した前記制御対象モジュールの設定を変更する、
処理を前記コンピュータが実行することを特徴とする付記８に記載の設定変更方法。
（付記１０）前記設定変更依頼パケットは、前記ソフトウェアから定期的に送信され、
前記コンピュータが、
前記設定変更依頼パケットを直前に受信してからの経過時間が所定時間を超えた場合、前記変更依頼内容に基づき変更された前記制御対象モジュールの設定をデフォルトに戻す、
処理を実行することを特徴とする付記９に記載の設定変更方法。
（付記１１）前記設定変更依頼パケットを直前に受信してからの経過時間が所定時間を超えた場合、前記加工モジュールを削除する、ことを特徴とする付記１０に記載の設定変更方法。
（付記１２）前記通信モジュールは、仮想ＮＩＣである、ことを特徴とする付記１～１１のいずれか一つに記載の設定変更方法。
（付記１３）前記オプションヘッダは、レコードルートオプションヘッダ、または、タイムスタンプオプションヘッダである、ことを特徴とする付記４に記載の設定変更方法。
（付記１４）前記オプションヘッダは、前記加工モジュールによって前記設定変更依頼パケットに付与される、ことを特徴とする付記６に記載の設定変更方法。
（付記１５）いずれかのＯＳで実行されているコンテナ上で動作するソフトウェアから、カーネルの設定変更依頼パケットを受信し、
受信した前記設定変更依頼パケットから、前記設定変更依頼パケットを受信した通信モジュールの識別情報を取得し、
ＯＳの識別情報と前記ＯＳの通信モジュールの識別情報との対応関係を示す情報を記憶する記憶部を参照して、取得した前記通信モジュールの識別情報に基づいて、前記コンテナが動作するＯＳを特定する、
処理をコンピュータに実行させることを特徴とする設定変更プログラム。
１００，１７００ 情報処理システム
１０１ 設定管理サーバ
１０２ 運用サーバ
１１０ ネットワーク
２００，１７１０ 仮想ＮＩＣ／ＯＳ対応表
４００，１９１２，１９２３，１９２４，ｐｍ 加工モジュール
８００ バス
８０１ ＣＰＵ
８０２ メモリ
８０３ ディスクドライブ
８０４ ディスク
８０５ 通信Ｉ／Ｆ
８０６ 可搬型記録媒体Ｉ／Ｆ
８０７ 可搬型記録媒体
９０１ 通信部
９０２ 特定部
９０３ 変更部
９０４ 出力部
９１０ 記憶部
１９００ コンテナ管理サーバ
２４００ 依頼管理テーブル
ｃｒ コンテナ

Claims (8)

  1. いずれかのＯＳで実行されているコンテナ上で動作するソフトウェアから、カーネルの設定変更依頼パケットを受信し、
    受信した前記設定変更依頼パケットから、前記設定変更依頼パケットを受信した通信モジュールの識別情報を取得し、
    ＯＳの識別情報と前記ＯＳの通信モジュールの識別情報との対応関係を示す情報を記憶する記憶部を参照して、取得した前記通信モジュールの識別情報に基づいて、前記コンテナが動作するＯＳを特定する、
    処理をコンピュータが実行することを特徴とする設定変更方法。
  2. 前記設定変更依頼パケットから特定される変更依頼内容に基づいて、特定した前記ＯＳのカーネルの設定を変更する、
    処理を前記コンピュータが実行することを特徴とする請求項１に記載の設定変更方法。
  3. 前記設定変更依頼パケットを受信した通信モジュールは、前記コンテナ用の通信モジュールと対向接続される、前記コンテナと前記いずれかのＯＳとの間の接続用の通信モジュールである、ことを特徴とする請求項１または２に記載の設定変更方法。
  4. 前記設定変更依頼パケットを受信した通信モジュールの識別情報は、前記設定変更依頼パケットのオプションヘッダに書き込まれる、ことを特徴とする請求項１～３のいずれか一つに記載の設定変更方法。
  5. 前記設定変更依頼パケットの宛先アドレスには、設定変更依頼用のマルチキャストアドレスが設定される、ことを特徴とする請求項１～４のいずれか一つに記載の設定変更方法。
  6. 前記設定変更依頼パケットを受信した通信モジュールの識別情報は、前記接続用の通信モジュールに対応して設けられる加工モジュールによって、前記設定変更依頼パケットのオプションヘッダに書き込まれる、ことを特徴とする請求項３に記載の設定変更方法。
  7. 前記コンピュータは、ＯＳごとに配置され、
    自ＯＳで実行されているコンテナ上で動作するソフトウェアから、カーネルの設定変更依頼パケットを受信し、
    受信した前記設定変更依頼パケットから、前記設定変更依頼パケットを受信した通信モジュールの識別情報を取得し、
    自ＯＳの識別情報と前記自ＯＳの通信モジュールの識別情報との対応関係を示す情報を記憶する記憶部を参照して、取得した前記通信モジュールの識別情報に基づいて、自ＯＳのカーネルの制御対象モジュールを特定する、
    処理を前記コンピュータが実行することを特徴とする請求項６に記載の設定変更方法。
  8. いずれかのＯＳで実行されているコンテナ上で動作するソフトウェアから、カーネルの設定変更依頼パケットを受信し、
    受信した前記設定変更依頼パケットから、前記設定変更依頼パケットを受信した通信モジュールの識別情報を取得し、
    ＯＳの識別情報と前記ＯＳの通信モジュールの識別情報との対応関係を示す情報を記憶する記憶部を参照して、取得した前記通信モジュールの識別情報に基づいて、前記コンテナが動作するＯＳを特定する、
    処理をコンピュータに実行させることを特徴とする設定変更プログラム。
JP2020003666A 2020-01-14 2020-01-14 設定変更方法および設定変更プログラム Active JP7338481B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2020003666A JP7338481B2 (ja) 2020-01-14 2020-01-14 設定変更方法および設定変更プログラム
EP20208046.1A EP3851988B1 (en) 2020-01-14 2020-11-17 Setting change method and setting change program
US17/103,745 US11722368B2 (en) 2020-01-14 2020-11-24 Setting change method and recording medium recording setting change program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2020003666A JP7338481B2 (ja) 2020-01-14 2020-01-14 設定変更方法および設定変更プログラム

Publications (2)

Publication Number Publication Date
JP2021111197A JP2021111197A (ja) 2021-08-02
JP7338481B2 true JP7338481B2 (ja) 2023-09-05

Family

ID=73455595

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020003666A Active JP7338481B2 (ja) 2020-01-14 2020-01-14 設定変更方法および設定変更プログラム

Country Status (3)

Country Link
US (1) US11722368B2 (ja)
EP (1) EP3851988B1 (ja)
JP (1) JP7338481B2 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100306358A1 (en) 2009-05-29 2010-12-02 Sun Microsystems, Inc. Handling of multiple mac unicast addresses with virtual machines
US20180046457A1 (en) 2017-10-26 2018-02-15 Iomaxis, Llc Method and system for enhancing application container and host operating system security in a multi-tenant computing environment
US20180357068A1 (en) 2016-06-13 2018-12-13 Dynatrace Llc Method And System For Automated Agent Injection In Container Environments

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4622835B2 (ja) * 2005-12-07 2011-02-02 株式会社日立製作所 仮想計算機システム及びそのネットワーク通信方法
US8099615B2 (en) * 2008-06-30 2012-01-17 Oracle America, Inc. Method and system for power management in a virtual machine environment without disrupting network connectivity
JP5476261B2 (ja) 2010-09-14 2014-04-23 株式会社日立製作所 マルチテナント型情報処理システム、管理サーバ及び構成管理方法
JP5888331B2 (ja) * 2010-12-28 2016-03-22 日本電気株式会社 ネットワーク仮想化システム、物理ノード及び仮想マシンにおける仮想インタフェース識別方法
JP6394455B2 (ja) * 2015-03-24 2018-09-26 富士通株式会社 情報処理システム、管理装置およびプログラム
US9870248B2 (en) * 2015-08-13 2018-01-16 Red Hat Israel, Ltd. Page table based dirty page tracking
US10063469B2 (en) * 2015-12-16 2018-08-28 Nicira, Inc. Forwarding element implementation for containers
JP6487359B2 (ja) 2016-03-16 2019-03-20 Kddi株式会社 ネットワークサービス評価システム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100306358A1 (en) 2009-05-29 2010-12-02 Sun Microsystems, Inc. Handling of multiple mac unicast addresses with virtual machines
US20180357068A1 (en) 2016-06-13 2018-12-13 Dynatrace Llc Method And System For Automated Agent Injection In Container Environments
US20180046457A1 (en) 2017-10-26 2018-02-15 Iomaxis, Llc Method and system for enhancing application container and host operating system security in a multi-tenant computing environment

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
森側 真一，入門者歓迎、中級者もスキルアップ！ Ｌｉｎｕｘ超マスター１００ステップ，日経Ｌｉｎｕｘ，日本，日経ＢＰ社，2012年04月，第１４巻 第４号，pp. 65-74
滝澤 隆史，意外と知らない すぐに役立つ サーバー・フリーソフト 第５回 仮想化ソフトウェア「ＯｐｅｎＶＺ」，日経Ｌｉｎｕｘ，日本，日経ＢＰ社，2009年02月，第１１巻 第２号，pp. 140-147

Also Published As

Publication number Publication date
JP2021111197A (ja) 2021-08-02
EP3851988B1 (en) 2024-04-10
US20210218627A1 (en) 2021-07-15
US11722368B2 (en) 2023-08-08
EP3851988A1 (en) 2021-07-21

Similar Documents

Publication Publication Date Title
JP6974218B2 (ja) ストレージシステム及びその動作方法
US10671289B2 (en) Tenant-level sharding of disks with tenant-specific storage modules to enable policies per tenant in a distributed storage system
CN110865867B (zh) 应用拓扑关系发现的方法、装置和系统
US9542404B2 (en) Subpartitioning of a namespace region
US9110694B2 (en) Data flow affinity for heterogenous virtual machines
US20150234846A1 (en) Partitioning file system namespace
US20210250223A1 (en) Storage System for Network Information
CN111837358B (zh) 网络中时间同步的方法及系统
CN112583618B (zh) 为业务提供网络服务的方法、装置和计算设备
CN110798541B (zh) 接口共享、报文转发方法、装置、电子设备及存储介质
CN109857545B (zh) 一种数据传输方法及装置
JP5457916B2 (ja) メモリ共有装置
US9858096B2 (en) Communication device migration method of extension function and communication system
CN111327651A (zh) 资源下载方法、装置、边缘节点及存储介质
JP7338481B2 (ja) 設定変更方法および設定変更プログラム
US20120265860A1 (en) Sharing A Hosted Device In A Computer Network
CN112751717B (zh) 一种业务流量的管理系统以及方法
CN111245698B (zh) 用于操作网络装置的方法和设备
WO2024003962A1 (ja) コンテナ移行装置、コンテナ移行方法およびコンテナ移行プログラム
Mullender Predictable cloud computing
CN112631727B (zh) 一种容器组pod的监控方法及装置
US20190286348A1 (en) Storage device, control method, and control program
US10630762B1 (en) Multicast network emulation
US20210036890A1 (en) Allocation of tokens for network packets based on application type
CN116401227A (zh) 一种集群配置方法、装置、设备及介质

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20220908

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20230725

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20230726

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20230807

R150 Certificate of patent or registration of utility model

Ref document number: 7338481

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150