[GEODE-4726] Documentation is misleading with a multi-homed Geode cluster

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 1.7.0
• Component/s: configuration, docs
• Labels: pull-request-available
• Assignee: Karen Smoler Miller
• Reporter: Kyle R Dunn
• Created: 22/Feb/18 21:10
• Updated: 03/Oct/18 21:38
• Resolved: 13/Jul/18 23:39

Description

The necessary step for binding Geode to an arbitrary network interface (e.g. eth2), is not clearly documented. A multi-homing scenario (i.e. several non-loopback NICs) is quite common.

The server-bind-address=w.x.y.z parameter appears to have no effect on the interface used by the server process;  however passing bind-address=w.x.y.z to the server startup produces the correct startup behavior. The documentation around this is a bit misleading.

The symptom was a startup hang, ultimately timing out, like the following:

[info 2018/02/22 13:13:29.134 MST server1 <main> tid=0x1] Attempting to join the distributed system through coordinator 172.16.139.1(locator1:70192:locator)<ec><v0>:1024 using address 192.168.0.29(server1:70198):1024

The following script was used successfully on Mac OS to bind to the "last" interface listed by ifconfig (vmnet8).

#!/bin/bash

rm -rf locator1 server1

export GEODE_HOME=/opt/pivotal-gemfire-9.3.0
export CLASSPATH=${GEODE_HOME}/lib/gemfire-greenplum-3.1.1.jar

gfsh <<EOF
start locator --name=locator1 --locators=172.16.139.1[10334] --bind-address=172.16.139.1 --port=10334 --include-system-classpath

start server --name=server1 --start-rest-api=true --http-service-port=28080  --locators=172.16.139.1[10334] --bind-address=172.16.139.1 --cache-xml-file=../config/ggc_cache.xml --classpath=${CLASSPATH} --include-system-classpath

EOF

The contents of ggc_cache.xml is below.

<?xml version="1.0" encoding="UTF-8"?>
<cache xmlns="http://geode.apache.org/schema/cache"
  xmlns:gpdb="http://schema.pivotal.io/gemfire/gpdb"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://geode.apache.org/schema/cache
  http://geode.apache.org/schema/cache/cache-1.0.xsd
  http://schema.pivotal.io/gemfire/gpdb
  http://schema.pivotal.io/gemfire/gpdb/gpdb-2.4.xsd"
  version="1.0">

    <disk-store name="pdx_meta_data"/>

    <pdx read-serialized="true" persistent="true" disk-store-name="pdx_meta_data"/>
    
    <jndi-bindings>
      <jndi-binding jndi-name="DemoDatasource" type="SimpleDataSource"
          jdbc-driver-class="org.postgresql.Driver" user-name="gpadmin"
          password="supersecret" connection-url="jdbc:postgresql://172.16.139.132:5432/gemfire_db">
      </jndi-binding>
    </jndi-bindings>

    <region name="TestData" refid="PARTITION">
    </region>

    <region name="CustDim" refid="PARTITION">
          <gpdb:store datasource="DemoDatasource">
          <gpdb:types>
              <gpdb:pdx name="com.aexp.gemfire.demo.entity.Customer"
                  schema="public"
                  table="cust_dim">
                  <gpdb:id field="id" />
                  <gpdb:fields>
                      <gpdb:field name="id" column="id" class="java.lang.String" />
                      <gpdb:field name="Name" class="java.lang.String" />
                      <gpdb:field name="income" class="java.lang.Double" />
                  </gpdb:fields>
              </gpdb:pdx>
          </gpdb:types>
          </gpdb:store>
    </region>

    <!-- I put the following in as place mark to talk about enabling GemFire to watch
    and make sure the system doesn't run out of memory -->
    <resource-manager critical-heap-percentage="80" eviction-heap-percentage="75"/>
  
    <gpdb:gpfdist port="3333" />

</cache>

Issue Links

• links to: GitHub Pull Request #1999