How to restart a large-scale training job using OnFailure restart policy about training-operator

[andreyvelich]

@hfwen0502 Did you try to use PyTorchJob Elastic Policy to configure your Job ?
Also, check the PyTorch example with torchrun: https://github.com/kubeflow/training-operator/blob/master/examples/pytorch/cpu-demo/demo.yaml.
Maybe if you run PyTorch in Elastic Mode with torchrun it can successfully restart your failed Worker and resume Training ?

cc @kuizhiqing @johnugeorge @tenzen-y For more info here.

[kuizhiqing]

To be honest, in our production environment to support job with 10k+ GPUs, the un-touched torchrun rendezvous mechanism is not efficient and stable enough (personal point of view, plz tell me if you have good practice for that).

One more thing to indicate would be that RestartPollicy=OnFailure for pod means restart internally with the same node, while I would recommend to delete the failed pod then rescheduler the pod with another node is better, since the physical failure is more frequent than the case which can be recovered by simply restart process.

[hfwen0502]

@hfwen0502 Did you try to use PyTorchJob Elastic Policy to configure your Job ? Also, check the PyTorch example with torchrun: https://github.com/kubeflow/training-operator/blob/master/examples/pytorch/cpu-demo/demo.yaml. Maybe if you run PyTorch in Elastic Mode with torchrun it can successfully restart your failed Worker and resume Training ?

cc @kuizhiqing @johnugeorge @tenzen-y For more info here.

Given that the number of GPUs required in our training jobs typically remains constant within our use cases, we will not be able to take advantage of the elastic policy in this scenario.

[hfwen0502]

To be honest, in our production environment to support job with 10k+ GPUs, the un-touched torchrun rendezvous mechanism is not efficient and stable enough (personal point of view, plz tell me if you have good practice for that).

One more thing to indicate would be that RestartPollicy=OnFailure for pod means restart internally with the same node, while I would recommend to delete the failed pod then rescheduler the pod with another node is better, since the physical failure is more frequent than the case which can be recovered by simply restart process.

Currently, the torchrun rendezvous protocol has been working fine within the current scale of our training jobs. Will keep that in mind when scaling to 10K+ GPU use cases.

Agree with the OnFailure comment. This is actually what I am leading to, whether there can be a new restart policy that will restart the entire training job in an automated fashion. Consider GPU failures occurring in the middle of the night, causing the entire job to become stuck, resulting in significant financial waste with over 1,000 GPUs idling.

[kuizhiqing]

What Andrey suggest is to use torchrun with elastic mode which can enable fault tolerant in pod level, like nnodes=100:100.

The struggling part comes from that the communication library NCCL do not support fault tolerant. It force all worker process should be restart to rebuild communicator after one peer failure. In torch context, the agent is responsible for restart worker processes which may not efficient and stable in large scale. The good news is we can implement our custom Agent to improve it.

[andreyvelich]

This is actually what I am leading to, whether there can be a new restart policy that will restart the entire training job in an automated fashion

I think, that is valid idea. So in such restart policy our controller should re-create all PyTorchJob's pods in case of single Pod failure. What do you think about it @kuizhiqing @tenzen-y @johnugeorge ?

[johnugeorge]

To be honest, in our production environment to support job with 10k+ GPUs, the un-touched torchrun rendezvous mechanism is not efficient and stable enough (personal point of view, plz tell me if you have good practice for that).

One more thing to indicate would be that RestartPollicy=OnFailure for pod means restart internally with the same node, while I would recommend to delete the failed pod then rescheduler the pod with another node is better, since the physical failure is more frequent than the case which can be recovered by simply restart process.

@kuizhiqing Is this a bug? https://github.com/kubeflow/training-operator/blob/master/pkg/controller.v1/common/pod.go#L355 Pod is deleted when restartPolicy is RestartPolicyOnFailure

[tenzen-y]

This is actually what I am leading to, whether there can be a new restart policy that will restart the entire training job in an automated fashion

I think, that is valid idea. So in such restart policy our controller should re-create all PyTorchJob's pods in case of single Pod failure. What do you think about it @kuizhiqing @tenzen-y @johnugeorge ?

@andreyvelich @johnugeorge Indeed, We (WG Batch) are working on resolving these barriers by custom restarting policies triggered by configurable failure and success policies at sig-apps. These features are called JobPodFailurePolicy and [JobSuccessPolicy](KEP is approved, this feature will be published in 1.30 as an alpha).

In this case, the JobPodFailurePolicy could resolve issues since the JobPodFailurePolicy can be configured to determine which errors we should handle actual errors and which actions we should take against each error, like Failure Job or Ignore the Failure.
This is similar to PyTorchJob's restartPolicy with exit-code, but it is more extensible and generic.

Unfortunately, the current training-operator can not support the kubernetes upstream PodFaiurePolicy and JobSuccessPolicy features since it directly manages raw pods and services.

So, I believe that we can remove these barriers once we complete these tasks: #1718