Điều chỉnh lưu trữ iSCSI


29

Đây là một câu hỏi Canonical về iSCSI mà chúng ta có thể sử dụng làm tài liệu tham khảo.

iSCSI là một giao thức đặt các lệnh SCSI dưới dạng tải trọng vào các gói mạng TCP. Do đó, nó có thể gặp phải một loạt vấn đề khác so với Kênh sợi quang. Ví dụ: nếu một liên kết bị tắc nghẽn và bộ đệm của bộ chuyển mạch đã đầy, theo mặc định, Ethernet sẽ bỏ khung thay vì bảo máy chủ chạy chậm lại. Điều này dẫn đến việc truyền lại dẫn đến độ trễ cao cho một phần rất nhỏ lưu lượng lưu trữ.

Có các giải pháp cho vấn đề này, tùy thuộc vào hệ điều hành máy khách, bao gồm sửa đổi cài đặt mạng. Đối với danh sách các HĐH sau đây, cấu hình máy khách iSCSI tối ưu sẽ trông như thế nào? Nó sẽ liên quan đến việc thay đổi cài đặt trên các công tắc? Còn việc lưu trữ thì sao?

  • VMWare 4 và 5
  • Windows Hyper-V 2008 & 2008r2
  • Windows 2003 và 2008 trên kim loại trần
  • Linux trên kim loại trần
  • AIX VIO
  • Bất kỳ hệ điều hành nào khác mà bạn nghĩ sẽ có liên quan

iSCSI phức tạp hơn thế nhiều - nhưng đối với ngăn xếp IP, tất cả đều áp dụng cho các kết nối IP có thông lượng cao, độ trễ thấp - không có nhiều đặc biệt ở đây.
Nils

Câu trả lời:


6

Tôi không quen với VMWare, nhưng tôi sử dụng Xenserver và tôi đã sử dụng Hyper-V (R2).

Với cấu hình Xenserver hiện tại của tôi, tôi có:

  • 8 máy chủ Dell Poweredge 29xx
  • 2 công tắc Dell Powerconnect 6248
  • 2 Dell MD3000i SAN (iSCSI)

Tôi đã thiết lập các thiết bị chuyển mạch của mình trong cấu hình đa đường và được tối ưu hóa cho iSCSI bằng cách:

  • Tách các công tắc của tôi thành 3 VLans (2 cho lưu lượng iSCSI và 1 cho quản lý)
  • Sử dụng JumboFrames
  • Áp dụng tối ưu hóa "iSCSI" mà kết nối nguồn có

Mỗi máy chủ có nhiều card mạng để cung cấp kết nối cho mỗi bộ chuyển mạch, lần lượt cung cấp dự phòng thông qua đa đường giữa các máy chủ và iSCSI SAN. Các VSC iSCSI không chứa lưu lượng truy cập nào khác ngoài iSCSI.

Tôi vui mừng báo cáo rằng với cấu hình này, "cụm" Xenserver hoạt động tuyệt vời.

Bên cạnh đó, tôi có một máy chủ Windows 2008 được iSCSI kết nối trực tiếp với HP SAN (máy chủ tệp cũ). Nó được sử dụng để chạy Windows 2003 và thường xuyên ngắt kết nối (ngay cả sau khi cài đặt lại năm 2003); tuy nhiên, ngay khi tôi nâng cấp lên windows 2008 thì nó vẫn được kết nối.

Tôi sẽ vui lòng trả lời bất kỳ câu hỏi về thiết lập của tôi.


1
Bạn có đang sử dụng cáp xếp chồng giữa hai công tắc Dell không?
SpacemanSpiff

Tại sao iSCSI? Tại sao không DRBD trên MD3000 được kết nối trực tiếp?
Nils

@SpacemanSpiff Công tắc của tôi không được xếp chồng lên nhau.
Steve

@Nils Tôi chưa nghiên cứu về DRBD, mặc dù tôi đã nghe nói về nó. DRBD sẽ cung cấp gì qua iSCSI cho bộ nhớ được kết nối trực tiếp của tôi?
Steve

DRBD không có chi phí SCSI. Một điều khác là bạn không thể thoát khỏi quy trình iSCSI-client khi máy chủ iSCSI của bạn chết hoặc không thể truy cập được (điều này không phải là vấn đề trong thiết lập của bạn).
Nils

3

Đây không phải là một câu trả lời ... chưa. Đây là khuôn khổ cho Câu trả lời chung chung. Nếu bạn có thời gian xin vui lòng điền vào bất cứ điều gì bạn biết. Liên quan đến việc định cấu hình phần cứng cụ thể, vui lòng gửi câu trả lời riêng cho từng nhà cung cấp để chúng tôi có thể giữ thông tin đó được tổ chức và tách biệt.

Cấu hình QoS tới các cổng, cũng như tắt điều khiển bão, thiết lập MTU thành 9000, bật điều khiển luồng và đưa các cổng vào portfast

Thông lượng và độ trễ

Cập nhật firmware, trình điều khiển và các hệ thống khác

MPIO

Khung Jumbo / MTU

Khi tốc độ của các liên kết mạng tăng lên, số lượng các gói có khả năng được tạo ra cũng tăng. Điều này mang lại ngày càng nhiều CPU / thời gian gián đoạn dành cho việc tạo ra các gói có tác dụng làm gánh nặng quá mức cho hệ thống truyền và chiếm quá nhiều băng thông liên kết với việc đóng khung.

Các khung được gọi là "jumbo" là các khung Ethernet vượt quá giới hạn 1518 byte chính tắc. Mặc dù số lượng có thể thay đổi dựa trên các nhà cung cấp chuyển đổi, các hệ điều hành và kích thước gói jumbo điển hình nhất của NIC là 9000 và 9216 byte (loại sau là phổ biến nhất). Cho rằng khoảng 6 lần dữ liệu có thể được đưa vào khung 9K, số lượng gói thực tế (và ngắt) được giảm đi một lượng tương tự trên máy chủ. Những lợi ích này đặc biệt rõ rệt trên các liên kết tốc độ cao hơn (tức là 10GE) gửi khối lượng dữ liệu lớn (tức là iSCSI).

Việc kích hoạt các khung jumbo yêu cầu cấu hình của cả máy chủ và bộ chuyển mạch Ethernet và cần cẩn thận trước khi thực hiện. Một số hướng dẫn nên được tuân theo-

1.) Trong một phân đoạn Ethernet (Vlan) nhất định, tất cả các máy chủ và bộ định tuyến phải có cùng cấu hình MTU. Một thiết bị không có cấu hình phù hợp sẽ xem các khung lớn hơn là lỗi liên kết (cụ thể là "người khổng lồ") và thả chúng xuống.

2.) Trong giao thức IP, hai máy chủ có kích thước khung khác nhau cần một số cơ chế để đàm phán kích thước khung chung phù hợp. Đối với TCP, đây là phát hiện đường dẫn MTU (PMTU) và dựa vào việc truyền các gói không thể truy cập ICMP. Đảm bảo rằng PMTU được bật trên tất cả các hệ thống và mọi quy tắc tường lửa hoặc tường lửa của ACL đều cho phép các gói này.

Kiểm soát lưu lượng Ethernet (802.3x)

Mặc dù được một số nhà cung cấp iSCSI khuyên dùng, nhưng không nên bật điều khiển luồng ethernet đơn giản trong hầu hết các môi trường trừ khi tất cả các cổng chuyển đổi, NIC và liên kết hoàn toàn dành riêng cho lưu lượng iSCSI và không có gì khác. Nếu có bất kỳ lưu lượng truy cập nào khác trên các liên kết (chẳng hạn như chia sẻ tệp SMB hoặc NFS, nhịp tim cho lưu trữ theo cụm hoặc lưu lượng truy cập theo dõi / điều khiển theo nhóm, v.v.), không nên sử dụng điều khiển luồng đơn giản 802.3x vì nó chặn toàn bộ cổng và lưu lượng không phải iSCSI khác cũng sẽ bị chặn. Hiệu suất của Ethernet Flow Control thường là tối thiểu hoặc không tồn tại, việc đo điểm chuẩn thực tế phải được thực hiện trên toàn bộ các kết hợp OS / NIC / switch / lưu trữ được xem xét để xác định xem có bất kỳ lợi ích thực tế nào không.

Câu hỏi thực tế từ góc độ máy chủ là: Tôi có dừng lưu lượng mạng nếu NIC hoặc Mạng của tôi bị tràn hay tôi bắt đầu thả và truyền lại các gói không? Bật điều khiển luồng sẽ cho phép bộ đệm được làm trống ở phía bên nhận nhưng sẽ làm căng bộ đệm ở phía người gửi (thông thường một thiết bị mạng sẽ đệm ở đây).

Kiểm soát tắc nghẽn TCP (RFC 5681)

TOE (Công cụ giảm tải TCP / IP)

iSOE (Động cơ giảm tải iSCSI)

LSO (Phân đoạn TCP / Giảm tải gửi lớn)

Mạng cách ly

Một thực tiễn tốt nhất phổ biến cho iSCSI là cách ly cả người khởi xướng và mục tiêu khỏi lưu lượng mạng không lưu trữ khác. Điều này mang lại lợi ích về bảo mật, khả năng quản lý và, trong nhiều trường hợp, sự cống hiến tài nguyên cho lưu lượng lưu trữ. Sự cô lập này có thể có nhiều hình thức:

1.) Cách ly vật lý - tất cả những người khởi xướng chỉ có một hoặc nhiều NIC dành riêng cho lưu lượng iSCSI. Điều này có thể - hoặc có thể không ngụ ý phần cứng mạng chuyên dụng tùy thuộc vào khả năng của phần cứng được đề cập và các yêu cầu vận hành và bảo mật cụ thể trong một tổ chức nhất định.

2.) Cách ly logic - Chủ yếu được tìm thấy trong các mạng nhanh hơn (tức là 10GE), những người khởi xướng có gắn thẻ Vlan (xem 802.1q) để cấu hình lưu lượng lưu trữ và không lưu trữ.

Trong nhiều tổ chức, các cơ chế bổ sung được sử dụng để đảm bảo rằng những người khởi xướng iSCSI không thể liên lạc với nhau qua các mạng chuyên dụng này và hơn nữa, các mạng chuyên dụng này không thể truy cập được từ các mạng dữ liệu tiêu chuẩn. Các biện pháp được sử dụng để thực hiện điều này bao gồm danh sách kiểm soát truy cập tiêu chuẩn, Vlan riêng và tường lửa.

Một cái gì đó về bảng nối đa năng và chuyển đổi vải ở đây quá.

QoS (802.1p)

vlan (802.1q)

STP (RSTP, MSTP, v.v.)

Ngăn chặn lưu lượng truy cập (Kiểm soát bão, Điều khiển đa / rộng)

Bảo vệ

Xác thực và bảo mật

CHAP

IPSec

Lập bản đồ LUN (Thực tiễn tốt nhất)


Có bất kỳ điều chỉnh cho RFC 5681 trên bất kỳ thiết bị? Nếu không chúng ta nên xóa phần đó.
Nils

Có đáng để thêm rằng các khung jumbo hiếm khi được hỗ trợ cho sao chép iSCSI (vì tất cả các thiết bị WAN trung gian sẽ phải hỗ trợ chúng)?
Jeremy

@Jeremy chắc chắn - viết nó lên trên. Ngay cả trên mạng LAN - nếu bạn quên một thiết bị trên đường (hoặc nếu nhóm mạng thuê ngoài của bạn không cấu hình sai thứ gì đó), đường dẫn MTU sẽ không hỗ trợ các khung hình khổng lồ.
Nils

Đồng ý với Jeremy. Nils, nếu TCP-CC có sẵn cho phép nó có những lợi ích và hậu quả có thể xảy ra, những cái đó nên được phác thảo ít nhất.
Chris S

1

Một số xem xét và nghiên cứu bạn nên được thực hiện chủ quan liên quan đến:

1) Đa đường - Giải pháp SAN và HĐH của bạn, có thể là trình ảo hóa hoặc HĐH kim loại trần có thể cần phần mềm cụ thể của nhà cung cấp để điều này hoạt động đúng.

2) Người khởi xướng - Bạn cần kiểm tra xem người khởi tạo phần mềm có đủ hiệu suất dựa trên nhu cầu hay không. Nhiều NIC có khả năng giảm tải iSCSI có thể cải thiện đáng kể thông lượng, nhưng một số trình ảo hóa cũ hơn đã được biết là khá khó chịu với chúng hỗ trợ khôn ngoan. Các dịch vụ trưởng thành hơn (ESXi 4.1+) dường như được đặt tốt đẹp.

3) Bảo mật / Quyền - Đảm bảo loại bỏ hoàn toàn những người khởi xướng yêu cầu quyền truy cập vào LUN nào ... bạn sẽ ở trong một ngày tồi tệ nếu quản trị viên trên một trong các máy Windows của bạn thực hiện "khởi tạo đĩa" trên đĩa mà được một máy chủ khác sử dụng làm kho dữ liệu VMware.


Liên quan đến đa đường - thực ra bạn cũng có thể đạt được điều này thông qua các mạng khác nhau - điều này hơi khó với IP hơn so với FC-SAN (trong đó khái niệm SAN A / B với các loại vải phần cứng khác nhau là khá phổ biến).
Nils

Kinh nghiệm của tôi về đa đường chủ yếu là tương đương, trong trường hợp đó, khách hàng thường được cung cấp một địa chỉ IP khám phá (IP nhóm) và sau đó đàm phán với địa chỉ đó cho các địa chỉ đích thực tế. Tôi cho rằng điều này có thể được thực hiện với các mạng khác nhau và máy khách sẽ có đường dẫn đến đó, hoặc không, nhưng khám phá sẽ đi xuống nếu mạng con IP đó được bật là mạng đã chết.
SpacemanSpiff

Tôi đã thử đa năng (bản địa) trên SLES11 trên các Vlan khác nhau. Phần khó khăn là sửa đổi cấu hình đa đường, do đó, các mục tiêu iSCSI đi đến cùng một bộ lưu trữ vật lý được xem là cùng một thiết bị.
Nils
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.