[
https://issues.apache.org/jira/browse/HDDS-16136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siyao Meng updated HDDS-16136:
------------------------------
Description:
SCM HA groups whose Ratis peers were recorded with IPv4 literal addresses
cannot move to IPv6-only operation by editing ozone-site.xml alone. SCM starts
its Ratis server with an empty group and recovers the peers, including their
addresses, from Raft storage, so the stored IPv4 addresses keep being used.
This is not a blocker for IPv6 support in general. It does not affect:
* New clusters deployed with IPv6 addresses.
* Peers configured with DNS names, which remain the preferred migration path
because the stored hostname resolves to IPv6.
* Dual-stack clusters that keep IPv4 connectivity.
* OM HA, which passes its configured peers to Ratis at startup, so its
connections follow ozone-site.xml. Only the stored and displayed addresses may
stay stale.
Candidate approaches:
* Document the offline ratis-shell {{local raftMetaConf}} command as a manual
procedure run on each stopped SCM.
* Register the configured SCM peers with Ratis before the server starts, as OM
does, so connections follow ozone-site.xml.
* Use a Ratis startup option that refreshes the stored peer addresses from the
supplied peers, if Ratis adds one. This was proposed in the review of
[apache/ratis#1630|https://github.com/apache/ratis/pull/1630]; RATIS-2082 was
closed as Won't Do.
Replacing each SCM through decommission and bootstrap with its new address
remains a fallback with existing tools.
Requirements:
* Preserve the Ratis group ID, peer IDs, storage, and committed state.
* Support a rolling restart while both IPv4 and IPv6 addresses are reachable.
* Allow a wrong address to be corrected by fixing the configuration and
restarting.
* Validate leader election and failover after migration.
* Add SCM migration tests.
Parent epic: HDDS-15763.
was:
SCM and OM HA groups configured with IPv4 literal peer addresses cannot migrate
to IPv6-only operation by changing ozone-site.xml. Ratis loads committed peer
configuration from persistent metadata and currently treats a configuration
with the same peer IDs and different addresses as unchanged.
Add supported Ozone administrative operations for updating SCM and OM Ratis
peer addresses.
Requirements:
* Preserve the Ratis group ID, peer IDs, storage, and committed state.
* Verify that the new IPv6 addresses are reachable before submitting the
configuration.
* Submit and verify an address-only Ratis configuration change.
* Support restart after ozone-site.xml is updated on every peer.
* Validate leader election and failover after migration.
* Support rollback to the old addresses before IPv4 connectivity is removed.
* Do not require direct edits to Ratis logs or storage files.
* Add SCM and OM migration and rollback tests.
Stable DNS names remain the preferred migration path because they do not
require changing the stored peer addresses.
Blocked by RATIS-2082.
Parent epic: HDDS-15763.
Summary: Support migrating SCM HA from IPv4 literal Ratis peer
addresses to IPv6-only (was: Support in-place IPv6 migration of SCM and OM
Ratis peer addresses)
> Support migrating SCM HA from IPv4 literal Ratis peer addresses to IPv6-only
> ----------------------------------------------------------------------------
>
> Key: HDDS-16136
> URL: https://issues.apache.org/jira/browse/HDDS-16136
> Project: Apache Ozone
> Issue Type: Task
> Reporter: Siyao Meng
> Priority: Major
>
> SCM HA groups whose Ratis peers were recorded with IPv4 literal addresses
> cannot move to IPv6-only operation by editing ozone-site.xml alone. SCM
> starts its Ratis server with an empty group and recovers the peers, including
> their addresses, from Raft storage, so the stored IPv4 addresses keep being
> used.
> This is not a blocker for IPv6 support in general. It does not affect:
> * New clusters deployed with IPv6 addresses.
> * Peers configured with DNS names, which remain the preferred migration path
> because the stored hostname resolves to IPv6.
> * Dual-stack clusters that keep IPv4 connectivity.
> * OM HA, which passes its configured peers to Ratis at startup, so its
> connections follow ozone-site.xml. Only the stored and displayed addresses
> may stay stale.
> Candidate approaches:
> * Document the offline ratis-shell {{local raftMetaConf}} command as a manual
> procedure run on each stopped SCM.
> * Register the configured SCM peers with Ratis before the server starts, as
> OM does, so connections follow ozone-site.xml.
> * Use a Ratis startup option that refreshes the stored peer addresses from
> the supplied peers, if Ratis adds one. This was proposed in the review of
> [apache/ratis#1630|https://github.com/apache/ratis/pull/1630]; RATIS-2082 was
> closed as Won't Do.
> Replacing each SCM through decommission and bootstrap with its new address
> remains a fallback with existing tools.
> Requirements:
> * Preserve the Ratis group ID, peer IDs, storage, and committed state.
> * Support a rolling restart while both IPv4 and IPv6 addresses are reachable.
> * Allow a wrong address to be corrected by fixing the configuration and
> restarting.
> * Validate leader election and failover after migration.
> * Add SCM migration tests.
> Parent epic: HDDS-15763.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
