Re: Running PostgreSQL in a Xen DomU?

Lists: pgsql-general
From: Thomas Harold <tgh(at)tgharold(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Running PostgreSQL in a Xen DomU?
Date: 2006-09-14 12:04:38
Message-ID: 45094556.7020603@tgharold.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-general

We're slowly trying to move away from hardware dependence for our
servers and it looks like Xen is the path. Our primary goal is that if
a particular server fails, we can simply migrate the guest OSs to
another Xen node and the users will not experience any downtime. Plus
it should allow us to consolidate a few servers.

Our database needs aren't that great at the moment, less then 50
concurrent users even at the worst of times. But we might have
multi-gigabyte databases that will be queried in bursts and then left
alone for a few days. A single CPU is generally fast enough for us.

So our current thinking is:

- Place PG in a DomU that can be moved from host-to-host as needed

- Backend storage would be over a SAN (iSCSI, 9k jumbo frames, dedicated
NIC or bonded NICs for the SAN, dedicated switch or VLAN for the SAN)

- SAN unit itself would be DRBD'd to a 2nd SAN storage unit. That's
down the road a bit once we build out the first few Xen nodes.

What I'm not sure of:

- Maybe it's better to run PGSQL in Dom0, on 2 different Xen units that
are beefed up, with a few lighter DomU guest OSs running in the
background. Some sort of heartbeat software that allows the 2 Xen units
to grab the PGSQL's IP address as needed.

- Performance of PGSQL in a DomU. What are the gotchas? Do we need to
export PCI NICs to the PGSQL DomU?

(I have a lot of freedom to experiment. As long as services are up and
running and things are stable... We're going from individual machine
with DAS to a more clustered/virtual environment with SAN.)


From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Thomas Harold <tgh(at)tgharold(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Running PostgreSQL in a Xen DomU?
Date: 2006-09-14 14:30:15
Message-ID: 45096777.7050004@commandprompt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-general


> What I'm not sure of:
>
> - Maybe it's better to run PGSQL in Dom0, on 2 different Xen units that
> are beefed up, with a few lighter DomU guest OSs running in the
> background. Some sort of heartbeat software that allows the 2 Xen units
> to grab the PGSQL's IP address as needed.

PostgreSQL performs very, very well on Xen even in DomU. It is one of
the things that lends to the Xen credibility because they use us in
their benchmarks.

>
> - Performance of PGSQL in a DomU. What are the gotchas? Do we need to
> export PCI NICs to the PGSQL DomU?

You will take about a 5% hit over Dom0.

Sincerely,

Joshua D. Drake

>
> (I have a lot of freedom to experiment. As long as services are up and
> running and things are stable... We're going from individual machine
> with DAS to a more clustered/virtual environment with SAN.)
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/


From: Ben <bench(at)silentmedia(dot)com>
To: Thomas Harold <tgh(at)tgharold(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Running PostgreSQL in a Xen DomU?
Date: 2006-09-14 15:33:22
Message-ID: C9ADD948-6DCE-4CB8-A971-AE881B1080AB@silentmedia.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-general

My database needs are probably less than yours, but I've had zero
issues running postgres inside a domU. I'm not using SAN, but instead
DRBD to replicate data at the block level between dom0s. I haven't
tried migrating the domU from one machine to another without
rebooting it, but the shutdown/move/startup process works quite well
for me.

I had some concerns that xen's virtual disk i/o speed wouldn't be
fast enough... but my database performance has never been bad enough
that I had to actually see how fast my domU can do i/o.

On Sep 14, 2006, at 5:04 AM, Thomas Harold wrote:

> We're slowly trying to move away from hardware dependence for our
> servers and it looks like Xen is the path. Our primary goal is
> that if a particular server fails, we can simply migrate the guest
> OSs to another Xen node and the users will not experience any
> downtime. Plus it should allow us to consolidate a few servers.
>
> Our database needs aren't that great at the moment, less then 50
> concurrent users even at the worst of times. But we might have
> multi-gigabyte databases that will be queried in bursts and then
> left alone for a few days. A single CPU is generally fast enough
> for us.
>
> So our current thinking is:
>
> - Place PG in a DomU that can be moved from host-to-host as needed
>
> - Backend storage would be over a SAN (iSCSI, 9k jumbo frames,
> dedicated NIC or bonded NICs for the SAN, dedicated switch or VLAN
> for the SAN)
>
> - SAN unit itself would be DRBD'd to a 2nd SAN storage unit.
> That's down the road a bit once we build out the first few Xen nodes.
>
> What I'm not sure of:
>
> - Maybe it's better to run PGSQL in Dom0, on 2 different Xen units
> that are beefed up, with a few lighter DomU guest OSs running in
> the background. Some sort of heartbeat software that allows the 2
> Xen units to grab the PGSQL's IP address as needed.
>
> - Performance of PGSQL in a DomU. What are the gotchas? Do we
> need to export PCI NICs to the PGSQL DomU?
>
> (I have a lot of freedom to experiment. As long as services are up
> and running and things are stable... We're going from individual
> machine with DAS to a more clustered/virtual environment with SAN.)
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org