さくらの専⽤サーバPHYとその裏側 さくらインターネット株式会社井上喬視 1

⾃⼰紹介 井上喬視(いのうえたかし) さくらインターネットクラウドサービス部 2015年⼊社 ⼊社以来ほぼさくらの専⽤サーバ関連の業務に従事 2

さくらインターネット株式会社 サーバなどの計算資源を貸し出すデータセンター事業者 1996年 さくらインターネット創業 12⽉に現社⻑の⽥中邦裕が、舞鶴⾼専在学中に学内ベンチャーとして創業 1999年 株式会社を設⽴ 10⽉には第1号となるデータセンターを⼤阪市中央区に開設 2005年 東証マザーズ上場 2011年 ⽯狩データセンター開設 11⽉、北海道⽯狩市に国内最⼤級の郊外型⼤規模データセンターを開設 2015年 東証⼀部に市場変更 2016年 創業20周年 3

さくらインターネットの事業 データセンターに データを預ける データを 保管・処理する インターネットを 介してデータが 流れる ブラウザ・アプリ からサーバに アクセスする データセンター インターネット 利⽤者 コンテンツ 事業者 さくらインターネット データ インターネット 4

サービス紹介 新サービス 専⽤サーバ・データセンター レンタルサーバ ハウジング VPS・クラウド（仮想化基盤） 電⼦契約プラットフォームβ 5

物理サーバーホスティングの歴史 物理サーバのホスティング事業は創業期から続くサービス 1997年 専⽤サーバサービス開始 2002年 専⽤サーバサービス全⾯リニューアル 2007年 専⽤サーバPlatformの提供を開始 2012年 さくらの専⽤サーバの提供を開始 2020年 さくらの専⽤サーバPHYの提供を開始 6

さくらの専⽤サーバPHY(ファイ) 2020年よりサービス提供を開始 7

さくらの専⽤サーバPHYの特⻑ 8

⾼性能なサーバーを専有で ⾼速なCPUと⼤量のメモリ、ストレージを専有 CPU:最⼤2.5GHz40Core(IntelXeonGold6248x2) メモリ:最⼤1.5TB ストレージ:最⼤SSD3.84TB(最⼤6つ搭載可能) オプションでNVMeを最⼤4つ搭載可（SSD3.2TB/6.4TB） RAID選択可（標準でRAID1） https://server.sakura.ad.jp/specification/ 9

物理サーバーの運⽤を⾏いやすく 冗⻑化された回線と電源を標準提供 サーバー電源、ネットワークスイッチの冗⻑化 全モデルで冗⻑構成を標準提供 ⾃由⾃在にスケール可能 サーバ１台の構成から台数に上限無しでスケールアウト可能 サーバーを欲しいときに 最短10分で提供が可能 オプション追加もオンラインで完結 10

柔軟なネットワーク構成 ハイブリッド接続によるネットワーク連携 さくらのクラウドやハウジングサービス等との接続も可能 オンプレミスのようなネットワークを構築可能に 1台のサーバーに複数のネットワークを接続可能 タグVLANをサポート アプライアンスも利⽤可能 ファイアウォール ロードバランサ 11

くわしくはWebで！ 公式サイト https://server.sakura.ad.jp/ マニュアル https://manual.sakura.ad.jp/ds/phy/ 12

さくらの専⽤サーバPHYの裏側 13

物理デバイス構築⾃動化の取り組み 実現できていること 基本的に⼈⼒作業は設置配線のみ ラックに設置して配線して電源ONで在庫化まで 構築の⾃動化が実現できているもの サーバー スイッチ インテリジェントPDU ラックに搭載するものすべて 14

サービス提供までの流れ（構築編） ラックプランの検討 設置するサーバのモデルを検討する 在庫状況や売れ⾏き等によって決まる 設置/配線 サーバーやスイッチなどをラックに搭載する セットアップ 販売在庫化 セットアップ完了済みのものを販売在庫として登録 15

ラックプランの検討 ラックプラン=どういうラックを構築するか PHYには複数の販売モデルがある ローエンド/ミドルエンド/ハイエンド サービスリニューアルによって変わる 販売モデルによってサーバだけでなく搭載するスイッチも変わる そのため販売モデルごとにラックを構築している ここは⾃動化しにくい部分 売れ⾏き、在庫などを総合的に判断して決める必要がある 16

設置/配線 設置や配線作業⾃体は基本的に⾃動化不可 設置ロボ？配線ロボ？ ラックへのサーバ/スイッチ搭載は⼈⼒で対応 ただし設置位置や配線経路はルールによって⾃動化 装置のラック搭載位置 電源ケーブルの配線 ネットワークケーブルの配線 17

設置位置/配線経路の決定ルール ラックに必ず設置される装置 管理⽤スイッチ=管理インターフェースを収容する インテリジェントPDU=ラック内のデバイスの電源供給 以下の３つの番号を⼀致させるルール サーバーのBMCを接続する管理⽤スイッチのポート番号 電源を取得するインテリジェントPDUのアウトレット番号 ラック内の設置位置（U位置） 18

管理⽤スイッチ インテリジェントPDU 41Uに設置されたサーバー =管理⽤スイッチの接続ポートは41 =PDUのアウトレット番号は41 19

20

設置が完了した機器のセットアップ DHCPをセットアップの起点としている ほとんどの装置は初期設定がDHCPとなっている DHCPでどうやって装置を判別する？ IPアドレスを払い出した対象はどれ？サーバー？スイッチ？ よくあるやり⽅はMACアドレスをベースにする⽅法 でもMACアドレス集めるのは⼤変 設置した後にMACアドレスを調べるのも⼤変 IPアドレスを払い出した後は？ 払い出しただけではセットアップが進まない 21

装置判別のためのアプローチ DHCPOption82の利⽤ スイッチのDHCPSnooping機能によって付与されるオプション RemoteID(スイッチホスト名)とCircuitID(ポート番号) どのスイッチのどのポートに接続されているかが分かる SwitchA Port1 DHCPSnoopingによってOption82を付与 DHCPDiscover DHCPDiscover RemoteID CircuitID :SwitchA :Port1 DHCPClient DHCPServer 22

IPアドレスを払い出した後は？ 払い出しただけではセットアップが進まない セットアップには構成情報が必要 装置のホスト名は？ どういう役割で何をする装置なのか？ PXEブートに必要なMACアドレスはなに？ 23

課題を解決するためのDHCPサーバ 課題解決のためDHCPサーバを独⾃に実装 Option82をキーとしたIPアドレスの固定払い出し 構築対象の特定を可能に IPアドレスを払い出した後にWebhookを送信する機能 実際のセットアップ処理を⾏うための通知機能 ZeroTouchProvisioning機能の実装 ONIE ベンダー固有のZTP機能 24

Option82による固定IPアドレス払い出し IPアドレス情報はYAMLベースの構成管理ファイルで定義 管理スイッチの接続ポートでIPアドレスが⼀意に決まる SwitchA Port1 DHCPSnoopingによってOption82を付与 DHCPDiscover DHCPDiscover RemoteID CircuitID :SwitchA :Port1 DHCPClient DHCPServer 構成管理ファイル (YAML) ファイルの内容に従い IPアドレスを決める 25

構成管理ファイル(LeaseDB) 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 26

構成管理ファイルの運⽤ 構成管理ファイルはGithubで管理している Githubflowな運⽤ 構成ファースト:構成があって初めて構築できる仕組み 構成管理ファイル (YAML) ラック構築したい⼈ 確認者 ブランチの作成/構成ファイルの追加 PullRequestの作成 マージ 確認依頼 27

セットアップ処理の開始 IPアドレス払い出し後にWebhookを送信 Webhookの送信先は構成管理ファイルに定義されている SwitchA Port1 DHCPDiscover DHCPDiscover RemoteID CircuitID :SwitchA :Port1 DHCPClient DHCPServer セットアップサーバー （スイッチ) セットアップサーバー (サーバー) セットアップサーバー （PDU) 構成管理ファイルの定義に従い Webhookを送信 セットアップ処理の開始 28

送信されるWebhookの中⾝ セットアップに必要な情報をペイロードに含めて送信 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" //構成管理ファイル記載のホスト名 } 29

セットアップ処理 ここは泥臭く頑張るところ 対象デバイスによってさまざまなやり⽅で実施 サーバーの場合 PXEBootによるOSの起動+OSのブートストラップ機能 RedfishによるBIOS/UEFIのセットアップ ネットワーク機器の場合 基本はShellScript+expectでごりごり セットアップ完了後は監視を有効化する 30

監視システムの構成 Prometheusを利⽤した監視基盤を構築 Alertmanagerによるアラート管理 サーバの監視 Redfishを利⽤するExporterを実装して利⽤ RAIDのステータス監視も⾏っている ネットワーク機器の監視 主にSNMPExpoterを利⽤ 追加でメトリクスを取得したい⼀部の機器は⾃作している 31

監視の有効化 監視されるデバイスはConsulで管理している PrometheusのConsulDiscoveryを利⽤ Consulに登録後、⾃動的にモニタリングが開始される セットアップサーバー セットアップ処理の開始 完了/エラーの通知 Consul Discovery 監視 監視登録 32

コンフィグバックアップの⾃動化 ネットワーク機器のコンフィグバックアップツール https://github.com/ytti/oxidized Git連携によるコンフィグの差分管理 HTTPSourceを利⽤してConsulと連携 バックアップ対象のリストをHTTP経由で取得する機能 Consulに登録されたデータをHTTPSource形式のJSONに変換 して返すサーバを実装 33

OxidizedとConsulの連携 Consulの登録データを元にJSONを返すエンドポイントを実装 Oxidizedで定期的に再読込するように設定 Consul登録後は⾃動的にコンフィグバックアップが開始される { "name":"ds-phy-spine-001", "ip":"192.0.2.101", "input":"ssh", "model":"eos", "group":"switch", "enable":true } 34

まとめ さくらの専⽤サーバPHYにおける構築の仕組み 設置と配線のみで⾃動構築できる仕組みが出来た DHCPOption82をキーにしたIPアドレス払い出し 払い出し後のWebhookで個別に⾃動構築を実施 ラック構成管理を構築フローに組み込み 構成情報の⼀元化 構成を前提とした⾃動化で作業ミスの可能性を低減 セットアップから監視登録、在庫化まで⾃動で完結 35

36