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.

大規模環境のOpenStack アップグレードの考え方と実施のコツ

OpenStackを継続的に運用するには、アップグレード戦略を導入段階から検討する必要があります。本資料ではOpenStackアップグレードの考え方から実施方法まで体系立てて扱います。月間1.7億UUを誇るポータルサイト”goo”を支えるNTTレゾナントのクラウド基盤は、2014年10月にOpenStackを導入し、物理サーバ400台を効率的に運用しています。
この大規模な環境をIcehouseからLibertyへ3世代アップグレードした事例をもとに、検討のポイントや実施のコツについて出し惜しみなくご紹介いたします。

  • Login to see the comments

大規模環境のOpenStack アップグレードの考え方と実施のコツ

  1. 1. Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. 実録!大規模環境のOpenStack アップグレードの考え方と実施のコツ ~NTTレゾナント、IcehouseからLibertyへ~ 2016/7/6 NTTソフトウェア株式会社 NTTレゾナント株式会社
  2. 2. Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. 2 本日の内容 • OpenStackのアップグレードとは • NTTレゾナントのOpenStack環境について • アップグレード全体の流れ • 検証内容についての紹介 • まとめ
  3. 3. Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. 3 自己紹介 橋本智哉 2001年~2012年 NTTレゾナント gooブログ・教えてgooなど主要サービスの設計・構築・運用 2012年~ (現職) NTTレゾナント サーバ基盤の設計・構築・運用 統括 三木 遼 2010年~(現職) NTTソフトウェア 仮想化関連技術に関する設計・開発・検証等 2012年(Essexの頃)からOpenStack関連プロジェクトに在籍 大木 和也 2011年~2014年 テプコシステムズ 東京電力グループIT基盤の設計・構築 2014年~2015年 NTTデータ先端技術 ログ可視化パッケージ製品の販売・保守・技術サポート 2016年~ (現職) NTTレゾナント サーバ基盤の設計・構築・運用
  4. 4. Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. 4 NTTレゾナントについて Dictionaries ZIP codes Laboratory Bodycloud Housing and real estateSearch Baby-care Movies Maps Navigation Horoscopes RankingsCar and bike News Weather Healthcare Smartphone applicationsBlogs Job search Love and marriage Online store Travel 「goo」は、使えば使うほど「あなたにフィット」していく NTTグループのポータルサイトです。Web検索やブログ、メール、 Q&Aサイト「教えて!goo」など、60を超える行動支援サービスを提 供しています。 Webポータルサイト goo http://www.goo.ne.jp/ 19周年!
  5. 5. Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. 5 NTTソフトウェアについて • 高い技術力でシステムの設計・開発・運用を手がける • 近年の注力キーワードは「クラウド」と「セキュリティ」 https://www.ntts.co.jp/ OpenStack案件の お手伝いします!!
  6. 6. 6Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. OpenStackのアップグレードとは
  7. 7. Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. 7 OpenStackのアップグレードについておさらい • コミュニティとしてのリリースサイクル • 半年ごとにメジャーリリース • 約一年後にEOLとなる • 新機能は最新のバージョンにしか追加されない Series Status Initial Release Date EOL Date Ocata Future TBD TBD Newton Under Development 2016-10-06 (planned) TBD Mitaka Current stable release, security-supported 2016-04-07 TBD Liberty Security-supported 2015-10-15 2016-11-17 Kilo EOL 2015-04-30 2016-05-02 Juno EOL 2014-10-16 2015-12-07 Icehouse EOL 2014-04-17 2015-07-02 Havana EOL 2013-10-17 2014-09-30 * http://releases.openstack.org/
  8. 8. Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. 8 OpenStackのアップグレードについておさらい • 主なディストリビューションでのリリースサイクル • RedHatはリリースから3年間のサポートを提供 • Ubuntuはバージョンによって異なるが最大で5年間のサポートを提供 Red Hat OpenStack Platform Release General Availability End of Production, Phase 1 End of Production, Phase 2 3(Grizzly) July 10, 2013 n/a July 31, 2014 4(Havana) December 19, 2013 June 19, 2015 June 19, 2015 5(Icehouse) June 30, 2014 June 30, 2015 June 30, 2017 6(Juno) Feb 9, 2015 Feb 9, 2016 Feb 17, 2018 7(Kilo) August 5, 2015 August 5, 2016 August 5, 2018 8(Liberty) April 20, 2016 April 20, 2017 April 20, 2019 ■ RedHat* ■ Ubuntu** * https://access.redhat.com/support/policy/updates/openstack/platform ** https://wiki.ubuntu.com/OpenStack/CloudArchive
  9. 9. Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. 9 OpenStackのアップグレード手法について • アップグレードはHavanaの頃から考慮されている • 無停止でのアップグレードもサポートされている コールドアップグレード ローリングアップグレード 考え方 OpenStackを完全に停止して更新する※ OpenStack停止時間の最小化を目指す 主な実現項目 • 1バージョン前とのConfigの互換性の維持 • DBスキーマ更新方法の提供 • 1バージョンアップグレード手順の提供 • コミュニティCIによる検証が実施されている • コールドアップグレードと同様の項目 • 複数のホストで異なるバージョンが混在する状態 での動作 対応中の プロジェクト Horizon, Keystone, Glance, Neutron, Nova, Swift, Ceilometer, Cinder, Fuel, Heat, Manila, Sahara Nova, Swift, Neutron ※OpenStackが停止してもVMやボリュームは停止しません
  10. 10. Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. 10 OpenStackのアップグレード手法について • ローリングアップデートでの制約事項 • 基本的に一つ前のバージョンとの連携しかテストされていない Compute Nodes Controller Nodes Icehouse Icehouse連携可能 Compute Nodes Controller Nodes Juno Icehouseサポート済 Compute Nodes Controller Nodes Kilo Icehouseサポート外
  11. 11. Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. 11 OpenStackのアップグレード手法について • 基本的にはコールドアップデートがお勧め • IからLなど数段階のアップグレードをする場合、ローリングアップデートでは 手順が煩雑 I J K L I J K L コントローラー ノード コンピュート ノード ①アップグレード ② ①の後でアップグレード ③ ④ ⑤ ⑥ ■ ローリングアップデート I L I L コントローラー ノード コンピュート ノード ①アップグレード ② ①同時にアップグレード ■ コールドアップデート
  12. 12. Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. 12 アップグレードへの考え方 商用ディストリビューションで長期サポートを確保する • システム廃棄期限までアップグレードしない • 新機能の追加は行わない コールドアップグレードできる環境作り • OpenStackを停止することへの組織内での合意形成 • OpenStackを停止できればアップグレードは比較的容易
  13. 13. 13Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. NTTレゾナントのOpenStack環境について
  14. 14. Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. 14 NTTレゾナントのOpenStackについて • 2014年10月から運用中のプライベートクラウド • 大小80種類以上のサービスを収容 • 月間 10億PV を支える環境 • 400台の物理サーバ & 4800物理CPUコア NTTレゾナントのメインデータセンタにOpenStackを導入 【VM起動数】 2016年7月現在 2200台以上 0 500 1000 1500 2000 2500 Launch
  15. 15. Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. 15 なぜアップグレードするのか? • プライベートクラウド機能追加要望への対応 • Kiloの新機能であるLBaaS(v2)等の利用を検討している • その他の今後発生する新機能への対応を考慮 • アップグレード手順の早期確立 Series Status Initial Release Date EOL Date Ocata Future TBD TBD Newton Under Development 2016-10-06 (planned) TBD Mitaka Current stable release, security-supported 2016-04-07 TBD Liberty Security-supported 2015-10-15 2016-11-17 Kilo EOL 2015-04-30 2016-05-02 Juno EOL 2014-10-16 2015-12-07 Icehouse EOL 2014-04-17 2015-07-02 Havana EOL 2013-10-17 2014-09-30 * http://releases.openstack.org/
  16. 16. Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. 16 OpenStack環境構成(1) OpenStack環境の全体像 • 物理サーバは約400台で、すべてスペックは同一のものを使用 – ※赤枠はKVM上で動作しているマシン • OpenStack環境上で動作しているVMは約2200台 Compute node Compute node Child cell Controller A Child cell Controller B Top cell Controller Maria DB Swift storage Swift storage Swift proxy 共通系 (DNS,Zabbix…) DNS コントローラノード (API受付・スケジューラ) コンピュートノード (VM起動) Swiftノード (イメージ管理) Cell A Cell B
  17. 17. Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. 17 OpenStack環境構成(2) • 利用モジュール・バックエンド等 • VMのパフォーマンスを最重要視した構成としている モジュール名 利用中 バックエンド 備考・特徴など Keystone Yes 認証基盤: →既存の共通認証システムと連携 特になし Nova Yes 仮想化: →Qemu/KVM ストレージ: →Qcow2をローカルディスクに保存 多量のComputeノードが存在する環境に対応するため、 Nova Cell(v1)を使用して、DBとMQを分割している Neutron Yes テナント間NW隔離: →VLAN IPとMacアドレスの管理に使用している。 仮想ルータや仮想FWなどのNFV機能は使用していない。 Glance Yes イメージ格納先: →Swift イメージとスナップショットの管理に使用 Swift Yes オブジェクト格納先: →ローカルディスク 特になし Horizon Yes - 運用ルールに基づいてカスタマイズして利用 Cinder - - ブロックストレージサービスは提供しない
  18. 18. Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. 18 OpenStack環境構成(3) • 利用中のOS • CentOS 6.x 及び 7.xを使用 • OpenStackインストーラ • Icehouse版Packstack(Puppet)をベース • 前述の環境構成を実現するために独自に改造 • OpenStackパッケージ • RDOベース • Horizon修正と、致命的なバグは独自に適用
  19. 19. 19Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. アップグレード全体の流れ
  20. 20. Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. 20 全体の工程・実施期間 アップグレード方針調査・決定 検証環境での手順作成 本番 検証環境構築 本番実施 2015年 12月 2016年 1月 6月3月2月 4月 5月 全体の流れ 本番環境 事前準備
  21. 21. Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. 21 アップグレード実施方針の調査 • 公式ドキュメントのガイドラインを調査* • アップグレードの基本的な流れが紹介されている • 詳細な手順は環境に依存するため、独自に確立する • 事前検証は絶対に必要 • 「極力本番に近い環境を用意すること」と記されている • 今回は商用クラウドを用いて本番に近い環境を構築した * http://docs.openstack.org/ops-guide/ops_upgrades.html サービス 停止 バックアップ 取得 パッケージ 更新 Config 更新 Database 最新化 サービス 起動
  22. 22. Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. 22 アップグレード実施方針の決定(1) サービス 停止 バックアップ 取得 パッケージ 更新 Config 更新 Database 最新化 サービス 起動 ▼Liberty搭載のサーバを新たに構築し、 Icehouseのサーバから切り替えるとする方式とした ・具体的にはComputeノード以外を新たに用意する ・万一に備え、ロールバックするための手順は必要と考えており、 Icehouseに切り替えるだけで、簡単に元に戻せるようにするため ▼コールドアップグレードの方式を選択 ・理想はユーザにアップグレード作業を意識させないレベルの ローリングアップグレードだが、自動化や検証等の稼働増加を懸念 ・APIサービスの停止は数日間は可能という背景があるため (ユーザ資源(VM)の停止は当然NG) ▼パッケージ更新とConfig更新は、 構成管理ツール(Puppet)を利用して自動化する ▼DB更新はコミュニティが提供しているツールを利用して実施する
  23. 23. Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. 23 アップグレード実施方針の決定(2) サービス 停止 バックアップ 取得 パッケージ 更新 Config 更新 Database 最新化 サービス 起動 Liberty ノード構築 Swiftデータ 事前コピー Icehouse 停止 バックアップ取得 (DB, Swift差分) Computeノード Libertyに更新 Database Liberty用に変換 Liberty 起動・LB切り替え 基本の流れ 事前準備期間 メンテナンス期間 ■メンテナンス期間短縮のため、 事前準備期間を用意 ▼実施内容 • Libertyノードを事前に構築(前頁より) • Swiftデータ事前コピー Swiftデータは約4TBになるため、 メンテナンス期間中に転送を実施すると、 それだけで数日掛かることが分かった。 そこで、事前にデータの大半をコピーし、 作業当日は差分のみをコピーする方式とした ■基本を踏襲し、今回の環境に読み替えた 今回の流れ
  24. 24. Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. 24 • ControllerノードとSwiftノードを新たに構築する アップグレード実施手順の説明 Database Nodes Compute Nodes Controller Nodes Swift Nodes ICEHOUSE ICEHOUSE ICEHOUSE LIBERTY Controller Nodes Swift Nodes LIBERTY 新規に構築 データベースは 既存クラスタを利用する VM VM Liberty ノード構築 Swiftデータ 事前コピー Icehouse 停止 バックアップ取得 (DB, Swift差分) Computeノード Libertyに更新 Database Liberty用に変換 Liberty 起動・LB切り替え
  25. 25. Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. 25 アップグレード実施手順の説明 • Icehouseサービス中にSwiftのデータをコピーする • ※サービス提供中の差分は公開停止後にコピーする Database Nodes Compute Nodes Controller Nodes Swift Nodes ICEHOUSE ICEHOUSE ICEHOUSE Controller Nodes Swift Nodes LIBERTY VM VM Swift 移行ツール ①Icehouseから全オブジェクト取得 ②オブジェクトのchecksumを計算 ③Libertyへアップロード LIBERTY Liberty ノード構築 Swiftデータ 事前コピー Icehouse 停止 バックアップ取得 (DB, Swift差分) Computeノード Libertyに更新 Database Liberty用に変換 Liberty 起動・LB切り替え 約4TBの転送
  26. 26. Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. 26 アップグレード実施手順の説明 • OpenStackのユーザ向けの公開を停止する • ※プロセス停止は、後述のSwiftデータ転送後 Database Nodes Compute Nodes Controller Nodes Swift Nodes ICEHOUSE ICEHOUSE ICEHOUSE Controller Nodes Swift Nodes LIBERTY VM VM ユーザ公開を 停止する LIBERTY Liberty ノード構築 Swiftデータ 事前コピー Icehouse 停止 バックアップ取得 (DB, Swift差分) Computeノード Libertyに更新 Database Liberty用に変換 Liberty 起動・LB切り替え ユーザが実施中の OpenStack処理が 存在しないことを 確認する
  27. 27. Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. 27 アップグレード実施手順の説明 • DBやConfig等、必要なバックアップを取得する • 差分データを転送後、OpenStack及び監視を完全停止する Database Nodes Compute Nodes Controller Nodes Swift Nodes ICEHOUSE ICEHOUSE ICEHOUSE Controller Nodes Swift Nodes LIBERTY VM VM LIBERTY Liberty ノード構築 Swiftデータ 事前コピー Icehouse 停止 バックアップ取得 (DB, Swift差分) Computeノード Libertyに更新 Database Liberty用に変換 Liberty 起動・LB切り替え Swift 移行ツール config Databaseや 更新により変更される Config等をバックアップ 事前コピー後からの 差分データを転送 (数GB)
  28. 28. Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. 28 アップグレード実施手順の説明 • 「パッケージ」「Config」をLibertyのものへ更新する Database Nodes Compute Nodes Controller Nodes Swift Nodes ICEHOUSE ICEHOUSE Controller Nodes Swift Nodes LIBERTY VM VM LIBERTY config Puppetを用いて約400台を 一斉に更新する パッケージ更新が VMに影響しないことを 事前に検証すること (特にqemu-kvm/libvirt) 参照するDBやMQの 接続先設定も Libertyへ変更する LIBERTY Liberty ノード構築 Swiftデータ 事前コピー Icehouse 停止 バックアップ取得 (DB, Swift差分) Computeノード Libertyに更新 Database Liberty用に変換 Liberty 起動・LB切り替え
  29. 29. Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. 29 アップグレード実施手順の説明 Database Nodes Compute Nodes Controller Nodes Swift Nodes ICEHOUSE ICEHOUSE LIBERTY Controller Nodes Swift Nodes LIBERTY VM VM LIBERTY • 作成済みのデータベースの中身を作成する • マイグレートにはCTノード(Liberty)の管理用ツールを利用 ① ダンプ・ エクスポート ② DBスキーマの マイグレート Liberty ノード構築 Swiftデータ 事前コピー Icehouse 停止 バックアップ取得 (DB, Swift差分) Computeノード Libertyに更新 Database Liberty用に変換 Liberty 起動・LB切り替え
  30. 30. Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. 30 アップグレード実施手順の説明 Database Nodes Compute Nodes Controller Nodes Swift Nodes ICEHOUSE ICEHOUSE LIBERTY Controller Nodes Swift Nodes LIBERTY VM VM LIBERTY • LBをlibertyノードに向け、サービスを再開する • 基本的な動作確認後に監視を再開する 切替 Liberty ノード構築 Swiftデータ 事前コピー Icehouse 停止 バックアップ取得 (DB, Swift差分) Computeノード Libertyに更新 Database Liberty用に変換 Liberty 起動・LB切り替え
  31. 31. 31Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. 検証内容についての紹介
  32. 32. Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. 32 事前検証の方針・観点 • 方針 • 可能な限り本番環境と同一構成の検証環境を構築し、アップグレード手 順の作成およびアップグレード・切り戻しの実施を行う • アップグレード後、正常性確認試験を実施する • 観点 • アップグレード手順に抜け漏れがないか • アップグレード手順で既存VMに影響がないか • アップグレード後、切り戻しが可能かどうか • アップグレードおよび切り戻し手順にどの程度の時間を要するか • 既存監視システムへの影響があるかどうか • 本番データでDBマイグレートが実施できるかどうか
  33. 33. Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. 33 事前検証の流れ 検証環境での事前検証検証環境構築 アップグレード検証・試験 切り戻し リハーサル (アップグレード試験) 検証環境での事前検証では、アップグレード2回、切り戻し1回を実施しました。 アップグレード検討 課題の洗い出し タイムテーブルの確定
  34. 34. Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. 34 • DBマイグレート試験にて課題を発見 検証で発生した課題の紹介(DBマイグレート) Icehouse Liberty Migrate1 Kilo • 本番環境データを利用したマイグレート試験を行ったところ、Liberty へマイグレートするためにはKiloを経由する必要があることが発覚。 • Cell環境でマイグレートを実施する際はダミーのRabbitMQが必要にな ることが判明。 Migrate2 DB Kilo環境(VM) ダミー RabbitMQ OpenStackの構成や本番環境データの状態によって、マイグ レートが想定通りにいかないことがあります。 本番環境データおよび本番と同等構成の環境でDBマイグレー ト試験を早期実施することをオススメします。
  35. 35. Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. 35 検証で発生した課題の紹介(OpenStack) • 正常性確認試験にて、OpenStackの課題を発見 • 致命的なバグが検出されることもあるため、事前検証は大事です 概要 対処 $ nova listコマンドでVMのIPアドレスが表示されない コミュニティから バックポート Horizon上でプロジェクトの切り替えが出来ない コミュニティから バックポート Horizonの一部で2バイト文字の扱いに失敗する 独自対処 (コミュニティ報告中) Shelveを実行すると複数のイメージが出来る 独自対処 (コミュニティ報告中) コミュニティからのバックポートやコード修正、テストなどを 確実に実施できる有識者、パートナーとの協力が重要となります。
  36. 36. Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. 36 検証で発生した課題の紹介(監視) • 試験にて、旧バージョンで解決済みだった監視の問題が再燃 • OpenStackの監視においては、ログの監視を行っており、無視しても良 いログを正規表現にて育てていた。 • 正常性試験時に監視システムがエラーを検知し発報 • ログのフォーマットが変更になったことにより、正規表現によって無視 していたログが検知されるようになった。 検証環境にも本番環境と同様の監視環境を構築し、監視の検証も行う必要がある 環境によっては監視環境に過大な負荷が掛かり監視が停止する恐れも……
  37. 37. 37Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. まとめ
  38. 38. Copyright© 2016 NTT Software Corporation, ©NTT Resonant Inc. 38 まとめ 本発表が皆様のOpenStack導入や、 アップグレードの実施など、何らかのお役に立てれば幸いです アップグレード手法は基本的にはコールドアップデートがお勧め 新バージョンのサーバを並行して構築しておくことで切り替え時間短縮・切り戻しも可能となる 実データを用いて初めて発覚する問題もあるので、早期に実データを用いた試験を実施しよう コミュニティからのバックポートやコード修正などを実施できる有識者、パートナーとの協力が重要

×