Global Forums

Discussions from around the globe

213 Topics

2016年頃に3ノードで導入したNutanix(vSphere)がノード障害を起こしてしまいました。調べてみると、ハードウェア障害でした。現在、障害の出ているノードはvSphere上では、該当のノードに”!”マークが表示されている状態です。iDRACでは、アクセスできており、メモリエラーが出ていました。(ソフトウェア・ハードウェア共にサポートが切れている状態です。Error：Correctable memory error rate exceeded for DIMM_B1.障害からの復旧方法をご教示いただけませんでしょうか。疑問点は以下の通りです。・障害の出ているノードをシャットダウンしても良いかどうか。・ハードウェアエラー復旧後のノード再登録方法。以上となります。よろしくお願いいたします。

15814

3 years ago

smzkstsNutanix Employee

posted in 日本語フォーラム (Japanese)

「ブログ書いたよ！」＆「こんな記事見つけたよ！」お知らせコーナー

Nutanixに関するブログを書いていただいた方は、より多くの方に読んでいただけるよう、ぜひこちらでお知らせください！また、Nutanixに関するメディア記事や海外ブログなどなど、ご自身が書いたもの以外でも「コレいいな」と思うものを見つけた際には、是非ご紹介ください！

41449

3 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

AOS 5.19登場: パフォーマンスの向上、セキュリティの改善、自動化された運用

本記事は2020年12月18日にAOS Product Teamが投稿した記事の翻訳版です。原文はこちら。 Nutanix HCIでリモートワークをセキュアに、ワークロードを加速、インフラストラクチャの自動運転を実現AOS 5.19とそれに関連したPrism Centralのリリース PC 2020.11によってNutanixのハイパーコンバージドインフラストラクチャを利用しているお客様に新たな機能をお届けできることを大変喜ばしく感じています。AOS 5.19はAOS 5.18においてなし得たブレイクスルーの上でのさらなるパフォーマンスの改善とデータの暗号化およびセキュア化についてのビルトインの鍵管理能力を拡張を提供します。AOS 5.19ではビルトインのハイパーバイザーであるAHV上で動作する仮想マシンのポータビリティも向上しており、先進的な管理機能との一元化なども行なわれています。セキュリティROBO環境向けのネイティブ鍵管理システム(KMS - Key Management System)我々は新たな環境においてもいずれの場所であっても暗号化を保証することで継続的にセキュリティをシンプル化し続けています。NutanixはすでにFIPS 140-2認証を得たデータの最終暗号化と鍵管理を外部のKMSもしくはネイティブのKMSの選択肢とともに提供しています。更に詳しくは Data at Rest guideを参照してください。このリリースで我々はネイティブのKMSを拡張し、1もしくは2ノードのリモート&ブランチ(ROBO)サイトをサポートし、シンプルでコスト効率の高いセキュアなエッジソリューションを実現しました。ネイティブKMSはリモートのPrism Centralベースのroot-of-trustの新たなオプションも提供し、リモートオフィス拠点でのさらなる保護を実現します。AOS 5.19では複数のリモートのクラスタから中央のPrism Centralインスタンスへとローカルに展開されたKMSインスタンスのバックアップ機能も提供し、容易にデータと鍵の双方を保護しセキュアにすることができます。 AHVのMicrosoftのVBS と Credential GuardのサポートAOS 5.19では今年のはじめに開始したセキュアブートについての一連の動き

4250

3 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

NutanixはAOS 5.18でHCIの歴史における新たなマイルストーンへ到達

本記事はSteve Carter氏が2020年10月12日に投稿した記事の翻訳版です。原文はこちら。 AOS 5.18のリリースはHCI顧客に革新的な分散アーキテクチャの上に実装された新しい機能でアプリケーションパフォーマンスの向上をもたらす一方で、IT運用のこれまで以上のシンプル化と自動化を提供することで、ハイパーコンバージドインフラストラクチャの歴史における大きな一歩を踏み出しました。ストレージ性能の向上AOSのバックボーンであるウェブスケールアーキテクチャはパフォーマンス、しなやかさ、そして拡張性に重きをおくのみならず、これらの領域に置ける継続的な革新を実現することにも重きをおいています。よく練り込まれたメタデータはスケールアウトアーキテクチャの基盤であり、妥協することのないしなやかさと柔軟性、そして想定通りの拡張性を実現しています。このメタデータは時々に応じたデータローカリティ、想定通りの高性能の提供をアクティブデータがアプリケーションのそばに維持することで提供しています。そして重要なことはAOSは適切なしやなやかさ、セキュリティ、性能をAOSの開発陣が速いペースでの堅牢な機能の確信を継続していくために、ユーザースペースで実装されているということです。 Blockstore(ブロックストア)Nutanixの完全に新しいブロックストアは低いCPUのオーバーヘッドと低遅延で、効率的にストレージメディアのIOを管理します。ブロックストアはユーザースペースのファイルシステムレイヤとブロック管理レイヤを司り、I/O操作を提供しながら、劇的にシステムコールとカーネルオーバーヘッドを削減します。ブロックストアによってAOSはあらゆる物理デバイス(NVMe、SSD、HDD)上にデータを迅速にかつ効率的に格納しながら、その一方でNANDベースのデバイスの摩耗を抑えることができます。まず最初はこの機能はNVMeデバイスを1つもしくは複数保持するオールフラッシュベースシステム向けに利用開始され、今後のリリースでより広範に利用されることになります。 SPDKブロックストアはAOSがIntel社のSPDK(Storage Performance Development Kit - ストレージパフォーマンス開発キット)を活用して、NVMeデバイスをユーザースペースから直接アクセスできる

6040

3 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

パブリッククラウドの課題 – パート8 – ストレージの拡張と運用への影響

本記事はJosh Odgers氏が2020年8月21日に投稿した記事の翻訳版です。原文はコチラ。本シリーズの索引はコチラです。このシリーズのパート2とパート3では、Nutanix ClustersとVMware VMConAWSで同じAWSベアメタル（i3.metal）ハードウェアを基盤として使用した場合に、Nutanix Clustersのほうが使用可能な容量が多くなることを紹介しました。次に、データ効率テクノロジーと回復力に関する考慮事項を比較し、容量効率、柔軟性、回復力、パフォーマンスに関してNutanix ClustersがvSANよりも明らかに優れていることを紹介しました。パート5では、Nutanix Clustersがストレージデバイス（NVMe SSD）のデバイス障害をどのように処理するかについて、パート6ではベアメタルインスタンスの障害の場合について紹介しました。両方の場合とも、Nutanix ClustersはVMC/vSANよりも影響が小さく、Nutanixの基盤となる分散ストレージファブリック（AOS）のおかげでデータ整合性と回復力を短時間で回復できます。パート7では、コントローラーVM（CVM）にNutanix Clusters（AOS）が実装されるため、ストレージI/Oパスでハードウェアやソフトウェアの問題が発生しても、VMCよりも回復力が高く、影響が小さいことを紹介しました。VMCでは不要なHAイベントがノードに発生し、大きな影響が生じます。AWS EC2では、NutanixやVMwareなどのベンダーはハードウェア層を制御できないため、ストレージ容量を拡張するには、シンプルに、環境にベアメタルインスタンスを追加します。どちらの製品の場合でも、ストレージ容量要件に対応するには、新しいベアメタルインスタンスを追加するだけで済むとも言えます。本当にそれだけでしょうか。いいえ、そうではありません。実は、どちらの製品においても、新しい容量を実際に使用するためには時間と労力が大幅にかかります。VMC/vSANの問題1 – 新しいノードをVMCクラスターに追加しても、新しいノードのストレージリソースは既存の仮想マシンの使用可能な容量（またはパフォーマンス）に追加されません。どういうことだろうか、とお思いになりますよね。例えば、4ノードのVMC/

5390

3 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

パブリッククラウドの課題 – パート7 – ストレージI/Oパスと回復力への影響

本記事はJosh Odgers氏が2020年8月20日に投稿した記事の翻訳版です。原文はコチラ。本シリーズの索引はコチラです。パート6では、ベアメタルインスタンスに障害が発生した後で、VMware VMCとNutanix Clustersの各アーキテクチャーではリビルドがどのように実行されるのかについて、および回復力とパフォーマンスにおいてNutanixで得られる主な利点について紹介しました。この投稿では、I/OパスにおいてI/Oが「スタック」または「ハング」するというシナリオに両方の製品がどのように対処するのかについて、および、これらの状況が及ぼす影響について紹介します。説明に入る前に、概念レベルで、インフラストラクチャーの目的は最大限の可用性とデータ整合性を確保することです。そのため、インフラストラクチャーと業務に対するリスクや影響を最小限に抑えるように、あらゆる障害に対処する必要があります。それを前提に、パブリッククラウドでVMware VMCとNutanix Clustersを使用する場合に、I/Oが「スタック」または「ハング」すると、どのようなことが発生するかを紹介します。VMwareはKB「How to handle lost or stuck I/O on a host in vSAN cluster (71207)」を公開しており、このKBの中で、I/Oパス内のいずれかの場所（ストレージコントローラーや物理ドライブ自体など）でI/Oの「スタック」または「損失」が発生した場合に、vSANがどのように対処するかを紹介しています。VMwareでは、この症状を以下のように説明しています。ストレージコントローラー上やストレージディスク上でI/Oのスタックまたは損失が発生した場合、ESXiストレージスタックはタスク管理リクエストを使用してI/Oを中止するように試み、以下のコンソールメッセージが表示されます。参照先：HTTPS://KB.VMWARE.COM/S/ARTICLE/71207続けて、以下のように説明しています。ホスト上でこのような損失I/Oが見つかった場合、vSANはこのホストで強制的にPSODを実行し、このホストがクラスター内の他のホストに影響を及ぼさないようにします。参照先：HTTPS://KB.VMWARE.COM/S/ARTICLE/712

4830

3 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

お客様とパートナー様への公開書簡

本記事はNutanixの新CEOであるRajiv Ramaswami氏が2020年12月9日に公開した記事の翻訳版です。原文はこちら。お客様の喜びへの絶え間のないフォーカスとともに、シンプルで柔軟性があり、コスト効率の良いソリューションを提供することがNutanixが行っていることの中心にあります。そのNutanixの新たなCEOとして、この機会で私自身をご紹介と、Nutanixに入社してどのように興奮しているか、そして皆様のビジネスの成功に導くお手伝いへの継続的なコミットについてお伝えしたいと考えています。本日、私はNutanixのCEO職にテクノロジー産業に置ける30年以上の経験とともに、つくこととなりました。直近ではVMware社でChief Operating Officer, Products and Cloud Servicesを務めていました。VMwareに入社する以前はIBMでキャリアをスタートさせたあと、Broadcom、Nortel、そしてCiscoを含む業界をリードする企業で様々なシニアリーダーシップを務めてきました。これらの時を経て、私は人材、テクノロジー、プロダクトを一体化させることで強力な企業を生み出す重要な役割について実感を得てきました。Nutanixは急速に成長し、データセンターに革命を起こし続けるハイパーコンバージドインフラストラクチャ市場を先駆け、作り出てきました。創業以来Dheerajは非常にうまくチームの舵を取り、18,000社以上のお客様とともに創業から$1B+企業へと導きました。実際私はDheerajが2010頃にシリコンバレーでNutanixについて述べていた場面に同席していたことを覚えています。その初期ステージからNutanixが公開企業として大規模に成長していることは素晴らしいことです。Nutanixの成長を勢いのある、そして手強い競合の立場から横目で見ながら、私はその企業がお客様そしてパートナー様と作り出すシンプルさと堅牢性そして深いレベルでのお客様の信頼と満足の代名詞とも呼べるイノベーティブな製品に長きに渡って称賛してきました。 2021はNutanixの進化、ソフトウェアサブスクリプションモデルへの転換へ新たなるステージをもたらす年になり、我々のハイパーコンバージドインフラストラクチャに置けるリーダーシップを

2110

3 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

パブリッククラウドの課題 – パート6：ベアメタルインスタンスの障害

本記事はJosh Odgers氏が2020年8月19日に投稿した記事の翻訳版です。原文はコチラ。本シリーズの索引はコチラです。パート1では、パブリッククラウドで環境の価値を高めるために、使用可能なネットワーク帯域幅を効率よく利用することがどれだけ重要なのかについて紹介しました。また、使用可能な帯域幅を最大限に確保すると、フラッシュデバイス（NVMe/SSD）の障害の場合にMean Time To Recover（MTTR：平均修復時間）が短くなり、回復力がどれほど向上するかについても紹介しました。ベアメタルインスタンス（サーバーとノード）の障害の場合にも同じ概念が当てはまります。ただしこの場合は、完全なデータ整合性を回復するためには、単一の1.9TB NVMeデバイス（i3.metalの場合）ではなく8つの1.9TB NVMeデバイスのデータを再保護する必要があります。そのため、リビルドをタイムリーに実行して影響を最小限に抑えるためには、効率的でスケーラブルなアーキテクチャーであることが重要です。まずVMware VMCについて、リビルドの基盤となるアーキテクチャーについて紹介します。VMC（vSANがベース）では、オブジェクト（最大255GB）がリストされるのは、オブジェクトがホストされているソースノード上のキャパシティドライブから、クラスター内の他のノード上のキャッシュドライブ（ディスクグループ当たり1つ）に対してだけです。AWSで、よく使用されているi3.metalインスタンス（8 x 1.9NVMeデバイス）を使用する場合、VMCのリビルド操作では主に2つのNVMeデバイス（2つの「キャッシュ」ドライブ）しか使用されず、キャッシュドライブが一杯になると、残りの3つのNVMeデバイス（ディスクグループ当たり）にリビルドデータが排出されます。つまり、VMwareのVMCを使用する場合、重要なリビルドトラフィックではリビルド用にNVMeドライブの20%しか使用されません。そのため、パート2とパート3で紹介したように、VMCでは使用可能な容量が少なくなるだけでなく、回復力とパフォーマンスの観点でハードウェアが効率よく使用されないため、明らかにVMCプラットフォームの価値が下がります。VMC/vSANでは、クラスター内の使用可能なハードウェアが最大限に利用されない

3560

3 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

NutanixがForresterのハイブリッドクラウド管理Waveでストロングパフォーマーとしてデビュー

本記事は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ソリューションから最大の付加価値を迅速に、そして自身のニーズにあった幅広い購買モデルの選択肢とともに提

1740

3 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

パブリッククラウドの課題 – パート5：ストレージデバイス障害と回復力への影響

本記事はJosh Odgers氏が2020年8月18日投稿した記事の翻訳版です。原文はコチラ、本シリーズの索引はコチラです。パート1では、AWSでVMwareのVMC製品を使用する場合、VMwareやその顧客はネットワーク帯域幅を制御できないという、VMCのコアアーキテクチャーが及ぼす重大な影響について紹介しました。パート1をお読みいただいていない場合は、この投稿を読み進める前に目を通していただくことをおすすめします。パート1で紹介している概念は、この投稿のテーマである「デバイス障害と回復力への影響」について理解を深めていただくために重要です。パート2、パート3、およびパート4では、AOSの機能のおかげで、Nutanix ClustersではVMCよりも高いフロントエンドパフォーマンスを発揮しながら、使用可能な容量も多くなるということについて紹介しました。また、パート4では、VMC（vSAN）で圧縮と重複解除を使用すると、ドライブ障害のリスクや影響が大きくなるのに対して、Nutanix Clustersでは、このようなデータ効率テクノロジーを使用するかどうかに関係なく、回復力への影響がないことを紹介しました。このようにNutanix ClustersはVMC/vSANに対して優位性がありますが、プラットフォームが障害に対して高い回復力を備えていなければ意味がありません。この投稿では、AWS i3.metalインスタンスを使用する場合に、Nutanix ClustersとVMware VMCがさまざまなドライブ障害シナリオをどのように対処し、どのように回復するのかについて紹介します。AWS EC2 i3.metalインスタンスなどのパブリッククラウドサービスを使用する際、NVMeフラッシュデバイスは耐久性が高くないと考えられるため、VMC/vSANなどの製品がディスクグループごとに単一キャッシュドライブに大きく依存する場合は、Drive Writes Per Day（DWPD：1日当たりのドライブ書き込み数）の指標が適切でない可能性がある、ということを考慮することが重要です。VMwareは記事「Understanding vSAN Architecture: Disk Groups」の中で、キャッシュドライブに関して以下のように述べています。高耐久性フラッシュデバイ

4200

3 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

パブリッククラウドの課題 – パート4：データ効率テクノロジーと回復力に関する考慮事項

本記事はJosh Odgers氏が2020年8月17日に投稿した記事の翻訳版です。原文はコチラ。本シリーズの索引はコチラです。パート1では、AWSでVMwareのVMC製品を使用する場合、VMwareやその顧客はネットワーク帯域幅を制御できないという、VMCのコアアーキテクチャーが及ぼす重大な影響について紹介しました。また、（オンプレミスの顧客が使用しているのと）同じAOSエンタープライズクラウドソフトウェアをベースとするNutanix Clusters製品で、Nutanix固有のデータローカリティ機能のメリットが得られることを紹介しました。この機能によって、ネットワークへの依存を最小限に抑えてネットワークリソースを解放できるため、ストレージや仮想マシンのパフォーマンスが向上し、クラスターの回復力や機能も強化されます。パート2とパート3では、AOSの機能によって、VMCよりも高いフロントエンドパフォーマンスを発揮しながら、使用可能な容量も多くなることを説明し、その結果としてNutanixで得られるTCO/ROIのメリットについて紹介しました。このようなメリットが得られる要因として、Nutanix AOSの卓越したイレージャーコーディングが挙げられます。また、Nutanixの高度な分散ストレージファブリックによって、レガシーな「キャッシュ+キャパシティ」アーキテクチャーを使用するVMC（vSANベース）のディスクグループよりも使用可能な物理容量が多くなることも挙げられます。このパート4では、VMwareのVMC製品とNutanix Clusters製品がそれぞれ備えているデータ効率機能について紹介し、AWSを使用した本番環境でのこれらのメリットと影響について明らかにします。Nutanix ADSFとVMware vSANの重複排除と圧縮の比較に関する投稿で、両方の製品が3つの主要なデータ効率テクノロジー（圧縮、重複排除、イレージャーコーディング）を備えていることを紹介しました。これらのテクノロジーは、表面上は同じように思えますが（以下の表を参照）、詳細は大きく異なります。また、これらのテクノロジーを有効にする場合、vSAN（VMCのベース）ではクラスターレベルの設定が「オールオアナッシング」であり、柔軟性が非常に低いことも紹介しました。VMCの顧客は、圧縮と重複排除

2940

3 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

パブリッククラウドの課題 – パート3：大規模環境でのTCO/ROIとストレージ容量

本記事はJosh Odgers氏が2020年8月14日に投稿した記事の翻訳版です。原文はコチラ。本シリーズの索引はコチラです。パート2では、効率的なAOSのおかげで、3ノードのi3.metal環境でのNutanix Clusters on AWSソリューションでは、使用可能な容量がVMwareのVMCよりも24.5%多くなることを説明しました。このことは小規模環境の顧客やコスト意識の高い顧客にとっては朗報ですが、Nutanixにおいて、環境が拡張されても容量やROIにおいて同様なメリットが得られるのか疑問に思う方もいらっしゃると思います。今回の投稿では、次の3つのシナリオについて紹介します。4ノードクラスターと5ノードクラスター 6ノードクラスター 16ノードクラスターこの3つのすべてのシナリオで、AWS i3.metalサービスを使用します。この3つの例を取り上げるのは、VMCでは、3ノード環境、4～5ノード環境、および6ノード以上の環境に対して、それぞれ異なるストレージポリシーがデフォルトで適用されるためです。16ノードの例では、VMCでサポートされている最大規模のクラスターを使用した場合について紹介します。 4ノードクラスターと5ノードクラスターの比較4ノード環境の場合、VMwareのVMCは、論理容量に対して物理容量のオーバーヘッドが2倍になるFTT1（ミラーリング）から、3+1ストライプサイズを使用するイレージャーコーディング（RAID5）に切り替わります。切り替え後は、1.33倍のオーバーヘッドで容量が提供されます。参照先：https://blogs.vmware.com/virtualblocks/2018/06/07/the-use-of-erasure-coding-in-vsan/イレージャーコーディング（RAID5）に切り替わると、使用可能な容量が増えるため、切り替えはその点で意味がありますが、以下のような重大な影響が生じます。オールオアナッシング的なアプローチのため、I/O用の重要なパスに影響が生じる。VMwareもパフォーマンスへの影響を認識している 4ノードクラスターでは単一ノード障害を許容できず、単一ノード障害の場合は自己修復が不可能（3+1のストライプでは4つのノードが必要）なため、回復力が低下する I/O処理が少なくとも4つのノード

6290

4 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

パブリッククラウドの課題 – パート2：TCO/ROIとストレージ容量

本記事は2020年8月13日にJosh Odgers氏が投稿した記事の翻訳版です。原文はコチラ。本シリーズの索引はコチラです。 Amazon EC2（AWS）などのパブリッククラウドサービスをNutanix ClustersやVMware Cloud（VMC）などの製品と併用することを検討する場合、ソリューションの仕組みや関連する総所有コスト（TCO）と投資対効果（ROI）を把握して、これらの要素を考慮することが重要です。簡単ながらも見落しがちなのは、どの程度のベアメタルリソースを実際に使用できるのかという点です。以前に製品比較したときに紹介したのですが、マーケティング資料（大概は「チェックボックス」形式のスライド）を比較して、記載されているままの価値を真に受けると、アーキテクチャーやサイジングに関して容量や回復力、パフォーマンスなどの重要な要素を検討する際に、誤った認識を前提としてしまう可能性があります。AWS i3.metalでVMCを使用する場合について、簡単な例を紹介します。AWSでi3.metalを使用した3ノードVMCクラスターVMCで31.1TBの物理容量が提供されているのが分かります。VMCは「ディスクグループ」を使用するvSANをベースとしており、「ディスクグループ」ごとに「キャッシュ」ドライブが必要です。VMCに対して、VMwareでは2つのディスクグループを使用することを選択しているため、キャッシュドライブとキャパシティドライブの比率は1対3になります。3ノードVMCクラスターのディスクグループ構成（i3.metal）次に、Nutanix Clusters on AWSを使用する場合の、使用可能な容量について紹介します。 Nutanix AOSのおかげで、3つのi3.metalノードで39.8TBが提供されており、VMCの場合よりも24.5%多くなっています。小規模な3ノード環境でも、AWSでi3.metalインスタンスを使用する場合は、Nutanix ClustersのほうがROIがはるかに高くなることが明らかです。その理由は、Nutanix AOSでは、キャッシュドライブとキャパシティドライブという、アーキテクチャー上の欠陥を持つ時代遅れの概念を適用していないためです。Nutanixノード内のすべてのフラッシュデバイスが書き込みと読み取りの

4540

4 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

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

8220

4 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

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

7720

4 years ago

YukiYoshidaExplorer

posted in 日本語フォーラム (Japanese)

HYCUによるNutanix Cluster on AWSの統合データ保護

こんにちは、HYCU（ハイク）の吉田です。当ブログは2020年8月12日にHYCUプロダクト部門のVPであるSubbiah Sundaramによるブログの翻訳版になります。原文はこちらオンプレミスとクラウドの両環境にNutanixを導入し、稼働している仮想マシンとアプリケーションに対し真のマルチクラウド・データ保護を必要とするNutanixのお客様には、HYCUが役立ちます。まず、Nutanix Cluster on AWSの一般提供開始に関する最近の発表について、Nutanixチームにおめでとうございますと言わせてください。これにより、Nutanixのエンタープライズ・クラウドインフラ・ソフトウェアとサービスは、AWSのベアメタルEC2インスタンスで実行できるようになりました。 Nutanixインフラストラクチャをクラウドで実行する理由について疑問がある場合は、ユースケースを注意深く検討する必要があります。Nutanixクラスタをクラウドで実行すべき最適な3つの使用例を次に示します。クラウドバースト：多くの企業は、ピークシーズンにワークロードが急激に増加するため、それらを実行する上で投資対効果の高い方法が必要です。オンデマンドの災害復旧：ご存じのとおり、災害復旧（DR）計画は必須ですが、いつ起こるか分からない災害対策にインフラストラクチャのコストを2倍にすることは、経済的にあまり意味がありません。その為、投資対効果の高いDR計画の重要性が不可欠です。高度なテスト/開発環境：本番環境に移行する前に、実際のシナリオでアプリケーションとインフラストラクチャをテストすることが不可欠です。クラウドを活用することで、「追加の」必要な予備容量だけで実行できます。 HYCUは、Nutanix Clusters on AWSに対し、検証済み且つ正式にサポートする、最初のデータ保護ソリューションの戦略的テクノロジーパートナーになりました！これは、HYCUとNutanixの業界初及び独自の対応に基づいています。Nutanixとの戦略的テクノロジーパートナーシップにより、製品開発段階からNutanixチームと緊密に連携することで、Nutanix Clusters on AWS のリリース日にHYCUも利用可能であることを確認できました！これまでと同様、HYCUは、Nutan

3690

4 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

Nutanix Clusters: マルチクラウド時代のハイブリッドクラウドインフラストラクチャ NutanixはAmazon Web Services上でも利用可能に

本記事は2020年8月10日に Vidhi Taneja氏と Sahil M Bansal氏が投稿した記事の翻訳版です。原文はこちら。今日のデジタルイノベーションの時代においてはこの数ヶ月のこれまでよりも多くことががリモートワークで行われているということと、ITチームは彼ら自身も完全にリモートで働きながら、ビジネスニーズをサポートするためにより迅速なイノベーションにフォーカスするということが同時に行われています。ITにおける課題である集中的なコントロールを維持しながら、迅速に展開を行うということを実現するため、AWS、Azure、GCP、その他のようなパブリッククラウドの採用が増加しています。ITチームは自身のオンプレミスの環境とそのスキルセットを自身が選択したパブリッククラウドへと拡張、パブリッククラウドサービスの恩恵を享受しつつ、統合インフラストラクチャ管理機構を維持するという必要性に迫られています。こうしたソリューションは単なるよくあるハイブリッドソリューションまたはマルチクラウドソリューションではありえません。それは完全なハイブリッド&マルチクラウドソリューションでなければならないのです。Nutanix Clustersはシームレスなハイブリッドクラウド環境を実現する最新の製品で、パブリッククラウドとネイティブに統合されています。クラウドネイティブサービスとのダイレクトな低遅延なアクセスを提供し、さらに想定通りのNutanixのしなやかさ、効率性、パフォーマンスを備えています。ソリューションはデータセンターのキャパシティをパブリッククラウドの自在性を利用して迅速に拡張することに特化しており、プライベートクラウドとパブリッククラウドにまたがって同じスキルとツールを活用し、運用効率を最大化する事ができます。ハイブリッドとマルチクラウド時代のためのNutanixクラウドプラットフォームNutanix Clustersはオンプレミスとパブリッククラウド環境の間で一貫したエクスペリエンスを提供できるようにデザインされています。これらの環境間をリスク、コスト、アプリケーションのリファクタにかかる時間なく移動させることが出来、その下のクラウドへのあらゆるロックインからの自由を完全に成し遂げることが出来ます。Nutanix Clustersの機能とメリットNuta

4810

4 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

Nutanixクラスタ内にContrail SDNコントローラーを展開する

本記事はNutanixのEnterprise ArchitectのAmin Aflatoonian氏によって2020年7月30日にNEXTコミュニティに投稿された記事の翻訳版です。原文はこちら。以前の記事の中で、AHVクラスタへのContrail統合のアーキテクチャ上の概要をお伝えしました。今回の記事ではこのコントローラーの展開について詳細にお話していきます。仮想マシンネットワークと仮想マシン作成の詳細についてはこの次の記事でお話します。展開Contrail on AHVの展開についてご説明するために、我々は3ノードのNutanixクラスタ環境で構成されているラボを利用します。ラボのアーキテクチャについては以下の図に示します。Contrail AHV ラボアーキテクチャContrailのコントローラーのHAは必要ないので、1台のContrailコントローラー仮想マシンと3台のvRouter仮想マシンのみを展開します(各々のノードに1台のvRouter)。Contrailの展開にはAnsibleを利用しました。このラボ上にAnsible deployer仮想マシン(Contrail deployerと呼びます)も作成し、これで展開ライフサイクルを管理します。このためにNutanixクラスタ上にprovisioningネットワークを作成し、このネットワークにすべてのContrail仮想マシン(コントローラーとvRouter)を接続します。以下の図はラボのネットワーク構成を顕したものです。Contrail AHV ラボ - ネットワーク構成ラボの準備以下のテーブルはContrail仮想マシンの展開に資料したこのラボのネットワーク構成を顕しています。ラボのネットワーク構成オーバーレイブリッジとvRouterオーバーレイネットワークContrail仮想マシンを展開する前に、すべてのNutanixノード上にオーバーレイブリッジ(brOvly)を作成します。このブリッジは隔離されており、物理NICや他のOVSブリッジとは一切接続されていません。このブリッジを作成するためにはCVMからallsshコマンドを利用することが出来ます。オーバーレイブリッジを作成した後には、vRouter仮想マシンとこのブリッジを接続するオーバーレイネットワークを作成します。このブリッジを作成するため

5090

4 years ago

YukiYoshidaExplorer

posted in 日本語フォーラム (Japanese)

HYCU for Nutanix on VMware ESXi

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

9650

4 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

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

7600

4 years ago

YukiYoshidaExplorer

posted in 日本語フォーラム (Japanese)

Nutanix Filesを最適にバックアップ

こんにちは、HYCU（ハイク）の吉田です。 Nutanix環境のデータ保護についてお話を伺う機会が増えてきましたが、その中でFilesのバックアップ要件が多いようですので、今回Filesのバックアップについて書きたいと思います。 HYCUは45日間使用できる評価版をご提供しております。フリートライアルのご依頼はこちらから https://www.hycu.com/tryhycu/ とにかくすぐに試したいという方は、Nutanix Test Driveから申請することで、Nutanix Mine with HYCUのデモ環境が触れます。 https://www.nutanix.com/jp/test-drive-hyperconverged-infrastructure Nutanix Filesの環境ではありませんが、操作イメージは掴めると思います。さて、本題に入ります。今回のシナリオはNutanix Filesのバックアップです。 HYCUは、ネイティブのCFT（Change File Tracking）APIを使用してNutanix Filesに完全に統合されたバックアップおよび復元機能を提供する最初のソリューションです。 NDMPのような従来型のバックアップはファイルサーバーに大きな負荷をかけていて、変更されたファイルを識別するためにファイルツリー全体を読み取る必要がありますが、HYCUはCFTを使用して、変更されたファイル情報を即座に取得することができます。また、Point-in-timeバックアップ（仮にバックアップに時間が掛かったとしても、どの時点のファイル／フォルダをバックアップしたか把握）が可能です。尚、このCFT対応ですが、HYCU以外ではあと１社しか対応しておらず、HYCUとNutanixが密に連携していることを証明しています。 HYCUによるNutanix Filesバックアップの特長はこちらです。 CFTを使用することで高速増分バックアップとPint-in-timeバックアップを実現 Nutanixスナップショットとの連携（スナップショットからのバックアップ取得により、使用中（オープン）のファイルもバックアップ可能） Nutanixスナップショットからの高速ファイル復元（スナップショ

12950

4 years ago

smzkstsNutanix Employee

posted in 日本語フォーラム (Japanese)

日本語フォーラムの使い方

皆さまこんにちは。 Nutanix Japanでテクニカルエバンジェリストをしている島崎です今までTetsuoMiyoshiのブログと化してした日本語フォーラムですが、せっかく日本語でのコミュニケーション用に設定されている場所なので、自由に質問やディスカッションが行える場にできれば、と思っています。というか、そもそもこのフォーラムの存在が知られてないですよねというわけで、今回は日本語フォーラム自体の存在を周知するのも兼ねて、日本語フォーラムの使い方を簡単に解説します！位置づけについてまず、こちらの日本語フォーラムは、Nutanix本社が運営するNutanix Community(前はNEXT Communityという表記だった気がする)のフォーラムの、サブフォーラムという位置づけです。閲覧は自由に行えますが、投稿や返信を行いたい場合にはMy Nutanixアカウント(無料)が必要となります。Nutanixの商用ユーザーの方や、Community Editionをダウンロードしたことがある方は既にアカウントをお持ち方と思いますが、サインアップはこちらから行えますので、まだアカウントをお持ちでない方は是非ご登録ください。サインアップした状態で日本語フォーラムのトップページを開くと、右側に[Subscribe]ボタンがあります。みなさん！！これは必ず押しておきましょう！！！Youtubeでいう「チャンネル登録してね！」ってやつです（※新しい投稿があった際にメール通知を受け取れます）なお、全世界共通のシステムであるため、日本語およびフランス語フォーラム以外でのコミュニケーションは、すべて英語で行われています。参加人数の母数が違いますので、英語のプロダクト/ソリューション別フォーラムを直接利用したほうがより多くの人の目に留まりますが、やはり日本人にとって言葉の壁は厚いですよね？そんなわけで、日本語でコミュニケーションしたいな～、というときには是非お気軽に、こちらのフォーラムをご利用ください。（※日本語とはいえ本社管轄のオフィシャルな場なので、本社側に「日本のコミュニティにこんなアクティブな人がいるよ！」という話をする際のソースにはしやすいかなと思います）投稿のしかた新しい投稿をしたいときは、右上の[Create Topic]をクリックすると、

43092

4 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

よろず相談所、はじめました!

すっかり某氏のブログと化しておりますが、ここは「フォーラム」です! Nutanixもしくはもう少し幅広くITインフラ・クラウドに関する疑問/質問を投稿してみんなで話し合いましょう!! せっかくなのでこちらでは自己紹介や、最近の在宅勤務でのおすすめ等↓に書いていくのはどうでしょう? まずはNutanix Technology Championのメンバーよろしくおねがいしまーす!

52687

4 years ago

sho.cntNutanix Employee

posted in 日本語フォーラム (Japanese)

Calm 3.0登場

本記事は2020年6月17日にMayank Gupta氏が投稿した記事の翻訳です。原文はこちら。 NutanixはNutanix Calm 3.0のリリースを発表できることを嬉しく思います。アップデートの全リストはこちらでご覧いただけますが、以下にいくつかのハイライトをご紹介したいと思います。 Nutanix Calmはご存知のように、開発者や運用チームのためのセルフサービスの仮想マシンとアプリケーションのライフサイクル管理、監視、標準化を提供します。発売以来、お客様はNutanix Calmを使用して、プライベートおよびパブリッククラウドのIaaS VMやビジネスアプリケーションの選択、プロビジョニング、管理を行ってきました。ランブック(指示書) 3.0で新たに追加されたNutanix Calmランブックは、ハイブリッドクラウドインフラストラクチャ内のインフラストラクチャとアプリケーション全体の自動化タスクのオーケストレーションを支援します。ランブックは、Nutanix Calmのブループリントによってすでに有効化されている仮想マシンやコンテナ、アプリケーションのライフサイクル管理以外のタスクを簡単かつスケーラブルにオーケストレーションする方法をユーザーに提供します。ランブックは、ロールベースのアクセスに基づいてエンドユーザーが手動で起動することも、REST APIを介してモニタリングツールやサービスデスクツールから起動して自動実行することもできます。ユースケース例: アップグレード、パッチ、ロードバランサやファイアウォール等の共有リソースに対するヘルスチェックや設定変更以前は、何百ものデータベースインスタンスにまたがる重要な脆弱性にパッチを当てるなどのタスクは、アプリケーションの各インスタンスにパッチを当てなければならないため、ブループリントを使って行うことは困難でした。ランブックは、何百ものアプリケーションインスタンス、または共有リソースのライフサイクル管理を簡素化します。ランブックは、"何をするか "と "どこでやるか "を定義するオーケストレーションタスクの集合体です。シェル/パワーシェルコマンド、変数、HTTPリクエスト、遅延、ループ、分岐タスクをサポートしています。その性質上、ランブックはアプリケーションのグルー

5930

4 years ago

YukiYoshidaExplorer

posted in 日本語フォーラム (Japanese)

リモート拠点をデータセンターで一括保護

5070

4 years ago

Page 6 / 9

Global Forums

Badges

Sign up

Login to the community

Scanning file for viruses.

This file cannot be downloaded