`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Твердые телом. Как раз такие в серверах и нужны

+1515
голосов

Универсальных рецептов повышения производительности серверов не существует. Принимая решения об изменениях серверной инфраструктуры без детального понимания среды исполнения приложений, надо быть готовым к любым результатам. В том числе — к отсутствию результатов.

Анатомия узких мест серверов

Постоянное обновление процессоров и платформ производителями подталкивает к поверхностному взгляду на эволюцию серверов, как на гонку процессорных мощностей. Такой прямолинейный подход к модернизации серверного парка гарантирует только одно — затраты. Если уж бороться за уместность и эффективность использования вычислительных средств, начинать надо с анализа особенностей приложений, препарирования всех вычислительных подсистем и их взаимосвязей.

Под «капотом» сервера есть много потенциально узких мест, которые не становятся шире с добавлением процессорной мощности. Это проявляется не только в специализированных приложениях с избирательной нагрузкой. Так, мода на виртуализацию подняла планку требований к общему балансу подсистем массовых серверов. Не случайно Intel уделяет сейчас так много внимания шинным обменам, сетевому и дисковому вводу/выводу. Относительно скромный прогресс и ограничения периферийных систем обмена данными обесценивают достоинства основного продукта компании — процессоров. Наиболее радикально пересматриваются модели хранения данных и транспортных средств их доставки — благодаря стремительному распространению твердотельных накопителей SSD на флэш-памяти NAND. Для объемного хранения основным носителем еще долго будут оставаться HDD. Но, при всем прогрессе стандартов, протоколов и интерфейсов от жестких дисков с вращающимися поверхностями невозможно добиться скачка производительности — из-за механических ограничений. Пришло время других технологий. Пока что SSD прочно обосновались в персональных устройствах. Посмотрим на положение дел на консервативном рынке корпоративных приложений.

Производительность дисковых подсистем

Для оценки производительности дисковой подсистемы пользуются двумя параметрами: потоковой скоростью чтения/записи (Megabyte per second, MBps) и количеством обрабатываемых в единицу времени операций ввода/вывода (Input/Output operations Per Second, IOPS). Какому из них отдавать приоритет и за что бороться — зависит от реального набора приложений. Скорость потоковых обменов важна при работе с данными преимущественно последовательного доступа (Sequential Read/Write): передаче видеопотоков высокого разрешения, в графических приложениях, в задачах 3D-моделирования, при операциях с файловыми архивами. Способность подсистемы хранения данных быстро обслуживать множественные запросы критична в операциях с преимущественно случайным доступом (Random Read/Write) — как в серверах баз данных, электронной почты и приложений, в виртуализированной среде.

Выбор носителей в серверах и системах хранения данных (СХД) диктуется характером приложений и требованиями доступности данных. Для долговременного статичного размещения больших объемов (например, как в файловых серверах) используют недорогие и емкие диски SATA RAID Edition 7200 rpm. В станции разработчика уместны диски SATA 10k rpm, а в среде коллективного доступа к объемным материалам (например, в сервере документооборота) — диски SAS NL 7200 rpm. В задачах с высокой интенсивностью конкурентных запросов (как в серверах нагруженных баз данных и кворум-ресурсах) традиционно используются диски скоростные диски SAS 10-15k rpm. И именно здесь велики перспективы SSD. В СХД многоуровневого хранения, с сортировкой данных по ценности, критичности доступа, востребованности, сочетаются разные типы накопителей.

Производительность дисковых операций, сохранность и состоятельность данных обеспечивает дисковая подсистема, как правило состоящая из RAID-контроллера и набора накопителей. RAID-контроллер работает под управлением ОС и собственных программных средств. Производительность RAID-массива зависит от многих факторов: характера приложений и доступа к данным (последовательный/случайный), типа и количества дисков, соотношения операций чтения/записи, архитектуры RAID-контроллера, выбранного уровня RAID, степени заполнения дисков.

Кэширование дисковых операций: уровни, выгоды, риски

Для ускорения дисковых операций с данными на таких относительно медленных устройствах как HDD используется кэш — буферная среда, промежуточная память с высокой скоростью доступа. Кэширование, как оптимизация работы с часто запрашиваемыми («горячими») данными — мощный инструмент повышения производительности в многопользовательском многозадачном окружении. Кэширование дисковых операций многоуровневое, в нем участвуют операционная система, приложения, контроллеры устройств хранения, сами накопители. ОС и приложения используют под кэш дисковых операций часть оперативной памяти. У аппаратных RAID-контроллеров есть собственные процессор и динамическая память — кэш-буфер для размещения данных, вычисления контрольных сумм и обработки очередей запросов. Есть кэш и у HDD.

На поверхности лежит идея кэширования всей базы данных в оперативной памяти. Работает быстро, но небезопасно: информационная система данные не только читает, но и пишет, отказ питания или сбой ОС убивает данные. Как правило, за кэширование данных отвечают RAID-контроллеры (иногда файловые системы — как ZFS). Продуктивность зависит от процессора контроллера, его встроенных алгоритмов и политик кэширования. А вот, к примеру, размер кэш-памяти RAID-контроллера на производительность как раз влияет мало. Контроллер с 1GB кэш-памяти одного производителя не лучше и не хуже контроллера с 512MB другого производителя. Разработчик контроллера сам выбирает оптимальный (разумно-достаточный) размер кэш-буфера.

Кэширование чтения дает понятный и предсказуемый выигрыш. Сложнее обстоит с записью. Есть две основные политики записи: прямая, она же сквозная (write-through) и обратная, или отложенная (write-back). При сквозной записи контроллер, получив данные, пишет их непосредственно на диски массива и подает управляющей ОС сигнал о завершении операции. При отложенной записи контроллер тоже рапортует ОС об успешной транзакции записи, но данные записывает в свой кэш-буфер. На диски они попадут позже — в подходящий с точки зрения контроллера момент, при снижении активности приложения или по заполнению кэша. Технология обратной записи дает серьезный скачок производительности, но на некоторое время делает данные на дисках неактуальными. ОС же считает данные на дисках состоятельными всегда. В этом кроется угроза целостности информации. Сбой питания может прервать транзакции и привести к необратимому разрушению RAID-массива.

Ощутимые выгоды от включения режима write-back заставляют компенсировать возникающие риски дополнительными мерами предосторожности. Обычно кэш RAID-контроллеров защищают с помощью аккумуляторов (Backup Battery Unit, BBU), способных после обесточивания контроллера держать напряжение в течение суток-двух, сохраняя содержимое кэша. После восстановления питания прерванные транзакции завершаются, состоятельность массива сохраняется. BBU, как и любые аккумуляторы, имеют ограниченный срок службы, постепенно теряют емкость и нуждаются в замене каждые полтора-два года. Не проводя регулярной профилактики серверов, можно однажды, того и не подозревая, остаться с незащищенным контроллером. В последние годы получила распространение технология безопасной защиты кэш-памяти контроллера, не требующая обслуживания. Аварийное копирование содержимого кэша в энергонезависимую флэш-память запитывается постоянно заряженным конденсатором большой емкости. После восстановления питания данные из флэш-памяти копируются обратно в кэш контроллера. Надо сказать, у большинства RAID-контроллеров невозможно включить режим write-back при неустановленных BBU или флэш-модуле защиты кэша.

Подключение сервера через источник бесперебойного питания (UPS) снижает вероятность разрушения массива от аварии по питанию, но не заменяет BBU полностью — ведь между UPS и дисками остается много потенциальных «смертников»: блок питания сервера, материнская плата с процессором и памятью, сама память и кабельные соединения. Для надежности нужны и UPS, и BBU.

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

Как устроены SSD, и чем они отличаются от HDD

Преимущества и недостатки SSD

Первый бытовой восторг вызывает способность SSD стартовать ОС и открывать приложения за несколько секунд — против минуты с лишним для старта с HDD. Низкая латентность (малое время доступа), на два порядка меньше, чем у HDD — основной козырь твердотельных накопителей. Радикальное ускорение загрузки приложений и рост общей производительности следуют из природы работы с памятью, каковой являются SSD. В HDD головкам надо сперва выполнить прицеливание над рабочей поверхностью, а потом последовательно, оборот за оборотом, провести операцию чтения или записи. SSD — это система работающих параллельно 8-16 конвейерных линий, с высоким уровнем готовности.

В SSD нет движущихся частей, HDD построены на пластинах, вращающихся со скоростью в пределах 5400-15000 оборотов в минуту. От механической природы HDD все его беды-попутчицы: высокое энергопотребление, ограничения температурных режимов, необходимость в теплоотводе, наведенные вибрации. Риск потери накопителей и данных нарастает при плотной компоновке компьютера. Смерть HDD почти равносильна потере данных на нем (точнее, их восстановление может обойтись непомерно дорого). Когда же заканчивается жизненный ресурс SSD, становится невозможной запись на него, но данные остаются доступными. В ячейках флэш-памяти NAND информация может сохраняться годами. SSD работают в широком диапазоне температур, выдерживают большую ударную нагрузку. Типичные допустимые для SSD значения: температура от −20 до 85° С, влажность 90%, переносимая нагрузка 1500G.

Главный недостаток SSD — ограниченное количество переносимых ими циклов перезаписи (от 10 до 100 тысяч на ячейку). Тем не менее, существующий разброс технологий производства памяти, контроллеров, конструктивных решений и прошивок позволяет применять SSD в большом диапазоне персональных и корпоративных приложений. Вопрос только в цене и оправданности решения. Невысокая в сравнении с HDD емкость (или, иначе, высокая цена достижения большой емкости) — еще один недостаток SSD, хотя и относительный.

Устройство и источники производительности SSD

SSD имеют разную компоновку, форм-фактор, интерфейс, даже могут быть бескорпусными. Но во всех SSD есть основная плата (PCB), контроллер и несколько модулей флэш-памяти NAND. Как правило, SSD имеют интерфейс SATA (SATA 2 или SATA 3) и подключаются через стандартный SATA или компактный mSATA разъем. Есть SSD c интерфейсом SAS. Существуют и контроллерные сборки SSD под шину PCI Express.

Подавляющее превосходство SSD над HDD в низкой латентности понятно — работа параллельных конвейеров прямого доступа многократно эффективнее процедуры механического прицеливания к данным, с вычитыванием их одним-единственным маршрутом, тогда как контроллер SSD общается с памятью по нескольким маршрутам («каналам»). Но одной только архитектурой не объяснить природу производительности. Разница показателей двух твердотельных накопителей между собой может быть огромной, какой никогда не бывало между HDD. Источники производительности SSD — контроллер, флэш-память и прошивка. Многообразие сочетаний порождает множество продуктов для разных целевых рынков и... путаницу в головах. Один и тот же контроллер может использоваться с разными типами памяти (асинхронная, синхронная, toggle mode) — для разведения SSD по потребителям и ценовым нишам. Один и тот же производитель может использовать разные контроллеры в своих продуктах. Так, Intel ставит в свои SSD 520-й и 330-й серий контроллеры SandForce, в 510-ю серию — контроллеры Marvell, а в 320-ю и 710-ю — свои собственные. В любом случае, основным субъективным фактором для выбора SSD все равно остается предполагаемая модель применения накопителя. И рекомендации производителя.

Рабочая емкость и overprovisioning

Традиционно емкость SSD считалась в степенях двойки — от восьми ячеек по 4GB и выше, а производители поначалу заявляли весь реальный физический объем памяти, распаянной на PCB: 32 — 64 — 128 ... GB. Теперь в ходу округленные емкости: 30 — 60 — 120 — ... GB — что говорит о применении производителями избыточного резервирования (overprovisioning). Часть памяти SSD отводится под невидимую и недоступную пользователю служебную область. Известно, что по мере заполнения SSD, заметно падает его производительность, и сокращается срок службы. Причина в том, что контроллер при записи постоянно выполняет циклы переноса содержимого ячеек/их стирания. Чем меньше свободного пространства — тем затейливее алгоритмы перемещения данных и сильнее износ ячеек. Увеличением свободы маневра для контроллера за счет резерва свободных ячеек добиваются роста производительности и срока службы SSD. Не только производители SSD делают избыточное резервирование по умолчанию, они еще и рекомендуют пользователям оставлять часть емкости неформатированной. Сколько памяти резервируют сами производители — их внутреннее дело, и зависит это от позиционирования SSD. Так, у SSD Intel 710-й «серверной» серии при задекларированной емкости 200 GB и доступной пользовательской емкости 186.3 GB «сырая емкость» микросхем памяти составляет 320GB (20 микросхем по 16GB), то есть показатель overprovisioning превышает 70%.

Магия чисел и суровая правда жизни

Задача маркетинга — продавать. Потому на рынке так мало анализа отличий между SSD, и так много шумихи вокруг показателей вроде «550 MBps на чтение или 520 MBps на запись». Запустив мониторинг типичных дисковых операций даже на обыкновенном ноутбуке или ПК, можно обнаружить, что потоковые операции c большими блоками (те самые Sequential Read/Writes 550/520MBps) составляют не более 1% (!) дисковой нагрузки. В то же время более половины операций — это запись короткими блоками 4К со случайным доступом (Random Write). Потому, заглядывая в паспорт SSD, надо смотреть в первую очередь на показатели Random Write I/O, даже если речь идет о персональных приложениях. А тем более, выбирая SSD под корпоративные приложения.

Популярность контроллеров SandForce объясняется рекордной скоростью последовательной записи — благодаря сжатию информации перед ее помещением в память. Кроме скорости работы за счет этого еще и увеличивается ресурс накопителя. Если бы других операций и типов данных не было — то контроллерам без компрессии (Intel, Marvell, Everest, Samsung) не осталось бы применения. На практике и данные плохо сжимаются (современные форматы Office, изображения, видео- и аудиофайлы), и операции не потоковые. Результаты тестовых лабораторий подтверждают, что запись несжимаемых данных случайным образом — это худшее, что можно сделать с твердотельным накопителем на SandForce.

В серверах важны показатели записи в операциях случайного доступа (с чтением хорошо у всех SSD), прогнозируемый предел по числу циклов перезаписи, среднее время наработки на отказ. Если сам производитель не позиционирует SSD для применения в серверах (например, прямо пишет, что продукт — геймерский) — это значит, что компонентная база, алгоритмы работы контроллера, резерв ячеек и запас прочности не рассчитаны на продолжительную работу в ответственных приложениях. Зачем испытывать судьбу?

SLC, MLC, MLC-HET, продление ресурса

Есть две технологии изготовления флэш-памяти NAND: MLC (Multi-level cell, c многоуровневыми ячейками) и SLC (Single-level cell, c одноуровневыми ячейками). По ресурсу перезаписи SLC (более 100 000 циклов) на порядок превосходит MLC. По цене тоже. SSD на памяти SLC применяются в критичных корпоративных приложениях, большей частью в дорогих СХД. Остальные довольствуются MLC. Позиционирование SSD, выполненных на одной и той же MLC-памяти может сильно разниться. Отличаются производительность контроллеров, их способность балансировать нагрузку и компенсировать неравномерный износ накопителей. Могут применяться конструктивные решения, снижающие риск потери данных. Так, в SSD Intel сериq 320 и 710 есть ускоритель аппаратного шифрования и цепи конденсаторов для защиты данных от перепадов напряжения. SSD 710-й серии на MLC-памяти Intel выпускает для корпоративного рынка и даже ввела для них новый термин MLC —HET (High endurance technology). По сути, отличие MLC-HET — в повышенной износоустойчивости за счет производственного отбора кристаллов памяти MLC, изменения алгоритмов работы контроллера (увеличения цикла программирования страниц и усиления записи), и за счет избыточного резервирования емкости. SSD Intel 710-й (MLC-HET) и 320-й серий (MLC) сделаны на одном контроллере, но по цене различаются вчетверо. MLC-HET можно считать разумным компромиссом в борьбе за емкость, как у MLC, и выносливость, как у SLC.

Перезапись ячеек, «сбор мусора», TRIM

В отличие от HDD, в ячейку флеш-памяти NAND нельзя перезаписать новые данные поверх старых, не очистив ее перед этим. Ячейки памяти SSD сгруппированы в страницы (обычно по 4 Кбайт каждая), страницы сгруппированы в блоки (64-128 страниц). Данные можно вписать на чистую страницу, но стирать можно только блоки целиком. Запись на SSD-носитель выполняется очень быстро до тех пор, пока существуют чистые страницы, но значительно замедляется, если необходимо очищать предварительно записанные страницы.

Твердые телом. Как раз такие в серверах и нужны

Запись и стирание ячеек в SSD [источник: Wikipedia]

Для очистки ячеек от неиспользуемых данных и поддержания резерва пустых страниц контроллер SSD выполняет процедуру «сбор мусора» (Garbage collection, GC). Чтобы вернуть в обращение ячейки блока, содержащего смесь актуальных данных и мусора (невалидных данных), контроллер копирует нужное (валидные данные) на пустую страницу нового блока, а затем стирает весь исходный блок. После этого ячейки блока будут готовы принять новые данные. Избыточное резервирование емкости SSD (производителем и пользователем) облегчает труд мусорщиков и смягчает проблему снижения производительности/срока службы с заполнением SSD.

Твердые телом. Как раз такие в серверах и нужны

Перезапись страниц и «сбор мусора» [Источник: www.thessdreview.com]

Агрессивность сборщика мусора зависит от контроллера, его прошивок и назначения SSD. В десктопных SSD уборка мусора может быть вялым непрерывным фоновым процессом, тогда как в SSD для корпоративных приложений контроллер анализирует активность и использует время простоя для наведения порядка. Обратная сторона агрессивного сбора мусора — повышенный износ . В контроллерах SSD могут быть реализованы различные техники увеличения производительности и продолжительности жизни (усиление записи, выравнивание износа).

Эффективность борьбы за производительность и продление ресурса SSD зависит от обмена информацией между ОС и контроллером SSD о том, какие страницы могут считаться занятыми, а какие свободными. Накопитель не имеет доступа к структурам файловой системы, таким как список неиспользуемых кластеров, и остаётся в неведении об освобождении блоков. В последних релизах многих ОС была введена команда TRIM для своевременной очистки неиспользуемых ячеек до того, как в них будет произведена запись. TRIM — это уведомление твердотельного накопителя операционной системой о логических адресах ячеек, где хранятся неиспользуемые данные. Эти ячейки можно немедленно готовить к записи. При содействии ОС, контроллер убирает не только свой «плановый» мусор, а по команде TRIM еще и тот, на который ему указала ОС. Понятно, что применение TRIM может снизить объем операции по очистке и в какой-то степени упредить снижение производительности и ранний износ.

Модели использования SSD в серверах

Консервативный рынок корпоративных приложений оценивает не характеристики отдельно взятых накопителей, а их поведение под реальной нагрузкой. Высокие паспортные показатели 4K IOPS (на запись при случайном доступе) — еще не автоматический пропуск в серверы. Пользователей, привыкших к логике работы дисковых массивов HDD под управлением RAID-контроллеров, интересует, какими средствами обеспечивается надежность хранения на твердотельных накопителях и их практический пробег. В зависимости от модели использования SSD в сервере пользователь может остановить свой выбор на любом типе накопителя. В терминах продуктовой линейки Intel это может быть 320-я серия на MLC-памяти, 710-я серия на MLC-HET c повышенным ресурсом на износ, совместный с Hitachi продукт SAS SSD на памяти SLC или PCIe MLC SSD 910-й серии. Главное, чтобы выбор был осознанным и свободным от маркетинговых наслоений.

RAID-массивы на SSD

Основной сдерживающий фактор для распространения в серверах массивов из одних только твердотельных накопителей — ограниченные возможности RAID-контроллеров на шине PCIe по числу обрабатываемых IOPs. При типичных для SSD показателях интенсивности чтения 30-40K IOPs, вычислительной мощности процессора RAID- контроллера (100-150K IOPs) в реальных задачах может не хватить для обслуживания массива уже из 3-4 SSD. Здесь важно отметить, что обычные контроллеры рассчитаны на работу с HDD и учитывают их геометрию. Часть ресурсов процессора RAID-контроллера уходит на оптимизацию опросов и пути головок над поверхностью дисков, перестроение очередей чтения и записи. А SSD — это память, со своим встроенным контроллером, таблицей адресов и собственным кэшем. Когда контроллер воспринимает SSD, как HDD, он выполняет ряд бессмысленных вычислений. Отключение ненужных, тратящих циклы процессора проверок и оптимизаций, привело бы к скачку производительности. Разработчики RAID-контроллеров так и поступают — хотя их действия выглядят нелогично: к дорогостоящему контроллеру продается опциональное ПО (Fast Path для RAID-контроллеров LSI), роль которого — отключить «интеллект» контроллера (то, из-за чего он стоит дорого) при создании массивов из SSD. Но другого способа обслужить десяток и больше SSD пока нет. Ситуация изменится с выходом многоядерных RAID-чипов производительностью выше 450K IOPs и контроллеров на их.

Свою нишу определенно займут контроллерные сборки SSD на шине PCIe: Intel SSD PCIe 910-й серии на MLC-памяти, где на одной плате четыре контроллера Hitachi SAS SSD работают под управлением LSI RAID, и собственный продукт LSI — WarpDrive SLP-300 на памяти SLC, c шестью контроллерами SandForce-1500 под управлением LSI RAID. Розничная цена $2.5K за первый и $13.7K за второй считается адекватной ожидаемым от них показателей 75K IOPS и 190K IOPS на запись соответственно.

Гибридные массивы

Комбинирование SSD и HDD как рабочей среды хранения данных в серверах и дисковых массивах позволяет создавать эффективные по стоимости решения корпоративного класса. В большей степени «гибридизация» затронула СХД, где используется управление жизненным циклом данных. По мере «остывания» данные в них перемещаются со скоростных носителей (SSD, SAS 10-15K) на менее дорогие SAS NL, SATA. В серверах гибридные RAID-массивы из cмеси дисковых и твердотельных накопителей мало популярны и применяются как компромиссное решение для объединения преимущество быстрого чтения c SSD и предсказуемой сохранности данных на HDD. SSD вводятся в RAID-массив как основной носитель, при этом данные читаются с SSD, а пишутся на HDD и SSD одновременно. Результатом является увеличение IOPS на чтение без снижения общей производительности записи и полная прозрачность для операционной системы и запускаемых приложений.

SSD-кэширование

Этот подход продвигают производители СХД и RAID-контроллеров, адаптировав свое программное обеспечение под работу с SSD. Динамическое кэширование чтения/записи для ускорения ввода/вывода выполняют все RAID-контроллеры, в своей памяти DRAM. В RAID-массиве на дисках HDD это единственный аппаратный кэш. Логика его работы основана на анализе запросов (learned-path algorithm), и размещении в кэш-памяти часто запрашиваемых или «горячих» данных. То же самое можно делать, добавив SSD в качестве промежуточного звена между контроллером и RAID-массивом на HDD. При адаптации дисковой подсистемы под реальной нагрузкой на SSD накапливаются и в процессе работы обновляются «горячие» данные. Cмещение активности ввода/вывода с HDD на более скоростную память достаточно большого объема позволяет поднять производительность дисковой подсистемы в целом и снизить число обращений к вращающимся носителям. RAID-контроллер управляет SSD, как кэшем второго уровня, только емкость этого кэша в сотни раз больше размера собственной DRAM, а память у SSD постоянная.

Твердые телом. Как раз такие в серверах и нужны

SSD кэширование в RAID-массивах HDD [источник www.adaptec.com]

Технология позволяет поднять скорость работы массивов HDD без значительных начальных вложений, что делает ее привлекательной для массового рынка серверов ответственных приложений. Используется привычная программная среда настройки дисковой подсистемы и простые, интуитивно понятные инструменты для управления пулами SSD/HDD. Еще одно важное преимущество состоит в снижении капитальных и операционных затрат: уменьшение нагрузки на HDD упрощает дисковую подсистему и серверы в целом. Самый большой прирост производительности достигается в новостных веб-серверах и приложениях электронной коммерции — задачах с преобладанием коротких запросов случайного чтения. В разной степени эффект наблюдается под всеми рабочими нагрузками, критичными к IOPs: в cерверах баз данных, файловых серверах, системах электронной почты.

Прогноз

Серверный рынок еще не скоро откажется от HDD, как минимум объемное хранение в обозримом будущем без них невозможно. Скорее произойдет расслоение приложений и исполняющих их серверов — на устройства, чувствительные к скорости доступа к данным, и неспешные системы хранения статичного контента. Продвижению прогрессивных подходов мешает консерватизм рынка. Как ни странно, склонный к тотальной экономии заказчик сервера начального уровня скорее потратится на RAID-контроллер и связку HDD, чем поставит в сервер один-единственный SSD MLC-HET — хотя SSD обойдется дешевле, будет многократно производительней, риск потери данных минимален, а данных у предприятия — кот наплакал, и ему большой объем HDD просто не нужен.

Можно ожидать поляризации процесса проникновения SSD в серверы. Они заменят HDD в недорогих системах, ориентированных на операционную эффективность (веб-магазины, агрегаторы, маршрутизаторы, фильтры), и начнут вытеснять HDD из самых дорогих серверов — критичных приложений масштаба предприятия. Вырастет интеллектуальная составляющая дисковых подсистем, представленная RAID-контроллерами и специализированными файловыми системами. «Температурный» анализ данных станет рядовой функцией, алгоритмы работы с «горячими» данными изощреннее, а многоуровневое хранение — признак благородных СХД за $50K — будет реализовано в массовых серверах стоимостью до $10K.

Ждем развития событий.

+1515
голосов

Напечатать Отправить другу

Читайте также

Жаль, что Intel сняла с производства замечательную Intel SSD 320 series со встроенным суперконденсатором - была отличная альтернатива SAS дискам в серверы под небольшие базы данных (той же 1С, к примеру) :-(.

Тема пропуска TRIM через RAID-контроллеры осталась нераскрытой...

А они TRIM не пропускают, поговорить не о чем.

Понятно, спасибо

К сожалению, команды TRIM в протоколе SAS на данный момент не предусмотрено.
Очевидно, что SAS RAID-контроллеры эту команду и не пропускают.
Все современные аппаратные RAID-контроллеры - SAS.

Спасибо, а что насчёт "программных" чисто SATA, типа Adaptec 1430SA или Areca ARC-1210/1220?

Если вы про TRIM, то никакие RAID-контроллеры, ни фейковые, ни аппаратные SATA эту команду не поддерживают. Старые контроллеры просто не знают что такое TRIM, а все новые - Unified SAS RAID architecture. Насколько я понимаю, хороший overprovisioning + GC снимают проблему падения скорости записи с наполнением SSD. И обходятся без TRIM. Просто не жалейте заварки.

Ясно, ещё раз спасибо за информацию :)

На самом деле была (или даже есть) интересная ситуация с материнскими платам на чипах Intel 202 и 204 серии.
Там при создании soft-RAID с точки зрения авторов драйверов от Intel команда TRIM работать не должна была... но работала.
Вероятнее всего, по той причине, что RAID имел представление как RAID на уровне драйверов Windows, при этом сами диски где-то на каком-то уровне воспринимались как отдельные SATA-устройства.
С выходом 206 чипсета с унифицированной SAS архитектурой эта "фича", скорее всего, работать уже не будет.

Обычно тему TRIM & RAID обсуждают в контексте "как нарастить объем SSD и при этом избежать деградации скорости записи". RAID 0 на бортовом контроллере на нескольких SSD, да без overprovisioning'а - совсем не серверная комбинация. Никто не запрещает, но и рекомендовать не станем.

Сейчас некоторые сборщики серверов предлагают 330 серию, как я понимаю она уже имеет интерфейс 6 Gb/s. насколько она лучше или хуже 320 серии?

Каким образом настраивается overprovisioning на RAID 10 массиве из SSD? Меньшим выбором доступного объема со всех дисков? Даст ли это прирост надежности?

330-я серия - это SSD для ПК. От 320-й серии их отличают: плохие показатели записи под нагрузкой случайного доступа, меньше показатели живучести (число циклов перезаписи), отсутствие конденсаторных цепей в тракте записи, другие прошивки, полное отсутствие оверпровиженинга. Взамен 320-й интел рекомендует 520-ю серию, но никак не 330-ю. Оверпровиженинг - это принудительное занижение паспортного объема SSD при инициализации диска. Все что пользователь отдал контроллеру SSD как служебную область, возвращается к нему сторицей - в виде роста производительности операций записи и долгих лет жизни диска. Чем больше простор, недоступный пользователю, тем меньше износ ячеек рабочей области.

Intel SSD 330 series категорически недопустим для использования в серверах. Потому как его реальная производительность сравнима скорее с производительностью не очень быстрых HDD.
Ничего общего с 320 серией он не имеет.
Его предназначение - давление на рынок сверхдешевых устройств.
По рекомендациям Intel его можно ставить в недорогие ноутбуки и ПК. В ПК и ноутбуки среднего уровня - уже позиционируется 520 серия.
Overprovisioning настраивается тем, что не менее 20% остается не размеченными. Чем больше оставили не размеченными - тем лучше. К примеру, у 710 серии под overprovisioning выделено на уровне производителя 42% емкости микросхем и рекомендуют выделять еще минимум 20% от оставшейся емкости - т.е. реально там получается под overprovisioning более 50% емкости отведено. Ну на это где-то и нужно ориентироваться.

Прошу уточнить про overprovisioning. Допустим я хочу собрать RAID 1 из 2-х SSD на внешнем контроллере Intel. Мне отдавать под массив всю емкость дисков, а потом в операционной системе размечать только часть? Или же средствами контроллера делать LUN меньшего размера?

>Допустим я хочу собрать RAID 1 из 2-х SSD на внешнем контроллере Intel
Двум SSD не нужен внешний контроллер. Постройте зеркало на бортовых портах материнской платы.
>уточнить про overprovisioning
Overprovisioning (OP) - это когда при разметке SSD вы оставляете его часть неотформатированной. ОС будет работать с размеченной частью диска. Остальную часть контроллер SSD будет использовать как служебную область.

А лучше возьмите пару SSD, предназначенных для использования в серверах и ограничьтесь заводским OP, побольше (как в серии Интел 3700) или поменьше (как в Интел 3500) - в зависимости от операционной нагрузки.

Спасибо за ответ.

> Двум SSD не нужен внешний контроллер
Сейчас имеем такую конфигурацию:
Бортовой контроллер с 4-мя портами - не задействован
На внешнем контроллере RS2BL080 такая конфигурация:
- RAID 10 из 4-х SATA (VelociRaptor). Тут находится система, сервер 1С, MS SQL (общие таблицы), логи всех таблиц + планируется перенести сюда базы бухгалтерии (5 штук примерно по 2 Гб каждая)
- RAID 1 из SSD Intel 3500 (120 Гб) под TempDB
- RAID 1 из SSD Intel 3500 (300 Гб) под основную базу управление торговлей (60 Гб).

Вроде как у серии 3500 пространство под overprovisioning не очень большое. Поэтому и задался вопросом - его расширить.

Имеет ли смысл RAID 1 c TempDB перенести на бортовой контроллер (теоретически должно работать быстрее)?

Серии 3500 MLC и 3700 eMLC - на одном контроллере. Фактически отличаются размером фабричного OP (у 3700 он примерно втрое выше). Отражается это на двух показателях - Random Write 4К IOPS и Endurance. К примеру, для SSD 200GB серии 3700 и 300GB серии 3500 имеем:
- по Random Write - 32 KIOPS у 3700 против 9 KIOPS у 3500
- по живучести - 10 перезаписей всего SSD в день в течение 5 лет у 3700 против 170TBW у 3500.

Если природных иопсов 3500 вам мало - лучше поставить 3700, чем руками править OP у 3500.

При работе с SSD всегда имеет смысл использовать принципа разумной достаточности. Если у вас БД 100GB и рост 20GB в год - то имеет смысл взять минимум 200GB SSD, разметить из них 160 и исходить из того, что через 3 года вы их либо поменяете, либо расширите.
Overprovisioning будет полезен любым SSD, т.к. снижает износ ячеек диска. Intel 3700 за счет большего заводского объема overprovisioning рассчитан на большие нагрузки, чем та же 3500 серия. И, соответственно, 3700 "от рождения" более живуч и более быстр.
Главный же вопрос - это ваша реальная потребность в IOPS на запись и объемы перезаписи в день. Просто измерьте ее Perfmon, и принимайте решения.

Благодарю за ответы. Будем пробовать

Жуковский с Тищенко дискутируют :) Приятно поговорить с умным человеком :)))

Владислав, когда мы уже дождемся вашей публикации? Напишите, обсудим. Например, какой IBM прикладывать к ранам - чтоб рубцевались быстрее.

:) Андрей, IBM лучше не к ранам прикладывать, а до их возникновения применять. Например, eXFlash.
но надо сказать, что тоже от отсутствия геморроя не гарантирует...

Хотел сказать, что, по моему мнению, Вам не совсем корректно комментировать Юрия

Я вас понял, странно, что известная достаточно компания по продаже серверов представила мне конфигурацию именно на 330 ссд...
У меня стоит конкретная в данный момент задача, подобрать конфигурацию сервера SQL, база данных 1с порядка 140 Гб, пользователей всего 10-18, но очень много периферийных баз, в течение дня идет обмен с данными базами и соответственно офис замирает. сервер, который обслуживает сейчас данную базу очень слаб, ему порядка 5-6 лет уже. Также на нем стоит приложение Сервер 1с.
Мучаюсь с выбором уже долго, понимаю что нужно использовать ссд, но под объем базы такой покупать 4 шт 710 по 100 гб в 10 рейд, боюсь что не хватит запаса объема и на год. да и по цене получается космическая. Смотрю в сторону 320 моделей 300 Гб.
желательно под систему поставить HDD? и RAID10 из 4 ссд под базу?

Есть ли смысл брать дорогущий Рейд контроллер от адаптека или LSI? или можно под зеркало и 10 рейд взять простые без кэша и батарейки?

И какой все таки контроллер выбрать от Адаптека или от LSI ?? Есть опыт работы с Адаптеком 6805 +AFM проблем не возникало.

Павел, а вариант взять в аренду не рассматривали? Это избавит Вас от мучений выбора. Например, услуга "Облачный датацентр" от De Novo позволит Вам самостоятельно создать сервер(ы) нужной конфигурации. Сервер 8GHz 16GB 150GB vHDD-A обойдется ~$450 в месяц. Диски класса A способны стабильно отдать 10-12K IOPS на OLTP-нагрузке с латентностью <5ms и ~700 MB/s при последовательном чтении/записи. Если так много не нужно - есть диски класса B (~2500-3000 IOPS), они в 3 раза дешевле. Для холодных данных и резервных копий есть vStorage (виртуальная СХД, вы ее сами нарезаете на iSCSI/CIFS/NFS диски) по цене ~$120/TB. И это все уже отказоустойчивое как на уровне вычислительной, так и на уровне инженерной инфраструктуры (TIER III). "Впрок" ничего брать не нужно - Вы можете менять объем потребляемых ресурсов по мере необходимости.

О небо, боги сошли на землю. Геннадий, мы в самом деле рады появлению в публичном пространстве предложений по аренде в облачных ДЦ. Банкам-банково, человекам - человечье. И очень хорошо, что пользователи с поставщиками начинают говорить на языке потребности приложений в ресурсах, а не понтов.

Андрей, по поводу богов вспомнился анекдот.
- Слышал, ты женился? Ну и как жена?
- Да нормально. Все говорят, на божью мать похожа.
- Да ну!
- Не веришь - приходи в гости.
Звонок в дверь, открывает жена.
(Хватается за голову) - Матерь божья...

Ну куда-то двигаться надо же. ЦОД продан на 2/3, оставшееся более-менее уже расписано. Так что потихоньку будем подбираться и к вашему сегменту, только сверху.

Сервер 8GHz 16GB

Геннадий, не продешевите за 8 ГГц-то?

Владислав, как ни напрягался - смысла реплики не понял. Что смутило то - цена, единицы измерения или что-то еще?

Предположу, что вопрос - к спецификациям процессора.
К примеру, топовый Intel® Xeon® Processor E5-2690
(20M Cache, 2.90 GHz, 8.00 GT/s Intel® QPI) по данным Intel, обладает частотой 2.90 GHz и в режиме Max Turbo Frequency 3.8 GHz.
У Вас указана частота 8 GHz, что несколько больше незапланированных Intel. Просят пояснить эту цифру.

именно. не помню процессоров с тактовой частотой выше, чем у Power6

Welcome to Cloud! В облаках и виртуальных инфраструктурах GHz - очень распространенная единица измерения процессорной мощности. Иначе говоря, это количество выделенных процессорных циклов. Как они отобразятся на vCPU зависит от частоты физических ядер и желания Заказчика. Понятно, что 8GHz на один vCPU отобразить невозможно. Но можно на 4, а если хочется - на 12 или 16.
Также очевидно, что, помимо GHz, играет роль и поколение процессоров. Поэтому мы используем единицы GHz-GX, где X=4 для E5/E7, 3 для 56xx и т.д. Но это уже тонкости.

:)) vMotion еще порекламируйте :)

Геннадий, то, что вы используете виртуальную арифметику, делает не вполне корректным ваше коммерческое предложение "Сервер 8GHz 16GB 150GB vHDD-A = $450 в месяц". Пользователь сравнивает владение сервером на типовых компонентах и аренду. В его прежней физической реальности таких гигагерцев не было, он чует подвох. Получается, что, заманивая его в облако, вам придется провести минимальный ликбез: чем виртуальный процессор отличается от реального, и как связана потребность в процессорных циклах с набором приложений. Чем ниже в массы, тем чаще придется сталкиваться с неглубокой квалификацией и недоверием к методике расчета облачных параметров. Возможно, упирать надо не на обещание вычислительной мощности, а на легкость и эластичность ее изменения (в большую сторону - с доплатой, в меньшую - с уменьшением квартплаты). Помогли бы детальные кейсы-калькуляторы (аренда против покупки), хоть бы и на примере уже имеющихся приложений ваших арендаторов (на условиях анонимности).

Андрей, все верно, так мы и делаем. Есть и детальные описания моделей использования, и калькуляторы, и кэйсы (заглянул на портал, за последние полгода просчитано 57 кэйсов), и, наконец, возможность бесплатного тестирования (в Облаке эта процедура значительно менее энергозатратна, чем в случае физического железа).
Лобовое сравнение облачный сервер <-> физический сервер не совсем корректно, т.к. мы продаем не серверы, а виртуальные датацентры, с сетью (включая межсетевые экраны, VPN-терминаторы, маршрутизаторы), безопастностью, отаказоустойчивостью, интерфейсами управления, системным ПО (по желанию) и, конечно, эластичностью. Так что корректное сравнение - это сравнение платформ для развертывания того или иного прикладного ландшафта.

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

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

куда им, региональным, до корпораций, про которые гуглу не ведомо...

Облако - не значит Интернет. Выделенные каналы в последние годы стали более-менее доступны даже в регионах. У нас есть примеры, когда регионы пользуют SAP из нашего Облака. Вполне довольны.

"странно, что известная достаточно компания по продаже серверов представила мне конфигурацию именно на 330 ссд"

И мне это кажется странным. Похоже на ошибку менеджера, 330-ю серию ставить под серверные приложения нельзя. У вас БД приличного размера, да еще с активными обменами. Вам нужны SSD с высокими показателями Random Write IOPS и Endurance - как минимум Intel 710 сейчас (или 3700 через месяц, как появятся). 4 х 100GB Intel 710 обойдутся дешевле $2K, а по производительности покроют 20-25 дисков SAS 15K. Космическая это цена или нет - решайте сами, с учетом ценности ваших данных. 320-я серия выйдет на показатели 710-й, если ей отрезать половину объема под служебную область(OP). Adaptec 6405/6805 LSI 9266-4i/8i с 4 SSD управятся. Роль кэша и батарейки в массивах SSD не так принципиальна как HDD-массивах.

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

Планируется процессор E5-2620, 48 или 64 Гб RAM, 2 HDD SAS SATA под систему в зеркало, 4 SSD intel 320 300 Гб (100 Гб из каждого под OP), Контроллер Adaptec 6805 (привычнее))
Из 10 рейда на SSD получим 400 Гб полезного объема, предварительно хватит как минимум на 2 года с их объемами. Вопрос только в том насколько долго продержатся SSD.
Может быть оценить объем записываемых данных в течение суток? чтобы понять какая нагрузка? Но только вот проблема никогда этого не оценивал не знаю как это сделать, каким счетчиком посчитать(

Клиент хочет чтобы скорость выросла как минимум вдвое, а лучше втрое))

Павел, вам же хочется не паспортных данных производителя по живучести, а каких-то приземленных оценок?

Да простит меня КО, отошлю к сторонним ресурсам

Опыт пользователя на похожем материале:
http://blog.imageofyou.ru/2012/11/16/databases-on-ssd/
Длинная ветка про SSD в серверах, где обсуждается ВСЁ
http://forum.ixbt.com/topic.cgi?id=66:9010

"Клиент хочет чтобы скорость выросла как минимум вдвое, а лучше втрое))"

Приходите в гости с подробным изложением задачи. По переписке проку не будет.

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

"Планируется процессор E5-2620, 48 или 64 Гб RAM, 2 HDD SAS SATA под систему в зеркало, 4 SSD intel 320 300 Гб (100 Гб из каждого под OP), Контроллер Adaptec 6805 (привычнее))"

Павел, раз уж вы собрались строить RAID 10 из SSD, и привыкли к Adaptec, посмотрите на комбинацию Adaptec 7805 + 4 x 200GB SSD Intel 3700. Cчиталка у нового адаптека мощная, справится. К новым SSD 3700-й серии применять OP не обязательно - там и так высокий запас прочности по перезаписи. У 3700-й серии Random Write IOPS как минимум на порядок выше, а латентность - в полтора раза ниже, чем у 320-й.

авторы писали-писали, хорошо теорию написали, а вывод практический сделали негожий

Владислав, ждем ваш гожий.
Обсудим.

вы ж написали про адаптеры со специализированным под ссд микрокодом, а предложили обычный, к тому же с кешем. я бы 10 дисков ссд поставил в два раздельных бекплейна на два таких "простых" адаптера. верно?

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT