« 2018年7月 | メイン | 2018年9月 »

2018年8月

2018/08/29

なぜなに Data Domain - 第十七回 - ”DD3300初期設定の流れ"

こんにちは。

Data Domainも今回で十七回目となりました。
第十六回ではDDOS6.X系のライセンスのダウンロードについて見てきました。
今回は "DD3300初期設定の流れ" について紹介します。

弊社購入モデル:Data Domain3300(16TB)

【1】事前準備 shine

・EMCオンラインサポートのアカウント登録

ライセンスファイル(.lic)

flair 構築作業前に上記が準備されていることを確認します!

flair ライセンスファイルの入手は第十六回のブログに記載しています!

    https://blogs.networld.co.jp/main/2018/08/data-domain-----ae63.html

   

【2】Data Domain 初回起動 shine

STEP1
 筐体シリアル番号の確認
17

flair シリアル番号は筐体背面のPSNTタグに記載されています。

STEP2
 DD3300と作業端末をシリアルケーブルで接続します。
38

39flair ボーレート9600の場合、正しく動作しません。
flair システム起動まで最大5分かかる場合があります

STEP3
 DD3300初回起動(電源ボタンを押下)

40

STEP4
 Data Domain初回ログイン
41

flair Data Domain起動後、sysadminでログインします。

flair 工場出荷時のパスワードは筐体シリアル番号になります。

 

STEP5
 使用許諾契約(EULA)

42

flair 使用許諾契約に対して【Y】で応答します。

shine 以上で初回起動は完了です。次はsysadminのパスワードを変更します。

【3】sysadminパスワード変更 shine

STEP6
 sysadminパスワード変更

43

flair ログイン後、パスワードを変更します。

shine 以上でパスワード変更は完了です。次はネットワーク設定をします。

【4】ネットワーク設定 shine

STEP7
   ライセンスファイル(.lic)を適用するため、ネットワーク設定をします。

44

STEP8
   ネットワーク設計に基づいて
【Use DHCP】を設定します。

45

flair 設定が不要な場合、"Enter" を実行して次に進みます。

STEP9
   ネットワーク設計に基づいて【Hostname】を設定します。

46

flair 設定が不要な場合、"Enter" を実行して次に進みます。

STEP10
   設計内容に基づいて【Domainname】を設定します。

47

flair 設定が不要な場合、"Enter" を実行して次に進みます。

STEP11
   ネットワーク設計に基づいて1Gbe【ethMa】を設定します。

50_3

flair 設定が不要な場合、"Enter" を実行して次に進みます。

STEP12
   ネットワーク設計に基づいて1Gbe【ethMb】を設定します。

51

flair 設定が不要な場合、"Enter" を実行して次に進みます。

STEP13
   ネットワーク設計に基づいて1Gbe【ethMc】を設定します。

52

flair 設定が不要な場合、"Enter" を実行して次に進みます。

STEP14
   ネットワーク設計に基づいて1Gbe【ethMd】を設定します。

53

flair 設定が不要な場合、"Enter" を実行して次に進みます。

STEP15
   ネットワーク拡張(10Gbe)をしている場合、

 ネットワーク設計に基づいて【eth1a】を設定します。

54_2

flair 設定が不要な場合、"Enter" を実行して次に進みます。

STEP16
   ネットワーク拡張(10Gbe)をしている場合、

 ネットワーク設計に基づいて【eth1b】を設定します。

55

flair 設定が不要な場合、"Enter" を実行して次に進みます。

STEP17
   ネットワーク設計に基づいて【Default Gateway】を設定します。

56

flair 設定が不要な場合、"Enter" を実行して次に進みます。

STEP18
   ネットワーク設計に基づいて【IP V6 Default Gateway】を設定します。

57

flair 設定が不要な場合、"Enter" を実行して次に進みます。

STEP19
   ネットワーク設計に基づいて【DNS servers】を設定します。

58_2

flair 設定が不要な場合、"Enter" を実行して次に進みます。

 

STEP20
   設定したネットワーク情報を確認し、設定内容を【Save】します。

59_2

shine 以上でネットワーク設定は完了です。次はGUI管理コンソールに接続します。

【5】GUI管理コンソール接続 shine

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

60

flair 接続URL: http://ホスト名またはIPアドレス/ddem

flair 接続アカウント: sysadmin

shine 以上でGUI管理コンソール接続は完了です。

shine 次はライセンスファイル(.lic)をアップロードします。

   

【6】ライセンスファイル(.lic)のアップロード shine

STEP22
   事前に準備したライセンスファイル(.lic)をアップロードします。

61

①【Administration】-【License】を選択。

②【Add License】をクリック。

62

③【参照】をクリックし、ライセンスファイル(.lic)を選択。

④【Apply】をクリック。

63

⑤【ライセンスファイル(.lic)】がアップロードされていることを確認。

shine 以上でライセンスファイル(.lic)のアップロードは完了です。

shine 次はバックアップ領域ディスク(4TB)を追加します。

【7】バックアップ領域ディスク(4TB)追加 shine

STEP23
   System Managerからバックアップ領域ディスク(4TB)を追加します。

64

①【Hardware】-【Storage】を選択。

②【Active Tier】- 【Configure】をクリック。

Configure Active Tier(1)

65

③【バックアップ領域用ディスク(4TB)】を選択。

④【Add to Tier】をクリック。

flair バックアップ領域ディスクはモデルごとに異なります。

66_4

 

Configure Active Tier(2)

67

⑤【Active Tier】バックアップ用ディスクが登録されていることを確認。

⑥【Save】をクリック。

Configure Active Tier(3)

68_2

⑦【file system to use the added storage】メッセージが表示。

⑧【OK】をクリック。

69

⑨ 追加ディスク処理が完了後、【Task complete】が表示。

⑩【Close】をクリック。

70

⑪【Disk】バックアップ領域用ディスクが追加されます。

⑫【State】が “Available” と表示され、ディスクが利用可能な状態であることを確認。

shine 以上でバックアップ領域用ディスク(4TB)の追加は完了です。

shine 次はファイルシステムを作成します。

【8】File Sytem Create / File System Enable shine

STEP24
   バックアップ領域ディスク追加後、ファイルシステムを作成します。

File System Create

71

①【Data Management】-【File System】を選択。

②【Create】をクリック。

Create File System(1)72

①【File System】を作成するバックアップ領域ディスクを選択。

②【Next】をクリック。

Create File System(2)73

③【Cloud Tier】を可能にするための必要ディスク容量が表示。

④【Next】をクリック。

Create File System(3)74

⑤【Active Tier】に作成される Filesystem Size が表示されます。

⑥【Enable file system after creation】を選択。

⑦【Finish】をクリック。

Create File System(4)75

⑧【File System】が作成されます。

⑨【File System Enable】になります。

⑩【Close】をクリック。

shine 以上でファイルシステムの作成は完了です。

shine 次は作成したファイルシステムの稼働状態を確認します。

STEP24
   ファイルシステムが正しく作成されていることを確認。

76

①【Data Management】- 【File System】を選択。

②【Active Tier Space Usage Tier】に作成されたファイルシステムが表示されます。

shine 以上でファイルシステムが正しく作成されていることの確認は完了です。

shine 次はファイルシステムの稼働状態を確認します。

STEP25
   作成されたファイルシステムの稼働状態を確認します。

77

①【Home】- 【Dashboard】

②【File System】内の【Status】が “Running” と表示されていることを確認。

shine 以上でファイルシステムの稼働状態の確認および初期設定は完了です。

flair DD3300は初期構築時には以下の3点を行う必要がありますのでご注意下さい。

  ・ライセンスファイル(.lic)のアップロード

  ・バックアップ領域用ディスクの追加

  ・ファイルシステムの作成と有効

 

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


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

担当:Data Domain製品担当

  

Nutanix 回復性能 – パート 9 – 自己修復機能

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

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

原文を参照したい方はNutanix Resiliency – Part 9 – Self healingをご確認ください。

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

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

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

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


Nutanixには他の従来のSAN/NASアレイだけでなく他のHCI製品とは異なる極めて重要で独自性のある自己回復機能があります.

Nutanixは完全自動でSSDs/HDDs/NVMeやノード障害時だけでなくユーザ処理を介さないで管理スタック(Prism)を完全に復旧させます。まず、デバイス,ノード障害からの自己修復を行いましょう。

簡単に平均の8ノード※Nutanixクラスタと従来のデュアルコントローラSANを比較してみましょう

※ここでいう平均とはグローバルに販売されているノードの平均を計算しています。

一つのコントローラー障害が発生するとSAN/NASは復旧機能が無い状態となり、復旧能力が回復する前にベンダーがコンポーネントを交換するSLAを受けることになります。

それと比べてNutanix8つのコントローラーの内の1(12.5%)がオフラインとなり、残された7つのコントローラーはワークロードを継続して提供し自動的に回復能力をパート1で示したように数分で復旧します。

私が以前ブログで 書いたHardware support contracts & why 24×7 4 hour onsite should no longer be required ではもっと詳細に本内容カバーしています。

簡単に言うとプラットフォームの回復性能を復旧するのは新しいパーツの到着、さらに技術人員による操作、ダウンタイム、データロスの危険性は自己修復がハードウェアの交換、人による介入を無しに完全に復旧できるプラットフォームと比較して極めて高いのです。

より小さいクラスタならどうなの?と思う人もいると思います。

いい質問です、たとえ4ノードのクラスタで1ノードの障害が発生してもハードウェアの交換や人手を介さないで完全に自己修復機能が3ノードでクラスタを稼働するようにします。

Nutanix環境でノード障害が発生した際に完全に自己修復できない唯一の構成は3ノードクラスタです。

しかし3ノードクラスタでも1ノード障害まで耐えられます、データは再保護されクラスタの機能は2ノードであっても機能しますが、次の障害でダウンタイムは発生しますが致命的なデータロスは起こりません。

2ノードで稼働していたとしてもドライブ障害には耐えられるのです。

3ノードのvSANクラスタで1ノード障害が発生するとデータは再保護されずにノードが交換され、リビルドが完了するまでリスクは継続します。

Nutanixがデータ(管理スタックのPRISM)の自己修復を行える前提条件はストレージが十分にあるかだけです。

どのくらいのキャパシティがあるかを確認し、N+1RF2 , N+2 の為のRF3構成を推奨します。これは2台の障害または、一台の障害の後に発生する後続の障害に対応します。

そのため最小構成クラスタでのシナリオではRF2では33% , 5ノードの場合で40%となります。しかし、競合他社による不確実性、疑問性の打破の前にクラスタサイズが増える際に自己修復でどの程度の容量が必要となるかを見てみましょう。

次のテーブルはN+1N+2を基準にクラスタのノードが32ノードまで拡張するための自己修復に必要な容量となります。

ノート:これらの値は全てのノードが100%利用している際の状態となります。

実際はこれよりもこの表よりも低いのが現状です。

Capacityreservedforrebuild

8ノードクラスタを見てみると容量はちょうど13%が必要となります。

N+28ノードで構成し2重障害時に完全にリビルドし回復性を復旧するには25%です。

重要なのは、Nutanix1MBのエクステントをクラスタ内で分散し使用するADSFのおかげで空き容量は大きなオブジェクト(:256GB)を必要としないという事です。

このため、他のプラットフォームと異なりフラグメンテーションによる容量の無駄が無いのです。

ノート:クラスタ内のノード数はリビルドの容量に影響はありません。

ADSFのいくつかの利点としてNutanixはドライブキャッシュはディスクグループのコンセプトを持っていない事です。

ディスクグループは一つのキャシュドライブの障害がディスクグループ(複数のドライブ)をオフラインにし必要以上にリビルド処理を強制的に実施することになるため、回復性能(レジリエンシー)に対して高いリスクとなります。

ADSFのドライブ障害はただの障害で、一つのドライブ障害はそのドライブに乗っているデータの再構築が必要となり、その処理は11の他のプロダクトとは異なり、多対多の分散処理となるのです。

一つのSSDドライブが搭載しているNutanixSSDドライブが障害になったときだけがノード障害と同一となるのですが、これはADSFの制限ではなく、どのハードウェアを利用するかによります。

本番環境化では2つのSSDの回復性能(レジリエンシー)が追加コストより上回るので、一つのSSDモデルよりも2つのSSD搭載モデルを推奨します。

興味深い所:vSANはおそらく一つのSSDシステムがディスクグループの一つのキャッシュとなっている以上、常にこれが単一障害点となります。

クラスタの自己修復と他の障害が発生した際はどのようになるか?とよく質問されます。

2013年にシドニーのvForumNutanixとこのセッションをプレゼンしており、内容をカバーしています。

このセッションはスタンディングルームでしたが、人気であったので5ノードクラスタでノード障害時に4ノードクラスタのためにどのように自己修復が行われるか、たの障害で3ノードクラスタになるためのどのように自己修復が行われるかのブログを書きました。

これは新しい機能でもなく、他の最新のプラットフォームと比べて最も回復性能が高いアーキテクチャでもありません。

Scale Out Shared Nothing Architecture Resiliency by Nutanix

ディスクグループとして構成されている障害時に実施する事は最近のvSan degraded device handlingで投稿されているVMware vSAN 記事から解るように障害の為により多くのディスクスペースを確保する必要がある事です。

この記事からいえる2つの考慮する事は

〇25-30%の余裕のある空き容量をクラスタ内で常に確保しなければいけないという事

〇ドライブがキャッシュだった場合にディスクグループはオフラインとなる事です。

vSANのアーキテクチャを考慮した際に何故VMwareが25~30%の空き容量に加えて FTT2 (three copies of data)を推奨するかが論理的にわかるようになります。

Next let’s go through the self healing of the Management stack from node failures.

ではノード障害の管理スタックの自己修復に移りましょう

Nutanixの全てのコンポーネント、構成、管理、監視、拡張と自動化はクラスタ内のすべてのノードで完全に分散されるようになります。

コアな機能を利用するためにお客様が管理コンポーネントを展開する必要はありません。

お客様が管理スタックを冗長化する必要もありません。

結果、Nutanix/Acropolisの管理層には単一障害点が無いのです。

下のではそれぞれのノードでサービスをしている4つのCVMがいます。

クラスタ内では一つのAcropolis Masterと複数のそれに所属するSlaveが存在ます。

Acropolis4nodecluster1

Acropolis Masterが利用不可となった場合は他のAcropolis SlaveMasterへ昇格します。

これはADSFによって完全分散されたストレージ内にCasandra databaseが保存されているために達成できるのです。

新しくノードがクラスタに追加された場合は、Acropolis Slaveが追加されクラスタの管理層が分散され、結果的には管理が問題になる事はないのです。

Acropolis5nodecluster

パフォーマンス管理、統計集計、仮想マシンのコンソール接続はMasterまたは、Slaveが提供している管理タスクのほんの一部なのです。

これに加えて他のNutanix利点は管理層はサイジング、手動で拡張する必要が一切無いのです。 vAppDatabase サーバ、Windows仮想マシンの展開、インストール、構成、管理やライセンスが不要です。これにより管理環境を単純化しコストも削減できるようになります。

Key point:

  1. The Nutanix Acropolis Management stack is automatically scaled as nodes are added to the cluster, therefore increasing consistency , resiliency, performance and eliminating potential for architectural (sizing) errors which may impact manageability.

The reason I’m highlighting a competitors product is because it’s important for customers to understand the underlying differences especially when it comes to critical factors such as resiliency for both the data and management layers.

Summary:

Nutanix ADSF provides excellent self healing capabilities without the requirement for hardware replacement for both the data and management planes and only requires the bare minimum capacity overheads to do so.

If a vendor led with any of the below statements (all true of vSAN), I bet the conversation would come to an abrupt halt.

  1. A single SSD is a single point of failure and causes multiple drives to concurrently go offline and we need to rebuild all that data
  2. We strongly recommend keeping 25-30% free “slack space” capacity in the cluster
  3. Rebuilds are a slow, One to One operation and in some cases do not start for 60 mins.
  4. In the event of a node failure in a three node vSAN cluster, data is not re-protected and remains at risk until the node is replaced AND the rebuild is complete.

When choosing a HCI product, consider it’s self healing capabilities for both the data and management layers as both are critical to the resiliency of your infrastructure. Don’t put yourself at risk of downtime by being dependant on hardware replacements being delivered in a timely manner. We’ve all experienced or at least heard of horror stories where vendor HW replacement SLAs have not been met due to parts not being available, so be smart, choose a platform which minimises risk by fully self healing.

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

2018/08/24

Nutanix CE を Nested ESXiへインストールする9つのTips

本内容はコミュニティに投稿されているKashi5409(カッシー)さんの翻訳内容です。

本文を参照したい方はこちらを参照ください※ログインにはコミュニティのアカウントが必要となります

今回はCEのインストールの際に必要なTipsをまとめました


Nested ESXiの環境にどうCEをインストールするか?9つのTipsを記載します


■ Community Editionの準備.

CEはコミュニティへログイン後にダウンロードが出来ます。

現在はisoのインストーラーとimg版があります。

46c37b10bc1748a38b723425f9246bef_2

Tips1 :
CEのインストールには必ずimgを利用してください。

現在のバージョンでISOインストーラーを利用したケースでは仮想マシン作成後に起動できないという

問題が数多く報告されているようです。

■ ダウンロードしたイメージをESXiのデータストアに上げます。

事前に仮想マシンの作成を実施(TypeはESXi)しておき、同フォルダ内にダウンロードしたイメージファイルとDescriptior Fileを作成しアップロードします。

Cee01beb52bc4b0096d55e85b7fdb66a

Tips2:
イメージファイルだけでは仮想マシンは作成できないので次のようなDescriptor Fileを作成してアップロードします。

# Disk DescriptorFile
version=1
encoding="UTF-8"
parentCID=ffffffff
isNativeSnapshot="no"
createType="vmfs"

# Extent description
RW 14540800 VMFS "ce.img"

# The Disk Data Base
#DDB

ddb.adapterType = "lsilogic"
ddb.geometry.cylinders = "905"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.thinProvisioned = "1"
ddb.virtualHWVersion = "11"

■ SATAコントローラの追加とCE.imgの追加

仮想マシン作成後にSATAのコントローラーを追加します。

B1bdbec8cf39402cbe722336f2721b91

SATAコントローラーの追加の後は既存のディスクの追加を実施してアップロードしたCE.imgを追加します。

SCSIコントローラーにイメージを追加するとインストールが出来ませんので注意が必要です。

E47dc15274014e68b724fcd099173aa220903ed41f9846c08a77c43cfd41a8e9

Tips3 :

CEのイメージ追加には必ずSATAコントローラーが必要になります。

さらにこのSATAコントローラーですが、vSphere Clientからは追加できないのでWeb Clientを利用して追加してください。

 

■ SCSIコントローラーへDiskを2台追加します

CEのインストールには最低でも2台のDiskが必要となります。

利用用途はHot Tier用、Cold Tier用です。

85181bd5d1db4280afee353784e9d5da

■ その他の構成

CVMが正常に起動するようにハードウェアアシスト仮想化支援が有効化を確認してください。

そして、Diskが2つ登録されている事を確認しましょう。

4213402cd51b468389b43e5ed38ca2d5

起動の順番がSATAになっていないケースがあるので、BIOSに入れるようにも設定をするのが良いです。

167378354d90411eb355b41defc0393b

Tips4 :

仮想マシンの仮想化支援が有効化を確認しまし

また、1stデバイスが何かを確認するためにBIOS 画面を確認できるように設定しましょう。

 

■ 起動

SATA Diskが最初になっているのを確認し、なっていない場合は起動の順番を調整し起動します。

2b543859941d4dbfbe9369f39f19a4ac

インストールを開始します

814e38eb7bde4d5a9df4846dd88664db

SSDディスクが無い環境ではここでFakeSSDを作ります。

AHVへrootでログインし次のコマンドを実行してデバイスが認識しているかを確認しましょう


Nutanix AHV
localhost login: root
#fdisk -l
( to know the device is fine )

58fcaf4906fc4e388c75d72f44ae813f/dev/sdbをダミーのSSDに変換します

# cat /sys/block/sdb/queue/rotational
1

※(change the parameter 1 to 0 )

#echo 0 > /etc/block/sdb/queue/rotational
0

#logout

09b23c1589e64b89bef871b384c09a60

Tips5 :

Nested 環境などでSSDが無い場合は/sys/blcks/sdb/queue/rotationalを変更しましょう

 

■ Nested ESXiへCEをインストールします

installコマンドを実行してCEをインストールします。

2610b2e44fda4b598f7d4b61521e65a5_2

必要なパラメーターを記入します。

シングルノードで構成したい場合は [×]Create Single-Node Clusterとしてください

この際にDNSが必要となりますが、実際はNTPサーバとの同期が必要になってきます。

また、EULAを読まないと次へ進めませんので、読んでおきます。

C552d23df95f4878a613390d0f5f167d

Startを実施したら、コーヒータイムにしましょう。

8d5f9a9d50694d5faf61dfe5d1818352

Tips6 :

EULAを読まないと先へ進めません。

シングルノードクラスタの作成には実際にDNSが必要ですが、これは0.pool.ntp.orgと1.pool.ntp.orgの名前解決、時間同期に使うようでこれが出来ないと起動しません。

■ Prismへログインする前に

Prismへログインするにはデフォルトのパスワードを変更します。

デフォルトユーザー名:admin

デフォルトパスワード:Nutanix/4u

変更後にPrism画面へ入るにはCommunityのメール、パスワードが必要になります。

79ef1ab4a2ec4c829a27a9ab93841f31

もしProxyが存在している環境ではncliコマンドでproxyを設定しましょう。

コマンドは次の通りです

$ncli
ncli> http-proxy add name=internet address=xxx.xxx.xxx.xxx port=8080 proxy-types=https,http

Tips7 :
Proxyがある環境では認証前にProxyを設定しましょう

■シングルノードクラスタの為のTips

シングルノードクラスタで名前解決が出来ない場合は

まだCVMの再起動はしないでください!!!!

なぜか?

シングルノードクラスタの場合、NTPサーバと同期がとれないとcluster start を実施しても

Clusterが起動しません。

最初にPrsimにログインしたら、まずNTPサーバを追加してあげてください。

または、ncliコマンドでも追加できます。

ncli> cluster add-to-ntp-servers servers=xxx.xxx.xxx.xxx

もし、CVMを再起動してしまったのであれば、一時的に次の対策をとりましょう。

/etc/hostsファイルへntpのIPを記載します。

実際にNTPサーバのIPを0.pool.ntp.orgとして時間同期ができるように設定してあげてください。

xxx.xxx.xxx.xxx 0.pool.ntp.org --- >> add
which allow cvm to start cluster .

Tips8 :
シングルノードクラスタではNTPサーバ必須です!

■  仮想マシンの作成の為に

現在のCEのバージョンではそのまま仮想マシンを作成、起動しようとすると次の画面で固まってしまいます。

Ea9541d0744d4ea98c5acc5692767b23

これを回避するためには次の2つのステップをすべてのAHVから実行します。

1.HVへrootでログインします

2. /home/install/phx_iso/phoenix/svm_template/kvm/default.xmlへpmu state の値を追加します

A0ae55bb500440f1bfcf7bc346b243c6

あと一息です!

1.HVへrootでログインします

2. /var/cache/libvirt/qemu/capabilities/3c76bc41d59c0c7314b1ae8e63f4f765d2cf16abaeea081b3ca1f5d8732f7bb1.xml の値を変更します。

実際は

<machine name='pc-i440fx-rhel7.2.0' hotplugCpus='yes' maxCpus='240'/> の項目を削除

次の値を変更します

【変更前】

<machine name='pc-i440fx-rhel7.3.0' alias='pc' hotplugCpus='yes' maxCpus='240'/>

【変更後】

<machine name='pc-i440fx-rhel7.2.0' alias='pc' hotplugCpus='yes' maxCpus='240'/>

841c94e09be3470d9ed7979ddab17993

完了したらCluster Stop -> CVMの再起動 -> Cluster Startを実施してみてください。

仮想マシンが作成できるようになっています。

Tips9 :

仮想マシンが作成できるように次の2つのファイルを変更しましょう

1, /home/install/phx_iso/phoenix/svm_template/kvm/default.xml

2, /var/cache/libvirt/qemu/capabilities/3c76bc41d59c0c7314b1ae8e63f4f765d2cf16abaeea081b3ca1f5d8732f7bb1.xml

■ 9つのTipsまとめ

Tips1 :
CEのインストールには必ずimgを利用してください。

現在のバージョンでISOインストーラーを利用したケースでは仮想マシン作成後に起動できないという

問題が数多く報告されているようです。


Tips2:
イメージファイルだけでは仮想マシンは作成できないので次のようなDescriptor Fileを作成してアップロードします。


Tips3 :

CEのイメージ追加には必ずSATAコントローラーが必要になります。

さらにこのSATAコントローラーですが、vSphere Clientからは追加できないのでWeb Clientを利用して追加してください。


Tips4 :

仮想マシンの仮想化支援が有効化を確認しまし

また、1stデバイスが何かを確認するためにBIOS 画面を確認できるように設定しましょう。


Tips5 :

Nested 環境などでSSDが無い場合は/sys/blcks/sdb/queue/rotationalを変更しましょう


Tips6 :

EULAを読まないと先へ進めません。

シングルノードクラスタの作成には実際にDNSが必要ですが、これは0.pool.ntp.orgと1.pool.ntp.orgの名前解決、時間同期に使うようでこれが出来ないと起動しません。


Tips7 :
Proxyがある環境では認証前にProxyを設定しましょう


Tips8 :
シングルノードクラスタではNTPサーバ必須です!


Tips9 :

仮想マシンが作成できるように次の2つのファイルを変更しましょう

1, /home/install/phx_iso/phoenix/svm_template/kvm/default.xml

2, /var/cache/libvirt/qemu/capabilities/3c76bc41d59c0c7314b1ae8e63f4f765d2cf16abaeea081b3ca1f5d8732f7bb1.xml

Prismの操作性の良さを実感いただけるようにCEのTipsをまとめました。

是非お試しいただけると幸いです。

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

2018/08/23

Foundation 4.1 の新機能

今回は、先日リリースされたFoundation 4.1 の新しい機能についてのご紹介になります。

 

すでにご存じの方も多いかと思いますが、Foundation は、ハイパーバイザーの導入(入れ替え)、

管理コンポーネント(Controller VM)の導入、Controller VM やHypervisor、など

ネットワーク設定、Nutanix クラスタの設定を行なうツールとなります。

 

今回リリースされた Foundation 4.1 の新機能として、

 

  ● 事前に作成したNutanix クラスタの構成ファイルをインポートすることで、Foundation 実行時の

    クラスタの設定(Hypervisor、CVM、IPMI の IP アドレス、クラスタ名など)の簡略化

  ● AOS(CVM)もしくは、Hypervisor のバージョンをそのままの状態で、もう一方を入れ替え

  ● 一部 UI の変更

 

などがありますが、今回は、一つ目の『構成ファイルを使用した Foundation の設定簡略化』について、

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

 

Foundation 全体の流れとしては

  ① MyNutanix にて、構成ファイル(.json)の作成

  ② Foundation VM 4.1 の準備

  ③ Foundation VM 4.1 へ構成ファイルのインポート

  ④ Nutanix の初期化(Foundation)

  

のようになりますが、①、③を中心にこれまでの操作との違いについて、紹介します。

 

[ ① My Nutanix にて、構成ファイル(.json)の作成 ]

すでにお気づきの方もいるかと思いますが、MyNutanix にログインしたところ、新たに

「Foundation Preconfiguration Portal」という項目が追加されております。ここから、

構成ファイルの作成画面へと遷移します。

 

31b

Preconfiguration のリストが表示されます。”Add New” を押下し、構成ファイルの

新規作成を始めます。

32a

【1. Start:】

構成ファイルに、任意の名前を付け、Hardware Platform を選択します。

(今回は、Nutanix 純正を選択しています)

34a

 

【2. Nodes:】

Block の数と、Block あたりの Node 数を指定します。

(以下、"Click here"をクリックした後の画面になりますが、今回は、1ブロック3ノードを

 指定します。)

  

37a

 

BLOCK SERIAL、IPMI の MAC Address、IPMI、Hypervisor、CVM のIPアドレス、

Hypervisorのホスト名を入力します。

 

なお、4.1 より以下赤枠部分は、デフォルトでは表示されておりません。

[Tool] > [Range Autofill] を選択することで表示されます。

 

ここに IP Address やホスト名の値を一つ入力することで、その配下のセルに、各ノード分の値が

自動的に入力されます。

例えば、IPMI IP の配下の AutoFull のところに、192.168.0.20 と入力すると、

192.168.0.20~22 という値が、Node A~C のところに入力されます。

39a_2


【3. Cluster】

クラスタ名、クラスタの IP、DNS、NTP の設定を入力し、"Next"を押下します。

40b

 

【4. AOS】

"Next" を押下します。

 

41a

 

【5. Hypervisor】

"Next" を押下します。

42a

 

【6. IPMI】

IPMI の Credential を設定しますが、[Tools] > [Fill with <ご利用のPlatform> defaults]を

選択すると、各ベンダーのデフォルト値が自動的に入力されます。

(今回の場合、Nutanix 純正のため、”Fill With Nutanix defaults” を選択します。)

44a_2

45a_2

“Validate”をクリックして、” Download Configuration”をクリックすると、構成ファイルを

ダウンロードすることが可能です。任意のフォルダに保存してください。

 

[ ② Foundation VM 4.1 の準備 ]

詳細については省略しますが、Nutanix のPortal(MyNutanix)より、ディスクイメージ

(ESXi であれば、.ovf、AHV であれば、.qcow2)を入手し、仮想化環境上に

Foundation VM をデプロイ、Foundation VM 上のスクリプト”set_foundation_ip_address”を

使用し、Foudantion VM のネットワーク設定などを行ないます。

 

 

[ ③ Foundation 4.1 へ構成ファイルのインポート ]

WinSCP などを使用し、展開した Foundation VM に作成した構成ファイルをコピーします。

 

Foundation VM のデスクトップ上の、”Nutanix Foundation”をクリックすると、以下のような

画面が表示されます。

”Import an install.nutanix.com file…”をクリックして、コピーした構成ファイルを選択します。

Fvm01a_2

構成ファイルのアップロードに成功しますと、以下のようにファイル名が表示されます。

Fvm03a


"Next" を押下しますと、自動的に、指定したパラメータが入力された状態で表示されます。

Fvm07a

Nutanix クラスタ関連のパラメータも、同様の構成ファイルのパラメータが自動的に

反映される形になります。

Fvm08a1

AOS、Hypervisor の選択画面は、これまでのバージョン同様になります。

Fvm09a

Fvm10a

[ ④ Nutanix の初期化(Foundation) ]

IPMI の画面で、”Start”を押下すると、初期化が開始します。

Foundation の流れ自体は、これまでと同様です。

Fvm11a

ここまで、Foundation 4.1 を用いた、初期化の流れを説明しました。

 

ご紹介した構成ファイル(.Json)をインポートすることで、Foundation 実行時のクラスタの

設定情報(Hypervisor、CVM、IPMI の IP アドレス、クラスタ名など)を都度入力する手間が省け、

Foundationの操作の簡略化することが可能になります。

また、構成ファイルを使用することで、人為的なミスを防ぐことも可能となります。

 

 

記事担当者 : SI技術本部 きたがわ

2018/08/22

本日のFrame検証 : アプリケーションの追加

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

今回もNutanixが買収したDaaS製品であるFrameの検証レポートをお送りいたします。

このシリーズの記事は以下のとおりです。

本日のFrame検証 : テストドライブの開始

本日のFrame検証 : アプリケーション

本日のFrame検証 : デスクトップ

この記事には以下の内容を記載しました。

・ProductionとSandbox

・Sandboxへのアプリケーションのインストール

・インストールしたアプリケーションの公開

・Productionへの反映


FrameはDaas (Desktop-as-a-Service) 製品ですが、アプリケーションの配信も可能であることは以前のブログでお伝えしたとおりです。

Frameのテストドライブではサンプルアプリケーションが最初から使えるようになっていますが、もちろんご自身でアプリを追加することも可能です。

【ProductionとSandbox】

以前の記事ではLaunchpadでの[Connected to]の部分において、「Sandboxがマスターイメージ兼テスト環境」であり、「Productionが本番環境」であると記載しました。

管理者はSandboxでアプリケーションのインストールとテストを行い、ユーザーはProductionで業務を行います。

イメージ的にはこんな感じになるかと思います。

V014

【Sandboxへのアプリケーションのインストール】

それでは早速[Connected to]がSandboxになっていることを確認して、アプリケーションのインストールをしていきます。

ここではテストとしてサクラエディタのインストールをしてみました。

084

Frameは現状でダブルバイト文字非対応なだけあって、一部文字化けしているところもありました。

086

無事インストールはできたものの、日本語入力はやはりできません。

(以前の記事にも書きましたが、手元のデバイスのIMEをリダイレクトして使う方式のようです。)

090

【インストールしたアプリケーションの公開】

アプリケーションのインストールが完了したら、インストールされた実体である.exeファイルを右クリックします。

すると[Onboard to Frame]というメニューがありますので、これをクリックします。

V015

このアプリケーションをFrame上で実行させるかという確認ダイアログが表示されますので、OKを選択します。

V016

いくつかの確認が表示されますので[ACCEPT]や[OK]で次へ進めます。

V017

その後、仮想デスクトップを公開したときと同じ管理画面を表示させると、今回インストールしたサクラエディタが[sakura]として追加されていることが確認できます。

仮想デスクトップのときと同様の手順でチェックボックスをONにして[sakura]を有効化させます。

V018

無事SandboxのLaunchpadで公開されていることが確認できます。

V019

【Productionへの反映】

Sandboxで問題なくアプリケーションが動作することを確認できたら、次は本番環境であるProductionへの反映をしましょう。

左上の歯車のメニューから[MANAGING WINDOWS APPS]を展開すると、[LAUNCHPAD SESSION SETTINGS]という項目があります。

[GO TO SETTINGS]をクリックして設定メニューを開きます。

V020

SANDBOXタブの中にある[PUBLISH]をクリックするとSandboxに加えた変更がProductionに反映されるという仕組みになっています。

V021

変更が反映されたら先ほどSandboxで[sakura]を有効化したときと同じ要領でProductionでも有効化すると、ProductionのLaunchpadでも[sakura]が表示されています。

(ここでは同時にWiresharkもインストールし、有効化してあります。)

V022

Frame上の本番用公開アプリケーションとしてサクラエディタが利用できるようになりました。

V023

お好きなアプリケーションの公開もNutanixの製品コンセプトにふさわしいシンプルかつカンタンな操作で実現できることがお分かりいただけるかと思います。

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

Nutanix 回復性能 – パート8 – RF3とEC-X利用時、ノード障害のリビルドパフォーマンス

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

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

原文を参照したい方はNutanix Resiliency – Part 8 – Node failure rebuild performance with RF3 & Erasure Coding (EC-X)をご確認ください。

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

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

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

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


パート1でRF2、パート3でRF3について話してきました。

ADSFの回復性能について話し合う際に重要な要素はドライブ、またはノード障害時に構成されているRFに沿った復旧が行われるスピードです。

パート1とパート3を簡単にまとめ、RF3とEC-Xが使われている時のノード障害のパフォーマンスの例を見ていきましょう。リビルド操作(RFやEC-Xを利用しているに関わらず)は全てのノードとドライブにまたがる完全な分散処理(例:多対多操作)となります。

それはとても早く、ノードのワークロードのボトルネックを最小限に抑え、稼働しているワークロードへの影響を減らします。

リビルドのパフォーマンスはクラスタのサイズ・数やモデル、ドライブ(例:NVMe, SATA-SSD , DAS-SATA)、同様にCPUの世代、ネットワークの接続性といった多くの要素に依存します。 次のハードウェアを利用してサンプルをお見せしたいと思います。

テストは15ノードクラスタで概ね5年前のハードウェアのNX-6050 , NX-3050でIvy Bridge 2560 Processorsを搭載し、6xSATA-SSDと2つの10GB接続を行っている混在環境のクラスタです。

Note:イレージャーコーディングはRF2 , 3よりも多くの計算処理のオーバーヘッドが生じます。より速いパリティ計算を行うのでリビルド時間に大きな違いがでますが、RFは単純にデータを複製するだけです(例:パリティ計算は必要ありません)

このテストではクラスタはRF3とイレージャーコーディングを構成しています。

前回のテストと同じでノード障害はIPMIの”Power off Server – Immediate”を実施しました。方法は次の通りで、これは物理サーバの電源を抜くのと同等です。

Ipmipoweroff

次のスクリーンショットはPrismの分析から取得したもので、ノード障害時のストレージプールのパフォーマンスを示しています。

Rebuildperformanceandcapacityusag_2

このチャートが示すリビルドの最大値は7.24GBpsでリビルドが完了するまで5GBpsを上回っていることが解ります。タスクは下の図のChronosが示す通り47分間かかりました。ChronosはCVMの2011ポートをhttpアクセスすると確認できます。

Nodefailuretaskduration

この例ではEC-Xが有効なNutanixクラスタでさえもADSFは極めて早くリビルドが完了しRF3を保持しながら素晴らしいキャパシティを提供できるのです。

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

2018/08/21

本日のFrame検証 : デスクトップ

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

今回もNutanixが買収したDaaS製品であるFrameの検証レポートをお送りいたします。

このシリーズの記事は以下のとおりです。

本日のFrame検証 : テストドライブの開始

本日のFrame検証 : アプリケーション

この記事には以下の内容を記載しました。

・Frameのテストドライブで仮想デスクトップを有効化にするには

・FrameのVDIの実体とは

・VDIとのファイルのやり取り

・クラウドストレージとの連携


【Frameのテストドライブで仮想デスクトップを有効化にするには】

Frameのテストドライブは、初期状態では仮想デスクトップが利用できるようになっていません。

テストユーザー自身で仮想デスクトップの利用を有効化してあげる必要があります。

左上のメニューから[MANAGING WINDOWS APPS]を選択し、FrameのWindowsアプリ管理画面を表示します。

033

いちばん下までスクロールさせると、ご自身の名前が付けられたDesktopというアプリがありますので、これをクリックし、有効化します。

V008

Launchpadへ戻り、[Connected to]の部分を[Production]から[Sandbox]へ切り替えると、Desktopが表示されます。

※Productionは本番環境、Sandboxはマスターイメージ兼テスト環境とお考えください。

V009

Desktopのアイコンをクリックすると仮想デスクトップが起動してきます。

064

【FrameのVDIの実体とは】

「実体とは」なんて煽るような見出しを付けましたが、もちろんその実体はAWSで稼働するWindowsです。

スペックは以下のとおりで、いわゆるサーバーVDIであることがお分かりいただけます。

・OS : Windows Server 2012 R2

・CPU : Xeon E5-2686v4 @ 2.3GHz

・RAM : 4GB

・ディスク : 44.6GB (初期の空き容量は6.09GB)

066

サーバーVDIということは、Windows 10や7のようなデスクトップOSではありませんので、ご自身でアプリをインストールして利用する場合は互換性やベンダーによるサポート可否の確認が重要になってきます。

デバイスマネージャーからドライバーの一覧も確認してみました。

当然のことながらAWS用のParavirtual ドライバーがインストールされており、ディスプレイアダプターは"Mainframe2 video driver"という独自のものが適用されています。

067

【VDIとのファイルのやり取り】

もちろん手元のデバイスとファイルをやり取りすることが可能です。

例えば、VDIで新しく作ったファイルを手元のデバイスに持ってきたいときは、対象となるファイルを右クリックします。

すると[Download with Frame]というメニューがありますので、これをクリックします。

V010

手元のデバイスのブラウザーのダウンロードウィンドウが表示されますので、任意の場所に保存することが可能です。

V011

【クラウドストレージとの連携】

上述のファイルのやり取り以外にクラウドストレージと連携することもできます。

LaunchpadからFilesをクリックすると、クラウドストレージとの連携メニューが表示されます。

V012

この連携設定の後、デスクトップからエクスプローラーを展開するとDropboxとGoogle Driveがそれぞれドライブとしてマウントされていることが確認できます。

読み込みも書き込みも問題なく可能です。

V013

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

2018/08/20

本日のFrame検証 : アプリケーション

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

今回もNutanixが買収したDaaS製品であるFrameの検証レポートをお送りいたします。

前回の記事はこちらです。

本日のFrame検証 : テストドライブの開始

この記事には以下の内容を記載しました。

・Frameでのアプリケーション起動と文字入力

・ブラウザーを「確認くん」で確認してみた

・アプリケーションの終了


【Frameでのアプリケーション起動と文字入力】

めでたくテストドライブが開始できるようになりますと、サンプルとなるアプリケーションが利用できる状態になっています。

Frameではこの画面をLaunchpadと呼びます。
015

さっそくLaunchpadからGoogle Chromeをクリックして起動してみました。

Initializing...と表示され、しばらく待つとGoogle Chromeが起動してきます。

016

手元のデバイス(私のパソコン)のChromeの中に、さらにChromeが表示されているのがお分かりいただけるかと思います。

017

デフォルトではウィンドウが最大化された状態で表示されますが、アプリケーションのウィンドウサイズを小さくすることも可能です。

018

ちなみに日本語入力はできないようですが、VDI側のIMEを利用する仕組みではなく、手元のデバイスのIMEをリダイレクトする方式です。

※手元のデバイスのIMEはGoogle IMEで、予測変換が機能しているようですが、残念ながら正常に入力することはできませんでした。

V003

YouTubeで動画再生を試してみたところ、再生自体は問題なくできました。

フレームレートや画質が特別良いというわけではありませんが、動画内の音声も含めてどんな動画かは十分に判別可能で視聴に耐え得る品質でした。

V005

【ブラウザーを「確認くん」で確認してみた】

みなさまは「確認くん」というWebサイトをご存知でしょうか。

ご自身のWebブラウザーがアクセス元としてどういった情報を持っているかを表示してくれるサイトですが、Frameから接続してどうなっているのかを確認してみました。

アクセス元のIPアドレスが18.179.42.0となっており、Frameからのアクセス元IPはAWSに割り当てられているレンジのものであることが分かります。

参考URL : ipinfo.io

V006

画面左下の[Click here to start]ボタンをクリックすると、別のアプリも同時に起動することが可能です。

V007

【アプリケーションの終了】

各アプリケーションの右上にある[X]ボタンをクリックすると自動的に終了します。

改めて別のアプリケーションを起動するにはLaunchpadに戻り、使いたいアプリケーションのアイコンをクリックするだけです。

023

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

2018/08/19

本日のFrame検証 : テストドライブの開始

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

先日、NutanixがDaaSを提供する企業であるFrame社の買収を発表し、当社のカッシー先輩もそれに関する記事をこのブログで公開しております。

Frameという製品はいわゆる DaaS (Desktop-as-a-Service) であり、今回は実際にそれをTest Driveで試してみた内容をお知らせします。

FrameがCitrixやVMware、Microsoft RDSなどとどう違うのかという点については、このFrame社ブログの記事が参考になるかと思います。

なお、Nutanixの島崎さんが上記の記事を翻訳して公開されています。


【Frameをテストドライブするには】

Frameはカンタンに試すことができます。

このFrame Test Driveというページへアクセスし、ご自身の情報を入力します。

001

テストしたい環境のデプロイ先を指定します。

今回はAWSの東京リージョンでテストすることにしました。005

次に電話番号を入力して認証をしますが、[SMS]によるテキスト通知と[Call me]による音声による通知が選択できます。

当初、私はSMSで試してみたのですがこれがうまくいかず、[Call me]を選択することで解決しました。

V001

認証が成功しますと、先ほど入力しているメールアドレスにFrameから確認のメールが送付されます。

010

[CREATE MY TEST DRIVE ACCOUNT]をクリックしますと、テスト用のアカウントの生成がスタートします。

私の場合は準備完了してログインできるようになるまで20分程度かかりました。

012_3

テストドライブではあらかじめ検証で利用できるようなアプリが用意されています。

2時間という限られた時間制限の中ではありますが、とてもカンタンにFrameを試せることがお分かりいただけるかと思います。

013

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

2018/08/15

Nutanix 回復性能 – パート7 – ハイパーバイザアップグレードの間のRead&Write I/O

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

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

原文を参照したい方はNutanix Resiliency – Part 7 – Read & Write I/O during Hypervisor upgradesをご確認ください。

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

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

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

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


まだパート1~4を読んでいない場合は前述したパートでは重要なRFと障害からの復旧スピード、RF2から3へ変更する事での回復性能の向上、同じくEC-Xを利用し同じRFを提供しながらの容量削減を記載していますので是非みてください。

パート5,6ではCVMがメンテナンスまたは障害時にどの様にリード・ライトI/Oを行うかを説明し、このパート7ではリード・ライト I/Oがあるハイパーバイザ(ESXi,Hyper-v,XenServer,AHV)のアップグレードにどの様な影響があるかを見てみます。

このブログはパート5,6と深く関係していますのでパート5,6を完全に理解して頂くことをお奨めします。

パート5,6を読むことで,CVMがどんな状況になったとしてもリード、ライト I/Oは継続され設定しているRFに従いデータが保持されるという事が解ります。

ハイパーバイザのアップグレードイベントで仮想マシンはまず移行され通常の操作が継続されます。

ハイパーバイザの障害では仮想マシンはHAのにより再起動され他のノードで稼働します。

ハイパーバイザまたはノードの障害なのか、ハイパーバイザのアップグレードなのか

どちらにしても結果的には仮想マシンはほかのノードで稼働し、元のノード(下のダイアグラムでいうNode1)はある程度の期間オフラインとなりローカルディスクは利用できなくなります。

Hostfailurehypervisorupgradewriteio

リードI/Oのシナリオはどうでしょうか?パート5で説明した内容と同じでリードはリモートのデータを読みに行くか仮想マシンの移動先のノードに複製データがある場合、リードはローカルからとなります。

リモートに1MBのエクステントがローカライズされるとその後のリードはローカルとなります。

書込みはどうか?パート6であるように

書き込みは常に構成されたRFに順次し、たとえハイパーバイザのアップグレード、CVM、ハイパーバイザ、ノード、ネットワーク、ディスク、SSD障害がだとしても一つの複製とローカルへ残りの1つまたは2つの複製をクラスタの現在のパフォーマンス、ノードの使用量をベースに分散します。

それは本当にシンプルでこのレベルの回復性能を実現するのはADSFのおかげなのです。

Summary:

  1. A hypervisor failure never impacts the write path of ADSF
  2. Data integrity is ALWAYS maintained even in the event of a hypervisor (node) failure
  3. A hypervisor upgrade is completed without disruption to the read/write path
  4. Reads continue to be served either locally or remotely regardless of upgrades, maintenance or failure
  5. During hypervisor failures, Data Locality is maintained with writes always keeping one copy locally where the VM resides for optimal read/write performance during upgrades/failure scenarios.

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

アクセスランキング

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