Microsoft Azure -> 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 both the Primary and Standby databases being hosted on MS Azure Windows 2016 Virtual Machines. In another document, we focus on 'On-Premise Primary' to Standby in the Azure Cloud. A link that document can be found here
The setup will be from Single Instance Primary Database to 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 Servers
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 both Virtual Machines will be 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.
In the User Name box, 'Oracle' was entered. However, further on into the installation it was realised that choosing a more generic name such as dbvisit (admin is a reserved word and not allowed) would have made more sense. Creating a Windows VM meant that the Oracle binaries needed also to be installed (unlike when you chose an Oracle pre-built VM in Azure where the platform is Linux and the binaries are pre-installed). The installation of the Oracle binaries insisted that the installing user not be an administrator and suggested to create a new user. Therefore it was not possible to use the oracle user to install the binaries and instead user dbvisit was created. This, in turn, meant the $ORACLE_HOME didn't have 'oracle' in the directory_path. (A minor annoyance, but still worth a mention to think about the users before creating the VMs)
It was decided to keep this in the guide as an information point.
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 and the VM was created. This process was then repeated for the 2nd VM.
Then, 'click' on the VM icon on the taskbar to view the VMs.
Connecting to each of the VM is via Microsoft Remote Desktop.
Within the dashboard home section of each VM, the connect icon downloads the RDP file required to connect.
The password details can be stored for each VM and the connection details adjusted to reflect the machine name instead of just the IP.
In addition to the 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
Summary Details of the 2 VMs are as follows :
Primary Server Details | Standby Server Details |
|---|---|
Name: dbvwin2016 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 | Name: dbvwin2016DR 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 Servers
Connect to each of the servers using the Microsoft Remote Desktop details provided earlier and copy and 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 and a database running ARCHIVELOG mode pre-created under the new dbvisit user.
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.
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 each Network Security Group for each node and, also inbound and outbound firewall rules need to be added to the VMs themselves.
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.
Perform the same task on each server.
In addition to this, add inbound and outbound firewall 'port' rules to the servers themselves.
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'