Cab081

Рейтинг
2
Регистрация
09.04.2009
DLag:
А проблемы перед носом так и не увидели.
О чем я собственно и писал.
Смешно наблюдать как Cab081 упорно доказывает что проверенное временем решение плохое.
Удачи вам, с таким подходом она вам понадобится...

Уважаемый, хорошо, давайте смеятся вместе.

Вы привели текст из википедии

скорость чтения и записи данных высока

При этом строчкой ниже написано:

-) наблюдаются проблемы со скоростью при частых запросах данных небольшого обьёма.

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

Ваша цитата:

RAID-5 существенно медленнее на запись только в случае с дешевым или старым контроллером.

Абсурд (с)

Сравнение raid5 и raid1 на дорогом одном и том же контроллере даст такой же результат.

Ваша цитата:

А вот в случае с массовыми операциями чтения, которые собственно и преобладают на серверах (надеюсь этот факт отрицать вы не будете), RAID 1 нервно курит в сторонке со своей линейной структурой.

Смотрим в уже знакомую нам всеми любимую википедию и читаем второй раз:

(-): массив этого типа хорош только для однозадачной работы с большими файлами, так как наблюдаются проблемы со скоростью при частых запросах данных небольшого обьёма.

Ваша цитата:

Вопрос в том что все операции выполняются параллельно и практически не влияют на скорость.

Во-первых, "параллельность" секвенции мы кое-как разжевали.

Во-вторых, тоже абсурд, хотя бы потому, что очередь команд к конкретному диску в raid5 просто не может выполняться "параллельнее" чем очередь команд к этому же диску в raid1.

Ваша цитата:

С учетом того что вы путаете понятие избыточности с распределением блоков ваши обращения сомнительны.

Это вы сами себя путаете. Моя фраза означала то, что этого самого распределения без избыточности не бывает - это цена за распределение данных.

И эта цена становится сомнительной, когда эффеткивность работы с данными решается одним только кэшированием. Как итог - плюсы оказываются бесполезными, а минусы - остаются.

Как итог итога - мы в нашем собственном конкретном случае решили, что достаточно и разумно raid5/6 не использовать.

А вообще - рейды мы используем и 5 и 50 и 6, но там где это необходимо. на конфигурациях мы не экономим.

Ну и после этого Вы и господин zzeus принялись весело и бодро изображать из себя взрослых воспитанных людей :)

Еще вопросы? :)

zzeus:
Секвенций VPS генерит не так много.

VDS никаких секвенций не генерит. Я об этом уже говорил. Это низкоуровневая работа RAID конктроллера.

zzeus:
Вот по этому мой хостер использует RAID60 :]

Мы рады за Вас и Вашего хостера, 60 хороший вариант для больших дисковых хранилищ, но и это опять-таки не связано с необходимостью буста прокачки дисковой подсистемы, это связано в первую очередь с тем, что вендоры дисков с трудом преодолевают показатели по появлению URE(Unrecoverable Read Error). Если коротко - с ростом объема дисков это означает, что если на raid5 у вас вылетел винт, и массив не успел доребилдиться, то очень высок шанс, что вылетит второй винт, и потеряется весь массив. Вам это кажется невероятным? На эту тему в последнее время много статей и статистик крупных датацентров.

Вообще, хочется свернуть уже эту тему RAID'ов. Читайте, изучайте, сомневайтесь и перепроверяйте информацию, мы так и делаем, главное - не надо торопиться с резкими выводами.

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

Но, вообще, планы на VDS и на сервисы на его основе у нас значительные.

Удачи!

Cab081:
Спасибо за замечания, остальным участникам ветки тоже, действительно многое становится понятнее.
Мы не на людях тестируем, а наоборот, люди тестируют нас. Участники тестирования постоянно присылают свои замечания, и субъективные, и вполне конкретные. Все принимается к сведению и будет учтено.

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

Brim.ru:
- блин, никто спасибо не скажет, у всех понты :( Ведь ясно говоришь:
1) 256Мб ОП без SWAP - это проблема
2) SWAP на RAID 1 - это проблема
- не верят, хотят тестировать на живых людях :(

Спасибо за замечания, остальным участникам ветки тоже, действительно многое становится понятнее.

Мы не на людях тестируем, а наоборот, люди тестируют нас. Участники тестирования постоянно присылают свои замечания, и субъективные, и вполне конкретные. Все принимается к сведению и будет учтено.

Brim.ru:

Вообще ветка получилась почти юмористическая: домены с 256Мб ОП и без свопа

Уважаемый, мы услугу те-сти-ру-ем. Мы за нее пока не-бе-рем оплату. Она окончательно еще не сформирована. Мы позволили будущим клиентам, я надаеюсь, самим поучаствовать в формировании услуги.

LineHost, Brim.ru, ребята, не мне вас учить тут жить, вы здесь давно, но можно попросить в ветке не того.. ну, вы сами знаете.

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 про секвенцию.

Это просто последовательность действий контроллера для сохранения логики данных на блинах, так работает кусок кода прошивки контроллера. И у него нет своих средств распараллелить секвенцию. Подозреваю, что он может в один срез времени читать один блок и писать другой, относящийся к другой секвенции, это да. Но не так как Вы описываете, мол, разом все этапы последовтельности(секвенции).

и еще к слову "параллельно" - процессоры arm многоядерными еще не делают, 2xcpu контроллеры если видели, покажите пожалуйста.

Парни, ну когда вы уже скажете - ну ладно, фиг с тобой, убедил.. :)

zzeus:
гхм. скажем так, это одна операция. поскольку чтение блока и четности происходит одновременно (диски разные).
аналогично, операция записи производится паралельно.

Операция занимает больше времени в случае если размер данных = min_chunk. Обычно контроллер накапливает данные в кеше, пока они не достигнут оптимальных размеров, после чего производит запись на все диски параллельно, что гораздо быстрее.

секвенция..

123
Всего: 26