Nutanix Ansible Certified Collection for NCP Expands the Red Hat Ecosystem
Discussions from around the globe
本記事は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
Nutanix Community Edition(CE)に関する話題はこちらへどうぞ。
