CyberAgentのプライベートクラウド Cycloudの運用及びモニタリングについて #CODT2020 / Administration and Monitoring for Cycloud
•
1 like•4,961 views
talked by Cloud Operator Days 2020 https://cloudopsdays.com
Recommended
More Related Content
What's hot
What's hot (20)
Similar to CyberAgentのプライベートクラウド Cycloudの運用及びモニタリングについて #CODT2020 / Administration and Monitoring for Cycloud
Similar to CyberAgentのプライベートクラウド Cycloudの運用及びモニタリングについて #CODT2020 / Administration and Monitoring for Cycloud (20)
More from whywaita
More from whywaita (20)
CyberAgentのプライベートクラウド Cycloudの運用及びモニタリングについて #CODT2020 / Administration and Monitoring for Cycloud
- 1. CyberAgentのプライベートクラウド Cycloudの運⽤及びモニタリングについて 株式会社サイバーエージェント 技術本部 プライベートクラウドグループ Nakanishi Kento @whywaita Cloud Operator Days Tokyo @ / /
- 2. Nakanisi Kento / whywaita • CyberAgent, Inc. Private Cloud Group from • 業務: OpenStack / Kubernetes を使った新機能開発 • 趣味: ⾃宅インフラ / アニソン • 在宅勤務で業務中にスピーカーから ⾳を流せるのは嬉しい！！ @whywaita
- 5. CyberAgentにおけるプライベートクラウド 5 •プライベートクラウド部署 •メディア事業部 •ブログなどメディア系事業 (ex: Ameba) 向け •発表者 whywaita はこちら •AI事業本部 •広告事業など 向け
- 6. CyberAgentにおけるプライベートクラウド 6 •プライベートクラウド部署 •メディア事業部 •ブログなどメディア系事業 (ex: Ameba) 向け •発表者 whywaita はこちら •AI事業本部 •広告事業など 向け
- 7. メディア事業部向けプライベートクラウド 7 •データセンタ運⽤開始 (2004年頃〜) •OpenStack Diablo •Clover (⾃作クラウドコントローラ) •現在: TKY / TKY ( . 〜) •TKY OpenStack Queens •Compute Node: 約250台
- 8. Cycloud 8 •Cy(berAgent)cloud •特徴 •各種コンポーネントのAPI化 •Cloud / Firewall / IPAddress / LoadBalancer / etc •性能に対するコストパフォーマンス (Public⽐) •運⽤者が「つらくない」プライベートクラウド
- 10. プライベートクラウドの「つらい」 10 •いつまでもつきまとう物理資産の管理 •「この在庫どこにいったの？？」 •「配線どうなってるんだ…」 •壊れ続けるCompute Nodeたち •「すぐ保守依頼出さなきゃ…」 •「AWS / GCPならできるのに…」
- 11. 11 ぴえん (; _ :)
- 12. 社内Slackのemoji 12
- 13. 使⽤例 13
- 18. 18 ですよね
- 20. 20
- 21. 21 そこに救世主到来✨
- 22. Bearman 22 •Django製 Baremetal 管理 (manager) ツール •物理サーバの管理 •UUID / hostname •Flavor (起動するOSの指定) •ComputeNode, Cinder, Software LoadBalancer •Network (VLAN, IPMI, IP Address)
- 23. Bearman 23 •Node: 物理サーバそのもの •Profile: OSの起動定義 •Flavor: NodeとProfileの紐付け •Network: VLAN / CIDR / GW などの情報 •Tenants: NetworkとFlavorの紐付け •Baremetals: 実際に起動しているNode情報
- 24. Bearman 24
- 26. Bearmanによる在庫管理 - 登録編 26 . iPXEによるブート (CentOS) . autorun.service が起動 . BIOS / NICのファームウェアバージョンチェック and アップ . lldpd によって近傍スイッチ情報をチェック . dmidecode コマンドでHW情報をチェック . Bearmanに登録 / IPMI設定 . CentOS シャットダウン！
- 28. Bearmanによる在庫管理 - 登録編 28 Node 初回ブート (iPXE) PXEブートによって起動 →iPXEに切替
- 30. Bearmanによる在庫管理 - 登録編 30 CentOS autorun.service 新規登録⽤ register.sh 取得 & 実⾏ object storage 1段階⽬OS
- 31. Bearmanによる在庫管理 - 登録編 31 . iPXEによるブート (CentOS) . autorun.service が起動 . BIOS / NICのファームウェアバージョンチェック and アップ . lldpd によって近傍スイッチ情報をチェック . dmidecode コマンドでHW情報をチェック . Bearmanに登録 / IPMI設定 . CentOS シャットダウン！ register.sh の職務
- 32. Bearmanによる在庫管理 - 登録編 32 CentOS autorun.service Bearmanに登録 ※正確にはregister.shで取得した bearman-cli (by Go) Bearman 1段階⽬OS register.sh https://bearman-grpc.example.com/
- 33. Bearmanによる在庫管理 - 登録編 33 CentOS autorun.service Bearman 1段階⽬OS register.sh 新規にNodeとして保存 Bearman DB Node (UUID: xxx)
- 36. Bearmanによる在庫管理 - 登録編 36 CentOS autorun.service Bearman 1段階⽬OS register.sh ②BearmanがIPMI IPを アサイン IPman ①IP払い出し
- 39. Bearmanによる在庫管理 - 登録編 39 CentOS autorun.service Bearman 1段階⽬OS register.sh IPman BMC • Node情報はBearmanから登録 • IPMIにてNodeに疎通可能
- 42. Bearmanによる在庫管理 - 起動編 42 Real OS (Ubuntu)iPXE kernel= initramfs= append= CentOS autorun.service kexec kernel= initramfs= append= 初回ブート 1段階⽬OS 2段階⽬OS
- 43. Bearmanによる在庫管理 - 起動編 43 Real OS (Ubuntu)iPXE kernel= initramfs= append= CentOS autorun.service kexec kernel= initramfs= append= 初回ブート 1段階⽬OS 2段階⽬OS 2段階⽬には ⾃由なOSを選択可能
- 47. Bearmanによる在庫管理 - 起動編 47 iPXE kernel= initramfs= append= CentOS autorun.service 初回ブート 1段階⽬OS Cephからダウンロード kexec.sh
- 48. Bearmanによる在庫管理 - 起動編 48 iPXE kernel= initramfs= append= CentOS autorun.service 初回ブート 1段階⽬OS ⾃分が起動するべき OS情報をBearmanから 取得 kexec.sh Bearman
- 49. Bearmanによる在庫管理 - 起動編 49 iPXE kernel= initramfs= append= CentOS autorun.service 初回ブート 1段階⽬OS ⾃分が起動するべき OS情報をBearmanから 取得 kexec.sh Bearman https://bearman-grpc.example.com/ipxe/${uuid}
- 50. Bearmanによる在庫管理 - 起動編 50 iPXE kernel= initramfs= append= CentOS autorun.service 初回ブート 1段階⽬OS kexec.sh Bearman https://bearman-grpc.example.com/ipxe/${uuid} $ dmidecode -s “system-uuid” にて決定
- 51. Bearmanによる在庫管理 - 起動編 51 iPXE kernel= initramfs= append= CentOS autorun.service 初回ブート 1段階⽬OS kexec.sh Bearman • 順番にエンドポイントを叩く • ${uuid}/profile • 起動⽤のprofile • ${uuid}/detail • IPアドレス / bond IPアドレスなど • ${uuid}/installed • インストール完了をBearmanに通知
- 53. Bearmanによる在庫管理 - 起動編 53 iPXE kernel= initramfs= append= CentOS autorun.service 初回ブート 1段階⽬OS kexec.sh Bearman • 順番にエンドポイントを叩く • ${uuid}/profile • 起動⽤のprofile • ${uuid}/detail • IPアドレス / bond IPアドレスなど • ${uuid}/installed • インストール完了をBearmanに通知
- 55. Bearmanによる在庫管理 - 起動編 55 iPXE kernel= initramfs= append= CentOS autorun.service 初回ブート 1段階⽬OS kexec.sh Bearman • 順番にエンドポイントを叩く • ${uuid}/profile • 起動⽤のprofile • ${uuid}/detail • IPアドレス / bond IPアドレスなど • ${uuid}/installed • インストール完了をBearmanに通知
- 57. Bearmanによる在庫管理 - 起動編 57 iPXE kernel= initramfs= append= CentOS autorun.service 初回ブート 1段階⽬OS kexec.sh Bearman このNodeが起動すべき OS情報などを取得
- 58. Bearmanによる在庫管理 - 起動編 58 iPXE kernel= initramfs= append= CentOS autorun.service kexec kernel= initramfs= append= 初回ブート 1段階⽬OS kexecのパラメータ組⽴
- 59. Bearmanによる在庫管理 - 起動編 59 Real OS (Ubuntu)iPXE kernel= initramfs= append= CentOS autorun.service kexec kernel= initramfs= append= 初回ブート 1段階⽬OS 2段階⽬OS
- 60. Bearmanによる在庫管理 - 起動編 60 Real OS (Ubuntu)iPXE kernel= initramfs= append= CentOS autorun.service kexec kernel= initramfs= append= 初回ブート 1段階⽬OS 2段階⽬OS ユーザ⽤の 2段階⽬OSが 起動成功🎉
- 61. Bearman のコンセプト 61 •No 現地作業 •ハードウェア構成の違いはソフトウェアで吸収 •利⽤者視点 •CLIツールでシステムを利⽤可能 •管理者視点 •データはDjango Adminで 閲覧/管理 可能
- 62. Bearman周辺の要素技術 62 •gRPC / Protocol Buffer •データはDBの扱いが得意なPython(Django)に •Baremetalからのアクセスはデプロイが楽なGoに •ansible (ansible_connection=lxd) なイメージ⽣成 •kernel / initramfs / rootfs を⽣成してくれる君 •VM上で物理⽤イメージをansibleで⽣成できる!!
- 63. Bearmanのメリット 63 •運⽤時の確認事項が⼤きく削減 •適切に電源 / 光ケーブルを配線し電源ポチで 🙆 •設定に不備があった場合はSlack通知で⽬視確認不要 •トラシュもフル機能のbashを使って可能 •IPMI情報などが⾃動で登録、Web画⾯から参照可 •チームメンバー誰でも気軽に物理利⽤
- 65. 65 👀監視👀してますか？
- 66. インフラ監視つらいあるある 66 •物理故障で紐付いてる監視全部発砲 😇 •付随してるメールサーバが耐えきれず 😇 •Slackに通知してたら投稿数多すぎて 😇 •メトリクスが多すぎて監視側の負荷が 😇 •監視サーバってどこまでやったら冗⻑って ⾔えますか？😇
- 67. 67 ですよね
- 68. 68 でもやらねばならぬ 🤢
- 69. 69 便利なものにのっかろう ☺
- 70. 70 最近の便利なもの
- 74. プライベートクラウド概要図 74 L Overlay Network (VXLAN on IP CLOS) Compute Node Compute Node Compute Node k s master k s master Firewall Load Blancer KVM / Container Users VM Users VM Users Service nova neutron Container KVM / Container OpenStack Controller Container other Container User Components OpenStack Components Physical Components Storage
- 75. プライベートクラウド概要図 75 L Overlay Network (VXLAN on IP CLOS) Compute Node Compute Node Compute Node k s master k s master Firewall Load Blancer KVM / Container Users VM Users VM Users Service nova neutron Container KVM / Container OpenStack Controller Container other Container User Components OpenStack Components Physical Components Storage Kubernetes Node群 managed by Bearman
- 76. プライベートクラウド概要図 76 L Overlay Network (VXLAN on IP CLOS) Compute Node Compute Node Compute Node k s master k s master Firewall Load Blancer KVM / Container Users VM Users VM Users Service nova neutron Container KVM / Container OpenStack Controller Container other Container User Components OpenStack Components Physical Components StorageKubernetesのPod (コンテナ)として OpenStack Componentsを起動
- 77. プライベートクラウド概要図 77 L Overlay Network (VXLAN on IP CLOS) Compute Node Compute Node Compute Node k s master k s master Firewall Load Blancer KVM / Container Users VM Users VM Users Service nova neutron Container KVM / Container OpenStack Controller Container other Container User Components OpenStack Components Physical Components StorageCompute Node上のnova-computeが libvirtと連携しユーザVMを作成
- 78. ディスクレスハイパーバイザ 78 •物理サーバ = Kubernetes Nodeに •OpenStack on Kubernetes •OSを全てオンメモリに展開することで障害からの 復旧を簡易化 •Bearmanと連携し簡単安全にNodeを復活 •ストレージは全てNetwork経由
- 79. Bearmanによる在庫管理 - 起動編 79 Compute NodeiPXE kernel= initramfs= append= CentOS autorun.service kexec kernel= initramfs= append= 初回ブート 1段階⽬OS 2段階⽬OS メモリ上にOSを展開
- 80. Bearmanによる在庫管理 - 起動編 80 Compute NodeiPXE kernel= initramfs= append= CentOS autorun.service kexec kernel= initramfs= append= 初回ブート 1段階⽬OS 2段階⽬OS その上にユーザのVM ストレージはiSCSI経由 Users VM Users VM Users VM
- 81. 81 👀監視👀について
- 82. 現⾏の監視概要 82 •Prometheus in Cycloud • メリット •Kubernetes との親和性 (native support) •exporterの⾃⼰開発ができる (OSS format) •ログ監視は現在なし (今回は詳細省略) •fluentdにて集約サーバに送付
- 83. Prometheus 83 •Monitoring & Metrics ツール by Golang •Graduated Project by Cloud Native Computing Foundation •Server → Agent なPull型 •動的な設定変更が標準で搭載 •通知は別コンポーネントにて⾏う •AlertManager
- 84. 現状の監視target数 84
- 85. 現状のメトリクス数 85
- 88. プライベートクラウド概要図 88 L Overlay Network (VXLAN on IP CLOS) Compute Node Compute Node Compute Node k s master k s master Firewall Load Blancer KVM / Container Users VM Users VM Users Service nova neutron Container KVM / Container OpenStack Controller Container other Container User Components OpenStack Components Physical Components StorageKubernetesのPod (コンテナ)として exporterも起動
- 89. 89
- 90. Prometheus の管理 90 •OpenStack上のVMにデプロイ •managed by terraform •config管理はansible (jinja ) + GHE •Service Discoveryは主にkubernetes_sd_configs •⼀部 file_sd_configsもあり
- 91. Prometheus の管理 91 Prometheus / Alert Manager 2300⾏ぐらい 🤯
- 95. libvirt_exporter 95 •OSS版 kumina/libvirt_exporter が存在 •libvirt XML に埋め込まれるnovaのattributeが 😫 •CPU Pinning の情報が 😫 •novaのPinning部分にバグがあり 障害発⽣したこともあるので監視したい！ •digitalocean/go-libvirt ベースに書き換え
- 96. dirty-flow-exporter 96 •Open vSwitchが挿⼊するflowがおかしい 🤔 •通信障害が発⽣ 😿 •オペレーションによりflowの修正を実⾏ •今後も不正なflowが組み込まれたら即検知したい → exporter書くぞ！！！！ ※現在はこの障害は完全に解決しています
- 97. dirty-flow-exporter 97 . Prometheusからリクエスト . ovs-ofctl dump-flows を実⾏ / パース . dirtyなflowを検知したらその数をmetricsに . metricsが1でも増えたらAlert発砲 💥 . Alertを確認して⼿動で削除 安⼼ 💯☺
- 102. 宣伝 102 •We Are Hiring! •⼀緒に問題に取り組む⽅を絶賛募集中 •インターンもお待ちしております • に にインフラ提供をします •絶賛いろいろ開発中です •おたのしみに！