Uploaded image for project: 'OpenShift Request For Enhancement'
  1. OpenShift Request For Enhancement
  2. RFE-2560

Migration from SNO (+1 or 2 workers) to 3 node Compact cluster

XMLWordPrintable

    • Icon: Feature Request Feature Request
    • Resolution: Done
    • Icon: Normal Normal
    • None
    • None
    • None
    • False
    • False
    • 0
    • 0% 0%

      1. Proposed title of this feature request

      Migration from SNO (+1 or 2 workers) to 3 node Compact cluster 

      2. What is the nature and description of the request?

      For certain deployments (e.g. D-RAN DU workloads), over time (e.g. due capacity growth) it is necessary to increase the number of deployed physical cores by expanding an SNO or SNO+worker cluster by adding additional nodes.

      Deployment of three SNOs side by side or SNO+2 workers is sub-optimal because HA of the cluster control plane is required due to the increased size of the cluster increasing the impact of any failure of the cluster control plane.

      Migration from SNO, SNO+worker or SNO+2 workers based clusters to a 3 node Compact cluster or a 3 node Compact cluster + additional worker nodes is required without any impact to service (zero cluster downtime) while preserving any data from the original cluster as part of the migration. 

      For a 3 node Compact cluster a maximum of 2 physical CPU cores (4 HyperThreads) per node (6 physical CPUs / 12 HyperThreads) can be used for RHOCP infrastructure with all remaining CPU cores available for workloads. 

      3. Why does the customer need this? (List the business requirements here)

      As the demands on a SNO (or SNO+1 or 2 workers) cluster increases it is necessary to migrate to a 3 node (or larger) cluster, however:

      • It is not cost optimal for the customer to deploy a 3+ node cluster initially as it results in additional upfront cost compared to deploying a smaller SNO based cluster initially and growing the size of the cluster over time.
      • The existing cluster to be migrated is carrying live traffic / workloads and service downtime to the workload running on the cluster  is not acceptable to the customer.
      • Data from the original original cluster must be preserved during the migration.

       

      4. List any affected packages or components.

            sgordon@redhat.com Steve Gordon
            bnivenje@redhat.com Ben Niven-Jenkins
            Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:
              Resolved: