I just started administering our university's LDM server, and my
experience so far has ONLY involved migrating away from our physical
server to running LDM on a virtual machine. I only understand LDM well
enough to have set up a second, virtual server that does everything that
our physical server does...but from my experience the only real concern is
storage access times and what happens when the host server or storage
servers go in to failover.
We run around 100 VM's on three physical hosts with ESX (128gb ram,
4x4x2.5ghz AMD each) and three LeftHand VSA's (iSCSI over 1GB ethernet),
all through a 2gig/sec link. Even with The only time I'm concerned that
running a virtualized instance of our LDM server is when the network RAID
storage needs to be re-striped between two nodes, and we have an
inordinate amount of disk I/O on the backend. Otherwise, even iSCSI
storage with network RAID is fast enough*, even though it is one of the
slower solutions for storage in a virtual environment.
*Fast enough...what does that mean? Myself not being a consumer of the LDM
data, and since the college is fairly unpopulated during the summer...I
can only assume because the load and I/O wait on the physical server is
the same as the virtual server, the VM is performing okay. I'm still not
entirely sure what metrics should be used to judge LDM performance, as the
only complaint I've ever handled with the physical server is "missing
data"...and I don't yet have enough people using our virtual LDM server to
let me know how it's doing..
Bottom line is that the IT staff running the virtual infrastructure should
have an idea of it's limits and be able to monitor if your LDM server is
having an effect on the other virtual machines it is sharing resources
with. They are offering it, and as long as it meets your needs you
shouldn't be concerned...they'll let you know pretty quickly if it's
adversely affecting others. In our case, it's a first come first serve
scenario when it comes to load: since we're running LDM virtualized now,
if other people add virtual servers and increase the load to a point that
it does affect LDM, we'll be looking at the newcomers as "the problem",
even if LDM proportionately uses more resources. It's hard to down the
road say "hey, you can't virtualize LDM any more" if we've already ditched
the hardware...
--Alex Kubacki
System Administrator
College of Science IT
Purdue University
PS - It was also suggested to me to store the product queue in in a
ramdisk to avoid excessive I/O, but I've yet to evaluate that possibility.
On 6/16/11 11:49 AM, "Cotton, Benjamin J" <bcotton@xxxxxxxxxx> wrote:
>Are you on this mailing list? If not, you should join and share your
>experiences with running LDM on a VM.
>
>
>---------- Forwarded message ----------
>From: Gilbert Sebenste <sebenste@xxxxxxxxxxxxxxxxxxxxx>
>Date: Thu, Jun 16, 2011 at 10:07 AM
>Subject: [ldm-users] LDM: Hey, hey, you, you, get onto my cloud
>To: ldm-users@xxxxxxxxxxxxxxxx
>
>
>Hey everyone,
>
>So I am trying to be wooed from our campus IT department to get onto
>their cloud of servers. They say they could put on an any operating
>system that I want,presuming Centos 6.X when it gets released...and if
>so, they talk it to the moon:
>
>Up to 2 TB hard drive space
>20 gigabit/sec throughput as of this fall to the Internet2/NLR
>2 gb/sec to commodity Internet
>24/7 monitoring as of this month
>Now backed up fully by a UPS and a new generator
>3 sources of A/C from 2 rooftop units
>
>Mirrored in two different places in town, one
>on campus, one off-campus, and if one is destroyed,
>I can be back up within 20 minutes
>
>So...has anyone actually done this, and is it worth it? I'm afraid to
>slam everyone else in my "cloud". Or, is Mick Jagger right, should I
>stay
>off of this cloud?
>
>**************************************************************************
>*****
>Gilbert Sebenste
>********
>(My opinions only!)
>******
>Staff Meteorologist, Northern Illinois University
>****
>E-mail: sebenste@xxxxxxxxxxxxxxxxxxxxx
>***
>web: http://weather.admin.niu.edu **
>**************************************************************************
>*****
>
>_______________________________________________
>ldm-users mailing list
>ldm-users@xxxxxxxxxxxxxxxx
>For list information or to unsubscribe, visit:
>http://www.unidata.ucar.edu/mailing_lists/
>
>
>--
>Ben Cotton
>Systems Research Engineer
>IT Research Systems
>Purdue University
