今回はコンテナを運用するための考慮すべきことや必要となることについて説明するとともに NetApp が提供しているコンテナ関連のテクノロジー、インテグレーションについて紹介します。
コンテナ、コンテナオーケストレーション とは？
さらに Docker だけでコンテナを管理しようとすると、単一のホストの機能を超えてアプリケーションを拡張することは複雑な作業になります。 このプロセスを簡単にするために、いくつかのコンテナオーケストラが非常に目立つようになりました。その1つは Kubernetes (k8s) です。
k8s を使用する場合、アプリケーション開発者/管理者は、アプリケーションを作成するために依存関係がある一連のコンテナの要件を定義します。 これには、各コンテナイメージだけでなく、ネットワーク上での通信方法や、必要なストレージまで含まれます。
コンテナをクラスタを構成するノードのどこにデプロイするか、クラスタ全体の管理や、リソース管理を行うものです。
現在のマーケットでは、主に以下のソフトウェアがプレイヤーとして登場します。
- Kubernetes
- Mesos (DC/OS)
- Docker Swarm
- OpenShift
- Rancher
今回は kubernetes/OpenShift に焦点を当て、 Kubernetes/OpenShift のデータ永続化について記載します。
コンテナ技術についてはよく話に上がりますが、何に使えるかという観点では様々な調査結果をまとめると大きく二点に絞られるかと思います。
- 社内の開発環境の払い出しの高速化
- ビジネス上のアウトプットの速度を向上、市場への TTM を高速化
kubernetes でのデータ永続化
Kubernetes の永続化ストレージの考え方は大きく ３ つに分類されます。
- Persistent Volume (PV)
kubernetes クラスタに導入されている iSCSI LUN, NFS export などの永続化ストレージの単位 - Persistent Volume Claim (PVC)
ユーザやアプリケーションからリクエストされる PV のこと、動的にストレージをプロビジョニングする際には PVC に StorageClass を指定する - StorageClass (SC)
ストレージのタイプを定義する仕組み。例えば “ Performance” や “ Capacity”といったストレージのサービスメニューを定義し、 PVCから要求した際に作成されるボリュームのカタログ化が可能。
[RELATED_POSTS]
Static Provisioning
kubernetes 1.3 まではデータの永続化にある程度制約が有りました、事前に手動で Persistent Volume (PV) を定義し実際のストレージリソースとのマッピングを実施します。 Persistent Volume Claim(PVC) が要求されたときに、条件にマッチする PV を探し出し割り当てる方式です。
PVC は kubernetes よって以下の動きをします。
k8s における Static provisioning のストレージリソース割り当て
コンテナを活用したセルフサービス、消費型のインフラストラクチャを実現するにはオンデマンドに PV を作成し、コンテナにマウントする必要があります。
Dynamic Provisioning & StorageClass
動的にストレージをプロビジョニングし、コンテナ化されたアプリケーションに PV を割り当てる機構として StorageClass が存在します。
StorageClass 自体は Kubernetes 1.2 でα版、 1.4 でβ版としてリリースされました。
- http://blog.kubernetes.io/2016/10/dynamic-provisioning-and-storage-in-kubernetes.html
そして Kubernetes 1.6 で安定版としてリリースされています。 - http://blog.kubernetes.io/2017/03/dynamic-provisioning-and-storage-classes-kubernetes.html
StorageClass を使った Dynamic Provisioning は以下のようなイメージで動作します。
k8s の Dynamic Provisioning & StorageClass
External Storage Provisioner とは？
External Storage Provisioner は kubernetes の out-of-tree (外側)で PV のダイナミックプロビジョニングを実現するものです。
out-of-tree とは kubernetes のコントローラーからボリュームをプロビジョニングするものではなく、外部に存在するもので独立してデプロイ、アップデートができるものです。
PersistentVolumeClaim で StorageClass を要求されたリクエストを監視し、自動的に PersistentVolume を作成します。
NetApp Trident
NetApp のストレージ・ポートフォリオを使用する場合、このダイナミックプロビジョニング機能は、 NetApp のオープンソースプロジェクトの NetApp Trident を使用して提供されます。
NetApp Trident を使用して提供されます。 Trident は Kubernetes/OpenShift に対応する External Storage Provisioner です。NFSエクスポートや iSCSI LUN などのストレージリソースを動的に作成し、アプリケーションによって指定された StorgeClass に設定されている要求を満たしたストレージリソースを作成し、提供します。 アプリケーションは、基盤となるストレージインフラストラクチャを気にすることなく、 Kubernetes クラスタ内のホスト間で Pod をシームレスに拡張し、展開でき、 必要なときに、必要な場所でストレージリソースを利用できます。
Trident は Storage Dynamic Provisioner として NetApp ストレージと StorageClass をマッピングすることで個々のアプリケーションに最適なストレージを提供することができます。
Trident の概念図
Trident を使用することで NetApp ストレージポートフォリオ全体に対して動的にボリュームを作成し個々の Pod (コンテナ化されたアプリケーション郡）に対して PV を割り当てることが可能となりました。
現時点( 2017/09 )で Trident は Kubernetes と OpenShift に対応しています。
NetApp で実現可能なこと
ここまでは機能的な説明をしました。ここからは NetApp を選択した場合どのようなメリットがあるかをお伝えします。
大きく ２ つの価値を提供できます。
消費型のインフラの実現
この記事の最初にも記載したとおり消費型のインフラをつくる、 PaaS のように開発者にワンクリックで環境を作成し提供するような場合に必須となる機能を実現することができます。
コンテナを活用した開発インフラを検討する際にはおそらく OpenShift や k8s をベースにすることを考えるでしょう。その時にストレージのプロビジョニングは動的にできワークロードに応じたストレージリソースをプロビジョニングする必要があります。ストレージオーケストレータである trideht を使うことで上記のことを実現することができます。
マルチクラウド運用の実現
NetApp が提唱しているデータファブリックのアーキテクチャの中でデータを管理し、データモビリティを実現することができるようになります。
例えば StorageClass のマッピング先として ONTAP を選択すると、データ管理については、あるときはオンプレミス上の ONTAP にデータを保管、コンテナのワークロードを AWS へ移行したくなった場合は AWS 上で稼働する ONTAP Cloud for AWS をデプロイしデータを非同期転送することで同じ環境、同じデータでアプリケーションを再開することができるようになります。
コンテナ化されたアプリケーションと同時にデータをシームレスに環境間を移動させることができるようになります。
アプリケーションのモビリティはコンテナを使用して実現し、データのモビリティは NetApp のデータファブリックの概念を使用し任意の場所にデータを移動することが可能となり、いつでもアプリケーションを稼働することが可能です。
ユーザは必要なタイミングでワークロードを最適な環境へ場所に移動できるようになります。
NetApp のテクノロジーでデータプラットフォームを作成することでオンプレミスやクラウドといった環境を考慮せずともそのときに最適なプラットフォームを選択できるようになります。
