Luke S Crawford wrote:
> "Fajar A. Nugraha" <fajar@xxxxxxxxx> writes:
>
>> With that in mind, it should be easier to simply use snapshot without
>> the need of xm save/restore. It will save some domU "downtime" (the time
>> needed to save and restore domU).
>>
>
> the idea is that 'xm save' saves your ram, including any write-back
> disk cash that has not been flushed. So if I do a 'xm save' and save the
> savefile, and take a bit-for-bit copy of the backing device while the
> domain is still frozen, I should be able to restore the bit-for-bit copy
> of the backing device at some point in the future, and then 'xm restore' the
> savefile I saved, and end up exactly where I was, with no inconsistancies
> or corruptions, as all disk writes that had not been flushed to disk are
> still in ram.
>
> (I can reduce downtime by only taking a snapshot while the domU is down, then
> doing the bit-for-bit copy off the snapshot.)
>
>
Even with snapshot, there's still the time required to "xm save" and "xm
restore". I guess it's more about choice, really.
If I snapshot without xm save-restore, I get a "dirty" filesystem
backup, but services would run as usual. If I do xm save-restore, I get
a "clean" backup, but that also means all services on that domU would be
unavailable for (at least) the duration of xm save-restore. I choose the
first one.
> you want to test
> restoring your backup to another server. A backup that isn't tested is
> no backup at all.
>
>
Good point on that.
>> Another thing to consider, when the question "how to backup domU" arised
>> on this list in the past (and it comes up quite often, search the list
>> archive) I'd generally reply "try using zfs snapshot". Which means :
>> - for backup in domU, you either need an opensolaris or zfs-fuse/linux
>> running on domU
>>
>
> Yeah, that's great if you are using opensolaris in the DomU (or something
> else that supports zfs well) but from what I understand, the linux zfs-fuse
> stuff is pretty slow.
>
>
Not really. zfs-fuse is slow if you let it handle raid (about half
lvm/md throughput). Since I mostly need the snapshot feature, I use
zfs-fuse on top of lvm. Performance-wise, depending on how you use it,
it's similar to ext3. Best case scenario, if you :
- disable checksum
- enable compression
- set application block size to match zfs block size (or vice versa)
you can actually get better read i/o performance (with cpu usage tradeoff).
>> - for backup in dom0, you need opensolaris dom0 (using zfs volume),
>> whatever the OS/fs running on domU.
>>
>
> This does sound interesting, though I haven't tried it.
>
>
I'm using opensolaris snv_98 dom0, and it works fine for the most part.
There are differences from linux dom0 though, like the fact that (for
now) you can't bridge a vlan interface to dom0 (you can only bridge
physical interfaces).
>> Another alternative is to have an opensolaris server exporting zfs
>> volumes via iscsi, have dom0/domU import it, and do all backups on the
>> storage server.
>>
>
> this is also interesting. Software ISCSI is obvously going to be slower
> than native disk, but how much slower? it is an interesting question.
>
>
This thread might give some info
http://mail.opensolaris.org/pipermail/zfs-discuss/2008-October/051749.html
> Right now, all my storage is local to the Dom0, and many hosts have
> excess disk. I've been thinking about exporting the excess disk via iscsi
> or NFS so that customers who want to buy more storage can do so without me
> worrying about balancing the local storage on various Dom0 hosts.
>
> and it would be easy enough to do that from within a OpenSolaris DomU.
>
> the big question in my mind is 'how much of the zfs benifits do I retain
> if I export over iscsi and format the block device ext3?'
>
>
You can get :
- zfs checksum and raidz, which would ensure data integrity (up to the
exported block-level anyway)
- transparent compression. Having compressed ext3 volumes is nice for
certain usage.
- snapshot and clone. Similar to qcow, but with block-device benefits.
> If the dd is causing performance problems, use ionice, and set it to the
> 'idle' class. your backup will be really, really slow but will not
> interfere with other I/O. (I have tested that, and it does seem to work
> as advertised.) Now, you're right about lvm snapshots being slow, so the
> domain being backed up is going to be slow until the backup finishes and the
> snapshot is cleared, but ionice makes a huge difference for the other
> domains on the box.
>
>
Good hint on ionice. At least it can isolate the performance penalty.
Regards,
Fajar
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home