Назад | Перейти на главную страницу

Низкая производительность чтения MD3000i (для одного контроллера, но не для другого)

У нас есть массив MD3000i, к которому обращаются три отдельных сервера (все блейд-серверы имеют доступ через ник-шасси). Контроллер 1 (оба порта 0 и 1) связаны с сервером A. Серверы B и C (оба с существенно меньшей активностью, чем сервер A) связаны с контроллером 0 (порты 0 и 1). Сервер A находится в отдельной VLAN (подключен к MD3000i через коммутатор на задней панели корпуса блейд-сервера), а серверы B и C находятся в своей собственной VLAN (также подключены к MD3000i через переключатель на задней панели корпуса блейд-сервера). ).

Проблема, с которой мы сталкиваемся, заключается в том, что сервер A явно имеет лучшую пропускную способность чтения с MD3000i. Например, при просмотре заданий резервного копирования, выполняемых через этот сервер, скорость выполнения заданий составляет примерно 3000 МБ / мин. Однако при просмотре заданий резервного копирования, выполняемых через серверы B или C, скорость выполнения заданий составляет всего 200 МБ / мин.

Если я просматриваю статистику передачи iSCSI MAC через MDSM, между контроллерами очень разные показания (помимо общего объема):

Mac transmit statistics

MAC transmit legend

F = Frame Count
B = Byte Count
MF = Multicast Frame Count
BF = Broadcast Frame Count
PF = Pause Frame Count
CF = Control Frame Count
FDF = Frame Deferral Count
FED = Frame Excess Deferral Count
FLC = Frame Late Collisions Count
FA = Frame Abort Count
FSC = Frame Single Collision Count
FMC = Frame Multiple Collisions Count
FC = Frame Collision Count
FDR = Frame Dropped Count
JF = Jumbo Frame Count

iSCSI Host   | Port    | F            | B               | MF     | BF     | PF   | CF     | FDF  | FED  | FLC  | FA   | FSC  | FMC  | FC   | FDR  | JF

Controller 0 |  port 0 | 440573739    | 651904980400    | 0      | 0      | 0    | 0      | 0    | 0    | 0    | 0    | 0    | 0    | 0    | 0    | 0
Controller 0 |  port 1 | 440549412    | 651892177000    | 0      | 0      | 0    | 0      | 0    | 0    | 0    | 0    | 0    | 0    | 0    | 0    | 0
Controller 1 |  port 0 | 109676946034 | 148467634266838 | 0      | 0      | 512  | 131072 | 512  | 1024 | 1024 | 1024 | 512  | 1792 | 2304 | 2304 | 589824
Controller 1 |  port 1 | 402653242    | 111669157090    | 524288 | 524288 | 2304 | 720896 | 2304 | 3328 | 3840 | 4352 | 2048 | 3584 | 5632 | 2048 | 1114112

Я подозреваю, что сетевая карта, используемая серверами B и C, не имеет возможностей, необходимых для достижения требуемой производительности (обратите внимание, что количество Jumbo-кадров равно 0 - Jumbo-кадры - это то, что я видел рекомендованным при нескольких серверы обращаются к одному контроллеру MD3000i). Сервер A получает доступ к MD3000i через Broadcom BCM57085 NetXtreme II, а серверы B и C получают доступ к MD3000i через двойной порт Intel PRO / 1000 МБ.

На данный момент у меня нет надежного метода для выявления причины низкой пропускной способности чтения на контроллере 0 (серверы B и C).

Да, скорее всего, проблема заключается в отсутствии больших кадров.

Для кадра MTU размером 1500 байт у вас, вероятно, будет около 200-250 байт накладных расходов между iSCSI, контрольной суммой, TCP / IP, кадрированием Ethernet и т. Д. Таким образом, для передачи данных остается около 1250 байт. С другой стороны, большой кадр размером 9000 MTU может передавать примерно в 7 раз больше данных с теми же издержками.

Вы также можете проверить, есть ли на картах механизм разгрузки TCP (TOE), и убедиться, что они включены. Это может оказать приличное влияние на пропускную способность, особенно если процессор начинает блокировать процесс.