On Tue, 2007-01-16 at 19:07 +0100, Martin Hierling wrote:
> Hi,
>
> new point for this backup discussion. What if there is a cluster of
> DomU servers sharing a common cluster mountpoint.
> I particular i am using ocfs2.
> Ocfs2 has a network heartbeat and a filesystem heartbeat. By default,
> if the system cant write to the disk for 7 loop (that are 14secs) the
> node self-fences itself and reboots. If i pause such a node, sync it
> (not 100% safe, as read in the other threads), make a lvm snapshot and
> unpause the domain. can this be done in that time?? Andbody did?
> ocfs2 faq about heartbeat:
> http://oss.oracle.com/projects/ocfs2/dist/documentation/ocfs2_faq.html#HEARTBEAT
>
> But thats only the system disk. What about the ocfs2 data volumes.
> While paused another domain could write to the disk!
> But even if that is no problem you can´t mount that snapshot to make a
> backup if the backup node (Dom0) is not in the cluster itself.
The easiest way to do this is bring up a dom-u that has a few block
devices attached :
1 - its own root file system
2 - a LVM or file backed image to store the backup
3 - access to the cluster FS
Use this guest to backup the image, boot it only when needed for
backups. Or, let dom-0 join the cluster. People have reported strange
things when dom-0 is a member of an ocfs2 cluster, depending on the
dom-0 distro and version of ocfs2 its using. In particular, the same
scenario you described, i.e. dom-0 rebooting itself.
This may have been resolved, I really have not kept up on it as I
usually use centralized (and virtualized) storage.
> Dont know about gfs ....
I try to avoid GFS, its over complicated and suffers from some security
risks when using it in a non trusted setting, i.e. non trusted users can
write to the file system.
At last check, if you use a shell script to create 10k random files and
delete them (empty files), its an inode DOS on the entire cluster FS.
ocfs2 allocates inodes in a different way, and doesn't suffer from this
issue. Again, this issue in GFS may have been fixed, my last check
(about 30 days ago) indicated it wasn't, or that packages / updates had
not yet been ported across all distros that yum in the RH cluster
suite.
It would be wise to check on this before using GFS on any cluster that
hosts public sites written in PHP, as one injection allowing the
intruder to exec() could in fact lead to a file system crash.
> only my 2cent, suggestions? has that been discussed?
>
> regards Martin
The best thing you can do is set up a lab, try everything you can think
of that makes sense, and share your findings to save others the hassle
of discovery.
Use plain HTML and proper headings / html tags (xhtml 1.0) so that
Google picks up your findings and folks can find you over those junk
ad-ridden how-to wikis that pop up by the hundred every week.
Best,
--Tim
_______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home