Topics started by TetsuoMiyoshi

ソフトウェア・ディファインド・ストレージはIT部門へ柔軟性、拡張性、そしてコスト削減をもたらすことができます。 本記事はMichael Brenner氏が 2023年5月30日にForecast by Nutanixに投稿した記事の翻訳版です。  データはあらゆる場所にあります。ビジネスによってデータは様々な場所、オンプレミスやリモートのデータセンター、そしてパブリッククラウドへと分散されていきます。データを安全に、そしてアクセス可能にしておくためには継続的な取り組みが必要で、大抵の場合、より多くのスペースが必要となります。ソフトウェアの手助けを借りる必要がある場面が大きく拡大し続けています。ソフトウェア・ディファインド・ストレージ(SDS)はストレージソフトウェアをあらゆる物理的なハードウェア部分と切り離す手法で、ネットワークのサイズに関わらず、大容量のデータを効率的に管理し、俊敏性を手にすることができるようになります。SDSを利用することの主な効果はビジネス部門の運営に合わせて効率的に拡張できるようになることと、コストを削減することです。 まとめ:SDSは組織のハードウェアをどのように使うかの柔軟性を実現することができます。 負担が小さく、素早い対応によってSDSはIT担当者と利用者にとって便利なストレージソリューションとなっています。 自動化、最適化、そしてプロプライエタリからの開放の全てがSDSを利用するビジネス部門にとっての削減となります。 ハードウェアからソフトウェアを分離することで、組織のストレージのプラクティスに従って社内、社外のいずれでも、ほぼ無制限の拡張性を実現することができます。SDSの効果を理解することで、このテクノロジーに対する投資が組織にとって非常に理にかなったものであるということを明瞭に理解することができます。  ソフトウェア・ディファインド・ストレージはどのように動作するのか?ソフトウェア・ディファインド・ストレージの背景にあるコア・コンセプトは抽象化です。物理的なハードウェアに依存すること無く、データを補完するという考え方は受け入れがたいものかもしれませんが、同様の抽象化は、一箇所のハードウェアのリソースをソフトウェアが引き出し、ホストサーバーとは分離された多くの仮想マシンを作成するという仮想化において一般的な考え方になっています。

 本記事はNutanixのLaura Jordana, Technical Marketing Engineer NCM と Christine McMonigal, Director of Hyperconverged Marketing at Intel が 2023年6月2日に投稿した記事の翻訳版です。原文はこちら。     高速なアプリケーション開発2020年の初頭、パンデミックが勃発した際に、Nutanixで我々はお客様が我々の製品とサービスをウェブブラウザーとインターネット接続だけですぐに使用できるアプリケーションを開発している真っ最中でした。この重要性は世界中で対面でのミーティングが文字通りキャンセルされていく中で、大変重要な物となっていきました。我々はデジタル化を加速し、お客様が我々と適切な方法でやり取りをするやり方を実現しなくてはなりませんでした。我々は他の多くの人々がそうであったように、迅速な拡張性が必要で、これを実現するためにパブリッククラウドを活用したのです。Intel® Virtualization Technology もしくは Intel VT-xの能力を活用し、我々はパブリッククラウド内でセキュアな入れ子(nested)仮想化の恩恵を受けることができ、これによって、我々のAHVハイパーバイザーを仮想化し、そのハイパーバイザー内で仮想マシンを稼働させ、デモデータやアプリケーションを提供することができたのです。これは現在Nutanix Test Drive として知られることになります。 Nutanix Test Driveとは?Product-led growth(製品主導の成長)について耳にしたことがあれば、製品の利用がお客様の獲得、維持、そして拡張を推進するということを知っているはずです。Nutanixでは我々はお客様の大部分がITプラクティショナー(実践者)であり、こうした人々は通常まずはハンズオンを受講することで製品について学びたいと考えており、ホワイトペーパーや営業マンを通して学びたいと考えてはいないということを理解していました。Test DriveはNutanix製品とソリューションの機能についてのショーケースを作成し、お客様やその候補に対して可能な限り面倒を感じさせないようにしています。Nutanixの開発チームはAHVハ

ITリーダーは、IT投資からより多くの利益を得るために、あらゆるエンタープライズ・テクノロジーを利用しています。  本記事は Scott Steinberg氏が 2023年4月19日に投稿した記事の翻訳版です。原文はこちら。 IT業界のベテランに話を聞くと、ほとんどすべての業務において効率化が最優先事項であることがわかります。世界経済が低迷し、新しいテクノロジーの波が意思決定を複雑化させるにつれ、その必要性と難易度はますます高まっています。 Gartnerによると、世界のITソリューションへの支出は、2023年には5.1%増の4.6兆ドルに達すると予想されています。アプリケーションソフトウェア、インフラソフトウェア、ビジネスプロセスサービス、システムアーキテクチャに対する企業の投資の半分以上が、今後数年間でクラウドへ移行すると予想されています。とはいえ、クラウド化を急ぎすぎた企業は、ハイブリッドクラウドアプローチが最善の方法であることに気付きつつあります。その一方で、企業は景気後退による投資の大幅な削減を懸念しています。 ITの意思決定者は、予算内でより多くのものを得ることを目指し、所有とレンタルを組み合わせたコンピューティング・リソースの総所有コスト（TCO）シナリオを検討しています。ハイパーコンバージドインフラストラクチャー（HCI）技術は、変化するニーズに合わせてワークロードを最適化できるハイブリッドマルチクラウド運用モデルを構築するのに役立ちます。 Juniper NetworksのCIOであるSharon Mandell氏は、Nutanixに対して次のように語っています。「ITリーダーとして、私たちは常に『少ないリソースでより多くのことを行う』という考え方で、業務にあたっています。」 “例えば、スタートアップと仕事をするとき、特にそれがビジネスの重要な領域である場合、まずは彼らが財務的にどのような状況にあるのかを理解したいと考えます。” 関連 ： HCIのビジネス価値を試算する 特に厳しい経済情勢下では、IT機能はビジネスコストとみなされ、厳しく管理されることが多いです。ITが将来にとって不可欠であると考える企業でさえも、必要なものだけに予算を使うという戦略性を強めています。コンピューティング・リソースを迅速にスケールアップまたはスケールダウンするという機

業界レポートや各地域の専門家は、アプリケーションやデータを管理するための技術に巨大投資が行われると予測しています。  本記事は Scott Steinberg氏が 2023年4月3日に投稿した記事の翻訳版です。原文はこちら。 市場調査会社IDCによると、2026年までに、アジアを拠点とする2,000社のトップ企業の総収入の40％が、デジタル製品、サービス、体験によって生み出されるようになるとのことです。これにより、爆発的に増加するアプリケーションやデータ、そしてそれらを実現するシステムを管理する必要性が高まります。 従来のデータセンターで運営されている技術が、「旧態依然」であり続けることは、もはや不可能です。また、クラウドサービスへの移行を急ぐことは、必ずしも最良の反応とは言えません。これらのことは、COVIDによる混乱後のビジネス調整で明らかになりました。と、NutanixのAPJセールス担当ジェネラルマネージャー兼バイスプレジデント(営業部長)であるAaron White氏は述べています。 「組織にとって今こそまさに、一歩引いて、パッチワークのような情報技術を手放し、時の試練に耐え得るより永続的で拡張性の高いソリューションへと切り替えるべき時なのです。」とWhite氏は述べています。 その結果、だんだんと、企業の多くが、ハイブリッド型マルチクラウドITオペレーションを採用し、構築するようになってきています。White氏は、APJ全域の顧客が、デジタルトランスフォーメーションとデータセンターの最新化を優先し、パンデミック時にパブリッククラウドとデータベースを急いで導入した状況を継続しつつ、より永続的でかつ安定したソリューションへ到達したと見ています。 「顧客は、アプリケーションの数が飛躍的に増加することで、その管理の必要性に迫られると同時に、データベースのスプロール化(無計画な広がり)にも対処せざるをえません。」「このことは、この地域のITチーム全体にまたがって、いくつかの重要な傾向をもたらしています。」と、White氏は述べています。 関連 ： ハイブリッドマルチクラウドシステムでデータベースを制御する IDCは、今後数ヶ月内に、この地域の企業が、コスト削減と効率化の手段として、ITソリューションに多額の投資を行うであろうと言及しています。同様に、アプリやデータ

Nutanix Clustersを評価したクラウド技術の性能検証の専門家が、　クラウド環境におけるよりよい経済運用を見出すヒントを提言します。本記事は Tom Mangan氏が 2023年3月28日に投稿した記事の翻訳版です。原文はこちら。  クラウドに経済的なメリットはあるのでしょうか？Tony Palmerは「それは、そのとおりです。ただ、どういった点に目を向けるべきかが問題なのです。」と述べています。Palmerは、マサチューセッツ州ボストン郊外のニュートンに拠点を置く技術コンサルティンググループ、Enterprise Strategy Group [esg-global.com] (ESG、TechTargetの一部門)の主席検証アナリストです。ESGが得意とする専門性のうちのひとつが、一般的なエンタープライズ・テクノロジーの有効性を検証し、その検証結果を徹底的にレポートすることです。「技術検証には、製品やソリューションが謳い文句通りに機能するかどうかを確認するテストの要素があります。」と、Palmer氏はThe Forecast by Nutanixのインタビューに答えています。Palmer氏は、検証がハードウェアやソフトウェアの性能を文書化するだけではなく、テクノロジーソリューションのビジネス価値をも実証しなければならないのであると、言及しています。 クラウドの経済的な利点とは？クラウドの経済的利点を検証することは、テクノロジー・アナリストに共通する楽しみです。クラウドがアジリティ(俊敏性)、スピード、スケールを提供することに疑いの余地はありません。しかし、クラウドの効率性についてはどうでしょうか。クラウドのコストは通常、クラウドの利用量と連動して上昇するため、その際のクラウドの効率性はより大きな課題となります。この板挟み的な難題は、2021年にシリコンバレーのベンチャーキャピタルであるAndreesen-Horowitz氏が発表した、影響力のある記事に端を発しています。この記事は、あることを指摘しています。企業のエンタープライズクラウドの導入が拡大するにつれ、企業のコストは爆発的に上昇し、結果、時価総額が数十億円減少している、すなわち、市場シェアの拡大や顧客体験の変革など、より差し迫った問題に費やした方が良い資金がクラウドのために費やされている、という

本記事は 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ランタイムプロバイダ向けの統合オープンソースク

本記事はRaghav Tulshibagwale氏が 2021年3月10日に投稿した記事の翻訳版です。原文はこちら。  本日の記事では、また新たなゲストライターを紹介させていただきます。皆さん、Nutanixのスタッフエンジニア、Raghav Tulshibagwaleにご挨拶を！本日の記事では、継続的なシリーズの第1弾として、Raghavが私たちをNutanixにおけるRocksDBの旅へと案内してくれます。そしてRocksDBがNutanixプラットフォームアーキテクチャの様々な側面にどのように適用されているのかをご紹介します。私がRaghav自身よりもうまく説明することは到底できませんので、さっそく始めましょう！ はじめに2016年初めのアーキテクチャ検討会以来、Nutanixエンジニアチームは、分散ストレージファブリックの3つの大きな目標、すなわち、持続的でランダムな書き込み性能の向上、大容量ディープストレージノードのサポートの追加、バックグラウンドでのデータ管理の効率化に取り組んできました。これらの目標を明確にし、詳細を詰めていくうちに、私たちの限界要因はアーキテクチャ自体にあることに気づきました。さらに改善し、将来のスケーラビリティ(拡張性)のニーズに対応するには、Nutanixでのメタデータの保存方法を完全に再構築する必要がありました。メタデータをデータに近づけるという私たちの最大の目的には、メタデータを保存するための新しい基盤コンポーネントが必要でした。すでにうまく機能しているシステムに、まったく新しいコンポーネントを導入するのは、リスクの高い試みです。最終的にオープンソースのキーバリューストア（KVS）であるRocksDBを選択しましたが、これはあらゆる選択肢を調査し、それぞれの潜在的なコストと効果を考慮した結果です。オープンソースのソリューションが、十分な信頼性と耐久性を持ち、私たちのチームが数カ月で十分なノウハウを身につけ、そのコンポーネントを本当に自分たちのものにできるのかを確かめたかったのです。このブログシリーズの最初の記事では、専門用語、自律エクステントストア（AES）プロジェクトの全体要件、新しいコンポーネントの選択基準、エクステントストア用のRocksDB展開の概要、現在RocksDBを使用している他のNutanix製品およびコンポー

本記事はAnoop Jawahar氏 および Sandeep Madanala氏が 2021年10月4日に投稿した記事の翻訳版です。原文はこちら。  このシリーズのパート 1では、RocksDBをベースに、数十テラバイトから数ペタバイトまでのスケールに対応する分散型の、クラウドネイティブな、高い可用性を備えた、高性能なキーバリューストア（KVS）を新たに実装するに至った経緯について述べてきました。この記事では、ChakrDBの概要とその特徴、アーキテクチャの詳細について説明し、パート 1で提示した要件の達成にどのように役立ったかをまとめます。 概要ChakrDBは、分散型のNoSQL KVSです。ChakrDBインスタンスは、複数の仮想ノード(vNode)が組み込まれた単一プロセス、コンテナ、ないしはポッドです。各仮想ノード(vNode)は独立したKVSで、クラスタ内のシャードを所有し、すべてのデータをリモートクラウドストレージ（ボリューム、Nutanix仮想ディスク、またはAWSやAzureなどのクラウドによって提供される任意の仮想ディスク）に書き込みます。vNodeはKubernetes(K8s)が展開したext4ファイルシステムベースのボリュームとNutanixの内部ファイルシステムであるBlockStoreのいずれもをサポートしています。BlockStoreは物理ディスクとNutanixの仮想ディスクを含む様々なタイプの基盤ストレージをブロックベースの抽象化によってサポートします。ブロックベースのファイルシステムにより、vNodeはストレージファブリックと直接対話し、iSCSIよりもext4を使用することで余分なオーバーヘッドを回避し、スループットとレイテンシーを約50％向上させることができます。 ChakrDB の主な特徴完全な自在性と柔軟性ChakrDBには、仮想ノード(vNode)に基づくシャーディングデザインが採用されています。仮想ノード(vNode)は、高いスループットとテールレイテンシの改善でリニアなスケーラビリティを実現します。各仮想ノード(vNode)はRocksDB上で動作するラッパーであり、それ自体でKVSスタック全体を保有するため独立性が高く、データの移動と配置に柔軟性を提供します。仮想ノード(vNode)ベースの設計により、クラスタは

 本記事はAnoop Jawahar氏 および Sandeep Madanala氏が 2021年10月4日に投稿した記事の翻訳版です。原文はこちら。  歴史、背景、動機Nutanixクラウドオペレーティングシステムは、Webスケール、スケールアウトな設計を通じて、高可用性、レジリエンス、障害無害化能力とともに、包括的なストレージとコンピュートの仮想化を提供し、オンプレミスのデータセンターでパブリッククラウドのエクスペリエンスを、提供しています。当社のソフトウェアの基盤となる2つの主な技術は、Nutanixの分散ストレージと、コンピュート管理のためのKubernetesベースのマイクロサービス・プラットフォーム（MSP）です。あらゆるパブリッククラウドサービスで同じようなテクノロジーを利用することができます。例えば、ストレージであればAmazon Web Services（AWS）のElastic Block Store（EBS）やAzureのマネージドディスク、コンテナのオーケストレーションであればAWS Elastic Kubernetes Service（EKS）、Azure Kubernetes Service（AKS）、Google Kubernetes Engine（GKE）などが挙げられます。 今日の分散型データベースやデータサービスは、こうしたクラウドインフラストラクチャーの構造を活用することで、より軽量で先進的なものになります。また、モダンなデータアプリケーションは、あらゆるパブリッククラウドやプライベートクラウドで実行できるように、一定の原則に従う必要があります。アプリケーションをクラウド対応にするには、通常、オープンソースのAPI標準へ準拠したり、標準化されたiSCSIストレージをエンドポイントとしたり、インフラストラクチャ運用管理用のKubernetes（K8s）のようなオープンコンテナオーケストレーションフレームワークが必要です。 Nutanix ObjectsチームがChakrDBとの協業を開始したとき、Nutanixの開発チームは当社のクラウドOS上のストレージサービスを作成していました。Nutanix Objectsは、非構造化データ向けのS3準拠のハイブリッドクラウドストレージで、クラウドの構造を活用できるよう構成されています。クラウ

本記事はHarshit Agarwal氏 と Gary Little氏がNutanix.Devに2022年4月20日に投稿した記事の翻訳版です。原文はこちら。 はじめにNutanix分散型ファイルシステム（NDFS）上では、仮想ディスク（vDisk）はクライアント（仮想マシンまたはコンテナ）がディスクの形態で利用できる、フラットな論理ストレージ空間です。このようなvDiskが各ノード上に複数存在し、I/Oを行うことで、クラスタの全リソースを効率的に利用できるようにシステムが設計されています。ですが、ユーザーのワークロードが、複数の仮想ディスク(vDisk)にまたがらない場合もあります。例えば、顧客がNutanixのハイパーコンバージド・プラットフォームに少数の巨大ボリュームを持つレガシー3層構成から移行したい場合、利用できるリソース（CPU、ディスク帯域、メモリ）があっても、ストレージサービスは最大のパフォーマンスを提供できない可能性があります。このようなユースケースは、リフト＆シフトのワークロードに限らず、以下のシナリオでも単一仮想ディスク(Single vDisk)のパフォーマンスが重要である考えてきました。アプリケーションが複数ディスクの使用をサポートしていない場合。 PoC時のベンチマーク・シナリオで、従来のシステムとNutanix HCIの仮想ディスクのパフォーマンスを比較する場合。 課題AOSのストレージは、Stargateと呼ばれる各々の仮想ディスク(vDisk)に対してコントローラーを保持するプロセスですべてのI/Oを管理しています。ワークロードでランダムにデータの読み取りを実行している間に、仮想ディスク(vDisk)コントローラは、CVM内の使用可能なCPUのキャパシティをすべて利用することはできず、単一のCPUへ制限されていました。仮想ディスクコントローラーは、設計段階でシングルスレッドとなっています。これによって、仮想ディスクコントローラーのコードをシンプルなまま、効率的に、vDiskをロック状態にすることなく、全てのデータ構造にアクセスできるからです。システム全体としての性能はvDiskの数によって拡張されますが、1台のvDiskの性能自体は単一のCPUコア/スレッドの性能によって制限されます。 ソリューションこの課題を克服するためには、単一

 本シリーズはNutanix本社のマーケティングチームが2022年の秋に投稿した記事の翻訳版シリーズです。上の画像でIDCが予測するように、2022年から2026年の4年間で生まれるアプリケーションの数は過去40年間かけて生み出されてきたアプリケーションの数に匹敵します。つまり、アプリケーションが生まれるスピードが10倍になっているのです。1年や2年に1回アプリケーションがアップグレードされるのではなく、アプリケーションは1-2ヶ月という頻度で更新されるようになります。このスピードに対応するためには5年に一度更新されるようなインフラストラクチャーでは間に合わなくなってきています。また、数週間に一度というアプリケーションのアップグレードにアプリケーションの停止を伴うようなアーキテクチャーもビジネス上許されなくなり、マイクロサービス型のアーキテクチャへと急速に移行していきます。この流れに対応するため、NutanixもHCIから(ハイブリッド＆マルチ)クラウドプラットフォームへと進化を続けています。これまでのNutanix HCIのメリット(メリット1-5)をベースのテクノロジーとして、マルチクラウド(メリット6,7)、クラウドDBaaS(メリット 8)、マルチプロトコルデータサービス(メリット 9)、そして何よりも重要なマルチクラウドセキュリティ(メリット 10)の提供とクラウドプラットフォームとして進化を続けています。 ぜひ復習として1-5、さらにクラウドとしてのNutanixとして6-10をぜひご確認ください。 Nutanixのメリット その 1: 動的に分散されたストレージ Nutanixのメリット その2: 自動化されたアプリケーションを意識したデータ管理 Nutanixのメリット その3: パフォーマンスとキャパシティのためのシームレスなクラスタ管理 Nutanixのメリット その4: きめ細やかで効率性の高いスナップショット Nutanixのメリット その5: エンタープライズグレードのレプリケーションとディザスタリカバリ Nutanixのメリットその6: ハイパーバイザーの選択肢 Nutanixのメリットその7: 自由なライセンスポータビリティ Nutanixのメリットその8: 統合されたセルフサービスでのデータベース管理 Nutanixのメリット その9

本記事はNutanixのTechnical Marketing Engineer – NCI & SecurityのEric Waltersが2022年10月13日に投稿した記事の翻訳版です。原文はこちら。  Nutanixのメリットシリーズを通して、Nutanixクラウドプラットフォームの多用途性、効率性、そしてレジリエンシーについてお伝えしてきました。このシリーズでは高いパフォーマンスとレジリエンシーを大規模環境においても実現するNutanixアーキテクチャのユニークな特性を取り上げてきました。エンタープライズグレードのレプリケーションと災害復旧(DR)と組み合わせ、Nutanixはお客様にハイパーバイザーの自由な選択肢とライセンスのポータビリティを提供できる優れたプラットフォームをご提供しています。加えて、Nutanixが単独のプラットフォームアプリケーションのニーズを満たす統合されたセルフサービスデータベース管理と完全に統合されたストレージをご提供することも確認してきました。これらのすべてのメリットは重要なものですが、昨今のようにエンタープライズにおいてセキュリティが最優先事項で語られるような状況においては、プラットフォームまたはデータがセキュアではない、ということになると、こうしたメリットは全て失われてしまいます。Nutanixはセキュリティを重要な要素として考え、レイヤー型アプローチでプラットフォーム、データ、そして最終的にはアプリケーションを網羅的に取り囲んで保護しています。 これから最もみなさまにとって重要なデータセキュリティについて掘り下げていきたいと思います。プラットフォームとアプリケーションのセキュリティの基本部分について取り上げていきますが、すべてを網羅するにはもう一つ別のシリーズが必要になってしまいます! プラットフォームセキュリティセキュリティは我々の Security development lifecycle (SecDL) プロセスを利用した開発のライフサイクルから始まります。  Nutanixはまた、セキュア構成管理および自動化(SCMA - Secure Configuration Management and Automation)でセキュリティベースラインを維持しており、自動的にセキュリティベースラインに合致しないあ

本記事は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のコントロールプレーンは利用しているハイパーバイザーに関わらず、一貫性を保っています。これはつまり、クラスタ、レプリケーション、運用、更にその他のNuta

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

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をク