ドライブの仕組み

呼び出し一覧

ドライブのオブジェクトは、id（vol-…。内部的には、ドライブはボリュームです）、name、size_bytes、used_bytes（書き込まれた量。課金の基準）、attached_to（読み書き可能で持っているサンドボックスとパス。最大 1 つ）、region（現在ある場所）、home と home_move（リージョンをまたぐ場合）、durability、status、lease（サンドボックスが持っている間：書き込むマシンと、その期限）、app_id と key（キー別インスタンスのドライブ）、parent_drive_id と root_drive_id（フォークの場合：フォーク元のドライブと、系統の最初のドライブ。それ以外のドライブでは null）、created_at を持ちます。

マウント

• サンドボックスに：作成時に --drive data:/data、実行中なら glac drives attach data web:/data。1 つのサンドボックスがマウントできるのは、ドライブとボリュームを合わせて最大 8 個です（409 too_many_drives。ボリュームだけを求めた場合は too_many_volumes）。
• キューブに：バージョンの --drive data:/var/lib/data（API では drives）は、サービスの唯一のインスタンスがマウントします。ドライブを持つサービスのインスタンスは 1 つで、複数のインスタンスやキーは拒否されます（409 drive_single_writer）。インスタンスはアプリの最初のリージョンに作られ、それはドライブのリージョンでなければなりません（--region）。データを保持するサービスを参照してください。
• キーごとに 1 つ：キーを使うアプリのバージョンは、キーごとのインスタンスに専用のドライブを持たせられます（--key-drive home:/home/app:10GiB、key_drives）。ドライブはキーの最初のインスタンスとともに作られ、キーとともに削除されます。キー別インスタンスを参照してください。
• スナップショットから読み取り専用で：ドライブのリージョンにあるサンドボックスなら、ドライブを誰が持っていても、いくつでも同時にそのスナップショットを読み取り専用でマウントできます（mode: "snapshot"、glac drives attach data web:/then --snapshot dsnap-…）。マウントのためにオブジェクトストアから取得するものに料金はかからず、マウントしたサンドボックスのキャッシュ外の読み取りとして表示されます。スナップショットの読み取り専用のマウントを参照してください。

中のファイルシステムは ext4 です。ファイルの削除で空いた領域は返却されます。マシンは 1 分ごとにドライブをトリムし、それに合わせて used_bytes も減ります。

書き込み元は 1 つだけ

ドライブを読み書き可能でマウントできるのは、一度に 1 つのサンドボックスだけです。スナップショットの読み取り専用のマウントはこの制限を受けません。ほかのサンドボックスが持っているドライブのアタッチは拒否され（409 drive_attached）、マウント中のドライブの削除も拒否されます。サンドボックスが持っている間は、そのサンドボックスを動かすマシンがドライブのリースを持ちます。そのマシンが応答しなくなると、リースが切れるまでは誰もドライブに書き込めません（503 node_unavailable。その期限が示されます）。その後、次のサンドボックスがオブジェクトストアからドライブを引き継ぎ、古いマシンはもう書き込めなくなります。

データベースのドライブを読み書き可能でマウントできるのはデータベースのインスタンスだけで、名前の変更、復元、削除はデータベースを通じて行います。ここでのそれらの呼び出しと、ほかの場所での読み書き可能なマウントは拒否されます（409 managed_by_database）。ドライブの managed_by（{"object": "database", "id": "db-…"}）にそう示されます。スナップショットは、ほかのドライブと同じく、プロジェクトで取得、フォーク、読み取り専用でのマウントができます。

ドライブの場所

ドライブは 1 つのリージョンで作られ、そこがホームになります。ブロックは最後にドライブを持っていたマシンの NVMe ディスク上にあり、書き込まれるそばから、ドライブがあるリージョンのオブジェクトストアにコピーされます。

• ドライブを持つマシン上のサンドボックスは、ローカルディスクとしてマウントします。
• リージョン内の別のマシン上のサンドボックスもマウントできます。ドライブがそこへ運ばれ、ブロックは読み取られるのに合わせてオブジェクトストアから取得されます。オブジェクトストアがまだドライブの現在の状態を持っていない間は、呼び出しに 503 copy_behind か drive_not_brought（どちらも retryable）が返り、少し後に同じ呼び出しをすれば成功します。
• どのサンドボックスも持たず、どのマシンも保持していないドライブはオブジェクトストアで待機し、次にマウントされるときに、リージョン内のどのマシンでも引き継げます。
• 別のマシンへ移動するサンドボックスは、ドライブを一緒に持っていきます。
• ドライブをマウントする新しいサンドボックスは、ドライブを持つマシンに空きがあればそこに、なければドライブを運べるマシンに作られます。どのマシンも引き受けられなければ、呼び出しは 503 no_capacity を返し、そのメッセージに、各ドライブの場所と、ほかのマシンが持てなかった理由が示されます。

リージョンをまたぐ場合

別のリージョンのサンドボックスも、そのリージョンのマシンがドライブのホームのオブジェクトストアを読める場合はドライブをマウントできます（読めなければ 409 not_on_one_machine）。そこでドライブとともに作る新しいサンドボックスでも、そこで動いていて後からドライブを渡されるサンドボックスでもかまいません。

• ドライブを持つマシンは、すべての書き込みを含むバージョンとしてドライブを手放し、別のリージョンのマシンがそこから引き継ぎます。ドライブはすぐにマウントされ、ブロックはゲストが読むのに合わせてホームのストアから読み取られます（リージョンをまたぐキャッシュ外の読み取りで、2 つのリージョン間の回線の速度です）。
• ゲストが書き込むものは、現在いるリージョンのオブジェクトストアに送られます。region はそのリージョンになり、home は元のリージョンのままです。
• ホームは、そこに 1 時間いると追従します。POST /v1/drives/{id}/home（glac drives home data）を使えばすぐに移ります。マシンは、ホームのストアに残っているものをバックグラウンドでそのまま自分のストアにコピーし、何も残らなくなった時点で home が新しいリージョンになります。home_move が移動の進み具合を示します（asked_at、asked_by（user または away）、copied_objects、copied_bytes、objects_left、止まった場合の error。移動は自動で続きます）。
• ホームが移る前に再びホームのリージョンでマウントされた場合は、別のリージョンで書き込んだものが同じ方法でホームにコピーされ（asked_by は back）、ホームはそのままです。移動中、移動済みのものは、古いストアがどうなっても新しいリージョンのストアから読み取られます。
• 古いホームのコピーは、ドライブが保持するどのバージョンもそこで必要としなくなった時点で消えます（移動の 1 日後。オブジェクトストアの猶予期間）。
• ドライブのホームが移るのは、最大で 6 時間に 1 回です（409 home_moved_recently、retry_after_seconds 付き）。2 つのリージョンで交互に使われるドライブが、行ったり来たりコピーされることはありません。ホームが現在のリージョンにあるドライブでは 409 home_here、どのマシンも保持していないドライブでは 503 drive_in_store になります（マウントしてください）。

スナップショットは、取得したときにドライブがあったリージョンに残り、そこで読み取り専用でマウントされます（スナップショット）。

書き込みの耐久性

ドライブの durability は作成時に設定し、その後は変わりません。

• standard（デフォルト）：ゲストの fsync はすぐに戻り、書き込みは少し後にオブジェクトストアへ送られます。マシンが失われた場合に失われるのは、最大で最後の 1 秒分の書き込みです。
• strict：ゲストの fsync と、ファイルシステムのフラッシュはすべて、それ以前のすべての書き込みをオブジェクトストアが保持してから戻ります。そのため、マシンが失われても、ゲストが同期したものは何も失われません。fsync のたびにオブジェクトストアへのリクエストを待つので、コミットがマシンより長く残らなければならないデータベースに使ってください。strict のドライブは、ディスクをオブジェクトストアにコピーするマシンでしか保持されず、strict のドライブの導入以降にビルドされたテンプレートから作られたサンドボックスでしかマウントできません。それ以外は拒否されます（409 strict_unsupported）。

glac drives create --name pgdata --size-bytes 20GiB --durability strict

課金対象

• データ：used_bytes、つまり書き込まれてトリムされていないバイト数で、すべて階層型ストレージに保存され、1 時間ごとに 1 GB-月あたり $0.02 で課金されます。ドライブのサイズではありません。これはスリープ中のサンドボックスやスナップショットと同じデータの計測項目で、無料プランの 15 GB と有料プランの 20 GB-月 はこれらの合計に対するものです。
• NVMe キャッシュ（請求書ではボリュームキャッシュ）：ドライブのうちマシンの NVMe に置く部分で、ドライブごとにゼロから全量まで設定でき、指定しなければ全量です。サーバーレス Postgres のデータベースは、ドライブの 4 分の 1（最小 1 GiB）をキャッシュします。キャッシュのサイズと保持しているデータの小さい方を 1 時間ごとに数え、1 GB-月あたり $0.06 で課金されます。すべてキャッシュすると 1 GB-月あたり $0.08 です。無料プランでは、ドライブが保持する量まで、合計 15 GB をキャッシュでき、これは 1 日のクォータではなく保持できる量です。有料プランには月 20 GB-月 が含まれます。
• 書き込みと読み取りには、キャッシュの有無にかかわらず料金はかかりません。キャッシュされていないブロックは、ネットワークの速度で読み取られます。
• スナップショット：ドライブの各スナップショットは、単独で保持する量に対して、ドライブが保持するものと同じ料金、同じストレージの計測項目で課金されます。スナップショットのページの課金対象を参照してください。

GET /v1/usage?group_by=drive（または drive_id=、kind=drive）はドライブごとの量を報告し、glac usage --drive data も同じです。利用上限額、残高不足、未払いは、サンドボックスと同じくドライブも制限します。未払い状態のアカウントは、ドライブとそのスナップショットの一覧表示、読み取り、削除はできますが、ドライブの作成、マウント、名前の変更、スナップショットの取得、フォーク、復元はできません（402 account_in_debt）。料金とプランを参照してください。

プロジェクトが保持できる量

これを超えると、新しいドライブは拒否されます（403 drive_limit_reached。数値が示されます）。有料プランでは、個数はソフトリミットで、ご要望に応じて引き上げます。エンタープライズアカウントでは、最大 16 TiB のドライブを使えるようにできます。キー別インスタンスのドライブは、個数ではなくバイト数で数えます。フォークは、そのサイズの新しいドライブとして数えます。スナップショットは数えないため、ドライブはいくつでも持てます。

イベント

drive.created、drive.deleted、drive.attached、drive.detached（reason は sandbox_deleted、drive_deleted、または呼び出しによる場合はなし）は、プロジェクトのイベントと Webhook で届きます。drive.snapshot.created と drive.snapshot.deleted も同じです。スナップショットの読み取り専用のマウントでは、drive.attached も drive.detached も送られません。

未対応の機能

• 取得したリージョンとは別のリージョンでの、スナップショットの読み取り専用のマウント（409 not_on_one_machine）。
• どのマシンも保持していないドライブの名前の変更（503 drive_in_store。マウントしてから名前を変更してください）。
• キューブのバージョンでの読み取り専用のマウント。バージョンはドライブを読み書き可能でマウントし、そこでの mode: "snapshot" は拒否されます（400 invalid_field）。読み取り専用のマウントはサンドボックス用です。
• スナップショット、フォーク、読み取り専用のマウントで未対応のものは、それらのページにあります。