日本語フォーラム (Japanese)

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に渡されます。 表：書き込みのバースト

本記事は2019年6月28日にGary Little氏が投稿した記事の翻訳版です。 原文はこちら。  今回の例では、pgbenchの実行は、データサイズの規模を表すスケールファクターを1000で実行しており、これは約15GBのデータベースサイズに相当します。（前回記事を参照）。ベンチマークを実行するLinux VMはRAMが32GBのため、データはメモリにキャッシュされます。そのため、ディスクへのReadがほとんど無いことが予想されます。  監視システムであるPrometheusでpgbenchを実施した結果のディスクIOパターンを見てみます(Linuxエクスポーター経由で性能情報を取得)。 IOパターンを確認すると、ログディスク(sda)への書き込みパターンは非常に一定で、データベースファイル(sdb)への書き込みパターンはバースト的であることが分かりました。 ※ログファイルとデータベースファイルは異なるディスク(sda/sdb)に配置しています。 pgbench - Linux buffer cacheサイズの50%のDBサイズでの結果 なお、今回のベンチマークではPostgreのcheckpoint_completion_target パラメータを 0.5 から 0.9 に調整しました。そうしないと、Postgreのチェックポイント時に SCSI スタックに負荷がかかり、ログ書き込みが遅くなるため、パラメータの調整を行いました。  pgbench(デフォルト設定) –チューニング前(デフォルト設定)、Logへの書き込みが急激に減少していることが分かります  

本記事は2019年6月28日にGary Little氏が投稿した記事の翻訳版です。原文はこちら。Image By Daniel Lundin この例では、Postgresとpgbenchワークロードジェネレータを用いて、仮想マシンに対して負荷をかけます。PostgresがインストールされたLinux仮想マシンを利用しますが、特にBitnami仮想アプライアンスを使います。VMが起動したらコンソールに接続します Postgres DBポートであるpostgresポート5432へアクセス許可するか sshを許可します $ sudo ufw allow 5432 postgresユーザーのパスワードを確認してください (cat ./bitnami_credentials) コンソールかSSHよりpsqlへログインします $ psql -U postgres オプションとしてパスワードを変更できます (プロンプト表示はpostgresデータベースユーザーのbitnami_credentialsからのパスワードです). $ psql -U postgrespostgres=# alter user postgres with password 'NEW_PASSWORD';postgresl=# \q pgbenchワークロードを実行するDBを作成します。この場合dbを“Scale Factor 10”でテストするためpgbench-sf10と名付けます。Scale Factorとはデータベースのサイズを定義する方法です。 $ sudo -u postgres createdb pgbench-sf10 ベンチマークを実行する準備ができているDBを初期化します。“createdb” ステップは空のスキーマを作成します。 -i は “initialize” を意味しています -s は “scale factor” を示し、例えば10など指定します pgbench-sf10 は利用するデータベーススキーマです。先程作ったpgbench-sf10を使います。  $ sudo -u postgres pgbench -i -s 10 pgbench-sf10 pgbench-sf10というDBスキーマに対してワークロードを実行します。 $ sudo -u postgres pgb

本記事は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.

本記事は2019年2月17日にGary Little氏が投稿した記事の翻訳版です。原文はこちら。 圧縮の有効性Nutanixクラスタ内で標準の圧縮を利用してデータベースを稼働させた場合にはどれほどの容量削減が期待できるでしょうか? TPCx-HCIベンチマークを稼働させた際には圧縮のみで、おおよそ2:1の削減を実現することができました。TPCx-HCIベンチマークはデータベース統合の構成をシミュレーションすることができます、つまり、ホストあたり多くのデータベースがあることになります。圧縮をしない場合のデータのサイズは45TBほどでした。 圧縮+暗号化加えて、データの保存時暗号化(Data at rest encryption - DARE)を有効にしました。クラスタの機能を利用して、圧縮と暗号化の両方を実現することができます。(まず圧縮を行い、その後暗号化)もしもデータベースエンジン自体が暗号化を行う場合、それによって圧縮の効果は小さくなります。  データの生成ZFSと同様に、Nutanixのファイルシステムは LZ4 圧縮を利用し、現実的なデータセットに対してインラインで2:1程度の容量削減の期待値です。TPCx-HCIベンチマークではE-Genデータ生成ツールを利用し、データベースを作成しました。E-GenはTPC-E ベンチマーク向けに作成されたツールで、機械が生成する文字列ではなく、国勢調査データとNYSEの株価リストなどの汎用的なリアルデータをもとにデータを生成します。 TPCx-HCI Data 

本記事はJose Gomez氏が2022年2月25日nutanix.devに投稿した記事の翻訳版です。原文はこちら。  このブログのシリーズの最初の記事である「Nutanix HCI上でRed Hat OpenShiftをはじめよう」では、デジタルトランスフォーメーションのためにクラウドネイティブを実装する中で、NutanixとRed Hatのアライアンスが組織をどのようにご支援するのかを見ていただくには良い内容となっています。  さて、Nutanix上でクラウドネイティブ(追加リソース)を動作させることについてはよく理解ができています、その次のステップへと歩みを進めましょう。Kubernetes ディストリビューションとしてRed Hat OpenShiftを利用して、Nutanix AHV上にKubernetesクラスタを動作させる方法についてです。 概要このブログを書いている時点で、サポートされているOpenShiftクラスタを展開する手法はplatform agnostic installer (プラットフォームに依存しないインストーラー)です。AHV上でのOpenShiftクラスタのインストールとライフサイクルを一元化するため、Nutanixコミュニティはこれらのタスクを自動化するための一連のNutanix Calm blueprint群を作成しました。Blueprintは こちらから入手可能です。 Calm blueprint毎に展開される仮想マシン このブログでは、Calm blueprintを使ったセルフサービスでAHV上へのOpenShiftクラスタを自動で展開する手順について見ていきます。以下の記事では読者がNutanix Calmを利用することができることを前提としています(追加リソース)。 Calm経由で展開されたOpenShiftクラスタはRed Hat社のサポート要件を完全に満たしています。これはOpenShiftに関する問題に出くわした際に重要です。 前提条件始める前に環境上に以下があることを確認してください:Nutanixクラスタ AHV 20201105.2175 または それ以降 最小AOSヴァージョン5.20.2 または 6.0.1 最低の利用可能リソース: 30 vCPU 106 GB メモリ 780 GB ディ

NutanixはPrismからESXiをアップグレード（またはパッチのアップデート）する機能を提供しており、サービス無停止でローリングアップグレードすることが可能です。この機能を利用するための代表的な要件として以下の2つがあります。vSphere DRSが有効 vSphere HAのアドミッションコントロールを無効化（アップグレード中のみ）これらの要件は、PrismからESXiアップグレードを実行した際に、プリチェックとして自動で検証されます。例えば、vCenterでDRSを無効化していたり、「一部自動化」の状態で有効化していたりする場合は、プリチェックの時点で以下のようにエラーとなりESXiアップグレードは実行されません。これは、自動ローリングアップグレードプロセスの中で、DRSが「完全自動化」でない場合、アップグレード中のESXiがメンテナンスモードに切り替わっても、仮想マシンが他のノードへ自動で退避できないためです。 また、HAのアドミッションコントロールが有効化されている場合も、プリチェックの時点で以下のようにエラーとなりESXiアップグレードは実行されません。これも、vSphere側の機能でリソース使用量に制約を適用するため、仮想マシンが移行できない場合が発生するためです。 これらは、DRSやHAを適切に設定すれば問題なく機能します。NutanixのドキュメントではPrismからのESXiアップグレードの要件として「DRSが有効になっていること」と明記されていますが、細かく言うと「完全自動化」で有効化されていることです。ESXiアップグレードの要件については以下ドキュメントをご参照ください。VMware ESXi Hypervisor Upgrade Recommendations and Limitations 

Nutanixは、LCM（Life Cycle Management）という機能を提供しており、Prism Web Consoleから操作できます。LCMを使用すると、クラスターのソフトウェアやファームウェアの各バージョン情報を取得して一覧表示したり、任意のコンポーネントをバージョンアップしたりすることが可能です。このLCMを使用して、各ソフトウェアやファームウェアをアップグレードする際に、場合によっては以下の状況に遭遇することがあります。このように [lcm] の [Updates] タブで、特定のソフトウェアやフォームウェアのアップグレードが無効化されて選択できない状態になることがあります。無効になったチェックボックスへカーソルを当てると、以下のように表示されます。This update is disabled since there is an emergency update available. Perform that emergency update prior to attempting this. Refer to KB 9111 more details.（利用可能な緊急のアップデートがあるためこのアップデートは無効化されています。このアップデートを試みる前に、緊急のアップデートを先に実行してください。詳細は KB9111 を参照） これは、Nutanixが緊急にアップグレードすることが必要と分類した特定のバージョンのソフトウェアやファームウェアがクラスターで実行されている場合に、表示されるようです。その特定のソフトウェアやファームウェアをアップグレードするまで、その他のアップグレードは利用できない仕組みになっています。ちなみに「KB 9111」を参照すると、緊急アップデートが必要と分類されているコンポーネントとその理由が確認できます。KB 9111: LCM update is disabled since there is an emergency update available上記の画像の環境では、実行しているAOSのバージョンが「5.15.5」であり、CVMの起動に失敗する不具合が確認されているために、AOSの緊急アップデートが必要と分類されていました。今回は例として、AOSを「5.15.5」→「5.15.6」へアップグレードし、再度L

本記事はHarshit Agarwal氏 と Samuel Gaver氏による2021年12月9日のnutanix.devへの投稿の翻訳版です。原文はこちら。  はじめにNutanixはハイパーコンバージドプラットフォームですが、その全てのサービス(ストレージサービスを含む)はコントローラーVM (CVM)と呼ばれる特殊な仮想マシン(VM)上で稼働しています。このCVMは現在カーネルバージョン3.10のCentOS Linuxディストリビューションで稼働しています。残念なことにこのカーネルのバージョンは結構古いもので、いくつかの課題を抱えており、このことが今回、Nutanixが新しいバージョンへとアップグレードをする動機となっています。 なぜアップグレードが必要か?バックポート作業の辛さを軽減する: バグやセキュリティ問題に出くわした場合、我々はより新しいバージョンのカーネルから、3.10.xへと変更をバックポートする必要がありました。これらのバックポートは大きく時間がかかるもので、開発者にとってはこうした変更が適用可能で、正しくポーティングされたのかを確認する必要のある大変な作業を必要とします。加えて、マニュアルでのバックポート作業はQAチームにもそれぞれの変更をテストして検証するという大きな負担となっていました。 新たな機能のメリットを享受する ： より新しいカーネルでは io_uringとBBR、我々のI/Oスタック内でのCPU効率と性能の改善が含まれており、より要件の高いワークロードを取り回す事ができるようになります。 LTSサポートへの追従 ： 3.10のサポートは2017年に終了しています。最近のLTSカーネルを利用することで我々はLinuxコミュニティのサポートを受けやすくなります、Linuxコミュニティでは必要なバグ修正がすべてバックポートされています。LTS系列へと合わせることで、マニュアルで修正を監視してそれらをバックポートするよりも、劇的な改善が見込まれます。  パフォーマンスの改善 ： AMD Zen上での優れたコンピュート性能と ext4における高速コミットの2つが、新たなカーネルを利用することで我々が同じハードウェア上でもより優れたパフォーマンスを達成することに貢献するカーネルの改善点です。 問題はなにか?作業を始めるにあたって我々は、最

 本記事は2021年12月14日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。 以前にNutanix AOSソリューションが提供するリビルドのパフォーマンスを含む拡張性、回復力、及び性能についての多くの優位性の詳細について述べてきました。これらはNutanix環境が障害発生後に自分自身で、完全な回復力を備えた状態にまでのリカバリを、可能な限り早く実行することを保証しています。 これはNutanix環境を支えるキャパシティとパフォーマンスに応じてデータをクラスタ全体で動的に分散させるAOSストレージファブリックによって可能になっています。 AOSストレージファブリックにはAOSがデータを1MB および 4MBのエクステントで保存するのとは反対に、未発達なHCI製品がデータの保存に巨大なオブジェクトを利用しているために潜在的に発生してしまう、個々のノードのキャパシティの問題に対して未然に対処する事ができる、という点以外にも多くの優位性があります。 AOS 6.1では、複数のノードを同時に取り外す事ができる新しい機能が搭載されますが、これを使うことによって同じAOSアーキテクチャ上で、合理的な時間内に効率的に複数のノードを取り外すことができるようになります。 ノードの取り外しは管理者が各々のノードの進捗状況を監視する必要なく行われ、1ノードが完了すると、それに続くノードの取り外しが前のノードと同様に行われます。 Nutanix Prism UI内でマルチノードの取り外しを実行するサンプル 一つずつ取り外すのと比べてどれぐらい効率的なのか?たとえば、8ノードのクラスタがあり、そこから２もしくはそれ以上のノードを取り外すときのことを考えてみましょう。 以前のAOSと、Nutanix以外のHCIプラットフォームではノード8からクラスタ内の他のノードへ移動されていました。 AOSはこれを、データを残されたすべてのノードに細やかなレベルでバランスしながら効率的に実施していましたが、それに続くノード７の取り外し時にはノード８に格納されていたデータのいくらかがノード7上に配置されており、再度データ移動の対象となってしまっていました。データを2回(もしくはもっと)移動させることは不必要ですし、クラスタへのオーバーヘッドと処理時間の長期化の両方が発生させます。 ノード

  本記事は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を展開したことがなく

本記事はJarian Gibson氏の記事の翻訳版です。原文はこちら。 今日の分散された職場環境を考えると、あらゆる場所から生産的に働ける、アプリケーション、デスクトップ、そしてデータにセキュアにリモートアクセスができる職場環境を迅速に用意できる能力は必要不可欠です。直近の数ヶ月、増加したリモートワークの要件によって、IT部門は分散された職場環境のニーズを迅速にサポートすることにフォーカスを余儀なくされました。IT部門が増加した分散された職場環境のニーズのために迅速にインフラストラクチャを展開できるようにするため、組織はAWS、Azure、GCPやその他のパブリッククラウドの採用を増加させています。IT部門は分散職場環境のニーズを満たすための ハイブリッド そして マルチクラウド ソリューションを探し求めています。Nutanix ClustersはNutanixのクラウドOSであるAOSをパブリッククラウドのサーバー上で稼働させ、同じ管理プレーンを利用して、パブリッククラウドにネイティブに統合されたシームレスなハイブリッドクラウド環境を実現します。 Nutanixはお客様の選択肢と Citrix Virtual Apps and Desktops が稼働するハイブリッドクラウド環境を実現します。Nutanix Clusters上のCitrix Virtual Apps and Desktopsによって、IT部門はCitrixワークロードのための迅速な分散された職場環境のサポートを実現することができます。この共同ソリューションによって、お客様は、これまでデータセンター内で提供していたのと同じ機能をクラウド内で実現することができます。 Nutanix Clusters上のCitrix Virtual Apps and Desktopsでは既存のNutanixのお客様は慣れ親しんだ同じ管理インターフェイスを提供します。Nutanix Clusters上のCitrix Virtual Apps and Desktopの管理はオンプレミスのNutanixインフラストラクチャ上での管理と見分けがつきません。実際のところ、オンプレミスのNutanixを管理するのに利用している同じPrism Centrarlインターフェイスを利用して、Nutanix Clustersを管理します。

本記事は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年11月22日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 このシリーズでは、Nutanixプラットフォームがいかに優れた回復力を有しているかを示す幅広いトピックを取り上げてきました。これには、障害時であっても新規書き込みのためのデータ整合性を維持できることや、障害後に問題を引き起こす次の障害のリスクを最小限にするために、タイムリーにリビルドする能力が含まれます。 このような情報があるにもかかわらず、競合ベンダーは、「2つのコピーが失われてしまえば、リビルド時間は問題の本質ではない」といった主張で、Nutanixが提供するデータインテグリティ（データ整合性・一貫性の担保の仕組み）の信用を貶めようとしています。現実的には、データの両方のコピーが同時に失われる可能性は低く、これは安易な主張です。しかし、もちろんNutanixは、最大限の回復力を求めるお客様のために、3つのデータのコピーを保存可能なRF3もサポートしています。 それでは、パート10に進みましょう。ここでは、ディスクスクラビングとチェックサムという2つの重要なトピックについて説明します。この2つの重要なトピックは、RF2とRF3の構成が非常に高い回復力を持ち、データが失われる可能性が極めて低いことを保証するものです。 まず、チェックサムについてですが、チェックサムとは何でしょうか？チェックサムは、書き込み操作中に作成された少量のデータであり、後で（チェックサムのデータを）読み込んで、実際のデータが完全なままであるかどうか（つまり、破損していないかどうか）を確認できます。次に、ディスクスクラビングですが、データの整合性を定期的にチェックするバックグラウンドタスクであり、エラーが検出された場合、ディスクスクラビングはエラー修正プロセスを開始して、修正可能な単独のエラーを修正します。 Nutanixは、すべての書き込み操作（RF2またはRF3）に対してチェックサムを実行し、すべての読み取り操作に対してチェックサムを検証します。これは、データの整合性検証がIO処理の一部であり、スキップしたりオフにしたりすることができないことを意味します。 データの整合性は、あらゆるストレージプラットフォームの最優先事項であり、これが故に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環境で、別のノード障害が発生しても

本記事は2018年6月19日に Josh Odgers 氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの牽引はこちら。 RF2についてはパート1で、RF3についてはパート3で説明したように、ADSFの回復力を議論する際の重要な要素は、ドライブやノードに障害が発生した場合に、設定されたレジリエンシーファクターに準拠した状態に回復する速度です。 それでは、第1回と第3回の内容を簡単に振り返ってから、RF3とイレイジャーコーディング(EC-X)を使用した場合のノード障害に対するADSFのパフォーマンスの例を見てみましょう。 リビルド処理は、設定されているレジリエンシーファクターやEC-Xなどのデータ削減にかかわらず、すべてのノードとドライブに完全に分散された処理（多対多の処理）であるため、非常に高速であると同時に、ノードごとの作業負荷が最小限に抑えられるため、ボトルネックを回避し、稼働中のワークロードへの影響を軽減することができます。 リビルドの性能は、クラスターの規模、ドライブの数や種類（NVMe、SATA-SSD、DAS-SATAなど）、さらにはCPUの世代やネットワークの接続性など、さまざまな要因に左右されることを忘れてはいけませんが、それを踏まえた上で、以下のハードウェアを使った例を紹介します。 テスト環境は15ノードのクラスターで、Ivy Bridge 2560プロセッサ（2013年第3四半期発売）を搭載したNX-6050およびNX-3050ノードなど、約5年前のハードウェアが混在しており、各ノードにはサイズの異なる6つのSATA-SSDと2つの10GbEネットワークインターフェースが搭載されています。 イレイジャーコーディングはRF2やRF3よりも多くの計算オーバーヘッドを必要とするため、より高速なプロセッサを使用することでリビルド速度に大きな差が出ます。レジリエンシーファクターは単にレプリカをコピーするだけです（つまり、パリティの計算は必要ありません）。 今回のテストでは、クラスターをRF3とイレイジャーコーディングで構成しました。 これまでのテストと同様に、IPMIインターフェースを使用し、以下のように「Power off server - immediate」オプションを使用してノード障害をシミュレートします。これは、物理的なサーバーの背面から電

本記事は2018年6月11日に Josh Odgers 氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの牽引はこちら。 パート1から4をまだ確認していない場合はぜひご確認ください。これらは重要なレジリエンシーファクターの障害からの回復速度に関するもので、その場でRF2からRF3へ、もしくは同じ回復力レベルを提供しながら容量を節約するイレイジャーコーディング(EC-X)へと変換することで、回復力を向上させることについて解説しています。 パート5と6では、CVM のメンテナンスまたは障害時に読み取りと書き込みI/Oがどのように機能するか解説し、このシリーズのパート 7 では、ハイパーバイザー (ESXi、Hyper-V、XenServer、AHV)  のアップグレードが読み取りと書き込み I/O にどのような影響を与えるかについて説明します。 この投稿ではパート5と6を頻繁に参照するので、このブログを完全に理解するには前の投稿をよく読んでください。 パート5とパート6で説明したように、CVM の状況に関係なく、読み取りおよび書き込み I/O は引き続き提供され、データは設定されたレジリエンシーファクターに準拠したままです。 ハイパーバイザーをアップグレードした場合、仮想マシンはまずノードから移行し、通常通りIO操作を続行します。ハイパーバイザーに障害が発生した場合、仮想マシンは HA によって再起動され、通常のIO操作を再開します。 ハイパーバイザー (またはノード) の障害またはハイパーバイザーのアップグレードのいずれの場合でも、最終的にはいずれのシナリオにおいても、仮想マシンを新しいノードで実行し、元のノード (下の図のノード 1) がオフラインになり、ローカルドライブ上のデータが一定の期間利用できなくなります。  このシナリオでは、読み取り I/O はどのように機能しますか? パート5での説明と同じ方法で読み取りはリモートで処理されます。または、2 番目のレプリカが仮想マシンが移行された (または HA によって再始動された) ノード上に存在する場合、読み取りはローカルで行われます。リモートでの読み取りが発生した際に、1MB のエクステントはローカライズされ、その後の読み取りはローカルで実行されるようになります。 書き込みI/Oはどうですか? パート6と同