OpenStackのアップグレードで悩むサーバ管理者を救う「Ops Workshop」の“集合知”（1/2 ページ）

OpenStackでは、開発者のコミュニティーの他にオペレーター側の運用ノウハウの共有と議論を深める場としてWorkshopを設けている。現場から挙がる運用事例と解決策の集合知を紹介しよう。

公開 2016年09月08日 09時02分

更新 2017年02月14日 11時36分

著者

塩田紳二

[著]

印刷する

　2016年7月に開催された、クラウド環境構築ソフトウェア「OpenStack」専門の年次カンファレンス「OpenStack Days Tokyo 2016」。その一環として、OpenStackを実際に利用しているオペレーターによるオペレーターのためのワークショップ「The 2nd Japan Ops Workshop」が開かれた。2015年12月に沖縄で開催された「Okinawa OpenDays 2015」に続く第2回目となる。

　本家の「Ops Meetup」は、開発者や機器メーカーなどが中心になるが、このOps Workshopは、日本で、OpenStackを用いてWebサイトを運営しているネットワーク管理者やサーバ管理者といった「システムオペレーター」が多数参加した。

　「DevOps」という言葉もよく耳にする。開発者と運用担当者が協力する開発手法の1つで、開発と運用の距離が縮まりつつある。オープンソースソフトウェア（OSS）を使った運用では、管理者や運用担当者といえども、ソフトウェアの内部に入り込まねばならない。

　オープンソースプロジェクトというと、開発者のコミュニティーに注目しがちだが、大規模なクラウド環境を運用するためのOpenStackは、これを導入して正常に稼働するために日夜苦労しているオペレーターがいてこそのシステムといえる。Ops Workshopは、オペレーターが必要とするOpenStackの管理ツールやバージョン管理などに関する情報交換とノウハウの共有だけでなく、現場の運用で発見した不具合や改善点を取りまとめて開発者側に要望するといった役割も果たそうとしている。

　第2回目となるOps Workshopでは、どのようなノウハウの共有があったのだろうか。その具体的な提案を紹介する。

併せて読みたいお勧め記事

サーバ分野で採用が進むオープンソース

管理担当者を悩ませるオープンソースの問題とは

業務に支障なくコールドアップグレードはできるのか

　Ops Workshopでは、OpenStackのユーザー企業のオペレーターによるプレゼンテーション、そして特定のテーマに沿ったディスカッションという構成で、複数のテーマを取り上げた。

　NTTレゾナントとNTTソフトウェアは「実録！　大規模環境のOpenStackアップグレードの考え方と実施のコツ」と題するプレゼンテーションを行った。NTTレゾナントが運営するWebポータルサイト「goo」は、Web検索やブログ、メールなどなど60種を越えるサービスを提供しており、月間11億7000万PV（ページビュー）を誇る。同社は400台の物理サーバと、そこに搭載した4800基の物理CPUを管理している。2014年10月からはプライベートクラウドも稼働した。プレゼンテーションでは、gooでの実際の作業を基に、業務に支障がないようにOpenStackをアップグレードするためのノウハウを紹介した。

　半年ごとにメジャーリリースがあることが、OpenStackの特徴の1つだ。OpenStackの開発コミュニティーによる各バージョンのサポートは、リリースから約1年後には終了する。加えてOpenStackの新機能は、最新バージョンでのみサポートするが、それ以前のOpenStackのバージョンでは公式にはサポートしない。こうした開発コミュニティーの動向に合わせて、ディストリビューターもOpenStackのサポートを一定期間に限定している。Red Hatなら3年、Canonicalは最大5年（バージョンにより異なる）だ。このため、OpenStackの利用者も定期的にアップグレードする必要がある。

　OpenStackのアップグレードには、全体を一気に変更する「コールドアップグレード」と、サーバ単位の「ローリングアップグレード」がある。コールドアップグレードは、OpenStackを完全に停止する必要がある。ローリングアップグレードでは、OpenStack停止がサーバ単位なのでその影響を抑制できる。

OpenStackのアップグレード方法とそれぞれのメリットデメリット

　ただ、ローリングアップグレードでは、作業途中でサーバごとに異なるバージョンのOpenStackソフトウェアが動作する可能性がある。開発コミュニティーでは「コントローラーノード」（仮想マシンの制御用サーバ群）と「コンピュートノード」（仮想マシンが起動するサーバ群）のバージョンが異なった場合、新しいバージョンのコントローラーノードが1つ前のバージョンのコンピュートノードを制御する場合しかテストしていない。このため、2つ前の世代からアップグレードする場合、その挙動に対して保証できないという問題がある。

　オペレーター側から実運用重視で考えた場合、OpenStackが完全に停止するものの、コールドアップグレードが有利だ。実運用ではサービスの構築や変更などもあり、半年でアップグレードすることは困難で、年単位での運用にならざるを得ない。そうなると、連続したバージョンではなく、飛び飛びのバージョンでのアップグレードとなる可能性が高い。

　ローリングアップグレードでは、コントローラーノードを先にアップグレードし、後からコンピュートノードをアップグレードするという手順を1バージョンごとに行い、目的のバージョンに到達させる必要がある。例えば現行で「Icehouse」（2014年リリースのOpenStackのバージョン）が動作しており、2016年4月リリースの「Mitaka」や2015年10月リリースの「Liberty」へ変更する場合を考えてみよう。コールドアップグレードでは、途中段階を経ずにアップグレードが可能なのに対して、ローリングアップグレードでは、「Juno」（2014年10月リリース）から「Kilo」（2015年4月リリース）と段階を経てアップグレードしなければならない。これは、大きな手間になる。

　NTTレゾナントは、2015年12月にアップグレード作業の検討を開始し、2016年6月末にアップグレードを実施した。同社はIcehouseからLibertyへの切り替えで、コールドアップグレードを選択した。事前に検証環境を用意して検証した段階で、幾つかの問題を発見できたと報告している。

OpenStackアップグレード作業で発見した問題

　具体的なアップグレード手順では、オブジェクトストレージシステム構築ソフトウェア「OpenStack Swift」のサーバ群（以下、Swiftノード）とコントローラーノードに関して、Libertyをインストールしたハードウェアを別に用意し、データベース用サーバ群（以下、データベースノード）には既存のクラスタ内にLiberty用のサーバ群を新たに用意した。これらを段階的にIcehouseから移行し、その作業が完了してからコンピュートノードをアップグレードする一方で、データベースノードを移行する方式を選択した。アップグレード中に問題が起こった場合でも、Icehouseに戻せると考えたからだ。さらに、停止期間中のデータ転送は差分だけでよくなり停止期間を最小化できたという。

次ページへ Cinderを有効にするために必要な条件とは

印刷する

この記事の著者

塩田紳二

塩田紳二（しおだしんじ）フリーランスのテクニカルライター。雑誌編集者、家電メーカー勤務を経て現職。ASCII.JP、@IT、マイナビニュース、日経BP xTECHなどにて執筆活動を行う。IoTなどの小さなハードウェアから上はスーパーコンピューターまで「小さなものから大きなものまで。ハードもソフトも。ただしゲームとアダルトを除く」が基本コンセプト。