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?
TIA for any insight / expertise offered!
Brad
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.
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.
=
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.
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.
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."
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.
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.
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."
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.