Skip to content

Introduce simple remote connection strategy #47480

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

Merged

Conversation

Tim-Brooks
Copy link
Contributor

This commit introduces a simple remote connection strategy which will
open remote connections to a configurable list of user supplied
addresses. These addresses can be remote Elasticsearch nodes or
intermediate proxies. We will perform normal clustername and version
validation, but otherwise rely on the remote cluster to route requests
to the appropriate remote node.

@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-distributed (:Distributed/Network)

@Tim-Brooks Tim-Brooks changed the title Introduce simple remote conneciton strategy Introduce simple remote connection strategy Oct 2, 2019
@Tim-Brooks Tim-Brooks requested a review from ywelsch October 3, 2019 16:59
Copy link
Contributor

@ywelsch ywelsch left a comment

Choose a reason for hiding this comment

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

Thanks for the PR. I've left some suggestions for code simplification

@Tim-Brooks Tim-Brooks requested a review from ywelsch October 8, 2019 01:01
@Tim-Brooks
Copy link
Contributor Author

@ywelsch i updated this PR for your comments.

Copy link
Contributor

@ywelsch ywelsch left a comment

Choose a reason for hiding this comment

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

I've left some nits, otherwise looking good.

@@ -161,4 +166,19 @@ boolean assertNoRunningConnections() {
}
return result;
}

static Predicate<ClusterName> getRemoteClusterNamePredicate(ClusterName remoteClusterName) {
Copy link
Contributor

Choose a reason for hiding this comment

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

this is only used by SniffConnectionStrategy now. Move it back down?


private void performSimpleConnectionProcess(Iterator<Supplier<TransportAddress>> addressIter, ActionListener<Void> listener) {
openConnections(listener, 1);

Copy link
Contributor

Choose a reason for hiding this comment

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

extra newline

} else {
int openConnections = connectionManager.size();
if (openConnections == 0) {
finished.onFailure(new IllegalStateException("Unable to open any simple connections to remote cluster"));
Copy link
Contributor

Choose a reason for hiding this comment

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

mention remote cluster name here?

if (openConnections == 0) {
finished.onFailure(new IllegalStateException("Unable to open any simple connections to remote cluster"));
} else {
logger.trace("unable to open maximum number of connections [opened: {}, maximum: {}]", openConnections,
Copy link
Contributor

Choose a reason for hiding this comment

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

mention remote cluster name here, and log at debug level?

trace is for expected things, debug for more unusual stuff


@Override
public void onFailure(Exception e) {
logger.debug(() -> new ParameterizedMessage("failed to open remote connection to address {}", address), e);
Copy link
Contributor

Choose a reason for hiding this comment

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

mention cluster name here

return resolvedAddresses.get(Math.floorMod(curr, resolvedAddresses.size()));
}

private ConnectionManager.ConnectionValidator clusterNameValidator(DiscoveryNode node) {
Copy link
Contributor

Choose a reason for hiding this comment

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

let's remove the node parameter here and have a single instance of the ConnectionValidator initialized in the constructor. The node here is not that useful, and you can get it from the connection (newConnection.getNode()).

@Tim-Brooks Tim-Brooks merged commit 98611e7 into elastic:master Oct 8, 2019
Tim-Brooks added a commit to Tim-Brooks/elasticsearch that referenced this pull request Oct 24, 2019
This commit introduces a simple remote connection strategy which will
open remote connections to a configurable list of user supplied
addresses. These addresses can be remote Elasticsearch nodes or
intermediate proxies. We will perform normal clustername and version
validation, but otherwise rely on the remote cluster to route requests
to the appropriate remote node.
Tim-Brooks added a commit that referenced this pull request Oct 25, 2019
* Extract remote "sniffing" to connection strategy (#47253)

Currently the connection strategy used by the remote cluster service is
implemented as a multi-step sniffing process in the
RemoteClusterConnection. We intend to introduce a new connection strategy
that will operate in a different manner. This commit extracts the
sniffing logic to a dedicated strategy class. Additionally, it implements
dedicated tests for this class.

Additionally, in previous commits we moved away from a world where the
remote cluster connection was mutable. Instead, when setting updates are
made, the connection is torn down and rebuilt. We still had methods and
tests hanging around for the mutable behavior. This commit removes those.

* Introduce simple remote connection strategy (#47480)

This commit introduces a simple remote connection strategy which will
open remote connections to a configurable list of user supplied
addresses. These addresses can be remote Elasticsearch nodes or
intermediate proxies. We will perform normal clustername and version
validation, but otherwise rely on the remote cluster to route requests
to the appropriate remote node.

* Make remote setting updates support diff strategies (#47891)

Currently the entire remote cluster settings infrastructure is designed
around the sniff strategy. As we introduce an additional conneciton
strategy this infrastructure needs to be modified to support it. This
commit modifies the code so that the strategy implementations will tell
the service if the connection needs to be torn down and rebuilt.

As part of this commit, we will wait 10 seconds for new clusters to
connect when they are added through the "update" settings
infrastructure.

* Make remote setting updates support diff strategies (#47891)

Currently the entire remote cluster settings infrastructure is designed
around the sniff strategy. As we introduce an additional conneciton
strategy this infrastructure needs to be modified to support it. This
commit modifies the code so that the strategy implementations will tell
the service if the connection needs to be torn down and rebuilt.

As part of this commit, we will wait 10 seconds for new clusters to
connect when they are added through the "update" settings
infrastructure.
@fpytloun
Copy link

fpytloun commented Dec 6, 2019

This is great feature, thank you.
Can you please post example configuration to switch existing setup to using simple strategy?

@Tim-Brooks
Copy link
Contributor Author

@fpytloun The meta issue is here #49067. As you can see, the work is scoped for 7.6 although things can always change.

Currently the "simple" work is currently available on either 7.6 or 8.0 snapshot builds.

It can be configured:

// If you do not configure a mode, it will default to the existing sniff implementation
cluster.remote.test_remote_cluster.mode: "simple"
cluster.remote.test_remote_cluster.simple.addresses: ["address:port"]

Please note that it is still in active development. For example, we are still debating whether we want to name it "simple" or "proxy" (the primary advantage of this mode over sniff is for routing through a proxy to unaddressable nodes).

You can follow any updates on the meta issue and the documentation will be updated before any release where this feature is GA.

@Tim-Brooks Tim-Brooks deleted the simple_remote_connection_strategy branch April 30, 2020 18:25
@jakelandis jakelandis removed the v8.0.0 label Jul 26, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants