The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Посоветуйте вариант хранения данных"
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Оптимизация и Промышленные системы (Public)
Изначальное сообщение [ Отслеживать ]

"Посоветуйте вариант хранения данных"  
Сообщение от elfy email(ok) on 20-Сен-08, 22:32 
Здравствуйте!

Я администрирую студенческий Интернет-центр. Недавно поступило предложение реорганизовать систему доступа пользователей к домашним папкам и я столкнулся с проблемой выбора новой технологии.

Сетап:
50+ рабочих станций. На каждой свой винт, на винте --- своп, раздел под ядро и раздел для данных.
1 сервер с виртуальными подсерверами. Экспортирует NFS-root, по которому грузятся рабочие станции.

Задача:
Каждый пользователь (LDAP) имеет некую домашнюю папку, которая должна видеться с каждого компьютера. Физическое место под папку должно быть на некой рабочей станции, ибо сервер забит под завязку.

Предыдущий вариант:
Каждая рабочая станция хостит некое число пользователей. LDAP запись "помнит" кто где хостится. При входе в систему через сессионный скрипт PAM нужная директория с нужной рабочей станции подключается по NFS.

Проблемы:
1) Юзеры тупы, норовят перезапускать компы, выдергивать шнуры эзернета итд.
2) При поломке компьютера возникает нерабериха, где чья папка лежит, как восстанавливать итд.
3) Сессионный скрипт выходит очень хрупким, иногда вобще виснет, когда нужного компьютера нет в сети.
4) Никакой защиты данных от сгорания харда.

Теперишний вариант:
Рабочая станция экспортирует раздел для данных через ATA-over-Ethernet. Координирующий сервер собирает из всех хардов RAID-6 с 2-3 spare-devices. По рейду идет обычная ФС, все это экспортируется по NFS и монтируется каждой рабочей станцией.

Проблемы:
1) Все ходит через один сервер, в отличие от исходного варианта, где все компы грузились равномерно.
2) Требуется супер-оперативность восстановления упавших компьютеров.
3) Требуется жесткая синхронизация стартапа и шатдауна, это сложно достичь из-за человеческого фактора.

Уважаемые гуру, прошу меня отговорить от этой дурной затеи и посоветовать что то получше. Я слышал о GFS/Lustrefs, но по причине малой осведомленности в кластерах ничего не могу выбрать толком. Посоветуйте, что на ваш взгляд лучше использовать.

Высказать мнение | Ответить | Правка | Cообщить модератору

 Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Посоветуйте вариант хранения данных"  
Сообщение от ReSeT on 23-Сен-08, 12:57 
Сколько всего пользователей? порядок хотя бы - 10,100,1000?

Ну по хорошему - все пользовательские данные лучше класть на сервер, машины делать одинаковыми и перезаливать из образа при неполадках любыми подручными средствами - от dd и dump/restore до acronis.

Получаем:

1. Надежность хранения данных - бэкапите сервер и спокойны как удав.
2. Супероперативность восстановления - время восстановления машины = времени заливки из образа
3. Пофигу на стартап/шатдаун, поскольку данные пользователя на сервере лежат
4. Если там не огромные фотки/видео гоняется - на 50 пользователей хватит заштатного сервера с гигабиткой и скази подсистемой

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Посоветуйте вариант хранения данных"  
Сообщение от elfy email(ok) on 23-Сен-08, 13:22 
>[оверквотинг удален]
>- от dd и dump/restore до acronis.
>
>Получаем:
>
>1. Надежность хранения данных - бэкапите сервер и спокойны как удав.
>2. Супероперативность восстановления - время восстановления машины = времени заливки из образа
>
>3. Пофигу на стартап/шатдаун, поскольку данные пользователя на сервере лежат
>4. Если там не огромные фотки/видео гоняется - на 50 пользователей хватит
>заштатного сервера с гигабиткой и скази подсистемой

Спасибо! И вправду протуканил с числами. Пользователей около 2-3 тыс., рабочих станций 40. На сервере маловато места, учитывая что там крутится куча виртуалок, он забит почти под завязку. С другой стороны, суммарно доступно около 2 Тб против 100 Гб свободных на сервере. Каждому пользователю даем по 500 Мб, занятость неоднородная — у кого густо у кого пусто.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Посоветуйте вариант хранения данных"  
Сообщение от ReSeT on 23-Сен-08, 15:16 
Тогда сложнее все. Денег на нормальный файл-сервер я так понимаю никто не дает. В любом случае мое ИМХО - надо отделять мух от котлет: данные пользователя отделять от системы где он работает и сервера отделять от рабочих станций.

Рабочие станции не стоит рассматривать как "почти пустой винт, который можно вставить в сервер", а скорее как "система, способная дать отказ в любой момент и лишить всех данных"

Сделано конечно хитро у Вас - АТА-овер-IP и RAID6 и все такое... но что будет с данными, если скажем сгорит/дурканет/глюканет_питанием свитч, на котором сидят клиенты? когда к примеру все 40 машин, или пусть даже 20 из них вдруг окажутся недоступными рейду6?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Посоветуйте вариант хранения данных"  
Сообщение от elfy email(ok) on 24-Сен-08, 00:10 
>Тогда сложнее все. Денег на нормальный файл-сервер я так понимаю никто не
>дает. В любом случае мое ИМХО - надо отделять мух от
>котлет: данные пользователя отделять от системы где он работает и сервера
>отделять от рабочих станций.

Не имеем возможности. Как бы университет на это золотых монет точно не даст, такое.

>Рабочие станции не стоит рассматривать как "почти пустой винт, который можно вставить
>в сервер", а скорее как "система, способная дать отказ в любой
>момент и лишить всех данных"

Именно :( Потому вот такой вопрос. Ориентировочно — все машины работают, из них критически могут не работать одновременно три. Если будет исчезать часть нодов — обидно но терпимо.

>Сделано конечно хитро у Вас - АТА-овер-IP и RAID6 и все такое...
>но что будет с данными, если скажем сгорит/дурканет/глюканет_питанием свитч, на котором
>сидят клиенты? когда к примеру все 40 машин, или пусть даже
>20 из них вдруг окажутся недоступными рейду6?

Нет, это еще так не сделано. Именно по приведенным причинам — сыкотно рейд делать, да и скорость не впечатляет. Свич кстати один и если он накроется то можно обьявить глобальный пипец =)
Пока что система такая — в лдап одно поле кодирует хост на котором файлы, PAM при логине подключает нужную папку с нужного хоста по NFS. Как бы тоже не фонтан

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Посоветуйте вариант хранения данных"  
Сообщение от ReSeT on 24-Сен-08, 11:59 
Рейд по идее еще и ребилдится будет при пропадании винтов. А ребилдить 2 терабайта - занятие достаточно долгое даже на локальных винтах. Не говоря уже о том, что внезапное появление "аварийного" винта в рейде (пользователь вдруг снова врубил машину) - действие достаточно критическое для рейд-контроллера (я сужу по обычным, аппаратным контроллерам). Он офигел бы ребилдить данные, если студенты пару раз за час перегрузят машины.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "Посоветуйте вариант хранения данных"  
Сообщение от elfy email(ok) on 24-Сен-08, 16:30 
>Рейд по идее еще и ребилдится будет при пропадании винтов. А ребилдить
>2 терабайта - занятие достаточно долгое даже на локальных винтах. Не
>говоря уже о том, что внезапное появление "аварийного" винта в рейде
>(пользователь вдруг снова врубил машину) - действие достаточно критическое для рейд-контроллера
>(я сужу по обычным, аппаратным контроллерам). Он офигел бы ребилдить данные,
>если студенты пару раз за час перегрузят машины.

а если spare-устройства задействовать? Перегрузы бывают сравнительно редко, то есть теоретически может быть, но не будет. Хотя да, рейд не совсем то. А вобще бывает что то распределенное? Кто то советовал GlobalFS от RedHat, с ней кто-то работал?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру