IBM Storage

意外と知られていないコンテナ環境でのストレージの役割

2021-02-09

カテゴリー IBM Storage | Software Defined Storage

記事をシェアする:

マルチクラウドでアプリケーションを運用する基盤としてコンテナ環境が注目されていますが、ストレージのことを決して忘れてはなりません。実はコンテナ環境は、オンプレミスの仮想化環境のような手厚い保護は行われていないのです。コンテナ環境におけるストレージの基礎を解説するとともに、Red Hat OpenShiftに対応したソフトウェア・ストレージのソリューションをご紹介します。

田中裕之
日本アイ・ビー・エム株式会社システム事業本部ソリューション事業部　ハイブリッドクラウド＆ AIストレージセンター　ITスペシャリスト

入社2年目からLinuxのチームに入り、その後も15年以上にわたり、オープンソースやクラウドの先端テクノロジーに携わってきた。現在はストレージのテクニカル・セールスとしてSDS（Software Defined Storage）を中心に活動しているが、KubernetesやOpenShiftをキーワードとする案件ではまっさきに声がかかるクラウド・インフラの専門家である。

従来の仮想化環境とは大きく異なるコンテナ環境こそ、ストレージが重要という事実

コンテナ環境でもストレージが必要になることはご存知でしょうか。コンテナというとどうしてもマルチクラウド環境におけるアプリケーションの話になりがちで、インフラのことを置き去りにしたまま話が進むとことが少なくありません。

コンテナ環境とストレージの関係を理解するために、まず通常の仮想化環境とコンテナ環境の違いをきちんと押さえておく必要があります。

オンプレミスのITインフラで広く利用されている現在の仮想化環境は、非常に手厚い可用性が担保されています。例えばホストが落ちた場合、その上で稼働していたVM（仮想マシン）はハイパーバイザーの機能によって別のホストに移して立ち上げられ、そのまま業務が引き継がれて稼働を再開します。さらにダウンタイムを短縮するために、あらかじめHAクラスター構成を採用している企業も多いのではないでしょうか。

これに対してコンテナ環境は、そうした業務レベルでの可用性は配慮されていません。クラウドネイティブの思想が根底にあり、障害が発生した場合でも基本的にサービス全体が止まらなければOKとする仕組みとなっています。
コンテナを動かしていたホストが落ちた場合、そのコンテナを別のホストで立ち上げることは可能ですが、IPアドレスが異なり、何もしなければデータも引き継がれません。以前のことはまったく関知せず、新たにコンテナを立ち上げるという感覚です。

もちろんデータなしでは業務継続に支障をきたしてしまうアプリケーションもあります。そこで用意されているのが永続ストレージと呼ばれる仕組みで、コンテナの外に別建てのストレージを置くことでアプリケーションのデータを保護することが可能となります。

このようにコンテナ環境とストレージは、切っても切り離せない不可分の関係にあるのです。したがって新たにコンテナ環境を構築する際には、アプリケーションの動作を確認するだけでなく、その後の運用まで見据えて、あらかじめストレージも含めたインフラ構成で検証を行っておくことが肝要です。

ストレージの要件を決めるのが難しいアプリケーションにも柔軟に対応

では、コンテナ環境に対してどんなストレージを用意すればよいのかという話になりますが、IBMではあらゆるコンテナ化アプリケーションの要件に対応するストレージ・オファリングとして、Red Hat OpenShiftに対応したストレージ・ソフトウェアのバンドル製品であるIBM Storage Suite for IBM Cloud Paksを用意しています。IBMとRed Hatのストレージソリューションを同時に利用できるところが一番の特長となります。

具体的にはIBM Spectrum Scale、IBM Cloud Object Storage、IBM Spectrum Discover、IBM Spectrum Virtualize for Public Cloud、Red Hat Ceph Storage、Red Hat Container StorageといったIBMとRed Hatの計6種類のストレージ・ソフトウェアを、自由に組み合わせて利用することができます。

なお、先ほどアプリケーションのデータを保護するために永続ストレージが必要になると述べましたが、実はもう１つ必要なストレージがあります。OpenShift自体がコンテナの集まりであり、そのログや統計情報を保管する目的でもストレージが必要です。要するにこの2パターンでストレージを利用することになります。

とはいえ、いざ検証しようと思っても、最初からストレージの要件を決めるのは困難なのが現実です。アプリケーションの担当者にどんなストレージが必要なのかと尋ねても、「今の時点で聞かれてもわからない」、「アプリケーションを作り始めたばかりで要件が変わるかもしれない」といった返事ばかりで、なかなか話は前に進みません。

そうした場面で役立つのが、前述のIBMとRed Hatの6種類のストレージ・ソフトウェアというわけです。これによりブロック・ストレージ、ファイル・ストレージ、オブジェクト・ストレージのいずれのタイプのストレージも提供することができます。また、クラウドにインストールするもの、オンプレミスにインストールするもの、さらにその両方の環境で動かせるものもあり、この6つのソフトウェア・ストレージの組み合わせで、ほとんどのアプリケーションの要件に応えることができるのです。また、検証から本番運用に移行した後にアプリケーションの要件が変わった場合も、それにあわせてソフトウェア・ストレージの組み合わせや配分を変更することも可能です。

将来が予測できないコンテナ環境にもスムーズに対応できる、非常に柔軟なソフトウェア・ストレージのソリューション群として自信をもっておすすめします。