Как правильно провести сайзинг СХД
Успех любого бизнеса напрямую зависит от того, насколько эффективно организовано хранение и обработка данных. Как оптимизировать расчет конфигурации и подбор типа СХД в зависимости от цели создания ИТ-решения, рассказывает Вячеслав Володкович, генеральный директор компании «Аэродиск».
Примета времени: сегодня буквально всем вокруг – людям, компаниям различного профиля и размеров, государству и его многочисленным ведомствам – всем резко понадобилось хранить данные, которые возникают при любой активности. ИТ-инфраструктура должна отвечать задачам хранения, организации, обработки и интерпретирования данных в рамках аналитических задач.
Для этого ИТ-специалисты компаний проводят так называемый сайзинг — определяют необходимые объемы и проектируют системы, в которых хранятся данные. Вот что нужно учесть в этом процессе.
Рабочие нагрузки
Чтобы облегчить и ускорить работу с новым уровнем количества и типов данных, создаются и совершенствуются специальные приложения для разного типа нагрузок, которые выполняются ресурсами СХД. В процессе сайзинга нужно учитывать несколько ключевых характеристик, определяющих тип рабочей нагрузки.
- Скорость — измеряется в IOPS (Input/Output Per Second), определяет количество операций ввода-вывода в секунду. Чтение и/или запись IOs могут иметь различный характер (например, последовательный и случайный). Чем выше IOPS, тем выше производительность.
- Пропускная способность — измеряется в МБ/с, определяет скорость передачи данных. Чем выше пропускная способность, тем больше данных может быть обработано в секунду.
- Отклик — измеряется в единицах времени и определяет, сколько миллисекунд нужно для завершения процедуры ввода-вывода. Чем ниже задержка, тем быстрее реагирует система/приложение и тем более плавной кажется работа пользователю.
От типа рабочей нагрузки зависит, какая характеристика является наиболее важной метрикой. Рассмотрим четыре наиболее распространенные рабочие нагрузки.
Транзакционные корпоративные приложения
Транзакционные корпоративные приложения часто опираются на базы данных, где отклик является ключевым фактором. Они также предполагают проведение большого числа мелких операций ввода-вывода и чтения. Уменьшение показателя задержки приводит к уменьшению состояний ожидания, которое, в свою очередь, сокращает нагрузку на процессор. Оптимизируя загрузку CPU, можно запускать больше баз данных на одном и том же процессоре, оптимизируя утилизацию ресурсов.
Виртуализация
Виртуализация является уникальной рабочей нагрузкой, поскольку она объединяет в гипервизоре несколько различных рабочих нагрузок приложений с разными характеристиками. Таким образом, у вас будет несколько приложений, выполняющих случайные блоки размером 4k, 8k и 16k в виртуальной машине, но гипервизор преобразует их в стандартные блоки размером 1MB или 2MB, которые отправляет в хранилище (или, наоборот, запрашивает из него).
Не все рабочие нагрузки приложений будут достигать пика в одно и то же время. Поэтому вместо того, чтобы чрезмерно выделять ресурсы, лучше отслеживать картину потребления ресурсов. Рабочие нагрузки виртуализации чаще всего оказываются случайными, для их выполнения приоритет имеет скорость (IOPS).
Общий файловый сервер
Как правило, такой файловый ресурс используется множеством пользователей в организации и различными приложениями, хранящими данные на этих файловых ресурсах. Пользователи открывают файл и работают с ним в течение некоторого времени, прежде чем снова сохранить его на том же файловом ресурсе. Поэтому пропускная способность при получении и сохранении файла (МБ/с) для пользователя часто наиболее важна. Однако в зависимости от приложений, хранящих файлы, приоритетом может быть и скорость IOPS.
Резервное копирование и архив
Рабочие нагрузки резервного копирования и архивирования больше всего выигрывают в производительности от максимизации пропускной способности СХД. Именно она позволяет уложиться в нужное «временное окно» при создании бэкапа.
Существуют два основных режима хранения резервных копий на диске: прямой инкрементальный и обратный инкрементальный. Из-за различий в способах записи резервных копий на диск эти режимы имеют разные профили ввода-вывода в хранилище.
Для чего нужен сайзинг?
Именно из-за разнообразия типов рабочих нагрузок и важен сайзинг: нужно заранее определить объем и тип рабочей нагрузки, чтобы спроектировать оптимальную систему хранения данных. Ошибки сайзинга могут привести к разного рода сбоям работы ИТ-решения в целом, к недостатку закупленного ресурса или, наоборот, переплате за неиспользуемые его объемы.
Чтобы избежать такого сценария, необходимо четко сформулировать бизнес-требования, а затем конвертировать их в технические требования. Итогом этой работы должен стать профиль рабочей нагрузки и емкости СХД.
Например, мы заложим в проект СХД «энное» количество подсистем с определенным характером нагрузки, с сочетанием функционала чтения и записи данных, а также определенными показателями доступности информации. Эта справка и будет профилем нагрузки и емкости.
Однако даже самый подробный профиль не исчерпывает собой все количество тонкостей и подводных камней.
Лайфхаки, трюки и на что обратить внимание
Например, когда мы говорим про сайзинг гиперконвергентной ИТ-инфраструктуры, вместе с ресурсами СХД необходимо учитывать и вычислительные мощности: процессор и оперативную память. Для расчета ресурсов процессора можно использовать переподписку, то есть распределение физических и виртуальных ядер в пользу виртуальных.
При выделении ресурсов оперативной памяти иногда применяют так называемый “over commitment” – выделяют больше, чем есть на самом деле. Чисто технически это работает, но для использования в продуктиве ИТ-решений делать этого я бы не рекомендовал. Память – не такая динамическая субстанция, как процесс. Несмотря на то, что предусмотрены механизмы типа balooning и прочая «магия», память – это память, играть с ней на запущенном в продуктив ИТ-решении не рекомендуется.
Также нужно учитывать минимальные ресурсы для служебных нужд. То есть на каждой ноде необходимо 2 ядра и 16 Гб оперативной памяти оставлять для работы системы. Аналогичный резерв должен закладываться и для ввода-вывода, потому что на тех же нодах работает и система хранения, что требует еще примерно 20% ресурсов оставлять под эти задачи.
Этот подход справедлив для классических, не гиперконвергентных архитектур. Ни одна система хранения, под Windows или Linux, если заполнить дисковое пространство на 100%, работать нормально не будет. Соответственно, необходимо при планировании учитывать, что 15-20% места должно быть свободным. Это гарантирует стабильную работу системы в целом, особенно в перспективе постоянного роста объема данных.
Строить решение, исходя из того, что оно оперирует неким статичным объемом данных, довольно опасно. Здесь мы подходим к еще одному моменту: необходимости оперировать в расчетах реальной, а не коммерческой емкости диска. Коммерческая емкость – это десятичное измерение объема дисков, к которому привыкли мы все, те самые знакомые и понятные 500 Гб, 1 Тб, 10 Тб. Проблема в том, что это человеческий подход к предмету – а компьютер мыслит в двоичной системе.
Когда мы переводим привычный объем в двоичное исчисление, у нас всегда получается меньший «человеческий» объем. При конвертации приходится расставаться с 10% коммерческой емкости (как минимум). В пользовательской картине мира это не проблема, но, когда речь идет о коммерческих системах, такие просчеты могут носить критический характер.
В ряде случаев объем дисков используется производителями для каких-то сервисных функций: они делают скрытые разделы для восстановления данных, ставят дополнительные прошивки и так далее. Все это тоже «съедает» какое-то количество пространства, поэтому внимательно изучайте спецификацию дисков.
С точки зрения максимальной производительности при сайзинге хранилища надо использовать replication factor. При этом надо всегда помнить, что и replication factor, и erasure coding на операциях записи съедают какое-то количество IOPS мегабайт в секунду из-за особенностей процесса.
Не забываем про пропускную способность портов interconnect. Они тоже используются при операциях ввода-вывода. Это создает накладные расходы на запись, особенно в случае метрокластера (распределенной системы хранения между разными площадками). То есть если у нас есть interconnect, у него есть определенная задержка в 1-2 миллисекунды, которая добавится в операции записи. Чудес здесь не будет, какие бы ни были хорошие коммутаторы.
А вот еще одна коммерческая уловка, которая тоже мешает жить простому ИТ-архитектору, который делает сайзинг. Никогда не используйте заводские характеристики дисков для расчетов! Достаточно залезть в характеристики любого диска и увидеть там 400 тысяч IOPS скорости работы. Или 500 тысяч IOPS, то есть космические, запредельные цифры. А затем мы берем этот диск, вставляем его в СХД, и заявленная скорость почему-то не достигается.
Нас обманывают? Нет, нас не обманывают.
Просто нужно понимать, что производители тестируют диски «в вакууме», идеальной тестовой среде. То есть они используют прямую запись прямо на диск, и теми блоками и с той нагрузкой, которые им интересны. Естественно, они об этом пишут. Эти цифры ни в коем случае нельзя использовать для сайзинга.
Что здесь не учитывается? Накладные расходы операционных систем виртуальных машин, систем хранения данных, а если у вас физическая система, то еще и хоста. А также очереди процессоров, ограничения оперативной памяти, расходы файловой системы и избыточности, а также заполняемость хранилища — все это напрямую влияет на производительность. Совокупность этих факторов и приводит к реальным показателям производительности, которые следует принимать за отправную точку при сайзинге.
Читать еще:
https://globalcio.ru/discussion/14818/?sphrase_id=14470
