iSCSI для NetApp FAS: высокая задержка при записи

Проблема

Инициатор Linux iSCSI обнаруживает большое время обслуживания при записи в цель NetApp FAS, открывая кучу LUN. Где искать причину и как ее устранить?

Размножение

Я использую iostats и sa из пакета sysstat, чтобы вычислить «ожидание» - среднее время ожидания конкретного запроса:

dd if=/dev/urandom of=test bs=8K count=1000000 & iostat -xdm 5 sdy dm-26
[...]
Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
sdy               0.00  1115.60    0.10   47.50     0.00     7.94   341.68     1.63   34.05   2.00   9.52
dm-26             0.00     0.00    0.10 2032.90     0.00     7.94     8.00   328.10  161.39   0.05   9.52

В этом сценарии ожидаемое значение для "ожидания" будет на одну величину ниже, чем значение, измеренное iostats. 10-секундный сетевой трафик, переданный за период времени в приведенном выше примере, составляет доступно в CloudShark. dm-26 устройство сопоставления устройств, на котором размещена файловая система (однодисковый том NSS), относящееся к sdy «физическое» устройство.

Окружающая среда

Инициатор и цель находятся в одной подсети. Хост-инициатор имеет IP-адрес 192.168.20.72, цель - 192.168.20.33, трафик коммутируется 1GbE, Jumbo Frames включены (и подтверждены для использования через трассировку сети), iSCSI Immediate Data включены (и используются как согласно упомянутой трассировке) дайджесты не включены.

Информация о сеансе iSCSI:

iscsiadm -m session -P 3
iSCSI Transport Class version 2.0-870
version 2.0-873.suse
Target: iqn.1992-08.com.netapp:sn.151745715
        Current Portal: 192.168.20.33:3260,2003
        Persistent Portal: 192.168.20.33:3260,2003
                **********
                Interface:
                **********
                Iface Name: default
                Iface Transport: tcp
                Iface Initiatorname: iqn.2015-06.de.example.dom:01:gw-cl-07
                Iface IPaddress: 192.168.20.72
                Iface HWaddress: <empty>
                Iface Netdev: <empty>
                SID: 1
                iSCSI Connection State: LOGGED IN
                iSCSI Session State: LOGGED_IN
                Internal iscsid Session State: NO CHANGE
                *********
                Timeouts:
                *********
                Recovery Timeout: 120
                Target Reset Timeout: 30
                LUN Reset Timeout: 30
                Abort Timeout: 15
                *****
                CHAP:
                *****
                username: <empty>
                password: ********
                username_in: <empty>
                password_in: ********
                ************************
                Negotiated iSCSI params:
                ************************
                HeaderDigest: None
                DataDigest: None
                MaxRecvDataSegmentLength: 262144
                MaxXmitDataSegmentLength: 65536
                FirstBurstLength: 65536
                MaxBurstLength: 65536
                ImmediateData: Yes
                InitialR2T: No
                MaxOutstandingR2T: 1
                ************************
                Attached SCSI devices:
                ************************
                Host Number: 3  State: running
                scsi3 Channel 00 Id 0 Lun: 0
                        Attached scsi disk sdb          State: running
                scsi3 Channel 00 Id 0 Lun: 1
                        Attached scsi disk sdc          State: running
                scsi3 Channel 00 Id 0 Lun: 10
                        Attached scsi disk sdl          State: running
                scsi3 Channel 00 Id 0 Lun: 11
                        Attached scsi disk sdm          State: running
                scsi3 Channel 00 Id 0 Lun: 12
                        Attached scsi disk sdn          State: running
                scsi3 Channel 00 Id 0 Lun: 13
                        Attached scsi disk sdo          State: running
                scsi3 Channel 00 Id 0 Lun: 14
                        Attached scsi disk sdp          State: running
                scsi3 Channel 00 Id 0 Lun: 15
                        Attached scsi disk sdq          State: running
                scsi3 Channel 00 Id 0 Lun: 16
                        Attached scsi disk sdr          State: running
                scsi3 Channel 00 Id 0 Lun: 17
                        Attached scsi disk sds          State: running
                scsi3 Channel 00 Id 0 Lun: 18
                        Attached scsi disk sdt          State: running
                scsi3 Channel 00 Id 0 Lun: 19
                        Attached scsi disk sdu          State: running
                scsi3 Channel 00 Id 0 Lun: 2
                        Attached scsi disk sdd          State: running
                scsi3 Channel 00 Id 0 Lun: 20
                        Attached scsi disk sdv          State: running
                scsi3 Channel 00 Id 0 Lun: 21
                        Attached scsi disk sdw          State: running
                scsi3 Channel 00 Id 0 Lun: 22
                        Attached scsi disk sdx          State: running
                scsi3 Channel 00 Id 0 Lun: 23
                        Attached scsi disk sdy          State: running
                scsi3 Channel 00 Id 0 Lun: 24
                        Attached scsi disk sdz          State: running
                scsi3 Channel 00 Id 0 Lun: 25
                        Attached scsi disk sdaa         State: running
                scsi3 Channel 00 Id 0 Lun: 26
                        Attached scsi disk sdab         State: running
                scsi3 Channel 00 Id 0 Lun: 27
                        Attached scsi disk sdac         State: running
                scsi3 Channel 00 Id 0 Lun: 28
                        Attached scsi disk sdad         State: running
                scsi3 Channel 00 Id 0 Lun: 3
                        Attached scsi disk sde          State: running
                scsi3 Channel 00 Id 0 Lun: 4
                        Attached scsi disk sdf          State: running
                scsi3 Channel 00 Id 0 Lun: 5
                        Attached scsi disk sdg          State: running
                scsi3 Channel 00 Id 0 Lun: 6
                        Attached scsi disk sdh          State: running
                scsi3 Channel 00 Id 0 Lun: 7
                        Attached scsi disk sdi          State: running
                scsi3 Channel 00 Id 0 Lun: 8
                        Attached scsi disk sdj          State: running
                scsi3 Channel 00 Id 0 Lun: 9
                        Attached scsi disk sdk          State: running

Другие наблюдения

По той или иной причине dm устройство, которое отображается на «физический» LUN, показывает значительное увеличение времени ожидания всякий раз, когда запросы записи объединяются в очередь запросов. Но мой вопрос на самом деле касается ожиданий на базовом устройстве - NetApp FAS должен просто помещать все запросы на запись в свою NVRAM и мгновенно подтверждать, даже для синхронной записи, поэтому я никогда не должен видеть ожидания выше 5 мс, пока сетевое соединение не насыщен (а это не так), и NVRAM не имеет противодавления (чего нет - FAS в настоящее время вообще не обрабатывает никакую другую нагрузку).

Время ожидания значительно меньше для операций чтения, даже для случайных чтений. Визуализированные 10-секундные данные sysstat из интервала, где iozone выполнял тест произвольного чтения / записи (однопоточный автоматический-type тестовый прогон с включенным O_DSYNC, размер блока 8K) показывает эффект: первая половина графика - случайные чтения, выполняющиеся со скоростью ~ 2-4 kIOPS и задержкой ~ 3 мс. Во второй половине рабочая нагрузка переключается на случайную запись, ожидание увеличивается до> 10 мс, а количество операций ввода-вывода в секунду падает до ~ 100 (нагрузка связана с задержкой и является однопоточной, поэтому количество операций ввода-вывода в секунду обратно пропорционально задержке)

По какой-то причине при анализе перехвата сетевого трафика выше статистическая функция Wireshark «Время отклика службы» для SCSI не может распознать большую часть write вызовы обнаруживают только 19 запросов и сообщают о среднем времени отклика службы 3 мс, при этом я ожидал бы около 500 вызовов и среднее значение SRT, подобное ожиданию 34 мс.

Используемый Linux - SuSE SLES 11 SP3, ядро 3.0.101-0.47.55 по умолчанию.

Я отредактирую этот ответ на основе дополнительной информации. Во-первых, нам нужно определить, соблюдает ли ожидание также NetApp или только хост. Если хост видит высокое время обслуживания, но NAS утверждает, что время обслуживания низкое, это что-то среднее между портами NAS и стеком SCSI сервера.

Какую версию data ontap вы используете? 7-режимный или CDOT? Что такое настройка LUN OS и настройка igroup OS? Обладая этой информацией, я могу предоставить вам команды, которые вы можете использовать в NetApp для проверки наблюдаемой задержки хранилища.

Слишком долго для комментария;

Я не гуру Linux, но в Windows отключаю Разгрузка большой отправки TCP на сетевом адаптере, так как это может привести к задержке. Он отправляет меньше пакетов, но больше, но для критического ввода-вывода это не рекомендуется.

Официальное объяснение;

Параметр TCP Large Send Offload позволяет уровню TCP AIX создавать сообщение TCP длиной до 64 КБ и отправлять его за один вызов по стеку через IP и драйвер устройства Ethernet. Затем адаптер повторно сегментирует сообщение на несколько кадров TCP для передачи по сети. Пакеты TCP, отправляемые по сети, представляют собой либо 1500-байтовые кадры для максимального блока передачи (MTU), либо 1500-байтовые кадры для MTU, равного 9000 (jumbo-кадры).