Настройка стека клиент / сервер NFS

У меня есть сервер CentOS 5 VMWare, подключающийся к машине OpenSolaris 2009.06 через NFS, которая содержит образы дисков. Кажется, мои виртуальные машины связаны медленным вводом-выводом, поэтому я бы хотел сделать все возможное, чтобы оптимизировать соединение.

Я не уверен в лучшем способе измерения пропускной способности в производственной системе, но некоторые ненаучные тесты, использующие записи dd bs=1024k count=400show local (OpenSolaris) о ~ 1.6 ГБ / с и удаленные (CentOS) записи ~ 50 МБ / с. Я полагаю, что они ниже, чем то, что я на самом деле получаю, поскольку 7 виртуальных машин в настоящее время работают через соединение.

В настоящее время эти 2 компьютера являются gigE с прямым подключением, а на обеих сетевых картах включены Jumbo-кадры (MTU = 9000). Кроме этого, никаких оптимизаций не было сделано. NFS mount / export использует значения по умолчанию.

С чего мне начать поворачивать ручки для повышения производительности?

Просто чтобы уточнить, вы получаете 50 МБ / с с NFS через одно соединение Gb Ethernet?

И на хост-сервере установлен CentOS с установленным VMware Server, который, в свою очередь, работает на 7 виртуальных машинах? Есть ли какая-то особая причина, по которой вы решили использовать CentOS и VMware Server вместе, а не VMware ESXi, который является решением с более высокой производительностью?

Скорость 50 МБ / с невелика, но она не намного ниже, чем можно было бы ожидать от одного сетевого кабеля Gb - после того, как вы добавили твики NFS, о которых упоминали выше, вы увидите 70- 80MB / сек. Варианты по линии:

"ро, жесткий, INTR, Retrans = 2, rsize = 32768, wsize = 32768, nfsvers = 3, TCP"

вероятно, разумны для вас на обоих концах системы.

Чтобы достичь этого, нужно объединить сетевые карты в пары, что должно увеличить пропускную способность примерно на 90%. Вам может потребоваться коммутатор, поддерживающий 802.3ad, чтобы получить лучшую производительность с агрегацией каналов .

Однако я хотел бы предложить одну вещь: ваша пропускная способность ввода-вывода на коробке OpenSolaris кажется подозрительно высокой, 12 дисков вряд ли будут поддерживать пропускную способность 1,6 ГБ / с, и это может быть сильно кэшировано Solaris + ZFS.

Для наших машин RHEL / CentOS 5 мы используем следующие флаги монтирования

nfsvers = 3, TCP, Timeo = 600, Retrans = 2, rsize = 32768, wsize = 32768, жесткий, INTR, noatime

Более новая версия ядра Linux поддерживает еще более широкие параметры rsize / wsize, но 32k - максимум для ядра 2.6.18 в EL5.

На серверах NFS, по крайней мере, для Linux no_wdelay предположительно помогает, если у вас есть контроллер диска с BBWC. Кроме того, если вы используете флаг noatime на клиентах, возможно, имеет смысл также смонтировать файловые системы на серверах с noatime.

И, как уже упоминалось, не беспокойтесь о UDP. В высокоскоростных сетях (1GbE +) существует небольшая, но ненулевая вероятность того, что изменение порядкового номера приведет к повреждению данных. Также, если есть вероятность потери пакетов, TCP будет работать лучше, чем UDP.

Если вас не очень беспокоит целостность данных, опция экспорта «async» может значительно повысить производительность (проблема с асинхронностью заключается в том, что вы можете потерять данные в случае сбоя сервера).

Кроме того, по крайней мере для сервера Linux, вы должны убедиться, что у вас достаточно потоков сервера NFS. Значение по умолчанию 8 слишком низкое.

Однажды я провел тест с Dell R710, 1 ЦП, 4 ГБ ОЗУ, 6 дисков SATA с RAID-10. Клиент был sun x2100, как с CentOS 5.3, так и с параметрами nfs, как упомянуто выше.

"ро, жесткий, INTR, Retrans = 2, rsize = 32768, wsize = 32768, nfsvers = 3, TCP"

крепится с обеих сторон с помощью noatime.

Я также увеличил nfsds до 256 и использовал планировщик noop для rac-контроллера perc6. Еще я хотел выровнять разделы по размеру полосы 64K контроллера рейда.

затем я измерил производительность nfs с помощью dd - для операций чтения я мог заполнить канал gigE, но для операций записи я мог получить лишь чуть лучшие результаты, чем вы. С включенной асинхронностью я мог получить от 70 до 80 МБ / с, но асинхронность не была для меня опцией

Может быть, вы не можете получить больше с NFS по ссылке GIGE?

Попробуйте это: временно отключите журнал ZFS Intent Log (ZIL) на сервере NFS OpenSolaris, выполнив следующие два шага

1. echo zil_disable/W0t1 | mdb -kw
2. заново смонтировать тестовый раздел

Затем проверьте снова. Вы можете использовать zilstat, чтобы убедиться, что в ZIL больше нет ввода-вывода. Если тест выполняется быстрее, вы знаете, что проблема с производительностью связана с ZIL. Если он все еще работает медленно, вы знаете, что ZIL не является виновником, и что использование SSD для ZIL также не поможет. См. ZFS Evil Tuning Guide для получения дополнительной информации о ZIL.

Другой вариант - захватить сетевой трафик (например, с помощью Wireshark) и посмотреть, есть ли какие-либо проблемы, например, с кадрами Jumbo. Убедитесь, что пакеты в сети выглядят так, как вы ожидаете от своей конфигурации. Происходит ли плохая фрагментация? Есть ретрансляторы?

Может помочь увеличение размеров чтения и записи. Особенно в сочетании с гигантскими кадрами.

Я стремлюсь найти 32k, чтобы быть оптимальным.

rsize=32768,wsize=32768

Переключение на транспорт UDP, конечно, быстрее, чем TCP, потому что это экономит накладные расходы на управление передачей. Но это применимо только в надежных сетях, где NFSv4 не используется.

Производительность NFS в ZFS значительно улучшена благодаря использованию SSD для журнала намерений ZFS (ZIL), поскольку это уменьшает задержку операций. Эта ветка о VMWare NFS о производительности ZFS в списках рассылки OpenSolaris NFS и ZFS содержит дополнительную информацию, в том числе инструмент для оценки производительности узкого места.

К вашему сведению, команда dd будет записывать в кеш, а не на диск, поэтому вы можете получить сумасшедшие цифры, такие как 1.6G / s, потому что вы пишете в ОЗУ, а не на диск в Solaris, вы можете использовать «-oflag = sync» для принудительной записи на диск