Abstract:
Many cloud solutions written by customers of
public cloud services rely on billing and costing of their resources from the
service provider, but they have absolutely no differentiation over their
usages. The pay-as-you-go billing model is inherently dependent on the
monitoring of the underlying cloud resources and that for the logic deployed by
the customer but the differentiation of the usages cannot be made by the cloud
infrastructure unless it is specified by the end-user application. Even if it
did, there is no inherent mechanism to color the usages across the cloud
resources to provide enhanced billing.
This article provides a glimpse into the service which could honor
customer differentiation of usages which could pave the way for assignment of
quality of service over the public cloud resource consumption.
Description:
Central to this proposal is the notion of
classification and quota management for the end-usages where the classification
is not only performed by the cloud resource provider based on connection
attributes but also helpfully tagged by the customer applications using those
resources. Customers can augment any resource usage with custom web request
headers that introduce tags in the values with which to classify. They also set
the user defined rules with which to classify. There is a clear separation
between the classification rules and the resource plans. This is because the
classification rules are dynamic in nature and could change for assigning the
connections to different groups. Groups of connections share the same pool of
resources. The cloud only needs to keep track of the resource plans. These
plans are determined by the customer for the public cloud and are actively
looked up by the cloud when assigning resources to workload. To the public
cloud, the requests do not matter, they belong to a group, but the resources
matter since the cloud must account for all resources and divide them between
groups. The groups are a label for different connections and was an identifier
to denote how much resources could be guaranteed to the cloud. The default
guarantee is all inclusive and permissible with the customer provided tags used
for accounting. The rules are for connections and connections are transient. In
comparison, the resource plans are more stable, and cloud defined. Second the
connections could have different characteristics and the classification based
on connection properties could change with the next connection. The classifier
is a simple user defined function with system defined rules included that
assigns the incoming connection to a group. The classifier has visibility into
the tags provided. This function evaluates the connections based on program
order and in the form of a decision tree. This classifier function can be
modified and updated independently from the resource plans. By its nature, the
classifier is code while the resource plan is data. Furthermore, the resource
plan data for the cloud is constantly read when assigning the resources and
require cloud reconfiguration at resource provider level after each change
since it affects resource throttling, monitoring and billing for incoming
connections. However, the cloud does not need to know anything about the
connections or persist any connection properties since these have been
evaluated to a group. The group is a label for the cloud that is used to assign
incoming connections on which a policy is applied as defined by the resource
plans. The groups can be hierarchical as well while the resource plans are
discrete and flat. The resource plans
also must tally up to the full cloud capability. Therefore, it is owned and
enforced by the cloud. The user connections, on the other hand, are mapped only
once to different pools. In addition, it is written as any other user defined
function. Although in practice this is done by the administrator and requires
cloud reconfiguration since the cloud needs to know that the memberships to the
groups have changed, the classifier is connection facing and hence qualifies as
just one other user defined function. The decision to reconfigure the cloud at
the resource provider level after every classifier change is an important one.
It is not merely sufficient to change the classifier to impact the next
incoming connection, it is important for the cloud to know that the memberships
to groups are being redefined. This means that connections that were previously
coming to a group might now be classified to another group and the plans for
that may deny resources or switch billing categories to the new connection. The
cloud treats the classifier and the plan definitions as together constituting
the resource management policy. So, if one of them changes the cloud's resource
management behavior changes. In a way this is a way to tell the cloud that the
policy has changed and is intended as a control for the administrator. Lastly,
the policies and the plans are different because there are checks placed on the
plan whereas the policies are arbitrary and have no relevance to the cloud. The
checks on the plan, however, determine whether the next billing cycle is
changed. The calculations by the resource provider are dependent on the plan
information and this is a state that's persisted so that the cloud can
automatically pick up the state between restarts. Thus, the resource policies
and plans are treated differently. This feature differs from the Azure resource
manager in that ARM has multiple resources, role-based access control, custom
tagging and self-service templates which affect create, update and delete of
resources whileresource usage management is the focus of this feasibility
study.
No comments:
Post a Comment