Dockerで外部ストレージを使った永続ストレージを実現する方法Dockerで永続ストレージ(後編)

外部ストレージのデータをDockerのコンテナから利用したいこともある。外部ストレージ利用には賛否両論あるが、それでも利用したい場合はどうすればよいのか。

» 2018年03月07日 10時00分 公開
[Chris EvansComputer Weekly]
Computer Weekly

 前編(Computer Weekly日本語版 2月21日号掲載)では、Dockerで永続ストレージを実現するための方法と、その選択のために検討すべき要件について解説した。

 後編では、外部ストレージを使う方法について検討する。

Computer Weekly日本語版 3月7日号無料ダウンロード

本記事は、プレミアムコンテンツ「Computer Weekly日本語版 3月7日号」(PDF)掲載記事の抄訳版です。本記事の全文は、同プレミアムコンテンツで読むことができます。

なお、同コンテンツのEPUB版およびKindle(MOBI)版も提供しています。

ボタンボタン

Dockerボリュームのプラグイン

 外部のストレージアレイに格納されているデータを使いたい場合はどうなるのか。

 共有ストレージを使用すると、ホストで障害が発生しても、それを切り抜けられるようになる。コンテナのコンテキストで、共有ストレージを使用する場合は多少の作業が必要だ。この技法を使うには、共有ストレージプラットフォームの開発をどこから着手すべきか、理解しておかなければならないからだ。

 従来のSAN(ストレージエリアネットワーク)は、多数の物理サーバに分散したストレージを集約する必要性から考案された仕組みだった。1つに集約することで、管理、セキュリティ、保守、効率性が向上した。例えば、共有アレイの物理LUNまたはボリュームは、ホスト内の物理アダプターにマッピングされ、マスクされる。

 仮想化への移行に伴い、ストレージはハイパーバイザーにマッピングされ、LUNやボリュームはハイパーバイザーで分割されるようになった。例えば物理LUNは、「VMware vSphere」ではデータストアとなる。通常、そのデータストア内で各仮想マシンのディスクはVMDKファイルだ。NASのファイル共有では、こうしたディレクトリ内にVMディレクトリとVMDKファイルを格納するようになるだろう。

 コンテナの観点から見ると、物理ホストにマッピングされたストレージは、ブロックデバイスのように見える。つまり、そのストレージはファイルシステムでフォーマットしなければならない。このファイルシステムをコンテナにマウントすることで、永続的なストレージが提供される。

 しかしこうした一連の手続きはどう見ても扱いにくい。そのため、プロセスをより効果的に管理するためにDockerはボリュームプラグインを導入した。サプライヤーは、Dockerの仕様に対応するプラグインソフトウェアを開発している。その仕様とは、LUNまたはボリュームの作成プロセスを自動化し、ホストおよび最終的にはコンテナに正しくマッピングするためのものだ。

外部ストレージに関する賛否両論

 外部ストレージを使用すると、当然ながらレジリエンスと永続性という利点を享受することになる。コンテナを廃棄しても、ボリュームを再接続することができる。ホストを廃止する場合は、LUNまたはボリュームを移動させて、別のホストにマウントすることができる。パフォーマンスは、システムがQoS(Quality of Service)などの機能を提供するLUNレベルで判断することになる。

 セキュリティの実装は、もう少し慎重な対応が必要だ。特定のコンテナホストに外部ボリュームをマッピングすることはできる。ただし、ホストやコンテナのオーケストレーションソフトウェアが提供しているものを除けば、ボリュームをコンテナに割り当てる際にセキュリティを確保できる仕組みは、ストレージには備わっていない。従って、KubernetesやSwarmを正しく割り当てなければならない。

 サプライヤーのサポートは、Dockerプラグインの形で提供される。ストレージアレイの主要サプライヤーの大半は、プラグインを提供している。具体的に挙げると、Pure Storage、NetApp、HPE(3PARおよびNimbleブランド)、EMC(オープンソースプロジェクトとして運営している「REX-Ray」および「{code}」を通して)が該当する。

 また、PortworxやStorageOSなど、新興企業が手掛けるプラグインもある。これらにはコンテナストレージに特化した設計のプラットフォームが備わっている。Red Hatなど、プラットフォームのサプライヤーは、汎用(はんよう)分散ファイルシステムである「GlusterFS」を通じてサポートを提供している。

 さらには、ローカルストレージとNFSリソースへのアクセスを提供する、サードパーティーのプラグインも存在する。Dockerプラグインのページには、こうしたサードパーティーのリストも掲載されている。ただしこのリストの更新はそう頻繁ではない。

 Kubernetesはコンテナを展開する際の標準になりつつある。Kubernetesのエコシステムは、Dockerに縛られる必要のないボリュームのサポートを提供するものだ。Kubernetesボリュームは「pod」が存続している間、ずっと存在する。なおpodとは、アプリケーションを記述するために使用される、複数のコンテナをグループとしてまとめたものを指す。

 現在、Kubernetesのボリュームサポートには、汎用のNFS、iSCSI、ファイバーチャネルのサポートが含まれている。また、「Microsoft Azure」など特定のクラウドに特化したサポートや、Portworx、ScaleIO、GlusterFS、StorageOSなどに対する特定サプライヤーのサポートもある。

まとめ

 ほとんどの外部ストレージサポートはボリュームベースであり、データをオンプレミスからクラウドへ移す機能を直接担っているわけではない。

 Dockerでデータを永続化するために使用される、グローバルなファイルシステムが増えているため、関連製品の機能の向上が期待される。

 要件が成熟し、採用されるファイルシステムが増えれば、ブロックデバイスは短期的なソリューションとなるだろう。

別冊Computer Weekly “なんちゃってOffice”よりもOffice 365も公開中!

Microsoft Officeの代替製品は数あれど、やはりMicrosoft Office の地位は揺るがない。そして、Office 365はOffice 20xxの単なるクラウド版以上の価値を提供する。


Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ