OpenStack再入門「ストレージ編」

日本OpenStackユーザ会 第49回勉強会 発表資料です。

https://openstack-jp.connpass.com/event/325758/

Transcript

1. OpenStack再入門 ストレージ編 2024/08/02 日本OpenStackユーザ会 第49回勉強会 1
2. 自己紹介 梶波 崇 (Takashi KAJINAMI) kajinamit kajinamit irc: tkajinam@OFTC Distinguished Cloud Engineer @ NTTデータグループ • クラウド基盤に関連した技術の研究開発を担当 • 現在のテーマはConfidential Computing OpenStackを中心にOSSコミュニティにて活動 • Heat(Orchestrationサービス) PTL • Oslo(共通ライブラリ) Release Liaison • Puppet OpenStack(OpenStack構築用のPuppetマニフェスト) PTL • Storlets(オブジェクトストレージ内でのアプリ実行エンジン) PTL PTL = Project Team Lead 2
3. Agenda • ストレージの基本 • OpenStackのストレージ機能 • より高度なストレージ機能 3
4. ストレージの基本 4
5. ストレージの種類 • OpenStackが提供するストレージには主に3つの種類がある • ストレージごとに特徴が違い、アプリケーション等の要件に応じて選択する • VMの動作にはまずブロックストレージが必須。ファイルシステムストレージ・オブジェクトストレージは必要に応じて採用する 5 種類 管理単位 プロトコル 共有 レイテンシ 容量 ブロックストレージ ブロック*1 SCSI, NVMe 不可 1VMからのみアクセス 小 プロトコルオーバーヘッド小 小 数十GB～数TB ファイルシステム ストレージ ファイル NFS, CIFS等 可 複数VMからアクセス 中 プロトコルオーバーヘッド中 中 数百GB～数十TB オブジェクト ストレージ オブジェクト*2 REST API 可 複数VMからアクセス 大 プロトコルオーバーヘッド大 大 数百TB～ *1: 固定長のデータ領域 *2: ファイルに類似。データと合わせて属性情報(メタデータ)を管理する 今日の主な トピック
6. ブロックストレージの種類 • VMから利用できるブロックストレージには2種類がある • ライフサイクルや特徴に差があるため、要件に応じて使い分けるべき • VMとは別のライクサイクルで管理できる永続ストレージがより一般的に利用されている 6 種類 ライフサイクル 保存先 レイテンシ 機能性 エフェメラルストレージ VMと同じ VMを削除すると消える サーバ内 小 サーバ内のデバイスアクセス 低 ソフトウェアでの作りこみが必要 永続ストレージ VMとは異なる VMを削除しても消えない 外部ストレージ 大 外部通信が必要 高 ストレージ機器の機能を活用
7. VMイメージ • クラウド上の仮想サーバはVMイメージを使ってインストールする • 実体はOSが入った起動ディスクのディスクイメージデータ • 近年は各Distributorが標準のイメージデータを提供している*1 • フォーマットが複数存在するが、OpenStackではrawおよびqcow2が一般的に利用される • VMの作成時には、イメージデータを仮想ディスク上に展開する • VMの初回起動時にエージェントプログラム(cloud-init*2)を実行し、 VMのスペック 等に合わせた調整・設定を行う • パーティション・ファイルシステムの拡張 • ホスト名やSSH公開鍵のインストール • スクリプトの実行 7 *1 https://docs.openstack.org/image-guide/obtain-images.html *2 https://github.com/canonical/cloud-init
8. OpenStackのストレージ 8
9. ストレージ関連コンポーネント 9 ブロックストレージ ファイルシステム ストレージ イメージストレージ オブジェクトストレージ • ストレージの種類に応じてストレージを管理するコンポーネントが存在 • 例外として、エフェメラルストレージ機能はNovaの組み込み機能として提供される • ストレージ要件に基づいて採用するコンポーネントを決定する エフェメラルストレージ
10. glance:イメージストレージ • VMイメージを管理するコンポーネント • raw, qcow2, vmdkなど複数のイメージフォーマットに対応 • VMやボリュームを作成する際は、Nova・Cinderがイメージを取得しストレージに書 き込む • イメージには property と visibility が定義可能 • 一部のpropertyはVM起動時のオプション*1として認識される • 例. hw_vif_multiqueue_enabled • visibilityにより公開(public)や非公開(private)等を制御 • イメージの保管用のドライバ実装を複数提供 • swift, file, ceph, cinder, s3, gcs • VMイメージは管理者だけではなくユーザも登録可能 • Policyを変更することで登録を管理者に制限することも可能 • イメージはVMやボリュームから作成することもできる 10 *1 参考: https://docs.openstack.org/glance/latest/admin/useful-image-properties.html#image-property-keys-and-values VM ストレージ ハイパーバイザ ボリューム エフェメラルストレージ ダウンロード 書込 書込 イメージデータ glance-api メタデータ swift driver
11. cinder: ブロックストレージ • 外部ストレージに格納されたストレージデータ(ボリューム)を管理するコ ンポーネント • ボリュームのスナップショットやバックアップも取得可能 • ボリュームの実態はストレージ機器内で作成されたLUN*1 • デフォルトは空領域だが、作成時にイメージやスナップショット等のデータを展開する ことも可能 • ボリュームのオプションやバックエンドを指定するボリュームタイプやQoSの設定が可能 • 多数のドライバ*2を提供し、ストレージ機器やSDSと連携 • 複数のストレージを同時に使うこともできる • ストレージとの接続プロトコルも複数対応 • iSCSI, Fiber Channel, NVME-oF等 • ボリュームはVMに対してアタッチして使う • 起動ボリュームあるいは追加ボリュームとして利用 11 *1 NFSドライバではボリュームに相当するイメージファイルを作成する *2 参考: https://docs.openstack.org/cinder/latest/configuration/block-storage/volume-drivers.html スナップショット ボリューム cinder-api ユーザ cinder-volume cinder-scheduler コントローラ D社ストレージ N社ストレージ
12. イメージからのボリューム作成 • イメージをソースとしたボリュームの作成時には、CinderがGlanceからイ メージをダウンロードし、ボリュームに対して書き込みを実行する • cinder-volumeが稼働するノードがLUNに接続し、書き込みを行う • イメージサイズが大きい場合やボリューム作成の多重度が多い場合、書 込み処理が高負荷を引き起こす場合がある • イメージのDLや焼きこみのネットワーク帯域消費 • 一時領域に保存したイメージデータの書き込み・読み込み • ストレージ内の複製(or CoW)機能を活用してイメージのダウンロードを 省略し、ボリューム作成処理を軽量化することができる*1 1. イメージキャッシュボリューム 2. Glanceのcinderバックエンド 3. 単一Cephクラスタの共通利用 12 ストレージ ボリューム 接続・書込 cinder-api cinder-volume コントローラ tmp領域 ストレージ ボリューム cinder-api cinder-volume コントローラ ボリューム イメージデータを ボリュームに保存 イメージデータを ネットワーク越しに DLし書込み Glanceからはメタ データだけ取得 ストレージ内で ボリュームを複製 1) swiftバックエンド利用時 2) cinderバックエンド利用時 *1 ストレージ内複製はrawフォーマットのみ対応
13. VMへのボリュームのアタッチ • VMはストレージには直接接続せず、ハイパーバイザを介してボリューム にアクセスする • ストレージとの接続プロトコルはVMからは隠蔽される • NovaとCinderが連携してVMへのアタッチを行う ① NovaがCinderにアタッチメントを要求 ② Cinderがストレージ機器にてVMが稼働するコンピュートノードからLUNへのアクセ ス許可を設定し、接続情報を返却 • 原則、ボリュームのLUNはボリュームが接続されているVMが割り当てられたコンピュートノー ドからしか認識できない ③ Novaが、Cinderから返却された接続情報(ターゲット・LUN ID等)を用いてハイ パーバイザとストレージとの接続を確立し、LUNを検出 • 必要に応じてマルチパスデバイスの作成も行う • 処理はiscsidやmultipathdなどのデーモンに移譲する場合もある ④ Novaが、ハイパーバイザに接続されたLUNをVMに接続する 13 VM コンピュートノード タ ー ゲ ッ ト cinder-api cinder-volume コントローラ nova-compute ①アタッチメント作成を要求 ②アクセス許可を設定 iscsid multipathd ③ストレージ接続・LUN検出 ④VMにLUNを接続 ストレージ LUN libvirtd
14. コンピュート エフェメラルストレージ • Novaによって管理されるブロックストレージ • VMのスペック(Flavor)の一部として定義され、VMの作成・削除と同時 に作成・削除される • ストレージのデータの保存や複製はイメージ作成によって行う • データはVMが動作するコンピュートノード上に作成されたイメージファイル に保存される • イメージファイルはデフォルトで /var/lib/nova/instances 配下に保存される • イメージファイルは、raw形式のディスクイメージをベースとしたqcow2形式の差分イメー ジとして作成される。イメージ形式はオプションによる変更可能。 • ブートディスクに加えて、swap用やその他の用途のためのストレージを追 加で接続することが可能 • EvacuateやRebuild等、特定の処理においてはデータが初期化される • Evacuate時のデータ初期化を防ぐ方法として、NFSやCephの利用が可能 14 VM VM VM イメージキャッシュ イメージA イメージB コンピュート VM VM VM [compute] use_cow_images = True [compute] use_cow_images = False VM毎に差分イメージ を作成 ディスクイメージ原本 はそのまま保存 VM毎に独立した イメージを作成
15. より高度なストレージ機能 15
16. manila: ファイルシステムストレージ • 外部ストレージに格納された共有ファイルシステムストレージ領域を 管理するコンポーネント • 共有ストレージ領域のスナップショットやバックアップも取得可能 • 構造などはcinderに似ている • 多数のドライバ*1を提供し、ストレージ機器やSDSと連携 • 複数のストレージを同時に使うこともできる • ストレージとの接続プロトコルも複数対応 • NFS、CIFS、HDFS、Ceph FS等 • ストレージ領域はVMからネットワーク越しに接続する • 共有ストレージ領域はShareネットワークに接続 • VMからはShareネットワーク経由で直接ストレージにアクセスする • アクセス可能なクライアントIPやユーザ等はアクセスルールにて規定 16 *1 参考: https://docs.openstack.org/manila/latest/configuration/shared-file-systems/drivers.html スナップショット 共有ストレージ領域 manila-api ユーザ manila-volume manila-scheduler コントローラ D社ストレージ N社ストレージ VM VM Shareネットワーク コンピュート
17. swift: オブジェクトストレージ • OpenStackコミュニティ内で開発されているオブジェクトストレージ • データとメタデータをまとめた「オブジェクト」を管理 • REST APIによってオブジェクトを操作(GET/PUT/…) • アカウント・コンテナというディレクトリに類似した構造を持つ • アカウント = Project に対応 • コンテナは疑似的に階層構造化ができる • 複数のノード、ディスクを束ねてスケーラブルなストレージを構成する • 集約された配置管理システムを持たず、Ringファイルに含まれるハッシュテーブ ルと格納パスによってデータを配置するディスクを特定する • ペタバイトスケールまで拡張可能。またデータセンタを跨いだ構成向けのアクセス 最適化機能なども備える • オブジェクト等のデータをクラスタ内の複数のデバイスに複製し、ノードやディ スクが故障した際もデータにアクセス可能にする • リージョンやゾーン(≒ラック)、サーバ、ディスクといった複数のFailure Domain に対してデータを分散させる • 標準は単純なデータ複製だがErasure Codingにも対応 17 プロキシサーバ proxy-server ストレージサーバ account-server container-server object-server ロードバランサ ストレージサーバ account-server container-server object-server ストレージサーバ account-server container-server object-server Ring Ring Ring Ring PUT GET
18. ボリュームデータの暗号化 • LUKSによりストレージ上のデータを暗号化する • Cinderがボリューム作成時にLUKSによるボリューム領域の暗号化を設定し、 その後イメージデータの書き込みを行う • 暗号化デバイスをアンロックするためのパスフレーズはBarbicanに格納する • 暗号化はVMに対して透過的に行われる • ストレージ上のデータやストレージと各サーバの通信は暗号化される • データはハイパーバイザで復号する • Novaがボリュームをアタッチする際、Barbicanからパスフレーズを取得して暗 号化デバイスをアンロックする 18 VM コンピュート cinder-api cinder-volume コントローラ nova-compute ストレージ LUN barbican-api 鍵を登録・取得 鍵を取得 デバイスを アンロック デバイスを アンロック データが暗号化される範囲
19. Cephとのインテグレーション • CephはInktank(後にRedHatが買収)が開発したOSSのストレージソフトウェア • 複数のサーバを束ねて一つのストレージクラスタを構築する • 様々なインタフェースを提供可能 • ブロック(RBD)、ファイル(Ceph FS)、オブジェクト(RADOSGW) • OpenStackの複数のコンポーネントにサポートされており、共通ストレージバックエンドとして利用 • 同一クラスタを採用すれば、Glance・Nova・Cinder間のイメージデータのやり取りをクラスタ内のイメージ複製＋Copy on Writeにより効 率化することができる 19 コンポーネント 用途 Nova エフェメラルストレージのデータ格納 *1 Glance イメージデータの格納 Cinder ボリュームデータの格納、バックアップデータの格納 *1 Manila 共有ストレージ領域のデータ格納 *2 Swift 互換APIを提供 *1 QEMUのrbdドライバを利用してVMからのIOを実行 *2 Ceph FSプロトコルを用いた直接接続や、NFS Ganeshaを仲介したNFSプロトコルでの接続が可能
20. Q&A 20