Virtualization vs. sharing a server
Virtualization vs. sharing a server
am 29.03.2010 16:50:01 von Ramiro Barreca
--0016e6d99b98abec8a0482f1a052
Content-Type: text/plain; charset=ISO-8859-1
At this moment we are considering a plan for upgrading many servers in our
datacenter.
As this is a very heterogeneous platform (from Oracle 10g, SQL Server 2008,
Firebird 2.1, Mysql 5, Postgre 8.4 up to Informix 5 and even COBOL apps) whe
are evaluating Virtualization or just sharing a server among PostgreSQL and
firebird or MySQL.
As Virtualiaztion is almost discarded after reading many articles that
locate this option in the "don'ts-list", we want to know your experience (if
any) about installing a PostgreSQL and a Firebird server in the same Linux
server.
Postgre is the DB that we are trying to migrate from Firebird, but this
process will demand several months to conclude.
1. Is there a configuration option we need to consider to share this
server?
2. What is the recomended hardware for a PostgreSQL server that has to
support between 500 and 1000 simultaneous user connections? Is there a
whitepaper about this?
Thanks in advance.
--
Ramiro Barreca
rbarreca@gmail.com
--0016e6d99b98abec8a0482f1a052
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
At this moment we are considering a plan for upgrading many servers in our =
datacenter.
As this is a very heterogeneous platform (from Oracle 10g, =
SQL Server 2008, Firebird 2.1, Mysql 5, Postgre 8.4 up to Informix 5 and ev=
en COBOL apps) whe are evaluating Virtualization or just sharing a server a=
mong PostgreSQL and firebird or MySQL.
As Virtualiaztion is almost discarded after reading many articles that=
locate this option in the "don'ts-list", we want to know you=
r experience (if any) about installing a PostgreSQL and a Firebird server i=
n the same Linux server.
Postgre is the DB that we are trying to migrate from Firebird, but thi=
s process will demand several months to conclude.=A0
=3D"webkit-indent-blockquote" style=3D"margin: 0 0 0 40px; border: none; pa=
dding: 0px;">
- Is there a configuration option we need to consider to=
share this server? - What is the recomended hardware for a PostgreSQ=
L server that has to support between 500 and 1000 simultaneous user connect=
ions? Is there a whitepaper about this?
Thanks in advance.
--
Ramiro Barreca
=3D"mailto:rbarreca@gmail.com">rbarreca@gmail.com
--0016e6d99b98abec8a0482f1a052--
Re: Virtualization vs. sharing a server
am 29.03.2010 17:33:35 von Michael Gould
--b1_f4bb7d2d0bb97154e5c7cb878cc7734a
Content-Type: text/plain; charset = "iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Ramiro,
I don't know why virtualization is considered a no-no.=A0 We use VMware =
ESX.=A0
On some smaller applications we run both the application and database on
the virutal machine.=A0 We've not had a issue with this combination in 5+
years.=A0 We also have 6 images that run on 2 machines just for the
appliations.=A0 Each of these 5 machines is running Windows 2003 Server =
with
Citrix XenAPP.=A0 We do have 2 database servers that are running 2 Quad =
Cores
Intel processors, one with 32 gig and one with 64 gig.=A0 We also have a
couple of old PIII 1 Gig machines running as our AD servers.
Each of the database servers are currently running SQL Anywhere 9 and =
MSSQL
2005.=A0 We've never had a issue.=A0 We keep one server (64 Gig one) as =
our
primary server and the other as a hot backup with auto failover.
If it were not for the virtualized application machines we would have had
to purchase quite a bit more hardware.=A0 Since these are all quad core =
with
32 gig running Windows 2003 64 bit, we can run about 100 users =
concurrently
on each application server before we start to see a strain.
In the past 5 years we've had one time when (when we only 2 physical
servers) and we lost one and the other was able to handle all of the
application needs although much more slowly.
I think that the success of virutalization is like anything else, having
the right people to set it up.=A0 We have no one in our compay to do this
kind of thing so we contract it out to others with platinum =
certifications
from the various vendors (Citrix/ Windows Servers and VMWare).
When we finish our commerical application to production we will probably
contract with EnterpriseDB to help us with tuning Postgres and the =
servers
they run on.
=A0
Best Regards
=A0
--
Michael Gould, Managing Partner
Intermodal Software Solutions, LLC
904.226.0978
904.592.5250 fax
--b1_f4bb7d2d0bb97154e5c7cb878cc7734a
Content-Type: text/html; charset = "iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Ramiro,
I don't know why virtualization is considered a no-no. We use =
VMware ESX. On some smaller applications we run both the =
application and database on the virutal machine. We've not had a =
issue with this combination in 5+ years. We also have 6 images that =
run on 2 machines just for the appliations. Each of these 5 =
machines is running Windows 2003 Server with Citrix XenAPP. We do =
have 2 database servers that are running 2 Quad Cores Intel processors, =
one with 32 gig and one with 64 gig. We also have a couple of old =
PIII 1 Gig machines running as our AD servers.
Each of the database servers are currently running SQL Anywhere 9 and =
MSSQL 2005. We've never had a issue. We keep one server (64 =
Gig one) as our primary server and the other as a hot backup with auto =
failover.
If it were not for the virtualized application machines we would have =
had to purchase quite a bit more hardware. Since these are all quad =
core with 32 gig running Windows 2003 64 bit, we can run about 100 users =
concurrently on each application server before we start to see a =
strain.
In the past 5 years we've had one time when (when we only 2 physical =
servers) and we lost one and the other was able to handle all of the =
application needs although much more slowly.
I think that the success of virutalization is like anything else, =
having the right people to set it up. We have no one in our compay =
to do this kind of thing so we contract it out to others with platinum =
certifications from the various vendors (Citrix/ Windows Servers and =
VMWare).
When we finish our commerical application to production we will =
probably contract with EnterpriseDB to help us with tuning Postgres and =
the servers they run on.
Best Regards
silver;">Michael Gould, Managing Partner
Intermodal Software Solutions, LLC
904.226.0978
904.592.5250 fax
--b1_f4bb7d2d0bb97154e5c7cb878cc7734a--
Re: Virtualization vs. sharing a server
am 29.03.2010 19:09:19 von Greg Smith
Michael Gould wrote:
>
> I don't know why virtualization is considered a no-no...Since these
> are all quad core with 32 gig running Windows 2003 64 bit, we can run
> about 100 users concurrently on each application server before we
> start to see a strain.
>
You answered your own question here. Ramiro is looking for suggestions
for how to scale up to >500 connections at once, and it's not that
likely virtualization can fill any useful role in that context. If
you're happy with 100, sure you can deploy on VMware ESX and have that
work. There are performance vs. manageability tradeoffs when deciding
if virtualized deployment makes sense, and for smaller workloads it's
easy to dismiss the performance side of things as not a limiting factor
and therefore favor VMs.
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com www.2ndQuadrant.us
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Re: Virtualization vs. sharing a server
am 29.03.2010 19:24:55 von Greg Smith
Ramiro Barreca wrote:
>
> 1. Is there a configuration option we need to consider to share
> this server?
>
The two main configuration options that impact how much RAM PostgreSQL
uses are shared_buffers and work_mem. If the server is shared, you just
need to avoid tuning those upwards as far as you would on a dedicated
system. The defaults for both are tiny, so unless you've already pushed
these upwards a lot you're unlikely to have any issues in an initial
deployment.
> 1. What is the recomended hardware for a PostgreSQL server that has
> to support between 500 and 1000 simultaneous user connections?
> Is there a whitepaper about this?
>
The recommendation is "try not to do that". PostgreSQL connections are
fairly expensive, and scaling into hundreds of connections on a single
system tends to break down due to connection creation/teardown
overhead. You should be investigating a connection pooler to put in
between the application and the database, limiting the number of
connections to something much smaller. PgBouncer is most people's first
choice for this scale of database: http://pgfoundry.org/projects/pgbouncer
Once you've gotten past that issue, recommended hardware varies greatly
depending on workload. Read vs. write balance? Size of the critical
working set in RAM? Size of the database? Peak commit rate? Types of
queries executed by the application? It all factors into the decision.
Add in business requirements for reliability and the inevitable vendor
preference, you're likely to end up with a stack of possible
configurations you could consider to sort through. There is no generic
recommendation for larger systems.
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com www.2ndQuadrant.us
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Re: Virtualization vs. sharing a server
am 30.03.2010 23:08:23 von Rodger Donaldson
On Tue, March 30, 2010 06:09, Greg Smith wrote:
> Michael Gould wrote:
>>
>> I don't know why virtualization is considered a no-no...Since these
>> are all quad core with 32 gig running Windows 2003 64 bit, we can run
>> about 100 users concurrently on each application server before we
>> start to see a strain.
>>
>
> You answered your own question here. Ramiro is looking for suggestions
> for how to scale up to >500 connections at once, and it's not that
> likely virtualization can fill any useful role in that context.
That rather depends on your virtualisation layer. We haven't run large P=
G
databases on our zLinux/zVM machines, but we have Oracle DBs running
comparable connection numbers without any issues.
--=20
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Re: Virtualization vs. sharing a server
am 31.03.2010 08:50:51 von Jaume Sabater
On Mon, Mar 29, 2010 at 4:50 PM, Ramiro Barreca wrote:
> As this is a very heterogeneous platform (from Oracle 10g, SQL Server 2008,
> Firebird 2.1, Mysql 5, Postgre 8.4 up to Informix 5 and even COBOL apps) whe
> are evaluating Virtualization or just sharing a server among PostgreSQL and
> firebird or MySQL.
> As Virtualiaztion is almost discarded after reading many articles that
> locate this option in the "don'ts-list", we want to know your experience (if
> any) about installing a PostgreSQL and a Firebird server in the same Linux
> server.
Virtualisation is not a bad option per-se. Just don't expect the same
performance as if it was running on bare metal.
I have a VPS with Xen Hypervisor, 4 GB of RAM at the moment, running
PostgreSQL 8.4, MongoDB and MySQL. No problems at all. The setup
includes LVM, virtual disks are images on real disk. It's working just
fine, but it won't "hold" forever. It's a "cheap" solution at the
moment, affordable and performs very well. But I don't expect it to
perform as if there were no virtualisation layer.
> Is there a configuration option we need to consider to share this server?
> What is the recomended hardware for a PostgreSQL server that has to support
> between 500 and 1000 simultaneous user connections? Is there a whitepaper
> about this?
You definitely want to do connection pooling when possible, or try to
share tables among several database servers to spread the load. 500 up
to 1000 simultaneous connections are very resource consuming, no
matter which hardware you have. Of course it also depends on the type
of application your users are running...
--
Jaume Sabater
http://linuxsilo.net/
"Ubi sapientas ibi libertas"
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Re: Virtualization vs. sharing a server
am 31.03.2010 12:55:11 von Greg Smith
Rodger Donaldson wrote:
> On Tue, March 30, 2010 06:09, Greg Smith wrote:
>
>> You answered your own question here. Ramiro is looking for suggestions
>> for how to scale up to >500 connections at once, and it's not that
>> likely virtualization can fill any useful role in that context.
>>
>
> That rather depends on your virtualisation layer. We haven't run large PG
> databases on our zLinux/zVM machines, but we have Oracle DBs running
> comparable connection numbers without any issues.
>
Connection scaling in Oracle doesn't have the same characteristics as
PostgreSQL, so you can't extrapolate from that. My point was that the
connection target here would be aggressive and difficult to achieve even
without virtualization involved. The virtualization sofware used will
impact the exact percentage of overhead involved, but you'd be hard
pressed to get this to work as hoped even if that number were 0--so
anything >0, even small, is increasing the odds of failure.
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com www.2ndQuadrant.us
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Re: Virtualization vs. sharing a server
am 01.05.2010 18:28:54 von weigelt
* Ramiro Barreca wrote:
> As Virtualiaztion is almost discarded after reading many articles that
> locate this option in the "don'ts-list", we want to know your experience (if
> any) about installing a PostgreSQL and a Firebird server in the same Linux
> server.
Depends on the kind of virtualization. As you're on Linux, you could
use OpenVZ: it has similar characteristics as chroot - it just separates
namespaces (eg. network interfaces, pids, etc) and allows different
limits (eg. maxprocs, maxfiles, maxmem, ...) on per-VZ basis.
BTW: my current customer already consolidated multiple formerly
dedicated mysql servers (in mass hosting) onto one metal (now we're
building a system which allows moving individual databases around
in the cluster w/o being visible to the customer ...). The same
should be easily possible w/ PostgreSQL and other RDBM'es.
cu
--
------------------------------------------------------------ ---------
Enrico Weigelt == metux IT service - http://www.metux.de/
------------------------------------------------------------ ---------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
------------------------------------------------------------ ---------
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin