DRBD-SDSとKubernetes

Kubernetesの永続ストレージとしてDRBD-SDSを利用すると、CephやNFSなどを利用するよりも柔軟にストレージを利用することができます。Kubernetes上で、MySQLやPostgreSQLなどのリレーショナルデータベースを利用する場合には、DRBD-SDSを利用することでサービスの冗長化を実現することができます。

DRBD-SDSとは

DRBD-SDSは、DRBDバージョン9からサポートされたSDS（Software Defined Storage）の機能です。DRBDは、Linbit社が開発したオープンソースの分散ブロックデバイスの技術です。DRBDは、もともとはネットワークミラーリング用のソフトウェアとして、主にHAクラスタなどで利用されてきました。DRBDバージョン9では、より高機能なSDSのソフトウェアとして、より多くのサーバのストレージを管理できるようになりました。次のような特徴があります。

Kubernetesの連携

DRBDでは、複数のサーバストレージをLINSTOR（LINbit dataSTOR)と呼ばれるコントローラが管理します。LINSTORは、Kubernetesのストレージ割当メカニズムと連携して動作することができます。そのため、Kubernetesでストレージを割り当てると、自動的に冗長化したストレージが割り当てられます。

KubernetesとLinstorの連携画像

低コストで冗長化されたストレージ

冗長化されたNFSサーバは、比較的高価です。DRBDを利用すると、コントロールノードやワーカーノードのハードディスクを使って、冗長化したストレージを作成することができます。そのため、ストレージに必要なコストを抑えることができます。

小さな構成からスタートできる

Cephで冗長化されたストレージを利用するには、最小3台のストレージノードが必要です。DRBDは、最小2台で構成することができます。

スケーラビリティ

割り当てられたストレージは、どのワーカーノード上でも利用することができます。また、ワーカーノードを追加すれば、ハードディスク容量も増加します。そのため、必要に応じてリソースを拡張することができます。

非常に高性能な永続ストレージ

DRBD-SDSとCephの性能については、ベンチマーク結果が公開されています。DRBD-SDSは、シーケンシャルなデータ書き込みでは、Cephに比べて最大で19倍も高速に動作します。ランダムな書き込みの場合でも、1.4～3倍の性能を発揮します。また、シーケンシャルな読み込みでも、Cephに比べて最大で14倍も高速に動作します。また、DRBDでは、データ読み込み時には複数のストレージノードから並列にデータを読み込むことで、ローカルディスクよりも高速に動作します。

KubernetesとDRBD-SDSのデータ書き込みグラフ画像

商用サポートが受けられる

ストレージは非常に重要な機能です。そのため、安定して動作する必要があります。DRBDは、オープンソースソフトウェアですが商用サポートを利用することもできます。そのため、安心して利用することができます。

DRBD-SDSとMySQL、PostgreSQL

Kubernetesでは、MySQLやPostgreSQLのようなデータベースをどのように管理するのかが課題になります。DRBDを使うことで、この課題を解決することができます。

KubernetesでのMySQLやPostgreSQLの問題点

Kubernetesで、CephやNFSでストレージを構成している場合には、次のような問題があります。

MySQLやPostgreSQLのデータは、複数のノードから同時に書き込みを行うと破壊されてしまう
データベースのPodをStatefulSetとして登録し、同時に1台しか動作しないようにコントロールする必要がある
稼働していたノードの通信が途絶えても、別のノードで処理を引き継ぐことができない

というのは、旧ノード上のデータベースが動作を続けているため、旧ノードの通信が復旧した場合に同時に2台からのアクセスが発生してしまい、データが壊れてしまう可能性があるためです。そのため、Kubernetesだけでは、RDBの冗長性を担保することができないのです。

DRBD-SDSでPostgreSQLやMySQLやも冗長化できる

KubernetesでDRBD-SDSを使うと、PostgreSQLやMySQLを通常のReplicaSetとして管理することが可能になります。Kubernetesのサービス監視機能と組み合わせて、完全な冗長化を実現できます。それは、DRBD-SDSの機能で、マスターノードが1台だけになるように制御することができるからです。

DRBDでは、ストレージノード間で通信が行われ、ストレージプール全体でマスターが管理される
稼働ノードの通信が途絶えると、他のノードで処理が発生した時に自動的にマスタに切り替わる
旧ノードの通信が復旧すると、DRBDのフェールセーフ機能が働き、旧ノードからはデバイスに書き込むことができません。

KubernetesでのDRBDの制御

KubernetesにDRBDを統合することができます。例えば、各ワーカーノードで、次のようにDRBDのストレージノードが登録されています。

# linstor --no-utf8 n l ⏎
+-------------------------------------------------------------+
| Node      | NodeType  | Addresses                  | State  |
|-------------------------------------------------------------|
| kmaster   | COMBINED  | 192.168.56.10:3366 (PLAIN) | Online |
| kworker01 | SATELLITE | 192.168.56.11:3366 (PLAIN) | Online |
| kworker02 | SATELLITE | 192.168.56.12:3366 (PLAIN) | Online |
+-------------------------------------------------------------+

この例では、Kubernetesのマスタサーバkmasterに、DRBDのLinstorのコントローラとサテライトノードを兼任（COMBINED）させています。また、次のようにkworker01とkworker02には、ストレージプールdrbd01を定義しています。

# linstor --no-utf8 sp l ⏎
+--------------------------------------------------------------------------------------------+
|StoragePool |Node      |Driver    |PoolName |FreeCapacity |TotalCapacity |SupportsSnapshots |
|--------------------------------------------------------------------------------------------|
|drbd01      |kworker01 |LvmDriver |drbdpool |    8.00 GiB |     8.00 GiB |false             |
|drbd01      |kworker02 |LvmDriver |drbdpool |    8.00 GiB |     8.00 GiB |false             |
+--------------------------------------------------------------------------------------------+

Kubernetesでのストレージの利用

KubernetesでDRBDストレージを使う場合には、次のようなことを行います。

ストレージプールを利用するためのストレージクラスを定義する
ストレージクラスから、永続ボリュームを割り当てる
永続ボリュームをPodに割り当てる

KubernetesでのDRBDストレージクラスの定義

Kubernetesでは、このストレージプールを利用するためのストレージクラスを定義します。まずは、次のようなファイルを用意します。

storageclass.yaml

apiVersion: storage.k8s.io/v1beta1
kind: StorageClass
metadata:
  name: drbd-storage
provisioner: external/linstor	← LINSTORの設定
parameters:	← LINSTORのパラメータ
  autoPlace: "2"   ← 2つのサーバに配置
  filesystem: "xfs"   ←　作成するファイルシステムタイプ
  storagePool: "drbd01"   ←　ストレージプールの名前
  controllers: "192.168.56.10"   ←　LINSTORのアドレス

このファイルでは、drbd-storageという名前のストレージクラスを定義します。provisionerは、このストレージプールの割り当てをlinstorで行うことを設定しています。また、autoPlaceで自動的に２つのサーバにミラーリングして配置し、上位にxfsを作成することが定義されています。storagePoolで、LINSTORに定義したdrbd01というプールを使うことを指定しています。このファイルを使って、次のようにストレージクラスを定義します。

# kubectl create -f storageclass.yaml ⏎

KubernetesでのDRBD永続ボリュームの割り当て

定義したストレージクラスから、永続ボリュームを割り当てるには、次のようなファイルを作成します。

PersistentVolumeClaim.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: drbd-volume01	← 作成する永続ボリュームの割り当て
  annotations:
    volume.beta.kubernetes.io/storage-class: drbd-storage	← 利用するストレージクラス
spec:
  accessModes:
  - ReadWriteOnce
  resources:
  requests:
    storage: 500Mi	← 割り当てるサイズ

これは、drbd-volume01という名前の永続ストレージを割り当てるための定義ファイルです。利用するストレージクラスには、先ほど定義したdrbd-storageを指定します。この例では、割り当てるサイズを500Mに設定しています。次のようにすることで、実際に永続ストレージの割り当てが行われます。

# kubectl create -f PersistentVolumeClaim.yaml ⏎

KubernetesでのDRBD永続ボリュームの使用

次は、実際にMySQLで、この永続ボリュームを使用する場合の使用例です。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql
spec:
  selector:
    matchLabels:
      app: mysql
  replicas: 1
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - image: mysql:5.6
        name: mysql
        env:
        - name: MYSQL_ROOT_PASSWORD
          value: password
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /var/lib/mysql
      volumes: #
      - name: mysql-persistent-storage
        persistentVolumeClaim:
          claimName: "drbd-volume01"	← 割り当てられた永続ストレージ

割り当てられたボリュームの名称drbd-volume01を/dataにマウントするように指定しています。このように、通常の永続ボリュームと同様にDockerコンテナから利用することができます。

デモのお申込み

もっと使い方が知りたい方へ
Kubernetesの操作方法や操作性をデモにてご確認いただけます。使い方のイメージを把握したい、使えるか判断したい場合にご活用下さい。Kubernetesのデモをご希望の方は、下記よりお申込みいただけます。

デモの申し込みイメージ

OSS情報「Kubernetes」

Kubernetes〜コンテナ管理の課題を解決するOSS〜: ここでは、Dockerコンテナの管理を自動化するためのソフトウェア「Kubernetes」を紹介します。

Kubernetesクラスタの構築: ここでは、CentOS7に最小限のKubernetesクラスタを構築する方法について説明いたします。

KubernetesのPod機能: ここではPod機能について説明いたします。

Kubernetesのレプリカセットとデプロイメント: ここではデプロイメントという機能を利用してレプリカセットを作成する方法について説明いたします。

Kubernetesのアーキテクチャ: ここではアーキテクチャについて説明いたします。

Kubernetesのコンテナアップデート: ここでは、Kubernetesでソフトウェアをアップデートする場合の手法について説明いたします。

Kubernetesのローリングアップデート: ここでは、Kubernetesのローリングアップデート機能の概要について説明いたします。

Kubernetesのダッシュボード: ここでは管理用のダッシュボードについて説明いたします。

Kubernetesの永続ストレージ: ここでは永続ストレージについて説明いたします。

Rancher〜Kubernetesの管理ソフトウェア〜: ここでは、Kubernetesの管理ソフトウェアのRancherについて紹介します。

GitLab〜Dockerのプロジェクト管理とレジストリ〜: GitLabは、ウェブ型のGitリポジトリマネージャーです。ここではGitLabのコンテナレジストリについて説明いたします。

DRBD-SDSとKubernetes: ここではDRBD-SDSを利用することでサービスの冗長化を実現させる手法について説明いたします。

Falco〜コンテナの侵入・改ざん検知ツール〜: ここではKubernetesを代表するコンテナ環境をターゲットにしているコンテナランタイムセキュリティソフトウェアのFalcoについて説明いたします。

Trivy〜コンテナイメージの脆弱性診断ツール〜: Trivyは、コンテナイメージの脆弱性診断ツールです。ここではTrivyの機能や特徴などについて説明いたします。

コンテナ型仮想化に関連したOSS: ここでは、コンテナ型仮想化に関連したOSSを紹介いたします。