Архив метки: load balancing

Настраиваем гугловый External Load Balancer через Deployment Manager

Как я и обещал когда-то, посмотрим теперь, как создать и настроить в гугловом облаке балансировщик нагрузки уже для внешнего траффика. External load balancer (ELB), то есть. Не кнопочками и формочками, а через файлы конфигурации и Deployment Manager, чтобы всё по-взрослому. Ведь хотя external балансировщик и будет похож на internal load balancer, это всё-таки совсем другой зверь:

  1. Во-первых, к external load balancer подключаются «снаружи» (Ваш КО. Не благодарите.). Но так как под «снаружи» попадает весь мир, основные компоненты балансировщика будут либо глобальные, либо хотя бы региональные.
  2. Во-вторых, ELB очень понимает, с каким траффиком он работает, и есть вдруг ему на вход подадут HTTP(S), то он в состоянии прочитать его заголовки и по URL выбрать тот бэкэнд сервис, которому этот траффик предназначался. Ага, на один ELB можно навесить много сервисов.
  3. В-третьих, ELB к тому же ещё и прокси, и если на вход ему приходит SSL, то на нём же SSL сессия и закончится. А дальше контент пойдёт либо с новой сессией, либо вообще нешифрованный.
  4. Ну и, наконец, убер бонус. Из-за того, что ELB умный, глобальный и исключительно софтварный, его нереально за DDoS’ить. По крайней мере, не сегодня. Серьёзно, самая мощная задокументированная DDoS атака была, кажется, что-то около 500 гигабит траффика в секунду. Всего один гугловый датацентр же может без особых проблем принять 1300. Датацентров много, ELB глобальный, так что have fun. После того как ELB поймёт, что траффик подозрительный, он его просто отсечёт от принимающих инстансов и «растворит» в себе.

На сегодня у гугла есть четыре породы внешних лоад балансеров: HTTP, HTTPS, SSL Proxy и TCP Proxy. Так как HTTPS самый замудрёный, его мы и будем сегодня препарировать.

Читать далее Настраиваем гугловый External Load Balancer через Deployment Manager

Настраиваем Internal Load Balancer через Deployment Manager

Прикольно, как некоторые относительно продвинутые инструменты и фрейморки стараются выглядеть проще и понятнее, и в результате превращаются во что-то ещё более зубодробительно невнятное. Давным-давно так было с git, когда мне пришлось перейти на командную строку и прочитать ‘Pro GIT’ целиком, чтобы гитовские GUI клиенты обрели хоть какую-то логику. Та же ерунда позже получилась с kubernetes, когда с более «простыми» kubectl run и kubectl expose было совсем непонятно, что же происходит на самом деле, в то время как перейдя на уровень ниже, к kubectl apply и YAML конфигурациям, всё стало на удивление простым логичным.

И вот теперь пришла очередь гугловых балансировщиков нагрузки — GCP load balancers. Глядя на все эти чекбоксы и кнопочки в гугловых визардах, я иногда чувствую себя младшим бухгалтером советского колхоза. С одной стороны, непонятно, что же именно я делаю. С другой стороны, непонятно — зачем. А вот как только создашь всё руками через файлы конфигурации, так всё снова кажется логичным. Читать далее Настраиваем Internal Load Balancer через Deployment Manager

Автоматическое масштабирование билд-серверов в GitLab CI

автоматическое масштабирование билд-серверов

На своём рабочем проекте Gitlab CI я использую уже где-то с год, и с большего всё было хорошо. Начинали мы с трёх билд-серверов (GitLab раннеров) под проект, а когда в команде появлялись новые люди, пытающиеся валом коммитов удивить начальство, либо билд-задач просто становилось больше, я добавлял ещё один сервак для возросшей нагрузки, и чувствовал себя героем. Но когда количество серверов пошло на второй десяток, то как-то стало понятно, что такой подход больше не работает.

Во-первых, всё равно случались пиковые нагрузки, с которыми билд-кластер справиться не мог. Хотя бы пару раз в неделю были периоды, когда количество билд-задач было раза в два больше, чем сервера могли вытянуть.

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

В общем, стало ясно, что существующий подход надо на что-то менять. Желательно на что-нибудь динамическое. И что здорово, в GitLab CI -таки встроено автоматическое масштабирование билд-серверов под текущую нагрузку. Её-то мы и будем сегодня пробовать.

Читать далее Автоматическое масштабирование билд-серверов в GitLab CI