Steps to perform maintenance on a node in PetaSAN 4.0.0
uduggireddy
6 Posts
December 9, 2025, 1:07 pmQuote from uduggireddy on December 9, 2025, 1:07 pmHi team,
Can you please help me with the steps and details that needs to be checked before doing maintenance and how to perform maintenance
Hi team,
Can you please help me with the steps and details that needs to be checked before doing maintenance and how to perform maintenance
admin
3,082 Posts
December 10, 2025, 4:41 amQuote from admin on December 10, 2025, 4:41 amCan you tell what sort of maintenance, replace disk ? remove node ? add disk ? ...
Can you tell what sort of maintenance, replace disk ? remove node ? add disk ? ...
uduggireddy
6 Posts
December 10, 2025, 10:07 amQuote from uduggireddy on December 10, 2025, 10:07 amWould like to know the process for disk replacement and also node reboot
Would like to know the process for disk replacement and also node reboot
admin
3,082 Posts
December 10, 2025, 2:02 pmQuote from admin on December 10, 2025, 2:02 pmTo replace a defective OSD, delete it from UI, physically add a new disk, then in UI press + button next to the new disk and add it as OSD.
It is possible to reboot a node without doing any additional actions, since the system is highly available and will deal with failures and recoveries.
But optionally, it is better but not a must:
- Move any paths of services from node to be rebooted to another node. This is not a must, but will make client i/o freeze for a shorter time.
- In UI Maintenance menu, set the no out flag before stopping the node, and return it to normal when node is up. This is not a must, but tells Ceph not to bother initiating a recovery since you know the node will be up soon. However if the node will be down for a long time, do not do this as you do want the normal recovery ( recreating lost replica) to go on.
To replace a defective OSD, delete it from UI, physically add a new disk, then in UI press + button next to the new disk and add it as OSD.
It is possible to reboot a node without doing any additional actions, since the system is highly available and will deal with failures and recoveries.
But optionally, it is better but not a must:
- Move any paths of services from node to be rebooted to another node. This is not a must, but will make client i/o freeze for a shorter time.
- In UI Maintenance menu, set the no out flag before stopping the node, and return it to normal when node is up. This is not a must, but tells Ceph not to bother initiating a recovery since you know the node will be up soon. However if the node will be down for a long time, do not do this as you do want the normal recovery ( recreating lost replica) to go on.
Last edited on December 10, 2025, 2:03 pm by admin · #4
matt
8 Posts
June 15, 2026, 8:08 pmQuote from matt on June 15, 2026, 8:08 pmHello, we recently upgrade from 3.3.0 to 4.0.0 but I was wondering if there is a much more graceful way to handle the reboots. Example
Node1, Node2, Node3 are all "Management" Nodes and where the OSDs are
Node4 and Node5 are "Storage" Nodes that are the iSCSI gateways/paths
Now i wish there was a better way to balance or failover 1 node without manually moving them but for now it is what it is.
However when I rebooted Node1 to boot into ubuntu 22 basically we have VMs locked up and freeze on us and I'm wondering if there is a safer way to move those to not be active or something?
Hello, we recently upgrade from 3.3.0 to 4.0.0 but I was wondering if there is a much more graceful way to handle the reboots. Example
Node1, Node2, Node3 are all "Management" Nodes and where the OSDs are
Node4 and Node5 are "Storage" Nodes that are the iSCSI gateways/paths
Now i wish there was a better way to balance or failover 1 node without manually moving them but for now it is what it is.
However when I rebooted Node1 to boot into ubuntu 22 basically we have VMs locked up and freeze on us and I'm wondering if there is a safer way to move those to not be active or something?
admin
3,082 Posts
June 24, 2026, 4:07 pmQuote from admin on June 24, 2026, 4:07 pmIn the vast majority of cases, if you have client issues or lockups after a node reboot, make sure you have Backfill Speed set to low unless you have fast hardware, in many cases the recovery traffic trying to sync the booted node can have impact on hardware and affect client i/o unless its is controlled to suite your hardware performance.
In the vast majority of cases, if you have client issues or lockups after a node reboot, make sure you have Backfill Speed set to low unless you have fast hardware, in many cases the recovery traffic trying to sync the booted node can have impact on hardware and affect client i/o unless its is controlled to suite your hardware performance.
Steps to perform maintenance on a node in PetaSAN 4.0.0
uduggireddy
6 Posts
Quote from uduggireddy on December 9, 2025, 1:07 pmHi team,
Can you please help me with the steps and details that needs to be checked before doing maintenance and how to perform maintenance
Hi team,
Can you please help me with the steps and details that needs to be checked before doing maintenance and how to perform maintenance
admin
3,082 Posts
Quote from admin on December 10, 2025, 4:41 amCan you tell what sort of maintenance, replace disk ? remove node ? add disk ? ...
Can you tell what sort of maintenance, replace disk ? remove node ? add disk ? ...
uduggireddy
6 Posts
Quote from uduggireddy on December 10, 2025, 10:07 amWould like to know the process for disk replacement and also node reboot
Would like to know the process for disk replacement and also node reboot
admin
3,082 Posts
Quote from admin on December 10, 2025, 2:02 pmTo replace a defective OSD, delete it from UI, physically add a new disk, then in UI press + button next to the new disk and add it as OSD.
It is possible to reboot a node without doing any additional actions, since the system is highly available and will deal with failures and recoveries.
But optionally, it is better but not a must:
- Move any paths of services from node to be rebooted to another node. This is not a must, but will make client i/o freeze for a shorter time.
- In UI Maintenance menu, set the no out flag before stopping the node, and return it to normal when node is up. This is not a must, but tells Ceph not to bother initiating a recovery since you know the node will be up soon. However if the node will be down for a long time, do not do this as you do want the normal recovery ( recreating lost replica) to go on.
To replace a defective OSD, delete it from UI, physically add a new disk, then in UI press + button next to the new disk and add it as OSD.
It is possible to reboot a node without doing any additional actions, since the system is highly available and will deal with failures and recoveries.
But optionally, it is better but not a must:
- Move any paths of services from node to be rebooted to another node. This is not a must, but will make client i/o freeze for a shorter time.
- In UI Maintenance menu, set the no out flag before stopping the node, and return it to normal when node is up. This is not a must, but tells Ceph not to bother initiating a recovery since you know the node will be up soon. However if the node will be down for a long time, do not do this as you do want the normal recovery ( recreating lost replica) to go on.
matt
8 Posts
Quote from matt on June 15, 2026, 8:08 pmHello, we recently upgrade from 3.3.0 to 4.0.0 but I was wondering if there is a much more graceful way to handle the reboots. Example
Node1, Node2, Node3 are all "Management" Nodes and where the OSDs are
Node4 and Node5 are "Storage" Nodes that are the iSCSI gateways/pathsNow i wish there was a better way to balance or failover 1 node without manually moving them but for now it is what it is.
However when I rebooted Node1 to boot into ubuntu 22 basically we have VMs locked up and freeze on us and I'm wondering if there is a safer way to move those to not be active or something?
Hello, we recently upgrade from 3.3.0 to 4.0.0 but I was wondering if there is a much more graceful way to handle the reboots. Example
Node1, Node2, Node3 are all "Management" Nodes and where the OSDs are
Node4 and Node5 are "Storage" Nodes that are the iSCSI gateways/paths
Now i wish there was a better way to balance or failover 1 node without manually moving them but for now it is what it is.
However when I rebooted Node1 to boot into ubuntu 22 basically we have VMs locked up and freeze on us and I'm wondering if there is a safer way to move those to not be active or something?
admin
3,082 Posts
Quote from admin on June 24, 2026, 4:07 pmIn the vast majority of cases, if you have client issues or lockups after a node reboot, make sure you have Backfill Speed set to low unless you have fast hardware, in many cases the recovery traffic trying to sync the booted node can have impact on hardware and affect client i/o unless its is controlled to suite your hardware performance.
In the vast majority of cases, if you have client issues or lockups after a node reboot, make sure you have Backfill Speed set to low unless you have fast hardware, in many cases the recovery traffic trying to sync the booted node can have impact on hardware and affect client i/o unless its is controlled to suite your hardware performance.