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.
Note that 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. Note that 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.
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 port range is specified as "startPort,endPort". "5010,5020" is used by the examples in this book.
servicerange
A second range of free ports that may be used by a Storage Node or a Replication Node when exporting RMI based services. Specifying this range is optional, and by default any available port may be used when exporting Storage or Replication Node services. The format of the value string is "startPort,endPort". This parameter is useful when there is a firewall between the clients and the nodes that comprise the store and the firewall is being used to restrict access to specific ports. See the section on Setting Store Parameters for more information about the servicePortRange.
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:
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 heirarchy. 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:
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 -jar KVHOME/lib/kvstore.jar makebootconfig -root KVROOT \
-port 5000 \
-admin 5001 \
-host <hostname> \
-harange 5010,5020 \
-capacity 1 \
-num_cpus 0 \
-memory_mb 0
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. You can use the
start utility for this:
nohup java -jar KVHOME/lib/kvstore.jar start -root KVROOT&
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
Ensure that the Oracle NoSQL Database client library can contact the
Oracle NoSQL Database Storage Node Agent (SNA) by using the
ping command:
> java -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 -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.
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.