このろくでもない、すばらしきストレージの世界。/storage is brilliant

コンテナ共創センター勉強会 #2
の発表資料です

Transcript

1. コンテナ共創センター勉強会 #2 このろくでもない、 すばらしきストレージの世界。 2021/05/26 レッドハット株式会社 ソリューションアーキテクト 宇都宮卓也
2. kind: HumanBeings metadata: name: 宇都宮 卓也 status: group: レッドハット株式会社 title: ソリューションアーキテクト born: 大阪 age: 39 history: - company: 日本アイ・ビー・エム株式会社 period: 2007/04 - 2017/02 role: ストレージTech Sales - company: レッドハット株式会社 period: 2017/03 - role: ソリューションアーキテクト favorites: - technology: ストレージ hobby: [“プロレス観戦”,“将棋”,”野球観戦”] drink: [“炭酸”, “トニックウォーター”] annoyance: [“最近目が霞む”, “体が痛い”] @japan_rook Japan Rook https://rook.connpass.com/ https://www.redhat.com/ja/resource s/openshift-4-first-step-guide-step-t o-enterprise-kubernetes-ebook 2 Whoami このろくでもない、すばらしきストレージの世界。
3. 3 このろくでもない、すばらしきストレージの世界。 本日の内容 • ストレージは難しい。 • ストレージは変わっていく。 • Kubernetes/OpenShiftのストレージ。 • ストレージを選ぶこと。 • ストレージはすばらしい。
4. ストレージは難しい。
5. 5 レッドハット社内の勉強会でとったアンケートより
6. 6 ❌　Kubernetes Storage is hard ⭕　Storage is hard KubeCon + CloudNativeCon Europe 2019 Keynote: Debunking the Myth: Kubernetes Storage is Hard - Saad Ali, Senior Software Engineer, Google https://kccnceu19.sched.com/event/MQhi このろくでもない、すばらしきストレージの世界。
7. 7 ストレージはなぜ難しい • ストレージの種類 ◦ ブロック ▪ iSCSI, FC, etc ◦ ファイル ▪ NFS, CIFS, etc ◦ オブジェクト ▪ S3, Swift, REST • 実装形態 ◦ HWアプライアンス ◦ SDS • アクセス制御 ◦ 論理パーティショニング ◦ ユーザー認証 ▪ AD/LDAP, RBAC • クライアント間の領域共有 ◦ 1クライアント占有 ◦ 複数クライアントで共有 • バックアップ ◦ Snapshot, Clone ◦ Backup SW連携 • 災害対策(DR) ◦ Stretched Cluster(同期レ プリケーション) ◦ 非同期レプリケーション • 暗号化 ◦ at rest ◦ in-flight ◦ 鍵管理 • プラットフォーム ◦ ベアメタルサーバー ◦ 仮想化基盤 ◦ コンテナ基盤 • コスト etc... • 容量 ◦ 初期容量, 将来の容量 ◦ 拡張性 • 性能 ◦ IOPS, Thruput ◦ Latency • データの冗長化手法 ◦ RAID ◦ ミラーリング ◦ Erasure Coding • 媒体 ◦ HDD ◦ Flash ▪ SAS/SATA SSD ▪ NVMe ▪ MLC/TLC/QLC ◦ Tape, Optical 考慮すべき要素の多さと関係性 このろくでもない、すばらしきストレージの世界。
8. 8 ストレージはなぜ難しい ミスが大事故につながる精神的負担 このろくでもない、すばらしきストレージの世界。 いくつかのニュースの記事を貼っていましたが自重します
9. 9 ストレージはなぜ難しい etc... その割に検討時間が充分にないこともしばしば • 基本的にアプリケーションから優先的に検討される ◦ アプリケーション側ほどビジネスへの影響の大きいので当然 • ストレージの要件はアプリ, MW, OS, Server 諸々の要件が積み重なって出され る ◦ これらが決まらないとストレージを決められない ◦ 現実的でない要件の場合は手戻り Application Middleware OS Server Storage Network 検 討 順 このろくでもない、すばらしきストレージの世界。
10. ストレージは変わっていく。
11. 11 ワークロードの変化に伴う ストレージに求められる事の変化 このろくでもない、すばらしきストレージの世界。 CI/CD マイクロサービス アーキテクチャ/ ドメイン駆動設計 コンテナ マルチプラットフォーム クラウドファースト ハイブリッドクラウド ストリーミングデータ サーバレス イベントドリブン データウェアハウス データレイク 機械学習 Stateful Appへの 永続ストレージの提供 プラットフォームフリーな実 装 プラットフォーム間のデータ 授受 イベント通知 構造化/非構造化データ スケーラビリティ
12. 12 データの種類 このろくでもない、すばらしきストレージの世界。 Data at rest データベース, DWH/Data Lake Data in motion ストリーミング, メッセージング Data in action データ分析, 意思決定, AI/機械学習
13. 13 このろくでもない、すばらしきストレージの世界。 昨年出させていただいたIBMさんのストレージ座談会 日時 テーマ 概要 第1回：10月13日 （火）12:00-13:00 ランサムウェア攻撃の最後の砦、身代金を 払わず事業継続できる仕組みとは データを人質に身代金を要求するランサムウェア被害が拡大しています。できる限りの 対策を講じても、ひとたび標的にされると被害を避けることは極めて困難ですが、感染 しないバックアップデータを使うことで、身代金を払わずに事業継続が可能となります。 当セミナーでは、増加するセキュリティー被害の動向や脅威に対峙するための有効な 対策について、専門家とともに議論します。 第2回：10月22日 (木) 12:00 – 13:00 時代の転換期！勝ち組企業を支えるデータ 基盤とは – 膨大なデータをいかに効率的に 貯め、活用していくか - デジタル変革や 5G時代に向けてデータの重要性は高まる一方です。データがビジネス 成長の原動力となる中、必要な全てのデータの安全かつ確実な保管、鮮度の高いデー タの高速処理、システム費用の効率化など、データ基盤に関わる課題は後を絶ちませ ん。当セミナーではこれら課題を如何にテクノロジーで実現できるか。お客様の先進的 な取り組みと共に新たな時代に向けたデータ基盤の選択肢を議論します。 第3回：11月12日 (木) 12:00 – 13:00 コンテナ活用で実はストレージが重要な理由 とその選択肢とは ビジネスニーズへの迅速な対応が求められる中、アプリの開発生産性や可搬性向上を 実現する技術としてコンテナが注目を集めています。本格的なコンテナ活用を考えた 時、ストレージも重要な役割を担うことをご存知でしょうか。当セミナーでは、コンテナプ ラットフォームの動向や意外と知られていないコンテナ環境でのストレージの役割や選 択のポイントを中心に議論します。 https://www.ibm.com/blogs/systems/jp-ja/ibmstorage- webseminar-2020/
14. 選択肢 回答 1. 考えたこともなかった 10.6 % 2. コストが合わない 0.0 % 3. 最適なストレージが分からない 42.6 % 4. セキュリティ 6.4 % 5. システムの連携・接続性 21.3 % 6. 技術者不足 4.3 % 7. ストレージが課題だと感じていない 8.5 % 8. わからない 6.4% 14 このろくでもない、すばらしきストレージの世界。 そこで取ったアンケート Q. コンテナ導入の「ストレージ活用」における懸念・課題点は何でしょうか。 A. 択一式、回答数 : 約110
15. 15 このろくでもない、すばらしきストレージの世界。 まだまだChallengeであり続けるコンテナ環境のストレージ From CNCF Survey 2020 : https://www.cncf.io/wp-content/uploads/2020/11/CNCF_Survey_Report_2020.pdf
16. 16 従来の考え方から見たコンテナ環境のストレージの難しさ このろくでもない、すばらしきストレージの世界。 • 新しい概念 ◦ 抽象化 ▪ Kubernetesで言う “Persistent Volume” の概念 ◦ Infrastructure as Code ▪ APIを使ったストレージ管理のコード化 ◦ Immutable(不変な) Infrastructure ▪ 『使い捨て』のクライアントとストレージ • ストレージの要件が不明確 ◦ 稼働するアプリケーションが予測できない ◦ 必要とする機能・性能が分からない • ユーザーの利便性とリソース管理のバランス ◦ ユーザーの利便性 ▪ セルフサービスで欲しい時にすぐストレージを使える ◦ リソース管理 ▪ 好き放題使われると容量・性能も不足する
17. Kubernetes/OpenShiftの ストレージ。
18. 18 Kubernetes/OpenShiftの永続ストレージ このろくでもない、すばらしきストレージの世界。 • 重要な概念/リソース ◦ Persistent Volume ◦ Persistent Volume Claim ◦ Storage Class 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 バックエンドストレージ
19. 19 Persistent Volume (PV) このろくでもない、すばらしきストレージの世界。 • Kubernetes/OpenShiftのPodが使用できる永続ストレージ • 様々な形態のストレージを抽象化した姿 LUN, volume, ... VMDK, QCOW2, ... Persistent Volume
20. 20 Persistent Volume Claim(PVC) このろくでもない、すばらしきストレージの世界。 • ユーザーがPVを使うための要求 ◦ セルフサービス • PVCに対してPVが割り当て(Bind)されると、ユーザーはPVを使える • 指定する項目の例 ◦ PVC name ◦ Size ◦ Access Mode ◦ Storage Class 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 PVCの例
21. 21 Access Mode このろくでもない、すばらしきストレージの世界。 • PVへのアクセス制御の方法を識別するモード ◦ Kubernetes/OpenShiftがアクセス制御しない、アクセス制御はバックエンドストレージに依存 • バックエンドストレージによって、使用できる Access Modeは異なる ◦ 使用できないAccess Modeを指定するとPVはBindされない Read Write Once (RWO) ◦ 1ノードからRead/Write可能 ◦ ほぼ全てのストレージで利用可能 ◦ 最も利用されることが多い基本のモー ド Read Only Many (ROX) ◦ 複数ノードから同時にRead-Onlyでア クセス可能 ◦ あまり使われることはなく、用途として は限定される Read Write Many (RWX) ◦ 複数ノードから同時にRead/Write可 能 ◦ 基本的にはファイルストレージで利用 可能 Persistent Volume Persistent Volume ReadOnly Persistent Volume
22. 22 Storage Class このろくでもない、すばらしきストレージの世界。 • バックエンドストレージを抽象化した姿 • 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 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の例
23. 23 Storage Provisioner このろくでもない、すばらしきストレージの世界。 • バックエンドストレージとAPIで通信して、論理ディスクのattach/detachや、作成/削除などを行う • 各ストレージシステムに対応する “In-tree (volume) plugin” または “CSI driver” を利用する ◦ In-tree pluginはKubernetesのbinaryに埋め込まれている (kubernetes.io/~) ◦ CSI driverはバックエンドストレージの提供元がサポートする Pod Pod Pod Storage A Storage A用 volume plugin Storage B用CSI driver Storage C用CSI driver Master Worker Worker Worker 各ストレージに対応した APIを 使ってPVを作成してPodに attach StorageClass=A StorageClass=B StorageClass=C Storage B Storage C PVC OCP 4.7のin-tree plugin
24. ストレージを選ぶこと。
25. 25 陥りやすいストレージの落とし穴 このろくでもない、すばらしきストレージの世界。 • なんとなく決めてしまうとハマる いま使ってるストレージが OpenShiftに対応してるらし い。 これで大丈夫だろ インフラ 設計者 NASみたいに使える？ 共有の置き場を作りたい ユーザー ハイブリッドクラウドに対応 できるようにして 変更依頼が多すぎて 全然間に合いません 運用 管理者 障害の時は詳しい人呼ばな いと保守できないです ひえ〜！ 容量パンパンです、性能の クレームも来てます なんで無理？データ置くだ けだろ？(怒) なんでこのストレージにした んだよ(怒)
26. 26 ストレージの隠れた課題 このろくでもない、すばらしきストレージの世界。 ユーザー(App開発者)から寄せられる 多様なストレージへの要求 ハイブリッドクラウドなインフラアーキテ クチャのストレージ設計 OCPの運用中のストレージの 作業負荷 OCPにおけるストレージの 運用保守の改善 • NASのように複数Podで同時に読み書きできる領域が欲しい • 自動でSnapshot取っておいて欲しい • オブジェクトストレージを使いたい • クラウドとオンプレで自由にアプリを動かせるようなストレージにし て欲しい • クラウドとオンプレでデータをミラーリングして欲しい • ストレージの割り当てが手作業なのでタイムリーに配れない • 依頼が多すぎて間に合わない • 使われなくなった領域の削除が手作業でつらい • ストレージの運用がボトルネックになっている • ストレージ専任者が居なくなっても保守できるようにしないと怖くて 運用できない
27. 27 望ましいストレージ このろくでもない、すばらしきストレージの世界。 • 広い用途に対応できるストレージで運用をはじめたい ◦ 1つでできるだけ広くストレージ要件をカバーできる ◦ 主力として使いながら、特殊な要件が出てきたら見合うストレージを購入して併用する • 主力として使えるだけの能力は備えて欲しい ◦ 耐障害性が高く、access loss/data lossが起こりにくい ◦ I/Oパフォーマンスは低すぎないこと • 初期投資は安く • 運用負担は低く ◦ OpenShiftと独立した運用はできるだけ避けたい ◦ 属人的な運用を避けたい
28. 28 Red Hat OpenShift Data Foundation このろくでもない、すばらしきストレージの世界。 • プラットフォームフリーなOpenShift専用ストレージ ◦ いかなるプラットフォームでも全く同じストレージを提供 ◦ 豊富なFeature • 自律的な運用保守 ◦ インストール、拡張/アップグレードなどの保守運用、障害発生時の復旧などの障害 運用を自動化し、運用負荷の低いストレージ環境を提供 • 幅広いユースケースに対応 ◦ Block(RWO), File(RWX), Objectの全種類のストレージを提供 • OpenShiftの機能との統合/連携 ◦ OpenShiftのGUIと統合されたダッシュボード ◦ OpenShiftのインフラサービスとの連携 (Logging, Metrics, etc) • Red Hat Ceph Storageをベースとする高信頼性 ◦ Red Hat Ceph Storage の機能に基づく耐障害性 ◦ バックアップ基盤との連携 ◦ 既存のRed Hat Ceph Storageとの統合 Persistent Volumeを提供 Logging Monitoring Registry ユーザー アプリケーション クラスターサービス 併用可能 他の ストレージ OpenShiftのために用意された最適なストレージ基盤
29. ストレージはすばらしい。
30. 30 ワークロードの変化に伴う ストレージに求められる事の変化 このろくでもない、すばらしきストレージの世界。 CI/CD マイクロサービス アーキテクチャ/ ドメイン駆動設計 コンテナ マルチプラットフォーム クラウドファースト ハイブリッドクラウド ストリーミングデータ サーバレス イベントドリブン データウェアハウス データレイク 機械学習 Stateful Appへの 永続ストレージの提供 プラットフォームフリーな実 装 プラットフォーム間のデータ 授受 イベント通知 構造化/非構造化データ スケーラビリティ
31. 31 ストレージには課題がある このろくでもない、すばらしきストレージの世界。 従来のストレージでは簡単にできないことが求められている • Massive scalability • Easy to expand • Elasticity • No more guessing about future. • API driven • On demand rapid provisioning and operations. • Speed and agility • Unified Management • Effective Monitoring and Metering. • Deeper Integration. • Robust User Interface • Simplified API • Multi-tenancy
32. 32 etc... このろくでもない、すばらしきストレージの世界。
33. 33 新たな”Cloud Native Storage”へ取り組む業界 このろくでもない、すばらしきストレージの世界。 • 大手ストレージベンダー、スタートアップ、 OSSプロジェクト、エンドユーザーが参画
34. 34 ストレージはすばらしい。 The world is a fine place and worth the fighting for. − Ernest Hemingway
35. Thank you