చాలా జట్లు Cloud SQL ప్రైవేట్ IP VPC లోపలి నుండి మాత్రమే పనిచేస్తుందని నమ్ముతాయి, ఆ నమ్మకం కొనసాగుతుంది ఎందుకంటే వైఫల్యం డేటాబేస్ సమస్యలా కనిపిస్తుంది. Google, Cloud VPN లేదా Cloud Interconnect ద్వారా అనుసంధానించిన నెట్‌వర్క్‌ల నుండి ప్రవేశాన్ని డాక్యుమెంట్ చేస్తుంది. ఆ నెట్‌వర్క్‌లకు ప్రత్యేక డేటాబేస్ ఫీచర్ అవసరం లేదు, సగం కాన్ఫిగర్ చేసి వదిలేయడం సులభమైన రెండు మార్గ మార్పిడులు అవసరం. టన్నెల్ పైకి వస్తుంది, కంప్యూట్ ఇన్‌స్టాన్స్‌లు సమాధానం ఇస్తాయి, డేటాబేస్ కనెక్షన్ సమయం ముగిసిపోతుంది — ప్రజలను తప్పు కన్సోల్‌కు పంపే సరిగ్గా ఆ కలయిక.

అపోహ: ప్రైవేట్ IP అంటే VPC కి ప్రైవేట్

ప్రైవేట్ సేవలకు ప్రవేశం అనేది మీ నెట్‌వర్క్ మరియు Google యాజమాన్యంలోని ఉత్పత్తిదారు నెట్‌వర్క్ మధ్య VPC పీరింగ్. సేవ కోసం కేటాయించిన పరిధి ఉత్పత్తిదారు వైపు ఉంటుంది, ఇన్‌స్టాన్స్ చిరునామా దానిలోపల ఉంటుంది. ఆ పీరింగ్ కారణంగానే మీ ప్రాజెక్ట్‌లోని డేటాబేస్ మీ VPC మార్గనిర్దేశం చేసే చిరునామాపై ఉండగలదు, మీ ఏ స్పష్టమైన సబ్‌నెట్‌లోనూ అది లేకున్నా.

ఇది పీరింగ్ కాబట్టి, పీరింగ్ ప్రవర్తన కూడా ఉంది, అనుకూల మార్గాలు స్వయంచాలకంగా దాటని భాగం సహా.

అపోహ: పనిచేసే టన్నెల్ డేటాబేస్ మార్గాన్ని కూడా తీసుకువెళుతుంది

రెండు పరిధులు ఈ ప్రయాణాన్ని తట్టుకోవాలి. మొదటిది క్లయింట్ ప్రిఫిక్స్: మీ స్థానిక నెట్‌వర్క్ నిర్దిష్ట ప్రిఫిక్స్‌లతో Cloud Router కి తెలిసి ఉండాలి, ఎందుకంటే డిఫాల్ట్ మార్గం ఉత్పత్తిదారు నెట్‌వర్క్‌కు తిరిగి వెళ్లే మార్గానికి అవసరమైన దిగుమతిని ఇవ్వలేదు. రెండవది కేటాయించిన సేవా పరిధి, దానిని బయటి వైపు నేర్చుకోవాలి, అప్పుడు డేటాబేస్ వైపు దాని ప్యాకెట్‌లకు వెళ్లడానికి స్థలం ఉంటుంది. ఇవి వేర్వేరు సరిహద్దులలో నిర్వహించే వేర్వేరు మార్గాలు, ఒకటి బాగుచేస్తే మరొకటి పగిలినట్లే ఉంటుంది.

Google వైపు దాని అర్థం సంబంధిత పీరింగ్ కనెక్షన్‌లపై Export custom routes ప్రారంభించడం మరియు టన్నెల్ కోసం Cloud Router ప్రకటించిన మార్గాలలో కేటాయించిన సేవా పరిధిని జోడించడం.

ఇప్పటికే ఉన్న ప్రకటనలను ఉంచండి. సేవా పరిధిని జోడించడం అదే BGP సెషన్ ఇతర ట్రాఫిక్ కోసం మోసుకెళ్లే VPC మార్గాలను తొలగించకూడదు, పూర్తిగా భర్తీ చేయబడిన ప్రకటనల సెట్ మొదటి సమస్య వెనుక దాగిన రెండవ అంతరాయం. బయటి పరికరంలో ప్రభావవంతమైన మార్గాలను కూడా తనిఖీ చేయండి, ఎందుకంటే VPN గేట్‌వే లేదా మరో సబ్‌నెట్‌ను చేరుకోవడం రవాణాను మాత్రమే నిరూపిస్తుంది.

అపోహ: Cloud SQL Auth Proxy నెట్‌వర్క్‌ను పరిష్కరిస్తుంది

The Auth Proxy మీ అప్లికేషన్ మరియు ఇన్‌స్టాన్స్ మధ్య మద్దతు ఉన్న ప్రామాణీకరణ మరియు ఎన్‌క్రిప్ట్ చేసిన రవాణాను అందిస్తుంది. అది మార్గాన్ని సృష్టించదు. ప్రైవేట్ నెట్‌వర్క్‌కు మార్గం లేని హోస్ట్‌పై ప్రారంభించిన ప్రాక్సీ నేరుగా కనెక్షన్ లాగానే విఫలమవుతుంది, దాని లాగ్‌లు కారణం గురించి తక్కువ సహాయకారిగా ఉంటాయి. ప్రాక్సీని కనెక్టివిటీ ఉన్న హోస్ట్‌కు తరలించడం మార్గంలో ఏ భాగం పనిచేయాలో మారుస్తుంది, అది పరిష్కారం కాదు, నిజమైన డిజైన్ నిర్ణయం.

అది చేయనిది ఏమంటే డిస్‌కనెక్ట్ అయిన ల్యాప్‌టాప్ ప్రైవేట్-మాత్రమే ఇన్‌స్టాన్స్‌ను చేరుకోవడానికి అనుమతించడం.

అపోహ: Private Service Connect అదే నియమాలను అనుసరిస్తుంది

Private Service Connect మీ సొంత సబ్‌నెట్‌లో endpoint మరియు మీరు నియంత్రించే DNS ఏర్పాటును ఉపయోగిస్తుంది, కాబట్టి అక్కడికి వెళ్లే మార్గం మీ యాజమాన్యంలోని చిరునామాకు సాధారణ మార్గం. పీరింగ్ ఎగుమతి సెట్టింగ్‌లు ఆ డిజైన్‌కు వర్తించవు, పీరింగ్ మార్పులను PSC అమలులో కాపీ చేయడం చేరుకోగల సామర్థ్యాన్ని జోడించకుండా ప్రమాదాన్ని జోడిస్తుంది.

రెండూ మీకు ప్రైవేట్ చిరునామా ఇస్తాయి; పోలిక అక్కడే ముగుస్తుంది.

మార్గాన్ని సరైన క్రమంలో పరీక్షించండి

బయటి క్లయింట్ నుండి మొదట డేటాబేస్ TCP endpoint ను పరీక్షించండి. పూర్తయిన TCP హ్యాండ్‌షేక్ అంటే మార్గనిర్దేశం, ఫైర్‌వాల్ మరియు శ్రోత అన్నీ ఉన్నాయని, తదుపరి పరీక్ష అనుమతించబడిన ప్రామాణీకృత కార్యకలాపం. ఆ సమయంలో ప్రామాణీకరణ తిరస్కరణ నిజానికి శుభవార్త, ఎందుకంటే డేటాబేస్ శ్రోత సమాధానం ఇచ్చిందని నిరూపిస్తుంది. ICMP సమయం ముగియడం డేటాబేస్ ప్రవేశం గురించి దాదాపు ఏమీ చెప్పదు, ఎందుకంటే చాలా మార్గాలు TCP ను సున్నితంగా పంపుతూనే దానిని పడవేస్తాయి.

మీ క్లయింట్ పరిధులు RFC 1918 వెలుపల ఉంటే, డిజైన్ మద్దతు లేదని నిర్ణయించే ముందు అదనపు మార్గ-ఎగుమతి మరియు నెట్‌వర్క్-అధికార అవసరాలను సమీక్షించండి.

కనెక్షన్‌తో నాలుగు వస్తువులను నమోదు చేయండి: బయటి ప్రిఫిక్స్, కేటాయించిన సేవా పరిధి, సంబంధిత పీరింగ్ కనెక్షన్‌లు మరియు ప్రకటించే రౌటర్. ఆ నాలుగూ మొత్తం ప్రైవేట్ మార్గాన్ని వివరిస్తాయి, Cloud SQL కి ఎప్పుడూ ప్రాక్సీ కావాలి లేదా VPN ద్వారా అసలు చేరుకోలేము అనే కథను అవి భర్తీ చేస్తాయి.

సంబంధిత వ్యాసాలు