Under what situations can the process initially created with the Storage class become a Log process?

(Jun Li) #1

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.

(gaurav) #2

Please check out this post: Roles / Classes matrix
Specifically, this section from Alex answers your query:

DataDistribution will recruit as many storage servers as it can from processes that match Storage at Unset or better. WorstFit class processes will only be used there are no healthy storage teams left, so we need to make drastic actions to try and restore fault tolerance back to ReplicationFactor copies of data.