>>Иногда в серверах банально не хватает корзин, я по тому и упомянула
>>1u машину.
>
>Так вроде давно уже делают одноюнитовые машинки, в которые можно и 8
>дисков напихать, так что это не бог весть какая проблема. На
>мой взгляд, гораздо сложнее в этом плане со слотами для модулей
>памяти - если их вдруг оказалось мало, то это означает переход
>в другой класс, с соответствующим увеличением цены. Я же не зря написала про бюджет :) бывают и 4 сокета в 1u корпусе, но сколько они стоят?
Вот у проекта может быть в бюджете статья на выделенный database сервер, но может не быть на то, что Вы описываете выше. И в таком случае достаточно бюджетная машинка с зеркалом на том же md (да и geom) из SSD дисков может быть гораздо удобнее, а лишние деньги можно потратить на CPU/озу
>>Он не везде нужен: raid вообще не средство гарантии сохранности информации, он
>>им не может быть просто по дизайну идеи.
>
>Кто говорил про RAID? RAID и контроль целостности между собой никак не
>связаны, как, впрочем, и RAID и сохранность информации или контроль целостности
>и сохранность информации.
raid это девятки после запятой в надежности работы сервиса. Контроль целостности нужен для добавления девяток, что бы _уменьшить_(но не исключить) необходимость восстановления из бэкапов
>>Рейд лишь средство добавления девяток после запятой в уровень стабильности сервиса: в случае порчи данных/файловой системы гарантирован даунтайм на восстановление из бэкапов, но рейд не может нас предостеречь от софтовой ошибки(когда данные, записанные на файловую систему уже некорректны), от взлома сервера (и rm -rf /, или компроментации и тотального трояненья данных) от банального уничтожения сервера по-отдельности, или с дата-центром(как это было недавно с хостинг.уа)
>
>Так речь об этом и не шла. Речь шла о сквозном контроле
>целостности. Никогда не приходилось поиском источника неявного повреждения данных заниматься? Врагу
>не пожелаешь такое "развлечение"
в случае железных проблем, или совсем бюджетного железа (без ECC памяти), или некоторых софтовых глюков (наверное, самый частый случай) ZFS будет закономерно писать на диск уже испорченные данные, испорченные до попадания их к ZFS.
>Кстати, вот Apache Software Foundation считает, что ZFS оказалась весьма полезна в
>ситуации восстановления после взлома сервера: http://blogs.apache.org/infra/entry/apache_org_downtime_report
Так я и не отрицаю полезность фич ZFS, но отрицаю ее "особый" и уникальный статус: имхо, не более чем очень хорошая файловая система, и даже лучшая в мире для некоторых задач
>Я бы все-таки сказал, что представление о ZFS как "всего-лишь навсего
>файловой системе" несколько наивно. Это скорее интегрированная система управления хранением данных.
Хорошо, очень хорошая "интегрированная система управления данными", лучшая в мире в каких-то очень узких и специальных применениях
>>Настоящие гарантии могут дать только бэкапы, причем глубокие, за длительное время, так как часто порча данных обнаруживается не сразу. А в случае с бэкапами, к каждому бэкапу достаточно прикладывать md5 сумму тарболла бэкапа, что бы знать, что он побился (на, например, софтовом рейде md 5/6 без батарейки)
>
>А я бы предпочел, чтобы за меня это делал компутер, он ведь
>для этого создан. Зачем мне лишняя забота - поддерживать в актуальном
>состоянии контрольные суммы бэкапов?
ZFS Вам _не_ может дать такой гарантии. Почему, смотрите выше. Для того, что бы смогла, из интегрированной системы хранения данными нужно сделать нечто большее: дать гарантии отсуствия глюков в тех данных, что передаются ZFS, и добавить избыточности ECC/registred памяти, так как на обычных серверах ее часто не хватает, так как ошибки памяти совсем не редкость(личный опыт, не один раз делала те же ремапы, когда сервис не поднимался).
>А под ручку со сквозным контролем целостности ходит обнаружение и исправление ошибок
>при наличии избыточности.
Оно не дает никаких гарантий того, что Ваши данные будут целостны. Их могут дать _только_ бэкапы, и процедура переодического восстановления из бэкапов (и тестов того, что восстановлено), и то, с оговорками
>>raid 1 обеспечивает, по возможности, только целостность файловой системы (и то, не до конца) > raid5/6, за счет контроля четности обеспечивают целостность блоков данных (но не данных самой файловой системы)
>
>Ну вот. Вы же сами выше писали, что он только добавляет девятки
>после запятой, а теперь утверждаете, что он обеспечивает целостность блоков данных.
>Сможете на пальцах объяснить, как он это делает? Попробуйте, хотя бы
>самой себе.
Целостность дает несколько дополнительных девяток после запятой к надежности, поэтому в SAN часто используется raid 60, вместо raid, например, 10, который быстрее (и raid6 для хранения данных без требования высокой производительности), хотя еще играет роль то, что raid6 вообще надежнее на современных больших дисках, с которыми вероятность вылета второго HDD во время ребилда не так уж и мала.
>> raidZ обеспечивает целостность и данных, но не предоставляет гарантий того, что данные не попали на диск в уже испорченном виде.
>
>Так этого и RAID-0/1/5/6 да и другие ФС не обеспечивают тоже. И
>что теперь, на основании этого отказаться от плюсов сквозного контроля целостности
>при передаче и хранении данных?
Без, например, ECC памяти на low-end серверах, да, отказаться, так как ничего на самом деле не гаратирует (так как просто в нем нет смысла) а в остальных случаях думать, не принесет ли с собой это какие-то неудобства (например, фрагментацию из-за COW-записи)
Объясню на пальцах: raid5 на терабайтниках и еще больших дисках(особенно десктопных) имеет достаточно большой шанс смерти во время ребилда, чем raid6, но:
1. Он быстрее на запись
2. Удобнее для маленьких массивов из четырех шпинделей (и, тем более, из трех), так как всего один диск теряется на избыточность.
raid5 до сих пор используется, и он надежнее, чем одиночный диск без массива (хотя с очень бизнес-критикал использованием он уже не совместим)
3. Часто защита от риска потери данных, пара девяток после запятой в raid6, стоят для проекта дороже, и бесполезнее, чем объем и бюджет(в raid5), ведь все равно есть бэкапы, а от всех рисков _остановки_(а не уничтожения!) сервиса не застрахуешься!, тогда как риск просадки производительности, во время возрастания нагрузки на проект, и остановки сервиса(от чего, на самом деле и защищает raid или zfs), больше вероятности второго вылета диска, когда даже первый вылет не факт, что когда-то случится!
с ZFS все точно так же: сквозной контроль целостности часто слишком избыточен, и совсем не нужен для проекта, если остальные компоненты системы совсем не такого уровня защиты.
>>Таким образом, контроль целостности данных, это лишь фича(которая имеет свою цену, и
>>не маленькую!),
>
>Которая имела немаленькую цену, когда процессоров был один, ядро у него было
>одно, и частота этого ядра была 5 МГц. И эта цена
>падает с каждым днем, а значение и польза - наоборот растут.
Больше вопрос в iops'ах, с которыми у ZFS не всегда все хорошо
>только off-site бэкапы.
>
>А как насчет раннего обнаружения этих самых ошибок, чтобы они не попали
>в самые глубокие офф-сайт бэкапы?
Для этого есть мониторинг. ZFS не может гарантировать того, что на ZFS у Вас верные данные!
А то представляете картину маслом: восстанавливаем
>последний бэкап - а там ошибка, восстанавливаем предпоследний - а там
>тоже ошибка, и так до самого первого. Ладно, если он прокатит
>- восстановимся, но время простоя-то какое будет? А что если и
>в самом первом ошибка?
Нужно было отработать процедуру восстановления, и регулярно ее производить, так как ZFS так же не может гарантировать от такой ситуации.
>>Согласна, но на опеннет ее любят превозносить как некий универсальный "эликсир" от
>>всех проблем!
>
>Ну эликсир то вряд-ли, но вот повод задуматься - это да.
Вам тоже: не все фичи в любых случаях полезны.
>>Если честно, я бы больше всего хотела бы, что бы кто-то сделал
>>софтовое решение проблемы хранения off-site бэкапов: за 40 лет так ничего
>>лучше лент в банковской яйчейке и не придумали, а библиотека с
>>автолоэдером, что бы не руками ленты тасовать, стоит очень и очень
>>недешево!
>
>Хранение больших архивов информации в течение длительных промежутков времени - дело крайне
>недешевое. И тенденций к изменениям вроде пока не наблюдается
Вот-вот, имхо, индустрия идет куда-то не туда, именно какое-то гениальное решение для удешевления надежных бэкапов и нужно гораздо больше всех COW, ZFS, кластеров, параллельных ФС, raid-массивов, и тд
