HPE Blog, Japan
キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 

コンテナストレージ 応用編1

Yoji_Inoue

 

GettyImages-200516654-001_800_0_72_RGB.jpg

以前のBlogでコンテナのデータボリュームはコンテナの移動や削除で消えてしまうこと、そのために永続的(ステートフル)ストレージが必要なことを説明しました。今回から数回にわたりコンテナストレージの最新情報と、実際の応用例について解説してみたいと思います。

 

 

 

 

コンテナのストレージにはステートレスとステートフルがある

以前のブログでも解説しましたように、コンテナのストレージには2種類があります。コンテナの削除、移動と共に消えてしまう「ステートレス・ストレージ」と、コンテナの削除や移動でも永続的に残る「ステートフル・ストレージ(Persistent volumeとも呼ぶ)」です。Dockerの場合は以下の例に示しますように、前者が「Dockerストレージ」、後者が「Dockerボリューム」となります。開発中のダミーデータであれば、ステートフルである必要はありませんが、最近導入が進むCI/CD(Continuous Integration Continuous Delivery : 継続的インテグレーションと継続的デリバリー)実現のためには、本番データを継続的に使用する必要があり、その場合高いIO性能やロードバランス、データ容量削減機能だけでなく、高い可用性、堅牢性、さらにはスナップショットやバックアップといった本格的ストレージ製品の機能が必要になります。そのため多くのストレージベンダーはプラグインを開発・提供しているわけです。HPE_Persisitent_Storage2.png

 

コンテナオーケストレーションのサポート

本格的にコンテナでデータストレージを利用するには単純にプラグインだけあれば良いというわけではありません。実際のコンテナ環境では、複数のコンポーネントが利用されていることが多いからです。現段階で押さえておくべきは以下の図のような構成をサポートできるようにすることでしょう。特にデータセンター規模でコンテナを実運用するにはコンテナオーケストレーションツールが必要です。主要なものは3つ、Kubernetes(以降k8s:文字数が多いので真ん中の8文字を短縮するこのような表現がよく使われます)、Docker社のSwarm、MESOSのMarathonですが、このうち一番使われているのはKubernetesです。Docker社も最新のEnterprise Edition 2.0(EE2.0)でKubernetesのサポートを開始しました。すでにDocker EEを利用されている場合は Docker EE内のUniversal Control Plane (UCP) を3.0.0にアップグレードすることで Kubernetesサポートが可能になります。

docker run --rm -it --name ucp -v /var/run/docker.sock:/var/run/docker.sock docker/ucp:3.0.0 upgrade --interactive

尚、HPEのDockerボリュームプラグインはコンテナランタイムと独立してしているため、前述の主要な3つのコンテナオーケストレーター全てのサポートが可能です。
 HPE_Persisitent_Storage.png

 

HPEストレージ製品の機能をk8sで使うメリット

HPEストレージのKubernetes実装はDoryというオープンソースドライバーで提供されます。Doryという名前の由来は、(多くの方が推察されるように)ファインディング・ニモのドリーからきていて、クジラ(Dockerのロゴ)と話しができることから命名されたようです。つまりDoryはKubernetes のFlexVolumeへのリクエストを Dockerボリュームプラグインのリクエストに変換(翻訳)してくれます。そのためDoryにより迅速なストレージプロビジョニングができるようになるだけでなく、Kubernetesから自動でステートフル・ストレージ(Persistent Volume)のアタッチやマウント等ができるようになります。

以下は具体例ですが、ポリシーベースでのストレージクラスリソースのプロビジョニングが非常に簡単に実行できます。(HPEのNimbleストレージの例)

 $ cat | kubectl create -f-
---
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
 name: prodmariadb
provisioner: hpe.com/nimble
parameters:
  description: "Prod StorageClass for Databases"
  perfPolicy: MariaDB
  protectionTemplate: Local48Hourly-Cloud64Daily #データ保護ポリシー
  limitIOPS: "15000"  #IOPSの上限
  encryption: "True"  #暗号化ON
storageclass "prodmariadb" created

 このようにStorageClassボリュームを作成し、それに対してPersistent Volume Claimsを作成します。

$ cat | kubectl create -f-
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: mariadb-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 256Gi
  storageClassName: prodmariadb
persistentvolumeclaim "mariadb-pvc" created

 

念のため作成されたPersistent Volume 確認します。

$ kubectl get pvc/mariadb-pvc
NAME        STATUS VOLUME              CAPACITY ACCESSSTORAGECLASS AGE
mariadb-pvc Bound  prodmariadb-a8e3... 256Gi    RWO   prodmariadb  5s

 

ここまでの簡単なステップで、MariaDBのパフォーマンスポリシーに最適な 256GiB 15K IOPS のPersistent ボリュームが作成されました。さらに本番環境のDBですので、スナップショットを1時間ごとに自動で作成し、2日間ローカルに保管。同時にHPE Cloud Volumeにレプリケーションされたデータを2か月間バックアップとして保管するように設定しています。このようにHPEのストレージのポリシー設定をそのまま利用することで、ユーザーはデータ容量以外の難解なストレージ設定から解放されます。

  

このようにコンテナを実運用で利用するためにはステートフルストレージ(Persistent volume)のサポートが必要なのですが、それを上記のような簡単な方法で実現できることがお分かりいただけたかと思います。
でもまだまだコンテナの具体的利用方法についてはピンとこない方も多いのではないでしょうか? ということで、次回以降はコンテナの具体的応用例をいくつかあげて解説してみたいと思います。 

 

 

0 感謝
作者について

Yoji_Inoue

Technology Evangelist, Composable Infrastructure, Software Defined Data Center and Cloud Technology Architect, Hyper Converged, Storage, Memory centric-Data driven computing, Specialist