Как выбрать сервер

Иногда лучше купить новый сервер, чем оптимизировать приложение. Время разработчиков сейчас стоит намного дороже серверов. Как выбирать сервера для роста и новых задач?

Ключевые узлы любого приложения — бекенд, фронтенд и база данных.

Бекенд

На бекендах обычно находится серверное приложение (PHP, Python, Ruby и т.п.). Практически всегда приложение требовательно к процессорной мощности. Исходные коды обычно занимают совсем немного места, поэтому к оперативной памяти несущественные.

Нагрузка на диск будет очень низкая (чтение файлов при обновлении кода). Учитывая то, что бекенды обычно легко заменяются, нет смысла ставить RAID массивы, достаточно одного диска. Однако нужно иметь минимум два бекенда.

Поэтому бекенд следует подбирать с небольшим диском, небольшим количеством оперативной памяти, но мощным процессором.

На практике, в проектах с десятками миллионов запросов в сутки мы выбирали сервера для бекендов такой конфигурации:

На бекендах часто размещают кэширующие сервисы, типа Memcach’a. Это очень удобно, т.к. подобные сервисы обычно требовательны к оперативной памяти и малотребовательны к процессору. Мы обычно устанавливали по 32Гб оперативки при той же конфигурации.

Фронтенд

В отличие от бекенда, фронтенд сервер занимается обработкой соединений от большого количества посетителей. Соединения занимают место в оперативной памяти. Следовательно ее объем должен быть большим.

К тому же фронтенд часто выполняет процессороемкие задачи — сжатие статики и ответов от бекендов, шифрование ответов при включенном SSL, авторизация и т.п. Следовательно процессор тут понадобится тоже мощный.

Диск чаще всего играет небольшую роль. Если вся статика влазит в оперативную память, будет достаточно самого простого варианта. Однако, если фронтенд отдает медиа-контент, следует выбирать более быстрые SAS или SSD диски.

Для обеспечения высокой доступности фронтенды также должны присутствовать минимум в количестве двух штук.

Мы обычно подбирали такие сервера для фронтендов:

База данных

База данных часто выступает в роли самого нагруженного узла. У БД высокие требования ко всем ресурсам — и к процессору и к оперативной памяти и к диску.

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

В хорошем случае около 30% всех данных должны помещаться в оперативную память — это обеспечит хорошую производительность при работе с диском в большинстве случаев.

RAID ставить обязательно, т.к. вероятность выхода из строя дисков тут очень высока, а время простоев должно стремиться к нулю.

Мы обычно подбирали такие сервера для обслуживания баз данных:

Другие узлы

На крупных проектах существует большое количество разнообразных узлов, кроме бекенда, фронтенда и баз данных.

Почтовые сервера

Диск маленький, процессор средний, оперативной памяти немного. Самый скромный сервера. Если почты Вы шлете очень много (миллионы) и используете шифрование и авторизацию (DKIM), следует поставить сервер с мощным процессором и быстрым диском, увеличение оперативки — ни к чему.

Файловые/медиа хранилища

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

Очереди задач

Если Вы используете что-то типа German, который не сохраняет задачи на диск, выбирайте много оперативки, мелкий диск и простой процессор (операции на таком сервере очень простые). В случае синхронизации задач с диском, следует ставить диски побыстрее (SAS или SSD), т.к. количество проходящих задач обычно довольно большое.

Сборщики статистики

Обычно это сервера, которые собирают данные для последующей аналитики (Hadoop, Elastic Search, Vertica и т.п.). Очень часто в них не критичны моментальные записи, однако данных часто очень очень очень много. Форма запросов обычно предполагает агрегатные выборки с перебором огромного количества записей, поэтому эффективно пользоваться оперативной памятью тут почти невозможно. Следует выбирать большие диски (SATA для экономии, SSD для скорости), средние процессоры и среднее количество оперативной памяти.

Полнотекстовые индексы

Под задачи поиска по тексту часто выделяют отдельные технологии. Elastic Search, Sphinx или Solr, Принципиально тут все похоже на базу данных. Быстрые диски, оперативной памяти побольше (чтобы треть индекса влазила в память) и мощный процессор.

Кэширующие кластеры

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

Самое важное

Железо выбираем на основе трех основных параметров — процессор, память и диск. Фронтенты критичны к памяти и процессору, бекенды — к процессору, а базы данных ко всему сразу.

Чаще всего Вы будете делать выбор между процессором и оперативной памятью. Избегайте универсальных серверов — выйдет дорого.

© Den Golotyuk