[megahertz0]

Итак, есть необходимость перенести сервер заббикса из виртуалки на отлельный сервак т.к. нагрузка растет и в виртуалке mysql начинает откровенно подтормаживать из-за тормознутых винтов. Сейчас все счастье крутиться на KVM, в качестве стораджей используются LVM-тома поверх RAID-10 на дисках WD RE. База порядка 80G, в сутки пишется около гига. Магию по тюнингу мускула применял (буферы, кеши, files per table и т.д.). Да и вообще охота иметь отдельный выделенные сервер под мониторинг. В общем, пора переезжать.

Так вот, встал перед воросом. Оказывается появились SATA-диски с 10К оборотов, вот такие WD к примеру. Ну и никуда не делась классика жанра - 2.5" SAS-диски с 10К оборотов, вот такие, к примеру.

Собственно вопрос вот в чем. Будет ли какая-нибудь серьезная разница 10К-дисками, подключенными к чипсетному рейду и собранными в RAID-10 на md, и между 10К-дисками 2.5", подключенными к RAID-контроллеру с батарейкой и кэшем, например к вот такому LSI? Речь идет о RAID-10 на четырех дисках.

Честно говоря, по цене с контроллером получается не очень. За цену контроллера и ЗиПа (т.е. пара дисков на склад плюс еще один контроллер) можно взять 2U-платформу и просто насовать туда в два раза больше дисков, на крайний случай md собирается на любом тазике. В общем, я в раздумиях...

[sexst]

SSD юзайте под базу, нафиг обычные диски.

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

[megahertz0]

SSD есть мнение что износится быстро... Хотя заявляемые интелом 20К перезаписей в энтерпрайз-дисках внушают.

Изменено 9 января, 2014 пользователем megahertz0

[micol]

Мнение есть, а реальных примеров отказов что-то не встречается)

 

А md практически одинаково быстр в некоторых конфигурациях

 

Для баз реально лучше ssd парочку для успокоения души)

Изменено 9 января, 2014 пользователем micol

[megahertz0]

К стати, а 2,5" SSD становятся в SFF-корзины (2,5") или в LFF через переходник на 3,5"? И попадают ли потом в коннетор SATA?

[vitalyb]

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

Это если battery-backed cache не считать и то, что у некоторых дисков от частой перезаписи суперблока md появляются UNC.

 

 

У нас cacti с бд на сата рейде дисковом, rrd'хи на выделенных двух ssd в зеркале, и всё это на контроллере LSI живет параллельно с кучей всякой ерунды по соседству и не чихает (DataSources:183122).

 

К стати, а 2,5" SSD становятся в SFF-корзины (2,5") или в LFF через переходник на 3,5"? И попадают ли потом в коннетор SATA?

Есть специальные переходники на 3.5 где SAS/SATA порт там, где надо (диск с краю, а не в середине). Но это к вендору.

[Lynx10]

ну ещё один плюс в сторону md - аппаратная независимость

[megahertz0]

Это если battery-backed cache не считать и то, что у некоторых дисков от частой перезаписи суперблока md появляются UNC.

А разве контроллер SSD не размазывает нагрузку по ячейкам?

ну ещё один плюс в сторону md - аппаратная независимость

Тут совершенно согласен. Летом сдох 3ware с двумя raid5. Именно такого контроллера в ЗИПе не оказалось, пришлось раскатывать все из бэкапов. В итоге когда все таки контроллер приехал, то оказалось, что один массив отправился в страну вечной охоты вместе со служебной информацией. Хорошо на массиве был netflow для отдельной от биллинга статистики, потеря которого некритична. Так что восстанавливать не стал, но осадок остался. Так что не только md может уничтожить суперблок. Поэтому теперь и задумываюсь насчет железных контроллеров. Смерть дисков это не так страшно, как смерть самого контроллера. А держать на складе еще один дороговато получается. А если серверов не один и контроллеры у всех разные, то вообще ппц.

[micol]

Можно вынести мета-данные md как раз таки на hdd, дабы не трястись над smart

[vitalyb]

А разве контроллер SSD не размазывает нагрузку по ячейкам?

Не вижу как это связано с первым или со вторым.... кроме "лишнего" износа ssd, конечно. Пишем суперблок с dirty=1, потом с dirty=0. Мелочь, конечно, учитывая объем но неприятно. Не помню сколько там, 0.1 секуда, кажется по умолчанию...

 

Так что не только md может уничтожить суперблок

Суперблок перезаписывается, а не портится, UNC появляются на соседних треках. Я всю голову сломал почему на 6 дисках в одном и том же месте +-1000 секторов постоянно нерелокейтящиеся "бэды" были.

 

Смерть дисков это не так страшно, как смерть самого контроллера

Ну в общем да, на контроллере ж может находиться до полугига "недописанных" данных. Тут мало что поможет помимо бакапа.

Изменено 9 января, 2014 пользователем vitalyb

[NiTr0]

Ни разу не видел бэдов от перезаписи суперблока. Несколько массивов живет, проблем особо нет.

[vitalyb]

Ни разу не видел бэдов от перезаписи суперблока. Несколько массивов живет, проблем особо нет.

Не бэды, а UNC - некорректируемые ошибки чтения. Могут вылезти или при long smart test'е, или при проверке консистентности массива. И, как я сказал, зависит от дисков. MD'шный битмап на выделенном диске имеет тот же эффект (файл обычно мелкий и часто перезаписывается), но последствия хуже: т.к. битмап - обычный файл и находится посреди ФС, может побить данные и структуру ФС.

 

Когда-то нашел это сообщение почти только по номеру сектора: https://lkml.org/lkml/2009/8/25/587

[sexst]

У ssd расположение блоков "виртуальное" и мапится контроллером на реальные ячейки флеш памяти. Причем контроллер их постоянно меняет чтобы равномерно изнашивать диск. Так что проблем от перезаписи одного файла придется ждать очень долго.

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

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

 

К стати, а 2,5" SSD становятся в SFF-корзины (2,5") или в LFF через переходник на 3,5"? И попадают ли потом в коннетор SATA?

У интелов таких родных адаптеров не встречал. Мы юзаем супермикры (в основном 6017 серия), у них есть специальные корзинки в слот LFF, но реально в них крепится SFF диск. Так что полагаю стоит вендора платформы попинать на сей счет.

[NiTr0]

Не бэды, а UNC - некорректируемые ошибки чтения.

А это разве не синоним? :)

 

Могут вылезти или при long smart test'е, или при проверке консистентности массива.

У меня ни разу не вылазили. Протиралась поверхность под структурами ФС/БД, но в районе суперблока все было гладко и шелковисто.

 

Да, такой же суперблок есть и у аппаратных массивов.

[vitalyb]

 

А это разве не синоним? :)

Нет, UNC после перезаписи успешно себе хранит данные и не требует ремапа, а бэд только ремапом лечится. UNC может появится при пропадании питания если сектор не допишется как следует или с помощью команды hdparm --make-bad-sector (не шутка).

 

Да, такой же суперблок есть и у аппаратных массивов.

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

Изменено 10 января, 2014 пользователем vitalyb

[vlad11]

Каждая модель SSD имеет свои ТТХ:

• кол-во ячеек (блоков)
  
• кол-во циклов перезаписи ячеек
  

 

В дешевых моделях - циклов перезаписи менее 10к.

 

У меня, например, хосты с виртуалками. Половина-полтора ТБ в сутки на запись. Дешевые модели SSD очень быстро выйдут со строя.

[vitalyb]

Ну, не так, чтоб и быстро...

[megahertz0]

Раз речь зашла об SSD, то вот какой интересен момент. Кто-нибудь пробовал формат файлов InnoDB Barracuda? Вроде по тестам везде пишется об уменьшении io и размеров базы при появлении оверхеда по процессору процентов в 10-15, что в общем то удивительно. Есть мнение, что при работе с заббиксом и мониторинге портов на доступе, где может быть много нулевых значений итемов (порт выключен к примеру или нет линка) может получиться хорошее сжатие базы на диске и соответственно уменьшение количества записи.

[vitalyb]

megahertz0

Некоторые SSD сами сжимают пред записью в свою физическую память. Кроме этого, SSD смещает узкое место с дисковой системы к процессору и эти 10-15% могут оказаться решающими.

[vlad11]

Ну, не так, чтоб и быстро...

 

Это уже не низший диапазон, а уже чуть выше. Это радует.

[megahertz0]

Некоторые SSD сами сжимают пред записью в свою физическую память. Кроме этого, SSD смещает узкое место с дисковой системы к процессору и эти 10-15% могут оказаться решающими.

Но место на SSD тоже стоит недешево, а если брать два диска в продакшен и один в hotspare, то совсем негуманные цены получаются. К примеру Intel DC S3700 на 200 Гб будет стоить около 500$, итого 1500$ за 2+1 диска. С другой стороны можно взять 3 таких же диска на 100 Гб за 750$, а на разницу взять более производительную платформу. Тот же ксеон Е5 вместо Е3.

[NiTr0]

Нет, UNC после перезаписи успешно себе хранит данные и не требует ремапа, а бэд только ремапом лечится.

UNC - сектор с попорченной контрольной суммой. Что есть причиной - сбой записи, или физическое повреждение магнитного слоя - вопрос десятый. Еще есть и другие типы ошибок (к примеру AMNF - проблемы с транслятором/сервометками, винт не может обнаружить нужный сектор).

И да, римэп с т.з. оси - не что иное как запись в сектор. Винт уже, прописав сектор, решает что с ним делать - если читается (причем - читается за ограниченное, причем - малое кол-во попыток) то считается годным, не читается - в утиль, заменяется резервным.

А то, что вы описали (повреждение из-за сбоев по питанию и т.д.) - софт-бэд.