Complete the 2024 IT Skills and Salary Survey and Enter to Win a $100 Gift Card!
Nutanixのハードウェアおよびソフトウェア製品に関するディスカッション。
本記事は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年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のキャパシティを超える
本記事は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
本記事は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ソリューションから最大の付加価値を迅速に、そして自身のニーズにあった幅広い購買モデルの選択肢とともに提
こんにちは3ノードで運用していましたが、1ノードが故障したため、4ノード目を追加したのち障害ノードを削除するつもりでした。しかし、ノード追加してクラスタ拡張は完了と出たものの、4ノード目が正常は追加されていないように見えます。cluster statusを見ると4ノード目はMedusa以降がすべてDownとなっています。4ノード目は、追加前にmanage_ovsで設定変更を実施した際にWARNINGが出ていて、これを解消しないままノード追加をしてしまったのが不味かったのかもしれないのですが、復旧できるでしょうか？ クラスタ拡張実施前に4ノード目で出ていたWARNINGは下記の通りです※全NICがbr0にアサインされている状態から、2nicのみbr0にしようとしましたnutanix@NTNX-51e75960-A-CVM:192.168.0.114:~$ manage_ovs --bridge_name br0 --bond_name br0-up --interface eth4,eth5 update_uplinks2024-04-13 12:40:07,181Z WARNING manage_ovs:1313 Failed to fetch gflags. Acropolis service might be down: HTTPConnectionPool(host='127.0.0.1', port=2030): Max retries exceeded with url: /h/gflags?show=hypervisor_username (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x7f2a15cfc4d0>: Failed to establish a new connection: [Errno 111] Connection refused',)).2024-04-13 12:40:07,182Z WARNING manage_ovs:1313 Failed to fetch gflags. Acropolis service might be down: HTTPConnectionPoo
Nutanix centralをインストールし、試しに、仮想サーバを「アクション」→「Quarantine VMs」→「厳格な」→「隔離」と設定したのですが、物理PCから当該仮想サーバにアクセスできてしまいます。（FTP、HTTP等）なお、物理PCと当該仮想サーバは同一セグメント（192.168.2.0/24）に存在します。flowは同一セグメントでも通信を制御（今回は遮断）できると思っていたのですが、この認識で会ってますでしょうか。また、同一セグメントにおいて通信制御はどのようにしたらいいのでしょうか。
本記事は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の可用性に
本記事は2018年6月11日に Josh Odgers 氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの牽引はこちら。 パート1から4をまだ確認していない場合はぜひご確認ください。これらは重要なレジリエンシーファクターの障害からの回復速度に関するもので、その場でRF2からRF3へ、もしくは同じ回復力レベルを提供しながら容量を節約するイレイジャーコーディング(EC-X)へと変換することで、回復力を向上させることについて解説しています。 パート5と6では、CVM のメンテナンスまたは障害時に読み取りと書き込みI/Oがどのように機能するか解説し、このシリーズのパート 7 では、ハイパーバイザー (ESXi、Hyper-V、XenServer、AHV) のアップグレードが読み取りと書き込み I/O にどのような影響を与えるかについて説明します。 この投稿ではパート5と6を頻繁に参照するので、このブログを完全に理解するには前の投稿をよく読んでください。 パート5とパート6で説明したように、CVM の状況に関係なく、読み取りおよび書き込み I/O は引き続き提供され、データは設定されたレジリエンシーファクターに準拠したままです。 ハイパーバイザーをアップグレードした場合、仮想マシンはまずノードから移行し、通常通りIO操作を続行します。ハイパーバイザーに障害が発生した場合、仮想マシンは HA によって再起動され、通常のIO操作を再開します。 ハイパーバイザー (またはノード) の障害またはハイパーバイザーのアップグレードのいずれの場合でも、最終的にはいずれのシナリオにおいても、仮想マシンを新しいノードで実行し、元のノード (下の図のノード 1) がオフラインになり、ローカルドライブ上のデータが一定の期間利用できなくなります。 このシナリオでは、読み取り I/O はどのように機能しますか? パート5での説明と同じ方法で読み取りはリモートで処理されます。または、2 番目のレプリカが仮想マシンが移行された (または HA によって再始動された) ノード上に存在する場合、読み取りはローカルで行われます。リモートでの読み取りが発生した際に、1MB のエクステントはローカライズされ、その後の読み取りはローカルで実行されるようになります。 書き込みI/Oはどうですか? パート6と同
お世話になります。 Nutanix3ノードで仮想基盤の構築を予定しています。(HVはAHV想定)その際に外部バックアップとしてバックアップソフトでの仮想基盤連携を行ったエージェントレスバックアップを取得しようと考えています。他の仮想化OSですとバックアップ用の管理ポートやバックアップサーバとの通信可能なIPを持たすことで管理ネットワークと分離したバックアップ構成を取ることが出来ますが、AHVやPrism Centralで複数ネットワークのIPを持たすことはサポートされていますでしょうか。またサポートされている場合は手順もご教示頂けると幸いです。構成:AHV 3ノード NCI Starter想定 Prism Centralは1台デプロイバックアップサーバ Windows OSで稼働しV社またはAr社のバックアップソフトを利用 V社の場合はProxyVMをデプロイするが、ProxyVMは管理IPと同じネットワークにデプロイされる(≒管理ネットワークでバックアップトラフィックが流れる)Ar社はProxyVMは不要だが管理IPを登録するため管理ネットワークにバックアップトラフィックが流れる。 よろしくお願い致します。
本記事はJarian Gibson氏の記事の翻訳版です。原文はこちら。 今日の分散された職場環境を考えると、あらゆる場所から生産的に働ける、アプリケーション、デスクトップ、そしてデータにセキュアにリモートアクセスができる職場環境を迅速に用意できる能力は必要不可欠です。直近の数ヶ月、増加したリモートワークの要件によって、IT部門は分散された職場環境のニーズを迅速にサポートすることにフォーカスを余儀なくされました。IT部門が増加した分散された職場環境のニーズのために迅速にインフラストラクチャを展開できるようにするため、組織はAWS、Azure、GCPやその他のパブリッククラウドの採用を増加させています。IT部門は分散職場環境のニーズを満たすための ハイブリッド そして マルチクラウド ソリューションを探し求めています。Nutanix ClustersはNutanixのクラウドOSであるAOSをパブリッククラウドのサーバー上で稼働させ、同じ管理プレーンを利用して、パブリッククラウドにネイティブに統合されたシームレスなハイブリッドクラウド環境を実現します。 Nutanixはお客様の選択肢と Citrix Virtual Apps and Desktops が稼働するハイブリッドクラウド環境を実現します。Nutanix Clusters上のCitrix Virtual Apps and Desktopsによって、IT部門はCitrixワークロードのための迅速な分散された職場環境のサポートを実現することができます。この共同ソリューションによって、お客様は、これまでデータセンター内で提供していたのと同じ機能をクラウド内で実現することができます。 Nutanix Clusters上のCitrix Virtual Apps and Desktopsでは既存のNutanixのお客様は慣れ親しんだ同じ管理インターフェイスを提供します。Nutanix Clusters上のCitrix Virtual Apps and Desktopの管理はオンプレミスのNutanixインフラストラクチャ上での管理と見分けがつきません。実際のところ、オンプレミスのNutanixを管理するのに利用している同じPrism Centrarlインターフェイスを利用して、Nutanix Clustersを管理します。
皆様こんにちは。ヴィームソフトウェアの斉藤と申します。Veeamに関するフォーラム寄稿の第3弾となります。前回にも記載しましたが、まずは以下4回に分けてトピックをお伝え致します。 ・Vol.1 Veeam Software会社紹介とラインナップ+ライセンス ・Vol.2 Veeamのバックアップについて ・Vol.3 Nutanix Mine "with Veeam"について（今回のトピック） ・Vol.4 クラウドやKubernetes環境のバックアップについて Nutanix Mine with Veeamのはじまり Nutanix Mineはご存知のとおりNutanixポートフォリオの一環として発表されたソリューションになります。“Mine”と言う英単語を聞くと私はまず「マインスイーパー」を思い出しますが、そのMineとは全く異なります。Mineにつけられたアイコンをご覧ください。ダイヤモンドが記載されています。つまり「鉱山」という定義が正しく、その心としてバックアップデータの中にあるダイヤモンドを掘り起こそう！というニュアンスが込められています。ゲームで言うと、「マインクラフト」が正解という事になります。ひょっとしたら「私のもの (mine)」といった副次的意味合いも含まれているかもしれません。参照先: https://www.nutanix.com/jp/products/mine そんな期待を込めてリリースされたNutanix Mineは、Nutanix プラットフォームの上でバックアップソフトウェアが稼働する統合型ソリューションとなります。稼働するバックアップソフトはNutanix プラットフォーム理念を継承し、マルチベンダ仕様となっており現在はHYCUとVeeam Softwareが選択可能となります。弊社がその一つとして選ばれたのが2年前の2019年5月になります。 参照先: https://www.veeam.com/jp/news/nutanix-mine-with-veeam-simplifies-secondary-storage.html Nutanix Mine with Veeamの提供価値 「NutanixのバックアップだったらやっぱりHYCUじゃないの？」と思う方もいらっしゃるかもしれません。確かにHYCUはNutanixと
本記事はNutanixのSenior Technical Marketing EngineerのBhavik Desaiが2022年8月18日に投稿した記事の翻訳版です。原文はこちら。 このシリーズのこれまでの2つの記事では、Nutanix AOSが自動化されたアプリケーションを意識したデータ管理を実現する、動的な分散されたストレージをどのように提供しているのか、ということについて掘り下げてきました。今回の記事では、これらの2つの機能が、管理者がクラスタに更に物理ノードを追加して拡張をしなければならない場合に、どのように強力なメリットをもたらすのかについて見ていきましょう。 パフォーマンスとキャパシティのためのクラスタ管理展開が終われば、インフラストラクチャーとアプリケーションの日々の運用が重要になります。Nutanix AOSは管理者の行うライフサイクル管理を簡単かつシームレスなものにします。すべての管理者が行わなければならない重要なタスクの一つにストレージもしくはパフォーマンスのためのインフラストラクチャーの拡張があります。管理者は通常、最初は均一なクラスタを展開することから始めることになりますが、アプリケーションが成長するにつれて、よく発生するユースケースがクラスタへのさらなるキャパシティの追加です。管理者は多くのストレージキャパシティを持つノードや、アプリケーション仮想マシンを動作させないストレージオンリーノードを含む様々なタイプのノードを追加するという選択肢があります。AOSはこの部分をその動的なクラウドアーキテクチャーで劇的にシンプルにすることができます。一度ノードが追加されると、アプリケーションは他のHCIシステムのように何らかの介入を必要とすることなく、即座にその追加されたリソースを活用することができます。これはAOSが書き込みを行うデータが最適なサイズであることと、動的に自律化されたWriteを行うことで可能となっています。AOSは自動的に新たなリソースを利用し始め、マニュアルでの介入を行うことなく、書き込みのコピーデータは新しいノードへと送信されます。それに加えて、AOS内のCuratorフレームワークがディスクのリバランスをバックグラウンドオペレーションとして開始させ、自動的にクラスタのバランスを調整します。以下の例で大容量のノードをクラスタ
本記事は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に渡されます。 表：書き込みのバースト
本記事はNutanixのSVP Product and Solutions MarketingのLee Caswell氏が2022年9月22日に投稿した記事の翻訳版です。原文はこちら。 ベイエリアに雨が降ると、それはスキーシーズンがさほど遠くないということの現れです。この何年かはダウンヒルの愛好家は場所が定められた一つのリゾートのパスだけに制限を受け、多くの人がフラストレーションを感じ、また前もっての計画と確定を余儀なくされていたのでした。スキーヤーは今日、全米、もしくは世界中のスロープを滑走できる新たなマルチリゾートのセレクションパスを選ぶことができるようになりました。この記事はNutanixがマルチリゾートパスと同様に展開しているポータビリティがどのようなものなのか、そして、それがITマネージャーの、時とともに変わり続けるアプリケーションのニーズを満たすために、様々な場所、そしてハイブリッドにクラウドインフラストラクチャーを構築する手助けしてくれるのかについてのものです。 ポータビリティの価値パフォーマンス、コスト、そして支配権についての心配が、ITマネージャーにどこにアプリケーションを配置するのかという課題を幾度となく投げかけます。しかし、これは簡単になしうることではありません。特にクラウドのリソースの追加とエッジで予測されている成長を鑑みるとなおさらです。実際、Gartner®は2027年までに2022年に配置された85%のワークロードの場所が要件の変化によって最適ではなくなる¹ 予測しています。クラウド、マルチクラウド、そして成長を続けるエッジでは拡張が起きています。時の流れの中でどこにアプリケーションとインフラストラクチャーを提供するのかという柔軟性の価値はその場所の選択肢が拡張されるにつれて大きくなっていきます。アプリケーションのモビリティ提供するためには、柔軟性を持ったインフラストラクチャーが必要不可欠なのです。幸運なことに、モダンなハイブリッドクラウドはサーバーインフラストラクチャー上で標準化されており、Nutanixはサーバーベースのハイブリッドクラウドをまたがった完全なソフトウェアスタックのポータビリティを実現しています。オンプレミス環境をお持ちのお客様はそのリソースをパブリッククラウドへまたはエッジへと要件の変化に合わせて移動させることがで
本記事は 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ランタイムプロバイダ向けの統合オープンソースク
기존 클러스터에 새 노드를 추가할 계획입니다.확장 전에 새 노드 AOS(베어 메탈 설치)가 시작됩니다.기존 버전과 새 AOS 버전이 다른 경우 문제가 있을 수 있습니까?(AOS 나는 당신이 같은 일을하고 싶습니다,하지만 불가능한 경우)전) 기존 클러스터 AOS 5.10.9 / 새로운 노드AOS 5.15.x 감사합니다.
