top of page

Spectra Logic、十分に活用されていないストレージの再利用で拡張計画を再検討へ

58 分前
読了時間: 18分

Spectra Logicは10月27日、Storage Reclaimを発表した。これは、フラッシュおよびディスクシステムが埋まれば自動的に容量を追加購入しなければならないという前提に異議を唱えるものだ。この製品は非アクティブデータを特定し、条件を満たすデータを保護されたストレージ階層へ移動する。Spectra Logicによる十分に活用されていないストレージの再利用は、一般的なアーカイブ作業をインフラ予算の問題へと転換する。既存容量のうち、どれだけがなお現行業務に使われているのかという問いだ。

同社によれば、このアプローチはストレージ分析、移行ポリシー、データ管理ソフトウェア、そしてBlackPearlゲートウェイおよびテープインフラを組み合わせる。直接的な影響を受けるのは、ストレージ拡張やハードウェア刷新を準備しているチームである。機器を発注する前に、保持中のファイルが依然として現行の性能を必要としているかどうかという、もう一つの判断を正当化する必要がある。

根底にあるアプローチには前例がある。SpectraはすでにStorCycleを通じた非アクティブデータ移行を提供しており、Kompriseもアクセス頻度の低いファイルを別のストレージ先へ移すことを訴求している。したがって中心的な競争軸は、既存のプライマリ容量を再利用するか、それとも拡張するかである。Storage Reclaimは前者をアセスメントとして提供するが、購入者には、アーカイブ済みデータが自社の要件内で引き続き利用可能であることを示す証拠が必要となる。

Spectra Logicによる十分に活用されていないストレージの再利用はアセスメントから始まる

Storage Reclaimは、追加インフラを指定する前に既存データを調査するようチームに求め、容量判断の出発点を変える。

SpectraはStorage Reclaimの発表で、分析、ポリシー選定、移動、容量回復を中心に構成された提供可能なソリューションを説明している。同社は、容量、刷新、予算に関する判断を控えたインフラチーム向けに位置付けている。その前提は明快だ。プライマリストレージを占有しているデータの一部は、もはやプライマリストレージの性能を必要としない。

プライマリストレージとは、稼働中のアプリケーションや頻繁にアクセスされるデータを提供するシステムを指す。非アクティブデータにも保持価値はあるが、利用頻度は低い。適切なデータを別の場所へ移すことで現行ワークロードのための空き容量を生み出せるが、そのためには元のストレージが実際にその容量を解放しなければならない。

この最後の条件は重要である。アーカイブコピーはデータを保護または保持するが、コピーするだけでは元データの占有は残る。再利用には、組織が求めるアクセス性と保護を維持しつつ、最終的に対象となる元データを削除する承認済みプロセスが必要だ。

Spectraによれば、初期分析は読み取り専用であり、元データを変更せずに環境を調査する。これにより、検出と移行が分離される。チームは、ファイル移動に伴う運用上の影響を受け入れる前に、その機会を評価できる。

アセスメントが生み出すのは候補であり、自動的な事業承認ではない。ファイルの経過年数やアクセスパターンは調査すべきデータの特定に役立つが、移動可能かどうかはアプリケーション所有者が判断しなければならない。めったに開かれない研究データセットも、予定されたプロジェクトには不可欠であり得る。

同じ区別は保持にも当てはまる。将来の参照のためにデータを保持することは、必ずしも最速の利用可能なシステム上に保持することを意味しない。しかし、保持要件だけでは、状況が変化した際にどれほど迅速にデータを取得しなければならないかは分からない。

したがってStorage Reclaimは、配置判断を購買プロセスに持ち込む。問われるのは、どのデータが現行ストレージの性能に値し、どのデータが異なる取得モデルを許容できるかである。この判断には、インフラチームとファイルに依存する人々との協力が必要となる。

この発表は、顧客向けの普遍的な再利用率を示していない。また、アセスメントによってハードウェア購入をどれだけ先送りできるかも確定しない。これらの結果は、対象データ、移行の完了、ワークロードの増加、組織が必要とする容量の余力に左右される。

購入者にとって有用な成果物は、こうした条件を踏まえても成立する、環境固有の見積もりである。大量の非アクティブデータは、あくまで出発点となる発見にすぎない。根拠のある拡張判断には、チームが適切に移行・管理できる、より小さな承認済みデータセットが必要だ。

拡張予算はデータ配置に左右されるようになった

圧力を受けるのは、アクティブなワークロードの増加と蓄積された保持データを区別せずに追加容量を計画しているチームである。

ストレージを追加購入すれば、既存システムが埋まりつつあるという当面の制約に対処できる。再利用では、なぜ埋まっているのか、また保持されるすべてのファイルがそこに置かれるべきなのかを問う。両方のアプローチは併用できるが、必要となるハードウェア量と実装スケジュールは異なる。

Spectraは、容量供給の制約とストレージコストの上昇を、この時点で容量回復を強調する理由としている。購入者は、自社環境内でより限定的な提案を検証するために、広範な市場予測を受け入れる必要はない。

今後の拡張要求は、その機会を提供する。承認済みのアーカイブ候補が意味のある容量を占めていれば、移行は購入時期や規模を変えられる。システムが主としてアクティブデータを保持している場合でも、同じアセスメントは拡張の根拠を強められる。

どちらの結果も、分析の失敗を意味しない。目的は、前提を配置判断へ置き換えることだ。アーカイブ製品が存在するというだけで、必要な性能や容量への投資を先送りすべきではない。

財務比較にも一貫した範囲設定が必要となる。プライマリストレージの拡張には一連の責務が発生し、アーカイブインフラやデータ管理プロセスの追加には別の責務が生じる。再利用は、支出をなくすのではなく移し替える可能性がある。

信頼できる評価には、移行作業、アーカイブ運用、取得要件、継続的な保守の責任範囲を含めるべきだ。これらの考慮事項は、先送りされるハードウェア購入と並べて扱う必要がある。そうでなければ、ストレージ支出の削減に見えたものが、別のチームの追加業務になり得る。

容量計画にはタイミングの問題もある。運用上の上限に近づくストレージシステムは、分析、承認、移動、検証をいつまでも待つことはできない。有望なアーカイブ機会であっても、残り容量に適したスケジュールが必要だ。

そのため、容量逼迫が緊急事態になる前にアセスメントを行う方が有用である。チームには、分類に異議を唱え、取得を検証する十分な時間が必要となる。切迫した状況では、十分に精査していない広範なポリシーへと進みかねない。

運用上の圧力はインフラ管理者だけに及ばない。研究責任者、分析チーム、アプリケーション所有者は、どのデータをプライマリストレージから移せるかを特定しなければならない。財務チームは、予測上の節約と、実際に回避または縮小された購入を区別する必要がある。

人工知能ワークロードを支える組織にとって、この問題はそれを支えるデータ資産に関わる。非アクティブなデータをアーカイブすれば、アクティブなデータセットのための余地を生み出せる。それ自体が、より高速なモデル学習や優れたアプリケーション性能を証明するわけではない。

この区別により、主張を測定可能に保てる。効果は、利用可能な容量、修正された購買判断、または文書化された運用改善として表れるべきである。AI需要への一般的な言及は、そうした結果の代わりにはならない。

Spectra Logicによる十分に活用されていないストレージの再利用が最も重要になるのは、データ配置が容量調達ほど精査されてこなかった領域だ。この発表は、インフラチームにその不均衡を見直す理由を与える。予算を変えるかどうかは、承認済みの移行機会にかかっている。

既存のデータ移動ツールがアーカイブ経路を実用的にする

Storage Reclaimは、容量回復を中心に確立済みのコンポーネントを組み合わせており、その価値は新たなストレージ原理ではなく、統合と実行にかかっている。

Blocks & Filesが説明した非アクティブデータのアセスメントでは、StorCycleを使用して、経過年数やサイズを含むファイルメタデータを調査する。メタデータとは、内容そのものではなくファイルを説明する情報である。Spectraは同誌に対し、互換性は選択するデータ移動ツールに依存すると述べた。

データ移動ツールとは、ストレージシステム間で情報を転送し、それに伴うワークフローを管理するソフトウェアである。Spectraは、この製品で利用可能な経路としてStorCycle、Komprise、Starfish Storage、rcloneを挙げている。これらを含めることで顧客に選択肢を与えるが、すべての構成が同等になるわけではない。

実務的な評価は、ソース環境から始まる。ファイル共有とオブジェクトストアでは、データの整理・公開方法が異なる。オブジェクトストレージは、個別にアドレス指定されるオブジェクトとしてデータを保持し、ファイルストレージはディレクトリとファイルを提示する。

購入者は、どの組み合わせが自社の実際のソース、保存先、権限、取得プロセスを支えるのかを確認する必要がある。サポート対象の製品名は、初期段階の互換性シグナルにすぎない。完全なワークフローを検証する代わりにはならない。

この発表をどこまで広く説明できるかは、その経緯によっても制限される。SpectraのStorCycleライフサイクルソフトウェアはすでに、プライマリストレージをスキャンし、非アクティブなファイルを別のストレージ先へ移行していた。容量回復という前提は、Storage Reclaimより前から存在する。

この連続性は、ニュースをより限定的に読むことを裏付ける。Spectraは、既存のライフサイクル管理機能を、現在の購買課題を中心に整理している。顧客は、このパッケージがアセスメント、統合、実装、サポートを通じて何を追加するのかを評価すべきだ。

Kompriseは、高価なプライマリストレージから離れるポリシーベースの移動も訴求しているため、有用な比較対象となる。ポリシーベースの移動とは、設定済みのルールに従ってソフトウェアがデータを選択することを意味する。同社のインテリジェントデータ階層化アプローチは、ファイルを別の保存先へ移しながらアクセスを維持することを強調している。

階層化とは、アクセス頻度や性能などの要件に応じて、ストレージクラス全体にデータを配置することである。Kompriseの説明では、クラウドオブジェクトストレージと低コストのネットワークストレージが強調されている。SpectraのStorage Reclaim提案は、保護されたテープ保持を中心としている。

これらの説明は、パートナー企業間の単純な競争ではなく、代替となる保存先戦略を示している。KompriseもSpectraのエコシステムに参加している。意味のある比較は、各提案構成が組織の保持データをどのように扱うかである。

クラウドの保存先とテープを基盤とする保存先は、アクセスの挙動、運用上の所有責任、インフラ要件が異なり得る。購入者は、同じデータセットに対して完全なワークフローを比較すべきだ。透過的なアクセスに関する広範な主張だけでは、こうした違いは決着しない。

データ移動ツールの選択は、誰がソリューションを運用するかにも影響する。別の管理プラットフォームを追加すれば、追加の専門知識が必要になることがある。既存プラットフォームの再利用は変更を減らせるが、その設定済みの挙動が新たなアーカイブ要件を満たす場合に限られる。

拡張判断にとって、統合の品質は直接的な影響をもたらす。転送の失敗、未解決の権限問題、不明確なリコール手順は、チームが元データの削除を承認できない原因になり得る。その承認がなければ、見込まれた容量は占有されたままとなる。

したがって、Storage Reclaimのパートナー・アプローチは、ワークフロー全体のレベルで評価する必要がある。重要な成果とは、一次容量を利用可能にする、完了かつ検証済みのデータ移動である。互換性のあるコンポーネントを列挙することは構成要素を示すが、導入によって結果が確立される。

移行後も可視のアーカイブデータには、なお取り出しに関する契約がある

移行後もファイルを発見できることは、アプリケーションが求められた期限内にそれを取り出せることを意味しない。

Spectraによれば、移動されたデータは同社のアーカイブ・アーキテクチャを通じて可視性、アクセス性、呼び戻し可能性を維持する。リコールとは、アーカイブ済みコンテンツを再び利用可能なアクセス経路へ戻すことを指す。どの用語も有用な機能を表すが、購入者はそれを具体的なアプリケーション動作へと読み替える必要がある。

可視性は、ユーザーが保持データを見つけられるかという問いに答える。アクセス性は、認可された要求がそのデータに到達できるかを示す。取得性能は、要求にどの程度の時間とリソースが必要かを示す。

これらの問いは、一次ストレージへの直接アクセスを置き換える際に特に重要となる。古いプロジェクトを時折開くユーザーと、多数のアーカイブ済みファイルを読み取る自動プロセスでは、要件が異なる。同じ配置ポリシーでも、一方のワークロードには適していても、もう一方には支障となり得る。

Spectraによるtape-aware gatewayの説明は、長いレイテンシを伴うストレージを明示的に対象とし、オブジェクトをバッチ処理するジョブベースのアプローチを採用している。レイテンシとは、要求が応答または利用可能なデータを生むまでの遅延を意味する。テープを考慮したバッチ処理は、記憶媒体の特性に合わせて転送を編成する。

このアーキテクチャは重要な区別を支える。使い慣れたオブジェクト・インターフェースは統合を容易にし得るが、インターフェースだけで取得速度は決まらない。ソフトウェア互換性とアプリケーションへの適合性は、別々に評価する必要がある。

したがって、分析では実際のアクセス・パターンを検証すべきである。購入者は、アーカイブ済みデータが通常の利用に戻った際に何が起こるのかを理解する必要がある。単独の取得に成功しても、競合する要求が発生した場合のシステム動作までは証明されない。

ここでは分類ミスも高コストになり得る。プロジェクトが再開すれば、古いデータセットが再びアクティブになる場合がある。ポリシーが過去の非活動状態を恒久的なものとして扱うと、組織は間もなく一次ストレージの性能を必要とするデータを移動してしまう可能性がある。

適切な対応は、明確な責任所在を伴う、元に戻せる配置プロセスである。チームは、誰が移動を承認し、取得を要求し、分類を変更できるのかを把握する必要がある。こうした責任は、当初の経過年数のしきい値と同じくらい重要である。

保護には別の要件も加わる。Spectraは、オンライン・アクセスから隔離されたメディアを意味するエアギャップ・テープを、保持に関する提案の一部として訴求している。購入者は、提案された構成で隔離がどのように機能するのか、またその後にどのように復旧するのかを確認すべきである。

一次コピーを移動すると、アーカイブの重要性も変わる。元のコピーが削除されれば、保持データには明示的に承認された保護体制が必要となる。「アーカイブ」という言葉だけでは、バックアップ範囲や復旧準備状況は独立して保証されない。

Spectraの研究向けバックアップ導入事例は、ユタ大学のCenter for High Performance Computingにおける具体例を示している。ベンダーの事例研究によれば、同機関は30ペタバイトを超える研究データを確実に保護する必要があった。

説明された環境には、Spectra Cube、BlackPearl、rcloneが含まれる。これは、大規模な研究データ保護要件を支える関連性の高い組み合わせを示している。ただし、この事例は新たなローンチによる測定済みのStorage Reclaim成果ではなく、バックアップとアーカイブ戦略に関するものである。

この区別により、参照導入事例に裏付け以上の証拠力を持たせることを防げる。研究データの保護は一つの成果を示す。一次容量の解放と拡張の先送りは、別の成果である。

ナレッジワーカーにとって比較可能な課題は、保存場所が変わった後に保持された資料を見つけることである。検索可能なナレッジベースは、別の方向から発見性に対応する。発見性と物理的な取得は別の要件であり、どちらも他方を保証しない。

Spectra Logicによる利用率の低いストレージの再利用は、最終的にこの分離を適切に扱えるかどうかにかかっている。購入者には、対象となるコンテンツが、それに依存する業務を損なうことなく一次ストレージを離れられるという証拠が必要である。

顧客成果は、移行を購買判断へ結び付けなければならない

最も強力な証拠は、承認済みのデータ移動、解放された一次容量、そして拡張計画における文書化された変更を結び付けるものである。

評価によって潜在的な機会を明らかにすることはできる。移行レポートによってデータが移動したことは示せる。しかし、どちらも単独では、組織が購入を先送りした、あるいは運用上の立場を改善したことを証明しない。

最初に欠けやすい結び付きは、利用可能な容量である。チームは、アーカイブへコピーされたデータと、アクティブな業務のために解放された元の容量を区別すべきである。この区別は基本的に聞こえるが、保護活動と、明示された再利用成果を分ける。

次の結び付きは需要である。回復した空き容量が計画期間をどれだけ延長するかは、アクティブなワークロードが容量を消費する速度との関係で決まる。大規模な移行であっても、新しいデータが移動済みデータをすぐに置き換えるなら、その効果は限定的となり得る。

購買判断が最後の結び付きをもたらす。注文内容の見直し、更新の延期、または拡張規模の縮小は、再利用がインフラ計画を変えた証拠となる。このつながりがなければ、主張される節約は予測にとどまる。

これは、すべての顧客がストレージ購入を避けなければならないことを意味しない。容量を再利用しても、なお拡張が必要な組織もある。その場合でも、評価によってより明確で適正規模の購入に至るなら、その成果は有用であり得る。

顧客向け報告では、各成果の境界も明らかにすべきである。あるプロジェクト・アーカイブの成功は、すべての部門への適合性を証明しない。低頻度の取得を前提に構築されたワークフローを、レイテンシに敏感なアクセスの証拠として扱うべきではない。

導入の労力も、こうした成果に含めるべきである。組織は、所有者の特定、データセットの承認、移動の設定、アクセスの検証にどれほどの作業が必要だったかを理解する必要がある。これらの作業は、初期プロジェクトを超えてプロセスを継続できるかどうかを左右する。

運用責任についても同様である。最初の移行が完了した後も、アーカイブは本番環境の一部であり続ける。誰かが障害、アクセス変更、保持判断、データを一次ストレージへ戻す要求を管理しなければならない。

評価主導の提供形態は、これらの責任を早期に明らかにする助けとなり得る。また、組織が保持データについて十分な情報を持っていないことも明らかにできる。この発見は、移行判断を遅らせる場合でも有用である。

したがって、懐疑的な立場は、テープや階層化を否定することよりも狭い。未解決の問いは、顧客の対象データ、取得要件、運用リソースが、約束された容量上の利益を支えられるかどうかである。Spectraの一般的な提案だけでは、すべての環境についてこの問いに答えられない。

同様に、購入者は、拡張にはハードウェア以外の運用コストがないと考えるべきではない。追加容量にも管理と保護が必要である。比較では、両方の選択肢を同じ証拠基準で評価すべきである。

このローンチは、購買規律を変える提案として評価するのが最も適切である。インフラを追加する前に、既存の利用状況を検証するよう購入者に促している。顧客成果は、この規律が小規模なアーカイブ・プロジェクトではなく、意味のある再利用にどの程度つながるかを示すことになる。

回復した容量、取得結果、拡張時期を注視する

次に必要な証拠は、Storage Reclaimが、保持データに付随するアクセス要件を満たしながら容量計画を変えるかどうかを示すものである。

まず、評価済み候補と完了した再利用を区別する顧客成果に注目すべきである。重要な進展は、特定されたデータから承認済みの移動、そして利用可能な一次容量へと続く。この進展を報告すれば、Spectraの主張は強化される。

アーカイブ容量だけを説明する成果では、中心的な問いに答えられない。組織は、同等の元容量を解放することなく、大量のデータを二次ストレージへ書き込むことができる。証拠は、製品が掲げる購買目的と一致する必要がある。

次に、対応するデータ移動経路全体における取得検証に注目すべきである。購入者には、代表的なファイル、アプリケーション要求、競合する取得について、公開または直接実証された動作が必要である。すべてのエコシステム選択肢が同一に動作するかのように示唆するのではなく、結果では構成を特定すべきである。

移行済みデータが合意された要件の範囲内で引き続き利用可能であるという証拠は、再利用の論拠を強める。一方、大量のデータを一次ストレージに残す必要がある例外が繰り返されれば、対象となる機会は限定される。どちらの発見も、購入者が導入規模を現実的に見積もる助けとなる。

第三に、完了したプロジェクトが拡張の時期や範囲を変えるかどうかに注目すべきである。文書化された購買変更は、技術的な運用を事業判断へ結び付ける。拡張を継続する場合は、成長、残るアクティブ・データ、プロジェクト本来の目標についての文脈が必要となる。

これらのシグナルは、約束の異なる側面を検証するため、今後数カ月にわたり注目に値する。容量結果は再利用を、取得結果は実用性を、購買変更は経済的目的を検証する。単一の実証ですべてを確立することはできない。

Spectra Logicによる利用率の低いストレージの再利用は、インフラチームに対し、次回の更新前に容量に関する前提を見直す具体的な理由を与える。この発表は、利用可能な提供形態と統合アプローチを示している。顧客固有の判断は、依然として承認済みのデータセット、検証済みのアクセス、信頼できる導入スケジュールに依存する。

拡張を承認する前に、インフラおよびアプリケーションの所有者に対し、追加容量の計画を測定済みの再利用オプションと比較するよう求めるべきである。両方の提案について、運用責任、保護要件、ユーザーが期待するアクセス期限を特定するよう求める。そして、予測される節約を、実際に変更される購買内容へ結び付ける。Spectra Logicによる利用率の低いストレージの再利用において決定的な問いは実務的である。どの保持データが一次ストレージを離れ、要求時にも有用性を維持し、次のインフラ判断を変えるのに十分な余地を生み出せるのか。答えを検証する時間がまだあるうちに、このレビューを始めるべきである。

 
 

無料で始めましょう

ローカルファーストのパーソナル知識管理付きAIアシスタント

より良いAI体験のために、

remio は現在、 Windows 10+ (x64)とM-Chip Mac のみをサポートしています。

仕事のAIパートナー
remioでもっと仕事が進む

計画・作成・仕上げまで
すべてをひとつに

bottom of page