You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "Kyle R Dunn (JIRA)" <ji...@apache.org> on 2018/02/22 21:12:00 UTC
[jira] [Updated] (GEODE-4726) Documentation is misleading with a
multi-homed Geode cluster
[ https://issues.apache.org/jira/browse/GEODE-4726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kyle R Dunn updated GEODE-4726:
-------------------------------
Description:
Trying to bind Geode to an arbitrary network interface (e.g. {{eth2}}), requires some non-obvious parameters to be set. Some of these parameters appear to be unrelated to multi-homing entirely, yet are necessary for both a locator and server to start correctly.
For example, 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.
Additionally, the {{hostname-for-clients}} parameter appears to be required for certain Geode extensions to function once added to the {{CLASSPATH}} - in my case it was a propriety Pivotal extension (GGC).
{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 --hostname-for-clients=172.16.139.1
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:
Trying to bind Geode to an arbitrary network interface (e.g. {{eth2}}), requires some non-obvious parameters to be set. Some of these parameters appear to be unrelated to multi-homing entirely, yet are necessary for both a locator and server to start correctly.
For example, 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.
Additionally, the {{hostname-for-clients}} parameter appears to be required for certain Geode extensions to function once added to the {{CLASSPATH}} - in my case it was a propriety Pivotal extension (GGC).
{code:shell}
// 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 --hostname-for-clients=172.16.139.1
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
>
> Trying to bind Geode to an arbitrary network interface (e.g. {{eth2}}), requires some non-obvious parameters to be set. Some of these parameters appear to be unrelated to multi-homing entirely, yet are necessary for both a locator and server to start correctly.
> For example, 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.
> Additionally, the {{hostname-for-clients}} parameter appears to be required for certain Geode extensions to function once added to the {{CLASSPATH}} - in my case it was a propriety Pivotal extension (GGC).
> {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 --hostname-for-clients=172.16.139.1
> 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)