Saturday, November 3, 2018


We were discussing the use of Object Storage to stash state for each worker from applications services and clusters and its implementation in the form of distributed services over object storage.
A lease is supposed to help track resource usage. If the callers have to send the requests to the same single point of contention, it is not very useful.  When requests are served from separate leaseing service, the performance generally improves when there ar e load balancers. That is why different proxy servers behind a lease could maintain their own leaseing service.  Shared services may offer at par service level agreement as an individual service for requests. Since a lease will not see performance degradation when sending to a proxy server or a shared dedicated lease, it works in both these cases. Replacing a shared dedicated leaseing service with individual dedicated leaseing service is entirely the call of the consumers.  

The policies for a lease need not be mere regex translation of worker parameters to object hierarchy. We are dealing with objects on a worker by worker basis where we can use all parts of the hierarchical namespace – bucket – object names to differentiate the resource usages for workers. For that matter names may be translated so that the caller may only need a lease id to enumerate all storage resources within the object storage. We are not just putting the lease on steroid, we are also making it smart by allowing more interpretations and actions on the resource usages. These rules can be authored in the form of expressions and statements much like a program with lots of if then conditions ordered by their execution sequence. The leases facilitate a lookup of objects without sacrificing performance and without restrictions to the organization of objects within or distributed stores because it enumerates them within the lease.

No comments:

Post a Comment