ExpressRoute વત્તા VPN: તમે કયા નિષ્ફળતા-ક્ષેત્રો આવરી લો છો?
બીજી IPsec ટનલ એક એન્ડપોઇન્ટ આવરે છે, તેની નીચેનું સર્કિટ નહીં. દરેક નિષ્ફળતા-ક્ષેત્રનું મ્યાપ કરો, પછી નક્કી કરો કે અનએન્ક્રિપ્ટેડ ફોલબેક માન્ય છે કે નહીં.
ExpressRoute ના ખાનગી પિયરિંગ પર ચાલતી IPsec ટનલ પહેલેથી અસ્તિત્વમાં હોય તેવા ટ્રાન્સપોર્ટમાં એન્ક્રિપ્શન ઉમેરે છે. બીજી ટનલ એન્ડપોઇન્ટની ઉપલબ્ધતા સુધારે છે, અને બંનેની નીચેના કેરિયર માર્ગ માટે તે કંઈ જ કરતી નથી. જ્યારે ડેશબોર્ડ બે લીલી ટનલ બતાવે અને ડિઝાઇન સમીક્ષા બીજો પ્રશ્ન પૂછે ત્યારે આ તફાવત ગુમાવવો સહેલો છે: આ કનેક્શન કઈ નિષ્ફળતાઓમાંથી પસાર થવું જોઈએ? પહેલાં તેનો જવાબ આપો, પછી ટનલ ગણો, કારણ કે લીલા સૂચકાંકોની સંખ્યા એન્ક્રિપ્શન સ્તરની લાક્ષણિકતા છે અને નિષ્ફળતા-ક્ષેત્રોની સંખ્યા આખા માર્ગની લાક્ષણિકતા છે.
લીલી ટનલથી નહીં, નિષ્ફળતાઓથી શરૂ કરો
કંઈ દોરતા પહેલાં ચાર પંક્તિઓ લખો: એક VPN એન્ડપોઇન્ટ અથવા પિયર ઇન્સ્ટન્સ નિષ્ફળ જવું, એક સ્થાનિક રાઉટર અથવા ફર્સ્ટ-માઇલ કનેક્શન નિષ્ફળ જવું, વહેંચાયેલ ExpressRoute માર્ગ નિષ્ફળ જવો, અને ખાનગી પિયરિંગ હજી ટ્રાફિક વહન કરે છે ત્યારે IPsec અનુપલબ્ધ થવું. દરેક પંક્તિ જણાવે છે કે ડિઝાઇને શું જાળવવું છે, અને દરેકનો જવાબ અલગ મિકેનિઝમ આપે છે.
| Failure | What must survive | What does not cover it |
|---|---|---|
| One VPN endpoint or instance | An alternate encryption endpoint and a route to it | A second tunnel terminating on the same instance |
| One local router or first mile | Independent local equipment and transport reachability | Any number of logical tunnels |
| The ExpressRoute path | A separately designed surviving underlay | An IPsec tunnel layered on the same circuit |
| IPsec unavailable, peering up | The intended encrypted-only or approved fallback policy | Assuming the tunnel is the only route |
Microsoft ExpressRoute ના ખાનગી પિયરિંગ પર ખાનગી-IP સાઇટ-ટુ-સાઇટ VPN અને ઇન્ટરનેટ-આધારિત સાઇટ-ટુ-સાઇટ કનેક્શન સાથેના સમર્થિત સહઅસ્તિત્વનું દસ્તાવેજીકરણ કરે છે. તે સહઅસ્તિત્વ એક અલગ અંડરલે ડિઝાઇન છે, અને તમે બીજું ખાનગી ટનલ એન્ડપોઇન્ટ ઉમેર્યું તેના કારણે જ તે દેખાતું નથી.
નિષ્ફળતા-ક્ષેત્ર 1: VPN એન્ડપોઇન્ટ
એક ગેટવે પરની બે ટનલ સામાન્ય રીતે active-active જોડ હોય છે જે એક જ Azure-બાજુના સંસાધન પર સમાપ્ત થાય છે. તેઓ એક ટનલ અથવા ઇન્સ્ટન્સની સમસ્યાથી રક્ષણ આપે છે, અને તે સંસાધન અનુપલબ્ધ, ફરીથી ગોઠવાયેલું કે ક્ષમતા વગરનું થવાથી રક્ષણ આપતા નથી. એન્ડપોઇન્ટ રિડંડન્સી એટલે પોતાના માર્ગ અને પોતાની ગોઠવણી ધરાવતું બીજું સમર્થિત એન્ડપોઇન્ટ, ઉપરાંત તેને પહોંચી શકે તેવો રૂટ.
ડાયાગ્રામ શું કહે છે તેના બદલે તમે ખરેખર શું તૈનાત કર્યું તે તપાસો, કારણ કે પોર્ટલ આ સંસાધનોને એવી રીતે જૂથબદ્ધ કરે છે જે તેમનો સંબંધ છુપાવે છે:
az network vpn-connection show -g rg-connectivity -n vpn-to-hub --query '{conn:connectionStatus,tunnels:tunnelConnectionStatus}'
az network vnet-gateway show -g rg-connectivity -n gw-hub --query '{sku:sku.name,activeActive:enableBgp,peers:bgpSettings.peers}'જો બંને ટનલ એક જાહેર IP ધરાવતા એક ગેટવે તરફ ઇશારો કરે, તો તમારી પાસે ચોક્કસ અને મર્યાદિત પ્રકારની એન્ડપોઇન્ટ રિડંડન્સી છે. તે કદાચ જરૂરિયાત માંગે છે તે જ હોઈ શકે, અને તેને રિડંડન્ટ કનેક્શન તરીકે વર્ણવવાને બદલે એમ જ કહેવું જોઈએ.
નિષ્ફળતા-ક્ષેત્ર 2: સ્થાનિક માર્ગ અને કેરિયર
એન્ક્રિપ્શનની નીચે ભૌતિક અને વ્યાપારી વાસ્તવિકતા છે: ગ્રાહક-ધાર ઉપકરણ, ક્રોસ-કનેક્ટ, પ્રદાતા નેટવર્ક અને પિયરિંગ સ્થાન. ExpressRoute ઉપલબ્ધતા માર્ગદર્શિકા સ્પષ્ટ છે કે એન્ડ-ટુ-એન્ડ રિડંડન્સીમાં ગ્રાહક અને સેવા-પ્રદાતા વિભાગોનો સમાવેશ થાય છે, ફક્ત Microsoft બાજુ નહીં. રાઉટર, પાવર ફીડ કે ફર્સ્ટ-માઇલ કનેક્શન વહેંચતા બે લોજિકલ માર્ગો હજી પણ તે અવલંબન વહેંચે છે.
અહીં જ એક ડિઝાઇન સામાન્ય રીતે પ્રામાણિક સમીક્ષામાં નિષ્ફળ જાય છે. એક જ પ્રદાતાના બે સર્કિટ, એક જ ઇમારતમાં સમાપ્ત થતા, એક જ ખરીદ ઓર્ડરના સાધનો પર, બે નિષ્ફળતા-ક્ષેત્રો નથી. તે બે ઇન્વોઇસ સાથેનું એક નિષ્ફળતા-ક્ષેત્ર છે.
કેરિયરને લેખિતમાં પૂછો: આમાંથી કયા માર્ગો ક્યાં અલગ પડે છે, અને વહેંચાયેલ વિભાગ નિષ્ફળ જાય ત્યારે દસ્તાવેજી વર્તન શું છે? ડિઝાઇન કૉલ દરમિયાનની મૌખિક ખાતરી તે આઉટેજમાં ટકતી નથી જેના માટે તમે ડિઝાઇન કરી રહ્યા છો.
નિષ્ફળતા-ક્ષેત્ર 3: IPsec વગર ટકી રહેતો રૂટ
ખાનગી પિયરિંગ અને IPsec એક જ એપ્લિકેશન પ્રીફિક્સ માટે સ્પર્ધાત્મક રૂટ આપી શકે છે. જો સંરક્ષિત રૂટ અદૃશ્ય થાય, તો ટકી રહેલો સીધો ExpressRoute રૂટ હજી પણ વપરાયોગ્ય હોઈ શકે, ટનલ જે એન્ક્રિપ્શન સ્તર આપતી હતી તેના વગર. તે સ્વીકાર્ય છે કે નહીં તે નીતિ-નિર્ણય છે, અને તે જ નિર્ણય છે જે સૌથી વધુ ગર્ભિત છોડવામાં આવે છે.
એન્ક્રિપ્શનની જરૂરિયાતો અને ઉપલબ્ધતાની જરૂરિયાતો અહીં ખરેખર અથડાઈ શકે છે. «ટકી રહેલો કોઈપણ રૂટ સફળતા ગણાય છે» એ ઉપલબ્ધતાનું નિવેદન છે જે એન્ક્રિપ્શનના પ્રશ્નનો શાંતિથી «ના» થી જવાબ આપે છે. કઈ જીતે છે, કયા પ્રીફિક્સ માટે, અને કોણે મંજૂરી આપી તે લખો.
az network vnet-gateway list-advertised-routes -g rg-connectivity -n gw-hub --peer 10.0.0.1
az network vnet-gateway list-learned-routes -g rg-connectivity -n gw-hub -o tableશીખેલા રૂટની તમે અપેક્ષા રાખેલા પ્રીફિક્સ સાથે સરખામણી કરો. નાનું વહીવટી ભાર વહન કરતો ફોલબેક તે ભાર માટે સંપૂર્ણ પર્યાપ્ત હોઈ શકે અને ઉત્પાદન માંગને જરૂરી ક્ષમતાથી ઘણો દૂર હોઈ શકે, તેથી રૂટની બાજુમાં ક્ષમતાની ધારણા નોંધો.
એક ચુકાદો નહીં, ત્રણ અલગ પંક્તિઓ નોંધો
એન્ડપોઇન્ટ રિડંડન્સી, ટ્રાન્સપોર્ટ રિડંડન્સી અને આપત્તિ પછીની પુનઃપ્રાપ્તિને ડિઝાઇન રેકોર્ડમાં અલગ એન્ટ્રી તરીકે રાખો, દરેકને પોતાનું મિકેનિઝમ, પોતાની ચકાસણી અને પોતાનો માલિક. જ્યારે ઘટના-સમીક્ષા પૂછે કે કનેક્શન ગેટવે રીસ્ટાર્ટ ટકી ગયું પણ ફાઇબર કટ નહીં, ત્યારે ત્રણ પંક્તિઓ એક વાક્યમાં જવાબ આપે છે; એક «રિડંડન્ટ» ચેકબોક્સ તે કરી શકતું નથી.
પછી જે પંક્તિઓ સસ્તામાં પરીક્ષણ કરી શકાય તેનું પરીક્ષણ કરો. એક ટનલ નિષ્ફળ કરો અને ખાતરી કરો કે ટ્રાફિક ખસે છે અને ફરીથી એન્ક્રિપ્ટ થાય છે. એક રૂટ પાછો ખેંચો અને ખાતરી કરો કે ટકી રહેલો માર્ગ તમે ઇચ્છ્યો તે જ છે, પછી ખાતરી કરો કે તે હજી એન્ક્રિપ્ટેડ છે કે નહીં. જે નિષ્ફળતાઓનું અનુકરણ તમે કરી શક્યા નહીં તેનું દસ્તાવેજીકરણ કરો, કારણ કે ન પરીક્ષણ કરેલી પંક્તિ એક ધારણા છે અને તેને એમ જ લેબલ કરવું જોઈએ.
ઉપયોગી પરિણામ એક ટૂંકું કોષ્ટક અને દરેક પંક્તિ માટે એક વાક્ય છે. જો પંક્તિમાં કોઈ મિકેનિઝમ ન હોય, તો તે જ શોધ છે, અને ડિઝાઇન સમીક્ષામાં તેને શોધવું કેરિયર આઉટેજ દરમિયાન શોધવા કરતાં ઘણું સસ્તું છે, જેમાંથી બંને ટનલ ક્યારેય ટકી ન હોત.