ಹಲವು 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 ಖರೀದಿಸುವುದು ಆ ಮಾಲೀಕತ್ವದ ನಿರ್ಧಾರಕ್ಕೆ ಪರ್ಯಾಯವಲ್ಲ. ಅದು ಅದೇ ನಿರ್ಧಾರ, ನಂತರ ತೆಗೆದುಕೊಂಡದ್ದು, ಬಿಲ್ ಮತ್ತು ರೂಟಿಂಗ್ ಕೋಷ್ಟಕವನ್ನು ಆನುವಂಶಿಕವಾಗಿ ಪಡೆಯುವವರಿಂದ.