Nutanixのハードウェアおよびソフトウェア製品に関するディスカッション。
本記事は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ソフトウェアの利用をシンプルに計画、価格、購入を実現する方法をご提供します。２つの新しいユースケースは仮想デスクトップインフラストラクチャ(VDI)とリモートオフィス／ブランチオフィス(ROBO)環境です。 [h2] [/h2][h2]新しい利用モデルとはどのようなもの?[/h2]この消費モデルは幾つかのNutanixソフトウェアソリューションを一緒に「ライセンシング」するモデルで、これによってハードウェアとソフトウェアの購入は分離されることになります。これによって、インフラストラクチャのニーズに基づいてどこに、どのようにNutanixソフトウェアを展開するかという点で、大きな柔軟性が実現されることになります。それぞれのモデルはAOS、AHV、Prism Starterを含んでいます。 [list] [*]VDIについてはこのライセンスモデルはVDI per userと呼ばれ、同時ユーザー数をベースとします。 [*]ROBOにつ
本記事は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
本記事は2020年3月２日に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の 最適な読
本記事は2020年2月26日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 このシリーズでは、重複排除と圧縮、およびイレージャーコーディングを使用する際に、Nutanixがより多くの使用可能な容量を提供するとともに、より大きな容量効率、柔軟性、回復力、およびパフォーマンスを提供することを学びました。また、Nutanixははるかに簡単で優れたストレージのスケーラビリティを提供し、ドライブの障害による影響を大幅に軽減していることも知りました。このパートでは、異なるモデルで構成するクラスタのサポートについて説明します。これは、HCIプラットフォームの拡張機能にとって非常に重要であり、絶えず変化するユーザーの要件を満たす/それ以上を提供するということを学んでいきます。ハードウェアのキャパシティ/パフォーマンスは非常に速いペースで進歩し続けており、ユーザーが一様な（同一スペックのノードによる）クラスタを使用することを余儀なくされた場合、TCOは上がり、投資の回収に多くの時間を必要とする可能性があります。これだけでも好ましくない事態ですが、それだけでなく、ユーザーが非効率的なサイロを作らなければ、新しいハードウェアの性能や集約のメリットを活かせなくなることを意味します。つまるところ、古いSAN時代のように、ハードウェアを「総入れ替え」する必要があるような状況にはなりたくありません。それでは、簡単な「チェックボックスの比較」から始めてみましょう。 サポートされているクラスタのノード構成 Nutanix VMware vSAN Heterogeneous（異なるモデルノード混在構成） Homogeneous（同一モデルノードのみの構成） 以前にも私が記事で強調したように "チェックボックス "スタイルの評価は、一般的に製品の機能についての誤った理解につながることを述べました。今回の記事は、この（"チェックボックス "スタイルの）評価における問題のまさに典型的なモデルで、簡単な例を挙げてみます。 再びDellEMCが推奨するハードウェアプラットフォームであるVxRail E-Seriesの4ノー
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.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上で稼働させることで、フルスタックの、エンタープライズ向けにサポートされ
こんにちは、HYCU（ハイク）の吉田です。 当ブログは2020年７月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スタンは、多くの恐怖を感じる事象に発展する可能性があり、最終的にはビジネスアプリケーションとサ
