« 2018年12月 | メイン | 2019年2月 »

2019年1月

2019/01/30

全てのNutanix AOS Clusterへ1TB容量のNutanix Files ライセンス

本記事の原文はVice President and GM of Nutanix FilesであるDave Kresse 氏によるものです。

原文を参照したい方は1 Free TB of Nutanix Files capacity with every Nutanix AOS clusterご確認ください。

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

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

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

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


Nutanix Filesが1TBまでAOSを合わせてご利用できるようになります。

全てのデータはセンターはファイルストレージをつかっています。Nutanix Filesを無償でつかってみませんか? NutanixFilesはNutanixが現代データーセンターにおける多くの課題を解決するためのシンプルでフレキシビリティでさらにインテリジェントなファイルストレージとなります。

そして、なんとNutanix AOSをご利用の方はAOSのCluster毎に1TBのFreeライセンスを入手できます!このことでNutanix AOSをお持ちの方はNutanixの環境へ素晴らしいファイルストレージソリューションを確かめることが出来るチャンスです!

少ないワークロードへ対しては十分ではないでしょうか

Nutanix Files って??

Nutanix FilesはNutanixの革新的なHCIプラットフォーム上に構成され、お客様のファイルストーレジのストレージ、ネットワーク、コンピュートの枠をなくします。

  • Nutanix Filesはシンプルです!それは1-クリックによる展開、プロビジョニング、NutanixPrimsで行えるシングル管理によって複雑性を排除するからです。
  • Nutanix Filesはフレキシブルです! それは多くの異なるハードウェアへ展開できますしノード、仮想リソースの追加を無停止する事でスケールアウト・スケールアップをを実現します。これだけではなく異なるタイプのストレージ(Files ,Object , Block)も同じ基盤へ展開できるのです。
  • Nutanix Filesはインテリジェンスです!リコメンデーションエンジンにより問題が発生する前にパフォーマンス、冗長化リスクを識別し1-クリックでどの様にすれば良いかを教えてくれるのです。

なんで1TBの容量が使えるのですか?

NutanixはNutanix Filesのフリーの1TBのライセンスをAOS Clusterの一部として提供します

(Nutanix Files Pro や追加機能は含まれません)

ライセンスの有効期限は?

これはお試し版ではありません。Nutanix AOSクラスタと同じ期間 Nutanix Files のライセンスを利用できます。

サポートは?

Nutanix AOS サポート契約により1TBのNutanix Files キャパシティはサポートされます。

 

どうやって利用するのですか?

既に1TBのCapacityライセンスがあります。AOSをご利用でしたらこの容量に対して何か有効にする必要もありませんので、Nutanix Filesを展開してセットアップすれば利用できます。

1TB以上のファイルストレージが必要になったら?

Nutanix Filesは既に利用可能な製品でAOSクラスタの一部として容量か専用のクラスタで利用できます。追加のサイズが必要となれば、キャパシティライセンスを購入し展開しているNutanix Filesを拡張する事が出来ます。

Mixed クラスタにNutanix Files Proを展開できますか?

いいえできません。

1TBのキャパシティはMixed Clusterで利用され、Nutanix Files ライセンスとなります。

Nutanix Filesは2つのライセンス体系となり、Nutanix Files , Nutanix Files Pro です。

Nutanix Files はmixed Cluster となりますが、Nutanix Files Proはファイルストレージ専用で構成するNutanix Clusterのライセンスとなり他のライセンス製品などを展開する事は出来ません。



©️ 2019 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

2019/01/23

再考されたPrism - 拡張と利用の為の設計

本記事の原文はもともとNutanix社の Senior Staff Designer であるBryan Crowe 氏によるものです。

原文を参照したい方はPrism Reimagined - Designing for Scale and Intentご確認ください。

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

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

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

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


Prism Centralはお客様がお持ちのNutanix インフラ基盤を管理するためのマルチクラウド管理ツールです。

最初に紹介したのは4年前で、この時は限定された機能と5つの管理されたエンティティタイプがありました(VMsなど) . それ以来、20を超える新しいエンティティタイプとPlanningやDRといった素晴らしい機能を紹介してきています。

さらに、お客様は多くのホスト、クラスタと仮想マシンを一つのPrism Centralから管理する事が出来るようになります。この機能により拡大するインフラはPrism Centralは元々のデザインである拡張限界に達したため、Prism Centralの方向性を再考慮する事になったのです。


Approach

スケール行う上でサーチ機能は非常に強力な機能であり、階層化を平らにし効率を高める事を容易にしてくれます。例えばmacOSのスポットライト機能、なかでもユーザが変更したい名前を変更(例えばDisplayなど)そしてそこへ直接行けることが出来るようになり、これはとても強力で私たちがPrismの方向性を設計する上でいくつか考慮したのです。


私たちの調査ではデータセンター管理者は検索機能を利用する事に興味をある方とクリックベースのメカニズムに興味のあるが混在しています。また、サーチ機能はいくつかの基礎となる構文、ユーザにすぐに解らない構造である以上、発見と学習のいささかチャレンジとなります。

私たちの調査、繰り返し設計するプロセスに基づき、次の目的に立っていする為のアプローチへとたどり着きました。

  • スケールを考慮した強力な検索機能の提供
  • 直感的なクリックベースの発見と学習
  • 検索とクリックベースのインタラクションの結合によりユーザが容易にそれらの変更と、最適なメカニズムの利用が出来ます。
  • カスタム化のサポートでユーザは簡単に知りたい情報を簡単に入手できます

Design

このセクションでは新しいインターフェースとその機能のツアーをご体験頂きます。

7a7eeda5173343238f383fcaa15307a7

Prism Centralのメインメニューはおなじみのダッシュボードです

Note:左のヘッダ部分は検索バーとナビゲーションメニューの為、クリーンアップされています。

Afec6dd5a1554129959139860b5b867d

グローバルナビゲーションはVMなどのページへ移動するために利用する事が出来ます

4889e7a6f7884e7aae9a77576847a731

VMサマリーページは様々な情報を教えてくれます。

54d92b4ef5bb423dbc0f3e5cf5ac0815

システムのホストを見つけるために、グローバルナビゲーションへ戻り検索を使うだけでホストを見つけることが出来ます。

54d92b4ef5bb423dbc0f3e5cf5ac0815_2


ホストサマリーページはVMサマリーページと同じように確認できます

Hostsummary

もしクラスタのアラートを確認したければ、検索で"cluster alerts"と入力するとClusterのアラートを確認できるのです。

Cluster_alert

これはオートコンプリートを最初にクリックしたときのスクリーンショットです。


さらに素晴らしいフィルタークエリーもあります。例えばiopsが50以下の全てのVMを次の画像のように入力すると確認できるようになります。

Performanced

オートコンプリートはフィルターを認識し理解するための特別なフォーマットを利用します。

他の面白い例ではAHVで稼働している電源がONの仮想マシンであったり、パフォーマンスでクリティカルアラートがあるものを入力する事も出来ます。

管理者はまたシステムの全てのエンティティ(例えば VM , Host , Security , Policy)などを名前による単純な検索か関連のあるIPアドレスを入力できます。


Vm_host

これは前のクエリーを追加したVMページの状態です。

特定のフィルターが適用された仮想マシンだけを見つけることが出来るようになります。



Vms

頻繁に使うビューに関してはブックマーク登録すると簡単にアクセスできるようになります。

Photo

グローバルメニューを再度開くとブックマークした項目が上部に表示され、これにより最も頻繁に訪れているページへ簡単にアクセスできます。

前の例ではこれらのブックマークいくつものフィルターを追加しています。今のサンプルでは

管理者は異なる観点(例えばDev, Test , Production)から異なるオプションを追加する事で簡単に見ることが出来るようになるのです。

これらカテゴリ機能はサーチ機能でサポートされこのようはビューを作成し利用する事が出来るのです。


Launguage

新しい検索機能は管理者が変更したい設定項目へ簡単に移動する事も出来ます。

例えば言語設定ですが、これはグローバルナビゲーションでPrism Central設定を選択しすべてのリストを見ることが出来ます。

サマリー

PrismCentralのような近代的なWebアプリケーションはより豊富に多くの機能をサポートするようになります。インフォメーション構造とナビゲーションメカニズムはより複雑になり、検索は大量のコンテンツをナビゲーションを通して確認する一般的な方法ですが、サーチ機能を習得する事は難しい事でユーザーによってはクリックしてから検索しています。

検索とナビゲーションの統合をシームレスにしクリックベースのナビゲーションが維持されます。

より効率の良いコンテンツへのアクセスが出来るようになった一方、この新しいアプローチで従来のクリックベースの対話は管理者がサーチを通して様々な事を確認し結果的にその機能を学ぶことができます。この方法でクリックベースのナビゲーションは検索をしたくない人に親しみのある経験を提供するだけでなく、全てのお客様が理解し、学び、検索の振る舞いを受け入れる自然な方法をも提供します。

これらは皆様の異なるプロトタイプからのフィードバックによるお陰なのです。

5.10へ搭載するための追加のフィードバックも私たちは楽しみにしています。

より多くの検索機能の詳細を知りたい場合はPrism Central 5.10以降でグローバル検索マークで"Learn about search"と入力するか、シンプルに"Search Guidelines"と入力してみてください。



©️ 2019 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

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

アクセスランキング

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