Azure VM 'ਤੇ RRAS ਸਮਰਥਿਤ ਨਹੀਂ: ਡਿਜ਼ਾਈਨ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂਚੋ

ਤੁਸੀਂ ਪੋਰਟਲ ਖੋਲ੍ਹਦੇ ਹੋ, Windows Server 2022 ਨੂੰ ਸਬਨੈੱਟ ਵਿੱਚ ਤੈਨਾਤ ਕਰਦੇ ਹੋ, ਅਤੇ Remote Access ਭੂਮਿਕਾ ਸਾਫ਼-ਸੁਥਰੀ ਸਥਾਪਿਤ ਹੁੰਦੀ ਹੈ। ਉਹ ਕ੍ਰਮ ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਇੰਸਟਾਲਰ ਕੰਮ ਕਰਦਾ ਹੈ, ਇਹ ਨਹੀਂ ਕਿ Microsoft ਇਸ ਸੰਰਚਨਾ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। Azure ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਲਈ ਪ੍ਰਕਾਸ਼ਿਤ ਸਰਵਰ ਸੌਫਟਵੇਅਰ ਸਮਰਥਨ ਗਾਈਡ RRAS ਨੂੰ ਉਨ੍ਹਾਂ Windows Server ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿੱਚ ਸੂਚੀਬੱਧ ਕਰਦੀ ਹੈ ਜੋ Azure VM 'ਤੇ ਸਮਰਥਿਤ ਨਹੀਂ ਹਨ, ਅਤੇ ਇਹ ਸਮੱਸਿਆ-ਨਿਵਾਰਨ ਦੀ ਵਿਸਤਾਰ ਨਹੀਂ ਬਲਕਿ ਆਰਕੀਟੈਕਚਰ ਫੈਸਲਾ ਹੈ। ਉੱਪਰ ਆਉਣ ਵਾਲੀ ਟਨਲ ਤੈਨਾਤੀ ਨੂੰ ਸਮਰਥਨ ਸੀਮਾ ਦੇ ਅੰਦਰ ਨਹੀਂ ਲਿਜਾਂਦੀ।

ਹੇਠਾਂ ਦਿੱਤੀ ਗਾਈਡ ਸਮਰਥਨ ਪੰਨੇ ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ, ਫਿਰ ਲੋੜਾਂ ਅਤੇ ਬਦਲਵੇਂ ਵਿਕਲਪਾਂ ਵੱਲ ਵਧਦੀ ਹੈ।

ਪ੍ਰਯੋਗਸ਼ਾਲਾ ਵਿੱਚ ਨਹੀਂ, ਸਮਰਥਨ ਪੰਨੇ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ

ਕੁਝ ਵੀ ਮਾਪਣ ਤੋਂ ਪਹਿਲਾਂ 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 ਨਿਯਮ, ਅਤੇ ਮਾਨੀਟਰਿੰਗ ਨੇ ਇਸਦੇ ਪਤੇ ਤੋਂ ਜੋ ਆਸ ਰੱਖਣਾ ਸਿੱਖਿਆ ਹੈ। ਸਮਰਥਿਤ ਟੀਚੇ ਦੇ ਨਾਲ-ਨਾਲ ਡਿਜ਼ਾਈਨ ਅਤੇ ਪ੍ਰਮਾਣਿਤ ਹੁੰਦੇ ਸਮੇਂ ਲੋੜੀਂਦੇ ਰਾਊਟ ਅਤੇ ਪਰਖਿਆ ਰਿਕਵਰੀ ਰਾਹ ਸੰਭਾਲੋ।

ਸਮਰਥਨਯੋਗਤਾ ਅਤੇ ਤਕਨੀਕੀ ਨਿਦਾਨ ਨੂੰ ਹਰ ਸਮੇਂ ਵੱਖਰੇ ਨਤੀਜਿਆਂ ਵਜੋਂ ਰੱਖੋ। ਅਸਮਰਥਿਤ ਪ੍ਰਬੰਧ ਵਿੱਚ ਆਮ ਰਾਊਟਿੰਗ ਗਲਤੀ ਵੀ ਹੋ ਸਕਦੀ ਹੈ, ਅਤੇ ਉਸ ਗਲਤੀ ਨੂੰ ਠੀਕ ਕਰਨ ਨਾਲ ਇਸਦੀ ਸਮਰਥਨ ਸਥਿਤੀ ਨਹੀਂ ਬਦਲਦੀ। ਦੋਵੇਂ ਕਥਨ ਰਿਪੋਰਟ ਵਿੱਚ ਹਨ, ਅਤੇ ਇੱਕ ਦੂਜੇ ਨੂੰ ਰੱਦ ਨਹੀਂ ਕਰਦਾ।

ਸਮਰਥਨ ਹਵਾਲਾ, ਲੋੜਾਂ ਦੀ ਸੂਚੀ, ਚੁਣਿਆ ਬਦਲ ਅਤੇ ਕਟਓਵਰ ਕ੍ਰਮ ਦਰਜ ਕਰਕੇ ਗਾਈਡ ਪੂਰੀ ਕਰੋ। ਲੇਖਾ-ਪਰੀਖਿਅਕ ਜਾਂ ਨਵਾਂ ਟੀਮ ਮੈਂਬਰ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਇਹੀ ਚਾਰ ਚੀਜ਼ਾਂ ਪੁੱਛੇਗਾ।