LTN Blog 〜 Lenovo Technology Network 〜

レノボのソリューション・サーバー製品に関する技術情報、お役立ち情報をお届けします

AWSにも対応したXtract VMs~Xtract for vmsの紹介~【第二弾】

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。

本日は以前にもご紹介したXtract for VMsのアップデート情報として、AWS対応についてお話したいと思います。前回ご紹介した内容も若干理解していたほうが今回の話題も理解しやすいと思いますので、以下に前回の記事も載せておきます。

blog.lenovojp.com

前回の内容はESXiからAHVへの移行についての内容になっていましたが、今回もそちらの内容にも触れますが、AWSからの移行をご紹介したいと思います。(現状はTechPreview版でのリリース)

1. Xtractによる仮想環境の移行について

f:id:t_komiya:20190114005936p:plain

 みなさまも仮想化環境をNutanixで検討するときに、現状の仮想化環境(VMware)からAHVの環境に移行する場合にシンプルでかつ効率的で柔軟性があるツールを期待していると思います。前回紹介したXtractでESXに関する部分での柔軟性は十分にお伝えしたかと思いますが、今回のXtract 2.0においてはAWSやHyper-Vからの環境をオンプレのAHV環境にマイグレーションができるようになっています。もちろんすべての環境が移行できるわけではなく、AHVでサポートしているものに限定されるわけでありますが、それでもNutanixの環境に統合できることは恩恵は大きいと思います。

2. アプリケーションモビリティの実現

f:id:t_komiya:20190114010311p:plain

AHVへの移行のためにXtractがあるわけではありません。 以前にもご紹介したかと思いますが、マルチクラウド環境においてワークロードを最適なロケーションで動作させるためにCalmでデプロイさせることやBeamなどで複数のクラウド環境(オンプレのNutanixも含む)で最適なコストを見極めて、最適な場所へワークロード移行を行う際にXtractを利用するという、NutanixのEnterprise Cloudのビジョンも進化することで、様々なシーンでXtractを利用される場面が出てきております。

3. Xtractのお客様導入例

f:id:t_komiya:20190114172609p:plain

Xtractを利用して仮想マシンを移行した例を紹介したいと思います。すでに100以上のお客様で合計30,000台以上の仮想マシン(1社あたりでは最大数千という会社もあり)で利用されており、ほとんどがWindowsやCentOSなどの環境をAHVの移行で利用しております。通常この作業を行うと数か月要しますが、このXtractを利用すると期間を短縮することができます。その理由はXtractの対応しているCBT機能が一つのの要因かもしれません。

4. 環境やワークロードに適したデータ移行についてf:id:t_komiya:20190114173404p:plain

Xtractを利用する場合に利用している環境や利用しているワークロードが適しているものかどうかを考える必要があります。ESXであればオンプレ同士で移行が可能ですが、AWSからの移行であれば、対応しているOSや(セキュリティを考慮した)ネットワーク環境も考える必要があります。また、ワークロードについても普通の仮想マシンだけではファイルサーバみたいな容量が大きいものをどうするかなども考える必要があります。(ファイルサーバの場合はデータだけで考えればXtractが必須なツールではありませんが)

マルチクラウド環境でのデータ移行を効率するためにXtractが利用されます。Exchangeやドメインコントローラのようなものの移行についてもベストプラクティス(英語)を後程URLなど記載しておきます。

5. AWSおよびHyper-Vからのアプリケーションモビリティ

f:id:t_komiya:20190114174127p:plain

今回のAWS対応でパブリッククラウドからの仮想マシンの移行がサポートにより、パブリッククラウドへの依存性を軽減することができます。例えばパフォーマンスを必要とするアプリケーションやレイテンシ(遅延)を気にするようなワークロードについてはオンプレに移行したほうがよい場合にXtractを利用することで、1クリック(事前に設定は必要になりますが)で移行が可能となります。オンプレに関してはHyper-Vもサポートが追加されることになります。

6. Xtractのアーキテクチャ(AWS)

f:id:t_komiya:20190114175053p:plain

Xtractのアーキテクチャを簡単にご紹介します。AWSからの仮想マシン移行において、AWSでのCrendential情報を利用して仮想マシンにアクセスできる環境が必要になります。Xtractで移行を実行する際に、仮想マシンは稼働している状態の場合は動作中の差分データの転送も行うためにCBT(Change Block Tracking)機能が必要となります。また、AWS側の環境にはXtract-Liteの仮想マシンをデプロイしてAWS側の仮想マシンにアクセスできるようなアプライアンスを用意する必要があります。もう少し詳細に記載したものを以下のイメージとして載せておきます。

f:id:t_komiya:20190114180415p:plain

 

f:id:t_komiya:20190114180739p:plain

7. Xtract のオペレーション

Xtractでは以下のオペレーション可能となります。

  • パワーオンまたはパワーオフ状態のVMを移行します
    : AWSでは、移行は電源が入った状態で行われます。ESXiの場合、電源状態は保持されます
  • 移行を一時停止して再開
  • 移行のスケジューリング
  • 仮想マシンのデータシーディングを事前にスケジュールし、新しいAHVクラスターに切り替え
  • 単一の管理インターフェース複数のクラスタ間の仮想マシン移行を管理
  • 簡単に移行できるように仮想マシンソートおよびグループ化
  • 個々の仮想マシンレベルでも移行計画の実行の詳細を監視
  • 個々の仮想マシン進行中の移行をキャンセル
  • すべてAHV認定OS移行可能

8. Xtractのコンポーネント

f:id:t_komiya:20190114181231p:plain

こちらがコンポーネントの一覧になります。CLIについてはそれぞれのOSの環境で提供されています。Xtract-vmはターゲットとなるAHV側に導入するモジュールになります。Xtract-vm-LiteはAWSから移行を行う際のAWS側にデプロイするモジュールになります。ESXiやHyper-V環境についてはエージェントを導入します。

また、Xtract for VMで必要なリソースは以下の通りです。

  • コアあたりのvCPU:2
  • コア数:2
  • メモリ:4 GB

9. サポートされているESXiおよびゲストOS情報

f:id:t_komiya:20190114181645p:plain

NutanixのSupport Portalに掲載している情報ですが、こちらにも掲載しておきます。(2019年1月13日現在の情報のため、移行を行う前に情報を確認お願い致します)
10. ESXiマイグレーションの要件

Xtract for VMs使用してESXi上で実行されている仮想マシン移行しようとする前に、以下に記載の要件を必ず満たしてください。

ESXiマイグレーションのための一般要件

  • 対応ブラウザ:Google Chrome
  • VMware ToolsはマイグレーションのためにゲストVMインストールされ、最新にする必要があ
  • 仮想マシン実行されている仮想ハードウェアのバージョンは7.0以上である必要がある
  • ソース仮想マシンChanged Block TrackingCBT)をサポートしている必要がある
  • CBT機能をサポートするには、VMのハードウェアバージョンが7以上である必要がある
  • ディスクスパース(空き容量をゼロブロックで埋める)またはフラットフォーマットでなければならず、最小バージョンは2でなければなりません
  • ESXiのバージョンは5.1以上
  • ホストはメンテナンスモードにしてはいけない
  • ポートTCP 443vCenterからXtractアプライアンスに通信可能な状態にする
  • ESXiホストは、ポートTCP 443およびTCP 902Xtractアプライアンスに通信可能な状態にする
  • すべての仮想マシンにはUUIDが必要です
  • ESXiホストには、仮想マシンの完全な構成詳細が必要
  • 仮想マシンXtractによって作成された複数のスナップショットと互換性がなければなりません
  • Xtract for VMネットワークとAHV CVMネットワークとの間のポート(TCPおよびUDP2049および111許可
  • ゲスト内操作を実行するために使用されるアカウントには、Windowsのローカルセキュリティポリシーまたはグループポリシー内の[Batch Jobしてログイン]権限が必要管理者ユーザーには十分な権限がありません
  • ソースVMにアクセスするためにsudo特権を持つroot以外のアカウントを使用している場合は、SSH サービスがソースVM上で実行されていることを確認してください。具体的には以下を確認が必要
  • localhostへのSSHは、パスワード認証のみを使用して許可されます。つまり、sshd_configPasswordAuthenticationyesに設定
  • sudoを使用してください。ユーザーはパスワードを入力せずにroot特権を引き受けること可能
  • ユーザーは/tmpに対する読み取りおよび書き込み権限が必要
  • Xtractユーザーが[ファイルとディレクトリリストア]セキュリティポリシーでグループに属している 必要があることを確認してください

サービスアカウント

Xtractは管理者権限を持つ以下のサービスアカウントを必要

  • vCenter Server
  • AHVクラスター用のPrism Element Webコンソール

11. AWSマイグレーションの要件

Xtract for VMs使用してAWSで実行されている仮想マシン移行しようとする前に、以下に記載の要件を必ず満たしてください。

AWSマイグレーションのための一般要件

  • 対応ブラウザ:Google Chrome
  • インターネットゲートウェイを持つVPCを少なくとも1つ持つXtractはそのVPCがXtract-Lite 展開しXtract-Lite通信する必要があります
  • ソースVMのすべての発信ポートを有効にする
  • WindowsソースVMの場合、UACがWindows管理者ユーザーに対して無効になっていることを確認が必要
  • LinuxソースVMの場合、必要なパッケージをダウンロードするための初期準備中にVMがインターネット 接続できることを確認。次のパッケージとその依存関係は、SaltStack、python34、python34-pip、wget、curl、epel-release、redhat-lsb-core、jqと共にインストールされます
  • ソースVMは、インターネットゲートウェイとパブリックIPが構成されたVirtual Private Cloud(VPC)の一部である必要が
  • ソースVM準備スクリプトを実行するのは、administratorWindowsソースVMまたはrootLinuxソースVMのいずれかであることを確認する必要がある
  • Windowsリモート管理(WinRM)機能が機能するためには、TCPプロトコルを使用する次インバウンドおよびアウトバウンドポートが有効になっていることを確認が必要
  • WinRM-HTTPS:5986
  • WinRM-HTTP:5985
  • RDP:3389(インバウンドのみ
  • SSH22
  • AWSソースの追加中に提供されたAWSアカウントには、EC2インスタンスのエンドツーエンド マイグレーションを実行するための次の一連の権限が必要
  • "ec2:DetachVolume",
  • "ec2:AttachVolume",
  • "ec2:DeleteSnapshot",
  • "ec2:TerminateInstances",
  • "ec2:DeleteTags",
  • "ec2:CreateTags",
  • "ec2:Describe",
  • "ec2:RunInstances",
  • "ec2:StopInstances",
  • "ec2:CreateVolume",
  • "ec2:DeleteVolume",
  • "iam:SimulatePrincipalPolicy",
  • "ec2:StartInstances",
  • "ssm:DescribeInstanceInformation",
  • "ec2:CreateSnapshot",
  • "iam:GetUser",
  • "ec2:KeyPair",
  • "route53:CreateHostedZone",
  • "route53:UpdateHostedZoneComment",
  • "route53:GetHostedZone",
  • "route53:ListHostedZones",
  • "route53:DeleteHostedZone",
  • "route53:AssociateVPCWithHostedZone",
  • "route53:ChangeResourceRecordSets",
  • "route53:DisassociateVPCFromHostedZone",
  • "route53:ListResourceRecordSets",
  • "route53:GetHostedZoneCount",
  • "route53:ListHostedZonesByName"

サービスアカウント

Xtractは管理者権限を持つ以下のサービスアカウントを必要

  • AHVクラスター用のPrism Element Webコンソール
  • ソースVM準備スクリプトを実行するadministratorためのWindowsソースVMまたはrootLinuxソースVM

12. ESXiからのマイグレーションに関する推奨事項

ESXiからVMを最適に移行するために、Nutanixは以下の内容を推奨

推奨事項

  • アラートが存在する場合は、vCenter内のすべてのVMアラートを消去
  • インベントリ更新
  • テンプレートVM変換
  • vCenterからVMアクセスを有効
  • すべてVMvCenterを介して接続されていることを確認
  • すべてVMvCenterで有効であることを確認
  • 親なし(orphanedVMがある場合は、VMを完全に回復して下さい
  • ディスクCBTの互換性を確認
  • FTペアにある場合は、VMFault ToleranceFT)を無効
  • 移行するVMに最新バージョンのVMware Toolsインストール
  • CBT対応VMのインベントリ内のスナップショット数が30未満であることを確認

13. マイグレーションでサポートされていない機能

f:id:t_komiya:20190114184012p:plain

上記が現状マイグレーションでサポートされていない機能の一覧になります。説明は長くなりますので、割愛させて頂きます。 

14. マイグレーションの機能制限

Xtract for VMsアプライアンス機能制限事項とDNS構成について記載します

AWSからマイグレーション関する認定メトリクス

以下のメトリクスは、AWSからの移行に適してい

  • 大規模なVMアクティブなワークロードを持つVMおよび複数のディスクを持つWindows VMLinux VM組み合わせ
  • 単一Xtract-Mainを使用して13の異なる領域から並行してVMマイグレーション可能
  • それぞれ13のディスクを並列に持つ5つのインスタンスを持つマイグレーションプラン
  • 500 GBのディスクを持つ2つのインスタンスを持つシングルマイグレーション
  • 2 TBのデータを含む5 TBのディスクのシングルマイグレーション
  • マイグレーション計画で10を超えるVMマイグレーション

AWSマイグレーション制限

サポートは以下によって制限される

  • EC2インスタンスタイプC4C5M4M5R4T2を使用したVMマイグレーションがサポート
  • 1.Xバージョンを実行しているXtract for VMsインスタンスから2.0.xへのアップグレードはサポートされていません。VM用のXtractの新しい展開が必要
  • 移行にかかる時間は、VMのサイズ、移行中のVM内のデータチャーン率、およびAWSとオンプレミスデータセンター間のインターネット接続によって異なります

ESXiの移行の制限

次の移行は推奨されませんが、いくつかの制限付きで実行できます。

  • Exchangeは、既存の運用環境と並行して新しいバージョンのExchange Serverをインストールして 移行し、次にユーザーのメールボックスを古いシステムから新しいシステムに移動する必要がある
  • ドメインコントローラは、新しいドメインコントローラを準備し、次にFSMO(Flexible Single Master Operations)の役割を移行することによって移行する必要がある
  • SQL Serverは、新しいSQL Serverをインストールしてから移行操作を実行して移行する必要がある
  • 移行にかかる時間は、VMのサイズ、移行中のVM内のデータチャーン率、およびソースとオンプレミスのデータセンター間のネットワーク帯域幅/接続性によって異なる

各種アプリケーションのマイグレーションのベストプラクティスは以下をご参照ください。

Exchange環境マイグレーションベストプラクティス

https://blogs.technet.microsoft.com/meamcs/2013/07/25/part-3-step-by-step-exchange-2007-to-2013-migration/

ドメインコントローラのマイグレーションベストプラクティス

https://blogs.technet.microsoft.com/canitpro/2014/05/27/step-by-step-active-directory-migration-from-windows-server-2008-r2-to-windows-server-2012-r2/

SQL Server 2012のマイグレーションベストプラクティス

https://www.microsoft.com/en-us/download/details.aspx?id=29302

15. Xtractのダッシュボード画面

f:id:t_komiya:20190114184702p:plain

ダッシュボードオプション

Xtractダッシュボードには、以下のオプションが含まれます。

Source Environment(ソース環境)利用可能なソース環境を表示します。サポートバンドルからVMを移行するための場所を追加するには、[ + Add Source Environment]をクリックします

Target Environment(ターゲット環境):利用可能なターゲット環境を表示しTargetます。+ Add Target Environment]クリックして、VMをAHVに移行する場所を追加します。

マイグレーションプランの作成:AHVにマイグレーションするVMのマイグレーションプランを立てます。マイグレーションプランにはスケジュールオプションが含まれますが、カットオーバープロセスは開始されません。

マイグレーションプランの管理: [Start]、[Pause]、[Resume]、[Abort]、[Edit]、または[Delete]操作を実行して、Xtractダッシュボードの[Migration Plan]ページで既存の移行プランを管理します。

f:id:t_komiya:20190114185126p:plain

Xtract VMにログオンしたら以下のアクションを行います。

  1. ソース環境タイプとして[VMware ESXi]を選択
  2. 表示されたフィールドに入力して「追加」をクリック

  a.ソース名:ソース環境の名前を入力

  b.vCenter ServervCenter ServerIPアドレス またFQDN入力

  c.ユーザー名:vCenter Serverにログオンするため ユーザー名入力

  d.パスワード:vCenter Serverにログオンするため パスワード入力

ソース環境がXtract VMに追加され、ソース環境リストに表示

f:id:t_komiya:20190114185204p:plain

Xtract VMにログオンしたら以下のアクションを行います。

  1. ソース環境タイプとして[Amazon Web Services]を選択
  2. 表示されたフィールドに入力して「追加」をクリック

  a. ソース名:ソース環境の名前を入力

  b.AWSアクセスキーIDAWSアカウントのアクセスキーID入力

  c.AWSシークレットアクセスキー:AWSアカウントにログオンするためのキーを入力

ソース環境がXtractに追加され、ソース環境リストに表示。[Source Name]をクリックしてソースインベントリの詳細を確認し、リージョンおよびVMの移行ステータスに基づいて結果をフィルタリングできます。

f:id:t_komiya:20190114185248p:plain

Xtract VMにログオンしたら以下のアクションを行います。

表示されたフィールドに入力して「追加」をクリック

  a. ターゲット名:Nutanix AHVターゲットの名前を入力

  b.Nutanix環境:ターゲットのPrism CentralまたはPrism ElementIPアドレスまたはFQDNを入力

  c.ユーザ名:ターゲットNutanix環境にログインするための ユーザ名を入力

  d.パスワード:ターゲットNutanix環境にログインするためパスワード入力

ターゲット環境がXtract VMに追加され、ターゲット 環境リストに表示

 

これらの情報を入力したら仮想マシンのマイグレーションが可能になります。

16. 仮想マシンのマイグレーション

f:id:t_komiya:20190114190957p:plain

先ほど設定した情報を元にXtractアプライアンス上でマイグレーションプランを作成します。

マイグレーションプラン作成については次の事項で説明します。マイグレーションプラン作成後はマイグレーションカットオーバーを実行することでマイグレーションが始まります。

マイグレーション前に移行対象の仮想マシンの情報を把握しておく必要があります。

17. ESXiのマイグレーションプランの作成

f:id:t_komiya:20190114191704p:plain

初回ログイン時にデフォルトの認証情報を使用してXtractアプライアンスにログオン可能となります。以下のアクション行うことでマイグレーションプランを作成することができます。

1.Xtract VMログオン

2.Xtractダッシュボードで、[マイグレーションプランの 作成]をクリック

3.新しいマイグレーションプラン名を入力して、[OK] クリック

4.以下のフィールドに入力して、「次へ」をクリック

   a.ソースの選択マイグレーションvCenterソースを選択

   b.ターゲットの選択マイグレーションするVMのターゲットを選択

   c.ターゲットコンテナVMマイグレーションとなるコンテナを選択

5.上記で選択したVMは、リストから1台のまたは複数VMを選択。すべてのVMを追加するには、[+ Add All]をクリックし、[Next]をクリックしますフィルタバーでVMを名前でフィルタできます。適切な列を選択してVMの種類をソートすること可能

6.VM準備のフィールドに入力して、次へ ]クリック

   a.ゲスト仮想マシンのユーザー名とパスワードを入力して、Xtractが必要なドライバーを
   
インストールします

   b.個々のVM設定を上書きする:個々のVMに対して同じ設定を上書きします。個々のVM
   ユーザー名とパスワード
更新したり、不要なVMを削除したり
することもできます。

   c.個々のVMの設定を管理する:ソースVMからのMACアドレスを保持するには、

   [Retain MAC Addresses]チェックボックスをオンにします。ゲストOSの変更を回避するには、

   [Bypass Guest Operations]チェックボックスをオンにします。

   この操作はVMデータマイグレーションには影響しませんが、カットオーバーの前に必要な

   AHVドライバーを使用してゲストOSを手動で準備する必要があります

   さらに、ゲスト操作を迂回する場合は、静的IPアドレスの保存を個別に管理する必要があります

7.ネットワーク設定のフィールドに入力して、次へをクリック

   a.ドロップダウンからターゲットネットワークを選択

   b.データシーディングスケジュール:チェックボックスをオンにして

   マイグレーション日時を選択

8.VMのマイグレーションのサマリを確認

   a.情報を編集するには[戻る]クリック

   b.マイグレーションプランを保存するには、[保存] クリック

   c.マイグレーションプランを保存してすぐに移行を開始するには[保存して開始 ]をクリック。

   マイグレーションの ためのデータ配置処理が開始します。

   マイグレーション プランの[ステータス]を選択してこの情報を監視可能

18. AWSのマイグレーションプランの作成

f:id:t_komiya:20190114192507p:plain

初回ログイン時にデフォルトの認証情報を使用してXtractアプライアンスにログオン可能となります。以下のアクション行うことでマイグレーションプランを作成することができます。

1.Xtract VMログオン

2.Xtractダッシュボードで、[マイグレーションプランの 作成]をクリック

3.新しいマイグレーションプラン名を入力して、[OK] クリック

4.以下のフィールドに入力して、「次へ」をクリック

   a.ソースの選択マイグレーション用のAWSのソースを選択

   b.リージョン:VMのマイグレーション元の リージョンを選択

   c.ターゲットの選択マイグレーションするVMのターゲットを選択

   d.ターゲットコンテナVMマイグレーションとなるコンテナを選択

5.上記で選択したVMは、リストから1台のまたは複数VMを選択。すべてのVMを追加するには、[+ Add All]をクリックし、[Next]をクリックしますフィルタバーでVMを名前でフィルタできます。適切な列を選択してVMの種類をソートすること可能

6.Xtractは自動的にXtract Lite VMを選択したリージョンに展開します。これにより、Xtractと選択したUVMとの間に安全な接続を確立できます。デプロイされたXtract Lite VMの構成です

   a.名前:NTNX-XTRACTLITE-INSTANCE

   b.インスタンスの種類:t2.micro

   c.RAM1GB

   d.ストレージ:20GB EBSボリューム

   e.VPC:指定リージョンのデフォルトVPC

   f.タグ:名前、バージョン、認証データ

   g.セキュリティキー:VMからXtract Liteへの通信をセキュリティで保護するために添付された
   動的に作成されたキー

VMの準備のウィンドウが表示

7.VMを自動的に準備させるには[自動]を選択

8.手動でマイグレーション準備のソフトウェアをダウンロードして実行するために、[手動]を選択してからそれぞれのソースのEC2インスタンスでVMの準備を提供しているスクリプトを実行。このスクリプトは、次のインストールを実行してインスタンスを準備します

   a. Nutanix VirtIOドライバーのインストール

   b. CBTドライバのインストール

   c. Python 3.4のインストール

   d. Xtract-Liteとの接続を確立するためのSalt Minion インストール

9.ネットワーク設定のフィールドに入力して、次へをクリック

   a.ターゲットネットワークを選択

   b.データシーディングのスケジュール:チェックボックスを オンにして、移行する日時を選択

10.VMのマイグレーションのサマリを確認

   a.情報を編集するには、[戻る]をクリック

   b.マイグレーションプランを保存するには、[保存]をクリック

   c.マイグレーションプランを保存してすぐに移行を開始するには[保存して開始 ]をクリック。
   マイグレーションのための
データ配置処理が開始します。マイグレーションプランの [ステータス]
   選択してこの情報を監視
可能

19. Automatic VM Preparation(自動VM準備)

EC2上のWindows VMを自動的に準備する機能を提供し,事前にWinRMを有効にしてポート利用できるようにします。

1.VM PreparationにおいてAutomaticを選択

2.ソースVMの認証情報のフィールドに入力し、[次へ]をクリックします。

   a.ゲスト仮想マシンのユーザー名とパスワードを入力して、Xtractが必要な
   ドライバーをインストールできるようにします。

   b.認証にプライベート(PEM)ファイルを使用する:Xtractが必要なドライバを
   インストールできるように、Linux VMにユーザー名とパスワードの代わりに
   キーを使用するには、認証にプライベート(PEM)ファイルを使用チェック
   ボックスをオンにします。

   c.個々のVM設定を上書きする:個々のVMに対して同じ設定を上書きします。
   個々のVMのユーザー名とパスワードを更新したり、不要なVMを削除したりする
   こともできます。

VMの認証情報が検証されます。検証が成功すると、ゲストツール マイグレーションプランのすべてのVMにダウンロードされ、インストール されます。その後、VM Preparation整っているかどうかが検証されます

20. WinRMの有効化

WinRMを有効にしてWindows EC2インスタンスにゲストツールをインストール

1.Windows VMでPowerShellを開きます。

2.スクリプトを実行して、EC2 Windowsインスタンスに対してWinRMを有効にします

>winrm quickconfig -q

winrm set winrm/config/winrs '@{MaxMemoryPerShellMB="300"}'

winrm set winrm/config '@{MaxTimeoutms="1800000"}'

winrm set winrm/config/service '@{AllowUnencrypted="true"}'

winrm set winrm/config/service/auth '@{Basic="true"}'

netsh advfirewall firewall add rule name="WinRM 5985" protocol=TCP dir=in localport=5985 action=allow

netsh advfirewall firewall add rule name="WinRM 5986" protocol=TCP dir=in localport=5986 action=allow

net stop winrm

cmd /c 'sc config winrm start= auto'

net start winrm

3. スクリプトを実行してSecure Sockets Layer(SSL)を有効にします。

>$c = New-SelfSignedCertificate -DnsName "$(hostname)" -CertStoreLocation

cert:\LocalMachine\My winrm create winrm/config/Listener?Address=*+Transport=HTTPS"@{Hostname=`"$(hostname)`";CertificateThumbprint=`"$($c.ThumbPrint)`"}"

21. マイグレーションプランの管理

基本的なアクション

  • Start すでに作成されている移行計画を開始します。ステータスがに変わります。検証計画そしてそれから 移行中。移行が完了すると、ステータスはに変わります。移行が完了しました
  • Pause 進行中の移行を一時停止します。ステータスがに変わります。移行が一時停止しました。このオプションは、移行計画を開始した後にのみ使用できます。移行が一時停止されると、移行を再開、中止、または削除可能
  • Resume 一時停止した移行を再開します。このオプションは、移行計画を一時停止した後にのみ使用可能
  • Abort マイグレーションをキャンセルします。ステータスがマイグレーション中止に変わり、その後マイグレーションのキャンセルに変更になります。マイグレーションがキャンセルされると、マイグレーションプランを削除することしかできず、そのマイグレーションプランに対して他のアクションを実行することはできません
  • Edit 既存のマイグレーションプランを更新します
  • Delete 既存のマイグレーションプランを削除します

22. マイグレーションカットオーバーの実行

f:id:t_komiya:20190114193948p:plain

23. 大規模データのマイグレーション

f:id:t_komiya:20190114194209p:plain

こちらはNutanixのSupport Portalに掲載されている情報になります。参考情報までに

 

最後にHyper-VにおけるXtractのアーキテクチャの情報を載せておきます。こちらも次のリリースで出てくる機能となります。

f:id:t_komiya:20190114194520p:plain

こちらのアーキテクチャはXtract-Liteではなく、Xtract Agentをソース側に導入してターゲット側からデータを取得する内容となります。

 

AHVへの仮想マシン移行時に是非試してみてはいかがでしょうか。

 

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

 

 

1年ぶりのLTS対応AOS5.10 とその追加機能のご紹介~AOS5.10の機能紹介~

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。

本日は昨年12月にリリースされたAOS 5.10の機能紹介をしたいと思います。AOS5.9がリリースされて3か月も経過していないのに、もう新しいAOS5.10がリリースされるの?と思われる方もいらっしゃるかと思います。NutanixのソフトウェアはLTS(Long Time Support)とSTS(Short Time Support)の二つ分かれて、LTSは1年おきのリリースでアナウンスされることになっており、12月はちょうど1年前にAOS5.5がリリースされた時期ということもあり、今回のリリースになっているわけです。

AOSのリリース時期については、以下のイメージでつかんで頂ければと思います。

f:id:t_komiya:20190107211115p:plain

昨年11月にLTSとSTSの記事は投稿しておりますが、改めてアップデートしたいと思います。

blog.lenovojp.com

 

今回のAOSの5.10がリリースされたことにより、LTSのサポートされる期間が2020年3月まで延びることになりました。AOS5.5のメンテナンスサポートが2019年4月で終了することから、リリースを待ち望んでいた人も多いと思います。メーカー各社のサポートを見て是非アップデートをお願いします。詳細は以下に掲載いたします。

f:id:t_komiya:20190107212231p:plain

f:id:t_komiya:20190107212326p:plain

f:id:t_komiya:20190107212425p:plain

一点だけ注意事項として、AOSのアップグレードパスについてです。

すべてのバージョンから最新版であるAOS5.10にアップグレードできるわけではありません。是非アップグレード前にNutanixのサポートポータル上のアップグレードパスをご参照ください。バージョンによっては2段階のアップグレードが必要になります。

f:id:t_komiya:20190107212644p:plain

 

AOS5.10で追加された機能について

XI Leap対応

f:id:t_komiya:20190107212934p:plain

AOS5.10からXi Leap(Nutanixのクラウドサービス)の接続が可能になりました。

今回はこちらのスライドでDRaaSとしての紹介を軽くしておきますが、今後Xi Leapについてはブログの中でもう少し具体的に紹介させて頂きたいと思います。

Autonomous Extend Store - AES

f:id:t_komiya:20190107213516p:plain

自律的なエクステントストアということですが、要するにランダムライトのパフォーマンスを向上するために、データパスの改善を行っています。今後の大容量化に向けてのメタデータ管理方法を変えてことが今回の狙いになります。(他のノードのCassandraのやりとりが軽減されている)

f:id:t_komiya:20190107214145p:plain

f:id:t_komiya:20190107214233p:plain

詳細は以上のイメージをご参照下さい。これを導入するとどのくらいの効果があるのか?というと・・・Nutanixの.NEXTでの資料を見たところでは20%程度向上しているようです。ポイントを以下に記載しておきます。

主な改善点

持続的なランダム書き込みを改善

  • IOPS Cliff解消
  • 低耐久性SSDの使用を可能にする

高容量のストレージノードのサポート

  • ノードあたり300TB以上

ローカライズされたバックグラウンドデータ管理

  • ローカルノードのILM、重複排除、変換

そんなAESについてですが、良いことばかりではありません。現状の制限事項もございますので、併せて掲載させて頂きます。

f:id:t_komiya:20190107214915p:plain

ここでのポイントですが、ALL Flashのみで利用可能であることとSSDやNVMeの搭載本数に制限があることです。今後のソフトウェアのアップグレードでこちらは解消されますが、すべてが反映されるのはしばらく先の話になります。

また、NXシリーズ以外は各社の認定ファームウェアの確認が必要となります。

Never Schedule Node

f:id:t_komiya:20190107215224p:plain

スケジュール不可ノードと記載がありますが、実際にはストレージ専用ノードと同様のことを記載しております。今まで各社のNutanixのハードウェアでストレージ専用ノードが存在していたかと思いますが、それが任意のシリーズでストレージ専用ノードとして利用することができるようになります。アプリケーションのライセンスを意識する場合には特に有効的になると思います。

また、Nutanixクラスタのデータストレージを増やすためにノードを追加したいが、そのノード上でAHVのVMを実行したくない場合は、スケジュール不可能ノードを追加できます。 AOSは新しいVMの展開時、あるホストから別のホストへのVMの移行中(ホスト障害の場合)、またはその他のVM操作中にかかわらず、スケジュール不可能ノード上のVMをスケジュールすることはありません。 したがって、スケジュール不可能なノード構成では、NutanixクラスタからCPUなどの追加のコンピュートリソースが消費されることはありません。

Disaster Recovery Orchestration

f:id:t_komiya:20190107220948p:plain

PrismでDRのオーケストレーションができるようになっています。DRサイト構築(今回はXi Leap上も含めて)時に仮想マシンの復旧できるシナリオを想定しておかなければならない場合に、そのテストも含めてできるようにするのがこの機能です。以前NearSyncをご紹介したときに出てきたRunBookと同様です。

その他のサポート機能について

f:id:t_komiya:20190107221412p:plain

AOS 5.10についてはほとんどがバグフィックスになりますが、そのほかにサポートされたのがこちらになります。vGPUについては、HAが今まで(AHVで)サポートしていなかったのですが、今回ベストエフォートのモードでのみサポートがされることになります。ベストエフォートモードを忘れてしまった方のために、リンクをつけておきます。blog.lenovojp.com

 

 

2019年1月7日時点でAOS 5.10も2回アップデートがかかっているため、是非プラットフォームがサポートされた段階で機能を試してみてはいかがでしょうか。

(今までAOS 5.6 - 5.9の機能も今回試すことができます)

 

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

IoTエッジやマイクロデータセンターの展開や運用を容易にする「Project Dimension」について

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日は今年のVMworldやvForumでも話題となりました「Project Dimension」について少しお話したいと思います。(今回の情報はインターネット上の公開情報+α程度のもので、詳細な説明は追ってさせて頂きたいと思います。

こちらのProject Dimensionですが、vSphereのHCIベースのコンピュートシステムとIoTエッジ/マイクロデータセンターの設置や運用を代行するサービスになります。これだけ聞くと大規模のシステムが必要になると思われますが、通常の3台のvSANのシステムから展開できるような、シンプルな構成で実現できます。

Project Domensionの説明を行う前に、まずはVMwareが提供するハイブリッドクラウドについて軽く説明したいと思います。

f:id:t_komiya:20181223160008p:plain

VMwareのクラウドのビジョンは従来型のプライベートクラウドと今回東京リージョンも開設したAWSとのハイブリットクラウドまででしたが、2018年になり大きく異なってきたのがエッジコンピューティングにフォーカスが当たってきたことです。2020年を見据えたオリンピックなどで高解像度のビデオ画像のリアルタイムのAI連携をはじめととしたエッジとクラウド・データセンターでは対応できないものが多くなってきている。そのために高速なネットワーク接続なども必要となるわけですが、エッジまでの伝送スピードも携帯の5Gなどの出現により広帯域のネットワークが出来上がるもの実現する一つのきっかけになります。

また、これらの構成を一つずつ手作りして提供するのではなく、サービスとして提供することにより、少しでも迅速なサービス展開(エッジ側にもコンピュートノードを設置)できるものを考えており、それらを一括で稼働状況も含めて管理できるようなものを考慮されております。現状提供予定しているベンダーとしてLenovoとDELL EMCの2社を予定しています。基本構成としては、VCF(VMware Cloud Foundation)が採用されることになります。

 

f:id:t_komiya:20181223164038p:plain

 ここで、エッジコンピューティングに必要な環境についてお話したいと思います。今までハイブリッドクラウドということで、オンプレミスのデータセンター・サービスプロバイダーやパブリッククラウドなどが挙げられますが、今回初めて登場するエッジについてもう細かく見ると、エッジコンピューティングはそれぞれの業種で異なる用途利用されます。製造業などで生産された商品データや小売業などでは、商品の売り上げデータなど様々なデータが日々生み出されます。俊敏なビジネスの変化ついていくために膨大なデータの活用をハイブリッドクラウド環境で利用する場合に、今まで通りにエッジ側の設備投資などでお金と時間をかける必要があるのでしょうか。

f:id:t_komiya:20181223165742p:plain

それらの生み出されたデータは膨大なデータとなり、分析することでリアルタイムの意思決定に必要なデータとして利用され、今後のビジネスの継続性にもつながりますf:id:t_komiya:20181223170411p:plain

このような構成が5Gのネットワークのインフラが整った場合にどのようになると思いますか?エッジ側で生成されるデータをオンプレのデータセンターやパブリッククラウドなどに転送しても遅延なども含めて問題ないような インフラが出来上がります。そのときに、ハイブリッドクラウドは場所では一つのビジネスケースとして取れることができ、ビジネスの変化にも柔軟に対応できるようになります。

f:id:t_komiya:20181223205407p:plain

ここでProject Dimensionの概要をお話したいと思います。ハイブリッドクラウド側を管理するVMwareとして、VCFのプラットフォームを利用します。ハイブリッドクラウドのコントロールプレーンとして、ゼロタッチプロビジョニングやローリングアップグレードなどの柔軟な管理とポリシー決め・セキュリティなども含まれております。VMware Cloudから各IoTのエッジのサイトに接続しデータの収集・連携を行います。

f:id:t_komiya:20181223212340p:plain

今回レノボがProject DimensionでVMwareと提供する部分についてですが、データセンター部分で提供されるハイパーコンバージドアプライアンスが対象になります。これだけならほかのメーカーでもできるのではと思いますが、実はエッジサイトからのデータの連携する部分においてもレノボが開発する部分があります。こちらの詳細は公開可能になった段階でお話させて頂きたいと思います。

f:id:t_komiya:20181223212903p:plain

イメージとしてこんな感じになると思います。データセンターの設備でエッジ側のそれぞれにサイトにおける規模を選択し、SLAを設定しそれぞれの拠点にポリシーを配信します。

f:id:t_komiya:20181223213114p:plain

設定された情報を元に各拠点からVMware Cloud上の管理サーバにデータの収集を行います。これを実現するプラットフォームがすなわちProject Dimensionになります。

f:id:t_komiya:20181223213450p:plain

提供するコンポーネントはこのようなイメージになると思います。ここでポイントになるのは、エッジ側のネットワークのプロビジョニングで利用されるのは、SD-WANソリューションになるVelocloudになります。Velocloudを利用することで1クリックでエッジ側のネットワーク情報を生成および配信までを実現し、VMware Cloudのネットワークを簡素化するソリューションとして利用されます。(物理スイッチは冗長化である必要は無いようです)

 

参考までに見て頂けれると幸いです。

 

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

データベース運用をワンクリック操作と自動化、複雑なコピーデータ管理を簡素化するソリューションNutanix Eraのご紹介

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。

本日は長いタイトルになっていますが、Nutanix Eraをご紹介したいと思います。

こちらの内容につきましては、Nutanix様からのドキュメントをベースに掲載させて頂いております。

まずNutanix Eraについて説明します。Nutanix EraはNutanixの純粋なソフトウェアではなくPaaSサービスになります。こちらの製品はデータベースの運用をを効率化および自動化するもので、データベースの管理者が日ごろのデータベースの管理から解放されて戦略的な仕事で専念できるようにするソリューションです。

こちらは、Nutanixの特徴であるワンクリックのシンプルな運用をそのまま受け継いでシンプルな操作でデータベースの運用(プロビジョニングなど)が可能になっています。それ以外にもコピーデータ管理(Copy Data Management)の機能も含まれておりデータベースのコピーデータの運用管理やコスト増からの負担を軽減します

 

1.データベース運用における課題

1.1 プロビジョニング

f:id:t_komiya:20181220013102p:plain

 

IDCの2016年のコピーデータ管理(CDM)レポートによると、調査対象組織の77%が200を超えるデータベースインスタンスを持ち、82%が各インスタンスを10以上コピーを行っています。典型的なデータベース管理者(DBA)は、2,000データベースインスタンスに対して他のデータベース操作をプロビジョニング、管理、リフレッシュ、リストアおよび実行する必要があります。これらのすべてのインスタンスを管理することの複雑さと時間のかかる問題は、データベースがさまざまなレガシーソフトウェアとハ​​ードウェアテクノロジで実行されている場合、さらに悪化します。

各データベースをプロビジョニングするには、コンピューティングを単一の仮想マシンまたはクラスタ内の複数の仮想マシンとして構成するなどの考慮が必要です。ストレージプロビジョニングでは、データファイル、ソフトウェア、オンラインログ、ログファイル、ローカルバックアップなど、さまざまな種類のデータベースデータを処理するために、複数のディスクグループが必要になることがあります。DBAが計算とストレージを識別し、データベースソフトウェアのインストールから始まります。クラスタシステムでは、追加コンポーネントのインストール、構成、およびテストが必要です。また、DBAは、異なるバックアップソフトウェアやハードウェアテクノロジとの統合を必要とするバックアップポリシーを構成することによって、データベースを保護する必要がありますf:id:t_komiya:20181220013545p:plain

データベースのリクエストから始まります(このリクエストはDev、Test、QA、Analyticsチームなどから来る可能性があります)。リクエストはデータベースに送信されます。adminはデータベースのバージョンやサイズなどを調べ、クラスタを作成するためのインフラストラクチャーを提供しています。

インフラ整備が完了したらDBA管理者はプロビジョニング・プロセスを開始します。データベースサーバーと構成のセットアップと最後にデータベースの作成をします。

データベースが作成されると、DBAはプロシージャの一部としてデータベースを保護する必要があります。そして最後に、Dev / Testチームが設定されたデータベースを取得します。

このプロセスでは多くのハンドオフと担当者間のやり取りがあります。したがって、場合によってはユニットによってDevチームがデータベースを取得します。

このケースでは数日のプロセスになって、複数チームとの連携で複雑なプロセスになりがちです。

 

1.2. コピーデータ管理

f:id:t_komiya:20181220014320p:plain

クローニングとデータリフレッシュプロセスも複雑です。クローン作成には、クローン作成に必要なログファイルとともにバックアップセットの識別が必要です。DBの管理者は、まずバックアップ(テープまたはセカンダリ・ソース)を見つけてから、データベース・サーバーの設定、データベースへの接続、データベース・バックアップのリストア、最後に特定の時間までのデータベース・ログの再生などの複雑なリカバリ・プロセスを実行する必要があります。次に、DBの管理者は、これらのデータベース・コピーとクローンをすべてソース・データで定期的にリフレッシュして有用にする必要があります。今、組織内のさまざまなグループ(テスト/開発者、BI、QAなど)をサポートするために、何百ものデータベースへの努力を拡大することを考えてみてみましょう。

f:id:t_komiya:20181220014743p:plain

ここでは、組織内の典型的なデータベース管理プラクティスのスナップショットを示します。 運用データベースから開始します。その後、本番データベースを保護してバックアップするためのデータベースコピーが作成されます。 そのデータベースのコピーは、レポート(BI)、テスト/開発、および品質保証(QA)チームなど、組織内のさまざまなグループによって消費されるように複製されます。現在、これらのデータベースはすべて管理する必要があります。

複雑性

・複数のSWおよびHW技術への統合

・専門のITリソースの必要性

・断片化されているサイロ化された環境

非効率的運用

・ストレージの使用

・DBプロビジョニング

・DBのリストア、リカバリ操作

IDCの調査では、日次にリフレッシュされるデータ32%、週次にリフレッシュされるデータが40%、開発/テストまたは分析用に使用されたコピーをリフレッシュされると言われています。

 

.Nutanix Eraを導入すると・・・

f:id:t_komiya:20181220020042p:plainf:id:t_komiya:20181220015509p:plain

Nutanix Eraはデータベース管理を自動化および簡素化し、ワンクリックでシンプルな操作と不可視な操作をデータベースのプロビジョニングとライフサイクル管理(L​​CM)にもたらすソフトウェアです。Nutanix Eraは、最初のオファリングとしてCopy Data Management(CDM)を始めとして、データベース管理者が任意の時点でデータベースのプロビジョニング、複製、更新、およびリストアを行うことができます。リッチで使いやすいUIやCLIにより、最新のアプリケーション一貫性のあるトランザクションに復元できます。

f:id:t_komiya:20181220020252p:plain

実際にどのくらいの時間が短縮できるのかをこちらの資料で見てみましょう。通常のプロセスであれば、リクエストを受けてからサーバー担当者の環境構築などを経て、DB管理者が再度構築するまでに約2週間から4週間程度を要します。

それがEraを利用することで、わずか数分の作業ですべてが完了します。そのため、作業のスピードアップが図ることができ、大幅なコスト削減を行うことができます。

 

f:id:t_komiya:20181220021129p:plain

f:id:t_komiya:20181220021436p:plain

f:id:t_komiya:20181220021557p:plain

Nutanix Eraは、データベース操作の複雑さを隠し、複数のデータベースエンジンに共通のAPI、CLI、およびGUIを提供します。

Nutanix Eraを使用すると、DB管理者は、データベースのプロビジョニングニーズの基準を定義し、ミッションクリティカルなクラスタ、HAデータベースの展開を含む最終状態のプロビジョニング機能を提供できます。

Eraプロビジョニングサービスには、 以下のものが含まれます

・エンタープライズニーズに合わせてカスタマイズされたカスタムソフトウェアイメージ(PSUとワンオフパッチ)

・Pre/Post DBスクリプト挿入を作成する

・複雑なHA環境のサポート(Oracle RACなど)

・洗練されたSLA(継続的、毎日、毎月のRPO)

・ビジネス要件に基づいた定義済み/カスタマイズ可能なSLA

 

Nutanix Eraのコピーデータ・サービスf:id:t_komiya:20181220021945p:plain

コピーデータ管理の話をする前に、まずはコピーデータについてご説明します。コピーデータとはデータセンター全体に分散された同じデータの複数コピーです。つまり、本番用のデータを実際に開発用・テスト用などに利用したいケースがありますが、それぞれで環境で同じデータを物理コピーしないで1つの本番データと差分管理でコピーデータを仮想化できるのでコピーにかかる容量や時間を大幅に削減できます

このコピーデータを任意の時間に戻すことがEraの機能でできるようになっています。それがこのタイムマシン機能と言われる機能になります。

 

3.1. タイムマシン機能

タイムマシン機能は、スケジュールで定義されているソースデータベースのスナップショットとトランザクションログをキャプチャして管理します。Nutanix Eraに登録するすべてのソースデータベースについて、そのソースデータベース用のタイムマシンが作成されます。特定の時点(トランザクションログを使用)またはスナップショットを使用してクローンを作成し、クローンを更新します。

f:id:t_komiya:20181220024034p:plain

タイムマシン機能を実現する上で任意の時間に戻す際に必要なのはデータベースとその時のトランザクションログになります。つまり該当時間のトランザクションがわかっていれば任意の時間に戻せるわけですが、トランザクションを永久に持つことは容量的にも厳しい(オブジェクトストレージのようなものがあれば話は別)と思いますので、二日次ベースで1週間程度は任意の時間に戻れるようにします。これをタイムマシン機能と呼んでいます。

f:id:t_komiya:20181220024100p:plain

トランザクションログとデータベースを突き合わせて出来上がったデータをポイント・イン・タイム・リカバリと呼び、このデータが開発用もしくはテストなどに利用されます。

f:id:t_komiya:20181220023724p:plain

また、週次以上前のデータについては、トランザクションではなく、スナップショットをベースにリカバリを行います。このようにすることで、直近データは任意の時間、週次・月次以上前のデータについてはスナップショットで戻します。

f:id:t_komiya:20181220025611p:plain

クローンは、特定の時点(トランザクションログを使用して)またはスナップショットを使用して作成します。スナップショットを使用してソースデータベースを複製する場合は、使用可能なスナップショットを選択し、ソースデータベースをスナップショットが取得された時点の状態に複製します。特定の時点でソースデータベースを複製する場合は、クローン時間を選択し、ソースデータベースはその時点の状態に複製されます。

クローンのリフレッシュはクローンデータベースをソースデータベースの最新の状態に更新することができます。特定の時点(トランザクションログを使用)またはスナップショットを使用して、データベースクローンを更新します。

 

ここからはデモ画面のイメージを掲載いたします。

 

f:id:t_komiya:20181220030418p:plain

こちらの画面では以下の内容が表示されております。

  • 本番環境のソース データベース数
  • クローンデータベース数
  • データ容量の削減率

f:id:t_komiya:20181220135033p:plain

こちらの画面はSLAの画面になります。CreateボタンをクリックしてSLA作成画面になります。

f:id:t_komiya:20181220134050p:plain

サービスレベルはGold、Silver、Bronzeの3種類で表示されます。

それぞれのSLAは以上のような規定になっています。

f:id:t_komiya:20181220140725p:plain

プロファイルとして以下の設定が可能です。

  • データベースエンジン毎の標準カタログ(Oracle/Postgres/MySQL/SQLServer)
  • 仮想マシンのサイズ (vCPU、メモリ容量)

f:id:t_komiya:20181220141035p:plain

  • データベースエンジン毎のネットワーク設定
  • データベースエンジン毎のデータベースパラメータ

f:id:t_komiya:20181220142113p:plain

f:id:t_komiya:20181220142157p:plain

f:id:t_komiya:20181220142237p:plain

作成したデータベースの一覧を確認することができます。

  • Overviewではサポートしているデータベースエンジンの一覧
  • Sourcesは登録済の ソースデータベースの一覧
  • Clonesはクローンされたデータベース一覧

f:id:t_komiya:20181220143121p:plainソースDBの登録画面になります。

1.Sourcesを選択し Register ボタンをクリック

f:id:t_komiya:20181220143421p:plain

2.データベースエンジンとして(今回は)Oracleを選択

3.データベースサーバに必要な パラメータを入力

f:id:t_komiya:20181220144212p:plain

4.データベース名、SIDを入力

5.タイムマシンのための スケジュールを設定

6.Registerボタンをクリック

f:id:t_komiya:20181220144659p:plain

7.Operationsページに移動して 登録状況画面を表示

f:id:t_komiya:20181220151848p:plain

データベースのプロビジョニング画面になります

1.Sourcesを選択し、Provisonボタンをクリック

f:id:t_komiya:20181220152003p:plain

2.データベースエンジンとしてOracle、 タイプはCluster Database、ノード数は2を選択

3.データベースサーバに必要なパラメータを入力

f:id:t_komiya:20181220152221p:plain

4.データベース名、SID、SYS/SYSTEMのパスワードを入力

5.タイムマシンのためのスケジュールを 設定

6.Provisionボタンをクリック

f:id:t_komiya:20181220152338p:plain

7.Operationsページに移動して プロビジョニングの状況画面を表示

f:id:t_komiya:20181220154500p:plain

1.Timemachinesページに移動して、「CRM_DB_TM」をクリック

f:id:t_komiya:20181220154625p:plain

2.タイムマシンのGUI画面

緑はログによるポイント・イン・タイム・ リカバリが可能な期間。青は日次、紫は週次で保持している期間を示します

3.左上のCloneボタンをクリック

f:id:t_komiya:20181220154808p:plain

4.右上のDayボタンをクリック

5.クローンする任意の時点を選択して、Next ボタンをクリック

f:id:t_komiya:20181220154956p:plain

6.VM Nameを入力して、Nextボタンを クリック

7.名前、Oracle SID、SYS/SYSTMEの パスワードを入力してCloneボタンを クリック

f:id:t_komiya:20181220155054p:plain

8.Operationsページに移動してクローンの 状況画面を表示

f:id:t_komiya:20181220155705p:plain

1.Databasesページに移動して左のパネルからClonesを選択して、「CRM_DB_Dev-1」をクリック

f:id:t_komiya:20181220160047p:plain

2.Refreshボタンをクリック

3.右上のDayボタンをクリック

4.Refreshする任意の時点を選択して、Refreshボタンをクリック

f:id:t_komiya:20181220160145p:plain

5.Operationsページに移動して リフレッシュの状況画面を表示

f:id:t_komiya:20181220160459p:plain

REST APIの設定項目画面になります

f:id:t_komiya:20181220160636p:plain

DBへの全オペレーションを可視化することができます。

 

最後にNutanix Eraについてまとめます。

 

  • Nutanix Eraによってデータベースのコピーデータ管理に伴う 複雑化する運用管理と増加するコスト負担を軽減
  • 1Clickデータベースプロビジョニング
  • タイムマシン機能によるデータベースのクローン、リフレッシュ、リカバリ運用の簡素化

是非一度利用してみてはいかがでしょうか。

よろしくお願いします。

LCM(Life Cycle Management)について

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。

本日はLCM(Life Cycle Management)についてお話したいと思います。

まずは、LCMとは何か?ということをお話します。LCMの役割はNutanixのクラスタ内のすべてのエンティティ(構成要素)のソフトウェアとファームウェアのバージョンを管理するものです。単にファームウェアを管理するだけなら普通にできるのではと思いますが、これが重要なのはNutanixで特徴である1クリックアップグレードの要素の一つになっています。つまり1クリックアップグレードはこのLCMの機能で成り立っているといっても過言ではありません。

ではその仕組みについて、説明していきたいと思います。

f:id:t_komiya:20181213012110p:plain

従来型の1クリックアップグレードはAOSをアップグレードする際に、アップグレードするタイプを選択し、メタデータとイメージをアップロードします。その後アップデートをクリックするとアップグレードは始まります。

今まではNutanix単独のいプラットフォームだけだったので、これでよかったのですが、今後は他のハードウェアベンダーや様々なデバイスが出てくることもあり、それらのプラットフォームにも1クリックアップグレードが対応する必要があります。

そのために、LCMのインターフェースを変更するがあります。

f:id:t_komiya:20181213025902p:plain

こちらのイメージはNutanixをご存じな方は見たことがあると思いますが、今後Nutanixは様々な規模での展開、プラットフォーム、アップグレードする要素が多様化することを示しています。

これらを今までアップグレードするときにはそれぞれ個別のオペレーションが必要であり、依存性も管理されておらず、中にはパフォーマンスに悪影響を及ぼすものもあります。

f:id:t_komiya:20181213030221p:plain

例えば、Linuxなどを例に挙げてみると、パッケージをアップデートする際にはyumコマンドで一発でできるようになっています。これがNutanixの場合はどうなっているのか?GUIで1クリックでアップデートできるようになっているのがNutanixユーザの理想だと思います。

f:id:t_komiya:20181213083623p:plain

こちらはPRISM上のLife Cycle Managementの画面をキャプチャしたものです。GUIでアップデート可能で、これが1クリックアップグレードできるようになれば良いことです。

f:id:t_komiya:20181213083857p:plain

f:id:t_komiya:20181213084527p:plain

f:id:t_komiya:20181213084744p:plain

LCMのアーキテクチャを図式化してみました。こちらはNXをベースにしております。AOS、ハイパーバイザーおよびその他の機能がLCMとクラスタ内のCVMが連携して(ローリング)アップデートを行います。もちろん、こちらはPRISM Centralからもアップデートが可能になっています。

f:id:t_komiya:20181213084221p:plain

f:id:t_komiya:20181213084610p:plain

LCMのRepositoryの構造になります。アップデートを行う際にアップデート対象のリストが必要になります。そのリストをもとにどのモジュールをアップデートするのかということでリストに書かれたモジュールをアップデートする際にダウンロードを行います。AOS、AHVなどの関連モジュール以外にそれぞれのハードウェアメーカー毎のモジュールもダウンロードします。

f:id:t_komiya:20181213084835p:plain

現状のLCMの機能について、最後にコメントします。

現状は複数社のハードウェアにも対応しています。LenovoのHXもその対象ですが、一部の機種はまだ未対応のものがあります。(近日対応予定)また、このLCMでアップデートする際に、他のホストに仮想マシンをvMotionしたり、ローリングアップグレードで各ホストを再起動してくれます。

また、複数のコンポーネントが選択されている場合はその依存関係もチェックした上で正しい更新順序でアップグレードを行います。

ダークサイト(インターネットがつながらない環境)下でもアップグレードできるようにインタフェースを持っています。(オフラインでのアップグレード)

 

是非試してみてはいかがでしょうか。検証環境をお持ちの方は気軽にやってみましょう。

 

よろしくお願いします。

Lenovo ThinkAgile HX for SAP HANA アップデート情報

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。

本日は以前にも話題で取り上げたThinkAgile HX for SAP HANAのアップデート情報を掲載します。構成組むうえで重要な情報を記載致しますので、参考にして頂ければと思います。

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

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

f:id:t_komiya:20181205233612p:plain

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

 

2. AHV Turboについて

f:id:t_komiya:20181205233801p:plain

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

f:id:t_komiya:20181205233908p:plain

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

f:id:t_komiya:20181205234039p:plain

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

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

f:id:t_komiya:20181205234147p:plain

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

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

f:id:t_komiya:20181205234324p:plain

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

f:id:t_komiya:20181205234505p:plain

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

f:id:t_komiya:20181205234616p:plain

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

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

SAP 導入後の運用者の悩み事について

①SAPのクリティカルな問題として、本番環境開発環境での 自己修復、稼働時間、データ保護とリカバリにフォーカスが 置かれています
  • 本番環境の生産性の低下は収益の損失と顧客からの信頼を失います
  • 開発環境がダウンすると開発者の生産性を失うことになります
SAPのお客様はピーク時を想定して定常状態のリソースをオーバーサイジングします③SAPのお客様は新しいSAPランドスケープの導入やサービス カタログの欠如に多くの時間と労力をかけている
④SAPのお客様は実装が簡単でコスト効率の高い開発/テストおよびディザスタリカバリのソリューションを求めています
⑤無秩序にサーバが増えることが問題になっています

これらを解決するためにSAP環境を仮想化していくことが重要になりますが、しかしそこには様々な障害が存在します。

 

SAPのランドスケープはますます複雑化

  • ビジネスとITの要件のバランスを取る必要がある
  • 2025年までにSAP HANAへの移行に伴い、管理コストが高く未使用のシステムが多数変化してきている

ハイパーバイザーがスケールアップ可能

  • より強力なコアとソケットあたりのコア数の増加により、仮想化は実行可能なオプションになります

簡素化された導入と高可用性

  • 仮想化されたクラスタがアプリケーションを意識している

 

これらを解決するにはSAP HANAがNutanixに対応していれば解決するのではないかと考える方もいらっしゃるかと思います。実はそのきっかけになる話があります。

f:id:t_komiya:20181206000103p:plain

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

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

f:id:t_komiya:20181206000246p:plain

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

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

f:id:t_komiya:20181206000516p:plain

実は、NutanixのAHVが最初にSAP HANAの認定を受けたHCIのプラットフォームになります。

ここで、SAP HANAにおけるソリューションのポジショニングを整理しておきます。

f:id:t_komiya:20181206001104p:plain

Nutanix対応のSAP HANAのお話する前にLenovoが提供するSAP HANAソリューションは上図になります。TDI(Traditional Datacenter Infrastructure)は通常のカスタムベースの構成になります。一番構成として出しやすいです。アプライアンスについては構成としては決められているモデルになります。こちらのモデルについては、Lenovoは一番出荷量が多いモデルになります。仮想化された環境という意味では、今まではVMwareのみが対応していましたが、残念ながらHCIには未対応の状況でした。それが今回AHVに対応になったのが、今回紹介のモデルになります。(11月にはvSANやSimplivityもSAP HANAになっています)

f:id:t_komiya:20181206000804p:plain

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

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

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

CPUについては、メモリ構成上で3CPU以上が必須な構成のため、今回のSAP HANA

モデルはLenovo ThinkSystemの4CPUモデルで採用しています。(3TB構成は実際に利用可能なメモリ容量としては2.3TBになります)

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

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

ちなみに、この構成でSAP HANAを組むことによって、AHVでのストレージオーバーサイジングは4%程度に収まっています。通常の場合は1.6倍程度のオーバーサイジングを考慮することが前提のため、この数字は素晴らしい数値になります。(vSANでの構成時は4%にはなりません)

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

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

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

 

4. ThinkAgile HX782xはSAP HANAのために作られたの?

f:id:t_komiya:20181206001604p:plain

先ほど紹介したモデルはSAP HANAにしか対応していないのか?と思う方もいらっしゃるかと思います。実はそうではなく、ブロックチェーンなどのP2Pのネットワークにも利用するできます。ブロックチェーンは一定期間内のトランザクションをつなげ合わせて処理を行っていくものであり、前の人の処理がメモリ上からアクセスできるような環境ができれば、いち早く処理を行えることからインメモリの環境にあるのは非常に最適な環境になるわけです。

f:id:t_komiya:20181206002051p:plain

そのブロックチェーンの基盤を支えるのが、こちらのNUMAのテクノロジーになります。こちらの技術を利用することにより、CPU間で接続されているI/O Controllerを通じて異なるCPUのメモリをアクセスすることができます。これを仮想環境でも利用できるようにするために、vNUMAがサポートされている必要がありますが、現時点ではAHVもVMwareもサポートしています。

 

5. SAP HANA for Nutanixサイジングにおけるちょっとしたコツ

f:id:t_komiya:20181206005629p:plain

f:id:t_komiya:20181206005730p:plain

ThinkAgile HX for SAP HANAにおけるプラットフォームの仕様とクラスタのガイダンスはこちらになります。3ノードが必要なのはNutanixの仕様上の話ですが、HX782xは最低でも2台と他のノードをHX782x以外で組むことはできます。しかしその場合はHAの仕様に制限出てきますので、本番環境で利用する場合にはできれば4ノード以上で構成することを推奨します。

また、先の説明でメモリは2.3TBしか利用できないについてもこちらでご説明したいと思います。

 

6. 3TBのメモリ構成が2.3TBしか利用できない理由とNUMAの関係性について

f:id:t_komiya:20181206010217p:plain

1台の巨大なVMを実装する場合に3つのCPUを利用することはできますが、一つの物理CPUはCVM用に割り当てる必要があり、すべてのメモリ領域を利用できるわけではありません。今までにそこまで大きなメモリ領域を使用することは少ないと思いますが、SAP HANAのようなインメモリデータベースは、会計上のデータなどの通常ストレージに入れるようなデータをメモリ上に展開する関係上、メモリの大容量化が必須になっているため、このようなリソースが必要となります。ハイパーコンバージド環境でSAP HANAを導入される場合は、ストレージリソースでどのくらい消費するのかも考慮しながら設計する必要があります。これは、Nutanixに限らず他のハイパーバイザーにも同様のことが言えます。

 

是非今回の内容を参考にして頂ければと思います。

 

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

 

Nutanixクラスタの正常性の確認について~Health Monitoring~

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。

本日はNutanixの正常性の確認(Health Monitoring)についてご説明したいと思います。

まず、はじめにNutanixの正常性を確認するというが何を見ることができるのか?ということをお話します。

f:id:t_komiya:20181201231034p:plain

モニタリングできるものは仮想マシン、ホスト、ディスクなどの状態を表示、深刻度などを表示します。またスケジューリングして表示したり、Nutanixのクラスタのチェックを定期的に行ったり、ログ収集を行います。

それぞれの機能についての詳細は上図をご参照下さい。

 

それでは、それらについて画面イメージも交えながらお話します。

 

ヘルスダッシュボードには、クラスタ内のVM、ホスト、およびディスクに関する動的に更新された正常性 情報が表示されます。ヘルスダッシュボードを表示するには、メインメニューの左側にあるプルダウンリストから[Health]を選択します。

  • メニューオプション

ヘルスダッシュボードには、メインメニュー以外のメニューオプションはありません。

画面の詳細

ヘルスダッシュボードは3つの列に分かれています。

  • 左側の列には、各エンティティタイプ(VM、ホスト、ディスク、ストレージプール、ストレージコンテナ、クラスタ サービス、および[構成されている場合]保護ドメインとリモートサイト)のタブが表示されます。各タブには、クラスタのエンティティの合計(ディスクの総数など)と各正常性状態の数が表示されます。タブをクリックすると、表示された 情報が展開されます(次のセクションを参照)。
  • 中央の列には、左側の列で選択されているものに関する詳細情報が表示されます。
  • 右側の列には、すべてのヘルスチェックの要約が表示されます。また、チェックボタン(成功、警告、失敗、無効)から個々のチェックを表示するオプションもあります。
  • [ Summary ]タブには、チェックステータスとチェックタイプに従って、すべてのヘルスチェックのSummaryが表示
  • [ Checks ]タブには、個々のチェックに関する情報が表示されます。カーソルを項目の上に移動すると、その ヘルスチェックに関する詳細情報が表示されます(次の図を参照)。適切なフィールドタイプをクリックして[ Apply ]をクリックすると、チェックをフィルタリングできます。チェック内容は以下のように分類されます。
  • ステータスでフィルタリング
    合格(Passed), 失敗(Failed), 警告(Warning), エラー(Error), オフ(Off),またはすべて(all)
  • タイプでフィルタリング

    スケジュールされていない、スケジュールされていない、イベントトリガーされている、またはすべて

  • エンティティタイプ別にフィルタリングする

    VM、ホスト、ディスク、ストレージプール、ストレージコンテナ、クラスタサービス、またはすべて

f:id:t_komiya:20181201232054p:plain
たとえば、Failureをチェックのみを表示する場合は、[ Failure ]オプションを選択してチェックをフィルタします。 特定のチェックをクリックすると、中央の列に、チェックが失敗した日時とチェック失敗の割合の詳細な履歴が 表示されます。バーをクリックすると、合格と失敗の履歴の詳細グラフが表示されます(上図参照)。

マウスをグラフの線に沿って動かすと、その時点に関する情報が表示されます。

 

f:id:t_komiya:20181201232258p:plainまた検索ボックスに文字列を入力することで、特定のチェックを検索することもできます。「Actionタブにはチェックを管理し、チェックを実行し、ログを収集するオプションがあります。

f:id:t_komiya:20181201232412p:plain

フィルタリングもVMやホスト、ディスクなどで行うことができます。

  • グループ化カテゴリをクリックすると、そのグループ化に関する詳細情報が表示されます。左側の列が展開され、グループ化とフィルタオプションのセットが表示されます。選択したグループが強調表示されます。そのグループをクリックすると、別のグループを選択できます。各グループエントリには、そのグループに含まれるカテゴリの数が表示され、中央のセクションにはそれらのカテゴリに関する情報が表示されます。次の例では、ディスクストレージ階層が選択されており、そのグループには2つのカテゴリ(SSDとHDD)があります。デフォルトでは、すべてのエンティティ(この例ではすべてのディスク)がカテゴリ情報に含まれています。1つまたは複数のフィルタをクリックすると、含まれているリストを絞り込むことができます。
  • 中央の列には、選択したグループ内の各カテゴリのフィールドが表示されます。各フィールドには、そのカテゴリの詳細が表示されます。特定のエントリにカーソルを置くと、追加情報が表示されます。フィルタリング用のドロップダウン選択リスト(グループ化フィルタと同じ)と、情報を並べ替えるためのリストによるドロップダウンソートがあります。
  • 右側の列には、そのエンティティタイプに関連するヘルスチェックが引き続き表示されます。

f:id:t_komiya:20181201232753p:plain

f:id:t_komiya:20181201232912p:plain

それぞれのエンティティについて、ダイアグラムビューで見ることも、それぞれの詳細な情報で出力することもできます。

 

一連のヘルスチェックが定期的に実行され、一連のクラスタヘルスインジケータが提供されます。実行する検査を 指定し、スケジューリング可能な検査および各ヘルスチェックのための他のパラメータを構成することができます。

クラスターヘルスチェックは、AOS、ハイパーバイザー、およびハードウェアコンポーネントを含むさまざまな エンティティをカバーします。チェックのセットはデフォルトで有効になっていますが、いつでもチェックの実行、無効化、または再設定ができます。1つまたは複数のヘルスチェックを再設定するには、次の手順を実行します。

 

1.ヘルスのダッシュボードでは、Action Manage Check クリックします

ヘルスダッシュボードには、ヘルスチェックに関する情報が再表示されます。特定のヘルスチェックをクリックすると、その チェックが強調表示されます。ヘルスチェックを選択するか(最初に選択するか)、以前に選択したヘルスチェックが強調表示されます。次の情報が表示されます。

  • 左側の列には、ハイライトされた状態が正常性チェックの一覧として表示されます。いずれかのエントリをクリックして、そのヘルスチェックを選択して強調表示します。
  • 中央の列には、このヘルスチェックの機能が記載されており、影響を受けるエンティティ(ホスト、ディスク、またはVM)全体で実行スケジュールと履歴が提供されます。
  • 右の列には、このヘルスチェックが失敗した原因(原因、解決、影響)が記載されています。

2.特定のチェックを実行するには、[ Run Check ]をクリックします。

3.ヘルスチェックをオフにする(またはオンにする)には、中央の列の上部にあるチェックオフ(またはチェックオン)リンクをクリックし、ダイアログボックスで[ Yes ]ボタンをクリックします。

4.パラメータの設定を変更するには(設定可能なパラメータがあるヘルスチェックの場合)、中央の列の上部にあるパラメータリンクをクリックし、ドロップダウンウィンドウでパラメータ値の1つ以上を変更して、[ Update ]ボタンをクリックします。このリンクは、ヘルスチェックに設定可能なパラメータが含まれている場合にのみ表示されます。設定可能なパラメータは、そのヘルスチェックに固有です。たとえば、CPU Utilizationヘルスチェックには、ホスト平均CPU使用率のしきい値とホストピークCPU使用率のしきい値の割合を指定するパラメータが含まれています。

f:id:t_komiya:20181201233422p:plain

f:id:t_komiya:20181201233545p:plain

  1. ヘルスチェックを実行するスケジュールを変更するには、中央の列の上部にあるスケジュール可能なチェックの スケジュールリンクをクリックし、ドロップダウンリストから間隔を選択します。1分から48時間までの間隔を選択 できます。各Checkにはデフォルトの間隔があり、ヘルスチェックに応じて1分に1回から1日に1回まで変更可能。 ほとんどの場合、デフォルトの間隔が最適であり間隔を変更することは推奨されません (Nutanixのカスタマーサポートによって要求されない限り)。

f:id:t_komiya:20181201234101p:plain

NCC(Nutanix Cluster Check)の間隔の設定について説明します。

こちらはNutanixのサポートに必要な情報を定期的にNutanixのサポートに送信します。(Pulseで設定します)

設定項目については上図をご参照下さい。 

f:id:t_komiya:20181201234158p:plain

Webコンソールを使用したCheckの実行について説明します。

Prism WebコンソールのHealthダッシュボードからNCCチェックを実行可能です。すべてのチェックを一度に実行するように選択することができます。失敗したチェックや警告を表示したり、選択した特定のチェックを表示したりすることができます。

f:id:t_komiya:20181201234247p:plain

Webコンソールを使用したログの収集について説明します。

Prism Webコンソールのホームダッシュボードから直接ログを収集可能。コントローラVM、ファイルサーバ、ハードウェア、アラート、ハイパーバイザ、およびシステムのログを収集可能。タスクが完了すると、タスクダッシュボードからログバンドルをダウンロード可能です。

 

参考にして頂ければ幸いです。よろしくお願い致します。

Windows Serverで実現するHCI ThinkAgile MXシリーズのご紹介

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。

本日は先日発表されたWindows Serverで実現するHCI 「ThinkAgile MXシリーズ」をご紹介します。

以前にもHCIに関しては、Nutanix社のHCI製品である「ThinkAgile HXシリーズ」やVMware社のvSANアプライアンスの「ThinkAgile VXシリーズ」を紹介してきましたが、今回の「ThinkAgile MX」はMicrosoftのWindows ServerベースのHCIになります。

もう少し詳細に説明すると、以下のようになります。(レノボ プレスリリースページから引用)

ThinkAgile MXシリーズ認定ノードは、Microsoft WSSDソリューションをベースに、事前検証済みハードウェアとファームウェアを構成、Windows Server 2016 Datacenter Editionをプリロードしパッケージ化したレノボおよびMicrosoftで認定したアプライアンスです。ストレージ構成として、フラッシュとHDDを組み合わせたハイブリッド構成と、フラッシュのみで構成されるオールフラッシュ構成を提供します。また、RDMA対応の高速ネットワークアダプターを標準で搭載、WSSDの性能を最大限に引き出す構成です。

f:id:t_komiya:20181123104903p:plain

赤枠で囲っている部分がThinkAgile MXの説明になります)

マイクロソフトの標準ハイパーバイザーであるHyper-Vを使い、Windows ServerのみでベースとなるHCIシステム構築が可能となります。別途、ソフトウェア製品を購入する必要がないため、初期投資を抑え、高い価格性能比のシステム導入が実現します。間もなくサポート終了となるWindows Server 2008から仮想サーバー統合や、中堅・中小企業におけるVDI導入に最適です。

ThinkAgile MXシリーズでは、現行のWindows Server 2016 Data Center Editionに加え、最新のWindows Server 2019 Data Center Editionに対応します。Windows Server 2019では、同社のパブリッククラウドサービスMicrosoft Azureとの連携も大幅に強化され、ThinkAgile MXシリーズを ベースとするハイブリッドクラウド環境の構築が可能となります。Windows Serverのライセンスはオプションとなり、OEMライセンスあるいはMicrosoft認定パートナーより提供されるライセンスを選択頂くことが可能です。

また、ハード、ソフトのテクニカルサポートを一括で提供するThinkAgileアドバンテージサポートは標準で含まれており、導入後のお客様の運用を強力に支援いたします。

 

通常のS2Dとの違いということであれば、ファームウェアの組み合わせ(Lenovoではこの組み合わせをベストレシピと呼ぶ)で検証されたハードウェアの構成により、パーツレベルでの相性も良いアプライアンスになります。そのため、パーツレベルで組み合わせれば単純に構成組んだとしても、ファームウェアの相性が悪ければブルースクリーンなども表示されてしまうこともあります。そのため、レノボでその構成を認定しているものを今回リリースしているわけです。

f:id:t_komiya:20181123105655p:plain

こちらが実際のコンセプトになります。もともとThinkAgile SXMというオンプレのAzureStackをリリースしていたのですが、今回Windows2019のリリースに合わせてS2DベースのHyper-VにおいてもAzure連携可能なプラットフォームにもなっているため、今回のThinkAgile MXシリーズはハイブリッドデータセンターというコンセプトを掲げて製品化しております。もちろん小規模のお客様にも手軽に導入でき、かつクラウドと連携しながら、リソースの有効活用しながら利用することもできます。

実はこのS2DベースのHCIが今一番成長率が高く、今年の3月から9月までの半年間で約50%の成長率になっています。現在注目のHCIと言っても過言ではありません。

f:id:t_komiya:20181123110357p:plain

S2Dに関してですが、Windows2012からベースの技術はありましたが、HCIの利用としてはWindows2016からになっています。しかしながら、Windows2016の時はHCIとしての機能はあったものの冗長性に関しては他社に比べて劣る部分があり、その点は改善してきました。(詳細な説明は今後ブログで紹介するかもしれません)

それに加えて今回は2ノード構成についてもプラスの要素がありますので、それは後程ご説明致します。

f:id:t_komiya:20181123111309p:plain

ここでS2Dのメリットをまとめてみました。

売り文句は費用対効果の高いストレージということです。ハイパフォーマンスということを売りにしているのですが、ストレージデバイスやネットワーク機器については日進月歩でテクノロジーが進化していきます。ソフトウェアでアーキテクチャを開発しなくても、高速ハードウェアの認定があればより効率性もあがるため、S2D(レノボのThinkAgile MX)はまさにそこをアピールしています。

昨今は大容量化も進んできていることもあり、少ないノード数でPBクラスの構成もサポートしています。

f:id:t_komiya:20181123111819p:plain

f:id:t_komiya:20181123112416p:plain

レノボでS2Dソリューション(ThinkAgile MX)を選択する理由について記載します。先ほども説明したベストレシピで認定構成をリリースしていることもありますが、今回の売りはThinkAgile Advantageサポートにあります。レノボのサポート窓口でハードウェアおよびソフトウェアを一括してサポートします。こちらの話はThinkAgile HXの認定ノードでも同様のことをお話しましたが、その内容と同等になります。

レノボが提供するソフトウェア選択型のNutanixノード~ThinkAgile HX認定ノードの登場!~ - LTN Blog 〜 Lenovo Technology Network 〜

 

f:id:t_komiya:20181123113254p:plain

f:id:t_komiya:20181123112544p:plain

f:id:t_komiya:20181123112658p:plain

ThinkAgile MXのハードウェアスペックをまとめてみました。NVMeやRDMAなどの最新ハードウェアの対応もありますが、ここでのポイントとしてはWindowsのAdminCenterとLenovo XClarityの連携により、XClarityのInventoryからWindows Server側のLogも閲覧できるようになっていて、管理性を向上させていますf:id:t_komiya:20181123113711p:plain

f:id:t_komiya:20181123113755p:plain

最後に2ノード構成のS2Dについて説明します。今回のWindows2019から新たにUSB Witnessの機能が追加されています。通常は外部でWitness用のサーバを立てる必要がありますが、こちらはルーター機器にUSBデバイスを差し込んで、2ノードのS2Dの監視を行うものです。構成図もイメージを載せておきますが、USB Witnessに対応しているルーターも現時点ではまだ数多く無いようです。今後増えていくと思いますので、いろんな周辺機器メーカーのページを参照して頂ければと思います。この構成により、ROBO(Remote Office / Branch Office)利用のHCIも出てくるかと思います。

 

WindowsプラットフォームでのHCIでお手軽の導入を考えていらっしゃるお客様は、是非検討頂ければと思います。

 

よろしくお願いします。

 

Nutanix Files(旧Acropolis File Services)の機能紹介【第二弾】

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。

以前のブログで紹介したNutanix Files(旧Acroplis File Services)の詳細についてお話したいと思います。今までは機能紹介で終わっていましたが、今回はもう少しオペレーションも含めてお話していきたいと思います。詳細はスライドの中にほぼすべて記載しているので、コメントは少なめです。

 

1.Nutanix Filesとは?

f:id:t_komiya:20181117214603p:plain

Nutanix FilesはNutanix上で実現するファイルサーバのことです。ホームディレクトリ、ユーザプロファイル、部門共有サーバなど様々な用途利用できます。Nutanix Filesは物理ホストで実現するのではなく、ファイルサービス用の仮想マシンを専用に構築する必要があります。実現できるハイパーバイザーとしてはAHVとESXiになり、現状はCIFS,NFSの両方のプロトコルに対応しています。容量増設もDSFに対応していることからとても簡単に行うことができます。

f:id:t_komiya:20181117215129p:plain

アーキテクチャについてお話します。Nutanixのクラスタ上に最小構成で3台の仮想ファイルサーバVMを構築する必要があります。この3台構成が必須になるのはNutanix上で高可用性を維持するために必要となります。

f:id:t_komiya:20181117215345p:plain

f:id:t_komiya:20181118162021p:plain機能についてお話します。共有サービスをディレクトリ・ファイルレベルで提供し、アクセス制御も行うことができます。また、高可用性で障害発生した場合にもFSVMでリソースが引き継げるようなアーキテクチャになっています。ユーザ毎に容量制限(クオータ)を設定することができます。1:Nのレプリケーションは対応していますが、NearSyncなどのRPOの短い要件には現状対応しておりません。f:id:t_komiya:20181117215709p:plain

ファイル共有については機能説明を省略させて頂きます。上記をご参照下さい。

2.ファイルサーバー用の仮想マシン

f:id:t_komiya:20181117220015p:plain

ファイルサーバーVMについてですが、最小4vCPU、12GBで構成され、ユーザの規模に応じてリソースの割り当てを変更してスケールさせていきます。詳細は後程紹介します。ファイルサーバーVMはNutanixのクラスタ以下にしなければならないため、3ノードの時は3ノード構成になりますが、最新のFilesでは1ノードや2ノード用のクラスタもサポートしているようです。また、上図で下のほうにABSと記載があるように、FSVMはストレージ部分とはiSCSI接続で利用します。

 

f:id:t_komiya:20181118161344p:plain

Nutanix FilesはSMB(CIFS) / NFSの両方のプラットフォームをサポートしていますが、共有やExportの設定はいづれかの設定になります。

f:id:t_komiya:20181118161532p:plain

 次にネットワークについてお話したいと思います。Nutanix Filesはクライアント側と通信を行う外部ネットワークとFSVMやCVMが冗長性を確保するための内部ネットワークを分けて形成します。そのため、FSVMを構築する際には、図のような形の構成を意識する必要がありますが、状況によってはネットワークの構成の変更が入る可能性もありますので、十分注意が必要となります。外部ネットワークにもActiveDirectoryやLDAP通信をできるようなネットワークを確保することが必要になります。

f:id:t_komiya:20181118162507p:plain

f:id:t_komiya:20181118162523p:plain

f:id:t_komiya:20181118162541p:plain

次にNutanix Filesでサポートされている機能を記載します。まずはサポートOSについてです。WindowsのクライアントOSはWindows7以降、WindowsサーバーOSはWndows2008以降になりますが、Windows2016に記載については現状NutanixのSupport Portal上も記載がないため、こちらを真として頂ければと思います。

また、FSVMの仕様についても記載しておりますが、こちらはNutanix社のReferenceになります。こちら以上の仕様については、複数台のFSVMを構築してスケールして設定して下さい。非同期DRの設定についても現状NearSyncなどの対応はしていないので、ご注意下さい。

f:id:t_komiya:20181118163111p:plain

f:id:t_komiya:20181118163151p:plain

クオータについて説明します。クオータについては、ユーザーとグループの2種類が設定できます。説明の通りでユーザー毎に容量を設定するのか、グループ毎に容量を設定するのかの違いです。また、クオータの設定内容については、ハードウェア的に制限するものと、ソフトウェア的に制限するものがあります。ソフトウェア的な制限を利用した場合は、利用者にメールで通知を行うことができます。

f:id:t_komiya:20181118175609p:plain

f:id:t_komiya:20181118175623p:plain

f:id:t_komiya:20181118175643p:plain

ファイルのパフォーマンスの最適化は、ファイルサーバーが負荷を受けているときにユーザーに通知し、最適化を改善するために変更を必要とします。この機能には、スケールアップ、スケールアウト、および再バランスのアクションが含まれます。

ストレージグループの中断によりパフォーマンスが低下するかどうかは、Prism Webコンソールから自動的に通知されます。ファイルサーバーページには、最適なパフォーマンスオプションの推奨事項が表示されます。

詳細はイメージにもコメントがありますので、参考にして頂ければと思います。

 

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

 

Nutanixの障害シナリオについて学んでみよう!

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。

本日はNutanixの障害シナリオについてお話したいと思います。

 

Nutanixはハードウェアおよびソフトウェアで構成されておりますが、ホストなどのハードウェアが障害があるケース、CVMなどのソフトウェアの障害またはネットワークなどの障害により挙動が違ってきます。今回はその想定される障害シナリオについていろいろとお話したいと思います。

f:id:t_komiya:20181111101419p:plain

障害シナリオについては、上記の記載した内容があります。

この中で、高密度型で導入していないお客様については、ブロックに関する障害はあまり関係ありませんが、どのようなケースなのかを覚えて頂くことも良いかもしれません。

f:id:t_komiya:20181111101835p:plain

ノード障害についてお話したいと思います。

物理障害であるため、ホスト・CVMの両コンポーネントがアクセスできなくなります。そのため、正常な物理ホストのみでクラスタを構成できるようになります。

こちらのスライドはその障害判断プロセスを記載しています。

実際に障害あった場合、ユーザはどのようにして気が付くのでしょうか?それを以下に記載します。

 

ユーザーには何が通知されるのでしょうか?

切り替え処理中に障害が発生したコントローラVMを持つホストは、共有ストレージが使用できないと報告 することがあります。このホスト上のゲストVMは、ストレージパスが復元されるまで「ハング」 しているように見えます。ゲストVMデータのプライマリコピーは、障害が発生したコントローラVMにマップされたディスクに格納されているため使用できませんが、そのデータのレプリカにはまだアクセス できます。リダイレクトが行われるとすぐに、VMは読み取りと書き込みを再開できます。

IOが内部ネットワークを経由するのではなく、ネットワークを介して移動しているため、パフォーマンスがわずかに低下する可能性があります。すべてのトラフィックが10GbEネットワークを通過するため、 ほとんどのワークロードはユーザーに認識されるようには減少しません。

 

のノードが障害になった場合はどうなりますか?

2番目のコントローラVMの障害は他のホストのVMにも同じ影響を与えます。つまり、2つのホストがネットワークを介してIO要求を送信します。しかし、さらに重要なことは、ゲストVMデータに追加のリスクがあることです。2つのコントローラVMを使用できないため、アクセス不能な2つの物理ディスクセットが存在するようになりました。RF2を持つクラスタでは少なくとも1つのコントローラVMが動作を再開するまで、一部のVMデータエクステントが完全に欠落する可能性があります。

 

f:id:t_komiya:20181111102415p:plain

ホスト障害時の挙動についてはこちらをご覧ください。

ノード障害が発生すると、他のノードでVMが再起動しますが他のノードにデータが存在していれば、問題なくデータにアクセスすることができます。ただし、3ノードで構成した場合は、障害時は正常なクラスタではありませんので、早急に復旧が必要になります。

 

ユーザーには何が通知されるのでしょうか?

HA保護されたVMにアクセスしているユーザーは、新しいホストでVMを再起動している間はそのVMを 使用できないことに気付きます。HAなしでは、VMを手動で再起動する必要があります。

 

別のノードが障害になった場合はどうなりますか?

2番目のホストの障害により、残りのホストの処理能力が不十分になり、2番目のホストからVMを再起動 する可能性があります。ただし、負荷の軽いクラスタであってもゲストVMデータに対する追加のリスクが懸念されます。

アクセス不能な2組の物理ディスクを使用すると、一部のVMデータエクステントが完全に失われる可能性があります。

 

f:id:t_komiya:20181111102836p:plain

f:id:t_komiya:20181111103024p:plain

次にドライブ障害について説明します。

ドライブには起動用の領域のブートドライブ、階層化データやOplog(書き込みデータ)がSSDおよびHDDなどのデバイスに格納されています。

それそれに対しての説明については、私の文章で記載することはなく、スライドの内容を参照して頂ければと思います。

ブートドライブについては、Lenovoの場合、2枚のM.2のSSDを利用してRAID1構成について冗長化していることから、1回の障害は保護できるような構成になっています。

 

ユーザーには何が通知されるのでしょうか?

スイッチング処理中に障害が発生したSSDのホストは、共有ストレージが使用できないと報告することがあります。このホスト上のゲストVMは、ストレージパスが復元されるまで「ハング」するように見えます。

リダイレクトが行われるとすぐにVMは読み取りと書き込みを再開できます。IOが内部ネットワークを経由するのではなく、ネットワークを介して移動しているため、パフォーマンスがわずかに低下する可能性があります。すべてのトラフィックが10 GbEネットワークを経由するため、ほとんどのワークロードはユーザーに認識されるようには減少しません。

別のノードが障害になった場合はどうなりますか?

2番目のメタデータドライブの障害は、他のホスト上のVMにも同じ影響を与えます。つまり、2つのホストがネットワークを介してIO要求を送信します。Cassandra Ringの回復機能は、第2の障害が回復プロセスが完了する前に起こらない限り、第2のノードを失うことに伴うリスクを軽減する。

f:id:t_komiya:20181111103122p:plain

メタデータドライブ(SSD)とデータドライブ(HDD・オールフラッシュ構成はSSD)については、クラスタ全体で複製されているため、単一障害では特に影響できることはありません。f:id:t_komiya:20181111103229p:plain

ネットワークの障害については、冗長化構成であれば、単一障害は問題ありません。1GbEのリンクにフェイルオーバーする場合とありますが、10GbEで組む構成が多いと思いますので、現状は気にすることはないと考えられます。

f:id:t_komiya:20181111103310p:plain

f:id:t_komiya:20181111103347p:plain

f:id:t_komiya:20181111103445p:plain

f:id:t_komiya:20181111103527p:plain

ブロックフォールトトレランスについては、ブロック(2U4Nのケースではあります)の時に関連する内容です。メタデータについてもBlockAwarenessも意識した構成が必要になりますので、十分注意が必要です。また、バージョンによってはEraser Codingのサポートにも影響があります

f:id:t_komiya:20181111103626p:plainブロックフォールトトレランスについてはデータ配置も構成も含めて図で示したほうがわかりやすいので、以下はイメージもつけて説明しております。

f:id:t_komiya:20181111103709p:plain

次にRedundancy Factorの話をしたいと思います。

こちらはRedundancy Factor3の内容になりますが、2ノードおよび異なるブロックの障害に耐えうる構成が必要になるオプションです。

デフォルトでは、Redundancy Factor2になるわけですが、クラスタのノードが増えれば増えるほど複数ノードの障害を考える必要があるので、こちらの設定が必要となります。詳細は以下のスライドをご参照下さい。

f:id:t_komiya:20181111103835p:plain

f:id:t_komiya:20181111103912p:plain

f:id:t_komiya:20181111103953p:plain

最後に劣化(Degrade)ノードについてお話したいと思います。

劣化したノードについてはパフォーマンスに悪影響を及ぼします。劣化ノードについては早期に検出して、リスクの軽減するための対策を立てる必要があります。詳細についてはスライドをご参照下さい。

f:id:t_komiya:20181111104036p:plain

f:id:t_komiya:20181111104157p:plain

ブログ内での説明よりもスライドの記載内容が多いため、コメントは少なめになってしまっておりますが、参考にして頂ければと思います。

 

よろしくお願いします。