В простейшем виде это одна (!) тушка с 2мя 24 дисковыми полками. 2х42 ТБ, если делать raid6 из 2ТБ дисков. Расширение - 4ТБ диски на подходе. А там хоть слона делайте поверх. 7 гигабит на полку, вроде. Само собой, тушку хорошо бэкапить на вторую такую же.
Если же клиентов много - то и NFS, и SMB будут плохим выбором, неважно что там под ними валяется. Если NFS последний ещё как-то можно рассматривать, то smb точно раскорячится.
"10-20 клиентов могут одновременно произвольно запрашивать файлы из хранилища." как показала практика в похожей ситуации - использовались два ящика coraid с зеркалированием с помощью drbd (это не я придумал так). то такая конструкция выдает большие задержки по I/O. то есть одна дисковая полка проблему скорее всего не решит, нужно разделять. но вот как? или есть волшебные варианты и все решит? Клиентов 10-20 вряд ли больше, виндовых из них меньшинство, сколько точно сказать не могу - не знаю. Так что если для виндовых клиентов за счет SMB будет чуть/особо медленнее - это не критично.
drdb достаточно тормоз. У меня такая тушка стоит, в пике на ней человек 40 работало по SMB. Вторая приходит и неторопливо делает rsync с flock. Правда, у меня там файло сильно больше и с синхронизацией вам придется придумывать что-то посложнее.
Полка с правильно потюненным XFS задержек в I/O больших создать не должна. В вашем случае очень и очень внимательно нужно отнестись к ФС, потому как ей от 40 ТБ мелких файлов станет плохо.
Ну и собственно вопрос - а какой latency приемлем?
вот и я думаю по rsync копии делать и от глюков ФС более застрахован, и тормозов меньше, изменения небольшие в системе. с XFS вроде как с навигацией по каталогам задержки возникают уже на 20ТБ, но там по 100 элементов каталоге. удаление очень медленно.
Вот в цифрах сказать не могу, но суть процесса такая, чем меньше задержка между запрашиваемыми файлами, тем лучше для задачи в целом - общая производительность. Но это не realtime обработка.
>>с XFS вроде как с навигацией по каталогам задержки возникают уже на 20ТБ, но там по 100 элементов каталоге. удаление очень медленно.
Ядра какие? Больше чем 2.6.38 / RHEL6 ? Там в XFS впилен delaylog и она стала сильно шустрее на операциях с метаданными (mass delete, mass update and such).
Вы ничего не сказали о количестве клиентов.
В простейшем виде это одна (!) тушка с 2мя 24 дисковыми полками. 2х42 ТБ, если делать raid6 из 2ТБ дисков. Расширение - 4ТБ диски на подходе. А там хоть слона делайте поверх. 7 гигабит на полку, вроде.
Само собой, тушку хорошо бэкапить на вторую такую же.
Если же клиентов много - то и NFS, и SMB будут плохим выбором, неважно что там под ними валяется. Если NFS последний ещё как-то можно рассматривать, то smb точно раскорячится.
Reply
как показала практика в похожей ситуации - использовались два ящика coraid с зеркалированием с помощью drbd (это не я придумал так).
то такая конструкция выдает большие задержки по I/O.
то есть одна дисковая полка проблему скорее всего не решит, нужно разделять. но вот как? или есть волшебные варианты и все решит?
Клиентов 10-20 вряд ли больше, виндовых из них меньшинство, сколько точно сказать не могу - не знаю. Так что если для виндовых клиентов за счет SMB будет чуть/особо медленнее - это не критично.
Reply
У меня такая тушка стоит, в пике на ней человек 40 работало по SMB. Вторая приходит и неторопливо делает rsync с flock. Правда, у меня там файло сильно больше и с синхронизацией вам придется придумывать что-то посложнее.
Полка с правильно потюненным XFS задержек в I/O больших создать не должна. В вашем случае очень и очень внимательно нужно отнестись к ФС, потому как ей от 40 ТБ мелких файлов станет плохо.
Ну и собственно вопрос - а какой latency приемлем?
Reply
с XFS вроде как с навигацией по каталогам задержки возникают уже на 20ТБ, но там по 100 элементов каталоге.
удаление очень медленно.
Вот в цифрах сказать не могу, но суть процесса такая, чем меньше задержка между запрашиваемыми файлами, тем лучше для задачи в целом - общая производительность. Но это не realtime обработка.
Reply
удаление очень медленно.
Ядра какие? Больше чем 2.6.38 / RHEL6 ? Там в XFS впилен delaylog и она стала сильно шустрее на операциях с метаданными (mass delete, mass update and such).
Reply
Reply
Leave a comment