Topics started by TetsuoMiyoshi

158 Topics

Nutanixが、パブリッククラウドから プライベートクラウドへのアプリケーションモビリティを発表

本記事2018年5月9日にMarc Trouard-Riolleが投稿した記事の翻訳版です。 原文はこちら。 Nutanixのお客様が、既存のワークロードをオンプレミスのNutanix Enterprise Cloudに移行するためのシンプルできめ細かな手段として、Xtract for VMsが発表されたのは、ちょうど7ヶ月前になります。お客様は、容易かつ迅速な移行手段によって、ワークロードを稼動できるようになるまでの時間や、価値提供までの時間を短縮することが可能になります。このような効果によって、Xtractは、何百社という非常に多くの企業に採用され、Microsoft WindowsやLinuxオペレーティングシステムをベースとした1万2,000ものVMを移行するために活用されてきました。 本日は、パブリッククラウドからのVMの移行を可能にする、Xtractのアプリケーションモビリティの次期リリースについて発表させて頂きたいと思います。   どんなVMの移行が可能になるのでしょうか?   Xtractの次期リリースでは、パブリッククラウドからNutanix Enterprise Cloudに対するVMの移行元として、Amazon Web Services (AWS) が追加されます。 なぜAWSからのVMの移行を発表したのですか?   自社で構築するのか、それともレンタルすべきかといういうテーマは、全ての企業が自問してきた課題です。パブリッククラウドにおける当初の戦略は、インフラストラクチャーをレンタルした方が簡単で安く済むというものでしたが、実際には、企業の優先事項が変わった場合、逆に時間やコストがかさむ結果となっていました。そこで、VMをパブリッククラウドやオンプレミスのインフラストラクチャーなど、別の場所に移そうという考えが浮上しました。   FacebookやDropboxといったパブリッククラウド環境からの移行を選択する企業は珍しくはありませんが、企業の規模に関わりなく、移行に伴う共通の課題が存在するのです。最近注目を集めているパブリッククラウドのサービス停止やレイテンシの問題が、企業のセキュリティやコンプライアンスに対する不安をさらに煽っています。   Nutanixでは、ベンダーロックインや高額な費用が発生することなく、

Xi Clusters: 完全なるハイブリッド

本記事は2019年5月8日のCTO, Cloud ServicesのBinny Gillによる記事の翻訳版です。 原文を参照したい場合はこちら。 5億年ほど前、海の生き物は陸上への進出を開始しました。多くの試行錯誤を通しての進化によって、いくつかの選ばれし生き物は陸上と水中の両方で生活できる能力を獲得します。両方の場所での生活を当たり前と感じることができるようになるこの能力は劇的な躍進であり、このハイブリッドな動物にとって成功の主要因となります。しかしながら、ほとんどの魚類は今日においても海洋での生活をそのまま残しています。魚類を個体で水族館に展示する人はいませんし、その水族館を湿地帯の中に作って、それを適応だとか、移行だとは言わないでしょう。これは不自然なlift-and-shift(手間のかかる引っ越し)です。生は(そして、さらに重要なことに死は)、自然と脆弱な進化をふるいおとし、柔軟性と効率性を備えた優れたデザインを生き残らせます。しかしこれはおよそ2億年前に行われた試みと熟成の連鎖を経て、真のワニ(クロコダイル)が登場することになります。それが故に彼らはこの惑星を支配し、大型動物の天敵で有り続けています。 "The eye of a caiman" by Another Seb is licensed under CC BY-NC-ND 2.0 テクノロジー産業においても進化はおこりますが、もっと劇的なスピードで行われます。およそ10年ほど前、エンタープライズのITインフラストラクチャはクラウドへの以降という課題に遭遇しました。これは初期投資を減らしたい、俊敏性を上げて、グローバルスケールでビジネスを迅速に拡大したいという欲求によって駆り立てられたものです。期せずして訪れた進化はハイパーコンバージドインフラ(HCI)と呼ばれ、ほぼ同時に発生しました。クラウドのような機能をエンタープライズのインフラストラクチャへもたらしたのです。3階層アーキテクチャは魚類のようなもので、クラウドの中では生き延びることができません。検索エンジン企業による初期のSANとNASアプライアンスを用いた3階層アーキテクチャの試みは失敗に終わりました。HCIはエンタープライズの中の新たなクラウドのようなアーキテクチャ内において、淘汰されることなく生き延びています。この

Nutanixの回復力 パート1 ノード障害時のリビルドのパフォーマンス

本記事は2018年5月30日にJosh Odgers氏が投稿した記事の日本語版です。原文はこちら。本シリーズの索引はこちら。 2013年半ばからNutanixに勤務し、ビジネスクリティカルなアプリケーション、スケーラビリティ、回復力、パフォーマンスに注力してきました。私はお客様やパートナーと、回復力について、また、Nutanixプラットフォームをどのように構成するのがベストなのかについて、たくさんの議論をしています。 Nutanixプラットフォームの多くの強みの1つであり、私が多くの時間とエネルギーを費やしている分野は、回復力とデータの整合性です。それには障害のシナリオとプラットフォームがどのように対処するかを理解することが重要です。 Nutanixは、独自の分散ストレージファブリック(ADSF)を使用して、仮想マシン、コンテナ、さらには物理サーバーにストレージを提供しています。このストレージは、レジリエンシーファクター(RF)2または3で構成することができます。つまり、回復力とパフォーマンスのために、データは2つもしくは3つのコピーが保存されます。 単純化して考えれば、RF2とN+1(例:RAID5)、RF3とN+2(例:RAID3)を比較するのは簡単です。しかし、実際には、RF2と3は分散ストレージファブリックのおかげで、従来のRAIDよりもはるかに高い耐障害性を持っています。これは、障害からのリビルドを極めて迅速に行うことができることと、障害が発生する前に問題を検出して解決するプロアクティブなディスクスクラビング機能を備えているためです。 Nutanixは、読み取りと書き込みのたびにチェックサムを実行し、データの整合性を最大限に確保するための継続的なバックグラウンドスクラビングを行います。これにより、LSE(Latent Sector Errors)やビットロット(Bit Rot)、通常のドライブの消耗などが事前に検出され、対処されるようになります。 ADSFの回復力を議論する際に重要なのは、ドライブやノードに障害が発生した場合に、RF2またはRF3に準拠した状態まで回復する速度です。 リビルドは、すべてのノードとドライブにまたがる完全な分散処理(多対多の処理)です。ですから、非常に高速ですし、ボトルネックを回避するため、そして稼働中のワークロードへの影響を軽

Nutanixの回復力 – パート2 - RF2からRF3への変換

本記事は2018年5月31日にJosh Odgers氏が投稿した記事の日本語版です。原文はこちら。本シリーズの索引はこちら。 パート1では、Nutanix AOSがAcropolis分散ストレージファブリック (ADSF)のおかげで、ノード障害からのリビルドを高速かつ効率的に行う能力について説明しました。パート2では、ストレージコンテナがどのようにしてRF2からRF3に変換されるのか、また、その操作が完了するまでのスピードについて、紹介したいと思います。 今回のテストでは、クラスター内に12台のノードしか存在しません。  まず、ストレージプール容量の使用状況から見てみましょう。  現在、クラスター全体で50TB超のストレージ使用量であることが確認できます。 RF3への変換、つまり簡単に言えば全データの3つ目のレプリカを追加する際には、十分な空き容量を確保する必要があり、さもないとRF3のコンプライアンス上、問題があります。 次に、クラスタ(およびメタデータ)のRedundancy Factor(冗長化係数)をRF3に増やします。これにより、クラスタはRF3コンテナをサポートし、メタデータの観点からは少なくとも2つのノード障害に耐えることができます。  次に、対象のストレージコンテナをRF3に増やします。 コンテナがRF3に設定されると、Curatorはクラスターが設定されたRedundancy Factorに準拠していないことを検出し、追加のレプリカを作成するためのバックグラウンドタスクを開始します。 今回のケースでは、ストレージプールに約50TBのデータがある状態でスタートしたので、このタスクでは50%のレプリカを作成する必要があり、最終的には約75TBのデータを格納することになります。 新しいRedundancy Factorに準拠するために、クラスターが25TBのデータを作成するのにかかった時間を見てみましょう。  今回は、7GBps以上のスループットで3時間未満の処理時間を示しており、1時間あたり約8.3TBとなりました。このプロセス全体を通して、クラスターはRF2レベルの完全な回復力を維持しつつ、このフェーズで新しい書き込みが行われた際には、すべてRF3で保護されていたことに注目してください。 下の図は、ストレージプールの使用量が運用中にリニアに増加してい

データベースワークロードのためのNutanixのパフォーマンス

 本記事は2021年11月24日にGary Little氏が投稿した記事の翻訳版です。原文はこちら。  皆さん、ようやくここまで来ました。  全面公開です。私は2013年からNutanixのパフォーマンスエンジニアリンググループで働いています。私の意見は偏っているかも知れませんが、それによってNutanixのストレージの性能についてはそれなりの経験と実績を持っています。すでにNutanix上でデータベースワークロードを稼働させている多くのお客様がおられます。しかし、これらのハイパフォーマンスなデータベースを依然として従来型のストレージ上で稼働させるとどうなるでしょうか? 2017年の.Nextでプレゼンテーションを行った際の資料を掘り出してきて、それに最近のプラットフォーム(AOS 6.0とNVME+SSDのプラットフォーム)のパフォーマンスを追加しました。このランダムReadのマイクロベンチマークのパフォーマンスは2倍以上にもなっています。HCIシステムを数年前にご覧になって、その際に必要なパフォーマンスが出ないと結論づけた方 ― もしかすると、今日出荷されているハードウェアとソフトウェアのシステムでは皆様の要件を達成できるかも知れません。更に詳細は下に。  私のラボの中にあるまだ出荷されていないビルド(※訳注:本日時点で6.1としてすでに出荷開始されています)のAOSが動作しているもう一つのクラスタを見てみましょう。このクラスタも2枚のoptaneドライブとRDMAに対応したNICを搭載しています。この4ノードのシステムでのマイクロベンチマークの結果は?   ワークロード 結果 ノート 8KB ランダムRead IOPS 1,160,551 IOPS 部分的にキャッシュされている 8KB ランダム Write IOPS 618,775 IOPS RF2でフラッシュメディアに完全にレプリケーションされている 1MB シーケンシャル Write スループット 10.64 GByte/s ネットワークスピードの上限に到達、RF2でフラッシュメディアに完全にレプリケーションされている

ServiceNowとNutanixの連携 その2

本記事は2019年12月12日にNutanix Solutions Architect - AutomationのSho Uchidaが統合した記事を一部転記したものです。 全文を参照したい場合はこちら。 本シリーズ(全5回)では ServiceNow社の提供する開発者インスタンスを用いてシンプルなServiceNow-Nutanixの統合環境を作ることを目指します。 本記事(その2)では 前回ご紹介した3つのユースケースのうち1つ目、「ServiceNowのイベント、インシデントとNutanixのアラートの統合」について実装方法をご紹介します。 Prism Proの機能である、X-Playを用いてNutanixのアラート発報を契機にアラート情報をServiceNowに送信します。 前提条件 Nutanix Prism Central v5.11.1 以降 Prism Pro ライセンス(X-Play使用のため) AOS/Prism Element 5.9 以降 ServiceNow Incident Managementプラグイン Event Managementプラグイン 手順 1. Prism Central側の準備 アラートや管理者のクリックを契機に定義されたアクションを自動実行出来るX-Play(Prism Proライセンスが必要)という機能を使用します。X-Playについて詳しくはこちらをご参照下さい。 手動での設定方法、スクリプトによる一括設定の2パターンがあります。 1a. 手動での設定方法 1a-1. Playbook設定 Prism Centralのダッシュボードから”プレイブック”に移動します。 "プレイブックの作成"ボタンを指定し、トリガとして”Alert”を選択します。"アラートポリシー"欄にServiceNowに送信したいアラートを選択し、”アクションの追加”を指定します。 定義されたアクションリストから”Send to ServiceNow”を選択します。 以下を記入し、”保存して閉じる”を指定します。 ServiceNow Instance Name: ServiceNowインスタンス名(https://[こちらの文字列].service-now.com/) Username: admin Password: ServiceNowイン

書き込みI/O パス (FTT1/RF2) の比較– Nutanix vs VMware vSAN

本記事は2020年2月27日にJosh Odgers氏によって投稿された記事の翻訳版です。原文は こちら。本シリーズの索引はこちら。 本シリーズではこれまでにNutanixでは重複排除や圧縮はもちろんのこと、イレイジャーコーディングを利用した場合であったとしても、より高い容量効率、柔軟性、回復力、そして性能をより多くの利用可能な容量ととともに、ご提供できることを学んできました。 更に、Nutanixは遥かに簡単に優れたストレージの拡張性を提供でき、ドライブ障害の影響を劇的に低減できることも学んできました。 そこから我々はギアを変え、混在クラスタのサポートについて取り上げ、これがなぜHCIプラットフォームの拡張能力、そして完全な置き換えや新たなサイロを作ることなくより強力なROIを実現に重要であるかを学びました。 ブログシリーズの今回のパートではそれぞれの製品の書き込み操作についてのI/Oパスについて、ミラーリング(vSANにとってはFTT1、そしてNutanixにとってはRF2)を例に上げて取り上げていきます。 それとは別にソフトウェア定義のストレージを「インカーネル」vs「コントローラーVM(CVM)」それぞれに展開する場合の比較の記事を公開する予定です。今回の記事ではトラフィックがどのようにノード間を飛び交うか、クラスタをどのように利用するかにフォーカスを当てたいと思います。 vSANとNutanix ADSFの両方で全くの新しい4ノードのクラスタがあり、600GBのvDiskの仮想マシンが1台あると考えましょう。600GBという値は2つの理由からこの値を選んでいます。 後ほど引用するVMwareの記事でもこの大きさを利用している 600GBということはvSANはディスクを複数のオブジェクトに分割する必要があります、これはvSANにとってプラス要素です。(<255GBであれば単一オブジェクトということになります>)vSANから見てきましょう: vSANは255GBというオブジェクトのサイズの上限からvDiskを3つのオブジェクトに分割します。つまり、3のオブジェクトと3つのレプリカ、そしてWitness(ウィットネス)が1つあるということになります。 オブジェクトはVMがホストされているノードともう1台の別のノードに以下に示すとおり配置されることにな

Nutanix と HPE が統合されたハイパーコンバージドインフラストラクチャアプライアンスを提供

本記事はMarc Trouard-Riolleが2019年8月1日に投稿した記事の翻訳版です。 原文はこちら。 code:.NEXT JapanでもHPE ProLiand DXのセッションが予定されています。NTX-29 14:55-15:35パートナー同時通訳同時通訳ついに出た!Nutanix on HPE DX:技術詳細から見積もりのコツ、おススメの売り方まで徹底解説 ※販売パートナー様限定(本セッションの受講にはNDAを含む有効なパートナー契約が必要となります。)Nutanix, Inc.ベン・ウィー・ゴーニュータニックス・ジャパン合同会社小林 正和HPE + Nutanixソリューションがいよいよ始まります! HPE ProLiant DX アプライアンス ファミリーの詳細をご紹介。クオリティの高いHPE ProLiantをベースにNutanixを組み合わせ、HPEを好まれるお客様にもお勧めしやすいソリューションが提示可能となります。技術的な詳細から、価値提案、見積もり方法まで、詳しく解説いたします。 2019年の4月、NutanixとHPEは統合されたハイブリッドクラウド・アズ・ア・サービス(aaS)ソリューションを市場へ投入するこというあらたなグローバル・パートナーシップをアナウンスしました。この合意によってNutanixのチャネルパートナーは直接HPEベースのアプライアンスとNutanix Enterprise Cloudソフトウェアと共に販売することができるようになります。 Nutanixはこの先のさらに次なるステップとしてHPE ProLiant DXを発表できることを大変喜ばしく思います。これは業界標準の最もセキュアなサーバーとしてすでにProLiantとAppolloプラットフォームで培ってきた基盤となるHPEサーバテクノロジーをベースとした幅の広いNutanixの統合されたアプライアンスです。 「HPEはHPEとNutanixのパートナーシップによってお客様により幅の広い選択肢を提供できるようになったことについて大変喜ばしく思います。」とSenior Vice President & General Manager, Volume Global Business Unit, Hewlett-Packard Enterpri

Nutanixのメリット その4: きめ細やかで効率性の高いスナップショット

本記事はNutanixのTechnical Marketing EngineerのMike Umpherysが2022年9月1日に投稿した記事の翻訳版です。原文はこちら。 これまでの記事でNutanixの分散アーキテクチャがどのようにビジネスクリティカルアプリケーションとデータベースに最適なのかをご紹介してきました。このアーキテクチャはその上に構成される他のすべての機能の基盤となっています。この記事では、クローンの作成時間をスピードアップし、あっという間の復元を実現するきめ細やかで効率的なNutanixのスナップショットに焦点を当てることにします。まず最初に何がスナップショットで何がスナップショットでないのかを定義しておきましょう。スナップショットは任意の時間のシステムの状態を参照する事ができるものです。しかしながら、システム内でバックアップを取る際にスナップショットを使うことはできますが、スナップショット自体はバックアップではありません。きめ細やかで効率的なスナップショットはNutanixのデータ保護機構の基盤です。 Nutanixは大規模なLUNやコンテナのレベルではなく、仮想マシンの目線でのスナップショットを単一のvdiskの単位で提供しています。Nutanixのスナップショットの先進性を理解するためには、まずは現在利用されている様々なタイプのスナップショットを理解する必要があります。現在エンタープライズのIT分野で広く利用されているスナップショットにはcopy-on-write(CoW)とredirect-on-write(RoW)の2つのタイプがあります。しかしながら、これらの2つのスナップショットの実装は同じではありません。それぞれの実装にはメリットとデメリットが存在します。Nutanixはいくつかの重要な理由からRoWのスナップショットを選択しました。1つ目は、多くの数のReadとWriteをリダイレクトについてです。RoWでは保護されているブロックへの更新を新たな場所へとリダイレクトし、その後メタデータ内のポインターをその場所を参照するように更新します。これは結果として1回のWrite操作です。RoWのスナップショットからの復元を行う際にはシステムはどこにデータが保存されているのかを探し出し、それを直接読み出すだけです。CoWは保護されたブロックを更

読み取りI/Oパスの比較 - Nutanix vs VMware vSAN

本記事は2020年3月2日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 本シリーズではこれまでにNutanixでは重複排除や圧縮はもちろんのこと、イレイジャーコーディングを利用した場合であったとしても、より高い容量効率、柔軟性、回復力、そして性能をより多くの利用可能な容量とともに、ご提供できることを学んできました。 更に、Nutanixは遥かに簡単に優れたストレージの拡張性を提供でき、ドライブ障害の影響を劇的に低減できることも学んできました。 そこから我々はギアを変え、混在クラスタのサポートについて取り上げ、これがなぜHCIプラットフォームの拡張能力、そして完全な置き換えや新たなサイロを作ることなくより強力なROIを実現に重要であるかを学びました。 前回は、書き込みI/Oパスの比較について学習し、クラスタ内のVMの現在の場所とパフォーマンス/容量の使用率に基づいた、データをインテリジェントに配置するNutanix独自のデータローカリティの多くの長所を取り上げました。 今回は、vSANとNutanix ADSFの読み込みI/Oパスの比較について詳しく説明します。 vSAN読み取りI/O パス:書き込みI/Oパスの比較で学んだように、vSAN I/O パスの最良のシナリオは、VMが作成されたホストから移動していないか、偶然にもオブジェクトが存在するホストにVMが存在する場合です。その場合、ローカルのデータオブジェクトと、回復力のために別のホストにリモートなデータオブジェクトを持つことになり、IOパスは最適になります。 シナリオ1: vSANvSANの最適な読み取りI/Oパス ローカルにホストされたオブジェクトを利用ここでは、すべてのデータがローカルでホストされているため、100%の読み取りをローカルで提供できるように見えます。 しかし、vSANはこのような動作はしません。vSANの読み取りは、すべてのオブジェクトに対する「ラウンドロビン」方式で実行されます。つまり、オブジェクトがVMにローカルであるという最良のシナリオでも、FTT1の場合で読み取りの50%、FTT2の場合は読み取りの66%がリモートから提供されるのです。 シナリオ2: vSANシナリオ1でVMをノード2にvMotionしてみましょう。vSANの 最適な読

1-クリックの進化...

本記事はPrincipal Product ManagerのCameron Stockwellが2019年6月7日に投稿した記事の翻訳版です。 原文はこちら。 数週間前のアナハイムでの.NEXTカンファレンスのキーの戸で、Dheerajは大きくなった我々のポートフォリオとともに、アップグレード管理についての課題についてハイライトし、それでも我々は運用をシンプルに維持し続ける苦労について述べました。 「我々は5,6年前は2つのものをアップグレードしていればよかったのです - AOSとPrism - これは成長におけるパラドックスです -- 成長は複雑さを生み出します。そして複雑さは成長を殺していまいます。」 「アップグレードについて一般的には、30分程度しかかかっていなかったアップグレードが大規模なクラスタを持つお客様にとっては4〜5時間もの時間を要するようになってきている。 しかし、これは非常に大きな責任が伴う。すべてのサーバ、ファームウェア、ハイパーバイザー、全てについて考慮しながら、なおもダウンタイムを伴わずに実行しなくてはならない。」 「このカンファレンスは皆様が言う「最も複雑なことを素晴らしくやってのけるとはどういうことか?」ということに対するものになっています。もはや我々のキャンバスは5年前にそうであったようにシンプルなものでは、もはやなくなっているからです。 我々のキャンバスはより複雑なものになっており、そして、Nutanixに課せられたバーはこれまでと同じような素晴らしさを既存のお客様、そしてこうした複雑さを実際には見ることのない新しい我々のお客様に対してご提供するというものになっています。ですが、我々はそれに取り組み、5年前よりも10倍も高速に進まなければなりません。-- これがこのカンファレンスのあるべき姿です。」 ビデオを46:57から見始めていただくと1-クリックアップグレードの話が始まります。 1-クリックの画板へと戻る2016年の初頭には、我々がポートフォリオを拡充しながら同時にシンプルな1-クリックアップグレードの約束を守り続けるためには新たな方法が必要であるということは明らかでした。これまでの実績を持つデザイン ー アップグレードのためのコードとロジックをAOSに組み込んでおくというもの ーは継続できないということが徐々に

Nutanixの回復力 – パート 5 – CVMのメンテナンス中または障害時のRead I/O

2018年6月8日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 これまでのシリーズでは、ADSFがクラスタ全体にデータを分散することで、ノード障害から迅速に回復する方法について説明してきました(パート1)。また、耐障害性をRF2(Resiliency Factor 2)からRF3へ変換した場合や(パート2)、よりスペース効率の高いEC-X(Erasure Coding)構成へ変換する場合でも(パート4)、影響がないことを説明しました。 ここでは、AOSのアップグレードなどのNutanix Controller VM (CVM)のメンテナンス時や、CVMのクラッシュや誤ってまたは悪意を持って電源を切ってしまった場合などの障害時に、VMがどのような影響を受けるかという非常に重要なトピックを取り上げます。 早速ですが、Nutanix ADSFがどのようにデータを書き込み、保護するのか、その基本を説明します。 下図は、3ノードでクラスタで、1台の仮想マシンが稼働している構成です。仮想マシンはa,b,c,dのデータを書き込んでいます。通常、すべての書き込みは、1つのレプリカが仮想マシンを実行しているホスト(ここではノード1)に書き込まれ、もう1つのレプリカ(RF3の場合は1つまたは複数)がディスク配置の選択優先順位に基づいてクラスタ全体に分散配置されます。ディスク配置の選択優先順位(私は「インテリジェント・レプリカ・プレースメント(Intelligent replica placement)」と呼んでいます)は、データが最初から最適な場所に置かれることを保証します。  クラスタに1つ以上のノードが追加された場合、インテリジェント・レプリカ・プレースメントは、新たな書き込みが発生しなかった場合でも、クラスタがバランスのとれた状態になるまで、それらのノードに比例してより多くのレプリカを送信します。ADSFは低い優先度のバックグラウンド処理でディスクバランスを行います。 Nutanixがどのように複数のレプリカを使用してデータ保護を行っているか(「Resiliency Factor」と呼ばれる)の基本がわかったところで、Nutanix ADSFストレージ層のアップグレード時にどのようなことが起こるかを確認します。 アップグレードは、

Nutanix AOS 5.11登場!

本記事は2019年8月5日にProduct Marketing Lead HCI CoreのMayank Guptaが投稿した記事の翻訳版です。 原文はこちら。 Nutanix AOS 5.9は遡ること2018年10月にリリースされ、そのフォーカスは、より機能を増したソフトウェアベースの暗号化で既存のクラスタ内のデータをセキュアにすることや、ラックの障害に対応するためのアベイラビリティゾーンの機能向上、更にはDRのためのニアシンクへの機能向上でデータの保護や弾力性についてのものでした。 それ以降、我々Nutanixは絶え間なくNutanix HCIプラットフォームのコアを強化すべく活動を続け、AOSの5.10と5.11をリリースしました。AOS 5.10は2018年の12月にリリースされたもので、今回はAOS 5.11のリリースとそれがポータルからダウンロードできるようになったことをお知らせできることを大変喜ばしく思います。 この2つのリリースは共にコアであるAOSのストレージパフォーマンス、ストレージキャパシティ、データ保護、セキュリティ、そしてクラスタのライフサイクル管理機能を向上させるものです。今回の記事では主な機能のうちのいくつかを取り上げたいと思います。機能向上についての完全なリストについてはリリースノートをご参照ください。 パフォーマンスと拡張性ストレージQoSNutanix AOSのアーキテクチャにはすでにノイジーネイバー(やかましいお隣さん)から保護のためのQoSの機能が組み込まれています。AOS 5.11では、エンドユーザーによるストレージのサービス品質(QoS)のコントロールが可能となり、Nutanixのクラスタ管理者によるクラスタ内の選択した仮想マシンについてのIOPSの速度制限(スロットル)が可能となっています。 5.11のストレージQ0Sはミッションクリティカルなワークロードについての想定通りの一貫性というエンタープライズのITにとって重要な目的を達成できるようにしました。特定の仮想マシンについての速度を制限することで、さほど重要ではないワークロードからミッションクリティカルなアプリケーションがパフォーマンスについての影響を受けることを妨げることができます。ワークロードの統合を行っているサービスプロバイダもしくは大企業にとって、Q

異なるモデルでのクラスタサポート - Nutanix vs VMware vSAN

本記事は2020年2月26日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 このシリーズでは、重複排除と圧縮、およびイレージャーコーディングを使用する際に、Nutanixがより多くの使用可能な容量を提供するとともに、より大きな容量効率、柔軟性、回復力、およびパフォーマンスを提供することを学びました。また、Nutanixははるかに簡単で優れたストレージのスケーラビリティを提供し、ドライブの障害による影響を大幅に軽減していることも知りました。このパートでは、異なるモデルで構成するクラスタのサポートについて説明します。これは、HCIプラットフォームの拡張機能にとって非常に重要であり、絶えず変化するユーザーの要件を満たす/それ以上を提供するということを学んでいきます。ハードウェアのキャパシティ/パフォーマンスは非常に速いペースで進歩し続けており、ユーザーが一様な(同一スペックのノードによる)クラスタを使用することを余儀なくされた場合、TCOは上がり、投資の回収に多くの時間を必要とする可能性があります。これだけでも好ましくない事態ですが、それだけでなく、ユーザーが非効率的なサイロを作らなければ、新しいハードウェアの性能や集約のメリットを活かせなくなることを意味します。つまるところ、古いSAN時代のように、ハードウェアを「総入れ替え」する必要があるような状況にはなりたくありません。それでは、簡単な「チェックボックスの比較」から始めてみましょう。 サポートされているクラスタのノード構成 Nutanix VMware vSAN Heterogeneous(異なるモデルノード混在構成) Homogeneous(同一モデルノードのみの構成) 以前にも私が記事で強調したように "チェックボックス "スタイルの評価は、一般的に製品の機能についての誤った理解につながることを述べました。今回の記事は、この("チェックボックス "スタイルの)評価における問題のまさに典型的なモデルで、簡単な例を挙げてみます。 再びDellEMCが推奨するハードウェアプラットフォームであるVxRail E-Seriesの4ノー

Nutanix HCI上でRed Hat OpenShiftをはじめよう

本記事はNUTANIX.DEVにMark Ravi氏が2021年10月26日に投稿した記事の翻訳版です。原文はこちら。  このブログシリーズでは実稼働環境グレードのNutanix AHVクラスタ上でのRed Hat OpenShiftのKubernetesを検討そして提供しているIT、DevOps、そしてシステム管理者へ向けたガイダンスを提供したいと考えています。 クラウドネイティブなデジタルトランスフォーメーション アプリケーションの物理サーバーから仮想ワークロードへの移行がこの20年にわたって続いてきましたが、仮想マシンからコンテナへの移行は始まって10年にもなりません。コンテナとしてアプリケーションをモダナイズさせて稼働させるためには新たなツールが必要になり、オープンソースのKubernetes project が次々に非常に広範なコンテナ管理システムを生み出してきています。  Kubernetesはクラウドネイティブな機能、アーキテクチャ、そして運用を提供しますが、それには新たなスキルセットが必要になり、そして迅速なソフトウェアのアップデートとパフォーマンスの拡張性のメリットを享受しようと考える従来型の組織にとって破壊的な変化を迫ります。Linuxオペレーティングシステムと同様に、Kubernetesには多くのディストリビューションが存在し、Red HatのOpenShift はハイブリッドクラウドをまたがった一貫性をもつ基盤とともに、アプリケーションをビルド、展開、稼働させるための市場を牽引するプラットフォームを提供しています。Red Hat OpenShiftにはOTA(over-the-air)アップデート、コンテナランタイム、ネットワーク機能、イングレス(Ingress)、監視、ロギング、コンテナレジストリ、そして認証、認定ソリューションが含まれています。  Nutanixはシンプルさ、拡張性そしてハイブリッドクラウドインフラストラクチャを提供しつつ、ストレージ、コンピュートそしてネットワークリソースおよびサービスの1-クリックアップグレードをお望みのハードウェア、パブリッククラウドそしてサービスプロバイダー上の環境で提供します。Red Hat OpenShiftをNutanix上で稼働させることで、フルスタックの、エンタープライズ向けにサポートされ

次なるフロンティア – ROBOおよびVDI環境に向けたインビジブルなライセンス

本記事は2019年8月7日にGreg White氏、Kong Yang氏、Adrian Finch氏が投稿した記事の翻訳版です。 原文はこちら。 Nutanixは継続的にITがよりビジネスへと付加価値を提供できるようにするためのシンプル化に取り組んでいます。まず最初に我々が行ったことはインフラストラクチャをインビジブルにすること、そしてデータセンタ、現在はクラウドです。続いてライセンシングに取り組むべきというのは非常に論理的ではないでしょうか?うーん、ちょっと言いすぎかもしれませんが、それ以外の件と同様に我々はライセンシングからも複雑さを取り除きたいのです。 Nutanixは特定のユースケースについてキャパシティベース(CBL)とアプライアンスライセンシング以外の新しい選択肢となる利用モデルを導入し、様々なNutanixソフトウェアの利用をシンプルに計画、価格、購入を実現する方法をご提供します。2つの新しいユースケースは仮想デスクトップインフラストラクチャ(VDI)とリモートオフィス/ブランチオフィス(ROBO)環境です。 新しい利用モデルとはどのようなもの?この消費モデルは幾つかのNutanixソフトウェアソリューションを一緒に「ライセンシング」するモデルで、これによってハードウェアとソフトウェアの購入は分離されることになります。これによって、インフラストラクチャのニーズに基づいてどこに、どのようにNutanixソフトウェアを展開するかという点で、大きな柔軟性が実現されることになります。それぞれのモデルはAOS、AHV、Prism Starterを含んでいます。 VDIについてはこのライセンスモデルはVDI per userと呼ばれ、同時ユーザー数をベースとします。 ROBOについてはこのライセンスモデルはROBO per VMと呼ばれ、サイト内で利用される仮想マシン数をベースとします。 なぜ新たなモデルが必要なのか?こうしたソリューションの領域においては、過去から市場において「毎」のモデルが利用されてきました。同様のアプローチをご提供することで、HCI上でのインフラストラクチャのモダナイゼーションの計画をシンプル化することができます。加えて、展開の初期の小さな環境において、ハードウェアに紐付けられた価格は組織がまだ成長の余地を残しているにも関

Nutanix Files Enterprise Cloudのためのファイルの監査と分析

本記事は2019年3月21日にNutanixのTechnical Marketing EngineerのMike McGheeが投稿したものの翻訳版です。原文はこちら。 広がり続けるデータの宇宙エンタープライズアプリケーションからモノのインターネット(IoT)に至るまで、データを生成するコネクテッドデバイスの数の成長は圧倒的な速さです。Business Insiderによると2020年までに240億以上のインターネットに接続されたデバイスが地球上でインストールされると予測されています[1]。IDCのアナリストが2025年までに全世界で175ゼタバイトのデータが生成され、これが2016までに生成されたデータの10倍に及ぶ[2]ということについて、疑問の余地はありません。 この膨大なデータの殆どが非構造化データであると予測されています。多くの非構造化データはオブジェクトストレージベースのサービスに保管される一方で、大量のそして頻繁にアクセスされるデータはデータセンタ内のSMBとNFSプロトコルを利用するネットワーク接続ストレージ(NAS)に保管されることになります。 従来型のシステムは大規模に非構造化データを管理していくという点において制限を継承しており、今後到来するデータの爆発に対応することができません。そして、管理者が複雑な環境をレガシーなツールで管理することに奮闘している最中にも監査とコンプライアンスについての新しい要件がビジネスの脆弱性が罰則に繋がってしまうこともあります。 データの監査とコンプライアンスについての課題Nutanixはサイロ化されたNAS環境の複雑性を排除するためにNutanix Filesを開発しました。しかし、データを保存することはデータについての洞察、監査、コンプライアンスを含むNASのコアとなる機能の外側における課題を生み出します。 あらゆる産業はそのコンプライアンス目標という点で異なる課題に直面しています。GDPRに伴う個人情報、PCI-DSSに影響するクレジットカード決済、またはHIPPAで管理された健康情報など、あらゆる業界に適合しなければならない固有のスタンダードがあります。特定の一つの業種の中だけでもその要件が異なる場合があります。例えば、アメリカ合衆国ではそれぞれの州に異なる法律があり、それによっ

ストレージのアップグレード比較 - NutanixとVMware vSAN/VxRAILの比較

本記事は2020年3月11日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 このシリーズでは、重複排除と圧縮、およびイレイジャーコーディングを使用する際に、Nutanixがより多くの使用可能容量を提供し、容量効率性、柔軟性、回復力、およびパフォーマンスを向上させることを学んできました。 また、Nutanixははるかに簡単かつ優れたストレージのスケーラビリティを提供し、ドライブやノードの障害による影響を大幅に軽減していることもわかりました。 このパートでは、NutanixのAOS(Acropolis Operating System)とVMwareのvSAN(Virtual SAN)における、ストレージ層のアップグレードなど、Day 2 オペレーションで重要となるトピックを取り上げます。 双方のプラットフォームでどのようにアップグレードが実行され、これらのアップグレードが環境にどのような影響を与えるかを議論していきます。 まずは単純な「チェックボックスの比較」から始めてみましょう。 アップグレード Nutanix VMware vSAN 停止を伴わないストレージのアップグレード ✅ ✅ 以前の記事でも強調しましたが、「チェックボックス」スタイルのスライドは、製品の能力に関するミスリーディング引き起こしがちです。この問題は、アップグレードなどのDay 2 オペレーションについても大いに当てはまります。 簡単な例を挙げてみましょう。 例1:AOSやvSANの新バージョンへのアップグレードチェックボックスの比較を見ると、両製品とも"停止を伴わないストレージのアップグレード"ができることがわかります。この議論のために、以下のシンプルな定義を使用します。 「停止を伴わないストレージのアップグレード」とは、仮想マシンが停止することなく、ソフトウェア定義ストレージ層のアップグレードを実行できることです。 NutanixとvSANの双方において、仮想マシンが停止することなくアップグレードを実行できるのは事実ですが、仮想マシンとクラスタの可用性/パフォーマンスとデータの整合性にはどのような影響があるのでしょうか? Nutanix のクラウド時代のハイ

ServiceNowとNutanixの統合

本記事は2019年10月9日にPaul Harbが投稿した記事の翻訳版です。原文はこちら。 Nutanixはエンタープライズの企業がパブリックとプライベートクラウド間のシームレスなエクスペリエンスを提供する完全なハイブリッドクラウド環境を必要としていると認識しています。Nutanixはイノベーティブな100%ソフトウェア定義のハイパーコンバージドインフラストラクチャとマルチクラウドサービスで業界をリードしており、お客様は規模を伴う環境の展開や自身のIT運用環境との統合の必要性を感じています。Nutanixはその豊富なAPIとX-Playのような製品におけるイノベーションによってこうした統合を実現しています。こうした領域において、我々はServiceNowとのより深く密な連携と、シームレスなIT運用とエンドユーザーエクスペリエンスを提供することにおいての戦略的なパートナーシップをアナウンスできることを誇らしく思います。我々の技術チームはServiceNowのSaaSサービスとNutanixインフラストラクチャの統合を実現するにあたり、彼らと非常に密に連携し、以下の領域にフォーカスしてきました:ServiceNOW CMDBのNutanixハイパーコンバージドインフラストラクチャの検知とモデリングでの統合 ServiceNowのイベント、インシデントとNutanixのアラートの統合、及びX-Playによるその修復 ServiceNOWのリクエスト管理とNutanix上にホストされている場合のCalmプラグインによるその対応図 1: Nutanix と ServiceNOW の統合フロー なぜこれが重要なのか?組織のIT環境がより大規模に、そして幅広くなっていくにつれて、ITプロセスはより確固たるもので、リスクを最小化、管理できるようなものを望むようになります。全てのエンドユーザーがITサービスを利用するにあたってよりシンプルな、単一窓口での方法を模索するようになり、全てを自動化したいと望むようになります!多くのプラットフォームが混在する状況において、ServiceNOWはそれら全ての集合地点であり、IT組織は1つの組の手順で、あらゆるプラットフォーム向けの普段利用するすべての承認フローをここにまとめようとしています。会社の収益や、人々の生活、金融市場への影響があるような

メモリ利用量の比較 – Nutanix ADSF vs VMware vSAN / DellEMC VxRAIL

本記事は2020年4月1日にJosh Odgers氏が投稿した記事の翻訳版です。 原文はこちら。本シリーズの索引はこちら。  本シリーズのパート1、vSAN/VxRailとNutanixの利用可能な容量において、Nutanixがより多くの利用可能な容量とともに、重複排除と圧縮はもちろん、イレイジャーコーディングを利用した場合にもより優れた容量の効率、柔軟性、回復力、そしてパフォーマンスを提供することを学びました。また、DellEMCが「大規模なワークロード向けに最適化したハイパフォーマンスノード」と謳うDellEMC VxRAIL P-シリーズと同等のノードを利用したもう一つ別のvSAN/VxRAILとNutanixの利用可能な容量の比較についてもご披露いたしました。その結果は驚くべきものではなく、Nutanixでは18.38TB(〜16%)も多くの利用可能な容量を4ノードのソリューションで提供しており、それが8ノードに拡張された場合には77.925TB(〜31%)で圧勝してしまうというものでした。メモリの利用量についての話題は、比較的容易で(一方で、よく誤解や誤記を目にします)NutanixのCVMは静的な容量のメモリで構成された仮想マシンであるという比較になります。 標準では、Nutanix CVMは最小のノードでの24GBからノードでアグレッシブなリカバリ目標時点(RPO)を想定した場合で最大40GBの間となりますが、そうでない場合は32GBです。vSAN/VxRAILの場合、VMwareは「ESXi 6.0 U3,6.5.0d以降のvSANのメモリ消費を理解する」というタイトルのナレッジベースの記事を公開し、更新しています。この記事では様々な例をあげており、最初の例は小さな1つのディスクグループのハイブリッド構成であり、その環境ではvSANのために16.478GBが必要となっています。 例1: ホストあたり1つのディスクグループ、ハイブリッド構成::公式:HOST_FOOTPRINT + ( NumDiskGroups * ( DISKGROUP_FIXED_FOOTPRINT + DISKGROUP_SCALABLE_FOOTPRINT + ( CacheSize * CACHE_DISK_FOOTPRINT) + NumCapacityDisks * C

クラウドファーストはしばしば間違い、その理由は?

本記事はJohn Williamson氏が2019年6月14日に投稿した記事の翻訳版です。 原文はこちら。 いくつかの企業にとって「クラウドファースト」ポリシーは疑いようのないものとして捉えられており、特に従来型のデータセンタインフラストラクチャのぬかるみと比較した場合にそれは顕著です。しかし、今日ではハイパーコンバージドインフラストラクチャ(HCI)のような新たなソフトウェア・ディファインド・データセンタソリューションがITの俊敏性を提供しながら、一方でパブリッククラウドで利用可能なものよりもより優れたセキュリティと統制を提供しています。驚くかもしれませんが、多くの人々がパブリッククラウドを利用する主な動機はそのコストであるということを述べますが、そうした事実を他所に、殆どの場合では、Nutanix Enterprise CloudのようなオンプレミスのHCIソリューションのコストよりも劇的に高いのです。 IDCが公開した調査によると、エンタープライズのワークロードの殆どを占めている負荷の予測が可能なワークロードにおいては、パブリッククラウド上でこれを動作させるコストはオンプレミスのNutanixで動作させる場合と比較して平均して2倍ほどになるということです。そして、2018年のIDCのCloud Repatriation Accelerates in a Multicloud Worldと銘打たれた調査によると、80%もの組織がパブリッククラウドからオンプレミスへとアプリケーションを回帰させており、今日インストールされている50%のパブリッククラウドアプリケーションは今後2年間のうちにオンプレミスへ回帰する予定であるとしています。 Steve Kaplan氏は彼の最新の著作である、The ROI Story: A Guide for IT Leadersで、導入時の先行投資がパブリッククラウドで下がるったことを理由に全体コストについて誤解している企業があると説明しています。初期コストは全体の大きな方程式の中の一つの要素にしかなりません。そしてITの意思決定者はすべての要素を勘案し、IT投資の本当のコストを足し合わせた経済的な分析を行うべきです。 パブリッククラウドとNutanix HCIのTCOを比較する際、Kaplan氏は以下を考慮するように推奨してい

Nutanix Bucketsとコンテナ化されたアーキテクチャ

本記事はNutanixのTechnical Marketing ManagerのLaura Jordanaの記事の翻訳版です。2019年4月2日に投稿された原文はコチラ。 今後予定されているNutanix BucketsはNutanixの製品ポートフォリオにネイティブなオブジェクトストレージソリューションを登場させることになります。このオブジェクトストアは他のNutanixのコアサービスと同じPrismユーザーインターフェイスから展開、管理されるもので、S3-互換アプリケーションからアクセスすることができます。Nutanix Bucketsはオブジェクトストレージでは一般的なHTTPとHTTPSのS3 REST API(GET、PUT、POST、DELETE、そしてLIST操作を含む)と互換性があります。つまり、オブジェクトストレージへのアクセスにS3コールを利用するあらゆるアプリケーションがNutanix Bucketsを追加のアプリケーションやコードの変更なくそのまま利用することができるということです。 Nutanix BucketsはCVM内もしくは特別な仮想マシンとして実装されている他のいくつかのサービスとははじめから異なる設計が行われており、コンテナ化されたプラットフォーム上にサービスを展開します。このプラットフォームはKubernetesをベースとしており、Bucketsに関連するすべてのサービスはKubernetesクラスタ内のコンテナとして動作しています。これによりBucketsは展開、アップグレード、拡張性において根本から柔軟なものとなっています。例えば、ちょっとしたリリースに際して、Bucketsサービス全体をアップグレードするのではなく、対象となるマイクロサービス(コンテナとして動作しています)のみをアップグレードするだけでよく、結果としてより迅速、俊敏なアップグレードサイクルが実現します。 これは今日現在のアプリケーションが俊敏で、流動的であり、インフラストラクチャとは高度に切り離されているべきであるとの期待があるクラウドを中心とした世界では重要なことです。こうした形のクラウドネイティブなアーキテクチャは高いパフォーマンスと共に迅速にスケールアウトさせることができ、インフラストラクチャを最適なやり方で活用することができま

Badges

Show all badges