summaryrefslogtreecommitdiffstats
path: root/requirements/04-gaps.rst
diff options
context:
space:
mode:
Diffstat (limited to 'requirements/04-gaps.rst')
-rw-r--r--requirements/04-gaps.rst373
1 files changed, 0 insertions, 373 deletions
diff --git a/requirements/04-gaps.rst b/requirements/04-gaps.rst
deleted file mode 100644
index 67ef86c4..00000000
--- a/requirements/04-gaps.rst
+++ /dev/null
@@ -1,373 +0,0 @@
-Gap analysis in upstream projects
-=================================
-
-This section presents the findings of gaps on existing VIM platforms. The focus
-was to identify gaps based on the features and requirements specified in Section
-3.3. The analysis work determined gaps that are presented here.
-
-VIM Northbound Interface
-------------------------
-
-Immediate Notification
-^^^^^^^^^^^^^^^^^^^^^^
-
-* Type: 'deficiency in performance'
-* Description
-
- + To-be
-
- - VIM has to notify unavailability of virtual resource (fault) to VIM user
- immediately.
- - Notification should be passed in '1 second' after fault detected/notified
- by VIM.
- - Also, the following conditions/requirement have to be met:
-
- - Only the owning user can receive notification of fault related to owned
- virtual resource(s).
-
- + As-is
-
- - OpenStack Metering 'Ceilometer' can notify unavailability of virtual
- resource (fault) to the owner of virtual resource based on alarm
- configuration by the user.
-
- - Ceilometer Alarm API:
- http://docs.openstack.org/developer/ceilometer/webapi/v2.html#alarms
-
- - Alarm notifications are triggered by alarm evaluator instead of
- notification agents that might receive faults
-
- - Ceilometer Architecture:
- http://docs.openstack.org/developer/ceilometer/architecture.html#id1
-
- - Evaluation interval should be equal to or larger than configured pipeline
- interval for collection of underlying metrics.
-
- - https://github.com/openstack/ceilometer/blob/stable/juno/ceilometer/alarm/service.py#L38-42
-
- - The interval for collection has to be set large enough which depends on
- the size of the deployment and the number of metrics to be collected.
- - The interval may not be less than one second in even small deployments.
- The default value is 60 seconds.
- - Alternative: OpenStack has a message bus to publish system events.
- The operator can allow the user to connect this, but there are no
- functions to filter out other events that should not be passed to the user
- or which were not requested by the user.
-
- + Gap
-
- - Fault notifications cannot be received immediately by Ceilometer.
-
-Maintenance Notification
-^^^^^^^^^^^^^^^^^^^^^^^^
-
-* Type: 'missing'
-* Description
-
- + To-be
-
- - VIM has to notify unavailability of virtual resource triggered by NFVI
- maintenance to VIM user.
- - Also, the following conditions/requirements have to be met:
-
- - VIM should accept maintenance message from administrator and mark target
- physical resource "in maintenance".
- - Only the owner of virtual resource hosted by target physical resource
- can receive the notification that can trigger some process for
- applications which are running on the virtual resource (e.g. cut off
- VM).
-
- + As-is
-
- - OpenStack: None
- - AWS (just for study)
-
- - AWS provides API and CLI to view status of resource (VM) and to create
- instance status and system status alarms to notify you when an instance
- has a failed status check.
- http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-instances-status-check_sched.html
- - AWS provides API and CLI to view scheduled events, such as a reboot or
- retirement, for your instances. Also, those events will be notified
- via e-mail.
- http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html
-
- + Gap
-
- - VIM user cannot receive maintenance notifications.
-
-* Related blueprints
-
- + https://blueprints.launchpad.net/nova/+spec/service-status-notification
-
-VIM Southbound interface
-------------------------
-
-Normalization of data collection models
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-* Type: 'missing'
-* Description
-
- + To-be
-
- - A normalized data format needs to be created to cope with the many data
- models from different monitoring solutions.
-
- + As-is
-
- - Data can be collected from many places (e.g. Zabbix, Nagios, Cacti,
- Zenoss). Although each solution establishes its own data models, no common
- data abstraction models exist in OpenStack.
-
- + Gap
-
- - Normalized data format does not exist.
-
-OpenStack
----------
-
-Ceilometer
-^^^^^^^^^^
-
-OpenStack offers a telemetry service, Ceilometer, for collecting measurements of
-the utilization of physical and virtual resources [CEIL]_. Ceilometer can
-collect a number of metrics across multiple OpenStack components and watch for
-variations and trigger alarms based upon the collected data.
-
-Scalability of fault aggregation
-________________________________
-
-* Type: 'scalability issue'
-* Description
-
- + To-be
-
- - Be able to scale to a large deployment, where thousands of monitoring
- events per second need to be analyzed.
-
- + As-is
-
- - Performance issue when scaling to medium-sized deployments.
-
- + Gap
-
- - Ceilometer seems to be unsuitable for monitoring medium and large scale
- NFVI deployments.
-
-* Related blueprints
-
- + Usage of Zabbix for fault aggregation [ZABB]_. Zabbix can support a much
- higher number of fault events (up to 15 thousand events per second, but
- obviously also has some upper bound:
- http://blog.zabbix.com/scalable-zabbix-lessons-on-hitting-9400-nvps/2615/
-
- + Decentralized/hierarchical deployment with multiple instances, where one
- instance is only responsible for a small NFVI.
-
-Monitoring of hardware and software
-___________________________________
-
-* Type: 'missing (lack of functionality)'
-* Description
-
- + To-be
-
- - OpenStack (as VIM) should monitor various hardware and software in NFVI to
- handle faults on them by Ceilometer.
- - OpenStack may have monitoring functionality in itself and can be
- integrated with third party monitoring tools.
- - OpenStack need to be able to detect the faults listed in the Annex.
-
- + As-is
-
- - For each deployment of OpenStack, an operator has responsibility to
- configure monitoring tools with relevant scripts or plugins in order to
- monitor hardware and software.
- - OpenStack Ceilometer does not monitor hardware and software to capture
- faults.
-
- + Gap
-
- - Ceilometer is not able to detect and handle all faults listed in the Annex.
-
-* Related blueprints / workarounds
-
- - Use other dedicated monitoring tools like Zabbix or Monasca
-
-Nova
-^^^^
-
-OpenStack Nova [NOVA]_ is a mature and widely known and used component in
-OpenStack cloud deployments. It is the main part of an
-"infrastructure-as-a-service" system providing a cloud computing fabric
-controller, supporting a wide diversity of virtualization and container
-technologies.
-
-Nova has proven throughout these past years to be highly available and
-fault-tolerant. Featuring its own API, it also provides a compatibility API with
-Amazon EC2 APIs.
-
-Correct states when compute host is down
-________________________________________
-
-* Type: 'missing (lack of functionality)'
-* Description
-
- + To-be
-
- - There needs to be API to change VM power_State in case host has failed.
- - There needs to be API to change nova-compute state.
- - There could be single API to change different VM states for all VMs
- belonging to specific host.
- - As external system monitoring the infra calls these APIs change can be
- fast and reliable.
- - Correlation actions can be faster and automated as states are reliable.
- - User will be able to read states from OpenStack and trust they are
- correct.
-
- + As-is
-
- - When a VM goes down due to a host HW, host OS or hypervisor failure,
- nothing happens in OpenStack. The VMs of a crashed host/hypervisor are
- reported to be live and OK through the OpenStack API.
- - nova-compute state might change too slowly or the state is not reliable
- if expecting also VMs to be down. This leads to ability to schedule VMs
- to a failed host and slowness blocks evacuation.
-
- + Gap
-
- - OpenStack does not change its states fast and reliably enough.
- - There is API missing to have external system to change states and to
- trust the states are then reliable (external system has fenced failed
- host).
- - User cannot read all the states from OpenStack nor trust they are right.
-
-* Related blueprints
-
- + https://blueprints.launchpad.net/nova/+spec/mark-host-down
- + https://blueprints.launchpad.net/python-novaclient/+spec/support-force-down-service
-
-Evacuate VMs in Maintenance mode
-________________________________
-
-* Type: 'missing'
-* Description
-
- + To-be
-
- - When maintenance mode for a compute host is set, trigger VM evacuation to
- available compute nodes before bringing the host down for maintenance.
-
- + As-is
-
- - If setting a compute node to a maintenance mode, OpenStack only schedules
- evacuation of all VMs to available compute nodes if in-maintenance compute
- node runs the XenAPI and VMware ESX hypervisors. Other hypervisors (e.g.
- KVM) are not supported and, hence, guest VMs will likely stop running due
- to maintenance actions administrator may perform (e.g. hardware upgrades,
- OS updates).
-
- + Gap
-
- - Nova libvirt hypervisor driver does not implement automatic guest VMs
- evacuation when compute nodes are set to maintenance mode (``$ nova
- host-update --maintenance enable <hostname>``).
-
-Monasca
-^^^^^^^
-
-Monasca is an open-source monitoring-as-a-service (MONaaS) solution that
-integrates with OpenStack. Even though it is still in its early days, it is the
-interest of the community that the platform be multi-tenant, highly scalable,
-performant and fault-tolerant. It provides a streaming alarm engine, a
-notification engine, and a northbound REST API users can use to interact with
-Monasca. Hundreds of thousands of metrics per second can be processed
-[MONA]_.
-
-Anomaly detection
-_________________
-
-
-* Type: 'missing (lack of functionality)'
-* Description
-
- + To-be
-
- - Detect the failure and perform a root cause analysis to filter out other
- alarms that may be triggered due to their cascading relation.
-
- + As-is
-
- - A mechanism to detect root causes of failures is not available.
-
- + Gap
-
- - Certain failures can trigger many alarms due to their dependency on the
- underlying root cause of failure. Knowing the root cause can help filter
- out unnecessary and overwhelming alarms.
-
-* Related blueprints / workarounds
-
- + Monasca as of now lacks this feature, although the community is aware and
- working toward supporting it.
-
-Sensor monitoring
-_________________
-
-* Type: 'missing (lack of functionality)'
-* Description
-
- + To-be
-
- - It should support monitoring sensor data retrieval, for instance, from
- IPMI.
-
- + As-is
-
- - Monasca does not monitor sensor data
-
- + Gap
-
- - Sensor monitoring is very important. It provides operators status
- on the state of the physical infrastructure (e.g. temperature, fans).
-
-* Related blueprints / workarounds
-
- + Monasca can be configured to use third-party monitoring solutions (e.g.
- Nagios, Cacti) for retrieving additional data.
-
-Hardware monitoring tools
--------------------------
-
-Zabbix
-^^^^^^
-
-Zabbix is an open-source solution for monitoring availability and performance of
-infrastructure components (i.e. servers and network devices), as well as
-applications [ZABB]_. It can be customized for use with OpenStack. It is a
-mature tool and has been proven to be able to scale to large systems with
-100,000s of devices.
-
-Delay in execution of actions
-_____________________________
-
-
-* Type: 'deficiency in performance'
-* Description
-
- + To-be
-
- - After detecting a fault, the monitoring tool should immediately execute
- the appropriate action, e.g. inform the manager through the NB I/F
-
- + As-is
-
- - A delay of around 10 seconds was measured in two independent testbed
- deployments
-
- + Gap
-
- - Cause of the delay needs to be identified and fixed
-
-..
- vim: set tabstop=4 expandtab textwidth=80: