When doing a rolling upgrade, the upgrade software watches for a node to come back online into the cluster group before moving on to the next node.  There is no equivalent 'watching' in the reboot script.  So there is not a single command one can use for a rolling reboot as you describe. 

You can log in to each node, perform the reboot, verify the node has come back online into the cluster group and then move on to the next node manually.  The following article walks through reboot actions to take.

https://support.emc.com/kb/16535

As for considerations for this kind of reboot, I would say there are 2 categories of consideration.

1. Interruption to active operations.

What kind of traffic is connected to the node as you are rebooting?  Connections to dynamic IP addresses will move automatically during the reboot.  However there could still be impact to actively transferring connections.  What is the tolerance for this kind of interruption?

You have options to drain connections gracefully before rebooting, but this could add significant time to the maintenance window.  You also should schedule the maintenance during a low usage time if at all possible. 

2. Node and journal health.

You are rebooting after 9 months of uptime, which is a reasonable practice.  However there is some minor risk that this could uncover node problems during the boot process.  If something does happen during the boot process, you should contact support immediately for assistance.

However, you can take some preventative steps to verify node and journal health prior to rebooting.  Steps such as pausing any active job engine jobs, checking on current drive status, and manually saving the journal to disk prior to performing the reboot.