IBM Storage
意外と知られていないコンテナ環境でのストレージの役割
2021-02-09
カテゴリー IBM Storage | Software Defined Storage
記事をシェアする:
マルチクラウドでアプリケーションを運用する基盤としてコンテナ環境が注目されていますが、ストレージのことを決して忘れてはなりません。実はコンテナ環境は、オンプレミスの仮想化環境のような手厚い保護は行われていないのです。コンテナ環境におけるストレージの基礎を解説するとともに、Red Hat OpenShiftに対応したソフトウェア・ストレージのソリューションをご紹介します。
![田中 裕之](https://www.ibm.com/blogs/systems/jp-ja/wp-content/uploads/sites/8/2020/10/Profile_Tanaka01.jpg)
田中 裕之
日本アイ・ビー・エム株式会社 システム事業本部 ソリューション事業部 ハイブリッドクラウド & 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種類のストレージ・ソフトウェアを、自由に組み合わせて利用することができます。
なお、先ほどアプリケーションのデータを保護するために永続ストレージが必要になると述べましたが、実はもう1つ必要なストレージがあります。OpenShift自体がコンテナの集まりであり、そのログや統計情報を保管する目的でもストレージが必要です。要するにこの2パターンでストレージを利用することになります。
とはいえ、いざ検証しようと思っても、最初からストレージの要件を決めるのは困難なのが現実です。アプリケーションの担当者にどんなストレージが必要なのかと尋ねても、「今の時点で聞かれてもわからない」、「アプリケーションを作り始めたばかりで要件が変わるかもしれない」といった返事ばかりで、なかなか話は前に進みません。
そうした場面で役立つのが、前述のIBMとRed Hatの6種類のストレージ・ソフトウェアというわけです。これによりブロック・ストレージ、ファイル・ストレージ、オブジェクト・ストレージのいずれのタイプのストレージも提供することができます。また、クラウドにインストールするもの、オンプレミスにインストールするもの、さらにその両方の環境で動かせるものもあり、この6つのソフトウェア・ストレージの組み合わせで、ほとんどのアプリケーションの要件に応えることができるのです。また、検証から本番運用に移行した後にアプリケーションの要件が変わった場合も、それにあわせてソフトウェア・ストレージの組み合わせや配分を変更することも可能です。
将来が予測できないコンテナ環境にもスムーズに対応できる、非常に柔軟なソフトウェア・ストレージのソリューション群として自信をもっておすすめします。
さらに詳しい資料を読む
IDC Japanレポート: IBMのハイブリッドクラウド向けストレージソリューションの価値を考察する
関連情報
Qiskit SDK v1.2がリリースされました!
主な新機能の最新情報や非推奨となった機能、Qiskitを世界で最も高性能な量子SDKとし続けるために進めている取り組みを含めて、Qiskit SDK v1.2のリリースの技術的要点をご紹介します。 2024年8月21日に […]
IBM Z 移行の勘所 – お役立ちブログ情報編
IBM Z をご愛顧いただいているお客様、また IBM Z の導入、展開、移行に際しお世話になっておりますビジネスパートナー向けに、このたび、IBM Systems Japan Blog に IBM Z 移行に関するお役 […]
未来のコンピューティングを具現化する IBM Researchのラボ
ニューヨークから 1 時間ほど北にあるラボには、世界で最も先進的な量子コンピューターと、革新的なプロトタイプ AI チップのクラスターがあります。IBM Researchの本拠地である Thomas J. Watson […]