Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support set local region for RegionAwareEnsemblePlacementPolicy #3248

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

wangjialing218
Copy link

Motivation

When RegionAwareEnsemblePlacementPolicy is enabled, write set of one entry contains bookie nodes in different region.
When bookkeeper client read entries, the policy provide a read sequence to read from bookies in the same region first. see

It depend on myRegion which indicate the local region of bookkeeper client (mostly pulsar broker).
Local region is not a configurable value, and it's generated by local host address. see

bn = createDummyLocalBookieNode(InetAddress.getLocalHost().getHostAddress());

It's okey when there is a bookie in the same host of broker.
But in most case, brokers were deployed in other nodes (or pod in kubernetes), and bookkeeper client will fail to get local region value.

Changes

Add configuration of local region for bookkeeper client.

Copy link
Contributor

@hangc0276 hangc0276 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For your motivation, If we read all the entries from the configured region, it may cause hot bookie, and increase the quarantine rate of the hot bookie.

basicReorderReadSequenceWithLocalRegionTest("region2", false);
}

@Test
public void testBasicReorderReadLACSequenceWithLocalRegion() throws Exception {
prepareNetworkTopologyForReorderTests("region2");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should both test read and write.

Copy link
Author

@wangjialing218 wangjialing218 Jul 26, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For your motivation, If we read all the entries from the configured region, it may cause hot bookie, and increase the quarantine rate of the hot bookie.

As current policy, read sequence is as follows


This motivation just add a configuration to set the local region as myRegion for client, bookies in the same region will be orderd as 1. available (local) bookies, when these bookies become unavailable or slow, they will be orderd as 3. R* remaining (local) bookies or 6. slow bookies.

We should both test read and write.

This motivation just add a configuration related to the read order of bookies in a writeSet. IMO we do not need test write.

@StevenLuMT
Copy link
Member

rerun failure checks

@@ -173,6 +174,10 @@ public RegionAwareEnsemblePlacementPolicy initialize(ClientConfiguration conf,
super.initialize(conf, optionalDnsResolver, timer, featureProvider, statsLogger, bookieAddressResolver)
.withDefaultRack(NetworkTopology.DEFAULT_REGION_AND_RACK);
myRegion = getLocalRegion(localNode);
String localRegion = conf.getString(REPP_LOCAL_REGION, null);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

simple code
String localRegion = conf.getString(REPP_LOCAL_REGION);
instead of
String localRegion = conf.getString(REPP_LOCAL_REGION, null);

image

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure whether throwExceptionOnMissing could be set true in some condition.

@@ -79,7 +80,7 @@ public class RegionAwareEnsemblePlacementPolicy extends RackawareEnsemblePlaceme
protected Feature disableDurabilityFeature;
private int lastRegionIndex = 0;

RegionAwareEnsemblePlacementPolicy() {
protected RegionAwareEnsemblePlacementPolicy() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not change it to public?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Change to protected so that we could extends RegionAwareEnsemblePlacementPolicy and implement some addtion policy in broker side in future.
IMO no need change to public.

@StevenLuMT
Copy link
Member

fix old workflow,please see #3455 for detail

@dlg99
Copy link
Contributor

dlg99 commented Dec 7, 2022

What alternative solutions have you looked at?

It's okey when there is a bookie in the same host of broker.

AFACT, the dummy bookie node is created to make use of the resolver API that takes BookieNode as a parameter.
After that it goes through the same resolution mechanism as any bookie; so if you use script-based mapping you can update it to resolve the client's address to region/rack etc, it does not really matter if the client is co-hosted with a bookie.

@wangjialing218
Copy link
Author

What alternative solutions have you looked at?

In synchronous geo-replication solution, suppose we have 4 bookies in two regions, bk1 and bk2 with rack setting /region1/rack, bk3 and bk4 with rack setting /region2/rack
A broker in region1 need to read ledger data and the writeSet is {bk1,bk3}, it's better to let broker read from bk1 which is in same region to avoid across region tracffic. If the topic unloaded to another broker in region2, the broker could read ledger data from bk3 instead.

AFACT, the dummy bookie node is created to make use of the resolver API that takes BookieNode as a parameter. After that it goes through the same resolution mechanism as any bookie; so if you use script-based mapping you can update it to resolve the client's address to region/rack etc, it does not really matter if the client is co-hosted with a bookie.

It's okey to resolve the broker's address to region/rack to achieve, we need to configure the resolver and it's not an easy way if brokers deployed in kubernetes.
This PR provide a bookkeeper client configuration reppLocalRegion for broker, so we could add region-aware setting for each broker according to where the broker is placement by command or configuration.

@hangc0276 hangc0276 modified the milestones: 4.17.0, 4.16.0 Jan 11, 2023
@hangc0276 hangc0276 modified the milestones: 4.16.0, 4.17.0 Mar 13, 2023
@hangc0276
Copy link
Contributor

It's okey to resolve the broker's address to region/rack to achieve, we need to configure the resolver and it's not an easy way if brokers deployed in kubernetes.

@wangjialing218 It is easy to configure by bin/pulsar-admin bookies set-bookie-rack command

If we introduce a configuration reppLocalRegion for the broker, and the broker is scheduled to another region by k8s, we still need to change the reppLocalRegion in conf/broker.conf. It will be hard to maintain.

@eolivelli eolivelli removed this from the 4.17.0 milestone May 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants