HTCondor 高可用性
我目前正在嘗試使本地隔離 HTCondor 集群的作業隊列和送出機制具有高可用性。該集群由 2 台主伺服器（之前為 1 台）和幾個計算節點和一個中央儲存系統組成。DNS、LDAP 和其他服務由主伺服器提供。在所有機器上的 Ubuntu 20.04.1 上，HTCondor 版本是 8.6.8。
我按照https://htcondor.readthedocs.io/en/latest/admin-manual/high-availability.html下的說明進行操作。對於生成的配置，請參見下文。
假離線目錄 (/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
在郵件列表和一些實驗的幫助下，我設法解決了這個問題。
由於現在有兩台主伺服器，它們不僅需要一個共享文件系統來進行假離線（如 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”。
結果是，condor 在內部仍然以某種方式引用了這個使用者名（見下文），這似乎是升級後的新使用者名。將“condor”添加到QUEUE_SUPER_USERS 後，問題得到解決，作業正常退出。
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"