│ ©

第 回 クラウド事業者向け 導入のメリットとポイント

2018 年 7月 31日

14:00より開始いたします。しばらくお待ちください。

アジェンダ

1 vSAN概要

2 vSANの導入メリットとサービス導入例

3 導入トラブルを防ぐポイント

4 vSAN 6.7 新機能

5 Q&A

│ ©

vSAN概要

クラウド・ストレージ

共有ストレージ

サーバー、ネットワーク、ストレージを仮想化データセンター全体の管理をソフトウェアによって自動化

コンピューティング

ネットワーク

ストレージ

管理

Software-Defined Data Center

次世代仮想基盤が向かうべき方向性

仮想環境におけるストレージの課題

• 仮想化を効果的に活用するには共有ストレージ

– 高価な専用ハードウェア

– 専門的な難しい作業

– 定期的な作業費

• 変化の早い、”今”のビジネスの状況にあった投資と調達

– 簡単に管理ができる

– 必要に応じた拡張性

– サービスレベルを後から変えたい

サーバを構成する時、ストレージ作業を同時に実行ストレージ作業をシンプルにする解決策が注目！

• 課題解決の方向性

– サーバ内蔵ディスクの活用

– 仮想マシン管理と同等レベルの作業

– セルフサービス化

│ ©

国内での vSAN 導入状況vSphere 6.0 U1 リリースを契機に本格的な導入が始まり、直近では導入傾向が大きく加速

✓ vSAN 5.5 技術的な課題✓ vSphere 6.0 U1待ち

➢ vSAN の機能向上➢ vSphere 6.x の普及

様々な 業種/ユースケース でご活用をいただいております

2014年 2015年 2016年

vSphere 5.5(2014年3月〜)

vSphere 6.0 (2015年3月〜)

vSAN 6.0 vSAN 6.1vSAN 5.5 vSAN 6.2 vSAN 6.5

vSphere 6.5(2016年11月〜)

2017年

vSAN 6.6 vSAN 6.7

2018年

vSAN 6.X

vSphere 6.7(2018年4月〜)

◆ vSAN 6.0での大幅な機能改善◆ vSphere 6.0 U1リリース

Update 1 Update 2Update 1

vSAN ベースの HCI・国内導入ユーザー数の推移

vSphere + Virtual SAN

…

ハードディスクSSD

ハードディスクSSD ハードディス

クSSD

Virtual SAN 共有データストア

VMware Virtual SAN 特長

➢ 内蔵ディスクが持つ “性能” を活用

➢ 内蔵ディスクの “共有” と “データ保護” を実現

➢ RAID , LUN の概念が存在しないので “とても簡単”

• カーネルに組み込まれたストレージ仮想化製品

• 標準 x86 サーバのローカルディスク(HDD/SSD) をプール化

• 仮想マシン(アプリ)視点のポリシーベース管理

│ ©

“カーネル組み込みアーキテクチャ”だからこそ実現される管理性

vSphere vSAN

vCenter

・シンプルなデータストア構造 (RAID, LUNを排除)・ポリシーベースで仮想マシンごとのSLAを実現・管理に必要な情報は全て vCenter が把握

：SLA 1：SLA 2：SLA 3

│ ©

vSANのアーキテクチャ従来型ストレージの “複雑さ要因を完全に排除” したシンプルなアーキテクチャ

VM

仮想

従来型アーキテクチャ

ESXi

Storage

VM

仮想

仮想マシンの払い出しと連動ストレージ要件(可用性, 性能)への柔軟な対応ポリシーはオンラインでの変更が可能

vSAN のアーキテクチャ

ESXi

仮想基盤の複雑さ要因を排除

Virtual SAN ハードウェア構成：ハイブリッドとオールフラッシュ

共通基盤

ESXi がサポートされるサーバ

ブートデバイス

ネットワークカード(NIC)

VSAN互換性コンポーネント

I/Oコントローラ

キャッシュ用デバイス

キャパシティ用デバイス

HW選定ガイドライン• VSAN Ready Nodes

VDI/サーバ仮想化の規模により組み上げ済み構成• コンポーネントベース

すべて手組みを行う柔軟性の高い構成

ハイブリッド オールフラッシュ

キャッシュ

Read/Write キャッシュ Write キャッシュ

SAS/NL SAS/SATA/Direct-attached JBOD フラッシュデバイス

キャパシティ

SSD PCIe Ultra DIMM SSD PCIe Ultra DIMM

│ ©

⚫ 各社からvSANに対応したバックアップツールがでている

⚫ 各ソリューションごとにKBがある

vSANにおけるバックアップ

VMware Compatibility Guide

検索カテゴリでvSAN Partner Solutionを指定し検索

│ ©

vSANの導入メリットとサービス導入例

│ ©

VMwareのアプローチ：Cloud is a Strategy, Not a Destinationクラウドは”戦略”であり、“行き先”ではない。

vs.柔軟なクラウド戦略

多くのクラウド事業者

一般的なアーキテクチャ

既存のプライベートクラウド

行き先としてのクラウド

既存のプライベートクラウド

一方通行

単一のクラウド事業者

長期的な視点に立った、最適なリソースを利用するための柔軟な戦略が重要

VMwareがエンドユーザ様に

Hybrid Cloudを訴求する資料より

│ ©

ハイブリッドクラウド環境における運用管理の例

2重化 2重化

ストレージポリシー(２重化)

ストレージポリシー(３重化)

3重化 3重化

ストレージポリシー(２重化)

ストレージポリシー(３重化)

セキュリティポリシー

VMware

Cloud

ネットワーク可視化

セキュリティポリシー

Private

Cloudオンプレミスサイト

Private

Cloud

継続時なリソースの可視化/キャパシティ管理

ログ分析

自動化

VMwareがエンドユーザ様に

Hybrid Cloudを訴求する資料より

クラウド戦略が HCI の選定に大きく関連してきている

Unified Software Defined

Platform

プライベートクラウド

コンピュート ストレージ ネットワーク

管理& 自動化

単一の管理フレームワーク

パブリッククラウド

Software Defined, HW非依存

エンタープライズ対応

柔軟な拡張性

パブリッククラウドへの拡張

全てのアプリに対応

自動化

VMwareがエンドユーザ様に

Hybrid Cloudを訴求する資料より

Hybrid Cloud に対応したクラウドが求められる

│ ©

vSANを活用しているクラウド事業者様

“RackspaceはvSANを利用して顧客のワークロードを継続的に

実行します”

“高パフォーマンスなAll FlashvSAN上に11 PBの顧客データ

を展開しています”

│ ©

株式会社 IDC フロンティア様vSANを基盤として、お客様ごとの分離性を実現したクラウドサービス

運用保守の見える化 アーキテクチャの見える化

すべてを可視化した「見える！クラウド」

「クラウド＝ブラックボックス」の常識を変える。自社所有と変わらない真にオープンな見えるクラウドを目指します。

お客さまは、サービスの隅々までを把握でき、自社でハンドルできる範囲（運用分界点）を明確化できます。

だから、システム変更時やトラブルの際にもお客さま側でいち早く対処できます。

https://www.idcf.jp/cloud/private/

│ ©

✓ オンプレポリシーのシームレスな受け入れ（Hybrid Cloud対応性）

✓ ストレージ管理の容易性（LUN管理がいらない、デバイス故障率の低減）

✓ 単一構成の拡張容易性（サーバ追加により自動的な容量拡張）

✓ ワンストップサポート

✓ ハードウェアのコスト削減

クラウドパートナー様のvSAN導入メリット

│ ©

導入トラブルを防ぐポイント

vSAN のトラブルは以下のポイントを押さえることで防げます！

1. 事前の構成をきっちり固める！

2. 構築時にきちんと最適化する！

事前構成をしっかり固める（ハードウェアの選定）事前構成をしっかり固める（サイジング）構築時きちんと最適化する（適切なデバイスドライバとファームウェアと最新パッチの適用）構築時きちんと最適化する（利用する機能を事前に定義する）構築時きちんと最適化する（ vSAN 健全性チェックで最終確認）

│ ©

ハードウェアの選定サイジング

事前の構成をしっかり固める

vSAN の提供形態

シンプルな初期セットアップもしくは工場で組み上げ出荷各社独自の専用ツールを搭載

vSAN HCL に記載されているデバイスから任意のものを選択

ハイブリッド、オールフラッシュ共に、各 HW ベンダーの組み上げテスト済み構成

vSAN Ready NodeHCI アプライアンス

VxRAIL PRIMEFLEX forVMware vSAN

ThinkAgile VX

DIY(Build Your Own)

DIY (Build Your Own)の場合

VMware Compatibility Guide でサポートデバイスを確認して選択

VMware Compatibility Guide (https://www.vmware.com/resources/compatibility/search.php?deviceCategory=vsan)

対象デバイス選択

vSAN バージョンの選択

vSAN タイプの選択

ハードウェア選定サマリ

HCI アプライアンス vSAN Ready Node DIY (Build Your Own)

セットアップの容易さ ◎ ○ △

構成の柔軟性 △ ○ ◎

保守性 ◎ ○ △

システムの拡張性 △ ○ ◎

それぞれ項目毎に向き不向きが存在するため、システム要件と照らし合わせて何を優先するかをきちんと考慮し、タイプを選択すると非常に HCI の運用を効率化することが出来る

CPU サイジング

• ホストあたり仮想マシンが使用するコア数 x 10%

• 例

– 仮想マシンに割り当てる CPU コア数が 40 コアの場合

– 40 コア x 10% → vSAN で使用する4コアを上乗せする

vSAN で使用する CPU リソースは？

vSAN メモリサイジング

vSAN メモリサイジング計算式

① + ( ディスクグループ数 x ( ② + ( ③ or ④ x SSD サイズ ))) + ( キャパシティディスク数 x ⑤ )

① BaseConsumption = 5426 MB

② DiskGroupBaseConsumption = 636 MB

③ SSDMemOverheadPerGB (hydrid) = 8 MB

④ SSDMemOverheadPerGB (allflash) = 14 MB

⑤ CapacityDiskBaseConsumption= 70 MB

例1: ハイブリッド、キャッシュが800GB、キャパシティ x 4本のディスクグループ数がホスト毎に2つ

5426 + ( 2 x ( 636 + ( 8 x 800 ))) + ( 70 x 4 ) = 13378 MB

例2: オールフラッシュ、キャッシュが400GB、キャパシティ x 3本のディスクグループ数がホスト毎に3つ

5426 + ( 3 x ( 636 + ( 14 x 400 ))) + ( 70 x 3 ) = 13314 MB

キャッシュサイジング

27

• ハイブリッド、vSAN 6.2 以前のオールフラッシュ構成

実行容量の 10% 程度をクラスタ全体で確保する例: 8ノード構成のクラスタで稼働する仮想マシンの VMDK の総容量が 20TB の場合20TB x 0.1 / 8 = 0.25TB (ホストあたり 250GB 以上のキャッシュを搭載)

• vSAN 6.5 以降のオールフラッシュ構成

実行される IO の性質や負荷に応じて以下の表を基に算出する

IO 性質・負荷 AF-8 80K IOPS AF-6 50K IOPS AF-4 20K IOPS

70/30 Random 800GB※ 400GB 200GB

>30% write random 1.2TB※ 800GB※ 400GB

100% write sequential 1.6TB※ 1.2TB※ 600GB

※ 1 ディスクグループあたりのキャッシュ搭載量が 600GB を超える場合には複数のディスクグループで構成する例: 800GB -> 400GB x 2 ディスクグループ

サイジングサマリ

項目 内容

CPU 仮想マシンが必要なコア数 x 10%

メモリ一般的な構成で、4 - 10 GB 程度SSD の容量、ディスクグループによって使用量は異なる

パフォーマンス Ready Node の構成ガイドラインのノードあたり参考 IOPS 値を確認

容量キャッシュ：論理容量(実効容量)の10%※ vSAN 6.5 以降のオールフラッシュ構成は IO 性質で選定キャパシティ：論理容量に許容する障害の数 +1 をかけた数(ミラーリング概算)

キャパシティサイジング

ホストあたりキャパシティディスクの容量計算式

実行容量 x データ保護方式係数 x スラックスペース係数 x ファイルシステムオーバヘッド係数 / ホスト数

実行容量の内訳

– 仮想マシンの VMDK 総容量

– 仮想マシン構成ファイル、ログファイルの総容量

– 仮想マシンスナップショットの差分容量 x 保持世代数

– 仮想マシンスワップファイルの総容量( = 仮想マシンのメモリ搭載量)

– ISO ファイルなどその他、テンポラリファイル領域の総容量

データ保護方式による必要容量

データ保護 実効容量 x N 倍

FTT = 1 キャパシティ( RAID 5 ) x1.33

FTT = 2 キャパシティ( RAID 6 ) x1.5

FTT = 1 パフォーマンス(ミラーリング) x2

FTT = 2 パフォーマンス(ミラーリング) x3

FTT = 3 パフォーマンス(ミラーリング) x4

データ保護方式により確保する容量は異なるデータ保護方式は仮想マシンもしくは VMDK 単位で設定出来るため、混在する場合にはそれぞれを計算して算出する

スラックスペースの用途

冗長性の観点以外にも、以下のオペレーション発生時のために空き容量を確保する必要がある

– コンポーネントのリビルド

– リバランス

– ストレージポリシーの変更

例 : RAID-1 から RAID-5 へ変更した時の一時的な消費容量の変化

オーバーヘッド

プライマリVM データ 消

費容量

1. RAID-1 設定

オーバーヘッド

プライマリVM データ

消費容量

2. RAID-5 へ設定変更

3. RAID-5 オブジェクト作成

オーバーヘッド

プライマリVM データ

消費容量

4. 古いコンポーネントの削除

vSAN のディスク使用量について

• キャパシティ用の各ディスク単位で使用量が 80% を超えると、データの再配分(リバランス)処理が発生します。 そのため、全体で使用量が 80% を超えないように維持する必要があります

• 30％ のフリースペース(スラックスペース)を維持することで、これらのアクティビティによる一時的な利用率の変動に対応しながら、リバランシング操作の発生を最小限に抑えます

vSphere vSAN vSphere vSAN vSphere vSAN vSphere vSAN

vSAN ファイルシステム オーバーヘッド

• ディスクグループの各ディスクは、vSAN 用のファイルシステムでフォーマットされる

• このフォーマットをオンディスク フォーマットと呼ぶ

• オンディスク フォーマットにはバージョンがあり、バージョンによってオーバヘッド値が異なる

vSANバージョン

オンディスクフォーマットバージョン

5.5 v1

6.0 v2

6.1 v2

6.2 v4

6.5 v4

6.6 v5

オンディスクフォーマットバージョン

オンディスク フォーマット オーバーヘッド

v1 ・キャパシティ デバイスあたり約 1 GB

v2 ・キャパシティ デバイスあたり容量の 1 – 2%

v3 以降 ・キャパシティ デバイスあたり容量の 1 – 2%・チェックサム + デデュープ/圧縮 有効時 :

キャパシティ デバイスあたり容量の 約 6.2%

* オンディスク フォーマット バージョン 3 は中間バージョンです。オンディスク フォーマットバージョン 2 からオンディスク フォーマット バージョン 4 へのアップグレード プロセス中に暫定的に使用されます。

│ ©

適切なデバイスドライバとファームウェアと最新パッチの適用利用する機能を事前に定義するvSAN 健全性チェックで最終確認

構築時にきちんと最適化する

最適なデバイスドライバとファームウェアの適用

VMware Compatibility Guide でデバイスを確認

vSAN のバージョンやタイプに合わせたデバイスドライバとファームウェアを確認して適用特に RAID コントローラは性能にも大きく影響するので注意

vSphere のパッチの考え方

メジャー リリース

マイナー リリース

メンテナンス リリース

ソフトウェアの一般的に利用可能なリリース機能の拡張と拡張、重大度が高く重大度の高いバグに対する修正が含まれている(例: vSphere 5.0 , vSphere 6.0)

現在のリリースで特定されている重大度の高い重大度の高いバグの修正版を新機能、機能、マイナーな機能強化などの限られた量で導入(例: vSphere 6.5 , vSphere 6.7)

Express パッチよりも多くの修正が含まれ、重要な機能やハードウェアの有効化も含まれる場合もある追加インストールしての ISO も提供される(例: vSphere 6.0.1 , vSphere 6.5.1)

アップデート

Express パッチ重要度の高いバグ修正のみを提供(例: vSphere 6.0.1EP06 , vSphere 6.5.0 EP02)

構築時に最新の Express パッチまできっちり適用させることで、既存バグへの遭遇を回避

vSAN の機能一覧

重複排除・圧縮 暗号化 Erasure Coding チェックサム QoS

vSAN タイプ オールフラッシュオールフラッシュ

ハイブリッドオールフラッシュ

オールフラッシュハイブリッド

オールフラッシュハイブリッド

有効範囲 vSAN クラスタ vSAN クラスタ仮想マシン

( VMDK )

仮想マシン

( VMDK )

仮想マシン

( VMDK )

vSAN の機能は利用するかしないかを選択することが可能機能によってクラスタ全体で有効化するものと仮想マシン( VMDK )単位で有効化するものに分かれるクラスタ全体で有効化するものは、有効化の際に vSAN クラスタ全体に影響を与える

この二つはデータが格納された後での有効化はデータ待避による処理時間の長期化と性能への影響が懸念されるため、構築時までに利用の可否を決定し事前に設定する

既存クラスタの重複排除を有効化する場合の注意事項

SSD

SSD SSD SSD

Disk Group

vSphere vSAN

既存クラスタに対して重複排除・圧縮を有効化する場合には以下のオペレーションが行われる

1. 別ディスクグループへのデータの待避2. ディスクグループの削除3. 重複排除・圧縮を有効化したディスクグループの作成

SSD

SSD SSD SSD

Disk Group

SSD

SSD SSD SSD

Disk Group

SSD

SSD SSD SSD

Disk Group

vSAN 健全性チェック概要

• ネットワーク• 物理ディスク• データ• クラスタ• 制限• ハードウェア互換性• パフォーマンスサービス• vSAN ビルドに関する推奨事項

SCSI コントローラの HCL やドライバ、ファームウェアのチェック

vSAN のプロセス、ソフトウェアバージョンの互換性などのチェック

vSAN オブジェクトの健全性のチェック

vSAN ネットワークの構成や状態のチェックメタデータの健全性やディスク容量、輻輳のチェック

パフォーマンスサービスの収集状況や統計 DB の状態チェック

vSAN ビルドに関する推奨事項

導入トラブルを防ぐポイントのまとめ

• vSAN のハードウェアタイプはシステムの要件に合わせて適切なものを選択する

• vSAN のサイジングは非常に重要、予期せぬトラブルを防ぐためにシステムに応じたシステムリソースとスラックスペースを確実に確保する

• 構築時の適切なデバイスドライバ、ファームウェアの適用、最新の vSphere パッチ適用で運用後のトラブルを最小限まで減らす

• 構築後に vSAN の健全性チェックでステータスがオールグリーンになっていることを確認するチェックに引っかかっている項目があれば、きちんと正常化して運用を開始する

• 重複排除・圧縮や暗号化など、クラスタ全体で設定する機能は運用後の変更を避けるために構築時までに利用するかしないかを決定する

│ ©

1. 1台をメンテナンスモードにできるように、最低4台のホストで構成する。メンテナンスの際にもVMに可用性とパフォーマンスを継続提供できるようにする

2. 10Gのオールフラッシュ構成を採用する

3. リンク集約制御プロトコル（LACP）を設定する

4. ネットワークI/Oコントロール（NIOC）をオンにして、vSANに必要な帯域幅を確保する

5. 特に旧来のクラウド環境から移行する場合、vSANの柔軟性を十分に活用するためにスモールスタートを採用する

クラウドサービスプロバイダのためのvSAN推奨事項とベストプラクティスVMware Cloud Provider Blog より

│ ©

vSAN 6.7 新機能

│ ©

モダンで効率的な HTML5 UI

vCenterに統合されたvRealize Operations

Windows Server Failover Cluster (WSFC) サポート

パフォーマンスの向上

• Adaptive Resync

• Faster destaging

容量効率の向上

• Thin provisioned swap objects

• Intelligent Decommissioning

クラスタトポロジの回復の向上

新規及び改善された健全性チェック

柔軟な診断パーティション

vSAN Support Insight

4Kn デバイスのサポート

FIPS 140-2 認定済み

vSAN 6.7 新機能

直感的な操作を可能に一貫したアプリケーションエクスペリエンス

統合的なサポートエクスペリエンス

│ ©

vCenter 組み込みのvRealizeにより強化されたインテリジェンス

vCenter HTML5 Client にvRealize Operations プラグインが統合

2つのデプロイ方法:

• 新しい vROps のインスタンス

• 既存 vROps インスタンス

vSphere と vSAN のダッシュボード

複数のクラスタも一元管理

vROps のvCenter UI への統合

vCenter 組み込まれた vRealize Operations

vCenter UI

vSphere vSAN vSphere vSAN

│ ©

従来型のクラスタリング技術への対応

vSAN iSCSI サービスを使用することで、Windows Server Failover Clusters (WSFC) 対応

下記をサポート:

• 物理 – サーバの iSCSI イニシエーターの使用

• 仮想 – ゲストVMの iSCSI イニシエーターを使用

vSAN iSCSI ボリュームを使用することでWSFCの透過的なフェールオーバを実現

WSFC をvSAN iSCSI ターゲットサービスと組み合わせて使う

│ ©

B/W Regulator

インテリジェントなI/O管理によるパフォーマンスの向上

再同期が行われている場合、再同期 I/O は少なくとも帯域の20% を保証

再同期トラフィックが発生していない場合、仮想マシンのI/O

が帯域の 100% を消費

各トラフィックに専用のキューを割り当て

読み取りと書き込みを調整

VM I/O と Resync I/O の最適なバランスを保証

再同期トラフィックの動的管理をおこなうアダプティブ再同期

Disk Group

NamespaceQueue

Resync I/O Queue

Metadata Queue

VM I/OQueue

Fairness Scheduler

Congestion

Signals

│ ©

まとめ

全体のまとめ

⚫ vSANは提供開始から4年以上たち、導入が加速している

✓ 基本的な特長１：HWメーカーが限定されない

✓ 基本的な特長２：汎用性の高いx86サーバと内蔵ディスクで低コストを実現

✓ 基本的な特長３：ストレージの専用概念を排除し、管理が難しくない

✓ 基本的な特長４：ポリシーベースで仮想マシン要件に対応可能

⚫ クラウド事業者でもvSAN活用事例が増えている

⚫ 外部ストレージには無い、簡単さ、コストメリットがある

⚫ ストレージにおける Hybrid Cloud対応性を実装できる

⚫ 導入トラブルを防ぐポイントが確立されてきている

⚫ 機能面、運用面、パフォーマンス面において進化を続けている

御社のクラウドでもvSANを是非ご活用ください！

│ ©

Q&A

│ ©

Q1. 増設の際に同じスペックのサーバーを追加しなければいけないのか

A1. 必ずしも同じスペックのサーバーを追加する必要はないが、パフォーマンスの偏りが発生する可能性があるので、できれば同じスペックのサーバーを同じクラスタに追加することを推奨している

Q2. 要件によってはストレージだけ追加したい場合やコンピュートリソースだけ追加したい場合も出てくると思うが、どのように対応できるか

A2. サーバーにSSDを追加搭載したり、ストレージ機能を持たないサーバーを追加してクラスタリソースとして利用するなど柔軟な対応ができる

Q3. vSANのディスクは少ない容量のディスクを多数入れるのと大容量のディスクを少量入れるのとどちらがいいのか

A3. 書き込みの観点ではディスクの数が多いことがメリットになる。あとはどのくらいのストレージサイズが必要か判断して構成することをお勧めする

Q4. ４台で構成したvSANクラスタのうち1台をメンテナンスモードにした場合仮想マシンに与える影響はあるか（冗長性の担保など）

A4. FTTの値によるがFTT1にすれば3台で運用可能なので、VMはそのまま運用できる。ただし、必ずしもパフォーマンスが全く同じとは限らないのでResyncも考慮する必要がある

いただいたQ&A

│ ©

ご清聴ありがとうございました

次回は

2018年8月23日（木）14:00〜を予定しております。

是非ご参加ください。