design summit報告 - ironic/cinder - hitachi.co.jp · © hitachi, ltd. 2014. all rights reserved....

© Hitachi, Ltd. 2014. All rights reserved.

日本OpenStackユーザ会 OpenStack Summit@Atlanta報告会

株式会社日立製作所横浜研究所

2014/6/13

守屋哲

Design Summit報告 - Ironic/Cinder


１. Ironic 2. Cinder

Contents

1


１. Ironic

2


１-１ Ironicとは

3

Novaの物理サーバ用ドライバを開発するプロジェクト

“Ironic is the OpenStack service which provides the capability to provision bare metal servers.”

‒ VMと同じ方法で物理サーバをデプロイ ‒ TripleOでも利用

現在 incubationプロジェクト ‒ Nova-baremetalからfork ‒ Junoでの incubation卒業が目標

Contributors

‒ HP ‒ Mirantis ‒ Red Hat ‒ Rackspace

http://www.stackalytics.com/


1-2 IronicのArchitecture

4 引用元： http://docs.openstack.org/developer/ironic/deploy/user-guide.html

• Driver • Core

• Power • Deploy

• Standard • Vendor

• IPMI • SSH

• PXE

IPMI

PXE


1-3 Ironicによる物理サーバデプロイの流れ

5

Ironic 物理サーバ

イメージの取得

TFTPの設定生成

電源ON via IPMI

PXE boot DHCP request

Deploy用kernel/ramdisk

HDDをiSCSIターゲットとして公開

パーティション作成、OSイメージ書き込み

リブート via IPMI

DHCP request

テナント用kernel/ramdisk

Cloud-Init

ユーザへ

DHCP TFTP

• Deploy用 • kernel/ramdisk

• テナント用 • kernel/ramdisk • OSイメージ


1-4 Ironic Design Summit Topics

6

Ironic python agent

Hardware multitenancy risk mitigation

Performance and scalability

Planning changes for Juno

随時100人程度参加


1-5 Ironic Python Agent

7

Ironic Python Agentとは・・・

Ironic 物理サーバ

電源ON via IPMI

PXE boot DHCP request

Deploy用kernel/ramdisk

HDDをiSCSIのターゲットとして公開

パーティション作成、OSイメージ書き込み

・・・・・・

ここに入れる

iSCSIのターゲット以外にもいろいろやりたい -> AgentがREST APIを提供し、Ironicから利用 e.g.) HDDの内容の消去、firmwareの更新等

‒ Rackspace主体で開発


1-6 Ironic Python Agent (contd.)

8

Ironic python agentの説明 ‒ Architecture

‒ Pluggable backend ‒ Hardware

‒ Provisioning

‒ Documentが欲しい

‒ REST API ‒ broken (url/command)

‒ Feature ‒ Heartbeats

‒ Hardware discovery

‒ Planed feature ‒ エージェントの無効化(if not heartbeating)

‒ サーバの削除（含、HDDの内容の削除等）

‒ PXEドライバとマージ？

‒ Pre-cache image → Nova

‒ CI ‒ 専任一人

‒ PXEドライバと同等レベルのテストを実施したい

‒ AgentのAPIを直接たたくテストをtempestに追加


1-7 Hardware Multitenancy Risk Mitigation

9

Multitenant環境でIronicサービスを提供する場合、危険がいっぱい → リスクを低減する方法を考えよう

シナリオ ‒ 誰かが使った物理サーバを別の人が利用する

‒ 同一ラック内に複数のユーザ

Firmwareの汚染(悪意あるfirmwareの検出・回避) ‒ Firmwareをflashする？ ←Firmwareは嘘をつくことが可能なので意味があるか・・・

Network isolation ‒ Untrusted HWをmgmtネットワークから切り離す

‒ Neutronと連携する必要あり

HDDの内容消去 ‒ HDDの指定方法 (UUID、WWN、コマンド等々)

‒ 安全に消去できないケース有(preserved ephemeral領域を同じ物理HDDに保存する場合？)

Node<->tenant割り当て →Nova

Quota/hardware flavor/usage tracking ‒ Quota→Novaで扱うべき

‒ Hardware flavor→extra spec

Best practice for operator ‒ Document

API access （ironic python agent) ‒ 非特権ユーザにAPIアクセスを許してOK?

‒ Authenticationは必要だけど、今は優先度低


1-8 Performance and Scalability

10

PerformanceやScalabilityについて情報共有して改善点を明確にしましょう

API performance ‒ 全てのAPI callを非同期にすべきでは？

Service scalability ‒ ゴール：100万物理ノードを管理

‒ # of 物理ノード per Conductor?? ‒ とりあえず1000とか？

‒ IPMI/TFTP/HTTP

‒ Benchmarkテストの結果がもっと必要

Parallel performance ‒ Glanceからのイメージコピーとか問題になりそう

= Novaでも同じ問題あるはず → midcycle meetup

‒ IntelligentにNetwork/Disk IOをthrottling

‒ 大量のRPCによりheartbeatが意図したとおりに動かない ‒ Workaround: RPC thread poolを64 -> 4にするとか

ブート時間 ‒ 現状のデプロイ時間：20分くらい

‒ 2 * POST cycle + イメージコピー時間

‒ POST cycleを減らす → kexec?


1-9 Planning Changing for Juno

11

Junoでやることの優先度付をするセッション

最終的には多数決を取り、PTLが整理して優先度付してMLに流すということになった

必須項目 ‒ for graduation

‒ Tempestのテストカバレッジ向上

‒ Grenade (migration path)の整備

‒ 他プロジェクトとのIntegrate推進 ‒ Nova/Ceilometer/Horizon

‒ Document

‒ RPC versioning

‒ Provisioning APIの標準化

‒ Not for graduation ‒ REST API -> fully async

‒ Ironic python agent

Optional ‒ Grouping

‒ Boot from volume

‒ iPXE

‒ UEFI boot

‒ Windows Deployment

‒ Diagnostic image for debugging


2. Cinder

12


2-1 Cinder Design Summit Topics

13

Volume Replication

DRBD For Cinder-Volumes

NFS and its role within Cinder

Adding Consistency Groups to Cinder

3'rd party certificiation and CI systems

Changed Block List for Cinder Volumes

Cinder State and Workflow Management

Framework for detailed Volume Stats reporting

Reconcile Cinder Volumes with Actual Storage (DR and B/R)

Mulitple Pools per Cinder Backend

What is a Cinder Driver

Glance/Cinder usage of Swift as backing store

随時40-50名程度参加


2-2 Volume Replication

14

Volume Replication ‒ CinderにおけるVolume replication対応について説明

‒ 目的 ‒ DR対応

‒ ボリュームのスナップショットを作成する方法をCinderで標準化

‒ リモートリプリケーションに必要なストレージの設定をcinderで自動設定する

‒ 基本方針 ‒ ユーザにはAPIを見せない ← ユーザの誤操作によるデータ破壊を防ぐため

‒ 今回提案された方式 ‒ 細かいエラーケースを考慮しないシンプルなもの

‒ ボリューム作成時に自動的にレプリカを作成 → 障害発生時にそのレプリカをactive にするというもの

‒ 問題 ‒ 現状の実装では、非同期でレプリカへのデータのコピーが走る場合、コピー中に実

行系で障害が発生すると、切り替わりが発生しデータの整合性が保てない

‒ まずは問題があっても基本機能をサポートし、その後に問題を修正する方針


2-3 DRBD For Cinder-Volumes

15

DRBD For Cinder-Volumes

‒ CinderでのDRBD対応の取り組み状況を説明

‒ DRBDはFSよりも低レイヤーで動作し、レプリケーションされたディスクをブロックデバイスとして使用可能

‒提案されたドライバは、CinderのLVMドライバとDRBDを組み合わせた利用が可能

‒ Cinderドライバは2百行程度でメンテナンスし易い


2-4 NFS and its role within Cinder

16

NFSドライバのセキュリティ ‒ 問題

‒ NFSドライバ：chowns/chmods/chgrps等をroot権限で実行

‒ →マウントオプションにsquash_rootが設定されていると動作しない

‒ →ファイルの権限を777にすると動作するが、セキュリティ上問題

‒ 解決案 ‒ rootユーザでの動作を禁止

‒ 一般ユーザをownerとし、660のパーミッションで他のユーザがR/Wできないようにする

‒ 上位クラスに関連コードが多く実装されているため、実装上の課題あり

ManilaとCinderの棲み分け ‒ 重複機能を提供

‒ CinderのNFSドライバ(FSベースのブロックドライバ)

‒ Manila

‒ 連携方法を議論 ‒ Cinder -> Manila?

‒ Manila -> Cinder?


2-5 Adding Consistency Groups to Cinder

17

Consistency Group(CG) ‒ snapshot、backup、disaster recoveryなど複数volumeに関連性がある場合、関連

するvolumeをグループ化して管理

‒ グループに関連づけられたvolumeは、一貫性をもってsnapshot等が実行される

‒ これまでHeatなどで対応してきたがユーザがVolumeの関係を手動で設定する必要があった

議論 ‒ グルーピング方法

‒ CGを作成してからそれに関連付けしてvolumeを作成

‒ 作成済みのvolumeをCGに追加

‒ CG操作のAPIやDBスキーマの実装案

スナップショット作成の流れ ‒ Cinder APIでcgsnapshot, 個々のボリュームのスナップショットエントリをDBに作成

‒ Cinder Managerがnovaclientを呼び出し、ファイルシステムを静止化

‒ Cinder ドライバがバックエンドストレージと会話し、CG内のボリュームに対してスナップショットを作成

‒ Cinder Managerがnovaclientを呼び出し、ファイルシステムをThawする


2-6 3'rd party certificiation and CI systems

18

cinderのコア部分の変更により、3rd party driverが動作しなくなる問題を検知するために、各ベンダに対してCIテストの実施を必須とする

3rd Party Driverが新規にパッチを投稿する際、各ベンダが自前のCIテスト環境を構築し、テストをパスさせることを義務づける(novaの運用方式を採用)。テスト結果が無いものは、コードのレビューを行わない

CIテスト環境を自前で構築しないケースや、テストの失敗を長期間放置するケースについては、ベンダに対してなんらかのペナルティを科すことも検討


2-7 Changed Block List for Cinder Volumes

19

CinderでSwiftにVolumeバックアップをとる場合、完全バックアップしかできない

→差分バックアップしたいというニーズあり

→スナップショット間の差分ブロックを返すAPIを実装するという提案あり

差分を取得する方法について ‒ QCOW2

‒ バッキングストアがスナップショットの差分を表す

‒ Ceph RBD ‒ 差分を取得するための機能が実装

‒ ベンダのバックエンドストレージ ‒ スナップショットの差分を得る機能があるのか？ → 課題


2-8 Cinder State and Workflow Management

20

TaskflowのCinderでの対応について進め方を議論

現状 ‒ ボリューム作成(create_volume)の仕組みはTaskflowに対

方針 ‒ ボリューム作成が問題なく動作するようになるまでは他の操作に対

するTaskflowは導入しない

Taskflow導入に対する懸念 ‒ Taskflowはタスクのストップ、リスタートをサポートしているが、

Cinderではこれらの概念は現在使われていない

‒ タスクをリカバーするための情報をCinderはvolume上に保持していない

‒ Cinderの各操作の動作状況の把握が困難なため、タスク種別毎のログ出力が必要

‒ 多数のロック機構が追加され処理が複雑になる

開発自体はコアメンバーを中心に作業がアサインされて継続的に対応していくとの事


2-9 Framework for detailed Volume Stats reporting

21

問題 ‒ クラウド環境で複数ベンダのストレージを利用する際に、それぞれの

提供する方法でストレージから情報を採取する必要あり

→ Cinderを使うことで統一的に各ストレージ、ボリュームに関連する統計情報を採取

採取対象の情報 ‒ ボリュームの識別子 (Backend name/Volume UUID)

‒ 平均Read/Write IOPS、Bandwidth(in kilobytes/sec)

‒ 平均Request Size (in bytes)

‒ Thin provisioning Poolのトータル使用量と、実ブロック割当量

→ 取得した情報はCeilometerへ

取得間隔 ‒ パラメータで設定可能（デフォルトは1回/分）

データサイズ（想定） ‒ 10,000 ボリュームで64KB

‒ 100,000 ボリュームで640KB


2-10 Reconcile Cinder Volumes with Actual Storage (DR and B/R)

22

問題 ‒障害などでCinder DBとストレージの状態の整合性が取れ

ない状態になることがある

例）ストレージにはVolumeがあるが、DBにないなどの状態

→ この場合DBのリストアなどの対処が必要

提案全Volumeの一覧表示やメタデータの追加などが調査のた

めに必要

→これらはCinderに実装済みのため、管理コマンドの追加が必要


2-11 Mulitple Pools per Cinder Backend

23

問題

‒ストレージには複数のプールを作ることができるものがあるが、現在の実装では独立したストレージのように扱われる

提案

‒複数のプールを扱えるようにする → 50GBずつ空きのあるプール2個を束ねて100GBの

Volumeを作ることができるようになる

– 異なる機能セットをもつプールを作成可能 → CinderがVolumeの要求に応じて適切な機能セットをもつ

プールを選択するなどの機能が必要


2-12 What is a Cinder Driver

24

cinderプロジェクトを運営する上で、コアメンバが抱える懸念を共有

EMCがViPR(*)をリリースしたことで、多くのベンダのストレージがViperの配下に入り、cinderと機能的に被る可能性あり → 一般的なclosedの製品 vs OSSの問題であり、プロジェクトの運営とは無関係なのでここでは議論

対象外

今後、ミドルウェア相当の機能が提案された場合

→拒否するべき

cinder driverとミドルの違いをきちんと定義(APIの定義)しておく

コアメンバが現状5名だが、今後人員不足でレビューが滞る懸念あり

コアメンバになることのメリットをわかりやすく説明するトレーニングの提案などをfoundationに対してしていくべき

ベンダのプラグインドライバが、cinderのコア部分を介さずに独自実装を入れ込んでくる可能性がある

→このようなケースは断固として拒否し、 cinderのコア部分を介すように即していく

(*) EMCのSoftware Defind Storage製品 http://japan.emc.com/cloud/vipr/index.htm


3. まとめ

25


まとめ

26

Ironic ‒ Topic

‒ Ironic python agent

‒ Scalability

‒ Multitenant

‒ Junoではincubationからの卒業が一番の目標

Cinder ‒ Topic （運用時に必要となる機能多数)

‒ボリュームのレプリケーション

‒ボリュームインポート・エクスポート

‒ボリュームデータの保護機能

‒ ドライバの品質維持

‒障害時のロールバック

‒ 品質面と障害時のロールバック、ボリュームのインポート・エクスポートあたりが揃うとようやく実用レベル


Trademarks

27

OpenStack is a trademark of OpenStack

Foundation in the United States, other

countries, or both.

Other company, product, or service names

may be trademarks or service marks of

others.


株式会社日立製作所横浜研究所

Design Summit報告 - Ironic/Cinder

2014/6/19

守屋哲

END

28

design summit報告 - ironic/cinder - hitachi.co.jp · © hitachi, ltd. 2014. all rights reserved....

Documents