Բարեւ բոլորին! Դասընթացը մեկնարկում է այսօր , որի կապակցությամբ անցկացրինք համապատասխան թեմատիկ վեբինար՝ նվիրված ELB ստուգատեսին։ Մենք դիտարկեցինք հավասարակշռողների տեսակները և հավասարակշռողով ստեղծեցինք մի քանի EC2 օրինակներ: Մենք ուսումնասիրեցինք նաև օգտագործման այլ օրինակներ։
, Դու պետք է:
- հասկանալ, թե ինչ է AWS Load Balancing-ը.
- իմանալ առաձգական բեռի հավասարակշռող սարքերի տեսակները և դրա բաղադրիչները.
- օգտագործեք AWS ELB-ը ձեր պրակտիկայում:
Ինչու՞ պետք է ընդհանրապես իմանաք սա:
- օգտակար է, եթե նախատեսում եք հանձնել AWS սերտիֆիկացման քննություններ.
- սա սերվերների միջև բեռը բաշխելու պարզ միջոց է.
- Սա ձեր ծառայությանը (ALB) լամբդա ավելացնելու պարզ միջոց է:
Անցկացրեց բաց դաս , համակարգերի ինժեներ մարքեթինգային ընկերությունում՝ վեբ կայքերի մշակման և աջակցության համար:
Ներածություն
Ինչ է առաձգական բեռի հավասարակշռիչը, կարելի է տեսնել ստորև ներկայացված գծապատկերում, որը ցույց է տալիս պարզ օրինակ.
Load Balancer-ն ընդունում է հարցումները և տարածում դրանք տարբեր ատյաններում: Մենք ունենք մեկ առանձին օրինակ, կան Lambda ֆունկցիաներ և կա AutoScaling խումբ (սերվերների խումբ):
AWS ELB տեսակները
1. Դիտարկենք հիմնական տեսակները:
Դասական բեռի հավասարակշռող: AWS-ի առաջին հավասարակշռիչը, որն աշխատում է OSI 4 և 7 շերտերի վրա, աջակցվում են HTTP, HTTPS, TCP և SSL: Այն ապահովում է հիմնական բեռի հավասարակշռում Amazon EC2 բազմաթիվ օրինակներում և աշխատում է ինչպես հարցումների, այնպես էլ կապի մակարդակներում: Եկեք բացենք այն (ընդգծված մոխրագույնով).
Այս հավասարակշռիչը համարվում է հնացած, ուստի խորհուրդ է տրվում օգտագործել միայն որոշակի դեպքերում: Օրինակ՝ հավելվածների համար, որոնք ստեղծվել են EC2‑Classic ցանցում: Սկզբունքորեն, ոչ ոք մեզ չի խանգարում ստեղծել այն.
2. Ցանցի բեռի հավասարակշռող: Հարմար է մեծ ծանրաբեռնվածության համար, գործում է OSI շերտում 4 (կարելի է օգտագործել EKS-ում և ECS-ում), աջակցվում են TCP, UDP և TLS:
Network Load Balancer-ը ուղղորդում է երթևեկությունը դեպի թիրախներ Amazon VPC-ում և ի վիճակի է մշակել միլիոնավոր հարցումներ վայրկյանում ծայրահեղ ցածր ուշացումով: Բացի այդ, այն օպտիմիզացված է հանկարծակի և փոփոխվող բեռներով երթևեկության օրինաչափությունները կարգավորելու համար:
3. Application Load Balancer. Աշխատում է 7-րդ շերտում, ունի Lambda աջակցություն, աջակցում է վերնագրի և ուղու մակարդակի կանոններին, աջակցում է HTTP և HTTPS:
Ապահովում է հարցումների առաջադեմ երթուղում՝ կենտրոնացած ժամանակակից ճարտարապետության վրա կառուցված հավելվածների, ներառյալ միկրոծառայությունների և կոնտեյներների վրա: Ուղղում է երթևեկությունը դեպի Amazon VPC-ի թիրախները՝ հիմնվելով հարցման բովանդակության վրա:
Շատ օգտատերերի համար Application Load Balancer-ը դասական Load Balancer-ին փոխարինելու առաջին ընտրությունն էր, քանի որ TCP-ն այնքան էլ տարածված չէ, որքան HTTP-ն:
Եկեք այն էլ ստեղծենք, որի արդյունքում արդեն կունենանք երկու բեռի հավասարակշռող.
Բեռնվածության մնացորդի բաղադրիչներ
Ընդհանուր բեռնվածքի հաշվեկշռի բաղադրիչներ (ընդհանուր բոլոր հավասարակշռողների համար).
- Մուտք գործելու գրանցման քաղաքականություն
— ձեր ELB մուտքի մատյանները: Կարգավորումներ անելու համար կարող եք գնալ Նկարագրություն և ընտրել «Խմբագրել հատկանիշները» կոճակը.
Այնուհետև մենք նշում ենք S3Bucket - Amazon օբյեկտների պահեստավորում.
- Սխեմա
- ներքին կամ արտաքին հավասարակշռող: Հարցն այն է, թե արդյոք ձեր LoadBalancer-ը պետք է արտաքին հասցեներ ստանա, որպեսզի հասանելի լինի դրսից, թե՞ դա կարող է լինել ձեր ներքին բեռի հավասարակշռիչը.
- Անվտանգության խմբեր
- մուտքի վերահսկում հավասարակշռողին: Ըստ էության, սա բարձր մակարդակի firewall է:
- Ենթացանցեր
— ենթացանցեր ձեր 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;
- ստեղծել թիրախային խումբ;
- անհրաժեշտ նավահանգիստների կամ Load Balancer կանոնների միջոցով ուղղել պահանջվող թիրախային խմբերին.
- Թիրախային խմբերում դուք հանձնարարում եք օրինակներ:
Գործառնական այս տրամաբանությունը կարող է ավելի բարդ թվալ, բայց իրականում ավելի հարմար է։
Հաջորդ բաղադրիչն է Լսողի կանոններ (երթուղիների կանոններ): Սա վերաբերում է միայն Application Load Balancer-ին: Եթե Network Load Balancer-ում դուք պարզապես ստեղծում եք ունկնդիր, և այն ուղարկում է տրաֆիկ որոշակի թիրախային խումբ, ապա Application Load Balancer-ում ամեն ինչ .
Հիմա մի քանի խոսք ասենք հաջորդ բաղադրիչի մասին. Էլաստիկ IP (ստատիկ հասցեներ NLB-ի համար): Եթե ունկնդիրների կանոնների երթուղավորման կանոնները ազդում էին միայն Application Load Balancer-ի վրա, ապա Elastic IP-ն ազդեց միայն Network Load Balancer-ի վրա:
Եկեք ստեղծենք ցանցի բեռի հաշվեկշիռ.
Եվ հենց ստեղծման գործընթացում մենք կտեսնենք, որ մեզ հնարավորություն է տրվում ընտրել Elastic IP.
Elastic IP-ն ապահովում է մեկ IP հասցե, որը ժամանակի ընթացքում կարող է կապված լինել տարբեր EC2 դեպքերի հետ: Եթե EC2 օրինակն ունի Elastic IP հասցե, և այդ օրինակը դադարեցվել կամ դադարեցվել է, դուք կարող եք անմիջապես կապել նոր EC2 օրինակը Էլաստիկ IP հասցեի հետ: Այնուամենայնիվ, ձեր ընթացիկ հավելվածը չի դադարի աշխատել, քանի որ հավելվածները դեռ տեսնում են նույն IP հասցեն, նույնիսկ եթե իրական EC2-ը փոխվել է:
Այստեղ թեմայի շուրջ, թե ինչու է անհրաժեշտ Էլաստիկ 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-ի պաշտոնական կայքից.
- .
Source: www.habr.com