[
https://issues.apache.org/jira/browse/HDDS-14167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18052497#comment-18052497
]
Wei-Chiu Chuang commented on HDDS-14167:
----------------------------------------
one of my colleague shared his approaches:
**a procedure to move roles of ozone from one node to another node**
for SCM & OM:Repeat this procedure for the 3 SCM:
1. Decommission the SCM node and delete it (if it is the primary one, change
the ozone.scm.primordial.node.id configuration to point to another one)
2. Add new one
Source:
https://docs.cloudera.com/cdp-private-cloud-base/7.1.9/ozone-storing-data/topics/ozone-scm-decommissioning.htmlRepeat
this procedure for the 3 OM:
1. Add configuration in ozone-site.xml safety valve the key
[ozone.om](http://ozone.om/).decommissioned.nodes.<ozone_service_id> and as
value the Node ID of the ozone node to decommission (can be found in logs or in
OM UI)
2. In CM > Ozone > Instances > Click on ozone Manager node > Actions > OM
decommission
3. Remove previous property
4. Delete the node
5. Add a new one
Source:
https://docs.cloudera.com/cdp-private-cloud-base/7.1.9/ozone-storing-data/topics/ozone-om-decommissioning.html
**docs.cloudera.com**
[**SCM
decommissioning**](https://docs.cloudera.com/cdp-private-cloud-base/7.1.9/ozone-storing-data/topics/ozone-scm-decommissioning.html)
Storage Container Manager (SCM) decommissioning is the process in which you can
gracefully remove one of the SCM from the SCM HA Ring.
**docs.cloudera.com**
[**OM
decommissioning**](https://docs.cloudera.com/cdp-private-cloud-base/7.1.9/ozone-storing-data/topics/ozone-om-decommissioning.html)
Ozone Manager (OM) decommissioning is the process in which you gracefully
remove one of the OM from the OM HA Ring.
---
Obviously, Recon & S3 Gateway just requires to add and remove instances.
---
for the Datanodes:Firstly, change
parameter:hdds.container.balancer.balancing.iteration.interval to 1m.Add all
new datanodes.Repeat this procedure for each datanode:
1. Stop and delete the Ozone Datanode
2. Wait to make sure no containers are under-replicated with command:
ozone admin container report
> [Docs] OM HA Migration
> ----------------------
>
> Key: HDDS-14167
> URL: https://issues.apache.org/jira/browse/HDDS-14167
> Project: Apache Ozone
> Issue Type: Task
> Components: OM, OM HA
> Reporter: Ivan Andika
> Assignee: Ivan Andika
> Priority: Major
>
> Add documentation for OM migrations. There are two main approaches
> * Configuration-based OM migrations:
> ** Pros: Safer
> ** Cons: Slower, requires all clients to update the OM configurations
> * DNS-based OM migrations: Use DNS mapping to point the same OM address to
> the new OM machine
> ** Pros: Faster, clients can use the same OM configurations
> *** For example, om1-host can be changed from old ip 10.0.0.1 to new ip
> 10.0.0.4
> ** Cons: Riskier
> *** Some clients might have hardcoded /etc/hosts might not be able to see
> the DNS mapping changes
> **** Need to take into account DNS caching TTL
> *** Unplanned leader election might promote the old OM that already
> unreferenced by the DNS mapping and clients cannot find the leader
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
