`

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

Чи використовує ваша компанія ChatGPT в роботі?

BEST CIO

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

Человек года

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

Продукт года

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

 

Каждый охотник желает знать где сидит... IOPS

+1111
голосов

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

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

Для массовых приложений, работающих с базами данных (БД) — таких как 1С, и емкость дисков, и их потоковая производительность (в MBps), и тип интерфейса (SAS или SATA) — параметры второстепенные, легко определяемые заранее (тем же объемом БД). Ключевым параметром дисковой подсистемы для работы с БД является ее способность обработать большое количество относительно мелких операций ввода/вывода — IOPS (Input Output operations Per Second). Именно IOPS на запись и чтение характеризуют способность дисков успевать за запросами приложения. В данном материале мы ограничимся недорогими реализациями, оценив их возможности по стандартному тесту IOMeter.

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

Исходим из того, что в сервере начального уровня установлен пусть и недорогой, но аппаратный RAID-контроллер cо своим процессором и кэш-памятью. Он нужен для:

— разгрузки центрального процессора, шин ввода/вывода и оперативной памяти;

— создания логических томов из разных типов дисков, разного объема и уровня RAID;

— прозрачности построения и управления массивами;

— обеспечения достаточного уровня устойчивости к сбоям;

— минимизации времени реконструкции RAID’а в случае сбоя диска.

Для тестов мы взяли Adaptec 6405E, демократичный по цене, с хорошим и простым управляющим ПО. Исключив по соображениям стоимости решения комбинации с дисками SAS HDD, мы сталкивали SSD и SATA HDD в трех сценариях:

  • «консервативный» 2 SATA HDD в RAID 1

  • «cмешанный» 1 SSD + 2 SATA HDD в Hybrid RAID

  • «радикальный» 2 SSD в RAID 1

В качестве SSD использовались накопители Intel SSD 320-й серии {SSDSA2CW080G310} 80GB — на такой диск помещается база данных 1С небольшой компании на 5-15 пользователей, занимая в среднем 10-25% его емкости. HDD были представлены 2TB Hitachi Ultrastar A7K2000 {HUA722010CLA330} 7200 rpm.

Моделировалась следующая постановка:

  1. Небольшая БД объемом 0,5-4GB (к примеру, под «1С:Предприятие 8.2 Бухгалтерский учет для Украины»);

  2. Чувствительная к быстродействию дисковой подсистемы в IOPS, БД располагается на максимально быстром RAID-томе;

  3. Операционная система, приложения и т.д. располагаются на другом RAID-томе.

Исключая споры, какие именно подсистемы и операции использовать в тестах под 1С, как наполнять БД, «и вообще у нас другая конфигурация», мы тестировали дисковую подсистему с помощью IOMeter. Да, это синтетический тест, в реальной работе столь стабильную и регулярную нагрузку никакие пользователи не создадут. Но результат IOMeter для баз данных (68% read / 32% write) очень хорошо коррелирует с поведением системы 1С при пиковых нагрузках (вроде перепроведения периода или закрытия месяца), утилита проста в использовании и доступна всем. Перепроверяйте.

Вводились ограничения: длина очереди запросов к диску — от 1 до 8 (типичные показатели для класса задач), размер блока данных в 4 и 8 KB (наиболее типичны для БД). Кэш на запись в HDD и SSD отключался в целях безопасности данных.

На первой и второй диаграмме — результат сравнения быстродействия в IOPS для обычного RAID 1 на 2-х HDD и гибридного RAID 1, в котором используется часть емкости SSD (25% оставили неразмеченной для over provisioning) и небольшая часть емкости HDD — в итоге получаем том ёмкостью 60GB под данные БД. Первая диаграмма — с 10% заполнения тома в 60GB, вторя с 50% заполнения тома.

Каждый охотник желает знать где сидит... IOPS

Тест 1. Диаграмма 1. (10% заполнения, глубина очереди 4, блоки 4KB и 8KB, без кэш)

Каждый охотник желает знать где сидит... IOPS

Тест 2. Диаграмма 2. (50% заполнения, глубина очереди 4, блоки 4KB и 8KB, без кэш)

Хорошо заметно, что:
а) при 10% заполнении тома гибридный RAID 1 на SSD+HDD показывает прирост производительности почти в 2,9 раза относительно RAID 1 на HDD+HDD;
б) при 50% заполнении тома гибридный RAID 1 на SSD+HDD показывает прирост производительности почти в 2,5 раза относительно RAID 1 на HDD+HDD.

Показательна Диаграмма 3, где отображена зависимость производительности классического тома RAID 1 на HDD+HDD и гибридного тома RAID 1 на SSD+HDD от длины очереди запросов к дискам.

Каждый охотник желает знать где сидит... IOPS

Тест 3. Диаграмма 3. (50% заполнения, глубина очереди 1-2-4-8, блоки 4KB)

По статистике около 80% времени на малых серверах длина очереди запросов к дискам не превышает 2. Другими словами, данный график демонстрирует «реактивность» отклика системы при типовых пользовательских, а не пиковых нагрузках.

Завершает тест Диаграмма 4 с данными производительности в IOPS томов RAID 1 «консервативого» (HDD+HDD), «смешанного» (SSD+HDD) и «радикального» (SSD+SSD).

Каждый охотник желает знать где сидит... IOPS

Тест 4. Диаграмма 4. (50% заполнения, глубина очереди 4, блоки 4KB и 8KB)

То, что производительность RAID 1 на SSD+SSD выше классического RAID 1 на HDD+HDD в терминах IOPS в 12-15 раз — вряд ли для кого-то новость. Отрыв RAID 1 на SSD+SSD от гибридного RAID 1 на SSD+HDD в IOPS в 5-6 раз тоже существенен. Вопрос лишь в «цене на билет»...

Разница в цене между бюджетным сервером с дисковой подсистемой RAID 1 на HDD+HDD и гибридным RAID 1 на SSD + 2 HDD — на стоимость SSD ($150 в нашем случае). Оснащение сервера аппаратным контроллером уровня Adaptec 6405E обойдется в $280. Добавление SSD в классический (HDD+HDD) RAID-массив и доведение его до гибридного обойдется в 10-15% стоимости сервера. При этом прирост производительности самого медленного компонента сервера — дисковой подсистемы — составит порядка 2,5 раз в IOPS. Интересно?

Наиболее производительный вариант сервера с RAID 1 на SSD+SSD плох только тем, что к нему неизбежно придется добавить RAID 1 на HDD+HDD — для размещения на нем операционной системы, приложений, ежедневных архивных копий. Переход к дисковой подсистеме (SSD+SSD) + (HDD+HDD) от традиционной пары HDD+HDD добавит к цене сервера 20-25% стоимости сервера — в обмен на 12-15 кратный прирост производительности дисковой подсистемы в IOPS.

Как в сказке про белого бычка, вернемся к началу. Чтобы понять, какой дисковой подсистемы достаточно серверу под имеющиеся задачи, требуется анализ нагрузки: нужны MBps или IOPS, сколько, на чтение или на запись, какова длина очереди запросов, моментальная и средняя? Вполне может оказаться, что даже на пиках нагрузки будет достаточно классического RAID 1 на HDD+HDD с его физическими 80-100 IOPS на запись и 200-240 IOPS на чтение. Пользователям с повышенными требованиями подойдёт гибридный RAID с его впечатляющими 12-16К IOPS по чтению и пристойными 300-400 IOPS на запись. Если же нагрузка будет требовать 18-32K IOPS на чтение или 600-4K IOPS на запись в режиме БД — то это прямой сигнал к переходу к более затратным решениям: массивам из SSD или схемам с SSD-кэшированием. Иначе охотник — и не охотник вовсе, а экстрим-турист.

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365

+1111
голосов

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

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

Владиславу

Один SAS 15К дает всего-то вдвое больше IOPS чем SATA 7200. При этом цены на диски начинаются от $250 за минимальный 300GB. Если рассчитывать на кэширование записи, надо покупать RAID-контроллер с батарейкой или флэш-модулем - а это потянет на $600. 4 диска SAS 15K на контроллере с кэшированием записи стоят $1600. За эти деньги можно получить ЦЕЛЫЙ сервер с гибридным рейдом, который по IOPS'ам ему как минимум не проиграет. При этом будет куда проще по устройству и тише в работе. Считайте, что постановка тестов адресована покупателю, у которого бюджет на сервер $1-1.5K, но он хочет избежать мучений в работе. А еще точнее - то тем пользователям, которые покупают непонятные коробки с двумя дисками SATA на бортовом рейде, а потом удивляются "а царь-то, ненастоящий".

Так все таки сколько будет стоить RAID 1 на SSD+SSD малого объема с установкой?

Если с простейшим аппаратным контроллером типа Adaptec 6405E ($280) и двумя 80GB Intel 320 (по $140), получается $560. На оставшиеся два порта контроллера можно повесить пару SATA HDD 500GB по $100 - если в сервере есть другие приложения и задачи, кроме работы с БП. При затратах на дисковую $760 добиваемся минимум 300 Random Write IOPS и есть место под хранение холодных данных. В режиме гибридного рейда, жертвуя одним SSD, экономим $140 и не сильно теряем в иопсах.

А если апгдейдить сервер, можно поставить второй контроллер?

Это как? В сервере уже стоит один RAID-контроллер и хотите добавить второй??

Спрашиваю можно или нет. И как быть если стоит уже контроллер (ведь он SSD может не поддерживать)

Любой контроллер, который работает с дисками SATA HDD, будет работать с SSD. Если захотите решить с помощью SSD проблему нехватки иопсов, просто добавьте в свой сервер зеркало из 2 SSD. Ну не будет у вас гибридного рейда, и ладно.

Если хотите гарантий - смотрите в HCL вашего контроллера, какие SSD там прописаны - те и будут работать.

Ну не будет у вас гибридного рейда, и ладно.

аффтор... :)))

Да ну ладно же, не в пропаганде гибридов дело! Что мне ответить человеку - чтоб выкинул свой контроллер и купил новый? Пусть сам переваривает информацию и принимает решение тоже сам. Вот уж чего мы не добиваемся - так это превращать КО в площадку готовых рецептов вкусной и здоровой пищи.

Ну а все таки можно два поставить контроллера? Контроллер может ведь не обеспечивать необходимую производительность (реально дисковая система сервера у клиентов работает медленне в несколько раз (3-4) (10МБ/с на запись), чем мой 2-летний ноутбук)

и это правильно. одна проблема - две шины для подключения дисков должно быть

Тут имеет смысл поставить вначале вопрос, почему текущая дисковая подсистема работает медленно. Поискать "узкие места" в настройках контроллера, уровнях RAID, настройках файловой системы ОС и т.д.
На счет производительности RAID-контроллеров.
Относительно старенькие 1-ядерные контроллеры Adaptec обеспечивают производительность процессора порядка 80K IOPS, что вполне достаточно для 2-х SSD (в среднем 33-38K IOPS на чтение на диск) + еще 2-4 диска SATA (100-120 IOPS на чтение на диск) или SAS (200-240 IOPS на чтение на диск).

Ситуация медленной дисковой системы сервера не единична, особенно при виртуализации и на запись и в монопольном режиме. И на практике RAID обычно значительно медленне одного диска в таком режиме. Поможет ли вообще SSD в таком случае?

Давайте говорить конкретнее.
1. Какой установлен RAID-контроллер.
2. Какой уровеньRAID выбран.
3. Какие конкретно диски и сколько установлено в массив.
4. Какая политика кэширования включена на контролере на чтение и на запись.
Как правило, даже RAID 1 ("зеркало") медленнее одиночного диска на запись на 5-7%, и быстрее одиночного диска в 1,8 раз на чтение.

> Владислав Слободяник
> "не понял, зачем сас исключили"

В данном материале опубликована часть экспериментальных результатов, полученных на протяжении почти месяца работ в тестовой лаборатории Entry.
SAS из данной серии тестов исключен сознательно.
Т.к. применительно к основному заказчику небольших 1-процессорных серверов, чаще всего идущих в небольшой офис на 5-15 пользователей 1С - технология HDD SAS 15000 prm, мягко выражаясь, "не очень популярна".
Что вполне справедливо в данном аспекте использования серверов - ведь существенного преимущества перед вариантом гибридный RAID, а тем более RAID на чистых SSD - SAS не несет.
По нашим наблюдениям, объем БД 1С в таких компаниях обычно составляет от 300MB до 4GB, и они полностью помещаются даже в небольших SSD.
При этом мы сознательно не использовали сверх дешевые, с урезанными техническими возможностями SSD объемом 30-60GB, т.к. не видим смысла в экономии 25% стоимости при потере 100-150% производительности.
Точно так же не использовали SSD в 120-160GB, которые в 2-3 раза быстрее на запись, и во столько же раз дороже. Они, как правило, применяются уже в чуть старшем сегменте северных решений, где как раз есть место и для SAS.

Adaptec 6405E, демократичный по цене, с хорошим и простым управляющим ПО

Управляющее ПО для обычного HDD и SSD какбы принципиально немного разное. Оно точно не убивает SSD раньше времени?

Оно его точно не убивает. Плюсы управляющего ПО перечислены в статье. Контроллер не увеличивает нагрузку на SSD, хотя я понимаю, о чем вы - про то что SSD сам занимается переносом данных между своими ячейками и внешний контроллер ему не помощник. Ваше опасение, что RAID-контроллер не различая SSD и HDD, делает лишние операции по оптимизации очередей, справедливо для конфигураций с большим количеством SSD - и там действительно приходится "отключать мозги" контроллерам. Для нашего случая простого или смешанного зеркала это точно некритично. Куда сильнее убивает SSD отсутствие встроенных процедур активной уборки мусора и оверпровиженинга.

Отвечу на том уровне достоверности, который возможен:
а) при подключении SSD RAID-контроллер в своей утилите управления дисками пишет, что к нему подключен именно SSD, а не HDD.
б) Тесты показывают, что SSD работает на иных скоростных параметрах, чем HDD.
Т.е., внутренняя прошивка RAID-контроллер Adaptec 6405E знает, что к ней подключен SSD и корректно с ним работает.
По понятным причинам влезть в прошивку RAID-контроллер и выяснить, как он конкретно работает с SSD - у нас возможности нет.
Если вопрос касался прохождения команды TRIM от ОС - то через интерфейс SAS она не проходит, т.к. такой команды в наборе команд SCSI нет.
Аналогом команды TRIM для SCSI являются команды UNMAP и WRITE SAME, последняя есть и в SATA. В Linux их можно настроить самостоятельно (по словам линуксоидов), а поддерживаются ли они Windows - еще сами не выяснили (планируем).
На счет убийства SSD "раньше времени" - вообще вопрос. Именно для долгой и счастливой жизни SSD применяется over provisioning. Берете ваш объем БД, умножаете на 2 или 3 - вот и все пространство, которое надо разметить. Ничего, кроме БД и индексов на SSD держать не нужно. Нам же наши SSD даже сколько-нибудь серьезно "замучить" тестами не удалось.

а ведь каков читатель пошел!? :))

правильно, применяйте столовые приборы по назначению - адаптер для SATA HDD свой, для SATA SSD свой.

Однако, таки статья о бюджетных решениях :))

Адаптер для обоих томов RAID - один и тот же.
Он легко делает 2 различных тома/массива - один на чистых SSD/SSD + часть HDD, второй - на HDD.
Он же позволяет весьма удобно ими раздельно управлять, применять различные политики кэширования (это тема еще одного материала, готовим), раздельно восстанавливать массив при выходе из строя диска (ребилд).

Он же позволяет ... применять различные политики кэширования

Каков адаптер... Это как - адаптер комбинирует режимы Write-Back и Write-Through? :)))

1. Из утилиты RAID-контроллера весьма удобно включать или отключать кэш на самих SSD и HDD.
2. Можно включить на массив из HDD кэширование на чтение, и выключить кэширование на чтение для SSD - к примеру.

В аапаратных контроллерах начального уровня, к которым относится и Adaptec 6405e, не предусмотрена работа кэша в режиме Write Back - хотя бы потому что на нем нет защиты кэша батарейкой или флеш-модулем. Кому охота развалить массив из-за сбоя по питанию? Выше в комментариях я уже считал, во что обойдется внедрение массива из 4 дисков на рейд-контроллере с отложенной записью. В нашем случае и SSD и HDD работают в режиме прямой записи Write Through.

Изначальная постановка звучит так: добыть IOPS'ы (если они объективно нужны) и при этом остаться в разумном бюджете. Мы не говорим про RAID 5, не обсуждаем кэширование записи, многошпиндельные конфигурации на дисках SAS - все это сильно поднимает цену сервера, зачастую избыточно и особого выигрыша по иопсам не дает. С другой стороны, мы призываем смотреть в корень проблем тех, кто в состоянии думать, и кому доброхоты советуют брать под 1С обычный ПК. Или сервер производителя ххх - ведь на них объявлена распродажа. Не в названии же дело, и не в одной цене. Всем хочется чтоб сервер был дешевым, но всем же хочется, чтоб он соответствовал задачам. Когнитивный диссонанс в мозгах простым брендингом не преодолевается. Вот и тестируем, ищем аргументы.

В нашем случае и SSD и HDD работают в режиме прямой записи Write Through

Оригинальная идея для SSD :))

Зачем вам рынок "кому доброхоты советуют брать под 1С обычный ПК" - вы ведь его все равно не вылечите? Хотя, сеять разумное, доброе, вечное - это ведь неплохо... Окупится?

> Оригинальная идея для SSD :))
Владислав, если не сложно, поясните, в чем ее "оригинальность"?

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

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

Предшествует. Только не продукту, а последующим статьям об источниках и составных частях производительности. Про гибридные массивы и говорить- то больше нечего. Это бюджетный способ снижения задержек отклика дисковой системы, при сохранении доступности данных. Без революций, на доступных продуктах. Простой в администрировании. К любому подходу есть вопросы, и лучше их обсуждать, чем предаваться бокс-мувингу или идолопоклонству. А Вам, Владислав, отдельное спасибо за поддержание дискуссии в тонусе, все выходные. Всем польза.

Я за качественный продукт.
Тем более приятно, когда тебя понимают :)

Нет, выводу продукта на рынок - не предшествует.
Технология гибридных массивов была выведена на рынок около 2-х лет назад.
На тот момент она была чуть сыровата и не столь эффективна.
Цель же материала - не популяризация технологий гибридных массивов, а описание возможных технологических альтернатив для недорогих 1-процессорных систем, с четким указанием сильных и слабых сторон. Ну и с цифрами.

Тем не менее, хотелось бы вернуться к заданному уточняющему вопросу: в чем оригинальность отключения кэша у SSD?
Нам действительно интересно. Вполне вероятно, что мы не там и не то промеряли. Или наши тесты были слишком синтетическими. Поделитесь, пожалуйста, своим практическим опытом в вопросе производительности SSD с включенным и выключенным кэшем на контроллере и на самом SSD.

нет, не "отключение кеша". а использование режима записи Write-Back адаптером имелось в виду. Вообще, большую часть моих дописив не стоит воспринимать буквально :)

Прошу прощения, не совсем верно понял вопрос.
Это мы тоже проверяли.
Для SSD и Hybrid RAID на RAID-контроллере более быстродействующим оказался вариант Write Through, а не Write Back.
Диаграмму с результатами измерений - опубликуем, вместе с небольшим текстом (скорее всего, в виде блога).

:)

Продолжим c новыми силами :)

"применяйте столовые приборы по назначению - адаптер для SATA HDD свой, для SATA SSD свой"

Во всех промышленных реализациях с твердым телом (будь то серверы и СХД со слоем "флеш как кеш" или контроллерные сборки на SSD - как Fusion IO, LSI Warp Drive, Intel 910 итд) SSD управляются внешними контроллерами. В смешанных схемах - как при реализации SSD-кеширования по типу Adaptec MaxCache и LSI CacheCade - смесью SSD и HDD управляет один контроллер. Корректно определяет тип носителя, позволяет назначить ему роль, приписывает соответствующему логическому тому, в нужном уровне RAID). Ничего крамольного в гибридном рейде нет, один контроллер обслуживает пару SSD + HDD, в режиме быстрого чтения с SSD и прямой записи на оба диска. Внешний контроллер не подменяет собой функции встроенного контроллера SSD, его задача - фоновое копирование на HDD, прозрачное построение/разбиение/восстановление массива под разными ОС, разгрузка центрального процессора.

PS Когда комментарии превышают по объему основной текст, это сигнал автору :)

так я ж об этом...

Народ ленив, большие тексты не читает.
Бьем на "много маленьких медвежат".

Я больше скажу, ничто не мешает поднять зеркало на SSD и зеркало на HDD без внешнего рейд-контроллера - на четырех бортовых портах SATA любой материнской платы. Разнести данные по томам - горячие (базу и индексы) на SSD, холодные (ОС, приложения, архивы) - на HDD. Организовать программное фоновое копирование операций с БД на HDD. Получить сопоставимые значения IOPS. Кругом же - прямая экономия. До первого сбоя все будет работать. Вопрос же только в понимании того что делаешь и контроле за ситуацией. Как обычно, работает закон сохранения энергии: сэкономил на аппаратной части - переплатил за сопровождение и последствия.

 

Ukraine

 

  •  Home  •  Ринок  •  IТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Мережі  •  Безпека  •  Наука  •  IoT