Thanks for the informations Yuan.<br><br>Regards,<br>Joby Xavier<br><br><div class="gmail_quote">On Fri, Apr 20, 2012 at 4:11 PM, Liu Yuan <span dir="ltr"><<a href="mailto:namei.unix@gmail.com">namei.unix@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 04/20/2012 05:56 PM, joby xavier wrote:<br>
<br>
> Hi Yuan,<br>
><br>
> I  tested sheepdog with the following steps<br>
> Total sheep nodes : 5<br>
><br>
>  mount /dev/sda3 /var/lib/sheepdog/<br>
>  mount -o remount,user_xattr /var/lib/sheepdog<br>
>  sheep -d /var/lib/sheepdog<br>
><br>
>  collie cluster format -b farm (only on one node)<br>
><br>
> Then i create sheep volume for iscsi<br>
><br>
>  qemu-img create sheepdog:tom -o preallocation=data 2G<br>
><br>
>  collie vdi list<br>
>   Name        Id    Size    Used  Shared    Creation time   VDI id  Tag<br>
>   tom          1  2.0 GB  2.0 GB  0.0 MB 2012-04-20 14:06   65958b<br>
><br>
> collie node info<br>
> Id    Size    Used    Use%<br>
>  0    20 GB    400 MB      2%<br>
>  1    20 GB    488 MB      2%<br>
>  2    20 GB    300 MB      1%<br>
>  3    20 GB    360 MB      1%<br>
>  4    20 GB    512 MB      2%<br>
> Total    98 GB    2.0 GB      2%<br>
><br>
><br>
> then sharing sheep volumes on two nodes through iscsi tgt<br>
><br>
> tgtadm --op new --mode logicalunit --tid 1 --lun 1 -b tom --bstype sheepdog<br>
><br>
> then, initiator server access iscsi through virtual IP<br>
> starts VM on this iscsi+sheep volume<br>
><br>
> What i see is that even one node fails the os gets crash and gets medium<br>
> errors. I tried both cache=none, writeback<br>
><br>
<br>
<br>
</div></div>Frankly speaking, I have no idea to use sheepdog with iscsi protocol and<br>
never have tried iscsi setup.<br>
<br>
I can only figure out that you separate storage (Sheepdog) from<br>
computing (VM), and in your computing node, there is no any sheep deamon<br>
for routing requests. Because of absence of sheep daemon, you can't take<br>
advantage of object cache, which acts as a local cache that supposed to<br>
reduce the network traffic and data availability.<br>
<br>
Without sheep daemon on the node, 'cache' option for qemu actually<br>
doesn't make any difference.<br>
<br>
Currently, even if you want to run VM in a node that doesn't want to<br>
provide storage to cluster, you can start sheep daemon with<br>
<br>
sheep -v 0<br>
<br>
on the dedicated node, which means you just use sheep as a gateway for<br>
your VM. With this scheme, you can make good use of object cache, live<br>
migration, snapshot, clone features.<br>
<div class="im"><br>
> would you please throw some light on this? please let me know if you<br>
> need any more logs or details. When can we expect the stable version of<br>
> sheepdog?<br>
<br>
<br>
</div>In our usage(node both provide storage and computing), sheepdog acts<br>
quit good in the node fail/join events, with this context, I could say<br>
sheepdog is very close to stable (we need a long running cluster to<br>
prove this).<br>
<div class="im"><br>
> We would like to roll this out to our production servers for high<br>
> availability VMs and storage.<br>
<br>
<br>
</div>There are someone asking to implement sheep client driver into kernel<br>
instead of qemu block layer, exporting a block volume in /dev/sheep_volume.<br>
<br>
We are happy to get patches to implement this feature, but currently we<br>
don't have hands for it.<br>
<br>
I am considering to implement a sheepfs based on FUSE, to both export<br>
sheep internal information (what collie does for now) and export image<br>
block volume (similar to /dev/sheep_volume). But I can't promise when I<br>
can start/finish it, because I am more concerned of scalability. (we<br>
expect to run a cluster more than 1000 nodes)<br>
<br>
Thanks,<br>
Yuan<br>
</blockquote></div><br><br clear="all"><br>