• 193 Topics
  • 155 Replies

193 Topics

AOS 5.17 参上!

AOS 5.17で、Nutanixは革新的な新たな機能に加え、引き続いてのコア機能の改善でハイパーコンバージドインフラストラクチャ(HCI)マーケットにおけるリードをまた更に広げようとしています。AOSサブスクリプション契約内で、お客様はNutanixの開発チームからの継続的なイノベーションからのメリットをPrism経由での1-クリックアップグレードで活用することができるようになります。以下のとおり、いくつかの主な改善点について取り上げたいと思います。完全なリストはリリースノートをご参照ください。  スケーラビリティとパフォーマンス  Foundation Centralによる自動化されたグローバルでの展開 大規模なデータセンター環境は歴史的にITデータセンターのライフサイクルにおいてコストの掛かる複雑な部分でありつづけてきました。積み木のようなAOSの特徴によって、Nutanixを利用しているお客様では、AOSとハイパーバイザーのインストール、そしてサーバーノードを接続してクラスタを形成することを自動化するNutanix Foundationを利用した迅速で簡単な展開にご満足いただいています。Foundationは時間の浪費やエラーの温床となりがちなインストールと構成のプロセスを管理者がいくつかの構成情報を入力して「Go」というボタンを押すだけのシンプルなインストーラーへとシンプル化します。   AOS 5.17では、NutanixはFoundationの能力とシンプルさを拡張し、Foundation Centralを投入します。Foundation Centralは大規模で地理的に分断された環境向けのAOSのインストールプロセスを一箇所から実施できるようにすることで、自動化します。この際に専門的なスキルセットやNutanixエコシステムについての先進知識は必要ありません。この機能によって、企業はより迅速に大規模なデータセンタ環境を構成することができるようになり、重要なIT活動のスピードを落とすことや投資を無駄にすることなく効率的にリモートサイトの最新鋭化をすすめることが出来るようになります。 図 1 - Foundation Central 拡張されたPrismのスケーラビリティ Nutanixのお客様はグローバルのAOSインフラストラクチャをPr

Nutanix と VMware vSAN/DellEMC VxRAILを比較

本記事は2020年2月27日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。 以下はNutanixのAcropolis分散ストレージファブリック(ADFS)とDellEMC VxRAILプラットフォームの基盤をなすVMware Virtual SAN(vSAN)の機能と能力を比較した一連の記事です。このシリースは継続的に更新、拡張されて行きます。 もしも取り上げてほしいご質問やトピックスがあれば@josh_odgersからTwitterやLinkedInでご連絡ください。(※日本語でのお問い合わせは本記事のコメントにてお願いいたします。)また、 DellEMC/VMwareがNutanixに対して行っている数多くの誤った訴えについて取り上げているDellEMC/VMware anti-Nutanix FUD index(DellEMC/VMwareのNutanixに対するFUDへの反論の索引)も御覧ください。     利用可能なキャパシティ比較   重複排除&圧縮   イレイジャーコーディングの比較   ストレージキャパシティの拡張   ドライブ障害の比較   混在クラスタのサポート   Write I/Oパスの比較   Read I/Oパスの比較   ノード障害の比較   ストレージアップグレードの比較   利用可能なキャパシティの比較 ー パート2   メモリ利用の比較   CPU利用の比較   ビッグデータの取り込み性能におけるネットワーク帯域への影響についての比較   高耐久性のフラッシュデバイス要件についての比較   I/Oパスのしなやかさの比較 更に追記予定!        

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

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

使用可能な容量の比較 - Nutanix ADSFとVMware vSAN

本記事は2020年1月30日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 ハイパーコンバージド(HCI)製品を検討する際には、ベンダー、パートナー、VAR(Value Added Resellers: 再販業社)、顧客が複数のソリューションを比較することがよくあります。 このような比較の際には、マーケティング資料や、多くの場合は「チェックボックス」スタイルのスライドが比較され、さらに悪いことには額面通りの価値で比較され、容量、回復力、パフォーマンスなどの重要なアーキテクチャ/サイズの考慮事項について誤った仮定をしてしまうことがあります。 簡単な例を挙げてみましょう: 顧客は、要件を満たすために16台のノードを選択/必要としており、密度、電力効率、高性能のために2ラックユニットあたり4ノード(4N2U)という最も一般的なフォームファクタを選択しています。 フラッシュストレージのコストがユースケースに見合ったものであるため、ノードには6台の1.92TBドライブ(All Flash)が搭載されています。 つまり、16台のホスト* 6台のドライブ=合計96台のドライブを使用しています。 1.92TBドライブがフォーマットされた時の容量を1.78TBとすると96本では170.88TBとなります。 次に、顧客は vSAN と Nutanix を比較します。どちらもデータ保護の主要な形態としてレプリケーションを使用しており(従来の RAID とは対照的)、2 つのコピー(Nutanix では RF2、vSAN では FTT1)と 3 つのコピー(RF3 または FTT2)のどちらかを使用しています。 彼らは簡単な計算をして、次のような結論を出しています。 170.88TB / 2 (RF2 または FTT1) = 85.44TB 使用可能170.88TB / 3 (RF3 または FTT2) = 56.96TB 使用可能 顧客/パートナー/VARは、両製品の使用可能容量は同じであるか、少なくともその差は購入やアーキテクチャ上の決定には重要ではないと結論づけてしまっていないでしょうか? もしそうだとしたら、彼らは2つの重大な理由から大きな勘違いをしたことになるでしょう。 理由1:ファイルシステム/オブジェクトストアのオーバーヘッド 

レイテンシ、スケジューラー、割り込み、なんてこった!Linuxカーネルアップグレードに関する壮大な物語

本記事は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つが、新たなカーネルを利用することで我々が同じハードウェア上でもより優れたパフォーマンスを達成することに貢献するカーネルの改善点です。 問題はなにか?作業を始めるにあたって我々は、最

Files 3.5

[img]https://d1qy7qyune0vt1.cloudfront.net/nutanix-us/attachment/d25b539a-2514-4bf7-83be-dd3026dd4d9a.png[/img] この投稿はDevon Helms Senior Product Marketing Manager - Storage Servicesの[url=https://next.nutanix.com/blog-40/nutanix-files-3-5-31952]投稿[/url]をTetsuo Miyoshi - Product Marketing Managerが翻訳したものです。 データは級数的な速度で膨らんでおり、非構造化データの成長がそれに拍車をかけています。15年前ですら100TBのデータは保存するには大きすぎるほどのデータだと考えられていました。今日、我々のお客様はその数倍のデータを管理しなくてはならなくなっています。従来型のNASソリューションはこうした急速な成長に合わせた設計にはなっていません。より大きなデータを管理するという点においての課題を抱えているのです。IT管理者はこの急速なデータの成長とレガシーシステムに対応するために80%[1]もの時間を単に稼働させ続けるためだけに費やしており、ビジネスのイノベーションのための時間には残り20%しか費やすことができていません。 Nutanix Filesはシンプルさ、柔軟性そしてデータインテリジェンスのために設計されています。Nutanix Files 3.5のリリースで我々はいくつもの新たな機能を追加いたしました。 [h2][b][u]Nutanix Files 3.5における新機能[/u][/b][/h2][h3]Nutanix Filesの分析機能はファイルデータに深い洞察をもたらします[/h3]ファイルデータは近年の組織の保持するデータのうち大部分を占めるようになっています。IDCは2025年までに全世界では175ゼタバイトのデータが生成されるとしています(“The Digitization of the World From Edge to Core”; IDC; Authors: David Reinsel, John Gantz, John Rydnin

Nutanix AES: 事例によるパフォーマンス パート2

本記事は[url=https://www.n0derunner.com/]n0derunner[/url]に2018年12月18日に掲載された記事の日本語ヴァージョンです。 原文を参照したい方は[url=https://www.n0derunner.com/2018/12/nutanix-aes-performance-by-example-pt2/]こちら[/url]。 [h2]大規模なデータベースの読み込みパフォーマンスを2倍まで解決する方法は?[/h2]Nutanix AOS 5.10は自律化エクステントストア(Autonomous Extent Store - AES)と呼ばれる機能を搭載しています。AESはこれまで存在していたデータローカリティを補完し、効率的にメタデータにローカリティをもたらします。巨大なデータセット(例えば 20%のホットデータを含む10TBのデータベース)において、2TBのホットデータセットに対してランダムアクセスを行った際にスループットが2倍改善するという結果を得ています。 [img]https://d1qy7qyune0vt1.cloudfront.net/nutanix-us/attachment/c87ccdfd-c0e6-430b-af79-c4fbd573185c.png[/img] 我々の実験では故意にワーキングセットを大きくして、メタデータがキャッシュ内に収まらないようにしています。2TBを100%ランダムなアクセスパターンでまんべんなくアクセスし、2TB全てのデータにアクセスするまでにかかる時間を記録しました。同じハードウェアを利用し、AESを有効にした場合、その時間は半分になりました。チャートで確認できるとおり、スループットは期待通り2倍になっています。 AESによるメタデータのローカライゼーションがこの2倍の改善に貢献しています。AESはメタデータの殆どをノードのローカルに維持します - ですから、ネットワークを超えてデータを取得する必要がありません。加えてAESはDRAM内にメタデータをキャッシュする必要性も低減しています。これはローカルアクセスが非常に高速だからです。非常に巨大なデータセットについてはメタデータの回収がアクセス時間の大部分を締めているケースがあります。これはあらゆるストレージ