Программирование с Ansible: Как сделать жизнь проще и немного веселее! 🚀

Бывают такие моменты, когда нужно приложить усилия, чтобы автоматизировать целую кучу компонентов в огромной системе,
и еще взаимодействовать с этими штуковинами по HTTP. Да, звучит серьезно, но давайте разберемся вместе! 🤖💬

Допустим, у нас есть проект, и нам приходится загружать файлы в Nexus.
Но ведь это не просто загрузка – нам нужно сделать это эффективно и идемпотентно. 📦🎯

Скажем, у нас есть список задач:
1. Рассчитать MD5-сумму файла.
2. Обратиться к Nexus и узнать, есть ли там такой файл.
3. Сравнить MD5-суммы файлов.
4. Решить, стоит ли загружать файл или уже есть такой. 🤔

На первый взгляд, всего лишь четыре пункта, но в реальности это может вылиться в кучу строчек кода в нашей Ansible-роли.
И вдобавок, если нужно как-то обрабатывать данные, то сложность только возрастает. 📜🔍

Но не переживайте, выход есть, и он называется Ansible action plugins либо же modules.
В чем разница? Modules работают на сервере, а action plugins – на вашей рабочей машине. 🖥️🔧

Нам как раз очень подходит последний вариант.
Для этого нам нужно создать основу, опираясь на официальное руководство.
И теперь самое интересное – мы можем использовать свою неповторимую логику.

Плюс в том, что мы работаем с полноценным языком программирования – Python, и можем использовать все его фишки.
Таким образом, можно значительно упростить нашу Ansible-роль, свести четыре задачи к одной. Волшебство! 🪄✨

#Ansible #ActionPlugins #Автоматизация #Python #Программирование

Кастомизация виртуальных машин пользовательскими shell скриптами

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

Недавно один из наших клиентов задал нам вопрос: "А что, если я хочу запускать свои shell-скрипты на вновь созданных виртуальных машинах?" Мы изучили вопрос и нашли несколько решений на эту проблему.

В большинстве платформ виртуализации и публичных облачных сервисов есть функциональность, позволяющая пользователю передавать свои скрипты на стадии преконфигурации. И казалось бы это то что нужно - использовать специально отведенное для таких задач поле. Однако выяснилось что каждая платформа имеет свои ограничения, например, размер параметра user_data в vSphere 7 не может превышать 3 кБ. Как же быть, если скрипты имеют больший размер?

Мы нашли вариант, который поможет решить эту проблему - использование встроенного ansible.builtin.shell модуля. Он позволяет выполнять любые консольные команды и применять на виртуальной машине shell-скрипты любого размера. Таким образом мы унифицируем все эти действия между разными платформами.

Сейчас эта опция уже находится в разработке и скоро будет выпущена в релиз!
Сталкивались ли с такой задачей? Как вам ее удалось решить?

#Автоматизация #shell #Ansible

Долгожданная новость ✨💫
Выпущен 64 релиз Cloudlink

Что нового?

Технические изменения:

1. Изменения в Order Service. Опции для настройки Дата-Центров, Платформ, Доменов и Сегментов сети административной панели перенесли в основное меню Control Panel. Это позволит проще настраивать инфраструктуру через UI 🤗
2. BugFix 🛠️. Решили проблему периодического конфликта разведки и деплоя виртуальных машин на платформе vSphere


Общие изменения:

1. По вашим заявкам добавили окно подтверждения выхода из портала самообслуживания 👍
2. Небольшие изменения в интерфейсе:
- дополнительные проверки корректности вводимых полей на странице создания организации

-фиксированное применение светлой темы

-корректирование имен фильтров в разделе IAM и Управление

Аналитика:

1. В карточках появилась возможность экспорта во внешние ресурсы 📈
это поможет нашим клиентам упростить интеграции с учетными системами 🔥 (например, с 1С 😉)


Продуктовый маркетплейс:

1. Добавили поддержку новой гостевой ОС AlmaLinux и тиражировали всю продуктовую линейку для этой ОС 🤩

2. Добавили новый продукт K8S 🥂🍾. Умеем создавать кластеры с различным количеством рабочих узлов и управлять ими (стоп/старт/ресайз) на всех поддерживаемых платформах (если вдруг забыли, мы работаем с vSphere, zVirt, Openstack)

Ставь лайк, если понравились фичи в новом релизе 👍

Кстати, мы открыли комментарии!
Самое время написать туда что бы вы хотели увидеть в следующем релизе 😊

#release_note #k8s #almalinux #iaas #paas #cloud

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

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

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

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

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

‰‰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 #балансировка