My rule number 1 is to put all DNS entries in /etc/hosts or use dnsmasq for local DNS caching.<div>Rule number 2 , add cluster nodes as ntp/chrony peers (with 'prefer' for the ntp servers) to avoid node drift if time source is down for a long time.</div><div><br></div><div>Should the cluster take care of unstable infra -> not without you explicitly asking for that (and being capable of).</div><div><br></div><div>Best Regards,</div><div>Strahil Nikolov <br> <br> <blockquote style="margin: 0 0 20px 0;"> <div style="font-family:Roboto, sans-serif; color:#6D00F6;"> <div>On Thu, Aug 4, 2022 at 9:38, Ulrich Windl</div><div><Ulrich.Windl@rz.uni-regensburg.de> wrote:</div> </div> <div style="padding: 10px 0 0 20px; margin: 10px 0 0 0; border-left: 1px solid #6D00F6;"> Hi!<br clear="none"><br clear="none">FYI, here is a copy what I had sent to SUSE support (stating "Because of the<br clear="none">very same DNS resolution problem, stopping also failed"; should a temporary DNS<br clear="none">resolving problem cause a resource stop to fail and cause node fencing in turn?<br clear="none">I don't think so!):<br clear="none">---<br clear="none">The problem is the Perl code that most likely was never tested to handle a<br clear="none">failure of or in ld_gethostservbyname():<br clear="none">FIRST it should be checked whether a value was returned at all; if not there<br clear="none">is a failure in resolution.<br clear="none">In turn a failure in resolution could mean two tings:<br clear="none">1) The names in the configuration are not correct and will never resolve.<br clear="none">2) A temporary failure of some kind caused a failure and the configuration IS<br clear="none">CORRECT.<br clear="none"><br clear="none">Clearly the bad case here was 2).<br clear="none"><br clear="none">Also looking at the code I wonder why it does not handle things like this:<br clear="none">                $ip_port=&ld_gethostservbyname($ip_port, $vsrv->{protocol},<br clear="none">$af);<br clear="none">                if ($ip_port) {<br clear="none">                    if ($ip_port =~ /^(.+):([^:]+)$/) { # replacing the split<br clear="none">                        ($vsrv->{server}, $vsrv->{port}) = ($1, $2);<br clear="none">                        # this should also handle the case "$ip_port =~<br clear="none">/(\[[0-9A-Fa-f:]+\]):(\d+)/"<br clear="none">                    } else {<br clear="none">                        # error "unexpected return from ld_gethostservbyname"<br clear="none">                    }<br clear="none">                } else {<br clear="none">                    # error "failed to resolve ..."<br clear="none">                    # here it's unfortunate that the original $ip_port is<br clear="none">lost,<br clear="none">                    # so it cannot be part of the error message<br clear="none">                }<br clear="none"><br clear="none">Despite of that is that the critical part was that the "stop" operation SEEMED<br clear="none">to have failed, causing fencing.<br clear="none">Regardless of the success of resolving the names ldirector should be able to<br clear="none">stop!<br clear="none">---<br clear="none">Opinions?<br clear="none"><br clear="none">Regards,<br clear="none">Ulrich<br clear="none"><br clear="none">>>> "Ulrich Windl" <<a shape="rect" ymailto="mailto:Ulrich.Windl@rz.uni-regensburg.de" href="mailto:Ulrich.Windl@rz.uni-regensburg.de">Ulrich.Windl@rz.uni-regensburg.de</a>> schrieb am 03.08.2022<br clear="none">um<br clear="none">11:13 in Nachricht <<a shape="rect" ymailto="mailto:62EA3C2C020000A10004C114@gwsmtp.uni-regensburg.de" href="mailto:62EA3C2C020000A10004C114@gwsmtp.uni-regensburg.de">62EA3C2C020000A10004C114@gwsmtp.uni-regensburg.de</a>>:<br clear="none">> Hi!<br clear="none">> <br clear="none">> I wanted to inform you of an unpleasant bug in ldirectord of SLES12 SP5:<br clear="none">> We had a short network problem while some redundancy paths reconfigured in <br clear="none">> the infrastructure, effectively causing that some network services could not<br clear="none"><br clear="none">> be reached.<br clear="none">> Unfortunately ldirectord controlled by the cluster reported a failure (the <br clear="none">> director, not the services being directed to):<br clear="none">> <br clear="none">> h11 crmd[28930]:   notice: h11‑prm_lvs_mail_monitor_300000:369 [ Use of <br clear="none">> uninitialized value $ip_port in pattern match (m//) at /usr/sbin/ldirectord<br clear="none"><br clear="none">> line 1830, <CFGFILE> line 21. Error [33159] reading file <br clear="none">> /etc/ldirectord/mail.conf at line 10: invalid address for virtual service\n<br clear="none">]<br clear="none">> h11 ldirectord[33266]: Exiting with exit_status 2: config_error: <br clear="none">> Configuration Error<br clear="none">> <br clear="none">> You can guess wat happened:<br clear="none">> Pacemaker tried to recover (stop, then start), but the stop failed, too:<br clear="none">> h11 lrmd[28927]:   notice: prm_lvs_mail_stop_0:35047:stderr [ Use of <br clear="none">> uninitialized value $ip_port in pattern match (m//) at /usr/sbin/ldirectord<br clear="none"><br clear="none">> line 1830, <CFGFILE> line 21. ]<br clear="none">> h11 lrmd[28927]:   notice: prm_lvs_mail_stop_0:35047:stderr [ Error [36293]<br clear="none"><br clear="none">> reading file /etc/ldirectord/mail.conf at line 10: invalid address for <br clear="none">> virtual service ]<br clear="none">> h11 crmd[28930]:   notice: Result of stop operation for prm_lvs_mail on h11:<br clear="none"><br clear="none">> 1 (unknown error)<br clear="none">> <br clear="none">> A stop failure meant that the node was fenced, interrupting all the other <br clear="none">> services.<br clear="none">> <br clear="none">> Examining the logs I also found this interesting type of error:<br clear="none">> h11 attrd[28928]:   notice: Cannot update <br clear="none">> fail‑count‑prm_lvs_rksapds5#monitor_300000[monitor]=(null) because peer <br clear="none">> UUID not known (will retry if learned)<br clear="none">> <br clear="none">> Eventually, here's the code that caused the error:<br clear="none">> <br clear="none">> sub _ld_read_config_virtual_resolve<br clear="none">> {<br clear="none">>         my($line, $vsrv, $ip_port, $af)=(@_);<br clear="none">> <br clear="none">>         if($ip_port){<br clear="none">>                 $ip_port=&ld_gethostservbyname($ip_port, $vsrv‑>{protocol},<br clear="none"><br clear="none">> $af);<br clear="none">>                 if ($ip_port =~ /(\[[0‑9A‑Fa‑f:]+\]):(\d+)/) {<br clear="none">>                         $vsrv‑>{server} = $1;<br clear="none">>                         $vsrv‑>{port} = $2;<br clear="none">>                 } elsif($ip_port){<br clear="none">>                         ($vsrv‑>{server}, $vsrv‑>{port}) = split /:/,<br clear="none">$ip_port;<br clear="none">>                 }<br clear="none">>                 else {<br clear="none">>                         &config_error($line,<br clear="none">>                                 "invalid address for virtual service");<br clear="none">>                 }<br clear="none">> ...<br clear="none">> <br clear="none">> The value returned by ld_gethostservbyname is undefined. I also wonder what<br clear="none"><br clear="none">> the program logic is:<br clear="none">> If the host looks like an hex address in square brackets, host and port are<br clear="none"><br clear="none">> split at the colon; otherwise host and port are split at the colon.<br clear="none">> Why not split simply at the last colon if the value is defined, AND THEN <br clear="none">> check if the components look OK?<br clear="none">> <br clear="none">> So the "invalid address for virtual service" is only invalid when the <br clear="none">> resolver service (e.g. via LDAP) is unavailable.<br clear="none">> I used host and service names for readability.<br clear="none">> <br clear="none">> (I reported the issue to SLES support)<br clear="none">> <br clear="none">> Regards,<br clear="none">> Ulrich<br clear="none">> <br clear="none">> <br clear="none">> <br clear="none">> _______________________________________________<br clear="none">> Manage your subscription:<br clear="none">> <a shape="rect" href="https://lists.clusterlabs.org/mailman/listinfo/users " target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users </a><br clear="none">> <br clear="none">> ClusterLabs home: <a shape="rect" href="https://www.clusterlabs.org/ " target="_blank">https://www.clusterlabs.org/ </a><div class="yqt0777512697" id="yqtfd80361"><br clear="none"><br clear="none"><br clear="none"><br clear="none">_______________________________________________<br clear="none">Manage your subscription:<br clear="none"><a shape="rect" href="https://lists.clusterlabs.org/mailman/listinfo/users" target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users</a><br clear="none"><br clear="none">ClusterLabs home: <a shape="rect" href="https://www.clusterlabs.org/" target="_blank">https://www.clusterlabs.org/</a><br clear="none"></div> </div> </blockquote></div>