[sheepdog-users] Sheepdog 0.9 missing live migration feature

[Liu Yuan]

On Mon, May 11, 2015 at 01:58:07PM +0200, Walid Moghrabi wrote:
> Hi,
> 
> > Sorry for keeping you waiting. I'll backport the patch tonight.
> 
> You're great :D
> 
> > Thanks a lot for your help. But I need to say that journaling and
> > object cache are unstable features. Please don't use them in
> > production.
> 
> Too bad :(
> I was really happy to try this on my setup, I equiped every node with a separated SSD drive on which I was wanting to store Sheepdog journal and/or object cache.
> Why are thse features "unstable" ?
> What are the risks ? In which conditions shouldn't I use them ?
> 
> Unless there is heavy risk, I think I'll still make a try (at least in my crash tests before moving the cluster to production) because it looks promising and anyway, Sheepdog is not considered stable until now and I'm using it with real joy since 0.6 even on production platform so ... ;)
> 
> Anyway, just for my wn curiosity, here is what I'm planning to do for my setup, I'd really appreciate any comment on it :
> 
> 9 nodes with each :
>   - 2 interfaces, one for cluster communication ("main" network) and one dedicated to Sheepdog's replication ("storage" network) with fixed IPs, completely closed and Jumbo frames enabled (mtu 9000)
>   - 3 600Gb SAS 15k dedicated hard drives that are not part of any RAID (standalone drives) that I was thinking using in MD mode
>   - 1 SSD SATA drive (on which the OS resides and that I was thinking to use for Sheepdog's journl and object cache)
> 
> So that means 27 hard drives cluster that I wanted to format using Erasure Code but until now, I don't really now which settings I'll configure for this ... I'd like to find the good balance between performances, security and storage space ... any proposition mostly welcomed.

I'd suggest MD + Object Cache + Dual NICs. Since you make use of Object cache,
no need to open '-n'. Basically, you might take following as an example:

#-w
#256G is just an placeholder, you can adjust on your own. If you found
#performance is not good enough, you can try turn off 'directio', then object
#cache code will take advantage of memory as the cache tier. But this might
#require you to tune some kernel memory flush settings for smooth performance.

#/meta should be put on a raid since it is single point of failure. MD will take
#care of your disk1,disk2,disk3. The "--directio" in the rear means don't use
#memory for backend store. '-n' would be helpful if you find overall performance
#sometimes drops down. '-n' in this case, will affect the performance of object
#cache when it is doing flush-back of the dirty data.

#-c
#for cluster driver, I'd suggest zookeeper

sheep -w size=256G,dir=/path/to/ssd,directio -i 'nic ip for IO' -y 'your main nic ip' \
      /meta,/disk1/disk2,/disk3 -c xxx --directio

Thanks,
Yuan