Topics started by TetsuoMiyoshi

158 Topics

Nutanix AHVクラスタにbitnamiイメージをインストールする

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

Nutanix Files Enterprise Cloudのためのファイルの監査と分析

本記事は2019年3月21日にNutanixのTechnical Marketing EngineerのMike McGheeが投稿したものの翻訳版です。原文はこちら。 広がり続けるデータの宇宙エンタープライズアプリケーションからモノのインターネット(IoT)に至るまで、データを生成するコネクテッドデバイスの数の成長は圧倒的な速さです。Business Insiderによると2020年までに240億以上のインターネットに接続されたデバイスが地球上でインストールされると予測されています[1]。IDCのアナリストが2025年までに全世界で175ゼタバイトのデータが生成され、これが2016までに生成されたデータの10倍に及ぶ[2]ということについて、疑問の余地はありません。 この膨大なデータの殆どが非構造化データであると予測されています。多くの非構造化データはオブジェクトストレージベースのサービスに保管される一方で、大量のそして頻繁にアクセスされるデータはデータセンタ内のSMBとNFSプロトコルを利用するネットワーク接続ストレージ(NAS)に保管されることになります。 従来型のシステムは大規模に非構造化データを管理していくという点において制限を継承しており、今後到来するデータの爆発に対応することができません。そして、管理者が複雑な環境をレガシーなツールで管理することに奮闘している最中にも監査とコンプライアンスについての新しい要件がビジネスの脆弱性が罰則に繋がってしまうこともあります。 データの監査とコンプライアンスについての課題Nutanixはサイロ化されたNAS環境の複雑性を排除するためにNutanix Filesを開発しました。しかし、データを保存することはデータについての洞察、監査、コンプライアンスを含むNASのコアとなる機能の外側における課題を生み出します。 あらゆる産業はそのコンプライアンス目標という点で異なる課題に直面しています。GDPRに伴う個人情報、PCI-DSSに影響するクレジットカード決済、またはHIPPAで管理された健康情報など、あらゆる業界に適合しなければならない固有のスタンダードがあります。特定の一つの業種の中だけでもその要件が異なる場合があります。例えば、アメリカ合衆国ではそれぞれの州に異なる法律があり、それによっ

NutanixとHPEはクラウドのシンプルさをオンプレミスへ提供するためにチームを結成協業

本記事は2019年10月9日にBrian Coxが投稿した記事の翻訳版です。原文はこちら。 2019年10月9日、HPEとNutanixはHPE GreenLake with Nutanixの提供開始をアナウンスしました。HPE GreenLakeはオンデマンドのキャパシティとプランニングを提供するインフラストラクチャサービスです。HPE GreenLakeの顧客は自身のアプリケーションが動作しているインフラストラクチャの展開と運用をサービスとして利用し、Nutanix Enterprise Cloudの1-クリックのシンプルさと高い拡張性を享受することができます。この新しいインフラストラクチャの利用モデルのアナウンスはデンマークのコペンハーゲンで開催されるNutanix .NEXT Europeユーザーカンファレンスでも取り上げられます。 NutanixのChief Marketing OfficerであるBen Gibsonは以下のように述べています。「HPE GreenLakeはHPEが提供するサービスの中で最も早く成長しているサービスの一つで、Nutanixがその一部になれることを大変喜ばしく思います。我々はお客様にさらなる選択肢を提供できることを嬉しく思います。Nutanix Enterprise CloudをGreenLakeのポートフォリオに加え、IT部門がビジネス部門へと迅速にサービスを提供する方法をシンプル化するまた一つ新しい方法を提供することができるのです。」HPE GreenLake Flex Capacity プログラムはHPEから提供される利用ベースでのITモデルですでに広く利用されており、お客様のIT運用をシフトさせます。pay-as-you-goのインフラストラクチャをキャパシティオンデマンドで提供し、パブリッククラウドの俊敏性と経済性をオンプレミスのセキュリティとパフォーマンスを融合させて提供します。HPE GreenLake with Nutanixは仮想マシンに割り当てられた仮想メモリのGiBの総量でその従量を計測しています。一ヶ月の平均的な利用が計算され、月ごとに請求が行われます。お客様はHPEシステムとNutanixソフトウェアをオンサイトもしくはお客様のコロケーションファシリティで提供を受けますが、先行投資コストは一切ありま

パブリッククラウドの課題 – パート3:大規模環境でのTCO/ROIとストレージ容量

本記事はJosh Odgers氏が2020年8月14日に投稿した記事の翻訳版です。原文はコチラ。本シリーズの索引はコチラです。パート2では、効率的なAOSのおかげで、3ノードのi3.metal環境でのNutanix Clusters on AWSソリューションでは、使用可能な容量がVMwareのVMCよりも24.5%多くなることを説明しました。このことは小規模環境の顧客やコスト意識の高い顧客にとっては朗報ですが、Nutanixにおいて、環境が拡張されても容量やROIにおいて同様なメリットが得られるのか疑問に思う方もいらっしゃると思います。今回の投稿では、次の3つのシナリオについて紹介します。4ノードクラスターと5ノードクラスター 6ノードクラスター 16ノードクラスターこの3つのすべてのシナリオで、AWS i3.metalサービスを使用します。この3つの例を取り上げるのは、VMCでは、3ノード環境、4~5ノード環境、および6ノード以上の環境に対して、それぞれ異なるストレージポリシーがデフォルトで適用されるためです。16ノードの例では、VMCでサポートされている最大規模のクラスターを使用した場合について紹介します。 4ノードクラスターと5ノードクラスターの比較4ノード環境の場合、VMwareのVMCは、論理容量に対して物理容量のオーバーヘッドが2倍になるFTT1(ミラーリング)から、3+1ストライプサイズを使用するイレージャーコーディング(RAID5)に切り替わります。切り替え後は、1.33倍のオーバーヘッドで容量が提供されます。参照先:https://blogs.vmware.com/virtualblocks/2018/06/07/the-use-of-erasure-coding-in-vsan/イレージャーコーディング(RAID5)に切り替わると、使用可能な容量が増えるため、切り替えはその点で意味がありますが、以下のような重大な影響が生じます。オールオアナッシング的なアプローチのため、I/O用の重要なパスに影響が生じる。VMwareもパフォーマンスへの影響を認識している 4ノードクラスターでは単一ノード障害を許容できず、単一ノード障害の場合は自己修復が不可能(3+1のストライプでは4つのノードが必要)なため、回復力が低下する I/O処理が少なくとも4つのノード

Nutanix AOS vs vSAN/VxRAIL 完全なデータ退避モードの場合

本記事は2021年2月2日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの牽引はこちら。  本シリーズのパート1では、HCIプラットフォームをテストするためにX-Rayを使って実行できる、新しい「HCI Platform Availability, Resiliency & Integrity (プラットフォームの可用性、回復力、そして整合性)」」のシナリオについて学びました。 パート2では、Nutanix AOSがメンテナンスモード、再起動、障害シナリオにおいて、仮想マシンの完全な可用性とデータの整合性を維持すること、そしてvSAN 7.0 Update 1が再起動と障害シナリオの両方でI/Oの整合性エラーが発生することを紹介しました。 パート3では、PVSCSIドライバのI/Oタイムアウトを30秒から180秒まで増やすことで問題が解決するかどうかを調べました。その結果、I/Oタイムアウトを増加させることでエラー数は減少しましたが、最終的にはvSAN 7 Update 1で発生するI/Oエラーを防ぐことはできませんでした。 今回のパート4での疑問は、「vSANの完全なデータ退避モードを使うことで、データの整合性の問題を回避できるか?」です。 完全なデータ退避モードについては、以下のVMware社のドキュメントで説明されています。簡単に言うと、ホストがメンテナンスモードになると、すべてのデータ(vSANオブジェクト)がクラスタ内の他のホストに再作成されます。ですので、理論上はホストがオフラインの間もデータの整合性が損なわれることはありません。 https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vsan.doc/GUID-521EA4BC-E411-47D4-899A-5E0264469866.html パート2と3で、vSANでもメンテナンスモードのフェーズでは、可用性の欠如やI/Oエラーが発生しないことを確認しました。これは、これらのテストでも完全なデータ退避モードが使用されており、vSAN7U1とすべてのオブジェクトが、ホストがオフラインであっても常に利用可能であったためです。 しかし、再起動や電源OFFのフェーズではどうでしょうか。 再起動や

HCIプラットフォームの可用性、回復力、そして整合性 – パート1

本記事は2021年1月11日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 X-Ray 向けの「Platform Availability, Resiliency & Integrity (プラットフォームの可用性、回復力、そして整合性)」のシナリオをもうすぐ(※原文記載時ママ)リリースできることを喜ばしく思います。 X-Rayにあまり馴染みのない方のためにご紹介しますと、X-Rayは自動化された検証とベンチマーキングのフレームワークのソリューションで、主なハイパーコンバージドインフラソリューションの包括的な360°でのアセスメントを提供します。 「Platform Availability, Resiliency & Integrity」シナリオ(これは現在ではvSphere 7 Update 1 のサポートのためのNutanixの公式なQAプロセスの一部でもあります)はHCIプラットフォームのメンテナンスモードへ入れたり、システムの再起動のような制御下で行われるメンテナンスはもちろん、ノード障害のような状況における仮想マシンのI/Oアクティビティ(可用性/回復力)を維持し、I/Oの整合性(エラーがないこと)を再現することを念頭に設計されています。  この検証では1台を除いたそれぞれノード上に1台の仮想マシンを展開すると、クラスタ内のノードに応じて自動的にテストをスケールアップします。これはN+1で適切に実際の環境でのサイジングをシミュレーションするためで、それぞれのノード内のフラッシュドライブの数をベースとして適切に目標となるI/Oレベルに合わせるためでもあります。 I/Oレベルをフラッシュドライブ数をベースとして調整していくことは、検証において比較的小さなノードやクラスタに過負荷をかけるだけで、結果として現実的ではない、人為的に生み出される多くのエラーを避けることができます。 それでは検証の内容とそのオプションを見ていきましょう。  この検証の主な目標は検証自体を大変シンプルで使いやすくすることで、迅速/簡単に概念検証(PoC)、インストール後の運用の確認の一部、そして構成変更後の期間での検証の一部として利用できるようにすることです。 特に手を加える必要もなく、検証は自動的に利用可能なクラスタ/利

Nutanix Prism Pro と 新機能 X-Play

code:今回の記事はシニアシステムズエンジニアの山下 富雄の記事です。山下は.NEXT JapanでPrism Proのセッションを担当します。新機能X-Playが加わったこれまでにはない自動化された運用を知りたい方、必見のセッションです。お申込みはこちらから。https://www.nutanix.jp/invisible/招待コードは「NTX049」にてお申し込みください。NTX-05 12:55-13:35システム運用をもっと楽に!Prism Proを使った高度なCluster管理 Nutanixが誕生して10年が経過しました。Nutanixが提唱した、インフラを簡単にする「Hyper Converged Infrastructure(HCI)」というアーキテクチャも、IT業界に広く浸透してきました。 またこの新しいインフラストラクチャを簡単に操作するための「Prism」も、ご利用いただいている多くの方々から高い評価をいただいています。 事前に特別なプログラムのインストールは不要で、WebブラウザでCluster IPへアクセスするだけでPrismへログインができ、様々なHCIの情報が確認できること、洗練されたインタフェース上で様々な操作が1-クリックで簡単に行えることなど、Prismが従来のインフラストラクチャの管理とは一線を画す理由は多く挙げられます。 Prism ElementとPrism Central さて、そんなPrismですが、みなさん存分に使い倒していますか? Prismには、Nutanixを導入すると標準で実装される「Prism Element(PE)」と、仮想アプライアンスで提供される「Prism Central(PC)」の2種類ががあります。 特にPrism Centralについては仮想アプライアンスを別途インストールする必要があることから、まだ利用いただいていない方も多いのではと思いますが、 Nutanixのソフトウェアやサービスにご興味を持っていただいた方にこそ、このPrism Centralはご利用いただきたいNutanix製品です。 Prism CentralとPrism Proライセンス Prism Centralは、大きく2つの特徴を備えています。 1.Nutanixの新しいソフトウェアやサービスの基盤 今後Nuta

NutanixがForresterのハイブリッドクラウド管理Waveでストロングパフォーマーとしてデビュー

本記事は2020年12月2日にAaditya Sood氏とVijay Raypati氏が投稿した記事の翻訳版です。原文はコチラ。 比較的にこのマーケットセグメントへの参入は新しいメンバーであるNutanixはThe Forrester Wave™: Hybrid Cloud Management, Q4 2020への参加の招待を受けました。ForresterはHCM Waveにおいて34の指標を用いて様々なソリューションを評価しており、我々は今回はじめての参加でしたが、ストロングパフォーマーとしてこれに含まれたことを大変誇りに思います。Forresterはハイブリッドクラウド管理(HCM)をガバナンス、可視性、ライフサイクル管理、そして最適化のためのインサイトをパブリックとプライベート環境を含むマルチクラウドに渡って提供するソフトウェアスタックとして定義しています。 Nutanixでは我々は2つの製品を提供しています ー Calm および Xi Beam ー これらはハイブリッドクラウド環境を管理するために必要な機能をソリューション実装の簡単さと利用のしやすさとともに提供しています。我々のこのレポートの分析によるとこのレポートに含まれるいくつかのベンダーは広範な製品群によって彼らのHCMソリューションを構成していますが、NutanixのHCMはエンタープライズの顧客がハイブリッドクラウド内で自身のアプリケーションとデータを管理するために広く共通して利用される機能を深いレベルでサポートし提供している点を強調したいと考えています。 なぜハイブリッドクラウド管理なのか? すべては自動化、コストの統制、セキュリティ自身のプライベートクラウドに加え、複数のパブリッククラウドでワークロードを稼働させている組織は単一ツールでのタスクの自動化、コストの管理、そしてセキュリティポリシーの徹底を求めています。こうしたツールがなければITおよびクラウドチームはそれぞれの環境向けの複数のプロプライエタリツールセットと運用モデルを管理しなければなりません。これはコスト増加、展開の遅さ、そしてエラーの増加に繋がります。簡単に展開できるパッケージによってNutanixは顧客が自身が利用するHCMソリューションから最大の付加価値を迅速に、そして自身のニーズにあった幅広い購買モデルの選択肢とともに提

VMware環境内のOracle – 今回はFUDなし!

本記事はTechnical Director, Business Critical AppsのMichael Webster氏が2019年9月17日に投稿した記事の翻訳版です。 原文はこちら。 John Troyer氏は本日のOracle OpenWorldでの出来事を象徴していると思います ー 世界がひっくり返った? Oracle Cloud Infrastructure上のVMwareのサポートとそれがオンプレミスの環境であったとしてもVMwareハイパーバイザー上のOracleのソフトウェアがサポートされます! [img]https://pbs.twimg.com/profile_images/1138638060394930178/0t3xziuG_bigger.jpg[/img]John Mark Troyer@jtroyer Hell freezes over? I think Larry undersold this VMware-Oracle announcement. Along with VCF on OCI, It includes mutual support for Oracle software on VMware! #OOW19[img]https://pbs.twimg.com/media/EEn-yGDUcAA248K?format=jpg&name=medium[/img] 639:03 AM - Sep 17, 2019Twitter Ads info and privacy 33 people are talking about this 本日サンフランシスコで開催されたOracle OpenWorldで、最初はさほど大きな注目を集めなかった小さなアナウンスが行われました。しかし、実際にはこれはIT業界に地殻変動的な変化をもたらすものです。OracleとVMwareは共同でOracle Cloud Infrastructure上のVMwareのStackについてVMware Cloud Foundationをサポートし、同時にオンプレミスの環境であってもVMware上のOracleソフトウェアについてのサポートを行うとアナウンスしました。すでにHyper-Vを認証していますが、これはOracle社が自身

次なるフロンティア – ROBOおよびVDI環境に向けたインビジブルなライセンス

本記事は2019年8月7日にGreg White氏、Kong Yang氏、Adrian Finch氏が投稿した記事の翻訳版です。 原文はこちら。 Nutanixは継続的にITがよりビジネスへと付加価値を提供できるようにするためのシンプル化に取り組んでいます。まず最初に我々が行ったことはインフラストラクチャをインビジブルにすること、そしてデータセンタ、現在はクラウドです。続いてライセンシングに取り組むべきというのは非常に論理的ではないでしょうか?うーん、ちょっと言いすぎかもしれませんが、それ以外の件と同様に我々はライセンシングからも複雑さを取り除きたいのです。 Nutanixは特定のユースケースについてキャパシティベース(CBL)とアプライアンスライセンシング以外の新しい選択肢となる利用モデルを導入し、様々なNutanixソフトウェアの利用をシンプルに計画、価格、購入を実現する方法をご提供します。2つの新しいユースケースは仮想デスクトップインフラストラクチャ(VDI)とリモートオフィス/ブランチオフィス(ROBO)環境です。 新しい利用モデルとはどのようなもの?この消費モデルは幾つかのNutanixソフトウェアソリューションを一緒に「ライセンシング」するモデルで、これによってハードウェアとソフトウェアの購入は分離されることになります。これによって、インフラストラクチャのニーズに基づいてどこに、どのようにNutanixソフトウェアを展開するかという点で、大きな柔軟性が実現されることになります。それぞれのモデルはAOS、AHV、Prism Starterを含んでいます。 VDIについてはこのライセンスモデルはVDI per userと呼ばれ、同時ユーザー数をベースとします。 ROBOについてはこのライセンスモデルはROBO per VMと呼ばれ、サイト内で利用される仮想マシン数をベースとします。 なぜ新たなモデルが必要なのか?こうしたソリューションの領域においては、過去から市場において「毎」のモデルが利用されてきました。同様のアプローチをご提供することで、HCI上でのインフラストラクチャのモダナイゼーションの計画をシンプル化することができます。加えて、展開の初期の小さな環境において、ハードウェアに紐付けられた価格は組織がまだ成長の余地を残しているにも関

Nutanix Era データベース& API自動化

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

Nutanixストレージ視点からのPostgresのベンチマーク

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

HCI プラットフォーム の可用性、 回復力、整合性 X-Ray のシナリオがGAしました!

 本記事は2021年3月5日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの牽引はこちら。 私はしばらくの間、社内のエンジニアリング/QAだけでなく、お客様がNutanixのより詳細な機能を迅速/容易にかつ反復してテストできるように、新しいX-Rayシナリオの構築に取り組んできました。 HCIプラットフォームの可用性、回復力、そして整合性シリーズでは、Nutanix AOSとVMware vSANの両方でテストがどのように機能するかを詳細に説明しており、AOSがvSANに対して大きな優位性を持ち、最小3ノードの構成で障害が発生しても常にデータの整合性(可用性と回復力の両方)を維持できることを強調しています。 一方、vSANは、より高いI/Oタイムアウト、より大きなクラスター、3つのデータコピー(FTT2)でもI/Oエラーが発生します。 しかし、私の言葉を鵜呑みにせず、ご自身でもテストを行ってみてください。 Nutanix ポータル から X-Rayバージョン3.10.2の、vSphere用のOVAまたはAHV用のQCOWイメージをダウンロードし、テストを行う予定のクラスターとは別のクラスターにデプロイするだけです。 その後、WebブラウザでX-Ray VMのIPアドレスに移動し、「ターゲット」クラスターを設定し、検証を実行して、すべての帯域外管理と認証情報が機能していることを確認すれば、準備完了です。  デフォルトのオプションでは、メンテナンスモード、再起動、および10%の稼働率でのノード障害のシミュレーションを含む、プラットフォーム全体の回復力テストを実行します。 このテストでは、クラスター内の1つのノードを除くすべてのノードに1つの仮想マシンをデプロイすることで、クラスター内のノード数に応じて自動的にスケールします。これにより、適切なサイズの実環境であるN+1をシミュレートするとともに、各ノードのフラッシュドライブ数に基づいて目標I/Oレベルを調整します。 フラッシュデバイスの数に基づいてI/Oレベルを調整することで、現実的ではない、あるいは人為的に高いエラー数につながる、小規模ノードやクラスターへの単純な過負荷を避けることができます。 このテストの目的は何でしょうか? 簡単に言えば、もしもHCIプラットフォームが、VMの可用性に

X-RayとpgbenchでCPUのパフォーマンスを測定する

本記事は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クラスタ内にContrail SDNコントローラーを展開する

本記事はNutanixのEnterprise ArchitectのAmin Aflatoonian氏によって2020年7月30日にNEXTコミュニティに投稿された記事の翻訳版です。原文はこちら。以前の記事の中で、AHVクラスタへのContrail統合のアーキテクチャ上の概要をお伝えしました。今回の記事ではこのコントローラーの展開について詳細にお話していきます。仮想マシンネットワークと仮想マシン作成の詳細についてはこの次の記事でお話します。 展開Contrail on AHVの展開についてご説明するために、我々は3ノードのNutanixクラスタ環境で構成されているラボを利用します。ラボのアーキテクチャについては以下の図に示します。Contrail AHV ラボ アーキテクチャContrailのコントローラーのHAは必要ないので、1台のContrailコントローラー仮想マシンと3台のvRouter仮想マシンのみを展開します(各々のノードに1台のvRouter)。Contrailの展開にはAnsibleを利用しました。このラボ上にAnsible deployer仮想マシン(Contrail deployerと呼びます)も作成し、これで展開ライフサイクルを管理します。このためにNutanixクラスタ上にprovisioningネットワークを作成し、このネットワークにすべてのContrail仮想マシン(コントローラーとvRouter)を接続します。以下の図はラボのネットワーク構成を顕したものです。Contrail AHV ラボ - ネットワーク構成ラボの準備以下のテーブルはContrail仮想マシンの展開に資料したこのラボのネットワーク構成を顕しています。ラボのネットワーク構成オーバーレイブリッジとvRouterオーバーレイネットワークContrail仮想マシンを展開する前に、すべてのNutanixノード上にオーバーレイブリッジ(brOvly)を作成します。このブリッジは隔離されており、物理NICや他のOVSブリッジとは一切接続されていません。このブリッジを作成するためにはCVMからallsshコマンドを利用することが出来ます。オーバーレイブリッジを作成した後には、vRouter仮想マシンとこのブリッジを接続するオーバーレイネットワークを作成します。このブリッジを作成するため

パブリッククラウドの課題 – パート5:ストレージデバイス障害と回復力への影響

本記事はJosh Odgers氏が2020年8月18日投稿した記事の翻訳版です。原文はコチラ、本シリーズの索引はコチラです。 パート1では、AWSでVMwareのVMC製品を使用する場合、VMwareやその顧客はネットワーク帯域幅を制御できないという、VMCのコアアーキテクチャーが及ぼす重大な影響について紹介しました。パート1をお読みいただいていない場合は、この投稿を読み進める前に目を通していただくことをおすすめします。パート1で紹介している概念は、この投稿のテーマである「デバイス障害と回復力への影響」について理解を深めていただくために重要です。パート2、パート3、およびパート4では、AOSの機能のおかげで、Nutanix ClustersではVMCよりも高いフロントエンドパフォーマンスを発揮しながら、使用可能な容量も多くなるということについて紹介しました。また、パート4では、VMC(vSAN)で圧縮と重複解除を使用すると、ドライブ障害のリスクや影響が大きくなるのに対して、Nutanix Clustersでは、このようなデータ効率テクノロジーを使用するかどうかに関係なく、回復力への影響がないことを紹介しました。このようにNutanix ClustersはVMC/vSANに対して優位性がありますが、プラットフォームが障害に対して高い回復力を備えていなければ意味がありません。この投稿では、AWS i3.metalインスタンスを使用する場合に、Nutanix ClustersとVMware VMCがさまざまなドライブ障害シナリオをどのように対処し、どのように回復するのかについて紹介します。AWS EC2 i3.metalインスタンスなどのパブリッククラウドサービスを使用する際、NVMeフラッシュデバイスは耐久性が高くないと考えられるため、VMC/vSANなどの製品がディスクグループごとに単一キャッシュドライブに大きく依存する場合は、Drive Writes Per Day(DWPD:1日当たりのドライブ書き込み数)の指標が適切でない可能性がある、ということを考慮することが重要です。VMwareは記事「Understanding vSAN Architecture: Disk Groups」の中で、キャッシュドライブに関して以下のように述べています。高耐久性フラッシュデバイ

Nutanix、企業向けオンプレミスKubernetesのAmazon EKS Anywhereサポートを拡大

本記事は Luke Congdon氏、 Andy Daniel氏、 Aaron Delp氏が 2022年10月26日に投稿した記事の翻訳版です。原文はこちら。  Nutanixと当社のお客様は、常にデータセンターにおける選択肢を受け入れてきました。Nutanix Cloud InfrastructureとNutanix Unified Storageは、数千にも及ぶお客様の、仮想マシン内と、Kubernetesを活用した、マイクロサービスベースのモダンなコンテナ内のアプリケーションが混在する環境において、容易かつ、エンタープライズクラスの運用とソリューション、そして拡張性を提供しています。本日、ミシガン州デトロイトで開催されたKubecon North Americaにおいて、今年初めにお約束した、Nutanixマネージドインフラストラクチャ上でのAmazon EKS AnywhereのGAサポートの実現ができたことを、嬉しく思っています。  Amazon EKS Anywhereは、Nutanix上にKubernetesクラスタを展開するためのエンタープライズクラスのソリューションで、クラスタの作成と運用を簡素化します。デフォルトのコンポーネント構成、統合されたサードパーティソフトウェア、およびAmazon EKSと一貫性のあるツールが含まれています。いったんインストールすれば、Amazon S3、Amazon RDS、Amazon API Gatewayなどを含めた、多くのAWSサービスを追加活用することができます。EKS Anywhere自体には、デフォルトの構成、コンテナランタイム、CNI、および複数の認証オプションが含まれています。 Nutanixは、あらゆるアプリケーションを実行するためのフルスタックかつスケーラブルなソフトウェア・ディファインドプラットフォームを提供する、最新のアプリケーションに最適なプラットフォームです。これには、Volumes、Objects、Files、Nutanix Database Service(NDB)など、ステートフルなアプリケーションのニーズに応える、柔軟で安全なエンタープライズグレードのデータサービスや、Amazon EKS Anywhereや参加するKubernetesランタイムプロバイダ向けの統合オープンソースク

Red Hat OpenShift IPI on Nutanix クラウドプラットフォーム

  本記事は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 4.0新機能。Smart DRの強化

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を使っている場合、環境をアップグレードするだけで、これらの

Nutanix Insightsの発表 - 健全性の予兆検知 & サポート自動化サービス

本記事はPrashant Batraが2019年10月9日に投稿した記事の翻訳版です。原文はこちら。 2018年の10月に私はNutanix Pulseについての記事を投稿しています。これは全てのNutanixのクラスタにビルトインされたオプションのテレメトリサービスで、皆様のNutanix Enterprise Cloudのための予兆分析を実現するためのものです。PlusテレメトリはNutanixのサポートがお客様により良いサービスを提供するため、お客様の特別な構成や利用状況を理解した上でのよりダイナミックで文脈を理解したサポートエクスペリエンスを提供しています。同様に、Nutanixの製品とエンジニアリングチームはこのテレメトリを活用し、お客様の利用や設定を理解し、お客さまのニーズにより合う既存のプロダクトの改善を行ったり、新たな製品を生み出しています。本日、我々はNutanix Insightsをアナウンスいたします - 皆様のNutanix Enterprise Cloudのための健全性の予兆検知とサポートの自動化サービスです。Nutanix Insights は新たなソフトウェア・アズ・ア・サービス(SaaS)サービスで、お客様がPulseを有効にしている場合、その受け取ったテレメトリを活用して、我々のお客様のサポートのエクスペリエンスを再定義し、クラスタの健全性を劇的に改善します。マニュアルのサポートプロセスを削減し、日々のメンテナンス作業に使う時間を短くすることで、ITチームはビジネスユニットに対する価値を高める活動にフォーカスすることができます。 我々はよくお客様からもっと深く自身のプライベートクラウドとハイブリッドクラウドインフラストラクチャを理解し、地域やサイトをまたがったインフラの管理をシンプルにしたいというリクエストをいただきます。典型的な質問は以下のとおりです:もうサポートされない(End-of-LifeもしくはEnd-of-Support)のソフトウェアを動作させていたりはしませんか? 我々のソフトウェアスタックは最新に維持されており、セキュアで全てのコンポーネントはそれぞれでハードウェアとソフトウェアのレイヤーで互換性が取れていますか? クラスタ内のノード、ライセンス、サポートサブスクリプションは最新でしょうか?もし次のために何かを今用

Postgresでのベンチマーク パート1

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

vSAN/VxRAILのストレッチクラスタはデータ整合性を維持できるか?

本記事は2021年2月11日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 このシリーズでは、ではNutanix AOSが回復力ファクタ(RFつまり2つのデータコピー)を利用した場合に3ノードクラスタの場合も含め、メンテナンスモード、再起動、および障害シナリオにおいて完全な仮想マシンの可用性とデータの整合性を維持できるということを見てきました。 そして、パート2では、Nutanix AOSとvSAN 7 Update 1とを比較し、vSANが再起動と電源サイクル(障害)シナリオの両方で、以下のようなあらゆるvSANにとって有利に働く状況を作ったとしてもI/O整合性のエラーに苦しんでいるという事実を確認しました: vSANが長い(SCSI)I/Oタイムアウト設定を利用している (180 秒 vs Nutanix 30 秒) vSANがデータの完全退避モードを利用している vSANのオブジェクトリビルドタイマーを60分の遅延から遅延なしに変更 (すなわち、これによってリビルドは即時開始される)  より大きなクラスタ(8ノード)を利用し、その上で、テストはそのクラスタ内の最初の4ノードのみで実施する パート7では、7ノードのクラスターでvSANの耐障害性(FTT)を2に設定した場合の動作について見ていきましたが、驚くことに、デュアルパリティのvSANを使用してもデータ整合性の問題に対処できないことがわかりました。 それでは、vSANをストレッチクラスター構成で使用する場合、仮想マシンの可用性とデータの整合性がどのように扱われるのかを確認していきます。 このテストは、8台のDell PowerEdge R740xd-24を使用し、VMware ESXi, 7.0.1, Build 17551050を用いて実施しました。 最初のテストでは、「4+4台構成のストレッチクラスタ|FTT1|I/Oタイムアウト180秒」を使用し、Active/Passiveスタイルのストレッチクラスタをシミュレートしました。ここでは、フォールトドメイン1では3つのVMを実行し、フォールトドメイン2ではVMを実行しませんでした。 簡単に言えば、このテストにおけるフォールト・ドメインとは、サイトやデータセンターを意味しますが、ノードはすべて同じ25Gbのネ

パブリッククラウドの課題 – パート7 – ストレージI/Oパスと回復力への影響

本記事はJosh Odgers氏が2020年8月20日に投稿した記事の翻訳版です。原文はコチラ。本シリーズの索引はコチラです。 パート6では、ベアメタルインスタンスに障害が発生した後で、VMware VMCとNutanix Clustersの各アーキテクチャーではリビルドがどのように実行されるのかについて、および回復力とパフォーマンスにおいてNutanixで得られる主な利点について紹介しました。この投稿では、I/OパスにおいてI/Oが「スタック」または「ハング」するというシナリオに両方の製品がどのように対処するのかについて、および、これらの状況が及ぼす影響について紹介します。説明に入る前に、概念レベルで、インフラストラクチャーの目的は最大限の可用性とデータ整合性を確保することです。そのため、インフラストラクチャーと業務に対するリスクや影響を最小限に抑えるように、あらゆる障害に対処する必要があります。それを前提に、パブリッククラウドでVMware VMCとNutanix Clustersを使用する場合に、I/Oが「スタック」または「ハング」すると、どのようなことが発生するかを紹介します。VMwareはKB「How to handle lost or stuck I/O on a host in vSAN cluster (71207)」を公開しており、このKBの中で、I/Oパス内のいずれかの場所(ストレージコントローラーや物理ドライブ自体など)でI/Oの「スタック」または「損失」が発生した場合に、vSANがどのように対処するかを紹介しています。VMwareでは、この症状を以下のように説明しています。ストレージコントローラー上やストレージディスク上でI/Oのスタックまたは損失が発生した場合、ESXiストレージスタックはタスク管理リクエストを使用してI/Oを中止するように試み、以下のコンソールメッセージが表示されます。参照先:HTTPS://KB.VMWARE.COM/S/ARTICLE/71207続けて、以下のように説明しています。ホスト上でこのような損失I/Oが見つかった場合、vSANはこのホストで強制的にPSODを実行し、このホストがクラスター内の他のホストに影響を及ぼさないようにします。参照先:HTTPS://KB.VMWARE.COM/S/ARTICLE/712

Badges

Show all badges