In this configuration, LifeKeeper is used to build an active/standby cluster as shown below. LifeKeeper is deployed on an Azure VM with a multi-NIC configuration.
|Virtual Machine size||
Cluster node: Standard_A1 (1 core, 1.75 GB memory)
Client/Witness Server is Standard B1s (1 vcpu number, 1 GiB memory)
(0.25 core, 0.75GB memory)
30GiB (for Oracle DB) *Note 3
10GiB (for swap area)
(/dev/disk/cloud/azure_resource is not usable as a data disk *Note 2)
|[VIP protected with IP resources]||10.3.1.200|
|[IP to set in ILB]||10.3.1.200|
|ILB forwarding port||1521|
|ILB load balancing target hosts and ports||1521 port for each lk4lnode01/lk4lnode02|
|[Azure private IP address]||
Cluster node (Active) 10.3.1.11 / 10.3.2.11
Cluster node (Standby) 10.3.1.12 / 10.3.2.12
Client and Witness server 10.3.1.50
*Note 1: Prepare the instance size and virtual machine disks to satisfy Oracle installation requirements (1 GB of memory, Oracle database installation disk size, and swap area size).
*Note 2: Most Azure VMs contain a temporary disk (/dev/disk/cloud/azure_resource), which is not a managed Disk. The temporary disk provides short-term storage for applications and processes and is intended to only store data such as page or swap files. The temporary storage is automatically mounted on /mnt but in the examples below it is being mounted on /mnt/resource. The azure_resource is often the /dev/sdb device node but can be a different device node depending on the configuration. This temporary disk is NOT suitable to be used as a LifeKeeper protected device such as storage used with DataKeeper. Refer to the file /mnt/DATALOSS_WARNING_README.txt for more information.
*Note 3: Microsoft Azure shared disk requires the steeleye-lkSCSI3 recovery kit available starting with LifeKeeper 9.6.2.
|OS||RedHat Enterprise Linux 7.8 64bit|
|LifeKeeper||SIOS Protection Suite for Linux v9.5.2|
|Oracle||Oracle Database 19c (19.3) Enterprise Edition|
|Monitored items||VIP PROTECTED WITH IP RESOURCES / File system / DataReplication / Oracle DB / Oracle Listener|
In Azure, a “virtual network” (VNET) is created to enable communication between virtual machines (VMs). The VNET enables communication between VMs within this subnet by specifying a subnet.
When configuring a network on a VM on Azure, it is common to create a VNET beforehand and specify this VNET for the VM. VNET allows you to provide a virtual private network (VPN) to the VM. Optionally, a VPN can be connected to the on-premises environment to enable hybrid or cross-premises solutions. VNET can control network topology, including DNS and IP address range configuration, through the management portal and Azure PowerShell.