Рубрика «load balancing»

Прим. перев.: В этой статье, написанной техническим консультантом и сертифицированным администратором Kubernetes из Великобритании — Daniele Polencic, — наглядно показывается и рассказывается о том, какую роль играет kube-proxy в доставке пользовательских запросов до подов и что происходит, когда на одном из узлов кластера возникают проблемы.

Код приложений, развёрнутых в Kubernetes, запускается на одном или более рабочих узлов. Узел может располагаться как на физической или виртуальной машине, так и в AWS EC2 или Google Compute Engine, а наличие множества таких площадок означает возможность эффективного запуска и масштабирования приложения. Например, если кластер состоит из трёх узлов и вы решаете отмасштабировать приложение на четыре реплики, Kubernetes равномерно распределит их среди узлов следующим образом:

Эксперименты с kube-proxy и недоступностью узла в Kubernetes - 1Читать полностью »

Kubernetes NodePort vs LoadBalancer vs Ingress? Когда и что использовать? - 1

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

Примечание: рекомендации рассчитаны на Google Kubernetes Engine. Если вы работаете в другом облаке, на собственном сервере, на миникубе или чем-то еще, будут отличия. Я не углубляюсь в технические детали. Если хотите подробностей, обратитесь к официальной документации.

Читать полностью »

HAProxy как LoadBalanсer для RDP фермы.

Совершенно случайно, в пассивном поиске альтернативы устаревшему 2X-LoadBalancer и тяжелому, непонятному Remote Connection Broker от MS наткнулся на HAProxy и его умению проксировать RDP трафик. В выдачах поисковиков практически не выдается haproxy в качестве прокси для RDP. Сейчас вдруг пачками стал выдавать. Вместе с тем, коммерческие продукты с таким же функционалом, такие как упоминались выше, стоят приличных денег.

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

Основы компьютерных сетей. Тема №8. Протокол агрегирования каналов: Etherchannel - 1

И снова всем привет! После небольшого перерыва, продолжаем грызть гранит сетевой науки. В данной статье речь пойдет о протоколе Etherchannel. В рамках данной темы поговорим о том, что такое агрегирование, отказоустойчивость, балансировка нагрузки. Темы важные и интересные. Желаю приятного прочтения.
Читать полностью »

Балансировка нагрузки с Pacemaker и IPaddr (Active-Active cluster) - 1

Хочу рассказать вам еще об одном способе балансировки нагрузки.
Про Pacemaker и IPaddr (ресурс-агент) и настройке его для Active/Passive кластера сказано уже и так достаточно много, но информации по организации полноценного Active/Active кластера, используя этот модуль я нашел крайне мало. Постараюсь исправить эту ситуацию.

Для начала расскажу подробнее чем такой метод балансировки примечателен:

  • Отсутсвие внешнего балансировщика — На всех нодах в кластере настраивается один общий виртуальный IP-адрес. Все запросы отправляются на него. Ноды отвечают на запросы на этот адрес случайно и по договоренности между ссобой.
  • Высокая доступность — Если одна нода падает ее обязаности подхватывает другая.
  • Простота настройки — Настройка осуществляется всего в 3-5 команд.
    Читать полностью »

Преамбула

Некоторе время назад перед нами стала задача спроектировать и развернуть систему для потокового видео. Суть была в массовом запуске/остановке инстанций, на которых происходит обратная сборка потокового видео и стриминг на множество media cdn провайдеров (youtube, livestream, ustream итд ) а также на собственные rtmp и ts точки назначения. Каждая инстанция требовала настройки перед запуском т.к. содержала специфическую для каждого клиента информацию. Также было понятно, что система должна работать в большом количестве регионов (как минимум во всех точках, где присутствует Амазон, а как максимум — в любом месте где можно арендовать сервер). Также основное требование — запуск инстанции в течении 1-2 секунд максимум, чтобы это было прозрачно для пользователя.

Читать полностью »

Зачем все это нужно

Все кто использовал Elasticsearch каластер для своих нужд (особенно для логирования и как основную базу данных) на больших нагрузках сталкивался с проблемами консистентности и масштабируемости. Когда требуется распараллелить нагрузку на Elasticsearch обычно применялись статические решения то типу NGINX+Elasticsearch. Это позволяет распараллелить нагрузку, но выглядит не слишком гибко. Особенно если учесть что ноды могут сами выпадать из кластера и простой хелсчек покажет что все отлично, а на самом деле нода перегружена, исключена из кластера. В любом случае хотелось бы иметь данные о состоянии кластера из первых рук, а не довольствоваться простыми проверками.
Итак, приступим к построению балансировки .

Как мы будем это делать

В данном случае мы будем использовать CAT node API, которое является частъю мощьнейшего CAT API, который является инструментом поиска заголовков по Elasticsearch клстреру.
Мы будем использовать только Gobetween и встроенные механизмы Elasticsearch для балансировки записи /чтения СRUD (DATA) нод при произвольном количестве/статусе нод в кластере.

Читать полностью »

Как все начиналось

В ходе работы с микросервисами мы неоднократно сталкивались с проблемами сервис дискавери при автоскелинге, схлопывании лишних нод.

Были перепробованы почти все решения существовавшие или существующие на данный момент, но как водится — ничего не ложилось идеально на наши динамичные окружения (десятки остановок/запусков однотипных контейнеров в час). Наиболее близкое решение было NGINX+Consul+Consul templates, но оно было некрасивым, требовало перезапуска, не давало возможности использовать внешние хелсчеки иначе как через Consul.

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

Предисловие. Эта публикация — продолжение темы создания отказоустойчивого кластера Windows Server в облаке Microsoft Azure. На этот раз разговор пойдёт про сеть.

Отказоустойчивый кластер Windows Server в Microsoft Azure. Сеть - 1

Привет, фанаты кластеров. В своей предыдущей статье я рассказал о том, как обойти ограничения среды Microsoft Azure IaaS при подготовке хранилища данных для отказоустойчивого кластера Microsoft Windows. Давайте теперь поговорим о другой важной части создания кластера — сети.

Читать полностью »

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

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

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

Балансировка нагрузки может осуществляться при помощи как аппаратных, так и программных инструментов. Об основных методах и алгоритмах и балансировки мы бы хотели рассказать в этой статье.
Читать полностью »