Contents 1. Ironic 2. Cinder 1

Transcription

1 日本 OpenStack ユーザ会 OpenStack 報告会 Design Summit 報告 - Ironic/Cinder 2014/6/13 株式会社日立製作所横浜研究所 守屋哲

2 Contents 1. Ironic 2. Cinder 1

3 1. Ironic 2

4 1-1 Ironic とは 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 3

5 1-2 Ironic の Architecture Driver Core Power Deploy Standard Vendor IPMI SSH PXE IPMI PXE 引用元 : 4

6 1-3 Ironic による物理サーバデプロイの流れ Ironic DHCP TFTP 物理サーバ イメージの取得 TFTP の設定生成 Deploy 用 kernel/ramdisk テナント用 kernel/ramdisk OS イメージ 電源 ON via IPMI DHCP request Deploy 用 kernel/ramdisk HDDをiSCSIターゲットとして公開 PXE boot パーティション作成 OS イメージ書き込み リブート via IPMI DHCP request テナント用 kernel/ramdisk Cloud-Init ユーザへ 5

7 1-4 Ironic Design Summit Topics Ironic python agent Hardware multitenancy risk mitigation Performance and scalability Planning changes for Juno 随時 100 人程度参加 6

8 1-5 Ironic Python Agent Ironic Python Agent とは Ironic 物理サーバ 電源 ON via IPMI DHCP request Deploy 用 kernel/ramdisk HDDをiSCSIのターゲットとして公開パーティション作成 OSイメージ書き込み PXE boot ここに入れる iscsi のターゲット以外にもいろいろやりたい -> Agent が REST API を提供し Ironic から利用 e.g.) HDD の内容の消去 firmware の更新等 Rackspace 主体で開発 7

9 1-6 Ironic Python Agent (contd.) 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 に追加 8

10 1-7 Hardware Multitenancy Risk Mitigation 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 は必要だけど 今は優先度低 9

11 1-8 Performance and Scalability 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? 10

12 1-9 Planning Changing for Juno 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 11

13 2. Cinder 12

14 2-1 Cinder Design Summit Topics 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 随時 名程度参加 13

15 2-2 Volume Replication Volume Replication Cinder における Volume replication 対応について説明 目的 DR 対応 ボリュームのスナップショットを作成する方法を Cinder で標準化 リモートリプリケーションに必要なストレージの設定を cinder で自動設定する 基本方針 ユーザには API を見せない ユーザの誤操作によるデータ破壊を防ぐため 今回提案された方式 細かいエラーケースを考慮しないシンプルなもの ボリューム作成時に自動的にレプリカを作成 障害発生時にそのレプリカを active にするというもの 問題 現状の実装では 非同期でレプリカへのデータのコピーが走る場合 コピー中に実行系で障害が発生すると 切り替わりが発生しデータの整合性が保てない まずは問題があっても基本機能をサポートし その後に問題を修正する方針 14

16 2-3 DRBD For Cinder-Volumes DRBD For Cinder-Volumes Cinder での DRBD 対応の取り組み状況を説明 DRBD は FS よりも低レイヤーで動作し レプリケーションされたディスクをブロックデバイスとして使用可能 提案されたドライバは Cinder の LVM ドライバと DRBD を組み合わせた利用が可能 Cinder ドライバは 2 百行程度でメンテナンスし易い 15

17 2-4 NFS and its role within Cinder NFS ドライバのセキュリティ 問題 NFS ドライバ :chowns/chmods/chgrps 等を root 権限で実行 マウントオプションに squash_root が設定されていると動作しない ファイルの権限を 777 にすると動作するが セキュリティ上問題 解決案 root ユーザでの動作を禁止 一般ユーザを owner とし 660 のパーミッションで他のユーザが R/W できないようにする 上位クラスに関連コードが多く実装されているため 実装上の課題あり Manila と Cinder の棲み分け 重複機能を提供 Cinder の NFS ドライバ (FS ベースのブロックドライバ ) Manila 連携方法を議論 Cinder -> Manila? Manila -> Cinder? 16

18 2-5 Adding Consistency Groups to Cinder 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 する 17

19 2-6 3'rd party certificiation and CI systems cinder のコア部分の変更により 3rd party driver が動作しなくなる問題を検知するために 各ベンダに対して CI テストの実施を必須とする 3rd Party Driver が新規にパッチを投稿する際 各ベンダが自前の CI テスト環境を構築し テストをパスさせることを義務づける (nova の運用方式を採用 ) テスト結果が無いものは コードのレビューを行わない CI テスト環境を自前で構築しないケースや テストの失敗を長期間放置するケースについては ベンダに対してなんらかのペナルティを科すことも検討 18

20 2-7 Changed Block List for Cinder Volumes Cinder で Swift に Volume バックアップをとる場合 完全バックアップしかできない 差分バックアップしたいというニーズあり スナップショット間の差分ブロックを返す API を実装するという提案あり 差分を取得する方法について QCOW2 バッキングストアがスナップショットの差分を表す Ceph RBD 差分を取得するための機能が実装 ベンダのバックエンドストレージ スナップショットの差分を得る機能があるのか? 課題 19

21 2-8 Cinder State and Workflow Management Taskflow の Cinder での対応について進め方を議論 現状 ボリューム作成 (create_volume) の仕組みは Taskflow に対 方針 ボリューム作成が問題なく動作するようになるまでは他の操作に対する Taskflow は導入しない Taskflow 導入に対する懸念 Taskflow はタスクのストップ リスタートをサポートしているが Cinder ではこれらの概念は現在使われていない タスクをリカバーするための情報を Cinder は volume 上に保持していない Cinder の各操作の動作状況の把握が困難なため タスク種別毎のログ出力が必要 多数のロック機構が追加され処理が複雑になる 開発自体はコアメンバーを中心に作業がアサインされて継続的に対応していくとの事 20

22 2-9 Framework for detailed Volume Stats reporting 問題 クラウド環境で複数ベンダのストレージを利用する際に それぞれの提供する方法でストレージから情報を採取する必要あり 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 21

23 2-10 Reconcile Cinder Volumes with Actual Storage (DR and B/R) 問題 障害などで Cinder DB とストレージの状態の整合性が取れない状態になることがある例 ) ストレージには Volume があるが DB にないなどの状態 この場合 DB のリストアなどの対処が必要 提案 全 Volume の一覧表示やメタデータの追加などが調査のために必要 これらは Cinder に実装済みのため 管理コマンドの追加が必要 22

24 2-11 Mulitple Pools per Cinder Backend 問題 ストレージには複数のプールを作ることができるものがあるが 現在の実装では独立したストレージのように扱われる 提案 複数のプールを扱えるようにする 50GB ずつ空きのあるプール 2 個を束ねて 100GB の Volume を作ることができるようになる 異なる機能セットをもつプールを作成可能 Cinder が Volume の要求に応じて適切な機能セットをもつプールを選択するなどの機能が必要 23

25 2-12 What is a Cinder Driver cinder プロジェクトを運営する上で コアメンバが抱える懸念を共有 EMC が ViPR(*) をリリースしたことで 多くのベンダのストレージが Viper の配下に入り cinder と機能的に被る可能性あり 一般的な closed の製品 vs OSS の問題であり プロジェクトの運営とは無関係なのでここでは議論対象外 今後 ミドルウェア相当の機能が提案された場合 拒否するべき cinder driver とミドルの違いをきちんと定義 (API の定義 ) しておく コアメンバが現状 5 名だが 今後人員不足でレビューが滞る懸念あり コアメンバになることのメリットをわかりやすく説明するトレーニングの提案などを foundation に対してしていくべき ベンダのプラグインドライバが cinderのコア部分を介さずに独自実装を入れ込んでくる可能性がある このようなケースは断固として拒否し cinderのコア部分を介すように即していく (*) EMC の Software Defind Storage 製品 24

26 3. まとめ 25

27 まとめ Ironic Topic Ironic python agent Scalability Multitenant Juno では incubation からの卒業が一番の目標 Cinder Topic ( 運用時に必要となる機能多数 ) ボリュームのレプリケーション ボリュームインポート エクスポート ボリュームデータの保護機能 ドライバの品質維持 障害時のロールバック 品質面と障害時のロールバック ボリュームのインポート エクスポートあたりが揃うとようやく実用レベル 26

28 Trademarks 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. 27

29 END Design Summit 報告 - Ironic/Cinder 2014/6/19 株式会社日立製作所横浜研究所 守屋哲 28