Discussions from around the globe
Nutanix Community Edition(CE)に関する話題はこちらへどうぞ。
本記事はNutanix Technical Marketing Engineer のNimal Kunnath氏が2022年8月16日に投稿した記事の翻訳版です。原文はこちら。 NutanixとRed Hatは継続してお客様がハイブリッドマルチクラウド環境を進んでゆくためにお望みの認証取得済の、一元化されたソリューションを提供し続けています。プラットフォームに特化したRed Hat OpenShiftクラスタをNutanix上にインストールすることも可能ではあるものの、このやり方では管理者が必要な仮想マシン、オペレーティングシステムイメージ、ロードバランサー、DNSエントリーなどをすべて展開しなければなりません。Nutanix NCM Self-ServiceとRed Hat Ansible Automation Platformを活用してこれらのワークフローをエンドツーエンドで自動化することもできますが、お客様は2つのプラットフォームをネイティブに統合したソリューションを必要とされています。 Red Hat OpenShift 4.11のリリースに伴い、Installer Provisioned Infrastructure もしくはIPIとして知られるフルスタックの自動化されたインストールプロセスがNutanixクラウドプラットフォーム向けにも利用できるようになったことをアナウンスできることを喜ばしく思います。 IPI手法ではOpenShiftインストーラーはNutanix Prism APIと統合され、AHV仮想マシンの作成、ブートイメージのインストール、そしてクラスタ全体のブートストラップを行います。インストールの中に統合されているため、外部のロードバランサーを作成し、構成する必要はありません。それだけではなく、刻々と変わり続けるワークロードに対応するためのクラスタのスケールアップ・ダウンもユーザーの介入なく行われます。これはNutanixのアップストリームクラスタAPIプロジェクトとカスタムOpenShiftリソースをベースとして完全なMachine APIのサポートによって実現されています。 それではIPIインストール展開ワークフローの詳細にステップごとに分け入ってみましょう。 前提条件Red Hat OpenShift Container Pla
Nutanix Files™リリース3.8で導入されたSmart DRは、障害復旧のためにアクティブなファイルサーバーインスタンス間で共有レベルのレプリケーションを実現しました。Smart DRについてまだよく知らない方は、この機能の概要とその利点をこちらでご覧ください。Nutanixは、最初のリリース後すぐに、Files 3.8.1リリースで1分間のレプリケーション間隔をサポートするようになりました。今回のFilesリリース4.0では、スケーラビリティの向上とセルフサービスリストア（SSR）の統合により、Smart DRをさらに強化しました。 拡張性Smart DRでは、物理ノードのストレージ密度に関係なく、ファイルサーバー共有のレプリケーションが可能ですが、Smart DRでは、レプリケーションのサポートが最大25の共有までという制限がありました。Files 4.0では、この制限を拡大し、ファイルサーバー間で最大100の共有までレプリケーションできるようになりました。最大25共有に対して1分間のレプリケーション間隔まで対応し、残りの共有は、10分間隔までサポートします。 SSRの相互運用性Nutanix Filesは以前からSSRスナップショットをサポートしており、エンドユーザはファイルの以前のバージョンにアクセスできます。Files 4.0では、Smart DRがソース共有とそのターゲット間でスナップショットのレプリケーションを対応しています。 ターゲット共有は、ソースと比べて同じまたは異なる保持スケジュールを持つことができます。たとえば、ソース側でファイルサーバーが直近の2時間ごとのスナップショットを保持するように構成されている場合、ターゲット側のファイルサーバーは直近の10時間ごとのスナップショットを保持するように構成して、より長い保存期間を提供可能です。または、保持スケジュールを一致させることで、フェイルオーバー発生時に備えて両方のサイトに同じSSRコピーも利用できます。 エンドユーザー、ITサポートエンジニア、ファイルサーバー管理者は、Smart DR関係のソースまたは読み取り専用ターゲットからSSRコピーを使用してデータを復旧できます。 現在、Nutanix FilesとSmart DRを使っている場合、環境をアップグレードするだけで、これらの
本記事は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でフラッシュメディアに完全にレプリケーションされている
本記事は2020年10月05日にGary Little氏が投稿した記事の翻訳版です。原文はこちら。 今回紹介するのは、ベンチマークVMの再利用、さらに重要なデータセットの再利用により、X-Rayベンチマークの実装サイクルを高速化する方法です。 課題：大規模なデータセットを利用する場合、ディスク上でのデータ作成に時間がかかることがあるノードあたり2TBを書き込み、ノード間のバンド幅が10GbEであるクラスタを考えてみましょう。十分なストレージ帯域性能があると仮定すると、スループットはワイヤーバインドとなり、プリフィル（事前のデータ埋め）ステージは2,000秒（1GB/sec換算）、つまり30分以上かかることになります。モデル化されたワークロードが開始されるまでに30分も待つのは、なかなかのストレスです。ワークセットサイズが比較的小さいシナリオであったとしても、X-Rayのベンチマーク用VMのプロビジョニングとX-Rayワークロードの実行を分割することで効率化が図れます。また、VMを再利用すれば、クローン、ブート、IPの確立などのコストを避けることができます。これは、シナリオを繰り返し実装する際に非常に有効です。 解決策：複数のテスト/シナリオ間でVMを再利用典型的なアプローチは、シナリオを2つのパートに分けることです。パート1：X-Rayシナリオで、VMのクローンを作成、ブートして、ディスク、データ投入を行う「デプロイシナリオ」 この「デプロイシナリオ」（＝ベンチマーク用VMの準備）は一度だけ実行します。 パート 2：X-Rayメインワークロードを含む「X-Ray実測シナリオ」。パート1で配置されたVMを再利用します。 この2つの別々パートでデプロイ、実行されるVMを関連付けるために、Curie VM ID※の概念を使用します。 ※X-Ray（X線）にちなんで、キュリー夫妻に掛けて、X-RayでデプロイされるVM名のプリフィクスにcurieが利用されていることに由来している模様 重要な注意事項「デプロイシナリオ」から"teardown"（ベンチマーク後処理）ステップを削除する 「X-Ray実測シナリオ」から" CleanUp"ステップを削除する "teardown"や" CleanUp"のステップを含む「標準の」シナリオは、たとえ「id」を使用していてもVMをク
本記事は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年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ワークロードをデプロイ、および実行をさせ
本記事は2019年10月1日にGary Little氏が投稿した記事の翻訳版です。原文はこちら。 アプリケーションの統合度を測るためのX-Rayワークロード。Nutanix X-RayはIO/ストレージワークロードをモデル化することができるツールとして知られていますが、CPUを多用するワークロードについてはどうでしょうか?X-Rayは、X-Rayワーカー仮想マシン上でAnsibleスクリプトを走らせることができ、そうすることでほとんどすべてのアプリケーションを展開することが可能です。我々の目的はPostgresデータベースとそれにビルトインされたベンチマークツールであるPGBenchを利用することです。意図的に仮想マシンのメモリに収まり、IOをほとんど発生させないような非常に小さなデータベースを作成するスクリプトを作成しました。X-rayのワークロードファイルは こちら に保存してあります。 pgbench向けのX-Rayインターフェイス X-Rayで標準（のベンチマーク実行スクリプト）のYAMLを利用し、Postgresの仮想マシンをいくつ展開するのか、クライアント数はいくつなのか、pgbenchを走らせる際のスレッド数はいくつなのか、などのカスタムパラメーターを渡すことができます。 X-Rayがワークロードを実行すると、その結果がX-RayのUI上に表示されます。今回はIOPSやストレージのスループットではなく、メトリックはデータベースの毎秒のトランザクション数(TXN/S)になっています。 Pgbenchの毎秒のトランザクション数がX-rayのUIに表示される ワークロードを走らせる仮想マシン数を変更しながら、様々な試験を実行することで、毎秒のトランザクションの総計と仮想マシンあたりの値をプロットすることができました、この値はホストプラットフォームのCPUがサチってくると減少することが想定されます。 このようなCPU主体のワークロード特性を利用して、異なるハイパーバイザー間での特性、CPUタイプごとのスケジューリング特性やCPU使用率の特性を見ることができます。負荷が小さい場合には優れたパフォーマンスを示すパラメーターの組み合わせを見つけましたが、他の組み合わせでも負荷は高いものの、優れたパフォーマンスを示していました。 ホストのCPUのキャパシティを超える
Nutanix centralをインストールし、試しに、仮想サーバを「アクション」→「Quarantine VMs」→「厳格な」→「隔離」と設定したのですが、物理PCから当該仮想サーバにアクセスできてしまいます。（FTP、HTTP等）なお、物理PCと当該仮想サーバは同一セグメント（192.168.2.0/24）に存在します。flowは同一セグメントでも通信を制御（今回は遮断）できると思っていたのですが、この認識で会ってますでしょうか。また、同一セグメントにおいて通信制御はどのようにしたらいいのでしょうか。
本記事は2019年6月28日にGary Little氏が投稿した記事の翻訳版です。 原文はこちら。 前回のパート1とパート2の Postgres と pgbench の検証に続き、今回は、Postgres と pgbench の検証です。Nutanix CVMからワークロードがどのように見えるか、簡単に見ていきましょう。 Postgresを実行しているLinux VMには2つの仮想ディスクがあります：1つはトランザクションログの書き込みを行っています。 もう1つはメインデータファイルの読み込みと書き込みを行います。データベースのサイズは小さいので（Linux RAMの50%のサイズ）、データはほとんどゲスト内部にキャッシュされており、ほとんどの読み出しはストレージにヒット（ストレージへのI/Oアクセス）しません。その結果、主にDB ファイルへの書き込みのみが表示されます。 さらに、データベースのデータファイルへの書き込みはバースト的にストレージへ到着し、これらの書き込みバーストはログファイルへの書き込みよりも激しい（〜10倍）ことがわかります。 図：Prometheus/Grafanaによる、LinuxゲストVMの視点から見たIOレートのチャート データベースのフラッシュ（ディスクへの強制書き出し）がバースト的に発生し、それなりの（書き込みの）並立性があるにもかかわらず、Nutanix CVMは平均1.5ms*の書き込み応答時間を実現しています。*1ms以下の書き込みが49%、2msから5ms以下の書き込みが41% Nutanix CVMポート2009のハンドラから、個々のvdisk統計にアクセスすることができます。この場合、（以下の各図の見出しにある）vDisk 45269番はデータファイル用のディスクで、vDisk 40043番はデータベーストランザクションログ用のディスクにあたります。 表：バースト時の長いキュー長にもかかわらずデータファイルへの書き込みを平均1.5ミリ秒で完了 Nutanixのvdisk categorizerは、データベースデータファイルへの書き込みパターンをランダム性の高い書き込みと正しく識別しています。 表：データベースのデータファイルへの書き込みはほとんどランダム その結果、書き込みはoplogに渡されます。 表：書き込みのバースト
