Azure VM પર RRAS સમર્થિત નથી: ડિઝાઇન પહેલાં તપાસો

તમે પોર્ટલ ખોલો છો, Windows Server 2022 ને સબનેટમાં તૈનાત કરો છો, અને Remote Access ભૂમિકા સ્વચ્છ રીતે સ્થાપિત થાય છે. તે ક્રમ સાબિત કરે છે કે ઇન્સ્ટોલર કામ કરે છે, એ નહીં કે Microsoft આ રૂપરેખાને સમર્થન આપે છે. Azure વર્ચ્યુઅલ મશીનો માટે પ્રકાશિત સર્વર સૉફ્ટવેર સમર્થન માર્ગદર્શિકા RRAS ને Azure VM પર અસમર્થિત Windows Server સુવિધાઓમાં સૂચવે છે, અને તે આર્કિટેક્ચર નિર્ણય છે, મુશ્કેલીનિવારણની વિગત નહીં. ઉપર આવતી ટનલ તૈનાતીને સમર્થન સીમાની અંદર ખસેડતી નથી.

નીચેની માર્ગદર્શિકા સમર્થન પૃષ્ઠથી શરૂ થાય છે, પછી જરૂરિયાતો અને બદલીના વિકલ્પો તરફ આગળ વધે છે.

પ્રયોગશાળામાં નહીં, સમર્થન પૃષ્ઠથી શરૂ કરો

કંઈપણ માપતા પહેલાં Azure VM સમર્થન માર્ગદર્શિકા વાંચો. તે Windows Server ને એક અભેદ બ્લોક તરીકે ગણવાને બદલે સમર્થિત ઉત્પાદનો, ભૂમિકાઓ અને સુવિધાઓને અલગ કરે છે. નોંધો કે તમારો ઇચ્છિત કાર્યભાર ખરેખર કઈ પંક્તિમાં આવે છે, કારણ કે કન્સોલમાં સંબંધિત દેખાતા બે ઘટકો જુદી જુદી પંક્તિઓમાં હોઈ શકે.

પૃષ્ઠ ખુલ્લું હોય ત્યારે જ ડિઝાઇન દસ્તાવેજમાં ઉદ્ધરણ લખો. સમર્થન સ્થિતિ એ સ્રોત સાથેની હકીકત છે, અને જે ડિઝાઇન સમીક્ષા તેને ઉદ્ધૃત કરી શકતી નથી તેને ડેમો ધરાવનાર વ્યક્તિ દલીલમાં હરાવશે.

OS સમર્થનને ભૂમિકા અને સુવિધા સમર્થનથી અલગ કરો

તે જ માર્ગદર્શિકા Network Policy and Access Services ને સમર્થિત ભૂમિકાઓમાં સૂચવે છે જ્યારે RRAS ને અલગથી અસમર્થિત તરીકે સૂચવે છે. તે બે નોંધો જુદી જુદી વસ્તુઓ વર્ણવે છે, અને તેમને “દૂરસ્થ ઍક્સેસ સમર્થિત છે” માં ભેગા કરવું એ ખોટા વાંચન પર પ્રોજેક્ટ મંજૂર કરવાનો માર્ગ છે. ઑપરેટિંગ સિસ્ટમ સમર્થિત હોવી એ પોતાની પંક્તિ ધરાવતી સુવિધા વિશે કંઈ કહેતું નથી.

મર્યાદા પણ ક્યારેક ટાંકવામાં આવે તેનાથી સાંકડી છે. તે Azure VM ની અંદર ચાલતી તે સુવિધા વિશે છે; તેનો અર્થ એ નથી કે ખાનગી નેટવર્ક Azure સાથે જોડાઈ શકતું નથી, અને તે એ પણ કહેતું નથી કે RRAS દરેક જગ્યાએ અસમર્થિત છે. જૂની પ્રયોગશાળા જે પેકેટોને યોગ્ય રીતે ફોરવર્ડ કરે છે તે પેકેટો વિશે પુરાવો છે, સમર્થન નિવેદન વિશે નહીં.

બાકીના પ્રોજેક્ટ માટે આ બે પ્રશ્નો અલગ રાખો: તે કામ કરે છે કે નહીં, અને તે સમર્થિત છે કે નહીં. દરેક માટે તમને જુદા જુદા જવાબો અને ક્યારેક જુદા જુદા માલિકોની જરૂર પડશે.

ડિઝાઇને ખરેખર શું કરવું જોઈએ તે લખો

બદલી પસંદ કરતા પહેલાં સાઇટની યાદીને એવી જરૂરિયાતોમાં બદલો કે જેની સામે ઉત્પાદનને માપી શકાય:

• શાખાના ઉપકરણો પહેલેથી બોલતા ટનલ પ્રોટોકોલ, અને શું કોઈ સાઇટને ગતિશીલ રૂટિંગની જરૂર છે.
• દૂરસ્થ પ્રીફિક્સ, રૂટિંગને બદલે અનુવાદની જરૂર હોય તેવી કોઈપણ ઓવરલેપિંગ સરનામાં જગ્યા સહિત.
• Azure સાથે રૂટની આપલે, અને રૂટિંગ ટેબલની દરેક નોંધનો માલિક કોણ છે.
• સૌથી વ્યસ્ત કલાકે ટકી રહેવાનું થ્રુપુટ અને જોડાણોની સંખ્યા.
• સાઇટ માલિકોએ સંમત થયેલું ફેલઓવર વર્તન, ફક્ત તમે બનાવી શકો તે જ નહીં.

NAT એ તે વસ્તુ છે જે છોડી દેવાય છે અને પછી આખી ડિઝાઇન નક્કી કરે છે. જે ઉપકરણ IPsec સ્થાપિત કરી શકે છે તે હજી પણ જે RRAS તૈનાતીનું સ્થાન લે છે તેનાથી જુદી રીતે સરનામાંનું અનુવાદ કરી શકે છે, જે બદલે છે કે શાખા કયા સરનામાંને સ્રોત તરીકે જુએ છે અને તમારા લોગ શું નોંધે છે.

યાદી નેટવર્ક માલિકો પાસે લઈ જાઓ અને કોઈપણ ઉત્પાદન ચર્ચા પહેલાં તેની પુષ્ટિ કરો. અસ્પષ્ટ જરૂરિયાતો દરેક વિક્રેતા સરખામણીને પસંદગીની દલીલમાં ફેરવે છે.

તે જરૂરિયાતો સામે બદલીઓનું મૂલ્યાંકન કરો

Azure ની સંચાલિત કનેક્ટિવિટી સેવાઓ અને વિક્રેતા-સમર્થિત નેટવર્ક વર્ચ્યુઅલ ઉપકરણો બંનેને એક જ યાદી સામે ગુણ આપવા જોઈએ. એવું ન ધારો કે તેમાંથી કોઈ RRAS VM નું સીધું સમકક્ષ છે કારણ કે તે IPsec સમાપ્ત કરી શકે છે: NAT મોડેલ અને રૂટની માલિકી અને ઉચ્ચ ઉપલબ્ધતાની ડિઝાઇન નક્કી કરે છે કે હાલની સાઇટો કેવી રીતે જોડાય છે અને તેમના જવાબો ક્યાં પાછા આવે છે. દરેક ઉમેદવારને કાગળ પર યાદી સામે ગુણ આપો અને લખો કે તે કઈ જરૂરિયાતો નિષ્ફળ કરે છે, કારણ કે તે નોંધ પસંદગીને પછીથી સમીક્ષાયોગ્ય બનાવે છે.

બે ઉપકરણ VM ની સામેનું લોડ બેલેન્સર પોતે ઉચ્ચ ઉપલબ્ધતા નથી. તે ફ્રન્ટ એન્ડ આપે છે, સમન્વિત ટનલ સ્થિતિ નહીં, અને દરેક સત્રને પડતું મૂકતું ફેલઓવર એ ડિઝાઇન પસંદગી છે જે કોઈએ જાણી જોઈને કરવી પડે. ઉપકરણ વિક્રેતાને પૂછો કે સમર્થિત HA પેટર્ન કઈ છે અને તે સાઇટોને વચન આપેલી ઉપલબ્ધતા સાથે મેળ ખાય છે કે નહીં. તે સાઇટો તેના પર આધાર રાખે તે પહેલાં ફેલઓવરનું પરીક્ષણ કરો, અને દરેક ગુમાવેલા સત્રને આશ્ચર્ય નહીં, શોધ તરીકે ગણો.

જ્યાં જરૂરિયાત ખરેખર સરળ છે — એક સાઇટ, એક પ્રીફિક્સ, કોઈ ઓવરલેપ નહીં — ત્યાં સંચાલિત સેવા સામાન્ય રીતે સંચાલન ખર્ચમાં જીતે છે. જ્યાં અનુવાદ અને ગતિશીલ રૂટિંગ બંને જોડાયેલા છે, ત્યાં ઉપકરણનો માર્ગ એકમાત્ર યોગ્ય હોઈ શકે છે, અને તે અસમર્થિત VM રાખવાને બદલે લાંબા સ્થળાંતરનું આયોજન કરવાનું કારણ છે.

જો RRAS VM પહેલેથી ચાલુ હોય

શોધ એ તેને ડિલીટ કરવાનું કારણ નથી. તે VM એ એકઠી કરેલી નિર્ભરતાઓ આસપાસ ફેરફારનું આયોજન કરો: અન્ય સબનેટ આધાર રાખતા રૂટ, સ્રોત સરનામાં છુપાવતા NAT નિયમો, અને મોનિટરિંગ તેના સરનામેથી જે અપેક્ષા રાખવાનું શીખ્યું છે તે બધું. સમર્થિત લક્ષ્ય સાથે સાથે ડિઝાઇન અને માન્ય થાય ત્યારે જરૂરી રૂટ અને પરીક્ષિત પુનઃપ્રાપ્તિ માર્ગ સાચવો.

સમર્થનક્ષમતા અને તકનીકી નિદાનને સમગ્ર સમય અલગ શોધ તરીકે રાખો. અસમર્થિત ગોઠવણીમાં સામાન્ય રૂટિંગ ભૂલ પણ હોઈ શકે છે, અને તે ભૂલ સુધારવાથી તેની સમર્થન સ્થિતિ બદલાતી નથી. બંને વિધાનો અહેવાલમાં આવે છે, અને એક પણ બીજાને રદ કરતું નથી.

સમર્થન ઉદ્ધરણ, જરૂરિયાતોની યાદી, પસંદ કરેલી બદલી અને કટઓવર ક્રમ નોંધીને માર્ગદર્શિકા પૂરી કરો. ઓડિટર કે નવો ટીમ સભ્ય પહેલાં આ ચાર વસ્તુઓ જ માંગશે.