Upgrade to Pro — share decks privately, control downloads, hide ads and more …

OpenShiftストレージの基礎 / OpenShift Storage Fundamentals

OpenShiftストレージの基礎 / OpenShift Storage Fundamentals

以前書いた"コンテナストレージの基礎理解"の改変版です。

61e7dc2e84a1a1c4ac1a8e2c552fee07?s=128

Takuya Utsunomiya

March 29, 2021
Tweet

Transcript

  1. Red Hat OpenShift ストレージの基礎 レッドハット株式会社 1

  2. • OpenShiftクラスター自身が動かすアプリケーション ◦ クラスターサービス (ex. Logging, Monitoring, Metrics, Registry) 2

    Red Hat OpenShift ストレージの基礎 ・・・ Logging Metrics Monitoring Registry ユーザー アプリケーション クラスターサービス Persistent Storage Persistent Volume OpenShiftは永続的なストレージを必要とする • ユーザー(開発者)が開発して動かすアプリケーション ◦ Statefulなアプリケーション (ex. データベース) OpenShiftにおけるストレージ
  3. 3 形態 アプライアンス(ハード) Software Defined Storage 場所 OpenShiftクラスターの外 OpenShiftクラスターの中 構成

    イメージ 特徴 性能や信頼性など要件に合わせて選択可 能。既存で利用中のストレージなら運用面も 変わらず利用可能。 ソフトウェアで構築するストレージ。柔軟性や 拡張性が特徴。クラウドとオンプレで同じ環 境を構築できる。 ストレージもコンテナで構築するハイパーコ ンバージドのような構成。すべてを OpenShiftで管理できる。 主な製品 クラウド:AWS EBS, Azure File オンプレ:ベンダーのストレージ オンプレ/クラウド: ベンダーやOSSのSDS オンプレ/クラウド:Red Hat OpenShift Container Storage(OCS), Portworx など masters workers Driver Driver Driver APP APP APP Controller Controller masters workers Driver Driver Driver APP APP APP Software Software Software 別サーバーにすることも可能 masters workers Driver Driver Driver APP APP APP Software Software Software Red Hat OpenShift ストレージの基礎 OpenShiftで利用できる永続ストレージのパターン
  4. OpenShiftで永続ストレージを提供する仕組み 4 • 次の3つのリソースが永続ストレージを提供するために重要な役割を担う ◦ Persistent Volume ◦ Persistent Volume

    Claim ◦ Storage Class Red Hat OpenShift ストレージの基礎 Storage Provisioner Storage Class Persistent Volume user project App Pod Persistent Volume Claim ストレージシステム ユーザー 論理ディスク (LUN, volume, directory等) PVC作成 (Storage Class指定) PVCからTrigger APIで命令 PV作成 PVC Bind 論理ディスク作成 Worker Node接続 Bind Mount
  5. Persistent Volume (PV) 5 • OpenShift/KubernetesのPodが利用できる永続ストレージ • 様々な形態のストレージを抽象化した姿 LUN, volume,

    ... VMDK, QCOW2, ... Persistent Volume 物理サーバー 仮想サーバー Kubernetes Pod Red Hat OpenShift ストレージの基礎
  6. Persistent Volume Claim (PVC) 6 • PVを使用するためのリクエスト • ユーザー自身がセルフサービスで PVCを作成する

    • 次のような項目を指定する ◦ PVC name ◦ Access Mode ◦ Storage Class ◦ Size 1. ユーザーがPVをリクエスト (PVC作成) 3. Podがmount App 2. PVを割り当て(Bind) apiVersion: v1 kind: PersistentVolumeClaim metadata: name: app-pvc spec: accessModes: - ReadWriteOnce volumeMode: Filesystem resources: requests: storage: 10Gi storageClassName: gp2 10GB Red Hat OpenShift ストレージの基礎 PVCの例
  7. Read Write Once (RWO) ◦ 1ノードからRead/Write可能 ◦ ほぼ全てのストレージで利用可能 ◦ 最も利用されることが多い基本のモー

    ド Access Mode 7 Read Only Many (ROX) ◦ 複数ノードから同時にRead-Onlyでア クセス可能 ◦ あまり使われることはなく、用途として は限定される Read Write Many (RWX) ◦ 複数ノードから同時にRead/Write可 能 ◦ 基本的にはファイルストレージで利用 可能 • PVへのアクセス制御のモード • ある1つのPVは1つのモードだけで使われる。 1つのPVを複数のモードで使われることはない • バックエンドのストレージシステムによって、使用できる Access Modeは異なる ◦ 使用できないAccess Modeを指定した場合はPVCが失敗し、PVはBindされない Persistent Volume Persistent Volume ReadOnly Persistent Volume Red Hat OpenShift ストレージの基礎
  8. Storage Class 8 • バックエンドのストレージシステムを抽象化した姿 • PVCではStorage Classを指定する。指定しない場合は default Storage

    Classが使われる • 次のような項目を指定する ◦ Provisioner ◦ Reclaim Policy ◦ Allow Volume Expansion ◦ Volume Binding Mode Storage Class Storage Class Storage Class Hardware-appliance Storage Cloud Storage Software-defined Storage Red Hat OpenShift ストレージの基礎 apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: gp2 provisioner: kubernetes.io/aws-ebs Parameters: encrypted: ”true” type: gp2 reclaimPolicy: Delete allowVolumeExpansion: true volumeBindingMode: WaitForFirstConsumer AWS EBSのStorageClassの例
  9. Storage Provisioner 9 • ストレージシステムと APIで通信して、論理ディスクの attach/detachや、作成/削除などを行う • 各ストレージシステムに対応する “volume

    plugin” または “CSI driver” を利用する • 全てのvolume pluginをRed Hatがサポートするわけではない ◦ volume pluginはKubernetesのbinaryに埋め込まれている • CSI driverはストレージシステムの提供元がサポートする Red Hat OpenShift ストレージの基礎 OCP 4.6のin-tree volume plugin Pod Pod Pod Storage A Storage A用 volume plugin Storage B用CSI driver Storage C用CSI driver Master Worker Worker Worker 各ストレージに対応したコマンド に変換して操作し、PVを作成して Podに接続 StorageClass=A StorageClass=B StorageClass=C Storage B Storage C PVC
  10. CSI (Container Storage Interface) • 複数のコンテナオーケストレーター (CO)で利用可能な業界標準的なストレージインターフェース • ストレージシステムに依存しない共通の部分と、ストレージシステムに依存する部分 (=

    CSI driver)を分離 ◦ 共通の部分は Kubernetes 側でコンテナとして提供 ◦ CSI driver はストレージプロバイダーがコンテナとして提供 • ストレージシステムに依存する部分を Kubernetes Coreから分離することで、修正の適用や Updateなどが容易になり、従来の in-tree volume pluginの課題を解決する - CSI Driver : unique container by storage provider - Provisioner, Attacher, Registrar : sidecar by k8s team Kubernetes Volume plugin Volume plugin Volume plugin Kubernetes zzzz-csi driver yyyy-csi driver xxxx-csi driver Updated csi driver Independant Update 10 Red Hat OpenShift ストレージの基礎 In-tree volume plugin利用 CSI利用
  11. Storage Class - その他の項目 11 • Reclaim Policy ◦ PVCにPVがBindされている状態で、PVCを削除した時のPVの扱いを決めるポリシー

    ◦ 2つのポリシーから選択 ▪ Delete (default): PVCの削除とともに、PVとストレージシステム側の論理ディスクも削除する。 Dynamic Provisioning時は常に “Delete” が選ばれる ▪ Retain: PVCを削除してもPVは残す • Allow Volume Expansion ◦ PVの容量拡張を許可するかを決める ( “true” or “false” ) ◦ 拡張のみ可能、縮小は不可 ◦ Volume Expansionに対応するStorage Provisionerだけ利用可能 • Volume Binding Mode ◦ PVC作成時に、PVをBindするタイミングを決めるポリシー ◦ 2つのポリシーから選択 ▪ Immediate (default): PVCが作られると直ちにPVをBind ▪ WaitForFirstConsumer: PodがPVCを指定して作られる際に PVをBindする。それまではPending Red Hat OpenShift ストレージの基礎
  12. Persistent Volumeのプロビジョニング方式 12 Red Hat OpenShift ストレージの基礎 Static(Manual) Provisioning •

    あらかじめ論理ディスクと PVを作成しておく • PVCの内容に合致するPVがあればBindされる Dynamic Provisioning • ストレージシステムに対応する Provisionerを設定 し、Storage Classを作成しておく • PVCの要件に応じてリアルタイムに論理ディスクと PVが作られBindされる 20GB あらかじめ論理ディスクを作って PVとして登録しておく ストレージ管理者 ユーザー PVCの内容に合うPVがBindされる ストレージ システム 10GB 10GB 10GB 20GB 20GB 50GB 50GB PVC - 20GB - RWO - StorageClass A PVC - 20GB - RWO - StorageClass A 20GB Storage Provisioner とStorage Classの設 定 ユーザー PVCの内容に合うPVがその場で作られてBindされる ストレージ管理者 ストレージ システム 論理ディスクを作成し、PV として登録 StorageClass A 20GB
  13. 20GBのPVはない Static Provisioning 13 Red Hat OpenShift ストレージの基礎 利点 •

    多くのストレージで使える方式 ◦ サポートの有無は要注意 • PVCの内容に合うPVが無い場合はPVがBindされない 10GB 10GB 10GB 10GB 10GB 10GB PVC : 20GB • 必要以上な容量のPVがBindされてストレージの利用効 率を下げることがある 10GB 10GB 10GB 10GB 10GB 10GB PVC : 5GB 10GBのPVをBind 10GB 難点 • ユーザーはPVが必要になる都度、ストレージ管理者に PV作成の依頼をして待つプロセスになりがち • 容量拡張時にストレージシステムと OpenShiftの両方の 変更作業が発生し、運用が煩雑となる 論理ディスクの作成 論理ディスク名/ID等 の確認 論理ディスク名/IDか らPVを作成 20GBのPVを下さい 10GBのPVを2個使って下さい 20GBのPVが必要です 分かりました、明日明後日には はぁ…(溜め息) Persistent Volume Persistent Volume
  14. Dynamic Provisioning 14 Red Hat OpenShift ストレージの基礎 利点 • ユーザーはStorage

    Classを選択して好きなサイズの PV を即座に入手できる ◦ Access Modeに注意 • 管理者は最初にストレージシステムで PV用の領域を用意 し、OpenShiftでProvisionerとStorage Classを設定する だけでよく、トイル*から解放される ◦ 領域の拡張時もストレージシステム側だけの変更 でよい 難点 • 対応していないストレージシステムも存在する ◦ OpenShiftではローカルデバイスと NFSを除き大半の volume pluginで対応する ◦ CSI driverは各ストレージプロバイダーに依存する • VolumeExpansionやSnapshot等の機能の利用可否が、 Storage Provisionerが対応できるかどうかに依存する Storage Class sc-A 20GB PVC : 20GB 20GBのPVをBind 20GB Storage Provisioner 20GBの論理ディスクを 作りなさい。 20GB 作りましたよ。 XXノードにattachしなさ い。 attachしましたよ。 できた論理ディスクからPV を作ります。 ♪ ♪ *トイル(Toil) : サービスを提供する上で不可避な作業の中でも、手作業で繰り返し行われるもの。サービスが拡大するに比例して作業量が増えるにもかかわ らず、長期的な価値を生まないことが特徴。
  15. OpenShiftでサポートされるPersistent Volume (v4.6) 15 Red Hat OpenShift ストレージの基礎 Volume Plug-in

    ReadWriteOnce (RWO) ReadOnlyMany (ROX) ReadWriteMany (RWX) Dynamic Provisioning AWS EBS ✅ - - ✅ Azure File ✅ ✅ ✅ ✅ Azure Disk ✅ - - ✅ OpenStack Cinder ✅ - - ✅ Fibre Channel ✅ ✅ - Depend on Storage system GCE Persistent Disk ✅ - - ✅ HostPath ✅ - - - iSCSI ✅ ✅ - Depend on Storage system Local volume ✅ - - - NFS ✅ ✅ ✅ - OpenStack Manila - - ✅ ✅ Red Hat OpenShift Container Storage ✅ Available for OpenShift Virtualization only ✅ ✅ VMware vSphere ✅ - - ✅ https://docs.openshift.com/container-platform/4.6/storage/understanding-persistent-storage.html https://docs.openshift.com/container-platform/4.6/storage/dynamic-provisioning.html
  16. OpenShiftで永続ストレージを提供する仕組み 16 • 次の3つのリソースが永続ストレージを提供するために重要な役割を担う ◦ Persistent Volume ◦ Persistent Volume

    Claim ◦ Storage Class Red Hat OpenShift ストレージの基礎 Storage Provisioner Storage Class Persistent Volume user project App Pod Persistent Volume Claim ストレージシステム ユーザー 論理ディスク (LUN, volume, directory等) PVC作成 (Storage Class指定) PVCからTrigger APIで命令 PV作成 PVC Bind 論理ディスク作成 Worker Node接続 Bind Mount
  17. 仮想化基盤(VMware)でOpenShiftを構築する場合の ストレージの注意点 17 Red Hat OpenShift ストレージの基礎 VMware Datastore(=論理ディスク) ESXi

    Worker(VM) CoreOS Pod App Pod App Worker(VM) CoreOS Pod App Pod App ESXi Worker(VM) CoreOS Pod App Pod App Worker(VM) CoreOS Pod App Pod App PV (=vmdk) vSphere volume PV (=論理ディスク) CSI対応の既存ストレージシステム FC/iSCSI/NFS等 iSCSI/N FS等 • ストレージシステムの CSI driverを利用するには、OpenShiftのノー ドとストレージシステムが 直接通信できる必要がある ◦ 仮想化基盤でストレージシステムが VMの仮想ネットワークに 接続できるケースは少なく、構成変更が必要となる ◦ 既存のストレージシステムに CSI driverがあるからといって、 無条件にPVで活用できるとは限らない • vSphere volumeをPVで使う場合は構成変更は不要 ◦ vSphere volumeはブロックデバイスを提供するので RWO PV のみ利用できる。RWX PVが必要な場合は別途ファイルスト レージを用意する ◦ VolumeSnapshotに対応していないため、 PVのバックアップ は要検討 VMと論理ディス クの直接通信が 必要
  18. linkedin.com/company/red-hat youtube.com/user/RedHatVideos facebook.com/redhatinc twitter.com/RedHat Red Hat is the world’s leading

    provider of enterprise open source software solutions. Award-winning support, training, and consulting services make Red Hat a trusted adviser to the Fortune 500. Thank you 18