Open Stack

Directions:
nova->switch port, switch port -> glance, glance->switch port (to 
swift). I assume traffic from switch to swift outside installation.

Glance-api receive and send same amount of traffic. It sounds like a 
minor issue until you starts to count CPU IRQ time of network card 
(doubled compare to a single direction of traffic).

Glance on compute will consume less CPU (because of high performance 
loopback).

On 01/21/2015 07:20 PM, Michael Dorman wrote:
> This is great info, George.
>
> Could you explain the 3x snapshot transport under the traditional Glance
> setup, please?
>
> I understand that you have compute —> glance, and glance —> swift.  But
> what’s the third transfer?
>
> Thanks!
> Mike
>
>
>
>
>
> On 1/21/15, 10:36 AM, "George Shuklin" <george.shuklin at gmail.com> wrote:
>
>> Ok, news so far:
>>
>> It works like a magic. Nova have option
>> [glance]
>> host=127.0.0.1
>>
>> And I do not need to cheat with endpoint resolving (my initial plan was
>> to resolve glance endpoint to 127.0.0.1 with /etc/hosts magic). Normal
>> glance-api reply to external clients requests
>> (image-create/download/list/etc), and local glance-apis (per compute)
>> are used to connect to swift.
>>
>> Glance registry works in normal mode (only on 'official' api servers).
>>
>> I don't see any reason why we should centralize all traffic to swift
>> through special dedicated servers, investing in fast CPU and 10G links.
>>
>> With that solution CPU load on glance-api is distributed evenly on all
>> compute nodes, and overall snapshot traffic (on ports) was cut down 3
>> times!
>>
>> Why I didn't thought about this earlier?
>>
>> On 01/16/2015 12:20 AM, George Shuklin wrote:
>>> Hello everyone.
>>>
>>> One more thing in the light of small openstack.
>>>
>>> I really dislike tripple network load caused by current glance
>>> snapshot operations. When compute do snapshot, it playing with files
>>> locally, than it sends them to glance-api, and (if glance API is
>>> linked to swift), glance sends them to swift. Basically, for each
>>> 100Gb disk there is 300Gb on network operations. It is specially
>>> painful for glance-api, which need to get more CPU and network
>>> bandwidth than we want to spend on it.
>>>
>>> So idea: put glance-api on each compute node without cache.
>>>
>>> To help compute to go to the proper glance, endpoint points to fqdn,
>>> and on each compute that fqdn is pointing to localhost (where
>>> glance-api is live). Plus normal glance-api on API/controller node to
>>> serve dashboard/api clients.
>>>
>>> I didn't test it yet.
>>>
>>> Any ideas on possible problems/bottlenecks? And how many
>>> glance-registry I need for this?
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators