2015年7月13日に行われたOpenStack Summitの歩き方で発表した資料になります。1事業者からOpenstackがどのように見えているか、Openstackをどのように導入したか、Openstack運用の課題などを解説しています。

1. goo基盤を支えるOpenstack
NTTレゾナント株式会社
ビジネスプラットフォーム事業部 サービス基盤部門
橋本 智哉
通山 和裕

2. 自己紹介
橋本智哉
通山和裕
2010年～2014年6月
NTTコミュニケーションズ OCNフレッツ系NW開発
2014年7月～ (現職)
NTTレゾナント 全社共通基盤の設計・構築・運用
2001年～2012年
NTTレゾナント gooブログ・教えてgooなど
主要サービスの設計・構築・運用
2012年～ (現職)
NTTレゾナント 全社共通基盤の設計・構築・運用
2

3. アジェンダ
• NTTレゾナントのおしごと
• NTTレゾナントのサーバ基盤概要
• NTTレゾナントのOpenStack環境の紹介
• まとめ
3

4. NTTレゾナントのおしごと
4

5. NTTレゾナントのおしごと
個人のお客様
法人のお客様
ポータルサイト等
スマホアプリ
goo milk feeder goo防災アプリ
5

6. は3月27日に18歳の誕生日を迎えました！
NTTレゾナントのおしごと
6

7. の規模感
NTTレゾナントのおしごと
ユニークユーザ数：1.7億UU/月
ページビュー数：10億PV/月
Yahoo! Google
楽天
Live
door MSN
@Nifty Excite
業界的には3番手ポジション
2015.02 NetRatings 月間UU
7

8. NTTレゾナントの
サーバ基盤概要
8

9. NTTレゾナントのサーバ基盤概要
• 2014年10月から運用中のプライベートクラウド(Openstack利用)
• 80種類以上のサービスを収容
• 月間 数億PV を支える環境
– 400台の物理サーバ
– 1700台以上の仮想サーバ
• 監視設定・障害管理をできるだけ自動化
– 監視対象サーバをZabbixが検出、ルールに基づき自動監視設定
– Zabbixが障害を検知するとRedmineに自動的にチケット起票
• 対インターネットトラフィック
NTTレゾナントのメインデータセンタ
9

10. サービス部隊
基盤部隊
NTTレゾナントのサーバ基盤概要
社内の体制
サービス担当 サービス担当
NTTレゾナント
サービス担当 サービス担当
サービス担当 サービス担当
サービス担当 サービス担当
～80サービス
共通基盤提供
運用委託先
複数社
…連携
10
～10人ほど
300人～
…

11. NTTレゾナントの
OpenStack環境の紹介
11

12. OpenStack環境の紹介
• 月間 数億PV を支える環境
• 400台の物理サーバ
• 1700台以上の仮想サーバ(2015年7月時点)
• 80種類以上のサービスを収容
規模
12

13. OpenStack環境の紹介
OpenStack機能イメージ
13
Horizon 各種API
Neutron
Nova
Glance
Cinder
Swift
Keystone
仮想ネットワーク制御
ハイパーバイザ制御
ベアメタル
プロビジョニング
イメージ
スナップショット管理
ブロックストレージ
制御
オブジェクト
ストレージ
統合認証
仮想ルータ、仮想L2
仮想ロードバランサ
仮想サーバ作成・削除
物理サーバ
仮想マシンのテンプレート
設定済みイメージのスナップショット
仮想ボリューム
REST入出力ファイルストア
レプリケーション、遠隔地分散
NTTレゾナント利用機能
VM VM VM
APP
OS
APP
OS
APP
OS
designed by Freepik

14. OpenStack環境の紹介
• 割り切った使い方をしています
– Neutron,Cinderの二大機能は(ほぼ)使用していない
– 仮想マシン管理に必要な部分に絞っている
• まずは仮想マシン管理を効率化・迅速化することを優先
– Neutronでの仮想NW構築はいったん見送り
– NWは今まで通りアプライアンス製品で手堅く構成
• 安価なサーバーを並べて運用してきた歴史
– 共有ストレージを利用せずに構成されている
– Cinderを使わなくてもサービス運用できる
NTTレゾナントでのOpenstack利用
14

15. OpenStack環境の紹介
• 検討開始からOpenStack部分の稼働開始まで約6ヶ月
– 色々割り切ったので、この期間で稼働させることに成功した
– その後、4ヶ月で80サービスをOpenstack環境に移転
OpenStack導入スケジュール
15
3月 7月 10月 1月６月4月 5月 8月 9月 11月 12月
2014年 2015年
Openstack環境構築Openstack環境構築
DC内設備設計 DC内物理構築作業
旧環境からのサービス移転作業
★Openstack本番運用開始
★移転完了
Openstack設計Openstack設計
要
件
定
義
約6ヶ月

16. OpenStack環境の紹介
• ホスト名の命名ルールを
強制したい
• セキュリティルールは
各サービスには触らせない
• OpenStackへの改造を実施
– Horizon(Webコンソール)への
修正を中心に約40項目
NTTレゾナント運用要件
• VM作成後、
VMの名前解決を可能にする
• VM作成後、
Puppetを即時実行可能にする
• OpenStack APIと連携したツールの実装
– VM追加・削除時に
ローカルDNS・LDAPにデータ連携
対応方法
• NTTレゾナント独自の運用要件に以下のように対応
– 組織によるが、素のOpenStackで業務を回せるとは限らない
OpenStackの改造と周辺ツール
16

17. OpenStack環境の紹介
• 仮想マシン提供時間が大幅スピードアップ
– 以前：VM作成申請から受領まで最大5営業日
– 現在：長くても5分、短ければ5秒
迅速化迅速化
稼働調整
必要なし
稼働調整
必要なし
作成コスト０作成コスト０
• 繁忙期でも余裕で対応
– 1ヶ月で1000VM以上を提供した
– 人手で対応していたら…
• スクラップ＆ビルドが容易に
– 試しにサーバを作ってみて、
うまくいかなければ壊してもう一度、
が簡単にできる
OpenStack導入の効果
17

18. OpenStack環境の紹介
• Puppetを標準ツールとして大規模に使用
– Puppetとは
• ユーザ作成・設定ファイルの配布など環境構築をコード化するツール
• 誰が、いつ実行しても完全に同じサーバが構築できる
– 2012年ごろから本格的に利用開始
– OpenStackそのもの、OpenStack上の仮想サーバもpuppetで構成管理
– ほぼすべてのサービスで利用
class openstack_keystone {
package { 'openstack-keystone':
ensure => latest,
require => [
Class['openstack_yum'],
File['/usr/local/bin/deploy_utils/check_keystone_tables.sh']];
}
:
: ※マニフェストの一部
構成管理について
18

19. OpenStack環境の紹介
• Openstack自体のバージョンアップ
– 1世代先へのversion upは設計上サポートされている
• ○Icehouse → Juno
• ×Icehouse → 一気にKilo
– 半年に1回のリリースに追従するのはかなり厳しい
• 自社用パッチを半年ごとに書き直す必要
• 検証や手順作成に手間がかかる（特に、初回はノウハウもない）
• Icehouse → 一旦Juno化 → すぐKilo化
を一度のメンテナンスで実施するのか？
– Verup作業中にサービス提供中のVMを停止したくない
• VMを稼働させながらのverup作業が自環境で可能か？
• Openstackのダウンタイムも極力短くしたいが、所要時間は？
– 悩みは尽きない
今後の方向性と課題
19

20. OpenStack環境の紹介
• Openstack自体のバージョンアップ
– CentOS6 と RDO を使って Openstack Icehouse を導入した
– RDOとは？
• Red Hat系OSでOpenstackを利用する人々のコミュニティの名称
• そこで提供されるRed Hat系のOpenstackパッケージ
今後の方向性と課題
20
https://www.rdoproject.org/

21. OpenStack環境の紹介
• Openstack自体のバージョンアップ
– CentOS6 と RDO を使って Openstack Icehouse を導入した
– が、CentOS6用のRDO(Juno版)は公式提供されていない！
今後の方向性と課題
21
CentOS7向けの
epel-7しかない
RDO Juno版リポジトリ
よく見ると
6向けのREADMEが置いてある！

22. OpenStack環境の紹介
• Openstack自体のバージョンアップ
– READMEの中身
今後の方向性と課題
22

23. OpenStack環境の紹介
• Openstack自体のバージョンアップ
– READMEのリンク先に
Nova, Ceilometerだけは有志が作成したJuno版PKGが置いてある
今後の方向性と課題
23
今から構築するならCentOS7 / RHEL7必須？

24. OpenStack環境の紹介
• Openstackのログ管理と分析
– 運用にはDEBUGログが重要だが、DEBUGログはとにかく量が多い
– 例）Openstack インスタンスを1個起動した（だけ）の正常系ログ
24
223行,119698文字
※DEBUGを除外すると24行しかない
今後の方向性と課題

25. OpenStack環境の紹介
• Openstackのログ管理と分析
– DEBUGログを除外して解析してみる (request-idでgrep)
– 例）インスタンスを1つ作成しようとして失敗した場合
25
2015-07-XX 17:00:YY TopCellController INFO
nova.osapi_compute.wsgi.server
172.X.X.X "GET <API_URL>/servers/<VM-UUID> HTTP/1.1" status: 200
→作成依頼を受け付けた
2015-07-XX 17:00:YY TopCellController INFO
nova.scheduler.filter_scheduler Attempting to build 1 instance(s)
→これから1インスタンスを作成する予告
2015-07-XX 17:00:YY ChildCellController WARNING
nova.scheduler.driver [instance:<VM-UUID>] Setting instance to ERROR state.
→インスタンスの状態をERRORに変更
2015-07-XX 17:00:YY ChildCellController INFO
nova.filters Filter DiskFilter returned 0 hosts
→ディスク容量判定フィルタが「作成先ハイパーバイザがない」と返している模様
…理由は？
2015-07-XX 17:00:YY TopCellController INFO
nova.osapi_compute.wsgi.server
172.X.X.X "GET <API_URL>/servers/<VM-UUID> HTTP/1.1" status: 200
→作成依頼を受け付けた
2015-07-XX 17:00:YY TopCellController INFO
nova.scheduler.filter_scheduler Attempting to build 1 instance(s)
→これから1インスタンスを作成する予告
2015-07-XX 17:00:YY ChildCellController WARNING
nova.scheduler.driver [instance:<VM-UUID>] Setting instance to ERROR state.
→インスタンスの状態をERRORに変更
2015-07-XX 17:00:YY ChildCellController INFO
nova.filters Filter DiskFilter returned 0 hosts
→ディスク容量判定フィルタが「作成先ハイパーバイザがない」と返している模様
…理由は？
今後の方向性と課題

26. OpenStack環境の紹介
• Openstackのログ管理と分析
– DEBUGログを解析してみると…
– 例）インスタンスを1つ作成しようとして失敗した場合
26
2015-07-XX 17:00:YY ChildCellController DEBUG
nova.filters Filter RamFilter returned 88 host(s) get_filtered_objects
/usr/lib/python2.6/site-packages/nova/filters.py:88
→要求したメモリを確保可能なハイパーバイザは88台ある
2015-07-XX 17:00:YY ChildCellController DEBUG
nova.scheduler.filters.disk_filter
(<hypervisor-name>) ram:46581 disk:731136 io_ops:0 instances:3
does not have 1433600 MB usable disk, it only has 731136.0 MB usable disk.
→要求したディスク容量を確保できない通知 × ハイパーバイザ88台分
…
2015-07-XX 17:00:YY ChildCellController INFO
nova.filters Filter DiskFilter returned 0 hosts
→要求したディスク容量が大きすぎたので作成できなかった、と読める
2015-07-XX 17:00:YY ChildCellController DEBUG
nova.filters Filter RamFilter returned 88 host(s) get_filtered_objects
/usr/lib/python2.6/site-packages/nova/filters.py:88
→要求したメモリを確保可能なハイパーバイザは88台ある
2015-07-XX 17:00:YY ChildCellController DEBUG
nova.scheduler.filters.disk_filter
(<hypervisor-name>) ram:46581 disk:731136 io_ops:0 instances:3
does not have 1433600 MB usable disk, it only has 731136.0 MB usable disk.
→要求したディスク容量を確保できない通知 × ハイパーバイザ88台分
…
2015-07-XX 17:00:YY ChildCellController INFO
nova.filters Filter DiskFilter returned 0 hosts
→要求したディスク容量が大きすぎたので作成できなかった、と読める
今後の方向性と課題
DEBUGログがないと内部挙動が見えない
が、DEBUGログを出力するとログ管理が大変

27. OpenStack環境の紹介
• スケーラビリティ＆拡張
– 現在：1DC, 1リージョン, 1AZ, Cell×2構成
– 今後の拡張をどうやっていくか？
– Cell
• ハイパーバイザ(HV)の管理単位を分割する機能
• HVが200台～から利用するか要検討
今後の方向性と課題
27
TopCellControllerTopCellController
ChildCellControllerChildCellController ChildCellControllerChildCellController
HVHV
HVHV
HVHV
HVHV
HVHV
HVHV
HVHV
HVHV
HVHV
HVHV
HVHV
HVHV
HVHV
HVHV
HVHV
HVHV
HVHV
HVHV
HVHV
HVHV
～200台 ～200台弊社構成

28. OpenStack環境の紹介
• スケーラビリティ＆拡張
– 複数Cell構成(Icehouse)はリソースが逼迫してくるとVM作成に失敗する
– ログを追うと、②Cell選択と③HV割当のアルゴリズムが連動していない
• TopCellには空きがあるように見えているが、実際は空きがない
今後の方向性と課題
28
TopCellControllerTopCellController
ChildCellControllerChildCellController ChildCellControllerChildCellController
HVHV
HVHV
HVHV
HVHV
HVHV
HVHV
HVHV
HVHV
HVHV
HVHV
HVHV
HVHV
HVHV
HVHV
HVHV
HVHV
HVHV
HVHV
HVHV
HVHV
①VM作成指示
空きがあるCellを選んでくれない
④空きがなかった
③空きHVを調べる⑤作成失敗通知
②どちらかのCellに処理を割り振る

29. OpenStack環境の紹介
• スケーラビリティ＆拡張
– TIPS：CLIならCellを強引に指定してVMをつくることができる
今後の方向性と課題
29
nova boot --availability_zone <az>:<hypervisor_name>
--flavor <flavor_id> --image <image_id>
--nic net-id=<net_id> <vm_name>
--hint target_cell=‘<target_cell>'
ただし、
--hint target_cell=‘<target_cell>‘
は、公式ドキュメントにも記載がない
ソースコードを読まないと気付きようがない
という話が無数にあるのがOpenstack

30. OpenStack環境の紹介
• スケーラビリティ＆拡張
– 複数DCにOpenstackを展開する場合はどうするべきか？
– インフラの要件・設計は組織や経緯によって異なる
• データセンタ間をどう接続するのか？
• リージョン？AZ？Cell？どれを使うべきか？
– 自分たちにとってベストな設計・実装の探究
– 世の中のベストプラクティスは何か？も重要
今後の方向性と課題
30

31. OpenStack環境の紹介
• 体制の強化
– 現在：CentOS＋RDOで運用中
• メーカサポートは受けていない
• サポート有りのディストリビューションも気にはなっているが…
• NTTグループ内で連携しつつ問題解決に取り組んでいる
今後の方向性と課題
31
連携