Explore: classic peer discovery with randomised startup delay #687
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ansd
changed the title
instead of rabbit_peer_discovery_k8s plugin. For RabbitMQ clusters deployed by the RabbitMQ cluster operator, there is no need for dynamic service discovery since cluster members are known at deploy time. By using the classic config, we increase likelihood of nodes discovering peers. In contrast, K8S peer discovery only considers peers that are ready, which might take a long time resulting in more than one node to start a cluster.
If the RabbitMQ cluster is under heavy load and is being scaled out (i.e. more RabbitMQ nodes added to the RabbitMQ cluster), existing nodes shouldn't be restarted. Before this commit, exising nodes were restarted because the ConfigMap gets updated since new peers get included for peer discovery. However, existing nodes do not need this new peer discovery configuration since the cluster is already formed.
ansd
force-pushed
the
peer-discovery-classic
branch
from
54a2b66 to
ff33f41
Compare
Member
Author
|
Closing this PR in favor of rabbitmq/rabbitmq-server#3075. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Relates #662.
Dynamic peer discovery is not needed for RabbitMQ Clusters deployed by the Cluster Operator. All nodes are known at deploy time. The Cluster Operator knows the number of replicas and their host names.
This PR uses classic peer discovery with a static list of nodes instead of the dynamic
rabbitmq_peer_discovery_k8splugin.In the case of a scale out (i.e. more RabbitMQ nodes added to the RabbitMQ cluster), existing nodes do not get restarted.
Pros:
runningbut not yetreadyincreasing the likelihood of discovering peersCons:
Alternatives:
rabbitmq_peer_discovery_k8s(e.g. as done in controller-runtime leader election)