特集・ブログ
ここ数年、IT運用の複雑性が問題視されています。この複雑性が従来のアプリケーションと最新のアプリケーションを同時に稼働させることを困難にしているからです。 そのため、市場投入の遅れや高額な運用コストが生じ、企業がROIを最大化しながら迅速にトランスフォーメーションを実施するための障害ともなっています。 これは IBM WebSphere Application Server（以下 WAS）のユーザーにとっても同様の課題です。 本記事では、WASの抱える課題と、既存の環境を変更することなく WASの運用を自動化・一元化することでアプリケーション・ワークロードの実行にかかる時間と労力を節約し、さらに、セキュリティとレジリエンシー、パフォーマンスを向上させる「IBM WebSphere Automation」について解説します。 Index WebSphereブランドの中核製品「IBM WebSphere Application Server」 WASユーザーが抱える悩み WASの運用を自動化・一元化する新ソリューション「IBM WebSphere Automation」 IBM WebSphere Automation活用の3つのメリット Cloud Pak for Watson AIOpsとの連携でより効率的に ぜひ、エヌアイシー・パートナーズにご相談ください この記事に関するお問い合わせ 関連情報 WebSphereブランドの中核製品 「IBM WebSphere Application Server」 IBMのミドルウェア・ソフトウェアブランド「WebSphere」の中で最も有名な製品が「IBM WebSphere Application Server (WAS)」です。 WASは、多くのミッションクリティカルを支える商用の Webアプリケーションサーバーとして1998年から提供されており、安定稼働が評価され長年にわたり多くのユーザーに利用されてきました。 WASの特長は、Webアプリケーション環境の一般的な3層構造 (Webサーバー・アプリケーションサーバー・DBサーバー) のうち、WAS単体で "Webサーバー" と "アプリケーションサーバー" 両方の機能を提供できることや、Webサーバーからリクエストを受け Java/PHP/Ruby などで作成されたアプリケーションを実行し、動的なコンテンツの生成が可能なことにあります。 さらに、負荷分散機能を持ったエディション "Network Deployment" により、大規模環境にもこの製品1つで対応が可能です。 また、ワークロード全体の可視性を高めエンタープライズ・アプリケーションを分析し、Kubernetes への対応を促進できるように設計されていることも、WASが多くのユーザーに活用される理由となっています。 WASユーザーが抱える悩み 多くのミッションクリティカルなシステムを支える基盤ミドルウェアとして長年にわたり企業に選ばれ活用されてきたWASですが、この歴史があるからこそ浮上する課題もあります。 それが「運用効率の低下」です。例えば、以下のようなことが起きています。 システムのサイロ化によってWASが複数のシステムにまたがって運用されており、それぞれを個別に管理しているため人手がかかる Webアプリケーションシステムのセキュリティ強化のためには、開発したアプリケーションだけではなく基盤であるWASの脆弱性を把握して速やかにパッチを適用することが重要だが、一括で状態が確認できず、調査・適用に手間がかかる 多くのミッションクリティカルシステムを支える基盤ミドルウェアであるのに、企業全体で一貫したポリシー適用が難しい これらWASが抱える問題を、費用対効果や脆弱性対策などの観点から解決するのが 「IBM WebSphere Automation」です。 WASの運用を自動化・一元化する新ソリューション 「IBM WebSphere Automation」 2021年5月12日、8つの新ソリューションの1つとしてIBMがオンラインイベント "Think 2021" で発表したのが、「IBM WebSphere Automation」です。 IBM WebSphere Automation なら、サイロ化したシステムに散在するWASの運用を、自動化かつ一元化することが可能です。既存環境の変更は必要ありません。 同時に、一貫したポリシーの適用を実現することで脆弱性対策を強化し、レジリエンシーとパフォーマンスの向上も実現します。 これにより、運用/管理の手間とコストを減らしアプリケーション開発にかける時間を創出。 アプリケーションの迅速な市場投入を可能にすることで、ROIを最大化します。 それでは、IBM WebSphere Automation活用の各メリットを詳しく見ていきましょう。 IBM WebSphere Automation活用の3つのメリット 1. 一貫したポリシーを適用したセキュアな運用 IBM WebSphere Automation は、サイロ化した各システムに散在するWASの管理を一元化することでリスクを低減し、コンプライアンスに厳格に対応します。 管理の一元化により、一貫したポリシー適用が可能になるだけでなく単一のダッシュボードを使用することで、運用チームが最も関連性の高い情報にアクセスすることを容易にします。 また、潜在するリスクに対しても自動的にリスクを検知し、各システムに散在するWASに対してパッチを効率的に配布することによって、DevSecOps をより積極的に実践することが可能になります。 2. 運用のレジリエンシーを確立し、イノベーションのための時間を創出 IBM WebSphere Automation は、WASの管理や運用を自動化することで煩雑な手作業を削減し、最適なリソース活用を通してコストと時間を節約します。 自動化によってルーティーン作業を削減し障害を素早く復旧することで、チームの対応能力強化に寄与し運用の効率化とレジリエンシーを確立します。 これにより、人手不足の解消、さらに、WASやLibertyの環境管理にかかるコストとその複雑性を最小限に抑えることが可能になります。 また、WASの運用管理工数の削減でチームの時間をより価値の高い活動にあてることができるため、イノベーションのための時間や機会を 生み出すことも大きな効果です。 3. 運用パフォーマンスの向上 IBM WebSphere Automation を活用し、様々な環境からの情報を統合するダッシュボードを活用することで、個々の環境を確認しなくてよくなるため運用効率を改善できます。 また、作業の自動化を行うことができるため、様々な環境に共通したベストプラクティスを展開することで安定稼働を実現できます。 これらにより、運用パフォーマンスを向上することができるため、コスト削減だけでなく安定稼働が可能となります。 Cloud Pak for Watson AIOpsとの連携でより効率的に さらに IBM WebSphere Automationは、「IBM Cloud Pak for AIOps」との連携でより効率的なWASの運用管理を実現することができます。 IBM Cloud Pak for AIOps は、AIを活用してIT運用の課題を解決できる運用基盤で、監視データを集約・分析し、現在なにが起こっているのかをリアルタイムに捕捉。問題発生をとらえ影響範囲を予測し、対処方法を提案します。 これらは、1つのダッシュボードで運用全体を確認できるため、複雑でサイロ化されたマルチクラウド/ハイブリッドクラウド環境でIT運用が抱える課題の迅速な解決を可能にします。 IBM Cloud Pak for AIOps は、予兆を検知することでプロアクティブ (積極的) な保全活動もできるようさらに製品を進化させており、今後の動向にも注目したいところです。 ぜひ、エヌアイシー・パートナーズにご相談ください エヌアイシー・パートナーズは IBM Value Add Distributor として、お客さまの課題に対し長年の実績とIBM製品への深い理解を持って、IBM製品を組み合わせた複合的な解決策をご提案しています。 以下に当てはまる顧客の課題を解決したい方は、ぜひ、エヌアイシー・パートナーズまでご相談ください。 クラウド・テクノロジーに関する経験が乏しく、お客様の運用提案ができていない お客様にアプリケーションサーバーの高額な運用コストの削減提案を実施したい お客様が利用しているWAS環境は様々な企業が個別に導入しているため、一貫したポリシー適用が難しい WASの脆弱性対策が一貫してできていない 費用対効果を最大化できるソリューションを採用したい 構築スキルの習得が難しい この記事に関するお問い合わせ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは以下のボタンよりお願いいたします。 お問い合わせ 関連情報 IBM WebSphere Application Server (WAS) (製品情報) 【やってみた】WebSphere Hybrid Edition導入してみた：OpenShift導入編 (ブログ) .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; }
日本企業が取り組むべきデジタルトランスフォーメーション（以下 DX）は、もはや助走期間を過ぎました。 2025年の崖を乗り越えデジタル競争の勝者となるためには、よりスピーディに、よりスマートに、企業活動を発展させていく必要があります。 経営とITが不可分である今日、その原動力となるのは企業情報システムです。 なかでも基幹システムは、より多くの処理をこなすだけでなく、より高いパフォーマンスで処理する能力が今まで以上に求められています。 さらに、取るべき戦略を多角的な視点で分析しすばやく意思決定を行っていくために、AIを日常的に活用していく必要があります。 また、ランサムウェアを始め、企業にとってシステムへの脅威は高まる一方で、従来以上にセキュリティ強化を図ることは不可欠です。セキュリティ強化という観点では、データのみならずハードウェアやOSも視野に入れなくてはなりません。 加えて近年は、産業界全体で脱炭素社会の実現をめざしており、企業の取り組みの進度が取引先選別のポイントにもなろうとしています。 企業が直面するこうした様々な課題を解決するために進化したのが、IBM Powerの最新版「IBM Power10」です。 当コラムでは、ハイエンドエンタープライズシステムE1080を基準に、POWER9からパワーアップした機能の数々と、おすすめの活用シーンを紹介します。 Index POWER9から大きくステップアップしたPower10 今のビジネスにすぐ貢献 -IBM Power10の適用シーン- POWER9との違いを知りぬいたエヌアイシー・パートナーズにご相談を この記事に関するお問い合わせ 関連情報 POWER9から大きくステップアップしたPower10 IBMは、プロセッサーからメモリーインターフェース、筐体間通信までを一貫して設計する唯一のベンダーです。 そのため、ビジネス最前線での利用ニーズを見極めながら、あらゆるコンポーネントを相互に最適化させて作り上げることが可能です。 これまでもその取り組みは行われてきましたが、IBM Power10においてその利点が最大限に発揮されたといえそうです。 システム全体で目指したパフォーマンスの向上 Power10プロセッサーは、7nm (ナノ・メートル) にて製造されています。POWER9の14nmからプロセスルールを半分にすることにより、最大15コアの搭載が実現しました。 トランジスタ密度がさらに向上したことでコアパフォーマンスが向上し、より多くのワークロードへの対応が可能になります。 実際 IBMによる自社製品の比較検証で、コアパフォーマンスはE980と比較して20～30％増加※1、E880Cとの比較では55～80％増加※1しているといいます。 これは、こうした既存機種を複数ノードで利用していたワークロードがあれば、E1080へ統合可能であることを意味します。 また、コアライセンス体系を持つソフトウェア利用ではライセンス費用の見直しにもなります。 メモリーでは、新しいOpen Memory Interface (以下 OMI) が導入されました。 チップあたり16チャネル搭載が可能となった結果、最大1TB/sの帯域幅を実現。POWER9の230GB/sに比して、4倍以上の性能向上となっています。 また、PowerAXONにより、筐体間でのメモリーのシェア (クラスタリング) が可能になり、メモリー使用の最適化が行えます。 一方インタフェースにおいては、POWER9はPCIe Gen4でしたが、PCIe Gen5にアップデートされたことで、従来比1.8倍※1の帯域幅を提供します。 このように、IBM Power10は、CPU単体性能の向上だけでなく、チップからメモリー、I/Oデバイス、ノード間に至るまでシステム全体で広帯域・低遅延のデータ通信を実現し、コアを中心に行うデータ連携のボトルネックが様々な点で解消されています。 ※1. IBMによる自社製品調べ (2021年9月) ハードウェアレベルからのセキュリティ強化 企業の重要な資産である情報システムを守り抜くために「セキュリティはあらゆる角度から考慮すべきだ」とIBMは考えています。 IBM Power10においても、ハードウェアであるプラットフォームからアプリケーションレベルでのワークロードまで、Power10セキュリティエコシステムと称された様々なセキュリティ対策が施されています。 特に目を引くハードウェアのセキュリティ対策では、メモリー暗号化機能が強化されました。 チップ上のメモリーコントローラ内に搭載された暗号化エンジンにより、OSやアプリケーションの種類に関わらず、透過的かつ容易にデータを暗号化できます。 その能力も、POWER9に比べ4倍※1 のAES暗号化エンジンをすべてのCPUコアに搭載しているため、約40%以上の高速化がされており、アプリケーションパフォーマンスへの影響を最小限に抑制可能です。 また、このシステムは来たるべき時代に備え、量子コンピュータにも耐えうる暗号化や、暗号化されたデータを復号化することなく演算を行えるデザインであることも大きな特長です。 つまり、IBM Power10は、ハードウェアレベルから強力なセキュリティ対策を施すことで保護とパフォーマンスを両立しており、新しい脅威にも対応できるといえます。 ※1. IBMによる自社製品調べ (2021年9月) IBM Power10だけでもAI活用が可能に ますます本格化するであろうAI活用のために、Power10プロセッサー上で高速な推論環境が構築できるようになりました。 それが、Matrix-Multiply Assist (以下 MMA) で、機械学習、ディープラーニングなどのアルゴリズムを効率的に実行するための行列演算エンジンです。POWER9に比べて最大20倍※1のAI推論処理性能を有しています。 また、機械学習やディープラーニングで作ったモデルを共通のフォーマット、ランタイムで実行できるようにする、Open Neural Network Exchange (以下 ONNX) をサポートしています。 これをハブとして活用することで、機械学習やディープラーニングの学習にどのフレームワークを利用しても同じフォーマットで実行・推論することが可能です。 このように、IBM Power10では、CPUだけでもAIの推論が実行でき、かつ、ソフトウェアを含めよりスコ―プの大きなエコシステムの構築を支援することで企業のAI活用を促進します。 ※1. IBMによる自社製品調べ (2021年9月) 可用性、信頼性、保守性をさらにパワーアップ 1年365日停止することの許されないミッションクリティカルなビジネスを支えるため、IBM Power10は、さらに信頼性、可用性を高めています。 リトライ/リカバリーと自己修復のための機能を備えたプロセッサーや、OMIに接続する先進的なメモリーDIMMの搭載がまさにそのためのもの。 さらに、IBM Power10のDIMMは、業界標準のDIMMと比較してメモリーの信頼性と可用性が2倍向上※2しています。 また、新しいノンアクティブ32Gb SMPケーブル採用により、信頼性が向上したのみならず時間領域反射率測定 (TDR) による障害分離が可能になり、保守性も上がりました。 加えてバックプレーン内の配線も不要になり、バスのパフォーマンス向上に寄与しています。 ※2. ITIC 2020 Global Server Hardware, Server OS Reliability Report (2020年4月) に基づく 脱炭素社会実現に向けたエネルギーの高効率化 エネルギー効率の向上という点も、IBM Powerは30年以上にわたり注力を続けてきました。 今回7nmを実現したPower10プロセッサーは、POWER9に比べて約3倍のエネルギー効率を実現しています。 これは高集積とリソースの効率的な活用が可能になるということで、同じ規模のワークロードであればより少ないインフラで処理が行えるということです。 消費電力の削減、ひいてはCO2排出量の削減につながることで、単に企業内でTCO削減が実現するというだけでなく脱炭素社会実現に向けた取り組みにもなります。 サステナブル時代に生きる企業にとって、エネルギーを意識した活動はもはや使命といえます。 今のビジネスにすぐ貢献 -IBM Power10の適用シーン- より少ないインフラで稼働してコスト削減 最大15コアという高集積なPower10プロセッサーを有効活用することにより、様々な業務の "コンパクト化" が実現できます。 まず、アプリケーション稼働にリソースが必要な場合、多くのコアで筐体数を減らせます。 例えば、POWER E980 2ノードで稼働していたシステムは Power E1080 1ノードに集約できる可能性があり、そうなれば約33%の消費電力が削減可能※1です。 次に、OracleやSAP HANAなど、アプリケーションのライセンス課金体系がCPU単位である場合、コアの集積度向上とコアあたりの性能向上により、TCO削減の効果が期待できます。 またIBMは、IBM Power10がAIX、IBM i、Linix上で稼働する数千ものISVアプリケーションに対応することを表明しています。 これにより、例えば、RedHat OpenShift対応の様々な業務をこの上で動かすことも可能です。 ※1. IBMによる自社製品調べ (2021年9月) データがある場所でAIを実行 "Train Anywhere, Deploy here"。これは、IBM Power10におけるAIコンセプトです。 その意味は、"学習はどの場所でも、デプロイは「IBM Power10」で" というものです。 AIのモデルというのは、一度作れば終わりではありません。変化する社会情勢や事業環境に合わせて日々アップデートする必要があります。 そこで最適なのが、Power10プロセッサーに搭載されたMMAの行列演算エンジンです。 これを用いれば、作成したモデルを基幹業務が稼働しているプラットフォームのすぐ横で動かすことができます。 例えば、同じAIXで稼働している基幹業務のすぐ隣にLinux区画を作り、そこでAIモデルを実行するといった具合です。 外部からやってくるトランザクションデータを取り込むにも同じ筐体で稼働するため、データ転送のオーバーヘッドが小さく管理するプラットフォームも小さく抑えられます (図1)。 また、高パフォーマンスのIBM Power10を用いることにより、システム全体としてのSLA達成も容易になります。 図1. IBM Power10でのAI活用シナリオ例 "摩擦レス" にハイブリッドクラウドを動的に拡張 クラウドへのリフト&シフトが進行している今日ですが、「従来のITとうまく統合できない」と悩んでいる企業が多いのも事実です。 その解決策としてIBM Power10では、DynamicCapacityという機能が提供されています。 これは、コアやメモリーといったサーバーリソースを同じモデルのすべてのサーバー同士 (プール) で共有できるというもの。 また、プール内の総起動分を超過して使用した分は事前購入した従量制容量のクラウドリソースで増強できます (図2)。 図2. IBM Power10のDynamic Capacity そのため、企業はサーバーごとのリソース不足という問題から解放されるだけでなく、バースト的に発生したビジネスピークにいつでも対応可能になります。 また、これをリフト&シフトの一環とし、そのままクラウド上で業務を続けることもできます。 つまり、このシステムは、アプリケーションが実行されている環境がオンプレミスに限られていないということです。 クラウドへも "摩擦レス" に移行でき、そこでも同様のスケーラビリティ、パフォーマンスが得られるということは、大きな差別化ポイントといえるでしょう。 POWER9との違いを知りぬいたエヌアイシー・パートナーズにご相談を こうして見てくると、IBM Power10は、様々な面でブレークスルーを果たしています。 サーバー全体、また、クラウドを含めた情報システム全体のエコシステムという観点で、大きな性能向上、セキュリティ強化、機能追加を果たしたことがよくわかります。 まさに、ハードウェアからOS、ソフトウェア、クラウドまですべてを手がける、IBMならではの価値提案です。 「新しい分野にチャレンジしたい」 「迅速な意思決定のためにシステムパフォーマンスを上げたい」 「凶悪化の一途をたどるサイバー攻撃からシステムを守りたい」 「サステナブル対応が喫緊の課題だ」 といったご要望やお悩みを抱えるエンドユーザー企業のご担当者の方は、IBM Power Systemsに長く携わり、ローンチ以前からIBM Power10に注目し、POWER9との違いも知りぬいたエヌアイシー・パートナーズに、ぜひ、ご相談ください。 この記事に関するお問い合わせ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは以下のボタンよりお願いいたします。 お問い合わせ 関連情報 【10分で早わかり】インタビュー記事「Power10の真の価値とは」(インタビュー) - 日本IBM Powerテクニカル・セールス ITスペシャリスト の釘井 睦和 氏に「Power10の真の価値」についてお話を伺いました！ 【外部サイト】(IBMサイト) Power10プロセッサー搭載 IBM Powerの特長 Power10プロセッサー搭載サーバー発表に向けて .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; }
「データが増え続け、業務に支障をきたさないように運用するのに苦労している」「増えたデータを活用しきれていない」「運用担当者は日々の業務運用で手一杯」。 このような悩みを打ち明けられていることはないでしょうか。 IoTや5Gといったテクノロジーの導入など、今企業では取得できるデータの幅が大きく広がり、データをどう集め、どう格納し、どう活用するか、さらに、急速に増えたデータをどう管理するかは、企業にとって重要なテーマになっています。 このような企業の課題解決の糸口としておすすめなのが、アプライアンス型のストレージです。 ハードウェアとソフトウェアが一体となって提供されるこの製品は、別途サーバーやソフトウェアを選定・初期構築する必要がなく、運用の負担を軽減できます。 さらに、最新のアプライアンスは大容量で拡張性にも富んでいるため、これから「データを蓄積していきたい」「AI活用に着手し、少しずつ本格化させたい」というニーズにも適しています。 そこで本記事では、スケール・アウト型の共用ファイルシステムである「IBM Spectrum Scale」をベースとしたアプライアンス・ストレージ 「IBM Elastic Storage System」を紹介します。 Index ハードウェアとソフトウェアが一体化した統合ソリューション 「IBM Elastic Storage System」 IBM Elastic Storage System内のエンジン「IBM Spectrum Scale」 IBM Elastic Storage Systemが誇る6つの特長 豊富なモデルの組み合わせで自由なカスタマイズが可能に エヌアイシー・パートナーズが、モデル選びを支援します この記事に関するお問い合わせ 関連情報 ハードウェアとソフトウェアが一体化した統合ソリューション 「IBM Elastic Storage System」 IBM Elastic Storage System (以下 IBM ESS) は、アプライアンス・ストレージです。 ハードウェアの構築、ソフトウェアのインストール、そして動作テストまでも工場で事前に実施した上でお客様サイトに搬入されます。 そのため、現場ではただちにラックへのマウント作業に入れます。 また、事前に綿密な設計を施さなくてもエンタープライズレベルのパフォーマンスや可用性を発揮するよう開発されており、短期間で本番運用を開始することができます。 さらに、運用開始後のシステムアップデートも、OSからファームウェアおよび IBM Spectrum Scale、IBM ESS に特化した部分に至るまで包括的なパッチプログラムは IBM から提供されるので、お客様側ではバッチプログラムを適用するだけで済みます。 そのため、ソフトウェア間の互換性のずれなどを気にすることなく、常に最新の状態で利用できます。 包括的なサービス提供ということに関しては、保守についても同様です。 ハードウェア、ソフトウェアの切り分けなく、問い合わせ窓口は IBM に一本化できます。 管理性に優れているのも IBM ESS の大きな特長です。 視認性に富んだ GUI管理ツールを備えており、これを用いることでストレージ専門の担当者でない方もわかりやすくかつ効果的に日常管理を行えます。 IBM Elastic Storage System内のエンジン 「IBM Spectrum Scale」 このストレージは、アプライアンスながら Software Defined Storage に属しています。 ベースになっているのは、Software Defined Storage であるスケール・アウト型の共用ファイルシステム IBM Spectrum Scale です。 IBM は長年このテクノロジーの発展に精力を傾けてきました。 長いデータソースのプロトコルを管理するパートとデータを管理するパートが別に存在し、それぞれ必要に応じて柔軟に追加可能です。 そのため、 最初は最少構成で導入して徐々に適用を広げていくといったスモールスタートが可能で、ご要件に合わせていつでも簡単に柔軟に拡張できます。 なかでもメリットの大きな機能として挙げられるのは、データの階層管理機能と拠点間ファイル連携機能です。 データの階層管理機能は、データのアクセス頻度に応じて高頻度のものは高速ストレージに、頻度の低いデータは低速ストレージに、とデータの適材適所保存が可能。 ユーザーは、どのストレージプール上にファイルがあるかを意識する必要はなく、データが移動してもいつも同じ操作でアクセスが可能です。 拠点間ファイル連携機能は Active File Management と呼ばれるもので、複数拠点間での非同期コピーを自動で実現します。 データすべてを選択することが可能なら、一部に絞ることもできます。 また、キャッシュはリードオンリー、リード/ライト、DR など様々なモードが選べるため、現場ユーザーの必要とするデータを本社から定期的に配信したり、逆に現場のデータを本社に自動収集する、といったデータ管理が容易に実現できます。 IBM Elastic Storage Systemが誇る6つの特長 IBM ESS がアプライアンス・ストレージとして持つ特長をご紹介します。 1. 可用性・性能設計いらずのSpectrum Scale RAID IBM ESS は、データ保護機能である RAID が設計ずみのソフトウェア機能として提供されます。 このため、通常のストレージのようにストレージ装置側で別途設計する手間をかける必要はありません。 また、このソフトウェアRAID は、一般的なディスク・ドライブでも十分にエンタープライズレベルのパフォーマンスを発揮します。 2. サイレント・データ破壊を検出可能なEnd-to-endチェックサム ストレージ管理においては、常に読み書きできるデータが保管されていることが重要です。 しかし、ときにはコンピュータシステム内部で電磁気的な干渉が発生し、メモリの中でビットが自発的に反転してしまうことがあります。 いわゆる "サイレント・データ破壊" で、通常は障害と見なされず読み出してからデータが壊れていることがわかるという厄介な事象です。 その点IBM ESS には、書きこみ時のチェックサムと読み出し時のチェックサムを比較するEnd-to-endチェックサム機能があります。 異常を検知した段階でRAID復旧が行われますので運用停止はありません。 3. パフォーマンス向上に貢献する小容量ファイルの高速Write このアプライアンス・ストレージでは、NVMeドライブあるいはサーバープロセッサー上の NVDIMMカードが高機能な RAIDコントローラの役割を担っています。 これにより、4KiB未満の小容量データをメタデータ内に直接格納することができます。 これをキャッシュに書きこんだ後ただちに IBM ESS内の I/Oサーバ間で自動レプリケーションが行われ、これを持って格納完了とします。 そのため、IoTデータなど小容量ながら新しいデータが次々送られてくるような利用ケースにおいてはさらにパフォーマンスを向上させることが可能です（図1）。 図1. IBM ESSの小容量ファイル高速Write機能 4. NVDIMM/NVMeによる停電耐性実現で、UPSバックアップいらず IBM ESS の NVDIMMカード/NVMeドライブは強力です。 まずデータに関しては、直接ディスク書込みをもって格納完了とするライトスルー機能を実現しています。 また、メタデータに関しては上記の特長3.でも触れたとおり、キャッシュ書き込みと2台の I/Oサーバ間でのレプリケーションで格納完了となります。 どちらかの I/Oサーバに障害が発生しても、片方の I/Oサーバで代替運転が可能です。 停電耐性も高く、万が一不測の停電が起きた場合でもNVDIMMカード/NVMeドライブ上のキャパシタがキャッシュ上のデータをただちにフラッシュに退避させます。 これにより、データ消失のリスクを最小限に抑えます。 5. 様々な容量のデータに最適対応 ストレージの性能は扱うデータの大きさによっても変化します。 大容量ファイルならば、ディスク内のブロックサイズを大きく設定したほうがパフォーマンス的に有利です。 しかし、小容量ファイルを大きなブロックサイズで管理すると断片化傾向が高まってしまい、性能が低下する上にデータの格納効率も低下してしまいます。 IBM ESSは、ファイルシステム単位で最適なブロックサイズを指定できます。 また、1つのブロックを複数のサブ・ブロックで構成可能であるため、小容量データを効率よく格納できます。 例えば、最大のブロックサイズである 16MiB である場合、16KiB のサブ・ブロックが最大1,024個まで構成可能です。 これにより、ストレージの実効容量を有効に活用できます。 6. 手間をかけずに容量の追加・拡張が可能 このアプライアンスはシステム拡張も容易です。 "小さく生んで大きく育てる" ことができる秘密が、この特長にあります。 これから AI活用を本格化させようという場合にはまさに不可欠な機能といえるでしょう。 増設の際、IBM Spectrum Scale がデータのリバランスをバックグランドで自動実行します。増設前後でデータを退避させたり切り戻したり、といった作業は必要ありません。 このため、当初にパフォーマンスや容量見積もりに頭を悩ませる懸念から解放されます。 豊富なモデルの組み合わせで自由なカスタマイズが可能に IBM ESS は、ラインナップが豊富なことも大きな魅力です。 速度重視モデルと容量重視モデルが用意されているので、エンドユーザー企業のニーズにフィットした構成を実現できます。 ただし、正直なところモデルがありすぎるために迷うことも事実です。また、選択したモデル路線をその後継続して利用することになるため、最初のモデル選びには慎重さも求められます。 そこで IBM では、モデル選択のために FOSDE tool というデザインツールを提供しています。 FOSDE tool は、正式名称を「File Object Solution Design Engine tool」といい、Webで提供されています。 IBMid があれば自由に利用することが可能です。 大きく、"案件管理" "IBM Spectrum Scale や IBM ESS の検討事項リスト" "ESS構成" という3つの機能があり、ウィザード形式で1つ1つステップを踏みながら最適なモデルを絞りこめるようになっています。 基本は英語表記ですが、検討事項リストなどには日本語訳がついています。 例えば ESS構成機能では、プルダウンメニューを選択していくだけで構成可能なモデルをどんどん特定していくことができます。 実効容量の計算やパフォーマンスの予測なども可能ですから、ここで欲しいストレージ性能をいろいろシミュレーションできるというわけです（図2）。 図2. FOSDE toolを使ったESS構成シミュレーション例 エヌアイシー・パートナーズが、モデル選びを支援します エヌアイシー・パートナーズでは、エンドユーザー企業の課題解決をパートナーとともに考え、提案できる体制を整えています。 IBM ESS に関しても、IBM Spectrum Scale を含めて技術の詳細に精通したエンジニアがいつでも構成設計をお手伝いします。 もちろん、構成作業を支援する FOSDE tool が存在します。入力した内容は IBM と共有でき、選択した構成に無理がないかどうかなどの観点でレビューが提供されることになっています。 ただ、英語表記ということもあり、ウィザードを進める過程では疑問・質問が生じることもあるかと思います。 そうした際は、ぜひ、エヌアイシー・パートナーズにご相談ください。パートナー、エンドユーザー企業の立場に立って支援させていただきます。 この記事に関するお問い合わせ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは以下のボタンよりお願いいたします。 お問い合わせ 関連情報 IBMストレージ製品 (製品情報) - ストレージ機能のソフトウェア化を実現した SDS製品 (Software Defined Storage) も含め、幅広いラインアップを取りそろえています。 .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メンバーの村上です。 本ブログは、IBM Power Virtual Server をトライしてみた内容や感想をご紹介するブログです。 シリーズ化していますので、まずインデックスのご紹介をします。 インデックス ・IBM Power Virtual ServerでAIX環境を作ってみた ・IBM Power Virtual ServerのAIX環境にSWを導入してみた ・IBM Power Virtual ServerのAIX環境を日本ロケールにしてみた ・IBM Power Virtual ServerのAIX環境をバックアップしてみた（Part.1） ・IBM Power Virtual ServerのAIX環境をバックアップしてみた（Part.2） ←今回 ・IBM Power Virtual ServerのAIX環境とIBM Cloud x86環境を接続してみた 今回は、AIX環境のバックアップ手順のご紹介です。 検証環境で2種類のバックアップ方法を試しましたので、Part.1 とPart.2(本ブログ)に分けてご紹介しています。 本ブログでは 「AIX環境をバックアップしてみた Part.2」として、FlashCopy によるバックアップ手順をご紹介します。 セクション 以下の1)～4)のセクションに分けてご紹介します。 1） FlashCopy の説明 2） IBM Cloud CLI 導入 3） FlashCopy によるバックアップの事前準備 4） FlashCopy の実施 検証はAIXのインスタンスで行いましたが、IBM i のインスタンスでも同等の手順で操作を行うことができます。 利用したクライアント端末（私のPC）は、Windows10 pro バージョン2004です。 1) FlashCopy の説明 Power Virtual Server で実装する FlashCopy は以下の仕様となっています(IBM Cloud 柔らか層本 20210915版より）。 説明 ・IBM Cloud で提供されており、外部ストレージ装置のコピーを実施する ・バックアップ/リストアの時間が大幅に削減できる ・NWデータ転送量を削減できる 主な用途 ・データベース領域のバックアップ(容量が大きいものにおススメ) ・VM全体のバックアップ 対象 rootvg を含む任意のボリューム 保管場所 外部ストレージ装置 取得時の LPAR停止有無 不要 ※ ファイルの整合性担保のためにバックアップ前にはアプリの静止、LPAR停止が推奨される 制約事項 など ・リストア時はアプリ静止、LPAR停止が推奨 ・GUIは未実装であり、API呼び出しでのみ実行可能(2021年9月 時点) ・FlashCopy 先のストレージは無償で利用可能 ・インスタンス削除と同時にFlashCopy データも消失する FlashCopyとは、「Snapshot 」「Clone 」「Point in time Copy」とも呼ばれ、ある一時点のボリュームのコピーを作成する機能です。コピー元とコピー先は異なるLUN(ストレージのボリューム単位)を使用することができ、バックアップ手法として利用されています。 FlashCopy 先のディスクは課金されず無料で利用することができますが、バックアップデータの実体をWEBインターフェースの画面で確認することはできません。また、インスタンスを削除するタイミングで FlashCopy のデータも消失するため、バックアップデータはICOSなどへのデータのエクスポートが推奨されています。 2) IBM Cloud CLI 導入 FlashCopy を実施する前に、実施環境(ローカルPC)の準備を行います。 Power Virtual Server の FlashCopy は「IBM Cloud API 」を利用します。残念ながらWEBインターフェース画面では FlashCopy 機能が提供されていません（2021年9月時点）。 FlashCopy の実行は「IBM Cloud API 」で行いますが、Power Virtual Server へのログインやFlashCopy に必要なパラメータ取得などで 「IBM Cloud CLI 」も利用します。 IBM Cloud API とは 仮想サーバを簡単にデプロイおよび構成するために利用されるAPI（アプリケーション・プログラム・インターフェイス） ：利用する場合、モジュールとしてのインストールは不要 IBM Cloud CLI とは IBM Cloud のリソースを管理するためのCLI（コマンド・ライン・インターフェイス） ：利用する場合、モジュールとしてのインストールが必要 「IBM Cloud CLI 」を利用するためには、ローカルPCに「IBM Cloud CLI」のモジュールをインストールする必要があります。 では、IBM Cloud CLI のインストール作業を行っていきます。 ・WEBブラウザーを利用して、GitHub の IBM Cloud リポジトリーにアクセスします。 ・IBM Cloud CLI を導入するPCのOSを選択します（私のPCは下記のピンク色で囲んだOS）。 IBM Cloud CLI のインストーラーがローカルPC内にダウンロードされました。 ※ 上記は2021年1月時点のバージョンで、2021年9月時点の最新版は v2.0.3 です。 ・ローカルPC内にダウンロードしたインストーラーをダブルクリックして起動します。 「IBM Cloud CLI の インストール・ウィザード」が表示されます。 ・「Next」をクリックします 「License Agreement 」の画面が表示されます ・「I accept the terms in the license agreement」にチェックを入れます ・「Next」をクリックします 「Ready to Install the Program」の画面が表示されます。 ・「Install」をクリックします 「The installation completed successfully」のメッセージでインストールが正常に終了した画面が表示されます。 ・「Finish」をクリックします IBM Cloud CLI のインストールが完了です！ IBM Cloud CLI が正常にインストールされていることを確認します。 これ以降の作業では、CUI を利用して検証を行います。CUI は Windows標準搭載の「Windows PowerShell」を利用します。（※画面ショットの 固有の値はマスキングします） ・Windows PowerShell を起動し IBM Cloud CLI のバージョン確認コマンドを入力します。 > ibmcloud -v 上記の通り、IBM Cloud CLI 1.3.0 でした。私のPC内の IBM Cloud CLI は、2021年1月頃に導入したので、かなりバージョンが古くなっているようです。 ・IBM Cloud CLIのバージョンアップを行います。 > ibmcloud update →「今すぐ更新しますか？[Y/n]」で「Y」を入力 自動でIBM Cloud CLI のインストーラーが立ち上がります。 ・インストールウィザードの画面で「Next」→「Finish」と進めます ・インストールウィザードが終了したらIBM Cloud CLI のバージョンを確認します。 > ibmcloud -v IBM Cloud CLI 2.0.3 にUpdateできていることが確認できました。 次に、Power Virtual Server 専用のプラグイン（power-iaas/pi ）を導入します。IBM Cloud CLI で Power Virtual Server を操作するためには、専用のプラグインが必要になるためです。 ・ibmcloud コマンドでプラグインの一覧を表示します > ibmcloud plugin repo-plugins -r "IBM Cloud" ・「power-iaas/pi」が「未インストール」になっていることを確認し「power-iaas/pi」を導入します。 > ibmcloud plugin install power-iaas プラグインが導入出来ました。 ・導入したプラグインのバージョンを確認します > ibmcloud plugin list 「状況」欄に「更新が使用可能です」と出力されている場合、プラグインのバージョンが古くなっています。 ・プラグインをUpdateします > ibmcloud plugin update 最新バージョンにUpdateでき、「状況」が空欄になりました。 IBM Cloud CLI の準備は完了です！ 3) FlashCopy によるバックアップの事前準備 FlashCopy を実施する前にFlashCopyに必要なパラメーターを用意します（パラメータは IBM Cloud API Docs の「Create a PVM instance snapshot」に記載されています）。 単純に出力できないパラメーターは変数に代入していきます。 FlashCopy に必要なパラメーター(変数)は以下となります。 内容 パラメーター/ 変数 ①IBM Cloud へログイン - ②認証情報 A. $TOKEN : IBM Cloud IAM アクセストークン B. $CRN：Cloud Resource Name ③Pathのパラメータ C. $CLOUD_INSTANCE_ID ：Cloud Instance ID D. $PVM_INSTANCE_ID：PVM Instance ID ④Bodyのパラメータ ・name ・description E. $VOL_ID：Volume ID それでは、上記の①～④の順番で、パラメータ(変数）を取得していきます。 ① IBM Cloud へログイン ・IBM Cloud へログインします（対話式コマンドでログインを行います）。 > ibmcloud login →「Email」にIBM Cloud ログインIDを入力 →「Password」にIBM Cloud ログイン時のパスワードを入力 →「アカウント選択」で利用するアカウントが複数ある場合はアカウントNo.を選択 IBM Cloud にログインができました。 ② 認証情報 の取得 ②では、Power Virtual Server の認証情報を取得します。 Power Virtual Server で IBM Cloud API を利用するためには、すべてのリクエストに 「IBM Cloud IAM アクセストークン」 と 「CRN※」が必要で、これは認証情報と呼ばれます。 ※ CRN：Cloud Resource Name の略。Power Virtual Server のインスタンスID と テナントIDが含まれたもの。 A. IBM Cloud IAM アクセストークンの取得 ・IBM Cloud CLI を利用しアクセストークンを出力します。 > ibmcloud iam oauth-tokens ・必要なストリングをjsonを利用して抽出し、結果を「$TOKEN 」変数に入れます。 > $TOKEN = (ibmcloud iam oauth-tokens --output JSON | ConvertFrom-Json ).iam_token IBM Cloud IAM アクセストークンのパラメータ変数「$TOKEN」 が取得できました。 B. CRNの取得 ・IBM Cloud CLI を利用しCRNを出力します。 > ibmcloud pi service-list ・出力したCRN ID のストリングを抜き出し「$CRN」変数に代入します。 > $CRN = ( ibmcloud pi service-list --json | ConvertFrom-Json).crn 「$CRN」が取得できました。 ③ Pathのパラメータ取得 ③では、FlashCopy の実行文の Path 部分に設定するパラメータを取得します。 C. Cloud Instance ID の取得 Cloud Instance ID を取得するためには「テナント ID」が必要です。「テナント ID」は「IBM Cloud のアカウントID」のことで、以下の通り、IBMCloud のWEB画面でも確認できます(https://cloud.ibm.com/account/settings)。 上記で確認できるIDをIBM Cloud CLI とAPI で取得します。 ・IBM Cloud CLI を利用し「$TENANT_ID」変数に IBM Cloud アカウントID(テナントID)を代入します。 > $TENANT_ID = (ibmcloud account show --output JSON | ConvertFrom-Json ).account_id ・IBM Cloud API を利用し、テナント状況「$TENANT_STATE」変数を作成します。 $TENANT_STATE = ( ` >> curl.exe -X GET ` >> https://tok.power-iaas.cloud.ibm.com//pcloud/v1/tenants/$TENANT_ID ` >> -H "Authorization: $TOKEN" ` >> -H "CRN: $CRN" ` >> -H "Content-Type: application/json" ` >> | ConvertFrom-Json ) ・「$TENANT_STATE 」の「cloudInstances」キーに「cloudInstanceID」が含まれているため(上記のピンク色で囲んだ値)、この値を「$CLOUD_INSTANCE_ID」変数に代入します。 > $TENANT_STATE.cloudInstances > $CLOUD_INSTANCE_ID = ( $TENANT_STATE.cloudInstances).cloudInstanceID 「$CLOUD_INSTANCE_ID」 が取得できました。 D. PVM Instance ID の取得 PVM Instance ID は、Power Virtual Server のインスタンスID のことです。下記の通り、IBM Cloud のWEB画面からも確認できます。 ・IBM Cloud CLI を利用してインスタンス情報を取得し結果を「$INSTANCE」変数に代入します。 > $INSTANCE = ( ibmcloud pi instances --json | ConvertFrom-Json ) ・「$INSTANCE」変数の「Payload.pvmInstances」キーの配下「pvmInstanceID」キーの値を「$PVM_INSTANCE_ID」変数に代入します。 >$PVM_INSTANCE_ID = ( $INSTANCE.Payload.pvmInstances.pvmInstanceID) 「$PVM_INSTANCE_ID」 が取得できました。 ④ Body のパラメータ取得 ④では、FlashCopy 実行文の Body 部分に設定するパラメータを取得します。 「name」と「description」は任意の値で構いません。 ・ name : test ・ description : snapshot-test と設定することにしました。 E. Volume ID の取得 ややこしいのですが、Volume ID は Volume Name を指しています。実際に、Volume ID というパラメーターもあるので間違えないように注意が必要です。Volume ID は、以下の通りWEB画面でも確認できます。 ・IBM Cloud CLIを利用してインスタンス名をリストし、インスタンスに紐づくボリュームを調べます。 > ibmcloud pi instances > ibmcloud pi instance-list-volumes AIX72-test ・上記のピンク色で囲んだ値を「$VOL_ID」変数に代入します。 > $VOL_ID =(ibmcloud pi instance-list-volumes AIX72-test --json |ConvertFrom-Json ).Payload.volumes.name 「$VOL_ID」 が取得できました。 4) FlashCopy の実施 すべてのパラメータが取得できたので、いよいよ(やっと) FlashCopy を実行します。 ・念のため、3)で取得したパラメータ（変数）がきちんと出力されるか確認します。 FlashCopy の実行文は IBM Cloud API Doc に記載がある以下の文です。この実行文を例に、上記の取得したパラメーター（変数）を当てはめて FlashCopy を実行します。 curl -X POST https://us-east.power-iaas.cloud.ibm.com/pcloud/v1/cloud-instances/ ${CLOUD_INSTANCE_ID}/ pvm-instances/{pvm_instance_id}/snapshots -H 'Authorization: Bearer <>' -H 'CRN: crn:v1...' -H 'Content-Type: application/json' -d '{ "name": "VM1-SS", "description": "Snapshot for VM1", "volumeIDs":["VM1-7397dc00-0000035b-boot-0"] }' 上記の実行文の通り、色々と試してみましたが、Body の部分( -d 以降) が PowerShell ではうまく実行できません。 そのため、Qiitaのブログを参考にさせていただき、Body は変数に当てはめて FlashCopy を実行しました（他の部分もかなり参考にさせていただいているブログです！）。 ・FlashCopy 実行文のBody の部分のみ変数に当てはめます。 > $BODY = '{"name": "test", "description": "snapshot-test","volumeIDs": ["' + $VOL_ID + '"] }' ・IBM Cloud API を利用して、FlashCopy を実行します。 > ( $BODY | curl.exe -X POST ` >> https://tok.power-iaas.cloud.ibm.com/pcloud/v1/cloud-instances/ $CLOUD_INSTANCE_ID/pvm-instances/$PVM_INSTANCE_ID/snapshots ` >> -H "Authorization: $TOKEN" ` >> -H "CRN: $CRN" ` >> -H "Content-Type: application/json" ` >> -d `@- ) FlashCopy が完了しました！ ・FlashCopy が正常に完了していることを IBM Cloud API を利用して確認します。(参考「Get all snapshots for this PVM instance」) > curl.exe -X GET ` >> https://tok.power-iaas.cloud.ibm.com/pcloud/v1/cloud-instances/ $CLOUD_INSTANCE_ID/pvm-instances/$PVM_INSTANCE_ID/snapshots ` >> -H "Authorization: $TOKEN" ` >> -H "CRN: $CRN" ` >> -H "Content-Type: application/json" 上記のピンク色で囲んだ値が FlashCopy の結果を示しています。 「percentComplete」が「100」、「status」が「available」であれば、FlashCopy が成功しています。 FlashCopy が成功していることを確認できました！ この後、AIX環境に変更を加えて、取得したFlashCopy のデータのリストアを行い、変更前の状態に戻っているところまで確認しましたが、長くなりましたのでブログはここで終了します。 リストアは「Restore a PVM Instance snapshot」を参考にし、今回のバックアップ手順で取得したパラメータを利用すると簡単に実行できました。 次のブログでは、IBM Cloud IA環境との接続手順をご紹介します。↓ ☆準備中です☆【やってみた】IBM Power Virtual Server AIX環境と IBM Cloud IA環境を接続してみた 最後に 今回の検証は、IBM Cloud API Docs や Qiita に投稿されているブログ を参考にさせていただきました。 Part.1 のImage Capture を利用したバックアップ方法と比べると、今回は慣れないAPIを利用したこともあり調査にとても時間が掛かりました。また、バックアップ処理自体はあっという間でも事前準備にも時間を取られました。 そのため、スピードを求められる開発環境や検証環境には、Image Capture の利用がおすすめです。 実際の運用に組み込むとしたら、FlashCopyでしょうか。 OS、ストレージ、データベース、アプリケーション。バックアップ対象も方法も様々で、バックアップ方法のドキュメントを読んでもイメージが湧かないことがよくありますが、実際に検証をしてみることで、イメージが湧き、メリットやデメリットを捉えることができるので、お客さまにも伝えやすくなります。 今後も時間を見つけ、こつこつ検証をしていきたいと思います。 お問い合わせ この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社 技術支援本部 E-Mail：nicp_support@NIandC.co.jp
製造現場やプラントでの設備資産保全業務は、「人手不足」と「属人性」がボトルネックとなって生産性向上を妨げられていることが少なくありません。日常的に安全を確保し効率的に設備資産保全業務を運用するためには、トラブルや故障時だけに実施する「後手の対応」ではなく、未然にトラブルや故障を防ぐ「予防保全」の発想を基にした保全管理業務のDXが必要となります。 本記事では、設備資産保全業務の課題解決とともに設備資産保全業務のDXを加速する統合型デジタル・プラットフォーム「IBM Maximo Application Suite」をご紹介いたします。 目次 設備資産保全業務の課題とソリューションの必要性 保全戦略を進化させる設備管理パッケージ「IBM Maximo Application Suite」 IBM Maximo Application Suiteの3つの強み IBM Maximo Application Suiteが企業の成長に寄与する理由 ビジネス機会を逃していませんか？NI＋C Pなら提案・サポートが可能です この記事に関するお問い合わせ 関連情報 設備資産保全業務の課題とソリューションの必要性 製造現場やプラントの設備資産保全業務は、これまで慢性的に「深刻な人手不足」や「設備の老朽化」、それに伴う「作業品質の低下」などの課題を抱え、その対応に迫られてきました。これら「人手不足」と「属人性」を背景とした課題だけでなく、昨今ではさらにコロナ禍における「リモート作業」や「少人数での業務遂行」もそれに加わっています。 今、設備資産保全業務には非常時にも事業を継続するための新たな取り組みが急務とされるとともに、その実現に必要となる柔軟な基盤が求められています。 こうした状況の改善方法の1つが「予防保全」へのDXを支援するソリューションの導入です。「予防保全」とは、設備構造や情報を見える化し、稼働状況や履歴、環境などを総合把握することで、トラブルが起きてから後追いで対応する従来の「事後保全」ではなく、先回りしてトラブルを予防することを意味します。 この「予防保全」を実現する戦略的設備管理ソリューションがもたらすのは、現場における人手不足と属人性からの脱却だけではありません。管理部門に対しては、生産設備の稼働時間を最大化することにより、設備停止に伴う「機会損失の最小化」、無駄に部品を交換しないことによる「交換費用の最小化」など、新たな設備資産保全業務の改善策ももたらします。 また、従来は作業負荷や入力フォーマットの物理的な限界などから記録が限定的だった保全作業の実施履歴も、現在では、IoTセンサーやモバイル端末などによって様々なデータを取得・記録できるテクノロジーが整ってきています。そして、これらの情報のすべてを保管し分析することで、設備・機器の管理に必要な予防、予測に用いることができるのです。 最近ではこれらのデータを AI とエッジ・コンピューティングを活用し分析することで以前とは桁違いの高レベルの洞察へと変換し、設備・機器の信頼性の向上と障害に強い運用を実現するために活用できます。ただ、このようなソリューションの機能を一度にすべて手にしても使いきれない恐れがあるため、自社に必要な機能のみを必要になったときに取得できる方が使わない機能に投資をしなくて済み、経済効率が高いといえます。 そこで力を発揮するのが「IBM Maximo Application Suite」です。続いて下記では、その強みと企業の成長に寄与する理由を紹介します。 保全戦略を進化させる設備管理パッケージ「IBM Maximo Application Suite」 製造現場やプラントにおいて、作業者や技術者、管理者が日々使用している CMMS（設備保全管理システム）または EAM（エンタープライズ資産管理）システムの中で、現在世界で最も利用されているソリューションの1つが、統合型デジタル・プラットフォーム「IBM Maximo Application Suite（以下 IBM MAS）」です。 IBM MAS は、Red Hat OpenShift を基盤に実績のある Maximo EAM（エンタープライズ・アセット・マネジメント）および APM（アプリケーション・パフォーマンス管理）ソリューションを単一パッケージ化しています。これにより、障害に強く信頼性の高い設備保全管理と運用に必須のインテリジェンスを提供し、将来の事業を生み出す設備保全の DX加速を支援するソリューションとなっています。 IBM MAS によって、製造現場やプラントは「ニューノーマル（新常態）」と呼ばれる現在の状況に対応する手段を構築するとともに、設備保全管理の新たな洞察と新しい働き方の循環モデルを実現し、保全戦略そのものを進化させることができるのです。 図1. IBM Maximo Application Suite主要機能一覧 ※バージョンによりご利用できる機能の範囲は異なります※予定情報を含みます※利用コンポーネント(CP4D、Kafkaなど）はアプリケーション毎に異なります IBM Maximo Application Suiteの3つの強み 次に、IBM MAS の3つの強みを紹介しましょう。 1. 豊富な導入実績と高度な専門知識を誇る、強力なコミュニティ基盤 IBM MAS の大きな強みの1つは、約30年に渡り積み上げられたIBMの豊富な導入実績です。 IBM は、その実績で生み出された多くのクライアントから成るユーザーグループを支援しており、そこで収集されたお客さまの声は IBM MAS の開発にしっかりと取り入れられています。 また、IBM には強力な業界ごとの専門知識を持つグローバル EAM（エンタープライズ・アセット・マネジメント）ビジネスパートナーたちがおり、長年にわたり製品の品質向上に寄与し続けています。 これらの分厚いコミュニティ基盤と高度な専門知識が、 IBM MAS の構成に大きな価値を与える基盤となっているのです。そのため、規制準拠を支援する IBM MAS の適応力はユーザーから高く評価されています。 2. カスタマイズの容易さが生み出す、スピード感ある開発 2つ目の強みは、高度なカスタマイズをアプリケーション内で容易に実行可能なことです。 IBM MAS の「テーラリング機能」は、プログラミングなしの GUI による簡単設定でユーザー要件に合わせた高度なカスタマイズを実行することができます。しかも、同機能によるカスタマイズはバージョンアップ対応時でも製品のサポート内です。 つまり、同機能を最大活用することにより、開発期間や工数、リスクを低減し、長期に使用するシステムの TCO（Total Cost of Ownership）を低減することが可能になります。また製品の持つ機能でカスタマイズを実現するため、簡単かつ素早くシステムを組織の固有のニーズに適合させ、効果を素早く得ることができるのです。 3. 必要な機能のみを簡単導入、成長に合わせて必要なアプリを追加購入 3つめの強みは、当初は必要な機能のみを導入し、ビジネスの成長やユーザーの状況に応じて必要なアプリケーションを簡単に追加導入できることです。 これにより、アプリケーションの使用開始タイミングをいつでも自由に変更できるだけでなくムダなく必要なときに必要な機能を追加できるため、資産ライフサイクルに大きな柔軟性を加えることができます。 またスイート製品全体でユーザー単位のライセンスを使用できるため、ユーザーは含まれる全ソリューションを利用でき、データの収集と分析、分析に基づく保全の実施にいたる包括的なソリューションを実現することが可能です。 IBM Maximo Application Suiteが企業の成長に寄与する理由 このように、IBM MAS は急速に変化する状況や想定外が続く状況下であっても、事後保全だけでなく将来の事業を生み出すための設備保全管理の「予防保全」を実現します。 次に、IBM MAS が企業の成長に寄与する理由を「マネジメント」「現場」「保全」の各視点から紹介しましょう。 【マネジメントの視点】保全戦略の高度化と現場の徹底的な見える化の実現 IBM MAS による設備構造・情報の見える化によって、「設備構造の全体俯瞰」と「ドリルダウン」が可能になります。 そのため、直感的に稼働状況や履歴、環境など製造現場の総合的な状態を把握できるだけでなく、データの集計レベルをさらに詳細に掘り下げることも可能です。 これにより、保全戦略の高度化や現場の徹底的な見える化を実現するとともに、データに基づく意思決定を素早く行うことができるようになります。 【現場の視点】日常業務の効率化の実現 IBM MAS は、今まで紙ベースだった「在庫の予実管理」「設備台帳」「状態保全・予知保全の記録」といった情報を、システム上に集約・保管します。 そのため、「点検・検査結果や設備情報の一元管理」や「直感的な情報検索や参照」が可能になります。 これにより、現場では日常点検を行う前の履歴を確認しやすくなるといった効果を得ることができ、記録を元に分析を進めることで属人性の排除や省人化を実現することができます。 【保全の視点】保全コストの最適化 IBM MAS でデジタル化された「在庫の予実管理」や「設備台帳連携」、「状態保全・予知保全」などの情報を一元管理することで、情報検索を可能にするだけでなく想定外の事象が発生する頻度を下げる「計画外の保全防止」や「保全作業の効率化」にも有効です。 これにより日常点検を効率化するとともに、保全コストを最適化することができます。 NI＋C Pならご提案サポートが可能です エヌアイシー・パートナーズは IBM Value Add Distributor として、お客さまの課題に対し長年の実績を持って IBM製品を組み合わせた複合的な解決策をご提案しています。また、IBM Maximo Visual Inspection の検証環境を提供可能なため、パートナー様提案前の技術検証（PoC）も可能です。 以下に当てはまるお客様の課題を解決したい方は、ぜひ、エヌアイシー・パートナーズまでご相談ください。 資産ロケーションと利用状況をトラッキング・可視化できていない 複雑化しすぎている資産管理作業と契約体系をシンプルにしたい 運用コストとメンテナンスコストを低減できていない 資産のライフサイクルを延長し、メンテナンスを最適化したい 機器資産の管理方法・ツールが分散しており、包括的な計画が立てられていない この記事に関するお問い合わせ この記事に関するお問い合せは以下のボタンよりお願いいたします。お問い合わせ 関連情報 IBM Maximo Visual Inspection (旧 IBM Visual Insights)（製品情報）- AI による業務の生産性向上、業務改革に取り組まれる方向けのソリューションです。 .highlighter { background: linear-gradient(transparent 50%, #ffff52 90% 90%, transparent 90%); } .anchor{ display: block; margin-top:-20px; padding-top:40px; } .btn_A{ height:30px; } .btn_A 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_A a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }
こんにちは。 てくさぽBLOGメンバーの岡田です。 IBM WebSphere Hybrid Edition（以下 WSHE）の導入をAzure上で検証してみた3回シリーズの3回目になります。 本記事ではWSHEで利用可能なアプリケーションのうち、Transformation AdvisorとCloud Foundry Migration Runtimeの導入検証を行いました。 WebSphere Hybrid Editionを導入してみた Vol.1 -OpenShift導入編- WebSphere Hybrid Editionを導入してみた Vol.2 -WebSphere Liberty導入編- WebSphere Hybrid Editionを導入してみた Vol.3 -アプリ導入編- ＊本編 １．WSHEで利用できるアプリケーション WSHEではWebsphere以外に4つのアプリケーションを利用できます。今回はこのうちTransformation Advisor（以下 TA）とCloud Foundry Migration Runtime（以下 CFMR）の2つを導入してみました。 それぞれのアプリケーションを簡単に説明します。 TA： オンプレミスで稼働しているJava EEアプリケーションやメッセージング環境をコンテナ環境へ移行・モダナイズできるかを簡単に調査・レポートできるツールです。WebSphereだけでなくWebLogic / Tomcat等のJavaEE環境、IBM MQも分析可能です。 CFMR： Cloud Foundry アプリケーションを OpenShift 上で変更せずに実行することができる機能です。Cloud Foundryを利用していた管理者・開発者・ユーザーはこれまでのCloud Foundryと同様に利用できます。 ２．事前準備 検証を行うにあたり、以下を用意しました。 ・踏み台サーバー兼NFSサーバー・・・今回はAzure上にRHEL8の仮想サーバーを作成し、リモートからこのサーバーに接続して作業しました。Persistent VolumeがTAの前提環境として必要になるため、今回は作業用サーバー上でNFSサーバーを起動し、OpenshiftのワーカーノードからNFSマウントできることまで事前に確認しました。 ・IBM ID ・・・ ライセンス・キーの入手に必要です。 ・TA用プロジェクト・・・今回は”ta"という名前で事前にOpenshift Webコンソールにて作成しました。作成手順は以下になります。 （１）Openshift Webコンソールにて、Home－Projectsを選択します。画面右にある「Create Project」ボタンをクリックします。 （２）名前（Name）に「ta」と入力して「Create」ボタンをクリックします。 （３）Projectsのリストに作成した「ta」があることを確認します。 ３．導入検証実施 IBM Cloud Pak CLI (cloudctl)を使用してコマンドラインから導入します。 以下の手順で導入を実施しました。 （１）ライセンス・キーの入手 以下のサイトにIBM IDでログインし、ライセンス・キーを入手します。ライセンス・キーが表示されたら「キーのコピー」をクリックして、ライセンス・キーを控えておきます。 https://myibm.ibm.com/products-services/containerlibrary （２） cloudctl ツールのダウンロードとインストール ・cloudctlコマンドをダウンロードします。 $ curl -L https://github.com/IBM/cloud-pak-cli/releases/latest/download/cloudctl-linux-amd64.tar.gz -o cloudctl-linux-amd64.tar.gz % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 155 100 155 0 0 593 0 --:--:-- --:--:-- --:--:-- 596 100 635 100 635 0 0 1306 0 --:--:-- --:--:-- --:--:-- 1306 100 12.2M 100 12.2M 0 0 6794k 0 0:00:01 0:00:01 --:--:-- 11.2M $ ・ダウンロードしたファイルを解凍し、パスの通っているディレクトリに移動し、実行できることを確認します。 $ tar zxvf ./cloudctl-linux-amd64.tar.gz cloudctl-linux-amd64 $ sudo mv ./cloudctl-linux-amd64 /usr/local/bin/cloudctl [sudo] xxx のパスワード: $ which cloudctl /usr/local/bin/cloudctl $ cloudctl NAME: cloudctl - A command line tool to interact with IBM Cloud Platform Common Services and IBM Cloud PrivateUSAGE: [environment variables] cloudctl [global options] command [arguments...] [command options]（以下、省略） （３）WebSphere Hybrid EditionのCASE アーカイブをダウンロード TAとCFMRの両方のプログラムが含まれているCASE（ContainerApplication Software for Enterprises）アーカイブをダウンロードします。コマンド出力がすべて”Success”となっていることを確認します。 $ cloudctl case save --case https://github.com/IBM/cloud-pak/raw/master/repo/case/ibm-websphere-hybrid-1.0.0.tgz --outputdir ./wshe-case Downloading and extracting the CASE ... - Success Retrieving CASE version ... - Success Validating the CASE ... Validating the signature for the ibm-websphere-hybrid CASE... - Success Creating inventory ... - Success Finding inventory items - Success Resolving inventory items ... Parsing inventory items Validating the signature for the ibm-cfmr CASE... Validating the signature for the ibm-transadv CASE... - Success （４）CASEアーカイブの検証 ・CP_USER および CP_APIKEY 環境変数を設定 $ export CP_USER=cp $ export CP_APIKEY=＜ライセンス・キー＞ ・oc クライアントを使用して、クラスターにログイン $ oc login -u kubeadmin -p <パスワード> https://api.nicpwhecluster.xxx.com:6443 Login successful.You have access to 59 projects, the list has been suppressed. You can list all projects with 'oc projects'Using project "ta". $ ・CASE アーカイブを検証し、ライセンスを表示 これ以降のcloudctlのコマンドはroot権限で実行しています。最後に”CASE launch script completed successfully OK”と出力されていることを確認します。 # cloudctl case launch --case wshe-case/ibm-websphere-hybrid-1.0.0.tgz --inventory installProduct --action initialize --args "--viewLicense" Welcome to the CASE launcher Attempting to retrieve and extract the CASE from the specified location [?] CASE has been retrieved and extracted Attempting to validate the CASE [?] CASE has been successfully validated Attempting to locate the launch inventory item, script, and action in the specified CASE [?] Found the specified launch inventory item, action, and script for the CASE Attempting to check the cluster and machine for required prerequisites for launching the item Checking for required prereqs...（途中省略）Kubernetes RBAC Prerequisite Verbs Result Reason *.*/ * trueUser permissions result: OK [?] Cluster and Client Prerequisites have been met for the CASE Running the CASE installProduct launch script with the following action context: initialize Executing inventory item installProduct, action initialize : launch.sh [?] CASE launch script completed successfully OK # （５）インストール構成ファイルを解凍し、確認 tgzファイルを解凍し、展開されたファイルを確認します。 # cloudctl case launch --case wshe-case/ibm-websphere-hybrid-1.0.0.tgz --inventory installProduct --action initialize --args "--acceptLicense" Welcome to the CASE launcher Attempting to retrieve and extract the CASE from the specified location [?] CASE has been retrieved and extracted Attempting to validate the CASE [?] CASE has been successfully validated Attempting to locate the launch inventory item, script, and action in the specified CASE [?] Found the specified launch inventory item, action, and script for the CASE Attempting to check the cluster and machine for required prerequisites for launching the item Checking for required prereqs...Prerequisite Result Client docker CLI must meet the following regex: version (1[7-9]|[2-9][0-9]). false Client podman CLI must meet the following regex: version 1.([4-9]|[1-8][0-9]|9[0-9]). trueRequired prereqs result: OK Checking user permissions...Kubernetes RBAC Prerequisite Verbs Result Reason *.*/ * trueUser permissions result: OK [?] Cluster and Client Prerequisites have been met for the CASE Running the CASE installProduct launch script with the following action context: initialize Executing inventory item installProduct, action initialize : launch.sh [?] CASE launch script completed successfully OK # ls -al ./wshe-case/ total 824 drwxr-xr-x. 3 root root 4096 Mar 5 08:15 . dr-xr-x---. 7 root root 198 Mar 9 05:04 .. drwxr-xr-x. 2 root root 6 Mar 5 08:15 charts -rw-r--r--. 1 root root 32 Mar 5 08:15 ibm-cfmr-1.0.0-charts.csv -rw-r--r--. 1 root root 10274 Mar 5 08:15 ibm-cfmr-1.0.0-images.csv -rw-r--r--. 1 root root 223820 Mar 5 08:15 ibm-cfmr-1.0.0.tgz -rw-r--r--. 1 root root 32 Mar 5 08:15 ibm-transadv-2.4.1-charts.csv -rw-r--r--. 1 root root 4216 Mar 5 08:15 ibm-transadv-2.4.1-images.csv -rw-r--r--. 1 root root 506537 Mar 5 08:15 ibm-transadv-2.4.1.tgz -rw-r--r--. 1 root root 32 Mar 5 08:15 ibm-websphere-hybrid-1.0.0-charts.csv -rw-r--r--. 1 root root 1195 Mar 5 08:15 ibm-websphere-hybrid-1.0.0-images.csv -rw-r--r--. 1 root root 67571 Mar 5 08:15 ibm-websphere-hybrid-1.0.0.tgz# （６）cloudctl CASE インストーラーを実行 最後に”CASE launch script completed successfully OK”と出力されていることを確認します。 # cloudctl case launch --case wshe-case/ibm-websphere-hybrid-1.0.0.tgz --inventory installProduct --action install --args "--acceptLicense" Welcome to the CASE launcher Attempting to retrieve and extract the CASE from the specified location [?] CASE has been retrieved and extracted Attempting to validate the CASE [?] CASE has been successfully validated Attempting to locate the launch inventory item, script, and action in the specified CASE [?] Found the specified launch inventory item, action, and script for the CASE Attempting to check the cluster and machine for required prerequisites for launching the item Checking for required prereqs...Prerequisite Result openshift Kubernetes version must be >=1.17.0, <1.19.0 true Kubernetes node resource must match a set of expressions defined in prereqs.yaml true Client docker CLI must meet the following regex: version (1[7-9]|[2-9][0-9]). false Client podman CLI must meet the following regex: version 1.([4-9]|[1-8][0-9]|9[0-9]). trueRequired prereqs result: OK Checking user permissions...Kubernetes RBAC Prerequisite Verbs Result Reason *.*/ * trueUser permissions result: OK [?] Cluster and Client Prerequisites have been met for the CASE Running the CASE installProduct launch script with the following action context: install Executing inventory item installProduct, action install : launch.shStarting Install ***************************************************************Login To Cluster... okstdout: Using provided cluster configuration. Logged in as kube:admin.Get Cluster Server Address... okstdout: https://api.nicpwhecluster.xxx.com:6443Save Cluster Server Address... okCheck Cluster Version... okstdout: OpenShift 4.5.31 detected.Check Cluster Administrator Role... okstdout: yesGet Authorization Endpoint... okstdout: https://oauth-openshift.apps.nicpwhecluster.xxx.com/oauth/authorizeSave Authorization Endpoint... okGet Default Cluster Subdomain... okstdout: apps.nicpwhecluster.azure-cloudpak-nicptest.comSet Cluster Subdomain... okCheck Entitled Registry Variables... okGet Existing Operator Subscriptions... okstdout: { "other": {} }Set Subscriptions Properties... okSwitch To Transformation Advisor Project... donestdout: Switched to ta project.Populate Transformation Advisor Operator Configuration... doneCreate Pull Secret... donestdout: secret/wshe-pull-secret createdInstall Transformation Advisor Operator... donestdout: operatorgroup.operators.coreos.com/ta created subscription.operators.coreos.com/wshe-transadv createdConfigure Transformation Advisor Service Account... donestdout: clusterrole.rbac.authorization.k8s.io/cluster-admin added: "system:serviceaccount:ta:ta-operator"stderr: Warning: ServiceAccount 'ta-operator' not foundAdd Security Context Constraints To User... donestdout: securitycontextconstraints.security.openshift.io/anyuid added to: ["system:serviceaccount:ta:default"]Check for Transformation Advisor Operator... okGet wshe-transadv ClusterServiceVersion... Retrying... (1 of 51) Retrying... (2 of 51) okstdout: ta-operator.v2.3.4Check ta-operator.v2.3.4 ClusterServiceVersion... Retrying... (1 of 51) Retrying... (2 of 51) Retrying... (3 of 51) Retrying... (4 of 51) Retrying... (5 of 51) Retrying... (6 of 51) Retrying... (7 of 51) Retrying... (8 of 51) okSwitch To Cloud Foundry Migration Runtime Project... donestdout: Created cfmr-operator project.Create Pull Secret... donestdout: secret/wshe-pull-secret createdConfigure Cloud Foundry Migration Runtime Service Account... donestdout: clusterrole.rbac.authorization.k8s.io/cluster-admin added: "system:serviceaccount:cfmr-operator:wshe-ibmcfmrprod-ibm-cfmr-serviceaccount" clusterrole.rbac.authorization.k8s.io/self-provisioner added: "system:serviceaccount:cfmr-operator:wshe-ibmcfmrprod-ibm-cfmr-serviceaccount"stderr: Warning: ServiceAccount 'wshe-ibmcfmrprod-ibm-cfmr-serviceaccount' not found Warning: ServiceAccount 'wshe-ibmcfmrprod-ibm-cfmr-serviceaccount' not foundAdd Security Context Constraints... donestdout: securitycontextconstraints.security.openshift.io/restricted added to: ["system:serviceaccount:cfmr-operator:wshe-ibmcfmrprod-ibm-cfmr-serviceaccount"]Install Cloud Foundry Migration Runtime Operator... donestdout: customresourcedefinition.apiextensions.k8s.io/ibmcfmrprods.cfmr.ibm.com created serviceaccount/cfmr-operator created clusterrole.rbac.authorization.k8s.io/cfmr-operator created clusterrolebinding.rbac.authorization.k8s.io/cfmr-operator created deployment.apps/cfmr-operator createdCheck for Cloud Foundry Migration Runtime Operator... Retrying... (1 of 51) Retrying... (2 of 51) Retrying... (3 of 51) Retrying... (4 of 51) Retrying... (5 of 51) okstdout: All cfmr-operator pods are running and are ready.Switch To Cloud Foundry Migration Runtime Project... donestdout: Switched to cfmr-operator project.Get Default Pull Secret... skippedSet Project Pull Secret... skippedPopulate Cloud Foundry Migration Runtime Custom Resource... doneInstall Cloud Foundry Migration Runtime Resource... donestdout: ibmcfmrprod.cfmr.ibm.com/wshe-ibmcfmrprod createdWait for Cloud Foundry Migration Runtime Install... Retrying... (1 of 301) Retrying... (2 of 301) Retrying... (3 of 301) （途中省略） Retrying... (79 of 301) Retrying... (80 of 301) Retrying... (81 of 301) Retrying... (82 of 301) Retrying... (83 of 301) okstdout: The wshe-ibmcfmrprod-ibm-cfmr job has completed successfullystderr: + NAMESPACE=cfmr-operator + LABEL_QUERY=release=wshe-ibmcfmrprod + sleep 10 ++ oc -n cfmr-operator get job -l release=wshe-ibmcfmrprod -o 'jsonpath={range .items[*]}{@.metadata.name}{end}' + JOBS=wshe-ibmcfmrprod-ibm-cfmr + for JOB_ENTRY in $JOBS ++ oc -n cfmr-operator get job wshe-ibmcfmrprod-ibm-cfmr -o 'jsonpath={.status.active}' + JOB_ACTIVE= ++ oc -n cfmr-operator get job wshe-ibmcfmrprod-ibm-cfmr -o 'jsonpath={.status.failed}' + JOB_FAILED= ++ oc -n cfmr-operator get job wshe-ibmcfmrprod-ibm-cfmr -o 'jsonpath={.status.succeeded}' + JOB_SUCCEEDED=1 + '[' -n '' ']' + '[' -n '' ']' + '[' -n 1 ']' + echo 'The wshe-ibmcfmrprod-ibm-cfmr job has completed successfully' + exit 0Get Cloud Foundry Migration Runtime UI Route... donestdout: xx.xx.xx.xx（外部IPアドレス） set_fact... ok Switch To Transformation Advisor Project... done stdout: Switched to ta project. Get Default Pull Secret... skipped Set Project Pull Secret... skipped Generate Certificate and Create Transformation Advisor Secret... done stdout: Secret transformation-advisor-secret already exists Load Generated Transformation Advisor Certificate... ok Populate Transformation Advisor Custom Resource... done Load Transformation Advisor Custom Resource... ok Customize Transformation Advisor Custom Resource... done Check Transformation Advisor Custom Resource... ok msg: All assertions passed Install Transformation Advisor Custom Resource... done stdout: transadv.charts.ta.cloud.ibm.com/ta created Check For Transformation Advisor UI... Retrying... (1 of 51) Retrying... (2 of 51) Retrying... (3 of 51) Retrying... (4 of 51) Retrying... (5 of 51) Retrying... (6 of 51) Retrying... (7 of 51) Retrying... (8 of 51) ok stdout: All ui pods are running. Check For Transformation Advisor Database... Retrying... (1 of 26) Retrying... (2 of 26) Retrying... (3 of 26) Retrying... (4 of 26) Retrying... (5 of 26) ok stdout: All couchdb pods are running. Check For Transformation Advisor Server... Retrying... (1 of 51) Retrying... (2 of 51) Retrying... (3 of 51) Retrying... (4 of 51) Retrying... (5 of 51) Retrying... (6 of 51) Retrying... (7 of 51) Retrying... (8 of 51) Retrying... (9 of 51) Retrying... (10 of 51) Retrying... (11 of 51) ok stdout: All server pods are running. Annotate Transformation Advisor Deployments... done stdout: deployment.apps/ta-ew7tae-couchdb patched deployment.apps/ta-ew7tae-server patched deployment.apps/ta-ew7tae-ui patched Get Transformation Advisor UI Route... done stdout: ta-apps.apps.nicpwhecluster.azure-cloudpak-nicptest.com set_fact... ok Mark Installation Complete... done Install successful ************************************************************* Installation complete. The IBM Transformation Advisor UI is available at: https://ta-apps.apps.nicpwhecluster.xxx.com The IBM Cloud Foundry Migration Runtime UI is available at: https://ui.xx.xx.xx.xx.nip.io [?] CASE launch script completed successfully OK # コマンド出力の最後にTAとCMFRそれぞれのアクセスするURLが表示されますのでメモしておきます。 （７）接続確認 TA：以下のURLにWebブラウザでアクセスしてページが表示されることを確認します。 https://ta-apps.apps.nicpwhecluster.xxx.com CMFR：こちらも同様に以下のURLにアクセスしてページが表示されることを確認します。 https://ui.<外部IPアドレス>.nip.io これで導入検証は完了です。 補足 以上が導入検証を実施した際の内容となりますが、現在は一部手順が更新されています。TAとCFMRは個別で導入するようにマニュアルが更新されています。これから導入される方は以下のマニュアルを確認の上、実施してみてください。 https://www.ibm.com/docs/en/websphere-hybrid?topic=installation 最後に いかがでしたでしょうか。WindowsアプリやLinuxのrpmパッケージのインストールのようには簡単ではないので、すこし難しいかなと感じました。cloudctlコマンドとCASEの利用はTA、CFMRそれぞれ単体の導入でも同様に行いますので、その際にこの記事が参考になればと思います。 ここまでお読みいただきありがとうございました。 お問い合わせ この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社 技術支援本部 E-Mail：nicp_support@NIandC.co.jp
こんにちは。 てくさぽBLOGメンバーの村上です。 本ブログは、IBM Power Virtual Server をトライしてみた内容や感想をご紹介するブログです。 シリーズ化していますので、まずインデックスのご紹介をします。 インデックス ・IBM Power Virtual ServerでAIX環境を作ってみた ・IBM Power Virtual ServerのAIX環境にSWを導入してみた ・IBM Power Virtual ServerのAIX環境を日本ロケールにしてみた ・IBM Power Virtual ServerのAIX環境をバックアップしてみた（Part.1） ←今回 ・IBM Power Virtual ServerのAIX環境をバックアップしてみた（Part.2） ・IBM Power Virtual ServerのAIX環境とIBM Cloud x86環境を接続してみた 今回は、AIX環境のバックアップ手順のご紹介です。 検証環境で2種類のバックアップ方法を試しましたので、Part.1(本ブログ)とPart.2に分けてご紹介いたします。 Power Virtual Server バックアップ方法 Power Virtual Server の AIX インスタンスでは、以下の4種類のバックアップ方法が推奨されています。 ※技術寄りな人が最初に読む_IBMCloud柔らか層本 を参照(情報は20210811版より抜粋) 取得方法 提供方法 取得対象 Image Capture IBM Cloud で提供される 任意のVolumeGroup Flash Copy IBM Cloud で提供される 任意のVolumeGroup mksysb / savevg AIX OS標準でサポートされる方式 任意のVolumeGroup バックアップ・ソフトウェア利用 お客さまが別途ソフトウェアを購入 OS領域以外のデータ領域 上記の表の太字にしていない「mksysb / savevg」と「バックアップ・ソフトウェア利用」のバックアップ方法は、オンプレミス環境で頻繁に利用されているのでイメージが付きやすいと思います。 そのため、IBM Cloud の機能で提供されている「Image Capture」と「Flash Copy」のバックアップ方法を試すことにしました。 今回は 「AIX環境をバックアップしてみた Part.1」として、Image Capture によるバックアップ取得手順と、そのバックアップデータを IBM Cloud Object Storage に保管する手順をご紹介します。 セクション 以下の1)～4)のセクションに分けてご紹介します。 1） Image Capture の説明 2） Image Capture によるバックアップ取得 3） IBM Cloud Object Storage の準備 4） IBM Cloud Object Storage への保管 準備工程にかかる時間は別として、2) の「 Image Capture によるバックアップ取得」は数十秒(バックアップ容量が20GB(USEDは13GB))、4) の「IBM Cloud Object Storage への保管」は約17分程度(圧縮後のデータ容量が6.6GB)でした。 検証はAIXのインスタンスで行いましたが、IBM i のインスタンスでも同等の手順で操作を行うことができます。 利用したクライアント端末（私のPC）は、Windows10 pro バージョン2004です。 1) Image Capture の説明 Image Capture は Power Virtual Server の WEBインターフェース画面で簡単に実行することができます。 ＜Image Capture とは＞ 説明 ・IBM Cloud で提供され、LPARのOVAイメージ(※)が出力される ・OVAイメージを使って別のインスタンスのデプロイが可能となる 主な用途 ・移行 ・複製（マスターイメージの管理） ・遠隔地保管 対象 rootvg を含む任意のボリューム 保管場所 ・Image Catalog ・IBM Cloud Object Storage 取得時の LPAR停止有無 不要 ※ ファイルの整合性担保のためにLPARを停止することが推奨される 制約事項 など ・手順を検証した上でバックアップとしても運用可能 ・サービス内の同時実行数は「1」 ・合計のボリュームサイズは最大10TB ・Flash Copy に比べると時間がかかる (※) OVAイメージとは、Open Virtual Appliance の略で、仮想サーバの構成や状態を丸ごとデータとしてファイルに写し取ったデータ形式のことです。 本来、Image Capture は移行や複製を目的とするようなのですが、制約事項に記載した通り、手順を確立する必要はあるもののバックアップとして利用できそうです。 また、制約事項に「Flash Copy より時間はかかる」とありますが、AIXユーザは mksysb や savevg の長時間バックアップに慣れているので、Flash Copy のような高速バックアップに比べて時間がかかる、くらいなら問題ないと感じます。 2) Image Capture によるバックアップ取得 前置きの説明が長くなりましたが、ここからは実際のバックアップ取得の手順となります。 IBM Cloud にログインし、インスタンスの詳細画面を表示します。 （インスタンスの詳細画面の表示方法は以前のブログに記載しています 【やってみた】IBM Power Virtual Server のAIX環境にSWを導入してみた ） ・「サーバ詳細」の右上に表示されている「VMアクション」のプルダウンをクリックし、「取り込んでエクスポート」をクリックします。 「AIX72-test の取り込みおよびエクスポート」画面が表示されます。 ・バックアップ対象ボリュームを選択します。 ・エクスポート先は「イメージ・カタログ」を選択します。 ・「カタログ・イメージ名」に任意の名前を入れます。「AIX72_CP」という名前にしました。 ・「取り込んでエクスポート」をクリックします。この操作がバックアップ実行ボタンです。 バックアップが進行しているメッセージが出力されます。 上記のメッセージのように「completed」が表示されたらバックアップが完了です。 取得したバックアップデータを確認します。 ・WEBインターフェース画面の左ペインの「ブート・イメージ」をクリックします。 ・「ブートイメージ」のリストに、先ほどバックアップを取得した「AIX72_CP」がリストアップされていることを確認します。 ※「AIX72_CP」の上に表示されている「7200-05-01」は、インスタンス「AIX72-test」作成時にできるイメージです。 以上で、簡単にバックアップが取得できました！ 通常は数十分かかるようなバックアップが1分もかからずに実行できたので驚きました。 次のセクションでは、取得したバックアップを別の場所（IBM Cloud Object Storage）にエクスポートします。 3) IBM Cloud Object Storage の準備 2) で取得したバックアップをIBM Cloud Object Storageにエクスポートする前に、IBM Cloud Object Storage のサービスを作成する必要があります（IBM Cloud Object Storage は、これ以降、ICOS と記載します）。 バックアップをICOS上にエクスポートすることで、Power Virtual Server のサービスが削除された後もバックアップデータを残しておくことができます。 ICOS には無料のライトプランが以下の条件で提供されており、今回は以下の条件に当てはまるのでライトプランを利用します。 ・1サービス、1ICOS ・最大25GBのストレージ容量 ・最大20,000 GET 要求/月 ・最大2,000 PUT 要求/月 ・最大10GB/月 のデータの取得 ・最大5GBのパブリック・アウトバウンドライト・プラン・サービスは、非アクティブで 30 日経過すると削除されます。 では、ICOSの環境を準備します。 （ICOSの準備は手順が少し長いですが、難しくないので ぜひお付き合いください） ・IBM Cloud のWEB画面右上の「カタログ」をクリックします。 ・検索バーに「object」と入力し、一番上にリストされる「Object Storage」を選択します。 以下の様に、ICOS のサービス作成画面が表示されます。 ・「リソースの構成」の「サービス名」の欄に任意のサービス名を記載します。今回は「COS-TEST」という名前にしました。 ・ライトプランなので金額が無料であることを確認し「作成」をクリックします。 ICOS サービスが作成できると下記の画面が表示されます。 ICOSサービスは、以下の通り、リソース・リストで確認でき、「ストレージ」のプルダウン以下にリストされます。 次は、「COS-TEST」内にバケットを作成します。 ・リソース・リストにリストされた「COS-TEST」をクリックします。 ・「バケットを作成」をクリックします。 ・「バケットのカスタマイズ」をクリックします。 「カスタム・バケット」の画面に移動します。 ・「固有のバケット名」に任意の名称を入れます。今回は「cos-test-2021」としました。 ・「回復力」は初期状態の「Regional」を選択したままとします。 ・「ロケーション」は「jp-tok」を選択します。 ・「ストレージ・クラス」は初期状態の「Smart Tier」を選択したままとします。 ・その他の項目は初期状態のままとし、画面の一番下にスクロールして「バケットの作成」をクリックします。 バケットが作成できました。 このバケットにアクセス・ポリシーを設定します。 ・上記の画面で「cos-test-2021」をクリックします。 ・左ペインに表示される「アクセス・ポリシー」をクリックします。 ・「ユーザを選択」のプルダウンから権限を付与するユーザを選択します。 ・「このパケットの役割」は初期状態の「ライター」を選択します。 ・「アクセス・ポリシーの作成」をクリックします。 アクセス・ポリシーの設定が完了すると以下が出力されます。 ICOSサービス資格情報を生成します。 ・左ペインより「サービス資格情報」を選択し、「サービス資格情報」の画面上に表示される「新規資格情報」をクリックします。 「資格情報の作成」の画面となります。 ・「HMAC資格情報を含める」を「オン」にします。 ・内容を確認して「追加」をクリックします。 サービスの資格情報が生成されました。 ・「cos_hmac_keys」の情報は、ICOSへバックアップデータをエクスポートする際に利用するのでコピペしておきます。 ICOSの準備が完了しました。 さて、次はバックアップイメージのエクスポート作業です。 4) IBM Cloud Object Storage への保管 2)で取得したバックアップイメージを、3) で作成したICOSのバケット内にエクスポートします。 ・2)で取得したバックアップイメージを表示します。 ・ブート・イメージ「AIX72_CP」の右側にある上矢印のマークをクリックします。これがエクスポートのボタンです。 「AIX72_CPを Cloud Object Storage にエクスポート」の画面が表示されます。 ・「リージョン」は「jp-tok」を選択します。 ・「バケット名」は3)で作成した「cos-test-2021」を入力します。 ・「HMACアクセス鍵」には、3) の手順でコピーしたサービス資格情報を入力します。 ・「HMAXシークレット・アクセス鍵」にも、3) の手順でコピーしたサービス資格情報を入力します。 ・すべての内容を確認し「エクスポート」をクリックします。 エクスポートの進捗は、ポップアップで画面に表示されます（すぐにポップアップが消えてしまい画面ショットは取れませんでした・・）。 バックアップイメージのエクスポートが完了したら、以下のようにICOSの「オブジェクト」画面にオブジェクトが追加されます。 バックアップイメージのエクスポートが完了しました！ 6.6GB のバックアップイメージがエクスポートされたことが分かります。 （OVAイメージは自動で圧縮されていました） エクスポートは約17分程度で完了しました。約6.6MB/秒 の転送速度です。 ICOSはIBM Cloud の x86側のサービスを利用しているのもあり、転送速度はちょっと遅いですね。 転送速度を上げるためには、Aspera の利用を検討してみてもよいかもしれません(利用する際は別料金です)。 ICOSを初めて利用する際はICOSの準備に少し手間がかかりましたが、バックアップイメージのエクスポートはとても簡単でした！ 次のブログでは、AIXインスタンスのバックアップ手順 Part.2をご紹介しています。 【やってみた】IBM Power Virtual Server のAIX環境をバックアップしてみた Part.2 最後に 実は、Power Virtual Server のバックアップの検証は2021年2月に完了していました。 本ブログを書くタイミングで、久しぶりにPower Virtual Server を触ってみると、ちょこちょこと仕様（画面の見え方など）が変わっていることに気づきまして、検証をやり直しました。 さすが、更新が頻繁に入っているPower Virtual Server ですね。 （情報発信は時間を置かずにすぐにやらないといけませんね！） 最新情報を逃さないよう、頻繁にチェックしていきたいと思います。 お問い合わせ この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社 技術支援本部 E-Mail：nicp_support@NIandC.co.jp
IBM Power Systems は企業情報システムの中心的存在です。 設置面積はコンパクトなのに、抜群の信頼性とパフォーマンスを発揮。止められない基幹業務を数多く担っています。セキュリティ脅威への対策など、管理負荷の高い x86サーバーに比べると運用に手がかからないという利点もあり、このシステムへの継続投資は理にかなっています。 ただし、IBM Power Systems に精通したエンジニアが減少傾向にあるのは事実で、かつ、日本では今さらなる DX推進が求められています。こうした理由から、エンドユーザー企業はシステム更改時に抜本的な環境刷新を検討するかもしれません。 そうした中、IBM Power Virtual Server はお客様が時代にキャッチアップし、IBM Power Systems上の資産を今後も維持していただくのに最適な選択肢です。 このホワイトペーパーをダウンロードして、内容を詳しくご覧ください。 ホワイトペーパーダウンロード ホワイトペーパー目次 IBM Cloudと連携して利用できるIBM Power Systems IBM Power Virtual Serverの3つの活用例 IBM Power Virtual Server提案上の注意点 エヌアイシー・パートナーズがエンドユーザー企業への提案を強力にサポート ホワイトペーパーダウンロード .anchor{ display: block; margin-top:-25px; padding-top:40px; } .btn_A{ height:30px; } .btn_A a{ display:block; width:100%; height:100%; text-decoration: none; background:#dceefe; text-align:center; border:2px solid #51aafd; color:#FFFFFF; font-size:16px; font-weight:normal; border-radius:16px; -webkit-border-radius:16px; -moz-border-radius:16px; transition: all 0.5s ease; } .btn_A a:hover{ background:#FFFFFF; color:#51aafd; margin-left:0px; margin-top:0px; border:2px solid #51aafd; box-shadow:0px 0px 0px 0px #FFFFFF inset; } .btn_B{ height:30px; } .btn_B a{ display:block; width:100%; height:100%; text-decoration: none; background:#085399; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; font-weight:normal; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #085399 ; transition: all 0.5s ease; } .btn_B a:hover{ background:#085399; color:#999999; margin-left:0px; margin-top:0px; border:1px solid #FFFFFF; box-shadow:0px 0px 0px 4px #085399 ; }
企業が利用するクラウドサービスは、これまでの情報系システムだけでなく基幹システムでの採用実績も増えています。 クラウドサービスを活用している企業は、より大きな価値を生み出すために、複数ベンダのパブリッククラウド、プライベートクラウド、オンプレミス、エッジコンピューティングを連携し活用しています。 一方で、様々な ITプラットフォームが混在することでシステム運用の煩雑さを生み、それぞれの環境でアプリケーションの開発・運用・管理の方法が異なることにより、サービス提供するまでの俊敏性や運用の効率性が損なわれてしまう、という課題があります。 この課題を解決する2021年のテクノロジー・トレンドワードとして最注目されているのが、「分散クラウドコンピューティング（以下 分散クラウド）」です。 そこで本記事では、「分散クラウド」とそれを実現する「IBM Cloud Satellite」について解説します。 Index 2021年の最注目トレンド「分散クラウド」に期待される効果 IBMの分散クラウドサービス「IBM Cloud Satellite」 「IBM Cloud Satellite」の主要なユースケース ビジネス機会を逃していませんか？NI＋C Pなら提案・サポートが可能です この記事に関するお問い合わせ 関連情報 2021年の最注目トレンド「分散クラウド」に期待される効果 既にパブリッククラウドを利活用している企業のよくある課題には、主に以下が挙げられます。 法規制やコンプライアンス遵守のためオンプレミスにデータ保持する必要がある ネットワークの遅延時間増加により、データとアプリケーションを近い場所に置く必要がある 複数のパブリッククラウドを利用した場合、個々のクラウド環境毎での運用が必要となるため、運用効率が悪く運用コストがかかってしまう オンプレミス側でも、パブリッククラウドと同等スピードでの新技術を導入し利用したい これら、多くのクラウドユーザーが抱えている課題を解決するためのテクノロジーとして、今最も注目されているのが「分散クラウド」です。 分散クラウドとは、パブリッククラウドのサービスを、オンプレミスや他のパブリッククラウド環境といった異なる物理的な場所で分散稼働させながら、「サービスの運用」や「ガバナンス」、「クラウドの進化」、「ライフサイクル管理」、「セキュリティ・信頼性・エンジニアリング」については、パブリッククラウド・プロバイダの責任のもとで利用するクラウドの利用形態のことを指します。 例えば、複数の環境で同一のアプリケーションを展開している場合、物理的に多くの場所で稼働していることによってアプリケーションの修正反映といった「俊敏性」が失われる、という課題があります。 これに対して、分散クラウドを導入することにより、複数の環境にアプリケーションを稼働する場合であってもパブリッククラウドと同じ使い勝手でアプリを迅速に開発し、リリースすることが可能になります。 また、分散クラウドではオンプレミス環境でも稼働できるため、自社所有のハードウェア上にデータを保持することで、外部にデータを保管するためのデータ保護の考慮が不要になります。 同様に、同一ロケーション内でデータを処理できるため、社外へのデータ転送がなくネットワークの遅延時間の制約を受けにくい、などの効果をもたらします。 運用面においても、クラウドベンダに依存しない一貫したアプリケーション稼働基盤となるため、インフラ層とアプリ層の運用を分離してアプリ層に注力した運用の統一化を可能にするだけでなく、オンプレ環境であっても利用量に応じた課金モデルで利用することができます。 また、分散クラウドベンダにより、随時新しい技術に更新されて利用可能となるため、運用スキルが乏しい機能であっても容易に使い始めることができるのも大きなメリットです。 このように、分散クラウドを活用することで、パブリッククラウドを活用する上での様々な課題が解決できるだけでなく、オンプレミス環境の利点も享受できるようになるのです。 IBMの分散クラウドサービス「IBM Cloud Satellite」 今、企業が抱えている課題を解決するために必要となる分散クラウドの導入を迅速に実現するのが、IBM が提供する分散クラウドサービス「IBM Cloud Satellite」です。 IBM Cloud Satelliteはフルマネージドのクラウドサービスで、IBM Cloudの様々なサービスを任意の場所で稼働させ、as-a-serviceとしてパブリッククラウドの単一の管理画面で提供します。 また、Kubernetes と Red Hat OpenShift をコアテクノロジーとしているため、デプロイ先に Red Hat OpenShift があれば、オンプレミス、パブリッククラウド、エッジなどの環境を問わず自由に展開することが可能です。 IBM Cloud Satellite の主な特長には以下が挙げられます。 パブリッククラウド・オンプレミスといった、複数の環境に導入した IBM Cloud Satellite上で稼働するコンテナアプリケーションを、IBM Cloud のコントロールプレーンで一元管理し、場所によらない一貫したサービスの稼働 セキュリティ・コンプライアンスの課題により、オンプレミス環境から移動できないデータや画像・動画といった大容量のデータ処理をする場合に、データを移動させず IBM Cloud の機能をマネージドサービスとして、データがある環境で利用可能 5Gやエッジを活用するような新しいワークロードの処理をローカル環境で実施することができるため、レイテンシが軽減でき、アプリケーションやエッジを容易に大量展開できる これらの特長が示す通り、オンプレミス、エッジ、パブリッククラウドなど、あらゆる環境で、いつでも・どこでも、一貫した環境をスピーディー、かつ、容易に提供・管理することができるのです。 図1. 「IBM Cloud Satellite」とは 「IBM Cloud Satellite」の主要なユースケース 次に、「IBM Cloud Satellite」の主要なユースケースをご紹介しましょう。 1.場所によらない一貫したサービスの稼働 自社のデータセンター内であれば、ハードウェア、ソフトウェア、アプリケーションのスタックは統一できますが、複数のパブリッククラウドも含めた環境のように、異なる基盤上で同じスタックを稼働することは簡単ではありません。 特に、パブリッククラウドを利用したマルチクラウド/ハイブリッドクラウド環境であればなおさら困難です。 しかし、運用管理の負担を軽減するためにシステム構成スタックを統一したい、という強い要件があるのも事実です。 IBM Cloud Satellite を利用することで、オンプレミス、複数のパブリッククラウドを組み合わせた基盤上で、Cloud Satellite、および OpenShift とその上で稼働するアプリケーションという、同一のスタックでアプリケーションやサービスを稼働させることが可能となり、設定の共通化・ワークロードの一元管理ができるようになります。 これにより、アプリケーション品質の均質化、リリース回数の増加、サービスの市場投入速度の短縮化が実現でき、利便性向上や顧客満足度向上にも繋がります。 さらに運用の観点では、スタックを共通化することで、運用の共通化に伴う運用コストの削減、問題発生時の切り分けが容易になります。 2.移動できないデータの処理 個人情報をはじめとしたセキュリティ・コンプライアンスの課題により、「オンプレミス環境から移動できないデータをクラウドサービスの機能を使って処理したい」というケースや、医療機関や工場におけるセンサーデータや画像データを活用した機械学習モデルを利用した分析処理など、「大量のデータを処理する時にデータを移動すると処理が間に合わない」ケースにおいては特定の場所以外ではデータを保持することができません。 これらのケースで威力を発揮するのが、IBM Cloud Satellite です。 IBM Cloud Satellite を利用することで、オンプレミス環境においても IBM Cloud の機能を活用することができるため、データ保護の観点で守るべき法規制の遵守と、クラウドサービスで様々な分析機能を利用した高度な分析の実行を両立することができます。 また、データ処理を行うアプリケーションとデータが近くに存在するため、処理にかかる時間を最小化することが可能になります。 今までデータ分析のためにクラウドにデータをアップロード、あるいは加工したデータをダウンロードしていた場合には、この操作がなくなるだけではなく、クラウドからデータを転送するための時間や費用を最小化することができます。 これによって、処理するデータの幅を広げるとともに処理時間を短縮することができるため、より多くの分析処理の実行や洞察を素早く得た上で次のアクションを決定することができるようになります。 3.新しいワークロードの処理 「5G」や「エッジコンピューティング」に代表される新しいテクノロジーは、これを活用することで大量のデバイスから発生するデータを処理し、自動車の自動運転や IoT機器を活用したリアルタイムでの分析を可能にします。 一方で、これらの処理においてはトラフィックをデータの発生元にできるだけ近い場所に集約し処理する機器 (エッジ) を利用することで、レイテンシを軽減することを基本とするシステムの稼働が求められます。 エッジは、その特性から数ヵ所のデータセンターに集約するのではなく、広い範囲に分散して配置する必要があります。 そのため、様々な場所に同じシステムを同じ形で提供し運用する必要がありますが、実現することは簡単ではなく多大なコストを要します。 こういった環境で威力を発揮するのが、IBM Cloud Satellite です。 エッジに、IBM Cloud Satellite を利用した OpenShift環境を配置し、アプリケーションを一元的に管理・更新することができるようになるため、運用管理にかかるコストを減らすことができます。 また、クラウドの特長を取り込んだ機能追加が迅速にできるため、ビジネスニーズに合わせたシステムの実現が可能になります。 ビジネス機会を逃していませんか？ NI＋C Pなら提案・サポートが可能です アプリケーションの迅速な構築とあらゆる場所での実行・一元管理を可能にする分散クラウドソリューション「IBM Cloud Satellite」に関するご提案、およびセキュリティに関する貴社取り組みについて、お悩みやご相談事項があればお気軽にエヌアイシー・パートナーズへお問い合わせください。 この記事に関するお問い合わせ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは以下のボタンよりお願いいたします。 お問い合わせ 関連情報 IBM Cloud Satellite (製品情報) - あらゆる環境で一貫したアプリケーションの構築、展開、実行ができます。 .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メンバーの岡田です。 IBM WebSphere Hybrid Edition（以下 WSHE）の導入をAzure上で検証してみた3回シリーズの2回目になります。 本記事では前回実施したAzure上にインストールしたOpenShift4.5環境に、WebSphere Liberty Coreをインストールしていきます。 WebSphere Hybrid Editionを導入してみた Vol.1 -OpenShift導入編- WebSphere Hybrid Editionを導入してみた Vol.2 -WebSphere Liberty導入編- ＊本編 WebSphere Hybrid Editionを導入してみた Vol.3 -ツール編- １．WSHEというソフトウェアが無い？ そもそもWSHEとはどのようなソフトウェアなのでしょうか。 分かりづらいですが、WSHEライセンスを購入してもWSHEというソフトウェアが利用できるわけではありません。WSHEライセンスは以下のWebSphere ApplicationServer関連の主要な製品をまとめたものです。 WebSphere Application Serverは，従来型のWebSphere traditionalおよび，コンテナ環境にも対応したWebSphere Libertyの二種類のランタイムがあります。今回は、WebSphere Libertyランタイムをインストールしてみます。 ２．作業用サーバーを用意する 今回、Azure上に構築したRHEL8サーバーに以下を導入します。＊個々のインストール手順は省略 ocコマンド podmanコマンド helmコマンド ３．WebSphere Libertyのインストール ここからは、Azure上のRHEL8サーバーにログインして行います。 （１）統合OCPレジストリーへのアクセス権を付与する ・OCPにログインします。 oc login -u kubeadmin -p <パスワード> https://api.nicpwhecluster.xxx.com:6443 ・oc get nodesでノードのホスト名を確認します。 $ oc get node NAME STATUS ROLES AGE VERSION nicpwhecluster-h8lq5-master-0 Ready master 4d23h v1.18.3+e574db2 nicpwhecluster-h8lq5-master-1 Ready master 4d23h v1.18.3+e574db2 nicpwhecluster-h8lq5-master-2 Ready master 4d23h v1.18.3+e574db2 nicpwhecluster-h8lq5-worker-japaneast-1 Ready worker 4d23h v1.18.3+e574db2 nicpwhecluster-h8lq5-worker-japaneast-2 Ready worker 4d23h v1.18.3+e574db2 nicpwhecluster-h8lq5-worker-japaneast-3 Ready worker 4d23h v1.18.3+e574db2 ・今回はマスターノードの1つ「nicpwhecluster-h8lq5-master-0」で実行します。クラスタから内部経路を使ってレジストリにアクセスします。 $ oc debug nodes/nicpwhecluster-h8lq5-master-0 Starting pod/nicpwhecluster-h8lq5-master-0-debug ... To use host binaries, run `chroot /host` Pod IP: 10.0.0.7 If you don't see a command prompt, try pressing enter. sh-4.2# ・ノード上でocやpodmanなどのツールにアクセスできるように次のコマンドを実行します。 sh-4.2# chroot /host sh-4.4# ・アクセストークンを使用して、コンテナイメージ・レジストリにログインします。 sh-4.4# oc login -u kubeadmin -p <パスワード> https://api.nicpwhecluster.xxx.com:6443 The server uses a certificate signed by an unknown authority. You can bypass the certificate check, but any data you send to the server could be intercepted by others. Use insecure connections? (y/n): yLogin successful.You have access to 58 projects, the list has been suppressed. You can list all projects with 'oc projects'Using project "default".Welcome! See 'oc help' to get started. sh-4.4# sh-4.4# podman login -u kubeadmin -p $(oc whoami -t) image-registry.openshift-image-registry.svc:5000 WARNING! Using --password via the cli is insecure. Please consider using --password-stdin Login Succeeded! sh-4.4# ・動作確認します。レジストリdocker.ioからイメージをローカルに持ってきます。 sh-4.4# podman pull docker.io/hello-world Trying to pull docker.io/hello-world... Getting image source signatures Copying blob 0e03bdcc26d7 done Copying config bf756fb1ae done Writing manifest to image destination Storing signatures bf756fb1ae65adf866bd8c456593cd24beb6a0a061dedf42b26a993176745f6b sh-4.4# ・取得できたか確認します。 sh-4.4# podman images REPOSITORY TAG IMAGE ID CREATED SIZE quay.io/openshift-release-dev/ocp-v4.0-art-dev <none> e62c0ee30db5 3 weeks ago 505 MB quay.io/openshift-release-dev/ocp-v4.0-art-dev <none> b920241dcb5e 3 weeks ago 331 MB quay.io/openshift-release-dev/ocp-v4.0-art-dev <none> 14b9f9be4696 3 weeks ago 312 MB （途中省略） quay.io/openshift-release-dev/ocp-v4.0-art-dev <none> 088760d6a49a 3 weeks ago 912 MB docker.io/library/hello-world latest bf756fb1ae65 13 months ago 20 kB sh-4.4# ・レジストリに対してpodman pushを実行します。 sh-4.4# podman tag docker.io/hello-world image-registry.openshift-image-registry.svc:5000/openshift/hello-world sh-4.4# podman push image-registry.openshift-image-registry.svc:5000/openshift/hello-world Getting image source signatures Copying blob 9c27e219663c done Copying config bf756fb1ae done Writing manifest to image destination Storing signatures sh-4.4# （２）統合OCPレジストリーのエクスポーズ ・DefaultRoute を 「True」にします。 $ oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=merge config.imageregistry.operator.openshift.io/cluster patched (no change) $ ・podmanでログインします。 $ HOST=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}') $ echo $HOST default-route-openshift-image-registry.apps.nicpwhecluster.xxx.com $ $ oc whoami -t M3Dbj0zF2oK68yG21jf7WTV37XeWR8EKRagF62QJOL0 $ $ podman login -u kubeadmin -p <パスワード> --tls-verify=false $HOST Login Succeeded! （３）SecurityContextConstraints (SCC) の定義 ・https://github.com/IBM/charts/tree/master/stable/ibm-websphere-liberty内の記載から以下の赤枠箇所の内容を含んだyamlファイルを作成します。今回はibm-websphere-liberty-scc.yamlという名前で作成しました。 ・oc applyコマンドでibm-websphere-liberty-scc を定義します。 $ oc apply -f ./ibm-websphere-liberty-scc.yaml securitycontextconstraints.security.openshift.io/ibm-websphere-liberty-scc created （４）プロジェクトwlp-sample作成 Websphere Liberty用にプロジェクトを作成します。今回は、Webコンソールから「wlp-sample」という名前で作成します。 （５）コンテナ・イメージのビルド ・server.xmlの用意 https://github.com/WASdev/ci.docker/blob/master/ga/latest/full/server.xml内の、36行あるserver.xmlの内容をコピーし、ファイルserver.xmlを作成します。 ・以下の内容のDockerファイルを作成します。 FROM ibmcom/websphere-liberty:19.0.0.12-full-java8-ibmjava-ubi COPY --chown=1001:0? server.xml /config/ RUN installUtility install --acceptLicense defaultServer ・コンテナ・イメージをビルドします。 $ podman build -f ./Dockerfile -t mylibertyapp:1.0 STEP 1: FROM ibmcom/websphere-liberty:19.0.0.12-full-java8-ibmjava-ubi Getting image source signatures Copying blob 58e1deb9693d done Copying blob 78afc5364ad2 done Copying blob 3325260754e7 done Copying blob 4427719dd2c9 done Copying blob c059e0bc6ac9 done Copying blob 0169ad963667 done Copying blob 6195cb089ab9 done Copying blob 9f87c21e1265 done Copying blob 725fc7f0231d done Copying blob 0331a4de6fdc done Copying blob bdab1c39af4a done Copying blob f5b53ae0ca41 done Copying config ce3acc7fda done Writing manifest to image destination Storing signatures STEP 2: COPY --chown=1001:0 server.xml /config/ fbd6f3d9cba9a7a72ac7a0dc3e3011b6400fdb2fd3e21fa34959dfe1925af803 STEP 3: COPY --chown=1001:0 SampleWebApp.war /config/dropins/ d64e1ce4931688a84d354446fbd4fa9f4744ef65cdcb187f830a2c9ea114dff8 STEP 4: RUN installUtility install --acceptLicense defaultServer Checking for missing features required by the server ... The server does not require any additional features. No features were installed.Start product validation... Product validation completed successfully. STEP 5: COMMIT mylibertyapp:1.0 515b092feddf7a2ebb165bbdab187bbfd54bf3bf09b55651b990b7da5b76f767 $ ・作成されたイメージを確認します。 $ podman images | grep myliberty localhost/mylibertyapp 1.0 515b092feddf 28 seconds ago 738 MB $ （６）Buildしたコンテナイメージを統合OCPレジストリーにpush ・まず統合OCPレジストリーへログインします。 $ podman login default-route-openshift-image-registry.apps.nicpwhecluster.xxx.com -u kubeadmin -p 75tT5caixaa_Mm7K6HiVT6xvbyFWeoHf1Dp1soB-21Y --tls-verify=false Login Succeeded! $ ・ビルドしたイメージに統合OCPレジストリーのホスト名とプロジェクトを示す名前を付与します。 実行したらpodman imagesコマンドで確認します。 $ podman tag mylibertyapp:1.0 default-route-openshift-image-registry.apps.nicpwhecluster.xxx.com/wlp-sample/mylibertyapp:1.0 $ podman images | grep myliberty localhost/mylibertyapp 1.0 515b092feddf 5 minutes ago 738 MB default-route-openshift-image-registry.apps.nicpwhecluster.xxx.com/wlp-sample/mylibertyapp 1.0 515b092feddf 5 minutes ago 738 MB $ ・統合OCPレジストリーへコンテナ・イメージを登録(push)します。 $ podman push default-route-openshift-image-registry.apps.nicpwhecluster.xxx.com/wlp-sample/mylibertyapp:1.0 --tls-verify=false Getting image source signatures Copying blob 995a5e8c59d9 done Copying blob 9e4e9b467e1d done Copying blob 18bd03b00625 done Copying blob 33037ee11bc5 done Copying blob 1d7ab3c032a8 done Copying blob da31cc4e7dec done Copying blob eeb6d8f926af done Copying blob 1228a4ab5ec0 done Copying blob 1235447b1b10 done Copying blob 60d1e32eff28 done Copying blob 6ab8cd79d784 done Copying blob 86b23fed23f4 done Copying blob 597be5f3fcff done Copying blob 7dd002d4a36c done Copying blob 6a5e24c477f6 done Copying config 515b092fed done Writing manifest to image destination Copying config 515b092fed done Writing manifest to image destination Storing signatures $ ・コンテナ・イメージが統合OCPレジストリーにpushされたことを確認します。 $ oc get imagestream NAME IMAGE REPOSITORY TAGS UPDATED mylibertyapp default-route-openshift-image-registry.apps.nicpwhecluster.xxx.com/wlp-sample/mylibertyapp 1.0 55 seconds ago$ oc describe imagestream mylibertyapp Name: mylibertyapp Namespace: wlp-sample Created: About a minute ago Labels: <none> Annotations: <none> Image Repository: default-route-openshift-image-registry.apps.nicpwhecluster.xxx.com/wlp-sample/mylibertyapp Image Lookup: local=false Unique Images: 1 Tags: 11.0 no spec tag* image-registry.openshift-image-registry.svc:5000/wlp-sample/mylibertyapp@sha256:bc6bc8fac41fd59b42d37e02888a3348f057c5caa0d8b41fd74d9e9f4aabdab4 About a minute ago $ （７）SCCをサービス・アカウントに付与(grant) ・（３）で作成したibm-websphere-liberty-sccをWebSphere Libertyが使用するサービス・アカウントに付与します。 $ oc project wlp-sample $ oc adm policy add-scc-to-user ibm-websphere-liberty-scc -z mylibertyapp-ibm-websphe clusterrole.rbac.authorization.k8s.io/system:openshift:scc:ibm-websphere-liberty-scc added: "mylibertyapp-ibm-websphe" $ （８）WebSphere LibertyのPodをデプロイ ・Helm Chartから変数ファイルを抽出します。 ＊WebSphere Liberty用helm Chart（「ibm-websphere-liberty-1.10.0.tgz」）をhttps://github.com/IBM/charts/tree/master/repo/stable からダウンロードしておきます。 $ helm inspect values ./ibm-websphere-liberty-1.10.0.tgz > mylibertyapp.yaml $ ・抽出した変数ファイルをエディタで開いてパラメーターを修正します。今回は以下の2箇所を更新しました。 ー （変更前）license: "" ⇒ （変更後）license: "accept" ー （変更前）ssl: enabled: true ⇒ （変更後）ssl: enabled: false ・修正した変数ファイルを指定して「helm install」コマンドを実行し、デプロイします。 $ helm install mylibertyapp ./ibm-websphere-liberty-1.10.0.tgz -f ./mylibertyapp.yaml NAME: mylibertyapp LAST DEPLOYED: Mon Mar 1 08:26:17 2021 NAMESPACE: wlp-sample STATUS: deployed REVISION: 1 NOTES: + If you are running on IBM Cloud Kubernetes Service, get the application address by running these commands: ibmcloud cs workers $(kubectl config current-context) export NODE_IP=<Worker node public IP from the first command> export NODE_PORT=$(kubectl get --namespace wlp-sample -o jsonpath="{.spec.ports[0].nodePort}" services mylibertyapp-ibm-websphe) echo Application Address: http://$NODE_IP:$NODE_PORTOtherwise, run the following commands: export NODE_IP=$(kubectl get nodes -l proxy=true -o jsonpath="{.items[0].status.addresses[?(@.type==\"Hostname\")].address}") export NODE_PORT=$(kubectl get --namespace wlp-sample -o jsonpath="{.spec.ports[0].nodePort}" services mylibertyapp-ibm-websphe) echo Application Address: http://$NODE_IP:$NODE_PORT $ ・正常にデプロイできたか確認します。 $ helm list NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION mylibertyapp wlp-sample 1 2021-03-01 08:26:17.876891227 +0000 UTC deployed ibm-websphere-liberty-1.10.0 19.0.0.6 $ ・作成された主要なOCPリソースの一覧と状況を確認します。 $ oc get all -l app=mylibertyapp-ibm-websphe NAME READY STATUS RESTARTS AGE pod/mylibertyapp-ibm-websphe-76478c8fcd-ngqpp 1/1 Running 0 82sNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/mylibertyapp-ibm-websphe NodePort 172.30.179.226 <none> 9080:30797/TCP 82sNAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/mylibertyapp-ibm-websphe 1/1 1 1 82sNAME DESIRED CURRENT READY AGE replicaset.apps/mylibertyapp-ibm-websphe-76478c8fcd 1 1 1 82s $ （９）手作業でRouteを定義し、WebSphere Libertyにアクセスします ・作成されたServiceを確認します。 $ oc get service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE mylibertyapp-ibm-websphe NodePort 172.30.179.226 <none> 9080:30797/TCP 112s $ ・Routeを作成します。 $ oc expose service mylibertyapp-ibm-websphe route.route.openshift.io/mylibertyapp-ibm-websphe exposed $ ・RouteのHOST名を確認します。 $ oc get route NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD mylibertyapp-ibm-websphe mylibertyapp-ibm-websphe-wlp-sample.apps.nicpwhecluster.xxx.com mylibertyapp-ibm-websphe http None $ ・最後に、Webページにアクセスしてみます。 ー コマンドの場合 $ curl -s http://mylibertyapp-ibm-websphe-wlp-sample.apps.nicpwhecluster.xxx.com <!DOCTYPE html> <html lang="en" xml:lang="en"> <head> <meta charset="utf-8" name="viewport" content="width=device-width,initial-scale=1.0"> <!--title data-externalizedString="WELCOME_TITLE"></title--> <title>WebSphere Liberty 19.0.0.12</title> <style> @font-face { font-family: IBMPlexSans-Medium; src: url('fonts/IBMPlexSans-Medium.woff'); } （以下、省略） ー Webブラウザの場合 ４．まとめ いかがでしたでしょうか。 コンテナ版なのでインストールは簡単かな、と思っていたのですが実行するコマンドも多くて結構大変だった印象です。大まかには「コンテナイメージのビルド」⇒「OCPレジストリにプッシュ」⇒「Podのデプロイ」という流れなのですがそれぞれの工程ごとにいろいろなコマンドを打つ必要があるので、実際にやってみようと思われている方の参考になればと思います。 ここまでお読みいただきありがとうございました。 次回はWSHEで利用可能な各種ツール群をインストールしてみた内容をお伝えいたします。 お問い合わせ この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社 技術支援本部 E-Mail：nicp_support@NIandC.co.jp
