Мониторинг и реагирование на критические ситуации

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

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

Категоризация событий

Существует три категории данных от системы мониторинга:

‰‰1. Срочные оповещения (alerts) — указывают, что нужно немедленно реагировать на что-то, что либо уже произошло, либо вот-вот произойдет.
2. Запросы на действия (tickets) — указывают на то, что система не может обработать событие автоматически, но предпринимать какие-то действия можно не сразу.
‰‰3. Журналирование (logging) — полезные для диагностических целей артефакты.

f(MTTF, MTTR) = Надежность

Надежность - это функция от MTTF и MTTR

Mean time to failure, MTTF — среднее время безотказной работы
Mean time to repair, MTTR — среднее время восстановления, самый значимый критерий оценки эффективности реагирования на критические ситуации.

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

Какой системой мониторинга пользуетесь вы? Довольны ли выбором системы оповещений?

#мониторинг #engineering #sre #надежность #alerts

Всех с пятницей! 🚀

Желаем хорошо провести эти выходные и набраться сил!

На следующей неделе поговорим про:
• Мониторинг распределенных систем — как наблюдать за большим приложением и при этом ничего не упустить
• Выбор подходящего уровня детализации для измерений показателей — как не положить сервис избыточными запросами
• Эволюция автоматизации — зачем нужно перекладывать рутину на автоматизацию и как Cloudlink может помочь с этим
• Поделимся запланированными новыми фичами нашего продукта
До встречи!

Эффективная работа с архивами Docker образов 🐳

Иногда возникает необходимость перенести Docker образ в закрытый контур и импортировать его в какое-либо хранилище.
И мы хотим сделать это как можно эффективнее, с точки зрения размера файла и времени импорта.
Как раз с такой задачей мы столкнулись на нашем проекте при развертывании Cloudlink. ☁️

В чем собственно проблема? 🤔
У нас есть порядка 70 образов, которые необходимо доставить на сервер, так называемым air-gap способом, чтобы обеспечить установку в полностью закрытых контурах, без интернета.

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

Способ №1 - docker save 📚
Если мы используем Docker, то кажется что самый простой вариант - это воспользоваться стандартной командой:

docker save python:3.11-slim > python-3.11.tar

В результате мы получили tar архив, в нем присутствуют метаданные и слои, но они находятся в не сжатом виде, поэтому размер файла достаточно большой (в случае с нашим образом получилось 149M). 😱

Хорошо, мы можем его сжать, используя gzip: 🗜️

docker save python:3.11-slim | gzip -c > python-3.11.tar.gz

Уже неплохо, размер файла значительно уменьшился (теперь 50M). 😌
По итогу получилось что метаданные и слои сжаты.

Если мы хотим каким-то образом работать с метаданными, которые находятся в архиве, то сначала придется разархивировать файл.

time tar -xzf python-3.11.tar.gz manifest.json

0.38s user 0.01s system 99% cpu 0.393 total

Кажется что 0.393 секунд это не много, но если мы работаем с большими образами (> 1GB), то разархивирование может занимать до нескольких секунд на один файл ⏳

Способ №2 - skopeo 🛠️
Следующий способ который мы попробовали - это использование skopeo:

skopeo copy docker://python:3.11-slim docker-archive:python-3.11.tar

К сожалению такой способ нам так же не совсем подходит, так как на выходе получается не сжатый tar файл (149M). 😞
Так же мы столкнулись с трудностями установки skopeo на относительно старые дистрибутивы, например Ubuntu 20.04 🐧, где нужно собирать пакет из исходников, что добавляет трудностей в поставке на полностью закрытые контура, air-gap методом.

Способ №3 - crane 🏗️
Далее мы решили попробовать crane:

crane pull python:3.11-slim python-3.11.tar

Кажется что он так же делает простой tar файл, но как оказалось не совсем. 🧐
Во-первых, мы сразу видим что его размер 51M. 👍
Если заглянуть внутрь, то мы увидим что слои внутри сжаты, но при этом метаданные нет:

tar -tf python-3.11.tar

sha256:596e0d6b34dfaa7ed330941075bcd38b376b3eba8e5b63a1da38bf04fe08bdd3
52d2b7f179e32b4cbd579ee3c4958027988f9a8274850ab0c7c24661e3adaac5.tar.gz
2b8a9a2240c1224b34f6aafbc3310f9a3fe65bd6893050906d02e89fc8326aa9.tar.gz
051d6521462a7eb4ca0374e97701d6eec68eb51b118d3ef5d002798b498fb12e.tar.gz
fce84b1f897c621e9474bd4d5a49e2e22fa35e248e78e754010d34ec3d2d28cd.tar.gz
46233543d8c2dc599bdb9d522180ca9e14cad4ac2017a5dc481660bfa4aa3ed9.tar.gz
manifest.json

Таким образом мы можем очень быстро эти метаданные читать, при этом не сильно теряя в размере файла. 🚀

time tar -xzf python-3.11.tar manifest.json

0.00s user 0.00s system 65% cpu 0.005 total

Итоги 🫶
Мы решили остановиться на crane, так как он полностью покрывает нужную нам функциональность и делает скачивание/загрузку образов простой и эффективной.

Надеюсь, что наш пост был полезным для вас и вы нашли что-то новое и интересное. 😊

#docker #crane #skopeo #devops #dockerimages

Прогнозирование нагрузки и планирование производительности

Поговорим про capacity-менеджмент и обеспечение запланированной производительности, а также как Cloudlink поможет не испытывать ресурсный кризис.

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

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

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

Материальное обеспечение

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

Производительность и эффективность

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

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

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

#capacity #engineering #computing

🔥Cloudlink включен в реестр отечественного ПО 🔥


Вчера пришла отличная новость, что Cloudlink включен в реестр отечественного ПО
Реестровая запись №18665 от 22.08.2023

Программы, зарегистрированные в реестре российского ПО, могут распространяться под 0% НДС (п.26 ст.149 НК РФ) на основании:

‰ • лицензионных договоров;
‰ • договоров на отчуждение исключительных прав на ПО;
‰ • продажу экземпляров ПО.

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

Ждем ваши огонечки 🔥и принимаем поздравления в комментариях 🤗👇

Ура-а-а!!!

#cloudlink #реестр_отечественного_по

Один дизайн, чтобы управлять всем. UI всевластия.

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

Как мы достигли этого?

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

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

Тем не менее, уже сейчас проделанная работа позволяет использовать новый пользовательский интерфейс, который вы сможете очень скоро опробовать!

#дизайн #разработка #ui #frontend #cloudlink

🔥Созвездие OrionSoft в Telegram🔥

@orionsoftru здесь всё про экосистему наших решений для построения ИТ-инфраструктуры космического уровня:
⁃ zVirt — защищенная платформа серверной виртуализации
⁃ Proxima DB — российская СУБД на базе PostgreSQL
⁃ Nova Container Platform — платформа для оркестрации контейнеризированных приложений
⁃ Cloudlink — on-premise решение для управления виртуализацией
⁃ Termit — система терминального доступа

Подписывайся, чтобы знать о тенденциях в сфере ИТ-инфраструктуры

#orionsoft #zvirt #cloudlink #proximadb #nova #termit

👋🏼 С пятницей всех! Впереди выходные, а значит будет время подумать о горячей теме – миграции с VMware на zVirt. Насколько это больно? 😉

Сейчас процесс миграции такой (на примере одного крупного заказчика):

👉🏼 17 операций (из них 3 ручные)
👉🏼 Миграция 1 ВМ занимает десятки минут
👉🏼 По 1 ВМ за раз (по очереди)
👉🏼 Примерно 50 ВМ в месяц

А вот так будет в Q4 после внедрения автомиграции (v2v-миграции):

🤩 Всего 2 клика
🤩 Миграция 1 ВМ занимает десятки секунд
🤩 Несколько ВМ параллельно
🤩 Примерно 300 ВМ в месяц

Ждать уже недолго!

#zVirt #новости_продуктов

Балансировка нагрузки 1/7

В этой серии постов поговорим про уровни и типы балансировки, их основные алгоритмы и методы. Сегодня напомним уровни балансировки в целом и про балансировку на сетевом уровне в частности.

Зачем нужна?

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

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

Основные цели:
• Распределение нагрузки между серверами
• Повышение отказоустойчивости
• Защита от некоторых видов атак


Уровни балансировки

Балансировка нагрузки осуществляется при помощи аппаратных и программных инструментов, т.е. целого комплекса алгоритмов и методов, соответствующим уровням модели OSI:

• сетевой уровень
• транспортный уровень
• прикладной уровень

Расскажем обо всем по порядку

Балансировка на сетевом уровне

Чтобы сделать балансировку на сетевом уровне, нужно сделать так, чтобы на один IP-адрес сервера (destination IP) отвечали разные машины. Такая балансировка может осуществляться несколькими способами:

• DNS-балансировка. На одно доменное имя выделяется несколько IP-адресов. Сервер, на который будет направлен клиентский запрос, обычно определяется с помощью алгоритма Round Robin
• Построение NLB-кластера. При использовании этого способа серверы объединяются в кластер, состоящий из входных и вычислительных узлов. Распределение нагрузки осуществляется при помощи специального алгоритма
• Балансировка по IP с использованием дополнительного маршрутизатора.
• Балансировка по территориальному признаку осуществляется путём размещения одинаковых сервисов с одними и теми же адресами в территориально разных регионах размещения (например, Anyсast DNS и в различных CDN).

Плюс такого метода:
• Независимость от протоколов высокого уровня
• Один публичный адрес
• Полная прозрачность работы для серверов

Недостатки:
• Повышенная нагрузка на балансировщик за счет обратного графика

#балансировка_нагрузки #модель_osi #engineering #dns

Балансировка нагрузки 2/7

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

Балансировка на транспортном уровне (ECMP)

Клиент обращается к балансировщику, тот перенаправляет запрос одному из серверов, который будет его обрабатывать. Выбор сервера, на котором будет обрабатываться запрос, может осуществляться в соответствии с самыми разными алгоритмами: путём кругового перебора, путём выбора наименее загруженного сервера из пула и т.д.

Зачастую балансировку на транспортном уровне не отличить от балансировки на сетевом уровне. Рассмотрим следующее правило для сетевого Packet Filter в OpenBSD: тут идет речь про балансировку трафика на конкретном 80-ом порту TCP:

web_servers = "{ 3.3.3.1, 3.3.3.2, 3.3.3.3 }"

match in on $ext_if proto tcp to port 80 rdr-to $web_servers round-robin sticky-address

Рассмотрим теперь другой пример:

pass in on $int_if from $lan_net \
route-to { ($ext_if1 $ext_gw1), ($ext_if2 $ext_gw2) }\
round-robin

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

В чем различие?

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

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

Плюсы
• Все также не зависит от протоколов высокого уровня
• Все также один публичный адрес

Минусы

• Надо устанавливать на серверы дополнительный софт, чтобы анонсировать серверную сеть на роутер
• Ограниченное количество ECMP на роутер (от 8 до 32 маршрутов, в зависимости от роутера)
• При такой схеме нагрузка на все серверы распределяется равномерно, что накладывает требование одинаковости на все серверы. И если добавлять в кластер более современный, мощный, сервер, нагрузка на него будет не больше, чем на соседа.

#балансировка_нагрузки #транспортный_уровень #ecmp #engineering

Балансировка нагрузки 3/7

Балансировка на прикладном уровне

На этом уровне балансировщик работает в режиме «умного прокси», он анализирует клиентские запросы и перенаправляет их на разные серверы в зависимости от характера запрашиваемого контента. Так работает, например, Nginx, распределяя запросы между фронтендом и бэкендом. За балансировку в Nginx отвечает модуль Upstream.

Nginx. Установка и дополнительные способы эффективного распределения нагрузки

Nginx можно быстро установить с помощью apt-get (при наличии соответствующих привелегий, естественно):

sudo apt-get install nginx

Для настройки round robin нам потребуется использовать модуль upstream. Включим конфигурацию в настройки nginx, например:

sudo nano /etc/nginx/sites-available/default

Добавляем файл конфигурации

upstream backend { server backend1.example.ru; server backend2.example.ru; server backend3.example.ru; }

Ссылаемся на этот модуль:

server { location / { proxy_pass http://backend; } }

Перезапускам nginx:

sudo service nginx restart

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

Выглядит хорошо, но можно лучше.

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

Настройка балансировки нагрузки с учетом веса сервера может выглядеть следующим образом:

upstream backend { server backend1.example.ru weight=1; server backend2.example.ru weight=2; server backend3.example.ru weight=4; }

По умолчанию вес равен 1. При весе 2 на backend2.example будет отправляться в два раза больше трафика, чем на backend1, а backend3 с весом 4 будет обрабатывать в два раза больше трафика, чем backend2, и в четыре раза больше, чем backend1.

IP-хэш позволяет серверам отвечать клиентам в соответствии с их IP-адресом, отсылая посетителей к одному и тому же VPS при каждом посещении (если только этот сервер не отключен). Если известно, что сервер не работает, он должен быть помечен как неработающий. При этом все IP-адреса, которые должны были направляться на неработающий сервер, перенаправляются на другой:

upstream backend { ip_hash; server backend1.example.ru; server backend2.example.ru; server backend3.example.ru down; }

По умолчанию nginx будет отправлять данные на серверы, даже если они не отвечают. Max fails позволяет автоматически предотвратить это, переводя не отвечающие серверы в нерабочее состояние на заданный промежуток времени.

С max fails связаны два фактора: max_fails и fall_timeout.
Max fails означает максимальное количество неудачных попыток подключения к серверу, которое должно произойти, прежде чем он будет признан неактивным.
Fall_timeout определяет время, в течение которого сервер считается неработоспособным. По истечении этого времени новые попытки связаться с сервером начнутся снова, по умолчанию 10 секунд.

upstream backend { server backend1.example.ru max_fails=3 fail_timeout=15s; server backend2.example.ru weight=2; server backend3.example.ru weight=4;

Что есть еще?

В качестве ещё одного примера инструмента балансировки на прикладном уровне можно привести pgpool — промежуточный слой между клиентом и сервером СУБД PostgreSQL. С его помощью можно распределять запросы серверам баз данных в зависимости от их содержания, например, запросы на чтение будут передаваться на один сервер, а запросы на запись — на другой.

Установив Cloudlink в периметре своей организации вы можете за 5 минут в несколько кликов получить сервер с предустановленным Nginx и PostreSQL любой версии и любой конфигурации, в том числе отказоустойчивый геораспределенный кластер СУБД👏🏻
Забудьте про потенциальные ошибки при ручном конфигурировании, доверьте свою инфраструктуру умной автоматизации Cloudlink 👍🏻

Записывайтесь на демо в комментариях

#engineering #прикладная_балансировка #nginx

Балансировка нагрузки 4/7

Принципы выбора алгоритма и метода балансировки

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

Среди целей и свойств следует выделить следующие:

• справедливость: гарантировать, что на обработку каждого запроса выделяются системные ресурсы и не допускать возникновения ситуаций, когда один запрос обрабатывается, а все остальные ждут своей очереди
• эффективность или равномерная загрузка ресурсов системы: все серверы, обрабатывающие запросы, должны быть заняты на 100%. Нельзя допускать ситуации, когда один из серверов простаивает в ожидании запросов на обработку (к слову, в реальности это практически недостижимо, но к этому нужно стремиться)
• сокращение времени выполнения запроса: следует обеспечить минимальное время между началом обработки запроса и его завершения
• сокращение времени отклика: нужно минимизировать время ответа на запрос пользователя
• предсказуемость: понимать при каких ситуациях и нагрузках алгоритм будет эффективным
• масштабирумость: алгоритм должен сохранять работоспособность при увеличении нагрузки.
#load_balancer #балансировка

Балансировка нагрузки 5/7

Round Robin

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

Самой распространёной имплементацией этого алгоритма является Round Robin DNS. Любой DNS-сервер хранит пару «имя хоста — IP-адрес» для каждой машины в определённом домене. С каждым именем из списка можно ассоциировать несколько IP-адресов. Выглядит это примерно так:

www.example.ru 1.1.1.1
www.example.ru 2.2.2.2
www.example.ru 3.3.3.3
www.example.ru 4.4.4.4


DNS-сервер проходит по всем записям таблицы и отдаёт на каждый новый запрос следующий IP-адрес: например, на первый запрос — 1.1.1.1, на второй — 2.2.2.2, и так далее. В результате все серверы в кластере получают одинаковое количество запросов.

Плюсы:
• Независимость от протоколов высокого уровня. Round Robin использует любой протокол, в котором обращение к серверу идёт по имени
• Не зависит от нагрузки на сервер. Кэширующие DNS-серверы помогут справиться с любым наплывом клиентов.
• Не требует связи между серверами. Можно использовать для локальной и для глобальной балансировки
• Практически нулевая стоимость. Достаточно добавить несколько записей в DNS.

Минусы:
• При выполнении всех операций должно быть задействовано одинаковое количество ресурсов. В реальности эти условия в большинстве случаев невыполнимы.
• Не учитывается количество активных подключений на данный момент времени
• Не учитывает загруженность серверов в кластере. Если один из серверов загружен на 100%, а другие на 10-15%, то по умолчанию загруженный сервер будет получать столько же запросов сколько и остальные


Weighted Round Robin

Как следует из названия, это усовершенствованная версия алгоритма Round Robin, в которой каждому серверу присваивается весовой коэффициент в соответствии с его производительностью. Это помогает распределить нагрузку более гибко: серверы с большим весом обрабатывают больше запросов, но надо понимать, что это не идеальное решение проблемы отказоустойчивости.

#engineering #dns #round_robin #балансировка_нагрузки

Балансировка нагрузки 6/7

Leastconn

Допустим есть два сервера: к server1 подключено меньше пользователей, чем к server2, но первый оказывается более перегруженным. Это происходит из-за того, что к server1 подключения поддерживаются дольше, чем к server2.

Такая проблема решается с помощью алгоритма least connections, который учитывает количество подключений, поддерживаемых серверами в текущий момент времени и каждый следующий вопрос передаётся серверу с наименьшим количеством активных подключений.

Как и во всех предыдущих примерах, есть усовершенствованная версия этого алгоритма — Weighted Least Connections — которая делает то же самое + учитывает весовой коэффициент серверов.

Locality-Based Least Connection Scheduling

Этот метод создан для кэширующих прокси-серверов: наибольшее количество запросов передаётся серверам с наименьшим количеством активных подключений. За каждым из клиентских серверов закрепляется группа клиентских IP. Запросы с этих IP направляются на «родной» сервер, если он не загружен полностью. Если загружен, то запрос уйдет на другой, менее чем на половину загруженный сервер.

Locality-Based Least Connection Scheduling with Replication Scheduling

В этом алгоритме каждый IP-адрес или группа IP-адресов закрепляется за целой группой серверов. Запрос передаётся наименее загруженному серверу из группы. Если же все серверы из «родной» группы перегружены, то будет зарезервирован новый сервер. Этот новый сервер будет добавлен к группе, обслуживающей IP, с которого был отправлен запрос. Чтобы избежать избыточной репликации, наиболее загруженный сервер из этой группы будет удалён


#балансировка_нагрузки #engineering