ਕਈ 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 ਖਰੀਦਣਾ ਉਸ ਮਾਲਕੀ ਫੈਸਲੇ ਦਾ ਬਦਲ ਨਹੀਂ ਹੈ। ਇਹ ਉਹੀ ਫੈਸਲਾ ਹੈ, ਬਾਅਦ ਵਿੱਚ ਲਿਆ ਗਿਆ, ਬਿੱਲ ਅਤੇ ਰੂਟਿੰਗ ਟੇਬਲ ਵਿਰਾਸਤ ਵਿੱਚ ਪਾਉਣ ਵਾਲੇ ਵਿਅਕਤੀ ਦੁਆਰਾ।