Global Forums | Nutanix Community
Skip to main content
226 Topics

本記事は Nutanix の Technical Marketing Engineer – NC2, NUS, NDB の Mike McGheeが 2022 年 10月 6日に投稿した記事の翻訳版です。 原文は こちら 。 Nutanixをハイパーコンバージドインフラストラクチャ-(HCI)と同義と考える方もいることでしょう。これは我々が別途ストレージ装置とストレージエリアネットワーク(SAN)、サーバー、仮想化が必要な構造のレガシーなソリューションを(HCIへと)置き換えてきたからです。しかし、Nutanixが完全な統合ストレージソリューションをご提供していることをご存知でしたか? 我々のストレージ・ソリューションには同じ分散プラットフォームを利用するiSCSIベースのブロックサービス、SMBとNFSのファイル共有、そしてS3互換のオブジェクト機能が含まれています。Nutanixはシンプルさ、柔軟さ、そしてビルトインされたデータに対するセキュリティをご提供するソフトウェア・ディファインドのエンタープレイズグレードの統合ストレージをご提供できる唯一のHCIソリューションです。 Nutanixユニファイドストレージ(NUS)とは? Nutanixユニファイドストレージ(NUS) には以下の3つのコアサービスが含まれています: ファイルサービス Nutanixのファイルサービスは、アプリケーションとユーザーによって生成される拡大し続ける非構造化データの保存、管理、拡張に対するシンプルかつセキュアなスケールアウトソリューションを提供します。一般的なユースケースにはVDI向けのホームもしくはプロファイルディレクトリ、監視ビデオやメディカルイメージまでもが含まれます。ファイルサービスはSMB 2, SMB 3, NFS v3, NFS v4の堅牢なプロトコルのサポートおよびマルチプロトコルのサポートを含む、完全な機能セットを提供します。シェアに対してのユーザークオータの適応や、WORMポリシーの設定、クラウドへのデータの階層化、そして災害復旧(DR)のためのシェアのネイティブなレプリケーションが利用できます。 オブジェクトサービス オブジェクトサービスはセキュアなS3互換オブジェクトストアを提供します。オブジェクトサービスはモダンなクラウドネイティブおよびビッグデータ分析ワ

本記事は 2022 年 9 月 29 日に投稿された記事の翻訳版です。 原文は こちら 。 Nutanixのメリットのシリーズのはじめに、我々はNutanixクラウドプラットフォームが動的な分散ストレージ、自動化されたアプリケーションを意識したデータ管理、そしてきめ細やかな効率的なスナップショットなどのアーキテクチャ上の決断から、重要なアプリケーションやデータベースを稼働させるための優れたプラットフォームであるということを示してきました。Nutanixにはこれらに加えて、これらのビルディングブロックの能力を活用した、NutanixデータベースサービスもしくはNDBとして知られるセルフサービスのデータベース管理プラットフォームもご提供しています。NDBはデータベースの管理者が日々行うタスクを自動化したり、開発者がセルフサービスでのデータベースの展開を行うことを実現して支援し、データベースのライフサイクル管理に向けた自動化の中心として機能します。Nutanixストレージのパフォーマンスと効率性と共に、NDBは高性能なデータベースをあらゆる規模で提供することをもより簡単にすることができます。 高速でシンプルなデータベースの展開 NDBはデータベースの展開を事前に定義された環境に合わせたプロファイルを利用することでシンプル化します。ソフトウェアプロファイルはOSとデータベースエンジンのテンプレートで、一貫したソフトウェアのバージョンを維持するのに役立ちます。さらに、追加のプロファイルを利用して環境をカスタマイズすることもできます。コンピュートプロファイルではメモリやCPUがデータベースの要件を満たすように柔軟な選択肢を提供します。ネットワークプロファイルはこうしたデータベースを開発、検証、本番であろうと適切なネットワーク上に配置することができます。データベースパラメータープロファイルはそれぞれのデータベースエンジンをデータベースのサイズやメモリ要件に応じてカスタマイズします。これらを利用してWindows上のMSSQLで利用されるメモリの上限を決めたり、PostgreSQLのワーカープロセスの最大数を制限したりすることができます。もしもWindows上にMSSQLを展開する場合にはドメインプロファイルを利用して、ドメインとカスタムのOUに必要に応じて参加させることもできます

本記事は Nutanix の SVP Product and Solutions Marketingの Lee Caswell氏 が 2022 年 9 月 22日に投稿した記事の翻訳版です。 原文は こちら 。 ベイエリアに雨が降ると、それはスキーシーズンがさほど遠くないということの現れです。この何年かはダウンヒルの愛好家は場所が定められた一つのリゾートのパスだけに制限を受け、多くの人がフラストレーションを感じ、また前もっての計画と確定を余儀なくされていたのでした。 スキーヤーは今日、全米、もしくは世界中のスロープを滑走できる新たなマルチリゾートのセレクションパスを選ぶことができるようになりました。この記事はNutanixがマルチリゾートパスと同様に展開しているポータビリティがどのようなものなのか、そして、それがITマネージャーの、時とともに変わり続けるアプリケーションのニーズを満たすために、様々な場所、そしてハイブリッドにクラウドインフラストラクチャーを構築する手助けしてくれるのかについてのものです。 ポータビリティの価値 パフォーマンス、コスト、そして支配権についての心配が、ITマネージャーにどこにアプリケーションを配置するのかという課題を幾度となく投げかけます。しかし、これは簡単になしうることではありません。特にクラウドのリソースの追加とエッジで予測されている成長を鑑みるとなおさらです。 実際、Gartner®は2027年までに2022年に配置された85%のワークロードの場所が要件の変化によって最適ではなくなる¹ 予測しています。クラウド、マルチクラウド、そして成長を続けるエッジでは拡張が起きています。時の流れの中でどこにアプリケーションとインフラストラクチャーを提供するのかという柔軟性の価値はその場所の選択肢が拡張されるにつれて大きくなっていきます。アプリケーションのモビリティ提供するためには、柔軟性を持ったインフラストラクチャーが必要不可欠なのです。 幸運なことに、モダンなハイブリッドクラウドはサーバーインフラストラクチャー上で標準化されており、Nutanixはサーバーベースのハイブリッドクラウドをまたがった完全なソフトウェアスタックのポータビリティを実現しています。オンプレミス環境をお持ちのお客様はそのリソースをパブリッククラウドへまたはエッジへと要件の

本記事は Nutanix の Technical Marketing Engineer の Brian Suhr が 2022 年 9 月 15 日に投稿した記事の翻訳版です。 原文は こちら 。 Nutanixはお客様に選択の自由を提供することでその評価を獲得してきました。これについては多くの例がありますが、今回の記事では、Nutanixクラウドプラットフォームのアーキテクチャがコンピュートハイパーバイザーとは独立して稼働する分散型AOSストレージスタックによってどのようにお客様にハイパーバイザーの選択肢というオプションを提供するのか、掘り下げたいと思います。 ご存知のとおり、ワークロードの稼働にどのハイパーバイザーを使うのか、選ぶのは朝起きで、どのシャツを着るのか選ぶのとはまるで違います。どんなときにも着ていけるシャツ(そしてハイパーバイザーも)はありません。ワークロードとアプリケーションはそれぞれに固有の要件を抱えており、それらのワークロードを混在させることもあるため、要件に競合や重複も出てきます。VMware ESXi、Hyper-V、Nutanix自身のAHVをNutanix HCIで柔軟に稼働させる事ができることは、こうした環境において大変重要です。 分散ストレージスタックと仮想化コンピュートレイヤーが異なるイノベーションによって推進されているということもまた事実です。例えば、多くのvSphere 6.7を利用しているお客様にとって、コンピュート仮想化レイヤーは十分に成熟したもので、新しい、よりコストの高いバージョンへのアップグレードは強い動機を感じるものではありません。こうしたお客様においては、ハイパーバイザーのアップグレードを行わずにアップグレードができるNutanixのストレージスタックのアップグレードの機能は選択肢と統制のもう一つの事例になります。 今回の記事では、単独のハイパーバイザーを動作させることと、複数のハイパーバイザーを動作させることについて掘り下げ、ハイパーバイザーの選択肢と共に、どのような以降の選択肢があるのかと、それらの価値を示す例をいくつか取り上げたいと思います。 マルチハイパーバイザーのサポート Nutanixのコントロールプレーンは利用しているハイパーバイザーに関わらず、一貫性を保っています。これはつまり、クラスタ、レプリケ

本記事は 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%削減できるという結果に

本記事はNutanixのTechnical Marketing EngineerのMike Umpherysが2022年9月1日に投稿した記事の翻訳版です。 原文はこちら。 これまでの記事でNutanixの分散アーキテクチャがどのようにビジネスクリティカルアプリケーションとデータベースに最適なのかをご紹介してきました。このアーキテクチャはその上に構成される他のすべての機能の基盤となっています。この記事では、クローンの作成時間をスピードアップし、あっという間の復元を実現するきめ細やかで効率的なNutanixのスナップショットに焦点を当てることにします。まず最初に何がスナップショットで何がスナップショットでないのかを定義しておきましょう。スナップショットは任意の時間のシステムの状態を参照する事ができるものです。しかしながら、システム内でバックアップを取る際にスナップショットを使うことはできますが、スナップショット自体はバックアップではありません。 きめ細やかで効率的なスナップショットはNutanixのデータ保護機構の基盤です。 Nutanixは大規模なLUNやコンテナのレベルではなく、仮想マシンの目線でのスナップショットを単一のvdiskの単位で提供しています。Nutanixのスナップショットの先進性を理解するためには、まずは現在利用されている様々なタイプのスナップショットを理解する必要があります。 現在エンタープライズのIT分野で広く利用されているスナップショットにはcopy-on-write(CoW)とredirect-on-write(RoW)の2つのタイプがあります。しかしながら、これらの2つのスナップショットの実装は同じではありません。それぞれの実装にはメリットとデメリットが存在します。Nutanixはいくつかの重要な理由からRoWのスナップショットを選択しました。 1つ目は、多くの数のReadとWriteをリダイレクトについてです。RoWでは保護されているブロックへの更新を新たな場所へとリダイレクトし、その後メタデータ内のポインターをその場所を参照するように更新します。これは結果として1回のWrite操作です。RoWのスナップショットからの復元を行う際にはシステムはどこにデータが保存されているのかを探し出し、それを直接読み出すだけです。 CoWは保護されたブ

本記事は Nutanix の Senior Technical Marketing Engineer の Bhavik Desai が 2022 年 8 月 18日に投稿した記事の翻訳版です。 原文は こちら 。 このシリーズのこれまでの2つの記事では、Nutanix AOSが自動化されたアプリケーションを意識したデータ管理を実現する、動的な分散されたストレージをどのように提供しているのか、ということについて掘り下げてきました。今回の記事では、これらの2つの機能が、管理者がクラスタに更に物理ノードを追加して拡張をしなければならない場合に、どのように強力なメリットをもたらすのかについて見ていきましょう。 パフォーマンスとキャパシティのためのクラスタ管理 展開が終われば、インフラストラクチャーとアプリケーションの日々の運用が重要になります。Nutanix AOSは管理者の行うライフサイクル管理を簡単かつシームレスなものにします。すべての管理者が行わなければならない重要なタスクの一つにストレージもしくはパフォーマンスのためのインフラストラクチャーの拡張があります。 管理者は通常、最初は均一なクラスタを展開することから始めることになりますが、アプリケーションが成長するにつれて、よく発生するユースケースがクラスタへのさらなるキャパシティの追加です。管理者は多くのストレージキャパシティを持つノードや、アプリケーション仮想マシンを動作させないストレージオンリーノードを含む様々なタイプのノードを追加するという選択肢があります。AOSはこの部分をその動的なクラウドアーキテクチャーで劇的にシンプルにすることができます。一度ノードが追加されると、アプリケーションは他のHCIシステムのように何らかの介入を必要とすることなく、即座にその追加されたリソースを活用することができます。これはAOSが書き込みを行うデータが最適なサイズであることと、動的に自律化されたWriteを行うことで可能となっています。AOSは自動的に新たなリソースを利用し始め、マニュアルでの介入を行うことなく、書き込みのコピーデータは新しいノードへと送信されます。それに加えて、AOS内のCuratorフレームワークがディスクのリバランスをバックグラウンドオペレーションとして開始させ、自動的にクラスタのバランスを調整します。以下

本記事は Nutanix の Senior Technical Marketing Engineer の Bhavik Desai が 2022 年 8 月 10 日に投稿した記事の翻訳版です。 原文は こちら 。 このブログシリーズはAOSのユニークな分散型ストレージアーキテクチャについて説明し、Nutanixのエンジニアがレジリエンシーと低遅延のパフォーマンスのために、スケールアウトクラスタ全体に動的に分散されるデータに対してどのように難しいアプローチを取ったのかということを取り上げていきます。 さて、今回は2つ目の記事です。AOSが仮想マシンのvDiskデータをどのようにして、extent groupと呼ばれる4MBのちょうどよいサイズのチャンクに分割しているのかについて、掘り下げていきたいと思います。 このアプローチは保存の効率が悪く、保護を行うためにネットワーク帯域を多く消費し、リビルドに時間のかかる静的な巨大なブロックを用いるアプローチに比べ遥かに洗練されたアプローチです。AOS内のextentは分散されたメタデータストアによって実現されています。分散メタデータストアはクラウドアーキテクトにとっては最適な状態においても障害発生時においても一貫性を保ち、効率的に分散されたデータを取り扱う方法として知られています。特に障害発生時の動きはストレージアーキテクトにとって興味を引く内容でしょう。 分散された拡張性のあるメタデータ 先の記事でご紹介したとおり、 AOS のインテリジェンスはコントローラー仮想マシン (CVM) に格納されたサービスとしてクラスタ全体に分割され広がっています。 AOS 内のメタデータはグローバルとローカルのメタデータストアに分類できます。グローバルメタデータストアは論理的な、どのノードがデータを保持しているかと言うようなメタデータで、一方ローカルメタデータは物理的に実際にどのディスクのどの領域にデータが保存されているかというようなメタデータです。これによって柔軟かつ最適にメタデータを更新することができます。 図1: グローバルとローカルのメタデータ グローバルメタデータストアはかなり大規模に手を入れたApache Cassandraをベースとした分散ストアで、Paxosアルゴリズムを使って厳格に一貫性を担保しています。メタデータはリング

本記事はNutanixのSenior Technical Marketing EngineerのBhavik Desaiが2022年8月3日に投稿した記事の翻訳版です。 原文はこちら。 我々はNutanix Cloud Platform(NCP)がAOS 6.5 LTSにて、ビジネスクリティカルアプリケーションとデータベースの要件を満たせるようになっているということを示すインフォクラッフィックスをリリースしました。このブログシリーズでは、それぞれの主張の技術的な背景を述べていき、皆様の重要なアプリケーションにとってNutanixのアーキテクチャがどのようなメリットをもたらすのかを解説していきます。 この最初の記事では、動的に分散されたストレージと、それが高性能なアプリケーション、レジリエンシー、そして拡張性にどのような意味を持つのかにフォーカスを当てます。 動的に分散されたストレージ Nutanixにおいて最も重要で、そして解決すべきアーキテクチャ上の決断はNutanixのストレージオペレーティングシステムであるAOSのデータパスをリアルタイムに完全に分散させるというものです。広く利用されているRAIDを用いた、ディスクのサブシスシステムをスケールアップさせるという場合には典型的な静的にデータを配置するというアプローチは比較的簡単なやり方ですが、一方で完全な分散モデルではスケールアウトモデルとしては当たり前のネットワーク、コンポーネント、そしてノード障害状況を考慮する必要があります。 完全な分散モデルだけが、本当に必要なパフォーマンスを提供することが出来ます、つまり、一貫性した低遅延のパフォーマンスと、 障害児の高速な並行リビルドです。このアーキテクチャー上のデザインはGoogleやAmazonのようなソフトウェア・ディファインドのスケールアウトハイパースケーラーが切り開いた分散システムを作り上げたNutanixを創業したエンジニアが念頭に置いていたものです。 AOSはそれぞれのノード上で分散されたサービスを動作させるコントローラー仮想マシン(CVM)のコンセプトを導入しています。AOSのリアルタイムインテリジェンスはスケールアウトクラスタ全体に分離し、広がっており、このためこれらのサービスを構成する要素には何一つ単一障害点はなく、どのノードのどのサービスも必要にな

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

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 コピーを使用してデータを復旧で

本記事は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でフラッシュメディアに完全にレプリケーションされている 1MB シーケンシャル Read スループット 26.35 GByte/s ホストあたり 6.5 Gbyte/s です、データローカリティのおかげです! 8KB Write 単独 IO レ

本記事は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"ステップを削除する "teardo

本記事は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 Step my.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 がベアメタルクラスターをプロビジョニング

本記事は 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までほぼ直線的に上昇し、明らかなボトルネッ

本記事は 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 IOPS vdbench workload write IOPS 基本的な動作が確認できたら、自由にvdbenchファイルを編集して、X-Rayに複数のLinux VMの展開、vdbe

本記事は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使用率の特性を見ることができます。負荷が小さい場合には優れたパフォーマンスを示すパラメーターの組み合わせを見つけましたが、他の組み合わせでも負荷は高いものの、優れたパフォーマンスを示していました。 ホストのCP

本記事は 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 は、データベースデータファイルへの書き込みパターンをランダム性の高い書き込みと正しく識別しています。 表:データベースの

本記事は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 postgres postgres=# 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スキーマに対してワークロードを実行します。

本記事は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 に直接イ

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

Most awesome this week!

Badges

Show all badges