Case Study об использовании подсистемы Linux FS-Cache

Case Study об использовании подсистемы Linux FS-Cache для решения проблемы производительности хранилища


У одного из наших клиентов большой портал, данные которого хранятся на отдельном выделенном NFS сервере. На сегодняшний день — это множество изображений, которые хранятся в одном плоском каталоге и занимают более 3 TB. Даже листинг этого каталога занимает несколько десятков секунд. До недавнего времени все работало более-менее неплохо, но потом движок обновили и случилось чудо, нагрузка на хранилище выросла на порядок. Все наши увещевания, что было хорошо, стало плохо ни к чему не привели, разработчики просто разводят руками.

Одна из самых больших проблем — это плоская структура каталога, в котором хранятся все файлы, таким образом, операции, которым нужен листинг просто превращают хранилище в тыкву и 4x2TB RAID10 никак не справляются. На периоды пиковой нагрузки мы переносили данные клиенты на наше SSD-хранилище, чтобы преодолеть проблему.

Новый виток боли начался недавно — у клиента стало заканчиваться место в хранилище, мы выполнили перенос на временный сервер, но проблема усугубилась — после перемонтирования хранилища NFS IOPS-ы стали зашкаливать, так как сервер приложений выкачивал все данные непосредственно с хранилища, и система просто встала колом. К счастью, на сервере приложений было около 500 GB высокоскоростного пространства на SSD и мы решили попробовать использовать FS-Cache для решения проблемы. Это был первый опыт применения данной технологии, но делать было нечего, все равно ничего не работало.

Проверяем совместимость ядра

# grep CONFIG_NFS_FSCACHE /boot/config-3.13.0-147-generic
CONFIG_NFS_FSCACHE=y

Отлично, ядро пересобирать не надо.

Монтируем NFS с нужным параметром FSC

server://files /mnt/vgslow-data nfs nfsvers=4,async,rw,_netdev,fsc 0 0

Обращаем внимание. Перемонтирование через remount не даст эффекта. Необходимо отмонтировать и смонтировать с параметром «fsc».

Устанавливаем и настраиваем демон кэширования

apt-get install cachefilesd
Редактируем настройки
# cat /etc/cachefilesd.conf 
###############################################################################
#
# Copyright © 2006,2010 Red Hat, Inc. All Rights Reserved.
# Written by David Howells (dhowells@redhat.com)
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version
# 2 of the License, or (at your option) any later version.
#
###############################################################################

dir /var/cache/fscache
tag mycache
brun 10%
bcull 7%
bstop 3%
frun 10%
fcull 7%
fstop 3%

# Assuming you're using SELinux with the default security policy included in
# this package
# secctx system_u:system_r:cachefiles_kernel_t:s0

В настройках мы изменили только параметр dir. Остальные параметры оставлены по умолчанию. Демон умеет определять доступное место на диске и держать его на заданных уровнях.

Указываем, что демон должен запускаться:

# cat /etc/default/cac
cacerts cachefilesd 
root@np0121:~# cat /etc/default/cachefilesd 
# Defaults for cachefilesd initscript
# sourced by /etc/init.d/cachefilesd

# You must uncomment the run=yes line below for cachefilesd to start.
# Before doing so, please read /usr/share/doc/cachefilesd/howto.txt.gz as
# extended user attributes need to be enabled on the cache filesystem.
RUN=yes

# Additional options that are passed to the Daemon.
DAEMON_OPTS=""

Запускаем сервис

service cachefilesd start

Проверяем работоспособность

# cat /proc/fs/nfsfs/volumes
NV SERVER   PORT DEV  FSID             FSC
v4 b078194a 801  0:35 16f9381700e59eda yes

Важно, чтобы в колонке FSC было yes. Это означает, что кэширование активировалось.

Теперь смотрим статистику кэша:

# cat /proc/fs/fscache/stats
FS-Cache statistics
Cookies: idx=6 dat=1890275 spc=0
Objects: alc=1097490 nal=0 avl=1097490 ded=1016804
ChkAux : non=0 ok=171729 upd=0 obs=0
Pages : mrk=148687337 unc=145492607
Acquire: n=1890281 nul=0 noc=0 ok=1890281 nbf=0 oom=0
Lookups: n=1097490 neg=925761 pos=171729 crt=925761 tmo=0
Invals : n=0 run=0
Updates: n=0 nul=0 run=0
Relinqs: n=1759445 nul=0 wcr=0 rtr=0
AttrChg: n=0 ok=0 nbf=0 oom=0 run=0
Allocs : n=0 ok=0 wt=0 nbf=0 int=0
Allocs : ops=0 owt=0 abt=0
Retrvls: n=2393196 ok=465345 wt=723800 nod=1927851 nbf=0 int=0 oom=0
Retrvls: ops=2393196 owt=662915 abt=0
Stores : n=118288880 ok=118288880 agn=0 nbf=0 oom=0
Stores : ops=2049040 run=120337487 pgs=118288447 rxd=118288880 olm=0
VmScan : nos=145461870 gon=0 bsy=0 can=433 wt=11
Ops : pend=662994 run=4442236 enq=153450538 can=0 rej=0
Ops : dfr=36586 rel=4442236 gc=36586
CacheOp: alo=0 luo=0 luc=0 gro=0
CacheOp: inv=0 upo=0 dro=0 pto=0 atc=0 syn=0
CacheOp: rap=0 ras=0 alp=0 als=0 wrp=0 ucp=0 dsp=0

Если счетчики двигаются, значит все ОК, настройка завершена.

Заключение
Нам повезло, что нагрузка клиента в основном представляет собой операции чтения, что позволяет использовать FS-Cache совместно с NFS. Если бы проблема была в нагрузке по записи, мы бы не смогли эффективно воспользоваться данной технологией.

billing.netpoint-dc.com/billmgr?func=register&lang=ru