Про диски для 1С

Поговорим про загрузку оборудования.
Замеры загруженности оборудования также очень важны. У для этой цели реализован сервис hardware, дающий отчёт о превышениях нормативов.
В настольной книге эксперта происходит отсылка к штатным механизмам в рамках операционной системы. Кроме того, вы самостоятельно можете использовать коммерческие утилиты, собирающие загруженность оборудования. Мы сосредоточились не на сборе данных, а на дальнейшей интерпретации собранных значений. Как показала наша практика, имея конкретные цифры, например о загруженности дисковой подсистемы, разные специалисты делают разные выводы. Мы посчитали правильным оттолкнуться не от того, что написано у вендоров в описании счётчиков, а от оценки того, насколько в реальности апгрейд исследуемого компонента сервера может помочь в решении задачи. Например, мы знаем, что решаемая задача – это ускорение оборотно-сальдовой ведомости для бухгалтера. Мало кто может вручную, посмотрев на график любой из характеристик дисков, чётко сказать – коррелируют ли цифры с событиями построения ОСВ и насколько быстрее ОСВ будет работать при замене исследуемых дисков.
Многие администраторы при апгрейде думают, что главная задача – на новом оборудовании получить более быстрое выполнение операции в одном потоке. По нашему опыту, при эксплуатации высоконагруженных информационных систем бОльшим приоритетом является обеспечение неснижения текущей скорости работы в пиковые моменты нагрузки. Зачастую маркетинговые описания вендорами характеристик продаваемого оборудования, не помогают при принятии решения.
Сложилась популярная практика: сравнивать диски по иопсам. Сделаем небольшое отступление и поясним, что иопс – это количество операций ввода-вывода за секунду.
Давайте поставим себя на место продавца, который хочет продать диски. Понятно, что нам нужно всякими правдами и неправдами показать наиболее выгодную информацию. Если при этом часть правды выгоднее не говорить, то кто-то может посчитать, что это не обман. Ярким примером некорректного сравнения иопсов могут быть дисковые подсистемы, построенные на SSD дисках и на SAS дисках. Сравнивая только по иопсам, можно не заметить легко, что время отклика у этого оборудования будет разным. Или например, максимально допустимая глубина очереди к диску, после которой начнётся резкая деградация производительности.
Вот как раз настал момент, когда на словах есть что рассказать, а картинок с обоснованием никаких показать не могу, потому что неразглашение. Как говорят — джентльменам у нас верят на слово.
В качестве примера вспоминается случай на одном из наших проектов, когда в целом у клиента на довольно насыщенной системе в много сот пользователей дисковая подсистема вполне адекватно справлялась с нагрузкой в большинстве случаев, но иногда необъяснимо что называется становилась колом, работать было невозможно. Мы поставили замеры, дождались очередной затык, и побежали смотреть в сервисы. Нашли, что затык начался с образования гигантской очереди к дискам, что-то порядка нескольких сот тысяч операций. Ну а так как всё это время продолжают поступать и новые заказы на операции, дисковая подсистема потихоньку разгружала очередь (условно по доле процента в секунду, то есть совершенно недостаточно). Ну а в качестве меры пожаротушения применялась перезагрузка сервера СУБД. Каждый такой инцидент выливался в простой всей учётной системы компании минимум на полчаса, а то и больше — сначала минут 10-15 все лицезреют собственно затык, попутно вздыхая “ну вот опять”, затем согласовывали очередной рестарт системы, ну и плюс сам рестарт занимает существенное время. Руководство компании это категорически не устраивало, поэтому дали добро на срочный подбор с нашей помощью более быстродействующей дисковой подсистемы. Старая СХД была на обычных SAS дисках, которых было много, новую подобрали на твердотельных. Поставили новую систему, время обслуживания операций в обычное время сократилось условно с пары десятков миллисекунд до пары миллисекунд.
Как вы понимаете, никто из пользователей этой разницы не ощутил. Зато когда в очередной раз возник тот самый затык — он возник в стиле “что-то у нас интерфейс 1С затормозился на полминуты”, а по счётчикам было видно, что изначальная очередь была примерно такая же, но очень быстрые диски очень быстро её раскидали, секунд за 30-40. Ну а потом мы и источник такого затыка нашли, очередная гигантская избыточная выборка в аналитический отчёт. И как обычно в таких случаях и оказывается, анализ показал, что подавляющее большинство выбираемых данных для целей отчёта просто не нужны, можно сделать, чтобы работало значительно быстрее, и значительно дешевле по ресурсам.
Есть и другие факторы, характеризующие диски, которые мы (как уже и было сказано во введении) можем посчитать несущественными и откинуть. Особо популярной является ситуация, когда происходят тендеры и покупается более дешёвое оборудование, а решение о том, что два различных компонента являются аналогами, принимает человек без достаточного опыта и знаний данного оборудования.
Далее про тесты и замеры, переходим к дисковой подсистеме. Есть много различных методик, порой очень сложных, с кучей вариантов тестирования, где один прогон теста может загружать систему на целые часы.
А мы используем Crystal Diskmark, пусть и не исчерпывающий тест, но очень быстро дающий неплохое представление о производительности дисковой подсистемы.
Надо сказать, что выясняя скорость компонентов оборудования, мало слов сказано про то, как это надо делать. Очень значимыми условиями тестов являются: 1) возможность проведения теста эксплуатируемого оборудования без остановки работы предприятия с получением достоверной исчерпывающей информации; для того, чтобы оценить линейную скорость записи или чтения одного потока, вовсе не обязательно каким-либо тестом многопоточно «класть» всю дисковую подсистему. Даже копирование файла размером больше кэша контроллера и дисков позволяет получить частичное представление о характеристиках системы. В реальной жизни проведение теста, оценивающего скорость работы только одного узла – необходимо, но не достаточно. Сумма скоростей тестов по компонентам может быть не равна суммарной реальной скорости системы. Надо помнить о том, что часто возможности оборудования могут использоваться программным обеспечением лишь частично, или не использоваться вовсе. Например, вы купили новое оборудование (процессор), а ваше текущее программное обеспечение ничего не знает о новых процессорных инструкциях и не использует их. Таким образом, тест процессора может показать более оптимистичные цифры, чем в реальности будут получены в процессе эксплуатации системы. Не стОит также забывать о программных ошибках в коде, которые присутствуют в приложении, но отсутствуют в тесте и влияют на производительность. В заключение хочется отметить будущее и настоящее! за NVMe дисками с технологиями типа 3D Xpoint (Optane) и полками на их базе. Смешно и грустно смотреть, как крупные организации в 2018 покупают полки десятками дисков SAS — технологии остановившейся десять лет назад.