[openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..

Sangeeta Singh singhs at yahoo-inc.com
Wed Mar 26 17:47:30 UTC 2014



On 3/26/14, 10:17 AM, "Khanh-Toan Tran" <khanh-toan.tran at cloudwatt.com>
wrote:

>
>
>----- Original Message -----
>> From: "Sangeeta Singh" <singhs at yahoo-inc.com>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>><openstack-dev at lists.openstack.org>
>> Sent: Tuesday, March 25, 2014 9:50:00 PM
>> Subject: [openstack-dev] [nova][scheduler] Availability Zones and Host
>>aggregates..
>> 
>> Hi,
>> 
>> The availability Zones filter states that theoretically a compute node
>>can be
>> part of multiple availability zones. I have a requirement where I need
>>to
>> make a compute node part to 2 AZ. When I try to create a host aggregates
>> with AZ I can not add the node in two host aggregates that have AZ
>>defined.
>> However if I create a host aggregate without associating an AZ then I
>>can
>> add the compute nodes to it. After doing that I can update the
>> host-aggregate an associate an AZ. This looks like a bug.
>> 
>> I can see the compute node to be listed in the 2 AZ with the
>> availability-zone-list command.
>> 
>
>Yes it appears a bug to me (apparently the AZ metadata indertion is
>considered as a normal metadata so no check is done), and so does the
>message in the AvailabilityZoneFilter. I don't know why you need a
>compute node that belongs to 2 different availability-zones. Maybe I'm
>wrong but for me it's logical that availability-zones do not share the
>same compute nodes. The "availability-zones" have the role of partition
>your compute nodes into "zones" that are physically separated (in large
>term it would require separation of physical servers, networking
>equipments, power sources, etc). So that when user deploys 2 VMs in 2
>different zones, he knows that these VMs do not fall into a same host and
>if some zone falls, the others continue working, thus the client will not
>lose all of his VMs. It's smaller than Regions which ensure total
>separation at the cost of low-layer connectivity and central management
>(e.g. scheduling per region).

    The need arises when you need a way to use both the zones to be used
for scheduling when no specific zone is specified. The only way to do that
is either have a AZ which is a superset of the two AZ or the other way
could be if the default_scheduler_zone can take a list of zones instead of
just 1.  
>
>See: http://www.linuxjournal.com/content/introduction-openstack
>
>The former purpose of regouping hosts with the same characteristics is
>ensured by host-aggregates.
>
>> The problem that I have is that I can still not boot a VM on the
>>compute node
>> when I do not specify the AZ in the command though I have set the
>>default
>> availability zone and the default schedule zone in nova.conf.
>> 
>> I get the error ³ERROR: The requested availability zone is not
>>available²
>> 
>> What I am  trying to achieve is have two AZ that the user can select
>>during
>> the boot but then have a default AZ which has the HV from both AZ1 AND
>>AZ2
>> so that when the user does not specify any AZ in the boot command I
>>scatter
>> my VM on both the AZ in a balanced way.
>> 
>
>I do not understand your goal. When you create two availability-zones and
>put ALL of your compute nodes into these AZs, then if you don't specifies
>the AZ in your request, then AZFilter will automatically accept all hosts.
>The defaut weigher (RalWeigher) will then distribute the workload fairely
>among these nodes regardless of AZ it belongs to. Maybe it is what you
>want?
>
>> Any pointers.
>> 
>> Thanks,
>> Sangeeta
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




More information about the OpenStack-dev mailing list