ВНИМАНИЕ!
Наша конференция посвящена космической тематике и компьютерным играм.
Политические вопросы и происходящие в мире события в данный момент на нашем сайте не обсуждаются!
|
| » RAID | страница 9 |
|
|
|
|
Железный канал: «RAID» |
|
|
|
Lars
 440 EGP
   
Рейтинг канала: 6(253)
Репутация: 77
Сообщения: 2450
Откуда: Архангельск
Зарегистрирован: 28.03.2007
  |
|
Чаще всего для построения RAID 5+1 используют два контроллера RAID 5, которые зеркалируют на программном уровне, что позволяет снизить затраты.
_________________
"Мозги... нам нужны мозги!"(с) "Живые мертвецы" |
|
|
|
Lars
440 EGP
Рейтинг канала: 6(253)
Репутация: 77
Сообщения: 2450
Откуда: Архангельск
Зарегистрирован: 28.03.2007
|
|
Так железо еще не купили?
_________________
"Мозги... нам нужны мозги!"(с) "Живые мертвецы" |
|
|
|
бухой джедай
 182 EGP
Рейтинг канала: 4(87)
Репутация: 70
Сообщения: 7906 Предупреждений: 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 раз |
|
|
|
NucleaR
961 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 |
|
|
|
Star'ik
325 EGP
Рейтинг канала: 3(48)
Репутация: 71
Сообщения: 1882
Откуда: Msk
Зарегистрирован: 29.04.2003
|
|
Э... А нафига, собственно, такой геморрой? RAID5 - это 1 xor 2 -> 3, а RAID 1 - 1 -> 2. В первом случае, если вылетит адын винт, собственно как и во втором случае, система будет жить. Если 5+1, то, получается, может умереть уже сколько угодно винтов в одном из контроллеров. Т.е. типа расчет на атомную войну? Если данные так важны, то гораздо эффективнее полнять репликационный сервачок, или просто производить копирование на внешний HDD (или на 10 внешних HDD, находящихся в разых уголках планеты). Но два сервера будут гораздо более эффективны, чем суперстабильная дисковая подсистема, которая, как и любая другая подсистема, может умереть.
_________________
Все хорошее когда-нибудь кончается |
|
|
|
Falcon
 310 EGP
  
Рейтинг канала: 3(29)
Репутация: 137
Сообщения: 6138
Откуда: КУЙ С НАМИ
Зарегистрирован: 07.02.2001
|
|
вы читали задание?
_________________
7ШJ |
|
|
|
Falcon
310 EGP
Рейтинг канала: 3(29)
Репутация: 137
Сообщения: 6138
Откуда: КУЙ С НАМИ
Зарегистрирован: 07.02.2001
|
|
я же вчера сказал - спасибо всем - тему можно закрыть ибо решение найдено
_________________
7ШJ |
|
|
|
aftermath
685 EGP
Рейтинг канала: 2(16)
Репутация: 234
Сообщения: 1316
Откуда: Нижний Новгород
Зарегистрирован: 07.04.2006
|
|
Гуру, подскажите.
Мамка Gigabyte P35-DS4, харды висят на интеловом контроллер, в биосе был включен режим AHCI и поставлена винда Vista SP1 64bit. Поставлена заботливо, кропотливо, долго, плюс куча софта и его настройки - убита уйма времени.
Стрельнуло сейчас махнуть неоправдавший надежд VelociRaptor на нулевой рейд из пары хардов. Жутко не хочется переставлять винду. Даже времени на это реально нет, да и просто жалко.
Как бы это дело перенести?
Проблема в том, что переключение режима с AHCI в RAID сразу приводит к "синьке" при загрузке висты  Поэтому даже перенос данных, с которым все более-менее понятно (думаю, акронис или гост справится из-под винды...), не решит проблемы неработоспособности винды. С XP вроде таких проблем не было. Если бы наоборот надо было включить AHCI, там все просто, а тут...
Никто не сталкивался?
Обобщая эту кашу, вопрос - как победить "синий" экран в висте при отключении режима AHCI?
Заранее благодарен 
_________________
В темном мире нет любви.
И в груди пусты сердца... (c) |
|
|
|
Rept-Tile
150 EGP
Рейтинг канала: 3(38)
Репутация: 55
Сообщения: 240
Откуда: Москва
Зарегистрирован: 08.11.2007
|
|
Не знаю, хватит ли у меня самого время для участия в этой дискуссии, но все же попробую закинуть удочку. Ибо народ здесь собрался пытливый, а лично для меня тема однозначного решения не имеет.
Перед ответом очень рекомендую ознакомиться с мнениями в одном флуд-топике на хоботах:
Сцылка
Дабы избежать экскурсии по пройденным другими граблям.
Итак, дополнительно к вопросам в заголовке опроса (просьба аргументировать свой ответ):
Известны ли вам и применялись ли на практике с анализом результата дефрагментаторы для NTFS, способные при дефрагментации:
А) учитывать архитектуру конкретного дефрагментируемого массива RAID?
Б) при этом учитывать еще и то, что LUN может быть как соответствовать физическому RAID, так и разделять его с другими LUNами?
В) проводить анализ реально используемого режима доступа к файлам и проводить дефрагментацию на основании этого анализа?
Если есть примеры или ссылки на тесты, убедительно показывающие последствия грамотной дефрагментации различных уровней RAID на конкретных серверах - it's strongly welcomed, как говорится.
|
|
|
|
Voha
 930 EGP
   
Рейтинг канала: 9(1038)
Репутация: 167
Сообщения: 4920
Откуда: Moscow, Russia
Зарегистрирован: 15.02.2001
|
|
Ответ: пофигу, ибо эффекта не будет никакого
99% дисковых операций в системах, построенных на любом типе RAID - random read и random/linear write. При таком типе дисковой активности распределение данных по диску не оказывает заметного влияния на скорость доступа.
Если активность специфическая, типа linear read - то ее оборотная сторона в тех же 99% случаев linear write, и файло само по себе нефрагментировано.
Печаль приходит, когда в таком нестандартном варианте идет запись на заполненный более, чем на 90% NTFS раздел. Писать будет тормозно и как попало - но это эффект алгоритмов работы файловой системы, в таком состоянии линейная запись будет на самом деле случайной. Полечить такой разброд, заставив выполнить запись линейно с точки зрения рэйда, сможет любой дефрагментатор, умеющий работать пофайлово (т.е. запись "дефрагментированного" файла происходит всегда полным файлом от начала до конца, а не перемещением кусочков файла так, что для системы он потом попадает в последовательную цепочку логических секторов).
_________________
Time will show... |
|
|
|
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 раз(а) |
|
|
|
Voha
930 EGP
Рейтинг канала: 9(1038)
Репутация: 167
Сообщения: 4920
Откуда: 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... |
|
|
|
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 раз |
|
|
|
Voha
930 EGP
Рейтинг канала: 9(1038)
Репутация: 167
Сообщения: 4920
Откуда: 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... |
|
|
|
Rept-Tile
150 EGP
Рейтинг канала: 3(38)
Репутация: 55
Сообщения: 240
Откуда: Москва
Зарегистрирован: 08.11.2007
|
|
| Voha : |
|
Не надо трогать то, что делает хардварный контроллер. Потому что последствия грустные всегда бывают.
|
Потому что а) стандарты для этого пока отсутствуют б) сложно ...
Это.. флуд, универсальные рецепты и их опровержения - дело, конечно, тоже нужное. Но лучше в личке или в отдельной теме. А то народ совсем зашугается, а мне бы еще мнений набрать хотелось..
|
|
|
|
Lars
440 EGP
Рейтинг канала: 6(253)
Репутация: 77
Сообщения: 2450
Откуда: Архангельск
Зарегистрирован: 28.03.2007
|
|
По моему, в общем случае, не нужна т.к. хардварный контроллер все равно запишет файлы как ему хочется
_________________
"Мозги... нам нужны мозги!"(с) "Живые мертвецы" |
|
|
|
Rept-Tile
150 EGP
Рейтинг канала: 3(38)
Репутация: 55
Сообщения: 240
Откуда: Москва
Зарегистрирован: 08.11.2007
|
|
| Lars : |
|
хардварный контроллер все равно запишет файлы как ему хочется
|
О том-то и речь, в общем-то - не появился ли уже софт, который может заставить его записать так, как нужно? Чтобы использовать это в целях "умной" дефрагментации. Или потенциальная возможность создания такого софта на сегодняшнем уровне технологий.
Ну и прочти 2 ссылки на документацию от DisKeeper и PerfectDisk, которые я приводил чуть выше. Не в целях склонения на свою сторону, а для просвещения по теме. В них, в частности, утверждается в один голос, что даже планарная (обычная) дефрагментация RAID-а (как обычного диска) полезна, в плане оптимизации использования ресурсов ЦПУ и памяти.
|
|
|
|
Lars
440 EGP
Рейтинг канала: 6(253)
Репутация: 77
Сообщения: 2450
Откуда: Архангельск
Зарегистрирован: 28.03.2007
|
|
| Rept-Tile : |
|
В них, в частности, утверждается в один голос, что даже планарная (обычная) дефрагментация RAID-а (как обычного диска) полезна, в плане оптимизации использования ресурсов ЦПУ и памяти.
|
Для RAID 1 и ему подобных может и полезно, для остальных пустая трата времени т.к. дефрагментаторов умеющих указывать контроллеру как и куда писать файлы я не встречал.
Сегодняшние технологии это реализовать могут, но на начальном этапе это будет контроллер + заточенный под него дефрагментатор
_________________
"Мозги... нам нужны мозги!"(с) "Живые мертвецы"
Последний раз редактировалось: Lars (15:06 27-02-2009), всего редактировалось 1 раз |
|
|
|
Voha
930 EGP
Рейтинг канала: 9(1038)
Репутация: 167
Сообщения: 4920
Откуда: Moscow, Russia
Зарегистрирован: 15.02.2001
|
|
| Rept-Tile : |
|
В них, в частности, утверждается в один голос, что даже планарная (обычная) дефрагментация RAID-а (как обычного диска) полезна, в плане оптимизации использования ресурсов ЦПУ и памяти.
|
По мне так рыклама, аналогичная "супер-пупер-оптимизаторам памяти" для винды. Имеет какой-то смысл только в случае софтварного рэйда, когда упомянутые ресурсы действительно используются при его работе.
_________________
Time will show... |
|
|
|
Rept-Tile
150 EGP
Рейтинг канала: 3(38)
Репутация: 55
Сообщения: 240
Откуда: Москва
Зарегистрирован: 08.11.2007
|
|
| Lars : |
|
на начальном этапе это будет контроллер + заточенный под него дефрагментатор
|
Угу. А потом будет универсальный стандарт, сдается мне. Вот только не отстали ли мы (я) от жизни, и может быть первые ласточки такого софта уже летают?
|
|
|
|
|
|
|
|
|
Железный канал: «RAID» |
|
|
| К списку каналов | Наверх страницы |
Цитата не в тему: Я конечно дико извиняюсь что оффтоплю, но все же считаю что мой пост по адресу. (Messer)
|
| » RAID | страница 9 |
|
