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


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

2018/09/26

Lenovo のネットワーク製品とネットワーク自動化ソリューション(ThinkAgile Network Orchestrator)を覚えてみよう!

この記事はレノボ・エンタープライズ・ソリューションズの小宮様に寄稿いただきました。
今回は、Lenovo社が提供するネットワーク製品とネットワーク自動化ソリューションについてご紹介致します。

------------------------------------------------------------------------------

レノボ・エンタープライズ・ソリューションズ小宮です。本日はNutanixのソリューションでも重要な要素になるネットワークに関する話題を取り上げてみたいと思います。

まずは、レノボのネットワーク製品に関する話題とNutanix環境におけるネットワークの自動化ソリューションについてお話します。

 

  1. レノボのネットワーク製品について

まず、レノボがなぜネットワーク製品を出しているのか?と思う方もいらっしゃるかと思います。レノボは2014年10月にIBMからx86サーバの事業を移管されてきたときに、IBMが買収していた旧Blade Network Technology社の製品がそのままレノボに移ってきたことになり、データセンター系製品のラインナップが現在もあります。

1_lenovoha_3


 また、レノボのネットワーク製品ですが、業界のアナリストからも高い評価を得ています。

  • パフォーマンスと互換性に優れている
  • SDNやNFV向けの新たなテクノジーを持っている
  • データセンター事業者にとって最も低いTCOを提供可能
  • については、競合他社に比べ、パフォーマンス面で優れていることと相互接続性も問題ない調査が記載されています。
  • については、SDNおよびクラウド向けのネットワーク対応があるだけでなく、世界の通信事業者向けのNFV(Network Functions Virtualization)におけるPoC環境を提供しています。

⓷については、競合他社に比べ、TCOの観点で優れていることが記載されています。

 

あまり知られていない内容ではありますが、これを機に覚えて頂ければと思います。

 

  1. Lenovoのネットワーク製品のポートフォリオ

2_


 
こちらがLenovoのネットワーク製品のポートフォリオになります。ソフトウェア(Cloud Network Operating System[CNOS])に関しては、ネットワーク機器を管理するXClarityの対応をはじめとして、Telemetryなどのネットワークの予兆検知・将来予測などのSDN機能などもございます。今回はこの中でもNutanixのPrismと連携可能なThinkAgile Network Orchestrator(CNOS対応必須)を最後に紹介したいと思います。

ハードウェアに関しては、通常の1Gスイッチに加えて、ハイパーコンバージドやiSCSIストレージ環境で利用される10G/25Gトップオブラックのスイッチラインナップ、データセンター向けのコアスイッチに相当する40G/100Gのスイッチがございます。このうち

このうち、CNOSに対応しているのはThinkSystem NEシリーズのスイッチになります。

 

3_thinksystemne

ここで、ThinkSystem NEシリーズの説明をします。今回すべてのスイッチでCNOSが対応することが可能になっているわけですが、こちらはVLAG環境で利用することが前提となっており、仮想マシンの状態と連動してネットワークの設定が可能になっています。また、XClarityによるスイッチ管理やVMware Log InsightやOpenStackなどの連携により、オープンな環境で利用できます。また、これらはAnsibleやREST APIなどにも対応しており、今回はNutanix PrismとREST APIの連携により仮想マシン作成時・変更時・削除時のVLAN設定変更の自動化を行います。

 

  1. Lenovoのスイッチがもたらすメリットとは?

4_


従来のネットワークは3層のアーキテクチャになっていて、Access系からCore系にアクセスするというNorth / South型のネットワーク構成になっていました。このネットワークはどちらかというとクライアントーサーバ系の通信でよく使われており、大規模で高額なコアスイッチが必要となります。こちらの構成は拡張を前提していないため、トラフィックが混雑してしまった場合に対処が難しくなります。

特に昨今は仮想化環境によりクライアントーサーバ通信よりもむしろサーバ間通信のほうが多くなってきており、East-West型のネットワークが主流になってきています。このようなネットワークを構成するときに利用するのが、LEAF/SPINEと呼ばれるデータセンタースイッチングの技術になります。この構成の特徴はネットワークをスケールアウトに拡張できること、高額なスイッチを用意せず比較的安価なスイッチをフラットに配置して構成します。このような構成するスイッチにレノボのThinkSystem NEシリーズがまさに適していると言っても過言ではありません。また、従来型な構成で必要な高額なスイッチのラインナップはレノボにはありません。トップベンダーに比べても比較的安価に購入できるレノボのスイッチをデータセンター近代で利用するのも良いと思います。

 

  1. データセンターのネットワーク管理における悩み事

5_


データセンター内のネットワーク運用で管理者を悩ませることが数多くあります。例えばネットワーク機器についてはお客様を多く収容しすぎてVLANの制限(4096)やセキュリティに引っかかってしまうこともあります。仮想マシンの設定変更によって、ネットワークの切断やメンテナンス作業が発生してしまうこともあります。また、手動でのネットワーク設定を行うことにより、夜間作業や休日作業を余儀なくされヒューマンエラーにつながりダウンタイムが発生することが考えられます。このようなことを避けるためにもネットワークの設定の自動化が必要になります。

 

  1. Lenovo ThinkAgile Network Orchestratorの登場

6_lenovothinkagile

7_thinkagileorch

先にも述べたようにThinkAgile Network OrchestratorはNutanix PrismとThinkSystem NEシリーズとAPI連携することによりネットワークの設定変更を自動化します。Prism上でトポロジーを検出して、仮想マシン作成・変更に合わせてスイッチにネットワーク情報を送信します。仮想マシン作成時に行うことで、事前にネットワークスイッチへのコンフィグ追加の作業が不要になります。これによりメンテナンスウインドウも不要でTCO削減につながります。また、稼働したままでの設定変更であることから稼働時間の向上にもつながり生産性の向上にもつながります。

 

  1. ThinkAgile Network Orchestratorが解決する問題

8_thinkagilenetwork


ThinkAgile Network Orchestratorが解決する問題は主に4つの内容になります。

  • ヒューマンエラー
  • ネットワークの停止
  • ネットワーク管理者の依存
  • 効率性

完全自動化によりヒューマンエラーはなくなり、ネットワークの停止もなくなります。また、VLAN設定を事前に行う必要がないことから、管理者による作業はなくなります。VLAN管理を行う必要がなくなることから管理によるオーバーヘッドが削減されます。

9_prism

自動化した場合と自動化しなかった場合での内容の違いを記載してみました。

ThinkAgile HXにはNetwork Orchestratorは標準では利用できるわけではなく、別途作業が必要になりますが、スイッチ上にコンフィグを10行程度追加して、Prismからスイッチの管理ポートと通信できるようにすれば設定は終了です。

Lenovo ThinkAgile HXとThinkSystem NEシリーズの組み合わせで一括サポート可能なハイパーコンバージド環境が提供可能になります。

 

10_lenovothinkagilenetwork

参考までにThinkAgile Network Orchestratorのコールフローを記載しておきます。スイッチに事前作業およびPrismでスイッチを認識させる作業が終了すれば、機能が利用可能になります。管理者が仮想マシンを作成時にVLANを指定すると、スイッチ側に設定が反映されてネットワークが利用できるようになります。

もちろん作成時だけでなく、変更時や仮想マシン削除・シャットダウン時にも連動してVLANの利用状況をスイッチと連携することにより、必要のないネットワークは設定しないようにしています。

 

小規模でシステム管理者が少ない企業で、仮想化環境でサーバ直下のスイッチの管理をサーバ管理者が行う場合に非常に適しています。

現状はESXiにも対応しておりますので、Nutanix環境で積極的にご提案して頂ければと思っております。

 

よろしくお願い致します。

------------------------------------------------------------------------------

今回は小宮様に Lenovo 社の ネットワーク製品とネットワーク自動化ソリューションについてご紹介いただきました。
小宮様には今後も定期的に寄稿いただく予定ですので、みなさまどうぞご期待ください!

 

Nutanix Calm 5.7 and 5.8: 新しいクラウド、新しいパワー

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


4a5774ec2c7f41f0be7265cd1c9b9afa_th

私たちがAOS5.5とCalmをリリースしてから6カ月も経過しているなんて信じられないことです。 Nutanix CalmはPCの一つのメージャーパッチがありました。最初のPrismのスタンドアローンのリリースといくつかのマイナーメジャーアップをAOS/Prism Central5.6, 5.8で追加し、今日はどんなクラウド、ツールそして機能がこれらのリリースで追加されたのか、どんな利点をここから得られるか見ていきましょう

ワークロードをESXi(Nutanix Clusterでなく、既存のESXiを含みます) と GCPへの展開

Prism Central 5.7で追加された素晴らしい機能はワークロードをESXiへ展開できるという事です。

このESXiはNutanix Clusterである必要が無く、これまでの3Tier環境などのESXiへも展開できるのです。

これを意味する事は、お客様は自動化とアプリケーション定義をCalmを利用して既存のクラスタをまたがる全ての環境に対してPrismから実行できるようになるのです。今はお客様はワークロードを定義、制御、管理をESXi5.5 , 6.0 , 6.5が稼働するインフラへワンクリックで実行できるようになりました。

Cba19ebbe9b14ec2baad22bf9133acc6

5.7では加えてGoogle Cloud Platform(GCP)をもサポートしお客様のブループリントをGoogle Cloudへ展開してGoogle Compute Engine の利点を得られることになります。

5.8.1ではさらにAWS GovCloudのサポートを行うので、合計でサポートするクラウドは5つ(AHV, ESXi, AWS , AWS GovCloud, GCP)となります。

こちらのTechTopX video on Application Profilesを確認すると簡単にこれらが利用できることが理解頂けるはずです。

D890d996c8184498b024c8e53bac6498

ブループリントとマーケットプレイスの更新

5.7と5.8で多くの管理、展開、自動化を行うえるブループリントを追加しました。

多くの事がカバーできるようになっておりますが、今回の新しい機能はこちらになります。

アプリケーションのスケール:

5.7ではアプリケーショの展開を実行する一方で”スケール”のタスクを使用してアプリケーションのネイティブ的なスケールアウトとスケールダウンが実施できるようになります。

これにより自動的にサービスの追加のコピーが展開され、お客様は他のスケールアクションでアプリケーショの応答が期待通りのものかを確認する事が出来るのです。最小限のセットアップ単位と最大の複製の許可によりアプリケーションが限界を越えてスケール、このことでリジリエンシーが失われることが無いようにします。

ブラウンフィールド インポート:

お客様はどんな既存のVMやクラウドのセットであっても直接アプリケーションへインポートする事ができます。自動化を行う事ができ、新しいサービスを既存の物と統合し既存のアプリケーションCalmから管理する事ができるようになります。もっと詳しい情報はこちらをご参照ください

6b4c575963c64157b7fc2c3c750669b8

マーケットプレイス ブループリントのバージョン化:

ブループリントを公開する際にお客様は現在バージョンを選択する事が出来るようになり、新しいプリケーションを展開するか、既存のアプリケーションのバージョンに合わせるかという事ができるようになります。まただれがどのバージョンを見れるかも設定できるようになりました。

これで以前のものへのアクセスを失うことなく新しいアプリケーションが展開できるのです。

271cfc0df9c14aca88d335bbaace6519

Web SSH コンソール:

アプリケーション管理、アップグレードと同じく、お客様はCalmからSSH コンソールを利用する事が出来るようになります。これには認証、ブループリントのキーストアを利用します。

これで直接ログインします。たとえ、皆さんが同じユーザー名でログインしたとしても。Calmは正常にどこへログインしているのかを把握しているので気にすることもありません

マクロのオーサリング機能:

組み込みのオートコンプリートによりオーサーリングがより簡単になりました。

Calmは (@@{}@@) から始まるマクロを認識し利用可能なコマンドリストの提供によりお客様のカスタム変数をより使いやすいようにしました。

005e16fe53634d1ea416f548e9cb9569

Native Powershell:

5.8.1のマイナー Calmリリースでは外部のWindowsサーバーに依存しないでPowerShellスクリプトを送れるようになりました。

 

Calm機能を今日から有効にしよう!


今日は5.7と5.8で追加されたほんの一部の機能しか説明できませんでした。もっと素晴らしい機能が

たくさんあります。Flowの統合、マルチクラウド、パッケージのインストール、削除のし易さの向上、Calmにはお客様が利用したい何かがあるはずです。5.7 5.8 の全ての機能をリリースノートから確認してみてください。

そして運用ガイドにはCalmで利用できる全ての機能が記載されています。

もしまだCalmを試されていないのでしたら、きっと調べる時間が無いのでしょう。

CalmはPrismCentralへ統合されていりますので、ダウンロード、インストールするものは何もないのです。単にPrism Centralから有効にしてください。

Prism Centralは25仮想マシン分のCalmで利用するライセンスが無償でついているので、仮想マシン、クラウド、アプリケーションの自動化が試せるのです。

もしいろいろと試されたりしたら是非forums.へ参加し作成したCalmの内容の共有やコミュニケーションの場としてご利用頂ければ幸いです。
 

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

最近のブログでは技術的な内容が多かったので、Calmの最新情報について記載しました。

これまでCalmを検討されているかたがいらっしゃれば、今回のこのアップデートを見ていただければ

Nutanix Cluster以外にもいろいろと使えることがお解りいただけたのではないでしょうか

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

2018/09/19

Nutanixのスケーラビリティ – パート 3 – 一つの仮想マシンへのストレージパフォーマンス

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

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

原文を参照したい方はNutanix Scalability – Part 3 – Storage Performance for a single Virtual Machineをご確認ください。

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

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

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

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


 Part 1 からの継続となりますが、Part1では、どの様にストレージオンリーノードを利用してNutanixがストレージをコンピュートとは別に拡張する事ができるかをお話しました。今回はNutanixがどう仮想マシンのストレージのパフォーマンスをスケールアップ出来るのかをお話していきます。

これまでの物理サーバで構築している仮想マシンはストレージコントローラーや複数のドライブ(HDD/SSDなどに関わらず)からのメリットがあります。

Nutanix ADSFの仮想マシンにも同じ事が言えます。多くのストレージコントローラーと多くの仮想ディスクがストレージパフォーマンスを向上することになるのです。

これまでのESXiHyper-Vといったハイパーバイザーで最大限のパフォーマンスと低遅延の要求により最大となる4つのSCSIコントローラーをVMへ割り当てを行います。複数のコントローラーは仮想ディスクへの多くのキューの処理が出来ることを示しており、結果より少ないボトルネックの削減による低遅延を可能としているのです。

この複数の仮想SCSIコントローラーはとても素晴らしい事なのでNutanixはこの機能をデフォルトで次世代のハイパーバイザー AHVで利用する事にしました。これはTurbo Mode“.として良く知られている機能です。

これはAHV上の仮想マシンがストレージコントローラーのレイヤでお客様がすでに持っているストレージコントローラーの構成、複雑性を排除し初期状態で最適化されているのです。

仮想ディスクに関わらずお客様が最適なパフォーマンスを得るために必要な事は4つの準仮想化SCSIコントローラーを使う事です。いくつか例を見ていきましょう。

MS Exchange サーバで20のデータベースを持っており、各データベースのパフォーマンス要求は100IOPSの範囲とすると、一つの仮想ディスクと一つのデータベース、それとログ用に別の仮想ディスクの割り当てが良いでしょう。

LargeタイプのMS SQLサーバに関していえば、数万から数十万にもなるIOPSが一つのデータベースで求められます、このようなケースでは複数の仮想ディスクをこのデータベースに割り当てSplitting SQL datafiles across multiple VMDKsを利用する事がVMのパフォーマンスの最適化となるでしょう。

2つの例ともにいえる事ですが、ESXiHyper-Vをご利用の場合は、仮想ディスクは4つの準仮想化SCSIコントローラーを通してアクセスできるように構成するべきです。一方でAHVを利用いただいているお客様は単純に仮想ディスクの作成すると、それぞれの仮想ディスクはStargateと呼ばれるNutanixADSFI/Oに占有のパスで直接接続できます。

詳細な情報はSQL & Exchange performance in a Virtual Machine も合わせてご覧ください。

ここではハイパーバイザーの仮想ディスクの数、ESXiHyper-vといったハイパーバイザーに関わらず、複数の準仮想化SCSIアダプターを設定する事が最適なパフォーマンスを得る方法であると学びました。

ではモンスター級のSQLワークロードがあり、ノードとクラスタが正しく構成されており、アクティブなワークロードが100% SSD層にあるかオールフラッシュクラスタについてお話ししましょう。

AHVで稼働している仮想マシンはターボモード(ESXi/Hyper-Vの準仮想化SCSIコントローラー)を利用するし、16の仮想ディスクを追加して、お客様のデータベースはvDiskを越えて追加していくことが出来ますが、もっとパフォーマンスが必要になったら???

良いニュースとしては、Nutanixはパフォーマンスを向上する多くの方法があるので、いくつか見てみましょう。

  • CVMのvCPUを向上する

これは稀な場合ですが、NutanixVMで稼働しているソフトウェアという事を理解する事は大事です。単純にvCPUを増やしCVMへアサインする事がより多くのI/Oパフォーマンスとクラスタ機能のバックグラウンド処理を向上します。

CVMは自動的にCVMN-2vCPUStargateI/O)に割り当てられます。つまり、多くのvCPUCVMへ追加する事がI/Oパフォーマの向上につながるのです

アプリケーションのパフォーマンスがローカルCVMにより影響を受けた場合(このケースはかなり稀なケースですが)2つ以上のvCPUCVMへアサインする事でCVMにはボトルネックを軽減しアフォーマンスを向上する事になります。

実際、私は以前このような状況を見たことがあります。

一つのCVM,複数のCVM,また、クラスタの構成やお客様のクラスタの要求事項の範囲で全てのCVMvCPUを増やせるのを知ることは大事です。

22コアプロセッサーと10コアプロセッサーの混在環境のクラスタだとするとクリティカルなVM22コアプロセッサーのノードへ移動しCVM のvCPU2つ追加し、10コアのvCPUはそのままにして置いてください。

これでパフォーマンスを向上させることが出来ますし、22コアノードの利益を最大限に利用できるのです。

この記事に関してはさらにCost vs Reward for the Nutanix Controller VM (CVM)にも詳細があるのでご参照ください。

  • Nutanix CVMのメモリーを増やす

メモリーを増やすのはもう一つの簡単にパフォーマンスを向上する方法です。

メモリーの追加でパフォーマンスを向上する主な2つの利用としてはCVMのメモリーはリードキャッシュを行いますので、アプリケーション、データセットのサイズには依存します。従来のリードキャッシュと全く違うのです。

次の理由としてはCVMRAMMedusa(metadata)のキャッシュとして利用されるようになるので、読み込み遅延がすくなくなるのです。

もしhttp://cvm-ip:2009/cache_stats(下にサンプルがあります)を見てキャッシュヒット幅が50%であれば、良いキャッシュヒットと言えます。一方5%程度ならワークサイズによりますが、大幅にリードパフォーマンスを向上するかもしれません。

他のパフォーマンスで大事な要素はMedusaのキャッシュです。

vDisk block map CacheExtent group id map Cacheを出来るだけ100%に近づけたいと考えています。

Stargatecachestats

上記はワーキングセットのRange Cache 50% , vDisk block map Cache , Extent group id map Cache 100%CVMメモリーが最適なシステムの例です。

The above cache and medusa hit rates are from a test cluster and it was achieving the following performance for a database checksum task (100% read).

上記のキャッシュとMedusaのヒットはテストクラスタからのもので、データベースのチェックサムタスク(100%Read)の際は次の値を達成しました。

Exampleperformancewith100medusahitr

ポイントはとても低いリードのレイテンシであるという事です。

最大でも0.35ms 0.18ms近辺の値が数時間にわたって継続されています。

CVMのメモリーが不十分だと一貫した読み込み遅延とはならないので、この問題に直面したらhttp://cvm-ip:2009/cache_status を確認してサポートにCVM RAMのサイジングについて相談してください。

ノート:CVMメモリーがNUMAノード内で最適な状態で構成されている環境でCVMへメモリーを追加する事は「害」ではありません。唯一のインパクトは仮想マシンに割り当てるメモリーが減る事です。

おさらいしましょう

AHVの仮想マシンはターボモードを利用し16の仮想ディスクでデータベースを仮想ディスクのスパンかして全体でアクセスさせ、CVMvCPUを追加します。

そして、Readキャッシュが正しくヒットしているかを確認しましょう。しかし、さらに多くのパフォーマンスが必要な場合は何を確認したらいいでしょうか?

  • ストレージオンリーノードの追加

もしまだ私投稿したScale out performance testing with Nutanix Storage Only Nodesを読んでいない場合に向けて簡単におさらいしますが、是非こちらのドキュメントも読んでください。

簡単に言うと、MS Exchange jetstress ワークロードを4VMで最適化されている4ノード構成のHybridクラスタで稼働させて達成した値が次の通りです。

Jetstress4nodessummary

  • ベースラインテストからの観測
  1. VM辺り1000IOPSの達成
  2. パフォーマンスは全てのJetstress インスタンスを通して安定
  3. ログ書き込みは1ms の範囲
  4. データベースの読み込みは平均で10ms以下 (Microsoftが推奨している20msよりもよい結果)
  5. データベース作成時間の平均は2時間24分
  6. 3つのデータベースの複製は平均で4時間17分
  7. データベースのチェックサムの取得の平均は38分

その後、4ノードをクラスタへ追加したのですが、Jetstress仮想マシン、クラスタのコンフィグは何もしていませんがIOPS2倍になったのです!

4つのJetstressの各結果は次の通りです。

Jetstress8nodessummary

ストレージオンリーノードを4ノード追加した概要は次の通りです

  1. IOPSはおおよそ2倍となる
  2. ログ書き込みの平均遅延は13%程度低くなる
  3. データベースの書き込み遅延は20%改善
  4. データベースの読み込み遅延はおおよそ2倍低くなる
  5. データベースの作成時間は15分ほど早くなる
  6. 3つのデータベースの複製は約35分改善
  7. データベースのチェックサムは40秒ほど早くなる

結果から分かる通り、ストレージオンリーノードの追加で変更を行わないでパフォーマンスが向上する事が解りました。Jetstressの構成を変更していたならば、より高いパフォーマンスとより低い読み込み、書込み遅延が達成できたことでしょう。

言い換えると、ストレージオンリーノードの追加は簡単にパフォーマンスと共にクラスタのresiliency and capacityも向上するのです。

これで、ワークロードに対して高いパフォーマンスを得るためのコンビネーションとしてCVMの最適化とストレージオンリーノードの話しをしました。

もし未だ求められているパフォーマンスを達成できていなきのであれば、Acropolis Volumesでパフォーマンスを向上させられるかもしれません

  • Acropolis Volumes

Acropolis Volumes は 2016にアナウンスし、お客様がNutanixがデータセンターの標準化のためのエッジの使用例として発表しましたが、多くの理由からこのビジョンを達成できませんでした。

  • 既存のサーバの再利用の要望、要求
  • 仮想化でないアプリケーション
  • パフォーマンス/外部接続しているサーバの拡張性
  • 外部iSCSIを含めたオペレーションへの複雑性

さらに多くの詳細はこちらをご参照ください。

In-guest ISCSI を利用しているNutanix VolumesはゲストOSの仮想ディスクを直接提供します。この仮想ディスクは自動的にNutanixクラスタ内で最適なパフォーマンスが提供できるようにロードバランスされるのです。

次のツイートにはNutanix Volumesを利用した際にどの様に分散されるかのFAQがあります。下のが示す通り、4ノードクラスタでは4つのiSCSIのパスとなりますが、クラスタを8ノードへ拡張するとNutanix Volumesは自動的に8パスに拡張しているのが解ります。

ABSの欠点といえばデータローカリティがなくなる事ですが、もしデータのローカリティを持てなかったとしても、その次に素晴らしいのは高い拡張、レジリエンシー、動的な分散ストレージファブリックを利用できる事です。

Nutanix Volumesは即時パフォーマンスのスケールが出来ますが、制限はネットワークのバンド幅、ノード数になってくるので、100GBNIC32ノードの物理クラスタでは数百万レベルのIOPSというとんでもないパフォーマンスを提供する事になるでしょう。

このIn-guest iSCSI の設定はとてもシンプルで、単にiSCSIターゲットをNutanixのクラスタIPとして設定するとクラスターサイズが増えた際に自動で計算しロードバランスをすることになります。仮想ディスクは自動的に新しいノード間でお客様の介入なしにバランシングが行われます。

これと同じことがノードの削除、メンテナンス、アップグレード、障害などに関しても言えます。

全て自動的に管理される為、Nutanix Volumesは管理者にとって非常にシンプルな実装といえます。

要約

Nutanixは仮想マシンに素晴らしい拡張性を提供し、より多くのパフォーマンスが求められるニッチなワークロードの為のNutanix Volumesはシングルノードが提供するものよりも多くのパフォーマンスを提供できるのです。

パフォーマンスを向上させる方法として簡単にできるのは次の2つですので是非覚えておきましょう

Writeパフォーマンスを向上させる方法はCVMへvCPUの追加

Readパフォーマンスを向上させる方法はCVMへメモリーの追加

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

2018/09/12

Nutanixのスケーラビリティ– パート 2 – コンピュート(CPU/メモリ-)

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

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

原文を参照したい方はNutanix Scalability – Part 2 – Compute (CPU/RAM)をご確認ください。

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

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

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

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


パート1のシリーズではNutanixがどのようにコンピュートノードとは別にストレージを拡張できるかという話をしました。次はCPUmemoryリソースをワークロード、クラスタレベルで拡張するという話題にしましょう

まずはこれまでの共有ストレージのスケールアウトに関するおさらいです。

Hcinothci

時代遅れの3 Tier層にも見えますね

HCIでないワークロードがコンピュート専用のノードで稼働する結果では

  • 従来の3-Tierのインフラ基盤と同じようにセットアップを実施し稼働させる

  • HCIベースのワークロードとは異なるパフォーマンスとなる

  • Compute+StorageというHCIのアドバンテージをなくすことになる

  • ネットワークへの依存が高まる

  • HCIノード毎のネットワーク利用率への影響

  • ネイティブHCIワークロードなどに対するHCIの利点への影響など

業界はHCIを将来の方法として受け入れている一方で、コンピュートだけど追加するのはとても良いことに聞こえるかもしれませんが、それは従来の3-Tierの複雑性と過去に起こった問題を再導入するになります。実際の要求事項を見直してみるとNutanixのノードがサイジングとコンフィグが正しく行われている時に不足になるという事はとてもまれな事なのです。

お客様は私にワークロードを見せ驚くことが良くありますが、私はCPU/RAMまたはストレージIO、容量の要求事項には驚かされることはないのです。客様のアプリケーションは実際、高くなく、もっと低いという話を何度繰り返してきたのか覚えていません。


例1:Nutanixのコンピュートを拡張する例


SQL/Oracle DB管理者:今のアプリケーションがだんだんと遅くなっているので、もっとたくさんのCPU/RAMが必要です。

Nutanixいくつか選択肢はありますよ

  1. 仮想マシンのvCPUとvRAMをNUMAノードのサイズに合わせてスケールアップします
  2. 仮想マシンのvCPUとvRAMをホストからCVMに割り当てているvCPUを差し引いた物理コアと同じになるようにスケールアップし、RAMにも同じ作業をします。

一つ目のオプションはCPUNUMAの境界のメモリーを最大限に活用する最適な方法ですが、2つめのオプションはSQLなどのアプリケーションなどに未だ実行可能ではありますが、メモリー不足になる影響の方がNUMAの境界を越えてアクセスするペナルティよりも高くなります。

ワークロードはユニークなので物理サーバが必要です!!

購入を検討、または既にNutanixをご利用のお客様にこれらの状況を聞いたにも関わらず、数少ない実際のワークロードは、たとえ、CVMの為にリソースを削除し、近代的なNutanix(OEM/ソフトウェアオンリー)のノードが提供するCPU/RAMよりも必要としてしまうのです。

私はそれが、まさに実際に物理サーバが必要とされる要件であるとわかります。標準のサーバ上で稼働している最適なサイズの仮想マシンは望ましいビジネスの結果を提供します

現在 Nutanix NXノード1ソケットあたり、28Core 2.5GHzを持っているInterl 8180プロセッサーをサポートしているので、合計56物理コア(112スレッド)になります。

Intel8180プロセッサーSPECint rate2720 or 48.5/Coreという値を利用する事ができるわけで、これはコアのパフォーマンスを21.25%向上させることになります。

お客様がInterl Broadwell  E5-2699 v4 CPUs (44 cores)を搭載している物理サーバから移行をし、ワークロードをNutanixCPUのオーバーコミットメントをvCPU:pCore1:1 とし Intel Platinum 8180 processor CPUを搭載した場合では8 pCoreCVMに割りあってたとしてもまだ48pCoreSQLの為に利用できます。

2328SpecIntRateでは全てのコアを利用している物理サーバよりも良い結果を出しています。

つまり 仮想マシンのCPUパフォーマンスが32%ほど、物理構成のサーバと比較して向上していることになるのです。

NutanixCVMとAcropolis 分散ストレージファブリック(ADSF)は高いパフォーマンスと低遅延ストレージ、CPUの効率化を実際に提供します。

この簡単な例からしても、お客様はNutanixの仮想マシンは新しい物理サーバであっても簡単に入れ替えることができ、一つの新しいCPUでより良いパフォーマンスを提供できるという事を理解頂けたことでしょう。

3-5年前の物理サーバがいくつものCPUの世代を越えてフラッシュベースのストレージへスケールアウトする事を想像してみましょう


例2:仮想マシンがNutanixノードのCPU/RAMより多くを必要とした場合


SQL/Oracle DB管理者: 今のアプリケーションは既存のノードが提供しているCPU/RAMより多くCPU/RAMが必要となります。

Nutanix:解決にはいくつかの選択肢があります

a):一つまたは、スペックの高いノードを購入しましょう(例 : Intel Platinum , Gold のCPUを搭載したNX-8035-G6を既存のクラスタに追加し仮想マシンをこれらのノードへ移動します。そして、アフィニティルールを設定し仮想マシンをパフォーマンスの高いノードへ固定しましょう

Nutanixは同じクラスタ内に世代、ハードウェアの異なるモデルの混在をサポートしており、これはいくつかの利用により専用のクラスタを作成するよりも良いオプションとなります。

  • 大きいクラスタはレプリケーショントラフィックの為の多くのデータの複製先にとなるので、平均書込み遅延が低くなります。
  • 大きいクラスタでは多くの障害に潜在的に耐えることが出来きますし、ドライブ、ノードの障害の復旧時間を向上する事がきる事から高いレジリエンシーを提供できるのです。
  • 大きいクラスタではノード障害時のインパクトが少なくて済みます

b):一つまたは、スペックの高いノードを購入しましょう(例 : Intel Platinum , Gold のCPUを搭載した新しいクラスタを作成して仮想マシンを移行しましょう。

専用クラスタは魅力的に感じるかもしれませんが、ほとんどのケースでは、最終的により高いパフォーマンス、レジリエンシーと拡張性を提供できる混在のワークロードクラスタを推奨します

C):MSMS SQL , Oracleはスケールアップよりもスケールあるとする事で、パフォーマンス、レジリエンシーの向上とインフラコストの削減が行えます。

MSMS SQL , Oracleはスケールアップよりもスケールあるとする事で、パフォーマンス、レジリエンシーの向上とインフラコストの削減が行えます。

一つの大きな仮想マシンが多くのデータベースを提供するのはあまり良い事ではありませんので、スケールアウトし多くの仮想マシンを稼働させることで、Nutanixクラスタ内で分散され全てのVMを通してワークロードが行われるのです。

99%のワークロードでは、コンピュート専用ノードの価値は見出せませんが、常に例外はあります。


3: 既存のハードウェアを再利用する


SQL DB管理者:Nutanixは最高なんだ、何台かのEOL1年以上ある物理サーバがあるんですが、Nutanixを入れて使い続けられるのだろうか?

Nutanix:いくつか選択肢があります。

a):ご利用いただいているハードウェアがHCLに掲載があるものでしたら、ソフトウェアのライセンスを購入し既存のハードウェアに展開してご利用いただけます。

b):Nutanix Volumesを利用しiSCSIを経由してスケールアウト側の高い冗長性を持ったストレージを利用する

Nutanix volumes2015年に発表されWindows ClusterMSSQL,クラスターファイルサーバで一般的に利用されるSCSI-3 Persistent Reservationsのストレージ利用としてサポートされます。

Nutanix Volumesはいくつかの次の例を含むユースケースをサポートしています

  • MS Exchange ServerのためのiSCSI接続
  • Linuxベースのクラスタの為の共有ストレージ
  • Windowsのフェイオーバークラスタ
  • Windowsクラスタの為のSCSI-3Persistent Reservation
  • OracleRAC環境の共有ストレージ
  • 物理環境でのiSCSI利用

結果Nutanix volumesは既存のハードウェアの再利用を可能としてROIを高める一方で、ADSFのメリットを得ることが出来るのです。

一度ハードウェアがEOLになると、すでにNutanixの上に置かれたストレージはすぐに仮想マシンへ提供する事が出来ます。ワークロードはNutanixHCIのメリットを受けれることになります。


今後の機能


2017年の終わりに NutanixNutanix Acropolis Compute Cloud (AC2)を発表しました。これは次に示すコンピュート専用ノードを提供する事を示しています。

Blog_ac202

お客様に3-Tierモデルや、HCIがそのままでは進化してないで無いかと理解してほしくないので、この機能については述べますと、それはコンピュート専用のノードでは無いのです。

この機能はソフトウエアベンダー (Oracleなど)のライセンスの観点からお客様がCPUCoreを最大限にアプリケーションが利用できるようにするためにりニッチな環境化向けにデザインされています。

ちょっとだけ言わせてください。

  • この機能は一般的な仮想マシン向けではありません.
  • パフォーマンスの為の機能ではありません
  • Nutanixは3-Tier コンピュートとストレージモデルへ戻っているわけではありません
  • Nutanixは未だ進化しています

Nutanixは素晴らしい拡張性をCPURAMレベルで仮想マシン、実際のワークロードへ提供します。

物理サーバが実際に要求されるまれなケースではABSが利用できますし、まもなくAHVに向けてこれらのまれなケースにライセンス価値を最大限に利用するためにもコンピュート専用ノードを提供します。

今年リリース予定のNutanix Acropolis Compute Cloud (AC2)ですが用途やライセンスなどに

合わせて最適なワークロードへ最適なモデルを選択できるものNutanixの強味ではないでしょうか

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

2018/09/10

Lenovo ThinkAgile HXのラインナップおよび 各種サービスも含めて覚えてみよう!

この記事はレノボ・エンタープライズ・ソリューションズの小宮様に寄稿いただきました。
当社ではNutanix製品を取り扱っておりますが、Nutanix社によるNXシリーズ以外の選択肢として、
Lenovo社によるThnkAgile HXシリーズについてご紹介致します。


レノボ・エンタープライズ・ソリューションズ小宮です。


本日はLenovoのNutanix製品であるThinkAgile HXシリーズの
ラインナップおよび各種サービスについてお話したいと思います。
最初にLenovoのNutanix製品について、ラインナップをご紹介したいと思います。

Lenovo11

Lenovo12

Lenovo13

アプライアンスモデルと認定ノードの違いについてもう少しお話したいと思います。

  • ハードウェア・ソフトウェアの関係について
    アプライアンスモデルも認定ノードも基本同じものを利用しています。
    認定ノードアプライアンスモデルについてはアプライアンスの構成で(ファームウェアも含めて)検証済みの構成で出荷されます。
    もちろん、認定ノードでもメモリの追加やNICの追加も対応可能ですが、
    あくまでアプライアンスのハードウェア構成として認定されているものをサポートするため、
    お客様側で非サポートの構成にしていれば、Lenovoのサポートを受けることはできません。
    認定ノードの場合にも、アプライアンスと同様の構成であることを確認してご提案することをおススメ致します。
    また、アプライアンスモデルと認定ノードの混在構成はサポートしておりません。
    アプライアンスモデル・認定ノードの提案は一番初めの段階で見極めるようにしましょう! 
  • Nutanixのソフトウェアライセンスについて
    さらに異なる点として挙げられるのはライセンスです。
    ライセンスについて、アプライアンスは購入型になっており、CPU・メモリ・SSD・HDD・NICの各種パーツにライセンスの金額が設定されています。
    認定ノードについては期間ベースのライセンスになっています。
    つまり、構成に関係なくノード数に比例してライセンスが課金されます。
    ここで気づくかと思いますが、構成に関係ないということは、1台のサーバの高スペックにしてもライセンスが変動しないため、認定ノードに関しては高スペックにしたほうがお得になりますが、実はライセンス金額によっては低スペックのサーバで構成した場合はアプライアンスの構成が安価になることがあります。
    また、小規模の場合は認定ノードで構成すると逆に高価になることもあり、構成のバランスを考えて提案する必要があります。
    エディションについても、アプライアンスモデルはStarterからUltimateまで低スペックから高スペックから選択可能なものに対して、認定モデルはPro以降のライセンスの選択が必須になります。そのため、以下のようなケースが一つの指標だと考えます。

アプライアンスモデル:小規模構成、1台のサーバが低スペック
認定モデル:大規模構成、1台のサーバが高スペック

  • 導入作業について
    アプライアンスモデルについては、Lenovoのプロフェッショナルサービスでの導入作業(Base作業)を必須とします。
    理由としてはLenovoが責任もってお客様のシステムをするためです。
    導入の際にお客様がNutanixを利用する際に必要なパラメータを設定するだけでなく、Lenovoの工場(国内)でNutanixのソフトウェア設定のチェック、テストを行っているたけでなく、ハードウェアの初期不良チェックも行っております
    そのため、国内での導入作業後、お客様サイトでの初期不良は現在のところ(2018年8月末現在)報告されておりません
    外資系メーカーだと国外生産で品質面を問われることがよくありますが、LenovoのNutanix製品は国内での検査で品質を上げておりますので、他社に比べて差別化になる要素の一つになります。

Lenovo14

認定ノードについては、Lenovoのプロフェッショナルサービスを必須としておりません
先ほども述べたように認定ノードはお客様にて導入可能な場合にその自由度を上げるために、Lenovoでの導入作業をオプションとしております。(もちろん導入作業を含めることは可能です)
BP様において、工場出荷後のハードウェアに自社で導入したパラメータを元にお客様のサポートを行うケースにおいては、認定ノードを選択するケースもあります。
詳細は以下のイメージをご参照ください。

Lenovo15

  • 保守サポートについて
    アプライアンスモデルと認定ノードの保守について、アプライアンスモデルの場合、保守をすべてLenovoで行うということは皆さん認識できると思いますが、ソフトウェア別売の認定ノードはソフトウェアのみのため、サポートが別という考えになると思われます。
    もちろん、お客様にて障害時にハードウェア・ソフトウェアの障害を切り分けて障害対応することも可能ですが、アプライアンスで培った知識もありますので、認定ノードだからと言ってソフトウェアの部分だけサポートできないことはありません。
    今回LenovoはThinkAgile HX認定ノードとして購入したNutanix製品については、通常のアプライアンス同様の保守サポートを提供いたします
    そのため、認定ノードの保守サポートは他社に比べて差別化になる要素の一つになります。

Lenovo16

また、VMware導入される場合で一括サポートを希望される場合は、OEMのライセンスを含めることで、一括窓口の保守が提供可能になります。
導入するハイパーバイザーや一括保守を求めるレベルによる、選択するThinkAgile HXのラインナップの選択およびハイパーバイザーのライセンスの選択をご検討ください。

Lenovo17

お役に立てたら幸いです。よろしくお願い致します。


今回は小宮様に Lenovo ThinkAgile HX シリーズのラインナップおよび各種サービスについてご紹介いただきました。
ネットワールドが提供する Lenovo ThinkAgile HX を強力な選択肢のひとつとしてご検討いただければ幸いです。
小宮様には定期的に寄稿いただきますので、みなさまどうぞご期待ください!

アクセスランキング

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