requirements_projects:resource_scheduler
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
requirements_projects:resource_scheduler [2015/01/14 09:28] Zhiqi Wang [Testability: ''(optional, Project Categories: Integration & Testing)''] |
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)'' | ||
| Line 11: | Line 11: | ||
| * **Network information monitoring and collection** | * **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: | + | For the telecommunication applications, besides the number of CPU and memory, the resource scheduler needs much more information of network for resource allocation. Currently, the function of the OpenStack to monitor and collect information from network is not enough for much applications. The information is listed below: |
| - | * The bandwidth and time delay of each plink between the physical hosts | + | * The bandwidth and time delay of each physical link between the physical hosts |
| * The physical network topology | * The physical network topology | ||
| * The state of the VLinks already scheduled in the physical network | * The state of the VLinks already scheduled in the physical network | ||
| Line 18: | Line 18: | ||
| * **Resource Isolation** | * **Resource Isolation** | ||
| - | {{ :requirements_projects:rs_1.png?300 |}} | + | {{ :requirements_projects:rs_1.png?450 |}} |
| 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. | 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** | * **Resource allocation optimization** | ||
| - | {{ :requirements_projects:rs_2.png?300 |}} | + | {{ :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. | 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. | 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. | ||
| Line 79: | Line 79: | ||
| ==== 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 97: | 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) | + | * 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 project. It 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 116: | 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.1421227734.txt.gz · Last modified: 2015/01/14 09:28 by Zhiqi Wang
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: Creative Commons Attribution 4.0 International License
