198 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の 最適な読

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の回復力 – パート 5 – CVMのメンテナンス中または障害時のRead I/O

2018年6月8日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 これまでのシリーズでは、ADSFがクラスタ全体にデータを分散することで、ノード障害から迅速に回復する方法について説明してきました(パート1)。また、耐障害性をRF2(Resiliency Factor 2)からRF3へ変換した場合や(パート2)、よりスペース効率の高いEC-X(Erasure Coding)構成へ変換する場合でも(パート4)、影響がないことを説明しました。 ここでは、AOSのアップグレードなどのNutanix Controller VM (CVM)のメンテナンス時や、CVMのクラッシュや誤ってまたは悪意を持って電源を切ってしまった場合などの障害時に、VMがどのような影響を受けるかという非常に重要なトピックを取り上げます。 早速ですが、Nutanix ADSFがどのようにデータを書き込み、保護するのか、その基本を説明します。 下図は、3ノードでクラスタで、1台の仮想マシンが稼働している構成です。仮想マシンはa,b,c,dのデータを書き込んでいます。通常、すべての書き込みは、1つのレプリカが仮想マシンを実行しているホスト(ここではノード1)に書き込まれ、もう1つのレプリカ(RF3の場合は1つまたは複数)がディスク配置の選択優先順位に基づいてクラスタ全体に分散配置されます。ディスク配置の選択優先順位(私は「インテリジェント・レプリカ・プレースメント(Intelligent replica placement)」と呼んでいます)は、データが最初から最適な場所に置かれることを保証します。  クラスタに1つ以上のノードが追加された場合、インテリジェント・レプリカ・プレースメントは、新たな書き込みが発生しなかった場合でも、クラスタがバランスのとれた状態になるまで、それらのノードに比例してより多くのレプリカを送信します。ADSFは低い優先度のバックグラウンド処理でディスクバランスを行います。 Nutanixがどのように複数のレプリカを使用してデータ保護を行っているか(「Resiliency Factor」と呼ばれる)の基本がわかったところで、Nutanix ADSFストレージ層のアップグレード時にどのようなことが起こるかを確認します。 アップグレードは、

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では、エンドユーザーによるストレージのサ

異なるモデルでのクラスタサポート - 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 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上で稼働させることで、フルスタックの、エンタープライズ向けにサポートされ

次なるフロンティア – 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スタンは、多くの恐怖を感じる事象に発展する可能性があり、最終的にはビジネスアプリケーションとサ

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

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年間のうちにオンプレミスへ回帰す

パブリッククラウドの課題 – パート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にデプロイした場合の、ネットワークの利用状況への影響について紹介します。ストレージトラフィックと仮想マシントラフィックストレージトラフィックがネットワークを独占的に使用する場合、仮想マシントラフィックが使用できる帯域幅はごくわずかであるため、ストレージ層のパフォーマンスが高くても、エンドユーザーアプリケーションやビジネスクリティカルなアプリケ

パブリッククラウドの課題 – 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を比較

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

本記事は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つのデータのコピー、または同等のパリティを持っています)。これらの操作は、データの整合性を復元し、

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)からトラフィックを受信した

3階層(もしくはそれ以上)のインフラストラクチャに迫る危機

本記事の原文は[url=https://www.nutanix.com/2018/03/19/perils-3-tier-infrastructure/]コチラ[/url]。 昔々のそのまた昔(1999年)、3階層のインフラストラクチャはアプリケーションのニーズのために生まれてきました。1999年からのことです。 上辺だけの話ではありません ー 3階層はウェブアプリケーションの爆発の際の変革であり、今回の話題はそのような話です:あらゆるテクノロジーは「その時代」ごとに置き換えられていくものであり、優れている、長期目線である、もしくは特に今日のクラウド対応の過ぎ去りし日のアプリケーションから進化を遂げた輝かしいアプリそして動的なワークロードを動作させたいと考えているような場合にそれが行われるのです。 ですが、どうして安住の地である3階層の世界にとどまっていてはならない理由は何でしょうか?何が危険なのでしょう? [h2]成長を妨げる可能性があります[/h2]バラバラのサーバベンダ、ストレージベンダ、ネットワークベンダ、仮想化ベンダーとこの3階層構成によって、会社組織はテクノロジーのベスト・オブ・ブリードを選択することができ、注意深く統合しながらデータセンタを作り上げてきました。しかし、このアプローチはITシステムにプレッシャーを掛けたり、新しいアプリケーションを利用したいというビジネスからのニーズと同じようにスケールアウトさせるには不向きです。単に3階層インフラストラクチャをベースとしたインフラストラクチャを拡張したいという試みですら複雑になり、より複雑性が増していきます。そして複雑性の話が続きます。。。 [h2]ルービックキューブよりも複雑、さらにただの時間の無駄[/h2]単に明かりを灯し続けるだけ。複数のベンダーを管理する。複数の管理インターフェイスを使う。専門家に頼り切り。週末、金曜日の夜、休日がない?もうこれぐらいにしましょう。3階層とともにもたらされる複雑さは管理のオーバーヘッドを伴うもので、IT部門は新しいより良い運用の方法を模索することになります。スムーズな運用を約束するシステムは単一のインターフェイスから全体の洞察そしてコントロールを保証します。([url=https://www.youtube.com/watch?v=JImLVKZu5cw]

Nutanix AES: 事例によるパフォーマンス

本記事は[url=https://www.n0derunner.com]n0derunner[/url]に2018年12月17日に掲載された記事の日本語ヴァージョンです。 原文を参照したい方は[url=https://www.n0derunner.com/2018/12/nutanix-aes-performance-by-example/]こちら[/url]。 [h2]データベースの復元にかかる時間を50%も削減する方法は?[/h2]ロンドンで行われた.Next 2018の最中にNutanixはコアデータパス内でのパフォーマンスの改善をアナウンスしました。これは最大で2倍のパフォーマンス改善をもたらすとのことです。以下では実際の現実世界での改善について例を上げたいと考えています。 [img]https://d1qy7qyune0vt1.cloudfront.net/nutanix-us/attachment/8b3795d4-e025-47cf-9661-1817f537b096.png[/img] X-Rayを利用して1TBのデータを既存のデータベース内に復元する操作をシミュレーションしました。64K,128K,256K,1MBに分割されるとはいえ、IOのサイズは非常に大きなものとなり、1TBのデータセットに対するアクセスパターンは100%ランダムなものとなります。 [code]bssplit=64k/20:128k/20:256k/20:512k/20:1m/20 [/code] 通常、大きなIOサイズを用いたストレージのベンチマークはそれに応じた結果になります。これはストレージのバックエンドでの取扱が比較的簡単なものだからです。最初にかける負荷としては現実的なものとなりますが、今回は100%ランダムなパターンの場合での復元をシミュレーションしたいと考えました。 今回のケースでは1TBを取り込みきるまでの時間は[b]半分[/b]になりました。比較の対象となっているのは自律化エクステントストア(Autonomous Extent Store - AES)が有効になったNutanix AOS 5.10と以前の従来からのエクステントストアです。 この改善ははAESによって、エクステントストアへの挿入が直接、より高速に行えるように

Nutanix Mine: データ保護をHyperconverge

本記事は2019年5月8日に投稿されたMark Nijmeijerの記事の翻訳版です。 原文を参照したい場合には[url=https://www.nutanix.com/blog/nutanix-mine-hyperconverge-your-data-protection.html]こちら[/url]。 2年前、私は[url=https://next.nutanix.com/blog-40/looking-back-to-go-forward-on-the-ahv-journey-22059]こちらの記事[/url]でNutanix AOSプラットフォームの周辺で形成されるデータ保護のエコシステムについての話題を共同執筆しました。Nutanixはその場にそのまま留まっていたわけではなく、それ以降、パートナーのリストを著しく拡充してきました。我々が検証を行ってきた完全なリストは[url=https://www.nutanix.com/partners/technology-alliances]Nutanix Ready Technology Alliance Partner Program page[/url]をご確認ください。 我々はここにとどまっているつもりはありません、これはまだNutanixのデータ保護に何が保存されるかの始まりにしか過ぎ無いのです!Nutanix Enterprise Cloud OSは急速に全てのアプリケーションワークロードのための業界最高のプラットフォームへとなりつつあります。 今日の[url=https://www.nutanix.com/press-releases/2019/nutanix-hyperconverges-secondary-storage-with-nutanix-mine]Nutanix Mineソリューションのアナウンス[/url]で我々は我々のプラットフォームをセカンダリーストレージへと拡張します。[url=https://www.nutanix.com/products/mine]Nutanix Mine[/url]プラットフォームはNutanix AOSの素晴らしさを活用し、現在アプリケーションにもたらしているのと同様の効果 ー シンプルさ、パフォーマンス、弾力性をセカンダリーストレージへとも

ServiceNowとNutanixの連携 その1

本記事は2019年12月11日にNutanix Solutions Architect - AutomationのSho Uchidaが統合した記事を一部転記したものです。 全文を参照したい場合はこちら。 ServiceNowとNutanixの連携について 概要 2019年10月のデンマーク、コペンハーゲンにおける.NEXT ConferenceにおいてServiceNow社とNutanixは両社ソリューションの連携を発表しました。詳しくは以下のURLをご覧下さい。 Nutanix、プライベートクラウド向け自動化機能を発表ServiceNowとNutanixの統合 ユースケース 執筆時点(2019/12)時点でのユースケースは以下3点です。 1. ServiceNowのイベント、インシデントとNutanixのアラートの統合(その2で紹介) 2. ServiceNowのリクエスト管理とCalmプラグインによるNutanixへのアプリケーションデプロイ(その3、その4で紹介) 3. ServiceNOW CMDBにおけるNutanixインフラの検知とモデリング(その5で紹介) アーキテクチャ アーキテクチャはこちら。上記ユースケース2,3はNutanix側にMIDサーバと呼ばれる、ServiceNowとNutanix間のデータ通信を担う中間サーバが必要となります。 本シリーズ(全5回)では ServiceNow社の提供する開発者インスタンスを用いてシンプルなServiceNow-Nutanixの統合環境を作ることを目指します。 本記事(その1)では 準備作業として開発者インスタンスの立ち上げとMIDサーバの立ち上げを行います。 続きを原文で読む。

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をオフ

Badges

  • Neighborly
    meddhas earned the badge Neighborly
  • Courteous
    meddhas earned the badge Courteous
  • Approachable
    sreehari41has earned the badge Approachable
  • Courteous
    LukaszWarcholhas earned the badge Courteous
  • Skillful
    Kcmounthas earned the badge Skillful
Show all badges