ZTP?
Zero Touch Provisioning 略してZTP。
通常、PCやサーバ、あるいはネットワーク機器は、ケーブルをつないで電源を入れただけで定常運用状態にならず、人間の手による初期設定処理が必要です。たとえば、WindowsがプリインストールされているPCの場合、起動するとライセンスの確認やタイムゾーンの指定、キーボードレイアウトの確認、アカウント情報の入力などが求められ、キーボードやマウスを使って操作することで初めてWindowsを使えるようセットアップが完了するという流れになります。
こういった手動設定をなくすための手法はいくつかあります。たとえば顧客を特定し出荷前に顧客ごとの設定をあらかじめ書き込んで出荷することで、受け取った顧客は電源投入するだけでよい、といった手法があります。
上記の手法は出荷側に多大な負担がかかるのですが、別のやり方として、機器を接続するネットワーク上に仕掛けを用意しておくことで、CLIやGUIの操作を全く介さずに自動的に設定を完了させるという手法があります。この自動設定の一連の処理やフレームワークをZTPと呼びます。
ホワイトボックススイッチにおけるZTP
ホワイトボックススイッチにおけるZTPはおおよそ下記の2段階に分けられます。
- ONIEによる自動OSインストール
- OSのZTP機能による自動初期設定
ホワイトボックススイッチは「OSがインストールされてないネットワークスイッチ製品」であるため、完全なZTPを実現するにはOSインストール部分から自動化できている必要があり、すでにそのための仕組みは用意されているのです。
ONIEによる自動OSインストール
ONIEとは、Open Network Install Environmentの頭文字をとったもので、「オープンネットワーキング」対応のホワイトボックススイッチにおいて事実上標準と言えるOSインストーラーです。事実上標準というのは、たいていの製品で出荷時にプリインストールされているということを意味します。
ONIEの正体は、ホワイトボックススイッチに用意されているシリアルコンソールやマネジメントポートといった独自ハードウェアに対応し、IP通信によってOSインストールイメージを読み込み内蔵ストレージに展開できる機能を持つ、ごく小さなLinuxディストリビューションです。
ONIE自体の話を書き出すとそれはそれで長くなるのでかいつまんで説明すると、IA-32/AMD64のプロセッサで制御されるホワイトボックススイッチにおける自動OSインストールは下記のような流れで実行されます。
- 機器が起動する
- ONIEが
OS Installモードで起動する - DHCPでマネジメントポートのIPアドレスを取得する
- DHCPの追加情報あるいは特定URLにてOSインストールイメージの存在場所を特定する
- OSインストールイメージを取得する
- インストールを実行する(ストレージ上にOSのファイルシステムイメージを書き込む)
- インストールが成功するとGRUBメニューを書き換え次回起動をインストールしたOSに変更する
- 自動的に再起動する
- インストールされたOSが起動する
つまり、インストール対象機器本体以外にも必要なものがあり、それは
- OSインストールイメージを配置・配信できるサーバ
- DHCPサーバ
- インストール対象機器との間のネットワークリーチャビリティ
です。
OSのZTP機能による自動初期設定
ONIEによってOSが無事インストールされたとして、OSの設定はどのようにやればZTPが実願できるでしょうか? ここについてはOSの種類やバージョンにより詳細な実現手段は異なるといっていいでしょう。基本的には、DHCPでIPアドレスを取得する際に同時に受け取る追加情報を元に設定情報を取得する、といった手段をとるOSが多いようです。
SONiCにおけるZTP
本稿執筆時点では、SONiCのZTP対応は完了していません。つまり、ONIEによって自動的にSONiCをインストールすることができても、その先の設定については人間が手動で実行する必要があります。
以上で解説はおしまい、というわけではなく、ZTPについてはHLD(High Level Design)に基づき実装が進められていて、現在レビュー中というステータスです。2020年の早い時期にmasterにmergeされるだろうと思います。ここではHLDでどのようにZTPを実現する設計としているかをかいつまんで説明します。細かい説明はHLDをご参照ください。
ZTP JSON
あらかじめ、DHCP option 67にURLを載せるようにDHCPサーバに設定しておき、SONiCのZTPサービスはそれを認識するとURLで指定されたファイルを読み込みます。このファイルはZTP JSONと呼ばれ、ZTP関連の設定を記述することになっています。記述内容はユーザ定義が可能、pluginを使って拡張できる、とあり、かなり自由度が高くなっています。また、すでに提供されているpluginであるconfigdb-jsonを使うことにより、外部から設定を取得して初期コンフィグとして適用することができます。下記はHLDに掲載されていたconfigdb-jsonの例です。
"configdb-json": {
"url": {
"source": "http://192.168.1.1:8080/spine01_config_db.json",
"destination": "/etc/sonic/config_db.json"
}
}
どうやってそれぞれの機器の設定をわけるのか
これはZTP HLDに書かれている話でなく自分の勝手な考えですが、いくらかやり方が考えられます。
- DHCPで付与されたIPアドレスの値に基づいてさまざまな設定値を決定する (たとえばx.x.x.4が付与されたらASN番号もxxx04にする、など)
- DHCPサーバ側で適宜JSONの参照先を切り替える (あらかじめ機器のMACアドレスを把握するなどしてサーバ側で役割を決めておく)
- 同一DHCPサーバから取得した機器は同一設定(たとえばIP CLOSのspine)で動作するようにし、管理ネットワーク側を対象に応じて分離する
いずれにせよ、ZTPの利点を生かせるのは大量の機器を扱い交換等の手間も軽減させる場合であり、1台や2台導入して試験するだけであれば無理して構築する必要性は薄いと言えるでしょう。