Sự khác biệt về hiệu năng SAS so với SATA?


16

Không thể tìm thấy bất cứ nơi nào có vẻ như.

Sự khác biệt hiệu suất được mong đợi trong kịch bản phụ trợ lưu trữ bị sai lệch nhiều về quyền truy cập (như SAN, lưu trữ máy chủ ảo hóa, v.v.) giữa SAS và SATA, tất cả những thứ khác có bằng nhau không?

Tôi nghĩ rằng nó chạy theo tác động của NCQ (giới hạn lệnh 32) đến giới hạn lệnh xuất hiện cao hơn MUCH của các đĩa SAS.

Chúng tôi đang xem xét việc thay thế một số đĩa và có cơ hội sử dụng SAS hoặc SATA - tất cả phần còn lại đã sẵn sàng - và tôi tìm kiếm một đánh giá từ điểm hiệu suất. Vui lòng bỏ qua tất cả các vấn đề khác (độ tin cậy, v.v.) - Tôi hoàn toàn tự hỏi về tác động mà SAS sẽ gây ra đối với các đĩa được xác định tương tự (RPM, v.v.) bằng nhau). Các đĩa mà chúng tôi có trong tâm trí có thể được đặt hàng bằng cả hai đầu nối và - có một ý tưởng ở đây là sử dụng SATA để ap có thể tái sử dụng sau này. Sự khác biệt về giá không thực sự cao, nhưng nó khiến tôi tự hỏi về tác động hiệu suất ...


2
Không giống như bạn hỏi "Tất cả mọi thứ đều bằng nhau" bởi vì sự khác biệt trong SAS và SATA là đủ để mọi thứ ... không bằng nhau.
Mark Henderson

@MarkHenderson Thực tế là - tất cả những thứ khác có thể bằng nhau. Seagate cung cấp một số đĩa có kết nối SAS hoặc SATA, vì vậy tất cả các tham số khác (bộ nhớ đệm, tốc độ quay, tốc độ di chuyển các bộ phận chuyển động) đều bằng nhau, tất cả đều chạy theo các vấn đề về Giao thức SAS / SATA.
TomTom

Tôi nghĩ rằng bạn phải đánh giá các đĩa cụ thể theo khối lượng công việc cụ thể của mình để hoàn toàn chắc chắn - có thể bạn có thể lấy một vài đĩa của mỗi đĩa, điểm chuẩn và gửi lại ở đây?
Andrew

@Andrew Vâng, giống như tôi là người duy nhất từng làm điều đó. Tôi nhớ (một cách mờ nhạt) một lần được bảo rằng sẽ có thêm khoảng 50% IOPS dựa trên độ dài hàng đợi nghiêm trọng có thể có trong SAS (nhưng không phải là SATA) dưới tải song song nặng (vì vậy thời gian dài thực sự xảy ra). Chỉ thiếu bất kỳ loại tài liệu tham khảo.
TomTom

1
Bạn đang xem xét gần tuyến SAS ở mức 7.2k RPM, hay SATA thực?
Basil

Câu trả lời:


11

Có, bộ lệnh mở rộng của SCSI là một phần thưởng lớn khi sử dụng nó trên SATA. từ Wiki của SAS :

SATA sử dụng một bộ lệnh dựa trên bộ lệnh ATA song song và sau đó được mở rộng ra ngoài bộ đó để bao gồm các tính năng như xếp hàng lệnh gốc, cắm nóng và TRIM. SAS sử dụng bộ lệnh SCSI, bao gồm một loạt các tính năng như phục hồi lỗi, đặt chỗ và cải tạo khối. ATA cơ bản chỉ có các lệnh để lưu trữ truy cập trực tiếp. Tuy nhiên, các lệnh SCSI có thể được tạo đường hầm thông qua ATAPI [2] cho các thiết bị như ổ đĩa CD / DVD.

Các lệnh khôi phục lỗi và các lệnh cải tạo khối là mấu chốt trong tính toàn vẹn dữ liệu, SMART thực sự dành cho thiết bị cấp tiêu dùng.

Ngoài ra, SAS sử dụng điện áp tín hiệu cao hơn, cho phép cáp dài hơn so với SATA. Điều đó quan trọng khi cố gắng kết nối bộ nhớ bổ sung vào SAN hiện có.

Bạn đã định danh NCQ, nhưng SCSI sử dụng TCQ thay thế, có thể được sử dụng ở ba chế độ khác nhau, tuy nhiên phần thưởng lớn hơn đối với các thiết lập song song là khả năng gửi tới 2 ^ 64 lệnh trước khi điền vào hàng đợi. Các giao thức như iSCSI và Fiber Channel hạn chế điều này ngay bây giờ nhưng khả năng là có để sử dụng trong tương lai.

Tôi chỉ có thể trả lời phần đó, vì tôi không biết nếu đi cùng với SAS cho một vài đĩa mới sẽ mang lại cho bạn lợi ích tương tự của việc thiết lập hoàn toàn SAS.


Một số tính năng khôi phục lỗi đang tràn vào ATA, với một số ổ đĩa hiện hỗ trợ TLER (mặc dù tôi không tin rằng có bất kỳ lệnh được tiêu chuẩn hóa nào trong ATA để định cấu hình thời gian chờ lỗi, như có trong SCSI).
Chris S

2

Đây là một câu trả lời muộn, nhưng tôi muốn thêm ý kiến ​​của tôi.

Từ quan điểm tốc độ thuần túy, một ổ đĩa gần (như những gì OP đã xem xét) sẽ thực hiện thực tế giống nhau cả khi sử dụng giao diện SATA hoặc giao diện SAS. Mặc dù NCQ có độ sâu thấp hơn nhiều ( 31 mục thay vì TCQ 64K), hàng đợi phần cứng giới hạn này là đủ, khi được tăng cường với hàng đợi IO dựa trên phần mềm sâu hơn nhiều, để trích xuất gần như các IOPS có thể thu được bằng cách sử dụng TCQ dựa trên SAS .

Dù sao, điều này không có nghĩa là SAS không có lợi thế thực tế:

  • hỗ trợ tốt hơn nhiều cho các bộ mở rộng
  • hỗ trợ giao diện liên kết đôi
  • hoạt động song công hoàn toàn
  • tốc độ báo hiệu tối đa nhanh hơn nhiều (12 Gb / s so với 6 Gb / s)

Tuy nhiên, khi xem xét hiệu suất một mình, thực tế đáng buồn là các giá trị IOPS ngẫu nhiên của đĩa cơ thấp đến mức giao diện gần như không có tác động, ngoại trừ các mảng đĩa lớn đôi khi có thể hạn chế tốc độ truyền IO liên tiếp của bạn. Do cách chúng tính độ trễ quay (được ẩn khỏi HĐH), tính năng tăng cường hiệu năng sát thủ là NCQ / TCQ và việc triển khai SATA đủ tốt ở đó.

Một số khác biệt đáng kể hơn xuất hiện khi xem xét các đĩa SAS cao cấp hơn, không chỉ cung cấp các đĩa RPM cao hơn (10K và 15K), mà còn có một số công nghệ kết hợp ghi thú vị (ví dụ: công nghệ bộ đệm phương tiện HGST), bằng cách nào, chậm tràn vào ổ đĩa doanh nghiệp-SATA cũng.

1 https://ata.wiki.kernel.org/index.php/Libata_FAQ :

Tuy nhiên, tiêu chuẩn ATA có một lỗi thiết kế. Thẻ NCQ được coi là bitmap 32 bit (từ khóa 32 bit). Nếu tất cả 32 thẻ được xác nhận, điều này tạo ra một giá trị (0xffffffff) có cùng giá trị được trả về bằng cách đọc một thanh ghi phần cứng sau khi phần cứng bị nóng, hoặc bị lỗi lớn. Do đó, để phân biệt điều kiện này, libata giới hạn một cách giả tạo tất cả các cấu hình NCQ ở mức 31 thẻ thay vì 32.


Câu trả lời tốt. Chúng tôi đã chuyển sang SSD SSD (trong một bảng nối đa năng) - thực sự bị giới hạn băng thông;) Nhưng cảm ơn, tôi đã mong đợi nhiều như bạn đã nói.
TomTom

Vâng, SSD là những con thú khác nhau;)
shodanshok

1

Bài đăng cũ, nhưng tôi muốn cập nhật nó vì tôi chưa bao giờ thấy đề cập đến sự khác biệt quan trọng nhất về hiệu suất, đó là SATA chỉ là một nửa song công. Mong đợi một sự khác biệt hiệu suất lớn dưới tải nặng với sự kết hợp giữa đọc / ghi. Chắc chắn không phù hợp với SAN hoặc ảo hóa IMO.

Tất nhiên như đã nêu ở trên, có những lợi ích khác với SAS. Ngày nay, đĩa NL-SAS có thể có nhiều hơn so với SATA.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.