From HP-UX to Redhat - Forum - OpenEdge RDBMS - Progress Community
 Forum

From HP-UX to Redhat

This question is answered

Good morning all,

It looks like we'll be migrating from HP-UX to RedHat EL in the not too distant future.  Was wondering if there's any sort of best practices / things to watch out for when migrating these 2 platforms? 

  1. It'll be RH Enterprise -- just not sure of which version quite yet should we just go with whatever the latest is?
  2. I know we'll have to D&L
  3. Pretty sure we should set the Linux DB file system's to 4K, and make the DB block size match
  4. Is there a list of kernel parameters that we might need to tune relative to the ones we've changed on HP-UX
  5. Anything the server itself needs prior to installing OE
  6. We average about 175 self service clients & about 25 client/server but that trend will flip around as we migrate our character based application to Gui
  7. The machine itself will have fast cores, lots of RAM and super fast SSD's
  8. We are considering virtualizing this server with VMWare, but having it be the only machine instance on the VMWare host itself.  We'll be careful not to run any other virtual servers with it.  Was wondering what if any overhead a VMware host sitting above the Linux server would cause? 
  9. We'd do that because with VMWare it's easy to make backup's of the entire instance and blast it elsewhere for a myriad of different scenarios/reasons -- even up to the cloud 
  10. We realize that with VMWare being at the top, we can't *really* control where DB, AI, /tmp etc. go but are ok with that given the machine itself will be plenty fast speed-wise, and we run AI Archiver (& backup those files elsewhere) plus we run OE Replication so we're kind of doubly covered redundancy wise there
  11. Any other potential issues with running this way?  i.e.  VMWare on top of 1 Linux instance

TIA for any insight / expertise offered!

Brad

Verified Answer
  • Test printing to see what works and what doesn't.

  • This is not OpenEdge-related but may impact you since most deployments somehow have Samba involved in some way.

    Do test your SMB configuration and make sure all your existing Samba shares work as expected. Migrating from one *Nix to another has been known to cause Samba issues with initial setup.

    Also, arranging your OE databases on your fastest SSD in RAID 0 will improve performance. If you have RAM to spare, increasing "B" startup parameter as much as possible will also help.

    Knowing your existing Firewall settings will be tremendously helpful, so you can duplicate those on the new servers. OpenEdge Broker/NS etc. use specific port settings and troubleshooting those may be something you will have to do.

    In addition to testing printers from your RHEL deployment, also do test any potential PDF generation software that sits between your OpenEdge application and the OS itself. Have many (not so) fond stories in my experience...

    I would also see how Red Hat customer support works for your subscription tier, since you will eventually need to talk to them at some point. 

    Lastly, I would comprehensively test any e-mail functionality you may have running on the current deployment. We recently migrated to RHEL 7.6 from RHEL 6.X and ran into how Azure does not allow outbound mail traffic unless you use something like SendGrid etc. 

  • Hi Brad,

    Sounds interesting topic as we're also in similar process. Not sure there's an up to date best practices material from Progress regarding LInux & VMWare (or concurrent) setting.

    Below a case we've found (db crash) during some pilot we did as we're not running our DB against root user (fixed by changing kernel param).

    knowledgebase.progress.com/.../semaphores-removed-when-user-logs-out-on-Linux-000086484

    Should you face also long adminserver start.

    knowledgebase.progress.com/.../AdminServer-slow-to-start-on-Linux

    For semaphore settings following KB might help

    knowledgebase.progress.com/.../P61278

    If you're not only migrating DB but ABL sources/script as well moving from Hp-UX to Linux might requires some extra checking too (basically OS-xxxx command as well INPUT/OUTPUT THROUGH...).

    We've not yet move any production DB to Linux (only some test pilot) but sounds keeping db block size to 8k is still ok (at least Progress seems recommended a multiple of OS block size which I guess is 4k for you so 8kb remains good).

    We've been working from many years with VMware and running several VM (HP-Ux) within same host without any issue. It's obviously depending on your hw but I can't see the point of limiting 1 vm per host. Most critical performance point might anyway remains on your FS definition and corresponding IO constraints. Should you use LVM you can configure volume group and disk as per basic Progress/DB recommendation (separated VG for DB, AI,BI) and adjust you disk/SAN adapter accordingly. Do not trust super fast SSD, that could help but you will super fast realize that iops bottleneck is elsewhere (unless your DB activity is fairly low) especially with SAN.

    Please keep posting your feedback I'm interesting to hear about any findings as we shall proceed with production DB and application migration from Hp-Ux to Linux at some point during 2019 too.

    Denis

  • HPUX was a decent option 20 years ago.  Going from HPUX to RH should be a breath of fresh air.  You will be very, very happy with performance.

    As has been mentioned the main thing to worry about is os-level things like printing, os-command, input/output through and the ilk.  You may find that you have some work to do in those areas.

    Linux kernel parameters will almost certainly not be an issue.  There is very little need to worry about those with Linux.  Especially since you only have 200 users.

    I have no qualms about using 8k blocks.  I find performance to be somewhat better than with 4k blocks.  Just don't go smaller than 4k, that would be bad.

    Virtualization will cost _something_.  If you do as you say and only use it in the way that you say it might not be too bad.  Be careful not to over-configure the VM (leave a few cores and some RAM unallocated) and follow best practices (there is a PUG presentation from Libor floating around somewhere).  DO NOT USE vm snapshots as backups!!!  That will not work.  If it appears to work it is only lulling you into complacence.  It WILL bite you hard when you really need it.

    --
    Tom Bascom
    tom@wss.com

  • We just did this migration last year in July.

    The config you are looking at is very similar to what we did, except we decided not to go VM. The performance hit was not worth the VM capabilities since the snapshot functionality doesn't work for the openedge DB. We went 2 physical servers with replication services. It has worked out great. Looking to put a replication instance in the cloud at the end of this year.

    I took a couple weeks, with some outside help, to tweak the necessary processes for the D&L to work in the time period we needed.  

    I would also suggest using a monitoring tool like ProTop (not getting paid for the endorsement) to see what is actually going on in the new environment vs the old environment. We made many changes to the database for the D&L based on recommendations from analysis of the data in the database. Next week after running for 6 months now we are making some additional DB changes based on recommendations from ProTop .  (Should have made them sooner but other items took priority).

    You will need to test EVERY script you used on the HP box to verify they function properly. Don't assume the script will function properly because others did. (Bit us in backside for about 2 weeks.) Also SE-Linux will come out and bite you with script access rights. Anything using PERL or PHP need to be double tested. Email was also an issue especially multiple attachments.

    The last thing I would suggest is TEST, TEST, TEST,TEST, and then TEST again.  It took us almost 2 full months of testing scripts before we did the actual move to the new OS. We have been very happy since.

  • > On Feb 13, 2019, at 1:09 PM, v205 wrote:

    >

    > arranging your OE databases on your fastest SSD in RAID 0 will improve performance

    this may or may not be true, depending on the exact configuration. in RAID 0, multiple drives are configured to appear as one large drive BUT THERE IS NO REDUNDANCY. if one drive fails, all the contents of the entire set will be lost.

    separate independent drives (aka JBOD) would be better.

    RAID 10 (striping and mirroring) gives performance and reliability but costs a little more.

    no matter what disk setup you use, you still have to do regular backups and after-image journalling.

    =

  • quiting chiumonster's earlier post:

    "DO NOT USE vm snapshots as backups!!! That will not work. If it appears to work it is only lulling you into complacence. It WILL bite you hard when you really need it."

  • I talked to a friend that was using snapshots during the development of an application.  He told me that 9 out of 10 times the database was usable when he restored a snapshot.  On the 10th time, he had to rebuild the database from scratch, and since this was a development job, he could do it.  He worked on this for months, so he was using snapshots and restoring them often.  90% success rate is not what you want to build your DR strategy on.

    Mike
    -- 
    Mike Furgal
    Director – Database and Pro2 Services
    PROGRESS
    617-803-2870 


  • Windows, rather than Linux, but I've had bad experiences with VM snapshots too. Server chewed up by ransomware including the backups. Customer restored a snapshot. Database was hosed. We got about 95% of it back with some creativity, but that's 95% of a database that was already hours out of date. And there was no easy way of telling which data was missing. And it took around 2 days of outage to get there as well.

    Moral of the story: Robust backup strategy using probkup, AI archiving, and getting it all off the database server ASAP is the only way to ensure your data is safe and current post disaster.

  • It's worth making sure that the folders the databases reside in are excluded from the snapshots as I've seen the concurrent access cause problems. And don't se vMotion unless the databases are quiesced first.

All Replies
  • Test printing to see what works and what doesn't.

  • This is not OpenEdge-related but may impact you since most deployments somehow have Samba involved in some way.

    Do test your SMB configuration and make sure all your existing Samba shares work as expected. Migrating from one *Nix to another has been known to cause Samba issues with initial setup.

    Also, arranging your OE databases on your fastest SSD in RAID 0 will improve performance. If you have RAM to spare, increasing "B" startup parameter as much as possible will also help.

    Knowing your existing Firewall settings will be tremendously helpful, so you can duplicate those on the new servers. OpenEdge Broker/NS etc. use specific port settings and troubleshooting those may be something you will have to do.

    In addition to testing printers from your RHEL deployment, also do test any potential PDF generation software that sits between your OpenEdge application and the OS itself. Have many (not so) fond stories in my experience...

    I would also see how Red Hat customer support works for your subscription tier, since you will eventually need to talk to them at some point. 

    Lastly, I would comprehensively test any e-mail functionality you may have running on the current deployment. We recently migrated to RHEL 7.6 from RHEL 6.X and ran into how Azure does not allow outbound mail traffic unless you use something like SendGrid etc. 

  • Hi Brad,

    Sounds interesting topic as we're also in similar process. Not sure there's an up to date best practices material from Progress regarding LInux & VMWare (or concurrent) setting.

    Below a case we've found (db crash) during some pilot we did as we're not running our DB against root user (fixed by changing kernel param).

    knowledgebase.progress.com/.../semaphores-removed-when-user-logs-out-on-Linux-000086484

    Should you face also long adminserver start.

    knowledgebase.progress.com/.../AdminServer-slow-to-start-on-Linux

    For semaphore settings following KB might help

    knowledgebase.progress.com/.../P61278

    If you're not only migrating DB but ABL sources/script as well moving from Hp-UX to Linux might requires some extra checking too (basically OS-xxxx command as well INPUT/OUTPUT THROUGH...).

    We've not yet move any production DB to Linux (only some test pilot) but sounds keeping db block size to 8k is still ok (at least Progress seems recommended a multiple of OS block size which I guess is 4k for you so 8kb remains good).

    We've been working from many years with VMware and running several VM (HP-Ux) within same host without any issue. It's obviously depending on your hw but I can't see the point of limiting 1 vm per host. Most critical performance point might anyway remains on your FS definition and corresponding IO constraints. Should you use LVM you can configure volume group and disk as per basic Progress/DB recommendation (separated VG for DB, AI,BI) and adjust you disk/SAN adapter accordingly. Do not trust super fast SSD, that could help but you will super fast realize that iops bottleneck is elsewhere (unless your DB activity is fairly low) especially with SAN.

    Please keep posting your feedback I'm interesting to hear about any findings as we shall proceed with production DB and application migration from Hp-Ux to Linux at some point during 2019 too.

    Denis

  • HPUX was a decent option 20 years ago.  Going from HPUX to RH should be a breath of fresh air.  You will be very, very happy with performance.

    As has been mentioned the main thing to worry about is os-level things like printing, os-command, input/output through and the ilk.  You may find that you have some work to do in those areas.

    Linux kernel parameters will almost certainly not be an issue.  There is very little need to worry about those with Linux.  Especially since you only have 200 users.

    I have no qualms about using 8k blocks.  I find performance to be somewhat better than with 4k blocks.  Just don't go smaller than 4k, that would be bad.

    Virtualization will cost _something_.  If you do as you say and only use it in the way that you say it might not be too bad.  Be careful not to over-configure the VM (leave a few cores and some RAM unallocated) and follow best practices (there is a PUG presentation from Libor floating around somewhere).  DO NOT USE vm snapshots as backups!!!  That will not work.  If it appears to work it is only lulling you into complacence.  It WILL bite you hard when you really need it.

    --
    Tom Bascom
    tom@wss.com

  • We just did this migration last year in July.

    The config you are looking at is very similar to what we did, except we decided not to go VM. The performance hit was not worth the VM capabilities since the snapshot functionality doesn't work for the openedge DB. We went 2 physical servers with replication services. It has worked out great. Looking to put a replication instance in the cloud at the end of this year.

    I took a couple weeks, with some outside help, to tweak the necessary processes for the D&L to work in the time period we needed.  

    I would also suggest using a monitoring tool like ProTop (not getting paid for the endorsement) to see what is actually going on in the new environment vs the old environment. We made many changes to the database for the D&L based on recommendations from analysis of the data in the database. Next week after running for 6 months now we are making some additional DB changes based on recommendations from ProTop .  (Should have made them sooner but other items took priority).

    You will need to test EVERY script you used on the HP box to verify they function properly. Don't assume the script will function properly because others did. (Bit us in backside for about 2 weeks.) Also SE-Linux will come out and bite you with script access rights. Anything using PERL or PHP need to be double tested. Email was also an issue especially multiple attachments.

    The last thing I would suggest is TEST, TEST, TEST,TEST, and then TEST again.  It took us almost 2 full months of testing scripts before we did the actual move to the new OS. We have been very happy since.

  • > On Feb 13, 2019, at 1:09 PM, v205 wrote:

    >

    > arranging your OE databases on your fastest SSD in RAID 0 will improve performance

    this may or may not be true, depending on the exact configuration. in RAID 0, multiple drives are configured to appear as one large drive BUT THERE IS NO REDUNDANCY. if one drive fails, all the contents of the entire set will be lost.

    separate independent drives (aka JBOD) would be better.

    RAID 10 (striping and mirroring) gives performance and reliability but costs a little more.

    no matter what disk setup you use, you still have to do regular backups and after-image journalling.

    =

  • @Gus, in our case, it (RAID0 performance gain) was significant. We measured it empirically using ProTop and other forms of load testing.

    As for backup, since our servers are on Azure, and there is a Regional Replication strategy in place, we do not really need database replication that badly, but your advice on AI sync and backups makes sense in general, of course.

    What I would like to know is how effective is VM Snapshots to recover from a catastrophe. Does anyone here have real experiences in that arena?

    Thanks to all, as always.

  • quiting chiumonster's earlier post:

    "DO NOT USE vm snapshots as backups!!! That will not work. If it appears to work it is only lulling you into complacence. It WILL bite you hard when you really need it."

  • I talked to a friend that was using snapshots during the development of an application.  He told me that 9 out of 10 times the database was usable when he restored a snapshot.  On the 10th time, he had to rebuild the database from scratch, and since this was a development job, he could do it.  He worked on this for months, so he was using snapshots and restoring them often.  90% success rate is not what you want to build your DR strategy on.

    Mike
    -- 
    Mike Furgal
    Director – Database and Pro2 Services
    PROGRESS
    617-803-2870 


  • Windows, rather than Linux, but I've had bad experiences with VM snapshots too. Server chewed up by ransomware including the backups. Customer restored a snapshot. Database was hosed. We got about 95% of it back with some creativity, but that's 95% of a database that was already hours out of date. And there was no easy way of telling which data was missing. And it took around 2 days of outage to get there as well.

    Moral of the story: Robust backup strategy using probkup, AI archiving, and getting it all off the database server ASAP is the only way to ensure your data is safe and current post disaster.

  • Just wanted to say thank you to all who've taken the time to respond and pass along your expertise.  Some great information in here!

    We do use online probkup daily and then back those files up elsewhere, so in a disaster the VM snapshot would be used to get the server itself / structure / software etc restored rather quickly, but then we'd use those online backups + AI archiver files to restore the database.  Definitely won't rely on those VM backups for the DB.  

  • It's worth making sure that the folders the databases reside in are excluded from the snapshots as I've seen the concurrent access cause problems. And don't se vMotion unless the databases are quiesced first.