RAID in 2024

[JLovegren]

My case:
Workgroup Database - nominally 30 users.
Version 12.8
OS Windows Server 2019 Std.
The backup of my database is 2.5GB
Configuring my system as Virtual, once all is complete, I would migrate to another server - when I go live.

I can keep this on a VM but am more comfortable with a new hardware server.

In concept, I am thinking about the following drives.
C: OS, RDBMS (Mirror 2 disks)
D: Before Image
E: Database
F: After Image

I usually just mirror the OS drive.
For the database, my v9.1E has been running fine with mirrored drives since 2004 (IBM Server) using 6 drives (no after image).

The server itself would likely have 64GB memory as a standard config.
I would install the smallest, most reliable drives for data. Due to the database size, I can do RAID-10 as space is not an issue.

Note: I do intend to ask Progress Software for recommendations - but I would like to know what the group thinks so I can have a balanced decision.

Q1: How would you configure?
Q2: RAID-5 for all data, separated into disk containers? RAID-10?
Q3: SSD or Spinning Disk?
Q4: Something else

Thanks in advance!

 

[Rob Fitzpatrick]

For the database, my v9.1E has been running fine with mirrored drives since 2004 (IBM Server) using 6 drives (no after image).

I don't know your business, or the rate at which your data changes, or how much you can afford to lose. But you should.

It sounds like you are modernizing to some extent. If I were you, I would start by modernizing the business continuity plan. Figure out your RPO and RTO and put in place licenses, processes, and procedures that fit your needs. For example, if you can't afford to lose 24+ hours of data in the event of a disaster, you need to implement after imaging in addition to your daily backups. If your RPO is closer to a few minutes than a few hours, you should be implementing OpenEdge Replication Plus.

I wouldn't go overboard with lots of volumes. In the grand scheme of things, this is a very small database. It's good to have separate physical volumes for the database and for AI/backups. Given the small size of your database, it is likely fine in your case to have one volume with the OS, OpenEdge installation, AI, AI archive, and backups. Have a second volume for the database (including the BI area). RAID 1 mirroring is fine; use it on both volumes. Be sure to monitor your hardware so you are aware of drive failures. Use fast enterprise SSDs if you can.

Ensure that you have reliable procedures/automation for:

• taking daily backups
• copying backups to your DR server
• testing your backups, e.g. restore to a warm spare DB on your DR server
• archiving your filled AI extents to a local AI archive location (via the AI archiver)
• copying your archived AI extents to your DR server
• managing file retention of your backups and AI extents, according to your retention policy

When you ask about RAID 10 and SSD, it makes me think you care about application/database performance. In that case I strongly suggest you upgrade your database license to Enterprise RDBMS. Note that Enterprise doesn't just deliver a multitude of performance benefits. It is also a requirement for many additional database capabilities, including quiet points, Transparent Data Encryption, Change Data Capture, Table Partitioning, and Multi-Tenancy.

You mentioned RAM; I'd say 64 GB is more than enough for you. You didn't mention CPU(s). Don't spend on 16, 32, or more cores. Buy fewer, faster cores. Buy the same hardware for your DR server. Be aware of the NUMA configuration of your chosen hardware.

As to "how would you configure", I can't answer that yet. It depends entirely on the licenses you purchase and your desired outcomes. Are there issues or limitations you face now that you want to eliminate? Do you anticipate future growth in database size, transaction volume, user count, etc?

 

[dimitri.p]

. You didn't mention CPU(s). Don't spend on 16, 32, or more cores. Buy fewer, faster cores.

You can say that again! That's the second "T-Shirt worthy" phrase you have come up with.

Use fast enterprise SSDs if you can.

And test, test , test.
If you hear "it's brand new, of course it will be faster", RUN!
Some SSDs exibit abysmaly horrendous performance for (reasonably ) small transfers.


In addition there are virtual machines and there are fast machines . But there are no fast virtual machines (to paraphrase the brave/old sailors saying) .
I haven't had the luxury to test identical hardware running on bare metal vs a VM on the exact same hardware, but so far I haven't seen any VMs that were "fast" (usually because of "too many slow cores disease" - other times because of too few slow corese disease!)

Assume nothing and test.

...and from the anecdotal evidence department....I have seen probkup taking 5 to 45 minutes to run in the middle of the night "without anyone doing anything on the system", from what I'm being told.

Curiosity question:
How long does probkup take to create the 2.5Gb backup ?

 

[Rob Fitzpatrick]

You can say that again! That's the second "T-Shirt worthy" phrase you have come up with.

Credit where it's due: that's @TomBascom's message based on his research and consulting; I'm just spreading the word.

Agreed on virtualization. It can provide real benefits but it isn't free (computationally) or risk-free. It adds another layer of abstraction and complexity, and can have some real pitfalls if used improperly. I've seen a database in a VM take fifteen minutes to proserve because someone had done the wrong thing with vmmemctl. We found and changed the setting and it went back to being near-instantaneous.

It wasn't mentioned, but I assume the upgrade plan is going to involve restructuring into Type 2 areas via dump and load, and not just a series of conversions to get the database from v9 to v12.

 

[JLovegren]

You can say that again! That's the second "T-Shirt worthy" phrase you have come up with.

And test, test , test.
If you hear "it's brand new, of course it will be faster", RUN!
Some SSDs exibit abysmaly horrendous performance for (reasonably ) small transfers.


In addition there are virtual machines and there are fast machines . But there are no fast virtual machines (to paraphrase the brave/old sailors saying) .
I haven't had the luxury to test identical hardware running on bare metal vs a VM on the exact same hardware, but so far I haven't seen any VMs that were "fast" (usually because of "too many slow cores disease" - other times because of too few slow corese disease!)

Assume nothing and test.

...and from the anecdotal evidence department....I have seen probkup taking 5 to 45 minutes to run in the middle of the night "without anyone doing anything on the system", from what I'm being told.

Curiosity question:
How long does probkup take to create the 2.5Gb backup ?

It takes 7 minutes on my 2005 IBM x346 and with compression added. I have not set the script to run on the VM yet and not ordered the hardware yet so i don't know how that will change when my update is live (now 9.1e).

 

[JLovegren]

Credit where it's due: that's @TomBascom's message based on his research and consulting; I'm just spreading the word.

Agreed on virtualization. It can provide real benefits but it isn't free (computationally) or risk-free. It adds another layer of abstraction and complexity, and can have some real pitfalls if used improperly. I've seen a database in a VM take fifteen minutes to proserve because someone had done the wrong thing with vmmemctl. We found and changed the setting and it went back to being near-instantaneous.

It wasn't mentioned, but I assume the upgrade plan is going to involve restructuring into Type 2 areas via dump and load, and not just a series of conversions to get the database from v9 to v12.

Yes. Implementing Type 2 storage. Thanks for the comment!