summaryrefslogtreecommitdiffstats
path: root/docs/development/overview/OPNFV_HA_Guest_APIs-Overview_HLD.rst
diff options
context:
space:
mode:
authorfuqiao <fuqiao@chinamobile.com>2017-03-30 09:53:11 +0800
committerfuqiao <fuqiao@chinamobile.com>2017-03-30 09:53:11 +0800
commitbc37f3b74db17b2ca550695c634f0b85e0d700a5 (patch)
tree467fef7ba04c9bf68624221d89ad17af259e47e0 /docs/development/overview/OPNFV_HA_Guest_APIs-Overview_HLD.rst
parent54961e9deb343b3d45d0ae0295729af207ec8451 (diff)
Modify format error in overview doc
Modify format error in overview doc JIRA: HA-28 Change-Id: I580b5ede0457ed5d6f38f03cea8acea6dffa0646 Signed-off-by:fuqiao@chinamobile.com
Diffstat (limited to 'docs/development/overview/OPNFV_HA_Guest_APIs-Overview_HLD.rst')
-rw-r--r--docs/development/overview/OPNFV_HA_Guest_APIs-Overview_HLD.rst128
1 files changed, 64 insertions, 64 deletions
diff --git a/docs/development/overview/OPNFV_HA_Guest_APIs-Overview_HLD.rst b/docs/development/overview/OPNFV_HA_Guest_APIs-Overview_HLD.rst
index e3aee4d..0a0a746 100644
--- a/docs/development/overview/OPNFV_HA_Guest_APIs-Overview_HLD.rst
+++ b/docs/development/overview/OPNFV_HA_Guest_APIs-Overview_HLD.rst
@@ -15,9 +15,9 @@ Overview
:abstract: This document presents a PROPOSAL for a set of new
optional capabilities where the OpenStack Cloud messages
into the Guest VMs in order to provide improved Availability
- of the hosted VMs. The initial set of new capabilities
- include: enabling the detection of and recovery from internal
- VM faults and providing a simple out-of-band messaging service
+ of the hosted VMs. The initial set of new capabilities
+ include: enabling the detection of and recovery from internal
+ VM faults and providing a simple out-of-band messaging service
to prevent scenarios such as split brain.
@@ -44,13 +44,13 @@ Introduction
Interfaces / APIs which are built on a messaging service between the
OpenStack Host and the Guest VM that uses a simple low-bandwidth
datagram messaging capability in the hypervisor and therefore has no
- requirements on OpenStack Networking, and is available very early
+ requirements on OpenStack Networking, and is available very early
after spawning the VM.
For each capability, the document outlines the interaction with
the Guest VM, any key technologies involved, the integration into
- the larger OpenStack and OPNFV Architectures (e.g. interactions
- with VNFM), specific OPNFV HA Team deliverables, and the use cases
+ the larger OpenStack and OPNFV Architectures (e.g. interactions
+ with VNFM), specific OPNFV HA Team deliverables, and the use cases
for how availability of the hosted VM is improved.
The intent is for the OPNFV HA Team to review the proposals of this
@@ -101,9 +101,9 @@ VM Heartbeating and Health Checking
VM Heartbeating and Health Checking provides a heartbeat service to monitor
the health of guest application(s) within a VM running under the OpenStack
Cloud. Loss of heartbeat or a failed health check status will result in a
- fault event being reported to OPNFV's DOCTOR infrastructure for alarm
- identification, impact analysis and reporting. This would then enable VNF
- Managers (VNFMs) listening to OPNFV's DOCTOR External Alarm Reporting through
+ fault event being reported to OPNFV's DOCTOR infrastructure for alarm
+ identification, impact analysis and reporting. This would then enable VNF
+ Managers (VNFMs) listening to OPNFV's DOCTOR External Alarm Reporting through
Telemetry's AODH, to initiate any required fault recovery actions.
.. image:: OPNFV_HA_Guest_APIs-Overview_HLD-Guest_Heartbeat-FIGURE-1.png
@@ -116,14 +116,14 @@ VM Heartbeating and Health Checking
A daemon within the Guest VM will register with the OpenStack Guest
Heartbeat Service on the compute node to initiate the heartbeating on itself
- (i.e. the Guest VM). The OpenStack Compute Node will start heartbeating the
- Guest VM, and if the heartbeat fails, the OpenStack Compute Node will report
+ (i.e. the Guest VM). The OpenStack Compute Node will start heartbeating the
+ Guest VM, and if the heartbeat fails, the OpenStack Compute Node will report
the VM Fault thru DOCTOR and ultimately VNFM will see this thru NOVA VM
State Chagne Notifications thru AODH. I.e. VNFM wouild see the VM Heartbeat
Failure events in teh same way it sees all other VM Faults, thru DOCTOR
initiated VM state changes.
- Part of the Guest VM's registration process is the specification of the
+ Part of the Guest VM's registration process is the specification of the
heartbeat interval in msecs. I.e. the registering Guest VM specifies the
heartbeating interval.
@@ -152,34 +152,34 @@ VM Heartbeating and Health Checking
In summary, the deliverables of this activity would be:
- - Host Deliverables: (OpenStack and OPNFV blueprints and implementation)
+ - Host Deliverables: (OpenStack and OPNFV blueprints and implementation)
- + an OpenStack Nova or libvirt extension to interpret the new flavor extraspec and
- if present setup the required 'virtio serial device' for Host-to-Guest
- heartbeat / health-check messaging, on the QEMU/KVM instance created
- for the VM,
- + an OPNFV Base Host-to-Guest Msging Layer Agent for multiplexing of Application
- Layer messaging over the 'virtio serial device' to the VM,
- + an OPNFV Heartbeat / Health-Check Compute Agent for local heartbeating of VM
- and reporting of failures to the OpenStack Controller,
- + an OPNFV Heartbeat / Health-check Server on the OpenStack Controller for
- receiving VM failure notifications and reporting these to Vitrage thru
- Vitrage's Data Source API,
+ + an OpenStack Nova or libvirt extension to interpret the new flavor extraspec and
+ if present setup the required 'virtio serial device' for Host-to-Guest
+ heartbeat / health-check messaging, on the QEMU/KVM instance created
+ for the VM,
+ + an OPNFV Base Host-to-Guest Msging Layer Agent for multiplexing of Application
+ Layer messaging over the 'virtio serial device' to the VM,
+ + an OPNFV Heartbeat / Health-Check Compute Agent for local heartbeating of VM
+ and reporting of failures to the OpenStack Controller,
+ + an OPNFV Heartbeat / Health-check Server on the OpenStack Controller for
+ receiving VM failure notifications and reporting these to Vitrage thru
+ Vitrage's Data Source API,
- - Guest Deliverables:
+ - Guest Deliverables:
- + a Heartbeat / Health-Check Message Specification covering
-
- - Heartbeat / Health-Check Application Layer JSON Protocol,
- - Base Host-to-Guest JSON Protocol,
- - Details on the use of the underlying 'virtio serial device',
+ + a Heartbeat / Health-Check Message Specification covering
+
+ - Heartbeat / Health-Check Application Layer JSON Protocol,
+ - Base Host-to-Guest JSON Protocol,
+ - Details on the use of the underlying 'virtio serial device',
- + a Reference Implementation of the Guest-side support of
- Heartbeat / Health-check containing the peer protocol layers
- within the Guest.
+ + a Reference Implementation of the Guest-side support of
+ Heartbeat / Health-check containing the peer protocol layers
+ within the Guest.
- - will provide code and compile instructions,
- - Guest will compile based on its specific OS.
+ - will provide code and compile instructions,
+ - Guest will compile based on its specific OS.
This proposal requires review with OPNFV's Doctor and Management & Orchestration
teams, and OpenStack's Nova Team.
@@ -197,7 +197,7 @@ VM Peer State Notification and Messaging
NOTE: A Server Group here is the OpenStack Nova Server Group concept where VMs
are grouped together for purposes of scheduling. E.g. A specific Server Group
- instance can specify whether the VMs within the group should be scheduled to
+ instance can specify whether the VMs within the group should be scheduled to
run on the same compute host or different compute hosts. A 'peer' VM in the
context of this section refers to a VM within the same Nova Server Group.
@@ -234,32 +234,32 @@ VM Peer State Notification and Messaging
In summary, the deliverables for Server Group Messaging would be:
- - Host Deliverables:
-
- + a Nova or libvirt extension to interpret the new flavor extraspec and
- if present setup the required 'virtio serial device' for Host-to-Guest
- Server Group Messaging, on the QEMU/KVM instance created
- for the VM,
- + [ leveraging the Base Host-to-Guest Msging Layer Agent from previous section ],
- + a Server Group Messaging Compute Agent for implementing the Application Layer
- Server Group Messaging JSON Protocol with the VM, and forwarding the
- messages to/from the Server Group Messaging Server on the Controller,
- + a Server Group Messaging Server on the Controller for routing broadcast
- messages to the proper Computes and VMs, as well as listening for Nova
- VM State Change Notifications and forwarding these to applicable Computes
- and VMs,
-
- - Guest Deliverables:
-
- + a Server Group Messaging Message Specification covering
-
- - Server Group Messaging Application Layer JSON Protocol,
- - [ leveraging Base Host-to-Guest JSON Protocol from previous section ],
- - [ leveraging Details on the use of the underlying 'virtio serial device' from previous section ],
-
- + a Reference Implementation of the Guest-side support of
- Server Group Messaging containing the peer protocol layers
- and Guest Application hooks within the Guest.
+ - Host Deliverables:
+
+ + a Nova or libvirt extension to interpret the new flavor extraspec and
+ if present setup the required 'virtio serial device' for Host-to-Guest
+ Server Group Messaging, on the QEMU/KVM instance created
+ for the VM,
+ + [ leveraging the Base Host-to-Guest Msging Layer Agent from previous section ],
+ + a Server Group Messaging Compute Agent for implementing the Application Layer
+ Server Group Messaging JSON Protocol with the VM, and forwarding the
+ messages to/from the Server Group Messaging Server on the Controller,
+ + a Server Group Messaging Server on the Controller for routing broadcast
+ messages to the proper Computes and VMs, as well as listening for Nova
+ VM State Change Notifications and forwarding these to applicable Computes
+ and VMs,
+
+ - Guest Deliverables:
+
+ + a Server Group Messaging Message Specification covering
+
+ - Server Group Messaging Application Layer JSON Protocol,
+ - [ leveraging Base Host-to-Guest JSON Protocol from previous section ],
+ - [ leveraging Details on the use of the underlying 'virtio serial device' from previous section ],
+
+ + a Reference Implementation of the Guest-side support of
+ Server Group Messaging containing the peer protocol layers
+ and Guest Application hooks within the Guest.
This proposal requires review with OPNFV's Management & Orchestration team and
OpenStack's Nova Team.
@@ -271,9 +271,9 @@ Conclusion
The PROPOSAL of Reach-thru Guest Monitoring and Services described in this document
leverage Host-to-Guest messaging to provide a number of extended capabilities
that improve the Availability of the hosted VMs. These new capabilities
- enable detection of and recovery from internal VM faults and provides a simple
+ enable detection of and recovery from internal VM faults and provides a simple
out-of-band messaging service to prevent scenarios such as split brain.
The integration of these proposed new capabilities into the larger OpenStack and OPNFV
- Architectures need to be reviewed with the other related teams in OPNFV (Doctor and
+ Architectures need to be reviewed with the other related teams in OPNFV (Doctor and
Management & Orchestration (MANO)) and OpenStack (Nova).