*IBM Feed

2019/01/16

IBM Cloud Private 3.1.1 Workerを追加してみよう(x86 Linux版)

WorkerはKubernetesでいうところの Node になります。
Knowledge centerは下記のように説明されています。

ワーカー・ノードは、タスクを実行するためのコンテナー化された環境を提供するノードです。 要求の増加に伴い、ワーカー・ノードをクラスターに簡単に追加して、パフォーマンスおよび効率性を向上させることができます。 1 つのクラスターには任意の数のワーカー・ノードを含めることができますが、少なくとも 1 つのワーカー・ノードが必要です。

"簡単に追加"とあるのでさっそく簡単に追加してみましょう。

既存環境

VAの追加と同じ環境です。
サーバースペックは同じもので2台のサーバーがあります。

OS RedHat Endterprise Linux 7.4
物理/仮想 仮想
CPU(Core) 8
Memory 24GB
Disk 300GB
NIC 1つ

Master ServerとWorker Serverが1台ずつあります。 ICPのバージョンは3.1.1になります。

以前、投稿した手順は3.1.0になります。3.1.1でも同様の手順でインストールできます。
また、この手順は3.1.0でも同様の作業内容になりますので、記載されているバイナリ名や、設定名等、 3.1.1 となっている部分は 3.1.0 と読み替えて手順を実施してください。

事前準備

WorkerやVAにするノードを準備します。
今回も既存環境と同じスペックのRHELの仮想マシンと同じものを用意します。

※Workerは x86_64 のLinuxサーバーだけでなく、Linux on Power や Linux on IBM Z でも動作させることができます。 動作環境の詳細は下記をご参照ください。
https://www.ibm.com/support/knowledgecenter/en/SSBS6K_3.1.1/supported_system_config/supported_os.html

追加するノード

追加するノードは下記になります。

Host name IP 作業ユーザー 追加するノードの種類
icp-poc-workeradd1.icp.local xxx.xxx.xxx.167 root Worker

追加ノードで行う作業

追加ノードで行う作業はVAの追加と同じです。 追加するノードでは下記の事を行います。

  1. 通信ポートの確認
  2. SE Linux の無効化、Firewallの無効化
  3. /etc/hostsを設定
  4. 時刻の同期
  5. Python のインストール(の確認)
  6. Dockerのインストール
  7. (後から作業) sshサービスの再起動

通信ポートの確認

下記コマンドを実行してなにも表示されないことを確認します。
ss -tnlp | awk '{print $4}' | egrep -w "8001|8500|3306"

SE Linux の無効化、Firewallの無効化

SE LinuxとFirewallを無効化します。
SE Linuxは /etc/selinux/config をdisableに変更します。
Firewallは下記のコマンドを実行します。

systemctl stop firewalld systemctl disable firewalld

/etc/hostsを設定

クラスターに存在するすべてのノード(Master/Worker/VA/Management/Proxy)を /etc/hosts に指定します。

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 xxx.xxx.xxx.161 icp-poc-master1.icp.local
xxx.xxx.xxx.164 icp-poc-worker1.icp.local

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 xxx.xxx.xxx.161 icp-poc-master1.icp.local
xxx.xxx.xxx.164 icp-poc-worker1.icp.local
xxx.xxx.xxx.167 icp-poc-workeradd1.icp.local

 
時刻の同期

追加するノードと既存のサーバー群と時刻の差が出ないように時刻同期を行います。
時刻同期方法は各Linuxのドキュメントをご確認ください。

RHELで時刻、時刻同期の設定の確認は下記コマンドでできます。

# timedatectl
Local time: Tue 2019-01-08 11:01:18 JST
Universal time: Tue 2019-01-08 02:01:18 UTC
RTC time: Tue 2019-01-08 02:01:17
Time zone: Asia/Tokyo (JST, +0900)
NTP enabled: n/a
NTP synchronized: no
RTC in local TZ: no
DST active: n/a
 

Python のインストール(の確認)

Pythonがインストールされていることを確認します。

# python --version
Python 2.7.5

サポートされているPythonのバージョンは、2.6,2.7,3.5以上になります。

Dockerのインストール

Dockerをインストールします。DockerのバイナリーはIBM社から提供されています。

  • IBM Cloud Private 3.1.1 Docker for Linux (x86_64) (CNXD2EN )
    size: 141MB

このファイルをノード上にコピーし実行します。

cd /(ファイルをコピーした場所) ./icp-docker-18.03.1_x86_64.bin --install

※このとき、内部で別のコンポーネントをyumでインストールします。

dockerが自動起動されるように設定します。

systemctl start docker
systemctl enable docker

(後から作業) sshサービスの再起動

既存のMaster ServerからSSH Keyをコピーした後にSSH Serviceの再起動を行います。
後述の手順内で再度ご案内します。


Master Serverで行う作業

実際のインストール作業については既存のMaster Serverから行います。

  • SSH Keyのコピー
  • (後から作業) sshサービスの再起動
  • バイナリーファイルの確認
  • Workerの追加

SSH Keyのコピー

Master Server上からノードにSSH Keyをコピーします。

ssh-copy-id -i ~/.ssh/id_rsa.pub <user>@<node_ip_address>

今回は、下記の情報を使ってコマンドを実行します。

user node_ip_address
root xxx.xxx.xxx.167
ssh-copy-id -i ~/.ssh/id_rsa.pub root@xxx.xxx.xxx.167

!!!ノードで作業!!! sshサービスの再起動

ノード上でSSH Serviceを再起動します。

systemctl restart sshd 

バイナリーファイルの確認

下記にLinux用のバイナリーファイルがあることを確認します。
インストールパスを変更している場合は適宜読み替えてください。

Path File name
/opt/ibm-cloud-private-3.1.1/cluster/images ibm-cloud-private-x86_64-3.1.1.tar.gz

コマンド

# ls /opt/ibm-cloud-private-3.1.1/cluster/images
ibm-cloud-private-x86_64-3.1.1.tar.gz

Workerの追加

Workerの追加は下記のコマンドを参考に実行します。

docker run -e LICENSE=accept --net=host \
-v "$(pwd)":/installer/cluster \
ibmcom/icp-inception-$(uname -m | sed 's/x86_64/amd64/g'):3.1.1-ee worker -l \
ip_address_workernode1,ip_address_workernode2

IPアドレス xxx.xxx.xxx.167 をWorkerとして追加しますので、実行するコマンドは下記になります。

cd /opt/ibm-cloud-private-3.1.1/cluster
docker run -e LICENSE=accept --net=host \
-v "$(pwd)":/installer/cluster \
ibmcom/icp-inception-$(uname -m | sed 's/x86_64/amd64/g'):3.1.1-ee worker -l \
xxx.xxx.xxx.167

これでWorkerの追加は完了です!追加の流れはVAの追加とほとんど変わりません。VAの追加よりも簡単です。
事前準備さえできればすぐ追加できます。

次に本当に追加されているかと動作を簡単に確認してみたいと思います。

管理コンソール上での確認

管理コンソールのメニューから[プラットホーム]-[ノード]とたどっていただくと登録されているノードが表示されます。
ここでWorkerとして追加したノードが表示されていることを確認できます。

20190111_17h21_59a

動作確認

次に実際にPodが追加したWorker上にスケジュール(動作)するか確認してみます。
※ KubernetesではPodのスケジューリングはWorker上の負荷を考慮して自動的に行われます。
このテストでは新しいWorkerに配置されてほしいので、Podが特定のWorkerに配置されるように仕込みをしたyamlファイルでデプロイします。

ラベルの作成

追加した Worker にラベルを付与し、そのラベルをもつWorkerに対してPodをデプロイするように指定します。

ICP MasterサーバーにSSHでログインし、Kubernetes Clusterにログインします。

# cloudctl login -a https://mycluster.icp:8443 --skip-ssl-validation
Username> admin
Password>
Authenticating...
OK
Targeted account mycluster Account (id-mycluster-account)
Select a namespace:
1. cert-manager
2. default
3. ibmcom
4. istio-system
5. kube-public
6. kube-system
7. microclimate-pipeline-deployments
8. microclimate-space
9. platform
10. services
Enter a number> 6
Targeted namespace kube-system
Configuring kubectl ...
Property "clusters.mycluster" unset.
Property "users.mycluster-user" unset.
Property "contexts.mycluster-context" unset.
Cluster "mycluster" set.
User "mycluster-user" set.
Context "mycluster-context" created.
Switched to context "mycluster-context".
OK
Configuring helm: /root/.helm
OK

※クラスター名を mycluster.icpから変更している場合は変更した値で実行してください。

Workerのリストを確認します。

# kubectl get nodes
NAME STATUS ROLES AGE VERSION
xxx.xxx.xxx.161 Ready etcd,management,master,proxy 5d v1.11.3+icpee
xxx.xxx.xxx.164 Ready worker 5d v1.11.3+icpee
xxx.xxx.xxx.167 Ready worker 3d v1.11.3+icpee

追加したWorkerは xxx.xxx.xxx.167 になりますので、このNodeに対してラベルを付与します。
付与するラベルは workertest=deploy としています。

# kubectl label node xxx.xxx.xxx.167 workertest=deploy

ラベルを確認します。

# kubectl -L=workertest get nodes
NAME   STATUS ROLES AGE VERSION WORKERTEST
xxx.xxx.xxx.161 Ready etcd,management,master,proxy 5d v1.11.3+icpee  
xxx.xxx.xxx.164 Ready worker 5d v1.11.3+icpee  
xxx.xxx.xxx.167 Ready worker 5d v1.11.3+icpee deploy

xxx.xxx.xxx.167 にラベルの値 deploy が付与されていることを確認します。

yamlファイルの作成

次にyamlファイルを2つ作成します。

  • ファイル名 : test-all.yaml
  • ファイル名 : test-add_only.yaml

それぞれの用途は下記になります。

ファイル名 用途
test-all.yaml すべてのWorkerを対象としてPodをデプロイ
test-add_only.yaml 追加したWorkerに対してだけPodをデプロイ

この2つのYamlを使って、追加したWorkerが利用できることと、既存のWorkerと一緒に動作し分散されることを確認します。

test-all.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: allnode-deployment
  spec:
    replicas: 5
    selector:
      matchLabels:
        app: allnode
    template:
      metadata:
        labels:
          app: allnode
      spec:
        containers:
          - name: nginx-container
            image: nginx:latest
            ports:
              - containerPort: 80

test-add_only.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: workeraddtest-deployment
spec:
  replicas: 5
  selector:
    matchLabels:
      app: addworkeronly
  template:
    metadata:
    labels:
      app: addworkeronly
    spec:
      containers:
        - name: nginx-container
          image: nginx:latest
          ports:
            - containerPort: 80
      nodeSelector:
        workertest: deploy

deploymentの作成

yamlファイルからDeploymentを作成します。

NameSpace(名前空間)を default に変更します。

# cloudctl login -a https://mycluster.icp:8443 -n default --skip-ssl-validation

Username> admin
Password>
Authenticating...
OK
Targeted account mycluster Account (id-mycluster-account)
Targeted namespace default
Configuring kubectl ...
Property "clusters.mycluster" unset.
Property "users.mycluster-user" unset.
Property "contexts.mycluster-context" unset.
Cluster "mycluster" set.
User "mycluster-user" set.
Context "mycluster-context" created.
Switched to context "mycluster-context".
OK
Configuring helm: /root/.helm
OK

PodやDeploymentが存在しないことを確認します。

# kubectl get deployments
No resources found.
# kubectl get pods
No resources found.

追加したWorkerにデプロイ

追加したWorkerにだけデプロイするyaml (test-add_only.yaml)をデプロイします。

# kubectl apply -f test-add_only.yaml
deployment.apps/allnode-deployment created

Deploymentが作成されていることを確認します。

# kubectl get deployment

20190115_14h27_35

Podを確認します。

# kubectl get pods -o wide

20190115_14h28_19a

NODEの値がすべて xxx.xxx.xxx.167 となっており、すべてのPodが追加されたWorker上で動作しています。

すべてのWorkerにデプロイ

最後にデプロイするWorkerを指定していない yamlファイルからDeploymentを作成し、ICPが自動でWorkerを分散してPodを作成することを確認します。

# kubectl apply -f test-all.yaml
deployment.apps/allnode-deployment created

Deploymentが作成されていることを確認します。

# kubectl get deployment

20190115_14h29_35

Podを確認します。

# kubectl get pods -o wide

20190115_14h29_52a_2

allnode-で始まるPodがすべてのWorkerにデプロイする設定としたPodです。
NODEの値に xxx.xxx.xxx.164 がありますので、既存であったWorkerと追加したWorkerどちらも利用してデプロイしていることが確認できます。

今回は以上になります。
後半の動作確認でいくつか実施していることがありますが、Workerの追加だけであればかなりシンプルに実施できることを実感していただけるかと思います。

動作確認で利用したyamlファイルは下記になります。  

(毎度の)最後に

IBM Cloud PrivateのPoC環境の貸し出しも実施しています。

https://www.networld.co.jp/product/ibm-hardware/trial/

Worker追加用の仮想マシンの用意もできますのでぜひぜひご利用ください。

すずきけ

2019/01/15

IBM Cloud Private 3.1.1 Microclimateのインストール

皆さん、CI/CDツールは何を利用されていますでしょうか?
IBM Cloud Privateはエンドツーエンドの開発環境であるMicroclimateの動作環境として対応しています。

https://Microclimate-dev2ops.github.io/

Microclimate is an end to end development environment that lets you rapidly create, edit, and deploy applications. Applications are run in containers from day one and can be delivered into production on Kubernetes through an automated DevOps pipeline using Jenkins. Microclimate can be installed locally or on IBM Cloud Private, and currently supports Java, Node.js, and Swift.

IBM Cloud Private上のHelmのカタログにもMicroclimateがあるか見てみますと・・・

20190110_13h32_22a

ありました!

あるなら動かしてみよう!の精神で今回はMicroclimateをインストール(デプロイ)してみます。

 

参考URL:

https://www.ibm.com/support/knowledgecenter/ja/SSBS6K_3.1.0/featured_applications/Microclimate.html
https://github.com/IBM/charts/blob/master/stable/ibm-Microclimate/README.md

 

テストした環境

サーバーは全部で3台用意します。

  • ICP Master Server
  • ICP Worker Server
  • NFS Server

 

Master / Worker Serverのスペック

OS RedHat Endterprise Linux 7.4
物理/仮想 仮想
CPU(Core) 8
Memory 24GB
Disk 300GB
NIC 1つ

 

NFS Serverの領域

Persistent Volumeとして20GB以上ご用意ください。
今回はCent OSを用意し、NFS Serverとして稼働させています。

ICP Version

ICPのバージョンは3.1.1になります。

ICPの構築

こちらを参考に構築してください。

Microclimateインストール手順概要

  1. Name Space の作成
  2. Microclimate PiplineのName Spaceの作成
  3. Cluster_CA_Domainの確認
  4. Cluster Image Policyの作成
  5. Microclimate registry secret の作成
  6. Helmで利用するSecretの作成
  7. Microclimate pipeline secretの作成
  8. Ingress Domain Name の作成(今回はHostsで逃げます)
  9. Helmからインストール
  10. Persistent Volumeの作成

github上のドキュメントでは、9.と10.が逆ですが、動きがわかりやすいようにこの順番でインストールを行っていきます。

 

 

Install !!

コマンド実行の作業はMaster Server上にSSH等でログインし実行します。

 

1. Name Space の作成

ICPではDefaultというNameSpace(ICPのGUI上では「名前空間」)が用意されていますが、Microclimate用に用意する必要があります。
GUI、コマンドどちらからでも設定できます。

NameSpace名は microclimate-space としています。

GUI

GUIから作成する場合は、ICP管理コンソールにログインし、メニューの[管理]-[名前空間]から作成します。
名前は任意となり、「ポッド・セキュリティ・ポリシー」では ibm-restricted-psp を選択してください。

コマンド

コマンドで設定する場合は以下になります。

※最初にICPクラスタにログインします。

cloudctl login -a https://<your-cluster-ip>:8443 -n kube-system --skip-ssl-validation 

ユーザー名: admin パスワード: admin

次に作成のコマンドを実行します。

kubectl create namespace <namespace name>

今回は名前を microclimate-space にします。

kubectl create namespace microclimate-space

作成したNameSpaceで作業するように変更します。

cloudctl login -a https://<your-cluster-ip>:8443 -n microclimate-space --skip-ssl-validation


2. Microclimate PiplineのName Spaceの作成

1.と同様にNameSpaceを作成します。

kubectl create namespace microclimate-pipeline-deployments

名前は変えず、このまま使います。 GUIで作成する場合も同様に作成します。「ポッド・セキュリティ・ポリシー」もibm-restricted-psp で問題ありません。


3. Cluster_CA_Domainの確認

これはインストール時に決まっています。Config.yamlで特に指定していなければ、 mycluster.icpがドメインになります。

設定値はConfig.yamlに記載されています。
下記のコマンドで確認できます。

cat /opt/ibm-cloud-private-3.1.1/cluster/config.yaml | grep cluster_name
# cluster_name: mycluster
# cluster_CA_domain: "{{ cluster_name }}.icp"


4. Cluster Image Policyの作成

ICPではデフォルトで取得できるDocker.ioのイメージがポリシーで設定されています。
MicroclimateのDockerイメージを取得できるように、ポリシーを追加します。

追加する前に 既存のポリシー を確認します。

ポリシーのリストを確認

kubectl get ClusterImagePolicy

結果

NAME AGE
ibmcloud-default-cluster-image-policy 1d
 

ポリシーの詳細を確認

kubectl describe ClusterImagePolicy ibmcloud-default-cluster-image-policy

Name: ibmcloud-default-cluster-image-policy
Namespace:
Labels: <none>
Annotations: <none>
API Version: securityenforcement.admission.cloud.ibm.com/v1beta1
Kind: ClusterImagePolicy
Metadata:
Creation Timestamp: 2018-12-25T08:27:11Z
Generation: 1
Resource Version: 3254
Self Link:
/apis/securityenforcement.admission.cloud.ibm.com/v1beta1/clusterimagepolicies/ibm
cloud-default-cluster-image-policy
UID: e00ff4c7-081e-11e9-8cff-00505687010b
Spec:
Repositories:
Name: mycluster.icp:8500/*
Name: registry.bluemix.net/ibm/*
Name: docker.io/ppc64le/*
Name: docker.io/amd64/busybox*
Name: docker.io/vault:*
Name: docker.io/consul:*
Name: docker.io/python:*
Name: docker.io/centos:*
Name: docker.io/postgres:*
Name: docker.io/hybridcloudibm/*
Name: docker.io/ibmcom/*
Name: docker.io/db2eventstore/*
Name: docker.io/icpdashdb/*
Name: docker.io/store/ibmcorp/*
Name: docker.io/alpine*
Name: docker.io/busybox*
Name: docker.io/dduportal/bats:*
Name: docker.io/cassandra:*
Name: docker.io/haproxy:*
Name: docker.io/hazelcast/hazelcast:*
Name: docker.io/library/busybox:*
Name: docker.io/minio/mc:*
Name: docker.io/minio/minio:*
Name: docker.io/nginx:*
Name: docker.io/open-liberty:*
Name: docker.io/rabbitmq:*
Name: docker.io/radial/busyboxplus:*
Name: docker.io/ubuntu*
Name: docker.io/websphere-liberty:*
Name: docker.io/wurstmeister/kafka:*
Name: docker.io/zookeeper:*
Name: docker.io/ibmcloudcontainers/strongswan:*
Name: docker.io/opsh2oai/dai-ppc64le:*
Name: docker.io/redis*
Name: docker.io/f5networks/k8s-bigip-ctlr:*
Name: docker.io/rook/rook:*
Name: docker.io/rook/ceph:*
Name: docker.io/couchdb:*
Name: docker.elastic.co/beats/filebeat:*
Name: docker.io/prom/statsd-exporter:*
Name: docker.elastic.co/elasticsearch/elasticsearch:*
Name: docker.elastic.co/kibana/kibana:*
Name: docker.elastic.co/logstash/logstash:*
Name: quay.io/k8scsi/csi-attacher:*
Name: quay.io/k8scsi/driver-registrar:*
Name: quay.io/k8scsi/nfsplugin:*
Name: k8s.gcr.io/hyperkube:*
Name: registry.bluemix.net/armada-master/ibm-worker-recovery:*
Events: <none>

 

ポリシーを追加設定

まずは、yamlファイルを作成します。
ファイル名: mycip.yaml

apiVersion: securityenforcement.admission.cloud.ibm.com/v1beta1
kind: ClusterImagePolicy
metadata:
name: microclimate-cluster-image-policy
spec:
repositories:
- name: <cluster_ca_domain>:8500/* # ← ドメインを変えるのを忘れずに。
- name: docker.io/maven:*
- name: docker.io/jenkins/*
- name: docker.io/docker:*
 
作成したファイルを適用します。

kubectl create -f mycip.yaml

作成されていることを確認します。

kubectl get clusterimagepolicy
NAME AGE
ibmcloud-default-cluster-image-policy 1d
Microclimate-cluster-image-policy 23h

作成したポリシーの詳細も確認してみます。

kubectl describe clusterimagepolicy microclimate-cluster-image-policy
Name: Microclimate-cluster-image-policy
Namespace:
Labels: <none>
Annotations: <none>
API Version: securityenforcement.admission.cloud.ibm.com/v1beta1
Kind: ClusterImagePolicy
Metadata:
Creation Timestamp: 2018-12-26T02:23:52Z
Generation: 1
Resource Version: 123615
Self Link:
/apis/securityenforcement.admission.cloud.ibm.com/v1beta1/clusterimagepolicies/Mic
roclimate-cluster-image-policy
UID: 494d92d8-08b5-11e9-8c84-00505687010b
Spec:
Repositories:
Name: <cluster_ca_domain>:8500/*
Name: docker.io/maven:*
Name: docker.io/jenkins/*
Name: docker.io/docker:*
Events: <none>

5. microclimate registry secretの作成

ICP内にあるPrivate Registryを使うための認証キーを作成します。
実行するコマンドは下記になります。

kubectl create secret docker-registry microclimate-registry-secret \
--docker-server=<cluster_ca_domain>:8500 \
--docker-username=<account-username> \
--docker-password=<account-password> \
--docker-email=<account-email>

それぞれデフォルト値は下記のようになります。

変数名 デフォルト値
< cluster_ca_domain > mycluster.icp
< account-username > admin
< account-password > admin
< account-email > デフォルト値なし。任意の値

環境にあわせたサンプルのコマンドは下記になります。

kubectl create secret docker-registry microclimate-registry-secret \
--docker-server=mycluster.icp:8500 \
--docker-username=admin \
--docker-password=admin \
--docker-email=admin@test.local
 

6. Helmで利用するSecretの作成

MicroclimateのデプロイにHelmを利用します。Helmを利用するのに必要な証明書を含んだSecretを作成します。

下記のコマンドで .Helm/ が見えるか確認します。 

見える場合のサンプル

ls -la $HELM_HOME

total 16
drwxr-xr-x 2 root root 51 Dec 27 10:15 .
dr-xr-x---. 10 root root 4096 Dec 26 15:16 ..
-rw------- 1 root root 2004 Dec 27 10:15 ca.pem
-rw------- 1 root root 1424 Dec 27 10:15 cert.pem
-rw------- 1 root root 1704 Dec 27 10:15 key.pem

3つの .pemファイルが表示されていない場合は、$HELM_HOMEにPathが通っているか確認します。

printenv | grep HELM_HOME

なにもリストされない場合は、Pathを設定します。
※今回は root で作業しているので下記になっています。

export HELM_HOME="/root/.helm"

再度、コマンドを実行し .pem ファイルがリストされることを確認します。

ls -la $HELM_HOME

下記のコマンドを実行して、Secretを作成します。

kubectl create secret generic microclimate-helm-secret --from-file=cert.pem=$HELM_HOME/cert.pem --from-file=ca.pem=$HELM_HOME/ca.pem --from-file=key.pem=$HELM_HOME/key.pem

 

7. Microclimate pipeline secretの作成

NameSpace "microclimate-pipeline-deployments" 用のSecretも必要になりますので作成します。
実行するコマンドは下記になります。

kubectl create secret docker-registry Microclimate-pipeline-secret \
--docker-server=<cluster_ca_domain>:8500 \
--docker-username=<account-username> \
--docker-password=<account-password> \
--docker-email=<account-email> \
--namespace=Microclimate-pipeline-deployments

デフォルトの値は 5. microclimate registry secretの作成 で作成した値と同じです。

変数名 デフォルト値
< cluster_ca_domain > mycluster.icp
< account-username > admin
< account-password > admin
< account-email > デフォルト値なし。任意の値

設定のサンプルは下記になります。

kubectl create secret docker-registry microclimate-pipeline-secret \
--docker-server=mycluster.icp:8500 \
--docker-username=admin \
--docker-password=admin \
--docker-email=admin@test.local \
--namespace=microclimate-pipeline-deployments

次にSecretを割り当てます。 まずは現状を確認します。

kubectl describe serviceaccount default --namespace microclimate-pipelinedeployments

Name: default
Namespace: Microclimate-pipeline-deployments
Labels: <none>
Annotations: <none>
Image pull secrets: <none>
Mountable secrets: default-token-2qn78
Tokens: default-token-2qn78
Events: <none>

"Image pull secrets" がnone の場合は下記コマンドを実行します。

kubectl patch serviceaccount default --namespace microclimate-pipeline-deployments -p "{\"imagePullSecrets\": [{\"name\": \"microclimate-pipeline-secret\"}]}"

"Image pull secrets" に Microclimate-pipeline-secret 以外の値(別のSecret)が適用されている場合、下記のコマンドで書き換えます。

kubectl patch sa default -n microclimate-pipeline-deployments --type=json -p="[{\"op\":\"add\",\"path\":\"/imagePullSecrets/0\",\"value\":{\"name\": \"microclimate-pipeline-secret\"}}]"

適用後は下記のようになります。

kubectl describe serviceaccount default --namespace Microclimate-pipelinedeployments

Name: default
Namespace: Microclimate-pipeline-deployments
Labels: <none>
Annotations: <none>
Image pull secrets: Microclimate-pipeline-secret
Mountable secrets: default-token-2qn78
Tokens: default-token-2qn78
Events: <none>

 

8. Ingress Domain Name の作成(今回はHostsで設定します)

環境上用意が難しいので今回はHostsを使って設定します。
MicroclimateとjenkinsのWebサービス用にサブドメインを自動的につけて、80,443で通信するので、仮にドメイン名が icppoc.local だとすると、

microclimate.icppoc.local
jenkins.icppoc.local

にアクセスすることになります。
今回はデプロイ完了後に接続元PC(Windows)のhostsを書き換えてアクセスさせてしまいます。

 

9. Helmからインストール

Helmからインストールします。 ここからはGUIで操作してみます。

管理コンソールの[カタログ]に移動し、[Microclimate]で検索します。
表示された項目をクリックします。

20190110_13h32_22a_2



[構成]をクリックします。

20190110_14h51_31

表示された画面で下記項目を埋めて、[インストール]をクリックします。

項目名
Helmリリース名 任意の名前(microclimatetest)
ターゲット名前空間 [1. Name Space の作成]で作成したNameSpaceを選択
使用許諾条件 チェックする
ポッドセキュリティー 入力なし
Microclimate Ingress Domain 任意のドメイン

今回、任意のドメインは icppoc.localと指定します。

20190110_14h52_57 

デプロイ後、Helmリリースの情報を確認してみます。 管理コンソールのメニューから[ワークロード]-[Helmリリース]に移動します。

20190110_14h56_08


microclimate で検索し、対象のHelmリリースをクリックします。

20190110_14h56_36a


デプロイメントのステータスで”使用可能”のステータスに”1”と表示されていなかったり、ポッドのステータスが"Running" となっていない状態になっています。
また、 Persistent Volume Claim の状況が Pendingになっています。

20190110_14h56_51

20190110_14h57_50

これは、Persistent Volumeが存在しないため、Persistent Volume Claimがディスクを割り当てできず正常に動作していません。
次のステップでPersistent Volumeを作成します。

 

10. Persistent Volumeの作成

Microclimateで利用するPersistent Volume (以下、PV)が必要になります。
今回は NFS Server を用意し、NFSボリュームをPVとして利用します。

まず、現時点ではPVを請求する Persistent Volume Claim (以下、PVC) が作成されている状態になりますので、PVCのステータスを確認します。

管理コンソールのメニューで[プラットホーム]-[ストレージ]を開き、「PersistentVolumeClaim」のタブをクリックします。

20190110_15h04_01c


microclimatetest-ibm-microclimatemicroclimatetest-jenkinsというエントリがあります。

それぞれのステータスは下記のようになっているかと思います。

名前 名前空間 状況 Persistent Volume 要求 アクセス・モード
microclimatetest-ibm-microclimate microclimate-space Pending - 8Gi RWX
microclimatetest-jenkins microclimate-space Pending - 8Gi RWO

PVが[-]となっていますので割り当てがありません。
MicroclimateのHelmリリースではデフォルトでDynamic Provisioningが有効になっています。これは、PVCが作成されたときに、PVCの内容を満たすPVが存在すれば自動的に割り当てる機能になります。

今回のPVの請求内容は上記図の要求アクセスモード部分が該当しますので、請求を満たすPVを用意します。

NFS Serverの準備

今回は別途、構築済みのCentOSサーバーにNFS Serverをインストールし利用します。
NFSのパスは2つ作成しました。

NFS Server IP : xxx.xxx.xxx.159
Path1 : /nfs/microclimate
Path2 : /nfs/jenkins

PVの作成

PVを作成します。今回もGUI(管理コンソール)で作成します。
先ほど開いていた管理コンソール画面を開きます。
場所は管理コンソールのメニューから[プラットホーム]-[ストレージ]を開きます。 "PersistentVolume"のタブをクリックします。

20190110_15h19_18a

PersistentVolumeの作成をクリックします。

まず、PVC microclimatetest-ibm-microclimate 用のPVを作成します。
要求 8Gi容量になります。RWXはアクセスモードでReadWriteManyになります。NFSサーバーはIPとPathが必要になりますので、Path1を使います。

今回設定する値は下記のようになります。

カテゴリ 設定名 設定値
一般 名前 任意の名前(microclimate-pv)
  容量 8Gi
  アクセス・モード 何度でも読み取り/書き込み
  再利用ポリシー 保持
  ストレージタイプ NFS
パラメーター キー1 server
  値1 xxx.xxx.xxx.159
  キー2 path
  値2 /nfs/microclimate

※記載のない設定は設定しません
※パラメーターのキーは"パラメーターの追加"で追加します。

 

次にPVC microclimatetest-ibm-jenkins用のPVを作成します。 容量8GiアクセスモードRWOです。 RWOはReadWriteOnceです。

カテゴリ 設定名 設定値
一般 名前 任意の名前(jenkins-pv)
  容量 8Gi
  アクセス・モード 一度だけの読み取り/書き込み
  再利用ポリシー 保持
  ストレージタイプ NFS
パラメーター キー1 server
  値1 xxx.xxx.xxx.159
  キー2 path
  値2 /nfs/jenkins

※記載のない設定は設定なし ※パラメーターのキーは"パラメーターの追加"で追加する

 

どちらも作成すると下記のようにPVにリストが追加されます。

20190110_15h26_32

請求の値にそれぞれ値が設定され、状況Boundになっています。
また、PersistentVolumeClaimのタブを開くとPersistentVolumeの値に作成したPV名が表示され、状況もBoundとなりますので、PVCはPVの割り当てを取得し、ストレージの割り当てが完了しました。
20190110_15h27_13

先ほど確認した際にはすべてが動作していなかったHelmリリースの情報を見に行きます。
管理コンソールのメニューから[ワークロード]-[Helmリリース]を開き、「microclimatetest」を開きます。

ポッドのステータスがすべてRunningになり、デプロイメントの使用可能のステータスがすべて1になっていることを確認します。

20190110_15h28_2620190110_15h28_34※ コンテナーがすべて作成されるまでに少し時間がかかります

 
最後にMicroclimateとJenkinsにログインしてみましょう。 今回、Domainに関して特に設定していませんので、Hostsを編集する必要があります。

管理コンソールのメニューから[ネットワーク・アクセス]-[サービス]を開き、「入口」タブをクリックします。

20190111_14h50_17

Microclimatetest-ibm-MicroclimateMicroclimatetest-jenkinsがリストされています。 それぞれ、ドメインは icppoc.local になり、サブドメインでMicroclimatejenkinsがついています。

アドレス部分が[-]となっている場合は、proxyノードのIPが使われています。 Proxyノードがどのサーバーか確認するには、管理コンソールの[プラットホーム]-[ノード]から確認ができます。
ここでは、 xxx.xxx.xxx.161 がProxyノードになります。

20190110_16h16_b

接続元のPCのHostsに下記を追記します。
 
xxx.xxx.xxx.161      microclimate.icptest.local
xxx.xxx.xxx.161      jenkins.icptest.local

設定後それぞれのURLにアクセスします。

https://microclimate.icptest.local/
https://jenkins.icptest.local/ 

Microclimate20190110_16h20_14

Jenkins20190110_16h19_54

この先はそれぞれのアプリケーションでの設定となっていきます。

もしアプリケーション開発環境として利用してみたいというユーザー様がいらっしゃれば、なんらかのPV(NFS)さえ用意できれば動きますので、ぜひ試してみてください。

最後に

IBM Cloud PrivateのPoC環境の貸し出しも実施しています。

https://www.networld.co.jp/product/ibm-hardware/trial/

Web上にNFSの用意の記載はありませんが、ご要望があればご用意はできますのでご興味のある方は是非ご連絡ください!

すずきけ

2019/01/10

IBM Cloud Private 3.1.1 Vulnerability Advisorを追加してイメージの脆弱性をスキャンしてみよう

こんにちは。IBM Cloud Privateについて、かなり間が空きましたが、前々回にインストールの内容を投稿しました。

今回は脆弱性アドバイザー(Vulnerability Advisor)を追加してみたいと思います。

脆弱性アドバイザーって何?

ドキュメント上では下記のように説明されています。

脆弱性アドバイザーは、IBM® やサード・パーティーによって提供されるか、組織のレジストリー名前空間に追加された、コンテナー・イメージのセキュリティー状況を検査します。 Container Scanner が各クラスターにインストールされている場合、脆弱性アドバイザーは、実行中のコンテナーの状況も検査します。 https://console.bluemix.net/docs/services/va/va_index.html#about

ICPで管理しているイメージや稼働しているコンテナー上で脆弱性をもつパッケージがないかと設定について問題がないかをレポートしてくれます。
また、この機能の開発は日本のラボで開発されているとのことです。

既存のICPの環境にVulnerability Advisor(VA)を追加して、イメージのスキャンとコンテナーのスキャンまでできることを確認してみたいと思います。

※注意※ 既存環境が存在しており、その環境にWorkerノードを追加構築していく想定の手順となっていますので、環境がまだないという方はインストール方法を参考に作ってみていただければと思います。 また、商用版のIBM Cloud Privateを想定した手順となっておりますので、CE版での実施は想定しておりません。(VAはCE版では利用できません。) あらかじめご了承ください。

また、今回の環境はICP 3.1.1の環境をベースに作成しています。
前回投稿したICPのインストール手順では3.1.0を利用していますが、今回手順については3.1.0でも変わりませんので、各コマンド部分の3.1.1部分を3.1.0に読み替えて実施してみてください。

 

脆弱性アドバイザー(VA)のインストール

既存環境

サーバースペックは同じもので2台のサーバーがあります。

OS RedHat Endterprise Linux 7.4
物理/仮想 仮想
CPU(Core) 8
Memory 24GB
Disk 300GB
NIC 1つ

Master ServerとWorker Serverが1台ずつあります。 ICPのバージョンは3.1.1になります。

以前、投稿した手順は3.1.0になります。3.1.1でも同様の手順でインストールできます。
また、この手順は3.1.0でも同様の作業内容になりますので、記載されているバイナリ名や、設定名等、 3.1.1 となっている部分は 3.1.0 と読み替えて手順を実施してください。

 

事前準備

WorkerやVAにするノードを準備します。
今回は以既存環境と同じスペックのRHELの仮想マシンと同じものを用意します。

Linux on PowerやLinux on IBM Z でも動作は可能(VAは制限あり)ですので、動作環境の詳細は下記をご参照ください。
https://www.ibm.com/support/knowledgecenter/en/SSBS6K_3.1.1/supported_system_config/supported_os.html

 

追加するノード

追加するノードは下記になります。

Host name IP 作業ユーザー
icp-poc-va1.icp.local xxx.xxx.xxx.158 root

 

追加ノードで行う作業

追加するノードでは下記の事を行います。

  1. 通信ポートの確認
  2. SE Linux の無効化、Firewallの無効化
  3. /etc/hostsを設定
  4. 時刻の同期
  5. Python のインストール(の確認)
  6. Dockerのインストール
  7. (後から作業) sshサービスの再起動
 

通信ポートの確認

下記コマンドを実行してなにも表示されないことを確認します。

ss -tnlp | awk '{print $4}' | egrep -w "8001|8500|3306"

 

SE Linux の無効化、Firewallの無効化

SE LinuxとFirewallを無効化します。
SE Linuxは /etc/selinux/config をdisableに変更します。
Firewallは下記のコマンドを実行します。

systemctl stop firewalld
systemctl disable firewalld
 

/etc/hostsを設定

クラスターに存在するすべてのノード(Master/Worker/VA/Management/Proxy)を /etc/hosts に指定します。

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
xxx.xxx.xxx.161 icp-poc-master1.icp.local
xxx.xxx.xxx.164 icp-poc-worker1.icp.local

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
xxx.xxx.xxx.161 icp-poc-master1.icp.local
xxx.xxx.xxx.164 icp-poc-worker1.icp.local
xxx.xxx.xxx.158 icp-poc-va1.icp.local
 

時刻の同期

追加するノードと既存のサーバー群と時刻の差が出ないように時刻同期を行います。
時刻同期方法は各Linuxのドキュメントをご確認ください。

RHELで時刻、時刻同期の設定の確認は下記コマンドでできます。

# timedatectl
Local time: Tue 2019-01-08 11:01:18 JST
Universal time: Tue 2019-01-08 02:01:18 UTC
RTC time: Tue 2019-01-08 02:01:17
Time zone: Asia/Tokyo (JST, +0900)
NTP enabled: n/a
NTP synchronized: no
RTC in local TZ: no
DST active: n/a
 

Python のインストール(の確認)

Pythonがインストールされていることを確認します。
サポートされているPythonのバージョンは、2.6,2.7,3.5以上になります。

# python --version
Python 2.7.5
 

Dockerのインストール

Dockerをインストールします。DockerのバイナリーはIBM社から提供されています。

  • IBM Cloud Private 3.1.1 Docker for Linux (x86_64) (CNXD2EN )
    size: 141MB

このファイルをノード上にコピーし実行します。

cd /(ファイルをコピーした場所)
./icp-docker-18.03.1_x86_64.bin --install

※このとき、内部で別のコンポーネントをyumでインストールします。

dockerが自動起動されるように設定します。

systemctl start docker
systemctl enable docker
 

(後から作業) sshサービスの再起動

既存のMaster ServerからSSH Keyをコピーした後にSSH Serviceの再起動を行います。
後述の手順内で再度ご案内します。


Master Serverで行う作業

実際のインストール作業については既存のMaster Serverから行います。

  • SSH Keyのコピー
  • (後から作業) sshサービスの再起動
  • バイナリーファイルの確認
  • ノードへのVAインストールの実施
  • ノードの状態の確認
  • Master Serverへの機能のAddon

SSH Keyのコピー

Master Server上からノードにSSH Keyをコピーします。

ssh-copy-id -i ~/.ssh/id_rsa.pub <user>@<node_ip_address>

今回は、下記の情報を使ってコマンドを実行します。

user node_ip_address
root xxx.xxx.xxx.158
ssh-copy-id -i ~/.ssh/id_rsa.pub root@xxx.xxx.xxx.158
 

!!!ノードで作業!!! sshサービスの再起動

ノード上でSSH Serviceを再起動します。

systemctl restart sshd

 

バイナリーファイルの確認

下記にLinux用のバイナリーファイルがあることを確認します。
インストールパスを変更している場合は適宜読み替えてください。

Path File name
/opt/ibm-cloud-private-3.1.1/cluster/images ibm-cloud-private-x86_64-3.1.1.tar.gz

コマンド

# ls /opt/ibm-cloud-private-3.1.1/cluster/images ibm-cloud-private-x86_64-3.1.1.tar.gz
 
VAの追加

VAの追加は下記のコマンドを参考に実行します。

docker run --rm -t -e LICENSE=accept --net=host -v \
$(pwd):/installer/cluster ibmcom/icp-inception-$(uname -m | sed 's/x86_64/amd64/g'):3.1.1-ee va -l \
ip_address_vanode1,ip_address_vanode2

IPアドレス xxx.xxx.xxx.158 をVAとして追加しますので、実行するコマンドは下記になります。

cd /opt/ibm-cloud-private-3.1.1/cluster
docker run --rm -t -e LICENSE=accept --net=host -v \
$(pwd):/installer/cluster ibmcom/icp-inception-$(uname -m | sed 's/x86_64/amd64/g'):3.1.1-ee va -l \
xxx.xxx.xxx.158
 

ノードの状態の確認

追加したノードがVAとして登録されているか確認します。
ICP管理コンソールから[プラットホーム]-[ノード]を開きます。
IPアドレスの末尾 158 の役割に VA と記載されていることを確認します。

20190109_15h16_01a_2

Master Serverへの機能のAddon

最後にMaster ServerとVAノードに機能をデプロイ(アドオン)します。

Master Server上のConfig.yamlを編集します。

vi /opt/ibm-cloud-private-3.1.1/cluster/config.yaml

変更前

## You can disable following services if they are not needed:
# custom-metrics-adapter
# image-security-enforcement
# istio
# metering
# monitoring
# service-catalog
# storage-minio
# storage-glusterfs
# vulnerability-advisor
management_services:
istio: disabled
vulnerability-advisor: disabled
storage-glusterfs: disabled
storage-minio: disabled

変更後

## You can disable following services if they are not needed:
# custom-metrics-adapter
# image-security-enforcement
# istio
# metering
# monitoring
# service-catalog
# storage-minio
# storage-glusterfs
# vulnerability-advisor
management_services:
istio: disabled
vulnerability-advisor: enabled     #←disabledからenabledに変更
storage-glusterfs: disabled
storage-minio: disabled
 

下記の内容を参考にコマンドを実行します。

docker run --rm -t -e LICENSE=accept --net=host -v $(pwd):/installer/cluster ibmcom/icp-inception-ARCH:3.1.1-ee addon

Dockerイメージ名が異なりますので、下記のように変更して実行します。

cd /opt/ibm-cloud-private-3.1.1/cluster
docker run --rm -t -e LICENSE=accept --net=host -v $(pwd):/installer/cluster ibmcom/icp-inception-amd64:3.1.1-ee addon

 

VA動作の確認

VAの機能追加完了後は、管理コンソール上でスキャンの状況やレポートが確認できるようになります。

 

管理コンソールのログアウト/ログイン

管理コンソールにログインした状態で機能の追加を行った場合は画面が正常に表示されない場合がありますので、管理コンソールからログアウトし、再度ログインします。

20190110_11h26_17_2

コンテナーイメージのスキャン状況の確認

VAの機能が有効化されると自動的にコンテナーイメージのスキャンが実行されます。
すべてのイメージをスキャンするには時間がかかりますが、スキャン済みのものからステータスの確認ができますので開いています。

  1. 管理コンソールを開きます。

  2. メニューから[コンテナー・イメージ]を選択します。

    20190110_11h28_01_2

  3. 一覧が表示されます。セキュリティー・スキャンのステータスに 成功 or 失敗しました のステータスがあるものはスキャンが完了しています。 

    20190109_15h33_34_2

  4. 失敗している ibmcom/curl-amd64 をクリックします。

    20190109_15h36_19a

  5. スキャンの結果、問題がいくつあるか表示されています。
    スキャンの表示 をクリックします。

    20190109_15h36_24a_2

  6. スキャン結果のレポートが表示されます。
    Organizational Policiesでは違反理由が表示されています。
    今回はイメージ内にインストールされたパッケージ上に既知の脆弱性が含まれていることが示されています。

    20190109_15h36_32_2

  7. [vulnerable Packages]のタブをクリックします。
    ここでは脆弱性の影響を受けるパッケージの情報が表示されます。

    20190109_15h36_38_2

  8. [Container Settings]のタブをクリックします。
    ここではコンテナーの設定に対して潜在的な脆弱性の問題や推奨されてる設定について表示されます。

    20190109_15h36_48_2


    今回は見つかっていませんが、Security MisconfigurationsやRisk Analysisの情報も確認できます。

  9. 次に稼働しているContainerのスキャンレポートを確認します。
    管理コンソールから[ツール]-[脆弱性アドバイザー]を選択します。
    ※ツールメニューが表示されない場合は管理コンソールのログアウト/ログインを行ってください。

    20190110_11h37_50_2

  10. [kube-system]を選択します。

    20190110_11h40_05a_2

  11. 別のタブが開き、[Vulnerability Advisor(List Containers)]が表示されます。
    Filterに[mariadb]と入力し、Organizational Policiesのステータスが Violation となっているリストをクリックします。

    20190110_09h36_09a_2

  12. Imageスキャンの結果と同じように Organizational Policies / Vulnerable Packages / Container Settings / Security Misconfigurations / Risk Analysis の情報が表示されます。

    20190110_09h39_05

以上がVAの展開からスキャンの結果の表示までの手順になります。
このほかにも **Mutation Advisor というContainer上で変更があった場合に検知する機能もあります。
今後、検証する予定ですので、別途レポートを投稿したいと思っています。

Docker Containerの利用が広がるにつれて、すでに公開されているDocker Imageを使ったり、公式で公開されているDocker Imageから作成したDocker Imageを利用する機会が増えてくると思いますが、Docker Image自体にセキュリティ上の問題がないか、設定上にも不備がないかもチェックしていかなければならないかと思います。
脆弱性のあるパッケージの確認についてはいろいろと製品が出てきてはいますが、Vulnerability AdvisorはICPに付属している製品ですので、ぜひ試してみてください。

参考URL:

https://www.ibm.com/support/knowledgecenter/en/SSBS6K_3.1.1/manage_applications/disable_service.html

https://www.ibm.com/support/knowledgecenter/en/SSBS6K_3.1.1/installing/add_node.html

最後に

IBM Cloud PrivateのPoC環境の貸し出しも実施しています。

https://www.networld.co.jp/product/ibm-hardware/trial/

Web上にVA機能についてのPoCについて記載はありませんが、PoC環境でVAも使って検証してみたい!といったご要望がありましたら問い合わせ窓口からご相談ください。

すずきけ

2018/11/20

IBM Cloud Private 3.1 Multi Cloud Manager インストール手順

こんにちは。前回はICP3.1のインストールについてご案内させていただきました。
今回は、ICP上で動作するIBM Multicloud Manager(以下、MCM)という製品のインストール方法を書いていきます。


MCMってなんぞや?

IBM Multicloud Managerですがその名の通り、複数のクラウドを管理するマネージャーになります。
このクラウドの中にはICP(オンプレ製品ですが)はもちろん、IBM発表の情報では、IKS(IBM Cloud上のKubernetesサービス)やAWS、Azure等々の他ベンダーのクラウドにあるKubernetesサービスも管理できるようになるという製品です。

MCM上でほかのKubernetesクラスターの状況確認はもちろん、Helmからリモートでデプロイする機能も含まれているようです。
ただ、まだまだ情報が出そろってはいません。
このあたりの機能などの情報については情報が出そろったらまたご案内できればと思います!


環境

ICPのインストール方法で作成したICP環境を 2セット 用意します。
前回の環境情報はこんな感じです。
/////////////////////////////////////////////////////////////////////
2台のサーバーを使いICPをインストールします。

1台目:Master node (Master,Management,etcd,Proxy)
2台目:Worker node (Worker)
※インストール手順では、1台目を「Master」、2台目を「Worker」を表記します。

サーバーはどちらも同一スペックを用意しています。

OS RedHat Endterprise Linux 7.4
物理/仮想 仮想
CPU(Core) 8
Memory 24GB
Disk 300GB
NIC 1つ

FirewallとSELinuxについては無効にしています。
//////////////////////////////////////////////////////////////////////


ファイルの準備

下記のファイルを入手します。

  • IBM Multi-cloud Manager 3.1.0 Kubernetes Images for Linux (CNVV6EN )
    size:962MB

事前にダウンロードしたファイルを解凍して、Tokyo Master,Osaka Master上それぞれにコピーしておきます。該当のファイル名は mcm-3.1.0_x86.tgz になります。

今回、このファイルは ~/ 配下にコピーしています。


やること

今回はMCMのインストールともう一つのICPクラスターをMCM配下のクラスターとして登録します。

登場人物

  • ICPクラスター2セット

    • クラスター名: Tokyo
      • Master: Tokyo Master IP末尾 50
      • Worker: Tokyo Worker IP末尾 51
    • クラスター名: Osaka
      • Master: Osaka Master IP末尾 60
      • Worker: Osaka Worker IP末尾 61
  • Multi Cloud Manager
    MCMの管理コンポーネント。Helmからインストール。

    • Tokyo Masterにインストール
  • Klusterlet
    MCM用のAgent。Helmからインストール。

  • hub-cluster
    IBM Multicloud ManagerをインストールしたICP Master(今回は Tokyo Master)のこと。

  • cluster_CA_domain
    Clusterのドメイン名。デフォルトは mycluster.icp
    ※変更するのはICPのインストール時になります。


手順の概要

  1. Tokyo Masterに MCM をインストール
  2. Tokyo Masterに Klusterlet をインストール
  3. Osaka Masterに Klusterlet をインストール

MCMインストール

インストールはCLIベースでの作業と管理コンソールでの作業があります。
CLIベースの作業は各クラスターの Master で作業を実施します。
CLIではRootにログインして作業します。


Tokyo Master 作業(CLI)


Docker にログイン

docker login mycluster.icp:8500
  • User : admin
  • Password : admin

IBM Cloud Private CLIにログイン

cloudctl login -a https://<Tokyo Master IP Address>:8443 -n kube-system --skip-ssl-validation
# サンプル cloudctl login -a https://xxx.xxx.xxx.50:8443 -n kube-system --skip-ssl-validation Username> admin #←ユーザー名:admin を入力 Password>  #←パスワード:admin を入力 Authenticating... OK Select an account: 1. mycluster Account (id-mycluster-account) Enter a number> 1  #← 1 を入力 Targeted account mycluster Account (id-mycluster-account) Targeted namespace kube-system Configuring kubectl ... Property "clusters.mycluster" unset. Property "users.mycluster-user" unset. Property "contexts.mycluster-context" unset. Cluster "mycluster" set. User "mycluster-user" set. Context "mycluster-context" created. Switched to context "mycluster-context". OK Configuring helm: /root/.helm OK

Helmチャートにファイルをロード

cd ~/ cloudctl catalog load-ppa-archive -a mcm-3.1.0_x86.tgz --registry mycluster.icp:8500

Tokyo Master 作業(GUI)


コンテナイメージの確認

管理コンソール上でMCMに必要なイメージがロードされていることを確認します。

  • 管理コンソールにログイン
  • 左上のメニューを開き、「イメージ」に移動
  • 検索窓で「kube-system」と入力し、イメージを確認

20181116_11h00_38



Helmカタログの確認

管理コンソールでHelmにカタログが登録されていることを確認します。

  • 管理コンソールにログイン
  • 右上の「カタログ」に移動
  • 検索窓で「mcm」と入力し、カタログを確認

20181116_11h02_55



カタログからデプロイ

管理コンソールからカタログに移動し、 ibm-mcm-controller を選択します。

20181116_11h02_55a


右下の 構成 をクリックします。

20181116_11h16_06_2



デプロイに必要なパラメータを入力します。

設定名 設定値
Helmリリース名 任意の名前を入力
ターゲット名前空間 kube-system
Multi-cloud Manager Namespace 専用の名前空間

名前空間はIBM Multicloud Manager用に専用の名前空間が必要になります。 ここでは mcm-tokyo と指定します。

20181116_11h16_47_2


インストール をクリックしインストールを実行します。 実行後、Helmリリースの状況を確認します。

20181116_11h21_27


よくあるミスとしては、ターゲット名前空間を間違えてしまうということがあります。
その場合 デプロイメント のなかの multicloudmanager-ibm-mcm-controller-controller の使用可能部分が 0 となっていることがあります。この場合は、Helmを使って、一度削除してが必要になります。(削除できないことがありますのでなるべく間違えないように気を付けてください。)

数分待ったあとに一度管理コンソールからログアウトし、再度ログインします。
正常動作している場合は、管理コンソールのメニューに マルチクラスター という項目が増えます。

20181116_11h25_34



Tokyo Master 作業(CLI)


Hub Clusterのへのログイン

cloudctl login -a https://<hub_cluster_host_name>:8443 --skip-ssl-validation

<hub_cluster_host_name>はTokyo Masterのホスト名もしくはIPアドレスになります。

cloudctl login -a https://xxx.xxx.xxx.50:8443 --skip-ssl-validation Username> admin # adminと入力 Password> # adminと入力 Authenticating... OK Select an account: 1. mycluster Account (id-mycluster-account) Enter a number> 1 # 1と入力 Targeted account mycluster Account (id-mycluster-account) Select a namespace: 1. cert-manager 2. default 3. ibmcom 4. istio-system 5. kube-public 6. kube-system 7. mcm-tokyo 8. platform 9. services Enter a number> 6 # 6と入力 Targeted namespace kube-system Configuring kubectl ... Property "clusters.mycluster" unset. Property "users.mycluster-user" unset. Property "contexts.mycluster-context" unset. Cluster "mycluster" set. User "mycluster-user" set. Context "mycluster-context" created. Switched to context "mycluster-context". OK Configuring helm: /root/.helm OK

MCM用のNameSpaceの作成

kubectl create namespace <mcm_namespace>

カタログからMCMをデプロイした際のNameSpaceと同一にします。
ここでは mcm-tokyoと指定しました。


Hub ClusterからのリモートHelmインストール機能を有効にする

export CLUSTER_IP=<hub_cluster_host_name> kubectl patch daemonset catalog-ui --patch '{"spec": {"template":{"spec":{"containers":[{"name":"catalog-ui","env":[{"name":"hcmCapabilityEnabled","value":"true"},{"name":"hcmRedirectUrl","value":"https://'${CLUSTER_IP}':8443/hcmconsole/remoteinstall"}]}]}}}}' -n kube-system

※<hub_cluster_host_name>部分をMCMをいれたICP Masterのホスト名にします。名前解決ができない場合はIPアドレスを指定します。


Klusterletのインストール(Tokyo Master)

次にMCMと通信を行うKlusterletをインストール(デプロイ)します。クラスターTokyoに対しても作業が必要になります。

Tokyo Master 作業(GUI)


事前準備

デプロイに必要なパラメータを確認します。
Tokyo Masterの管理コンソールにログインし、右上の人型アイコンをクリックし、クライアントの構成 をクリックします。

20181116_11h31_45


「クライアントの構成」のポップアップが表示されます。

20181116_11h33_54a


パラメータが表示されている部分を2列分をコピーします。

kubectl config set-cluster cluster.local --server=https://xxx.xxx.xxx.50:8001 --insecure-skip-tls-verify=true
kubectl config set-credentials admin --token=eyJ0(以下、略)

このあとに使用する部分は、

  • --server= https://xxx.xxx.xxx.50:8001
  • --token= eyJ0(以下、略)
    略部分はもちろん略さず利用します。

Tokyo Master 作業(CLI)


Tokyoクラスターにログイン

cloudctl login -a https://mycluster.icp:8443 --skip-ssl-validation Username> admin # adminと入力 Password> # adminと入力 Authenticating... OK Select an account: 1. mycluster Account (id-mycluster-account) Enter a number> 1 # 1と入力 Targeted account mycluster Account (id-mycluster-account) Select a namespace: 1. cert-manager 2. default 3. ibmcom 4. istio-system 5. kube-public 6. kube-system 7. mcm-tokyo 8. platform 9. services Enter a number> 6 # 6と入力 Targeted namespace kube-system Configuring kubectl ... Property "clusters.mycluster" unset. Property "users.mycluster-user" unset. Property "contexts.mycluster-context" unset. Cluster "mycluster" set. User "mycluster-user" set. Context "mycluster-context" created. Switched to context "mycluster-context". OK Configuring helm: /root/.helm OK

※ICPクラスター名をインストール時に変更している場合は適宜クラスター名を変更します。


Secret の作成

kubectl create secret tls <klusterlet_tiller_secret> --cert ~/.helm/cert.pem --key ~/.helm/key.pem -n kube-system

<klusterlet_tiller_secret> に任意の名称を入力します。ここでは、klusterlet-tiller-secret として入力します。

kubectl create secret tls klusterlet-tiller-secret --cert ~/.helm/cert.pem --key ~/.helm/key.pem -n kube-system

Secretの確認

Secretが正常に作成されているか確認します。

kubectl get secret | grep klusterlet-tiller-secret

Klusterlet用のNameSpaceの作成

kubectl create namespace <mcm_namespace>

ここでは mcm-tokyo-klusterletと指定しました。


Tokyo Master 作業(GUI)

デプロイ

管理コンソールにログインし右上のカタログをクリックします。
検索画面で mcm と入力し、表示された ibm-mcm-klusterlet を選択します。

20181116_11h02_55b


遷移した画面で構成 をクリックします。
それぞれパラメータを指定していきます。

設定名 設定値
Helmリリース名 任意の名前を入力
ターゲット名前空間 kube-system
Cluster Name 任意のクラスター名
Cluster Namespace Klusterlet専用の名前空間
Klusterlet Tiller Secret Name 事前に作成してSecret名
Hub Cluster Kubernetes API Server 事前に確認したAPIサーバー名
Hub Cluster Kubernetes API server token 事前に確認したToken

今回の環境では下記のようになります(しました)。

設定名 設定値
Helmリリース名 tokyo-cluster-klusterlet
ターゲット名前空間 kube-system
Cluster Name tokyo-cluster
Cluster Namespace mcm-tokyo-klusterlet
Klusterlet Tiller Secret Name klusterlet-tiller-secret
Hub Cluster Kubernetes API Server https://xxx.xxx.xxx.50:8001
Hub Cluster Kubernetes API server token eyJ0(以下、略)

20181116_17h11_05b


ローカルインストール を選択し、デプロイを開始します。


デプロイの確認

デプロイ状況を確認します。
管理コンソールのメニューから[ワークロード]-[Helmリリース]を開きます。

20181116_17h15_59


検索画面にtokyo と入力し、tokyo-cluster-klusterletを選択します。

20181116_17h16_55


使用可能の値が必要数と異なっていたり、エラー等が発生していないことを確認します。

20181116_17h17_34


管理コンソールのメニューから[マルチクラスター]-[クラスター]を開きます。

20181116_17h18_06


tokyo-cluster が表示され、Statusが正常なことを確認します。

20181116_17h18_58



Klusterletのインストール(Osaka Master)

Osaka MasterにKlusterletをインストール(デプロイ)します。

Osaka Master 作業(CUI)

Docker にログイン

docker login mycluster.icp:8500
  • User : admin
  • Password : admin

IBM Cloud Private CLIにログイン

cloudctl login -a https://<Osaka Master IP Address>:8443 -n kube-system --skip-ssl-validation
# サンプル cloudctl login -a https://xxx.xxx.xxx.60:8443 -n kube-system --skip-ssl-validation Username> admin Password> Authenticating... OK Select an account: 1. mycluster Account (id-mycluster-account) Enter a number> 1 Targeted account mycluster Account (id-mycluster-account) Targeted namespace kube-system Configuring kubectl ... Property "clusters.mycluster" unset. Property "users.mycluster-user" unset. Property "contexts.mycluster-context" unset. Cluster "mycluster" set. User "mycluster-user" set. Context "mycluster-context" created. Switched to context "mycluster-context". OK Configuring helm: /root/.helm OK

Helmチャートにファイルをロード

cd ~/ cloudctl catalog load-ppa-archive -a mcm-3.1.0_x86.tgz --registry mycluster.icp:8500

Osakaクラスターにログイン

cloudctl login -a https://mycluster.icp:8443 --skip-ssl-validation Username> admin # adminと入力 Password> # adminと入力 Authenticating... OK Select an account: 1. mycluster Account (id-mycluster-account) Enter a number> 1 # 1と入力 Targeted account mycluster Account (id-mycluster-account) Select a namespace: 1. cert-manager 2. default 3. ibmcom 4. istio-system 5. kube-public 6. kube-system 7. mcm-tokyo 8. platform 9. services Enter a number> 6 # 6と入力 Targeted namespace kube-system Configuring kubectl ... Property "clusters.mycluster" unset. Property "users.mycluster-user" unset. Property "contexts.mycluster-context" unset. Cluster "mycluster" set. User "mycluster-user" set. Context "mycluster-context" created. Switched to context "mycluster-context". OK Configuring helm: /root/.helm OK

※ICPクラスター名をインストール時に変更している場合は適宜クラスター名を変更します。


Secret の作成

kubectl create secret tls <klusterlet_tiller_secret> --cert ~/.helm/cert.pem --key ~/.helm/key.pem -n kube-system

<klusterlet_tiller_secret> に任意の名称を入力します。ここでは、klusterlet-tiller-secret として入力します。
※Tokyo Clusterと同じで問題ありません。

kubectl create secret tls klusterlet-tiller-secret --cert ~/.helm/cert.pem --key ~/.helm/key.pem -n kube-system

Secretの確認

Secretが正常に作成されているか確認します。

kubectl get secret | grep klusterlet-tiller-secret

Klusterlet用のNameSpaceの作成

kubectl create namespace <mcm_namespace>

ここでは mcm-osaka-klusterletと指定しました。



Tokyo Master 作業(GUI)

事前準備

Tokyo MasterにKlusterletをデプロイした直後であれば確認は必要ありません。しかし、時間をあけてデプロイする場合は、Tokenの値が更新されていることがありますので必ずご確認ください。

デプロイに必要なパラメータを確認します。
Tokyo Masterの管理コンソールにログインし、右上の人型アイコンをクリックし、クライアントの構成 をクリックします。

20181116_11h31_45_2


「クライアントの構成」のポップアップが表示されます。 パラメータが表示されている部分を2列分をコピーします。

kubectl config set-cluster cluster.local --server=https://xxx.xxx.xxx.50:8001 --insecure-skip-tls-verify=true
kubectl config set-credentials admin --token=eyJ0(以下、略)

このあとに使用する部分は、

  • --server= https://xxx.xxx.xxx.50:8001
  • --token= eyJ0(以下、略)
    略部分はもちろん略さず利用します。

Osaka Master 作業(GUI)


デプロイ

管理コンソールにログインし右上のカタログをクリックします。
検索画面で mcm と入力し、表示された ibm-mcm-klusterlet を選択します。

20181116_17h29_36


遷移した画面で構成 をクリックします。
それぞれパラメータを指定していきます。

設定名 設定値
Helmリリース名 任意の名前を入力
ターゲット名前空間 kube-system
Cluster Name 任意のクラスター名
Cluster Namespace Klusterlet専用の名前空間
Klusterlet Tiller Secret Name 事前に作成してSecret名
Hub Cluster Kubernetes API Server 事前に確認したAPIサーバー名
Hub Cluster Kubernetes API server token 事前に確認したToken

今回の環境では下記のようになります(しました)。

設定名 設定値
Helmリリース名 osaka-cluster-klusterlet
ターゲット名前空間 kube-system
Cluster Name osaka-cluster
Cluster Namespace mcm-osaka-klusterlet
Klusterlet Tiller Secret Name klusterlet-tiller-secret
Hub Cluster Kubernetes API Server https://xxx.xxx.xxx.50:8001
Hub Cluster Kubernetes API server token eyJ0(以下、略)

20181116_17h34_08


また、今回はClusterの場所の表示を変えるためにすべてのパラメーターを下記のように設定します。
※記載のないパラメーターは変更していません。

設定名 設定値
Cluster Region AP
Cluster Datacenter Osaka
Cluster Owner it

20181116_17h35_20


ローカルインストール を選択し、デプロイを開始します。


Tokyo Master 作業(GUI)


デプロイの確認

デプロイ状況を確認します。
管理コンソールのメニューから[ワークロード]-[Helmリリース]を開きます。

20181116_17h43_12


検索画面にosaka と入力し、osaka-cluster-klusterletを選択します。

20181116_17h43_40


使用可能の値が必要数と異なっていたり、エラー等が発生していないことを確認します。

20181116_17h45_19



Tokyo Master 作業(GUI)


デプロイの確認

管理コンソールのメニューから[マルチクラスター]-[クラスター]を開きます。

20181116_17h46_05


osaka-cluster が表示され、Statusが正常なことを確認します。


その他


NameSpaceの確認

作成したNameSpaceはコマンドでも管理コンソールでも確認できます。
コマンドの場合は

kubectl get namespace

管理コンソールの場合は、メニューの[管理]-[名前空間]から確認ができます。


Hub Cluster上のNameSpace(名前空間)

Hub Cluster上には管理するクラスターでKlusterletデプロイ時に指定したNameSpaceが作成されます。

20181116_17h47_08




MCMの情報ソース

現在は下記のURLにMCMの構築手順や管理手順が記載されていますので、不明点がありましたらご参照ください。
IBM Multi-cloud Manager
※日本語は用意されていませんので必ず英語でご確認ください。
※メニューは「Table of Contents」をクリックすると開きます。

今回は以上になります!複数のKubernetes Serviceを利用されている皆様には良い機能かと思いますので是非是非使ってみてください。
評価等のご希望がありましたら、こちらの「お問い合わせ・ご相談はこちら」からブログを見て!とご連絡を頂ければと思います。
すずきけ

2018/10/30

IBM Cloud Private 3.1.0 インストール方法(RHEL編)

ICP3.1インストール_RHEL編.md

今回はIBM Cloud Private 3.1.0(以下、ICPを記載します)のインストール方法をご紹介します。 ICPはいくつかのエディションがあります。

  • Community Edition
  • Cloud Native Edition
  • Enterprise Edition

今回はCloud Native Editionを使ってインストールをしていきます。 Community Editionは無償ですが本番用途では使用できないなど制約があります。


ICPの情報リソース

現段階ではあまり情報が公開されていません。IBMのKnowledge Centerがさくっとみられる情報です。
https://www.ibm.com/support/knowledgecenter/en/SSBS6K/product_welcome_cloud_private.html

今回はここにあるインストール手順を参考にインストールを行います。
※記載の手順と順番が異なる部分があります。あらかじめご了承ください。


構築する環境

2台のサーバーを使いICPをインストールします。

1台目:Master node (master,management,etcd,Proxy)
2台目:Worker node (Worker)
※インストール手順では、1台目を「Master」、2台目を「Worker」を表記します。

サーバーはどちらも同一スペックを用意しています。

OS RedHat Endterprise Linux 7.4
物理/仮想 仮想
CPU(Core) 8
Memory 24GB
Disk 300GB
NIC 1つ

FirewallとSELinuxについては無効にしています。


利用するファイル類の準備

今回はライセンス品になりますので、IBM社のサイトからダウンロードしてきます。
ICP用のDockerについてもIBM社から提供されますので、ICP本体とDockerファイルをダウンロードします。

  • IBM Cloud Private 3.1.0 for Linux (x86_64) Docker (CNW6SEN )
    Size : 8,839MB
  • IBM Cloud Private 3.1.0 Docker for Linux (x86_64) (CNVP4EN )
    Size : 141MB

今回これらのファイルは「/root/」に配置しています。

[root@tokyo-master01 ~]# ls -l /root total 9640628 -rw-------. 1 root root 1992 Oct 18 11:17 anaconda-ks.cfg -rw-r--r--. 1 root root 9268925381 Oct 2 10:19 ibm-cloud-private-x86_64-3.1.0.tar.gz -rwxr-xr-x. 1 root root 148057785 Oct 2 09:50 icp-docker-18.03.1_x86_64.bin -rw-r--r--. 1 root root 455008787 Sep 12 22:52 mcm-3.1.0_x86.tgz

※ ファイル名:mcm-3.1.0_x86.tgz は今回使用しません。


OSインストールで気を付けること

OSインストールではDiskパーティションの構成に気を付ける必要があります。 具体的には、「/」を250GB以上割り当てておかないとインストール時にWarningがでます。テスト用のインストールであれば、150GB程度でも動作しております。
今回の環境では下記のようにパーティションを設定しています。

[root@tokyo-master01 ~]# fdisk -l Disk /dev/sda: 322.1 GB, 322122547200 bytes, 629145600 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk label type: dos Disk identifier: 0x000c5d5b Device Boot Start End Blocks Id System /dev/sda1 * 2048 2099199 1048576 83 Linux /dev/sda2 2099200 629137407 313519104 8e Linux LVM Disk /dev/mapper/rhel_tokyo--master01-root: 268.4 GB, 268435456000 bytes, 524288000 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/mapper/rhel_tokyo--master01-swap: 23.4 GB, 23416799232 bytes, 45735936 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/mapper/rhel_tokyo--master01-home: 29.2 GB, 29183967232 bytes, 56999936 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes

インストール(Master/Worker共通)

すべてrootでログインして作業しています。


共通でやること

  • Pythonのインストール
  • Dockerのインストール
  • SSH鍵の交換
  • /etc/hostsを書く
  • SElinuxをとめる
  • Firewallをとめる
  • 再起動

Pythonのインストール

Pythonがインストールされていない場合はPythonを先にインストールします。
Pythonは3系にも対応しています。3系を利用する場合は「Python」コマンドでPython3が呼び出されるようにリンクを作成しておく必要があります。


Dockerのインストール


Dockerインストーラへの実行権限付与

ダウンロードしてきたDockerのインストーラには実行権限がないので実行権限を付与します(上記のファイルリスト上ではすでに権限を付与しています)

cd ~/ chmod +x icp-docker-18.03.1_x86_64.bin

Dockerのインストール

./icp-docker-18.03.1_x86_64.bin --install systemctl start docker systemctl enable docker

SSH鍵の交換


SSH鍵の作成

ssh-keygen -b 4096 -f ~/.ssh/id_rsa -N ""

許可された鍵のリストに追加

cat ~/.ssh/id_rsa.pub | sudo tee -a ~/.ssh/authorized_keys

各ノード間でSSH公開鍵をコピー

##サンプル ssh-copy-id -i ~/.ssh/id_rsa.pub <user>@<node_ip_address> ssh-copy-id -i ~/.ssh/id_rsa.pub root@xxx.xxx.xxx.xxx ssh-copy-id -i ~/.ssh/id_rsa.pub root@xxx.xxx.xxx.xxx

SSHの再起動

systemctl restart sshd

パスワードなしでお互いにログインできるか確認

ssh (Master or Worker IP)

SSH接続後、抜けるのを忘れずに行う

exit

/etc/hostsを指定する

/etc/hostsでMasterとWorkerが名前解決できるように設定します。

vi /etc/hosts ############# 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 # ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 # コメントアウト ## 追加する MasterIP MasterHostname WorkerIP WorkerHostName #############

SELinuxを止める

今回はざっくりと止めます。

vi /etc/selinux/config ########### # This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=disabled # enforcingからdisabledに変更する # SELINUXTYPE= can take one of three two values: # targeted - Targeted processes are protected, # minimum - Modification of targeted policy. Only selected processes are protected. # mls - Multi Level Security protection. SELINUXTYPE=targeted ###########

Firewallも止める

Firewallも止めてしまいます。

systemctl stop firewalld systemctl disable firewalld

再起動

OSを再起動します。

reboot

インストール(Master編)

ここから先はWorkerで作業をすることはありません。Masterのみで実行していきます。


DokcerコンテナのイメージをMasterに取り込む

cd ~/ tar xf ibm-cloud-private-x86_64-3.1.0.tar.gz -O | sudo docker load

※ 環境にもよりますが10~20分かかります。


取り込んだイメージの確認

docker images

※重要※イメージ名を確認

イメージ名に ibmcom/icp-inception- が含まれるイメージを確認してメモします。

docker images | grep ibmcom/icp-inception-
ibmcom/icp-inception-amd64 3.1.0-ee 481dbd525a28 4 weeks ago 744MB

ディレクトリを作成して移動

mkdir /opt/ibm-cloud-private-3.1.0 cd /opt/ibm-cloud-private-3.1.0/

イメージから構成ファイルを抽出

docker run -v $(pwd):/data -e LICENSE=accept ibmcom/icp-inception-amd64:3.1.0-ee cp -r cluster /data

ここで指定している ibmcom/icp-inception-amd64:3.1.0-ee が手順「※重要※イメージ名を確認」で確認したイメージ名になります。


作成されたフォルダ内のファイルリストを確認

ls -la /opt/ibm-cloud-private-3.1.0/cluster ### total 28 drwxr-xr-x 3 root root 4096 Sep 27 15:03 . drwxr-xr-x 3 root root 4096 Sep 27 15:03 .. -rw-r--r-- 1 root root 7452 Sep 27 15:03 config.yaml -rw-r--r-- 1 root root 104 Sep 27 15:03 hosts drwxr-xr-x 3 root root 4096 Sep 27 15:03 misc -r-------- 1 root root 1 Sep 27 15:03 ssh_key ###

クラスター内の各ノードのIPアドレスをすべて指定 /<installation_directory>/cluster/hosts ファイルに追加します。

ナレッジ︓ https://www.ibm.com/support/knowledgecenter/SSBS6K_3.1.0/installing/hosts.html

vi /opt/ibm-cloud-private-3.1.0/cluster/hosts
[master] xxx.xxx.xxx.xxx # MasterのIPを入力 [worker] xxx.xxx.xxx.xxx # WorkerのIPを入力 [proxy] xxx.xxx.xxx.xxx # MasterのIPを入力 #[management] #4.4.4.4 #[va] #5.5.5.5

※今回はProxyをMasterにインストールしています。


ICP ClusterにSSH秘密鍵をコピー

cp /root/.ssh/id_rsa /opt/ibm-cloud-private-3.1.0/cluster/ssh_key

インストールディレクトリに移動し、Imageフォルダを作成

cd /opt/ibm-cloud-private-3.1.0 mkdir -p cluster/images

作成したフォルダにインストールイメージファイルをコピー

mv ~/ibm-cloud-private-x86_64-3.1.0.tar.gz cluster/images/

コピーされていることを確認

ls cluster/images/

環境のデプロイ

cd ./cluster sudo docker run --net=host -t -e LICENSE=accept -v "$(pwd)":/installer/cluster ibmcom/icp-inception-amd64:3.1.0-ee install

ここで指定している ibmcom/icp-inception-amd64:3.1.0-ee が手順「※重要※イメージ名を確認」で確認したイメージ名になります。

インストールが完了すると下記のメッセージが表示されます。

PLAY RECAP ********************************************************************************************* xxx.xxx.xxx.xx0 : ok=164 changed=82 unreachable=0 failed=0 xxx.xxx.xxx.xx1 : ok=130 changed=62 unreachable=0 failed=0 localhost : ok=267 changed=163 unreachable=0 failed=0 POST DEPLOY MESSAGE ************************************************************************************ The Dashboard URL: https://xxx.xxx.xxx.xx0:8443, default username/password is admin/admin Playbook run took 0 days, 0 hours, 31 minutes, 27 seconds

管理コンソールログイン

インストール完了時に表示されたURLにWebブラウザでアクセスしてログインします。

  • ログインユーザー: admin
  • パスワード: admin

20181030_21h52_57




注意事項


docker loadするDockerイメージ名について

今回、Docker loadで下記のイメージ名を指定しています。 ibmcom/icp-inception-amd64:3.1.0-ee
[:]以下の値がバージョンになるのですが、このバージョンの指定が間違っていると latest のイメージをDocker Hubからダウンロードしてきてしまいます。
Docker Hubのイメージではインストールができないため、インストール時にエラーが発生してしまいます。 必ず、イメージをロード後、docker images | grep ibmcom/icp-inception- で保持しているイメージを確認してください。
※ IBM Knowledge Centerで指定しているイメージが今回利用したイメージ名と異なっているのでご注意ください。


Dockerのインストールに失敗したとき

Dockerのインストールに失敗することがあります。失敗の原因はパッケージが不足しているためですが、通常、yumが使える環境であれば自動的にパッケージをインストールします。
yumが利用できるように設定していただくか、インストールイメージもしくはDVDをマウントしていただいてDiskをyumのリポジトリとして利用できるようにしていただければと思います。



今回の内容は以上になります。次回はMulti Cloud Managerという製品を今回作成した環境にインストールしていきたいと思います。(すずきけ)

2018/10/05

導入事例に学ぶ Kubernetes を活用した次世代システム基盤

こんにちは。今回は、先日実施させていただいたセミナー 「導入事例に学ぶ Kubernetes を活用した次世代システム基盤」について セミナーの内容をご紹介したいと思います。

・・・ただ、申し訳ないのです事例については公開ができない部分があるので製品面を主体に書いていきます。

最近の動向

セミナーの題名からお気づきの方もいるかと思いますが、コンテナー基盤であるKubernetesに紐づくお話でした。

Kubernetesを利用したコンテナーの基盤は、アメリカ、ヨーロッパ、中国の順に導入が進んでおり、導入規模としてはアメリカは大規模基盤での導入が進んでいるが、日本では小規模の環境への導入にとどまっているとのことでした。

20180926_10h48_44_3

20180926_10h48_51_2


Googleでは一般提供しているすべてのサービスや社内サービスをすべてコンテナーで動作させており、週に20億のコンテナを起動しているようです。

20180926_10h55_51



なぜ、世界中でコンテナー活用が始まっているか?

牛丼的に書くと
- 軽い!
- 早い!
- 持ち運びが簡単!
です。
どれもコンテナー環境だけ(例えばDockerだけ)でもできそうですが、オーケストレーションツールであるKubernetesがあることで短時間でのスケーラビリティに対応できます。

20180926_11h04_42



Why IBM? Why Kubernetes?

Kubernetes自体はGoogleの開発でオープンソース化されているのに、なぜIBMなのか?
また、オーケストレーションツールは複数あるのになぜKubernetesなのか?

- Why IBM?
IBMはCloud Native Computing Foundation(CNCF)に設立時から参画しており、DockerやKubernetesに対してコミットしており、IBM Middlewareもコンテナー化が進んでいます。
このセミナーでは詳細の話はありませんが、IBM Cloud上にもKubernetesベースのコンテナーサービスを展開しています。
今後もオープンソースに継続して投資を行っていくと話が出ていました。

- Why Kubernetes?
スライドで「Kubernetesがコンテナ時代のソフトウェア産業を全面的に支配、大企業もCloud Native Computing Foundationに参集する」を紹介していました。
CNCFのサポートやKubernetesはもはやデファクトスタンダードになっているので、Kubernetesを使いつつ、新しい価値を生み出していく方向のようです。


IBM Cloud Privateのご紹介

動向としてコンテナー環境やKubernetesの話がされていましたが、実際にはこれら以外にも必要になるものがいくつもあります。

20180926_11h59_44


これらを一つ一つ集めていれるのは大変ですよね。。。そんなときに必要なものをまとめて提供する製品がIBM Cloud Privateになります。

20180926_12h00_40



IBM Cloud Private (ICP)はオープンテクノロジーをベースに企業の次世代システム基盤に必要となる技術を統合、All–in–oneで提供します。
ポイントは3つ

1. オープンテクノロジー
2. 充実したコンテンツ(カタログ)
3. マルチクラウド対応


オープンテクノロジー

最新の動向に記載したようにIBMとしてオープンソースに継続して投資を行っていく方針であり、投資を行いつつ、製品として昇華したものがIBM Cloud Privateに搭載されています。
具体的には、44ものOSSコンポーネントをIBM Cloud Privateに搭載し、且つOSSに対してIBMによる商用サポートを受けることができます。
コンポーネントはそろっているのですぐに利用が可能です。

20180928_14h10_16



充実したコンテンツ(カタログ)

IBM Cloud PrivateにはHelmというコンポーネントが含まれており、このHelmのカタログからコンテナーをデプロイすることができます。
このカタログも通常であれば、Googleなどが公開しているレポジトリを利用してデプロイするか、レポジトリを自分で用意してコンテナーイメージも作成する必要がありますが、IBM Cloud Privateでは最初からIBM社製品のミドルウェアについてはコンテナーイメージが用意されており、すぐにデプロイし利用することができます。

20180926_14h37_32


マルチクラウド対応

「Private」と製品名にあるようにオンプレ製品のように思えますが、クラウド(IaaS)にも対応しています。


コンテナ環境におけるストレージ選択のポイント

まずは、コンテナー環境と仮想環境でのデータの扱い方の違いです。

20180926_14h52_35



  • 仮想環境
    共有DISKなどにデータを置いているので、仮想マシンが停止した場合は別ホストで仮想マシンが起動しデータを引きつぐ

  • コンテナー環境
    通常はコンテナー上でデータを保持。コンテナーの数を保てるが不足した場合、新しくコンテナーを起動。データは引き継がれない

こういった特徴から、データベースなどデータを保管した場合は永続的ボリュームを検討する必要があります。

Kubernetesで使えるストレージの種類は2つあります。

20180926_14h57_07

Volumeではインフラを把握している必要があります。 Persistent Volumeは特にインフラを知らなくても簡単にボリュームを利用できます。

Persisten Volumeのアクセスモードとプロビジョニング方法

前項で話がでていたようにPersistent Volumeはユーザーが簡単にボリュームを利用できます。その際、Persistent Volumeにはどんな設定や動作が存在するかの説明がありました。

  • 3種類のアクセスモード

20180928_15h05_12



  • 静的プロビジョニングと動的プロビジョニング

20180926_15h07_21

20180926_15h07_30

二つの大きな違いとしてはボリュームの切り出しを管理者が自動で行うか、もしくはコンテナーをデプロイするときに自動で行うかです。


注意事項

Kubernetesに対応した外部ストレージを利⽤すると、ユーザーの利便性を⾼めつつ、管理者の負担を抑えることが可能です。
Persistent Volumeの動的プロビジョニングを使うことで永続的ストレージを必要な分だけ払いだしたり、データは外部ストレージにあるので、外部ストレージのもつ便利な機能(QoSやスナップショットなど)も使うことができます。

注意事項ももちろんあります。

  • ベンダーによる対応の違い
    サポート状況(OSSでの提供でベストエフォートな場合も)
    使える機能の違い
    Kubernetesは⾼度なストレージ管理のオプションを提供していないベンダー独自の実装でオプションが追加されていたり、Kubernetesの外部からストレージ機能を呼び出せることもある

  • Kubernetesのアップデートが早い
    ストレージ対応状況や新機能など刻々と変化
    正式リリース前の機能も追加されているContainerStorageInterface(CSI)v1.9からアルファ版が含まれる

    IBMならどうなのか?

IBMのSpectrum Connectというコンテナとストレージをつなぐソフトウェアを利用してFlashSystemを使うことができます。

20180926_15h46_56



ICP on VersaStackによるプライベートクラウドの構築

VersaStackを利用したICP環境の紹介と実際にICP環境上にコンテナーをデプロイし、データを外部ストレージに保存し、コンテナーが一度削除されてもデータが残っていることを確認するデモを行っていました。

VersaStackとは?

サーバーハードウェアはCisco UCS、ストレージシステムはIBM Storwizeストレージ・システムを組み合わせたソリューションです。

IBM Cloud Privateとしては、IBM Cloud Private用のOSとしてRedhat Enterprise LinuxをUCS上に構成し、Storwize ストレージシステムをIBM Cloud Private上のPersistent Volumeとして利用することを想定しています。

Persistent Volumeを実現させるためのSpectrum Connect

前項の最後にあったSpectrum Connectについて説明がありました。

20180926_16h54_54

IBM Cloud Private ⇔ Spectrum Connect ⇔ Storwize StorageSystem
となり、IBM Cloud Private とStorwize の橋渡しをしてくれます。

検証デモ

検証では、本当にPersistent Volumeにデータは保存されているのか?ちゃんとコンテナーが再作成されてもデータは保持されるのか?という観点で行いました。

デモ時のシナリオと動画をこっそりもっているのでここで公開してみます。


YouTube: IBM Cloud Private検証動画


デモ動画が行っている内容はこちら。

なにをするか?

  • この記事を作成、保存し、Wordpress上で閲覧できる状態にします。
  • Wordpressが稼働している状況でのICPコンソール上のステータスを確認
    • ワークロード→デプロイメントのステータス確認
    • プラットホーム→ノードのステータス確認
  • 閲覧できる状態からWordpressコンテナ+MySQLコンテナが動くWorkerノードを停止
    • 停止はVMwareのRemote ConsoleからHaltコマンドを実行
  • Wordpressに接続できない状況の確認とICPコンソール上でのステータスを確認
    • ワークロード→デプロイメントのステータス確認
    • プラットホーム→ノードのステータス確認
  • 停止したWorker Nodeを起動
    • VMwareのRemote Consoleから起動
    • OSにログインできることとHostnameを確認。(Worker3)
  • ICPコンソール上でWorkerとコンテナのステータスを確認
    • プラットホーム→ノードのステータス確認
    • ワークロード→デプロイメントのステータス確認
      注意事項 Persistent Volumeを使っている場合はUbiquity(デプロイメントの名前空間”Ubiquity")が動作している必要があります。
  • Wordpressに接続し、この記事が表示されることを確認



最後に

次世代基盤としてのコンテナーの最新の状況から、IBMの提供コンテナー基盤環境とそれに紐づくソフトウェア、ハードウェア、ユースケースのご紹介と、本当に動くのか?というところを含めたデモを実施したセミナーとなっておりました。

最低限システムをご理解いただくための内容としていますので、詳細を聞きたい!などご要望がございましたら、ぜひぜひご連絡ください。
versastack-info@networld.co.jp


最後まで読んで頂き有難うございました!
すずき(け)

2017/12/28

IBMでコンテナ化されたクラウドに力を~IBM ITインフラブログより引用~

本記事のIBM社のPower Systems Cloud Offering ManagerのAlise Spence氏によってIBM IT Infrastructure Blogに投稿されたものからの引用です。

原文を参照したい方はPower your containerized cloud with IBMをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

Fig348

先月、IBMは新たなオンプレミス用のIBM Cloud Privateを発表しています。

このIBM Cloud Privateについては以下のように表現されています。

An innovative and revolutionary platform-as-a-service (PaaS) offering, IBM Cloud Private incorporates the best of open source tools, including Kubernetes container orchestration, with the unique IBM values that enterprises need to be confident in a secure, compliant and performant private cloud platform.

革新的かつ革命的なプラットフォーム-アズ-ア-サービス(PaaS)製品で、IBM Cloud PrivateはKubernetesのコンテナオーケストレーションを含む最高のオープンソースツールをIBMの付加価値である企業に求められるセキュアでコンプライアンスを満たし、パフォーマンスについても確信を持って利用できるプライベートクラウドプラットフォーム上で動作させることができるようになっています。

IBM Power Systemsをネイティブにサポートしており、競合との差別化は以下のような点があげられます:

  • Developers can create blazing-fast apps by deploying cognitive services on hardware optimized for the work at hand, for higher container density and better throughput.
  • Apps that integrate new cloud-native apps and services with core business data on enterprise systems can be co-located with near-zero latency.
  • Data center administrators can deploy Cloud Private on their choice of Power servers including the IBM Hyperconverged Systems powered by Nutanix, LC servers and enterprise servers with PowerVM.
  • 開発者は高いコンテナの統合率と優れたスループットのためのハードウェアに最適化されたコグニティブサービスを展開することで、非常に高速なアプリケーションを作成することができる
  • 新しいクラウドネイティブなアプリやサービスを統合するアプリケーションとエンタープライズシステムのコアビジネスデータをほとんど遅延のない場所に共存させることができる
  • データセンタ管理者はCloud PrivateをIBM Hyperconverged Systems powered by Nutanix、LCサーバ、そしてPowerVMを搭載したエンタープライズサーバを含むPowerサーバの中から選んで展開することができる

それぞれを詳しく見ていきましょう。。

Want to accelerate the speed of your apps? Our optimized hardware puts you in the driver’s seat with higher container density and better throughput.(アプリのスピードを高速化したい? 最適化されたハードウェアがより高い統合率のコンテナ、より良いスループットへと皆様をお連れいたします。)

A properly configured cloud environment delivers efficiency–a huge benefit to any business, especially when delivered by platform performance. Optimized for cognitive services, Power Systems can deliver insights faster. How? Because of fewer systems and improved horizontal and vertical scalability. The IBM POWER9-based AC922 delivers 3.8 times the reduction in AI model training times[1]. Other Power System servers deliver similar performance gains, all leading to faster and more accurate results for next generation deep learning workloads.

And with multi-architecture support for Docker containers, developers can easily control and automate which platform to deploy specific containers to for best results.

適切に構成されたクラウド環境が効率性を提供します ー あらゆるビジネスにとって巨大なメリットです、特にプラットフォームにパフォーマンスがもたらされた場合には。コグニティブサービスに最適化されたPowerシステムは知見をより高速に提示します。どうやって? 選りすぐったシステムと改善された水平、垂直の拡張性によって、です。IBMのPOWER9ベースのAC922はAIモデルの教育時間を3.8倍も削減することに成功しました(*)。他のPowerシステムサーバも同様のパフォーマンス向上を示しており、全ての次世代のディープラーニングのワークロードをより早く、正確な結果へと導いています。

Dockerコンテナをマルチアーキテクチャでサポートすることで、開発者は最良の結果のためにどのプラットフォームへどのタイプのコンテナを展開するかということを制御、自動化することができます。

Integrate modernized cloud-native apps and services with core business data(コアビジネスデータを最新のクラウドネイティブアプリと統合)

Top enterprises use Power Systems for their most critical business data. Frequently, industry or government regulations are forcing them to find ways to make data more accessible while maintaining their required data security and availability. IBM Cloud Private on IBM Power Systems enables enterprises to create or modernize applications while providing tight integration with the critical data that applications require. By co-locating apps and data, clients will see near-zero latency when integrating with data stores managed in Linux, AIX, or IBM i environments.

トップ企業がそのもっとも重要なビジネスデータのためにPowerシステムを利用しています。よくあることとして業界や当局が標準仕様としてデータに必要なセキュリティと可用性を維持しながら、一方でデータへのアクセス性をより高めるような方法を探すべし、としていることがあります。IBM Powerシステム上のIBM Cloud Privateは企業がアプリケーションが求める重要なビジネスデータの緊密な統合を実現しながら、企業がアプリケーションを作成、もしくは近代化することができるようにします。アプリケーションとデータを同一の場所に格納することで、クライアントからはLinux、AIXもしくはIBM iの環境に管理保管されているデータと連携する際もほぼ遅延のないアクセスを実現することができるのです。

Deploy new cloud native apps on choice of infrastructure, including IBM Hyperconverged Systems powered by Nutanix(IBM Hyperconverged Systems powered by Nutanixを含むインフラストラクチャから新たなクラウドネイティブアプリを展開先を選択できる)

IBM Cloud Private runs across the entire IBM Power Systems portfolio, POWER8 or above, requiring a little endian partition running any flavor of Linux. Clients wishing to leverage existing systems or skills can deploy Cloud Private into PowerVM LPARs. Clients looking to maximize performance for AI or data scientist workloads can opt for bare metal support on OpenPOWER systems. And clients looking to build out new infrastructure in support of new services can get the fastest time-to-value with minimal effort using IBM Hyperconverged Systems powered by Nutanix.

IBM Cloud Private for Power Systems Starter Kits makes it quick and easy to get started. These kits offer implementation guidance that helps organizations to get up and running quickly on their choice of Power Systems infrastructure: OpenPOWER scale-out, enterprise servers, or hyperconverged. When ready, clients can leverage a choice of service-optimized Power Packs, which are Reference Architectures to expand compute capacity and deploy production-ready HA clusters.

Click here to learn more about IBM Cloud Private and try the software, or click here to learn more about cloud solutions like IBM Cloud Private on IBM Power Systems and download a solution brief.

IBM Cloud PrivateはIBM Power システムのPOWER8以降のリトルエンディアンのパーティショニングを稼働させているあらゆるLinuxのすべてのポートフォリオで動作します。既存のシステムを活用する事もできますし、もしくはスキルさえあればCloud PrivateをPowerVM LPARS内に展開することもできます。AIやデータサイエンティストのワークロードの性能を最大化したい場合にはOpenPOWERシステムのサポートの元ベアメタルを利用することもできます。そしてもっとも価値創出までの時間の短い、新しいインフラを最小の労力で作成したいという場合にはIBM Hyperconverged Systems powered by Nutanixをつかうとよいでしょう。

IBM Cloud Private for Power Systems Starter Kitsを利用すれば、素早く、簡単に始めることができます。こうしたキットは実装のガイダンスが記載されており、ご自身の選択したPower システムインフラストラクチャ(OpenPOWERのスケールアウト、エンタープライズサーバ、またはハイパーコンバージド)の稼働開始、稼働の手助けとなります。準備ができたら、サービスに最適化されたPower Packを選び活用することもできます。これにはコンピューティングキャパシティの拡張や本稼働系を展開する際の高可用性クラスタのためのリファレンスアーキテクチャが含まれています。

IBM Cloud Privateについてより詳しく学ぶ、もしくはソフトウェアの試用については こちら をクリック。または こちら をクリックして、IBM Cloud Private on IBM Power Systemsなどのソリューションについて詳しく調べたり、ソリューションブリーフをダウンロードして下さい。

もしもアプリケーションの近代化でどれほどスピードが上がるのかを知りたいのであれば、以下のライブウェブキャストにもご参加下さい :

Bring the Changes Your Customers Want: application modernization and agility with IBM Cloud Private on Power Systems(お客様の要求に変化をもたらす : IBM Cloud Private on Power Systemsでアプリケーションの近代化と俊敏性を)

Time and Date:  11:00 AM EST, January 11, 2018 (日本時間 :2018年11月12日1:00 AM)

Register here. https://event.on24.com/wcc/r/1560084/CF1B4670D48B2BAD72B54C8CD25C8A83

(*) •Results are based IBM Internal Measurements running 1000 iterations of Enlarged GoogleNet model (mini-batch size=5) on Enlarged Imagenet Dataset (2240×2240) .

  • Power AC922; 40 cores (2 x 20c chips), POWER9 with NVLink 2.0; 2.25 GHz, 1024 GB memory, 4xTesla V100 GPU ; Red Hat Enterprise Linux 7.4 for Power Little Endian (POWER9) with CUDA 9.1/ CUDNN 7;. Competitive stack: 2x Xeon E5-2640 v4; 20 cores (2 x 10c chips) /  40 threads; Intel Xeon E5-2640 v4;  2.4 GHz; 1024 GB memory, 4xTesla V100 GPU, Ubuntu 16.04. with CUDA .9.0/ CUDNN 7 .

記事担当者: マーケティング本部 三好哲生 (@Networld_NTNX

Ntc2017_2

本当は年明けに・・・と思っていたのですが、1月12日の深夜1時からのIBMさんのウェブセミナーの告知も含まれていたので、こんな日にも記事を出しております、ゴメンナサイ。

Nutanix担当の目線でいくと、Nutanix on Powerの上で、IBM Cloud Privateを動作させれば、「Googleのようなウェブスケールなインフラ上でIBMのクラウドが動く」という事になります。重要なデータをAIやコグニティブサービスを使ってビジネスに活用していく、こうした世の中だからこそのプラットフォームだと思います。

2017/12/13

ADSでAHVの仮想マシンをスケジュールすることが何故、他と違うのか? ちょっと解説してみる

本記事はNutanix Advent Calendar 2017への寄稿も兼ねております。是非アドベントカレンダーの他の記事もお楽しみください。

本記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社のSr Product Marketing ManagerのMike Wronski氏によるものです。原文を参照したい方はA Quick Explanation of What Makes AHV Virtual Machine Scheduling with ADS So Uniqueをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

Fig298

エンタープライズの仮想化についてよく知っている人であれば誰でも一定の効果を期待しています。その効果の中には仮想化プラットフォームがリソースの利用を最適化し、優れたパフォーマンスを保証する機能を提供するということも含まれています。VMwareにとってはこれはvCenter内の分散リソーススケジューラー(もしくは一般的にDRS)と呼ばれるコンポーネントです。MicrosoftではSystem Center Operations Manager(SCOM)のリソース監視とSystem Center Virtual Machine Monitor(SCVMM)を組み合わせて活用するパフォーマンスリソース最適化(PRO)ということになります。

多くの人がリソース最適化はハイパーバイザーの機能であると誤解しています。が、実際にはこれは管理プレーンからイベントドリブンで発生する自動化機能なのです。必要となる唯一のハイパーバイザーの機能は仮想マシンを別のサーバーへ停止なしに移行させる機能だけです。データの収集し、「悪い状況」の検知、それから何らかのアクションを行うとうことは外部の管理機構が行うもので、ハイパーバイザー自体が行うものではないのです。

Nutanix AcropolisソフトウェアとAcropolis Hypervisor(AHV)を組み合わせたソリューションは他の仮想化ソリューションとは異なります。これは特にAcropolis Dynamic Scheduler(ADS)を利用する場合に顕著です。その理由は:

ロードバランサーではない

なによりも声を大にしてお伝えしなければいけない1つめはADSはリソースの競合を回避するためのエンジンであって、ロードバランサーではないということです。ロードバランサー単体は大した効果を提供してくれるものではありません。仮想マシンをクラスタ内のサーバ間で移動させるという作業はパフォーマンスへの影響が出るほとにリソース競合が発生しているときのみに限定すべきです。これは移動自体がリソースを多く消費するからです。ADSは仮想マシンをその移動がその移行に見合うだけの充分な効果を得られると判断した場合にのみ移動させます。

構成不要

ADSの他にはない差別化要素としての1つは管理者が構成すべきものは何一つないというところです。ADSは標準で有効となっており、機械知識ベースの実装によって一切の人的なチューニングを必要としません。Nutanixはこの機械知識の機能をXfitと名付けてグループ化しており、Prism管理ソフトウェア内で複数の機能に渡って利用しています。ADSはConstraint Satisfaction Problem(CSP ー 制約充足問題) ソルバー(解決器)と呼ばれる人工知能アルゴリズムのクラスを利用しています。CSPソルバーは幾つかの変数をベースにモデルを作成し、最終状態の許容範囲を定義してから、変数を繰り返し変更しながら、回答を探し出します。実装の洗練具合によっても違いますが、総当り的なものや、経験則に基づいて特定の部分だけを探す場合や、妥当な回答を導き出しやすくするためにフィードバックループを利用する場合もあります。一般的なCSPのプログラムの例としてあげられるのはパズル数独を解くというものでしょう。AHVの世界では回答とは仮想マシンの移行を計画するということで、クラスタからリソースの競合またはホットスポットを取り除くという事になります。

これまでに無い可視性

我々はスタック全体を提供しています。HCIインフラストラクチャから我々が開発するAHV、管理、そして自動化に至るまで。これによってNutanixは従来型の仮想化のインフラでは持ち得なかった、他にはない知見を得る事ができます。例えば、ADSはAHVから仮想マシンのリソースの利用状況を得るだけではなく、ストレージリソースをCVMコントローラーから得ることができます。従来型の3階層のアーキテクチャのストレージコントローラーを考えてみて下さい。将来的にはネットワークからアプリケーションレベルの知見に至るまで、他の入力についても考慮するようになります。

Fig299

仮想マシンの「アドバイザー」

ADSはリソースの競合の解決に利用されるだけではありません。ADSは新しい仮想マシンの配置自体がリソースの競合を発生させないということを保証し、理想的な配置はどこであるかということを提示します。ADSサービスは定期的に時系列データをチェックし、リソースの競合を見つけ出します。競合を見つけるとCSPソルバーが問題を解消するための回答となる仮想マシンの移行ソリューションを提示します。ソルバーはリソースの競合を入力として考慮する他、守らなければならないすべての仮想マシン、またはホストのアフィニティルールも加えて考慮して、移行に際して消費するリソースを最小に保ちながら最適な回答を導き出すのです。仮想マシンの移行自体がリソースを消費するということを思い出して下さい。消費されるリソースの殆どはアクティブなRAMの以降です。ソルバーは割り当てられているメモリの大きな仮想マシンよりも小さな仮想マシンの移行をオススメしてきます。

回答が見つかったら、仮想マシンが移行され、イベントとしてログに保存されます。最適な回答がない場合には、管理者がそれ以上の対応を行えるようにアラートとアラームがPrismへ発報されます。Prism Proはこれに加えて仮想マシンの移行だけでは解消できない競合を解決するためにリソースの回収とノードの拡張についてのレポートと分析を提示てくれます。ですが、これについては別の記事にしましょう。

ADSの他にはない実装は唯一つの目的だけのために設計されています : 管理者とアプリケーションオーナーの人生をより生きやすい人生に ー 複雑性を取り除くだけでなく、自動化と機械学習を活用することで継続的に最適なアプリケーションパフォーマンスを保証します。Nutanixは今後Software Defined Networking(SDN)やパブリッククラウドの管理へも拡張していきます。他にどんなデータをADSのエンジンに考慮させるべきでしょうか? ぜひフォーラムの我々の会話として継続議論しましょう。

What other metrics could be fed into the ADS engine as Nutanix expands into software defined networking (SDN) and public cloud management? We encourage you to continue that discussion on our forum. 

© 2017 Nutanix, Inc.  All rights reserved. Nutanix, AHV, and the Nutanix logo are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. All other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s).

記事担当者: マーケティング本部 三好哲生 (@Networld_NTNX

Ntc2017_2

ADSの中身をちょっと見てみよう・・・イキナリ出てくるのが制約充足問題です。この制約充足問題というのは実は厄介な問題でして、「一定の条件をクリアできる組み合わせを探しなさい」というたぐいのものです。つまり組み合わせは何種類もあって、もっと良い形もあるかもしれない・・・という問題なわけです。計算もややこしいもの(下手をすれば総当たり的なもの)になりますので、そのリソースも馬鹿になりません。つまり、現実的には「現実的なリソース消費の中で」「現実的な時間内で」「(最高ではないにしろ)なかなかのレベルで」答えを見つけると、こういう話になります。NutanixのCSPソルバーではおそらく様々なヒューリスティック(経験則)をもとにこれを実現しているのだと思います。

しかし、機械学習、人工知能盛り上がっていますね。当社も何らかのアクションをということで、現在IBM Watson Application Developerの資格保有者を増やしています。IBMといえばNutanix on Powerも有りますので(Nutanixの機能としてではなく、お客様の業務の効率化のための)人工知能がNutanixの上に今後どんどん乗ってくると思います。

↓ せっかく取れたし、今回AIっぽい内容なので、載せておきます。

Watsonv3appdevprofcertification

2017/05/31

データセンタにさらなる自由を(NutanixがIBMをOEMパートナーへ)

本記事はNutanix社のオフィシャルブログの翻訳版です。原文を参照したい方はFurther Liberation of the Data Centerをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら

1980年代のオープンシステムの夜明けとともに、IBMはデータセンタコンピューティングに新しい自由をもたらしました。前世代に当たるミニコンピューターとメインフレームのプロプライエタリのサイロを超え、IBMはPOSIX準拠のソフトウェアスタックとの相互互換性を備えるUNIXオープンシステムを先駆けたのです。これによって異なるベンダーのUNIX OS感を乗り換えることは非常に簡単なものとなりました。2001年、IBMはSystem pや他のプラットフォーム上でのLinuxを発表し、RISCベースのPowerアーキテクチャの先進性によって更にその自由を推し進めました。今日我々はIBMとともにNutanixエンタープライズクラウドプラットフォームソフトウェアをIBM Powerシステム上で動作させ、その自由をさらに拡張する計画を発表しました。設計計画によると、IBMをご利用のお客様はご自身のデータセンタ内でパブリッククラウドのような簡単さを利用することができるようになります。

エンタープライズクラウドプラットフォームによって、IBMを利用されているお客様は容易な拡張性、インフラストラクチャ展開の簡便性、そしてGoogleやMicrosoft AzureそしてAmazon Web Servicesにインスパイアされた管理を利用でき、しかもそれをオンプレミスに置くことができるのです。Nutanixが5000社以上、100カ国に渡って提供しているシンプルさと柔軟性と同じものがIBMのグローバルIT顧客において利用できるようになるのです。

IBM-NutanixのハイパーコンバージドシステムはIBM WebSphereアプリケーションサーバ(WAS)や数々のオープンソースデータベース(OSDBMS)はもちろんのこと、IBMがコグニティブコンピューティングと称している高いパフォーマンスが必要となる予測的な分析を行うワークロード向けにフォーカスされたものです。

WASはハイブリッドクラウドの能力とともにアプリケーションインフラストラクチャを最適化し、コスト削減をもたらします。開発フレームワークとしてもWASはクラウドーネイティブ、ウェブベース、そしてマイクロサービスの開発に利用されており、アプリケーションをあらゆるクラウド、あらゆるコンテナサービスをまたいで管理するのに利用されています。

それだけではありません、IBMによると「2018年までに70%以上の自社開発アプリケーションはOSDBMS上で開発されるようになり、50%の商用RDMBSインスタンスは置き換わってしまう」(https://www-03.ibm.com/systems/power/hardware/upgrade/)とのことです。リレーショナルRDMSによるエンタープライズデータベースの話を聞く一方でMongoDB、Neo4J、Redis Labsなどの名前をNoSQLとして耳にすることもよくあると思います。

急成長するワークロード、コグニティブコンピューティングは「・・・人間の思考のプロセスをコンピュータ化されたモデルでシミュレーションする。コグニティブコンピューティングはデータマイニング、パターン認識を利用する自己学習システム、人間の脳の働きを模倣する方法での自然言語処理を含みます。コグニティブコンピューティングの目的は、人間の手助けなしに問題を解決する能力を持った自動化されたITシステムを生み出すことです。コグニティブコンピューティングはエキスパートシステム、自然言語プログラミング、ニューラルネットワーク、ロボット工学、そして仮想現実などの膨大な数の人工知能(AI)アプリケーションで利用されています。」(http://whatis.techtarget.com/definition/cognitive-computing)

これはコンピューターができる最大限のことを更に拡張しようー 大きな規模においてもタスクをシンプル化しよう ー というNutanixのアプローチと全く方向性が同じです。IBMを利用しているお客様が膨大な量のばらばらのデータを捕まえて収集し、分析を施すことで人間が一人もしくはチームで考えるだけでは常識的な時間の範囲内では到底及びもつかないパターンを見つけ出したり、他の推薦事項を導き出したりしています。基本的に自動化のプロセスは人間を退屈なタスクから開放し、もっと付加価値の高い業務へと集中させてくれます。コンピューティングが継続的に進化しつづければ、たとえデータが不完全であったとしてもコンピューターはもっと人間らしい思考(これがコグニティブコンピューティング)をすることができるようになります。同様にNutanixもこうしたコンピューティングの不条理さを押さえ込む努力を続けています。NutanixのChief ArchitectであるBinny Gill氏はこれをIntentful Machines(訳注: 気の利く機械)と呼んでいます。(https://www.linkedin.com/pulse/towards-intentful-machines-building-next-generation-binny-gill)

IBMはNutanixのエンタープライズクラウドプラットフォームを活用はハイパーコンバージドインフラストラクチャや今やITアーキテクチャの主流となったハイブリッドクラウドを確認だけにとどまりません。Enterprise Strategy Groupの新しい調査結果は以下のとおりです:

  • 87%のHCIユーザーはHCIを利用することでITの俊敏性が増したと感じています(25%は劇的に俊敏性が増したと回答)
  • 73%の回答者はHCIがクラウドライクな、またはIT-as-a-serviceをより広く展開するための重要な役割を担うと回答しています(44%はHCIがクラウドライクな、またはIT-as-a-serviceを提供するのに最高の環境だと回答しています)

(ESG Research, Converged & Hyperconverged Infrastructure Trends Survey, May 2017)

コグニティブコンピューティングがシンプル化そしてエンタープライズクラウドの拡張性と結合することでお客様はEnterprise Strategy GroupのSenior AnalystであるTerri McClureが「コグニティブクラウド」と呼ぶものを実現できるようになります。言い方を変えるとIBMとNutanixのコラボレーションによって予測的な分析のパワーをハイパーコンバージェンスによるモジューラー型の拡張性とインフラストラクチャ管理の一元化とともに提供し、コグニティブコンピューティングを現実的に実現できる環境を展開できるということです。

IBMをご利用のお客様はOSDBMS、WAS、そしてコグニティブコンピューティングの能力をNutanixが地球上の数千にも及ぶ環境で実証してきたよく利用されているERP、CRM、VDI、ユニファイド・コミュニケーションなどで利用される商用アプリケーションと組み合わせることができるのです。

こうしたNutanixのお客様はAcropolisの共通データ、AHVハイパーバイザーを含むコンピューティングファブリックを活用することができます。そしてNutanixのPrism Centralを利用すれば多くのクラスタをーそれがPowerであれx86アーキテクチャであれー単一の中央コンソールからすべて管理することができます。

この共通性と利用の簡単さはNutanixがその裏でインフラストラクチャをインビジブルにし、お客様はビジネスの競争力の源泉となるアプリケーションやサービスにフォーカスできるようにしているからこそです。Nutanixとのコラボレーションによって、IBMは再度データセンタに自由をもたらそうとしているのです。

© 2017 Nutanix, Inc. All rights reserved. Nutanix, the Enterprise Cloud Platform, and the Nutanix logo are trademarks of Nutanix, Inc., registered or pending registration in the United States and other countries.

Disclaimer: This blog contains links to external websites that are not part of Nutanix.com. Nutanix does not control these sites and disclaims all responsibility for the content or accuracy of any external site. Our decision to link to an external site should not be considered an endorsement of any content on such site.

Forward-Looking Statements
This blog includes forward-looking statements concerning our plans and expectations relating to our relationship with IBM and the deployment of our software on, and interoperability of our software with, IBM Power Systems. These forward-looking statements are not historical facts, and instead are based on our current expectations, estimates, opinions and beliefs. The accuracy of such forward-looking statements depends upon future events, and involves risks, uncertainties and other factors beyond our control that may cause these statements to be inaccurate and cause our actual results, performance or achievements to differ materially and adversely from those anticipated or implied by such statements, including, among others: failure to develop, or unexpected difficulties or delays in developing, new product features or technology on a timely or cost-effective basis; the introduction, or acceleration of adoption of, competing solutions, including public cloud infrastructure; a shift in industry or competitive dynamics or customer demand; and other risks detailed in our quarterly report on Form 10-Q for the fiscal quarter ended January 31, 2017, filed with the Securities and Exchange Commission. These forward-looking statements speak only as of the date of this blog and, except as required by law, we assume no obligation to update forward-looking statements to reflect actual results or subsequent events or circumstances.

記事担当者: マーケティング本部 三好哲生 (@Networld_NTNX

Ntc2017_2

さて、今回はNutanix社とIBM社がコラボレーションするという記事です。まさかの展開、この展開を予想されていた方はいなかったのではないかと思います。さすがNutanixさん。AHVをPowerプロセッサでも動作できるようにすることでPowerプロセッサに最適化されたOSDBMS、WASはもちろん、IBM社のもつ巨大なコグニティブコンピューティングの資産をベストな組み合わせで利用することができるだけでなく、上に述べられているようにx86アーキテクチャ上で動作しているワークロードとデータ連携も可能ですし、Prism Centralで全体を一元管理することも可能です。

RICSとCISCの話・・・ビッグエンディアンやリトルエンディアンをどう変換する?など色々と気になることもたくさんですが、もっと詳細がでてくるのは6月の.NEXTでしょうか?最新情報を掴みましたらまたご報告いたします。

え? なぜIBMのOEMなのにネットワールドが翻訳ブログを書いているのかって!? ネットワールドはIBMのディストリビュータとしてパートナー様へ今回登場したコグニティブコンピューティングを含むソフトウェアはもちろん、IBMハードウェア(Nutanixソフトウェア搭載)の販売も可能(になるはず)です。すべてのNutanixの国内ビジネスはネットワールドにおまかせください!

2016/12/12

最新鋭、IBM FlashSystem A9000を大解剖!

IBMの最新鋭の超高速フラッシュストレージ FlashSystem A9000をお借りしちゃいましたっ。


驚きのデータ削減!あらゆる電力喪失に対応する究極の電源機構!
何処をとってもワンランク上のA9000ですが性能も機能も一味違います!!
その噂の真相を確かめるべく、検証も次のステージへっ。

7vocbqxlurq9an61481180153_148118042


ここからはお待ちかねのA9000の持つ機能や性能について
さらに切り込んでいこうと思うっ♪


で、今回はズバリ QoS ですっ♪

クラウド基盤好きには、ハズせないマストアイテムがこのQoS
このA9000!、次のスケジュールもパンパンで、お借りできる期間もあとわずかっ!
限られた時間内(いろいろな検証の合間を縫ってこっそり決行っ!)に出来る限りの検証をおこなってみたよっ♪

ちなみにQoSってなにっ?って人もいると思うので簡単に説明しようっ。
QoSとは Quality of Service(クオリティ・オブ・サービス) の略でザックリ言うと
その名の通り、「サービスの品質!」 要は「ユーザーを満足させられる度」みたいな意味になりますっ。

したがって、ここで言うQoSは「ストレージアクセスの品質」ですねっ♪
例えば、「社内で野放しのワークロードが蔓延りクリティカルアプリケーションに影響がでてる!」のような
他の利用者の大きなI/Oに影響を受けるいわゆる“ノイジーネイバー”問題っ。
QoS 機能はこういった問題を解消するために無くてはならない機能っ!。

A9000/A9000Rの
QoS機能は、接続先ごとのプライオリティーに応じて
柔軟できめ細やかな設定が可能ですっ。
例えばこの図ように「帯域」または「IOPS」を設定したり、また「その両方」を設定することもできます。
もちろん単一ボリューム単位だけでなく、複数のボリュームでシェアしたり
ストレージプール単位での設定だって出来ちゃいますっ♪

A9000qostest001


更にA9000/A9000Rは管理アカウントまで独立したマルチテナンシー機能も搭載され
クラウド基盤、クラウドサービス、そして流行のVDI環境にも最適な一台です!!

それでは、A9000の QoS機能の検証結果をご覧くださいっ♪

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

検証が進むにつれ

筆者はこの「グリッドコントローラー」の完成度の高さに驚いているっ。
特にパフォーマンスに関しては、驚きの結果(本当に想定外です。)を次々とたたき出してますので

そのへん、次回にでもお見せできればと思いますっ。


                        by:まいけル