Một câu chuyện ngắn về fio và etcd
Hiệu suất cụm phần lớn phụ thuộc vào hiệu suất lưu trữ của nó. etcd xuất một số số liệu sang để cung cấp thông tin hiệu suất lưu trữ mong muốn. Ví dụ: chỉ số wal_fsync_duration_seconds. : Để lưu trữ được coi là đủ nhanh, phân vị thứ 99 của chỉ số này phải nhỏ hơn 10 mili giây. Nếu bạn định chạy một cụm etcd trên máy Linux và muốn đánh giá xem bộ lưu trữ của bạn có đủ nhanh không (ví dụ: SSD), bạn có thể sử dụng là một công cụ phổ biến để kiểm tra hoạt động I/O. Chạy lệnh sau, trong đó test-data là thư mục bên dưới điểm gắn kết bộ nhớ:
fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytestBạn chỉ cần xem kết quả và kiểm tra xem phân vị thứ 99 của thời lượng ít hơn 10 ms. Nếu vậy, bạn có dung lượng lưu trữ khá nhanh. Đây là một ví dụ về kết quả:
sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
sync percentiles (usec):
| 1.00th=[ 553], 5.00th=[ 578], 10.00th=[ 594], 20.00th=[ 627],
| 30.00th=[ 709], 40.00th=[ 750], 50.00th=[ 783], 60.00th=[ 1549],
| 70.00th=[ 1729], 80.00th=[ 1991], 90.00th=[ 2180], 95.00th=[ 2278],
| 99.00th=[ 2376], 99.50th=[ 9634], 99.90th=[15795], 99.95th=[15795],
| 99.99th=[15795]Ghi chú
- Chúng tôi đã tùy chỉnh các tùy chọn --size và --bs cho kịch bản cụ thể của mình. Để nhận được kết quả hữu ích từ fio, hãy cung cấp các giá trị của riêng bạn. Lấy chúng ở đâu? Đọc .
- Trong quá trình thử nghiệm, tất cả tải I/O đều đến từ fio. Trong một tình huống thực tế, có khả năng sẽ có các yêu cầu ghi khác được đưa vào bộ lưu trữ bên cạnh những yêu cầu liên quan đến wal_fsync_duration_seconds. Tải thêm sẽ tăng giá trị của wal_fsync_duration_seconds. Vì vậy, nếu phân vị thứ 99 gần bằng 10 mili giây, bộ nhớ của bạn sắp hết tốc độ.
- Lấy phiên bản không thấp hơn 3.5 (những cái trước không hiển thị phần trăm thời lượng fdatasync).
- Trên đây chỉ là một đoạn kết quả từ fio.
Câu chuyện dài về fio và etcd
WAL trong etcd là gì
Cơ sở dữ liệu thường sử dụng ; etcd cũng sử dụng nó. Chúng tôi sẽ không thảo luận chi tiết về nhật ký viết trước (WAL) ở đây. Chúng ta chỉ cần biết rằng mỗi thành viên của cụm etcd duy trì nó trong bộ lưu trữ liên tục là đủ. etcd ghi từng hoạt động khóa-giá trị (chẳng hạn như cập nhật) vào WAL trước khi áp dụng nó vào cửa hàng. Nếu một trong các thành viên lưu trữ gặp sự cố và khởi động lại giữa các ảnh chụp nhanh, nó có thể khôi phục cục bộ các giao dịch kể từ ảnh chụp nhanh cuối cùng theo nội dung WAL.
Khi khách hàng thêm khóa vào kho lưu trữ khóa-giá trị hoặc cập nhật giá trị của khóa hiện có, etcd sẽ ghi lại hoạt động trong WAL, đây là một tệp thông thường trong bộ lưu trữ liên tục. etcd PHẢI hoàn toàn chắc chắn rằng mục WAL đã thực sự xảy ra trước khi tiếp tục xử lý. Trên Linux, một cuộc gọi hệ thống là không đủ cho việc này. , vì quá trình ghi thực tế vào bộ nhớ vật lý có thể bị trì hoãn. Ví dụ: Linux có thể lưu trữ một mục nhập WAL trong bộ đệm trong bộ nhớ nhân (chẳng hạn như bộ đệm trang) trong một thời gian. Và để dữ liệu được ghi chính xác vào bộ lưu trữ liên tục, cần có lệnh gọi hệ thống fdatasync sau khi ghi và etcd chỉ cần sử dụng nó (như bạn có thể thấy trong kết quả của công việc , trong đó 8 là bộ mô tả tệp WAL):
21:23:09.894875 lseek(8, 0, SEEK_CUR) = 12808 <0.000012>
21:23:09.894911 write(8, ". 20210220361223255266632$10 20103026"34"rn3fo"..., 2296) = 2296 <0.000130>
21:23:09.895041 fdatasync(8) = 0 <0.008314>Thật không may, việc ghi vào bộ lưu trữ liên tục không xảy ra ngay lập tức. Nếu cuộc gọi fdatasync chậm, hiệu suất của hệ thống etcd sẽ bị ảnh hưởng. rằng bộ lưu trữ được coi là đủ nhanh nếu ở phân vị thứ 99, lệnh gọi fdatasync mất ít hơn 10 mili giây để ghi vào tệp WAL. Có các số liệu hữu ích khác để lưu trữ, nhưng trong bài đăng này, chúng tôi chỉ nói về số liệu này.
Ước tính dung lượng lưu trữ với fio
Nếu bạn cần đánh giá xem bộ lưu trữ của mình có phù hợp với etcd hay không, hãy sử dụng fio, một công cụ kiểm tra tải I/O rất phổ biến. Cần nhớ rằng các hoạt động của đĩa có thể rất khác nhau: đồng bộ và không đồng bộ, nhiều loại lệnh gọi hệ thống, v.v. Kết quả là fio khá khó sử dụng. Nó có nhiều tham số và các kết hợp giá trị khác nhau của chúng tạo ra khối lượng công việc I/O rất khác nhau. Để có số liệu đầy đủ cho etcd, bạn nên đảm bảo rằng tải ghi thử nghiệm từ fio càng gần với tải thực tế từ etcd khi ghi tệp WAL càng tốt.
Do đó, tối thiểu fio nên tạo một tải dưới dạng một loạt các lần ghi liên tiếp vào tệp, mỗi lần ghi sẽ bao gồm một lệnh gọi hệ thống theo sau là cuộc gọi hệ thống fdatasync. Ghi tuần tự vào fio yêu cầu tùy chọn --rw=write. Để fio sử dụng lệnh gọi hệ thống ghi khi viết, thay vì , bạn nên chỉ định tham số --ioengine=sync. Cuối cùng, để gọi fdatasync sau mỗi lần ghi, bạn cần thêm tham số --fdatasync=1. Hai tùy chọn khác trong ví dụ này (--size và -bs) dành riêng cho tập lệnh. Trong phần tiếp theo, chúng tôi sẽ chỉ cho bạn cách thiết lập chúng.
Tại sao chính xác là fio và cách chúng tôi học cách thiết lập nó
Trong bài đăng này, chúng tôi mô tả một trường hợp thực tế. Chúng tôi có một cụm v1.13 mà chúng tôi đã theo dõi bằng Prometheus. etcd v3.2.24 được lưu trữ trên ổ SSD. Các số liệu v.v. cho thấy độ trễ fdatasync quá cao, ngay cả khi cụm không làm gì. Các số liệu rất lạ và chúng tôi không thực sự hiểu ý nghĩa của chúng. Cụm bao gồm các máy ảo, cần phải hiểu vấn đề là gì: ở SSD vật lý hay ở lớp ảo hóa. Ngoài ra, chúng tôi thường thực hiện các thay đổi đối với cấu hình phần cứng và phần mềm và chúng tôi cần một cách để đánh giá kết quả của chúng. Chúng tôi có thể chạy etcd trong mọi cấu hình và xem các số liệu của Prometheus, nhưng điều đó quá phức tạp. Chúng tôi đang tìm kiếm một cách khá đơn giản để đánh giá một cấu hình cụ thể. Chúng tôi muốn kiểm tra xem chúng tôi có hiểu chính xác các chỉ số Prometheus từ etcd hay không.
Nhưng đối với điều này, hai vấn đề phải được giải quyết. Đầu tiên, tải I/O mà etcd tạo ra khi ghi vào WAL trông như thế nào? Những cuộc gọi hệ thống nào được sử dụng? Kích thước của các bản ghi là gì? Thứ hai, nếu chúng tôi trả lời những câu hỏi này, làm cách nào để chúng tôi tạo lại khối lượng công việc tương tự với fio? Đừng quên rằng fio là một công cụ rất linh hoạt với nhiều tùy chọn. Chúng tôi đã giải quyết cả hai vấn đề theo một cách tiếp cận - sử dụng các lệnh и . lsof liệt kê tất cả các bộ mô tả tệp được sử dụng bởi quy trình và các tệp liên quan của chúng. Và với strace, bạn có thể kiểm tra một quy trình đang chạy hoặc bắt đầu một quy trình và kiểm tra nó. strace in tất cả các lệnh gọi hệ thống từ quy trình đang được kiểm tra (và các quy trình con của nó). Cái sau rất quan trọng, vì etcd chỉ thực hiện một cách tiếp cận tương tự.
Lần đầu tiên chúng tôi sử dụng strace để khám phá máy chủ etcd cho Kubernetes khi không có tải trên cụm. Chúng tôi thấy rằng hầu hết tất cả các bản ghi WAL đều có cùng kích thước: 2200–2400 byte. Do đó, trong lệnh ở đầu bài, chúng tôi đã chỉ định tham số -bs=2300 (bs có nghĩa là kích thước tính bằng byte cho mỗi mục nhập fio). Lưu ý rằng kích thước của mục etcd phụ thuộc vào phiên bản etcd, phân phối, giá trị tham số, v.v. và ảnh hưởng đến thời lượng fdatasync. Nếu bạn gặp trường hợp tương tự, hãy kiểm tra các quy trình etcd của bạn bằng strace để tìm ra con số chính xác.
Sau đó, để hiểu rõ hệ thống tệp etcd đang làm gì, chúng tôi đã bắt đầu nó với các tùy chọn strace và -ffttT. Vì vậy, chúng tôi đã cố gắng kiểm tra các quy trình con và ghi lại đầu ra của từng quy trình đó trong một tệp riêng biệt, đồng thời nhận được các báo cáo chi tiết về thời điểm bắt đầu và thời lượng của mỗi cuộc gọi hệ thống. Chúng tôi đã sử dụng lsof để xác nhận phân tích của chúng tôi về đầu ra strace và xem bộ mô tả tệp nào đang được sử dụng cho mục đích nào. Vì vậy, với sự trợ giúp của strace, kết quả hiển thị ở trên đã thu được. Số liệu thống kê về thời gian đồng bộ hóa đã xác nhận rằng wal_fsync_duration_seconds từ etcd nhất quán với lệnh gọi fdatasync với bộ mô tả tệp WAL.
Chúng tôi đã xem qua tài liệu về fio và chọn các tùy chọn cho tập lệnh của mình để fio tạo ra tải tương tự như etcd. Chúng tôi cũng đã kiểm tra các cuộc gọi hệ thống và thời lượng của chúng bằng cách chạy fio từ strace, tương tự như v.v.
Chúng tôi đã cẩn thận chọn giá trị của tham số --size để biểu thị toàn bộ tải I/O từ fio. Trong trường hợp của chúng tôi, đây là tổng số byte được ghi vào bộ lưu trữ. Hóa ra nó tỷ lệ thuận với số lần gọi hệ thống ghi (và fdatasync). Đối với một giá trị nhất định của bs, số lần gọi fdatasync = size/bs. Vì chúng tôi quan tâm đến phần trăm, nên chúng tôi phải có đủ mẫu để chắc chắn và chúng tôi đã tính toán rằng 10^4 là đủ cho chúng tôi (tức là 22 mebibyte). Nếu --size nhỏ hơn, thì có thể xảy ra các ngoại lệ (ví dụ: một số lệnh gọi fdatasync mất nhiều thời gian hơn bình thường và ảnh hưởng đến phân vị thứ 99).
Tự mình thử
Chúng tôi đã chỉ cho bạn cách sử dụng fio và xem liệu bộ lưu trữ có đủ nhanh để etcd hoạt động tốt hay không. Giờ đây, bạn có thể tự mình dùng thử, chẳng hạn như các máy ảo có bộ lưu trữ SSD trong .
Nguồn: www.habr.com