Нужен совет, по организации дисковой подсистемы
Модератор: Модераторы разделов
Нужен совет, по организации дисковой подсистемы
Сервер предназначен для базы данных 1С7.7, работает под wine@etersoft 1.0.12 в терминальном режиме, ОС Debian 7 32 bit
На старом серваке было 4 винта. Два в программном райде1 под систему и два в программном райде1 под базы 1С (базы dbf , 3 гБ, термигальный доступ).
Все работало без перебоев. Если вылетал один из винтов, я без напряга его менял, и синхронизировал. Короче надежность меня устраивала скорость правда не очень.
В новом серваке будет два винта HDD и два SSD. (это уже решено и изменению не подлежит)
Изначально планировалось пойти по старой схеме, два HDD в программном райде1 под систему и два SSD в программном райде1 под базы 1С.
Вот теперь сижу и думаю, может с учетом наличия SSD можно дисковую систему лучше организовать? Может райд1 на SSD нафиг не нужен?
На старом серваке было 4 винта. Два в программном райде1 под систему и два в программном райде1 под базы 1С (базы dbf , 3 гБ, термигальный доступ).
Все работало без перебоев. Если вылетал один из винтов, я без напряга его менял, и синхронизировал. Короче надежность меня устраивала скорость правда не очень.
В новом серваке будет два винта HDD и два SSD. (это уже решено и изменению не подлежит)
Изначально планировалось пойти по старой схеме, два HDD в программном райде1 под систему и два SSD в программном райде1 под базы 1С.
Вот теперь сижу и думаю, может с учетом наличия SSD можно дисковую систему лучше организовать? Может райд1 на SSD нафиг не нужен?
спам-подпись удалена
- drBatty
- Сообщения: 8735
- Статус: GPG ID: 4DFBD1D6 дом горит, козёл не видит...
- ОС: Slackware-current
- Контактная информация:
Re: Нужен совет, по организации дисковой подсистемы
уже писал: зачем вам HDD? В смысле, зачем там систему держать,почему не на SSD?
а вот это я не знаю. Надёжность SSD (как и HDD) не очень высока, если запись достаточно частая (HDD убивает любой доступ, а SSD только запись). Но если есть бекап, и скорость достаточна (т.е. если "бутылочное горло" не SSD), то ИМХО raid1 не нужен. Лучше на второй SSD (и/или на HDD) де6лать бекап crond'ом.
Re: Нужен совет, по организации дисковой подсистемы
ssd модель можно узнать?
Re: Нужен совет, по организации дисковой подсистемы
Диск: Intel® SSDSC2BA100G301 SSD S3700 Series Enterprise MLC (100GB, 64MB, 2.5in SATA 6Gb/s, 25nm 7mm), OEM
Почитал интернеты.
Думаю про 2 HDD в программном райде1 для ОС + SSD для баз и /temp + докуплю или выковыряю из старого один HDD для бекапов, а второй SSD будет лежать как запасной.
Плиз покритикуйте или предложите другие варианты.
спам-подпись удалена
Re: Нужен совет, по организации дисковой подсистемы
Вот тут будет тормозистор. Если RAID, то уж аппаратный, тем более речь идет о сервере.
- Bizdelnick
- Модератор
- Сообщения: 20752
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: Нужен совет, по организации дисковой подсистемы
Почему? Это ж зеркало, там xor'ы считать не надо.
Пишите правильно:
в консоли вку́пе (с чем-либо) в общем вообще | в течение (часа) новичок нюанс по умолчанию | приемлемо проблема пробовать трафик |
Re: Нужен совет, по организации дисковой подсистемы
Да ведь вся работа по управлению массивом все равно процессор нагружает, разве нет?
Re: Нужен совет, по организации дисковой подсистемы
я совсем не буду утвержадть, что мой способ верный, но... Посмотрите на старом серваке реальный объем занимаемый "система + бд" и если объем менее 70 гб, без вариантов лучше делать: на ссд система и бд; хдд под архивы или под резерную копию всей системы.
я не специалист, всякие раиды видел больше со стороны, но даже раид 5, проц i5 не нагружает почти вообще никак (смотрел через htop). Уверен, что расчетом зеркала в раид 1 можно без напряга пренебречь на сервере, дольше сама операция ввода вывода будет выполняться, чем расчеты.
Да ведь вся работа по управлению массивом все равно процессор нагружает, разве нет?
я не специалист, всякие раиды видел больше со стороны, но даже раид 5, проц i5 не нагружает почти вообще никак (смотрел через htop). Уверен, что расчетом зеркала в раид 1 можно без напряга пренебречь на сервере, дольше сама операция ввода вывода будет выполняться, чем расчеты.
- Bizdelnick
- Модератор
- Сообщения: 20752
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: Нужен совет, по организации дисковой подсистемы
Существенно меньше, чем та же файловая система. То есть пренебрежимо мало.
Пишите правильно:
в консоли вку́пе (с чем-либо) в общем вообще | в течение (часа) новичок нюанс по умолчанию | приемлемо проблема пробовать трафик |
Re: Нужен совет, по организации дисковой подсистемы
Bizdelnick писал(а): ↑09.09.2014 10:53
Существенно меньше, чем та же файловая система. То есть пренебрежимо мало.
Первый рейд процессор не слишком то нагружает, там считать особо нечего.
Другой дело - у меня возникают серьезные вопросы по надежности программного рейда. Тем более в связке с ssd
Если у вас есть деньги на покупку ssd корпоративного класса - купите до кучи lsi 9260, или аналог
И еще - базы и систему на одном разделе лучше не держать, лучше вообще на разных рейд-группах (хотя с учетом ssd может и выдержит, но обычно на sas 10-15k c оракловой базой начинает быстро расти l.avg), так что вариант система на hdd + база на ssd более чем грамотна.
- Bizdelnick
- Модератор
- Сообщения: 20752
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: Нужен совет, по организации дисковой подсистемы
И что он даст в плане надёжности?
Пишите правильно:
в консоли вку́пе (с чем-либо) в общем вообще | в течение (часа) новичок нюанс по умолчанию | приемлемо проблема пробовать трафик |
Re: Нужен совет, по организации дисковой подсистемы
вангую (не уверен), что лучше при монтировании ssd указать заведомо меньший объем (процентов на 5).
Re: Нужен совет, по организации дисковой подсистемы
Наверно, не при монтировании, а при разметке -- рекомендуется, да.
Основная рекомендация: свободное место. Его должно быть МНОГО. В идеале 40%, хотя можно и поменьше, но не менее 25% носителя. Следует помнить о том, что фундаментальные истины не стареют: ещё Кнут доказал, что ЛЮБОЕ ЗУ начинает тупить, если сильно заполнено (более 90%).
Спасибо сказали:
Re: Нужен совет, по организации дисковой подсистемы
Kopilov думаете?
мой совет, так как ssd винт будет убирать нерабочие кластеры (прозрачно для ос). При этом процент бракованных мегабайт (не используемых) может быть весьма солидным дажи при выпуске с завода. И может внезапно оказаться, что 1 ssd винт у вас на 100,1 гб; а недавно купленный на 99,9 гб. Вот чтобы с этим не парится, лучше заранее бытовые винчестеры монтировать как 95 гб для raid и не гадать об уменьшении объема винта в результате износа. Это особенно верно для hdd.
Я вполне допускаю, что я не прав, но я так думаю (логически гадаю).
--------
ваш совет не забивать файловую систему целиком, так как некоторые файловые системы (ntfs например) при некотором объеме начинает совсем по другому фрагментировать файлы. И исправить такую не верную фрагметацию можно только форматированием.
мой совет, так как ssd винт будет убирать нерабочие кластеры (прозрачно для ос). При этом процент бракованных мегабайт (не используемых) может быть весьма солидным дажи при выпуске с завода. И может внезапно оказаться, что 1 ssd винт у вас на 100,1 гб; а недавно купленный на 99,9 гб. Вот чтобы с этим не парится, лучше заранее бытовые винчестеры монтировать как 95 гб для raid и не гадать об уменьшении объема винта в результате износа. Это особенно верно для hdd.
Я вполне допускаю, что я не прав, но я так думаю (логически гадаю).
--------
ваш совет не забивать файловую систему целиком, так как некоторые файловые системы (ntfs например) при некотором объеме начинает совсем по другому фрагментировать файлы. И исправить такую не верную фрагметацию можно только форматированием.
Re: Нужен совет, по организации дисковой подсистемы
С трудом представляю как корректно ответить на этот вопрос.
Софтовые рейды имеют неприятную привычку осыпаться практически на ровном месте, например после некорректной перезагрузки. Проблема обычно решается одной-двумя командами в консоли, но зачем все это нужно? Опять же не видел чтобы софт-рейд умел spare диски, хотя тут могу и ошибаться.
Опять же с диска, вынутого из софтового рейда очень часто без бубна запуститься не получается.
Из личных наблюдений:
lvm для raid 1 требует отдельного раздела для неких своих метаданных. в идеале раздел этот надо хранить на диске не включенном в рейд. Неудобно и ненадежно.
gmirror - любит осыпаться после жесткого ребута, обычно лечится быстро, но в целом тоже не комильфо. Из полусотни проксей на филиалах в месяц рейд разваливается на 2-х 3-х. Впрочем это строго говоря ни разу не линуксы.
dmraid использовал всего один раз проблем не заметил, что в общем не показатель, ибо сервер стоит с хорошим аптаймом, под ибп. Так что тут наверное просто можно считать что данных нет.
Если честно тут вопрос ни о чем. Если есть возможность/средства на покупку железного рейда - надо покупать, чтобы спать спокойно, тем более что тогда получится прирост в производительности. Это не я придумал, это общепризнанная практика.
Если денег нет - софт рейд.
Спасибо сказали:
Re: Нужен совет, по организации дисковой подсистемы
spLin только они hard raid очень часто не совместимы с никс системами. А ваще читал мнение (не знаю верно ли оно), что покупать hard raid под сата мягко говоря глупо, под sas более чем разумно. и железка с нормальным процессором на борту (а не отдающая расчет на процессор) стоит от 17К и выше. Это не так?
- Bizdelnick
- Модератор
- Сообщения: 20752
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: Нужен совет, по организации дисковой подсистемы
Так это и не RAID в прямом смысле слова.
Какая-то всё экзотика... mdadm нынче вроде стандарт де-факто. И с ним я проблем не наблюдал ни разу. (Ну то есть был один сервак, на котором RAID1 регулярно разваливался, но это подозрительно коррелировало с запуском туда не вполне пряморукого товарища с root-правами...)
Несовместимы обычно встроенные в материнку (хотя бывают и дискретные) fake raid, которые по сути своей являются софтовыми. Как были в своё время win-модемы, так и это win-raid. А hard raid - это совсем другая история.
Пишите правильно:
в консоли вку́пе (с чем-либо) в общем вообще | в течение (часа) новичок нюанс по умолчанию | приемлемо проблема пробовать трафик |
- Bizdelnick
- Модератор
- Сообщения: 20752
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: Нужен совет, по организации дисковой подсистемы
Kopilov писал(а): ↑12.09.2014 00:13Основная рекомендация: свободное место. Его должно быть МНОГО. В идеале 40%, хотя можно и поменьше, но не менее 25% носителя. Следует помнить о том, что фундаментальные истины не стареют: ещё Кнут доказал, что ЛЮБОЕ ЗУ начинает тупить, если сильно заполнено (более 90%).
Забыли указать, что писал этот текст не спец по SSD, а drBatty, и пруфов он не привёл. Я не утверждаю, что это брехня, но и слепо верить написанному не вижу резона.
Пишите правильно:
в консоли вку́пе (с чем-либо) в общем вообще | в течение (часа) новичок нюанс по умолчанию | приемлемо проблема пробовать трафик |
Re: Нужен совет, по организации дисковой подсистемы
azsx писал(а): ↑12.09.2014 10:55spLin только они hard raid очень часто не совместимы с никс системами. А ваще читал мнение (не знаю верно ли оно), что покупать hard raid под сата мягко говоря глупо, под sas более чем разумно. и железка с нормальным процессором на борту (а не отдающая расчет на процессор) стоит от 17К и выше. Это не так?
Я рекомендовал LSI 9260.
Он более чем совместим с практически всеми *nix, причем без каких-то дополнительных телоджвижений.
Стоит - да недешево (17к примерно правильная цена)
Если хочется дешевле - можно посмотреть в сторону adaptec, их контроллеры при аналогичных характеристиках обычно дешевле на 50-100$. Точную модель к сожалению сказать не могу, так как слабо с ними знаком. Самый простой способ понять будет этот контроллер работать с linux/bsd или нет - смотреть на заявленную поддержку vmware/esxi. Если есть - работать будет, если нет - то возможно будет работать с дистрибутивами rhel/centos/sles, и то не факт и скорее всего с проблемами, про *deb-based дистрибутивы в таком случае можете просто забыть.
По поводу покупки рейда под sata - разница при использовании контроллера заключается в наличии буфера и снижении нагрузки на CPU.
Если последним можно в современных системах и пренебречь, то вот кэш будет одинаково давать прирост в скорости независимо от sas или sata дисков.
Причем (это уже мои домыслы) мне кажется что в процентном соотношении с использованием sata дисков прирост будет даже больше, за счет того что диски медленнее и кэш на sata дисках меньше.
Re: Нужен совет, по организации дисковой подсистемы
Bizdelnick писал(а): ↑12.09.2014 11:48
Так это и не RAID в прямом смысле слова.
Какая-то всё экзотика... mdadm нынче вроде стандарт де-факто. И с ним я проблем не наблюдал ни разу. (Ну то есть был один сервак, на котором RAID1 регулярно разваливался, но это подозрительно коррелировало с запуском туда не вполне пряморукого товарища с root-правами...)
Несовместимы обычно встроенные в материнку (хотя бывают и дискретные) fake raid, которые по сути своей являются софтовыми. Как были в своё время win-модемы, так и это win-raid. А hard raid - это совсем другая история.
Если честно я не очень хорошо разбираюсь в современной моде на soft-raid под линукс. В филиалах у меня bsd с gmirror а в головном офисе все больше схд/железные рейды, тут уже soft-raid ни к чему.
Но думаю общая тенденция ненадежности подобных программных решений сохранилась.
Несовместимы обычно встроенные в материнку (хотя бывают и дискретные) fake raid, которые по сути своей являются софтовыми. Как были в своё время win-модемы, так и это win-raid. А hard raid - это совсем другая история.
Вот это плюсую.
- Bizdelnick
- Модератор
- Сообщения: 20752
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: Нужен совет, по организации дисковой подсистемы
Вы - думаете, остальные - пользуются...
Поскольку принцип работы что софтового, что железного рейда одинаков, если реализация не кривая - вероятность сбоев из-за потери питания одна и та же.
Пишите правильно:
в консоли вку́пе (с чем-либо) в общем вообще | в течение (часа) новичок нюанс по умолчанию | приемлемо проблема пробовать трафик |
Re: Нужен совет, по организации дисковой подсистемы
это как?
ты же создаешь raid перед загрузкой системы в конфигураторе платы, а системе она отдает уже готовый виртуал_диск, который может быть как зеркалом, так и с чередованием - система об этом уже ничего не знает, если только нет фирменных утилит для диагностки, но все равно, к "совместимости" это не имеет отношения.
Re: Нужен совет, по организации дисковой подсистемы
если только нет фирменных утилит для диагностки
именно утилиты я и имел в виду.
Re: Нужен совет, по организации дисковой подсистемы
Докладываю.
Как я уже писал на новом серваке два винта HDD и два SSD.
2 HDD в программном райде 1, под систему (Debian 7)
На одном SSD положил базы 1С (две базы ДБФ-ые по 3 гига каждая)
На втором SSD положил Темпы баз.
С базами работаю от 5 до 20 человек одновременно в терминальном режиме.
Результаты просто превосходные.
База 3 гига индексировалась сегодня 1 мин 15 сек. Раньше на сатавских винтах это занимало около 8 минут.
Но самое интересное это формирование отчетов и проводки. Если раньше отчет формировался до 5 минут, то сейчас это происходит буквально за 3-4 секунды.
Проводка документов практически мгновенная. Пропали все затыки листания справочников, задержки открывания документов, все "летает".
Честно говоря я надеялся на прирост производительности, но результат многократно превзошел все мои ожидания.
Теперь самое интересное, на сколько хватит SSD-шки под базами.
Как я уже писал на новом серваке два винта HDD и два SSD.
2 HDD в программном райде 1, под систему (Debian 7)
На одном SSD положил базы 1С (две базы ДБФ-ые по 3 гига каждая)
На втором SSD положил Темпы баз.
С базами работаю от 5 до 20 человек одновременно в терминальном режиме.
Результаты просто превосходные.
База 3 гига индексировалась сегодня 1 мин 15 сек. Раньше на сатавских винтах это занимало около 8 минут.
Но самое интересное это формирование отчетов и проводки. Если раньше отчет формировался до 5 минут, то сейчас это происходит буквально за 3-4 секунды.
Проводка документов практически мгновенная. Пропали все затыки листания справочников, задержки открывания документов, все "летает".
Честно говоря я надеялся на прирост производительности, но результат многократно превзошел все мои ожидания.
Теперь самое интересное, на сколько хватит SSD-шки под базами.
спам-подпись удалена
- drBatty
- Сообщения: 8735
- Статус: GPG ID: 4DFBD1D6 дом горит, козёл не видит...
- ОС: Slackware-current
- Контактная информация:
Re: Нужен совет, по организации дисковой подсистемы
это рекомендация для Windows. В OS Linux можно управлять дисковой подсистемой не так топорно. Ну т.е. можно конечно и так сделать, но есть и другие варианты. Например в /home/ можно mkfs -m5, всё равно рут туда ничего писать не должен. То же можно сделать на сервере для /var, этим мы ограничим демонов вроде почтового сервера. При этом, даже если почтовик пожрёт всё место в /var, система всё равно будет работать, и можно будет всё исправить(в т.ч. удалённо).
Также можно сделать swap. В нормальной работе он не будет использоваться, но в случае аварии реакция OOM Killer'а будет более адекватной — возможно он завалит ваше Java приложение на сервере, но sshd не тронет. А если свопа нет, то может прибить даже sshd, и придётся идти к серверу ножками.
Bizdelnick писал(а): ↑12.09.2014 11:53Забыли указать, что писал этот текст не спец по SSD, а drBatty, и пруфов он не привёл. Я не утверждаю, что это брехня, но и слепо верить написанному не вижу резона.
пруфы были у Intel, но искать их мне лениво. Если вы не согласны, так и скажите. Я не вижу других точек зрения и не считаю нужным доказывать очевидное.
Данная рекомендация прямо следует из особенностей конструкции SSD. И я не очень понимаю, с чем вы спорите? Я неправильно понимаю, как устроен SSD, или понимаю я правильно, но следствие совсем иное? Или вы просто так, потрещать пришли?
- drBatty
- Сообщения: 8735
- Статус: GPG ID: 4DFBD1D6 дом горит, козёл не видит...
- ОС: Slackware-current
- Контактная информация:
Re: Нужен совет, по организации дисковой подсистемы
не будет ИМХО. Он просто сдохнет, вот и всё. При этом его номинальный объём не измениться до последнего дня. То, что диск деградирует, заметно только по S.M.A.R.T'у Да и там оно пишет только "сколько было ошибок" и "сколько было записей в среднем".
А вот "сколько сдохло ячеек" у меня не пишет. Я конечно не специалист, но это ИМХО доказывает то, что SSD ничего не вычёркивает, а так и пишет в битые блоки.
Как он умудряется читать без ошибок из битых блоков? Да очень просто: помехоустойчивые коды применяются и в HDD, и в CD-ROM, и очевидно в SSD тоже.
Да, пруфов не будет, кода firmware у меня под рукой нет. Свидетельства лишь косвенные, основанные на анализе деградации и статистике ошибок.
Если у кого-то есть более надёжные источники, я буду благодарен за их предоставление. Я не смог найти. Производители SSD не раскрывают деталей реализации, потому-то я тоже не могу всё это обосновать.
- Bizdelnick
- Модератор
- Сообщения: 20752
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: Нужен совет, по организации дисковой подсистемы
Я сказал то, что посчитал нужным сказать. Я тоже не специалист в этой области, и никаких собственных суждений на сей счёт у меня нет. Спорить ни с чем не намерен.
Пишите правильно:
в консоли вку́пе (с чем-либо) в общем вообще | в течение (часа) новичок нюанс по умолчанию | приемлемо проблема пробовать трафик |
- drBatty
- Сообщения: 8735
- Статус: GPG ID: 4DFBD1D6 дом горит, козёл не видит...
- ОС: Slackware-current
- Контактная информация:
Re: Нужен совет, по организации дисковой подсистемы
Re: Нужен совет, по организации дисковой подсистемы
Как он умудряется читать без ошибок из битых блоков? Да очень просто: помехоустойчивые коды применяются и в HDD, и в CD-ROM, и очевидно в SSD тоже.
немного (наверное) не согласен. читал как то на китайском (на сайте производителя), что они просто делают небольшой запас под выбитые байты. Типа сделали ssd на 120 гбайт (по госту), а на деле там 125 гбайт. И отключай на здоровье банки. С hdd (особенно оптимизированных под raid абсолютно то же самое). Кстати во времена низкоуровневого форматирования bad кластеры видно было хорошо и переразметка bad кластеров приводила к ошибкам при записи. Просто когда низкоуровневое форматировние оказалось вредным - я не умею перебивать bad'ы. Зато убрав bad можно было увеличить емкость винта.
зы
кстати на никс я тут убил один винт хдд хитачи, он именно дает ошибки при записи. Если предложите тест - могу проверить как оно это всё происходит. Смар в убунту пишет что винт не рабочий.
- Bizdelnick
- Модератор
- Сообщения: 20752
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: Нужен совет, по организации дисковой подсистемы
drBatty писал(а): ↑26.09.2014 02:44я вот эту ссылку не давал разве? http://en.wikipedia.org/wiki/Write_amplification
Вроде бы нет. Хотя это явление мне знакомо.
azsx писал(а): ↑26.09.2014 12:14читал как то на китайском (на сайте производителя), что они просто делают небольшой запас под выбитые байты. Типа сделали ssd на 120 гбайт (по госту), а на деле там 125 гбайт. И отключай на здоровье банки. С hdd (особенно оптимизированных под raid абсолютно то же самое).
Это видно в SMART.
Пишите правильно:
в консоли вку́пе (с чем-либо) в общем вообще | в течение (часа) новичок нюанс по умолчанию | приемлемо проблема пробовать трафик |