In our FDB cluster configuration, we define two VM (or Kubernetes Pod) templates. One is the Storage template, in which the FDB server processes in this VM (POD) are launched with:
/user/sbin/fdbserver --class storage <other parameters>
that is, they are launched with the storage class specification.
The second template is for Transaction class. The launched processes is with “–class transaction”.
Recently we were doing some resiliency testing by randomly killing pods in the cluster. Then we checked the status.json file and found that a storage VM (pod) has one of the FDB server process being assigned with the role of “log”, even though all of the FDB server processes were launched initially with “–class storage”.
My question: how can a storage process being launched with “–class storage” to become a log process, which is supposed to be from another different class (transaction class)?
The reason that I bring up this question is that we have different CPU/memory/storage settings for the Storage Pods and for the Log/Transaction Pods. If a storage process can be assigned with a “log” role at runtime, the performance might suffer due to different resources allocated to the Pods.