This article describes how you can use a tool such as SystemScan AIX AIX to migrate from AIX to Linux
Preparation
The first and possibly most important step in any migration project is to understand what you have now and to fix as many issues as possible. Things that cannot be fixed must be at least documented so alternative arrangements can be made.
1. Produce an accurate and detailed inventory of the existing systems.
SystemScan can scan an AIX system in minutes and provide an in-depth analysis highlighting issues such as missing packages, or differences between OS levels.
2. Make an inventory of the applications, workloads, and licences.
Creating an accurate inventory of your users, filesystems, applications, etc. can help you to understand what you need to migrate and perhaps buy new, or transfer existing licences and applications. It is also important to remember that an IBM Power chip is more powerfull than any Intel equivelant and thus can support far larger workloads, therefore you may require more licences in the Linux environment.
3. Compare users and groups on all systems and try to align (standardise) them where possible. E.g. Make user Oracle uid=200 on all systems.
a. Consider using an external single-sign-on such as LDAP to migrate users
b. Identify and where possible standardise any sudo rules
Reducing the amount of non-system users, and standardising UIDs etc. greatly reduces the amount of work required during a migration and reduces the risk of orphaned files. If possible try to map application IDs so that they are the same on Linux as AIX and use shared LDAP/AD users so that they can login to both the source and target with the same credentials, and their files are also available.
4. Create an inventory of any (host) keys and certificates.
a. Consider replacing or renewing certificates possibly with more modern/secure versions. This is always a good idea as they may have been compromised and as computers become more powerful so ever longer key lengths are required to protect them.
b. Create some kind of automated calendar or alert system to renew certificates before expiry.
SystemScan helps you to identify keys and certificates so the you can plan to transfer or replace them.
5. Identify any workloads or partitions that cannot be migrated and/or are now longer required.
a. Create a separate plan for decommissioning or long-term maintenance in or to maintain these worloads.
There are always going to be applications that are no longer supported, or are so old that there is no modern version, or perhaps they cannot even run on Linux. In this case you need to look for a replacement or plan to keep them running on IBM equipment by either leasing some dedicated kit or looking for a partner that can host it for you.
6. Ensure the same software versions are available on Linux, e.g. Oracle 11i. If an upgrade is required research any data conversions etc.
a. If the source and destination application are the same consider connecting both systems (Linux initially read-only) and test to ensure that the data can be used without any translation or conversion.
b. If conversion is required you must plan for the identical amount of storage to be (temporarily) available to Linux in order to test migration etc.
7. Check (equivalent) device-drivers are available on Linux and ensure that fibre-cards etc, can connect to the SAN or network at the same or improved speed.
8. Patch the AIX environment as much as possible and do all possible hardening and tuning in order to ensure that the source systems are in the best possible state.
9. Attempt to measure user perception(s) and experience in order to create a baseline otherwise users may attribute existing problems to the migration.
a. Identify any known issues or bugs because if something is broken in source it will be broken in target.
10. Use your current partition inventory to estimate the number of processors and memory sizings required for the target Linux systems.
11. Create some test cases such as reading 10GB of data, or having 100 users simultaneously logged-in in order to create a PVU ratio e.g. one Power7 PROC=4 Intel PROCS, or one HP Blade can handle the equivalent workload as an LPAR with 0.4 VPROCS.
12. Consult the application vendors such as Oracle to see if Intel has special requirements e.g. an AIX system with a 3GB SGA needs be increased to 4GB on Intel.
13. Check if any special permissions are in place on AIX e.g. RBAC and ensure that there is a conversion plan.
14. Ensure that any existing monitoring systems can handle both AIX and Linux, or that there is a migration plan.
15. Check any existing backup data can still be recovered after the migration.
16. Ensure there is a backup plan in place to replace the existing arrangements.
17. AIX uses NIM and mksysb for provisioning and bare-metal recovery. Linux uses Kickstart in place of NIM, however there is no direct replacement for mksysb. Suggest using Storix as it works on both platforms.
a. Create a Linux satellite server in order to centrally control the release and installation of patches.
18. Ensure that Linux support and licencing is fit for purpose and is budgeted for going forward.
19. Research all file-transfer (MFT) connections and where possible centralise them using a solution such as GoAnywhere as this will enable you to test both the source and target environments whilst maintain a central single point of control.
20. If you intend to migrate middleware such as WMQ to an open-source solution you must also check that there is a way to compare both solutions and/or to run them in parallel using some kind of message gateway.
21. Do you intend to do a big-bang, or a gradual conversion. In either case do you have adequate fallback and DR plans?
22. How long do change requests etc take and what is the size of any change window? If you now this you can ensure that no change takes more than 40% of this Window in order to allow for management meetings and fallback decisions.
23. Plan dry-runs and dress rehearsals.
24. Decide whether the new solution will be locally or cloud-based and ensure that there are DR plans in place.
25 .Finally you should ensure that your LInux supplier can provide adequate support and there are suitable support arrangments in place.
1. Produce an accurate and detailed inventory of the existing systems.
SystemScan can scan an AIX system in minutes and provide an in-depth analysis highlighting issues such as missing packages, or differences between OS levels.
2. Make an inventory of the applications, workloads, and licences.
Creating an accurate inventory of your users, filesystems, applications, etc. can help you to understand what you need to migrate and perhaps buy new, or transfer existing licences and applications. It is also important to remember that an IBM Power chip is more powerfull than any Intel equivelant and thus can support far larger workloads, therefore you may require more licences in the Linux environment.
3. Compare users and groups on all systems and try to align (standardise) them where possible. E.g. Make user Oracle uid=200 on all systems.
a. Consider using an external single-sign-on such as LDAP to migrate users
b. Identify and where possible standardise any sudo rules
Reducing the amount of non-system users, and standardising UIDs etc. greatly reduces the amount of work required during a migration and reduces the risk of orphaned files. If possible try to map application IDs so that they are the same on Linux as AIX and use shared LDAP/AD users so that they can login to both the source and target with the same credentials, and their files are also available.
4. Create an inventory of any (host) keys and certificates.
a. Consider replacing or renewing certificates possibly with more modern/secure versions. This is always a good idea as they may have been compromised and as computers become more powerful so ever longer key lengths are required to protect them.
b. Create some kind of automated calendar or alert system to renew certificates before expiry.
SystemScan helps you to identify keys and certificates so the you can plan to transfer or replace them.
5. Identify any workloads or partitions that cannot be migrated and/or are now longer required.
a. Create a separate plan for decommissioning or long-term maintenance in or to maintain these worloads.
There are always going to be applications that are no longer supported, or are so old that there is no modern version, or perhaps they cannot even run on Linux. In this case you need to look for a replacement or plan to keep them running on IBM equipment by either leasing some dedicated kit or looking for a partner that can host it for you.
6. Ensure the same software versions are available on Linux, e.g. Oracle 11i. If an upgrade is required research any data conversions etc.
a. If the source and destination application are the same consider connecting both systems (Linux initially read-only) and test to ensure that the data can be used without any translation or conversion.
b. If conversion is required you must plan for the identical amount of storage to be (temporarily) available to Linux in order to test migration etc.
7. Check (equivalent) device-drivers are available on Linux and ensure that fibre-cards etc, can connect to the SAN or network at the same or improved speed.
8. Patch the AIX environment as much as possible and do all possible hardening and tuning in order to ensure that the source systems are in the best possible state.
9. Attempt to measure user perception(s) and experience in order to create a baseline otherwise users may attribute existing problems to the migration.
a. Identify any known issues or bugs because if something is broken in source it will be broken in target.
10. Use your current partition inventory to estimate the number of processors and memory sizings required for the target Linux systems.
11. Create some test cases such as reading 10GB of data, or having 100 users simultaneously logged-in in order to create a PVU ratio e.g. one Power7 PROC=4 Intel PROCS, or one HP Blade can handle the equivalent workload as an LPAR with 0.4 VPROCS.
12. Consult the application vendors such as Oracle to see if Intel has special requirements e.g. an AIX system with a 3GB SGA needs be increased to 4GB on Intel.
13. Check if any special permissions are in place on AIX e.g. RBAC and ensure that there is a conversion plan.
14. Ensure that any existing monitoring systems can handle both AIX and Linux, or that there is a migration plan.
15. Check any existing backup data can still be recovered after the migration.
16. Ensure there is a backup plan in place to replace the existing arrangements.
17. AIX uses NIM and mksysb for provisioning and bare-metal recovery. Linux uses Kickstart in place of NIM, however there is no direct replacement for mksysb. Suggest using Storix as it works on both platforms.
a. Create a Linux satellite server in order to centrally control the release and installation of patches.
18. Ensure that Linux support and licencing is fit for purpose and is budgeted for going forward.
19. Research all file-transfer (MFT) connections and where possible centralise them using a solution such as GoAnywhere as this will enable you to test both the source and target environments whilst maintain a central single point of control.
20. If you intend to migrate middleware such as WMQ to an open-source solution you must also check that there is a way to compare both solutions and/or to run them in parallel using some kind of message gateway.
21. Do you intend to do a big-bang, or a gradual conversion. In either case do you have adequate fallback and DR plans?
22. How long do change requests etc take and what is the size of any change window? If you now this you can ensure that no change takes more than 40% of this Window in order to allow for management meetings and fallback decisions.
23. Plan dry-runs and dress rehearsals.
24. Decide whether the new solution will be locally or cloud-based and ensure that there are DR plans in place.
25 .Finally you should ensure that your LInux supplier can provide adequate support and there are suitable support arrangments in place.
No comments:
Post a Comment