2018年01月

18

VMware on IBM Cloudでクラウド化の提案してみませんか

こんにちは。てくさぽBLOGメンバーの山田です。

クラウドサービスのお問い合わせが少しずつ増えてきていますが、クラウド化については未だ皆さん悩まれているようです。今日はクラウド化を考えるヒントになるクラウドサービスについてご紹介したいと思います。

国内のプライベートクラウド市場

AIやIoTといった最先端のテクノロジー分野の話題が盛んな今日、SaaSのようなパブリッククラウドへの移行が加速する一方、以下のIDC Japanのレポートによると、国内プライベートクラウド市場もまだまだ成長するようです。

ここでいうプライベートクラウドとは、オンプレミス・プライベートクラウド、ホスティング・プライベートクラウド(Dedicated)、ベンダーがプライベートクラウド・サービスを提供するコミュニティ・クラウドを含んでいます。

オンプレミス・プライベートクラウドの比率は下がっていくものの、プライベートクラウド全体は2021年の支出額は2016年比5.2倍、成長率も35%以上と高い成長率が続くと予測されています。


出典:IDC Japan 10・2017 国内プライベートクラウド市場 支出額予想

インフラと密接な関係があるバックアップや可用性、運用監視などの非機能要件は、クラウド化することによって、利用者側の制御範囲が変わったり、アプリケーション側で吸収できるように変更する必要があったり、というアーキテクチャーの変更検討が必要となります。これは俊敏性や柔軟性をもつクラウドを効果的に活用したいと考えている企業にとって、クラウド化検討におけるブレーキにもなっています。

既存環境はオンプレミスのまま使い続けるしかないのでしょうか。既存環境を活かしながらクラウドのメリットを享受することはできないのでしょうか。

そんなお客様には、VMware on IBM Cloudをご紹介してみてはいかがでしょう。

 

なぜオンプレミスをそのまま移行できるのか

クラウド化を検討する際、すべてのケースでアーキテクチャーの変更が必要になるわけではありません。下図のように変えなくてよいものはシステム更改などに合わせてアーキテクチャーを変更せず”リフト”によってクラウド上で稼働させる。また、変えた方がよいものでも、一旦アーキテクチャーを変更せず”リフト”したうえで、クラウドに最適化されたアーキテクチャーに変更して”シフト”する、という方式が考えられます。

リフト&シフトについては、こちらの特集記事”【特集】知らないでは済まされない?! IBMクラウド戦略 3つのキーワードに迫る!”もご参照ください。


図1:IBMホワイトペーパー”VMware環境のクラウド移行を成功させるための最適解とは?”より抜粋

VMware on IBM Cloudは、ベアメタル(専用物理サーバー)上に構築された、インフラ・運用・パートナーソリューションを自由に組み合わせることができるIBM Cloudのソリューションで、オンプレミスで使用していたVMwareのサーバー仮想化ソフトやストレージ仮想化機能をサブスクリプション型で利用できるサービスです。

図2:VMware on IBM Cloudのデプロイメント方式(IBM Cloud柔らか層本より抜粋)

上図のように、VMware on IBM Cloudでは、要件や規模に応じて3種のデプロイメント方式が用意されています。
いずれのデプロイメント方式においても利用者側に管理者権限が付与され、オンプレミス環境でのアーキテクチャーを変更することなく、”リフト”によるクラウドへの移行を実現でき、自由度の高いクラウドの恩恵を得ることができます。
特に図の左側にあるVMware vSphere on IBM Cloudでは、個別カスタマイズ型のため、オンプレミスで培った運用・ポリシー・ツール・スキルなどを活かしながら、クラウドのメリットを享受できます。

VMware on IBM Cloudの優位性

ベアメタルという専用物理サーバーを活用している点で、ホスティング型クラウドと似ている点もありますが、以下のようにクラウドならではの俊敏性や柔軟性を実現しています。一番の優位性は、移行の容易性、すなわち、vSphereの環境のVMをそのまま稼働させることができることですが、他にも以下のような優位性があります。

  • 最短30分、最大でも4時間程度で環境をデプロイメント可能
  • デプロイメント後のプロセッサー変更も可能
  • 1時間単位での課金も可能、最低契約期間の縛りもなし
  • CPUの選択肢も多く、最新機種や話題のGPU搭載マシンも選択可能

AWSやIIJなどIBM以外のクラウド業者もVMware社との提携を進め、ベアメタルの提供も始めています。

IBM Cloudのベアメタルは2005 年から提供されており多くの実績がありますが、クラウドインフラの特長と合わせ、他社と比較して以下の優位性があります。

  • 要件や規模に応じた複数のデプロイメント方式を提供(図2参照)
  • 日本を含む世界中40拠点以上のデータセンターで利用可能
  • 各データセンター間の高速回線を無償で利用可能
  • データセンターの場所が公開されており、オンプレミスとクラウド間での専用線接続が可能
  • 利用者がVMwareの管理者権限を保有可能
  • 既存のVMwareライセンスをそのまま持ち込める など

たとえば、多くのクラウドベンダーではVMware管理者権限がユーザー側に与えられないため、レプリケーションやセキュリティ機能の独自強化ができないなど、オンプレミスからの移行に大きな影響を与える可能性があります。

また、ここでは詳しくご説明しませんが、オープンスタンダード技術でつくられたPaaS連携やAPIによる操作性の良さもIBM Cloudの特長です。

 

さいごに

個別カスタマイズ型の”VMware vSphere on IBM Cloud”だけでなく、NSXやvSANの機能を素早く使いたい、VMware社認定構成で使いたい、ZertoやVeeamなどのパートナーソリューションもワンストップで提供してほしい、といった要件であれば、自動構築型の”VMware vCenter Server on IBM Cloud(VCS)”やVMware Cloud Foundation on IBM Cloud(VCF)” といったデプロイメント方式も有効です。

また、今回ご紹介したような“そのまま移行する”が実現できることにより、既存システムとクラウドの連携が進み、オンプレミスとパブリッククラウド、あるいは複数のクラウドをシームレスにつなぎたいという、ハイブリッドクラウドの要件も増えてくると思います。

昨年、VMwareとIBMが共同で発表した「VMware HCX テクノロジー」は、オンプレミスとクラウドのvSphere環境をシームレスに接続し、相互運用やアプリケーション・モビリティを実現する技術で、旧バージョンのオンプレミスのVMware環境から、最新のIBM Cloud のVMware環境に容易にワークロードをマイグレーションできますし、ゼロダウンタイムで大規模な移行が可能になります。
このテクノロジーは、IBM Cloud で先行して提供されるようです。

F5 NetworksやFortinetと協業したパブリッククラウドでのセキュリティ強化サービスも提供されるなど、企業のクラウド化を促進するサービスがどんどん発表されていますので、引き続き皆様にご紹介していきたいと思います。

 

※この記事は2018年1月17日時点の情報を元に作成しています。

この記事に関する、ご質問は下記までご連絡ください。

エヌアイシー・パートナーズ株式会社

技術支援本部

E-Mail:nicp_support@NIandC.co.jp

その他の記事

2021年06月18日

“増えて消せない”データのために描く、企業規模のストレージ戦略

日本企業が未来のために進むべき道の1つとして、DXがあります。ただしその一方で、こうした業務のデジタライゼーションがデータ爆発を加速させていることも確かです。 重要な資産であるデータを格納するストレージは容量がひっ迫しがちになり、パフォーマンスの劣化やその回避策に苦慮している企業は多いことでしょう。データが増えるとバックアップ運用の難易度も上がります。 また、ストレージは業務システムごとに部分最適で導入される傾向があり、管理工数という点でもコストという点でも、負荷の高さが課題でした。 本格的な DR対策も長年の懸案事項です。加えて、企業の収益向上に資するデータ分析や AI活用も求められています。スピード経営を実現するためにコンテナ技術を取り入れたい、と構想する企業も増えてきました。 本記事では、まだまだストレージの機能を使いこなせていないというエンドユーザー企業の悩みに応えるために、企業情報システムのストレージ戦略の中核テクノロジーとして活躍する IBM Spectrum Scale をご紹介します。   ストレージ課題で悩む企業への解決策は、IBM Spectrum Scale IBM Spectrum Scale は、企業情報システムのデータ戦略の中核に位置付けるにふさわしいスケールアウト型のストレージ・ソフトウェアであり、エンタープライズ・データ・サービスです。 これによって様々なストレージ課題を解決できます。 その構成は、クライアントに対する窓口の役目を果たし、NFS/SMB/オブジェクトプロトコルに対応するプロトコルノードと、共有ディスク・アクセスを直接行うNSDサーバーからなります。 また、ストレージはそのバックエンドのストレージプールにおいて共用可能な状態で提供されます。 図1. IBM Spectrum Scale は、多様なデータのハブとなるエンタープライズ・データ・サービス プロトコルノードと NSDサーバーは、利用形態に合わせて柔軟に増減できます。 ストレージ上のファイルにアクセスするクライアントが増えるのならプロトコルノードを増やす、データ量が増えたなら NSDサーバーを増設するといった具合に、どんどんスケールアウトしていくことが可能です。 あらためて IBM Spectrum Scale の特長を紹介すると、次のようになります。   1. バックアップ効率化やDR対策として活用できる拠点間連携機能 IBM Spectrum Scale には Active File Management (以下、AFM) と呼ばれる機能があり、複数拠点間で非同期コピーを自動で実現します。データがすべてを選択することも可能で、一部に絞ることもできます。 また、キャッシュはリードオンリー、リード/ライト、DR など、様々なモードが選択可能です。   2.担当者を手作業管理から解放するデータ階層化機能 これは、データの自動振分け機能です。 IBM Spectrum Scale は、フラッシュ、SSD、SAS、SATA、 NL-SAS といった異なった種類のストレージを混在させてファイルシステムを構成することができます。 そのため、高頻度にアクセスされるデータは高速ストレージに、アクセス頻度の低いデータは低速ストレージに、といったデータの適材適所の保存を苦もなく実現。ストレージのみならず、テープやクラウドとも自動連携可能 (テープとの連携は別途ソフトウェアが必要) です。 ユーザーは、どのストレージプール上にファイルがあるか を意識する必要がなく、データが移動しても同じ操作でアクセスが可能です。これによって、ストレージ担当者はデータ保管先を管理する作業から完全に解放されます。   3.高い拡張性とパフォーマンス 拡張性・パフォーマンスに優れたファイルシステムです。 プロトコルノードは最大16,384ノードまで拡張可能。格納できるファイルの上限数は9千兆個で、最大ファイルシステム・サイズは8 エクサバイト。つまり、800万テラバイトに上ります。 これだけの容量があれば、ほとんどのケースでストレージ容量の上限に悩まされることなく、リニアに拡張性を追求していくことができます。 パフォーマンスという観点でも、ブロックサイズ単位で分散並列I/O が可能な一方で、最大16MiBの大容量ファイルにも対応。2.5テラバイト/secという高いスループットもすでに実証されており、高速処理が求められるシステムに適用可能です。   4.多様なプロトコル対応で全体最適のデータ戦略を後押し プロトコルノードの追加により、Windows環境の CIFS、SMB、UNIX環境の NFS、オブジェクトの HTTPS、Hadoop の HDFS など、様々なプロトコルでのファイルアクセスが可能です。 そのため、異なるプロトコルが混在する企業情報システムであってもそれぞれを "サイロ化" させず、部分最適ではなく全体最適の観点でストレージ活用が可能になります。   5.ビジネススピードを加速させるOpenStack対応 KVMホストに Spectrum Scale Client をインストールすることで、IBM Spectrum Scale は OpenStack のバックエンドストレージとしても活用できます。 Copy on Write機能により、インスタンス/ボリューム の高速な作成や容量の効率的な使用が可能。複数ホストでファイルシステムを共有できるため、Live Migration を行いたいなどというときも、データのコピーを行うことなく短時間で切り替えられます。   6.分析結果をよりスピーディーに活用できるHDFS対応 Hadoop はオープンソースで大量のテキストデータを分散処理によって高速に処理可能な主要技術ですが、分析対象となるデータを配置するファイルシステム HDFS はそのままではデータの格納庫として利用できません。 分析結果の利用先システムが分析対象データの発生元システムのデータを利用するにはデータコピー作業が必要になり、ストレージを別に用意しなければなりません。 しかし IBM Spectrum Scale なら、分析対象データの発生元システムが Hadoop で利用する IBM Spectrum Scale 上のディレクトリにデータを直接書き込みさえすれば、分析結果の利用先システムはデータを直接読むことができます。 これは、分析結果をそれだけ早く現場で活用できることを意味し、DX推進につながります。   短期間で構築可能なアプライアンス:IBM Elastic Storage System IBM Spectrum Scale は Software Defined Storage であるため、プロトコルノードや NDSサーバーを自由に選択したり、既存のサーバーを有効活用できる、という利便性があります。 その稼働環境も、IBM AIX®、Red Hat Linux、SUSE Linux Enterprise Server、Microsoft Windows Server、Microsoft Windows、IBM z Systems™と幅広いため、企業のシステム環境に合わせて選択できる自由があります。 しかし、エンドユーザーであるお客様によってはそれがかえって面倒と感じられるかもしれません。 その場合は、アプライアンスとして提供される IBM Elastic Storage System がお勧めです。 幅広いラインナップがそろっており、ハードウェア構築、ソフトウェア導入およびテストを工場で事前に実施。お客様サイトには、ラックにマウント可能な状態で搬入できます。 お客様は当初から利用に専念でき、保守およびサポート窓口が一本化されるため、自ら障害切り分けに動く必要もありません。   こんなシチュエーションで活かせます Case 1. バックアップ運用の効率化に AFM機能を利用します。 全拠点の全ファイルを、本社データ・センターで集中管理します。IT担当者のいない遠隔地拠点では、バックアップ運用は行わず本社データ・センター側でまとめて実施します。遠隔地拠点では、よく使うファイルだけがキャッシュされるようにします。 拠点内であるため、高速なアクセスが実現します。 図2. AFM機能を利用した本社・遠隔地拠点間連携   Case 2. AI分析基盤として IBM Spectrum Scale は、データ蓄積のために求められるストレージ要件を満たしています。 それは、「多様なシステムと連携可能なプロトコル対応」「分散したデータを集約する遠隔地連携機能」「高いコストパフォーマンス」です。また、データ分析のために求められるストレージ要件にも合致しています。 それらは、「処理性能に合わせた分散処理機能とスケーラビリティ」「高い性能を引き出すオールフラッシュ・ストレージとの連携機能」「ハイブリッド・クラウド環境でのデータ連携機能」で、これらの点から、深層学習の基盤などとしても最適の環境です。   Case 3. アーカイブ自動化で ストレージプールを、ゴールド、シルバー、ブロンズと階層化します。 階層化に使用できるファイル属性には「最後にファイルアクセスがあった日時」「最後にファイル修正があった日時」「ファイルセット名」「ファイル名 / ファイル拡張子名」「ファイルサイズ」「ユーザーID / グループID」「ファイルアクセス頻度(ファイルヒート)」があり、これらに基づいてポリシーを策定。 Gold にあるデータがポリシーの閾値を超えたらシルバーに移動、またそこで閾値を超えたらブロンズに移動させます。そして、ブロンズで365日間アクセスがなかった場合はファイルシステムから削除。逆に、2日未満の間隔でアクセスがあったらシルバーに移動、などといった具合に、アーカイブ自動化により絶え間ないデータ循環が実現します。   Case 4. 増え続ける大容量データへの対応に 生命科学研究の最前線ではゲノム解析が進んでおり、そこでは膨大なデータが発生します。 10人分の全ゲノムで1テラバイトボリュームのデータになるといい、さらに解析を付加することでデータ容量はますます膨らんでいきます。 こうした指数関数的なデータ増加に対しても、800万ペタバイトまで拡張可能な IBM Spectrum Scale であれば、余裕を持ってシステム構築を行えます。   ビジネス機会を逃していませんか?NI+C Pなら提案・サポートできます エヌアイシー・パートナーズ (NI+C P) は、1990年代に IBM Spectrum Scale の前身である GPFS が登場したときから、進化を長く見守ってきました。そのため、この技術については深く熟知しているという自信があります。 提案先のストレージ担当者が何か課題を抱えておられるようなら、ぜひ、その情報を共有してください。ともに解決策を模索しましょう。 ひょっとすると、IBM Spectrum Scale はソフトウェア製品であるために全体像がつかみにくいかもしれません。そのような場合には、弊社の検証環境設備で実際に製品の動作を見ながらご相談にのることも可能です。 データを企業資産ととらえ、全社ストレージ戦略を立案したい情報システム部門と、それを支えたいパートナーの皆様のお力になれると思います。お気軽にお声がけください。     この記事に関するお問合せ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは、「こちら」からお願いします。   参考情報 IBM Spectrum Scale (製品情報) IBM Spectrum Archive (製品情報) データ爆発時代が生んだ、“手間レス”オールフラッシュストレージ (コラム) 「壊れにくく、処理速度が落ちない」IBM FlashSystem の特長とラインナップを徹底解説 (コラム)  

2021年06月08日

【やってみた】WebSphere Hybrid Edition導入してみた:OpenShift導入編

こんにちは。 てくさぽ BLOG メンバーの岡田です。 今回はIBM WebSphere Hybrid Edition(以下、WSHE)の導入をAzure上で検証してみたので3回シリーズで検証で得られた知見をお伝えします。 当初は前回実施したIBM Cloud Pak for Applications(以下、CP4Apps)導入検証をプラットフォームをAzureに変えて検証する予定で進めていたのですが、CP4Appsが販売終了となり後継としてWSHEが発表されたので内容を変更し、WSHEをAzure上で検証することにしました。 今回は3回シリーズの1回目です。 第一回:【やってみた】WebSphere Hybrid Editionを導入してみた:OpenShift導入編 *本編 第二回:【やってみた】WebSphere Hybrid Editionを導入してみた:WebSphere Liberty導入編 第三回:【やってみた】WebSphere Hybrid Editionを導入してみた:ツール編   1.はじめに 前回、CP4Apps導入検証の際にはAWS上にUser Provisioned Infrastructure(以下、UPI)方式でOpenShift4(以下、OCP4)を構築してみましたが、今回はAzure上でもUPI方式で行ってみました。 なお、筆者はAzure未経験だったので何箇所かつまづきましたが、初心者はこんなところでつまずくんだなあ、と思って読んでいただけると幸いです。 手順は以下を参考にしました。 1.7. ARM テンプレートを使用したクラスターの AZURE へのインストール https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.5/html/installing_on_azure/installing-azure-user-infra OCP4導入後にWSHEのコンポーネントを導入する予定のため、OCP4のバージョンは4.5を利用しました。(現在はOCP4.5~4.7までサポートされていますが、検証当時はOCP4.5のみサポートでした。) 今回の環境・サーバー構成の概要図は以下となります。Bootstrapを除くと計6ノード構成になります。   2. 事前準備 2-1. 作業用Linux環境準備 OpenShiftのインストール作業に必要なLinux環境を準備します。 今回の作業環境は以下になります。 環境:手元のPC(Windows 10 1909)上にWindows Subsystem for Linux(WSL)+Ubuntu 18.04 実行ユーザー:user01を作成 (1)作業用ディレクトリとして以下2つのディレクトリを作成 /home/user01/os45      ※OpenShift インストールプログラム置き場 /home/user01/os45/conf  ※yamlやjsonなどの設定ファイル置き場 (2)Azure CLIインストール (3)jqパッケージインストール (4)cloudctlインストール (5)ocコマンドインストール 以下の手順でダウンロードします。 ・Red Hat Custmer Portalにログインします。「ダウンロード」をクリックし、次の画面で"Red Hat OpenShift Container Platform"をクリックします。 ・次の画面でバージョン4.5の最新バージョンを選択し、画面下から”OpenShift v4.5 Linux Client"を/home/user01/os45フォルダにダウンロードし、ファイルを解凍し、パスの通っている/user/local/binフォルダに移動します。   2-2. ファイルの準備 (1)OCP4.5インストールファイルのダウンロード ・ocコマンドをダウンロードしたのと同じページで”OpenShift v4.5 Linux Installer"を/home/user01/os45フォルダにダウンロードします。 (2)Pull Secretファイル Red Hat OpenShift Cluster Manager サイトの「Pull Secret」ページから、インストールプルシークレットを/home/user01/os45フォルダにダウンロードします。   2-3. パブリックDNSゾーン設定 (1)リソースグループを作成 まずリソースグループを作成します。今回は「ocp-cluster」という名前のリソースグループを作成しました。 次の画面のタグは特に設定せずに進み、確認画面で「作成」ボタンをクリックします。 (2)App Serviceドメインを作成 今回は「azure-cloudpak-nicptest.com」という名前で作成しました。事前にレジストラからドメイン名を購入せずに作成できるかやってみましょう。 【連絡先情報】を入力します。 ドメインのデプロイが完了したら、nslookupやdigコマンドで確認しました。正しく引けたので、無事ドメインが作成できたようです。別途ドメイン名を用意しておかなくてもよかったです。 〈つまづきポイント:その1〉DNSドメインが正しく作成されない 連絡先情報の”州または準州”の箇所に、最初は”Tokyo-to"と入力してドメインを作成たところ、以下のエラー画面となり正常に作成されませんでした。 原因は”Tokyo-to”と入力した箇所でした。一旦既に作成されていたリソースを削除し、再作成の際に”Tokyo"と入力することで無事ドメインが作成できました。以下は再作成で成功した画面です。 〈つまづきポイント:その2〉Azure アカウント制限は拡張する必要がある? 参考にしたマニュアルにはvCPUの「デフォルトの Azure 制限」がリージョン毎に20、説明に”デフォルトのクラスターには 40 の vCPU が必要であるため、アカウントの上限を引き上げる必要があります。”と書いてあったので引き上げないといけないと思い込みサポートに事情を説明しリクエストしました。ところが、サポートからの回答は契約したサブスクリプションではデフォルトの制限は350コアで必要数は最初から超えているとのことでした。 Azure Portal の [サブスクリプション] ページの [使用量 + クォータ] セクションで確認できると教えてもらいましたので、皆さんもAzure上でOpenShift構築を実施する前には一度確認してみてください。   2-4. サービスプリンシパルの作成 そもそもサービスプリンシパルとはなんでしょう?Azure初心者の私もよく分からず、調べた結果、「Azureリソースを管理・操作するアプリケーションのためのアカウント」とのことでした。 今回はAzure Resource Managerでリソースが構築されるので、そのための専用アカウントと理解しました。 以下を実施します。 (1)Azureへのログイン(az login) (2)アクティブなアカウントの詳細を表示して「tenantId」「id」を確認 (3)アカウントのサービスプリンシパルを作成し「appId」「password」を確認 (4)サービスプリンシパルに追加パーミッションを付与 (4-1)User Access Administrator ロールを割り当て (4-2)Azure Active Directory Graph パーミッションを割り当て (5)パーミッション要求を承認   3.OpenShift 導入 3-1. SSH秘密鍵の作成 クラスタの作成後に、ノードにアクセスするためにSSH秘密鍵を作成します。 (1)作業用Linuxマシン上でgenコマンドを実行しSSHキーを作成 (2)ssh-agent プロセスをバックグラウンドタスクとして開始 (3)SSH プライベートキーを ssh-agent に追加   3-2. インストールファイルの作成 (1)install-config.yaml ファイル生成 (2)ARM テンプレートの一般的な変数のエクスポート (3)クラスターの Kubernetes マニフェストを生成 (4)コントロールプレーン、ワーカーノードを定義する Kubernetes マニフェストファイルを削除 (5)Kubernetes マニフェストファイルを変更 (6)変数のエクスポート (7)Ignition 設定ファイルを取得 (8)ファイルの確認   3-3. Azure リソースグループおよびアイデンティティーの作成 OCPクラスタのインストールに必要なリソースグループとアイデンティティーを作成します。 (1)リソースグループを作成 (2)リソースグループの Azure アイデンティティーを作成 (3)Contributor ロールを Azure アイデンティティーに付与 (3-1)ロール割当に必要な変数をエクスポート (3-2)Contributor ロールをアイデンティティーに割り当て   3-4. RHCOS クラスターイメージおよびブートストラップ Ignition 設定ファイルのアップロード (1)Azureストレージアカウントの作成 (2)ストレージアカウントキーを環境変数としてエクスポート (3)VHD の URL を環境変数にエクスポート (4)選択した VHD を blob にコピー (5)blob ストレージコンテナーを作成し、生成されたbootstrap.ignファイルをアップロード   3-5. DNSゾーンの作成 (1)プライベートDNSゾーンを作成   3-6. Azure での VNet の作成 (1)デプロイメントを作成 (2)VNet テンプレートをプライベート DNS ゾーンにリンク   3-7. RHCOS クラスターイメージのデプロイ (1)RHCOS VHD blob URL を変数としてエクスポート (2)クラスターイメージのデプロイ   3-8.ネットワークおよび負荷分散コンポーネントの作成 (1)ネットワークオブジェクトおよびロードバランサーのデプロイ (2)変数のエクスポートとクラスターを既存のパブリックゾーンに追加 以上で、OCPノードを作成する手前まで完了しました。   3-9.ノードの作成 (1)ブートストラップマシンの作成 (2)コントロールプレーンの作成 (3)ワーカーマシンの作成 (4)クラスターへのログイン (5)マシンの証明書署名要求の承認 (6)ブートストラップリソースを削除 (7)クラスターのインストールを完了する (8)ログイン クラスタにログインできたのでインストールは成功です! 長かったですね、最初のディレクトリ作成から数えて計50工程がようやく終わりました。   まとめ いかがでしたでしょうか。やはりUPIは作業工程が多くて大変でした。 記載のとおり、Azureでの確認や設定で何箇所かつまづきましたが、コマンドを実行していくところはマニュアル記載のコマンドでエラーなく進めることができました。 もっと簡単にOCP環境を構築したいのであればIPI(Installer Provisioned Infrastructure)方式もありますが、構成をカスタマイズしたくてUPI方式を選択することもあるかと思いますので、その際にこの記事が参考になればと思います。 ここまでお読みいただきありがとうございました。 次回は構築したこのOpenShift上でのWebSphereをインストールしてみた内容をお伝えいたします。     この記事に関する、ご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社 技術支援本部 E-Mail:nicp_support@NIandC.co.jp

back to top