2020年09月

02

【やってみた】IBM Cloud Pak for Applications導入してみた:OpenShift導入編 (手順詳細)

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


 

1.本記事について

本記事は「【やってみた】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

その他の記事

2021年03月25日

企業を狙ったランサムウェアの増加で再認識される、 バックアップの重要性と対策のポイント

2017年5月に世界的に大流行し、その後鎮静化していたランサムウェアの脅威が増大しています。 IPA(独立行政法人 情報処理推進機構)が毎年発表する「情報セキュリティ10大脅威」の組織部門においても、ここ数年、不動の第1位に君臨する「標的型攻撃による被害」の陰で、「ランサムウェアによる被害」が2017年以降5位以内をキープ。最近では多額の身代金が獲れそうな企業にターゲットを定め、データを暗号化するだけではなく機密データを窃取し、それを公開すると脅して身代金を要求するなど、標的型化の事例も報告され、高度化・巧妙化が進んでいます。 本記事では、こうした最新動向や被害の状況に触れつつランサムウェア感染からのシステム復旧を考える上で欠かせないバックアップについて、対策のポイントとそれを踏まえたお勧めのソリューションとして「IBM Spectrum Protect」を紹介します。   企業を狙った標的型ランサムウェアの被害が増加中 2017年に登場し猛威を振るった「WannaCry」などのランサムウェアでは、無差別に送られる「ばらまき型」メールによって感染し、端末がロックされたユーザに対してロック解除のための身代金を要求するケースが一般的でした。 しかし、高額な身代金を支払える個人は少なく、攻撃者にとってあまりに非効率でした。 そこで攻撃者は対象を企業や団体に移し、特定のターゲットに対し下調べをしたうえで攻撃を仕掛けるようになりました。 2020年6月には、某国内大手自動車メーカーがサイバー攻撃を受け、マルウェアに感染。9つの工場で操業に影響が出ただけなく、コロナ禍でテレワーク中の従業員が社内システムにアクセス不能になるなど、深刻な事態に陥りました。 この事案では、ネットワーク偵察や感染経路の確保など入念な事前調査が行われていた可能性が指摘されており、まさに標的型ランサムウェアともいうべきものです。 結局4日をかけて工場の操業を再開したものの、その間工場の出荷が停止するなど、同社のビジネスにグローバルで大きなダメージを与えました。   サイバーセキュリティ+サイバーレジリエンスで、 ランサムウェアに多層的に対応 ランサムウェア感染の結果、製造業では前段で紹介した事例のように、工場の操業が止まることで利益損失に直結するほか、医療機関や社会インフラサービスなどが狙われると人命が危険にさらされたり、人々の生活に困難をきたすことも。 問題は、標的型攻撃の場合、マルウェアがひそかに侵入し時間をかけて機密情報の搾取を試みる間も業務継続が可能なのに対し、ランサムウェアに感染した場合、感染後にデータが暗号化されてしまうとデータの利用ができなくなり、一気に業務停止に至ることです。 このためランサムウェア対策では、インシデント発生を未然に防ぐ "サイバーセキュリティ" の対策だけでなく、発生したインシデントをいかに早く沈静化して本来の状態に戻すか、という "サイバーレジリエンス(セキュリティレジリエンス)※" のアプローチも必要です。 様々なセキュリティ対策で侵入を防ぎつつ、万が一侵入を許してデータが暗号化されてしまった場合に、その状態から迅速に復旧するための手段を備える "多層的な対策" が求められます。 ※レジリエンス=復元力、弾性   まずはデータバックアップ、さらには感染を迅速に検知する 仕組みを ランサムウェアの被害に対するサイバーレジリエンスを高める上で欠かせないのが、バックアップです。 ランサムウェアに感染しデータが暗号化されてしまうと、データ利用は不可能で、もしデータバックアップがされていなければ、もはや打つ手はありません。逆に言うと、バックアップさえあれば時間や工数はかかっても、システムを初期化するなどした上で感染前のデータに戻すことができます。 では、バックアップさえとっていればOKか?というと、必ずしもそうとは言い切れません。 ランサムウェアの感染を早いタイミングで検知できなければ、復旧に用いるバックアップデータが古い世代にものになってしまい、一定期間分のデータロストが発生するためです。 ランサムウェア対策を考えると、まずは高頻度でバックアップをとること(オフラインでバックアップデータを保管するのが望ましい)を基本とし、感染したことを早期に検知して、できるだけ新しいデータで復旧する仕組みがあるのが理想的です。   ランサムウェアの感染を "ふるまい検知" して通知。 確実な復旧を実現する「IBM Spectrum Protect」 ここからは、サイバーレジリエンスまで考慮した有望なランサムウェア対策の1つとして、データ保護ソリューション「IBM Spectrum Protect」を紹介します。 この製品(ソフトウェア)がすぐれているのは、ランサムウェアに感染したことを検知し管理者にメール通知してくれる点です。 ランサムウェアに感染すると、ファイル数やデータ量が急増する一方本来増えるはずの重複排除率が逆に減少する、といった、通常では考えられない現象が見られます。 IBM Spectrum Protect では、バックアップ対象データを統計的に分析することで、こうした平常時と異なる "ふるまい" を検知。即座に管理者へメール通知します。これによって、感染後できるだけ早期のデータ復旧が可能になります。 また、ランサムウェアによってはバックアップからの復旧を不可能にするため、バックアップデータの破壊を試みるものもありますが、IBM Spectrum Protect では、サーバーからアクセス不能な保護領域を確保し、最大500世代の増分バックアップを実現(セーフガード・コピー)。生命線ともいうべき感染前のクリーンなバックアップデータをしっかり保護し、確実なデータ復旧へと導きます。   効率的なバックアップ・アーカイブ・階層管理を実現 バックアップの対象となるクライアントと管理サーバーで構成される「IBM Spectrum Protect」は、以下のような優れた機能により、効率的なバックアップ・アーカイブ・階層管理を実現します。   1.真の永久増分バックアップで、バックアップウィンドウを最小化 定期的なバックアップデータの合成で、フルバックアップを更新する他社の永久増分バックアップと異なり、「IBM Spectrum Protect」の永久増分バックアップはフルバックアップの取得は初回のみで、その後は増加した分のバックアップだけで OK。 バックアップの合成にともなう時間とシステムリソースの消費を回避できます。さらに、複数のバックアップサーバーに存在する同一データをブロックレベルで 1つにまとめ(重複排除)、ストレージ容量の削減に貢献します。   2.高速転送機能で、低品質WAN環境でも安定的なデータ転送を実現 永久増分バックアップと重複排除により遠隔地バックアップの時間短縮を実現する「IBM Spectrum Protect」ですが、標準搭載の高速転送機能(Aspera Fast Adaptive Secure Protocol)は、海外など脆弱なWAN環境においても安定した高速転送を実現します。   3.オンプレミスだけでなく、クラウド環境も含めた統合バックアップ オンプレミス環境(物理・仮想)はもちろん、クラウド環境も含めて統合的にバックアップを管理できます。 しかも、上りのデータ転送料が無料というメリットを活かし、長期保存のデータをクラウドにバックアップ(アーカイブ)したり、オンプレミス←→クラウド間のレプリケーションで DR環境を構築する、といった活用シナリオに対応します。   このほか「IBM Spectrum Protect」は、バックアップ対象の複数サーバーを単一ダッシュボードから統合管理できるオペレーションズ・センターを提供。 管理者は場所を問わず、必要な時にブラウザ上で各種バックアップの実行や健全性の確認などが可能。「コロナ禍で、バックアップのために出社するのは避けたい」「リモートでバックアップ状況を把握・管理したい」といったニーズにも対応します。 ランサムウェアの対策として、またニューノーマル対応のデータ保全・バックアップ対策として、この機会に「IBM Spectrum Protect」を検討してみてはいかがでしょう。     この記事に関するお問合せ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは、「こちら」からお願いします。   参考情報 (製品情報)IBM Spectrum Protect (コラム)DRで考えるべきITシステム復旧の3つの指標と、実現方法を解説。BCPとの違いは?効率的な対策は? (ブログ)データを守るということについて  

2021年03月08日

ハイブリッド/マルチクラウドの環境に最適なセキュリティ基盤 「IBM Cloud Pak for Security」の3つの価値

DX の推進にともない企業が利用するクラウド環境は拡大し、システムやアプリケーションはこれまで以上に複雑化しています。 これによって、現状でも充足していないとされるセキュリティ担当者の仕事は多忙を極めています。また、リソースをさらに増強するのが難しいため、セキュリティリスクは高まる懸念があります。 本記事では、ハイブリッド/マルチクラウド環境でのセキュリティの課題とその対策について考察します。   サイロ型の運用では困難になった、 複雑な IT環境のセキュリティインシデント対応 これまでの企業のセキュリティ対策方法は、異なるベンダーの検知・防御のためのセキュリティ製品やソリューションを複数導入し、それぞれで運用管理していました。 しかしこの方法ではツールが増えすぎて収拾がつかないばかりか、ツールとログの断片化と分断化が進み「セキュリティサイロ」が生じてしまいます。また、導入しているセキュリティ製品やソリューションも単体機能ではセキュリティ保護に貢献するものの、相互に連携することができなければ企業全体を一貫したポリシーでIT環境を守ることが難しくなり、より高度なセキュリティ脅威の検知をすることは極めて困難です。 特に IT環境のクラウドへの移行が進んでいる現状においては、オンプレミス環境だけでなくクラウド環境のログも収集しセキュリティ保護対象とする必要があるため、すべて人力で対応をすることが現実的ではありません。 この問題に対処し、高度な脅威を検出・対応するために大企業などを中心に導入されているのが、ログを一元管理し相関分析することでインシデントになりうる脅威を検知する「SIEM*」製品です。 SIEM製品によって、今まで検知できなかったセキュリティ脅威を検知することができるようになりますが、インシデントが発生した後の対応までを自動化・効率化できないため、インシデントの状況把握や調査、対応にかかる時間が長くなり、解決までに時間がかかることが課題となっています。 *SIEM(Security Information and Event Management : セキュリティ情報・イベント管理)   セキュリティ製品の情報を一元的に探索する 「IBM Cloud Pak for Security」 ハイブリッド/マルチクラウド環境全体で脅威に対するより深い洞察を得るために、既存のセキュリティ・ツールをより迅速に統合できるように支援するのが、ソフトウェア・プラットフォーム「IBM Cloud Pak for Security (以下 ICP for Security )」です。 ICP for Security は、世界中で 1,000 以上の組織によってすでに採用されている Red Hat OpenShift エンタープライズ・アプリケーション・プラットフォームを含むコンテナ化されたソフトウェアで構成されます。 ICP for Security は、オンプレミスやパブリック/プライベートクラウドが混在する複雑な IT 環境下でも、様々なログやデータソースに1つの画面から「横串通し」にアクセスすることができます。 そのため、セキュリティ製品からログやデータを移動する必要はありません。複数の SIEM、エンドポイント検出システム、脅威インテリジェンス・サービス、IDリポジトリー、クラウド・リポジトリーなどのサード・パーティー製ツールとデータソースに ICP for Security を接続し、アクセスすることができます。 それにより、企業内のサイロ化されたすべてのセキュリティ・ツールのデータから「セキュリティリスクの検出」、「インシデントの発見と通知」、「脅威に対する詳細な分析情報の作成」、「対処方法の洗い出し」、「修復の自動化」など、インシデントの状況把握と調査、およびその対応を単一のコンソールで、かつ省力化して実行することが可能です。   ICP for Security の3つの価値 ICP for Security を導入することで得られる価値を3つに絞って紹介します。   1.脅威インテリジェンスによるセキュリティ脅威への対応の迅速化 複数のフィード、プラットフォーム、およびそれを使用する他のソースなどが脅威インテリジェンスとして世の中に存在していますが、自身に最も重要なものを探すためにふるい分けるのは簡単ではありません。 Threat Intelligence Insights では、組織との関連性によって優先順位付けされた実用的な脅威インテリジェンスを使用し、環境をスキャンして影響を受けているかどうかを確認できます。 また、各脅威がどの程度関連しているかを簡単に確認でき、「影響を受けているかどうかの確認」ツールを使用すると、接続されたデータソースの手動または自動スキャンを実行できます。 環境内で脅威が見つかった場合はケースを自動的に作成して、さらに調査を進めることができます。 これにより、脅威を検知しその対応を進めることができるようになるのです。   2.隠れている脅威を見つけ出し、リスク・ベースの意思決定力を向上 今までは統合ログストレージへデータを収集し分析することが主流でしたが、ICP for Security が構築するセキュリティ・エコシステムは統合ログストレージへデータを集めません。逆に ICP for Security から各種データソースにアクセスすることで、最新のログを対象にした高速検索を可能にしています(フェデレーション検索)。 セキュリティ管理者は「Data Explorer」から IPアドレスや URL、ハッシュ値、IoC* などの条件を指定して検索するだけで、個々のツールやシステムにアクセスする必要がなく、接続しているシステムやツールのデータソースから必要な情報を迅速に探し出すことができ、関連性を発見しインシデントへの対応を速やかに実施することができるようになります。 *IoC (Indicators of Compromise) : 侵害指標、痕跡情報、脅威のインディケーター   3.ナレッジを共有し、脅威への対応力の強化と修正時間の短縮を実現 ICP for Security はインシデントへの迅速な対応を支援するため、統一されたインターフェースによってクライアント・ワークフローに接続し、セキュリティ対応の調整および自動化することが可能です。 また、ワークフロー機能にはインシデントの発生状況や調査結果、その対応履歴を記録する「インシデント管理」ソリューションも含まれています。過去のインシデント対応の記録を参考にすることで、インシデント発生時の対応を効率化できます。 このワークフロー機能を使用することにより、チーム内でのナレッジの共有とともに属人性を排することが可能に。インシデント対応プロセスの高度化による複雑なサイバー脅威への対応力の強化と修正時間の短縮を実現して、チームがセキュリティに割ける時間を増やすことができます。   統合プラットフォームへのシフトを支援する IBM のアプローチ セキュリティリスクは、実際に発生した場合、甚大な影響と莫大な損害を企業や組織に与えます。 そのため、多くの企業や組織が最新の脅威への対応に新しいセキュリティ・テクノロジーを迅速に導入します。また、分断されてうまく相互機能しない複数のツールをなんとかやりくりします。 今後ハイブリッド/マルチクラウド環境の拡大とともにインシデントの脅威が高まる中で、連携しない複数のツールを使い続けることにより生じる問題を解決するためには、よりオープンなテクノロジーと各ツールをつなぎあわせることができる統合プラットフォームにシフトすることが必要です。 ICP for Security のアプローチはまさにこの要件に合致しており、単一の簡素化されたインターフェース内にセキュリティ・スタックのすべての層をまとめられる可能性を持っています。 ICP for Security は、オンプレミス、プライベート、およびパブリッククラウドなど、どこでも実行できるため、様々な環境下にあるソースから大量のセキュリティ・データを把握するのに有効なソリューションです。 オープン・テクノロジーをベースとするソリューションを使用することで、すでに使用しているツールへオープンに接続でき、相互運用性を促進します。 また、一元化された統合検索機能と統合インシデント管理機能は、状況把握や調査・分析、具体的な対応の効率向上につながるだけでなく、データを複数のツールで効率的な分析ができるように均質化するため、既存のツールの利用率も上がります。 さらに、8,000名を超える専門家と10ヵ所の研究開発拠点を擁する世界最大規模のセキュリティ・エキスパート集団「X-Force」による最新の脅威情報や、セキュリティトレンドを提供されることも、ICP for Security 利用の大きなメリットの1つです。 これまで各企業はセキュリティ・データを1ヵ所に集めようと努力してきましたが、すべての情報ソースを網羅した最新情報のアップデートを維持することは難しく、セキュリティ・チームはさらにデータの移動に時間とお金を費やす結果となりました。 この現象はマルチクラウドの世界ではますます顕著となり、セキュリティ・チームにはさらに大きな負担となるため、迅速な対応を難しくさせます。 しかし、セキュリティ・データを保管場所から移動させる必要がない ICP for Security を利用すれば、投資をさらに活用し、従来は網羅できなかった情報ソースに隠れていた脅威を確認して、より良いリスク・ベースの意思決定を行うことも可能になるのです。   DX の進化を支える基盤 - IBM Cloud Paks レガシーシステムの問題点を解決し、オープンなコンテナ技術によるアプリの可搬性の向上とオープンなオーケストレーションによる管理・運用の効率化を実現するのが、プラットフォームを最適化する IBM のソリューション「IBM Cloud Paks」です。 IBM Cloud Paks は、エンタープライズにおけるユースケース別に6製品をオンプレミス、プライベートクラウド、パブリッククラウド、エッジ・コンピューティングと同じアーキテクチャーで提供しており、これらを活用していくことでモダナイゼーションを効率的に進めていくことができます。 また、企業固有のアプリケーション、データ、ワークロードの要件に対応する最適なアーキテクチャーと手法を選択できます。 IBM のハイブリッド・マルチクラウド・プラットフォームは、Linux や Kubernetes などのオープン・テクノロジーに基づいているため、選択したクラウド上でデータやアプリケーションを安全に展開・実行・管理でき、将来にわたってロックインされるリスクもありません。     この記事に関するお問合せ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは、「こちら」からお願いします。   参考情報 (製品情報) IBM Cloud Pak for Security (資料) IBM IBM Cloud Pak for Security 製品 (資料) IBM Cloud Paks シリーズ ご紹介資料 (資料) サイバー脅威対応製品アップデート (IBMサイト) IBM Cloud Pak for Security  

2021年02月19日

ハイブリッド/マルチクラウド環境の効率的な管理を実現し、クラウドのメリットを最大化する「IBM Cloud Pak for Multicloud Management」

今後の基幹業務システムは、クラウド化・コンテナ化が進み、オンプレミス、クラウドを問わず稼働します。 クラウド環境とオンプレミス環境/プライベートクラウドを併用するハイブリッドクラウド、もしくは複数のクラウド環境を併用するマルチクラウドで稼働する企業システムの一元管理を実現するためには、従来の SoR* のシステム、およびクラウド・ネイティブな SoE*システムを、シンプルに統合管理していくことが必要になります。 この記事では、複雑化するマルチクラウド管理の現状を解説するとともに、ハイブリッド・マルチクラウド環境に対応し、効率的に IT基盤を管理する「IBM Cloud Pak for Multicloud Management」をご紹介します。 *SoR (System of Records): 「記録のためのシステム」の意味。社内に従来から存在する分断化されたレガシーシステム。 *SoE (System of Engagement): 顧客とのつながりを作り・維持し、絆を生むために、顧客視点をもとに構築した新しいITシステム。   これからのIT基盤管理における中核は、 ハイブリッド/マルチクラウドの統合管理 業務の効率化・生産性向上の実現を目的としたクラウド・ベースのサービスを利用するために、オンプレミス環境だけに留まらず、ハイブリッドクラウド、もしくはマルチクラウドを活用する企業が急増しています。 ところが、戦略的にハイブリッド/マルチクラウド環境を活用している企業はあるものの、効率的な管理ができている企業はまだ限られているのが現状です。 オンプレミス環境だけではなく、ハイブリッドクラウドやマルチクラウドを積極的に活用する "ハイブリッド/マルチクラウド戦略" は、プライベートクラウドとパブリッククラウド双方の最も良い点を組み合わせるため、莫大な価値を企業にもたらします。 一方で、この複雑なハイブリッド/マルチクラウド環境には、混在するアプリケーションやシステム基盤およびデータ、複数のクラウドと複数ベンダー、そしてクラウド・テクノロジーには、それぞれベンダー独自の運用・管理ツールを利用する必要があります。 それぞれの環境が独立した管理となるため、クラウドのコストと管理の最適化を運用管理上の大きな課題として挙げる管理者も少なくありません。 これからマルチクラウド環境の導入を検討している方は、複数の環境を管理することが必要となること、また、この課題を解決する必要があることを理解しなくてはなりません。 ハイブリッド/マルチクラウド環境を効率的に管理するには、最適なパフォーマンスと利便性を維持しながらコストをコントロールできるだけでなく、セキュリティも保護できなければなりません。また、ハイブリッドクラウドの要件に合わせて、オンプレミスのレガシー・ネットワークを改良する必要もあります。 クラウド環境との効率的な連携を実現するためのネットワークには、信頼性・柔軟性・拡張性・安全性が求められます。運用負荷の軽減と柔軟性の確保を目的に、仮想化および自動化テクノロジーを活用しネットワークの管理を簡素化することで、更なる運用効率の向上を検討する必要がでてきます。 つまり、基幹業務のクラウド化・コンテナ化が進み、オンプレミス、クラウドを問わず複雑なハイブリッド/マルチクラウド環境を活用する今日の企業がこれらの課題を解決するためには、企業システムが稼働する環境を効率的に管理する「一元管理」の実現が必要なのです。 例えば、どの環境でどのアプリケーションが稼働しているのか、そのアプリケーションの負荷がどの程度なのか、を把握しコントロールすることで、アプリケーションの負荷を最適化し、無駄なアプリケーションの稼働を削減することができます。 それによってクラウド環境で利用するリソースを最適化できるため、コスト削減につながります。 今回ご紹介するようなオールインワンのハイブリッド/マルチクラウド管理ソリューションは、管理コストを削減するだけでなく、環境の選択肢を拡大します。 また、セキュリティとガバナンスを向上させ、ワークロードごとのニーズに基づいた柔軟なアプリケーション展開を可能にします。   ハイブリッド/マルチクラウド環境の統合管理ソリューション「IBM Cloud Pak for Multicloud Management」 「IBM Cloud Pak for Multicloud Management (以下、ICP4 MCM)」は、Red Hat OpenShift 上で稼動し、ハイブリッド/マルチクラウド環境を統合管理するソリューションです。 ICP4 MCM は、ハイブリッド/マルチクラウド環境全体にわたって複数の kubernetesクラスタを統合管理し、ガバナンスの強化、VM/コンテナ基盤のプロビジョニングの自動化、および共通化を提供します。 さらにアプリケーション展開後には複数のソースからのイベントを統合し、SoR/SoE 問わず統合モニタリングを実施することで障害の解決を速やかに行うことができ、可用性の向上にも寄与します。   ICP4 MCMの3つの価値 ICP4 MCM の機能は大きく「インフラ管理」「マルチクラスタ―管理」「イベント管理/アプリケーション管理」の3つに分けられます。 概要は以下の図になります。 これらの機能も含めて、ICP4 MCM が提供する価値は大きく以下の3つです。 ハイブリッド/マルチクラウド環境への仮想マシン/コンテナの迅速な展開 (「インフラ管理」「マルチクラスタ―管理」機能) イベント統合・統合モニタリングによる問題判別と解決スピードの向上 (「イベント管理/アプリケーション管理」機能) オープン・テクノロジーのサポートを提供するマルチクラウド運用管理基盤 (IBMによるサポート) それぞれについて説明をしていきます。   1.ハイブリッド/マルチクラウド環境への仮想マシン/コンテナの 迅速な展開 ICP4 MCM は、オンプレミスやプライベートクラウド、パブリッククラウドを併用するハイブリッド/マルチクラウド環境において、仮想マシン/コンテナの展開を自動化することでサーバーの構築作業を最小限にし、アプリケーションの展開を素早く実施できます。 仮想マシンの展開はテンプレートから行うため、同じアプリケーションを複数の環境(例えば、オンプレミス環境と IBM Cloud環境それぞれ)へ展開することができます。コンテナ環境においては、複数の kubernetesクラスタを統合管理することができるため、クラスタをまたがったアプリケーションの一貫したデプロイ、アップデート、管理を実現でき、リソース効率を最大化します。 アプリケーションの展開を速めることで、お客様の DX がより円滑に進められるようになります。   2.イベント統合・統合モニタリングによる問題判別と解決スピードの 向上 ICP4 MCM は、ハイブリッド/マルチクラウド環境で発生するイベントを統合し、イベント/インシデントの相関処理・優先順位付けを行うことで、環境が複雑になるのに従い長期化しやすくなっている障害対応を迅速化します。 また、アラート通知の自動化やタスクの自動化機能により、繰り返し発生する問題を解決するための工数を削減します。   3.オープン・テクノロジーのサポートを提供するマルチクラウド 運用管理基盤 ICP4 MCM は、VM およびコンテナ基盤のライフサイクルを一元管理するためのオープン・テクノロジーを IBM のサポート付きで利用できます。 ICP4 MCM のすべての管理コンポーネントはコンテナ対応済みで、Red Hat OpenShift 上で稼働するために最適化されています。 また、これらのコンテナは Red Hat で認定済みであることに加えて、IBM 認定済みのソフトウェアとして事前統合されており、IBM がサポートをするので安心して利用することができます。   このように、全社レベルでクラスタを統合管理し、アプリケーション展開速度の向上や問題対応に活用することで、ICP4 MCM はお客様のIT管理とモダナイゼーションを支援します。 また、ハイブリッド/マルチクラウドの環境を一貫した構成と共通のセキュリティ・ポリシーで管理し、オンプレとクラウドに同じ基準・ルールを適用することで、既存のレガシーシステムの運用に加えて新規のクラウド・ネイティブ技術ベースのアプリケーションも統合的に管理することが可能となり、コストを削減することも可能です。 さらに、アプリケーションの実行環境が必要なときにも、従来は数日から数週間かかっていたのに対し、即日(場合によっては数分程度)で環境を手に入れることができるのです。   *DXの進化を支える基盤- IBM Cloud Paks* レガシーシステムの問題点を解決し、オープンなコンテナ技術によるアプリの可搬性の向上とオープンなオーケストレーションによる管理・運用の効率化を実現するのが、プラットフォームを最適化するIBM のソリューション「IBM Cloud Paks」です。 IBM Cloud Paksは、エンタープライズにおけるユースケース別に6製品を、オンプレミス、プライベートクラウド、パブリッククラウド、エッジ・コンピューティングと同じアーキテクチャーで提供しており、これらを活用していくことで、モダナイゼーションを効率的に進めていくことができます。 また、企業固有のアプリケーション、データ、ワークロードの要件に対応する、最適なアーキテクチャーと手法を選択できます。IBMのハイブリッド・マルチクラウド・プラットフォームは、Linux や kubernetes などのオープン・テクノロジーに基づいているため、選択したクラウド上でデータやアプリケーションを、安全に展開・実行・管理でき、将来にわたってロックインされるリスクもありません。     この記事に関するお問合せ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは、「こちら」からお願いします。   参考情報 (製品情報) IBM Cloud Pak for Multicloud Management (資料) IBM Cloud Pak for Multicloud Management のご紹介 (資料) IBM Cloud Paks シリーズ ご紹介資料 (IBMサイト) IBM Cloud Pak for Multicloud Management  

back to top