మొదటి రెండు కథనాలలో, నేను ఆటోమేషన్ సమస్యను లేవనెత్తాను మరియు దాని ఫ్రేమ్‌వర్క్‌ను రూపొందించాను, రెండవదానిలో నేను సేవల కాన్ఫిగరేషన్‌ను ఆటోమేట్ చేయడానికి మొదటి విధానంగా నెట్‌వర్క్ వర్చువలైజేషన్‌లోకి తిరోగమనం చేసాను.
ఇప్పుడు భౌతిక నెట్‌వర్క్ యొక్క రేఖాచిత్రాన్ని గీయడానికి సమయం ఆసన్నమైంది.
మీకు డేటా సెంటర్ నెట్‌వర్క్‌లను సెటప్ చేయడం గురించి తెలియకపోతే, దీన్ని ప్రారంభించమని నేను గట్టిగా సిఫార్సు చేస్తున్నాను .
అన్ని సమస్యలు:
ఈ శ్రేణిలో వివరించిన పద్ధతులు ఏ రకమైన నెట్‌వర్క్‌కైనా, ఏ పరిమాణానికైనా, ఏ రకమైన విక్రేతలకైనా (కాదు) వర్తిస్తాయి. అయితే, ఈ విధానాల యొక్క అప్లికేషన్ యొక్క సార్వత్రిక ఉదాహరణను వివరించడం అసాధ్యం. అందువల్ల, నేను DC నెట్‌వర్క్ యొక్క ఆధునిక నిర్మాణంపై దృష్టి పెడతాను: .
మేము MPLS L3VPNలో DCI చేస్తాము.
అతివ్యాప్తి నెట్‌వర్క్ హోస్ట్ నుండి భౌతిక నెట్‌వర్క్ పైన నడుస్తుంది (ఇది ఓపెన్‌స్టాక్ యొక్క VXLAN లేదా టంగ్‌స్టన్ ఫ్యాబ్రిక్ లేదా నెట్‌వర్క్ నుండి ప్రాథమిక IP కనెక్టివిటీ మాత్రమే అవసరమయ్యే ఏదైనా కావచ్చు).
ఈ సందర్భంలో, మేము ఆటోమేషన్ కోసం సాపేక్షంగా సరళమైన దృష్టాంతాన్ని పొందుతాము, ఎందుకంటే మనకు అదే విధంగా కాన్ఫిగర్ చేయబడిన చాలా పరికరాలు ఉన్నాయి.
మేము వాక్యూమ్‌లో గోళాకార DCని ఎంచుకుంటాము:
- ప్రతిచోటా ఒక డిజైన్ వెర్షన్.
- ఇద్దరు విక్రేతలు రెండు నెట్‌వర్క్ విమానాలను రూపొందించారు.
- ఒక DC మరొకటి పాడ్‌లో రెండు బఠానీల లాంటిది.
కంటెంట్
- భౌతిక టోపోలాజీ
- రూటింగ్
- IP ప్రణాళిక
- లాబా
- తీర్మానం
- ఉపయోగకరమైన లింకులు
మా సేవా ప్రదాత LAN_DCని అనుమతించండి, ఉదాహరణకు, నిలిచిపోయిన ఎలివేటర్‌లలో జీవించడం గురించి శిక్షణ వీడియోలను హోస్ట్ చేయండి.
మెగాసిటీలలో ఇది బాగా ప్రాచుర్యం పొందింది, కాబట్టి మీకు చాలా భౌతిక యంత్రాలు అవసరం.
ముందుగా, నేను నెట్‌వర్క్‌ని నేను కోరుకున్నట్లు వివరిస్తాను. ఆపై నేను దానిని ప్రయోగశాల కోసం సరళీకృతం చేస్తాను.
భౌతిక టోపోలాజీ
స్థానాలు
LAN_DC 6 DCలను కలిగి ఉంటుంది:
- రష్యా (RU):
- మాస్కో (MSK)
- కజాన్ (kzn)
- స్పెయిన్ (SP):
- బార్సిలోనా (bcn)
- మాలాగా (mlg)
- చైనా (CN):
- షాంఘై (SHA)
- జియాన్ (రెండు)
DC లోపల (ఇంట్రా-DC)
అన్ని DCలు క్లోస్ టోపోలాజీ ఆధారంగా ఒకేలా అంతర్గత కనెక్టివిటీ నెట్‌వర్క్‌లను కలిగి ఉంటాయి.
అవి ఎలాంటి క్లోస్ నెట్వర్క్లు మరియు అవి ఎందుకు విడివిడిగా ఉన్నాయి .
ప్రతి DC యంత్రాలతో 10 రాక్‌లను కలిగి ఉంటుంది, అవి ఇలా లెక్కించబడతాయి A, B, C అందువలన న.
ఒక్కో ర్యాక్‌లో 30 యంత్రాలు ఉంటాయి. వారు మాకు ఆసక్తి చూపరు.
ప్రతి రాక్‌లో అన్ని యంత్రాలు కనెక్ట్ చేయబడిన స్విచ్ ఉంది - ఇది ర్యాక్ స్విచ్ పైన - ToR లేకుంటే, క్లోస్ ఫ్యాక్టరీ పరంగా, మేము దానిని పిలుస్తాము లీఫ్.
ఫ్యాక్టరీ యొక్క సాధారణ రేఖాచిత్రం.
మేము వారిని పిలుస్తాము XXX- ఆకుYపేరు XXX - మూడు-అక్షరాల సంక్షిప్త DC, మరియు Y - క్రమ సంఖ్య. ఉదాహరణకి, kzn-leaf11.
నా కథనాలలో నేను Leaf మరియు ToR అనే పదాలను పర్యాయపదాలుగా కాకుండా పనికిమాలిన పదాలను ఉపయోగించడానికి అనుమతిస్తాను. అయితే, ఇది అలా కాదని మనం గుర్తుంచుకోవాలి.
ToR అనేది యంత్రాలు కనెక్ట్ చేయబడిన రాక్‌లో ఇన్‌స్టాల్ చేయబడిన స్విచ్.
లీఫ్ అనేది ఫిజికల్ నెట్‌వర్క్‌లో పరికరం యొక్క పాత్ర లేదా క్లోస్ టోపోలాజీ పరంగా మొదటి-స్థాయి స్విచ్.
అంటే, లీఫ్ != ToR.
కాబట్టి లీఫ్ ఒక EndofRaw స్విచ్ కావచ్చు, ఉదాహరణకు.
అయినప్పటికీ, ఈ ఆర్టికల్ ఫ్రేమ్‌వర్క్‌లో మేము వాటిని పర్యాయపదాలుగా పరిగణిస్తాము.
ప్రతి ToR స్విచ్ నాలుగు ఉన్నత-స్థాయి అగ్రిగేషన్ స్విచ్‌లకు కనెక్ట్ చేయబడింది - వెన్నెముక. DC లో ఒక ర్యాక్ స్పైన్స్ కోసం కేటాయించబడింది. మేము దీనికి ఇలాగే పేరు పెడతాము: XXX- వెన్నెముకY.
అదే ర్యాక్ DC - 2 రౌటర్ల మధ్య కనెక్టివిటీ కోసం నెట్‌వర్క్ పరికరాలను కలిగి ఉంటుంది, ఇది MPLSతో ఉంటుంది. కానీ పెద్దగా, ఇవి ఒకే ToRలు. అంటే, స్పైన్ స్విచ్‌ల దృక్కోణం నుండి, కనెక్ట్ చేయబడిన యంత్రాలతో సాధారణ ToR లేదా DCI కోసం రూటర్ అస్సలు పట్టింపు లేదు - కేవలం ఫార్వార్డింగ్.
అటువంటి ప్రత్యేక ToRలు అంటారు అంచు-ఆకు. మేము వారిని పిలుస్తాము XXX-ఎడ్జ్Y.
ఇది ఇలా ఉంటుంది.
పైన ఉన్న రేఖాచిత్రంలో, నేను నిజానికి అంచు మరియు ఆకులను అదే స్థాయిలో ఉంచాను. అప్‌లింక్ చేయడాన్ని (అందుకే ఈ పదాన్ని) అప్‌లింక్‌లుగా పరిగణించాలని వారు మాకు నేర్పించారు. మరియు ఇక్కడ DCI “అప్‌లింక్” వెనక్కి తగ్గుతుందని తేలింది, ఇది కొంతమందికి సాధారణ తర్కాన్ని కొద్దిగా విచ్ఛిన్నం చేస్తుంది. పెద్ద నెట్‌వర్క్‌ల విషయంలో, డేటా సెంటర్‌లను ఇంకా చిన్న యూనిట్‌లుగా విభజించినప్పుడు - పాడ్యొక్క (పాయింట్ ఆఫ్ డెలివరీ), వ్యక్తిగతంగా హైలైట్ చేయండి అంచు-PODDCI కోసం మరియు బాహ్య నెట్‌వర్క్‌లకు యాక్సెస్.
భవిష్యత్తులో అవగాహన సౌలభ్యం కోసం, నేను ఇప్పటికీ వెన్నెముకపై అంచుని గీస్తాను, అయితే వెన్నెముకపై తెలివితేటలు లేవని మరియు సాధారణ లీఫ్ మరియు ఎడ్జ్-లీఫ్‌తో పనిచేసేటప్పుడు తేడాలు ఉండవని మేము గుర్తుంచుకోవాలి (ఇక్కడ సూక్ష్మబేధాలు ఉన్నప్పటికీ. , కానీ సాధారణంగా ఇది నిజం).
అంచు-ఆకులతో కర్మాగారం యొక్క పథకం.
లీఫ్, స్పైన్ మరియు ఎడ్జ్ యొక్క త్రిమూర్తులు అండర్లే నెట్‌వర్క్ లేదా ఫ్యాక్టరీని ఏర్పరుస్తాయి.
నెట్‌వర్క్ ఫ్యాక్టరీ యొక్క విధి (అండర్లే చదవండి), మేము ఇప్పటికే నిర్వచించినట్లుగా , చాలా, చాలా సులభం - ఒకే DC లోపల మరియు వాటి మధ్య యంత్రాల మధ్య IP కనెక్టివిటీని అందించడం.
అందుకే నెట్‌వర్క్‌ను ఫ్యాక్టరీ అని పిలుస్తారు, ఉదాహరణకు, మాడ్యులర్ నెట్‌వర్క్ బాక్స్‌లలోని స్విచ్చింగ్ ఫ్యాక్టరీ లాగా, మీరు దీని గురించి మరింత చదవవచ్చు .
సాధారణంగా, అటువంటి టోపోలాజీని ఫ్యాక్టరీ అని పిలుస్తారు, ఎందుకంటే అనువాదంలో ఫాబ్రిక్ అంటే ఫాబ్రిక్. మరియు విభేదించడం కష్టం:
ఫ్యాక్టరీ పూర్తిగా L3. VLAN లేదు, బ్రాడ్‌కాస్ట్ లేదు - LAN_DCలో మాకు అలాంటి అద్భుతమైన ప్రోగ్రామర్లు ఉన్నారు, L3 నమూనాలో నివసించే అప్లికేషన్‌లను ఎలా వ్రాయాలో వారికి తెలుసు మరియు వర్చువల్ మెషీన్‌లకు IP చిరునామాను భద్రపరిచే లైవ్ మైగ్రేషన్ అవసరం లేదు.
మరియు మరోసారి: కర్మాగారం ఎందుకు మరియు L3 ఎందుకు విడిగా ఉంది అనే ప్రశ్నకు సమాధానం .
DCI - డేటా సెంటర్ ఇంటర్‌కనెక్ట్ (ఇంటర్-DC)
DCI ఎడ్జ్-లీఫ్‌ని ఉపయోగించి నిర్వహించబడుతుంది, అనగా అవి హైవేకి మా నిష్క్రమణ స్థానం.
సరళత కోసం, DCలు ఒకదానికొకటి ప్రత్యక్ష లింక్‌ల ద్వారా అనుసంధానించబడి ఉన్నాయని మేము ఊహిస్తాము.
బాహ్య కనెక్టివిటీని పరిగణనలోకి తీసుకోకుండా మినహాయిద్దాం.
నేను ఒక భాగాన్ని తీసివేసిన ప్రతిసారీ, నేను నెట్‌వర్క్‌ను గణనీయంగా సరళీకృతం చేస్తానని నాకు తెలుసు. మరియు మేము మా నైరూప్య నెట్‌వర్క్‌ను ఆటోమేట్ చేసినప్పుడు, ప్రతిదీ బాగానే ఉంటుంది, కానీ నిజమైన దానిలో క్రచెస్ ఉంటుంది.
ఇది నిజం. ఇప్పటికీ, ఈ ధారావాహిక యొక్క ఉద్దేశ్యం ఏమిటంటే, ఆలోచనాత్మకమైన సమస్యలను వీరోచితంగా పరిష్కరించడం కాదు, విధానాలపై ఆలోచించడం మరియు పని చేయడం.
ఎడ్జ్-లీఫ్స్‌లో, అండర్లే VPNలో ఉంచబడుతుంది మరియు MPLS వెన్నెముక (అదే ప్రత్యక్ష లింక్) ద్వారా ప్రసారం చేయబడుతుంది.
ఇది మనకు లభించే ఉన్నత-స్థాయి రేఖాచిత్రం.
రూటింగ్
DC లోపల రూటింగ్ కోసం మేము BGPని ఉపయోగిస్తాము.
MPLS ట్రంక్ OSPF+LDPపై.
DCI కోసం, అంటే, భూగర్భంలో కనెక్టివిటీని నిర్వహించడం - MPLS ద్వారా BGP L3VPN.
సాధారణ రూటింగ్ పథకం
ఫ్యాక్టరీ వద్ద OSPF లేదా ISIS (రష్యన్ ఫెడరేషన్‌లో రూటింగ్ ప్రోటోకాల్ నిషేధించబడింది) లేదు.
ప్రోటోకాల్, పొరుగు మరియు విధానాలను సెటప్ చేయడం మాన్యువల్ (వాస్తవానికి ఆటోమేటిక్ - మేము ఇక్కడ ఆటోమేషన్ గురించి మాట్లాడుతున్నాము) మాత్రమే - స్వయంచాలక-ఆవిష్కరణ లేదా చిన్న మార్గాల గణన ఉండదని దీని అర్థం.
DC లోపల BGP రూటింగ్ పథకం
BGP ఎందుకు?
ఈ అంశంపై ఉంది Facebook మరియు Arista పేరు పెట్టబడింది, ఇది ఎలా నిర్మించాలో చెబుతుంది చాలా పెద్ద BGPని ఉపయోగించే డేటా సెంటర్ నెట్వర్క్లు. ఇది దాదాపు కల్పన లాగా చదువుతుంది, నీరసమైన సాయంత్రం కోసం నేను దీన్ని బాగా సిఫార్సు చేస్తున్నాను.
మరియు నా వ్యాసంలో దీనికి అంకితమైన మొత్తం విభాగం కూడా ఉంది. నేను నిన్ను ఎక్కడికి తీసుకెళతాను మరియు .
కానీ ఇప్పటికీ, సంక్షిప్తంగా, పెద్ద డేటా సెంటర్‌ల నెట్‌వర్క్‌లకు ఏ IGP అనుకూలంగా ఉండదు, ఇక్కడ నెట్‌వర్క్ పరికరాల సంఖ్య వేలల్లో ఉంటుంది.
అదనంగా, BGPని ప్రతిచోటా ఉపయోగించడం వలన మీరు అనేక విభిన్న ప్రోటోకాల్‌లకు మరియు వాటి మధ్య సమకాలీకరణకు మద్దతు ఇవ్వడానికి సమయాన్ని వృథా చేయకుండా అనుమతిస్తుంది.
గుండె మీద చేయి, మా ఫ్యాక్టరీలో, అధిక స్థాయి సంభావ్యతతో వేగంగా వృద్ధి చెందదు, OSPF కళ్ళకు సరిపోతుంది. ఇవి వాస్తవానికి మెగాస్కేలర్లు మరియు క్లౌడ్ టైటాన్స్ యొక్క సమస్యలు. కానీ మనకు అవసరమైన కొన్ని విడుదలల కోసం మాత్రమే ఊహించుకుందాం మరియు ప్యోటర్ లాపుఖోవ్ ఇచ్చిన విధంగా మేము BGPని ఉపయోగిస్తాము.
రూటింగ్ విధానాలు
లీఫ్ స్విచ్‌లపై, మేము అండర్లే నెట్‌వర్క్ ఇంటర్‌ఫేస్‌ల నుండి ప్రిఫిక్స్‌లను BGPలోకి దిగుమతి చేస్తాము.
మధ్య BGP సెషన్ ఉంటుంది ప్రతి లీఫ్-స్పైన్ జత, దీనిలో ఈ అండర్లే ప్రిఫిక్స్‌లు నెట్‌వర్క్‌లో మరియు అక్కడక్కడ ప్రకటించబడతాయి.
ఒక డేటా సెంటర్‌లో, మేము ToReకి దిగుమతి చేసుకున్న స్పెసిఫికేషన్‌లను పంపిణీ చేస్తాము. ఎడ్జ్-లీఫ్స్‌లో మేము వాటిని సమగ్రపరచి, వాటిని రిమోట్ DCలకు ప్రకటిస్తాము మరియు వాటిని TORలకు పంపుతాము. అంటే, ప్రతి ToRకి అదే DCలో మరొక ToRకి ఎలా చేరుకోవాలో మరియు మరొక DCలో ToRకి ఎక్కడ ఎంట్రీ పాయింట్ రావాలో ఖచ్చితంగా తెలుస్తుంది.
DCIలో, మార్గాలు VPNv4గా ప్రసారం చేయబడతాయి. దీన్ని చేయడానికి, ఎడ్జ్-లీఫ్‌లో, ఫ్యాక్టరీ వైపు ఇంటర్‌ఫేస్ VRFలో ఉంచబడుతుంది, దానిని అండర్లే అని పిలుద్దాం మరియు ఎడ్జ్-లీఫ్‌పై స్పైన్‌తో ఉన్న పరిసరాలు VRF లోపల మరియు VPNv4-లోని ఎడ్జ్-లీఫ్‌ల మధ్య పెరుగుతాయి. కుటుంబం.
వెన్నుపూసల నుండి తిరిగి వాటికి తిరిగి వచ్చే మార్గాలను తిరిగి ప్రకటించడాన్ని కూడా మేము నిషేధిస్తాము.
లీఫ్ మరియు స్పైన్‌పై మేము లూప్‌బ్యాక్‌లను దిగుమతి చేయము. రూటర్ IDని గుర్తించడానికి మాత్రమే మాకు అవి అవసరం.
కానీ ఎడ్జ్-లీఫ్స్‌లో మేము దానిని గ్లోబల్ BGPకి దిగుమతి చేస్తాము. లూప్‌బ్యాక్ చిరునామాల మధ్య, ఎడ్జ్-లీఫ్‌లు ఒకదానితో ఒకటి IPv4 VPN-ఫ్యామిలీలో BGP సెషన్‌ను ఏర్పాటు చేస్తాయి.
మేము EDGE పరికరాల మధ్య OSPF+LDP వెన్నెముకను కలిగి ఉంటాము. అంతా ఒకే జోన్‌లో ఉంది. చాలా సులభమైన కాన్ఫిగరేషన్.
ఇది రూటింగ్‌తో కూడిన చిత్రం.
BGP ASN
ఎడ్జ్-లీఫ్ ASN
ఎడ్జ్-లీఫ్స్‌లో అన్ని DCలలో ఒక ASN ఉంటుంది. ఎడ్జ్-లీఫ్‌ల మధ్య iBGP ఉండటం ముఖ్యం మరియు మేము eBGP యొక్క సూక్ష్మ నైపుణ్యాలలో చిక్కుకోము. ఇది 65535గా ఉండనివ్వండి. వాస్తవానికి, ఇది పబ్లిక్ AS సంఖ్య కావచ్చు.
వెన్నెముక ASN
వెన్నెముకపై మేము ఒక DCకి ఒక ASNని కలిగి ఉంటాము. ప్రైవేట్ AS - 64512, 64513 మొదలైన వాటి నుండి మొదటి సంఖ్యతో ఇక్కడ ప్రారంభిద్దాం.
DCలో ASN ఎందుకు?
ఈ ప్రశ్నను రెండుగా విడదీద్దాం:
- ఒక DC యొక్క అన్ని వెన్నుముకలపై ASNలు ఎందుకు ఒకే విధంగా ఉంటాయి?
- వేర్వేరు DCలలో అవి ఎందుకు భిన్నంగా ఉంటాయి?
ఒక DC యొక్క అన్ని వెన్నుముకలపై ఒకే ASNలు ఎందుకు ఉన్నాయి?
ఎడ్జ్-లీఫ్‌లో అండర్లే మార్గం యొక్క AS-పాత్ ఇలా కనిపిస్తుంది:
[leafX_ASN, spine_ASN, edge_ASN]
మీరు దానిని వెన్నెముకకు తిరిగి ప్రకటించడానికి ప్రయత్నించినప్పుడు, దాని AS (Spine_AS) ఇప్పటికే జాబితాలో ఉన్నందున అది దానిని విస్మరిస్తుంది.
అయితే, ఎడ్జ్‌కు ఎక్కే అండర్లే మార్గాలు క్రిందికి వెళ్లలేవని DC లోపల మేము పూర్తిగా సంతృప్తి చెందాము. DCలోని అతిధేయల మధ్య అన్ని కమ్యూనికేషన్లు తప్పనిసరిగా వెన్నెముక స్థాయిలోనే జరగాలి.
ఈ సందర్భంలో, ఇతర DCల యొక్క సమగ్ర మార్గాలు ఏ సందర్భంలో అయినా సులభంగా ToRలను చేరుకుంటాయి - వాటి AS-పాత్‌లో ASN 65535 మాత్రమే ఉంటుంది - AS ఎడ్జ్-లీఫ్‌ల సంఖ్య, అక్కడ అవి సృష్టించబడ్డాయి.
వేర్వేరు DCలలో అవి ఎందుకు భిన్నంగా ఉంటాయి?
సిద్ధాంతపరంగా, మేము DCల మధ్య లూప్‌బ్యాక్ మరియు కొన్ని సర్వీస్ వర్చువల్ మిషన్‌లను లాగవలసి రావచ్చు.
ఉదాహరణకు, హోస్ట్‌లో మేము రూట్ రిఫ్లెక్టర్ లేదా రన్ చేస్తాము (వర్చువల్ నెట్‌వర్క్ గేట్‌వే), ఇది BGP ద్వారా TopRతో లాక్ చేయబడుతుంది మరియు దాని లూప్‌బ్యాక్‌ను ప్రకటిస్తుంది, ఇది అన్ని DCల నుండి అందుబాటులో ఉండాలి.
కాబట్టి దీని AS-మార్గం ఇలా ఉంటుంది:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]
మరియు ఎక్కడా నకిలీ ASNలు ఉండకూడదు.
అంటే, Spine_DC1 మరియు Spine_DC2 తప్పనిసరిగా లీఫ్‌ఎక్స్_డిసి1 మరియు లీఫ్‌వై_డిసి2 లాగా వేర్వేరుగా ఉండాలి, అదే మనం చేరుకుంటున్నాము.
మీకు బహుశా తెలిసినట్లుగా, లూప్ ప్రివెన్షన్ మెకానిజం (సిస్కోలో అనుమతించడం) ఉన్నప్పటికీ డూప్లికేట్ ASNలతో మార్గాలను ఆమోదించడానికి మిమ్మల్ని అనుమతించే హ్యాక్‌లు ఉన్నాయి. మరియు ఇది చట్టబద్ధమైన ఉపయోగాలను కూడా కలిగి ఉంది. కానీ ఇది నెట్‌వర్క్ స్థిరత్వంలో సంభావ్య అంతరం. మరియు నేను వ్యక్తిగతంగా దానిలో రెండు సార్లు పడిపోయాను.
మరియు ప్రమాదకరమైన వస్తువులను ఉపయోగించకుండా ఉండటానికి మనకు అవకాశం ఉంటే, మేము దానిని సద్వినియోగం చేసుకుంటాము.
ఆకు ASN
నెట్‌వర్క్ అంతటా ప్రతి లీఫ్ స్విచ్‌లో మేము ఒక వ్యక్తి ASNని కలిగి ఉంటాము.
పైన పేర్కొన్న కారణాల కోసం మేము దీన్ని చేస్తాము: లూప్‌లు లేని AS-పాత్, బుక్‌మార్క్‌లు లేకుండా BGP కాన్ఫిగరేషన్.
లీఫ్‌ల మధ్య మార్గాలు సజావుగా వెళ్లాలంటే, AS-పాత్ ఇలా ఉండాలి:
[leafX_ASN, spine_ASN, leafY_ASN]
ఇక్కడ leafX_ASN మరియు leafY_ASN భిన్నంగా ఉంటే బాగుంటుంది.
DCల మధ్య VNF లూప్‌బ్యాక్ ప్రకటనతో పరిస్థితికి కూడా ఇది అవసరం:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]
మేము 4-బైట్ ASNని ఉపయోగిస్తాము మరియు స్పైన్ యొక్క ASN మరియు లీఫ్ స్విచ్ నంబర్ ఆధారంగా దీన్ని రూపొందిస్తాము, అవి ఇలా: వెన్నెముక_ASN.0000X.
ఇది ASNతో ఉన్న చిత్రం.
IP ప్రణాళిక
ప్రాథమికంగా, మేము ఈ క్రింది కనెక్షన్‌ల కోసం చిరునామాలను కేటాయించాలి:
- ToR మరియు మెషిన్ మధ్య నెట్‌వర్క్ చిరునామాలను అండర్లే చేయండి. అవి తప్పనిసరిగా మొత్తం నెట్‌వర్క్‌లో ప్రత్యేకంగా ఉండాలి, తద్వారా ఏదైనా యంత్రం ఏదైనా ఇతర వాటితో కమ్యూనికేట్ చేయగలదు. గ్రేట్ ఫిట్ 10/8. ప్రతి రాక్ కోసం రిజర్వ్‌తో /26 ఉన్నాయి. మేము ప్రతి DCకి /19 మరియు ప్రతి ప్రాంతానికి /17 చొప్పున కేటాయిస్తాము.
- లీఫ్/టోర్ మరియు వెన్నెముక మధ్య చిరునామాలను లింక్ చేయండి.
నేను వాటిని అల్గారిథమిక్‌గా కేటాయించాలనుకుంటున్నాను, అంటే కనెక్ట్ చేయవలసిన పరికరాల పేర్ల నుండి వాటిని లెక్కించండి.
అది ఉండనివ్వండి... 169.254.0.0/16.
అవి 169.254.00X.Y/31పేరు X - వెన్నెముక సంఖ్య, Y - P2P నెట్‌వర్క్ /31.
ఇది DCలో గరిష్టంగా 128 రాక్‌లను మరియు 10 స్పైన్‌లను ప్రారంభించేందుకు మిమ్మల్ని అనుమతిస్తుంది. లింక్ చిరునామాలు DC నుండి DCకి పునరావృతం చేయవచ్చు (మరియు ఉంటుంది). - మేము సబ్‌నెట్‌లలో స్పైన్-ఎడ్జ్-లీఫ్ జంక్షన్‌ని నిర్వహిస్తాము 169.254.10X.Y/31, సరిగ్గా అదే X - వెన్నెముక సంఖ్య, Y - P2P నెట్‌వర్క్ /31.
- ఎడ్జ్-లీఫ్ నుండి MPLS బ్యాక్‌బోన్‌కి చిరునామాలను లింక్ చేయండి. ఇక్కడ పరిస్థితి కొంత భిన్నంగా ఉంటుంది - అన్ని ముక్కలు ఒక పైకి కనెక్ట్ చేయబడిన ప్రదేశం, కాబట్టి అదే చిరునామాలను మళ్లీ ఉపయోగించడం పని చేయదు - మీరు తదుపరి ఉచిత సబ్‌నెట్‌ను ఎంచుకోవాలి. అందువల్ల, ఒక ప్రాతిపదికగా తీసుకుందాం 192.168.0.0/16 మరియు మేము దాని నుండి ఉచిత వాటిని తొలగిస్తాము.
- లూప్‌బ్యాక్ చిరునామాలు. వాటి కోసం మొత్తం రేంజ్ ఇస్తాం 172.16.0.0/12.
- లీఫ్ - / DCకి 25 - అదే 128 రాక్‌లు. మేము ఒక్కో ప్రాంతానికి /23 చొప్పున కేటాయిస్తాము.
- వెన్నెముక - / DCకి 28 - 16 వెన్నెముక వరకు. ఒక్కో ప్రాంతానికి /26 చొప్పున కేటాయిద్దాం.
- ఎడ్జ్-లీఫ్ - / DCకి 29 - 8 బాక్స్‌ల వరకు. ఒక్కో ప్రాంతానికి /27 చొప్పున కేటాయిద్దాం.
DCలో మనకు తగినంత కేటాయించబడిన పరిధులు లేకుంటే (మరియు ఏవీ ఉండవు - మేము హైపర్‌స్కేలర్‌లమని క్లెయిమ్ చేస్తాము), మేము కేవలం తదుపరి బ్లాక్‌ని ఎంచుకుంటాము.
ఇది IP చిరునామాతో ఉన్న చిత్రం.
లూప్‌బ్యాక్‌లు:
ఉపసర్గ
పరికరం యొక్క పాత్ర
ప్రాంతం
DC
172.16.0.0/23
అంచున
172.16.0.0/27
ru
172.16.0.0/29
MSK
172.16.0.8/29
kzn
172.16.0.32/27
sp
172.16.0.32/29
bcn
172.16.0.40/29
mlg
172.16.0.64/27
cn
172.16.0.64/29
SHA
172.16.0.72/29
రెండు
172.16.2.0/23
వెన్నెముక
172.16.2.0/26
ru
172.16.2.0/28
MSK
172.16.2.16/28
kzn
172.16.2.64/26
sp
172.16.2.64/28
bcn
172.16.2.80/28
mlg
172.16.2.128/26
cn
172.16.2.128/28
SHA
172.16.2.144/28
రెండు
172.16.8.0/21
ఆకు
172.16.8.0/23
ru
172.16.8.0/25
MSK
172.16.8.128/25
kzn
172.16.10.0/23
sp
172.16.10.0/25
bcn
172.16.10.128/25
mlg
172.16.12.0/23
cn
172.16.12.0/25
SHA
172.16.12.128/25
రెండు
అండర్లే:
ఉపసర్గ
ప్రాంతం
DC
10.0.0.0/17
ru
10.0.0.0/19
MSK
10.0.32.0/19
kzn
10.0.128.0/17
sp
10.0.128.0/19
bcn
10.0.160.0/19
mlg
10.1.0.0/17
cn
10.1.0.0/19
SHA
10.1.32.0/19
రెండు
లాబా
ఇద్దరు విక్రేతలు. ఒక నెట్‌వర్క్. ADSM.
జునిపెర్ + అరిస్టా. ఉబుంటు. మంచి పాత ఈవ్.
మిరానాలోని మా వర్చువల్ సర్వర్‌లోని వనరుల మొత్తం ఇప్పటికీ పరిమితంగానే ఉంది, కాబట్టి ప్రాక్టీస్ కోసం మేము పరిమితికి సరళీకృతం చేయబడిన నెట్‌వర్క్‌ని ఉపయోగిస్తాము.
రెండు డేటా కేంద్రాలు: కజాన్ మరియు బార్సిలోనా.
- ఒక్కొక్కటి రెండు వెన్నుముకలు: జునిపెర్ మరియు అరిస్టా.
- ప్రతిదానిలో ఒక టోరస్ (లీఫ్) - జునిపెర్ మరియు అరిస్టా, ఒక కనెక్ట్ చేయబడిన హోస్ట్‌తో (దీని కోసం తేలికైన సిస్కో IOLని తీసుకుందాం).
- ఒక్కొక్క ఎడ్జ్-లీఫ్ నోడ్ (ప్రస్తుతానికి జునిపెర్ మాత్రమే).
- వాటన్నింటినీ పాలించడానికి ఒక సిస్కో స్విచ్.
- నెట్‌వర్క్ బాక్స్‌లతో పాటు, వర్చువల్ కంట్రోల్ మెషీన్ నడుస్తోంది. ఉబుంటును నడుపుతోంది.
ఇది అన్ని పరికరాలకు ప్రాప్యతను కలిగి ఉంది, ఇది IPAM/DCIM సిస్టమ్‌లు, పైథాన్ స్క్రిప్ట్‌ల సమూహం, Ansible మరియు మనకు అవసరమయ్యే ఏదైనా అమలు చేస్తుంది.
అన్ని నెట్‌వర్క్ పరికరాలలో, మేము ఆటోమేషన్ ఉపయోగించి పునరుత్పత్తి చేయడానికి ప్రయత్నిస్తాము.
తీర్మానం
అది కూడా అంగీకరించబడిందా? నేను ప్రతి వ్యాసం క్రింద ఒక చిన్న ముగింపు వ్రాయాలా?
కాబట్టి మేము ఎంచుకున్నాము DC లోపల క్లోజ్ నెట్‌వర్క్, మేము చాలా తూర్పు-పశ్చిమ ట్రాఫిక్‌ని ఆశిస్తున్నాము మరియు ECMPని కోరుకుంటున్నాము.
నెట్‌వర్క్ భౌతిక (అండర్లే) మరియు వర్చువల్ (ఓవర్‌లే)గా విభజించబడింది. అదే సమయంలో, అతివ్యాప్తి హోస్ట్ నుండి ప్రారంభమవుతుంది - తద్వారా అండర్లే కోసం అవసరాలను సులభతరం చేస్తుంది.
నెట్‌వర్క్ నెట్‌వర్క్‌ల స్కేలబిలిటీ మరియు పాలసీ ఫ్లెక్సిబిలిటీ కోసం మేము BGPని రూటింగ్ ప్రోటోకాల్‌గా ఎంచుకున్నాము.
DCI - ఎడ్జ్-లీఫ్‌ని నిర్వహించడానికి మాకు ప్రత్యేక నోడ్‌లు ఉంటాయి.
వెన్నెముక OSPF+LDPని కలిగి ఉంటుంది.
MPLS L3VPN ఆధారంగా DCI అమలు చేయబడుతుంది.
P2P లింక్‌ల కోసం, మేము పరికర పేర్ల ఆధారంగా IP చిరునామాలను అల్గారిథమిక్‌గా గణిస్తాము.
మేము పరికరాల పాత్ర మరియు వాటి స్థానాన్ని వరుసగా లూప్‌బ్యాక్‌లను కేటాయిస్తాము.
అండర్లే ప్రిఫిక్స్‌లు - లీఫ్ స్విచ్‌లపై మాత్రమే సీక్వెన్షియల్‌గా వాటి స్థానం ఆధారంగా.
ప్రస్తుతం మన దగ్గర ఇంకా పరికరాలు ఇన్‌స్టాల్ చేయబడలేదని అనుకుందాం.
కాబట్టి, మా తదుపరి దశలు వాటిని సిస్టమ్‌లకు (IPAM, ఇన్వెంటరీ) జోడించడం, యాక్సెస్‌ని నిర్వహించడం, కాన్ఫిగరేషన్‌ను రూపొందించడం మరియు దానిని అమలు చేయడం.
తదుపరి కథనంలో మేము నెట్‌బాక్స్‌తో వ్యవహరిస్తాము - DCలో IP స్థలం కోసం జాబితా మరియు నిర్వహణ వ్యవస్థ.
ధన్యవాదాలు
- ప్రూఫ్ రీడింగ్ మరియు దిద్దుబాట్ల కోసం ఆండ్రీ గ్లాజ్‌కోవ్ అకా @glazgoo
- ప్రూఫ్ రీడింగ్ మరియు సవరణల కోసం అలెగ్జాండర్ క్లిమెన్కో అకా @v00lk
- KDPV కోసం ఆర్టియోమ్ చెర్నోబే
మూలం: www.habr.com