Research Request: VM Start Ordering
Nutanixのハードウェアおよびソフトウェア製品に関するディスカッション。
本記事は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回(もしくはもっと)移動させることは不必要ですし、クラスタへのオーバーヘッドと処理時間の長期化の両方が発生させます。 ノード
