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

Nutanixはここ数年、MCSプラグインfor Citrix MCS、Nutanixの分散ファイルシステムがもたらす素晴らしいIO性能と簡単なストレージ管理、そして少ないネットワークIOによりAppとDesktop環境を変えてきました。

お客様はNutanixが最適にCitrix XenAppとXenDesktopを最適に実行できるという価値を認識しています。

NutanixとCitrixは共同でパフォーマンス、レイテンシのインパクトなしに数十万もの同時ユーザをサポートするスケーラビリティを実現するためのプラグイン[PVS Plug-in]を提供します。

Nutanix管理プレーンと,Citrix Provisioning Service , Desktopのコントロールプレーンの統合によりCitrixの管理コンソール内から1クリックで必要に応じて展開する事ができるのです。

これにより大規模拡張、容易なオペレーション、予測可能なパフォーマンス、より高い可用性をCitrix環境で実現しPay-as-you-growという利益を得られることになります。

PVS Plug-inの利用でお客様はXenApp、XenDesktop環境でのシングルインスタンスイメージ管理を実現できるのです！

もはやVDI全体を通してソフトウェアの展開に関して心配する必要はなくなり、

これからお客様はする事は、ただ一つでシングルイメージの更新と数千ものデスクトップの配信です。

新しいソフトウェアをマスターイメージにインストールしてもPVSクライアントを再起動するだけで新しいソフトウェアがインストールされた新しいイメージを利用する事ができるのです。

Nutanixは常にPVS Plug-inの提供という要望をコミットしてきました。

Nutanix AHV上でのCitrix PVSの自動化を実現するためにNutanixはPoSHを通して実現してきましたが、その方法には依然として問題がありました。

PVS Plug-inにより現在は1クリックで実行いただけるようになっています。

Nutanix Enterprise Cloud とCitrix XenApp , XenDesktopが一緒になる事で、デスクトップの仮想環境が完全にサポートされるようになります。

PVS Plug-inが統合されたスケールアウトアーキテクチャのNutanixはお客様のVDI環境を数千ではなく数十万というユーザへの拡大をPay-as-you-growの形で拡大する事が出来るのです。

ここ最近でNutanix上にCitrix XenApp , XenDesktopを稼働しているお客様が出てきており、Citrixの導入を加速するNutanixの重要性が増えていることを証明しているのです。

私たちはCitrixとのパートナーを継続して続け最新のイノベーションをお届けする

先駆者となります。

引き続きより深いPVS Plug-inや他の素晴らしい情報をお頼みしください。

6月29日　名古屋で次のWindows10 & Nutanix導入セミナーを開催しますので、ご興味があれば是非ご参加ください！

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

.NEXT 2018で発表のあったFlow + Netsil　ですが今後どのような形でリリースされるのか非常に楽しみです。

現在NetsilAOCは14日間のトライアルをお試しいただけますので入れてみました。

本ブログは今後組み込まれてくる本製品のコンポーネントと概念を理解し製品がリリースされた際に理解を早めるためのものとして理解いただければと思います。

【概要】

Netsil AOCとはCollectorと呼ばれるエージェントとAOSと呼ばれる製品が連携し

自動的にアプリケーションマップを作成、可視化する事が簡単にできる製品であり次の特徴があげられます。

• 監視-トラフィックを監視し全ての内部サービスや外部サービス間のアプリケーション間通信方法やプロトコルを見直し
• 検索と検知-コードを変更することなくサービスとその依存関係を広範囲に検索して発見
• 作成と共有-インフラストラクチャータグと通信の属性でホストをフィルタリングし、論理的にグループ化してマップを作成、それを共有
• 差分比較-新しい（アプリケーションや通信方式）デプロイの前後と過去の挙動を比較する差分比較機能
• 指標-レイテンシ、スループット、エラーなどのKPIは、すべてのAPI呼び出し、DBクエリ、DNSクエリなどのサービスとそのリンクで利用可能

【用語】

AOC ：APPLICATION OPERATIONS CENTER の事で各マシンはAOCに対してデータを送り、AOCの画面で実際にマップが確認できます。

【AOCの画面】

Collector：監視、トラフィック監視対象となるマシン（エージェントのインストールが必要）

CollectorからはHTTP,DNS,MySQLなどのメトリックをAOCへ送ります

AOCからはGoogleMapを彷彿させるアプリケーションの地図を自動で作成してくれます。

Collectorのアーキテクチャは次のようになっていますので、Kubernetes, DC/OSで連携させるといろいろと面白いかもしれません

【AOCはどこにあるのか？】

AOCは現在 Netsil Cloudにあり、評価版を依頼すると14日間の評価期間で様々な確認ができるようになります。

また、AOCは現在セルフホストという形で別のクラウドにもインストールが出来きます。

【2018年6月現在、Netsil AOC展開可能先のクラウド】

AWSでは東京もあるようです！

評価をするには？

評価版の申し込みはこちらから申し込みいただくと評価可能になります。

簡単なセットアップの流れはつぎのようになります。

評価版の申し込みが完了するとログインが可能となります。

ログインした後は対象のマシンへCollectorのセットアップを行うだけです。

インストール方法はAOCのドキュメントに記載されており、簡単にセットアップが出来ます。

今回はLinuxマシン3台にCollectorをインストールして可視化の確認をしてみました。

 Collectorのイントール

AOCのDocumentからcollectors installation をクリックします

次に対象を選択します

今回はRPM / RHELです

あとはクイックセットアップの行をコピー＆ペーストしておわりです

実際に実行するコマンド

簡単ですよね？？

 さてMapを選択してみると・・・・・

【あれ？マップが表示されない？】

本来はこの設定で/etc/init.d/netsil-collectorsが起動していれば

マップが自動作成されると思っていたのですが・・なぜか表示されません。

 なぜならドキュメントに次の用に記載があるからです。

まりNetsil Cloud を利用する場合は利用ポートに443を利用する必要があるとあります。

One More Advice

CollectorをインストールしたLinuxマシンで次のおまじないをして、Netsil Collectorを再起動してあげてください。

実行するコマンドは次の通りです

なんということでしょう

ちゃんと地図が作成されているではありませんか！？

現在正式にGAしているNutanix のマイセグとこのNetsil L7アプリケーションベースの監視機能がどのような形でリリースされるのか非常に期待が膨らみますね

全てはOne Click で Simple そしてメーカーサポートを一貫して受けれらるという事も大きな魅力ではないでしょうか？

本製品は期間が短いですので評価をさせる際は計画的にしましょう！

6月29日　名古屋で次のWindows10 & Nutanix導入セミナーを開催しますので、ご興味があれば是非ご参加ください！

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

前回はTrend Micro Cloud App Security(以下、TMCAS) の評価導入の

ステップをお伝えしました。

前回記事はこちら↓
Office365 と Trend Micro Cloud App Security でより安全なクラウドへ
(前編)

後編となる今回は、TMCASの管理機能の解説と、実際にウィルス検知時に

どのような動作となるか、ご紹介したいと思います。

TMCASの検索方法としては、システムが自動で検索処理を行う「リアル

タイム検索」と管理者が都度実行する「手動検索」方法があります。
　
※無料評価版の制限として「リアルタイム検索」が利用不可となっています。

そのため検知時の処理に関しては「手動検索」による結果を記載しています。

TMCASの基本的な管理はWebコンソールを利用します。

ログインすると最初に以下のようなダッシュボードが表示されます。

ダッシュボードでは、全体の利用状況のグラフ表示などで確認できます。

検知数などのリンクをクリックすると検知ログの一覧などに遷移します。

ダッシュボードをはじめ管理コンソールは以下のパーツで構成されています。

・高度な脅威対策

・情報漏えい対策

・ログ

・隔離

・運用管理

上記パーツのうち、セキュリティ運用のルール(ポリシー)を設定する箇所が

「高度な脅威対策」と「情報漏洩対策」です。

TMCASではOffice 365 のサービス毎(Exchange、SharePoint、OneDrive

に上記２つのポリシーを定義して利用する事になります。

TMCASのテナントを開設した時点でそれぞれ既定のポリシーが構成されて

います。

「高度な脅威対策」は、ウィルス対策、Web および ファイルレピュテー

ションに関するポリシーを定義します。

「情報漏洩対策」は、データ損失保護(DLP)に関わる部分で、マイナンバー

などの個人情報や機密情報の流出保護に関するポリシーを定義します。

1つのサービスにつき複数のポリシーを作成する事が出来ますのでユーザー

グループ単位で異なるポリシーを割り当てることが可能です。

今回は一例として、Exchange Online に対して「高度な脅威対策ポリシー」

を紹介したいと思います。

「一般」ではリアルタイム検索の有効/無効、ポリシーの優先度および、

対象のユーザー/グループを指定します。

「高度なスパムメール対策」では、スパムメール対策の有効/無効を設定し、

検索範囲および検知レベルのルール設定と、検知後の処理、通知の有無を

指定します。　　　

「不正プログラム検索」では、不正プログラムの検索範囲や機械学習を

用いた検索の有効/無効のルール設定と、検知後の処理、通知を指定します。

「ファイルブロック」では、特定の拡張子をもつファイルをブロックする

ルール設定を指定します。

「Webレピュテーション」では、不審URLに対する検索範囲や検知レベルを

指定します。

「仮想アナライザ」では、TMCASのサンドボックス処理による振る舞い

検知に関するルールを指定します。

上記は例として Exchange Online の「高度な脅威対策」ポリシーを見て

きましたが、TMCASによって実際に検知/処理がどのような挙動となるか

試したいと思います。

検知に利用するのはテスト用ウィルスとしてお馴染みの「eicar」を使用

して、、と言いたいところですが、今回は趣向を変えて Office 365の

機能を利用して不審URLを含んだメールによる挙動を試してみたいと

思います。

今回利用するOffice 365の機能は「Office 365 攻撃シミュレーター

(Attack Simulator)」を利用します。

ご存知の方もいらっしゃると思いますが、Office 365 攻撃シミュ

レーターは、Office 365 E5プランで提供されており、管理者は

以下に挙げる3つの攻撃シミュレーションを試す事が出来るように

なっています。

・スピアフィッシング攻撃
・ブルートフォース辞書攻撃
・パスワードスプレー攻撃

ちなみにこの 攻撃シミュレーター ですが、実行可能なユーザーの前提条件

としてOffice 365の多要素認証(MFA)を有効化する必要があります。

ですので、TMCASから少し脱線しますが Office 365 のMFAおよび攻撃

シミュレーターの手順についても簡単に触れたいと思います。

※既にMFAを利用されている方は、この説明はスキップして下さい。

まず、Office 365管理者ポータルに管理者アカウントでアクセスします。

ユーザー＞アクティブなユーザー画面に移動し、ユーザーを選択し

「Azure Mult Fac..」をクリックします。

多要素認証を有効化するユーザーを選択し、画面右側の「有効」をクリック

します。

続いて、「multi facter authを有効にする」をクリックします。

処理が正常終了した旨のメッセージを確認し、「閉じる」をクリックします。

その後、別のブラウザを立ち上げ、有効化したユーザーでOffice 365ポータル

にアクセスし、いつものようにID、PWを入力します。

すると追加の認証を求める画面が表示されますので、「今すぐセットアップ

する」をクリックします。

追加のセキュリティ画面で連絡方法を選択します。

MFAのパターンとしては、電話への認証コードの送信あるいは通話に応答

するパターンと、「Microsoft Authenticator(以下、Authenticator)」

という専用のモバイルアプリを利用するパターンがあります。

今回はAuthenticator を利用したいので「モバイルアプリ」を選択して

進めます。

続いてどのような方法で多要素認証を行うかを問われますので、今回は

「確認コードを使用する」を選択し「セットアップ」をクリックします。

すると画面上にQRコードの表示がされますので、このQRコードを

Authenticator アプリで読み取る必要があります。

Apple Store または Google Play 経由で「Microsoft Authenticator」を

インストールします。(今回、アプリのインストールは割愛します)

インストールしたAuthenticatorを起動後、画面右上の「＋」をクリック

します。

「職場および会社のアカウント(Work or school account)」をクリック

します。

スキャンを求められますので、画面に表示されているQRコードを読み取る

とアカウント情報が追加されます。

これでモバイルアプリ側の設定が完了です。

次回以降、Office 365ログイン時に、ID/PWを入力すると、Authenticator

に表示される6桁の確認コードを都度入力する動作となります。

これでAttack Simulatorを利用する準備が出来ましたので、スピアフィッ

シング攻撃のシミュレーションを実行したいと思います。

攻撃シミュレーターの詳細は以下も併せてご確認下さい。

攻撃 Simulator (Office 365)
https://support.office.com/ja-jp/article/%E6%94%BB%E6%92%83-Simulator-Office-365-da5845db-c578-4a41-b2cb-5a09689a551b?wt.mc_id=O365_Portal_MMaven

まず、Office 365管理ポータルにアクセスし、「管理センター」＞「セキュ

リティ」を選択します。

「脅威の管理」＞「攻撃シミュレーター」をクリックします。

スピアフィッシングの「攻撃の開始」をクリックします。

「Use Template」クリックします。

するとテスト用に「プレゼントの当選」「給与計算の更新」といった2つの

テンプレートが選択出来ますので、今回は「経費精算」を利用したいと

思います。

続いて、攻撃対象となるターゲットユーザーを指定して「次へ」をクリック

します。

実際に通知される差出人や件名、不審URLなどを指定して「次へ」をクリック

します。

必要に応じてメール文面等も加筆修正し、「次へ」をクリックします。

最後に「完了」をクリックします。

ここまでの手順でフィッシングメールがユーザーに通知された事になります。

それではTMCASによる処理の状態を見てみたいと思いますが、冒頭にも

お伝えしたように今回は無料評価版を利用した内容となりますので

手動検索のみが利用可能となっています。

そのため、今回はTMCAS管理コンソールから「手動検索」を実施し、

フィッシングメールがどのように処理されるかを確認したいと思います。

TMCAS管理コンソールにアクセス、「高度な脅威対策」に移動します。

「初期設定のExchange ポリシー - 高度な脅威対策」の左端にあるチェック

を付け「手動検索」をクリックします。

検索内容を確認し、ここでは既定のままで[実行]をクリックします。

OWAからメールボックスにアクセスしてみると、フィッシングメールは

すでに削除されており、またTMCASが削除処理を実行した旨のシステム

メッセージが表示されています。

今度は、TMCASの管理コンソールから検知ログの状態を確認してみま

しょう。

すると、 ログにもWebレピュテーションによってメールメッセージが削除

処理されたログが確認出来ました。

今回は評価版という事もあり、手動検索で検知・処理される様子を紹介し

ましたが製品版であればメール受信後すぐにリアルタイム検索で検知される

動作となります。

このようにTMCASは、Office365 のセキュリティ と組み合わせて様々な

脅威に対して対処可能である事がお分かり頂けたと思います。

2回にわたってTMCASの解説をしてきましたが如何でしたでしょうか。

是非、TMCASでより安全に快適な Office 365 環境を実現頂ければと

思います。

今回も最後まで読んで頂きありがとうございました！

記事投稿者：津久井

本記事はNutanix社のオフィシャルブログの翻訳版です。原文を参照したい方は

Nutanix Introduces Application Mobility from Public to Private Cloudsご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

Xtract For VMs機能はちょうど7カ月前にリリースしたものでした。

それはNutanixをご利用しているお客様へ簡単に既存のワークロードをオンプレミス上のNutanixへ移行するために提供してきました。

簡単に素早く移行を完了させることは既存のワークロードにかける時間を減らし、お客様は時間を有効活用できるようなります。

この結果、何百もの多くのお客様がXtractを採用しLinuxやMicrosoft Windowsといった12,000VMsもの仮想マシンの移行がされています。

本日、XtraxtのアプリケーションモビリティがパブリッククラウドからVMをマイグレーションする機能を将来リリースする事を発表いたします。

What VM migrations are being announced?

今度のXtractのバージョンと共にNutanixはVM移行のソースとしてAWSのPublicクラウドからNutanixへの移行する機能を追加します。

Why introduce VM migrations from AWS?

オンプレミスで構築するか、パブリッククラウドを利用するか・・皆さんが悩む所ですよね

たとえもし、パブリッククラウドを利用する方が簡単で安かったとしても、パブリッククラウドの最初の戦略ではビジネスプライオリティが変更になった際の時間、コストの消費、そして仮想マシンが他のパブリッククラウドやオンプレミスの環境に移行する事が必要になった際に証明されるのです。

パブリッククラウドへ移行した組織の例としてはFacebookやDropboxといった組織を含めてですが、難しい事ではありませんが、組織の規模にかかわらず同様の課題があります。

最近では大手パブリッククラウドの停止や遅延といった問題は組織のセキュリティやコンプライアンスに懸念をもたらすことになります。

Nutanixはハイブリッドクラウドの複雑さをシンプルにするための管理という自由を組織は様々なベンダーロックインやコストの追加無しに手に入れるべきと考えています。

How are migrations managed?

Xtract for VMsはオンプレミスで使われているESXiからAHVへの移行に加えて、VM移行のソースとしてAWSを追加しました。

ご利用方法はこれまで皆様が行っていた方法と同じ手順で実行する事ができます。

AWSとの接続は非常に簡単で適切な名前、AWSのアクセスキーIDとシークレットアクセスキーのみです

登録したAWSのアカウントで接続するとVMとリージョンが表示されます。

マイグレーション計画の作成方法は同じ少ないステップで他のオンプレミスのNutanix環境へ移行する事が出来るのです。

ソースとターゲットのネットワークマップもこれまでのオンプレミスと同じように設定する事ができ数クリックでマイグレーションプランを完了し実行する事が出来るのです。

一度マイグレーションを実行すると初期データ送信が始まります。あとはデータサイズ、接続スピードに依存するので、必要な時間待つだけです。

この間ソースとなる仮想マシンは稼働し続けるので停止は必要ありません。

一度　全ての移行対象の仮想マシン同期が完了すると、Xtractはカットオーバーするまで差分データを定期的に送信します。

カットオーバーするプロセスを制御する事は企業が最も最適なタイミングでカットオーバーを行い、仮想マシンの停止を最小限にすることが出来るXtractの重要な機能機能です。

Nutanixのテストではt2.microインスタンスの移行に20分足らずで終了しカットオーバーにはたった1分で行えました。

Can I migrate all workloads?

パブリッククラウド移行の最も難しい面の一はクラウドネイティブサービスに形成される依存関係です。

Nutanixはこの新しいPublic Cloudマイグレーション機能をXtract製品チームのアーリアクセスリリースの準備として発表します。そのため、数社のお客様の積極的な参加を求めています。

もしお客様でAWSパブリッククラウド環境を利用しており、本プログラムの参加に30-60分ほどの調査、議論を持たせていただけるのであれxtractfromaws@nutanix.comへご連絡ください

Learn more about Nutanix Xtract at www.nutanix.com/xtract, and join in with the community discussion here.

Disclaimer: 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.

Forward-Looking Disclaimer: This blog includes forward-looking statements, including but not limited to statements concerning our plans and expectations relating to product features and technology that are under development or in process and capabilities of such product features and technology and our plans to introduce product features in future releases. These forward-looking statements are not historical facts, and instead are based on our current expectations, estimates, opinions and beliefs. The accuracy of such forward-looking statements depends upon future events, and involves risks, uncertainties and other factors beyond our control that may cause these statements to be inaccurate and cause our actual results, performance or achievements to differ materially and adversely from those anticipated or implied by such statements, including, among others: failure to develop, or unexpected difficulties or delays in developing, new product features or technology on a timely or cost-effective basis; delays in or lack of customer or market acceptance of our new product features or technology; and other risks detailed in our Form 10-Q for the fiscal quarter ended January 31, 2018, filed with the Securities and Exchange Commission. These forward-looking statements speak only as of the date of this presentation and, except as required by law, we assume no obligation to update forward-looking statements to reflect actual results or subsequent events or circumstances.

© 2018 Nutanix, Inc. All rights reserved. Nutanix and the Nutanix logo are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. All other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s).

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

今回はSharePoint Online 移行ツール(Migration Tool)をご紹介したい

と思います。

SharePoint 移行ツールの導入
https://docs.microsoft.com/ja-jp/sharepointmigration/introducing-
the-sharepoint-migration-tool

このツールを利用する事でオンプレミスのSharePoint サイトのリストや

ドキュメントライブラリのアイテムを含め簡単なステップでOffice 365

SharePoint Online に移行出来ます。

現在のところ、移行元として選択できるのはSharePoint Server 2013
のみとなります。

(最初この前提を見逃して、SharePoint 2010と2016 のサーバーを用意

してしまうという初歩的な過ちをおかしてました(笑))

今回の投稿は「試しにやってみた」といったライトな感じで簡単な手順を

ご紹介していきたいと思います。

今回も Azure を利用して、ADサーバー1台と、SharePoint Server 2013

のサーバー1台の環境を作成しました。

チームサイトを作成し、サイトコンテンツとして「お知らせリスト」と
「ドキュメントライブラリ」を作成し、適当なアイテムを作成しておきます。

見分けがつきやすいようにトップページのログやレイアウト変更など若干

手を加えました。

移行元の準備が整いましたので、SharePoint Online 移行ツールのサイトに

アクセスします。

https://docs.microsoft.com/ja-jp/sharepointmigration/introducing-
the-sharepoint-migration-tool

画面上部に「SharePoint 移行ツール バージョン 2」というリンクをクリックします。

以下の画面に遷移しますので、同意にチェックをし、「インストール」を

クリックします。

もう1度「インストール」をクリックします。

「サインイン」をクリックします。

Office365管理者の資格情報を入力します。

移行元の選択。オンプレミスのSharePoint、ファイル共有、JSON/CSVを

使用した一括移行の3パターンが選択可能です。

今回は「SharePoint on-premise」を選択します。 

移行元SharePoint サイトのURLを入力します。

移行元SharePoint サイトの管理者権限をもつ資格情報を入力します。

移行対象データを選択し、「Next」をクリックします。

移行先となる SharePoint Online サイトのURLを入力します。

移行元と移行先サイトが正しいことを確認します。

ここで「Migrate」をクリックすると移行処理が開始されます。

ちなみに赤枠で囲った歯車のアイコンをクリックすると、移行処理の

オプション設定を確認する事が出来ます。

各オプションの詳細は、下記サイトの情報をご確認下さい。

https://docs.microsoft.com/ja-jp/sharepointmigration/how-to-use-the-sharepoint-migration-tool#advanced-settings

今回はオプション設定は変更せず既定値のまま、移行処理を進めます。

移行処理が完了しました。

「Open Report」をクリックしてみます。

移行処理に関する各種ログを確認する事が出来ます。

それでは移行先のSharePoint Online サイトがどのように変化しているか

アクセスしてみましょう。

移行元のリストやライブラリのアイテムは正常に移行出来ている事が確認

出来ましたが、トップページに配置したWebパーツのレイアウト復元は

行われず、タイトル名のみが置き換えられる結果となりました。

今回は簡易的に試した結果ですので、ウィザード中のオプション設定を

変更する事でまた違った結果が得られるかもしれません。

未確認の機能がまだありそうですが、ご覧頂いたように簡単なステップで

オンプレミスから SharePoint Online への移行を試して頂けますので

是非皆さんも試して頂ければと思います。

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

記事投稿者：津久井

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

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

原文を参照したい方は Identifying & Resolving Excessive CPU Overcommitment (vCPU:pCore ratios) をご確認ください。

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

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

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

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

HELP! 私の環境のパフォーマンスがひどいのですが、コンサルやベンダーはキツいCPUオーバーコミットが原因だと言っています。どうしたら良いのでしょうか？

質問:どれくらいまでCPUのオーバーコミットはいけるんですか？

その答えはもちろん「場合によります！」であり、どのような仮想マシンを動作させるか、物理CPUは何を搭載しているかということだけではなく、他の仮想マシンがどのように動作しているかなど複雑な要素が絡み合います。

その他のよくある質問:
いま、どれだけのオーバーコミットをしているのですか？
そして
オーバーコミットがパフォーマンスの問題を引き起こしている原因であるかはどうすれば分かりますか？
さあ、それでは「いま、どれだけのオーバーコミットをしているのですか？」から触れていきましょう。
Nutanixを使うと非常に簡単にその作業ができます。
まず、PRISMのハードウェアというメニューからダイアグラムをクリックし、次に示すようにノードの１つを選択します。

そうすると、SummaryセクションにCPUのモデルやコア数、ソケット数が表示されます。

この場合、１ソケットあたり合計10個の物理コアが存在するため、2つのソケットと20個のコアがあることがお分かりいただけます。
クラスターに複数のノードの種類が存在する場合、クラスター内の異なる種類ごとにこの手順を繰り返してください。
次にクラスター内の物理コアの総数を単純に合計します。
このケースでは3つのノードがあり、それぞれ20個のコアがあり、合計60個の物理コアがあることになります。
次に、クラスター内に割り当てたvCPUの数を調べましょう。これはPRISMの仮想マシンのページで以下に示すように見つけることができます。

つまり、60ノードの物理コア(pCore)を持つ3ノードのクラスターがあり、130個のvCPUを割り当てていることが分かります。
ということで、vSphere Cluster Sizing Calculatorに確認した内容を入力し、希望する可用性レベル(この場合はN+1)を考慮したオーバーコミットの状況を識別することができます。

このカリキュレーターはコンサバティブに設計されており、構成された可用性レベルに必要なリソース(CPU/RAM)が計算から除外されている前提で情報を表示します。言い換えれば、vCPU:pCoreの比率はN+1の余裕を考慮したホストがクラスターの中に存在しないものと想定しています。
カリキュレーターはvCPU:pCoreの比率が3.25:1であることを示します。

SQLやExchange、OracleやSAPなどのビジネス上で重要なアプリケーションの場合、CPUのオーバーコミットを行わず(つまり1:1)にサイジングを行い、仮想マシンのパフォーマンスが低下しないようにすることを推奨します。
オーバーコミットの比率が分かったら次に何をすればよいでしょうか？
オーバーコミットの状況がもともと想定していた設計と一致しているかを確認し、現在の状態で仮想マシンがどのように動いているかを評価する必要があります。
素晴らしい設計はアプリケーション要件、CPUのオーバーコミット、仮想マシンの配置状況やDRSのルールといったパフォーマンスの要因を考慮するべきでしょう。

それでは、オーバーコミットがパフォーマンスの問題の原因となっているかはどのようにして確認すればよいのでしょうか？

仮想マシンがCPUスケジューリング競合を起こしているかどうかを判断するいちばんよい方法はAHVで”CPU準備時間”または”Stolen Time”を確認することです。

“CPU準備時間”は基本的に仮想マシンがCPUコアにスケジューリングされることを要求してから実際にスケジューリングされるまでの遅延です。

これを示すいちばん簡単な方法のひとつは、仮想マシンがスケジュールされることを待っている合計時間の割合を求めることです。

How much CPU Ready is OK?

私が得た経験則は次のとおりです。

2.5%未満のCPU準備時間

一般的に問題ありません。

2.5%-5% CPU準備時間

ピーク時に監視する必要がある最小限の競合です。

5%-10% CPU準備時間

調査するべき重要な競合です。

10%より大きいCPU準備時間

早急に調査し、対処が必要な重大な競合です！

とは言え、"CPU準備時間"の影響はアプリケーションによって異なりますので、特にビジネスクリティカルなアプリケーションでは1%の競合も見落とすことのないように注意しましょう。

"CPU準備時間"は重要な性能基準であるため、Nutanixはこれを仮想マシンごとにPRISMに表示することにしました。これによりお客様はCPUスケジューリングの競合状況を簡単に識別することができます。

以下では、仮想マシンを強調表示した後、PRISMで仮想マシンのページに表示されるパフォーマンスの概要を示しており、ページの下部に”CPU準備時間”を示すグラフが表示されます。

2.5%のCPU準備時間は大多数の仮想マシンにとっては大きな問題を引き起こすことはないと思われますが、例えばデータベースや動画/音声などのレイテンシに敏感なアプリケーションでは、その2.5%という数字が大きな問題を引き起こす可能性があります。

私は仮想マシンに注目することをお勧めします。

そして、CPU準備時間が1%を超える程度だとしても、それがビジネスクリティカルなアプリケーションである場合、CPU準備時間が0.5%以下になるまでこの記事のトラブルシューティング手順に従い、性能差を評価してみてください。

Key Point: SQL ServerのAlwaysOnのような可用性グループ、Oracle RAC、Exchane DAGなどのアプリケーションの場合、CPU準備時間が発生している仮想マシンは他の仮想マシンが通信(またはレプリケーション)をしようとするフローに影響を与える可能性があります。

そのため、他の要因を調査する前に、仮想マシンやアプリケーションの依存性が”CPU準備時間”によって悪影響が起きていないことを確認してください。

端的に言えば、CPU準備時間が発生していないサーバーAは、サーバーBとの通信を試みているときにサーバーBのCPU率が高いことによって遅延が発生する可能性がある、ということです。

私がこのような話を持ち出す理由は「パフォーマンスの問題を調査するときは視野を狭めないことが重要」だと言えるからです。

さあ、ここからがおもしろいところで、CPU準備時間のトラブルシューティングと解決法です！

1. 仮想マシンの正しいサイジング

このステップを無視しないようにしてください！CPUオーバーコミット率は関係ありません。正しいサイジングはいつも仮想マシンの効率とパフォーマンスを向上させます。
より多くのvCPUをスケジューリングしようとするとハイパーバイザーレイヤーのオーバヘッドが増加しますので、オーバーコミットをさせないとしても仮想マシンはオーバーサイジングしないようにしましょう。よくある誤解として、90%のCPU使用率はボトルネックであることが挙げられますが、実際にはこれは正しいサイジングをした仮想マシンの兆候であると言えます。vCPUがピーク時のサイジングとなっていることが前提となりますが、仮想マシンが100%の使用率で長時間固定されている場合を除いて、100%となるCPUスパイクは必ずしも問題になるとはいえません。
次に仮想マシンの正しいサイジングによるメリットの例を示します。 (VM Right Sizing – An example of the benefits)
仮想マシンを正しくサイジングしたら、ステップ2へ進みましょう

2. NUMAを考慮してサイジングする

まず、NUMAとは何でしょうか？これは非常にシンプルで、コア数をソケット数で割ったものです。
これがNUMAであり、最高のメモリパフォーマンスと最適なCPUスケジューリングの恩恵を受けたい場合に仮想マシンが持てる最大のvCPU数でもあります。
ホストの合計RAMもまた、RAMの合計数をソケットの数で割ります。
これが仮想マシンに対して割り当てることができる最大のメモリ搭載量であり、これにそぐわない場合は約30%程度のパフォーマンスペナルティが発生します。
例:12コアを搭載したNutanixノード上で、12vCPU/96GBの仮想マシンでExchangeを動作させているお客様がいました。
(最終的にはマイクロソフト社の製品不具合でしたが)Exchangeがうまく動作しておらず、CPUの性能不足が問題であると主張しました。
そのため、お客様は仮想マシンに対し、18個のvCPUを増やすことにしました。
残念ながらこれはパフォーマンス問題を解決させることができませんでした。
そして、実際にはNUMAよりも大きな仮想マシンが他のワークロードを実行しているホスト上でその仮想マシンの”CPU準備時間”による影響を与えてしまったため、他のホストへもパフォーマンスに対する悪影響を及ぼしてしまいました。
結局12vCPUに戻して"CPU準備時間"を解放し、最終的にはマイクロソフト社のパッチでこの問題を解決しました。

3. 最重要仮想マシンを実行しているホストから他の仮想マシンを移行する

これはCPUスケジューリングの競合を緩和するための大変簡単なステップであり、CPUオーバーコミットをさせないことによるパフォーマンス上のメリットを確認することができます。仮想マシンのパフォーマンスが向上したとすると、パフォーマンスの問題の原因の少なくともひとつ見つけられた可能性があります。これはより難しい内容です。ひとつの仮想マシンごとにホストを用意する余裕がない限り、ホストを移行するためのコンプリメンタリーワークロードを特定する必要があります。コンプリメンタリーワークロードってなに？よくぞ聞いてくれました！例をご紹介しましょう。
正しくサイジングされた10vCPU/128GBのSQL Server用の仮想マシンがあり、そのホストは１ソケットあたり10コア(合計20コア)の2つのソケットと256GBのRAMを搭載したNX-8035-G4です。SQLであることから、ビジネスクリティカルなアプリケーションのバックエンドですので、IO要件は高いものと想定されます。
Nutanixであることから、さらにリソース(例えば8vCPUと32GBのメモリ)を使用してCVMも保持していることとなります。興味のある方は” Cost vs Reward for the Nutanix Controller VM (CVM)”をご覧ください。コンプリメンタリーワークロードには次に挙げるひとつ以上の特性があります:

コンプリメンタリーワークロードってなに？
よくぞ聞いてくれました！例をご紹介しましょう。
正しくサイジングされた10vCPU/128GBのSQL Server用の仮想マシンがあり、そのホストは１ソケットあたり10コア(合計20コア)の2つのソケットと256GBのRAMを搭載したNX-8035-G4です。

SQLであることから、ビジネスクリティカルなアプリケーションのバックエンドですので、IO要件は高いものと想定されます。
さらにNutanixであることから、追加でリソースを使用してCVMも保持していることとなります。(例えば8vCPUと32GBのメモリ)
興味のある方は "Cost vs Reward for the Nutanix Controller VM (CVM)” をご覧ください。
コンプリメンタリーワークロードには次に挙げるひとつ以上の特性があります:

A) 96GB未満のメモリ(ホストの搭載RAM256GB、SQL Server用の仮想マシン128GB、CVM32GBのとき、96GBの残容量)
B) vCPUが2以下 (これは1:1のvCPU:pCoreという比率を意味する)
C) vCPUの要件および使用率が低い
D) IO要件が低い
E) ディスク容量の要件が低い(これはデータローカリティを利用した最大のRead性能を考慮し、ノードのローカルに保持されるSQL Serverのデータ量を確保する)
F) SQLのワークロードとは異なる時刻にCPUやストレージを使用するワークロード

例:SQLは午前８時から午後6時までビジー状態になる可能性がありますが、その時間外は負荷が大幅に低下すると考えられます。
午後７時から深夜まで実行されるCPU/ストレージIO要件が高い仮想マシンは、オーバーコミットを可能にし、重複しない仮想マシンの動作時間に起因するパフォーマンスの影響を最小限に抑えるため、隙間をぬった負荷になると言えます。

4. より多くの物理コアを持つノードに仮想マシンを移行させる

これは当たり前かもしれませんが、より多くの物理コアを持つノードではCPUスケジューリングの柔軟性が増し、CPU準備時間を削減することができます。
仮想マシン上でvCPUを増やさなくても、仮想マシンは物理コア上で処理をするための時間を得る可能性が高く、それによりパフォーマンスが向上します。
 

5. 仮想マシンをよりCPUクロックの高いノードに移行させる

これもまた当たり前な内容のひとつですが、ベンダーやお客様が要件としてvCPUの数を引き合いに出すことはとても一般的です。
オーバーコミットのない最高のvCPUは１つの物理的なコアに相当します。物理コアはクロックが異なることがありますが、
高クロックなCPUは特に厄介とされるシングルスレッドアプリケーションのパフォーマンスに大きな影響を与えます。
注: クロックの高いCPUはコア数が少ないことが多いため、NUMAを超えるような仮想マシンの配置をしないようにしましょう。

6. 物理サーバーで高度な電源管理をオフにし、ポリシーとして”High Performance”を使用する (ESXiの場合)

高度な電源管理の設定は電力を節約し、場合によってはパフォーマンスへの影響を最小限に抑えることもできますが、パフォーマンス上の問題、
特にビジネスクリティカルなアプリケーションのトラブルシューティングには高度な電源管理を無効化することでパフォーマンスの問題が解決することもあります。

7. ハイパースレッディング(HT)を有効にする

ハイパースレッディングはCPUスケジューリングのメリットを提供し、多くの場合はパフォーマンスを向上させ、
CPUベンチマークでも10～30%程度の性能アップを実現させます。
長い話を簡単に言えば、Ready状態の仮想マシンは何もしていないので、ハイパースレッディングを有効にしてあげると、何もしないよりもより良いということです。
また、ハイパーバイザーは非常に賢く、優先的にvCPUをpCoreにスケジューリングするため、ビジー状態の仮想マシンはpCore上に存在せず、vCPUの要求の低い仮想マシンはハイパースレッディングにスケジューリングできます。Win-Winですね。
注:マイクロソフト社のExchangeのように一部のベンダーはハイパースレッディングをオフにすることを推奨しています。
しかしながら、この推奨事項は実際には物理サーバー上で動作するExchangeのみに適用されます。
仮想環境ではハイパースレッディング対応のワークロードとExchangeのようなvCPUとpCoreの比率を1:1に設定したようなワークロードを共存させることで、一貫した高性能を実現させます。

(マイクロソフト社のような)ハイパースレッディングを無効にするように主張しているベンダーと戦っているひとのための、ハイパースレッディングに関するアーキテクチャー状の考慮事項があります。

Example Architectural Decision – Hyperthreading with Business Critical Applications (Exchange 2013)

8. クラスターにノードを追加する

最適化されたワークロードを持つノードに適切なサイジングを施した仮想マシンがあり、最適なNUMA構成を保証し、
ビジネスクリティカルなアプリケーションを動作させている仮想マシンが最高のクロックのCPUで稼働していることを確認していながらも
パフォーマンスの問題が残っている場合は、１つまたは複数のノードをクラスターに追加します。
追加ノードはより多くのCPUコアを提供し、ひいてはより多くのCPUスケジューリングの機会を作ります。

私がよくされる質問は「重要な仮想マシンでCPU予約を使って、CPUを100%保証するのはなぜですか？」というものです。

言い換えれば、CPU予約を使用してもCPU準備時間の問題を解決することはできず、この内容について記事も書きました : Common Mistake – Using CPU reservations to solve CPU Ready

ワイルドカード: ストレージノードを追加する
待って、どういうこと？なぜストレージノードを追加するとCPUの競合が減るのでしょうか？
これは非常に簡単で、Read/WriteのIOレイテンシが低くなるため、CPUがIOを完了することを「待っている」時間であるCPU WAITが少なくなるためです。
例えば、I/OがNutanixでは1ms、従来のSANでは5ms必要な場合、仮想マシンをNutanixに移動させると仮想マシンのCPU待機時間が4ms少なくなります。これは仮想マシンが割り当てられたvCPUをより効率的に使用できることを意味します。
追加の容量が必要ない場合でも、ストレージノードを追加するとクラスター内の平均I/Oレイテンシが向上し、仮想マシンを物理コアにスケジューリングし、作業を完了させて、別の仮想マシンにpCoreを解放したり、その他の処理を実行したりします。
注: ストレージノードとデータの分散スループットの方法はNutanixの独自機能です。仮想マシン/アプリに変更を必要としないストレージノードでパフォーマンスがどのように改善されるかについては、次の記事を参照してください。

Scale out performance testing with Nutanix Storage Only Nodes

要約:
ストレージノードによるストレージの強化など"CPU準備時間"の問題に対処するためにできることはたくさんあります。
 

"CPU準備時間"に関するその他の記事

1. VM Right Sizing – An Example of the benefits

2. How Much CPU Ready is OK?

3. Common Mistake – Using CPU Reservations to solve CPU Ready

4. High CPU Ready with Low CPU Utilization

あとがき

量が多くて大変だなという記事でしたが、書いてあることは非常に重要なものです。

この記事では、仮想マシンのパフォーマンスはvCPUの数を増やせば向上するというものではなく、Nutanixのノードが搭載している物理コアの数やメモリの量、そして負荷の性質などを考慮した上で仮想マシンのリソースや配置を検討する必要があるという内容を示唆しています。

訳を作成する中で、個人的に興味深いフレーズもありました。

原文にある "It depends."というものです。

私は「場合によります！」という訳にしましたが、今年Citrix Synergyに参加したときにいろいろなアーキテクトと会話をし、サイジングの話ではだいたい "It depends."という言葉を耳にしています。

私自身もセミナーなどでサイジングの内容に触れるときは「お客様の使い方や条件、環境に依存します」という前提条件を付けます。

当然のことながら、ワールドワイドでもサイジングについては「絶対にこれだ！」という正解はないんだということを改めて実感しています。

記事担当者 : SI技術本部 海野航 (うんのわたる) @Nutanix_NTNX

今回はExchange Online のハイブリッド簡易移行についてご紹介したいと

思います。

オンプレミスのExchange Server 2010/2013/2016から Exchange

Onlineへメールデータを移行する手段としてハイブリッド移行という

移行方法が用意されています。

「ハイブリッド移行」は要件に応じて大きく以下の2つのパターンに

分かれています。

・完全ハイブリッド
・最低限のハイブリッド

さらに「最低限のハイブリッド」のオプションとして「簡易移行

(Express Migration)」という手法も用意されています。

簡易移行を端的に説明すると、「移行時に一度だけAD同期を実行する」

パターンとなります。アカウント管理の違いで区分けすると以下のような

分類となります。

この最もシンプルな「簡易移行(Express Migratioin)」の手順をご紹介

していきたいと思います。

今回の環境ですが、Azure上にADサーバー一台とExchange Server 2010

SP3 Rollup 19のコンバインドロール(HUB/CAS/Mailboxの役割を1台に

まとめた)のサーバー1台を用意しました。

こちらがオンプレミスのExchange 2010 環境を再現した構成となります。

Exchange2010とした理由ですが、延長サポートフェーズが2020年で

切れるという事もあり、Exchange 2010 からの移行をお考えの方も

多くいらっしゃるのではないか、という事で今回はExchange 2010の

環境を準備しました。

また、今回のシステム構成でご注意頂きたいのですが、Azure 仮想マシン

としてサポートされるExchange のバージョンは2013以降であり、かつ

Azure Premium Storage での利用が推奨となります。

Microsoft Azure 仮想マシンのマイクロソフト サーバー ソフトウェアの

サポート
https://support.microsoft.com/ja-jp/help/2721672/microsoft-
server-software-support-for-microsoft-azure-virtual-machines

Exchange 2013 仮想化
https://technet.microsoft.com/ja-jp/library/jj619301(v=exchg.150).aspx

Exchange 2016 仮想化
https://technet.microsoft.com/ja-jp/library/jj619301(v=exchg.160).aspx

今回はあくまで一時的な検証目的ですので、本番環境での利用は控えて頂きます

ようお願いします。

尚、本記事では移行先となる Office365 テナント開設済みで独自ドメイン

の登録が完了している前提で、ハイブリッド構成ウィザードの手順を中心

にご紹介していきます。

早速見ていきたいと思いますが、一連の操作はオンプレミスのExchange

2010 サーバーから実行しています。

まず最初に Office365 管理ポータルにアクセスします。

セットアップ＞データ移行に移動し、「Exchange」 をクリックします。

ハイブリッド構成ウィザードのインストールを求められますので、

「インストール」をクリックします

「次へ(Next)」をクリックします。

オンプレミスのExchange Server 環境が自動検出されます。

検出が完了したら、そのまま「次へ(Next)」をクリックします。

「サインイン(sign in)」をクリックします

認証ダイアログが表示されますので、管理者IDとPW入力します。

「次へ(next)」をクリックします

オンプレミスとOffice365環境の情報収集が開始されます。

処理が成功したら「次へ(next)」をクリックします。

ハイブリッド機能の選択です。

今回は「最低限のハイブリッド構成(Minimal Hybrid Configuration)」を

選択します。

画面の一番下には「Organization Configuration Translator」という

チェックボックスがオプション設定として追加されています。

これは先日、下記ブログでもアナウンスされていますが、新たに追加された

機能で、このオプションを有効にする事によりハイブリッド構成時にオン

プレミスのExchange 組織の下記情報を移行します。

Hybrid Organization Configuration Transfer
https://blogs.technet.microsoft.com/exchange/2018/06/18/hybrid-organization-configuration-transfer/

・アイテム保持ポリシー(Retention Policy)

・保持タグ(Retention Policy Tags)

・OWAメールボックスポリシー(OWA Mailbox Policy)

・モバイルデバイスメールボックスポリシー

   (Mobile Device Mailbox Policy)

・Exchange ActiveSync メールボックスポリシー
   (Active Sync Mailbox Policy)

今回は、Exchange 2010側で事前にサンプル値を仕込んでおきましたので

そちらの結果も後ほど確認してみたいと思います。

引き続きウィザードを進めていきたいと思います。

「更新(update)」をクリックします。

続いて、Azure Active Directory Connect のインストールが求められ

ます。

「一度だけユーザーとパスワードを同期する(Synchronize my users and

password one time)」を選択し、「次へ(next)」をクリックします。

AAD Connet のセットアップ画面が表示されますので、同意にチェックし、

「構成(Configure)」をクリックします。

「簡易設定を使用する(Use express setting)」をクリックします。

Office365管理者のID、PWを入力し、「次へ(Next)」をクリックします。

再度認証ダイアログでPW入力し「サインイン(Sign in)」をクリックします。

続いて、オンプレミスADの管理者ID、PWを入力して「次へ(Next)」を

クリックします。

ドメイン構成を確認します。Office365側で未登録のドメインが

「追加されていない(Not Added)」となっている場合は、

「ドメイン検証なしで続行する(Continue without any verified domains)」にチェックを付け、「次へ(Next)」をクリックします。

最後に「Exchange hybrid deployment」にチェックし、

「インストール(install)」をクリックします。

構成が完了したことを確認し「次へ(Next)」をクリックします。

「Azure Active Directory Connect は正常に完了しました」が選択されて

いることを確認し、「次へ(Next)」をクリックします。

ハイブリッド構成完了のメッセージが表示されますので「次へ(Next)」を

クリックします。

ハイブリッド構成後のステップとして、メールボックス移行の処理を

行います。「閉じる(Close)」をクリックします。

Office365管理ポータルへのサインイン画面が表示されますので

管理者アカウントでサインインします。

サインインするとすぐに「データ移行」メニューに遷移します。

先程のハイブリッド構成ウィザードの手順でID同期が実行されましたので

既存のユーザー一覧が表示されます。

こちらの画面にも表示されていますが、メールボックスを移行するには

対象のユーザーに対してOffice365のライセンスを事前に割り当てる

必要があります。

ライセンスを付与するには、ユーザー＞アクティブなユーザーに移動し、

ユーザー一覧からライセンスを割り当てたいユーザーを選択します。

今回は2名のユーザーを指定し、「製品ライセンスの編集」をクリックします。

「既存の製品ライセンスの割り当てに追加」を選択し「次へ」をクリックします。

「場所」を選択し、割り当てたいライセンスを指定して「追加」を

クリックします。

「閉じる」をクリックします。

データ移行のメニューに戻り、「Exchange」をクリックします。

ライセンスエラーの表示が解消されていますので、移行したいユーザーに

チェックを付け「移行の開始」をクリックします。　

バックグラウンドで移行処理が開始されます。

「移行が正常に完了しました」のメッセージが表示されると完了です。

最後は、移行ステップの途中で触れたようにメールボックス以外の

OWAポリシー等の Exchange 組織の構成が移行出来ているか

確認したいと思います。

サンプルとして作成したOWAポリシー「OWAMP01-TEST」が移行されて

いる事が確認出来ます。

アイテム保持ポリシー「RP01-TEST」、保持タグ「RPTAG01-TEST」も

問題なく移行されています。

Exchange ActiveSync ポリシー(ASMP01-TEST)は、「モバイルデバイス

メールボックスポリシー」に移行されています。

今回はオンプレミスのExchange 2010 から Exchange Online への

ハイブリッド簡易移行の手順をご紹介しましたが、如何でしたでしょうか。

簡易移行に必要な前提を満たしていれば、ウィザードに従って進めるだけで

メールボックスを移行して頂く事が可能です。

今回は触れていませんが、メール移行における前提や注意すべき点などを

確認したいという方には、Office365で提供されている「メール移行アド

バイザー」というツールをご利用頂ければと思います。

既にOffice365を試験的にお使いの方であれば、Office365管理ポータルから

簡単に利用できるツールです。

移行時に必要となる作業や考慮すべき点を細かくチェックしながら移行作業を

進める事が可能となっています。

メール移行アドバイザーでは、Exchangeだけでなく、IMAPやGmailなど

様々な環境に対する移行手順を提示してくれますので、こちらも是非活用

下さい。

メール移行アドバイザーはOffice365環境への移行をサポートするツール

でしたが、移行先がクラウドではなく、オンプレミスで新しい

バージョンのExchange Server を構築、移行を検討されている方は

以下の「Exchange Server 展開アシスタント」をご利用下さい。

Microsoft Exchange Server 展開アシスタント
https://technet.microsoft.com/ja-jp/office/dn756393.aspx

展開アシスタントは、メール移行アドバイザーと同様にウィザードに

従って対話形式の質問に答える事でExchange Serverを展開する様々な

シナリオにおける確認事項や注意点を提示してくれるツールです。

既存でExchange Server 2010以降をご利用のお客様は是非こちらの

展開アシスタントを活用して、移行計画にお役立てください。

今回も最後までお読み下さり有難うございました。

記事投稿者：津久井

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

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

原文を参照したい方はNutanix Resiliency – Part 1 – Node failure rebuild performanceをご確認ください。

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

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

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

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

2013年の中旬からNutanixでビジネスクリティカルアプリケーション、スケーラビリティ、回復力とパフォーマンスに注目しながら働いてきています。

私はよくお客様やパートナーの方とNutanix製品の回復力に関する事やNutanix Platformでどのように構成するのが一番良い方法か会話しています。

Nutanix Platformの数多くある強みの一つで私が多くの時間と努力を費やしてきた領域は回復力とデータの完全性、そして重要なのは障害シナリオとどのようにNutanixが障害時に動作するのかを理解する事です。

Nutanixは独自の分散ストレージファブリック(ADSF)で仮想マシン、コンテナのストレージの提供をします。そのRF2 または3で構成されている物理サーバでもあります。

単純な視点からRF2とN+1(例えばRAID5)RF3 とN+2 (例えばRAID6)を比較する事が出来ますが、RF2と3は分散ストレージファブリックの障害からの素早く再構築が出来き、障害発生の前に検知し解決するディスクスクラブにより回復力が従来のRAIDよりも非常に高いのです。

Nutanixはデータの完全性を確実にするための継続的なバックグラウンドでのスクラブの実施だけでなく、すべてのリード、ライトへチェックサムの実施をしています。

RF2が使われいるとしてもADSFの回復力の話をするときの重要な要素はRF2または3に準拠した形でドライブ、ノードフェイルに対する復旧のスピードです

リビルドはすべてのノード、ドライブをまたいだ完全な分散処理になるので、素早く、各ノードのボトルネックを最小減に抑え、稼働しているワークロードのインパクトを少なくすることが出来るのです。

どうして早いか？　当然、CPU世代、とネットワーク接続性、同様にクラスタのサイズ、どのようなドライブが搭載されているか(NVMe , SATA-SSD , DAS-sATA)に依存します。サンプルはこうです。

テスト環境が16クラスタ　殆どが五年前のハードウェアのNX-6050 , NX-3050の混在構成でCPUはIvy Bridge 2560( 2013年Q3のもの)、各ドライブは6本のSATA-SSDを搭載し2x10GBのネットワーク接続とします

最初のテストではデータ削減技術（重複排除や圧縮またはいれージャーコーディング）を利用しないデータを利用しますが、データ削減がパフォーマンスを向上しデータ削減によりデータの再構築にかける時間を短縮できるので、このテストの結果はベストなケースシナリオではありません。

次に示す通りノードは5TBちょっとのデータがあり、測定するのは5TBのノード障害シナリオに対するリビルドの速度となります。

クラスタの半分のノードは約9TBの容量で他の半分は1.4TB ～ 3TBの容量となります。

ノード障害はIPMIの”Power off server  - immediate” にて実施します。

この操作は電源を引き抜く操作に相当します。

Acropolis Distributed Storage Fabric (ADSF)の回復力の良いところはノード障害中の各ノードの統計情報を見ると明らかにわかります。1GBpsのスループットがシングルノードで達成しクラスタのすべてのノードが容量に応じてほぼ同じスループットが出ているのがわかります。

半分のノードのスループットが低いのは容量が少なく、結果リビルドするデータが少ないからです。

もしすべてのノードが同じだったとしたらスループットは概ね最初の4つのリストにあ

RAIDに組まれているドライブが大きくなればなるほど、リビルドにかかる時間が多くなり、その間の障害発生に対しるデータロスのリスクが高くなります。

RAIDのリビルド中に発生するパフォーマンスの影響もドライブ一台の障害と一台のリビルド先しかないことかにより高くなります。

これは長いウィンドウのパフォーマンスインパクトとデータが保護されていない事を意味します。

るノード（1GBpsでているもの）と同じになるでしょう。

Nutanixが分散ストレージファブリックを使っていなければ、リビルドはリビルド元、RAID、または一般的なHCIのリビルド先のノードによって制約が発生するでしょう。

例えば、全てのノードが小さいエクステント(1MB)を多対多、効率的にクラスタ内で複製する事に反して、Node-Aは大きいオブジェクトをNode-Bへ複製するでしょう

これまでのRAID5を比較すると、リビルド元になるのは障害が発生した特定のドライブのみとなります。RAIDのドライブは3～24で構成されリビルド用に一つのスペアディスクを設定します。つまりリビルド操作は一つのディスクによるボトルネックがあります。

ほとんどすべてのITプロフェッショナルの方々はRAID5、たとえRAID6であったとしても　数時間から数日の長期間にわたるシングルドライブ障害の復旧にかかるRAID構成に対して“ゾッ”とする話をもっています。

これらの一般的な嫌な経験はN+1(そしてRF2)でさえ悪評となった大きな理由です。

RAID5 , 6のリビルドが数分以内で完了できたとしたら・・

大多数の次に発生する障害がダウンタイムやデータロスをもたらす結果にはならないでしょう。

ではNutanix ADSFのリビルドパフォーマンスにもどりましょう。

繰り返しですがADSFはレプリカ（データ）を1MBのサイズでクラスタ内に分散します。（すべてのデータが2つだけのノードに存在するペアスタイルではありません）

この分散がリビルド中の書込みのパフォーマンスを向上し、結果的に多くのコントローラー、CPU、ネットワーク幅をリビルドのために利用します。

簡単に言うと、クラスタが大きくなればなるほど、ノードはレプリカのRead, Writeが増えていき復旧にかかる時間が早くなります。

クラスタのサイズが大きいほど障害とリビルドに対するインパクトが下がり、大きなクラスタではRF2の構成でさえ素晴らしい回復力を提供できるのです。

下の画像はNutanixのPrismから取得した分析のスクリーンショットです。

ノード障害を想定してからのリビルド期間中のストレージプールのスループットを表示しています。

このチャートではリビルドが20:26にそして終了したのは20:46で完了までの間 9GBpsを維持している事がわかります。

この例では5年前のノードで5TBの利用率でデータの完全なリストアに20分以下となるのです。

クラスタサイズが増えるか　新しいノードが速いNICやNVMeドライブのようなストレージを使われているのであれば、リビルドはもっと早くなりRF2を利用していてもデータロスの可能性はとても少なくなるのです。

NutanixではCVMでデータ保護をしているのでノードが増えても処理できるマシンが増えリビルドにかかる時間は減りますし、早いCPU等を搭載したモデルでもリビルドにかかる時間が削減されます。

イメージ的にはRAIDコントローラ処理速度もOne-Clickで！といったところですね！

Summary:

• Nutanix RF2 is vastly more resilient than RAID5 (or N+1) style architectures
• ADSF performs continual disk scrubbing to detect and resolve underlying issues before they can cause data integrity issues
• Rebuilds from drive or node failures are an efficient distributed operation using all drives and nodes in a cluster
• A recovery from a >5TB node failure (in this case, the equivalent of 6 concurrent SSD failures) can be less than 20mins

Next let’s discuss how to convert from RF2 to RF3 and how fast this compliance task can complete.

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

こんにちは、ネットワールドの海野です。

今日のCitrix PowerShellはこちら。

Set-BrokerSite -DnsResolutionEnabled $true

【どんなときに使うの？】

XenApp/XenDesktopは、StoreFrontで生成されたICAファイルに記載されているIPアドレスを基に、
Citrix Receiver(お手元のデバイス)からVirtual Delivery Agent(公開された仮想アプリ/仮想デスクトップ)へ接続します。

NATを利用しているネットワーク環境の場合、Citrix Receiverが解釈できないIPアドレスがICAファイルに記載されている状況になってしまう可能性があります。

それでは期待通りにXenApp/XenDesktopへ接続することができません。

そのときに役に立つのがこのPowerShellです。

このPowerShellを適用するとICAファイル内のIPアドレスの項目がDNSで解決可能な名前に置き換えられるようになります。

Citrix ReceiverがVDAの名前をDNSで解決できることが前提となりますが、これによりNATされている環境でもVDAに接続することができます。

【こんなひとにオススメ！】

• XenApp 6.5以前の環境でWeb Interfaceの機能である[変換]や[代替]を使っていて、XenApp 7.xへの移行を検討しているひと
  (有効でないケースもあります)
• やむを得ずXenApp環境をマルチNICにしている状態で、ICAファイルのIPアドレスが期待するNIC側で生成されず、うまく接続できないひと

【どのバージョンで使えるの？】

ネットワールドのCitrixチームではXenApp/XenDesktop 7.6 LTSR および 7.15 LTSRで動作確認をしております。

大正義Citrixのオフィシャルナレッジベースも併せてご確認ください！

How to Enable DNS Address Resolution in XenDesktop

記事担当者 : SI技術本部 海野 航 (うんの わたる)

本記事の原文はCitrixのアーキテクトである Daniel Feller氏 (@djfeller) によるものです。

原文を参照したい方はWindows Server 2016 Optimizations for Citrix XenAppをご確認ください。

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

「OSの最適化」についてお話しますと、私は「2つの側面」があると考えています。

最適化はサーバー単体のスケーラビリティを向上させますが、OSを複雑に設定するほどOSを破損させてしまう可能性が高くなると思います。

デフォルトアプリケーション

Windows 10にはユーザーのログオン時間を増加させる既定のアプリケーションが多数ありますが、
Windows Server 2016にはこのような追加機能はありません。

サービス

Windows 10で無効にしたサービスの多くは、Windows Server 2016では既に手動として構成されています。
もう少し深いところに目を向けますと、これらのサービスの多くはアプリケーションによる要求に基づいて開始されるか、スケジュールされたタスクに基づいて起動されます。
サービスの起動が無効になっている場合、サービスとの連携が必要なアプリケーションまたはシステムコンポーネントは起動に失敗します。
このサービス起動の無効化設定によってアプリケーション/システムの問題が引き起こされ、サポートを呼び出したうえで長時間のトラブルシューティングを行わなければならない、という結果となってしまいます。
これらに基づき、無効にするべき唯一のサービスは次のとおりです。

注:マイクロソフトは無効化にすることができるサービスと無効化するべきではないサービスの一覧を公開しています。無効化することができるサービスのほとんどは手動起動モードに設定されています。

スケジュールされたタスク

スケジュールされたタスクは、トリガーが条件を満たしたときだけ実行されますので、集約度に対する影響は部分的です。
無効にする対象を決定するときは、非永続な環境でタスクによる影響を調べる必要があります。
この前提はXenApp Best Practice #3:Consistencyに基づきます。

スケジュールされたタスク - アプリケーション

スケジュールされたタスク - Microsoft Customer Experience Program

スケジュールされたタスク - 安全性

スケジュールされたタスク - メンテナンス

スケジュールされたタスク - 一般的なもの

ユーザーインタフェース

ユーザーインターフェイスの最適化の多くはWindows 2000 Server以降で使用されています。
これにはユーザーからサーバーの管理ツールを隠すための設定と、ユーザーインターフェイスの機能を無効化することにより全体的な集約率を高める設定があります。

システム

最終的な最適化はシステムレベルの設定にフォーカスしており、お客様の組織はシステムの価値を最大限に引き出すことができます。

システム - BIOS

システム - コマンド

システム - レジストリの更新

記事担当者 : SI技術本部 海野 航 (うんの わたる)

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

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

原文を参照したい方はNutanix Resiliency – Part 2 – Converting from RF2 to RF3をご確認ください。

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

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

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

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

パート1ではAcropolis Distributed Storage Fabric (ADSF)のおかげで効率よく素早くノード障害からリビルドを行えるというNutanixAOSの能力について話しました。

パート2ではストレージコンテナがどのようにしてRF2からRF3に変換できるか、そして完了までにかかる速度をお見せしたいと思います。

このテストでは12台のノードでクラスタを作成しています。

ストレージプールの使用率を確認しながら始めましょう

現在50TB以上のストレージがクラスタ内で利用されています。

RF3へするには単純にすべてのデータに3つ目の複製を追加するかです。

当然それを実施するだけの十分な容量を持っておく必要があります。

次にRedundancy Factor（FTレベル）をRF3に増やします。

これによりRF3のコンテナがサポートできるようになり、少なくても2ノードの障害でも稼働できるようになります。

次にストレージコンテナをRF３にします。

一度コンテナがRF3にセットしてまえば、CuratorがクラスタのRedundancy factorに従いバックグラウンド処理で追加の複製を作成します。

この例では凡そ50TBのデータがストレージプールにあるので、この処理では50%の複製が実施されることになるので75TBのデータ量になる事となります。

3時間以内のプロセスでは7GBps以上のスループットが出ていることが確認でき、1h/約8.3TBとなります。

クラスタが完全にRF2レベル冗長性を維持しながら、このRF3への変換プロセスの間に新しいデータが書き込みがされた場合、そのデータはRF3として作成され、保護されるという事が大切です。

下のチャートはストレージプール利用率がリニアに増えていくことを示しています。

クラスタサイズが大きくなれば、この処理にかかる時間は早くなるという事が大事なことで、ADSFが本当の分散ストレージファブリックであり、ノードが増えれば増えるほどコントローラが多くの書き込みを処理できるです。

素晴らしいノード追加の例はScale out performance testing with Nutanix Storage Only Nodesをご覧ください(英語サイト)

処理が完了するとストレージプールは予想していた75TB程度になっています。

NutanixADSFがどの程度このドライブに対して処理をさせているか興味を持っている方の為に、実行中のいくつかのステータスを取得しました。

解ることは物理ディスクが単一のキャッシュドライブでインテリジェントでないHCI環境のように容量のオフロードされているのではなく、最大限にリードライトをすべてのドライブにまたがって利用しているという事です。

Summary:

• Nutanix ADSF can change between Redundancy levels (RF2 and RF3) on the fly
• A compliance operation creating >25TB of data can complete in less than 3 hours (even on 5 year old equipment)
• The compliance operation performed in a linear manner throughout the task.
• A single Nutanix Controller VM (CVM) is efficient enough to drive 6 x physical SSDs at close to their maximum ability
• ADSF reads and writes to all drives and does not use a less efficient cache and capacity style architecture.

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

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

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

原文を参照したい方はNutanix Resiliency – Part 3 – Node failure rebuild performance with RF3をご確認ください。

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

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

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

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

パート1ではAcropolis Distributed Storage Fabric (ADSF)のおかげで効率よく素早くノード障害からリビルドを行えるというNutanixAOSの能力について話し、一方パート2ではストレージコンテナがRF2からRF3へ変換し回復性能、どれくらい完了までに早くその処理が終わるかを議論しました。

パート2では12ノードクラスタで各ノードのディスクの利用率はこのようになっています。

障害をシュミレートするノードは5TBのディスクの使用率でこれはパート１で実施したノード障害のテストと近い状態です。

クラスタは現在12ノードのみで構成されているので、パート1と比べてリード・ライトを行うコントローラーが少ないことが解ります。

次にIPMI経由で”Power Off -Immediate”でノード障害をシュミレートします。

次が示すのは30分後に5TBのデータの再保護が完了する際のノードのリビルドのストレージプールのスループットです。

まず、すぐに解るのは5TBのデータの再保護までに約30分かかるとことです。

5年前のハードウェアとすれば、他のSANやHCI製品と比べても上出来でしょう。

しかしもっと早くてもよいのではと感じたので調べてみました。

ノード試験当時クラスタがアンバランスな状態になっていることが解り、結果的にノードはまったく、または殆どデータを持たないため正常時のように全てのノードがリビルド処理を行っていなかったのです。

クラスタがアンバランス状態になったのは私が頻繁にノード障害のシュミレートを試しており正常にするためにノード追加の後にバランス処理が完了するのを待てないでノード障害のシュミレートを行ったのです。

通常メーカーは最適でない結果を投稿しませんが、私は透明性が重要と強く感じています。クラスタがアンバランスになる可能性があり、もしその様な状況でノード障害が発生した際にどの様な回復性能に影響があるかを知ることが大事です。

そこで、クラスタがバランスの状態である事を確認してテストを再度実施した結果が次の通りです。

ここで解るのは5GBpsだったアンバランスと比べて6GBps以上のスループットが出ており、

1GBpsものパフォーマンス向上が凡そ12分間にわたって続いていたのです。

またアンバランスの状態で確認できたスループットの劣化は発生していません。

これはすべてのノードが均等にデータを持つことでリビルドの期間、全てのノードがリビルドを実施する事が出来たおかげなのです。

Summary:

• Nutanix RF3 is vastly more resilient than RAID6 (or N+2) style architectures
• ADSF performs continual disk scrubbing to detect and resolve underlying issues before they can cause data integrity issues
• Rebuilds from drive or node failures are an efficient distributed operation using all drives and nodes in a cluster
• A recovery from a >4.5TB node failure (in this case, the equivalent of 6 concurrent SSD failures) around 12mins
• Unbalanced clusters still perform rebuilds in a distributed manner and can recover from failures in a short period of time
• Clusters running in a normal balanced configuration can recover from failures even faster thanks to the distributed storage fabric built in disk balancing, intelligent replica placement and even distribution of data.

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

こんにちは、ネットワールドの海野です。

今日はVMware PowerCLIについて記事を書きました。

PowerCLIを使うと、WindowsのPowerShellによってVMware製品の環境を操作することができます。

ネットワールドのプライベートイベントであるNetworld .next 2017にてご紹介した「HEY! GARAGE」も、この仕組みの上で動作しています。

ということで、早速インストールの方法です。

最新のPowerCLIのインストールはとってもカンタンです。

なお、ここでは説明の簡単化のために、既存でPowerCLIはインストールされていないクリーンな環境を前提とします。

互換性リストなどの詳細はこちらをご確認ください。

さて、実際の手順ですが、インターネットに接続している Windows 10 または Windows Server 2016 で、スタートメニューから[PowerShell (管理者)]を起動します。

PowerShellの中で以下のコマンドを実行します。

Install-Module VMware.PowerCLI

インストールを確定、実行するために"A"を選択します。

これでPowerCLIのインストールは完了です。

かつてのバージョンのPowerCLIはモジュールをダウンロードしてexeファイルからインストールをするタイプだったのですが、

現在は上記のようなPowerShellのリポジトリからインストールするような仕組みになっています。

慣れないとちょっと不安だと思いますが、2018年7月20日時点の最新バージョンである10.1.1はPowerShell Galleryからのみインストール可能ですので、勇気を出してがんばりましょう！

より詳細を知りたい方はオフィシャルのドキュメントも併せてご覧いただければと思います。

今日は準備までですが、どのようにPowerCLIを使って仮想マシンを制御するのかをご紹介していきます。

記事担当者 : SI技術本部 海野 航 (うんの わたる)

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

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

原文を参照したい方はNutanix Resiliency – Part 4 – Converting RF3 to Erasure Coding (EC-X)をご確認ください。

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

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

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

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

このシリーズでクラスタはRF2からRF3に変換されている状態です。

いま、お客様は回復性能の影響なしに容量効率を良くしたいと思うとすると

イレージャーコーディングの有効化のプロセスとスピードを見る必要があります。

Nutanixのイレージャーコーディング(EC-X)はRFの構成が完了していて至上な状態のコールドデータに対してのみ実施されます。そしてEC-Xはポストプロセスで実行するため、クラスタに対するインラインの書き込みには影響が無いようになっています。

Nutanix EC-Xについてもっと知りたいかたは Nutanix – Erasure Coding (EC-X) Deep Dive.を参照ください

どんなI/OがNutanixのEC-Xに有効なのですか？　いい質問！です

書込みのコールドデータのみです。

EC-XはデータがコールドデータになったらNutanixADSF キューレーターが低優先のタスクとしてバックグラウンド処理でEC-Xを実施します。

どのくらい RF2/3 からEC-Xにするのは早いのですか？

簡潔にいうと全パートで示したように基盤のなるディスクは高速処理が可能ですが、EC-Xは容量削減を目的とした技術で、データにリスクが無いため、ドライブ障害やノード障害の様にスピードは必要ないので、“ErasureCode:Encode”タスクのプライオリティが下に示すように3となります。

ノード・ディスク障害はプライオリティは「１」となります。

もしお客様がこの処理をどんな方法を使ってもそれがキュレータをメンテナンスにしソフトリミットを削除して多くの処理を実施させることになったとしても、出来るだけ早く実施したい場合はサポート対応となりますので、ここでは方法を共有しません。

次にスループットとEC-X後のストレージプールの状態です。

途中で一部スループットが落ちているのは、バックグラウンドのキューレータースキャンを通してEC-Xを部分的に有効にしたたため、結果データのいくつかが変換されたものです、その後手動で他のフルスキャンを実施し、高いスループット（> 5GBps）を実現し完了しました。

次に示すのは理論的に最大値の2:1に近い、1.97:1の容量の最適化の結果です。

EC-Xがこのように最大値に近い結果にたどり着いたのはアクティブなワークロードがクラスタ内になるく、テストデータがすべてコールドとなりEC-Xがストライプ出来たからです。

だから37.7TB近いデータセットのリードと再書き込みを１８TB近く使われているEC-Xへ行い、結果は18.54TBのデータ削減につながることになりました。

単純計算で37.7TBのデータがADSFで読み込まれ、18TBのEC-XストライプデータがADSFによる全体の56TBのIOサービスのため、90分以内で書かれたのです。

Summary:

• Nutanix EC-X has no additional write penalty compared to RF3 ensuring optimal write performance while providing up to 2x capacity efficiency at the same resiliency level.
• ADSF uses it’s distributed storage fabric to efficiently stripe data
• Background EC-X striping is a low priority task to minimise the impact on front end virtual machine IO
• ADSF can sustain very high throughput during EC-X (background) operations
• Using RF3 and EC-X ensures maximum resiliency and capacity efficiency resulting in up to 66% usable capacity of RAW storage (up to 2:1 efficiency over RF3)

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

今回はOffice365の２つの機能、Forms & Flowを使ってお手軽アンケートを作成
する手順をお伝えしたいと思います。

Office365を既にご利用頂いてる方はご存知かと思いますが、簡単にForms と Flow
についてご紹介したいと思います。

●Microsoft Formsについて
アンケートや質問表といった様々な入力フォームを作成する事が出来るツールとなり
ます。

これまでは、Webのアンケートフォームなどを作成する場合、SharePointで実現する
パターンが多かったと思いますが、フォーム作成に特化する事でより身近に利用頂ける
ようになっています。

Formsによって簡単にアンケートフォームを作成でき、アンケートの回答を利用して
Excelに集計する事も出来るようになっています。

私のチームでもアンケートだけでなく、各種レポートであったりチームのモチベー
ションを測る意識調査に活用させてもらっています。

●Microsoft Flowについて
Flowは、業務ワークフローや定型的なタスクを自動化する事に役立つツールです。

Flowでは非常に多くの処理が出来るようになっており、多彩な実行条件やアクション
などを定義する事が出来ます。

最近では、RPA（Robotic Process Automation）という単純作業を自動化する
ソリューションが増えていますが、Flowはお手軽RPAといえる機能かもしれませんね。

●今回のゴール
今回は上記2つの機能を組みあわせて

「アンケートフォーム＆回答者への自動メール返信」を作っていきます。

仕組みとしては、Formsでアンケートフォームを作成し、Flowを利用してアンケート
回答者ならびにアンケート管理者グループの双方にアンケート回答の受信確認をメール
で通知するという動作となります。

ちなみにForms単体でもアンケートの回答をメールで通知する機能を備えていますが、
補助的な機能のため、通知先のアドレスが指定出来なかったり、送信元メール
アドレスが作成者個人のアドレスになってしまいます。

そこで今回はFlowを利用して送信元を個人のアドレスからOffice365グループ
アドレスに置き換えていくひと手間を加えていく事になります。

●作業ステップ

手順は以下の流れで進めていきます。

① アンケート管理用にOffice365グループを新規作成
② 作成したOffice365グループのメールボックスに対して「メールボックス所有者
　として送信する」権限を付与
③ アンケート管理用グループ用にMicrosoft Formを利用してアンケートフォームを
　作成
④ Microsoft Flow テンプレートを利用して③で作成したアンケートフォームの
　連携設定
⑤ メール通知内容および通知アクションをカスタマイズ

尚、①と②の手順に関しては割愛させて頂きますが、手順の詳細を確認したい方は、
設定手順が記載された下記URLを参考にして下さい。

① の手順：管理センターで Office 365 グループを作成する
https://bit.ly/2Nt7dWy

② の手順：Office 365 グループとしてメールを送信することをメンバーに許可する
https://bit.ly/2NxwUFd

※既に①、②の前提を満たしているOffice365グループが存在している環境であれば
　この手順はスキップ頂いて構いません。

では早速進めていきましょう。

Office365ポータルにログインし、「Forms」をクリックします。

「グループのフォーム」を選択後、[最近使ったグループのフォーム]右側にある「↓」を
クリックします。

Office365上に存在するグループ一覧が表示されます。
今回は「labo-admin-team」Office365 グループ用にフォームを作成します。

「新しいグループのフォーム」をクリックすると「無題のフォーム」が表示される
ので、こちらをクリックします。

「無題のフォーム」をクリックして任意のタイトルを入力します。

今回は「ブログ記事に関するアンケート」をタイトルとしました。
タイトルの下にはフォームに対する説明を追記出来ます。

タイトルを入力した後は質問を追加していきます。
アンケートフォームにおける質問形式としては以下の6種類です。

各質問形式の利用用途を表にまとめてみましたので参考にして下さい。

今回はフォーム作成の細かい手順は割愛しますが、参考としてそれぞれの質問形式の
回答イメージと設定画面を載せておきます。

●選択肢の回答イメージ

●選択肢の設定画面
先頭行に質問事項を記入し、[オプションn]の箇所をクリックする事で回答となる選択肢を入力します。

選択肢を増やす場合は、「オプションを追加」をクリックします。

選択肢として回答者自身が任意のキーワードを入力させる場合には、
「“その他”オプションの追加」をクリックします。

補足説明となるサブタイトルの追加や、選択肢をドロップダウンリスト形式に切り
替えるオプションが用意されています。

また、複数回答を有効化すると、選択肢がチェックボックス形式に切り替わります。

●テキストの回答イメージ

●テキストの設定画面
テキスト質問形式の場合は、「長い回答」オプションが用意されています。
これにより複数行に渡っての回答を得る事が出来ます。

●評価の回答イメージ

●評価の設定画面
評価の質問形式では、「シンボル」の箇所で☆マークによる評価(スターレーティング)
とするか、数字による評価を選択出来ます。

評価のレベルは最大で10段階となります。

●日付の回答イメージ

●ランキングの回答イメージ

●リッカートの回答イメージ

●その他の機能
「分岐の設定」を利用すると、質問の回答によって任意の質問事項にスキップする事が
出来ます。

「設定」では、回答ユーザーのスコープおよびオプションを選択出来ます。

匿名回答とする場合は「リンクにアクセスできるすべてのユーザーが回答可能」を

選択し、組織内ユーザーに限定する場合はもう一方のオプションを選択します。

「回答のオプション」では期限設定や、回答時にメール通知をする事も可能です。

画面上部の「テーマ」を選択するとフォームの背景画像を選択出来ます。また、Bing

検索やPCローカルの画像ファイルも利用可能です。

「共有」をクリックすると、用途別のURLを確認出来ます。

・回答者専用URL　　 (回答者が実際にアンケートを入力するためのURLとなります)
・テンプレートURL (フォームをテンプレートとして公開するためのURLとなります)
・共同編集用URL　　 (複数メンバーが共同編集する場合に共有するURLとなります)

ここまでご説明してきた画面は全て編集画面となりますが、回答者から見た実際の回答フォームを確認するには「プレビュー」をクリックします。

PCで見た場合、スマートフォンで見た場合の両方をプレビューで確認する事が出来ます。

今回の投稿はここまでとさせて頂き、次回は後編としてFlowによる回答結果をメール
で通知する手順をお伝えします。

今回も最後までお読み頂きありがとうございました！

記事投稿者：津久井

こんにちは。

Data Domainも今回で十五回目となりました。
第十四回ではファイル・システム・クリーニングについて見てきました。
今回はData Domainのラインナップに新たに加わりました "新モデルDD3300"に
ついて紹介します。

【1】新モデルData Domain3300登場

・DD3300はData Domainラインナップ初の "Dell EMCモデル”となります。
　ハードはDellのサーバ技術・ノウハウを活かして設計されたPower Edgeサーバになります。

・DD3300は既存のエントリーモデルのDD2200の後継機種になります。
　筐体は2Uラックマントで容量に応じて3つのモデル提供となります。（4TB、16TB、32TB）

・容量は後から拡張することが出来ます。

・DD2200と比較すると性能を1.5倍に、拡張性は5.6倍に。
　DD3300の最大スループットは7.0TB/時間。論理容量は200TB～1.6ペタバイトになります。

・上位機種（DD6800、DD9300、DD9300）に提供されていたクラウド対応機能が
　利用できるようになりました。

　クラウド機能1　Data Domain Cloud Tier: データをクラウドストレージに保存する機能

　クラウド機能2　Data Domain Cloud DR: 災害時にクラウドストレージに保存したデータを利用して災害復旧する機能

※ 弊社で購入したDD3300の前面の写真を撮ってみました。（パシャ）
　 前面ベゼルにはモデル名のD3300が刻字されています。前面ベゼルは変わりましたね。

【2】DD3300の容量拡張 

DD3300は購入後、容量の拡張を行うことが可能です。
4TBモデル、16TBモデルの容量拡張についてご説明します。

容量拡張がサポートされているのは「4TB → 16TB」・「16TB →32TB」のみとなります。
4TBモデルは「16TB」に1回だけアップグレード可能です。
アップグレード後の16TBから32TBへの2回目のアップグレードは現在サポートされていません。

【3】DD3300とDD2200比較

DD3300のスループット数、ストリーム数等をDD2200と比較して見てみましょう。

【4】DD3300 ハードウェア（前面・背面）

DD3300のハードはDellのサーバ "Powe Edge"を採用しています。
DD2200と比較しながらハードウェアを見てみましょう。

※ 弊社で購入したDD3300の前面・背面の写真を撮ってみました。（パシャ パシャ）

＜前面＞

【電源】
DD2200は電源ボタンが搭載されていませんが、
DD3300は右コントールパネル上段に電源ボタンが搭載されました。

【ディスク】
 DD2200ではディスクのスロット番号の割り当ては左から順に
 ⓪ → ① → ② になっていました。
 DD3300ではハードがPower Edgeに変更されたことにより、
ディスクのスロット番号の割り当ては左から下に⓪ ↓ ① ↓ ② に変更になりました。

＜背面＞

【イーサネットポート】
DD2200と同様にオンボードで1Gbeのポートが4Port搭載されています。

ポート番号は左から順に [0] → [1] → [2] → [3] になります。

論理ポート名はDD2200と同様となります。(ethMa, ethMb, ethMc, ethMd)
論理ポート名は ”system show ports"コマンドで確認できます。

【PSU】
 DD2200と同様に100V/200Vの2系統になります。
 DD2200と異なる点はステータスLEDとして点灯する
 半透明のハンドルが搭載されました。

【PSNT（製品シリアル番号タグ）】
 PSNTはシステムの背面にあり、シャーシ中央のアームに貼付されています。
 このシリアル番号は初回起動時のログインパスワードになります。

 初期構築する際は事前にシリアル番号を控えて構築しましょう！

SN: 製品シリアル番号(14桁の英数字)
PN: DD3300用のパーツ番号

【5】DD3300が搭載しているDDOS

DD3300に搭載されているDDOSバージョンは
最新のDDOS6.1を搭載しています。

搭載されているDDOSのバージョンは
”uname"コマンドで確認できます。

【6】Data Domain System Manager 

DD2200と同様にDD3300もData Domain Ssystem Managerに
と呼ばれるWebベースの管理コンソールを利用してCIFS設定など行います。

DDOS6.1になってSystem Managerへのログイン画面が変わりました！

次回は別の機能、技術的な部分についてご紹介したいと思います。
それでは次回もよろしくお願いします。

【Dell EMC DD3300新規発売キャンペーン】
https://www.networld.co.jp/campaign/dellemc_dd3300/

[キャンペーン期間]2018/7/9～2018/10/31
※DD2200は8月11日で終息となります。

担当： Data Domain製品担当

こんにちは。

Data Domainも今回で十六回目となりました。
第十五回ではData Domainのラインナップに新たに加わりました
"新モデルDD3300"について紹介しました。
今回はDDOS6.X系のライセンスダウンロードについて紹介します。

DDOS6.X系ライセンスの変更点（e-license）

＜DDOS5.X系＞
・ライセンスは工場出荷時にプリインストールされていました。

＜DDOS6.X系＞
・DDOS6.X系からは工場出荷後に御客様でライセンスファイルをダウンロードし、
　Data Domainシステムに適用が必要となりました。

・ライセンスの適用は従来のライセンスコードの入力ではなく、
　ライセンスファイルの適用型に変更になりました。

DDD3300に搭載されているDDOSは6.1となります。
ライセンスファイルの適用が必要になりますのでご注意下さい。

【1】EMCサポートサイトのアカウント登録

・ライセンスファイルをダウンロードは "EMCサポートアカウント"を
　利用してダウンロードします。

・事前準備としてEMCサポートアカウントを登録します。

※既にアカウントをお持ちの場合は登録は不要です。
※新規登録の場合、登録に２～3営業日が掛かります。

構築作業前にEMCサポートアカウントが準備されていることを
必ず確認しましょう！

DELL EMC オンライン・サポートのアカウント作成と制限解除方法
https://community.emc.com/docs/DOC-25233

※EMCアカウント登録手順は上記URLに記載されています。

【2】ライセンスメール（LAC）の確認

・購入時に指定したメールアドレスにライセンス関する
　関する情報がメーカより送信されます。

件名

EMC License Authorization, LAC# XXXXXXXXX, PO# XXXXXXXXX , SO# XXXXXXXXX

LACメールサンプル

筐体のシリアル番号は LAC以降の英数字の文字列になります。

【3】事前確認

ライセンスファイルをダウンロードする前に
以下が準備されていることを確認します。

 ・EMCサポートアカウントが登録済みであること。
 ・インターネットの接続環境であること。
 ・ライセンスメール（LAC）を受信していること。

上記の3点が準備されていることを確認後、次はライセンスの
"アクティベーション”と "ダウンロード"を行います！

ラインスアクティベーションはData Domainシステムの
納品前に行うことが可能です!

【4】ライセンスのアクティベーション

STEP１
　ライセンスメール（LAC）に記載されたURLをクリックします。

ライセンスメール内の【Japanese日本語】をクリックすると、
メール本文を日本語表示にできます

STEP2
　EMCサポートアカウントでログインします。

STEP3
　Software License Centralより【ACTIVATE MY SOFTWARE】を
　クリックします。

STEP4
　ライセンスコート（筐体シリアル番号）を入力し、
　【SEARCH】をクリックします。

ライセンスコードは筐体シリアル番号になります。
筐体シリアル番号はライセンスメール（LAC）に記載されています。

STEP5
　表示されているライセンスコードを確認し、
 【START THE ACTIVATION PROCESS】をクリックします。

STEP6
　【SELECT A COMPANY】をクリックします。

STEP7
　表示されている会社情報を確認し、
 【SELECT A SITE】をクリックします。

STEP8
　表示されているサイト情報を確認し、
 【NEXT:ENTER DETAILS】をクリックします。

STEP9
　表示されている筐体シリアルナンバーを確認し、
 【NEXT:REVIEW】をクリックします。

STEP10
　アクティベート完了メール受信のメールアドレスを入力し、
 【ACTIVATE】をクリックします。

以上でライセンスのアクティベーションは完了です。
次は STEP11 ライセンスファイル（.lac）をダウンロードします。

【5】ライセンスファイル（.lac）のダウンロード

STEP11
　ライセンスファイル（.lac）をダウンロードします。
 【SAVE TO FILE】をクリックします。

以上でライセンスファイル（.lac）のダウンロードは完了です。
次は Data Domainシステムにライセンス（.lac）ファイルを適用します。

【6】ライセンスファイル（.lac）の適用

事前確認

   Data Domainシステムにネットワーク設定（IPアドレス）がされ、
　ネットワーク疎通が行えることを確認します。

STEP1
　ネットワーク設定（IPアドレス）設定後、
　System Manager に接続します。

ユーザ名：sysadmin
パスワード：初期設定時に設定したパスワード

STEP2
　①【Administration】-【License】を選択します。
　②【Add License】をクリックします。

STEP3
　③【参照】をクリックし、ライセンスファイル（.lic）を選択します。
　④【Apply】をクリックします。

STEP4
　⑤ ライセンスファイル（.lac）が
　アップロードされていることを確認します。

以上でライセンスファイル（.lac）の適用は完了です。

次回は別の機能、技術的な部分についてご紹介したいと思います。
それでは次回もよろしくお願いします。

【Dell EMC DD3300新規発売キャンペーン】
https://www.networld.co.jp/campaign/dellemc_dd3300/

[キャンペーン期間]2018/7/9～2018/10/31
※DD2200は8月11日で終息となります。

担当：Data Domain製品担当

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

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

原文を参照したい方はNutanix Resiliency – Part 5 – Read I/O during CVM maintenance or failures?をご確認ください。

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

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

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

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

これまでにADSFがノード障害からの復旧が早いという事、またどRF2～3にすることで回復性能を高めること、そして稼働したまま空き容量を効率化するためのEC-Xへの変更を話してきました。

今回はCVMがAOSアップグレードの間のメンテナンス期間中、またはCVMの障害が発生している間、どのように仮想マシンが影響を受けるかというクリティカルで重要な話題をしていきます。

では簡単にADSFがどのように書込みを実施してデータを保護するか説明します。

次のダイアグラムでは3つのノードでクラスタが構成されており一つの仮想マシンが存在しています。

仮想マシンは正常な状況では全ての書き込みは一つの複製と共に仮想マシンが稼働しているノード(ここではNode1)に書込み、他の複製（レプリカがRF3の場合も）をディスクの健全性を元にクラスタへ分散してデータ（a,b,c,d）を書き込みます。

ディスクの健全性(私が“Intelligent replica replacement”と呼んでいるもの)はデータはまず最も最適な場所にかかれます。

１または複数のノードが追加されるとすれば、”Intelligent replica placement”はクラスタがバランスの状態になるまで、たとえ新しい書込みが発生していなくてもノードに比例して複製を送信します。

ADSFはバックグラウンド処理で低い優先順位としてディスクが全体的に均衡になるように処理をするのです。

どのようにしてNutanix が複数の複製(Resiliency Factorと呼んでいるもの)を利用してデータ保護を行っているかの基本を理解した所で、Nutanix ADSFのストレージ部分のアップグレード時にどんな事が起こるか見てみましょう。

アップグレードは”ワンクリック”で始まり、それはRFやEC-Xの構成にかかわらず一度に1つのCVMがアップデートされるローリングアップデートのスタイルとなります。

ローリングアップグレードはCVMを一度オフラインにし、アップグレードの実施を行い、自己診断後にクラスタに参加し次のCVMが同じ処理を行います。

NutanixのストレージがHypervisorと分離している（例：ストレージがカーネルのんかに組み込まれているものではない）多くのアドバンテージの一つがアップグレードとストレージレイヤーの障害が仮想マシンに何の影響も与えない事なのです。

仮想マシンは再起動を必要としません（HAのようなイベントは無しです）そして仮想マシンを他のノードに移動する必要もありません。

たとえローカルコントローラーが如何なる理由でオフラインになっても、仮想マシンはストレージトラフィックの中断無しに稼働します。

もしローカルにあるCVMがメンテナンスや他の障害でダウンしたら、I/Oは動的にクラスタ内へリダイレクトされます。

CVMの仮想マシンが如何なる理由であれオフラインになった際のRead I/O処理をみてみましょう。

ローカルのCVMがオフラインになるという事はCVMが稼働しているサーバの物理ドライブ（NVMe,SSD,HDDなど）が利用できなくなる事を意味していて、それはローカルデータ（複製）が使用できないことになります。

全てのリードI/Oはリダイレクトされクラスタ内のすべてのCVMによってリード処理は継続されます。

このメンテナンス・障害のシナリオは仮想マシンがストレージを提供できなくなってもネットワーク越しにストレージを利用できるノードは稼働するという点において3Tierアーキテクチャと比較ができます。

Nutanixはクラスタのすべてのノードでリードが提供できる分散アーキテクチャなので最悪のケースとして3ノードクラスタでノード障害、もしくはメンテナンスの期間中であってもデュアルコントローラーのストレージと同等の機能があるわけです。

繰り返しますと、3ノードクラスタで1ノードが障害または、メンテナンスとなる最悪のシナリオが発生しているクラスタのリードはリモートから読み込みます。

Nutanixの最も悪いデグレード状態は最適な状態のデュアルコントローラーのストレージにコンピュートノードがアクセスするのと同等なのです。

もしNutanixが8ノードで構成しており、1台がメンテナンスまたはダウンしても7台のノードがVMへストレージアクセスを行うのです。

この処理は実際には何も新しくなく、Nutanixが昔から行っている方法なのです。

詳細はAcropolis Hypervisor (AHV) I/O Failover & Load Balancing　2015年の7月のBlogにも記載があります。

ローカルのCVMが一度オンラインになればリード I/Oは再びローカルのCVMによって提供され、リモートへの読み込みはデータがローカルに無い場合に発生します。

リモートの読み込みが発生するとそのデータを含む1MBのエクステントがローカライズされリードはローカルから読み込まれるようになります。

エクステントのデータがローカライズされることはリモートのリードを行うことに比べて追加のオーバーヘッド無く、ローカライズは追加のオーバーヘッド無しにパフォーマンスが良くなるという事を理解する事は非常に重要な事です。

Summary:

1. ADSF writes data on the node where the VM resides to ensure subsequent reads are local.
2. Read I/O is serviced by the local CVM and when the Local CVM is unavailable for any reason the read I/O is serviced by all CVMs in the cluster in a distributed manner
3. Virtual machines do not need to be failed over or evacuated from a node when the local CVM is offline due to maintenance or failure
4. In the worst case scenario of a 3 node cluster and a CVM down, a virtual machine running on Nutanix has it’s traffic serviced by at least two storage controllers which is the best case scenario for a Server + Dual Controller Storage Array (3 Tier) architecture.
5. In clusters larger than three, Virtual machines on Nutanix enjoy more storage controllers serving their read I/O than an optimal scenario for a Server + Dual Controller Storage Array (3 Tier) architecture.

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

本記事はNutanix社のオフィシャルブログの翻訳版です。原文を参照したい方は

Desktops-as-a-Service, With No Cloud Lock-In – Frame and Nutanix Xi Cloud Servicesご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

本日　私たちはfra.meをNutanixのファミリーにむかえ、Nutanix Xi サービスにDesktop-as-a-Serviceを提供できるようになることをお知らせします。

本サービスは、まず1クリックデスクトップの展開をAWS、Azureする事をサポートし、そして全てのクラウドに拡張していきます。

NutanixのミッションはITスタックをシンプルにすることで、物理インフラから始まり徐々にデーターセンターインフラ基盤へ広げていきます。

Nutanix Xi サービスはハイブリットクラウドのパワーを企業へもたらし、ツールや企業システムの複雑な事に対して摩擦無しにクラウドファーストの消費モデルをサポートする為の戦略の進化となります。

このハイブリッドクラウドは純粋なパブリッククラウドパスの代わりとなるのです。

私たちが企業の収益創出をお手伝いする事ができず、もっとも便宜的で費用対効果の高い方法で全てを問題のすべてを取り除く事が出来ないとすれば、本当のアプリケーションとITの目的はなんでしょうか？

このミッションに鋭く焦点を当てる一方で、Nutanixはこのミッション、クリティカルなアプリケーション、高いパフォーマンス、トランザクション処理の入るデータベース、ビックデータで求められるデータレイクや他のすべてのアプリケーション（アナリストの用語でいう、モード1,モード2アプリケーション - オンプレミス vs クラウド - そしてインフラストラクチャ基盤のインビジブルがこれらのアプリケーションへ提供するように進化をしてきているのです。

このコンセプトは1クリック機能、インテリジェンスなアルゴリズム、ゼロタッチオペレーション、利用者向けのUX,Webスケール技術によって作られています。

お客様を基準としたNutanixの多様性はアプリケーションの本質を持ち、仮想デスクトップとApps（VDI）は依然として私たちにとって重要なものであり劇的に成長しているのです。

ハイパーコンバージドが斬新とされていた早い段階から、VDI環境はストレージ、ネットワーク、サーバと運用の境界をなくし、個々のサイロ化された専門性、高いOPEXを維持しながら続ける環境へどのようにゲームチェンが行われるかを知ることができる最初のものでした。

VDIはハイパーコンバージェンスを引っ張る要因となり、世界へこれが全てのアプリケーションの為のデーターセンターを構築する新しい方法だという事を示したのです。

その方法は純粋なパブリッククラウドを利用するよりもあるかに説得力のある方法だったのです。

現在の素晴らしいNutanixの上で稼働するVDIですが、VDIはかつてのように多くの負担をかけるものではなくなった一方、最も使われている2つのソリューションを組み合わせたものでビジネス全体では重要な部分です。

Nutanixが順調にアプリケーションスタックの下で革新したとしても、インビジブルな仮想化のAHV、ゼロタッチ運用の為のPrism Pro, ネットワークセキュリティの為のFlow、ソフトウェア定義のスケールアウトファイルサービスAFS、と共にVDIの提供を継続するのがより良い事となり、常にVDIにもっと良いことが出来るかと考えているのです。

2016年初め、NutanixはCitrix社と提携し、非常に素晴らしいシンプルなCitrixの展開を行うため、AHVのインビジブルな仮想化基盤を活用し、お客様のこの統合における絶大な価値を認識頂いています。

2017年後半にはCitrix Cloud のInstantONの導入がお客様のVDIの展開を簡単にし迅速に展開できる価値を提供しました。

インビジブルなインフラ基盤を全ての有名なVDI環境へ提供し、Nutanixは数千ものお客様の環境へ入ることで変化するお客様の意向が見えました。

この振舞は、利用されている殆どの期間が8時間 x 5日、またはすべてのアプリケーションがSaaSやクラウドへ移行した際のオンプレミスの仮想デスクトップ環境であったとしても24時間 x7日間仮想デスクトップのインスタンスを働し続けなければ行けないという疑問に向けられました。

クラウドネイティブなアーキテクチャ上でどの程度デスクトップやAppが使われてるか根本的に簡素化する必要が急速に高まっていることが明らかになったのです。

AWSはワークスペースの立ち上げをこれで開拓しましたが、市場の中で多くの需要がないニーズの機能を提供したのと同様に1つのクラウドへのロックインをしたのです。

それがこの機会となり、Frameの買収とNutanixと共に進むという交点がエンタープライズ環境の中でシンプルさへという道のりのなか衝撃をさらに広げる事になるのです。そして、今Nutanixはデスクトップとアプリケーションレイヤーを持ち合わせています。

想像してみてください。1クリックで簡単にNutanix Xi サービスにDaaSが提供しているFrameの魅力的なものを追加できるとしたら？クラウドロックインがされていなかったら？Frameは選択の考え、開放性、簡素性を統合する

もし何かが複雑すぎて1クリックが達成できない場合は振り出しに戻ってやり直し、アーキテクチャがクラウドスケールでない場合は技術スタック全体を再考、もしNutanixがしているようにNPSスコア90という一貫性が取れないほど魅力の無い場合は真の価値が提供されるまでそこに注力します。

この目的に向け、Frameは殆ど多くのクラウドへ展開できる”クラウド生まれのDaaSソリューション”として作られており、お客様が選択しているNutanixの1クリック、シンプルという哲学と一貫しています。

これは、いかなるシングルクラウドのロックインを避けることが出来、ITの長期間リスクは最小限となります。

全ての企業の運用ツールを変更しないでNutanix　Xiサービスが利用できる事は、クラウドパブリックをより身近にし、多くの機会を提供することになります。

アイシングはFrameの素晴らしいユーザーエクスペリエンスであり強力な展開プロトコルが最も要求の厳しいグラフィック-インテンシブアプリケーションでさえも完璧に利用者のネットワーク上で動作します。これはHTML5ブラウザになるので如何なるクライアントソフトウェアの必要もないのです。

私たちは素晴らしく才能がありハングリー精神のあるFrameチームがNutanixと一緒になる事に本当に興奮しているのです。Nutanix Xi サービスとしてFrameが実行できることはこの旅のエキサイティングな一歩であり、他のエンタープライズレイヤに1クリックでユーザー、管理者が利用者へクラウドスケールデスクトップとアプリケーショをもたらし他のエンタープライズのレイヤーの障壁を粉砕する事を楽しみにしています。

Frameがどのように簡単に利用が出来るのか？

当社のVDIを得意とする技術メンバーが検証し今後Blogで紹介したいと思いますので

お楽しみにしてください！

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

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

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

原文を参照したい方はNutanix Resiliency – Part 6 – Write I/O during CVM maintenance or failuresをご確認ください。

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

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

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

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

パート5ではCVMがメンテナンス中、または障害時にどの様にリードI/Oが行われるかを説明しました、今度は同じようにメンテナンス、障害のシナリオ期間中に発生するより重要な書込みI/Oについて知っておく必要があります。

パート5をお読みになった方は同じように感じるでしょう、まだパート5を読んでいないかたは是非パート5も読んでください。

さて、簡単にどのようにNutanix ADSFが書込みを行い、データ保護をしているか説明します。

下のダイアグラムでは3つのノードと一つの仮想マシンが存在しています。

仮想マシンは正常な状況では全ての書き込みは一つの複製と共に仮想マシンが稼働しているノード(ここではNode1)に書込み、他の複製（レプリカがRF3の場合も）をディスクの健全性を元にクラスタへ分散してデータ（a,b,c,d）を書き込みます。

ディスクの健全性(私が“Intelligent replica replacement”と呼んでいるもの)はデータはまず最も最適な場所にかかれます。

１または複数のノードが追加されるとすれば、”Intelligent replica placement”はクラスタがバランスの状態になるまで、たとえ新しい書込みが発生していなくてもノードに比例して複製を送信します。

ADSFはバックグラウンド処理で低い優先順位としてディスクが全体的に均衡になるように処理をするのです。

どのようにしてNutanix が複数の複製(Resiliency Factorと呼んでいるもの)を利用してデータ保護を行っているかの基本を理解した所で、Nutanix ADSFのストレージ部分のアップグレード時にどんな事が起こるか見てみましょう。

アップグレードは”ワンクリック”で始まり、それはRFやEC-Xの構成にかかわらず一度に1つのCVMがアップデートされるローリングアップデートのスタイルとなります。

ローリングアップグレードはCVMを一度オフラインにし、アップグレードの実施を行い、自己診断後にクラスタに参加し次のCVMが同じ処理を行います。

NutanixのストレージがHypervisorと分離している（例：ストレージがカーネルのなかに組み込まれているものではない）多くのアドバンテージの一つがアップグレードとストレージレイヤーの障害が仮想マシンに何の影響も与えない事なのです。

仮想マシンは再起動を必要としません（HAのようなイベントは無しです）そして仮想マシンを他のノードに移動する必要もありません。

たとえローカルコントローラーが如何なる理由でオフラインになっても、仮想マシンはストレージトラフィックの中断無しに稼働します。

もしローカルにあるCVMがメンテナンスや他の障害でダウンしたら、I/Oは動的にクラスタ内へリダイレクトされます。

CVMの仮想マシンが如何なる理由であれオフラインになった際のWrite I/O処理をみてみましょう。

ローカルのCVMがオフラインになるという事はCVMが稼働しているサーバの物理ドライブ（NVMe,SSD,HDDなど）が利用できなくなる事を意味していて、それはローカルデータ（複製）が使用できないことになります。

全てのライトI/Oは一つの複製をローカルに置くという事より、RFに従う形で書き込みが継続されます。データはリネットワーク越しにリモートのCVMを通して複製します。

次の例では3つのノードでノード1にいる仮想マシンが”E”のデータをネットワーク越しにNode2 , 3に書き込みます。これがリモートのCVMによって新しいデータが書き込まれる方法です。

もっと多くのノードがクラスタに存在していれば書き込みはクラスタ内のすべてのノードに”Intelligent Replica Placement”によって下の図のように分散されます。

新しいデータとは反対に上書きが発生した場合、ローカルにあるデータはCVMのオフラインにより利用できません。

Nutanixは他の複製に上書きを行い次にそのデータの複製をRFに応じて別のノードに書き込むことによってデータの整合性が保たれます。

これはとても重要な事で、もしデータがRF（VMware VSANでいうFTT）に常に準じていなければ次に起こりうるドライブ、ノード障害がデータ損失の原因になります。

vSANよりも優れたRFの大きなアドバンテージをNutanixにはるのは、全ての障害、メンテナンスシナリオに対してRF準拠する事です。

しかしvSANは全てのホストメンテナンス、障害シナリオのFTTを構成していません。

FTT1で構成されているvSAN上のVMはホストが提供している一つのvSANオブジェクトのメンテナンスでオフラインの場合、新しい上書きは保護されないため、一つのディスク障害がデータロスを引き起こす事があります。

VMware社のチーフテクノロジー Duncan Epping氏は最近に次の"VSAN:6.2でFTT=2がデフォルト"になる理由という記事を掲載しました。この記事によりDuncan Epping 氏はFTT=2をvSAN利用者のため、新しいデフォルト値として推奨したのです。

私はDuncan氏には同意です。しかしvSANをFTT=2にするべきとは言いません。

FTT=1はメンテナンス、または障害時の間の上書き処理に対する単一障害点となるのでFTT=2にしなければならないと考えます。これは多くの本番環境にとって受け入れがたい事です。

一方NutanixはvSANと同じアーキテクチャではないので、RF2は非常に優れ、このシリーズで説明したとおり、クリティカルな本番環境にも適しています。

そしてADSFはタイムリーにRFを復旧するのでRF2はvSANのFTT=1と比べても非常に優れていると言えるのです。

次はハイパーバイザのアップグレードで仮想マシンがどのように影響を受けるかを説明します。

Summary:

1. Write I/O continues uninterrupted if the local CVM is offline
2. Write I/O is distributed throughout the cluster evenly thanks to Intelligent Replica Placement
3. All new data is written in compliance with the configured Resiliency Factor
4. Overwrites of existing data is always written in compliance with the configured Resiliency Factor by writing a new replica where the original replica is not available.
5. Data integrity is ALWAYS maintained regardless of a CVM being under maintenance or failure.
6. Nutanix RF2 is more resilient than vSAN FTT=1 despite each claiming to maintain two copies of data.

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