Workload Prioritization – How it Works Together

Before we move on and we have a question related to it.
So the question for is that “Does workload
prioritization help the scaling, for example, higher disk
plus lower CPU or vice versa?”. I’m not sure I understood
the question.
I will try to
answer it.
So first of all, workload prioritization
is only about user workloads
So during the actual scaling, when streaming happens,
it is already isolated from user queries
in a way that should interfere with it
as little as possible.
So actually workload prioritization doesn’t apply
here.
You cannot define a workload type for scaling.
I hope this answers the question.
Okay.
And I hope we have time for one more question from Piotr.
“Is there a timeout defined in the query?” So
there is
you can define,
as I mentioned before,
you can you actually have three different definitions
for timeout of queries.
One is in the YAML and this is the default
if you haven’t given any other value.
The second one is the service level.
If you define something about the session specific
timeout,
it will be respected, of course.
And the third one is a dynamic one.
I guess that this is the one that Piotr is asking about.
We have a CQL extension that
that is using timeout
and you can actually run a query
with different timeout
demands.
So if you have specific query that you want to get the answer
very fast or fail, of course you can use the “using
timeout”.. So this is something you can do.
And what Scylla will do, it will try to serve the request.
And if at some point in time while processing it,
it will get to a conclusion
that the timeout has already passed.
It will get back a timeout exception as you would get
if the cluster is overloaded or something or
like any other timeout.. So
yes, Scylla is respecting it in the query level,
if it is given.
And if not, as I said, we fall back to the session properties
and if this doesn’t exist, we fall back to the YAML
definition, which, if I’m not mistaken,
defaults to something like 20 seconds.
So it’s not very useful for
real time.. Okay.
Awesome. Okay.
Thanks. Let’s move on.
Okay.
I’ll try to answer it later.
Chin May.
How do we create service level?
So, first of all,. I just included here
the actual documentation
from the Scylla website about service levels and also
about the additional isolation of workload prioritization.
So you can have a look at it and see
about all of the prerequisites, for example,
that needs to be defined on the cluster.. I will
mention them shortly, but so the prerequisites are, first
need to have
authentication and authorization enabled because Scylla is
using the authentication system or identification system
in order to determine which session type is logged in.
So it does it by the username that is logged in.
So you have to have some kind of an authentication for this
and you need to have at least one role. Of course, that
if you enable authentication, you will have at least one role,
the Cassandra one, the default one, so it’s kind of a given.
How do we actually create service levels?
This is taken from the documentation.
So for open source, we just use the CQL that is mentioned.
You can see here that the timeout can be
expressed in some standard units.
It can be milliseconds or seconds.
I don’t believe that anyone want to go beyond that.
But I think it is supported
and the workload type, of course that you –
everything is optional, so you can actually define
a service level with no parameters
or only one parameter,
and then for the
other parameter that you didn’t define,
you will get the default.
About Enterprise, so it’s very much the same
except for the other
supported isolation, which is called “shares”.
The shares number doesn’t have any meaning by itself.
It only has meaning relative to other service levels.
So I will show an example later on.
Just to recap, service level uses Scylla RBAC (role based
access control) or users logins for short.
Roles are ordered in a hierarchical structure, so
you can have role that is granted
a different role. Just as an example, you could have
like two master roles in your system, interactive
and batch, for example, that are not actual users.
And then for every user, you can grant one of those roles
and the sessions, the session parameters
that applies for one of those base roles
will apply also to the user because it inherits this role.
As each service level can be attached to any role
and even to multiple roles, but every role can have only
one service level attached, so it’s one too many relationships.
And for a specific role session,
all of the roles in the hierarchy
or the service level that are attached
to all of the roles in the hierarchy are merged
to compose the final session configuration.
So this is how it works.
How do we attach a service level to role?
So we use this command, “attach service_level” something
to some username.