2018年03月

30

【速報】IBM のパートナー様向け旗艦イベント “PartnerWorld at Think 2018” (3/20~22)に参加してきました!

皆さんこんにちは。エヌアイシー・パートナーズ 取締役 企画本部長 平沢 です。

先週、IBM 初の試みとなる全ブランドが集結する世界最大規模のイベント”Think2018“がラスベガスにて開催されましたが、今回は、その中の PartnerWorld at Think の模様をいち早く、ご紹介していきます。

ラスベガス MGM Grand ホテルで盛大に開催!

PartnerWorld at Think は 3月20日の Beacon Award 表彰式から 22日のクロージング・セッションまで 3日間に渡り、ラスベガスの MGM Grand ホテルで開催されました。

MGM Grand ホテルでの
Beacon Award 表彰式風景

IBM Global Business Partners を率いる John Teltsch ゼネラルマネージャーが「今年は簡素化を一層推進し、パートナー様にとって付き合い易い IBM になる年とする」と宣言し、基調講演が始まりました。今回の際立ったトピックスは以下の2つでした。

● パートナー様トランスフォーメーション事例
● スペシャルゲスト Earvin “Magic” Johnson 氏の講演

パートナー様トランスフォーメーション事例

先ず「パートナー様トランスフォーメーション事例」です。Watson Build Challenge の欧州チャンピオンにして世界チャンピオンを勝ち取ったイタリアの blueit 社です。blueit 社は Watson Build Challenge への参加をきっかけにトランスフォーメーション(変革) を目指しました。”Precision Farming as a Service” (ドローンが撮影した畑の写真から病害虫の状況を Watson が特定し、必要な区画に適切な対策をガイドする AI) を開発し、栄冠を勝ち取りました。今後はワイン用のぶどうに固有の病気を予防 (Preventive Maintenance) する AI を開発するそうです。革新(Innovation) はプロジェクトではなくプロセス(終わりの無い継続する活動)であるという言葉が心に残りました。

スペシャルゲスト Earvin “Magic” Johnson 氏の講演

次は基調講演のスペシャルゲスト Earvin “Magic” Johnson 氏の講演です。NBA のレジェンドにして現在は実業家。15歳の時に Triple Double (得点、リバウンド、アシスト、スティール、ブロックの内の 3つを 1試合の中で 2桁回数) を達成し “Magic” の称号を得ました。「僕は十分大きいからステージから降りて話すよ」と言って、聴衆の間を巡りながらの講演です。

“Magic” Johnson 氏のモットーは Winning Attitude勝ちへのこだわり、勝てるように変わる)。自身の経験談として、「激しく早く動き回るゲームから球をじっくり持って攻めるバスケットボールに変わった時期があり、自分自身とチームがそれに合わせて Adjust することで常勝チームを維持した」、「今の IBM と一緒だね!」という言葉は説得力があります。

“Magic” Johnson 氏は 7人兄弟姉妹の大家族だったため、父親は ゼネラルモータースの給料に加えゴミ回収の仕事を家計の足しにしていたそうです。厳冬のミシガン州で父親の手伝いをした時、こぼれたゴミをきちんと片付けなかった “Magic” Johnson 氏に父親が言った「半分しかしない人間は半人前の人間にしかなれない」という言葉が “Magic” Johnson 氏を Perfectionist (完璧主義者)にしたそうです。そして年2回、自分自身を「1人の男性」、「夫」、「父親」、「ビジネスマン」として SWOT 分析しているそうです。

ビジネスとして “Magic” Johnson 氏とスターバックス ハワード・シュルツ CEO との共同事業の事例を話してくれました。マイノリティ(アフリカやヒスパニック系住民)が多く住む都心の密集地にはスターバックスが全くありませんでした。”Magic” Johnson 氏はハワード・シュルツ氏と 50/50 で出店する説得に成功。唯一の条件は、並べるスウィーツと店内音楽をマイノリティ向けに変えることでした。Overdeliver(期待以上のことを提供) することがとても重要で、この Adjustment(調整 = スウィーツと音楽の変更)で 105店舗を展開しているそうです。

締めくくりは聴衆との質疑応答です。「リーダーシップとは」という問いに「部下や同僚を引き上げること」、「あの時こうしていればと思うことは」という問いには「過去を振り返って後悔することはない。常に前向きに新しいことに向かう」と明快に答えていました。その後は質問者と一緒に並び、ビッグスマイルのツーショット写真です。
6フィート 9インチ(206センチメートル!)の身体は大迫力で普通のアメリカ人男性が子供に見えます。ビジネスのことは分からなかったのでメンターを付けて一から学んだという謙虚で賢い人格が会場を満たしていました。

日本から参加されたパートナー様向け”Japan Forum

3日間に渡るセッションをまとめる形で日本から参加されたパートナー様向けに Japan Forum が開催されました。日本アイ・ビー・エム株式会社 ジョージ・カチャドリアン (取締役専務執行役員 チーフ・オペレーティング・オフィサー、ストラテジー・チャネルズ&オペレーションズ担当)から “We are OPEN to business.” (ビジネスを第一義とし、全ての可能性を追求すると筆者は理解) を Japan GBP (Global Business Partner)のスローガンとしているというお話しで開会しました。

Watson Build Challenge 日本チャンピオンの情報技術開発株式会社 ソリューション・コンサルタント部 工藤弘隆様と宮崎温子様が「コグニティブビジネスへの取り組み – Create New Generation Zoo by Smart Zoo」をお話しされました。前半は宮崎様が英語でのプレゼンを短縮版で披露され、聴衆を魅了しました。素晴らしいの一言です!後半は情報技術開発株式会社様の Watson への取り組みを工藤様がご説明くださいました。

今回 Japan Forum の目玉は、アメリカのパートナー様 Stan Wysocki (スタン・ワイソッキ), VP, Mark III Systems 社による “Transformation (変革) or Transit(遷移)” という講演でした。Mark III Systems 社はテキサス州の創立 20数年のインフラビジネスを得意としてきた会社でしたが、オープンソースを活用したソリューションカンパニーに、最近はアウトカム(お客様の目的を達成し結果を出す)カンパニーに進化してきたそうです。重要なのは Stay Relevant – お客様のビジネスに関わり続けること。IBM のイベントではありましたが、「IBM が変われと言うから変わるものではない」、「自社はこれまでお客様に販売、提供してきたモノに自信と責任がある」とぶれない考えを披露してくれました。よって、新しいことを始めることは過去を捨てるのでなく、その上に積み上げる(Additive = move up stack)という考え方で進んでいるそうです。

重要なのは “Stay Relevant”
お客様のビジネスに関わり続ける 
こと

事例として、昨年 11月に不動産登記の女性経営者からシステムパフォーマンス不具合を相談する電話があったそうです。Stan Wysocki 氏から不具合は全く問題なく解決できること、しかしそんなことができる IT 会社は近隣に何社もあることを説明。それより、その女性が経営する会社が直面する課題について話して欲しいと水を向けると、競合会社の脅威があることを話してくれたそうです。詳しく話を聴くと彼女から「これこそ正に私が話したかったこと」。経営課題に取り組みつつ、システムの課題も解決しました。完全な信用を取り付けていたため、価格交渉は一切無かったそうです。

このような Outcome Conversation (お客様の目的を達成し結果を出すことを話し合う) が最重要との指摘です。Talk to clients what needs to be done! (お客様とは成されるべきコトを話そう!) です。会社を進化させる中でオープンソースに取り組む際、新しい技術に貪欲で尽きない興味を持つエンジニアを採用してきたそうです。そして、エンジニアが「もっと試してみたい」と言う時は言うに任せ、Empowerment しているそうです。実際に会社を進化させてきた経営者のお話しに聴衆全員が聞き入りました。

来年 2019年は 2月12日から15日サンフランシスコで開催されます。
今直ぐ手帳に予定を書き込み、是非ご一緒に参りましょう。

この記事に関する、ご質問やご意見がございましたらコチラにてご連絡ください。

その他の記事

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