On 2019-01-08 9:22 p.m., Sage Weil wrote:
I have a question about how to handle mon upgrades to nautilus. Nautilus
will support the new v2 protocol on port 3300 (which notably will
support encryption over the wire). By default the mon will bind to both
the v1 and v2 ports (3300, 6789) for new clusters so that newer clients
will use the new protocol and older clients the old protocol.
The firewalld.conf file that is included in the ceph package already
whitelists both ports (the IANA-assigned 3300 was given to us a couple
years back but we're just now getting around to using it).
So... if there is no firewalling, or firewalld is the firewall being used,
then having the mons automagically reconfigure themselves to bind to the
new port when the nautilus upgrade completes would work.
But if someone has a non-standard firewall config, having mons
reconfigure themselves would mean 3300 would appear in the monmap and
clients trying to use 3300 would be unable to connect: even if they also
support 6789, we always prefer (and switch over to) the new 3300 port if
it is listed.
So we can either:
1) have a big warning in the upgrade notes to verify port 3300 is not
firewalled and automatically make the transition, or
2) have an explicit step that enables the new v2 protocol at port 3300,
something like
ceph mon enable-v2-port
The latter is an extra upgrade step admins have to do but is less likely
to make the mons appear to go dark during an upgrade.
We should probably do #2, right?
#2 + big red warning in upgrade notes. Many companies have internal
firewalls that work on both ends of the pipes and setting up firewalld on
mon node may be not enough.
--
Piotr Dałek
piotr.dalek@xxxxxxxxxxxx
https://www.ovhcloud.com
