This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-users] iscsi vs nfs for xen VMs

To: "xen-users@xxxxxxxxxxxxxxxxxxx" <xen-users@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-users] iscsi vs nfs for xen VMs
From: Freddie Cash <fjwcash@xxxxxxxxx>
Date: Wed, 26 Jan 2011 12:15:40 -0800
Delivery-date: Wed, 26 Jan 2011 12:17:23 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=i0XHaq4XUgx8ZM0c0CpR1eDDf9r64N+p5Q1IFDV1dLc=; b=vBKh0amn0AEMFYvJGzYlcOUPhqz6Uk8E8OJzSB0ZvW47Q/Tei0UAteGMSWkU52cUQq xH2SMl+JoxbpaEV2CdeizmPsJd9CEwDELbIRG0Z6nP6Tqv0go7rQXunQBXFVncuPd2CB +85t8UkddM0sJ+3rXwlFrto2v8mv7Des9cqnM=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=DCZWhxgKMHGiIV1IZkEunYVBUFjL001M44gqmekpKCT1ZHWFat38z/t4dXNuHiPnRU 0O/AxSNbyJ7kA24aJbSI1Sz+rh/sU0Zwio/mDG0o5ACGHT4XAagTBs/VQDzYxtR6j0rh FQuOfB1pjjTo5bX37qVwoOe+6URknZGMuF3sA=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4D407E80.1050209@xxxxxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <994429490908070648s69eed40eua19efc43c3eb85a7@xxxxxxxxxxxxxx> <7bc80d500908070700s7050c766g4d1c6af2cd71ea89@xxxxxxxxxxxxxx> <994429490908070711q4c64f92au9baa6577524e5c5d@xxxxxxxxxxxxxx> <3463f63d0908070726y630d320u3e3f1f1cae9b34a4@xxxxxxxxxxxxxx> <sig.0007322cfd.AANLkTi=2S3bKf6jv9BbqYMbkWFbjJTrpYh8GK2EGXGns@xxxxxxxxxxxxxx> <4D3FD940.1090000@xxxxxxxxxxxx> <AANLkTi=J-s+oc44wY-N_wQ+wQr=VhnG-EK48QYpx7y-Y@xxxxxxxxxxxxxx> <5DB0519124BB3D4DBEEB14426D4AC7EA18BFE6FF56@xxxxxxxxxxxxxxxxxxxxx> <sig.40076de9f5.AANLkTim+T5yAfovgX2JsH9BMp3r6agxCqRxVBoG7acXT@xxxxxxxxxxxxxx> <AANLkTi=Nws9ULuk6MjoEJJJLh=zTf9yDJo5HnheX6sie@xxxxxxxxxxxxxx> <4D407E80.1050209@xxxxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
On Wed, Jan 26, 2011 at 12:05 PM, Christian Zoffoli
<czoffoli@xxxxxxxxxxx> wrote:
> Il 26/01/2011 18:11, Freddie Cash ha scritto:
> [cut]
>> If there's anything that we've missed, let me know.  :)
> the exposed setup is very intesting but:
> a) ZFS on freebsd is not as stable as on solaris

But it's plenty stable enough for our uses.  Been using it for over 2
years now, since ZFSv6 hit FreeBSD 7.0.  Once we got over the initial
tuning glitches and upgraded to ZFSv14, things have been rock solid,
even when swapping drives.

> b) opensolaris is dead (oracle killed it)
> c) we have no guarantee that in the future oracle will release updated code

For ZFS?  No, there are no guarantees.  But the Illumos, Nexenta, and
FreeBSD devs won't be sitting still just waiting for Oracle to release
something (look at the removal of the python dependency ZFS
delegations in Illumos, for example).  This may lead to a split in the
future (Oracle ZFS vs OpenZFS).  But that's the future.  ZFSv28 is
available for FreeBSD right now, which supports all the features we're
looking for in ZFS.

> d) NFS is slow ...NFS over RDMA is fast but freebsd has no open/official
> infiniband stack

NFS doesn't have to be slow.

> e) consistent snapshots are very different from backuping only files.
> For example if you backup a DB server copying files is not enought you
> have to dump also what you have in memory at the same time (the key word
> is "at the same time")

Yes, true.  But having a cronjob in the guest (or having the backups
server execute the command remotely) that does a dump of the database
before the backup snapshot is created is pretty darn close to atomic,
and hasn't failed us yet in our restores.  It's not perfect, but so
far, so good.

Compared to the hassle of getting iSCSI live-migration working, and
all the hassles of getting a cluster-aware LVM or FS setup, I'll take
a little drop in raw disk I/O.  :)  Ease of management trumps raw
performance for us (we're only 5 people managing servers for an entire
school district of ~2100 staff and 50 schools).

Freddie Cash

Xen-users mailing list