Как выбрать сервер для баз данных

Сначала нагрузка СУБД, затем сервер

Сервер для баз данных нужно выбирать от характера нагрузки. Для OLTP-систем критичны задержки, стабильная работа транзакций, быстрый журнал и надежное хранение. Для отчетности и аналитики важны RAM, скорость чтения, CPU, временные таблицы, параллелизм и работа с большими выборками. Для 1С, ERP и CRM дополнительно нужно учитывать пользователей, регламентные задания, обмены, интеграции, фоновые операции и требования прикладной платформы.

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

Процессор для баз данных: частота, ядра и лицензирование

CPU влияет на обработку запросов, сортировки, агрегации, индексы, параллельные операции, компрессию, шифрование, репликацию, backup-агенты и системные процессы. Для части СУБД и приложений важна высокая производительность одного ядра, для других — количество ядер и способность обслуживать много параллельных запросов.

При выборе процессора нужно учитывать не только производительность, но и лицензирование. Для некоторых СУБД и корпоративных приложений стоимость лицензий может зависеть от количества ядер или сокетов. Поэтому избыточный многоядерный CPU не всегда экономически оправдан: иногда лучше выбрать более быстрые ядра, оптимальный объем RAM и сильную дисковую подсистему.

Оперативная память: кэш, ECC, каналы и NUMA

Для серверов баз данных оперативная память часто влияет на производительность сильнее, чем формальное увеличение числа ядер. Чем больше полезных данных, индексов и рабочих наборов помещается в кэш СУБД и системный кэш, тем меньше обращений к дискам и ниже задержки при типовых запросах.

Для production-СУБД нужно использовать ECC-память. Ошибки RAM могут привести к сбоям, повреждению данных или некорректным результатам. Также важны каналы памяти, равномерная установка модулей, частота, поддержка платформы и NUMA-архитектура, особенно на двухсокетных серверах.

Важно не только купить достаточный объем RAM, но и настроить СУБД: лимиты памяти, буферный кэш, temp-зоны, параллелизм, планировщик задач, параметры журналирования и мониторинг. Без настройки даже мощный сервер может работать ниже своих возможностей.

Дисковая подсистема: NVMe, SSD, RAID, HBA и задержки

Диски для баз данных нужно выбирать по задержкам, IOPS, ресурсу записи, стабильности под нагрузкой и совместимости с платформой. Для активных баз, журналов транзакций, temp-данных и индексов часто нужны SSD или NVMe. HDD подходят для архивов, резервных копий и холодных данных, но редко оптимальны для интенсивной рабочей СУБД.

RAID повышает доступность дисковой подсистемы, но его нужно выбирать осознанно: разные уровни RAID дают разный баланс емкости, скорости, отказоустойчивости и стоимости. RAID-контроллер, HBA, кэш, BBU/CacheVault, backplane, кабели, U.2/U.3/NVMe и поддержка горячей замены должны быть совместимы с серверной платформой.

Важная практика — разделять рабочие данные, журналы, temp-области и backup, если это оправдано нагрузкой. Это упрощает диагностику и снижает риск конкуренции за один и тот же дисковый ресурс.

Сеть, СХД и архитектура хранения

Если база данных работает локально на сервере, сеть влияет на доступ приложений, пользователей, репликацию, backup и мониторинг. Если данные размещаются на СХД или NAS, сеть становится критичной частью дисковой подсистемы: задержки, пропускная способность, потери пакетов и отказоустойчивость напрямую отражаются на работе СУБД.

Для небольших систем может быть достаточно 1/10GbE, но для production-СУБД, виртуализации, СХД, backup и репликации часто рассматривают 10/25/100GbE, отдельные VLAN, bonding/LACP, резервные uplink, выделенный storage-контур и отказоустойчивые коммутаторы.

Если база растет или нужна централизованная архитектура, стоит оценить разделы «Хранилища данных» и «Системы хранения данных». Для сетевой части полезен раздел «Сетевое оборудование».

Надежность, backup, RPO/RTO и сопровождение

База данных — критичный актив компании, поэтому сервер должен проектироваться с учетом отказов. Нужны резервные блоки питания, ИБП, мониторинг дисков, контроль температур, уведомления, проверка SMART/NVMe-health, журналирование, обновления прошивок, резервное копирование и регламент восстановления.

RAID не заменяет backup. Резервные копии защищают от удаления данных, повреждения базы, ошибок администрирования, шифровальщиков, логических сбоев и аварий. Для СУБД нужно согласовать RPO и RTO: сколько данных можно потерять и за какое время систему нужно восстановить. Эти показатели влияют на частоту backup, схему хранения копий, репликацию и тестовые восстановления.

Для работ по настройке, диагностике, модернизации и сервисному сопровождению можно использовать раздел «Услуги ANDPRO». Для предварительной сборки конфигурации — конфигуратор серверов.

Типичные ошибки при выборе сервера для баз данных

Первая ошибка — считать, что сервер для СУБД должен быть просто «самым мощным». Без правильных дисков, RAM, настройки СУБД и backup производительный CPU не решит проблему медленных запросов. Вторая ошибка — экономить на накопителях и использовать диски без учета latency, IOPS и ресурса записи.

Третья ошибка — не учитывать лицензирование и покупать избыточное число ядер. Четвертая — размещать базу, temp-данные, журналы, backup и другие сервисы на одном медленном массиве. Пятая — не планировать рост: база, отчеты, интеграции, пользователи и требования к доступности обычно растут быстрее, чем ожидалось.

Еще одна ошибка — отсутствие мониторинга. Без метрик CPU, RAM, дисков, IOPS, latency, wait events, temp-пространства, сети и backup сложно понять, где узкое место, и инфраструктура начинает дорабатываться реактивно, уже после жалоб пользователей.

Какие данные подготовить перед подбором сервера ANDPRO для СУБД

Перед подбором сервера подготовьте тип СУБД, версию, размер базы, темп роста, число пользователей, профиль нагрузки, количество транзакций, характер отчетов, требования к SLA, RPO/RTO, резервному копированию, репликации, виртуализации, интеграциям, ОС, лицензированию и бюджету.

Также полезны текущие метрики: загрузка CPU, объем RAM, cache hit ratio, wait events, IOPS, latency, объем журналов, длительность backup, скорость восстановления, пиковые периоды, размер temp-данных и жалобы пользователей. Эти данные помогают подобрать не абстрактно мощный, а действительно подходящий сервер.