Оборудование для СУБД в современных реалиях

10 сентября 2024 г.

За последние два года российские компании столкнулись с беспрецедентными трудностями в приобретении серверного оборудования. Ограничения на ввоз техники, разрывы в логистических цепочках привели к дефициту и резкому удорожанию оставшихся ресурсов. В таких условиях многие организации, стремящиеся перейти на отечественные ИТ-решения, включая СУБД, вынуждены искать альтернативные пути использования имеющегося оборудования. Этот подход несёт определённые риски, но при грамотной стратегии может стать ключом к поддержанию стабильной работы и снижению затрат в новых реалиях. Рассмотрим, как компании могут эффективно переиспользовать существующие ресурсы и оптимизировать свою инфраструктуру, чтобы справиться с вызовами на рынке.

Процесс подбора оборудования: как это было ранее

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

1. Пилотный проект на типовой конфигурации. Разворачивается небольшой кластер, сбалансированный по нагрузке, чтобы протестировать решение.
2. Адаптация конфигурации. Анализируются ресурсоёмкие запросы, на основе этого корректируют соотношение ядер CPU, объёма памяти и типа дисков.
3. Оптимизация TCO. Принимаются решения о выборе оборудования: узлы максимальной ёмкости или оптимальные по стоимости, заключение контракта на обслуживание или ежегодная закупка.

Если удалось сохранить этот подход, никаких проблем вы, скорее всего, не испытываете и можете не углубляться дальше, а для тех, кто столкнулся с ситуацией, когда «нового оборудования нет и не предвидится», продолжаем.

Переиспользование оборудования

В случаях, когда компании переходят с крупных инженерных систем, таких как Oracle, Exadata или Teradata, возникает соблазн переиспользовать оборудование. Это решение несёт в себе серьёзные риски, так как каждая СУБД предъявляет собственные условия к ресурсам. Несоответствие между требованиями нового ПО и возможностями старого оборудования может привести к некорректной работе, снижению производительности и даже к выходу из строя отдельных компонентов из-за несовместимости драйверов или других критических программных элементов. Но если вас не пугают сложности, необходимо учитывать несколько факторов.

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

Если в комплексе оборудование не может работать с новым ПО, стоит рассмотреть переиспользование отдельных компонентов, таких как процессоры (CPU), оперативная память (RAM), жёсткие диски, RAID-контроллеры и сетевые карты. Эти составляющие элементы часто совместимы с новым программным обеспечением и могут быть интегрированы в новую архитектуру.

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

Оптимизация инфраструктуры

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

• Максимальное сжатие данных. Используйте алгоритмы сжатия, чтобы высвободить часть ресурсов дисковой подсистемы. Хотя сжатие потребует дополнительных вычислительных ресурсов, такой подход позволит создать резерв для роста данных без дополнительных затрат. Важно найти баланс между нагрузкой на CPU и степенью сжатия, хотя в нынешних условиях точка баланса смещается в сторону повышения компрессии.
• Ревизия политик резервирования и катастрофоустойчивости. Проведите проверку соответствия текущих политик резервирования и катастрофоустойчивости бизнес-требованиям. Если требования к резервированию снизились, высвободите часть мощностей хранения, использовавшихся для оперативных бэкапов, и перенаправьте на другие нужды.
• Объединение сред разработки и тестирования. Рассмотрите возможность объединить разделённые контуры или среды (разработку, тестирование, UAT, preprod). В прошлые годы такое разделение могло быть оправданным, но в условиях ограниченных ресурсов эти среды можно объединить для эффективного использования имеющегося оборудования.
• Оптимизация использования оборудования для СУБД. Освободившееся оборудование следует использовать под СУБД, обладающее следующими характеристиками:
  • колоночное хранение данных: позволяет уменьшить объём занимаемого места;
  • эффективное сжатие данных: применение алгоритмов, таких как zstd, обеспечивает дополнительную экономию пространства;
  • федерализация запросов: важно обеспечить возможность как входящих, так и исходящих федеративных запросов, что улучшает гибкость работы с распределёнными данными.

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

Источник: Михаил Дейсс, архитектор Arenadata