Subject: Re: [KLUG Members] Redhat 8.0

Adam Williams members@kalamazoolinux.org
03 Oct 2002 18:36:59 -0400


>Would you please explain in a little more detail what you mean about RedHat
>supporting a real file system?

ext2/3 poses problems to maintaining a high-performance 24/7 system.  It
is as simple as that.  Not that it can't be done,  it just takes more
man hours.

>The company I work for is getting ready for a re-write of some mission
>critical software. I had the money for the server last year and had Monarch
>build a server with an AMD 1.2GHz Athalon processor, dual hot swap power
>supplies and a SCSI Raid 0+1 with a hot swap spare drive.

Install and configure the lmsensors package so you can monitor the
temps,  that way you can be sure you have adequate ventilation.

>I had Monarch install RedHat 7.2 with ext3 so I would have a journaling file
>system out of the box. The only other journaling file system I have heard
>much about is Reiser. Since RedHat only supported ext3, I opted for a
>straight RedHat 7.2 with ext3 system. If there is a better file system out
>there, I would definitely be interested in knowing what it is and why it is
>better.

I use ext2/2 for my system volumes (/var, /usr, /, /usr/local, etc...) 
it is great for that.  All the tools support it, etc...  

For data I use xfs.  It can allocate space faster,  is faster with
really large files (like databases use) and can dynamically allocate
inodes (a HUGE plus over ext2/3).  Plus you can defrag a mounted
filesystem, and you have extended attributes included access control
lists.

For "grinder" filesystems like used by a Squid proxy, apache session
files, etc... I use reiserfs.  That provides really good performance. 
But I don't trust it for networked volumes or where there is file
contention (locking, etc...) It just isn't proven,  and the maintenance
utilities are almost useless.  It is very good for filesystems where, if
there is a problem, you just recreate it.

>The Logical Volume Manager concept in RedHat 8 sounds like something I
>should be interested in for this project. In your opinion would it be worth
>the effort to rebuild this box with RedHat 8 for this feature?

Yes.  I intend to do that with several of my servers.  But I'll wait
until it has been out for a couple of weeks, and the SGI guys provide an
XFS enabled installer.

If you have alot of data to backup and don't want an hour plus downtime
every day LVM is a necessity.  Snapshotting lets you create an instant
picture of a filesystem and you can back that up while real work
continues.  Then you just toss the image.  The image is a special type
of journal, so one could probably take a couple of hundred megs and
image a 1Tb filesystem if the transaction volume isn't really extreme. 
Only changes to the true filesystem cause data to actually be copied to
the snapshot,  but to utilities like tar, etc..., it looks like yet
another filesystem.

>We have a programmer about to start. He will be writing the mission critical
>application. I told him we wanted to do open source. He is thinking he wants
>to use a PostgreSQL database backend. I would prefer to go with the recently
>open sourced version of SAP. If you have any opinions on the database choice
>I would love to hear those too.

I've used PostgreSQL extensively, and today wouldn't hesitate to drop
enterprise level stuff on it.  I'm certain SAP is good, but it doesn't
have the installed base that PostgreSQL does.  Transactions,
constraints, and stored procedures work very well;  plus the ODBC driver
is *FAST*.  Software packages like xmlBlaster express a preference for
postgresql, and those guys are smarter than me.

But don't expect to use PostgreSQL outa-the-rpm to do heavy lifting. 
It's parameters need to be tuned like any other real database.

>Also, I had some money left over at the end of this year, so I was able to
>pickup some hardware that I might be able to use for this and a couple of>other projects. I bought a dual Xenon motherboard with two 2.4GHz
>processors. I will be building a system around this and an Adaptec 39160
>Ultra 160 SCSI adaptor, but I don't know if this would be any better
>platform for writing the database application.

The Xeon processors have large caches which help multitasking, and
databases like SMP.  But I wouldn't want to trade off dual power
supplies, etc... for anything.

>Does a database app need to be built for dual CPU's from scratch or will the
>OS distribute the workload between the two processors if we migrate the
>application from the AMD to the dual Xenon system sometime down the road?

Depends on the application.  Any modern database engine will certainly
take advantage of SMP.  

Are we talking about a web application, a some-kind-of-transaction
processor, financials,...?  You can always put the app on one box and
the DB on a separate box. 

>Finally, I am getting in pieces and parts to build a couple of Linux boxen
>to try out some of the workgroup software (Bynari Server) and maybe
>something like MrProject if it can be used by my windoze clients.

I don't know of a Win32 port of Mr. Project.  But it is a nice project.

>I would appreciate any suggestions you might have.

Create lots of documentation.

-- 
----------------------------------------------------------------
This message undoubtedly processed by the purely benevolent "US
Department of Homeland Security",  but don't worry... they're
only goal is to protect life, liberty and the pursuit of property.