Здравейте всички! Курсът започва днес , във връзка с което проведохме съответен тематичен уебинар, посветен на прегледа на ELB. Разгледахме типовете балансьори и създадохме няколко екземпляра EC2 с балансьор. Проучихме и други примери за употреба.
, Ти ще:
- разберете какво е AWS Load Balancing;
- познава видовете Elastic Load Balancer и неговите компоненти;
- използвайте AWS ELB във вашата практика.
Защо изобщо трябва да знаете това?
- полезно, ако планирате да се явите на изпити за сертифициране на AWS;
- това е лесен начин за разпределяне на натоварването между сървърите;
- Това е прост начин да добавите Lambda към вашата услуга (ALB).
Проведе открит урок , системен инженер в маркетингова компания за разработка и поддръжка на уебсайтове.
въведение
Какво е Elastic Load Balancer може да се види на диаграмата по-долу, която показва прост пример:
Load Balancer приема заявки и ги разпределя между инстанции. Имаме един отделен екземпляр, има Lambda функции и има AutoScaling група (група от сървъри).
Типове AWS ELB
1. Нека да разгледаме основните видове:
Класически Load Balancer. Първият балансьор на натоварването от AWS работи както на OSI слой 4, така и на слой 7, като поддържа HTTP, HTTPS, TCP и SSL. Той осигурява основно балансиране на натоварването в множество екземпляри на Amazon EC2 и работи както на ниво заявка, така и на ниво връзка. Нека го отворим (маркирано в сиво):
Този балансьор се счита за остарял, така че се препоръчва да се използва само в определени случаи. Например за приложения, изградени в мрежата EC2‑Classic. По принцип никой не ни пречи да го създадем:
2. Балансиране на натоварването на мрежата. Подходящ за големи натоварвания, работи на OSI Layer 4 (може да се използва в EKS и ECS), TCP, UDP и TLS се поддържат.
Network Load Balancer насочва трафика към цели в Amazon VPC и е в състояние да обработва милиони заявки в секунда с изключително ниска латентност. Освен това, той е оптимизиран да се справя с модели на трафик с внезапни и променящи се натоварвания.
3. Балансиране на натоварването на приложенията. Работи на слой 7, има поддръжка на Lambda, поддържа правила за ниво на заглавка и път, поддържа HTTP и HTTPS.
Осигурява разширено маршрутизиране на заявки, фокусирано върху доставяне на приложения, изградени върху модерни архитектури, включително микроуслуги и контейнери. Насочва трафика към цели в Amazon VPC въз основа на съдържанието на заявката.
За много потребители Application Load Balancer беше първият избор за замяна на Classic Load Balancer, тъй като TCP не е толкова често срещан, колкото HTTP.
Нека го създадем също, в резултат на което вече ще имаме два балансира на натоварването:
Компоненти за балансиране на натоварването
Общи компоненти за балансиране на натоварването (общо за всички балансьори):
- Правила за регистриране на достъп
— вашите регистрационни файлове за достъп до ELB. За да направите настройки, можете да отидете на Описание и да изберете бутона „Редактиране на атрибути“:
След това посочваме S3Bucket - съхранение на обекти на Amazon:
- схема
— вътрешен или външен балансьор. Въпросът е дали вашият LoadBalancer трябва да получава външни адреси, за да бъде достъпен отвън, или може да бъде вашият вътрешен балансьор на натоварването;
- Групи за сигурност
— контрол на достъпа до балансьора. По същество това е защитна стена от високо ниво.
- Подмрежи
— подмрежи във вашия VPC (и, съответно, зона на достъпност). Подмрежите се посочват по време на създаването. Ако VPC са ограничени по региони, тогава подмрежите са ограничени от зони на достъпност. Когато създавате Load Balancer, по-добре е да го създадете в поне две подмрежи (помага, ако възникнат проблеми с една зона на достъпност);
- Слушатели
— вашите протоколи за балансиране. Както споменахме по-рано, за Classic Load Balancer може да бъде HTTP, HTTPS, TCP и SSL, за Network Load Balancer - TCP, UDP и TLS, за Application Load Balancer - HTTP и HTTPS.
Пример за класически балансьор на натоварването:
Но в Application Load Balancer виждаме малко по-различен интерфейс и като цяло различна логика:
Компоненти на Load Balancer v2 (ALB и NLB)
Сега нека разгледаме по-отблизо версия 2 балансьори Application Load Balancer и Network Load Balancer. Тези балансьори имат свои собствени характеристики на компонентите. Например се появи такава концепция като целеви групи - екземпляри (и функции). Благодарение на този компонент имаме възможност да посочим към коя от целевите групи искаме да насочим трафика.
С прости думи, в целевите групи ние определяме случаите, където ще дойде трафикът. Ако в същия Classic Load Balancer просто незабавно свържете интензитета към балансира, тогава в Application Load Balancer първо:
- създаване на Load Balancer;
- създайте целева група;
- директно чрез необходимите портове или правила за балансиране на натоварването към необходимите целеви групи;
- в Целеви групи задавате инстанции.
Тази логика на работа може да изглежда по-сложна, но всъщност е по-удобна.
Следващият компонент е Правила за слушане (правила за маршрутизация). Това се отнася само за Application Load Balancer. Ако в Network Load Balancer просто създадете Listener и той изпраща трафик към конкретна целева група, тогава в Application Load Balancer всичко .
Сега нека кажем няколко думи за следващия компонент - Еластичен IP (статични адреси за NLB). Ако правилата за маршрутизиране на правилата на слушателя засягат само балансиращото натоварване на приложението, тогава еластичният IP засяга само балансиращия натоварването на мрежата.
Нека създадем балансьор на мрежовото натоварване:
И точно по време на процеса на създаване ще видим, че ни е дадена възможност да изберем Elastic IP:
Еластичният IP предоставя един IP адрес, който може да бъде свързан с различни екземпляри на EC2 във времето. Ако екземпляр на EC2 има еластичен IP адрес и този екземпляр е прекратен или спрян, можете незабавно да свържете нов екземпляр на EC2 с еластичен IP адрес. Вашето текущо приложение обаче няма да спре да работи, тъй като приложенията все още виждат същия IP адрес, дори ако истинският EC2 се е променил.
тук е по темата защо е необходим Elastic IP. Вижте, виждаме 3 IP адреса, но те няма да останат тук завинаги:
Amazon ги променя с течение на времето, може би на всеки 60 секунди (но на практика, разбира се, по-рядко). Това означава, че IP адресите могат да се променят. А в случая на Network Load Balancer можете просто да свържете IP адрес и да го посочите във вашите правила, политики и т.н.
Направете изводи
ELB осигурява автоматично разпределение на входящия трафик между множество цели (контейнери, инстанции на Amazon EC2, IP адреси и функции Lambda). ELB е в състояние да разпределя трафик с различни натоварвания както в рамките на една зона на достъпност, така и в множество зони на достъпност. Потребителят може да избира от три типа балансьори, които осигуряват висока наличност, автоматично мащабиране и добра защита. Всичко това е важно, за да осигурите устойчивост на грешки на вашите приложения.
Основните предимства:
- висока наличност. Споразумението за услугата предполага 99,99% наличност за балансиращото натоварване. Например множество зони на достъпност гарантират, че трафикът се обработва само от здрави обекти. Всъщност можете да балансирате натоварването в целия регион, пренасочвайки трафика към здрави цели в различни зони на достъпност;
- безопасност. ELB работи с Amazon VPC, като предоставя различни възможности за сигурност - интегрирано управление на сертификати, удостоверяване на потребителя и SSL/TLS декриптиране. Всичко заедно осигурява централизирано и гъвкаво управление на TLS настройките;
- еластичност. ELB може да се справи с внезапни промени в мрежовия трафик. И дълбоката интеграция с Auto Scaling дава на приложението достатъчно ресурси, ако натоварването се промени, без да се изисква ръчна намеса;
- гъвкавост. Можете да използвате IP адреси, за да насочвате заявки към целите на вашите приложения. Това осигурява гъвкавост при виртуализиране на целеви приложения, като по този начин дава възможност за хостване на множество приложения на един екземпляр. Тъй като приложенията могат да използват един мрежов порт и имат отделни групи за сигурност, комуникацията между приложенията е опростена, когато имаме, да речем, базирана на микроуслуги архитектура;
- мониторинг и одит. Можете да наблюдавате приложенията в реално време с помощта на функциите на Amazon CloudWatch. Говорим за метрики, логове, проследяване на заявки. С прости думи, вие ще можете да идентифицирате проблемите и да определите пречките в производителността доста точно;
- хибридно балансиране на натоварването. Възможността за балансиране на натоварването между локалните ресурси и AWS с помощта на един и същ балансьор на натоварването улеснява мигрирането или разширяването на локалните приложения към облака. Обработката на грешки също е опростена с помощта на облака.
Ако се интересувате от подробности, ето още няколко полезни връзки от официалния уебсайт на Amazon:
- .
Източник: www.habr.com