Global Forums | Nutanix Community
Skip to main content
226 Topics

Nutanixは、LCM(Life Cycle Management)という機能を提供しており、Prism Web Consoleから操作できます。LCMを使用すると、クラスターのソフトウェアやファームウェアの各バージョン情報を取得して一覧表示したり、任意のコンポーネントをバージョンアップしたりすることが可能です。 このLCMを使用して、各ソフトウェアやファームウェアをアップグレードする際に、場合によっては以下の状況に遭遇することがあります。 このように [lcm] の [Updates] タブで、特定のソフトウェアやフォームウェアのアップグレードが無効化されて選択できない状態になることがあります。無効になったチェックボックスへカーソルを当てると、以下のように表示されます。 This update is disabled since there is an emergency update available. Perform that emergency update prior to attempting this. Refer to KB 9111 more details. (利用可能な緊急のアップデートがあるためこのアップデートは無効化されています。このアップデートを試みる前に、緊急のアップデートを先に実行してください。詳細は KB9111 を参照) これは、Nutanixが緊急にアップグレードすることが必要と分類した特定のバージョンのソフトウェアやファームウェアがクラスターで実行されている場合に、表示されるようです。その特定のソフトウェアやファームウェアをアップグレードするまで、その他のアップグレードは利用できない仕組みになっています。 ちなみに「KB 9111」を参照すると、緊急アップデートが必要と分類されているコンポーネントとその理由が確認できます。 KB 9111: LCM update is disabled since there is an emergency update available 上記の画像の環境では、実行しているAOSのバージョンが「5.15.5」であり、CVMの起動に失敗する不具合が確認されているために、AOSの緊急アップデートが必要と分類されていました。 今回は例として、AOSを「5.15.5」→「5.15.6」へアップグ

本記事はHarshit Agarwal氏 と Samuel Gaver氏による2021年12月9日のnutanix.devへの投稿の翻訳版です。 原文はこちら。 はじめに Nutanixはハイパーコンバージドプラットフォームですが、その全てのサービス(ストレージサービスを含む)は コントローラー VM (CVM) と呼ばれる特殊な仮想マシン(VM)上で稼働しています。このCVMは現在カーネルバージョン3.10のCentOS Linuxディストリビューションで稼働しています。残念なことにこのカーネルのバージョンは結構古いもので、いくつかの課題を抱えており、このことが今回、Nutanixが新しいバージョンへとアップグレードをする動機となっています。 なぜアップグレードが必要か ? バックポート作業の辛さを軽減する: バグやセキュリティ問題に出くわした場合、我々はより新しいバージョンのカーネルから、3.10.xへと変更をバックポートする必要がありました。これらのバックポートは大きく時間がかかるもので、開発者にとってはこうした変更が適用可能で、正しくポーティングされたのかを確認する必要のある大変な作業を必要とします。加えて、マニュアルでのバックポート作業はQAチームにもそれぞれの変更をテストして検証するという大きな負担となっていました。 新たな機能のメリットを享受する : より新しいカーネルでは io_uringとBBR、我々のI/Oスタック内でのCPU効率と性能の改善が含まれており、より要件の高いワークロードを取り回す事ができるようになります。 LTSサポートへの追従 : 3.10のサポートは2017年に終了しています。最近のLTSカーネルを利用することで我々はLinuxコミュニティのサポートを受けやすくなります、Linuxコミュニティでは必要なバグ修正がすべてバックポートされています。LTS系列へと合わせることで、マニュアルで修正を監視してそれらをバックポートするよりも、劇的な改善が見込まれます。 パフォーマンスの改善 : AMD Zen上での優れたコンピュート性能と ext4 における高速コミット の2つが、新たなカーネルを利用することで我々が同じハードウェア上でもより優れたパフォーマンスを達成することに貢献するカーネルの改善点です。 問題はなにか ? 作業を始めるに

本記事は2021年12月14日にJosh Odgers氏が投稿した記事の翻訳版です。 原文はこちら。 以前にNutanix AOSソリューションが提供するリビルドのパフォーマンスを含む拡張性、回復力、及び性能についての多くの優位性の詳細について述べてきました。これらはNutanix環境が障害発生後に自分自身で、完全な回復力を備えた状態にまでのリカバリを、可能な限り早く実行することを保証しています。 これはNutanix環境を支えるキャパシティとパフォーマンスに応じてデータをクラスタ全体で動的に分散させるAOSストレージファブリックによって可能になっています。 AOSストレージファブリックにはAOSがデータを1MB および 4MBのエクステントで保存するのとは反対に、未発達なHCI製品がデータの保存に巨大なオブジェクトを利用しているために潜在的に発生してしまう、個々のノードのキャパシティの問題に対して未然に対処する事ができる、という点以外にも多くの優位性があります。 AOS 6.1では、複数のノードを同時に取り外す事ができる新しい機能が搭載されますが、これを使うことによって同じAOSアーキテクチャ上で、合理的な時間内に効率的に複数のノードを取り外すことができるようになります。 ノードの取り外しは管理者が各々のノードの進捗状況を監視する必要なく行われ、1ノードが完了すると、それに続くノードの取り外しが前のノードと同様に行われます。 Nutanix Prism UI内でマルチノードの取り外しを実行するサンプル 一つずつ取り外すのと比べてどれぐらい効率的なのか ? たとえば、 8 ノードのクラスタがあり、そこから2もしくはそれ以上のノードを取り外すときのことを考えてみましょう。 以前の AOS と、 Nutanix 以外の HCI プラットフォームではノード 8 からクラスタ内の他のノードへ移動されていました。 AOS はこれを、データを残されたすべてのノードに細やかなレベルでバランスしながら効率的に実施していましたが、それに続くノード7の取り外し時にはノード8に格納されていたデータのいくらかがノード 7 上に配置されており、再度データ移動の対象となってしまっていました。データを 2 回 ( もしくはもっと ) 移動させることは不必要ですし、クラスタへのオーバーヘッドと処理

本記事は Chris Rasmussen 氏が 2020 年 11 月 16 日に nutanix.dev に投稿した記事の翻訳版です。 原文は こちら 。 Nutanix上での自動化を考えた場合、これは仮想マシンやイメージだけにとどまりません。Nutanix Calmでアプリケーションライフサイクル管理を、KarbonでKubernetesクラスタを自動化することができます。これらについてはコンポーネントや製品について、多くの記事とコードのサンプルでカバーされています。 ほとんどすべてのアプリケーションの一部ではあるものの、未だにNutanix.devでカバーされていないコンポーネントがあります ― データベースです。読者の一部はNutanix Eraが「あらゆるクラウドのデータベース運用をシンプル化」するものであるということについてご存知でしょう。Eraがどのようなものかについて更に詳しくはNutanix.comの記載を参照していきましょう : パブリック、プライベート、そしてハイブリッドクラウドにおいて、Eraは単一コンソールからのシンプルで、高速、一貫した管理によって思い通りのデータベース管理を実現します。Eraによって劇的に稼働時間が改善され、退屈なマニュアル操作は低減され、コスト効率性が高まります。この次世代のクラウドとクラスタをまたいだ1-クリックのシンプルさが実現されます。これこそがEraが実現する新時代なのです。 – https://www.nutanix.com/products/era しかしながら、もしもあなたがアプリケーションを設計する立場であるのなら、Nutanix Eraによって提供される優れたメリットをプログラマティックな形で享受したいと考えますよね? この記事はそんな皆様のためのものです。 私の環境 私がこの記事を2週間ほど前に書き始めたときには、Nutanix Eraのヴァージョンは1.3でした。最も新しいNutanix Eraのヴァージョンは2020年11月16日時点で2.0.1(2021年12月8日の翻訳時の最新は2.3)です。私の開発環境内ではこのヴァージョン(2.0.1)が利用されています。これ以降のEraのヴァージョンではユーザーインターフェイスが変更されている場合があります。 もしもこれまでに環境内にNutanix E

本記事はJarian Gibson氏の記事の翻訳版です。 原文はこちら。 今日の分散された職場環境を考えると、あらゆる場所から生産的に働ける、アプリケーション、デスクトップ、そしてデータにセキュアにリモートアクセスができる職場環境を迅速に用意できる能力は必要不可欠です。直近の数ヶ月、増加したリモートワークの要件によって、IT部門は分散された職場環境のニーズを迅速にサポートすることにフォーカスを余儀なくされました。IT部門が増加した分散された職場環境のニーズのために迅速にインフラストラクチャを展開できるようにするため、組織はAWS、Azure、GCPやその他のパブリッククラウドの採用を増加させています。IT部門は分散職場環境のニーズを満たすための ハイブリッド そして マルチクラウド ソリューションを探し求めています。Nutanix ClustersはNutanixのクラウドOSであるAOSをパブリッククラウドのサーバー上で稼働させ、同じ管理プレーンを利用して、パブリッククラウドにネイティブに統合されたシームレスなハイブリッドクラウド環境を実現します。 Nutanixはお客様の選択肢と Citrix Virtual Apps and Desktops が稼働するハイブリッドクラウド環境を実現します。Nutanix Clusters上のCitrix Virtual Apps and Desktopsによって、IT部門はCitrixワークロードのための迅速な分散された職場環境のサポートを実現することができます。この共同ソリューションによって、お客様は、これまでデータセンター内で提供していたのと同じ機能をクラウド内で実現することができます。 Nutanix Clusters上のCitrix Virtual Apps and Desktopsでは既存のNutanixのお客様は慣れ親しんだ同じ管理インターフェイスを提供します。Nutanix Clusters上のCitrix Virtual Apps and Desktopの管理はオンプレミスのNutanixインフラストラクチャ上での管理と見分けがつきません。実際のところ、オンプレミスのNutanixを管理するのに利用している同じPrism Centrarlインターフェイスを利用して、Nutanix Clustersを管理します

本記事は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上で稼働させることで、フルスタックの、エンタープライズ向けにサポートされるス

本記事は 2018 年 11 月 22 日に Josh Odgers 氏が投稿した記事の翻訳版です。 原文は こちら 。本シリーズの索引は こちら 。 このシリーズでは、 Nutanix プラットフォームがいかに優れた回復力を有しているかを示す幅広いトピックを取り上げてきました。これには、障害時であっても新規書き込みのためのデータ整合性を維持できることや、障害後に問題を引き起こす次の障害のリスクを最小限にするために、タイムリーにリビルドする能力が含まれます。 このような情報があるにもかかわらず、競合ベンダーは、「 2 つのコピーが失われてしまえば、リビルド時間は問題の本質ではない」といった主張で、 Nutanix が提供するデータインテグリティ(データ整合性・一貫性の担保の仕組み)の信用を貶めようとしています。現実的には、データの両方のコピーが同時に失われる可能性は低く、これは安易な主張です。しかし、もちろん Nutanix は、最大限の回復力を求めるお客様のために、 3 つのデータのコピーを保存可能な RF3 もサポートしています。 それでは、パート 10 に進みましょう。ここでは、ディスクスクラビングとチェックサムという 2 つの重要なトピックについて説明します。この 2 つの重要なトピックは、 RF2 と RF3 の構成が非常に高い回復力を持ち、データが失われる可能性が極めて低いことを保証するものです。 まず、チェックサムについてですが、チェックサムとは何でしょうか?チェックサムは、書き込み操作中に作成された少量のデータであり、後で(チェックサムのデータを)読み込んで、実際のデータが完全なままであるかどうか(つまり、破損していないかどうか)を確認できます。 次に、ディスクスクラビングですが、データの整合性を定期的にチェックするバックグラウンドタスクであり、エラーが検出された場合、ディスクスクラビングはエラー修正プロセスを開始して、修正可能な単独のエラーを修正します。 Nutanix は、すべての書き込み操作( RF2 または RF3 )に対してチェックサムを実行し、すべての読み取り操作に対してチェックサムを検証します。これは、データの整合性検証が IO 処理の一部であり、スキップしたりオフにしたりすることができないことを意味します。 データの整合性は、あらゆる

本記事は2018年6月20日にJosh Odgers氏が投稿した記事の日本語版です。 原文はこちら。本シリーズの索引はこちら。 Nutanixには、いくつもの非常に重要でユニークな自己修復機能があります。これらによって従来からのSAN/NAS装置だけでなく、他のHCI製品とも差別化されています。 Nutanixは、SSD/HDD/NVMeデバイスの損失やノードの障害を完全に自動で自己修復するだけでなく、ユーザーの介入なしに管理スタック(PRISM)を完全に復旧させることができます。 まず最初に、 デバイスやノードの障害からデータを自己修復する方法 について説明します。 従来のデュアルコントローラーのSANと、平均的*なサイズの8ノードのNutanixクラスターを単純に比較してみましょう。 *平均値は、全世界の顧客数を販売台数で割って算出しています。 1台のストレージコントローラが故障した場合、SAN/NASでは回復力が失われます。ベンダーがコンポーネントを交換し、回復力(多くの場合は性能劣化も)を取り戻すまでは、SLA(サービスレベルアグリーメント)を守るために奔走しなければなりません。 Nutanixと比較すると、8台のストレージコントローラのうち1台(12.5%)だけがオフラインになり、7台がワークロードへのサービスを継続し、回復力を自動的に取り戻すことができます(パート1で示したように、通常は分単位で回復します)。 以前、「ハードウェアサポート契約と24時間365日のオンサイトが不要な理由」というブログで、このコンセプトを詳しく紹介しました。簡単に言うと、プラットフォームの回復力を取り戻すために、新しい交換部品の到着や、さらに悪いことに人手に依存している場合、ハードウェアの交換やマニュアルでの作業なしに完全な回復力を持つ状態に自己回復できるプラットフォームに比べて、ダウンタイムやデータロスのリスクは飛躍的に高くなります。 「もっと小さな(Nutanixの)クラスターではどうか」と反論する人(あるいは競合他社)もいるかもしれません。 よくぞ聞いてくださいました。4ノードのクラスターであっても、ノード障害が発生すると、ハードウェアの交換やマニュアルでの作業なしに、完全に自己回復して回復力のある3ノードのクラスターになります。 Nutanix環境で、別のノード障害が

本記事は2018年6月19日に Josh Odgers 氏が投稿した記事の翻訳版です。 原文はこちら。本シリーズの牽引はこちら。 RF2についてはパート1で、RF3についてはパート3で説明したように、ADSFの回復力を議論する際の重要な要素は、ドライブやノードに障害が発生した場合に、設定されたレジリエンシーファクターに準拠した状態に回復する速度です。 それでは、第1回と第3回の内容を簡単に振り返ってから、RF3とイレイジャーコーディング(EC-X)を使用した場合のノード障害に対するADSFのパフォーマンスの例を見てみましょう。 リビルド処理は、設定されているレジリエンシーファクターや EC-X などのデータ削減にかかわらず、すべてのノードとドライブに完全に分散された処理 (多対多の処理)であるため、非常に高速であると同時に、ノードごとの作業負荷が最小限に抑えられるため、ボトルネックを回避し、稼働中のワークロードへの影響を軽減することができます。 リビルドの性能は、クラスターの規模、ドライブの数や種類(NVMe、SATA-SSD、DAS-SATAなど)、さらにはCPUの世代やネットワークの接続性など、さまざまな要因に左右されることを忘れてはいけませんが、それを踏まえた上で、以下のハードウェアを使った例を紹介します。 テスト環境は15ノードのクラスターで、Ivy Bridge 2560プロセッサ(2013年第3四半期発売)を搭載したNX-6050およびNX-3050ノードなど、約5年前のハードウェアが混在しており、各ノードにはサイズの異なる6つのSATA-SSDと2つの10GbEネットワークインターフェースが搭載されています。 イレイジャーコーディングはRF2やRF3よりも多くの計算オーバーヘッドを必要とするため、より高速なプロセッサを使用することでリビルド速度に大きな差が出ます。レジリエンシーファクターは単にレプリカをコピーするだけです(つまり、パリティの計算は必要ありません)。 今回のテストでは、クラスターをRF3とイレイジャーコーディングで構成しました。 これまでのテストと同様に、IPMIインターフェースを使用し、以下のように「Power off server - immediate」オプションを使用してノード障害をシミュレートします。これは、物理的なサーバーの背

本記事は2018年6月11日に Josh Odgers 氏が投稿した記事の翻訳版です。 原文はこちら。本シリーズの牽引はこちら。 パート1から4をまだ確認していない場合はぜひご確認ください。これらは重要なレジリエンシーファクターの障害からの回復速度に関するもので、その場でRF2からRF3へ、もしくは同じ回復力レベルを提供しながら容量を節約するイレイジャーコーディング(EC-X)へと変換することで、回復力を向上させることについて解説しています。 パート5と6では、CVM のメンテナンスまたは障害時に読み取りと書き込みI/Oがどのように機能するか解説し、このシリーズのパート 7 では、ハイパーバイザー (ESXi、Hyper-V、XenServer、AHV) のアップグレードが読み取りと書き込み I/O にどのような影響を与えるかについて説明します。 この投稿ではパート5と6を頻繁に参照するので、このブログを完全に理解するには前の投稿をよく読んでください。 パート5とパート6で説明したように、CVM の状況に関係なく、読み取りおよび書き込み I/O は引き続き提供され、データは設定されたレジリエンシーファクターに準拠したままです。 ハイパーバイザーをアップグレードした場合、仮想マシンはまずノードから移行し、通常通りIO操作を続行します。ハイパーバイザーに障害が発生した場合、仮想マシンは HA によって再起動され、通常のIO操作を再開します。 ハイパーバイザー (またはノード) の障害またはハイパーバイザーのアップグレードのいずれの場合でも、最終的にはいずれのシナリオにおいても、仮想マシンを新しいノードで実行し、元のノード (下の図のノード 1) がオフラインになり、ローカルドライブ上のデータが一定の期間利用できなくなります。 このシナリオでは、読み取り I/O はどのように機能しますか? パート5での説明と同じ方法で読み取りはリモートで処理されます。または、2 番目のレプリカが仮想マシンが移行された (または HA によって再始動された) ノード上に存在する場合、読み取りはローカルで行われます。リモートでの読み取りが発生した際に、1MB のエクステントはローカライズされ、その後の読み取りはローカルで実行されるようになります。 書き込みI/Oはどうですか? パート6と同様

本記事は2021年9月21日にJeremy Launier氏が投稿した記事の翻訳版です。 原文はこちら。.NEXT 2021に関する記事の索引はこちら。 今現在、データベースはほぼすべての組織に存在すると言っても言い過ぎではありません ー データベースは至るところにあります ー それ無しでは業務もそして競争に打ち勝つこともできません。組織の規模やその複雑さに関係なく、データベースのアナリストと管理者は疲れる暇もなくデータを管理し、データベースが提供するビジネス価値 ー 競争優位性に関する分析や戦略的な活動の推進 ー を展開することでステークホルダーをサポートしています。 NutanixはIDCに、データベースの管理にまつわる課題や複雑さについて議論したInfoBrief *の執筆を委託しました。その結果は目を見開くべきものでした : 73%の組織はオンプレミスとクラウド環境とで異なる手順でデータベースの管理を行っていました。 75%のリレーショナル・データベース(RDBMS)環境は依然としてプライベートクラウドに残されていました。 63%の回答者はプライベートとパブリッククラウドをまたがった共通のデータベース管理が非常に有用であると信じていると回答しました。 多くの組織はデータベースのライフサイクルの管理の複雑性に消耗しており、特にこの調査によってオンプレミスでこれが顕著であることが明らかになりました。これには新たなデータベースの展開、既存のデータベースの管理、そしてデータベースのライフサイクルに関連するバックアップ/リカバリ、アップグレード、パッチ、拡張、そしてデータ管理などの多くの日々のタスクが含まれています。 Nutanixは3年ほど前にEra®データ管理ソフトウェアをリリースし、データベース管理にシンプルさと自動化をもたらしました。我々はお客様がデータベースサービスをAPI経由でオンプレミスでも、クラウド上でも、もしくはクラウドをまたぐ形でも一貫したやり方で、運用し、利用する、そうした未来を思い描いています。我々はこれをお客様に対してデータベースにまつわるタスクを透過的なやり方で自動化することでOSとデータベースのヴァージョン、そしてカスタマイズ性を維持したまま、自動化による効果を享受できるようにすることで提供しようとしています。製品の立ち上げ以降、Nuta

本記事は2021年9月21日にTuhina Goel氏が投稿した記事の翻訳版です。 原文はこちら。.NEXT 2021に関する記事の索引はこちら。 Nutanix ユニファイドストレージ - 非構造化データ管理における新たなマイルストーン Nutanixは長きに渡って、「ユニファイドストレージ(統合ストレージ)」プラットフォームを提供し、その形がどのようなものであれ(構造化データ または 非構造化データ)、それがどのような場所であれ ー オンプレミス、パブリッククラウド、もしくはエッジ上 ー お客さまのデータを管理し、保護できるとお約束してきました。このビジョンを胸に、お客様のデータ管理をシンプル化でき、データ分析ワークロードから勝ちを得るまでの時間を短縮、爆発的なデータの成長を管理し、セキュリティリスクからそのデータを保護することのできるNutanix Unified Storage™ソリューションの新たな機能をアナウンスできることを大変喜ばしく思います。この最新のリリースの基盤は ー 2つの製品をまたいだデータのファイフサイクル全体の統合 ー Nutanix Files™ および Nutanix Objects™で ーお客様へ完全に統合されたストレージエクスペリエンスを提供いたします。 シームレスなデータのライフサイクル管理 Nutanix Files 4.0ではSmartTier™(スマート階層化)が導入され、NASシェアからNutanix Objects(または、Amazon S3のようなあらゆるS3互換エンドポイント)を含むプライベートもしくはパブリッククラウドへの透過的なデータ階層化機能を提供します 。この新しい機能ではお客様はNutanix Filesから長期保存用のデータストレージとしてNutanix Objectsへとデータを移行し、コストを削減する一方で、引き続き単一インターフェイスからのアクセスを維持することができます。これによって、デジタル文書、音声や動画ファイル、アクティブ/パッシブアーカイブのような古くなったデータの保存についてのコストを下げ、ビジネスや規制要件を満たすことができます。 これを更にもう一歩を進めると、「凍結」オブジェクトをパブリッククラウドへと移動させ、その非常に安価なアーカイブむけの価格を活用することで、長期的なコストを

本記事は2021年9月21日にNutanix HCI Teamが投稿した記事の翻訳版です。 原文はこちら。.NEXT 2021に関する記事の索引はこちら。 HCIソフトウェアのパイオニアであるNutanix® AOSの大規模なマイルストーンと、Nutanix AOS 6ソフトウェアのリリースをアナウンスできることを大変喜ばしく思います。 VMworld 2011で市場を創生するHCIソリューションを立ち上げて(Best of VMworldアワードも受賞しています)から10年、Nutanix AOS™ インフラストラクチャソフトウェアは仮想化データセンターの業界標準のプラットフォームへと成熟し、今ではお客様をハイブリッドクラウドへとつながる橋渡しに貢献しています。 本日AOS 6は我々の差別化されたアーキテクチャのコア機能上に構成しながら、一方で破壊的な新機能群を追加しています。このリリースではパフォーマンスの最大化をより簡単に成し遂げられるようにするのみならず、クラスタの回復力についての可視化と統制を向上させて、ミッションクリティカルなワークロードに対するサポートを改善しています。それに加えて、AOS 6では大規模環境におけるセキュリティと保護を長く待ち望まれていたflow networkingと新しいDRダッシュボードも加え、改善しています。 パフォーマンスと拡張性 Replication Factor 1 (RF1) Nutanix AOSはHCIクラスタ上で動作するアプリケーションのデータを複数のコピーを保持することで保護しています。AOSはクラスタ内の異なるノードに複数のコピーを保存しており、これによってハードウェア障害発生時に自動的にデータを復元することができます。これはレプリケーションファクタ(Replication Factor)として知られており、2 または 3のコピー(それぞれ RF2、RF3)を作成するように構成することが可能です。Hadoop®、SAS Analytics®、Splunk® そして NoSQL®データベースのような多くのモダンなビッグデータアプリケーションは、それを下支えするインフラストラクチャの力を借りることなく、自身のデータをアプリケーションレベルで保護しています。従来型のSQLデータベースもいくらかの非永続的な一次で、保

本記事は2021年9月21日にSahil M Bansal氏とVidhi Taneja氏が投稿した記事の翻訳版です。 原文はこちら。.NEXT 2021に関する記事の索引はこちら。 NutanixはMicrosoftとコラボレーションし、より素早く、シンプルで、コスト効率性の高いクラウドへの道筋をご提供します。 近年、そしてこの18ヶ月は特に顕著になってきましたが、ITチームは常に進化し続けるビジネスニーズの真ん中で、増加し続けるハイブリッドなワークプレースをサポートするために、より俊敏にならなければならないというプレッシャーに晒されてきました。多くのビジネス部門では数年分にも値するデジタルトランスフォーメーションの活動を削減された予算の中で運用を行い、短時間に詰め込んできました。プライベートとパブリッククラウドベンダーの両方がそれぞれのお客さまのニーズ、それは多くの場合でオンプレミスとクラウドをミックスさせたインフラストラクチャ上で、ワークロードを稼働させる、つまりはワークロードとビジネスのニーズにより良く答えるための取り組みを行っています。 ハイブリッドクラウドアーキテクチャのアイディアは少し前から存在していましたが、そこにはいくつかのハイブリッドクラウドプラットフォームの急激な採用を阻む課題がありました。オンプレミスのデータセンターとパブリッククラウドの間の複雑なネットワークの管理は長きにわたる障害で有り続け、また、レガシーなアプリケーションをクラウド向けにリアーキテクトすることは時間のかかる作業でコストも高く付きます。もう一つの課題はそれぞれのクラウドのための複数の異なる管理ツールを使うことによって生じるサイロによる非効率性です。 これらの課題を解決し、お客様のITニーズを次なるレベルへとパワーアップさせるため、Nutanixはマイクロソフトとハイブリッドクラウドソリューションにおいて協業し、クラウドとオンプレミスの間の境界を融合させ、完全なハイブリッドクラウドエクスペリエンスをご提供します。 プレビュー開始: Nutanix Clusters on Microsoft Azure Nutanix Clusterson Microsoft Azure を限定的なプレビューとしてアナウンスできることを大変喜ばしく思います! NutanixはMicrosoftと

本記事は.NEXT Digital Experience 2021でのアナウンスメントについての記事の索引です。 2021年内は.NEXT Digital Experience 2021 (グローバルイベント)のレコーディングにアクセスが可能ですので、ぜひ詳細が気になる方はイベントへの登録をお願いいたします。 また、2021年10月7日には.NEXT Conference Japan 2021が実施されます。 字幕入りのキーノートはもちろんですが、完全日本オリジナルコンテンツの22に及ぶブレイクアウトセッションは必見です。こちらも10月末まで視聴が可能ですので、ぜひイベントへの登録をお願いいたします。(グローバルイベントとは登録が独立していますのでご注意ください。) 本索引では、Nutanix社員はもちろん、コミュニティでの情報も集めて行きます。 .NEXTに際して、こんな記事を書きましたというコミュニティの皆様、ぜひコメントにてお知らせください。 記事タイトル 概要 原文リンク Nutanix AOS 6のご紹介 HCIソフトウェアのパイオニアであるNutanix AOSの大規模なマイルストーンであるNutanix AOS 6ソフトウェアをご紹介します。 Announcing Nutanix AOS 6 NutanixとMicrosoft Azureによるハイブリッドクラウドインフラストラクチャ NutanixはMicrosoftとコラボレーションし、より素早く、シンプルで、コスト効率性の高いクラウドへの道筋をご提供します。 Hybrid Cloud Infrastructure with Nutanix and Microsoft Azure Nutanix Eraによる思い通りのデータベース・アズ・ア・サービス Nutanix Eraの最新の機能をご紹介します。 Database-as-a-Service on your terms with Nutanix Era データ中心の世界のためのストレージを再考する Nutanixの統合ストレージ ー 非構造化データ管理の新たなマイルストーン Rethinking Storage For A Data Centric World コミュニティの皆様のブログ ブログタイトル 著者 Nutanix Global .NE

本記事は2018年6月8日に Josh Odgers 氏が投稿した記事の翻訳版です。 原文はこちら。本シリーズの牽引はこちら。 パート5では、CVMのメンテナンスや障害時のI/Oの処理方法について説明しましたが、今度は同じメンテナンスや障害シナリオでWrite I/Oを処理するという、間違いなくより困難で重要なタスクを説明する必要があります。 パート5をお読みになった方であれば、この次のセクションがよくわかると思います。パート5を読んでいない方は、ぜひ読んでいただきたいのですが、ここではNutanix ADSFがどのようにデータを書き込み、保護するのかという基本的なことを簡単に説明します。 以下の図を見ると、3ノードのクラスターに1台の仮想マシンがあります。仮想マシンはa,b,c,dで表されるデータを書き込んでいます。通常の状況では、すべての書き込みは、1つのレプリカが仮想マシンを実行しているホスト(この場合はノード1)に書き込まれ、他のレプリカ(RF3の場合は1つまたは複数)はディスク適合性の値に基づいてクラスター全体に分配されます。ディスクの適合性の値(私は「インテリジェント・レプリカ・プレースメント」と呼んでいます)は、容量とパフォーマンスに基づいて、データが最初から最適な場所に配置されることを保証します。 クラスターに1つ以上のノードが追加された場合、インテリジェント・レプリカ・プレースメントは、クラスターがバランスの取れた状態になるまで、それらのノード数に比例して多くのレプリカを(分散して)送信します。万が一、新たな書き込みが発生しなかった場合でも、ADSFにはバックグラウンドでディスクバランスをとるプロセスがあり、低い優先度でクラスター内のバランスをとります。 Nutanixが複数のレプリカを使用してデータを保護する方法(「レジリエンシーファクター(RF)」と呼ばれるもの)の基本がわかったところで、Nutanix ADSFストレージ層のアップグレード時に何が起こるかについて説明します。 アップグレードはワンクリックで開始され、設定されたレジリエンシーファクター(RF)やイレイジャーコーディング (EC-X) の使用の有無に関わらず、一度に1つのコントローラVM (CVM)をローリング方式で実行します。ローリングアップグレードでは、一度に1つのCVMをオフ

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 CEの3ノードクラスタで1ノードに障害が発生し、再セットアップを実施している最中に仮想マシンが停止する事象が発生しました。 現在の状態から復旧可能か再構築が必要かお分かりになりましたら教えてください。 バージョンは2020.09.16を使用しております。 ■経緯 1.3ノードの内、1ノード(2号機)で稼働している仮想マシンが全てパワーオフになっていることを確認。 2.ログを確認したところ、HAでfail overがかかった記録があり、リソース不足で仮想マシンがパワーオンできなかったことを確認。 3.パワーオフされている仮想マシンを1台手動でパワーオンすると以下のエラーが発生し、仮想マシンがパワーオンできないことを確認。 ---------- NetworkError: OVS Error running: { "args":[ "br0","be616bfb-4c01-4ed1-8232-49c10a69aeda","50:6b:8d:e7:f5:fb",1500,0,true,[],false,null,null ], "cmd": "create_local_port", "kwargs":{}} Output: Error: /bin/bash: Input/Output error ---------- 4.2号機のコンソールを確認したところ、AHV用のUSBメモリのエラーが発生し、コンソールログインできない状態だったため、2号機の電源を強制再起動。 5.再起動してもブートメディアが見つからないメッセージが表示されAHVが起動しなかったので、AHV用のUSBメモリをWindows機に差し替え、USBメモリの正常性を確認したところ、アクセスができない状態になっていたことを確認。 6.昨日日本語フォーラム向けにブートデバイス障害時の復旧方法について質問させていただき、本日新しいAHV用USBメモリを用意して2号機を4号機(新規ノード)として再インストールを実施。 昨日質問させていただいたフォーラムのURL ---------- 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-ce

本記事は2021年6月5日にJosh Odgers氏が投稿した記事の翻訳版です。 原文はこちら。本シリーズの索引はこちら。 これまでの本シリーズの過程で、クラスタはRF2からRF3へと変換されている状態です。ここで、お客様は回復力に影響を与えることなく、容量効率の向上を図りたいと考えています。ここから我々はイレイジャーコーディング(EC-X)を有効化する際のプロセスとそのスピードについて見ていこうと思います。 これまでに議論してきたように、Nutanix の EC-X はバックグラウンドタスクとして動作し、そして Write Cold( 上書きの頻度が小さい ) データのみを対象として実行されます。つまり、構成されているRF処理が通常通り完了し、そしてさらにポストプロセスとしてEC-X の処理が行われます。これは初回の書き込みI/Oにクラスタ内の数多くのノードの参加が必要になることで、書き込みのプロセスが遅くなってしまわないことを保証するためです。 Nutanix EC-Xの実装についての更に詳しい情報については私の「Nutanix – Erasure Coding (EC-X) Deep Dive」という記事をご参照ください。 「What I/O will Nutanix Erasure coding (EC-X) take effect on? (Nutanixのイレイジャーコーディング(EC-X)はどのようなI/Oに対して適用されますか?)」: 良いご質問です、Write Coldデータのみです。ですから、EC-Xでの削減効果はデータが徐々にColdになってゆき、NutanixのADSFのCuratorスキャンが低優先度タスクとしてバックグラウンドで変換を行っていくに従って時とともに向上していきます。 ADSFのRF2/3からEC-Xストライプへの変換の速さは? : 極端な話をすれば、本シリーズの最初の部分で示したとおり、ハードウェアとして搭載されたドライブが可能な速さで行なえます、ですが、EC-Xは容量を削減するためのテクノロジーで、データをリスクに晒すものではないため、例えばノードやドライブの障害時の動作と同じ速さでやる意味はありません。 ですから、内部的な「ErasureCode:Encode(イレイジャーコード:エンコード)」タスクの優先順位は以下に示

本記事は2021年6月5日にJosh Odgers氏が投稿した記事の翻訳版です。 原文はこちら。本シリーズの索引はこちら。 パート1では、Nutanix AOSが分散ストレージファブリック(ADSF)により、ノード障害からレジリエンシーファクター2(RF2)の状態に高速かつ効率的にリビルドする機能について説明しましたが、パート2では、ストレージコンテナをRF2からRF3に変換して耐障害性をさらに向上させる方法と、そのプロセスがどれだけ高速に完了するかを紹介しました。 (今回も)パート2と同様に、12ノードのクラスタを使用しており、ノードごとのディスク使用量の内訳は以下の通りです。 今回障害をシミュレートするノードのディスク使用量は5TBで、パート1のノード障害テストでの容量とほぼ同じです。なお、クラスタが12 ノードになったことで、パート1と比べて(パート1では16ノードを利用)読み書きするコントローラが少なくなっています。 次に、ノードのIPMインターフェイス(IPMI)にアクセスし、「Power Off – Immediate(即時の電源オフ)」の操作を実行してノード障害をシミュレートしました。 以下は、ノード障害時のリビルドが約30分で完了し、5TBのデータの再保護が完了した際のストレージプールのスループットを示しています。 パッと見、5年以上前のハードウェアで5TBのデータの再保護が約30分で完了したことは、SANや他のHCI製品と比較しても非常に素晴らしいことですが、(Nutanixのリビルドは)もっと速くなるはずだと感じたので、少し調べてみました。 その結果、ノード障害をシミュレートした時点でクラスタ(を構成する各ノード上のデータ量)のバランスが崩れており、(障害状態をシミュレートしたノードに比べて)他のノードにデータがほとんどないため、通常の状況のようにリビルドに貢献できなかったことがわかりました(リビルド時の読み取りの観点から)。 クラスタがアンバランスな状態になっていたのは、(ここまでで)ノード障害のシミュレーションを頻繁に繰り返し行っており、ノード障害のシミュレーションを行う前に、クラスタにノードを追加した後にディスクバランシングが完了するのを待たなかったためです。 通常、ベンダーは最適ではないパフォーマンス結果を掲載することはありませんが、私は

皆様こんにちは。ヴィームソフトウェアの斉藤と申します。 Veeamに関するフォーラム寄稿の第4弾となります。 ・Vol.1 Veeam Software会社紹介とラインナップ+ライセンス ・Vol.2 Veeamのバックアップについて ・Vol.3 Nutanix Mine "with Veeam"について ・Vol.4 クラウドやKubernetes環境のバックアップについて(今回のトピック) Veeam のマルチクラウドアーキテクチャ はじめにVeeamは「クラウド・データ・マネジメント」の名のもと、マルチクラウド環境下でのインフラマネジメントを推進していることを改めて共有させていただきます。 つまり、オンプレミスで稼働するワークロードのみならず「クラウドリフト」および「クラウドシフト」そして「モダナイゼーション」に対応するための支援をさせていただいております。今回はその3つを以下の観点でご紹介したいと思います。 ・クラウドリフト:パブリッククラウド(AWS/Azure/GCP)への移行 ・クラウドシフト:パブリッククラウド(AWS/Azure/GCP)上のバックアップ ・モダナイゼーション:Kubernetes 環境のバックアップ クラウドリフト:パブリッククラウド(AWS/Azure/GCP)への移行 現在はクラウドの利活用が進み、開発環境や分析基盤をパブリッククラウドで運用するケースや、お客様によってはすべてのインフラをクラウドに移行するような場合もございます。いずれにせよ、現行のインフラ運用における最適解はオンプレ共存の「ハイブリッドクラウド」もしくは一歩進んでベンダロックインを避けるための「マルチクラウド」になります。 しかしながら、オンプレにある環境をパブリッククラウドに移行する場合は適切なパブリッククラウドの選定だけでなく、パブリッククラウド上で既存インフラが稼働するかどうかの動作確認が事前に必要となります。その場合、一旦クラウドにシステムを移し替えるための準備や手間が必要となるため、運用者にとっての負荷増は否めません。 その際、Veeamをお使いのお客様であれば「クラウドモビリティ」によりバックアップデータから直接パブリッククラウドにリストアすることが可能です。 ・Restore to Amazon EC2 : バックアップをAmazon EC2

本記事は 2018 年 5 月 31 日に Josh Odgers 氏が投稿した記事の日本語版です 。 原文は こちら 。本シリーズの索引は こちら 。 パート 1 では、 Nutanix AOS が Acropolis 分散ストレージファブリック (ADSF) のおかげで、ノード障害からのリビルドを高速かつ効率的に行う能力について説明しました。パート 2 では、ストレージコンテナがどのようにして RF2 から RF3 に変換されるのか、また、その操作が完了するまでのスピードについて、紹介したいと思います。 今回のテストでは、クラスター内に 12 台のノードしか存在しません。 まず、ストレージプール容量の使用状況から見てみましょう。 現在、クラスター全体で50TB超のストレージ使用量であることが確認できます。 RF3 への変換、つまり簡単に言えば全データの 3 つ目のレプリカを追加する際には、十分な空き容量を確保する必要があり、さもないと RF3 のコンプライアンス上、問題があります。 次に、クラスタ(およびメタデータ)の Redundancy Factor (冗長化係数)を RF3 に増やします。これにより、クラスタは RF3 コンテナをサポートし、メタデータの観点からは少なくとも 2 つのノード障害に耐えることができます。 次に、対象のストレージコンテナを RF3 に増やします。 コンテナが RF3 に設定されると、 Curator はクラスターが設定された Redundancy Factor に準拠していないことを検出し、追加のレプリカを作成するためのバックグラウンドタスクを開始します。 今回のケースでは、ストレージプールに約 50TB のデータがある状態でスタートしたので、このタスクでは 50 %のレプリカを作成する必要があり、最終的には約 75TB のデータを格納することになります。 新しい Redundancy Factor に準拠するために、クラスターが 25TB のデータを作成するのにかかった時間を見てみましょう。 今回は、 7GBps 以上のスループットで 3 時間未満の処理時間を示しており、 1 時間あたり約 8.3TB となりました。このプロセス全体を通して、クラスターは RF2 レベルの完全な回復力を維持しつつ、このフェーズで新しい書き込みが

Most awesome this week!

Badges

Show all badges