2018年01月

30

【特集ブログ】IBM Watsonが支援する「働き方改革」第3弾:資料 & 総集編 ~時間と場所を超えて個人とチームの力を最大化~

カモシーこと、日本IBM 鴨志田です。
IBM Watson が支援する「働き方改革」の第3弾にあたる今回を最終回として、お届けします。最終回は、資料の準備にかかる時間を減らすことをテーマをメインに進めていきます。
これまでの以下の記事もぜひご覧ください。

【特集ブログ】IBM Watsonが支援する「働き方改革」
       第1弾:会議編 / 第2弾:メール編  


※出典:*1,2 ガートナージャパン 2016年 *3 IBM調べ資料検索や準備にかかる割合

IBM では、毎年 営業メンバーからある特定の1日をサンプリングして、その日の活動時間を項目ごとにどれだけかかっているか調査しています。その結果、半分近くの 43% を資料の検索や準備に費やしていることが判明いたしました。次のような項目から成り立っています。

営業プラン作成/訪問準備/資料検索/提案書作成/条件調整/提案レビュー/質問回答準備/営業管理報告/営業プラン更新/管理業務
資料といえば、Box?

資料といえば、ファイル、ファイルと言えばクラウド型コンテンツ管理プラットフォームである Box が有名です。しかしここでは、短絡的に「Box を使いましょう」と言いたいのではなく、Box というプラットフォームやファイル、データをいかに効率良く、効果的に活用するかが「働き方改革」を支援することにつながっていくかについて考えていきたいと思います。

Box とは

あらためて Box とは何かについてご紹介してまいります。大きく特長は 3点 です。

1. 容量無制限
2. プレビュー・セキュア
3. 連携

1. 容量無制限であること

ファイルサーバーですと、毎年のようにストレージ容量を追加していかないといけない、現場の各部門にヒアリングして必要容量を計算して予算を確保および、そのバックアップも考えなければいけない、そのようにコスト試算が面倒ですし毎年どんどんコストが膨らんでいく傾向にあります。しかし、Box であれば、一定の使用料を確保しておくことで毎年の予算が定常化され、運用していくことができます。また、最近は動画や音声ファイルも電子化されていってますので、容量無制限は非常に魅力的です。

2. セキュリティ

クラウドというと「セキュリティは大丈夫か?」という議論が必ず発生いたします。Box は、データの暗号化、通信の暗号化はもちろんのこと、その特長として細かいアクセス権管理があります。例えば、プレビューアーという役割では、ファイルのプレビューはできるけれど、ダウンロードはできないという権限です。「外部のお客様とファイルの共有をして見てもらいたいけど、ファイルをそのまま渡してしまうのは好ましくない」ような場合に使えます。反対にアップローダーという役割では、ファイルのアップロードはできるが、その他のファイルを見ることはできないという役割です。例えば関連業者様や企画会社にファイルをアップロードしてもらう場合や学校のゼミなどで生徒が課題を提出する場合にアップローダー権限を付与し、先生方は編集者として提出されたものを添削、コメントしていくことができます。

3. 連携

Box は様々なソリューションとの連携も大きな特長の1つです。例えば前回ご紹介したような電子メールとの連携があげられます。Box は通常、ブラウザやスマートデバイス上の Box アプリから利用しますが、BoxDrive のモジュールを設定することで、ファイル・エクスプローラー(Mac でいう Finder)や各種オフィスなどのアプリケーションから直接 Box にアクセスしてファイルの読み書き・更新ができます。一方で、そのように直接 Box を利用していくのではなく、デジタル複合機と連携し、契約書などの紙媒体をスキャンする際に複合機の操作パネルから直接 Box のフォルダを選択し、直接 Box に格納して電子的に管理していくことでデジタル複合機を入り口としてアクセスしていくことも可能です。また、IBM Notes/DominoIBM Connections Cloud およびサイボウズ kintone などのアプリケーションのファイル格納先として Box を利用していくこともできるようになっています。利用者は Box の存在や Box との連携を意識することなく、利用しているアプリケーションから自然と Box にセキュアに情報を格納していくことができるのです。

IBM Watson との連携例

では、次に IBM Watson と組み合わせるとどのようなことができるかご紹介していきましょう。Box でのコンテンツ管理と IBM Watson の各種サービスを組み合わせることで次のようなことが実現できます。

① AI による高精度な検索
② 画像の自動分類による属性(タグ)追加
③ 音声ファイルのテキスト化
④ Box のコンテンツ操作を対話(チャットボット)で補助

以下、Youtube の動画ファイルがありますので、是非ご参照ください。
▼AI 時代の box + IBM Waston ナレッジ活用ソリューション (Youtube より)

AI による高度な検索

ご紹介の YouTube でご覧いただきましたように、1 つ目の例にある「AI による高度な検索」だけでも大きく「働き方改革」や今回のテーマである「資料の準備にかかる時間を減らす」ことに寄与することがわかると思います。Box のみならず、IBM Notes など様々なアプリケーションでそれぞれ検索機能は搭載されていますが、必要な情報がなかなか見つからないということも多いと思います。そこへ IBM Watson が加わることによって、役立つ資料かどうかの判別ができたり、自らその評価のフィードバックをすることができたりしますので、有益な情報の見える化またその資料探しの短時間化に繋がります。

画面左が IBM Watson によって学習した後の検索結果、右は IBM Watson とは連携しない時の結果です。結果が異なることがわかります。

IBM Watson およびサイボウズ kintone との連携例

次に、サイボウズ kintone と連携していくとどのようなことができるでしょうか?例えば、IBM Watson と サイボウズ kintone そして Box の組み合わせでは、農業改革につながっていったという事例があります。

右のような画像があります。よく見ると白い斑点がありますが、このような写真を含めて、kintone 上のアプリで報告書などのレポートをまとめたり、統計管理をしたりしていきます。
写真は kintone から自動的に Box に格納され、さらにそれが IBM Watson の Visual Recognition というサービスと連携することで、この白い斑点の問題の判定と対応策の提示を行ってくれるのです。
数十年農家に専従している熟練者でなくても、迅速に問題解決を図ることができます。高齢化、後継者対策や専門的な判断の補助など農業に必要な知識の習得期間の短縮に寄与しています。

Box Capture でスマートに働き方改革

先の例のような画像・写真と Box および IBM Watson との連携をよりシンプルに行っていくことができます。それを支援するのが Box Capture (キャプチャー)です。AppStore からアプリをスマートデバイスに無料でダウンロードして利用することができます。

Box Capture は、カメラや録音アプリです。
Box Capture を利用すると、iPhone などのアプリに保存することなく、直接 Box の指定したフォルダに写真や音声をアップすることができます。Box に入った後は、先の Visual Recognition で画像判別をしたり、タグ付けをしたりしていくことができます。

また、IBM Watson と連携をしなくても、リアルタイムに現場での写真を本部の方や遠隔地の方と共有することができますので、例えば建設現場や保守メンテナンスの現場写真を本部の方がレポートにまとめたり、技術の方が見て適切なアドバイスを即座にもしくは、並行作業で行ったりすることができます。個人だけでなく、チームでの働き方改革に寄与できるのではないでしょうか。

「働き方改革」成功のポイント

さて、これまで 3回の連載に渡って IBM Watson やコラボレーションツールおよびそれらの組み合わせによって「働き方改革」の事例や解決策の例をご案内してまいりましたが、最後に働き方改革成功のポイントを IBM での経験を元にご案内したいと思います。結論から申しますと、成功のポイントはツールの有効活用だけではありません。

以下の図にあるように領域 0 から 4 までの 5つの点を考え、対応する必要があります。

IT ツールやそれを利用する環境、スマートデバイスのような端末や外出先や自宅からアクセス、共有できるインフラ環境は、領域 1.2. ハード面としています。ここでは、領域3.4. のソフト面および領域 0 の組織風土・意識を整備する方法や IBM での例をご紹介いたします。

領域0. 組織風土・意識

「組織風土・意識」を整備するのはもしかすると最も難しいかもしれません。IBM Watsonを活用するにしても働き方改革を実践するにしても、情報・データ・ファイルなどこれらがナレッジとして活用されていく情報の元ネタが必要になります。まずこれらの情報がないと話になりません。「俺のものは俺のもの」としてみなさま各人の頭の中やPCの中にしまわれていては困ってしまいます。組織内に共有されてそれが活用の土台にあがっていくかが重要です。

IBMでの例としては、トップ自らが情報の重要性を訴えています。具体的には次のようなことを従業員に訴求しています。

「知識をどれだけシェアしているかが社員の勝ちを決める」

こんなふうに訴えかけられたら「俺のものは俺のもの」なんて言ってられませんよね。
トップ自らが情報の重要性を訴える、トップ自らが情報発信をするなどの行動が必要かつわかりやすい訴求方法ではないかと思います。

領域3.4.  ソフト面

「知識をどれだけシェアしているかが社員の価値を決める」と言われてもお客様情報や個人情報など何でも共有できるものでもありません。その辺りのルール整備も必要です。従業員が迷った時の指針となるものがあると安心して行動ができると思います。これも IBM を例に取りますが、IBM では BCG (ビジネス・コンダクト・ガイドライン=行動基準)を定めています。

内容は非常にシンプルでごくアタリマエのことが記述されていますが、IBM 従業員としての基本的な行動基準ですので、行動の拠り所として利用することができ、このようなものが有るというだけでも安心感があります。IBM 従業員は毎年この内容を学習して(クイズなどにも答えます(苦笑))同意し、サインをして働いています。こちらの BCG は外向けにも公開されていますので、参考にしてもらえればと思います。

『IBMビジネス・コンダクト・ガイドライン』(IBM企業行動基準)

最後に・・・

以上、IBM Watson が支援する「働き方改革」と題して身近な「働き方改革」をどのように実現できるかを例を交えて連載してまいりましたが何かヒントになるものはありましたでしょうか? 身近な「働き方改革」で最も重要なことは行動を起こすことかもしれません。みなさまのまわりでできることを何か少しでも実践してみませんか?

 

その他の記事

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