We were discussing the use of Object Storage to stash state for each worker from applications services and clusters. We referred to the use of leases in the form of tickets. The tickets need not be issued from a singleton service Tickets can be distributed just as the objects tracked by the tickets can belong to different object storage. We discuss these alternate forms of issuing tickets:
The ticketing service can be chained across object storage. If the current object storage does meet the need for a worker pool, it is possible to pass on the ticketing to another similar stack. The ticketing layer merely needs to forward the requests that it cannot answer to a default pre-registered outbound destination. In a distributed Ticketing service, the ticketing service handlers can make sense out of the requests simply with the help of the object-storage-namespace-bucket-object hierarchy and say if a request can be handled it or forwarded. If it does not, it simply forwards it to another ticketing service cum object storage stack. This is somewhat different from the original notion that the ticketing service is bound to an object storage where the resources for the workers are maintained. The linked ticketing service does not even need to take time to resolve object location to see if it exists. It can merely translate the hierarchical naming to know if the resources belong to it or not. This shallow lookup means a request can be forwarded faster to another linked object storage and ultimately to where it may be guaranteed to be found. The Linked Storage has no criteria for the object store to be similar and as long as the forwarding logic is enabled, any implementation can exist in each of the storage for translation, lookup and return. another way to distribute tickets is with hashes where the destination is determined based on a hash table. Whether we use routing tables or a static hash table, the networking over the object storage can be its own layer facilitating request resolution at different object storage and ticketing later stack.
The ticketing service can be chained across object storage. If the current object storage does meet the need for a worker pool, it is possible to pass on the ticketing to another similar stack. The ticketing layer merely needs to forward the requests that it cannot answer to a default pre-registered outbound destination. In a distributed Ticketing service, the ticketing service handlers can make sense out of the requests simply with the help of the object-storage-namespace-bucket-object hierarchy and say if a request can be handled it or forwarded. If it does not, it simply forwards it to another ticketing service cum object storage stack. This is somewhat different from the original notion that the ticketing service is bound to an object storage where the resources for the workers are maintained. The linked ticketing service does not even need to take time to resolve object location to see if it exists. It can merely translate the hierarchical naming to know if the resources belong to it or not. This shallow lookup means a request can be forwarded faster to another linked object storage and ultimately to where it may be guaranteed to be found. The Linked Storage has no criteria for the object store to be similar and as long as the forwarding logic is enabled, any implementation can exist in each of the storage for translation, lookup and return. another way to distribute tickets is with hashes where the destination is determined based on a hash table. Whether we use routing tables or a static hash table, the networking over the object storage can be its own layer facilitating request resolution at different object storage and ticketing later stack.
No comments:
Post a Comment