2019/01/18

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

みなさん、こんにちは。

Workerの追加のエントリで x86 Linux版とつけていましたが、このエントリのためでした。
先日、Power 9が搭載されている Newell が納品され、Redhat Enterprise Linuxがインストールされたタイミングで、こっそり借りることができたので、ICPのWorkerとして追加してしまいました。

追加方法は IBM Cloud Private 3.1.1 Workerを追加してみよう(x86 Linux版) とほぼ変わりません。
異なる点とテスト方法についてのみ書いていきます。

追加するNewell環境

環境は下記になります。


# hostnamectl
   Static hostname: Newell
         Icon name: computer
        Machine ID: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
           Boot ID: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  Operating System: Red Hat Enterprise Linux
       CPE OS Name: cpe:/o:redhat:enterprise_linux:7.5:GA:server
            Kernel: Linux 4.14.0-49.el7a.ppc64le
      Architecture: ppc64-le

  
# python --version
Python 2.7.5  


IPアドレスは xxx.xxx.xxx.6 です。

手順概要

手順の大枠はx86 Linux版とほぼ変わりません。

    追加するノードでは下記の事を行います。
    1. 通信ポートの確認  
    2. SE Linux の無効化、Firewallの無効化  
    3. /etc/hostsを設定  
    4. 時刻の同期  
    5. Python のインストール(の確認)  
    6. Dockerのインストール  
    7. (後から作業) sshサービスの再起動  

    Master Serverで行う作業  
    実際のインストール作業については既存のMaster Serverから行います。  
    - SSH Keyのコピー
    - (後から作業) sshサービスの再起動  
    - バイナリーファイルの確認
    - Workerの追加 

異なる点は Power用のバイナリを用意する必要があります。

  • ICP本体
    IBM Cloud Private 3.1.1 for Power Linux LE (64-bit) Docker (CNZ4XEN )
    Size : 11,108MB

  • Docker
    IBM Cloud Private 3.1.1 Docker for Power Linux LE (64-bit) (CNXD3EN )
    Size : 108MB


Dockerのバイナリは追加するノードへのインストールで利用します。
ICPのPower用バイナリは /(installation_directory)/cluster/images に配置します。
下記がKnowledge Centerの情報です。

https://www.ibm.com/support/knowledgecenter/ja/SSBS6K_3.1.1/installing/add_node.html#worker

    Ensure that the installer for the platform that the new node runs on, is available in your //cluster/images directory.
    For a Linux® 64-bit node, you need the ibm-cloud-private-x86_64-3.1.1.tar.gz or ibm-cp-app-mod-x86_64-3.1.1.tar.gz file.  
    For a Linux® on Power® (ppc64le) node, you need the ibm-cloud-private-ppc64le-3.1.1.tar.gz or ibm-cp-app-mod-ppc64le-3.1.1.tar.gz or file.  
    For a IBM® Z worker node, you need the ibm-cloud-private-s390x-3.1.1.tar.gz file. 


Worker追加手順

今回は事前準備が終わった状態で、Master Server上にバイナリーファイルをコピーまでが終わった状態の想定でバイナリーファイルの確認から行います。

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

Power用の ibm-cloud-private-ppc64le-3.1.1.tar.gz が配置されていることを確認します。


下記コマンドを実行し、Workerの追加を行います。
実行コマンドは x86 Linux版のときと全く同じです。

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.6 


動作確認


管理コンソール上で確認

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

20190118_11h42_11a


アーキテクチャー部分が ppc64le となっているものがPowerのノードです。


ノードの動作確認

次に実際にPodが追加したWorker上にスケジュール(動作)するか確認してみます。
x86 Linuxの場合は仕込みをして確認しましたが、今回は仕込みをせずにHelmを利用する際にパラメーターを変更して対応します。

管理コンソール右上の カタログ をクリックします。 検索部分で Liberty といれると、Web Sphere LibertyOpen Liberty が表示されますので、 Open Liberty を選択します。

20190118_11h50_14a


Open Libertyの情報が表示されますので、構成 をクリックします。

20190118_11h50_21


パラメータを指定してデプロイします。

  • Helmリリース名 : 任意の名前
  • ターゲット名前空間 : Default
  • ポッドセキュリティー : 入力なし
  • 使用許諾条件 : チェックをつける
  • すべてのパラメーターを開く
    • Architecture scheduling preference
      -> ppc64le scheduling preference
      -> 3 - Most preferred


20190118_11h51_57a_2


すべて入力後、インストール を実行します。


ポップアップが表示されたら Helmリリースの表示 をクリックします。
Helmリリースのステータスが表示されます。
Containerの作成が完了するまで少し待ち、デプロイメント項目にリストされているデプロイメントをクリックします。
※今回であれば power-openliberty-test1 です。

20190118_11h55_17a


表示された画面の ポッド 部分を確認します。
ホストIPが PowerのWorker Nodeとなっていることを確認します。
この画面上では xxx.xxx.xxx.6になります。

20190118_11h56_24a


以上になります。
せっかくのPowerのWorkerですので、できる範囲で検証を公開していきたいと思っていますのでご期待ください。


ご案内

今回利用したPowerの機器(Newell)ですが、弊社の Networld ディープラーニング検証センターにて無料でご利用いただくことが可能です。

https://www.networld.co.jp/solution/ibm-hardware_nvidia_minsky/

Power8のMinskyとPower9のNewell どちらもありますので検証してみたいという方は是非ご連絡ください!もちろんIBM Cloud Private用途でなくても問題ありません!

すずきけ

2019/01/17

IBM Cloud Private 全部GUIでやるOpen Libertyのテストデプロイ

今回はIBM Cloud Privateって構築してみたけど、アプリケーションの開発とかやらないし、この先どうしたらいいのかよくわからないな~という人のためにサクッとできるデプロイしたContainerが動作しているか確認する方法を書いていきたいと思います。
また、ポイントとしてはGUIでという部分です。ご存知の通り、ICPではKubernetesサービスが動いていますが、他のクラウドサービスとかですとコマンドベースで動かしていることが多そうです。
ただ、せっかく製品買ったし、GUIあるなら使いたい!ということでGUIをご案内します。

環境

定番の環境の情報です。
今回使ったのはICPクラスタ1台です。
作り方は IBM Cloud Private 3.1.1 インストール方法(RHEL編) で書いています!
※今回使う環境はICP 3.1.0 ですが、方法に変わりはありません。


構築する環境

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

1台目:Master node (manager,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つ


デプロイするアプリケーション

今回は、OSSの Open Liberty をデプロイします。


手順概要

  1. 管理コンソールにログイン
  2. Helmカタログからデプロイするアプリケーション(Open Liberty)を選択
  3. パラメータを指定してデプロイ
  4. デプロイした情報を確認(接続ポート)
  5. Webブラウザーからアクセス確認

※ 今回、Open LibertyへのWebアクセスはHTTPで構成します。


作業手順


管理コンソールにログイン

管理コンソールにログインします。
ログインのURLは

https://(MasterサーバーIP):8443

です。

Helmカタログからデプロイするアプリケーション(Open Liberty)を選択

管理コンソール右上の カタログ をクリックします。

検索部分で Liberty といれると、Web Sphere LibertyOpen Liberty が表示されますので、 Open Liberty を選択します。

20190116_14h09_17a


Open Libertyの情報が表示されますので、構成 をクリックします。

20190116_14h10_05a


パラメータを指定してデプロイ

今回はテストですので、必要最低限の設定だけを行います。

  • Helmリリース名 : 任意の名前
  • ターゲット名前空間 : Default
  • ポッドセキュリティー : 入力なし
  • 使用許諾条件 : チェックをつける


設定完了後、インストールをクリックします。

20190116_15h01_15a


デプロイした情報を確認(接続ポート)

インストールをクリックすると下記のポップアップが開きます。

20190116_15h15_07


Helmリリースの表示をクリックします。
Helmでデプロイされた内容の一覧が表示されます。
デプロイ直後は稼働しきっていませんので、数分後に画面をリロードします。

20190116_15h16_21

20190116_15h16_34


正常に稼働している場合は上記の画像のようになります。
稼働しているかチェックするポイントはデプロイメント使用可能1となっていることと、Pod準備完了1/1となっていることです。
※稼働するまで少し時間がかかります。

20190116_15h16_34a


外部からデプロイしたOpen Libertyに接続するために必要な接続ポートを確認します。 サービスポートの値を確認します。

9443:30791/TCP

9443 はICP内部で接続する際に使用するポートで、外部から接続する場合は 30791 を使用します。

接続先のIPですが、サービスタイプ部分がNodePortになっています。
NodePortの場合はICPクラスタ内のすべてのNodeのIPアドレスとポートの組み合わせで接続ができます。

今回の環境の場合、下記の2台のサーバーがあります。

  • Master Server xxx.xxx.xxx.161
  • Worker Server xxx.xxx.xxx.164

この環境でNodePortは下記のどちらからもアクセスが可能です。

  • https://xxx.xxx.xxx.161:30791/
  • https://xxx.xxx.xxx.164:30791/


Open Libertyに接続してみる

Webブラウザからアクセスしてみます。

http://(ICPクラスター内のNodeのIP):(確認したポート)/

にアクセスします。

Open Libertyのサンプルページが表示されます。

20190116_15h25_25


  • Master Server(IP末尾161)に接続

20190116_15h25_40b


  • Worker Server(IP末尾164)に接続

20190116_15h25_48b


以上です。
ICPのHelmのカタログを使うことであっさりとOpen Libertyを動作させることができました。
IBM社が用意しているものでも数多くありますので、ぜひいろいろ試してみてください。

ICP上でWAS LibertyをガッツリつかってWebアプリケーションを使いたい方は、WAS Liberty on IBM Cloud Private 利用ガイドがIBM様からリリースされていますので是非読んでみてください。

(毎度の)最後に

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

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

すずきけ

2019/01/16

Calm .NEXT 要約: クラウドマイグレーション, Kubernetes,等々

55e2617be281476786924e1f1c1ea7a6_th

本記事の原文はもともとNutanix社のVP,Engineering のVishal Sinha 氏によるものです。

原文を参照したい方はCalm .NEXT Recap: Cloud Migration, Kubernetes, and More!ご確認ください。

情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

ネットワールドのNutanix関連情報は、ぜひ当社のポータルから取得ください。

(初回はID、パスワードの取得が必要です)


先日 数千人ものITプロフェッショナルの方々が ヨーロッパで開催された.NEXT へ集まりました。

もし見逃していても心配しないでください。本日はお客様がキャッチアップできるように主要なCalm、関連するセッションの要約をプレゼンテーションのリンクと動画紹介します。

キーノートでのCalm: App Mobility デモ

オープニングキーノート良かったものを選択するのは難しいですが、Calm, Xi Beam , Xtractはスタイリッシュに締めくくりました。最高のデモの中で私たちはどのようにBeamが非効率を無駄な投資を識別しCalmを利用したAHVへの移行も含め改善方法を推奨してくれます。

0e10b2ce0a974b56b7b632c2a1a33a2e

Calm はアプリケーションプロファイルを利用して移行を実施し、移行中はCalmはシームレスにXtractを利用してデータのコピーを行います。カットオーバーを実施する際は、CalmはXtractを利用してNutanix CBTドライバを利用して最終変更の差分をコピーします。

3b87873e6b4148938672417b6fbde46d

App Mobilityは以前開発段階ですが、これは私たちがオンプレミスの専門知識とマルチクラウド管理のポートフォリオによる解除できるたくさんの可能性の内の1つでしかありません。

これがら利用可能になった際には追加の情報と共にお知らせしますのでそれまでお待ちください。


 
 
 

ブレークアウトセッション

キーノートは未来の可能性を理解するのには素晴らしい場所ですですが、私たちが今日何が利用できるを深くしる事ができるのはブレークアウトセッションです。私たちは既にすべてのブレークアウトセッションをこちらに投稿しています。4つのトラックをまたがる50以上もあるブレークアウトセッションはお客様がもっと常に知りたいと思っている事をカバーする何かがあるはずです。

特に次の4つはお客様がきっと気に入っていただけるCalm , 自動化に関するセッションです。


Automation and Multi-Cloud Management with Nutanix Calm:Calmを開始するには?

Calmとは?Calmの基礎を理解するセッションです。

Nutanix Calm In-depth and Implementation Tips:もっと多くの技術セッションを探していますか?

このセッションはこのセッションはKubernetesやJenkins Integrationのデモに注力しているのでスライドが抜けていますが、カバーするために TechTopX seriesも合わせてご覧ください。残りに関しても準備が出来次第、投稿していきます。


Cloud Native Apps with Nutanix Kubernetes (Karbon):Nutanix Karbon - 現在はTech Preview の製品です - ワンクリックでお客様のNutanix Cluster へKubernetes環境を展開する事が出来ます。こちらはCalm’s Kubernetes supportも合わせて参照頂くことでより理解を高めKubernetesを始める良い機会になります。

Nutanix Era: 1-Click Database Management: Eraはタイムマシン機能を利用しながら、素晴らしいCDMと一体化したNative データベースの提供、客様がデータベースのコピー、ロールバック、即座にデータリフレッシュを提供する事を可能しています。



©️ 2018 Nutanix, Inc. All rights reserved. Nutanix, the Nutanix logo and the other Nutanix products and features mentioned herein 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).

記事担当者 : SI技術本部 カッシー @Networld_NTNX

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/11

Azure 上に Terraform を使って Windows Server 2019 を展開してみる

今回のテーマ

皆さん、こんにちは。Microsoft 担当の津久井です。

2019年を迎えてMicrosoft 関連の投稿第1回目は、Azure上で利用できるTerraformを利用して

Windows Server 2019 の仮想マシン展開までの一連の流れを試してみたいと思います。

まず本題に入る前にまずはTerraformに関する概要をご説明します。

Terraformとは

Terraformは単一のテンプレート形式言語 (HashiCorp 構成言語 (HCL)) によるコーディングに

よってインフラストラクチャー全体を構築するツールとなります。

Azureにおいてはリソースグループ、ネットワーク、ストレージなどインフラストラクチャ全体を

コードとして定義し、その内容に沿って展開できる自動化ツールとなります。

インフラ管理者は構成したいインフラの情報を記載した定義ファイルを作成します。

この設定ファイルによって作成された環境は、容易に破壊する事も出来るようになっていますので

開発や検証に必要な環境をわずかなステップで準備出来ます。

 

今回紹介する作業の流れ

 作業の流れとしては以下となります。 

・Azure Cloud Shellを利用してGithubからTerraformのサンプルファイルをダウンロード。

・サンプルの定義ファイルを元に、Windows Server2019の展開用に定義ファイルを編集。

・Terraformを実行し、仮想マシンが作成されている事を確認 

作業手順

Azure 管理ポータルにサインインし、画面右上のAzure Cloud Shell を起動します。

84

操作がしやすいよう全画面表示に変更します。

108

Github サイトの Terraform レポジトリにアクセスし、Clone&DownloadをクリックしてURLをコピーします。

372

以下のコマンドを実行しダウンロードします。

git clone  https://github.com/terraform-providers/terraform-provider-azurerm.git

480

ダウンロード完了したらサンプルファイルが保存されているディレクトリに移動します。

今回利用するテンプレートは、[vm-joined-to-active-directory]です。

684

既にテンプレート化されたファイルですので、編集せずにそのまま実行出来るのですが、今回は

Azureリージョンを「West Europe→East US」とOSバージョンを「2016→2019」に変更する

ために以下の3つのファイルを編集していきます。

今回は Cloud Shell エディターを利用してファイルを編集します。

816_2

編集の行うのは以下の3つのファイル(黄色ハイライト)となります。
Editfiles

エディタを利用しして、該当箇所を編集していきます。

main.tf ファイル内の location を「East US」に変更します。

1068

2-virtual-machine.tf ファイル内の sku を「2019 Datacenter」に変更します。

1260

編集が終わったら、「terrafom init」コマンドを実行します。

これにより Azure でテンプレートをビルドするための条件が Terraform に与えられます。

Init

続いて、[terraform plan]を実行します。これにより定義ファイルのエラーチェックならびに期待通りの結果が得られるかどうかを確認する事ができます。

今回のテンプレートでは、展開に必要な以下の3つの変数を入力します。

・admin_password:管理者パスワード
・admin_username:仮想マシンのローカルおよびADの管理者ID
・var.prefex:リソースグループ名など Azure の各リソース名のプレフィックス値となる文字列


Plan

処理を実行して良いかの確認で「yes」を入力します。

2424  

Planで問題ない事が確認出来たら、「terraform apply」コマンドを実行します。

これにより実際に処理が行われますので、あとは待つのみです。

テンプレートのREADME通り、展開には20分程で完了しました。

2844

画面ショットだけではわかりにくいかもしれませんので実際にコマンドを実行した様子を動画に

まとめていますのでこちらも併せてご覧ください。

 terraform 実行デモ動画   

動作確認

処理完了後、Azure Portalを確認してみると想定通り2台の仮想マシンが作成されました。 

Azure ポータルからリモートデスクトップで接続してみると、ドメイン参加済みのサーバー1台と、Active Directoryドメインコントローラーが正しく構成されておりました。 Image003

まとめ

今回は2台のWindows Server 2019 の仮想マシンを作成し、Active Directoryが稼働する

テンプレートをご紹介しました。

 

TerraformではAzure に限らず他社のクラウドやオンプレミス向けにも豊富なテンプレートが

用意されています。

 

Terraformを利用してシステムの一貫性を保ちつつ複数台を一気に展開する事も可能かと思います。

 

Azureでは今回ご紹介したTerrafom以外にも下記に紹介されているような自動化を支援する

ツールが利用可能となっていますのでお客様のニーズにマッチしたツールをご利用頂ければと

思います。

 

Azure の仮想マシンでインフラストラクチャ自動化ツールを使用する

今回も最後まで読んで下さりありがとうございました!

記事担当者:津久井

  

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も使って検証してみたい!といったご要望がありましたら問い合わせ窓口からご相談ください。

すずきけ

2019/01/09

Nutanix Filesのデータ保護

本記事の原文はもともとNutanix社のVP,Engineering のVishal Sinha 氏によるものです。

原文を参照したい方はComprehensive Data Protection with Nutanix Filesご確認ください。

情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

ネットワールドのNutanix関連情報は、ぜひ当社のポータルから取得ください。

(初回はID、パスワードの取得が必要です)


障害はデータセンタ内のいかなるレベルでも発生する事があります。ディスクも障害となりますし、ノードも物理的に損傷を受けるかもしれません、またはデーターセンタが災害によりダウンする事も考えられます。またデータは誤った操作により失うかもしれません。

それは削除であったり、意図しない上書き、またはマルウェアにりそうさせるかもしれません。

Nutanix filesはデータ保護ソリューションでデータを安全に保護します。


ディスク障害とノード障害に対するデータ保護

Nutanix FilesはAOSへ影響しながら次の障害に対する保護を提供します。

ディスク障害 - ディスクに障害が発生した際、データは自動的にアクセス可能な他のノードへパフォーマンスの影響なしにアクセスできます。Nutanixプラットフォームはデータ保護の為のハードウェアRAIDには依存しません。

一度壊れたディスクが交換されると新しいディスクへリビルド処理がクラスタ内の全てのノードを同時に利用して実施します。


ノード障害 - データの冗長性はノード障害が発生したとしても変わりません。データはは他のノードのレプリカがまだ利用できますし、ノードが交換された際はデータは新しいノードにリビルドされます。


Block 障害 – Nutanix Filesを含むクラスタは"Block Aware"です。つまりこれはデータのコピーを同じブロックに配置をしないことになります。

ブロックはラックマウントで1~4ノードでなりたっており、複数ノードのブロックでは電源、FANがブロックで共有される唯一の構成要素となります。

Block Awareness機能なしだとNutanix Clusterは一つのノード障害に対応できますが、Block Awarenessと構成すれば、ブロック内の複数のノードがダウンしてもクラスタは稼働します。

仮想マシンも同様に稼働しますが、これはクラスタの構成データや、仮想マシンのレプリカ、メタデータを他のブロックに保存するからです。

この機能は特定の条件下になると自動的に有効かされます

(ただし Proライセンスが別途必要となりますので、ご注意ください)



ローカル、リモートスナップショットを利用したファイルサーバレベルの障害に対するデータ保護

Nutanix Filesはサイト障害からのNutanix Filesインスタンスの保護を実施するファイルサーバレベルでのデータ保護を提供します。

ファイルサーバが作成されると、Nutanix Filesは自動的にProtection Domainも作成しこのProtection Domain にはファイルサーバ(VM , Volume Group)が含まれます


管理者がする事はいつデータのスナップショットをとるかをスケジュールします。

リテンションポリシーでどの位の期間スナップショットを保持するか、スナップショットをローカルに置くのか、リモートサイトに置くのか、リモートサイトの場合は1対多、多対1、多対多の複製をサポートしているので、管理者は全てのワークロードを前サイトにまたがって保護する事が出来るのです。

サードパーティバックアップの為のChanged File Tracking (CFT)

殆どの存在するソリューションは20年以上のNDNPの技術に頼っており、これはNutanix Filesなどのスケールアウトファイルサーバや、複数ヘッドのサーバといった、スケールモデルをサポートしていません。

Nutanix FilesはCFT技術を提供する事でスケールアウトファイルサーバ(Nutanix Files)のバックアップを行えるようになるのです。

これを利用するメリットをいくつか説明します。



Point-in-time backup:この機能は全てのファイルとディレクトリの point-in-timeバックアップを提供するので、もしバックアップに非常に時間がかかっていても実際にファイルのバックアップがいつ行われているのか推測する必要がなくなります。

“In use” files backup:多くの従来のバックアップソリューションでは使用中のファイルはバックアップされません。CFTでは全てのファイルまたはディレクトリを状態を関係なくバックアップします。

Smart Incremental backup:CFTは前回のスナップショットとユーザが差分バックアップを行うための全てのファイル、ディレクトリのトラックを保持します。NDMPではバックアップごとにすべての変更点をスキャンします。CFTはバックアップの時間を削減する事になります。


Fast backup:CFTは複数の同時ストリームをシングルファイルサーバVMに適用するだけでなく、複数のパラレルバックアップストリームをすべてのファイルサーバVMで活用できるようにします。例えば16VMからなるNutanix Files Clusterがあるとすると、一つのファイルサーバVM毎に2つのバックアップストリームを同時に実行すると仮定し同じファイルサーバからは32のパラレルバックアップを一度に実施できるのです。

CFTを使ったファイルサーバのバックアップでは最初にフルバックアップを取得、その後は差分のバックアップとなります。

ヒューマンエラー、予期せぬアクシデント、悪意のある攻撃からのデータ保護

誤ったデータ削除、ランサムウェアや悪意のある攻撃によるデータ消失に対してNutanix FilesはSelf-Service-Restore(SSR)機能を提供する事でユーザはWindows Previos Version(WPV)を利用して以前のバージョンからデータをコピー、復元することが出来ます。

管理者はSSRをファイルサーバレベルか共有レベルで構成できますし、SSRスナップショットは読み込み専用でPoint-in-timeコピーとなります。

下の画像はWindows OSでどのように以前のファイルを復元するかを示しています。



以下の図ではNutanix Filesがサポートしているデータ保護の仕組みになります。

Filesをファイルサーバとして利用する場合にもNutanix本来の冗長性に加えてFiles側でのデータ保護の仕組みを活用する事が出来るわけです。


©️ 2018 Nutanix, Inc. All rights reserved. Nutanix, the Nutanix logo and the other Nutanix products and features mentioned herein 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).

記事担当者 : SI技術本部 カッシー @Networld_NTNX

2018/12/28

コピーデータ活用~連載シリーズ CDM製品パイオニアActifio(アクティフィオ)のご紹介! ~ 設定編1~

こんにちは。前回、Actifio (アクティフィオ) 製品のコンセプトをご紹介いたしましたが、Actifio の管理インターフェース、リモートサイトへの DR 構成、VMware vSphere 環境の仮想マシンのバックアップ設定方法をご紹介いたします。

 

【Actifio 管理インターフェース】

Actifio のインターフェースには、インストール型の管理コンソール "Actifio Desktop" というクライアントアプリケーション(GUI) が提供されています。管理コンソール画面を通じて、対象データの取り込みやコピーデータのマウントなどの各種の設定が直感的に操作てきます。

 

001_3

 

また、Actifio には、Role Based Access Control(RBAC) 機能が実装されていますので、グループまたはユーザ毎に、対象サーバの保護ジョブの実行やコピーデータ利用の操作などを制限して運用することもできます。

 

【Actidio データ保護ポリシー: SLA (Serivce Level Agreement)】

Actifio では、データ保護レベルを統一した SLA (Service Level Agreement) というテンプレートを使用して、バックアップの設定・管理を行います。

 

002

  

【Actifio レプリケーションとクラウドストレージへのデータ転送】

Actifio のレプリケーション機能は、プールの構成と同様に要件に応じて、複数の転送方式を使用することができます。StreamSnap は Snapshot プールからリモートの Actifio アプライアンスの Snapshot プールへ転送する動作、1時間に1回など比較的短い転送間隔に対応できる方式です。

 

もう1つの方式の Dedup Replication は、Dedup プール内の重複排除済のデータを転送する方式ですが、ブロック送信前にリモート側に対して同一ブロックの存在を確認する重複排除転送プロトコルを実装しているため、ネットワーク回線帯域の使用を抑えたレプリケーションを実施することができます。

 

DAR(Dedup Async Replication)は、Dedup Replication の転送効率とリモート側でのコピーデータの即時利用ニーズを両立した方式で、リモート側のDedupプールへの
転送が完了すると自動的にSnapshotプールへ復元・展開処理が行われます。 

003

 

【Dedup Async Replication の流れ】

① VMware API 経由で差分ブロッックを取得しSnapshot Pool に格納

②③ SnapShot 内部の差分ブロックを重複除外しながら転送

④ 重複除外データから差分ブロックを再現し、Snapshot Pool のVMイメージを更新

 

迅速なVMの復旧として、Actifio ReadyVM が提供されています。この機能は、ローカルサイトまたはリモートサイトで障害が発生したしたVMを瞬時にマウント、またはリカバリすることができます。ReadyVM を使用して、ディザスタリカバリテストをオンデマンドで行うこともできます。

 

004 

【ReadyVM の流れ】

① VMware API 経由で増分ブロッックを取得しSnapshot Pool に格納

②③ SnapShot 内部の増分ブロックを重複除外しながら転送

④ 重複除外データから増分ブロックを再現し、災対用ストレージのVMイメージを更新

 

今回、VMware vSphere 環境の仮想マシンのバックアップ設定手順をご説明します。バックアップの設定から開始までは、以下のステップで行います。

 

  • VMware vCenter の登録

    Actifio Desktop の Domain Manager から vCenter の登録を行います。

    006

     
  • ESXi ホストの iSCSI の登録
    Actifio Desktop の Domain Manager からバックアップデータ転送用の iSCSI を設定します。

    007

     

  • バックアップ対象仮想マシンの登録
    Actifio Desktop の Application Manager からバックアップ対象仮想マシンを検索して登録します。

    008 

  • バックアップテンプレート SLA の設定/割り当て

    Actifio Desktop の SLA Architect からバックアップのスケジュール保持期間や保持期間を設定し、バックアップ対象仮想マシンにSLAを割り当てます。

    010

    011

     
  • バックアップ開始

    SLA の設定に従い、バックアップが実施されます。

    012

 

バックアップジョブの設定も従来のバックアップと違い、ポリシーベースで管理し、設定手順もシンプルな手順で対応することができます。次回、リモートサイトへのレプリケーションをご紹介いたします。

 

今月 18日に弊社開催の「次世代バックアップソリューション Day 2018 ~ガチンコ対決~」というイベントに多くのお客様にご参加いただきました。 Actifio、Cohesity、Rubrik 3社で各社のバックアップアプライアンスの魅力をアピールいただき、お客様からの注目も高く、イベントも大盛況で終わりました。

 

Actifio、Cohesity、Rubrik 3社の取扱いは弊社のみですので、ご興味のある製品がありましたら、ぜひ担当営業までご相談ください。最後までお読みいただきありがとうございました!

 

【過去の掲載】 

 

Edit by :バックアップ製品担当 松村

2018/12/26

Nutanix レジリエンシー – パート 10 – Disk スクラブ / チェックサム

本記事の原文はもともとNutanix社のStaff Solution Architectで、Nutanix Platform Expert (NPX) #001、

そしてVMware Certified Design Expert (VCDX) #90として活動しているJosh Odger氏によるものです。

原文を参照したい方はNutanix Scalability – Part 5 – Scaling Storage Performance for Physical Machinesをご確認ください。

情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

ネットワールドのNutanix関連情報は、ぜひ当社のポータルから取得ください。

(初回はID、パスワードの取得が必要です)


このシリーズでは私はどれだけレジリエントがNutanix Platformでは素晴らしいか

障害中のあたしい書込みデータ、障害が発生した後にその後のリスクを最小限にするためのリビルドの機能を含めてカバーしていきています。

全てのこの情報にも関わらず、他のベンダーは依然としてNutanixが提供している 

リビルドパフォーマンスは問題ではなく、二つのコピーセットが消えたらという?というデータの信頼性という簡単に言え、両方のデータが消える可能性は極めて低いことについて触れていますが、もちろんNutanixはこのようなお客様に対してデータの3重化をサポートしています。

それではパート10に行きましょう。

ここではDiskスクラブとチェックサムという2つお客様はRF2,3の展開が非常にレジリエンシーがありデータロストする可能性がほとんどないという事を学んでいただけるはずです。

ではチェックサムから始めましょう、チェックサムとはなんでしょうか?

チェックサムは書込み操作の間に作成された小さいデータを後に読み込みデータが正しいかを確認します。

一方 Disk スクラブは定期的にデータの一貫性を確認するバックグラウンド処理となり、いかなるエラーでも発生すれば、Diskスクラブはシングルコレクタブルエラーを実施するようになります。

Nutanixは全ての書込み操作(RF2 又は3)へのチェックサムを行い、全てのリード操作でチェックサムを確かめます!この意味はデータの完全性がIOパスの一部で、スキップまたはOFFにされていない事になります。

データの完全性は全てのストレージPlatformの一番の優先事項であり、Nutanixが決して無効にしないオプションなのです。

Nutanixはリードのチェックサムを行っている以上、データがアクセスされると常にチェックされる事となり、もしエラーが発生すした場合はNutanix AOSは自動的にRFコピーからデータを復元しIOのサービス、同時にデータロスが発生しないように修復します。

Nutanixがノード/ドライブまたはExtent(1MB のブロックデータ)から復旧するスピードはデータの完全性には非常に重要な事です。

コールドデータについてはどうか??

多くの環境では非常に多くのコールドデータを持っており、つまりアクセスが頻繁にされないという事になるため、データのチェックサムが行われず、頻繁にアクセスされないデータのチェックは全くされないことになってしまいます。データがアクセスされない場合、どのようにしてデータを保護するのでしょうか?

単純です、Diskスクラブになります。

フロントエンドの読み込み操作を通しているデータ(VM/Appからの読み込みデータ)に関しては

一日に一回のNutanixのディスクスクラブ実行がコールドデータをチェックします。

Diskスクラブタスクはクラスタ内の全てのDiskへ実施するため、ドライブ障害や、Extent(1M ブロックデータ),データがある2つのディスクの同時障害というような複数の同時障害が発生する可能性は極めて低いのです。これはRF2を利用した場合を仮定しています。

データの障害は完全に直近24時間でデータの読み込みが発生していなかった事、バックグラウンドディスクスクラブが2つのコピーデータに対して実施されていなかったこと、AOSの予測ドライブ障害がドライブ障害を発見できなかった、AOSのPredictiveなドライブ障害がドライブ障害を検知できない、またそこへすでにデータの再保護がされてしまっている事が同時に発生している必要があります。

いま、シナリオが発生したと仮定します、ドライブ障害は破損したデータブロックと同じストアがある必要があり、NX3460などの4ノードの小さいクラスタでさえあっても、ドライブは24となるため可能性は非常にすくなくなります。クラスタが大きくなればなるほど、この可能性は低くなりますし、以前のシリーズでお話したとおり、リビルドの時間は早くなります。

まだとてもリスクがあると感じ、全てのイベントを完全に列挙してからRF3を展開し3ノード障害に加えてデータロスを起こすために奇跡を起こす必要があります。

VSANを展開しているとDisk スクラブは年に一度実行され、VMwareは頻繁にチェックサムをOFFにする事を推奨しています。SAP HANAドキュメントもそうでしたが後にデータロスのリスクがあるため、このドキュメントは更新されています。

NutanixはまたDiskスクラブアクティビティを監視する機能があります。

下にあるスクリーンショットは2TB SATAディスクで75%程利用されているDisk ID 126のディスクスキャンを表しています。

Diskscrubbingstats

Disk126

AOSはディスクスクラブを保証し、ディスクのサイズに関わらず24時間ごとに実施します。上のスクリーンショットはスキャンが 48158724ms走っているものとなります。 googleによると13.3時間で556459ms(0.15hrs)でETAが完了します。

Scanduration

データが動的に容量、パフォーマンスを基準に分散するADSFの性質と組み合わせると、Nutanix Clusterは各ノードの複数の同時ディスク障害に対応する機能を持っており、チェックサムは全てのリードライト操作で実施され、ディスクスクラブは毎日完了します。プロアクティブなドライブ健康状態の監視はドライブ障害が発生する様々なケースのデータ再保護が行われます。

同じく、ADSFはデータのリビルドを行いRF2を利用していたとしても簡単に素晴らしいレジリエンシーを提供するのです。

まだ満足していない様でしたらRF3へ変更し、よりレジリエンシーを高めるようにしてみましょう。

レジリエンシーファクター,vSANでいうFailure Tolerateを考慮するとき、それぞれ2重化でも動作がことなりますので、間違えないようにしまし、それぞれあったものを検討頂ければと思います。

以下はその他の Josh Odger氏が投稿しているBlogの外部リンクとなります

Index:
Part 1 – Node failure rebuild performance
Part 2 – Converting from RF2 to RF3
Part 3 – Node failure rebuild performance with RF3
Part 4 – Converting RF3 to Erasure Coding (EC-X)
Part 5 – Read I/O during CVM maintenance or failures
Part 6 – Write I/O during CVM maintenance or failures
Part 7 – Read & Write I/O during Hypervisor upgrades
Part 8 – Node failure rebuild performance with RF3 & Erasure Coding (EC-X)
Part 9 – Self healing
Part 10: Nutanix Resiliency – Part 10 – Disk Scrubbing / Checksums

記事担当者 : SI技術本部 カッシー @Networld_NTNX

アクセスランキング

お問い合わせ先
ネットワールド ブログ運営事務局
blog.doc-info@networld.co.jp
フォトアルバム