[ 
https://issues.apache.org/jira/browse/GEODE-4726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kyle R Dunn updated GEODE-4726:
-------------------------------
    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:
{code:bash}
[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
{code}

{code:bash}
// 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
{code}

  was:
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:
{code:bash}
[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
{code]

{code:bash}
// 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
{code}


> Documentation is misleading with a multi-homed Geode cluster
> ------------------------------------------------------------
>
>                 Key: GEODE-4726
>                 URL: https://issues.apache.org/jira/browse/GEODE-4726
>             Project: Geode
>          Issue Type: Bug
>          Components: configuration
>            Reporter: Kyle R Dunn
>            Priority: Major
>
> 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:
> {code:bash}
> [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
> {code}
> {code:bash}
> // 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
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to