”参加してみた” GTC Japan 2017

2017年12月

”参加してみた”　GTC Japan 2017

ブログ

こんにちは、てくさぽBLOG メンバーの佐藤です。
12/12(火)、12/13(水)にヒルトンお台場で開催されたNVIDIA主催のカンファレンス「GTC Japan 2017」に参加してきました。
本ブログは12/13(水)の内容になります。

１．GTC Japan 2017とは？

GPUの雄NVIDIA主催のイベントとなります。
近年AI,ディープラーニングの市場規模が拡大していることもあり、話題のイベントとなります。

なお、昨年のレポートも参照ください。
”参加してみた”　GTC Japan 2016

２．基調講演

基調講演の始まる30分程前に到着したのですが長蛇の列でした。
基調講演会場に何とか入れましたが、入れなかった方もいたようです。
おなじみの革ジャンをまとったNVIDIAのCEOジェンスン・ファン氏が登壇し今年もひとりで説明。
当初の予定を超過して1時間半強、話しっぱなしでした。

内容をまとめると、大きく以下の3点をアピールしていました。

・性能の飛躍がもたらす恩恵
・シミュレーターonシミュレーター
・自動運転

レクサスはCG?と思いきや、リアルタイムレンダリングで、中央のロボットらしきものはVRで参加している人になります。
内装も、エンジンも部品単位でデータ化されています。
未来のデザインlabという事でしたが、ここでいう”デザイン”というのは単純に見た目だけでなく
パーツの配置や組み付けの考慮という広い意味でのデザインとなります。

続いて、開発環境についての紹介です。
NVIDIAとしてはオンプレかクラウドかという選択を迫るわけではなく、クラウド環境でもオンプレ環境でも同じフレームワークで自由に使い分け、移行が出来るようにしています。

こちらの女性はディープラーニングによりAIが作り出した女性の写真です。
ほかにも男性や老人が次々と映し出されていました。
これらは3Dのモデリングで描画しているわけではなくディープラーニングによって作り出しています。
注目は左の車窓で、こちらも自動生成された画像になります。
このデモは学習結果から学習元のサンプルデータを作り出すことができるということで、たとえば自動運転の場合は実際に車を走らせなくてもマシンパワーさえあれば仮想空間に昼も夜も、何十、何千万台でも自動運転カーを走らすことができます。
結果、自動運転のラーニングを飛躍的に加速させることができます。

サプライズということで日本では未発表だったVOLTA版Titan Vが発表。
こちらは開発用のカードで複数枚未サポートですが、安価にGPUを使うことができます。
価格は2999USD。

実績としては画像認識系のソリューションで今まで4ラックのシステムをV100によりなんと1ノードになった！とのこと。
CEOいわく、GPUは買えば買うほどお得になるとの事。

次はバーチャルゴルフコースのバーチャルロボットのデモ
実際のロボットもゴルフコースも用意しなくても、パターゴルフのディープラーニングがバーチャルで実施できます。
学習開始はよちよちな動きで、ボールにも当たらない、途中からボールにあたるようになり、最後は100発100中になりました。
現実的な問題としてはこのシミュレーターの中だけですべてのテストを終わらせるのは厳しいはずですが、ロボットアームやロボットは学習過程において自分自身を破壊してしまったり、意図せず人間を傷つける事があるため、少なくとも人間ではありえないエラーを出さない程度に仮想で事前学習してくれるのは現時点でも有用と思われます。

基調講演は最後にこれがAI革命だ！と締めくくりました。

実機を用意しなくてもディープラーニングができるというのはかなり革新的でこうなるとコストや時間といった物理的な制約から解放されて膨大な量のテストができます。
しかも学習用のサンプルデータも作り出すことができる。
これが進むと、十分にテストができるため”初期ロットは不具合が多い”といった常識は変わっていきますし今まで量が膨大になりすぎるので、無意識に切り取られていたテストから新しい発見、発明が出るかもしれません。

３．セッション

セッションはたくさんあり、どこも立ち見が出るほど大盛況でした。
1つだけ紹介したいと思います。

IBMからは、最近発表した「Power System AC922」に関する内容と、IBMが考えるプロセッサの将来についてです。
一般的に、GPUだけ高速なマシンはパフォーマンスを引き出すのにチューニングが難しい上級者向けとなります。
その点、AC922はCPUとGPUをNVLink2という高速なバスで接続することにより全体としてバランスの取れたマシンと言えると思います。
バスの比較ですが、一般的に使われているPCIe Gen3 x16では帯域は双方向32GB/sで、仮にPCIe Gen4になっても64GB/sにとどまります。
NVLink2ではこれが150GB/sとなり、高帯域幅を利用することが可能となります。
以下は4GPU構成の例です。

次にIBMが考える将来のAIアクセラレーターについてです。
IBMとしてはGPUは単体で将来的には今の10倍、それを並列に並べスケールすることにより、さらに10倍程度の性能が上限とみています。
次世代については、研究中の脳を模したSyNAPSEチップを用いることにより100倍以上の性能、次々世代は一部提供が開始されているIBM Q…量子コンピュータを想定しているようです。

注目が集まるIBM Qについて、先日50Qubitのプロトタイプが発表されましたが、50Qubitは量子コンピュータの一つの壁と言われています。
サービス提供がされればブレークスルーになるかもしれません。
将来が楽しみな発表でした。

４．おわりに

最後に、今年はトヨタが協業を発表したこともあって、ブースは車関係の内容が非常に多く日本における自動車業界の市場規模の大きさを体感しましたし、主催者の想定をはるかに超えた参加者だったようでした。

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

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

技術支援本部

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月18日

厳しくなる個人情報保護法への対応は大丈夫？〜クラウドシフトで、データセキュリティ対策の必要性が高まる理由とは〜

多くの企業はこれまでも様々なセキュリティ製品を導入し、対策に注力してきました。それにもかかわらず、セキュリティ事故が増え続けています。 (さらに…)

ホワイトペーパー

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を導入してみた：ツール編１．はじめに前回、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を作成（１）作業用ディレクトリとして以下２つのディレクトリを作成 /home/user01/os45 　　　 ※OpenShift インストールプログラム置き場 /home/user01/os45/conf 　※yamlやjsonなどの設定ファイル置き場（２）Azure CLIインストール（３）jqパッケージインストール（４）cloudctlインストール（５）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. ファイルの準備（１）OCP4.5インストールファイルのダウンロード・ocコマンドをダウンロードしたのと同じページで”OpenShift v4.5 Linux Installer"を/home/user01/os45フォルダにダウンロードします。（２）Pull Secretファイル Red Hat OpenShift Cluster Manager サイトの「Pull Secret」ページから、インストールプルシークレットを/home/user01/os45フォルダにダウンロードします。 2-3. パブリックDNSゾーン設定（１）リソースグループを作成まずリソースグループを作成します。今回は「ocp-cluster」という名前のリソースグループを作成しました。次の画面のタグは特に設定せずに進み、確認画面で「作成」ボタンをクリックします。（２）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でリソースが構築されるので、そのための専用アカウントと理解しました。以下を実施します。（１）Azureへのログイン（az login）（２）アクティブなアカウントの詳細を表示して「tenantId」「id」を確認（３）アカウントのサービスプリンシパルを作成し「appId」「password」を確認（４）サービスプリンシパルに追加パーミッションを付与（４－１）User Access Administrator ロールを割り当て（４－２）Azure Active Directory Graph パーミッションを割り当て（５）パーミッション要求を承認 3．OpenShift 導入 3-1. SSH秘密鍵の作成クラスタの作成後に、ノードにアクセスするためにSSH秘密鍵を作成します。（１）作業用Linuxマシン上でgenコマンドを実行しSSHキーを作成（２）ssh-agent プロセスをバックグラウンドタスクとして開始（３）SSH プライベートキーを ssh-agent に追加 3-2. インストールファイルの作成（１）install-config.yaml ファイル生成（２）ARM テンプレートの一般的な変数のエクスポート（３）クラスターの Kubernetes マニフェストを生成（４）コントロールプレーン、ワーカーノードを定義する Kubernetes マニフェストファイルを削除（５）Kubernetes マニフェストファイルを変更（６）変数のエクスポート（７）Ignition 設定ファイルを取得（８）ファイルの確認 3-3. Azure リソースグループおよびアイデンティティーの作成 OCPクラスタのインストールに必要なリソースグループとアイデンティティーを作成します。（１）リソースグループを作成（２）リソースグループの Azure アイデンティティーを作成（３）Contributor ロールを Azure アイデンティティーに付与（３－１）ロール割当に必要な変数をエクスポート（３－２）Contributor ロールをアイデンティティーに割り当て 3-4. RHCOS クラスターイメージおよびブートストラップ Ignition 設定ファイルのアップロード（１）Azureストレージアカウントの作成（２）ストレージアカウントキーを環境変数としてエクスポート（３）VHD の URL を環境変数にエクスポート（４）選択した VHD を blob にコピー（５）blob ストレージコンテナーを作成し、生成されたbootstrap.ignファイルをアップロード 3-5. DNSゾーンの作成（１）プライベートDNSゾーンを作成 3-6. Azure での VNet の作成（１）デプロイメントを作成（２）VNet テンプレートをプライベート DNS ゾーンにリンク 3-7. RHCOS クラスターイメージのデプロイ（１）RHCOS VHD blob URL を変数としてエクスポート（２）クラスターイメージのデプロイ 3-8.ネットワークおよび負荷分散コンポーネントの作成（１）ネットワークオブジェクトおよびロードバランサーのデプロイ（２）変数のエクスポートとクラスターを既存のパブリックゾーンに追加以上で、OCPノードを作成する手前まで完了しました。 3-9.ノードの作成（１）ブートストラップマシンの作成（２）コントロールプレーンの作成（３）ワーカーマシンの作成（４）クラスターへのログイン（５）マシンの証明書署名要求の承認（６）ブートストラップリソースを削除（７）クラスターのインストールを完了する（８）ログインクラスタにログインできたのでインストールは成功です！長かったですね、最初のディレクトリ作成から数えて計50工程がようやく終わりました。まとめいかがでしたでしょうか。やはりUPIは作業工程が多くて大変でした。記載のとおり、Azureでの確認や設定で何箇所かつまづきましたが、コマンドを実行していくところはマニュアル記載のコマンドでエラーなく進めることができました。もっと簡単にOCP環境を構築したいのであればIPI(Installer Provisioned Infrastructure)方式もありますが、構成をカスタマイズしたくてUPI方式を選択することもあるかと思いますので、その際にこの記事が参考になればと思います。ここまでお読みいただきありがとうございました。次回は構築したこのOpenShift上でのWebSphereをインストールしてみた内容をお伝えいたします。この記事に関する、ご質問は下記までご連絡ください。エヌアイシー・パートナーズ株式会社技術支援本部 E-Mail：nicp_support@NIandC.co.jp

ブログ