[Deploying Sakai] Sakai Database migrating to VM server

David Adams da1 at vt.edu
Fri Mar 15 12:56:19 PDT 2013

Agreed. We've found that moving our databases (for any of our apps, not
just Sakai) to VMs has caused far more problems than it was intended to
solve. Not just performance overhead, but issues with interfacing with
external systems. Unexplained network jitters and SAN fiber connection
drops to name a couple. Plus even if you have the same CPU and RAM
allocated in the VM environment, unless you are on a dedicated host with
just the single VM, you *will* run into contention unless the other VMs
have truly trivial workloads.

IMO, VMs are ill suited for high-peak workloads that need to squeeze
every iota of performance out of the hardware, at least on a monolithic
architecture like Sakai, with one database server being the bottleneck
for every operation in the system from auth to events to clustering to
data storage to search, stats, and warehousing.

Be sure to ask your admins if they intend to make use of any "live
migration" features. Sakai on Oracle in particular doesn't get along
with network connections that don't respond while the "transparent"
server migration is occurring. We've had multiple incidents where our
apps went down because the sysadmins believed the marketing copy, and
live-migrated our DB server during peak usage times because it was
"supposed to be transparent".

Those are just a few things to watch out for. In our environment, we
switched our production Sakai off VMs and onto physical hardware as
soon as we had the opportunity, and we've never looked back. Honestly,
these days with the excellent config management software out there,
there's no reason why you can't get all the same deployment and
management benefits of virtualization while still running certain
high-demand hosts on bare metal.


Sam Ottenhoff wrote:
> Well, you just added a large layer between your database server and a real
> disk.  A degradation of 10% seems pretty normal and expected.  Around 20%
> and I believe there's probably room for painstaking IO optimization work.
> But unless you have the ability to read/write from native disk, I don't
> think you can ever expect to go back to native disk performance.
> --Sam
> On Fri, Mar 15, 2013 at 9:18 AM, Liu, Peter <peter.liu at yale.edu<mailto:peter.liu at yale.edu>> wrote:
> Hi,
> Has any school been running the Sakai Database server on a VM machine?  We are planning to move our Oracle database from a stand-alone server to a VM environment with the same Memory: 24G and CPU: 8.
> However, our load tests show us some performance degrading by 10 to 20 percent from user’s perspective.  There are so many factors, which  can affect the overall performance such as the network I/O etc. in the VM world.
> Can you share any light on this one?
> Many thanks!
> Peter Liu
> _______________________________________________
> production mailing list
> production at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/production
> TO UNSUBSCRIBE: send email to production-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"

More information about the production mailing list