On Premise -> Microsoft Azure
- 1 1. Introduction
- 2 2. Initial Setup and Configuration
- 3 3. Install, Configure and Run the Standby software
1. Introduction
The purpose of this Deployment guide is to demonstrate the way in which Dbvisit Standby 8.0 software can be used within the Azure Cloud Hosting Space. In this guide, we focus on the Primary being located 'on-premise' and a Standby database hosted in MS Azure Cloud. In another document, we focus on both the Primary and Standby databases hosted in the Azure Cloud.
A link that document can be found here
The setup will be from a Single Instance on-Premise Primary Database to a Single Instance Standby Database with Datafiles stored on standard filesystems on a Windows Platform. However, the options for configuring Dbvisit Standby are in no way limited to this.
2. Initial Setup and Configuration
2.1 Provisioning the Standby Server
Connect to Azure Portal and Select 'Compute' from the options for 'New'
In this guide, we are going to install and configure Dbvisit Standby on Windows so the Azure Virtual Machine will run Windows Server 2016 Datacenter.
Clicking "create" directed us to a wizard with the following Steps.
Step 1 "Basics": configures the name of the VM and adds an 'Admin User', Subscription and Resource Group. License details are also entered here. Choosing No for the Windows Server License here means the daily cost of the VM increases as the Windows Server License costs are bundled into the daily price for the VM.
There was already resource group 'dbvresgrp' created during a previous VM creation.
Step 2 "Choose Virtual Machine Size". The size of both VMs in this Guide is DS11 Standard consisting of 2 vCPUs, 14GB Memory and 28GB local SSD.
Throughout this guide, no mention is made about the licensing implications of running Oracle software on Microsoft Azure. The setup we have here has been built for demonstration purposes and falls within the scope of the Microsoft Azure 'free-trial'. Further information regarding Oracle Licenses in the cloud can be found here. Also Licensing Oracle Software in the Cloud Computing Environment.
Specify the name of a new Virtual network (1) and Network Security Group (2).
The defaults were accepted for step 4 the VM was created.
Then, 'click' on the VM icon on the taskbar to view.
Connecting to the VM is via Microsoft Remote Desktop.
Within the dashboard home section, the connect icon downloads the RDP file required to connect.
The password can be stored and the connection details adjusted to reflect the machine name instead of just the IP.
In addition to this, clicking on the Redirection option allows a local drive to be mapped to the Machine. This was useful for copying both the Oracle and Dbvisit Standby binaries
The primary server is a Local Oracle Virtualbox Windows 2012 machine running Oracle 12.1.0.2. Dbvisit Standby v8 has already been installed and configured on this machine and a 12c Database is running.
An overview of both Primary and Standby machines is shown in the table below.
Primary Server Details | Standby Server Details |
|---|---|
Name: dbvwin202 Hosted: Oracle Virtualbox Running Locally vCPUs: 2 OS: Windows 2012 Memory: 3G Storage: 75G Version: 12.1.0.2 Edition: Enterprise Edition Database: LAA Dbvisit Base: C:\Program Files\Dbvisit Standby Version: 8.0.14.19191 | Name: dbvwin2016DR Hosted: Microsoft Azure vCPUs: 2 OS: Windows 2016 Datacenter Memory: 14G Storage: 28G Version: 12.1.0.2 Edition: Enterprise Edition Database: LAA Dbvisit Base: C:\Program Files\Dbvisit Standby Version: 8.0.14.19191 |
2.2 Preparing the Azure Server
Connect to the server using the Microsoft Remote Desktop details provided earlier and copy then unzip the required binaries for the Oracle and Dbvisit Installations from the local mapped drive.
In-depth details regarding the Oracle Binaries installation are outwith the scope of this guide. However, Oracle 12c binaries were installed under a new user 'oracle'.
One other point to note. It was found to be easier to pre-create the user for the Oracle install rather than choose this option as part of the binary installation. The reason for this, when the user is created as a windows administrator, the password policy is adhered to. However, when a password is chosen as part of the binary installation unless you are confident the password adheres to the correct security policy no check is made until the create user step is reached. If the password doesn't fit the security standards, the installation fails and exits.
In order for Dbvisit Standby to communicate between the 2 hosts, and to enable access to the GUI frontend, 3 ports need to be made available. These are 7890 (Dbvnet), 7891 (Dbvagent) and 4433 (dbvserver: GUI). To do this, security rules need to be added to the Network Security Group for the Azure VM. In addition to this, inbound and outbound firewall rules need to be added to both the Primary and Standby servers.
E.g. For the Network Security Group Associated with the DR machine
Configure additional Inbound and Outbound Security rules. For ease, a range encompassing all 3 ports can be used (as is shown here). But for maximum security create one rule per port.
Inbound Rules
Outbound rules.
On both Primary window host and standby, windows host add inbound and outbound firewall 'port' rules.
When using 'New Rule Wizard', note that the default 'Action' for the outbound rule is 'Block the connection'. This needs to be set to 'Allow the connection' which is the default action for a new 'Inbound Rule'
Windows 2016 Datacenter and Windows 2012 run IPv6 by default. This must be disabled as the final step to allowing connections between the servers.
Begin by 'un-checking' the IPv6 and then select the 'properties' of IPv4, then 'Advanced' and Enter an 'Interface metric'