많은 여유 RAM, NVMe Intel P4500 및 모든 것이 매우 느립니다. 스왑 파티션 추가 실패에 대한 이야기

이 기사에서는 최근 VPS 클라우드의 서버 중 하나에서 발생한 상황에 대해 이야기하겠습니다. 이로 인해 몇 시간 동안 당황하게 되었습니다. 나는 약 15년 ​​동안 Linux 서버를 구성하고 문제를 해결해 왔지만 이 사례는 내 실무에 전혀 맞지 않습니다. 문제의 원인을 정확하게 파악하고 해결할 수 있기 전에 몇 가지 잘못된 가정을 하고 약간의 절망에 빠졌습니다. .

서문

우리는 32개 코어, 256GB RAM 및 4500TB PCI-E Intel P4 NVMe 드라이브 구성을 갖춘 표준 서버에 구축된 중간 규모의 클라우드를 운영하고 있습니다. VM 인스턴스 유형 수준에서 올바른 제한을 제공함으로써 IO 오버헤드에 대해 걱정할 필요가 없기 때문에 이 구성이 정말 마음에 듭니다. NVMe 인텔이기 때문에 P4500 뛰어난 성능을 제공하므로 IOWAIT 없이 시스템에 대한 전체 IOPS 프로비저닝과 백업 서버에 대한 백업 스토리지를 동시에 제공할 수 있습니다.

우리는 VM 볼륨을 저장하기 위해 하이퍼컨버지드 SDN 및 기타 세련되고 패셔너블한 젊은 제품을 사용하지 않는 오래된 신봉자 중 하나입니다. 시스템이 단순할수록 "주요 전문가가 사라졌습니다"라는 조건에서 문제를 해결하는 것이 더 쉽다고 믿습니다. 산으로.” 결과적으로 우리는 LVM2 위에 배포되는 XFS 또는 EXT4에 QCOW2 형식으로 VM 볼륨을 저장합니다.

또한 오케스트레이션에 사용하는 제품인 Apache CloudStack에 의해 QCOW2를 사용해야 합니다.

백업을 수행하기 위해 볼륨의 전체 이미지를 LVM2 스냅샷으로 만듭니다(예, LVM2 스냅샷이 느리다는 것을 알고 있지만 여기서도 Intel P4500이 도움이 됩니다). 우리는하다 lvmcreate -s .. 그리고 도움으로 dd ZFS 저장소가 있는 원격 서버로 백업 복사본을 보냅니다. 여기서는 여전히 약간 진보적입니다. 결국 ZFS는 데이터를 압축 형식으로 저장할 수 있으며 다음을 사용하여 신속하게 복원할 수 있습니다. DD 또는 다음을 사용하여 개별 VM 볼륨을 얻습니다. mount -o loop ....

물론 LVM2 볼륨의 전체 이미지를 제거하는 것이 아니라 파일 시스템을 다음 위치에 마운트할 수 있습니다. RO QCOW2 이미지 자체를 복사했지만 이로 인해 XFS가 즉각적이지는 않지만 예측할 수 없는 방식으로 나빠졌다는 사실에 직면했습니다. 하이퍼바이저 호스트가 주말, 밤 또는 공휴일에 언제 발생하는지 명확하지 않은 오류로 인해 갑자기 "고착"되는 것을 정말 좋아하지 않습니다. 따라서 XFS의 경우 스냅샷 마운트를 사용하지 않습니다. RO 볼륨을 추출하려면 전체 LVM2 볼륨을 복사하면 됩니다.

우리의 경우 백업 서버로의 백업 속도는 백업 서버의 성능에 따라 결정되며, 압축할 수 없는 데이터의 경우 약 600-800MB/s입니다. 추가 제한은 백업 서버가 연결되는 10Gbit/s 채널입니다. 클러스터에.

이 경우 8개의 하이퍼바이저 서버의 백업 복사본이 하나의 백업 서버에 동시에 업로드됩니다. 따라서 백업 서버의 디스크 및 네트워크 하위 시스템은 속도가 느려 하이퍼바이저 호스트의 디스크 하위 시스템이 과부하되는 것을 허용하지 않습니다. 이는 하이퍼바이저 호스트가 쉽게 처리할 수 있는 8GB/초를 처리할 수 없기 때문입니다. 생산하다.

위의 복사 프로세스는 빠른 Intel P4500 드라이브 사용, NFS 사용 및 아마도 ZFS 사용 등 세부 사항을 포함하여 추가 이야기에 매우 중요합니다.

백업 스토리

각 하이퍼바이저 노드에는 8GB 크기의 작은 SWAP 파티션이 있으며 다음을 사용하여 하이퍼바이저 노드 자체를 "롤아웃"합니다. DD 참조 이미지에서. 서버의 시스템 볼륨의 경우 LSI 또는 HP 하드웨어 컨트롤러에서 2xSATA SSD RAID1 또는 2xSAS HDD RAID1을 사용합니다. 일반적으로 시스템 볼륨은 SWAP를 제외하고 "거의 읽기 전용" 모드로 작동하므로 내부 내용에는 전혀 신경 쓰지 않습니다. 그리고 서버에 많은 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를 사용하는 레거시 노드가 많이 있으므로 이는 관련이 있으므로 이동 중입니다. 그대로. 전반적으로 이것은 무익함을 설명하는 흥미로운 코드 조각입니다. ionice 그러한 구성의 경우.

깃발에 주의하세요 iflag=direct 에 DD. 우리는 읽을 때 불필요한 IO 버퍼 교체를 피하기 위해 버퍼 캐시를 우회하는 직접 IO를 사용합니다. 하지만, oflag=direct ZFS를 사용할 때 성능 문제가 발생했기 때문에 그렇지 않습니다.

우리는 이 계획을 몇 년 동안 문제 없이 성공적으로 사용해 왔습니다.

그리고 시작됐어... 우리는 노드 중 하나가 더 이상 백업되지 않고 이전 노드가 50%라는 엄청난 IOWAIT로 실행되고 있음을 발견했습니다. 복사가 발생하지 않는 이유를 이해하려고 할 때 다음 현상이 발생했습니다.

Volume group "images" not found

우리는 "Intel P4500의 종말이 왔다"고 생각하기 시작했지만 드라이브 교체를 위해 서버를 끄기 전에 여전히 백업을 수행해야 했습니다. LVM2 백업에서 메타데이터를 복원하여 LVM2를 수정했습니다.

vgcfgrestore images

우리는 백업을 시작했고 다음 유화를 보았습니다.

다시 한 번 우리는 매우 슬펐습니다. 모든 VPS가 고통을 겪을 것이기 때문에 이렇게 살 수 없다는 것이 분명했습니다. 이는 우리도 고통을 겪을 것임을 의미합니다. 무슨 일이 일어났는지는 완전히 불분명합니다. iostat 불쌍한 IOPS와 가장 높은 IOWAIT를 보였습니다. “NVMe를 교체하자”는 것 외에는 아이디어가 없었지만, 때마침 통찰력이 떠올랐습니다.

단계별로 상황 분석

역사잡지. 며칠 전 이 서버에서는 128GB RAM을 갖춘 대규모 VPS를 생성해야 했습니다. 메모리가 충분한 것 같았지만 안전을 위해 스왑 파티션에 32GB를 추가로 할당했습니다. 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 없이 이전처럼 작동하기 시작했습니다.

출처 : habr.com