Մի քանի Google Cloud նախագիծ, մեկ հիբրիդային VPN? Նախ որոշեք
Համօգտագործվող VPC-ն, փիրինգը և կապակցության կենտրոնը պատասխանում են սեփականության տարբեր հարցերի։ Ընտրեք ցանցի սահմանը նախքան յուրաքանչյուր նախագծի համար մեկ VPN տեղակայելը։
Երբ մի քանի Google Cloud նախագծեր հիբրիդային հասանելիության կարիք ունեն, բնազդը յուրաքանչյուր նախագծի համար մեկ VPN-ն է, և դա գրեթե միշտ սխալ ձևն է։ Նախագծի սեփականությունը և փաթեթների երթուղավորումը կապված, բայց տարբեր հարցեր են, և օգտակար ճարտարապետությունը պահպանում է ձեզ անհրաժեշտ վարչական սահմանները՝ միաժամանակ նախատեսված նախածանցերին մեկ մտածված ուղի տալով դեպի գրասենյակ կամ տվյալների կենտրոն։ Այս ստուգումները որոշում են, թե իրականում որ ցանցային մոդելն եք ուզում, այն հերթականությամբ, որը խուսափում է վերամշակումից։ Դրանցից յուրաքանչյուրը կարող է վաղ ավարտել քննարկումը, և դա է իմաստը։
Նախագծի սահմանը ինքնաբերաբար չի պահանջում իր սեփական թունելը։
Ստուգեք՝ արդյոք համօգտագործվող օբյեկտը ցանցն է
Սկսեք սեփականության, ոչ թե կապակցության մասին հարցով․ կարո՞ղ է ցանցի կենտրոնական սեփականությունը աջակցել այս աշխատանքային բեռերին։ Եթե պատասխանը այո է և կազմակերպությունն ունի համապատասխան կոնֆիգուրացիա, հոսթ նախագիծը տիրապետում է VPC-ին, ենթացանցերին և կապակցությանը, մինչդեռ ծառայության նախագծերը տիրապետում են իրենց հավելվածային ռեսուրսներին։ Այդ համօգտագործվող ցանցում մեկ Cloud VPN կապը կարող է այնուհետև սպասարկել նախատեսված աշխատանքային բեռի նախածանցերը, ենթակա լինելով երթուղավորման և անվտանգության քաղաքականությանը ։
Եղեք ճշգրիտ այն հարցում, թե ինչ է անում միավորումը։ Ծառայության նախագիծ կցելը չի միաձուլում նրա գոյություն ունեցող անկախ VPC-ն հոսթ ցանցի հետ և չի տեղափոխում յուրաքանչյուր ռեսուրս ինքնաբերաբար։ Աշխատանքային բեռի կցումը, թույլտվությունները, հասցեային տարածությունը և DNS-ը ճարտարապետության մասեր են, ոչ թե կարգավորման հետևանքներ։ Կարդացեք միավորումը սկզբում որպես թույլտվության փոփոխություն, ապա որպես երթուղավորման փոփոխություն, քանի որ թիմերը սովորաբար տարբերությունը բացահայտում են անցման ընթացքում։
Եթե կենտրոնական սեփականությունն անընդունելի է ներգրավված թիմերի համար, կանգ առեք այստեղ և մնացածը դիտարկեք որպես փիրինգ կամ կենտրոնի ձևավորում։ Shared VPC-ն անկախ ցանցային կյանքի ցիկլեր ունեցող խմբի վրա պարտադրելը ստեղծում է տեխնիկական անունով քաղաքական խնդիր։
Ստուգեք՝ արդյոք անկախ VPC-ները կարող են անկախ մնալ
Փիրինգը պահպանում է առանձին VPC-ներ, և հենց դրա համար է գրավում այն թիմերին, ովքեր ուզում են իրենց սեփական հասցեային պլանները և իրենց սեփական փոփոխությունների վերահսկումը։ Խորտակն այն է, որ փիրինգը տրանզիտիվ չէ․ A-ից-B և B-ից-C փիրինգը ինքնին չի ստեղծում A-ից-C երթուղավորում B-ի միջով։ Եթե երեք նախագիծ պետք է հասնեն մեկ հիբրիդային նպատակակետի, ձեզ անհրաժեշտ է մտածված փոխանակման պլան, այլ ոչ թե փիրինգների շղթա։
Հիբրիդային հասանելիության կիսումը նույնպես կախված է փաստաթղթավորված հատուկ երթուղիների փոխանակումից և նախատեսված Cloud Router հայտարարություններից։ Փիրինգի ակտիվ կարգավիճակը ապացուցում է, որ փիրինգը գոյություն ունի, ոչ թե որ կողմերից յուրաքանչյուրի համար կարևոր նախածանցերը երբևէ արտահանվել են։ Ստուգեք արտահանված միջակայքերը փիրի երկու կողմերում՝ արտահանումը կատարող կոնֆիգուրացիայում, և համեմատեք դրանք այն հասցեների հետ, որոնք ձեր աշխատանքային բեռերը փաստացի օգտագործում են։ Այնտեղ անհամապատասխանությունը ամենատարածված պատճառն է, թե ինչու փիրինգը առողջ է թվում, մինչ նախածանցը մնում է անհասանելի։
Գրեք հասցեային պլանը նախքան ամեն ինչ։ Չհատվող միջակայքերը, դեպի յուրաքանչյուր նախատեսված նպատակակետ տանող երթուղիները և վերադարձի հայտարարությունները երեք այն արտեֆակտներն են, որոնց վրա այս մոդելը ապրում կամ մահանում է։
Ստուգեք՝ արդյոք կենտրոնի մոդելը համապատասխանում է տոպոլոգիային
Ավելի մեծ կամ այլ կերպ սեգմենտավորված ձևավորման համար Google-ի Network Connectivity Center ակնարկը նկարագրում է կենտրոնի և ճառագայթի մոդելները։ Կարդացեք այն ընթացիկ թողարկման աջակցության համար, ոչ թե այն բանի համար, ինչ ենթադրում է դիագրամը․ VPC-ի և հիբրիդային որ համակցություններ, երթուղիների որ ընտանիքներ և ինչ քաղաքականություն է թույլատրում յուրաքանչյուր ճառագայթի տեսակ։
Ստուգեք հասցեների ընտանիքը բացահայտ։ Ուղեցույցների մեծ մասում, ներառյալ այս մեկը, պլանավորման օրինակները վերաբերում են IPv4-ին, և մի ճառագայթի տեսակի համար գոյություն ունեցող գործառույթը ինքնաբերաբար չի կիրառվում անփոփոխ մյուսի վրա։ Եթե ձեր միջավայրը կրկնակի կույտ ունի, այդ հարցը պատկանում է մոդելի ընտրությանը, ոչ թե ավելի ուշ միգրացիային։
Ստորև բերված աղյուսակը երեք մոդելների ամփոփումն է և այն հարցը, որը որոշում է յուրաքանչյուրը։
| Model | Network relationship | Planning question |
|---|---|---|
| Shared VPC | Service projects use subnets of a host project's VPC | Can central network ownership support these workloads? |
| VPC Network Peering | Independent VPCs exchange supported routes through explicit peers | Are direct peer and hybrid route exchanges sufficient? |
| Network Connectivity Center | Supported VPC and hybrid spokes join a managed hub | Does the required topology fit current routing and policy? |
Ստուգեք, թե ինչ չի տալիս երթուղավորումը
Երթուղիների փոխանակումը վստահության համապարփակ տրամադրում չէ։ DNS-ի լուծումը, ֆայրվոլի թույլտվությունը և հավելվածի լիազորումը մնում են իրենց պատասխանատվությունները, և դրանցից յուրաքանչյուրը կազմակերպությունների մեծ մասում կարգավորում է տարբեր սեփականատեր։ Նախագծումը, որը ենթադրում է, թե հասանելիությունը նշանակում է լիազորում, կանցնի իր կապակցության թեստը և կձախողվի անվտանգության վերանայումում։
Հաստատեք նաև DNS-ի պատմությունը յուրաքանչյուր մոդելի համար, քանի որ գոտու և փոխանցման կարգավորումները տարբերվում են համօգտագործվող ցանցի և փիր ցանցերի միջև։ Մեկ նախագծում լուծվող մասնավոր անունները չեն հետևում երթուղուն մեկ այլ նախագիծ։
Գրանցեք որոշումը և դրա սեփականատիրոջը
Կենտրոնացրեք այնտեղ, որտեղ կազմակերպությունը ցանկանում է համօգտագործվող ցանցի սեփականատեր․ պահեք առանձին VPC-ներ այնտեղ, որտեղ դա պահանջում է կյանքի ցիկլը կամ քաղաքականությունը։ Այնուհետև ընտրեք աջակցվող կապակցության հարաբերություն և գրեք, թե որն եք ընտրել, ով է տիրապետում համօգտագործվող ցանցին և ինչ կարող է հայտարարել յուրաքանչյուր նախագիծ։
Նախագծերը հաշվելը և յուրաքանչյուրի համար մեկ VPN գնելը չի փոխարինում այդ սեփականության որոշմանը։ Դա նույն որոշումն է՝ ավելի ուշ կայացված նրա կողմից, ով ժառանգում է հաշիվը և երթուղավորման աղյուսակը։