On Tue, Sep 11, 2007 at 06:07:44PM -0500, Decibel! wrote:
On Tue, Sep 11, 2007 at 05:09:00PM -0400, Michael Stone wrote:
You can get DAS arrays with multiple controllers, PSUs, etc. DAS !=
single disk.
It's still in the same chassis, though,
I think you're confusing DAS and internal
On Fri, Sep 07, 2007 at 02:10:32PM -0700, [EMAIL PROTECTED] wrote:
3. Easy to set up warm standby functionality. (Then again, if the
postgres server fails miserably, it's likely to be due to a disk
crash).
and if postgres dies for some other reason the image on disk needs repair,
unless
On Tue, Sep 11, 2007 at 03:55:51PM -0500, Decibel! wrote:
Also, to reply to someone else's email... there is one big reason to use
a SAN over direct storage: you can do HA that results in 0 data loss.
Good SANs are engineered to be highly redundant, with multiple
controllers, PSUs, etc, so that
On Tue, Sep 11, 2007 at 05:09:00PM -0400, Michael Stone wrote:
On Tue, Sep 11, 2007 at 03:55:51PM -0500, Decibel! wrote:
Also, to reply to someone else's email... there is one big reason to use
a SAN over direct storage: you can do HA that results in 0 data loss.
Good SANs are engineered to be
On Tue, 11 Sep 2007, Decibel! wrote:
On Tue, Sep 11, 2007 at 05:09:00PM -0400, Michael Stone wrote:
On Tue, Sep 11, 2007 at 03:55:51PM -0500, Decibel! wrote:
Also, to reply to someone else's email... there is one big reason to use
a SAN over direct storage: you can do HA that results in 0
Yeah, the DAS we are considering is Dell MD3000, it has redundant hot
swappable raid controllers in active-active mode. Provision for hot spare
hard-disk. And it can take upto 15 disks in 3U, you can attach two more
MD1000 to it, giving a total of 45 disks in total.
-- Harsh
On 9/12/07, [EMAIL
[Decibel! - Tue at 06:07:44PM -0500]
It's still in the same chassis, though, which means if you lose memory
or mobo you're still screwed. In a SAN setup for redundancy, there's
very little in the way of a single point of failure; generally only the
backplane, and because there's very little
On Fri, Sep 07, 2007 at 12:33:41PM +0200, Tobias Brox wrote:
Advantages:
1. Higher I/O (at least the salesman claims so)
Benchmark it. It is extremely unlikely that you'll get I/O *as good as*
DAS at a similar price point.
2. Easier to upgrade the disk capacity
Is this an issue? You may
We're also considering to install postgres on SAN - that is, my boss is
convinced this is the right way to go.
Advantages:
1. Higher I/O (at least the salesman claims so)
2. Easier to upgrade the disk capacity
3. Easy to set up warm standby functionality. (Then again, if the
postgres server
I'm getting a san together to consolidate my disk space usage for my
servers. It's iscsi based and I'll be pxe booting my servers from it.
The idea is to keep spares on hand for one system (the san) and not have
to worry about spares for each specific storage system on each server.
This also
On Fri, Sep 07, 2007 at 12:26:23AM -0400, Greg Smith wrote:
consider is this: your SAN starts having funky problems, and your
database is down because of it. You call the vendor. They find out
you're running CentOS instead of RHEL and say that's the cause of your
problem (even though it
* Arjen van der Meijden:
The disadvantage of using Areca or 3Ware is obviously the lack of
support in A-brand servers and the lack of support for SAS-disks. Only
recently Areca has stepped in the SAS-market, but I have no idea how
easily those controllers are integrated in standard servers
We are currently running our database against on SAN share. It looks like this:
2 x RAID 10 (4 disk SATA 7200 each)
Raid Group 0 contains the tables + indexes
Raid Group 1 contains the log files + backups (pg_dump)
Our database server connects to the san via iSCSI over Gig/E using
jumbo
On Friday 07 September 2007 10:56, Bryan Murphy
[EMAIL PROTECTED] wrote:
Our database server connects to the san via iSCSI over Gig/E using
jumbo frames. File system is XFS (noatime).
Throughput, however, kinda sucks. I just can't get the kind of
throughput to it I was hoping to get.
A
Bryan Murphy wrote:
Our database server connects to the san via iSCSI over Gig/E using
jumbo frames. File system is XFS (noatime).
...
Throughput, however, kinda sucks. I just can't get the kind of
throughput to it I was hoping to get. When our memory cache is blown,
the database can
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alan Hodgson wrote:
On Friday 07 September 2007 10:56, Bryan Murphy
[EMAIL PROTECTED] wrote:
Our database server connects to the san via iSCSI over Gig/E using
jumbo frames. File system is XFS (noatime).
Throughput, however, kinda sucks. I
On Fri, 7 Sep 2007, Tobias Brox wrote:
We're also considering to install postgres on SAN - that is, my boss is
convinced this is the right way to go.
Advantages:
1. Higher I/O (at least the salesman claims so)
Shockingly, the salesman is probably lying to you. The very concept of
SAN says
On Sep 6, 2007, at 2:42 PM, Scott Marlowe wrote:
I'd recommend against Dell unless you're at a company that orders
computers by the hundred lot. My experience with Dell has been that
unless you are a big customer you're just another number (a small one
at that) on a spreadsheet.
I order
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
On Fri, 7 Sep 2007, Tobias Brox wrote:
We're also considering to install postgres on SAN - that is, my boss is
convinced this is the right way to go.
Advantages:
1. Higher I/O (at least the salesman claims so)
In
On Fri, 7 Sep 2007, Tobias Brox wrote:
We're also considering to install postgres on SAN - that is, my boss is
convinced this is the right way to go.
Advantages:
1. Higher I/O (at least the salesman claims so)
only if you buy better disks for the SAN then for the local system (note
that
Hi,
We are currently running our DB on a DualCore, Dual Proc 3.Ghz Xeon, 8GB
RAM, 4x SAS 146 GB 15K RPM on RAID 5.
The current data size is about 50GB, but we want to purchase the hardware to
scale to about 1TB as we think our business will need to support that much
soon.
- Currently we have a
On 9/6/07, Harsh Azad [EMAIL PROTECTED] wrote:
Hi,
We are currently running our DB on a DualCore, Dual Proc 3.Ghz Xeon, 8GB
RAM, 4x SAS 146 GB 15K RPM on RAID 5.
The current data size is about 50GB, but we want to purchase the hardware to
scale to about 1TB as we think our business will
Thanks Mark.
If I replicate a snapshot of Data and log files (basically the entire PG
data directory) and I maintain same version of postgres on both servers, it
should work right?
I am also thinking that having SAN storage will provide me with facility of
keeping a warm standby DB. By just
On Thu, 2007-09-06 at 18:05 +0530, Harsh Azad wrote:
Hi,
We are currently running our DB on a DualCore, Dual Proc 3.Ghz Xeon,
8GB RAM, 4x SAS 146 GB 15K RPM on RAID 5.
The current data size is about 50GB, but we want to purchase the
hardware to scale to about 1TB as we think our business
Thanks Scott, we have now requested IBM/EMC to provide test machines.
Interestingly since you mentioned the importance of Raid controllers and the
drivers; we are planning to use Cent OS 5 for hosting the DB.
Firstly, I could only find postgres 8.1.x RPM for CentOS 5, could not find
any RPM for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Harsh Azad wrote:
Thanks Scott, we have now requested IBM/EMC to provide test machines.
Interestingly since you mentioned the importance of Raid controllers and the
drivers; we are planning to use Cent OS 5 for hosting the DB.
Firstly, I could
On 6-9-2007 14:35 Harsh Azad wrote:
2x Quad Xeon 2.4 Ghz (4-way only 2 populated right now)
I don't understand this sentence. You seem to imply you might be able to
fit more processors in your system?
Currently the only Quad Core's you can buy are dual-processor
processors, unless you
On 9/6/07, Harsh Azad [EMAIL PROTECTED] wrote:
Thanks Scott, we have now requested IBM/EMC to provide test machines.
Interestingly since you mentioned the importance of Raid controllers and the
drivers; we are planning to use Cent OS 5 for hosting the DB.
What RAID controllers have you looked
Hi,
How about the Dell Perc 5/i card, 512MB battery backed cache or IBM
ServeRAID-8k Adapter?
I hope I am sending relevant information here, I am not too well versed with
RAID controllers.
Regards,
Harsh
On 9/6/07, Scott Marlowe [EMAIL PROTECTED] wrote:
On 9/6/07, Harsh Azad [EMAIL
On Thu, 2007-09-06 at 22:28 +0530, Harsh Azad wrote:
Thanks Mark.
If I replicate a snapshot of Data and log files (basically the entire
PG data directory) and I maintain same version of postgres on both
servers, it should work right?
I am also thinking that having SAN storage will provide
On 9/6/07, Harsh Azad [EMAIL PROTECTED] wrote:
Hi,
How about the Dell Perc 5/i card, 512MB battery backed cache or IBM
ServeRAID-8k Adapter?
All Dell Percs have so far been based on either adaptec or LSI
controllers, and have ranged from really bad to fairly decent
performers. There were
Scott Marlowe wrote:
On 9/6/07, Harsh Azad [EMAIL PROTECTED] wrote:
Hi,
How about the Dell Perc 5/i card, 512MB battery backed cache or IBM
ServeRAID-8k Adapter?
All Dell Percs have so far been based on either adaptec or LSI
controllers, and have ranged from really bad to fairly
I am not sure I agree with that evaluation.
I only have 2 dell database servers and they have been 100% reliable.
Maybe he is referring to support which does tend be up to who you get.
When I asked about performance on my new server they were very helpful but I
did have a bad time on my NAS device
On 6-9-2007 20:42 Scott Marlowe wrote:
On 9/6/07, Harsh Azad [EMAIL PROTECTED] wrote:
Hi,
How about the Dell Perc 5/i card, 512MB battery backed cache or IBM
ServeRAID-8k Adapter?
All Dell Percs have so far been based on either adaptec or LSI
controllers, and have ranged from really bad to
On 6-9-2007 20:29 Mark Lewis wrote:
Maybe I'm jaded by past experiences, but the only real use case I can
see to justify a SAN for a database would be something like Oracle RAC,
but I'm not aware of any PG equivalent to that.
PG Cluster II seems to be able to do that, but I don't know whether
On 9/6/07, Joel Fradkin [EMAIL PROTECTED] wrote:
I am not sure I agree with that evaluation.
I only have 2 dell database servers and they have been 100% reliable.
Maybe he is referring to support which does tend be up to who you get.
When I asked about performance on my new server they were
On Thu, 6 Sep 2007, Harsh Azad wrote:
Firstly, I could only find postgres 8.1.x RPM for CentOS 5, could not find
any RPM for 8.2.4. Is there any 8.2.4 RPM for CentOS 5?
You've already been pointed in the right direction. Devrim, the person who
handles this packaging, does a great job of
37 matches
Mail list logo
