2020年09月

02

【てくさぽBLOG】IBM Cloud Pak for Applicationsを導入してみた(OpenShift導入編 - 手順詳細)

IBM Cloud Pak for Applicationsの新規販売は終了いたしました。
今後のアプリケーションランタイムソリューションは、2021年1月15日に発表されたWebSphere Hybrid Editionとなります。


 

1.本記事について

本記事は「IBM Cloud Pak for Applicationsを導入してみた(OpenShift導入編)」の コマンドの詳細を掲載したものです。
本編をご覧頂きながら、詳しいコマンドや実行結果を本記事でご確認ください。

 

2. 事前準備

2-1. 作業用Linux環境準備

(1)Cent OSインストールとディレクトリ作成

今回はCent OS 7をインストールし、ルート配下に以下の3つのディレクトリを作成します。

  • /work    ※作業用スペース
  • /os42    ※OpenShift インストールプログラム置き場
  • /os42/conf   ※yamlやjsonなどの設定ファイル置き場

 

(2)AWS CLIインストール

前提ソフトウェアを確認し、AWS CLI をインストール・設定します。

<前提バージョン(2.7または3.4以上)の python が導入されていることを確認します。>


# python –version
Python 3.6.8


 

<aws cliをインストールし、バージョンを確認します。>
rootユーザーで実行する場合の手順を行いました。


# curl “https://s3.amazonaws.com/aws-cli/awscli-bundle.zip” -o “awscli-bundle.zip”
# unzip awscli-bundle.zip
# export PATH=~/.local/bin:$PATH
# source ~/.bash_profile
# pip3 install awscli –upgrade –users
# aws –version
aws-cli/1.18.31 Python/3.6.8 Linux/4.18.0-147.5.1.el8_1.x86_64 botocore/1.15.31


 

<aws cli設定>

AWSアカウント情報・利用するリージョンを元にAWS CLIを設定します。


# aws configure
AWS Access Key ID:         ※利用するAWSアカウントのAccess Keyを入力
AWS Secret Access Key:  ※利用するAWSアカウントのSecret Access Keyを入力
Default region name [None]: ap-northeast-1
Default output format [None]: json


 

(3)jqパッケージのインストール

<CentOS 7 の標準リポジトリには jq が含まれていないので、EPELリポジトリを yum コマンドでインストールし、その後 jqパッケージをインストールします。>


# yum -y install epel-release
# yum -y install jq


 

2-2. インターネットドメインの取得とRoute53への登録

<インターネット上から OpenShift クラスターにアクセスするためにインターネットドメインを利用できるようにします。>
今回は AWS Route53で独自ドメインを取得・登録しました。

インターネットドメイン名:example.com(仮称)

 

2-3. インストールファイルの取得

インストールに利用するファイルを用意します。

<作業用Linuxマシンにて、Red Hat OpenShift Cluster Manager サイトの「Infrastructure Provider」ページから「AWS」-「User-Provisioned Infrastructure」を選択し、(1)OpenShift installer と(2)Pull secret をダウンロードし “oc42ディレクトリ” に配置します。>

 

以下、配置後の確認結果です。


# ll
drwxr-xr-x. 2 root root 4096 3月 18 09:39 conf
-rw-r–r–. 1 root root 80468756 3月 16 10:18 openshift-install-linux-4.2.23.tar.gz
-rw-r–r–. 1 root root 2763 3月 4 13:15 pull-secret.txt


 

3. OpenShift 導入手順

3-1.AWS 環境構築

(1)SSH プライベートキーの生成およびエージェントへの追加

<作業用 Linuxマシン上で以下コマンドを実行し SSHキーを作成します。>


# ssh-keygen -t rsa -b 4096 -N ” -f ~/.ssh/id_rsa
Generating public/private rsa key pair.
Created directory ‘/root/.ssh’.
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:jyTeAdzo1xi7bZh7+EK+r6j7y5rVDT5Jus8U9JDX8vs root@rpa-20
The key’s randomart image is:
+—[RSA 4096]—-+
| |
| . o . . |
| + * o . |
| . o O o |
| o S o . |
| . X.& . |
| +o%.= . |
| + =++. . |
| ==*o*Bo E |
+—-[SHA256]—–+


 

<ssh-agent プロセスをバックグラウンドタスクとして開始します。>


# eval “$(ssh-agent -s)”
Agent pid 13552


 

<SSH プライベートキー(id_rsaファイル)を ssh-agent に追加します。>


# ssh-add ~/.ssh/id_rsa
Identity added: /root/.ssh/id_rsa (/root/.ssh/id_rsa)


 

(2)AWS のインストール設定ファイルの作成

<install-config.yaml ファイルを取得します。>
以下を実行すると install-config.yaml ファイルが作成されます。


# ./openshift-install create install-config –dir=/os42

プロンプト上で選択または入力

  • SSHキー:/root/.ssh/id_rsa ※”(1)SSH プライベートキーの生成およびエージェントへの追加”で作成したSSHキー
  • ターゲットプラットフォーム:aws
  • AWSアクセスキーID:   ※利用するAWSアカウントのAccess Keyを入力
  • AWSシークレットキー:  ※利用するAWSアカウントのSecret Keyを入力
  • AWSリージョン:ap-northeast-1 (tokyo)
  • Route53のベースドメイン名:example.com ※AWS Route53に登録したドメイン名
  • クラスター名:nicptestcluster  ※任意の名前
  • Pull Secret:※”/os42/pull-secret.txt”の内容をコピー&ペースト

※特に完了のメッセージは表示されませんのでご注意ください。


 

<install-config.yaml ファイルを編集し、コンピュートレプリカ の数を 0 にします。>


#vi install-config.yaml

compute:
– hyperthreading: Enabled
name: worker
platform: {}
replicas: 3 ← ここを0に変更


 

<install-config.yaml ファイルはインストール実行時に消去されてしまうので、別名でバックアップしておきます。>


#cp install-config.yaml install-config.yaml.org


 

(3)インフラストラクチャー名の抽出

*インストールプログラムが生成する Ignition 設定ファイルには、24時間が経過すると期限切れになる証明書が含まれます。

<クラスターの Kubernetes マニフェストを生成します。>


#./openshift-install create manifests –dir=/os42


 

<openshiftフォルダが作成されるのでフォルダ内を確認します。>


# ll openshift
-rw-r—–. 1 root root 219 3月 18 09:49 99_cloud-creds-secret.yaml
-rw-r—–. 1 root root 181 3月 18 09:49 99_kubeadmin-password-secret.yaml
-rw-r—–. 1 root root 1530 3月 18 09:49 99_openshift-cluster-api_master-machines-0.yaml
-rw-r—–. 1 root root 1530 3月 18 09:49 99_openshift-cluster-api_master-machines-1.yaml
-rw-r—–. 1 root root 1530 3月 18 09:49 99_openshift-cluster-api_master-machines-2.yaml
-rw-r—–. 1 root root 2713 3月 18 09:49 99_openshift-cluster-api_master-user-data-secret.yaml
-rw-r—–. 1 root root 2027 3月 18 09:49 99_openshift-cluster-api_worker-machineset-0.yaml
-rw-r—–. 1 root root 2027 3月 18 09:49 99_openshift-cluster-api_worker-machineset-1.yaml
-rw-r—–. 1 root root 2027 3月 18 09:49 99_openshift-cluster-api_worker-machineset-2.yaml
-rw-r—–. 1 root root 2713 3月 18 09:49 99_openshift-cluster-api_worker-user-data-secret.yaml
-rw-r—–. 1 root root 1207 3月 18 09:49 99_openshift-machineconfig_master.yaml
-rw-r—–. 1 root root 1207 3月 18 09:49 99_openshift-machineconfig_worker.yaml
-rw-r—–. 1 root root 222 3月 18 09:49 99_role-cloud-creds-secret-reader.yaml


 

<クラスターがコントロールプレーンマシンを自動的に生成するのを防ぐために、コントロールプレーンマシンを定義する Kubernetes マニフェストファイルを削除します。>


#rm -f openshift/99_openshift-cluster-api_master-machines-*.yaml


 

<同様に、ワーカーマシンを定義する Kubernetes マニフェストファイルを削除します。>


#rm -f openshift/99_openshift-cluster-api_worker-machineset-*.yaml


 

</oc42/manifests/cluster-scheduler-02-config.yml を変更し、Pod がコントロールプレーンマシンにスケジュールされないようにします。>


# vi /oc42/manifests/cluster-scheduler-02-config.yml
“mastersSchedulable”パラメーターの値を False に設定、保存します。


 

<Ignition 設定ファイルを取得します。>


#./openshift-install create ignition-configs –dir=/os42


 

<コマンド実行後、作成されたファイル・ディレクトリを確認します。>


# ll
-rw-r–r–. 1 root root 706 3月 9 20:16 README.md
drwxr-x—. 2 root root 50 3月 18 09:52 auth  ←あることを確認
-rw-r—–. 1 root root 291635 3月 18 09:53 bootstrap.ign ←あることを確認
drwxr-xr-x. 2 root root 4096 3月 18 09:39 conf
-rw-r—–. 1 root root 4045 3月 18 09:49 install-config.yaml.org
-rw-r—–. 1 root root 1837 3月 18 09:52 master.ign  ←あることを確認
-rw-r—–. 1 root root 267 3月 18 09:53 metadata.json ←あることを確認
-rwxr-xr-x. 1 root root 323536416 3月 9 20:16 openshift-install
-rw-r–r–. 1 root root 80468756 3月 16 10:18 openshift-install-linux-4.2.23.tar.gz
-rw-r–r–. 1 root root 2763 3月 4 13:15 pull-secret.txt
-rw-r—–. 1 root root 1837 3月 18 09:52 worker.ign ←あることを確認

# ll auth/
-rw-r—–. 1 root root 23 3月 18 09:52 kubeadmin-password ←あることを確認
-rw-r—–. 1 root root 8972 3月 18 09:52 kubeconfig ←あることを確認


 

<インフラストラクチャー名を抽出します。>
Ignition 設定ファイルメタデータからインフラストラクチャー名を抽出・表示します。ここで事前に準備したjqコマンドが必要になるのですね。


# jq -r .infraID /os42/metadata.json
nicptestcluster-w8r8h ←インフラストラクチャー名が出力されることを確認


 

(4)AWS での VPC の作成

</os42/confディレクトリに以下のファイルを作成します。>
なお、これ以降の手順の中で作成した yamlファイル、jsonファイルともファイル名は任意です。

CloudFormation Template:”cf_newvpc.yaml”ファイル
CloudFormation Templateのパラメーター:”cf_newvpc.json”ファイル

*cf_newvpc.yaml、cf_newvpc.jsonファイルの中身はRed Hatマニュアルページの”1.5.7. AWS での VPC の作成”に書かれている内容をコピー・アンド・ペーストします。今回はマニュアル記載の値のままで作成しました。

ParameterKey ParameterValue 備考
VpcCidr 10.0.0.0/16 VPC の CIDR ブロック。
AvailabilityZoneCount 1 VPC をデプロイするAZの数
SubnetBits 12 各AZ内の各サブネットのサイズ

 

<VPC 作成の CloudFormation 展開コマンドを実行します。>
–stack-name の後のスタック名(以下のコマンドでは createvpc)は任意の名前です。
*ここで本検証で初めて CloudFormation を実行しました。

 

(5)AWS でのネットワークおよび負荷分散コンポーネントの作成

<VPC作成時と同様に、マニュアルの該当ページの内容を含んだファイルをそれぞれ”/os42/conf”に配置します。>

CloudFormation Template:”cf_network.yaml”ファイル
CloudFormation Templateのパラメーター:”cf_network.json”ファイル

 

<cf_network.jsonファイルを編集します。>

ここがポイントです。
以下の cf_network.jsonファイル内の7つの ParameterKey に指定する ParameterValue を、これまで実行したコマンドや情報からの値に更新します。

ParameterKey ParameterValue 備考
ClusterName nicptestcluster install-config.yaml ファイルを生成した時に入力したクラスター名
InfrastructureName nicptestcluster-w8r8h Ignition 設定ファイルから抽出したインフラストラクチャー名
HostedZoneId ZMxxxxxxxxxxx Route53 パブリックゾーン ID(事前にAWSコンソールで確認します)
HostedZoneName example.com nstall-config.yaml ファイルを生成した時に使用した Route53 ベースドメイン名
PublicSubnets subnet-0306b9ca39a3a00bd VPC の CloudFormation テンプレートの出力より
PrivateSubnets subnet-0407cf93524961fb4 VPC の CloudFormation テンプレートの出力より
VpcId vpc-00a56e4c475a50da8 VPC の CloudFormation テンプレートの出力より

 

<更新した cf_network.jsonファイルを用いて CloudFormation 展開コマンドを実行します。>


# aws cloudformation create-stack –stack-name createnetwork –template-body file:///os42/conf/cf_network.yaml –parameters file:///os42/conf/cf_network.json –capabilities CAPABILITY_NAMED_IAM


 

<出力を確認します。>


# aws cloudformation describe-stacks –stack-name createnetwork


ParameterKey ParameterValue 備考
PrivateHostedZoneId Z0xxxxxxxxxxxxxxxxxxxx プライベート DNS のホストゾーン ID
ExternalApiLoadBalancerName net/nicptestcluster-w8r8h-ext/9a604677bb972af0 外部 API ロードバランサーのフルネーム
InternalApiLoadBalancerName net/nicptestcluster-w8r8h-int/a277ca3a4501369a 内部 API ロードバランサーのフルネーム
ApiServerDnsName api-int.nicptestcluster. example.com API サーバーのFQDN
RegisterNlbIpTargetsLambda arn:aws:lambda:ap-northeast-1:359962000209:function:createnetwork-RegisterNlbIpTargets-1M2PEFJK0J2C3 これらのロードバランサーの登録/登録解除に役立つ Lambda ARN
ExternalApiTargetGroupArn arn:aws:elasticloadbalancing:ap-northeast-1:359962000209:targetgroup/creat-Exter-RH5R6UUT2ULX/80f9d95fe136b5e3 外部 API ターゲットグループの ARN
InternalApiTargetGroupArn arn:aws:elasticloadbalancing:ap-northeast-1:359962000209:targetgroup/creat-Inter-B5IB5RST56XN/4cfdcc5ae595e3f9 内部 API ターゲットグループの ARN
InternalServiceTargetGroupArn arn:aws:elasticloadbalancing:ap-northeast-1:359962000209:targetgroup/creat-Inter-NEZL8AMZ4W1X/5a6cce34822ca9dc 内部サービスターゲットグループの ARN

 

(6)AWS でのセキュリティーグループおよびロールの作成

<これまでと同様にマニュアルの該当ページの内容を含んだファイルをそれぞれ”/os42/conf”に配置します。>

CloudFormation Templateのパラメーター:”cf_security.json”ファイル
CloudFormation Template:”cf_security.yaml”ファイル

 

<cf_security.jsonファイルを編集します。>
以下の4箇所のParameterValueに値をセットします。

ParameterKey ParameterValue 備考
InfrastructureName nicptestcluster-w8r8h Ignition 設定ファイルから抽出したインフラストラクチャー名
VpcCidr 10.0.0.0/16 VPCのサブネットアドレス値
PrivateSubnets subnet-0407cf93524961fb4 VPC の CloudFormation テンプレートの出力より
VpcId vpc-00a56e4c475a50da8 VPC の CloudFormation テンプレートの出力より

 

<CloudFormation展開コマンドを実行します。>


# aws cloudformation create-stack –stack-name createsecurity –template-body file:///os42/conf/cf_security.yaml –parameters file:///os42/conf/cf_security.json –capabilities CAPABILITY_NAMED_IAM


 

<出力を確認します。>


# aws cloudformation describe-stacks –stack-name createsecurity


ParameterKey ParameterValue 備考
MasterSecurityGroupId sg-0ca008469442d0702 マスターセキュリティーグループ ID
WorkerSecurityGroupId sg-0fcaab02eeb63b716 ワーカーセキュリティーグループ ID
MasterInstanceProfile createsecurity-MasterInstanceProfile-JAFR521FJOOL マスター IAM インスタンスプロファイル
WorkerInstanceProfile createsecurity-WorkerInstanceProfile-1320LLA579623 ワーカー IAM インスタンスプロファイル

 

(7)AWS インフラストラクチャーの RHCOS AMI

<利用するRHCOS AMIのAWSゾーンとAWS AMIをマニュアルページの”1.5.10. AWS インフラストラクチャーの RHCOS AMI”にて確認します。>
今回は aws configure でも指定した ap-northeast-1 ですので、該当ゾーンの AWS AMI を確認します。

  • AWSゾーン:ap-northeast-1
  • AWS AMI:ami-0426ca3481a088c7b

 

3-2. OpenShift導入

(1)Bootstrapノード作成

OpenShiftクラスターの初期化で使用するBootstrapノードをAWS上に作成します。

<Ignition 設定ファイルを S3バケットに配置します。>


まずS3バケットを作成します

# aws s3 mb s3://nicptestcluster-infra

続いてIgnition 設定ファイル(bootstrap.ign )をS3バケットにアップロードします。

# aws s3 cp bootstrap.ign s3://nicptestcluster-infra/bootstrap.ign

最後にファイルがアップロードされたことを確認します。

# aws s3 ls s3://nicptestcluster-infra/
2020-03-27 10:08:33 291635 bootstrap.ign


 

</os42/confディレクトリに以下のファイルを作成します。>

CloudFormation Template:”cf_bootstrap.yaml”ファイル
CloudFormation Templateのパラメーター:”cf_bootstrap.json”ファイル

 

<cf_bootstrap.jsonファイルを編集します。>

ParameterKey ParameterValue 備考
InfrastructureName nicptestcluster-w8r8h Ignition 設定ファイルから抽出したインフラストラクチャー名
RhcosAmi ami-0426ca3481a088c7b 確認したAWS AMI
AllowedBootstrapSshCidr 0.0.0.0/0 デフォルトのまま
PublicSubnet subnet-0306b9ca39a3a00bd VPC の CloudFormation テンプレートの出力より
MasterSecurityGroupId sg-0ca008469442d0702 セキュリティーグループおよびロールの CloudFormation テンプレートの 出力より
VpcId vpc-00a56e4c475a50da8 VPC の CloudFormation テンプレートの出力より
BootstrapIgnitionLocation s3://nicptestcluster-infra/bootstrap.ign ブートストラップファイルの場所
AutoRegisterELB yes ネットワークロードバランサー (NLB) を登録するかどうか
RegisterNlbIpTargetsLambdaArn arn:aws:lambda:ap-northeast-1:359962000209:function:createnetwork-RegisterNlbIpTargets-1M2PEFJK0J2C3 ネットワークのCloudFormationテンプレートの出力より
ExternalApiTargetGroupArn arn:aws:elasticloadbalancing:ap-northeast-1:359962000209:targetgroup/creat-Exter-RH5R6UUT2ULX/80f9d95fe136b5e3 ネットワークのCloudFormationテンプレートの出力より
InternalApiTargetGroupArn arn:aws:elasticloadbalancing:ap-northeast-1:359962000209:targetgroup/creat-Inter-B5IB5RST56XN/4cfdcc5ae595e3f9 ネットワークのCloudFormationテンプレートの出力より
InternalServiceTargetGroupArn arn:aws:elasticloadbalancing:ap-northeast-1:359962000209:targetgroup/creat-Inter-NEZL8AMZ4W1X/5a6cce34822ca9dc ネットワークのCloudFormationテンプレートの出力より

 

<CloudFormation 展開コマンドを実行します。>


# aws cloudformation create-stack –stack-name bootstrap –template-body file:///os42/conf/cf_bootstrap.yaml –parameters file:///os42/conf/cf_bootstrap.json –capabilities CAPABILITY_NAMED_IAM


 

<出力を確認します。>


# aws cloudformation describe-stacks –stack-name bootstrap


ParameterKey ParameterValue 備考
BootstrapInstanceId i-0a68a104e8a04ae08 Bootstrapインスタンス ID
BootstrapPublicIp 13.112.188.xxx Bootstrapノードのパブリック IP アドレス
BootstrapPrivateIp 10.0.0.xxx Bootstrapのプライベート IP アドレス

 

(2)コントロールプレーン(Masterノード)の作成

</os42/confディレクトリに以下のファイルを作成します。>

CloudFormation Template:”cf_controlplane.yaml”ファイル
CloudFormation Templateのパラメーター:”cf_controlplane.json”ファイル

 

<cf_controlplane.jsonファイルを編集します。>

ParameterKey ParameterValue 備考
InfrastructureName nicptestcluster-w8r8h Ignition 設定ファイルから抽出したインフラストラクチャー名
RhcosAmi ami-0426ca3481a088c7b 確認したAWS AMI
AutoRegisterDNS yes yesまたはno
PrivateHostedZoneId Z0xxxxxxxxxxxxxxxxxxxx ネットワークのCloudFormationテンプレートの出力より
Master0Subnet subnet-0407cf93524961fb4 VPC の CloudFormation テンプレートの出力より
Master1Subnet subnet-0407cf93524961fb4 VPC の CloudFormation テンプレートの出力より
Master2Subnet subnet-0407cf93524961fb4 VPC の CloudFormation テンプレートの出力より
MasterSecurityGroupId sg-0ca008469442d0702 セキュリティーグループおよびロールの CloudFormation テンプレートより
IgnitionLocation https://api-int.nicptestcluster.example.com:22623/
config/master
生成される Ignition 設定ファイルの場所を指定
CertificateAuthorities data:text/plain;charset=utf-8;base64,LS0tLS1・・・ インストールディレクトリーにあるmasiter.ignファイルから値を指定
MasterInstanceProfileName” createsecurity-MasterInstanceProfile-JAFR521FJOOL セキュリティーグループおよびロールの CloudFormation テンプレートより
MasterInstanceType m5.xlarge 利用するEC2インスタンスタイプを指定
AutoRegisterELB yes yesまたはno
RegisterNlbIpTargetsLambdaArn arn:aws:lambda:ap-northeast-1:359962000209:function:createnetwork-RegisterNlbIpTargets-1M2PEFJK0J2C3 ネットワークのCloudFormationテンプレートの出力より
ExternalApiTargetGroupArn arn:aws:elasticloadbalancing:ap-northeast-1:359962000209:targetgroup/creat-Exter-RH5R6UUT2ULX/80f9d95fe136b5e3 ネットワークのCloudFormationテンプレートの出力より
InternalApiTargetGroupArn arn:aws:elasticloadbalancing:ap-northeast-1:359962000209:targetgroup/creat-Inter-B5IB5RST56XN/4cfdcc5ae595e3f9 ネットワークのCloudFormationテンプレートの出力より
InternalServiceTargetGroupArn arn:aws:elasticloadbalancing:ap-northeast-1:359962000209:targetgroup/creat-Inter-NEZL8AMZ4W1X/5a6cce34822ca9dc ネットワークのCloudFormationテンプレートの出力より

 

<今回、”MasterInstanceType” に m5 インスタンスタイプを指定するので、そのインスタンスタイプを cf_controlplane.yaml ファイルの MasterInstanceType.AllowedValues パラメーターに追加します。>


途中、省略

MasterInstanceType:
Default: m4.xlarge
Type: String
AllowedValues:
– “m4.xlarge”
– “m4.2xlarge”
– “m4.4xlarge”
– “m4.8xlarge”
– “m4.10xlarge”
– “m4.16xlarge”
– “m5.xlarge” ←追加
– “m5.2xlarge” ←追加
– “m5.4xlarge” ←追加
– “m5.8xlarge” ←追加

以下、省略


 

<CloudFormation 展開コマンドを実行します。>


# aws cloudformation create-stack –stack-name controlplane –template-body file:///os42/conf/cf_controlplane.yaml –parameters file:///os42/conf/cf_controlplane.json


 

<状況を確認します。>


# aws cloudformation describe-stacks –stack-name controlplane


 

(3)Workerノードの作成

※CloudFormation テンプレートは、1 つのWorkerマシンを表すスタックを作成します。今回はWorkerノードを2台作成するので、それぞれのWorkerマシンにスタックを作成する必要があります。

</os42/confディレクトリに以下のファイルを作成します。>

CloudFormation Template:”cf_worker.yaml”ファイル
CloudFormation Templateのパラメーター:”cf_worker.json”ファイル

 

<cf_worker.jsonファイルを編集します。>

ParameterKey ParameterValue 備考
InfrastructureName nicptestcluster-w8r8h Ignition 設定ファイルから抽出したインフラストラクチャー名
RhcosAmi ami-0426ca3481a088c7b 確認したAWS AMI
Subnet subnet-0407cf93524961fb4 VPC の CloudFormation テンプレートの出力より
WorkerSecurityGroupId sg-0fcaab02eeb63b716 セキュリティーグループおよびロールの CloudFormation テンプレートより
IgnitionLocation https://api-int.nicptestcluster.example.com:22623/
config/worker
生成される Ignition 設定ファイルの場所を指定
CertificateAuthorities data:text/plain;charset=utf-8;base64,LS0tLS1・・・ インストールディレクトリーにあるworker.ignファイルから値を指定
WorkerInstanceProfileName createsecurity-WorkerInstanceProfile-1320LLA579623 セキュリティーグループおよびロールの CloudFormation テンプレートより
WorkerInstanceType m5.xlarge 利用するEC2インスタンスタイプを指定

 

<cf_controlplane.yamlと同様に、”MasterInstanceType” に m5 インスタンスタイプを指定するので、そのインスタンスタイプを cf_worker.yaml ファイルの MasterInstanceType.AllowedValues パラメーターに追加します。>

CloudFormation 展開コマンドを実行。
今回ワーカーノードは2台作成するので、stack-name を「worker1」「worker2 」と分けて2回実行します。


# aws cloudformation create-stack –stack-name worker1 –template-body file:///os42/conf/cf_worker.yaml –parameters file:///os42/conf/cf_worker.json
# aws cloudformation create-stack –stack-name worker2 –template-body file:///os42/conf/cf_worker.yaml –parameters file:///os42/conf/cf_worker.json


 

<出力を確認します。>


# aws cloudformation describe-stacks –stack-name worker1
# aws cloudformation describe-stacks –stack-name worker2


 

(4)Bootstrapノードの初期化

<Bootstrapノードの初期化コマンドを実行し、FATAL エラーなどが出ずに終了することを確認します。>


# ./openshift-install wait-for bootstrap-complete –dir=/os442 –log-level=info
INFO Waiting up to 30m0s for the Kubernetes API at https://api.test.example.com:6443…
INFO API v1.14.6-152-g117ba1f up
INFO Waiting up to 30m0s for bootstrapping to complete…
INFO It is now safe to remove the bootstrap resources


 

(5)CLI のインストール

<OpenShift Installer、Pull secretをダウンロードしたページにて、「Command-line interface」項目からOSとして「Linux」を選択し、「command-line tools」をダウンロードします。>

<CLIツールの展開 – ダウンロードした圧縮ファイルを展開します 。>


※OS42ディレクトリにダウンロードしたファイルをコピーし、展開します。
# cp tar xvf openshift-client-linux-4.2.23.tar.gz /os42/tar xvf openshift-client-linux-4.2.23.tar.gz
# tar xvf openshift-client-linux-4.2.23.tar.gz
※パスに/oc42を追加します。
# export PATH=”$PATH:/os42″
※ocコマンドのテスト
# oc help


 

(6)クラスターへのログイン

※kubeadmin 認証情報をエクスポートします。
# export KUBECONFIG=/os42/auth/kubeconfig
※oc コマンドを正常に実行できることを確認
# oc whoami
system:admin


 

(7)マシンの CSR の承認

<クラスターがマシンを認識していること(今回Masterノード3台、Workerノード2台が表示されること)を確認します。>


# oc get nodes
NAME                   STATUS  ROLES  AGE   VERSION
ip-10-0-48-xxx.ap-northeast-1.compute.internal  Ready   worker  57s   v1.14.6+8fc50dea9
ip-10-0-49-xxx.ap-northeast-1.compute.internal    Ready    worker  42m  v1.14.6+8fc50dea9
ip-10-0-50-xxx.ap-northeast-1.compute.internal  Ready    master  22h  v1.14.6+8fc50dea9
ip-10-0-58-xxx.ap-northeast-1.compute.internal  Ready    master  22h  v1.14.6+8fc50dea9
ip-10-0-59-xxx.ap-northeast-1.compute.internal  Ready    master  22h  v1.14.6+8fc50dea9


 

(8)Operator の初期設定

5秒ごとに実行される oc get clusteroperators の結果をモニタリングし、クラスターコンポーネントがオンラインになることを確認します。

<”Available” が ”True”、”DEGRADED” 列が ”False” になることを確認します。>


# watch -n5 oc get clusteroperators
NAME      VERSION  AVAILABLE  PROGRESSING  DEGRADED  SINCE
authentication   4.2.23   True      False       False     44m
cloud-credential  4.2.23   True      False       False     22h
cluster-autoscaler  4.2.23   True      False       False     22h
console      4.2.23   True      False       False     46m
dns        4.2.23   True      False       False     22h
image-registry   4.2.23   True      False       False     50m
ingress      4.2.23   True      False       False     50m


以下、省略


 

本検証では、(7)マシンの CSR の承認の手順で全ノードが Ready となった後に確認するとすべての Operator コンポーネントがオンライン(AVAILABLE 列が True)になっていましたが、image-registry Operator がオフライン(AVAILABLE 列が False)である場合はマニュアルページの「1.5.17.1. イメージレジストリーストレージの設定」の章をご確認ください。

 

(9)Bootstrapノードの削除

クラスターの初期 Operator 設定を完了した後に Bootstrapリソースを削除します。

<CloudFormation コマンドで”(1)Bootstrapノード作成”手順で作ったbootstrap という名前の Stack を削除します。>
これにより、ブートストラップノードが削除されます。


# aws cloudformation delete-stack –stack-name bootstrap


 

(10)クラスターのインストールを完了

<クラスターのインストール完了を確認します。>
以下のコマンドでインストール状況をモニターします。


#./openshift-install –dir=/os42 wait-for install-complete

(中略)

INFO Install complete!
INFO To access the cluster as the system:admin user when using ‘oc’, run ‘export KUBECONFIG=/os42/auth/kubeconfig’
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.nicptestcluster.example.com
INFO Login to the console with user: kubeadmin, password: XXXXX


上記のように ”Install complete!” となり、「コンソールのURL」「ユーザー名」「パスワード」が表示されればインストール完了で OpenShift 環境が利用可能となります。

!!重要!!

インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになる証明書が含まれます。
Ignition ファイルは 24 時間有効であるため、この時間内に OpenShift デプロイメントを実行する必要があります。 作成から24時間過ぎた場合はIgnition ファイルを再生成する必要があります。

 

<動作確認 – OpenShiftのコンソールにアクセスします。>

  • Webコンソールの場合:
    https://console-openshift-console.apps.nicptestcluster.example.com
  • CLI の場合:
    oc login -u kubeadmin -p XXXXX https://api.nicptestcluster.example.com:6443

以上で OpenShift インストールは完了となります。

 

お問い合わせ

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

エヌアイシー・パートナーズ株式会社
技術支援本部

E-Mail:nicp_support@NIandC.co.jp

 

その他の記事

2025年07月11日

【参加レポート】Domino Hub 2025

公開日:2025-07-11 みなさまこんにちは。ソリューション企画部 松田です。 2025年6月19日・20日と2日間に渡って開催された「Domino Hub 2025」に参加しました。これは HCL Ambassador有志が企画・実行する Dominoコミュニティイベントです。去年に続き、今回が3回目の開催となります。 昨年同様、今回もエヌアイシー・パートナーズはスポンサーとしてご支援させていただき、両日参加いたしました。そのレポートをお送りします。 目次 イベント概要 セッション内容 - Domino 14.5 リリース 特徴的機能とライセンス改定 -ロードマップ -お客様事例:曽根田工業様 最後に 関連情報 お問い合わせ イベント概要 「Domino Hub」は、HCL Ambassadorが主宰となり、Dominoの利用者、開発者、ソリューションベンダーが一堂に会するコミュニティイベントです。今回は1日目がオンライン、2日目はオンサイトのみの開催でした。 特に2日目は参加率が非常に高かったとのことで、会場も大変盛況でした。結婚式場としても使われている今回の会場は、中庭から陽の光が差し込み、解放感があるラグジュアリーな空間で、一般的なビジネスミーティングよりも上質な雰囲気が感じられました。 併せて展示ブースも設置され、Dominoアプリケーションがスマートフォンやブラウザで使えるようになる「HCL Nomad」などのHCL製品とともに、様々なビジネスパートナー様の多彩な関連製品が数多く展示・紹介されていました。 セッション内容 2日間で全22セッションが行われました。セッションはHCLをはじめ、HCL Ambassadorから、様々な開発ベンダー、製品ベンダー、エンドユーザーからの事例紹介などのセッション、そしてパネルディスカッションがありました。まずHCLからのセッション内でのトピックをお伝えします。機能のみならずライセンスまわりで大きなニュースもありました。 Domino 14.5 リリース 特徴的機能とライセンス改定 Domino Hubの2日前、2025年6月17日にリリースされました。 Domino IQ 特徴的な機能で最も注目すべき、今回もご説明に時間を割かれていたのが「Domino IQ」です。 一言で言えば「Domino内にローカルでLLMを持たせ、蓄積されてきたDominoアプリ内の情報も取り込み、セキュアな環境で生成AIを用いた業務を実現する」ものです。 企業内業務で生成AIをどのように実装し利用していくかは今、皆様の大きな関心事項であられると思います。自社のDomino環境内で、Dominoアプリケーションを用い、Notesクライアントからそれが実現できることになります。 (画像クリックで拡大) Nomad for Web COM対応 またNomad for WebがCOMに対応したことにより、これまではNotesクライアントだけでしかできなかったExcelやPowerPointを埋め込んだDiminoアプリもブラウザから利用できるようになりました。 ライセンスダッシュボード:DLAUの統合 これまでGitHubからダウンロードしてセットアップしていたDomino License Analysis Utility (DLAU)がDomino内にデフォルトで統合され、The Domino License Administration (DLA) となりました。 (画像クリックで拡大) ライセンス改定 そしてライセンスにも大きなベネフィットが付加されました。CCB Termライセンスにはこれまで「Domino Leapで5アプリケーションまで開発・利用が可能」という権利が含まれていましたが、2025年7月1日からその制限がなくなりました。すなわち「2025年7月1日以後有効なCCB Termライセンスをお持ちのお客様は、Domino Leapのフル機能が利用できる」となります。 同時に、Domino Leapライセンスの利用範囲であるHCL Enterprise Integrator(HEI)の利用権利も含まれます。これでCCB Termライセンスのみで、追加費用なく「ブラウザによるノーコード/ローコード開発」「基幹業務とDominoアプリケーションの連携」が可能になります。 さらにCCB Termで利用できるSametime Chatで添付ファイルと画像添付も可能になりました。 ロードマップ Domino、Notes、Verse、Nomadなど各ソリューションについてのロードマップも紹介されました。先々の計画は出てこないものですが、このようにHCLから明確に提示されることにより、Dominoをお使いのお客様はこれからも安心して利用を継続していただけると思います。 Dominoのロードマップ(画像クリックで拡大) Notesのロードマップ(画像クリックで拡大) Nomad, VerseといったエンドユーザーのUI部分が短期間でバージョンアップされていく。(画像クリックで拡大) お客様事例:曽根田工業 様 Dominoユーザーの有限会社曽根田工業 代表取締役 曽根田 直樹 様より、Domino事例のご講演がありました。曽根田様は2001年に静岡県磐田市で個人で企業され、切削機械の刃物を製造されています。曽根田様のお話で非常に興味深かった部分を抜粋致します。 "独立・起業するにあたり、前職で使っていたNotes/Dominoを自社でも使うことにした。現在は大手メーカーからの発注依頼や過去に作った品番の再発注など数多く受けており、当時のCAD/CAMのデータや販売管理データなどをDominoに入れて運用している。 オンプレミス環境のリスクやセキュリティ、IT技術のトレンドに合わせてクラウド化を検討した場合、Dominoからは離れたほうがいいのではないか?と思い、他社SaaS製品も検討しトライアルで利用登録をした。 しばらく触れずにいたところ、アカウント情報に登録していた支払い口座から利用料の引き落としがされていなかったためアカウントが凍結、さらに保存していたデータも突然消去されてしまっていた。支払いが滞っただけで中身まで削除されてしまうようなシステムには会社の大事な資産であるデータを載せられないので、「Dominoを『やめることを止める』判断」をした。" Dominoから他製品への移行を検討され断念されるお客様は多く、その理由は「Dominoの業務アプリケーションを、サービス内容を落とさずに別プラットフォームに移行することがはなはだ困難である」ということをよくお聞きしますが、この点にも意外な理由が潜んでいました。 最後に 初の2年連続開催となった今年のDominoHubは、コミュニティの力を象徴するかのような盛り上がりを見せました。14.5のリリース、生成AIの実装、ライセンス強化など、今後のDominoの発展を確信させる要素が数多く披露されたほか、実際のユーザー事例も非常に示唆に富むものでした。加えてロードマップの提示による未来への安心感も得られました。 DominoHubは単なる情報共有の場に留まらず、技術、コミュニティ、そしてビジネスの未来を交差させる特別な場となっています。これからもこのような取り組みが継続していき、多くのDominoユーザー、デベロッパー、そして販売パートナーが更なる価値を引き出していけることを楽しみにしています。これからもDominoと私たちの未来を築いていきましょう。 関連情報 「Domino Hub」大阪開催 Domino Hubは、2025年9月18日に大阪でのオンサイト開催が決定致しました。詳細およびお申し込みについては、こちらのリンクからご確認ください。 お問い合わせ エヌアイシー・パートナーズ株式会社E-mail:voice_partners@niandc.co.jp   .highlighter { background: linear-gradient(transparent 50%, #ffff52 90% 90%, transparent 90%); } .anchor{ display: block; margin-top:-20px; padding-top:40px; } .btn_A{ height:30px; } .btn_A a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_A a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; } figcaption { color: #7c7f78; font-size: smaller; }

2025年06月30日

APMとARMのシームレスな連携で効率的な統合アプリケーション運用管理を実現する ~Instana+Turbonomicのシナジー~

公開日:2025-06-30 ワークロードが変化しつづけるハイブリッド・クラウド環境下においては、アプリケーションスタックが複雑化し、分散され、流動的となり、それがアーキテクチャーと、正しい設計および変化する需要に対応できる十分なリソースの提供を難しくしています。 複雑化したIT環境で、システムの正常性やパフォーマンスリスクに対応するためには、アプリケーションの運用管理において、アプリケーションとインフラ両方の情報を一元管理します。そして、統合的に参照することができ、システムの変調を見逃さない高度な可観測性を実現するアプリケーションの運用の高度化が重要となります。 本コラムでは、アプリケーションパフォーマンス監視(APM)ツール「IBM Instana Observability」(以下 Instana)とアプリケーション・リソース管理(ARM)ソリューション「IBM Turbonomic」の連携で生まれる、統合アプリケーション運用管理の相乗効果について紹介します。 目次 1. 複雑化したIT環境に求められるAPMによる可視化とアプリケーションの運用高度化 2. アプリケーションリソース管理の課題を解決するARMの活用 3. APMとARMの統合が可能にするアプリケーションの運用管理の効率化 4. InstanaとTurbonomicの連携による、一元的な管理の相乗効果 5. InstanaとTurbonomicの連携による、統合的なアプリケーションの運用管理の価値 6. まとめ お問い合わせ 1. 複雑化したIT環境に求められるAPMによる可視化とアプリケーションの運用高度化 アプリケーションの稼働環境がオンプレミスだけでなくクラウド環境へ拡大しています。クラウド上では様々なクラウドネイティブなサービスが稼働しており、それを利用することはコスト面・スピード面で必然となっています。しかし、クラウドネイティブ環境が増え続けることで複雑化しがちであり、そのような複雑なクラウドネイティブ環境の運用監視をいかに効率的に行うか、がビジネスにおいて大きな課題となっています。 システムを構成するハードウェアとソフトウェアが正常に稼動しているかについて、個々の状態を把握することに主眼がおかれた従来型モニタリングは、ハードウェアの障害やソフトウェアの異常を素早く検知することに役立つ一方で、ハードウェアの故障やサービスの停止をともなわないアプリケーションの性能低下などが検知することが難しく、原因の特定に非常に多くの時間がかかります。 また、従来型モニタリングの多くは、各環境で利用されている言語やプログラムにあわせた事前の導入と構成・設定が必要なだけではなく、サービス間の依存関係が把握できず、固定の閾値を超えたかどうかの確認しかできないため、ダイナミックに変化しつづけるクラウドネイティブ環境に追随していくことは困難です。 これに対して、アプリケーションのパフォーマンスを監視し、問題が発生した際に迅速に検知し、解決するのが、アプリケーションパフォーマンス管理(Application Performance Management: APM)による「アプリケーションの運用高度化」です。 APMにより、アプリケーションが本番環境で正常に動作していることをモニタリングして、システムやアプリケーションが利用者に提供している「サービスの品質」と「システムの状態」を可視化し、トランザクションのパフォーマンスの状態を測定するのが可能になります。 IBMのAPMツール「Instana」は、「自動化」「コンテキストの把握と解析」「インテリジェントなアクション」の特長を持ち、デジタルプラットフォームの効率的な管理および迅速な障害個所の特定など、クラウドネイティブ環境の可視化を実現しアプリケーションの可用性向上に貢献します。 2. アプリケーションリソース管理の課題を解決するARMの活用 一方、アプリケーションが安定したパフォーマンスを提供し続けるには、アプリケーションがユーザからのリクエストを処理するため必要なリソースを確保することが前提条件となります。 そのためには、適切なリソースを割り当て、必要に応じて増減させる管理をする必要があります。その上で、利用者の要望を実現する高度な機能とストレスのない使いやすいUX/UIの提供、24時間365日無停止での安定したサービスの継続、急激なアクセスの増加にも耐える拡張性や俊敏性が求められます。さらには、システム上で実行されるアプリケーションが、事前に定義されたセキュリティポリシーやルールに完全に適合していなくてはなりません。 しかし、アプリケーションスタックが複雑化し、ワークロードが変化しつづけるハイブリッド・クラウド環境下で、従来のインフラ中心のアプローチや手動ツールを使った人手主体の管理や監視手法だけで24時間365日アプリケーションリソースを維持管理し、適切なリソースを予測し確保し続けることは非常に困難です。 また、リソース不足にならないように、必要以上の余剰な CPU/メモリ/ディスクなどのサーバリソースを持たせることは、コスト面で大きな負担となります。さらに、多頻度のリリースに対応しうる高速・高効率で、継続的な品質担保に対応することが求められる一方で、高スキルのIT人材が、慢性的に不足していることも現状の管理体制の大きな負担となっています。 これに対して、コンピュートリソースの不足を早期に把握し、最適化を行い人手をかけずに適切な意思決定を適切なタイミングで行うことで、アプリケーションのレスポンスを維持するのが、アプリケーションリソース管理(Application Resource Management : ARM)です。 IBM の AI駆動型ARMソリューション「IBM Turbonomic ARM」は、アプリケーションからインフラまでをフルスタックで可視化し、アプリケーションが必要とする ITリソースを最適化します。そして、AI を用いてアプリケーションパフォーマンス、コンプライアンスおよびコストの継続的な管理を可能にします。 3. APMとARMの統合が可能にするアプリケーションの運用管理の効率化 アプリケーション運用管理の効率化は、宣言的に定義されたシステムのあるべき状態にシステムを制御する各種のオーケストレータによって、APMとARMを活用し徹底して自動化することで実現できます。ただし、システムで現在起きている問題のリアルタイムでの監視や、オーケストレータを介した問題へ自動に対処することはもちろん、あるべき姿へ迅速に回帰する「クローズドループサイクル(循環生産)」型のプロセスを実現することが不可欠となります。 このプロセスにおいて、APMとARMをそれぞれ独立した状態で活用するだけでは、目的に応じた画面の切り替えやツールごとの設定・操作などに非常に手間が掛かります。 APMであるInstanaとARMであるTurbonomicを連携することで、「統合的なアプリケーションの運用管理」を実現し、運用管理作業効率を向上することで以下のような効果を発揮します。 (1)ワンストップでインフラやアプリUXなどのパフォーマンスを統合管理できる (2)素早く問題の発生を検知し原因を特定できる (3)新規の監視対象を自動で認識でき個別の作業が不要となる (4)メンテナンスに工数がかからない 4. InstanaとTurbonomicの連携による、一元的な管理の相乗効果 InstanaとTurbonomicを連携させ、双方向の統合を設定することで、画面を切り替えることなく、1ヵ所・1画面の一元化された操作で、効率的に統合的なアプリケーションの運用管理を行うことが可能です。 InstanaとTurbonomic の連携による相乗効果には、次のようなものか挙げられます。 (1)アプリケーションレベルからインフラレベルまで統一管理できる TurbonomicにInstanaの情報を連携することにより、1つの画面でインフラからアプリケーションレベルまでアプリケーション・スタック全体を統合的に可視化し、操作もシームレスに連携することで、パフォーマンスのリスクを把握しリソースを最適化するための積極的な推奨策を得るとともに、リスクの軽減や迅速な判断をすることが可能になります。 (2)故障が発生する前に予兆を検知して事前に対応できる アプリケーション視点でのパフォーマンス・障害分析とインフラ観点でのリソース分析と最適化を同時に行うことで、障害の発生を未然に防ぐための対策を実施できるようになるため、アプリケーションの可用性を向上することができるようになります。 そのため、リソースの輻輳を最小限に抑えることができ、その効果として、平均修復時間(MTTR)と平均故障間隔(MTBF)を改善し、機会損失を最小限に抑えます。 (3)パフォーマンスに影響するリソースを理解し対応ができるようになる Instanaは、Turbonomicの実行したアクションと監視対象アプリケーションのパフォーマンスへの影響について、履歴の記録を得ることができます。また、Turbonomicによって提供されるリソース自動最適化機能を統合し、IT環境全体の集約された性能を最適な状態に維持します。これにより、ユーザは、単一の場所から一元的にアプリケーションを監視し、リアルタイムのデータと需要に基づいた状況に合わせて、需要に則したリソース割りあて・確保の決定を実行することができます。 InstanaとTurbonomicの統合によって、クラウド環境やKubernetesのリソース費用を正確に把握できるようになるため、十分に活用されていないリソースやオーバープロビジョニングされたリソースを最適化するための推奨案が得られます。これを元に、ハイブリッド(セルフ・マネージド)やクラウドネイティブ、Kubernetesのワークロードのパフォーマンス改善、効率化、コンプライアンス対応、コスト削減を促進し、クラウドの無駄を削減するとともに、その効果を向上させることが可能になります。 5. InstanaとTurbonomicの連携による、統合的なアプリケーションの運用管理の価値 このようにInstanaとTurbonomicを連携させることで、お客様は、インフラ・アプリケーションを統合的に可視化できるようになるだけでなく、アプリケーションのパフォーマンスリスクに素早く対応することが可能になります。 また、Turbonomicと連携できるAPMはInstanaだけではなく、お客様が、現在お使いになっているAPMとも連携することも可能です。さらには下図のロードマップのように、APM+ARMだけでなく、他のソリューションとも連携させることで、お客様のアプリケーションの運用高度化をさらに進め、ビジネスにより大きな価値をもたらすことができます。 図1:InstanaとTurbonomicの連携によるアプリケーションの運用高度化 6. まとめ このように、InstanaとTurbonomicを連携させた一元的な操作によって、複雑化したIT環境においても、ワンストップでインフラやアプリUXなどを監視・管理し、リソースの無駄やクラウド費用の増加なしに、アプリケーションに最適なリソースを動的に割りあてることができます。これにより、効率的なアプリケーションの管理の実現と、期待どおりのパフォーマンスを発揮して顧客のニーズを満たすことが可能になります。 エヌアイシー・パートナーズ株式会社は、IBMソフトウェア(SW)とハードウェア(HW)の認定ディストリビュータとして、InstanaおよびTurbonomicに関する支援が可能です。 お客様のニーズや要件に合わせて、IBMのSWとHWを組み合わせた最適な提案やカスタマイズの支援、IBM製品の特長・利点をお客様にわかりやすく説明し、お客様・パートナー様のビジネスに最適な提案でサポートいたします。 「シナジー効果の高いInstanaおよびTurbonomicに絡めたセールスをサポートしてほしい」といったご要望があれば、いつでもお気軽にお問い合わせ・ご相談ください。 お問い合わせ この記事に関するお問い合せは以下のボタンよりお願いいたします。お問い合わせ   .highlighter { background: linear-gradient(transparent 50%, #ffff52 90% 90%, transparent 90%); } .anchor{ display: block; margin-top:-20px; padding-top:40px; } .btn_A{ height:26px; } .btn_A a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_A a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }

2025年06月26日

次世代型のインフラ構築を実現するIBM Fusion HCIがクラウドシフトを加速

公開日:2025-06-26 クラウドファースト時代となり、企業のインフラ構築においてもクラウドネイティブなアーキテクチャをめざす潮流が高まりつつあります。なかでも重要な技術とされるのが、コンテナベースの基盤づくりで、アプリケーションをコンテナ化できれば、その移植性や効率性、スケーラビリティなどが大きく高まり、ビジネスの展開を高速化できると期待が集まっています。 しかし、基盤のコンテナ化は、これまでのシステム構築のあり方と大きく“作法”が異なり、専門のナレッジやスキルが求められます。ただでさえ IT人材が不足している今日、一朝一夕に移行するのは難しく、この点が多くの企業にとって大きなジレンマとなっています。 貴社においても、 「クラウド移行は進めたものの、残るオンプレミスシステムとどう連携させればいいのか」 「自社で腰を据えてAI活用に取り組みたいが、社内リソースが足りない」 などのお悩みはないでしょうか。 今回は、企業が課題を抱えがちな次世代型のインフラ構築をあっさり実現するソリューションIBM Fusion HCIを紹介します。 目次 インフラ基盤が抱える課題 IBM Fusion HCIの概要 インフラ基盤が抱える課題への最適策 IBM Fusion HCIを利用したユースケース 次世代のインフラ基盤への鍵を握るIBM Fusion HCI お問い合わせ インフラ基盤が抱える課題 今日、企業情報システムのインフラ基盤は様々な意味で岐路に立っているといえます。これまで同様の手法では、刻一刻と変化し続けるビジネス環境を受けとめきれず企業競争力を低下させる恐れもあります。 例えば、具体的な危惧の内容として次のようなものがあります。 1. クラウドネイティブなアーキテクチャ導入の高い難易度 クラウドネイティブなアーキテクチャは柔軟性やスケーラビリティを重視した設計手法で、ビジネススピードの向上にも貢献します。しかしその導入には既存のシステムとは手法が異なるため、互換性確保や高度な専門知識を持つ人材の確保といった点に障壁があります。また、従来型の開発手法から移行する際には、文化的変革や技術的理解のギャップが課題になっています。結果、プロジェクトを立ち上げたものの頓挫してしまった、というケースも発生しています。 2. マルチクラウド戦略を推進する上での壁 マルチクラウド戦略とは複数のクラウドサービスを使い分けることで、効率的なリソース管理やリスク分散を実現することを指します。多くの企業が「オンプレとクラウドを統合」または「複数のクラウド環境を最適化」したいと考えています。 しかし、相互接続性やデータ移動に大きな課題があります。また、異なるプロバイダ間での運用調整やコスト管理の複雑化も実践の妨げになりがちです。特に、各クラウド特有の設計要件への対応やパブリッククラウドとプライベートクラウド間のデータ連携には多くのリソースとノウハウが必要です。 3. 自社AIワークロードの拡大 AIワークロードの拡大は、迅速なデータ処理や大量データ解析を可能にします。しかし、これに伴って高性能なインフラ整備が求められます。既存のインフラでは計算負荷が高く、パフォーマンスが著しく制限されるためです。慎重に選定を進めなければ計算資源の増加による費用の急増が発生するリスクがあります。 エッジ環境でのデータ処理や通信コストの抑制に対応できる基盤という観点も重視しなければなりません。開発プロセスの最適化や適切な AIモデルの選定なども大きな課題です。 4. VMware基盤のコスト問題 すべての企業に当てはまるわけではありませんが、仮想化基盤として VMware を採用するのは普遍的なソリューションであり、信頼性の高い仮想化テクノロジーを提供します。 しかし、近年そのコスト問題が大きく取り沙汰されており、ライセンス料や運用費用の高さが企業にとって大きな負担となっています。長期的な予算圧迫を招く可能性があり、特に運用規模が拡大していくビジネス環境の場合、コスト管理が難航するリスクがあります。さらに、技術的な側面では仮想マシン単位でしか運用管理できないという点があり、リソースの効率的な活用に限界があります。 IBM Fusion HCIの概要 IBM Fusion HCI は、上記のようなインフラ課題を解決するために登場したハイパーコンバージドインフラ(HCI)ソリューションです。コンテナ(Red Hat OpenShift、以下 OpenShift)ベースのシステムを構築するために必要な機能をあらかじめすべてパッケージ化しており、コンテナ専用のオール・イン・ワンソリューションといえます。 具体的に必要な機能とは、統合運用管理ダッシュボード、ストレージファイルシステム、バックアップリストア、コンテナ、仮想マシンを指しており、オプションでデータ連携カタログも選択できます。納品後最短4時間で構築が完了し、すぐに使用を開始することができます。 図1:IBM Fusion HCI概念図 これにより、企業において統合データ管理やクラウドとの透過的アクセス、アプリケーションの高速化といった次世代志向のインフラ構築が実現します。また、IBM Fusion HCI はサーバー/スイッチも統合管理でき、サポートを IBM に統一できるという点においても企業の運用管理負荷を大きく軽減することが可能です。AI を含む負荷の高いワークロードにも対応できます。 このプラットフォームで、データ管理、計算リソース、ストレージを効率的に統合できるため、AIアプリケーションの実行に必要な環境がシームレスに整います。例えば、AIモデルのトレーニングや推論処理を高速化するために計算資源にスケーラビリティをもたせるといったことも可能です。さらに、セキュリティ面でも信頼性の高い機能が提供されており、企業の重要なデータを安全に保護します。 インフラ基盤が抱える課題への最適策 IBM Fusion HCI は 導入しやすく柔軟でパフォーマンスに優れたインフラ基盤 です。コンテナベースのシステム構築を進めたい企業にとって最適の選択肢といえ、そのメリットとしては次のようなものがあります。 1. クラウドネイティブへのスムーズな移行を実現 Red Hat OpenShift を基盤とし、これをあらかじめパッケージした HCI であるため、ユーザーはクラウドネイティブなコンテナ基盤を導入する際に設計を始めとした複雑な調整を省けます。また、専用インストーラーを搭載しており導入をスムーズに進めることができるため、製品が到着したその日からデジタルトランスフォーメーションに着手することが可能です。 2. マルチクラウド/エッジ環境への移行 IBM Fusion HCI は、オンプレミス、パブリッククラウド、エッジ環境のどこでも稼働することができます。特に、ハイブリッドクラウドのアプローチを強化するために設計された新しいサービス「IBM Cloud Satellite」を活用すれば、IBM Cloud サービスのメリットを IBM Fusion HCI の環境にも容易に拡張できます。 例えば、データが特定の地域に留まる必要がある法規制に従う際に、IBM Cloud Satellite はその地域でのデプロイメントをサポートしつつ IBM Cloud が提供する最新の AI、セキュリティ、ストレージ機能をオンプレミス環境で利用できます。 この透過的なデータ連携能力は、マルチクラウド環境のデータ制御に大きな力を発揮します。 3. AIワークロードに対する優れた対応力 セルフ型オンプレミスクラウドの提供 IBM Fusion HCI は AIワークロードに特化した柔軟で高度なインフラ基盤を提供します。強みは、watsonx との連携によるセルフ型オンプレミスクラウドの構築が可能 である点です。この連携により、クラウドの利便性をオンプレミス環境に取り入れ、AIモデルのトレーニングやインファレンス(推論)作業をシームレスかつ効率的に進められます。 AI処理に最適化された設計 IBM Fusion HCI には高速な AI処理を実現する設計が施されています。NVIDIA GPU の活用を可能とし、AIモデルのトレーニングや推論の速度を飛躍的に向上させます。また、watsonx.data と組み合わせることでデータクエリのパフォーマンスを従来インフラの最大90倍まで高速化 することが可能です。 エンタープライズグレードのデータ基盤 IBM Fusion HCI はデータレイクハウスとしての機能を提供し、AIワークロードに必要なデータ収集・分析基盤の構築を支援します。エンタープライズ規模の大容量データ管理に対応し高い柔軟性と拡張性を持つため、DX を推進する企業にとって理想的な選択肢と言えます。 4. コスト削減と効率性の向上 VMwareのライセンス費用をカット IBM Fusion HCI は、VMware を利用した仮想化基盤の代替として大幅なコスト削減の可能性とします。物理サーバー上に Red Hat OpenShift環境を直接構築する仕組みによって VMwareライセンス費用や運用コストを削減すると同時に、OpenShift利用における費用も最適化できます。 効率的なリソース管理 コンテナ単位での精細なリソース管理を実現する IBM Fusion HCI は、従来の仮想マシン管理よりも大きな効率性を発揮します。これにより、仮想化環境の課題(例:仮想マシン単位でしかリソースを扱えない問題)を解消し、リソースの使用効率を最大化します。 運用負荷とコストの削減 IBM Fusion HCI は設計・導入・運用にかかる負担を軽減し、運用管理の効率化を達成します。IBM による一元的なサポートが可能なため、トラブル発生時の対応が迅速かつスムーズです。また、watsonx を活用した次世代ワークロードに最適化されており、最新技術を活用しながら長期的なライセンスコストの抑制を実現します。 5. 障害時の運用負荷負担削減 IBM Fusion HCI は、システムの信頼性を高めるために設計された自動監視および報告機能である CallHome機能を搭載しています。そのため、障害発生時に IBM に自動通知でき、運用負担を軽減することができます。統合管理コンソールによりシステムの状態を一元的に確認できるため、トラブルシューティングも容易に行うことができます。 IBM Fusion HCIを利用したユースケース 1. IoTサービスでの利用 製造業で IoTサービスを開始したいという場合、製品や生産機械から IoTデータを収集し、このデータをクラウドなど IoTサービスの拠点に送る必要があります。しかし、生産拠点によってはセキュリティやネットワーク要件が厳しくデータをクラウドに出せないということもあります。 そこで、条件の厳しい工場には IBM Fusion HCI を設置しクラウド同様の IoTサービスを展開することで、エンドユーザーにデータから得られる知見を提供できます。 2. マルチクラウドでの利用 すでに進んでいるクラウド移行を統一管理したい場合にも IBM Fusion HCI は活躍します。例えば、複数クラウドの OpenShift環境に統一したセキュリティポリシーを適用するとした場合、お客様サイトの IBM Fusion HCI を起点として IBM Cloud を介して様々なロケーションの OpenShiftサービスを一元化できます。ポリシーをアップデートする際も変更が自動的に反映されるため、運用管理の負荷が大きく軽減できます。 3. AIワークロードでの利用 AIデータ処理を IBM Fusion HCI上の NVIDIA A100 GPU で実行することができます。これにより、大規模な AIシステムを構成するコアシステムやクラウド上の AIアプリケーションのデータへライブストリーミングすることができます。また、エッジで処理を終えてから、コアシステムやクラウド上のデータレイクやデータウェアハウスに送信するといったことも可能です。 図2:エッジのIBM Fusion HCIでAIデータ処理を実行 次世代のインフラ基盤への鍵を握るIBM Fusion HCI 未来志向のインフラ基盤に求められるのは「柔軟性」「効率性」「スピード」「安全性」です。IBM Fusion HCI は、これらすべてを備えた次世代型のソリューションとして、顧客提案の新しい切り札になると考えられます。 エヌアイシー・パートナーズは、IBM ソフトウェア/ハードウェアの認定ディストリビューターとして、IBM Fusion HCI のお客様への提案をサポートします。また、IBM のソフトウェア製品およびハードウェア製品を組み合わせた最適な提案を提供するとともに、製品の特長や利点をお客様にわかりやすく説明し、お客様・パートナー様のビジネスをサポートしています。 「お客様のニーズや要件に合わせて総合的なIBMソリューションを提案したい」 「IBM製品の機能や適用方法についての問い合わせに適切に対応したい」 「IBM製品の特長や利点を活かしてお客様ビジネスに最適なプランを提示したい」 といったご要望をお持ちの際は、お気軽にエヌアイシー・パートナーズへご相談ください。 お問い合わせ この記事に関するお問い合せは以下のボタンよりお願いいたします。お問い合わせ   .highlighter { background: linear-gradient(transparent 50%, #ffff52 90% 90%, transparent 90%); } .anchor{ display: block; margin-top:-20px; padding-top:40px; } .btn_A{ height:26px; } .btn_A a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_A a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }

back to top