ファイル管理も新たな時代へ
次世代のファイルシステム4種、それぞれの特徴は?
コンピューティングやデータセンターの変化に伴い、ファイルシステムも進化しなければならない。本稿では、ファイルシステムの現状と今後の方向性について考える。
少し前まで、ファイル管理は単純だった。WindowsであればNTFS、Linuxであればext4を利用していただろう。だが、ファイルシステムが進化を遂げた今、状況は大きく変わりつつある。ファイルシステムではマルチボリュームが一般的になった。さらに並列ファイルシステムと分散ファイルシステムの登場により、ローカルファイルストレージからクラウドへの拡張が簡単にできるようになった。
本稿では、ストレージ業界で近年話題のマルチボリュームファイルシステム、分散ファイルシステム、ハイブリッドクラウドストレージの3種類のファイルシステムについて取り上げる。さらに「分散型クラウドオブジェクトストレージ」という新たな考え方にも目を向けてみよう。
併せて読みたいお薦め記事
データストレージのトレンドを知る
クラウド化に向けて何をすべきか?
次世代ローカルファイルシステム
Linuxのファイルシステムの改良については約10年にわたり議論が交わされている。具体的には、Oracleの「Zettabyte File System」(ZFS)の基準を満たすファイルシステムが求められ続けている。必要な機能としては、コピーオンライト、簡単なサイズ変更、データの整合性向上などがある。
OracleがLinuxで使用するために設計したファイルシステム「B-tree File System」(Btrfs)は、こうした機能を備えているかのように思われた。Btrfsの開発は2007年に始まり、2014年以降は安定したと考えられてきた。だが、Linux市場において最も重要な立場を担うRed HatがBtrfsのメンテナンスを継続しないことを決定したため、Btrfsの将来性は不透明になった。ただし、近年はデータセンターのワークロードとパブリッククラウドやプライベートクラウドを密接に統合する機会も多々あることから、次世代ローカルファイルシステムはもはや最重要開発案件ではない。
分散ファイルシステム
ローカルファイルシステムの主な問題点は「ローカル」、つまり局所的なところだ。一方、ローカル分散環境でのコンピューティングも増えている。分散ファイルシステムはその名の通りデータを分散させて格納するシステムだ。NFSなどのクライアントサーバモデルの分散ファイルシステムは数十年前から存在するが、最近ではクラウド環境でも分散ファイルシステムを利用できるようになっている。
クラウド環境での分散ファイルシステムは、ファイルを複数のチャンクに分割できるところに価値がある。こうしたチャンクは複数のサーバに複製可能だ。これにより冗長性を保ちながら、任意のクライアントに対してそのファイルへのアクセスを簡単に提供できるようになる。このチャンクを複数のサーバに分散させることで、ファイルの異なる部分に並列アクセスすることも可能になる。これにより、マルチクライアント環境でのロックの問題が解消される。
他の分散ファイルシステムとしては、Red Hatの「Ceph」や「Swift」などのオブジェクトストレージ型も含まれている。Googleや「Apache Hadoop」のファイルシステムなど、クラウドベースのストレージもある。分散ファイルシステムでは、ノード数が数百にも及ぶ可能性がある。そのため、ハードウェア障害によるファイルシステムへの影響は少なくなる。
ハイブリッドクラウドストレージ
多くのデータセンターがクラウドと密接に連携するのに伴い、プライベートクラウドやパブリッククラウドとローカルストレージを統合することも増えている。Dell、IBM、NetAppなど従来のストレージベンダーだけでなく、Amazon Web Services(AWS)の「AWS」、Microsoftの「Microsoft Azure」などパブリッククラウドベンダーもハイブリッドクラウドストレージを提供している。ハイブリッドストレージ市場は、依然クラウドベンダーとストレージベンダーが席巻している。
企業がファイルシステムを検討する際にハイブリッドストレージを候補とする理由はたくさんあるが、主な理由の一つはスケーラビリティがある点だ。つまりストレージの拡張に大きな投資をする必要はない。さまざまなファイルシステムの中でも、実際に必要な場合にのみ課金される従量課金制であるという点でクラウドストレージは抜きん出ている。必要なくなれば、ユーザーはローカルストレージに戻ることができる。
ローカルストレージをクラウドストレージに接続するには、データを移動するプロトコルが必要になる。一般的なのはiSCSI、「Amazon Simple Storage Service」(Amazon S3)のAPI、NFSなどのNASプロトコル、ローカルデータとパブリッククラウドの間の接続を行うゲートウェイなどがある。
分散型クラウドオブジェクトストレージ
クラウドサーバはストレージ容量が過剰な場合もあるが、分散型クラウドオブジェクトストレージはこの問題を解決している。分散型クラウドオブジェクトストレージでは、インターネットにある複数の匿名デバイスにデータを分散させるためにクライアントサイドの暗号化が用いられている。
暗号化された小さなデータチャンクはクライアントPCに格納される。しかしPCの所有者はそのデータに対して何もできないため、データの機密性は守られる。「Storj」はそうした分散型クラウドオブジェクトストレージの一つで、2019年初めに公開される予定だ。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
事例
[フォーティネットジャパン合同会社] 複雑化しがちな「SASE運用」 IT・医療・金融などの事例に見る導入成功の秘訣 -
製品資料
[フォーティネットジャパン合同会社] 「SD-WAN」導入で失敗しないための5つの重要事項 -
技術文書・技術解説
[フォーティネットジャパン合同会社] VPNの代替候補「ZTNA」を理解できるようになる“3大要素”とは? -
事例
[フォーティネットジャパン合同会社] すぐ分かる「SD-WAN」選定のポイント 成功企業はどんな成果を出した? -
製品資料
[SCSK株式会社] 「Dropbox」管理・運用の困りごと解決ガイド
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
半数がブルーカラー転向を視野に? ベテランエンジニアを追い込む“54歳の壁”
-
2
PHP脆弱性「PHP2Shell」で2260万件に影響 情シスの緊急チェックリスト
-
3
みずほ証券が「液冷サーバ」を採用 1日3.6億件の計算を支えるための要件
-
4
「Microsoft 365」が乗っ取られる MFAを破る“本物の画面”の恐怖
-
5
「Windows」の不要なファイルを安全に消して容量を空ける方法
-
6
Microsoft月例パッチ1400件超で過去最多 「限界点」を迎えたパッチ管理
-
7
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
8
RAGで「データをAIに送る」運用が限界を迎えている理由
-
9
SAP導入後も残る“Excel依存” 京急電鉄は「kintone」でどう解消した?
-
10
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
ホワイトペーパーランキング PR
-
1
AI駆動攻撃にどう対抗する? 超速の攻撃からエンドポイントを保護する方法
-
2
2026年のサイバーセキュリティには何が必要か? 最新データに学ぶ傾向と対策
-
3
経験豊富な即戦力人材に直接アプローチできる、「攻めの採用」への転換術
-
4
「IT史に名を残すシステム障害」8選
-
5
最速72分でデータが流出? 最新の脅威トレンドや侵入手法から分かった防衛策
-
6
AI駆動開発のスピードと安全性を両立 「品質・セキュリティ管理」の実践ガイド
-
7
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
8
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
-
9
「標的型攻撃メール」事例・サンプル集
-
10
Microsoft 365のメールセキュリティ、3つの“死角”と追加で検討すべき対策とは
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー