データセット、ディレクトリパス、URLの構造について
データセット、ディレクトリパス、URLの構造について
- データセット、ディレクトリパス、URLの構造について
- ZFSのデータセットとは
- InfiniCLOUDにおけるデータセット構造について
- 各データセットの役割
- アプリケーション固有のデータセットに関して
- (参考資料)データセットに対してURLアクセスできるメカニズム
ZFSのデータセットとは
InfiniCLOUDのファイルシステムとして利用しているZFSのデータセットは、ディレクトリのような入れ子構造をもつ。
データセット毎に異なるプロパティを持つことができるため、容量などの値の取得、スナップショットの作成、参照、また将来においてロールバック、差分、クォータ、圧縮管理、暗号化など、様々な機能のコントロール単位となる。
また、プロパティは親子で継承されるため、基本的に、設定は親のものを継承するし、利用容量などは子を含んだものを表す。
これらは、パスのような書式で管理されており、
DATASET名 / /backup /backup/data.ZsXw /backup/data.WtPO /files
次の様に、実際には次の様にディレクトリ・パスにマウントされている。
DATASET名 | MOUNTPOINT |
---|---|
/ | ./ |
/backup | ./backup |
/backup/data.ZsXw | ./backup/data.ZsXw |
/backup/data.WtPO | ./backup/data.WtPO |
/files | ./files |
マウントポイントは、パスへの配置を意味する。
上記のようなデータセット構造で、./backup/fooというディレクトリがあった場合、これはあくまでばbackupデータセットに設置された単なるfooというディレクトリであり、/backup/fooというデータセットがあるわけでは無い。データセットの作成はディレクトリの作成よりは高コストなので、ディレクトリ毎にデータセットを作るものではない。
ディレクトリではなく、データセットを作成する場合は、あくまでデータセットリソースを固有で管理したいとき、例えばスナップショットを固有で取りたい、それを参照したい、将来においては、ロールバックをしたい、差分を取りたいなど、何か管理区分を変えたいときに利用するものとなる。
また、上記に置いてデータセットとは、次のものを総称した名称である。
- ファイルシステム
- スナップショット
したがって、上記に置いてのデータセットとは、データセットのファイルシステムということとなる。
ファイルシステムとは
ZFSにおけるファイルシステムとは、ディレクトリ・パスにマウントできるデータセットのことを意味する。
スナップショットとは
スナップショットとは、データセット-ファイルシステムのイメージを、ある時点で「そのまま」固めて持つことができる機能である。これは「ほとんど一瞬」で取得することができる。スナップショット作成後にデータを書いても、ファイルシステムには差分しかデータは記録されずにすむ。そのため、極めてコストの低い方法で現在の状態を保持できるものとなる。
スナップショットはデータセットのファイルシステムに対して取得ができる。データセット単位で行う必要があるが、リカーシブの設定をすれば、下位のデータセット-ファイルシステムまで含め、同時刻で取得することも可能だ。なお、スナップショットのスナップショットは取得することができない。
参照は、それぞれのデータセットの直下にある/.zfs/snapshot以下に、スナップショット名と同名の参照専用ディレクトリがある。スナップショットは、そのデータセット自身にあるファイルのみが参照できるので、上記の例では/filesのスナップショットのファイルは/files/.zfs/snapshot以下にだけある。仮に/files/fooというデータセットを作った場合は、./foo以下ディレクトリに置いたファイルのスナップショットは、/files/foo/.zfs/snapshot以下に設置され、/files/.zfs/snapshot/<スナップショット名>/foo以下には存在しない。
スナップショットはあくまでその時点の状態を保持するものであり、バックアップではない。しかし、ロジカルな操作ミスからの復元にはとても役に立つ。
なお、InfiniCLOUDにおいてはスナップショットはユーザ毎に100個までしか取得することはできない。
またスナップショットの作成はほとんど一瞬で作成できるものの、削除、特に占有しているデータ領域の開放には時間がかかる。
ロールバックとは
ファイルシステムを、スナップショットの時点に巻き戻す機能である。スナップショット以後に書かれたものを全て捨て、ファイルシステムを元の状態に戻す機能である。
ロールバックをした場合、経過のスナップショットは全て失われるため、ロールバックの取り消しをすることは原理的にできない。
現在のInfiniCLOUDは未サポートであり、将来サポートされる予定となっている。
クローンとは
クローンはスナップショットを元に、新しいファイルシステムを作る機能である。
スナップショット以後からの差分しかデータを保持しないため、同じようなデータの入ったものであれば、容量の圧迫を防ぐことができる。
現在のInfiniCLOUDは未サポートであり、将来サポートされる予定となっている。
ファイルシステムレベルの暗号化とは
ファイルシステムの単位でAES等の暗号化をする機能である。
このファイルシステムは、マウント時にパスワードか、キーを必要とする。パスワードやキーを失った場合、データは暗号化されているため、当然復元はできなくなる。
現在のInfiniCLOUDは未サポートであり、将来サポートされる予定となっている。
InfiniCLOUDにおけるデータセット構造について
InfiniCLOUDのユーザは、アカウント作成時に一つのユーザ用データセット-ファイルシステムを持ち、ディレクトリにマウントされている。そしてその下に更にデータセット-ファイルシステムを持っている。
このデータセット-ファイルシステムは、同名のマウントポイントにマウントされ、ユーザのデータが保存されている。
このうち、URL経由でアクセスできるデータセットは、マウントパスとマッピングされたものだけで、これはHTTPS(WebDAV)プロトコルを用いてアクセスする。ブラウザ経由で一般ユーザが自由にアクセス可能なのは、/dav/のみであり、/backup以下はアプリケーションが固有に使うことができる領域となる。
DATASET名 | 内部MOUNTPOINT | WebDAV URL |
---|---|---|
/ | / | なし |
/backup | /backup | /backup ※BASIC認証のWebDAVのみ。browserからは閲覧不可。以下のパスも同様。 |
/backup/JUSTPLAYER | /backup/JUSTPLAYER | /backup/JUSTPLAYER |
/backup/JUSTPLAYER/appname | /backup/JUSTPLAYER/appname | /backup/JUSTPLAYER/appname |
/backup/data.ZsXw | /backup/data.ZsXW | /backup/data.ZsXW |
/backup/data.WtPO | /backup/data.WtPO | /backup/data.WtPO |
/files | /files | /dav/ ※BASIC認証用 /v2/dav/ ※browserから閲覧可。 |
/someappdata | /someappdata | なし ※一般には作るべきではない |
/someappdata2 | /someappdata2 | なし ※一般には作るべきではない |
ユーザのルートデータセット以下は、すべてユーザの持ち物であり、ユーザの使用容量とはルートデータセットの下位(子孫)をすべて含んだ使用容量を意味する。
ただし、データセット名は本来、先頭に/をつけないため、ルートは便宜上のもので、API上ではヌルストリングとなる。
データセット長は、最大で64文字となっている。
また、ユーザのIDとパスワード(認証方法によってアカウントパスワードかアプリパスワードかが異なる)で、データセットの全てが管理でき、REST APIで好きなところに32個まで、データセットを作ることができる。
InfiniCLOUDにおいて、ファイルシステム型のデータセットは、必ずルートからのデータセット名と等しい場所にマウントされる。つまり、someappdataというデータセットを作ると、/someappataというパスにマウントされ、その下にsomeappdata/fooというデータセットを作ると、/someappdata/fooというパスにマウントされる。
しかしながら、たとえばfiles/fooというデータセットを作ろうとしたとき、すでにユーザがfooというディレクトリを作り、ファイルを設置している場合は、そのデータセットの作成はできない。
各データセットの役割
システムで予約されているデータセット名は下記の通りとなる。
DATASET名 | URL | 役割 |
---|---|---|
/ | なし | ユーザの領域のもっとも親となる。容量の合計計測はこちらから参照することとなるが、一部のユーザを除いてこの領域が直接使われる事は無い。 |
/files | /dav/ , /v2/dav/ | ユーザの一般領域。ブラウザや、一般的なWebDAVクライアントからアクセスすることができる。ただし、2015年4月以前に作られたユーザにこのデータセットはなく、直接ルートデータセットに配置されている。 files以下にデータセットを作成する事は構わないが、これ以下は一般的に、ユーザが自由にデータを保持している領域である為、ユーザが同名のディレクトリを作っていた場合、そのままでは作ることができないため、注意が必要。 /dav/はBASIC認証のクレデンシャルでアクセス可能なものであり、/v2/dav/は、OAUTH2によるクレデンシャルでアクセス可能になる。 |
/backup | /backup | アプリケーションが、ユーザが簡単に触ることができない特定の領域を用意する場合に利用する。用途は、バックアップデータ、アプリのデータ保存など。 |
それ以外のDATASET名 | なし | 現時点に置いて、無作為な名前を作ることは推奨されない。今後、要望に応じて、これらの領域に特殊アクセスする仕組みが作られる可能性はある。 |
アプリケーション固有のデータセットに関して
/dav/や/v2/dav/でアクセスできる領域は、ユーザがブラウザで簡単にアクセスできるため、ユーザが意思にかかわらず、間違って操作してしまう恐れがある。
アプリケーションによっては、そのことが致命的な問題に繋がる場合もあるため、InfiniCLOUDではユーザがブラウザなどで簡単にアクセス出来ない領域を作成する事ができるようになっている。
加えて、InfiniCLOUDの採用するファイルシステムであるZFSは、様々な管理やオペレーションをデータセット(ファイルシステム)単位で行うため、アプリケーション開発者は役割毎にデータセットを作成することによって、様々なメリットを得ることができる(ただしユーザ毎に最大10まで)。
ユーザの/backup以下の領域に、データセット(ファイルシステム)を作成する場合、下記の様なルールで作成する事ができる。
- /backup/<VendorID>/<AppName>
- VendorID、AppNameは自由につけて良いが、全体の長さで最大64文字、英数字のみ。スペースを含む記号は許されないため、VendorID、AppNameは、ある種の簡易名称であることが推奨される。
ブラウザからは参照不可能なので、ユーザがあえてそのパスを汎用のWebDAVクライアントに指定した場合には、その限りではない事に注意が必要。
例:/backup/JUSTPLAYER/tctool 等。 - /backup/data.XXXX
- ベンダ名、アプリ名を入れる必要がない、あるいは入れたくはない時に利用する。
全てのベンダ、アプリ名で同じ階層に設置するため、data.XXXXの名はユニーク(固有)でなくてはならない。作成時には、dataset apiのput datasetにて、suffixに(unique)を利用しなくてはならない。XXXXでシステムによりランダムで作られる。
なおこれらのデータセットは、ユーザ自身でブラウザ内にある「データセットエディタ」で削除することとができるため、ユーザに絶対的にアクセス不可能になるものではないことに注意。
(参考資料)データセットに対してURLアクセスできるメカニズム
InfiniCLOUDでは、データセット(ファイルシステム)名とマウントポイントは一意の関係があるが、データセットと公開されたURLには一意の関係はない。
通常、ユーザがウェブインタフェイスや、WebDAVで見ることができるエリアは、「/dav/」というパスからアクセスすることができる。
URL層 | /dav/ |
---|---|
URLパス変換ルール(固定) | /dav/ → /dav/ |
ディレクトリパス層 | /dav/ |
マッパー /dav/ → /files/ | |
/files | |
マウントパスルール(固定) | /files → files |
データセット層 | files |
「URLパス:/dav/」は、「ファイルパス:/files/」にURLマッピングされる。「ファイルパス:/files/」へ「データセット:files」がマウントされている。(※2015年4月以前に作られたユーザには、filesデータセットはなく、ルートデータセットに/files/というディレクトリが作られている)
上記のURLマッパーは、今後公開される予定のmapperAPIで切り替えられるよう考慮されているため、これができることにより、ある時点のCloneを保全して見せることが可能になるなど、応用範囲も広い。しかしながら、この機能には認証キャッシュなどとの副作用も多いため、現在は、実装、公開の検討中となっている。