• 200 Topics
  • 215 Replies

200 Topics

読み取りI/Oパスの比較 - Nutanix vs VMware vSAN

本記事は2020年3月2日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 本シリーズではこれまでにNutanixでは重複排除や圧縮はもちろんのこと、イレイジャーコーディングを利用した場合であったとしても、より高い容量効率、柔軟性、回復力、そして性能をより多くの利用可能な容量とともに、ご提供できることを学んできました。 更に、Nutanixは遥かに簡単に優れたストレージの拡張性を提供でき、ドライブ障害の影響を劇的に低減できることも学んできました。 そこから我々はギアを変え、混在クラスタのサポートについて取り上げ、これがなぜHCIプラットフォームの拡張能力、そして完全な置き換えや新たなサイロを作ることなくより強力なROIを実現に重要であるかを学びました。 前回は、書き込みI/Oパスの比較について学習し、クラスタ内のVMの現在の場所とパフォーマンス/容量の使用率に基づいた、データをインテリジェントに配置するNutanix独自のデータローカリティの多くの長所を取り上げました。 今回は、vSANとNutanix ADSFの読み込みI/Oパスの比較について詳しく説明します。 vSAN読み取りI/O パス:書き込みI/Oパスの比較で学んだように、vSAN I/O パスの最良のシナリオは、VMが作成されたホストから移動していないか、偶然にもオブジェクトが存在するホストにVMが存在する場合です。その場合、ローカルのデータオブジェクトと、回復力のために別のホストにリモートなデータオブジェクトを持つことになり、IOパスは最適になります。 シナリオ1: vSANvSANの最適な読み取りI/Oパス ローカルにホストされたオブジェクトを利用ここでは、すべてのデータがローカルでホストされているため、100%の読み取りをローカルで提供できるように見えます。 しかし、vSANはこのような動作はしません。vSANの読み取りは、すべてのオブジェクトに対する「ラウンドロビン」方式で実行されます。つまり、オブジェクトがVMにローカルであるという最良のシナリオでも、FTT1の場合で読み取りの50%、FTT2の場合は読み取りの66%がリモートから提供されるのです。 シナリオ2: vSANシナリオ1でVMをノード2にvMotionしてみましょう。vSANの 最適な読

Nutanix と HPE が統合されたハイパーコンバージドインフラストラクチャアプライアンスを提供

本記事はMarc Trouard-Riolleが2019年8月1日に投稿した記事の翻訳版です。 原文は[url=https://www.nutanix.com/blog/nutanix-and-hpe-deliver-integrated-hyperconverged-infrastructure-appliance]こちら[/url]。 [code].NEXT JapanでもHPE ProLiand DXのセッションが予定されています。 NTX-29 14:55-15:35 パートナー 同時通訳同時通訳 ついに出た!Nutanix on HPE DX:技術詳細から見積もりのコツ、おススメの売り方まで徹底解説 ※販売パートナー様限定(本セッションの受講にはNDAを含む有効なパートナー契約が必要となります。) Nutanix, Inc. ベン・ウィー・ゴー ニュータニックス・ジャパン合同会社 小林 正和 HPE + Nutanixソリューションがいよいよ始まります! HPE ProLiant DX アプライアンス ファミリーの詳細をご紹介。 クオリティの高いHPE ProLiantをベースにNutanixを組み合わせ、HPEを好まれるお客様にもお勧めしやすいソリューションが提示可能となります。技術的な詳細から、価値提案、見積もり方法まで、詳しく解説いたします。 [/code] 2019年の4月、NutanixとHPEは統合されたハイブリッドクラウド・アズ・ア・サービス(aaS)ソリューションを市場へ投入するこという[url=https://www.nutanix.com/press-releases/2019/hpe-nutanix-sign-global-agreement-deliver-hybrid-cloud-service]あらたなグローバル・パートナーシップをアナウンス[/url]しました。この合意によってNutanixのチャネルパートナーは直接HPEベースのアプライアンスとNutanix Enterprise Cloudソフトウェアと共に販売することができるようになります。 Nutanixはこの先のさらに次なるステップとして[url=https://www.nutanix.com/viewer?type=pdf&path=/cont

Nutanix HCI上でRed Hat OpenShiftをはじめよう

本記事はNUTANIX.DEVにMark Ravi氏が2021年10月26日に投稿した記事の翻訳版です。原文はこちら。  このブログシリーズでは実稼働環境グレードのNutanix AHVクラスタ上でのRed Hat OpenShiftのKubernetesを検討そして提供しているIT、DevOps、そしてシステム管理者へ向けたガイダンスを提供したいと考えています。 クラウドネイティブなデジタルトランスフォーメーション アプリケーションの物理サーバーから仮想ワークロードへの移行がこの20年にわたって続いてきましたが、仮想マシンからコンテナへの移行は始まって10年にもなりません。コンテナとしてアプリケーションをモダナイズさせて稼働させるためには新たなツールが必要になり、オープンソースのKubernetes project が次々に非常に広範なコンテナ管理システムを生み出してきています。  Kubernetesはクラウドネイティブな機能、アーキテクチャ、そして運用を提供しますが、それには新たなスキルセットが必要になり、そして迅速なソフトウェアのアップデートとパフォーマンスの拡張性のメリットを享受しようと考える従来型の組織にとって破壊的な変化を迫ります。Linuxオペレーティングシステムと同様に、Kubernetesには多くのディストリビューションが存在し、Red HatのOpenShift はハイブリッドクラウドをまたがった一貫性をもつ基盤とともに、アプリケーションをビルド、展開、稼働させるための市場を牽引するプラットフォームを提供しています。Red Hat OpenShiftにはOTA(over-the-air)アップデート、コンテナランタイム、ネットワーク機能、イングレス(Ingress)、監視、ロギング、コンテナレジストリ、そして認証、認定ソリューションが含まれています。  Nutanixはシンプルさ、拡張性そしてハイブリッドクラウドインフラストラクチャを提供しつつ、ストレージ、コンピュートそしてネットワークリソースおよびサービスの1-クリックアップグレードをお望みのハードウェア、パブリッククラウドそしてサービスプロバイダー上の環境で提供します。Red Hat OpenShiftをNutanix上で稼働させることで、フルスタックの、エンタープライズ向けにサポートされ

1-クリックの進化...

本記事はPrincipal Product ManagerのCameron Stockwellが2019年6月7日に投稿した記事の翻訳版です。 原文は[url=https://www.nutanix.com/blog/evolution-of-1-click.html]こちら[/url]。 数週間前のアナハイムでの.NEXTカンファレンスのキーの戸で、Dheerajは大きくなった我々のポートフォリオとともに、アップグレード管理についての課題についてハイライトし、それでも我々は運用をシンプルに維持し続ける苦労について述べました。 「我々は5,6年前は2つのものをアップグレードしていればよかったのです - AOSとPrism - これは成長におけるパラドックスです -- 成長は複雑さを生み出します。そして複雑さは成長を殺していまいます。」[img]https://d1qy7qyune0vt1.cloudfront.net/nutanix-us/attachment/6b3b6440-decf-47e7-940b-103d9e0030be.png[/img] 「アップグレードについて一般的には、30分程度しかかかっていなかったアップグレードが大規模なクラスタを持つお客様にとっては4〜5時間もの時間を要するようになってきている。 しかし、これは非常に大きな責任が伴う。すべてのサーバ、ファームウェア、ハイパーバイザー、全てについて考慮しながら、なおもダウンタイムを伴わずに実行しなくてはならない。」 [img]https://d1qy7qyune0vt1.cloudfront.net/nutanix-us/attachment/43f43467-09d9-4ebb-b25f-c614c6acde25.png[/img] 「このカンファレンスは皆様が言う「最も複雑なことを素晴らしくやってのけるとはどういうことか?」ということに対するものになっています。もはや我々のキャンバスは5年前にそうであったようにシンプルなものでは、もはやなくなっているからです。 我々のキャンバスはより複雑なものになっており、そして、Nutanixに課せられたバーはこれまでと同じような素晴らしさを既存のお客様、そしてこうした複雑さを実際には見ることのない新しい我々のお客様に対してご提供するというものに

異なるモデルでのクラスタサポート - Nutanix vs VMware vSAN

本記事は2020年2月26日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 このシリーズでは、重複排除と圧縮、およびイレージャーコーディングを使用する際に、Nutanixがより多くの使用可能な容量を提供するとともに、より大きな容量効率、柔軟性、回復力、およびパフォーマンスを提供することを学びました。また、Nutanixははるかに簡単で優れたストレージのスケーラビリティを提供し、ドライブの障害による影響を大幅に軽減していることも知りました。このパートでは、異なるモデルで構成するクラスタのサポートについて説明します。これは、HCIプラットフォームの拡張機能にとって非常に重要であり、絶えず変化するユーザーの要件を満たす/それ以上を提供するということを学んでいきます。ハードウェアのキャパシティ/パフォーマンスは非常に速いペースで進歩し続けており、ユーザーが一様な(同一スペックのノードによる)クラスタを使用することを余儀なくされた場合、TCOは上がり、投資の回収に多くの時間を必要とする可能性があります。これだけでも好ましくない事態ですが、それだけでなく、ユーザーが非効率的なサイロを作らなければ、新しいハードウェアの性能や集約のメリットを活かせなくなることを意味します。つまるところ、古いSAN時代のように、ハードウェアを「総入れ替え」する必要があるような状況にはなりたくありません。それでは、簡単な「チェックボックスの比較」から始めてみましょう。 サポートされているクラスタのノード構成 Nutanix VMware vSAN Heterogeneous(異なるモデルノード混在構成) Homogeneous(同一モデルノードのみの構成) 以前にも私が記事で強調したように "チェックボックス "スタイルの評価は、一般的に製品の機能についての誤った理解につながることを述べました。今回の記事は、この("チェックボックス "スタイルの)評価における問題のまさに典型的なモデルで、簡単な例を挙げてみます。 再びDellEMCが推奨するハードウェアプラットフォームであるVxRail E-Seriesの4ノー

Nutanix AOS 5.11登場!

本記事は2019年8月5日にProduct Marketing Lead HCI CoreのMayank Guptaが投稿した記事の翻訳版です。 原文は[url=https://www.nutanix.com/blog/aos-5-11-is-here]こちら[/url]。 Nutanix [url=https://www.nutanix.com/blog/nutanix-aos-5-9-is-here]AOS 5.9[/url]は遡ること2018年10月にリリースされ、そのフォーカスは、より機能を増したソフトウェアベースの暗号化で既存のクラスタ内のデータをセキュアにすることや、ラックの障害に対応するためのアベイラビリティゾーンの機能向上、更にはDRのためのニアシンクへの機能向上でデータの保護や弾力性についてのものでした。 それ以降、我々Nutanixは絶え間なくNutanix HCIプラットフォームのコアを強化すべく活動を続け、AOSの5.10と5.11をリリースしました。AOS 5.10は2018年の12月にリリースされたもので、今回はAOS 5.11のリリースとそれが[url=http://portal.nutanix.com/]ポータル[/url]からダウンロードできるようになったことをお知らせできることを大変喜ばしく思います。 この2つのリリースは共にコアであるAOSのストレージパフォーマンス、ストレージキャパシティ、データ保護、セキュリティ、そしてクラスタのライフサイクル管理機能を向上させるものです。今回の記事では主な機能のうちのいくつかを取り上げたいと思います。機能向上についての完全なリストについては[url=https://portal.nutanix.com/#/page/docs/details?targetId=Release-Notes-Acr-v510:Release-Notes-Acr-v510][u]リリースノート[/u][/url]をご参照ください。 [h2][b]パフォーマンスと拡張性[/b][/h2][h3]ストレージQoS[/h3]Nutanix AOSのアーキテクチャにはすでにノイジーネイバー(やかましいお隣さん)から保護のためのQoSの機能が組み込まれています。AOS 5.11では、エンドユーザーによるストレージのサ

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

本記事は2019年8月7日にGreg White氏、Kong Yang氏、Adrian Finch氏が投稿した記事の翻訳版です。 原文は[url=https://www.nutanix.com/blog/next-frontier-invisible-licensing-for-robo-vdi-environments]こちら[/url]。 [img]https://d1qy7qyune0vt1.cloudfront.net/nutanix-us/attachment/83a96a65-c9cd-4609-9d8b-58144c43b9f4.png[/img] Nutanixは継続的にITがよりビジネスへと付加価値を提供できるようにするためのシンプル化に取り組んでいます。まず最初に我々が行ったことはインフラストラクチャをインビジブルにすること、そしてデータセンタ、現在はクラウドです。続いてライセンシングに取り組むべきというのは非常に論理的ではないでしょうか?うーん、ちょっと言いすぎかもしれませんが、それ以外の件と同様に我々はライセンシングからも複雑さを取り除きたいのです。 Nutanixは特定のユースケースについてキャパシティベース(CBL)とアプライアンスライセンシング以外の新しい選択肢となる利用モデルを導入し、様々なNutanixソフトウェアの利用をシンプルに計画、価格、購入を実現する方法をご提供します。2つの新しいユースケースは仮想デスクトップインフラストラクチャ(VDI)とリモートオフィス/ブランチオフィス(ROBO)環境です。 [h2] [/h2][h2]新しい利用モデルとはどのようなもの?[/h2]この消費モデルは幾つかのNutanixソフトウェアソリューションを一緒に「ライセンシング」するモデルで、これによってハードウェアとソフトウェアの購入は分離されることになります。これによって、インフラストラクチャのニーズに基づいてどこに、どのようにNutanixソフトウェアを展開するかという点で、大きな柔軟性が実現されることになります。それぞれのモデルはAOS、AHV、Prism Starterを含んでいます。 [list] [*]VDIについてはこのライセンスモデルはVDI per userと呼ばれ、同時ユーザー数をベースとします。 [*]ROBOにつ

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

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

ストレージのアップグレード比較 - NutanixとVMware vSAN/VxRAILの比較

本記事は2020年3月11日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 このシリーズでは、重複排除と圧縮、およびイレイジャーコーディングを使用する際に、Nutanixがより多くの使用可能容量を提供し、容量効率性、柔軟性、回復力、およびパフォーマンスを向上させることを学んできました。 また、Nutanixははるかに簡単かつ優れたストレージのスケーラビリティを提供し、ドライブやノードの障害による影響を大幅に軽減していることもわかりました。 このパートでは、NutanixのAOS(Acropolis Operating System)とVMwareのvSAN(Virtual SAN)における、ストレージ層のアップグレードなど、Day 2 オペレーションで重要となるトピックを取り上げます。 双方のプラットフォームでどのようにアップグレードが実行され、これらのアップグレードが環境にどのような影響を与えるかを議論していきます。 まずは単純な「チェックボックスの比較」から始めてみましょう。 アップグレード Nutanix VMware vSAN 停止を伴わないストレージのアップグレード ✅ ✅ 以前の記事でも強調しましたが、「チェックボックス」スタイルのスライドは、製品の能力に関するミスリーディング引き起こしがちです。この問題は、アップグレードなどのDay 2 オペレーションについても大いに当てはまります。 簡単な例を挙げてみましょう。 例1:AOSやvSANの新バージョンへのアップグレードチェックボックスの比較を見ると、両製品とも"停止を伴わないストレージのアップグレード"ができることがわかります。この議論のために、以下のシンプルな定義を使用します。 「停止を伴わないストレージのアップグレード」とは、仮想マシンが停止することなく、ソフトウェア定義ストレージ層のアップグレードを実行できることです。 NutanixとvSANの双方において、仮想マシンが停止することなくアップグレードを実行できるのは事実ですが、仮想マシンとクラスタの可用性/パフォーマンスとデータの整合性にはどのような影響があるのでしょうか? Nutanix のクラウド時代のハイ

HYCU for Nutanix on VMware ESXi

こんにちは、HYCU(ハイク)の吉田です。 当ブログは2020年7月16日にHYCUのエンジニアリング部門のVPであるGoran Garevskiのブログの翻訳版になります。原文はこちら VMware ESXiを使用するNutanix環境において、HYCUがVMバックアップにストレージレベルのスナップショットを活用する、唯一のバックアップベンダーだとご存知ですか? HYCUだけと言うのが信じられないように聞こえますが本当です。HYCUはNutanix APIに完全に統合することにより、Nutanix AHVとESXiの両環境において、VMバックアップ時に効率的なNutanix redirect-on-writeスナップショットを活用します。これによりVMスタンを回避し、ビジネスアプリケーション/サービスに影響を与えることなく、煩わしさを完全に排除したバックアッププロセスを実現します。残念ながら、HYCU以外のベンダーでは、Nutanixの優れた機能(およびAPI)を活用することなく、NutanixのストレージをただのJBODとして扱っているようです。(Nutanix redirect-on-writeスナップショット関する説明は、今回のブログでは割愛させて頂きます。) 典型的な以下のような事象を経験したことはありますか? 最新のハイエンド・ストレージをVMware vSphereに接続していた時代、ストレージレベルのスナップショットをサポートしていなければ、有効なバックアップソリューションではありませんでした。VMware vSphere環境では、これらの事象が発生していましたが、もうだれも経験したくないでしょう: VMがバックアッププロセス内で応答しないため、本番アプリケーションのフェイルオーバーが発生 ビジネスサービスがダウンしているか、システムがユーザーに応答していない 障害発生時、バックアップベンダーとVMwareが責任の押し付け合い 要約すると、VMware vSphere環境ではバックアップ中に仮想マシンが気絶(停止)するような事象が発生します。これをVMスタンと呼んでいますが、VMスタンはVADP APIに関連するバックアッププロセス中に発生します。 このVMスタンは、多くの恐怖を感じる事象に発展する可能性があり、最終的にはビジネスアプリケーションとサ

メモリ利用量の比較 – Nutanix ADSF vs VMware vSAN / DellEMC VxRAIL

本記事は2020年4月1日にJosh Odgers氏が投稿した記事の翻訳版です。 原文はこちら。本シリーズの索引はこちら。  本シリーズのパート1、vSAN/VxRailとNutanixの利用可能な容量において、Nutanixがより多くの利用可能な容量とともに、重複排除と圧縮はもちろん、イレイジャーコーディングを利用した場合にもより優れた容量の効率、柔軟性、回復力、そしてパフォーマンスを提供することを学びました。また、DellEMCが「大規模なワークロード向けに最適化したハイパフォーマンスノード」と謳うDellEMC VxRAIL P-シリーズと同等のノードを利用したもう一つ別のvSAN/VxRAILとNutanixの利用可能な容量の比較についてもご披露いたしました。その結果は驚くべきものではなく、Nutanixでは18.38TB(〜16%)も多くの利用可能な容量を4ノードのソリューションで提供しており、それが8ノードに拡張された場合には77.925TB(〜31%)で圧勝してしまうというものでした。メモリの利用量についての話題は、比較的容易で(一方で、よく誤解や誤記を目にします)NutanixのCVMは静的な容量のメモリで構成された仮想マシンであるという比較になります。 標準では、Nutanix CVMは最小のノードでの24GBからノードでアグレッシブなリカバリ目標時点(RPO)を想定した場合で最大40GBの間となりますが、そうでない場合は32GBです。vSAN/VxRAILの場合、VMwareは「ESXi 6.0 U3,6.5.0d以降のvSANのメモリ消費を理解する」というタイトルのナレッジベースの記事を公開し、更新しています。この記事では様々な例をあげており、最初の例は小さな1つのディスクグループのハイブリッド構成であり、その環境ではvSANのために16.478GBが必要となっています。 例1: ホストあたり1つのディスクグループ、ハイブリッド構成::公式:HOST_FOOTPRINT + ( NumDiskGroups * ( DISKGROUP_FIXED_FOOTPRINT + DISKGROUP_SCALABLE_FOOTPRINT + ( CacheSize * CACHE_DISK_FOOTPRINT) + NumCapacityDisks * C

ServiceNowとNutanixの統合

本記事は2019年10月9日にPaul Harbが投稿した記事の翻訳版です。原文はこちら。 Nutanixはエンタープライズの企業がパブリックとプライベートクラウド間のシームレスなエクスペリエンスを提供する完全なハイブリッドクラウド環境を必要としていると認識しています。Nutanixはイノベーティブな100%ソフトウェア定義のハイパーコンバージドインフラストラクチャとマルチクラウドサービスで業界をリードしており、お客様は規模を伴う環境の展開や自身のIT運用環境との統合の必要性を感じています。Nutanixはその豊富なAPIとX-Playのような製品におけるイノベーションによってこうした統合を実現しています。こうした領域において、我々はServiceNowとのより深く密な連携と、シームレスなIT運用とエンドユーザーエクスペリエンスを提供することにおいての戦略的なパートナーシップをアナウンスできることを誇らしく思います。我々の技術チームはServiceNowのSaaSサービスとNutanixインフラストラクチャの統合を実現するにあたり、彼らと非常に密に連携し、以下の領域にフォーカスしてきました:ServiceNOW CMDBのNutanixハイパーコンバージドインフラストラクチャの検知とモデリングでの統合 ServiceNowのイベント、インシデントとNutanixのアラートの統合、及びX-Playによるその修復 ServiceNOWのリクエスト管理とNutanix上にホストされている場合のCalmプラグインによるその対応図 1: Nutanix と ServiceNOW の統合フロー なぜこれが重要なのか?組織のIT環境がより大規模に、そして幅広くなっていくにつれて、ITプロセスはより確固たるもので、リスクを最小化、管理できるようなものを望むようになります。全てのエンドユーザーがITサービスを利用するにあたってよりシンプルな、単一窓口での方法を模索するようになり、全てを自動化したいと望むようになります!多くのプラットフォームが混在する状況において、ServiceNOWはそれら全ての集合地点であり、IT組織は1つの組の手順で、あらゆるプラットフォーム向けの普段利用するすべての承認フローをここにまとめようとしています。会社の収益や、人々の生活、金融市場への影響があるような

Nutanix Bucketsとコンテナ化されたアーキテクチャ

[img]https://d1qy7qyune0vt1.cloudfront.net/nutanix-us/attachment/d8b24279-cf03-4f1a-ac2f-d45737c53a38.png[/img] 本記事はNutanixのTechnical Marketing ManagerのLaura Jordanaの記事の翻訳版です。2019年4月2日に投稿された原文は[url=https://next.nutanix.com/blog-40/nutanix-buckets-and-containerized-architecture-32020]コチラ[/url]。 今後予定されているNutanix BucketsはNutanixの製品ポートフォリオにネイティブなオブジェクトストレージソリューションを登場させることになります。このオブジェクトストアは他のNutanixのコアサービスと同じPrismユーザーインターフェイスから展開、管理されるもので、S3-互換アプリケーションからアクセスすることができます。Nutanix Bucketsはオブジェクトストレージでは一般的なHTTPとHTTPSのS3 REST API(GET、PUT、POST、DELETE、そしてLIST操作を含む)と互換性があります。つまり、オブジェクトストレージへのアクセスにS3コールを利用するあらゆるアプリケーションがNutanix Bucketsを追加のアプリケーションやコードの変更なくそのまま利用することができるということです。 Nutanix BucketsはCVM内もしくは特別な仮想マシンとして実装されている他のいくつかのサービスとははじめから異なる設計が行われており、コンテナ化されたプラットフォーム上にサービスを展開します。このプラットフォームはKubernetesをベースとしており、Bucketsに関連するすべてのサービスはKubernetesクラスタ内のコンテナとして動作しています。これによりBucketsは展開、アップグレード、拡張性において根本から柔軟なものとなっています。例えば、ちょっとしたリリースに際して、Bucketsサービス全体をアップグレードするのではなく、対象となるマイクロサービス(コンテナとして動作しています)のみをアップグレードするだ

クラウドファーストはしばしば間違い、その理由は?

本記事はJohn Williamson氏が2019年6月14日に投稿した記事の翻訳版です。 原文は[url=https://www.nutanix.com/blog/cloud-first-is-often-a-mistake.html]こちら[/url]。 いくつかの企業にとって「クラウドファースト」ポリシーは疑いようのないものとして捉えられており、特に従来型のデータセンタインフラストラクチャのぬかるみと比較した場合にそれは顕著です。しかし、今日ではハイパーコンバージドインフラストラクチャ(HCI)のような新たなソフトウェア・ディファインド・データセンタソリューションがITの俊敏性を提供しながら、一方でパブリッククラウドで利用可能なものよりもより優れたセキュリティと統制を提供しています。驚くかもしれませんが、多くの人々がパブリッククラウドを利用する主な動機はそのコストであるということを述べますが、そうした事実を他所に、殆どの場合では、[url=https://www.nutanix.com/products]Nutanix Enterprise Cloud[/url]のようなオンプレミスのHCIソリューションのコストよりも劇的に高いのです。 [url=https://www.nutanix.com/go/multicloud-architectures-empower-agile-business-strategies]IDCが公開した調査によると[/url]、エンタープライズのワークロードの殆どを占めている負荷の予測が可能なワークロードにおいては、パブリッククラウド上でこれを動作させるコストはオンプレミスのNutanixで動作させる場合と比較して平均して2倍ほどになるということです。そして、2018年のIDCの[url=https://www.idc.com/getdoc.jsp?containerId=US44185818]Cloud Repatriation Accelerates in a Multicloud World[/url]と銘打たれた調査によると、80%もの組織がパブリッククラウドからオンプレミスへとアプリケーションを回帰させており、今日インストールされている50%のパブリッククラウドアプリケーションは今後2年間のうちにオンプレミスへ回帰す

Nutanixの回復力 - パート 6 - CVMのメンテナンスや障害時のWrite I/Oについて

 本記事は2018年6月8日に Josh Odgers 氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの牽引はこちら。 パート5では、CVMのメンテナンスや障害時のI/Oの処理方法について説明しましたが、今度は同じメンテナンスや障害シナリオでWrite I/Oを処理するという、間違いなくより困難で重要なタスクを説明する必要があります。パート5をお読みになった方であれば、この次のセクションがよくわかると思います。パート5を読んでいない方は、ぜひ読んでいただきたいのですが、ここではNutanix ADSFがどのようにデータを書き込み、保護するのかという基本的なことを簡単に説明します。 以下の図を見ると、3ノードのクラスターに1台の仮想マシンがあります。仮想マシンはa,b,c,dで表されるデータを書き込んでいます。通常の状況では、すべての書き込みは、1つのレプリカが仮想マシンを実行しているホスト(この場合はノード1)に書き込まれ、他のレプリカ(RF3の場合は1つまたは複数)はディスク適合性の値に基づいてクラスター全体に分配されます。ディスクの適合性の値(私は「インテリジェント・レプリカ・プレースメント」と呼んでいます)は、容量とパフォーマンスに基づいて、データが最初から最適な場所に配置されることを保証します。  クラスターに1つ以上のノードが追加された場合、インテリジェント・レプリカ・プレースメントは、クラスターがバランスの取れた状態になるまで、それらのノード数に比例して多くのレプリカを(分散して)送信します。万が一、新たな書き込みが発生しなかった場合でも、ADSFにはバックグラウンドでディスクバランスをとるプロセスがあり、低い優先度でクラスター内のバランスをとります。 Nutanixが複数のレプリカを使用してデータを保護する方法(「レジリエンシーファクター(RF)」と呼ばれるもの)の基本がわかったところで、Nutanix ADSFストレージ層のアップグレード時に何が起こるかについて説明します。 アップグレードはワンクリックで開始され、設定されたレジリエンシーファクター(RF)やイレイジャーコーディング (EC-X) の使用の有無に関わらず、一度に1つのコントローラVM (CVM)をローリング方式で実行します。ローリングアップグレードでは、一度に1つのCVMをオフ

パブリッククラウドの課題 – パート1:ネットワークパフォーマンス

本記事はJosh Odgers氏の記事の翻訳版です。原文はコチラ。本シリーズの索引はコチラです。 AWS EC2などのパブリッククラウド製品は「ベアメタル」サーバーをレンタルする機能を長年提供しており、顧客やパートナー企業はこの機能を利用することで、それぞれ選択したワークロードやソリューションをデプロイしています。追加のハードウェアはスタンバイ状態になっており、これまでと比べ短時間でのデプロイが可能なため、ハイパーコンバージド・インフラストラクチャー(HCI)ベンダーは、オンプレミス環境よりもさらに柔軟にオンデマンドで拡張できる形でベンダーのソリューションを提供できるようになりました。AWS EC2などのサービスは、ベアメタルインスタンス当たりの接続数や使用可能な帯域幅に関して、顧客がネットワークをほとんど制御できない点が課題となります。例えば、よく使用されているi3.metalインスタンスには、36個の物理CPUコア、512GBのメモリー、および25ギガビットネットワーク(公表値)が、8本の1.9TB NVMe SSDとともに含まれています。参照: https://aws.amazon.com/ec2/instance-types/i3/この構成は、Nutanixのような高度なHCIソリューションには最適ですが、ネットワークへの依存度が高いvSANのような製品にはそれほど適していません。「25ギガビットネットワーク(公表値)」とした理由実際に25Gbpsが使用可能なわけではないためです。使用できるのは、i3.metalインスタンスが同じ1台のラック内に配置されている場合は接続当たり最大10Gbps、複数のラックにまたがって配置されている場合は最大5Gbpsです。以下の例は、最新のアイドル状態のクラスターでテストした結果、AWS EC2で大きなばらつきが発生するということを示しています。次に、HCIソリューションをAWS EC2にデプロイした場合の、ネットワークの利用状況への影響について紹介します。ストレージトラフィックと仮想マシントラフィックストレージトラフィックがネットワークを独占的に使用する場合、仮想マシントラフィックが使用できる帯域幅はごくわずかであるため、ストレージ層のパフォーマンスが高くても、エンドユーザーアプリケーションやビジネスクリティカルなアプリケ

データローカリティはストレージのパフォーマンスにのみ関係すると思いますか?もう一度考えてみてください!

本記事は2020年6月11日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちらです。 Nutanixの競合他社が、データローカリティは重要ではないと自分自身やお客様を納得させようと必死に努力しようとも、ネットワーキングを含むリソースを不必要に使うことは、非効率であり、ボトルネックとなって機能面やパフォーマンスに影響を与える可能性があるという事実は変わりません。 Nutanixは、当初よりこのような課題に対処するためにAOSを設計し、データローカリティが特にプラットフォームの成功の鍵となり、私どものお客様環境を拡大し、長年にわたり最もミッションクリティカルなエンタープライズワークロードをサポートしてきました。 ここでは、データローカリティのそれほど目立たないながらも重要な利点をいくつか紹介します。 1. より高速なvMotion/ノードフェイルオーバー使用可能なネットワーク帯域幅が増えるほどvMotionの処理は早く完了し、VMとアプリケーションへの影響が少なくなるため、明らかな効果が得られます。VM のパフォーマンスが向上するだけでなく、ストレージ、ハイパーバイザ、ハードウェアのメンテナンス/アップグレードのためにメンテナンスモードに入るホストなどの運用保守業務を迅速に完了できます。ビジネスクリティカルアプリケーションが、vMotionの影響を長時間受けたことはありませんか? vMotionに十分な帯域幅を確保することは、vBCA(ビジネスクリティカルアプリケーション)を仮想環境で利用する上で重要です。 2. 同期/非同期レプリケーションの帯域幅の更なる確保実際の状況では、フロントエンドVMのIOPS/スループットだけではなく、目標復旧時点 (RPO)と目標復旧時間(RTO)に関する実際に必要なSLAを満たすことも必要です。レプリケーションをスケジュール通りに実行するために使用できる帯域幅が不足している場合、SLAの達成に影響を与える可能性があります。 3. クラスターの再構築/再同期のパフォーマンスドライブ、ノード、ブロック、またはラックの障害が発生すると、HCI 製品は再構築/再同期を実行して、設定されたレベルの回復力に復旧します。(通常、2つか 3つのデータのコピー、または同等のパリティを持っています)。これらの操作は、データの整合性を復元し、

Prism CentralのOVAエクスポート・インポートがうまくいかない場合(AHV to ESXi)

はじめにPrism Centralには、OVAエクスポート・インポート機能がありますが、Prism CentralでAHVからエクスポートしたOVAをESXiへインポートして起動すると、画面がフリーズしたり、再起動を繰り返したり、vDISKをうまく読み込めなかったりして、結果使えなかったという経験をした方もいらっしゃるのではないでしょうか?実は私も以前この機能でAHV上のVMをOVA(vmdk)エクスポートし、ESXiへインポートするということを試したのですが、うまくいかずあきらめたことがあります。ただ今回、色々試してみてうまくいったので内容を共有します。▽テストした環境エクスポート元: AOS 6.5.1.5 AHV 20201105.30417 Prism Central pc.2022.6インポート先(1): vCenter 7.0 U3g 20150588, ESXi 7.0 U3f 20036589インポート先(2): vCenter 6.7 U3 14368073, ESXi 6.7 U3 14320388 上手くいかない場合に試したいこと(AHV to ESXi)① ESXiにインポートした仮想マシンの設定画面で「ゲスト OS ファミリ」と「ゲスト OS バージョン」を適切な値に変更する。OVAをインポートした時点では、なぜか「その他」「その他(32 ビット)」と表示されます。② 同じく仮想マシンの設定画面で SCSI コントローラーを「LSI Logic SAS」に変更します。OVAインポートした時は「LSI Logic パラレル」が選択されているのですが、Windowsではすでにこのコントローラーはサポートされておりません。私の環境では、この設定によって仮想マシンが起動できるようになりました。初回起動時はマウスポインタの動きがかなり悪いのでご注意ください。キーボードを駆使して、VMware Toolsを何とかインストールして再起動すると解消します。Prism CentralのOVAエクスポート・インポートがうまくいかない場合はぜひ試してみてください。

パブリッククラウドの課題 – VMware VMConAWSとNutanix Clustersの比較 – 索引

本記事は2020年8月19日にJosh Odgers氏が投稿した記事の翻訳版です。原文はコチラ。パブリッククラウド内のベアメタルハードウェアにHCI(ハイパーコンバージドインフラストラクチャー:IT環境整備のための仮想化基盤インフラ)ソリューションをデプロイするメリットは、価値実現までの時間、スケーラビリティ、およびシンプルさという観点で大きな意味がありますが本ブログシリーズで紹介しているように、すべてのHCI製品が同じように開発されているわけではありません。もっともよく使用されている2つのHCIソリューションはVMware vSANとNutanix AOSであり、どちらのソリューションでも、ベアメタルインスタンスを使用したAWS EC2のサービスが用意されています。本ブログで連載するこのシリーズでは、パブリッククラウドベースのHCIソリューションを選択する際に考慮すべき主なトピックについて紹介します。尚、このブログシリーズは、新しいトピックを追加して改訂したり、テクノロジーの変化に応じて、必要に応じて改訂したりする場合があります。パート1 – ネットワークパフォーマンス パート2 – TCO/ROIとストレージ容量  パート3 – 大規模環境でのTCO/ROIとストレージ容量  パート4 – データ効率テクノロジーと回復力に関する考慮事項  パート5 – ストレージデバイス障害と回復力への影響  パート6 – ベアメタルインスタンスの障害  パート7 – ストレージI/Oパスと回復力への影響  パート8 – ストレージの拡張と運用への影響  パート9 - キャパシティの改善と妥協なきパフォーマンス(更にその上でしなやかさは?) パート10 – 未定NutanixとVMware vSAN / VxRAILのプライベートクラウド/オンプレミスの比較については、以下を参照してください。NutanixとVMware vSAN / DellEMC VxRailを比較

Nutanixの回復力 パート9 自己修復

本記事は2018年6月20日にJosh Odgers氏が投稿した記事の日本語版です。原文はこちら。本シリーズの索引はこちら。 Nutanixには、いくつもの非常に重要でユニークな自己修復機能があります。これらによって従来からのSAN/NAS装置だけでなく、他のHCI製品とも差別化されています。 Nutanixは、SSD/HDD/NVMeデバイスの損失やノードの障害を完全に自動で自己修復するだけでなく、ユーザーの介入なしに管理スタック(PRISM)を完全に復旧させることができます。 まず最初に、デバイスやノードの障害からデータを自己修復する方法について説明します。 従来のデュアルコントローラーのSANと、平均的*なサイズの8ノードのNutanixクラスターを単純に比較してみましょう。 *平均値は、全世界の顧客数を販売台数で割って算出しています。 1台のストレージコントローラが故障した場合、SAN/NASでは回復力が失われます。ベンダーがコンポーネントを交換し、回復力(多くの場合は性能劣化も)を取り戻すまでは、SLA(サービスレベルアグリーメント)を守るために奔走しなければなりません。 Nutanixと比較すると、8台のストレージコントローラのうち1台(12.5%)だけがオフラインになり、7台がワークロードへのサービスを継続し、回復力を自動的に取り戻すことができます(パート1で示したように、通常は分単位で回復します)。以前、「ハードウェアサポート契約と24時間365日のオンサイトが不要な理由」というブログで、このコンセプトを詳しく紹介しました。簡単に言うと、プラットフォームの回復力を取り戻すために、新しい交換部品の到着や、さらに悪いことに人手に依存している場合、ハードウェアの交換やマニュアルでの作業なしに完全な回復力を持つ状態に自己回復できるプラットフォームに比べて、ダウンタイムやデータロスのリスクは飛躍的に高くなります。 「もっと小さな(Nutanixの)クラスターではどうか」と反論する人(あるいは競合他社)もいるかもしれません。よくぞ聞いてくださいました。4ノードのクラスターであっても、ノード障害が発生すると、ハードウェアの交換やマニュアルでの作業なしに、完全に自己回復して回復力のある3ノードのクラスターになります。 Nutanix環境で、別のノード障害が発生しても

CPU利用の比較 – Nutanix AOS vs VMware vSAN / DellEMC VxRAIL

本記事は2020年3月2日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 このシリーズでは、NutanixプラットフォームがvSAN/VxRAILよりも多くの使用可能な容量を提供することで、物理ストレージをより効率的に利用できることをすでに学んできました。 また、Nutanixのアーキテクチャは、ドライブやノードの障害をより安全に処理し、復旧までの平均時間を大幅に短縮することができるなど、多くの利点があることを学びました。 Nutanixの容量拡張や性能向上を即座に改善する独自能力は、Day2 Operations(運用フェーズ)をはるかに単純化し、価値を生み出すまでの時間を短縮することにもつながります。 また、Nutanix Controller VM (CVM)は、基本的なストレージ層のみしか提供しないvSANカーネルモジュールよりも価値が高いことがわかりました。Nutanix CVMは、より高度な、回復力があり、スケーラブルで、パフォーマンスの高い分散型ストレージファブリックを提供するだけでなく、データ保護/レプリケーションなどの機能も提供し、利用性の高い管理スイート(PRISM Element)も提供します。 CVMは、より多くの価値を提供しているにもかかわらず、メモリ使用量の比較記事では、Nutanix CVMのメモリ使用量はvSAN/VxRAILと同等かそれ以下であることが多いということがわかりました。 さらに、vSAN/VxRAILが「インカーネル」で実行されていることがリソース使用量の面で大きな利点になるという神話を払拭するために、CPU使用量の例をいくつか見てみましょう。 注: VMwareのEULAでは、IOPS/スループットのパフォーマンス数値を共有することができませんが、すべての比較において、プラットフォームの差の割合を示しています。これにより、提供されるパフォーマンスが異なる場合でも、CPU使用率を正確に比較することができます。 次のチャートは、Nutanix X-Rayツールを使用して、「Four Corners」と「Throughput Scalability」のシナリオを使用して作成したものです。 例1 - ランダムリードのCPU使用率 このテストでは、IOPSの結果は両プラットフォーム

Contrail SDNコントローラーを統合し、AHVクラスタ内のオーバーレイネットワークを管理

本記事は2020年7月20日にNutanixのEnterprise ArchitectであるAmin Aflatoonianが .NEXTコミュニティに寄稿した記事の翻訳版です。 原文はこちら。    Juniper Contrailはテレコム・クラウド業界で幅広く様々なユースケースで展開されているソフトウェア定義のネットワーク機能(SDN)コントローラーです。最近NutanixとJuniperはNutanixのネイティブなハイパーバイザー である AHV上での展開が検証済みであるということをアナウンスしました。 この記事では、この2つのテクノロジーをアーキテクチャの面から見ていき、どのように統合が行われているか解説していきます。 アーキテクチャ このセクションではContrailとAHV製品の両方のアーキテクチャの概略を見ていき、これら2つの製品がどのように結合して付加価値サービスを提供するのかをお見せしていきます。これらの製品について更に詳しく学びたい場合にはNutanixとJuniperのオフィシャルウェブサイトをご確認ください。 Juniper Contrail Contrailはオーバーレイネットワークを物理、そして仮想インフラストラクチャ上に作成・管理するSDNコントローラーです。 Contrailは主に2つのコンポーネントから構成されています: Contrail vRouter: ハイパーバイザー上で稼働し、仮想マシンに対してネットワーク機能を提供する分散ルーター Contrail Controller: 複数のvRouterの統制、管理、オーケストレーション、分析を提供する論理的な集中コントロールプレーン 図 1 Contrail アーキテクチャContrailの最も高いレベルでは、そのノースバウンドインターフェイス(NBI)経由でコントローラーはハイレベルなネットワーク構成(仮想ネットワーク、vNIC、ルーティング、ポリシーなど)を受け取り、それに合わせてvRouterのルーティングテーブルをプログラムします。こうした指示をvRouterに送信するためにコントローラーはXMPPプロトコルを利用しています。 データプレーンのレベルでは、vRouterが仮想マシンに接続されたインターフェイス(vNIC)からトラフィックを受信した

Badges

Show all badges