CyberAgent が開発した「ぴえん（;_;）」を解消する救世主　「Bearman」の仕組みと使い方

Bearmanを使った在庫の登録

Bearmanは自動的にノードを登録する機能をもつんですけれども、ここからは、その機能のフローの流れについて説明したいと思います。

文章にするとこんな感じですけれども、一つずつ図を使って説明したいと思っています。

これが実際のBearmanの先ほど言ったNodeと呼ばれているところです。ちょっといろいろ隠れていてよくわからないと思うんですけれども、一番左側にあるのがUUIDです。その次がシリアル番号ですね。その次がVENDOR。どこのベンダから買ったのかです。その次がPRODUCT NAMEですね。どういったサーバなのか。いろいろあると思いますけど、まずそれを買ったりとか。

その次にFLAVORがあるんですけれども、これは紐づいているものです。どういったFlavorで上げてくるのかというのが紐づいている。その右がAvailability Zone、IPMI IP、STATUSなどと続きます。このへんは書いてあるとおりの用途で使われています。

では実際に、どういったフローで起動して登録されるかという説明に移りたいと思います。

最初は、ノードを実際にラッキングしてネットワークの配線をします。もちろんそこはやるんですけれども、配線したあとは、そのまま電源をポチッと押すだけでいったんiPXEのサーバが上がってきます。これはPXEブートによって起動させていて、これによって物理サーバが上がってくるのですが、この時に我々はCentOSを使って上げています。

上がってきたCentOSは完全に管理用で、我々が管理しているところなんですけれども、そうするとautorun.serviceと呼ばれているsystemdのユニットファイルが起動します。

ここからどういうことをするかというと、初回の起動だった場合は、register.shと呼ばれている気合のこもったシェルスクリプトがあり、それを使って取ってきます。cephにあるオブジェクトストレージから取ってきていろいろなことをやります。

register.shは具体的にどういうことをしているかは、ここのへんにあるんですけれども、BIOSやNICに埋め込まれているファームウェア。そもそもバージョンアップが必要なんだっけというチェックであるとか、実際にアップデートしたりとか。

それからLLDPを使って、そのCompute Nodeに挿さっているスイッチにちゃんと正しく配線されているか。どういうことかといいますと、マルチモードの光ファイバーでは、2芯の線を使ったりすると思うんですけれども、これが例えば入れ子になっている、逆の状態で挿さっていると、そもそも挿さっているはずなんだけど、挿さっているし本来ならリンクアップするはずなんだけど、なんかリンプアップしていないよねとなります。これを検知できたりします。

そのほかにも、dmidecodeコマンドを使ってハードウェアの情報を取ってくるとかもやったりしています。

こうしてregister.shを使って、そうした設定をするんですけれども、その下の6番の部分に、Bearmanの登録というところがあると思います。

Bearmanの登録では、どういうことするかというと、bearman-cliというものを使って、gRPC経由でアプリケーションとしてデプロイされているBearmanに対してアクセスを行います。「私が新しい新規ノードですよ」というのをCentOSのその中から実行すると、Bearmanの中ではNodeというかたちでデータベースに保存されると。

これが先ほどの図ですが、新しくregister.shから呼ばれたbearman-cliを実行することによって、ノードとして保存されて、ここの画面に新しく出てくる。こうすることによって物理在庫としても自動的に追加されるというような流れになっています。

その次です。ここにIPMIのIPがあると思うんですけれども、自動的にIPアドレスをつけるということをやっています。

ここに書いてあるとおりなんですけれども、IPを管理する「IPman」というのがあります。これは比較的簡単なアプリケーションなんですけれども、どういったIPを使っているのか、どういったIPアドレスを使えるのかというのを管理していて、BearmanがそのIPmanに対して「新規のノードが来たから、IPMIアドレスで使えるIPを教えてくれ」というのをリクエストして、そこから払い出されると。そこから払い出されたのをさらにBearmanが新規のノードに返すということをやります。

ここからregister.shはそのIP情報を見て、自分のノードのBMCに対してIPアドレスを設定するというようなことをやります。

このすべての処理が終わったあとに何をやるかというと、IPMI情報を設定したあとは、もう完全にシャットダウンしてしまうんですね。そうすることによってノードの管理情報はBearmanを見ることによって見ることができると。

さらにそこから、じゃあこのノードを使いたいなってなった時は、IPMIの情報はすでに登録されているので、そこに対してIPMIを使ってアクセスして、そこから起動させるなりなんなりということができます。

登録したらシャットダウンするのがポイント

最後にシャットダウンさせるのは、これけっこう重要な運用の部分になっています。大量にノードをセットアップしたい場合というのは、ままあることなんですけれども、その時にラックにたくさんガーッとラッキングしますよね。そのあと電源ケーブルなりLANケーブルなり光ファイバーなりをいろいろ挿すと思うんですけれども、その時に一気に全部電源をポチポチ押します。

そうすると、それぞれで先ほど説明したregister.shが起動していろいろな登録処理を行うんですけれども、すべて正常に終了した場合はシャットダウンするということは、終了しなかった場合というのは、そのままサーバが起動したままになるんですね。

こうすることによって、すべて電源をポチポチ押して起動したあとに、何らかのほかの作業をして、少し経ったらまたそのラックに戻って、ガーッとラックを見るだけでいいわけですよ。そうすると、電源ボタンの中で「なんかこのサーバだけ光っているな」とか。このサーバだけ光っているということは、ほかのサーバはちゃんと登録が終わったんだけれども、そのサーバだけはなんらかの要因によって登録作業が終わらなかったということがすぐ外から判別できる。

1個1個コンソールを挿して「なんでこれ登録できていないんだっけ？」とかそういうのを設定する必要がないので、これは、めちゃくちゃ便利です。100台ぐらいの登録とかもたまに行ったりするのですが、かなりそういうところでは運用が楽になっているかなと。まぁ、つらくな……いや、違う。「つらくない」じゃない。「ぴえん（;;）じゃない」ですね（笑）。「ぴえん（;;）」じゃなくなっているかなと思っています。

Bearmanにおける起動フロー

では次に起動編です。起動のフローについて説明しようと思います。先ほど説明したProfileというものなんですけれども、これが言ったとおり、Bearmanにて起動させるOSです。どういったOSを起動させるかという定義を乗っけます。

これが起動のフローになります。最初は初回ブートしますというのは先ほどと同じです。一番右に「2段階目OS」というのがあります。先ほどautorun.serviceによって登録作業をするというふうに説明したと思います。登録時は最後にシャットダウンしたわけですが、起動時はそのあとシャットダウンせずに、2段階目のOSというのを起動させることができます。

ここには「（Ubuntu）」と書いていますが、これはUbuntuに限りません。自分たちが使いたいOSなら自動で起動できますし、例えば物理提供したい場合などでも、ここにユーザーさんが使いたいOSを登録できる。わざわざハードウェアの管理用のエージェントをユーザーさんのOSの上にプロセスとして起動させるということもしなくていいので、かなり便利になっています。

これがProfileの詳細画面です。ちょっといろいろ書いてあるのですがズームします。上にappendというのがあります。これが2段階目OSの時に使うcmdline、カーネルのcmdlineですが、これが登録されています。ここにあるとおりfetchと呼ばれているところで、Bearmanに置いてあるfilesystem.squashfsであるとか、そういった情報がいろいろと書いてあったりします。

これによってどういったOSのどういったカーネルパラメータで起動するのかというのがDjango Adminの画面上から管理できる、というふうな利点があります。

下にあるのが2段階目OS用のインストールスクリプトです。OSをインストールしたあとにどういったようなことをやるのか。例えばここに書いてある例だと、pkillでdhclientを落としてたりすると思うんですけれども、これによってBearmanの持っているIPアドレスを登録するというようなことをやったりできます。

2段階目OS起動のフロー

こうやって2段階目のOSを起動していくのですが、ちょっとフローについて、また詳細に説明したいと思います。

1段目のOSのautorun.serviceに関しては先ほどの登録編と同じ流れになっています。先ほどはregister.shというシェルスクリプトを持ってきたんですけれども、次はkexec.shというシェルスクリプトをもってきます。

このkexec.sh自体は、基本的にどのノードに対しても同じようなシェルスクリプトを撒いています。特に「このノードは〇〇用だからこのスクリプトを落とす」というのを切り替えたりはしていません。

これはどういうスクリプトかと言うと、ただ、自分がどういったOSで起動すべきかというのをBearmanから取ってくるというような処理をやっています。ここから取ってくることによって、先ほど書いたFlavorの部分で、どういったFlavorから起動するのかというのをiPXEの「bearman-grpc.example.com/ipxe/${uuid}」というようなURLによって取得できます。

このuuidというのはdmidecodeのsystem-uuidという筐体固有のUUID番号ですね。なので、これによって特に重複なども起こらず、このUUIDを使ってBearmanの中も管理しているので、比較的検索しやすいように作られています。

起動の最中にいろいろなスクリプトを動かすというお話をしたと思うんですけど、いくつかエンドポイントを叩いていきます。

最初に「/profile」というところで自分がどういうProfileで起動すべきなのか。先ほど、cmdlineの設定であったりとか、起動のシェルスクリプトの部分とかっていうのがいろいろ書いてあったと思うんですけれども、そういったところを取ってきます。

その次に、シェルスクリプトのほかにそもそもIPアドレス、これは先ほど言ったIPMIではなくて、そもそも2段階目OS上で使うIPアドレス。Service IPアドレスとか言うと思うんですけれども、そういったPアドレスを取ってきたりとかを「/detail」というエンドポイントでやっています。そのdetailから返ってきたレスポンスをもとにIPアドレスを設定するというような流れです。

最後に「/installed」というところを投げることによって、自分がちゃんとインストールが完了したんだよということをBearmanに通知しています。

これは実際のBaremetalの画面です。これによって、先ほど紹介した3つのエンドポイントを叩くことによって、NodeからProfileをベースとしてOSをインストールする。そのあとにできたそのOSの列というのが、ここに書いてあるBaremetalです。

これ先ほど説明しましたね。IPアドレスというところがあって、これはBaremetalの項目にちゃんと書いてあります。VLANに関して、どういうVLAN IDで設定するのかであったりとか、サービスのIPはどういうIPであるのかっていうのがここから一目瞭然です。

例えば「このCompute NodeにSSHしたい」だったりとか「この物理サーバにSSHしたい」というのはけっこうあると思うんですけれども、そういった時はこのBaremetalの画面を見て、そのままここに書いてあるIPアドレスへSSHにすれば、つながるようになっているという流れになっています。

先ほど言ったとおり「/installed」を使うことによって、最後のステートがDEPLOY……INSTALLEDとかになるんですけれども、先ほどの処理の一連の流れの中でいくつか状態を持っていまして、DEPLOY_STARTであったりとかDEPLOYINGとかUNRECOVERABLE_ERROR。これはもう完全にやばそうな感じしかしないですね（笑）。こういったいくつかの状態をDjango Admin上で管理しています。

先ほど物理的な筐体は電源をポチポチすることによって登録作業のチェックが簡単に行えるということを話したと思うんですけれども、この表示を出すことによってDjango Admin上から「このOSってちゃんと起動できたんだっけ？」というのを確認できたりとか。ここの画面だと全部「INSTALLED」が並んでいると思うんですけれども、例えば「DEPLOYING」のままずっと放置になっているとかだと「これってなんかおかしいよね」ということがすぐわかったりします。

そこから先ほど言ったとおり、IPアドレスの設定とかをしたあとに、OSの情報をBearmanから取ってくる。先ほどcmdlineの話をしたと思うんですけれども、それ以外にも、もちろんどういったカーネルを使うだとかどういったinitramfsを使うだとかっていうような情報を持ってきて、最終的に2段階目のOSが無事起動できました。というような流れになっています。

Bearmanのコンセプト

Bearmanのコンセプトをいくつか説明すると、先ほども言ったとおり現地作業を一切なくしたい。完全になくすのは不可能なんですけれども、配線や物理的なところ以外はすべて自動化したいというのがコンセプトとして作られています。

先ほど本当に何回も説明しているとおり、登録編ではもう完全に差したあとは電源をポチポチ押していればOK。こちらから起動したい場合はBearmanの画面を使ってIPMIを操作することも可能なので、そこから電源を入れて起動させるとかも可能になっています。そうすることによって、もう本当にラッキングして配線が終わったら、あとは現地はほとんど触らなくてOKだよというふうに作ってあるのが、このBearmanのコンセプトです。

もちろんいろいろなハードウェアを使っているんですけれども、そういった違い、例えばPreseedであるとかKickstartとかは、OSによってどういったプロビジョニングツールを使うのかが変わってくるとは思いますが、そうしたところもBearmanによってもう完全に吸収してしまうことによって、同じインターフェース上で違うOSであるとか違うハードウェアというのを使えるようにというのがコンセプトの1つになっています。

利用者視点としては、完全にCLIを使うことによってもBearmanを操作できる。管理者としては、データはDjango AdminのWeb画面で閲覧や管理できる。開発者によると、これは「Django Adminで我慢してね」というふうに書いてあるんですけれども、でも比較的個人的にはそれでも十分かなとは思っています。

gRPC

Bearmanが使っている周辺技術として、gRPCというものが挙げられています。Protocol Bufferともいいます。これは何の略称かを見たんですけれども、gRPCの略称ってgRPCらしいんですよね。gRPC Procedure Remote Controlle、gRPC Remote Procedure Calとか……ん、ちょっとなんか違う気がする。まぁいいです。そういうふうになっていて、明らかにこれはGoogle製なので、たぶんGoogle RPCと言いたかったんだと思うんですけれども、そういったような名前になっています。

これはどういうものかというと、複数の言語のクライアントとサーバの実装を吐けるRPC、自動的に生成できるRPCというふうになっています。どういった関数が必要なのか、どういった入力からどういった返答を返すのかというのをProtoファイルと呼ばれているもので定義したあとに、例えばPythonだったりとかGolangであったりとかRubyだったりとかっていうサーバ実装とクライアント実装を自動的に生成できるというのがgRPCの特徴です。

やっぱりいろいろなプログラミング言語を扱っていて……。例えば今回我々はGoとPythonを使っているんですけれども、CLIツールとかを使うのに関してGoというのはすごく楽だなと思っています。いろいろなところにデプロイしたりとかをすごく楽にできています。

ただ、DBの扱いとかはまだデファクトスタンダードが出ていなかったりだとか、Web画面をHTMLで組み立てるというのはまだちょっと不得意かなと思っていて、そういった時にDjango Admin、というかDjangoを使うことによって、そちらにデータを保存しておいて、例えばCompute NodeのCentOSの上で動かすのはCLIというところで。楽に、便利にgRPCをすごく使っています。

AnsibleとLXDを組み合わせる

先ほど2段階目のOSでUbuntuを立ち上げるとかいろいろなOSを立ち上げるという話をしたと思うんですけれども、その時のイメージの生成にはAnsibleとansible_connection=lxd、つまりLXDコンテナを使ってAnsibleでプロビジョニングするとようなものを使っています。

物理のイメージ作るのって、実はけっこう大変だと思っています。わざわざ物理を用意して物理のイメージを作るというのはけっこう面倒くさいんですね。その対策として、AnsibleとLXDを組み合わせることによって、適当にVM上でそういったカーネルとかinitramfsとかrootfsというのを生成できるのが、かなり便利なところになっています。

Bearmanのメリットのまとめ

最後にちょっとBearmanの部分のところでメリットのまとめをしておきますが、運用時の確認事項というのは、すごく大きく減らすことができます。電源を挿して、ファイバーも挿して、電源をポチッ。あとは後ほど確認していくというぐらいでもぜんぜんOKです。

設定に不備があった場合、先ほどシャットダウンしないというお話をしたと思うんですけれども、Slackの通知も一緒に行っています。Slackが通知する時には、CentOSについているIPアドレスも一緒に通知するので、SlackからもうSSHの必要な情報が書いてあるんですね。そこからSSHすれば「どこで処理が止まったんだっけ？」というのがリモートで確認できる。これ、めちゃくちゃ便利なところです。

やっぱりそういった低レイヤーのプロビジョニングって、なんというか、GRUBシェルとかを使って、比較的使いにくいシェルを使うことが多いと思うんですけれども、この方法ですとCentOSの普通のbashが使えるので、比較的トラブルシューティングもしやすい。ネットワークもつながっているので、そのへんに関してもけっこうやりやすいような特徴があります。

Django Adminを使ってWeb画面から見れるというのも、かなり便利なところです。チームビルディングにもよりますが、けっこう「物理を扱っているチームしか物理のことは知らないんだよね」ということがわりとあると思っています。

そうした時に、このBearmanを使うことによって、とりあえず現地に配線をしてもらって登録作業まではしてもらう。そのあとはもう完全にWeb画面から使うことができるので、物理にそんなに近くないチーム、そんなに扱っていないチームでも、物理筐体を使っていろいろなことができるというのがけっこういい特徴になっています。

ここまでが我々がやっている自動的な物理管理術です。次に、Cycloudにおける監視術について説明したいと思います。

（次回につづく）