Open Stack

We do not using centralized storages (all instances running with local 
drives). And I just can't express my happiness about this. Every time 
monitoring send me '** PROBLEM ALERT bla-bla-bla', I know it not a big 
deal. Just one server.

I do not want to turn gray prematurely. Just light glance on 
https://www.google.com/search?q=ceph+crash+corruption give me strong 
feeling I don't want to centralize points of failures.

Btw: If I sold nodes designated for Ceph as normal compute nodes, it 
will be more effective than sell only space from them (and buy more 
compute nodes for actual work).

On 01/16/2015 12:31 AM, Abel Lopez wrote:
> That specific bottleneck can be solved by running glance on ceph, and 
> running ephemeral instances also on ceph. Snapshots are a quick 
> backend operation then. But you've made your installation on a house 
> of cards.
>
> On Thursday, January 15, 2015, George Shuklin 
> <george.shuklin at gmail.com <mailto:george.shuklin at gmail.com>> 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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150116/f033f938/attachment.html>