2020年06月

29

OpenShiftに代表されるコンテナ環境へのIBMストレージの対応

IBMの岡田です。前回の「全包囲網。。。最新 IBMストレージ 概要」はいかがでしたか?

今回は、今流行りのコンテナ環境とIBMのストレージがどのようにこれらの環境に対応しているのかに触れてみたいと思います。

 

コンテナって何?

ある調査によると、クラウドファーストを掲げて次々とクラウド環境に IT を移していくといった流れは世界中の ITワークロードの5分の1ほど移ったところで一段落していると言われています。今日では従来型IT環境、仮想化環境、プライベートクラウド環境などのオンプレミス環境と、複数から成るパブリッククラウド環境を上手く使い分ける時代に入ってきたという人もいます。

何れにせよ、今後の IT はこう言った環境の種類に依存することなく、適材適所かつ必要に応じていかなる環境でも同じようにアプリケーション開発や検証ができ、完成されたアプリケーションをどこでも同じように作動させることができ、場合によってはそれぞれの環境で連携して動くと言った技術が必要になってきます。

この要求に応えることができるのがコンテナ技術です。

図1. 仮想環境とコンテナの比較

 

コンテナのメリット

図2.コンテナを使うことのメリット

どうしてコンテナ技術を用いるとこれらの要求を解決することができるのでしょうか?

それはコンテナ技術を用いることで、動かすべき対象つまりアプリケーションと、動かすための環境つまりインフラストラクチャーを明確に分けることができ、前者は同じコンテナ基盤であればどこでも同じように動かすことができ、後者はどんなプラットフォームでもこのコンテナ基盤を使えばどこでも同じ動作環境をアプリケーションに提供することができるからです。
別の見方をすると、従来型IT環境では機能要件と非機能要件を分けて考えることが時には困難な場合もありましたが、コンテナ環境ではこれらを明確に分けることができるわけです(図3参照)。

図3. 従来型IT環境とコンテナ環境での考え方の違い

 

Red Hat OpenShift について

このようなコンテナですが、その方式はいくつか存在し、ここ数年いろいろな方々が実際に触っていくうちに自然と多くの人に使われるものが絞られてきました。
また、その周りを司る管理機能についてもやはり幾つかの方式からここに至ってある程度代表的なものに絞られてきました。いわゆるデファクトという呼び方をしたりするものですが、恐らく現在デファクトのコンテナ用オーケストレーターと言えるものは Kubernetes ではないでしょうか?

この Kubernetes についての詳しい話はネット上にも沢山出てくると思いますので、ここではこれ以上触れません。
ちなみに最近はよくこの Kubernetes を “K8s” と書くことがあります。この K8s の “8” は Kubernetes の頭の “K” と最後の “s” に挟まれた “ubernete” の8文字を表しています。
Ruby 関連で i18n が internationalization を指すのと同じことです。そもそも IT の根本は如何にシステムを使って楽するかという怠け者の発想ですのでこんな略し方もわかる気がしますね。
(以下このブログでは、”Kubernetes” を “K8s” と表記します。)

さて本題に戻ります。
K8s 環境は実際にちゃんと作ろうとすると、周辺機能を選びつつ構築していくことが必要となります。
またこれらは通常 OSS で組むこととなるため、ミッションクリティカルな環境への適用は、何かあった際のクイックなサポート等の面から非常に難しくなります。

Red Hat OpenShift は、K8s を中心に置き、必要な周辺モジュールを全てパッケージ化した上で評価を完了させてある商用パッケージです。
そのため、要らぬところに労力を割くことなく、正しい K8s環境を短時間で構築することができます。しかも、商用であるがゆえに保守等もちゃんと付いています。

図4.OpenShift について

IBM はこの OpenShift をベースに各用途向けにコンテナ化された IBMソフトウェアを搭載し、パッケージ化した6つの IBM Cloud Pak というソリューションを提供しています。
(※詳しくは「製品・ソリューション/ソフトウェア」内で紹介されている、各種 IBM Cloud Pak をご参照ください。)

 

コンテナ環境下でのストレージのあり方

コンテナのメリットは先程ご説明しましたが、その中でも特にポータビリティという点は十分に考えられたソリューションです。

しかし、果たしてそれだけで十分でしょうか?

アプリケーションの作りにもよりますが、普通にコンテナ内のストレージを使いアプリケーションを動かすと、コンテナが不要となり消し去った際データも一緒に消えてしまいます。
複数のコンテナを並列に動かすような作りの場合にはデータを連携する必要があるかもしれません。

図5.永続ストレージの必要性

つまり、コンテナから独立したデータの器が必要となります。
これが永続ストレージというものです(図5参照)。

最近の IT の記述書などでよく “PV” という文字を見かけます。それは “Persistent Volume” の略であり、永続ストレージはその PV を使って定義づけられます。

では、永続ストレージにはどのような接続形態があるのでしょうか?

 

永続ストレージの接続形態

図6で示す通り、永続ストレージにはいくつかの形態があります。ちなみに一番左は通常のコンテナでのストレージのあり方で、この方法だとコンテナと共にデータは消えることとなります。

図6. K8s 環境でのストレージのあり方

ノード内の永続ストレージという点では OpenShift においては Red Hat OpenShift Container Storage が使われます。こちらはノード依存性がありますので複数ノードにまたがって連携することはできません。

それに対し、外部にストレージを保つ方法があります。ソフトウェア・デファインド・ストレージかハードウェア製品かに関わらず、K8s ノード外にあるストレージを使うため、仮にノードごとに何らかの理由で停止するようなことがあってもデータはキープされます。
(※どのような製品が対応可能かは後ほど触れます。)

これらの接続方法は、実は K8s のバージョンによって変わってきます。
ここでは K8s を包含した OpenShift のバージョンでお話しします。

図7. OpenShift のバージョンによる接続方法の違い

 

CSI

CSI とは Container Storage Interface の略です。K8s のストレージはこうあるべきという考えに基づき、K8s とは独立にプロトコルを標準化したものです。

よって、CSI を使うことで K8s ユーザーはストレージのメーカーや製品を意識することなく同じに使うことができるようになります。逆に言うと各メーカーの優位性を出すことが難しくなります。
とは言え、IBMストレージとしては後述の通りハードウェア製品とソフトウェア・デファインド・ストレージ製品との連携でより便利に使うことが可能です。

 

IBM のストレージ対応

さて、ここまではどちらかと言うとコンテナ側のお話をしてきましたが、いよいよ IBM のストレージの対応についてお話していきましょう。

 

ブロックストレージ編

図8. IBM のブロックストレージの CSI 対応状況

IBM FlashSystem は、IBMストレージのブロックストレージにあたります。

FlashSystem はいち早く CSI にも対応しています。
もちろん FlashSystem 同様 IBM Spectrum Virtualize ファミリーのアプライアンス製品 SAN Volume Controller も、ソフトウェア・デファインド・ストレージとしてクラウド上にポーティング済みの IBM Spectrum Virtualize for Public Cloud も、対応済みです。

オンプレミスとパブリック・クラウド間でのデータ連携も永続ストレージ間で実施できるため、コンテナ上のアプリのポータビリティをオンプレミスとパブリック・クラウドの間でデータも含めて実現することができます。
実際、図2で示したコンテナのメリットは、ちゃんと永続ストレージを使ってどのプラットフォーム上でもできないと完璧にこなすことはできません。これが IBM のコンテナ対応のバリューです。

当然のことながら、フラグシップであるところの DS8000シリーズも CSI 対応済みです。

 

ファイルストレージ編

次にファイルストレージについて見てみましょう。

図9. IBM のファイルストレージの CSI 対応状況

IBMのファイルストレージと言えば、IBM Spectrum Scale というソフトウェア・デファインド・ストレージ製品ですが、アプライアンス製品として IBM Elastic Storage Server という製品があります。(第一回目のブログでもご紹介しましたね。)
この ESS についても CSI 対応済みということになります。

こちらも IBM Spectrum Scale の機能を使ってプラットフォーム間でデータを連携することができます(Active File Management 機能は後日別の回での解説を予定しています)。

IBM Spectrum Scale を用いると、ある面白いこともできます。
これも詳しくは後日解説しますが、少しだけお話すると、IBM Spectrum Scale は NAS、オブジェクトストレージを含むマルチプロトコル対応です。CSI で静的プロビジョニングを用いてコンテナからアクセスできるようにすると、既存で NAS 等で使っているボリュームを見せることも可能となります。
さらに IBM Spectrum Scale は Unified Access という機能で同じファイルを NAS としてもオブジェクト・ストレージとしても共有できる機能があるため、コンテナでも同一ファイルを使うことが可能となり、実質的に従来型IT とコンテナとの間でもデータが連携できることになります。

従来型のシステムとコンテナのアプリ間でデータ連携できることのメリットは、まさに最初に述べた環境を用途などで使い分ける現在の IT環境には無くてはならない機能です。
これも IBMストレージの大きなメリットです。

ハードウェア製品、アプライアンス製品、ソフトウェア製品を通じてブロックストレージ、ファイルストレージ共に IBM はコンテナ対応済みであると言えます。

 

オブジェクト・ストレージ編

オブジェクト・ストレージは基本的に RESTful API による HTTP 接続が使われます。
よってコンテナに限ったことではありませんが、ブロックやファイルストレージとは異なり、独自ドライバや CSI を介する必要はなく、アプリケーションから直接 I/O することが可能です。

IBM は IBM Cloud Object Storage というソフトウェア・デファインド・ストレージを扱っています。
また IBM Spectrum Scale もオブジェクト・ストレージとして使用可能です。

オブジェクト・ストレージについては AI&Bigデータの回で詳しくお話することにしましょう。

 

ソフトウェア・デファインド・ストレージのもう一つの対応

図10. IBM Storage Suite for IBM Cloud Paks

現在取り扱っているコンテナ対応済みソフトウェア・デファインド・ストレージを取りまとめて、IBM Storage Suite for IBM Cloud Paks という名前で IBM Cloud Paks 向けに提供を始めました。

ここには IBM の前述のソフトウェア・デファインド・ストレージ製品3つと、メタデータ、タグマネージメントといった機能を持った IBM Spectrum Discover、それに Red Hat OpenShift でネイティブなRed Hat OpenShift Container Storage と根強いファンの多い Red Hat Ceph Storage を加えた6つをワンパッケージにしました。

この Suite 製品の面白いところは、OCS(Red Hat OpenShift Container Storage)の契約 VPC数(契約対象の仮想プロセッサコア数)に応じた容量分を自由に何種類でも組合わせて使うことができるというところです(もちろん単体で全容量使うのもありです)。

この手のコンテナ環境・クラウド環境でストレージを使うことは、はじめは何をどのくらい使うべきかわかっていない状況だったりするものです。特にアジャイル、アジャイルと言われる昨今、「とにかくやってみよう」という傾向が強いのも事実です。
そんな時にこのパッケージを使うと、容量を超えない限りどのストレージをいくら使っても自由ですので、使ってみて決めていくということができます。

まさに現在のクラウド時代にふさわしいストレージパッケージと言えるでしょう。

 

今回のまとめ

ここまで見てきた通り、IBM のストレージ製品は2020年7月現在取り扱っているものとしてはブロック、ファイル、オブジェクト・ストレージであり、これらすべてコンテナ対応が完了しています。

図11. IBMストレージの OpenShift 対応状況

Red Hat OpenShift あるいは各種 IBM Cloud Pak においては、接続性も含めて検証済みであり安全にお使いいただけます。

もしコンテナ環境をご検討中であれば、ハードウェアもクラウド上のソフトウェア・デファインド・ストレージもあり上下のデータ連携が可能な IBM のストレージ製品を、ぜひご活用ください!

 

お読みいただきまして、ありがとうございます。
次回はハイブリッド・クラウド、マルチ・クラウドに適切なストレージについてお話する予定です。お楽しみに!

 

 

この記事に関するお問合せ

エヌアイシー・パートナーズ株式会社
企画本部 事業企画部

この記事に関するお問い合せは、「こちら」からお願いします。

 

参考ページ

 

その他の記事

2022年06月24日

【早わかり】AIX と IBM i ライセンス情報

こんにちは。エヌアイシー・パートナーズ 村上です。 2022年度は新しい試みとして、 ・理解しているつもりだけど説明はできない ・時間があれば調べたいと思っていた ・当たり前な知識かもしれなくて質問しにくい という内容を取り上げた「早わかりシリーズ」を掲載していきます。 今回は、IBM Power のメインOS、AIX と IBM i のライセンス情報をご紹介します。 AIX とIBM i は、片方のライセンス情報しか知らないという方も意外と多いので、ぜひこの機会に比較しながら読んでみてくださいね。   セクション 1) 永続ライセンスのおさらい 2) マンスリーとサブスクリプションをご存じですか? 3) ライフサイクルとバージョンのポイント   1) 永続ライセンスのおさらい AIX とIBM i のスタンダードなライセンス「永続ライセンス」。 有効期限のない永続ライセンスは、SWMA (SoftWare MAintenance) と合わせて所有します。 永続ライセンス OSを利用できる権利。1年目に購入。 SWMA 「サブスクリプション(最新バージョンへのアップグレード)」と「テクニカルサポート(対象製品に対するQAサポート)」の権利。 1年~5年で選択し、継続するためには都度オーダーが必要。 更改などで新ハードウェアへ移行する場合、 AIX 永続ライセンスはIBM Power本体に紐づくので、新ハードウェアになるタイミングで永続ライセンスが買い直しになります IBM i 既存機のライセンスを新ハードウェア移管することが可能です(移行先の機械レベルが高くなる場合は追加料金が発生) IBM i には、移行中ライセンスとして安価なITL(IBM Temporary License)が提供されたり、DR機専用のライセンスがあったりもします。   2) マンスリーとサブスクリプションをご存じですか? さて、このセクションが今回のブログの本題です。 2022年6月現在、AIX とIBM i には「永続」「マンスリー」「サブスクリプション」と3種類のライセンスがあります。 以下は利用ケースのイメージです。 利用ケース 永続ライセンス ・長期間利用 マンスリーラインセンス ・移行時の短期利用 ・スパイク(最低限の環境をさっと作って概ねの方向性を確認する) サブスクリプションライセンス ・初期投資を抑えたい場合に利用 ・HWに依存せず臨機応変に利用(中長期間でAIXの場合) サブスクリプションライセンスは、AIX は2021年、IBM i は2022年に提供が開始されました。 (表が見えにくいのでクリックして拡大してご覧ください) サブスクリプションライセンスは、今後拡張が予定されています。 利用ケースにあったライセンスを選択できるようになってきたので、臨機応変な検討ができるようになりますね。   3) ライフサイクルとバージョンのポイント 2022年6月時点で、IBMは「AIX も IBM i も将来の投資を継続する」という発表をしています。 IBM Power ユーザとしては一安心です。 どちらのOSも、サポートライフサイクルは10年間となります。 下記にバージョンのポイントを纏めてみました。 <AIX > 購入できるバージョン v7.2 , v7.3 標準サポートがあるバージョン v7.1, v7.2, v7.3 どうやってもサポートが終わっているバージョン v5.3 実はまだ有償延長サポートがあるバージョン v6.1 TLが出るタイミング(※) 1回/年、成熟してくると1回/2年 サポートライフサイクル(10年) 標準(最短6年)+延長保守(3~5年) <IBM i > 購入できるバージョン v7.3 , v7.4, v7.5 標準サポートがあるバージョン v7.3, v7.4, v7.5 どうやってもサポートが終わっているバージョン v6.1 実はまだ有償延長サポートがあるバージョン v7.1, v7.2 TRが出るタイミング(※) 2回/年(最新バージョンと1世代前のバージョンに対して) サポートライフサイクル(10年) 標準(7年)+延長保守(3年) <※TLとTRの補足> TL:テクノロジー・レベル。AIXにおける問題の修正、新しいハードウェアのサポート、ソフトウェアの機能拡張が含まれたプログラム。 TR:テクノロジー・リフレッシュ。IBM i におけるオファリング、サービス、およびハードウェアの機能拡張を提供するプログラム。 かなり前のバージョンも、延長保守のサポートがあるため更改時も安心です。 ただ、延長保守サポートは、部品不足による急な保守終了や、新規の問い合わせに対応いただけない、という面があるので要注意です。 また、延長保守サポートには細かい前提が設けられており前提にも随時変更が入りますので、ご利用を検討される際はお問い合わせください。   さいごに つい先日(2022年6月)、IBM i の複数のソフトウェアラインセンスが無償化される発表(IBM PartnerWorld)がありました。 IBM i では更改の検討が始まると、実際に利用している有償ソフトウェアの見直しが入ったりして、見積もりに時間がかかることがありますよね。 有償ライセンスが減ったことで、見積もりが少しでも簡単になり助かります。 クラウドシフトが進む中で、ライセンス体系、課金、監査方法が複雑化しています。 弊社には毎日のようにパートナー様からライセンス関連の相談やお問い合わせが来ています。 OSのみではなく、あらゆるソフトウェアのライセンス情報収集に日々奮闘(?)しているSEが多数おりますので、お困りの際はお気軽にご連絡ください! ※ 本ブログの情報は時間経過とともに変更が入る可能性があります。   お問い合わせ この記事に関する、ご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社 E-Mail:voice_partners@niandc.co.jp  

back to top