Устранение пиков задержки в хранилищах данных ESXi NFS

44

Я испытываю задержки fsync около пяти секунд в хранилищах данных NFS в ESXi, которые запускаются некоторыми виртуальными машинами. Я подозреваю, что это может быть вызвано виртуальными машинами, использующими NCQ / TCQ, поскольку это не происходит с виртуальными дисками IDE.

Это можно воспроизвести с помощью fsync-tester (Тед Цо) и ioping . Например, с помощью действующей системы Grml с диском объемом 8 ГБ:

Linux 2.6.33-grml64:
root@dynip211 /mnt/sda # ./fsync-tester
fsync time: 5.0391
fsync time: 5.0438
fsync time: 5.0300
fsync time: 0.0231
fsync time: 0.0243
fsync time: 5.0382
fsync time: 5.0400
[... goes on like this ...]

Это 5 секунд, а не миллисекунды. Это даже создает задержки ввода-вывода на другой виртуальной машине, работающей на том же хосте и хранилище данных :

root@grml /mnt/sda/ioping-0.5 # ./ioping -i 0.3 -p 20 .
4096 bytes from . (reiserfs /dev/sda): request=1 time=7.2 ms
4096 bytes from . (reiserfs /dev/sda): request=2 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=3 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=4 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=5 time=4809.0 ms
4096 bytes from . (reiserfs /dev/sda): request=6 time=1.0 ms
4096 bytes from . (reiserfs /dev/sda): request=7 time=1.2 ms
4096 bytes from . (reiserfs /dev/sda): request=8 time=1.1 ms
4096 bytes from . (reiserfs /dev/sda): request=9 time=1.3 ms
4096 bytes from . (reiserfs /dev/sda): request=10 time=1.2 ms
4096 bytes from . (reiserfs /dev/sda): request=11 time=1.0 ms
4096 bytes from . (reiserfs /dev/sda): request=12 time=4950.0 ms

Когда я перемещаю первую виртуальную машину в локальное хранилище, она выглядит совершенно нормально:

root@dynip211 /mnt/sda # ./fsync-tester
fsync time: 0.0191
fsync time: 0.0201
fsync time: 0.0203
fsync time: 0.0206
fsync time: 0.0192
fsync time: 0.0231
fsync time: 0.0201
[... tried that for one hour: no spike ...]

То, что я пробовал, не имело значения:

  • Протестировано несколько сборок ESXi: 381591, 348481, 260247
  • Протестировано на другом оборудовании, на разных блоках Intel и AMD
  • Протестировано на разных серверах NFS, все показывают одинаковое поведение:
    • OpenIndiana b147 (синхронизация ZFS всегда или отключена: без разницы)
    • OpenIndiana b148 (синхронизация ZFS всегда или отключена: без разницы)
    • Linux 2.6.32 (синхронизация или асинхронность: без разницы)
    • Не имеет значения, находится ли сервер NFS на том же компьютере (в качестве устройства виртуального хранилища) или на другом хосте.

Гостевая ОС проверена, показывает проблемы:

  • 64-разрядная версия Windows 7 (при использовании CrystalDiskMark всплески задержки происходят в основном на этапе подготовки)
  • Linux 2.6.32 (fsync-tester + ioping)
  • Linux 2.6.38 (fsync-tester + ioping)

Я не мог воспроизвести эту проблему на виртуальных машинах Linux 2.6.18.

Другим обходным решением является использование виртуальных дисков IDE (по сравнению с SCSI / SAS), но это ограничивает производительность и количество дисков на виртуальную машину.

Обновление 2011-06-30:

Пики задержек, по-видимому, происходят чаще, если приложение выполняет запись в несколько небольших блоков перед fsync. Например, fsync-tester делает это (прямой вывод):

pwrite(3, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 1048576, 0) = 1048576
fsync(3)                                = 0

ioping делает это при подготовке файла:

[lots of pwrites]
pwrite(3, "********************************"..., 4096, 1036288) = 4096
pwrite(3, "********************************"..., 4096, 1040384) = 4096
pwrite(3, "********************************"..., 4096, 1044480) = 4096
fsync(3)                                = 0

Фаза настройки ioping почти всегда зависает, в то время как fsync-tester иногда работает нормально. Может ли кто-то обновить fsync-tester для записи нескольких небольших блоков? Мои навыки С сосать;)

Обновление 2011-07-02:

Эта проблема не возникает с iSCSI. Я попробовал это с сервером OpenIndiana COMSTAR iSCSI. Но iSCSI не дает вам легкого доступа к файлам VMDK, поэтому вы можете перемещать их между хостами с помощью моментальных снимков и rsync.

Обновление 2011-07-06:

Это часть захвата wireshark, захваченного третьей виртуальной машиной на том же vSwitch. Все это происходит на одном хосте, без физической сети.

Я начал драться около 20 минут. Пакеты не отправлялись, пока не закончилась пятисекундная задержка:

No.  Time        Source                Destination           Protocol Info
1082 16.164096   192.168.250.10        192.168.250.20        NFS      V3 WRITE Call (Reply In 1085), FH:0x3eb56466 Offset:0 Len:84 FILE_SYNC
1083 16.164112   192.168.250.10        192.168.250.20        NFS      V3 WRITE Call (Reply In 1086), FH:0x3eb56f66 Offset:0 Len:84 FILE_SYNC
1084 16.166060   192.168.250.20        192.168.250.10        TCP      nfs > iclcnet-locate [ACK] Seq=445 Ack=1057 Win=32806 Len=0 TSV=432016 TSER=769110
1085 16.167678   192.168.250.20        192.168.250.10        NFS      V3 WRITE Reply (Call In 1082) Len:84 FILE_SYNC
1086 16.168280   192.168.250.20        192.168.250.10        NFS      V3 WRITE Reply (Call In 1083) Len:84 FILE_SYNC
1087 16.168417   192.168.250.10        192.168.250.20        TCP      iclcnet-locate > nfs [ACK] Seq=1057 Ack=773 Win=4163 Len=0 TSV=769110 TSER=432016
1088 23.163028   192.168.250.10        192.168.250.20        NFS      V3 GETATTR Call (Reply In 1089), FH:0x0bb04963
1089 23.164541   192.168.250.20        192.168.250.10        NFS      V3 GETATTR Reply (Call In 1088)  Directory mode:0777 uid:0 gid:0
1090 23.274252   192.168.250.10        192.168.250.20        TCP      iclcnet-locate > nfs [ACK] Seq=1185 Ack=889 Win=4163 Len=0 TSV=769821 TSER=432716
1091 24.924188   192.168.250.10        192.168.250.20        RPC      Continuation
1092 24.924210   192.168.250.10        192.168.250.20        RPC      Continuation
1093 24.924216   192.168.250.10        192.168.250.20        RPC      Continuation
1094 24.924225   192.168.250.10        192.168.250.20        RPC      Continuation
1095 24.924555   192.168.250.20        192.168.250.10        TCP      nfs > iclcnet_svinfo [ACK] Seq=6893 Ack=1118613 Win=32625 Len=0 TSV=432892 TSER=769986
1096 24.924626   192.168.250.10        192.168.250.20        RPC      Continuation
1097 24.924635   192.168.250.10        192.168.250.20        RPC      Continuation
1098 24.924643   192.168.250.10        192.168.250.20        RPC      Continuation
1099 24.924649   192.168.250.10        192.168.250.20        RPC      Continuation
1100 24.924653   192.168.250.10        192.168.250.20        RPC      Continuation

2-е обновление 2011-07-06:

Кажется, есть некоторое влияние от размеров окна TCP. Я не смог воспроизвести эту проблему, используя FreeNAS (на основе FreeBSD) в качестве сервера NFS. Захваты Wireshark показали регулярные обновления окна TCP до 29127 байт. Я не видел их с OpenIndiana, которая по умолчанию использует окна большего размера.

Я больше не могу воспроизвести эту проблему, если я установил следующие параметры в OpenIndiana и перезапустил сервер NFS:

ndd -set /dev/tcp tcp_recv_hiwat 8192 # default is 128000
ndd -set /dev/tcp tcp_max_buf 1048575 # default is 1048576

Но это убивает производительность: запись из / dev / zero в файл с dd_rescue идет со 170 МБ / с до 80 МБ / с.

Обновление 2011-07-07:

Я загрузил этот захват tcpdump (можно проанализировать с помощью wireshark). В этом случае 192.168.250.2 является сервером NFS (OpenIndiana b148), а 192.168.250.10 является хостом ESXi.

Вещи, которые я проверял во время этого захвата:

Начал "ioping -w 5 -i 0.2." в момент 30, 5 секунд зависания в настройке, завершено в момент времени 40.

Начал "ioping -w 5 -i 0.2." во время 60, 5 секунд зависания в настройке, завершено во время 70.

Запустил "fsync-tester" в момент 90, со следующим выводом, остановился в момент 120:

fsync time: 0.0248
fsync time: 5.0197
fsync time: 5.0287
fsync time: 5.0242
fsync time: 5.0225
fsync time: 0.0209

2-е обновление 2011-07-07:

Протестирована другая виртуальная машина NFS-сервера, на этот раз NexentaStor 3.0.5 Community Edition: показывает те же проблемы.

Обновление 2011-07-31:

Я также могу воспроизвести эту проблему на новой сборке ESXi 4.1.0.433742.

vmware-esxi nfs latency exo_cw
источник
12
Я должен сказать, что прошло много времени с тех пор, как совершенно новый пользователь пришел на форум с таким хорошо задокументированным и продуманным вопросом - серьезно, снимаю шляпу перед вами. Это действительно интересно, я тоже не сталкивался с fsync-tester, так что спасибо. Тем не менее, я не уверен, что мне есть что добавить, вы пробовали так много вещей, которые я бы уже сделал - я бы сказал, поговорите с самими VMWare, чтобы быть честными, они очень хороши в этом всерьез о «длинном хвосте» / «не фактическом отключении сервиса». Во всяком случае просто хотел сказать , хорошо сделано на то , что вы сделали до сих пор :)
Chopper3
К сожалению, сайт VMware не позволяет мне связаться с ними: «В настоящее время у вас нет прав активной поддержки»
exo_cw
ах, да, это может быть проблемой, конечно ...
Chopper3
3
5 секундный тайм-аут с NFS звучал знакомо. В Linux NFS есть тайм-аут на 0,7 секунды для RPC, который удваивается после каждого сбоя и тянет мажор после 3 неудач (настройки по умолчанию). 0,7 + 1,4 + 2,8 = 4,9 секунды. Существует множество проблем аутентификации RPC, которые могут вызвать это.
Марк
2
@Ryan: Я загрузил файл захвата. Я также загрузил вывод nfsstat .
exo_cw

Ответы:

5

Эта проблема, кажется, исправлена ​​в ESXi 5. Я успешно протестировал сборку 469512.

exo_cw
источник
3

Спасибо, nfsstat выглядит хорошо. Я рассмотрел захват. Не нашли ничего убедительного, но нашли что-то интересное. Я отфильтровал tcp.time_delta> 5. В каждом экземпляре задержки я обнаружил точное начало вызова RPC. Не все новые вызовы RPC были медленными, но все замедления происходили при точном начале вызова RPC. Кроме того, из перехвата видно, что 192.168.250.10 содержит всю задержку. 192.168.250.2 немедленно отвечает на все запросы.

Выводы:

  • Задержки всегда происходят в первом пакете вызова RPC
  • Типы команд NFS не были связаны с задержками
  • Фрагментация = задерживает только первый пакет

Большой вызов записи может разбиваться на 300 отдельных TCP-пакетов, и только первый задерживается, но все остальные проходят. Никогда не происходит задержки в середине. Я не уверен, как размер окна мог так сильно повлиять на начало соединения.

Следующие шаги: я бы начал настраивать параметры NFS, такие как NFSSVC_MAXBLKSIZE, вниз, а не в окне TCP. Также я заметил, что 2.6.18 работает, а 2.6.38 - нет. Я знаю, что поддержка была добавлена ​​для драйвера VMXnet3 в течение этого периода. Какие драйверы NIC вы используете на хостах? TCP разгрузка да / нет? Приблизительно в 95 секунд секунда есть более 500 пакетов TCP для одного вызова записи NFS. Все, что отвечает за TCP и разрушение большого PDU, может быть тем, что блокирует.

Райан
источник
Я попытался установить nfs: nfs3_max_transfer_size, nfs: nfs3_max_transfer_size_cots и nfs: nfs3_bsize до 8192: без разницы, те же проблемы. Гости Linux просто используют свои SCSI / SAS-диски, а не NFS - ESXi является NFS-клиентом, поэтому нет проблем с сетевым драйвером на гостевой Linux. На стороне сервера NFS я пробовал виртуальные e1000 и vmxnet3: без разницы. Насколько я знаю, ESXi использует только разгрузку TCP для iSCSI.
exo_cw
Самый большой ? У меня есть причина, по которой настройка окна TCP будет иметь значение ... Моя интуиция говорит мне, что это связано с фрагментацией этих больших PDU через TCP. Что-то в сетевом стеке, которое задыхается от этого. Просто не могу придумать ничего, что соответствовало бы поведению, которое мы наблюдаем. Если размер окна был проблемой, мы должны видеть задержку, ограничивающую пропускную способность в середине большой передачи, а не в начале, но это всегда первый пакет вызова RPC ... сложный.
Райан
2

У меня есть то, что похоже на ту же проблему, используя ESXi4.1U1 и CentOS VM. Хосты - Dell R610s, хранилище - кластер EMC2 Isilon.

Вы случайно не использовали VLANS? Я обнаружил, что использование VLAN на порте VMkernel для хранения привело к «зависаниям» 4000-5000 мс для всего трафика хранилища на VMHost. Однако, если я перемещаю порт VMkernel из VLAN, чтобы он принимал непомеченные пакеты, я не вижу проблемы.

Простая настройка ниже вызовет проблему в моей сети:

1) Установите ESXi 4.1U1 на сервер или рабочую станцию ​​(обе проблемы возникли, когда я пытался)

2) Добавьте порт VMkernel в VLAN.

3) Добавьте хранилище данных NFS (мое находится в той же VLAN, т.е. Isilon получает помеченные пакеты)

4) Установите 2 виртуальные машины CentOS 5.5, одна с ioping.

5) Загрузка виртуальных машин в однопользовательском режиме (т.е. без сети, минимальное количество услуг)

6) Запустите ioping на одной машине, чтобы она записывала на свой виртуальный диск

7) Запустите dd или somesuch на другом компьютере, чтобы записать 100 МБ данных в / tmp или подобное

Чаще всего я вижу, как обе виртуальные машины зависают на 4-5 секунд.

Будьте действительно заинтересованы, чтобы увидеть, видел ли кто-либо подобное.

Ник
источник
Добро пожаловать в сбой сервера! Это старый вопрос. Если ответы не помогают, вам нужно задать новый НОВЫЙ вопрос, нажав кнопку « Задать вопрос» .
user9517 поддерживает GoFundMonica
Да, конечно, я использую VLAN с тегами. Поскольку я использую их повсюду, я даже не думал о них как о потенциальном источнике этой проблемы. Я собираюсь попытаться воспроизвести это на нетегированном порту.
exo_cw
Я также могу воспроизвести эту проблему на портах без тегов, на этом хосте вообще не задействованы виртуальные локальные сети.
exo_cw
Я просто попробовал еще раз и увидел проблему на портах без тегов, это немного реже, может быть, поэтому я пропустил это. Прошу прощения за задницу. Я не вижу проблемы на Win7 64-битной с использованием iometer, плюс, кажется, я могу просматривать диск c: в то время как другие Linux-VMS зависли. Я собираюсь попробовать с CrystalDiskmark
Ник
На самом деле мне было бы интересно увидеть ваши результаты с iometer на win7 x64. Он измеряет задержку, но наивысшая общая цифра, которую я получил, была 300 мс с использованием теста чтения 4k, а не 4000 + мс
Ник,
2

У нас была точно такая же проблема две недели назад. ESX41 U1 и Netapp FAS3170 + хранилища данных NFS. Виртуальные машины RHEL5 зависают в течение 2 или 4 секунд, и мы увидели очень высокие пики с консоли производительности Виртуального центра.

Я прошу сетевого парня проверить конфигурацию, и проблема была в коммутаторе cisco. У нас есть два канала Ethernet, которые были настроены на Etherchannel на стороне Netapp, а не на стороне cisco. Он создает статический Ethechannel на Cisco и теперь он работает нормально. Чтобы определить проблему такого рода, закройте все порты, кроме одного, между фильтром и коммутатором. Оставь в живых только один порт и посмотри, как идут дела.

Во-вторых, мы удалили управление потоком с коммутатора и файлера, потому что мы подозреваем, что он отправляет кадр паузы.

Laurent
источник
1

Как выглядит ваш DNS? Вы /etc/resolv.confправы? Время ожидания по умолчанию составляет 5 секунд.

От man resolv.conf

timeout:n
                 sets the amount of time the  resolver  will  wait  for  a
                 response  from  a  remote name server before retrying the
                 query via a different name server.  Measured in  seconds,
                 the default is RES_TIMEOUT (currently 5, see <resolv.h>).

Попытайтесь добавить timeout:3к вашему, /etc/resolv.confа затем снова запустите ваши тесты fsync.

Джозеф Керн
источник
Я попытался добавить это на сервере NFS (в данном случае OpenIndiana) и на хосте ESXi. К сожалению, это не имеет значения. Я могу решить IP сервера и гостя просто отлично.
exo_cw
Похоже, вы отфильтровали весь трафик, не связанный с потоком nfs, возможно, нам нужно увидеть больше!
Тони Рот
@tony roth: На самом деле это весь трафик в то время. Я проверил это на отдельном vSwitch только с хостом и NFS-сервером.
exo_cw
Можете ли вы сбросить DNS с Wireshark?
Джозеф Керн
@ Джозеф Керн: Я только что снова проанализировал файлы перехвата: во время перехватов вообще не было никакого трафика DNS. Хранилище данных NFS сопоставляется по IP на хосте ESXi. DNS отлично работает на ESXi и NFS-сервере, я проверил прямой и обратный поиск всех задействованных IP-адресов. Сейчас у меня нет оснований полагать, что DNS является причиной этого.
exo_cw
1

Здесь хватается за соломинку, но какие сетевые карты вы используете на этих серверах? У системных администраторов переполнения стека были странные сетевые проблемы с сетевыми картами Broadcom, которые исчезли, когда они переключились на сетевые адаптеры Intel: http://blog.serverfault.com/post/broadcom-die-mutha/

проворный
источник
Последние тесты проводились только на vSwitch, без участия физической сети (e1000 и vmxnet3: без разницы). Но я также проверил это на Intel 82574L, Intel 82576 и Intel 82567LF-3, и все это показало проблему. Я не нашел никакого оборудования, где я не могу воспроизвести это.
exo_cw
1

Вот еще одно предположение ... Ваш IPv6 включен на хосте EXS? Если да, то попробуйте выключить? По моему опыту, если вся ваша сеть не настроена должным образом для IPv6 (то есть RADV, DHCP6, DNS, обратный DNS), это может быть проблемой для некоторых служб. Кроме того, убедитесь, что он выключен на сервере NFS.

dtoubelis
источник
IPv6 уже был отключен на хосте ESXi. Я отключил IPv6 на сервере NFS (ifconfig -a6 сейчас пуст), но это не имеет значения: он показывает те же проблемы.
exo_cw