(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Гб. Строка запуска:

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% канальной емкости.

Забавно посмотреть, что творилось в это время в кластере:( Read more... )

(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Гб. Строка запуска:

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% канальной емкости.

Забавно посмотреть, что творилось в это время в кластере:( Read more... )