User Tools

Site Tools


requirements_projects:resource_scheduler

This is an old revision of the document!


Resource Scheduler:

  • Proposed name for the project: Resource Scheduler
  • Proposed name for the repository: Resource Scheduler
  • Project Categories: (Requirements)

Project description:

The overall goal of this project is to ensure the success of VNF deployment to meet specific requirements by means of resource scheduler.

Firstly, there are several VMs in one VNF. Each VM has specific resource requirement, and each VLink between two VMs has corresponding QoS requirement. Once a VM couldn’t be deployed successfully, the VNF deployment fails. Currently, OpenStack doesn’t know whether a VNF could be deployed successfully until all VMs are deployed successfully.

Secondly, there are certain specific deployment policies and rules applied to the VNF, such as Min-host-number, load-balance, optimal-performance, affinity/anti-affinity, etc.

However, the Nova-Scheduler of OpenStack implements VM deployment via filters and weighting method currently, described in the figure below, and can’t meet these specific requirements.

Finally, to provide low call latency and high quality media service, the guest os of IMS VNF requires a real-time running environment. Specifically, the media VNFs also require high accurate system timer so that VNFs can encode media data in a constant frequency to avoid media packet jitter. However, OpenStack couldn’t isolate VNF’s compute resources completely at present so that guest OS can’t be scheduled in real time. For example, the Openstack services in compute nodes may preempt CPU from VNF’s VMs. When two or more VMs share one core, service processes will also affect each other. It is the only way to guarantee VNF’s QoS that NFVI should isolate VNF’s VM from other VNFs and NFVI service.

It’s necessary to enhance OpenStack’s scheduler to support these demands.

The figure below shows the Resource Scheduling for VNF with some specific demands, deployment policies and rules. The VNFM or NFVO request the VNF deployment by Or-Vi or Vi-Vnfm interface. The request contains the compute/storage/network resource each VM needed in the VNF, the deployment policies such as Load Balance, the rules such as VM-VM affinity/anti-affinity, and QOS requirement of the VLink, etc. Then the Scheduler get the Host and PLink real time status, and choose suitable algorithm to schedule VM and Host to deploy VNF successfully.

Scope:

  • Describe the problem being solved by project

As a requirements category project, it plans to solve the problem as following:

  • 1) To pre-judge whether the VNF with policies and rules could be deployed successfully
    • Before the deployment of VNF, VIM could calculate whether the resource of computing, storage and network meet the needs of the VNF deployment. If so, continue to deploy the VNF; otherwise return failure, instead of deploying VMs one by one until failure.
  • 2) Network resource scheduling implementation
    • When deploying VMs, the VIM must figure out the PLink that QoS (such as time-delay, bandwidth, etc.) can meet the VLink requirement. For example, the time-delay requirement of the VLink1-2 between VM1 and VM2 is no more than 8ms, while time-delay of the PLink between HostA and HostB is 15ms. Then VM1 and VM2 can’t be deployed on the HostA and HostB respectively.
  • 3) VNF Deployment with Specific Policies and Rules
    • A) Policies
      • Min-host-number, load-balance, event-based policy, etc.
    • B) rules
      • VM-VM affinity/anti-affinity, VM-HOST affinity/anti-affinity, control/user plane separation, etc.
  • 4) VNF Deployment with VM real-time scheduling requirements
    • When the VNF requires a real-time scheduling environment, the NFVI can provide strongly isolated compute resources. VNF’s VM, can monopolize some CPU cores and be isolated from other VM and NFVI management services. The solution we suggested is showed in the figure below.

  • 5) System monitoring
  • Monitoring the real-time resource status, this will be references for migration, failover and scaling.
  • Specify any interface/API specification proposed
    • Nf-vi, Or-Vi, Vi-Vnfm
  • Specify testing and integration:
  • Debugging and Tracing
  • Unit/Integration Test plans
  • Client tools developed for status shows etc.
  • Identity a list of features and functionality will be developed.
  • Identify what is in or out of scope. So during the development phase, it helps reduce discussion.
  • In scope:
    • Unified resource scheduling during VNF deployment
    • Supporting specific deployment polices and rules during VNF deployment
      • To pre-judge whether the deployment is successful
        • To pre-judge whether the VNF could be deployed successfully
      • Multi-VM scheduling
        • Multi-VM scheduling at the same time
      • Different deployment policies and rules
        • Supporting different deployment policies and rules of VNF deployment
      • Network resource Scheduling
        • Scheduling the network resource for QoS, such as time-delay, bandwidth, etc.
      • System monitoring
        • Real-time resource status monitoring
      • Optimization of resource deployment policies
        • Algorithm to maximize resources usage
        • Algorithm to implement the host work-load Load balancing
        • etc.
  • Out of scope
    • Resource Reservation
  • Describe how the project is extensible in future

The following features will be developed as part of the project.

  • 1) Dynamic resource scheduling
    • When VMs have running for a period of time, the system would not maintain the initial policy, such as load balance. So some running VMs need to be migrated to other hosts by some algorithms, to meet the initial policy.
  • 2) Auto-Scaling
    • Predicting the work-load of current VM by some algorithms, in order to scale out or scale in.
  • 3) Fault handling
    • When a failure happens on one VM or one Host, the VM or all VMs on the Host can be migrated dynamically.
  • 4) Resource orchestration implementation

Testability: ''(optional, Project Categories: Integration & Testing)''

Specify testing and integration like interoperability, scalability, high availablity

  • TBD

What QA and test resources will be available?

  • TBD

Documentation: ''(optional, Project Categories: Documentation)''

  • Documentation on all functions will be provided.

Dependencies:

  • Identify similar projects is underway or being proposed in OPNFV or upstream project
    • TBD
  • Identify any open source upstream projects and release timeline.
    • TBD
  • Are there any external fora or standard development organization dependencies. If possible, list and informative and normative reference specifications.
    • TBD
  • If project is an integration and test, identify hardware dependency.
    • This project shall not have any hardware dependency

Committers and Contributors:

  • Names and affiliations of the committers:
    • Haibo Zhang (HUAWEI: zhanghaibo@huawei.com)
    • Ruopeng Wang (HUAWEI: Ruopeng.Wang@huawei.com)
    • Zhiqi Wang (HUAWEI: zhiqi.wang@huawei.com)
    • Ximing Li (HUAWEI: liximing@huawei.com)
    • Qiao Fu (CMCC: fuqiao@chinamobile.com)

* Any other contributors: TBD

Planned deliverables

  • Describe the project release package as OPNFV or open source upstream projects.
  • If project deliverables have multiple dependencies across other project categories, described linkage of the deliverables.
    • N/A

Proposed Release Schedule:

  • When is the first release planned?
    • March, 2015.
  • Will this align with the current release cadence
    • Yes.
requirements_projects/resource_scheduler.1420340803.txt.gz · Last modified: 2015/01/04 03:06 by Zhiqi Wang