« 2018年9月 | メイン | 2018年11月 »

2018年10月

2018/10/31

LenovoがSAP、Nutanixと連携します: インテリジェントエンタープライズの為のHCI

本記事の原文はLenovo社に務めている友人によるものです。
原文を参照したい方は <こちら > をご覧ください。
情報は原文の投稿時のものですので、現時点では投稿時の情報と製品とで差異が生じている場合があります。
当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら
ネットワールドのNutanix関連情報は、ぜひ当社のポータルから取得ください。
(初回はIDおよびパスワードの取得が必要です。)


6a131c1293c34ba496e01d521176e081_th

Lenovo TinkAgile HX7820がSAP HANAの認定となりました。

データーセンターインフラストラクチャーはオンプレミス、クラウド、ハイブリッド技術の結合によりさらに複雑になってきています。

最近のハイパーコンバージドインフラストラクチャー(HCI)ソリューションはデーターセンターリソースを単一の管理、シンプルにするために出てきています。

伝統あるパートナーのSAPとNutanixはHCIソリューションのアクセスを加速する必要があります。LenovoはSAP社よりSAP HANA HCIの認定をもらった最初のサーバーベンダーとなりました。

この認定はNutanix AHVとなり、HCI環境においてSAP HANA の本番環境の認定を得られた最初のハイバーバイザーとなります。

SAP HANA の認定がある新しいLenovo ThinkAgileにより、お客様はビジネスの拡張性、俊敏性があるHCIの上でSAPのワークロードを動かすという利点を得られます!

これらのSAPワークロードはエンタープライズ事業者がより早くデータ分析やマシンラーニングなどの統合データへアクセスするためのin-memoryデーターベースの利益を享受し、そしてストレージ、コンピュート、ネットワークのスケールが出来るのです。

SAP HANAの為に最適化されたLenovo ThinkAgile HX はNutanix社がお客様のインテリジェントエンタープライズのビジョンを実現するために設計されています。

Lenovo社の新しい発表の4ソケットシステムのThinkAgile HX7820により、このソリューションはHCI Think Agile HX ポートフォリオの中で最高クラスのミッションクリティカルの分野に適しているのとなります。

高い信頼性、パフォーマンスが素晴らしいLenovo PlatformにNutanix エンタープライズクラウドOSを組み込むことで、Lenovo Think Agile HX シリーズはお客様へHCIソリューションの展開を約3/1のコスト、合計でTCOを57%も削減する事が出来るようになります。

さらにESGの2018年1月のホワイトペーパーでは300%以上もの見返りがあるとされています。

SAP認定のあるThinkAgile HX7820をご購入されたお客様はSAP HANAワークロードを安心して展開できるようになります。

Lenovo社とSAP社との緊密なパートナーシップによりお客様はインテリジェントエンタープライズのビジョンの実現とエンドツーエンドのライスサイクル管理と共にシームレスなカスタマーエクスペリエンスを可能とします。


SAP HANAのThinkAgile HX ソリューションはLenovoプロフェッショナルサービスによるオンサイトのSAP HANAの展開を含めており、さらに全てのSAPソリューションはLenovoのエキスパートによりサポートされます。

LenovoのSAPコンピテンシーセンターとSAPアーキテクトはお客様のSAPの展開にも役立ちます。

お客様はシステムが認定されており、すぐに展開できる準備が整っていることに対して安心する事が出来ますし、このソリューションはSAP HANAの互換性のあるオプションで構成され、事前にNutanixソフトウェアはLenovo工場で最適なファームウェアと共にインストールされます。

最終的にLenovoとNutanixがSAP HANAを展開する事でお客様はSAP HANAのワークロードを驚異的なパフォーマンスとNutanixのシンプルさをLenovoで稼働させることが出来ます。

もっと詳しくしりたいかたはこちらを参照ください。



Disclaimer: The views expressed in this blog are those of the author and not those of Nutanix, Inc. or any of its other employees or affiliates. This blog may contain links to external websites that are not part of Nutanix.com. Nutanix does not control these sites and disclaims all responsibility for the content or accuracy of any external site. Our decision to link to an external site should not be considered an endorsement of any content on such site.

©️ 2018 Nutanix, Inc. All rights reserved. Nutanix and the Nutanix logo are trademarks of Nutanix, Inc., registered in the United States and other countries. SAP and the SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other countries. All other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s).

Nutanixの拡張性、シンプル性などを活かしながらミッションクリティカルなワークロードとして

SAPを動かす事もサポートされました。

まさにあらゆるワークロードを稼働させるインフラ基盤としてNutanix Enterprise Cloud OS があるのだなと実感できますね。

ご興味があるかたは、是非ネットワールドの担当営業へご相談ください。

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

2018/10/30

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

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

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

  • Community Edition
  • Cloud Native Edition
  • Enterprise Edition

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


ICPの情報リソース

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

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


構築する環境

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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


共通でやること

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

Pythonのインストール

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


Dockerのインストール


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

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

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

Dockerのインストール

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

SSH鍵の交換


SSH鍵の作成

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

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

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

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

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

SSHの再起動

systemctl restart sshd

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

ssh (Master or Worker IP)

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

exit

/etc/hostsを指定する

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

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

SELinuxを止める

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

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

Firewallも止める

Firewallも止めてしまいます。

systemctl stop firewalld systemctl disable firewalld

再起動

OSを再起動します。

reboot

インストール(Master編)

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


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

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

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


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

docker images

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

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

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

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

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

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

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

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


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

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

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

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

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

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


ICP ClusterにSSH秘密鍵をコピー

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

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

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

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

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

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

ls cluster/images/

環境のデプロイ

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

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

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

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

管理コンソールログイン

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

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

20181030_21h52_57




注意事項


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

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


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

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



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

2018/10/24

Nutanix スケーラビリティ、レジリエンシー、パフォーマンス の目次

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

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

原文を参照したい方はNutanix | Scalability, Resiliency & Performance | Indexをご確認ください。

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

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

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

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


Scalabilityresiliencyperformance

製品が一つのエリアでとても素晴らしく他のエリアで良い場合、また3つの内、2つがあっても十分ではなく3つのエリアで高く素晴らしい標準的なものがビジネスの成功には必要となります。

例えば、パフォーマンスが良くても拡張性が無い製品では、ビジネス成長性を見込んでいる客様はこのような製品について考慮すべきではないですし、製品の拡張性が素晴らしくてもレジリエンシーが乏しい場合は全ての本番環境に適していないかもしれません、利用するソリューションがリジリエンシーがあっても拡張性が無い際でも魅力的でない制約が発生します。

以前にインフラストラクチャを選ぶ際に考える事を記載し、ここではワークロードの統合をNutanixのような最近のPlatformで行うところではサイロ化を避けることで、より素晴らしいパフォーマンス、レジリエンシー、明確な拡張性が得られるようになります。

お客様がこの全て3つの性質を持ち合わせている製品を利用している場合は素晴らしいビジネスの結果を得ることが出来るでしょう。

以前に投稿した最大のパフォーマンスと現実のパフォーマンスの比較ではストレージソリューションで最大のパフォーマンスが大事な要素になる事は殆どなく、たとえPOCを行う際にでも最大のパフォーマンステストを行う事は時間を無駄にする事というのは良く知られているでしょう。

このシリーズの目的はNutanixのPlatformが全ての三つのエリアでどのようにしているか、いくつかのサンプルをお見せしてお客様の決定を助けるためのものです。

これらの3つのエリアは私が重点的に日々,Nutanix社のPrincipal Architect として注目しているところであり、Nutanix Platformのコアが全てのエリアで均等に向上していけるように努力をしています。

このシリーズの読者の方は多くの投稿がそれぞれに関連づいており、多くのケースが同じようなエリアをカバしていることに気づくでしょう。これは意図的に拡張性、レジリエンシーとパフォーマンスが結びついており、エンタープライズのソリューションの本質なのです。

このシリーズは新しい機能、強化されたものや、その他リリースなどをアップデートしていきます。

私はこのシリーズが有益なもので、既存、購入可能性のあるお客様の参考となり、またアナリストの方が進化しているNutanixいついてより多くの事を学んで頂く場となれば幸いです。

Scalability


オリジナル Part 1 – Storage Capacity

ネットワールド らぼ Nutanixのスケーラビリティ パート1 - ストレージキャパシティ


オリジナル Part 2 – Compute (CPU/RAM)

ネットワールド らぼ Nutanixのスケーラビリティ– パート 2 – コンピュート(CPU/メモリ-)


オリジナル Part 3 – Storage Performance for a single Virtual Machine

ネットワールド らぼ Nutanixのスケーラビリティ – パート 3 – 一つの仮想マシンへのストレージパフォーマンス


オリジナル Part 4 – Storage Performance for Monster VMs with AHV!

ネットワールド らぼ Nutanix スケーラビリティ – パート 4 – AHV環境でモンスターVMに対するストレージパフォーマンス


オリジナル Part 5 – Scaling Storage Performance for Physical Machines

ネットワールド らぼ Nutanix スケーラビリティ – パート 5 – 物理マシンのパフォーマンス拡張


More coming soon.

Resiliency

Index:


オリジナル Part 1 – Node failure rebuild performance

ネットワールド らぼ Nutanix 回復性能 – パート1 – ノード障害のリビルドに関するパフォーマンス


オリジナル Part 2 – Converting from RF2 to RF3

ネットワールド らぼ Nutanix 回復性能 – パート2 – RF2 から RF3へ変換する


オリジナル Part 3 – Node failure rebuild performance with RF3

ネットワールド らぼ Nutanix 回復性能 – パート3 – RF3でのノード障害


オリジナル Part 4 – Converting RF3 to Erasure Coding (EC-X)

ネットワールド らぼ Nutanix 回復性能 – パート4 – RF3からイレージャーコーディングへ変換


オリジナル Part 5 – Read I/O during CVM maintenance or failures

ネットワールド らぼ Nutanix 回復性能 – パート5 – CVMがメンテナンスまたは障害時のRead I/O


オリジナル Part 6 – Write I/O during CVM maintenance or failures

ネットワールド らぼ Nutanix 回復性能 – パート6 – CVMがメンテナンスまたは障害時のWriteI/O


オリジナル Part 7 – Read & Write I/O during Hypervisor upgrades

ネットワールド らぼ Nutanix 回復性能 – パート7 – ハイパーバイザアップグレードの間のRead&Write I/O


オリジナル Part 8 – Node failure rebuild performance with RF3 & Erasure Coding (EC-X)

ネットワールド らぼ Nutanix 回復性能 – パート8 – RF3とEC-X利用時、ノード障害のリビルドパフォーマンス


オリジナル Part 9 – Self healing

ネットワールド らぼ Nutanix 回復性能 – パート 9 – 自己修復機能


Bonus: Sizing Nutanix for Resiliency with Design Brews

More coming soon.

Performance

Part 1 – Coming soon.

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

2018/10/17

Nutanix スケーラビリティ – パート 5 – 物理マシンのパフォーマンス拡張

本記事の原文はもともと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、パスワードの取得が必要です)


パート 3パート 4 ではNutanixが仮想マシンに対してABS,Volume Group Load Balancer(VG LB)で素晴らしいパフォーマンスを仮想マシンへ提供できることを学んだと思います。

こちらを読んで頂いている皆様はすでにどのように仮想マシンのパフォーマンスをスケールさせるかを知っているので、物理サーバ―に対してどの様なルールが当てはまるかを見ていきましょう!

お客様は物理サーバ―とNutanixのクラスタを持っています、さて次にどうします?

多くの仮想ディスクが仮想マシンのストレージパフォーマンスを向上させるという事はパート 3パート 4で説明しました。

ABSを使う事で同じことが物理サーバ―にも言えるのです。

仮想ディスクをiSCSIを通してサーバーに提供し、最適なパフォーマンスを少なくてもクラスタ内の一つのノードから一つの仮想マシンを得ることができます。各仮想ディスクはNutanixのIOエンジンであるStargateによって管理され、このサービスは各CVMで起動しているのです。

もし4ノードクラスタをお持ちの場合は4つの仮想ディスクを利用すべきで、8つのクラスタであれば8つの仮想ディスクを使う事でパフォーマンスを向上する事が出来ます。

次のTweetでは4つノードからなるクラスタへ4ノード追加し、8ノードからなるクラスタにした際に動的に全てのノードを利用するようにパスが増えている事を示しています。

結果的にABSを物理サーバーで利用するケース(特にデーターベースサーバーなどパフォーマンスを求められるもの)では最低で8つの仮想ディスクを利用する事を推奨しますが、クラスターサイズが大きいケースでは仮想ディスクとクラスターサイズを同じにしてみてください。

8ノードのクラスタの環境で、例えば32の仮想ディスクを使い、全てのノードを分散させる場合でも結果的に4つのStargateのインスタンスがきちんと動作します。

 

クラスターサイズより多くの仮想ディスクを利用しても、ノードを追加時にABSは動的にロードバランスを行い、既存のノードをと新しいノードで自動的に分散されパフォーマンスを向上させます。

MS ExchangeとMS SQLの例では仮想マシンに対しての内容をカバーしていましたが、今回は特に物理サーバ―の場合についてカバーしていきます。

現在、20のデータベースがあるMS Exchange サーバーがあり、パフォーマンスの要求は各データーベースの3桁ようなIOPSの場合、私はお客様にはデーターベース毎に一つの仮想ディスクとログ用に別途仮想ディスクの設定をする事を推奨します。

もっと大きなMS SQLサーバーで数千、数万ものIOPSが必要な一つのデーターベースの場合、複数の仮想ディスクをまたぐように分散する事で物理サーバーのパフォーマンスを最適化できます。

同じにおもいます??? 上の2つの内容はパート3の内容のコピー&ペーストなのです。

同じルールが仮想マインと物理サーバーに適応される、シンプルですよね!

 

もっとパフォーマンスがほしいですか?

これも同じルールが物理サーバーに適応されます。

パート 3 , 4 で学んだように

  • CVMのvCPU を増やす
  • CVMのメモリーを増やす
  • Add storage only nodes

簡単ですね

概要:

パート3,4,5 でNutanixが提供するパフォーマンスのスケーラビリティについて学びました。

このルールは物理、仮想環境に適応する事が出来きますし、単純に仮想ディスクの追加、ストレージ専用ノード、CVMのリソースの増加しパフォーマンス向上となり、要件を満たすことが出来るようになります。

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

2018/10/10

Nutanix スケーラビリティ – パート 4 – AHV環境でモンスターVMに対するストレージパフォーマンス

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

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

原文を参照したい方はNutanix Scalability – Part 4 – Storage Performance for Monster VMs with AHV!をご確認ください。

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

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

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

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


パート3では次のように一つの仮想マシンのパフォーマンスを上げる方法を学ぶことが出来ました。

  • 複数のパラバーチャルSCSIコントローラーを利用する
  • 複数の仮想マシンのディスクを利用する
  • データーベースの様な大きなワークロードを複数のvDisk/コントローラーに分ける
  • 仮想マシンのvCPU / vRAMを増やす
  • ストレージ専用ノードの追加
  • Nutanix Volumes の利用

今日もNutanixの中で特にソリューション/パフォーマンスチームの技術チームは常により効率よくパフォーマンスを向上する方法を突き詰めています。

同僚の一人であるMichael Webster 氏(NPX#007 and VCDX#66の有資格者)は現在、Volume Group Load Balancer (VG LB)と呼ばれている機能の設計と開発に関わったチームのメンバーでした。

Volume Group Load Balancer はより単純で動的なバージョンのNutanix Volumesを作成するための、Acropolis Distributed Storage Fabric (ADSF)の利点であるAHVターボモードとIOパス効率を統合したAHVの唯一の機能です

Nutanix Volumesを介したVG LBの主な利点といえば、シンプルな事です。

Nutanixの仮想マシンに対して必要なものは何もありません。

PrismのUIからVG LBを作成し仮想マシンの構成をアップデートするだけです

Updatevmwvg

現在のVG_LBで一つだけ手間のかかる事といえば、ロードバランス機能を有効にすること位なのですが、これにAcropolis CLI (acli)コマンドを実行する必要があります。

コマンドは次の通りです

acli vg.update Insert_vg_name_here load_balance_vm_attachments=true

お客様が全てのCVMがVG LBのIOを提供させたくない、いくつかのCVMをロードバランスから除外したいと考えている場合でも、CVMへの接続が確認されても、Acropolis Dynamic Scheduler(ADS)が仮想ディスクのセッションを移動させるのでクラスタの設定はそのままにする事を推奨します。

iSCSIセッションはまた動的にバランスされ個々のCVMのワークロードが85%を越えるとホットスポットを迅速に緩和するために他のCVMへ移動します。これがCVMを除外しないで下さいといっている理由となります。

VG LV ではなんと> 8k のランダムリードIOpsで100万IOPSを達成し、遅延はわずか0.11msでした 

10ノードのクラスタでこの値を達成したのです。考えてみてくださいクラスターを拡張したらどれくらいの値になるのか?

良くある関連性のある質問で、高いパフォーマンスのVMがvMotionしたらどんなことが起こるか

というものがあります。上記リンクはYouTubeのデモも含まれています。簡単にいうとIOはvMotionしている凡そ3秒間の間100万 IOPSを下回ることになりましたが結果は956,000 iops です。

言いたい事は3秒の間,10%程度のパフォーマンスのドロップでこれはマイグレーションに起因していてストレージレイヤでは無いのです。

次の質問は複合のリード・ライトのワークロードはどうでしょうか?

再度上記のリンクにYouTubeのデモを含めた詳細を記載しておきます。

ここでもおそらく驚くことは無いと思いますが、この結果は最大で436,000 IOPSのリードと187,000 iops のランダムライトが突如マイグレーションするとパフォーマンスは359,000 のリードiopsと164,000 iopsのランダムライトに落ちますが、数秒以内にさらによい値の446,000 iops のリードと192,000 iops のランダムリードを達成したのです。

Nutanix VG LB は素晴らしいパフォーマンスが日々Live Migrationなどの操作を行っている仮想マシンでさえも達成する事が出来るのです。

VG LB機能はNutanixの独自であり、本当の分散ストレージファブリックによって実現しているのです。

Nutanixの拡張性が高いSoftware Defined Storage (SDS)とストレージ専用ノード、AHVターボ、VG LBといった独自の機能があります。 ”なぜ”という質問はSANを推奨している方に対して真剣にしなくてはいけない質問なのです。

概要:

パート3ではNutanixが提供している仮想マシンへの素晴らしい拡張性、Nutanix Volumesの提供をお話ししました。

このNutanix Volumes はパート4の中で、どのようにNutanixの次世代HypervisorのAHVが簡単にモンスターVMのパフォーマンスを向上されせる事ができるのかを説明しています。

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

The Nutanix Certified Professional (NCP) が開始しています!

本記事の原文はNutanix社のTraining & Certification Merketing Manager であるJill Liles氏によるものです。
原文を参照したい方は <こちら > をご覧ください。
情報は原文の投稿時のものですので、現時点では投稿時の情報と製品とで差異が生じている場合があります。
当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら。
ネットワールドのNutanix関連情報は、ぜひ当社のポータルから取得ください。
(初回はIDおよびパスワードの取得が必要です。)


0615bb2c65bf4f6ab680f391a72a7e92_th



Nutanix Educationは今日 Nutanix Certified Professional (NCP)  認定試験を発表出来ることが大変嬉しく思います。


Nutanix Certified Professional(NCP)によってお客様の、展開、管理、トラブルシュートのスキルを証明する事になり、データーセンター内のAOS5.5のトラブルシュートにより成功してた方は展開、そしてAOS5.5のノード,Block,Clusterの管理が行うことが出来るようになり、モニタリング、トラブルシュート、AHVと仮想マシンの管理をPrismを通して行えるようになります。

11/27日までは無償で試験が受けられます!

新しい認定試験は信頼性、価値、Nutanixの認定の向上という3つ視点でNPPとは異なってきます。

NCPの開発方法で使われた方法はより、正確で厳密にプロセスかされ、NCPは殆ど大手IT認定プログラムで行われている業界標準に従ったプログラムとなります。

NCPプログラムは保護されており、試験を完了するまで外部のリソースを利用する事が出来ません。この保護の為にNCP試験では試験を受けている間はモニターし誰が試験に受けているかを確認しています。

このリモート保護の仕組みによりNCP試験はどこかれでも受験できるようになっているので、お客様はテストセンターへ訪問する必要がありません。

このシステムにより試験をより多く受けることが出来る環境を皆様に提供し、安全な環境を維持しています。

NPP認定試験は2018 10月1日をもって終了しました。

NCP認定を完了するにはトレーニング、試験のガイド、FAQをご覧ください。

詳しくはwww.Nutanix.com/certificationを参照頂ければと考えております。

NPPの試験が終了となり、今後はNCPと呼ばれる試験に変更されました。

そして良い事にNCPは11月27日まで無償で受講が出来きます。

上記日程を過ぎますと費用が別途発生してしまいますので、無償の間に皆様も取得を目指してはいかがでしょうか

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

2018/10/09

Azure Automation と Microsoft Flow で 仮想マシンの起動・停止ボタンを作ってみよう

今回のテーマ

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

 

今回のお話ですが、Azure 仮想マシン管理に関するトピックとなります。

今回は大きく以下の3つの機能を組み合わせた内容となります。

・Microsoft Flow

・Azure Automation

・Azure Monitor

 

まずはこちらに関して簡単に概要をご説明したいと思います。

 

Microsoft Flow とは

Microosft Flow に関しては過去の投稿でもご紹介しておりますのでそちらも併せてご確認頂け

ればと思いますが、端的に言えばOffice 365が提供する自動化ツールとなります。

 

Microsoft Flowが提供する機能の中で、自動化の処理をキックする手段として「Flowボタン」

というものが用意されています。

 

Flowはスマホアプリとしても提供されているのですが、スマホアプリからボタンをクリックする

事で自動化処理を開始する事が出来ます。

Azure Automation とは

FlowがOffice 365の自動化ツールで、こちらはAzure自動化ツールといったところでしょうか。

Automation を利用する仮想マシンの状態や起動、停止などAzureのリソースに対する自動化を

実現する機能となっています。

参考URL:Azure Automation の概要

 

Azure Monitor とは

Azure Monitorは、最新の詳細なパフォーマンスと使用率のデータを取得したり、全てのAPI

呼び出しを追跡するアクティビティログにアクセスしたり、Azure リソースの問題をデバッグ

するための診断ログの取得が可能です。

 

またアラートルールを構成する事でステータス変更などを管理者に通知する事が出来ます

 参考URL:Azure Monitor

今回のゴール

ご紹介したように Azure Automation 機能を利用する事で Azure 仮想マシンの起動、停止を

スケジュール可能となりますが、スケジュールだけでなく自分の好きなタイミングで手軽に起動、

停止する方法は無いかなぁと考えていたら同じように考えてらっしゃる方がやはりいました!

 

Using Microsoft Flow to Start and Stop a Set of Azure VMs

https://briantjackett.com/2017/10/15/using-microsoft-flow-to-start-and-stop-a-set-of-azure-vms/

 

今回はこちらの情報を参考にしながら、実際に起動・停止ボタンを作成し Azure Monitorによる

ステータス監視をプラスした内容をお伝えしたいと思います。

導入ステップの流れ

今回は大きく以下の3ステップで進めていきます

 

  • Azure Automationで仮想マシンの起動・停止アクションを定義
  • Microsoft FlowでAzure Automation 処理を呼び出すフローを作成
  • Azure Monitorのアラートルールを作成

 それでは早速見て行きましょう

導入ステップの詳細

  • Azure Automationで仮想マシンの起動・停止アクションを定義

 

Automation の最初のステップとして、Automation アカウントを作成していきます。

Azure 管理ポータルにアクセスし、[リソースの作成]をクリックします。

Image1_7

検索窓でAutomationと入力します

Image3

検索結果から[オートメーション]をクリックします

Image4

[作成]をクリックします

Image5

Automationアカウント名、サブスクリプション、リソースグループ、場所を指定して[作成]を

クリックします。今回はアカウント名は[labo01]としました。

Image7

作成完了後、アカウント一覧から[labo01]をクリックします

Image8

[プロセス オートメーション]-[Runbookギャラリー]をクリックします

Image9_2

ギャラリー一覧の最初に表示される[Start Azure V2 VMs]をクリックします

Image15

[インポート]をクリックします。

Image11

Runbookの名前を入力し、[OK]をクリックします

Image13

Runbook一覧から作成したRunbookを再度クリックします

Image19_3

[編集]をクリックします

Image21

[公開]をクリック後、[はい]をクリックします

※一度[公開]を実行することでRunbookの編集可能な状態となります。

Image23

[リソース]-[Webhook]をクリックします

Image24

[Webhookの追加]をクリックします

Image25

Webhookの名前を入力します。その後、URL欄に表示されるアドレスをメモ帳などにコピー&ペーストしておきます。

※URLの情報はセキュリティのため新規作成時のみ表示される情報となっていますので必ず記録しておいて下さい。

Image28

コピー&ペーストが完了したら[OK]をクリックします。

Image29

続いて[パラメーターと実行設定]の項目を入力します。

Runbookの適用範囲となるリソースグループ名や仮想マシン名を入力し[OK]をクリックします

※今回は特定のリソースグループ内の全ての仮想マシンに適用したいため、リソースグループのみ
 指定しました。

Image32

ここまでの手順で「仮想マシンを起動する」アクションが整いました。

続いて Runbookギャラリーから[Stop Azure V2 VMs]に対しても同様の手順を実行して

[仮想マシンを停止する]アクションを設定します。

Image16_2

Automationアカウントの構成が完了したら次はMicrosoft Flowの設定に移ります。

  • Microsoft FlowでAzure Automation 処理を呼び出すフローを作成

Office365 管理ポータルにアクセスし、Flowを選択します。

 

Image42

[一から作成]をクリックします

Image43

再度[一から作成]をクリックします

Image45

Flowを実行するトリガーを選択します。今回はFlowボタンをトリガーとしたいので一覧から

[モバイルのFlowボタン]を選択します。

Image46

続いて[新しいステップ]-[アクションの追加]をクリックします

Image49

アクション一覧から[HTTP]をクリックします

Image50

[HTTP-HTTP]をクリックします

Image51

[方法]には[POST]を指定します

Image53

[URI]には、Automation アカウントのWebhook作成時にコピーしておいたアドレスを入力し

[保存]をクリックします。

※ここでは[Start Azure V2 VMs]作成時にコピーしたアドレスを貼り付けてます

Image54

「仮想マシンの停止」のフローに関しても同様の手順を繰り返します。

ここまでの手順でHTTP POSTリクエストをトリガーに Automationで定義した仮想マシンの

起動・停止が発動する仕組みが整いましたので、今回のお題に対する目的は達成出来ました。

 

ただ、これだけでは仮想マシンの起動・停止を発動したのは良いけどちゃんと実行出来ているのか

気になりますよね。

 

 そこで最後のステップとして、Azure Monitor の機能を利用して仮想マシンの状態を確認する

仕組みを作っていきます。

 

  • Azure Monitorのアラートルールを作成

 Azure 管理ポータルにアクセスし、画面左の [モニター] から、[アラート]に移動し、画面上部の

[新しいアラートルール]をクリックします。

Image3_4

[ターゲットの選択]をクリックします

Image4_3

[リソースの種類のフィルター]のドロップダウンリストから[Virtual Machine ]を選択します

Image5_2

仮想マシンのみ表示される状態となりますので、ここで対象となるリソースグループを選択します

※リソースグループを選択することで、リソースグループ内の全ての仮想マシンが対象となります

Image7_2

[アラートの条件]で[条件の追加]をクリックします

Image8_2

[システムロジックの構成]一覧から[仮想マシンの停止(virtualMachine)]をクリックします

Image9_4

[状態]ドロップダウンから[成功]を選択します

Image11_3

[3.アクショングループ]に移動します

Image14_3

[新しいアクショングループ]をクリックします

Image16_3

アクショングループ名、短い名前、サブスクリプション、リソースグループなど入力します

Image17_2

[アクションタイプ]のドロップダウンリストから[電子メール/SNS/プッシュ/音声]を選択します

Image19_4

任意の[名前]を入力し、[電子メール]チェックボックスをオンにします。

最後に通知先となるメールアドレスを入力後、[OK]をクリックします

※複数アドレスの登録は出来ないため、複数人で受信したい場合はグループエイリアスをご準備下さい

※通知先のメールアドレスにはアクショングループに追加された旨の案内メールが届きます

Inkedimage40_li

再度[OK]をクリックします

Image22_2

[アラートルールの作成]をクリックします

Image23_2

作成したアラートルールは画面上部の[アラートルールの管理]から確認出来ます

Image44_2

ここまでの手順と同じ要領で[仮想マシンの割り当て解除 (virtualMachines)]の成功ログを

条件としたアラートルールを作成して設定完了となります。

実際の動作を確認してみる

最後の今回の動作を確認したいと思いますが、Microsoft Flow アプリを初めて利用される場合は

事前に App Store または Google Playからインストールして下さい。

App Storeはこちら

Google Playはこちら

インストールが終わったら、Microsoft Flowを起動し、Office365 アカウントでログインします。

画面下に[ボタン]が表示されますのでこちらをクリックします。

 

Flowで作成した[仮想マシン起動]と[仮想マシン停止]ボタンが表示されますので、今回は

仮想マシンが現在起動している前提で「仮想マシン停止」を実行してみます。

Button_3

Flowボタン実行後まもなく、Azure Monitor アラートルールによって仮想マシンが停止した旨の

メールが通知されている事が確認できました。

Image55 

まとめ

今回のAzure Automation とMicrosoft Flowによる仮想マシン起動・停止してみようという

お話でしたが、如何でしたでしょうか。

Azure といったクラウドサービスは使った分だけ課金されるものです。

水道のように蛇口をひねれば水がすぐに飲めるという利便性がある一方で、使えるからと

言って水を出しっぱなしにしては料金も掛かります。

Azure においても検証環境など短時間で利用するもの、常時起動する必要のないものは

使いたい時だけ起動すればお財布にも優しい使い方だと思います。

皆さんも是非これらの機能を利用して煩雑な手順を自動化などを試して頂ければと思います。

今回も最後まで読んで下さり有難うございました!

記事担当者:津久井

2018/10/05

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

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

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

最近の動向

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

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

20180926_10h48_44_3

20180926_10h48_51_2


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

20180926_10h55_51



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

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

20180926_11h04_42



Why IBM? Why Kubernetes?

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

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

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


IBM Cloud Privateのご紹介

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

20180926_11h59_44


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

20180926_12h00_40



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

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


オープンテクノロジー

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

20180928_14h10_16



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

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

20180926_14h37_32


マルチクラウド対応

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


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

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

20180926_14h52_35



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

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

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

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

20180926_14h57_07

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

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

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

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

20180928_15h05_12



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

20180926_15h07_21

20180926_15h07_30

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


注意事項

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

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

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

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

    IBMならどうなのか?

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

20180926_15h46_56



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

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

VersaStackとは?

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

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

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

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

20180926_16h54_54

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

検証デモ

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

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


YouTube: IBM Cloud Private検証動画


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

なにをするか?

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



最後に

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

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


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

アクセスランキング

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