🚀 Маленькая, но важная частичка инфраструктуры для работы кластеров. ⏰

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

🔧 Сейчас мы находимся в процессе разработки продукта Kubernetes,
который можно будет получить буквально парами кликов мышки.
И для построения мульти мастера критически важно синхронизированное время между нодами.
Оно гарантирует, что все внутренние события и логи являются консистентными,
что в свою очередь помогает избежать ошибок и конфликтов, связанных со смещенным временем (aka split-brain).

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

#Kubernetes #инфраструктура #серверы #кластеры #разработка

Постмортем как неотъемлемая часть работы инженера

Разберемся что такое постмортем и как отделять мух от котлет работу от текучки


Инженерная работа vs операционная текучка

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

Хорошо, когда инженер тратит не более 50% своего времени на обработку запросов на обслуживание и сопровождение внедрений. В таком случае, остальное время используется для работы над проектами. А проекты — это отличный плацдарм для прокачивания своих hard skills.
Этого показателя можно достичь на практике путем наблюдения за количеством операционной работы, выполняемой командой инженеров. Все, что выходит за рамки 50% — перенаправлять на команды разработки заранее согласованным и утвержденным маршрутом для последующей автоматизации, желательно без ручного участия. Этот способ обеспечивает эффективную обратную связь, ориентируя разработчиков на создание систем, не требующих человеческого вмешательства. Чтобы такой подход работал, все команды внутри компании должны понимать почему это ограничение существует.

Постмортем

Опираясь на опыт работы наших самых больших коллег, оптимальное число критических событий для обработки не должно достигать более трех за 8-часовую смену на дежурстве. В таком случае, инженеру точно удастся обработать событие и восстановить сервис, а затем проанализировать первопричину произошедшего. Если событий больше чем три, то у инженеров не получится предотвратить аналогичные ошибки в будущем.
Стоит обратить внимание на то, что если инженер стабильно получает меньше критических событий за дежурство, то нельзя считать его работу на месте дежурного пустой тратой времени. Есть легенда, что в крупных зарубежных компаниях инженерам, отвечающим за стабильность сервисов, платят щедрые бонусы, когда все сервисы в зоне их ответственности показывают пресловутые «пять девяток» доступности (если это не так, то дайте знать).

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

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

#engineering #sre #management

Бюджет ошибок и его влияние на качество внедрений

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

Суммарный уровень или error budget

Противоречия между командами разработчиков и инженеров заключается в соотношении темпов внедрения изменений и стабильности продукта.
Мы должны приложить все усилия, чтобы вывести этот конфликт на первый план, а затем постепенно избавляться от него, вводя понятие суммарного уровня ошибок, или бюджета ошибок (error budget).
Это значит что достижение 100%-ной надежности будет необоснованным требованием в подавляющем большинстве случаев. Посудите сами: для любой* системы 100 % — избыточный показатель надежности, поскольку ни один пользователь не заметит разницу между 100% и 99,999%, так как она теряется на фоне случайных факторов, обусловленных недоступностью других систем (wi-fi, ноутбук и т.д.).
Прежде чем начать размышления на тему стремления к 100% уровню надежности, то задайте сами себе следующие вопросы:
• ‰Есть ли у недовольных доступностью пользователей какие-либо альтернативы?
• ‰‰Как на них отразится изменение уровня доступности продукта?
• ‰Какой показатель доступности удовлетворит пользователей, при условии, что мы знаем как и когда они используют продукт?

Нужно ли стремиться к «сотне» и переживать из-за багов?

Коротко: в подавляющем большинстве случаев — нет*.
Система должна иметь установленный целевой показатель доступности.
Как только этот показатель будет определен, также будет определен допустимый суммарный уровень ошибок, который будет равен единице минус запланированный показатель доступности.
Например: доступный в 99,99 % случаев сервис будет недоступен в 0,01 % случаев. 0.01% — ни что иное как бюджет ошибок.
Участники команд вольны тратить этот «бюджет» на все, что хотят, но лучше тратить на что-то полезное (спасибо, кэп🫡).
Однако если бюджет ошибок потрачен или понижен (т.е. сервис работает на уровне, определенном в SLA или ниже его), то запуск любых новых возможностей замораживается до тех пор, пока команда не уменьшит количество ошибок до уровня, позволяющего продолжить запуск.

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

*если речь идет о каком-то сервисе, который подвергает риску жизни людей или большому финансовому убытку, то, безусловно, доступность должна быть 100% (например, системы поддержания жизнедеятельности и иные медицинские сервисы, автоматическая система торможения в автомобиле, системы мониторинга на ГЭС/АЭС и т.д;)


#engineering #sre #management #sla

Программирование с 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