(Removed) Preparing Digital Worker for fault tolerance

 Removed in 20.0.3  Before you are ready to move to a production environment, you must prepare your system for fault tolerance by configuring high availability and backing up your data.

1. Configure high availability.

   Kubernetes automatically restarts pods when they crash, but this can take from a few seconds to a couple of minutes. In order to remain available during that time, it is important to have multiple pods for each IBM Automation Digital Worker component. By default, Kubernetes tries to span those pods on different nodes of the cluster to reduce the risk of having two of them failing together.

   1. Define the replicas during the installation. When you install the product, you can define the number of replicas for each component in the custom resource configuration file. Each component has only one replica by default.

      Table 1. Replicas parameters

      Configuration	Description	Default
      designer.replicas	The number of initial pods of Digital Worker Designer in the cluster.	1
      runtime.replicas	The number of initial pods of runtime in the cluster.	1
      management.replicas	The number of initial pods of management in the cluster.	1
      mongodb.replicas	The number of initial pods of MongoDB in the cluster.	1
      npmRegistry.replicas	The number of initial pods of NPM registry in the cluster.	1

   2. After the product is installed, check the number of pods:
      • Digital Worker Designer is a Kubernetes application of the type Deployment. Check the replica of this component with the following command:

        kubectl get deployment -n [namespace]

        For example:

        

      • Others components are Kubernetes applications of the type StatefulSet. Check the replica of these components with the following command:

        kubectl get statefulsets -n [namespace]

        For example:

        

      In the previous examples, you can see two replicas for each component.

   3. Scale services after installation. To scale components after installation, you can update the replicas values in the custom resource configuration file, which is used by the deployment. Use the command kubectl update -f <file>, then the new values are taken into account automatically after several minutes.

      If you need to downscale the runtime, be careful that you must not have tasks in deployment, otherwise the deployment cannot complete. To verify that there are no tasks in deployment, open Digital Worker > Digital worker tasks and check the status of the tasks.

2. Back up data. It is important to back up any data that is stored on the disk so it can be recovered after a disk crash.

   The Kubernetes PersistentVolume API contains the details of the storage implementation, such as the storage server, and the path. It is recommended to use storage with fault tolerance solutions, such as NFS.

   Persistent volumes can be provisioned statically or dynamically:

   • Dynamic volume provisioning allows storage volumes to be created on-demand. Follow the configuration in the custom resource configuration file to define the persistent volume type of each component.
   • Static volume provisioning means that cluster administrators must manually create the storage volumes.

     Table 2. Provisioning parameters

     Parameter	Description
     runtime.persistence.useDynamicProvisioning	Use StorageClasses to dynamically create persistence volumes.
     management.persistence.useDynamicProvisioning	Use StorageClasses to dynamically create persistence volumes.
     mongodb.persistence.useDynamicProvisioning	Use StorageClasses to dynamically create persistence volumes.
     npmRegistry.persistence.useDynamicProvisioning	Use StorageClasses to dynamically create persistence volumes.

     If you use static volume provisioning, you must set the persistence.useDynamicProvisioning to false. With this provisioning option, you must provide a persistent volume declaration configuration during the installation.

   Note: Persistent volumes can have various reclaim policies, including Retain, Recycle, and Delete. If the reclaim policy is Delete, when a user deletes the corresponding persistent volume claim, the dynamically provisioned volume is automatically deleted. It is recommended to use the Retain policy. With this policy, if a user deletes a persistent volume claim, the corresponding persistent volume is not deleted. Instead, it is moved to the Released phase, where all of its data can be manually recovered.