Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 18
а почему файловый архив должен быть под управлением именно Windows?
ну конечно надежность такой конструкции не ахти, но в случаи жесткой экономии сгодится
ну конечно надежность такой конструкции не ахти, но в случаи жесткой экономии сгодится
Исторически так сложилось, но самое главное то что рейд собранный в Windows для Linux невиден. Сейчас стало попроще, Winwows 2003 находится в виртуальной машине, рейд отдельное блочное устройство — есть пространство для маневра. Вторая причина — права доступа к папкам внутри этого файлового хранилища выдаются администратором через контроллер домена не вставая с места.
Разве Samba не умеет acl?
Samba можно ввести в домен, для «шар» можно прописывать права в конфигурационном файле, но это сложность — администраторы обслуживающие организацию ориентированы на Windows, как сделать так чтобы они могли раздавать права на отдельные папки внутри Samba пользуясь только средствами Windows (также как для родных папок общего доступа Windows) я еще незнаю… Задача не возникала, но если это возможно буду рад совету, может удастся сдвинуть файловые хранилища в сторону Linux, не ломая для администраторов домена привычных операций в работе.
Прописывать каждый раз в конфигурационном файле новые правила доступа я конечно могу, но я не администратор домена а разработчик с опытом работы в *unix.
Прописывать каждый раз в конфигурационном файле новые правила доступа я конечно могу, но я не администратор домена а разработчик с опытом работы в *unix.
Последний раз когда я настраивал такое я использовал wins + Kerberos для авторизации на контроллере домена (который был на Windows 2008).
Еще нужно смотнировать файловую систему с параметром acl.
Вроде бы больше никаких манипуляций не понадобилось. Версия самбы 3.6.x.
Еще нужно смотнировать файловую систему с параметром acl.
Вроде бы больше никаких манипуляций не понадобилось. Версия самбы 3.6.x.
NTFS права доступа — основная причина, я полагаю.
А ещё из плюшек:
DFS (в случае с одним сервером не имеет смысла).
В свежих серверных операционках: BranchCache и дедупликация.
А ещё из плюшек:
DFS (в случае с одним сервером не имеет смысла).
В свежих серверных операционках: BranchCache и дедупликация.
b2ron
Вот здесь я с Вами не соглашусь.
1) Образ любой виртуальной машины можно в сжатые сроки перенести на любой другой Linux сервер и гостевая система даже не поймет что у неё изменился хост.
2) Нет ничего плохого в экономичности. Сокращенные ресурсы заставляют мозг работать и искать варианты, а не действовать по шаблону.
3) Программный рейд от mdadm для данного сервера наиболее подходит чем аппаратный, так как:
— не требуется сверх-высокая производительность;
— добавление каждого последующего винчестера на 3TB автоматически расширяет хранилище на тот же объем;
— массив можно безболезненно перенести на другой сервер.
ну конечно надежность такой конструкции не ахти, но в случаи жесткой экономии сгодится
Вот здесь я с Вами не соглашусь.
1) Образ любой виртуальной машины можно в сжатые сроки перенести на любой другой Linux сервер и гостевая система даже не поймет что у неё изменился хост.
2) Нет ничего плохого в экономичности. Сокращенные ресурсы заставляют мозг работать и искать варианты, а не действовать по шаблону.
3) Программный рейд от mdadm для данного сервера наиболее подходит чем аппаратный, так как:
— не требуется сверх-высокая производительность;
— добавление каждого последующего винчестера на 3TB автоматически расширяет хранилище на тот же объем;
— массив можно безболезненно перенести на другой сервер.
Да, удивительно, до чего можно додуматься в условиях ограниченных ресурсов. Такое ощущение, что это надо было сделать на необитаемом острове, где временно взять диски у кого-то, чтобы скопировать данные — негде. Ощущение спортиртивного администрирования. Если данные сжимаемые можно было бы еще поиграться с btrfs со включенным сжатием или, если нравятся массивы программные, то ZFS — это очень интересно и спортивно.
Один из ограничивающих ресурсов — время, а его было с 18:00 до 9:00 утра.
По правилам организации брать только со «склада» магазина, но оплата только по безналичному расчёту, что резко ограничивает оперативность. Если бы у меня лежал дома на полке абсолютно пустой диск на 3TB+ я бы конечно одолжил его «на время» и данная статья не была бы написана потому как не имела бы смысла.
ZFS для личного развития тестировал в OpenSolaris (буквально как только он появился), есть у него и плюсы и минусы. Недавно ZFS собрал «нативно» в ядро Linux (без fuse), но в боевых условиях я его использовать не буду.
Во-первых, нет подходящих задач. Во-вторых, то количество оперативной памяти которые потребляет ZFS (и которое нужно ему отдавать — так правильно и заложено архитектурой) я с большим удовольствием выделю для кеширования программного raid — выигрыш будет очевиден и виден невооруженным взглядом. Третье и последнее, с mdadm уже не один год, накопленный опыт и отточенные до автоматизма процедуры мониторинга и восстановления массивов позволяют спать спокойно.
По правилам организации брать только со «склада» магазина, но оплата только по безналичному расчёту, что резко ограничивает оперативность. Если бы у меня лежал дома на полке абсолютно пустой диск на 3TB+ я бы конечно одолжил его «на время» и данная статья не была бы написана потому как не имела бы смысла.
ZFS для личного развития тестировал в OpenSolaris (буквально как только он появился), есть у него и плюсы и минусы. Недавно ZFS собрал «нативно» в ядро Linux (без fuse), но в боевых условиях я его использовать не буду.
Во-первых, нет подходящих задач. Во-вторых, то количество оперативной памяти которые потребляет ZFS (и которое нужно ему отдавать — так правильно и заложено архитектурой) я с большим удовольствием выделю для кеширования программного raid — выигрыш будет очевиден и виден невооруженным взглядом. Третье и последнее, с mdadm уже не один год, накопленный опыт и отточенные до автоматизма процедуры мониторинга и восстановления массивов позволяют спать спокойно.
Адская схема для организации хранения данных.
Какова вероятность того что навернётся md3? Какова вероятность того что навернётся md4 в целом?
Рассуждения на тему надежности RAID5
Также я не завидую тому кто будет разбираться в данной схеме в случае поломки во время вашего отпуска/больничного/смены места работы.
Да, согласен, что ограниченный бюджет заставляет мозги думать, но он никак вас не оправдает в глазах того же руководства после фатального факапа.
Какова вероятность того что навернётся md3? Какова вероятность того что навернётся md4 в целом?
Рассуждения на тему надежности RAID5
Также я не завидую тому кто будет разбираться в данной схеме в случае поломки во время вашего отпуска/больничного/смены места работы.
2) Нет ничего плохого в экономичности. Сокращенные ресурсы заставляют мозг работать и искать варианты, а не действовать по шаблону.
Да, согласен, что ограниченный бюджет заставляет мозги думать, но он никак вас не оправдает в глазах того же руководства после фатального факапа.
Адская временная схема для хранения данных, только raid5 утром надежнее чем raid0 предыдущим вечером.
Вероятность того что md3 рассыпется из-за выхода одного из двух винчестеров 100%, вероятность того что после этого деградирует md4 — 100%, вероятность не успешного восстановления деградировавшего md4 — 50%.
Руководство поставили в известность и приложили счёт на два винчестера по 3TB, md3 должен исчезнуть а md4 стать raid6.
Собираюсь проверить схему по дополнительному ускорению восстановления данных, между восстанавливаемым диском и массивом ставится ssd диск для кеширования в режиме Write-Back, для дисков с которых восстанавливаются данные кеш в ОЗУ в режиме Read-Only с запретом индексирования последовательного чтения. По теории все упирается в скорость записи на восстанавливаемый диск, при том что с источников ведется последовательное чтение, но это чтение нарушается запросами на доступ к данным от клиентов, поэтому их запросы и закешируем. Возможно рано написал я еще не проверил в какой последовательности считываются данные с дисков иссточников…
p.s. А в отпуск уже много лет только со связью и компьютером, в стародавние времена gprs модем выдавался.
Вероятность того что md3 рассыпется из-за выхода одного из двух винчестеров 100%, вероятность того что после этого деградирует md4 — 100%, вероятность не успешного восстановления деградировавшего md4 — 50%.
Руководство поставили в известность и приложили счёт на два винчестера по 3TB, md3 должен исчезнуть а md4 стать raid6.
Собираюсь проверить схему по дополнительному ускорению восстановления данных, между восстанавливаемым диском и массивом ставится ssd диск для кеширования в режиме Write-Back, для дисков с которых восстанавливаются данные кеш в ОЗУ в режиме Read-Only с запретом индексирования последовательного чтения. По теории все упирается в скорость записи на восстанавливаемый диск, при том что с источников ведется последовательное чтение, но это чтение нарушается запросами на доступ к данным от клиентов, поэтому их запросы и закешируем. Возможно рано написал я еще не проверил в какой последовательности считываются данные с дисков иссточников…
p.s. А в отпуск уже много лет только со связью и компьютером, в стародавние времена gprs модем выдавался.
Какой-то чудовищное описание «как влезть на ёлку и при этом не ободраться».
В нормальном системном администрировании так не делается, сама предпосылка была неправильная.
В нормальном системном администрировании так не делается, сама предпосылка была неправильная.
Согласен, но мы живем в реальном мире, а он далёк от нормальности и порой приходится крутиться.
Извините, но не в случае миграции ценных данных. Цена вопроса дополнительных HDD существенно меньше стоимости информации на ней, количество шагов, на которых можно было ошибиться и/или потерять данных, слишком велико. Я бы ещё понял, если бы это были редкие/дорогие винты, но обычнейшие SATA!
Dyr, видимо мы «избалованны» продакшеном и бюджетами.
StepanTomsk, Реальный мир таков, что обычно право руководство. И сколько бы бумажек не напиши, крайним будет технический исполнитель, потому как не настоял на своём решение.
Искренне надеюсь что у вас это не так.
StepanTomsk, Реальный мир таков, что обычно право руководство. И сколько бы бумажек не напиши, крайним будет технический исполнитель, потому как не настоял на своём решение.
Искренне надеюсь что у вас это не так.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Программные рейды: миграция с Windows raid0 на Linux mdadm raid5