Architecture - Proxy Cache
Note: The content on this page reflects the state of design of a Lustre feature at a particular point in time and may contain outdated information.
- By default, the entire distributed entity exporting a lustre file system, both data and metadata (i.e. not the individual server processes of which it is composed).
- An intermediate server that aggregates its clients' filesystem operations onto the backend server it exports to them.
- caching proxy
- A proxy that caches data and/or metadata.
- NV caching proxy
- Non-volatile caching proxy - i.e. a proxy that extends its cache onto local non-volatile memory (e.g. disk, flash).
- disconnected operation
- How the proxy operates when one or more of its component servers can no longer communicate with one or more components of its backend servers.
A proxy uses caching and aggregation to reduce the load on its backend server and to provide better throughput and latency to its clients. Both volatile (in-store) and non-volatile (flash, disk) cache may be applied in any combination (including none at all), as determined by caching policies. This gives the proxy many uses from simple connection aggregation to limit backend server fan-out, to filesystem replication over a wide-area network.
A proxy translates credentials between the client side and the backend server side. This translation implements a security policy on the proxy's clients.
Manage cache contention between different backends.
- Prefetch (what to cache aggressively) - writeback (how much can backend lag) - granularity - whole F/S - single file - filesets?
F/S snapshot - "cut" over servers! persistent lock pre-empts reduced coherence debate? google uses persistent locks?
(partial) Disconnected operation
partial disconnected operation
Local stable storage
Clustered - Restriping - Data and Metadata
Connection offload (Security! SSL etc)