OpenStack Vancouver Summit Report presented at nttgroup meeting in Japanese

Copyright©2015 NTT corp. All Rights Reserved.
NTTグループ合同報告会
OpenStack Vancouver Summit
- OpenStackコンポーネント全体について -
2015年6月10日
市川俊一
第三推進プロジェクト
NTT ソフトウェアイノベーションセンタ
Copyright(c)2015 NTT Corp. All Rights Reserved.

2Copyright©2015 NTT corp. All Rights Reserved.
• 全体動向
• プロジェクトのガバナンスの変更
• エコシステムを維持するための取り組み（DefCore）
• 主要なプロジェクトの動向
• Nova
• Glance
• Neutron
• Cinder
• Keystone & Horizon
• 新しいプロジェクトから
• Congress
• デプロイツールから
• OpenStack Ansible Deployment
発表内容

• プロジェクトの定義の変更
• Workgroupsから（公式な）プロジェクト化の要件
• Technical Committee (TC)が次の基準で審査・承認
• OpenStackに貢献するための明確に定義された目的を持つ
• オープンなSource, Community, Development, Designに沿う
• 相互接続性を保証、すなわちkeystoneに対応
• 1分野に1つという制約はない
• Deploymentツールとして、TripleOだけではなく、
PuppetOpenStackとChefOpenstackプロジェクトが発足。
プロジェクトのガバナンス 1/2 - The Big Tent -
多くのプロジェクトが作られていき、
提供される選択肢・機能が増える

• IncubatorとIntegratedのプロジェクト区分の廃止
• これまで（Workgroup→Incubator→Integrated）は、
半年サイクルのIntegratedリリースに加わるために、
TCの審査をクリアしなければならなかった。
• 基準：Scope, Maturity, Process, QA, Documentation, User
support, Release management, Security, API, Upgrade
• これからは半年サイクルのCoordinatedリリースに加わるか、
各プロジェクトが決める（Workgroup→Project）。
• Release Cycle Managementプロジェクトはそのまま
• Stableブランチのポイントリリースを廃止しようという議論が別にある
• 各プロジェクトが任意のタイミングで自由にリリースしてもよい
• tc-approved-release プロジェクトはTCが選定する、
Foundationが定める商標利用の候補となるプロジェクトを示す
• 初期は、tag-integrated-releaseタグの対象と等しい
プロジェクトのガバナンス 2/2 - The Big Tent -
多くのプロジェクトが早期にリリースに加われる

• Integrated Releaseに
含まれたプロジェクト
• Kiloで12個のプロジェクト
これまでのIntegrated Releaseの流れ
Austin Bexar Essex Folsom Havana Icehouse Juno Kilo
Nova Nova Nova Nova Nova Nova Nova Nova
Glance
Keystone
Horizon
Neutron
Ceilometer
Heat
Cinder
Trove
Sahara
Ironic
Swift
Glance
Keystone
Horizon
Neutron
Ceilometer
Heat
Cinder
Trove
Sahara
Swift
Glance
Keystone
Horizon
Neutron
Ceilometer
Heat
Cinder
Trove
Swift
Glance
Keystone
Horizon
Neutron
Ceilometer
Heat
Cinder
Swift
Glance
Keystone
Horizon
Neutron
Cinder
Swift
Glance
Keystone
Horizon
Swift
Glance
SwiftSwift
and C,D and G

• プロジェクトとリリースカテゴリのタグ
（2015年6月4日調べ）
Libertyリリースに向けた各プロジェクトの動き
Barbican
Ceilometer
Cinder
Designate
Glance
Heat
Horizon
Ironic
Keystone
Magnetodb
Manila
Murano
Neutron
Nova
Sahara
Swift
Trove
Zaqar
Ceilometer
Cinder
Glance
Heat
Horizon
Ironic
Keystone
Neutron
Nova
Sahara
Swift
Trove
integrated-release
release:at-6mo-cycle-end
Magnum
Swift
release:independent
ツール・クライアント・ライブラリのプロジェクト・レポジトリは省略。
また、下線はintegrated-releaseに含まれていないもの（9個）。
参考：http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
Congress
Mistral
release未宣言

• release:at-6mo-cycle-end
• Barbican・・・鍵管理のサービス
• Designate・・・DNSのサービス
• Magnetodb・・・key-valueストアのサービス
• Manila・・・共有ファイルシステムのサービス
• Murano・・・アプリケーションカタログのサービス
• Zaqar・・・メッセージングのサービス
• release:independent
• Magnum・・・アプリケーションコンテナのサービス
• release未宣言
• Congress・・・ガバナンスのサービス
• Mistral ・・・ワークフローのサービス
新しいプロジェクト

• DefCore Committee
• OpenStackのInter-operabilityを確保するための機関
• OpenStackの”Core”を定義する、最小限の必須要素を定義
• TrademarkとMarketPlace
• OpenStackの商標・ロゴを使う、もしくは、OpenStackのMarketplace
サイトに掲載される、ためにはDefCoreの基準を満たすことが必須。
• サミットでは、既に16社が認定を受けた、と発表された。
• 基準
• （今日の）DefCoreの試験(DefCore Capability)は、
Tempestプロジェクトの開発用API試験のサブセットで定義されている
• DefCoreの試験のバージョンは、リリースサイクルとは独立。
バージョンは日付（YYYY.MM）の形式。
• 最新の2バージョンのどれかでパスできれば合格と認定される。
• 2015年6月4日時点で、”2015.05”と”2015.04”がある。
エコシステムの維持 - DefCore -
OpenStackのエコシステムの基準定義であり、
製品・サービス提供者とアプリ開発者の双方に重要

• 疑問
• ユーザはどうやって検査すればよいか？
• DefCoreはどうやって基準の内容を定義していくか？
• Refstack (refstack.net)が準備された
• テストを実行するためのツールセットが配布されている
• 試験ツールTempestの専門知識がなくても実施可能
• 特定の試験ツールに依存しないプロセス
• テストの実行結果をコミュニティから集めるデータベース
• 実績を参考に”common”な対象試験が選ばれていく予定
RefStack - DefCore -
Refstack
OpenStack
コミュニティ
テストツール
テスト結果
データベース

• DefCore バージョン2015.05に含まれる試験内容
• Nova, Glance, Keystone, Swiftの一部のAPIのみ
• 実行時間：DefCoreは10分 vs Tempestフルセットは2時間
DefCore Capability version 2015.05
1. compute-auth: Auth related tests using Compute API
2. compute-images: Image operations within the Compute API
3. compute-flavors: Flavor operations in the Compute API
4. images-v2: CRUD image operations in Images API v2
5. compute-volume: Retrieve volume information through the Compute API
6. identity-auth: Auth operations within the Identity API
7. compute-servers: Basic server operations in the Compute API
8. objectstore-object: Basic object operations in Object Storage API
9. compute-keypairs: Generate, import, and delete SSH keys within Compute services
10. compute-quotas: Quotas management in Compute API
11. compute-instance-actions: Basic support Compute API
for server actions such as reboot, rebuild, resize
DefCore Capabilities, Version “2015.05”
まだ初期段階でテストの対象は限定的

• These results are from voluntary surveys answered online
between March 9, 2015 - April 16, 2015. (n=270)
最近の利用状況の調査結果
http://superuser.openstack.org/articles/openstack-users-share-how-their-deployments-stack-up

Nova

• スケジューラ
• allocation ratio（オーバーコミット）がschedulerからresource trackerへ
• アップグレードを改善するためにVersioned Object対応にする
• request-spec（VMに指定される起動パラメータ）
• resource tracker（nova-computeの状態を定期的に管理する仕組み）とresource
• Shared-state scheduler
• 複数プロセス間でのconsistentでscalableな共有のためにOmegaを入れる
• ライブマイグレーションにおけるブート時のスケジューリングの適用
• スケジューラの外出しをする前に、スケジューラ外部APIを整備する
• セルとAvailability Zoneの関係は、Availability Zoneが複数セルを含むという
対応付けが提案されたが、結論は出なかった
• セルv2
• 単独セルでのデプロイメントを実現する
• 可能であれば複数セルのデプロイメントの実現も
• ライブアップグレード
• オンラインスキーマチェンジの実装を引き続き行うこととなった
Nova 1/2

• Nova API v2.1（元v3.0）
• python-novaclientの対応など
• Libertyからはv2.1をデフォルトにする
• Kiloで導入されたNova API v2.1は、
• 一貫性のある入力値の検証機能が導入された
• Nova API v2.0で動いたアプリケーションはそのままv2.1で動く
• Micro Versioningをサポートする
• HTTPのContent Negotiation（TextやHtml等表現を変える）のような仕組み
• HTTPヘッダでクライアントが対応しているバージョンを渡し、サーバ側が対応を変える仕組み
• つまり、今後APIエンドポイントはバージョンが上がっても変わらない
• ExtensionsはすべてNova APIになった。Extensionの仕組みは”deprecated”となった。必要
なものはCoreとして追加して、一つのCore APIを維持すべきという考えに基づく。
• Task APIの作業を再開する
• Quota
• 階層的なクォータの実装を引き続き進める
• Functional Testing
• 複数Compute Nodeへのスケジューリング、クォータなど
• nova-networkからneutronへのマイグレーションは引き続き取り組む
Nova 2/2

Glance

• KiloではTask API(v2)に”Import”タスクが実装された。
• エンドユーザがImageをアップロードする機能。
• Glance v1の”copy-from”と”location”との違いは、
対象が正しいImageであるという前提がなくても良い点。
• システム側を守る考慮がされている。最終段階までImageは登録されない等。
• Libertyに向けて
• イメージをリージョン間でコピーする機能、Intercloudでのコピー
• Experimental v3 APIの中で、Artifacts（イメージだけでなくHeatテン
プレートなどのオブジェクトも含めた一般化されたデータアセット）を管
理する機能の実装を進める。ImagesもArtifactsの一つになる。
• Image (v1/v2) 関連のAPIの安定化
• Catalog Index Service (Experimental API)
• Kiloで新たに追加されたSearchのためのAPI (experimental)
• Glanceプロジェクトの外に出て、SearchLightプロジェクト(OpenStack
Indexing and Search)として独立することになった。
• Glanceだけではなく全てのOpenStackサービスのAPIを対象に検索の機能と性
能を改善することを目標としている
• ElasticSearchをベースとして作り直される予定
• NovaはまだGlance v1 APIに依存している。
• Kiloサイクルで取り組まれたが完成せず。
• Libertyサイクルでv2 APIへの移行に継続して取り組むことが確認された
。
Glance

Neutron

• Neutronの開発チーム運営方法が変更になる
• Neutronのレビュー活動をチーム分けし、各チームリーダーが副
PTLとしてマネジメントする
• チームの分野
• API and DB
• Built-In Control Plane（L2 agents, DHCP agents, SGs,
metadata agents and the portion of ML2）
• Client
• Docs
• L3（L3 agent, DVR, and IPAM）
• Services（FWaaS, LBaaS, and VPNaaS）
• Testing
• 新機能提案のプロセスが変更になる
－Request For Enhancement (RFE) の導入－
• 新しい機能の要望をLaunchpadにRFE bugとして上げる
• Specのテンプレートが簡素化され、HowではなくWhatに焦点
• RFE bugやSpecに特別な締め切りを設けない
Neutron 1/4

• Kiloで導入された機能
• L3
• IPv6 support （L3-HAも）
• Distributed Virtual RouterのVLAN対応
• SubnetPools
• ML2
• Hierarchial Port-binding
• Portsecurity for OVS （Security Groupを無効にもできる）
• API extensions（MTU、VLAN transparency）
• Services
• LBaaS v2、reference実装はHAProxy
• 構成設計のリファクタ
• TLS termination（TLS証明書はBarbicanに格納）
• ドライバ：haproxy, Octavia, A10, Brocade, Citrix, KEMP
• VPNaaS、reference実装はopenswan
• FWaaSはExperimentalの位置づけ
Neutron 2/4

• Liberty向けに注力する新機能
• Service Function Chaining
• VLAN aware VM
• QoS
• IPAM
• BGP
• Security Groups （OVSでのパフォーマンス改善）
• L3-HAのLibertyに向けた取り組み
• 通常のrouterをHAのrouterにアップグレードする
• Master HA routerを手動でAgentにスケジュールする機能
• L2 PopulationとHA routerの共存
• DVR SNATでのHAサポート
• Stateful SNATのConntrack support
• nova-network
• OVS DVRは代替とならないという意見が根強く残っており、
linuxbridgeとOVSの2つをメンテナンスしていく
Neutron 3/4

• LBaaS の今後
• L7 Content Switching
• Pool Sharing (例えば、HTTPとHTTPSのlistenerがpool共有)
• LBaaS v2 API in Horizon
など
• Octavia
• OpenStackのWorkgroup
• Operator-grade open source scalable load balancer
• Octavia をLBaaSのデフォルトのリファレンス実装にしていく
• Octavia v0.5
• Service VMs （HAProxyが動いている）(Amphoraと呼ばれる）
• Spare pool failures
• Octavia v1.0 – Liberty?
• Active/Passive構成
• Control planeの高可用化
• Octavia v2.0
• Active/Active構成
• 水平方向のスケール
Neutron 4/4

Cinder

Cinder 1/2
• Kiloでは
• Incremental backupがサポートされた。また、(これまでの
Swiftに加え)NFSがbackupの格納先としてサポートされた。
• Encrypted volumeのbackupとrestoreもサポートされた。
• Consistency groupの導入。Groupに属する複数のvolumeの
snapshotを同時に取る。単一のbackendドライバのみ動作。
• Replicated volume v1の導入。Volumeのレプリケーション
やフェイルオーバ操作ができる。volumev1は限られた単一の
backendドライバのみ。
• 1つのbackendドライバが複数のstorage resource poolをス
ケジューラに対して示すことができるようになった。
• 1つのストレージアレイを複数のプールに分割できる
• Rolling upgrade対応、データを抽象化するためのオブジェク
トの概念を導入した。
• Private volume typeが作れるようになった。アクセスできる
テナントを指定できる

• Libertyに向けて
• Replicated volume v2
• Volumeがアタッチされた状態での
VMのlive-migrationの品質改善
• Cinder-volume Active-active構成の実現
• 現状、API呼び出し間の排他制御がまだ実現されていない。
• 排他制御の実装案・ロックの粒度について議論があった
• 既にactive/activeのGaleraクラスタをバックエンド（＝ノード間でoptimistic
な排他制御の並列処理を行う）に置いた場合に問題ないか、等も議論
• Multi-master構成で性能がどれだけ低下するかベンチマークの検証もされてい
て、問題ないという報告があった
• Nova側のattach/detach処理は、Cinderが想定している呼び出し
方になっておらず、問題がある。調整が必要。という課題も共有さ
れていた。
Cinder 2/2

Keystone & Horizon

• Kiloリリースで対応された機能
• Keystone
• Identity SourceにIdentity Providerが加わった
• Authentication PluginsにFederated Identityが加わった
• つまり、
• SAML、OpenID connectに対応
• KeystoneはService Providerとして動作
• フロントにApache httpdのmod_shib(SAML),
mod_auth_openidc(OpenID)を動作させプロトコルを処理
• Horizon
• Web Single Sign Onが可能になった。（SSOオプション）
• Keystone、Django_openstack_authと連携して、
SAML、OpenID Connect、Kerberosに対応
• Libertyに向けての課題
• Keystoneclientが十分についてきていない。OpenID未対応。
Keystone & Horizon

Congress

Congress とは
Nova Neutron IDS ・・・
Congress
ポリシー
API
ポリシーに違反していないか、
各資源の状態を監視
- 違反していた場合に、
違反しない状態へ戻すための
API を実行
システムのあるべき状態をポリシーとして記述
ポリシー例
- インターネットに接続している VM は
80 ポートで通信できてはいけない
- 同じユーザの VM は異なる HV の上で
動作していること
Congress = ポリシー制御機能

• 基本機能の実装が Kilo で完了
• ポリシーの投入、制御対象のモニタリング、ポリシー違反時の
API 実行、別プロジェクトからのポリシー違反問い合わせ機能
• congress 自体の HA、スケールといった非機能要件に
はまだ取り組まれていない（単一プロセス構成）
• 運用の省力化なら良いが、サービスの構成要素としてはまだ不
適切で成熟するまでは時間がかかりそう
• 適用事例（VMwareにおける）
• capex 削減: HV のメモリ利用量が閾値以下になると、VM を
マイグレしてその他の HV へ移動させるポリシーを利用
• まだまだ少人数のプロジェクト
• コミット数は VMware が 8 割 (Kilo)
• PTL 及びコアデブ全て VMware
• work session の参加企業: VMware, NTT, HP, Cisco
Congress

OpenStack
Ansible Deployment

• OpenStack Ansible Deployment Workgroup
• OpenStackをセットアップするためのAnsibleのPlaybook
• パッケージではなくgitのOpenStackコードを利用
• OpenStackコンポーネント・サービスの分離にLXCを利用
• Kiloがコミュニティ版の最初のリリース
• 参考：https://github.com/stackforge/os-ansible-deployment
• JunoとIcehouseはRackspace方式依存のものがある
• Summitでの動き
• Ansible inc.が初日にPress Releaseをしていた。
• パートナとして、Cisco, CSC, HP, Rackspaceの名前がある。
• 参考：https://www.openstack.org/news/view/61/ansible-announces-the-
simple-openstack-initiative
• いくつかのセッション（RedHat, Rackspace等）で処理内容を示
すスクリプトとしてAnsibleのPlaybookが使われていた。
• Design SummitのAnsible Work Sessionは小さい部屋（30名）
だったが、50名位は集まっていた。司会は多さに驚いていた。
OpenStack Ansible Deployment

まとめ
Integrated Release
(6ヶ月毎)
Coordinated Release(6ヶ月毎)
+ Individual Release
tc-approved-release認定
DefCore

OpenStack Vancouver Summit Report presented at nttgroup meeting in Japanese

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (10)

Semelhante a OpenStack Vancouver Summit Report presented at nttgroup meeting in Japanese

Semelhante a OpenStack Vancouver Summit Report presented at nttgroup meeting in Japanese (20)

OpenStack Vancouver Summit Report presented at nttgroup meeting in Japanese