Падает производительность файлового сервера
 

В один прекрасный момент появилась задача сделать файловый сервер для перенаправленных папок и перемещаемых профилей (порядка 2 000) для терминальной фермы.
Что было сделано:
- Поднят отказоустойчивый кластер на 2 виртуальных машинах с 2 линками по гигабиту.
- Операционная система Windows Server 2008 R2, все критичные обновления стоят.
- По ISCSI подцеплен диск, расположенный на СХД HP Lefthand 4500
- Созданы папки, настроено перенаправление и т.д.
По итогу все замечательно заработало, работало достаточно долго (более года).
При росте количества пользователей до примерно 4 000 начали наблюдаться недетские тормоза. Очень долгое применение политики, низкая скорость доступа. Вход в каталог, содержащий порядка 2 000 папок, занимал 10-15 секунд. Наращивание мощности виртаулок эффекта не дало. СХД загружено порядка на 30% от максиума, в моменты тормозов нагрузка на СХД падала...
Одну из нод кластера заменили на железный HP DL 380(толстый, модный. пара процов, 98 памяти), воткнули в него сетевые 10G. Нормальная работа продолжилась примерно до нарастания количества пользователей до 6 000, далее опять тормоза.
Разделили перенаправленные папки и перемещаемые профили. Профили положили на отдельный сервер с DAS на SSD. Приммерно до 8 000 пользователей все работало. Потом опять тормоза. Разделили и перенаправленные папки по обкатанной схеме, вынесли aplication data на отдельный сервер с DAS на SSD. Некоторое время проработало, сейчас пользователей перевалило за 9 000. На серваке с SSD опять начались тормоза.
В момент тормозов нагрузка проца 50-60% (время ядра). Память не обязательно занята вся (хотя чаще всего вся занята кэшем). Нагрузка сетевой 1-2% Активное время винта - до 10. Глубина очереди до 0.5 Перезагрузка сервера помогает на пару-тройку часов.
Из-за тормозов на файловом доступе вход на терминальную ферму может занимать 10-15 минут, сохранение екселевского файла на 100 метров - минут 5.
Разбивать aplication data еще на 2 сервера - попахивает маразмом. Делать децентрализацию - вызывает еще больший ворох проблем.
Куда дальше копать - нет ни малейших идей. Сменить операционку - лучше не предлагать, ибо спецов нет, и при проблемах в работе никто упавший линукс не поднимет... Специализированная железка в планах, но до нее надо дожить. Есть впечатление, что ложится на определенном количестве активных коннектов.
Может у уважаемого сообщества есть хоть какие-то идеи в каком направлении можно покопать для решения проблемы? Заранее благодарен.

В смысле "маразм" и "ворох проблем"?
Если у вас так много клиентских профилей, значит у вас очень много подразделений.
Сделайте через групповые политики для разных подразделений разные пути к перенаправленным папкам, и размещайте эти папки на разных файловых серверах.

Over 9000 офисных работников в фирме, и ни одного системного администратора с достаточным уровнем знания Linux в отделе IT? Не верю.

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

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

cameron, терминальников более 50.
Системные интеграторы пока разводят руками. Обещают посмотреть бест практикс, подумать над вопросом, но результата пока ноль. Да никто и браться особо не хочет. Абсолютно верно говорят:"Купите нормальную железку и будет вам счастье." Но по внутренним причинам с бюджетом большая напряженка и выбить деньги во вменяемые сроки надежды особой нет.

Это перенаправленные папки и перемещаемые профили. На что мне задать ограничение? Что скажет терминальник пользователю, когда тупо его не пустит за профилем?

Придется поверить. Используется только продукция Microsoft. Политику компании можно обсуждать, но выполнять все равно придется.

Маразм - в смысле что при дальнейшем росте нечего уже будет разбивать. Вполне возможна ситуация, когда один сервер содержит рабочие столы, второй - папку мои документы, третий - application data, четвертый - профили, пятый - мелочи вроди избранного, меню пуска и прочего. И в один прекрасный момент серверов не хватит.
С другой стороны проблема - на чем это все хранить. Если LeftHand - это отказоустойчивый сетевой RAID 10 (в частном случае RAID 1), то хранение на DAS - это временное решение (очень надеюсь) от невозможности решить проблему. Что виновато в низкой производительности и в "затупах" - бог его знает. Есть подозрение на сервер, но доказать не могу. При децентрализации мест хранения - надо не только обеспечить достойную СХД в "подкладку", но и обеспечить хранение синхронной копии, бакапов и т.д. Оборудования нет :(
Да и явных ограничений от Microsofta на количество сессий с сервером тоже не нашел. Если есть мощная не нагруженная железка, причем узкого места не видно, то почему она не работает как надо?

а что, в данном случае, подразумевается под "нормальной железякой"?


а чем в данном случае поможет линукс-решение?

Hitachi NAS Platform в планах.

P.S. Забыл сказать, местоположение - Беларусь.

я бы посоветовала поглядеть на Storwize или Equallogic с NAS-шлюзами.
не могу ничего подсказать про интеграторов РБ, в РФ есть i-teco, которые в своё время показали заоблачные компетенции (надеюсь, что это не сочтут за рекламу).

СХД hitachi уже едет, буквально через неделю в руках будет. Так что выбор уже сделан. Но NAS Platform к ней пока не едет :(
А самое главное - я не могу никому объяснить, чегож мне не хватает в существующем решении.

Вы совсем не поняли меня.
Вы размещаете на разных серверах не "разные папки", а папки разных подразделений. Например:
Профили отдела продаж располагаются в DFS по адресу "\\domain\пользовательские\перенаправленные папки\отдел продаж\", который соответствует сетевой папке "\\server1\roamed_prodazhi$"
Профили отдела закупок располагаются в DFS по адресу "\\domain\пользовательские\перенаправленные папки\отдел закупок\", который соответствует сетевой папке "\\server2\roamed_zakupki$"
И так далее по списку.
Благо разным подразделениям можно назначить разные групповые политики с разными путями перенаправленных папок. Также можно назначить разным подразделениям разные пути к перемещаемым профилям пользователей.
Таким образом нагрузка распределяется между несколькими серверами.
Ну а вы в свою очередь через оснастку DFS в любой момент для равномерного распределения нагрузки (по количеству одновременно работающих пользователей и/или объёму файлов) можете произвести изменение реальной сетевой папки таким образом, что пользователи ничего не заметят.

Не вполне понял мысль.
Децентрализация вышеописанным способом вроде бы как не требует "подкладки".
DFS - это просто структура папок (на одном или нескольких дублирующих серверах) с "ярлычками" на реальные сетевые ресурсы.
При использовании двух и более ярлычков для одного раздела DFS репликация реальных сетевых папок производится встроенными средствами Windows Server.

P.S.
"10-15 минут" на "9000 пользователей" даёт общее время простоя порядка полутора тысяч человеко-часов ежедневно
При средней стоимости человеко-часа даже в 150 руб получаем порядка 225 тысяч прямого убытка ежедневно.
Представьте себе, какую шайтан-машину для серверной можно было бы купить даже за одну рабочую неделю.
Даже если деньги в бюджете расписаны по разным кодам, и конкретно по вашему коду "денег нет и не предвидится", то составленная подобным образом служебная записка позволит существенно ускорить процесс выделения.

Нагрузку по нодам DFS уже делить некдуа, нужно вводить в эксплутацию ещё одну. Исходя из фразы Проблема именно в мощностях сервера.
З.ы. Я правильно понимаю, что при первоначальной схеме у вас единая точка отказа в виде СХД?

Вообще-то изначально DFS вообще не упоминалось.
Зато по описанию проблемы получалось, что over9000 пользователей пытаются открыть одну сетевую папку, что вызывает определённые проблемы у службы файлового сервера.
По этому я в качестве решения предлагаются разнести эту информацию по разным сетевым папкам, размещённым на разных файловых серверах.

shaikov, если не секрет, что у вас за организация и какие функции выполняют все эти пользователи?

Подкладка - СХД, обеспечивающая физическое хранение данных. Прошу простить, что не совсем точно выразил свою мысль. Мне просто негде взять еще 2-3 нормальных сервера с нормальными системами хранения без единой точки отказа. Если я на надежной СХД храню критичные папки "рабочий стол" и "документы", где содержится информация, которую никак невозможно потерять, то потеря профилей и aplication data болезненна, но не смертельна. Именно поэтому выбирали такой путь разделения. Не могу согласиться с использованием DFS в этом случае. Проблемы синхронизации DFS на больших размерах папок с большим количеством данных в активной работе достаточно известны. Пробовали, пришлось отказаться при намного меньшей нагрузки. Можно использовать только для изменения месторасположения реальной папки, но без синхронизации не особо имеет смысл. Еще раз повторюсь: "Почему система, которой со всех сторон все хватает, не может данным образом функционировать?" Это основной вопрос. Иначе не понятно в какую сторону развиваться.
Я не буду ничего говорить про отношение руководства к ИТ, но прошу поверить, что все аргументы, расчеты и доказательства приводились, служебные записки писались и т.д. Больше я об этой ситуации без мата ничего сказать не могу.

HP LeftHand 4500 - это сетевое зеркало. Стоит 2 (можно больше) ящика и реплицируются между собой "на лету". Сломать весьма тяжело.

Ну они пытаются открыть разные папки, каждый свою :) Но расположены изначально были на одном файловом сервере. Сейчас уже получается на 3. Организация - достаточно крупная розничная сеть. Функции пользователей - сравнимы с обычными офисными заданиями.

shaikov,
по моему опыту серверу в режиме ТС сложно переваривать больше 100 пользователей.
уж не знаю почему, но мои выкладки получились именно такими.
вы не пробовали увеличивать кол-во серверов в ферме для уменьшения кол-ва пользователей на каждого члена фермы?
как я понимаю хранилища у вас вытягивабт нагрузку, очереди не зашкаливают, интерфейсы не 100% утилилированы?
какой-нибудь тиринг используется? SSD кеш? для чтения он может давать хорошие результаты.

Без напряжения работают до 300. Существует несколько ферм для различных задач + несколько одиночных серверов. От 50 до 300 пользователей в зависимости от используемого для работы прикладного софта. У всех общий рабочий стол, документы, настройки. Количество серверов увеличиваем постоянно, с ростом пользователей. Уже точно выяснили, что проблемы начинаются при тормозах на файловом сервере.
В настоящий момент СХД подпирает основной файловый кластер, который содержит рабочие столы и документы. Профили лежат просто на серваке с SSD, aplication data лежат также на серваке с SSD. В настоящий момент периодические тормоза на последнем. Ни СХД, ни SSD-диски не напрягаются. На SSD более 500 IOPS не видел, СХД тоже очень далека от предела. На тестах выдавала значения в 10 раз больше чем выдает в момент тормозов. Нагрузки на интерфейсах больше 25% вообще никогда не видел, в момент тормозов нагрузка 0.1-0.2% очереди менее 0.5, чаще 0.2.

я предполагаю, что дело в кол-ве одновременных сессий\открытых файлов.
поэтому я вас спрашивала про СХД с NAS шлюзами (блочный уровень или файловый).
как я понимаю, сейчас у вас блочный, что возвращает нас к файловому серверу, как агрегатору файлового уровня.

У меня тоже создается такое впечатление, хотя ни в одном источнике я не нашел какого-то ограничения на количество открытых файлов либо установленных сессий. Сегодня смотрел счетчики. Тормозов не было. Примерно в пиковые времена порядка 4500 сессий и 51000 открытых файлов. Эту неделю тормоза проявляются в какие-то абсолютно случайные промежутки времени, и я даже не всегда могу их связать с пиками загрузки по количеству пользователей.
Посмотрев, что во многих блочных СХД NAS шлюзами являются сервера с установленным Windows Storage Server, есть желание поставить его. Но реальных цифр, доказывающих что Storage Server имеет какое-то преимущество над ролью файлового сервера обычного Windows Servera, не нашел. Везде только утверждения типа "быстрее-выше-сильнее".

а нет каких либо файлов (если торговля то предположительно таблиц эксель с 200+ тыс строк\столбцов) с которыми работает большое кол-во пользователей расположенных на разных фермах? Быть может обращение к таким файлам и даёт "тормоза", поэтому и систематики нет никакой.

Судя по всему, есть.
Вообще-то для такого уже нужно использовать специальные СУБД - ту же "1С: Предприятие"

Уточнение - вы используете непосредственно физические сервера или же виртуальные машины?

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

я говорю про аппаратное решение.
вот поэтому и можно нагнуть интеграторов, поставив чёткую задачу:
хочу 45к сессий и 510к открытых файлов. смогут решить - и вам хорошо и им, не смогут - вы ничего не потеряете.

Kondei, El Scorpio, исходя из того что доступ к рабочему столу и документам пользователя есть лишь только у самого пользователя - скорее всего файлов с многочисленным открытием нет. Файлы по 100-300 Мб встречаются, но работа в монопольном режиме. 1С и прочее используется, конечно, но многим пользователям в екселе привычнее.
В настоящее время кластер на физических машинах, на который прицеплена СХД и 2 виртуальных сервера с SSD. После многочисленных экспериментов ESX обвинить ни в чем не могу...

Я понял, что про аппаратное. Просто например HP, для обеспечения файлового доступа к своему 3PAR, предлагает NAS шлюз, представляющий из себя сервер с установленным Windows Storage Server. Имеет ли смысл попробовать перейти от просто Windows Server к Storage Server? Есть ли реальные преимущества. Может кто сталкивался? Вопрос о лицензионной чистоте пока опустим, я знаю, что Storage продается только с железками.
cameron, беда в Беларуси с интеграторами.... За проект, который стоит меньше пары сотен тысяч зелени, браться и гарантировать что-то никто особо не рвется. Стандартное отношение - вот эта железка по спецификации обеспечит столько. Наверное... Если вам повезет...
Я пока не нашел, кто может точно объяснить что происходит. Общие предположения что где-то чего-то не хватает... Но гарантировать никто ничего не стремится...

Еще раз повторюсь: Что нужна новая железка, все вроде соглашаются. Но очень хочется найти "узкое место" в существующем решении.

Поскольку вы используете перенаправление папок "рабочий стол" и "мои документы", то получаете over9000 постоянных соединений с каждым файловым сервером, который хранит любую из данных папок.

Что "привычнее"?
Получать нагоняи из-за того, что в разных файлах оказались разные цифры? :)


Получается, что клиенты обращаются по SMB к сетевым папкам на сервере Windows 2008R2 (кластер из двух машин).
Затем служба "Сервер" читает локальный жёсткий диск, который на самом деле - блочное устройство iSCSI. И сам файл блочного устройства физически хранится на HP Lefthand 4500.

Как следствие, есть следующие подозрительные места:
- служба SMB файлового сервера Windows
- дисковая подсистема NTFS сервера Windows
- клиент iSCSI кластера
- сервер iSCSI СХД
- дисковая подсистема СХД
При этом последние три позиции не зависят от количества клиентов на сервере, потому что там идёт работа с блочным устройством, и достаточно только соответствия по скорости чтения/записи.


Вопрос: а поддерживает ли устройству HP Lefthand 4500 протокол SBM? Яндекс подсказывает, что протокол CIFS (SMB 2.0) имеется.
Может лучше было бы выделить на СХД отдельный диск (раздел), отформатировать его под NTFS и открыть на нём потребное количество сетевых папок, чтобы клиенты обращались к устройству HP Lefthand 4500 напрямую?
Возможно, служба SBM на нём будет работать лучше, чем на Windows Server?

Поэтому в первую очередь подозрение на количество открытых файлов. Но это недоказуемо, скорее эмпирические ощущения.

Все так, но на самом деле поддержка появляется при наличии "Шлюз на базе операционной системы Windows Storage Server 2008 R2 Enterprise и серверов HP ProLiant"
Те же песни, только вид сбоку.

Каждый файл exel по 100-300 мб даёт очень хорошую утилизацию памяти.
Я до сих пор понять не могу, долго открываются сами файлы или каталоги в которых файлы?

И то и другое. Медленно работает все с файлового сервера.

shaikov,
не знаю, видели вы или нет, но вдруг:
http://blogs.citrix.com/2010/10/21/s...s-server-2008/
http://blogs.msdn.com/b/openspecific...n-windows.aspx