Storage¶
ストレージは、データベースのワークロードで最も重要なコンポーネント 。ストレージは常に利用可能で、スケーリングし、適切に機能し、一貫性と耐久性を保証する必要があります。仮想マシンやベアメタルなどの従来の環境に適用されるのと同じ期待と要件は、Kubernetesによって管理されるコンテナコンテキストでも有効です。
重要
Kubernetesには、動的にプロビジョニングされたストレージに関して独自の特性があります。これらには、ストレージクラス、永続ボリューム、および*永続ボリューム要求*が含まれます。 VMおよび物理的サーバー上のデータベースワークロードのストレージに関して長年にわたって構築してきた貴重な知識に加えて、これらの概念を所有する必要があります。
ストレージへのアクセスには、プライマリに2つの方法があります。
ネットワーク ：直接または間接（Kubernetesを実行しているホストにローカルにマウントされたNFSボリュームを考えてください）
ローカル ：Podが実行されているノードに直接接続されます（これには、Kubernetesのベアメタルインストールに直接接続されたディスクも含まれます）
Kubernetesで最も一般的な使用パターンであるネットワークストレージは、従来の環境で経験できるのと同じスループットとレイテンシの問題を示しています。これらは、いくつかのアプリケーションとのI / O競合によりパフォーマンス結果のばらつきが増加する共有環境で強調できます。
ローカルストレージは、シェアードナッシングアーキテクチャを可能にします。これは、より高い予測可能なパフォーマンスを保証するため、高トランザクションおよび超大規模データベース（VLDB）ワークロードにより適しています。
警告
CloudNativePGでPostgreSQLクラスターをデプロイする前に、使用しているストレージがデータベースワークロードに推奨されていることを保証してください。私たちのアドバイスは、最初に fio などのツールを使用してストレージをベンチマークし、次に pgbench を使用してデータベースをベンチマークすることにより、パフォーマンスの期待値を明確に設定することです。
CloudNativePGのベンチマーク¶
EDBは、 cnp-bench を管理します。 cnp-bench は、運用環境でデータベースを展開する前に、管理されたKubernetes環境でCloudNativePGをベンチマークするためのオープンソースのガイドラインとHelmチャート稼動。
簡単に言うと、 cnp-bench
は2つのレベルで動作するように設計されています。
関連する
fioを使用して、基礎となるストレージのパフォーマンスを測定する シーケンシャル読み取り、シーケンシャルのスループットなどのデータベースワークロードのメトリック 書き込み、ランダム読み取り、ランダム書き込みデフォルトのベンチマークツールを使用してデータベースのパフォーマンスを測定する PostgreSQLと一緒に配布：
pgbench
重要
ストレージとデータベースのパフォーマンスの両方を測定することは、データベースが稼動する**前に行う必要があるアクティビティです。ただし、このような結果は、計画段階（キャパシティプランニングなど）だけでなく、特に緊急事態（この種のテストを実行する余裕がない場合）の稼動ライフサイクルでも非常に貴重です。データベースは実際に時間とともに変化し進化するため、データのディストリビューションも変化し、パフォーマンスに影響を与える可能性があります。シーケンシャル読み取りまたは書き込みの理論上の最大スループットを知ることは、こうした状況で非常に役立ちます。特に、外部ワークロードの影響により結果が変わらないシェアードナッシングコンテキストでは。 **システムを把握し、ベンチマークを行います。
永続的なボリューム要求¶
演算子は、 PGDATA
を保存することを目的として、PostgreSQLインスタンスごとに永続ボリューム要求（PVC）を作成し、それを各ポッドにマウントします。
ストレージクラスを介した設定¶
PostgreSQLクラスのストレージを設定する簡単な方法は、次の例のように、特定のサイズのストレージを要求することです。
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
name: postgresql-storage-class
spec:
instances: 3
storage:
size: 1Gi
前の構成を使用すると、生成されたPVCはデフォルトのstorageclassで満たされます。ターゲットKubernetesクラスターにデフォルトのストレージクラスがない場合、またはPVCを既知のストレージクラスで満たす必要がある場合でも、カスタムリソースに設定できます。
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
name: postgresql-storage-class
spec:
instances: 3
storage:
storageClass: standard
size: 1Gi
重要
CloudNativePGは、ストレージクラスに依存しないように設計されています。いつものように、稼動環境に到達する前に、制御された環境でストレージクラスを適切にベンチマークすることをお勧めします。
PVCテンプレートを介した設定¶
生成されたPVCをさらにカスタマイズするには、次の例のように、カスタムリソース内にPVCテンプレートを提供できます。
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
name: postgresql-pvc-template
spec:
instances: 3
storage:
pvcTemplate:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
storageClassName: standard
volumeMode: Filesystem
ボリューム拡張¶
Kubernetesは、 expanding PVCs を許可するAPIを公開します。これはデフォルトで有効になっていますが、基礎となる
StorageClass でサポートするニーズがあります。
特定の StorageClass
がボリューム拡張をサポートしているかどうかを確認するには、ストレージクラスの
allowVolumeExpansion フィールドを読み取ります。
$ kubectl get storageclass -o jsonpath={$.allowVolumeExpansion} premium-storage
true
ボリューム拡張Kubernetes機能を使用する¶
ストレージクラスがボリューム拡張をサポートしている場合、 Cluster
のサイズ要件を変更できます。演算子はすべてのPVCに変更を適用します。
StorageClass
が online volume resizing をサポートしている場合、変更はすぐにポッドに適用されます。基になるストレージクラスがそれをサポートしていない場合、サイズ変更をトリガーするにはポッドを削除する必要があります。
続行する最善の方法は、レプリカから開始し、各Podがバックアップされるのを待機して、一度に1つのPodを削除することです。
AKSでのPVCボリュームの拡張¶
現時点では、 Azure is not able to resize the PVC's volume without restarting the pod .CloudNativePGは、 Operator configuration の
ENABLE_AZURE_PVC_UPDATES 環境変数によってこの制限を克服しています。
'true'
に設定すると、CloudNativePGはPostgresクラスターのローリング更新をトリガーします。
または、以下の回避策に従って、AKSでボリュームのサイズを手動で変更できます。
AKSでのボリューム拡張の回避策¶
次の手順に従って、AKS上のPVCを手動でサイズ変更できます。例、3つのレプリカを持つクラスターがあるとします。
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
cluster-example-1 1/1 Running 0 2m37s
cluster-example-2 1/1 Running 0 2m22s
cluster-example-3 1/1 Running 0 2m10s
`docs <https://github.com/kubernetes-sigs/azuredisk-csi-driver/blob/master/docs/known-issues/sizegrow.md>`__ で説明されているように、Azureディスクは「接続されていない」状態のときにのみ展開できます。
< ！ _ _ _ _ _。これにより、オペレータはポッドを再作成し、バックグラウンドディスクのサイズ変更が完了する前にすぐにPVCに再接続できなくなります。
最初のステップは、新しいサイズを適用するクラスター定義を編集することです。たとえば、「2Gi」と次のようになります。
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
name: cluster-example
spec:
instances: 3
storage:
storageClass: default
size: 2Gi
cluster-example-1
Podがクラスターのプライマリであると仮定すると、最初にレプリカに進むことができます。例、
cluster-example-3
Podをホストするkubernetesノードのコード化からスタートます。
kubectl cordon <node of cluster-example-3>
次に、 cluster-example-3 ポッドを削除します。
$ kubectl delete pod/cluster-example-3
次のコマンドを実行します。
kubectl get pvc -w -o=jsonpath={.status.conditions[].message} cluster-example-3
次の出力が表示されるまで待ちます。
Waiting for user to (re-)start a Pod to finish file system resize of volume on node.
次に、ノードのコードを解除できます。
kubectl uncordon <node of cluster-example-3>
ポッドが正しく再作成され、実行中および準備完了状態になるまで待ちます。
kubectl get pods -w cluster-example-3
cluster-example-3 0/1 Init:0/1 0 12m
cluster-example-3 1/1 Running 0 12m
ここで、次のコマンドを実行してPVCの拡張を確認します。これにより、構成された「2Gi」が結果れます。
kubectl get pvc cluster-example-3 -o=jsonpath={.status.capacity.storage}
そのため、残りのポッドに対してこれらの手順を繰り返すことができます。
重要
kubectl cnpg promote （例： kubectl cnpg promote cluster-example 3 をプライマリにプロモートさせる kubectl cnpg promote cluster-example 3 ）を使用して、スイッチオーバーで新しいサイズ変更されたPodを昇格した後、プライマリインスタンスに関連付けられたディスクのサイズ変更を最後のディスクのままにします。
ストレージの再作成¶
ストレージクラスがボリュームの拡張をサポートしていない場合でも、ストレージを増やした新しいPVCを割り当てて、そこにデータベースを移動することで、異なるPVCでクラスターを再生成できます。このオペレーションは、クラスターに複数のノードが含まれる場合にのみ実行可能です。
それを行う間、次の例のように、 resizeInUseVolumes
フラグを無効にして、演算子が既存のPVCを変更しないようにする必要があります。
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
name: postgresql-pvc-template
spec:
instances: 3
storage:
storageClass: standard
size: 1Gi
resizeInUseVolumes: False
クラスター全体を別の格納領域に移動オーダーには、すべてのPVCとすべてのPodを再作成する必要があります。次の例のような3つのレプリカを持つクラスターがあるとします。
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
cluster-example-1 1/1 Running 0 2m37s
cluster-example-2 1/1 Running 0 2m22s
cluster-example-3 1/1 Running 0 2m10s
異なるPVCを使用してクラスターを再作成するには、クラスター定義を編集してdisable
resizeInUseVolumes
にしてから、すべてのインスタンスを異なるPVCに再作成します。
例として、 cluster-example-3
のストレージを再作成するには、次のことができます。
$ kubectl delete pvc/cluster-example-3 pod/cluster-example-3
それを行った後、演算子は、サイズ変更されたPVCを使用して別のレプリカの作成を調整します。
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
cluster-example-1 1/1 Running 0 5m58s
cluster-example-2 1/1 Running 0 5m43s
cluster-example-4-join-v2bfg 0/1 Completed 0 17s
cluster-example-4 1/1 Running 0 10s
