さくらの専用サーバPHYとその裏側〜物理ホスティング環境構築自動化の取り組み〜 (後編)

この記事は2020年10月23日に行われたオープンソースカンファレンス2020 Online/Fallにおける発表を文章化したものです。

さくらインターネットの井上です。本記事では、最近リリースした新サービス「さくらの専用サーバPHY」の紹介と、その裏側、中でも主に物理サーバーやネットワーク環境の構築自動化の取り組みについてご紹介します。前編ではサービスのご紹介、およびサービス提供までの流れと、機器の設置・配線に関してご説明いたしました。それに続く後編(本記事)では、機器のセットアップ、監視、バックアップといった環境構築の自動化についてご説明します。

設置した機器のセットアップ
装置判別にDHCP Option82を利用
DHCPサーバを独自に実装
DHCPサーバが参照する構成管理ファイル
Webhookを使ったセットアップ処理
セットアップサーバーが行うセットアップ処理
監視システムの構成
監視の有効化
コンフィグのバックアップも自動化
まとめ

設置した機器のセットアップ

前編では機器をラックに設置し配線するまでをご説明しました。機器をラックに搭載した後は、セットアップを行います。セットアップはDHCPを起点としておりまして、その理由はほとんどの装置において管理用インターフェースの初期設定としてDHCPが設定されていることが多いためです。

ただDHCPでセットアップする場合、どうやって装置を判別するかという問題があります。前編の記事に掲載した写真のように、1つのラックに大量のスイッチやサーバーを搭載するためDHCPでIPアドレスを払い出しても、どのサーバーに払い出したのか、どのサーバーの構築進んでいるいるのか、といったところがわかりにくいという問題があります。それから、サーバーだけでなくスイッチもあるため、払い出した対象がサーバーなのかスイッチなのか、という判別についても一工夫が必要です。

この解決策としてよくあるやり方はMACアドレスをベースにする方法です。これは、「このMACアドレスはサーバーのMACアドレスだからこういう設定をしよう」とか、「これはスイッチのMACアドレスだからこういう設定をしよう」といったやり方です。しかし、そもそもMACアドレスを集めるのは大変です。例えば装置に貼り付けられているラベルを見たり、あるいは実際にログインして確認したり、または装置ベンダーから集めるという方法が考えられますが、いずれにしても収集および管理は大変です。また集めたとしても、そのMACアドレスが何U目に搭載されているかがわかるようにするのは結構な労力です。特定のMACアドレスの装置を特定の場所に設置するのは大変な作業ですし、また、設置してからMACアドレスを調べようとしても、スイッチの裏側に書いてあったりして設置してからでは見えないような装置もあります。

また、DHCPでIPアドレスを払い出しただけではセットアップは進みません。PXEブートやベンダー固有の初期設定機能のようなものが搭載されている装置もありますが、そういったものがない装置、たとえばサーバーのBMCのインターフェースなどの場合は何らかの手段でセットアップを自動化していかなければなりません。

装置判別にDHCP Option82を利用

まずどうやって装置を判別するかという問題の解決アプローチとして、さくらの専用サーバPHYではDHCP Option82というものを利用しています。これはスイッチのDHCP SnoopingによってDHCPパケットに付与されるオプションです。

下図を用いて説明しますが、まずDHCPクライアントからDHCP Discoverが送信されます。DHCP DiscoverはSwitchAがいったん受信するわけですが、スイッチのDHCP Snooping機能によって、DHCPパケットの中にOption82というオプションを追加します。どういった値が付与されるかというと、RemoteIDとCircuitIDの2つの値です。RemoteIDはスイッチのホスト名で、下図ではSwitchAというホスト名がオプションとして追加されます。CircuitIDはポート番号で、Port1という値になります。つまり、Option82によってスイッチのホスト名とポート番号がDHCPパケットに追加されることになります。。これによってDHCPサーバは、DHCP Discoverはどこのスイッチのどのポートにつながっている機器が送信したものなのかを理解することができます。

しかし、先ほども述べたとおり、IPアドレスを払い出しただけではセットアップは進みません。セットアップするには構成情報が必要で、装置のホスト名は何にすればいいのか、この装置にはどういう設定をする必要があるのか、どういう役割の装置なのかといった問題があり、これらを解決しつつ払い出した後にセットアップしていく必要があります。

DHCPサーバを独自に実装

こうした問題も一緒に解決するため、さくらの専用サーバPHYの環境ではDHCPサーバを独自に実装して利用しています。

このDHCPサーバはどういう機能を持っているかというと、まずOption82で付与されるRemoteIDとCircuitIDをキーとして、IPアドレスを固定で払い出します。これで、どのスイッチのどのポートに接続されたデバイスからリクエストが飛んできたかがわかります。次に、IPアドレスを払い出した後にWebhookを送信する機能も搭載しています。こちらはIPアドレスの払い出し後にセットアップ処理を行いますので、セットアップするサーバーに対して、「このデバイスにこのIPアドレスの払い出しをしたよ」という通知をするための機能です。あとはおまけとしてZeroTouchProvisioning機能も実装しています。これは、一部のスイッチに搭載されているONIEと呼ばれるオープンな初期設定プロトコルや、あとはベンダー固有のZTP機能の実装になります。

なぜDHCPサーバを独自実装したかというと、Option82をキーとした固定IPアドレスの払い出しは、よく利用されているISC DHCPでもできるのですが、設定が煩雑になり、また対象台数が多いと非常に重くなり運用に向かないといった点、また払い出し後の通知（Webhookの送信）の仕組みがないといった問題を解決するため、自前で実装をしています。

Option82による固定IPアドレスの払い出しは、先ほども説明した通り、DHCP Discoverにどのスイッチのどのポートからであるかというのが記載されているので、それに応じてIPアドレスを払い出すという形になります。よくあるDHCPサーバだとIPアドレスのレンジを切って、そのレンジのどこかを払い出すようなのが一般的かと思います。しかしさくらの専用サーバPHYではそうではなく、YAMLフォーマットのファイルとして定義している構成管理ファイルを見て、固定のIPアドレスを常に一意に払い出すようにしています。よって、ポート1から来たものは常に同じIPアドレスですし、ポート2から来たものは別の固定IPアドレスが常に払い出されるようになっています。

DHCPサーバが参照する構成管理ファイル

この構成管理ファイルを弊社ではLeaseDBと呼んでいいます。例を以下に示しますが、このファイルには、どのスイッチから来たのかがわかるようにするための管理用スイッチ名、管理用スイッチのモデル、払い出すIPアドレスやネットワーク情報、データセンターやラック名などを記載しています。そして、portという項目が実際に払い出すための情報で、例えばポート2にはどういった機器がつながっていてどういうホスト名か、ポート3はどういった機器なのか、といったことを記載しています。この例ではポート2とポート3は接続されている装置が違うものであることがわかります。

name: ds-phy-mgmt-001   #管理スイッチ名
model: xxxx             #管理スイッチのモデル名
start: 192.0.2.11       #払い出し先頭IPアドレス
netmask: 255.255.254.0  #払い出されるサブネットマスク
gateway: 192.0.2.1      #払い出されるゲートウェイアドレス
datacenter: is          #設置されるデータセンタ
zone: 3a                #データセンタ内のゾーン
rack: a-1               #ラック名
port:
  - index: 2                  #ポート番号
    hostname: ds-phy-node-001 #接続される機器のホスト名
    webhook: build_node       #払い出し後のWebhook送信先
  - index: 3
    webhook: phy_server_setup

IPアドレスはどうやって決めるかというと、払い出し先頭IPアドレスという項目がありますが、これがportのindex:1の機器に払い出されるIPアドレスです。index:2の場合はこれに1をプラスしたアドレス(この例では192.0.2.12)が払い出されます。こういった形で、必要最低限の記載でIPアドレスを払い出せるような仕組みにしています。

なおこの構成管理ファイルはGitHubで管理しています。よって、ファイルを誰かが作成する必要がありますが、このファイルはラックプランの検討において「こういうラックを作ろう」と決まれば作成できるファイルになっていますので、ラックを検討する段階で決まったらファイルを作って、確認者に確認をしてマージするといったような、GitHub flowな運用を行っています。これのいいところは、構成がないとサーバーのキッティングが進まないという点がフローに組み込まれていることです。これにより構成があって初めて構築できるという仕組みを担保しています。

Webhookを使ったセットアップ処理

IPアドレスを払い出した後（DHCP ACK送信後）は、DHCPサーバがWebhookを送信します。Webhookの送信先はセットアップされる対象のデバイスによって変えることができ、また送信先は構成管理ファイルに記載することができます。

下の図で説明すると、サーバー（BMC）、PDU、スイッチに対してそれぞれのセットアップサーバーがあります。DHCPサーバはDHCPクライアントから届いたリクエストを見て、リクエストを送ってきたクライアントの種別を判断し、その種別のセットアップサーバーに対してWebhookを送信するという形です。セットアップサーバーはWebhookを受信したら、DHCPクライアントに対してセットアップ処理を実行します。

送信されるWebhookの中身ですが、こちらはセットアップに必要な情報をまとめてペイロードに載せて送信しています。具体的には、DHCPクライアントから上がってきたDHCP Discoverもしくはリクエストの情報と、構成管理ファイルに記載している情報を合わせて送っています。例を以下に示しますが、この中の払い出しIPアドレスは構成管理に含まれている情報です。MACアドレスはDHCPパケットに含まれているものを送信しています。あとはポート番号やスイッチのホスト名も合わせて送信する形です。実際にはもう少し多くのデータを載せていて、メタデータなどの細かい情報も送信していますが、メインで使うものとしてはこれらの情報を送信して構築を進めています。

{
  "ipaddr":"192.0.2.5",              //払い出しIPアドレス
  "mask":"255.255.255.224",          //払い出しサブネットマスク
  "gateway":"192.0.2.1",             //払い出しゲートウェイアドレス
  "macaddress":"00:00:5e:00:53:01",  //払い出しデバイスのMACアドレス
  "port":3,                          //管理スイッチのポート番号
  "switch":"ds-phy-mgmt-001",        //管理スイッチホスト名
  "hostname":"ds-phy-tor-001-a"      //構成管理ファイル記載のホスト名
}

セットアップサーバーが行うセットアップ処理

セットアップサーバーがどういうセットアップ処理をしているかというと、ここはかなり泥臭く頑張っている部分です。対象となるデバイスが複数あり、サーバーをとってもベンダーが複数の可能性もありますし、またベンダーが同じでもBMCのインターフェースが違うなど、設定方法が変わるケースもあります。そのため、ここはサーバーそれぞれに応じて対応しています。これはさくらの専用サーバにおいて昔から割と泥臭く頑張っているところです。

例えばサーバーの場合は、PXEブートさせて、OSを起動させてから、OSのブートストラップ機能、例えばCentOSであればkickstartとか、そういったものを使って、サーバーの初期設定や構成チェックを行います。また、最近のハードウェアでは一般的になってきているRedfishというBMCインターフェースの標準化されたプロトコルがあり、これによってBIOSやUEFIのセットアップを行っています。サーバーの場合、BIOSのGUIにはいり、画面をポチポチ操作することがよくありますが、Redfishを使うとそういった操作がおおむねすべてHTTP経由で実施できます。Redfishはサーバーベンダーによって実装が違ったりすることがあり注意は必要ですが、大変便利に利用しています。

ネットワーク機器の場合は、基本はシェルスクリプトとexpectという昔からある手段でゴリゴリと設定を行っています。最近だとAnsibleでできたりとか、NETCONFとかYANGとか、そういったものもありますが、結局シェルスクリプト＋expectでやった方が早いケースも多く、今のところこれで充足しているという形です。

それから、セットアップ完了後は監視を有効化します。さくらの専用サーバPHYではセットアップ完了後に自動でテストを行った後に、監視の有効化も自動で行っています。

監視システムの構成

監視の有効化の話が出てきたところで、監視システムの構成についても簡単に紹介します。さくらの専用サーバPHYの裏側の監視はPrometheusを利用しています。Prometheusと合わせて、AlertManagerによるアラートの管理も行っています。

サーバーの監視ですが、弊社が監視している対象はBMCのインターフェースです。BMCインターフェースの監視は、Redfishを利用する監視用のExporterを自前で実装して監視を行っています。Redfishを用いてどういった監視をするかというと、サーバーのメモリやCPUなどの状態に加えて、RAIDのステータス(どういうRAIDが組まれているか、ディスクは正常か、RAIDが壊れてないか)といった内容です。これらをPrometheusを経由して行っています。またこちらのRAIDステータスの監視結果は、お客様がさくらの専用サーバPHYで操作を行う際に利用するコントロールパネルにも通知しています。

ネットワーク機器については主にSNMPを使って監視をしていますが、SNMPでは取れないけどどうしてもメトリクスを取りたい値がある、という一部の機器についてはExporterを自作しています。これはスイッチが持っているAPIを使って取りに行くものだったりとか、expect的なものでコマンドを取ってパースしてメトリクスを返すようといったものです。

監視の有効化

監視されるデバイスはすべてConsulで管理しています。Consulについては詳細を割愛しますが、ノードの情報やIPアドレスがすべてConsulに保存されている、という風に理解いただければよいかと思います。さくらの専用サーバPHYの裏側の環境では、Prometheusの機能であるConsul Discoveryを利用しており、Consulに保存されているノードの情報をPrometheusが定期的に取得して監視対象を取得しています。

監視を有効化する時は、セットアップサーバーが対象ノードのセットアップを行い、すべて完了した日にConsulに監視登録を行います。するとPrometheusがDiscoveryをし、自動的に監視が始まるといったような仕組みです。セットアップサーバーからエラーが出たりログを吐きたいといったときはSlackに流して、もし何かあったらわかるような形にもなっています。

コンフィグのバックアップも自動化

また、ネットワークスイッチの場合はコンフィグのバックアップについても、監視の有効化と同じタイミングで自動的に有効となるようにしています。。ネットワーク機器のコンフィグバックアップを行うOxidizedというツールを利用しており、こちらはGitと連携してコンフィグを差分管理できるのが特長です。

またOxidizedにはHTTP Sourceというインターフェースがあり、監視対象をHTTP経由で取得することができます。Consulに監視対象の装置を全部入れているので、このConsulに登録されたデータをHTTP SourceのフォーマットであるJSONに変換して返すというようなサーバーを実装して運用しています。具体的には、Consulに登録されたデータを元に下図のような形式のJSONを返すというエンドポイントを実装しています。Oxidizedの方でこのJSONを定期的に再読み込みすると、セットアップが完了してConsulに登録したネットワークスイッチがJSONに含まれてきますので、自動的にコンフィグのバックアップも開始されるというような連携の仕組みを構築しています。

{
  "name":"ds-phy-spine-001",
  "ip":"192.0.2.101",
  "input":"ssh",
  "model":"eos",
  "group":"switch",
  "enable":true
}

まとめ

さくらの専用サーバPHYの裏側で動いている構築の仕組みを今回ご紹介させていただきました。基本的には設置と配線だけで自動構築できる仕組みが実現できています。これはDHCP Option82をキーとしたIPアドレスの払い出しと、払い出し後のWebhookによる連携で構築を進めるといった構成となっており、ラックの構成管理についても構成管理ファイルによって構築フローに組み込まれています。構成情報は一元化されており、構成の過程で自動化が前提となっているので、「間違えて構成を組んでしまった」というような作業ミスの可能性を減らしています。それから、セットアップから監視登録、この記事では割愛しましたが在庫化(お客様への販売在庫にする)まで自動で完結をしているような形です。

さくらの専用サーバPHYでは、こういった自動化の仕組みを通して、安心してご利用いただけるような物理サーバー環境を提供させていただいております。当社の仮想サーバーである「さくらのVPS」や「さくらのクラウド」と比べると、スペックも高いということもあってお値段は少しお高めではありますが、もし物理サーバーを使いたいとか、とにかくパワーが必要な処理を行いたいとか、そういったことでお困りでしたら、ぜひさくらの専用サーバPHYをご利用いただければと思います。よろしくお願いします！