在這篇文章中，我將討論我們的 VPS 雲端中的一台伺服器最近發生的一個情況，這讓我困惑了幾個小時。 我從事Linux 伺服器配置和故障排除工作已經有大約15 年了，但這個案例根本不適合我的實踐- 在我能夠正確確定問題原因並解決它之前，我做了幾個錯誤的假設並且變得有點絕望。
前言
我們經營一個中型雲，該雲基於具有以下配置的標準伺服器構建：32 個核心、256 GB RAM 和 4500TB PCI-E Intel P4 NVMe 驅動器。 我們非常喜歡這種配置，因為它透過在 VM 實例類型層級提供正確的限制，消除了對 IO 開銷的擔憂。 因為 NVMe 英特爾 具有令人印象深刻的效能，我們可以同時為機器提供完整的 IOPS 配置，並為備份伺服器提供零 IOWAIT 的備份儲存。
我們是那些不使用超融合SDN和其他時尚、時尚、年輕的東西來存儲VM卷的老信徒之一，認為系統越簡單，在“主要大師已經走了”的情況下就越容易排除故障到山里去。” 因此，我們將 VM 磁碟區以 QCOW2 格式儲存在 XFS 或 EXT4 中，部署在 LVM2 之上。
我們用於編排的產品 Apache CloudStack 也迫使我們使用 QCOW2。
為了執行備份，我們將磁碟區的完整映像作為 LVM2 快照（是的，我們知道 LVM2 快照很慢，但 Intel P4500 也可以幫助我們）。 我們的確是 lvmcreate -s .. 並在幫助下 dd 我們將備份副本傳送到具有 ZFS 儲存的遠端伺服器。 這裡我們還是稍微進步一下——畢竟ZFS可以以壓縮的形式儲存數據，我們可以使用以下命令快速恢復它 DD 或使用以下命令取得單獨的虛擬機器卷 mount -o loop ....
當然，您可以不刪除 LVM2 磁碟區的完整映像，而是將檔案系統掛載到
RO並複製 QCOW2 映像本身，但是，我們面臨這樣一個事實：XFS 會因此而變壞，而且不是立即變壞，而是以一種不可預測的方式變壞。 我們真的不喜歡虛擬機器管理程式在週末、晚上或假日由於不清楚何時發生的錯誤而突然「卡住」。 因此，對於XFS我們不使用快照掛載RO要提取卷，我們只需複製整個 LVM2 卷即可。
在我們的例子中，備份到備份伺服器的速度由備份伺服器的效能決定，對於不可壓縮數據，備份伺服器的效能約為 600-800 MB/s；另一個限制因素是備份伺服器連接的 10Gbit/s 通道到集群。
在這種情況下，8 個虛擬機器管理程式伺服器的備份副本同時上傳到一台備份伺服器。 因此，備份伺服器的磁碟和網路子系統速度較慢，不允許管理程式主機的磁碟子系統過載，因為它們根本無法處理例如 8 GB/秒，而管理程式主機可以輕鬆處理該速度。生產。
上述複製過程對於進一步的故事非常重要，包括細節 - 使用快速 Intel P4500 驅動器、使用 NFS 以及可能使用 ZFS。
備份故事
在每個虛擬機器管理程式節點上，我們都有一個大小為 8 GB 的小型 SWAP 分區，並且我們使用以下命令「推出」虛擬機器管理程式節點本身 DD 從參考影像。 對於伺服器上的系統卷，我們在 LSI 或 HP 硬體控制器上使用 2xSATA SSD RAID1 或 2xSAS HDD RAID1。 一般來說，我們根本不關心裡面有什麼，因為我們的系統磁碟區以「幾乎只讀」模式運行，除了交換之外。 由於我們的伺服器上有大量 RAM，並且有 30-40% 空閒，因此我們不會考慮 SWAP。
備份過程。 這個任務看起來像這樣：
#!/bin/bash
mkdir -p /mnt/backups/volumes
DIR=/mnt/images-snap
VOL=images/volume
DATE=$(date "+%d")
HOSTNAME=$(hostname)
lvcreate -s -n $VOL-snap -l100%FREE $VOL
ionice -c3 dd iflag=direct if=/dev/$VOL-snap bs=1M of=/mnt/backups/volumes/$HOSTNAME-$DATE.raw
lvremove -f $VOL-snap注意 ionice -c3，其實這個東西對於NVMe設備來說完全沒用，因為它們的IO調度器設定為：
cat /sys/block/nvme0n1/queue/scheduler
[none] 然而，我們有許多具有傳統 SSD RAID 的遺留節點，這對他們來說是相關的，因此他們正在遷移 AS IS。 總的來說，這只是一段有趣的程式碼，它解釋了無效性 ionice 在這種配置的情況下。
注意旗幟 iflag=direct 為 DD。 我們使用繞過緩衝區快取的直接 IO 來避免讀取時不必要的 IO 緩衝區替換。 然而， oflag=direct 我們不這麼做是因為我們在使用 ZFS 時遇到了效能問題。
我們已經成功使用這個方案好幾年了，沒有出現任何問題。
然後事情就開始了……我們發現其中一個節點不再備份，而前一個節點的 IOWAIT 高達 50%。 當試圖理解為什麼不發生複製時，我們遇到了以下現象：
Volume group "images" not found我們開始思考“Intel P4500的末日已經到來”，然而，在關閉伺服器更換驅動器之前，仍然需要進行備份。 我們透過從 LVM2 備份還原元資料來修復 LVM2：
vgcfgrestore images我們啟動了備份，看到了這幅油畫：
我們再次感到非常悲傷 - 顯然我們不能像這樣生活，因為所有 VPS 都會受到影響，這意味著我們也會受到影響。 發生了什麼事完全不清楚—— iostat 表現出可憐的IOPS和最高的IOWAIT。 除了「讓我們取代 NVMe」之外沒有其他想法，但一個洞察及時出現。
逐步分析狀況
歷史雜誌。 幾天前，需要在該伺服器上建立一個具有 128 GB RAM 的大型 VPS。 看起來記憶體夠了，但為了安全起見，我們又分配了 32 GB 給交換分割區。 VPS 已創建，成功完成其任務，事件被遺忘，但 SWAP 分區仍然存在。
配置功能。 對於所有雲端伺服器該參數 vm.swappiness 已設定為預設值 60。 SWAP是在SAS HDD RAID1上建立的。
發生了什麼事（根據編輯）。 備份時 DD 產生大量寫入數據，這些數據在寫入 NFS 之前被放置在 RAM 緩衝區中。 制度核心，政策引導 swappiness，正在將許多 VPS 記憶體頁面移至交換區域，該交換區域位於慢速 HDD RAID1 磁碟區上。 這導致 IOWAIT 成長非常強勁，但不是由於 IO NVMe，而是由於 IO HDD RAID1。
問題是如何解決的。 32GB 交換分割區已停用。 這花了 16 個小時；您可以單獨閱讀有關 SWAP 如何以及為何關閉如此緩慢的資訊。 設定已更改 swappiness 等於一個值 5 遍佈雲端。
這怎麼可能不會發生呢？。 首先，如果 SWAP 在 SSD RAID 或 NVMe 設備上，其次，如果沒有 NVMe 設備，但速度較慢的設備不會產生如此大的資料量 - 諷刺的是，問題的發生是因為 NVMe 太快了。
之後，一切開始像以前一樣工作 - IOWAIT 為零。
來源： www.habr.com