DLag: А проблемы перед носом так и не увидели. О чем я собственно и писал. Смешно наблюдать как Cab081 упорно доказывает что проверенное временем решение плохое. Удачи вам, с таким подходом она вам понадобится...
Уважаемый, хорошо, давайте смеятся вместе.
Вы привели текст из википедии
скорость чтения и записи данных высока
При этом строчкой ниже написано:
-) наблюдаются проблемы со скоростью при частых запросах данных небольшого обьёма.
-) большая нагрузка на контрольный диск, что приводит к тому, что его надёжность сильно падает по сравнению с дисками с данными.
Ваша цитата:
RAID-5 существенно медленнее на запись только в случае с дешевым или старым контроллером.
Абсурд (с)
Сравнение raid5 и raid1 на дорогом одном и том же контроллере даст такой же результат.
Ваша цитата:
А вот в случае с массовыми операциями чтения, которые собственно и преобладают на серверах (надеюсь этот факт отрицать вы не будете), RAID 1 нервно курит в сторонке со своей линейной структурой.
Смотрим в уже знакомую нам всеми любимую википедию и читаем второй раз:
(-): массив этого типа хорош только для однозадачной работы с большими файлами, так как наблюдаются проблемы со скоростью при частых запросах данных небольшого обьёма.
Ваша цитата:
Вопрос в том что все операции выполняются параллельно и практически не влияют на скорость.
Во-первых, "параллельность" секвенции мы кое-как разжевали.
Во-вторых, тоже абсурд, хотя бы потому, что очередь команд к конкретному диску в raid5 просто не может выполняться "параллельнее" чем очередь команд к этому же диску в raid1.
Ваша цитата:
С учетом того что вы путаете понятие избыточности с распределением блоков ваши обращения сомнительны.
Это вы сами себя путаете. Моя фраза означала то, что этого самого распределения без избыточности не бывает - это цена за распределение данных.
И эта цена становится сомнительной, когда эффеткивность работы с данными решается одним только кэшированием. Как итог - плюсы оказываются бесполезными, а минусы - остаются.
Как итог итога - мы в нашем собственном конкретном случае решили, что достаточно и разумно raid5/6 не использовать.
А вообще - рейды мы используем и 5 и 50 и 6, но там где это необходимо. на конфигурациях мы не экономим.
Ну и после этого Вы и господин zzeus принялись весело и бодро изображать из себя взрослых воспитанных людей :)
VDS никаких секвенций не генерит. Я об этом уже говорил. Это низкоуровневая работа RAID конктроллера.
zzeus: Вот по этому мой хостер использует RAID60 :]
Мы рады за Вас и Вашего хостера, 60 хороший вариант для больших дисковых хранилищ, но и это опять-таки не связано с необходимостью буста прокачки дисковой подсистемы, это связано в первую очередь с тем, что вендоры дисков с трудом преодолевают показатели по появлению URE(Unrecoverable Read Error). Если коротко - с ростом объема дисков это означает, что если на raid5 у вас вылетел винт, и массив не успел доребилдиться, то очень высок шанс, что вылетит второй винт, и потеряется весь массив. Вам это кажется невероятным? На эту тему в последнее время много статей и статистик крупных датацентров.
Вообще, хочется свернуть уже эту тему RAID'ов. Читайте, изучайте, сомневайтесь и перепроверяйте информацию, мы так и делаем, главное - не надо торопиться с резкими выводами.
Мы на ближайшую перспективу не планируем больших дисковых хранилищ для VDS. Я не зря в самом начале упомянул принцип разумного и достаточного.
Но, вообще, планы на VDS и на сервисы на его основе у нас значительные.
Cab081: Спасибо за замечания, остальным участникам ветки тоже, действительно многое становится понятнее.
Мы не на людях тестируем, а наоборот, люди тестируют нас. Участники тестирования постоянно присылают свои замечания, и субъективные, и вполне конкретные. Все принимается к сведению и будет учтено.
Забыл о главном (а сейчас реклама): самые активные наши тестеры будут вознаграждены дополнительными месяцами бесплатного использования VDS.
Brim.ru: - блин, никто спасибо не скажет, у всех понты :( Ведь ясно говоришь:
1) 256Мб ОП без SWAP - это проблема
2) SWAP на RAID 1 - это проблема
- не верят, хотят тестировать на живых людях :(
Спасибо за замечания, остальным участникам ветки тоже, действительно многое становится понятнее.
Мы не на людях тестируем, а наоборот, люди тестируют нас. Участники тестирования постоянно присылают свои замечания, и субъективные, и вполне конкретные. Все принимается к сведению и будет учтено.
Вообще ветка получилась почти юмористическая: домены с 256Мб ОП и без свопа
Уважаемый, мы услугу те-сти-ру-ем. Мы за нее пока не-бе-рем оплату. Она окончательно еще не сформирована. Мы позволили будущим клиентам, я надаеюсь, самим поучаствовать в формировании услуги.
DLag: Дык смыл то в том что вас уже ткнули в проблему, которую мы уже решили давным-давно. Вопрос в том что вы считаете себя едино правым, а это в технике плохое занятие.
А я вам отвечаю, что преблема выдуманная.
И разве я не написал, что готов выслушать аргументы? Ваши аргументы меня, простите, не убедили.
У меня, знаете, другой взгляд. Субъективно - Вы не верите или делаете вид, что не верите фактам из моих уст. Если не верите мне, спрашивайте своих авторитетов.
Объективно - как ни странно, но у технарей тоже полно своих мифов и суеверий, иногда доходящих до мракобесия. А на форумах достаточно распространителей этих суеверий, этот - не исключение. Не принимайте только это на свой счет.
Сталкиваться с инерциями приходится постоянно.
Cab081 добавил 09.04.2009 в 18:21
zzeus: Не. одна секвенция выполняется последовательно. Другое дело, что несколько секвенций могут выполняться параллельно. Ну и плюс количество секвенций с размером блока < min_chunk явно меньшая доля нагрузки на диски.
Во-первых, параллельные секвенции, если и имеют место (это можно, кстати, в суппорте интела спросить), то это частный случай.
Во-вторых, видите, что получается, мы один раз усложнили схему, добавив шаги в секвенцию, потом стали думать над параллельностью, которая описывает только частный случай, может быть только тогда, когда данных на массиве меньше трети минус один диск. Когда данных больше - raid5 нервно курит, как говорит Dlag.
А если у нас еще и винт вылетел, и идет ребилд и пересчет контрольных сумм...
DLag: zzeus, смысл что-либо объяснять когда человек не видит проблем у себя под носом.
Спасибо, что хоть человеком назвали :)
Cab081 добавил 09.04.2009 в 17:46
zzeus: Сильно сомневаюсь, что VPS генерит секвенций (это записи в логи, ИМХО только) с размером блока < min_chunk достаточно, для оправданий RAID1. Мало того, у вас большое количество клиентов на одном сервере => если количество одновременных записей в логи (на разных VPS) превысит 2 то снова вперед выйдет RAID5/6.
эта секвенция про VDS вообще ничего не знает. А VDS про секвенцию.
Это просто последовательность действий контроллера для сохранения логики данных на блинах, так работает кусок кода прошивки контроллера. И у него нет своих средств распараллелить секвенцию. Подозреваю, что он может в один срез времени читать один блок и писать другой, относящийся к другой секвенции, это да. Но не так как Вы описываете, мол, разом все этапы последовтельности(секвенции).
zzeus: гхм. скажем так, это одна операция. поскольку чтение блока и четности происходит одновременно (диски разные).
аналогично, операция записи производится паралельно.
Операция занимает больше времени в случае если размер данных = min_chunk. Обычно контроллер накапливает данные в кеше, пока они не достигнут оптимальных размеров, после чего производит запись на все диски параллельно, что гораздо быстрее.
А проблемы перед носом так и не увидели.
О чем я собственно и писал.
Смешно наблюдать как Cab081 упорно доказывает что проверенное временем решение плохое.
Удачи вам, с таким подходом она вам понадобится...
Уважаемый, хорошо, давайте смеятся вместе.
Вы привели текст из википедии
При этом строчкой ниже написано:
-) наблюдаются проблемы со скоростью при частых запросах данных небольшого обьёма.
-) большая нагрузка на контрольный диск, что приводит к тому, что его надёжность сильно падает по сравнению с дисками с данными.
Ваша цитата:
Абсурд (с)
Сравнение raid5 и raid1 на дорогом одном и том же контроллере даст такой же результат.
Ваша цитата:
Смотрим в уже знакомую нам всеми любимую википедию и читаем второй раз:
(-): массив этого типа хорош только для однозадачной работы с большими файлами, так как наблюдаются проблемы со скоростью при частых запросах данных небольшого обьёма.
Ваша цитата:
Во-первых, "параллельность" секвенции мы кое-как разжевали.
Во-вторых, тоже абсурд, хотя бы потому, что очередь команд к конкретному диску в raid5 просто не может выполняться "параллельнее" чем очередь команд к этому же диску в raid1.
Ваша цитата:
Это вы сами себя путаете. Моя фраза означала то, что этого самого распределения без избыточности не бывает - это цена за распределение данных.
И эта цена становится сомнительной, когда эффеткивность работы с данными решается одним только кэшированием. Как итог - плюсы оказываются бесполезными, а минусы - остаются.
Как итог итога - мы в нашем собственном конкретном случае решили, что достаточно и разумно raid5/6 не использовать.
А вообще - рейды мы используем и 5 и 50 и 6, но там где это необходимо. на конфигурациях мы не экономим.
Ну и после этого Вы и господин zzeus принялись весело и бодро изображать из себя взрослых воспитанных людей :)
Еще вопросы? :)
Секвенций VPS генерит не так много.
VDS никаких секвенций не генерит. Я об этом уже говорил. Это низкоуровневая работа RAID конктроллера.
Вот по этому мой хостер использует RAID60 :]
Мы рады за Вас и Вашего хостера, 60 хороший вариант для больших дисковых хранилищ, но и это опять-таки не связано с необходимостью буста прокачки дисковой подсистемы, это связано в первую очередь с тем, что вендоры дисков с трудом преодолевают показатели по появлению URE(Unrecoverable Read Error). Если коротко - с ростом объема дисков это означает, что если на raid5 у вас вылетел винт, и массив не успел доребилдиться, то очень высок шанс, что вылетит второй винт, и потеряется весь массив. Вам это кажется невероятным? На эту тему в последнее время много статей и статистик крупных датацентров.
Вообще, хочется свернуть уже эту тему RAID'ов. Читайте, изучайте, сомневайтесь и перепроверяйте информацию, мы так и делаем, главное - не надо торопиться с резкими выводами.
Мы на ближайшую перспективу не планируем больших дисковых хранилищ для VDS. Я не зря в самом начале упомянул принцип разумного и достаточного.
Но, вообще, планы на VDS и на сервисы на его основе у нас значительные.
Удачи!
Спасибо за замечания, остальным участникам ветки тоже, действительно многое становится понятнее.
Мы не на людях тестируем, а наоборот, люди тестируют нас. Участники тестирования постоянно присылают свои замечания, и субъективные, и вполне конкретные. Все принимается к сведению и будет учтено.
Забыл о главном (а сейчас реклама): самые активные наши тестеры будут вознаграждены дополнительными месяцами бесплатного использования VDS.
- блин, никто спасибо не скажет, у всех понты :( Ведь ясно говоришь:
1) 256Мб ОП без SWAP - это проблема
2) SWAP на RAID 1 - это проблема
- не верят, хотят тестировать на живых людях :(
Спасибо за замечания, остальным участникам ветки тоже, действительно многое становится понятнее.
Мы не на людях тестируем, а наоборот, люди тестируют нас. Участники тестирования постоянно присылают свои замечания, и субъективные, и вполне конкретные. Все принимается к сведению и будет учтено.
Вообще ветка получилась почти юмористическая: домены с 256Мб ОП и без свопа
Уважаемый, мы услугу те-сти-ру-ем. Мы за нее пока не-бе-рем оплату. Она окончательно еще не сформирована. Мы позволили будущим клиентам, я надаеюсь, самим поучаствовать в формировании услуги.
LineHost, Brim.ru, ребята, не мне вас учить тут жить, вы здесь давно, но можно попросить в ветке не того.. ну, вы сами знаете.
Дык смыл то в том что вас уже ткнули в проблему, которую мы уже решили давным-давно.
Вопрос в том что вы считаете себя едино правым, а это в технике плохое занятие.
А я вам отвечаю, что преблема выдуманная.
И разве я не написал, что готов выслушать аргументы? Ваши аргументы меня, простите, не убедили.
У меня, знаете, другой взгляд. Субъективно - Вы не верите или делаете вид, что не верите фактам из моих уст. Если не верите мне, спрашивайте своих авторитетов.
Объективно - как ни странно, но у технарей тоже полно своих мифов и суеверий, иногда доходящих до мракобесия. А на форумах достаточно распространителей этих суеверий, этот - не исключение. Не принимайте только это на свой счет.
Сталкиваться с инерциями приходится постоянно.
Cab081 добавил 09.04.2009 в 18:21
Не. одна секвенция выполняется последовательно. Другое дело, что несколько секвенций могут выполняться параллельно. Ну и плюс количество секвенций с размером блока < min_chunk явно меньшая доля нагрузки на диски.
Во-первых, параллельные секвенции, если и имеют место (это можно, кстати, в суппорте интела спросить), то это частный случай.
Во-вторых, видите, что получается, мы один раз усложнили схему, добавив шаги в секвенцию, потом стали думать над параллельностью, которая описывает только частный случай, может быть только тогда, когда данных на массиве меньше трети минус один диск. Когда данных больше - raid5 нервно курит, как говорит Dlag.
А если у нас еще и винт вылетел, и идет ребилд и пересчет контрольных сумм...
zzeus, смысл что-либо объяснять когда человек не видит проблем у себя под носом.
Спасибо, что хоть человеком назвали :)
Cab081 добавил 09.04.2009 в 17:46
Сильно сомневаюсь, что VPS генерит секвенций (это записи в логи, ИМХО только) с размером блока < min_chunk достаточно, для оправданий RAID1. Мало того, у вас большое количество клиентов на одном сервере => если количество одновременных записей в логи (на разных VPS) превысит 2 то снова вперед выйдет RAID5/6.
эта секвенция про VDS вообще ничего не знает. А VDS про секвенцию.
Это просто последовательность действий контроллера для сохранения логики данных на блинах, так работает кусок кода прошивки контроллера. И у него нет своих средств распараллелить секвенцию. Подозреваю, что он может в один срез времени читать один блок и писать другой, относящийся к другой секвенции, это да. Но не так как Вы описываете, мол, разом все этапы последовтельности(секвенции).
и еще к слову "параллельно" - процессоры arm многоядерными еще не делают, 2xcpu контроллеры если видели, покажите пожалуйста.
Парни, ну когда вы уже скажете - ну ладно, фиг с тобой, убедил.. :)
гхм. скажем так, это одна операция. поскольку чтение блока и четности происходит одновременно (диски разные).
аналогично, операция записи производится паралельно.
Операция занимает больше времени в случае если размер данных = min_chunk. Обычно контроллер накапливает данные в кеше, пока они не достигнут оптимальных размеров, после чего производит запись на все диски параллельно, что гораздо быстрее.
секвенция..