storage.config¶

The storage.config file (by default, located in /usr/local/etc/trafficserver/) lists all the files, directories, and/or hard disk partitions that make up the Traffic Server cache. After you modify the storage.config file the new settings will not be effective until Traffic Server is restarted.

フォーマット¶

The format of the storage.config file is a series of lines of the form

pathname size [ volume=number ] [ id=string ]

where pathname is the name of a partition, directory or file, size is the size of the named partition, directory or file (in bytes), and volume is the volume number used in the files volume.config and hosting.config. id is used for seeding the Assignment Table. You must specify a size for directories; size is optional for files and raw partitions. volume and id are optional.

注釈

The volume option is independent of the id option and either can be used with or without the other, and their ordering on the line is irrelevant.

注釈

If the id option is used every use must have a unique value for string.

注釈

Any change to this files can (and almost always will) invalidate the existing cache in its entirety.

どんなサイズのどんなパーティションでも使用する事が出来ます。最適な性能のためには以下のようにします:

ローディスクパーティションを使用する
各ディスクで、全パーティションを同じサイズになるように作成する
各ノードで、全ディスクのパーティションを数が同じになるように作成する
似たような種類のストレージを、別ボリュームにグループ化する例えば、SSDやRAMドライブは独自のボリュームに分割する

オペレーティングシステム要求により、pathnames を指定してください。以下の例を確認してください。storage.config ファイルには、フォーマット済みもしくはローディスクを、少なくとも 128MB 指定しなければなりません。

ローディスクやローパーティションを使う場合、Traffic Server プロセスに使用される Traffic Server ユーザ が、ローディスクデバイスやローパーティションの読み書きの権限を持っているか確認するべきです。ベストプラクティスの一つは、デバイスファイルに 'g+rw' 権限が付与されることとTraffic Server ユーザがデバイスファイルの自身のグループに属していることを確認することです。しかしながら、幾つかのオペレーティングシステムではより強い要求があります。更なる情報については、以下の例を確認してください。

標準的な records.yaml の数値と同様、ヒューマンリーダブルなプレフィックスもサポートされています。これらには以下のものを含みます。

K キロバイト (1024 バイト)

M メガバイト (1024^2 または 1,048,576 バイト)

G ギガバイト (1024^3 または 1,073,741,824 バイト)

T テラバイト (1024^4 または 1,099,511,627,776 バイト)

Assignment Table¶

Each storage element defined in storage.config is divided in to stripes. The assignment table maps from an object URL to a specific stripe. The table is initialized based on a pseudo-random process which is seeded by hashing a string for each stripe. This string is composed of a base string, an offset (the start of the stripe on the storage element), and the length of the stripe. By default the path for the storage is used as the base string. This ensures that each stripe has a unique string for the assignment hash. This does make the assignment table very sensitive to the path for the storage elements and changing even one can have a cascading effect which will effectively clear most of the cache. This can be problem when drives fail and a system reboot causes the path names to change.

The id option can be used to create a fixed string that an administrator can use to keep the assignment table consistent by maintaining the mapping from physical device to base string even in the presence of hardware changes and failures.

例¶

以下に、キャッシュストレージとして /big_dir ディレクトリで、128MB 使用する例を示します。:

/big_dir 134217728

. シンボルを使用してカレントディレクトリを用いることもできます。以下に、カレントディレクトリで 64MB キャッシュストレージを構築する例を示します。:

. 134217728

代わりとして、ヒューマンリーダブルなプレフィックスを使用し、 64GB ファイルキャッシュを表現できます:

/really_big_dir 64G

注釈

When using on-filesystem cache disk storage, you can only have one such directory specified. This will be addressed in a future version.

Linux の例¶

注釈

Rather than refer to disk devices like /dev/sda, /dev/sdb, etc., modern Linux supports alternative symlinked names for disk devices in the /dev/disk directory structure. As noted for the Assignment Table the path used for the disk can effect the cache if it changes. This can be ameliorated in some cases by using one of the alternate paths in via /dev/disk. Note that if the by-id or by-path style is used, replacing a failed drive will cause that path to change because the new drive will have a different physical ID or path. The original hash string can be kept by adding id or path with the original path to the storage line.

If this is not sufficient then the id or path argument should be used to create a more permanent assignment table. An example would be:

/dev/sde id=cache.disk.0
/dev/sdg id=cache.disk.1

以下の例では、Linux オペレーティングシステムにおいてローディスクを使用します。:

/dev/disk/by-id/[DiskA_ID]    volume=1
/dev/disk/by-path/[DiskB_Path]   volume=2

traffic_server がこのディスクへアクセス可能なことを確実にするために、udev(7) を使って永続的に適切なパーミッションを設定することができます。以下のルールはUbuntuをターゲットにされており、 /etc/udev/rules.d/51-cache-disk.rules に保存されます:

# Assign DiskA and DiskB to the tserver group
# make the assignment final, no later changes allowed to the group!
SUBSYSTEM=="block", KERNEL=="sd[ef]", GROUP:="tserver"

これらの設定を適用するには、udevadm(8) で再読み込みを行ってください:

udevadm trigger --subsystem-match=block

FreeBSD の例¶

5.1 FreeBSD から、明示的なローデバイスのサポートは終了しました。FreeBSDにおいて全デバイスは、現在、生でアクセス可能です。

以下の例では、FreeBSD オペレーティングシステムでローディスク全体を使用します。:

/dev/ada1
/dev/ada2

traffic_server がこのディスクへアクセス可能なことを確実にするために、devfs(8) を使って永続的に適切なパーミッションを設定することができます。以下のルールは、 devfs.conf(5) に保存されます。

# Assign /dev/ada1 and /dev/ada2 to the tserver user
own    ada[12]  tserver:tserver

Advanced¶

Because relative paths in storage.config are relative to the base prefix, when using customized runroot it may be necessary to adjust such paths in storage.config or adjust runroot.yaml itself. Despite the name, the cachedir value is not used for this file.