[openstack-dev] [HA] About next HA Team meeting (VoIP)

Sam P sam47priya at gmail.com
Tue May 17 11:03:03 UTC 2016


Hi All,

 Since no objections raised, HA team VoIP meeting will shift to 9am
UTC 18th May 2016.

Here are the gotomeeting details for the meeting.
1.  Please join the meeting, May 18, 2016 at 18:00 GMT+9 (9am UTC).
https://global.gotomeeting.com/join/424496645
2. You will be connected to audio using your computer's microphone and
speakers (VoIP).  A headset is recommended.
Meeting ID: 424-496-645




I would like to add following topic to agenda.
-------------------------------------------------------
Instance HA API use case

  We consider following use cases need APIs to manage instance HA in operation.
  Detailed specs and database schema can be found at following link.
  https://github.com/ntt-sic/masakari/wiki/Masakari-API-Design

[Failover Segment]
System can be zoned from top to down levels, into Regions,
Availability Zones and Host Aggregates (or Cells). Within those zones,
one or more pacemaker/pacemaker-remote clusters may exist. In addition
to those boundaries, shared storage boundary is also important to
decide the optimal host for fail-over. Openstack zoned boundaries
(such as Regions, AZ, Host Aggregates, etc..) can be managed by the
nova scheduler. However, shared storage boundaries are difficult to
manage. Moreover, the operator may want to use other types of boundary
such as rack layout and powering. Therefore, operator may want to
define the segment of hypervisor hosts and assign the failover
host/hosts for each of them. Those segment can be define based on the
shared storage boundaries or any other limitations may critical for
selection of the failover host.

[Capacity Reservation]
Service provider who ensures an uptime of VM instance to their
customer needs to make sure that the certain amount of host capacity
are reserved to prepare a failure event. If the host capacity of
system is full and the host failure happens, the VM on the failure
host cannot be evacuated to other host. The system capacity is
typically fragmented into segments due to underlying component’s
scalability and each segment has a limited capacity. To increase
resource efficiency, high utilization of host capacity is preferred.
However, as any user consume resources on demand, the host capacity of
each segment tends to reach the full if the system doesn’t provides
the way to reserve the portion of host capacity to the operators.
Therefore, the function to reserve host capacity for failover event is
important to ensure the high availability of VM instance.

[Host Maintenance]
A host has to be temporarily and safely removed from the system for
the maintenance such as hardware failure, firmware update and so on.
During the maintenance, the monitoring function on the host should be
disabled and the monitoring alert from the host should be ignored not
to trigger any recovery action of VM instance on the host if it’s
running. The host should be excluded from reserved hosts as well.
-------------------------------------------------------
--- Regards,
Sampath



On Mon, May 9, 2016 at 8:45 PM, Adam Spiers <aspiers at suse.com> wrote:
> Sam P <sam47priya at gmail.com> wrote:
>> Hi All,
>>
>>  In today's ( 9th May 2016) meeting we agree to skip the next IRC
>> meeting (which is 16th May 2016)  in favour of a gotomeeting VoIP on
>> 18th May 2016 (Wednesday).
>>  Today's meeting logs and summary can be found here.
>>  http://eavesdrop.openstack.org/meetings/ha/2016/ha.2016-05-09-08.04.html
>>
>>  About the meeting Time:
>>  Every one was convenient with 8:00am UTC.
>>  However due to some resource allocation issues, I would like to shift
>> this VoIP meeting to
>>  9am UTC 18th May 2016
>>
>>  Please let me know if you are convenient or not with this time slot.
>
> That later time is fine for me :)  Thanks!
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list