એકથી વધુ Google Cloud પ્રોજેક્ટ, એક હાઇબ્રિડ VPN? પહેલા નિર્ણય લો
શેર કરેલ VPC, પીઅરિંગ અને એક કનેક્ટિવિટી હબ વિવિધ માલિકીના પ્રશ્નોના જવાબ આપે છે. દરેક પ્રોજેક્ટ માટે એક VPN તૈનાત કરતા પહેલા નેટવર્કની સીમા પસંદ કરો.
જ્યારે ઘણા Google Cloud પ્રોજેક્ટને હાઇબ્રિડ ઍક્સેસની જરૂર હોય, ત્યારે સહજ વૃત્તિ દરેક પ્રોજેક્ટ માટે એક VPN છે, અને તે લગભગ હંમેશા ખોટો આકાર છે. પ્રોજેક્ટની માલિકી અને પેકેટ રૂટિંગ સંબંધિત પણ જુદા મુદ્દા છે, અને ઉપયોગી આર્કિટેક્ચર તમને જરૂરી વહીવટી સીમાઓ રાખે છે જ્યારે ઇચ્છિત પ્રીફિક્સને ઓફિસ કે ડેટા સેન્ટર સુધી એક વિચારપૂર્વકનો માર્ગ આપે છે. આ તપાસો નક્કી કરે છે કે તમે ખરેખર કયું નેટવર્ક મોડેલ ઇચ્છો છો, એ ક્રમમાં જે ફરી કામ ટાળે છે. દરેક તપાસ ચર્ચા વહેલી પૂરી કરી શકે છે, અને તે જ મુખ્ય મુદ્દો છે.
પ્રોજેક્ટની સીમા આપમેળે તેની પોતાની ટનલની માંગ કરતી નથી.
તપાસો કે શેર કરેલ વસ્તુ નેટવર્ક છે કે નહીં
માલિકી વિશેના પ્રશ્નથી શરૂ કરો, કનેક્ટિવિટીથી નહીં: શું કેન્દ્રીય નેટવર્ક માલિકી આ વર્કલોડને ટેકો આપી શકે? જવાબ હા હોય અને સંસ્થા પાસે યોગ્ય ગોઠવણી હોય, તો હોસ્ટ પ્રોજેક્ટ VPC, સબનેટ અને કનેક્ટિવિટી ધરાવે છે, જ્યારે સેવા પ્રોજેક્ટ તેમના એપ્લિકેશન સંસાધનો ધરાવે છે. તે શેર કરેલ નેટવર્કમાં એક Cloud VPN કનેક્શન પછી ઇચ્છિત વર્કલોડ પ્રીફિક્સની સેવા કરી શકે છે, રૂટિંગ અને સુરક્ષા નીતિઓને આધીન .
સંલગ્નતા શું કરે છે તે અંગે સચોટ રહો. સેવા પ્રોજેક્ટ જોડવાથી તેનું હાલનું સ્વતંત્ર VPC હોસ્ટ નેટવર્કમાં ભળી જતું નથી, અને દરેક સંસાધન આપમેળે ખસતું નથી. વર્કલોડ જોડાણ, પરવાનગીઓ, સરનામાંની જગ્યા અને DNS બધા આર્કિટેક્ચરનો ભાગ છે, ગોઠવણીના પરિણામ નથી. સંલગ્નતાને પહેલા પરવાનગી પરિવર્તન અને પછી રૂટિંગ પરિવર્તન તરીકે વાંચો, કારણ કે ટીમો સામાન્ય રીતે સંક્રમણ દરમિયાન તફાવત શોધે છે.
જો કેન્દ્રીય માલિકી સંબંધિત ટીમો માટે સ્વીકાર્ય ન હોય, તો અહીં રોકાઈને બાકીનાને પીઅરિંગ કે હબ ડિઝાઇન તરીકે ગણો. સ્વતંત્ર નેટવર્ક જીવનચક્રની જરૂર હોય તેવા જૂથ પર Shared VPC લાદવાથી ટેકનિકલ નામ ધરાવતી રાજકીય સમસ્યા ઊભી થાય છે.
તપાસો કે સ્વતંત્ર VPC સ્વતંત્ર રહી શકે છે કે નહીં
પીઅરિંગ અલગ VPC જાળવી રાખે છે, અને તેથી જ તે એવી ટીમોને આકર્ષે છે જેમને પોતાની સરનામાં યોજના અને પોતાનું ફેરફાર નિયંત્રણ જોઈએ. મુશ્કેલી એ છે કે પીઅરિંગ ટ્રાન્ઝિટિવ નથી: A-થી-B અને B-થી-C પીઅરિંગ પોતાની રીતે B દ્વારા A-થી-C રૂટિંગ બનાવતું નથી. જો ત્રણ પ્રોજેક્ટને એક હાઇબ્રિડ ગંતવ્ય સુધી પહોંચવું હોય, તો તમને પીઅરિંગની સાંકળ નહીં, વિચારપૂર્વકની આદાનપ્રદાન યોજના જોઈએ.
હાઇબ્રિડ પહોંચવાળી ક્ષમતા વહેંચવી દસ્તાવેજીકૃત કસ્ટમ-રૂટ આદાનપ્રદાન અને ઇચ્છિત 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 ખરીદવું એ તે માલિકી નિર્ણયનો વિકલ્પ નથી. તે એ જ નિર્ણય છે, પછી લેવાયેલો, જે બિલ અને રૂટિંગ કોષ્ટકનો વારસો લે છે.