さくらの専用サーバ PHYとその裏側@OSC2020 Online/Fall

OSC2020 Online/Fall のセミナー資料です。
https://event.ospn.jp/osc2020-online-fall/session/200649

Transcript

1. さくらの専⽤サーバ
   PHYとその裏側 さくらインターネット株式会社
   井上喬視 1
2. ⾃⼰紹介 井上
   喬視(いのうえ
   たかし) さくらインターネット
   クラウドサービス部 2015年⼊社 ⼊社以来ほぼさくらの専⽤サーバ関連の業務に従事 2
3. さくらインターネット株式会社 サーバなどの計算資源を貸し出すデータセンター事業者 1996年
   さくらインターネット創業 12⽉に現社⻑の⽥中邦裕が、舞鶴⾼専在学中に学内ベンチャーとして創業 1999年
   株式会社を設⽴ 10⽉には第1号となるデータセンターを⼤阪市中央区に開設 2005年
   東証マザーズ上場 2011年
   ⽯狩データセンター開設 11⽉、北海道⽯狩市に国内最⼤級の郊外型⼤規模データセンターを開設 2015年
   東証⼀部に市場変更 2016年
   創業20周年 3
4. さくらインターネットの事業 データセンターに データを預ける データを 保管・処理する インターネットを 介してデータが 流れる ブラウザ・アプリ からサーバに アクセスする データセンター インターネット 利⽤者 コンテンツ 事業者 さくらインターネット データ インターネット 4
5. サービス紹介 新サービス 専⽤サーバ・データセンター レンタルサーバ ハウジング VPS・クラウド（仮想化基盤） 電⼦契約プラットフォームβ 5
6. 物理サーバーホスティングの歴史 物理サーバのホスティング事業は創業期から続くサービス 1997年
   専⽤サーバサービス開始 2002年
   専⽤サーバサービス全⾯リニューアル 2007年
   専⽤サーバ
   Platformの提供を開始 2012年
   さくらの専⽤サーバの提供を開始 2020年
   さくらの専⽤サーバ
   PHYの提供を開始 6
7. さくらの専⽤サーバ
   PHY
   (ファイ) 2020年よりサービス提供を開始 7
8. さくらの専⽤サーバ
   PHYの特⻑ 8
9. ⾼性能なサーバーを専有で ⾼速なCPUと⼤量のメモリ、ストレージを専有 CPU:
   最⼤2.5GHz
   40Core
   (Intel
   Xeon
   Gold
   6248
   x
   2) メモリ:
   最⼤1.5TB ストレージ:
   最⼤SSD
   3.84TB
   (最⼤6つ搭載可能) オプションでNVMeを最⼤4つ搭載可（SSD
   3.2TB/6.4TB） RAID選択可（標準でRAID1） https://server.sakura.ad.jp/specification/ 9
10. 物理サーバーの運⽤を⾏いやすく 冗⻑化された回線と電源を標準提供 サーバー電源、ネットワークスイッチの冗⻑化 全モデルで冗⻑構成を標準提供 ⾃由⾃在にスケール可能 サーバ１台の構成から台数に上限無しでスケールアウト可能 サーバーを欲しいときに 最短10分で提供が可能 オプション追加もオンラインで完結 10
11. 柔軟なネットワーク構成 ハイブリッド接続によるネットワーク連携 さくらのクラウドやハウジングサービス等との接続も可能 オンプレミスのようなネットワークを構築可能に 1台のサーバーに複数のネットワークを接続可能 タグVLANをサポート アプライアンスも利⽤可能 ファイアウォール ロードバランサ 11
12. くわしくはWebで！ 公式サイト https://server.sakura.ad.jp/ マニュアル https://manual.sakura.ad.jp/ds/phy/ 12
13. さくらの専⽤サーバ
    PHYの裏側 13
14. 物理デバイス構築⾃動化の取り組み 実現できていること 基本的に⼈⼒作業は設置配線のみ ラックに設置して配線して電源ONで在庫化まで 構築の⾃動化が実現できているもの サーバー スイッチ インテリジェントPDU ラックに搭載するものすべて 14
15. サービス提供までの流れ（構築編） ラックプランの検討 設置するサーバのモデルを検討する 在庫状況や売れ⾏き等によって決まる 設置/配線 サーバーやスイッチなどをラックに搭載する セットアップ 販売在庫化 セットアップ完了済みのものを販売在庫として登録 15
16. ラックプランの検討 ラックプラン
    =
    どういうラックを構築するか PHYには複数の販売モデルがある ローエンド/ミドルエンド/ハイエンド サービスリニューアルによって変わる 販売モデルによってサーバだけでなく搭載するスイッチも変わる そのため販売モデルごとにラックを構築している ここは⾃動化しにくい部分 売れ⾏き、在庫などを総合的に判断して決める必要がある 16
17. 設置/配線 設置や配線作業⾃体は基本的に⾃動化不可 設置ロボ？配線ロボ？
    ラックへのサーバ/スイッチ搭載は⼈⼒で対応
    ただし設置位置や配線経路はルールによって⾃動化 装置のラック搭載位置 電源ケーブルの配線 ネットワークケーブルの配線 17
18. 設置位置/配線経路の決定ルール ラックに必ず設置される装置 管理⽤スイッチ
    =
    管理インターフェースを収容する インテリジェントPDU
    =
    ラック内のデバイスの電源供給 以下の３つの番号を⼀致させるルール サーバーのBMCを接続する管理⽤スイッチのポート番号 電源を取得するインテリジェントPDUのアウトレット番号 ラック内の設置位置（U位置） 18
19. 管理⽤スイッチ インテリジェントPDU 41Uに設置されたサーバー
    
    =
    管理⽤スイッチの接続ポートは41
    
    =
    PDUのアウトレット番号は41 19
21. 設置が完了した機器のセットアップ DHCPをセットアップの起点としている ほとんどの装置は初期設定がDHCPとなっている DHCPでどうやって装置を判別する？ IPアドレスを払い出した対象はどれ？サーバー？スイッチ？ よくあるやり⽅はMACアドレスをベースにする⽅法 でもMACアドレス集めるのは⼤変 設置した後にMACアドレスを調べるのも⼤変 IPアドレスを払い出した後は？ 払い出しただけではセットアップが進まない 21
22. 装置判別のためのアプローチ DHCP
    Option82の利⽤ スイッチのDHCP
    Snooping機能によって付与されるオプション RemoteID(スイッチホスト名)とCircuitID(ポート番号) どのスイッチのどのポートに接続されているかが分かる SwitchA Port1 DHCP
    SnoopingによってOption82を付与 DHCP
    Discover DHCP
    Discover RemoteID
    CircuitID :
    SwitchA
    :
    Port1 DHCP
    Client DHCP
    Server 22
23. IPアドレスを払い出した後は？ 払い出しただけではセットアップが進まない セットアップには構成情報が必要 装置のホスト名は？ どういう役割で何をする装置なのか？ PXEブートに必要なMACアドレスはなに？ 23
24. 課題を解決するためのDHCPサーバ 課題解決のためDHCPサーバを独⾃に実装 Option82をキーとしたIPアドレスの固定払い出し 構築対象の特定を可能に IPアドレスを払い出した後にWebhookを送信する機能 実際のセットアップ処理を⾏うための通知機能 ZeroTouchProvisioning機能の実装 ONIE ベンダー固有のZTP機能 24
25. Option82による固定IPアドレス払い出し IPアドレス情報はYAMLベースの構成管理ファイルで定義 管理スイッチの接続ポートでIPアドレスが⼀意に決まる SwitchA Port1 DHCP
    SnoopingによってOption82を付与 DHCP
    Discover DHCP
    Discover RemoteID
    CircuitID :
    SwitchA
    :
    Port1 DHCP
    Client DHCP
    Server 構成管理ファイル
    (YAML) ファイルの内容に従い
    IPアドレスを決める 25
26. 構成管理ファイル(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
27. 構成管理ファイルの運⽤ 構成管理ファイルはGithubで管理している Github
    flowな運⽤ 構成ファースト:
    構成があって初めて構築できる仕組み 構成管理ファイル
    (YAML) ラック構築したい⼈ 確認者 ブランチの作成/構成ファイルの追加
    Pull
    Requestの作成 マージ 確認依頼 27
28. セットアップ処理の開始 IPアドレス払い出し後にWebhookを送信 Webhookの送信先は構成管理ファイルに定義されている SwitchA Port1 DHCP
    Discover DHCP
    Discover RemoteID
    CircuitID :
    SwitchA
    :
    Port1 DHCP
    Client DHCP
    Server セットアップサーバー （スイッチ) セットアップサーバー (サーバー) セットアップサーバー （PDU) 構成管理ファイルの定義に従い
    Webhookを送信 セットアップ処理の開始 28
29. 送信される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
30. セットアップ処理 ここは泥臭く頑張るところ
    対象デバイスによってさまざまなやり⽅で実施 サーバーの場合 PXE
    BootによるOSの起動
    +
    OSのブートストラップ機能 RedfishによるBIOS/UEFIのセットアップ ネットワーク機器の場合 基本はShellScript+expectでごりごり
    セットアップ完了後は監視を有効化する 30
31. 監視システムの構成 Prometheusを利⽤した監視基盤を構築 Alertmanagerによるアラート管理 サーバの監視 Redfishを利⽤するExporterを実装して利⽤ RAIDのステータス監視も⾏っている ネットワーク機器の監視 主にSNMP
    Expoterを利⽤ 追加でメトリクスを取得したい⼀部の機器は⾃作している 31
32. 監視の有効化 監視されるデバイスはConsulで管理している PrometheusのConsul
    Discoveryを利⽤ Consulに登録後、⾃動的にモニタリングが開始される セットアップサーバー セットアップ処理の開始 完了/エラーの通知 Consul Discovery 監視 監視登録 32
33. コンフィグバックアップの⾃動化 ネットワーク機器のコンフィグバックアップツール https://github.com/ytti/oxidized Git連携によるコンフィグの差分管理 HTTP
    Sourceを利⽤してConsulと連携 バックアップ対象のリストをHTTP経由で取得する機能 Consulに登録されたデータをHTTP
    Source形式のJSONに変換 して返すサーバを実装 33
34. 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
35. まとめ さくらの専⽤サーバ
    PHYにおける構築の仕組み 設置と配線のみで⾃動構築できる仕組みが出来た DHCP
    Option82をキーにしたIPアドレス払い出し 払い出し後のWebhookで個別に⾃動構築を実施 ラック構成管理を構築フローに組み込み 構成情報の⼀元化 構成を前提とした⾃動化で作業ミスの可能性を低減 セットアップから監視登録、在庫化まで⾃動で完結 35