• 196 Topics
  • 185 Replies

196 Topics

パブリッククラウドの課題 – パート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/

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

こんにちは、HYCU(ハイク)の吉田です。   複数拠点、複数のNutanixクラスタ環境をお持ちの場合、どのようにバックアップやDRを実現するのでしょうか?最近続けてお問い合わせを受けていますので、今回書かせて頂きました。   HYCUは45日間使用できる評価版をご提供しておりますので、環境をお持ちの方は実際に触って頂くほうが分かりやすいと思います。 フリートライアルのご依頼はこちらから https://www.hycu.com/tryhycu/   とにかくすぐに試したいという方は、Nutanix Test Driveから申請することで、Nutanix Mine with HYCUのデモ環境が触れます。 https://www.nutanix.com/jp/test-drive-hyperconverged-infrastructure 2拠点構成ではありませんが、操作イメージは掴めると思います。   さて、本題に入ります。 今回のシナリオは2つの拠点、リモート拠点とデータセンターとします。 両サイトにNutanixクラスタが存在し、リモート拠点のデータ保護が目的です。   リモート拠点のバックアップだけであれば、リモート拠点にバックアップの仕組みを構築すればいいのですが、DRまで考慮するとデータセンターへデータを複製することを検討しないといけません。また、リモート拠点にIT担当者が居ない場合、バックアップの仕組みを日々どうやって運用するのか課題が出てきます。 そこで、Nutanixの”保護ドメイン”とHYCUの”Backup from Replica”を組み合わせることで、バックアップとDRの両方を実現します。 この構成のメリットはこちらです。 リモート拠点からバックアップデータをコピーしないため、WANを流れるデータ量を増やさない リモート拠点に何も展開しない(エージェントもプロキシも作業担当も不要) データはリモート拠点でもデータセンターでも、どこにでも復元可能   構築の流れは、 Nutanixで保護ドメインを作成し、リモート拠点のVMスナップショットをデータセンターへレプリケートする。NearSyncとAsyncどちらも可能。 HYCUのポリシー作成画面で、”Backup from Replica”オプ

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

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リクエスト、遅延、ループ、分岐タスクをサポートしています。その性質上、ランブックはアプリケーションのグルー

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デバイスをユーザースペースから直接アクセスできる

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

パブリッククラウドの課題 – パート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ノード内のすべてのフラッシュデバイスが書き込みと読み取りの

HYCUはNutanixを補完する秘伝のタレ

こんにちは、HYCU(俳句)の吉田です。   前回はNutanix Mine with HYCUのHYCUって何?について説明させて頂きました。これまでHYCUについてご存じなかった方もイメージを掴んで頂けたなら幸いです。 さて、その際に私はHYCUには面白い特徴が10あるとお伝えしました。 RTOを設定することで、決めた時間内にリカバリができるか予測を立てる データ保護の3-2-1ルールに従って、データをなくさないようにコピージョブやアーカイブジョブとシームレスに連携 Nutanixスナップショットの保持世代を指定し、迅速復旧に活用 CBT(変更ブロックトラッキング)を使ったVMのバックアップ CFT(変更ファイルトラッキング)を使ったNutanix Filesのバックアップ Nutanix ESXiからのStunフリーバックアップ 絶対にエージェントを使わずに(特許取得済み)、仮想マシン内のアプリケーションを自動検索・自動認識し、アプリケーションレベルの静止点を確保したバックアップ リモート拠点のマシンも、Nutanixのレプリケーション側から楽にバックアップ オンプレミスもクラウドも場所を問わない、バックアップの保存場所登録 ランサムウェアに強いセキュリティ対策 今回からは、少し深堀りしながらどうやってHYCUがNutanixを補完するのかお話ししたいと思います。   と、その前に・・・ HYCUではフリートライアル版をご提供しています。 45日間使えるキーが含まれていますので、是非お試しください。 フリートライアルのご依頼はこちらから https://www.hycu.com/tryhycu/   さて、HYCUの機能を一枚にまとめるとこんな感じです。 Nutanixを美味しくする秘伝のタレ   1.RTOを設定することで、決めた時間内にリカバリができるか予測を立てる HYCUのジョブはポリシーベースになっています。 このポリシー中に[RECOVER WITHIN]という設定がありますが、許容できるRTO(戻すまでに掛かる時間)を決めることができます。例えばこの値に6時間を入れると、復元タスクを開始して6時間以内で復元が完了するのか予測を立てます。 測定のベースとなるのは日々のバックアップ転送速度やバッ

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以外ではあと1社しか対応しておらず、HYCUとNutanixが密に連携していることを証明しています。   HYCUによるNutanix Filesバックアップの特長はこちらです。 CFTを使用することで高速増分バックアップとPint-in-timeバックアップを実現 Nutanixスナップショットとの連携(スナップショットからのバックアップ取得により、使用中(オープン)のファイルもバックアップ可能) Nutanixスナップショットからの高速ファイル復元(スナップショ

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:大規模環境での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つのノード

IT内製化を実現するITプロフェッショナル向け実践セミナー ー Xperience!

  ITにとっての新しい当たり前 この3ヶ月は我々全員にとって試練の時でした。ソーシャルディスタンス、屋内退避、オンライン授業、在宅勤務などなど – これらがすべてを「新しい当たり前」にしてしまいました。 ITに目を向けると – 皆さまのようなITプロフェッショナルにとっての新しい当たり前とは何でしょうか? 我々のCIOである Wendy M. Pfeifferはそれを「なぶり殺し」と表現します。今日、ITはこれまで以上に必要とされています – そして恐ろしいことに24時間365日要求にさらされます。あらゆる会社においてITプロフェッショナルは舞台裏でビジネスを支え続けています。これについて語る人は多くはありませんが、我々Nutanixはそれを理解し、皆さまをパンデミックにおけるヒーローだと思っています!   Xperience: 我々が見据える未来 Nutanixは我々の初めてのヴァーチャルイベント Xperience でITヒーロたちをたたえます。アメリカ地域では6月24日、それに続いてアジア・パフィックでは7月2日、日本では7月10日、ヨーロッパ・中東・インドでは7月16日に開催されます。是非、皆様ご参加いただき、ビジネス継続を再定義したITプロフェッショナル仲間と交流してください。イベントに参加されればNutanixがこの困難 – そしてその先で歩みをすすめる際に様々な面で皆さまの力になるということを確信していただけます。 イベントを少しだけ覗き見してみましょう。我々はSVP of Product and Solutions MarketingのMonica Kumarによるキーノートセッション「デジタルの未来へとつながる道」でキックオフします。CIO現職そして以前CIOを努めた2名 -- Nutanix CIOの Wendy M. PfeifferとNutanix Board Director、Investor、そして以前のWall Street CIOであるVirginia Gambaleを加え、Monicaは現状を乗り越え、ビジネスを将来に向けて継続して稼働させ続けるためにITが何をでき、何をすべきなのか議論を掘り下げます。CIOの観点からの洞察に満ちた「実践からの教訓」とそこから考える「その先」を是非聞いてみてください!   災

NutanixとHYCUでセキュリティ強化!ランサムウェアだって怖くない!

こんにちは、HYCU(ハイク)の吉田です。   前回は、10の特長のうち9つまでご紹介しましたので、今回は最後のセキュリティ対策についてご紹介したいと思います。   と、その前に・・・ HYCUでは45日間使えるフリートライアル版をご提供しています。是非お試しください。 フリートライアルのご依頼はこちらから。 https://www.hycu.com/tryhycu/   様々なバックアップベンダーがセキュリティ強化の一環として、イミュータブルストレージにデータを保存し、バックアップデータが安全であることを強調しています。それはその通りだと思いますが、では、データ保護基盤自体の脆弱性とか、日々の作業ミスや悪意のある操作からどうデータを守るのか?と言う視点でみると、ベンダーによって大きな違いがあると思います。この点について、HYCUの特長をご紹介したいと思います。   こちらがグローバルで使われているスライドです。   ちなみに、私が使っているスライドはこちら   レイアウトは異なりますが、意図するところは同じです。   それでは一つずつみていきましょう。(※前回のブログと重複する箇所があります。) 1.HYCUはNutanix上に展開するCentOSベースの仮想アプライアンス = バックアップサーバーです。また、カーネルやユーザースペースに対する脆弱性攻撃から防護するためにハードニングされています。OSを構築してバックアップソフトをインストールする製品と異なり、最初からセキュリティ対策がバッチリ施されているんですね。(そもそもLinuxはWindowsに比べて攻撃対象になりにくい?)構築が楽なのもありますが、OSの脆弱性を突かれた攻撃には強いと言えます。   2.以前のブログでも触れましたが、製品のアップグレードは5分でできます。https://next.nutanix.com/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%95%E3%82%A9%E3%83%BC%E3%83%A9%E3%83%A0-70/nutanix-mine-with-hycu%E3%81%AEhycu%E3%81%A3%E3%81%A6%E4%BD%95-37685 元々のマシンには手を加えずに名前を変えて保存しておきます。そして新

パブリッククラウドの課題 – パート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の顧客は、圧縮と重複排除

お客様にこれまで以上の選択肢を: HPE-Nutanixのパートナーシップの拡大

本記事はBrian Cox氏が2020年6月24日に投稿した記事の翻訳版です。 原文はこちら。   Hewlett Packard Enterprise(HPE)とNutanixのグローバルパートナーシップが始まってから1年が過ぎ、我々は新たな製品とソリューション、新しいお客様向けのプロモーション、そしてお客様からのご注文が増えていくのを目にしてきました。 このパートナーシップは出荷開始からほんの僅か、3四半期で順調に立ち上がりました。実際、ウォールストリートのアナリストとの我々の直近の四半期の業績についてのディスカッションの中で、NutanixのCFOであるDustin WilliamsはNutanixのHPE DX関連のビジネスの年間契約額(annual contract value - ACV)は四半期ごとに16%の勢いで伸びていると述べています。 HPE ProLiant DXとNutanixでの追加の構成、ユースケース、そしてワークロードを含む新たな機能がこれまで以上にお客様の選択肢を広げます。新しい選択肢の中には: OLTPやVDIワークロードにより優れた価格/性能を提供するAMDベースのシステム 厳しいコンピューティング環境に対応した耐久性システム SAP ERPシステムへの認証取得 非構造化データ向けの高キャパシティストレージ よく利用されるバックアップソフトウェアとのターンキー型データ保護   HPE ProLiant DX385システム内に搭載したAMD EPYCプロセッサによる、より優れた価格/性能エコノミクス HPE ProLiant DXシステムに搭載された新世代のAMD EPYC 7002サーバープロセッサは他の業界標準アーキテクチャプロセッサに対し、カエル飛びのような能力の飛躍を遂げ、お客様がお支払いになった対価に対してこれまでにないパフォーマンス向上を提供します。お客様はより少ない数のシステムの購入でなお、これまでよりも早く負えなければならない仕事を完了させることができます。これはAMD EPYCプロセッサーのソケットあたりの数多くのコアとストレージへのネイティブ接続のための広域なI/Oチャネルによって実現されています。結果として、オンライントランザクション処理、データ分析、仮想デスクトップインフラストラクチャ

パブリッククラウドの課題 – パート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」の中で、キャッシュドライブに関して以下のように述べています。高耐久性フラッシュデバイ

Test DriveでNutanix Mine with HYCUが試せるようになりました!

こんにちは、HYCU(ハイク)の吉田です。   毎週立て続けのブログになりますが、ご案内させてください。 HYCUは、45日間使用できる評価版をご提供しております。今月から3日間利用できるオンラインのラーニングセンター(ハンズオン環境)のサービスを開始しました。 そして、第三弾として、なんとTest DriveでNutanix Mine with HYCUが試せるようになりました! 評価版とハンズオン環境についてはまた次回とし、今回はTest DriveでNutanix Mine with HYCUを触った内容をご紹介します。 ご存じの通り、Nutanix Test DriveはすぐにHCI環境に触れることができるデモ環境です。以下のサイトから申し込みできます。 https://www.nutanix.com/jp/test-drive-hyperconverged-infrastructure 必要事項(名前やメールアドレス等)を入力し、[TEST DRIVEを起動]ボタンをクリックします。   ちなみに、英語サイトはこちらです。 https://www.nutanix.com/test-drive-simplified-backup-with-hycu?utm_source=hycu_social&utm_medium=referral&utm_campaign=test-drive-mine   すぐにメールが届きました。Test Driveの環境が整っていますので、メール本文にある[Access Your Test Drive]ボタンをクリックします。   [Ensure Business Continuity]を選択します。   [Nutanix Mine with HYCU]を発見!こちらを選択します。   [Welcome to Nutanix Mine with HYCU]の画面です。   Nutanix Prism画面が開きます。   ガイドツアーに従い、設定・操作方法を確認します。 最初はMineクラスタの設定・操作方法になります。   HYCUの実体は仮想アプライアンスで、HYCUバックアップコントローラーVMが作成されていることを確認できます。   バックアップデータの保

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

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

パブリッククラウドの課題 – パート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では、クラスター内の使用可能なハードウェアが最大限に利用されない

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仮想マシンとこのブリッジを接続するオーバーレイネットワークを作成します。このブリッジを作成するため

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

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

本記事は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の進化、ソフトウェアサブスクリプションモデルへの転換へ新たなるステージをもたらす年になり、我々のハイパーコンバージドインフラストラクチャに置けるリーダーシップを

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

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

Badges

Show all badges