Wiki

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

The overall goal of this project is to enhance the resource scheduler for the performance optimization, with the information of network and resource isolation.

• Network information monitoring and collection

For the telecommunication applications, besides the number of CPU and memory, the resource scheduler needs much more information of network for resource allocation. The information is listed below:

• The bandwidth and time delay of each plink between the physical hosts
• The physical network topology
• The state of the VLinks already scheduled in the physical network
• …

• Resource Isolation

To provide low call latency, compute capability of VMs must be guaranteed for VNF. Every VM should not interfere with other VMs. However, OpenStack couldn’t isolate compute resources completely at present. Firstly, the NFVI management system may preempt CPU resources from VMs of VNF. Secondly, when two or more VMs may share one core, service processes will affect each other. In above cases, call latency on VMs will be extended and can’t meet carrier-grade requirements.

• Resource allocation optimization

One application usually consists of several VMs and VLinks. The VMs and VLinks may have different resource requirements and constraints. The allocation of the VMs and VLinks should not only obey these requirements and constraints, but also meet the policy of the optimize performance for the system as possible, like minimize the number of the hosts, or load-balance with minimal difference among the hosts, and so on. However, the VM deployment is implemented by Nova-Scheduler of OpenStack via filters and weighting method currently, and can’t guarantee high performance. Even more, the Ceilometer in OpenStack could not get the information of network, so the Nova-Scheduler can’t support the network resource requirements and constraints. If the VMs which need to be allocated simultaneously can be considered together, the performance of the result would be better. So the scheduler needs to be enhanced for multi VM allocation optimizing of this problem. The figure below shows the Resource Scheduling for VNF with some specific policies and deployment constrains. 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, constrains such as VM-VM affinity/anti-affinity, QOS requirement of the VLink, etc. The network information can be getting from the Neutron, Ceilometer, libvert, and even SDN Controller. Then the Scheduler gets the current Host and PLink status, and schedules VM and Host to deploy VNF successfully.

• 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

Specify testing and integration like interoperability, scalability, high availablity

• TBD

What QA and test resources will be available?

• TBD

• Documentation on all functions will be provided.

• 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

• 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)

• Contributors:
  • Zhipeng Huang (HUAWEI: huangzhipeng@huawei.com)
  • Kin-Yip Liu ((Cavium: Kin-Yip.Liu@caviumnetworks.com)

• Describe the project release package as OPNFV or open source upstream projects.
  • Ceilometer project (https://wiki.openstack.org/wiki/Ceilometer ) is the upstream project of this project. It would be aligned with OpenStack release schedule and OPNFV Release 1 schedule.
  • Nova project (https://wiki.openstack.org/wiki/Nova ) is the upstream project of this project. It would be aligned with OpenStack release schedule and OPNFV Release 1 schedule.
• If project deliverables have multiple dependencies across other project categories, described linkage of the deliverables.
  • N/A

• When is the first release planned?
  • March, 2015.
• Will this align with the current release cadence
  • Yes.