Рубрика «load balancing»
vPC-MLAG: сравнение Eltex с Cisco и Huawei
2025-04-23 в 14:47, admin, рубрики: Cisco, Eltex, hsrp, huawei, lag, load balancing, mlag, STP, VPC, vrrp
NGINX Mail Proxy: на пути к INBOX
2024-09-03 в 11:47, admin, рубрики: dovecot, imap, load balancing, mail, nginx, proxy, pythonПеред нами загруженный почтовый сервер с заполненными почтовыми ящиками, большим почтовым трафиком и задача сделать с этим что-нибудь, так как письма "не ходят", а ещё Sieve еле шевелится. Предположим, что докинуть ядер/дисков не получится, а сделать что-то нужно.
Можно развернуть архивный почтовый сервер, перекинуть туда письма старше N лет, сделать скрипты перемещения на основном, но это не для нас. Мы будем делать более элегантное решение, которое позволит нам в будущем упростить расширение почтовой инфраструктуры.
Для Nginx существует модуль mailЧитать полностью »
Босяцкий кластер высокой доступности
2022-08-22 в 1:01, admin, рубрики: DNS, failover, gtm, high availability, high availability clusters, high performance, keepalived, load balancing, nginx, vrrp, высокая производительность, Сетевые технологии, системное администрированиеПорой нам бывает нужно добавить избыточность какому-то сервису, который оказался публичной точкой входа в нашу инфраструктуру. Например, представьте, что мы хотим добавить второй балансировщик для высокой доступности. При этом балансировщики находятся на границе нашей сети и пересылают трафик доступным бэкенд-серверам.
Читать полностью »Как оценить ёмкость сервиса и не упасть под нагрузкой
2019-12-24 в 7:18, admin, рубрики: capacity planning, load balancing, performance testing, sre, Блог компании Яндекс, команда яндекс.маркета, Разработка веб-сайтов, системное администрирование, Тестирование IT-систем, Тестирование веб-сервисов
Рано или поздно любому растущему сервису приходится оценивать свои технические возможности. Сколько посетителей мы в силах обслужить? Какова ёмкость (она же capacity) системы? Не добрались ли мы до предела и не упадём ли, если привлечём ещё несколько тысяч пользователей? Сколько дополнительных вычислительных ресурсов заложить в бюджет на следующий год, чтобы соответствовать планам роста?
Ответы можно получить аналитическим путём, адресовав вопросы опытному разработчику/DevOps/SRE/админу. Достоверность оценки зависит от огромного числа факторов: начиная с темпов наполнения системы функциональностью и графа взаимосвязей между компонентами и заканчивая временем, которое эксперт с утра провёл в пробке. Чем сложнее система — тем больше сомнений в адекватности аналитической оценки.
Меня зовут Максим Куприянов, вот уже пять лет я работаю в Яндекс.Маркете. Сегодня я расскажу читателям Хабра, как мы учились оценивать ёмкость наших сервисов и что из этого вышло.
Читать полностью »
Пишем на Go простой балансировщик
2019-11-18 в 9:46, admin, рубрики: Go, load balancing, Блог компании Mail.Ru Group, высокая производительность, никто не читает теги, Разработка веб-сайтов, Сетевые технологии
Балансировщики нагрузки играют в веб-архитектуре ключевую роль. Они позволяют распределять нагрузку по нескольким бэкендам, тем самым улучшая масштабируемость. А поскольку у нас сконфигурировано несколько бэкендов, сервис становится высокодоступным, потому что в случае сбоя на одном сервере балансировщик может выбирать другой работающий сервер.
Поигравшись с профессиональными балансировщиками наподобие NGINX, я попробовал ради веселья создать простенький балансировщик. Написал я его на Go, это современный язык, поддерживающий полноценный параллелизм. Стандартная библиотека в Go имеет широкие возможности и позволяет писать высокопроизводительные приложения с меньшим количеством кода. К тому же для простоты распространения она генерирует единственный статически скомпонованный бинарник.
Читать полностью »
Архитектура сетевого балансировщика нагрузки в Яндекс.Облаке
2019-04-18 в 12:52, admin, рубрики: ECMP, health monitoring system, ipv4v6, load balancing, балансировка нагрузки, балансировка трафика, Блог компании Яндекс, высокая производительность, консистентное хеширование, облачные сервисы, Сетевые технологии, яндекс.облако
Привет, я Сергей Еланцев, разрабатываю сетевой балансировщик нагрузки в Яндекс.Облаке. Раньше я руководил разработкой L7-балансировщика портала Яндекса — коллеги шутят, что чем бы я ни занимался, получается балансировщик. Я расскажу читателям Хабра, как нужно управлять нагрузкой в облачной платформе, каким мы видим идеальный инструмент достижения этой цели и как движемся к построению этого инструмента.Читать полностью »
Check Point Maestro Hyperscale Network Security — новая масштабируемая security платформа
2019-02-04 в 6:14, admin, рубрики: check point, load balancing, maestro, security, tssolution, Блог компании TS Solution, информационная безопасность, Серверная оптимизация, Сетевые технологии, системное администрирование
Компания Check Point довольно резво начала 2019 год сделав сразу несколько анонсов. Рассказать обо всем в одной статье не получится, поэтому начнем с самого главного — Check Point Maestro Hyperscale Network Security. Maestro это новая масштабируемая платформа, которая позволяет наращивать «мощность» шлюза безопасности до «неприличных» цифр и практически линейно. Достигается это естественно за счет балансировки нагрузки между отдельными шлюзами, которые работают в кластере, как единая сущность. Кто-то может сказать — "Было! Уже есть блейд-платформы 44000/64000". Однако Maestro это совсем другое дело. В рамках этой статьи я вкратце постараюсь объяснить что это, как это работает и как эта технология поможет сэкономить на защите периметра сети.Читать полностью »
Проверки работоспособности и постепенная деградация распределенных систем
2018-12-17 в 15:46, admin, рубрики: devops, distributed systems, fault tolerance, kubernetes, load balancing, prometheus, reliability, Блог компании Southbridge, Серверное администрирование, системное администрирование
Как всегда, спасибо Фреду Хеберту и Саргуну Дхиллону за то, что прочли черновик этой статьи и предложили нескольких бесценных советов.
В своем докладе о скорости Тамар Берковичи из Box подчеркнула важность проверок работоспособности при автоматическом аварийном переключении баз данных. В частности, она отметила, что мониторинг времени выполнения сквозных запросов, как метод определения работоспособности базы данных, — лучше, чем простое эхо-тестирование (пингирование).
... перебрасывая трафик на другую ноду (реплику), чтобы устранить бездействие, надо построить средства защиты от дребезга и других пограничных ситуаций. Это не сложно. Фокус при организации эффективной работы в том, чтобы знать, когда перевести базу данных в первую позицию, т.е. надо быть в состоянии правильно оценить работоспособность базы данных. Сейчас многие параметры, на которые мы привыкли обращать внимание, — например, загрузка процессора, время ожидания блокировки, частота ошибок, — являются вторичными сигналами. Ни один из этих параметров на самом деле не говорит о способности базы данных к обработке клиентского трафика. Поэтому, если используете их для принятия решения о переключении, можете получить как ложноположительные, так и ложноотрицательные результаты. Наше устройство проверки работоспособности фактически выполняет простые запросы к узлам базы данных и использует данные о выполненных и невыполненных запросах для более точной оценки работоспособности базы данных.
Я обсудила это с другом, и он предположил, что проверки работоспособности должны быть предельно простыми, и что реальный трафик — это лучший критерий для оценки работоспособности процесса.
Kubernetes в production: сервисы
2018-09-24 в 14:34, admin, рубрики: devops, kubernetes, load balancing, Блог компании okmeter.io, отказоустойчивость, распределенные системы, Серверное администрирование, системное администрирование
Полгода назад мы закончили миграцию всех наших stateless сервисов в kubernetes. На первый взгляд задача достаточно простая: нужно развернуть кластер, написать спецификации приложений и вперед. Из-за одержимости в вопросе обеспечения стабильности в работе нашего сервиса пришлось сразу начать разбираться с тем, как работает k8s и тестировать различные сценарии отказов. Больше всего вопросов у меня возникало ко всему, что касается сети. Один из таких "скользких" моментов — работа сервисов (Services) в kubernetes.
В документации нам говорят:
- выкатите приложение
- задайте liveness/readiness пробы
- создайте сервис
- дальше все будет работать: балансировка нагрузки, обработка отказов итд.
Но на практике все несколько сложнее. Давайте посмотрим, как оно работает на самом деле.
Эксперименты с kube-proxy и недоступностью узла в Kubernetes
2018-05-24 в 6:16, admin, рубрики: devops, kube-proxy, kubernetes, load balancing, Блог компании Флант, системное администрированиеПрим. перев.: В этой статье, написанной техническим консультантом и сертифицированным администратором Kubernetes из Великобритании — Daniele Polencic, — наглядно показывается и рассказывается о том, какую роль играет kube-proxy в доставке пользовательских запросов до подов и что происходит, когда на одном из узлов кластера возникают проблемы.
Код приложений, развёрнутых в Kubernetes, запускается на одном или более рабочих узлов. Узел может располагаться как на физической или виртуальной машине, так и в AWS EC2 или Google Compute Engine, а наличие множества таких площадок означает возможность эффективного запуска и масштабирования приложения. Например, если кластер состоит из трёх узлов и вы решаете отмасштабировать приложение на четыре реплики, Kubernetes равномерно распределит их среди узлов следующим образом:
