Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

DeNA Private Cloud の現在と未来

29,996 views

Published on

DeNA TechCon 2018の登壇資料です。

Published in: Technology
  • Be the first to comment

DeNA Private Cloud の現在と未来

  1. 1. DeNA Private Cloudの現在と未来 システム本部 IT基盤部 廣瀬 正明
  2. 2. 自己紹介 氏名 廣瀬 正明 入社 2011年12月 所属 システム&デザイン本部 IT基盤部 1
  3. 3. アジェンダ • Private Cloud導入の背景と目的 • これまで編 – 現在の規模感 – OpenStack Mitakaへアップグレード – Canonical Livepatch Service導入 – VM HA導入 – 管理者権限分離 – Ceph改善 • これから編 – OpenStack on Container – Container on OpenStack – Cephバージョンアップ 2
  4. 4. Private Cloud導入の背景と目的 3
  5. 5. DeNA TechCon 2016, 2017 4
  6. 6. Private cloud導入の目的 • サーバー運用とネットワーク運用の統合 – 依頼業務、待ちを無くし、スピードアップを 図る – OpenStack, SDN, LBaaSの導入 • 仮想化基盤の運用改善 – ホストサーバー故障時のゲスト再構築の手間 を減らしたい – SDSとしてCephの導入 5
  7. 7. 構成図 66 © 2016 Big Switch Networks,Inc. All rights reserved. © 2014 F5 Networks,Inc. All rights reserved. © 2015, Red Hat, Inc. All rights reserved. Production: OpenStack version: Mitaka OS: Ubuntu 14.04 + xenial kernel + kernel livepatch © 2015, Red Hat, Inc. All rights reserved. © The OpenStack Foundation September 19,2012 © The OpenStack Foundation September 19,2012 Development: OpenStack version: Mitaka OS: Ubuntu 14.04 + xenial kernel + kernel livepatch
  8. 8. 7 これまで編 現在の規模感 OpenStack Mitakaへアップグレード Canonical Livepatch Service導入 VM HA導入 管理者権限分離 Ceph改善
  9. 9. 現在の規模感 8 80 Compute nodes 2,000 Instances 100 TB Volume size
  10. 10. 9 これまで編 現在の規模感 OpenStack Mitakaへアップグレード Canonical Livepatch Service導入 VM HA導入 管理者権限分離 Ceph改善
  11. 11. OpenStack Mitakaへアップグレード • ねらい – Kilo, Liberty混在をMitakaに統一したかった – Horizonでインスタンス作成時にメタデータ を入力したかった • 内製のサーバー管理ツールとの連携のため 10
  12. 12. OpenStack Mitakaへアップグレード • セミライブアップグレード – 各コンポーネントのAPIは一時的に止めた – 稼働中のインスタンスは無停止 • 詳しい手順はブログを参照ください – DeNAにおけるOpenStack Upgrade https://engineer.dena.jp/2017/08/denaopenstack4.html 11
  13. 13. OpenStack Mitakaへアップグレード • 遭遇した問題 – Open vSwitchのタグ情報(other_config)の違いに より、インスタンスの通信が数秒間途絶える – iptablesのCTターゲットのzoneの扱いの違いで、イ ンスタンスの接続済コネクションの通信が途絶える – OVSブリッジのfail_modeの値によってフロー情報が クリアされてしまい、通信断が発生する • 入念な事前検証で発見された問題 – 対策を準備したので、実際のアップグレードは大き な問題はなく完遂できた 12
  14. 14. 13 これまで編 現在の規模感 OpenStack Mitakaへアップグレード Canonical Livepatch Service導入 VM HA導入 管理者権限分離 Ceph改善
  15. 15. Canonical Livepatch Service導入 • ねらい – Computeノードの再起動は極力避けたい • インスタンスが50程度稼働しているので、live migrationで きるとはいえComputeノード全台で行うのはかなりの手間 になる – とはいえ、再起動せざるを得ないときもある • Kernelの脆弱性対応 – CVE-2017-2636: local privilege escalation flaw in n_hdlc – CVE-2017-6074: DCCP double-free vulnerability (local root) – などなど 14
  16. 16. Canonical Livepatch Service導入 • Canonical Livepatch Serviceとは – 危険度が高いkernel脆弱性の修正パッチを自動で再 起動せずに適用してくれる夢のようなサービス – Linux kernel 4.0で実装されたlivepatch機能 (Documentation/livepatch/livepatch.txt)を利用 している – Canonicalによる有償サービス(1台$225/年〜) – 対象: Ubuntu 14.04, 16.04 • 2017/6に14.04対応が発表された ※16.04のバックポート kernelをインストールする必要あり 15
  17. 17. Canonical Livepatch Service導入 • 参考 – Canonical Livepatch Service https://www.ubuntu.com/server/livepatch – Kernel/Livepatch - Ubuntu Wiki https://wiki.ubuntu.com/Kernel/Livepatch – Plans and pricing https://www.ubuntu.com/support/plans-and-pricing – Canonical Kernel Livepatch Service now available for Ubuntu 14.04 LTS! | Ubuntu Insights https://insights.ubuntu.com/2017/06/06/canonical- kernel-livepatch-service-now-available-for-ubuntu- 14-04-lts/ 16
  18. 18. 17 これまで編 現在の規模感 OpenStack Mitakaへアップグレード Canonical Livepatch Service導入 VM HA導入 管理者権限分離 Ceph改善
  19. 19. VM HA導入 • ねらい – Computeノードが突然ダウンすると、数十のイ ンスタンスが停止する – 分散ストレージ (Ceph) を使っているので、別の Computeノードで起動し直し復旧できる • が、手作業でやるとそこそこ手間 • 夜中に起こされたくない。。。 – インスタンスの起動し直し(evacuate)を自動 化したい 18
  20. 20. VM HA導入 • Masakari – Virtual Machine High Availability(VMHA)を実 現するプロダクト • インスタンスの異常終了 • nova-computeプロセスの停止 • Computeノードの停止 – https://github.com/ntt-sic/masakari • オリジナル実装 – https://github.com/openstack/masakari • OpenStackの公式プロジェクトを目指している実装 19
  21. 21. VM HA導入 • オリジナル実装に手を入れて使用 – 機能的に十分だったし、新しい方はMitakaに対応してなかった ので • 修正点 (PR済) – Evacuate発動までの時間を約300秒から約50秒に短縮できた • 数十のインスタンスをevacuateするといくつか失敗することがあ る – 外部スクリプトで状態を監視して、リトライするようにした • 導入後数回Computenノードがダウンしたが、無事に全台 evacuateできた 20
  22. 22. 21 これまで編 現在の規模感 OpenStack Mitakaへアップグレード Canonical Livepatch Service導入 VM HA導入 管理者権限分離 Ceph改善
  23. 23. 管理者権限分離 • ねらい – 初期状態だとadminしか新規プロジェクトを作れ ない • admin権限は最高権限なので多くの人に付与したくな い – IT基盤部のチームで自由にプロジェクトを作れる ようにし、作ったプロジェクトには管理権限を与 えたい • 他のチームのプロジェクトは操作できないようにした い 22
  24. 24. 管理者権限分離 • 実現方針 – チームのメンバーが属するチームプロジェクトを 用意する – チームプロジェクトのメンバーには、新設した project_admin権限を与える – 各サービスのプロジェクトは、チームプロジェク トの小プロジェクトとして作る – project_admin権限は子プロジェクトに継承され るようにする 23
  25. 25. 管理者権限分離 • keystone.conf – [os_inherit] enabled=True • Mitakaでdeprecated、Ocataで削除されデフォルト有効になっ た • keystone API v3を使う – Horizonの設定 • policy.jsonを変更する – Keystone – Horizon • Horizon本体のコード修正 • 詳細は後日ブログに… 24
  26. 26. 25 これまで編 現在の規模感 OpenStack Mitakaへアップグレード Canonical Livepatch Service導入 VM HA導入 管理者権限分離 Ceph改善
  27. 27. Ceph改善 • OSD in/out時の負荷軽減 • 容量ならしの自動化 • I/O制限導入 • NVMeSSD化検討 26
  28. 28. Ceph改善 - OSD in/out時の負荷軽減 • ねらい – OSDを再起動した際に発生するI/O遅延の抑制す る • 約130秒間、最大で28.5秒のI/O遅延 – OSDを新規に追加した際にかかる時間を短縮す る • 約37時間 – OSDを新規に追加した際に発生するI/O遅延を抑 制する 27
  29. 29. Ceph改善 - OSD in/out時の負荷軽減 • 現行のSATA-HDD 8TBとNVMeSSDとでベンチマー ク – OSD再起動 • 約130秒間、最大で28.5秒のI/O遅延 • →約10秒間、最大で1.7秒のI/O遅延 – OSD新規追加 • 約37時間 • →約5.3時間 • NVMeSSDは%utilが15%程度だったので、I/O遅延の 発生回数、遅延時間も小さくなると予測される 28
  30. 30. Ceph改善 • OSD in/out時の負荷軽減 • 容量ならしの自動化 • I/O制限導入 • NVMeSSD化検討 29
  31. 31. Ceph改善 - 容量ならしの自動化 • ねらい – それぞれのOSDが保持するオブジェクトの数は ある程度ばらつきがある – ばらつきが大きいと、上限に達しそうなOSDが いる一方で、まだまだ余裕のあるOSDが存在す る状況になる – osd reweightを使いオブジェクトを移動させて 均等化することができる – が、それを手動で行うのは非効率 30
  32. 32. Ceph改善 - 容量ならしの自動化 • スクリプトを書いて自動化 – 以下を1分毎に行う • 最も使用量が多いOSDを選出し、所定の閾値より 多く使っていたら、ちょっとweightを下げる • 使用量が小さく、所定の閾値より少なく使ってい たら、ちょっとweightを上げる 31
  33. 33. Ceph改善 • OSD in/out時の負荷軽減 • 容量ならしの自動化 • I/O制限導入 • NVMeSSD化検討 32
  34. 34. Ceph改善 – I/O制限導入 • ねらい – 一部のインスタンスが高いI/Oを出すと、全 体影響が出てしまう • 現状、ひとつのクラスタなので • 復数クラスタ化も検討中 – I/Oに上限を設けて全体影響出ないようにし たい 33
  35. 35. Ceph改善 – I/O制限導入 • I/O制限を課す方法 (1) – Cinderのvolume typeに対してQoSを設定す る • cinder qos-XXX • 適用範囲:設定後に新規に作成されるインスタン ス • ※既存インスタンスには反映されない (stop/startしても) 34
  36. 36. Ceph改善 – I/O制限導入 • I/O制限を課す方法 (2) – Novaのflavorに対してQoSを設定する • openstack flavor set • 適用範囲:設定後に新規に作成されるインスタン スのうち、当該flavorであるもの • ※既存インスタンスには反映されない (stop/startしても) 35
  37. 37. Ceph改善 – I/O制限導入 • I/O制限を課す方法 (3) – インスタンス毎にNovaのDBを変更する • nova.block_device_mappingのconnection_info カラム • 適用範囲:当該インスタンス。Stop/start後に反 映される。 36
  38. 38. Ceph改善 – I/O制限導入 • I/O制限を課す方法 (4) – インスタンス毎にvirshで設定する • virsh blkdeviotune • 適用範囲:当該インスタンス。即座に反映される • ※再起動で元に戻る – total/read/write, bytes_sec/iops_sec 37
  39. 39. Ceph改善 – I/O制限導入 • 新規インスタンス – (1) Cinderのvolume typeに対してQoSを設 定する • 既存インスタンス – (4) インスタンス毎にvirshで設定する – (3) インスタンス毎にNovaのDBを変更する 38
  40. 40. Ceph改善 • OSD in/out時の負荷軽減 • 容量ならしの自動化 • I/O制限導入 • NVMeSSD化検討 39
  41. 41. Ceph改善 - NVMeSSD化検討中 • ねらい – OSD in/out時の負荷軽減(前述) – 慢性的にIO utilが高いのを解消したい 40
  42. 42. Ceph改善 - NVMeSSD化検討中 • ベンチマーク (fio) – bs: 4kb → CPUネック – bs: 32kb → ネットワークネック • TCP再送数が増える • 10GbE x 2 (IEEE 802.3ad) • 実際のワークロード – Ceph ジャーナル: 20kb – Ceph データ: 8kb • ハードウェア構成検討中 – 2U NVMeSSD x 最大24 – CPUがサチらないように – ネットワークがサチらないように 41 ジャーナル データ
  43. 43. 42 これから編 OpenStack on Container Container on OpenStack Cephバージョンアップ
  44. 44. 43 これから編 OpenStack on Container Container on OpenStack Cephバージョンアップ
  45. 45. OpenStack on Container • OpenStackはmicroservicesなのでコンテナと の相性はよい 44https://www.suse.com/documentation/suse-openstack-cloud-7/book_cloud_admin/data/sect1_chapter_book_cloud_admin.html nova-compute nova-scheduler nova-conductor nova-cert nova-consoleauth …
  46. 46. OpenStack on Container • ねらい – 特定のコンポーネントは新しいバージョンを 使いたい • コンポーネント毎に実行環境を分離 – 全体アップグレード時の手間を軽減したい • 検証環境でテストされたイメージを共用 • コンテナを新しいイメージで起動するだけでアッ プグレード完了 45
  47. 47. OpenStack on Container • コンテナ構成を支援するプロジェクトの充実 – Kolla • OpenStackのコンポーネントのコンテナ化とデプ ロイを支援するプロジェクト – OpenStack-Helm • Kubernetes上でのOpenStackコンポーネントの デプロイを支援するプロジェクト • 大手テレコムなどの事例 46
  48. 48. 47 これから編 OpenStack on Container Container on OpenStack Cephバージョンアップ
  49. 49. Container on OpenStack • ねらい – 利用者(開発者)からの「コンテナ使いたい!」 要望を叶える – 運用者視点では、kernel共有型のコンテナを使う ことでkernelに脆弱性があってもインスタンス側 での対応が不要になる • Kernel livepatchのおかげ • アプリケーションコンテナだけでなく、KVMの代替し てLXDなどのシステムコンテナも検討する 48
  50. 50. 49 これから編 OpenStack on Container Container on OpenStack Cephバージョンアップ
  51. 51. Cephバージョンアップ • ねらい – 性能向上 – バージョン • Hammer (v0.94) ←使用中 • Jewel (v10.2.0) • Luminous (v12.2.0) ←これにしたい 50
  52. 52. Cephバージョンアップ • BlueStore – Cephの新しいストレージバックエンド • Ceph Jewelで実装、Luminousでデフォルトのバックエンドに なった – 特徴 • ブロックデバイスに直接読み書きする – 旧来のFileStoreはxfs等のファイルシステム上のファイルで 管理 • メタデータの管理にRocksDBを採用 – パフォーマンス • ざっくり2〜3倍の性能向上と言われている • 社内でも軽く検証した結果、確かに性能向上が確認できた 51
  53. 53. まとめ • Private Cloud導入の背景と目的 • これまで編 – 現在の規模感 – OpenStack Mitakaへアップグレード – Canonical Livepatch Service導入 – VM HA導入 – 管理者権限分離 – Ceph改善 • これから編 – OpenStack on Container – Container on OpenStack – Cephバージョンアップ 52

×