User Tools

Site Tools


requirements_projects:resource_scheduler

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
requirements_projects:resource_scheduler [2015/01/07 03:46]
Zhiqi Wang [Committers and Contributors:]
requirements_projects:resource_scheduler [2015/03/18 02:05] (current)
Mingjiang Li [Planned deliverables]
Line 2: Line 2:
  
   * Proposed name for the project: ''​Resource Scheduler''​   * Proposed name for the project: ''​Resource Scheduler''​
-  * Proposed name for the repository: ''​Resource Scheduler''​+  * Proposed name for the repository: ''​Conductor''​
   * Project Categories: ''​(Requirements)''​   * Project Categories: ''​(Requirements)''​
  
 ==== Project description:​ ==== ==== 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.+The overall goal of this project is to enhance ​the resource scheduler ​for the performance optimization,​ with the information of network and resource isolation
  
-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. ​+  * **Network information monitoring ​and collection**
  
-Secondly, there are certain specific deployment policies and rules applied to the VNFsuch as Min-host-number, ​load-balance,​ optimal-performanceaffinity/​anti-affinity,​ etc+For the telecommunication applicationsbesides the number ​of CPU and memorythe resource scheduler needs much more information of network for resource allocation. Currentlythe function of the OpenStack to monitor and collect information from network is not enough for much applicationsThe information is listed below: 
 +  * The bandwidth and time delay of each physical link between the physical hosts 
 +  * The physical network topology 
 +  * The state of the VLinks already scheduled in the physical network 
 +  * …
  
-Howeverthe Nova-Scheduler ​of OpenStack implements ​VM deployment via filters and weighting method currentlydescribed in the figure below, and can’t meet these specific ​requirements.+  * **Resource Isolation** 
 +{{ :​requirements_projects:​rs_1.png?​450 |}} 
 +To provide low call latencycompute 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 casescall latency on VMs will be extended ​and can’t meet carrier-grade ​requirements.
  
-{{:​requirements_projects:​rs_fig_1.png?700|}}+  * **Resource allocation optimization** 
 +{{ :​requirements_projects:​rs_2.png?550 |}} 
 +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.  
 + 
  
-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. 
- 
-{{:​requirements_projects:​rs_fig_2.png?​700|}} 
 ==== Scope: ==== ==== Scope: ====
-  * Describe ​the problem being solved by project +  * __Describe ​the problem being solved by project__ ​   ​ 
-    ​As a requirements category project, it plans to solve the problem as following:​ +    * 1) Network information monitoring ​and collection 
-      ​* 1) To pre-judge whether the VNF with policies ​and rules could be deployed successfully ​ +      Monitoring ​the physical ​and virtual ​network, ​and collecting ​the corresponding informationincluding ​the bandwidth and time delay of the physical network, the physical topology ​of the network, the VLinks among the VMs which are already scheduled, etc. 
-        Before ​the deployment of VNF, VIM could calculate whether the resource of computing, storage ​and network ​meet the needs of the VNF deployment. If socontinue to deploy ​the VNF; otherwise return failure, instead of deploying VMs one by one until failure. +    2Resource Isolation 
-      * 2) Network resource scheduling implementation +      * When the VNF strictly ​requires ​low latency, the VNF can apply for strongly isolated compute resources. ​For exampleone VM can monopolize some CPU cores and be isolated from other VM.  
-        * 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 8mswhile 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. +      * A guest OS environment with low scheduling latency ​and high-precision timer can be provided for the media-plane VNF to provide fluency voice services. 
-      * 3) VNF Deployment with Specific Policies and Rules +      * Basing on network bandwidth filter, ​The OpenStack can place VM to guarantee sufficient network bandwidth
-        * A) Policies +    * 3) Enhanced scheduler for optimize the performance of the VMs and Vlinks allocation
-          * Min-host-number,​ load-balance,​ event-based policy, etc. +      * Include the network resource, following all the resource requirements and constraints,​ get high performance for the allocation policies in DC. 
-        Brules +      Multi-VM scheduling at the same time for optimization
-          * VM-VM affinity/​anti-affinity,​ VM-HOST affinity/​anti-affinity,​ control/​user plane separation, etc. +      * Other optimization aspect corresponding with nova scheduler.
-      ​* 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+
-         {{:​requirements_projects:​rs_fig_3.png?​700|}} ​           +
-      * 5) System monitoring +
-        Monitoring the real-time resource status, this will be references ​for migration, failover and scaling+
  
-  * Specify ​any interface/​API specification ​proposed+  * __Specify ​any interface/​API specification ​proposed__
     * Nf-vi, Or-Vi, Vi-Vnfm     * Nf-vi, Or-Vi, Vi-Vnfm
  
-  * Specify ​testing and integration:​+  * __Specify ​testing and integration:​__ 
 +    * __Debugging and Tracing:__ N/A 
 +    * __Unit/​Integration Test plans:__ N/A 
 +    * __Client tools developed for status shows etc:__ N/A
  
-  * Debugging and Tracing +  * __Identity ​a list of features and functionality will be developed__ 
- +    * 1) Network information monitoring and collection
-  * Unit/​Integration Test plans +    * 2) The mechanism of resource isolation. 
- +    3) Enhanced scheduler for multi VMs to be scheduling together for high utilization ​of the resource.
-  * 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.+
  
 +  * __Identify what is in or out of scope. So during the development phase, it helps reduce discussion.__
     * In scope:     * In scope:
-      * Unified resource scheduling during VNF deployment +      * Network information collection 
-      * Supporting specific deployment polices and rules during VNF deployment  +      * Resource isolation 
-        *To pre-judge whether the deployment is successful +        * The mechanism of resource isolation ​ 
-           ​To pre-judge whether the VNF could be deployed successfully +      Enhanced scheduler 
-        *Multi-VM scheduling +        * Enhanced scheduler including the information of network 
-           ​* Multi-VM scheduling at the same time +        * Multi-VM scheduling at the same time 
-        *Different deployment policies and rules +        * Other optimization aspect corresponding with nova scheduler
-           * 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     * Out of scope
 +      * Policy Engine
       * Resource Reservation       * Resource Reservation
  
-  * Describe ​how the project is extensible in future +  * __Describe ​how the project is extensible in future__ 
-The following ​features ​will be developed as part of the project. +    * OpenStack Qos will extend ​features ​through its Nova API
-      * 1) Dynamic resource scheduling +    * Resource orchestration implementation ​
-        *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)''​ ==== ==== Testability:​ ''​(optional,​ Project Categories: Integration & Testing)''​ ====
 Specify testing and integration like interoperability,​ scalability,​ high availablity Specify testing and integration like interoperability,​ scalability,​ high availablity
-    * TBD+    * N/A
 What QA and test resources will be available? What QA and test resources will be available?
-    * TBD+    * N/A
 ==== Documentation:​ ''​(optional,​ Project Categories: Documentation)''​ ==== ==== Documentation:​ ''​(optional,​ Project Categories: Documentation)''​ ====
     * Documentation on all functions will be provided.     * Documentation on all functions will be provided.
  
 ==== Dependencies:​ ==== ==== Dependencies:​ ====
 +{{ :​requirements_projects:​rs_3.png?​500 |}}
 +  * Identify similar projects is underway or being proposed in OPNFV or upstream project
 +    * Copper: ​
 +      * The Copper focuses on the policy engine, mostly on how to describe the policy with the policy language, but this project doesn'​t focus on how to implement any single policy. Our project wants to achieve some mechanism and policies, not focus on policy engine.
 +    * Promise: ​
 +      * The Promise focuses on the resourse reservation. However, the network information collection and resource isolation in the resource scheduler project are not the content of the Promise. And the enhanced scheduler considers about the mechanisms above, as well as the performance optimization,​ which is not consider about the resource reservation. ​
  
-  * Identify similar projects is underway or being proposed in OPNFV or upstream project 
-    * TBD 
   * Identify any open source upstream projects and release timeline.  ​   * Identify any open source upstream projects and release timeline.  ​
-    * TBD+    * OpenStack Nova 
 +    * OpenStack Heat 
 +    * OpenStack Neutron 
 +    * OpenStack Ceilometer 
 +    * OpenDayLight 
 +    * KVM
   * Are there any external fora or standard development organization dependencies. If possible, list and informative and normative reference specifications.   * Are there any external fora or standard development organization dependencies. If possible, list and informative and normative reference specifications.
-    * TBD+    * N/A
   * If project is an integration and test, identify hardware dependency.   * If project is an integration and test, identify hardware dependency.
     * This project shall not have any hardware dependency     * This project shall not have any hardware dependency
Line 116: Line 106:
     * Zhiqi Wang (HUAWEI: zhiqi.wang@huawei.com)     * Zhiqi Wang (HUAWEI: zhiqi.wang@huawei.com)
     * Ximing Li (HUAWEI: liximing@huawei.com)     * Ximing Li (HUAWEI: liximing@huawei.com)
-    * Qiao Fu (CMCC: fuqiao@chinamobile.com)+    * Qiao Fu (China Mobile: fuqiao@chinamobile.com) 
 +    * Hao Pang(HUAWEI:​ shamrock.pang@huawei.com) 
 +    * Yimin Wang (HUAWEI: yimin.wang@huawei.com) 
 +    * Qi Liang (HUAWEI: liangqi1@huawei.com) 
 +    * Mingjiang Li (HUAWEI: limingjiang@huawei.com)
  
    
   * Contributors: ​   * Contributors: ​
     * Zhipeng Huang (HUAWEI: huangzhipeng@huawei.com)     * Zhipeng Huang (HUAWEI: huangzhipeng@huawei.com)
 +    * Kin-Yip Liu (Cavium: Kin-Yip.Liu@caviumnetworks.com)
 +    * Ryota Mibu (NEC: r-mibu@cq.jp.nec.com)
  
 ==== Planned deliverables ==== ==== Planned deliverables ====
  
   * Describe the project release package as OPNFV or open source upstream projects.   * 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 projectIt would be aligned ​with OpenStack release schedule and OPNFV Release 1 schedule+    * User requirements ​of OPNFV Resource Scheduler. 
-    * 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.+    * Gap analysis on Resource Scheduler ​with open source upstream projects
 +    * Propose BPs in Nova project (https://​wiki.openstack.org/​wiki/​Nova ) .
   * If project deliverables have multiple dependencies across other project categories, described linkage of the deliverables.   * If project deliverables have multiple dependencies across other project categories, described linkage of the deliverables.
-    * N/A+    * TBD
  
  
Line 134: Line 131:
  
   * When is the first release planned? ​   * When is the first release planned? ​
-    * March, 2015.+    * Gap analysis is planned to be finished in April, 2015. 
 +    * OPNFV resource scheduler software framework architecture (including API specification) is planned to be finished by August, 2015.
   * Will this align with the current release cadence   * Will this align with the current release cadence
     * Yes.     * Yes.
- 
requirements_projects/resource_scheduler.1420602415.txt.gz · Last modified: 2015/01/07 03:46 by Zhiqi Wang