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

Unidirectional flow of messages on a topic in two Cluster #6035

Open
Hitesh-Agrawal opened this issue Oct 24, 2024 · 1 comment
Open

Unidirectional flow of messages on a topic in two Cluster #6035

Hitesh-Agrawal opened this issue Oct 24, 2024 · 1 comment
Labels
defect Suspected defect such as a bug or regression

Comments

@Hitesh-Agrawal
Copy link

Hitesh-Agrawal commented Oct 24, 2024

Observed behavior

I have two NATS Clusters each with 4 Node.
ClusterA
node1a.cluster.svc.local
node2a.cluster.svc.local
node3a.cluster.svc.local
node4a.cluster.svc.local
Load Balancer :- clustera.lb.internal.com

ClusterB
node1b.cluster.svc.local
node2b.cluster.svc.local
node3b.cluster.svc.local
node4b.cluster.svc.local
Load Balancer :- clusterb.lb.internal.com

I want messages generated in Cluster A on any topic to flow to ClusterB ( if there is interest for the topic), but not vice-versa.

I have configured 1 nodes in ClusterA (node1a.cluster.svc.local) with
leafnodes {
listen: 0.0.0.0:7222
}

=================
In ClusterB only 1 node (node1b.cluster.svc.local) is configured with leaf remote as follow
listen: 0.0.0.0:4222
http: 0.0.0.0:8222

cluster {
listen: 0.0.0.0:5222
name: ClusterB

routes = [
nats-route://node2b.cluster.svc.local:5222
nats-route://node3b.cluster.svc.local:5222
nats-route://node4b.cluster.svc.local:5222
]

no_advertise: true
connect_retries: 0
cluster_advertise: node1b.cluster.svc.local:5222
}
leafnodes {
remotes = [
{
urls: [
"nats-leaf://node1a.cluster.svc.local:7422",
]
deny_exports = [">"]
},
]
}

logtime: true
max_connections: 65535
max_control_line: 512
max_payload: 1048576
max_pending: 67108864
write_deadline: "2s"

=====================================================

Expected behavior

When a message is pub on "testtopic" in cluster "A",
nats pub testtopic "Test from cluster A" --server nats://clustera.lb.internal.com
07:27:03 Published 23 bytes to "testtopic"

It should be received on all the 4 nodes in cluster "B"

but its received only on node1b.cluster.svc.local
nats sub testtopic --server nats://node1b.cluster.svc.local
07:26:38 Subscribing on testtopic
[#1] Received on "testtopic"
Test from cluster A

When I do
nats sub testtopic --server nats://node2b.cluster.svc.local

I dont receive anything here

======================================
Expected Behaviour
Messages published by any node in "Cluster A" , should be receivable on all the nodes in "Cluster B"

The message received on node1b.cluster.svc.local from remote leaf "node1a.cluster.svc.local" should be forwarded to all nodes (node{2-4}b) in "Cluster B".

Question:
Do I need to configure all the nodes in cluster B as a leafnode to "nats-leaf://node1a.cluster.svc.local:7422" ?
I think node1b.cluster.svc.local should have acted as a forwarded for any interest generated in local clusterB for topic "testtopic"
I cannot remove
deny_exports = [">"] as I do not want any messages generated in ClusterB to flow to ClusterA.

Server and client version

[60] 2024/10/24 06:00:12.354477 [INF] Starting nats-server
[60] 2024/10/24 06:00:12.354522 [INF] Version: 2.3.4

Host environment

EKS Kubernetes v1.29

Steps to reproduce

Configure your clusters as above and test the same.

@Hitesh-Agrawal Hitesh-Agrawal added the defect Suspected defect such as a bug or regression label Oct 24, 2024
@Hitesh-Agrawal
Copy link
Author

Hitesh-Agrawal commented Oct 24, 2024

Just to add,
I want node1b.cluster.svc.local to act as an 1 way bridge between "Cluster A" and "Cluster B". Only node1b.cluster.svc.local can reach node1a.cluster.svc.local:7222 other nodes in "Cluster B" cannot reach Cluster A.

Message flow should be "Cluster A" -> node1a.cluster.svc.local:7222 -> node1b.cluster.svc.local -> All nodes in "Cluster B"
If there is any other solution in place , I would be happy to explore that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
defect Suspected defect such as a bug or regression
Projects
None yet
Development

No branches or pull requests

1 participant