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

Недавно я разработал и настроил кластер из 4 узлов для веб-приложения, которое выполняет большую часть обработки файлов. Кластер был разделен на две основные роли: веб-сервер и хранилище. Каждая роль реплицируется на второй сервер с использованием 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: Серверы являются физическими серверами, и их спецификации:

• WebServers:

  • Intel Bi Xeon E5606 2x4 2,13 ГГц
  • 24 ГБ DDR3
  • Intel SSD 320 2 х 120 ГБ Raid 1

• Место хранения:

  • Intel i5 3550 3,3 ГГц
  • 16 ГБ DDR3
  • 12 х 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>

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

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

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

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

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

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