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

自動化されたネットワーク仮想化はマルチクラウド環境でのビジネス継続に必要なものになっています。VXLAN-EVPNベースのオープンスタンダードは効率的でありながらマルチクラウドの為のデーターセンターの拡張(DCI)となります。

統合されたネットワーク管理はマルチクラウドを展開する鍵となります。
NutanixとMellanoxはより高いアプリケーションの稼働時間、ビジネス継続を提供しながら
シームレスなマルチクラウドネットワークソリューションの統合を行います。

エンタープライズクラウドネットワーク管理をシンプルにそして効率的にする一方で
ここらスイート　シンフォニーの始まりです。

最初の動向：クラウド、ハイブリッドクラウドとNutanix Enterprise Cloud

クラウドコンピューティングはここ最近にかなりの勢いで採用されてきています。
クラウドは新しいビジネスを素早く拡張、ビジネスの効率性の向上をするプラットフォームとして、インフラ基盤、SaaSを仮想化環境として提供しています。

独自のオンプレミスクラウドの構築やAmazon Web Services(AWS),Microsoft Azureを利用する一方
多くのエンタープライのお客様はクラウド制御、プライベートセキュリティ、拡張性とパブリッククラウドからの俊敏性からくるを最大限に活かせるハイブリッドクラウド戦略を始めています。

このアプローチによりマルチクラウドにわたる業務の合理化をするので、エンタープライズは統合されたクラウドインフラストラクチャーを頼るのです。

エンタープライズクラウドソリューションのリーダーとして、Nutanixは、オンプレミスのプライベートクラウトからリモートオフィス・ブランチオフィス（ROBO)、そしてパブリッククラウド、リモートDRサイトのITファブリック全体にわたるハイブリッドクラウドのエクスペリエンスを提供しています。

エンタープライズクラウドOSとAHV　ハイパーコンバージドインフラストラクチャの構築で
Nutanixのソリューションは俊敏さとパブリッククラウドのセキュリティ、コントロール、予測可能な経費、プライベートクラウドで必要なパフォーマンスをOne-Clickというシンプルな形に統合します。

クラウドで稼働しているアプリケーションに注目してみると、Nutanix ハイブリッドクラウドソリューション(AOS5.6以降)では
VMのマイクロセグメンテーションをFlowを利用する事でアプリケーションのセキュリティを向上します。

Flowではポリシー強化、ネットワークの拡張とセキュリティ機能と3rd パーティソフトウェアの組み込みによる自動化の為の
ネットワークの可視化を提供しており、結果的にワンクリックによるDR、ミッションクリティカルのビジネス継続をするお客様ベースの管理性が複雑なクラウド管理を簡単にするのです。

第二の動向　: ネットワークの仮想化とデータセンター相互接続

クラウドがネットワークの可視化し、複数のクラウドはデーターセンター相互接続（DCI）によって接続されます。
別々のテナントのトラフィックは仮想化ネットワークセグメントに入り、データーセンター間のアプリケーションの移動を
サポートし、モビリティ、スケーラビリティ、アプリケーションをマルチテナントにサービスるための為のセキュリティを
提供する事でクラウドインフラストラクチャーはアプリケーション指向となっています。

ネットワークセグメンテーションはレイヤー2のネットワークが仮想ローカルエリア(VLAN)化したデータセンターから
始まっています。
VLANはホストまたは、仮想マシンの接続、セグメント内での移動、セキュリティの為に他のVLANからの孤立を提供しましたが、
VLANには拡張の制限があります。　それは4000セグメントで一つのデータセンターを越えて拡張する事が出来なかったのです。

L3のネットワークと通してデーターセンターの間でVLANを拡張する為に、L3アンダーレイの上にL2をオーバーレイするVXLAN(Virtual eXtensible Local Area Network)技術が開発されています。
L3越しのトンネリングにより、VXLANはホスト、仮想マシンを配置し同じVLANに所属しているかのようにコミュニケーションが出来るようになります。
次の図はVXLANトポロジーの簡単なものです。
ホストAとホストBは2つのデーターセンターのリーフスイッチに接続されています。
2つのリーフスイッチはまたVXLANトンネルのエンドポイント(別称VTEP)としてサービスしています。

VXLAトンネルVNI1000を通してこれらの2つのホストはたとえそれが2つの別々のデータセンターにあったとしても同じVLAN100で通信できます。
24ビットの識別番号によりクラウドスケールの為に合計で1600万ものVXLANセグメントがサポートされるのです。
L3アンダーレイを通るデータトラフィックとして、ネットワークはより高い拡張性と柔軟性(BGP)、信頼性(マルチパス)と完全利用(ECMP）が再びクラウドネットワークの要求事項となります。

VXLANはVXLANセグメント内でVTEP DiscoveryとMac アドレス学習とVTEP Discoveryの為にFlood-and-Learnメカニズムを利用しています。例えば、L3マルチキャストと通してBUMトラフィックの転送(ARP 要求) , フラッディングを避けるために、IT管理者はVXLANをコントロールプレーンと一緒に展開しますが、独自のVXLANコントローラーを利用する際にユーザーはシングルコントローラーのボトルネックや、高価なソフトウェアライセンス、ベンダーロックインという新たな問題に取り組み必要が出てきます。
今日、BGP-EVPNベースのコントロールプレーンを利用する事で、より多くのVXLANはコントローラーレスが出来るようになっています。

主にL3プロトコルはとても広大なスケールのネットワークをサポートし、そしてEVPN拡張の統合、BGP分散ネットワークのL2 MACとIPの到達情報、結果として自動的にVTEP Discovery、効率的なアドレス学習と最適化のルーティング/スイッチングが行われます。
分散されたAnycast　ゲートウェイはまたシングルコントローラのボトルネックを排除します。もっとも大事な事は BGP-EVPNコントロールプレーンが基準となりクラウドスケールと提供するという事です。

VXLAN-EVPNベースのDCIの利用できるソリューションとしてMellanox Spectrum スイッチで構築されたMellanox DCがあり
パフォーマンス、エンタープライズクラスの信頼性とクラウドスケールで際立っています。

SptectrumスイッチでのVTEPサポートにより、Mellanox DCIはハードウェアVXLANカプセル、脱カプセル化、対称、非対称のVXLANの100Gb/sでのルーティングを提供します。
他のソリューションと比べてもサーバー6大分と同等の750までのVTEPおよび、10万のVXLANトンネルとサポートし、Mellanox DCIは制限のないVXLANスケールを実現をするのです。

Mellanox　DCIは共通のVXLANコントローラーとしても使われます。

3つめの動向: 統合されたネットワークオーケストレーション

BGP-EVPN DCIはマルチクラウドをまたがる物理ネットワークインフラストラクチャの基盤からくるネットワークコントロールプレーンを
抽象化するので、私たちは　ネットワーク仮想化によるL2-L3の統合とクラウドソリューションのセキュリティ管理プレーンによるマルチクラウドの操作を簡素化しています。

NutanixとMellanoxは実際にPrism Centralを利用してアプリケーションの展開、Flowによるセキュリティの自動化、サービスチェインによるinsertion,Chainingが出来るようになりました。
Mellanox　ネットワークオケ―ストレーターとしてはNEO™️とPrism Centralがあります。

Mellanox NEOはネットワークのオーケストレーション、管理の為の素晴らしいソリューションです。
NEOはネットワークのコンフィグとリアルタイムのステータスを見れるようにし、データーセンターのネットワークの構成、監視、エンドツーエンドのEthernet のトラブルシュートを数クリックで行えるようにします。

RESTful APIベースであり、NEOはでのネットワークデザインのシンプル化、一つのクラウドの中のローカルネットワーク、マルチクラウド環境での操作性、トラブルシューティングの提供をする3rdパーティの管理ソフトウェアとシームレスに統合します。

Webhook APIsを通してNutanixとMellanoxはNEOとPrismを統合しました。この統合は自動化されたVLANマッピングとDiscovery、DCIでのVLAN/VXLANマッピングを可能とします。そして、ネットワークプロビジョニングをVM GRUDイベント(作成、移動、削除)に対して行います。
さらにVMレベルのネットワーク可視性があり、NEOはNutanix AHVのお客様が可視化とVMがどこで動いているのを知ることが出来きますし、仮想化と特定のアプリケーションが必要とするネットワークの管理と監視を行えるようになります。

例えば、アプリケーションがリモートサイト(DRなど）へフェイルオーバーが発生した際、NEOはPrism CentralからのAPIトリガを受け取ります。
それを基準ににNEOはリモートサイトに関連付けされているアプリケーションのバックアップとリカバリの為にDCIを構成します。
オーケストレーションは主に先の内容で説明しているEVPN DCIベースで、VXLANがプライマリーの場所からバックアップの場所へVLANをのまま伸ばしていきます。
Anycast gatewayはEPVN機能のシームレスなワークロードの移行を補助し、基本的にお客様の視点でネットワークを抽象化します。
お客様はこの全体のプロセスの間に如何なる中断もなくアプリケーションへアクセス継続は可能です。

Mellanox NEOは現在 NutanixのPrism Central + Calmの構成をして頂ければダウンロードと展開がワンクリックで実施できます。

最後に:マルチクラウドでのビジネス継続性を確かなものへ

マルチクラウド環境でのビジネス継続は必須条件です。アプリケーションが拡張や、DRの為に移動するので、ネットワークは
ビジネス継続で求められる課題の一つです。
NutanixとMellanoxのソリューションを採用頂ければ、NutanixとMellanoxの間で自動的にライフサイクル管理の一部としてネットワークのプロビジョニングを行い、ワークロードはDRサイトに移動してもIPを保持する事で一部また、完全なフェイルオーバーの間のビジネス継続を実現します。
これらの機能はネットワークを透過的にプライマリー、セカンダリーサイトに伸ばすことが出来るVXLAN/EPVNオーバーレイを利用して行われます。

VXLAN-EVPNはマルチクラウドをまたがるDCIを簡素化するオープンスタンダードな技術です。
EVPNベースのDCIはLayer2をデーターセンター間で拡張し、仮想マシンという形でのアプリケーションは簡単に同じIPとゲートウェイを持たまま移動する事が可能となり、これまでのDNSエントリーを手動で再構成する手間がなくなります。
アプリケーションのフェイルオーバー、DRがあると、EVPNベースのコントロールプレーンはVMの場所を自動的に更新しクライアントはVMが移動したことを知らなくてもアクセスは継続されます。

この素晴らしいオーケストレーションはMellanox ネットワークオーケストレーター NEOとNutanixのPrism Centralに統合されています。
透過的、ビジネス継続を確実にするためにNEOが提供する機能は次の通りです：

・VMレベルでのネットワークの可視化
・VM操作の為のVLAN/VXLANのプロビジョニング
・ワンクリックでのmLAG , RoCE構成
・監視の為のリアルタイムとトラフィック/パフォーマンスネットワークデータ履歴
・規模に応じたソフトウェアのアップグレードの変更
・Nutanix CALMからのNEOのワンクリック展開

もっと興味がある方はSweet Symphony for Multi-Cloud NetworkingのWebinerにご参加ください

Follow us on Twitter: @MellanoxTech, @nutanix. Also visit us for the solution demo at .NEXT London and upcoming Mellanox/Nutanix events in your area.

Related resources:

• Mellanox Spectrum switch product webpage
• Mellanox NEO product webpage
• Mellanox VXLAN-EVPN webpage
• Mellanox DCI POC webpage
• Solution Brief: Controllerless VXLAN with Mellanox Spectrum Ethernet Switches
• Solution Brief: Network Provisioning with Nutanix AHV and Mellanox
• Mellanox Blog: How to make advanced networks for Hybrid/Multi Cloud?
• Mellanox Blog: Is it Time to Upgrade to VXLAN?
• Mellanox Blog: VXLAN is finally simple, use EVPN and set up VXLAN in 3 steps
• Video: Mellanox Spectrum VXLAN differentiators
• Video: Automated VMs Operations with Mellanox
• Video: NEO & Prism Central demo for business continuity

2018 Nutanix, Inc. All rights reserved. Nutanix, the Enterprise Cloud Platform, the Nutanix logo and the other Nutanix products, features, and/or programs mentioned herein are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. All other brand and product names mentioned herein are for identification purposes only and are the property of their respective holder(s), and Nutanix may not be associated with, or sponsored or endorsed by such holder(s). This document is provided for informational purposes only and is presented ‘as is’ with no warranties of any kind, whether implied, statutory or otherwise.

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

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

多くの方がご存じで、認識していきているように従来のITインフラ基盤は時代遅れになっています。

ハイパーコンバージドインフラストラクチャが私たちが環境について考えている事を変えています。

そして、エンタープライズ事業者の方は次の動向を計画しています。

お客様はリスクとコスト（これは現在のレガシーなシステムで構成されているものを仮想化によるすばらしい機敏性を手に入れる事）を最小化したいと考えているのです。

これらの新しい優先順位により、IT部門の方はギアをシフトし日々負荷が高く稼働しているワークロードを予算内に収めるソリューションを探すことがプレッシャーとなっています。同感ですか？良いことにNutanixはお客様が求めているスケールを簡単に実現できるものなのです。

Nutanix のAHVはレガシーのソリューションからクラウドへ再注目しているお客様へ仮想化機能を提供、主導しマルチクラウド環境はビジネスのストレージサイロを排除し管理を分離することにより、ストレージスペース、ビジネス計画開発に必要なスタッフのリソースを節約する事が出来ます。

また、AHVではスナップショットを通したデータ保護と遠隔レプリケーションの機能がありますが、エンタープライズの高いスケーラビリティーがあっても、膨大なデーターリスクとIT部門の方が考慮しなければいけないオンラインでのダウタイムの可能性があります。

NutanixのAcropolisインフラストラクチャーはエンタープライズクラスで、エージェントが不要なデータ保護の為の冗長性が必要なのです。

NutanixはVeeam社とこの冗長性このギャップ（ここのギャップとはお客様が求めている事とITが提供できるもの）を埋めるために提携しました。

Hyper-Available HCIを包括したソリューションでお客様を安心させるものとなります。Nutanix エンタープライズのお客様は現在、IT管理者の方を夜中に起こす "データ保護" という頭痛から解放されています。

Veeam Availablity for Nutanix AHVはVeeamのPlatformの一部でNutanixユーザーの為に特別に設計されました。

これは簡単にWebベースのUIでの利用やPrismと同じような感覚で操作できるようにしているためです。

Veeam Availability for Nutanix AHVは実際にNutanixが作成するSnapshotと連携します。

2つのオプションによりお客様はNutanixAHVのSnapshotによる早いバックアップ、仮想マシンのバックアップや個別ファイル、アプリケーションアイテムの復旧といった事が出来るようになります。

Veeam Availability for Nutanix AHVは簡単操作で、慣れているデザインであるため安心して利用いただけるはずです。

アプリケーション第一の考えはこのソリューション開発における大部分を占めており、私たちが求めているエンタープライズクラスソリューションでの重要な利益を提供するものなので、インフラ全体でのデータロス、従来のインフラストラクチャに付随する管理コスト、やデータ保護の対応に関連するものです。

エンタプライズのお客様は現在HCIへの一歩を踏み出すだけでなく、Veeam Availability for Nutanix AHVによるデータ保護、投資を有効という機会があるのです。

VeeamはNutanix社とのパートナーとお客様へ全てのアプリケーションの保護の為のHyper-Availabilityをお客様へ提供できることをとても誇らしく思っています。

もっと多くの情報を知りたい方はwww.veeam.com.まで

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

この記事はレノボ・エンタープライズ・ソリューションズの小宮様に寄稿いただきました。

第3回目となります今回は、Lenovo社が提供する ThinkAgile HXのSAP HANA対応についてご紹介になります。

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

レノボ・エンタープライズ・ソリューションズ小宮です。本日はNutanix上でミッションクリティカルなワークロード環境を実現するThinkAgile HX for SAP HANAのソリューションについて取り上げてみたいと思います。

まずは、SAP HANAのNutanix対応をお話する前に、必要となるソリューションをお話したいと思います。

1. SAP HANAをNutanix環境で実現するにあたり必要なものとは？

SAP HANAはインメモリデータベースであり、その特徴はメモリ上にデータを保有しているためハードディスク上で動作するRDBMS製品と比較して、10~100,000倍の速度でデータを処理できます。そのデータベースが遅延なく動かすために、AHVのI/O高速化アーキテクチャであるAHV Turbo、25Gb以上の高速なネットワークかつRDMA（Remote Direct Memory Access）対応のNIC、高速なI/Oスループットを実現するNVMe/3D Xpointなどのデバイスが必要となります。

それに加えて、Nutanixプラットフォームを利用することにより従来型（3Tier）の構成に比べて最大31%のTCO削減が見込まれます。そのため、今後SAP HANAのインフラはNutanixで提案しましょうというお話になります。詳細の内容はこの後お話致します。

2. AHV Turboについて

AHV Turboをお話する前にNutanixのデータローカリティについて覚えておく必要があります。仮想マシンから書き込みがあったデータを別ノードの冗長性を保つためにデータをレプリケーションします。この一連の動作を高速化することがSAP HANAをNutanixで実現するために必要な要素になります。 

AHV Turboについてご説明致します。AHV TurboとはAHV環境におけるI/Oを高速化する技術になります。主な用途としてはアプリケーションの高速化に効果として望まれます。従来のNutanixのCVMは仮想マシンからのI/Oを一つのコアで処理をしていましたため、たくさん仮想マシンが動作している環境ではCVMがボトルネックになってパフォーマンスが出ないケースがありました。 

それをAOS5.5からCVMのCPUコアを分割してI/O処理できるようにすることで、並列処理が可能になりパフォーマンスを上げることができるようになりました。（上図でわかりやすく紹介）

しかしながら、本当にAHV Turboを導入したからと言ってI/Oが高速するのでしょうか？実はストレージデバイス側も並列処理に対応している必要があります。 

ストレージデバイスについてご説明致します。現状のハードディスクやSSDについてはSATAデバイス、SASデバイスで接続されています。こちらのデバイスの場合１つのコマンドキューしか対応していないため、いくらAHV Turboに対応してもデバイス側その効果を発揮できるものではありませんでした。そこで必要になるのはNVMeなどの高速ストレージデバイスになります。こちらのNVMeは64Kのコマンドキューをサポートしており、AHV Turboのような並列のI/O処理にも対応できるため、高IOPSを実現できる環境が整います。実際にNutanixでリリースされているNVMeモデルでは1仮想マシンあたり120万IOPSを実現しているものもあります。

そのため、AHV Turbo + NVMeは高スループット実現する環境になります。 

AHV Turbo環境で高スループット実現するにはNVMeなどのストレージデバイスだけで足らず、データローカリティ部分の高速化をするためにはネットワーク部分についても高速化が必要となります。実際にHCI環境のネットワークは10GbEで十分だという認識でいると思われます。それは従来型の利用方法では十分でしたが、今回のような64Kの並列処理を行うようなI/O環境ではネットワークの負荷も膨大なものになってきます。そのため、10Gbでは足らないケースも起こりますし、逆にデータ転送における遅延にもつながります。そのため、AHV Turbo + NVMeの環境では25GbEが必須になってきます。データローカリティでホスト内の処理を高速に処理できたとしても、データローカリティのシーケンスはデータの冗長化ができて初めてシーケンスが終了します。この理由から25GbE以上のネットワークが必要となります。 

実際にSAP HANAのようなインメモリデータベースの場合、ストレージ部分だけの高速化だけでは処理としてはまだ不十分です。ホスト間のデータ通信を早くするだけでなく、いち早くアプリケーションレイヤまでデータ通信させる必要があります。そこで必要な技術としてRDMA（Remote Direct Memory Access）になります。RDMAについてはHPC（High Performance Computing）などのスーパーコンピュータ関連で使われている技術でアプリケーションにデータ転送するためにCPUをオフロードして高速化を実現します。 

こちらのRDMAについては、最新のAOS 5.9から対応しています。(対応NICはMellanox社)

3. ThinkAgile HX Solution for SAP HANAについて

SAP HANAがなぜいきなりNutanix対応になった経緯についてご説明致します。

SAP社から2015年に「2025年からは次世代ERPはSAP HANAを前提としたプラットフォームにします」という発表がありました。そのため、ERPを導入している各社は現状の環境からSAP HANAの環境への移行を行う必要があります。

また、SAPなどのミッションクリティカルな環境は基本3Tier構成で組むことを前提としているため、ハードウェアのリプレース時のデータ移行やリソース不足による増設などでシステム停止などの運用で大きな負荷がかかっています。そのため、HCIなどの運用および拡張性に柔軟性のありプラットフォームやクラウド対応などもSAPのERP環境にも求められていることから、数年前からSAPおよびNutanixの両社でNutanixのS/4 HANA対応を行ってきました。 

SAP HANA対応について現状のハイパーコンバージドでの構成ではどうなるのか？ということについてご説明します。

SAPのERPなどはHANAのデータベースとそれ以外のアプリケーションで構成されます。HANA以外のアプリケーションについては今までの仮想化環境で十分対応できていました。しかしながら、SAP HANAに関してはSAPの認定するパフォーマンスについてNutanixのプラットフォームとして十分ではなかったからです。そのため、インメモリデータベースで動作するための環境作りがNutanix側で必要になってきており、今までは実現できていませんでした。それが、2018年8月末になり、NutanixのAHV環境（Enterprise Cloud OS）においてようやくHANAの認定が取ることができました。 

ThinkAgile HXのSAP HANA対応についてご説明します。

こちらはThinkAgile HX7820（アプライアンス）/HX7821（認定ノード）のラインナップでSAP HANA対応のスペックになっています。詳細は上図をご参照下さい。

実際に赤字になっているところがポイントです。

CPUについては、メモリ構成上で3CPU以上が必須な構成のため、今回のSAP HANAモデルはLenovo ThinkSystemの4CPUモデルで採用しています。（3TB構成は実際に利用可能なメモリ容量としては2.3TBになります）

次にNVMeと25GbE NICについては、先にご説明したAHV Turboの必要要件になっています。10GbEでの構成もサポートしていますが、10GbEのネットワーク構成としては最低でも4本以上が必要なります。

RDMAについては、ROC Capable NICsがそれに相当します。これが、AOS5.9の環境で動作することになります。

また、SAPでLenovoを選択するメリットもあります。

LenovoはグローバルでSAPのマーケットで（アプライアンスで）リーダーの地位にいます。また、パフォーマンスのベンチマークとしても世界記録を持っています。最後にAHVについては、LenovoはハードウェアベンダーでAHV対応が一番進んでいる（ネットワークの自動化、XClarity Integrator）ことから、このソリューションにおいては他のベンダーに比べて優位性があります。 

また、こちらのSAP HANA対応機種について、実はNutanixのNXシリーズではラインナップがございません。SAP HANAのNutanix対応については、是非Lenovoのプラットフォームをご選択頂けると幸いです。

今後ともよろしくお願い致します。

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

今回は小宮様に Lenovo 社の ThinkAgile HXのSAP HANA対応についてご紹介いただきました。Nutanix 上で、SAP HANA を動かすために必要なコンポーネントから、SAP HANA の Nutanix 対応に至る背景、SAP HANA 対応の Lenovo ThinkAgile HX のモデルについて解説いただいてきました。
小宮様には今後も定期的に寄稿いただく予定ですので、みなさまどうぞご期待ください！

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

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

今回は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」を表記します。

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

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

注意事項

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という製品を今回作成した環境にインストールしていきたいと思います。（すずきけ）

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

本記事の原文はもともと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ノードからなるクラスタにした際に動的に全てのノードを利用するようにパスが増えている事を示しています。

How many #Nutanix CVMs service a single bare metal workload when using Acropolis Block Services?#HCI #FightTheFUD pic.twitter.com/yLUrSIaRYG

— Josh Odgers (@josh_odgers) 2016年8月7日

結果的に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

本記事の原文はもともと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を作成し仮想マシンの構成をアップデートするだけです

現在の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でした 

#Nutanix delivering 1 million IOPS in a single VM at 8k block size and only 0.11ms latency puts to bed the In-kernel vs Controller VM debate.#VSAN #VMware #HCI pic.twitter.com/afkq1cC0e3

— Josh Odgers (@josh_odgers) 2017年11月9日

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

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

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

今回のテーマ

皆さん、こんにちは。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 管理ポータルにアクセスし、[リソースの作成]をクリックします。

検索窓でAutomationと入力します

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

［保存］をクリックします。

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

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

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

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

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

気になりますよね。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

［アラートルールの作成］をクリックします

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

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

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

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

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

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

App Storeはこちら

Google Playはこちら

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

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

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

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

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

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

まとめ

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

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

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

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

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

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

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

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

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

記事担当者：津久井