我目前正在尝试使本地隔离的 HTCondor 集群的作业队列和提交机制高度可用。该集群由 2 个主服务器（以前是 1 个）和几个计算节点以及一个中央存储系统组成。DNS、LDAP 和其他服务由主服务器提供。所有机器上的 Ubuntu 20.04.1 上的 HTCondor 版本均为 8.6.8。
我按照下面的说明进行操作https://htcondor.readthedocs.io/en/latest/admin-manual/high-availability.html。最终配置请参见下文。
spool 目录 (/clients/condor/spool) 位于每个服务器都可以访问的 NFS v3 共享 (/clients) 上。所有机器都有一个本地用户 (r-admin)，uid 和 gid 为 1000，spool 目录归该用户所有，因为它被配置为 Condor 用户。每个其他用户都通过 LDAP 映射到每个服务器（包括存储集群）。在两个主服务器上，用户“condor”具有相同的 uid 和 gid。
HADLog 定期更新，不会显示任何错误。每次只有一个主服务器具有主要角色。ReplicationLog 似乎也很好。
然而，存在几个问题：
假设 master1 目前是主服务器。使用没有任何参数的 condor_q 仅在这台机器上有效，并显示正确的作业队列。在 master2 上，使用 condor_q 会导致分段错误。如果将 SCHEDD_NAME 作为参数（“condor_q master@”），则会出现输出，但其中包含 master2 的 IP 且没有任何作业。而且作业不会启动，它们处于空闲状态。
有人知道配置可能出了什么问题吗？或者我可以在哪里找到有关此主题的更多见解？任何帮助都将不胜感激！
编辑
当尝试在 master2 上运行 condor_q 时，您可以在下面找到 master1 上的 SchedLog 条目：
10/08/20 11:50:30 (pid:47347) Number of Active Workers 0
10/08/20 11:50:41 (pid:47347) AUTHENTICATE: handshake failed!
10/08/20 11:50:41 (pid:47347) DC_AUTHENTICATE: authentication of <192.168.1.22:10977>
did not result in a valid mapped user name, which is
required for this command (519 QUERY_JOB_ADS_WITH_AUTH), so aborting.
10/08/20 11:50:41 (pid:47347) DC_AUTHENTICATE: reason for authentication failure:
AUTHENTICATE:1002:Failure performing handshake|AUTHENTICATE:1004:Failed to authenticate using KERBEROS|
AUTHENTICATE:1004:Failed to authenticate using FS|FS:1004:Unable to lstat(/tmp/FS_XXXGNYmKn)
主恶魔
DAEMON_LIST = MASTER, SCHEDD, COLLECTOR, NEGOTIATOR
节点守护进程
DAEMON_LIST = MASTER, STARTD
本地配置（/etc/condor/condor_config.local，所有服务器）
COLLECTOR_NAME = HPC
CENTRAL_MANAGER_HOST = master1.condor,master2.condor
UID_DOMAIN = condor
FILESYSTEM_DOMAIN = condor
ENABLE_HISTORY_ROTATION = TRUE
MAX_HISTORY_LOG = 2000000000
MAX_HISTORY_ROTATIONS = 100
EMAIL_DOMAIN = condor
ENABLE_IPV6 = FALSE
CONDOR_IDS = 1000.1000
QUEUE_SUPER_USERS = root, r-admin
CONDOR_ADMIN = root@condor
SOFT_UID_DOMAIN = TRUE
ALLOW_READ = *, $(CONDOR_HOST), $(IP_ADDRESS), $(CENTRAL_MANAGER_HOST)
ALLOW_WRITE = *, $(CONDOR_HOST), $(IP_ADDRESS), $(CENTRAL_MANAGER_HOST)
ALLOW_ADMINISTRATOR = *, $(CONDOR_HOST), $(IP_ADDRESS), $(CENTRAL_MANAGER_HOST)
HA 配置（/etc/condor/config.d/ha.conf，仅主服务器）
## HA Konfiguration
## Shared Job Queue
MASTER_HA_LIST = SCHEDD
SPOOL = /clients/condor/spool
HA_LOCK_URL = file:/clients/condor/spool
VALID_SPOOL_FILES = $(VALID_SPOOL_FILES) SCHEDD.lock
SCHEDD_NAME = master@
## Shared Negotiator and Collector
HAD_USE_SHARED_PORT = TRUE
HAD_LIST = master1.condor:$(SHARED_PORT_PORT),master2.condor:$(SHARED_PORT_PORT)
REPLICATION_USE_SHARED_PORT = TRUE
REPLICATION_LIST = master1.condor:$(SHARED_PORT_PORT),master2.condor:$(SHARED_PORT_PORT)
HAD_USE_PRIMARY = TRUE
HAD_CONTROLLEE = NEGOTIATOR
MASTER_NEGOTIATIOR_CONTROLLER = HAD
DAEMON_LIST = $(DAEMON_LIST), HAD, REPLICATION
HAD_USE_REPLICATION = TRUE
STATE_FILE = $(SPOOL)/Accountantnew.log
MASTER_HAD_BACKOFF_CONSTANT = 360
答案1
在邮件列表和一些实验的帮助下，我设法解决了这个问题。
由于现在有两个主服务器，它们不仅需要一个用于假脱机的共享文件系统（如 HA 指南中所述和上文所示），还需要一个用于身份验证的共享文件系统。至少将 FS_REMOTE 配置为身份验证机制是实现此目的的一种方法：
SEC_DEFAULT_AUTHENTICATION_METHODS = FS, FS_REMOTE
FS_REMOTE_DIR = /clients/condor/sec
守护进程正确验证后，作业开始运行，一切似乎都正常。condor_q 生成了正确的输出，故障转移按预期工作。但是，作业完成后并未从作业队列中删除，而是重新排队：
SchedLog: "SetEffectiveOwner security violation: setting owner to r-admin when active owner is "condor""
ShadowLog: "SetEffectiveOwner(r-admin) failed with errno=13: Permission denied."
错误消息指出了有关用户 condor 的一些信息，但实际上根本不应该涉及该信息，因为 CONDOR_IDS 已设置为 1000.1000 (r-admin)。实际上不存在任何文件、进程或其他任何由用户“condor”拥有或引用的内容。
事实证明，condor 以某种方式仍在内部引用这个用户名（见下文），这似乎是升级后的新用户名。在 QUEUE_SUPER_USERS 中添加“condor”后，问题得到解决，作业正常退出。
04/22/21 23:50:25 (fd:19) (pid:2200) (D_COMMAND) Calling HandleReq <handle_q> (0) for command 1112 (QMGMT_WRITE_CMD) from condor@child <XXX.XXX.XXX.XXX:22171>
04/22/21 23:50:25 (fd:19) (pid:2200) (D_SYSCALLS) Got request #10030
04/22/21 23:50:25 (fd:19) (pid:2200) (D_ALWAYS) SetEffectiveOwner security violation: setting owner to r-admin when active owner is "condor"