Показать полную графическую версию : Падает производительность файлового сервера
В один прекрасный момент появилась задача сделать файловый сервер для перенаправленных папок и перемещаемых профилей (порядка 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 сервера - попахивает маразмом. Делать децентрализацию - вызывает еще больший ворох проблем.
Куда дальше копать - нет ни малейших идей. Сменить операционку - лучше не предлагать, ибо спецов нет, и при проблемах в работе никто упавший линукс не поднимет... Специализированная железка в планах, но до нее надо дожить. Есть впечатление, что ложится на определенном количестве активных коннектов.
Может у уважаемого сообщества есть хоть какие-то идеи в каком направлении можно покопать для решения проблемы? Заранее благодарен.
El Scorpio
15-04-2015, 04:00
Разбивать aplication data еще на 2 сервера - попахивает маразмом. Делать децентрализацию - вызывает еще больший ворох проблем. »
В смысле "маразм" и "ворох проблем"?
Если у вас так много клиентских профилей, значит у вас очень много подразделений.
Сделайте через групповые политики для разных подразделений разные пути к перенаправленным папкам, и размещайте эти папки на разных файловых серверах.
Сменить операционку - лучше не предлагать, ибо спецов нет, и при проблемах в работе никто упавший линукс не поднимет »
Over 9000 офисных работников в фирме, и ни одного системного администратора с достаточным уровнем знания Linux в отделе IT? Не верю.
Есть впечатление, что ложится на определенном количестве активных коннектов. »
Возможно.
Попробуйте явно задать ограничение сессий на уровне файлового сервера для наиболее активно используемых сетевых папок.
shaikov,
настоятельно рекомендую вам обратиться к интеграторам.
задача в данном случае относительно простая и запрощенный результат может быть оценён оперативно.
просто для информации - 9к пользователей на ферме из двух терминальных серверов?
cameron, терминальников более 50.
Системные интеграторы пока разводят руками. Обещают посмотреть бест практикс, подумать над вопросом, но результата пока ноль. Да никто и браться особо не хочет. Абсолютно верно говорят:"Купите нормальную железку и будет вам счастье." Но по внутренним причинам с бюджетом большая напряженка и выбить деньги во вменяемые сроки надежды особой нет.
Попробуйте явно задать ограничение сессий на уровне файлового сервера для наиболее активно используемых сетевых папок. »
Это перенаправленные папки и перемещаемые профили. На что мне задать ограничение? Что скажет терминальник пользователю, когда тупо его не пустит за профилем?
Over 9000 офисных работников в фирме, и ни одного системного администратора с достаточным уровнем знания Linux в отделе IT? Не верю. »
Придется поверить. Используется только продукция Microsoft. Политику компании можно обсуждать, но выполнять все равно придется.
В смысле "маразм" и "ворох проблем"?
Если у вас так много клиентских профилей, значит у вас очень много подразделений.
Сделайте через групповые политики для разных подразделений разные пути к перенаправленным папкам, и размещайте эти папки на разных файловых серверах. »
Маразм - в смысле что при дальнейшем росте нечего уже будет разбивать. Вполне возможна ситуация, когда один сервер содержит рабочие столы, второй - папку мои документы, третий - application data, четвертый - профили, пятый - мелочи вроди избранного, меню пуска и прочего. И в один прекрасный момент серверов не хватит.
С другой стороны проблема - на чем это все хранить. Если LeftHand - это отказоустойчивый сетевой RAID 10 (в частном случае RAID 1), то хранение на DAS - это временное решение (очень надеюсь) от невозможности решить проблему. Что виновато в низкой производительности и в "затупах" - бог его знает. Есть подозрение на сервер, но доказать не могу. При децентрализации мест хранения - надо не только обеспечить достойную СХД в "подкладку", но и обеспечить хранение синхронной копии, бакапов и т.д. Оборудования нет :(
Да и явных ограничений от Microsofta на количество сессий с сервером тоже не нашел. Если есть мощная не нагруженная железка, причем узкого места не видно, то почему она не работает как надо?
Абсолютно верно говорят:"Купите нормальную железку и будет вам счастье." »
а что, в данном случае, подразумевается под "нормальной железякой"?
и ни одного системного администратора с достаточным уровнем знания Linux в отделе IT? Не верю. »
а чем в данном случае поможет линукс-решение?
а что, в данном случае, подразумевается под "нормальной железякой"? »
Hitachi NAS Platform в планах.
P.S. Забыл сказать, местоположение - Беларусь.
Hitachi NAS Platform в планах. »
я бы посоветовала поглядеть на Storwize или Equallogic с NAS-шлюзами.
P.S. Забыл сказать, местоположение - Беларусь. »
не могу ничего подсказать про интеграторов РБ, в РФ есть i-teco, которые в своё время показали заоблачные компетенции (надеюсь, что это не сочтут за рекламу).
СХД hitachi уже едет, буквально через неделю в руках будет. Так что выбор уже сделан. Но NAS Platform к ней пока не едет :(
А самое главное - я не могу никому объяснить, чегож мне не хватает в существующем решении.
El Scorpio
16-04-2015, 01:24
Цитата El Scorpio:
В смысле "маразм" и "ворох проблем"?
Если у вас так много клиентских профилей, значит у вас очень много подразделений.
Сделайте через групповые политики для разных подразделений разные пути к перенаправленным папкам, и размещайте эти папки на разных файловых серверах. »
Маразм - в смысле что при дальнейшем росте нечего уже будет разбивать. Вполне возможна ситуация, когда один сервер содержит рабочие столы, второй - папку мои документы, третий - application data, четвертый - профили, пятый - мелочи вроди избранного, меню пуска и прочего. И в один прекрасный момент серверов не хватит. »
Вы совсем не поняли меня.
Вы размещаете на разных серверах не "разные папки", а папки разных подразделений. Например:
Профили отдела продаж располагаются в DFS по адресу "\\domain\пользовательские\перенаправленные папки\отдел продаж\", который соответствует сетевой папке "\\server1\roamed_prodazhi$"
Профили отдела закупок располагаются в DFS по адресу "\\domain\пользовательские\перенаправленные папки\отдел закупок\", который соответствует сетевой папке "\\server2\roamed_zakupki$"
И так далее по списку.
Благо разным подразделениям можно назначить разные групповые политики с разными путями перенаправленных папок. Также можно назначить разным подразделениям разные пути к перемещаемым профилям пользователей.
Таким образом нагрузка распределяется между несколькими серверами.
Ну а вы в свою очередь через оснастку DFS в любой момент для равномерного распределения нагрузки (по количеству одновременно работающих пользователей и/или объёму файлов) можете произвести изменение реальной сетевой папки таким образом, что пользователи ничего не заметят.
При децентрализации мест хранения - надо не только обеспечить достойную СХД в "подкладку", но и обеспечить хранение синхронной копии, бакапов и т.д. »
Не вполне понял мысль.
Децентрализация вышеописанным способом вроде бы как не требует "подкладки".
DFS - это просто структура папок (на одном или нескольких дублирующих серверах) с "ярлычками" на реальные сетевые ресурсы.
При использовании двух и более ярлычков для одного раздела DFS репликация реальных сетевых папок производится встроенными средствами Windows Server.
P.S.
Абсолютно верно говорят:"Купите нормальную железку и будет вам счастье." Но по внутренним причинам с бюджетом большая напряженка и выбить деньги во вменяемые сроки надежды особой нет. »
"10-15 минут" на "9000 пользователей" даёт общее время простоя порядка полутора тысяч человеко-часов ежедневно
При средней стоимости человеко-часа даже в 150 руб получаем порядка 225 тысяч прямого убытка ежедневно.
Представьте себе, какую шайтан-машину для серверной можно было бы купить даже за одну рабочую неделю.
Даже если деньги в бюджете расписаны по разным кодам, и конкретно по вашему коду "денег нет и не предвидится", то составленная подобным образом служебная записка позволит существенно ускорить процесс выделения.
Нагрузку по нодам DFS уже делить некдуа, нужно вводить в эксплутацию ещё одну. Исходя из фразы Одну из нод кластера заменили на железный HP DL 380(толстый, модный. пара процов, 98 памяти), воткнули в него сетевые 10G. Нормальная работа продолжилась примерно до нарастания количества пользователей до 6 000, далее опять тормоза »
Проблема именно в мощностях сервера.
З.ы. Я правильно понимаю, что при первоначальной схеме у вас единая точка отказа в виде СХД?
El Scorpio
16-04-2015, 07:08
Нагрузку по нодам DFS уже делить некдуа »
Вообще-то изначально DFS вообще не упоминалось.
Зато по описанию проблемы получалось, что over9000 пользователей пытаются открыть одну сетевую папку, что вызывает определённые проблемы у службы файлового сервера.
По этому я в качестве решения предлагаются разнести эту информацию по разным сетевым папкам, размещённым на разных файловых серверах.
shaikov, если не секрет, что у вас за организация и какие функции выполняют все эти пользователи?
Децентрализация вышеописанным способом вроде бы как не требует "подкладки". »
Подкладка - СХД, обеспечивающая физическое хранение данных. Прошу простить, что не совсем точно выразил свою мысль. Мне просто негде взять еще 2-3 нормальных сервера с нормальными системами хранения без единой точки отказа. Если я на надежной СХД храню критичные папки "рабочий стол" и "документы", где содержится информация, которую никак невозможно потерять, то потеря профилей и aplication data болезненна, но не смертельна. Именно поэтому выбирали такой путь разделения. Не могу согласиться с использованием DFS в этом случае. Проблемы синхронизации DFS на больших размерах папок с большим количеством данных в активной работе достаточно известны. Пробовали, пришлось отказаться при намного меньшей нагрузки. Можно использовать только для изменения месторасположения реальной папки, но без синхронизации не особо имеет смысл. Еще раз повторюсь: "Почему система, которой со всех сторон все хватает, не может данным образом функционировать?" Это основной вопрос. Иначе не понятно в какую сторону развиваться.
Я не буду ничего говорить про отношение руководства к ИТ, но прошу поверить, что все аргументы, расчеты и доказательства приводились, служебные записки писались и т.д. Больше я об этой ситуации без мата ничего сказать не могу.
З.ы. Я правильно понимаю, что при первоначальной схеме у вас единая точка отказа в виде СХД? » HP LeftHand 4500 - это сетевое зеркало. Стоит 2 (можно больше) ящика и реплицируются между собой "на лету". Сломать весьма тяжело.
Зато по описанию проблемы получалось, что over9000 пользователей пытаются открыть одну сетевую папку, что вызывает определённые проблемы у службы файлового сервера.
По этому я в качестве решения предлагаются разнести эту информацию по разным сетевым папкам, размещённым на разных файловых серверах.
shaikov, если не секрет, что у вас за организация и какие функции выполняют все эти пользователи? »
Ну они пытаются открыть разные папки, каждый свою :) Но расположены изначально были на одном файловом сервере. Сейчас уже получается на 3. Организация - достаточно крупная розничная сеть. Функции пользователей - сравнимы с обычными офисными заданиями.
shaikov,
по моему опыту серверу в режиме ТС сложно переваривать больше 100 пользователей.
уж не знаю почему, но мои выкладки получились именно такими.
вы не пробовали увеличивать кол-во серверов в ферме для уменьшения кол-ва пользователей на каждого члена фермы?
как я понимаю хранилища у вас вытягивабт нагрузку, очереди не зашкаливают, интерфейсы не 100% утилилированы?
какой-нибудь тиринг используется? SSD кеш? для чтения он может давать хорошие результаты.
по моему опыту серверу в режиме ТС сложно переваривать больше 100 пользователей. »
Без напряжения работают до 300. Существует несколько ферм для различных задач + несколько одиночных серверов. От 50 до 300 пользователей в зависимости от используемого для работы прикладного софта. У всех общий рабочий стол, документы, настройки. Количество серверов увеличиваем постоянно, с ростом пользователей. Уже точно выяснили, что проблемы начинаются при тормозах на файловом сервере.
В настоящий момент СХД подпирает основной файловый кластер, который содержит рабочие столы и документы. Профили лежат просто на серваке с SSD, aplication data лежат также на серваке с SSD. В настоящий момент периодические тормоза на последнем. Ни СХД, ни SSD-диски не напрягаются. На SSD более 500 IOPS не видел, СХД тоже очень далека от предела. На тестах выдавала значения в 10 раз больше чем выдает в момент тормозов. Нагрузки на интерфейсах больше 25% вообще никогда не видел, в момент тормозов нагрузка 0.1-0.2% очереди менее 0.5, чаще 0.2.
В настоящий момент СХД подпирает основной файловый кластер, который содержит рабочие столы и документы. Профили лежат просто на серваке с 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, не нашел. Везде только утверждения типа "быстрее-выше-сильнее".
Сегодня смотрел счетчики. Тормозов не было. Примерно в пиковые времена порядка 4500 сессий и 51000 открытых файлов. Эту неделю тормоза проявляются в какие-то абсолютно случайные промежутки времени, и я даже не всегда могу их связать с пиками загрузки по количеству пользователей. »
а нет каких либо файлов (если торговля то предположительно таблиц эксель с 200+ тыс строк\столбцов) с которыми работает большое кол-во пользователей расположенных на разных фермах? Быть может обращение к таким файлам и даёт "тормоза", поэтому и систематики нет никакой.
El Scorpio
17-04-2015, 04:59
а нет каких либо файлов (если торговля то предположительно таблиц эксель с 200+ тыс строк\столбцов) с которыми работает большое кол-во пользователей расположенных на разных фермах? »
сохранение екселевского файла на 100 метров - минут 5. »
Судя по всему, есть.
Вообще-то для такого уже нужно использовать специальные СУБД - ту же "1С: Предприятие"
СХД, обеспечивающая физическое хранение данных. Прошу простить, что не совсем точно выразил свою мысль. Мне просто негде взять еще 2-3 нормальных сервера с нормальными системами хранения без единой точки отказа. »
Уточнение - вы используете непосредственно физические сервера или же виртуальные машины?
Не могу согласиться с использованием DFS в этом случае. Проблемы синхронизации DFS на больших размерах папок с большим количеством данных в активной работе достаточно известны. »
Я не предлагаю дублировать один раздел DFS на несколько разных серверов.
Однако использование DFS позволяет упростить структуру сетевых папок и обеспечить сокрытие вносимых изменений от конечных пользователей, что позволяет избегать массового изменения настроек при переносе информации
, в том числе
Посмотрев, что во многих блочных СХД NAS шлюзами являются сервера с установленным Windows Storage Server, есть желание поставить его. Но реальных цифр, доказывающих что Storage Server имеет какое-то преимущество над ролью файлового сервера обычного Windows Servera, не нашел. Везде только утверждения типа "быстрее-выше-сильнее". »
я говорю про аппаратное решение.
Везде только утверждения типа "быстрее-выше-сильнее". »
вот поэтому и можно нагнуть интеграторов, поставив чёткую задачу:
хочу 45к сессий и 510к открытых файлов. смогут решить - и вам хорошо и им, не смогут - вы ничего не потеряете.
Kondei, El Scorpio, исходя из того что доступ к рабочему столу и документам пользователя есть лишь только у самого пользователя - скорее всего файлов с многочисленным открытием нет. Файлы по 100-300 Мб встречаются, но работа в монопольном режиме. 1С и прочее используется, конечно, но многим пользователям в екселе привычнее.
В настоящее время кластер на физических машинах, на который прицеплена СХД и 2 виртуальных сервера с SSD. После многочисленных экспериментов ESX обвинить ни в чем не могу...
я говорю про аппаратное решение. »
Я понял, что про аппаратное. Просто например HP, для обеспечения файлового доступа к своему 3PAR, предлагает NAS шлюз, представляющий из себя сервер с установленным Windows Storage Server. Имеет ли смысл попробовать перейти от просто Windows Server к Storage Server? Есть ли реальные преимущества. Может кто сталкивался? Вопрос о лицензионной чистоте пока опустим, я знаю, что Storage продается только с железками.
cameron, беда в Беларуси с интеграторами.... За проект, который стоит меньше пары сотен тысяч зелени, браться и гарантировать что-то никто особо не рвется. Стандартное отношение - вот эта железка по спецификации обеспечит столько. Наверное... Если вам повезет...
Я пока не нашел, кто может точно объяснить что происходит. Общие предположения что где-то чего-то не хватает... Но гарантировать никто ничего не стремится...
Еще раз повторюсь: Что нужна новая железка, все вроде соглашаются. Но очень хочется найти "узкое место" в существующем решении.
© OSzone.net 2001-2012
vBulletin v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.