Назад | Перейти на главную страницу

Медленная производительность 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,13 ГГц
- 24 ГБ DDR3
- Intel SSD 320 2 x 120 ГБ Raid 1
Место хранения:
- Intel i5 3550 3,3 ГГц
- 16 ГБ DDR3
- 12 портов SATA емкостью 2 ТБ

Первоначально между серверами была установка 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 показывает мне следующее: размер таблицы inode достигает 80 КБ непосредственно перед зависанием, а затем внезапно падает до 10 КБ. Как и в случае с памятью, объем кэшированных данных также внезапно падает с 7 ГБ до 500 МБ. Средняя нагрузка также резко возрастает во время зависания и использования устройства. drbd устройство также подскакивает до значений около 90%.

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

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

РЕДАКТИРОВАТЬ 5:

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

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

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

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

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

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

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

$ hdpard -tT /dev/<device>

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

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

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

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

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

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

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

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

$ vmstat 1

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

Удачи!

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

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

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

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

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

Какие сетевые соединения существуют между каждым узлом

Настраивается ли NFS через частную сеть вашего хостинг-провайдера.

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

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

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

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

Если не считать 01:00 -> 12:00, они кажутся регулярными.

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

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

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

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

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

# mfssetgoal 3 / папка

// христианин