5 Essential Tips for Maximizing Your Experience at Nutanix .NEXT for Bloggers
本記事は2021年2月11日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 このシリーズでは、ではNutanix AOSが回復力ファクタ(RFつまり2つのデータコピー)を利用した場合に3ノードクラスタの場合も含め、メンテナンスモード、再起動、および障害シナリオにおいて完全な仮想マシンの可用性とデータの整合性を維持できるということを見てきました。 そして、パート2では、Nutanix AOSとvSAN 7 Update 1とを比較し、vSANが再起動と電源サイクル(障害)シナリオの両方で、以下のようなあらゆるvSANにとって有利に働く状況を作ったとしてもI/O整合性のエラーに苦しんでいるという事実を確認しました: vSANが長い(SCSI)I/Oタイムアウト設定を利用している (180 秒 vs Nutanix 30 秒) vSANがデータの完全退避モードを利用している vSANのオブジェクトリビルドタイマーを60分の遅延から遅延なしに変更 (すなわち、これによってリビルドは即時開始される) より大きなクラスタ(8ノード)を利用し、その上で、テストはそのクラスタ内の最初の4ノードのみで実施する パート7では、7ノードのクラスターでvSANの耐障害性(FTT)を2に設定した場合の動作について見ていきましたが、驚くことに、デュアルパリティのvSANを使用してもデータ整合性の問題に対処できないことがわかりました。 それでは、vSANをストレッチクラスター構成で使用する場合、仮想マシンの可用性とデータの整合性がどのように扱われるのかを確認していきます。 このテストは、8台のDell PowerEdge R740xd-24を使用し、VMware ESXi, 7.0.1, Build 17551050を用いて実施しました。 最初のテストでは、「4+4台構成のストレッチクラスタ｜FTT1｜I/Oタイムアウト180秒」を使用し、Active/Passiveスタイルのストレッチクラスタをシミュレートしました。ここでは、フォールトドメイン1では3つのVMを実行し、フォールトドメイン2ではVMを実行しませんでした。 簡単に言えば、このテストにおけるフォールト・ドメインとは、サイトやデータセンターを意味しますが、ノードはすべて同じ25Gbのネ
本記事はPrashant Batraが2019年10月9日に投稿した記事の翻訳版です。原文はこちら。 2018年の10月に私はNutanix Pulseについての記事を投稿しています。これは全てのNutanixのクラスタにビルトインされたオプションのテレメトリサービスで、皆様のNutanix Enterprise Cloudのための予兆分析を実現するためのものです。PlusテレメトリはNutanixのサポートがお客様により良いサービスを提供するため、お客様の特別な構成や利用状況を理解した上でのよりダイナミックで文脈を理解したサポートエクスペリエンスを提供しています。同様に、Nutanixの製品とエンジニアリングチームはこのテレメトリを活用し、お客様の利用や設定を理解し、お客さまのニーズにより合う既存のプロダクトの改善を行ったり、新たな製品を生み出しています。本日、我々はNutanix Insightsをアナウンスいたします - 皆様のNutanix Enterprise Cloudのための健全性の予兆検知とサポートの自動化サービスです。Nutanix Insights は新たなソフトウェア・アズ・ア・サービス(SaaS)サービスで、お客様がPulseを有効にしている場合、その受け取ったテレメトリを活用して、我々のお客様のサポートのエクスペリエンスを再定義し、クラスタの健全性を劇的に改善します。マニュアルのサポートプロセスを削減し、日々のメンテナンス作業に使う時間を短くすることで、ITチームはビジネスユニットに対する価値を高める活動にフォーカスすることができます。 我々はよくお客様からもっと深く自身のプライベートクラウドとハイブリッドクラウドインフラストラクチャを理解し、地域やサイトをまたがったインフラの管理をシンプルにしたいというリクエストをいただきます。典型的な質問は以下のとおりです：もうサポートされない(End-of-LifeもしくはEnd-of-Support)のソフトウェアを動作させていたりはしませんか? 我々のソフトウェアスタックは最新に維持されており、セキュアで全てのコンポーネントはそれぞれでハードウェアとソフトウェアのレイヤーで互換性が取れていますか? クラスタ内のノード、ライセンス、サポートサブスクリプションは最新でしょうか?もし次のために何かを今用
本記事はDerek Seaman's IT Blogの翻訳版です。2019年4月1日に投稿された原文はこちら。 できたてホヤホヤのNutanix Acropolis Operation System(AOS)であるAOS 5.10.3.1とPrism Central 5.10.3 が登場しました。AOSの5.10.xは長期サポート(LTS)ブランチであり、将来的には1-クリックダウンロードとインストールが有効になる予定です。 今回のリリースには以下が含まれています ： AHV-20170830.256 Prism Central 5.10.3 AOS 5.10.3.1 Witness VM 5.10.3 重要なことは本日のリリースにはAHVのAOS 5.10.3における予期しない問題およびHAイベントもしくはゲストの再起動を引き起こす可能性のある競合問題を発生させてしまうバグの修正が含まれているということです。もしもAOS 5.10.3を先週ダウンロードしてインストールしてしまっている場合にはすぐに5.10.3.1へアップグレードしてください。 関連リンク AOS 5.10.3.1 Download AOS 5.10.3.1 Release Notes AHV 20170830.256 Release Notes Prism Central 5.10.3 Download Prism Central 5.10.3 Release Notes Witness VM Downloads Nutanix Compatibility Matrix
本記事はNutanixのTechnical Marketing EngineerのMike Umpherysが2022年9月8日に投稿した記事の翻訳版です。原文はこちら。 一つ前の記事では、Nutanixがネイティブに提供するきめ細やかで効率性の高いスナップショットのテクノロジーと、Nutanixのスナップショットの実装の違い、それがなぜ差別化要素になるのか、ということについて取り上げました。今回の記事では、Nutanixプラットフォームにビルトインされたネイティブのエンタープライズグレードのレプリケーションとディザスタリカバリ(DR/災害復旧)オーケストレーションのメリットについて取り上げたいと思います。 レプリケーションはじめから、Nutanixはプラットフォーム内にきめ細やかなレベルでのレプリケーションを含めていました。我々はこれをエクステントベースのレプリケーション(EBR – Extent-based Replication)と呼んでおり、ストレージのエクステントの範囲で動作しています。エクステントの1つは1 MBの論理的な連続したデータのブロックです。しかし、64 KBの変更データのみを転送したいという場合にはどうなるでしょうか? AOS 6.5 Long Term Support(LTS)以前ではプラットフォームは変更データを含む1 MBのエクステント全体をリモートへとレプリケーションし、リモートシステムは必要ではない部分を切り捨てていました。例えば、100の異なるエクステントでそれぞれ 16 KBの変更データが有った場合、ターゲットクラスタに対して 100 MBのデータを転送する必要がありました。AOS 6.5 LTSには、完全に新しいレンジベースレプリケーション(RBR – Range Based Replication) が含まれており、Nutanixプラットフォームはこれ以降、新規、もしくは更新されたデータの範囲のみをレプリケーションすることが可能になりました。上の例でRBRを利用したとすると、100MBではなく、スナップショットは1.6MBになります。我々の検証によると最大9のスナップショットを利用して、4つの異なるデータの変更率を利用した場合、レプリケーションされるデータを最大で63%削減できるという結果になりました。さらに、すでにターゲ
本記事は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
本記事は2021年2月8日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 このシリーズではNutanix AOSが回復力ファクタ(RFつまり2つのデータコピー)を利用した場合に3ノードクラスタの場合も含め、メンテナンスモード、再起動、および障害シナリオにおいて完全な仮想マシンの可用性とデータの整合性を維持できるということを見てきました。 そして、パート2ではNutanix AOSとvSAN 7 Update 1とを比較し、vSANが再起動と電源サイクル(障害)シナリオの両方で、以下のようなあらゆるvSANにとって有利に働く状況を作ったとしてもI/O整合性のエラーに苦しんでいるという事実を確認しました:vSANが長い(SCSI)I/Oタイムアウト設定を利用している (180 秒 vs Nutanix 30 秒) vSANがデータの完全退避モードを利用している vSANのオブジェクトリビルドタイマーを60分の遅延から遅延なしに変更 (すなわち、これによってリビルドは即時開始される) より大きなクラスタ(8ノード)を利用し、その上で、テストはそのクラスタ内の最初の4ノードのみで実施する それではvSAN 7 Update 1が対障害性(FTT)を2に設定した場合の動作について見ていきます、つまりvSANはデータのコピーを3つ書き込んでいくことになり、理論的には回復力を向上して、2つの同時ドライブもしくはノード障害に対応ができることになります。 この一連のテストは回復力にフォーカスを当てており、FTT2(もしくはNutanix AOSではRF3)を利用するということは同時に実効で利用可能なキャパシティを50%からファイルシステム、キャッシュドライブ、そして回復用のキャパシティ(N-1/N-2)をマイナスしたものから33%から同じオーバーヘッドをマイナスしたものへと減少させるというコストを伴うということを理解しておくことが重要です。 FTT2(NutanixではRF3)を利用する場合には、同じ仮想マシンのフロントエンドのパフォーマンスに対してもより多くのシステムリソース(例:CPU/ストレージIO)を消費します。例えば、デュアルパリティへの移行によってサイジングには劇的な影響があり、大抵の場合33%以上になりますし、もちろんプラ
本記事はChris Rasmussen氏が2020年11月16日にnutanix.devに投稿した記事の翻訳版です。原文はこちら。 Nutanix上での自動化を考えた場合、これは仮想マシンやイメージだけにとどまりません。Nutanix Calmでアプリケーションライフサイクル管理を、KarbonでKubernetesクラスタを自動化することができます。これらについてはコンポーネントや製品について、多くの記事とコードのサンプルでカバーされています。 ほとんどすべてのアプリケーションの一部ではあるものの、未だにNutanix.devでカバーされていないコンポーネントがあります ― データベースです。読者の一部はNutanix Eraが「あらゆるクラウドのデータベース運用をシンプル化」するものであるということについてご存知でしょう。Eraがどのようなものかについて更に詳しくはNutanix.comの記載を参照していきましょう : パブリック、プライベート、そしてハイブリッドクラウドにおいて、Eraは単一コンソールからのシンプルで、高速、一貫した管理によって思い通りのデータベース管理を実現します。Eraによって劇的に稼働時間が改善され、退屈なマニュアル操作は低減され、コスト効率性が高まります。この次世代のクラウドとクラスタをまたいだ1-クリックのシンプルさが実現されます。これこそがEraが実現する新時代なのです。– https://www.nutanix.com/products/era しかしながら、もしもあなたがアプリケーションを設計する立場であるのなら、Nutanix Eraによって提供される優れたメリットをプログラマティックな形で享受したいと考えますよね? この記事はそんな皆様のためのものです。 私の環境私がこの記事を2週間ほど前に書き始めたときには、Nutanix Eraのヴァージョンは1.3でした。最も新しいNutanix Eraのヴァージョンは2020年11月16日時点で2.0.1(2021年12月8日の翻訳時の最新は2.3)です。私の開発環境内ではこのヴァージョン(2.0.1)が利用されています。これ以降のEraのヴァージョンではユーザーインターフェイスが変更されている場合があります。 もしもこれまでに環境内にNutanix Eraを展開したことがなく
本記事は2021年6月5日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 これまでの本シリーズの過程で、クラスタはRF2からRF3へと変換されている状態です。ここで、お客様は回復力に影響を与えることなく、容量効率の向上を図りたいと考えています。ここから我々はイレイジャーコーディング(EC-X)を有効化する際のプロセスとそのスピードについて見ていこうと思います。 これまでに議論してきたように、NutanixのEC-Xはバックグラウンドタスクとして動作し、そしてWrite Cold(上書きの頻度が小さい)データのみを対象として実行されます。つまり、構成されているRF処理が通常通り完了し、そしてさらにポストプロセスとしてEC-Xの処理が行われます。これは初回の書き込みI/Oにクラスタ内の数多くのノードの参加が必要になることで、書き込みのプロセスが遅くなってしまわないことを保証するためです。 Nutanix EC-Xの実装についての更に詳しい情報については私の「Nutanix – Erasure Coding (EC-X) Deep Dive」という記事をご参照ください。 「What I/O will Nutanix Erasure coding (EC-X) take effect on? (Nutanixのイレイジャーコーディング(EC-X)はどのようなI/Oに対して適用されますか?)」：良いご質問です、Write Coldデータのみです。ですから、EC-Xでの削減効果はデータが徐々にColdになってゆき、NutanixのADSFのCuratorスキャンが低優先度タスクとしてバックグラウンドで変換を行っていくに従って時とともに向上していきます。 ADSFのRF2/3からEC-Xストライプへの変換の速さは? ：極端な話をすれば、本シリーズの最初の部分で示したとおり、ハードウェアとして搭載されたドライブが可能な速さで行なえます、ですが、EC-Xは容量を削減するためのテクノロジーで、データをリスクに晒すものではないため、例えばノードやドライブの障害時の動作と同じ速さでやる意味はありません。 ですから、内部的な「ErasureCode:Encode(イレイジャーコード:エンコード)」タスクの優先順位は以下に示すとおり3で、それに
本記事はRaghav Tulshibagwale氏が 2021年3月10日に投稿した記事の翻訳版です。原文はこちら。 本日の記事では、また新たなゲストライターを紹介させていただきます。皆さん、Nutanixのスタッフエンジニア、Raghav Tulshibagwaleにご挨拶を！本日の記事では、継続的なシリーズの第1弾として、Raghavが私たちをNutanixにおけるRocksDBの旅へと案内してくれます。そしてRocksDBがNutanixプラットフォームアーキテクチャの様々な側面にどのように適用されているのかをご紹介します。私がRaghav自身よりもうまく説明することは到底できませんので、さっそく始めましょう！ はじめに2016年初めのアーキテクチャ検討会以来、Nutanixエンジニアチームは、分散ストレージファブリックの3つの大きな目標、すなわち、持続的でランダムな書き込み性能の向上、大容量ディープストレージノードのサポートの追加、バックグラウンドでのデータ管理の効率化に取り組んできました。これらの目標を明確にし、詳細を詰めていくうちに、私たちの限界要因はアーキテクチャ自体にあることに気づきました。さらに改善し、将来のスケーラビリティ(拡張性)のニーズに対応するには、Nutanixでのメタデータの保存方法を完全に再構築する必要がありました。メタデータをデータに近づけるという私たちの最大の目的には、メタデータを保存するための新しい基盤コンポーネントが必要でした。すでにうまく機能しているシステムに、まったく新しいコンポーネントを導入するのは、リスクの高い試みです。最終的にオープンソースのキーバリューストア（KVS）であるRocksDBを選択しましたが、これはあらゆる選択肢を調査し、それぞれの潜在的なコストと効果を考慮した結果です。オープンソースのソリューションが、十分な信頼性と耐久性を持ち、私たちのチームが数カ月で十分なノウハウを身につけ、そのコンポーネントを本当に自分たちのものにできるのかを確かめたかったのです。このブログシリーズの最初の記事では、専門用語、自律エクステントストア（AES）プロジェクトの全体要件、新しいコンポーネントの選択基準、エクステントストア用のRocksDB展開の概要、現在RocksDBを使用している他のNutanix製品およびコンポー
本記事は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上で稼働させることで、フルスタックの、エンタープライズ向けにサポートされ
本記事は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のTechnical Marketing Engineer – NCI & SecurityのEric Waltersが2022年10月13日に投稿した記事の翻訳版です。原文はこちら。 Nutanixのメリットシリーズを通して、Nutanixクラウドプラットフォームの多用途性、効率性、そしてレジリエンシーについてお伝えしてきました。このシリーズでは高いパフォーマンスとレジリエンシーを大規模環境においても実現するNutanixアーキテクチャのユニークな特性を取り上げてきました。エンタープライズグレードのレプリケーションと災害復旧(DR)と組み合わせ、Nutanixはお客様にハイパーバイザーの自由な選択肢とライセンスのポータビリティを提供できる優れたプラットフォームをご提供しています。加えて、Nutanixが単独のプラットフォームアプリケーションのニーズを満たす統合されたセルフサービスデータベース管理と完全に統合されたストレージをご提供することも確認してきました。これらのすべてのメリットは重要なものですが、昨今のようにエンタープライズにおいてセキュリティが最優先事項で語られるような状況においては、プラットフォームまたはデータがセキュアではない、ということになると、こうしたメリットは全て失われてしまいます。Nutanixはセキュリティを重要な要素として考え、レイヤー型アプローチでプラットフォーム、データ、そして最終的にはアプリケーションを網羅的に取り囲んで保護しています。 これから最もみなさまにとって重要なデータセキュリティについて掘り下げていきたいと思います。プラットフォームとアプリケーションのセキュリティの基本部分について取り上げていきますが、すべてを網羅するにはもう一つ別のシリーズが必要になってしまいます! プラットフォームセキュリティセキュリティは我々の Security development lifecycle (SecDL) プロセスを利用した開発のライフサイクルから始まります。 Nutanixはまた、セキュア構成管理および自動化(SCMA - Secure Configuration Management and Automation)でセキュリティベースラインを維持しており、自動的にセキュリティベースラインに合致しないあ
本記事は2020年3月23日にGary Little氏が投稿した記事の翻訳版です。原文はこちら。 ストレージ性能テストを担当されるは多くの場合vdbenchを使い慣れており、ハイパーコンバージドインフラストラクチャ（HCI）の性能をテストする際にもvdbenchを使いたいと考えているでしょう。HCIの性能を正しくにテストするには、HCIを構成するすべてのノードにワークロードを展開する必要があります。しかし、複数のVMをデプロイし、vdbenchの動作を調整するのは大変です。そこでNutanix X-Rayは、vdbenchを簡単にスケールアウトして実行する仕組みを提供しています。今回は、その使用手順を紹介します。X-Rayにvdbenchを追加する手順Oracleのサイトからvdbenchをダウンロードする X-Rayのvdbenchテストシナリオを GitHub https://github.com/garyjlittle/xray.git から取得する (リポジトリを自分のPCにクローンし、X-Rayのサーバーにアップロードできます) Oracleからダウンロードしたzipファイルの名前を”vdbench.zip” に変更する X-Rayシナリオ内で、zipファイルの名前が正確にこのとおり(vdbench.zip)であることが前提となっています。X-Rayサーバーに移動し、vdbench.zipファイルとX-RayのvdbenchテストシナリオファイルをX-Rayサーバーにアップロードする vdbenchを実行するためのJVMをインストール可能な状態にするため、Nutanixクラスタ上に作成されたVMがインターネットにアクセスできることを確認する それでは、X-Rayにデフォルトでビルトインされているテストと同じように、HCI アプライアンスに対してvdbench ワークロードを実行しましょう。結果は次のようになるはずです。 また、ビルトインされたGrafanaで表示することも可能です。 vdbench workload read IOPSvdbench workload write IOPS 基本的な動作が確認できたら、自由にvdbenchファイルを編集して、X-Rayに複数のLinux VMの展開、vdbenchワークロードをデプロイ、および実行をさせ
ITにとっての新しい当たり前 この3ヶ月は我々全員にとって試練の時でした。ソーシャルディスタンス、屋内退避、オンライン授業、在宅勤務などなど – これらがすべてを「新しい当たり前」にしてしまいました。 ITに目を向けると – 皆さまのようなITプロフェッショナルにとっての新しい当たり前とは何でしょうか? 我々のCIOである Wendy M. Pfeifferはそれを「なぶり殺し」と表現します。今日、ITはこれまで以上に必要とされています – そして恐ろしいことに24時間365日要求にさらされます。あらゆる会社においてITプロフェッショナルは舞台裏でビジネスを支え続けています。これについて語る人は多くはありませんが、我々Nutanixはそれを理解し、皆さまをパンデミックにおけるヒーローだと思っています! Xperience: 我々が見据える未来 Nutanixは我々の初めてのヴァーチャルイベント Xperience でITヒーロたちをたたえます。アメリカ地域では6月24日、それに続いてアジア・パフィックでは7月2日、日本では7月10日、ヨーロッパ・中東・インドでは7月16日に開催されます。是非、皆様ご参加いただき、ビジネス継続を再定義したITプロフェッショナル仲間と交流してください。イベントに参加されればNutanixがこの困難 – そしてその先で歩みをすすめる際に様々な面で皆さまの力になるということを確信していただけます。 イベントを少しだけ覗き見してみましょう。我々はSVP of Product and Solutions MarketingのMonica Kumarによるキーノートセッション「デジタルの未来へとつながる道」でキックオフします。CIO現職そして以前CIOを努めた2名 -- Nutanix CIOの Wendy M. PfeifferとNutanix Board Director、Investor、そして以前のWall Street CIOであるVirginia Gambaleを加え、Monicaは現状を乗り越え、ビジネスを将来に向けて継続して稼働させ続けるためにITが何をでき、何をすべきなのか議論を掘り下げます。CIOの観点からの洞察に満ちた「実践からの教訓」とそこから考える「その先」を是非聞いてみてください! 災
本記事は2021年6月5日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 パート1では、Nutanix AOSが分散ストレージファブリック（ADSF）により、ノード障害からレジリエンシーファクター2（RF2）の状態に高速かつ効率的にリビルドする機能について説明しましたが、パート2では、ストレージコンテナをRF2からRF3に変換して耐障害性をさらに向上させる方法と、そのプロセスがどれだけ高速に完了するかを紹介しました。（今回も）パート2と同様に、12ノードのクラスタを使用しており、ノードごとのディスク使用量の内訳は以下の通りです。 今回障害をシミュレートするノードのディスク使用量は5TBで、パート1のノード障害テストでの容量とほぼ同じです。なお、クラスタが12ノードになったことで、パート1と比べて（パート1では16ノードを利用）読み書きするコントローラが少なくなっています。次に、ノードのIPMインターフェイス（IPMI）にアクセスし、「Power Off – Immediate（即時の電源オフ）」の操作を実行してノード障害をシミュレートしました。以下は、ノード障害時のリビルドが約30分で完了し、5TBのデータの再保護が完了した際のストレージプールのスループットを示しています。 パッと見、5年以上前のハードウェアで5TBのデータの再保護が約30分で完了したことは、SANや他のHCI製品と比較しても非常に素晴らしいことですが、（Nutanixのリビルドは）もっと速くなるはずだと感じたので、少し調べてみました。その結果、ノード障害をシミュレートした時点でクラスタ（を構成する各ノード上のデータ量）のバランスが崩れており、（障害状態をシミュレートしたノードに比べて）他のノードにデータがほとんどないため、通常の状況のようにリビルドに貢献できなかったことがわかりました（リビルド時の読み取りの観点から）。クラスタがアンバランスな状態になっていたのは、（ここまでで）ノード障害のシミュレーションを頻繁に繰り返し行っており、ノード障害のシミュレーションを行う前に、クラスタにノードを追加した後にディスクバランシングが完了するのを待たなかったためです。通常、ベンダーは最適ではないパフォーマンス結果を掲載することはありませんが、私は透明性が重要
本記事は2018年6月20日にJosh Odgers氏が投稿した記事の日本語版です。原文はこちら。本シリーズの索引はこちら。 Nutanixには、いくつもの非常に重要でユニークな自己修復機能があります。これらによって従来からのSAN/NAS装置だけでなく、他のHCI製品とも差別化されています。 Nutanixは、SSD/HDD/NVMeデバイスの損失やノードの障害を完全に自動で自己修復するだけでなく、ユーザーの介入なしに管理スタック（PRISM）を完全に復旧させることができます。 まず最初に、デバイスやノードの障害からデータを自己修復する方法について説明します。 従来のデュアルコントローラーのSANと、平均的*なサイズの8ノードのNutanixクラスターを単純に比較してみましょう。 *平均値は、全世界の顧客数を販売台数で割って算出しています。 1台のストレージコントローラが故障した場合、SAN/NASでは回復力が失われます。ベンダーがコンポーネントを交換し、回復力(多くの場合は性能劣化も)を取り戻すまでは、SLA（サービスレベルアグリーメント）を守るために奔走しなければなりません。 Nutanixと比較すると、8台のストレージコントローラのうち1台（12.5％）だけがオフラインになり、7台がワークロードへのサービスを継続し、回復力を自動的に取り戻すことができます（パート1で示したように、通常は分単位で回復します）。以前、「ハードウェアサポート契約と24時間365日のオンサイトが不要な理由」というブログで、このコンセプトを詳しく紹介しました。簡単に言うと、プラットフォームの回復力を取り戻すために、新しい交換部品の到着や、さらに悪いことに人手に依存している場合、ハードウェアの交換やマニュアルでの作業なしに完全な回復力を持つ状態に自己回復できるプラットフォームに比べて、ダウンタイムやデータロスのリスクは飛躍的に高くなります。 「もっと小さな（Nutanixの）クラスターではどうか」と反論する人（あるいは競合他社）もいるかもしれません。よくぞ聞いてくださいました。4ノードのクラスターであっても、ノード障害が発生すると、ハードウェアの交換やマニュアルでの作業なしに、完全に自己回復して回復力のある3ノードのクラスターになります。 Nutanix環境で、別のノード障害が発生しても
本記事は2021年9月21日にNutanix HCI Teamが投稿した記事の翻訳版です。原文はこちら。.NEXT 2021に関する記事の索引はこちら。 HCIソフトウェアのパイオニアであるNutanix® AOSの大規模なマイルストーンと、Nutanix AOS 6ソフトウェアのリリースをアナウンスできることを大変喜ばしく思います。 VMworld 2011で市場を創生するHCIソリューションを立ち上げて(Best of VMworldアワードも受賞しています)から10年、Nutanix AOS™ インフラストラクチャソフトウェアは仮想化データセンターの業界標準のプラットフォームへと成熟し、今ではお客様をハイブリッドクラウドへとつながる橋渡しに貢献しています。 本日AOS 6は我々の差別化されたアーキテクチャのコア機能上に構成しながら、一方で破壊的な新機能群を追加しています。このリリースではパフォーマンスの最大化をより簡単に成し遂げられるようにするのみならず、クラスタの回復力についての可視化と統制を向上させて、ミッションクリティカルなワークロードに対するサポートを改善しています。それに加えて、AOS 6では大規模環境におけるセキュリティと保護を長く待ち望まれていたflow networkingと新しいDRダッシュボードも加え、改善しています。 パフォーマンスと拡張性Replication Factor 1 (RF1)Nutanix AOSはHCIクラスタ上で動作するアプリケーションのデータを複数のコピーを保持することで保護しています。AOSはクラスタ内の異なるノードに複数のコピーを保存しており、これによってハードウェア障害発生時に自動的にデータを復元することができます。これはレプリケーションファクタ(Replication Factor)として知られており、2 または 3のコピー(それぞれ RF2、RF3)を作成するように構成することが可能です。Hadoop®、SAS Analytics®、Splunk® そして NoSQL®データベースのような多くのモダンなビッグデータアプリケーションは、それを下支えするインフラストラクチャの力を借りることなく、自身のデータをアプリケーションレベルで保護しています。従来型のSQLデータベースもいくらかの非永続的な一次で、保護の必
本記事は2020年3月5日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 このシリーズでは、重複排除と圧縮、およびイレイジャーコーディングを使用する際に、Nutanixはより多くの使用可能な容量を提供し、より高い容量効率、柔軟性、回復力、およびパフォーマンスを提供することを学びました。 その後、ギアを切り替えて、異機種が混在したクラスタのサポートをカバーしました。これがHCIプラットフォームの拡張能力にいかに重要であるか、また、ツギハギやサイロを作らずに、強力なROIを実現できることを学びました。 次に、書き込み操作のためのI/Oパスを取り上げ、クラスタ内のVMの現在の位置とパフォーマンス/容量利用率に基づいてインテリジェントにデータを配置するNutanix独自のデータローカリティの多くの強みを解説しました。最適な書き込みレプリカの配置により、その後の読み込みI/O操作はNutanix ADSFでは主にローカルで提供されることが保証されます。これは（従来のSANのように）主にリモートで読み込みを提供するvSANとは対照的です。 また、Nutanixは、はるかに簡単で優れたストレージの拡張性を提供しているため、ドライブの故障による影響が大幅に軽減されることがわかりました。 今回は、回復力という重要なトピックをとりあげます。それぞれのプラットフォームがどのようにして様々な ノード障害シナリオに対処し、回復するかについて説明します。反論を避けるために、前回の記事でドライブの障害を取り上げたときと同様、DellEMCの圧倒的に人気の高いオールフラッシュのハードウェア構成であるVxRAIL Eシリーズを使用します。 注：使用されているコモディティなハードウェアは、この記事で提供されている例で、vSANやNutanix ADFS用のSWの動作という観点では、違いはもたらしません。しかし、フラッシュデバイスの量は、本記事で取り上げている、2つの製品間の違いについて、劇的な影響を与えます。 例1: ホストが応答しない/障害になった vSAN ホストが応答しない場合、VMware のドキュメントには以下のようにプロセスが記述されています:"ホストの障害または再起動によりホストが応答しなくなった場合、vSANは、クラスタ内の他の場所にある
本記事は2020年8月18日にGary Little氏が投稿した記事の翻訳版です。原文はこちら。執筆時点の情報となりますので現時点とUI、手順が異なる箇所があります。 AWS上でのNutanixクラスタの作成とX-Rayの実行(Youtube動画) 以下のリンクから、上記ビデオの各セクションにジャンプできます：Nutanix Cluster on AWSの作成と起動 Nutanix Cluster on AWSにPrismからの接続 X-rayディスクイメージのダウンロードと作成 AWSでサブネットとルーティングの作成（X-Ray VM、Worker VM用） Prismを使用してAWSで作成したサブネットをAHVへ接続する PrismからX-Ray VMを作成する AWSでロードバランサを作成し、X-Ray VMに外部からアクセスできるようにする X-Ray VMへのアクセスを許可するセキュリティグループの設定 Prism Virtual IPアドレスの設定 X-Ray VMへの接続 X-Ray VMからテストターゲットの設定 Four Corners Microbenchmarkシナリオを使用したパフォーマンステストを実行する X-Rayの実行と結果：IOPS X-Rayの実行と結果：Throughput Step By Stepmy.nutanix.comに移動し、Nutanix Clustersで[Launch]を選択します。 Create Clusterをクリックします Create Clusterダイアログで詳細を入力します。Create Clusterの2ページ目で、Prism Accessに "Public "を、Management Services Accessに "Restricted "を選択します。他にAWSに接続していない場合は、必ず管理サービスの現在のIPアドレスを追加してください。(今回のデモでは必要ありませんが、新しいsshキーを作成しダウンロードしました) "Create Cluster "ボタンをクリックします。Initialize cluster initiated "というポップアップが表示されるはずです。AWSがベアメタルクラスターをプロビジョニングします。これは通常20-30分かかります。 Statusが "C
本記事は2020年3月27日にGary Little氏が投稿した記事の翻訳版です。原文はこちら。 データベースの統合率をどのように測定しますか？より多くのDBを統合することによってデータベース性能はどのように変化しますか? CVMの実行は利用可能なホストリソースにどのような影響を与えますか? クラスタの性能は理論的上の最大値の90%を達成できました。 CVMのオーバーヘッドはこのワークロードの5%でした。 テスト環境設定評価の目的は、クラスタにデータベースワークロードを徐々に追加していくことでDBのパフォーマンスがどのように影響を受けるかを確認することでした。2つ目の目的として、データベースサーバーと同じホストで仮想ストレージコントローラーを動かすことによる負荷を測定します。Postgresデータベースでpgbenchワークロードを用いて1秒当たりの合計トランザクションを測ります。 クラスタ構成4ノードのNutanixクラスタにて、各ホストはソケットあたり20コアで構成された2つのXeon CPUを備えています データベース構成各データベースは下記スペックやソフトウェアで構成しますPostgres 9.3 Ubuntu Linux 4 vCPU 8GBのメモリ pgbenchベンチマークは、”Simple”のクエリセットを実行しますデータベースのサイズはメモリ内に収まるように調整します。IOではなくCPU/メモリのテストです。 テスト手順1台のホスト上の1つのデータベースよりテストを行います。合せて40データベースになるまでクラスター上にデータベースを追加します。40のデータベースではそれぞれ4つのvCPUとCPUバウンドのワークロードで構成され、クラスター上で160個のCPUコアをすべて利用します。データベースはホストのDRAMメモリに収まるように構成しており、ベンチマークはCPUバウンドであり、可能な限り高速に実行されます。 結果下記より4ノードクラスタ上で1-40台のデータベースを実行した際の測定結果をご覧ください。40台のデータベースでCPUコアが飽和状態になるまで、パフォーマンスは4から160 CPUまでほぼ直線的に上昇し、明らかなボトルネックはありません。 4ノードクラスタでデータベースを1台から40台まで拡張する 完全なスケーリング 対 実際のスケーリ
本記事は2020年2月19日にJosh Odgers氏によって投稿された記事の翻訳版です。原文は こちら。本シリーズの索引はこちら。 このシリーズの最初の記事では、同じハードウェア上におけるNutanix ADSFとVMware vSANの、実際の使用可能な容量を比較しました。 Nutanixが約30～40%多くの使用可能な容量を提供することがわかりました。 次に重複排除と圧縮の技術を比較したところ、NutanixはvSANよりも容量効率、柔軟性、回復力、パフォーマンスの面で優れていることがわかりました。 次にイレイジャーコーディングについて調査し、Nutanixの実装（EC-Xと呼ばれる）は、リアルタイムにパフォーマンスとキャパシティ効率性のバランスを保つ、ダイナミックかつフレキシブルなものであることを学びました。 次に、私たちは両方のソリューションでどのように容量を拡張できるか、という議論を行いました。vSANには多くの制約があり、拡張の魅力を失わせていることがわかりました。 しかしながら、NutanxのvSANに対するこれらの優位性は、前提としてプラットフォームが障害に対する高い回復力を持っていなければ意味がありません。 このパートでは、オールフラッシュの一般的なハードウェア構成において、両プラットフォームがどのようにして様々なドライブ障害シナリオを処理し、復旧を行うかについて説明します。 最近、あるDell EMC の従業員の方から、これまでのサンプルでは最も広く利用されているハードウェアを使用していない、というご指摘を受けましたので、今回はアーロン氏がイチオシの VxRail E シリーズを使用してみます。Eシリーズは、10本の2.5インチドライブをサポートしています。よくオススメされる、10本の1.92TBのドライブを搭載したオールフラッシュ構成にしましょう。(アーロン、どういたしまして！) VxRail Eシリーズでは、vSANは2つのディスクグループを作成する構成をとります。興味深いことに、1つのディスクグループは最大7つのキャパシティドライブしかサポートできないため、2つのディスクグループを作成せざるを得ないというのがその内実です。 Nutanixに馴染みのない方のために補足しておくと、Nutanixにはディスクグループのような概念や煩わしさはなく
本記事はHarshit Agarwal氏 と Gary Little氏がNutanix.Devに2022年4月20日に投稿した記事の翻訳版です。原文はこちら。 はじめにNutanix分散型ファイルシステム（NDFS）上では、仮想ディスク（vDisk）はクライアント（仮想マシンまたはコンテナ）がディスクの形態で利用できる、フラットな論理ストレージ空間です。このようなvDiskが各ノード上に複数存在し、I/Oを行うことで、クラスタの全リソースを効率的に利用できるようにシステムが設計されています。ですが、ユーザーのワークロードが、複数の仮想ディスク(vDisk)にまたがらない場合もあります。例えば、顧客がNutanixのハイパーコンバージド・プラットフォームに少数の巨大ボリュームを持つレガシー3層構成から移行したい場合、利用できるリソース（CPU、ディスク帯域、メモリ）があっても、ストレージサービスは最大のパフォーマンスを提供できない可能性があります。このようなユースケースは、リフト＆シフトのワークロードに限らず、以下のシナリオでも単一仮想ディスク(Single vDisk)のパフォーマンスが重要である考えてきました。アプリケーションが複数ディスクの使用をサポートしていない場合。 PoC時のベンチマーク・シナリオで、従来のシステムとNutanix HCIの仮想ディスクのパフォーマンスを比較する場合。 課題AOSのストレージは、Stargateと呼ばれる各々の仮想ディスク(vDisk)に対してコントローラーを保持するプロセスですべてのI/Oを管理しています。ワークロードでランダムにデータの読み取りを実行している間に、仮想ディスク(vDisk)コントローラは、CVM内の使用可能なCPUのキャパシティをすべて利用することはできず、単一のCPUへ制限されていました。仮想ディスクコントローラーは、設計段階でシングルスレッドとなっています。これによって、仮想ディスクコントローラーのコードをシンプルなまま、効率的に、vDiskをロック状態にすることなく、全てのデータ構造にアクセスできるからです。システム全体としての性能はvDiskの数によって拡張されますが、1台のvDiskの性能自体は単一のCPUコア/スレッドの性能によって制限されます。 ソリューションこの課題を克服するためには、単一
本記事は2020年4月1日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 vSAN/VxRAILとNutanixの使用可能な容量の比較のパート1では、Nutanixは重複排除と圧縮、およびイレイジャーコーディングを利用した場合に、容量の効率性、柔軟性、回復力、およびパフォーマンスの向上とともに、より多くの使用可能な容量を提供することを学びました。また、vSANの使用可能容量を改善する方法はありますかという問いに対して、（使用可能な容量の比較 – パート1の中で）4つの例を示しました（以下を参照）。 単一のディスクグループのみを使用することで、キャッシュによって「失われる」容量をSSD 1枚分だけをとどめます ディスクグループごとに、より多く本数のSSDを利用する/またはより大容量の SSD を使用します 圧縮/重複排除を使用します イレイジャーコーディング/RAID5または6を使用します この（Nutanix ADSF vs VMware vSANの）比較のためのハードウェア仕様は、4台のNVMeドライブと20台のSATA-SSDを搭載した4台のDell PowerEdge R740xdです。これは、各vSANディスクグループが前回の例（キャッシュドライブ1台、キャパシティドライブ2台）よりも多くのSSDを使用することを意味し、結果としてキャッシュドライブ1台、キャパシティドライブ5台となります。今回はより多くのSSDを搭載したノードや、ディスクグループごとに大容量のSSDを搭載したノードを使用して比較します。 この構成は、DellEMC社によって「データベースなどの重いワークロードに最適化された高性能ノード」と説明されているDellEMC VxRAIL P-Seriesの構成に相当し、24本の12G SASドライブスロット（2.5インチ）のディスク構成をサポートし、それぞれ最大5台のキャパシティドライブから構成される最大4つのディスクグループを持つことが可能です。 参考 : http://dellemcstorage.com/dell-emc-vxrail-p-series.html 以下は、vSphereクライアントに表示されるドライブを示しています。 4台のNVMe P4600 3.2TBドライブ（フォーマット済
本記事は2019年6月28日にGary Little氏が投稿した記事の翻訳版です。原文はこちら。 パブリッククラウドの良いところは、Bitnamiのような企業が作成した、あらかじめパッケージングされたアプリケーションの仮想アプライアンスを使用できることです。 Nutanix AHV上でも、これらと同じアプライアンスイメージを使って、簡単にPostgresデータベースのベンチマークを行うことができます。 ステップ1. bitnamiのイメージを入手するwget https://bitnami.com/redirect/to/587231/bitnami-postgresql-11.3-0-r56-linux-debian-9-x86_64.zip ステップ2. ファイルを解凍し、bitnamiのvmdk イメージを単一の qcow2[1] ファイルに変換します。qemu-img convert *vmdk bitnami.qcow2 ブラウザでアクセスできる場所にbitnami.qcow2イメージを置き、Prismサービスに接続し、"Image Configuration "を使ってアップロードします。 イメージのアップロードが完了したら、今度はそのイメージを元に新しいVMを作成します。 起動するとbitnamiのロゴが表示され、コンソールでbitnamiのパスワードの設定やsshの有効化などを行うことができます。bitnamiイメージでのsshの有効化/無効化bitnamiイメージでPostgresに接続する注意 - "sudo -c postgres <some-psql-tool>" と入力したときに求められるパスワードは、Postgres DB のパスワード（./bitnami-credentials に保存）であり、 OSのユーザーのパスワードではありません。 アプライアンスに接続したら、postgresとpgbenchを使って、単純なデータベースワークロードを生成することができます。 [1] これはどこかのLinux環境で実施してください。なぜか、brew経由でインストールしたqemuユーティリティでは、変換に失敗しました。OVAをAHVに直接インポートすることは、将来的に可能になるはずです。(※訳注：Prism Central 2020.
本記事は2020年2月5日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 最近の記事で、同じハードウェア上のNutanix ADSFとVMware vSANの実際の使用可能容量を比較しました。Nutanixの方が約30～40%も多くの使用可能なキャパシティを実現していることがわかりました。 次に重複排除と圧縮の技術を比較したところ、NutanixはvSANに比べて容量効率、柔軟性、回復力、パフォーマンスの面で圧倒的な優位性を持っていることがわかりました。 ここでは、もう一つ、利用に値する価値があり、なおかつ実績も備えた技術であるイレイジャーコーディングについて見ていきます。イレイジャーコーディングは、重複排除と圧縮にさらに加えて、容量の拡大とパフォーマンスの効率化を可能にします。 以前の記事で強調したように、「チェックボックス」スタイルのスライドは、容量、回復力、パフォーマンスなどの重要なアーキテクチャー/サイジング上の考慮事項について、誤解を招きがちです。 この問題はイレイジャーコーディングにも当てはまります。簡単な例を挙げてみましょう: 機能 Nutanix VMware vSAN イレイジャーコーディング / RAID5と6 ✅ ✅ 上記の表では、NutanixとVMware vSANでイレイジャーコーディング / RAID 5と6がサポートされていることを示しています。 この情報を見ると、顧客/パートナー/VARは、両製品のデータ削減機能は同等か、少なくとも購入やアーキテクチャの決定には重要ではないと結論づけてしまうのではないでしょうか？ もしそうだとしたら、様々なとんでもない理由で途方も無い勘違いをしたという事になるでしょう。 以下の表は、両製品で現在サポートされているデータ削減の構成を示しています。 機能 Nutanix VMware vSAN オールフラッシュ ハイブリッド オールフラッシュ ハイブリッド イレイジャーコーディング / RAID5と6 ✅
Already have an account? Login
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.
