特集・ブログ
IBMの岡田です。 前回の「OpenShiftに代表されるコンテナ環境へのIBMストレージの対応」でも触れた通り、ここ数年の傾向として何でもかんでもクラウドに移行するという時代は過ぎ、従来型の IT インフラとクラウド環境とを上手く使い分け、あるいは連携しながら、目的の業務アプリケーションを動かしていく方向になりつつあります。いわゆるハイブリッドクラウドというものです。 そして、パブリッククラウド自体もそれぞれのサービスにより使い分ける風潮があり、今やパブリッククラウド・ユーザー企業の半分以上が、複数のパブリッククラウドを使っているのではないかと思われます。いわゆるマルチクラウドと呼べるものですね。 しかし、なかなか統合的に管理するというところにまでは至っておらず、クラウドを含めたサイロ化が起こっている状況です。 このような運用ではアプリケーションの適材適所はおろか、データさえ十分に使えていないことは明白です。 今回はこのようなハイブリッド/マルチクラウドの状況の中でデータを上手く連携し活用していくために、IBMのストレージにできるソリューションを紹介しましょう。 ハイブリッド/マルチクラウドの位置づけ 以下の図は、ハイブリッドクラウド、マルチクラウドを模式的に表したものです。 オンプレ環境のプライベートクラウドまで含んでマルチクラウドという人もいますし、従来型の物理サーバーや仮想化された VM 環境もハイブリッドクラウドのオンプレミス部分の一部と考える人もいます。人によっても会社によっても捉え方は色々ですが、ここでは敢えて従来型 IT もハイブリッドクラウドの一部として話をしたいと思います。 図1. ハイブリッドクラウドとマルチクラウド IBM Spectrum Virtualize for Public Cloud とは！？ IBM Spectrum Virtualize for Public Cloud（SV4PC）は、第一回目、第二回目のブログでも登場した IBM のメインストリームとなるブロックストレージ、FlashSystem にも搭載されている管理機能ソフトウェア、これをパブリッククラウドでも使えるようしたものです。 つまり、SV4PC はハイブリッドクラウドやマルチクラウドに対応したストレージ製品です。 SV4PC を知れば FlashSystem を知ることができますので、SV4PC の機能を紐解いていきましょう。 外部仮想化機能 2003年、この Spectrum Virtualize ファミリーの元となる製品が生まれました。SAN Volume Controller、通称 SVC です。 今でもこの製品は最新のテクノロジーを装備してファミリーの一員です。（IBM Spectrum Virtualize for Public Cloud も Spectrum Virtualize ファミリー製品です。） そこから脈々と受け継がれた外部仮想化という機能は、IBM および他社ストレージ製品約500種類を配下に接続可能で、これを仮想化して自身のストレージとして扱うことができるものです。 図2 外部仮想化機能 もちろん、既存で使われているストレージのボリュームや保存されたデータを生かしたまま配下に収めることができるため、オンライン・データ移行はもちろん、コピーサービス（スナップショット等の機能）を持たないストレージにそういった機能を与える事もできます。 この機能を使う事で、FlashSystem では他社製品を含めた古い製品から簡単に最新のテクノロジーにデータを引っ越すことが可能です。 パブリッククラウド上では、SV4PCがプロバイダーが提供する基本的な機能しか持たないブロックストレージを配下に置くことができます。 これにより、最新のデータ削減機能の他、ブロックレベル自動階層化のEasy Tier（補足参照）、FlashCopyや筐体間コピーを含むコピーサービス（補足参照）、といったテクノロジーも使用可能となるわけです。 図3. データ移行のイメージ 様々なデータ削減機能 FlashSystem 5010 を除く Spectrum Virtualize ファミリーには、いくつかのデータ削減機能があります。 これらは DRP（Data Reduction Pool）というデータ削減にはなくてはならない機能を実装した Spectrum Virtualize ファミリー特有のストレージプール上で実現されます。また DRP での各処理単位はフラッシュ系デバイスに最適化されています。 図4.Data Reduction Pool 具体的には「リアルタイムデータ圧縮機能」「重複排除機能」「シン・プロビジョニング機能」がサポートされています（一部組合せによりサポートできないデバイスがあります）。 ※詳しくは補足をご覧ください。 Spectrum Virtualizeファミリーのハイブリッドクラウド/マルチクラウド対応 触れてきた通り IBM の Spectrum Virtualize ファミリーであれば、オンプレミスの FlashSystem あるいは SVC とパブリッククラウド上の SV4PC とでデータ連携できるので、データの観点でハイブリッドクラウド対応ができます。 また、パブリッククラウド同士でデータ連携することもそれぞれに SV4PC を置くことで可能となり、マルチクラウド対応もできます（2020年7月時点、IBM Cloud と AWS に対応）。 図5. ハイブリッド/マルチクラウドのデータ連携 さらにこの方法を使えば、他社の既存データも活かすことができます。外部仮想化機能が使えるからです。 つまり IBM の Spectrum Virtualize ファミリーを使うと、他社ストレージ製品も含めてハイブリッドクラウド対応できる事になります。 では、データをハイブリッド/マルチクラウド連携できると何が嬉しいのでしょうか。 ハイブリッドクラウド/マルチクラウドの利点 グローバルでは、一番広く使われているのが災害対策用途です。 被災時に本番環境が使えなくなった際も、パブリッククラウド側で仮想サーバー、コンテナなどを使い業務を継続できるからです。 今求められるデータ活用としては AI/アナリティクスなどと言うものもあります。 オンプレミスで使えるものもありますが、手軽にやろうとすると各パブリッククラウド上で提供している AI サービスを使うのが早いですね。最初に触れた通りサイロ化されたデータをパブリッククラウドと連携するにもハイブリッドクラウドは有効です。 バックアップ先としてパブリッククラウドを使うと、いらぬ投資をすることなく遠隔保管が可能となります。 通常テープを使った遠隔保管ですと保管場所である拠点、定期的な搬送といった固定費が発生します。最悪の場合、本番業務側が被災した場合にもデータをリストアしなければならないことを考えると、保管場所にリストアする仕組みが必要となります。これも大きな投資となるでしょう。 パブリッククラウドをバックアップ先とした場合それだけで遠隔保管が実現でき、必要な場合のみ仮想サーバーも立てることができるため DR としての役割も果たせるのです。 また、クラウドに業務を移行するというケースもまだまだ発生しますね。 この際クラウドプロバイダーが提供している方法もありますが、移行対象となるデータが多量にあると、なかなか与えられた方法を用いて計画通りに移行することは困難な場合があります。特にプロバイダーから送られたハードウェアを仲介して行う方法は、移行の間は業務を止めて対応する必要があります。これではビジネス的なインパクトが発生します。 ハイブリッドクラウド形態でのクラウド・オンプレミス間のデータ同期であれば業務を止めずに対応でき、万が一クラウドに移行したことで何らかの不具合を生じた場合にも即座に元の環境に戻すことができます。 これらの有益なハイブリッドクラウドのデータ連携にマルチクラウドのデータ連携要素が加わると、更に有益なことがあります。 最近の風潮としては、パブリッククラウド上にデータを置く場合でもミッションクリティカルなものの場合には、AZ（アベイラビリティーゾーン）を跨ってレプリケーションを取ることが一般的になってきています。冗長性を保つという意味では、異なるパブリッククラウドにコピーを持つことも有効でしょう。 このような用途にもマルチクラウド・データ連携は役に立ちます。 またメジャーなパブリッククラウドは、基本的にグローバル展開をしております。 自身で海外にサイトを立ち上げる必要なく、容易に海外展開できるといった利点や、国内でも東阪の災対環境も手軽に築くことも可能です。 図6. ハイブリッド/マルチクラウドで実現できるソリューション ハイブリッドクラウド・データ連携の具体例：クラウドへのデータ移行 パブリッククラウドに業務を移行する際に、ハイブリッドクラウドの接続形態を使うことで既存の業務を止めないオンラインデータ移行が可能です。（ただし既存ストレージの仮想化のための接続変更時は短時間ですが止める必要があります。） 図7. ハイブリッドクラウド活用例・クラウドへのデータ移行 オンプレミスとパブリッククラウド、あるいはパブリッククラウド同士でのレプリケーションは方向を変えることも可能ですので、もししばらく使ってみて移行先で業務がうまくいかないなどの不具合が生じた場合は、データをオンプレミス側に戻すことも可能です。 他の活用例も結局はこのレプリケーションを使って双方を連携させることによりますので、アイディア次第でお客様の用途に合わせて色々な活用方法が見つかるかもしれません。 クラウド上ではこんな使い方も SV4PC だけでも面白い使い方ができます。 多くのパブリッククラウドの環境下では、その環境内で使える仮想ブロックストレージが用意されています。 プロバイダーにもよりますが、大雑把に言ってしまえばクラウドは大規模な物理リソースを小出しにして使っている都合上、様々な制約があったり、性能の低いリソースを使わないとコストがかかりすぎるなど難しい局面も持っています。 例えば一つの仮想ブロックストレージの上限容量です。あるプロバイダーでは 16TB までしか使えなかったり、IOPS の上限にひっかかったりします。 このように、デフォルトのままではパフォーマンス要件をこなせないような場合でも、SV4PC で仮想ブロックストレージを複数束ねることで、仮想サーバー側に提供するストレージをスケールアウトすることができるので解決できたりもします。 また、データがホットな時期は SSD、旬が過ぎると HDD レベルで充分なデータを扱う場合、そもそも一時的なパフォーマンスのために全データを同じ SSD に置いておくのは無駄があります。 このような場合、最小限必要な SSD と充分な HDD を SV4PC で束ねつつ、前述の Easy Tier のような自動階層化機能を使うと、意識することなくホットデータは SSD で処理、その後は HDD へ配置されるので、クラウド上のストレージコストを全体的に減らすことができたりもします。 さらに、SV4PC のシン・プロビジョニング機能を使えば効率の良いコスト削減が可能となります。 通常の場合、仮想ブロックストレージの払い出しは見込み容量を先に決めてからその分払い出すことになり、運用後の拡張の手間を考えると、あらかじめ余裕を持った容量を払い出しがちです。この場合、実際に使用していなくとも払い出した容量は課金対象となります。 これに対しシン・プロビジョニングは、実際に存在する容量以上のストレージ空間を切り出すことができるのと、後から不足しそうな容量分の仮想ブロックストレージをストレージプールに加えることもできるので、最小限の容量から始めることができ、容量課金を削減することができます。 図8. パブリッククラウド上でのSV4PCの活用 なお何度も言いますが、SV4PC は今後のコンテナ環境にも対応しております。 ここまで見てきた通り、SV4PC はクラウド全盛の今だからこその機能を備えた Software Define Storage ソリューションであることが分かると思います。 いかがでしたか？ ハードウェアはもちろん技術の塊ですが、ソフトウェアのみでも十分に使える IBM Spectrum Virtualize ファミリー、少しは興味を持っていただけたのではないでしょうか？ 次回は「最新のデータのライフサイクル管理」ということで ESS、Sepctrum Scale、オブジェクトストレージ、そして Spectrum Discover といった製品に触れてみたいと思います。 乞うご期待！ 補足 1）リアルタイムデータ圧縮 バッチ処理で圧縮するのではなく、データの書き込み時に圧縮処理をして記憶域に書き込む圧縮方法です。FlashSystem 5030 と SV4PC を除きハードウェア・アクセラレータを活用できます。 もちろん 5030 および SV4PC もコントローラのリソースのみの処理ですが暗号化機能を実現しています。 圧縮率は、対象となるデータの種類によって異なりますが、一般にデータベース、メール、仮想サーバーイメージなどのファイルが高いと言われています。 以前はオフィスデータなども高かったのですが、最近はすでにオリジナルのオフィスファイル自体で圧縮済みですので、あまり効果は期待できなくなっていると言われます。 更に DRP の機能とは別に、IBM 特有の FlashCore モジュール（略して FCM。FlashSystem 5100, 7200, 9200/R で使用可能）であれば、モジュールそのものにインライン・ハードウェア圧縮機能があります。これはモジュール内のハードウェア的なデータの通り道にワイヤードロジックによる圧縮機能を設けているため、性能に影響を与えません。 ちなみにこのワイヤードロジックには暗号化機能も盛り込まれており、同様に性能に影響のない暗号化を実現しています。 2）重複排除 データのなかに同じパターンを見つけて、冗長なデータを削減することで容量を節約する機能です。特に仮想サーバーイメージなどには有効な手法です。 以前は非常に負荷がかかる作業だったため、バックアップなどに限定して使われていた技術ですが、昨今は性能の向上により、通常のストレージでも当たり前に使われる技術となりました。 以下は非常に単純化したインラインで扱われる重複排除のイメージです。バックアップ等での処理はこの限りではありません。 図9. 重複排除 実際はこう単純ではありません。 書かれたデータのパターンに応じたフィンガープリントと呼ばれる代替え値をハッシュ関数により導き、新たに書かれるデータのハッシュ値がすでに存在するフィンガープリントと一致している場合は、データそのものは書き込まず、参照するフィンガープリントのポインターのみを管理テーブルに記録する。これによりデータを間引くことができ、書き込み容量を削減することができるのです。 DRP 上での重複排除の特徴はフィンガープリントを同一ボリューム内のみならず、同じ DRP で定義された別のボリュームも含めて参照していることです（※図4参照）。同じプール内でバックアップなどのボリュームが定義された場合などに効果を発揮できるからです。 図4.Data Reduction Pool 3）シン・プロビジョニング こちらは、データ削減と言うよりはサーバーから見た際の話になります。 通常、ストレージ装置側で定義したボリュームをそのまま OS で認識させ使用することになります。その際の容量は、ストレージ装置のボリューム定義そのままの容量となります。 図10. シン・プロビジョニング シン・プロビジョニングを使うと、その容量定義を物理的に存在しない容量も上乗せして定義することができます。この場合消費されるストレージ装置の容量は実際に書き込みが起こった時にそのデータ容量分ずつとなります。 もちろんその存在しない容量分に書き込みが発生するとエラーになりますので、そうなる前に物理容量を追加する必要があります。同じストレージプール内の複数のボリュームで、実際に存在する実効容量を共有して消費するといった使い方が効果的です。が、OS 側からは何も意識することがありません。 この方法は、実はパブリッククラウドのように払い出し容量で月額課金されるようなサービスでは、より有効な節約方法となります。 4）Easy Tier Spectrum Virtualize ファミリーには、もう一つ特徴的な機能として自動階層化機能があります。 通常データの階層管理というと、ファイルレベルで実装するものをイメージされる方が多いのではないでしょうか？ Easy Tier はブロックレベルでありながらストレージの負荷情報を自ら学習し、アクセスの集中するホットなデータは Flash系のデバイス、アクセス頻度の低いデータは容量単価に優れる大容量・低速の HDD といった階層にデータを AI を使ってストレージの機能で動的に移動させる機能です。 図11. EasyTierの動作イメージ この機能を使うと高価な半導体系のストレージデバイスの容量を節約し、安価なハードディスクを増やすことで、パフォーマンスを下げずに全体の容量単価を下げることができます。 オンプレミスの FlashSystem はもちろん、払い出し容量で月額課金されるパブリッククラウドでも有効な節約手段となります。 5）コピーサービス 今や多くの廉価なストレージ装置もスナップショット、レプリケーションといった機能は当たり前になっています。 図12. 様々な用途に使えるコピーサービスの数々 スナップショットなどの瞬間のボリュームイメージを切り取る機能は、一般的にポイント・イン・タイム・コピーと呼び、IBM の場合は FlashCopy と言われる機能になります。 こちらは通常ストレージ装置内で使われる機能です。バックアップを取るときなどアプリケーションや RDB などと連携して、静止点をとるのに有効な機能です。 これに対して、ストレージ装置間で関連づけたボリューム同士で同期を取り、それぞれのボリュームを常に同じデータで満たす方法がレプリケーションです。 スナップミラー、ボリュームミラー、リモート・ミラーあるいはリモート・コピーなど、メーカーによって呼び方は様々ですが、基本的には時間的ズレのない同期型のものと、多少の時間的ズレを容認する非同期のものとに大別されます。 前者は銀行など災害などでのデータ損失を認めないような要件で使われ、拠点を跨ぐ場合、それなりの高価な設備（ネットワーク設備であったり拠点設備であったり）と共に使われます。後者はデータの多少の損失は容認するか、または別の方法（ログデータとかとの併用など）で補うかして、むしろ、より遠隔にデータを退避することを優先するなどの目的で使われます。広域災害などへの対策が多いですね。 考慮すべき事項に、特にレプリケーションは同じストレージ装置同士であると言う大前提があります。メーカーごとに使っている技術が異なるからです。 IBM の場合、Spectrum Virtualize ファミリーであれば相互接続が可能です。つまりオンプレミスのFlashSystem または SVC とパブリッククラウド上の SV4PC との接続が可能なのです。これが IBM ストレージがハイブリットクラウドに対応できると言う一つの根拠です。 もちろん前回触れた通り CSI（Container Storage Interface）にも対応していますので、コンテナ環境にも対応可能です。 接続方法について以前は、ストレージ機器同士の同期ということでより早く安全な FCP（Fibre Channel Protocol）に頼っていましたが、今日では非同期を前提に充分に IP 接続でも対応できるようになりました。 また、帯域以上のデータ転送を余儀無くされる初期同期が問題になりますが、前述のシン・プロビジョニング・ボリュームを対象とすることでボリューム全転送を必要とせず差分だけで可能となったり、データそのものも効率的な圧縮・重複排除の活用で小さくなったというのも大きいですね。 この記事に関するお問い合わせ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは以下のボタンよりお願いいたします。 お問い合わせ 関連ページ IBMストレージ製品 (製品情報) 全包囲網。。。最新 IBMストレージ 概要 (ブログ) OpenShiftに代表されるコンテナ環境へのIBMストレージの対応 (ブログ) 最新のデータライフサイクル管理とは？（前編）(ブログ) 最新のデータライフサイクル管理とは？（後編）(ブログ) AI導入はどこまで現実的？ 5大ハードルとその解決策を解説 (ホワイトペーパー) 普及が進む、機械学習による異常検知。導入の課題はここまで解決している (コラム) .btn_B{ height:25px; } .btn_B a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_B a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }
IBM Cloud Pak for Applicationsの新規販売は終了いたしました。 今後のアプリケーションランタイムソリューションは、2021年1月15日に発表されたWebSphere Hybrid Editionとなります。 1.本記事について 本記事は「IBM Cloud Pak for Applicationsを導入してみた（OpenShift導入編）」の コマンドの詳細を掲載したものです。 本編をご覧頂きながら、詳しいコマンドや実行結果を本記事でご確認ください。 2. 事前準備 2-1. 作業用Linux環境準備 （１）Cent OSインストールとディレクトリ作成 今回はCent OS 7をインストールし、ルート配下に以下の3つのディレクトリを作成します。 /work ※作業用スペース /os42 ※OpenShift インストールプログラム置き場 /os42/conf ※yamlやjsonなどの設定ファイル置き場 （２）AWS CLIインストール 前提ソフトウェアを確認し、AWS CLI をインストール・設定します。 <前提バージョン（2.7または3.4以上）の python が導入されていることを確認します。> # python --version Python 3.6.8 <aws cliをインストールし、バージョンを確認します。> rootユーザーで実行する場合の手順を行いました。 # curl "https://s3.amazonaws.com/aws-cli/awscli-bundle.zip" -o "awscli-bundle.zip" # unzip awscli-bundle.zip # export PATH=~/.local/bin:$PATH # source ~/.bash_profile # pip3 install awscli --upgrade --users # aws --version aws-cli/1.18.31 Python/3.6.8 Linux/4.18.0-147.5.1.el8_1.x86_64 botocore/1.15.31 <aws cli設定> AWSアカウント情報・利用するリージョンを元にAWS CLIを設定します。 # aws configure AWS Access Key ID: ※利用するAWSアカウントのAccess Keyを入力 AWS Secret Access Key: ※利用するAWSアカウントのSecret Access Keyを入力 Default region name [None]: ap-northeast-1 Default output format [None]: json （３）jqパッケージのインストール <CentOS 7 の標準リポジトリには jq が含まれていないので、EPELリポジトリを yum コマンドでインストールし、その後 jqパッケージをインストールします。> # yum -y install epel-release # yum -y install jq 2-2. インターネットドメインの取得とRoute53への登録 ＜インターネット上から OpenShift クラスターにアクセスするためにインターネットドメインを利用できるようにします。＞ 今回は AWS Route53で独自ドメインを取得・登録しました。 インターネットドメイン名：example.com（仮称） 2-3. インストールファイルの取得 インストールに利用するファイルを用意します。 <作業用Linuxマシンにて、Red Hat OpenShift Cluster Manager サイトの「Infrastructure Provider」ページから「AWS」－「User-Provisioned Infrastructure」を選択し、（１）OpenShift installer と（２）Pull secret をダウンロードし "oc42ディレクトリ" に配置します。> 以下、配置後の確認結果です。 # ll drwxr-xr-x. 2 root root 4096 3月 18 09:39 conf -rw-r--r--. 1 root root 80468756 3月 16 10:18 openshift-install-linux-4.2.23.tar.gz -rw-r--r--. 1 root root 2763 3月 4 13:15 pull-secret.txt 3. OpenShift 導入手順 3-1.AWS 環境構築 （１）SSH プライベートキーの生成およびエージェントへの追加 <作業用 Linuxマシン上で以下コマンドを実行し SSHキーを作成します。> # ssh-keygen -t rsa -b 4096 -N '' -f ~/.ssh/id_rsa Generating public/private rsa key pair. Created directory '/root/.ssh'. Your identification has been saved in /root/.ssh/id_rsa. Your public key has been saved in /root/.ssh/id_rsa.pub. The key fingerprint is: SHA256:jyTeAdzo1xi7bZh7+EK+r6j7y5rVDT5Jus8U9JDX8vs root@rpa-20 The key's randomart image is: +---[RSA 4096]----+ | | | . o . . | | + * o . | | . o O o | | o S o . | | . X.& . | | +o%.= . | | + =++. . | | ==*o*Bo E | +----[SHA256]-----+ <ssh-agent プロセスをバックグラウンドタスクとして開始します。> # eval "$(ssh-agent -s)" Agent pid 13552 <SSH プライベートキー（id_rsaファイル）を ssh-agent に追加します。> # ssh-add ~/.ssh/id_rsa Identity added: /root/.ssh/id_rsa (/root/.ssh/id_rsa) （２）AWS のインストール設定ファイルの作成 <install-config.yaml ファイルを取得します。> 以下を実行すると install-config.yaml ファイルが作成されます。 # ./openshift-install create install-config --dir=/os42 プロンプト上で選択または入力 SSHキー：/root/.ssh/id_rsa ※”（１）SSH プライベートキーの生成およびエージェントへの追加”で作成したSSHキー ターゲットプラットフォーム：aws AWSアクセスキーID： ※利用するAWSアカウントのAccess Keyを入力 AWSシークレットキー： ※利用するAWSアカウントのSecret Keyを入力 AWSリージョン：ap-northeast-1 (tokyo) Route53のベースドメイン名：example.com ※AWS Route53に登録したドメイン名 クラスター名：nicptestcluster ※任意の名前 Pull Secret：※"/os42/pull-secret.txt"の内容をコピー＆ペースト ※特に完了のメッセージは表示されませんのでご注意ください。 <install-config.yaml ファイルを編集し、コンピュートレプリカ の数を 0 にします。> #vi install-config.yaml compute: - hyperthreading: Enabled name: worker platform: {} replicas: 3 ← ここを0に変更 <install-config.yaml ファイルはインストール実行時に消去されてしまうので、別名でバックアップしておきます。> #cp install-config.yaml install-config.yaml.org （３）インフラストラクチャー名の抽出 ＊インストールプログラムが生成する Ignition 設定ファイルには、24時間が経過すると期限切れになる証明書が含まれます。 <クラスターの Kubernetes マニフェストを生成します。> #./openshift-install create manifests --dir=/os42 <openshiftフォルダが作成されるのでフォルダ内を確認します。> # ll openshift -rw-r-----. 1 root root 219 3月 18 09:49 99_cloud-creds-secret.yaml -rw-r-----. 1 root root 181 3月 18 09:49 99_kubeadmin-password-secret.yaml -rw-r-----. 1 root root 1530 3月 18 09:49 99_openshift-cluster-api_master-machines-0.yaml -rw-r-----. 1 root root 1530 3月 18 09:49 99_openshift-cluster-api_master-machines-1.yaml -rw-r-----. 1 root root 1530 3月 18 09:49 99_openshift-cluster-api_master-machines-2.yaml -rw-r-----. 1 root root 2713 3月 18 09:49 99_openshift-cluster-api_master-user-data-secret.yaml -rw-r-----. 1 root root 2027 3月 18 09:49 99_openshift-cluster-api_worker-machineset-0.yaml -rw-r-----. 1 root root 2027 3月 18 09:49 99_openshift-cluster-api_worker-machineset-1.yaml -rw-r-----. 1 root root 2027 3月 18 09:49 99_openshift-cluster-api_worker-machineset-2.yaml -rw-r-----. 1 root root 2713 3月 18 09:49 99_openshift-cluster-api_worker-user-data-secret.yaml -rw-r-----. 1 root root 1207 3月 18 09:49 99_openshift-machineconfig_master.yaml -rw-r-----. 1 root root 1207 3月 18 09:49 99_openshift-machineconfig_worker.yaml -rw-r-----. 1 root root 222 3月 18 09:49 99_role-cloud-creds-secret-reader.yaml <クラスターがコントロールプレーンマシンを自動的に生成するのを防ぐために、コントロールプレーンマシンを定義する Kubernetes マニフェストファイルを削除します。> #rm -f openshift/99_openshift-cluster-api_master-machines-*.yaml <同様に、ワーカーマシンを定義する Kubernetes マニフェストファイルを削除します。> #rm -f openshift/99_openshift-cluster-api_worker-machineset-*.yaml </oc42/manifests/cluster-scheduler-02-config.yml を変更し、Pod がコントロールプレーンマシンにスケジュールされないようにします。> # vi /oc42/manifests/cluster-scheduler-02-config.yml "mastersSchedulable"パラメーターの値を False に設定、保存します。 <Ignition 設定ファイルを取得します。> #./openshift-install create ignition-configs --dir=/os42 <コマンド実行後、作成されたファイル・ディレクトリを確認します。> # ll -rw-r--r--. 1 root root 706 3月 9 20:16 README.md drwxr-x---. 2 root root 50 3月 18 09:52 auth ←あることを確認 -rw-r-----. 1 root root 291635 3月 18 09:53 bootstrap.ign ←あることを確認 drwxr-xr-x. 2 root root 4096 3月 18 09:39 conf -rw-r-----. 1 root root 4045 3月 18 09:49 install-config.yaml.org -rw-r-----. 1 root root 1837 3月 18 09:52 master.ign ←あることを確認 -rw-r-----. 1 root root 267 3月 18 09:53 metadata.json ←あることを確認 -rwxr-xr-x. 1 root root 323536416 3月 9 20:16 openshift-install -rw-r--r--. 1 root root 80468756 3月 16 10:18 openshift-install-linux-4.2.23.tar.gz -rw-r--r--. 1 root root 2763 3月 4 13:15 pull-secret.txt -rw-r-----. 1 root root 1837 3月 18 09:52 worker.ign ←あることを確認 # ll auth/ -rw-r-----. 1 root root 23 3月 18 09:52 kubeadmin-password ←あることを確認 -rw-r-----. 1 root root 8972 3月 18 09:52 kubeconfig ←あることを確認 <インフラストラクチャー名を抽出します。> Ignition 設定ファイルメタデータからインフラストラクチャー名を抽出・表示します。ここで事前に準備したjqコマンドが必要になるのですね。 # jq -r .infraID /os42/metadata.json nicptestcluster-w8r8h ←インフラストラクチャー名が出力されることを確認 （４）AWS での VPC の作成 </os42/confディレクトリに以下のファイルを作成します。> なお、これ以降の手順の中で作成した yamlファイル、jsonファイルともファイル名は任意です。 CloudFormation Template："cf_newvpc.yaml"ファイル CloudFormation Templateのパラメーター："cf_newvpc.json"ファイル ＊cf_newvpc.yaml、cf_newvpc.jsonファイルの中身はRed Hatマニュアルページの”1.5.7. AWS での VPC の作成”に書かれている内容をコピー・アンド・ペーストします。今回はマニュアル記載の値のままで作成しました。 ParameterKey ParameterValue 備考 VpcCidr 10.0.0.0/16 VPC の CIDR ブロック。 AvailabilityZoneCount 1 VPC をデプロイするAZの数 SubnetBits 12 各AZ内の各サブネットのサイズ <VPC 作成の CloudFormation 展開コマンドを実行します。> --stack-name の後のスタック名（以下のコマンドでは createvpc）は任意の名前です。 ＊ここで本検証で初めて CloudFormation を実行しました。 （５）AWS でのネットワークおよび負荷分散コンポーネントの作成 <VPC作成時と同様に、マニュアルの該当ページの内容を含んだファイルをそれぞれ”/os42/conf”に配置します。> CloudFormation Template："cf_network.yaml"ファイル CloudFormation Templateのパラメーター："cf_network.json"ファイル <cf_network.jsonファイルを編集します。> ここがポイントです。 以下の cf_network.jsonファイル内の7つの ParameterKey に指定する ParameterValue を、これまで実行したコマンドや情報からの値に更新します。 ParameterKey ParameterValue 備考 ClusterName nicptestcluster install-config.yaml ファイルを生成した時に入力したクラスター名 InfrastructureName nicptestcluster-w8r8h Ignition 設定ファイルから抽出したインフラストラクチャー名 HostedZoneId ZMxxxxxxxxxxx Route53 パブリックゾーン ID（事前にAWSコンソールで確認します） HostedZoneName example.com nstall-config.yaml ファイルを生成した時に使用した Route53 ベースドメイン名 PublicSubnets subnet-0306b9ca39a3a00bd VPC の CloudFormation テンプレートの出力より PrivateSubnets subnet-0407cf93524961fb4 VPC の CloudFormation テンプレートの出力より VpcId vpc-00a56e4c475a50da8 VPC の CloudFormation テンプレートの出力より <更新した cf_network.jsonファイルを用いて CloudFormation 展開コマンドを実行します。> # aws cloudformation create-stack --stack-name createnetwork --template-body file:///os42/conf/cf_network.yaml --parameters file:///os42/conf/cf_network.json --capabilities CAPABILITY_NAMED_IAM <出力を確認します。> # aws cloudformation describe-stacks --stack-name createnetwork ParameterKey ParameterValue 備考 PrivateHostedZoneId Z0xxxxxxxxxxxxxxxxxxxx プライベート DNS のホストゾーン ID ExternalApiLoadBalancerName net/nicptestcluster-w8r8h-ext/9a604677bb972af0 外部 API ロードバランサーのフルネーム InternalApiLoadBalancerName net/nicptestcluster-w8r8h-int/a277ca3a4501369a 内部 API ロードバランサーのフルネーム ApiServerDnsName api-int.nicptestcluster. example.com API サーバーのFQDN RegisterNlbIpTargetsLambda arn:aws:lambda:ap-northeast-1:359962000209:function:createnetwork-RegisterNlbIpTargets-1M2PEFJK0J2C3 これらのロードバランサーの登録/登録解除に役立つ Lambda ARN ExternalApiTargetGroupArn arn:aws:elasticloadbalancing:ap-northeast-1:359962000209:targetgroup/creat-Exter-RH5R6UUT2ULX/80f9d95fe136b5e3 外部 API ターゲットグループの ARN InternalApiTargetGroupArn arn:aws:elasticloadbalancing:ap-northeast-1:359962000209:targetgroup/creat-Inter-B5IB5RST56XN/4cfdcc5ae595e3f9 内部 API ターゲットグループの ARN InternalServiceTargetGroupArn arn:aws:elasticloadbalancing:ap-northeast-1:359962000209:targetgroup/creat-Inter-NEZL8AMZ4W1X/5a6cce34822ca9dc 内部サービスターゲットグループの ARN （６）AWS でのセキュリティーグループおよびロールの作成 <これまでと同様にマニュアルの該当ページの内容を含んだファイルをそれぞれ”/os42/conf”に配置します。> CloudFormation Templateのパラメーター："cf_security.json"ファイル CloudFormation Template："cf_security.yaml"ファイル <cf_security.jsonファイルを編集します。> 以下の4箇所のParameterValueに値をセットします。 ParameterKey ParameterValue 備考 InfrastructureName nicptestcluster-w8r8h Ignition 設定ファイルから抽出したインフラストラクチャー名 VpcCidr 10.0.0.0/16 VPCのサブネットアドレス値 PrivateSubnets subnet-0407cf93524961fb4 VPC の CloudFormation テンプレートの出力より VpcId vpc-00a56e4c475a50da8 VPC の CloudFormation テンプレートの出力より <CloudFormation展開コマンドを実行します。> # aws cloudformation create-stack --stack-name createsecurity --template-body file:///os42/conf/cf_security.yaml --parameters file:///os42/conf/cf_security.json --capabilities CAPABILITY_NAMED_IAM <出力を確認します。> # aws cloudformation describe-stacks --stack-name createsecurity ParameterKey ParameterValue 備考 MasterSecurityGroupId sg-0ca008469442d0702 マスターセキュリティーグループ ID WorkerSecurityGroupId sg-0fcaab02eeb63b716 ワーカーセキュリティーグループ ID MasterInstanceProfile createsecurity-MasterInstanceProfile-JAFR521FJOOL マスター IAM インスタンスプロファイル WorkerInstanceProfile createsecurity-WorkerInstanceProfile-1320LLA579623 ワーカー IAM インスタンスプロファイル （７）AWS インフラストラクチャーの RHCOS AMI <利用するRHCOS AMIのAWSゾーンとAWS AMIをマニュアルページの”1.5.10. AWS インフラストラクチャーの RHCOS AMI”にて確認します。> 今回は aws configure でも指定した ap-northeast-1 ですので、該当ゾーンの AWS AMI を確認します。 AWSゾーン：ap-northeast-1 AWS AMI：ami-0426ca3481a088c7b 3-2. OpenShift導入 （１）Bootstrapノード作成 OpenShiftクラスターの初期化で使用するBootstrapノードをAWS上に作成します。 <Ignition 設定ファイルを S3バケットに配置します。> まずS3バケットを作成します # aws s3 mb s3://nicptestcluster-infra 続いてIgnition 設定ファイル（bootstrap.ign ）をS3バケットにアップロードします。 # aws s3 cp bootstrap.ign s3://nicptestcluster-infra/bootstrap.ign 最後にファイルがアップロードされたことを確認します。 # aws s3 ls s3://nicptestcluster-infra/ 2020-03-27 10:08:33 291635 bootstrap.ign </os42/confディレクトリに以下のファイルを作成します。> CloudFormation Template："cf_bootstrap.yaml"ファイル CloudFormation Templateのパラメーター："cf_bootstrap.json"ファイル <cf_bootstrap.jsonファイルを編集します。> ParameterKey ParameterValue 備考 InfrastructureName nicptestcluster-w8r8h Ignition 設定ファイルから抽出したインフラストラクチャー名 RhcosAmi ami-0426ca3481a088c7b 確認したAWS AMI AllowedBootstrapSshCidr 0.0.0.0/0 デフォルトのまま PublicSubnet subnet-0306b9ca39a3a00bd VPC の CloudFormation テンプレートの出力より MasterSecurityGroupId sg-0ca008469442d0702 セキュリティーグループおよびロールの CloudFormation テンプレートの 出力より VpcId vpc-00a56e4c475a50da8 VPC の CloudFormation テンプレートの出力より BootstrapIgnitionLocation s3://nicptestcluster-infra/bootstrap.ign ブートストラップファイルの場所 AutoRegisterELB yes ネットワークロードバランサー (NLB) を登録するかどうか RegisterNlbIpTargetsLambdaArn arn:aws:lambda:ap-northeast-1:359962000209:function:createnetwork-RegisterNlbIpTargets-1M2PEFJK0J2C3 ネットワークのCloudFormationテンプレートの出力より ExternalApiTargetGroupArn arn:aws:elasticloadbalancing:ap-northeast-1:359962000209:targetgroup/creat-Exter-RH5R6UUT2ULX/80f9d95fe136b5e3 ネットワークのCloudFormationテンプレートの出力より InternalApiTargetGroupArn arn:aws:elasticloadbalancing:ap-northeast-1:359962000209:targetgroup/creat-Inter-B5IB5RST56XN/4cfdcc5ae595e3f9 ネットワークのCloudFormationテンプレートの出力より InternalServiceTargetGroupArn arn:aws:elasticloadbalancing:ap-northeast-1:359962000209:targetgroup/creat-Inter-NEZL8AMZ4W1X/5a6cce34822ca9dc ネットワークのCloudFormationテンプレートの出力より <CloudFormation 展開コマンドを実行します。> # aws cloudformation create-stack --stack-name bootstrap --template-body file:///os42/conf/cf_bootstrap.yaml --parameters file:///os42/conf/cf_bootstrap.json --capabilities CAPABILITY_NAMED_IAM <出力を確認します。> # aws cloudformation describe-stacks --stack-name bootstrap ParameterKey ParameterValue 備考 BootstrapInstanceId i-0a68a104e8a04ae08 Bootstrapインスタンス ID BootstrapPublicIp 13.112.188.xxx Bootstrapノードのパブリック IP アドレス BootstrapPrivateIp 10.0.0.xxx Bootstrapのプライベート IP アドレス （２）コントロールプレーン（Masterノード）の作成 </os42/confディレクトリに以下のファイルを作成します。> CloudFormation Template："cf_controlplane.yaml"ファイル CloudFormation Templateのパラメーター："cf_controlplane.json"ファイル <cf_controlplane.jsonファイルを編集します。> ParameterKey ParameterValue 備考 InfrastructureName nicptestcluster-w8r8h Ignition 設定ファイルから抽出したインフラストラクチャー名 RhcosAmi ami-0426ca3481a088c7b 確認したAWS AMI AutoRegisterDNS yes yesまたはno PrivateHostedZoneId Z0xxxxxxxxxxxxxxxxxxxx ネットワークのCloudFormationテンプレートの出力より Master0Subnet subnet-0407cf93524961fb4 VPC の CloudFormation テンプレートの出力より Master1Subnet subnet-0407cf93524961fb4 VPC の CloudFormation テンプレートの出力より Master2Subnet subnet-0407cf93524961fb4 VPC の CloudFormation テンプレートの出力より MasterSecurityGroupId sg-0ca008469442d0702 セキュリティーグループおよびロールの CloudFormation テンプレートより IgnitionLocation https://api-int.nicptestcluster.example.com:22623/ config/master 生成される Ignition 設定ファイルの場所を指定 CertificateAuthorities data:text/plain;charset=utf-8;base64,LS0tLS1・・・ インストールディレクトリーにあるmasiter.ignファイルから値を指定 MasterInstanceProfileName" createsecurity-MasterInstanceProfile-JAFR521FJOOL セキュリティーグループおよびロールの CloudFormation テンプレートより MasterInstanceType m5.xlarge 利用するEC2インスタンスタイプを指定 AutoRegisterELB yes yesまたはno RegisterNlbIpTargetsLambdaArn arn:aws:lambda:ap-northeast-1:359962000209:function:createnetwork-RegisterNlbIpTargets-1M2PEFJK0J2C3 ネットワークのCloudFormationテンプレートの出力より ExternalApiTargetGroupArn arn:aws:elasticloadbalancing:ap-northeast-1:359962000209:targetgroup/creat-Exter-RH5R6UUT2ULX/80f9d95fe136b5e3 ネットワークのCloudFormationテンプレートの出力より InternalApiTargetGroupArn arn:aws:elasticloadbalancing:ap-northeast-1:359962000209:targetgroup/creat-Inter-B5IB5RST56XN/4cfdcc5ae595e3f9 ネットワークのCloudFormationテンプレートの出力より InternalServiceTargetGroupArn arn:aws:elasticloadbalancing:ap-northeast-1:359962000209:targetgroup/creat-Inter-NEZL8AMZ4W1X/5a6cce34822ca9dc ネットワークのCloudFormationテンプレートの出力より <今回、"MasterInstanceType" に m5 インスタンスタイプを指定するので、そのインスタンスタイプを cf_controlplane.yaml ファイルの MasterInstanceType.AllowedValues パラメーターに追加します。> 途中、省略 MasterInstanceType: Default: m4.xlarge Type: String AllowedValues: - "m4.xlarge" - "m4.2xlarge" - "m4.4xlarge" - "m4.8xlarge" - "m4.10xlarge" - "m4.16xlarge" - "m5.xlarge" ←追加 - "m5.2xlarge" ←追加 - "m5.4xlarge" ←追加 - "m5.8xlarge" ←追加 以下、省略 <CloudFormation 展開コマンドを実行します。> # aws cloudformation create-stack --stack-name controlplane --template-body file:///os42/conf/cf_controlplane.yaml --parameters file:///os42/conf/cf_controlplane.json <状況を確認します。> # aws cloudformation describe-stacks --stack-name controlplane （３）Workerノードの作成 ※CloudFormation テンプレートは、1 つのWorkerマシンを表すスタックを作成します。今回はWorkerノードを2台作成するので、それぞれのWorkerマシンにスタックを作成する必要があります。 </os42/confディレクトリに以下のファイルを作成します。> CloudFormation Template："cf_worker.yaml"ファイル CloudFormation Templateのパラメーター："cf_worker.json"ファイル <cf_worker.jsonファイルを編集します。> ParameterKey ParameterValue 備考 InfrastructureName nicptestcluster-w8r8h Ignition 設定ファイルから抽出したインフラストラクチャー名 RhcosAmi ami-0426ca3481a088c7b 確認したAWS AMI Subnet subnet-0407cf93524961fb4 VPC の CloudFormation テンプレートの出力より WorkerSecurityGroupId sg-0fcaab02eeb63b716 セキュリティーグループおよびロールの CloudFormation テンプレートより IgnitionLocation https://api-int.nicptestcluster.example.com:22623/ config/worker 生成される Ignition 設定ファイルの場所を指定 CertificateAuthorities data:text/plain;charset=utf-8;base64,LS0tLS1・・・ インストールディレクトリーにあるworker.ignファイルから値を指定 WorkerInstanceProfileName createsecurity-WorkerInstanceProfile-1320LLA579623 セキュリティーグループおよびロールの CloudFormation テンプレートより WorkerInstanceType m5.xlarge 利用するEC2インスタンスタイプを指定 <cf_controlplane.yamlと同様に、"MasterInstanceType" に m5 インスタンスタイプを指定するので、そのインスタンスタイプを cf_worker.yaml ファイルの MasterInstanceType.AllowedValues パラメーターに追加します。> CloudFormation 展開コマンドを実行。 今回ワーカーノードは2台作成するので、stack-name を「worker1」「worker2 」と分けて2回実行します。 # aws cloudformation create-stack --stack-name worker1 --template-body file:///os42/conf/cf_worker.yaml --parameters file:///os42/conf/cf_worker.json # aws cloudformation create-stack --stack-name worker2 --template-body file:///os42/conf/cf_worker.yaml --parameters file:///os42/conf/cf_worker.json <出力を確認します。> # aws cloudformation describe-stacks --stack-name worker1 # aws cloudformation describe-stacks --stack-name worker2 （４）Bootstrapノードの初期化 <Bootstrapノードの初期化コマンドを実行し、FATAL エラーなどが出ずに終了することを確認します。> # ./openshift-install wait-for bootstrap-complete --dir=/os442 --log-level=info INFO Waiting up to 30m0s for the Kubernetes API at https://api.test.example.com:6443... INFO API v1.14.6-152-g117ba1f up INFO Waiting up to 30m0s for bootstrapping to complete... INFO It is now safe to remove the bootstrap resources （５）CLI のインストール <OpenShift Installer、Pull secretをダウンロードしたページにて、「Command-line interface」項目からOSとして「Linux」を選択し、「command-line tools」をダウンロードします。> <CLIツールの展開 - ダウンロードした圧縮ファイルを展開します 。> ※OS42ディレクトリにダウンロードしたファイルをコピーし、展開します。 # cp tar xvf openshift-client-linux-4.2.23.tar.gz /os42/tar xvf openshift-client-linux-4.2.23.tar.gz # tar xvf openshift-client-linux-4.2.23.tar.gz ※パスに/oc42を追加します。 # export PATH="$PATH:/os42" ※ocコマンドのテスト # oc help （６）クラスターへのログイン ※kubeadmin 認証情報をエクスポートします。 # export KUBECONFIG=/os42/auth/kubeconfig ※oc コマンドを正常に実行できることを確認 # oc whoami system:admin （７）マシンの CSR の承認 <クラスターがマシンを認識していること（今回Masterノード3台、Workerノード2台が表示されること）を確認します。> # oc get nodes NAME STATUS ROLES AGE VERSION ip-10-0-48-xxx.ap-northeast-1.compute.internal Ready worker 57s v1.14.6+8fc50dea9 ip-10-0-49-xxx.ap-northeast-1.compute.internal Ready worker 42m v1.14.6+8fc50dea9 ip-10-0-50-xxx.ap-northeast-1.compute.internal Ready master 22h v1.14.6+8fc50dea9 ip-10-0-58-xxx.ap-northeast-1.compute.internal Ready master 22h v1.14.6+8fc50dea9 ip-10-0-59-xxx.ap-northeast-1.compute.internal Ready master 22h v1.14.6+8fc50dea9 （８）Operator の初期設定 5秒ごとに実行される oc get clusteroperators の結果をモニタリングし、クラスターコンポーネントがオンラインになることを確認します。 <”Available" が ”True”、”DEGRADED” 列が ”False” になることを確認します。> # watch -n5 oc get clusteroperators NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE authentication 4.2.23 True False False 44m cloud-credential 4.2.23 True False False 22h cluster-autoscaler 4.2.23 True False False 22h console 4.2.23 True False False 46m dns 4.2.23 True False False 22h image-registry 4.2.23 True False False 50m ingress 4.2.23 True False False 50m ・ ・ 以下、省略 本検証では、（７）マシンの CSR の承認の手順で全ノードが Ready となった後に確認するとすべての Operator コンポーネントがオンライン（AVAILABLE 列が True）になっていましたが、image-registry Operator がオフライン（AVAILABLE 列が False）である場合はマニュアルページの「1.5.17.1. イメージレジストリーストレージの設定」の章をご確認ください。 （９）Bootstrapノードの削除 クラスターの初期 Operator 設定を完了した後に Bootstrapリソースを削除します。 <CloudFormation コマンドで"（１）Bootstrapノード作成"手順で作ったbootstrap という名前の Stack を削除します。> これにより、ブートストラップノードが削除されます。 # aws cloudformation delete-stack --stack-name bootstrap （１０）クラスターのインストールを完了 <クラスターのインストール完了を確認します。> 以下のコマンドでインストール状況をモニターします。 #./openshift-install --dir=/os42 wait-for install-complete （中略） INFO Install complete! INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/os42/auth/kubeconfig' INFO Access the OpenShift web-console here: https://console-openshift-console.apps.nicptestcluster.example.com INFO Login to the console with user: kubeadmin, password: XXXXX 上記のように ”Install complete!" となり、「コンソールのURL」「ユーザー名」「パスワード」が表示されればインストール完了で OpenShift 環境が利用可能となります。 ！！重要！！ インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになる証明書が含まれます。 Ignition ファイルは 24 時間有効であるため、この時間内に OpenShift デプロイメントを実行する必要があります。 作成から24時間過ぎた場合はIgnition ファイルを再生成する必要があります。 <動作確認 - OpenShiftのコンソールにアクセスします。> Webコンソールの場合： https://console-openshift-console.apps.nicptestcluster.example.com CLI の場合： oc login -u kubeadmin -p XXXXX https://api.nicptestcluster.example.com:6443 以上で OpenShift インストールは完了となります。 お問い合わせ この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社 技術支援本部 E-Mail：nicp_support@NIandC.co.jp
IBM Cloud Pak for Applicationsの新規販売は終了いたしました。 今後のアプリケーションランタイムソリューションは、2021年1月15日に発表されたWebSphere Hybrid Editionとなります。 こんにちは。 てくさぽBLOGメンバーの岡田です。 全3回「IBM Cloud Pak for Applicationsを導入してみた」シリーズの、"OpenShift導入編" です。 IBM Cloud Pak for Applicationsを導入してみた（概要編） IBM Cloud Pak for Applicationsを導入してみた（OpenShift導入編） ← 今回 IBM Cloud Pak for Applicationsを導入してみた（ICP4 Applications導入編） 本記事では、我々が実際にやってみてつまづいたポイントや AWS 特有の注意事項も記載していますので、ぜひ最後までお読みください。 1. はじめに 概要編でも述べていますが、IBM Cloud Paks（以下 Paks）は OpenShift 上で稼働するアプリケーションのため、Paks を利用するためには OpenShift の構築が必要となります。 今回の検証では最小構成での検証を実施するために、以下の環境で実施しました。 AWS 上での構築 OpenShift バージョン4.2（検証時最新） User-Provisioned Infrastructure（UPI）方式・・・ユーザーがインフラ環境を事前に用意してインストールを行う方法 CloudFormation テンプレートの使用 さて、以下が今回インストールする全体構成になります。Masterノード3台、Workerノード2台の構成です。 また本検証では、以下の Red Hat 社マニュアルページを利用しました。 インストールで利用する jsonファイル、yamlファイルの中身はこのマニュアル内の記載からコピー・アンド・ペーストして作成します。 「1.5. CLOUDFORMATION テンプレートの使用による、AWS でのユーザーによってプロビジョニングされたインフラストラクチャーへのクラスターのインストール」 2. 事前準備 2-1. 作業用Linux環境準備 OpenShiftのインストール作業に必要なLinux(Cent OS)環境を準備します。 詳細な手順はリンク先を参照ください。 （１）Cent OS インストールとディレクトリ作成 （２）AWS CLI インストール （３）jqパッケージのインストール 2-2. インターネットドメインの取得とRoute53への登録 インターネット上から OpenShift クラスターにアクセスするためにインターネットドメインを利用できるようにAWS Route53で独自ドメインを取得・登録しました。 インターネットドメイン名：example.com（仮称） 2-3. インストールファイルの取得 OpenShiftのインストールに利用するファイルをRed Hatサイトからダウンロードします。 3. OpenShift 導入手順 3-1.AWS 環境構築 まずは AWS 環境を構築します。 今回は以下の全7項目を順番に実施しました。 詳細な手順はリンク先を参照ください。 （１）SSH プライベートキーの生成およびエージェントへの追加 （２）AWS のインストール設定ファイルの作成 （３）インフラストラクチャー名の抽出 （４）AWS での VPC の作成 ※つまづきポイントをこの後ご紹介 （５）AWS でのネットワークおよび負荷分散コンポーネントの作成 （６）AWS でのセキュリティーグループおよびロールの作成 （７）AWS インフラストラクチャーの RHCOS AMI 「（４）AWSでのVPCの作成」でのつまづきポイント VPC作成のCloudFormationコマンドを実行した際にエラーが発生したので、原因と解決方法をご紹介します。 ↓このコマンドでエラーが出ていますが、どこが間違っているか分かりますか？ # aws cloudformation create-stack --stack-name createvpc --template-body conf/cf_newvpc.yaml --parameters conf/cf_newvpc.json Error parsing parameter '--parameters': Expected: '=', received: 'EOF' for input: conf/cf_newvpc.json パッと見、おかしいところが無さそうなのですがエラーとなっています。 検証メンバーで調査＆トライ・アンド・エラーすること小一時間。。。原因は単純でした。 ファイル名を”file://”で指定していなかったのでyamlファイルやjsonファイルが読み込めなかったのです。以下が正しいコマンドになります。”file://”の後ろはフルパスで指定しているので"/"が3つ並んでます。 # aws cloudformation create-stack --stack-name createvpc --template-body file:///os42/conf/cf_newvpc.yaml --parameters file:///os42/conf/cf_newvpc.json 3-2. OpenShift導入 今回は以下の全10項目を順番に実施しました。 こちらも詳細な手順はリンク先を参照ください。 （１）Bootstrapノード作成 （２）コントロールプレーン（Masterノード）の作成 （３）Workerノードの作成 （４）Bootstrapノードの初期化 （５）CLI のインストール （６）クラスターへのログイン （７）マシンの CSR の承認 ※つまづきポイントをこの後ご紹介 （８）Operator の初期設定 （９）Bootstrapノードの削除 （１０）クラスターのインストールを完了 「（７）マシンの CSR の承認」でのつまづきポイント "oc get nodes"コマンドを実行してもマスターノードのみを認識しワーカーノードを認識しなかったので、その解決方法を紹介します。 下記のとおり、oc get nodes を実行してもマスターノードしか認識していません。 # oc get nodes NAME STATUS ROLES AGE VERSION ip-10-0-50-xxx.ap-northeast-1.compute.internal Ready master 21h v1.14.6+8fc50dea9 ip-10-0-58-xxx.ap-northeast-1.compute.internal Ready master 21h v1.14.6+8fc50dea9 ip-10-0-59-xxx.ap-northeast-1.compute.internal Ready master 21h v1.14.6+8fc50dea9 保留中の証明書署名要求 (CSR) を確認するとPending になっています。 # oc get csr NAME AGE REQUESTOR CONDITION csr-485lx 22m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending csr-9qjqw 18m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending ・ ・ 以下、省略 そこでまずは個々のCSRを承認していきましたがコマンド実行してもすぐに反映されない、また保留状態のCSRが増えていくという状態になりました。 # oc adm certificate approve csr-9qjqw certificatesigningrequest.certificates.k8s.io/csr-9qjqw approved # oc get csr NAME AGE REQUESTOR CONDITION csr-9qjqw 53m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Approved,Issued csr-485lx 22m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending ・ ・ 以下、省略 CSRが増える一方で状況が悪化しており、出てきたCSRを個別に処理するのもキリがないためこの時点で一度諦めました。 翌日にまとめて CSR を承認するコマンドを探して実行すると、ワーカーノードが認識できました。 # oc get csr -ojson | jq -r '.items[] | select(.status == {} ) | .metadata.name' | xargs oc adm certificate approve certificatesigningrequest.certificates.k8s.io/csr-2fn5z approved certificatesigningrequest.certificates.k8s.io/csr-4cj8b approved certificatesigningrequest.certificates.k8s.io/csr-4lpv7 approved ・ ・ 以下、省略 ※少しタイムラグがあるので、何回か状況確認・Approve処理を行う必要がありました。10分ぐらい間隔をあけた方がよかったです。 oc get nodesコマンドで全ノードの STATUSがReady であることを確認できます。 # oc get nodes NAME STATUS ROLES AGE VERSION ip-10-0-48-xxx.ap-northeast-1.compute.internal Ready worker 57s v1.14.6+8fc50dea9 ip-10-0-49-xxx.ap-northeast-1.compute.internal Ready worker 42m v1.14.6+8fc50dea9 ip-10-0-50-xxx.ap-northeast-1.compute.internal Ready master 22h v1.14.6+8fc50dea9 ip-10-0-58-xxx.ap-northeast-1.compute.internal Ready master 22h v1.14.6+8fc50dea9 ip-10-0-59-xxx.ap-northeast-1.compute.internal Ready master 22h v1.14.6+8fc50dea9 まとめて承認するコマンドが見つからなかったら、と思うとゾッとします。読者の方は事前に調べておきましょうね。 4. AWS特有の注意事項 AWSネットワークの理解は必須 Red Hat社のマニュアルページの内容を利用して jsonファイルと yamlファイルを用意し、CloudFormationコマンドを実行すれば AWS コンポーネントや OpenShift ノードなど必要なコンポーネントが自動的に作成されますが、自動的に作成されるが故に、ロードバランサー、サブネット、EC2インスタンスなどのコンポーネント間の接続の関係性が分かりづらいと思いました。 AWS マネージメントコンソールでなにが作成されたかを確認できますが、AWS のネットワークを理解していないと全体像の把握が難しくその点が苦労しました。 CloudFormation 特有のインストール時のクセを理解し慣れる CloudFormation でのインストールでは、それ以前に実行して出力された値を次の CloudFormation コマンドで用いる jsonファイルに転記して利用する、という操作を繰り返します。特に UPI方式では転記する項目も回数も多かったので、Excel でどの項目がどのフェーズの jsonファイルに転記するのかを整理してインストールを進めました。 またそのような CloudFormation の特徴から、事前に設定ファイルをすべて用意して順番に実行する、ということができませんのでインストール作業は時間に余裕を持って行いましょう。 5. まとめ 本記事で OpenShift を AWS 上で UPI インストールする流れを確認いただけましたでしょうか。 必要なインフラのコンポーネントをインストーラが自動的に作成してくれる IPI (Installer Provisioned Infrastructure) 方式と比べると作業工程が多くなりますが、本番環境のお客様要件に対し常に IPI方式で構築できるとは限らないと想定し、UPI方式を学んでおくことは大変有用だと思いますので参考になれば幸いです。 本記事の内容で構築した環境に、この後 Paks をインストールすることが可能となります。Paks の種類によって必要リソースは異なりますが UPI方式での手順は同じです。 次回は、この OpenShift の環境に Cloud Pak for Application をインストールしてみた内容をお伝えします。 お問い合わせ この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社 技術支援本部 E-Mail：nicp_support@NIandC.co.jp 関連情報 全ての企業が AI カンパニーになる！「IBM THINK Digital 2020」に参加した (ブログ) - 全世界から9万人以上の参加者が！ 【やってみた】IBM Cloud Pak for Applications導入してみた：概要編 (ブログ) - シリーズ第1回目！概要編として検証の目的・背景や環境周りをご紹介します。 【やってみた】Cloud Pak for Applications 導入してみた：Cloud Pak for Applications 導入編 (ブログ) - AWS 上に構築した Openshift 環境に Cloud Pak for Applications をインストールしてみました。 今、デジタルサービスに求められる必須要件とは!? アプリケーションのコンテナ化で得られる5つのメリット (コラム) - 今注目されている「コンテナ化」。コンテナ化とは？そのメリットとは？ IBM Cloud Paks シリーズ ご紹介資料 (資料) ※会員専用ページ - 6つの Cloud Paks について、お客様の理解度に応じて必要な資料を選択できる形式になっています。 【外部ページ】 IBM Cloud Pak for Applications (IBMサイト)
こんにちは。 てくさぽBLOGメンバーの佐野です。 およそ9か月前にCloud Pak for Dataのトライアルに関する記事を書きましたが、その後「触ってみてどういうものか理解できた！」「機能が豊富すぎて全部を理解するのは難しい」などの反響も頂きました。 この9か月の間にいくつかCloud Pak for Data関連のアップデートがありましたのでその情報をお届けします。 大きなトピックとして2点あります。 ・トライアルだけでなくビデオでの説明・紙芝居のような操作確認をIBM Demosでご提供 ・Cloud Pak for Data v3.0の出荷開始 まずはIBM Demosに関することから共有します。 １．IBM Demos 「Cloud Pak ExperienceというサイトでCloud Pak for Dataのトライアルができますよー」と利用方法含めて前回の記事で記載しました。 しかし、チュートリアルに従って簡単な利用方法を確認できるとはいえ、環境だけあっても「具体的にどんな機能があるんだ？」「こういう使い方できるんだろうか？」というところは自力で探して理解するしかありませんでした。 そこに対しての解決策の一つとなるのが”IBM Demos”です。 IBM Demosのサイトにアクセスをするといろいろな製品のデモや概要説明ビデオなどを探すことができます。 この中にCloud Pak for Dataもありますので、Cloud Pak for Dataに関する内容を閲覧することができます。 下の図の赤枠で括った箇所をクリックすると、IBM Demos内のCloud Pak for Dataサイトに飛びます。 サイトの表示は英語ですが、URLの最後の「?lc=en」を「?lc=ja」に変えることで日本語表示に変更することができます。ただ、一部違和感がある表現があったり、日本語字幕入りのビデオしか表示されないため、本記事では英語表示のままで説明をします。 IBM Demosはいくつかのパートに分かれています。Cloud Pak for Dataでは以下の3つです。 ・Video ・Product Tour ・Hands on Lab Videoでは概要を把握できるような説明ビデオが流れます。一部は日本語字幕有なので、英語が分からなくても内容が理解できるようになっています。 私のお勧めは「Overview of IBM Cloud Pak for Data」です。このビデオではCloud Pak for Dataの概要を理解することができます。他にはCloud Pak for Dataの特長の一つであるデータ仮想化の機能について説明している「IBM Cloud Pak for Data - Intro to Data Virtualization」も（英語ですが）見ておいた方がよいと思います。 Product Tourでは特定の機能を製品画面の操作をすることでより深く把握することができます。ただし、自由な操作はできずに、シナリオに沿った操作を紙芝居のようにできるぐらいです。 本記事の執筆時点では4つのみですが、ご自身が使いたい機能がこの中にあるようでしたら操作方法が分かりますので確認した方がよいでしょう。 Hands on Labsではトライアル用マシンを使って実際の操作を体験することができます。ここから先はIBM idが無いと操作ができません。「Experience IBM Cloud Pak for Data」ではIBM Demosから離れてCloud Pak Experienceへ移動します。 Cloud Pak Experience Cloud Pak Experienceですが、Cloud Pak for Dataのトライアル環境です。画面が前のブログと若干異なりますが、画面左側に表示されているHands-on Learning項目のCloud Pakシリーズのリンクを押すとIBM Demosに遷移する動作は変わっていません。 トライアルを始めるといっても、いくつかの基本的なシナリオの操作をすることがベースなので、まずはデータを収集するための”Collect”から始めましょう。 画面を少し下に移動して「Log in to explore」を押します。 IBMidを持っている人はIBMidとパスワードを入力し先に進みます。お持ちでない人はIBMidを作成します。画面の真ん中に「IBMid の作成」というリンクがあるのでこちらから作成してください。 こんな画面が出ることもあるようですが、問題なければ「次に進む」を押します。 デモ環境へアクセスするために、利用条件やプライバシーに関する同意を求められますので、内容を読んだうえで「次へ」を押します。 Cloud Pak Experienceのサイトにログインした状態で戻ってきました。「Explore」を押して早速Cloud Pak for Dataを体験してみましょう。 Exploreを押すと「しばらく待て」というメッセージがでるので、少し待ちます。 しばらく待つと自動的に画面が遷移します。 ここで自分自身で操作するか、ガイド付きかを選択できます。今回は「Let's go!」を押します。 ここから先は詳細を飛ばしますが、画面表示が日本語になっているのがうれしいですね。日本語で操作ができるなら見た目でも何が書いてあるのか理解しやすいですし、自力でなんとかなりそうな気もしてきます。 ただ、ガイド文は英語なので、どういうことをしようとしているのか？を読むのが大変かもしれません。 本ブログを書いている時点で、Cloud Pak Experience環境で使っているCloud Pak for Dataのバージョンは「3.0.1 enterprise」という最新バージョンでした。 なので、導入を検討しているようなステップにある場合でも画面や操作感が変わらない状態で確認できます。 是非、データ分析基盤の導入を検討する際にはCloud Pak Experienceを使ってみて下さい。 ２．Cloud Pak for Data v3アップデート情報 Cloud Pak for Data v3が2020/6/19に出荷開始となりました。主なアップデート内容は以下になります。 DataOps機能拡張 Watson Knowledge Catalog機能拡張およびデータ仮想化連携強化 セキュリティ強化 ⾮構造化データ管理の拡張（InstaScan) AIの機能拡張 ML Ops Auto AIの機能拡張 コンポーネントの拡張 Planning Analytics、Virtual Data Pipeline、Master Data Managementを含む新たなサービス群の追加 運用機能拡張 監査、バックアップといった運用機能強化 OpenShift v4.3対応 UIの変更 Cloud Pak for Dataライセンス名称の変更（Cloud Native→Standardへ変更）及びnon-productionライセンスの提供（Enterpriseのみ） 紙面の関係上、具体的な機能のアップデートは省略してコンポーネント拡張とライセンスについてご説明します。 Cloud Pak for Data v3で利用できるコンポーネントの一覧を図にまとめました。 ベースコンポーネント列にある製品(機能)はCloud Pak for Dataを購入すれば利用できます。追加サービス列にある製品(機能)はCloud Pak for Dataライセンスには含まれず、個別にライセンスを購入する必要があります。 表の中でも青文字で書かれた製品が今回のv3の提供に伴って追加となっています。この提供形態はv2.5からですが、追加サービスはどんどん増えているので今後の拡張にも期待できます。 追加サービスを購入する場合、例えばDataStageは個別の製品ライセンスとしても販売していますので既にDataStage自体をご利用になられているお客様もいらっしゃるのではないかと思います。 そういったお客様がCloud Pak for Dataへ移行しやすくなるように、一部の追加サービス製品においては既存環境のライセンスをCloud Pak for Dataの追加サービスに置き換えることで既存環境・Cloud Pak for Data環境どちらでも利用可能となるものもあります。 具体的な例を図に表しました。 この例では既に2,800PVU（40VPC相当）のDataStage環境をお使いのお客様がCloud Pak for Data DataStage追加サービス×40VPCへ置き換えたケースです。 図に示しているいずれのシーンにおいても、ライセンスを追加購入する必要がないため、Cloud Pak for Dataへ移行している最中であっても、もちろんCloud Pak for Dataへ移行した後であっても追加のライセンス費用はかかりません。 また、単体製品としてのDataStageからCloud Pak for Data DataStage追加サービスへのトレードアップもできますので、ゼロからライセンス買い直しをせずにCloud Pak for Dataを利用することができるようになり、非常にお得です。 注：ライセンス情報・コンポーネント情報は更新される場合がありますので最新情報を必ずご確認下さい。 ３．まとめ Cloud Pak for Dataはまだまだ発展しており、更新情報も全部ご説明ができていませんが情報てんこ盛りになってしまいました。 データ分析基盤をご検討頂いている方には自社のデータ分析をどのように効率できるのか、是非ともCloud Pak for Dataを体験頂き、その体験をするためにこの記事がお役に立てれば幸いです。 また、別のコラムやホワイトペーパーでデータ分析基盤について解説していますので、そちらもあわせてご確認下さい。 お問い合わせ この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社 技術支援本部 E-Mail：nicp_support@NIandC.co.jp
IBM Cloud Pak for Applicationsの新規販売は終了いたしました。 今後のアプリケーションランタイムソリューションは、2021年1月15日に発表されたWebSphere Hybrid Editionとなります。 こんにちわ。 てくさぽBLOGメンバーの佐野です。 今回はIBM Cloud Pakシリーズの1つである「Cloud Pak for Applications」の導入を弊社内で検証してみたので3回シリーズで検証で得られた知見をお伝えします。 第1回目の本記事では、概要編として検証の目的・背景や環境周りをご紹介いたします。 ＊連載の続きはこちら 【やってみた】IBM Cloud Pak for Applications導入してみた：OpenShift導入編（第2回） 【やってみた】IBM Cloud Pak for Applications 導入してみた：Cloud Pak for Applications 導入編（第3回） Cloud Pak for Applicationsの導入検証をした 背景・目的 以前のブログでCloud Pak for Dataの導入について紹介をしました。 その際はIBMの製品であるIBM Cloud Privateをコンテナ基盤としたCloud Pak for Data 2.1の導入であったため、インストーラを実行するとIBM Cloud PrivateとCloud Pak for Dataの両方を導入できました。 その後、Cloud Pakシリーズを導入するための基盤としてOpenShift Container Platform(以下OpenShift)に一本化となり、OpenShiftを導入した上でCloud Pakシリーズを導入する方式となりました。 Cloud Pakシリーズを導入するためにOpenShiftが前提となるなら、OpenShiftのスキル習得しなくては！ということでOpenShiftの導入スキルを習得することを主な目的として導入の検証をしてみることにしました。 OpenShiftだけを導入したのではCloud Pak導入までの確認ができないため、手順や製品の中身を確認した上で一番導入が簡単にできそうなCloud Pak for Applicationsの導入もしてみよう。ということになったのが今回の検証をすることになった背景です。 OpenShift/Cloud Pak for Applicationsを利用する メリット さて、何故Cloud Pakシリーズを動かすための基盤がOpenShiftに一本化されたのでしょうか？ この説明のためにはIBMの戦略とRed Hatを買収した目的を理解する必要があります。 まず、IBMは企業向け（の中でも特に大企業向け）のソフトウェアソリューション提供を強みにしている会社です。 10年前であればサーバーといえば自社データセンターに置くものでしたがAWSやAzureといったパブリッククラウドが普及し、アプリケーションを稼働させる環境が自社データセンター内に留まらず、パブリッククラウドで動かすことも多くなってきています。 IBMとしても手をこまねいているわけではなく2013年にSoftLayer社を買収し本格的にパブリッククラウド市場へ参入していますが、2020年3月時点のシェアを見ても決して成功している状況ではありません。 そんな中2018年10月にRed Hat社を買収すると発表し、2019年7月に買収が完了しました。 これらの動きから見て取れるIBMの戦略は、どのクラウドであってもIBMソフトウェアを稼働させることができる「ハイブリッドクラウド・マルチクラウド化の推進」です。 それを実現するために、既にAWSやAzure上でもサービスとして提供されているOpenShiftを共通基盤として据えることが必要だったのです。 OpenShift上で稼働するCloud Pakシリーズであればお客様がクラウド上（自社データセンター含む）で動かしたい、といった場合であってもほとんど対応することができ、Cloud Pakのコンポーネントがコンテナ化されているため、単独で提供されている製品よりも可用性・拡張性にも優れます。 Cloud Pakシリーズの中でもCloud Pak for Applicationsはお客様が開発したアプリケーションのモダナイゼーションを支援するツールが含まれており、Cloud Pak for Applications上で現在のアプリケーションを動かしつつ、モダナイゼーション支援ツールを使ってアプリケーションのクラウドネイティブ化を進めることができます。 もちろん、企業として担保すべきガバナンスや品質を維持・向上させるための機能も含んでいます。 このCloud Pak for Applicationsを使うことでアプリケーションをモダナイゼーションし稼働させることができる、ということが大きなメリットです。 導入検証環境 導入検証で利用した環境ですが、今回はAWSを利用しました。 理由としては、IaaSとしてシェアが高いサービスであり、AWS上での知見を得ておくことで構築プロジェクトでも役立てることができると考えたためです。 導入方式 AWS上で検証することを決めたわけですが、AWS上での構築方法を調べると大きく2種類あることが分かりました。 1つはIPI（Installer Provisioned Infrastructure）と呼ばれる方法、もう1つがUPI（User-Provisioned Infrastructure）と呼ばれる方法です。 簡単に違いを上げると、IPIではドメイン名などの初期設定を定義してインストーラーを実行すると自動的にOpenShiftのノードが展開され、利用可能となります。 インストールが自動化されているので展開は楽ですが、設定がある程度固まった状態での展開となるため細かい変更ができません。また、最小のWorkerノード数もAWSの場合では3ノードであるため、導入検証するには少し勿体ないです。 UPIではユーザー自身がロードバランサーやOpenShiftのノードを導入・設定する必要がありますが、設定を自身で決められるので柔軟性が高いといえます。またOpenShiftとしての最小構成でWorkerノード2台の構成とするためには自身でインストール時に設定する必要があります。 今回は最小構成でCloud Pak for Applicationsの導入検証をするため、UPIでの導入検証をしています。 導入検証の環境 今回導入検証をする環境について簡単に説明をします。 環境・サーバー構成の概要図は以下となります。 簡単に構成を説明します。 OpenShift 4.2での導入検証を行うため、Masterノード（Control Plane）を3台が最小構成です（図の中央）。Workerノードは2台となります（図の右側）。 それ以外にはDNSのサービスであるRoute 53でOpenShift用のインターネットドメインを登録・管理しています。（図の左側中段） ユーザーからのアクセスを3台のMasterノードが受けるために外部ロードバランサーが必須で、MasterノードからWorkerノードへのトラフィック用に内部ロードバランサーも構成しています。（それぞれInternetGatewayとControl Planeの間、Control PlaneとWorkerの間） また、永続ストレージ用にNFSサーバーを構築し、OpenShift環境に割り当てすることでデータを保管します。（図の右下） 特長的なのは図の左下にあるBootstrapというサーバーで、OpenShiftのインストールコマンドをインストール作業用PCで実行した後はこのBootstrapサーバーから各ノードへOpenShiftのインストールを実行します。初期導入が完了した後にはこのサーバーを削除します。（図の左下） なので、Bootstrapサーバーは本番運用が始まった時には削除して稼働していない状態となります。インストール専用マシンですね。 インストールを実行するための作業用端末も別途必要となり、こちらはLinuxかMacがOS要件です。WindowsがNGなので用意するのが意外と大変かもしれません。（図の左端） 今回の検証ではVirtual Box上にCentOSを導入し、インストール作業を実施しています。 最後に 第1回目の本記事でCloud Pak for ApplicationsをOpenShift上に導入検証をする目的とその環境・構成がどのようになっているかがご理解頂けたと思います。 第2回ではOpenShiftを実際に導入した手順と苦労した点についてお伝えしますので次回のブログもご覧ください！ お問い合わせ この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社 技術支援本部 E-Mail：nicp_support@NIandC.co.jp 関連情報 全ての企業が AI カンパニーになる！「IBM THINK Digital 2020」に参加した (ブログ) - 全世界から9万人以上の参加者が！ 【やってみた】IBM Cloud Pak for Applications導入してみた：概要編 (ブログ) - シリーズ第1回目！概要編として検証の目的・背景や環境周りをご紹介します。 【やってみた】Cloud Pak for Applications 導入してみた：Cloud Pak for Applications 導入編 (ブログ) - AWS 上に構築した Openshift 環境に Cloud Pak for Applications をインストールしてみました。 今、デジタルサービスに求められる必須要件とは!? アプリケーションのコンテナ化で得られる5つのメリット (コラム) - 今注目されている「コンテナ化」。コンテナ化とは？そのメリットとは？ IBM Cloud Paks シリーズ ご紹介資料 (資料) ※会員専用ページ - 6つの Cloud Paks について、お客様の理解度に応じて必要な資料を選択できる形式になっています。 【外部ページ】 IBM Cloud Pak for Applications (IBMサイト)
皆さま、こんにちは。てくさぽBLOGメンバーの佐藤です。 前回の続きになります。 【てくさぽBLOG】H2O Driverless AIをIBM Power System AC922で動かして競馬予想する（その1） 今回の目的 Driverless AIによって予測した内容と実際の結果を照らしあわせ、予測の精度が有用かどうか検証します。 前回、回帰分析が終了したところまで、書きました。 回帰分析した内容を確認します。 回帰分析結果を確認 イテレーション検証スコア まず、左下の赤枠の中、イテレーション検証スコアから確認します。 こちらの内容はどのくらいの精度で的中するかになります。 0に近づくほど精度が高くなります。 スコアリングについては前回記載した通りMAEやRMSEをご確認ください。 スコアが、2.6021という値ですので、仮にスコアが1として1着予測としても3着程度までが平均精度になります。 特徴量の重要度 次に下中央の特徴量の重要度です。 こちらの内容はどのようなデータを用いて予測するのか？になります。どのデータを元にしどのような割合で利用するのか、予測の調合データです。 上に行くほど高い重要度になりますので、より着順に関係性が深い値ということになります。 一番上の CVTE とは Cross Validation Target Encoding の略で、着順が低いともう一方の数値の傾向があるという関連性を見つけており、CID調教素点は調教データを数値化した指数となります。 つまり、調教が良い状態であれば結果(着順)も良いという事になります。 2行目にご注目ください。 Freq とありますが、Frequency Encoding の略になります。Frequency Encoding とは、こういう条件のときにこうなりやすいという確率です。 例えば、"芝で1枠だと1着になりやすい" といった傾向分析になります。 このケースの場合、"情報指数" "条件" "距離適性" という3つのデータの特定条件が揃うと着順に対して傾向がある事を Driverless AI が発見しています。 Driverless AI の特徴として個々の列データの特徴だけでなく、複数列のデータを組み合わせ新たな条件を作り出せます。 複数の列データの組み合わせ及び抽出条件を様々テストするというのは手作業でやるには大変な労力になります。また人間の目でみて関係なさそうな組み合わせからも有効な組み合わせを発見できる、これが Driverless AI の強味になります。 予測 回帰分析が完了しましたので次は予測してみます。 まずは予測したいファイルを用意します。 今回回帰分析したデータは2020年3月頭までになるため、それより後の日付のデータを用意します。 回帰分析したデータを予測データとして読み込むと予測は可能ですが、非常に高い精度で的中してしまいますので、回帰分析に用いたデータより未来の2020年4月～2020年5月16日までのデータを用意しました。 Experience 画面から他のデータセットを用いて予測を押し、データを選択します。 するとしばらく待った後ファイルダウンロードが始まりますので保存します。 Driverless AI の内部では回帰分析で生成された条件式に従い計算するという作業しますが、答え合わせの処理ですので、回帰分析する時間よりはかなり短い時間で終わります。 少し待った後ファイルダウンロードが始まりますので保存します。 保存したファイルを開くと最終列に "着順.predicted" という列が追加されています。 これが Driverless AI が予測した順位になります。 予測結果は小数点で表示されます。 検証 実際の結果と予測データを照らし合わせます。 的中率を算出します。 今回は3連複、ボックス6頭という Driverless AI の結果の数字が低い順に6頭を選ぶと仮定して当たりはずれを検証しました。 3連複は任意の3頭が1着2着3着に入ることを予測する買い方になります。BOX は任意の数でのすべての組み合わせとなります。6頭BOX ですと20通りになります。 仮に12～18頭レースとすると三連複の組み合わせは220～816通りありますので、単純な確率ですと6頭BOX の場合の的中率は 2.5％～9％ となります。 結果444レース中187レース的中しました。的中率約 41％ となります。 純粋に的中率でいえば、完全なランダムと比較して圧倒的に高い数字ですので、予測は機能してるという事はわかります。 さらに精度を上げる ここからはもう少し結果に対して掘り下げを行います。根気よくデータを見ることによってさらに精度を上げることができます。 今回のケース、条件によって的中率に変化があるのか検証します。 エクセルで頑張りましたが、この作業の時に IBM SPSS のような BIツールがあれば便利ではないかなと感じました。 いくつか見方を試してみたところ、レース番号と距離よって的中率にばらつきがあることがわかりました。 レース番号と的中率の関係 レース番号 レース数 あたり はずれ 的中率 1 37 23 14 62% 2 37 17 20 46% 3 37 16 21 43% 4 37 19 18 51% 5 37 11 26 30% 6 37 16 21 43% 7 37 19 18 51% 8 37 12 25 32% 9 37 16 21 43% 10 37 17 20 46% 11 37 9 28 24% 12 37 10 27 27% レース距離と的中率の関係 レース距離 レース数 あたり はずれ 確率 1000 3 0 3 0.0% 1150 13 5 8 38.5% 1200 76 23 53 30.3% 1300 5 4 1 80.0% 1400 57 27 30 47.4% 1600 57 25 32 43.9% 1700 26 11 15 42.3% 1800 97 40 57 41.2% 1900 4 1 3 25.0% 2000 47 21 26 44.7% 2100 5 2 3 40.0% 2200 11 4 7 36.4% 2300 2 0 2 0.0% 2400 15 11 4 73.3% 2500 1 1 0 100.0% 2600 5 3 2 60.0% 2750 5 2 3 40.0% 2770 5 3 2 60.0% 2880 1 0 1 0.0% 2890 3 1 2 33.3% 3140 1 1 0 100.0% 3200 1 0 1 0.0% 3380 1 1 0 100.0% 3930 1 0 1 0.0% 4250 1 0 1 0.0% 第5レースと第11レースと第12が的中率が悪いため、外してみます。 次に20レース以上ある中で的中率が悪い距離を見てみます。 1200mが30%程で悪いので外します。 276レース中137的中で的中率49.6％という事でほぼ半分当てることができました。 払戻金傾向 払戻金に傾向があるか回帰分析してみます。 今度は配当金のデータを Driverless AI で解析してみます。 やり方は同じで Terget を配当金にします。 "このモデルを解釈" をクリックすると、データの傾向がわかります。 発走時刻で見ますと14:45以降が配当金が高い傾向がわかります。 14時45分以降ですと10R～12Rとなります。 こちらの条件で絞ると、狙い目のレースを絞ることができます。 AC922の優位性 最後に今回のデータを使って、AC922 と一般的な IAサーバとで Driverless AI の回帰分析時間を比較してみました。 条件をそろえるためにどちらもGPUは "無効"、 AC922 については、"48スレッド(Power9は1Coreあたりのスレッド数4)" "メモリ128GB" に制限して実行しました。 【AC922(8335-GTH)】 Power9 2.4GHz~3.0GHz 40コア160スレッド →48スレッドに制限 メモリ1024GB →128GBに制限 GPU NVIDIA V100 16GB ×2 →GPU無効 960GB SSD ×2(RAID1) 回帰分析完了までの時間：2時間39分43秒 【IAServer】 Xeon E5-2680v3 2.5GHz~3.3GHz 12コア24スレッド メモリ128GB GPU Titan RTX ×1 →GPU無効 480GB SSD ×1 回帰分析完了までの時間：4時間23分54秒 まとめ AIで競馬予測のまとめに入ります。 今回、出た予測結果に対して内容を掘り下げることをによって、適用条件を絞ることによりさらに高い精度で運用できる事を確認できました。Driverless AI の結果そのままではうまくいかない場合は範囲を絞って運用し、知見を貯め、追加のデータを用意し、徐々に適用範囲を広げていくのが良いと感じました。 また、AC922 Power9 の強力な演算性能により短時間で終わらせることも確認できました。 お問い合わせ この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社 技術支援本部 E-Mail：nicp_support@NIandC.co.jp
IBMの岡田です。前回の「全包囲網。。。最新 IBMストレージ 概要」はいかがでしたか？ 今回は、今流行りのコンテナ環境とIBMのストレージがどのようにこれらの環境に対応しているのかに触れてみたいと思います。 コンテナって何？ ある調査によると、クラウドファーストを掲げて次々とクラウド環境に IT を移していくといった流れは世界中の ITワークロードの5分の1ほど移ったところで一段落していると言われています。今日では従来型IT環境、仮想化環境、プライベートクラウド環境などのオンプレミス環境と、複数から成るパブリッククラウド環境を上手く使い分ける時代に入ってきたという人もいます。 何れにせよ、今後の IT はこう言った環境の種類に依存することなく、適材適所かつ必要に応じていかなる環境でも同じようにアプリケーション開発や検証ができ、完成されたアプリケーションをどこでも同じように作動させることができ、場合によってはそれぞれの環境で連携して動くと言った技術が必要になってきます。 この要求に応えることができるのがコンテナ技術です。 [caption id="attachment_90768" align="alignnone" width="600"]図1. 仮想環境とコンテナの比較[/caption] コンテナのメリット [caption id="attachment_90871" align="alignnone" width="600"]図2．コンテナを使うことのメリット[/caption] どうしてコンテナ技術を用いるとこれらの要求を解決することができるのでしょうか？ それはコンテナ技術を用いることで、動かすべき対象つまりアプリケーションと、動かすための環境つまりインフラストラクチャーを明確に分けることができ、前者は同じコンテナ基盤であればどこでも同じように動かすことができ、後者はどんなプラットフォームでもこのコンテナ基盤を使えばどこでも同じ動作環境をアプリケーションに提供することができるからです。 別の見方をすると、従来型IT環境では機能要件と非機能要件を分けて考えることが時には困難な場合もありましたが、コンテナ環境ではこれらを明確に分けることができるわけです（図3参照）。 [caption id="attachment_90771" align="alignnone" width="600"]図3. 従来型IT環境とコンテナ環境での考え方の違い[/caption] 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環境を短時間で構築することができます。しかも、商用であるがゆえに保守等もちゃんと付いています。 [caption id="attachment_90872" align="alignnone" width="600"]図4．OpenShift について[/caption] IBM はこの OpenShift をベースに各用途向けにコンテナ化された IBMソフトウェアを搭載し、パッケージ化した6つの IBM Cloud Pak というソリューションを提供しています。 （※詳しくは「製品・ソリューション/ソフトウェア」内で紹介されている、各種 IBM Cloud Pak をご参照ください。） コンテナ環境下でのストレージのあり方 コンテナのメリットは先程ご説明しましたが、その中でも特にポータビリティという点は十分に考えられたソリューションです。 しかし、果たしてそれだけで十分でしょうか？ アプリケーションの作りにもよりますが、普通にコンテナ内のストレージを使いアプリケーションを動かすと、コンテナが不要となり消し去った際データも一緒に消えてしまいます。 複数のコンテナを並列に動かすような作りの場合にはデータを連携する必要があるかもしれません。 [caption id="attachment_90873" align="alignnone" width="450"]図5．永続ストレージの必要性[/caption] つまり、コンテナから独立したデータの器が必要となります。 これが永続ストレージというものです（図5参照）。 最近の IT の記述書などでよく "PV" という文字を見かけます。それは "Persistent Volume" の略であり、永続ストレージはその PV を使って定義づけられます。 では、永続ストレージにはどのような接続形態があるのでしょうか？ 永続ストレージの接続形態 図6で示す通り、永続ストレージにはいくつかの形態があります。ちなみに一番左は通常のコンテナでのストレージのあり方で、この方法だとコンテナと共にデータは消えることとなります。 [caption id="attachment_90773" align="alignnone" width="600"]図6. K8s 環境でのストレージのあり方[/caption] ノード内の永続ストレージという点では OpenShift においては Red Hat OpenShift Container Storage が使われます。こちらはノード依存性がありますので複数ノードにまたがって連携することはできません。 それに対し、外部にストレージを保つ方法があります。ソフトウェア・デファインド・ストレージかハードウェア製品かに関わらず、K8s ノード外にあるストレージを使うため、仮にノードごとに何らかの理由で停止するようなことがあってもデータはキープされます。 （※どのような製品が対応可能かは後ほど触れます。） これらの接続方法は、実は K8s のバージョンによって変わってきます。 ここでは K8s を包含した OpenShift のバージョンでお話しします。 [caption id="attachment_90774" align="alignnone" width="600"]図7. OpenShift のバージョンによる接続方法の違い[/caption] CSI CSI とは Container Storage Interface の略です。K8s のストレージはこうあるべきという考えに基づき、K8s とは独立にプロトコルを標準化したものです。 よって、CSI を使うことで K8s ユーザーはストレージのメーカーや製品を意識することなく同じに使うことができるようになります。逆に言うと各メーカーの優位性を出すことが難しくなります。 とは言え、IBMストレージとしては後述の通りハードウェア製品とソフトウェア・デファインド・ストレージ製品との連携でより便利に使うことが可能です。 IBM のストレージ対応 さて、ここまではどちらかと言うとコンテナ側のお話をしてきましたが、いよいよ IBM のストレージの対応についてお話していきましょう。 ブロックストレージ編 [caption id="attachment_90775" align="alignnone" width="600"]図8. IBM のブロックストレージの CSI 対応状況[/caption] IBM FlashSystem は、IBMストレージのブロックストレージにあたります。 FlashSystem はいち早く CSI にも対応しています。 もちろん FlashSystem 同様 IBM Spectrum Virtualize ファミリーのアプライアンス製品 SAN Volume Controller も、ソフトウェア・デファインド・ストレージとしてクラウド上にポーティング済みの IBM Spectrum Virtualize for Public Cloud も、対応済みです。 オンプレミスとパブリック・クラウド間でのデータ連携も永続ストレージ間で実施できるため、コンテナ上のアプリのポータビリティをオンプレミスとパブリック・クラウドの間でデータも含めて実現することができます。 実際、図2で示したコンテナのメリットは、ちゃんと永続ストレージを使ってどのプラットフォーム上でもできないと完璧にこなすことはできません。これが IBM のコンテナ対応のバリューです。 当然のことながら、フラグシップであるところの DS8000シリーズも CSI 対応済みです。 ファイルストレージ編 次にファイルストレージについて見てみましょう。 [caption id="attachment_90776" align="alignnone" width="600"]図9. IBM のファイルストレージの CSI 対応状況[/caption] 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データの回で詳しくお話することにしましょう。 ソフトウェア・デファインド・ストレージのもう一つの対応 [caption id="attachment_90777" align="alignnone" width="600"]図10. IBM Storage Suite for IBM Cloud Paks[/caption] 現在取り扱っているコンテナ対応済みソフトウェア・デファインド・ストレージを取りまとめて、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月現在取り扱っているものとしてはブロック、ファイル、オブジェクト・ストレージであり、これらすべてコンテナ対応が完了しています。 [caption id="attachment_90778" align="alignnone" width="600"]図11. IBMストレージの OpenShift 対応状況[/caption] Red Hat OpenShift あるいは各種 IBM Cloud Pak においては、接続性も含めて検証済みであり安全にお使いいただけます。 もしコンテナ環境をご検討中であれば、ハードウェアもクラウド上のソフトウェア・デファインド・ストレージもあり上下のデータ連携が可能な IBM のストレージ製品を、ぜひご活用ください！ お読みいただきまして、ありがとうございます。 次回はハイブリッド・クラウド、マルチ・クラウドに適切なストレージについてお話する予定です。お楽しみに！ この記事に関するお問い合わせ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは以下のボタンよりお願いいたします。 お問い合わせ 関連情報 IBMストレージ製品 (製品情報) 全包囲網。。。最新 IBMストレージ 概要 (ブログ) 最新のデータライフサイクル管理とは？（前編）(ブログ) 最新のデータライフサイクル管理とは？（後編）(ブログ) ハイブリッド/マルチクラウド時代だからこそIBMのストレージ (ブログ) AI導入はどこまで現実的？ 5大ハードルとその解決策を解説 (ホワイトペーパー) 普及が進む、機械学習による異常検知。導入の課題はここまで解決している (コラム) .btn_B{ height:25px; } .btn_B a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_B a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }
こんにちは、IBM でストレージ・ソリューション・セールスのパートナー様向け技術支援を担当している岡田です。 今回は IBM の最新情報を交えつつ、IBM のストレージ製品の概要をご紹介させていただき、次回以降でその詳細に触れていきたいと思います。 はじめに 皆さんはどのくらい IBM のストレージ製品にご興味がおありでしょうか？ 興味のあるなしに関わらず、多くの方は知らず知らずのうちに IBM や他のメーカー のストレージ上に様々なデータを書き込んでいることでしょう。ストレージの使用は、あえてデータを保管しようとせずとも無意識に行なっているものです。 例えば… 例えば、コンサートやイベントのチケットなどのケース。 発売当日は予想を超えるアクセス数がありますね。昔ならサーバーを増強してサーバーがパンクしないように対策し、それでもなおかつ処理能力を超えてしまいダウンしてしまったなどという話を聞いたことがあると思います。 しかし今では、クラウド上で一時的に仮想サーバーを増やして難なく対応するというように、時代とともにやり方は変化してきています。 でもその時データを貯めるストレージはどう扱うのでしょう？ オンプレミスでもクラウドでも連携してハイブリッド・クラウド環境でデータをきちんと管理できるのが IBM のストレージです。 また、景品やポイント目当てで今日もスマホからアンケートに答えている方も多いことでしょう。 そのデータは、しばらくは価値のあるデータとして集計やいろんな解析に回されたりするかもしれません。少し時間が経過してもアンケートのコメント欄に書かれた内容を閲覧する人もまだちらほらといるかもしれません。 でもいずれは旬を過ぎたデータとしてどこかに保存だけされ、そのうち不要なデータとして削除しなければならなくなる。 これが、まさにデータのライフサイクルです。 しかし、実際はこのようなデータを正しく管理するのは非常に手間がかかります。場合によってはどこかでミスを起こし、まさかのデータ流出なんてことになりかねません。 データの「揺り籠から墓場まで」を実際にきちんと自動管理できるのが IBM のストレージです。 そして、さらに考えてみてください。そのデータはどうやって守られているのかを。 「守られている」というのには幾通りかの解釈があります。盗まれない・改ざんされないように守るセキュリティ、無くならないように守る信頼性、壊れないように守るインテグリティ、セキュアな移動に耐えうるポータビリティなど、これら「守る」をきちんと管理できる機能があるのも IBM のストレージです。 では、それらを実現する IBM のストレージの概要をみていきましょう。 IBMストレージ製品の紹介 IBM は現在、あらゆるお客様の規模・業種あるいはユースケースなどに対応するためにストレージ製品群を以下の4つのカテゴリーに分けて考えております。 図1. IBMストレージ製品カテゴリー これらのカテゴリーにはハードウェア製品のみならず、IBM Spectrum Storage ファミリーというソフトウェア・デファインド・ストレージ製品もマッピングされています。 IBM はいち早くソフトウェア・デファインド・ストレージに取り組み、今やストレージのみならず、バックアップ、マネージメントと幅広いカバレージで展開しております。 それでは一つ一つ見ていきましょう。 Hybrid Multi Cloud Storage ハイブリッド・マルチクラウド・ストレージに属するものとして、FlashSystem という FlashCore Module（以下 FCM）や SSD などの半導体メモリー系記憶デバイスを活用したストレージ製品群があります。 いわゆるオープン系と呼ばれていた分野は仮想化という過程を経てクラウド時代へ突入しており、コンテナ時代も本格化の兆しを呈しております。この分野で扱うのに適しているストレージ群という位置付けです。 IBM FlashSystem 9200 このラインアップはエントリークラスからハイエンド製品まで、お客様の規模等に合わせた製品を選択でき、なおかつ統一された操作性を実現する製品です。 またこれら FlashSystem の制御機能を外出しした IBM Spectrum Virtualize のパブリック・クラウド版と連携することで、オンプレミスや他のクラウド環境との容易なデータ連携を実現します。 （※詳細は第三回のブログで明らかにします。） 同じカテゴリーに位置する IBM Storage Insights は SaaS として提供される統合ストレージ管理サービスです。 複数の IBM ストレージを一括管理できるだけでなく、他のメーカー様のストレージも管理対象としています。世界中で培われた数多くの知見と AI により提供されるアドバイザリー機能は、ストレージの障害発生率の劇的削減につながります。 AI & Big Data Web Scale という言葉で代表される分野です。 特徴としては IoT のデータのように無限に増えていくデータに対応しうる拡張性、分散保管系、そして広いエリアでファイルやオブジェクトを一意的に扱えるグローバル・ネーム・スペースといったところが挙げられます。 製品で言うと IBM Cloud Object Storage や Elastic Storage System（ひとつ前のモデルまでは Elastic Storage Server と呼んでいました）がこれにあたります。 IBM Cloud Object Storage はオブジェクト・ストレージ機能に特化しており、ペタバイト級のデータを、高信頼性・高可用性・高安全性を保ちつつ扱うことができる分散保管型のストレージで、拡張性にも優れた製品です。業界ではデファクトとなっているオブジェクト・ストレージの AWS（Amazon Web Services）の S3 に準拠した API により、多くのサードパーティーのゲートウェイ・ソフト製品にも対応しております。 IBM Cloud Object Storage はアプラアンス製品としてハードとともに提供しておりますが、評価済みの汎用サーバーをお持ちであればソフトウェアのみでの提供も可能です。また IBM Cloud 上では IaaS としての IBM Cloud Object Storage が月額で使用可能です。 Elastic Storage System は IBM Spectrum Storage 製品のうち IBM Spectrum Scale という分散型ファイル・システムのアプライアンス製品です。GPFS（General Parallel File System）という Power 製品の分野で培った高度なファイル・システムをベースとしており、自動階層化機能、マルチプロトコル対応、拡張性といった特徴のみならず、分散ノードの並列度を上げることで高パフォーマンスな用途にも対応できます。 今日時点最新である2019年11月18日発表のスーパーコンピュータ性能ランキング「TOP 500」で、1位2位を独占する Summit という IBM のスーパーコンピュータにも搭載されている優れものです。 （※次回以降、階層化機能を中心に明らかにします。） また AI や BigData を扱うエリアでは、膨大なデータにおけるカテゴライズや検索といったことが重要になってきます。 通常はシステムにより自動付加される情報に頼ることが多いですが、メタデータ、タグ情報といったもので効率的にデータを扱える仕組みがあります。このメタデータやタグ情報を管理できるのが IBM Spectrum Discover で、上記2つの製品群と一緒に使われることでデータにより一層の価値を持たせることが可能となります。 Modern Data Protection 一番わかりやすいのがモダン・データ・プロテクションのエリア。災害や障害に耐えうるバックアップやディザスター・リカバリーに特化した製品群です。 いかに短い時間で効率的にバックアップを取得するかということは当然のことながら、いかにロス無く早くシステムを復旧できるかということが重要になってきます。 また、以前より障害やヒューマンエラー、災害対策、争乱と対象が発展し、今やサイバー攻撃にも対応する必要が出てきました。 さらに守るべき対象もオンプレミスだけではなく有機的にクラウドと結びついている場合もあり、これらに対応していくということが、まさにモダン・データ・プロテクションたる所以であります。 ここでの中心となるのはテープ製品群です。 現在の企業向けテープ規格のスタンダードと言えば LTO（Leaner Tape-Open）を思い浮かべる方が多いと思いますが、IBM は規格立案時代より中心的に関わっており、LTO および企業向けに発展させた 3592エンタープライズ向けテープ（IBM 独自フォーマット）の2本立てのテープカートリッジ規格に対応した製品群を扱っております。 IBM TS4500 Tape Library 同じカテゴリーの IBM Spectrum Storage ファミリー製品としては、IBM Spectrum Protect というバックアップ・ソリューション・ソフトウェアがあります。 これは Tivoli Storage Manger というバックアップ・ソフトを Spectrum ファミリーに統合したもので、長い歴史と実績を持っています。完全なる永久増分バックアップ機能と各種データ圧縮機能を用いることでバックアップ容量およびバックアップ時間を格段に削減することが可能です。 仮想サーバー環境に特化した IBM Spectrum Protect Plus という製品もあり、すでにいくつかのパブリック・クラウド上での月額使用も可能となっております。 昨今、テープ装置は物理的にシステムから切り離すことができるストレージとして、「エアー・ギャップ」という言葉のもと、サイバー攻撃にも耐えうるソリューションとして見直されつつあります。 （※詳細は第五回のブログで明らかにします。） Storage for Z IBM のフラグシップとも言えるメインフレーム製品にも対応するハイエンド・ストレージ機器群となります。 技術の結晶とも言われるこの分野の製品は信頼性・可用性共に高いレベルにあり、過去から現在に至るまで世界中の経済を支えてきたと言っても過言ではありません。 DS8000 シリーズはホスト製品のみならず、オープン系の分野も含め 2000年代初頭から現在までの長い間、高可用性・高性能の分野で一役を担ってきました。 遠隔のストレージ同士をミラーリングするという考えは、もともとホスト系ストレージ・システムで行なっていた PPRC、XRC と呼ばれるミラーリングに始まり、現在の Metro Mirror、Global Mirror といった同期・非同期のミラーリングに受け継がれているもので、今ではエントリー製品にもあたりまえのように使われる技術となっています。 IBM DS8900F DS8000 シリーズは今でも進化しており、最新ラインアップ DS8900F シリーズではオール・フラッシュ製品に変化を遂げ、超低遅延・高可用性の他、クラウドとの連携やマルウェア・ランサムウェア対策など最新の技術を投入され、今後のIT環境にも活用いただけるフラグシップ製品です。 図2. IBMストレージ製品ポートフォリオ まだまだ説明したい製品がありますが、別の機会にご説明させていただきたいと思います。 おわりに 今後も、以下のようなテーマでブログを掲載させていただく予定ですのでお楽しみに！ （もしかしたら突発的な話題や多少の変更はあるかもしれませんがご了承ください。） 第二弾：「OpenShiftに代表されるコンテナ環境へのIBMストレージの対応」 第三弾：「ハイブリッド/マルチクラウド時代だからこそIBMのストレージ」 第四弾：「最新のデータライフサイクル管理とは？（前編）」「最新のデータライフサイクル管理とは？（後編）」 第五弾：「データを守ることについて」 このブログで少しでも IBM のストレージ製品にご興味を抱いていただけると幸いです。 この記事に関するお問い合わせ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは以下のボタンよりお願いいたします。 お問い合わせ 関連情報 IBMストレージ製品 (製品情報) 全包囲網。。。最新 IBMストレージ 概要 (ブログ) 最新のデータライフサイクル管理とは？（前編）(ブログ) 最新のデータライフサイクル管理とは？（後編）(ブログ) ハイブリッド/マルチクラウド時代だからこそIBMのストレージ (ブログ) AI導入はどこまで現実的？ 5大ハードルとその解決策を解説 (ホワイトペーパー) 普及が進む、機械学習による異常検知。導入の課題はここまで解決している (コラム) .btn_B{ height:25px; } .btn_B a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_B a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }
こんにちは。てくさぽBLOGメンバー山田です。 2018年はラスベガス、2019年はサンフランシスコと、アメリカの主要都市で開催されていた「IBM Think」ですが、2020年は COVID-19 の影響でデジタル開催となりました。 エンターテイメント的な高揚感や全世界から集まる参加者の熱気を体感できなかったものの、機械翻訳による日本語字幕やアジア地域の時間帯に合わせた配信などの新しい試みも随所にあり、2年連続して参加した私も今回は自宅から参加することになりました。 デジタル配信とはいえ9万人もの事前登録があり、現在もオンデマンドで100以上ものセッションが視聴可能です。 Think 2020 オンデマンドはこちら。（※IBMid が必要となります） IBM サイト：「Think Digital Event Experience -On Demand Sessions-」 ハイブリッド・クラウド、AI、5G が DX を牽引する 4月に新たに CEO となったアービンド・クリシュナ氏は、以下のように語りました。 "ハイブリッド・クラウド、AI そして 5G といったテクノロジーが企業のデジタル変革を牽引し、このパンデミックな状況が重要な転換期となって適応スピードがさらに加速する。" クリシュナ氏の講演では、ハイブリッド・クラウドと AI が実現する新しいソリューションとして以下の3つの発表がありました。 IBM Watson AIOps エッジ・コンピューティング 金融サービス向け ISV提携 エッジ・コンピューティングについては後程ご紹介しますが、5G の活用や金融サービスの ISV提携など、この数年の発表としてはインダストリー色が少し強くなった印象があります。 IBM Watson AIOps は、2019年の Think で紹介されたテクノロジーやコンセプトが具現化された製品のように思えました。 2019年の Think では AI関連のセッションは省力化についてフォーカスされたものが多く、Watson を手組で取り入れながら個別のプロジェクトで対応する、または PoC での評価段階だったように感じていたためです。 今年の Think では、効率化に加えて "スピードと自動化" の重要性がより前面に出ていたように感じました。 COVID-19 発生のような、予測や分析が難しく人々が自由に動けなくなってしまうような事態であっても、事業は継続しなくてはなりません。そのためには業務プロセス全体の効率化を考えるとともに、AI による運用自動化のような取り組みが必要ということでしょう。 今回発表された IBM Watson AIOps は、まさに AI を IT インフラのオペレーションに組み込んだソリューションです。既存の IT 運用ツールを置き換えるものではなく、それらをデータソースとして AI が働き、異変を検出、対処方法の診断・自動化が可能となります。 図1：IBM Watson AIOpsの概念 エンタープライズの世界では企業 IT の世界では予期しない IT ダウンタイムの発生によって、年間約2.8兆円規模の損失が発生していると言われています。予兆検知により早期にトラブルを予測できれば大きなアドバンテージとなりますし、IT オペレーションの自動化を促進することで、IT 人材不足の課題にも対応できます。 また、ユーザーインタフェースに Slack を採用することで "ChatOps" が実現され、同時に他システムとのプロセス連携/自動化のための API も提供されるなど、まさに "オペレータをスーパーマンにする" ソリューションと言えます。 図2のように、インシデントや緊急停止の件数、顧客のロイヤリティ（NPS：Net Promoter Score）や従業員の満足度といった CIO の指標を改善することで、CIO を支援するソリューションであることも強調していました。 図2：セッション "Keeping IT Costs Down While Still Delivering Impact" より抜粋 当製品は OpenShift ベースの IBM Cloud Pak for Data 上に構築されているため、ハイブリッド・クラウド環境のどこにでも展開でき、日本では2020年内に提供開始予定です。 エッジ・コンピューティングへの拡がり "一度作ったアプリケーションがどこでも動かせるというオープン性の価値と、それを実現する統合プラットフォームの IBM Cloud Paks、そして統合プラットーフォームの中心に RHEL と OpenShift がある。" これは、クリシュナ氏とともに4月に新社長に就任した 元 Red Hat 社 CEO のジム・ホワイトハースト氏のメッセージです。 またエッジ・コンピューティングについては、工場や空港などの現場（＝エッジ）で生まれるワークロードに対してもデータや AI の取り組みが必要であり、コンテナベースでアプリケーションが構築されるようになると述べられました。 5G のテクノロジーと組み合わせて、ポリシーを使ったコンテナ・アプリケーションの自動配布やライフサイクルの自律的な管理を可能にするユニークなソリューション「IBM Edge Application Manager」の発表がありました。 図3：IBM Edge Application Manager 4.1 architecture 欠かせないパートナー様とのエコシステム 従来は IBM ビジネス・パートナーのエグゼクティブしか参加できなかった PW at Think も、今回はデジタル配信ということで視聴することができました。 興味深かったのは、パートナー様の収益の 58％ は⾃社の知的財産から生じていることや、マネージドサービスに対するお客様の需要は伸びており、2019年にクラウドサービスの再販が 17％ 以上増加した、という IDC データの紹介でした。 そういった分析結果を踏まえ、構築（Build）、サービス提供（Service）、販売（Sell）といったパートナー様のビジネス・モデルに合わせた支援サービスが発表されており、常に IBM が、顧客の多様化したニーズに応えるにはビジネス・パートナー様とのエコシステムが必須であるとメッセージし、エコシステムのための施策もしっかり打ち出していると改めて感じました。 図4：セッション "IBM Partner Ecosystem: The Power of Ecosystem" より抜粋 さいごに ほんの数年前にはあこがれのような存在だった AI が、「Watson Anywhere：どこでもWatsonが使える」、そして「全ての企業が AI カンパニーになる。それは必然だ。」と、更に身近で、かつ避けられない存在になったことを実感したイベントでした。 来年の Think でどんな新しいメッセージが聞けるのか、今から楽しみです。
こんにちは。 てくさぽBLOGメンバーの瓜谷です。 最近、クラウド上のソフトウェアのライセンス購入に関して 「自社で購入して持ち込んでいいの？」 「オンプレミス環境と同じ種類のライセンスでいいの？ 」 「いくつ購入すればいいの？ 」 といったお問い合わせが増えてきています。 そこで、よくお問い合わせいただくIBM Cloud ベアメタルへのWindows ServerとRed Hat Enterprise LinuxのOSの持ち込みライセンスの考え方についてご説明したいと思います。 IBM Cloud ベアメタル環境への持ち込み可否 「IBM Cloud ベアメタル環境へOSのライセンスを持ち込めるの？」に関して、結論から申しますと “Yes” です。 ただし、持ち込むOSによっては、オンプレミスで使用しているエディションが使用できない場合があります。 では最初に、IBM Cloud ベアメタルで使用できるOSのエディションの種類を説明します。 Windows Serverのエディションには、下記の2つがあります。 Windows Server DataCenter Core 2ライセンス ⇒"持ち込み可" Windows Server Standard Core 2ライセンス ⇒"持ち込み可" この2つのエディションに関しましては、両方ともIBM Cloud ベアメタルへ持ち込むことが出来ます。 Windows Serverの場合には、エディションの種類を考慮しなくてもよいことなります。 それでは、次にRed Hat Enterprise Linuxを見ていきましょう。 Red Hat Enterprise Linuxのエディションには、下記の2つあります。 Red Hat Enterprise Linux Server ⇒"持ち込み可" Red Hat Enterprise Linux for Virtual Datacenters ⇒"持ち込み不可" 残念ながらRed Hat Enterprise Linux for Virtual Datacenters(ゲストOS無制限)は、IBM Cloud ベアメタルへの持ち込みはできません。 Red Hat Enterprise Linuxの場合には、オンプレミスとクラウドでライセンスポリシーが違うので注意が必要です。 IBM Cloud ベアメタルへの持ち込み可能なOSのエディションの種類がわかったところで、次に「IBM Cloud ベアメタルへ持ち込むOSライセンスの考え方」を説明します。 IBM Cloud ベアメタルへ持ち込むOSライセンスの考え方 Windows Server とRed Hat Enterprise Linux Server は、IBM Cloud へ持ち込む場合でもオンプレミス環境と同じカウント方法になります。 【Windows Server を仮想OS上で使用する場合】 Windows Server のライセンスは、仮想OSが搭載されているサーバのCPUのソケット数とコア数やゲストOS数によってライセンスの数量が変わってきます。 ここでは、一番問い合わせが多い2CPU以下のサーバを例にとって説明します。 ■Windows Server DataCenter Core 2ライセンスの場合 このライセンスは、サーバにゲストOSを無制限に搭載することができます。 そして、ライセンスの数量を考えるには、2つのルールがあります。 ２コアで1ライセンスとして算出します。 １．サーバのCPUの合計コア数が16コア以上の場合には、合計コア数必要 ２．サーバのCPUの合計コア数が16コア未満の場合、16コアとして計算 上記1、2の説明に対する図を、下の図1に示しています（説明1は左側の図、説明2は右側の図です） ■Windows Server Standard Core 2ライセンスの場合 このライセンスは、サーバのCPUの合計コア数とゲストOS数によってライセンス数が変わってきます。 サーバのCPUの合計コア数分のライセンスで、ゲストOS2つまで使用できますが それ以上使用する場合には、サーバのCPUの合計コア数分のライセンスを加算することでさらにゲストOS2つ追加して使用することができます。 ２コアで1ライセンスとして算出します。 ライセンスの数量の考え方の例を3つにまとめます。 １．サーバのCPUの合計コア数が16コア以上の場合には、合計コア数でゲストOSを2つまで使用可能 ２．サーバのCPUの合計コア数が16コア未満の場合、16コアとしてゲストOSを2つまで使用可能 上記の１と２を式にて表現してみると次のようになります。 変数α = サーバのCPUの合計コア数(但し、16コア未満の場合には16コアとして計算します) 変数β = ゲストOS数(但し、ゲストOS数が奇数の場合には+1にして偶数にします) ライセンス数 = 変数α ÷ 2(2コアライセンスのため) × 変数β ÷ 2(2ゲストOS毎のため) ３．サーバ毎に、最大ゲストOSを数えて計算(待機系であっても課金対象) 上記1、2、3の説明に対する図を、下の図2に示しています（説明1は左側の図、説明2は真ん中の図、説明3は右側の図です） 【Red Hat Enterprise Linux Serverを仮想OS上で使用する場合】 Red Hat Enterprise Linux Server は、仮想OSが搭載されているサーバのCPUのソケット数とコア数は関係なく、搭載するゲストOSの数量によってサブスクリプション数が決定されます。 ■Red Hat Enterprise Linux Serverの場合 ライセンスの数量を考えるには、3つのルールがあります。 １．サブスクリプション毎に、2ゲストまで使用可能 ２．稼動するRed Hat Enterprise Linux Server のOSの数量の合計で課金 ３．同時稼動するRed Hat Enterprise Linux Server OSの最大数で課金 上記1、2、3の説明に対する図を、下の図3に示しています（説明1は左側の図、説明2は真ん中の図、説明3は右側の図です） 最後に 皆様、 IBM Cloud ベアメタルへのWindows ServerとRed Hat Enterprise LinuxのOSの持ち込みライセンスの考え方は、ご理解いただけましたでしょうか？ 「意外と簡単だった！」 「理解できたけど、数を数えるの間違えちゃいそう！」 人それぞれ感想が異なるかと思います。 ここで注意してほしいのは、クラウド業者やOSのメーカーによって、持ち込みの可否や購入する際のルールや考え方等は異なるということです。 また、バージョンが変わることでライセンスのポリシーが変更になることもありますので、その都度確認が必要です。 常にライセンス見積に携わっていない方は「調べるのが大変！面倒！」と思われるかもしれませんが、そんな時はNI+C Pに是非ご相談ください。 また、クラウドに関わらず、●●●のライセンスの考え方を掲載してほしい等のご要望等ありましたらご連絡ください。要望が多いものから掲載していきたいと思います。 お問い合わせ この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社 技術支援本部 E-Mail：nicp_support@NIandC.co.jp 商標帰属 すべての名称ならびに商標は、それぞれの企業の商標または登録商標です。 ※上記の記載は、2020/5/11現在の内容となります。
