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