glusterfs version3 and xen images

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hallo,

i have tried the new version 3 of glusterfs with xen.

we have 2 gfsserver and 2 xen server. we use client-side-replication with domUs.

i need to know if our configuration is good to use with xen domUs:

server:
# export-domU-images-server_repl
# gfs-01-01 /GFS/domU-images
# gfs-01-02 /GFS/domU-images

volume posix
type storage/posix
option directory /GFS/domU-images
end-volume

volume locks
type features/locks
subvolumes posix
end-volume

volume domU-images
type performance/io-threads
option thread-count 16 # default is 16
subvolumes locks
end-volume

volume server
type protocol/server
option transport-type tcp
option auth.addr.domU-images.allow 192.168.11.*,127.0.0.1
option transport.socket.listen-port 6997
subvolumes domU-images
end-volume

and client:
volume gfs-01-01
type protocol/client
option transport-type tcp
option remote-host gfs-01-01
option transport.socket.nodelay on
option remote-port 6997
option remote-subvolume domU-images
option ping-timeout 7
end-volume

volume gfs-01-02
type protocol/client
option transport-type tcp
option remote-host gfs-01-02
option transport.socket.nodelay on
option remote-port 6997
option remote-subvolume domU-images
option ping-timeout 7
end-volume

volume gfs-replicate
type cluster/replicate
subvolumes gfs-01-01 gfs-01-02
end-volume

volume writebehind
type performance/write-behind
option cache-size 16MB
subvolumes gfs-replicate
end-volume

volume readahead
type performance/read-ahead
option page-count 16 # cache per file = (page-count x page-size)
subvolumes writebehind
end-volume

volume iocache
type performance/io-cache
option cache-size 1GB
option cache-timeout 1
subvolumes readahead
end-volume


i start a domU and simulate an crash on gfs-01-02 (rcnetwork stop; sleep 150; rcnetwork start). domU runs further without any problems.

Client Log:
[2009-12-10 16:34:16] E [client-protocol.c:415:client_ping_timer_expired] gfs-01-02: Server xxx.xxx.xxx.xxx:6997 has not responded in the last 7 seconds, disconnecting. [2009-12-10 16:34:16] E [saved-frames.c:165:saved_frames_unwind] gfs-01-02: forced unwinding frame type(1) op(GETXATTR) [2009-12-10 16:34:16] E [saved-frames.c:165:saved_frames_unwind] gfs-01-02: forced unwinding frame type(2) op(PING) [2009-12-10 16:34:16] N [client-protocol.c:6972:notify] gfs-01-02: disconnected [2009-12-10 16:34:38] E [socket.c:760:socket_connect_finish] gfs-01-02: connection to xxx.xxx.xxx.xxx:6997 failed (No route to host) [2009-12-10 16:34:38] E [socket.c:760:socket_connect_finish] gfs-01-02: connection to xxx.xxx.xxx.xxx:6997 failed (No route to host)

network on gfs-01-02 started

Client Log:
[2009-12-10 16:35:15] N [client-protocol.c:6224:client_setvolume_cbk] gfs-01-02: Connected to xxx.xxx.xxx.xxx:6997, attached to remote volume 'domU-images'. [2009-12-10 16:35:18] N [client-protocol.c:6224:client_setvolume_cbk] gfs-01-02: Connected to xxx.xxx.xxx.xxx:6997, attached to remote volume 'domU-images'. [2009-12-10 16:35:20] E [afr-self-heal-common.c:1186:sh_missing_entries_create] gfs-replicate: no missing files - /vm_disks/virt-template. proceeding to metadata check

everything looks good - sync is started from gfs-01-01 to gfs-01-02 but the whole image were transfered.

if we do a ls -la in domU while the transfer the prompt in domU disappears. After the sync is ready the prompt in domU appears and we can work further.

my question: is this a normal behavoir? in http://ftp.gluster.com/pub/gluster/glusterfs/3.0/LATEST/GlusterFS-3.0.0-Release-Notes.pdf we have read:

2.1) Choice of self-heal algorithms

During self-heal of file contents, GlusterFS will now dynamically choose between two
algorithms based on file size:

a) "Full" algorithm – this algorithm copies the entire file data in order to heal the out-ofsync
copy. This algorithm is used when a file has to be created from scratch on a
server.

b) "Diff" algorithm – this algorithm compares blocks present on both servers and copies only those blocks that are different from the correct copy to the out-of-sync copy. This
algorithm is used when files have to be re-built partially.

The “Diff” algorithm is especially beneficial for situations such as running VM images, where self-heal of a recovering replicated copy of the image will occur much faster because
only the changed blocks need to be synchronized.

can we change the self-heal algorithmus in config file?

Thank you very much

Roland Fischer





[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux