I hope you're not so tired as I am.
Anyway, thanks.
Okay, so my name is Miguel Ruj.
I come from Portugal.
I'm a community user active.
I love to come to Fossil.
I think it's one of the best conferences.
And I blog a bit.
I should blog more.
But I especially like to help people
and Slack and some questions and Slack
or stack more flow blogs and these kind of things.
I work at Masquel at Oracle.
However, I'm here on my own as a community guy.
I've been working there for 13 years now.
Multiple projects.
Masquel proxy.
Enterprise monitor and so on.
But I'd say the most fulfilling ones were the latest.
That is Masquel shell in the NAPI.
And router and the architectures,
the cluster set and so on.
Let's get moving.
I have a lot of content and not much time.
So let's set the stage and let's talk a bit about
why smarter query routing is important and why is needed.
So I think you all know Masquel router and how it works,
which is a quick refresher.
Masquel router is a core component of the
Masquel architectures.
It serves as a, it has a full integration there.
It does transport clients connection routing.
So it knows where to send the queries.
It sits behind your, between your applications clients
and the notes in the topology.
And it knows where to forward everything.
So it provides a balancing application connection
fell over.
And it's very lightweight.
It's just a simple middleware, very lightweight.
And it's automatically does what is expected from it
most of the times, with almost no setup.
But I'd like to share a personal experience
that's kind of demonstrates where current routing falls short,
not falls apart, but falls short.
So this was a personal experience with a friend of mine
that they, you work in a small startup.
They do some e-commerce.
And they have, you know, the v-cluster deployment.
So they have multiple secondaries.
That's just a simplification of the architecture.
They have multiple secondaries, read weblicas.
And they do three types of traffic.
They have a frontend traffic that they prefer to send
to the secondaries.
They have some kind of B-I traffic that he told me they have
very expensive queries, lots of resources needed.
And they don't care for replication lag.
So they send it to the read replicas.
And on top of that, they even deploy some instances
running newer versions for testing.
So they have it all in the same typology.
And he was struggling with Moscow router.
You know how to configure it to send the queries
to the places you wanted them to go.
So he started by trying to do manual route
the router configuration, which was the terrible idea
because if you configure router manually,
then you lose all the flexibility and the capabilities
of router to dynamically adapt to the topology
and the topology changes.
So no.
Then he, I was talking to him and I was telling him,
why don't you use the read-only target option
that he can configure it through shell.
And he can configure your routers to send the read-only traffic
to only the secondaries, only the read replicas
or both.
And he was like, yeah, but for that, I need multiple routers.
And it's like, yeah, that's the way to do it, right?
You just place router next to your application.
He said, no, no, no.
We have some kind of layer.
We have some one router in a container.
One configuration.
Then we deploy multiple of them.
And that's under the virtual IP for HE for router.
Something like that.
So anyway, at the end,
it's also thinking that for the newer versions,
you cannot do anything with router.
You cannot just configure it to send traffic there.
So no.
Also no.
Rejected.
And we were having lunch and by the end of HE he was like,
hey, man, why don't you write up?
Why don't I open a feature request and you write the batch
to support this like, oh man, no way.
The first of all is not that simple.
And then I'm going to create a feature
or some kind of feature that works just for you,
and nobody else.
And that's some undeniable.
And we will just open a Pandora box.
And it's just really a bad decision.
So he said, okay, I wasn't going to pay you lunch, but nope.
Anyway, this was just to demonstrate how with the evolution of my
school architectures and topologies,
routing can bring a lot of challenges.
So we need to really need a smarter approach,
something more flexible to adapt to this kind of topologies.
This is an example of a cluster set.
So in cluster set you have,
geographically distributed instances,
multiple clusters.
Here there's just two, one in the US and another one in Europe.
And in this kind of set ups,
you want to optimize traffic based on proximity.
So you want queries to go to the closest data center.
And rather than consider the latency differences between that
centers.
So you want to do this optimization,
and you want to configure it to use proximity.
Another example, resource prioritization,
in a scenario of, for example, an overload of the system,
or some partial load type,
usage, you certainly want, or you may want some critical
operations to be prioritized.
And you can do that with router,
because router treats all sessions equally.
So that's a challenge.
Another example, the last one,
if you want to do some kind of schema specific routing,
you want to, some queries of a specific schema to go to that cluster.
Some others of another schema to go to the other cluster.
You just can't do it at a moment.
You need to do some manual management of the connections
and that's really complicated and is not ideal.
So it's also another limitation with the current routing mechanisms.
So just summarizing quickly this.
Has a thing as the complexity of the setups grows.
We certainly want support for application specific configurations.
We want to adapt in scenarios of overloads,
failovers, or even maintenance.
And in particular, we want to enable granular control.
So we want to go even down to individual statements within a session.
We want to work with that and know and do better management of routing.
So we want to consume routing for very narrow and very specific use cases.
So meet my scroll routing guidelines.
This is a new thing.
It's just got out in nine two, a couple of weeks ago.
For shell and router.
And this is aims to lift up those limitations and solve those challenges.
So let's jump to the details and tech and what's better than a snippet.
So routing guidelines are written in JSON.
They live in the metadata schema of the topologies.
And they have four main attributes.
Name version.
We use semantic versioning for this.
And then the important ones are the destinations and routes.
If you look at the destinations, you can see this is a very simple example.
The primary and the secondary.
That's you know what it is.
There's a match that's I'm going to talk about it later.
It's also easy to read.
That's member role primary and secondary.
I guess you understand what that means.
And then you have the routes.
Also here on the bottom that one is named RO.
It's for read only.
There's a match expression that is saying that target parts of the session equals to routers with only part.
And then a list of destinations that I will explain how it works.
So let's break it down.
Starting with the destinations.
Like I was saying destinations.
They group the servers of the topology using this pattern matching expressions.
So here I have three.
I'm using the member role primary, secondary and read replica.
And I create this list of destinations.
And each we call it destination class.
Each class forms a pool of candidates for offices for routing.
As for the routes, similarly they use pattern matching expressions.
And routes are used to classify the incoming sessions according to an expression.
And route to a list of destinations.
So this one is called read only.
The match expression, like I was saying before, is that if the session target part equals to the routers read only part.
Then I want the queries to go to those destinations.
The list of destinations is ordered by priority.
The first one with priority zero, the secondary.
And so it means that if there are secondary, if there are instances available on that destination class.
The things the queries will go there first.
If none is available, it will jump to the next one.
That is the class primary.
And then you see the strategy that is the strategy applied for the queries.
So run, run in this case.
So as for the matching rules, these matching expressions.
We have three predefined sets of variables.
Server ones, related to my school server, session related to the client session.
And the router related to the router instance.
And then you can apply functions and operators.
So you have the logical operators.
The inclusion checks, the like operator to the pattern matching.
Arithmetic operations, comparisons, and the list of functions that I will show after that.
You're going to be familiar with them.
So summarizing these matching expressions.
They are used to classify the servers and the sessions and the routers with logical conditions.
So those expressions.
Evaluates to true or false.
You can compose using variables, operators, and values to create the matches.
It can change them with these conditions.
We don't are not for flexibility.
This is the bottom, the syntax of how to, of the matching expressions.
I'm not going to go through the whole list.
You can then download the slides later.
But just to give you an idea, this is the server ones.
You have stuff like server address, power to your ID version.
The member role that we used on the previous example.
And so on.
The session ones.
Port, source, the username, schema, connection attributes.
That opens the door for many, many things.
There was already a talk that mentioned them.
And the router ones, the router parts, read rights, read only, read rights split.
Bind address, the name of the router, the host name, and so on.
As for the functions, this is the ones available, concatenation, network,
contains, resolve, rejects, and so on.
You can, I put some examples there.
You can work with these functions to create these complex or not matching expressions.
So the workflow, the high level vision of it in router, is that router classifies destinations.
So it's group servers into the destination classes.
Each member of the topology can belong to one or non or multiple destination classes.
Then the matching rules, the rules are matched when the incoming sessions come.
And then router applies if a session is matched to a rule.
And there are destination classes available.
The router will apply the routing strategy.
As of now, we have first available and run robin.
And router is continuously monitoring the topology.
Reclassifying servers if needed, updating routes, or disconnect invalid connections.
If that's the case, because the routing guideline changed, or some other conditions.
Now moving to shell and the admin API, as usual shell fully supports the management of
routing guidelines.
And it was extended with new bunch of new commands.
It has support for the three architectures.
You know, the cluster replica set in cluster set.
There's a new routing guideline class with many functions to manage the routing guidelines.
And this is just a print screen of creating default routing guideline on cluster topology.
So these are the main commands to start.
So you have create routing guideline.
Set routing option that enables you to activate the guideline on a topology or deactivate.
And each topology can have multiple routing guidelines.
But only one case can be enabled at a time or non.
Get routing guideline, remove routing guideline.
Routing guidelines to list the ones of your topology.
And import, because you can import from adjacent file into the topology using that command.
As for the new class, the routing guideline class.
There's a show command that will print in a human readable way.
The destinations with a much expression for each one with a name.
And includes the servers of your topology.
That are much to those destinations.
The routers library to do that in runtime.
Has Jason to printed out destinations and routes to print the destinations and routes.
Add routes, add destination, remove route, remove destination.
I just use a bunch of synonyms for clear in the purpose, because the names face a URL.
Set destination options, set route option, copy to copy over a routing guideline.
Export to export it to adjacent file.
So you can import it later.
And rename to just rename it.
Do you have a quick question?
Yes.
This is on the shelf, but you can probably talk to the routers.
We're going to print that synchronizing the configuration setting.
Now, everything is in the metadata.
It's all stored in the metadata.
Routing guidelines are stored there as Jason.
And the route is reading from that to later.
Yes.
Exactly.
Okay.
There's still 10 minutes.
So I want to go through some use cases and to show how the potential of routing guidelines.
And let's start with the common one.
High availability in disaster recovery.
So cluster sets.
And we want seamless fill over in this kind of topology.
So we want to redirect traffic to alternate nodes when there is an outage.
So we have service all the time.
We want to prioritize local traffic.
So we want to not prioritize local traffic.
We want traffic to be local if possible for performance reasons.
We want to optimize read by routing.
Router already does that by default.
So to router the queries to the primaries or the secondaries.
And to the real replicas for the red scale out.
But we want also to have fallback levels.
In case the one of the destination classes is available.
Just another one and so on and so on.
To ensure maximum availability of your topology.
So I don't know if you can see this.
It's screenshots.
I'm showing here the destinations command.
And I've created all these destinations.
And starting from top.
The two first ones are related to the primary member.
Primary local primary remote.
And I'm using the cluster role is the primary cluster of the cluster set.
And the member role is the primary member of that cluster.
And I don't want the cluster to be validated.
An validated cluster is in a case of fill over in cluster set.
Like in an asynchronous topology.
That old primary is invalidated because we don't want the data to be wrong.
And finally, the server cluster name equals to the router local cluster.
So when you bootstrap a router, the router is bootstrap against the cluster.
And we know the name of that cluster.
So that cluster is local to the router.
So if I say that my server's cluster name is that router's same name.
I know that is a local one.
As for the remote is the same thing except in the end in set of equals.
I'm using it's not equal.
Then I did the same for the second there is scale out.
And the final ones is the read only file bulk local.
In this case, I accept that the cluster is validated like the extreme case.
That I cannot read from anywhere else.
And I would like to read from those.
There's a destination for that.
So destinations are defined as for the adding routes.
The first one for read right traffic is the more simple one.
I say that I want the target parts of my incoming session.
To be either the routers read the right port or the read right split port.
And I want to use the following destinations.
They are the way you write the list is the order that they get into the routing guidelines.
So first use the primary local.
If not available, jump to the primary remote.
And then I want to say also that I want to allow connection sharing in my school router.
And what's the last one?
Enable through.
Yeah.
Because you cannot route and they're disabled and we enable them at any time.
As for the read only traffic.
In this case, I want that the session target part is the read only part of router.
And I do run the robbing of all the secondary destinations.
This is just an example to show you how to.
In this case, to define fallback levels.
Being the first one, I want that things go to the secondarys.
And the scale out local to scale the reads.
And the last one, to use only the fallback.
This one here.
That is the one of the things related to cluster just as an extreme situation.
Is the last resort.
No, an example.
Maybe this is easier to read.
So this one is about geolocation based routing and compliance.
So here I have some destinations based on regions.
And I also have some traffic that I want to send to some particular instances for compliance reasons.
So I have the two destinations for the regions on top.
In this case, I'm using the server address.
And I want the server address to be long to US east one example.com or US west two example.com.
Those are the US regions.
And the same for the European regions.
And then I use the server tags compliance.
So the tags are you can set them through shell.
And they are key value pairs.
This case I called it compliance.
The key and the value GDPR.
And those are the destinations that I named GDPR compliance.
So having those destinations defined.
And I can create the routes.
And starting with the geotratic based on IP.
The first one is called geobaste.
And over there I'm using in the match expression the network.
So I'm shaking if the network, the range of the IP address that network is the same as that.
182.
The other one.
So IP network matching.
I want those to be routed to those destinations.
And on the other routes called compliance based.
I'm using the tags.
So I'm not tags the connection attribute.
And I'm saying that the connection attribute region equals EU.
And for those I want the traffic to go to the servers that were tagged with GDPR compliance.
Schema based routing.
Also just an example in case you want to split traffic.
You want traffic of sessions that use a specific schema to go to some destinations and sessions using another schema to go to some other destinations.
In this case different clusters.
For that I can use the session schema variable.
And with that, this is the example of the show command.
And like I said before, it lists the routes with a match expression.
And the destinations of your topology.
It evaluates in that runtime.
And so I have these two routes, the app schema routing.
And that app schema routing that use the sessions schema variable to define.
To define the destinations that we want to use.
And the destination classes are based on the server variables.
Cluster role, member role, and cluster name.
And without I could define those four destinations for this example.
It's just an example.
I'm not sure you understand this.
But you have a single endpoint to the connection.
We're like a deployable schema once again.
Yes.
Then you could route based on that.
Yeah, that's true.
Next one.
This is an interesting example.
So in this case, I have four types of traffic.
Testing, staging, production, and session affinity related traffic.
So I want to 10% of my client sessions to go to testing servers.
20% to go to staging servers for validation.
And the remaining traffic to go to production servers for stability.
And then I have this session affinity that is to ensure that sessions using that accounts.
The persistent user are kept to all the servers for to ensure continuity.
So for that, I have defined three types of servers.
Production staging and testing.
For those I've set tags.
So using shalloc and tag the instances.
And as for the routes, I use the session random value.
So random value is a double that is randomly generated by router at runtime.
Per session and it's between 0 and 1.
So I say that if the random value is slower than 0.1, that's 10%.
I want to send it to the testing servers using the first available routing strategy.
Then if the random value is between 0.1 and 0.3, so 20%.
I want to send it to the staging servers.
And the rest, if it's higher than 0.3, send to the production servers using the first available.
Finally, if the session user is persistent user, I just run the run through all the available destinations.
Production staging and testing servers.
Another interesting example, again, connection attributes.
So in this case, I have traffic coming from my scope dump that I want to send to some backup servers.
I have traffic coming from Linux sessions that I want to send to servers running Linux.
And for that, I use the connection attributes OS and program name.
And the metadata tags again to define the destinations.
And in this case, I have defined the two destinations on top, backup servers, Linux servers using tags.
And the routes first routes Linux traffic.
I want to say that if the session with the connection attribute, your OS equals Linux,
I want to send them to the Linux servers.
And down if the program name is my scroll dump, I want to send that to the backup servers.
And back to my friends challenge a couple of weeks ago, I told him,
now you can do interesting things.
So let's solve your problem.
So we've started by defining destinations using the memory role.
So primary, red, red, red, black and secondary.
And we split the red, red because by traffic, by network.
And remember rules.
And we have the testing servers that use higher versions.
And for that we use the server version variable.
And with that we could define those destinations for the red replica traffic for frontend traffic.
For as a follow up level, the red replica traffic for the BI traffic.
The second there is that to receive the frontend traffic, the primary and the testing servers.
In this case, I'm indicating that the server version is nine two.
And this is how the routing guideline looks like.
Frontend traffic prioritizing secondary and falling back to the red replica.
And the BI traffic is prioritizing red replica that are dedicated for that.
And only falls back to frontend red replica if needed.
And in case none of those are available.
So there's not much time to go into a lot of details.
So it's closed and just three takeaways.
Routing guidelines enable a declarative way of defining routing.
It's very flexible in dynamic.
Using shell admin API, it's really easy.
It's quite pleasant to manage this.
And this allows future radio architectures.
We have more flexible setups and we can handle more narrow use cases and and complex topologies.
Some resources.
I wrote a cook book.
It's on the shell repo.
It's called routing guidelines MD.
There's tons of examples.
I go through all the shell commands in a.
The intuitive kind of academic way of explaining things.
So you buy the end of it.
You understand everything.
There's the official documentation, of course.
And we're in Slack and we.
We love to help people.
So.
Thanks.
That's what's in margin.
For four feet.
Yes.
One.
Two.
No.
Not yet.
Maybe when it is these things working.
Yeah.
Does it do mirroring?
Sorry.
Does it do mirroring as well?
Like if you want to send it to two.
If it is what?
Sorry.
Does it do mirroring?
Oh, mirroring?
No, no, no, no.
We haven't thought about it.
But.
Yeah.
Thanks for that.
Yes, everyone.
Have you considered also.
The matching of protein based on courier.
Yes.
Good question.
That's.
That's next.
Yeah.
I have a question.
It's a country here.
Some kind of high probability for the.
Well, well.
You can do many things.
In this case, he, this guy was doing.
He had it under a virtual IP.
So if the router goes away, it goes to the next one.
That's the line one, one route.
If I say that, we have three that are same.
There's a four that are same.
I think the line one that one that's found route.
No, you should actually you should deploy router together with the application with a client.
So you can see router as the connector.
It's the next station to the connector.
So that's how it should be deployed.
That's a recommendation actually.
Okay.
But it's like it's going to boot.
It's going to boot.
That's the route for each line station in the platform.
Find somewhere in the case.
Then basically, there are two ways.
That you can just go with us in.
Use the name.
You can use the name.
By bootstrapping all the time.
So you can use the same one.
The user name for the router.
You can use the same one.
Yeah.
You can use the same one.
Yeah.
And in shell, you can create an account for bootstrapping.
That you can use for all routers.
So.
Yes, using the rest API, you can access that information.
Yeah.
Let's.
Yes.
So this is a well.
Yes.
This is available in router 92 and shell 92.
But your server can run eight, eight, four, whatever.
So.
What are you doing?
There's a real population of route.
Or not so I can switch over to standby.
Or if you're a mobile call.
And now the local one is in three.
Yes.
You might as well.
Next.
Next section.
Yes.
Well, connection.
That's something.
Yeah.
I understand the use case.
That's something we should probably think about.
Yeah.
Thank you.
Thanks.