Add hostname support in Sentinel. (#8282)
This is both a bugfix and an enhancement.
Internally, Sentinel relies entirely on IP addresses to identify
instances. When configured with a new master, it also requires users to
specify and IP and not hostname.
However, replicas may use the replica-announce-ip configuration to
announce a hostname. When that happens, Sentinel fails to match the
announced hostname with the expected IP and considers that a different
instance, triggering reconfiguration, etc.
Another use case is where TLS is used and clients are expected to match
the hostname to connect to with the certificate's SAN attribute. To
properly implement this configuration, it is necessary for Sentinel to
redirect clients to a hostname rather than an IP address.
The new 'resolve-hostnames' configuration parameter determines if
Sentinel is willing to accept hostnames. It is set by default to no,
which maintains backwards compatibility and avoids unexpected DNS
resolution delays on systems with DNS configuration issues.
Internally, Sentinel continues to identify instances by their resolved
IP address and will also report the IP by default. The new
'announce-hostnames' parameter determines if Sentinel should prefer to
announce a hostname, when available, rather than an IP address. This
applies to addresses returned to clients, as well as their
representation in the configuration file, REPLICAOF configuration
commands, etc.
This commit also introduces SENTINEL CONFIG GET and SENTINEL CONFIG SET
which can be used to introspect or configure global Sentinel
configuration that was previously was only possible by directly
accessing the configuration file and possibly restarting the instance.
Co-authored-by: myl1024 <myl92916@qq.com>
Co-authored-by: sundb <sundbcn@gmail.com>
2021-01-28 12:09:11 +02:00
|
|
|
proc set_redis_announce_ip {addr} {
|
|
|
|
foreach_redis_id id {
|
|
|
|
R $id config set replica-announce-ip $addr
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
proc set_sentinel_config {keyword value} {
|
|
|
|
foreach_sentinel_id id {
|
|
|
|
S $id sentinel config set $keyword $value
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
proc set_all_instances_hostname {hostname} {
|
|
|
|
foreach_sentinel_id id {
|
|
|
|
set_instance_attrib sentinel $id host $hostname
|
|
|
|
}
|
|
|
|
foreach_redis_id id {
|
|
|
|
set_instance_attrib redis $id host $hostname
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
test "(pre-init) Configure instances and sentinel for hostname use" {
|
|
|
|
set ::host "localhost"
|
|
|
|
restart_killed_instances
|
|
|
|
set_all_instances_hostname $::host
|
|
|
|
set_redis_announce_ip $::host
|
|
|
|
set_sentinel_config resolve-hostnames yes
|
|
|
|
set_sentinel_config announce-hostnames yes
|
|
|
|
}
|
|
|
|
|
|
|
|
source "../tests/includes/init-tests.tcl"
|
|
|
|
|
|
|
|
proc verify_hostname_announced {hostname} {
|
|
|
|
foreach_sentinel_id id {
|
|
|
|
# Master is reported with its hostname
|
2021-01-30 04:18:58 -05:00
|
|
|
if {![string equal [lindex [S $id SENTINEL GET-MASTER-ADDR-BY-NAME mymaster] 0] $hostname]} {
|
|
|
|
return 0
|
|
|
|
}
|
Add hostname support in Sentinel. (#8282)
This is both a bugfix and an enhancement.
Internally, Sentinel relies entirely on IP addresses to identify
instances. When configured with a new master, it also requires users to
specify and IP and not hostname.
However, replicas may use the replica-announce-ip configuration to
announce a hostname. When that happens, Sentinel fails to match the
announced hostname with the expected IP and considers that a different
instance, triggering reconfiguration, etc.
Another use case is where TLS is used and clients are expected to match
the hostname to connect to with the certificate's SAN attribute. To
properly implement this configuration, it is necessary for Sentinel to
redirect clients to a hostname rather than an IP address.
The new 'resolve-hostnames' configuration parameter determines if
Sentinel is willing to accept hostnames. It is set by default to no,
which maintains backwards compatibility and avoids unexpected DNS
resolution delays on systems with DNS configuration issues.
Internally, Sentinel continues to identify instances by their resolved
IP address and will also report the IP by default. The new
'announce-hostnames' parameter determines if Sentinel should prefer to
announce a hostname, when available, rather than an IP address. This
applies to addresses returned to clients, as well as their
representation in the configuration file, REPLICAOF configuration
commands, etc.
This commit also introduces SENTINEL CONFIG GET and SENTINEL CONFIG SET
which can be used to introspect or configure global Sentinel
configuration that was previously was only possible by directly
accessing the configuration file and possibly restarting the instance.
Co-authored-by: myl1024 <myl92916@qq.com>
Co-authored-by: sundb <sundbcn@gmail.com>
2021-01-28 12:09:11 +02:00
|
|
|
|
|
|
|
# Replicas are reported with their hostnames
|
|
|
|
foreach replica [S $id SENTINEL REPLICAS mymaster] {
|
2021-01-30 04:18:58 -05:00
|
|
|
if {![string equal [dict get $replica ip] $hostname]} {
|
|
|
|
return 0
|
|
|
|
}
|
Add hostname support in Sentinel. (#8282)
This is both a bugfix and an enhancement.
Internally, Sentinel relies entirely on IP addresses to identify
instances. When configured with a new master, it also requires users to
specify and IP and not hostname.
However, replicas may use the replica-announce-ip configuration to
announce a hostname. When that happens, Sentinel fails to match the
announced hostname with the expected IP and considers that a different
instance, triggering reconfiguration, etc.
Another use case is where TLS is used and clients are expected to match
the hostname to connect to with the certificate's SAN attribute. To
properly implement this configuration, it is necessary for Sentinel to
redirect clients to a hostname rather than an IP address.
The new 'resolve-hostnames' configuration parameter determines if
Sentinel is willing to accept hostnames. It is set by default to no,
which maintains backwards compatibility and avoids unexpected DNS
resolution delays on systems with DNS configuration issues.
Internally, Sentinel continues to identify instances by their resolved
IP address and will also report the IP by default. The new
'announce-hostnames' parameter determines if Sentinel should prefer to
announce a hostname, when available, rather than an IP address. This
applies to addresses returned to clients, as well as their
representation in the configuration file, REPLICAOF configuration
commands, etc.
This commit also introduces SENTINEL CONFIG GET and SENTINEL CONFIG SET
which can be used to introspect or configure global Sentinel
configuration that was previously was only possible by directly
accessing the configuration file and possibly restarting the instance.
Co-authored-by: myl1024 <myl92916@qq.com>
Co-authored-by: sundb <sundbcn@gmail.com>
2021-01-28 12:09:11 +02:00
|
|
|
}
|
|
|
|
}
|
2021-01-30 04:18:58 -05:00
|
|
|
return 1
|
Add hostname support in Sentinel. (#8282)
This is both a bugfix and an enhancement.
Internally, Sentinel relies entirely on IP addresses to identify
instances. When configured with a new master, it also requires users to
specify and IP and not hostname.
However, replicas may use the replica-announce-ip configuration to
announce a hostname. When that happens, Sentinel fails to match the
announced hostname with the expected IP and considers that a different
instance, triggering reconfiguration, etc.
Another use case is where TLS is used and clients are expected to match
the hostname to connect to with the certificate's SAN attribute. To
properly implement this configuration, it is necessary for Sentinel to
redirect clients to a hostname rather than an IP address.
The new 'resolve-hostnames' configuration parameter determines if
Sentinel is willing to accept hostnames. It is set by default to no,
which maintains backwards compatibility and avoids unexpected DNS
resolution delays on systems with DNS configuration issues.
Internally, Sentinel continues to identify instances by their resolved
IP address and will also report the IP by default. The new
'announce-hostnames' parameter determines if Sentinel should prefer to
announce a hostname, when available, rather than an IP address. This
applies to addresses returned to clients, as well as their
representation in the configuration file, REPLICAOF configuration
commands, etc.
This commit also introduces SENTINEL CONFIG GET and SENTINEL CONFIG SET
which can be used to introspect or configure global Sentinel
configuration that was previously was only possible by directly
accessing the configuration file and possibly restarting the instance.
Co-authored-by: myl1024 <myl92916@qq.com>
Co-authored-by: sundb <sundbcn@gmail.com>
2021-01-28 12:09:11 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
test "Sentinel announces hostnames" {
|
|
|
|
# Check initial state
|
|
|
|
verify_hostname_announced $::host
|
|
|
|
|
|
|
|
# Disable announce-hostnames and confirm IPs are used
|
|
|
|
set_sentinel_config announce-hostnames no
|
2021-01-30 04:18:58 -05:00
|
|
|
assert {[verify_hostname_announced "127.0.0.1"] || [verify_hostname_announced "::1"]}
|
Add hostname support in Sentinel. (#8282)
This is both a bugfix and an enhancement.
Internally, Sentinel relies entirely on IP addresses to identify
instances. When configured with a new master, it also requires users to
specify and IP and not hostname.
However, replicas may use the replica-announce-ip configuration to
announce a hostname. When that happens, Sentinel fails to match the
announced hostname with the expected IP and considers that a different
instance, triggering reconfiguration, etc.
Another use case is where TLS is used and clients are expected to match
the hostname to connect to with the certificate's SAN attribute. To
properly implement this configuration, it is necessary for Sentinel to
redirect clients to a hostname rather than an IP address.
The new 'resolve-hostnames' configuration parameter determines if
Sentinel is willing to accept hostnames. It is set by default to no,
which maintains backwards compatibility and avoids unexpected DNS
resolution delays on systems with DNS configuration issues.
Internally, Sentinel continues to identify instances by their resolved
IP address and will also report the IP by default. The new
'announce-hostnames' parameter determines if Sentinel should prefer to
announce a hostname, when available, rather than an IP address. This
applies to addresses returned to clients, as well as their
representation in the configuration file, REPLICAOF configuration
commands, etc.
This commit also introduces SENTINEL CONFIG GET and SENTINEL CONFIG SET
which can be used to introspect or configure global Sentinel
configuration that was previously was only possible by directly
accessing the configuration file and possibly restarting the instance.
Co-authored-by: myl1024 <myl92916@qq.com>
Co-authored-by: sundb <sundbcn@gmail.com>
2021-01-28 12:09:11 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
# We need to revert any special configuration because all tests currently
|
|
|
|
# share the same instances.
|
|
|
|
test "(post-cleanup) Configure instances and sentinel for IPs" {
|
|
|
|
set ::host "127.0.0.1"
|
|
|
|
set_all_instances_hostname $::host
|
|
|
|
set_redis_announce_ip $::host
|
|
|
|
set_sentinel_config resolve-hostnames no
|
|
|
|
set_sentinel_config announce-hostnames no
|
|
|
|
}
|