Tôi sẽ trả lời theo hai phần: đầu tiên "tại sao câu trả lời truyền thống về phân tách tuần tự và ngẫu nhiên thường không áp dụng."
Sau đó, tôi sẽ thảo luận về các lợi ích tiềm năng của việc tách các tệp trong tệp vật lý Windows và thêm các vHBA bổ sung và phân phối các tệp vật lý giữa chúng.
Mong đợi lợi ích từ việc tách IO đĩa ngẫu nhiên và tuần tự ở cấp độ vật lý Windows thường giả định các thiết bị HDD để lưu trữ dữ liệu. Nó cũng thường giả định rằng các vật lý Windows riêng biệt có nghĩa là các thiết bị HDD riêng biệt. Ý tưởng là một số bộ ổ cứng đang xử lý chủ yếu là đĩa IO tuần tự và có chuyển động đầu đĩa rất hạn chế (ví dụ: ổ cứng lưu trữ một txlog bận *) trong khi một bộ ổ cứng riêng biệt đang xử lý IO đĩa ngẫu nhiên.
Những giả định đó hiếm khi có được ngày hôm nay - đặc biệt là trong VM. Trước hết, trừ khi các VM vật lý Windows là RDM, nhiều trong số đó có thể nằm trong một kho dữ liệu - hoặc có thể nhiều kho dữ liệu nằm trên một LUN máy chủ ESXi. Vì vậy, những gì được phân tách trong khách có thể được xử lý ở cấp máy chủ ESXi.
Nhưng hãy nói rằng RDM được sử dụng hoặc mỗi máy khách vật lý nằm trên kho dữ liệu riêng của nó, trên ESXi LUN của chính nó. Ngay cả sau đó, tuần tự riêng biệt từ io ngẫu nhiên trong máy khách thường được xử lý tại mảng, vì các LUN được trình bày cho máy chủ ESXi có thể từ cùng một nhóm thiết bị đĩa. Hầu như mọi mảng lưu trữ đều thực hiện điều này ngay bây giờ - độc quyền hoặc là một tùy chọn để dễ dàng quản lý và tăng hiệu quả sử dụng tài nguyên / hiệu quả của mảng.
Cuối cùng, rất nhiều dung lượng lưu trữ ngày nay là tất cả flash hoặc hybrid flash + HDD. Không phải lo lắng về chuyển động, flash không quan tâm đến việc phân tách tuần tự cho ngẫu nhiên, thậm chí không quan tâm đến việc dệt IO.
Vì vậy, tất cả những lý do đó tách biệt tuần tự với ngẫu nhiên có thể không có lợi cho tất cả. Tiếp theo, tại sao việc truyền bá các tệp trên các tệp vật lý và truyền bá các tệp vật lý trên các vHBA vẫn có thể tăng hiệu suất.
* Tôi cố tình đề cập đến một nhật ký giao dịch trong ví dụ về ổ cứng này. Khi một số luồng IO tuần tự riêng biệt (ví dụ 8 nhật ký giao dịch bận) đang diễn ra trên cùng một ổ cứng - trừ khi gần như tất cả các hoạt động đều nằm trong bộ đệm SAN - chuyển động đầu liên tục giữa các rãnh IO liên tiếp dẫn đến dệt IO. Đó là một kiểu đập đầu đĩa cụ thể dẫn đến độ trễ của đĩa "tệ hơn ngẫu nhiên". Xảy ra trên RAID5 và RAID10, mặc dù RAID10 có thể chịu đựng được một chút thay đổi về vấn đề này so với RAID5 trước khi xuống cấp đáng kể.
Bây giờ - được cho là cuộc nói chuyện dài dòng về việc tách biệt tuần tự khỏi ngẫu nhiên có thể không giúp ích gì - làm thế nào để truyền bá các tệp trên vật lý vẫn có thể giúp? Làm thế nào có thể truyền bá vật lý giữa các vHBA?
Đó là tất cả về hàng đợi IO đĩa.
Bất kỳ Windows vật lý hoặc LogicalDisk nào cũng có thể có tới 255 IO đĩa nổi bật tại một thời điểm được báo cáo bởi perfmon là "Hàng đợi đĩa hiện tại". Từ các IO đĩa nổi bật trong hàng đợi vật lý, repositoryport có thể chuyển tối đa tới 254 tới minidriver. Nhưng minidriver cũng có thể có cả hàng đợi dịch vụ (được chuyển xuống cấp thấp hơn tiếp theo) và hàng đợi. Và repositoryport có thể được yêu cầu giảm số lượng mà nó chuyển từ 254.
Trong một máy khách VMware Windows, trình điều khiển pvscsi có độ sâu hàng đợi "thiết bị" mặc định là 64, trong đó thiết bị là một ổ đĩa vật lý. Vì vậy, mặc dù perfmon có thể hiển thị tới 255 IOs trong "chiều dài hàng đợi đĩa hiện tại" cho một đĩa vật lý duy nhất, nhưng chỉ có tối đa 64 trong số chúng được chuyển sang cấp độ tiếp theo (trừ khi thay đổi mặc định được thay đổi).
Có bao nhiêu IOs có thể nổi bật với mộtNhật ký giao dịch bận rộn tại một thời điểm? Chà, ghi nhật ký giao dịch có thể có kích thước lên tới 60kb. Trong một ETL quy mô cao, tôi thường thấy mỗi lần ghi vào txlog ở mức 60kb. Người viết txlog có thể có tới 32 lần viết 60kb xuất sắc cho một txlog mỗi lần. Vậy điều gì sẽ xảy ra nếu tôi có một txlog dàn dựng bận rộn và một txlog bận rộn trên cùng một đĩa vật lý, với các cài đặt VMware mặc định? Nếu cả hai txlog đều đạt tối đa 32 lần ghi 60kb nổi bật, thì tệp vật lý đó ở độ sâu hàng đợi là 64. Bây giờ, nếu còn có các tệp phẳng như một nguồn ETL trên bảng vật lý thì sao? Vâng, giữa các lần đọc đến các tệp tin phẳng và ghi txlog, họ sẽ phải sử dụng hàng đợi trong, vì chỉ 64 có thể thoát ra được một lúc. Đối với các cơ sở dữ liệu có txlog bận rộn như thế, cho dù là máy chủ vật lý hay ảo, tôi khuyên bạn nên sử dụng txlog trên vật lý riêng của mình, không có gì khác trên vật lý. Điều đó ngăn chặn việc xếp hàng ở cấp độ đó và cũng loại bỏ bất kỳ mối quan tâm nào với nội dung của nhiều tệp xen kẽ (đây là mối quan tâm ít, nhiều hơn nhiều trong những ngày này).
Có bao nhiêu IOs có thể nổi bật trong một tệp hàng tại một thời điểm (theo quan điểm của SQL Server, không nhất thiết phải gửi đến các cấp thấp hơn)? Bản thân SQL Server thực sự không có giới hạn (dù sao tôi cũng đã tìm thấy). Nhưng giả sử tập tin có trên Windows PhysicalDisk đơn (Tôi không khuyên bạn sử dụng đĩa năng động sọc cho SQL Server, đó là một chủ đề cho một thời điểm khác), có là một giới hạn. Đó là 255 tôi đã đề cập trước đó.
Với sự kỳ diệu của SQL Server readahead và IO không đồng bộ, tôi đã thấy 4 truy vấn đồng thời mỗi truy vấn chạy trong ổ đĩa nối tiếp có tổng "chiều dài hàng đợi đĩa hiện tại" là hơn 1200! Do giới hạn 255, điều đó thậm chí không thể thực hiện được với tất cả các nội dung hàng trên một đĩa vật lý. Nó đã chống lại một nhóm fileg chính với 8 tệp, mỗi tệp trên tệp vật lý riêng.
Vì vậy, đọc readahead có thể rất tích cực, và có thể nhấn mạnh hàng đợi IO. Họ có thể hung hăng đến mức các hàng khác đọc và viết cuối cùng chờ đợi. Nếu các nhật ký giao dịch nằm trên cùng một tệp vật lý như các hàng, thì trong quá trình đọc đồng thời, đọc và txlog sẽ rất dễ dàng để chờ đợi diễn ra. Ngay cả khi sự chờ đợi đó không ở mức "chiều dài hàng đợi đĩa hiện tại", nó vẫn có thể chờ ở hàng đợi thiết bị (64 theo mặc định với pvscsi).
Việc đọc sao lưu đối với các tệp hàng cũng có thể gây hấn, đặc biệt là nếu bộ đệm đã được điều chỉnh để tối đa hóa thông lượng sao lưu.
Có thêm một loại SQL Server io cần lưu ý khi xem xét cách ly txlogs: tràn truy vấn sang tempdb. Khi sự cố tràn truy vấn diễn ra, mỗi lần đổ tràn làm việc ghi vào tempdb. Có rất nhiều công nhân song song tất cả đổ ra cùng một lúc? Đó có thể là một tải ghi. Giữ một txlog bận rộn và các hàng đợi quan trọng tránh xa điều đó có thể thực sự hữu ích :-)
Bây giờ, có thể thay đổi độ sâu hàng đợi thiết bị mặc định cho trình điều khiển pvscsi. Nó mặc định là 64 và có thể được đặt ở mức cao nhất là 254, đó là kho chứa nhiều nhất sẽ vượt qua. Nhưng hãy cẩn thận thay đổi điều này. Tôi luôn khuyên bạn nên căn chỉnh độ sâu hàng đợi của thiết bị khách với độ sâu hàng đợi LUN của máy chủ ESXi bên dưới. Và thiết lập ESXi lưu trữ độ sâu hàng đợi LUN trên mỗi mảng thực hành tốt nhất. Sử dụng EMC VNX? Độ sâu hàng đợi LUN của máy chủ phải là 32. Khách sử dụng RDM? Tuyệt quá. Đặt độ sâu hàng đợi thiết bị pvscsi của khách thành 32 để nó được căn chỉnh với độ sâu hàng đợi LUN của máy chủ ESXi. EMC VMAX? Điển hình là 64 ở cấp máy chủ ESXi, 64 khách. Pure / Xtremio / IBM FlashSystem? Đôi khi độ sâu hàng đợi LUN của máy chủ sẽ được đặt cao tới 256! Đi trước và đặt độ sâu hàng đợi thiết bị pvscsi thành 254 (Tối đa có thể) sau đó.
Đây là một liên kết với các hướng dẫn.
https://kb.vmware.com/'mservice/microsites/search.do?lingu=en_US&cmd=displayKC&externalId=2053145
Liên kết cũng nói về các trang requestring - WhatAreThose ?? Họ xác định độ sâu hàng đợi cho bộ điều hợp pvscsi. Mỗi trang cung cấp 32 vị trí trong độ sâu hàng đợi bộ điều hợp. Theo mặc định, các trang requestring là 8 cho độ sâu hàng đợi bộ điều hợp là 256. Nó có thể được đặt cao tới 32 cho 1024 khe độ sâu hàng đợi bộ điều hợp.
Hãy nói rằng mọi thứ đều mặc định. Tôi đã có 8 tệp vật lý với các hàng trên chúng và SQL Server đang rất bận rộn. Có trung bình 32 "chiều dài hàng đợi đĩa hiện tại" trên 8 và không có gì cao hơn 64 (mọi thứ đều phù hợp với các hàng đợi dịch vụ thiết bị khác nhau). Tuyệt vời - mang lại cho 256 OIO. Nó phù hợp với hàng đợi dịch vụ thiết bị, nó phù hợp với hàng đợi dịch vụ bộ điều hợp, vì vậy tất cả 256 làm cho nó ra khỏi khách để xếp hàng ở cấp máy chủ ESX.
Tuy nhiên, nếu mọi thứ trở nên bận rộn hơn một chút, thì trung bình là 64 với hàng đợi của một số đĩa vật lý cao tới 128. Đối với những thiết bị có hơn 64 xuất sắc, phần thừa đang trong hàng chờ. Nếu có hơn 256 trong hàng đợi dịch vụ của thiết bị trên 8 vật lý, thì phần thừa sẽ có trong hàng đợi cho đến khi các vị trí trong hàng đợi dịch vụ bộ điều hợp mở ra.
Trong trường hợp đó, việc thêm một pvscsi vHBA khác và truyền bá các vật lý giữa chúng tăng gấp đôi tổng chiều sâu hàng đợi bộ điều hợp lên 512. Có thể truyền thêm io từ khách đến máy chủ cùng một lúc.
Một cái gì đó tương tự có thể đạt được bằng cách ở một bộ điều hợp pvscsi và tăng các trang yêu cầu. Chuyển đến 16 sẽ mang lại 512 vị trí và 32 mang lại 1024 vị trí.
Khi có thể, tôi khuyên bạn nên đi rộng (thêm bộ điều hợp) trước khi vào sâu (tăng độ sâu hàng đợi bộ điều hợp). Nhưng trên nhiều hệ thống bận rộn nhất, phải thực hiện cả hai: đặt 4 vHBA cho khách và tăng các trang yêu cầu lên 32.
Có rất nhiều cân nhắc khác, quá. Những thứ như sioc và điều chỉnh độ sâu hàng đợi thích ứng nếu vmdks được sử dụng, cấu hình đa đường, cấu hình của bộ điều hợp ESXi ngoài độ sâu hàng đợi LUN, v.v.
Nhưng tôi không muốn quá lời chào đón :-)
Lonny Niederstadt @sqL_handLe