Friday, May 20, 2022

Rackware - Workload Migration (RMM) - Part 1




Migrating application and database servers from on-prem to cloud is really challenging. Current era organizations are focusing to stretch towards clouds to optimize their workloads.  This gives immense pressure on IT architects and administrators on how swiftly and smoothly they can migrate servers to the cloud.  

After the migration, the next challenge is to have an optimal DR strategy. The best practice would be replicating the servers to different regions.  There are many tools in the market to address these challenges,  

RMM is a great tool to address migrations and DR strategies.

Product Overview

RackWare Migration Manager (RMM) is a third-party application that we employ as a Cloud Migration and Disaster Recovery solution. RMM is compatible with all of the major cloud providers including Oracle, Azure, AWS, and Google Cloud, and can also be used in On-premise scenarios.

The product consists of following areas :
  1. Discovery and Analysis
  2. Workload Migration
  3. Disaster Recovery and Backup
When organizations are planning to move their current VMware, Hyper-V, or Oracle VM to the cloud, RackWare is a really good solution to cater to this environment. This migration methodology in addressing migration at the VM level.

The following figures illustrate the RackWare Technology Support matrix:



At a high level, the RackWare CloudMotion process consists of:

1. Provisioning of the RackWare RMM instance.

2. Setup network ingress and egress rules allowing communication between source and target networks.

3. Initialize and license the RMM Server then start the RMM service.

4. Configuring SSH connectivity between source and the target server.

5. Create Cloud User and Policies

6. Create and configure a ‘Wave’ within the RackWare Admin UI. 

Note: If we are planning to use the same IP Address Subnets on the source and target networks we will require a bridge network.


The following is a link to RackWare documenation outlining the above process in greater detail.

Rackware RMM Migration Getting Started for Oracle  Marketplace | Hybrid Cloud Management Platform | Cloud Management Platform | RackWare



This figure illustrates how the RackWare Bridge provides the IP Aliasing.



Simplified diagram of the RRM to Bridge Server communication:



RackWare has different feature sets, unlocked via licensing options:

  1. RackWare Migration Manager
  2. RackWare Migration Manager (RMM) BYOL
  3. RackWare Disaster Recovery (SMB)
As a partner, to obtain licensing for POC purposes we can email licensing@rackwareinc.com to obtain a 30 day trial license.

Deployment Scenarios

There are 3 ways to deploy the RMM software.
  1. Install the software from yum package to RedHat Linux and derivative operating systems (eg Oracle Linux and CentOS).
  2. Import image from OCI block storage

https://objectstorage.us-ashburn-1.oraclecloud.com/p/3ShJEeISW-IgvrynXI1BMYUVNMc-4R2o8kaVcvI7S8T4MDE7-LQAXvw2ZNAxcRA1/n/rworacleuniversal/b/rackware-mkt-storage/o/RMM-7_4_0_307-base

  3. Provisioning from an OCI Marketplace image



In this article, we covered only product overview and deployment methods. Next article we will cover the installation and configuration part of the RMM server.
at No comments:
Labels:

Sunday, May 15, 2022

Clone 12c RDBMS Binary

 








We are currently living in the cloud era and the majority of organizations want to expand their database workloads to the cloud. The cloud environment gives a clear picture of costs and gives more flexibility to optimize the workload. challenging parts come when the organization wants to migrate on-prem database workloads to cloud environments. Even it comes to Oracle databases migration there are many aspects to address.

As a first step, migrating Oracle workloads from on-prem to cloud environment we need to make sure oracle binary levels are identical, It's important to match patch levels before working on a fresh installation. Installed patches can be compared via opatch utility tool by running "./opatch lspatches "

Here is a sample output below


[oracle@localhost OPatch]$

[oracle@localhost]$ ./opatch lspatches
33192694;OJVM RELEASE UPDATE: 19.13.0.0.211019 (33192694)
33192793;Database Release Update : 19.13.0.0.211019 (33192793)
33208123;OCW RELEASE UPDATE 19.13.0.0.0 (33208123)

OPatch succeeded.
[oracle@localhost]$


Installing the oracle RDBMS binary takes a considerable amount of effort and time. To address this matter, Oracle has introduced the method to perform binary cloning. Before cloning makes sure to install the required RPMs for Oracle RDBMS. 

In this article, I will cover the cloning steps and issue encountered during this cloning process.

There are many benefits of cloning the RDBMS binary, A few benefits are listed below.

  • One time installation and clone the installation to all other servers.
  • Simple to perform and it saves time and effort.
  • No need to fire Oracle Installer on all servers.

Consistent RDBMS binary backup can be taken from the source database by stopping the running database and the listener.

Backup RDBMS HOME 



############# Clone db home
cd /u01/app/oracle/product/12.1.0.2/
tar -cvf /backup/12C_BINARY_BKP/db_home_1_26012022_${HOSTNAME}.tar dbhome_1

Clone RDBMS binary

Running below mention commands with "/u01/app/oracle/product/12.1.0.2/dbhome_1/clone/bin/clone.pl" helps to clone oracle binary. 



/u01/app/oracle/product/12.1.0.2/dbhome_1/perl/bin/perl /u01/app/oracle/product/12.1.0.2/dbhome_1/clone/bin/clone.pl \
ORACLE_BASE="/u01/app/oracle/" ORACLE_HOME="/u01/app/oracle/product/12.1.0.2/dbhome_1" OSDBA_GROUP=dba -defaultHomeName

Sample output 



/u01/app/oracle/product/12.1.0.2/dbhome_1/perl/bin/perl /u01/app/oracle/product/12.1.0.2/dbhome_1/clone/bin/clone.pl \
ORACLE_BASE="/u01/app/oracle/" ORACLE_HOME="/u01/app/oracle/product/12.1.0.2/dbhome_1" OSDBA_GROUP=dba -defaultHomeName

[oracle@atz-retail-pos-ordb-dev-db02 dbhome_1]$ /u01/app/oracle/product/12.1.0.2/dbhome_1/perl/bin/perl /u01/app/oracle/product/12.1.0.2/dbhome_1/clone/bin/clone.pl ORACLE_BASE="/u01/app/oracle/" ORACLE_HOME="/u01/app/oracle/product/12.1.0.2/dbhome_1" OSDBA_GROUP=dba -defaultHomeName
./runInstaller -clone -waitForCompletion  "ORACLE_BASE=/u01/app/oracle/" "ORACLE_HOME=/u01/app/oracle/product/12.1.0.2/dbhome_1" "oracle_install_OSDBA=dba" -defaultHomeName  -silent -paramFile /u01/app/oracle/product/12.1.0.2/dbhome_1/clone/clone_oraparam.ini
Starting Oracle Universal Installer...

Checking Temp space: must be greater than 500 MB.   Actual 25367 MB    Passed
Checking swap space: must be greater than 500 MB.   Actual 15359 MB    Passed
Preparing to launch Oracle Universal Installer from /tmp/OraInstall2022-01-26_08-45-55PM. Please wait ...You can find the log of this install session at:
 /u01/app/oraInventory/logs/cloneActions2022-01-26_08-45-55PM.log
..................................................   5% Done.
..................................................   10% Done.
..................................................   15% Done.
..................................................   20% Done.
..................................................   25% Done.
..................................................   30% Done.
..................................................   35% Done.
..................................................   40% Done.
..................................................   45% Done.
..................................................   50% Done.
..................................................   55% Done.
..................................................   60% Done.
..................................................   65% Done.
..................................................   70% Done.
..................................................   75% Done.
..................................................   80% Done.
..................................................   85% Done.
..........
Copy files in progress.

Copy files successful.

Link binaries in progress.

Link binaries successful.

Setup files in progress.

Setup files successful.

Setup Inventory in progress.

Setup Inventory successful.

Finish Setup successful.
The cloning of OraHome1 was successful.
Please check '/u01/app/oraInventory/logs/cloneActions2022-01-26_08-45-55PM.log' for more details.

Setup Oracle Base in progress.

Setup Oracle Base successful.
..................................................   95% Done.

As a root user, execute the following script(s):
        1. /u01/app/oracle/product/12.1.0.2/dbhome_1/root.sh



..................................................   100% Done.



Execute root.sh 



### root.sh
[root@localhost installation]# /u01/app/oracle/product/12.1.0.2/dbhome_1/root.sh
Check /u01/app/oracle/product/12.1.0.2/dbhome_1/install/root_atz-retail-pos-ordb-dev-snap-db03_2022-01-31_19-54-49.log for the output of root script
[root@local-host ]#
[root@local-host ]# cat /u01/app/oracle/product/12.1.0.2/dbhome_1/install/root_atz-retail-pos-ordb-dev-snap-db03_2022-01-31_19-54-49.log
Performing root user operation.

The following environment variables are set as:
    ORACLE_OWNER= oracle
    ORACLE_HOME=  /u01/app/oracle/product/12.1.0.2/dbhome_1
   Copying dbhome to /usr/local/bin ...
   Copying oraenv to /usr/local/bin ...
   Copying coraenv to /usr/local/bin ...

Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root script.
Now product-specific root actions will be performed.
[root@localhost]#

Make sure to check the relinking log file for verification



### latest log 
view /u01/app/oracle/product/12.1.0.2/dbhome_1/install/relink.log

Relink 

In this scenario, We had faced issues while trying to create a database. Even though the cloning showed as successful, there were some relinking issues. The decision was to relink the binary manually using the below-listed commands.


cd $ORACLE_HOME/rdbms/lib
make -f $ORACLE_HOME/rdbms/lib/ins_rdbms.mk ipc_rds ioracle
$ORACLE_HOME/bin/relink all
$ORACLE_HOME/bin/skgxpinfo

Relink issues

Open the latest relink log file and "/u01/app/oracle/product/12.1.0.2/dbhome_1/install/relink.log" and search for errors. We found permission issues on two binary files.

test ! -f /u01/app/oracle/product/12.1.0.2/dbhome_1/bin/extjob || (\
   mv -f /u01/app/oracle/product/12.1.0.2/dbhome_1/bin/extjob /u01/app/oracle/product/12.1.0.2/dbhome_1/bin/extjobO &&\
   chmod 600 /u01/app/oracle/product/12.1.0.2/dbhome_1/bin/extjobO )
chmod: changing permissions of ‘/u01/app/oracle/product/12.1.0.2/dbhome_1/bin/extjobO’: Operation not permitted
make: [iextjob] Error 1 (ignored)
mv /u01/app/oracle/product/12.1.0.2/dbhome_1/rdbms/lib/extjob /u01/app/oracle/product/12.1.0.2/dbhome_1/bin/extjob

test ! -f /u01/app/oracle/product/12.1.0.2/dbhome_1/bin/jssu || (\
   mv -f /u01/app/oracle/product/12.1.0.2/dbhome_1/bin/jssu /u01/app/oracle/product/12.1.0.2/dbhome_1/bin/jssuO &&\
   chmod 600 /u01/app/oracle/product/12.1.0.2/dbhome_1/bin/jssuO )
chmod: changing permissions of ‘/u01/app/oracle/product/12.1.0.2/dbhome_1/bin/jssuO’: Operation not permitted
make: [ijssu] Error 1 (ignored)
mv /u01/app/oracle/product/12.1.0.2/dbhome_1/rdbms/lib/jssu /u01/app/oracle/product/12.1.0.2/dbhome_1/bin/jssu

Solution

Make sure to check the permission first on the binary before making any changes. To get a clear idea about the binary files, you have to check the permission on the source server. To overcome this permission error we changed the permission to oracle and performed relink again.


[oracle@localhost]$ ls -l /u01/app/oracle/product/12.1.0.2/dbhome_1/bin/extjobO
-rwsr-x---. 1 root oinstall 1630568 Jan 31 19:51 /u01/app/oracle/product/12.1.0.2/dbhome_1/bin/extjobO
[oracle@localhost]$ ls -l /u01/app/oracle/product/12.1.0.2/dbhome_1/bin/jssuO
-rwsr-x---. 1 root oinstall 46920 Jan 31 19:51 /u01/app/oracle/product/12.1.0.2/dbhome_1/bin/jssuO
[oracle@local-host]$

at No comments:
Labels:
Subscribe to: Posts (Atom)

Unified Auditing Housekeeping

  Intro  Data is the new currency. It is one of the most valuable organizational assets, however, if that data is not well...