క్లౌడ్ కంప్యూటింగ్ మన జీవితాల్లోకి మరింత లోతుగా చొచ్చుకుపోతుంది మరియు కనీసం ఒక్కసారైనా క్లౌడ్ సేవలను ఉపయోగించని ఒక్క వ్యక్తి కూడా ఉండకపోవచ్చు. అయితే, క్లౌడ్ అంటే ఏమిటి మరియు అది ఎలా పని చేస్తుందో, ఆలోచన స్థాయిలో కూడా కొంతమందికి తెలుసు. 5G ఇప్పటికే రియాలిటీగా మారుతోంది మరియు టెలికాం ఇన్‌ఫ్రాస్ట్రక్చర్ పూర్తిగా హార్డ్‌వేర్ సొల్యూషన్‌ల నుండి వర్చువలైజ్డ్ “స్తంభాల”కి మారినప్పుడు చేసినట్లే, పిల్లర్ సొల్యూషన్‌ల నుండి క్లౌడ్ సొల్యూషన్‌లకు మారడం ప్రారంభించింది.
ఈ రోజు మనం క్లౌడ్ ఇన్‌ఫ్రాస్ట్రక్చర్ యొక్క అంతర్గత ప్రపంచం గురించి మాట్లాడుతాము, ప్రత్యేకించి మేము నెట్వర్క్ భాగం యొక్క ప్రాథమికాలను పరిశీలిస్తాము.
మేఘం అంటే ఏమిటి? అదే వర్చువలైజేషన్ - ప్రొఫైల్ వీక్షణ?
తార్కిక ప్రశ్న కంటే ఎక్కువ. లేదు - ఇది వర్చువలైజేషన్ కాదు, అయినప్పటికీ అది లేకుండా చేయలేము. రెండు నిర్వచనాలను చూద్దాం:
క్లౌడ్ కంప్యూటింగ్ (ఇకపై క్లౌడ్‌గా సూచిస్తారు) పంపిణీ చేయబడిన కంప్యూటింగ్ వనరులకు వినియోగదారు-స్నేహపూర్వక ప్రాప్యతను అందించడానికి ఒక నమూనా, ఇది సేవా ప్రదాతకి సాధ్యమైనంత తక్కువ జాప్యం మరియు కనీస ధరతో డిమాండ్‌పై అమలు చేయబడాలి మరియు ప్రారంభించబడాలి.
వర్చువలైజేషన్ - ఇది ఒక భౌతిక ఎంటిటీని (ఉదాహరణకు, సర్వర్) అనేక వర్చువల్‌గా విభజించే సామర్ధ్యం, తద్వారా వనరుల వినియోగాన్ని పెంచుతుంది (ఉదాహరణకు, మీరు 3 సర్వర్‌లను 25-30 శాతంతో లోడ్ చేసారు, వర్చువలైజేషన్ తర్వాత మీకు 1 సర్వర్ లోడ్ అవుతుంది. 80-90 శాతం వద్ద). సహజంగానే, వర్చువలైజేషన్ కొన్ని వనరులను తింటుంది - మీరు హైపర్‌వైజర్‌కు ఆహారం ఇవ్వాలి, అయితే, అభ్యాసం చూపినట్లుగా, ఆట కొవ్వొత్తికి విలువైనది. వర్చువలైజేషన్‌కు ఆదర్శవంతమైన ఉదాహరణ VMWare, ఇది వర్చువల్ మిషన్లను సంపూర్ణంగా సిద్ధం చేస్తుంది లేదా ఉదాహరణకు KVM, నేను ఇష్టపడతాను, కానీ ఇది రుచికి సంబంధించిన విషయం.
మేము గ్రహించకుండానే వర్చువలైజేషన్‌ని ఉపయోగిస్తాము మరియు ఐరన్ రూటర్‌లు కూడా ఇప్పటికే వర్చువలైజేషన్‌ని ఉపయోగిస్తున్నాయి - ఉదాహరణకు, JunOS యొక్క తాజా వెర్షన్‌లో, ఆపరేటింగ్ సిస్టమ్ రియల్ టైమ్ Linux డిస్ట్రిబ్యూషన్ (Wind River 9) పైన వర్చువల్ మెషీన్‌గా ఇన్‌స్టాల్ చేయబడింది. కానీ వర్చువలైజేషన్ అనేది క్లౌడ్ కాదు, కానీ వర్చువలైజేషన్ లేకుండా క్లౌడ్ ఉనికిలో ఉండదు.
క్లౌడ్ నిర్మించబడిన బిల్డింగ్ బ్లాక్‌లలో వర్చువలైజేషన్ ఒకటి.
ఒక L2 డొమైన్‌లో అనేక హైపర్‌వైజర్‌లను సేకరించడం ద్వారా క్లౌడ్‌ను తయారు చేయడం, కొన్ని రకాల యాన్సిబుల్ ద్వారా vlanలను స్వయంచాలకంగా నమోదు చేయడం కోసం కొన్ని yaml ప్లేబుక్‌లను జోడించడం మరియు స్వయంచాలకంగా వర్చువల్ మిషన్లను సృష్టించడం కోసం ఆర్కెస్ట్రేషన్ సిస్టమ్ వంటి వాటిని జామ్ చేయడం పని చేయదు. ఇది మరింత ఖచ్చితమైనది, కానీ ఫలితంగా ఫ్రాంకెన్‌స్టైయిన్ మనకు అవసరమైన క్లౌడ్ కాదు, అయితే ఇది ఇతరులకు అంతిమ కల కావచ్చు. అంతేకాకుండా, మీరు అదే ఓపెన్‌స్టాక్‌ని తీసుకుంటే, అది ఇప్పటికీ ఫ్రాంకెన్‌స్టైయిన్‌గా ఉంటుంది, అయితే సరే, దాని గురించి ఇప్పుడు మాట్లాడకు.
కానీ పైన అందించిన నిర్వచనం నుండి వాస్తవానికి క్లౌడ్ అని పిలవబడేది పూర్తిగా స్పష్టంగా లేదని నేను అర్థం చేసుకున్నాను.
కాబట్టి, NIST (నేషనల్ ఇన్‌స్టిట్యూట్ ఆఫ్ స్టాండర్డ్స్ అండ్ టెక్నాలజీ) నుండి ఒక పత్రం క్లౌడ్ ఇన్‌ఫ్రాస్ట్రక్చర్ కలిగి ఉండవలసిన 5 ప్రధాన లక్షణాలను అందిస్తుంది:
అభ్యర్థనపై సేవను అందించడం. వినియోగదారుకు అతనికి కేటాయించిన కంప్యూటర్ వనరులకు (నెట్‌వర్క్‌లు, వర్చువల్ డిస్క్‌లు, మెమరీ, ప్రాసెసర్ కోర్లు మొదలైనవి) ఉచితంగా యాక్సెస్ ఇవ్వాలి మరియు ఈ వనరులు తప్పనిసరిగా స్వయంచాలకంగా అందించబడాలి - అంటే, సర్వీస్ ప్రొవైడర్ జోక్యం లేకుండా.
సేవ యొక్క విస్తృత లభ్యత. ప్రామాణిక PCలు మరియు సన్నని క్లయింట్లు మరియు మొబైల్ పరికరాల వినియోగాన్ని అనుమతించడానికి ప్రామాణిక యంత్రాంగాల ద్వారా వనరులకు ప్రాప్యత తప్పనిసరిగా అందించబడాలి.
వనరులను కొలనులుగా కలపడం. రిసోర్స్ పూల్స్ తప్పనిసరిగా ఒకే సమయంలో బహుళ క్లయింట్‌లకు వనరులను అందించగలగాలి, క్లయింట్లు ఒంటరిగా మరియు పరస్పర ప్రభావం మరియు వనరుల కోసం పోటీ లేకుండా ఉండేలా చూసుకోవాలి. నెట్‌వర్క్‌లు కూడా పూల్స్‌లో చేర్చబడ్డాయి, ఇది అతివ్యాప్తి చెందుతున్న చిరునామాను ఉపయోగించే అవకాశాన్ని సూచిస్తుంది. కొలనులు తప్పనిసరిగా డిమాండ్‌పై స్కేల్ చేయగలగాలి. కొలనుల ఉపయోగం అవసరమైన స్థాయి వనరుల తప్పును తట్టుకోవడం మరియు భౌతిక మరియు వర్చువల్ వనరుల సంగ్రహణను అందించడం సాధ్యం చేస్తుంది - సేవ యొక్క గ్రహీత అతను అభ్యర్థించిన వనరుల సమితితో అందించబడుతుంది (ఈ వనరులు భౌతికంగా ఎక్కడ ఉన్నాయి, ఎన్ని ఉన్నాయి సర్వర్లు మరియు స్విచ్‌లు - ఇది క్లయింట్‌కు పట్టింపు లేదు). అయితే, ప్రొవైడర్ ఈ వనరుల పారదర్శక రిజర్వేషన్‌ను నిర్ధారించాలి అనే వాస్తవాన్ని మేము తప్పనిసరిగా పరిగణనలోకి తీసుకోవాలి.
వివిధ పరిస్థితులకు త్వరిత అనుసరణ. సేవలు అనువైనవిగా ఉండాలి - వనరులను వేగంగా అందించడం, వాటి పునఃపంపిణీ, క్లయింట్ అభ్యర్థన మేరకు వనరులను జోడించడం లేదా తగ్గించడం మరియు క్లౌడ్ వనరులు అంతులేనివని క్లయింట్ యొక్క భావం ఉండాలి. అర్థం చేసుకునే సౌలభ్యం కోసం, ఉదాహరణకు, సర్వర్‌లోని హార్డ్ డ్రైవ్ విరిగిపోయినందున Apple iCloudలో మీ డిస్క్ స్థలంలో కొంత భాగం కనిపించకుండా పోయిందని మరియు డ్రైవ్‌లు విచ్ఛిన్నమవుతాయని మీకు హెచ్చరిక కనిపించదు. అదనంగా, మీ వంతుగా, ఈ సేవ యొక్క అవకాశాలు దాదాపు అపరిమితంగా ఉంటాయి - మీకు 2 TB అవసరం - సమస్య లేదు, మీరు చెల్లించి స్వీకరించారు. ఇలాంటి ఉదాహరణ Google.Drive లేదా Yandex.Diskతో ఇవ్వవచ్చు.
అందించిన సేవను కొలిచే అవకాశం. క్లౌడ్ సిస్టమ్‌లు తప్పనిసరిగా వినియోగించబడే వనరులను స్వయంచాలకంగా నియంత్రించాలి మరియు ఆప్టిమైజ్ చేయాలి మరియు ఈ మెకానిజమ్‌లు తప్పనిసరిగా వినియోగదారు మరియు సేవా ప్రదాత ఇద్దరికీ పారదర్శకంగా ఉండాలి. అంటే, మీరు మరియు మీ క్లయింట్లు ఎన్ని వనరులను వినియోగిస్తున్నారో మీరు ఎల్లప్పుడూ తనిఖీ చేయవచ్చు.
ఈ అవసరాలు ఎక్కువగా పబ్లిక్ క్లౌడ్‌కు అవసరమనే వాస్తవాన్ని పరిగణనలోకి తీసుకోవడం విలువ, కాబట్టి ప్రైవేట్ క్లౌడ్ కోసం (అనగా, కంపెనీ అంతర్గత అవసరాల కోసం ప్రారంభించబడిన క్లౌడ్), ఈ అవసరాలు కొద్దిగా సర్దుబాటు చేయబడతాయి. అయినప్పటికీ, అవి ఇంకా పూర్తి కావాలి, లేకపోతే క్లౌడ్ కంప్యూటింగ్ యొక్క అన్ని ప్రయోజనాలను మనం పొందలేము.
మనకు మేఘం ఎందుకు అవసరం?
అయితే, ఏదైనా కొత్త లేదా ఇప్పటికే ఉన్న సాంకేతికత, ఏదైనా కొత్త ప్రోటోకాల్ ఏదైనా దాని కోసం సృష్టించబడుతుంది (అలాగే, RIP-ng మినహా, కోర్సు). ప్రోటోకాల్ కోసం ఎవరికీ ప్రోటోకాల్ అవసరం లేదు (అలాగే, RIP-ng మినహా, కోర్సు). వినియోగదారు/క్లయింట్‌కు ఒక రకమైన సేవను అందించడానికి క్లౌడ్ సృష్టించబడిందనేది తార్కికం. మనందరికీ కనీసం కొన్ని క్లౌడ్ సేవల గురించి తెలుసు, ఉదాహరణకు డ్రాప్‌బాక్స్ లేదా Google.Docs, మరియు చాలా మంది వ్యక్తులు వాటిని విజయవంతంగా ఉపయోగిస్తున్నారని నేను నమ్ముతున్నాను - ఉదాహరణకు, ఈ కథనం Google.Docs క్లౌడ్ సేవను ఉపయోగించి వ్రాయబడింది. కానీ మనకు తెలిసిన క్లౌడ్ సేవలు క్లౌడ్ యొక్క సామర్థ్యాలలో ఒక భాగం మాత్రమే-మరింత ఖచ్చితంగా, అవి SaaS-రకం సేవ మాత్రమే. మేము క్లౌడ్ సేవను మూడు మార్గాల్లో అందించగలము: SaaS, PaaS లేదా IaaS రూపంలో. మీకు ఏ సేవ అవసరం అనేది మీ కోరికలు మరియు సామర్థ్యాలపై ఆధారపడి ఉంటుంది.
ప్రతి ఒక్కటి క్రమంలో చూద్దాం:
సాఫ్ట్‌వేర్ ఒక సేవ (సాస్) క్లయింట్‌కు పూర్తి స్థాయి సేవను అందించడానికి ఒక నమూనా, ఉదాహరణకు, Yandex.Mail లేదా Gmail వంటి ఇమెయిల్ సేవ. ఈ సర్వీస్ డెలివరీ మోడల్‌లో, మీరు క్లయింట్‌గా, వాస్తవానికి సేవలను ఉపయోగించడం తప్ప ఏమీ చేయరు - అంటే, మీరు సేవను సెటప్ చేయడం, దాని తప్పు సహనం లేదా రిడెండెన్సీ గురించి ఆలోచించాల్సిన అవసరం లేదు. ప్రధాన విషయం ఏమిటంటే మీ పాస్‌వర్డ్‌తో రాజీ పడకూడదు; ఈ సేవ యొక్క ప్రొవైడర్ మీ కోసం మిగిలిన వాటిని చేస్తారు. సర్వర్ హార్డ్‌వేర్ మరియు హోస్ట్ ఆపరేటింగ్ సిస్టమ్‌ల నుండి డేటాబేస్ మరియు సాఫ్ట్‌వేర్ సెట్టింగ్‌ల వరకు - సర్వీస్ ప్రొవైడర్ దృక్కోణం నుండి, అతను మొత్తం సేవకు పూర్తి బాధ్యత వహిస్తాడు.
ప్లాట్‌ఫామ్ ఒక సేవ (PaaS) — ఈ మోడల్‌ను ఉపయోగిస్తున్నప్పుడు, సర్వీస్ ప్రొవైడర్ క్లయింట్‌కు సేవ కోసం వర్క్‌పీస్‌ను అందిస్తుంది, ఉదాహరణకు, వెబ్ సర్వర్‌ని తీసుకుందాం. సర్వీస్ ప్రొవైడర్ క్లయింట్‌కు వర్చువల్ సర్వర్‌ను అందించింది (వాస్తవానికి, RAM/CPU/స్టోరేజ్/నెట్స్ వంటి వనరుల సమితి), మరియు ఈ సర్వర్‌లో OS మరియు అవసరమైన సాఫ్ట్‌వేర్‌ను కూడా ఇన్‌స్టాల్ చేసింది, అయితే, కాన్ఫిగరేషన్ ఈ విషయాలన్నీ క్లయింట్ స్వయంగా చేస్తారు మరియు సేవ యొక్క పనితీరు కోసం క్లయింట్ సమాధానమిస్తారు. సేవా ప్రదాత, మునుపటి సందర్భంలో వలె, భౌతిక పరికరాలు, హైపర్‌వైజర్‌లు, వర్చువల్ మెషీన్, దాని నెట్వర్క్ లభ్యత మొదలైన వాటి పనితీరుకు బాధ్యత వహిస్తాడు, అయితే సేవ ఇకపై దాని బాధ్యత పరిధిలో ఉండదు.
ఒక సేవగా మౌలిక సదుపాయాలు (IaaS) - ఈ విధానం ఇప్పటికే మరింత ఆసక్తికరంగా ఉంది, వాస్తవానికి, సర్వీస్ ప్రొవైడర్ క్లయింట్‌కు పూర్తి వర్చువలైజ్డ్ ఇన్‌ఫ్రాస్ట్రక్చర్‌ని అందిస్తుంది - అంటే, CPU కోర్లు, RAM, నెట్‌వర్క్‌లు మొదలైన కొన్ని వనరుల (పూల్) సెట్. క్లయింట్ - క్లయింట్ కేటాయించిన పూల్ (కోటా) లోపల ఈ వనరులతో ఏమి చేయాలనుకుంటున్నారు - ఇది సరఫరాదారుకి ప్రత్యేకించి ముఖ్యమైనది కాదు. క్లయింట్ తన స్వంత vEPCని సృష్టించాలనుకుంటున్నారా లేదా మినీ ఆపరేటర్‌ని సృష్టించి కమ్యూనికేషన్ సేవలను అందించాలనుకుంటున్నారా - ప్రశ్న లేదు - దీన్ని చేయండి. అటువంటి దృష్టాంతంలో, సేవా ప్రదాత వనరులు, వాటి తప్పు సహనం మరియు లభ్యత, అలాగే ఈ వనరులను పూల్ చేయడానికి మరియు వాటిని క్లయింట్‌కు ఏ సమయంలోనైనా వనరులను పెంచడానికి లేదా తగ్గించగల సామర్థ్యంతో అందుబాటులో ఉంచడానికి అనుమతించే OSకి బాధ్యత వహిస్తారు. క్లయింట్ యొక్క అభ్యర్థన మేరకు. క్లయింట్ సెల్ఫ్ సర్వీస్ పోర్టల్ మరియు కన్సోల్ ద్వారా అన్ని వర్చువల్ మెషీన్‌లు మరియు ఇతర టిన్సెల్‌లను స్వయంగా కాన్ఫిగర్ చేస్తాడు, ఇందులో నెట్‌వర్క్‌లను సెటప్ చేస్తుంది (బాహ్య నెట్‌వర్క్‌లు మినహా).
OpenStack అంటే ఏమిటి?
ఈ మూడు ఎంపికలలో, క్లౌడ్ ఇన్‌ఫ్రాస్ట్రక్చర్‌ను రూపొందించడాన్ని ప్రారంభించే OS సర్వీస్ ప్రొవైడర్‌కు అవసరం. వాస్తవానికి, SaaSతో, ఒకటి కంటే ఎక్కువ విభాగాలు మొత్తం టెక్నాలజీల స్టాక్‌కు బాధ్యత వహిస్తాయి - మౌలిక సదుపాయాలకు బాధ్యత వహించే ఒక విభాగం ఉంది - అంటే, ఇది మరొక విభాగానికి IaaSని అందిస్తుంది, ఈ విభాగం క్లయింట్‌కు SaaSని అందిస్తుంది. ఓపెన్స్టాక్ క్లౌడ్ ఆపరేటింగ్ సిస్టమ్‌లలో ఒకటి, ఇది స్విచ్‌లు, సర్వర్లు మరియు నిల్వ సిస్టమ్‌ల సమూహాన్ని ఒకే రిసోర్స్ పూల్‌గా సేకరించడానికి మిమ్మల్ని అనుమతిస్తుంది, ఈ సాధారణ పూల్‌ను సబ్‌పూల్‌లుగా (అద్దెదారులు) విభజించి, నెట్వర్క్ ద్వారా క్లయింట్‌లకు ఈ వనరులను అందిస్తుంది.
ఓపెన్స్టాక్ ఒక క్లౌడ్ ఆపరేటింగ్ సిస్టమ్, ఇది కంప్యూటింగ్ వనరులు, డేటా నిల్వ మరియు నెట్వర్క్ వనరుల యొక్క పెద్ద కొలనులను నియంత్రించడానికి మిమ్మల్ని అనుమతిస్తుంది, ఇది ప్రామాణిక ప్రమాణీకరణ విధానాలను ఉపయోగించి API ద్వారా అందించబడుతుంది మరియు నిర్వహించబడుతుంది.
మరో మాటలో చెప్పాలంటే, ఇది క్లౌడ్ సేవలను (పబ్లిక్ మరియు ప్రైవేట్ రెండూ) సృష్టించడానికి రూపొందించబడిన ఉచిత సాఫ్ట్‌వేర్ ప్రాజెక్ట్‌ల సముదాయం - అంటే, సర్వర్ మరియు పరికరాలను ఒకే వనరులలో కలపడానికి, నిర్వహించడానికి మిమ్మల్ని అనుమతించే సాధనాల సమితి ఈ వనరులు, తప్పు సహనం యొక్క అవసరమైన స్థాయిని అందిస్తాయి.
ఈ విషయాన్ని వ్రాసే సమయంలో, OpenStack నిర్మాణం ఇలా కనిపిస్తుంది:
నుండి తీసిన చిత్రం
OpenStackలో చేర్చబడిన ప్రతి భాగాలు ఒక నిర్దిష్ట విధిని నిర్వహిస్తాయి. ఈ పంపిణీ చేయబడిన నిర్మాణం మీకు అవసరమైన ఫంక్షనల్ భాగాల సమితిని పరిష్కారంలో చేర్చడానికి మిమ్మల్ని అనుమతిస్తుంది. అయినప్పటికీ, కొన్ని భాగాలు మూల భాగాలు మరియు వాటి తొలగింపు మొత్తం పరిష్కారం యొక్క పూర్తి లేదా పాక్షిక అసమర్థతకు దారి తీస్తుంది. ఈ భాగాలు సాధారణంగా వర్గీకరించబడతాయి:
- డాష్బోర్డ్ — OpenStack సేవలను నిర్వహించడానికి వెబ్ ఆధారిత GUI
- కీస్టోన్ ఇతర సేవలకు ప్రమాణీకరణ మరియు అధికార కార్యాచరణను అందించే కేంద్రీకృత గుర్తింపు సేవ, అలాగే వినియోగదారు ఆధారాలు మరియు వారి పాత్రలను నిర్వహించడం.
- న్యూట్రాన్ - వివిధ ఓపెన్స్టాక్ సేవల ఇంటర్‌ఫేస్‌ల మధ్య కనెక్టివిటీని అందించే నెట్వర్క్ సేవ (VMల మధ్య కనెక్టివిటీ మరియు బయటి ప్రపంచానికి వాటి యాక్సెస్‌తో సహా)
- కాష్ట — వర్చువల్ మెషీన్ల కోసం బ్లాక్ స్టోరేజ్ యాక్సెస్‌ను అందిస్తుంది
- నోవా - వర్చువల్ మిషన్ల జీవిత చక్ర నిర్వహణ
- గ్లాన్స్ — వర్చువల్ మెషిన్ ఇమేజ్‌లు మరియు స్నాప్‌షాట్‌ల రిపోజిటరీ
- స్విఫ్ట్ — నిల్వ వస్తువుకు యాక్సెస్ అందిస్తుంది
- సీలోమీటర్ — టెలిమెట్రీని సేకరించి అందుబాటులో ఉన్న మరియు వినియోగించే వనరులను కొలవగల సామర్థ్యాన్ని అందించే సేవ
- వేడి — స్వయంచాలక సృష్టి మరియు వనరులను అందించడం కోసం టెంప్లేట్‌ల ఆధారంగా ఆర్కెస్ట్రేషన్
అన్ని ప్రాజెక్ట్‌ల పూర్తి జాబితా మరియు వాటి ప్రయోజనం చూడవచ్చు .
ప్రతి ఓపెన్స్టాక్ కాంపోనెంట్ అనేది ఒక నిర్దిష్ట విధిని నిర్వహించే ఒక సేవ మరియు ఆ ఫంక్షన్‌ని నిర్వహించడానికి మరియు ఇతర క్లౌడ్ ఆపరేటింగ్ సిస్టమ్ సేవలతో పరస్పరం సంకర్షణ చెందడానికి ఏకీకృత అవస్థాపనను రూపొందించడానికి APIని అందిస్తుంది. ఉదాహరణకు, నోవా కంప్యూటింగ్ రిసోర్స్ మేనేజ్‌మెంట్ మరియు ఈ వనరులను కాన్ఫిగర్ చేయడానికి యాక్సెస్ కోసం APIని అందిస్తుంది, గ్లాన్స్ ఇమేజ్ మేనేజ్‌మెంట్ మరియు వాటిని నిర్వహించడానికి APIని అందిస్తుంది, Cinder బ్లాక్ స్టోరేజ్ మరియు దానిని నిర్వహించడానికి APIని అందిస్తుంది. అన్ని విధులు చాలా దగ్గరి మార్గంలో పరస్పరం అనుసంధానించబడి ఉంటాయి.
అయితే, మీరు దానిని చూస్తే, ఓపెన్‌స్టాక్‌లో నడుస్తున్న అన్ని సేవలు అంతిమంగా నెట్‌వర్క్‌కు కనెక్ట్ చేయబడిన ఒక రకమైన వర్చువల్ మెషీన్ (లేదా కంటైనర్). ప్రశ్న తలెత్తుతుంది - మనకు చాలా అంశాలు ఎందుకు అవసరం?
వర్చువల్ మెషీన్‌ను సృష్టించడం మరియు ఓపెన్‌స్టాక్‌లో నెట్వర్క్ మరియు నిరంతర నిల్వకు కనెక్ట్ చేయడం కోసం అల్గోరిథం ద్వారా వెళ్దాం.
- మీరు యంత్రాన్ని సృష్టించడానికి ఒక అభ్యర్థనను సృష్టించినప్పుడు, అది హారిజోన్ (డ్యాష్‌బోర్డ్) ద్వారా అభ్యర్థన లేదా CLI ద్వారా అభ్యర్థన కావచ్చు, కీస్టోన్‌పై మీ అభ్యర్థనకు అధికారం ఇవ్వడం మొదటి విషయం - మీరు యంత్రాన్ని సృష్టించగలరా, అది ఉందా ఈ నెట్‌వర్క్‌ని ఉపయోగించే హక్కు, మీ డ్రాఫ్ట్ కోటా, మొదలైనవి.
- కీస్టోన్ మీ అభ్యర్థనను ధృవీకరిస్తుంది మరియు ప్రతిస్పందన సందేశంలో ప్రామాణీకరణ టోకెన్‌ను రూపొందిస్తుంది, అది తదుపరి ఉపయోగించబడుతుంది. కీస్టోన్ నుండి ప్రతిస్పందనను స్వీకరించిన తర్వాత, అభ్యర్థన నోవా (nova api) వైపు పంపబడుతుంది.
- Nova-api మునుపు రూపొందించిన ప్రామాణీకరణ టోకెన్‌ని ఉపయోగించి కీస్టోన్‌ను సంప్రదించడం ద్వారా మీ అభ్యర్థన యొక్క చెల్లుబాటును తనిఖీ చేస్తుంది
- కీస్టోన్ ప్రామాణీకరణను నిర్వహిస్తుంది మరియు ఈ ప్రామాణీకరణ టోకెన్ ఆధారంగా అనుమతులు మరియు పరిమితులపై సమాచారాన్ని అందిస్తుంది.
- Nova-api nova-డేటాబేస్‌లో కొత్త VM కోసం ఎంట్రీని సృష్టిస్తుంది మరియు మెషీన్‌ను సృష్టించడానికి అభ్యర్థనను nova-షెడ్యూలర్‌కు పంపుతుంది.
- Nova-షెడ్యూలర్ పేర్కొన్న పారామితులు, బరువులు మరియు జోన్‌ల ఆధారంగా VM అమలు చేయబడే హోస్ట్ (కంప్యూటర్ నోడ్)ని ఎంచుకుంటుంది. దీని యొక్క రికార్డ్ మరియు VM ID నోవా-డేటాబేస్‌కు వ్రాయబడ్డాయి.
- తర్వాత, నోవా-షెడ్యూలర్ నోవా-కంప్యూట్‌ను ఇన్‌స్టెన్స్‌ని అమలు చేయమని అభ్యర్థనతో సంప్రదిస్తుంది. నోవా-కంప్యూట్ నోవా-కండక్టర్‌ని సంప్రదిస్తూ మెషిన్ పారామీటర్‌ల గురించి సమాచారాన్ని పొందడం కోసం (నోవా-కండక్టర్ అనేది నోవా-డేటాబేస్ మరియు నోవా-కంప్యూట్ మధ్య ప్రాక్సీ సర్వర్‌గా పనిచేసే నోవా ఎలిమెంట్, డేటాబేస్‌తో సమస్యలను నివారించడానికి నోవా-డేటాబేస్‌కు అభ్యర్థనల సంఖ్యను పరిమితం చేస్తుంది. స్థిరత్వం లోడ్ తగ్గింపు).
- Nova-కండక్టర్ అభ్యర్థించిన సమాచారాన్ని nova-డేటాబేస్ నుండి స్వీకరిస్తుంది మరియు దానిని nova-computeకి పంపుతుంది.
- తరువాత, చిత్రం IDని పొందడానికి నోవా-కంప్యూట్ గ్లాన్స్ కాల్స్. గ్లేస్ కీస్టోన్‌లో అభ్యర్థనను ధృవీకరిస్తుంది మరియు అభ్యర్థించిన సమాచారాన్ని అందిస్తుంది.
- నెట్వర్క్ పారామితుల గురించి సమాచారాన్ని పొందేందుకు నోవా-కంప్యూట్ కాంటాక్ట్స్ న్యూట్రాన్. గ్లాన్స్ మాదిరిగానే, న్యూట్రాన్ కీస్టోన్‌లోని అభ్యర్థనను ధృవీకరిస్తుంది, ఆ తర్వాత అది డేటాబేస్ (పోర్ట్ ఐడెంటిఫైయర్, మొదలైనవి)లో ఎంట్రీని సృష్టిస్తుంది, పోర్ట్‌ను సృష్టించడానికి అభ్యర్థనను సృష్టిస్తుంది మరియు అభ్యర్థించిన సమాచారాన్ని నోవా-కంప్యూట్‌కి అందిస్తుంది.
- వర్చువల్ మెషీన్‌కు వాల్యూమ్‌ను కేటాయించాలనే అభ్యర్థనతో నోవా-కంప్యూట్ కాంటాక్ట్స్ సిండర్. గ్లాన్స్ మాదిరిగానే, పళ్లరసం కీస్టోన్‌లోని అభ్యర్థనను ధృవీకరిస్తుంది, వాల్యూమ్ సృష్టి అభ్యర్థనను సృష్టిస్తుంది మరియు అభ్యర్థించిన సమాచారాన్ని అందిస్తుంది.
- Nova-compute కాంటాక్ట్స్ libvirt పేర్కొన్న పారామితులతో వర్చువల్ మిషన్‌ని అమలు చేయమని అభ్యర్థనతో.
వాస్తవానికి, ఒక సాధారణ వర్చువల్ మెషీన్‌ను సృష్టించే సాధారణ ఆపరేషన్ క్లౌడ్ ప్లాట్‌ఫారమ్ యొక్క మూలకాల మధ్య API కాల్‌ల సుడిగుండంగా మారుతుంది. అంతేకాకుండా, మీరు చూడగలిగినట్లుగా, గతంలో నియమించబడిన సేవలు కూడా పరస్పర చర్య జరిగే చిన్న భాగాలను కలిగి ఉంటాయి. యంత్రాన్ని సృష్టించడం అనేది క్లౌడ్ ప్లాట్‌ఫారమ్ మిమ్మల్ని అనుమతించే దానిలో ఒక చిన్న భాగం మాత్రమే - ట్రాఫిక్‌ను సమతుల్యం చేయడానికి బాధ్యత వహించే సేవ, బ్లాక్ నిల్వకు బాధ్యత వహించే సేవ, DNSకి బాధ్యత వహించే సేవ, బేర్ మెటల్ సర్వర్‌లను అందించడానికి బాధ్యత వహించే సేవ మొదలైనవి ఉన్నాయి. క్లౌడ్ మీ వర్చువల్ మెషీన్‌లను గొర్రెల మందలా (వర్చువలైజేషన్‌కు విరుద్ధంగా) పరిగణించేలా మిమ్మల్ని అనుమతిస్తుంది. వర్చువల్ వాతావరణంలో మీ మెషీన్‌కు ఏదైనా జరిగితే - మీరు దానిని బ్యాకప్‌లు మొదలైన వాటి నుండి పునరుద్ధరించండి, కానీ క్లౌడ్ అప్లికేషన్‌లు వర్చువల్ మెషీన్ అంత ముఖ్యమైన పాత్ర పోషించని విధంగా నిర్మించబడ్డాయి - వర్చువల్ మెషీన్ “డైడ్” - సమస్య లేదు. - కొత్తది ఇప్పుడే సృష్టించబడింది వాహనం టెంప్లేట్ ఆధారంగా రూపొందించబడింది మరియు వారు చెప్పినట్లు, స్క్వాడ్ ఫైటర్ యొక్క నష్టాన్ని గమనించలేదు. సహజంగానే, ఇది ఆర్కెస్ట్రేషన్ మెకానిజమ్‌ల ఉనికిని అందిస్తుంది - హీట్ టెంప్లేట్‌లను ఉపయోగించి, మీరు డజన్ల కొద్దీ నెట్‌వర్క్‌లు మరియు వర్చువల్ మెషీన్‌లతో కూడిన సంక్లిష్టమైన ఫంక్షన్‌ను సులభంగా అమలు చేయవచ్చు.
నెట్వర్క్ లేకుండా క్లౌడ్ ఇన్‌ఫ్రాస్ట్రక్చర్ లేదని గుర్తుంచుకోవడం ఎల్లప్పుడూ విలువైనదే - ప్రతి మూలకం ఒక విధంగా లేదా మరొకటి నెట్వర్క్ ద్వారా ఇతర అంశాలతో సంకర్షణ చెందుతుంది. అదనంగా, క్లౌడ్ ఖచ్చితంగా నాన్-స్టాటిక్ నెట్‌వర్క్‌ను కలిగి ఉంది. సహజంగానే, అండర్‌లే నెట్వర్క్ మరింత ఎక్కువ లేదా తక్కువ స్థిరంగా ఉంటుంది - ప్రతిరోజూ కొత్త నోడ్‌లు మరియు స్విచ్‌లు జోడించబడవు, కానీ ఓవర్‌లే భాగం నిరంతరం మారవచ్చు మరియు అనివార్యంగా మారుతుంది - కొత్త నెట్‌వర్క్‌లు జోడించబడతాయి లేదా తొలగించబడతాయి, కొత్త వర్చువల్ మిషన్లు కనిపిస్తాయి మరియు పాతవి కనిపిస్తాయి. చనిపోతారు. మరియు మీరు వ్యాసం ప్రారంభంలో ఇచ్చిన క్లౌడ్ యొక్క నిర్వచనం నుండి గుర్తుంచుకున్నట్లుగా, వనరులు వినియోగదారుకు స్వయంచాలకంగా మరియు సేవా ప్రదాత నుండి కనీసం (లేదా ఇంకా మెరుగైన, లేకుండా) జోక్యంతో కేటాయించబడాలి. అంటే, ఇప్పుడు http/https ద్వారా యాక్సెస్ చేయగల మీ వ్యక్తిగత ఖాతా రూపంలో ఫ్రంట్-ఎండ్ రూపంలో ఉన్న నెట్వర్క్ వనరులను అందించే రకం మరియు ఆన్-డ్యూటీ నెట్వర్క్ ఇంజనీర్ వాసిలీ బ్యాకెండ్‌గా క్లౌడ్ కాదు, కూడా వాసిలీకి ఎనిమిది చేతులు ఉంటే.
న్యూట్రాన్, నెట్వర్క్ సేవగా, క్లౌడ్ ఇన్‌ఫ్రాస్ట్రక్చర్ యొక్క నెట్వర్క్ భాగాన్ని నిర్వహించడానికి APIని అందిస్తుంది. Network-as-a-Service (NaaS) అనే సంగ్రహణ పొరను అందించడం ద్వారా సేవ Openstack యొక్క నెట్‌వర్కింగ్ భాగాన్ని శక్తివంతం చేస్తుంది మరియు నిర్వహిస్తుంది. అంటే, నెట్వర్క్ అదే వర్చువల్ కొలవగల యూనిట్, ఉదాహరణకు, వర్చువల్ CPU కోర్లు లేదా RAM మొత్తం.
కానీ ఓపెన్స్టాక్ యొక్క నెట్వర్క్ భాగం యొక్క నిర్మాణానికి వెళ్లే ముందు, ఈ నెట్వర్క్ ఓపెన్‌స్టాక్‌లో ఎలా పనిచేస్తుందో మరియు నెట్వర్క్ క్లౌడ్‌లో ఎందుకు ముఖ్యమైన మరియు అంతర్భాగంగా ఉందో పరిశీలిద్దాం.
కాబట్టి మాకు రెండు RED క్లయింట్ VMలు మరియు రెండు GREEN క్లయింట్ VMలు ఉన్నాయి. ఈ యంత్రాలు ఈ విధంగా రెండు హైపర్‌వైజర్‌లపై ఉన్నాయని అనుకుందాం:
ప్రస్తుతానికి, ఇది కేవలం 4 సర్వర్‌ల వర్చువలైజేషన్ మరియు మరేమీ లేదు, ఎందుకంటే ఇప్పటివరకు మేము చేసినదంతా 4 సర్వర్‌లను వర్చువలైజ్ చేసి, వాటిని రెండు ఫిజికల్ సర్వర్‌లలో ఉంచడం. మరియు ఇప్పటివరకు అవి నెట్‌వర్క్‌కు కూడా కనెక్ట్ కాలేదు.
క్లౌడ్ చేయడానికి, మేము అనేక భాగాలను జోడించాలి. ముందుగా, మేము నెట్వర్క్ భాగాన్ని వర్చువలైజ్ చేస్తాము - మేము ఈ 4 మెషీన్‌లను జతగా కనెక్ట్ చేయాలి మరియు క్లయింట్లు L2 కనెక్షన్‌ని కోరుకుంటారు. మీరు స్విచ్‌ని ఉపయోగించవచ్చు మరియు ట్రంక్‌ను దాని దిశలో కాన్ఫిగర్ చేయవచ్చు మరియు లైనక్స్ బ్రిడ్జ్‌ని ఉపయోగించి ప్రతిదీ పరిష్కరించవచ్చు లేదా మరింత అధునాతన వినియోగదారుల కోసం, openvswitch (మేము దీనికి తర్వాత తిరిగి వస్తాము). కానీ చాలా నెట్‌వర్క్‌లు ఉండవచ్చు మరియు నిరంతరం L2ని స్విచ్ ద్వారా నెట్టడం ఉత్తమ ఆలోచన కాదు - వివిధ విభాగాలు, సర్వీస్ డెస్క్, అప్లికేషన్ పూర్తయ్యే వరకు నెలలు వేచి ఉండటం, ట్రబుల్షూటింగ్ యొక్క వారాలు - ఆధునిక ప్రపంచంలో ఇది విధానం ఇకపై పనిచేయదు. మరియు ఒక సంస్థ దీనిని ఎంత త్వరగా అర్థం చేసుకుంటే, అది ముందుకు సాగడం సులభం. కాబట్టి, హైపర్‌వైజర్‌ల మధ్య మన వర్చువల్ మిషన్లు కమ్యూనికేట్ చేసే L3 నెట్‌వర్క్‌ని ఎంచుకుంటాము మరియు ఈ L3 నెట్వర్క్ పైన మన వర్చువల్ మెషీన్ల ట్రాఫిక్ రన్ అయ్యే వర్చువల్ L2 ఓవర్‌లే నెట్‌వర్క్‌లను నిర్మిస్తాము. మీరు GRE, Geneve లేదా VxLANని ఎన్‌క్యాప్సులేషన్‌గా ఉపయోగించవచ్చు. ఇది ప్రత్యేకించి ముఖ్యమైనది కానప్పటికీ, ప్రస్తుతానికి రెండవదానిపై దృష్టి పెడదాం.
మనం ఎక్కడో VTEPని గుర్తించాలి (ప్రతి ఒక్కరికీ VxLAN పరిభాషతో పరిచయం ఉందని నేను ఆశిస్తున్నాను). మేము సర్వర్‌ల నుండి నేరుగా వస్తున్న L3 నెట్‌వర్క్‌ను కలిగి ఉన్నందున, సర్వర్‌లలో VTEPని ఉంచకుండా ఏమీ నిరోధించదు మరియు OVS (OpenvSwitch) దీన్ని చేయడంలో అద్భుతమైనది. ఫలితంగా, మాకు ఈ డిజైన్ వచ్చింది:
VMల మధ్య ట్రాఫిక్ తప్పనిసరిగా విభజించబడాలి కాబట్టి, వర్చువల్ మిషన్ల వైపు పోర్ట్‌లు వేర్వేరు vlan నంబర్‌లను కలిగి ఉంటాయి. ట్యాగ్ నంబర్ ఒక వర్చువల్ స్విచ్‌లో మాత్రమే పాత్రను పోషిస్తుంది, ఎందుకంటే VxLANలో ఎన్‌క్యాప్సులేట్ చేసినప్పుడు మనం దానిని సులభంగా తీసివేయవచ్చు, ఎందుకంటే మనకు VNI ఉంటుంది.
ఇప్పుడు మన మెషీన్‌లు మరియు వాటి కోసం వర్చువల్ నెట్‌వర్క్‌లను ఎలాంటి సమస్యలు లేకుండా సృష్టించవచ్చు.
అయితే, క్లయింట్ మరొక యంత్రాన్ని కలిగి ఉంటే, కానీ వేరే నెట్‌వర్క్‌లో ఉంటే? మనకు నెట్‌వర్క్‌ల మధ్య రూటింగ్ అవసరం. కేంద్రీకృత రౌటింగ్ ఉపయోగించినప్పుడు మేము ఒక సాధారణ ఎంపికను పరిశీలిస్తాము - అంటే, ట్రాఫిక్ ప్రత్యేక అంకితమైన నెట్వర్క్ నోడ్‌ల ద్వారా మళ్లించబడుతుంది (అలాగే, ఒక నియమం వలె, అవి నియంత్రణ నోడ్‌లతో కలిపి ఉంటాయి, కాబట్టి మనకు అదే విషయం ఉంటుంది).
ఇది సంక్లిష్టంగా ఏమీ లేనట్లు అనిపిస్తుంది - మేము కంట్రోల్ నోడ్‌లో వంతెన ఇంటర్‌ఫేస్‌ను తయారు చేస్తాము, దానికి ట్రాఫిక్‌ని డ్రైవ్ చేస్తాము మరియు అక్కడ నుండి మనకు అవసరమైన చోటికి దారి తీస్తాము. కానీ సమస్య ఏమిటంటే RED క్లయింట్ 10.0.0.0/24 నెట్‌వర్క్‌ను ఉపయోగించాలనుకుంటోంది మరియు GREEN క్లయింట్ 10.0.0.0/24 నెట్‌వర్క్‌ను ఉపయోగించాలనుకుంటోంది. అంటే, మేము చిరునామా ఖాళీలను కలుస్తాము. అదనంగా, క్లయింట్లు ఇతర క్లయింట్లు తమ అంతర్గత నెట్‌వర్క్‌లలోకి వెళ్లాలని కోరుకోరు, ఇది అర్ధమే. నెట్‌వర్క్‌లు మరియు క్లయింట్ డేటా ట్రాఫిక్‌ను వేరు చేయడానికి, మేము వాటిలో ప్రతిదానికి ప్రత్యేక నేమ్‌స్పేస్‌ను కేటాయిస్తాము. నేమ్‌స్పేస్ నిజానికి Linux నెట్వర్క్ స్టాక్ యొక్క కాపీ, అంటే నేమ్‌స్పేస్ REDలోని క్లయింట్లు నేమ్‌స్పేస్ GREEN నుండి క్లయింట్‌ల నుండి పూర్తిగా వేరుచేయబడి ఉంటాయి (అలాగే, ఈ క్లయింట్ నెట్‌వర్క్‌ల మధ్య రూటింగ్ డిఫాల్ట్ నేమ్‌స్పేస్ ద్వారా లేదా అప్‌స్ట్రీమ్ ట్రాన్స్‌పోర్ట్ పరికరాలలో అనుమతించబడుతుంది).
అంటే, మేము ఈ క్రింది రేఖాచిత్రాన్ని పొందుతాము:
L2 సొరంగాలు అన్ని కంప్యూటింగ్ నోడ్‌ల నుండి కంట్రోల్ నోడ్‌కి కలుస్తాయి. ఈ నెట్‌వర్క్‌ల కోసం L3 ఇంటర్‌ఫేస్ ఉన్న నోడ్, ప్రతి ఒక్కటి ఐసోలేషన్ కోసం ప్రత్యేక నేమ్‌స్పేస్‌లో ఉంటుంది.
అయితే, మేము చాలా ముఖ్యమైన విషయం మరచిపోయాము. వర్చువల్ మెషీన్ తప్పనిసరిగా క్లయింట్‌కు సేవను అందించాలి, అంటే, అది చేరుకోగలిగేలా కనీసం ఒక బాహ్య ఇంటర్‌ఫేస్‌ని కలిగి ఉండాలి. అంటే మనం బయటి ప్రపంచంలోకి వెళ్లాలి. ఇక్కడ వివిధ ఎంపికలు ఉన్నాయి. సరళమైన ఎంపికను చేద్దాం. మేము ప్రతి క్లయింట్‌కు ఒక నెట్‌వర్క్‌ని జోడిస్తాము, ఇది ప్రొవైడర్ నెట్‌వర్క్‌లో చెల్లుబాటు అవుతుంది మరియు ఇతర నెట్‌వర్క్‌లతో అతివ్యాప్తి చెందదు. నెట్‌వర్క్‌లు కూడా కలుస్తాయి మరియు ప్రొవైడర్ నెట్వర్క్ వైపున ఉన్న విభిన్న VRFలను చూడవచ్చు. నెట్వర్క్ డేటా ప్రతి క్లయింట్ యొక్క నేమ్‌స్పేస్‌లో కూడా ఉంటుంది. అయినప్పటికీ, వారు ఇప్పటికీ ఒక భౌతిక (లేదా బాండ్, ఇది మరింత తార్కికమైన) ఇంటర్‌ఫేస్ ద్వారా బయటి ప్రపంచానికి వెళతారు. క్లయింట్ ట్రాఫిక్‌ను వేరు చేయడానికి, బయట వెళ్లే ట్రాఫిక్ క్లయింట్‌కు కేటాయించిన VLAN ట్యాగ్‌తో ట్యాగ్ చేయబడుతుంది.
ఫలితంగా, మేము ఈ రేఖాచిత్రాన్ని పొందాము:
ఒక సహేతుకమైన ప్రశ్న ఏమిటంటే, కంప్యూట్ నోడ్‌లపై గేట్‌వేలను ఎందుకు తయారు చేయకూడదు? ఇది పెద్ద సమస్య కాదు; అంతేకాకుండా, మీరు పంపిణీ చేయబడిన రూటర్ (DVR) ను ఆన్ చేస్తే, ఇది పని చేస్తుంది. ఈ దృష్టాంతంలో, మేము కేంద్రీకృత గేట్‌వేతో సరళమైన ఎంపికను పరిశీలిస్తున్నాము, ఇది Openstackలో డిఫాల్ట్‌గా ఉపయోగించబడుతుంది. అధిక-లోడ్ ఫంక్షన్ల కోసం, వారు పంపిణీ చేయబడిన రూటర్ మరియు SR-IOV మరియు పాస్‌త్రూ వంటి యాక్సిలరేషన్ సాంకేతికతలను రెండింటినీ ఉపయోగిస్తారు, కానీ వారు చెప్పినట్లు, ఇది పూర్తిగా భిన్నమైన కథ. మొదట, ప్రాథమిక భాగంతో వ్యవహరిస్తాము, ఆపై మేము వివరాలలోకి వెళ్తాము.
వాస్తవానికి, మా పథకం ఇప్పటికే పని చేయగలదు, కానీ కొన్ని సూక్ష్మ నైపుణ్యాలు ఉన్నాయి:
- మేము మా మెషీన్‌లను ఎలాగైనా రక్షించుకోవాలి, అంటే క్లయింట్ వైపు స్విచ్ ఇంటర్‌ఫేస్‌లో ఫిల్టర్‌ను ఉంచాలి.
- వర్చువల్ మెషీన్ స్వయంచాలకంగా IP చిరునామాను పొందడాన్ని సాధ్యం చేయండి, తద్వారా మీరు ప్రతిసారీ కన్సోల్ ద్వారా లాగిన్ చేసి చిరునామాను నమోదు చేయవలసిన అవసరం లేదు.
యంత్ర రక్షణతో ప్రారంభిద్దాం. దీని కోసం మీరు సామాన్యమైన iptables ను ఉపయోగించవచ్చు, ఎందుకు కాదు.
అంటే, ఇప్పుడు మా టోపోలాజీ కొంచెం క్లిష్టంగా మారింది:
ముందుకు వెళ్దాం. మేము DHCP సర్వర్‌ని జోడించాలి. ప్రతి క్లయింట్ కోసం DHCP సర్వర్‌లను గుర్తించడానికి అత్యంత అనువైన ప్రదేశం పైన పేర్కొన్న నియంత్రణ నోడ్, ఇక్కడ నేమ్‌స్పేస్‌లు ఉన్నాయి:
అయితే, ఒక చిన్న సమస్య ఉంది. ప్రతిదీ రీబూట్ అయితే మరియు DHCPలో చిరునామాలను అద్దెకు తీసుకోవడం గురించి మొత్తం సమాచారం అదృశ్యమైతే. యంత్రాలకు కొత్త చిరునామాలు ఇవ్వబడటం తార్కికం, ఇది చాలా సౌకర్యవంతంగా లేదు. ఇక్కడ రెండు మార్గాలు ఉన్నాయి - డొమైన్ పేర్లను ఉపయోగించండి మరియు ప్రతి క్లయింట్ కోసం ఒక DNS సర్వర్‌ని జోడించండి, ఆపై చిరునామా మాకు ప్రత్యేకించి ముఖ్యమైనది కాదు (k8sలో నెట్వర్క్ భాగం వలె) - కానీ బాహ్య నెట్‌వర్క్‌లతో సమస్య ఉంది, ఎందుకంటే చిరునామాలను DHCP ద్వారా కూడా జారీ చేయవచ్చు - మీకు క్లౌడ్ ప్లాట్‌ఫారమ్‌లోని DNS సర్వర్‌లతో మరియు బాహ్య DNS సర్వర్‌తో సమకాలీకరణ అవసరం, ఇది నా అభిప్రాయం ప్రకారం చాలా సరళమైనది కాదు, కానీ చాలా సాధ్యమే. లేదా మెటాడేటాను ఉపయోగించడం రెండవ ఎంపిక - అంటే, మెషీన్‌కు జారీ చేయబడిన చిరునామా గురించి సమాచారాన్ని సేవ్ చేయండి, తద్వారా యంత్రం ఇప్పటికే చిరునామాను స్వీకరించినట్లయితే యంత్రానికి ఏ చిరునామాను జారీ చేయాలో DHCP సర్వర్‌కు తెలుస్తుంది. రెండవ ఎంపిక సరళమైనది మరియు మరింత సౌకర్యవంతమైనది, ఎందుకంటే ఇది కారు గురించి అదనపు సమాచారాన్ని సేవ్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది. ఇప్పుడు రేఖాచిత్రానికి ఏజెంట్ మెటాడేటాను యాడ్ చేద్దాం:
క్లయింట్‌లందరూ ఒక బాహ్య నెట్‌వర్క్‌ను ఉపయోగించగల సామర్థ్యం కూడా చర్చించదగిన మరొక సమస్య, ఎందుకంటే బాహ్య నెట్‌వర్క్‌లు, అవి మొత్తం నెట్‌వర్క్‌లో చెల్లుబాటు అయ్యేలా ఉంటే, కష్టంగా ఉంటుంది - మీరు ఈ నెట్‌వర్క్‌ల కేటాయింపును నిరంతరం కేటాయించాలి మరియు నియంత్రించాలి. పబ్లిక్ క్లౌడ్‌ను క్రియేట్ చేసేటప్పుడు క్లయింట్‌లందరికీ ఒకే బాహ్య ముందుగా కాన్ఫిగర్ చేయబడిన నెట్‌వర్క్‌ని ఉపయోగించగల సామర్థ్యం చాలా ఉపయోగకరంగా ఉంటుంది. ఇది మెషీన్‌లను అమలు చేయడాన్ని సులభతరం చేస్తుంది ఎందుకంటే మనం చిరునామా డేటాబేస్‌ని సంప్రదించాల్సిన అవసరం లేదు మరియు ప్రతి క్లయింట్ యొక్క బాహ్య నెట్వర్క్ కోసం ప్రత్యేకమైన చిరునామా స్థలాన్ని ఎంచుకోవాల్సిన అవసరం లేదు. అదనంగా, మేము ముందుగానే బాహ్య నెట్‌వర్క్‌ను నమోదు చేసుకోవచ్చు మరియు విస్తరణ సమయంలో మేము క్లయింట్ మెషీన్‌లతో బాహ్య చిరునామాలను మాత్రమే అనుబంధించవలసి ఉంటుంది.
మరియు ఇక్కడ NAT మా సహాయానికి వస్తుంది - NAT అనువాదాన్ని ఉపయోగించి డిఫాల్ట్ నేమ్‌స్పేస్ ద్వారా క్లయింట్లు బయటి ప్రపంచాన్ని యాక్సెస్ చేయడాన్ని మేము సాధ్యం చేస్తాము. సరే, ఇక్కడ ఒక చిన్న సమస్య ఉంది. క్లయింట్ సర్వర్ సర్వర్‌గా కాకుండా క్లయింట్‌గా వ్యవహరిస్తే ఇది మంచిది - అంటే, ఇది కనెక్షన్‌లను అంగీకరించకుండా ప్రారంభిస్తుంది. కానీ మనకు అది మరోలా ఉంటుంది. ఈ సందర్భంలో, మేము గమ్యం NATని చేయాలి, తద్వారా ట్రాఫిక్‌ని స్వీకరించినప్పుడు, కంట్రోల్ నోడ్ ఈ ట్రాఫిక్ క్లయింట్ A యొక్క వర్చువల్ మెషీన్ A కోసం ఉద్దేశించబడిందని అర్థం చేసుకుంటుంది, అంటే మనం బాహ్య చిరునామా నుండి NAT అనువాదం చేయాలి, ఉదాహరణకు 100.1.1.1 .10.0.0.1, అంతర్గత చిరునామాకు 100. ఈ సందర్భంలో, క్లయింట్‌లందరూ ఒకే నెట్‌వర్క్‌ని ఉపయోగిస్తున్నప్పటికీ, అంతర్గత ఐసోలేషన్ పూర్తిగా భద్రపరచబడుతుంది. అంటే, మనం కంట్రోల్ నోడ్‌లో dNAT మరియు sNAT చేయాలి. ఫ్లోటింగ్ అడ్రస్‌లు లేదా ఎక్స్‌టర్నల్ నెట్‌వర్క్‌లతో ఒకే నెట్‌వర్క్‌ని ఉపయోగించాలా లేదా రెండింటినీ ఒకేసారి ఉపయోగించాలా అనేది మీరు క్లౌడ్‌లోకి తీసుకురావాలనుకుంటున్న దానిపై ఆధారపడి ఉంటుంది. మేము రేఖాచిత్రానికి తేలియాడే చిరునామాలను జోడించము, కానీ ఇంతకు ముందు జోడించిన బాహ్య నెట్‌వర్క్‌లను వదిలివేస్తాము - ప్రతి క్లయింట్‌కు దాని స్వంత బాహ్య నెట్వర్క్ ఉంటుంది (రేఖాచిత్రంలో అవి బాహ్య ఇంటర్‌ఫేస్‌లో vlan 200 మరియు XNUMXగా సూచించబడ్డాయి).
ఫలితంగా, మేము ఒక ఆసక్తికరమైన మరియు అదే సమయంలో బాగా ఆలోచించిన పరిష్కారాన్ని అందుకున్నాము, ఇది నిర్దిష్ట సౌలభ్యాన్ని కలిగి ఉంది కానీ ఇంకా తప్పును సహించే విధానాలను కలిగి లేదు.
మొదట, మనకు ఒకే ఒక నియంత్రణ నోడ్ ఉంది - దాని వైఫల్యం అన్ని వ్యవస్థల పతనానికి దారి తీస్తుంది. ఈ సమస్యను పరిష్కరించడానికి, మీరు కనీసం 3 నోడ్‌ల కోరమ్‌ని తయారు చేయాలి. దీన్ని రేఖాచిత్రానికి జోడిద్దాం:
సహజంగానే, అన్ని నోడ్‌లు సమకాలీకరించబడతాయి మరియు యాక్టివ్ నోడ్ నిష్క్రమించినప్పుడు, మరొక నోడ్ దాని బాధ్యతలను తీసుకుంటుంది.
తదుపరి సమస్య వర్చువల్ మెషిన్ డిస్క్‌లు. ప్రస్తుతానికి, అవి హైపర్‌వైజర్‌లలోనే నిల్వ చేయబడతాయి మరియు హైపర్‌వైజర్‌తో సమస్యల విషయంలో, మేము మొత్తం డేటాను కోల్పోతాము - మరియు మేము డిస్క్‌ను కాకుండా మొత్తం సర్వర్‌ను కోల్పోతే రైడ్ ఉనికి ఇక్కడ సహాయపడదు. దీన్ని చేయడానికి, మేము ఒక రకమైన నిల్వ కోసం ఫ్రంట్ ఎండ్‌గా పనిచేసే సేవను తయారు చేయాలి. ఇది ఏ రకమైన నిల్వ అనేది మాకు ప్రత్యేకంగా ముఖ్యమైనది కాదు, కానీ ఇది డిస్క్ మరియు నోడ్ మరియు బహుశా మొత్తం క్యాబినెట్ రెండింటి వైఫల్యం నుండి మా డేటాను రక్షించాలి. ఇక్కడ అనేక ఎంపికలు ఉన్నాయి - వాస్తవానికి, ఫైబర్ ఛానెల్‌తో SAN నెట్‌వర్క్‌లు ఉన్నాయి, కానీ నిజాయితీగా ఉండండి - FC ఇప్పటికే గతానికి సంబంధించినది - రవాణాలో E1 యొక్క అనలాగ్ - అవును, నేను అంగీకరిస్తున్నాను, ఇది ఇప్పటికీ ఉపయోగించబడుతోంది, కానీ అది లేకుండా పూర్తిగా అసాధ్యం ఎక్కడ మాత్రమే. అందువల్ల, నేను 2020లో స్వచ్ఛందంగా FC నెట్‌వర్క్‌ని అమలు చేయను, ఇతర ఆసక్తికరమైన ప్రత్యామ్నాయాలు ఉన్నాయని తెలుసుకున్నాను. ప్రతి ఒక్కరికి తన స్వంతమైనప్పటికీ, FC దాని అన్ని పరిమితులతో మనకు కావాల్సిందల్లా నమ్మే వారు ఉండవచ్చు - నేను వాదించను, ప్రతి ఒక్కరికీ వారి స్వంత అభిప్రాయం ఉంటుంది. అయితే, నా అభిప్రాయంలో అత్యంత ఆసక్తికరమైన పరిష్కారం Ceph వంటి SDSని ఉపయోగించడం.
Ceph మీరు డిస్క్‌ల స్థానాన్ని పరిగణనలోకి తీసుకుని, వివిధ డిస్క్‌లకు పూర్తి డేటా రెప్లికేషన్‌తో ముగిసే (రైడ్ 5 లేదా 6కి సారూప్యంగా) సమాన తనిఖీతో కోడ్‌లతో ప్రారంభించి, సాధ్యమయ్యే బ్యాకప్ ఎంపికల సమూహంతో అత్యంత అందుబాటులో ఉన్న డేటా నిల్వ పరిష్కారాన్ని రూపొందించడానికి మిమ్మల్ని అనుమతిస్తుంది. సర్వర్లు, మరియు క్యాబినెట్లలోని సర్వర్లు మొదలైనవి.
Cephని నిర్మించడానికి మీకు మరో 3 నోడ్‌లు అవసరం. బ్లాక్, ఆబ్జెక్ట్ మరియు ఫైల్ స్టోరేజ్ సేవలను ఉపయోగించి నెట్వర్క్ ద్వారా నిల్వతో పరస్పర చర్య కూడా నిర్వహించబడుతుంది. స్కీమాకు నిల్వను జోడిద్దాం:
గమనిక: మీరు హైపర్‌కన్వర్జ్డ్ కంప్యూట్ నోడ్‌లను కూడా తయారు చేయవచ్చు - ఇది ఒక నోడ్‌పై అనేక ఫంక్షన్‌లను కలపడం అనే భావన - ఉదాహరణకు, నిల్వ+కంప్యూట్ - సెఫ్ నిల్వ కోసం ప్రత్యేక నోడ్‌లను కేటాయించకుండా. మేము అదే తప్పు-తట్టుకునే పథకాన్ని పొందుతాము - SDS మేము పేర్కొన్న రిజర్వేషన్ స్థాయితో డేటాను రిజర్వ్ చేస్తుంది కాబట్టి. అయినప్పటికీ, హైపర్‌కన్వర్జ్డ్ నోడ్‌లు ఎల్లప్పుడూ రాజీపడతాయి - నిల్వ నోడ్ మొదటి చూపులో కనిపించే విధంగా గాలిని వేడి చేయదు (దానిపై వర్చువల్ మెషీన్‌లు లేవు కాబట్టి) - ఇది SDS సర్వీసింగ్ కోసం CPU వనరులను ఖర్చు చేస్తుంది (వాస్తవానికి, ఇది అన్నింటినీ చేస్తుంది నోడ్స్, డిస్క్‌లు మొదలైన వాటి వైఫల్యాల తర్వాత ప్రతిరూపణ మరియు పునరుద్ధరణ). అంటే, మీరు కంప్యూట్ నోడ్‌ని స్టోరేజ్‌తో కలిపితే దాని పవర్‌లో కొంత భాగాన్ని కోల్పోతారు.
ఈ అంశాలన్నింటినీ ఎలాగైనా నిర్వహించాలి - మనకు మెషిన్, నెట్వర్క్, వర్చువల్ రౌటర్ మొదలైనవాటిని సృష్టించగల ఏదైనా అవసరం. దీన్ని చేయడానికి, మేము డ్యాష్‌బోర్డ్‌గా పనిచేసే కంట్రోల్ నోడ్‌కు సేవను జోడిస్తాము - ది క్లయింట్ http/ https ద్వారా ఈ పోర్టల్‌కి కనెక్ట్ అవ్వగలరు మరియు అతనికి అవసరమైన ప్రతిదాన్ని చేయగలరు (బాగా, దాదాపు).
తత్ఫలితంగా, ఇప్పుడు మనం తప్పులను తట్టుకునే వ్యవస్థను కలిగి ఉన్నాము. ఈ ఇన్‌ఫ్రాస్ట్రక్చర్‌లోని అన్ని అంశాలు ఏదో ఒకవిధంగా నిర్వహించబడాలి. ఓపెన్స్టాక్ అనేది ప్రాజెక్ట్‌ల సమితి అని గతంలో వివరించబడింది, వీటిలో ప్రతి ఒక్కటి నిర్దిష్ట ఫంక్షన్‌ను అందిస్తుంది. మేము చూస్తున్నట్లుగా, కాన్ఫిగర్ చేయబడి మరియు నియంత్రించాల్సిన అంశాలు తగినంత కంటే ఎక్కువ ఉన్నాయి. ఈ రోజు మనం నెట్వర్క్ భాగం గురించి మాట్లాడుతాము.
న్యూట్రాన్ ఆర్కిటెక్చర్
ఓపెన్‌స్టాక్‌లో, వర్చువల్ మెషీన్ పోర్ట్‌లను సాధారణ L2 నెట్‌వర్క్‌కు కనెక్ట్ చేయడం, వివిధ L2 నెట్‌వర్క్‌లలో ఉన్న VMల మధ్య ట్రాఫిక్ రూటింగ్‌ను నిర్ధారించడం, అలాగే అవుట్‌వర్డ్ రూటింగ్, NAT, ఫ్లోటింగ్ IP, DHCP మొదలైన సేవలను అందించే బాధ్యత న్యూట్రాన్.
అధిక స్థాయిలో, నెట్వర్క్ సేవ యొక్క ఆపరేషన్ (ప్రాథమిక భాగం) క్రింది విధంగా వివరించవచ్చు.
VMని ప్రారంభించేటప్పుడు, నెట్వర్క్ సేవ:
- ఇచ్చిన VM (లేదా పోర్ట్‌లు) కోసం పోర్ట్‌ను సృష్టిస్తుంది మరియు దాని గురించి DHCP సేవకు తెలియజేస్తుంది;
- కొత్త వర్చువల్ నెట్వర్క్ పరికరం సృష్టించబడింది (libvirt ద్వారా);
- VM దశ 1లో సృష్టించబడిన పోర్ట్(ల)కి కలుపుతుంది;
విచిత్రమేమిటంటే, న్యూట్రాన్ యొక్క పని లైనక్స్‌లోకి ప్రవేశించిన ప్రతి ఒక్కరికీ తెలిసిన ప్రామాణిక మెకానిజమ్‌లపై ఆధారపడి ఉంటుంది - నేమ్‌స్పేస్‌లు, iptables, linux వంతెనలు, openvswitch, conntrack మొదలైనవి.
న్యూట్రాన్ SDN కంట్రోలర్ కాదని వెంటనే స్పష్టం చేయాలి.
న్యూట్రాన్ అనేక పరస్పర అనుసంధాన భాగాలను కలిగి ఉంటుంది:
ఓపెన్స్టాక్-న్యూట్రాన్-సర్వర్ API ద్వారా వినియోగదారు అభ్యర్థనలతో పనిచేసే డెమోన్. ఈ భూతం ఎటువంటి నెట్వర్క్ కనెక్షన్‌లను నమోదు చేయడంలో పాల్గొనదు, కానీ దీని కోసం అవసరమైన సమాచారాన్ని దాని ప్లగిన్‌లకు అందిస్తుంది, అది కావలసిన నెట్వర్క్ మూలకాన్ని కాన్ఫిగర్ చేస్తుంది. ఓపెన్స్టాక్ నోడ్స్‌లోని న్యూట్రాన్ ఏజెంట్లు న్యూట్రాన్ సర్వర్‌తో నమోదు చేసుకుంటారు.
న్యూట్రాన్-సర్వర్ వాస్తవానికి పైథాన్‌లో వ్రాయబడిన అప్లికేషన్, ఇందులో రెండు భాగాలు ఉన్నాయి:
- REST సేవ
- న్యూట్రాన్ ప్లగిన్ (కోర్/సర్వీస్)
REST సేవ ఇతర భాగాల నుండి API కాల్‌లను స్వీకరించడానికి రూపొందించబడింది (ఉదాహరణకు, కొంత సమాచారాన్ని అందించడానికి అభ్యర్థన మొదలైనవి)
ప్లగిన్లు API అభ్యర్థనల సమయంలో పిలవబడే ప్లగ్-ఇన్ సాఫ్ట్‌వేర్ భాగాలు/మాడ్యూల్‌లు - అంటే, సేవ యొక్క ఆపాదింపు వాటి ద్వారా జరుగుతుంది. ప్లగిన్లు రెండు రకాలుగా విభజించబడ్డాయి - సర్వీస్ మరియు రూట్. నియమం ప్రకారం, గుర్రపు ప్లగ్ఇన్ VMల మధ్య చిరునామా స్థలం మరియు L2 కనెక్షన్‌లను నిర్వహించడానికి ప్రధానంగా బాధ్యత వహిస్తుంది మరియు సర్వీస్ ప్లగిన్లు ఇప్పటికే VPN లేదా FW వంటి అదనపు కార్యాచరణను అందిస్తాయి.
ఉదాహరణకు ఈరోజు అందుబాటులో ఉన్న ప్లగిన్‌ల జాబితాను చూడవచ్చు
అనేక సర్వీస్ ప్లగిన్లు ఉండవచ్చు, కానీ ఒక గుర్రపు ప్లగిన్ మాత్రమే ఉంటుంది.
ఓపెన్స్టాక్-న్యూట్రాన్-ml2 ప్రామాణిక Openstack రూట్ ప్లగ్ఇన్. ఈ ప్లగ్ఇన్ మాడ్యులర్ ఆర్కిటెక్చర్‌ను కలిగి ఉంది (దాని పూర్వీకుల వలె కాకుండా) మరియు దానికి కనెక్ట్ చేయబడిన డ్రైవర్ల ద్వారా నెట్వర్క్ సేవను కాన్ఫిగర్ చేస్తుంది. వాస్తవానికి ఇది ఓపెన్స్టాక్ నెట్వర్క్ భాగంలో కలిగి ఉన్న సౌలభ్యాన్ని ఇస్తుంది కాబట్టి మేము ప్లగ్‌ఇన్‌ను కొంచెం తర్వాత పరిశీలిస్తాము. రూట్ ప్లగ్ఇన్ భర్తీ చేయవచ్చు (ఉదాహరణకు, కాంట్రయిల్ నెట్‌వర్కింగ్ అటువంటి రీప్లేస్‌మెంట్ చేస్తుంది).
RPC సేవ (rabbitmq-సర్వర్) — ఇతర ఓపెన్స్టాక్ సేవలతో క్యూ నిర్వహణ మరియు పరస్పర చర్యను అందించే సేవ, అలాగే నెట్వర్క్ సేవా ఏజెంట్ల మధ్య పరస్పర చర్య.
నెట్వర్క్ ఏజెంట్లు — ప్రతి నోడ్‌లో ఉన్న ఏజెంట్లు, దీని ద్వారా నెట్వర్క్ సేవలు కాన్ఫిగర్ చేయబడతాయి.
అనేక రకాల ఏజెంట్లు ఉన్నాయి.
ప్రధాన ఏజెంట్ L2 ఏజెంట్. ఈ ఏజెంట్లు కంట్రోల్ నోడ్‌లతో సహా ప్రతి హైపర్‌వైజర్‌లపై అమలు చేస్తారు (మరింత ఖచ్చితంగా, అద్దెదారులకు ఏదైనా సేవను అందించే అన్ని నోడ్‌లలో) మరియు వాటి ప్రధాన విధి సాధారణ L2 నెట్‌వర్క్‌కు వర్చువల్ మిషన్లను కనెక్ట్ చేయడం మరియు ఏదైనా సంఘటనలు జరిగినప్పుడు హెచ్చరికలను కూడా రూపొందించడం ( ఉదాహరణకు పోర్ట్‌ను డిసేబుల్/ఎనేబుల్ చేయండి).
తదుపరిది, తక్కువ ముఖ్యమైన ఏజెంట్ కాదు L3 ఏజెంట్. డిఫాల్ట్‌గా, ఈ ఏజెంట్ ప్రత్యేకంగా నెట్వర్క్ నోడ్‌పై నడుస్తుంది (తరచుగా నెట్వర్క్ నోడ్ కంట్రోల్ నోడ్‌తో కలిపి ఉంటుంది) మరియు అద్దెదారు నెట్‌వర్క్‌ల మధ్య రూటింగ్‌ను అందిస్తుంది (దాని నెట్‌వర్క్‌లు మరియు ఇతర అద్దెదారుల నెట్‌వర్క్‌ల మధ్య, మరియు బయటి ప్రపంచానికి అందుబాటులో ఉంటుంది. NAT, అలాగే DHCP సేవ). అయినప్పటికీ, DVR (డిస్ట్రిబ్యూటెడ్ రూటర్) ఉపయోగిస్తున్నప్పుడు, L3 ప్లగ్ఇన్ అవసరం కూడా కంప్యూట్ నోడ్‌లలో కనిపిస్తుంది.
L3 ఏజెంట్ ప్రతి అద్దెదారుకు దాని స్వంత వివిక్త నెట్‌వర్క్‌ల సమితిని అందించడానికి Linux నేమ్‌స్పేస్‌లను ఉపయోగిస్తుంది మరియు లేయర్ 2 నెట్‌వర్క్‌ల కోసం గేట్‌వే సేవలను అందించే మరియు ట్రాఫిక్‌ను రూట్ చేసే వర్చువల్ రూటర్‌ల కార్యాచరణను అందిస్తుంది.
డేటాబేస్ - నెట్‌వర్క్‌లు, సబ్‌నెట్‌లు, పోర్ట్‌లు, పూల్స్ మొదలైన వాటి ఐడెంటిఫైయర్‌ల డేటాబేస్.
వాస్తవానికి, న్యూట్రాన్ ఏదైనా నెట్వర్క్ ఎంటిటీల సృష్టి నుండి API అభ్యర్థనలను అంగీకరిస్తుంది, అభ్యర్థనను ధృవీకరిస్తుంది మరియు RPC (ఇది కొంత ప్లగ్ఇన్ లేదా ఏజెంట్‌ను యాక్సెస్ చేస్తే) లేదా REST API ద్వారా (అది SDNలో కమ్యూనికేట్ చేస్తే) ఏజెంట్‌లకు (ప్లగిన్‌ల ద్వారా) ప్రసారం చేస్తుంది అభ్యర్థించిన సేవను నిర్వహించడానికి అవసరమైన సూచనలు.
ఇప్పుడు టెస్ట్ ఇన్‌స్టాలేషన్‌కు వెళ్దాం (ఇది ఎలా అమలు చేయబడింది మరియు దానిలో ఏమి చేర్చబడింది, మేము తరువాత ఆచరణాత్మక భాగంలో చూద్దాం) మరియు ప్రతి భాగం ఎక్కడ ఉందో చూద్దాం:
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$
నిజానికి, అది న్యూట్రాన్ యొక్క మొత్తం నిర్మాణం. ఇప్పుడు ML2 ప్లగ్ఇన్‌లో కొంత సమయం గడపడం విలువైనదే.
మాడ్యులర్ లేయర్ 2
పైన పేర్కొన్న విధంగా, ప్లగ్ఇన్ ఒక ప్రామాణిక OpenStack రూట్ ప్లగ్ఇన్ మరియు మాడ్యులర్ ఆర్కిటెక్చర్ కలిగి ఉంటుంది.
ML2 ప్లగ్ఇన్ యొక్క పూర్వీకుడు ఏకశిలా నిర్మాణాన్ని కలిగి ఉంది, ఉదాహరణకు, ఒక ఇన్‌స్టాలేషన్‌లో అనేక సాంకేతికతల మిశ్రమాన్ని ఉపయోగించడం అనుమతించదు. ఉదాహరణకు, మీరు openvswitch మరియు linuxbridge రెండింటినీ ఒకే సమయంలో ఉపయోగించలేరు - మొదటిది లేదా రెండవది. ఈ కారణంగా, దాని నిర్మాణంతో ML2 ప్లగ్ఇన్ సృష్టించబడింది.
ML2 రెండు భాగాలను కలిగి ఉంది - రెండు రకాల డ్రైవర్లు: టైప్ డ్రైవర్లు మరియు మెకానిజం డ్రైవర్లు.
డ్రైవర్లను టైప్ చేయండి నెట్వర్క్ కనెక్షన్‌లను నిర్వహించడానికి ఉపయోగించే సాంకేతికతలను నిర్ణయించండి, ఉదాహరణకు VxLAN, VLAN, GRE. అదే సమయంలో, డ్రైవర్ వివిధ సాంకేతికతలను ఉపయోగించడానికి అనుమతిస్తుంది. ప్రామాణిక సాంకేతికత ఓవర్‌లే నెట్‌వర్క్‌లు మరియు vlan బాహ్య నెట్‌వర్క్‌ల కోసం VxLAN ఎన్‌క్యాప్సులేషన్.
టైప్ డ్రైవర్లు క్రింది నెట్వర్క్ రకాలను కలిగి ఉంటాయి:
ఫ్లాట్ - ట్యాగింగ్ లేకుండా నెట్వర్క్
VLANలు - ట్యాగ్ చేయబడిన నెట్వర్క్
స్థానిక — ఆల్-ఇన్-వన్ ఇన్‌స్టాలేషన్‌ల కోసం ప్రత్యేక రకమైన నెట్వర్క్ (అటువంటి ఇన్‌స్టాలేషన్‌లు డెవలపర్‌ల కోసం లేదా శిక్షణ కోసం అవసరం)
GRE — GRE సొరంగాలను ఉపయోగించి ఓవర్‌లే నెట్వర్క్
VxLAN — VxLAN సొరంగాలను ఉపయోగించి ఓవర్‌లే నెట్వర్క్
మెకానిజం డ్రైవర్లు రకం డ్రైవర్‌లో పేర్కొన్న సాంకేతికతల సంస్థను నిర్ధారించే సాధనాలను నిర్వచించండి - ఉదాహరణకు, openvswitch, sr-iov, opendaylight, OVN, మొదలైనవి.
ఈ డ్రైవర్ అమలుపై ఆధారపడి, న్యూట్రాన్ ద్వారా నియంత్రించబడే ఏజెంట్లు ఉపయోగించబడుతుంది లేదా బాహ్య SDN కంట్రోలర్‌కు కనెక్షన్‌లు ఉపయోగించబడతాయి, ఇది L2 నెట్‌వర్క్‌లను నిర్వహించడం, రూటింగ్ మొదలైన వాటికి సంబంధించిన అన్ని సమస్యలను చూసుకుంటుంది.
ఉదాహరణ: మేము OVSతో కలిపి ML2ని ఉపయోగిస్తే, OVSని నిర్వహించే ప్రతి కంప్యూటింగ్ నోడ్‌లో L2 ఏజెంట్ ఇన్‌స్టాల్ చేయబడుతుంది. అయితే, మేము ఉపయోగిస్తే, ఉదాహరణకు, OVN లేదా OpenDayLight, అప్పుడు OVS యొక్క నియంత్రణ వారి అధికార పరిధిలోకి వస్తుంది - న్యూట్రాన్, రూట్ ప్లగ్ఇన్ ద్వారా, కంట్రోలర్‌కు ఆదేశాలను ఇస్తుంది మరియు ఇది ఇప్పటికే చెప్పినట్లు చేస్తుంది.
ఓపెన్ vSwitchలో బ్రష్ అప్ చేద్దాం
ప్రస్తుతానికి, OpenStack యొక్క ముఖ్య భాగాలలో ఒకటి Open vSwitch.
జూనిపర్ కాంట్రయిల్ లేదా నోకియా నూయేజ్ వంటి అదనపు విక్రేత SDN లేకుండా OpenStackను ఇన్‌స్టాల్ చేస్తున్నప్పుడు, OVS అనేది క్లౌడ్ నెట్వర్క్ యొక్క ప్రధాన నెట్వర్క్ భాగం మరియు iptables, conntrack, namespacesతో కలిపి, పూర్తి స్థాయి బహుళ-అద్దె ఓవర్‌లే నెట్‌వర్క్‌లను నిర్వహించడానికి మిమ్మల్ని అనుమతిస్తుంది. సహజంగానే, ఈ భాగాన్ని భర్తీ చేయవచ్చు, ఉదాహరణకు, మూడవ పక్ష యాజమాన్య (విక్రేత) SDN పరిష్కారాలను ఉపయోగిస్తున్నప్పుడు.
OVS అనేది ఓపెన్ సోర్స్ సాఫ్ట్‌వేర్ స్విచ్, ఇది వర్చువలైజ్డ్ ఎన్విరాన్‌మెంట్‌లలో వర్చువల్ ట్రాఫిక్ ఫార్వార్డర్‌గా ఉపయోగించడానికి రూపొందించబడింది.
ప్రస్తుతానికి, OVS చాలా మంచి కార్యాచరణను కలిగి ఉంది, ఇందులో QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK మొదలైన సాంకేతికతలు ఉన్నాయి.
గమనిక: OVS మొదట్లో అధిక లోడ్ చేయబడిన టెలికాం ఫంక్షన్ల కోసం సాఫ్ట్ స్విచ్‌గా భావించబడలేదు మరియు WEB సర్వర్ లేదా మెయిల్ సర్వర్ వంటి తక్కువ బ్యాండ్‌విడ్త్-డిమాండింగ్ IT ఫంక్షన్ల కోసం ఎక్కువగా రూపొందించబడింది. అయినప్పటికీ, OVS మరింత అభివృద్ధి చేయబడుతోంది మరియు OVS యొక్క ప్రస్తుత అమలులు దాని పనితీరు మరియు సామర్థ్యాలను బాగా మెరుగుపరిచాయి, ఇది టెలికాం ఆపరేటర్లు అధిక లోడ్ చేయబడిన ఫంక్షన్లతో ఉపయోగించడానికి అనుమతిస్తుంది, ఉదాహరణకు, DPDK త్వరణానికి మద్దతుతో OVS అమలు ఉంది.
మీరు తెలుసుకోవలసిన OVS యొక్క మూడు ముఖ్యమైన భాగాలు ఉన్నాయి:
- కెర్నల్ మాడ్యూల్ - నియంత్రణ మూలకం నుండి అందుకున్న నియమాల ఆధారంగా ట్రాఫిక్‌ను ప్రాసెస్ చేసే కెర్నల్ స్థలంలో ఉన్న ఒక భాగం;
- vSwitch డెమోన్ (ovs-vswitchd) అనేది వినియోగదారు స్థలంలో ప్రారంభించబడిన ప్రక్రియ, ఇది కెర్నల్ మాడ్యూల్‌ను ప్రోగ్రామింగ్ చేయడానికి బాధ్యత వహిస్తుంది - అంటే, ఇది నేరుగా స్విచ్ యొక్క ఆపరేషన్ యొక్క లాజిక్‌ను సూచిస్తుంది.
- డేటాబేస్ సర్వర్ - OVS నడుస్తున్న ప్రతి హోస్ట్‌లో ఉన్న స్థానిక డేటాబేస్, దీనిలో కాన్ఫిగరేషన్ నిల్వ చేయబడుతుంది. SDN కంట్రోలర్‌లు OVSDB ప్రోటోకాల్‌ని ఉపయోగించి ఈ మాడ్యూల్ ద్వారా కమ్యూనికేట్ చేయవచ్చు.
ఇవన్నీ ovs-vsctl, ovs-appctl, ovs-ofctl మొదలైన డయాగ్నస్టిక్ మరియు మేనేజ్‌మెంట్ యుటిలిటీల సమితితో కూడి ఉంటాయి.
ప్రస్తుతం, EPC, SBC, HLR మొదలైన నెట్వర్క్ ఫంక్షన్‌లను తరలించడానికి టెలికాం ఆపరేటర్‌లచే ఓపెన్స్టాక్ విస్తృతంగా ఉపయోగించబడుతుంది. కొన్ని ఫంక్షన్‌లు OVSతో సమస్యలు లేకుండా జీవించగలవు, అయితే ఉదాహరణకు, EPC సబ్‌స్క్రైబర్ ట్రాఫిక్‌ను ప్రాసెస్ చేస్తుంది - తర్వాత అది వెళుతుంది. భారీ మొత్తంలో ట్రాఫిక్ (ఇప్పుడు ట్రాఫిక్ వాల్యూమ్‌లు సెకనుకు అనేక వందల గిగాబిట్‌లకు చేరుకుంటాయి). సహజంగానే, అటువంటి ట్రాఫిక్‌ను కెర్నల్ స్పేస్ ద్వారా నడపడం (ఫార్వర్డర్ డిఫాల్ట్‌గా ఉన్నందున) ఉత్తమ ఆలోచన కాదు. అందువల్ల, OVS తరచుగా DPDK యాక్సిలరేషన్ సాంకేతికతను ఉపయోగించి పూర్తిగా వినియోగదారు స్థలంలో కెర్నల్‌ను దాటవేస్తూ NIC నుండి వినియోగదారు స్థలానికి ట్రాఫిక్‌ను ఫార్వార్డ్ చేయడానికి అమలు చేయబడుతుంది.
గమనిక: టెలికాం ఫంక్షన్ల కోసం అమలు చేయబడిన క్లౌడ్ కోసం, OVSని నేరుగా పరికరాన్ని మార్చడం ద్వారా కంప్యూట్ నోడ్ నుండి ట్రాఫిక్‌ను అవుట్‌పుట్ చేయడం సాధ్యపడుతుంది. ఈ ప్రయోజనం కోసం SR-IOV మరియు పాస్‌త్రూ మెకానిజమ్‌లు ఉపయోగించబడతాయి.
ఇది నిజమైన లేఅవుట్‌లో ఎలా పని చేస్తుంది?
సరే, ఇప్పుడు ఆచరణాత్మక భాగానికి వెళ్దాం మరియు ఇది ఆచరణలో ఎలా పనిచేస్తుందో చూద్దాం.
ముందుగా, ఒక సాధారణ ఓపెన్స్టాక్ ఇన్‌స్టాలేషన్‌ని అమలు చేద్దాం. ప్రయోగాల కోసం నా వద్ద సర్వర్‌ల సెట్ లేనందున, మేము వర్చువల్ మెషీన్ల నుండి ఒక ఫిజికల్ సర్వర్‌లో ప్రోటోటైప్‌ను సమీకరించాము. అవును, సహజంగానే, అటువంటి పరిష్కారం వాణిజ్య ప్రయోజనాల కోసం తగినది కాదు, కానీ ఓపెన్‌స్టాక్‌లో నెట్వర్క్ ఎలా పనిచేస్తుందో ఉదాహరణ చూడటానికి, అటువంటి ఇన్‌స్టాలేషన్ కళ్ళకు సరిపోతుంది. అంతేకాకుండా, శిక్షణా ప్రయోజనాల కోసం ఇటువంటి సంస్థాపన మరింత ఆసక్తికరంగా ఉంటుంది - మీరు ట్రాఫిక్, మొదలైనవి పట్టుకోవచ్చు కాబట్టి.
మేము ప్రాథమిక భాగాన్ని మాత్రమే చూడాల్సిన అవసరం ఉన్నందున, మేము అనేక నెట్‌వర్క్‌లను ఉపయోగించలేము కానీ కేవలం రెండు నెట్‌వర్క్‌లను ఉపయోగించి అన్నింటినీ పెంచుతాము మరియు ఈ లేఅవుట్‌లోని రెండవ నెట్వర్క్ అండర్‌క్లౌడ్ మరియు DNS సర్వర్‌కు ప్రాప్యత కోసం ప్రత్యేకంగా ఉపయోగించబడుతుంది. మేము ప్రస్తుతానికి బాహ్య నెట్‌వర్క్‌లను తాకము - ఇది ప్రత్యేక పెద్ద కథనానికి సంబంధించిన అంశం.
కాబట్టి, క్రమంలో ప్రారంభిద్దాం. మొదట, ఒక చిన్న సిద్ధాంతం. మేము ట్రిపుల్‌ఓ (ఓపెన్‌స్టాక్‌లో ఓపెన్స్టాక్) ఉపయోగించి ఓపెన్‌స్టాక్‌ను ఇన్‌స్టాల్ చేస్తాము. TripleO యొక్క సారాంశం ఏమిటంటే, మేము అండర్‌క్లౌడ్ అని పిలువబడే ఓపెన్స్టాక్ ఆల్-ఇన్-వన్ (అంటే ఒక నోడ్‌లో) ఇన్‌స్టాల్ చేసి, ఆపై ఓవర్‌క్లౌడ్ అని పిలువబడే ఆపరేషన్ కోసం ఉద్దేశించిన ఓపెన్‌స్టాక్‌ను ఇన్‌స్టాల్ చేయడానికి మోహరించిన ఓపెన్స్టాక్ సామర్థ్యాలను ఉపయోగిస్తాము. అండర్‌క్లౌడ్ భౌతిక సర్వర్‌లను (బేర్ మెటల్) - ఐరోనిక్ ప్రాజెక్ట్ - గణన, నియంత్రణ, నిల్వ నోడ్‌ల పాత్రలను నిర్వహించే హైపర్‌వైజర్‌లను అందించడానికి దాని స్వాభావిక సామర్థ్యాన్ని ఉపయోగిస్తుంది. అంటే, మేము Openstackని అమలు చేయడానికి ఏ మూడవ-పక్ష సాధనాలను ఉపయోగించము - మేము Openstackని ఉపయోగించి Openstackని అమలు చేస్తాము. ఇన్‌స్టాలేషన్ పురోగతితో ఇది చాలా స్పష్టంగా మారుతుంది, కాబట్టి మేము అక్కడ ఆగి ముందుకు వెళ్లము.
గమనిక: ఈ వ్యాసంలో, సరళత కోసం, నేను అంతర్గత ఓపెన్స్టాక్ నెట్‌వర్క్‌ల కోసం నెట్వర్క్ ఐసోలేషన్‌ను ఉపయోగించలేదు, కానీ ప్రతిదీ ఒకే నెట్‌వర్క్‌ని ఉపయోగించి అమలు చేయబడుతుంది. అయినప్పటికీ, నెట్వర్క్ ఐసోలేషన్ యొక్క ఉనికి లేదా లేకపోవడం పరిష్కారం యొక్క ప్రాథమిక కార్యాచరణను ప్రభావితం చేయదు - ఐసోలేషన్‌ను ఉపయోగిస్తున్నప్పుడు ప్రతిదీ సరిగ్గా అదే పని చేస్తుంది, అయితే ట్రాఫిక్ అదే నెట్‌వర్క్‌లో ప్రవహిస్తుంది. కమర్షియల్ ఇన్‌స్టాలేషన్ కోసం, విభిన్న vlans మరియు ఇంటర్‌ఫేస్‌లను ఉపయోగించి ఐసోలేషన్‌ని ఉపయోగించడం సహజంగా అవసరం. ఉదాహరణకు, ceph స్టోరేజ్ మేనేజ్‌మెంట్ ట్రాఫిక్ మరియు డేటా ట్రాఫిక్ (డిస్క్‌లకు మెషిన్ యాక్సెస్ మొదలైనవి) వేర్వేరు సబ్‌నెట్‌లను (స్టోరేజ్ మేనేజ్‌మెంట్ మరియు స్టోరేజ్) ఉపయోగిస్తాయి మరియు ఇది ఈ ట్రాఫిక్‌ను విభజించడం ద్వారా పరిష్కారాన్ని మరింత తప్పు-తట్టుకునేలా చేయడానికి మిమ్మల్ని అనుమతిస్తుంది, ఉదాహరణకు. , వివిధ పోర్ట్‌లలో లేదా విభిన్న ట్రాఫిక్ కోసం విభిన్న QoS ప్రొఫైల్‌లను ఉపయోగించడం వలన డేటా ట్రాఫిక్ సిగ్నలింగ్ ట్రాఫిక్‌ను దూరం చేయదు. మా విషయంలో, వారు ఒకే నెట్‌వర్క్‌లో వెళతారు మరియు వాస్తవానికి ఇది మమ్మల్ని ఏ విధంగానూ పరిమితం చేయదు.
గమనిక: మేము వర్చువల్ మిషన్ల ఆధారంగా వర్చువల్ ఎన్విరాన్‌మెంట్‌లో వర్చువల్ మిషన్లను అమలు చేయబోతున్నాము కాబట్టి, ముందుగా మనం నెస్టెడ్ వర్చువలైజేషన్‌ను ప్రారంభించాలి.
సమూహ వర్చువలైజేషన్ ప్రారంభించబడిందా లేదా ఇలా కాదా అని మీరు తనిఖీ చేయవచ్చు:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#మీకు N అక్షరం కనిపిస్తే, మీరు నెట్‌వర్క్‌లో కనుగొనే ఏదైనా గైడ్ ప్రకారం మేము నెస్టెడ్ వర్చువలైజేషన్‌కు మద్దతును ప్రారంభిస్తాము, ఉదాహరణకు .
మేము వర్చువల్ మిషన్ల నుండి క్రింది సర్క్యూట్‌ను సమీకరించాలి:
నా విషయంలో, భవిష్యత్ ఇన్‌స్టాలేషన్‌లో భాగమైన వర్చువల్ మిషన్లను కనెక్ట్ చేయడానికి (మరియు నేను వాటిలో 7 పొందాను, కానీ మీకు చాలా వనరులు లేకుంటే మీరు 4 ద్వారా పొందవచ్చు), నేను OpenvSwitchని ఉపయోగించాను. నేను ఒక ovs వంతెనను సృష్టించాను మరియు పోర్ట్-గ్రూప్‌ల ద్వారా దానికి వర్చువల్ మిషన్లను కనెక్ట్ చేసాను. దీన్ని చేయడానికి, నేను ఇలాంటి xml ఫైల్‌ను సృష్టించాను:
[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1
<network>
<name>ovs-network-1</name>
<uuid>7a2e7de7-fc16-4e00-b1ed-4d190133af67</uuid>
<forward mode='bridge'/>
<bridge name='ovs-br1'/>
<virtualport type='openvswitch'/>
<portgroup name='trunk-1'>
<vlan trunk='yes'>
<tag id='100'/>
<tag id='101'/>
<tag id='102'/>
</vlan>
</portgroup>
<portgroup name='access-100'>
<vlan>
<tag id='100'/>
</vlan>
</portgroup>
<portgroup name='access-101'>
<vlan>
<tag id='101'/>
</vlan>
</portgroup>
</network>మూడు పోర్ట్ సమూహాలు ఇక్కడ ప్రకటించబడ్డాయి - రెండు యాక్సెస్ మరియు ఒక ట్రంక్ (రెండోది DNS సర్వర్‌కు అవసరం, కానీ మీరు అది లేకుండా చేయవచ్చు లేదా హోస్ట్ మెషీన్‌లో ఇన్‌స్టాల్ చేయవచ్చు - ఏది మీకు మరింత సౌకర్యవంతంగా ఉంటుంది). తరువాత, ఈ టెంప్లేట్ ఉపయోగించి, మేము మాది virsh net-define ద్వారా ప్రకటిస్తాము:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 ఇప్పుడు మనం హైపర్‌వైజర్ పోర్ట్ కాన్ఫిగరేషన్‌లను ఎడిట్ చేస్తాము:
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens1f0
TYPE=Ethernet
NAME=ens1f0
DEVICE=ens1f0
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=ovs-br1
ONBOOT=yes
OVS_OPTIONS="trunk=100,101,102"
[root@hp-gen9 ~]
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ovs-br1
DEVICE=ovs-br1
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.255.200
PREFIX=24
[root@hp-gen9 ~]# గమనిక: ఈ దృష్టాంతంలో, పోర్ట్ ovs-br1 చిరునామాకు vlan ట్యాగ్ లేనందున అది యాక్సెస్ చేయబడదు. దీన్ని పరిష్కరించడానికి, మీరు sudo ovs-vsctl సెట్ పోర్ట్ ovs-br1 ట్యాగ్=100 ఆదేశాన్ని జారీ చేయాలి. అయితే, రీబూట్ చేసిన తర్వాత, ఈ ట్యాగ్ అదృశ్యమవుతుంది (ఎవరైనా దీన్ని ఎలా ఉంచాలో తెలిస్తే, నేను చాలా కృతజ్ఞతతో ఉంటాను). కానీ ఇది చాలా ముఖ్యమైనది కాదు, ఎందుకంటే ఇన్‌స్టాలేషన్ సమయంలో మాత్రమే మనకు ఈ చిరునామా అవసరం మరియు ఓపెన్స్టాక్ పూర్తిగా అమలు చేయబడినప్పుడు ఇది అవసరం లేదు.
తరువాత, మేము అండర్‌క్లౌడ్ మెషీన్‌ను సృష్టిస్తాము:
virt-install -n undercloud --description "undercloud" --os-type=Linux --os-variant=centos7.0 --ram=8192 --vcpus=8 --disk path=/var/lib/libvirt/images/undercloud.qcow2,bus=virtio,size=40,format=qcow2 --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=access-101 --graphics none --location /var/lib/libvirt/boot/CentOS-7-x86_64-Minimal-2003.iso --extra-args console=ttyS0ఇన్‌స్టాలేషన్ సమయంలో, మీరు మెషీన్ పేరు, పాస్‌వర్డ్‌లు, యూజర్‌లు, ఎన్‌టిపి సర్వర్లు మొదలైన అన్ని అవసరమైన పారామితులను సెట్ చేసారు, మీరు వెంటనే పోర్ట్‌లను కాన్ఫిగర్ చేయవచ్చు, కానీ నాకు వ్యక్తిగతంగా, ఇన్‌స్టాలేషన్ తర్వాత, మెషీన్‌లోకి లాగిన్ చేయడం సులభం కన్సోల్ మరియు అవసరమైన ఫైళ్లను సరిచేయండి. మీరు ఇప్పటికే రెడీమేడ్ ఇమేజ్‌ని కలిగి ఉన్నట్లయితే, మీరు దాన్ని ఉపయోగించవచ్చు లేదా నేను చేసిన పనిని చేయవచ్చు - కనిష్టమైన Centos 7 చిత్రాన్ని డౌన్‌లోడ్ చేసి, VMని ఇన్‌స్టాల్ చేయడానికి దాన్ని ఉపయోగించండి.
విజయవంతమైన ఇన్‌స్టాలేషన్ తర్వాత, మీరు అండర్‌క్లౌడ్‌ను ఇన్‌స్టాల్ చేయగల వర్చువల్ మెషీన్‌ను కలిగి ఉండాలి
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningమొదట, ఇన్‌స్టాలేషన్ ప్రాసెస్‌కు అవసరమైన సాధనాలను ఇన్‌స్టాల్ చేయండి:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
అండర్‌క్లౌడ్ ఇన్‌స్టాలేషన్
మేము స్టాక్ వినియోగదారుని సృష్టిస్తాము, పాస్‌వర్డ్‌ను సెట్ చేస్తాము, దానిని sudoerకి జోడిస్తాము మరియు పాస్‌వర్డ్‌ను నమోదు చేయకుండానే sudo ద్వారా రూట్ ఆదేశాలను అమలు చేయగల సామర్థ్యాన్ని అతనికి అందిస్తాము:
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackఇప్పుడు మేము హోస్ట్ ఫైల్‌లో పూర్తి అండర్‌క్లౌడ్ పేరును నిర్దేశిస్తాము:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6తరువాత, మేము రిపోజిటరీలను జోడించి, మనకు అవసరమైన సాఫ్ట్‌వేర్‌ను ఇన్‌స్టాల్ చేస్తాము:
sudo yum install -y https://trunk.rdoproject.org/centos7/current/python2-tripleo-repos-0.0.1-0.20200409224957.8bac392.el7.noarch.rpm
sudo -E tripleo-repos -b queens current
sudo -E tripleo-repos -b queens current ceph
sudo yum install -y python-tripleoclient
sudo yum install -y ceph-ansibleగమనిక: మీరు cephని ఇన్‌స్టాల్ చేయడానికి ప్లాన్ చేయకపోతే, మీరు ceph-సంబంధిత ఆదేశాలను నమోదు చేయవలసిన అవసరం లేదు. నేను క్వీన్స్ విడుదలను ఉపయోగించాను, కానీ మీరు మీకు నచ్చిన మరేదైనా ఉపయోగించవచ్చు.
తర్వాత, అండర్‌క్లౌడ్ కాన్ఫిగరేషన్ ఫైల్‌ను యూజర్ హోమ్ డైరెక్టరీ స్టాక్‌కు కాపీ చేయండి:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confఇప్పుడు మనం ఈ ఫైల్‌ని సరిదిద్దాలి, దానిని మన ఇన్‌స్టాలేషన్‌కు సర్దుబాటు చేయాలి.
మీరు ఫైల్ ప్రారంభంలో ఈ పంక్తులను జోడించాలి:
vi undercloud.conf
[DEFAULT]
undercloud_hostname = undercloud.openstack.rnd
local_ip = 192.168.255.1/24
network_gateway = 192.168.255.1
undercloud_public_host = 192.168.255.2
undercloud_admin_host = 192.168.255.3
undercloud_nameservers = 192.168.255.253
generate_service_certificate = false
local_interface = eth0
local_mtu = 1450
network_cidr = 192.168.255.0/24
masquerade = true
masquerade_network = 192.168.255.0/24
dhcp_start = 192.168.255.11
dhcp_end = 192.168.255.50
inspection_iprange = 192.168.255.51,192.168.255.100
scheduler_max_attempts = 10కాబట్టి, సెట్టింగుల ద్వారా వెళ్దాం:
undercloud_hostname — అండర్‌క్లౌడ్ సర్వర్ పూర్తి పేరు, తప్పనిసరిగా DNS సర్వర్‌లోని ఎంట్రీతో సరిపోలాలి
స్థానిక_ip - నెట్వర్క్ ప్రొవిజనింగ్ వైపు స్థానిక అండర్‌క్లౌడ్ చిరునామా
నెట్వర్క్_గేట్‌వే — అదే స్థానిక చిరునామా, ఓవర్‌క్లౌడ్ నోడ్‌ల ఇన్‌స్టాలేషన్ సమయంలో బయటి ప్రపంచానికి యాక్సెస్ కోసం గేట్‌వేగా పనిచేస్తుంది, ఇది కూడా స్థానిక ipతో సమానంగా ఉంటుంది.
undercloud_public_host - బాహ్య API చిరునామా, ప్రొవిజనింగ్ నెట్వర్క్ నుండి ఏదైనా ఉచిత చిరునామా కేటాయించబడుతుంది
undercloud_admin_host అంతర్గత API చిరునామా, ప్రొవిజనింగ్ నెట్వర్క్ నుండి ఏదైనా ఉచిత చిరునామా కేటాయించబడుతుంది
undercloud_nameservers - DNS సర్వర్
ఉత్పత్తి_సేవ_సర్టిఫికేట్ - ప్రస్తుత ఉదాహరణలో ఈ లైన్ చాలా ముఖ్యమైనది, ఎందుకంటే మీరు దీన్ని తప్పుగా సెట్ చేయకపోతే మీరు ఇన్‌స్టాలేషన్ సమయంలో ఎర్రర్‌ను అందుకుంటారు, సమస్య Red Hat బగ్ ట్రాకర్‌లో వివరించబడింది
స్థానిక_ఇంటర్‌ఫేస్ నెట్వర్క్ ప్రొవిజనింగ్‌లో ఇంటర్‌ఫేస్. అండర్‌క్లౌడ్ విస్తరణ సమయంలో ఈ ఇంటర్‌ఫేస్ మళ్లీ కాన్ఫిగర్ చేయబడుతుంది, కాబట్టి మీరు అండర్‌క్లౌడ్‌లో రెండు ఇంటర్‌ఫేస్‌లను కలిగి ఉండాలి - ఒకటి దీన్ని యాక్సెస్ చేయడానికి, రెండవది ప్రొవిజనింగ్ కోసం
స్థానిక_mtu - MTU. మా వద్ద ఒక పరీక్షా ప్రయోగశాల ఉంది మరియు OVS స్విచ్ పోర్ట్‌లలో నేను 1500 MTUని కలిగి ఉన్నందున, VxLANలో పొదిగిన ప్యాకెట్లు దాని గుండా వెళ్ళడానికి దానిని 1450కి సెట్ చేయడం అవసరం.
నెట్వర్క్_సిడర్ - ప్రొవిజనింగ్ నెట్వర్క్
మారువేషాల - బాహ్య నెట్‌వర్క్‌ను యాక్సెస్ చేయడానికి NATని ఉపయోగించడం
మాస్క్వెరేడ్_నెట్వర్క్ - నెట్వర్క్ NAT చేయబడుతుంది
dhcp_start — ఓవర్‌క్లౌడ్ విస్తరణ సమయంలో నోడ్‌లకు చిరునామాలు కేటాయించబడే చిరునామా పూల్ యొక్క ప్రారంభ చిరునామా
dhcp_end - ఓవర్‌క్లౌడ్ విస్తరణ సమయంలో నోడ్‌లకు చిరునామాలు కేటాయించబడే చిరునామా పూల్ యొక్క చివరి చిరునామా
తనిఖీ_ప్రారంభం - ఆత్మపరిశీలనకు అవసరమైన చిరునామాల పూల్ (పై పూల్‌తో అతివ్యాప్తి చెందకూడదు)
షెడ్యూల్_గరిష్ట_ప్రయత్నాలు - ఓవర్‌క్లౌడ్‌ను ఇన్‌స్టాల్ చేయడానికి గరిష్ట సంఖ్యలో ప్రయత్నాలు (నోడ్‌ల సంఖ్య కంటే ఎక్కువగా లేదా సమానంగా ఉండాలి)
ఫైల్ వివరించబడిన తర్వాత, మీరు అండర్‌క్లౌడ్‌ని అమలు చేయడానికి ఆదేశాన్ని ఇవ్వవచ్చు:
openstack undercloud install
మీ ఇనుముపై ఆధారపడి ప్రక్రియ 10 నుండి 30 నిమిషాల వరకు పడుతుంది. అంతిమంగా మీరు ఇలా అవుట్‌పుట్‌ని చూడాలి:
vi undercloud.conf
2020-08-13 23:13:12,668 INFO:
#############################################################################
Undercloud install complete.
The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.
There is also a stackrc file at /home/stack/stackrc.
These files are needed to interact with the OpenStack services, and should be
secured.
#############################################################################ఈ అవుట్‌పుట్ మీరు అండర్‌క్లౌడ్‌ని విజయవంతంగా ఇన్‌స్టాల్ చేసారని మరియు మీరు ఇప్పుడు అండర్‌క్లౌడ్ స్థితిని తనిఖీ చేసి, ఓవర్‌క్లౌడ్‌ని ఇన్‌స్టాల్ చేయడానికి కొనసాగవచ్చు.
మీరు ifconfig అవుట్‌పుట్‌ని చూస్తే, కొత్త వంతెన ఇంటర్‌ఫేస్ కనిపించినట్లు మీరు చూస్తారు
[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.1 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe2c:89e prefixlen 64 scopeid 0x20<link>
ether 52:54:00:2c:08:9e txqueuelen 1000 (Ethernet)
RX packets 14 bytes 1095 (1.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 20 bytes 1292 (1.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0ఓవర్‌క్లౌడ్ విస్తరణ ఇప్పుడు ఈ ఇంటర్‌ఫేస్ ద్వారా నిర్వహించబడుతుంది.
దిగువ అవుట్‌పుట్ నుండి మేము అన్ని సేవలను ఒకే నోడ్‌లో కలిగి ఉన్నామని మీరు చూడవచ్చు:
(undercloud) [stack@undercloud ~]$ openstack host list
+--------------------------+-----------+----------+
| Host Name | Service | Zone |
+--------------------------+-----------+----------+
| undercloud.openstack.rnd | conductor | internal |
| undercloud.openstack.rnd | scheduler | internal |
| undercloud.openstack.rnd | compute | nova |
+--------------------------+-----------+----------+అండర్‌క్లౌడ్ నెట్వర్క్ భాగం యొక్క కాన్ఫిగరేషన్ క్రింద ఉంది:
(undercloud) [stack@undercloud ~]$ python -m json.tool /etc/os-net-config/config.json
{
"network_config": [
{
"addresses": [
{
"ip_netmask": "192.168.255.1/24"
}
],
"members": [
{
"dns_servers": [
"192.168.255.253"
],
"mtu": 1450,
"name": "eth0",
"primary": "true",
"type": "interface"
}
],
"mtu": 1450,
"name": "br-ctlplane",
"ovs_extra": [
"br-set-external-id br-ctlplane bridge-id br-ctlplane"
],
"routes": [],
"type": "ovs_bridge"
}
]
}
(undercloud) [stack@undercloud ~]$ఓవర్‌క్లౌడ్ ఇన్‌స్టాలేషన్
ప్రస్తుతానికి మనకు అండర్‌క్లౌడ్ మాత్రమే ఉంది మరియు ఓవర్‌క్లౌడ్ అసెంబుల్ చేయబడే తగినంత నోడ్‌లు మా వద్ద లేవు. అందువల్ల, ముందుగా, మనకు అవసరమైన వర్చువల్ మిషన్లను అమలు చేద్దాం. విస్తరణ సమయంలో, అండర్‌క్లౌడ్ ఓవర్‌క్లౌడ్ మెషీన్‌లో OS మరియు అవసరమైన సాఫ్ట్‌వేర్‌ను ఇన్‌స్టాల్ చేస్తుంది - అంటే, మేము మెషీన్‌ను పూర్తిగా అమలు చేయవలసిన అవసరం లేదు, కానీ దాని కోసం డిస్క్ (లేదా డిస్క్‌లు) మాత్రమే సృష్టించి దాని పారామితులను నిర్ణయిస్తుంది - అంటే , నిజానికి, మేము OS ఇన్‌స్టాల్ చేయకుండా బేర్ సర్వర్‌ని పొందుతాము .
మన వర్చువల్ మెషీన్ల డిస్క్‌లతో ఫోల్డర్‌కి వెళ్లి, అవసరమైన పరిమాణంలో డిస్క్‌లను సృష్టించండి:
cd /var/lib/libvirt/images/
qemu-img create -f qcow2 -o preallocation=metadata control-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-2.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata storage-1.qcow2 160G
qemu-img create -f qcow2 -o preallocation=metadata storage-2.qcow2 160Gమేము రూట్‌గా పనిచేస్తున్నందున, హక్కులతో సమస్య రాకుండా ఈ డిస్క్‌ల యజమానిని మార్చాలి:
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 root root 61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 root root 61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 root root 61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:07 undercloud.qcow2
[root@hp-gen9 images]#
[root@hp-gen9 images]#
[root@hp-gen9 images]# chown qemu:qemu /var/lib/libvirt/images/*qcow2
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:08 undercloud.qcow2
[root@hp-gen9 images]# గమనిక: మీరు దానిని అధ్యయనం చేయడానికి cephని ఇన్‌స్టాల్ చేయడానికి ప్లాన్ చేయకపోతే, కమాండ్‌లు కనీసం రెండు డిస్క్‌లతో కనీసం 3 నోడ్‌లను సృష్టించవు, కానీ టెంప్లేట్‌లో వర్చువల్ డిస్క్‌లు vda, vdb మొదలైనవి ఉపయోగించబడతాయని సూచిస్తున్నాయి.
గొప్పది, ఇప్పుడు మనం ఈ యంత్రాలన్నింటినీ నిర్వచించాలి:
virt-install --name control-1 --ram 32768 --vcpus 8 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/control-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=trunk-1 --dry-run --print-xml > /tmp/control-1.xml
virt-install --name storage-1 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-1.xml
virt-install --name storage-2 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-2.xml
virt-install --name compute-1 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-1.xml
virt-install --name compute-2 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-2.xml చివరలో -print-xml > /tmp/storage-1.xml కమాండ్ ఉంది, ఇది /tmp/ ఫోల్డర్‌లోని ప్రతి మెషీన్ యొక్క వివరణతో xml ఫైల్‌ను సృష్టిస్తుంది; మీరు దానిని జోడించకుంటే, మీరు చేయలేరు. వర్చువల్ మిషన్లను గుర్తించగలుగుతారు.
ఇప్పుడు మనం ఈ యంత్రాలన్నింటినీ విర్ష్‌లో నిర్వచించాలి:
virsh define --file /tmp/control-1.xml
virsh define --file /tmp/compute-1.xml
virsh define --file /tmp/compute-2.xml
virsh define --file /tmp/storage-1.xml
virsh define --file /tmp/storage-2.xml
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#ఇప్పుడు ఒక చిన్న సూక్ష్మభేదం - ట్రిపుల్‌ఓ ఇన్‌స్టాలేషన్ మరియు ఆత్మపరిశీలన సమయంలో సర్వర్‌లను నిర్వహించడానికి IPMIని ఉపయోగిస్తుంది.
ఆత్మపరిశీలన అనేది నోడ్‌లను మరింతగా అందించడానికి అవసరమైన దాని పారామితులను పొందేందుకు హార్డ్‌వేర్‌ను తనిఖీ చేసే ప్రక్రియ. బేర్ మెటల్ సర్వర్‌లతో పని చేయడానికి రూపొందించబడిన సేవ, వ్యంగ్యాన్ని ఉపయోగించి ఆత్మపరిశీలన నిర్వహించబడుతుంది.
అయితే ఇక్కడ సమస్య ఉంది - హార్డ్‌వేర్ IPMI సర్వర్‌లకు ప్రత్యేక పోర్ట్ (లేదా షేర్డ్ పోర్ట్, కానీ ఇది ముఖ్యం కాదు) అయితే వర్చువల్ మెషీన్‌లకు అలాంటి పోర్ట్‌లు ఉండవు. ఇక్కడ vbmc అనే క్రచ్ మా సహాయానికి వస్తుంది - IPMI పోర్ట్‌ను అనుకరించడానికి మిమ్మల్ని అనుమతించే ఒక యుటిలిటీ. ESXI హైపర్‌వైజర్‌లో అటువంటి ప్రయోగశాలను సెటప్ చేయాలనుకునే వారికి ఈ స్వల్పభేదం ప్రత్యేకించి శ్రద్ధ చూపడం విలువైనది - నిజం చెప్పాలంటే, దీనికి vbmc యొక్క అనలాగ్ ఉందో లేదో నాకు తెలియదు, కాబట్టి ప్రతిదీ అమలు చేయడానికి ముందు ఈ సమస్య గురించి ఆలోచించడం విలువ. .
vbmcని ఇన్‌స్టాల్ చేయండి:
yum install yum install python2-virtualbmcమీ OS ప్యాకేజీని కనుగొనలేకపోతే, రిపోజిటరీని జోడించండి:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmఇప్పుడు మేము యుటిలిటీని సెటప్ చేసాము. ఇక్కడ ప్రతిదీ అవమానకరమైన స్థాయికి సామాన్యమైనది. ఇప్పుడు vbmc జాబితాలో సర్వర్లు లేవని తార్కికం
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# అవి కనిపించాలంటే, వాటిని మాన్యువల్‌గా ఇలా ప్రకటించాలి:
[root@hp-gen9 ~]# vbmc add control-1 --port 7001 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-1 --port 7002 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-2 --port 7003 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-1 --port 7004 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-2 --port 7005 --username admin --password admin
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+--------+---------+------+
| Domain name | Status | Address | Port |
+-------------+--------+---------+------+
| compute-1 | down | :: | 7004 |
| compute-2 | down | :: | 7005 |
| control-1 | down | :: | 7001 |
| storage-1 | down | :: | 7002 |
| storage-2 | down | :: | 7003 |
+-------------+--------+---------+------+
[root@hp-gen9 ~]#కమాండ్ సింటాక్స్ వివరణ లేకుండా స్పష్టంగా ఉందని నేను భావిస్తున్నాను. అయితే, ప్రస్తుతానికి మా సెషన్‌లన్నీ డౌన్ స్టేటస్‌లో ఉన్నాయి. వారు UP స్థితికి వెళ్లాలంటే, మీరు వాటిని ప్రారంభించాలి:
[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Started vBMC instance for domain control-1
[root@hp-gen9 ~]# vbmc start storage-1
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-2
[root@hp-gen9 ~]#
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domain name | Status | Address | Port |
+-------------+---------+---------+------+
| compute-1 | running | :: | 7004 |
| compute-2 | running | :: | 7005 |
| control-1 | running | :: | 7001 |
| storage-1 | running | :: | 7002 |
| storage-2 | running | :: | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#మరియు చివరి టచ్ - మీరు ఫైర్‌వాల్ నియమాలను సరిచేయాలి (లేదా పూర్తిగా నిలిపివేయండి):
firewall-cmd --zone=public --add-port=7001/udp --permanent
firewall-cmd --zone=public --add-port=7002/udp --permanent
firewall-cmd --zone=public --add-port=7003/udp --permanent
firewall-cmd --zone=public --add-port=7004/udp --permanent
firewall-cmd --zone=public --add-port=7005/udp --permanent
firewall-cmd --reload
ఇప్పుడు అండర్‌క్లౌడ్‌కి వెళ్లి, ప్రతిదీ పని చేస్తుందో లేదో తనిఖీ చేద్దాం. హోస్ట్ మెషీన్ యొక్క చిరునామా 192.168.255.200, అండర్‌క్లౌడ్‌లో మేము విస్తరణ కోసం సన్నాహక సమయంలో అవసరమైన ipmitool ప్యాకేజీని జోడించాము:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
65 control-1 runningమీరు చూడగలిగినట్లుగా, మేము నియంత్రణ నోడ్‌ను vbmc ద్వారా విజయవంతంగా ప్రారంభించాము. ఇప్పుడు దాన్ని ఆఫ్ చేసి, కొనసాగిద్దాం:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Chassis Power Control: Down/Off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#తదుపరి దశ ఓవర్‌క్లౌడ్ ఇన్‌స్టాల్ చేయబడే నోడ్‌ల ఆత్మపరిశీలన. దీన్ని చేయడానికి, మేము మా నోడ్‌ల వివరణతో json ఫైల్‌ను సిద్ధం చేయాలి. దయచేసి గమనించండి, బేర్ సర్వర్‌లపై ఇన్‌స్టాలేషన్ కాకుండా, ఫైల్ ప్రతి మెషీన్‌కు vbmc రన్ అవుతున్న పోర్ట్‌ను సూచిస్తుంది.
[root@hp-gen9 ~]# virsh domiflist --domain control-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:20:a2:2f
- network ovs-network-1 virtio 52:54:00:3f:87:9f
[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:98:e9:d6
[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:6a:ea:be
[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:79:0b:cb
[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:a7:fe:27గమనిక: నియంత్రణ నోడ్‌లో రెండు ఇంటర్‌ఫేస్‌లు ఉన్నాయి, కానీ ఈ సందర్భంలో ఇది ముఖ్యమైనది కాదు, ఈ ఇన్‌స్టాలేషన్‌లో ఒకటి మాకు సరిపోతుంది.
ఇప్పుడు మనం json ఫైల్‌ని సిద్ధం చేస్తాము. ప్రొవిజనింగ్ నిర్వహించబడే పోర్ట్ యొక్క గసగసాల చిరునామా, నోడ్‌ల పారామితులు, వాటికి పేర్లు ఇవ్వండి మరియు ipmiని ఎలా పొందాలో సూచించాలి:
{
"nodes":[
{
"mac":[
"52:54:00:20:a2:2f"
],
"cpu":"8",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"control-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7001"
},
{
"mac":[
"52:54:00:79:0b:cb"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7002"
},
{
"mac":[
"52:54:00:a7:fe:27"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7003"
},
{
"mac":[
"52:54:00:98:e9:d6"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7004"
},
{
"mac":[
"52:54:00:6a:ea:be"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7005"
}
]
}ఇప్పుడు మనం వ్యంగ్యం కోసం చిత్రాలను సిద్ధం చేయాలి. దీన్ని చేయడానికి, వాటిని wget ద్వారా డౌన్‌లోడ్ చేసి, ఇన్‌స్టాల్ చేయండి:
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/overcloud-full.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/ironic-python-agent.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ ls -lh
total 1.9G
-rw-r--r--. 1 stack stack 447M Aug 14 10:26 ironic-python-agent.tar
-rw-r--r--. 1 stack stack 1.5G Aug 14 10:26 overcloud-full.tar
-rw-------. 1 stack stack 916 Aug 13 23:10 stackrc
-rw-r--r--. 1 stack stack 15K Aug 13 22:50 undercloud.conf
-rw-------. 1 stack stack 2.0K Aug 13 22:50 undercloud-passwords.conf
(undercloud) [stack@undercloud ~]$ mkdir images/
(undercloud) [stack@undercloud ~]$ tar -xpvf ironic-python-agent.tar -C ~/images/
ironic-python-agent.initramfs
ironic-python-agent.kernel
(undercloud) [stack@undercloud ~]$ tar -xpvf overcloud-full.tar -C ~/images/
overcloud-full.qcow2
overcloud-full.initrd
overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ ls -lh images/
total 1.9G
-rw-rw-r--. 1 stack stack 441M Aug 12 17:24 ironic-python-agent.initramfs
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:24 ironic-python-agent.kernel
-rw-r--r--. 1 stack stack 53M Aug 12 17:14 overcloud-full.initrd
-rw-r--r--. 1 stack stack 1.4G Aug 12 17:18 overcloud-full.qcow2
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:14 overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$అండర్‌క్లౌడ్‌కి చిత్రాలను అప్‌లోడ్ చేస్తోంది:
(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Image "overcloud-full-vmlinuz" was uploaded.
+--------------------------------------+------------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aki | 6761064 | active |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" was uploaded.
+--------------------------------------+-----------------------+-------------+----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | ari | 55183045 | active |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" was uploaded.
+--------------------------------------+----------------+-------------+------------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | qcow2 | 1487475712 | active |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" was uploaded.
+--------------------------------------+------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aki | 6761064 | active |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" was uploaded.
+--------------------------------------+-------------------+-------------+-----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | ari | 461759376 | active |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$అన్ని చిత్రాలు లోడ్ అయ్యాయో లేదో తనిఖీ చేస్తోంది
(undercloud) [stack@undercloud ~]$ openstack image list
+--------------------------------------+------------------------+--------+
| ID | Name | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | active |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | active |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | active |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | active |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | active |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$మరొక విషయం - మీరు DNS సర్వర్‌ని జోడించాలి:
(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID | Name | Network | Subnet |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field | Value |
+-------------------+-----------------------------------------------------------+
| allocation_pools | 192.168.255.11-192.168.255.50 |
| cidr | 192.168.255.0/24 |
| created_at | 2020-08-13T20:10:37Z |
| description | |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 192.168.255.1 |
| host_routes | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id | f45dea46-4066-42aa-a3c4-6f84b8120cab |
| ip_version | 4 |
| ipv6_address_mode | None |
| ipv6_ra_mode | None |
| name | ctlplane-subnet |
| network_id | 6ca013dc-41c2-42d8-9d69-542afad53392 |
| prefix_length | None |
| project_id | a844ccfcdb2745b198dde3e1b28c40a3 |
| revision_number | 0 |
| segment_id | None |
| service_types | |
| subnetpool_id | None |
| tags | |
| updated_at | 2020-08-13T20:10:37Z |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$ఇప్పుడు మనం ఆత్మపరిశీలన కోసం ఆదేశాన్ని ఇవ్వవచ్చు:
(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json
Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "manageable" state.
Successfully registered node UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Successfully registered node UUID b89a72a3-6bb7-429a-93bc-48393d225838
Successfully registered node UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Successfully registered node UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Successfully registered node UUID 766ab623-464c-423d-a529-d9afb69d1167
Waiting for introspection to finish...
Started Mistral Workflow tripleo.baremetal.v1.introspect. Execution ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Waiting for messages on queue 'tripleo' with no timeout.
Introspection of node b89a72a3-6bb7-429a-93bc-48393d225838 completed. Status:SUCCESS. Errors:None
Introspection of node 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e completed. Status:SUCCESS. Errors:None
Introspection of node bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 completed. Status:SUCCESS. Errors:None
Introspection of node 766ab623-464c-423d-a529-d9afb69d1167 completed. Status:SUCCESS. Errors:None
Introspection of node b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 completed. Status:SUCCESS. Errors:None
Successfully introspected 5 node(s).
Started Mistral Workflow tripleo.baremetal.v1.provide. Execution ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "available" state.
(undercloud) [stack@undercloud ~]$మీరు అవుట్‌పుట్ నుండి చూడగలిగినట్లుగా, ప్రతిదీ లోపాలు లేకుండా పూర్తయింది. అన్ని నోడ్‌లు అందుబాటులో ఉన్న స్థితిలో ఉన్నాయో లేదో తనిఖీ చేద్దాం:
(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None | power off | available | False |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None | power off | available | False |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None | power off | available | False |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None | power off | available | False |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None | power off | available | False |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ నోడ్‌లు వేరే స్థితిలో ఉంటే, సాధారణంగా నిర్వహించదగినవి, అప్పుడు ఏదో తప్పు జరిగింది మరియు మీరు లాగ్‌ని చూసి ఇది ఎందుకు జరిగిందో గుర్తించాలి. ఈ దృష్టాంతంలో మేము వర్చువలైజేషన్‌ని ఉపయోగిస్తున్నామని మరియు వర్చువల్ మిషన్లు లేదా vbmc వినియోగానికి సంబంధించి బగ్‌లు ఉండవచ్చని గుర్తుంచుకోండి.
తరువాత, ఏ నోడ్ ఏ ఫంక్షన్‌ను నిర్వహిస్తుందో మనం సూచించాలి - అంటే, నోడ్ ఏ ప్రొఫైల్‌ను అమలు చేస్తుందో సూచించండి:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available | None | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available | None | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available | None | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available | None | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available | None | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| ID | Name | RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| 168af640-7f40-42c7-91b2-989abc5c5d8f | swift-storage | 4096 | 40 | 0 | 1 | True |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal | 4096 | 40 | 0 | 1 | True |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control | 4096 | 40 | 0 | 1 | True |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 | 40 | 0 | 1 | True |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute | 4096 | 40 | 0 | 1 | True |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage | 4096 | 40 | 0 | 1 | True |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$ప్రతి నోడ్ కోసం ప్రొఫైల్‌ను పేర్కొనండి:
openstack baremetal node set --property capabilities='profile:control,boot_option:local' b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' b89a72a3-6bb7-429a-93bc-48393d225838
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 766ab623-464c-423d-a529-d9afb69d1167మేము ప్రతిదీ సరిగ్గా చేశామని తనిఖీ చేద్దాం:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available | control | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available | ceph-storage | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available | ceph-storage | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available | compute | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available | compute | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ప్రతిదీ సరిగ్గా ఉంటే, ఓవర్‌క్లౌడ్‌ని అమలు చేయడానికి మేము ఆదేశాన్ని ఇస్తాము:
openstack overcloud deploy --templates --control-scale 1 --compute-scale 2 --ceph-storage-scale 2 --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage --libvirt-type qemuనిజమైన ఇన్‌స్టాలేషన్‌లో, అనుకూలీకరించిన టెంప్లేట్‌లు సహజంగా ఉపయోగించబడతాయి, మా విషయంలో ఇది ప్రక్రియను చాలా క్లిష్టతరం చేస్తుంది, ఎందుకంటే టెంప్లేట్‌లోని ప్రతి సవరణను వివరించాలి. ఇంతకు ముందు వ్రాసినట్లుగా, ఇది ఎలా పని చేస్తుందో చూడడానికి ఒక సాధారణ సంస్థాపన కూడా సరిపోతుంది.
గమనిక: ఈ సందర్భంలో --libvirt-type qemu వేరియబుల్ అవసరం, ఎందుకంటే మనం నెస్టెడ్ వర్చువలైజేషన్‌ని ఉపయోగిస్తాము. లేకపోతే, మీరు వర్చువల్ మిషన్లను అమలు చేయలేరు.
ఇప్పుడు మీకు ఒక గంట లేదా అంతకంటే ఎక్కువ సమయం ఉంది (హార్డ్‌వేర్ సామర్థ్యాలను బట్టి) మరియు ఈ సమయం తర్వాత మీరు ఈ క్రింది సందేశాన్ని చూస్తారని మీరు ఆశించవచ్చు:
2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE Stack CREATE completed successfully
Stack overcloud CREATE_COMPLETE
Host 192.168.255.21 not found in /home/stack/.ssh/known_hosts
Started Mistral Workflow tripleo.deployment.v1.get_horizon_url. Execution ID: fcb996cd-6a19-482b-b755-2ca0c08069a9
Overcloud Endpoint: http://192.168.255.21:5000/
Overcloud Horizon Dashboard URL: http://192.168.255.21:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed
(undercloud) [stack@undercloud ~]$ఇప్పుడు మీరు ఓపెన్స్టాక్ యొక్క దాదాపు పూర్తి స్థాయి సంస్కరణను కలిగి ఉన్నారు, దానిపై మీరు అధ్యయనం చేయవచ్చు, ప్రయోగాలు చేయవచ్చు మొదలైనవి.
ప్రతిదీ సరిగ్గా పని చేస్తుందో లేదో తనిఖీ చేద్దాం. వినియోగదారు హోమ్ డైరెక్టరీ స్టాక్‌లో రెండు ఫైల్‌లు ఉన్నాయి - ఒకటి స్టాక్‌క్లౌడ్ (అండర్‌క్లౌడ్‌ని నిర్వహించడానికి) మరియు రెండవ ఓవర్‌క్లౌడ్‌ర్క్ (ఓవర్‌క్లౌడ్ నిర్వహణ కోసం). ఈ ఫైల్‌లు తప్పనిసరిగా మూలాధారంగా పేర్కొనబడాలి, ఎందుకంటే అవి ప్రామాణీకరణకు అవసరమైన సమాచారాన్ని కలిగి ఉంటాయి.
(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID | Name | Status | Networks | Image | Flavor |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0 | ACTIVE | ctlplane=192.168.255.15 | overcloud-full | control |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | ACTIVE | ctlplane=192.168.255.26 | overcloud-full | compute |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | ACTIVE | ctlplane=192.168.255.34 | overcloud-full | ceph-storage |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | ACTIVE | ctlplane=192.168.255.19 | overcloud-full | compute |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | ACTIVE | ctlplane=192.168.255.44 | overcloud-full | ceph-storage |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ source overcloudrc
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack project list
+----------------------------------+---------+
| ID | Name |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin |
| ee1c68758bde41eaa9912c81dc67dad8 | service |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$నా ఇన్‌స్టాలేషన్‌కు ఇప్పటికీ ఒక చిన్న టచ్ అవసరం - నేను పని చేస్తున్న మెషీన్ వేరే నెట్‌వర్క్‌లో ఉన్నందున, కంట్రోలర్‌లో మార్గాన్ని జోడించడం. దీన్ని చేయడానికి, హీట్-అడ్మిన్ ఖాతా కింద కంట్రోల్-1కి వెళ్లి మార్గాన్ని నమోదు చేయండి
(undercloud) [stack@undercloud ~]$ ssh [email protected]
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254బాగా, ఇప్పుడు మీరు హోరిజోన్‌లోకి వెళ్ళవచ్చు. మొత్తం సమాచారం - చిరునామాలు, లాగిన్ మరియు పాస్‌వర్డ్ - ఫైల్ /home/stack/overcloudrcలో ఉన్నాయి. చివరి రేఖాచిత్రం ఇలా కనిపిస్తుంది:
మార్గం ద్వారా, మా ఇన్‌స్టాలేషన్‌లో, యంత్ర చిరునామాలు DHCP ద్వారా జారీ చేయబడ్డాయి మరియు మీరు చూడగలిగినట్లుగా, అవి "యాదృచ్ఛికంగా" జారీ చేయబడతాయి. మీకు అవసరమైతే, విస్తరణ సమయంలో ఏ మెషీన్‌కు ఏ చిరునామా జోడించబడాలో మీరు టెంప్లేట్‌లో ఖచ్చితంగా నిర్వచించవచ్చు.
వర్చువల్ మిషన్ల మధ్య ట్రాఫిక్ ఎలా ప్రవహిస్తుంది?
ఈ వ్యాసంలో మేము ట్రాఫిక్‌ను దాటడానికి మూడు ఎంపికలను పరిశీలిస్తాము
- ఒక L2 నెట్‌వర్క్‌లో ఒక హైపర్‌వైజర్‌పై రెండు యంత్రాలు
- ఒకే L2 నెట్‌వర్క్‌లో వేర్వేరు హైపర్‌వైజర్‌లపై రెండు యంత్రాలు
- వేర్వేరు నెట్‌వర్క్‌లలో రెండు యంత్రాలు (క్రాస్-నెట్వర్క్ రూటింగ్)
బాహ్య నెట్వర్క్ ద్వారా బయటి ప్రపంచానికి ప్రాప్యత ఉన్న కేసులు, ఫ్లోటింగ్ చిరునామాలు, అలాగే పంపిణీ చేయబడిన రూటింగ్ ఉపయోగించి, మేము తదుపరిసారి పరిశీలిస్తాము, ప్రస్తుతానికి మేము అంతర్గత ట్రాఫిక్‌పై దృష్టి పెడతాము.
తనిఖీ చేయడానికి, కింది రేఖాచిత్రాన్ని కలపండి:
మేము 4 వర్చువల్ మెషీన్‌లను సృష్టించాము - 3 ఒక L2 నెట్‌వర్క్‌లో - net-1 మరియు 1 నెట్-2 నెట్‌వర్క్‌లో
(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID | Name | Tenant ID | Status | Task State | Power State | Networks |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-2=10.0.2.8 |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ సృష్టించిన యంత్రాలు ఏ హైపర్‌వైజర్‌లపై ఉన్నాయో చూద్దాం:
(overcloud) [stack@undercloud ~]$ nova show f53b37b5-2204-46cc-aef0-dba84bf970c0 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-1 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000001 |(overcloud) [stack@undercloud ~]$ nova show fc8b6722-0231-49b0-b2fa-041115bef34a | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-2 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000002 |(overcloud) [stack@undercloud ~]$ nova show 3cd74455-b9b7-467a-abe3-bd6ff765c83c | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-3 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000003 |(overcloud) [stack@undercloud ~]$ nova show 7e836338-6772-46b0-9950-f7f06dbe91a8 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-4 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000004 |
(ఓవర్‌క్లౌడ్) [stack@undercloud ~]$
యంత్రాలు vm-1 మరియు vm-3 కంప్యూట్-0లో ఉన్నాయి, యంత్రాలు vm-2 మరియు vm-4 నోడ్ కంప్యూట్-1లో ఉన్నాయి.
అదనంగా, పేర్కొన్న నెట్‌వర్క్‌ల మధ్య రూటింగ్‌ని ప్రారంభించడానికి వర్చువల్ రూటర్ సృష్టించబడింది:
(overcloud) [stack@undercloud ~]$ openstack router list --project 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| ID | Name | Status | State | Distributed | HA | Project |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | router-1 | ACTIVE | UP | False | False | 5e18ce8ec9594e00b155485f19895e6c |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
(overcloud) [stack@undercloud ~]$ రూటర్‌లో రెండు వర్చువల్ పోర్ట్‌లు ఉన్నాయి, ఇవి నెట్‌వర్క్‌లకు గేట్‌వేలుగా పనిచేస్తాయి:
(overcloud) [stack@undercloud ~]$ openstack router show 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | grep interface
| interfaces_info | [{"subnet_id": "2529ad1a-6b97-49cd-8515-cbdcbe5e3daa", "ip_address": "10.0.1.254", "port_id": "0c52b15f-8fcc-4801-bf52-7dacc72a5201"}, {"subnet_id": "335552dd-b35b-456b-9df0-5aac36a3ca13", "ip_address": "10.0.2.254", "port_id": "92fa49b5-5406-499f-ab8d-ddf28cc1a76c"}] |
(overcloud) [stack@undercloud ~]$ అయితే ట్రాఫిక్ ఎలా ప్రవహిస్తుందో చూసే ముందు, మనం ప్రస్తుతం కంట్రోల్ నోడ్‌లో (ఇది నెట్వర్క్ నోడ్ కూడా) మరియు కంప్యూట్ నోడ్‌లో ఏమి ఉందో చూద్దాం. కంప్యూట్ నోడ్‌తో ప్రారంభిద్దాం.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl show
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:3 missed:3
br-ex:
br-ex 65534/1: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$ప్రస్తుతానికి, నోడ్‌లో మూడు ovs వంతెనలు ఉన్నాయి - br-int, br-tun, br-ex. వాటి మధ్య, మనం చూస్తున్నట్లుగా, ఇంటర్‌ఫేస్‌ల సమితి ఉంది. సులభంగా అర్థం చేసుకోవడానికి, రేఖాచిత్రంలో ఈ ఇంటర్‌ఫేస్‌లన్నింటినీ ప్లాట్ చేసి, ఏమి జరుగుతుందో చూద్దాం.
VxLAN సొరంగాలు లేవనెత్తిన చిరునామాలను చూస్తే, కంప్యూట్-1 (192.168.255.26)కి ఒక సొరంగం పైకి లేపబడిందని చూడవచ్చు, రెండవ సొరంగం నియంత్రణ-1 (192.168.255.15)గా కనిపిస్తుంది. కానీ చాలా ఆసక్తికరమైన విషయం ఏమిటంటే, br-ex భౌతిక ఇంటర్‌ఫేస్‌లను కలిగి ఉండదు మరియు మీరు ఏ ప్రవాహాలు కాన్ఫిగర్ చేయబడిందో చూస్తే, ఈ వంతెన ప్రస్తుతానికి ట్రాఫిక్‌ను మాత్రమే తగ్గించగలదని మీరు చూడవచ్చు.
[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.19 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe6a:eabe prefixlen 64 scopeid 0x20<link>
ether 52:54:00:6a:ea:be txqueuelen 1000 (Ethernet)
RX packets 2909669 bytes 4608201000 (4.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1821057 bytes 349198520 (333.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-novacompute-0 ~]$ మీరు అవుట్‌పుట్ నుండి చూడగలిగినట్లుగా, చిరునామా భౌతిక పోర్ట్‌కు నేరుగా స్క్రూ చేయబడింది మరియు వర్చువల్ బ్రిడ్జ్ ఇంటర్‌ఫేస్‌కు కాదు.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-ex
cookie=0x9169eae8f7fe5bb2, duration=216686.864s, table=0, n_packets=303, n_bytes=26035, priority=2,in_port="phy-br-ex" actions=drop
cookie=0x9169eae8f7fe5bb2, duration=216686.887s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL
[heat-admin@overcloud-novacompute-0 ~]$
మొదటి నియమం ప్రకారం, phy-br-ex పోర్ట్ నుండి వచ్చిన ప్రతిదీ తప్పనిసరిగా విస్మరించబడాలి.
వాస్తవానికి, ఈ ఇంటర్‌ఫేస్ (br-intతో ఉన్న ఇంటర్‌ఫేస్) నుండి తప్ప ఈ వంతెనలోకి ట్రాఫిక్ రావడానికి ప్రస్తుతం మరెక్కడా లేదు మరియు చుక్కలను బట్టి చూస్తే, BUM ట్రాఫిక్ ఇప్పటికే వంతెనపైకి వెళ్లింది.
అంటే, ట్రాఫిక్ ఈ నోడ్‌ను VxLAN సొరంగం ద్వారా మాత్రమే వదిలివేయగలదు మరియు మరేమీ కాదు. అయితే, మీరు DVRని ఆన్ చేస్తే, పరిస్థితి మారుతుంది, కానీ మేము దానిని మరొకసారి పరిష్కరించుకుంటాము. నెట్వర్క్ ఐసోలేషన్‌ని ఉపయోగిస్తున్నప్పుడు, ఉదాహరణకు vlansని ఉపయోగిస్తున్నప్పుడు, మీకు vlan 3లో ఒక L0 ఇంటర్‌ఫేస్ ఉండదు, కానీ అనేక ఇంటర్‌ఫేస్‌లు ఉంటాయి. అయినప్పటికీ, VxLAN ట్రాఫిక్ నోడ్‌ను అదే విధంగా వదిలివేస్తుంది, కానీ ఒకరకమైన అంకితమైన vlanలో కూడా సంగ్రహించబడుతుంది.
మేము కంప్యూట్ నోడ్‌ను క్రమబద్ధీకరించాము, కంట్రోల్ నోడ్‌కి వెళ్దాం.
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl dpif/show
system@ovs-system: hit:930491 missed:825
br-ex:
br-ex 65534/1: (internal)
eth0 1/2: (system)
phy-br-ex 2/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/3: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/4: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff13 3/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.19)
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$వాస్తవానికి, ప్రతిదీ ఒకేలా ఉందని మేము చెప్పగలం, కానీ IP చిరునామా భౌతిక ఇంటర్‌ఫేస్‌లో ఉండదు కానీ వర్చువల్ వంతెనపై ఉంటుంది. ఈ పోర్ట్ బయటి ప్రపంచానికి ట్రాఫిక్ నిష్క్రమించే ఓడరేవు కాబట్టి ఇది జరుగుతుంది.
[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.15 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe20:a22f prefixlen 64 scopeid 0x20<link>
ether 52:54:00:20:a2:2f txqueuelen 1000 (Ethernet)
RX packets 803859 bytes 1732616116 (1.6 GiB)
RX errors 0 dropped 63 overruns 0 frame 0
TX packets 808475 bytes 121652156 (116.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
3 100 28:c0:da:00:4d:d3 35
1 0 28:c0:da:00:4d:d3 35
1 0 52:54:00:98:e9:d6 0
LOCAL 0 52:54:00:20:a2:2f 0
1 0 52:54:00:2c:08:9e 0
3 100 52:54:00:20:a2:2f 0
1 0 52:54:00:6a:ea:be 0
[heat-admin@overcloud-controller-0 ~]$ ఈ పోర్ట్ br-ex బ్రిడ్జ్‌తో ముడిపడి ఉంది మరియు దానిపై ఎటువంటి vlan ట్యాగ్‌లు లేనందున, ఈ పోర్ట్ అన్ని vlanలు అనుమతించబడే ట్రంక్ పోర్ట్, ఇప్పుడు ట్రాఫిక్ ట్యాగ్ లేకుండానే బయటికి వెళుతుంది, ఇది vlan-id 0 ద్వారా సూచించబడింది పైన అవుట్‌పుట్.
ప్రస్తుతానికి మిగతావన్నీ కంప్యూట్ నోడ్‌ను పోలి ఉంటాయి - అదే వంతెనలు, రెండు కంప్యూట్ నోడ్‌లకు ఒకే సొరంగాలు వెళుతున్నాయి.
మేము ఈ కథనంలో నిల్వ నోడ్‌లను పరిగణించము, కానీ అర్థం చేసుకోవడానికి ఈ నోడ్‌ల యొక్క నెట్వర్క్ భాగం అవమానకరమైన స్థాయికి సామాన్యమైనది అని చెప్పడం అవసరం. మా విషయంలో, దానికి కేటాయించిన IP చిరునామాతో ఒక భౌతిక పోర్ట్ (eth0) మాత్రమే ఉంది మరియు అంతే. VxLAN సొరంగాలు, సొరంగం వంతెనలు మొదలైనవి లేవు - ఇందులో ఎటువంటి పాయింట్ లేనందున ovs అస్సలు లేదు. నెట్వర్క్ ఐసోలేషన్‌ను ఉపయోగిస్తున్నప్పుడు, ఈ నోడ్‌లో రెండు ఇంటర్‌ఫేస్‌లు ఉంటాయి (ఫిజికల్ పోర్ట్‌లు, బాడ్నీ లేదా రెండు vlans - ఇది పర్వాలేదు - ఇది మీకు కావలసినదానిపై ఆధారపడి ఉంటుంది) - ఒకటి నిర్వహణ కోసం, రెండవది ట్రాఫిక్ (VM డిస్క్‌కి వ్రాయడం , డిస్క్ నుండి చదవడం మొదలైనవి)
ఏ సేవలు లేనప్పుడు మేము నోడ్‌లలో ఏమి కలిగి ఉన్నాము అని మేము కనుగొన్నాము. ఇప్పుడు 4 వర్చువల్ మెషీన్‌లను ప్రారంభిద్దాం మరియు పైన వివరించిన స్కీమ్ ఎలా మారుతుందో చూద్దాం - మనకు పోర్ట్‌లు, వర్చువల్ రౌటర్లు మొదలైనవి ఉండాలి.
ఇప్పటివరకు మా నెట్వర్క్ ఇలా కనిపిస్తుంది:
ప్రతి కంప్యూటర్ నోడ్‌లో మనకు రెండు వర్చువల్ మిషన్లు ఉన్నాయి. కంప్యూట్-0ని ఉదాహరణగా ఉపయోగించి, ప్రతిదీ ఎలా చేర్చబడిందో చూద్దాం.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ యంత్రానికి ఒకే ఒక వర్చువల్ ఇంటర్‌ఫేస్ ఉంది - tap95d96a75-a0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
ఈ ఇంటర్‌ఫేస్ linux వంతెనలో కనిపిస్తుంది:
[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.0242904c92a8 no
qbr5bd37136-47 8000.5e4e05841423 no qvb5bd37136-47
tap5bd37136-47
qbr95d96a75-a0 8000.de076cb850f6 no qvb95d96a75-a0
tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ మీరు అవుట్‌పుట్ నుండి చూడగలిగినట్లుగా, వంతెనలో కేవలం రెండు ఇంటర్‌ఫేస్‌లు మాత్రమే ఉన్నాయి - tap95d96a75-a0 మరియు qvb95d96a75-a0.
ఇక్కడ ఓపెన్‌స్టాక్‌లోని వర్చువల్ నెట్వర్క్ పరికరాల రకాలపై కొంచెం ఆలోచించడం విలువైనదే:
vtap - వర్చువల్ ఇంటర్‌ఫేస్ ఒక ఉదాహరణకి జోడించబడింది (VM)
qbr - Linux వంతెన
qvb మరియు qvo - vEth జత Linux వంతెనకు కనెక్ట్ చేయబడింది మరియు vSwitch వంతెనను తెరవండి
br-int, br-tun, br-vlan — vSwitch వంతెనలను తెరవండి
patch-, int-br-, phy-br- - ఓపెన్ vSwitch ప్యాచ్ ఇంటర్‌ఫేస్‌లను కలిపే వంతెనలు
qg, qr, ha, fg, sg - OVSకి కనెక్ట్ చేయడానికి వర్చువల్ పరికరాల ద్వారా ఉపయోగించే vSwitch పోర్ట్‌లను తెరవండి
మీరు అర్థం చేసుకున్నట్లుగా, మేము వంతెనలో qvb95d96a75-a0 పోర్ట్‌ను కలిగి ఉన్నట్లయితే, అది vEth జత అయితే, ఎక్కడో దాని ప్రతిరూపం ఉంది, దానిని తార్కికంగా qvo95d96a75-a0 అని పిలవాలి. OVSలో ఏ పోర్టులు ఉన్నాయో చూద్దాం.
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:526 missed:91
br-ex:
br-ex 65534/1: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
qvo5bd37136-47 6/6: (system)
qvo95d96a75-a0 3/5: (system)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$ మనం చూడగలిగినట్లుగా, పోర్ట్ br-int లో ఉంది. Br-int వర్చువల్ మెషిన్ పోర్ట్‌లను ముగించే స్విచ్‌గా పనిచేస్తుంది. qvo95d96a75-a0తో పాటు, పోర్ట్ qvo5bd37136-47 అవుట్‌పుట్‌లో కనిపిస్తుంది. ఇది రెండవ వర్చువల్ మెషీన్‌కు పోర్ట్. ఫలితంగా, మా రేఖాచిత్రం ఇప్పుడు ఇలా కనిపిస్తుంది:
శ్రద్ధగల రీడర్‌కు వెంటనే ఆసక్తి కలిగించే ప్రశ్న - వర్చువల్ మెషిన్ పోర్ట్ మరియు OVS పోర్ట్ మధ్య లైనక్స్ వంతెన ఏమిటి? వాస్తవం ఏమిటంటే, యంత్రాన్ని రక్షించడానికి, భద్రతా సమూహాలు ఉపయోగించబడతాయి, ఇవి iptables కంటే మరేమీ కాదు. OVS iptablesతో పనిచేయదు, కాబట్టి ఈ "క్రచ్" కనుగొనబడింది. అయినప్పటికీ, ఇది వాడుకలో లేదు - ఇది కొత్త విడుదలలలో కాంట్రాక్ ద్వారా భర్తీ చేయబడుతోంది.
అంటే, చివరికి పథకం ఇలా కనిపిస్తుంది:
ఒక L2 నెట్‌వర్క్‌లో ఒక హైపర్‌వైజర్‌పై రెండు యంత్రాలు
ఈ రెండు VMలు ఒకే L2 నెట్‌వర్క్‌లో మరియు ఒకే హైపర్‌వైజర్‌లో ఉన్నందున, రెండు యంత్రాలు ఒకే VLANలో ఉంటాయి కాబట్టి వాటి మధ్య ట్రాఫిక్ తార్కికంగా br-int ద్వారా స్థానికంగా ప్రవహిస్తుంది:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000003
Interface Type Source Model MAC
-------------------------------------------------------
tap5bd37136-47 bridge qbr5bd37136-47 virtio fa:16:3e:83:ad:a4
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int
port VLAN MAC Age
6 1 fa:16:3e:83:ad:a4 0
3 1 fa:16:3e:44:98:20 0
[heat-admin@overcloud-novacompute-0 ~]$ ఒకే L2 నెట్‌వర్క్‌లో వేర్వేరు హైపర్‌వైజర్‌లపై రెండు యంత్రాలు
ఇప్పుడు ఒకే L2 నెట్‌వర్క్‌లోని రెండు మెషీన్ల మధ్య ట్రాఫిక్ ఎలా వెళ్తుందో చూద్దాం, కానీ వేర్వేరు హైపర్‌వైజర్‌లలో ఉంది. నిజం చెప్పాలంటే, ఏమీ పెద్దగా మారదు, హైపర్‌వైజర్‌ల మధ్య ట్రాఫిక్ vxlan సొరంగం గుండా వెళుతుంది. ఒక ఉదాహరణ చూద్దాం.
మేము ట్రాఫిక్‌ని చూసే వర్చువల్ మిషన్ల చిరునామాలు:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000002
Interface Type Source Model MAC
-------------------------------------------------------
tape7e23f1b-07 bridge qbre7e23f1b-07 virtio fa:16:3e:72:ad:53
[heat-admin@overcloud-novacompute-1 ~]$ మేము కంప్యూట్-0లో br-intలో ఫార్వార్డింగ్ పట్టికను చూస్తాము:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:72:ad:53
2 1 fa:16:3e:72:ad:53 1
[heat-admin@overcloud-novacompute-0 ~]ట్రాఫిక్ పోర్ట్ 2కి వెళ్లాలి - ఇది ఎలాంటి పోర్ట్ అని చూద్దాం:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:7e:7f:28:1f:bd:54
2(patch-tun): addr:0a:bd:07:69:58:d9
3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$ఇది ప్యాచ్-టన్ - అంటే, br-tun లో ఇంటర్‌ఫేస్. Br-tunలో ప్యాకేజీకి ఏమి జరుగుతుందో చూద్దాం:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:72:ad:53
cookie=0x8759a56536b67a8e, duration=1387.959s, table=20, n_packets=1460, n_bytes=138880, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:72:ad:53 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-novacompute-0 ~]$ ప్యాకెట్ VxLANలో ప్యాక్ చేయబడింది మరియు పోర్ట్ 2కి పంపబడింది. పోర్ట్ 2 ఎక్కడికి దారితీస్తుందో చూద్దాం:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:b2:d1:f8:21:96:66
2(vxlan-c0a8ff1a): addr:be:64:1f:75:78:a7
3(vxlan-c0a8ff0f): addr:76:6f:b9:3c:3f:1c
LOCAL(br-tun): addr:a2:5b:6d:4f:94:47
[heat-admin@overcloud-novacompute-0 ~]$ఇది కంప్యూట్-1లో ఒక vxlan టన్నెల్:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl dpif/show | egrep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$కంప్యూట్-1కి వెళ్లి, ప్యాకేజీతో తర్వాత ఏమి జరుగుతుందో చూద్దాం:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:44:98:20
2 1 fa:16:3e:44:98:20 1
[heat-admin@overcloud-novacompute-1 ~]$ Mac కంప్యూట్-1లో br-int ఫార్వార్డింగ్ టేబుల్‌లో ఉంది మరియు పై అవుట్‌పుట్ నుండి చూడగలిగినట్లుగా, ఇది పోర్ట్ 2 ద్వారా కనిపిస్తుంది, ఇది br-tun వైపు పోర్ట్:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46సరే, కంప్యూట్-1లోని br-intలో డెస్టినేషన్ గసగసాలు ఉన్నట్లు మనం చూస్తాము:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:72:ad:53
3 1 fa:16:3e:72:ad:53 0
[heat-admin@overcloud-novacompute-1 ~]$ అంటే, అందుకున్న ప్యాకెట్ పోర్ట్ 3కి ఎగురుతుంది, దాని వెనుక ఇప్పటికే వర్చువల్ మెషీన్ ఇన్‌స్టాన్స్-00000003 ఉంది.
వర్చువల్ ఇన్‌ఫ్రాస్ట్రక్చర్‌పై నేర్చుకోవడం కోసం ఓపెన్‌స్టాక్‌ని అమలు చేయడంలోని అందం ఏమిటంటే, మనం హైపర్‌వైజర్‌ల మధ్య ట్రాఫిక్‌ను సులభంగా క్యాప్చర్ చేయవచ్చు మరియు దానితో ఏమి జరుగుతుందో చూడవచ్చు. ఇప్పుడు మనం చేసేది ఇదే, కంప్యూట్-0 వైపు vnet పోర్ట్‌లో tcpdump ను అమలు చేయండి:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
*****************omitted*******************మొదటి పంక్తి చిరునామా 10.0.1.85 నుండి పటేక్ చిరునామా 10.0.1.88 (ICMP ట్రాఫిక్)కి వెళుతుందని చూపిస్తుంది మరియు ఇది VxLAN ప్యాకెట్‌లో vni 22తో చుట్టబడి ఉంటుంది మరియు ప్యాకెట్ హోస్ట్ 192.168.255.19 (కంప్యూట్-0) నుండి హోస్ట్ 192.168.255.26కి వెళ్తుంది. .1 (కంప్యూట్-XNUMX). VNI ovsలో పేర్కొన్న దానితో సరిపోలుతుందో లేదో మేము తనిఖీ చేయవచ్చు.
ఈ లైన్ చర్యలకు తిరిగి వెళ్దాం=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. హెక్సాడెసిమల్ నంబర్ సిస్టమ్‌లో 0x16 vni. ఈ సంఖ్యను 16వ సిస్టమ్‌కి మారుద్దాం:
16 = 6*16^0+1*16^1 = 6+16 = 22అంటే, vni వాస్తవికతకు అనుగుణంగా ఉంటుంది.
రెండవ పంక్తి రిటర్న్ ట్రాఫిక్‌ను చూపుతుంది, బాగా, దానిని వివరించడంలో అర్థం లేదు, అక్కడ ప్రతిదీ స్పష్టంగా ఉంది.
వేర్వేరు నెట్‌వర్క్‌లలో రెండు యంత్రాలు (ఇంటర్-నెట్వర్క్ రూటింగ్)
వర్చువల్ రూటర్‌ని ఉపయోగించి ఒక ప్రాజెక్ట్‌లోని నెట్‌వర్క్‌ల మధ్య రూటింగ్ చేయడం నేటి చివరి సందర్భం. మేము DVR లేని కేసును పరిశీలిస్తున్నాము (మేము దానిని మరొక కథనంలో పరిశీలిస్తాము), కాబట్టి నెట్వర్క్ నోడ్‌లో రూటింగ్ జరుగుతుంది. మా సందర్భంలో, నెట్వర్క్ నోడ్ ప్రత్యేక ఎంటిటీలో ఉంచబడలేదు మరియు నియంత్రణ నోడ్‌లో ఉంది.
ముందుగా, రూటింగ్ పని చేస్తుందో చూద్దాం:
$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bytes from 10.0.2.8: seq=0 ttl=63 time=7.727 ms
64 bytes from 10.0.2.8: seq=1 ttl=63 time=3.832 ms
^C
--- 10.0.2.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.832/5.779/7.727 msఈ సందర్భంలో ప్యాకెట్ తప్పనిసరిగా గేట్‌వేకి వెళ్లి అక్కడకు మళ్లించబడాలి కాబట్టి, మేము గేట్‌వే యొక్క గసగసాల చిరునామాను కనుగొనాలి, దీని కోసం మేము ఉదాహరణలో ARP పట్టికను చూస్తాము:
$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether] on eth0
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether] on eth0
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether] on eth0
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether] on eth0ఇప్పుడు గమ్యం (10.0.1.254) fa:16:3e:c4:64:70 ఉన్న ట్రాఫిక్‌ని ఎక్కడికి పంపాలో చూద్దాం:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:c4:64:70
2 1 fa:16:3e:c4:64:70 0
[heat-admin@overcloud-novacompute-0 ~]$ పోర్ట్ 2 ఎక్కడికి దారితీస్తుందో చూద్దాం:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:7e:7f:28:1f:bd:54
2(patch-tun): addr:0a:bd:07:69:58:d9
3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$ ప్రతిదీ తార్కికంగా ఉంది, ట్రాఫిక్ br-tunకి వెళుతుంది. ఇది ఏ vxlan సొరంగంలో చుట్టబడి ఉంటుందో చూద్దాం:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:c4:64:70
cookie=0x8759a56536b67a8e, duration=3514.566s, table=20, n_packets=3368, n_bytes=317072, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:c4:64:70 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3
[heat-admin@overcloud-novacompute-0 ~]$ మూడవ పోర్ట్ vxlan సొరంగం:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ ఇది నియంత్రణ నోడ్‌ను చూస్తుంది:
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ ట్రాఫిక్ కంట్రోల్ నోడ్‌కు చేరుకుంది, కాబట్టి మనం దాని వద్దకు వెళ్లి రూటింగ్ ఎలా జరుగుతుందో చూడాలి.
మీకు గుర్తున్నట్లుగా, లోపల ఉన్న కంట్రోల్ నోడ్ కంప్యూట్ నోడ్ లాగానే కనిపిస్తుంది - అదే మూడు వంతెనలు, కేవలం br-ex మాత్రమే భౌతిక పోర్ట్‌ను కలిగి ఉంది, దీని ద్వారా నోడ్ బయటికి ట్రాఫిక్‌ని పంపగలదు. ఇన్‌స్టాన్స్‌ల సృష్టి కంప్యూట్ నోడ్‌లపై కాన్ఫిగరేషన్‌ను మార్చింది - లైనక్స్ బ్రిడ్జ్, iptables మరియు ఇంటర్‌ఫేస్‌లు నోడ్‌లకు జోడించబడ్డాయి. నెట్‌వర్క్‌ల సృష్టి మరియు వర్చువల్ రౌటర్ కూడా కంట్రోల్ నోడ్ యొక్క కాన్ఫిగరేషన్‌పై దాని గుర్తును వదిలివేసింది.
కాబట్టి, గేట్‌వే MAC చిరునామా తప్పనిసరిగా కంట్రోల్ నోడ్‌లోని br-int ఫార్వార్డింగ్ టేబుల్‌లో ఉండాలి అని స్పష్టంగా తెలుస్తుంది. అది అక్కడ ఉందో, ఎక్కడ వెతుకుతుందో చూద్దాం:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:c4:64:70
5 1 fa:16:3e:c4:64:70 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ Mac పోర్ట్ qr-0c52b15f-8f నుండి కనిపిస్తుంది. మేము ఓపెన్‌స్టాక్‌లోని వర్చువల్ పోర్ట్‌ల జాబితాకు తిరిగి వెళితే, ఈ రకమైన పోర్ట్ వివిధ వర్చువల్ పరికరాలను OVSకి కనెక్ట్ చేయడానికి ఉపయోగించబడుతుంది. మరింత ఖచ్చితంగా చెప్పాలంటే, qr అనేది వర్చువల్ రూటర్‌కి పోర్ట్, ఇది నేమ్‌స్పేస్‌గా సూచించబడుతుంది.
సర్వర్‌లో నేమ్‌స్పేస్‌లు ఏమిటో చూద్దాం:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ మూడు కాపీలు ఎక్కువ. కానీ పేర్లను బట్టి చూస్తే, వాటిలో ప్రతి ప్రయోజనం ఏమిటో మీరు ఊహించవచ్చు. మేము ID 0 మరియు 1తో ఉన్న సందర్భాలకు తిరిగి వస్తాము, ఇప్పుడు మేము నేమ్‌స్పేస్ qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abeపై ఆసక్తి కలిగి ఉన్నాము:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ip route
10.0.1.0/24 dev qr-0c52b15f-8f proto kernel scope link src 10.0.1.254
10.0.2.0/24 dev qr-92fa49b5-54 proto kernel scope link src 10.0.2.254
[heat-admin@overcloud-controller-0 ~]$ ఈ నేమ్‌స్పేస్ మనం ఇంతకు ముందు సృష్టించిన రెండు అంతర్గత వాటిని కలిగి ఉంది. రెండు వర్చువల్ పోర్ట్‌లు br-intకి జోడించబడ్డాయి. పోర్ట్ qr-0c52b15f-8f యొక్క Mac చిరునామాను తనిఖీ చేద్దాం, ట్రాఫిక్, గమ్యస్థానం Mac చిరునామా ద్వారా నిర్ణయించడం, ఈ ఇంటర్‌ఫేస్‌కు వెళ్లింది.
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.254 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fec4:6470 prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:c4:64:70 txqueuelen 1000 (Ethernet)
RX packets 5356 bytes 427305 (417.2 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5195 bytes 490603 (479.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$ అంటే, ఈ సందర్భంలో, ప్రతిదీ ప్రామాణిక రౌటింగ్ చట్టాల ప్రకారం పనిచేస్తుంది. ట్రాఫిక్ హోస్ట్ 10.0.2.8 కోసం ఉద్దేశించబడినందున, అది తప్పనిసరిగా రెండవ ఇంటర్‌ఫేస్ qr-92fa49b5-54 ద్వారా నిష్క్రమించాలి మరియు కంప్యూట్ నోడ్‌కు vxlan టన్నెల్ ద్వారా వెళ్లాలి:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe arp
Address HWtype HWaddress Flags Mask Iface
10.0.1.88 ether fa:16:3e:72:ad:53 C qr-0c52b15f-8f
10.0.1.90 ether fa:16:3e:83:ad:a4 C qr-0c52b15f-8f
10.0.2.8 ether fa:16:3e:6c:ad:9c C qr-92fa49b5-54
10.0.2.42 ether fa:16:3e:f5:0b:29 C qr-92fa49b5-54
10.0.1.85 ether fa:16:3e:44:98:20 C qr-0c52b15f-8f
[heat-admin@overcloud-controller-0 ~]$ ప్రతిదీ తార్కికంగా ఉంది, ఆశ్చర్యం లేదు. హోస్ట్ 10.0.2.8 యొక్క గసగసాల చిరునామా br-intలో ఎక్కడ కనిపిస్తుందో చూద్దాం:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
2 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ ఊహించిన విధంగా, ట్రాఫిక్ br-tunకి వెళుతుంది, తర్వాత ట్రాఫిక్ ఏ సొరంగంలోకి వెళ్తుందో చూద్దాం:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:6c:ad:9c
cookie=0x2ab04bf27114410e, duration=5346.829s, table=20, n_packets=5248, n_bytes=498512, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0002/0x0fff,dl_dst=fa:16:3e:6c:ad:9c actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ కంప్యూట్-1 కోసం ట్రాఫిక్ సొరంగంలోకి వెళుతుంది. సరే, కంప్యూట్-1లో ప్రతిదీ చాలా సులభం - br-tun నుండి ప్యాకేజీ br-intకి మరియు అక్కడి నుండి వర్చువల్ మెషిన్ ఇంటర్‌ఫేస్‌కి వెళుతుంది:
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
4 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46
[heat-admin@overcloud-novacompute-1 ~]$ ఇది నిజంగా సరైన ఇంటర్‌ఫేస్ అని తనిఖీ చేద్దాం:
[heat-admin@overcloud-novacompute-1 ~]$ brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.02429c001e1c no
qbr3210e8ec-c0 8000.ea27f45358be no qvb3210e8ec-c0
tap3210e8ec-c0
qbre7e23f1b-07 8000.b26ac0eded8a no qvbe7e23f1b-07
tape7e23f1b-07
[heat-admin@overcloud-novacompute-1 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000004
Interface Type Source Model MAC
-------------------------------------------------------
tap3210e8ec-c0 bridge qbr3210e8ec-c0 virtio fa:16:3e:6c:ad:9c
[heat-admin@overcloud-novacompute-1 ~]$
వాస్తవానికి, మేము ప్యాకేజీ ద్వారా అన్ని విధాలుగా వెళ్ళాము. ట్రాఫిక్ వివిధ vxlan సొరంగాల గుండా వెళ్లి వివిధ VNIలతో నిష్క్రమించిందని మీరు గమనించారని అనుకుంటున్నాను. ఇవి ఏ రకమైన VNI అని చూద్దాం, దాని తర్వాత మేము నోడ్ యొక్క కంట్రోల్ పోర్ట్‌లో డంప్‌ను సేకరిస్తాము మరియు పైన వివరించిన విధంగా ట్రాఫిక్ సరిగ్గా ప్రవహించేలా చూస్తాము.
కాబట్టి, కంప్యూట్-0కి సొరంగం కింది చర్యలను కలిగి ఉంటుంది=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],అవుట్‌పుట్:3. 0x16ను దశాంశ సంఖ్య వ్యవస్థకు మారుద్దాం:
0x16 = 6*16^0+1*16^1 = 6+16 = 22కంప్యూట్-1కి సొరంగం క్రింది VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],అవుట్‌పుట్:2ని కలిగి ఉంది. 0x63ని దశాంశ సంఖ్య వ్యవస్థకు మారుద్దాం:
0x63 = 3*16^0+6*16^1 = 3+96 = 99సరే, ఇప్పుడు డంప్‌ను చూద్దాం:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4
tcpdump: listening on vnet4, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:35:18.709949 IP (tos 0x0, ttl 64, id 48650, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.41591 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.710159 IP (tos 0x0, ttl 64, id 23360, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 63, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.711292 IP (tos 0x0, ttl 64, id 43596, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.42588 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 64, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
04:35:18.711531 IP (tos 0x0, ttl 64, id 8555, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 63, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
*****************omitted*******************మొదటి ప్యాకెట్ హోస్ట్ 192.168.255.19 (కంప్యూట్-0) నుండి vni 192.168.255.15తో 1 (నియంత్రణ-22) వరకు ఒక vxlan ప్యాకెట్, దీని లోపల ICMP ప్యాకెట్ హోస్ట్ 10.0.1.85 నుండి హోస్ట్ 10.0.2.8 వరకు ప్యాక్ చేయబడింది. మేము పైన లెక్కించినట్లుగా, vni మనం అవుట్‌పుట్‌లో చూసిన దానితో సరిపోతుంది.
రెండవ ప్యాకెట్ హోస్ట్ 192.168.255.15 (నియంత్రణ-1) నుండి vni 192.168.255.26తో 1 (కంప్యూట్-99)కి హోస్ట్ చేసే vxlan ప్యాకెట్, దీని లోపల ICMP ప్యాకెట్ హోస్ట్ 10.0.1.85 నుండి 10.0.2.8 హోస్ట్ వరకు ప్యాక్ చేయబడుతుంది. మేము పైన లెక్కించినట్లుగా, vni మనం అవుట్‌పుట్‌లో చూసిన దానితో సరిపోతుంది.
తదుపరి రెండు ప్యాకెట్లు 10.0.2.8 కాదు 10.0.1.85 నుండి తిరిగి వచ్చే ట్రాఫిక్.
అంటే, చివరికి మేము క్రింది నియంత్రణ నోడ్ పథకాన్ని పొందాము:
అదెలా అనిపిస్తోంది? మేము రెండు నేమ్‌స్పేస్‌ల గురించి మరచిపోయాము:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ మేము క్లౌడ్ ప్లాట్‌ఫారమ్ యొక్క నిర్మాణం గురించి మాట్లాడినప్పుడు, యంత్రాలు DHCP సర్వర్ నుండి స్వయంచాలకంగా చిరునామాలను స్వీకరిస్తే మంచిది. ఇవి మా రెండు నెట్‌వర్క్‌లు 10.0.1.0/24 మరియు 10.0.2.0/24 కోసం రెండు DHCP సర్వర్లు.
ఇది నిజమో కాదో చెక్ చేద్దాం. ఈ నేమ్‌స్పేస్‌లో ఒకే ఒక చిరునామా మాత్రమే ఉంది - 10.0.1.1 - DHCP సర్వర్ యొక్క చిరునామా మరియు ఇది br-intలో కూడా చేర్చబడింది:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 1 bytes 28 (28.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 28 (28.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tapca25a97e-64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.1 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fee6:2c5c prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:e6:2c:5c txqueuelen 1000 (Ethernet)
RX packets 129 bytes 9372 (9.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 49 bytes 6154 (6.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0నియంత్రణ నోడ్‌లో వాటి పేరులో qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ఉన్న ప్రక్రియలు ఉన్నాయో లేదో చూద్దాం:
[heat-admin@overcloud-controller-0 ~]$ ps -aux | egrep qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
root 640420 0.0 0.0 4220 348 ? Ss 11:31 0:00 dumb-init --single-child -- ip netns exec qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 /usr/sbin/dnsmasq -k --no-hosts --no-resolv --pid-file=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/host --addn-hosts=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/opts --dhcp-leasefile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases --dhcp-match=set:ipxe,175 --local-service --bind-dynamic --dhcp-range=set:subnet-335552dd-b35b-456b-9df0-5aac36a3ca13,10.0.2.0,static,255.255.255.0,86400s --dhcp-option-force=option:mtu,1450 --dhcp-lease-max=256 --conf-file= --domain=openstacklocal
heat-ad+ 951620 0.0 0.0 112944 980 pts/0 S+ 18:50 0:00 grep -E --color=auto qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
[heat-admin@overcloud-controller-0 ~]$ అటువంటి ప్రక్రియ ఉంది మరియు ఎగువ అవుట్‌పుట్‌లో అందించిన సమాచారం ఆధారంగా, ఉదాహరణకు, మేము ప్రస్తుతం అద్దెకు ఉన్న వాటిని చూడవచ్చు:
[heat-admin@overcloud-controller-0 ~]$ cat /var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases
1597492111 fa:16:3e:6c:ad:9c 10.0.2.8 host-10-0-2-8 01:fa:16:3e:6c:ad:9c
1597491115 fa:16:3e:76:c2:11 10.0.2.1 host-10-0-2-1 *
[heat-admin@overcloud-controller-0 ~]$ఫలితంగా, మేము నియంత్రణ నోడ్‌లో క్రింది సేవలను పొందుతాము:
బాగా, గుర్తుంచుకోండి - ఇది కేవలం 4 మెషీన్‌లు, 2 అంతర్గత నెట్‌వర్క్‌లు మరియు ఒక వర్చువల్ రూటర్ మాత్రమే... ఇప్పుడు మనకు ఇక్కడ బాహ్య నెట్‌వర్క్‌లు లేవు, విభిన్న ప్రాజెక్ట్‌ల సమూహం, ఒక్కొక్కటి వాటి స్వంత నెట్‌వర్క్‌లు (అతివ్యాప్తి చెందడం) మరియు మేము కలిగి ఉన్నాము పంపిణీ చేయబడిన రౌటర్ ఆఫ్ చేయబడింది మరియు చివరికి, టెస్ట్ బెంచ్‌లో ఒకే ఒక నియంత్రణ నోడ్ ఉంది (తప్పు సహనం కోసం మూడు నోడ్‌ల కోరం ఉండాలి). వాణిజ్యంలో ప్రతిదీ “కొంచెం” మరింత క్లిష్టంగా ఉండటం తార్కికం, కానీ ఈ సాధారణ ఉదాహరణలో ఇది ఎలా పని చేయాలో మేము అర్థం చేసుకున్నాము - మీకు 3 లేదా 300 నేమ్‌స్పేస్‌లు ఉన్నాయా అనేది చాలా ముఖ్యమైనది, కానీ మొత్తం ఆపరేషన్ కోణం నుండి నిర్మాణం, ఏదీ పెద్దగా మారదు... అయినప్పటికీ మీరు కొంత విక్రేత SDNని ప్లగ్ చేయరు. కానీ అది పూర్తిగా భిన్నమైన కథ.
ఇది ఆసక్తికరంగా ఉందని నేను ఆశిస్తున్నాను. మీకు ఏవైనా వ్యాఖ్యలు/చేర్పులు ఉంటే లేదా ఎక్కడైనా నేను పూర్తిగా అబద్ధం చెప్పినట్లయితే (నేను మనిషిని మరియు నా అభిప్రాయం ఎల్లప్పుడూ ఆత్మాశ్రయమే) - సరిదిద్దాల్సిన/జోడించాల్సిన వాటిని వ్రాయండి - మేము అన్నింటినీ సరిచేస్తాము/జోడిస్తాము.
ముగింపులో, VMWare నుండి క్లౌడ్ సొల్యూషన్‌తో Openstack (వనిల్లా మరియు విక్రేత రెండింటినీ) పోల్చడం గురించి నేను కొన్ని మాటలు చెప్పాలనుకుంటున్నాను - గత రెండు సంవత్సరాలుగా నేను ఈ ప్రశ్నను చాలా తరచుగా అడిగాను మరియు స్పష్టంగా చెప్పాలంటే, నేను ఇప్పటికే అది అలసిపోతుంది, కానీ ఇప్పటికీ. నా అభిప్రాయం ప్రకారం, ఈ రెండు పరిష్కారాలను పోల్చడం చాలా కష్టం, కానీ రెండు పరిష్కారాలలో ప్రతికూలతలు ఉన్నాయని మేము ఖచ్చితంగా చెప్పగలం మరియు ఒక పరిష్కారాన్ని ఎన్నుకునేటప్పుడు మీరు లాభాలు మరియు నష్టాలను తూకం వేయాలి.
OpenStack కమ్యూనిటీ-ఆధారిత పరిష్కారం అయితే, VMWare తనకు కావలసినది మాత్రమే చేసే హక్కును కలిగి ఉంటుంది (చదవడానికి - దానికి ఏది లాభదాయకంగా ఉంటుంది) మరియు ఇది తార్కికం - ఎందుకంటే ఇది తన ఖాతాదారుల నుండి డబ్బు సంపాదించడానికి ఉపయోగించే వాణిజ్య సంస్థ. కానీ పెద్ద మరియు లావుగా ఒకటి ఉంది కానీ - మీరు నోకియా నుండి ఓపెన్స్టాక్ నుండి బయటపడవచ్చు మరియు తక్కువ ఖర్చుతో, ఉదాహరణకు, జునిపర్ (కాంట్రైల్ క్లౌడ్) నుండి పరిష్కారానికి మారవచ్చు, కానీ మీరు VMWare నుండి బయటపడే అవకాశం లేదు. . నాకు, ఈ రెండు పరిష్కారాలు ఇలా కనిపిస్తాయి - ఓపెన్స్టాక్ (విక్రేత) అనేది మీరు ఉంచబడిన ఒక సాధారణ పంజరం, కానీ మీ వద్ద ఒక కీ ఉంది మరియు మీరు ఎప్పుడైనా బయలుదేరవచ్చు. VMWare ఒక బంగారు పంజరం, యజమాని వద్ద పంజరం యొక్క కీ ఉంది మరియు అది మీకు చాలా ఖర్చు అవుతుంది.
నేను మొదటి ఉత్పత్తిని లేదా రెండవదాన్ని ప్రమోట్ చేయడం లేదు - మీకు ఏది అవసరమో మీరు ఎంచుకోండి. కానీ నాకు అలాంటి ఎంపిక ఉంటే, నేను టెలికాం క్లౌడ్ కోసం రెండు పరిష్కారాలను ఎంచుకుంటాను - IT క్లౌడ్ కోసం VMWare (తక్కువ లోడ్లు, సులభమైన నిర్వహణ), కొంతమంది విక్రేత నుండి OpenStack (Nokia మరియు Juniper చాలా మంచి టర్న్‌కీ పరిష్కారాలను అందిస్తాయి) -. నేను స్వచ్ఛమైన IT కోసం ఓపెన్‌స్టాక్‌ని ఉపయోగించను - ఇది పిచ్చుకలను ఫిరంగితో కాల్చడం లాంటిది, కానీ రిడెండెన్సీ కాకుండా దాన్ని ఉపయోగించడంలో నాకు ఎలాంటి వ్యతిరేకతలు కనిపించడం లేదు. అయితే, టెలికామ్‌లో VMWareని ఉపయోగించడం అనేది ఫోర్డ్ రాప్టర్‌లో పిండిచేసిన రాయిని లాగడం లాంటిది - ఇది బయటి నుండి అందంగా ఉంటుంది, కానీ డ్రైవర్ ఒకటికి బదులుగా 10 ట్రిప్పులు చేయాల్సి ఉంటుంది.
నా అభిప్రాయం ప్రకారం, VMWare యొక్క అతిపెద్ద ప్రతికూలత దాని పూర్తి క్లోజ్‌నెస్ - కంపెనీ మీకు ఇది ఎలా పని చేస్తుందనే దాని గురించి ఎటువంటి సమాచారం ఇవ్వదు, ఉదాహరణకు, vSAN లేదా హైపర్‌వైజర్ కెర్నల్‌లో ఏమి ఉంది - ఇది లాభదాయకం కాదు - అంటే మీరు VMWareలో ఎప్పటికీ నిపుణుడు కాకూడదు - విక్రేత మద్దతు లేకుండా, మీరు నాశనం చేయబడతారు (చాలా తరచుగా నేను పనికిమాలిన ప్రశ్నలతో కలవరపడే VMWare నిపుణులను కలుస్తాను). నా కోసం, VMWare హుడ్ లాక్ చేయబడిన కారుని కొనుగోలు చేస్తోంది - అవును, మీరు టైమింగ్ బెల్ట్‌ను మార్చగల నిపుణులను కలిగి ఉండవచ్చు, కానీ మీకు ఈ పరిష్కారాన్ని విక్రయించిన వ్యక్తి మాత్రమే హుడ్‌ను తెరవగలరు. వ్యక్తిగతంగా, నేను సరిపోని పరిష్కారాలను నేను ఇష్టపడను. మీరు హుడ్ కిందకి వెళ్లవలసిన అవసరం లేదని మీరు చెబుతారు. అవును, ఇది సాధ్యమే, కానీ మీరు 20-30 వర్చువల్ మిషన్లు, 40-50 నెట్‌వర్క్‌ల నుండి క్లౌడ్‌లో పెద్ద ఫంక్షన్‌ను సమీకరించాల్సిన అవసరం వచ్చినప్పుడు నేను మిమ్మల్ని చూస్తాను, వీటిలో సగం బయటికి వెళ్లాలనుకుంటున్నాయి మరియు రెండవ సగం అడుగుతుంది SR-IOV త్వరణం, లేకపోతే మీకు ఈ కార్లలో రెండు డజన్ల కొద్దీ అవసరం - లేకపోతే పనితీరు సరిపోదు.
ఇతర దృక్కోణాలు ఉన్నాయి, కాబట్టి మీరు ఏమి ఎంచుకోవాలో మాత్రమే నిర్ణయించగలరు మరియు ముఖ్యంగా, మీ ఎంపికకు మీరు బాధ్యత వహిస్తారు. ఇది నా అభిప్రాయం మాత్రమే - నోకియా, జునిపర్, రెడ్ హ్యాట్ మరియు విఎమ్‌వేర్ - కనీసం 4 ఉత్పత్తులను చూసిన మరియు తాకిన వ్యక్తి. అంటే, నేను పోల్చడానికి ఏదో ఉంది.
మూలం: www.habr.com