Storage Feed

2017/11/09

EMC日本語サポート フォーラムのご紹介

こんにちは、今回はDELLEMC社様のご了解を得て、EMC日本語サポート フォーラムをご紹介させて頂きます。

EMC日本語サポート フォーラムはEMCコミュニティ ネットワーク(略称 ECN)の一部です。 ECNアカウントに登録してログインすることで、新規ディスカッション スレッドやドキュメントの作成、返信やコメントの投稿などのフォーラムの活動に参加できます。

簡単に言い換えると、製品購入前の疑問点や、購入後に、サポートに問い合わせるほど深刻ではない質問をしたり、現場や自社検証によって分かった結果を同じような課題に困っている人のために投稿して共有するサイトです。

質問に回答してくれるのは原則としてEMC社の方なので、回答内容はDELLEMC社の公式なものになります。

ともあれ、メンバー登録をして実際に使ってみませんか?

メンバー登録URLはこちらです。

https://developer-content.emc.com/login/login.asp

00003_2

        URLにアクセスしたら、REGISTER NOW をクリックしてください。

00004_2

必要な情報を入力して SUBMIT をクリックします。

数分後に登録したメールアドレスにベリファイメールが届きますので

Please click here to verify your email address for your account.  をクリックし、登録したユーザアカウントでログインしてみてください。

00001

00002

さっそくディスカッションを投稿してみてください。

00006

詳しいサイトの使い方は https://community.emc.com/docs/DOC-32230 をご確認ください。

以上です。

2017/10/11

AFSはパートナーエコシステムの拡充を通じて新しい機能を追加

記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社のSr. Product Marketing ManagerのShubhika Taneja氏、Principal Product ManagerのShubhankar Chatterjee氏によるものです。原文を参照したい方はAFS Adds New Capabilities Through An Expanding Partner Ecosystemをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

Fig282

Acropolis ファイルサービス(AFS)はエンタープライズクラウドのために最高のNASの特性とパブリッククラウドサービスの特性を同時に提供するために、根本から考え直したファイルサービスです。AFSによって、お客様は仮想マシンと非構造化データを統合することができ、よりシンプルなインフラスタックを手に入れることができます。これまでにないシンプルさ、拡張性、柔軟性、そして継続的なエンタープライズグレードの機能の追加によって、AFSは例えばAmazon社のイラスティックファイルサービス(EFS)のようなパブリッククラウドソリューションの良い特性と従来型のNASの良い特性を同時に提供することができるのです。

AFSはあらゆるNutanixクラスタ内に我々の統合管理プレーンであるPrismから数クリックで展開することができます。AFSはその機能をNutanix APIを利用して豊富なエコシステムパートナーを統合することで拡張していきます。これらのNutanix APIはNutanixコンポーネントをパートナーのコンポーネントにインストールしたり、その逆を行ったりする必要を廃し、エコシステムパートナーがNutanixエンタープライズクラウドプラットフォーム上にソリューションを統合、作成することを驚くほどシンプルに実現してくれます。

こうした今後提供される機能について幾つか以下でご紹介いたします :

インライン アンチウィルス スキャン

お客様は会社の重要なデータをよく利用されているシマンテック社とマカフィー社のアンチウィルスソリューションを利用したインラインでのウィルススキャンによってセキュアに保つことがっできるようになります。NutanixはICAP(Internet Content Adaptation Protocol)を利用することにしました。このプロトコルは標準プロトコルで、様々なセキュリティベンダーや製品でサポートされています。

Fig283

一度SMBクライアントがファイルアクセスのリクエストを送信すると、AFSはメタデータとウィルススキャンポリシーに基づいてそのファイルをスキャンする必要があるかどうかを決定します。もしもスキャンが必要であればAFSはスキャンのためにそのファイルをICAPサーバへと送信します。ICAPサーバがスキャン結果をAFSサーバに報告すると、その結果を元にしてAFSサーバはSMBクライアントに対してアクセスを許可するか、却下するかを決定します。

高速で効率の良いバックアップ

慣習的に、NASの管理者はNASのバックアップについて、NDMPを利用するための複雑なインフラストラクチャをセットアップしなくてはなりませんでした。この作業の中には複雑なファイバーチャネルのゾーニング構成や他にも多くのものが含まれています。Nutanixのコアとなる基盤はこうしたタイプの複雑さを排除するためのものです。ですから、我々がAFSはNDMPのサポートを実装しないと決めたことに驚きはさほど感じないと思います。

NDMPを利用したくないというすべての環境(我々のお客様の中で多く目にしてきました)は慣習的にバックアップソフトウェアでバックアップしなくてはいけないシェアを直接指定するというもので、バックアップアプリケーションは他のNASクライアントがするのと同様にバックアップするファイルを読み込みます。問題はバックアップソフトウェアがインクリメンタルバックアップを行いたいという際に発生します。これを行うためにはバックアップアプリケーションはファイルシステムのメタデータのスキャンを通じて最後のバックアップ移行に変更されたファイルを検知しなくてはなりません。そして、これは数億ものファイルがあるとしたら非常に時間がかかる実装です。

Fig284

Nutanixは効率よく簡単にAFSファイルシェアをバックアップするためのAPIを用意して、道を舗装しておきました。これらのAPIによってバックアップアプリケーションは最後のバックアップ移行に変更されたファイルのリストを受け取ることができます。ですから、ファイルシステムをスキャンして変更を検出する必要はありません。これはNDMPが提供している効率性と同様ですが、NDMPを利用したときに発生する複雑さと制限はありません。発表を行う直前にNutanixはComtrade社とRubrik社にこのAPIをサポートするように働きかけを始め、他のベンダーとも積極的な意見交換を行っています。

グローバル/マルチーサイト ネームスペース

AFSをリリースして以降、我々は頻繁にお客様から2つのユースケースについて耳にする用になりました:

  • 2つのサイトの間で負荷分散を行っているVDIインスタンスがあるVDI環境のユーザーのホームディレクトリをAFSで利用するにはどうすればよいのか?
  • 地理的に分散したオフィスに居るユーザーが同じプロジェクトでコラボレーションを行う際に、WAN越しにファイルにアクセスしたり、所有権のやり取りなどを行わずに済ませる方法はないのか?

このいずれのケースもお客様はこれまでMicrosoft社のDFS-RをWindowsファイルサーバとともに利用してこれに近い機能を実現していました。しかし、これは日常的に発生してしまうファイルの競合とその解決を管理しなくてはならないという悪夢となってしました。この問題を見た時、我々はAFSにDFS-Rのサポートを追加するということは意味をなさず、お客様に同じ問題を発生させてしまうと思いました。本日、我々はPeer Software社とのパートナーシップを発表できることを嬉しく思います。PeerLink製品との統合によって、上のいずれのお客様のケースにおいても課題を解決した上で、AFSのメリットをすべてのサイトで活用頂くことができるのです。

Fig285

これを利用するためにはお客様はPeer Software社からPeerLink製品を購入して、そのソフトウェアを上の図にあるように展開しなくてはなりません。

それぞれのサイトがプロジェクト(もしくはVDIの負荷分散の際には2つのサイト)でコラボレーションすることができ、AFSのネームスペースは独立しています。AFSのネームスペース内で変更が生じる度にPeerLinkソフトウェアはその変更についての通知を行います。PeerLinkはその後、この変更をすべての「Peer」となるAFSネームスペースへとレプリケーションします。これにはファイルロックも含まれるため、ネームスペースは同期され続けます。これによって2箇所、もしくはマルチサイトでの双方向でのプロジェクトのコラボレーションが実現するのです。

ファイル監査

データの汚染は近年当たりのようになってきました。多くのお客様がAFSへのすべてのアクセス・更新監査ログの保存の機能を求めていました。この機能があればAFSへの全てのアクセスについて必要な履歴を保存できるのですが、現在の監査アプリケーションはそれ以上を行っており、監査の情報を保存するだけでなく、リアルタイム分析で何らかおかしな活動が検出された際には警告をおこなう機能なども付属しています。本日、Varonis社とSTEALTHbits社のそれぞれ DatAdvantage と StealthAUDIT® という強力な監査ソリューションとのパートナーシップを発表できることを誇らしく思います。

統合ソリューションを利用ために、お客様は監査アプリケーションを選択することができ、それによって非高増加データに対して適切なセキュリティとデータの統制を行うことができます。

こうした全てのパートナーシップをアナウンスできることを嬉しく思う一方で、同様に重要なポイントはこうした機能はすべて標準のREST APIで実現されているということです。現在我々はこうした選抜したベンダー様と活動を行っていますが、我々は今後我々のAPIが一般公開のステータスになれば全てのパートナー様に公開します。RESTフレームワークを活用し、これらのAPIを誰もが簡単に利用できるようにする予定です。お客様にもこうしたAPIを利用し革新的な利用方法を見つけていただきたいと思っています。我々はこうしたユースケースをもっとよく知るためにも世界中に共有します。

これはまだ始まりにしか過ぎません、AFSの今年の後半の素晴らしい機能にご期待ください!以下はAFSのパートナーシップについて取り上げたプレスリリースで、AFS関連での我々の動きについても触れています。

Disclaimer: This blog may contain links to external websites that are not part of Nutanix.com. Nutanix does not control these sites and disclaims all responsibility for the content or accuracy of any external site. Our decision to link to an external site should not be considered an endorsement of any content on such site.

© 2017 Nutanix, Inc. All rights reserved. Nutanix and the Nutanix logo are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. All other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s).

記事担当者: マーケティング本部 三好哲生 (@Networld_NTNX

Ntc2017_2

久しぶりにテッキーな内容だったかもしれません。AFS、素晴らしいスピードで進化していますし、AFSのREST APIも公開され様々なパートナーシップが結ばれつつあります。インラインウィルススキャン、インクリメンタルバックアップなどここは必ずいるでしょう!という定番やコラボレーション、監査などまで幅広く対応しています。しかもこれほどの統合が実現できるのに、標準APIしか使っていない、とのことですので強力かつ柔軟なAPIのようですね。今後様々な製品が対応してくることが期待できます。

Nutanixはプラットフォーム、これはネットワークソリューション、(仮想マシンの)バックアップソリューションだけではなく、AFSも加わってより強力なものになっていっています!

2017/09/06

HyperFlexのバックアップはVeeamにお任せ!2017

シスコ社のHCIであるHyperFlexのバックアップにはVeeam Backup & Replication(以下、VBR)で間違いないことは、前回お伝えしましたが、最新のVBR 9.5 Update 2では、更に進化し、HyperFlexのネイティブスナップショットとの連携が可能になりました!

VBRの特徴の1つであるストレージスナップショット連携は、これまでもDell EMC/NetApp/Nimble/HPE などのハードウェアストレージには対応しておりましたが、HCIのSDS(Software-Defined-Storage)としては、HyperFlexが初の対応です。

そんなHyperFlexですが、7月末にHyperFlexの最新バージョンである2.5がリリースされました。早速、HyperFlex 2.5(1b)とVBR 9.5 Update2の組み合わせでHyperFlexのネイティブスナップショットとの連携によるバックアップを試してみましたので、ちょっとご紹介しましょう。


まずは、HyperFlexの登録です。VBRの管理コンソールを起動し、[STORAGE INFRASTRUCTURE]で [Add Storage]をクリックします。 
Vbrhx01_3



「CISCO HYPERFLEX」をクリックします。
Vbrhx02_3



HyperFlexの管理用のIPアドレスを入力し、[Next]をクリックします。
Vbrhx03_3



HyperFlexの管理者ユーザー(admin)の認証情報を設定し、[Next]をクリックします。

Vbrhx04



そのまま[Next]をクリックします。

Vbrhx05



サマリーを確認して、[Next]をクリックします。HyperFlexのバージョン情報(2.5.1b-26284)も認識しています。
Vbrhx06



登録処理が実行され、登録が完了します。Vbrhx07_4



バックアップを実行してみたところ、HyperFlex スナップショットの作成と削除のメッセージが表示され、スナップショット連携のバックアップが成功しました。 

Vbrhx09

 

バックアップ中に仮想マシンのスナップショットを確認すると、「SENTINEL」というスナップショットが作成され、その下にVeeamによるテンポラリのスナップショットが作成されています。「SENTINEL」というスナップショットはHyperFlexのネイティブスナップショットを使う際に最初に作成されるスナップショットのため、VeeamからHyperFlexのスナップショットを呼び出していることが分かります。

Vbrhx10a_2


何故、HyperFlexのネイティブスナップショットと連携できると良いのか?HyperFlexとVBRを組み合わせるとどんなリットがあるのか?ピンと来ていない方は、下記のセミナーに参加いただけると、きっとお分かりいただけると思います。東京・名古屋・大阪・福岡で開催しますので、是非ご参加ください!

シスコの爆速堅牢なハイパーコンバージドインフラご紹介セミナー

https://networld.smartseminar.jp/public/seminar/view/814


このセミナーでは最新のHyperFlex 2.5の情報もお伝えします。HyperFlex 2.5では専用の管理ツールのHyperFlex Connectやレプリケーション機能など新機能が盛り沢山ですので、ご期待ください。これからHyperFlexを提案や導入しようとしている方は必見ですが、既にHyperFlexをご利用いただいている方のご参加もお待ちしております。

Vbrhx11_2



最後に、Ciscoと Veeamと言えば、アプライアンスの下記キャンペーンも好評につき、キャンペーン期間を延長しましたので、こちらも併せて宜しくお願い致します。http://www.networld.co.jp/campaign/cisco_veeam_backup/

 担当:臼井

2017/08/31

VMware Cloud on AWS 技術概要

本ブログエントリーはVMware社のR&DでSenior Staff Architectを務めているFrank Denneman氏のブログの翻訳版です。 Frank氏について、詳しくはこちらもご参照ください。

本記事の原文はVMware Cloud on AWS Technical Overviewで閲覧可能です。

ネットワールドのVMwareに関する情報はこちら

昨日我々はVMware Cloud on AWSサービスを立ち上げました。VMware Cloud on AWSはVMware vSphere上で動作するプライベート、パブリック、そしてハイブリッドクラウド環境上でのアプリケーションの稼働ををAWSサービスへの最適化されたアクセスと同時に実現します。このCloud SDDCはvSphere、NSXそしてvSANのテクノロジーによって構成され、みなさんが現状でお持ちのスキルセットで管理、運用できるため、非常に馴染み深いものとなります。AWSインフラストラクチャのベアメタルを活用し、このCloud SDDCはこれまでにない方法で拡張することができます。

VMware Cloud on AWSはサービスです。これはサービスに関して言及する際に製品のヴァージョンを利用しないということを意味します。その代わりに我々はこのサービスが最初に利用できるようになったものをファーストリリースと呼ぶことになります。その後の全てのリリースについてはフューチャーリリースと呼ぶことになります。VMware Cloud on AWSはVMwareによって運用されています。これは短く言うとVMwareがインフラストラクチャリソースに責任を負い、お客様はリソースの消費を担当するということです。この記事は最初に利用時のCloud SDDCのリソースキャパシティを探検するものとなります。

VMware Cloud on AWSのコンピューティング

最初の利用時、VMware Cloud on AWSの構成には4台のホストが含まれています。それぞれのホストは512GBのメモリと2つのCPUで構成されています。これらのCPUはカスタムビルドのIntel Xeon Processor E5-2686 v4 CPUです。それぞれのCPUは2.3GHzで動作する18のコアを内包しています。結果として物理クラスタのコア数は144となります。ハイパースレッディングが有効になっているため、仮想マシンは288のロジカルプロセッサを標準のCloud SDDCの構成として利用ができるようになっています。VMware Cloud on AWSは単一の固定のホスト構成で提供されており、ホスト構成へのコンポーネントの追加オプションは現時点では提供されていないことにご注意下さい。ですがスケールアウト型での拡張が最大で16ホストまで利用できるため、結果として576 CPUコア、8TBまでのメモリを利用することが可能です。

vSphere DRSとvSphere HAが有効になっており、最高の可用性とリソース利用効率を提供します。vSphere DRSは完全自動で、移行のしきい値は標準のvSphere DRSのレベルに設定されており、vSphere vMotion操作が過剰に行われないようになっています。クラスタリソースの高可用性がvSphere HAで提供されており、ハードウェアの自動復帰が行われます。

vSphereの高可用性はESXiホスト障害時の仮想マシンの再起動中にもリソースを保証するためにも利用されます。ESXiホストは監視されており、障害イベント時には障害ホスト上の仮想マシンが代替となるクラスタ内のESXiホストで再起動されます。オーバーヘッドを最小化しながら、生産性を最大化するため、クラスタのvSphere HAの設定は1台のESXiホスト分と等しく構成されています(%ベースのアドミッションコントロールポリシーで25%)。ホスト孤立時の対応は仮想マシンの電源を落とし、仮想マシンを再起動するにセットされています。

Vmcaws_fig1

ホスト障害の修復についてはVMwareが担当します。ホストの障害が恒久的なものであれば、VMwareはESXiホストの交換をユーザーを煩わせること無く行います。障害を起こしたハードウェアの自動的な交換は恒久的なホスト障害による長期間に渡るリソースの減少からの影響を削減します。Cloud SDDCは2つのDRSリソースプールで構成されています。一つ目のリソースプールはCloud SDDCを運用するための管理用の仮想マシンが置かれており、もう一つはお客様のワークロードを管理するためのリソースプールのトップレベルのプールです。お客様は子リソースプールを作成することができます。

Vmcrp720p

VMware Cloud on AWSのストレージ

SDDCクラスタはオールフラッシュのvSANを含んでおり、それぞれのホストは合計で仮想マシンが利用するための10TBの物理キャパシティを供給します。標準のCloud SDDCクラスタでは40TBの物理キャパシティを提供します。仮想マシンのキャパシティの消費は構成されているストレージポリシーに依存します。標準ではRAID-1障害許容の手法が適応されます。ですが、お客様はストレージプロファイルを作成し、よりオーバーヘッドの小さなRAID-5やRAID-6という障害許容手法を利用することもできます。RAID-6の障害許容手法を利用する際には最小でCloud SDDCクラスタ内に6ホストが必要となることにご注意下さい。

それぞれのESXiホストは8つのNVMeデバイスを保持しています。これらの8つのデバイスはvSANディスクグループをまたいで分散されています。単一のディスクグループ内では、1台のNVMeデバイスの1.7TBのストレージがWriteキャッシュ層として利用されます。ストレージキャパシティ層には他の3台のNVMeデバイスが利用され、合計すると5.1TBのストレージとなります。

Vmcaws_fig2

ストレージ暗号化

vSAN暗号化によるデータストアレベルの暗号化またはvSphereの仮想マシン暗号化による仮想マシンレベルの暗号化はVMware Cloud on AWSの最初のリリースでは利用できません。データセキュリティについては全てのストレージNVMeデバイスがAWSによってファームウェアレベルで暗号化されています。この暗号キーはAWSによって管理されており、公開されることも、VMwareやVMware Cloud on AWSのお客様が制御することもありません。

Cloud SDDCの構成

最初のリリースではCloud SDDCはAWSの単一のリージョンと可用性ゾーン(AZ)に限定されています。ハードウェア障害は自動的に検出され、自動修復によって、障害ホストは他のESXiホストへと入れ替えられます。もしも必要な場合にはvSANデータストアがユーザーを煩わせること無く自動的にリビルドを行います。

将来のVMware Cloud on AWSのリリースではVMwareとAWSのパートナーシップを通じてマルチ-AZでの可用性が2つの同一リージョン内の2つのAZをまたいでクラスタをストレッチすることで初めて実現される可能性があります。このまたとない機能によって、従来からのアプリケーションをAWSインフラストラクチャ上で高可用性を得るためにリファクタリングする必要はなくなります。その代わり、同期WriteレプリケーションがAZをまたいで活用されることになり、復元目標点(RPO - recovery point object)はゼロとなり、復元目標時間(RTO - recovery time object)はvSphere HAの再起動時間次第となります。

Spanningaz

VMware Cloud on AWSのネットワーク

VMware Cloud on AWSはNSXを中心として構成されています。このネットワークはCloud SDDC内の仮想マシンのネットワークの提供に最適化されている一方で、Amazon 仮想プライベートクラウド(VPC)ネットワークを抽象化しています。仮想マシンへの論理ネットワークの提供とクラスタスケールアウト時の新しいホストと論理ネットワークVMKernelネットワークとの自動的な接続によって簡単な管理を実現します。最初のリリースではユーザーはVMware Cloud on AWSにレイヤ3のVPN接続で接続します。しかし、将来のリリースのVMware Cloud on AWSではAWSのダイレクト接続とクロスクラウドのvSphere vMotion操作ができるようになります。

オンプレミスのvCenterサーバインスタンスとCloud SDDC内のクラスタ上で動作している管理コンポーネントとの接続にはIPsecのレイヤ3VPNがセットアップされます。またもう一つのIPsec レイヤ3 VPNが作成され、オンプレミスのワークロードとCloud SDDCのクラスタ内で動作している仮想マシンとの接続に利用されます。NSXは全てのネットワークとセキュリティに於いて利用され、Amazon VPCのネットワークから分離されています。コンピュートゲートウェイとDLRは暗黙的なネットワークトポロジの一部として事前に構成されており、お客様が変更することはできません。お客様はご自身のサブネットとIPの範囲を提供するだけです。

Vmcaws_fig4

VMware Cloud on AWSは皆様のワークロードに対応

VMware Cloud on AWSは皆様の現在のスキルセットとツールセットを使いながら利用できるクラウドのリソースを提供します。それぞれのCloud SDDCは今日最も要件の高いアプリケーションを動作できるだけの十分なリソースをご提供します。世界最高のエンタープライズソフトウェアが世界最高のクラウド事業者と融合し、これまでにない方法でデータセンタを稼働、拡張することを実現するのです。

更に詳しくは こちらへ https://cloud.vmware.com/vmc-aws/resources

記事担当者: マーケティング本部 三好哲生 (@miyo4i

Screenshot20141105at0820381

業界はVMworldで盛り上がっていますね。ちょっと時間がうまく取れなかったのでもっとタイムリーに翻訳記事を公開したかったのですが、少し遅れてのリリースです。これまではあまり語られてこなかった、VMware Cloud on AWSを契約するとどうしたリソースが利用できるのか?今回はこれが明らかになりました。すごいスペック・・・。2TB、288スレッドのクラスタ・・・以上に私がびっくりしたのはNVMeを8本も搭載し、うち2本=3.4TBもをWriteキャッシュに振り当てるという豪華っぷり!

NSXでAmazon VPCのネットワークをきれいに隠してしまうのもVMwareユーザーにはうれしいですね。マルチAZでのストレッチにもチャレンジしていくとのこと、ワクワクします。日本に来るのが待ち遠しいですね!

追記 : お値段は?という方がおられましたので、こちらです。米国の価格なのでそのまま日本に来るとは限りませんが、ご参考まで。 https://cloud.vmware.com/vmc-aws/pricing

2017/08/09

NVMeについて従来からのストレージベンダーがあなたに知ってほしくない5つの秘密

記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社のSr. Manager, Technical Marketing EngineeringであるPaul Updike氏、およびSr. Technical Marketing EngineerであるAndy Daniel氏、およびSr. Product Marketing ManagerであるMarc Trouard-Riolle氏によるものです。原文を参照したい方はFive secrets traditional storage array vendors don’t want you to know about NVMeをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

Fig266

Non-Volatile Memory Express(NVMe)は、従来からのストレージ装置が膨大なストレージデバイスを利用し、その駆動のために製品への巨大な投資が必要になるというやり方を破壊しつつあります。どうしてかって? それはNVMeは従来型のストレージアーキテクチャではないからです。実際、フラッシュストレージの最初の波(SSD)もそうではありませんでした。しかし、製品をより市場に早く送り出し、幅広く浸透させるため、ドライブのインターフェイスとプロトコルは変更されませんでした。最初のSSDはフラッシュを従来型のストレージアーキテクチャで利用するために設計されていました。この要件を満たすために、SSDは従来型の回転するハードドライブを模倣しています。データの入出力はハードドライブのインターフェイスを通り、その先に回転するお皿があるかのように振る舞っており、その模倣の持つ制限に縛られているのです。これを心に留めて考えると、以下はNVMeについて従来型のストレージベンダーがあなたに知ってほしくないことなのです:

 

1. NVMe は最初はサーバテクノロジーとして提供される

殆どの新しいテクノロジーと同様に最初のドライブは一般的なデスクトップそしてサーバシステムの内部に搭載されます。今日ではNVMeテクノロジーはほとんどのメジャーなベンダーのサーバー内に搭載して購入することができます。もちろん、Best Buyで個別のユニットを買うということもできます。ゲーマーならそれをデスクトップに搭載しますし、もしも昨年購入したノートパソコンであれば、NVMeはすでに搭載されているかもしれません。残念なことにNVMeと他の多くのマスマーケットを対象にしたテクノロジーはサーバー内で利用されるために設計されており、ストレージ装置で利用されるようになるまでに長い時間がかかります。(Nutanixのハイパーコンバージドインフラストラクチャはサーバーベースのテクノロジーです)

 

2. 新しいアーキテクチャでは高可用性が必要とされる

従来型の装置はSASとSATAインターフェイスを利用するために設計されています。SASは元から1つ以上のコントローラーと同時に接続するためにデュアルポート構成で、装置ベンダーは特殊なトランスポーター(転送機)を利用してSATAでも同じことができるようにしています。NVMeのアーキテクチャはSASまたはSATAのコンポーネントを利用しません。そして、全く新しい設計が必要になります。最初のNVMe 1.1のスペックでは、U.2 デュアルポートのNVMeドライブが2016年の初期にアナウンスされました、しかし、このデュアルポートの能力を持つドライブを出荷しているメジャーなベンダーはありません。デュアルポートのU.2は複数のPCIeレーン(各コントローラーに2つ)が必要だということを覚えておいて下さい。これはスループットを制限する可能性があります。(Nutanix ハイパーコンバージドインフラストラクチャは高可用性のために複数箇所でドライブをマウントする必要はありません)

 

3. NVMe はホットスワップが難しい

NVMeはPCIe上でダイレクトに動作し、PCIeホットスワップがプラットフォームで完全にサポートされていなくてはなりません。ホットプラグ可能として販売されているNVMeドライブはありますが、それは特定の物理プラットフォーム、CPU、オペレーティングシステム、そしてドライバーが揃っている場合だけです。現在のドライバーはサーバープラットフォームとOSのために書かれたものです。繰り返しとなりますが、このサポートにはベンダーの専門性が必要とされます。(Nutanixではワークロードを移行させ、ノードレベルで停止無く修理を行うことができます)

 

4. リモートのNVMeデバイスを完全活用するためにはRDMAが必要となる

複雑怪奇なPCIeのスイッチの設計の他に、リモートのNVMeへ従来型のファブリック(イーサーネットやファイバーチャネル)経由でアクセスするためには遠隔ダイレクトメモリアクセス(remote direct memory access ー RDMA)とNVMe over Fabric(NVMeF)のような新しいプロトコルが必要になります。RDMAでスタックをバイパスせずに、単純なTCP/IPスタックを利用していてはNVMeによるレイテンシーの削減を台無しにしてしまいます。多くの業界のスタンダードと同じように、NVMeFの開発は遅く、現在殆どのストレージベンダーがこれを出荷していません。(NutanixはRDMAを活用する際にNVMeFを利用する必要はありません)

 

5. NVMe をストレージ装置上で利用する場合にはより多くのリスクが集中します

ストレージ装置ベンダーはデータをデータセンタ内で成長、統合させたいため、実際のところ多くのストレージベンダーがこれを推奨しています。多くのベンダーの目的は古い世代のハードウェアの定期的な交換です。これをより早くするため、大きなキャパシティを持つストレージでは同一システム内にデータを固めなくてはなりません。それは「バスケットの中の卵」のようなリスクで、より膨らんでいくのです。(Nutanix エンタープライズクラウドはノードの単位で成長していきます。リスクは集中するのではなく、より分散していきます)

 

NVMEを今すぐに活用するにはどうしたら…

Nutanixは新しいオールフラッシュノードを追加します。NX-9030シリーズプラットフォームはSATA SSDとNVMeを搭載しています。まとめにその方法を記載します: 

1. 我々のクラスターノードはサーバーの標準的なアーキテクチャです

2. 我々の障害と交換の対応はノードレベルで非常に簡単です。NVMeが障害を起こすことも想定済みです。

3. 我々はソフトウェアをNVMeを思慮深く利用するようにカスタマイズし、パフォーマンスを向上させています。

4. 我々は迅速に既存のRDMAテクノロジーを活用する方法を開発しました。これは新たな業界標準には依存しません。

5. 我々のエンタープライズクラウドはリスクを集中させるのではなく分散します。

 

究極的に、Nutanix製品は革新的なソフトウェアです。我々のハイパーコンバージドインフラストラクチャの哲学をベースとした障害前提ウェブスケール設計は迅速な革新的なハードウェアベンダーからの新しいハードウェアテクノロジーの適応を実現します。サーバの革新の波にのることで、我々はお客様がより早くポジティブなビジネス成果をあげることのお手伝いをすることができるのです。

 

© 2017 Nutanix, Inc.  All rights reserved. Nutanix and the Nutanix logo are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. All other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s).

記事担当者: マーケティング本部 三好哲生 (@Networld_NTNX

Ntc2017_2

さて、抽象度の高い記事で、訳しにくいAndy Danielさんも共著のブログですが、割りと今回訳しやすかったです。

ストレージベンダーがNVMeについて知ってほしくない5つの秘密・・・ですが、以前翻訳した「フラッシュにとってネットワークは遅すぎる、どうしたら?」もその一つであると思います。今回はネットワークスピードではなく新たなNX-9030プラットフォームが登場しますので(Readはローカリティで回避、でもWriteでは不可避であった)ネットワークスピードの問題もRDMAで低減してきています。NVMeFを使うとどれぐらい良いのかはこちらなどでも結果が紹介されていますが、リモートへのWriteもローカルとほとんど変わらないようなスピードが実現されています。(これはNutanixを対象とした検証ではありませんし、単にネイティブとイーサーネット、インフィニバンドの比較を行うため、ファイルシステムなども加味されておりません、あくまでどれぐらいのレイテンシなのかということのご参考です)。

2017/06/21

Acropolisファイルサービス(AFS) 2.1 ー より簡単なリソースへのアクセス

本記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社のSr Technical Marketing EngineerであるDwayne Lessner氏によるものです。原文を参照したい方はAFS 2.1 - Easier Access To Your Resourcesをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

AOS 5.1のリリースとともにAcropolisファイルサービス(AFS)もヴァージョンが2.1となり、AFS自身の改善や修正更新がなされています。AFSはAcropolisブロックサービス(ABS)との連携によるユーザーのトップレベルディレクトリの分散処理によって、これまでの従来型のファイルサーバより優れたパフォーマンスと管理機能を提供します。Nutanixの開発チームはAFS 2.1で全体としての改善も続けています。

保護と復元をより簡単に

AFS 2.1以前はWindowsの以前のヴァージョン(WPV - Windows Previous Version)機能のためのスケジュールでのスナップショットは1時間毎の24のスナップショットしかありませんでした。今回、WPVシェアに関しての標準スケジュールをPrismから変更することができるようになっています。

AFSをアップグレード後、AFSは24回の1時間毎のスナップショットを新しい標準の刻みのスケジュールへと変更します :

  • 24回 毎時間
  • 7回 毎日
  • 4回 毎週
  • 3回 舞月

管理者はこれを自身の要件とポリシーに基づいて編集することができます。

Fig236

UIからは各シェアあたりで全リテンションポリシー毎に最大で50というスナップショット数の上限値があります。これについてはNutanix コマンドラインインターフェイスによって緩和することができ、お客様はこちらでは100ファイルサーバ仮想マシンあたり100以下のシェアであれば利用することができます。

MACクライアントのサポート

WPVのUIほどセクシーではありませんが、ホームシェアとしてのMACクライアントのサポートがサポートされました。これ以前のリリースでは一般シェアのみがサポートされます。

簡単な展開オプション

今回、展開についてアドバンスドオプションが利用できるようになり、Prismから適切なActive DirectoryのOUを指定することができるようになっています。小さなアップデートに見えるかもしれませんが、AFSサーバコンピュータオブジェクトをコンピューターの標準OUではないOUに置くことがほとんどです。これによって管理者がコマンドラインを使わなければならない事態や展開時のエラーや災害復旧のワークフロー実施時の苦労を減らせると考えています。ドメイン参加時にAFSサーバのもっとも近くにある書込み可能なドメインコントローラー(Writeable Domain Controller)を選択することもできるようになっています。

Fig237

クリーンで迅速なリソースへのアクセス

Nutanix上のホームシェアはユーザーから短縮UNCパスでアクセスできるようになりました。AFS 2.1以前はユーザーは \\AFS-server\home\<user-name> という形で自身のホームディレクトリへアクセスする必要がありました。幾つかのお客様は \\AFS-server\<user-name> でホームディレクトリへアクセスできるようにしてほしいとリクエストしてきました。もしも何千にもなるユーザーがいたとしたら、それと同じ数だけのシェアをAFSで作成しなくてはならなかったのですが、これはある裏側が意味恐ろしい事になります。AFS 2.1ではすべてのトップレベルディレクトリ(TLD)を仮想シェアとしてエクスポートする機能を備えています。ですから、今後はホームディレクトリへのアクセスに \\AFS-server\<user-name> を指定することができます。

Fig238

Fig239

TLDを仮想シェアとして共有する機能によってグループポリシーでの管理とユーザーが自身のリソースにアクセスすることの両方が簡単になります。もちろんこの機能を各シェアのレベルで向こうにすることもできます。この機能を利用するためにはTLD名がユーザーのアクティブディレクトリのアカウント名と一致する必要があります。

常に最適なサイズに

古くからよくある質問に、どれだけのメモリとCPUをサイジングすれば良いんだい?というものがあります。今回、この質問はほんとうに意味のないものになりました。最初の正式リリースであるAFS 2.0には 1クリック最適化が含まれていました。1クリック最適化ではファイルサーバ仮想マシン(FSVM)とそれを支えるストレージにどの程度負荷がかかっているのかを監視し、スケールアップするか、スケールアウトするかを決定することができました。AFS 2.1では一切の停止を伴わずスケールアップが可能になったのです! FSVMは再起動なしにホットアップデートされます。ファイルサーバへ接続中のクライアントの通信の切断やその他のサービスの停止はありません。CPUとメモリの追加は全て自動化されていますのでビジネスの要求に応じて、利用中にもっと多くの接続をさばけるように調整することも簡単です。

AFS 2.1はすでにダウンロード可能になっています。既存のESXiもしくはAHV環境上に展開またはアップデートしてビジネスをより良いものとしてください。

© 2017 Nutanix, Inc. All rights reserved. Nutanix is a trademark of Nutanix, Inc., registered in the United States and other countries. All other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s).

記事担当者: マーケティング本部 三好哲生 (@Networld_NTNX

Ntc2017_2

AOS 5.1のアップデート情報からAFS部分にフォーカスした記事です。AOS 5.1で正式サポートされたAHV上の仮想マシンへのリソースのホットアドを活用してファイルサーバを完全に非破壊的に拡張できるようになりました。ESXiではホットアドは以前からできましたので、AHVが追いついてきたということになりますね。標準OU以外への対応は記事内にもありますが、やっぱりこれがないと・・・!という最後の1マイルを埋めるようなものにもなっています。

Nutanix上の仮想環境のあまりリソースでファイルサーバ、実に現実的なソリューションだと思います!

さて、来週はNutanix .NEXTが開催されますので水曜日9:00とは限らずで更新されるモードになります。ぜひ@networld_NTNXをフォローして更新記事を見逃さないようにしてください!!

2017/04/18

【CommVault】管理コンソールの言語表示の切り替えってできるの?

こんにちは。

先月、CommVault v11 の最新サービスパック(SP7) がリリースされました。

CommVault v11 SP7 の新機能概要は、CommVault 社の技術ドキュメントのサイトで公開されていますので、ご興味のある方は、ぜひご覧ください!SP7 の適用により、Virtual Server Agent での VMware vSphere 6.5 環境の仮想マシンの保護がサポートされました。技術ドキュメントのサイトは、こちらをクリックしてください。

 

さて、今回は、ちょっとした技術的な Tips を紹介したいと思います。

製品のご提案の際に、お客様から管理コンソールは日本語で対応しているの?ということをよくご質問をいただくことがありますが、CommVault 管理コンソール (CommCell Console) は、もちろん日本語に対応していますので、ご安心ください。

 

CommVault 管理コンソールは、通常、管理サーバ CommServe 上に一緒に導入します。国内のユーザー様の多くは、日本語 OS 環境で CommServe を導入されていると思いますので、CommVault 管理コンソールの言語表示は、日本語がベースとなります。

 

実は、CommVault 管理コンソールの言語表示は、日本語の他に、様々な言語に対応していて言語を切り替えて表示することができます。サポートする言語については、以下の言語となります。

 

  • English (United States)
  • Chinese (Traditional)
  • Chinese (Simplified)
  • French (Canada)
  • French (France)
  • German (Germany)
  • Italian
  • Japanese
  • Russian
  • Korean
  • Portuguese (Brazil)
  • Spanish (Mexico)
  • Spanish (Spain)

 

既にユーザー様の中には、管理コンソールの言語表示を切り替える方法をご存じの方もいらっしゃると思いますが、以下の手順で言語表示を切り替えることができますので、試されたことが無い方は、お試しください!

 

  1. CommServe のデスクトップ上に [CommVault CommCell Console] のショートカットのアイコンをコピーします。
    (ショートカットのアイコンは、C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Commvault\Instance001 に格納されています)

  2. ショートカットのアイコンを右クリックし、プロパティを表示します。(screen_capture_property.PNGをダウンロード)

  3. リンク先のパスの -jar の前にCommVault がサポートするISO言語と国コードを追加し、[OK]をクリックします。

    [リンク先(Default)]
    %JAVA_HOME%\bin\javaw.exe -jar cv.jar commserve_host.company.com 8401 -oemid= 1

    [リンク先の追加例:英語表示]
    %JAVA_HOME%\bin\javaw.exe -Duser.language=en -Duser.country=US -jar cv.jar commserve_host.company.com 8401  -oemid= 1

    [リンク先の追加例:スペイン語表示]
    %JAVA_HOME%\bin\javaw.exe -Duser.language=es -Duser.country=MX -jar cv.jar commserve_host.company.com 8401 -oemid= 1

    その他の言語のISO言語と国コードは、Can I launch the CommCell Console in different languages? (英文) を参照ください。

  4. ISO言語と国コードを追加した[CommVault CommCell Console] のショートカットのアイコンをだダブルクリックして管理コンソールを起動します。英語とスペイン語の管理コンソールの表示例は、以下のダウンロードリンクをクリックしてご確認ください。

    CommCell Console 英語表示ログイン画面 : connect_to_commcell_english.PNGをダウンロード
    CommCell Console 英語表示 : commcell_english_display.PNGをダウンロード  
    CommCell Console スペイン語表示ログイン画面 : connect_to_commcell_spanish.PNGをダウンロード 
    CommCell Console スペイン語表示 : commcell_spanish_display.PNGをダウンロード

 

CommCell Console の英語表示は、CommVault 社の Documentationサイト での設定手順の確認 KBサイト のエラーなどの検索の際に役立つと思いますので、活用してみてください!

 

Edit by :バックアップ製品担当 松村・安田

 

【過去の記事】

 

メーカのサイト:
Simpana早わかり講座

 

CommVault Simpana:番外
CommVault Simpana:番外 クライアントPCのバックアップ バイナリ作成編
CommVault Simpana:番外 クライアントPCのバックアップ パッケージカスタマイズ(Mac OS)編
CommVault Simpana:番外 クライアントPCのバックアップ インストール(MacOS)編

 

導入編:

【連載】第1回 始めてみよう!CommVault Simpana インストール編
【連載】第2回 始めてみよう!CommVault Simpana インストール後の作業とバックアップ編
【連載】第3回 始めてみよう!CommVault Simpana VMwareバックアップ編
【連載】第4回 始めてみよう!CommVault Simpana VMwareバックアップ応用編(1)
【連載】第5回 始めてみよう!CommVault Simpana VMwareバックアップ応用編(2)とリストア
【連載】第6回 始めてみよう!CommVault Simpana データアーカイブ機能を活用してみませんか?

 

製品紹介編:

第一回、最新!データ統合管理ソリューション CommVault Simpana のご紹介!
第二回、データ統合管理ソリューションCommVault Simpana 基本構成
第三回、データ統合管理ソリューションCommVault Simpana Backup
第四回、データ統合管理ソリューションCommVault Simpana Deduplication
第五回、データ統合管理ソリューションCommVault Simpana SnapShot Management
第六回、データ統合管理ソリューションCommVault Simpana Virtualization

 

Tips編:
【CommVault】次期バージョン v11の国内提供が始まりました! 
【CommVault】管理コンソールの言語表示の切り替えってできるの?
【CommVault】CommServe データベースの保護ってどうするの?

2017/03/08

Acropolis ファイルサービス(AFS)でのデータの分散について

本記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社のSr Technical Marketing EngineerであるDwayne Lessner氏によるものです。原文を参照したい方はData Distribution with Acropolis File Services (AFS)をご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

AFS(Acropolisファイルサービス)で作成の出来る共有(シェア)には2つのタイプがあります。それはホームシェア(Home Share)と一般シェア(General Share)です。一般シェアは作成時には6つのvDiskからなるヴォリュームグループによって形成されています。ホームシェアはクラスタを形成するファイルサーバ仮想マシン毎に5つのヴォリュームグループから構成されています。ですから、小さな構成のAFSでも15のヴォリュームグループでホームシェアを構成することになります。ホームシェアはAFSを展開すると自動的に作成されます。

Fig183AFSで利用されるヴォリュームグループ

ホームシェアはファイルサーバを構成するファイルサーバ仮想マシンのトップレベルディレクトリを分割することでデータを分散します。AcropolisファイルサービスはそれぞれのファイルサーバVMが内部のInsightDBと呼ばれるスケールアウト型データベースを利用してどのディレクトリをどのファイルサーバVMが担当するかのマッピングを行います。

Fig184ホームディレクトリシェアの分散

もしユーザーが「\\FileServer1\Users」というシェアを作成し、その中に「\Bob」、「\Becky」、「\Kevin」というトップディレクトリがあったとすると、「\Bob」はファイルサーバ仮想マシン1上に、「\Becky」はファイルサーバ仮想マシン2に、「\Kevin」は3にと、そのように配置されます。ファイルサーバ仮想マシンはディレクトリ名についての文字列のハッシュアルゴリズムをベースとして、トップディレクトリを分散します。

この分散によって、単一シェアを利用するユーザーが非常に大きくなっても対応が可能です。拡張性による問題から、従来からの設計では管理者はシェアを複数作る必要がありました。例えばその最たるものとしてラストネームがA~Mで始まるユーザーのためにコントローラーを一つ割り当て、N~Zまでの人に別のコントローラーを割り当てるというものです。この設計は管理のためのオーバーヘッドという苦痛を生み出し、不必要にアクティブディレクトリを複雑にしてしまっていたのです。こうした理由から、AFSはクラスタ全体で1つのホームディレクトリしか要らないという実装になっています。もしも1つよりも多くのホームディレクトリシェアが必要な場合、nCLIを利用して作成することが出来ます。

トップディレクトリは終結点となっており、基本的にはショートカットです。前の説明と合わせると、全てのユーザーフォルダをルートディレクトリに作成することで適切なロードバランシングが行えるようになります。ショートカットとして見えるため、シェアのルートディレクトリにはファイルを置くことは出来ないようにしています。また、ユーザーのフォルダを展開する前にシェアのルートフォルダのパーミッションの設定を推奨しています。

一般用途のシェア(ユーザーディレクトリではない)はトップレベルディレクトリでの分散を行いません。一般用とのシェアではファイルとサブフォルダは常に特定の単一のファイルサーバが所有権を持ちます。以下の図は2つの一般用のシェア(例:Accouting(経理)とIT(情報システム)部門)が同一のファイルサーバ上に配置されています。

Fig185

2つの目的の異なるシェアを同じファイルサーバ内に配置

ホームディレクトリシェアとは異なり、シェアのルートにファイルを保管することが出来ます。

気になることがありましたら、コミュニティフォーラムでお話しましょう。ご自身の経験をコミュニティでぜひご共有ください。もちろんTwitterでもご質問を受け付けております。ハッシュタグ「#AskNutanix」をご利用ください。

Disclaimer: This blog contains links to external websites that are not part of Nutanix.com. Nutanix does not control these sites and disclaims all responsibility for the content or accuracy of any external site. Our decision to link to an external site should not be considered an endorsement of any content on such site.

記事担当者: マーケティング本部 三好哲生 (@Networld_NTNX

Ntc2017_2

10のシリーズは一旦終了ですが、今回は社内、社外でよく質問を受けるAFS(Acropolis ファイルサービス)についての記事を取り上げました。AFSはNutanixにネイティブに実装されている、、、結局のところABSをバックエンドにしているため、ヴォリュームグループと言う単位で管理を考える必要があり、Windowsのファイルサーバ仮想マシンを利用する場合の感覚とは少し違ってくる部分があります。ですが記事の中にある通り、巨大なホームシェアを(スケールアウトで!)取り扱うことが出来ますので多くのメリットがあります。実際の操作は仮想マシンを作るのと同じ感覚で作れますので特定のお約束だけ理解していればWindowsを立てるより簡単でしょう。次回もAFSの中身を掘り下げる記事を予定しています。

2017/02/01

ランサムウェアの被害が広まる??

日本国内でもランサムウェアの被害の件数と身代金の支払額が大幅に上がっているようです。

”ランサムウェア 2016”で検索するだけでもかなりの記事が出てきます。

被害は、一般企業よりも、医療公共教育関係が多く、全体の8~9割を締めています。報道される事例もあるわけですが、氷山の一角であろうと推測されます。

2016年の統計では、Q2からQ3で急激に件数が延び4倍に達したとの報告があります。

2017年も始まり1ヶ月が経ちますが、今年もウカウカしていられない状況が続きそうです。

また、身代金を支払っても、100%復旧できるかというとそうではないようです。 半数近くがデータが戻らない状況があったようです。 酷い話です。

始めから感染しなければ何も問題がないわけですが、お金を払った後でデータが元に戻らないのは問題です。

ついでに、偽のランサムウェア(感染していないけど攻撃したように見せかけて身代金を要求する)で身代金を支払った事例もあるようで、被害を恐れる心理面に漬け込む悪質な事例です。

インフルエンザと同様避けて通れない状況になってきていますので、感染しても大丈夫なように手立てを考えるべきだと思います。ネットワークには繋がり続けているわけですから、必要な対策をするべきでしょう。

セキュリティ面とデータ保護の2面から取り組むべきです。セキュリティ対策だけでは感染してからは手立てがないので、大事なデータは事前にバックアップが必要です。

それも出来る限り長い期間のバックアップを残すことが重要です。

今年もPCやスマホ、企業だけではなく個人のデータについてもバックアップを考えるよい機会だと思います。

是非、弊社のランサムウェア対策をご覧ください。

ランサムウェア対策:http://www.networld.co.jp/solution/ransomware/

Edit by :バックアップ製品担当 松村・安田

2017/01/18

フラッシュにとってネットワークは遅すぎる、どうしたら?

Fig163


本記事の原文はNutanix社のGlobal Engineering / R&D TeamでManager Business Critical Appsを務めるMichael Webster氏によるものです。原文を参照したい方はYour Network Is Too Slow For Flash And What To Do About Itをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

Fig162フラッシュの技術がデータセンタの形を変えつつあることに疑いを持つ方はもうおられないでしょう。ロックバンドのクイーンは30年以上も前にそれを理解していたようですが!フラッシュはハイパフォーマンスアプリケーションの展開のための経済性を変革しましたし、回転するディスクをベースとした従来型のストレージシステムには多くあったパフォーマンス上のボトルネックを取り除きました。実環境のデータでのハイブリッドストレージ(SSD+HDD)のデータの削減率という記事の中で示したとおり、データの削減のためにフラッシュを利用する必要はありません、ですが、データ削減とともにフラッシュストレージを利用すればフラッシュの容量の経済性を改善することが出来ます(ディスクを利用するよりも安く、フラッシュのパフォーマンスを利用することが出来ます)し、電源や空調を削減し、可動パートがないことによる信頼性の改善を同時に得ることが出来ます。みなさんはまだご存じないかもしれませんが、近年のSSDなどのフラッシュデバイスはハードドライブ以上の信頼性を誇っています。物理的な容量という観点からもSSDのキャパシティは期間あたりのでのダイあたりのトランジスタ数の収容量のおかげで、CPUのパフォーマンスが上がっていくのと同じようなスピードで増えていっています。あるベンダーは既に2.5インチのドライブで16TBという物を出荷開始しており、この価格は2.5インチのハードドライブよりも安くなっており、消費電力も低く、冷却コストも低く、スペースもより小さくすることが出来ます。記事の冒頭の画像はインテルのM.2デバイスのものですが、3.5TBものキャパシティをもち、恐ろしいほどの小さなフォームファクターを実現しています。では、ネットワークはこれにどう対処しなければならないのでしょうか?

ファイバーチャネルを利用しているのであれ、イーサーネットを利用しているのであれ、ネットワークはフラッシュの技術、そしてもっと重要なことにはアプリケーションを上手く動かすために大きな役割を担っています。この理由はとてもシンプルです。データベースの管理者にとっては随分前から知られていたことです。データがアプリケーションから遠くはなれてしまうことで、レイテンシが高くなり、スループットが落ちてしまい、それによってパフォーマンスとユーザーからのレスポンスタイムが劣化してしまうということが原因です。これはフラッシュによってより明確に浮かび上がります、特にキャパシティとパフォーマンスの技術がどんどん先へと進み、1本、もしくは数本のデバイスだけでネットワークのパフォーマンスを限界に追いやってしまうことになるからです。こうした理由は幾つかのエンジニアリングシステムがインフィニバンドのネットワークやRDMAを利用するための一つの理由ですが、それでさえ、遅いのです。以下は3つの異なるフラッシュデバイスと現在のイーサネットネットワーク技術のスループットを比較したグラフです。

Fig164

数多く目にする2.5インチのホットプラグ出来る一般的な形のフラッシュデバイスは今日では500MB/sのスループットを実現でき、最大で50K(5万)か、それ以上のIOPSを低遅延で実現することが出来ます。ですから、たったの2本のドライブで10GbEのイーサネットワークを飽和させますし、4本あれば16Gb/sのFCネットワークも飽和させてしまいます。幸いなことに、我々はサーバごとに複数のNICポートもしくはHBAを通常利用しています。しかし、これはストレージ装置が数十から数百のドライブもしくは、サーバ内、もしくはストレージシェルフで12~24のドライブを利用するようになると役には立ちません。もちろん、今日一般的なフラッシュの技術であったとしても、それをネットワークに接続するのであれば、そこがパフォーマンスのボトルネックとなり、全パフォーマンスに近い値をなし得ることはほとんど不可能です。

さて、今日のNVMeへと目を移しましょう。これは次世代のフラッシュテクノロジーであり、2016年の終わりまでには一層普及し、2017年にはメインストリームとなっていく技術です。それぞれのデバイスは40GbEのNICを飽和させるのに充分なスループットとIOPSになります。もし、システム内に2つのデバイスがあるとしても、デュアルポートの40GbEのNICを飽和させてしまいます。これがEMCのDSSDのようなNVMeベースのストレージシステムが従来型のネットワークでストレージとサーバを接続しない主な理由で、そのかわりにDSSDは多くの第3世代 PCIe接続を多く束ねて接続を実施しています。彼らは既にネットワークが大きなボトルネックで、NVMeベースのフラッシュが提供するようなパフォーマンス能力を届けるためにはおそすぎるということを認識しているのです。それぞれのNVMeデバイス自体は今日我々が目にする一般的なほとんどのエンタープライズストレージのフラッシュよりも6倍から8倍は高速です。今日どれだけのお客様が40GbEのNICや32Gb/sのFC HBAをデータセンタ内のサーバに搭載しているでしょうか?

SSDは速いです。NVMeをベースにしたSSDはもっと速いです、ですが、インテルとマイクロンが共同で開発している3D Xpointはブッたまげるほど速いのです。3D Xpointは2015年にアナウンスされ、エンタープライズのプラットフォームへの導入は2018年か2019年と期待されています。これは今日一般的なエンタープライズのシステムで利用されているSSDの1000倍高速です。3D Xpointが提供するパフォーマンスによって、マザーボード、プロセッサ技術、メモリバス、そしてそれ以外のすべてが強力にブーストされることになるでしょう。デバイス単独でもマルチポートの400GbEネットワーク(400GbEは100GbEの次に予定されています)を飽和させるのに充分です。これを今すぐにネットワークへと接続したとしても、ネットワークを1年は待たなくてはなりません。3D Xpointは150ナノ秒以下のレイテンシを提供すると予想されており、これは今日の40GbE、100GbEのスイッチポートよりも速いのです。Gen3/Gen4のPCIeを利用したとしてもこれほどのパフォーマンスへの対応には充分に速いとはいえません。インメモリデータベースの影響を考えなんて、とんでもない!これはDRAMのスピードで動作しているのです。

Fig165

上のCrehan Research Inc.のデータが示すように、10GbEと40GbEのポートの利用は増え続けており、100GbEのポートのコストも下がりつつ有ります。しかし、100GbEはまだ幅広く受け入れられているとは言い難く、今時点では40GbEのサーバもまだという状況です。Crehan Researchの2015年のレポートによると100GbEは2017年から広く利用され始めると予測しています。しかし、これはスイッチングやバックボーンでの話であり、サーバーでの利用ではありません。NVMeがメインストリームとなり、3D Xpointを数年先に控えても、それぞれのサーバ間のネットワーク接続はこの1000倍の隔たりを短い時間では吸収しきれません。本来でいえばデュアルポートのTbEの接続を備える必要があるのです。

ですから、こうした証拠からもしフラッシュをネットワークに接続するとしたら、パフォーマンスへ影響を与えるボトルネックと投資への有効性への制限をある程度は抱えてしまうことになるのです。それと同時にお持ちのフラッシュが叩き出す可能性があるスループットに近いレベルでのデータの保護についても保証がほしいと考えるでしょう。どうすれば両立できるのでしょうか? 高いパフォーマンス、低いレイテンシ、アプリケーションに可能な限り近いデータ、それでいてデータ保護を保証できる方法は?

簡単な答えはSSDをローカルのRAIDカードに接続する、ということになるでしょう。これは2.5インチのSSDであればうまくいくでしょう(もちろん、パフォーマンスの観点から複数のRAIDカードをサーバに搭載しなくてはなりません)、しかし、これはNVMeや3D Xpointでは上手く行きません。複数のローカルのRAIDコントローラーを全てのサーバに入れる、ということは個別に管理しなくてはならない数百、数千のストレージキャパシティのサイロを生み出します。我々は長い時間をかけてこの管理のオーバーヘッドを集中管理することで回避できるアーキテクチャを作り上げてきました。この新しいテクノロジーを活用すべきで、後戻りすべきではありません。

現実的な回答は2つです、一つ目は仮想化、そして二つ目は本来の意味で分散されているシステムアーキテクチャへの投資で、そのこころはデータローカリティという概念です。データローカリティを持つアーキテクチャはデータ保護のために分散しながら、一方でデータがアプリケーションにとってローカルにあるということを保証します。仮想化が必要な理由は膨大なまでの高いパフォーマンスを持つストレージがあり、単独のアプリケーションではそれを現実的に使いこなせないからです。仮想化を利用することで、コンピューティングとストレージのキャパシティとパフォーマンスを充分に利用することが出来るのです。幸福なことに、インテルはプロセッサの能力を毎年向上させ続けており、コンピューティングのためのコアを、ハイパフォーマンスストレージのためにも利用することが出来るようになっているのです(プロプライエタリなコンポーネントは必要ありません)。

データローカリティの概念は大きく成長し、拡張する必要がありながら、データ保護と高いパフォーマンスが必要となる多くのウェブスケールアプリケーションで利用されています。データローカリティの概念で、膨大なネットワーク負荷を減らすことが出来、それがボトルネックに成長することを防ぐことが出来て、新しいタイプのフラッシュテクノロジーの将来を保証することが出来るのです。データはアプリケーションからはローカルのPCIeバスを通じてメモリに読み込まれ、書き込み、もしくは変更だけがそのデータを保護するためにネットワークを経由します。データローカリティをベースとしたアーキテクチャが適切に実装されていれば、拡張はリニアに行え、想定通りの一貫したパフォーマンスが得られるのです。これによって多くの推測での作業やトラブルシューティング、ビジネスにおけるリスクを削減できます。これはアーキテクチャが環境へのシステムの追加や退役などの矢継ぎ早に変更される要件に適応する能力をより多く保持しているからです。

データローカリティをもつ分散アーキテクチャを利用して、カスタムメイドのアプリケーションや新しいウェブスケールのビッグデータアプリケーション(Hadoopやそれに準じるもの)へも対応が可能です。ですが、もしこうしたタイプのアーキテクチャからメリットを受けることが出来ない開発者がいない場合、どうしたメリットが有るのでしょうか?新しいストレージの技術に適応可能なアーキテクチャでかつ、変化の起こりつつあるデータセンタの将来を保証できるものは?その答えはSANではありません。ここで述べてきたとおり、フラッシュをネットワークの終端に接続するとしたら、その近く以外ではなにも実現ができないのです。現在存在する唯一のソリューションはハイパーコンバージドシステムで、サーバとストレージは単一のユニットに融合しており、それは分散アーキテクチャをなしているのです。

すべてのハイパーコンバージドシステムはデータローカリティの概念をその中に実装しているわけではありません。ですから、注意深くベンダーを選定してください。それぞれのベンダーをご自身の要件とビジネスのニーズにおいて評価し、どのベンダーが大きなアーキテクチャの変革無く、将来に渡って投資を保護してくれるのかをお考えください。幾つかのベンダーはアンチローカリティをプロモーションし、お客様へ単に多くのネットワークポートを購入しながらオールフラッシュを利用することを推奨しています。残念なことに、ネットワークカードはフラッシュのテクノロジーに対応ができません(400GbEでも遅いのです)。ですから、パフォーマンスは最高のものが保証されませんし、そのアーキテクチャではどんどんと変化していくフラッシュのテクノロジーをシームレスに採用していくことも出来ないのです。

さらに、一度フラッシュに投資を行い、それをアプリケーションの近くへと配置すれば、CPUの利用率も上昇させることが出来るということも付け加えさせてください。特定のユースケースにおいてこれは劇的です。これはストレージがもはやボトルネックではなくなったということが原因です。アプリケーションはIOの完了を待つ必要がなくなりますので、ユーザーへのレスポンスが良くなりますし、バッチジョブはより早く完了しますし、より短い時間で多くのトランザクションからなるプロセスを実行できます。結果として、CPUのアイドルの時間がより少なくなるのです。究極的にはより短い時間でより多くの有益なしことをこなすことが出来ます。ですから、フラッシュを利用して急にCPUの利用率が80%を超えたとしてもビックリしないでください。これは期待通りです。投資がすべて良い方向へ使われた結果に他なりません。それとも、もっと沢山の機材を購入されますか?

終わりに

この話とそれ以外の話をビールを飲みながらNutanixの開発エンジニアであるTony Allen氏としているビデオを以下から見ることが出来ます。以下のビデオはエンジニアとビールを飲もう!シリーズの1つです。(訳注:字幕は入れておりません)

データローカリティは唯一の将来が保証されたデータセンタアーキテクチャであり、かつ、データセンタを継続的に破壊し続けるフラッシュテクノロジーの進化を取り込むことが出来るものです。Nutanix(私はそこで働いています)はデータローカリティをアーキテクチャのコア部分として本当に初期のリリースから取り入れています。この主な理由はアーキテクチャは拡張し続けられなくてはならないものであり、過去5年間に導入された異なる世代の環境にその下のアーキテクチャの変更無く受け入れられるものでなくてはならないからです。もちろん、起こりうる変化に対応して将来保証されていなくてはなりません。我々はお客様に様々なプラットフォームを組み合わせて使っていただくことが出来るようになっています。それでいてデータをアプリケーションにとってのローカルにし、データとアプリケーションの間のパスをできり短くし、アプリケーションのレイテンシを低くすることが出来るのです。

記事担当者: マーケティング本部 三好哲生 (@Networld_NTNX

Ntc2017_2

さて、前回に引き続きオールフラッシュの内容ですが、その内容は衝撃ではありませんか? 今後はフラッシュデバイスがどんどん早くなり、SSDが安くなっていく・・・ここまでは様々なストレージベンダーもが口をそろえて同じ事を言いますが、フラッシュデバイスはもっと早くなり・・・SANでは対応ができなくなる(もしくは普及もしていないような高価な高速なNICを買い続ける?)ということです。

もちろん、普及しなければNIC値段は下がりませんのでジリ貧ですが、「データローカリティ」を備えたHCIであればこのネットワークを超えるスピードを持つフラッシュを効率的に(もちろん、Writeが極端に多いアプリケーションがあれば話は別ですが、いろいろな仮想マシンで負荷の平均化が出来るでしょう)データセンター内に取り込むことが出来るのです。

アプリケーションとデータを近くする以外にはネットワークのボトルネックを通さなければいけませんので、正にこの話はPernixDataが描いていたストーリーですし、それを買収したNutanixがどこを見ているのかが分かりやすい記事だと思いました。2017年、いよいよPernixDataのテクノロジーが入ったNutanixが楽しみです!