Dbvisit Standby works with Oracle Cloud.
...
Here you can see details of the newly created dbvrep-se-three service:
Setup connectivity to the new VM:
Because there are a number of tasks I would like to initiate locally, the first thing I to do is establish a connection to dbvrep-se-three from my laptop. Here I make use of the SSH keys generated earlier (originally done on the primary server in my configuration, dbvrep-se-two, and copied to my laptop), which were entered as inputs at the service create stage:
...
Once this is done, I can then SSH to dbvrep-se-three directly, and establish SFTP connectivity, which I find usefulI find useful. Here you can find additional notes on configuring SSH for use with the Oracle Cloud.
What version of Linux are we running on these provisioned servers? A quick check reveals the following:
| No Format |
|---|
[oracle@dbvrep-se-three ~]$ uname -a Linux dbvrep-se-three 2.6.39-400.109.1.el6uek.x86_64 #1 SMP Tue Jun 4 23:21:51 PDT 2013 x86_64 x86_64 x86_64 GNU/Linux [oracle@dbvrep-se-three ~]$ cat /etc/*-release LSB_VERSION=base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch Oracle Linux Server release 6.4 Red Hat Enterprise Linux Server release 6.4 (Santiago) Oracle Linux Server release 6.4 |
With a clear view of this, we can now download the most recent version of Dbvisit Standby v7 for the platform (OEL6 in this case) from the Dbvisit website. Once complete, we then upload the file to the server. In the following, I have done so using FileZilla, and putting it to /tmp, but you free to select another location for this as you see fit:
...
Dbvisit Standby needs to be installed on both servers in our configuration, and so the installation files need to uploaded to both VMs. This is an important point to remember, because we will walk through this only once in the following example.
The installation process is a well documented one in the Dbvisit Standby online user guide – and a good place to begin is the prerequisites checklist.
...
You are, of course, welcome to change these values, but the default options make good sense and are more than acceptable. They are:
| No Format |
|---|
Install directory - /usr/dbvisit (should be amended to what you have chosen) Default user - oracle Dbvnet port - 7890 Dbvnet password - admin Dbvnet start after install - yes Dbvserver protocol - https Dbvserver https port - 8443 Dbvserver default user - admin Dbvserver default |
...
password - admin Dbvserver - start after installation - yes |
...
Afterwards the complete log of the installation process will look something like the following:
| No Format |
|---|
Thank you. Configuration is complete. Installation will commence now. >>> Installing Standby - the Dbvisit disaster recovery software... Installing product files... Updating and migrating existing DDC files in /usr/dbvisit... > Removing old DDC files with appended timestamps Updating and migrating existing DDC files in /usr/dbvisit/standby... > Removing old DDC files with appended timestamps Removing old product files... Dbvisit Standby installation complete. >>> Installing Dbvnet - the Dbvisit network layer... >>> Adjusting init script templates for product dbvnet... Please find some init script templates in the following directory: /usr/dbvisit/dbvnet/conf/init.d These templates will allow your Systems Administrator to automatically start Dbvserver after a database server reboot. Templates are available for Sun Solaris, IBM AIX, and the Linux flavours OpenSuSE, RedHat/Centos/Fedora & Debian/Ubuntu. >>> Starting Dbvnet daemon, please wait... Dbvnet is up and running on the following ip address and port: niop://10.196.243.122:7890 >>> Installing Dbvserver - the Dbvisit web interface... >>> Adjusting init script templates for product dbvserver... Please find some init script templates in the following directory: /usr/dbvisit/dbvserver/conf/init.d These templates will allow your Systems Administrator to automatically start Dbvserver after a database server reboot. Templates are available for Sun Solaris, IBM AIX, and the Linux flavours OpenSuSE, RedHat/Centos/Fedora & Debian/Ubuntu. >>> Starting Dbvserver daemon, please wait... Dbvserver is up and running. Please point your browser to the following URL to log in to the Dbvisit web interface: https://10.196.243.122:8443 Login user name is 'admin' (password 'admin') >>> Dbvisit product and component installation is now complete. >>> NEXT STEPS: CONFIGURE DBVISIT STANDBY VIA COMMAND LINE INTERFACE (CLI): cd /usr/dbvisit/standby ./dbvisit_setup Note: Dbvisit can also be configured and run through a (GUI) web browser. Dbvserver (dbvserverd) must be installed and started for this. >>> IMPORTANT - PLEASE NOTE THE FOLLOWING REQUIREMENTS BEFORE CONTINUING: > The Dbvisit Standby, Dbvnet, and Dbvserver software must be installed on both the primary and standby servers. > For network communication between the primary and standby server via Dbvnet port number 7890 must not be blocked by your firewalls. > Dbvnet must be up and running on both the primary and standby servers at all times. > If you wish to use Dbvserver, the Dbvisit web interface, then please ensure port 8443 is open on your servers' firewalls, as well. >>> Thank you for using Dbvisit software! |
If working with the defaults, as I have done, once the installer has completed you will be able to see the dbvserver (webserver) and dbvnet (communication channel) processes that have been started:
...
The next step then is to open ports to enable each of the VMs in the configuration to communicate with the other, by adding an entry in the /etc/hosts file. This resolves the internal IP (not the external one) for the machine on the other side to its given name, and will look something like this:
10.196.243.122 dbvrep-se-three
Once added, when you ping the server names they should resolve to the internal IP, although they will not return successful as there are additional ports which are yet to be opened to enable this communication. This is also the case when running the Dbvnet connection test, which is initiated as per the following, run from the (install_location)/dbvisit/dbvnet location:
...
A final step before creating a new configuration is to create the location (a directory) known as archdest on both servers. This is the location Dbvisit Standby will deliver the archive logs to (from Primary to DR) and retrieve them from on the DR side. Although this location is not technically required on the primary side initially, it pays to create it now as it will be needed should a Graceful Switchover (role reversal) action take place. I create the following, with full permissions to this directory, for the oracle user:
/u03/app/oracle/archdest
So, at this point, we have installed Dbvisit Standby on both of our servers and enabled communication on the required ports. We are now ready to create a new Dbvisit Standby configuration encompassing a primary and DR server pair, and the outcome of this is the production of the DDC file: the Dbvisit Standby Database Configuration file. The key point to make here is that, even though our servers and databases are entirely within the Oracle Cloud environment, the steps from hereon in are standard, and the same as doing this on any other on-premise/cloud/mixed system.
...