#CNDT2019 Cloud Native Storageが拓くDatabase on Kubernetesの未来

Cd891a89dfec6ca7bd278b5f5bd87c90?s=47 tzkoba
July 19, 2019

#CNDT2019 Cloud Native Storageが拓くDatabase on Kubernetesの未来

2019/7/22 CloudNativeDays Tokyoの発表資料です。
Database on Kubernetesの課題と現在地点、未来予想図について紹介しています。

・PostgreSQL+Rook/Ceph
・PostgreSQL+LINSTOR/DRBD
・Stolon
・KubeDB

Cd891a89dfec6ca7bd278b5f5bd87c90?s=128

tzkoba

July 19, 2019
Tweet

Transcript

  1. 2.

    2 PostgreSQL on Kubernetes、色々やってます Cloud Native Developers JP #12 Database

    on Kubernetesの現在地点 - HA,Replication and more - PGConf.Asia 2019 @Bali Building PostgreSQL as a Service with Kubernetes  + =∞
  2. 3.

    3 アジェンダ 1. Cloud Nativeなデータベースとは? 2. Cloud Nativeなストレージとは? 3. Kubernetes上でデータベースを動かす際の課題

    4. Database on Kubernetesの実装例  HAパターン  Replicationパターン  Operatorパターン 5. DBプラットフォームとしてのKubernetes
  3. 5.

    5 Cloud Nativeなデータベースの様々な構成 Compute Storage マネージド Amazon Aurora Amazon Redshift

    Amazon RDS on Cloud on Kubernetes • マネージドサービスからコンテナ/K8sベースまで様々ある。
  4. 9.

    9 ストレージの基本的な分類  一般的には以下の3つに分類される。 ① ブロックストレージ ② ファイルストレージ(例:NFS、SMB) ③ オブジェクトストレージ(例:S3、Swift)

     現在では提供形態として、大まかに2つに分かれる。  物理ストレージ(例:Dell EMC、NetAppなど)  SDS(EBSも利用者から見るとSDSの一例)
  5. 10.

    10 Compute Control plane Data plane Kubernetes “Ready” と “Native”

    なストレージ Controler Controler • K8sがストレージのどこまでを管理する/できるかの違いがある。 Kubernetes Ready Kubernetes Native
  6. 12.

    12 データベースから利用 ≒ ブロックデバイス 名称 バックエンド ブロック? OSS/Proprietary Rook Ceph

    ◎ OSS OpenEBS --- ◎ OSS Redhat OpenShift Container Storage GlusterFS △ Proprietary StorageOS --- ◎ Proprietary • K8s Native+ブロック+OSSのRookが目立つ存在となっている。
  7. 15.

    15 Kubernetesの本質は分散システム • K8sクラスタはetcdを中心とした分散システムとして構築される。 • つまりノードが未応答の際に、 – ネットワーク分断? – プロセス(kubelet)障害?

    – ノード障害? どれに該当するか、判断が難しい。 • ディスクリソースがattachされて いれば、その状態も把握する必要 がある。 永続ボリュームを利用する workloadが嫌われる理由はこれ。 FailOver?
  8. 17.

    18 DBクラスタリングの基礎知識 HA (Active/Standby) 1 Sharding Replication (Active/Active) 2以上 インスタンス数

    データ冗長化 2以上 Shared Disk Log Shipping (基本的に) なし × スケールアウト Read Read/ Write Failover (Fencing) 障害時切替 Promotion (Election) --- • 複数ノードでDBを構成するクラスタリングには下記の手法があり、 インスタンス数や切替方法で違いがある。
  9. 18.

    19 クラスタパターン① HA • 障害検知/切替はLinux-HA等で • 生死監視の専用NW(二重化) • データは共有ストレージで冗長化 <<避けるべき最悪ケース>>

    • 複数インスタンスでストレージに 書き込みをしてしまうこと <<対策>> • Fencing:強制的なリソース解放 VIP Linux-HA Controller Controller • UNIX以前から使われる古典的クラスタリングだが、今なお有用。
  10. 19.

    20 Fencingとは VIP Linux-HA Controller Controller << 状態不明なマスターが発生したら>> ① 強制的にノードの電源落とす

    i. プロセスを確実に停止 ii. ストレージのマウントを外す iii. VIPを外す ② その上で別ノードでリソースを 獲得して、マスターを起動 ※強制電源断はHWベンダ提供の管理ポートや クラウドAPIを通して行われる。 • 障害ノードをフェンスで囲うこと(隔離) =Fencing
  11. 20.

    21 クラスタパターン② Replication WAL • マスタはRead/Write、 スレーブはReadのみを処理 • 障害検知/切替は別ツールが必要 •

    データはWAL転送で冗長化 <<避けるべき最悪ケース>> • 複数マスタが選出されること <<対策>> • リーダー選出:常に1台のマスタ • DBMSに組み込まれた冗長化機能で、データを相互同期する構成。 マスタ スレーブ スレーブ
  12. 21.

    22 リーダー選出とは WAL データは最新、 リーダーに選出。 他はスレーブ。 • 複数候補から常に1台のマスタ を選出 •

    元マスタが復帰後もスレーブに なっていることを通知する <<状態不明なマスタが発生したら>> ① 残ったスレーブから1台の リーダーを選出する ② 選出されたらマスターへ昇格 ③ 復帰ノードはスレーブになる • アルゴリズムとしてはPaxos、Raftなどが有名。 マスタ スレーブ
  13. 22.

    23 クラスタパターン③ Sharding • ノード間でデータを分割して保持、 一つのDBのように見せる。 • コーディネータが処理を振り分け、 負荷を分散する。 •

    データ冗長化は基本的に含まない。 合わせて実装することもある。 • トランザクション実装が難しい。 ※当資料でShardingの細かな解説はしない。 • 可用性よりも拡張性を高める際に使われる構成。 コーディネータ
  14. 24.

    25 Database on Kubernetes構成のサマリ # 分類 利用OSS 説明 ⅰ HA構成

    • 共有ストレージに Rook/Cephを利用 ⅱ • 共有ストレージに LINSTOR/DRBDを利用 ⅲ Replication • 共有ストレージなし、 Streaming Replication ⅳ Operator • Streaming Replicationを 自動で構築、運用する • K8sを用いたDBクラスタを4例、紹介する。
  15. 25.

    27 HA構成パターン(i): Replicas:1 • PostgreSQLはStatefulSet、PVとしてRook/Cephを用いる。 • DBもストレージも全て K8sで管理するHA構成 • 共有ディスクはCeph

    • kube-fencingでNode 障害時のFencing << 課題 >> • 複雑すぎるCeph • ネットワーク越しのIO による性能劣化 kube-fencing
  16. 27.

    29 HA構成パターン(ii): Replicas:1 kube-fencing • LINSTORがProvisioning/AttachするDRBDボリュームを用いる。 • DBもストレージも全て K8sで管理するHA構成 •

    DRBDでデータ冗長化 • シンプル • ReadはローカルIO、 性能面でCephに優る << 課題 >> • スケール上限あり
  17. 29.

    31 Replicationパターン: proxy proxy proxy keeper keeper keeper sentinel sentinel

    sentinel • PostgreSQLのSRをK8s上に構築、リーダー選出を実装。 • proxy:接続管理 • keeper:DBの実体、 レプリケーションを構成 • sentinel:リーダー選出 • 共有リソースなし ※SR=Streaming Replication << 課題 >> • コンポーネントの多さ • Readの分散不可
  18. 30.

    32 • Operatorでこうした問題も解決。 • KubernetesのOperatorは、 – Custom Resource Definition(CRD) –

    Custom Controller で構成される。 • ユーザ定義のCRDに対応して、 Controllerが状態維持を行う。 Database on Kubernetesの更なる課題 • HA(+SDS)やReplicationでDBクラスタリングの部品は揃ったが、 共通の課題が存在する。 コンポーネントが沢山あって、 インストールが大変。 CephやDRBD、PostgreSQLの コマンドを知らないと バックアップ・リストアなど 運用ができない YAMLが多くて 記述・管理がつらい。
  19. 31.

    33 (参考)Operatorの例: • RookはCeph他のSDSを構築・管理するOperatorである。 operator agent/discover agent/discover agent/discover osd osd

    osd mon mon mon CSI csi-provisioner csi-rbdplugin csi-rbdplugin csi-rbdplugin Rook • RookはCephクラスタや CSI対応を容易にする。 • CephクラスタはCRDと して管理される。 • osdやmonの数やモニタ リングの設定も宣言的に 設定が可能。
  20. 32.

    34 Operatorパターン: • KubeDBはPostgreSQLに限らず、様々なDBを扱えるOperator。 kubedb-operator -0 -1 -2 postgres snapshot

    dormantdabases • KubeDBでは – PostgreSQL – MySQL – Redis 等のCRDが準備済。 • kubedb-operatorが PostgreSQLのSRを構成。 • SnapshotのCRDもあり、 バックアップ・リストア が可能。 S3等にスナップショット の保存が可能
  21. 33.

    35 (例)KubeDBでPostgreSQL apiVersion: kubedb.com/v1alpha1 kind: Postgres metadata: name: ha-postgres namespace:

    demo spec: version: “10.6-v2" replicas: 3 storageType: Durable storage: storageClassName: "standard" accessModes: - ReadWriteOnce resources: requests: storage: 100Gi • バージョン、replica数を指定する だけで、良しなに構築。 • CRDには他にもプロパティがある ので、詳細な指定も可能。  spec.archiver – アーカイブログの格納先を指定可能  spec.init – 初期化元となるscript、snapshotを指定  spec.backupSchedule – バックアップ取得タイミングを指定 • シンプルにReplication構成のデータベースを定義可能。
  22. 34.

    36 (例)KubeDBでSnapshot apiVersion: kubedb.com/v1alpha1 kind: Snapshot metadata: name: snapshot-to-s3 labels:

    kubedb.com/kind: Postgres spec: databaseName: ha-postgres storageSecretName: s3-secret s3: endpoint: 's3.amazonaws.com' bucket: kubedb-qa prefix: demo • Snapshotの定義もYAMLで宣言的に管理可能。 • 取得するDB名と格納先の接続情報 を記述したYAML(左)をapply、 簡単にバックアップできる。 • 格納先はS3だけでなく、GCS、 Azure Storageなどのクラウドや Swift、さらにKubernetesのPVも 指定が可能。
  23. 35.

    37 (参考)PostgreSQL+Rook/Cephでのバックアップ $ kubectl exec -it -n rook-ceph rook-ceph-tools-seq --

    rbd -p replicapool ls pvc-bdbc6e53-f6e9-11e8-b0d9-02f062df6b48 $ kubectl exec -it pg-rook-sf-0 -- psql -h localhost -U postgres -c "SELECT pg_start_backup(now()::text);" pg_start_backup ----------------- 0/C000028 (1 row) $ kubectl exec -it -n rook-ceph rook-ceph-tools-seq -- rbd snap create replicapool/img@snap $ kubectl exec -it pg-rook-sf-0 -- psql -h localhost -U postgres -c "SELECT pg_stop_backup();" NOTICE: pg_stop_backup complete, all required WAL segments have been archived pg_stop_backup ---------------- 0/D000050 (1 row) • Postgresのbackup、Cephのrbdコマンド等を使いこなす必要あり。
  24. 38.

    41 手掛かりとなるもの (兆候1)  PostgreSQLのPluggable Storage 対応  MySQLのようにバックエンドストレージを選択可能に。 

    DBに最適化されたストレージを利用可能となる。 (兆候2)  AWS Aurora、Azure Hyperscaleのようにクラウド・ リソースをフル活用して、RDBMSを再構築する試み。
  25. 39.

    42 (参考)THE LOG IS THE DATABASE. SQL Transactions Caching Storage

    Logging Storage Logging Storage Logging CPU Memory Cache(SSD) Page Cache(SSD) Log AWS Aurora(PostgreSQL) Azure Hyperscale • 両者ともRDBMSの機能を分割し、自社クラウドで展開している。
  26. 40.

    43 DB/Storage プラットフォームとしてのKubernetes DBaaS by Kubernetes STaaS by Kubernetes <<DBaaSの基本要素>>

    • HA • Replication • DB Operator <<STaaSの基本要素>> • シンプルな冗長化 • 分散ストレージ • 互換性の高いIF(CSI) • “Platform for Platforms”として、K8sが各Serviceを支える。