Why AIX? 2

[Nostradamus]

We´re about to upgrade a lot of old AIX machines to one big server and I have some questions.

Anything I should have in mind when buying the hardware (cpu, RAM, RAID, Disc etc.)?

Does anyone have experience with AIX and Progress as a DBMS?

any tips regarding this setup would be appreciated. /Sören

 

[prv3116]

Gosh, recommendations...

Here are some things to think on and plan with:

How many users and what type of connectivity will you be using; i.e. users telneting in, client/server?

Do you have ESS or SAN or NAS being planned for the rest of your IT? SSA is the way to go if there is no need for that kind of storage capacity.

How large of a database in Progress; multi-volume or single?

Are you going with a particular vendor using the Progress DB or are you going to be developing your own inhouse?

What is going to be your availability requirements, High Availability or full redundancy? What is your downtime and maintenance needs?

Servers: B80 with 2 cpus at 375MHz - up to - the new 6H1 with 6 cpus at 668 MHz

http://www-1.ibm.com/servers/eserver/pseries/index.html

What level of support staff do you have or are you planning for: DBAs, Unix Admins or Engineers

Progress has quite a few logs and monitoring tools. Doesn't seem like there are a lot of Progress DBAs out there. Could become the function of a dedicated Unix Admin/Engineer to maintain it.

Progress has a really good support center and training. Not hard to learn for a Unix person dedicated to application support. This link is to the Progress Knowledge Base. You can get some good information here:

http://www.progress.com/support/kb/index.htm

Hope this helps some. Remember, amateurs built the Ark, professionals built the Titanic.

 

[Nostradamus]

I´m beeing informed on monday regarding many of your questions. I´ll also ask yours if they don´t come up.
Many helpful tips... thanks. *vote*

I´ll take a look at the links tomorrow and I´ll fill in the rest of your questions on monday.

Now I´m going home. Working late again, perhaps I should demand a raise /Sören

 

[Nostradamus]

It seems like the server in mind is the monster 660-6H1 with 1-4 64bits cpu´s, 2 Gb RAM, a disc-subsystem rack with a SSA-adapter. I figure 2x9,1 Gb will be used internally for the OS (mirrored). 3x3 discs (RAID5) for the database and 2x2 (mirrored) discs for the logs/transactions externally. All other hardware is duplicated (fans, powersupply, NIC) for minimal downtime and maximum availability.
Some downtime is necessary when upgrading OS,Application etc. but that´s perhaps an hour/2 weeks.

All former servers will act as a different database in the new machine. Multivolume=yes

The vendors we´ll be using is IBM themself and a progress-guru from a nearby company. We will dump the data on the old servers and import it into the new.

We have licenses for up to 500 simultaneuous progress-users. They are spred across 900 workstations, but around 2000 people have access to the system. (they work night and day so the 500 limit shouldn´t be reached).
The users are telnetting in.

Both progress and hardware are under a rather huge support-deal. We (I and someone else) will be the one acting as DBA,Unix admin and try to learn the system. When I get stuck the help is merely a phonecall away.

A person from IBM will be with me shortly to explain more about the server.

A rather fun setup if I may say so.
This could be interesting.
Any more tips/things I should have in mind? /Sören

 

[prv3116]

Sounds fun! You will like the 6H1! We have about 6 on the way here. Progress is not hard to learn to support if you're inclined to application support. Some AIX admins/engineers prefer to stay strictly OS and/or hardware/networking. Progress requires lots of attention, particularly in development. Lot's of logs to monitor depending upon your setup! Myself, I like supporting applications and databases. We did not have a dedicated Progress DBA so it was up to me to learn the environment. I do recommend going to a Progress class, the V7/V8 Administration or the V9 Admininstration course, very good foundation for you. Even if you can't go for sometime after your install, you will pick up a lot of information.

Make sure you are very involved in the install and configuration. Take lot's of notes, you will be surprised how much you will need to remember and refer to later on.

Okay, performance is a big issue with Progress databases. Not only are the normal OS performance monitoring, but some specific recommendations for multi-volume Progress databases. You can very finely tune your DB.

Since your users are going to be telneting, you'll need to work frequently with your networking/tcpip skills. Netstat commands to keep watch on your connectivity performance and sar to monitor overall performance.

Enjoy! Remember, amateurs built the Ark, professionals built the Titanic.

 

[Nostradamus]

How do you think 30 seperate databases will affect performance? Do you know any kernel parameters that, if tweaked, makes progress runs better?

Do you know any tweaks on the database-side that would make my DB run smoothly

We thought perhaps we would use our Compaq disc cabinett (RA-8000) which is practically unused. Do you have any experience with mixing those sort of things? A Compaq Disc cabinett instead of IBM´s own. The AIX-machine would then be equipped with 2 Fibrechannel cards. Ever configured that on an AIX?

Do you know if progress have any trouble with 64bits cpu or SMP? progress v.9 that is.

Thanks for all the information and all the tips. /Sören

 

[prv3116]

30 seperate databases shouldn't pose a problem, just is quite a lot to keep up with. The most I've seen is about 6, and this was with 1 main DB and the others were read-only, supporting the main DB. Curious, has anyone mentioned if your other DBs going to using any two-phase commit functions, where you enter data into one DB and it also enters into another, using a commit communication and both DBs get updated.

Here are some links directly from the Progress Knowledge base. Some of this will probably not make much sense until you can get into you install. After a while this will all become second nature for you.

Memory and disk space was the most OS related tuning that we did. SMP is great. In fact, V9 was developed to specifically take advantage of the 64 bit technology by the way Progress designed the threads. Supposed to dramatically increase speed in V9 with the new ways they do the indexing and tables. Can't really explain it any further than that.

Study these articles. They refer to OS kernel tuning, Multi-volume strategy, extent size. Most of you tuning parameters will be in your startup sequence. It is a "pro" command with several parameters that determine how your database comes up. Disk I/O can be an issue, but if your'e going to use Raid you should be fine there.

http://www.progress.com/services/support/cgi-bin/techweb-kbase.cgi/webkb.html?kbid=10804&keywords=-b

http://www.progress.com/services/su...gi/webkb.html?kbid=11937&keywords=performance

http://www.progress.com/services/su...gi/webkb.html?kbid=11431&keywords=performance

http://www.progress.com/services/su...cgi/webkb.html?kbid=1251&keywords=performance

http://www.progress.com/services/su...gi/webkb.html?kbid=16645&keywords=performance

http://www.progress.com/services/su...gi/webkb.html?kbid=15911&keywords=performance

http://www.progress.com/services/su...gi/webkb.html?kbid=17188&keywords=performance

Here's an article from IBM regarding Compaq. I don't have any experience with the RA8000 you are referring to. Just EMC and ESS Shark. I will have an opportunity to configure fibershannel on the servers we have coming in.

http://www.storage.ibm.com/press/disk/20000706.htm

Remember, amateurs built the Ark, professionals built the Titanic.

 

[bi]

Sören,

You and prv3116 seem to have most of the important, more difficult items under control.

I would like to add just a couple of thoughts: You said in one of your earlier messages that you are looking at a 1-4 CPU system with 2 GB of RAM. Considering all that is going to be run on this system, I would just suggest that you get as many CPUs as you can (at least more than one) and try to at least double your RAM to 4 GB.

Have fun!

 

[prv3116]

Agreed! I meant to mention that when I saw it. Progress is a very I/O intensive and memory intensive product. We used a swap space of at least 512 for every major file system containing the logs generated. Now, our DB was customized and did a lot of external processing that produced a great amount of I/O, your's may not be so.

Definetly take advantage of the multi CPUs and max the memory. Remember, amateurs built the Ark, professionals built the Titanic.

 

[Nostradamus]

We´re using 2Gb RAM because of the chipkill-feature, which needs 8 DIMM-modules? The most cost-efficient proposal was 8x256 Mb. But Perhaps the 512 Mb-modules is something to think about. We´ll also use 4x450Mhz as cpu power. The guy from IBM said that cpu wouldn´t be the bootleneck here, and choose 4 merely for redundancy.
The exact disc strategy is this. (all discs is 9,1Gb)
1x1 internally for OS (raid1)
3x3 externally for database (raid0+1)
1x1 externally for transactions, logs, temp (raid1)
1x1 externally for backup (raid1)
raid0 is disc stripe and 1 is mirrored, right? anyway, that´s what I mean

I don´t think that any two-phase commit functions will be used. The application will share similar records though, such as the population register, but that´s a database on another server.

How much memory will Progress use, 0,5Mb/user?

Considering that the databases are medium read/write intensive and the ASS adapters work at their maximum of 160Mb/s. (we´ll use 4 Where would the bootleneck be in my system if it appears?

I suppose a lot of answers will be presented as soon as the server is up and running. I´m just curios.

Thanks again for all your help and tips.
Now I´ll spend my entire day browsing through that awsome link-collection thanks prv3116 /Sören

 

[prv3116]

I don't have my Progress manuals here with me, but I think it was something like 1 meg per user, just to log into the application. And I am thinking that we had way more memory than that. I want to say something like 8 gig (?). We went through some changes after we were up and running for several months. We had to increase the amount of semaphores that the database started up with. We didn't see it earlier, it wasn't until our user load started to increase that we had the problem. Check out Kingston Memory, much less expensive. We purchase minimum config from IBM and then upgrade

Your network is the last area, and the one that you may have the least control over. Make sure you run at 100 Full duplex and your network people set the switch to 100 Full, not auto negotiate. If your are using T1, we found that the best performance was on the T1's with 8 or less hubs off of it, which was about 40 to 80 users. My biggest task was watching the network traffic. We ended up doing some tuning with the mbufs and thewall. Plus once we switched to 100 Full we noticed big difference is response times for the users. Learn to monitor the collision rates in your netstat outputs. Progress updates as it goes. Not sure of the technical terminology for it, but what I mean is that each field is updated as the user inputs data, it doesn't wait for a page to complete then send that page. It updates by the field. Remember, amateurs built the Ark, professionals built the Titanic.

 

[baggetta]

Nostradamus, I don't think your sever configuration will handle your required Progress db's and the amount of users your looking at. We also purchased 2, 660-6H1 with 2x800 CPU, 6 GIG Ram, 34 Hdisks x 18 GIG....still not enough. We have 2 Progress databases on this server, one is 34GIG and the other about 7 GIG...performance will start to decrease as your database gets larger, and if you don't use the Progress storage areas for your db, your users will definately see the impact of speed.

Both our servers are in a HACMP Cascading environment, there are some problems with Progress and IBM using HACMP. That's all I can say. (ie: doesn't always work, so no point of using HA). I will say the servers have been very stable over the 4 years, only 1 power unit blew up and then blew another 2 after that since the power load was high...

SSA, not the way to go. Get a ESS or FastT i think they call it. SSA is really expensive in the long run. Need any 36 GIG disks? I have 2 I can't install because of my SSA cabling strcuture...good old IBM knows how to get you later on when you need to expand.

Out of curiosity, you planning on running MFG/Pro on these progress dbs?

 

[alexhu]

baggetta

If he hasn't done it by now , he never will.

Check the date of the post

Alex