ネットワールド　らぼ

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

今日は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 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

本記事の原文はもともと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

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

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

名前(サービス名)	スタートアップ の種類	状態	公開アプリ での設定	公開デスクトップでの設定
Themes	自動	実行中	無効	有効にすると : ユーザーエクスペリエンスの向上 無効にすると : サーバーでの集約率の向上

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

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

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

タスク	説明
Application Experience \ Microsoft Compatibility Appraiser	アプリケーションの互換性の問題を解決するのに役立ちます。
Application Experience \ StartupTask	起動エントリーが多すぎるかどうかを判断し、ユーザーに通知します。

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

タスク	説明
AutoCHK \ Proxy	このタスクはMicrosoftカスタマーエクスペリエンス向上プログラムに 同意した場合、autochk SQMデータを収集してアップロードします。
Customer Experience Improvement Program \Consolidator	このタスクはWindowsカスタマエクスペリエンス向上プログラムに 参加することに同意した場合、Microsoftに使用データを収集して 送信します。
Customer Experience Improvement Program \KernelCeipTask	このタスクはシステムに関する追加情報を収集し、カーネルCEIP (Customer Experience Improvement Program)のデータを マイクロソフトに送信します。 ユーザーがCEIPに参加することに同意しない場合、このタスクは 何も行いません。
Customer Experience Improvement Program \UsbCeip	このタスクは、ユニバーサルシリアルバス関連の統計情報と コンピュータに関する情報を収集し、MicrosoftのWindows Device Connectivityエンジニアリンググループに送信します。 受け取った情報は、WindowsのUSBの信頼性、安定性、および 全体的な機能を向上させるのに役立ちます。 ユーザーがCEIPへの参加に同意しなかった場合、このタスクは 何も行いません。

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

タスク	説明
Windows Defender \ Windows Defender Cache Maintenance	別のウイルスとマルウェアの保護がインストールされている場合は無効にすることができます。
Windows Defender \ Windows Defender Cleanup	別のウイルスとマルウェアの保護がインストールされている場合は無効にすることができます。
Windows Defender \ Windows Defender Scheduled Scan	別のウイルスとマルウェアの保護がインストールされている場合は無効にすることができます。
Windows Defender \ Windows Defender Verification	別のウイルスとマルウェアの保護がインストールされている場合は無効にすることができます。
Windows Filtering Platform \BfeOnServiceStartTypeChange	このタスクは、BFE(Base Filtering Engine)のスタートアップの種類が無効になっている場合に、 ファイアウォールによって実行されるサービスのスタートアップの種類を調整します。

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

タスク	説明
CHKDSK \ Proactive Scan	NTFSボリュームの健全性スキャンをします。
Diagnosis \ Scheduled	Windowsの定期メンテナンスタスクは、問題を自動的に解決するか、 またはアクションセンターを通じて報告することによって、コンピューターの 定期的なメンテナンスを実行します。
DiskDiagnostic \ Microsoft-Windows-DiskDiagnosticDataCollector	Windows Disk Diagnosticは、Customer Experience Programに参加している ユーザーのために、一般的なディスクおよびシステム情報をMicrosoftに報告します。
Maintenance \ WinSAT	システムのパフォーマンスと機能を測定します。
Power Efficiency Diagnostics \ AnalyzeSystem	このタスクは、高いバッテリー使用を引き起こす可能性のある状態を探して システムを分析します
RecoveryEnvironment \ VerifyWinRE	Windowsの回復オプション環境を検証します。
Registry \ RegIdleBackup	レジストリアイドルバックアップタスクです。

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

タスク	説明
Mobile Broadband Accounts / MNO Metadata Parser	モバイルブロードバンドユーザーに関する情報を解析します。
Power Efficiency Diagnostics \ AnalyzeSystem	このタスクは、高いバッテリー使用を引き起こす可能性のある状態を探してシステムを分析します。
RAS / MobilityManager	既定のインターフェイスがダウンしたときに、モビリティ対応VPN接続切り替えへのサポートを提供します。
Shell / IndexerAutomaticMaintenance	検索インデックスのメンテナンスをします。
WDI \ ResolutionHost	Windows診断インフラストラクチャ解決ホストは、診断ポリシーサービスによって検出されたシステム 問題の対話型の解決を可能にします。 これは、適切なユーザーセッションで診断ポリシーサービスによって必要に応じて実行されます。 診断ポリシーサービスが実行されていない場合、このタスクは実行されません。

ユーザーインタフェース

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

最適化項目	設定個所
スクリーンセーバーを無効化	HKEY_USERS\.DEFAULT\ControlPanel\Desktop
	“ScreenSaveActive”=dword: 00000000
ハードウェアに関するエラーを非表示	[HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Control\Windows]
	“ErrorMode”=dword:00000002
視覚効果をカスタムに設定する	[HKEY_CURRENT_USER\Software\Microsoft\Windows\ CurrentVersion\Explorer\VisualEffects]
	“VisualFXSetting”=dword:00000003
「半透明の[選択]ツールを表示する」を無効化	[HKEY_CURRENT_USER\Software\Microsoft\Windows\ CurrentVersion\Explorer\Advanced]
	“ListviewAlphaSelect”=dword:00000000
「ウィンドウの下に影を表示する」を無効化	[HKEY_CURRENT_USER\Software\Microsoft\Windows\ CurrentVersion\Explorer\Advanced]
	“ListviewShadow”=dword:00000000
ウィンドウを最大化や最小化するときにアニメーションで表示する	[HKEY_CURRENT_USER \ControlPanel\Desktop\WindowMetrics]
	“MinAnimate”=”0”
「タスクバーでアニメーションを表示する」を無効化	[HKEY_CURRENT_USER\Software\Microsoft\Windows\ CurrentVersion\Explorer\Advanced]
	“TaskbarAnimations”=dword:00000000
プレビューを有効にする」を無効化	[HKEY_CURRENT_USER\Software\Microsoft\Windows\DWM]
	“EnableAeroPeek”=dword:00000000
タスクバーの縮小版のプレビューを保存する」を無効化	[HKEY_CURRENT_USER\Software\Microsoft\Windows\DWM]
	“AlwaysHibernateThumbnails”=dword:00000000
スクリーンフォントの縁を滑らかにする」を無効化	[HKEY_CURRENT_USER \Control Panel\Desktop]
	“FontSmoothing”=”0”
視覚効果の無効化	[HKEY_CURRENT_USER \Control Panel\Desktop\]
	“UserPreferencesMask”=RegBin: “90,12,03,80,10,00,00,00”
マウスカーソルの点滅を無効化	[HKEY_CURRENT_USER \Control Panel\Desktop]
	“CursorBlinkRate”=”-1″
Internet Explorerの初回起動時のウィザードを無効化	[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\ Microsoft\InternetExplorer\Main]
	“DisableFirstRunCustomize”=dword:00000001
メニューの遅延表示を減らす	[HKEY_CURRENT_USER\ControlPanel\Desktop]
	MenuShowDelay”, “0”

システム

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

システム - BIOS

最適化項目	設定個所
最大パフォーマンス (電源)	BIOSが低電力モードではなく最大パフォーマンスで設定されていることを確認します。

システム - コマンド

最適化項目	設定個所
休止状態の無効化	Powercfg -h off

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

最適化項目	設定個所
NTFSの最終アクセス日時の更新を無効化	[HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Control\FileSystem]
	“NtfsDisableLastAccessUpdate”=dword:00000001
メモリダンプの生成を無効化	[HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Control\CrashControl]
	“CrashDumpEnabled”=dword:00000000
	“LogEvent”=dword:00000000
	“SendAlert”=dword:00000000
ディスクI/Oのタイムアウト値を200秒に増やす	[HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\Disk]
	“TimeOutValue”=dword:000000C8

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

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

今日の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技術本部 海野 航 (うんの わたる)

本記事の原文はもともと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

今回は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氏によるものです。

原文を参照したい方は 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

今回は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社のオフィシャルブログの翻訳版です。原文を参照したい方は

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