Log in

No account? Create an account

ALOM, Xen, DRBD...

« previous entry | next entry »
Aug. 2nd, 2007 | 02:02 pm

The T1000 is the first Sun I have spent a lot of energy on for a while.

From the hardware side I am both impressed, and is the norm annoyed
with Sun. The T1000 ALOM, aka "Advanced Lights Out Manager", is
sharp. A Solaris sysadmin friend had told me about the feature a
while ago and had explained that its why he had been seeing Linux
shops by Sun hardware.

And why annoyed? Well lets say a single USB port to boot the machine
off of a DVD drive would have been nice when I had to reload the OS.

So what is ALOM? Its a embedded boot console with its own serial
interface and ethernet port. ssh into it, and you can directly
connect to the console of the computer. You can power it up, shut it
down... everything built into one box.

That is sharp.

I've seen a lot of remote console systems, but I've never been that
impressed with them. Most are very expensive and most only do half of
what you need them to do. ALOM does everything I want (and it even
lets you turn on a locator light on the front of the machine!).

So why do I mention Xen in the post? ALOM got me thinking a bit about
Xen. Xen gives me the same sort of functionality as ALOM if setup

I can tell the Xen DOMAIN/0 (aka the xen manager) to use one Ethernet
card, and let the hosted Xen servers use another. I can point the
hosted Xen servers out to the network and leave the xen manager
pointed into a controlled network. Disable SSH on the Xen hosted
machines and I can secure up the Xen hosted machines a bit more.

For access? Use the xen console to talk to the virtual instances.

All of this is pretty nice, though I can see why someone would still
want to pay for Sun Hardware to get ALOM.

An ALOM with Xen like capabilities would be nice.

At this point Xen really looks to be the way to go for
virtualization. I am finding that having multiple Xen domains
running MySQL with DRBD handling the underlying disk structures works

This setup allows for live migrations of a database from host to
host. While it works, I do not know the current hit on performance
during the migration.

It could be a hickup, or a dip, I just do not know.... but the one
test I ran with slap generating data did show that the database
continued to run. Picking a low time in traffic where you can't spare
any downtime, but could spare some performance is viable.

Link | Leave a comment |

Comments {9}

Brian "Krow" Aker

(no subject)

from: krow
date: Aug. 3rd, 2007 04:23 am (UTC)


Keep in mind, me making something happen once, doesn't mean this is ready for production (though I would be surprised if it wasn't).

Reply | Parent | Thread

Artur Bergman

(no subject)

from: crucially
date: Aug. 3rd, 2007 06:29 am (UTC)

If you run DRBD in dual primary mode, then you can run on local devices and still migrate?

Reply | Parent | Thread

Brian "Krow" Aker

(no subject)

from: krow
date: Aug. 7th, 2007 12:32 am (UTC)

My slow response is because I am thinking about the best way to go about this... I'm getting enough pings that I suspect that a number of us want this...

And the dual primary mode is the key.... but I am suddenly wondering if this is really the best way to go about this.

Reply | Parent | Thread

Artur Bergman

(no subject)

from: crucially
date: Aug. 7th, 2007 12:37 am (UTC)

No worries.

As far as I recall, xen makes sure all the data is flushed before it executes the vm move. So in a dual primary mode it should be fine.

Of course, you also need a watchdog that starts it up on the other machine if the active host goes away.

Reply | Parent | Thread

Brian "Krow" Aker

(no subject)

from: krow
date: Aug. 7th, 2007 12:40 am (UTC)

Its calling Sync... the only way I can see being screwed is if you have write cached enabled...

My main thought is just taking old boxed out of commission. Also looking at dynamically being able to increase Innodb's pool (of course... we need to increase the OS as well...).

Reply | Parent | Thread