Library Version 12.1.3.0

Installation Configuration
Prev | Chapter 2. Installing Oracle NoSQL Database | Next

## Installation Configuration

Before you configure Oracle NoSQL Database, you should determine the following parameters for each Storage Node in the store:

- root

  Where the KVROOT directory should reside. There should be enough disk space on each node to hold the data to be stored in your Oracle NoSQL Database store. The KVROOT disk space requirements can be reduced if the storagedir parameter is used to store the data at a different location outside the KVROOT directory. It is best if the KVROOT is the same local directory path on each node (but not a shared or NFS mounted directory). The examples in this book assume that the KVROOT directory already exists.

- port

  The TCP/IP port on which Oracle NoSQL Database should be contacted. This port should be free (unused) on each node. It is sometimes referred to as the registry port. The examples in this book use port 5000.

- admin

  The port on which the Oracle NoSQL Database web-based Admin Console is contacted. This port only needs to be free on the node which runs the administration process. The examples in this book use port 5001. You can also change this port number by modifying the value of the `adminHttpPort` parameter. For more information, see Changing Parameters.

  ### Note

  Setting the value of -admin or the `adminHttpPort` parameter to 0 disables the web interface.

  The administration process can be replicated across multiple nodes, and so the port needs to be available on all the machines where it runs. In this way, if the administration process fails on one machine, it can continue to use the http web service on a different machine. You can actually use a different port for each node that runs an administration process, but for the sake of simplicity we recommend you be consistent.

- runadmin

  Forces an Admin to be included in the boot configuration even if `-admin 0` was specified.

  If `-admin 0` is specified in conjunction with `-runadmin`, the admin web interface will not be started.

  If `-runadmin` is not specified, the admin is included in the boot configuration only if an admin port value greater than 0 is specified.

- harange

  A range of free ports which the Replication Nodes use to communicate among themselves. These ports must be sequential and there must be at least as many as there are Replication Nodes running on each Storage Node in your store. The Storage Node Agent manages this allotment of ports, reserves one for an Admin service, and uses the rest to allocate one per Replication Node. The port range is specified as "startPort,endPort". "5010,5020" is used by the examples in this book.

- servicerange

  A range of ports that may be used for communication among administrative services running on a Storage Node and its managed services. This parameter is optional and is useful when services on a Storage Node must use specific ports for firewall or other security reasons. By default the services use anonymous ports. The format of the value string is "startPort,endPort." The value varies with the capacity of the Storage Node. For more information about the servicePortRange, see Storage Node Parameters.

- store-security

  Specifies if security will be used or not. In the examples in this book, no security is used.

  If `-store-security none` is specified, no security will be used.

  If `-store-security configure` is specified, security will be used and the security configuration utility will be invoked as part of the makebootconfig process.

  If `-store-security enable` is specified, security will be used. You will need to configure security either by utilizing the security configuration utility or by copying a previously created configuration from another system.

  For more information on configuring Oracle NoSQL Database securely, see the Oracle NoSQL Database Security Guide.

- capacity

  The total number of Replication Nodes a Storage Node can support. Capacity is an optional parameter. Capacity can be set to values greater than 1 when the Storage Node has sufficient disk, cpu, memory and network bandwidth to support multiple Replication Nodes.

  Please keep the following configuration considerations in mind for nodes with capacity greater than one:

  1. It is best if the Storage Node is configured with a capacity equal to the number of disks available on the machine. Such a configuration permits the placement of each Replication Node on its own disk and ensures that the Replication Nodes on the Storage Node are not competing for I/O resources. The location of this directory on its disk can be specified via the storagedir parameter.

     For example:

         > java -jar KVHOME/lib/kvstore.jar makebootconfig \
             -root /opt/ondb/var/kvroot \
             -port 5000 \
             -admin 5001 \
             -host node10
             -harange 5010,5025 \
             -store-security none \
             -capacity 3 \
             -storagedir /disk1/ondb/data \
             -storagedir /disk2/ondb/data \
             -storagedir /disk3/ondb/data \

     where capacity=3 equals the number of disks (disk1, disk2, disk3) located on the same Storage Node (node10).

  2. Increase the harange parameter to account for the additional ports required by the Replication Nodes.
  3. Increase the servicerange parameter to account for the additional ports required by the Replication Nodes.

  The value defaults to the number of storagedir parameters if they were specified. Otherwise the value defaults to "1". "1" is used as the capacity by the examples in this book.

- storagedir

  A path to the directory that will contain the environment associated with a Replication Node. For capacity values greater than one, multiple storagedir parameters must be specified, one for each Replication Node that will be hosted on the Storage Node. It is best if each directory path resolves to a separate disk. This is typically accomplished via suitable entries in /etc/fstab that attach the file system on a disk to an appropriate location in the overall directory hierarchy. Placing each environment on a distinct disk ensures that the Relocation Nodes are not competing for I/O resources. It also isolates the impact of a disk failure to a single environment.

  In the absence of explicit directory arguments the environments are located under the KVROOT directory.

- num_cpus

  The total number of processors on the machine available to the Replication Nodes. It is used to coordinate the use of processors across Replication Nodes. If the value is 0, the system will attempt to query the Storage Node to determine the number of processors on the machine. This value defaults to "0". "0" numCPUs is used by the examples in this book.

- memory_mb

  The total number of megabytes of memory that is available in the machine. It is used to guide the specification of the Replication Node's heap and cache sizes. This calculation becomes more critical if a Storage Node hosts multiple Replication Nodes, and must allocate memory between these processes. If the value is 0, the store will attempt to determine the amount of memory on the machine, but that value is only available when the JVM used is the Oracle Hotspot JVM. The default value is "0". "0" is used by the examples in this book.

Once you have determined this information, configure the installation:

1. Create the initial "boot config" configuration file using the `makebootconfig` utility. You should do this on each Oracle NoSQL Database node. You only need to specify the -admin option (the Admin Console port) on the node which hosts the initial Oracle NoSQL Database administration processes. (At a later point in this installation procedure, you deploy additional administration processes.)

   To create the "boot config" file, issue the following commands:

       > mkdir -p KVROOT     (if it does not already exist)
       > java -Xmx256m -Xms256m \
       -jar KVHOME/lib/kvstore.jar makebootconfig -root KVROOT \
                                                       -port 5000 \
                                                       -admin 5001 \
                                                       -host <hostname> \
                                                       -harange 5010,5020 \
                                                       -store-security none  \
                                                       -capacity 1 \
                                                       -num_cpus 0 \
                                                       -memory_mb 0

2. Start the Oracle NoSQL Database Storage Node Agent (SNA) on each of the Oracle NoSQL Database nodes. The SNA manages the Oracle NoSQL Database processes on each node. It also owns and manages the registry port, which is the main way to communicate with Oracle NoSQL Database processes on that node. You can use the `start` utility for this:

       nohup java -Xmx256m -Xms256m \
       -jar KVHOME/lib/kvstore.jar start -root KVROOT&

   ### Note

   If the Replication Node or Admin Service crashes, the SNA ensures that the processes restart.

3. Verify that the Oracle NoSQL Database processes are running using the `jps -m` command:

       > jps -m
       29400 ManagedService -root /tmp -class Admin -service
       BootstrapAdmin.13250 -config config.xml
       29394 StorageNodeAgentImpl -root /tmp -config config.xml

4. Ensure that the Oracle NoSQL Database client library can contact the Oracle NoSQL Database Storage Node Agent (SNA) by using the `ping` command:

       > java -Xmx256m -Xms256m \
       -jar KVHOME/lib/kvstore.jar ping -port 5000 -host node01

   If SNA is running, you see the following output:

       SNA at hostname: node01, registry port: 5000 is not registered.
       No further information is available

   This message is not an error, but instead it is telling you that only the SN process is running on the local host. Once Oracle NoSQL Database is fully configured, the ping option has more to say.

   If the SNA cannot be contacted, you see this instead:

       Could not connect to registry at node01:5000
       Connection refused to host: node01; nested exception is:
       java.net.ConnectException: Connection refused

If the Storage Nodes do not start up, you can look through the adminboot and snaboot logs in the KVROOT directory in order to identify the problem.

You can also use the -host option to check an SNA on a remote host:

    > java -Xmx256m -Xms256m \
    -jar KVHOME/lib/kvstore.jar ping -port 5000 -host node02
    SNA at hostname: node02, registry port: 5000 is not registered.  No
    further information is available

Assuming the Storage Nodes have all started successfully, you can configure the KVStore. This is described in the next chapter.

### Note

For best results, you should configure your nodes such that the SNA starts automatically when your node boots up. How this is done is a function of how your operating system is designed, and so is beyond the scope of this manual. See your operating system documentation for information on automatic application launch at bootup.

Prev | Up | Next
Installation | Home | Chapter 3. Plans