Tag Info

New answers tagged

0

To throw in my $.02: Take a look at ceph. Throw at it half a gigabyte of memory on each server (make them all OSDs) and designate three servers as MDS/MON (depending on the load they may or may not run other intensive stuff as well). Use it as a object storage or as a block device or as a filesystem ... that is up to you ... It can be redundat and it can ...


0

I believe LizardFS and GfarmFS are well suited for the task. Both storage systems use metadata (i.e. directory) servers allowing low-latency operations on millions of files. LizardFS "master" (i.e. metadata server) uses RAM (memory footprint is less than 3 GiB for 7_000_000 files) while GfarmFS metadata server uses PostgreSQL.


0

We have deployed a similiar setup with Atomic (http://www.projectatomic.io/) instead of CoreOS to a replicated non-distributed GlusterFS storage system with three replica-2 sets. This works very well. However, you need to keep a few special characteristics of GlusterFS in mind. Like Brian already mentioned, Gluster places consistency and reliability above ...


2

Assuming you were using replica 3, when 2 hosts go down the file system becomes read-only and this could explain what you currently see to some degree. In most cases we should expect the VM to freeze as qemu cannot write to the storage, but I need some more information about it so log files from the hosts are needed here. First of all let's see that the ...


1

It's a bug This is really a bug (the static-network-up is not a job, it's an event signal). Moreover, using the network job as suggested in other answers is not the most correct solution. So, I created this bug report and submitted a patch to this problem. As a workaround, you can apply my proposed solution (at the end of this answer) and use the _netdev ...



Top 50 recent answers are included