This page was used for initial draft solutions for Scale In.  It has now been deprecated and is no longer up to date.  The latest version can be found on the Dublin Scaling Use Case wiki section.



Scaling Seq Diagram Copy

Scale In Diagram


 

 

 

 

Issues to be resolved

  1. When should scaling be done?
    1. In Dublin our primary reason for scaling will be focused on adjusting resources to the load.  As load increases or decreases, the VNF will scale Out or In as appropriate. This can be done either manually or automatically.
    2. Other reasons for scaling may include:
      1. Upgrades
      2. VM Moves
      3. Meet with Operations to determine other reasons
  2. Which instance should be removed?
    1. How should Policy be involved? (Long term: Policy should query an OOF microservice)
    2. Last In First Out as a temporary solution? (Dublin: will need to query for all instances and then choose)
  3. We need a generic Pre-Action API with a scale in flag to trigger a scale in playbook.  This will allow the VNF to do any VNF specific actions prior to a scale in action

  4. We need a generic Pre-Action API with a scale in flag to trigger a scale in playbook.  This will allow the VNF to do any VNF specific actions prior to a scale in action

    1. In onboarding package vendor needs to say whether or not they support a Pre and Post action
  5. How do we use Distribute_Traffic? 
    1. Distribute_Traffic will move all new traffic
      1. Will need to make Distribute_Traffic work at the VM/VNFC level
    2. Quiesce_traffic can be used for returning a response once all traffic is drained from the target instance
      1. will need to make Quiesce_Traffic work on the VM/VNFC level
  6. Need to build a ConfigScaleIn action and API for APPC and SDNC
  7. Will we be able to use CDS for AutoConfiguration?
  8. How do we determine which controller to use?
  9. STOP VM before Termination
  10. Scale In will release all resources.  It is not guaranteed that the same resources will be reassigned on the next scale out.
  • No labels

6 Comments

  1. Scott Blandford

    To Do Items:

    1. When is Scale In Triggered?
      1. when usage diminishes and resources can be freed up.
      2. For updates/upgrades similar to Build and replace. 
    2. Which component decides which instance is removed? 
      1. OOF Only considers Resource Allocation when making recommendations.  It does not consider service-specific Metrics.
      2. In Dublin this will either have to be a hard coded algorithm such as LIFO or possibly a call to Policy to determine the best choice.
      3. Should a controller make this decision? (APPC Team says controllers do not have this capability)
      4. Manual Scale in can pick which instance through VID.
    3. Do we need a VNF preparation phase so VNFs can execute VNF specific checks and actions?
    4. Can Scale In use Traffic Redistribution to move traffic from instance to be deleted? (Yes 8/21) 
    5. SO Workflow (How much can be done with Work Flow Designer) 
      1. Receive Scale In Trigger
      2. Decide which instance to Scale In
      3. Redistribute traffic with target instance set to 0%
      4. Either wait a configured amount of time or get confirmation that Redistribute has finished
        1. May need to monitor target instance through DCAE and Policy to receive another trigger once the target is no longer receiving traffic
      5. Reconfigure VNF (ConfigScaleIn) (Can we use CDS?) 
        1. Need address of VNF that needs to be configured
        2. Needs configuration parameters, (Which address needs to be removed) 
      6. request to MultiVIM to delete instance and
      7. unassign and reclaim resources 

    Assumptions:

    1. Workflow designer exists
      1. What building blocks will be available in R4?
      2. Can we develop additional building blocks?
      3. Can we intermingle WFD building blocks and traditional BPM workflows? 

    1. Lathishbabu Ganesan

      In the SO wrokflow, Decide which instance to scale in. We could have a mechanism to identify the least traffic instance to ease the traffic migration.

      1. Scott Blandford

        Pamela Dragosh is looking into using Policy to make this comparison and delivering on a flexible policy driven criteria.  I am also going to check with the architecture team to see how they would approach this issue.  In my mind it is really an optimization issue since you might choose based on traffic, # of stream, lowest CPU, oldest version, etc.  If there is no way to easily configure this choice in Dublin then we may want to choose a very simple algorithm (eg. LIFO) in the short term and begin development of a flexible capability for the future.


  2. Lathishbabu Ganesan

    Scale in by modes,

    Brutal:

    When scale in is triggered, it just randomly deletes the instances.

    Graceful:

    Identifying which instance to be deleted and migrate the traffic from and delete it.

    Design a monitoring system to know the traffic at instance level and based on it the decision is made to delete a instance. This is a graceful way of scale in.

    Andrew Fenner, @joss.armstrong@ericsson.com


    1. Scott Blandford

      I think we definitely want to stick with your graceful mode.  We do not want to abandon traffic flows by deleting instance before the traffic has been migrated.

  3. Marco Platania

    Scott Blandford, the sequence diagram for scale in use case strictly reflects the scale out use case sequence diagram that is being implemented for Casablanca. It's a good starting point, but let's keep in mind that components may change for Dublin, so we may need to revisit the chart. For example, if CDS will be fully delivered and usable, then we may not need the SO-Controller payload, because the controller would be able to resolve the scale in parameters via data dictionary.