IBM Storage Cephがクラスタ性能を高速化、ただし次はベンチマーク検証
IBM Storage Cephはバージョン9.9.2で、頻繁にアクセスされるメタデータを低速なデバイスに残すのではなく高速ストレージへ移すことで、クラスタ性能を高速化する。
10月14日のリリースでは、RocksDBによって管理されるメタデータ向けの自動ティアリング機構、BlueFS Spillover Cleanerが導入された。IBMによれば、この機能は重要なワークロードの一貫性を高め、レイテンシを低減するはずだという。ただし、同社の発表にはベンチマーク結果が含まれていない。
この不足が中心的な緊張を生んでいる。IBMは混在メディアのCephクラスタにおける現実的な性能課題に対処したが、購入者には依然としてワークロードレベルの証拠が必要だ。このリリースは、分散ストレージクラスタの改善には常にフラッシュの追加、ノードの増設、あるいは大規模なハードウェア更新が必要だという前提に疑問を投げかける。
また、コミュニティ版Cephの導入環境や競合ストレージプラットフォームにも圧力をかける。管理者は、自動メタデータ配置が許容できない移行、監視、アップグレードのリスクを増やさずに、意味のある改善をもたらすかを判断しなければならない。
IBM Storage Cephはメタデータティアリングでクラスタ性能を高速化する
重要な変更は新しいストレージプロトコルではない。Cephが最も頻繁に利用されるメタデータをどこに置くかを自動的に判断する仕組みだ。
IBM Storage Ceph 9.9.2は2026年10月14日に一般提供を開始した。IBMはこの製品を、単一のテクノロジースタックを通じてブロック、ファイル、オブジェクトストレージを提供する、エンタープライズサポート付きのソフトウェア定義プラットフォームと説明している。
今回のリリースの中心となる性能機能はBlueFS Spillover Cleanerだ。IBMは、その基盤となる仕組みをインテリジェントなBlueFS Tiering Managerとも呼んでいる。
BlueFSは、CephのストレージバックエンドであるBlueStoreがRocksDBファイルを管理するために使用する小規模なファイルシステムである。RocksDBは、論理オブジェクトと物理ストレージの対応関係を含む内部メタデータを記録する組み込み型キーバリューデータベースだ。
Cephのストレージデバイスでは、複数のメディア層を使用できる。WALデバイスは先行書き込みログを保持し、オプションのDBデバイスはRocksDBメタデータを保存する。メインデバイスはオブジェクトデータを保持し、ほかに収まりきらなくなったメタデータも受け入れることができる。
管理者は通常、DBおよびWAL機能をSSDまたはNVMeデバイスに配置する。その一方で、大規模なオブジェクトデータセットは、より安価なハードドライブに置くことができる。
このアーキテクチャには重要な障害モードがある。高速なDBデバイスがいっぱいになると、RocksDBファイルがプライマリデータデバイスへあふれ出す可能性がある。ハードドライブは十分な容量を提供できるが、そのようなスピルオーバー後はメタデータアクセスが遅くなり、予測しにくくなる。
新しいマネージャーは、ファイルアクセスパターンを継続的に調べる。IBMの9.9.2リリース概要によると、頻繁にアクセスされるファイルをDBデバイスへ再配置し、あまりアクティブでないファイルを低速メディアへ移す。
この仕組みはキャッシュ管理に似ているが、アプリケーションオブジェクトではなくRocksDBファイルに対して動作する。アクティブなワークロードに最も直接的に寄与するメタデータのために、限られた高速容量を確保しようとする。
この違いは重要だ。アプリケーションはホットなメタデータを特定したり、特別な配置コマンドを発行したりする必要がない。ストレージ層がアクティビティを監視し、裏側でファイル配置を変更する。
初期の性能レポートは、この構成によって価値の高いメタデータを高速メディア上に維持できると論じている。また、非アクティブなデータベースファイルが貴重なSSD容量を無期限に消費することも防ぐはずだ。
IBMは、その結果としてメタデータアクセスがより効率化され、レイテンシが低下し、クラスタ性能の一貫性が高まるとしている。こうした説明は、独立したテストが再現可能なワークロードで効果を測定するまで、ベンダー側の主張にとどまる。
IBM Storage Ceph 9.9.2には、より広範な更新も含まれる。これらはNVMe/TCPゲートウェイ管理、S3オブジェクトブラウジング、CephFS隔離、NFSフェイルオーバー、SMB統合、クラスタ管理を対象とする。
いくつかの追加機能は、引き続きテクノロジープレビューである。完全なオブジェクト重複排除、透過的なNFS状態移行、macOS SMBサポート、S3経由のSMBアクセスは、いずれも成熟した本番機能として位置付けられているわけではない。
BlueFS Spillover Cleanerが異なるのは、Cephサービスの下にある分散オブジェクト層、RADOSの中核に対処する点だ。そのため、その効果は複数のインターフェースを通じて公開されるワークロードに及び得る。
この機能は、別のアクセス手段を追加するのではなく、繰り返し発生する運用上の問題を対象にしている。IBMは、多くの顧客がすでに運用しているハードウェアから、より安定した性能を引き出そうとしている。
このため、この更新は限定的な説明から想像される以上に重要だ。ストレージ購入者には、実際の導入条件で改善が維持されるなら、ハードウェア拡張を先送りできる可能性のあるソフトウェア機構が提示されている。
メタデータ配置がクラスタ全体の性能課題になる理由
オブジェクトのあらゆる操作は正確な内部マッピングに依存するため、少量の誤配置されたメタデータが、はるかに大きなデータセットへ影響を及ぼし得る。
Cephは、OSDとして知られる多数のオブジェクトストレージデーモンに情報を分散する。各OSDはローカルストレージデバイスを管理し、レプリケーション、リカバリ、リバランシング、クライアント操作に参加する。
BlueStoreはデータを生のブロックデバイスへ直接書き込む。オブジェクトとその構成要素の配置を示すメタデータにはRocksDBを使用する。BlueFSは、そのデータベースにファイルシステムサービスを提供する。
メタデータ検索は、大規模なオブジェクト転送と比べれば小さい。しかし、検索の遅延は多くのアプリケーションリクエストのクリティカルパス上に存在し得る。ワークロードが多数の小規模またはランダムな操作を生成する場合、その影響はより明確になる。
性能は一様に低下するのではなく、不安定になる場合もある。あるリクエストはSSD上のメタデータへ到達する一方、別のリクエストはハードドライブにあふれ出したRocksDBファイルに触れる可能性がある。
平均スループットでは、この差を隠せる場合がある。データベースプラットフォーム、仮想マシン、対話型分析は、多くの場合、見出しになるシーケンシャル帯域幅よりもロングテールレイテンシに敏感に反応する。
これが、IBMによる配置自動化の決定が重要である理由だ。クラスタには高速なDBデバイスが導入されていても、メタデータの規模が変化した後には有効に活用されない可能性がある。
成長はこの状態を徐々にもたらす。基盤となるハードウェアが健全なままでも、オブジェクト、スナップショット、バケット、配置グループの増加はメタデータへの圧力を高める。
運用イベントはさらなる負荷を加える可能性がある。リバランシング、リカバリ、コンパクション、保守活動はアクセスパターンを変化させたり、デバイスリソースを競合させたりする。
管理者はDBデバイスの容量を見積もり、スピルオーバーを監視できるが、静的な計画が変化するワークロードに常に一致するとは限らない。大規模オブジェクト向けに設計されたクラスタが、後に多数の小さなファイルや急速に変化する仮想マシンイメージを受け入れることもある。
BlueFS Spillover Cleanerは、高速層を適応的にしようとする。観測されたアクセスに基づき、アクティブなRocksDBファイルを昇格させ、より低温のファイルを降格させる。
概念は理解しやすいが、その実装には難しい問題が伴う。マネージャーは、過剰なバックグラウンドI/Oを生じさせずに有用なパターンを特定しなければならない。また、ティアリング自体が得ようとする利益を消費するほど頻繁にファイルを移動させない必要もある。
IBMは発表の中で、このポリシーのしきい値や詳細な判断モデルを公開していない。そのため購入者には、マネージャーがワークロードの変化にどれほど迅速に反応するかについて明確な見通しがない。
また、コンパクション中に機能がどのように振る舞うかも知る必要がある。RocksDBは定期的にデータファイルを再編成し、ファイルサイズやアクセスパターンを変える可能性のある書き込みアクティビティを生み出す。
このクリーナーは、大容量ハードドライブと小規模なSSDメタデータデバイスを組み合わせるハイブリッドクラスタで特に有用となる可能性がある。こうしたシステムでは、DBメディアとSLOWメディアの性能差が最も大きく現れる。
オールフラッシュクラスタは別のケースとなる。二つのフラッシュ層の間でメタデータを移動することにも意味はあり得るが、レイテンシ差はより小さいかもしれない。CPU、ネットワーク、あるいはソフトウェアの直列化が主要な制約となる可能性がある。
IBMのハードウェアガイダンスは、Storage Cephが独自仕様ではない汎用システム上で稼働できることを強調している。IntelおよびAMDのx86-64プロセッサをサポートし、バージョン9.9.0では完全なARMサポートが追加された。
このハードウェアの柔軟性は、Cephの魅力の中心にある。同時に、単一の性能主張であらゆる導入環境を代表できないことも意味する。
ドライブの種類、ネットワーク設計、OSD密度、CPU割り当て、障害ドメイン、データ保護ポリシー、オブジェクトサイズは、いずれも結果を変え得る。ティアリング機能もこの変動性を引き継ぐ。
したがって実用上の約束は、単にCephを高速化することよりも限定的だ。IBM Storage Cephがクラスタ性能を高速化するのは、メタデータのスピルオーバーが意味のあるボトルネックであり、高速なDB容量に余裕がある場合である。
この条件は多くの混在メディアシステムに存在するだろうが、すべてに当てはまるわけではない。購入者は、アップグレードを万能の解決策とみなす前に、まず自らのレイテンシがどこで発生しているかを特定すべきだ。
真の競争はソフトウェア最適化とハードウェア拡張の間にある
IBMの最も強い主張は、より賢明な配置によって、顧客にクラスタの容量層を交換させずに性能を回復できるという点だ。
ストレージの負荷に対する一般的な対応は、リソースの追加である。管理者はより大容量のDBデバイスを導入し、ハードドライブをSSDに置き換え、ノードを追加し、あるいはネットワークを再設計する場合がある。
こうした行動は有効であり得るが、予算、保守スケジュール、障害計画、物理容量に影響する。分散クラスタの拡張は、新しいリソースが十分な効果を発揮する前にデータ移動を引き起こす場合もある。
BlueFS Spillover Cleanerは別の道筋を示す。すでに存在するフラッシュを継続的に活用し、アクティブなメタデータを優先することで価値を高めようとする。
これにより、このリリースの主な対立軸が明確になる。ソフトウェア主導の最適化と、ハードウェア主導の拡張である。IBMは、配置インテリジェンスが少なくとも一部のインフラ変更を先送りできると見込んでいる。
同社は容量計画の必要性をなくすわけではない。著しく容量不足のDB層では、ソフトウェアがどれほど適切に優先順位を付けても、すべてのアクティブなファイルを保持できない。
メタデータティアリングは、飽和したネットワークや過負荷のプロセッサを修復することもできない。あらゆるワークロードに対して、ハードドライブのオブジェクトストレージをオールフラッシュアレイへ変えるものではない。
その価値は無駄を避けることにある。非アクティブなメタデータが高速メディアを占有し、アクティブなメタデータが低速デバイス上にあるなら、ハードウェアを追加購入しても、配置を是正せずに症状を処理するだけになる。
この変更は、DIYによるCeph運用に対するエンタープライズ版の優位性も強める。コミュニティ版Cephはオープンで高度に設定可能なままだが、組織は選択した構成を統合、検証、監視、サポートしなければならない。
IBMはCephコードを、テスト済みリリース、管理インターフェース、アップグレードプロセス、ハードウェアオプション、エンタープライズサポートとともに提供する。自動ティアリングマネージャーは、サポート付きディストリビューションと社内で維持する導入環境を比較するもう一つの理由を購入者に与える。
これは、単純なプロプライエタリ対オープンソースの対立ではない。IBM Storage Cephは引き続きCephを基盤としており、IBMはより広範なエコシステムにも貢献している。
真の違いは運用責任に関するものだ。コミュニティユーザーはシステムを直接調整できる一方、IBMの顧客は厳選されたライフサイクルとサポート付き実装に対して費用を支払う。
Red Hatは、Red Hat Ceph Storageとプラットフォーム統合を通じて、エンタープライズ向けCeph技術も提供している。IBMは2023年にRed Hatからエンタープライズ向けCeph製品の責任を引き継ぎ、CephをIBMの幅広いストレージポートフォリオに組み入れた。
従来型のストレージベンダーは別のアプローチを取る。多くの場合、独自ソフトウェアと厳格に管理されたハードウェアを組み合わせ、構成のばらつきを抑える一方で、汎用ハードウェアの柔軟性を制限している。
IBMはその中間に位置する。サポート付きのソフトウェア定義ストレージ、任意で選べる検証済みノード、そして単一のアプライアンスモデルにとどまらない導入オプションを提供する。
パフォーマンスマネージャーは、この立ち位置によく合っている。IBMはハードウェアの選択肢を維持しながら、ソフトウェアによって挙動を改善できる。
バージョン9.9.2には、RADOS Gatewayインスタンス向けのダウンタイムなしローリングアップグレードも含まれる。IBMによれば、新しいRGWバージョンは既存インスタンスと並行して起動でき、処理中のリクエストは旧バージョンで完了できる。
この機能は運用面での主張を補強する。パフォーマンスは重要だが、企業は保守作業がS3互換アプリケーションを中断させるかどうかも評価する。
このリリースでは、NVMe/TCPゲートウェイグループ向けのライフサイクル制御も強化された。管理者はダッシュボードを通じて、ホスト、アクセス、ネットワーク、表示の管理機能を拡張して利用できる。
これらの変更がRocksDBを直接高速化するわけではない。しかし、ブロックサービスとオブジェクトサービスに伴う管理コストを削減し、エンタープライズディストリビューション全体の価値に影響を与える。
IBMの従来のCephリリースも、別の仕組みで性能向上を追求してきた。Storage Ceph 8.0にはスナップショットの改善が含まれ、テクノロジープレビューとしてCrimsonバックエンドの開発も継続された。
Crimsonは、非同期処理と最新CPUの効率性を軸に設計された新しいOSDアーキテクチャである。メタデータのスピルオーバーよりも広範なソフトウェア実行上の課題に取り組む。
バージョン9.9.0では、新規作成プールに対し、イレージャーコーディング最適化もデフォルトで有効化された。IBMによると、これらの最適化はパディングを減らし、対応構成における小規模I/Oの挙動を改善する。
この変更は、小さなオブジェクトやランダムアクセスを含むRBD、CephFS、オブジェクトワークロードに恩恵をもたらす。一方、IBMの最適化ガイダンスによれば、大規模なシーケンシャルオブジェクトワークロードへの効果は限定的だ。
こうした展開は、階層的な戦略を示している。IBMはデータ保護効率、OSD実行、メタデータ配置、プロトコル管理、管理ワークフローを改善している。
BlueFS Spillover Cleanerが際立つのは、高速ストレージと低速ストレージの間にある直接的なミスマッチに対処するためだ。アプリケーション側の変更を求めず、より良い挙動を実現するとしている。
競争上の問いは、ここから測定可能な形になる。ソフトウェア主導の配置は、ハードウェア拡張を先送りできるほどの改善をもたらすのか。それとも、限定的なボトルネックを滑らかにするだけなのか。
IBMの性能主張が示していないこと
このリリースは信頼できる仕組みを示しているが、IBMは本番ワークロード全体にわたる効果を定量化するのに十分なデータを示していない。
IBMの発表にも初期レポートにも、BlueFS Spillover Cleanerに関する標準化ベンチマーク結果は含まれていない。有効化構成と無効化構成を比較したIOPS、スループット、レイテンシの公開データもない。
IBMはテールレイテンシの分布も示していない。この欠落は重要である。より一貫した性能は、明示されている利点の一つだからだ。
平均値だけでは結論は出ない。購入者には、メタデータのスピルオーバー後に発生する散発的な低速処理を、この機能が抑制できるかどうかを示すパーセンタイルデータが必要となる。
発表ではテストクラスターの詳細も示されていない。読者は、ドライブの種類、DBデバイスの比率、ネットワーク速度、OSD数、レプリケーション設定、オブジェクトプロファイルを評価できない。
また、この機能の効果をブロック、ファイル、オブジェクトアクセス別に分けていない。各サービスはRADOSレイヤーに異なる負荷をかける。
仮想マシンのワークロードでは、小規模なランダムブロック操作が中心になる可能性がある。S3リポジトリには大規模なシーケンシャルオブジェクトが含まれる一方、データパイプラインでは数百万件の小さなファイルが生成される場合がある。
クリーナーの価値は、こうしたケースごとに大きく異なり得る。意図的に小さく構成したDBデバイスに焦点を当てたベンチマークは、十分にプロビジョニングされたクラスターでの効果を過大評価するおそれがある。
逆に、短期間のテストでは機能を過小評価する可能性がある。自動階層化には、アクティブなファイルを認識して配置を組み替えるために、十分な時間とワークロードの変動が必要だ。
バックグラウンドでの移動も別の不確実性を生む。昇格と降格はI/O帯域幅を消費するが、このリリースではそのオーバーヘッドの測定値は示されていない。
管理者は、システムがどのようにスラッシングを防ぐのかを問うべきだ。急速に変化するワークロードでは、ポリシーに安定した閾値がなければ、ファイルが階層間を行き来する可能性がある。
リカバリー時の挙動も検証すべきである。Cephクラスターでは、デバイスやノードの障害後、まさに予測可能なレイテンシが重要になる局面で、激しい内部活動が発生し得る。
このリリースでは、リカバリー中にクリーナーが停止するのか、優先順位を変えるのか、それともファイル移動を継続するのかが説明されていない。これらの判断は、アプリケーショントラフィックと修復時間の双方に影響し得る。
アップグレード時の挙動にも同様の注意が必要だ。既存導入環境では、マネージャーが自動的に開始されるのか、構成が必要なのか、初回の再配置を実行するのかを把握する必要がある。
IBMの公開サマリーには、すべての過去レイアウトを対象とした互換性マトリクスはない。購入者は、本番で有効化する前に、ドキュメントで前提条件を確認し、代表的なクラスターでテストすべきだ。
容量は依然として厳しい制約である。クリーナーはメタデータの優先順位を付けられるが、DB容量を増やすことはできない。高速デバイスより大きい、恒常的に高負荷なメタデータセットは、依然としてスピルする。
改善によって別の制約が露呈する可能性もある。メタデータ検索が高速化されれば、ネットワーク飽和やCPU処理が全体的な性能向上の上限になる場合がある。
これはIBMの設計を否定するものではない。主張が成立する範囲を定義するものだ。
Cephアーキテクチャガイドは、ストレージ、ネットワーク、ソフトウェアの相互作用するコンポーネントに挙動が依存する分散システムを説明している。一つの経路を最適化しても、アプリケーションレベルで同程度の改善が保証されるわけではない。
したがって組織は、IBM Storage Ceph 9.9.2を可検証なアップグレードとして扱うべきであり、オブザーバビリティの代替とみなすべきではない。導入前にチームは、ベースラインとなるレイテンシ、スループット、デバイス使用率、スピルオーバー状況を記録すべきだ。
アップグレード後には、代表的なワークロードを再実行する必要がある。テストには、定常トラフィック、急激なワークロード変化、RocksDBコンパクション、リカバリー、保守作業を含めるべきだ。
チームは平均値だけでなく、パーセンタイルレイテンシを比較すべきである。また、DBデバイスとSLOWデバイス間で移動するデータ量も追跡する必要がある。
成功した結果では、アクティブなメタデータが高速メディア上により多く維持され、破壊的なバックグラウンド活動が起きていないことが示されるはずだ。より整理されたストレージレイアウトだけでなく、アプリケーションレベルの利点も確認される必要がある。
調達においては、独立したベンチマークが特に重要である。IBMはStorage Cephをソフトウェア、サービス、検証済みハードウェアと組み合わせた製品として販売している。
これらの導入モデルが同一の結果を生むとは限らない。購入者には、自社環境に近い構成で得られた証拠が必要だ。
慎重な結論は明快である。IBMはCephレイテンシの一因を減らす技術的に妥当な方法を説明しているが、公開されている証拠は影響の定量化に至る前で止まっている。
改善の重要性を示す3つのシグナル
次の検証点は、IBMの配置メカニズムがリリース発表の外でも再現可能な向上を生むかどうかだ。
最初のシグナルは、ベンチマークの公開である。IBM、パートナー、または独立テスターは、同一ハードウェア上で、クリーナーを有効化したバージョン9.9.2と無効化した構成を比較すべきだ。
有用なテストには、NVMe DBデバイスと組み合わせたハードディスクのデータデバイスを含める必要がある。平均およびパーセンタイルレイテンシ、IOPS、スループット、移動オーバーヘッド、DB階層の使用率を報告すべきだ。
仮想マシン、小規模S3オブジェクト、大規模オブジェクト、CephFSのメタデータ集約型操作を、それぞれ別のプロファイルで扱う必要がある。複数のワークロードで改善が一貫していれば、これらの結果はIBMの主張を強化する。
意図的に制約を設けたデモに限定された結果は、より広い解釈を弱める。その仕組みを証明することにはなっても、一般的な本番価値を示すものではない可能性がある。
2つ目のシグナルは、アップグレード済みクラスターから得られる運用上の証拠である。管理者は、需要が変動する数週間を経ても、アクティブなRocksDBファイルが高速デバイス上に維持されるかを監視すべきだ。
安定した挙動は、IBMのソフトウェア最適化という主張を支える。頻繁な移行、予期しない書き込み増幅、難しいチューニングが見られれば、より大きなDBデバイスと単純な静的レイアウトの優位性が高まる。
実際の導入環境では、リカバリーやコンパクション中にクリーナーがどのように動作するかも明らかになるはずだ。これらの期間は、有効なポリシーと、整った実験室環境向けに最適化されたポリシーを分ける可能性がある。
3つ目のシグナルは、IBMが機能説明から詳細なライフサイクルガイダンスへ移行することだ。ドキュメントでは、デフォルト設定、閾値、監視メトリクス、アラート、ロールバック時の挙動、アップグレード前提条件を説明すべきである。
明確なガイダンスは、IBMが幅広い本番利用を期待していることを示す。ドキュメントが限定的であれば、顧客は厳密に監督された導入を通じて進めるべきだということになる。
競合他社やアップストリームの反応も重要だが、二次的な要素である。決定的な証拠は、マーケティング比較ではなく、性能データと運用経験から得られる。
顧客は、IBMがCrimsonへの取り組みを継続するかにも注目すべきだ。メタデータ階層化はファイル配置を改善する一方、CrimsonはOSDソフトウェアパス内部の効率を対象としている。
両者が順調に成熟すれば、IBMはCephの性能上限がソフトウェアによってますます対処可能になっていると主張できる。これは、ハードウェア中心の拡張や独自ストレージシステムに対する同社の立場を強化するだろう。
イレージャーコーディング最適化は、もう一つの参照点となる。IBMが、効率向上が新規プールに十分成熟したと判断した場合に、すでにデフォルトの挙動を変えていることを示すからだ。
BlueFS Spillover Cleanerが同様の信頼を得るには、持続的な負荷下での挙動を顧客が理解できるようになる必要がある。ハードウェア障害や急激な需要変化が起きた際にも、自動配置は予測可能でなければならない。
より広い教訓はCephを超える。現代のストレージシステムは、より大きな容量プールを連携して管理する、小容量で高速なメディア階層への依存を強めている。
この高速階層を適切に管理することは、名目上の容量と同じくらい重要になり得る。配置が不適切ならフラッシュは無駄になり、制御されない移動はそれ自体が性能コストを生む可能性がある。
IBM Storage Cephは、メタデータ配置を能動的なプロセスに変えることでクラスター性能を高める。見出しを飾るベンチマークがなくても、これは意味のあるアーキテクチャ上の変更だ。
ただし、アーキテクチャは購買判断の始まりにすぎない。企業チームは、レイテンシがどれだけ低下するのか、どのワークロードが恩恵を受けるのか、移動にどのような運用コストが伴うのかを知る必要がある。
このリリースは、管理者に具体的な実験を提示している。BlueFSスピルオーバーのあるクラスターを特定し、ベースラインを確立し、管理された環境をアップグレードして、アプリケーションレイテンシとバックグラウンド活動の両方を観察することだ。
クリーナーが適切なファイルを一貫して昇格させるなら、IBMは既存のハイブリッドストレージからソフトウェアで性能を取り戻せることを示したことになる。改善が限定的なままであれば、ハードウェア拡張は従来どおりの役割を維持するだろう。
現時点でIBM Storage Ceph 9.9.2が注目に値するのは、一貫した仕組みで特定のボトルネックを狙っているためだ。次の一手は、運用者と独立テスターに委ねられている。
実際のクラスターは、自動化されたメタデータ配置が次のハードウェア購入を先送りすると裏付けるのか。それとも、ボトルネックが単に別の場所へ移ることを明らかにするのか。
