Kuroyuri(「くろゆり」と読んでください) はネットワーク実験支援ソフトウェア群 SpringOS の一部で、 実験遂行を担当します。 スクリプト実行システムと考えて差し支えありません。 スクリプトは「K言語」と呼ばれています。 このページでは kuroyuri の原理や使い方、 そして K言語について紹介します。

ネットワーク実験は数十台・数百台の計算機から一斉に通信が開始したり、 ランダムに通信したり、分散処理の側面があります。 数台なら手作業で通信を指示できますが、 それ以上になると困難になります。 この類の実験は繰り返し実施されることが多いので、 手作業を何度も繰り返すとなると、 毎回同じように実施するのは非常に困難です。 そこで、自動化が重要となってきます。 kuroyuri はスクリプト言語を含んでいて、 ネットワーク実験の大部分を自動化可能です。 これまでの実績では最大 250台の実験を扱うことができました。 それより大きな実験をしている例がないので実効最大台数はまだ不明です。 まだまだ大きな実験が扱えるかもしれません。

kuroyuri は対象計算機のディスクイメージの書き換えも可能で、 OSの配布も自動化可能です。 電源投入やシャットダウンも自動化しています。 また、多数の計算機を使う際には、 何らかの原因で起動しない、 通信に応えないなどの障害をもつ計算機もでてきます。 全てを網羅することはできませんが、 kuroyuri は予備計算機を設けることで、 起動時の障害を回避する機能を持ちます。

kuroyuri のスクリプト言語であるK言語は、 複数計算機へ命令を逐次送って実行するだけではなく、 命令を集めて(命令列)送って実行するため、 命令転送の効率が高まり、 ループや条件分岐も容易に表現可能です。

K言語のスクリプトは 各計算機と中央の管理計算機の間でメッセージを交換可能です。 このメッセージ交換を使って、 計算機間で各種パラメータや命令を伝えることができます。 また、各計算機の処理の歩調を合わせるために、 メッセージによるバリア同期も記述できます。 「サーバが起動した後に、クライアントを起動」というような、 計算機をまたがった順序が重要な処理が容易に記述可能です。

ネットワーク実験では、 「サーバを10台」「クライアントを20台」というように、 同じ役割の計算機を多数設ける場面が頻繁に出てきます。 kuroryuri では記述の簡略化とミス防止のため、 実験で登場する計算機をクラス化して扱える機構を設けています。 この機構のおかげで、 台数が変更になってもスクリプトの変更は少なくて済みます。

ソースコードは全て公開しています。 StarBED で開発しましたので、 StarBED 由来の前提もいくつかありますが、 条件が揃えば他の施設・設備でも利用可能でしょう。 現に、いつかの組織で使われています。 なお、UNIX向けに開発しており、 WINDOWS や Mac での実績はありません。

他の方法との議論は後述します >>。

kuroyuri は実験装置で動くK言語評価器(プログラム)と、 それらを取りまとめるK言語評価器で構成されています。 この全体をまとめるプログラムを支配する側として「マスタ」(master)、 支配される側を「スレーブ」(slave)と呼びます。

マスタが多数のスレーブを支配する

K言語は宣言文と実行文に分かれていて、 宣言文はノード(後述)やネットワークのクラスやインスタンスの定義を行います。 実行文では、代入や演算、値の出力、条件分岐等、多岐にわたります。

宣言文例:

node server {
    netif media fastethernet
    scenario {
        print self.name
    }
}

実行文例:

a = 13
b = a/4
print b

なお、以下の文章では「構文を評価する」という意味で、 「評価」という言葉が多数で出て来ますが、 「実行」と読みかえてもらっても差し支えありません。

kuroyuri は実験の遂行を支援するプログラムで、 実験内容は直接扱えません。 実験を行う専用のプログラムを用意することが必要です。 つまり、別のプログラムを kuroyuri から呼び出します。 したがって、 kuroyuri を用いたネットワーク実験の大部分は外部プログラムの実行になります。

外部プログラムの実行は call構文を用いて以下のように行います。 これは UNIX の exec システムコールに準拠したものです。

call "/bin/ls"

外部プログラムの単純に実行するだけでなく、 その実行終了を待ちたい場面もあります。 その際には callw 構文を使ってください。

callw "/bin/ls"

SpringOS では実験の主体となる計算機を「ノード」と呼びます。 これは前述のスレーブ評価器が稼働している計算機です。 実験では多数のノードが同じような仕様や役割を担当するので、 同じ仕様や役割をまとめて宣言するために、 「ノードクラス」という機構が用意されています。 ノードクラスはノードの種で、 同時に複数のノードをノード集合を宣言します。

次の記述例中のノード集合 httpd は ノードクラス apache を元にした 7つのノードです。 各ノードの内容は前述の server と同じです。

nodeclass apache {
    netif media fastethernet
    scenario {
        print self.name
    }
}
nodeset httpd class apache num 7

シナリオは構文の列です。 ノードで実行される構文はノードあるいはクラス定義中の scenario 構文で囲まれた部分です。 ここでは、これをノードシナリオ(node scenario)と呼びます。 ノードシナリオは kuroyuri 実行時に スレーブ評価器で評価されることになります。 一方、残りの部分はマスター評価器で評価されますが、 scenario 構文で書かれた箇所を特にグローバルシナリオ(global scenario) と呼びます。

...
nodeclass A {
    ...
    scenario {
        ...
        ノードシナリオ
        ...
    }
}
...
scenario {
    ...
   グローバルシナリオ
    ...
}

ネットワーク・トポロジは attach構文で ネットワーク・インターフェイスのネットワークへの接続を記述します。 二つのノード A,B がネットワーク core,leaf に以下のように接続している場合、 次のように記述します。

アタッチ例

node A {
    netif media fastethernet
    netif media fastethernet
    scenario {
    }
}
node B {
    netif media fastethernet
    netif media fastethernet
    scenario {
    }
}
net leaf {
    media fastethernet
}
net core {
    media fastethernet
}

attach A.netif[0] leaf
attach A.netif[1] core
attach B.netif[0] core
attach B.netif[1] leaf

kuroyuri では変数(variables)を使うことができます。 数字や文字列等を格納して、繰り返し使用可能です。 これは記述ミスの防止にもつながります。

v1 = 133
str1 = "Japan Advaced Institute of Science and Technology"
str2 = "School of Information Science"
str3 = str2 + ", " + str1
print v1
print v1*8
print v1/4
print str1
print str2
print str3

export 構文でマスタからスレーブへ変数を伝えることも可能です。 ただし、この変数の伝達は前述のようにノードを設定した際に行われますので、 値を代入する度に伝達されるわけではありません。 たとえば、以下のようなスクリプトを実行すると、 ノードAで出力されるのは 31です。

foo=31
export foo

node A {
    ...
    scenario {
        print foo
    }
}

scenario {
    foo=75
}

kuroyuri はマスタ-スレーブ間で文字列を交換可能です。 スレーブ間では交換できませんので注意してください。 スレーブ間の通信はプログラムが非常に繁雑で、 負荷も高いために実装していません。

メッセージ交換は send, recv 構文を用います。 たとえば、マスタでは以下のように

send client[3] "start"
recv client[7] res

スレーブでは通信相手はマスタしかいませんので、 通信相手の記述は不要です。

recv cmd
send "ok"

複数の計算機に処理を任せる際には、 ある計算機のなんらかの処理が済んだ後に、 次の処理に進むような場面が出て来ます。 このような順序を容易に記述できるよう。 kuroyuri はスレーブからのメッセージを待機する機能があります。 sync 構文で条件を記述します。 次の例は、 クライアントとサーバへ「START」のメッセージを送ります。 その後、クライアントの「OK」のメッセージを待って、 サーバへ「STOP」のメッセージを送ります。

send server "START"
send client "START"
sync {
    msgmatch client "OK"
}
send sever "STOP"

sync構文の条件は複数記述できます。 たとえば、クライアントが二つある場合は、 以下のように記述します。

sync {
    msgmatch client[0] "OK"
    msgmatch client[1] "OK"
}

kuroyuri の実行では以下のようなプログラム群を用います。

シェル:

多くのOSや計算機システムではシェルと呼ばれるスクリプト機能を持っています。 それを使えば、ある程度の自動化が実現できます。 しかし、それらの多くは計算機の内部を扱うもので、 複数の計算機にまたがる処理は扱えません。

分散シェル:

シェルの複数計算機にまたがる処理が扱えない欠点を補うため、 分散シェルと呼ばれるシステムが登場しています。 これを用いると、多数の計算機に命令を送りこんで実行できます。 ただし、シェルは予備ノードやメッセージ交換のような先進的な機能も、 クラス等 kuroyuri のもつ便利な機能を持ちません。

• StarBED Project
• SpringOS

• Toshiyuki Miyachi, Ken-ichi Chinen and Yoichi Shinoda: "Automatic Configuration and Driving Internet Experiments On An Actual Node-base Testbed" , Tridentcom2005, pp.274-282, Trento, ISBN 0-7695-2219-X, 2005
• Ken-ichi Chinen, Toshiyuki Miyachi and Yoichi Shinoda: "A Rendezvous in Network Experiment --- Case Study of Kuroyuri" , Tridentcom2006, Barcelona, ISBN 1-4244-0106-2, 2006
• Toshiyuki Miyachi, Ken-ichi Chinen and Yoichi Shinoda: "StarBED and SpringOS:Large-scale General Purpose Network Testbed and Support System for Experiments" , ValueTools2006, Pisa, 2006

くろゆりは SpringOS の開発場所である北陸の名所 白山の有名な花です。 地元に由来する名前をつけようと考え、この名前にしました。 このページ先頭の花の絵がくろゆりです。 佐野さんの撮られた写真をもとに作成しました。 佐野さんありがとうございました。

知念