Dell PowerStoreOS 5.0の詳細分析：エリートリセットのソフトウェア面

今年初めにDell PowerStore Gen 3を詳しく解説した際、その焦点はハードウェアにあり、その内容は非常に充実していました。Dellはシャーシからプラットフォームを再構築し、キャッシュ用のスロットを一切使用しない3U筐体に40個のE3.S NVMeベイを搭載、CPU世代から切り離されたコントローラ間の200GbE RDMAミッドプレーン、NVRAMドライブに代わるソフトウェア定義型パーシステントメモリ、エンドツーエンドのPCIe Gen 5、そして独自のSLICキャリアに代わるOCP 3.0 I/Oモジュールを採用しました。これらの選択はすべて、複数回のインプレースコントローラアップグレードによる10年間のサービス寿命をサポートするために行われたものであり、これがプラットフォームのライフサイクル延長というストーリーを確固たるものにしました。

ハードウェア発売当時、PowerStoreOS 5.0はまだ非公開でした。現在は一般公開されており、第3世代システムの新規出荷分で動作し、既存のインストールベース向けにもダウンロード可能となっています。そこで、新機能とさらに強化された点について調べてみました。簡単に言うと、今回のリリースで注目すべき点は運用面です。OS 5.0は、単一の目玉機能よりも、異なる世代のPowerStoreシステムを1つのシステムのように動作させ、新しいハードウェアからより多くの効率を引き出し、パフォーマンスとセキュリティをより厳密に監視することに重点を置いています。

世代を超えて使える、一つのOS

PowerStoreOS 5.0の最も重要な点は、それがどこで動作するかという点です。これは第3世代専用ではなく、新しいPowerStore 1500に搭載されている5.0リリースは、第1世代および第2世代のアプライアンスにもダウンロードできます。一部の機能はハードウェアによって制限されますが（暗号化されたデータ転送用FCカードがその代表例です）、オペレーティング環境自体はインストールベース全体に及びます。

これはクラスタリングのため重要です。第1世代、第2世代、第3世代のアプライアンスは、単一のPowerStoreクラスタ内で共存でき、それらの間でワークロードを中断することなく移動できます。Dellが私たちに見せてくれたデモ環境では、この点が明確に示されています。第1世代1000Tとして製造され、その場でアップグレードされた1200Tが、第3世代アプライアンスとクラスタリングされ、すべてが単一のPowerStore Managerインスタンスから管理されています。PowerStore Managerは、クラスタビューで各アプライアンスの世代とストレージクラスを表示するようになったため、混在環境を一目で簡単に把握できます。計画上の注意点として、新しいハードウェアではクラスタリングは一方向です。第3世代アプライアンスは第2世代クラスタに参加できますが、その逆はできません。第3世代アプライアンスが追加されると、追加の第2世代アプライアンスは追加できなくなります。このルールは、初期構成ウィザードで最初に説明されています。

旧型の PowerStore ハードウェアを使用している顧客にとって、これが移行パスです。既存のクラスタに Gen 3 アプライアンスを追加し、PowerStore Manager でボリュームをネイティブに移行し、データ移行が完了したら自動的に切り替えを行い、空になった古いアプライアンスを廃棄または再利用します。ブロック移行は現在この方法で動作します。クラスタ内のアプライアンス間のファイル移行は、次のリリースで予定されています。それまでの間、Dell はファイルを使用する顧客に対し、レプリケーション、Unity または VNX からのネイティブファイル移行、または仮想化環境向けの Storage vMotion などのホストベースの移行を推奨しています。セッション中にライブ Unity NFS インポートを監視しましたが、EMC 時代のミッドレンジアレイを廃棄したことがある人なら誰でもその流れがわかるでしょう。ソースを検出し、ファイルシステムをペアリングし、バックグラウンドでコピーした後、PowerStore が古いシステムの性質を引き継ぐ間、短い切り替えウィンドウを取ります。Dell の推定では、まだ数万台の Unity システムが稼働しているため、このインポートパスは今後も活発に利用されるでしょう。

第1世代および第2世代では、展開は統合型かブロック最適化型かの選択から始まります。統合型を選択すると、ファイルが使用されるかどうかに関わらず、NASコンテナ用にCPUとメモリの一部が静的に割り当てられます。つまり、ブロックワークロードは、アイドル状態になる可能性のあるファイルヘッドルームに対して料金を支払うことになります。第3世代では、この選択はなくなります。すべてのアプライアンスは統合型で展開され、動的コア割り当てにより、必要に応じてブロックサービスとファイルサービス間でリソースが共有されます。ファイルは、ウィザードが必要と推測したリソースではなく、必要なリソースを取得し、ブロックはそれ以外のすべてを再利用します。Metroレプリケーションは世代を超えても機能し、第3世代アプライアンスと第2世代アプライアンス間のアクティブ/アクティブMetroボリュームペアの優先ロールを切り替えるには、クリック1回で済み、切り替えは1秒未満で完了します。

TLCかQLCか：ワークロードに最適なストレージ

第3世代モデル（1500、5500、9500）はすべて、TLCまたはQLC E3.Sドライブに対応しており、モデルによる階層分けはなく、Dellによれば、メディアの種類によるパフォーマンスのトレードオフもありません。ラインナップを分けるために使用されていたTとQの接尾辞は第3世代では廃止され、モデル名でプラットフォームが定義され、ドライブの種類は用途に応じて自由に選択できます。

これを可能にするソフトウェアは、OS 5.0の自律型データパス機能であり、I/Oごとのインテリジェンスを配置とデステージングに適用することで、大容量QLCが十分な性能を発揮できるようにしています。内部的には、書き込みはDRAMに書き込まれ、旧世代で使用されていたCPUを介したパスではなく、RDMAインターコネクトを介してノード間でミラーリングされ、ドライブに触れることなくホストに確認応答されます。デステージング時には、システムは縮小されたデータをフルストライプ書き込みに集約してバックエンドに送信し、書き込み増幅を抑えます。これはQLCの耐久性にとって最も重要な特性です。Dellは、この改良されたデータパスにより、基盤となるハードウェアと同等の最大2倍の高速な読み取りを実現したと述べています。

容量は、TLC で 3.84TB、7.68TB、15.36TB、QLC で 30.72TB です。40 個のベイすべてを QLC で埋めると、Dell は 3U で 5.8PB の実効容量という見出しを掲げています。これは、6:1 の完全な削減を前提とした実効値です。Dell は QLC の参入障壁も下げました。第 3 世代の 1500 は 7 台の 30.72TB QLC ドライブから始まりますが、前世代の QLC 構成では最低 11 台が必要でした。PowerStore 5200Qが QLC を主流のワークロードに導入して以来、Dell の QLC に対する姿勢が進化するのを見てきました。第 3 世代では、QLC 対 TLC の決定は、ついにパフォーマンス ティアではなく、ギガバイトあたりの価格と密度に絞られます。

効率性と6対1の保証

第3世代では、ディスク上のジオメトリが変更されました。ページサイズが以前の世代の4Kから8Kに変更されたのです。これにより、システムがテラバイトあたりに追跡する必要のあるメタデータが半分になり、ユーザーのワークロードに容量と処理の余裕が生まれます。しかし、これだけでは重複排除にとっては後退となります。以前は独立して重複排除されていた2つの4Kブロックが、異なる8Kページに分割される可能性があるからです。OS 5.0の解決策は、非アラインメント重複排除です。8K境界上のページのみを照合するのではなく、システムはページ境界をまたぐ重複した8Kブロックを検出し、それらを削減することができます。これにはより多くの処理が必要ですが、これはまさに第3世代ハードウェアがサイクルと新しいオフロードシリコンを投入して行うべき種類の処理です。強化された圧縮オフロードが、データ削減パイプラインを完成させます。ジオメトリの変更はホストとアプリケーションにとって透過的であり、イニシエータ側で再構成する必要はありません。

そのパイプラインこそが、見出しのDR数値の背後にあるものです。Dellはこのプラットフォームでデータ削減保証を5:1から6:1に引き上げましたが、その数値には条件が付いています。6:1の保証は、削減可能なデータに対して、OS 5.0が最初にインストールされた第3世代アレイに適用されます。Dellのエンジニアは、その仕組みについて私たちに率直に説明してくれました。対象となる顧客が削減可能なデータで6:1を実現できない場合、Dellは追加のドライブで対応します。同社は、新しいQATオフロード世代、より高速なプロセッサ、CPUのノード間転送を軽減するRDMAカード、改訂されたデータストライピング、そして削減アルゴリズムがどこで節約の機会を逃しているかを示したDell AIOps（旧CloudIQ）の長年のフリートテレメトリの組み合わせが功を奏したと述べています。

Dellは、負荷の軽いクラスタ（物理容量の1.4%を使用）から2つの容量ダッシュボードのキャプチャを提供し、これらの数値がPowerStore Managerでどのように表示されるかを示しました。データ節約パネルは、書き込まれたすべてのデータに対する全体的なDRRと、アレイが削減不可能と分類したデータを除外した個別の削減可能なDRRを報告し、削減不可能な部分はGB単位で示されます。最初のキャプチャでは、2.5TBの論理データが359GBの物理スペースに格納され、全体的なDRRは7.2:1、削減可能な部分では11.7:1となっています。

同じボリュームにさらにデータが書き込まれた2番目のキャプチャでは、物理容量376.4GBに対して論理容量2.7TBが表示され、全体の効率は7.4:1、削減可能な効率は12.3:1となっています。ダッシュボードにはスナップショットとシンプロビジョニングによる節約も全体の効率値（ここでは29.5:1と28.2:1）に反映されていますが、これは6:1の議論には含めない方が良い数値です。なぜなら、保証範囲は削減可能なデータに対するデータ削減に限られているからです。これらはDellがDellデータセットをキャプチャしたものなので、レポートのデモンストレーションとして扱ってください。実際の運用ワークロードがどれだけ削減されるかは別の問題です。

NAS、Nutanix、そして外部ストレージの物語

PowerStoreをAHVの外部オールフラッシュストレージとしてNutanix NCI 7.6に導入したパートナーシップに続き、OS 5.0ではPowerStore Managerの統合がさらに進みました。Nutanixは、VMwareがVMをファイルに分解するのと同様に、多数のボリュームからストレージを構築します。AHV上の数百のVMは、アレイ上で4,000のボリュームに相当します。5.0以前は、これらのボリュームは一般的なボリュームビューに表示され、他のすべてのボリュームを覆い隠していました。現在では、Nutanixクラスタが接続されると、PowerStore Managerは外部管理ボリュームタブ（および対応する外部管理ホストタブ）を追加し、Nutanixオブジェクトを独自のビューに隔離し、それぞれにNutanixアプリケーションタイプでタグ付けします。ストレージ管理者はボリュームリストを取り戻し、Nutanixが接続されていないシステムではこのタブは存在しません。

PowerStore の接続は Prism Central から行います。外部ストレージベンダーとして Dell PowerStore を選択し、PowerStore Manager を指定するだけで、Nutanix 側でのボリューム作成とマッピングが統合処理されます。ハイパーバイザー戦略を柔軟に変更したい企業にとって、基盤となるアレイは変更不要ですが、その上に構築されるプラットフォームは柔軟に対応できます。

PowerStoreOS 5.0 のモビリティ機能は OpenShift にも拡張されています。PowerStoreOS 5.0 は XCOPY オフロードを Red Hat の Migration Toolkit for Virtualization と統合しているため、マルチディスク VM を含む VM の移行時に、iSCSI やファイバー チャネルを介してホスト経由でデータをルーティングするのではなく、コピー処理をアレイにオフロードします。KubeVirt へ VM を移行するお客様にとって、これは本稿後半で説明する Automation Platform のストーリーと自然に結びつきます。つまり、移行トラフィックをホストが一切処理する必要がなくなるということです。

パフォーマンスをより鋭く見つめる

OS 5.0では、アレイの余裕をより簡単に視覚化できる新しいパフォーマンスダッシュボードウィジェットが追加されました。パフォーマンス使用率ウィジェットは、アプライアンスの負荷を構成要素に分解するため、使用率の数値がもはや謎ではなくなります。チャート上のポイントにカーソルを合わせると、その時点でのCPU、キャッシュメディア、フロントエンドポート、バックエンドドライブの使用率とレイテンシが表示されます。このウィジェットには持続IOPSビューも搭載されており、システムが約2週間分の履歴を収集すると、予測トグルで使用率とレイテンシを信頼区間とともに3か月先まで予測できます（スクリーンショット参照）。

異常検出自体は PowerStoreOS 4.2 でアプライアンス レベルで実装されました。5.0 で追加されたのはダッシュボードへの昇格で、6 つのメトリック (帯域幅、合計、読み取りおよび書き込み IOPS、レイテンシ、平均 I/O サイズ) をカバーする専用ウィジェット、アプライアンス間の並列比較、およびエクスポート可能な結果が含まれています。メカニズムは変更されていません。約 72 時間分の履歴のベースラインを構築した後、アレイは各ワークロードの動作を学習し、ライブ メトリックの背後に期待される範囲を描画し、静的なしきい値がトリガーされるのを待つのではなく、逸脱をフラグ付けします。スクリーンショットがそれを物語っています。帯域幅が灰色の履歴季節性の範囲内で変動し、ツールチップには観測値、期待される範囲、および明確な異常判定が表示されます。

制限テーブルにも余裕が生まれます。5.0では、ボリュームファミリーごとのクローン制限が256から1,000に引き上げられ（500を超えるGen 2モデルとすべてのGen 3モデルはアップグレード時に自動的に適用）、ハイエンドの9XXXモデルではボリュームとNVMeホストのマッピングが32,000に倍増し、大型のGen 2およびGen 3システムではNASサーバーインターフェイスが1,000、ファイルシステムが14,000に引き上げられ、ファイル制限の通知が80%、90%、99%の時点で追加されるため、上限に達したときに突然驚くことはありません。

これらのビューの基盤となるI/Oレベルのテレメトリは、デルがアレイ自体にインラインでランサムウェアを検出するために構築した土台であり、同社はこの機能を近日中に提供開始する予定だと述べている。

サイバーレジリエンス：MPA、Dell Cyber​​ Detect、およびKeys

バージョン5.0におけるセキュリティ対策は、人的セキュリティの強化、データのスキャン、鍵の管理という3つの柱に分かれています。

マルチパーティ認証は以前のリリースで、有効にするか無効にするかの二者択一のスイッチとして導入されました。つまり、有効にすると、クラスタ上のあらゆる破壊的な操作に、別の管理者の承認が必要になります。OS 5.0では、よりきめ細かな設定が可能になりました。管理者は、コンピューティング、ストレージ、保護、システム、ハードウェア、設定の各カテゴリにわたる61種類の保護対象アクションのカタログから選択でき、デフォルトで41種類が​​保護されています。また、リストを自身の許容範囲に合わせて調整できます。ある組織では、スナップショットの削除には承認が必要だが、保護ポリシーの編集は許可する、といった設定が可能です。また別の組織では、ユーザーによる削除には別の管理者の承認が必要だが、SMB共有の変更には承認は不要、といった設定も可能です。

承認タイムアウトは、以前の7日間固定ではなく、3日から7日間まで設定可能になりました。メール通知とリマインダーにより、リクエストがキューで滞留するのを防ぎ、設定全体がクラスタ全体に適用され、新しいアプライアンスが参加すると自動的に反映されます。承認フロー自体もMPAで保護されています。保護されたアクションリストを変更すると、2人目の管理者が承認する必要のあるリクエストが生成され、監査ログにはリクエストしたユーザーと承認したユーザーが記録されます。すべてがREST経由で公開されているため、数十台のアレイを運用するサービスプロバイダは、フリート全体にわたって最適なMPA設定をスクリプト化できます。

Dell Cyber​​ Detectは、Index EnginesのCyber​​Senseアナリティクスを統合したDell独自のソリューションで、OS 5.0のコードではなく、アレイと並行して動作します。これは、PowerProtectでおなじみのフルコンテンツ分析エンジンです。PowerStoreをターゲットに、スナップショットをスキャンして破損や暗号化イベントの統計的特徴を検出します。ポリシーは、アレイに接続し、本番ホストを選択し、iSCSIまたはFC経由でスキャンをスケジュールするウィザードを使用して構成されます。管理者は、検証済みのクリーンなスナップショットのカタログを取得できるため、攻撃後の復旧は既知の正常なコピーから開始できます。これは、管理者であっても保持期間が満了するまで削除できないPowerStoreのセキュアスナップショットと組み合わせることで、Cyber​​ Detectが識別するクリーンなコピーは、攻撃者が削除できないコピーにもなります。データに対するCyber​​ Detect、テレメトリに対するAIOpsランサムウェア監視、コントロールプレーンに対するMPAにより、ランサムウェア対策はコンテンツ、動作、および影響範囲を網羅するようになりました。

3 つ目のトラックは、特に政府関連企業からの直接の顧客からの要望でした。保存データの暗号化キーのローテーション (D@RE) が、ユーザーが制御できるようになりました。以前はキー管理が完全に内部で行われていましたが、5.0 では、管理者が独自のコンプライアンス クロックでオンデマンドで新しいキー セットを生成し、キー ストアをダウンロードできます。Dell はこれを最初のフェーズと説明し、ロード マップにはスケジュールされたローテーションが含まれています。第 3 世代のハードウェアには、さらに 2 つのレイヤーが追加されています。ポスト量子暗号で署名されたファームウェアにより、プラットフォームは「今すぐ収集して後で復号化」戦略に対抗できる位置づけとなり、FIPS 140-3 準拠の SDPM により、デステージを待っているキャッシュ データは、ドライブ上のデータと同じ標準で保護されます。

AIによる推奨事項：洞察から行動へ

7月現在、Dell AIOps（旧CloudIQ）とDell Automation Platformが連携し、AIによる推奨事項と自動最適化を結びつける統合機能が提供されていますが、現時点では提供範囲が限定されています。

この組み合わせにより、オペレーターは洞察から行動へとより直接的な経路を得ることができ、人間の監視とデジタルツイン技術によって、システムが提案する内容への信頼を構築できます。ユーザーは、単一のインターフェース内で推奨事項から自動アクションへと移行できます。このインターフェースは、Dellが生成型UIとして再設計したもので、デフォルトではチャット優先かつ最小限の機能を備え、ユーザーは必要なテーブル、グラフ、ビューを生成し、それらを永続的なパーソナライズされたワークスペースに固定できます。

リリース時には、実行可能なユースケースが 3 つあり、そのうち 2 つは PowerStore 専用です。継続的な容量最適化では、再利用可能なストレージ、ホスト マッピングがないボリューム、または最近の I/O がないボリュームが特定され、管理者は PowerStore Manager を開くことなく、推奨事項から実際の再利用可能化までを実行できます。PowerStore のシステム アップデートでは、管理者はコード レベルの許容範囲、ターゲットのインストール日、バッチ サイズ、およびアップグレード前のヘルス チェックの繰り返しを設定し、同じ会話からアップデート プランを実行できます。アップデートが失敗した場合は、サポート チケットが生成されます。3 つ目のユースケースでは、過剰にプロビジョニングされた VMware ベースのクラスターを特定し、ワークロードで不要になったノードを統合し、クラスターに必要なノードを保持することで、Dell Private Cloud クラスターを拡張します。

設計上の決定事項のうち、特に注目すべき点が2つあります。まず、すべての操作に人間が関与する仕組みになっており、システムは計画と根拠を提示し、「この推奨事項はどのようにして思いついたのですか？」という質問に平易な言葉で回答し、明確な承認を待ちます。初期導入後まもなく、顧客環境のデジタルツインが提供され、変更が実行される前に下流への影響を検証します。ServiceNowの変更管理との統合も開発中であり、チケット単位で承認を制限できます。次に、ライセンス体系に変更はありません。AI RecommendationsはAIOpsに付属しており、AIOpsはDell ProSupport以上の契約に含まれているため、ほとんどのPowerStore導入企業でこの機能を利用できます。

プライベートクラウド、オートメーションプラットフォーム、およびMCP

AI 推奨レイヤーの下には、プライベート クラウドをデプロイおよび実行する仕組みがあります。Dell Automation Platform オーケストレーターを使用すると、管理者はブループリントを選択し、JSON 構成をアップロード（またはパラメーターを手動で入力）して、実行グラフが環境全体のデプロイを順に実行していく様子を確認できます。これには、PowerStore ハードウェアの検証、コンピューティングとネットワークの準備、ハイパーバイザーのインストールが含まれ、ストレージの手順はワークフローに直接組み込まれています。これには、PowerStore ボリュームを iSCSI 経由で VMkernel アダプターに接続したり、Kubernetes が稼働している場合に CSI ドライバーをインストールしたりすることが含まれます。ハイパーバイザー メニューは、VMware、Red Hat、Nutanix、Microsoft Azure Local に及び、Dell Private Cloud 拡張機能は、各プラットフォームのコンソール、vSphere Client、OpenShift Web Console、Prism、または Azure ポータルにインストールされます。そのため、VM とコンテナの 2 日目のライフサイクル管理は、チームが既に使用しているツールで行われます。Dell は、同じ拡張機能を使用して OpenShift 上の KubeVirt に Windows VM をデプロイすることで、コンテナと VM の操作を 1 か所に統合​​し、ループを閉じることができます。

ワークロードの所有者にとって興味深いのは、ブループリントカタログです。インフラストラクチャブループリントに加えて、Dell Automation Studio を使用すると、顧客はカスタムオーケストレーションを構築できます。Dell のショーケースは、データベース・アズ・ア・サービス パターンです。vCenter 上の PowerStore をバックエンドとするデータストアに PostgreSQL ブループリントをデプロイし、アプリケーションは Ansible を介してインストールされます。ログはジョブの VMware および Red Hat ステップ全体で統合され、vSphere が起動している間、ライブの cloud-init および VM 初期化ログが 1 つのレポート ビューにストリーミングされます。vSphere 側は VMware SDK 上に構築されたプラットフォーム プラグインを介して実行され、Ansible アクションが完了すると、データベースが配置され、サービスが提供されます。PowerStore の顧客に対する売り文句は、アレイがプロビジョニング先の宛先ではなくなり、プラットフォームが自動的に構成するリソースになるということです。

これらすべてが向かう先は、エージェント型です。Dell の発表文は明確です。オートメーション プラットフォームは「AI エージェントと対話型インターフェイスを組み合わせることで、企業がインフラストラクチャを展開、監視、管理する方法を変革する」ものであり、プラットフォームのエージェント型 AI 機能は今年後半に予定されています。Dell は、顧客が独自のエージェントを持ち込むという要望に応えて MCP サーバーの開発に取り組んでいることを認めており、Dell ストレージ向けの MCP サーバーが最初に登場します。Dell Technologies 開発者サイトでは、PowerStore、PowerScale、PowerProtect、PowerFlex、PowerMax、ObjectScale にわたる 100 を超える MCP ツールが今後登場する予定であることが既に説明されており、一般提供は年末を目標としています。ツールとパラメーターは各プラットフォームのバージョン管理された OpenAPI 仕様から派生しているため、モデルは存在しない呼び出しを作成することはできません。ローカル プロセス、HTTP サーバー、または Kubernetes サイドカーとして実行でき、すべての変更には構造化された監査ログが記録され、大量破壊操作には 2 段階の確認が必要です。MCP は、AI エージェントにエンタープライズ システムへの構造化された許可アクセスを提供する標準インターフェイスとして急速に普及しています。オートメーションプラットフォーム用のMCPサーバーを導入することで、顧客自身のエージェントが、プラットフォームのネイティブエージェントが利用するのと同じ設計図、推奨事項、テレメトリデータを利用できるようになります。プラットフォームにおけるMCPの導入計画は、エージェントの展開と並行して具体化していくと予想しており、その際には改めてご報告いたします。

次は？：リズムは続く

PowerStoreOS 5.0は既にリリースされていますが、Dellは顧客ニーズに応えるため迅速なリリースサイクルを採用しており、開発チームは既に5.1の開発に深く取り組んでおり、今秋にリリース予定です。Dellは5.1の全機能の詳細をリリース直前まで公表していませんが、既に決定している機能の一つは、データ転送時の暗号化です。

PowerStore Gen 3 は、現在では OCP スロットに EDIF 対応のファイバー チャネル カードを搭載して構成できます。暗号化自体は、ソフトウェア アップデートによって提供されるため、5.1 の話題の中心となっています。EDIF (Encrypted Data-in-Flight) は、ホストとアレイ間、または 2 つのレプリケーション アレイ間のファイバー チャネル トラフィックを暗号化し、ファイアウォールでは対応できなかったギャップ、つまり平文で転送される内部 SAN トラフィックを解消します。アレイは受信時に復号化するため、重複排除と圧縮は削減可能なデータとして認識され、このリリースでさらに改善するために尽力した効率性を損なうことなく、ワイヤが保護されます。ホスト層またはアプリケーション 層で暗号化すると、アレイに到着するすべてのブロックが固有のノイズになりますが、EDIF はそのような負担をかけずにトランスポートを保護します。

物語のもう半分はサーバー側にあります。Emulex Secure HBAについては、ハードウェアオフロードによるアダプタ自体でのセッションベースの暗号化、新興のFC-SP-3規格への準拠、内部トラフィックに対するゼロトラストの姿勢など、詳細に解説してきました。そして、このアプローチが自律的なSAN全体の暗号化へと成熟していく様子を見てきました。5.1でアレイ側が稼働すると、エンドツーエンドで暗号化されたファイバーチャネルがPowerStore上で通常の構成となります。

ハードウェア発表会で執筆した記事は、第3世代とPowerStoreOS 5.0がどのように融合するのかという期待感で締めくくられていました。今回、一般提供版を実際に使用してみたところ、ソフトウェアは搭載されるシャーシの野心に見合う性能を備えていることが分かりました。3世代にわたるハードウェアに対応する単一のOS、主流となったQLC、保証付きの大幅な効率向上、そして自己完結型の運用レイヤーにより、ストレージ管理者が短期間で達成できることがさらに拡大しています。

最後に、もう一つ注目すべき数字があります。7月、デルの運用テレメトリは、報告対象システム全体でPowerStoreの稼働時間が累計10億時間を突破しました。これは6年間の運用実績に相当し、マシン年換算で11万4000時間以上になります。この規模のシステム全体にわたる学習こそが、前述のデータ削減チューニング、異常検知モデル、レコメンデーションエンジンのトレーニングに活用され、5.0の優れた機能の大部分を支える強みとなっています。プラットフォームの次の10億時間は、より高度なソフトウェアと、それに匹敵する性能を持つハードウェアプラットフォームによって実現されます。

PowerStore製品ページ

このレポートは、Dell Technologies の提供により提供されています。このレポートで表明されているすべての見解や意見は、検討中の製品に対する当社の公平な見解に基づいています。