On 10/20/2015 03:13 PM, Cyril Scetbon wrote:
I'm trying to migrate from ipv4 to ipv6 for those
communications. I tried to follow a similar procedure as the one used
at CASSANDRA-8382
<https://issues.apache.org/jira/browse/CASSANDRA-8382?focusedCommentId=14259892&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14259892>.
When I do the change on the first
node, nodes seems to not see each other, if I trust nodetool :
As mentioned in the linked JIRA, I'm quite certain you will need to do
all IPv4 -> IPv6 address changes on all nodes at the same time for the
entire cluster - not one at a time.
_on first node :_
Datacenter: s1
==============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID
Rack
*DN 10.10.12.19* ? 256 ?
dab24e23-4b42-438e-9070-7994e329e868 i10
*UN* *2a01:c940:a5:2005:0:0:0:18* 244.35 MB 256 ?
03c558ec-add9-4dcd-bf2b-a1b28575e06b c10
This is likely due to the fact that an IPv6 address will not be really
able to route directly to an IPv4 address.
_on second node :_
_
_
Datacenter: s1
==============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID
Rack
*DN 10.10.12.18* 244.24 MB 256 100.0%
03c558ec-add9-4dcd-bf2b-a1b28575e06b c10
*UN 10.10.12.19* 244.11 MB 256 100.0%
dab24e23-4b42-438e-9070-7994e329e868 i10
Because the second node is not aware of the first, since there is no
communication established.
I can see in the first node logs that it tries to handshake with node
2, however I can't see neither error in node 1 logs nor information in
node 2 logs.
Of course, I'm trying to find a procedure that does not cause any
downtime of the whole cluster.
Doubtful that this is fully possible. It is very similar to the IPv4
example in the linked JIRA - the 10. and 192.168. networks cannot speak
to one another, so at least some downtime is to be expected here. Are
the connecting clients already dual-homed?
That said, there *may* be the possibility to use dual-homed IPv4/v6
interfaces and using listen_interface and isten_interface_prefer_ipv6:
true(?) From conf/cassandra.yaml
# If you choose to specify the interface by name and the interface has
an ipv4 and an ipv6 address
# you can specify which should be chosen using
listen_interface_prefer_ipv6. If false the first ipv4
# address will be used. If true the first ipv6 address will be used.
Defaults to false preferring
# ipv4. If there is only one address it will be selected regardless of
ipv4/ipv6.
listen_address: localhost
# listen_interface: eth0
# listen_interface_prefer_ipv6: false
I'd try out some different methods in a dev env - full listen_address:
edits and cluster restart; test out listen_interface: and a rolling
restart, perhaps. Practice your changes in dev, and worst case, you can
minimize downtime, if it's really necessary. You could be working on a
network migration no one else has really tried yet :)
--
Kind regards,
Michael
