DMK_HA virtual IP solution for Unix/Linux
In order to provide efficient and fast connection possibilities while connecting to Oracle high available technologies (i.e Data Guard or Dbvisit) it is advised to configure and manage virtual IPs (VIP).
It might also happen that some applications do not support ADDRESS_LIST. This implies a direct IP and a port to connect to an Oracle database.
Up to june 2013, on Linux platforms dbi services advised the usage of the Corosync/Pacemaker framework to manage such a VIP. Unfortunately over the time, it appeared that this solution suffer from several drawbacks like the leak of information in the log files after an problem/crash and the poor documentation level. For this purpose dbi services decided to propose an additional solution to manage Virtual IPs in parallel to Corosync/Pacemaker.
The script called “dmk_vip.ksh” manages such VIP , it is furnished within this package and it allows to manage a vitual IP linked to a database.
ℹ️ Since RHEL/OL 7 the deprecated net-tools utilities (i.e ifconfig) are no more part of the O.S minimal installation. The new ipoute2 network utilities (ie ip); which are available since a while on the Linux distributions became the default. And therefore, iproute2 utilities are prioritized against net-tools (ifconfig).
Purpose
The script “dmk_vip.ksh” allows starting and stopping a VIP configured in a database context. The VIP configuration goes through a simple and easy configuration file (see later).
The purpose of the script is to manage VIP. It is easy to manage and robust. The main specifications of the tool are the following ones :
“dmk_vip.ksh” can manage several VIP (one per database)
before starting up a VIP it must make sure that the same VIP is not running somewhere else (in this case this VIP must be stopped)
“dmk_vip.ksh” should improve the re-ARP process which is necessary after having affected another MAC adress to the new VIP
“dmk_vip.ksh” should be programmed to be able to run on all Unixes with main focus on Linux
Specifications
The VIP specification consist in a list of parameters:
Oracle instance: SID
Address of the VIP (IP which will be used by Oracle clients to connect to the database)
Network mask in use for the VIP definition
Physical network interface to bind the VIP to
Listener to start while the VIP starts
Number of iterations to stop the VIP if the VIP is already running of multiple nodes (default: 2)
Requirements
Set sudo permissions
In order to be able to start a VIP on a UNIX network interface, the dmk_vip.ksh script will have to get some "root" privileges. Indeed the ifconfig, ip and arping command will be started as root.
For this purpose, as root, following authorization must be added in the "/etc/suoders" file through the visudo command:
[root@vmoraoel ~]# visudoAdd the following line:
oracle ALL = NOPASSWD: /sbin/ifconfig, /sbin/arping, /sbin/ipThe oracle user can call both commands ifconfig, ip and arping with root privileges without asking for any password.
Look at the sudo and visudo syntax for more details about the options and further possibilities. It might happen that you just have to add the both binaries at the end of an existing configuration.
Furthermore, as the script will be started from a database job, which is not a real TTY the sudo parameter “requiretty” must be commented out. When this flag is set, sudo can only be run from a login session and not via other means such as cron, shell/perl/python or cgi-bin scripts.
This flag is set on many distributions by default.
Edit /etc/sudoers, comment following line:
#Defaults requirettyOtherwise, you might encounter following sudo error:
sudo: sorry, you must have a tty to run sudo⚠️ Do not forget to deploy the sudo configuration on all nodes of High Availability environment.
SSH Passwordless login
It is mandatory that passwordless login for oracle user is set between the servers, for the script to run ssh connections without the need to enter any password. On each server run the script create_pwdless_ssh_login.sh from the deploy/VIP directory giving as argument the secondary server.
Example from one server vmtestoradg1 to the secondary one vmtestoradg2:
oracle@vmtestoradg1:/u01/app/oracle/local/dmk_ha/deploy/VIP/ [DB19C] ssh oracle@vmtestoradg2
no such identity: /home/oracle/.ssh_dbi/id_rsa: No such file or directory
oracle@vmtestoradg2's password:
oracle@vmtestoradg1:/u01/app/oracle/local/dmk_ha/deploy/VIP/ [DB19C] ./create_pwdless_ssh_login.sh vmtestoradg2
Remote server is vmtestoradg2. Would you like to continue (Y/N)? Y
Provide oracle password for host vmtestoradg2 :
Creating /home/oracle/.ssh_dbi directory
Generating public/private rsa key pair.
Your identification has been saved in /home/oracle/.ssh_dbi/id_rsa.
Your public key has been saved in /home/oracle/.ssh_dbi/id_rsa.pub.
The key fingerprint is:
SHA256:/Rk1+ZklTw2MWL0BdZo6udFZ7U9tSWowHf1rzSRKRKU oracle@vmtestoradg1
The key's randomart image is:
+---[RSA 2048]----+
| ++O= .|
| . +.=Bo|
| +E.B+B|
| . +==XO|
| S ..*+oBX|
| .o* =+|
| + . .|
| |
| |
+----[SHA256]-----+
/home/oracle/.ssh/config file exists, make backup
/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/oracle/.ssh_dbi/id_rsa.pub"
/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
oracle@vmtestoradg2's password:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'vmtestoradg2'"
and check to make sure that only the key(s) you wanted were added.
oracle@vmtestoradg1:/u01/app/oracle/local/dmk_ha/deploy/VIP/ [DB19C] ssh oracle@vmtestoradg2
Last login: Mon Dec 23 16:09:48 2024
Dummy:
------
Dummy : rdbms19250(19.25.0/dbhome_1)
Database(s):
------------
Open/(No)Mount : DB19C(19.25.0/dbhome_1)
Listener(s):
------------
Started : LISTENER(19.25.0/dbhome_1)
oracle@vmtestoradg2:/home/oracle/ [rdbms12201]externaljob.ora permissions
For the dbhome (primary and standby) the database is linked to, we need to setup externaljob permissions. externaljob.ora will be read by the externaljobscheduling system, and thus appropriate user and group needs to be setup. With root user, update externaljob.ora file and change nobody/nobody to oracle/oinstall.
Example:
oracle@SRV01:~/ [DB] ls -l $ORACLE_HOME/rdbms/admin/externaljob.ora
-rw-r-----. 1 root oinstall 1534 Dec 21 2005 /u01/app/oracle/product/19_20_0_0_RU230718_v0/rdbms/admin/externaljob.ora
oracle@SRV01:~/ [DB] grep ^run_ $ORACLE_HOME/rdbms/admin/externaljob.ora
run_user = nobody
run_group = nobody
oracle@SRV01:~/ [DB] echo $ORACLE_HOME
/u01/app/oracle/product/19_20_0_0_RU230718_v0
[root@SRV01 ~]# vi /u01/app/oracle/product/19_20_0_0_RU230718_v0/rdbms/admin/externaljob.ora
oracle@SRV01:~/ [DB] grep ^run_ $ORACLE_HOME/rdbms/admin/externaljob.ora
run_user = oracle
run_group = oinstallConfiguration
The complete “dmk_vip.ksh” configuration should be performed in the dmk_vip.conf file located in $DMK_HA/etc. A template configuration file available in $DMK_HA/templates:
cp ${DMK_HA}/templates/dmk_vip.cfg.unix \\
${DMK_HA}/etc/dmk_vip.cfgThe syntax of the configuration file is presented below:
#---------------------------------------------------------------------------
# Configuration file for VIP management of databases (dmk_vip.ksh)
#
# PRUPOSE : # Configures VIP attached to Oracle databases (and listeners)
#---------------------------------------------------------------------------
# Configuration format :
#
# SID:VIP_ADR:VIP_MASK:VIP_IF:<VIP_LSNR>
#
# SID : Oracle SID for which the VIP is configured - mandatory
# VIP_ADR : Address of the VIP - mandatory
# VIP_MASK : VIP Network address Mask - mandatory
# VIP_IF : Network interface to attach the VIP (i.e eth0) - mandatory
# VIP_LSNR : VIP Listener - optional
# VIP_STOPLOOP : Number of nodes on which dmk_vip.ksh will try to stop the
VIP
#
# Note :
#
# The usage of parameters delimitors allows to have potentially empty (not
# defined parameters)
#
# The listener LISTENER_DBITEST will be stoped/started by DMK
#
#---------------------------------------------------------------------------
# Example :
# <SID>:<VIP_ADR>:<VIP_MASK>:<VIP_IF>:<VIP_LSNR>:<VIP_STOPLOOP>
# DBITEST:172.22.1.4:255.255.0.0:eth0:LISTENER_DBITEST:1
# DBITEST:172.22.1.5:255.255.0.0:eth0::3The VIP (parameter VIP_ADR) will be started on the physical interface (VIP_IF) using the UNIX Virual IP. If iproutes2 network utilities are available on the system then the script will use the “ip” command. Otherwise, we will use the old fashion deprecated “ifconfig” net-tools utility, with following syntax: ethX:Y, where Y is the next free integer counter on the interface ethX : ethX:1, ethX:2, aso ... The counter is determined automatically by the dmk_vip.ksh script.
In case an Oracle listener must be also started against this VIP, its name must be added to the configuration line (parameter VIP_LSNR). The DMK script listener.ksh will be used to start this listener.
It is possible to define a number of iteration during dmk_vip.ksh will trying to stop existing VIPs with the same address. If, due to some wrong manipulations, the VIP has been started on several nodes, the dmk_vip.ksh script will try to stop all of them before starting the VIP on the local node. Per default these "zombies" VIP will be stopped on maximum two nodes. If the Data Guard or Dbvisit cluster has 4 nodes, it might be useful to try to stop the VIP "zombies" on all the nodes of the cluster before starting it on the local node, therefore increase VIP_STOPLOOP to 4.
⚠️Usually the dmk_vip.cfg file is the same on all nodes of the cluster, do not forget to deploy it on all nodes after any modification.
Usage
Configuration: dmk_vip.cfg
DBITEST:172.22.1.5:255.255.0.0:eth0::3Start the VIP:
oracle@vmoraoel:/u00/app/oracle// [rdbms11203] dmk_vip.ksh start DBITEST
...Stop the VIP:
oracle@vmoraoel:/u00/app/oracle// [rdbms11203] dmk_vip.ksh stop DBITEST
...Check VIP Interface:
oracle@vmoraoel:/u00/app/oracle// [rdbms11203] ifconfig
...
eth0:1 Link encap:Ethernet HWaddr 00:50:56:85:00:07
inet addr:172.22.1.5 Bcast:172.22.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
...Or if “ifconfig” not available using the “ip” command:
oracle@vmoraoel:/u00/app/oracle// [rdbms11203] ip addr show
...
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
UP qlen 1000
link/ether 08:00:27:ff:b2:12 brd ff:ff:ff:ff:ff:ff
inet 172.22.1.2/24 brd 192.168.56.255 scope global eth0
inet 172.22.1.5/24 scope global secondary eth0
inet6 fe80::a00:27ff:feff:b212/64 scope link
valid_lft forever preferred_lft forever
...Database integration/automation
The “dmk_vip.ksh” integration with the database is quite simple as it consists of two (3) components:
A db user with appropriate permissions
A STARTUP_TRIGGER which fires after “startup on database” and if the current database role (V$DATABASE.database_role) is PRIMARY.
Executable DBMS_SCHEDULER jobs VIP_STOP and VIP_START
⚠️The script will not create the trigger and the scheduler jobs under SYS user, but under the username given in the scripts as argument
The integration database script is excepting an argument, the database username. For CDB make sure to use a common username starting with C##. For nonCDB omit it.
Before running the script, make sure the correct CDB/DB Instance is sourced, in our example here CDBOMF. In case of CDB the script needs to be run again the CDB$ROOT. Run the scripts as following as follows:
oracle@srv-ol8-ora-tmo:/u01/app/oracle/local/dmk_ha/deploy/VIP/ [CDBOMF (CDB$ROOT)] ./create_user_for_dmk_vip.sh C##VIPTEST
SQL*Plus: Release 19.0.0.0.0 - Production on Wed Apr 9 14:50:42 2025
Version 19.14.0.0.0
Copyright (c) 1982, 2021, Oracle. All rights reserved.
Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.14.0.0.0
SQL> set feed on
SQL>
SQL> CREATE USER &1 IDENTIFIED BY VALUES 'S:0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F;0F0F0F0F0F0F0F0F'
2 DEFAULT TABLESPACE USERS
3 TEMPORARY TABLESPACE TEMP
4 ACCOUNT LOCK;
old 1: CREATE USER &1 IDENTIFIED BY VALUES 'S:0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F;0F0F0F0F0F0F0F0F'
new 1: CREATE USER C##VIPTEST IDENTIFIED BY VALUES 'S:0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F;0F0F0F0F0F0F0F0F'
User created.
...
...
...The logs can be found in ${DMK_ORA_ADMIN_SID}/log
Last updated