Trong bài viết này, tôi sẽ nói về một tình huống gần đây đã xảy ra với một trong các máy chủ trên đám mây VPS của chúng tôi, khiến tôi bối rối trong vài giờ. Tôi đã định cấu hình và khắc phục sự cố máy chủ Linux được khoảng 15 năm, nhưng trường hợp này hoàn toàn không phù hợp với thực tiễn của tôi - tôi đã đưa ra một số giả định sai lầm và hơi tuyệt vọng trước khi có thể xác định chính xác nguyên nhân của sự cố và giải quyết nó .
Lời nói đầu
Chúng tôi vận hành một đám mây cỡ trung bình mà chúng tôi xây dựng trên các máy chủ tiêu chuẩn có cấu hình sau - 32 lõi, RAM 256 GB và ổ đĩa Intel P4500 NVMe 4TB PCI-E. Chúng tôi thực sự thích cấu hình này vì nó giúp loại bỏ sự lo lắng về chi phí IO bằng cách cung cấp hạn chế chính xác ở cấp loại phiên bản VM. Bởi vì NVMe Intel có hiệu suất ấn tượng, chúng tôi có thể đồng thời cung cấp cả việc cung cấp IOPS đầy đủ cho máy và bộ lưu trữ dự phòng cho máy chủ dự phòng không có IOWAIT.
Chúng tôi là một trong những tín đồ cũ không sử dụng SDN siêu hội tụ và những thứ trẻ trung, thời trang, sành điệu khác để lưu trữ khối lượng VM, tin rằng hệ thống càng đơn giản thì càng dễ khắc phục sự cố trong điều kiện “bậc thầy chính đã ra đi”. đến những ngọn núi." Do đó, chúng tôi lưu trữ các ổ đĩa VM ở định dạng QCOW2 ở XFS hoặc EXT4, được triển khai trên LVM2.
Chúng tôi cũng buộc phải sử dụng QCOW2 bởi sản phẩm mà chúng tôi sử dụng để điều phối - Apache CloudStack.
Để thực hiện sao lưu, chúng tôi chụp ảnh toàn bộ ổ đĩa dưới dạng ảnh chụp nhanh LVM2 (vâng, chúng tôi biết rằng ảnh chụp nhanh LVM2 chậm, nhưng Intel P4500 cũng giúp chúng tôi giải quyết vấn đề này). chúng tôi làm lvmcreate -s .. và với sự giúp đỡ dd chúng tôi gửi bản sao lưu đến máy chủ từ xa có bộ lưu trữ ZFS. Ở đây chúng tôi vẫn đang tiến bộ một chút - xét cho cùng, ZFS có thể lưu trữ dữ liệu ở dạng nén và chúng tôi có thể nhanh chóng khôi phục dữ liệu đó bằng cách sử dụng DD hoặc nhận các khối VM riêng lẻ bằng cách sử dụng mount -o loop ....
Tất nhiên, bạn không thể xóa hình ảnh đầy đủ của ổ LVM2 mà gắn hệ thống tệp vào
ROvà tự sao chép các hình ảnh QCOW2, tuy nhiên, chúng tôi phải đối mặt với thực tế là XFS trở nên tồi tệ vì điều này, không phải ngay lập tức mà theo một cách không thể đoán trước. Chúng tôi thực sự không thích khi các máy chủ hypervisor “dính” đột ngột vào cuối tuần, ban đêm hoặc ngày nghỉ do những lỗi không rõ khi nào chúng sẽ xảy ra. Do đó, đối với XFS, chúng tôi không sử dụng tính năng gắn ảnh chụp nhanh trongROđể trích xuất các tập, chúng tôi chỉ cần sao chép toàn bộ tập LVM2.
Tốc độ sao lưu vào máy chủ dự phòng được xác định trong trường hợp của chúng tôi bởi hiệu suất của máy chủ dự phòng, khoảng 600-800 MB/s đối với dữ liệu không thể nén; một giới hạn hơn nữa là kênh 10Gbit/s mà máy chủ dự phòng được kết nối đến cụm.
Trong trường hợp này, bản sao lưu của 8 máy chủ ảo hóa được tải đồng thời lên một máy chủ dự phòng. Do đó, các hệ thống con đĩa và mạng của máy chủ dự phòng, chậm hơn, không cho phép các hệ thống con đĩa của máy chủ ảo hóa quá tải, vì đơn giản là chúng không thể xử lý 8 GB/giây mà máy chủ ảo hóa có thể dễ dàng xử lý. sản xuất.
Quá trình sao chép ở trên rất quan trọng đối với câu chuyện tiếp theo, bao gồm các chi tiết - sử dụng ổ Intel P4500 nhanh, sử dụng NFS và có thể sử dụng ZFS.
Câu chuyện sao lưu
Trên mỗi nút bộ ảo hóa, chúng tôi có một phân vùng SWAP nhỏ có kích thước 8 GB và chúng tôi “triển khai” chính nút bộ ảo hóa bằng cách sử dụng DD từ hình ảnh tham chiếu. Đối với âm lượng hệ thống trên máy chủ, chúng tôi sử dụng 2xSATA SSD RAID1 hoặc 2xSAS HDD RAID1 trên bộ điều khiển phần cứng LSI hoặc HP. Nói chung, chúng tôi không quan tâm đến những gì bên trong vì ổ đĩa hệ thống của chúng tôi hoạt động ở chế độ “gần như chỉ đọc”, ngoại trừ SWAP. Và vì chúng tôi có rất nhiều RAM trên máy chủ và nó trống 30-40% nên chúng tôi không nghĩ đến SWAP.
Quá trình sao lưu. Nhiệm vụ này trông giống như thế này:
#!/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-snapChú ý đến ionice -c3, trên thực tế, thứ này hoàn toàn vô dụng đối với các thiết bị NVMe, vì bộ lập lịch IO cho chúng được đặt là:
cat /sys/block/nvme0n1/queue/scheduler
[none] Tuy nhiên, chúng tôi có một số nút kế thừa có RAID SSD thông thường, đối với chúng điều này phù hợp nên chúng đang di chuyển AS IS. Nhìn chung, đây chỉ là một đoạn mã thú vị giải thích sự vô ích ionice trong trường hợp cấu hình như vậy.
Hãy chú ý đến lá cờ iflag=direct cho DD. Chúng tôi sử dụng IO trực tiếp bỏ qua bộ đệm đệm để tránh việc thay thế bộ đệm IO không cần thiết khi đọc. Tuy nhiên, oflag=direct chúng tôi không làm như vậy vì chúng tôi đã gặp phải các vấn đề về hiệu suất ZFS khi sử dụng nó.
Chúng tôi đã sử dụng thành công chương trình này trong nhiều năm mà không gặp vấn đề gì.
Và sau đó nó bắt đầu... Chúng tôi phát hiện ra rằng một trong các nút không còn được sao lưu nữa và nút trước đó đang chạy với IOWAIT khủng khiếp là 50%. Khi cố gắng tìm hiểu tại sao việc sao chép không xảy ra, chúng tôi gặp phải hiện tượng sau:
Volume group "images" not foundChúng tôi bắt đầu nghĩ đến việc “Intel P4500 đã đến hồi kết”, tuy nhiên, trước khi tắt máy chủ để thay ổ đĩa, vẫn cần phải thực hiện sao lưu. Chúng tôi đã sửa LVM2 bằng cách khôi phục siêu dữ liệu từ bản sao lưu LVM2:
vgcfgrestore imagesChúng tôi đã khởi chạy một bản sao lưu và thấy bức tranh sơn dầu này:
Một lần nữa chúng tôi rất buồn - rõ ràng là chúng tôi không thể sống như thế này, vì tất cả các VPS sẽ bị ảnh hưởng, đồng nghĩa với việc chúng tôi cũng sẽ bị ảnh hưởng. Chuyện gì đã xảy ra hoàn toàn không rõ ràng - iostat cho thấy IOPS đáng thương và IOWAIT cao nhất. Không có ý tưởng nào khác ngoài “hãy thay thế NVMe”, nhưng một ý tưởng sâu sắc đã xuất hiện đúng lúc.
Phân tích tình hình từng bước
tạp chí lịch sử. Trước đó vài ngày, trên máy chủ này cần tạo một VPS lớn với RAM 128 GB. Dường như có đủ bộ nhớ, nhưng để đảm bảo an toàn, chúng tôi đã phân bổ thêm 32 GB nữa cho phân vùng trao đổi. VPS đã được tạo, hoàn thành xuất sắc nhiệm vụ và sự cố bị lãng quên nhưng phân vùng SWAP vẫn còn.
Tính năng cấu hình. Đối với tất cả các máy chủ đám mây, tham số vm.swappiness đã được đặt thành mặc định 60. Và SWAP đã được tạo trên SAS HDD RAID1.
Chuyện gì đã xảy ra (theo các biên tập viên). Khi sao lưu DD tạo ra rất nhiều dữ liệu ghi, được đặt trong bộ đệm RAM trước khi ghi vào NFS. Cốt lõi hệ thống, được hướng dẫn bởi chính sách swappiness, đang di chuyển nhiều trang của bộ nhớ VPS sang vùng trao đổi, nằm trên ổ HDD RAID1 chậm. Điều này dẫn đến IOWAIT phát triển rất mạnh mẽ, nhưng không phải do IO NVMe mà là do IO HDD RAID1.
Vấn đề đã được giải quyết như thế nào. Phân vùng trao đổi 32GB đã bị vô hiệu hóa. Quá trình này mất 16 giờ; bạn có thể đọc riêng về cách thức và lý do SWAP tắt quá chậm. Cài đặt đã được thay đổi swappiness đến một giá trị bằng 5 trên khắp đám mây.
Làm thế nào điều này có thể không xảy ra?. Thứ nhất, nếu SWAP nằm trên thiết bị SSD RAID hoặc NVMe và thứ hai, nếu không có thiết bị NVMe nhưng thiết bị chậm hơn sẽ không tạo ra lượng dữ liệu như vậy - trớ trêu thay, sự cố lại xảy ra do NVMe đó quá nhanh.
Sau đó, mọi thứ bắt đầu hoạt động như trước - không có IOWAIT.
Nguồn: www.habr.com