Elite Games - Свобода среди звезд!
.
  » RAID | страница 9
Конференция предназначена для общения пилотов. Для удобства она разделена на каналы, каждый из которых посвящен определенной игре. Пожалуйста, открывайте темы только в соответствующих каналах и после того, как убедитесь, что данный вопрос не обсуждался ранее.

Поиск | Правила конференции | Фотоальбом | Регистрация | Список пилотов | Профиль | Войти и проверить личные сообщения | Вход

   Страница 9 из 11
На страницу: Пред.  1, 2, 3 ... 8, 9, 10, 11  След.    Перейти:   Все страницы
Поиск в этой теме:
Железный канал: «RAID»
Lars
 440 EGP


Суровый помор
Рейтинг канала: 6(253)
Репутация: 77
Сообщения: 2450
Откуда: Архангельск
Зарегистрирован: 28.03.2007
Чаще всего для построения RAID 5+1 используют два контроллера RAID 5, которые зеркалируют на программном уровне, что позволяет снизить затраты.
_________________
"Мозги... нам нужны мозги!"(с) "Живые мертвецы"
    Добавлено: 13:48 30-09-2008   
Lars
 440 EGP


Суровый помор
Рейтинг канала: 6(253)
Репутация: 77
Сообщения: 2450
Откуда: Архангельск
Зарегистрирован: 28.03.2007
Так железо еще не купили?
_________________
"Мозги... нам нужны мозги!"(с) "Живые мертвецы"
    Добавлено: 21:19 30-09-2008   
бухой джедай
 151 EGP


Рейтинг канала: 4(87)
Репутация: 67
Сообщения: 7879 Предупреждений: 1
Откуда: Одесса:)
Зарегистрирован: 08.09.2007
http://forum.ru-board.com/topic.cgi?forum=62&topic=11959#1

может чемтопоможет

добавлено спустя 1 минуту:
http://forum.ru-board.com/topic.cgi?forum=84&topic=0135&start=520#2

и это
_________________
Так Добрый вечер...Превед с большого Бодуна...
Магистр Непросыхаемость...
Злобный Рецедивист...

Последний раз редактировалось: бухой джедай (22:46 30-09-2008), всего редактировалось 1 раз
    Добавлено: 22:46 30-09-2008   
NucleaR
 960 EGP


Администратор
Рейтинг канала: 5(131)
Репутация: 226
Сообщения: 2990
Откуда: MSK
Зарегистрирован: 08.12.2003
ф. Не слушай их, они тебе немного другой уровень рассказывают. я ща тоже набил большой текст но стер ибо не знаю как фибра работает. Лучше погугли и задай вопрос на какомнить спецфоруме типа http://forum.ixbt.com/?id=66

Погуглил чучуть, вот что в результате появилось:
1. для того чтобы два САНа и два сервера между собой работали нужен FC коммутатор (по идее)
2. КАК из двух пятерок делать единичку - хз, возможно надо смотреть коммутаторы которые это умеют (если такое возможно)

и от себя - почему именно пятые рейды? ониж тормоза, не лучше ли собрать в одном кузове десятку?

ЗЫ всеж лучше подождать спецов, которые знают точно что именно с твоим оборудованием делать. я так, дал только направления для похода в гугл Подмигиваю
_________________
it's nice to be important but it's more important to be nice
    Добавлено: 23:59 30-09-2008   
Star'ik
 325 EGP


Рейтинг канала: 3(48)
Репутация: 71
Сообщения: 1878
Откуда: Msk
Зарегистрирован: 29.04.2003
Э... А нафига, собственно, такой геморрой? RAID5 - это 1 xor 2 -> 3, а RAID 1 - 1 -> 2. В первом случае, если вылетит адын винт, собственно как и во втором случае, система будет жить. Если 5+1, то, получается, может умереть уже сколько угодно винтов в одном из контроллеров. Т.е. типа расчет на атомную войну? Если данные так важны, то гораздо эффективнее полнять репликационный сервачок, или просто производить копирование на внешний HDD (или на 10 внешних HDD, находящихся в разых уголках планеты). Но два сервера будут гораздо более эффективны, чем суперстабильная дисковая подсистема, которая, как и любая другая подсистема, может умереть.
_________________
Все хорошее когда-нибудь кончается
    Добавлено: 23:16 02-10-2008   
Falcon
 290 EGP


Ангел с прибором
Рейтинг канала: 3(29)
Репутация: 140
Сообщения: 6138
Откуда: КУЙ С НАМИ
Зарегистрирован: 07.02.2001
Star'ik :
А нафига,

вы читали задание?
_________________
7ШJ
    Добавлено: 13:49 03-10-2008   
Falcon
 290 EGP


Ангел с прибором
Рейтинг канала: 3(29)
Репутация: 140
Сообщения: 6138
Откуда: КУЙ С НАМИ
Зарегистрирован: 07.02.2001
я же вчера сказал - спасибо всем - тему можно закрыть ибо решение найдено
_________________
7ШJ
    Добавлено: 14:59 03-10-2008   
aftermath
 685 EGP


Рейтинг канала: 2(16)
Репутация: 234
Сообщения: 1315
Откуда: Нижний Новгород
Зарегистрирован: 07.04.2006
Гуру, подскажите.

Мамка Gigabyte P35-DS4, харды висят на интеловом контроллер, в биосе был включен режим AHCI и поставлена винда Vista SP1 64bit. Поставлена заботливо, кропотливо, долго, плюс куча софта и его настройки - убита уйма времени.

Стрельнуло сейчас махнуть неоправдавший надежд VelociRaptor на нулевой рейд из пары хардов. Жутко не хочется переставлять винду. Даже времени на это реально нет, да и просто жалко.

Как бы это дело перенести?

Проблема в том, что переключение режима с AHCI в RAID сразу приводит к "синьке" при загрузке висты Расстроен Поэтому даже перенос данных, с которым все более-менее понятно (думаю, акронис или гост справится из-под винды...), не решит проблемы неработоспособности винды. С XP вроде таких проблем не было. Если бы наоборот надо было включить AHCI, там все просто, а тут...

Никто не сталкивался?

Обобщая эту кашу, вопрос - как победить "синий" экран в висте при отключении режима AHCI?

Заранее благодарен Улыбка
_________________
В темном мире нет любви.
И в груди пусты сердца... (c)
    Добавлено: 22:35 24-10-2008   
Rept-Tile
 150 EGP


Рейтинг канала: 3(38)
Репутация: 55
Сообщения: 240
Откуда: Москва
Зарегистрирован: 08.11.2007
Не знаю, хватит ли у меня самого время для участия в этой дискуссии, но все же попробую закинуть удочку. Ибо народ здесь собрался пытливый, а лично для меня тема однозначного решения не имеет.

Перед ответом очень рекомендую ознакомиться с мнениями в одном флуд-топике на хоботах:
Сцылка
Дабы избежать экскурсии по пройденным другими граблям. Подмигиваю

Итак, дополнительно к вопросам в заголовке опроса (просьба аргументировать свой ответ):
Известны ли вам и применялись ли на практике с анализом результата дефрагментаторы для NTFS, способные при дефрагментации:
А) учитывать архитектуру конкретного дефрагментируемого массива RAID?
Б) при этом учитывать еще и то, что LUN может быть как соответствовать физическому RAID, так и разделять его с другими LUNами?
В) проводить анализ реально используемого режима доступа к файлам и проводить дефрагментацию на основании этого анализа?

Если есть примеры или ссылки на тесты, убедительно показывающие последствия грамотной дефрагментации различных уровней RAID на конкретных серверах - it's strongly welcomed, как говорится. Улыбка
    Добавлено: 21:36 24-02-2009   
Voha
 887 EGP


Модератор
Рейтинг канала: 8(875)
Репутация: 165
Сообщения: 4650
Откуда: Moscow, Russia
Зарегистрирован: 15.02.2001
Ответ: пофигу, ибо эффекта не будет никакого
99% дисковых операций в системах, построенных на любом типе RAID - random read и random/linear write. При таком типе дисковой активности распределение данных по диску не оказывает заметного влияния на скорость доступа.
Если активность специфическая, типа linear read - то ее оборотная сторона в тех же 99% случаев linear write, и файло само по себе нефрагментировано.
Печаль приходит, когда в таком нестандартном варианте идет запись на заполненный более, чем на 90% NTFS раздел. Писать будет тормозно и как попало - но это эффект алгоритмов работы файловой системы, в таком состоянии линейная запись будет на самом деле случайной. Полечить такой разброд, заставив выполнить запись линейно с точки зрения рэйда, сможет любой дефрагментатор, умеющий работать пофайлово (т.е. запись "дефрагментированного" файла происходит всегда полным файлом от начала до конца, а не перемещением кусочков файла так, что для системы он потом попадает в последовательную цепочку логических секторов).
_________________
Time will show...
    Добавлено: 22:37 24-02-2009   
Rept-Tile
 150 EGP


Рейтинг канала: 3(38)
Репутация: 55
Сообщения: 240
Откуда: Москва
Зарегистрирован: 08.11.2007
Voha :
99% дисковых операций в системах, построенных на любом типе RAID - random read и random/linear write
Не согласен. В промышленных системах периодически имеют место мощные операции линейного чтения - например, Full Backup БД. Время на выполнение бэкапа в отдаленной перспективе - тоже не пустой звук при проектировании систем.
Voha :
Если активность специфическая, типа linear read - то ее оборотная сторона в тех же 99% случаев linear write, и файло само по себе нефрагментировано.
Не согласен с выводом. Если большое файло пишется на уже фрагментированный FreeSpace (например, при выборочном удалении большого кол-ва мелких файлов перед этим) - то и линейная запись приведет к фрагментации. Это азбука дефрагментации.

добавлено спустя 10 минут:
Voha :
Печаль приходит, когда в таком нестандартном варианте идет запись на заполненный более, чем на 90% NTFS раздел. Писать будет тормозно и как попало - но это эффект алгоритмов работы файловой системы, в таком состоянии линейная запись будет на самом деле случайной. Полечить такой разброд, заставив выполнить запись линейно с точки зрения рэйда, сможет любой дефрагментатор, умеющий работать пофайлово (т.е. запись "дефрагментированного" файла происходит всегда полным файлом от начала до конца, а не перемещением кусочков файла так, что для системы он потом попадает в последовательную цепочку логических секторов).
А вот тут уже начинается самое интересное. Именно от архитектуры конкретного RAID зависит, к какому расположению данных приведет работа "плоского" дефрагментатора. На зеркале это будет одно физическое расположение кусков, на RAID5,6 - совсем другое. Имхо, без анализа того, как в среднем будет осуществляться последующий доступ к "дефрагментированным" файлам, простому дефрагментатору доверяться нельзя.
Если несложно - проставь-таки свое мнение в виде варианта.

Последний раз редактировалось: Rept-Tile (00:27 25-02-2009), всего редактировалось 3 раз(а)
    Добавлено: 00:26 25-02-2009   
Voha
 887 EGP


Модератор
Рейтинг канала: 8(875)
Репутация: 165
Сообщения: 4650
Откуда: Moscow, Russia
Зарегистрирован: 15.02.2001
Rept-Tile :
Voha :
99% дисковых операций в системах, построенных на любом типе RAID - random read и random/linear write
Не согласен. В промышленных системах периодически имеют место мощные операции линейного чтения - например, Full Backup БД. Время на выполнение бэкапа в отдаленной перспективе - тоже не пустой звук при проектировании систем.
Если на этапе проектирования архитектуры кто-то прошелся кривыми руками - выпрямлять полученный эффект дефрагментацией бесполезно...
В промышленных системах с нагрузкой 24х7 бакап БД происходит непрерывно - ибо [множественная] репликация. Если ГОСТ требует бакапа на внешний носитель для укладки в сейф - то этот бакап делается с остановленной реплики. При этом на реплике ничего, кроме БД не живет - и портить диск фрагментацией там некому.
Если БД маленькая и кривенькая, и денег на железку для реплики жалко - даже тогда ее можно вынести на отдельный дисковый массив, портить который фрагментацией будет опять же некому.
Rept-Tile :
Voha :
Если активность специфическая, типа linear read - то ее оборотная сторона в тех же 99% случаев linear write, и файло само по себе нефрагментировано.
Не согласен с выводом. Если большое файло пишется на уже фрагментированный FreeSpace (например, при выборочном удалении большого кол-ва мелких файлов перед этим) - то и линейная запись приведет к фрагментации. Это азбука дефрагментации.
Кто бы еще мне рассказал, как на системе с преимущественной дисковой активностью "линейная запись" образуется много маленького файла, которое вдруг пришлось удалить. 1С не предлагать, ибо даже в этой ублюдочной системе можно в качестве бэкэнда использовать нормальный сервер БД, а не пофайловую помойку (см. чуть выше про этап проектирования).

Rept-Tile :
Voha :
Печаль приходит, когда в таком нестандартном варианте идет запись на заполненный более, чем на 90% NTFS раздел. Писать будет тормозно и как попало - но это эффект алгоритмов работы файловой системы, в таком состоянии линейная запись будет на самом деле случайной. Полечить такой разброд, заставив выполнить запись линейно с точки зрения рэйда, сможет любой дефрагментатор, умеющий работать пофайлово (т.е. запись "дефрагментированного" файла происходит всегда полным файлом от начала до конца, а не перемещением кусочков файла так, что для системы он потом попадает в последовательную цепочку логических секторов).
А вот тут уже начинается самое интересное. Именно от архитектуры конкретного RAID зависит, к какому расположению данных приведет работа "плоского" дефрагментатора. На зеркале это будет одно физическое расположение кусков, на RAID5,6 - совсем другое. Имхо, без анализа того, как в среднем будет осуществляться последующий доступ к "дефрагментированным" файлам, простому дефрагментатору доверяться нельзя.
А физическое размещение данных по носителям рейда никого не волнует. Достаточно знать, что при записи и чтении используется один и тот же алгоритм позиционирования. И если запись линейна - то чтение будет таким же "линейным", с точностью до длинны буфера контроллера, где он будет склеивать одновременно читаемые с разных носителей куски и потом отплевывать этот буфер в систему.
Rept-Tile :
Если несложно - проставь-таки свое мнение в виде варианта.
Варианта ответа "дефрагментация никак не влияет на скорость доступа к данным в системе с правильной архитектурой" в опросе нет. Задавшись целью, можно построить синтетическую систему, для которой [де]фрагментация данных на RAID даст заметное влияние на производительность - но для этого нужно сильно напрягаться и окончательно похоронить в себе остатки здравого смысла.
_________________
Time will show...
    Добавлено: 10:36 25-02-2009   
Rept-Tile
 150 EGP


Рейтинг канала: 3(38)
Репутация: 55
Сообщения: 240
Откуда: Москва
Зарегистрирован: 08.11.2007
Voha :
В промышленных системах с нагрузкой 24х7 бакап БД происходит непрерывно - ибо [множественная] репликация. Если ГОСТ требует бакапа на внешний носитель для укладки в сейф - то этот бакап делается с остановленной реплики.
В реальной жизни - далеко не всегда, есть множество других рабочих сценариев.
Voha :
При этом на реплике ничего, кроме БД не живет - и портить диск фрагментацией там некому.
БД может быть не одна и не две на одном диске - вполне рабочая ситуация в случае дефицита железа при высоком уровне SLA. Думаю, здесь нет смысла рассматривать огрехи или ограничения других уровней проектирования. Вопрос в том, может ли помогать конкретно дефрагментация при определенных условиях. И какой она для этого должна быть.
Voha :
Кто бы еще мне рассказал, как на системе с преимущественной дисковой активностью "линейная запись" образуется много маленького файла. 1С не предлагать

Пример из рабочей практики - логи Exchange. (Не смешиваем с тем, что написано выше, там имеется в виду другая ситуация.)

Думаю, нам сейчас нет смысла спускаться глубоко в частности. Опрос пока что лишь общего плана, хочется знать мнения людей, которые задумывались на данную тему.
Voha :
А физическое размещение данных по носителям рейда никого не волнует. Достаточно знать, что при записи и чтении используется один и тот же алгоритм позиционирования. И если запись линейна - то чтение будет таким же "линейным", с точностью до длинны буфера контроллера, где он будет склеивать одновременно читаемые с разных носителей куски и потом отплевывать этот буфер в систему.
Вот как раз это и волнует - что происходит с позиционированием, т.е. за пределами алгоритмов оптимизации контроллера. Традиционно принято ими отгораживаться, как барьером. Но по моему убеждению, при сильном уровне фрагментации потери на неоптимальное позиционирование теоретически могут достичь такого уровня, что никакая оптимизация не поможет. Вот тут и хотелось бы услышать о практике (замеры производительности до и после дефрагментации).
Voha :
Задавшись целью, можно построить синтетическую систему, для которой [де]фрагментация данных на RAID даст заметное влияние на производительность - но для этого нужно сильно напрягаться и окончательно похоронить в себе остатки здравого смысла.
Вот это и произошло в процитированной ветке топика на хоботах - потеря нити здравого смысла из-за страха перед сложностью задачи. Улыбка Есть желание в этом разобраться.

С одной стороны - присутствуют громкие маркетинговые заявления в документации по DisKeeper (пример), Raxco (пример), Paragon и других менее известных, утверждающих, что дефрагментация на рейдах необходима, но обосновывающих это лишь общими словами и не раскрывающими технологию "поддержки RAID" своими продуктами.

С другой - соображения, которые я попытался привести.

Суммарно - хочется попробовать докопаться до истины, а для этого нужна прежде всего практика - тесты, тесты и еще раз тесты. Причем скрупулезные, учитывающие много условий.
Voha :
Варианта ответа "дефрагментация никак не влияет на скорость доступа к данным в системе с правильной архитектурой" в опросе нет.
Есть - это вариант "Не нужна".

Последний раз редактировалось: Rept-Tile (11:37 25-02-2009), всего редактировалось 1 раз
    Добавлено: 11:34 25-02-2009   
Voha
 887 EGP


Модератор
Рейтинг канала: 8(875)
Репутация: 165
Сообщения: 4650
Откуда: Moscow, Russia
Зарегистрирован: 15.02.2001
Rept-Tile :
Вот как раз это и волнует - что происходит с позиционированием, т.е. за пределами алгоритмов оптимизации контроллера. Традиционно принято ими отгораживаться, как барьером. Но по моему убеждению, при сильном уровне фрагментации потери на неоптимальное позиционирование теоретически могут достичь такого уровня, что никакая оптимизация не поможет. Вот тут и хотелось бы услышать о практике (замеры производительности до и после дефрагментации).
Не надо трогать то, что делает хардварный контроллер. Потому что последствия грустные всегда бывают. Когда мне покажут дефраг, умеющий выключить 4-й диск из 10 в HW-RAID5 или 10 - я поверю, что дефраги научились понимать хардварные рейды. Ну или хотя бы в своих рекламках начнут давать список поддерживаемых контроллеров вместо красивого слова RAID Улыбка Особливо забавляет рекламируемая "дефрагментация" подключенных по i-SCSI устройств. Они бы еше NFS-тома дефрагментить взялись...
Тесты для 4-х штук Barracuda ES.2 ST31000640SS в RAID0 в полке М1000 через НР-шный контроллер говорят, что на BS=16Мб скорость линейного и случайного чтения отличаются в два раза (120 и 60)
На BS<=4кб - линейное чтение в 50 раз быстрее случайного (120 и 2.5 Мб/сек). Ну и перекрестно - случайное на BS=16М в 25 раз быстрее случайного на 4К (зависимость экспоненциальная, на BS=1M скорость случайного чтения 20Мб/сек

Все зависит от режимов чтения... Если доступ мелкими кусочками - то пофиг на фрагментацию. Если крупными кусочками - сделай так, чтоб квант фрагментации был больше размера кусочка - и эффект будет незаметен. Придумать систему, которая сначала нашинкует данные кусками по 4кб. а потом будет их читать по 16 мегов - мне сложно...
_________________
Time will show...
    Добавлено: 13:05 25-02-2009   
Rept-Tile
 150 EGP


Рейтинг канала: 3(38)
Репутация: 55
Сообщения: 240
Откуда: Москва
Зарегистрирован: 08.11.2007
Voha :
Не надо трогать то, что делает хардварный контроллер. Потому что последствия грустные всегда бывают.
Потому что а) стандарты для этого пока отсутствуют б) сложно ...
Это.. флуд, универсальные рецепты и их опровержения - дело, конечно, тоже нужное. Улыбка Но лучше в личке или в отдельной теме. А то народ совсем зашугается, а мне бы еще мнений набрать хотелось.. Подмигиваю
    Добавлено: 13:21 25-02-2009   
Lars
 440 EGP


Суровый помор
Рейтинг канала: 6(253)
Репутация: 77
Сообщения: 2450
Откуда: Архангельск
Зарегистрирован: 28.03.2007
По моему, в общем случае, не нужна т.к. хардварный контроллер все равно запишет файлы как ему хочется
_________________
"Мозги... нам нужны мозги!"(с) "Живые мертвецы"
    Добавлено: 22:56 26-02-2009   
Rept-Tile
 150 EGP


Рейтинг канала: 3(38)
Репутация: 55
Сообщения: 240
Откуда: Москва
Зарегистрирован: 08.11.2007
Lars :
хардварный контроллер все равно запишет файлы как ему хочется
О том-то и речь, в общем-то - не появился ли уже софт, который может заставить его записать так, как нужно? Чтобы использовать это в целях "умной" дефрагментации. Или потенциальная возможность создания такого софта на сегодняшнем уровне технологий.
Ну и прочти 2 ссылки на документацию от DisKeeper и PerfectDisk, которые я приводил чуть выше. Не в целях склонения на свою сторону, а для просвещения по теме. В них, в частности, утверждается в один голос, что даже планарная (обычная) дефрагментация RAID-а (как обычного диска) полезна, в плане оптимизации использования ресурсов ЦПУ и памяти.
    Добавлено: 00:47 27-02-2009   
Lars
 440 EGP


Суровый помор
Рейтинг канала: 6(253)
Репутация: 77
Сообщения: 2450
Откуда: Архангельск
Зарегистрирован: 28.03.2007
Rept-Tile :
В них, в частности, утверждается в один голос, что даже планарная (обычная) дефрагментация RAID-а (как обычного диска) полезна, в плане оптимизации использования ресурсов ЦПУ и памяти.
Для RAID 1 и ему подобных может и полезно, для остальных пустая трата времени т.к. дефрагментаторов умеющих указывать контроллеру как и куда писать файлы я не встречал.
Сегодняшние технологии это реализовать могут, но на начальном этапе это будет контроллер + заточенный под него дефрагментатор
_________________
"Мозги... нам нужны мозги!"(с) "Живые мертвецы"

Последний раз редактировалось: Lars (15:06 27-02-2009), всего редактировалось 1 раз
    Добавлено: 11:44 27-02-2009   
Voha
 887 EGP


Модератор
Рейтинг канала: 8(875)
Репутация: 165
Сообщения: 4650
Откуда: Moscow, Russia
Зарегистрирован: 15.02.2001
Rept-Tile :
В них, в частности, утверждается в один голос, что даже планарная (обычная) дефрагментация RAID-а (как обычного диска) полезна, в плане оптимизации использования ресурсов ЦПУ и памяти.
По мне так рыклама, аналогичная "супер-пупер-оптимизаторам памяти" для винды. Имеет какой-то смысл только в случае софтварного рэйда, когда упомянутые ресурсы действительно используются при его работе.
_________________
Time will show...
    Добавлено: 12:15 27-02-2009   
Rept-Tile
 150 EGP


Рейтинг канала: 3(38)
Репутация: 55
Сообщения: 240
Откуда: Москва
Зарегистрирован: 08.11.2007
Lars :
на начальном этапе это будет контроллер + заточенный под него дефрагментатор
Угу. А потом будет универсальный стандарт, сдается мне. Вот только не отстали ли мы (я) от жизни, и может быть первые ласточки такого софта уже летают?
    Добавлено: 12:39 27-02-2009   
Железный канал: «RAID»
На страницу: Пред.  1, 2, 3 ... 8, 9, 10, 11  След.    Перейти:   Все страницы
  
Показать: 
Предыдущая тема | Следующая тема |
К списку каналов | Наверх страницы
Цитата не в тему: Земля в иллюминаторе, земля в иллюминаторе... да кто же набросал туда земли?!

  » RAID | страница 9
Каналы: Новости | Elite | Elite: Dangerous | Freelancer | Star Citizen | X-Tension/X-BTF | X2: The Threat | X3: Reunion | X3: Terran Conflict | X Rebirth | X4: Foundations | EVE Online | Orbiter | Kerbal Space Program | Evochron | VoidExpanse | Космические Миры | Онлайновые игры | Другие игры | Цифровая дистрибуция | play.elite-games.ru | ЗВ 2: Гражданская война | Творчество | Железо | Игра Мечты | Сайт
   Дизайн Elite Games V5 beta.18