Балансировка SAS против балансировки сети

Я хочу настроить файловый сервер в среде MS Windows Server 2012 R2, что бы балансировка нагрузки трафика.

У меня есть дисковый массив SAS с 2 контроллерами SAS, который подключен к 2 узлам кластера Hyper-V с помощью 4 избыточных множественных путей SAS:

контроллер1 <-> узел1, контроллер1 <-> узел2,

контроллер2 <-> узел1, контроллер2 <-> узел2.

Я не знаю, работает ли балансировка нагрузки SAS было бы заметно если бы я НЕ уравновешивал сеть, а это значит, что только один сервер в сети будет обрабатывать все запросы ввода-вывода файлов. Балансировка сети кажется сложной, потому что я не хочу иметь 2 файловых сервера с идентичной копией данных (избыточность гарантируется на уровне RAID дискового массива). Я хочу одну кучу разделение данных на два непересекающиеся области, каждая по отдельный файловый сервер (каждый виртуальный сервер на одном узле кластера), что действовать как единый сервер или общий ресурс SMB.

Пользователь не знает, какие данные находятся на сервере A или B, путь SMB должен быть примерно таким: \\domain.com\home\username или \\domain.com\share\department а дома или отделы должны быть распределены по двум серверам (например, те, которые начинаются с «A-P» на первом, а остальные - на втором).

У меня есть центральный сетевой коммутатор, и каждый узел кластера имеет агрегированный канал со скоростью 5 ГБ / с. Остальная часть сети подключена к этому коммутатору (каждый коммутатор доступа подключается по каналу 2 ГБ / с, клиенты подключаются по каналу 1 ГБ / с).

Мои вопросы:

Если я не буду выполнять балансировку сетевой нагрузки и сохраню балансировку нагрузки SAS, будет ли балансировка нагрузки SAS заметна или нет?
Есть ли какой-то метод кластеризации с балансировкой сетевой нагрузки, с помощью которого я мог бы достичь указанных результатов?
Я знаю, что существует множество факторов, которые зависят от конкретной ситуации (например, максимальное количество одновременных подключений или частота отдельных, возможно, коротких подключений; доминируют ли операции чтения и т. Д.), Но есть ли какие-либо общие передовые практики Я должен уважать?
Разве это не самый простой (и, возможно, лучший) способ ничего не балансировать нагрузкой и иметь простое управление?

РЕДАКТИРОВАТЬ:

Большое спасибо! На самом деле DFS был одним из первых, что я искал, но в итоге я пришел к выводу, что то, что я хочу, с DFS невозможно.

Поиграв с ним некоторое время, я получил следующую конфигурацию:

Одно пространство имен DFS HOME, оба файловых сервера добавлены к нему в качестве серверов пространства имен, поэтому на каждом есть общий ресурс с именем «home», физически находящийся в папке «C: \ DFSRoots \ home». На каждом сервере также есть скрытая основная общая папка с именем «home $», физически размещенная в дисковом массиве. В скрытой части первого сервера я вижу одну половину ДОМОВ, на другой - остальные ДОМА. В домашнем ресурсе DFS (обоих серверов) я вижу только ссылки (распределенные на скрытые общие ресурсы), но на все ДОМАШНИЕ.

Когда клиент подключается к корню (\ domain.com \ root), один из серверов пространства имен DFS отвечает клиенту. В моей ситуации это всегда один и тот же сервер, потому что у меня только один сайт. Но это не имеет значения, потому что он перечисляет только содержимое корня DFS. Когда затем клиент переходит к одной из перечисленных ссылок, DFS устанавливает соединение с целевой скрытой папкой, которая является одним из серверов, поэтому балансировка нагрузки выполняется.

Эта конфигурация правильная, оптимальная?

И последний вопрос: насколько в целом SAS быстрее по сравнению с LAN (например, 5 ГБ / с, агрегированные LACP)?

Вам действительно стоит взглянуть на Microsoft DFS, чтобы делать то, о чем вы говорите.

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

Так, например, у вас будет:

2 узла кластера (FSCL1, FSCL2)
2 кластерные файловые службы (FS1, FS2), работающие на указанных выше узлах
2 доменных пространства имен DFS (HOMES, SHARES), размещенных на указанных выше узлах

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

Вот как это делается там, где я работаю. Возможно, это не самое лучшее, но для нас это очень функционально.

Наши пространства имен размещаются на выделенных серверах, но на самом деле это не является обязательным требованием. Это просто означает, что у нас нет конфликтов имен между общими ресурсами DFS и целевыми общими ресурсами.

На наших файловых серверах (FS1, FS2 и т. Д.) Мы используем точки монтирования для томов данных, потому что в противном случае мы бы запускали буквы (~ 28 томов данных, ~ 7 корневых точек монтирования, служебные тома и кворум). Скажем так, для FS1 с двумя томами данных у нас будет что-то вроде этого:

Диски
Корень точки монтирования: том 2 ГБ, назначенный как X:\
Объем данных 1: 2 ТБ, смонтированный как X:\FS1_VOL1
Объем данных 2: 2 ТБ, смонтированный как X:\FS1_VOL2

Акции
На каждом томе данных есть «базовая» папка для всех общих ресурсов, будь то групповые или пользовательские.
Для групповых акций: X:\FS1_VOL1\FS1_V1_SHARE и X:\FS1_V2_VOL2\FS1_V2_SHARE
Для общих ресурсов пользователей: X:\FS1_VOL1\FS1_V1_HOME и X:\FS1_V2_VOL2\FS1_V2_HOME

Затем они скрываются, чтобы создать эти 4 общих ресурса:

\\FS1.example.com\FS1_V1_SHARE$
\\FS1.example.com\FS1_V2_SHARE$
\\FS1.example.com\FS1_V1_HOME$
\\FS1.example.com\FS1_V2_HOME$

Внутри этих общих ресурсов может существовать любое количество папок пользователей или групп по мере необходимости.

\\FS1.example.com\FS1_V1_SHARE$\HR
\\FS1.example.com\FS1_V2_SHARE$\Engineering
\\FS1.example.com\FS1_V1_SHARE$\Finance
\\FS1.example.com\FS1_V2_SHARE$\ITOPS

\\FS1.example.com\FS1_V1_HOME$\John.Public
\\FS1.example.com\FS1_V2_HOME$\Barak.Obama
\\FS1.example.com\FS1_V1_HOME$\Stephen.Harper
\\FS1.example.com\FS1_V2_HOME$\Paul.Smith

DFS
Именно здесь происходит вся «магия» балансировки нагрузки.

Если у вас МНОГО общих ресурсов / пользователей, вам может понадобиться создать структуру папок в пространстве имен. Мы только что создали 26 папок верхнего уровня, от А до Я.

в SHARE пространство имен, вы затем создадите ссылки на свои общие ресурсы следующим образом:

\\example.com\SHARE\H\HR           =>  \\FS1.example.com\FS1_V1_SHARE$\HR
\\example.com\SHARE\E\Engineering  =>  \\FS1.example.com\FS1_V2_SHARE$\Engineering
\\example.com\SHARE\F\Finance      =>  \\FS1.example.com\FS1_V1_SHARE$\Finance
\\example.com\SHARE\I\ITOPS        =>  \\FS1.example.com\FS1_V2_SHARE$\ITOPS

И HOME пространство имен будет выглядеть так:

\\example.com\HOME\P\John.Public    =>  \\FS1.example.com\FS1_V1_HOME$\John.Public
\\example.com\HOME\O\Barak.Obama    =>  \\FS1.example.com\FS1_V2_HOME$\Barak.Obama
\\example.com\HOME\H\Stephen.Harper =>  \\FS1.example.com\FS1_V1_HOME$\Stephen.Harper
\\example.com\HOME\S\Paul.Smith     =>  \\FS1.example.com\FS1_V2_HOME$\Paul.Smith

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

В этом суть.

Это означает, что вам нужно создать ссылки DFS для каждый общий ресурс / пользователь но также дает вам бесконечную гибкость в том, где находятся ваши данные, при этом делая все, чтобы все они были в одном месте.