特集・ブログ
皆さま、こんにちは。てくさぽBLOG メンバーの 岡田です。 エヌアイシー・パートナーズでは2016年からCisco Unified Computing System（以下、UCS）の取り扱いを始めています。 UCSが発表されてから既に10年以上経っておりますが、再びUCSが注目を浴びています。今回は、これからUCSを検討しようとお考えの皆さんに向けて、その特徴やメリットをお伝えします。 １． Cisco UCS とは ずばり、Cisco社製のIA（Intel Architecture）サーバです。 Intel製CPUが搭載されているので、Windows Server/Linux/VMware ESXiなどの、Intel CPU用のサーバOSがUCS上でも稼働します。 では、なぜネットワーク機器のベンダーであるCiscoがIAサーバを出したのでしょうか。 仮想化が一般化した現在のデータセンターでは、サーバ、ネットワーク、ストレージ、アプリケーションといった各構成要素を個別に構築、デザイン、最適化するサイロ型になっています。その結果として、各コンポーネント個別の管理となり、管理者間の連携の煩雑さや環境変更時の検討項目・調整・検証期間工数の増大が大きな課題となっています。 これらの問題を解決するために、UCS は、仮想環境やクラウド環境で利用されることを念頭に置き、すべてのコンポーネントを全体最適化されたアーキテクチャの下に統合することで、複雑さをなくし、リソース管理を容易にし、最適な仮想環境を実現しています。つまり、サーバやネットワークを大きな１つのリソースとして一元管理することにより、管理・運用がしやすくなるということです。 （UCSの全体最適化されたアーキテクチャ） ２．他社IAサーバとの違い では、UCSは他社IAサーバと比べて、どんなところが違うのでしょうか。UCSが他社IAサーバと異なるところは主に以下の３点になります。 ①ファブリックインターコネクト ユニファイドポートという1Gbまたは10Gbのイーサネットポート、またはファイバーチャネルポートのどちらにも設定できるスイッチポートを搭載したスイッチです。一般的なIAサーバでは、ネットワークスイッチとファイバーチャネルスイッチそれぞれに接続しますが、UCSサーバは基本的にこのファブリックインターコネクトとのみ接続します。 ②UCS Manager ファブリックインターコネクトに搭載された統合管理コンソールです。接続されたBladeサーバ、ラックサーバを一元管理します。 ③サービスプロファイル UCSでは、サーバのハードウェア各種設定情報をサービスプロファイルとして保持し、これを実際のハードウェアに関連付けることでサーバやネットワークの設定を行います。 ④Intersight Intersightはオンプレミスにある複数のCisco UCSやHCI製品のHyperFlexを統合的に管理するためのSaaSサービスです。地理的に離れた環境にある複数システムを一元管理できます。SaaSサービスなので管理サーバーを用意する必要がなく、管理者はどこからでも管理ダッシュボード画面にアクセスできます。 このような違いを持つUCSを選択すると、どのようなメリットがあるのでしょうか。 ３．UCSのメリット シンプルな構成 UCSサーバはファブリックインターコネクトとのみ10Gbイーサネットケーブルで接続します。この10Gbイーサネットケーブルの中に、イーサネットとファイバーチャネルの両方のプロトコルが流れます。 これにより、ラック背面のケーブル本数が激減し、より適切なエアフローと低い消費電力を実現します。この結果として、データセンターのファシリティコスト、配線コスト、配線トラブルを削減できます。 管理ポイントの削減 UCSでは、サーバやBladeシャーシ毎に管理モジュールを持たず、ファブリックインターコネクト上にあるUCS Managerで一元管理されます。これにより、台数が増えても管理ポイントはUCS Manger１箇所のみのままですので、管理対象が増えません。これにより、個々の機器毎に管理する必要がなくなり、管理工数を削減できます。 シンプルな運用 サービスプロファイルを利用することで、構築時や障害発生における機器交換時において時間がかかっていたハードウェア設定作業を大幅に削減することが可能になります。他社IAサーバでは、サーバ導入時にさまざまな設定を個々に実施する必要がありますが、サービスプロファイルを利用するとハードウェアにプロファイルを割り当てるだけでハードウェア設定が完了します。また、機器が届く前にMAC アドレスなどの予約や、BIOS の設定を先にやっておくといったことも可能になります。 ラックマウントサーバの統合 ファブリックインターコネクト配下に接続することで、UCS Managerによる統合管理機能を、サーバ形状を問わずに一元管理可能になります。 このような特徴を持つUCSですが、エヌアイシー・パートナーズでは日本IBM社が取り扱う、IBM保守のUCSをお勧めしています。 ４．IBM保守 UCSの特徴 IBM技術員によりオンサイト保守を実施します。 スペシャリストによりリモート問題判別支援をおこないます。 保守時間帯の選択が可能です。 UCSの運用を支援するオプション（交換したハードディスクのお渡しサービスと部品2時間配送サービス）を追加できます。 ５．まとめ いかがでしたでしょうか。UCSはサーバメーカーとしては後発であることのメリットを活かして、これまでのIAサーバが抱えていた課題を解決できるソリューションを備えています。これにIBM保守を加えることで、ネットワーク機器からサーバまで保守をまとめてIBM社に一元化することができます。現在のデータセンター運用に課題を抱えたお客様にはぜひUCSをご検討ください。 また、エヌアイシー・パートナーズではUCSとIBMストレージ、ネットワークスイッチ等の複雑な組み合わせでの構成でも対応可能です。ご相談からお見積り依頼まで、遠慮無くお申し付けください。 最後に、弊社サイトのUCSページにてラインナップや支援内容などを記載していますので、こちらももぜひ御覧ください。 https://www.nicpartners.co.jp/products/72456/?from_category=category_all 【変更履歴】 2020/12 Intersight説明を追加。弊社サイトのUCSページへのリンクを修正。 この記事に関する、ご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社 技術支援本部 E-Mail：nicp_support@NIandC.co.jp 商標帰属 ・すべての名称ならびに商標は、それぞれの企業の商標または登録商標です。
IBM の岡田です。 いよいよシリーズ物、最後のテーマまでやってきました。 ここまでの内容はいかがでしたでしょうか？もう少しで完結しますので、最後までお付き合いいただければと思います。 さて、今回のテーマは「データを守ることについて」ということで、様々な脅威からどうやってデータを守るか、という内容でお届けします。 データを脅かす脅威とは 一昔前までは、データの脅威といえば人為的オペミス、装置の故障・障害、災害などが挙げられてました。しかし、最近はこれに加えサイバー攻撃といったものも加わってきております。 今まではサイバー攻撃というと、ネットワークあるいはサーバーにて対処すべきもの、という考え方が主流だったかと思います。これらはサイバーセキュリティという範疇の対策であり、今までも多くの製品やサービスによって培われてきた技術です。 しかし、昨今のサイバー攻撃はマルウェアが主流となっており、特にランサムウェアと呼ばれる攻撃が世間的にも目立ち始めてます。企業のデータを強制的に暗号化し解除するための身代金を要求するというものです。 確か最近ニュースで、日本での被害のとんでもない状況を目にした覚えがあります。調査対象の半数以上の企業は攻撃を受けた経験を持ち、実際に身代金を払った会社も調査対象の約3分の１あったということ、また、本当に支払われた身代金も平均が億を優に超える金額だったことに筆者も驚きました。 ということで、今回はストレージ技術にできるデータの保全について、従来の物理的な脅威から守ること、今日のサイバー攻撃から守ることの2つに分けてお話していきます。 物理的な脅威からデータを守る 止まらないシステムを構築するために、IT の世界では様々な対策が体系化し今日に至ってます。 全ての ITインフラを成す要素を冗長化するといったものはごく当たり前で、IT技術者なら必ず取っている対策ですね。機器自体も各パーツが冗長化されいつでもホットスワップでパーツ交換できるような仕組みになっているのが現在の IT機器です。 このように、シングルポイントになり得る構成をできる限り排除することで物理的な機器の障害や故障からシステムを守る、というのが今時当たり前のシステム設計なのはご存知の通りです。 データについてはどうでしょう。 システム構成の一部としてデータの通り道も冗長化されているのが昨今の設計ですが、データを貯める場所、つまりストレージについては過去より多くの技術が使われてきております。 パーツとしての HDD 等に用いられる磁気ディスクの盤面に書き込む際のフォーマットについては、ECC（Error Check and Correction）と呼ばれる技術、すなわちデータをビット化けや傷・汚れなどによるディスク上の脱落から計算により正しいデータを導くテクノロジーが用いられております。 さらに上のレイヤーでは、HDD や SSD などデイバイスの故障に対応するために、RAID といった技術が使われていることも多くの IT技術者はご存知でしょう。 最近は大容量下での再構成の長時間化などを改善するため、各社独自の RAID技術を駆使していたり、イレージャーコーディングといった、今まではディスク盤面などミクロな世界で行われていたような ECC をベースとした考え方を、装置・筐体といったレベルまで広げた技術などが使われ始めています。 最近のストレージ装置はユーザーに開放している論理ボリュームに対して、そのコピーを複数個筐体内に取って世代管理することもありますし、筐体間レプリケーションで別の安全な場所にコピーを取るということもできます。 そして、昔からあるオーソドックスな方法としては、ある時点のデータを静的に固めて安全な媒体に書き出して取っておく、所謂、バックアップが一番一般的ではないでしょうか？ しかし、実はバックアップ技術も1990年代のような、ただテープ媒体などに静的データを単純にとれば良いという時代はとっくに終わっており、今やバックアップ先データ容量を極限まで抑える技術であったり、転送を効率的に行う技術であったり、いろいろな技術が併用されております。 少し簡単に紹介しましょう。以下にご紹介するのは IBM Spectrum Protect と呼ばれるバックアップソフトで使われている技術です。 1. 永久増分バックアップ 初回バックアップのみフルバックアップを取り、その後のバックアップは増分（差分）のみ。 こうすることでバックアップ先データに必要な容量を格段に節約することができますし、このデータを遠隔にレプリケーションする際もデータ量が少ないため、ネットワークに余計な負担をかけずに済みます。 図1. 永久増分バックアップ 2. 重複排除・圧縮技術 すでに枯れた技術で、ストレージ装置にも使われているものですが、特に重複排除については過去のバックアップデータとの重複もあるので、さらに効果が見込まれます。 また、VM などの仮想環境でも似たディスクイメージを扱うことで、重複排除率は格段に上がります。 図2. 重複排除 3. FASP技術 バックアップデータを DR 目的で遠隔に飛ばす際には、ネットワーク帯域を通常の TCP/IP より効率的に使用できる FASP（Fast Adaptive Secure Protocol）により、高速転送が可能となります。 図3. FASP転送 4. 今時のバックアップ先ストレージ バックアップのとり先といえば、昔はテープ、そしてディスクの時代があり、最近はまたテープが見直されてきています。 理由はもちろんビット単価であったり可搬性であったりが主ですが、後述するサイバー攻撃対策としても最近は注目されています。 最新技術活用という点では、クラウドのオブジェクトストレージにバックアップするというのも出てきています。その基本的な3形態を示したのが次の図です。 図4. バックアップ3形態 悪意のあるサイバー攻撃からデータを守る ここまでは、レガシーな考え方、つまり物理的な脅威への対策としての最新のバックアップ技術です。 ところが昨今はこう言った脅威のみならず、意図的なデータ破壊や改竄への脅威、つまりサイバー攻撃への対策というものが必要になってきています。 そもそも色々な技術の蓄積で現在のサイバーセキュリティ成り立っていますが、攻撃者とのいたちごっこであることは否めません。したがって、突破された際の対策というものも必要になります。 最近のデータによると、実際にハッカーあるいはマルウェア等に侵入されたことが発覚するまでの日数は数百日とも言われており、わかった時にはすでに多くのデータの破壊・改竄・漏洩がなされた後、ということになりかねません。 このうち、破壊・改竄はデータが失われる訳で、データを使った企業活動ができなくなるという致命的な結果になり得ます。ゆえに、破壊・改竄（ランサムウェアによる強制的暗号化も含む）への対策が必要となるわけです。 図5. サイバー攻撃の際、データが役に立たなくなる 多くの場合、ネットワーク越しにサイバー攻撃が行われます。つまり、バックアップがあるから大丈夫と思っていても同じネットワーク内にあれば同様に犯された使えないバックアップデータとなる可能性が出てきます。 そこで、覚えていただきたいキーワードがあります「エアギャップ」と「イミュータブル」。 サイバーレジリエンシーの基本的な考え方です。 図6. エアギャップ・イミュータブル 前者は、ネットワーク的なつながりのない場所・物・仕組みを指し、後者は、改竄できない場所・物・仕組みをさしています。 つまり、バックアップなどの最後の砦となりうるデータは、こういったエアギャップ対応、あるいはイミュータブル対応のなされたメディア・機器・場所・仕組みなどに置くことで、初めてサイバー攻撃からデータを守るということができるわけです。 もちろん RPO がゼロになるわけではないので失うものも若干ありますが、億単位の身代金を支払うことからは救われます。 RPO をゼロに近くするためには当然、検知能力を上げる他ありません。 サイバーセキュリティで 100％検知できればこのような不幸は起こりませんが、万一気づかずネットワーク内に攻撃が入ってしまった場合も、データ側の仕組みで検知することもできるかもしれません。以下に二つの検知技術を紹介します。 図7. IBM Spectrum Protect の検知機能 こちらは、定常状態と大きなデータの変化のあった状態との差からサイバー攻撃の可能性の有無をチェックする機構です。 データが暗号化されたり破壊されたりすると、直前のバックアップデータとは大きく異なるデータとなるため、当然の事ながら重複排除率は極端に低くなります。さらに、圧縮率やファイルの増加数など、定常時とは異なる変化が現れるでしょう。 そういった変化を検知することで、データに何か大きな変化があったこと、すなわち破壊・改竄の可能性をいち早く検知することができるわけです。 次に、例えば IBM の Spectrum Scale には File Audit Logging という機能があります。 これをサイバーセキュリティの仕組みで検知系に繋げてあげれば、いち早くおかしなデータから本番データを守ることができるわけです。 図8. IBM Spectrum ScaleとQradar によるサイバー攻撃の検知 サーバー攻撃と対策のいたちごっこは、これからも続いていくでしょう。 しかし、アンチウィルス系の対策のようにウィルス自体のシグネーチャーやパターンに頼った対策は、必ず後手となります。そういう意味で、定常状態との変化で検知する方法は非常に有効な手段かと思われます。 ぜひ有効な対策を打って、備えを万全にしていきましょう！ 約半年にわたってブログを書かせていただきましたが、少しでも IT を担う皆様にお役に立つことができると幸いです。 ありがとうございました！ この記事に関するお問合せ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは、「こちら」からお願いします。 参考ページ IBMストレージ製品 全包囲網。。。最新 IBMストレージ 概要 OpenShiftに代表されるコンテナ環境へのIBMストレージの対応 ハイブリッド/マルチクラウド時代だからこそIBMのストレージ AI導入はどこまで現実的？ 5大ハードルとその解決策を解説 普及が進む、機械学習による異常検知。導入の課題はここまで解決している (IBMサイト) データ・ファーストのハイブリッドクラウド基盤を実現するIBMストレージ (IBMサイト) ハイブリッドクラウドにおけるデータ連携の鍵を握るもの
こんにちは。てくさぽBLOG新メンバーの佐藤です。 最近でも、10GbpsEtherを含めたサーバの構成依頼を多くいただきます。 種類がいくつかありますので、どの10GEtherにしましょうか?と確認すると 種類が多すぎてどれにしていいかわからない、どうお客様にヒヤリングしていいかわからない といったお困りの声が多いため 今回は、何を選定していいか迷ってしまいがちな「10GbpsEther」について改めて解説いたします。 10GbpsEtherとは？ 読んで字の通りですが従来のGbitEtherの後継で10倍の転送速度を持つEtherとなります。 10GbpsEtherの難点は複数の種類があるところです。 代表的なものを以下にあげます。 なお、これ以外にもありますが現在あまり販売していないもの、WAN回線用の長距離通信の規格については除いています。 ･10GBASE-T ･10GBASE-SR ･10GBASE-LR ･10GBASE-SFP+ それぞれについての技術的な解説等は多数のサイトにお任せするとして 本ブログでは、 何を選択すればいいか?に焦点を絞って解説致します。 10GbpsEtherを選定する際は基本的には以下の2つの要素から決めます。 1.汎用性 2.配線距離 1.汎用性 2016年8月現在、サーバに搭載する10GbpsEther汎用性ランキング＊は以下の通りです。 ＊個人的な感覚を含みます。 ランキング 名称 成長率 1位 10GBASE-SFP+ → 2位 10GBASE-T ↑ 3位 10GBASE-SR → 4位 10GBASE-LR → 1位は10GBASE-SFP+としています。 今買うのであればもっとも普及しており、汎用性が高い規格となります。 スイッチの種類も豊富です。 ただし、今後は10GBASE-Tの動向次第といったところです。 2位の10GBASE-Tは、期待を背負って最後に登場した規格となりますが 様々な理由から穏やかに成長しており、価格的にも今のところは10GBASE-SFP+と同じくらいです。 しかしながら、RJ-45コネクタおよびメタルケーブル接続という潜在的なコストメリットは最も高いため、今後普及がさらに進めば価格が下がることが期待されます。 3位以下は次にあげる配線長の理由が無い限り特に大きなメリットが感じられません。 2.配線距離 各規格の最大配線長は以下の通りです。 配線長 名称 種類 ~10m 10GBASE-SFP+(Cu Twinnax) メタル ~100m 10GBASE-T メタル ~300m 10GBASE-SR 光(MMF) ~10km 10GBASE-LR 光(SMF) SFP+(Cu Twinnax)はダイレクトアタッチケーブルと呼ばれるものです。 最大10m以下となりますので、実質ラック内配線専用となります。 10GBASE-Tの最大長は最も高品質なCat6a/Cat7ケーブルを使った場合で100mまで、Cat6/Cat6eですと55mまでとなります。 そのため、データセンターなどの広いフロア内の配線や、上下階配線ではやや物足りない長さとなります。 10GBASE-SRはOM3という高品質光ケーブルを使用すると300mまで伸ばすことができます。 300mあれば、フロア内配線で困る事は無いでしょう。 10GBASE-LRは最大長10kmと敷地内の棟をまたぐような特別長い配線をする場合に必要になります。 基本的にスイッチ間接続が主用途となります。 10GBASE-SFP+ ここで、SPF+について補足します。 上記の通り、10mまでしか配線出来ないのであればSPF+は汎用性高くないではないか？ と疑問に思われる事でしょう。 しかし、SFP+は、モジュールを選択することによって10GBASE-SFP+(Cu Twinnax)と10GBASE-SR両方に対応可能です。 たとえば、ラック内配線では10GBASE-SFP+(Cu Twinnax)で安価に、ラック外との接続はSRトランシーバーを使用し光ファイバで接続といった具合に、メタルケーブルの経済性と光ケーブルの長距離、高品質を両立させることができます。 設置環境の情報が不明なケースが多いため、私はもっとも汎用性が高いSFP+を選択することが多いです。 10GBASE-SFP+(Cu Twinnax)_ダイレクトアタッチケーブルの例 10GBASE-SFP+ SRトランシーバモジュールの例 まとめ さまざまな規格が存在する10GbpsEtherの世界ですが、今から購入するのであれば10GBASE-SFP+か10GBASE-Tのどちらかとなります。 今のところ迷ったり、指定がない場合、汎用性と配線距離を踏まえてSFP+を選択します。 10GBASE-Tについては、現状ではSFP+と比較して ・RJ-45ではあるが、ケーブルを引き直す必要が有り、配線を流用できない ・最大ケーブル長がSFP+と比較して短い ・消費電力が高め(改善されつつある) ・高レイテンシ となり、積極的に選ぶか?といわれると意見の分かれるところになります。 敷設のしやすさ、ケーブルの取り回しのしやすさ1GbpsEtherとの接続性といった点を 評価するのであれば 10GBASE-Tとなります。 普及が進み、スイッチ含め、価格がもう一段下がれば基本は10GBASE-Tで構成となるかと思います。 ※SFP+ダイレクトアタッチケーブルを使用する場合の注意点(2018/11/2追記)※ SFP+のダイレクトアタッチケーブルですが、ネットワークスイッチ側で制限がかけられているケースがあるようです。 具体例ですとCISCOのCatalystシリーズと接続する場合はCISCO以外のメーカーのケーブルを接続するとリンクアップしないようです。 Catalystの場合、回避策がありますので知りたい方は”#no errdisable detect cause gbic-invalid”や”#service unsupported-transceiver”で検索ください。 ダイレクトアタッチケーブルの場合、サーバーとネットワークスイッチのメーカーが違う場合は相互にサポートするケーブルはありませんのでサポートを気にされる場合は、SRトランシーバーでの接続をお勧めいたします。 以下は、ダイレクトアタッチケーブルの適合性についての資料となりますがこちらのリンク先の資料については、各メーカーのサポート状況をまとめたものではなく、あくまで互換SFP+モジュールを販売しているPanduit社の調査結果に基づくデータとなります。 こちらの情報で使用可能となっていても、メーカーのサポートは受けられない、もしくは動かないケースもあり得ます。 あくまで自己責任の範囲でご参照ください。 http://www.panduit.com/heiler/TechnicalReferences/D-COTR104--WW-JPN-Rev2-SFPCprCblAsmbl.pdf http://www.panduit.com/heiler/TechnicalReferences/D-COTR104--WW-ENG-Rev5-SFPCprCblAsmbl.pdf 25GbpsEtehrの記事も追加しております。 ↓↓↓↓↓↓↓↓↓↓↓↓↓↓ いまさら聞けない25GbpsEther この記事に関する、ご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社 技術支援本部 E-Mail：nicp_support@NIandC.co.jp
IBM Cloud Pak for Applicationsの新規販売は終了いたしました。 今後のアプリケーションランタイムソリューションは、2021年1月15日に発表されたWebSphere Hybrid Editionとなります。 こんにちは。 てくさぽ BLOG メンバーの岡田です。 第１回、第２回に続いて、今回は AWS 上に構築した Openshift 環境に Cloud Pak for Applications（以下、CP4A）をインストールします。 手順は Knowledge Center 内「Installing」の内容に基づいていますのでこちらもご参照ください。 【環境】 Openshift 4.3.22 （AWS 上に CloudFormation を用いて構築） CP4A 4.0.1 目次 事前準備 インストール実行 ２－１．Entitlement Key の入手 ２－２．インストール構成ファイルをインストーライメージから取り出す ２－３．インストーラの実行 ２－４．インストール後の確認 つまづいたポイント 最後に １．事前準備 IBM id を用意します。 Docker コマンド 17.05 以上の実行環境を用意します。 構築した Openshift 環境に ocコマンドでログインできることを確認します。 ２．インストール実行 ２－１．Entitlement Key の入手 ＜ "MyIBM Container Software Library" にアクセスし Entitlement Key をコピー＞ ※アクセスすると IBM id でのログインが求められるので ID・パスワードを入力してログインし、以下の画面に遷移したら「キーのコピー」をクリックします。 ２－２．インストール構成ファイルをインストーライメージから取り出す <以下のコマンドを、docker をインストールした端末から実行> # export ENTITLED_REGISTRY=cp.icr.io # export ENTITLED_REGISTRY_USER=cp # export ENTITLED_REGISTRY_KEY=<apikey> ※apikeyは2-1.でコピーしたライセンス・キーです。 <entitled registry にログイン> # docker login "$ENTITLED_REGISTRY" -u "$ENTITLED_REGISTRY_USER" -p "$ENTITLED_REGISTRY_KEY" WARNING! Using --password via the CLI is insecure. Use --password-stdin. WARNING! Your password will be stored unencrypted in /root/.docker/config.json. Configure a credential helper to remove this warning. See https://docs.docker.com/engine/reference/commandline/login/#credentials-store Login Succeeded <dataディレクトリを作成し、そこに configurationファイルを展開> # mkdir data # docker run -v $PWD/data:/data:z -u 0 -e LICENSE=accept "$ENTIITLED_REGISTRY/cp/icpa/icpa-installer:4.0.1" cp -r "data/*" /data Unable to find image 'cp.icr.io/cp/icpa/icpa-installer:4.0.1' locally 4.0.1: Pulling from cp/icpa/icpa-installer 964d57e311cc: Pulling fs layer 6d1814359c74: Pulling fs layer 77181019ed4d: Pulling fs layer 60aa381192cc: Pulling fs layer （途中省略） 2.602kB/2.602kB7d09be603f64: Extracting 2.602kB/2.602kB7d09be603f64: Pull complete df8e82fdbe08: Extracting 32.77kB/925.6kBdf8e82fdbe08: Extracting 925.6kB/925.6kBdf8e82fdbe08: Pull complete b0cda391a0db: Extracting 32.77kB/973kBb0cda391a0db: Extracting 973kB/973kBb0cda391a0db: Extracting 973kB/973kBb0cda391a0db: Pull complete Digest: sha256:a1c6c478dfb4d2039df385f8a75ecf3e6d358e35f8d662afc506b6bbc5d308af Status: Downloaded newer image for cp.icr.io/cp/icpa/icpa-installer:4.0.1 # <dataディレクトリに4つの yamlファイルが作成されたことを確認> ※config.yaml, kabanero.yaml, servicemesh.yaml, transadv.yaml が作成されます。 # ls -la data 合計 20 drwxr-xr-x. 2 root root 91 4月 21 10:44 . dr-xr-xr-x. 21 root root 4096 4月 21 10:40 .. -rw-r--r--. 1 root root 704 4月 21 10:44 config.yaml -rw-r--r--. 1 root root 539 4月 21 10:44 kabanero.yaml -rw-r--r--. 1 root root 1299 4月 21 10:44 servicemesh.yaml -rw-r--r--. 1 root root 3792 4月 21 10:44 transadv.yaml ２－３．インストーラの実行 <Openshift 環境へログイン> # oc login https://api.nicptestcluster.example.com:66443 -u kubeadmin -p 〈kubeadminのパスワード〉 Login successful. You have access to 51 projects, the list has been suppressed. You can list all projects with 'oc projects' Using project "default". <チェックコマンドの実行> ※最後に "Check successful" と表示されることを確認します。 # docker run -v ~/.kube:/root/.kube:z -u 0 -t -v $PWD/data:/installer/data:z -e LICENSE=accept -e ENTITLED_REGISTRY -e ENTITLED_REGISTRY_USER -e ENTITLED_REGISTRY_KEY "$ENTITLED_REGISTRY/cp/icpa/icpa-installer:4.0.1" check Starting Check ***************************************************************** Login To Cluster... ok stdout: Using environment variables to log-in to cluster. Login successful. You have access to 57 projects, the list has been suppressed. You can list all projects with 'oc projects' Using project "openshift-marketplace". Get Cluster Server Address... ok （途中省略） Check Existing OpenShift Serverless Subscription... skipped Check Existing OpenShift Pipelines Subscription... skipped Check Existing Appsody Subscription... skipped Check successful *************************************************************** <インストールの実行> ※チェックコマンドで問題がなければ実行します。チェックコマンドとは最後のパラメータが "check" か "install" かの違いです。 最後に "Installation complete" と表示されることを確認します。 # docker run -v ~/.kube:/root/.kube:z -u 0 -t -v $PWD/data:/installer/data:z -e LICENSE=accept -e ENTITLED_REGISTRY -e ENTITLED_REGISTRY_USER -e ENTITLED_REGISTRY_KEY "$ENTITLED_REGISTRY/cp/icpa/icpa-installer:4.0.1" install Starting Install *************************************************************** Login To Cluster... ok stdout: Using environment variables to log-in to cluster. Login successful. You have access to 57 projects, the list has been suppressed. You can list all projects with 'oc projects' Using project "openshift-marketplace". Get Cluster Server Address... ok （途中省略） Mark Installation Complete... done Install successful ************************************************************* Installation complete. Please see https://ibm-cp-applications.apps.nicptestcluster.example.com to get started and learn more about IBM Cloud Pak for Applications. The Tekton Dashboard is available at: https://tekton-dashboard-tekton-pipelines.apps.nicptestcluster.example.com. The IBM Transformation Advisor UI is available at: https://ta-apps.apps.nicptestcluster.example.com. The IBM Application Navigator UI is available at: https://kappnav-ui-service-kappnav.apps.nicptestcluster.example.com. ２－４．インストール後の確認 ＜インストール画面に表示された Cloud Pak Console の URL にアクセス＞ https://ibm-cp-applications.apps.nicptestcluster.example.com/ ※Cloud Pak Console には OpenShift Webコンソールからもアクセスできます。 画面右上の四角形のアイコンをクリックすると "Cloud Pak for Applications - Cloud Pak Console" が確認できます。 以上で CP4A のインストールは完了です！ ３．つまづいたポイント インストールがエラーで完了しない 作業当初は、以下のシステム要件ページに記載の "Cloud Pak for Applications 4.0.1 only runs on x86 Intel on Red Hat OpenShift Container Platform (OCP) versions 4.3 and 4.2. " より OpenShift4.2.23 上にてインストールを開始しました。 https://www.ibm.com/support/knowledgecenter/en/SSCSJL_4.0.x/install-prerequisites.html 上記 <チェックコマンドの実行> までは正常に完了しましたが、次の <インストールの実行> でエラーとなりました。 # docker run -v ~/.kube:/root/.kube:z -u 0 -t -v $PWD/data:/installer/data:z -e LICENSE=accept -e ENTITLED_REGISTRY -e ENTITLED_REGISTRY_USER -e ENTITLED_REGISTRY_KEY "$ENTITLED_REGISTRY/cp/icpa/icpa-installer:4.0.1" check Starting Check ***************************************************************** Login To Cluster... ok （途中省略） Retrying... (39 of 41) Retrying... (40 of 41) failed msg: non-zero return code stdout: The kappnav-ui pods are not created. Check logs for details. Install failed ***************************************************************** このログをみる限り、kappnav-uiポッドが立ち上がってこない状況で止まっていますので、続いて、pod のログを確認しました。 # oc describe kappnav.kappnav.io/instance -n kappnav Name: instance Namespace: kappnav Labels: <none> Annotations: kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"kappnav.io/v1alpha1","kind":"KAppNav","metadata":{"annotations":{},"name":"instance","namespace":"kappnav"},"spec":{"appNav... API Version: kappnav.io/v1alpha1 Kind: KAppNav （途中省略） Status: Conditions: Last Transition Time: 2020-05-12T07:50:44Z Status: True Type: Initialized Last Transition Time: 2020-05-12T07:50:48Z Message: failed to install release: chart requires kubeVersion: >=1.11.0 which is incompatible with Kubernetes v1.14.6-152-g117ba1f Reason: InstallError Status: True Type: ReleaseFailed Events: <none> # 続いて Openshiftクラスターの Kubernetesバージョンを確認します。"v1.14.6+8fc50dea9" でした。 # oc get nodes NAME STATUS ROLES AGE VERSION ip-10-0-48-228.ap-northeast-1.compute.internal Ready worker 51d v1.14.6+8fc50dea9 ip-10-0-49-10.ap-northeast-1.compute.internal Ready worker 51d v1.14.6+8fc50dea9 ip-10-0-50-165.ap-northeast-1.compute.internal Ready master 52d v1.14.6+8fc50dea9 ip-10-0-58-201.ap-northeast-1.compute.internal Ready master 52d v1.14.6+8fc50dea9 ip-10-0-59-142.ap-northeast-1.compute.internal Ready master 52d v1.14.6+8fc50dea9 その後、いろいろと調査をしたのですが原因が特定できなかったため、4.0.1 がサポートしている Openshift の最新バージョン 4.3.22 にアップデートをして再度 CP4A のインストールを実施したところ、無事完了しました。 4.3.22 にバージョンアップ後の oc get nodes 結果です。4.2.23 のときについていた "+xxx" という文字列は無くなり "v1.16.2" となっています。 $ oc get node NAME STATUS ROLES AGE VERSION ip-10-0-48-228.ap-northeast-1.compute.internal Ready worker 213d v1.16.2 ip-10-0-49-10.ap-northeast-1.compute.internal Ready worker 213d v1.16.2 ip-10-0-50-165.ap-northeast-1.compute.internal Ready master 213d v1.16.2 ip-10-0-58-201.ap-northeast-1.compute.internal Ready master 213d v1.16.2 ip-10-0-59-142.ap-northeast-1.compute.internal Ready master 213d v1.16.2 原因を特定できなかったのは残念でしたが、つまづいたら一旦環境を最新にしてエラーが再現するかを確認する、という問題解決の基本を改めて実感しました。 最後に いかがでしたでしょうか。 一部の dockerコマンドが長くて難しく感じましたが、手順そのものは前回ブログでの Openshift 構築と比べると工程数は非常に少ないので、それほど CP4A のインストールは難しくないと、実際に検証してみて感じました。 皆様の CP4A 構築にこの記事が参考になれば幸いです。 この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社 技術支援本部 E-Mail：nicp_support@NIandC.co.jp
IBM の岡田です。 「最新のデータライフサイクル管理とは？（前編）」では "データの価値" や "IBM Spectrum Scale" についてのお話をしました。 後編は "IBM Cloud Object Storage" とは何か、といったことから、続きのお話をしていきましょう。 IBM Cloud Object Storageとは 先にデータの価値の話をしました。今度は昨今のデータの在り方のお話から入ります。 ここ10年ほどの間に、データの中心はトランザクション系の構造化データからビデオコンテンツや写真や IoT のセンサーデータなどの非構造化データにシフトしています。 近年その伸びも2年ごとに90％レベルの伸びを示しており、現在世の中のデータはすでに数十ゼタバイト程とも言われています。 つまり、これからのストレージはその容量の拡大についていく必要があり、そのような大容量下でデータ保全していかなければならないということです。 このような膨大な非構造化データの保管に向いているのが、オブジェクトストレージと言われるものです。（ブロック・ファイル・オブジェクトの違いはGoogle検索してみると色々解説がありますので、そちらをご参照ください） オブジェクトストレージには以下の特徴があります。 階層を持たない API による I/O 複数ノードによる分散保管 IBM Cloud Object Storage（以降 ICOS と呼ぶ）はこの複数ノードによる分散保管を地域レベルまで広げ、複数サイトでデータを持ち合う（ただしミラーではない）ことで地域災害などサイトレベルでのダウンにも対応できる保全性を実現します。 これにはイレージャーコーディングという RAID とは別のデータ保全の仕組みが使われてます。 RAID の問題点は、扱う容量が大きくなればなるほど障害後の再構成の時間がかかるようになるということ。この再構成時に新たな障害が発生するとデータロストに繋がります。 ICOS で使われる Information Dispersal Algorithm（以降 IDA と呼ぶ）というイレージャーコーディングをベースにした技術は、複数ディスク、複数ノードの障害を許容する、さらに言えば、ハードウェアは壊れることが当然、という思想の元に出てきたデータ保全方法のため、ある閾値に達するまではハードウェアの障害に影響されず、データの読み書き、運用が正常に行われます。 閾値で許容される障害ノード台数がサイトのノード数以上であればサイト障害にも耐えうる、ということです。 図6. IBM Cloud Object Storageの基本的なアーキテクチャー IBM Cloud 上でもこの ICOS を使った月額課金のオブジェクトストレージを提供していますが、アジア圏の場合、東京・ソウル・香港の3箇所に分散して ICOS を運用しております。 図7. IBM Cloud のオブジェクトストレージ（ICOS） このような3箇所ないしそれ以上の拠点に暗号化したデータを分散しておくことで、セキュアで信頼性の高いデータ保管が可能となり、現実に ICOS に保管されたデータの信頼性は最大 15ナイン（99.9999999999999%）とも言われています。 安い容量単価でデータの最後の砦としての信頼性を確保できるストレージとして、ICOS はテープと違った面で適していると言えます。 また ICOS は API でやりとりするという点でも、昨今の Cloud Native なアプリケーションとも相性が良く、AI や Analytics系でのデータ提供にも非常に適しています。 よって、非構造化データのような保管がメインで利活用の可能性が高いデータに最適な選択と言えるのが、IBM Cloud Object Storage です。 ICOS にはデータのライフサイクルを管理する上で重要な機能があります。 WORM という言葉をご存知でしょうか？ 元々は US で決められた法律に準拠したデータ保管のメディア方式の一つです。Write Once Read Many の略で、要は上書きが出来ず、改竄不能なメディアとして出来たものです。 ICOS にもこの WORM の機能があります。 WORM として設定されたエリア（一般的にはバケットにあたる。IBM では Vault と呼んでいる）にひとたびデータを書き込むと、そのデータは消去もできなければ改竄もできなくなります。データ保管の期間を設定することができるので、データライフが終わった時にタイムリーにデータを削除することも可能となります。 例えば、法律や規定等で保管年数を決められている契約書などの書類や、証拠物件として扱われる写真や帳簿類など、普段はアクセスすることもないが無くしてはいけない重要なデータのライフ管理には有効な手段となります。 また、最近はランサムウェアなどのデータ改竄（暗号化）に耐えうるバックアップデータエリアとしても注目されています。 IBM Spectrum Discover ここまでに示した通り、データはますます伸び率が高くなってきています。日ごとに増えるデータを扱う上でネックになるのが、データの特定等、保管データを後から扱うときの仕組みです。 最近のトレンドとしては、ファイルに関連づけられたメタデータや、ユーザーが自由に付加できるタグを活用しデータをカテゴライズしたり検索したり、といった作業が多くなっています。 IBM Spectrum Discover は、こういったメタデータ、タグデータをマネージするためのソフトウェアです。 明確には SDS というわけではなく、むしろデータマネージメントの意味合いが強いソフトウェアです。Discover の強みは、API を介して AI などにデータを食わせることができる、という点にあります。 例えば、画像データであれば画像解析の機能を持った AI（IBM では Watson Visual Recognition がこれに当たる）で画像に付随する情報を抽出し、これをタグデータとして付加する、といった作業を半自動的に行えることです。これにより、膨大なデータのカタログ化や一部のデータの抽出、あるいは不要であったりおかしなデータが紛れ込んでいないかなど、ガバナンスに対応することが可能です。 こうしたデータの利活用の方法も、大きな意味でデータのライフサイクルを支える新しい手法と考えられ、データマネージメントに寄与することができるわけです。 図8. IBM Spectrum Discover のデータマネージメントのイメージ 次回はデータを守ることについてお届けします。最後までお読みいただきありがとうございました。 この記事に関するお問合せ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは、「こちら」からお願いします。 参考ページ IBMストレージ製品 全包囲網。。。最新 IBMストレージ 概要 OpenShiftに代表されるコンテナ環境へのIBMストレージの対応 ハイブリッド/マルチクラウド時代だからこそIBMのストレージ AI導入はどこまで現実的？ 5大ハードルとその解決策を解説 普及が進む、機械学習による異常検知。導入の課題はここまで解決している (IBMサイト) データ・ファーストのハイブリッドクラウド基盤を実現するIBMストレージ (IBMサイト) ハイブリッドクラウドにおけるデータ連携の鍵を握るもの
IBM の岡田です。 少し間が空きましたが、前回のハイブリッド/マルチクラウド時代だからこそIBMのストレージ は盛り沢山で機能豊富なブロックストレージを中心にクラウド連携のお話をさせていただきまいしたので、少々お腹いっぱいだったかもしれませんね。 今回はデータのライフサイクルを考えていくことで「ファイルストレージ」「オブジェクトストレージ」を前編/後編の2回でお話しさせていただきます。 データの価値 少々古いデータになりますが、以下は時間とともにデータの価値がどう変化するか、ということを示したグラフです。 「Development Code」のように多少の例外はありますが、多くは作られた直後のデータ価値が高く、時間とともにその価値は失われていくという傾向があります。 例外と言いましたが「Development Code」については以下ように解釈できます。 初期は完成に至ってないためコード価値は低く、実際に完成品となって初めてその価値が高くなる。そして製品のライフとともにコード価値が失われていくという意味において、コードの完成時をタイムゼロとみれば、他のデータとも同じ価値の変化を示すと考えられなくもないです。 これをもう少し概念的に捉えたものが次の図です。 図2. データの時間的価値変化のモデル 図に書かれたように、これらのデータにはその時の価値にふさわしい保管場所というものがあります。おそらくみなさんも切羽詰まった時、例えるならば PC のハードディスクがいっぱいになってしまった時など、慌てて古いファイル類を安価な記憶媒である DVD、BD、USB接続の外部記憶装置などに退避したり、使わないファイルを消去したりするのではないでしょうか？ 企業で取り扱う大量のデータでは、使わなくなったデータの保管にマッチした記憶デバイスへの移動をタイムリーに実施しないと、無意味に高価な保存スペースを浪費し、多くの無駄が発生します。 このようなことが無いよう、適切にデータのライフに合わせて保管場所を管理する必要があります。以前は、図3左側のように人手でこのような管理を行っていました。これでは手間がかかるだけでなく、ミスが生じてデータを消してしまったり、保管場所がわからなくなってしまうなど多くの不具合が生じる原因にもなりかねません。 このような手間をなくし、自動的に階層管理ができるのが、IBM Spectrum Scale です。 図3. データの階層化管理・今昔 IBM Spectrum Scaleとは IBM Spectrum Scale は、IBM が1990年代に開発した GPFS（General Parallel File System）と呼ばれる科学計算向けの高速ファイルシステムをベースに長年かけて熟成させたソフトウェア・デファインド・ストレージ製品です。 当初は AIX用に使われており、複数サーバーから同一ファイルへの同時アクセス可能とした当時としては先進的なファイルシステムで、特にグリッド系の処理に役立つものでした。 これをベースに様々な機能が付け加えられ、今日ではサーバーからアクセスしやすい NFS や SMB などの標準的なプロトコルに加え、HDFS にも対応した多目的使用に耐えうるものになっています。 この IBM Spectrum Scale には、図4に示す通り多くのハイパフォーマンス・ストレージに根ざした技術があり、また名前が示す通りスケールアウトすることで、より高速、より大容量を扱うことができるようなソリューションです。 現在では多くのスーパーコンピュータやハイパフォーマンスコンピューティングの分野で活用されています。 図4. IBM Spectrum Scale 全容 このように多くの機能がある中、当ブログではあえて自動階層化という機能に焦点を当ててお話をします。 Spectrum Scale は管理下に種類の異なる媒体を複数持つことができます。 この機能の例として、図5のように高価で高速な Flash系のストレージ、速度より容量重視の HDD、そしてテープ装置などで構成されたファイルシステムを見ていきましょう。 図5. IBM Spectrum Scale の自動階層化機能 これらの自動化にはどのように階層管理するかのルールが必要となります。配置ポリシー、移行ポリシーというのがそれにあたります。 配置ポリシーは、ファイルを書き込む際に何を基準にどの媒体・どの位置に書き込むかなどのルールを決めたものです。移行ポリシーは、すでに保管されているファイルがどのような条件で移動し、その際どの媒体・どの位置に移動させるかを決めるものです。 例えば、図5では、初期保管時にはフラッシュに書き込まれます。 次に保管期間が1ヶ月を過ぎると自動的に HDD に移動されます。この時ユーザーから見たファイルの位置は変わっておらず、書き込んだ時のフォルダーにそのまま存在して見えます。 さらに3ヶ月が過ぎるとフォルダーにスタブと呼ばれるリンクポインターのみを残し、ファイル本体はテープに移行されれます。ひとたびこのスタブにアクセスが生じると、ファイルはテープから書き戻され、また3ヶ月後にはスタブのみ残して元に戻ります。 というような、ファイルの価値にふさわしい媒体への移動を自動的に行うことで高価なデバイスの容量を減らすことができ、最終的にテープなどの安価なデバイスで管理することが可能となります。これにより、旬なデータの I/O パフォーマンスを損なうことなくストレージ全体のコストを減らすことにもつながります。 自動階層化の最終層には、テープの他にも、パブリッククラウド上のオブジェクトストレージなども有効です。こうすることで手元の余計な資産を減らすことにも繋がります。もちろんオンプレミスのオブジェクトストレージでも安価な容量単価を実現することができます。 「最新のデータライフサイクル管理とは（後編）」にて、そのオブジェクトストレージの IBM製品、IBM Cloud Object Storage のお話をしましょう。 最後までお読みいただきありがとうございました。 この記事に関するお問合せ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは、「こちら」からお願いします。 参考ページ IBMストレージ製品 全包囲網。。。最新 IBMストレージ 概要 OpenShiftに代表されるコンテナ環境へのIBMストレージの対応 ハイブリッド/マルチクラウド時代だからこそIBMのストレージ AI導入はどこまで現実的？ 5大ハードルとその解決策を解説 普及が進む、機械学習による異常検知。導入の課題はここまで解決している (IBMサイト) データ・ファーストのハイブリッドクラウド基盤を実現するIBMストレージ (IBMサイト) ハイブリッドクラウドにおけるデータ連携の鍵を握るもの
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大ハードルとその解決策を解説 普及が進む、機械学習による異常検知。導入の課題はここまで解決している
IBM Cloud Pak for Applicationsの新規販売は終了いたしました。 今後のアプリケーションランタイムソリューションは、2021年1月15日に発表されたWebSphere Hybrid Editionとなります。 1.本記事について 本記事は「【やってみた】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回「Cloud Pak for Applications 導入してみた」シリーズの、"OpenShift 導入編" です。 【やってみた】Cloud Pak for Applications 導入してみた：概要編 【やってみた】Cloud Pak for Applications 導入してみた：OpenShift 導入編 ← 今回 【やってみた】Cloud Pak for Applications 導入してみた：Cloud Pak for 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 参考情報 （製品情報）IBM Cloud Pak for Applications 全ての企業が AI カンパニーになる！「IBM THINK Digital 2020」に参加した Cloud Pak for DataのトライアルとCloud Pakシリーズアップデート情報 IBM Cloud Paks シリーズ ご紹介資料 （IBM サイト）IBMデモ Cloud Pak for Applications 【やってみた】IBM Cloud Pak for Applications導入してみた：概要編 【やってみた】Cloud Pak for Applications 導入してみた：Cloud Pak for Applications 導入編 今、デジタルサービスに求められる必須要件とは!? アプリケーションのコンテナ化で得られる5つのメリット
こんにちわ。 てくさぽ 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
