Architecture - Request Redirection

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.

Definitions

 * Target OST: an OST which file data were initially written to, it receives data access requests from clients, manages locks, maintains information about data cached by clients and dedicated servers, maintains persistent and in-code redirect information.
 * Client:an application which accesses data from target OST
 * Migration: moving file data from one set of OSTs to another
 * Collaborative cache: read only cache distributed over clients or dedicated cache servers. Target OSTs maintain in-core information about clients and cache servers and data they are caching and redirect read accesses to appropriate cache server.
 * Flash cache: write only cache. There are dedicated flash cache servers. Target OSTs maintain (persistent?) information about data cached by flash cache servers and redirect write accesses to them.

Summary
Request Redirection is a mechanism which allows target OST to redirect client requests to other servers. Target OST may decide to redirect a request in hope to improve system throughput or may have to redirect in case when it does not store requested data anymore.

Requirements

 * Universality:clients get redirected to instances of data created via different ways with the same request redirection mechanism
 * Flexibility:the request redirection mechanism can allow clients to specify preferences (for example, "do not redirect me", or "let me choose myself")
 * Extensibility:adding new ways to create instances of data should require no or minimal changes to request redirection mechanism
 * Availability:requested data are accessible either at servers to which a client is redirected or at target OST
 * Centralization:target OST keeps all the information about possible redirections, all lock requests get sent to it, it does locking and optionally can redirect a client to another server where data access will happen without further locking
 * Modes:redirection information can be stored persistently when it has to survive reboots (for example in case of migration) or it can be maintained in memory only (for example in case of collaborative cache)
 * API:request redirection mechanism provides means for clients to send/receive redirection information to/from a target OST, means for target OST to store that information
 * Multiplexing:there may be several instances of the same data. Request redirection mechanism should be able to deal with that. For example, in case of collaborative cache target OST has to be able to find clients which are caching requested data and to choose where to redirect.

Use Cases

 * collaborative cache populating


 * collaborative cache redirection


 * flash cache redirection


 * client accesses a file which migrates


 * data server crash


 * agent sends a RID update request to data server

Questions

 * 1. Is there need for request redirection mechanism to be involved into filesystem replication? Hopefully not, because of significant overhead of RID maintainence.
 * 2. in case of replication it may happen that data server can either serve a request locally or redirect the request somewhere else. Who is to make a choice?