2018年03月

30

いまさら聞けない25GbpsEther

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

ハイパーコンバージドや、次世代移動通信「5G」等、今後さらなるネットワークの高速化の需要が高まることが予想されます。
現在10Gbpsを採用されるケースが多いかと思いますが、2018年以降普及しそうなNVMeOF等を踏まえると10GbpsEtherですらボトルネックになることが想定されます。
今回は、10Gbpsの次の世代、今から覚えておいて損はない25GbpsEtherの紹介をしたいと思います。

RJ45の終焉

以前、10GbpsEtherは何を選べばよいの?で10GBase-Tについて触れました。
有線LANといえばRJ45アダプタというのは一般の人にも広くなじみがあるのではないでしょうか? 気になるのは後継にあたる25/40GBase-Tだとおもいます。
25/50GBase-Tでは?と思われますが、技術的に実現できないという事で、25/40GBase-Tで規格化されました。
25/40GBase-Tについては、2016年にIEEE 802.3bqで標準化されましたが実際の製品は2018年3月現在、残念ながら存在しません。
技術的な課題から製品の登場は2020年以降と言われています。
また、スイッチとなるとさらにそのあとにリリースとなりますので、現時点では普及するのが全く見えない規格といえます。
今現在、10Gbpsを超える規格については、RJ45は選択できません。

40/100Gbpsを振り返る

ご存じの方は、40/100GbpsEtherが先にあるのに、なぜ今になって遅い25/50Gbpsなのだ?違和感を覚えるかもしれません。
そこで、40/100GbpsEtherを振り返ってみましょう。
40/100GbpsEtherは10GbpsEtherの技術をなるべく流用しようとのコンセプトの元作られています。
簡単に言うと、40GbpsEtherは内部的には10GbpsEtherが4つ束ねられています。
100GbpsEtherは大きく分けて2つの規格があるのですが、一つは10GbpsEtherを10本束ねる方式 もう一つは25Gbpsを4つ束ねる方式を標準化しました。

40/100GbpsEtherの問題点とは?

さて、当初40/100GbpsEtherは規格化も製品化も比較的スムーズに進んだのですが、課題の低コスト化が解決できずに普及がなかなか進んでいません。
問題は何か?これらの規格は見た目のケーブルは1本ですが、内部的には4ないし10のケーブルが束ねられています。
実際、ネットワークスイッチやNICカード内の配線が過去の4倍もしくは10倍必要で、特にネットワークスイッチは内部配線が大変なことになります。
当然、10Gbpsを10本束ねるタイプの100GbpsEtherについてはかなりコストが高止まりすることになりました。

25/50GbpsEtherとは?

そんな問題点を解決する策は1つしかありません。
技術的にはハードルが高いですが、1本あたりの転送速度を25Gbpsする必要があります。
100Gbpsであれば10Gbps×10ではなく、25Gbps×4の100Gbps方式をとるということです。
25GbpsEtherの期待値が高いことがこれでお分かりになると思います。

規格一覧表

文章で説明してきましたが、かなりややこしいと思いますので、一覧にまとめます。

イーサネット クロックレート レーン数 データレート
1GbE 1.25GHz 1 1Gbps
10GbE 10.31GHz 1 10Gbps
25GbE 25.78GHz 1 25Gbps
40GbE 10.31GHz 4 40Gbps
50GbE 25.78GHz 2 50Gbps
100GbE 10.31GHz 10 100Gbps
100GbE 25.78GHz 4 100Gbps

ケーブル種類

ケーブルについては、メタル、光と豊富にありますので、戸惑いますが、自由に組み合わせることができます。
現在主流のSFP/QSFP系のみ紹介します。
選び方は、低コストは短距離、高コストは長距離となります。

1.DAC(DirectAttachCopper)
・最も安い
・最大長~5m
Mellanox MCP2M00-A003 Passive Copper Cable Ethernet up to 25Gb/s SFP28 3m 28AWG
画像はmellanoxから、直販価格は、25Gbps SFP28 3m $59

2.AOC(ActiveOpticalCable)
・DACに次いで安い
・最大長~100m

Mellanox MFA2P10-A020 Ethernet active optical cable 25GbE SFP28 20m

画像はmellanoxから、直販価格は、25Gbps SFP28 20m $220

3.Optical Transceiver
・高コスト(Transceiver+Cableが必要)
・最大長 SR~100m LR~10km

画像はmellanoxから、直販価格は一つ当たり、25Gbps SFP28 LC-LC SR $155


画像はmellanoxから、LRが25Gbpsはまだ出てなかったので参考で100Gbpsになります。
直販価格は、一つ当たり100Gbps QSFP28 LC-LC LR4 $4315(!)

まとめ

10GbpsEtherの時もそうでしたが、10Gbpsを超える速度の世界は種類が非常に多く悩ましいと思います。
現状を踏まえると
・RJ-45タイプは製品が出ていないので選択肢から外れる。
・25Gbpsより上の速度はマルチレーンになり、同じ100Gbpsでも10Gbps×10と25Gbps×4では互換性がない。
・RDMA/RoCE,NVMeOFといった技術を使うことにより、規格上の帯域だけでなく実効転送速度も期待できる。

となります。
現状RJ45のケーブルを敷設しているユーザーはケーブルの敷設のやり直しが必要になります。
単純にネットワークの高速化だけではコストが高すぎるとなるケースもあるかもしません。
25Gbpsですと帯域的にもファイバチャネルの置き換えも可能になりますので、SANネットワークの置き換えも併せてご提案というのが良いシナリオになるかと思います。
IBM Storage製品ではV7000/V50x0シリーズが25GbpsEtherに対応しておりますので、ご提案検討に含めていただけると幸いです。

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

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

技術支援本部

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