[
https://issues.apache.org/jira/browse/IGNITE-26892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-26892:
------------------------------------
Description:
h1. Motivation
As a user, I want to leverage DNS to keep the client connected to all cluster
nodes, even in the face of topology changes.
h1. Requirements
1. When a host name is provided in IgniteClientConfiguration#addresses, the
client should resolve it and use all returned IPs as potential node addresses
2. Resolve all known host names again and connect to newly discovered addresses:
- On any connection error (might indicate node failure)
- On primary replica change (might indicate topology change)
- On timer (to handle DNS caching)
h1. Usage Examples
h2. Kubernetes Headless Service
K8s headless service approach is typically used for distributed systems (Redis,
Cassandra, Kafka, etc).
* One host name “my-db.default.svc.cluster.local” resolves to all pod addresses
* Only “ready” pods are returned by default
* If a node is not in the cluster yet, it is not “ready” (use REST API as a
readiness probe)
* Pods come and go, their IPs can change, K8s handles that
was:
h1. Motivation
As a user, I want to leverage DNS to keep the client connected to all cluster
nodes, even in the face of topology changes.
h1. Requirements
1. When a host name is provided in IgniteClientConfiguration#addresses, the
client should resolve it and use all returned IPs as potential node addresses
2. Resolve all known host names again and connect to newly discovered addresses:
- On any connection error (might indicate node failure)
- On primary replica change (might indicate topology change)
- On timer (to handle DNS caching)
h1. Usage Examples
h2. Kubernetes Headless Service
K8s headless service approach is typically used for distributed systems (Redis,
Cassandra, Kafka, etc).
* One host name “my-db.default.svc.cluster.local” resolves to all pod addresses
* Only “ready” pods are returned by default
* If a node is not in the cluster yet, it is not “ready”
* Pods come and go, their IPs can change, K8s handles that
> Thin clients: improve DNS resolution logic
> ------------------------------------------
>
> Key: IGNITE-26892
> URL: https://issues.apache.org/jira/browse/IGNITE-26892
> Project: Ignite
> Issue Type: Epic
> Components: thin clients ai3
> Reporter: Pavel Tupitsyn
> Assignee: Pavel Tupitsyn
> Priority: Major
> Labels: ignite-3
> Fix For: 3.2
>
>
> h1. Motivation
> As a user, I want to leverage DNS to keep the client connected to all cluster
> nodes, even in the face of topology changes.
> h1. Requirements
> 1. When a host name is provided in IgniteClientConfiguration#addresses, the
> client should resolve it and use all returned IPs as potential node addresses
> 2. Resolve all known host names again and connect to newly discovered
> addresses:
> - On any connection error (might indicate node failure)
> - On primary replica change (might indicate topology change)
> - On timer (to handle DNS caching)
> h1. Usage Examples
> h2. Kubernetes Headless Service
> K8s headless service approach is typically used for distributed systems
> (Redis, Cassandra, Kafka, etc).
> * One host name “my-db.default.svc.cluster.local” resolves to all pod
> addresses
> * Only “ready” pods are returned by default
> * If a node is not in the cluster yet, it is not “ready” (use REST API as a
> readiness probe)
> * Pods come and go, their IPs can change, K8s handles that
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
