• 199 Topics
  • 198 Replies

199 Topics

Nutanixのメリットその7: 自由なライセンスポータビリティ

本記事はNutanixのSVP Product and Solutions MarketingのLee Caswell氏が2022年9月22日に投稿した記事の翻訳版です。原文はこちら。  ベイエリアに雨が降ると、それはスキーシーズンがさほど遠くないということの現れです。この何年かはダウンヒルの愛好家は場所が定められた一つのリゾートのパスだけに制限を受け、多くの人がフラストレーションを感じ、また前もっての計画と確定を余儀なくされていたのでした。スキーヤーは今日、全米、もしくは世界中のスロープを滑走できる新たなマルチリゾートのセレクションパスを選ぶことができるようになりました。この記事はNutanixがマルチリゾートパスと同様に展開しているポータビリティがどのようなものなのか、そして、それがITマネージャーの、時とともに変わり続けるアプリケーションのニーズを満たすために、様々な場所、そしてハイブリッドにクラウドインフラストラクチャーを構築する手助けしてくれるのかについてのものです。 ポータビリティの価値パフォーマンス、コスト、そして支配権についての心配が、ITマネージャーにどこにアプリケーションを配置するのかという課題を幾度となく投げかけます。しかし、これは簡単になしうることではありません。特にクラウドのリソースの追加とエッジで予測されている成長を鑑みるとなおさらです。実際、Gartner®は2027年までに2022年に配置された85%のワークロードの場所が要件の変化によって最適ではなくなる¹ 予測しています。クラウド、マルチクラウド、そして成長を続けるエッジでは拡張が起きています。時の流れの中でどこにアプリケーションとインフラストラクチャーを提供するのかという柔軟性の価値はその場所の選択肢が拡張されるにつれて大きくなっていきます。アプリケーションのモビリティ提供するためには、柔軟性を持ったインフラストラクチャーが必要不可欠なのです。幸運なことに、モダンなハイブリッドクラウドはサーバーインフラストラクチャー上で標準化されており、Nutanixはサーバーベースのハイブリッドクラウドをまたがった完全なソフトウェアスタックのポータビリティを実現しています。オンプレミス環境をお持ちのお客様はそのリソースをパブリッククラウドへまたはエッジへと要件の変化に合わせて移動させることがで

Nutanixのメリットその6: ハイパーバイザーの選択肢

本記事は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のメリット その5: エンタープライズグレードのレプリケーションとディザスタリカバリ

本記事は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のメリット その4: きめ細やかで効率性の高いスナップショット

本記事は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のメリット その3: パフォーマンスとキャパシティのためのシームレスなクラスタ管理

本記事はNutanixのSenior Technical Marketing EngineerのBhavik Desaiが2022年8月18日に投稿した記事の翻訳版です。原文はこちら。  このシリーズのこれまでの2つの記事では、Nutanix AOSが自動化されたアプリケーションを意識したデータ管理を実現する、動的な分散されたストレージをどのように提供しているのか、ということについて掘り下げてきました。今回の記事では、これらの2つの機能が、管理者がクラスタに更に物理ノードを追加して拡張をしなければならない場合に、どのように強力なメリットをもたらすのかについて見ていきましょう。 パフォーマンスとキャパシティのためのクラスタ管理展開が終われば、インフラストラクチャーとアプリケーションの日々の運用が重要になります。Nutanix AOSは管理者の行うライフサイクル管理を簡単かつシームレスなものにします。すべての管理者が行わなければならない重要なタスクの一つにストレージもしくはパフォーマンスのためのインフラストラクチャーの拡張があります。管理者は通常、最初は均一なクラスタを展開することから始めることになりますが、アプリケーションが成長するにつれて、よく発生するユースケースがクラスタへのさらなるキャパシティの追加です。管理者は多くのストレージキャパシティを持つノードや、アプリケーション仮想マシンを動作させないストレージオンリーノードを含む様々なタイプのノードを追加するという選択肢があります。AOSはこの部分をその動的なクラウドアーキテクチャーで劇的にシンプルにすることができます。一度ノードが追加されると、アプリケーションは他のHCIシステムのように何らかの介入を必要とすることなく、即座にその追加されたリソースを活用することができます。これはAOSが書き込みを行うデータが最適なサイズであることと、動的に自律化されたWriteを行うことで可能となっています。AOSは自動的に新たなリソースを利用し始め、マニュアルでの介入を行うことなく、書き込みのコピーデータは新しいノードへと送信されます。それに加えて、AOS内のCuratorフレームワークがディスクのリバランスをバックグラウンドオペレーションとして開始させ、自動的にクラスタのバランスを調整します。以下の例で大容量のノードをクラスタ

Nutanixのメリット その2: 自動化されたアプリケーションを意識したデータ管理

本記事は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のメリット その 1: 動的に分散されたストレージ

本記事は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のリアルタイムインテリジェンスはスケールアウトクラスタ全体に分離し、広がっており、このためこれらのサービスを構成する要素には何一つ単一障害点はなく、どのノードのどのサービスも必要になればその

Red Hat OpenShift IPI on Nutanix クラウドプラットフォーム

  本記事は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 4.0新機能。Smart DRの強化

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を使っている場合、環境をアップグレードするだけで、これらの