Speaker Rabbit

abbra


CIFS: curious information funneled sometimes


Previous Entry Share Next Entry
(no subject)
Speaker Rabbit
abbra
Для завтрашнего мероприятия в Мариотт Гранд, гоняли сегодня тестики по кластерной самбе. Простейший кластер из двух узлов, (2х1Гбит/с, один в пользовательскую сеть, один -- служебный), полка с десятью 15К RPM дисками. Внутре -- GPFS, поверх которой крутится кластерная Самба 3.2.3 в рамках IBM Scale out File Services. Все это воткнуто в Active Directory на базе Windows 2003 Server, так что с системой могут работать в принципе любые клиенты -- от линуксовых до самых распоследних вист.

Берем четыре клиентских машины, каждая с 1Гбит/с, запускаем на них smbtorture из Samba4 с тестом BENCH-NBENCH, который имитирует "отраслевой стандарт" NetBench. Сам скрипт для теста -- чтение блоками по 64Кб из файлов размером в 1Гб. Строка запуска:
bin/smbtorture //filer/test -UПользователь%Пароль BENCH-NBENCH \
     --loadfile=loadfiles/read_1G_64k_at_a_time.load \
     -t 100 --num-progs 4 --option=torture:readonly=yes

То есть, запускаем на каждом клиенте по 4 параллельных процесса, которые читают блоками по 64Кб из файлов рамером в 1Гб и даем 100 секунд на выполнение. BENCH-NBENCH грузит скрипт, форкается и запускает четыре процесса обработки скрипта. Через некоторое время "прогрева" (пока процессы соединятся с серверами...), начинают идти результаты. Указанный адрес сервера (//filer) на самом деле представляет собой "имя сервера" в CIFS. Ему соответствуют разные IP узлов нашего кластера в DNS, так что клиенты получают их при разрешении имени в режиме round-robin.

Поскольку запускал я тесты руками, то между запусками были временные разрывы. Так что какой-то из клиентов успел "отъесть" больше полосы пропускания, чем другие. У нас теоретически 4Гбит/с от клиентов (1Гбит/с от каждого) и 2Гбит/с от кластера. Между коммутаторами настроено объединение каналов -- по 4 1Гбит/с порта с каждой стороны, то есть теоретически мы могли бы "прокинуть" 4Гбит/с, если бы со стороны кластера они были. Каждый клиент мог "съесть" свой 1Гбит/с, если бы получилось.

Тест воспроизводит типичную картину "голода" в офисе, когда возможностей файлового сервера не хватает на всех клиентов из-за ограничений полосы пропускания. В данном случае важным становится эффективное распределение нагрузки между узлами кластера. То есть, в обычном офисном случае у нас файловый сервер на самом деле один и максимум, что мы можем сделать -- это "съесть" его сетевые возможности. С кластерной самбой становится возможным "размазать" этот поток запросов и ответов между несколькими серверами одновременно, а не помещать все сетевые карты в один сервер. Когда-нибудь возможности одного сервера закончатся -- либо по пропускной способности его сетевой подсистемы, либо по затратам на память при обслуживании клиентов (Самба 3.2 требует приблизительно 500-700Кб служебных данных на клиента и порядка 5-7Мб кода на процесс, что транслируется в реальности в 400-500 одновременных пользователей на 1Гб ОЗУ сервера). И если память нарастить еще можно, то слоты для сетевых карт закончатся довольно быстро, пусть и с многопортовками.

В результате, мы получаем приблизительно следующую картину для четырех клиентов:
$ cat client?-1.log|grep Throughput
Throughput 38.7363 MB/sec
Throughput 38.8454 MB/sec
Throughput 100.868 MB/sec
Throughput 40.1211 MB/sec


Видно, что один из клиентов "сообразил" раньше и захватил всю доступную себе полосу пропускания -- из 1Гбит/с ему было доступно 100.868 МБайт/с, или 80.69% канальной емкости. Остальные запустились более-менее одновременно и потому распределили между собой оставшийся объем канала. Суммарно вышло 218.5708МБайт/с из доступных 2Гбит/с, которые кластер мог отдать. Или 87.42% канальной емкости.

Забавно посмотреть, что творилось в это время в кластере:
# smbstatus
Samba version 3.2.3
PID     Username      Group         Machine                        
-------------------------------------------------------------------
1:29854   SOFSDEMO\administrator  SOFSDEMO\domain users  n2           (10.222.25.12)
1:29855   SOFSDEMO\administrator  SOFSDEMO\domain users  n2           (10.222.25.12)
1:29403   SOFSDEMO\administrator  SOFSDEMO\domain users  n1           (10.222.25.11)
1:29606   SOFSDEMO\administrator  SOFSDEMO\domain users  n3           (10.222.25.13)
1:29406   SOFSDEMO\administrator  SOFSDEMO\domain users  n1           (10.222.25.11)
1:29609   SOFSDEMO\administrator  SOFSDEMO\domain users  n3           (10.222.25.13)
0:25719   SOFSDEMO\administrator  SOFSDEMO\domain users  mgmtx        (10.222.25.1)
0:25740   SOFSDEMO\administrator  SOFSDEMO\domain users  mgmtx        (10.222.25.1)
0:25741   SOFSDEMO\administrator  SOFSDEMO\domain users  mgmtx        (10.222.25.1)
0:25742   SOFSDEMO\administrator  SOFSDEMO\domain users  mgmtx        (10.222.25.1)
0:25745   SOFSDEMO\administrator  SOFSDEMO\domain users  mgmtx        (10.222.25.1)
1:29856   SOFSDEMO\administrator  SOFSDEMO\domain users  n2           (10.222.25.12)
1:29404   SOFSDEMO\administrator  SOFSDEMO\domain users  n1           (10.222.25.11)
1:29607   SOFSDEMO\administrator  SOFSDEMO\domain users  n3           (10.222.25.13)
1:29407   SOFSDEMO\administrator  SOFSDEMO\domain users  n1           (10.222.25.11)
1:29853   SOFSDEMO\administrator  SOFSDEMO\domain users  n2           (10.222.25.12)
1:29573   SOFSDEMO\administrator  SOFSDEMO\domain users  n3           (10.222.25.13)
1:29605   SOFSDEMO\administrator  SOFSDEMO\domain users  n3           (10.222.25.13)
1:29405   SOFSDEMO\administrator  SOFSDEMO\domain users  n1           (10.222.25.11)
1:29851   SOFSDEMO\administrator  SOFSDEMO\domain users  n2           (10.222.25.12)

Service      pid     machine       Connected at
-------------------------------------------------------
test         0:25740   mgmtx         Mon Oct 27 15:35:50 2008
test         1:29606   n3            Mon Oct 27 15:35:56 2008
test         1:29854   n2            Mon Oct 27 15:35:59 2008
test         1:29573   n3            Mon Oct 27 15:35:55 2008
test         1:29851   n2            Mon Oct 27 15:35:59 2008
test         1:29404   n1            Mon Oct 27 15:35:52 2008
test         0:25742   mgmtx         Mon Oct 27 15:35:50 2008
test         1:29605   n3            Mon Oct 27 15:35:56 2008
test         1:29406   n1            Mon Oct 27 15:35:52 2008
test         1:29607   n3            Mon Oct 27 15:35:56 2008
test         1:29856   n2            Mon Oct 27 15:35:59 2008
test         1:29853   n2            Mon Oct 27 15:35:59 2008
test         1:29403   n1            Mon Oct 27 15:35:52 2008
test         1:29855   n2            Mon Oct 27 15:35:59 2008
test         0:25741   mgmtx         Mon Oct 27 15:35:50 2008
test         1:29609   n3            Mon Oct 27 15:35:56 2008
test         0:25719   mgmtx         Mon Oct 27 15:35:50 2008
test         1:29405   n1            Mon Oct 27 15:35:52 2008
test         1:29407   n1            Mon Oct 27 15:35:52 2008
test         0:25745   mgmtx         Mon Oct 27 15:35:50 2008

Locked files:
Pid          Uid        DenyMode   Access      R/W        Oplock           SharePath   Name   Time
--------------------------------------------------------------------------------------------------
0:25740      10000000   DENY_NONE  0x183       RDWR       LEVEL_II         /gpfs/shared/test   clients/client1/file.dat   Mon Oct 27 15:36:31 2008
1:29405      10000000   DENY_NONE  0x183       RDWR       NONE             /gpfs/shared/test   clients/client1/file.dat   Mon Oct 27 15:35:52 2008
1:29605      10000000   DENY_NONE  0x183       RDWR       NONE             /gpfs/shared/test   clients/client1/file.dat   Mon Oct 27 15:35:56 2008
1:29853      10000000   DENY_NONE  0x183       RDWR       NONE             /gpfs/shared/test   clients/client1/file.dat   Mon Oct 27 15:35:59 2008
0:25741      10000000   DENY_NONE  0x183       RDWR       LEVEL_II         /gpfs/shared/test   clients/client2/file.dat   Mon Oct 27 15:36:31 2008
1:29404      10000000   DENY_NONE  0x183       RDWR       NONE             /gpfs/shared/test   clients/client2/file.dat   Mon Oct 27 15:35:52 2008
1:29606      10000000   DENY_NONE  0x183       RDWR       NONE             /gpfs/shared/test   clients/client2/file.dat   Mon Oct 27 15:35:56 2008
1:29854      10000000   DENY_NONE  0x183       RDWR       NONE             /gpfs/shared/test   clients/client2/file.dat   Mon Oct 27 15:35:59 2008
0:25745      10000000   DENY_NONE  0x183       RDWR       LEVEL_II         /gpfs/shared/test   clients/client4/file.dat   Mon Oct 27 15:36:28 2008
1:29407      10000000   DENY_NONE  0x183       RDWR       NONE             /gpfs/shared/test   clients/client4/file.dat   Mon Oct 27 15:35:52 2008
1:29607      10000000   DENY_NONE  0x183       RDWR       NONE             /gpfs/shared/test   clients/client4/file.dat   Mon Oct 27 15:35:56 2008
1:29856      10000000   DENY_NONE  0x183       RDWR       NONE             /gpfs/shared/test   clients/client4/file.dat   Mon Oct 27 15:35:59 2008
0:25742      10000000   DENY_NONE  0x183       RDWR       LEVEL_II         /gpfs/shared/test   clients/client3/file.dat   Mon Oct 27 15:36:31 2008
1:29406      10000000   DENY_NONE  0x183       RDWR       NONE             /gpfs/shared/test   clients/client3/file.dat   Mon Oct 27 15:35:52 2008
1:29609      10000000   DENY_NONE  0x183       RDWR       NONE             /gpfs/shared/test   clients/client3/file.dat   Mon Oct 27 15:35:56 2008
1:29855      10000000   DENY_NONE  0x183       RDWR       NONE             /gpfs/shared/test   clients/client3/file.dat   Mon Oct 27 15:35:59 2008


Видно, что процессы smbd запущены на разных узлах (0: и 1: в колонке Pid -- виртуальные номера узлов в кластере), а информация о блокировках файлов доступна всем процессам smbd на всех узлах. Оно просто работает. Правда, нагрузка распределилась между узлами неравномерно, но это скорее вопрос к настройке коммутаторов, где было включено хэширование соединений по IP-адресам.

Увеличивая количество узлов в кластере мы можем добиться более оптимальной утилизации канала для текущего количества клиентов. В нашем случае дисковая полка, очевидно, вытягивает и больше, а не хватает именно канальной емкости. В случае если не будет хватать шпинделей, достаточно добавить их и GPFS "размажет" данные по добавочной емкости.

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

Да, с августа 2008 в GPFS появилась поддержка Windows -- теперь тома GPFS можно монтировать по ее родному протоколу. Выиграем ли мы, используя родной протокол GPFS против CIFS? Наверное, где-нибудь процентов 5, а может и проиграем, я не сравнивал производительность GPFS и CIFS. Есть еще расходы на TCP/IP, а 87% реальной утилизации уже довольно близки к тому, что можно достичь с Gigabit Ethernet.
Tags: , ,

  • 1
Помнится был у тебя неск.лет назад доклад в "Красном зале", из которого было ясно зачем нужен GE =)

В этом году вроде появились первые матери с 10GE на борту и наши системные инженегры уверяют, что датацентрам пора думать о миграции на 10GE на доступе (т.е. от серверов к коммутаторам) примерно в 2010 году.
А на 40-гигабитных скоростях уже открываются возможности по перенаправлению трафика без потери пакетов при перерезании оптоволокна ножницами -- система успевает заметить деградацию качества канала и переключиться на резервный канал до того как что-нибудь пропало.

Мы уже внедряем 10GE, с SoFS. :-)

  • 1
?

Log in

No account? Create an account