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:
Add the following line:
The 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:
Otherwise, you might encounter following sudo error:
⚠️ 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:
Configuration
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:
The syntax of the configuration file is presented below:
The 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
Start the VIP:
Stop the VIP:
Check VIP Interface:
Or if “ifconfig” not available using the “ip” command:
Database integration/automation
The “dmk_vip.ksh” integration with the database is quite simple as it consists of two (2) components:
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
⚠️Please create the STARTUP_TRIGGER and the DBMS_SCHEDULER jobs as user SYS. DBMS_SCHEDULER jobs are executed as O.S user “ORACLE” if the owner is SYS otherwise the scripts are executed as the O.S pseudo-user “nobody.
Please refer to the Oracle Database administrator guide for details
Install trigger and scheduler jobs as follows:
Last updated