Усунення стрибків затримки у сховищах даних ESXi NFS

У мене спостерігаються затримки у стислі синхронізації - близько п'яти секунд у сховищах даних NFS в ESXi, ініційованих певними віртуальними машинами. Я підозрюю, що це може бути викликано віртуальними машинами, що використовують NCQ / TCQ, оскільки цього не відбувається з віртуальними накопичувачами IDE.

Це можна відтворити за допомогою fsync-tester (від Теда Ц'о ) та іопінгу . Наприклад, використання живої системи 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 секунд, а не мілісекунд. Це навіть створює затримки вводу-виводу на інший VM, що працює на одному хості та сховищі даних :

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

Коли я переміщую перший VM в локальне сховище, це виглядає абсолютно нормально:

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 знаходиться на одній машині (як пристрій віртуального зберігання) або на іншому хості

Тестування гостьової ОС показало проблеми:

• Windows 7 64 біт (використовуючи CrystalDiskMark, сплески затримки трапляються здебільшого під час підготовки)
• Linux 2.6.32 (fsync-тестер + іопінг)
• Linux 2.6.38 (fsync-тестер + іопінг)

Я не міг відтворити цю проблему на версіях 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

Фаза налаштування іопінгу майже завжди висить, тоді як fsync-тестер іноді працює добре. Хтось здатний оновити fsync-тестер для написання декількох маленьких блоків? Мої навички C смоктати;)

Оновлення 2011-07-02:

Ця проблема не виникає при iSCSI. Я спробував це з сервером OpenIndiana COMSTAR iSCSI. Але iSCSI не надає вам легкого доступу до файлів VMDK, тому ви можете переміщати їх між хостами за допомогою знімків та rsync.

Оновлення 2011-07-06:

Це частина захоплення проводів акумулятора, захоплена третьою машиною управління на тому ж 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. Захоплення проводів показувало оновлення вікон 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 переходить від 170MB / s до 80MB / s.

Оновлення 2011-07-07:

Я завантажив це захоплення tcpdump (можна проаналізувати за допомогою дроту). У цьому випадку 192.168.250.2 - сервер NFS (OpenIndiana b148), а 192.168.250.10 - хост ESXi.

Те, що я перевірив під час цього захоплення:

Почав "іопінг -w 5 -i 0,2". на час 30, 5 секунд зависають у налаштуваннях, завершено в час 40.

Почав "іопінг -w 5 -i 0,2". на час 60, 5 секунд висіть у налаштуваннях, завершено в час 70.

Почався "fsync-тестер" у 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:

Перевірено інший сервер VM сервера NFS, на цей раз видання спільноти NexentaStor 3.0.5: Показує ті самі проблеми.

Оновлення 2011-07-31:

Я також можу відтворити цю проблему на новій збірці ESXi 4.1.0.433742.

Здається, ця проблема виправлена ​​в ESXi 5. Я перевірив збірку 469512 з успіхом.

Дякую, 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 Write. Що б не було відповідальним за TCP та розбиття великого PDU, це може бути тим, що блокує.

У мене є те, що схоже на ту саму проблему з використанням 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 ВМ, один з іопінг.

5) Завантажте VM в єдиний користувальницький режим (тобто відсутність мережі, мінімальні послуги)

6) Запустіть іопінг на одній машині, щоб записати його на віртуальний диск

7) Запустіть dd або щось на іншому пристрої, щоб записати 100MB даних в / tmp або подібне

Найчастіше я бачу замерзання обох VM протягом 4-5 секунд.

Будьте дуже зацікавлені, щоб хтось ще бачив подібне.

Ми мали саме таку ж проблему два тижні тому. ESX41 U1 і Netapp FAS3170 + сховища даних NFS. Відеомагнітофони RHEL5 висять на 2 або 4 секунди, і ми побачили дуже високі шипи на консолі продуктивності Virtual Center.

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

Друге, що ми робимо, це було зняти Контроль потоку на switchcj і файлері, тому що ми підозрюємо, що він надсилає кадр паузи.

Як виглядає ваш 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.

Обираючись за соломинки тут, але які NIC ви використовуєте на цих серверах? Систематизатори переповнення стека мали дивні проблеми з мережею з NIC-кодами Broadcom, які відійшли, коли вони перейшли на Intel NIC: http://blog.serverfault.com/post/broadcom-die-mutha/

Ось ще одна здогадка ... Чи увімкнено ваш IPv6 на хості EXS? Якщо так, то спробуйте вимкнути його? З мого досвіду, якщо вся ваша мережа не налаштована належним чином для IPv6 (тобто RADV, DHCP6, DNS, зворотний DNS), це може бути проблемою для деяких служб. Також переконайтеся, що він вимкнено на сервері NFS.