VMware NSX փոքրիկների համար: Մաս 5. Բեռների հավասարակշռության կարգավորում

Առաջին մաս. ներածական
Մաս երկրորդ. Firewall-ի և NAT-ի կանոնների կարգավորում
Մաս երրորդ. DHCP-ի կարգավորում
Մաս չորրորդ. Երթուղիների կարգավորում

Անցյալ անգամ մենք խոսեցինք NSX Edge-ի հնարավորությունների մասին՝ ստատիկ և դինամիկ երթուղղման առումով, իսկ այսօր կզբաղվենք բեռների հավասարակշռողով։
Նախքան տեղադրումը սկսելը, ես կցանկանայի համառոտ հիշեցնել հավասարակշռման հիմնական տեսակների մասին:

Теория

Այսօրվա բոլոր բեռների հավասարակշռման լուծումներն առավել հաճախ բաժանվում են երկու կատեգորիայի՝ հավասարակշռում մոդելի չորրորդ (տրանսպորտ) և յոթերորդ (կիրառական) մակարդակներում։ ԿԱՄ ԵԹԵ. OSI մոդելը լավագույն հղման կետը չէ հավասարակշռման մեթոդները նկարագրելիս: Օրինակ, եթե L4 հավասարակշռողն աջակցում է նաև TLS-ի դադարեցմանը, արդյո՞ք այն դառնում է L7 հավասարակշռող: Բայց դա այն է, ինչ կա:

• Հավասարակշռող L4 ամենից հաճախ դա միջին վստահված անձ է, որը կանգնած է հաճախորդի և հասանելի backend-ների մի շարքի միջև, որը դադարեցնում է TCP կապերը (այսինքն, ինքնուրույն արձագանքում է SYN-ին), ընտրում է հետին պլան և սկսում է նոր TCP նիստ իր ուղղությամբ՝ ինքնուրույն ուղարկելով SYN: Այս տեսակը հիմնականներից մեկն է, հնարավոր են այլ տարբերակներ։
• Հավասարակշռող L7 բաշխում է երթևեկությունը հասանելի հետին մասերում «ավելի բարդ», քան դա անում է L4 հավասարակշռողը: Այն կարող է որոշել, թե որ backend-ն ընտրել՝ հիմնվելով, օրինակ, HTTP հաղորդագրության բովանդակության վրա (URL, cookie և այլն):

Անկախ տեսակից, հավասարակշռիչը կարող է ապահովել հետևյալ գործառույթները.

• Ծառայությունների հայտնաբերումը հասանելի backend-ների հավաքածուի որոշման գործընթացն է (Static, DNS, Consul, Etcd և այլն):
• Հայտնաբերված հետնամասերի ֆունկցիոնալության ստուգում (հետին պլանի ակտիվ «պինգ»՝ օգտագործելով HTTP հարցում, TCP կապերում խնդիրների պասիվ հայտնաբերում, պատասխաններում մի քանի 503 HTTP կոդերի առկայություն և այլն):
• Հավասարակշռումն ինքնին (կլոր ռոբին, պատահական ընտրություն, աղբյուրի IP հեշ, URI):
• TLS դադարեցում և վկայականի ստուգում:
• Անվտանգության հետ կապված տարբերակներ (նույնականացում, DoS հարձակման կանխարգելում, արագության սահմանափակում) և շատ ավելին:

NSX Edge-ն առաջարկում է աջակցություն երկու բեռի հավասարակշռման ռեժիմների համար.

Պրոքսի ռեժիմ, կամ միակողմանի. Այս ռեժիմում NSX Edge-ն օգտագործում է իր IP հասցեն որպես սկզբնաղբյուրի հասցե, երբ հարցում է ուղարկում հետնամասերից մեկին: Այսպիսով, հավասարակշռողը միաժամանակ կատարում է Source և Destination NAT գործառույթները: Backend-ը տեսնում է ողջ տրաֆիկը, ինչպես ուղարկվել է հավասարակշռողից և անմիջապես արձագանքում է դրան: Նման սխեմայի դեպքում հավասարակշռողը պետք է լինի ներքին սերվերների հետ ցանցի նույն հատվածում:

Ահա թե ինչպես է այն ընթանում.
1. Օգտագործողը հարցում է ուղարկում Edge-ում կազմաձևված VIP հասցեին (հավասարակշռող հասցեին):
2. Edge-ն ընտրում է հետնամասերից մեկը և կատարում նպատակակետ NAT՝ փոխարինելով VIP հասցեն ընտրված հետնամասի հասցեով:
3. Edge-ը կատարում է աղբյուրի NAT-ը՝ փոխարինելով հարցումն ուղարկած օգտատիրոջ հասցեն իր հասցեով։
4. Փաթեթն ուղարկվում է ընտրված հետին պլան:
5. Backend-ը չի արձագանքում ուղղակիորեն օգտագործողին, այլ Edge-ին, քանի որ օգտագործողի սկզբնական հասցեն փոխվել է հավասարակշռողի հասցեի:
6. Edge-ը սերվերի պատասխանը փոխանցում է օգտագործողին:
Դիագրամը՝ ստորև։


Թափանցիկ կամ ներկառուցված ռեժիմ: Այս սցենարում հավասարակշռողն ունի ինտերֆեյսներ ներքին և արտաքին ցանցերում: Միևնույն ժամանակ, արտաքինից ուղղակի մուտք դեպի ներքին ցանց չկա։ Ներկառուցված բեռի հավասարակշռիչը գործում է որպես NAT դարպաս ներքին ցանցի վիրտուալ մեքենաների համար:

Մեխանիզմը հետևյալն է.
1. Օգտագործողը հարցում է ուղարկում Edge-ում կազմաձևված VIP հասցեին (հավասարակշռող հասցեին):
2. Edge-ն ընտրում է հետնամասերից մեկը և կատարում նպատակակետ NAT՝ փոխարինելով VIP հասցեն ընտրված հետնամասի հասցեով:
3. Փաթեթն ուղարկվում է ընտրված հետին պլան:
4. Backend-ը ստանում է հարցում օգտվողի սկզբնական հասցեով (աղբյուր NAT-ը չի կատարվել) և ուղղակիորեն պատասխանում է դրան:
5. Երթևեկությունը կրկին ընդունվում է բեռի հավասարակշռողի կողմից, քանի որ ներկառուցված սխեմայում այն ​​սովորաբար գործում է որպես սերվերային ֆերմայի լռելյայն դարպաս:
6. Edge-ը կատարում է աղբյուրի NAT-ը՝ օգտվողին տրաֆիկ ուղարկելու համար՝ օգտագործելով իր VIP-ը որպես աղբյուրի IP հասցե:
Դիագրամը՝ ստորև։

Պրակտիկա

Իմ թեստային նստարանն ունի 3 սերվեր, որն աշխատում է Apache-ով, որը կազմաձևված է աշխատելու HTTPS-ով: Edge-ը կկատարի HTTPS հարցումների շրջանաձև հավասարակշռում՝ յուրաքանչյուր նոր հարցում փոխանցելով նոր սերվերին:
Եկեք սկսենք.

SSL վկայագրի ստեղծում, որը կօգտագործվի NSX Edge-ի կողմից
Դուք կարող եք ներմուծել վավեր CA վկայական կամ օգտագործել ինքնաստորագրված: Այս թեստի համար ես կօգտագործեմ ինքնաստորագրված:

1. vCloud Director ինտերֆեյսում անցեք Edge ծառայությունների կարգավորումներ:
   
2. Գնացեք «Վկայականներ» ներդիր: Գործողությունների ցանկից ընտրեք ավելացնել նոր ԿՍՊ:
   
3. Լրացրեք պահանջվող դաշտերը և սեղմեք Պահել:
   
4. Ընտրեք նորաստեղծ ԿՍՊ-ն և ընտրեք ինքնաստորագրման ԿՍՊ տարբերակը։
   
5. Ընտրեք վկայագրի վավերականության ժամկետը և սեղմեք Պահել
   
6. Ինքն ստորագրված վկայականը հայտնվում է առկաների ցանկում:
   

Հավելվածի պրոֆիլի կարգավորում
Հավելվածի պրոֆիլները հնարավորություն են տալիս ավելի ամբողջական վերահսկել ցանցային երթևեկությունը և դարձնում այն ​​կառավարելը պարզ և արդյունավետ: Դրանք կարող են օգտագործվել երթևեկության հատուկ տեսակների համար վարքագիծ սահմանելու համար:

1. Գնացեք «Load Balancer» ներդիր և միացրեք հավասարակշռիչը: Acceleration-ի միացված տարբերակը այստեղ թույլ է տալիս հավասարակշռողին L4-ի փոխարեն օգտագործել L7-ի ավելի արագ հավասարակշռում:
   
2. Գնացեք հավելվածի պրոֆիլի ներդիր՝ հավելվածի պրոֆիլը սահմանելու համար: Սեղմեք +:
   
3. Սահմանեք պրոֆիլի անունը և ընտրեք տրաֆիկի տեսակը, որի համար կկիրառվի պրոֆիլը: Թույլ տվեք բացատրել որոշ պարամետրեր.
   Համառություն – պահում և հետևում է սեսիայի տվյալները, օրինակ՝ լողավազանի կոնկրետ որ սերվերն է սպասարկում օգտվողի հարցումը: Սա երաշխավորում է, որ օգտատերերի հարցումները ուղղորդվում են նույն լողավազանի անդամին սեսիայի կամ հետագա նիստերի ողջ ընթացքում:
   Միացնել SSL անցումը – Երբ ընտրված է այս տարբերակը, NSX Edge-ը դադարեցնում է SSL-ի դադարեցումը: Փոխարենը, դադարեցումը տեղի է ունենում անմիջապես այն սերվերների վրա, որոնք հավասարակշռվում են:
   Տեղադրեք X-Forwarded-For HTTP վերնագիրը – թույլ է տալիս որոշել հաճախորդի աղբյուրի IP հասցեն, որը միանում է վեբ սերվերին բեռի հավասարակշռիչի միջոցով:
   Միացնել Pool Side SSL-ը – թույլ է տալիս նշել, որ ընտրված լողավազանը բաղկացած է HTTPS սերվերներից:
   
4. Քանի որ ես հավասարակշռելու եմ HTTPS տրաֆիկը, ես պետք է միացնեմ Pool Side SSL-ը և ընտրեմ նախկինում ստեղծված վկայագիրը Վիրտուալ սերվերի վկայագրեր -> ծառայության վկայական ներդիրում:
   
5. Նմանապես Pool Certificates -> Service Certificate:
   

Մենք ստեղծում ենք սերվերների լողավազան, որի երթևեկը կլինի հավասարակշռված Pools

1. Գնացեք «Լողավազաններ» ներդիր: Սեղմեք +:
   
2. Մենք սահմանում ենք լողավազանի անվանումը, ընտրում ենք ալգորիթմը (ես կօգտագործեմ կլոր ռոբին) և մոնիտորինգի տեսակը առողջության ստուգման հետևի համար: Թափանցիկ տարբերակը ցույց է տալիս, թե արդյոք հաճախորդների սկզբնական աղբյուրի IP-ները տեսանելի են ներքին սերվերների համար:
   • Եթե ​​տարբերակն անջատված է, ներքին սերվերների համար տրաֆիկը գալիս է հավասարակշռողի աղբյուրի IP-ից:
   • Եթե ​​տարբերակը միացված է, ներքին սերվերները տեսնում են հաճախորդների սկզբնաղբյուր IP-ն: Այս կազմաձևում NSX Edge-ը պետք է գործի որպես լռելյայն դարպաս՝ ապահովելու, որ վերադարձված փաթեթներն անցնեն NSX Edge-ով:

   NSX-ն աջակցում է հետևյալ հավասարակշռման ալգորիթմներին.

   • IP_HASH – սերվերի ընտրություն՝ հիմնված յուրաքանչյուր փաթեթի աղբյուրի և նպատակակետի IP-ի համար հեշ ֆունկցիայի արդյունքների վրա:
   • LEASTCONN – մուտքային կապերի հավասարակշռում` կախված որոշակի սերվերի վրա արդեն հասանելի քանակից: Նոր կապերը կուղղվեն ամենաքիչ կապեր ունեցող սերվերին:
   • ROUND_ROBIN – յուրաքանչյուր սերվերին հերթով ուղարկվում են նոր կապեր՝ իրեն հատկացված քաշին համապատասխան:
   • URI – URI-ի ձախ մասը (նախքան հարցականը) հեշավորված է և բաժանվում է լողավազանի սերվերների ընդհանուր քաշի վրա: Արդյունքը ցույց է տալիս, թե որ սերվերն է ստանում հարցումը, ապահովելով, որ հարցումը միշտ ուղղորդվում է նույն սերվերին, քանի դեռ բոլոր սերվերները հասանելի են:
   • HTTPHEADER – Հավասարակշռում` հիմնված կոնկրետ HTTP վերնագրի վրա, որը կարող է նշվել որպես պարամետր: Եթե ​​վերնագիրը բացակայում է կամ չունի որևէ արժեք, կիրառվում է ROUND_ROBIN ալգորիթմը:
   • URL – Յուրաքանչյուր HTTP GET հարցում որոնում է URL պարամետրը, որը նշված է որպես փաստարկ: Եթե ​​պարամետրին հաջորդում է հավասար նշան և արժեք, ապա արժեքը հաշված է և բաժանվում է գործող սերվերների ընդհանուր քաշի վրա: Արդյունքը ցույց է տալիս, թե որ սերվերն է ստանում հարցումը: Այս գործընթացն օգտագործվում է հարցումներում օգտվողների ID-ներին հետևելու և ապահովելու համար, որ նույն օգտվողի ID-ն միշտ ուղարկվի նույն սերվերին, քանի դեռ բոլոր սերվերները հասանելի են:

   

3. Անդամների բլոկում սեղմեք +՝ լողավազանում սերվերներ ավելացնելու համար:
   
   
   Այստեղ դուք պետք է նշեք.
   • սերվերի անունը;
   • Սերվերի IP հասցե;
   • այն նավահանգիստը, որի վրա սերվերը կստանա տրաֆիկ.
   • նավահանգիստ առողջության ստուգման համար (Monitor healthcheck);
   • քաշ – օգտագործելով այս պարամետրը, դուք կարող եք կարգավորել լողավազանի որոշակի անդամի համար ստացված տրաֆիկի համամասնական քանակը.
   • Max Connections – սերվերի հետ կապերի առավելագույն քանակը;
   • Min Connections – միացումների նվազագույն քանակը, որը սերվերը պետք է մշակի նախքան տրաֆիկը փոխանցվի հաջորդ խմբի անդամին:

   
   
   Ահա թե ինչ տեսք ունի երեք սերվերների վերջնական լողավազանը.
   

Վիրտուալ սերվերի ավելացում

1. Գնացեք «Վիրտուալ սերվերներ» ներդիր: Սեղմեք +:
   
2. Մենք ակտիվացնում ենք վիրտուալ սերվերը՝ օգտագործելով Enable Virtual Server:
   Մենք տալիս ենք անունը, ընտրում ենք նախկինում ստեղծված Application Profile, Pool և նշում ենք IP հասցեն, որի վրա Վիրտուալ Սերվերը կստանա հարցումներ դրսից: Մենք նշում ենք HTTPS արձանագրությունը և 443 պորտը:
   Ընտրովի պարամետրեր այստեղ.
   Միացման սահմանաչափ – միաժամանակյա միացումների առավելագույն քանակը, որը կարող է մշակել վիրտուալ սերվերը.
   Միացման արագության սահմանաչափ (CPS) – նոր մուտքային հարցումների առավելագույն քանակը վայրկյանում:
   

Սա ավարտում է հավասարակշռողի կազմաձևումը, կարող եք ստուգել դրա ֆունկցիոնալությունը: Սերվերներն ունեն պարզ կոնֆիգուրացիա, որը թույլ է տալիս հասկանալ, թե լողավազանի որ սերվերն է մշակել հարցումը: Կարգավորման ընթացքում մենք ընտրեցինք Round Robin հավասարակշռման ալգորիթմը, և յուրաքանչյուր սերվերի համար Weight պարամետրը հավասար է մեկին, ուստի յուրաքանչյուր հաջորդ հարցում կմշակվի լողավազանի հաջորդ սերվերի կողմից:
Մենք բրաուզերում մուտքագրում ենք հավասարակշռողի արտաքին հասցեն և տեսնում ենք.


Էջը թարմացնելուց հետո հարցումը կմշակվի հետևյալ սերվերի կողմից.


Եվ կրկին՝ լողավազանից երրորդ սերվերը ստուգելու համար.


Ստուգելիս կարող եք տեսնել, որ Edge-ը մեզ ուղարկած վկայականը նույնն է, ինչ մենք ստեղծել ենք հենց սկզբում:

Հավասարակշռողի կարգավիճակի ստուգում Edge gateway վահանակից: Դա անելու համար մուտքագրեք ցույց տալ ծառայության loadbalancer լողավազան.


Ծառայության մոնիտորը կարգավորվում է լողավազանում սերվերների կարգավիճակը ստուգելու համար
Օգտագործելով Service Monitor-ը, մենք կարող ենք վերահսկել սերվերների կարգավիճակը backend լողավազանում: Եթե ​​հարցման պատասխանը սպասվածի նման չէ, ապա սերվերը կարող է դուրս հանվել լողավազանից, որպեսզի այն չստանա նոր հարցումներ:
Լռելյայնորեն կազմաձևված են ստուգման երեք եղանակ.

• TCP մոնիտոր,
• HTTP մոնիտոր,
• HTTPS մոնիտոր.

Եկեք ստեղծենք նորը:

1. Գնացեք ծառայության մոնիտորինգի ներդիր, սեղմեք +:
   
2. Ընտրեք.
   • նոր մեթոդի անվանումը;
   • այն ընդմիջումը, որով կուղարկվեն հարցումները,
   • պատասխանի սպասման ժամանակի ընդմիջում,
   • մոնիտորինգի տեսակը – HTTPS հարցում՝ օգտագործելով GET մեթոդը, ակնկալվող կարգավիճակի կոդը – 200(OK) և հարցման URL:
3. Սա ավարտում է նոր ծառայության մոնիտորի կարգավորումը, այժմ մենք կարող ենք օգտագործել այն լողավազան ստեղծելիս:
   

Դիմումի կանոնների կարգավորում

Կիրառման կանոնները որոշակի գործարկիչների հիման վրա տրաֆիկի մանիպուլյացիայի միջոց են: Այս գործիքի միջոցով մենք կարող ենք ստեղծել ծանրաբեռնվածության հավասարակշռման առաջադեմ կանոններ, որոնք հնարավոր չէ հնարավոր լինել Application-ի պրոֆիլների կամ Edge Gateway-ում հասանելի այլ ծառայությունների միջոցով:

1. Կանոն ստեղծելու համար անցեք հավասարակշռողի կիրառման կանոնների ներդիր:
   
2. Ընտրեք անուն, սցենար, որը կօգտագործի կանոնը և սեղմեք Պահել:
   
3. Կանոնը ստեղծելուց հետո մենք պետք է խմբագրենք արդեն կազմաձևված վիրտուալ սերվերը:
   
4. Ընդլայնված ներդիրում ավելացրեք մեր ստեղծած կանոնը:
   

Վերևի օրինակում մենք միացրել ենք tlsv1 աջակցությունը:

Եվս մի քանի օրինակ.

Վերահղեք երթևեկությունը մեկ այլ լողավազան:
Այս սկրիպտով մենք կարող ենք երթևեկությունը վերահղել դեպի մեկ այլ հավասարակշռող լողավազան, եթե հիմնական լողավազանն անջատված է: Որպեսզի կանոնը գործի, մի քանի լողավազաններ պետք է կազմաձևվեն հավասարակշռողի վրա, և հիմնական լողավազանի բոլոր անդամները պետք է լինեն ցած վիճակում: Դուք պետք է նշեք լողավազանի անունը, ոչ թե դրա ID-ն:

acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME


Վերահղեք տրաֆիկը դեպի արտաքին ռեսուրս:
Այստեղ մենք երթևեկությունը վերահղում ենք դեպի արտաքին կայք, եթե հիմնական լողավազանի բոլոր անդամները չեն աշխատում:

acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down

Նույնիսկ ավելի շատ օրինակներ այստեղ.

Ինձ համար այսքանն է հավասարակշռողի մասին: Եթե ​​հարցեր ունեք, հարցրեք, ես պատրաստ եմ պատասխանել։

Source: www.habr.com