• 198 Topics
  • 187 Replies

198 Topics

ChakrDB:クラウド上に誕生した分散型RocksDB、その1

 本記事はAnoop Jawahar氏 および Sandeep Madanala氏が 2021年10月4日に投稿した記事の翻訳版です。原文はこちら。  歴史、背景、動機Nutanixクラウドオペレーティングシステムは、Webスケール、スケールアウトな設計を通じて、高可用性、レジリエンス、障害無害化能力とともに、包括的なストレージとコンピュートの仮想化を提供し、オンプレミスのデータセンターでパブリッククラウドのエクスペリエンスを、提供しています。当社のソフトウェアの基盤となる2つの主な技術は、Nutanixの分散ストレージと、コンピュート管理のためのKubernetesベースのマイクロサービス・プラットフォーム(MSP)です。あらゆるパブリッククラウドサービスで同じようなテクノロジーを利用することができます。例えば、ストレージであればAmazon Web Services(AWS)のElastic Block Store(EBS)やAzureのマネージドディスク、コンテナのオーケストレーションであればAWS Elastic Kubernetes Service(EKS)、Azure Kubernetes Service(AKS)、Google Kubernetes Engine(GKE)などが挙げられます。 今日の分散型データベースやデータサービスは、こうしたクラウドインフラストラクチャーの構造を活用することで、より軽量で先進的なものになります。また、モダンなデータアプリケーションは、あらゆるパブリッククラウドやプライベートクラウドで実行できるように、一定の原則に従う必要があります。アプリケーションをクラウド対応にするには、通常、オープンソースのAPI標準へ準拠したり、標準化されたiSCSIストレージをエンドポイントとしたり、インフラストラクチャ運用管理用のKubernetes(K8s)のようなオープンコンテナオーケストレーションフレームワークが必要です。 Nutanix ObjectsチームがChakrDBとの協業を開始したとき、Nutanixの開発チームは当社のクラウドOS上のストレージサービスを作成していました。Nutanix Objectsは、非構造化データ向けのS3準拠のハイブリッドクラウドストレージで、クラウドの構造を活用できるよう構成されています。クラウ

HCIプラットフォームの可用性、回復力、整合性 – パート7 – vSAN 7U1 および対障害性2 (FTT2)

本記事は2021年2月8日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 このシリーズではNutanix AOSが回復力ファクタ(RFつまり2つのデータコピー)を利用した場合に3ノードクラスタの場合も含め、メンテナンスモード、再起動、および障害シナリオにおいて完全な仮想マシンの可用性とデータの整合性を維持できるということを見てきました。 そして、パート2ではNutanix AOSとvSAN 7 Update 1とを比較し、vSANが再起動と電源サイクル(障害)シナリオの両方で、以下のようなあらゆるvSANにとって有利に働く状況を作ったとしてもI/O整合性のエラーに苦しんでいるという事実を確認しました:vSANが長い(SCSI)I/Oタイムアウト設定を利用している (180 秒 vs Nutanix 30 秒) vSANがデータの完全退避モードを利用している vSANのオブジェクトリビルドタイマーを60分の遅延から遅延なしに変更 (すなわち、これによってリビルドは即時開始される) より大きなクラスタ(8ノード)を利用し、その上で、テストはそのクラスタ内の最初の4ノードのみで実施する それではvSAN 7 Update 1が対障害性(FTT)を2に設定した場合の動作について見ていきます、つまりvSANはデータのコピーを3つ書き込んでいくことになり、理論的には回復力を向上して、2つの同時ドライブもしくはノード障害に対応ができることになります。 この一連のテストは回復力にフォーカスを当てており、FTT2(もしくはNutanix AOSではRF3)を利用するということは同時に実効で利用可能なキャパシティを50%からファイルシステム、キャッシュドライブ、そして回復用のキャパシティ(N-1/N-2)をマイナスしたものから33%から同じオーバーヘッドをマイナスしたものへと減少させるというコストを伴うということを理解しておくことが重要です。 FTT2(NutanixではRF3)を利用する場合には、同じ仮想マシンのフロントエンドのパフォーマンスに対してもより多くのシステムリソース(例:CPU/ストレージIO)を消費します。例えば、デュアルパリティへの移行によってサイジングには劇的な影響があり、大抵の場合33%以上になりますし、もちろんプラ

Nutanix AOS vs vSAN/VxRAIL 完全なデータ退避モードの場合

本記事は2021年2月2日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの牽引はこちら。  本シリーズのパート1では、HCIプラットフォームをテストするためにX-Rayを使って実行できる、新しい「HCI Platform Availability, Resiliency & Integrity (プラットフォームの可用性、回復力、そして整合性)」」のシナリオについて学びました。 パート2では、Nutanix AOSがメンテナンスモード、再起動、障害シナリオにおいて、仮想マシンの完全な可用性とデータの整合性を維持すること、そしてvSAN 7.0 Update 1が再起動と障害シナリオの両方でI/Oの整合性エラーが発生することを紹介しました。 パート3では、PVSCSIドライバのI/Oタイムアウトを30秒から180秒まで増やすことで問題が解決するかどうかを調べました。その結果、I/Oタイムアウトを増加させることでエラー数は減少しましたが、最終的にはvSAN 7 Update 1で発生するI/Oエラーを防ぐことはできませんでした。 今回のパート4での疑問は、「vSANの完全なデータ退避モードを使うことで、データの整合性の問題を回避できるか?」です。 完全なデータ退避モードについては、以下のVMware社のドキュメントで説明されています。簡単に言うと、ホストがメンテナンスモードになると、すべてのデータ(vSANオブジェクト)がクラスタ内の他のホストに再作成されます。ですので、理論上はホストがオフラインの間もデータの整合性が損なわれることはありません。 https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vsan.doc/GUID-521EA4BC-E411-47D4-899A-5E0264469866.html パート2と3で、vSANでもメンテナンスモードのフェーズでは、可用性の欠如やI/Oエラーが発生しないことを確認しました。これは、これらのテストでも完全なデータ退避モードが使用されており、vSAN7U1とすべてのオブジェクトが、ホストがオフラインであっても常に利用可能であったためです。 しかし、再起動や電源OFFのフェーズではどうでしょうか。 再起動や

NutanixにおけるRocksDBの活用

本記事はRaghav Tulshibagwale氏が 2021年3月10日に投稿した記事の翻訳版です。原文はこちら。  本日の記事では、また新たなゲストライターを紹介させていただきます。皆さん、Nutanixのスタッフエンジニア、Raghav Tulshibagwaleにご挨拶を!本日の記事では、継続的なシリーズの第1弾として、Raghavが私たちをNutanixにおけるRocksDBの旅へと案内してくれます。そしてRocksDBがNutanixプラットフォームアーキテクチャの様々な側面にどのように適用されているのかをご紹介します。私がRaghav自身よりもうまく説明することは到底できませんので、さっそく始めましょう! はじめに2016年初めのアーキテクチャ検討会以来、Nutanixエンジニアチームは、分散ストレージファブリックの3つの大きな目標、すなわち、持続的でランダムな書き込み性能の向上、大容量ディープストレージノードのサポートの追加、バックグラウンドでのデータ管理の効率化に取り組んできました。これらの目標を明確にし、詳細を詰めていくうちに、私たちの限界要因はアーキテクチャ自体にあることに気づきました。さらに改善し、将来のスケーラビリティ(拡張性)のニーズに対応するには、Nutanixでのメタデータの保存方法を完全に再構築する必要がありました。メタデータをデータに近づけるという私たちの最大の目的には、メタデータを保存するための新しい基盤コンポーネントが必要でした。すでにうまく機能しているシステムに、まったく新しいコンポーネントを導入するのは、リスクの高い試みです。最終的にオープンソースのキーバリューストア(KVS)であるRocksDBを選択しましたが、これはあらゆる選択肢を調査し、それぞれの潜在的なコストと効果を考慮した結果です。オープンソースのソリューションが、十分な信頼性と耐久性を持ち、私たちのチームが数カ月で十分なノウハウを身につけ、そのコンポーネントを本当に自分たちのものにできるのかを確かめたかったのです。このブログシリーズの最初の記事では、専門用語、自律エクステントストア(AES)プロジェクトの全体要件、新しいコンポーネントの選択基準、エクステントストア用のRocksDB展開の概要、現在RocksDBを使用している他のNutanix製品およびコンポー

NutanixとMicrosoft Azureによるハイブリッドクラウドインフラストラクチャ

本記事は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と従

パブリッククラウドの課題– パート9 – キャパシティの改善と妥協なきパフォーマンス(更にその上でしなやかさは?)

本記事はJosh Odgers氏が2020年8月21日に投稿した記事の翻訳版です。原文はコチラ 。本シリーズの索引はコチラです。 パート2ではVMC/vSANが「ディスクグループ」アーキテクチャを採用していることからNutanix Clustersのほうが劇的に多くの利用可能なキャパシティを提供しながら、高いしなやかさを保証できることを学びました。パート3ではこの先進性が環境のサイズが拡張していくにつれてより良くなっていくだけであることを見てきました。パート9ではVMware社の直近のAWS i3en.metalインスタンスとNVMeネームスペースについてのアナウンスについて見ていきます。この記事において興味深いのは私がVMC/vSANがそれを支える物理フラッシュストレージデバイスにおいて非効率すぎると言い続けてきたことを確認できるということです。 この新しいホストで利用可能になるRawハードウェアを見ると、8本の7.5TB NVMeデバイスを見つけることができます ― ほぼ60TBのRawメディアで劇的なまでの量のリソースを保証してくれます。残念なことにvSANで7.5TBのNVMeデバイスを利用するには課題があります。もしもi3.metalでの実装をコピーしてメディアをディスクグループの一部へと分解していくと、キャッシュ層における利用されることのないリソースについてどうすることもできなくなってしまいます。リファレンス: HTTPS://BLOGS.VMWARE.COM/VIRTUALBLOCKS/2020/07/15/I3EN-METAL-ENHANCED-CAPACITY/ ですから、「ディスクグループ」のアーキテクチャ上の成約を回避するために、VMC on AWSはNVMeのネームスペースを利用し、フラッシュデバイスのキャパシティを論理的に分割し、別々のデバイスとして認識させています。これによって、VMC/vSANはWriteキャッシュレイヤーにおけるキャパシティの無駄を最小化することができるため、その意味ではこれは良い改善になるように思えます。VMCのソリューションでは7.5TBのNVMeフラッシュストレージデバイスを4つのネームスペースで分割し、32の独立した認識デバイスを作り上げます。そしてそれらはそれぞれのディスクグループが2つの専用デバイス利用した

Nutanix Era データベース& API自動化

  本記事は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 Eraを展開したことがなく

X-Rayを使用したAWS上のNutanixのパフォーマンステスト方法

本記事は2020年8月18日にGary Little氏が投稿した記事の翻訳版です。原文はこちら。執筆時点の情報となりますので現時点とUI、手順が異なる箇所があります。  AWS上でのNutanixクラスタの作成とX-Rayの実行(Youtube動画)   以下のリンクから、上記ビデオの各セクションにジャンプできます:Nutanix Cluster on AWSの作成と起動 Nutanix Cluster on AWSにPrismからの接続 X-rayディスクイメージのダウンロードと作成 AWSでサブネットとルーティングの作成(X-Ray VM、Worker VM用) Prismを使用してAWSで作成したサブネットをAHVへ接続する PrismからX-Ray VMを作成する AWSでロードバランサを作成し、X-Ray VMに外部からアクセスできるようにする X-Ray VMへのアクセスを許可するセキュリティグループの設定 Prism Virtual IPアドレスの設定 X-Ray VMへの接続 X-Ray VMからテストターゲットの設定 Four Corners Microbenchmarkシナリオを使用したパフォーマンステストを実行する X-Rayの実行と結果:IOPS X-Rayの実行と結果:Throughput  Step By Stepmy.nutanix.comに移動し、Nutanix Clustersで[Launch]を選択します。 Create Clusterをクリックします Create Clusterダイアログで詳細を入力します。Create Clusterの2ページ目で、Prism Accessに "Public "を、Management Services Accessに "Restricted "を選択します。他にAWSに接続していない場合は、必ず管理サービスの現在のIPアドレスを追加してください。(今回のデモでは必要ありませんが、新しいsshキーを作成しダウンロードしました)  "Create Cluster "ボタンをクリックします。Initialize cluster initiated "というポップアップが表示されるはずです。AWSがベアメタルクラスターをプロビジョニングします。これは通常20-30分かかります。 Statusが "C

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

Veeam Software at Nutanix Vol.1 Veeam Software会社紹介とラインナップ+ライセンス

皆様こんにちは。ヴィームソフトウェアの斉藤と申します。この度こちらの日本語フォーラムに寄稿させていただくことになりました。これから以下4回に分けてトピックをお伝えしようと思います。Vol.1 Veeam Software会社紹介とラインナップ+ライセンス(今回のトピック) Vol.2 Veeamのバックアップについて Vol.3 Nutanix Mine "with Veeam"について Vol.4 クラウドやKubernetes環境のバックアップについて Veeam SoftwareについてVeeam Softwareは2006年、スイス・バールにて創業した主にバックアップを生業とするデータマネジメントに関する企業になります。2020年に米国の投資会社「Insight Partner」による買収を経て現在はアメリカのオハイオ州に本社機構を移転しております。 2020年の売上高は10億ドルを超え、1,000億円の規模に到達しました。バックアップ業界におけるシェアはヨーロッパではNo.1、そしてグローバルでもこの度2020年後半にVeritas社を抜き、遂にNo.2 に浮上致しました。  お客様満足度も非常に高いのがポイントになりますが、中でもNPS (Net Promoter Score)の高さをベンチマークに挙げさせていただいており、使いやすさの方向性はNutanixに非常に近しいものだと考えております。  第三者機関の評価も非常に良好で、Gartner社のMagic Quadrantでは4年連続「Leaders」ポジションに選出されております。  2020年は縦軸の「実行力(Ability to Execute)」にてNo.1 のご評価をいただき、まさに有言実行でビジネスを行っている事が評価されていると考えております。 近年のビジョンとなるメッセージは「クラウド・データ・マネジメント」を掲げており、データ視点におけるマルチクラウド環境のDXをめざしております。ビジョンにおける方向性もまた、Nutanix 社に近いものだと考えております。 Veeam SoftwareのポートフォリオそれではVeeam Softwareが提供しているポートフォリオをご紹介させていただきます。 Veeamのコア製品ともいえるソリューションが、「Veeam Availability S

Nutanix OEMパートナープラットフォーム紹介

Nutanixを NXだけでなくHPEやDellなど、皆さんの環境にある様々なサーバでお使いいただけることはご存知だと思いますが、OEMパートナーである Lenovo及び富士通環境についてご紹介します。・Lenovo HXシリーズ https://www.lenovo.com/jp/ja/p/WMD00000326エッジ環境向けモデルを含む豊富なラインナップが特徴で、OEMアプライアンスとHWとSWを分離した認定ノードでご利用できます。LenovoのDCSCツールでHXのHW構成やサポート及びサービスも柔軟に組むことができます。VDIやSAPを含む大手お客様環境の事例や病院への導入も多く、様々な環境へご検討いただけます。 ・富士通 XFシリーズ https://www.fujitsu.com/jp/products/computing/integrated-systems/virtual/primeflex-nutanix/スモールスタートに適した 1CPUモデルや、中規模環境向け、大規模環境向けの高密度モデルなどお客様環境に応じたモデルを提供しています。認定ノードとして利用いただけますが、日本語による24時間365日対応するワンストップサポートも提供されています。MoveやFilesなどもお客様ご利用実績があり、検証情報にもとづく情報提供や導入時の支援、セミナーにおいて使い方の紹介も行われ、アセスメントサービスなどもあり、エンタープライズ環境への導入は定評があります。いずれの環境においても評価環境もご用意され、Nutanixを初めて検討される方や試してみたいという方に対するご支援もありますので、各社のご相談窓口よりお気軽にお問合せください。Nutanixでご利用いただけるパートナ各社の状況をご覧いただき、各プラットフォームの詳細はパートナー各社へお問合せくださいますようお願いいたします。また、ディストリビューター各社からも 各パートナーソリューションを活用いただけます。OEM Partnerships (nutanix.com)https://www.idaten.ne.jp/portal/page/out/css/hci/thinkagilehx.htmlhttps://licensecounter.jp/engineer-voice/blog/articles

HCIプラットフォームの可用性、回復力、そして整合性 – パート2

本記事は2021年1月12日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 Part1ではX-Rayのシナリオである「Platform Availability, Resiliency & Integrity (プラットフォームの可用性、回復力、そして整合性)」の成功結果のチャートと失敗結果のチャートを確認しました。(可用性が期待されたレベルで維持できたか、障害で I/Oエラーが検出されたかを確認できます) パート2では、ESXi7.0.1ビルド17325551で実行されているNutanixAOS5.19およびvSAN7 Update1のさまざまなテスト結果を確認します。 注:同じテストをESXi6.7とESXi7.0.1の以前のビルドで行い、AOSとvSANの両方で同様の結果が得られました。 最初の比較では、X-Ray向けの「Platform Availability, Resiliency & Integrity」のシナリオを使用し、シナリオのデフォルト設定を使用します。ディスク使用率は10%、I/Oタイムアウトは30秒、および「全てのプラットフォームでの復元力テスト」です。 パート1で学習したように、テストではノードごとに1つのVMをデプロイし(N+1ノード目は除く)、ノードでアクションが実行される前に、VMをノードからプロアクティブに移動します。これにより、VMはテスト全体を通じて起動し続け、I/Oアクティビティと整合性を正確に確認できます。 Nutanix AOS 5.19とvSANはどちらも、ESXi 7 Update 1(ビルド17325551)と同じDell PowerEdge R740xd-24 NVMe + SSDハードウェアで実行されています。 テスト前に、すべてのノードを最新のBIOS/ファームウェアに更新し、可能な限り公平で比較可能であることを確認しました。 VMの可用性(メンテナンスモード):NutanixAOSとvSAN7U1はどちらもVMの可用性を維持していました(合格) VM I / Oエラー(メンテナンスモード):NutanixAOSまたはvSAN7U1ではI / Oエラーは発生しませんでした(合格) VMの可用性(ローリングリブート):NutanixAOSとvSAN

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

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

Nutanixのメリット その9: 完全な統合ストレージ

本記事はNutanixのTechnical Marketing Engineer – NC2, NUS, NDBのMike McGheeが2022年10月6日に投稿した記事の翻訳版です。原文はこちら。   Nutanixをハイパーコンバージドインフラストラクチャ-(HCI)と同義と考える方もいることでしょう。これは我々が別途ストレージ装置とストレージエリアネットワーク(SAN)、サーバー、仮想化が必要な構造のレガシーなソリューションを(HCIへと)置き換えてきたからです。しかし、Nutanixが完全な統合ストレージソリューションをご提供していることをご存知でしたか? 我々のストレージ・ソリューションには同じ分散プラットフォームを利用するiSCSIベースのブロックサービス、SMBとNFSのファイル共有、そしてS3互換のオブジェクト機能が含まれています。Nutanixはシンプルさ、柔軟さ、そしてビルトインされたデータに対するセキュリティをご提供するソフトウェア・ディファインドのエンタープレイズグレードの統合ストレージをご提供できる唯一のHCIソリューションです。 Nutanixユニファイドストレージ(NUS)とは?Nutanixユニファイドストレージ(NUS)  には以下の3つのコアサービスが含まれています: ファイルサービスNutanixのファイルサービスは、アプリケーションとユーザーによって生成される拡大し続ける非構造化データの保存、管理、拡張に対するシンプルかつセキュアなスケールアウトソリューションを提供します。一般的なユースケースにはVDI向けのホームもしくはプロファイルディレクトリ、監視ビデオやメディカルイメージまでもが含まれます。ファイルサービスはSMB 2, SMB 3, NFS v3, NFS v4の堅牢なプロトコルのサポートおよびマルチプロトコルのサポートを含む、完全な機能セットを提供します。シェアに対してのユーザークオータの適応や、WORMポリシーの設定、クラウドへのデータの階層化、そして災害復旧(DR)のためのシェアのネイティブなレプリケーションが利用できます。 オブジェクトサービスオブジェクトサービスはセキュアなS3互換オブジェクトストアを提供します。オブジェクトサービスはモダンなクラウドネイティブおよびビッグデータ分析ワークロード向けの高いパフ

緊急性の高いアップデートがある場合、LCMがその他のアップデートを無効にするケース

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」へアップグレードし、再度L

Nutanix AOS vs vSAN/VxRAIL 大規模クラスタ & vSAN 7U1のデータ整合性

本記事は2021年2月5日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 このシリーズでは、Nutanix AOSが、3ノードクラスタを含むResiliency Factor 2(RF2:データのコピーを2つ保持する設定)を使用している場合に、メンテナンスモード、リブート、障害シナリオにおいて、仮想マシンの完全な可用性とデータの整合性を維持することを学びました。 また、Nutanix AOSとvSAN 7 Update 1を比較し、(vSANが)より高い(SCSI)I/Oタイムアウトの設定、データの完全退避モードを使用し、オブジェクト再構築タイマーを60分遅延からゼロ遅延(つまり、再構築を即時開始する設定)にしたにもかかわらず、vSANは再起動と電源オンオフ(障害)シナリオの両方でI/Oの整合性エラーが発生するという事実を見てきました。 このパートでは、引き続きX-Ray のPlatform Availability, Resiliency and Integrity(プラットフォームの可用性、回復性、整合性)テストを実施しますが、今回はDell PowerEdge r740xd-24ノード(NVMe+SSD)を使用した8ノードのvSAN 7 Update 1クラスタで行います。 このテストの目的は、大規模なクラスタが結果にどのような影響を与えるか、また、vSANが大規模な環境でI/Oの整合性を維持できるかどうかを確認することです。 それでは早速、結果を見ていきましょう。 メンテナンスモード:  (このテストフェーズでは)I / Oエラーはレポートされません。  再起動時:  (このテストフェーズでは)206のI/Oエラーが確認できます。 電源オフ時:  (このテストフェーズでは)56 のI/Oエラーが確認できます。 (テスト結果の)考察:4ノードのvSANクラスタでの以前の結果と比較すると、小さいクラスタよりも大きいクラスタの方がI/Oエラー数を減らすことができるようです。 これは、仮想マシンオブジェクトがより多くのノードに配置された状況下で、テスト内容が(8ノード構成の)クラスタ内の最初の4つのノードでのみ操作(メンテナンスモード、再起動、電源オフ)を実行するため、理にかなっています。 もし、このテストが(最初の4

ネットワークトラフィックがビッグデータインジェストのパフォーマンスに与える影響の比較 – Nutanix vs VMware vSAN / DellEMC VxRAIL

本記事は2020年3月9日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 このシリーズでは、Nutanix AOSソリューションがvSAN / VxRAILと比較して、多くのアーキテクチャ上の利点があることを学んできました。 この記事では、実世界のネットワークトラフィックがパフォーマンスに与える影響の例を紹介します。これまでに説明してきたコンセプトの多くが証明できます。この例では、ビッグデータのインジェスト処理のような書き込みの多いワークロードを見てみましょう。 ベースラインとなるテスト: 2つの同一構成の4ノード・クラスターを使用します。完全にアイドル状態になるのを待って 、X-Rayを使ってビッグデータ取り込みのシナリオを開始しました。2つのプラットフォームは同じくらいの時間でデータの取り込みを完了しました。 Nutanix AOSは13分、VMware vSANは14分でした。 ネットワークトラフィックがない状態でのビッグデータの取り込みテストの所要時間 テスト中のネットワーク使用率は、どちらのソリューションも約2GBpsで、vSANはテストが半分ほど経過したところで約1.5GBpsに低下しました。  次に、各ホスト上でiPerfを実行し、実世界のシナリオをシミュレートしました。ストレージトラフィックだけでなくVM間やクライアント・サーバ間のトラフィックを処理する環境です。 iPerfでネットワークトラフィックを生成した環境でのテスト 次のグラフは、テスト全体のネットワーク帯域幅を示しています。この中にはiPerf(~6GBps)で生成されるトラフィックとX-Rayのシナリオで生成されるビッグデータ取り込み(前のグラフのように~2GBps)の両方のトラフィックが含まれています。これらは両プラットフォームで同様の条件です。  当然のことながら、いくつかの影響が見られました。このテストは100%書き込みで、両方のプラットフォームが書き込みレプリカにネットワークを使用しなければならないためです。 iPerfのネットワークトラフィックを用いたビッグデータ取り込み処理の所要時間 Nutanixへの影響としては、シナリオ完了までに4分(~31%増)多くの時間がかかりました。vSANは14分(~100%増)多くかかりました。 

Postgresでのベンチマーク パート1

本記事は2019年6月28日にGary Little氏が投稿した記事の翻訳版です。原文はこちら。Image By Daniel Lundin この例では、Postgresとpgbenchワークロードジェネレータを用いて、仮想マシンに対して負荷をかけます。PostgresがインストールされたLinux仮想マシンを利用しますが、特にBitnami仮想アプライアンスを使います。VMが起動したらコンソールに接続します Postgres DBポートであるpostgresポート5432へアクセス許可するか sshを許可します $ sudo ufw allow 5432 postgresユーザーのパスワードを確認してください (cat ./bitnami_credentials) コンソールかSSHよりpsqlへログインします $ psql -U postgres オプションとしてパスワードを変更できます (プロンプト表示はpostgresデータベースユーザーのbitnami_credentialsからのパスワードです). $ psql -U postgrespostgres=# alter user postgres with password 'NEW_PASSWORD';postgresl=# \q pgbenchワークロードを実行するDBを作成します。この場合dbを“Scale Factor 10”でテストするためpgbench-sf10と名付けます。Scale Factorとはデータベースのサイズを定義する方法です。 $ sudo -u postgres createdb pgbench-sf10 ベンチマークを実行する準備ができているDBを初期化します。“createdb” ステップは空のスキーマを作成します。 -i は “initialize” を意味しています -s は “scale factor” を示し、例えば10など指定します pgbench-sf10 は利用するデータベーススキーマです。先程作ったpgbench-sf10を使います。  $ sudo -u postgres pgbench -i -s 10 pgbench-sf10 pgbench-sf10というDBスキーマに対してワークロードを実行します。 $ sudo -u postgres pgb

ChakrDB:クラウド上に誕生した分散型RocksDB、その2

本記事はAnoop Jawahar氏 および Sandeep Madanala氏が 2021年10月4日に投稿した記事の翻訳版です。原文はこちら。  このシリーズのパート 1では、RocksDBをベースに、数十テラバイトから数ペタバイトまでのスケールに対応する分散型の、クラウドネイティブな、高い可用性を備えた、高性能なキーバリューストア(KVS)を新たに実装するに至った経緯について述べてきました。この記事では、ChakrDBの概要とその特徴、アーキテクチャの詳細について説明し、パート 1で提示した要件の達成にどのように役立ったかをまとめます。 概要ChakrDBは、分散型のNoSQL KVSです。ChakrDBインスタンスは、複数の仮想ノード(vNode)が組み込まれた単一プロセス、コンテナ、ないしはポッドです。各仮想ノード(vNode)は独立したKVSで、クラスタ内のシャードを所有し、すべてのデータをリモートクラウドストレージ(ボリューム、Nutanix仮想ディスク、またはAWSやAzureなどのクラウドによって提供される任意の仮想ディスク)に書き込みます。vNodeはKubernetes(K8s)が展開したext4ファイルシステムベースのボリュームとNutanixの内部ファイルシステムであるBlockStoreのいずれもをサポートしています。BlockStoreは物理ディスクとNutanixの仮想ディスクを含む様々なタイプの基盤ストレージをブロックベースの抽象化によってサポートします。ブロックベースのファイルシステムにより、vNodeはストレージファブリックと直接対話し、iSCSIよりもext4を使用することで余分なオーバーヘッドを回避し、スループットとレイテンシーを約50%向上させることができます。 ChakrDB の主な特徴完全な自在性と柔軟性ChakrDBには、仮想ノード(vNode)に基づくシャーディングデザインが採用されています。仮想ノード(vNode)は、高いスループットとテールレイテンシの改善でリニアなスケーラビリティを実現します。各仮想ノード(vNode)はRocksDB上で動作するラッパーであり、それ自体でKVSスタック全体を保有するため独立性が高く、データの移動と配置に柔軟性を提供します。仮想ノード(vNode)ベースの設計により、クラスタは

Postgresでのベンチマーク パート2

本記事は2019年6月28日にGary Little氏が投稿した記事の翻訳版です。 原文はこちら。  今回の例では、pgbenchの実行は、データサイズの規模を表すスケールファクターを1000で実行しており、これは約15GBのデータベースサイズに相当します。(前回記事を参照)。ベンチマークを実行するLinux VMはRAMが32GBのため、データはメモリにキャッシュされます。そのため、ディスクへのReadがほとんど無いことが予想されます。  監視システムであるPrometheusでpgbenchを実施した結果のディスクIOパターンを見てみます(Linuxエクスポーター経由で性能情報を取得)。 IOパターンを確認すると、ログディスク(sda)への書き込みパターンは非常に一定で、データベースファイル(sdb)への書き込みパターンはバースト的であることが分かりました。 ※ログファイルとデータベースファイルは異なるディスク(sda/sdb)に配置しています。 pgbench - Linux buffer cacheサイズの50%のDBサイズでの結果 なお、今回のベンチマークではPostgreのcheckpoint_completion_target パラメータを 0.5 から 0.9 に調整しました。そうしないと、Postgreのチェックポイント時に SCSI スタックに負荷がかかり、ログ書き込みが遅くなるため、パラメータの調整を行いました。  pgbench(デフォルト設定) –チューニング前(デフォルト設定)、Logへの書き込みが急激に減少していることが分かります  

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

Nutanix AHVクラスタにbitnamiイメージをインストールする

本記事は2019年6月28日にGary Little氏が投稿した記事の翻訳版です。原文はこちら。 パブリッククラウドの良いところは、Bitnamiのような企業が作成した、あらかじめパッケージングされたアプリケーションの仮想アプライアンスを使用できることです。 Nutanix AHV上でも、これらと同じアプライアンスイメージを使って、簡単にPostgresデータベースのベンチマークを行うことができます。 ステップ1. bitnamiのイメージを入手するwget https://bitnami.com/redirect/to/587231/bitnami-postgresql-11.3-0-r56-linux-debian-9-x86_64.zip ステップ2. ファイルを解凍し、bitnamiのvmdk イメージを単一の qcow2[1] ファイルに変換します。qemu-img convert *vmdk bitnami.qcow2 ブラウザでアクセスできる場所にbitnami.qcow2イメージを置き、Prismサービスに接続し、"Image Configuration "を使ってアップロードします。  イメージのアップロードが完了したら、今度はそのイメージを元に新しいVMを作成します。  起動するとbitnamiのロゴが表示され、コンソールでbitnamiのパスワードの設定やsshの有効化などを行うことができます。bitnamiイメージでのsshの有効化/無効化bitnamiイメージでPostgresに接続する注意 - "sudo -c postgres <some-psql-tool>" と入力したときに求められるパスワードは、Postgres DB のパスワード(./bitnami-credentials に保存)であり、 OSのユーザーのパスワードではありません。 アプライアンスに接続したら、postgresとpgbenchを使って、単純なデータベースワークロードを生成することができます。 [1] これはどこかのLinux環境で実施してください。なぜか、brew経由でインストールしたqemuユーティリティでは、変換に失敗しました。OVAをAHVに直接インポートすることは、将来的に可能になるはずです。(※訳注:Prism Central 2020.

X-RayとpgbenchでCPUのパフォーマンスを測定する

本記事は2019年10月1日にGary Little氏が投稿した記事の翻訳版です。原文はこちら。 アプリケーションの統合度を測るためのX-Rayワークロード。Nutanix X-RayはIO/ストレージワークロードをモデル化することができるツールとして知られていますが、CPUを多用するワークロードについてはどうでしょうか?X-Rayは、X-Rayワーカー仮想マシン上でAnsibleスクリプトを走らせることができ、そうすることでほとんどすべてのアプリケーションを展開することが可能です。我々の目的はPostgresデータベースとそれにビルトインされたベンチマークツールであるPGBenchを利用することです。意図的に仮想マシンのメモリに収まり、IOをほとんど発生させないような非常に小さなデータベースを作成するスクリプトを作成しました。X-rayのワークロードファイルは こちら に保存してあります。 pgbench向けのX-Rayインターフェイス X-Rayで標準(のベンチマーク実行スクリプト)のYAMLを利用し、Postgresの仮想マシンをいくつ展開するのか、クライアント数はいくつなのか、pgbenchを走らせる際のスレッド数はいくつなのか、などのカスタムパラメーターを渡すことができます。 X-Rayがワークロードを実行すると、その結果がX-RayのUI上に表示されます。今回はIOPSやストレージのスループットではなく、メトリックはデータベースの毎秒のトランザクション数(TXN/S)になっています。 Pgbenchの毎秒のトランザクション数がX-rayのUIに表示される ワークロードを走らせる仮想マシン数を変更しながら、様々な試験を実行することで、毎秒のトランザクションの総計と仮想マシンあたりの値をプロットすることができました、この値はホストプラットフォームのCPUがサチってくると減少することが想定されます。  このようなCPU主体のワークロード特性を利用して、異なるハイパーバイザー間での特性、CPUタイプごとのスケジューリング特性やCPU使用率の特性を見ることができます。負荷が小さい場合には優れたパフォーマンスを示すパラメーターの組み合わせを見つけましたが、他の組み合わせでも負荷は高いものの、優れたパフォーマンスを示していました。 ホストのCPUのキャパシティを超える

Badges

Show all badges