SAS, балансирующийся по сравнению с Сетевой балансировкой
Я хочу к серверу файла конфигурации в среде R2 Сервера MS Windows 2012 года, которая загрузила бы трафик баланса.
У меня есть дисковый массив SAS с 2 контроллерами SAS, который подключен к 2 кластерным узлам Hyper-V 4 избыточными мультипутями SAS:
controller1 <-> node1, controller1 <-> node2,
controller2 <-> node1, controller2 <-> node2.
Я не знаю, было ли выравнивание нагрузки SAS noticable, если я НЕ сбалансирую сеть, что означает, это всего, один сервер в сети обработал бы все запросы файлового ввода-вывода. Суммирующая схема, кажется, является сложной, потому что я не хочу иметь 2 файловых сервера с идентичной копией данных (дублирование гарантируется на уровне RAID дискового массива). То, что я хочу, является одним набором разделения данных к двум непересекающимся объемам, каждому на отдельном файловом сервере (каждый виртуальный сервер на одном узле кластера), который действовал бы как единственный сервер или доля SMB.
Пользователь shloudn't знает, какие данные находятся на сервере A или B, путь SMB должен быть чем-то как \\domain.com\home\username или \\domain.com\share\department и дома или отделы должны быть распределены через два сервера (например, те, которые запускаются с "A-P" на первом и остальных на втором).
У меня есть центральный переключатель ядра сети, и каждый кластерный узел имеет агрегированный канал на 5 ГБ/с к нему. Остальная часть сети подключена к этому переключателю (каждый коммутатор доступа подключен ссылкой на 2 ГБ/с, клиенты соединены ссылкой на 1 ГБ/с).
Мои вопросы:
- Если бы я не делаю балансировки сетевой нагрузки и сохраняю выравнивание нагрузки SAS, выравнивание нагрузки SAS было бы примечательно или нет?
- Там некоторая сетевая нагрузка балансирует кластеризирующуюся технику, которой я достиг бы упомянутых результатов?
- Я знаю, что существует много факторов, который зависит от определенной ситуации (такой как максимальное количество одновременных соединений или частота отдельных, возможно короткие соединения; являются ли операции чтения доминирующими и т.д. и т.д.), но есть ли какие-либо общие лучшие практики, которые я должен уважать?
- Не является самым легким (и возможно лучший) способ не сделать, загрузка балансирует что-нибудь и имеет простое управление?
Править:
Большое спасибо! На самом деле DFS был одним из первых, думают, что я искал, но я закончил с результатом, который, что я хочу, невозможен с DFS.
После проигрывания с ним некоторое время, я имею после configration:
Одно пространство имен DFS ДОМОЙ, оба файловых сервера, добавленные к нему как пространство имен серверы, таким образом, на каждом существует доля, названная "домой" физически под "C:\DFSRoots\home". На каждом сервере также имеют скрытую основную совместно используемую папку, названную "home$", физически помещенным в дисковый массив. В скрытой доле первого сервера я вижу одну половину ДОМОВ на другой остальной части ДОМОВ. В домашней доле DFS (обоих серверов) я вижу только ссылки (распределенный скрытым долям), но всем ДОМАМ.
Когда клиент связывается с корнем (\domain.com\root), один из серверов пространства имен DFS отвечает клиенту. В моей ситуации это всегда - тот же сервер, потому что у меня есть только один сайт. Но это не имеет значения, потому что это только перечисляет содержание корня DFS. Когда затем клиент перешел к одной из перечисленных ссылок, DFS estabilishes соединение с целью скрытой папки, которая является одним из серверов, таким образом выравнивание нагрузки выполняется.
Эта конфигурация корректна, оптимальна?
И последний вопрос: Сколько быстрее SAS обычно по сравнению с LAN (например, 5GB/s агрегированный LACP)?
Вам действительно стоит посмотреть на Microsoft DFS, чтобы сделать то, о чем вы говорите.
Она предоставляет способ абстрагировать физическое расположение данных, объединяя все в одном месте.
Так, например, у вас будет:
- 2 кластерных узла (FSCL1, FSCL2)
- 2 кластерных файловых сервиса (FS1, FS2), работающих на вышеуказанных узлах
- 2 доменных пространствах имен DFS (HOMES, SHARES), размещенных на вышеуказанных узлах
Каждая файловая служба может иметь любое количество разделяемых файлов, и вы просто создаете ссылки в DFS для них по мере необходимости.
Вот как это установка, где я работаю. Может, это и не самая лучшая вещь, но она очень функциональна для нас.
Наши пространства имен размещаются за пределами выделенных серверов, но это не является обязательным требованием. Это просто означает, что у нас нет столкновений имен между разделяемыми и целевыми ресурсами DFS.
На наших файловых серверах (FS1, FS2 и т.д...) мы используем точки монтирования для томов данных, потому что в противном случае мы бы запускали буквы (~28 томов данных, ~7 корней точек монтирования, томов утилит и кворум). Скажем так, для FS1, с 2 томами данных, у нас было бы что-то вроде этого:
Диски
Mount Point root: 2 Гб том, установленный как X:\
Объём данных 1: 2 Тб, установленный как X: \FS1_VOL1
Объем данных 2: 2 ТБ, установленный как X:\FS1_VOL2
Shares
На каждом томе данных есть "базовая" папка для всех общих папок, групповых или пользовательских.
Для групповых акций: 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 папок верхнего уровня, A-Z.
В пространстве имен 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 связи для каждого отдельного ресурса/пользователя, но также дает вам бесконечную гибкость в том, где находятся ваши данные, при этом все они находятся в одном и том же месте.
.