![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
(no subject)
Для завтрашнего мероприятия в Мариотт Гранд, гоняли сегодня тестики по кластерной самбе. Простейший кластер из двух узлов, (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Гб. Строка запуска:
То есть, запускаем на каждом клиенте по 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Гб ОЗУ сервера). И если память нарастить еще можно, то слоты для сетевых карт закончатся довольно быстро, пусть и с многопортовками.
В результате, мы получаем приблизительно следующую картину для четырех клиентов:
Видно, что один из клиентов "сообразил" раньше и захватил всю доступную себе полосу пропускания -- из 1Гбит/с ему было доступно 100.868 МБайт/с, или 80.69% канальной емкости. Остальные запустились более-менее одновременно и потому распределили между собой оставшийся объем канала. Суммарно вышло 218.5708МБайт/с из доступных 2Гбит/с, которые кластер мог отдать. Или 87.42% канальной емкости.
Забавно посмотреть, что творилось в это время в кластере:
Видно, что процессы smbd запущены на разных узлах (0: и 1: в колонке Pid -- виртуальные номера узлов в кластере), а информация о блокировках файлов доступна всем процессам smbd на всех узлах. Оно просто работает. Правда, нагрузка распределилась между узлами неравномерно, но это скорее вопрос к настройке коммутаторов, где было включено хэширование соединений по IP-адресам.
Увеличивая количество узлов в кластере мы можем добиться более оптимальной утилизации канала для текущего количества клиентов. В нашем случае дисковая полка, очевидно, вытягивает и больше, а не хватает именно канальной емкости. В случае если не будет хватать шпинделей, достаточно добавить их и GPFS "размажет" данные по добавочной емкости.
В принципе, аналогичную картину можно получить и с другими кластерными файловыми системами, если постараться и настроить их соответственно. Весь код доступен, так что желающие могут попробовать.
Да, с августа 2008 в GPFS появилась поддержка Windows -- теперь тома GPFS можно монтировать по ее родному протоколу. Выиграем ли мы, используя родной протокол GPFS против CIFS? Наверное, где-нибудь процентов 5, а может и проиграем, я не сравнивал производительность GPFS и CIFS. Есть еще расходы на TCP/IP, а 87% реальной утилизации уже довольно близки к тому, что можно достичь с Gigabit Ethernet.
Берем четыре клиентских машины, каждая с 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.