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] streaming server on a virtual machine.

To: "Mauro" <mrsanna1@xxxxxxxxx>
Subject: RE: [Xen-users] streaming server on a virtual machine.
From: Jeff Sturm <jeff.sturm@xxxxxxxxxx>
Date: Sun, 27 Sep 2009 10:39:49 -0400
Cc: xen-users <xen-users@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sun, 27 Sep 2009 07:41:33 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <ab520d140909260242n1e50914cvba5bc5bc0e510701@xxxxxxxxxxxxxx>
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: <ab520d140909180307g31d6c768i8a749509a066354b@xxxxxxxxxxxxxx> <64D0546C5EBBD147B75DE133D798665F03F3EA79@xxxxxxxxxxxxxxxxx> <ab520d140909260242n1e50914cvba5bc5bc0e510701@xxxxxxxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Aco+jatwxmu4a2L3Qr2nzhI2V0/fMAA7WVFg
Thread-topic: [Xen-users] streaming server on a virtual machine.
> -----Original Message-----
> From: Mauro [mailto:mrsanna1@xxxxxxxxx]
> Sent: Saturday, September 26, 2009 5:43 AM
> To: Jeff Sturm
> Cc: xen-users
> Subject: Re: [Xen-users] streaming server on a virtual machine.
> > (Lately we've been doing a lot of physical-to-virtual migrations, and
> > I've found myself asking: "What kinds of servers do we have that should
> > never be virtual?"  There aren't many on that list.)
> >
> You say that a streaming server can be installed on a virtual machine.
> I don't want to create any kind of disturb but I've asked the same
> question to the KVM mailing list and they said that a streaming server
> (I user red5), due to the high I/O traffic, it must absolutely not
> virtualized.

Honestly I know little about streaming servers--I work with database servers 
each day.  If I can guess though that they behave somewhat like a web server 
with large media files, it seems intuitive that:

- Large files will be often read in large sequential chunks; random I/O will be 
- Disk bandwidth usage shouldn't exceed network bandwidth usage (since the 
purpose of reading files from disk is to serve them over rtmp).

Given the latter, assuming common 1Gbps Ethernet is used, it doesn't seem 
likely that you'd need much more than 100MB/s read throughput from your disks 
during peak load.  I know from experience this  is well within the capabilities 
of a paravirtualized Linux guest (on Xen) when the dom0 has a good I/O 
subsystem.  However, if someone who knows red5 far better than I can point on 
the flaws in my simplistic analysis, feel free to tell me I'm out to lunch...

It may also be true this isn't feasible on KVM.  I know even less about KVM 
than streaming servers.  On the surface it appears to be a virtualization 
product architecturally similar to Xen but with hypervisor integrated in 
kernel, and somewhat less mature than Xen.   But if the disk block drivers on 
KVM are paravirtualized as they are in Xen, I don't see why KVM could not reach 
the same I/O performance levels (if not today, then someday).

I also want to point out that using absolutes like "...must absolutely not..." 
doesn't convey any useful information to understand the tradeoffs.  It may or 
may not be a stupid idea to virtualize a streaming server, but I'd bet it is 
certainly possible, if not downright feasible.  Ultimately it comes down to 
cost vs. performance.  The prices of commodity components on the open market 
can fluctuate from day to day, and this is sometimes a bigger factor in a 
buying decision than the capabilities of the technology.

If you have the opportunity to evaluate some solutions, test and quote out a 
few different configurations.  Examples:

1) a farm of physical servers with direct-attached storage
2) a farm of physical servers connected to an iSCSI SAN
3) a farm of virtual servers running on a few large systems with a FC SAN

The first option may be the simplest to configure and operate, but may increase 
your overall storage costs depending on how much storage capacity you require 
and how many servers (bandwidth) are needed.  Option 2 enables sharing files, 
e.g. with NFS or a cluster filesystem, which may reduce the overall storage 
capacity needed, and hence the expense.  Option 3 has the priciest individual 
components, with larger servers and a FC SAN (typically much more expensive 
than iSCSI), but depending on how much you can reduce the number of physical 
nodes needed by sharing RAM/CPU/disk, could actually be cost-effective compared 
to the first two.

What's also interesting here is that 3) may yield higher peak I/O throughput to 
a single server (in spite of virtualization) than either 1) or 2), since 1) is 
limited to the performance of the local disk, and 2) limits per-host throughput 
to the iSCSI network interface or HBA.  I can't speak to your application, but 
it's possible that peak performance is just as important to consider as overall 
aggregate throughput.


Xen-users mailing list