☰

Низкая производительность NFS и GFS2

tag-icon • tag-icon web-server storage nfs gfs2
Низкая производительность NFS и GFS2

Недавно я спроектировал и настроил кластер из 4 узлов для веб-приложения, которое выполняет множество операций с файлами. Кластер был разбит на 2 основные роли: веб-сервер и хранилище. Каждая роль реплицируется на второй сервер с помощью drbd в активном/пассивном режиме. Веб-сервер выполняет монтирование NFS каталога данных сервера хранилища, а на последнем также запущен веб-сервер для обслуживания файлов браузерными клиентами.

В серверах хранения я создал GFS2 FS для хранения данных, которые подключены к drbd. Я выбрал GFS2 в основном из-за заявленной производительности, а также из-за размера тома, который должен быть довольно большим.

С тех пор, как мы вошли в производство, я столкнулся с двумя проблемами, которые, как я думаю, тесно связаны. Во-первых, монтирование NFS на веб-серверах зависает примерно на минуту, а затем возобновляет нормальную работу. Анализируя логи, я обнаружил, что NFS на некоторое время перестает отвечать и выводит следующие строки журнала:

Oct 15 18:15:42 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:44 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:46 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:47 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:47 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:47 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:48 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:48 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:51 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:52 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:52 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:55 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:55 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:58 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK

В данном случае зависание длилось 16 секунд, но иногда для возобновления нормальной работы требуется 1-2 минуты.

Моей первой догадкой было то, что это происходит из-за большой нагрузки на монтирование NFS, и что при увеличении RPCNFSDCOUNTдо большего значения это станет стабильным. Я увеличивал его несколько раз, и, по-видимому, через некоторое время логи стали появляться реже. Сейчас значение равно 32.

После дальнейшего изучения проблемы я столкнулся с другим зависанием, несмотря на то, что сообщения NFS все еще появляются в журналах. Иногда GFS2 FS просто зависает, что заставляет и NFS, и веб-сервер хранилища обслуживать файлы. Оба остаются зависшими некоторое время, а затем возобновляют нормальную работу. Это зависание не оставляет следов на стороне клиента (также не оставляет NFS ... not respondingсообщений), а на стороне хранилища система журналов кажется пустой, хотя работает rsyslogd.

Узлы подключаются через невыделенное соединение 10 Гбит/с, но я не думаю, что это проблема, поскольку зависание GFS2 подтверждено, но подключение происходит напрямую к активному серверу хранения.

Я уже некоторое время пытаюсь решить эту проблему и перепробовал разные варианты конфигурации NFS, прежде чем обнаружил, что GFS2 FS также зависает.

Монтирование NFS экспортируется следующим образом:

/srv/data/ <ip_address>(rw,async,no_root_squash,no_all_squash,fsid=25)

А клиент NFS монтируется с помощью:

mount -o "async,hard,intr,wsize=8192,rsize=8192" active.storage.vlan:/srv/data /srv/data

После ряда тестов были выявлены конфигурации, обеспечившие кластеру большую производительность.

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

Пожалуйста, сообщите мне, нужно ли вам предоставить сведения о конфигурации кластера, и какие именно данные вы хотите, чтобы я опубликовал.

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

Серверы размещены на стороннем предприятии, и у меня нет к ним физического доступа.

С наилучшими пожеланиями.

ПРАВКА 1: Серверы представляют собой физические серверы и имеют следующие характеристики:

  • Веб-серверы:

    • Intel Bi Xeon E5606 2x4 2.13GHz
    • 24 ГБ DDR3
    • Intel SSD 320 2 x 120 ГБ Raid 1

  • Хранилище:

    • Intel i5 3550 3.3ГГц
    • 16 ГБ DDR3
    • 12 x 2 ТБ SATA

Первоначально между серверами была установлена ​​VRack, но мы модернизировали один из серверов хранения, чтобы иметь больше оперативной памяти, и он не был внутри VRack. Они подключаются через общее соединение 10 Гбит/с между ними. Обратите внимание, что это то же самое соединение, которое используется для публичного доступа. Они используют один IP (используя IP Failover) для соединения между собой и для обеспечения плавного переключения при отказе.

Таким образом, NFS работает через публичное соединение, а не в какой-либо частной сети (так было до обновления, и проблема все еще существовала).

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

Надеюсь, это поможет разобраться в проблеме.

ПРАВКА 2:

Соответствующие версии программного обеспечения:

CentOS 2.6.32-279.9.1.el6.x86_64  
nfs-utils-1.2.3-26.el6.x86_64  
nfs-utils-lib-1.1.5-4.el6.x86_64  
gfs2-utils-3.0.12.1-32.el6_3.1.x86_64  
kmod-drbd84-8.4.2-1.el6_3.elrepo.x86_64  
drbd84-utils-8.4.2-1.el6.elrepo.x86_64

Конфигурация DRBD на серверах хранения:

#/etc/drbd.d/storage.res
resource storage {
    protocol C;

    on <server1 fqdn> {
            device /dev/drbd0;
            disk /dev/vg_storage/LV_replicated;
            address <server1 ip>:7788;
            meta-disk internal;
    }

    on <server2 fqdn> {
            device /dev/drbd0;
            disk /dev/vg_storage/LV_replicated;
            address <server2 ip>:7788;
            meta-disk internal;
    }
}

Конфигурация NFS на серверах хранения данных:

#/etc/sysconfig/nfs
RPCNFSDCOUNT=32
STATD_PORT=10002
STATD_OUTGOING_PORT=10003
MOUNTD_PORT=10004
RQUOTAD_PORT=10005
LOCKD_UDPPORT=30001
LOCKD_TCPPORT=30001

(может ли возникнуть конфликт при использовании одного и того же порта для LOCKD_UDPPORTи LOCKD_TCPPORT?)

Конфигурация GFS2:

# gfs2_tool gettune <mountpoint>
incore_log_blocks = 1024
log_flush_secs = 60
quota_warn_period = 10
quota_quantum = 60
max_readahead = 262144
complain_secs = 10
statfs_slow = 0
quota_simul_sync = 64
statfs_quantum = 30
quota_scale = 1.0000   (1, 1)
new_files_jdata = 0

Среда сети хранения данных:

eth0      Link encap:Ethernet  HWaddr <mac address>
          inet addr:<ip address>  Bcast:<bcast address>  Mask:<ip mask>
          inet6 addr: <ip address> Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:957025127 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1473338731 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2630984979622 (2.3 TiB)  TX bytes:1648430431523 (1.4 TiB)

eth0:0    Link encap:Ethernet  HWaddr <mac address>  
          inet addr:<ip failover address>  Bcast:<bcast address>  Mask:<ip mask>
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

IP-адреса назначаются статически с заданными сетевыми конфигурациями:

DEVICE="eth0"
BOOTPROTO="static"
HWADDR=<mac address>
ONBOOT="yes"
TYPE="Ethernet"
IPADDR=<ip address>
NETMASK=<net mask>

и

DEVICE="eth0:0"
BOOTPROTO="static"
HWADDR=<mac address>
IPADDR=<ip failover>
NETMASK=<net mask>
ONBOOT="yes"
BROADCAST=<bcast address>

Файл Hosts, обеспечивающий плавное переключение на резервный ресурс NFS в сочетании с параметром NFS, fsid=25установленным на обоих серверах хранения:

#/etc/hosts
<storage ip failover address> active.storage.vlan
<webserver ip failover address> active.service.vlan

Как видите, количество ошибок пакетов снизилось до 0. Я также долгое время запускал ping без потери пакетов. Размер MTU — обычный 1500. Поскольку VLan пока нет, этот MTU используется для связи между серверами.

Сетевая среда веб-серверов аналогична.

Я забыл упомянуть, что серверы хранения обрабатывают около 200 ГБ новых файлов каждый день через соединение NFS, и это ключевой момент, позволяющий мне предположить, что это какая-то проблема с большой нагрузкой либо с NFS, либо с GFS2.

Если вам нужны дополнительные подробности конфигурации, пожалуйста, сообщите мне.

ПРАВКА 3:

Ранее сегодня у нас произошел крупный сбой файловой системы на сервере хранения. Я не смог получить подробности сбоя сразу, потому что сервер перестал отвечать. После перезагрузки я заметил, что файловая система работала крайне медленно, и я не мог обслужить ни один файл ни через NFS, ни через httpd, возможно, из-за разогрева кэша или чего-то в этом роде. Тем не менее, я внимательно следил за сервером, и в dmesg. Источником проблемы, очевидно, является GFS, которая ждет lockи через некоторое время оказывается в состоянии голодания.

INFO: task nfsd:3029 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
nfsd          D 0000000000000000     0  3029      2 0x00000080
 ffff8803814f79e0 0000000000000046 0000000000000000 ffffffff8109213f
 ffff880434c5e148 ffff880624508d88 ffff8803814f7960 ffffffffa037253f
 ffff8803815c1098 ffff8803814f7fd8 000000000000fb88 ffff8803815c1098
Call Trace:
 [<ffffffff8109213f>] ? wake_up_bit+0x2f/0x40
 [<ffffffffa037253f>] ? gfs2_holder_wake+0x1f/0x30 [gfs2]
 [<ffffffff814ff42e>] __mutex_lock_slowpath+0x13e/0x180
 [<ffffffff814ff2cb>] mutex_lock+0x2b/0x50
 [<ffffffffa0379f21>] gfs2_log_reserve+0x51/0x190 [gfs2]
 [<ffffffffa0390da2>] gfs2_trans_begin+0x112/0x1d0 [gfs2]
 [<ffffffffa0369b05>] ? gfs2_dir_check+0x35/0xe0 [gfs2]
 [<ffffffffa0377943>] gfs2_createi+0x1a3/0xaa0 [gfs2]
 [<ffffffff8121aab1>] ? avc_has_perm+0x71/0x90
 [<ffffffffa0383d1e>] gfs2_create+0x7e/0x1a0 [gfs2]
 [<ffffffffa037783f>] ? gfs2_createi+0x9f/0xaa0 [gfs2]
 [<ffffffff81188cf4>] vfs_create+0xb4/0xe0
 [<ffffffffa04217d6>] nfsd_create_v3+0x366/0x4c0 [nfsd]
 [<ffffffffa0429703>] nfsd3_proc_create+0x123/0x1b0 [nfsd]
 [<ffffffffa041a43e>] nfsd_dispatch+0xfe/0x240 [nfsd]
 [<ffffffffa025a5d4>] svc_process_common+0x344/0x640 [sunrpc]
 [<ffffffff810602a0>] ? default_wake_function+0x0/0x20
 [<ffffffffa025ac10>] svc_process+0x110/0x160 [sunrpc]
 [<ffffffffa041ab62>] nfsd+0xc2/0x160 [nfsd]
 [<ffffffffa041aaa0>] ? nfsd+0x0/0x160 [nfsd]
 [<ffffffff81091de6>] kthread+0x96/0xa0
 [<ffffffff8100c14a>] child_rip+0xa/0x20
 [<ffffffff81091d50>] ? kthread+0x0/0xa0
 [<ffffffff8100c140>] ? child_rip+0x0/0x20

ПРАВКА 4:

Я установил munin и получил некоторые новые данные. Сегодня снова произошло зависание, и munin показывает мне следующее: размер таблицы инодов достигает 80k непосредственно перед зависанием, а затем внезапно падает до 10k. Как и в случае с памятью, кэшированные данные также внезапно падают с 7 ГБ до 500 МБ. Средняя нагрузка также резко возрастает во время зависания, а использование устройства drbdтакже резко возрастает до значений около 90%.

По сравнению с предыдущим зависанием, эти два индикатора ведут себя одинаково. Может ли это быть связано с плохим управлением файлами на стороне приложения, которое не освобождает обработчики файлов, или, возможно, с проблемами управления памятью, исходящими от GFS2 или NFS (в чем я сомневаюсь)?

Спасибо за любые возможные отзывы.

ПРАВКА 5:

Использование таблицы инодов от Munin:

Использование памяти от Munin:

решение1

Я могу дать лишь некоторые общие указания.

Сначала я бы запустил несколько простых контрольных показателей. По крайней мере, тогда вы будете знать, к лучшему ли идут ваши изменения.

  • Мунин
  • Кактусы

  • Нагиос

    есть несколько хороших вариантов.

Являются ли эти узлы виртуальными или физическими серверами, каковы их характеристики?

Какой тип сетевого соединения существует между каждым узлом?

Настроен ли NFS поверх частной сети вашего хостинг-провайдера?

Вы не ограничиваете пакеты/порты с помощью брандмауэров. Делает ли это ваш хостинг-провайдер?

решение2

Я думаю, у вас две проблемы. Узкое место, вызывающее проблему в первую очередь, и, что более важно, плохая обработка сбоев GFS. GFS действительно должен замедлять передачу, пока она не заработает, но я не могу помочь с этим.

Вы говорите, что кластер обрабатывает ~200 ГБ новых файлов в NFS. Сколько данных считывается из кластера?

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

Если вы установите iperf на каждом из ящиков, вы сможете протестировать доступную пропускную способность сети в любой заданной точке. Это может быть быстрым способом определения наличия узкого места в сети.

Насколько интенсивно используется сеть? Насколько быстры диски на сервере хранения и какую конфигурацию RAID вы используете? Какую пропускную способность вы получаете на нем? Предполагая, что он работает под управлением *nix и у вас есть тихий момент для тестирования, вы можете использовать hdparm

$ hdpard -tT /dev/<device>

Если вы обнаружили высокую загрузку сети, я бы рекомендовал разместить GFS на вторичном и выделенном сетевом подключении.

В зависимости от того, как вы сделали raid(ed) на 12 дисках, вы можете иметь разную степень производительности, и это может быть вторым узким местом. Это также будет зависеть от того, используете ли вы аппаратный raid или программный raid.

Обильные объемы памяти, которые у вас есть на коробке, могут быть бесполезны, если запрашиваемые данные распределены по объему, превышающему общую память, что, похоже, и может быть. Кроме того, память может помочь только с чтениями, и то в основном, если многие чтения относятся к одному и тому же файлу (иначе он будет выброшен из кэша).

При запуске top / htop следите за iowait. Высокое значение здесь — отличный показатель того, что процессор просто вертит пальцами в ожидании чего-то (сети, диска и т. д.)

По моему мнению, NFS вряд ли является виновником. У нас достаточно большой опыт работы с NFS, и хотя его можно настроить/оптимизировать, онимеет тенденциюработать достаточно надежно.

Я бы склонился к тому, чтобы стабилизировать компонент GFS, а затем посмотреть, исчезнут ли проблемы с NFS.

Наконец, OCFS2 может быть вариантом для рассмотрения в качестве замены GFS. Пока я проводил некоторые исследования для распределенных файловых систем, я провел достаточно много исследований и не могу вспомнить причины, по которым я решил попробовать OCFS2, но я это сделал. Возможно, это было как-то связано с тем, что OCFS2 используется Oracle для своих бэкэндов баз данных, что подразумевает довольно высокие требования к стабильности.

Munin — ваш друг. Но гораздо важнее top / htop. vmstat также может дать вам некоторые ключевые цифры

$ vmstat 1

и вы будете каждую секунду получать обновленную информацию о том, на что именно тратит свое время система.

Удачи!

решение3

Первый HA-прокси перед веб-серверами с Varnish или Nginx.

Затем для файловой системы веб: почему бы не использовать MooseFS вместо NFS, GFS2, он отказоустойчив и быстр для чтения. То, что вы теряете от NFS, GFS2, это локальные блокировки, нужны ли они вам для вашего приложения? Если нет, я бы переключился на MooseFS и пропустил проблемы NFS, GFS2. Вам нужно будет использовать Ucarp для обеспечения высокой доступности серверов метаданных MFS.

В MFS установите цель репликации на 3

# mfssetgoal 3 /папка

//Христианин

решение4

На основании ваших графиков munin можно сделать вывод, что система сбрасывает кэши, это эквивалентно запуску одного из следующих действий:

  1. echo 2 > /proc/sys/vm/drop_caches
    1. бесплатные дентри и иноды
  2. echo 3 > /proc/sys/vm/drop_caches
    1. бесплатный кэш страниц, дентиры и иноды

Возникает вопрос: может быть, есть какая-то затянувшаяся задача cron?

За исключением 01:00 -> 12:00, они, по-видимому, следуют с регулярным интервалом.

Также стоит проверить примерно половину пути через пик, если выполнение одной из вышеуказанных команд воссоздает вашу проблему, однаковсегдаsyncпрежде чем сделать это, убедитесь, что вы поворачиваете направо.

Невыполнение этого straceпроцесса DRBD (опять же, если это является причиной) примерно во время ожидаемой чистки и вплоть до самой чистки может пролить свет.

Связанный контент