Какое решение стоит использовать в данном случае для построения файлового сервера?

Question

[Евгений Ферапонтов]

Необходимо сделать файловое хранилище для бекапов, рабочих данных и roaming profiles с redirected folders пользователей с фермы терминальных серверов, данных WSUS, WDS. Большой производительности не требуется, поэтому никаких дисковых полок не планируется. Вся серверная инфраструктура базируется на нескольких хостах hyper-v, было бы неплохо и файловые сервера в нее вписать.
Чего хочется:

• Катастрофоустойчивость (при выходе из строя одного узла второй должен содержать точную копию, со всеми разрешениями NTFS и прочим)
  
• Масштабируемость решения
  

Короче говоря, хочется этакого RAID 1 из файловых серверов. Сначала планировалось под эти нужды развернуть DFS из нескольких узлов, но для перемещаемых профилей пользователей такое решение не самая лучшая идея. С файловыми кластерами не знаком, но, если я правильно понял, оно подразумевает единое хранилище на несколько узлов -- такое нам не надо.
Какие еще есть варианты?

Comments

[Александр Никитин]

Без общего хранилища никак. У Майков нет таких технологий для файлового sharing nothing, на сколько мне известно. Единственная технология что приходит в голову - это поднять на двух физических серверах Hyper-V 3.0 и в них уже поднимать файловый север с репликацией на соседа. Но это скорее отказоустойчивость, производительности это не даст - так как реплика будет потушена и поднять ее можно только в случае выхода из строя оригинала.

[Евгений Ферапонтов]

@padla2k: Тогда я вообще не понимаю смысла кластеризации. Если у меня, допустим, высоконагруженный SQL заставляет диски на износ пахать, а он является бэкэндом для какого-нибудь критического компонента бизнеса, как мне кластеризация в этой ситуации поможет? Ну будет он харды на дисковой полке изнашивать, а не внутри сервера -- все равно он их убьет. Надеяться на бэкапы и скорость их раскатывания в случае отказа? Нафиг вообще кластеризация нужна, если вместо одной точки отказа (сервер) мы получаем ОДНУ ТОЧКУ ОТКАЗА (SAN)?
Да ну к черту такие высокие технологии. Пойду шаманить с DFSR без DFS или просто выбивать из начальства бабло на отдельный сервер для файлов.

[Александр Никитин]

@e1ferapontov: Вообще то SAN содержит собственные средства как отказоустойчивости (RAID) так и катастрофоустойчивости (SAN Replica). Сама SAN не может быть одной точкой отказа - там задублировано должно быть все. Суть кластеризации на уровне сервера в том что бы обеспечить устойчивую к отказу (возвращение сервиса к работе с минимальным простоем) или даже отказоустойчивую (переключение на другой сервер при отказе основного) конфигурацию. Как сейчас видит Майкрософт отказоустойчивость в части хранилищ - это либо классическая SAN и ресурсы хранилища подключены к серверам по FC, FCoE или iSCSI, либо это полки подключенные напрямую к серверам (JBOD) и организация отказоустойчивости там возлагается на Storage Spaces, где вы можете выбрать надежность хранения и принцип организации виртуальных LUN (тонкие/толстые).

Answer 1

[alexk24]

Не уверен что подойдет, но посмотрите в сторону DFS
Еще вариант посмотреть на решение от Starwind

Answer 2

[anton1234]

DFS replication позволит иметь копию. Актуальность будет зависеть от объема записываемых данных и скорости обмена между серверами DFS.
Лучшее, что можно сделать с DFS это один активный сервер и любое количество серверов в холодном резерве.
Доступ к данным организовать можно через dfs namespaces либо использовать общий алиас в dns. В случае аварии меняете запись, а клиенты ничего не заметив будут уже работать с резервным сервером.
Ничего лучше я не знаю. Основная проблема в контроле одновременной записи одного файла на разных серверах. Блокировок нет. Более новый перезапишет себя на оба сервера.

Comments

[Евгений Ферапонтов]

>Лучшее, что можно сделать с DFS это один активный сервер и любое количество серверов в холодном резерве.
That's it! Я ведь правильно понимаю, что все взаимодействие клиентов будет происходить с primary member'ом, а холодный резерв будет только перетягивать данные по расписанию? Если так, то именно этим и воспользуюсь, пожалуй.