Skip to main content

Hubble Accelerator Guides

Hubble Accelerator - System Configuration

In order to configure your network settings on the Accelerator, you need to make use of a built in script called ybnetconf.

The script can do three things: configure the identity of the machine, configure the networking of the machine and configure the root password of the machine.

The three sub-procedures will be asked sequentially every time the script is executed. They are not logically connected, e.g. you can skip options, as explained below.

For first and third sub-procedures there are 3 (technically 2) options: Yes, No and Enter. Typing “y” accesses the sub-procedure (see below for details).

Pressing Enter straight away or “n” and then Enter skips to the next sub-procedure. For the second sub- procedure, you can chose between dhcp and static settings, or just skip it by pressing Enter straight away.

  1. Configure the identity of the machine.
    1. The typical output when accessing the sub-procedure for configuring the identity of the machine is:

      characters - use dashes instead. The script trims all spaces, so for example entering "new identity" will result in "newidentity".

      Make sure you do not use backspace or the arrow keys while typing the identity of the machine. This may result in a problem that will force a reboot.

      Note: After you type in the new identity press Enter. The script will apply the changes and move on to the option to access the next sub-procedure.

  1. Configure the networking of the machine. You can switch between dhcp and static settings as well as specifying the static address, netmask,
    1. dns address and gateway address if the static setting is chosen.
    2. Picking dhcp returns you just this:

    3. Picking the static option leads to questions about static address, netmask, gateway, and dns servers. Those can be skipped to default to the current values, or new values can be entered. The following screen shot is an example of what may be displayed (it should not be strictly followed).

      In the example above, the machine has been configured to have a static IP of 10.13.1.83. That IP has a netmask of 24 and the gateway and DNS server has been set to 10.13.0.1.

      The static IP cannot be the same as the IP of the gateway or any of the DNS servers.

      The DNS server and gateway can be configured to be the same IP.

      There may be more than one DNS server IP address. These can be entered simply by inputting the multiple IP addresses separated by commas, e.g. 10.13.0.1,10.13.0.2.

      Note: Try to avoid using backspace as it result in problems with the output.

  1. Configure the root password of the machine.

    1. Picking “y” gives you the following output:

      Type in the password. Do NOT expect to see the password on the dialog, as it is hidden. Simply press ENTER when the password has been typed in. The output you should then see is:

      If anything else it displayed, it is recommended that you run the script again. Sometimes the password generator adds a “/” to the password which confuses both the script and the xml that has been generated “under the hood”. The password is maintained in an encrypted state.

Once you have finished with all the sub-procedures, the final result can be seen by running:

cat /config/config/config.xml

The output should be similar to:

In this example, the elements <identity>,<address>,<gateway>,<dns-server> and <root-password> display the entered settings.

If dhcp was picked, all of the <static> element is replaced with </dhcp>.

The changes take effect after the machine has been restarted. After the script is complete you can restart the machine by typing:

reboot;logout

Hubble Accelerator - Post-deployment Configuration

In order to configure the data drive, database, database users and tables, run ybvwconf from the accelerator's bash.

The script is executed three times. After the first and second run the accelerator reboots automatically.

When it is executed the first time, you will be prompted to specify the type of hypervisor the accelerator is running on and the name of the data drive to be used.

An example of a normal output after a first run:

Once the machine restarts, run ybvwconf again.

On the second run the expected output is:

The shell-init errors are expected behavior. The machine will reboot one more time.

After running the script for the last time, the expected output is:

Important: The output of the command on the third run will display database user names and passwords. It is very important that you take a note of these and keep them in a safe place, as you will need to use them when setting up replication, or when creating a connection to the Accelerator from Hubble.    

The script will then display out a number of SQL create statement commits and, and will finish with the following output:

At this point the script has now finished configuring the accelerator.

Hubble Accelerator - Adding an NFS Mount

This topic outlines the steps to add an NFS mount to the Hubble Accelerator. In the example procedure below, the NFS mount is intended to be used to access Archive redo logs from Qlik using the Direct access to logs option in the Hubble Tech Mirroring Overview details the replication options document.

  1. Open /config/config/config.xml:

    2. nano /config/config/config.xml

  2. Replace the values in {} and paste the code block right after </root-password> or right after

    </network> if </root-password> does not exist.

    <remote-files>

    <nfs name="{local_folder_name}">

    <host>{remote_host_ip}</host>

    <path>{remote_folder_path}</path>

    </nfs>

    </remote-files>

    e.g.

    <remote-files>

    <nfs name="attunity_logs">

    <host>10.13.0.16</host>

    <path>/logs</path>

    </nfs>

    </remote-files>

  3. Save the file, exit the editor and reboot.
  4. After reboot, there should be a folder, with the same name given in "" in the config, under / import.

    In this example, there should be a folder called attunity_logs and it should mirror whatever is in /logs in the remote host, e.g.:

    /import/attunity_logs

  5. Although different permissions configured, depending on how the shared folder is set up, the root should be able to write to it anyway.
Notes:
  • When the NFS Server is setup on the Oracle machine you may have to allow access for the folder to the IP address of the Accelerator Machine, as there is no password option with the mount.
  • If the files are mounted to a different location from where oracle is set to output them, then the following setting can be used in Qlik to override the path prefix:

Hubble Accelerator - SNMP Monitoring

Once Hubble is deployed in your infrastructure, resources can be monitored in the Hubble Application Server using SNMP protocol. SNMP is included in the Application Server. It can be accessed through the “hubble” read community.

Note that:

  • Only SNMPv2-MiB and HOST-RESOURCES-MiB are accessible (e.g. so that information like CPU and memory usage, mounted partitions, etc. can be monitored)
  • You can access both SNMP implementations by using the “hubble” read community.
  • If required, the implementation can be tested using a simple client such as snmpB (see https://sourceforge.net/projects/snmpb/).

Add NFS mounts for Dockerized Accelerator

This topic outlines the steps to add an NFS mount to a Hubble Accelerator running in a Docker container. In this example it is assumed that you have already set up a NFS server and you want to configure your dockerized accelerator to be able to view and read files from the NFS server.

After completing these steps, the dockerized accelerator will have access to the files that are in the export directory on the NFS server. This example assumes that you are sharing the /export/ accelerator directory. The files in that directory will appear in the containerized accelerator, in the / imports sub-directory defined by ACCL_YB_NFS_NAME_1, in this example /imports/nfs1.

On the NFS Server

  1. Edit the /etc/exports file to add an additional line with the docker accelerator host IP.

    2. If your dockerized accelerator is deployed in AWS then you are using the docker network. Add following line:

    /export/accelerator your_host_ip(rw,sync,no_subtree_check)

  2. Then restart the NFS server to apply the new configuration:

    3. systemctl restart nfs-kernel-server

On the Docker Accelerator Host

  1. On the accelerator host, edit the /etc/hubble/accelerator/.env and enter the following details:

    ACCL_YB_IDENTITY=hubble-docker-accelerator

    ACCL_YB_NFS_NAME_1=nfs1

    ACCL_YB_NFS_HOST_1=your_nfs_server_ip

    ACCL_YB_NFS_PATH_1=/export/accelerator

    ACCL_YB_NFS_NAME_1 will show in the accelerator as a sub-directory of /imports if the NFS is working correctly.

    ACCL_YB_NFS_HOST_1 is the NFS server IP address.

    ACCL_YB_NFS_PATH_1 is the path on the NFS server where the files will be copied from.

  2. Restart the docker container, making sure that replication has been stopped first. Then run the following commands on the host run:

    cd /etc/hubble/accelerator

    docker-compose -p accelerator down && docker-compose -p accelerator up -d

  3. Now check to see if the files on the NFS server appear in your accelerator Docker container:

    docker exec -ti accelerator_hubble_accelerator_1 sh -l -c "ls / imports/nfs1"

Workaround

If the default process described above does not work, the following workaround is available:

  1. Mount the NFS share folder into the host in any folder. e.g. /mnt/nfs_mount.
  2. Add NFS variables to the .env file with some dummy data, e.g.:

    ACCL_YB_NFS_NAME_1=nfs1

    ACCL_YB_NFS_HOST_1=local

    ACCL_YB_NFS_PATH_1=/import

  3. Edit the docker-compose.yml to add the volume to the running container, make sure you choose /import as a folder within the container:

    nano docker-compose.yml

    Add to the "volumes:" section "/mnt/data:/mnt/ybdata" as shown in the example below:

    ...

    volumes:

    /mnt/data:/mnt/ybdata /mount/point/on/the/host:/import

    ...

  4. Restart the docker container, making sure that replication has been stopped first. Then, on the host run the following commands:

    cd /etc/hubble/acceleratordocker-compose -p accelerator down && docker-compose -p accelerator up -d

    Note: If you want to use the functionality in the Admin tool to back up the Accelerator, make sure there is a folder within your nfs share called "dbbackup".

Migrate to a Dockerized Accelerator

This topic describes the steps necessary to migrate an Accelerator (VM or AWS) to a dockerized Accelerator. It assumes that your accelerator has already been deployed and that the data drive now needs to be migrated to a dockerised accelerator.

For both VM and AWS Accelerator, this involves detaching the data drive, attaching it to your new instance and then running through the installation steps.

Virtual Machine (VM) Accelerator

Detach Data Drive

Right-click the instance, select edit settings, then the Hard disk you want to detach, Take a note of the name of the disk, then click on Remove.

Attach to a new VM

Right-click the instance, select edit settings, and then click Add.

Select “Use an existing virtual disc”:

Select the data drive you removed in the first step.

Finally, install the Accelerator on docker. Refer to the Hubble Accelerator Installation on Docker topic in the Hubble Initial Deployment Guide for details.

AWS

Accelerator

Detach Data Drive

Identify the data drive in your Accelerator that you want to migrate on to the docker Accelerator. Right- click it and select Detach Volume.

Attach the Drive to a new AWS Instance

This AWS instance must be running Docker and docker compose. Select the drive you just detached and attach it to a new instance.

Finally, install the Accelerator on docker. Refer to the Hubble Accelerator Installation on Docker topic in the Hubble Initial Deployment Guide for details.

Was this article helpful?

We're sorry to hear that.