Связаться по Skype: vkarabedyants
Позвонить Написать
+7 (499) 404-28-83

Блог о системном администрировании серверов и сайтов

Установка, настройка программного обеспечения Linux, Windows операционных систем

Настройка нагруженных серверов High Load

В настоящее время в IT-среде всё чаще можно услышать термины «хайлоад», «настройка High Load сервера» («HL установка и настройка»). Большой нагрузкой зачастую пугают на собеседованиях при приёме на работу, о них рассказывают на профильных и не очень конференциях и семинарах. Многие стремятся работать с хайлоадом, однако мало кто в действительности понимает, что же это такое, и как должна осуществляться настройка HL серверов. Как правило, речь идёт о количестве запросов, приходящихся на секунду времени. Но что лучше – 1000 rps на статическую информацию либо 10 rps на системы, предназначенные для распознавания человеческих лиц?

Проекты высокой нагрузки

Все проекты высокой нагрузки можно условным образом разделить на четыре типа хайлоада:

  • по количеству запросов (баннерная сеть);
  • по логике (непростые вычисления на бэкэнде)
  • по трафику (видеосервис);
  • смешанные.

Рассмотрим их более подробно.

 Нагруженные системы по числу запросов

Говоря о данной категории проектов, в первую очередь необходимо отметить rps-ы. Ярким примером системы, ориентированной на большой объём запросов является рекламная баннерная сеть. В наиболее простом варианте она представляет собой веб сервер, базу данных, а также ряд скриптов, которые обеспечивают передачу клиентам из базы верных данных по разным критериям (в частности, учитывается тип устройства, с которого был получен запрос, место положения пользователя, текущее время и многое другое).

Что касается более сложных систем, то они включают одновременно несколько серверов «переднего плана» (нагрузка на них балансируется на уровне DNS-запросов). За указанными серверами может располагаться собственные серверы БД или же сторонние баннерные сети-партнёры (они также могут обеспечивать рекламу для клиентов (трафика)).

Применение только собственной независимой архитектуры может иметь следующие «узкие места»:

  • мощность процессора.

Данный вопрос решается благодаря верной настройке High Load сервера, оптимизации кода генерации баннеров. В крайнем случае, можно расширить число серверов отдачи.

  • Корректная настройка сетевых подсистем.

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

Что касается выходов из рассматриваемых ситуаций, то их оказывается не очень много. К примеру, можно попытаться кэшировать баннеры у себя либо же как-то попытаться договориться с партнёром. Очевидно, что огромную роль играет верная HL установка и настройка (настройка High Load сервера).

 Нагрузка сервера: трафик

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

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

Очевидно, что при больших нагрузках речь не идёт об единственном сервере. Зачастую в подобного рда ситуациях имеют место несколько серверных групп, которые географически распределены для обеспечения диверсификации рисков отказа.

Данные внутри каждой из групп синхронизируются по кольцу аналогичным образом как и между самими группами. Для этого применяются Isyncd/ rsynс. Что касается запросов к видеохранилищам, то их балансировка осуществляется на уровне DNS. В случае выхода из строя одного либо большего количества серверов они попросту выключаются из кольца синхронизации, а также из DNS.

Говоря об «узких местах» в данном случае стоит отметить следующие аспекты:

  • Пропускную способность сети

Так, увеличение нагрузки на тяжёлом трафиковом сервисе ведёт к нехватке ширины канала до сервера. Выход в этой ситуации имеется – необходимо попросу поменять карточку на более большую по объёму, к примеру, 100Мбитная заменяется на 1 Гбитную.

  • Дисковую производительность

Даже когда гигабитный канал производительности полностью загружен, SATA-дисков должно хватать. Если же вы хотите получить ещё большую скорость доступа к серверу, необходимо задуматься над приобретением SAS-дисков на 10000 оборотов и сложить их в десятый рейд.

  • Трафик

Для тех, кто планирует содержать трафиковые проекты, лучше отдавать предпочтение  хостерам, которые лояльным образом относятся к большому объёму информации, передаваемым серверами. При этом настройка High Load сервера также должна проводиться проверенными специалистами. Даже если вы сотрудничаете с системным администратором удалённо, необходимо тщательно контролировать его работу.

 Нагруженные сервера: Логика

Примером указанной категории проектов является интернет-магазин.

Допустим, у нас имеется интернет-магазин детских товаров (примерно 20 тысяч позиций продукции) различных маров, стоимости, рассчитанных на малышей разного возраста.

Чтобы найти в базе конкретную вещь можно, конечно, составить запрос, включающий порядка десятка условий, однако на «среднем железе» он будет выполняться очень долго.  Хорошо, если процесс займёт 10-20 секунд, а не несколько минут. Как же быть в таком случае?

Как вариант можно создать парк серверов, выполнить правильную настройку HL серверов, разделить информацию логическим образом по различным базам, для каждых из которых придётся сделать шардинг. Но что делать тем, кто не хочет тратить много денег на серверный парк?

Проблема может решаться и иным способом. Так, данный можно собрать в единую таблицу, содержащую около двадцати параметров. Каждому из них будет присвоено значение «0» либо «1». Получается, что в итоге создаётся маска из 20 бит (например, 01000001101111000001), характеризующая определённый товар.

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

Рассматрвиаемый подход обеспечивает сокращение затрат на серверную инфраструктуру проектов.

Что касается «узких мест» рассматриваемой категори проектов, то в первую очередь стоит отметить переиндексацию данных. Так, на большом объёме информации данная процедура может занимать много времени, при этом будет создаваться дополнительная нагрузка.

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

 Смещанный тип хайлоада

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

Действующая структура приведённого выше проекта выглядит следующим образом:

  • сервер переднего плана, содержащий веб-часть;
  • сервер с БД;
  • отдельное хранилище, где размещаются загруженные и сгенерированные фото;
  • сервис очередей;
  • пучок обрабатывающих серверов.

Всё это работает по схеме: пользователи загружают фото на хранилище, скрипты передают запросы в сервис очередей на «генерацию потенцаильного ребёнка», который контролирует, насколько загруженной является очередь генерации. Если она отсутствует, новая задача ставится в очередь. Когда имеет место большая нагрузка, а обработка поставленной задачи может затормозиться, то сервис очередей «идёт и приобретает дополнительный инстанс для генерации фотографий». После того, как загрузка снижается, лишние инстансы удаляются сервисом. Таким образом, минимизируются траты на содержание ненужных ресурсов и решается вопрос, касающийся резкого увеличения посещаемости ресурса.

«Узким местом» проектов со смешанным типом хайлоада является сервис очередей. Перед запуском его в работу, нужно обязательно провести тщательную проверку, настройку HL сервера, а после этого систематически мониторить перечень основных показателей.

Оставить комментарий

Лимит времени истёк. Пожалуйста, перезагрузите CAPTCHA.