Find Communities by: Category | Product

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。



VxRail 4.0からはVxRail Managerがインターネットにアクセスできる環境にある場合は、

VxRail ManagerのUIから直接アップグレード用パッケージをダウンロードし、パッチの適用が可能になりました。

先週、VxRail 4.0.100というマイナーバージョンがリリースされたので、どのようなものか試してみました。

 

ちなみに、それぞれのバージョンの中身は以下となります。

 

■VxRail 4.0.0

  • VMware vCenter Server Appliance 6.0.0 build-3634794 (6.0u2)
  • VXRail Manager 4.0.0-4631184
  • VxRail Manager VIB 4.0.0-4631184
  • VMware ESXi 6.0.0 build-4192238 (6.0p03)

 

■VxRail 4.0.100

  • VxRail Manager 4.0.100-4907696
  • VxRail Manager VIB 4.0.100-4907696
  • VMware vCenter Server Appliance 6.0.0 build-4541948 (6.0u2a)
  • VMware ESXi 6.0.0 build-4600944 (6.0p04)

 


以下、実際にVxRail Managerを利用したインターネット経由のアップグレードを試してみました。


新しいアップグレードが可能になると、UI左側のメニューに赤①のマークがつきます。

21.png

 

最新バージョンと現在のバージョンが確認できます。

22.png

23.png

 

「インターネットアップグレード」のボタンをクリックすると、VxRail ManagerがSupport EMCにアクセスし、

VxRail Manager用のアップグレードバイナリと、vSphereのパッケージ(vCSA 6.0.u2a + ESXi6.0P04)がダウンロードされます。

29.png

※軽い気持ちでDLを開始すると、合計4GBくらいのパッケージのDLが始まりますのでご注意ください。

 外部回線が細い検証環境で試したら3時間くらい掛かってしまいました...

 

ちなみにVxRail Managerにダウンロードされたファイルは[ /tmp/lcm ]に置かれます。


VxMng:/tmp/lcm # ls -alh

total 2.9G

drwxr-xr-x  3 tcserver pivotal 4.0K Feb  1 16:48 .

drwxrwxrwt 54 root     root    4.0K Feb  1 17:24 ..

-rw-r--r--  1 root     root   2.9G Feb  1 16:48 VXRAIL_COMPOSITE-4.0.100-4907697.zip  ← vSphere6.0u2a関連のパッケージ

drwxr-xr-x  3 tcserver pivotal 4.0K Feb  1 16:48 unpacked

 

 

VxMng:/tmp/lcm/unpacked/bundles # ls -alh

total 859M

drwxr-xr-x 2 tcserver pivotal 4.0K Feb  1 16:49 .

drwxr-xr-x 3 tcserver pivotal 4.0K Feb  1 16:48 ..

-rw-r--r-- 1 tcserver pivotal 858M Feb  1 16:48 VXRAIL_Manager-4.0.100.00000-4907696-updaterepo.zip ← VxRail Managerのパッケージ

 

 

ダウンロードが完了したら「続行」

30.png

 

アップグレードに必要な各コンポーネントの管理者アカウント情報を入力して続行します。

FILESV01_VxRail_ResourcePool_20170201_035.png

VxRail Managerの更新から始まります。

ここで一度VxRail Managerが再起動されるのでセッションが切れるようです。

 

FILESV01_VxRail_ResourcePool_20170201_039.png

 

ここで打ち合わせが入っていたので、ほったらかしにして2時間後くらいに再度ログインしてみました。

エラーで失敗してました...

FILESV01_VxRail_ResourcePool_20170201_040.png

 

KB488890を見よ、と記載があるのので確認すると、事前にチェックしておくべき項目(DRSが有効か?メンテナンスモードにしてないか?など)がいくつかありましたが、とりあえず検証環境ですし「Retry」ボタンがあったので軽い気持ちで再チャレンジ。

※本番環境のときも、エラーのときは現状維持で待機しているはずなので、慌てずエラーの内容を確認してEMCかパートナーに連絡してください。

42.png

 

今度はうまく進んでいました。

打ち合わせで途中の確認は飛ばしていたのすが、VxRail Managerの再起動後、vCSAとPSCの6.0u2aパッチ適用、各ホストへのP04パッチ適用が順次進んでいました。

FILESV01_VxRail_ResourcePool_20170201_052.png

 

あとは眺めているだけで、各ホストのバージョンアップ含め、すべてのコンポーネントが更新されました。

やっぱり便利ですねこの機能。

FILESV01_VxRail_ResourcePool_20170201_058.png

 

アップグレード直後は「監視抑制モード」モードでしたが、しばらくすると通常モードに戻ります。

FILESV01_VxRail_ResourcePool_20170201_060.png

 

ちなみに、vCSA 6.0u2aにアップグレードしたことで、vSAN HCL DBの情報がリセットされてしまう様でしたので、

アップグレード直後、以下のようにクラスタ稼働状態が「エラー」となってしまいます。

FILESV01_VxRail_ResourcePool_20170201_062.png


vSAN HCL DBを更新すればよいので、Web Clientのクラスタ管理画面でvSAN HCL DBを更新してください。

※インターネット経由のアップグレードした環境であれば即時更新可能です。

63.png

 

vSAN HCL DBを更新すれば、vSANヘルスチェックもOKになるのでvSANのアラームも解除で問題ありません。

FILESV01_VxRail_ResourcePool_20170201_064.png

 

以上、VxRail 4.0から利用可能になったインターネット経由でのアップグレード機能でした。

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。



2016年末にリリースされたVxRail 4.0から、従来の2U4NのQuanta製ハードウェアに加え、DELL製ラックマウントサーバをベースとしたモデルがラインナップに加わり、CPU、メモリ、ドライブ構成の他、ネットワーク構成の選択の幅も増え、より多くのお客様の要望、要件に対応できるようになりました。

 

今回は初期構成時のネットワークの組み方や、拡張時の制限など幾つかおさえておくポイントがありますので、以下にまとめたいと思います。

※あくまで私の所属する組織(NetOneSystems)で整理した情報となりますので、提案時の詳細確認や機能証明はDELL EMC社へのSRを上げてください。

※2017年1月31日時点で確認した情報となります。


※2017年4月11日に、DELLモデルのVxRailノードのPCIe追加NICの構成がオンボードNDCの10GbE形状と異なるRJ45 or SFP+で選択可能になった事を追記しました。

 

 

【VxRail 4.0の構成基本ルール】

  • 拡張時はVxRailソフトウェアバージョンが一致している事(VxRail 3.5 に VxRail 4.0のソフトウェアバージョンのノード拡張は不可、事前に3.5→4.0にバージョンアップしておく)
  • 異なるVxRailモデルの混在は可能(Gen2とGen3の混在、Quantaモデル、DELLモデルの混在など)
  • Virtual SANの基本ポリシーとして明らかに異なるパフォーマンスの混在は非サポート(1GbEと10GbEの混在、ハイブリッドとオールフラッシュの混在は不可)
  • VxRailとしての拡張はサポートしている構成であっても、容量・ドライブ性能が大きく異なるノードは全体のアンバランスとなるため、vSANのベストプラクティスとしてはなるべく避けた方がよい(Eシリーズ 8台の中にSシリーズ1台だけ拡張、など)

 

【ネットワーク構成のルール】

  • VxRailのノード拡張は同一ネットワーク速度の構成のみサポート。
    • 1GbEモデルと10GbEモデルの異なるネットワーク速度のノードの混在は不可(10GbE * 2ポートモデル と 1GbE * 4ポートモデルの混在NG)
  • 上位のスイッチがサポートしていればSFP+モデル(10G-SR)とRJ45モデル(10G BASE-T)の混在は可能
  • 1GbE * 4ポート構成はGシリーズ、Eシリーズ、Sシリーズのシングルプロセッサ構成 かつ RJ45モデルでのみサポート。
    • Eシリーズ、Sシリーズはオンボードの10G BASE-T * 2ポート + 1GbE * 2ポートの4ポートで構成され、10GbEポートは1GbEでリンクします。
  • シングルプロセッサ構成のEシリーズ、Sシリーズには追加の10GbE NICは搭載不可(オンボード10GbE NICのみ利用可能)

 

【ドライブ構成のルール】

  • ハイブリッドモデルとオールフラッシュモデルの混在拡張は不可(Virtual SANの仕様)。
  • シングルプロセッサ構成はハイブリッドモデルのみをサポート。
  • オールフラッシュモデルはデュアルプロセッサ構成、10GbEネットワーク構成のみをサポート。
  • 2U4Nモデル(Gシリーズなど)にドライブ追加する場合は、シャーシ筐体内の各ノードのドライブ構成は均等に追加する事。

 

【拡張時の制限・上限のルール】

  • 初期の4ノードは同一モデル・構成で組む
  • 1GbEモデルは最大8ノードまでの拡張が可能
  • 10GbEは最大64ノードまでの拡張が可能(33ノード以上の構成時はEMCへの構成確認の申請が必要)

 


それぞれ、文字だけだと分かり難いので簡単なイラストで説明します。

 

まずVxRailの拡張について、2U4Nのアプライアンス以外のモデルでも初期の4ノードは同一構成で組むことが求められます。

※5ノード以降は任意のモデルノードで拡張可能。

VxRail_Expand-01.png

 

初期構成に拡張のノードを追加すると、vSphereクラスタ(vSANクラスタ)が自動で拡張され、vSANのストレージ容量もオンラインで拡張されます。

VxRail_Expand-02.png

 

拡張がサポートされるのは、同じvSAN構成のノードのみです。

VxRail_Expand-03.png

VxRail_Expand-04.png

ハイブリッドとオールフラッシュの混在拡張、1GbEモデルと10GbEモデルの混在など、

パフォーマンスの違いが大きいノードを拡張する事はできません。

VxRail_Expand-05.png

VxRail_Expand-06.png

ノード単位での拡張は、初期の4ノードは同じ構成とする必要があります(Gシリーズならばシャーシスロットを全て埋める)

VxRail_Expand-07.png

5ノード以降は、任意のモデルを追加可能です。

※ただし、2U4Nモデルの場合は、同一シャーシ内の各4ノードは同一構成とする必要があります。

VxRail_Expand-08.png

SSD・HDDに空きスロットの余裕がある場合はオンラインで拡張可能です。

※ただし、2U4Nモデルはシャーシ内の各ノードで同一構成にそろえる必要があります。

VxRail_Expand-09.png

VxRail 4.0から登場したDELLサーバモデルは、オンボード ドーターカードにて

標準で10GbE 2ポート + 1GbE 2ポートが実装されています。

購入時にRJ45(10G BASE-T)モデル、またはSFP+(10G-SR)モデルを選択可能です。

※初期セットアップ時に利用しないオンボード1GbEは、EMCに申請(RPQ)を上げる事で、セットアップ後に仮想マシン用途などで利用可能。

VxRail_Expand-10.png

※DELLサーバモデルで1GbE * 4ポートの構成で組む場合は、Eシリーズ、またはSシリーズのシングルプロセッサ構成のRJ45モデルでのみサポートされます。

 

2CPU構成のDELLサーバモデルは、追加のPCIe デュアルポート 10GbE NICを装着可能です。

追加NICのインターフェースは、オンボードの10GbE NICの形状と同一のものとなります。

追加PCIe 10GbE NICの形状は、2017年4月のアップデートからオンボードNDCの形状と異なるものも選択可能となりました。


※初期セットアップ時はオンボードの10GbEでセットアップし、初期セットアップ完了後に任意の仮想マシンネットワークなどで拡張PCIe NICを利用可能です(拡張10GbEの利用時はRPQは不要)。

VxRail_Expand-11.png

追加PCIe 10GbE NICの形状は、2017年4月のアップデートからオンボードNDCの形状と異なるものも選択可能となりました。

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。


※本記事は2016年時点のVxRail 4.0での問題でしたが、その後のバージョンアップで改善しておりますので過去の情報として参照ください。



VxRail Managerを利用したクラスタの全シャットダウンは非常に便利な機能なのですが、

このシャットダウンのフローの中でクラスタの「DRS」が無効にされます。

 

DRSを無効にする事で、次回起動時に管理VMがノード1に集まっている状態で起動できるようにするための仕様なのですが、

DRSが無効になると「リソースプール」が全て削除されてしまいます。

 

仮想マシンのリソース割り当てをコントロールするためにも重要な機能ですし、

沢山の仮想マシンを用途ごとにまとめるフォルダとして利用される場合もありますので、

これが意図せず削除されてしまうと設定の戻しは非常に面倒です。

 

これを防ぐためには、

クラスタ全シャットダウンの前に、DRSを手動で無効化し、DRS設定のスナップショットを保存しておくことが必要です。

※全シャットダウン時とは別に、定期的にスナップショットを保存しておく事が推奨です。

 

以下、DRS リソースプールスナップショットの取得方法をご紹介します。

 

【通常のクラスタ全シャットダウン手順】

Shutdown_01png.png

クラスタのシャットダウンボタンを押します。

計画停電時や、機器の移設時に便利な機能です。

 

FILESV01_VxRail4.0_Upgrade_20161207_075.png

「確認」を押します。

Shutdown_02png.png

最初のステップで無慈悲にDRSが無効化されるので、リソースプールは残念ながらすべて削除されます

 

次回起動時にリソースプールが無い!と慌てないように、クラスタ全シャットダウンの前に、手動でDRSを無効化してスナップショットを取得しておきましょう。

 

 

【リソースプールのスナップショットの取得方法】

Shutdown_03.png

クラスタの管理ViewでvSphere DRSの「編集」ボタンをクリック

 

Shutdown_04.png

「vSphere DRSをオンにする」のチェックを外し、「OK」。

 

Shutdown_05.png

ここでリソースプールがクラスタに存在すると、リストア用のスナップショットを保存するかどうか確認されるので必ず「はい」を選択する。

 

Shutdown_06.png

スナップショットはvSphere上ではなく、Web Clientを開いているクライアントPC上にファイルで保存されます。

無くさないように、定期的に管理者が利用するファイルサーバなどに保存することをお勧めします。

スナップショットがあればリソースプールを間違って消してしまったり、違うリソースプールに仮想マシンを間違って移動してしまった場合にも一瞬で戻せるので重宝します。

 

 

【リソースプールスナップショットのリストア方法】

クラスタの再起動後、削除されてしまったリソースプールをスナップショットからリストアするには、

「クラスタ」を右クリックし表示されるメニューで「リソースプールツリーのリストア」を選択します。

Shutdown_07.png

 

すると以下の画面が表示されるので、保存していたスナップショットファイルを「参照」から選択します。

shutdown_08.png

「OK」を押せばリソースプールは仮想マシンの配置も含めて一瞬で元通りとなります。

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。


VxRailに限らずvSphereを導入する際、必ずvCenter、ESXiともに参照先DNSサーバの設定が必要となります。

※DNSサーバと合わせてNTPサーバの設定も重要です。

 

vSphere 6.x以降のWeb Clientを利用したことのある方は恐らく気付く動きですが、

Web ブラウザにvCenterのIPアドレスを打ち込んでWeb Clientを開いた場合も、必ずSSOが動作するPSCサーバに対してFQDNでブラウザ画面がリダイレクトされて認証連携されます。

仮想マシンコンソールが開かない、プラグインが正しく動作しない、といった場合もDNSの参照が正しく動作していない場合にみられる事象です。

 

それ以外にもvSphere 6.x以降では各コンポーネント間がSSOで連携する際に裏ではFQDNでお互いが参照されていますので、NSX、vRA、vDPなどコンポーネントの導入時もそれぞれがFQDNで名前解決できるようにする必要があります。

 

当然、VxRailでもDNSサーバの設定は重要となってきます。

VxRailには2つのvCenterのモード、VxRail 組み込みのvCenter、PSCを利用するモードと、お客様が利用している既存のvCenterを利用する外部vCenterモードがあります。

それぞれのモードで、各コンポーネントのDNS参照先が異なるので、以下イラストで説明します。

 

 

【組み込みvCenter、PSC利用時】

まず、VxRailにデフォルトで組み込まれているvCenterを利用する場合のDNS参照の向きです。

ここでポイントになるのは、VxRailではLinuxベースのvCSAに「dnsmasq」と呼ばれる簡易DNSサーバサービスをインストールして、

vCenter、PSCをそれぞれDNSサーバとして動くように設定します。

これにより、もし外部のDNSサーバが利用できない場合でも、VxRailのコンポーネント間でのFQDNの通信は可能となるので、

隔離環境でDNSサーバを用意できない場合でも、VxRailのセットアップ、利用は可能となります。

 

embedded_vcsa_vxrail.png

※VxRail 初期セットアップ時に実行される事前検証(Validation)時に、その時点でアクセスできないDNSが設定されていると検証が失敗するので、隔離環境でセットアップする際はセットアップウィザードのDNSサーバ欄は空欄としてください。

後々、外部のDNS参照先を設定する際はdnsmasqサービスが参照しているフォアーダ先のDNSサーバを設定変更する事が可能です。

 

dnsmasqサービスの設定変更については以下KBが公開されていますので参照願います。

▼VxRail: How to modify the DNS server IP address for VxRail after the initial configuration

https://support.emc.com/kb/492132

 

※上記以外にも、VxRail Managerのコンフィグファイルの値も別途修正しておく必要がありますが、詳細手順は正式には公開されていないのでSRを上げてサポートを依頼してください。

参考までにどの様な箇所の変更が必要かかはVxRailのDNS、NTP、Syslog設定変更 にコメントしていますのでご確認願います。

 


【外部vCenter利用時】

VxRail 3.5以降ではお客様がお持ちの環境に用意されたvCenter配下にVxRailの各ESXiを追加可能です。

外部vCenterを利用する際はvSphere 6.0u2以降であること、空のデータセンター、何も設定していない管理用アカウントの作成などいくつか条件があります。

vSAN Stretched Clusterなどを検討される場合は外部vCenter構成が必須です。

 

外部vCenter利用時はdnsmasqサービスはインストールされないため、

vCenter、PSC、ESXi、VxRail Managerの各コンポーネントは必ず事前に用意された外部DNSサーバを参照する形となりますので、

事前に各コンポーネントがFQDNで名前解決できるようにレコードを登録してください。

external_vcsa_vxrail.png

外部vCenter利用時のDNSサーバ参照先の矢印はすべて外部DNSサーバに向いているので、外部DNSサーバの可用性は重要になってきます。

 


【FQDN、ホスト名の設定の重要性】

VxRailをセットアップ完了後、ホスト名を変更したい、ドメイン名を別のものにしたい、という要望がたまにありますが、

基本的にこれらはサポートされず、VxRailの初期化を伴う再セットアップが必要となります。

 

WebUIで気軽にセットアップが可能なVxRailですが、ホスト名やIPアドレスなど重要なパラメータは事前にしっかり設計する必要があります。

 

▼VxRail: How to change hostname of each components in VxRAIL

https://support.emc.com/kb/486258

VxRAILとしては上記のKBがありますが、実際にはvCenter Serverの仕様によって変更が困難となります。

 

※関連KB:

▼vCenter Server または Platform Service Controller の IP アドレスまたはホスト名を変更するとサービスで障害が発生する (2139374)

https://kb.vmware.com/kb/2130599

----

vCenter Server または PSC の Primary Network Identifier (PNID) を変更することは現在サポートされておらず、そうすると vSphere サービスが起動に失敗します。

vCenter Server または PSC が PNID として FQDN または IP を使用してデプロイされている場合、この構成を変更することはできません。

 

この問題を解決するには、次のいずれかのオプションを使用します。

•IP アドレスまたはホスト名を変更する前にスナップショットまたはバックアップに戻す。

•vSphere 環境を再デプロイする。

----

 

▼VMware vCenter Server Appliance 6.0 の IP アドレスを変更しようとすると次のエラーで失敗する: このノードの IPv4 構成 (nic0) は、デプロイ後に編集することはできません。 (2132705)

https://kb.vmware.com/kb/2132705

 

 

【おまけ】

DNSサーバに次いで重要となるNTPサーバも、初期セットアップ後に設定を変更する場合のKBが公開されていますので、

変更する場合は以下のKBを参照願います。

 

▼VxRail: How to change NTP server after VxRail is built

https://support.emc.com/kb/493891

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。


EVO:RAILのころから直近のVxRail 3.5までは、2U4Nのアプライアンス型で アップリンクのネットワークが10GbE * 2Port固定(または1GbE * 4Port)でしたが、 VxRail4.0ではDELL HWモデルが加わり10Gの追加ポートでの構成が可能になったため、 従来のvMotionネットワークの帯域制御や、VSANネットワークのAct-Stbのアップリンクをテレコに組んでのトラフィックの分散していたパターンから、vSphereの機能であるNetwork IO Control v3(NIOCv3)での帯域制御に切り替わりました。

何がどう変わったか、実機の画面キャプチャを交えてご説明します。

■VxRail 4.0のNIOCv3のデフォルト設定値

まずはVxRail 4.0での各物理NICポートとポートグループの冗長の組み合わせと、NIOCシェア値は以下のようになります。

■1GbE * 4Portモデル

トラフィックタイプUPLINK1(1Gb)UPLINK2(1Gb)UPLINK3(1Gb)Uplink4(1Gb)NIOCシェア値
ManagementStandbyActive--40
Virtual MachinesActiveStandby--60
vMotion--StandbyActive50
vSAN--ActiveStandby100

■10GbE * 2Portモデル

トラフィックタイプUPLINK1(10Gb)UPLINK2(10Gb)UPLINK3(1Gb)UPLINK4(1Gb)NIOCシェア値
ManagementActiveStandby--20
Virtual MachinesActiveStandby--30
vMotionActiveStandby--50
vSANStandbyActive--100

※追加の10GbE * 2Portの構成は、初期セットアップ後に新規のvDSを作成し接続する事で任意の利用が可能の様です。
※ 2017/1/16 現在では、DELL EMC公式には未サポートの様ですが、vSphere FT 6.0など、専用の10GbEのネットワークを用意する必要がある機能も、DELL HWを利用して追加10GbE NICがあればFT 6.0 + vSANも VxRailで組むことが可能になるのではと考えています。  

■VxRail 3.5 実機でのvDS設定

まずはVxRail 3.5の画面を確認します。

VxRail3.5-4.0_Upgrade_20170113_008.png

VxRail 3.5のvDS(分散スイッチ)の名称は懐かしのEVO:RAILの名前が残っています。
そしてNIOCは無効です。

VxRail3.5-4.0_Upgrade_20170113_010.png

NIOCは無効なのでシェア値もデフォルトのままです。

VxRail3.5-4.0_Upgrade_20170113_012.png

その代わり、vMotionなどバーストトラフィックが発生しやすいものは、vDSの機能を利用してIn-Outで4Gbpsに帯域制御をかけていました。

■ VxRail 4.0のNIOCv3の設定値

VxRail 4.0を新規にセットアップするとNIOCが有効となり、以下の設定値がデフォルトで投入されます。また、4.0ではvMotion Networkに設定されていた帯域制御は削除されています。
※実機で検証したところ、VxRail 3.5から4.0へのアップグレードした場合は、NIOCは有効とならず、以前のvMtion Networkの帯域制御が有効のままなので、必要に応じて手動でNIOCの設定を投入することとなる様です。

VxRail4.0_NW_20170111_001.png

VxRail 4.0でのvDSの設定はNIOCがデフォルト有効になっています。
また、以前かラの設定ですが、隣接スイッチの検出プロトコルはデフォルトのCDPなので、Cisco以外のスイッチを利用の際はLLDPに変更可能です。

そして大したことではないのですが、今まで「EVO:RAIL Distributed Switch」だったvDSの名称が「Vmware HCIA Distributed Switch」に変更となってしまいました。
VxRail 3.5からアップグレードされた場合はvDSの名称は変わらないので、EVO:RAILの名前に愛着がある方はそのままの利用をお勧めします。

VxRail4.0_NW_20170111_006.png

VxRail 4.0の機能向上の本命のNIOCの設定画面は上記のようになっています。

重要な点は「シェア値」の設定であって、「予約」や「制限」ではないので、帯域に余裕があるときは各ネットワークが必要な分だけトラフィックを流すことが出来る事です。

 

HCIとして、ポリシーベースの制御がネットワークでも実装されるようになったことは非常に有益なことだと思います。

これに加え、VxRail Gen3 ハードウェアとしてリリースされたDELL HWベースのノードは10GbE NICを追加して、10GbE * 4ポート構成も可能なので、外部ストレージやvSphere FT、Stretch Cluster用の専用ネットワークなどいろいろな用途に対応できるようになるので、エンジニアとして非常に楽しみな製品だと感じています。

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。

 

VxRail 4.0で故障したドライブの交換操作が非常にやりやすく、親切になったのでご紹介します。

 

【確認できたVxRail 4.0でのドライブ交換の機能向上点】

  • ドライブ交換時にホストの再起動が不要になった(今まで再起動を要していたのが地味に嫌でした)
  • 取り外したドライブがアクティブな状態のときはパーティションを飛ばしてくれた
  • 装填したドライブにパーティションが存在すると警告を出してくれる(間違ってデータのあるドライブを挿した時のフェイルセーフ?)
  • とにかく簡単で早かった

 

■ドライブ交換の流れ

001.png

VxRail Managerで交換対象のドライブを選択し「ハードウェアの交換」をクリック。

※今回は正常なドライブで試したので、LEDがブルーですが気にしないでください。

 

002.png

「続行」をクリック

 

003.png

ドライブ交換を進めてよいかクラスタのチェックが走り、もう一度「続行」をクリック

 

005.png

取り外すドライブのデータを削除してパーティションを飛ばしてくれます。地味に親切。

 

008.png

ドライブを取り外す準備ができたので、ここで物理的に交換対象のドライブを引き抜き、新しいドライブを装填します。

そのあと「続行」をクリック。

※対象のドライブがどれか判るように、ドライブスロットのフロントLEDが点滅してくれます。

 

012.png

新しいドライブの初期化(Web Clientで確認するとvSANディスクグループへの追加)が走ります。

 

026.png

1分経たずに操作は終了です。ホストの再起動は不要であっさり終わりました。

 

028.png

今回、他の環境からドライブを持ってきたため、ディスクラベルが異なっていますが、ちゃんとvSAN ディスクグループに追加が完了したことが確認できます。

 

■番外編

今回、他のvSAN環境で利用していたドライブをそのまま挿してしまったため、「パーティションがあるぞ」と警告が出ました。

114.png

ちゃんと見ているんですね。

通常、故障ドライブの交換時にこういうことはないと思いますが、これが出たときはホストにSSHでログインして

/sbin/partedUtil delete <削除対象パーティション>

でパーティションを削除するか、vSphere 6.0u2以降ではWeb Clientでも簡単にパーティションの削除ができるので以下の手順を実施します。

 

116.png

対象のドライブを選択して「パーティションを消去」を実行。

 

118.png

今回はほかのvSANで利用していたため上記二つが確認できます。このまま削除してよいなら「OK」をクリック。

パーティションが削除されれば、あとは再度以下の画面で「再試行」をクリックすれば正しくvSANディスクグループに組み込まれました。

 

114.png

 

以上、簡単ですがVxRail 4.0でのドライブ交換手順でした。

※ドライブはCRUパーツですが、本番環境のドライブ交換はSolveDesktopの手順書を確認しながら慎重に実施しましょう。

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。


本投稿はvExperts Advent Calendar 2016への寄稿も兼ねて、

あまり一般的には使われていないvSAN Stretched Clusterがどんなものか、実際に2台のVxRailを利用してクラスタを組む際のポイントをまとめてみました。

画面キャプチャ多用していますので、こういう導入手順なんだ、と眺めていただければ幸いです。

 

今回はデータセンターを跨いでRTT 5ms以下で10Gbpsの帯域を持つネットワークはとても用意できないので、隣のラック、別のTop Of Rack スイッチに接続された2セットのVxRailアプライアンスを利用しました。

 

ラックやサーバールーム、建屋を跨いだVSANの可用性担保をFault Domainの機能を用いて実装するのですが、

通常のFault Domainではなく、Stretched Cluster用のVSAN Witnessを利用することで、2セットのアプライアンスでもFault Domainが構成可能となります。

 

※今回はvSAN 2Node Clusterを組む要領で、VxRail 2アプライアンス Stretched Clusterを組んでみたのでそのレポートです。

 

※実際に本番環境でVxRailでStretched Clusterを組む際にはDELL EMCにRPQ(Request Per Qualification)を申請し、サポート承認を得る必要がありますのでご注意ください。

 

VxRailでのStretched Clusterに関しては以下のWhite Paper、Tech Bookを参照にしました。

今回はラック跨ぎのStretched Clusterとしたため、本来必要となるデータセンター間、Witnessサイト間とのネットワーク遅延やL3 スタティックルートの設計など、細かな要件を端折っています。それぞれの要件についてはドキュメントを参照願います。

 

【DELL EMC VxRAIL PLANNING GUIDE FOR VIRTUAL SAN STRETCHED CLUSTER 】

https://www.emc.com/collateral/white-papers/h15275-vxrail-planning-guide-virtual-san-stretched-cluster.pdf

 

【VMware Virtual SAN 6.2 Stretched Cluster & 2 Node Guide】

http://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/vsan/vmware-virtual-san-6.2-stretched-cluster-guide.pdf

 

【VMware Virtual SAN Stretched Cluster Bandwidth Sizing Guidance】

https://www.vmware.com/files/pdf/products/vsan/vmware-virtual-san-6.1-stretched-cluster-bandwidth-sizing.pdf

 

 

 

■ VxRail 2Appliance vSAN Stretched Cluster の概要図

vsansc02.png

 

 

■ vSAN Stretched Clusterを組む前の事前準備

通常、VxRailはデフォルトでバンドルされている(出荷時にデプロイされている)vCenter Server Applianceを利用してクラスタをセットアップしますが、

vSAN Stretched Clusterの場合は、2セットのVxRailはデータと仮想マシンの格納場所として利用し、

vCenterは既設の管理クラスタ上に、vSAN Witness Applianceとともに設置したものを利用します。

 

※VxRail 3.5以降では外部vCenter(External vCenter)構成も正式にサポートされているので、既存で利用しているvCenter配下にVxRailのvSANクラスタを組み込むことも可能になりました。

 

FILESV01_VxRail4.0_StretchCluster_20161218_001a.png

今回はこのvCSAとPSCを別の管理クラスタ上に作成し、VxRailを格納する空のDetaCenter 「DataCenter-A」と「DataCenter-B」を作成しておきます。

 


■ vSAN Witness Appliance のデプロイ

vSAN Witness Appliance は所謂 Nested ESXiの様な形をしたvSAN Witness機能専用の軽量ESXiとして、vSphere上にデプロイします。

予めMy Vmwareから利用するvSANと同じバージョンのvSAN Witness Appliance のOVAファイルをダウンロードしておきます。

FILESV01_VxRail4.0_StretchCluster_20161218_037.png

OVAテンプレートのデプロイは通常の仮想アプライアンスの導入と変わりありません。


FILESV01_VxRail4.0_StretchCluster_20161218_046.png

サイズや配置先データストアは用途によって異なりますので割愛しますが、

vSAN Witness Appliance はvCenterとの通信、vSANの通信が必要となるためデプロイ先のクラスタのネットワークには、

予めvSANネットワークとの疎通のあるポートグループを作成しておきます。

※リモートサイトに置く場合など、L3でのルーティングが必要な場合はStatic Routeを設定しておきます。

 

FILESV01_VxRail4.0_StretchCluster_20161219_009.png

デプロイしたvSAN Witness Appliance を起動すると、見た目は普通のESXiのコンソールが立ち上がります。

通常のESXiを初期設定するように、IP、ホスト名、DNSなどの設定を投入します。

ここではSSHを有効にしておくと後々の設定変更に便利です。

 

FILESV01_VxRail4.0_StretchCluster_20161219_017a.png

初期設定が終わったvSAN Witness Appliance は外部vCenterとなるvCSAとPSCと同じ環境に設置しました。

 


■ Stretched Cluster プライマリサイト側VxRail のセットアップ

 

今回は前項で事前に用意したExternal vCenter環境配下にVxRailを展開します。

FILESV01_VxRail4.0_StretchCluster_20161218_073.png

お馴染み(?)のようこそ画面からいつも通りVxRailをセットアップします。


FILESV01_VxRail4.0_StretchCluster_20161218_077.png

今回は最新のVxRail 4.0を利用したので、初期セットアップ時にどのアプライアンス、どのノードに対してセットアップを行うかがスキャンされるようになりました。

最小は3ノードから構成可能です。

 

FILESV01_VxRail4.0_StretchCluster_20161218_081a.png

いつもと違うセットアップ項目は以下の画面で「既存のvCenter Serverの結合」「外部 Platform Service Controller」にチェックを入れ、

既存環境のFQDN、vCenterの認証情報を投入しておく事です。

今回は予め作成済みの「DataCenter-A」 配下に「vSAN StretchCluster」を作成してVxRailが組み込まれるようにします。

 

FILESV01_VxRail4.0_StretchCluster_20161218_089.png

設定内容に問題がなくValidationが通ればVxRailのセットアップが始まります。

※ここでValidationが失敗する例として、DNSでのFQDNでの名前解決が通らない事や、VxRailのアップリンクの10Gスイッチの設定漏れ、特にvSANが利用するマルチキャストの設定漏れなどがありますので、エラーが出たらメッセージに従ってネットワーク周りを重点的に確認しましょう。

 

FILESV01_VxRail4.0_StretchCluster_20161218_099.png

External vCenterを利用する場合、vCSAのFirst boot scriptなど時間がかかる処理がないので、それこそ10分もあればVxRailのセットアップはあっという間に完了してしまいます。

 

FILESV01_VxRail4.0_StretchCluster_20161218_118.png

セットアップが完了すると、External vCenterでは以下のようにクラスタに格納されます。

 

FILESV01_VxRail4.0_StretchCluster_20161219_004.png



■ 次にvSAN Witness Appliance を「DataCenter-B」にESXiホストとして追加します。

FILESV01_VxRail4.0_StretchCluster_20161219_023.png

追加方法はいたって簡単。

 

FILESV01_VxRail4.0_StretchCluster_20161219_027.png

デプロイ後、VMkernel アダプタの設定を確認するとvSAN用ポートが設定されていないので、IPを割り当てます。

FILESV01_VxRail4.0_StretchCluster_20161219_032.png

 

vSAN VMkernelにIPを割り当てた後は、

vSAN Witness Appliance にSSHでログインし、それぞれのVxRailノードのvSANカーネルに対してvmkpingでIP疎通があることを確認しておきましょう。

 


■ Stretched Cluster セカンダリサイト側のVxRailのセットアップ(既存へのノード追加)

FILESV01_VxRail4.0_StretchCluster_20161219_034a.png

VxRailのノード追加は非常に簡単で、既存VxRailと管理ネットワークの疎通がある状態で追加ノードの電源を投入すると自動検知され「ノードが検出されました」と追加ウィザードのボタンが有効になります。


FILESV01_VxRail4.0_StretchCluster_20161219_035.png

追加ノードに必要なパラメータは各ノードのVMkernelに割り当てるIP(管理・vMotion・vSAN)と、既存のESXi、vCenterのパスワードのみです。

ここで4ノード追加するので予め4つ分まとめてレンジでIPを投入しました。

 

FILESV01_VxRail4.0_StretchCluster_20161219_041.png

追加は初期導入よりもっとスピーディで、1ノードあたり3分~4分で完了します。

スケールアウトの簡単さはHCIのメリットですね。


FILESV01_VxRail4.0_StretchCluster_20161219_045.png

4ノードすべて正常に拡張が完了しました。

 

 

■ vSAN Stretched Clusterの有効化

 

今回のメイン、vSAN Stretched Clusterを有効化します。

FILESV01_VxRail4.0_StretchCluster_20161219_051a.png

前項までに初期セットアップが完了したVxRailノード合計8台があります。

ここではStretched Cluster(拡張クラスタ)もFault Domainもまだ設定されていません。

 

まずはStretched Clusterを有効化します。


FILESV01_VxRail4.0_StretchCluster_20161219_054.png

まず8台のノードを、プライマリサイトの4台と、セカンダリサイトの4台で分けます。

※今回は同一サイト内・別ラックで構成しているのでラック全断障害などを想定した構成です。

 

FILESV01_VxRail4.0_StretchCluster_20161219_056.png

監視ホスト(vSAN Witness)の設定は「DataCenter-B」に配置したvSAN Witness Appliance を選択します。

 

FILESV01_VxRail4.0_StretchCluster_20161219_061.png

設定はすぐに反映されます。

メインの作業はこれだけです。拍子抜けするほど簡単ですね。

 

■ vSAN Health Checkでエラーがないか確認

見た目なにもエラーがなくても油断しないでHealth Checkを確認しましょう。

vSphere 6.0 u1からはvCenterにデフォルトで組み込まれたHealth Check (以前はpluginで配布されていた)は

vSANの構成、データの同期状態など細かく状態確認が可能です。

FILESV01_VxRail4.0_StretchCluster_20161219_064a.png

ここではvSANを構成する8台のノードと、vSAN Witnessで詳細設定(ノード拡張上限、ネットワークヒープ値)が異なると指摘されているので、vSAN WitnessにSSHでログインしてさくっと直してしまいます。

 

[root@rgm-96x:~] esxcli system settings advanced set -o /VSAN/goto11 -i 1

[root@rgm-96x:~] esxcli system settings advanced set -o /Net/TcpipHeapMax -i 1024

 

変更したらvSAN Witnessを再起動し、警告が消えたことを確認します。


 

■ その他の健全なクラスタ運用のための諸設定

ここまででだいたいvSAN Stretched Clusterの設定は完了しましたが、

通常のHAクラスタの冗長性で考慮するN+1の構成ではなく、今回は1+1の構成なので、サイト障害時(片系アプライアンス全断)時には

リソースの負荷が残った方にすべてフェイルオーバーしてくるので、HAのアドミッションコントロールの予約値を50%に設定しておきます。

 

FILESV01_VxRail4.0_StretchCluster_20161219_070a.png

Active - Active のStretched Clusterを組むからには太っ腹であることが重要ですね。

 

また、仮想マシンを作成する際にも、どの仮想マシンが通常時どちらのサイトで稼働するかを指定しておいた方が

負荷のバランスと管理が行いやすくなります。


FILESV01_VxRail4.0_StretchCluster_20161219_077a.png

ここではDRSのアフィニティルール 「仮想マシンからホストへ」を利用して、仮想マシンが稼働するサイトを指定します。


FILESV01_VxRail4.0_StretchCluster_20161219_078.png FILESV01_VxRail4.0_StretchCluster_20161219_079.png

プライマリサイトのホストと仮想マシン、セカンダリサイトのホストと仮想マシンをそれぞれ

「グループ内のホスト上で実行してください」という英語表記では「Shuld」でルールを作成します。

※ここで「グループ内のホスト上で実行する必要があります」という英語表記での「Must」でルールを作成すると仮想マシンがフェイルオーバーできなくなってしまうので注意してください。

 

ここまで作成すれば、正常な状態時には仮想マシンの配置と、データの配置がきれいに管理でき、vSAN Health Checkの以下の画面で仮想マシンのデータの配置場所(どのホストのどのドライブに格納されているか)が簡単に確認できます。

FILESV01_VxRail4.0_StretchCluster_20161219_080.png

 


■ vSAN Stretched Clusterでの障害試験、HA挙動

 

最後に、組みあがったvSAN Stretched Clusterで障害(片系アプライアンス全断)の挙動を確認してみます。

以下の画面はIPMIでセカンダリサイトの全ノードを強制電源Offにした直後の画面です。

FILESV01_VxRail4.0_StretchCluster_20161219_082.png

きれいに半分にアラートが上がっています。

上で動いていた仮想マシン、今回はMS-07 ~ MS-09までが稼働していましたが、無事にHAが働き、プライマリサイトのノード上で再起動されたようです。


FILESV01_VxRail4.0_StretchCluster_20161219_085a.png

片系アプライアンス全断時には各仮想マシンのミラーされたデータの片方へのアクセスが出来ないので、

vSAN Health Check 上では以下のようにコンプライアンスエラー状態となります。


FILESV01_VxRail4.0_StretchCluster_20161219_086.pngFILESV01_VxRail4.0_StretchCluster_20161219_090.png

このエラー状態も、全断していたアプライアンスが起動してくれば元通りになります(デフォルトでは1時間以内の復旧時は差分データの同期のみで完了)。


■ まとめ

今回はデータセンター跨ぎではなく、ラック跨ぎのvSAN Stretched Clusterの作成でしたので、WitnessサイトへのL3ルーティングの設定や、サイト間遅延時間の考慮などは特にせず簡単に作り上げることが出来ました。

アプライアンス筐体障害やラック電源障害などによる全断を回避するための構成として度々Fault Domain構成は提案する事があるのですが、最低3ドメイン必要となるためなかなかハードルが高かったところを、vSAN Witnessを代用する事でシンプルに組むことが出来ました。

 

VxRailとして本番利用するためにはRPQを通してサポート承認が必要となりますが、

vSANとしてはこのように簡単に組むことが出来るので、ぜひ皆さんも一度試してみていただければと思います。

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。



先週12月5日にVxRail 4.0がGAされたので早速アップグレードを試してみました。

非常に簡単で数クリックするだけで、4台のESXiへのpatch適用も含め、約60分でアップグレード作業が完了しました。


画面キャプチャばかりですが、アップグレードの作業の参考にしていただければ幸いです。

 

※EMC製品のアップグレードは必ず事前にプロダクトガイド、SolveDesktopの手順書を参照して作業することが前提です。

 

■アップグレードの事前準備

※アップグレードに必要なバイナリはSupport EMCからDL可能です。

https://support.emc.com/downloads/41560_VxRail-Appliance-Famil

 

FILESV01_vdp92error_20161212_020.png

VxRail 3.5からVxRail 4.0へのアップグレードには

  • VxRail Managerのアップグレード用パッケージ(VxRail Manager Upgrade Package 4.0.0)
  • ESXi 6.0u2 → 6.0P3 アップグレード用パッケージ(VxRail Composite Package 4.0.0)

の二つが必要となるので事前にDLしておきます。

 

■VxRail Managerのアップグレード

まずVxRail Managerを4.0にアップグレードします。

 

VxRail Managerにアクセスし、「構成」 > 「機能」を開き、「更新」ボタンから「ローカルバージョンのアップロード」を選択し、前項でDLしたVxRail Managerのアップグレードパッケージをアップロードします。

FILESV01_VxRail4.0_Upgrade_20161207_003a.png

FILESV01_VxRail4.0_Upgrade_20161207_005a.png


ファイルのアップロードをしばし待ちます。

FILESV01_VxRail4.0_Upgrade_20161207_007.png


アップロードが完了したら、「インストール」をクリックします。

FILESV01_VxRail4.0_Upgrade_20161207_008a.png


アップグレード実行前の診断プロセスが走りますので、完了後「今すぐアップグレードしてください」をクリックします。

FILESV01_VxRail4.0_Upgrade_20161207_014a.png


VxRail Managerの再起動含め、だいたい10分くらいでソフトウェアの更新が完了します。

FILESV01_VxRail4.0_Upgrade_20161207_018.png


■アップグレードの確認と、ESXiへのpatch適用


VxRail Managerのセッションに再度接続するとバージョンが4.0になった事が確認できました。

そしてメニューには「インターネットアップグレード」が標準の表示になっています。

今後のVxRail 4.0.x、4.xへのアップグレードはインターネットの接続が利用できれば、Support EMCから事前にファイルをDLしなくても、直接アップグレードが可能になるようです。

FILESV01_VxRail4.0_Upgrade_20161207_027a.png

※右下のロゴも「DELL EMC」に変更されてます。


次にESXiのアップグレード(patch適用)を行います。

今回は事前にDLしたESXiのパッケージを手動でアップロードします。

FILESV01_VxRail4.0_Upgrade_20161207_031a.png


アップロードが完了するまでしばらく待ちます。

FILESV01_VxRail4.0_Upgrade_20161207_035.png


アップロードが完了したら「続行」ボタンをクリックします。

※今回はVxRailのクライアントエージェント(marvin VIB)のアップグレードと、6.0u2 → 6.0p3へのアップグレードが行われます。


FILESV01_VxRail4.0_Upgrade_20161207_036a.png

 

アップグレードが開始されると、VxRail Managerのクラスタ管理モードが抑制モードに自動で切り替わり、

  • 各ノードのVxRail Manager VIB(marvin)のアップグレード
  • 各ノードのESXiのpatch適用(6.0u2 → 6.0p3)

が開始されます。

※「詳細」メニューを開くと、現在の進行状況が細かく把握できます。

FILESV01_VxRail4.0_Upgrade_20161207_050.png

 

裏で動くvCenterに接続してみると、ESXiへのpatch適用に関する一連のオペレーションが自動で実行されていることが確認できます。

※個人的には面倒だった個別VIBの適用や、仮想マシンの退避を含むpatch適用の一連操作がvUM(vSphere Update Manager)を準備しなくても一括で実行できるのが非常に気に入りました。

FILESV01_VxRail4.0_Upgrade_20161207_052a.png

 

アップグレードはVSAN クラスタを構成する各ノードが順々にメンテナンスモード → 再起動が実行される形で行われ、稼働中のVMは別のホストにvMotionで自動的に退避されながらローリングアップデートが実行されます。

※仮想マシンの自動退避しながらのローリングアップグレードは「DRS」が有効なライセンス(Enterprise plus、vSphere Desktopなど)が必要です。

vSphere Standard Editionの場合は仮想マシンのvMotionは手動で行う必要があるようです(私はまだ試せていません...)

 

■アップグレードの完了

今回はVxRail 120 Hybrid VSANモデルで試しましたが、

VxRail Managerのアップグレード(再起動含む)に約10分、4台のESXiのpatch適用(それぞれの再起動)に50分、合計60分でVxRail 4.0へのアップグレードが完了しました。

FILESV01_VxRail4.0_Upgrade_20161207_068.png

FILESV01_VxRail4.0_Upgrade_20161207_069a.png

 

今回はVxRail 3.5 → 4.0へのオンラインアップグレードの一連の流れをご紹介しました。


デビッド ウェブスター(David Webster)

APJエンタープライズ担当プレジデント、Dell EMC

 

自動運転車で通勤したり、夕食の献立について冷蔵庫と会話したり、AI(人工知能)を実装したチャットボットからカスタマー サービスを受けたりする。このようなことを生きているうちに体験できるかもしれないとは、驚くべきことです。テクノロジーの発展は、以前であればフィクションだったこのようなシナリオを、もうまもなく実現しようとしています。

 

Realizing 2030_Planets_TW.jpg

これらのソリューションを現実化するために飽くことなくイノベーション(革新)を進めていく中で、私たちはマシンとの相互関係を根本から変えることになります。実際、最近デル テクノロジーズが発表した「Realizing 2030: A Divided Vision of the Future」によると、アジア太平洋および日本(APJ)地域のビジネス リーダーの大部分(80%)が、5年以内に人とマシンが統合チームとして仕事をするだろうと考えています。

 

APJ地域の企業はデジタル トランスフォーメーションの過程で新しいテクノロジーを導入しており、これらのテクノロジーがより多くの人とマシンのパートナーシップへの道筋を作り出しています。例えばAIについて、この調査ではビジネスリーダーの81%が5年以内にAIによって顧客のニーズを先取りできるようになることを見込んでいます。これは前向きで明るい結果ですが、新しいテクノロジーおよびこれらのテクノロジーが生み出す膨大な増加データから企業が最大限の価値を引き出すためには、クラウド コンピューティングへのアプローチについて正しいITトランスフォーメーションの判断をすることが欠かせません。デジタルを背景にした新たな要件によって、既存のITインフラストラクチャはたやすく打ち破られるでしょう。

 

APJ地域のビジネス リーダーとITリーダーは、残念ながら今でも過去に下した意思決定からの重荷を引きずっています。大抵の場合、クラウドの導入は幅広い戦略の一部というよりは数ある項目の1つに過ぎません。これまで長年にわたりパブリック クラウドの導入が進められてきていましたが、現在プライベート クラウドやハイブリッド クラウドへのシフトおよび多様なビジネス ニーズとワークロードに応えるクラウド サービス プロバイダとのパートナーシップが進んでいます。例えば、スピードと効率の向上という観点から一定のワークロードがオンプレミスへ戻されている一方で、パブリック クラウドは非ミッション クリティカルなワークロードに対して利用される場面が増えています。実際、IDC社はAPJ地域のエンタープライズ企業の70%以上が2018年までにマルチクラウド戦略を採用するとしています。

 

multi-cloud.pngこのようにマルチクラウドが未来の方向性であることは明らかですが、企業はこの現実がもたらす複雑さとニーズの管理について、大きな課題に直面しています。企業には、データのやり取りを簡単に行えるとともにマルチクラウド インフラストラクチャをシンプルかつシームレスに管理できる戦略が必要です。

 

このような複雑さに対処して新たに出現するテクノロジーから最大限の価値を引き出せるようにするには、コラボレーションに重点を置く必要があります。企業が最適なコラボレーティブ アプローチを確立するためにはどうすべきなのか、その方法を紹介します。

 

顧客を中心に据える

今日の市場においてカスタマー エクスペリエンスは重要な差別化要因で、新しいカスタマー エンゲージメント モデルへの移行にマルチクラウド環境が使われる場面が増えてきています。前出の調査「Realizing 2030」において、カスタマー エクスペリエンスを役員会レベルの事案として取り組むことを優先事項であるとしているAPJ地域の企業は、10社中9社近くに上ります。社内外を通じたさまざまな相手先との世話役として、IT部門およびCIOの戦略的役割が高まるのに伴い、すべての関係者が質の高いカスタマー エクスペリエンスの提供に集中できるようにすることは、コラボレーションとパートナーシップを醸成する上での助けになります。

 

applications.pngデータがすべての要であることを認識する

あらゆる業種を通じて、イノベーションの実現、高品質なカスタマー エクスペリエンス、差別化の促進における鍵となるのが、クラウド ネイティブ アプリケーションです。APJ地域のビジネス リーダーのうち、すでにアプリケーションをパブリックまたはプライベート クラウド(ハイブリッド クラウドなど)へ移行するテクノロジーに投資しているとしたリーダーが45%に上り、今後5年間で投資を行う予定であるとしたリーダーが47%に上るのも不思議はないでしょう(「Realizing 2030」調査)。

 

ただし、これはテクノロジーだけの話ではなく、適切な人材とスキルへの投資も含まれています。今日のマルチクラウドの世界では、単なるクラウド ネイティブ アプリケーションの提供の先へと進化していくためのDevOps へのニーズも出現しています。新たに出現しているさまざまなテクノロジーによってデータ量が増加している中、DataOps の到来を認識し、効果的なコラボレーション方法を見つけてデータを管理できる企業が、デジタル トランスフォーメーションを加速させることができます。

 

将来に焦点を当てたパートナーシップを組む

マルチクラウドは単なる始まりにすぎません。私の同僚でDell EMCのCTOであるジョン ローズ(John Roese)は、2018年の予測の中で、複数のクラウドシステムが連携して相互作用するメガクラウドこそが未来であると述べています。メガクラウドは次世代のITインフラストラクチャで、IT部門と業務部門は社内で真の戦略的パートナーシップを構築することに集中し、これまで以上に緊密なコラボレーションを実現しなければなりません。

 

ITのリーダーシップについて、Dell EMCのAPJ担当CIOであるヘマル シャア(Hemal Shah)は、このパートナーシップ アプローチの発展に対する見解を的確にまとめています: 「規模が大きな企業では小規模で自己充足的な専任チームが出現しており、イノベーションに焦点を当てた活動を展開するとともに、アプリケーション開発者やデータ サイエンティスト、またIT部門で他の役割を担っているスタッフに、上級役員と連携して新たな機会を認識するための機会を提供しています」。

 

テクノロジーが進化を続けていく中で、企業は将来出現するトランスフォーメーションの大きな課題に対処できる十分な効率性と俊敏性を確立してメガクラウドの基盤を構築するために、今日、緊密なコラボレーションを構築することに集中する必要があります。

 

新たに出現しているさまざまなテクノロジーは、私たちの生活に信じられないような数多くの変革をもたらすでしょう。このような未来を現実化する上で、クラウドは欠かすことのできない重要な役割を果たします。私たちがクラウドを利用する方法は、急速に変化しつつあります。これらの新しいテクノロジーから真の価値を引き出すためには、このような進化と適切な文化を対にして組み合わせる必要があります。コラボレーションに重点を置くことによって、APJ地域のビジネス リーダーは、それぞれの企業組織をデジタル トランスフォーメーションに向けたより円滑でより高速な軌道に乗せることができるでしょう。

【全6回シリーズ4/6 新時代のデータ保護】

ITジャーナリスト 大西高弘

 

数年前からITセキュリティの世界で「複合防御」という言葉が頻出するようになってきた。何を「複合化」するのかというと、「マルウェアなどのセキュリティ侵害を遮断する」という手法と、「侵入された場合に被害を最小限に食い止める」手法を合わせて対策をとるということだ。何が何でも水際でシステムを守る、という発想では、セキュリティ対策としては万全とはいえない、ということは、かなり以前から専門家の間で言われてきたことである。

 

そんな矢先、ランサムウェアの被害が世界中で報告されるようになり、日本企業にも被害が出た。ランサムウェアは、OSなどの脆弱性をついてシステムに侵入する、という点では従来のマルウェアと変わらないが、データをコピーして盗みだすということはしない。データを暗号化して乗っ取り、復号キーと引き換えに金を出せ、という手法を使う。

 

しかし、言い方は悪いがこのやり口ならまだましだ。金さえ払えばデータは復号できる。もっと悪質なのは、結局金銭を払っても復号キーを渡さなかったり、中には、金銭の要求も何もせず、ただデータを破壊してしまうだけのケースや、復号手段がない暗号化をしまうケースも出現しつつある。つまり、愉快犯のような攻撃者もいるということだ。

 

サイバー犯罪者の中には、ある種の思想信条の下に攻撃相手を定めて悪事を働く者もいるようだが、それだけではなく、金銭を詐取するという目的もなく、ただ世間を騒がせたいというタイプもいる。しかも、特別なスキルがなくてもマルウェアを入手して、改良を加えてどこかに侵入させる、というケースもある。

 

ランサムウェアの「流行」のせいで、データを乗っ取り、破壊するという行為をもっと高度な技術を使って行う攻撃者も今後出てくるだろう。

 

いまの時代、企業の重要なデータは、紙で記録されていない。ほとんどが電子化されている。すべて丸のみされてしまえば、その瞬間から会社はすべての機能がストップしてしまう。

 

●「ランサムウェア対策にはバックアップしていれば大丈夫」というのは昔の話?

 

「複合防御」の考え方からすれば、ランサムウェアに侵入されてしまったときの対策をどう打つかがポイントになる。本番データが乗っ取られても、バックアップデータから復旧、またはDRサイトへ切り替えての運用をすればビジネスは継続できる。

 

しかし、この方策も実は危うい、ということが分かってきた。最近では、攻撃者は先回りしてバックアップデータやDRサイトから先に乗っ取り、あるいは破壊する手口を使うようになってきたからだ。

 

では、どうすればいいのか。

 

データ保護ソリューションに詳しい、Dell EMC(EMCジャパン株式会社)DPS事業本部 事業推進部 シニア ビジネス ディベロップメント マネージャー の西頼大樹氏は、次のように話す。

 

「まず、データの乗っ取りを防ぐには、バックアップデータへのアクセス方法を複雑・堅牢化することで、侵入「検知」から「対応」までの間、乗っ取られるリスクを抑えること。そして、データそのものを、外部からアクセスしにくい場所(条件下)に置くことです」

 

狡猾な攻撃者は、システムに侵入するとまずその全体像を把握し、バックアップデータなどの復旧手段のありかを探し当て、システム管理者に成りすますなどして、データにアクセスする。誰か1人のアカウントを乗っ取ればバックアップデータに簡単にアクセスできる体制を変え、複数の承認を得ないとデータそのものにアクセスできないようにすることで、簡単にはデータを破壊・暗号化してしまうことはできない。

 

また、バックアップデータの格納場所が常にネットワークでつながっていることは、攻撃者にとってこれほどいい環境はない。そこで、最後の砦となるバックアップデータは、やり取りをするときだけネットワークにつながり、普段は、遮断されている環境に置いておけば、リスクは大幅に軽減されるというわけだ。

 

西頼氏は、ある海外の海運会社の例を話す。

 

「その会社は大手の海運会社で、貨物管理に関わる本番システムだけでなく、バックアップデータのあるDRシステムも乗っ取られてしまいました。世界中の海で船に積んでいる荷物を一体どこに運べばいいのかもわからなくなってしまったんです。しかし、複数あるDRサイトのうち1カ所だけ、システムメンテナンスのためネットワークから遮断されていて、乗っ取られていなかった。そこでそのデータを使って事なきを得たということです。」

 

偶然とはいえ、まさに不幸中の幸いで、その会社はビジネスを復旧できたのである。ただ、このような規模のビジネス危機に直面することを考えた場合、「幸運」に頼る企業はいないはずだ。

 

●バックアップはあくまで手段、「サイバー復旧」の発想こそビジネス継続の要

 

昨今、ランサムウェアの被害が注目されているが、セキュリティ侵害はそれだけではなく、外部、内部からのさまざまな攻撃によって起こされる。「ランサムウェア対策にはデータバックアップ」という観点だけで対策を考えていくのではなく、もっと広い視野からセキュリティ対策を打つべきなのだろう。

 

「国内外の専門機関からは、ITセキュリティのフレームワークに、Recovery(復旧)という発想が重要だというメッセージが出されています。現にセキュリティの専門家がその動向をもっとも注視している米国国立標準技術研究所(NIST)は、サイバーセキュリティのフレームワークにおいて、『復旧』という機能を5大重要施策のひとつとして位置付けていますし、他の同様機関から同じようなメッセージが出始めています。」(西頼氏)

 

Dell EMCでは、すでに2015年からこの「サイバー復旧」に関するソリューションに力を入れているという。

 

まず、前述したバックアップデータへのアクセス方法を複雑化することと、データそのものを、外部からアクセスしにくい場所に置くこと、については、すでに同社ではデータ保護ストレージ「Dell EMC Data Domain」で実際に提供している。

 

アクセス方法を複雑化は、もともとData DomainにはRetention Lock機能というものがあり、これで実現できる。データの改変に関してのみ、システム管理者よりも高い権限を持ったセキュリティ管理者を複数名設定し、たとえシステム管理者、あるいはシステム管理者がアクセスを認めた人物がバックアップデータにアクセスしようとしても、そのセキュリティ管理者が認めなければ、誰もデータにアクセスや変更ができない仕組みだ。また、一度保存されたデータの閲覧はできても、改ざんできないようにすることも可能だ。

 

さらにアクセスしにくい場所にデータを置きたいというニーズについては、「エアギャップ」という仕組みがあり、Data Domainを活用してグローバルで100社以上の企業が導入している。「エアギャップ」自体は米国連邦金融検査協議会(FFIEC)が提唱したデータ転送時のみネットワーク接続を限定させる機能で、普段は利用企業のネットワークからは隔離されている。

 

DD.png                                         

※データギャップ機能の仕組み

 

「エアギャップ機能を使っても理論的には、転送時に攻撃を受ける可能性はあります。ですから、転送時間をできるだけ短くすることが大切です。Dell EMCがData Domainを前提とした理由はそこにあります。優れた重複排除機能が、転送するバックアップデータを重複排除された差分データに限定することで、接続時間≒転送時の攻撃リスクを極小化します。ケースバイケースですが、大規模なデータをバックアップしているユーザーでも、転送は一回に数分、数秒ということがほとんどです。」(西頼氏)

 

また隔離する仕組みを持つことで、隔離したData Domain内のデータを活用し、サイバー脅威に対する攻めの施策を検討することも可能になる。健全なデータの堅牢な保管・蓄積もさることながら、隔離されたバックアップデータを使い、最低限の再現環境を配備したうえでのサイバー災害対策テストの実施、隔離されたデータをオフラインでセキュリティ担当に、侵害の兆候や感染の有無を調べるテストデータとして提供することなど、応用できる範囲は多彩だ。

 

またDell EMCのテクノロジーを使うと、この仕組みを作るプラットフォームにパブリッククラウドを活用することも検討できるのがさらなるメリットだ。中核となるData Domainは、AWSやAzureでネイティブに動く仮想アプライアンス版を持っている。つまり、エアギャップで隔離するデータをクラウドに保存するという方法も検討できるのだ。また、隔離データとは別にクラウド内のData Domainアプライアンスを使ってデータの健全性を確認し、確認できたらデータを消去する形でのテストなど、低コストで「最後の砦」ともいうべきデータの健全性を保つことができる。

 

DD2.png

※クラウドを活用したバックアップデータの隔離

 

●大規模なバックアップデータをどう生かせばいいのか

 

「Retention Lock」や「エアギャップ」の機能を使った仕組みは、Data Domainでないと構築できない、というわけではない。しかし、Data DomainベースのCyber Recovery Solutionであれば、標準機能を活用することが前提となっているので、余分な構築作業などにコストをかけることなく、導入してすぐに利用開始できると西頼氏は話す。

 

「Data Domainは重複排除機能を世界で初めて備えたバックアップストレージです。もちろん、重複排除率は他社製品と比較してもトップクラス。エアギャップのメリットを最大化するには、バックアップデータの転送時間を可能なかぎり短くすることが必要なので、重複排除が重要なのです」(西頼氏)

 

バックアップデータを隔離した環境に置く、というならテープなどの別媒体を使うという手段も考えられるのではないか、と少しいじわるな質問をしてみると、西頼氏は次のように話してくれた。

 

「隔離した環境に置く、という意味でなら、そうした方法も否定するものではありません。しかしテラバイト、ペタバイト単位のデータを別媒体にとって置くという場合、果たしてそれが安全かどうか。テープ管理作業の工数負荷も考えなくてはいけないし、紛失、盗難などの心配も出てくる。それからテープには常に、メディア規格への追随や、データ自体が劣化してしまうリスクが付きまといます。そしてなによりも、そうして保存したデータを使って復旧する場合、いったいどれくらいの時間でビジネスを再開できるのか、ということも考えておくべきでしょう」

 

確かにサイバー復旧は、それが可能かどうか、だけではなく、どれくらいの時間でできるのか、ということも重要な要素だ。ディスクベースでの復旧がテープより速いのは想像がつくが、Data Domainを使えば、標準でDIA(非脆弱性アーキテクチャ)という自己修復機能が備わっているので、テープやディスクにおけるデータ破損など、リストアを実施した時にはじめて復旧できないことが判明するといった事態の事前防衛もできているという。

 

  

 

これまで、企業や組織・団体のIT担当者は、主として「このデータが盗まれたら」と考えてデータ保護関連のセキュリティ施策を講じてきた。しかし、これからは同時に「このデータが利用不可能にされたら」というケースも想定しなくてはならなくなった。

 

データを盗まれることは、損害賠償しなくてはならないこともあり、大きな損失だ。しかし、それ以上にデータが利用不可能にされることは「最大の悪夢」といえるだろう。ビジネスを動かすことができなければ、会社の存亡にかかわってくる。西頼氏によれば、海外の企業の中には、データを破壊されたことで、発覚してから数時間で倒産したケースもあるという。

  

そのような時代に入り、各ITベンダーもセキュリティについて新しいアプローチをとりつつある。たとえばDell EMCはDell Technologiesグループの一員だが、セキュリティ分野においては、同じグループ内のRSA、SecureWorksといった専業組織の技術を統合し、エンドポイントからバックアップまでデータ保護ソリューションを総合的に提供する体制を整えている。

 

ユーザーが求めるのは、オンプレミス、クラウドの区別なく効果的な「複合防御」を実践できる仕組みだ。どんな新手のサイバー攻撃が登場しても、ビジネスの継続は担保したい。その意味で、今後、「サイバー復旧」という視点は、ITセキュリティの分野でますます重要なものとなっていくだろう。

 

  

【シリーズ:新時代のデータ保護】

1回:DellEMCDNAを融合させたData Domainシリーズの最新版「Data Domain DD3300」の魅力とは?

2回:最新のデータ保護アーキテクチャを適正なコストで構築するための秘訣

3回:今後、データ保護ルールの新デファクトスタンダードになる可能性もあるEU一般データ保護規則(GDPR)

4回:サイバー対策の最新トレンド「サイバー復旧」とは何か?

5回:近日公開予定

6回:近日公開予定

前回は、Elastic Cloud Storage(ECS)をご紹介いたしました。その中でIsilonとECSの連携について軽く触れましたが、今回は具体的にどのように動作するのか設定と併せてご紹介します。

 

 

CloudPools

IsilonとECSの連携はIsilonのCloudPoolsという自動階層化の機能によって実現しますが、CloudPoolsに入っていく前に少しだけストレージの自動階層化についてご説明します。

自動階層化の機能自体は古くからILMやHSMなどと言われており、高速な(性能単価に優れている)ストレージと低速な(容量単価に優れている)ストレージ間でデータを自動で移動させる技術のことを指します。特に新しい技術ではありませんが、最近では非構造化データの肥大化や分析基盤のアーキテクチャにおいて高速(オールフラッシュ)で分析を行い結果の保管のために低速(アーカイブ)に移動させるようなニーズが高まっています。

Isilonには性能単価に優れたノード、容量単価に優れたノードなど様々なタイプのノードがありますがSmartPoolsによりノードの混在が可能となりノード間でポリシベースの自動階層化を行うことができます。長期間参照されないファイルは容量単価の良いノードに自動的に移すことにより性能と容量とコストのバランスが取れTCOの削減につながります。

このSmartPoolsの機能を拡張してクラウドストレージにアーカイブする機能のことをCloudPoolsと言います。また、クラウドストレージ以外にもECSや別クラスタのIsilonなどに階層化することもできます。

 

なお、ECSは容量無制限にスケールアウトできるのでIsilonとECSを組み合わせることにより、実質無制限のストレージシステムを作ることができます!(と言ってもIsilonのみで68PBまでスケールアウトできます

cloudpools.png

                    どの階層にファイルがあってもクライアントやアプリケーションからは透過的にアクセスできます

 

 

上記のとおり自動階層化自体は最新の技術ではないですが、実は意外と自動階層化の機能を有していないストレージ製品もあります。特に従来型のNASではRAIDでデータ保護を行っていたりボリュームという概念があるためファイル単位での自動階層化が出来ないものや、そもそも自動階層化をサポートしていない製品があります。Isilonには以前から自動階層化の機能であるSmartPoolsが実装されており、OneFS 8.0から実装されたCloudPoolsも2年以上の実績があります。Isilonであればノード間やパブリッククラウドに対してファイル単位で階層化を行うことができます。

 

 

今回は以下とおり、Isilon(OneFS)シミュレータ 1台と、ECS Community Edition 1台を用意しました。実際に試して頂く際にECS Community Editionは前回の内容を参考に準備いただければと思いますが、準備するのが大変な場合はECS TEST DRIVEをご利用頂くこともできます。

env.png

 

 

 

1. ECSの設定

ECS側では、CloudPools用の専用NamespaceとCloudPoolsからアクセスする際の専用のユーザを作成していきます。なお、Bucketは自動的に作成されますので作成不要です。

 

1.1 Namespaceの作成

はじめにCloudPools用のNamespaceを作成します。ECS Portalにログインして「Manage」から「Namespace」を選択します。次に「New Namespace」をクリックして以下を入力します。

・Name = cloudpools

入力後「Save」をクリックします。

create_namespace.png

 

以下のとおりcloudpoolsというNamespaceが作成されたことを確認します。

list_namespace.png

 

 

1.2 ユーザの作成

CloudPoolsからアクセスする際に必要なユーザを作成します。「Manage」から「Users」を選択します。次に、「New Object User」をクリックして以下を入力します。

・Name = cloudpools_user1

・Namespace = cloudpools

入力後「Save」をクリックします。

create_user.png

 

以下のとおりcloudpools_user1というユーザが作成されたことを確認します。

list_user.png

 

1.3 Secret Keyの生成

上記1.2で作成したcloudpools_user1のSecret Keyを生成していきます。cloudpools_user1の「Actions」にある「Edit」をクリックします。以下の画面のS3 / Atmosにある「Generate & Add Secret Key」をクリックします。「Show Secret Key」のチェックボックスにチェックを入れるとSecret Keyが表示されますので内容をコピーします。(コピーしたSecret Keyは2.2で使用します。)

key_gen.png

 

 

2. Isilon CloudPoolsの設定

Isilon側の設定の流れとしては、先ずSmartPoolsとCloudPoolsの評価ライセンスを有効化します。次にCloudPoolsの設定(Cloud Storage AccountとCloudPoolの作成)を行い、自動階層化のポリシを定義していきます。

 

2.1 ライセンスの有効化

CloudPoolsの利用にあたりライセンスを有効化する必要があります。OneFS 8.1では製品やシミュレータの評価ライセンスをお客様やパートナ様のほうでも有効化いただけるようになりました。

OneFS web administration interface(Web UI)にログインします。「Cluster Management」から「Licensing」を選択します。一番下に「Manage trial versions of software modules」という項目がありますので、「Manage Trials」をクリックします。

Manage trialsの画面がポップアップされ、どの機能を評価するか選択します。CloudPoolsはSmartPoolsのライセンスも必要になるため最低限SmartPoolsとCloudPoolsを選択し「Start Trial」をクリックして有効にしてください。(下記は全部の機能を有効にした例です。)

trial_license_activate.png

 

 

2.2 Cloud Storage Accountの作成

ECSにアクセスするためのアカウントを作成します。「File System」メニューから「Storage Pools」の「CloudPools」を選択し「Create a Cloud Storage Account」をクリックします。

以下のとおりECSの接続情報を入力していきます。

・Name or Alias = ecs_cloudpools_user1

・Type = EMC ECS Appliance

・URI = http://luna.isilonian.local:9020

・User Name = cloudpools_user1

・Key = my2DnVGKC7xdh+D2Cg148nhN8NPXL/GPZkvwk0zH(1.3 で生成/確認したSecret Key)

入力後に「Connect Account」をクリックします。このタイミングで接続のテストが行われ、ECS側にBucketが生成されます。

2_create_acct.png

 

2.3 CloudPoolの作成

続いて、「Create a CloudPool」をクリックして以下の内容を入力します。

・Name = ecs_cloudpool1

・Type = EMC ECS Appliance

・Account in CloudPool = ecs_cloudpools_user1

4_cp_create.png

 

 

登録が完了した後、以下のとおりCloud Storage AccountsとCloudPoolsの状態がEnabledとなっていることを確認します。

5_cp_created.png

 

 

2.4 ECS PortalからBucketsの確認

ECS PortalからBucketsを確認するとcloudpoolsのnamespace配下にBucketが作成されたことがわかります。

6_bucket.png

 

同様に、S3 Browserからも空のBucketsが確認できます。

s3_browser.png

 

3. 自動階層化の設定

自動階層化にあたりポリシを設定していきます。SmartPoolsでIsilon内で階層化する場合でもCloudPoolsで外部ストレージへ階層化する場合でもFile Pool Policyで設定することで、きめ細かいポリシを一気通貫で作成することができます。ポリシで設定可能な項目としては、ファイル名、ファイルパス、ファイルタイプ、ファイルサイズ、作成日時、更新日時、アクセス日時、ファイル属性、属性変更日時があり、これらをANDもしくはORで組み合わせて設定することができます。

「File System」メニューから「Storage Pools」の「File Pool Policies」を選択します。次に「Create a File Pool Policy」をクリックします。

各フィールドに以下の内容を入力します。

・Policy Name = archive_to_ecs

・File Matching Criteria = "Modified" "is older than" "1" "second" agoを選択(条件にマッチすれば何でもOKです。)

・Move to cloud storage = チェックボックスのチェックをつける

・CloudPool Storage Target = ecs_cloudpool1

入力後、「Create Policy」をクリックします。

8_filepool.png

 

 

 

4. 動作確認

 

4.1 テストファイルの作成

/ifs配下にhogeという名前のディレクトリを作成してSMB共有を設定し幾つかファイルを配置します。配置するファイルは何でも良いですが、今回は動作確認しやすいように少し大きめなサイズのファイルを作成します。なお、簡単に大きめなサイズのファイルが作れる&圧縮が効くという目的でペイントを使ってビットマップを作成します。

bitmap.JPG.jpg

 

9.3MBのファイルが作成されました。File System Explorerからは以下のとおり確認できます。

fileexplorer.png

duコマンドを実行しても同様に9.3MBのビットマップが確認できます。

sim-1# du -sh 画像.bmp

9.3M    画像.bmp

 

isi getコマンドで実体があるか確認します。SmartLinkedの項目がTrueになっているファイルはIsilon側に実体が存在せずクラウド(今回の場合はECS)に移動しています。現時点では以下のとおりFalseになっています。ちなみに、OneFS 8.0ではSmartLinkedではなくStubbedと表示されます。

sim-1# isi get -DD 画像.bmp | grep -i smartlinked

*  SmartLinked:        False

 

4.2 SmartPools Jobの実行

SmartPoolsのJobを手動で実行します。(通常はスケジュールによる自動実行となりますが動作確認のため。)

「Cluster Management」の「Job Operations」、「Job Types」と辿りSmartPoolsの「Start Job」をクリックします。以下の画面が表示されますので「Start Job」を実行します。

start_job.png

 

CloudPoolsの状態はisi cloud jobs listコマンドで確認ができます。"Effective State"がrunningからcompletedに変わります。

sim-1# isi cloud jobs list

ID   Description                             Effective State  Type

--------------------------------------------------------------------------------------

1    Write updated data back to the cloud    running          cache-writeback

2    Expire CloudPools cache                 running          cache-invalidation

3    Clean up cache and stub file metadata   running          local-garbage-collection

4    Clean up unreferenced data in the cloud running          cloud-garbage-collection

10                                           completed        archive

 

isi getコマンドを実行すると"SmartLinked"がTrueに変化していることが確認できます。

sim-1# isi get -DD 画像.bmp | grep -i smartlinked

*  SmartLinked:        True

        SmartLinked file flags   0      5

        SmartLinked file size    5      9

 

duコマンドを実行すると、ファイルサイズが減っている(512B)ことが確認できます。これは、Isilon側に実体は存在せずSmartLinkのみ保存されているためです。もちろんユーザからの見た目のパスや実際のファイルサイズに変更はありません。

sim-1# du -sh 画像.bmp

512B    画像.bmp

 

 

4.3 ECSのBucketの確認

ECSのBucketをS3 Browserで確認すると、1MBのオブジェクトが9個と316.85KBのオブジェクトが1個存在していることが確認できます。クラウドストレージにアーカイブされたデータをIsilonではCloud Data Object(CDO)と呼んでいます。CDOは1MB単位で分割されECSへ格納されます。1個だけある316.85KBは端数(残り)です。

9_s3_browser.png

 

 

4.4 CloudPoolsによる圧縮機能

CloudPoolsは転送する際に圧縮と暗号化を行うオプションがあります。先程試したファイルと同じものを圧縮した場合にどうなるか試してみます。(なお、今回作成したビットマップは非常に圧縮が効くようになっておりWindowsの標準のZIP圧縮ツールを使うと9.42KBとなりました。)

sim-1# du -sh 画像2.bmp

9.3M    画像2.bmp

 

「File System」メニューから「Storage Pools」の「File Pool Policies」を選択します。上記3.で作成したFile Pool Policyを「View / Edit」をクリックし編集します。Compress data before transferにチェックを入れ「Save Changes」で保存後、上記4.2と同様の操作でSmartPoolsを実行します。

compress.png

 

4.5 ECSのBucketの確認

ECSのBucketを確認すると、今度は1.08KBのオブジェクトが8個、1.12KBのオブジェクトが1個と408Bのオブジェクトが1個となりました。合計で約10KBですので約900分の1に圧縮されていることが確認できます。

compress_s3_browser.png

 

 

 

 

さいごに

ご覧頂きましたように、IsilonのCloudPoolsとECSの組み合わせによって性能と容量のバランスに優れたシームレスなストレージシステムを作ることができます。また、ECSはIsilonのアーカイブ先だけではなくバックアップのターゲットやS3を用いたモバイル/Webベースのアプリケーションの基盤などにも使用可能ですので、これらのデータを統合する中核のストレージとしてECSを配置することによりTCOの削減にも繋がります。なお、ECSのGeoレプリケーションは高い保護レベルでデータのオーバヘッド削減できるアルゴリズムを採用していますので特にGeoレプリケーションを検討されている場合は是非ご連絡ください。

geo.png

CloudPools含めIsilonおよびECSは今後も様々な機能がエンハンスされていきますのでご期待ください。

 

 

参考情報

ISILON CLOUDPOOLS AND ELASTIC CLOUD STORAGE (Solution Guide)

DELL EMC ISILON CLOUDPOOLS

Isilon Simulator download

ECS CE download

ECS Test Drive




バックナンバー

IsilonianTech 第1回 Isilonとオープンソース ~REX-Ray編~

IsilonianTech 第2回 Isilonとオープンソース ~OpenStack Manila編~

IsilonianTech 第3回 Isilonとオープンソース ~Isilon Data Insights Connector~

IsilonianTech 第4回 Software Defined Storage ~IsilonSD Edge~

IsilonianTech 第5回 Isilonとオープンソース ~Isilon-POSH~

IsilonianTech 第6回 Isilonとオープンソース ~Elastic Stack編~

IsilonianTech 第7回 Isilonとデータアナリティクス ~Cloudera編~

IsilonianTech 第8回 Elastic Cloud Storage (ECS) ~ECS Community Edition~

IsilonianTech 第9回 ISILON + ECS = UNLIMITED ~Isilon CloudPools~

 

 

安井 謙治

Dell EMC Unstructured Data Solutions

UDS事業本部 SE

【全6回シリーズ3/6 新時代のデータ保護】

2018年5月25日から施行されたEU一般データ保護規則(GDPR)。EU圏内の企業と取引のない日本企業の多くは「それほど影響はない」ととらえられていることが多い。しかしGDPRは、EU企業だけでなくEU市民の個人情報も保護対象としており、違反企業に対する罰金も日本国内のルールよりもはるかに高い。そうなると国内の旅行・観光企業や医療機関、ネットサービス企業なども「対岸の火事」とはいえなくなる。今回は、施行後のGDPRがビジネスにどのような影響を及ぼすのかについて、Dell EMCの2人の専門家に聞いてみた。

 

Alex Lei

Dell EMC

VP,Data Protection Solutions,APJ

 

Yeong Chee Wai

Dell EMC

Dirctor,Head of Presales

Data Protection Solutions,Asia Pacific&Japan

 

 

2018年5月25日からEU一般データ保護規則(GDPR)が施行されました。GDPRは、EUに拠点を持つ企業だけでなく、EU圏外であってもEU市民の個人データを扱いビジネスをしている企業や組織さえ適用範囲とされます。

 

GDPRそのものについて基礎知識がある人は少なくありませんが、例えば、EUから日本にやってきた旅行者の個人情報についても、GDPRの適用範囲であるということはあまり知られていません。

 

「GDPRは、欧州企業と取引のある企業が対応するもので、うちはそういう取引はないから大丈夫」と考えている企業関係者は多いようですが、EUに居住している人の個人情報も対象になるため、ECサイトや国内ビジネスなどでも個人情報を扱う場合は、要注意です。

 

EU諸国から日本にやってくる観光客は年々増加しています。また、日本企業のITサービスを利用するEU居住者も多いはずです。GDPR施行後は、おそらく個人情報の取り扱いについて、日本でビジネスをする企業でさえ、これまで以上に詳細な説明を求められる可能性があります。

 

このときに「日本ではこういうことになっているから」とか「ほかの外国人の人たちにはそこまで説明していない」といったローカルルールは通用しません。個人情報の保護について、さまざまな質問に対して素早くわかりやすい形で説明でき、納得してもらわなくてはなりません。

 

例えば、EU居住者が日本で病気になり、診療を受けた場合、本人の個人情報が記録されることになりますが、この場合でも、対象になりえます。つまり一般の企業ではない法人や組織さえGDPRの対象になるのです。

 

●GDPRに組み込まれている「right to be forgotten」

 

GDPRで特に注目されるのが、その罰則規定です。違反があった場合、罰金の額がグローバルの売上高の4%にもなることがあります。GDPRの中身が明らかになるにつれ、米国をはじめ、オーストラリア、シンガポール、香港など欧州との取引がさかんな国、地域で関心が高まり、対策が講じられてきました。日本では、現在でも一部の企業、業界でしか関心が高まっていないように見受けられます。

 

もちろん、日本にも個人情報保護法をはじめ、さまざまなデータ関連の規制はあります。しかしGDPRでは、right to be forgotten(忘れられる権利)も組み込まれているので、「保存しているデータを削除してほしい」と依頼されれば対応しなくてはいけません。

 

つまり、安全にデータを保管するだけでなく、たとえ古いデータであっても、迅速に検索して見つけ出し、削除し、その証跡を提示できなくてはならないのです。

 

日々増え続けるデータを管理するだけでも大変なのに、たとえば5年前に取得した個人データを探し出し、削除するというのは、もし全保管データから迅速に検索する仕組みを持っていなければ、かなり骨の折れる作業となるでしょう。

 

もし、「個人情報を削除してほしい」というEU居住者からの依頼に、時間が経過しても対応できなければどうなるでしょう。GDPR規定に基づく罰則という直接的な制裁に加え、SNSで対応の不備について拡散される可能性もありますし、訴訟を起こされる可能性もあります。

 

●EUだけでなくグローバルで広まる可能性

 

わたしたちは、データ保護に関する専門家として日本を含むアジア太平洋地域で仕事をしています。その専門家たちの間では、GDPRが、事実上データ保護規制の新しいグローバルスタンダードとして、広く適用されるようになるのではないかという考え方が、一般的になってきました。

 

このような考え方が、施行される前の段階から広がりつつあるというのは、珍しいことかもしれません。しかし、GDPRでEU居住者の個人情報が守られるのなら、全世界の人たちの情報も同様のルールで守るようにしてほしい、という声が生まれるのはごく自然な流れだと思います。

 

日本でも、個人情報についてGDPRに準じた考え方や判例が今後出てこないとも限りません。IDC社の調査では、日本を含むアジア太平洋地域において、日本はプライバシー侵害に対する罰則の重さが2番目に低い国とされています1。ローカルルールを基準としていると、GDPR施行後の個人情報の漏えい事案などでの賠償額は、これまで以上に、想定を超える大きなリスクになると考えられます。

 

GDPRで扱うのは個人情報だけではありませんが、重要なファクターであり、最も関心を集めている分野です。今後、欧州企業との取り引きの有無にかかわらず企業全般で、GDPRへの対応が求められるようになるでしょう。

 

Dell EMCでは、国内だけでなくグローバルでGDPRへの対応についての最新情報を集め、お客様に正しいデータ保護の指針を策定するお手伝いができるよう体制を整えています。

 

GDPRのルールが広まっていく時代では、データをただ保護するだけでなく、迅速にコントロールできる能力がますます重要になってきます。企業だけでなく、人の交流も対EUでは活発化していくことでしょう。組織の規模にかかわらず、あらためて、データの活用プロセスをリスクの側面から見直す必要があると考えます。

 

《取材雑感》

データ保護に関する専門家によれば、GDPRはEU圏内に籍を置く企業・個人についてだけでなく、事実上、データ保護に関するグローバルスタンダードとなる可能性があるという。ということは、国内企業同士の取引においてもGDPR準拠のデータ保護体制が求められるようになることは必至だ。今後は、そうしたことを踏まえ、社内システムのデータ保護ルールおよびポリシーを再点検する必要が出てきそうだ。

 

聞き手・構成 ITジャーナリスト 大西高弘

 

 

注1:IDC Data Risk Management Barometer 調査
barometer | Dell EMC Japan

 

【シリーズ:新時代のデータ保護】

1回:DellEMCDNAを融合させたData Domainシリーズの最新版「Data Domain DD3300」の魅力とは?

2回:最新のデータ保護アーキテクチャを適正なコストで構築するための秘訣

3回:今後、データ保護ルールの新デファクトスタンダードになる可能性もあるEU一般データ保護規則(GDPR)

4回:サイバー対策の最新トレンド「サイバー復旧」とは何か?

5回:近日公開予定

6回:近日公開予定

【全6回シリーズ2/6 新時代のデータ保護】

 

社内データの保護はセキュリティとバックアップ製品を導入するのが基本。しかし、クラウドを活用してコストを最適化し、さらに万が一の災害、サイバー攻撃備えて迅速なリカバリ体制を整え、日常業務でのデータ活用もスムーズに実行できるようにするには、それだけでは足りない。日々増加し続けるビジネスデータの保護は、コストと可用性の両方を高いレベルで満たさなくてはならない時代に入ったのである。では具体的にどのように考え、施策を練っていけばいいのか。今回は、データ保護の最前線でユーザーの声に耳を傾け、ベストプラクティスを提案し続けている2人の専門家に話を聞いた。

 

 

Alex Lei

Dell EMC

VP Data Protection Solutions, Asia Pacific&Japan

 

Yeong Chee Wai

Dell EMC

Director Head of Presales

Data Protection Solutions, Asia Pacific&Japan

 

 

わたしたちは、Dell EMCのデータ保護ソリューション部門で、主に日本を含むアジア太平洋地域のお客様にソリューションを提供させていただいています。

 

データ保護、というと従来はバックアップ(データの複製処理)と同義語のようにとらえられていましたが、現在では、リカバリ(データの復旧)を最重視したソリューションとして考えられるようになっています。

 

この考え方は、かなりお客様にも浸透してきているとは思うのですが、まだまだ誤解されている部分も多いのです。その最大のものが、コストです。

 

従来のバックアップ主体のデータ保護から、リカバリを最重視したソリューションへと移行するには、アーキテクチャそのものを変更する必要が出てきます。その際のコストについて莫大な額がかかる、という誤解があります。

 

年々増加するデジタルデータに対し、サイバー攻撃や人的操作ミス、ハードウェアの故障などにより喪失してしまうことを、コストを低減させながら防ぐことは、実は可能です。

 

Dell EMCでは、2年から4年のROIを示しながら、適正なコストで高度なデータ保護を実現することが可能なことを、お客様への提案のなかでお伝えしてきています。

 

●ビジネスの「燃料(Fuel)」であるデータをどう安全に利用するか

 

今や、デジタルデータは企業にとってビジネスを動かすうえでの「燃料」のようなものです。店舗や事業所を持たず、モバイル経由でデータを活用したビジネスを展開している企業も出てきました。もちろん、そうした企業だけでなく、長い歴史を持つ企業も、どんどんデジタルデータを活用した新しいビジネスを起こし、成果を上げています。

 

そうした中で、もし、そのデータがサイバー攻撃によって利用できなくなったらどうなるでしょうか。

 

ある海運会社では、サイバー攻撃を受け業務がストップし、船の運航そのものができなくなりました。受けた被害は計り知れないものがあります。そしてこのような事例は、決して珍しいものではありません。

 

サイバー攻撃によって、顧客情報が盗まれるという事案もまだまだありますが、データそのものを失うことによって、日常業務を停止せざるを得ない、という時代になってきているのです。データの喪失は、サイバー攻撃だけが原因になるとは限りません。データを運用している社員による誤操作で起きることもありますし、システムを支えるハードウェアやアプリケーションが原因で起きることもあります。

 

わたしたちは、サイバーセキュリティだけでなく、あらゆる側面からデータ保護についてのベストプラクティスを提供することを使命としています。

 

●あらゆるリスクを考慮に入れたリカバリを目指す

 

データが失われたとしたら、バックアップしていたデータを利用して復旧しなくてはなりません。しかし、この復旧もさまざまな課題があります。

 

Dell EMCが独自に行った調査1では、日本のIT部門の意思決定権者はデータの復旧について明確な自信がなかなか持てない(「完全な自信あり」回答は1割未満)、という結果が出ていました。しかし、これは日本企業だけに限られたことではないのです。

 

データを喪失または破壊前の時点に戻って、迅速にビジネスを復旧するということは、その実現を支えるソリューションを構築していなければ簡単には実行できません。

 

いま、わたしたちは、多くの日本のお客様と最適なデータ保護についての議論を重ねています。そうしたお客様は、サイバー攻撃、人的ミス、自然災害などあらゆるリスクを考慮に入れ、データを最適な時点(RTO)に、最適な時間内(RPO)でリカバリできる体制を構築することを目指しています。

 

Dell EMCでは、Dell Technologies(デル テクノロジーズ)グループ企業とDell EMCのこれまでの技術力を、完全に統合して、お客様のニーズにさらに的確に対応できるようになりました。これは何を意味するのかというと、ストレージ単体に限らず、ハードウェアやアプリケーションも含めて、データ保護ソリューションが一体的に対応できるということです。

 

●クラウド時代に適応したデータ保護ソリューション

 

ハードウェアやアプリケーションも含めた、一貫したデータ保護ソリューションを提供するということは、クラウドについても当然適用されます。

 

まずプライベート、パブリック、ハイブリッドといった、クラウドの多様なスタイルにも対応します。そして、オンプレミスのシステムからデータを移行する際にも、常時暗号化した状態で実行することを可能にしています。これはクラウドとクラウドの間でも同様です。セキュアな状態で、迅速にデータを自由に移行するためのソリューション群を整えました。

 

データの保護、復旧をしやすくするには、管理手法を簡素化しなくてはなりません。もちろんそのためのソリューションも提供しています。高度な検索性を持ち、削除などの操作も安全に実行できるようにすることで、データ保護、復旧の能力も格段に上がっていきます。

 

また、パブリッククラウドをDRサイトとして利用するお客様が増えてきました。そこでDell EMCでは、2017年にクラウド災害対策ソリューションData Domain Cloud DRを発表しました。このソリューションは、通常のデータ保護システムの延長線で、オンプレミス上のVMware仮想マシンを、AWSのEC2インスタンスへ自動的に変換、移行することを可能にします。

 

●クラウドに関する誤解とリスクを理解する

 

クラウドとデータ保護、ということでは、まだまだ誤解されている部分も多々あります。とくにパブリッククラウドでは、セキュリティについてデフォルトで全面的保護されると考えがちです。しかし、現実には利用者側がセキュリティおよびデータ保護の措置を取らなければならないケースが多々あります。

 

例えば、パブリッククラウド上で企業独自のアプリケーションを構築、運用するケースがあります。このときの不具合によってデータが損失したりしても、それはクラウド提供事業者ではなく、ユーザーの自己責任で復旧しなければならないケースがほとんどです。

 

つまり、「うちはクラウドにデータを預けていて、セキュリティも事業者に任せているから大丈夫だ」「アプリケーションの不具合も事業者の責任」ということにはならないのです。

 

クラウド時代のデータ保護は、やはり、利用者である企業がしっかりと手当しなくてはなりません。その際は、ぜひ、リスクベースのアプローチで具体的にどのような保護策を実施するのかを利用者がクラウドを使う上で、使う前に考えておくべきでしょう。

 

●攻めのビジネス戦略に「データ保護」を取り入れる

 

今後は、多くの企業がオンプレミスのシステムとプライベートクラウドを連携させ、そのうえで、パブリッククラウドの活用を進めるという、ハイブリッドクラウドの運用が主流となっていくでしょう。

 

こうしたシステム運用で何が起きるのか。まず考えられるのは、扱うアプリケーションの増加です。そしてこれらのアプリケーションの大半は、保有するビジネスデータと連動して機能します。

 

前述したように、多くのアプリケーションがデータと連動するため、そのデータが失われると、またたくまにビジネスに多大な影響をもらしてしまうのです。

 

そして、多数のアプリケーションによってデータの運用自体も複雑化し、バックアップや復旧も複雑化します。こうしたことを念頭に置いたうえで、最適な保護施策を適用し、迅速な復旧を実現するには、ただセキュリティソフトやバックアップソフトを導入するだけでは、問題解決になりません。

 

Dell EMCでは、このような個々のお客様のシステム環境の課題を多角的に判断したうえで、最適なデータ保護ソリューションを提案しており、価格面からも評価をいただいています。それを裏付けるグローバルも含めた多数の事例がそれを証明しています。

 

データ保護は決して守りの施策ではありません。ビジネスの「燃料」であるデータを最大限に生かし、厳しい競争にうちかつための攻めの施策という側面もあるのです。そのことを踏まえたうえで、Dell EMCの提案を参考にしていただければと思います。

 

《取材雑感》

「データドリブンでビジネスを動かしていく」というコンセプトは、数年前から提唱されてきたが、2人の専門家の話を聞いているとまさにリアルなビジネスにおいてデータドリブンの時代が本格化してきたのだと実感した。そのような時代においては、データはビジネスの燃料であり、それを守り、効率的に利用するには、目的ごとに製品を導入するだけではなく、システムアーキテクチャ全体から最善手を導いていく考え方が必要になる。最適なデータ保護体制の構築は「攻めの経営」にもつながるという意見はまさに卓見といえるだろう。

 

聞き手・構成 ITジャーナリスト 大西高弘

 

 

 

注1:Dell EMC Data Protection Index
https://www.emc.com/microsites/emc-global-data-protection-index/index.htm

 

 

【シリーズ:新時代のデータ保護】

1回:DellEMCDNAを融合させたData Domainシリーズの最新版「Data Domain DD3300」の魅力とは?

2回:最新のデータ保護アーキテクチャを適正なコストで構築するための秘訣

3回:今後、データ保護ルールの新デファクトスタンダードになる可能性もあるEU一般データ保護規則(GDPR)

4回:サイバー対策の最新トレンド「サイバー復旧」とは何か?

5回:近日公開予定

6回:近日公開予定

【全6回シリーズ1/6 新時代のデータ保護】

 

Dell EMC EMCジャパン株式会社 DPS事業本部 事業推進部 

シニア ビジネス ディベロップメント マネージャー

西頼大樹

 

2017年10月に公開された「ブレードランナー 2049」という映画では、全世界の電子データが喪失、または破壊されてしまった世界が描かれていました。そのため主人公は、わずかに残されたデータをもとに仕事をしなくてはいけません。

 

現実の世界ではまだ幸いにもこのような大規模なデータ損失は起きていません。しかし企業や組織単位で見てみると、データがしっかりと保護されていないため、有事の際、適切な過去データを探し出すことができず、ビジネスが遅滞してしまった、あるいは、監査などへの対応が大幅に遅れてしまった、ということは、残念ながらそれほど珍しいことではありません。

 

ある時点で、どのデータが、ビジネスやサービスを提供する上で最適かを把握することは、業務を遂行する上できわめて基本的ですが、最も重要な問題です。災害、大規模なシステム障害、セキュリティ侵害などデータ損失の原因は様々ありますが、万一データ損失が発生したときも、顧客への影響が最小または無い適切なデータを使ってすぐにビジネスを再開できる、ということが、企業や組織にとっての信用に大きく影響します。

 

そのために、現代の企業や組織では、デジタルデータのバックアップ作業が欠かせません。日常業務に利用する資料用のデータからWebコンテンツデータ、そして販売実績などの財務データ、利益の根幹をなす情報資産データ(開発情報、設計図面、等々)、顧客データ、データベースシステムに記録された最新データなど、保存しておかなくてはならないデジタルデータは、種類、量ともに年々増加の一途をたどっています。

 

また、昨今システムの仮想化が常識となってきました。仮想化は、ITのビジネス対応を促進し、モバイル活用などにも欠かせないソリューションとなっていますが、バックアップデータの容量を飛躍的に増加させる一因ともなっています。仮想マシンや、そこから生成されるデジタルデータの増加によってバックアップの時間が大幅に延び、業務にも支障が出ることが増えてきた企業も散見されるようになったため、バックアップ問題の解決が急がれるようになっています。

 

●バックアップ専用ストレージとして高い評価を持つDell EMC Data Domain

 

このような時代におけるバックアップの課題は、時間とコストです。

 

年ごとのデータ増加量の伸び率から、バックアップに必要な時間とそれに必要なストレージやネットワークなどのコストを換算すると、数年先には今のシステムの状況では現実的な対応ができない、という企業がここ数年大幅に増えてきました。

 

このようなことを背景に、Dell EMC Data Domain(DD)は開発されました。DDは、高い重複排除能力を搭載したバックアップ専用ストレージで、既存のバックアップ環境を変更することなく導入できる製品です。

 

重複排除機能とは、事前に対象データの重複部分を判定し、重複しないユニークな部分しか実データとして扱わない圧縮技術です。そのため、バックアップのデータ量を平均10分の1から30分の1程度に低減できます。これにより、バックアップに必要な時間もストレージやネットワークなどのコストも両方節約ができるのです。

 

DDは発売以来、多くのお客様から支持されてきました。その理由は、データ保護のスペシャリストであるDell EMCならではの技術が投入されているからです。例えば、重複排除機能1つとっても「可変長ブロック単位」を採用し、より多くの重複部分を探し出すことを可能にしています。また、独自ソフトウェア(DDBoost)によって、アプリケーション側にて、重複部分を探し出す機能を分散させることで、より迅速に処理できるようにしています。

 

また、DDをお使いのお客様からは、レプリケーションを簡単に設定でき、正確に実行できるという評価をいただいています。自動でデータ転送することはもちろん、複数のDD、複数のクライアントからレプリケーションされたデータをまとめて重複排除することができるので、レプリケーション先で集約保管するバックアップデータの容量をさらに少なくすることが可能です。また、回線の帯域制御機能によって、最適な方法でデータ転送を実施することができるため、他の業務に支障をきたすということも避けられます。

 

●これまでにない機能を追加したDD3300

EMCは2015年、「Dell EMC」として再スタートを切ることになりました。そして2018年3月、DDのラインアップに「Data Domain DD3300」(DD3300)が加わることになりました。

DD1.png

 

DD2.png

※DDシリーズのラインアップ(2018年5月現在)

DD3.png

※DD3300とDD2200との性能比較

 

 

 

DD3300は、現DDラインアップの最小モデルであるDD2200と同じエントリーモデルに位置付けられます。4TB、16TB、32TBの3つの導入オプションが用意され、中堅企業や大企業の拠点で利用しやすい価格に設定されています。

 

DD3300は、前述してきました機能を継承したうえで、よりユーザー本位の機能を追加しています。大きな変化はクラウド対応です。

DD4.png

※ITにおけるクラウドの動向

 

昨今、多くの企業でバックアップデータ用途にパブリッククラウドサービスを利用するという方法が採られるようになってきました。そこでDD3300でも、レプリケーション先や長期保管データの階層化先などにクラウドを要望されても対応できるようにしたのです。これにより、事前設定に基づき、自動的にクラウドをバックアップ目的で活用することができ、また、高い重複排除機能により、クラウド保管に必要なクラウドストレージコストを抑え、データをリストアする場合も迅速かつ低コストで実行することができます。

 

とりわけバックアップにクラウドを利用するというのは、利用頻度の少なくなった過去のデータを長期保管したいというニーズが多いですが、災害対策(DR)に利用するという目的もあるでしょう。いずれにせよ、クラウドを利用する場合でも、データ量が増加すれば、コストはかさんできます。従って、保存するデータは少なければ少ないほうがいい。DD3300は、ユーザーのクラウドコストを最小限にするという意味でも、大きなメリットを提供できます。

 

DD5.png

※クラウド対応の概要

 

Dell EMCでは、2017年にクラウド連携型災害対策ソリューションData Domain Cloud DRを発表しました。このソリューションは、オンプレミス上のVMware仮想マシンを、AWSのEC2インスタンスへ自動的に変換し、立ち上げる仕組みを持っています。DD3300は、エントリーモデルながら、Data Domain Cloud DRを実装しているため、クラウドを活用した災害対策が可能となりました。

 

もちろん、DD3300同士でレプリケーションを行うことも可能です。従って、日常のバックアップと遠隔地保管はオンプレミスで実施し、万が一の事態にも対応できるよう、DR対策としてクラウドも効率的に利用するという体制を組めます。

 

●最高レベルの費用対効果を提供しデータ保護の課題を解決

 

DD3300の魅力はこれだけではありません。DD3300はハードウェアとして優れた面を持っています。

DD3300は、Dellで培われた技術を移植した、DDラインアップ初の“Dell EMC”モデルです。Dellは、PowerEdgeに代表されるサーバプラットフォームの開発を長年行っており、DD3300にはそのノウハウがふんだんに投入されています。その技術・ノウハウを活かし、性能を最大限発揮できるよう設計され、2Uの小型堅牢な製品に仕上げました。

また同時にセットアップ作業の簡素化も実施。どの程度簡単なのか、それは以下をご覧いただくことでお分かりいただけると思います;

・Data Domain DD3300 初期設定

 

・Data Domain DD3300 セットアップの仕上げとカスタマイズ

DD6.png

※ハードウェアとしてのDD3300の魅力

 

製品内部もDellサーバプラットフォームの代名詞とも言える、これまでにない洗練された作りとなっており、従来のDDユーザーのお客様が内部を見られると、その変貌ぶりに驚かれるであろう改良が数多く施されています。まだ、実物に触れていないのであれば、ぜひ手に取ってごらんになることをお勧めします。

 

このように様々な新しい取り組みによって開発されたDD3300は、7.0TB/時(DD Boost 使用時)という従来の1.5倍の性能と、クラウド活用時の最大論理容量が最大4.8PBという拡張性を実現しました。

 

ここまでご説明してきたことを踏まえると、DD3300は、エントリーモデルのストレージアプライアンスとして、歴代のDDラインアップと比べ、一線を画すモデルだということがお分かりになると思います。まさにDD3300は、EMCとDellそれぞれのDNAの良い部分を融合させた製品なのです。

 

データ保護におけるバックアップの重要性は、中規模企業のお客様や大組織の各拠点のご担当者様にとっては新しい課題です。まさか自分の会社やチームでそのような問題が起きるとは予想もしていなかった、ということがほとんどでしょう。限られた予算の中で、いかにしてこの課題を解決していくのか、そうしたミッションに取り組む上で、DD3300は大きな援軍となるはずです。

 

 

 

 

【シリーズ:新時代のデータ保護】

1回:DellEMCDNAを融合させたData Domainシリーズの最新版「Data Domain DD3300」の魅力とは?

2回:最新のデータ保護アーキテクチャを適正なコストで構築するための秘訣

3回:今後、データ保護ルールの新デファクトスタンダードになる可能性もあるEU一般データ保護規則(GDPR)

4回:サイバー対策の最新トレンド「サイバー復旧」とは何か?

5回:近日公開予定

6回:近日公開予定

私が所属しているUDS事業本部(旧アイシロン事業本部)は、Unstructured Data Solutionsが英語表記での正式名称でして名称のとおり非構造化データ(ファイル、オブジェクト、ストリームデータ)を中心としたソリューションを扱っております。今回は非構造化データの中でもニーズが増えているオブジェクトストレージ DellEMC Elastic Cloud Storage(ECS)についてご紹介します。

いつものように、簡単にECSの概要をご紹介して、後半でECS Community Edition(無償版のECS)をセットアップしていきたいと思います。

ECS.png

 

 

Elastic Cloud Storage (ECS)

DellEMCのオブジェクトストレージの歴史は古く2002年リリースのCenteraから始まります。その後Atmosを経て2014年にECSをリリースいたしました。Centeraがリリースされた当初は長期保管データ(アーカイブ)用ストレージとして利用されることが多かったですが3世代目であるECSでは時代の変遷に伴い各種機能を実装した結果、コンテンツのグローバル共有ストレージ、モバイルアプリケーション用ストレージ、ビッグデータやIoTでの大量な解析データ(データレイク)用ストレージとしても利用されるようになりました。

また、DellEMCのIsilonやDataDomainを始め3rd Party製品との連携ができますので様々な製品のバックエンドのストレージとして利用されることも増えてきております。

ecosystem.png

                   ECSのエコシステム

 

 

スケールアウト型のアーキテクチャやサポートしているプロトコルなどECSとIsilonで共通している部分は多いですがECSとIsilonは以下のような違いがあります。

なお、両製品ともに市場から大きな評価を得ており、ガートナー社のマジック・クアドラントにおいてECSとIsilonはビジョンの完全性と実行能力におけるリーダーに位置付けられています。(分散ファイル システムおよびオブジェクト ストレージのマジック・クアドラント

ECSIsilon
ストレージアーキテクチャスケールアウトオブジェクト

スケールアウトNAS

データアクセス

オブジェクト(S3、Swift、Atmos、CAS)

HDFS、NFS、SMB(CIFS-ECS Tool)

ファイル(SMB、NFS)

HDFS、Swift、FTP、HTTP

トポロジ

サイトを跨ったアクティブ/アクティブ

構成が可能(最大8サイト)、グローバルネームスペース

サイト間でアクティブ/パッシブ構成(基本2サイト)

※カスケードレプリケーションより複数サイト構成も可能

主なユースケースモダンアプリケーション、アーカイブ、データレイク大規模NAS、データレイク、アーカイブ

 

 

 

ECSのセットアップ

ECS Community EditionはGitHubにて無償で公開されておりSource版とOVA版があります。今回はOVA版を使ってセットアップしていきます。なお、ECS Community Editionはこちらからダウンロードください。(DellEMC ECS Software Download現時点では、2018年3月にリリースされたECS 3.2が最新となります。

 

環境準備

ECS Community Editionを評価いただく際に必要な環境は下記となります。ECS Community Editionの仮想マシンを稼働させるためのvSphere ESXとvCenter Server、ECSにアクセスするS3クライアント(S3 BrowserやCyberduck、CloudBerry Explorerなど。今回はS3 Browserを使います)をご用意ください。

env_ecsce.png

ECSは分散ストレージですので本来複数ノード必要となります。ECSのデフォルトのイレイジャーコーディングは、12+4(データ+コーディング)となり最低4ノード必要となりますが、今回は機能検証が目的のため1ノードで構成します。なお、ECS Community Editionでも簡単に複数ノード構成を試していただくことが出来ますが、仮想マシン1台につき下記リソースが必要となります。

コンポーネント最小要件
CPU4
メモリ16 GB
ハードディスク1(システム用)16 GB
ハードディスク2(データ用)104 GB

 

 

ECS Community EditionのOVAファイルのデプロイ

1. vSphere Web Clientを使用してOVAファイルをデプロイします。ファイルメニューの「OVFテンプレートのデプロイ」からダウンロードしたOVAファイル(dellemc-ecsce-3.2.0.0-install-node-2.7.0-vm0.ova)を選択し登録していきます。

2. OVAのデプロイ後、仮想マシンの「設定の編集」を開きメモリを16GBに変更します。(初期状態は2GB)

ecsce_prop.png

 

 

ECS Community Editionの設定

1. 仮想マシンの電源を投入してコンソールに入ります。ユーザ名はadmin、パスワードはChangeMeでログインします。なお、以後コマンドを実行していきますので必要に応じてroot権限(sudo)で実行してください。なお、ECS Community EditionはAnsibleで簡単に設定できるようになっていますのでコマンド数回の実行でセットアップが完了します。

 

2. nmcli(もしくはnmtui)でネットワークの設定を行います。OVA版はens32がネットワークアダプタ1となります。ホスト名は、この後のセットアップで設定しますのでデフォルト(localhost)のままで問題ありません。

[admin@localhost ~]$ nmcli c mod ens32 ipv4.addresses <IPアドレス>

[admin@localhost ~]$ nmcli c mod ens32 ipv4.gateway <Gateway IP>

[admin@localhost ~]$ nmcli c mod ens32 ipv4.dns <DNS IP>

[admin@localhost ~]$ nmcli c mod ens32 ipv4.method manual

[admin@localhost ~]$ nmcli c mod ens32 connection.autoconnect yes

[admin@localhost ~]$ nmcli c up ens32

必須ではありませんが、このタイミングでvSphereのコンソールから抜けてsshで接続します。


3. fdiskでハードディスク1とハードディスク2を確認します。ハードディスク2は104GBに設定されていますので容量から下記の赤字(/dev/sdb)がハードディスク2であることが確認できます。(104*1024*1024*1024=111669149696 bytes)

[admin@localhost ~]$ sudo fdisk -l

[sudo] password for admin:


Disk /dev/sdb: 111.7 GB, 111669149696 bytes, 218103808 sectors

Units = sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes



Disk /dev/sda: 17.2 GB, 17179869184 bytes, 33554432 sectors

Units = sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk label type: dos

Disk identifier: 0x0009563f


   Device Boot      Start         End      Blocks   Id  System

/dev/sda1   *        2048     2099199     1048576   83  Linux

/dev/sda2         2099200    33554431    15727616   8e  Linux LVM


Disk /dev/mapper/cl-root: 14.4 GB, 14382268416 bytes, 28090368 sectors

Units = sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes



Disk /dev/mapper/cl-swap: 1719 MB, 1719664640 bytes, 3358720 sectors

Units = sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

 

4. videployコマンドでdeploy.ymlを編集していきます。なお、videployやこの後使用するコマンドは/home/admin/bin配下に存在しており既にパスが通っております。

[admin@localhost ~]$ videploy

 

5. 下記deploy.ymlの赤字部分を編集します。

~8行目~

licensing:

  license_accepted: true

trueに変更することで使用許諾に同意したことになります。

 

~31行目~

  install_node: <IPアドレスまたはホスト名>

インストールを実行するノードのIPアドレスまたはホスト名を入力します。


~64行目~

  node_defaults:

    dns_domain: isilonian.local

    dns_servers:

      - DNSサーバのアドレス>

    ntp_servers:

      - <NTPサーバのアドレス>

DNSサーバおよびNTPサーバの情報を入力します。


~97行目~

  storage_pool_defaults:

    is_cold_storage_enabled: false

    is_protected: false

    description: Default storage pool description

    ecs_block_devices:

      - /dev/sdb

fdiskで確認したハードディスク2のデバイス名に変更します。


~106行目~

  storage_pools:

    - name: sp1

      members:

        - <IPアドレスもしくはホスト名>

      options:

        is_protected: false

        is_cold_storage_enabled: false

        description: My First SP

        ecs_block_devices:

          - /dev/sdb

membersにセットアップするノードのIPアドレスもしくはホスト名(複数台の場合は改行して入力)、ecs_block_devicesはfdiskで確認したハードディスク2のデバイス名に変更します。

 

6. deploy.ymlの編集が終了したら:wq!で保存して編集モードから抜けます。

 

7. ova-step1を実行します。

[admin@localhost ~]$ ova-step1

 

8. ova-step2を実行します。

[admin@localhost ~]$ ova-step2

 

以上で、ECS Community Editionのセットアップは完了です。

ECS Community Editionでは、ova-step1を実行するとホスト名は自動的に付与されますので1台目はlunaとなります。(余談ですが、2台目からはphobos、deimos、io、europa、ganymede、callisto、amaltheaと衛星が続きます。それ以上知りたい場合は、https://github.com/EMCECS/ECS-CommunityEdition/blob/master/ui/etc/autonames.ymlを参照ください

 

 

ECS PortalへのログインとBucketの作成

1. ブラウザで、https://<ECSのIPアドレスまたはホスト名>にアクセスします。ユーザ名はroot、パスワードはChangeMeでログインします。

ECS_login.png

 

2. ログイン後にパスワードを変更するように促されますので新しいパスワードに変更します。

ChangeMe.png

 

3. 再度ログインするとGETTING STARTED TASK CHECKLISTが表示されますので、「No thanks, I'll get started on my own」を選択してDashboardに移動します。

Getting_Started.png

 

4. Dashboardに表示されている内容をひと通り確認します。

ECS_Dashboard1.png

 

5. 続いてBucketを作成していきます。「Manage」から「Buckets」を選択してBucketを作成します。今回は「Bucket Name」にbk1、「Bucket Owner」にobject_user1を入力します。入力後、「Next >」で進みデフォルトのまま「Save」して終了します。

Create_Bucket.png

 

6. bk1というBucketが作成されたことを確認します。

bk1_created.png

 

7. 次に、「Users」からobject_user1の行の「Edit」を選択し、「S3/Atmos」にある"Show Secret Key"のチェックボックスをチェックします。Secret Keyに表示されている内容をコピーします。(デフォルトはChangeMeChangeMeChangeMeChangeMeChangeMeです)

Users_SecretKey.png

 

 

 

S3クライアントからのファイルアップロード

1. S3 Browserを起動して「Accounts」から「 Add New Account」を選択し以下のように登録します。

 ・Account Name:ECS

 ・Account Type:S3 Compatible Storage

 ・REST Endpoint:<IPアドレスもしくはホスト名:9021>

 ・Signature Version:Signature V2

 ・Access Key ID:object_user1

 ・Secret Access Key:ChangeMeChangeMeChangeMeChangeMeChangeMe(ECS Portalのobject_user1からコピーしたSecret Key)

S3B_setup.png

 

2. 「Upload」からファイルを選択しアップロードします。

S3_browser_uploading.png

 

 

3. 書き込み後にECS PortalのDashboardを確認します。

ECS_Dashboard.png

 

 

 

おまけ

DellEMCのサポートアカウントをお持ちの場合はCIFS-ECS Toolがダウンロードできます。CIFS-ECS ToolをWindowsにインストールすることでECSをローカルストレージのように利用することが可能です。

CIFSECS.JPG.jpg

 

 

 

参考情報

DellEMC ECS Software Download

ECS Community Edition OVA Installation(GitHub)

分散ファイル システムおよびオブジェクト ストレージのMagic Quadrant

Elastic Cloud Storage データシート

ECS Overview and Architecture

 

 

 

バックナンバー

IsilonianTech 第1回 Isilonとオープンソース ~REX-Ray編~

IsilonianTech 第2回 Isilonとオープンソース ~OpenStack Manila編~

IsilonianTech 第3回 Isilonとオープンソース ~Isilon Data Insights Connector~

IsilonianTech 第4回 Software Defined Storage ~IsilonSD Edge~

IsilonianTech 第5回 Isilonとオープンソース ~Isilon-POSH~

IsilonianTech 第6回 Isilonとオープンソース ~Elastic Stack編~

IsilonianTech 第7回 Isilonとデータアナリティクス ~Cloudera編~

IsilonianTech 第8回 Elastic Cloud Storage (ECS) ~ECS Community Edition~

IsilonianTech 第9回 ISILON + ECS = UNLIMITED ~Isilon CloudPools~

 

 

安井 謙治

Dell EMC Unstructured Data Solutions

UDS事業本部 SE

Filter Blog

By date:
By tag: