使用 Systemd 定時器可靠地執行 ownCloud 後台作業
將按需作業運行替換為 systemd 定時器,該定時器每 15 分鐘執行一次 ownCloud 支援的 occ system:cron 命令。
Data%當 SUSE Linux Enterprise Server 的精簡設定磁碟區報告「裝置上沒有剩餘空間」時,請先檢查精簡池Meta%。如果資料區已滿,而磁碟區組有可用區段,則應使用更大的容量擴展精簡池,而lvextend不僅僅是擴展其精簡邏輯磁碟區的虛擬大小。元資料區完全填滿的情況有所不同:可能需要離線修復才能恢復正常寫入。
以下步驟使用針對 Linux 系統編寫的 LVM2 指令,以及SUSE Linux Enterprise Server 15 SP7 儲存管理指南中所述的儲存模型。在其他 SLES 服務包或叢集安裝中,命令可用性和服務配置可能有所不同。在修改生產儲存之前,請務必進行應用程式一致性備份並限制大量寫入作業。
在擁有活動精簡池的主機上執行以下命令,並將 ` vgdata<volume-group name>` 替換為您的磁碟區組名稱:
sudo lvs -a -o lv_name,lv_size,segtype,data_percent,metadata_percent,pool_lv vgdata
thin-pool尋找包含下列值的行SegType:Data%`<value>` 表示已指派的資料區塊數;Meta%`<value>` 表示池的對應元資料。這些是不同的容量限制。如果 ` Data%<value>` 接近 100 但Meta%遠低於 100,則新增額外的資料區是最直接的解決方法。如果 ` Meta%<value>` 等於 100,請使用第 4 節中的復原措施。

舉個例子,假設vgdata/pool0一個 100 GiB 的儲存池,資料使用率為 98.12%,元資料使用率為 40.26%。即使掛載的精簡卷顯示空間充足,該儲存池也面臨立即被佔滿的風險。如同SUSE 的 Expert Partitioner 文件所述,df -h精簡磁碟區的虛擬大小可能超過儲存池的實體容量。
同時檢查最近的錯誤:
sudo journalctl -k --since "-30 min" | grep -Ei 'thin|no space|I/O error'
不要將空的 grep 結果解讀為沒有寫入失敗的證據。也要檢查應用程式的日誌,尤其是在儲存池滿時資料庫或虛擬機器正在寫入資料的情況下。
在更改資金池規模之前,請先了解交易量組是否能為擴容提供資金:
sudo vgs -o vg_name,vg_size,vg_free vgdata

在假設的範例中,200 GiB 的捲組有 40 GiB 的可用空間。因此,原則上可以擴展 20 GiB 的池,但需滿足分配限制並預留元資料增長的空間。建議保留一些卷組空間作為儲備,而不是將所有可用空間分配給池。
如果VG_FREE值為零,lvextend則無法建立物理容量。請將已正確識別並準備好的實體磁碟區新增至磁碟區組 (VG),根據需要擴展底層儲存及其 LVM PV,或在重試之前回收資料區塊。 SUSE 文件介紹了在調整磁碟區組大小時新增實體磁碟區的方法。切勿pvcreate對未經驗證的磁碟執行此操作:這可能會破壞現有的儲存元資料。
當Data%限制因素是元資料未耗盡且有足夠的 VG 擴充空間可用時,應擴展池本身:
sudo lvextend -L +20G vgdata/pool0

此+20G語法會將目前池大小增加 20 GiB,但不會將最終大小設為 20 GiB。在本例中,後端池從 100 GiB 成長到 120 GiB。在已分配資料未變更的情況下,已使用的 98.12 GiB 約佔擴充後池大小的 81.8%。如果在操作期間繼續寫入,實際百分比可能會有所不同。
請勿進行替換lvextend -L +20G vgdata/thin1。擴大精簡磁碟區的虛擬位址空間不一定會增加其池的實體資料容量。由於此命令擴展的是後端池而非檔案系統的虛擬區塊設備,因此通常不需要為此特定操作調整檔案系統大小。權威的LVM 精簡配置手冊詳細記錄了精簡池擴展機制及其限制。
如果檔案已從精簡檔案系統中刪除,且整個堆疊都支援丟棄操作,則考慮回收已丟棄的資料區塊:
sudo fstrim -v /srv/data
使用精簡磁碟區的實際掛載點,而不是精簡池設備。成功的 TRIM 操作可能會降低儲存池Data%容量,但單獨刪除檔案通常不會將資料區塊返回儲存池。精簡快照可以保留共用資料塊,而設定為忽略丟棄資料的儲存池不會從中受益。不要將 TRIM 操作視為物理容量的可靠緊急替代方案,尤其是在寫入作業開始失敗的情況下。僅在檢查舊快照的所有權、依賴關係和保留要求後才能刪除它們;快照刪除操作是不可逆的。
如果Meta%已達到 100%,請停止應用程式寫入並規劃受控停機。 LVM 警告稱,元資料耗盡會導致精簡池元資料和檔案系統不一致。僅僅增加池資料大小、重試寫入或強制啟動並不能解決此風險。
已記錄的復原順序是:離線停用受影響的儲存池,使用 `merge_metadata_callback` 修復其精簡元數據lvconvert --repair VG/ThinPool,使用 `merge_metadata_callback` 擴大元資料容量lvextend --poolmetadatasize,然後使用相應的離線工具檢查每個受影響的檔案系統。例如,元資料邏輯磁碟區小於 2 GiB 的儲存池可能需要進行下列審查:
sudo lvextend --poolmetadatasize 2G vgdata/pool0
請勿在已損壞的活動儲存池上盲目執行此命令。其大小僅為示例,並非普遍要求。請先確認目前元資料大小、可用擴充區、正確的停用設定、還原媒體和備份。lvconvert --repair必須具備停機時間和復原方面的專業知識才能進行規劃;LVM 手冊指出,即使執行此操作,資料仍可能無法復原。在驗證儲存池和檔案系統之前,請保留舊的元資料邏輯磁碟區 (LV)。從 LVM 配置備份vgcfgbackup不會備份精簡儲存池元資料。對於業務關鍵型數據,請在嘗試修復之前聯絡 SUSE 支援或您的儲存恢復團隊。
系統穩定後,在配置activation部分配置主動成長策略/etc/lvm/lvm.conf。此範例在磁碟使用率達到 70% 時開始擴展,並要求 20% 的成長;請根據寫入速率和可用 VG 容量調整這些值:
activation {
thin_pool_autoextend_threshold = 70
thin_pool_autoextend_percent = 20
}
確保將設定應用於正確的配置範圍,並對池進行監控:
sudo lvchange --monitor y vgdata/pool0

自動精簡池成長依賴 LVM 事件監控(dmeventd)和足夠的空閒擴展區。檢查 SLES 安裝提供的監控服務(例如,systemctl status lvm2-monitor該單元是否存在),並查看其日誌。如果寫入操作超過擴充限製或磁碟區組已滿,則閾值無法保證保護。請參閱LVM 手冊中的自動擴充指南和lvchange 監控選項。
讀取池利用率和VG剩餘容量:
sudo lvs -o lv_name,lv_size,data_percent,metadata_percent vgdata/pool0
sudo vgs -o vg_name,vg_free vgdata
Data%資料池擴展後,容量應該會下降,Meta%必須保持在耗盡狀態以下,且資料池應處於活動狀態,沒有新的 I/O 錯誤。檢查檔案系統狀態和應用程式日誌,然後在釋放已暫停的工作負載之前,執行一個小型的、適合應用程式的讀寫測試。如果空間可用後錯誤仍然存在,請將受影響的工作負載保持離線狀態,直到評估其檔案系統和應用程式的完整性;增加容量無法恢復已失敗或遺失的寫入操作。
將按需作業運行替換為 systemd 定時器,該定時器每 15 分鐘執行一次 ownCloud 支援的 occ system:cron 命令。
透過 Apache、Nginx 或反向代理程式追蹤 WebDAV 請求,然後使用經過驗證的 PROPFIND 測試確認 ownCloud 同步功能正常。
透過設定其規範 URL 並從伺服器本身檢查 DNS、HTTPS 和反向代理路由,修復 Nextcloud 缺少出站位址警告的問題。
透過本機 Unix 套接字配置 APCu 和 Redis,以實現 Nextcloud 快取和檔案鎖定,並提供目前和舊版 Nextcloud 的步驟。
檢查 Nextcloud 的 cron 模式,修復其 systemd 服務和計時器,並驗證後台作業在啟動後以及每隔五分鐘運行一次。
啟用可靠的 Nextcloud 檔案鎖定,選擇適當的 Redis 或 Valkey 後端,並驗證警告是否清除,同時避免並發檔案變更的風險。
使用最新更新、HTTPS 和 HSTS、精確的反向代理信任以及針對公共伺服器的檢查,修復 Nextcloud 掃描中常見的錯誤。
為需要加密的儲存配置 Nextcloud SSE,保護加密金鑰,並在加密現有文件之前測量傳輸和 CPU 影響。
將 Nextcloud 的檔案搜尋連接到 Elasticsearch,索引文件內容,並選擇適合您的伺服器和安全需求的設定。
配置 Nextcloud 在規定的保留期後刪除已刪除的文件,可靠地安排後台作業,並避免執行清除所有使用者回收站的命令。