[El Scorpio]

Нагрузку по нодам DFS уже делить некдуа »

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

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

[shaikov]

Децентрализация вышеописанным способом вроде бы как не требует "подкладки". »

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

З.ы. Я правильно понимаю, что при первоначальной схеме у вас единая точка отказа в виде СХД? »

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

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

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

[cameron]

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

[shaikov]

по моему опыту серверу в режиме ТС сложно переваривать больше 100 пользователей. »

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

[cameron]

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

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

[shaikov]

я предполагаю, что дело в кол-ве одновременных сессий\открытых файлов »

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

[Kondei]

Сегодня смотрел счетчики. Тормозов не было. Примерно в пиковые времена порядка 4500 сессий и 51000 открытых файлов. Эту неделю тормоза проявляются в какие-то абсолютно случайные промежутки времени, и я даже не всегда могу их связать с пиками загрузки по количеству пользователей. »

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

[El Scorpio]

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

сохранение екселевского файла на 100 метров - минут 5. »

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

СХД, обеспечивающая физическое хранение данных. Прошу простить, что не совсем точно выразил свою мысль. Мне просто негде взять еще 2-3 нормальных сервера с нормальными системами хранения без единой точки отказа. »

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

Не могу согласиться с использованием DFS в этом случае. Проблемы синхронизации DFS на больших размерах папок с большим количеством данных в активной работе достаточно известны. »

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

[cameron]

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

я говорю про аппаратное решение.

Везде только утверждения типа "быстрее-выше-сильнее". »

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

[shaikov]

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

я говорю про аппаратное решение. »

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

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