🥇Cách kiểm tra đĩa fio xem có đủ hiệu năng cho etcd

Ghi chú. bản dịch.: Bài viết này là kết quả của một nghiên cứu nhỏ do các kỹ sư Đám mây của IBM thực hiện nhằm tìm kiếm giải pháp cho một vấn đề thực tế liên quan đến hoạt động của cơ sở dữ liệu etcd. Một nhiệm vụ tương tự có liên quan đến chúng tôi, tuy nhiên, quá trình phản ánh và hành động của các tác giả có thể thú vị trong bối cảnh rộng hơn.

Tóm tắt ngắn gọn toàn bộ bài viết: fio and etcd

Hiệu suất của cụm etcd phụ thuộc nhiều vào tốc độ của bộ lưu trữ bên dưới. etcd xuất các chỉ số Prometheus khác nhau để theo dõi hiệu suất. một trong số đó là wal_fsync_duration_seconds. Trong tài liệu cho etcd nó nói rằngdung lượng lưu trữ đó có thể được coi là đủ nhanh nếu phân vị thứ 99 của số liệu này không vượt quá 10 ms…

Nếu bạn đang xem xét thiết lập cụm etcd trên máy Linux và muốn kiểm tra xem ổ đĩa (chẳng hạn như SSD) có đủ nhanh hay không, chúng tôi khuyên bạn nên sử dụng trình kiểm tra I/O phổ biến có tên fio. Chỉ cần chạy lệnh sau (thư mục test-data phải được đặt trong phân vùng được gắn kết của ổ đĩa đã kiểm tra):

fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest

Chỉ còn cách xem đầu ra và kiểm tra xem phần trăm thứ 99 có phù hợp không fdatasync trong 10 ms. Nếu vậy, thì ổ đĩa của bạn đang hoạt động đủ nhanh. Đây là một ví dụ đầu ra:

fsync/fdatasync/sync_file_range:
  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]

Một số lưu ý:

Trong ví dụ trên, chúng tôi đã điều chỉnh các thông số --size и --bs cho một trường hợp cụ thể. Để có được một kết quả có ý nghĩa từ fio, chỉ định các giá trị phù hợp với trường hợp sử dụng của bạn. Làm thế nào để chọn chúng sẽ được thảo luận dưới đây.
Chỉ trong thời gian thử nghiệm fio tải hệ thống con đĩa. Trong cuộc sống thực, có khả năng các quy trình khác sẽ ghi vào đĩa (ngoài những quy trình liên quan đến wal_fsync_duration_seconds). Tải bổ sung này có thể tăng wal_fsync_duration_seconds. Nói cách khác, nếu phân vị thứ 99 từ thử nghiệm với fio, chỉ dưới 10 ms một chút, rất có thể hiệu suất lưu trữ không đủ.
Đối với bài kiểm tra, bạn sẽ cần phiên bản fio không thấp hơn 3.5, vì các phiên bản cũ hơn không tổng hợp kết quả fdatasync ở dạng phần trăm.
Kết luận trên chỉ là một đoạn trích nhỏ trong kết luận chung fio.

Tìm hiểu thêm về fio và vv

Đôi lời về WAL, v.v.

Nói chung, cơ sở dữ liệu sử dụng đăng nhập chủ động (ghi nhật ký ghi trước, WAL). etcd cũng bị ảnh hưởng. Một cuộc thảo luận về WAL nằm ngoài phạm vi của bài viết này, nhưng với mục đích của chúng tôi, điều bạn cần biết là mỗi thành viên cụm etcd lưu trữ WAL trong bộ lưu trữ liên tục. etcd ghi một số thao tác lưu trữ khóa-giá trị (chẳng hạn như cập nhật) vào WAL trước khi thực hiện chúng. Nếu một nút gặp sự cố và khởi động lại giữa các ảnh chụp nhanh, etcd sẽ có thể khôi phục các giao dịch kể từ ảnh chụp nhanh trước đó dựa trên nội dung của WAL.

Do đó, mỗi khi khách hàng thêm khóa vào kho lưu trữ KV hoặc cập nhật giá trị của khóa hiện có, etcd sẽ thêm mô tả hoạt động vào WAL, đây là một tệp thông thường trong kho lưu trữ liên tục. etcd PHẢI chắc chắn 100% rằng mục nhập WAL đã thực sự được lưu trước khi tiếp tục. Để đạt được điều này trên Linux, việc sử dụng lệnh gọi hệ thống là chưa đủ write, vì bản thân thao tác ghi vào phương tiện vật lý có thể bị trì hoãn. Ví dụ: Linux có thể giữ một mục nhập WAL trong bộ đệm nhân trong bộ nhớ (ví dụ: trong bộ đệm trang) trong một thời gian. Để đảm bảo rằng dữ liệu được ghi vào phương tiện, một cuộc gọi hệ thống phải được gọi sau khi ghi fdatasync - đây chính xác là những gì etcd làm (như bạn có thể thấy trong kết quả sau strace; Đây 8 - 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$1020103026"34"rn3fo"..., 2296) = 2296 <0.000130>
21:23:09.895041 fdatasync(8)            = 0 <0.008314>

Thật không may, ghi vào lưu trữ liên tục mất một thời gian. Việc thực hiện lệnh gọi fdatasync kéo dài có thể ảnh hưởng đến hiệu suất của etcd. Trong tài liệu kho lưu trữ chỉ ra, để có đủ hiệu suất, phần trăm thứ 99 của thời lượng tất cả các cuộc gọi cần fdatasync khi ghi vào tệp WAL chưa đến 10 ms. Có các số liệu khác liên quan đến dung lượng lưu trữ nhưng bài viết này sẽ tập trung vào số liệu đó.

Định giá dung lượng lưu trữ với fio

Bạn có thể đánh giá xem một bộ lưu trữ nhất định có phù hợp để sử dụng với etcd hay không bằng cách sử dụng tiện ích fio — một trình kiểm tra I/O phổ biến. Hãy nhớ rằng I/O của đĩa có thể xảy ra theo nhiều cách khác nhau: đồng bộ hóa/không đồng bộ, nhiều lớp syscall khác nhau, v.v. Mặt khác của đồng xu là fio cực kỳ khó sử dụng. Tiện ích có nhiều tham số và các kết hợp giá trị khác nhau của chúng dẫn đến kết quả hoàn toàn khác nhau. Để có được ước tính hợp lý cho etcd, bạn cần đảm bảo rằng tải ghi do fio tạo ra càng gần với tải ghi tệp WAL của etcd càng tốt:

Điều này có nghĩa là việc tạo ra fio tải ít nhất phải là một loạt các lần ghi liên tiếp vào tệp, trong đó mỗi lần ghi bao gồm một lệnh gọi hệ thống writetheo dõi bởi fdatasync.
Để cho phép viết tuần tự, bạn phải chỉ định cờ --rw=write.
Đó fio đã viết sử dụng các cuộc gọi write (chứ không phải các cuộc gọi hệ thống khác - ví dụ: pwrite), sử dụng cờ --ioengine=sync.
Cuối cùng, lá cờ --fdatasync=1 đảm bảo rằng đối với mỗi write nên fdatasync.
Hai tham số khác trong ví dụ của chúng tôi là: --size и --bs - có thể thay đổi tùy theo trường hợp sử dụng cụ thể. Phần tiếp theo sẽ mô tả cấu hình của chúng.

Tại sao chúng tôi chọn fio và cách chúng tôi học cách thiết lập nó

Ghi chú này xuất phát từ một trường hợp thực tế mà chúng tôi gặp phải. Chúng tôi đã có một cụm trên Kubernetes v1.13 với tính năng giám sát trên Prometheus. SSD đã được sử dụng làm bộ lưu trữ cho etcd v3.2.24. Số liệu Etcd cho thấy độ trễ quá cao fdatasync, ngay cả khi cụm không hoạt động. Đối với chúng tôi, những số liệu này có vẻ rất đáng ngờ và chúng tôi không chắc chúng đại diện chính xác cho điều gì. Ngoài ra, cụm bao gồm các máy ảo, vì vậy không thể nói liệu sự chậm trễ là do ảo hóa hay SSD là nguyên nhân.

Ngoài ra, chúng tôi đã xem xét nhiều thay đổi khác nhau trong cấu hình phần cứng và phần mềm, vì vậy chúng tôi cần một cách để đánh giá chúng. Tất nhiên, có thể chạy etcd trong từng cấu hình và xem các chỉ số Prometheus tương ứng, nhưng điều đó sẽ đòi hỏi nỗ lực đáng kể. Điều chúng tôi cần là một cách đơn giản để đánh giá một cấu hình cụ thể. Chúng tôi muốn kiểm tra hiểu biết của mình về các chỉ số Prometheus đến từ etcd.

Điều này đòi hỏi phải giải quyết hai vấn đề:

Đầu tiên, tải I/O do etcd tạo ra khi ghi vào tệp 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 khối bản ghi là gì?
Thứ hai, giả sử chúng ta có câu trả lời cho những câu hỏi trên. Cách tái tạo tải tương ứng với fio? Rốt cuộc fio — tiện ích cực kỳ linh hoạt với vô số tham số (điều này rất dễ xác minh, ví dụ: đây - xấp xỉ. bản dịch.).

Chúng tôi đã giải quyết cả hai vấn đề bằng cùng một cách tiếp cận dựa trên lệnh lsof и strace:

Với lsof bạn có thể xem tất cả các bộ mô tả tệp được quy trình sử dụng, cũng như các tệp mà chúng đề cập đến.
Với strace bạn có thể phân tích một quy trình đã chạy hoặc chạy một quy trình và xem nó. Lệnh hiển thị tất cả các cuộc gọi hệ thống được thực hiện bởi quy trình này và, nếu cần, hậu duệ của nó. Cái sau rất quan trọng đối với các quy trình đang rẽ nhánh và etcd là một trong những quy trình như vậy.

Điều đầu tiên chúng tôi làm là sử dụng strace để kiểm tra máy chủ etcd trong cụm Kubernetes khi nó không hoạt động.

Vì vậy, người ta thấy rằng các khối bản ghi WAL được nhóm rất dày đặc, kích thước của phần lớn nằm trong khoảng 2200-2400 byte. Đó là lý do tại sao lệnh ở đầu bài viết này sử dụng cờ --bs=2300 (bs là kích thước tính bằng byte của mỗi khối ghi trong fio).

Xin lưu ý rằng kích thước của các khối ghi etcd có thể khác nhau tùy thuộc vào phiên bản, triển khai, giá trị tham số, v.v. - nó ảnh hưởng đến thời lượng fdatasync. Nếu bạn có trường hợp sử dụng tương tự, hãy phân tích với strace các quy trình etcd của bạn để nhận các giá trị cập nhật.

Sau đó, để có được ý tưởng rõ ràng và toàn diện về cách thức hoạt động của etcd với hệ thống tệp, chúng tôi đã bắt đầu từ bên dưới strace với cờ -ffttT. Điều này cho phép nắm bắt các quy trình con và ghi đầu ra của từng quy trình vào một tệp riêng biệt. Ngoài ra, thông tin chi tiết về thời gian bắt đầu và thời lượng của mỗi cuộc gọi hệ thống đã được thu thập.

Chúng tôi cũng đã sử dụng lệnh lsofđể xác nhận sự hiểu biết của bạn về đầu ra strace về việc bộ mô tả tệp nào được sử dụng cho mục đích nào. tôi đã có kết luận strace, tương tự như trên. Thao tác thống kê với thời gian đồng bộ hóa đã xác nhận rằng số liệu wal_fsync_duration_seconds từ etcd phù hợp với các cuộc gọi fdatasync với bộ mô tả tệp WAL.

Để tạo với fio một khối lượng công việc tương tự như khối lượng công việc từ etcd, tài liệu của tiện ích đã được nghiên cứu và các tham số phù hợp với nhiệm vụ của chúng tôi đã được chọn. Chúng tôi đã xác minh rằng các cuộc gọi hệ thống chính xác đang diễn ra và xác nhận thời lượng của chúng bằng cách chạy fio của strace (như nó đã được thực hiện trong trường hợp etcd).

Đặc biệt chú ý đến việc xác định giá trị của tham số --size. Nó đại diện cho tổng tải I/O do tiện ích fio tạo ra. Trong trường hợp của chúng tôi, đây là tổng số byte được ghi vào phương tiện. Nó tỷ lệ thuận với số lượng cuộc gọi write (và fdatasync). Đối với một cụ thể bs số cuộc gọi fdatasync bằng size / bs.

Vì chúng tôi quan tâm đến phân vị nên chúng tôi muốn số lượng mẫu đủ lớn để có ý nghĩa thống kê. Và quyết định rằng 10^4 (tương ứng với kích thước 22 MB) là đủ. Giá trị tham số nhỏ hơn --size phát ra tiếng ồn rõ rệt hơn (ví dụ: các cuộc 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ùy bạn đấy

Bài viết chỉ ra cách sử dụng fio người ta có thể đánh giá liệu phương tiện dự định sử dụng với etcd có đủ nhanh hay không. Bây giờ nó thuộc về bạn! Bạn có thể khám phá các máy ảo có bộ lưu trữ dựa trên SSD trong dịch vụ Đám mây của IBM.

Tái bút từ người dịch

Với các trường hợp sử dụng làm sẵn fio Đối với các nhiệm vụ khác, xem tài liệu hoặc trực tiếp đến kho dự án (có nhiều hơn trong số chúng được đề cập trong tài liệu).

PPS từ người dịch

Đọc thêm trên blog của chúng tôi:

Nguồn: www.habr.com

Cách kiểm tra đĩa với fio để có đủ hiệu năng cho etcd