SUMMARY: V440 small DATABASE SERVER

• Previous message: ktn: "Re: help! picld error - is it a hardware issue?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Fri, 11 Jun 2004 16:10:45 +0100
To: Sun Managers <sunmanagers@sunmanagers.org>

Hi gurus

Many thanks to every one who replied, the general concensus was that the
V440 would be up to the job although there was concern about only
utilising 2 disks in a RAID volume for the actual DB but that this
shouldnt really be a problem if most of the load is read biased and low
activity (since most users will be call centre based accessing customer
demographic information) also that the primary DB would only be 10-20GB
in size.

One person (Gary Chambers) suggested that you could attach a small single
pak drive for the OS (rootdg) to the external SCSI controller and boot
off this leaving the internal drives for the DB in a nice RAID
arrangement, or mirror the Solaris FS with Sun Volume Manager and the
rest with VxVM to ease OS upgrades.

We had the option of going for a 2xV440 with DB replication setup or
2xV880's, even though one was recommended with the multipathing option,
the company preferred the safety of a second failover system - completely
dedicated to the client.

Replies follow, thanks again.

----------------------------------------------------------------------------------

Based on what you have told me, I think you'll have a nicely
configurable and scalable database server, but I'm still a bit
apprehensive about how few disks you're using. I'm unfamiliar with a
PICK variant database, so your mileage with my "advice" may vary. It's
great that you're the DBA and sysadmin.

What I'd do (and have done in the past) is attach to the external SCSI

controller a small (single-pak) disk drive to use as rootdg. It's out
of the way, isn't an I/O bottleneck, and it satisfies Veritas' rootdg
requirements. As an added step to ease OS upgrades, mirror the Solaris
filesystems with Solaris Volume Manager (SVM), formerly (in Solaris 8
and below) Solaris DiskSuite. You can then use VxVM on the remaining
drives for the database disk group.

Gary Chambers

----------------------------------------------------------------------------------

Great boxes, sell very well. All database boxes we sell will typically
have external storage.

The V440 does have Ultra320 drives though, which are faster than a lot of
the 3310 strorage arrays that are often attached to the V440 for database
configs - that said, the 3310 would usually be configured with 0+1.

Bear in mind too that most Microsoft users would use internal disks in a
RAID 5 conig, from what I've seen, so using your internal drives may well
be fine!

Chris

----------------------------------------------------------------------------------
        My shop has about 20-25 V440's in production right now. They are
great little systems for what you pay. We use them for medium intensive
oracle and sybase database servers and various applications. All attached
to SAN.

        Basically, unless its a compute intesive application (like
linear alg type math functions in geo-seismic) the V440's work fine. We
use Linux on Xeon Compaq systems when we want raw horsepower.

        HTH,

        Chris Price
----------------------------------------------------------------------------------
This is one of the good products. I have deployed few of these as DB (
sybase ) servers - I boot off of the internal disks. So far so good.

This is our solution to replace E4500 ( 12 x12 ). ( not an upgrade ) .

I have these 4x16gb and hooked up to our San with emulex cards. My largest
server currently houses a data base of 118gb ( total space is 270gb )

Hope this is helpful

navi
----------------------------------------------------------------------------------
D1000's are about $250+drive cost + differential controller. Also, that box
can be split and shared between two servers.

Kris
----------------------------------------------------------------------------------

Martin,

I have on experience w/ V440's, but for 200users they should handle DB's
w/o much problem (Oracle?).

Since you only have 4 disks, you're limited in the setup you have. There
isn't much to advice, you'll have a few volumes striped across 2 disks
and mirrored to the other 2. For oracle files (if oracle) use OFA
compliant mount points (search for OFA), such as /u01, /u02, etc and plan
your layout so that the migration to a DAS would be painless. Make sure
the App is tuned to not do crazy IO (queries tuned), and you should be OK.

-Andrey.

----------------------------------------------------------------------------------
The V440 is a great box and should handle this no problem. If this is
going

to be IO intensive then I would recommend external storage. Something I use
a lot are D1000's. You may choose something newer.

Best of luck,
Kris-

----------------------------------------------------------------------------------

Hi,

bit of vaguely-relevant-info, for what it is worth:

We had a small extranet server running a fairly classic "3-tier" client
data access setup (Apache->Jserv->Oracle) ; initially it was all running
on a single e250 (2x400mhz, 2 gigs ram, 4 internal SCSI disks, 2 in
mirror for OS slices and 2 mirrored for oracle data slices). Despite
the fact that the whole shebang ran on this one box (not just the
database), performance was just fine, since clients were relatively few
and they all did read-only access to boot.

A while later, we shuffled our hardware and moved the whole setup onto a
sunblade 100 (1x500mhz CPU and 2 gigs generic DIMM memory)with a pair of
mirrored 60gig IDE disks. Nobody noticed.

So, all this to say, that "low power hardware" is quite capable of doing
.. quite a lot of work ... and it may be the case, you might be able
to set your sights even lower down the feeding chain, depending on how
demanding the query work is expected.

ie, 4-way CPU capability .. is pretty generous unless the queries are
quite complex / cpu intensive OR very abundant in terms of ## of
simultaneous queries...

I might suggest, if possible, to characterize the nature of the queries
/ workload a bit more (read vs write allocation in typical workload?) ;
CPU intensity generated by queries on current hardware ; expected
concurrent loading patterns? ... maybe even if possible, try a test-run
on "low power hardware" , "just for a lark" -- you may be pleasantly
suprised to find a so-called low-end CPU (assuming adequate RAM is
available, typically the biggest/critical limiting factor in the past
I've found on "low end boxes" doing database server role) is adequate /
appropriate.

Also, of course, to comment: if your data footprint is so tiny, and
"standalone operation" is a good thing -- then SAN might be .. not
really necessary/appropriate..

anyhow. Just my 2 cents worth. Possibly it is preferable to have lots
of room for over-capacity, but .. often, you pay quite a premium and
don't always get any real benefits from it..

--Tim
----------------------------------------------------------------------------------

Martin,

        Hello. I'm using a V480 now, but I used one V440 for the kind of DB you
are talking about, but slightly different, we had a 25GB DB (RAW) with
behaviour information, and we ran experiments on it. The performance use
to be ok, until the 101 user went into the DB... then everything was
degrading slowly... Anyway, my guess was always on the network and not
on the cpu/disks. but again, our experiments use to get info from the
DB, process something, go back to the DB, process something and so on...
        I don't really know if this will help, or perhaps is just going to
confuse everything more...

Cheers!

Pablo.-

----------------------------------------------------------------------------------

I'd be a bit concerned about the number of [possible] concurrent users,
and having so few HDDs to which you can spread the load of I/O.
Additionally, I'd watch the queries that are submitted to the database.
Developers are infamous for bringing a server to its knees with
poorly-written queries, then blaming the server or the database. I
assume this will be for Oracle? Will you be involved in the
configuration of the database (e.g. where the different tablespaces,
control files, redo logs, etc. will be installed)?

Gary Chambers
----------------------------------------------------------------------------------

ORIGINAL QUESTION:

Hi all

Hope everybody is well.

My company has a requirement for an off-SAN solution (DAS) that can
provide sufficient grunt to power a small database. The database will
consist of mostly customer demographic information that will be
accessed/updated sporadically by around 120-150 call centre staff
connecting via a VB application - may also be some updating processes
going on, but not much.

All random i/o, database around 20GB but with a view to small growth.

I have put forward 2 V440's to do the job (2x1.28ghz UltraSPARC IIIi
processors, 4GB memory and 4x73GB ULTRA320 10K RPM SCSI disks in each),
volumes will be VxVM controlled and RAID 10.

I am also heavily involved with speccing and deploying an upgrade SAN
solution, and so I have specced these two servers with HBA's in order to
plumb them into the future SAN, so the internal disks will not be used
for too long.

I just wondered what people thought of the V440's, does anyone use them
here as a small database server using the internal drives? if so how did
you set it up and how do you find performance.

Thanks
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers

• Previous message: ktn: "Re: help! picld error - is it a hardware issue?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]