Hello Experts,
We have a perfectly functioning Dual Stack network based ALICE::Kolkata::EOS2 running Citrine with size 997.7 TB.Now we have planned to add new EOS FST disk servers in our existing ALICE::Kolkata::EOS2 instance to expand the eos space size . The existing EOS systems i.e. MGM/SLAVE and FSTs are running on Dual Stack network (IPv4 and IPv6). Now, currently we have no more IPv4 IPs, instead we have lots of IPv6 IPs.
So, is it possible to add new FSTs in existing EOS only with IPv6 ip addresses (without Dual Stack network)? If we use only IPv6 ip addresses in new FSTs, will that leave any impact between MGM/Slave and FSTs and in current setup?
ALICE is not ready for IPv6-only data servers. We are running many enough legacy jobs that only support IPv4. So some form of IPv4 access to all data must be implemented for the time being.
A very happy new year.
We want to add more storage in our EOS instance, but as my colleague updated, we do not have IPv4, so we can allocate only IPv6 to new FSTs or servers.
Kindly update that can we use only IPv6 for EOS FSTs?
Unfortunately I don’t have better news than last time. Only 48% of the worker nodes used by ALICE support IPv6. And we still run some legacy code with Xrootd 3 libraries and no IPv6 support. So an IPv6-only storage node will create problems since data will not be accessible for a large part of our jobs.
I suggest trying a setup like this, and maybe our EOS colleagues can help with suggestions on if / how it could be practically done.
Existing storage node:
Hostname: eos11.tier2-kol.res.in
IPv4: 144.16.112.25
IPv6: 2405:8a00:c012::e:11
EOS FST binding on port 1095
New storage node:
Hostname: eos12.tier2-kol.res.in
IPv4: 144.16.112.25 (same as eos11)
IPv6: 2405:8a00:c012::e:12
EOS FST binding on port 1096
Between eos11 and eos12: a private IPv4 network (same or different network card).
That plus setting a DNAT on eos11 to forward all traffic to eos12 on the private network would allow it to work. For as long as the MGM node would redirect clients to the public addresses, i.e.
eos11: 144.16.112.25:1095 (directly served)
eos12: 144.16.112.25:1096 (DNAT to eos11 on the private segment)
It will indeed route part of the traffic via one of the existing nodes, on the other hand will allow all existing clients to continue to work on IPv4.
While from a network point of view this should be possible, my question to our EOS colleagues is how to fake the MGM registration for the new node on IPv4, so that a different IPv4 address than that of the new FST is used instead of the private one.
If you see a simpler solution than the above please share it so we know how to best address such cases in the future.