> -----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
limited
- 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.
-Jeff
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home