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 -

RefstackOpenStack

コミュニティ

テストツール

テスト結果

データベース


• 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

Software