This chapter focuses on the prerequisites needed to successfully deploy TimesTen Scaleout. These sections discuss the requirements for each host used in the grid:
TimesTen Scaleout is only supported on the Linux platform. For the supported Linux platform versions, see the "Platforms and configurations" section in the documentation library. For the most recent information about your particular TimesTen release, see the Oracle TimesTen In-Memory Database Release Notes (README.html) in your installation directory.
Perform these steps on all hosts that will run the management and data instances and membership servers for the grid:
Install the same operating system version and release on each host.
Configure all hosts in the same internal network.
When you set up your network, you must create a single internal network for all the grid components to communicate with each other. While clients may use the same internal network to connect to instances, you may wish to create an external network for client connections.
Install and configure NTP (Network Time Protocol). Clocks must be synced.
Ensure all instances in the grid can communicate with all other instances in the grid over the internal network on any port.
To avoid problems before and after installation, confirm your file system has sufficient space. (See "Storage provisioning for TimesTen" in Oracle TimesTen In-Memory Database Operations Guide for more information.)
These sections discuss the operating system prerequisites:
These sections describe and show how to create both the TimesTen users group and the operating system user (which will serve as the instance administrator):
TimesTen restricts access to the installation and the instances created from that installation to members of a single operating system group. This group, called the TimesTen users group, owns the installation and the instances created from the installation. Create this group (for example, timesten) and add the desired operating system users prior to installation. Once you create the TimesTen users group, you cannot change the name of the group or the group ID. See "Create the TimesTen users group and the OS user" for more information.
Note that:
The instance administrator's primary group must be the TimesTen users group.
Users who wish to access databases through TimesTen utilities or direct mode applications must be members of the TimesTen users group. This group can be the user's primary or secondary group.
Users connecting to a database through a client connection do not have to be members of the TimesTen users group.
The instance administrator for all instances in your grid is the operating system user who creates the active management instance. This user then becomes the instance administrator of all other instances in TimesTen Scaleout, including the second management instance and all data instances.
Note that:
The instance administrator cannot be the root user.
The instance administrator configures the grid, creates and manages the databases in the grid, starts and stops the databases in the grid, performs all management activities, and performs backup and restore operations.
You cannot change the instance administrator after that administrator creates the active management instance.
The instance administrator is a member of the TimesTen users group. See "The TimesTen users group" for more information.
The instance administrator's user name and UID, and the group name and the group id (GID) of the TimesTen users group must be the same on all hosts in the grid, including the hosts on which the management and data instances exist, as well as any of the SCP repository hosts.
The installation and the instances must have the same owner (the instance administrator).
In this example, instanceadmin is the name of the operating system user and timesten is the name of the TimesTen users group.
Create the TimesTen users group. Name the group timesten with group ID 10000.
# sudo groupadd -g 10000 timesten
Create the instanceadmin user with UID 55000 and assign this user to the timesten primary group. Then, create a password for the instanceadmin user.
# sudo useradd -u 55000 -g timesten instanceadmin # sudo passwd instanceadmin
You must configure kernel parameters on the hosts that run instances.
For hosts that run data instances:
For hosts that run management instances:
A database in TimesTen Scaleout consists of elements, where each element stores a portion of data from the database. Each element resides in a shared memory segment. On Linux, shared memory segments consists of pages, where the default page size is normally 4 kB (4,096 bytes). You can verify the default page size by running the getconf PAGESIZE command:
% getconf PAGESIZE 4096
Configure these shared memory kernel parameters to control the size of the shared memory segment:
shmmax: The maximum size of a single shared memory segment expressed in bytes. The value must be large enough to accommodate the size of the total shared memory segment for the element.
shmall: The total size of all shared memory segments system wide. The value is expressed in multiples of the page size (4 kB) and must be greater or equal to the value of shmmax. It is recommended that you set the value of shmall to less than or equal to the total amount of physical RAM. To display the total amount of physical memory, run the Linux cat /proc/meminfo command.
The size of the element is based on the values of the PermSize, TempSize, LogBufMB and Connections connection attributes. The element sizing formula is:
PermSize + TempSize + LogBufMB + 1 + (0.042 * Connections)
The PermSize, TempSize, and LogBufMB values are expressed in MB (megabytes). PermSize, TempSize, LogBufMB, and Connections are connection attributes that you define in your database definition file. If you do not define values for these attributes, TimesTen uses the default values. See "PermSize," "TempSize," and "LogBufMB" in the Oracle TimesTen In-Memory Database Reference for details on each connection attribute.
See "Determining the value of the PermSize attribute" for information on determining the PermSize value. See "Modifying the connection attributes of a database" for information on modifying the PermSize or TempSize attribute.
As an example, assume each element has a PermSize value of 32 GB (32,768 MB), a TempSize value of 4 GB (4,096 MB), a LogBufMB value of 1 GB (1,024 MB) and a Connections value of 2,048. Applying the sizing formula, the size of each element is:
37975 MB (32768 MB + 4096 MB + 1024 MB + 1 + (0.042 MB * 2048))
Notes:
For hosts that will run management instances, sizeshmmax and shmall based on a shared memory segment size of at least 400 MB. You can increase the settings of shmmax and shmall if there are other applications that require them to be greater.
The shmmax and shmall values must be the same on each of the hosts that will run data instances. Similarly, the values must be the same on each host that will run management instances.
In this example, to size shmmax and shmall:
As the root user, edit the /etc/sysctl.conf file, modifying kernel.shmmax and kernel.shmall. Assuming the size of the element is 37,975 MB and the shmmax and shmall values must be greater than the size of the element, for this example, set shmmax to 48 GB (51,539,607,552 bytes) and shmall to 56 GB (60,129,542,144 bytes = 58,720,256 kB /4 kB page size = 14,680,064 kB pages).
# sudo vi /etc/sysctl.conf ... kernel.shmmax=51539607552 kernel.shmall=14680064
To reload the settings from the modified /etc/sysctl.conf file:
# sudo /sbin/sysctl -p
Run the Linux ipcs lm command to display the current shmmax and shmall settings. The max seg size (kbytes) is the shmmax value and the max total shared memory (kbytes) is the shmall value. The shmmax value expressed in kB is 50,331,658 (51,539,607,552 bytes) and the shmall value expressed in kB is 58,720,256 (60,129,542,144 bytes).
% ipcs -lm ------ Shared Memory Limits -------- max number of segments = 4096 max seg size (kbytes) = 50331648 max total shared memory (kbytes) = 58720256 min seg size (bytes) = 1
Note:
The settings forshmmax and shmall in these examples can be increased if there are other applications that require them to be greater.You can configure HugePages for more efficient memory management. For hosts that will run management instances, there is no requirement to configure HugePages. For hosts that will run data instances, if the element's shared memory segment is greater than 256 GB, you must configure HugePages. Once configured, the memory allocated for HugePages is taken from the total RAM on the Linux system and is not available for any other use. In addition, the HugePages memory segment is automatically locked and cannot be swapped to the file system.
To configure HugePages, you need to know:
The maximum size of the shared memory segment for the element
The HugePages page size on your Linux system
The group ID of the instance administrator
Using the examples in the "Configure shmmax and shmall" section, where the size of the element is 37,975 MB and the shmmax value is 48 GB and the "Create the TimesTen users group and the OS user" section, where the group ID of the instanceadmin user is 10000:
The size of the total shared memory segment is 48 GB.
The HugePages page size is 2,048 kB. (This value is fixed for each platform and is not configurable.)
To determine the HugePages page size, run the Linux cat /proc/meminfo|grep Hugepagesize command:
% cat /proc/meminfo | grep Hugepagesize Hugepagesize: 2048 kB
The group ID is 10,000.
To determine the group ID of the instance administrator, log in as the instanceadmin user, and run the Linux id command:
% id uid=55000(instanceadmin) gid=10000(g10000)groups=10000(g10000)
To configure HugePages:
Determine the number of HugePages by dividing the size of the total shared memory segment (expressed in MB) by the value of Hugepagesize (expressed in MB). In this example, the total shared memory segment for the element is 48 GB (49,152 MB) and the Hugepagesize value is 2,048 kB (2 MB):
49152 MB/ 2 MB = 24576
As the root user, edit the /etc/sysctl.conf file, and set vm.nr_hugepages to the number of HugePages (24,576 in the example) and set vm.hugetlb_shm_group to the group ID of the instance administrator (10,000 in the example). The latter setting restricts access to HugePages to members of the group.
# sudo vi /etc/sysctl.conf ... ... vm.nr_hugepages=24576 vm.hugetlb_shm_group=10000
Reload the settings from the modified /etc/sysctl.conf file:
# sudo /sbin/sysctl -p
To verify that you have configured HugePages correctly, run the Linux cat/proc/meminfo|grep HugePages command and verify the value for HugePages_Total is 24,576 and the value for HugePages_Free is 24,576.
% cat /proc/meminfo|grep HugePages HugePages_Total: 24576 HugePages_Free: 24576 ...
Notes:
For hosts that will run data instances, HugePages for these hosts must be the same.
Because HugePages must be allocated in contiguous available memory space, the requested allocation may not be granted, or may be only partially granted, until after the system is restarted. Check the HugePages_Total and HugePages_Free values from /proc/meminfo. Restarting grants the full allocation, assuming enough memory is available in the system.
If a database less than or equal to 256 GB does not fit into the available HugePages space, regular pages are used. If a database greater than 256 GB does not fit into the HugePages space, the database cannot be loaded into memory.
The TimesTen PL/SQL shared memory segment consumes some of the configured HugePages allocation, determined by the value of the PLSQL_MEMORY_SIZE connection attribute. See "PLSQL_MEMORY_SIZE" in the Oracle TimesTen In-Memory Database Reference for more information.
On Linux, the HugePages segment is automatically locked such that the memory segment is not a candidate to be swapped to the file system. Therefore, if you configure HugePages, you do not need to set the MemoryLock connection attribute.
The memlock entries in the /etc/security/limits.conf file control the amount of memory a user can lock. These entries are set at the system level and are different than the MemoryLock connection attribute setting. For hosts that will run management instances, setting the memlock settings is optional. For hosts that will run data instances, set the hard memlock and soft memlock entries (expressed in kB) to the size of the shared memory segment for each element. If HugePages are configured, the memlock values must be large enough to accommodate the size of the shared memory segment or the element will not be loaded into memory.
For example, for the instanceadmin user, assuming a total shared memory segment size of 48 GB (49,152 MB), set the memlock entries to 50,331,648 kB (49,152 * 1,024):
As the root user, edit the /etc/security/limits.conf file, and set the memlock entries to 50,331,648 kB for the instanceadmin user. This value indicates the total amount of memory the instanceadmin user can lock.
# sudo vi /etc/security/limits.conf ... ... instanceadmin soft memlock 50331648 instanceadmin hard memlock 50331648
As the instanceadmin user, log out and log in again for the changes to take effect.
Notes:
For hosts that will run data instances, thememlock settings for these hosts must be the same. Similarly, if you set memlock settings for hosts that will run management instances, the memlock settings for these hosts must be the same.TimesTen has an upper bound on the maximum number of connections to the database. The database connections consist of:
User connections: established by user applications
System connections: established internally by TimesTen (set at 48 connections)
The number of user connections is the sum of all user connections across all elements of the grid, not just the user connections to the local grid element. For example, if the grid will support 10,000 concurrent applications, each host running the data instance must be configured to support the 10,000 connections (plus the system connections).
Each user and system connection (a database connection) is assigned one semaphore, such that the total semaphores for a database are:
Total semaphores = user connections (N) + system connections (48) +
other required connections (107)
Total semaphores = N + 155
The semaphore settings are located in the kernel.sem configuration directive in /etc/sysctl.conf:
kernel.sem = SEMMSL SEMMNS SEMOPM SEMMNI
where:
SEMMSL is the maximum number of semaphores per array. Configure this value to 155 plus the number of connections.
SEMMNS is the maximum number of semaphores system wide. Use the formula SEMMNS = (SEMMNI * SEMMSL) as a guideline.
SEMOPM is the maximum number of operations for each semop call.
SEMMNI is the maximum number of arrays.
Follow these steps to configure the SEMMSL and SEMMNS settings (Ensure that the user is root):
View the existing kernel parameter settings:
# /sbin/sysctl -a | grep kernel.sem kernel.sem = 2500 320000 1000 1280
Edit the /etc/sysctl.conf file, changing semmsl (the first value in kernel.sem) to 155 plus the number of connections. For hosts that will run management instances, the number of connections is 400. For hosts that will run data instances, the number of connections is not fixed. In this example, to support up to 3,845 connections, set the semmsl value to 4,000 (155 + 3,845). Change semmns (the second value in kernel.sem) to 400,000.
# sudo vi /etc/sysctl.conf ... ... kernel.sem = 4000 400000 2000 2560
Reload the settings from the modified /etc/sysctl.conf file:
# sudo /sbin/sysctl -p
Note:
For hosts that will run data instances, the semaphore values for these hosts must be the same. Similarly, for hosts that will run management instances, the semaphore values for these hosts must be the same.For most production environments, TimesTen Scaleout requires a single private internal network and at least one external network. This section describes the requirements for those networks.
Instances in a grid communicate with each other over a single internal network using the TCP protocol. TimesTen Scaleout uses this network to perform all SQL, backup, and management operations required by the grid and its databases. In addition, instances communicate with membership servers through this network. Membership servers use this network to communicate among themselves.
Ensure that your internal network has these characteristics:
High bandwidth. The faster the network the better, in terms of throughput (gigabits per second). For production environments, ensure at minimum a 10 Gigabit Ethernet network or equivalent.
Low latency. To reduce network latency (time to transmit a message from one host to another) to a minimum, the hosts and membership servers attached to your internal network should either:
Span a single data center within a small number of racks.
Span multiple data centers within a small geographic region (city or suburb) connected by a metropolitan area network (MAN). Only recommended with a 10 GbE network or better.
Not span multiple data regions (states or provinces) connected by a wide area network (WAN).
IPv4 or IPv6 addresses.
No network address translation (NAT).
No TCP packet filtering.
For an on-premises environment, ensure your internal network meets these requirements:
If your internal network consists of a single network segment, all hosts are connected to a single Ethernet switch or equivalent.
If your internal network consists of multiple network segments, those segments are connected through bridges instead of IP routers.
If your internal network uses a MAN, ensure that the MAN can provide the required bandwidth and latency for your workload.
When you define a host for your grid, you must specify a single value for the internal address of that host. Optionally, you specify a value for that the external address of that host. The value you specify for the internal address of a host can be either an IPv4 address, an IPv6 address or a name that resolves into one or more IPv4 or IPv6 addresses. For example:
A dot-decimal IPv4 address such as 192.168.1.1
A colon-hexadecimal IPv6 address such as 2606:fe80::f816:3eff:fe15:44b3
A name specified in the /etc/hosts file such as host1
A name defined in a private Domain Name Server (DNS) such as int-host1.example.com
If you use a name to define the internal address of a host:
If the name resolves to multiple IP addresses, those addresses must be on the same network segment.
Every host in the grid must be able to resolve a name to the same addresses. For example, if you use the hosts file to define a name, then the hosts file on each host in the grid must contain identical entries for that name.
A grid may optionally use one or more public external networks. These networks enable applications running on machines that are not part of the grid to create client/server connections to databases in the grid. You cannot perform any grid or database management operations through an external network.
While the performance of an external network is important, it is less important than the performance of the internal network. If the internal network performs poorly or unreliably, the grid and its databases may perform poorly or unreliably for all users. Conversely, if an external network performs poorly or unreliably, it may only affect the applications connected to the databases in the grid through that network. As a result, there are fewer requirements for an external network than for the internal network.
Your external networks should have these characteristics:
Bandwidth based on the requirements of your client/server applications.
Latency based on the requirements of your client/server applications.
IPv4 or IPv6 addresses.
TCP connectivity to the server port of each data instance.
Any combination of network technologies (VPN, routers, LAN, WAN, etcetera).
If your grid uses a single external network, then the value you specify for the external address of a host can be in any of the forms described in the "Syntax for internal addresses" section. If your grid uses multiple external networks, then you must use a name to define the external address of a host. The name must resolve to at least one IP address for each external network you use.
When you unpack the TimesTen distribution on a host, you create an installation (that is read only). Do not add, alter, or remove files or directories within the installation, unless you are deleting the installation.
The installation may be a full installation or a client-only installation. A client-only installation supports the client use of TimesTen:
| Type | Description |
|---|---|
| Full installation | Use the TimesTen full distribution for this type of installation (for example, timesten181410.server.linux8664.zip). |
| Client-only installation | You can connect and access databases in TimesTen Classic through a client. Use the full installation (for example, timesten181410.server.linux8664.zip) to unpack the distribution and then specify ttInstanceCreate -clientonly. See "Database connections" for details on the types of clients and how they connect to a database. |
The operating system user that you designated as the instance administrator creates the installation by:
Downloading the TimesTen distribution on the host that will contain the active management instance. The distribution is a ZIP file where the ZIP file name indicates the platform, release number, and the type of distribution. For example, timesten181410.server.linux8664.zip.
Unpacking the ZIP file to create a TimesTen installation. The installation includes the binaries and the support files from which you can create a grid (and all of its components), membership servers, and clients
Only the first installation is created manually by the instance administrator on the host containing the active management instance. Additional installations used by additional instances are created by TimesTen Scaleout utilities. See "Configure your grid" for information on when to create additional installations for additional instances.
After you download the distribution, follow these steps:
Log in as the instance administrator to the host that will contain the initial management instance. In this example, instanceadmin is the name of the instance administrator. You can verify the instance administrator with the Linux id command.
Create the desired directory for the installation such as /grid/installation1.
% mkdir -p /grid/installation1
Extract and unpack the distribution file into the directory. This example unpacks the installation using the unzip command:
% unzip /timesten181410.server.linux8664.zip -d /grid/installation1
[...UNZIP OUTPUT...]
The top level directory of the installation is the TimesTen release. For example, the directory created under /grid/installation1 is:
dr-xr-x--- 19 instanceadmin timesten 4096 Mar 2 22:07 tt18.1.4.1.0
These sections provide details on how to verify your installation:
The ttInstallationCheck utility, located in the installation_dir/tt18.1.4.1.0/bin directory, verifies the success or failure of the installation. This utility generates an error if the checksum value for the installation differs from the original checksum value. Checksum values are different if there are any of these changes to the installation directory or files:
Contents of a file
Name of a file
Addition of a file to a directory
Removal of file from a directory
Changes to the permissions of a file or directory
In this example, the installation is verified:
% ttInstallationCheck This installation has been verified.
In this example, permissions on a file were changed, and ttInstallationCheck generates an error:
% ttInstallationCheck Cannot validate the installation in /grid/installation1/tt18.1.4.1.0.
See "ttInstallationCheck" in the Oracle TimesTen In-Memory Database Reference for detailed information on the ttInstallationCheck utility.
A TimesTen full installation includes these subdirectories located under the top-level installation_dir/tt18.1.4.1.0 directory.
3rdparty: Includes resources for:
Apache ZooKeeper
Java Message Service (JMS)
bin: TimesTen utilities and executables
grid: Files and resources for TimesTen Scaleout
include: TimesTen include files, among them timesten.h (for TimesTen ODBC features) and tt_errCode.h (for information about TimesTen error codes)
lib: TimesTen libraries
plsql: Files and resources for TimesTen PL/SQL
ttoracle_home: Oracle Database Instant Client files and resources, for OCI, Pro*C/C++, and ODP.NET
Note:
A client-only installation does not include the3rdparty or the grid directories.The instance administrator must be able to use SSH to log without a password to all hosts within a grid for the management instances and ttGridAdmin utility to be able set up and manage the grid and all its members.
Specifically, all hosts with management instances need passwordless SSH access for the instance administrator to all hosts with instances and repositories. Also, hosts with data instances need passwordless SSH access for the instance administrator to all hosts with repositories.
The ttGridAdmin gridSshConfig command is able to set for the current user the required passwordless SSH access. Ensure that you execute the command with the user you intend for instance administrator.
Before setting up a grid, you can run the ttGridAdmin gridSshConfig command while providing the addresses or DNS names that you will later use to host management instances, data instance, and repositories. When prompted, enter the OS password of the user executing the command. The user and password must already be set on all systems and be identical. See "Understanding the TimesTen users group and the operating system user" for more information on the instance administrator.
% grid/installation1/tt18.1.4.1.0/bin/ttGridAdmin gridSshConfig -mgmtAddress int-host1 int-host2 -dataAddress int-host3 int-host4 int-host5 int-host6 int-host7 int-host8 Enter password: Setup ssh configuration on local system...............................OK Setup ssh configuration on int-host1..................................OK Setup ssh configuration on int-host2..................................OK Setup ssh configuration on int-host3..................................OK Setup ssh configuration on int-host4..................................OK Setup ssh configuration on int-host5..................................OK Setup ssh configuration on int-host6..................................OK Setup ssh configuration on int-host7..................................OK Setup ssh configuration on int-host8..................................OK Setup passwordless ssh from local system to int-host1.................OK Setup passwordless ssh from local system to int-host2.................OK Setup passwordless ssh from local system to int-host3.................OK Setup passwordless ssh from local system to int-host4.................OK Setup passwordless ssh from local system to int-host5.................OK Setup passwordless ssh from local system to int-host6.................OK Setup passwordless ssh from local system to int-host7.................OK Setup passwordless ssh from local system to int-host8.................OK Setup passwordless ssh from int-host1 to int-host1....................OK Setup passwordless ssh from int-host1 to int-host2....................OK Setup passwordless ssh from int-host1 to int-host3....................OK Setup passwordless ssh from int-host1 to int-host4....................OK Setup passwordless ssh from int-host1 to int-host5....................OK Setup passwordless ssh from int-host1 to int-host6....................OK Setup passwordless ssh from int-host1 to int-host7....................OK Setup passwordless ssh from int-host1 to int-host8....................OK Setup passwordless ssh from int-host2 to int-host1....................OK Setup passwordless ssh from int-host2 to int-host2....................OK Setup passwordless ssh from int-host2 to int-host3....................OK Setup passwordless ssh from int-host2 to int-host4....................OK Setup passwordless ssh from int-host2 to int-host5....................OK Setup passwordless ssh from int-host2 to int-host6....................OK Setup passwordless ssh from int-host2 to int-host7....................OK Setup passwordless ssh from int-host2 to int-host8....................OK Passwordless ssh working between hosts: From\To int-host1 int-host2 int-host3 int-host4 int-host5 ... int-host8 --------- --------- --------- --------- --------- --------- ... --------- *us* Yes Yes Yes Yes Yes ... Yes int-host1 Yes Yes Yes Yes Yes ... Yes int-host2 Yes Yes Yes Yes Yes ... Yes int-host3 N/A N/A N/A N/A N/A ... N/A int-host4 N/A N/A N/A N/A N/A ... N/A int-host5 N/A N/A N/A N/A N/A ... N/A int-host6 N/A N/A N/A N/A N/A ... N/A int-host7 N/A N/A N/A N/A N/A ... N/A int-host8 N/A N/A N/A N/A N/A ... N/A
For a grid where the latest version of the model has yet to be applied and new hosts and instances were added to the model, run the ttGridAdmin gridSshConfig command on the active management instance. The ttGridAdmin utility then will query the latest version of the model and set up the appropriate SSH connectivity amongst the hosts described in the model.
% ttGridAdmin gridSshConfig Enter password: Setup ssh configuration on local system...............................OK Setup ssh configuration on int-host1..................................OK Setup ssh configuration on int-host2..................................OK Setup ssh configuration on int-host3..................................OK Setup ssh configuration on int-host4..................................OK Setup ssh configuration on int-host5..................................OK Setup ssh configuration on int-host6..................................OK Setup ssh configuration on int-host7..................................OK Setup ssh configuration on int-host8..................................OK Setup passwordless ssh from local system to int-host1.................OK Setup passwordless ssh from local system to int-host2.................OK Setup passwordless ssh from local system to int-host3.................OK Setup passwordless ssh from local system to int-host4.................OK Setup passwordless ssh from local system to int-host5.................OK Setup passwordless ssh from local system to int-host6.................OK Setup passwordless ssh from local system to int-host7.................OK Setup passwordless ssh from local system to int-host8.................OK Setup passwordless ssh from int-host1 to int-host1....................OK Setup passwordless ssh from int-host1 to int-host2....................OK Setup passwordless ssh from int-host1 to int-host3....................OK Setup passwordless ssh from int-host1 to int-host4....................OK Setup passwordless ssh from int-host1 to int-host5....................OK Setup passwordless ssh from int-host1 to int-host6....................OK Setup passwordless ssh from int-host1 to int-host7....................OK Setup passwordless ssh from int-host1 to int-host8....................OK Setup passwordless ssh from int-host2 to int-host1....................OK Setup passwordless ssh from int-host2 to int-host2....................OK Setup passwordless ssh from int-host2 to int-host3....................OK Setup passwordless ssh from int-host2 to int-host4....................OK Setup passwordless ssh from int-host2 to int-host5....................OK Setup passwordless ssh from int-host2 to int-host6....................OK Setup passwordless ssh from int-host2 to int-host7....................OK Setup passwordless ssh from int-host2 to int-host8....................OK Passwordless ssh working between hosts: From\To int-host1 int-host2 int-host3 int-host4 int-host5 ... int-host8 --------- --------- --------- --------- --------- --------- ... --------- *us* Yes Yes Yes Yes Yes ... Yes int-host1 Yes Yes Yes Yes Yes ... Yes int-host2 Yes Yes Yes Yes Yes ... Yes int-host3 N/A N/A N/A N/A N/A ... N/A int-host4 N/A N/A N/A N/A N/A ... N/A int-host5 N/A N/A N/A N/A N/A ... N/A int-host6 N/A N/A N/A N/A N/A ... N/A int-host7 N/A N/A N/A N/A N/A ... N/A int-host8 N/A N/A N/A N/A N/A ... N/A
For more information on the ttGridAdmin gridSshConfig command, see "Configure SSH (gridSshConfig)" in the Oracle TimesTen In-Memory Database Reference.