Yn y ddwy erthygl gyntaf, codais y mater o awtomeiddio a braslunio ei fframwaith, yn yr ail enciliais i rithwiroli rhwydwaith, fel y dull cyntaf o awtomeiddio cyfluniad gwasanaethau.
Nawr mae'n bryd llunio diagram o'r rhwydwaith ffisegol.
Os nad ydych chi'n gyfarwydd â sefydlu rhwydweithiau canolfannau data, yna rwy'n argymell yn gryf i ddechrau .
Pob mater:
Dylai'r arferion a ddisgrifir yn y gyfres hon fod yn berthnasol i unrhyw fath o rwydwaith, o unrhyw faint, gydag unrhyw amrywiaeth o werthwyr (nid). Fodd bynnag, mae'n amhosibl disgrifio enghraifft gyffredinol o gymhwyso'r dulliau hyn. Felly, byddaf yn canolbwyntio ar bensaernïaeth fodern y rhwydwaith DC: .
Byddwn yn gwneud DCI ar MPLS L3VPN.
Mae rhwydwaith Troshaen yn rhedeg ar ben y rhwydwaith ffisegol o'r gwesteiwr (gallai hyn fod yn VXLAN neu Twngsten Fabric OpenStack neu unrhyw beth arall sydd angen dim ond cysylltedd IP sylfaenol o'r rhwydwaith).
Yn yr achos hwn, rydym yn cael senario gymharol syml ar gyfer awtomeiddio, oherwydd mae gennym lawer o offer sydd wedi'i ffurfweddu yn yr un modd.
Byddwn yn dewis DC sfferig mewn gwactod:
- Un fersiwn dylunio ym mhobman.
- Dau werthwr yn ffurfio dwy awyren rhwydwaith.
- Mae un DC fel un arall fel dau bys mewn pod.
Cynnwys
- Topoleg ffisegol
- Llwybro
- Cynllun IP
- Laba
- Casgliad
- Dolenni defnyddiol
Gadewch i'n Darparwr Gwasanaeth LAN_DC, er enghraifft, gynnal fideos hyfforddi am oroesi mewn codwyr sownd.
Mewn megaddinasoedd mae hyn yn hynod boblogaidd, felly mae angen llawer o beiriannau corfforol arnoch chi.
Yn gyntaf, byddaf yn disgrifio'r rhwydwaith yn fras fel yr hoffwn iddo fod. Ac yna byddaf yn ei symleiddio ar gyfer y labordy.
Topoleg ffisegol
Lleoliadau
Bydd gan LAN_DC 6 DC:
- Rwsia (RU):
- Moscow (msk)
- Kazan (kzn)
- Sbaen (SP):
- Barcelona (bcn)
- Malaga (mlg)
- Tsieina (CN):
- Shanghai (sHA)
- Xi'an (sia)
Y tu mewn DC (Intra-DC)
Mae gan bob DC rwydweithiau cysylltedd mewnol union yr un fath yn seiliedig ar dopoleg Clos.
Pa fath o rwydweithiau Clos ydyn nhw a pham maen nhw mewn rhwydwaith ar wahân .
Mae gan bob DC 10 rac gyda pheiriannau, byddant yn cael eu rhifo fel A, B, C Ac yn y blaen.
Mae gan bob rac 30 o beiriannau. Ni fyddant o ddiddordeb i ni.
Hefyd ym mhob rac mae switsh y mae pob peiriant yn gysylltiedig ag ef - dyma Switsh Top of the Rack - ToR neu fel arall, o ran y ffatri Clos, byddwn yn ei alw Dail.
Diagram cyffredinol o'r ffatri.
Byddwn yn eu galw XXX-dailYlle XXX - Talfyriad tair llythyren DC, a Y - rhif Serial. Er enghraifft, kzn-dail11.
Yn fy erthyglau byddaf yn caniatáu i mi fy hun ddefnyddio'r termau Leaf a ToR braidd yn wamal fel cyfystyron. Fodd bynnag, rhaid inni gofio nad yw hyn yn wir.
Mae ToR yn switsh sydd wedi'i osod mewn rac y mae peiriannau'n gysylltiedig ag ef.
Deilen yw rôl dyfais mewn rhwydwaith ffisegol neu switsh lefel gyntaf o ran topoleg Cloes.
Hynny yw, Dail!=ToR.
Felly gall Leaf fod yn switsh EndofRaw, er enghraifft.
Fodd bynnag, o fewn fframwaith yr erthygl hon byddwn yn dal i'w trin fel cyfystyron.
Mae pob switsh ToR yn ei dro wedi'i gysylltu â phedwar switsh agregu lefel uwch - Sbin. Dyrennir un rac yn y DC ar gyfer Spines. Byddwn yn ei enwi yn yr un modd: XXX- asgwrn cefnY.
Bydd yr un rac yn cynnwys offer rhwydwaith ar gyfer cysylltedd rhwng y llwybrydd DC - 2 gyda MPLS ar ei bwrdd. Ond ar y cyfan, yr un Cylchoedd Gorchwyl yw'r rhain. Hynny yw, o safbwynt switshis Spine, nid yw'r ToR arferol gyda pheiriannau cysylltiedig neu lwybrydd ar gyfer DCI yn bwysig o gwbl - dim ond anfon ymlaen.
Gelwir ToRs arbennig o'r fath Ymyl-dail. Byddwn yn eu galw XXX-ymylY.
Bydd yn edrych fel hyn.
Yn y diagram uchod, gosodais ymyl a dail ar yr un lefel mewn gwirionedd. Dysgon nhw i ni ystyried uplinking (felly y term) fel uplinks. Ac yma mae'n troi allan bod y “uplink” DCI yn mynd yn ôl i lawr, sydd i rai yn torri'r rhesymeg arferol ychydig. Yn achos rhwydweithiau mawr, pan fydd canolfannau data wedi'u rhannu'n unedau hyd yn oed yn llai - Pod's (Pwynt Cyflenwi), amlygu unigol Ymyl-POD's ar gyfer DCI a mynediad i rwydweithiau allanol.
Er hwylustod canfyddiad yn y dyfodol, byddaf yn dal i dynnu Edge dros Asgwrn Cefn, tra byddwn yn cadw mewn cof nad oes unrhyw wybodaeth am Asgwrn Cefn ac nad oes unrhyw wahaniaethau wrth weithio gyda Leaf and Edge-leaf rheolaidd (er y gallai fod arlliwiau yma , ond yn gyffredinol Mae hyn yn wir).
Cynllun o ffatri gyda Edge-leafs.
Mae'r drindod o Ddeilen, Asgwrn Cefn ac Ymyl yn ffurfio rhwydwaith neu ffatri Underlay.
Tasg ffatri rhwydwaith (darllenwch Underlay), fel yr ydym eisoes wedi'i ddiffinio yn , syml iawn, iawn - i ddarparu cysylltedd IP rhwng peiriannau o fewn yr un DC a rhyngddynt.
Dyna pam y gelwir y rhwydwaith yn ffatri, yn union fel, er enghraifft, ffatri newid y tu mewn i flychau rhwydwaith modiwlaidd, y gallwch ddarllen mwy amdani yn .
Yn gyffredinol, gelwir topoleg o'r fath yn ffatri, oherwydd mae ffabrig mewn cyfieithiad yn golygu ffabrig. Ac mae'n anodd anghytuno:
Mae'r ffatri yn gyfan gwbl L3. Dim VLAN, dim Darllediad - mae gennym ni raglenwyr mor wych yn LAN_DC, maen nhw'n gwybod sut i ysgrifennu cymwysiadau sy'n byw yn y patrwm L3, ac nid oes angen Mudo Byw ar beiriannau rhithwir gyda chadwraeth y cyfeiriad IP.
Ac unwaith eto: yr ateb i'r cwestiwn pam y ffatri a pham L3 mewn ar wahân .
DCI - Rhyng-gysylltiad Canolfan Ddata (Rhyng-DC)
Bydd DCI yn cael ei drefnu gan ddefnyddio Edge-Leaf, hynny yw, nhw yw ein man ymadael i'r briffordd.
Er mwyn symlrwydd, tybiwn fod y DCs wedi'u cysylltu â'i gilydd trwy gysylltiadau uniongyrchol.
Gadewch inni eithrio cysylltedd allanol rhag ystyriaeth.
Rwy'n ymwybodol fy mod yn symleiddio'r rhwydwaith yn sylweddol bob tro y byddaf yn tynnu cydran. A phan fyddwn yn awtomeiddio ein rhwydwaith haniaethol, bydd popeth yn iawn, ond ar yr un go iawn bydd baglau.
Mae hyn yn wir. Eto i gyd, pwrpas y gyfres hon yw meddwl a gweithio ar ddulliau, nid datrys problemau dychmygol yn arwrol.
Ar Edge-Leafs, mae'r isgarth yn cael ei osod yn y VPN a'i drosglwyddo trwy asgwrn cefn MPLS (yr un cyswllt uniongyrchol).
Dyma'r diagram lefel uchaf a gawn.
Llwybro
Ar gyfer llwybro o fewn y DC byddwn yn defnyddio BGP.
Ar gefnffordd MPLS OSPF+CDLl.
Ar gyfer DCI, hynny yw, trefnu cysylltedd yn y tanddaear - BGP L3VPN dros MPLS.
Cynllun llwybro cyffredinol
Nid oes OSPF nac ISIS (protocol llwybro wedi'i wahardd yn Ffederasiwn Rwsia) yn y ffatri.
Mae hyn yn golygu na fydd Awto-ddarganfod na chyfrifo'r llwybrau byrraf - dim ond â llaw (awtomatig mewn gwirionedd - rydym yn sôn am awtomeiddio yma) yn sefydlu'r protocol, cymdogaeth a pholisïau.
Cynllun llwybro BGP o fewn y DC
Pam BGP?
Ar y pwnc hwn mae wedi'i henwi ar ôl Facebook ac Arista, sy'n dweud sut i adeiladu mawr iawn rhwydweithiau canolfannau data gan ddefnyddio BGP. Mae'n darllen bron fel ffuglen, rwy'n ei argymell yn fawr ar gyfer noson ddigywilydd.
Ac mae yna hefyd adran gyfan yn fy erthygl sy'n ymroddedig i hyn. Ble ydw i'n mynd â chi a .
Ond yn dal i fod, yn fyr, nid oes unrhyw IGP yn addas ar gyfer rhwydweithiau o ganolfannau data mawr, lle mae nifer y dyfeisiau rhwydwaith yn rhedeg i'r miloedd.
Yn ogystal, bydd defnyddio BGP ym mhobman yn caniatáu ichi beidio â gwastraffu amser ar gefnogi sawl protocol gwahanol a chydamseru rhyngddynt.
Law yn llaw, yn ein ffatri, na fydd gyda lefel uchel o debygolrwydd yn tyfu'n gyflym, byddai OSPF yn ddigon i'r llygaid. Problemau megascalers a titans cwmwl yw'r rhain mewn gwirionedd. Ond gadewch i ni ddychmygu dim ond am ychydig o ddatganiadau bod ei angen arnom, a byddwn yn defnyddio BGP, fel y gadawodd Pyotr Lapukhov.
Polisïau Llwybro
Ar switshis Leaf, rydym yn mewnforio rhagddodiaid o ryngwynebau rhwydwaith Underlay i BGP.
Bydd gennym sesiwn BGP rhwng yr un pâr Leaf-Spine, lle bydd y rhagddodiaid Underlay hyn yn cael eu cyhoeddi dros y rhwydwaith yma ac acw.
O fewn un ganolfan ddata byddwn yn dosbarthu'r manylebau a fewnforiwyd gennym i ToRe. Ar Edge-Leafs byddwn yn eu hagregu a'u cyhoeddi i DCs anghysbell a'u hanfon i lawr i TORs. Hynny yw, bydd pob ToR yn gwybod yn union sut i gyrraedd Cylch Gorchwyl arall yn yr un DC a ble mae'r pwynt mynediad i gyrraedd y Cylch Gorchwyl mewn DC arall.
Yn DCI, bydd llwybrau'n cael eu trosglwyddo fel VPNv4. I wneud hyn, ar Edge-Leaf, bydd y rhyngwyneb tuag at y ffatri yn cael ei roi mewn VRF, gadewch i ni ei alw UNDERLAY, a bydd y gymdogaeth ag Spine on Edge-Leaf yn codi o fewn y VRF, a rhwng Edge-Leafs yn y VPNv4- teulu.
Byddwn hefyd yn gwahardd ailgyhoeddi llwybrau a dderbynnir o feingefn yn ôl iddynt.
Ar Ddeilen ac Asgwrn Cefn ni fyddwn yn mewnforio Dolenni yn ôl. Dim ond nhw sydd eu hangen arnom i bennu ID y Llwybrydd.
Ond ar Edge-Leafs rydyn ni'n ei fewnforio i Global BGP. Rhwng cyfeiriadau Loopback, bydd Edge-Leafs yn sefydlu sesiwn BGP yn y teulu IPv4 VPN gyda'i gilydd.
Bydd gennym asgwrn cefn OSPF+ CDLl rhwng dyfeisiau EDGE. Mae popeth mewn un parth. Ffurfweddiad hynod o syml.
Dyma'r llun gyda llwybro.
BGP ASN
Ymyl-Dail ASN
Ar Edge-Leafs bydd un ASN ym mhob DC. Mae'n bwysig bod iBGP rhwng Edge-Leafs, ac nid ydym yn cael ein dal yn naws eBGP. Gadewch iddo fod yn 65535. Mewn gwirionedd, gallai hyn fod y nifer o AS cyhoeddus.
ASN asgwrn cefn
Ar asgwrn cefn bydd gennym un ASN fesul DC. Gadewch i ni ddechrau yma gyda'r rhif cyntaf un o'r ystod o UG preifat - 64512, 64513 Ac yn y blaen.
Pam ASN ar DC?
Gadewch i ni rannu'r cwestiwn hwn yn ddau:
- Pam mae'r ASNs yr un peth ar bob asgwrn cefn un DC?
- Pam maen nhw'n wahanol mewn gwahanol DCs?
Pam fod yr un ASNs ar bob asgwrn cefn un DC?
Dyma sut olwg fydd ar lwybr AS-Llwybr yr Underlay ar Edge-Leaf:
[leafX_ASN, spine_ASN, edge_ASN]
Pan geisiwch ei hysbysebu yn ôl i Spine, bydd yn ei daflu oherwydd bod ei AS (Spine_AS) eisoes yn y rhestr.
Fodd bynnag, o fewn y DC rydym yn gwbl fodlon na fydd y llwybrau Underlay sy'n esgyn i'r Ymyl yn gallu mynd i lawr. Rhaid i bob cyfathrebu rhwng gwesteiwyr o fewn y DC ddigwydd o fewn lefel yr asgwrn cefn.
Yn yr achos hwn, bydd llwybrau agregedig DCs eraill yn cyrraedd y ToRs yn hawdd beth bynnag - dim ond ASN 65535 fydd gan eu Llwybr AS - nifer yr AS Edge-Leafs, oherwydd dyna lle cawsant eu creu.
Pam maen nhw'n wahanol mewn gwahanol DCs?
Yn ddamcaniaethol, efallai y bydd angen i ni lusgo Loopback a rhai peiriannau rhithwir gwasanaeth rhwng DCs.
Er enghraifft, ar y gwesteiwr byddwn yn rhedeg Route Reflector neu (Virtual Network Gateway), a fydd yn cloi gyda TopR trwy BGP ac yn cyhoeddi ei ddolen yn ôl, a ddylai fod yn hygyrch o bob DC.
Felly dyma sut olwg fydd ar ei AS-Lwybr:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]
Ac ni ddylai fod unrhyw ASNs dyblyg yn unman.
Hynny yw, mae'n rhaid i Spine_DC1 a Spine_DC2 fod yn wahanol, yn union fel leafX_DC1 a leafY_DC2, sef yr union beth rydyn ni'n agosáu.
Fel y gwyddoch mae'n debyg, mae yna haciau sy'n eich galluogi i dderbyn llwybrau ag ASNs dyblyg er gwaethaf y mecanwaith atal dolen (allowas-in ar Cisco). Ac mae ganddo ddefnyddiau cyfreithlon hyd yn oed. Ond mae hwn yn fwlch posibl yn sefydlogrwydd y rhwydwaith. Ac yr wyf yn bersonol yn syrthio i mewn iddo cwpl o weithiau.
Ac os cawn gyfle i beidio â defnyddio pethau peryglus, byddwn yn manteisio arno.
Deilen ASN
Bydd gennym ASN unigol ar bob switsh Leaf ar draws y rhwydwaith.
Rydym yn gwneud hyn am y rhesymau a roddir uchod: AS-Llwybr heb ddolenni, ffurfweddiad BGP heb nodau tudalen.
Er mwyn i lwybrau rhwng Dail basio'n esmwyth, dylai'r AS-Llwybr edrych fel hyn:
[leafX_ASN, spine_ASN, leafY_ASN]
lle byddai leafX_ASN a leafY_ASN yn braf bod yn wahanol.
Mae hyn hefyd yn ofynnol ar gyfer y sefyllfa gyda chyhoeddiad dolen VNF rhwng DCs:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]
Byddwn yn defnyddio ASN 4-beit ac yn ei gynhyrchu yn seiliedig ar ASN y Spine's a rhif switsh Leaf, sef, fel hyn: Asgwrn cefn_ASN.0000X.
Dyma'r llun gydag ASN.
Cynllun IP
Yn y bôn, mae angen i ni ddyrannu cyfeiriadau ar gyfer y cysylltiadau canlynol:
- Is-haenu cyfeiriadau rhwydwaith rhwng ToR a pheiriant. Rhaid iddynt fod yn unigryw o fewn y rhwydwaith cyfan fel y gall unrhyw beiriant gyfathrebu ag unrhyw beiriant arall. Ffit wych 10/8. Ar gyfer pob rac mae yna /26 gyda chronfa wrth gefn. Byddwn yn dyrannu /19 fesul DC a /17 fesul rhanbarth.
- Cyfeiriadau cyswllt rhwng Leaf/Tor a Spine.
Hoffwn eu neilltuo'n algorithmig, hynny yw, eu cyfrifo o enwau'r dyfeisiau y mae angen eu cysylltu.
Gadewch iddo fod... 169.254.0.0/16.
Sef 169.254.00X.Y/31lle X - Rhif asgwrn cefn, Y — Rhwydwaith P2P /31.
Bydd hyn yn caniatáu ichi lansio hyd at 128 o raciau, a hyd at 10 Spines yn y DC. Gall (a bydd) cyfeiriadau cyswllt yn cael eu hailadrodd o DC i DC. - Rydym yn trefnu cyffordd Spine-Edge-Leaf ar is-rwydweithiau 169.254.10X.Y/31, lle yn union yr un fath X - Rhif asgwrn cefn, Y — Rhwydwaith P2P /31.
- Cyfeiriadau cyswllt o Edge-Leaf i asgwrn cefn MPLS. Yma mae'r sefyllfa ychydig yn wahanol - y man lle mae'r holl ddarnau wedi'u cysylltu i mewn i un pastai, felly ni fydd ailddefnyddio'r un cyfeiriadau yn gweithio - mae angen i chi ddewis yr isrwyd rhad ac am ddim nesaf. Felly, gadewch i ni gymryd fel sail 192.168.0.0/16 a ni a ysgrífenwn y rhai rhydd o honi.
- Cyfeiriadau Cylchol. Byddwn yn rhoi'r ystod gyfan ar eu cyfer 172.16.0.0/12.
- Deilen - /25 y DC - yr un 128 rac. Byddwn yn dyrannu /23 fesul rhanbarth.
- Asgwrn cefn - /28 fesul DC - hyd at 16 asgwrn cefn. Gadewch i ni ddyrannu /26 fesul rhanbarth.
- Edge-Leaf - /29 y DC - hyd at 8 blwch. Gadewch i ni ddyrannu /27 fesul rhanbarth.
Os nad oes gennym ddigon o ystodau wedi'u dyrannu yn y DC (ac ni fydd unrhyw rai - rydym yn honni eu bod yn hyperscalers), rydym yn syml yn dewis y bloc nesaf.
Dyma'r llun gyda chyfeiriad IP.
Dolenni yn ôl:
Rhagddodiad
Rôl y ddyfais
Rhanbarth
DC
172.16.0.0/23
ymyl
172.16.0.0/27
ru
172.16.0.0/29
msk
172.16.0.8/29
kzn
172.16.0.32/27
sp
172.16.0.32/29
bcn
172.16.0.40/29
mlg
172.16.0.64/27
cn
172.16.0.64/29
sHA
172.16.0.72/29
sia
172.16.2.0/23
asgwrn cefn
172.16.2.0/26
ru
172.16.2.0/28
msk
172.16.2.16/28
kzn
172.16.2.64/26
sp
172.16.2.64/28
bcn
172.16.2.80/28
mlg
172.16.2.128/26
cn
172.16.2.128/28
sHA
172.16.2.144/28
sia
172.16.8.0/21
dail
172.16.8.0/23
ru
172.16.8.0/25
msk
172.16.8.128/25
kzn
172.16.10.0/23
sp
172.16.10.0/25
bcn
172.16.10.128/25
mlg
172.16.12.0/23
cn
172.16.12.0/25
sHA
172.16.12.128/25
sia
Isgarped:
Rhagddodiad
Rhanbarth
DC
10.0.0.0/17
ru
10.0.0.0/19
msk
10.0.32.0/19
kzn
10.0.128.0/17
sp
10.0.128.0/19
bcn
10.0.160.0/19
mlg
10.1.0.0/17
cn
10.1.0.0/19
sHA
10.1.32.0/19
sia
Laba
Dau werthwr. Un rhwydwaith. ADSM.
Meryw + Arista. Ubuntu. Noswyl hen dda.
Mae faint o adnoddau ar ein gweinydd rhithwir yn Mirana yn gyfyngedig o hyd, felly ar gyfer ymarfer byddwn yn defnyddio rhwydwaith sydd wedi'i symleiddio i'r eithaf.
Dwy ganolfan ddata: Kazan a Barcelona.
- Dau big yr un: Juniper ac Arista.
- Un torus (Deilen) ym mhob un - Juniper ac Arista, gydag un gwesteiwr cysylltiedig (gadewch i ni gymryd Cisco IOL ysgafn ar gyfer hyn).
- Un nod Edge-Leaf yr un (am y tro dim ond Juniper).
- Un switsh Cisco i reoli pob un ohonynt.
- Yn ogystal â'r blychau rhwydwaith, mae peiriant rheoli rhithwir yn rhedeg. Rhedeg Ubuntu.
Mae ganddo fynediad i bob dyfais, bydd yn rhedeg systemau IPAM/DCIM, criw o sgriptiau Python, Ansible ac unrhyw beth arall y gallai fod ei angen arnom.
o'r holl ddyfeisiau rhwydwaith, y byddwn yn ceisio eu hatgynhyrchu gan ddefnyddio awtomeiddio.
Casgliad
A yw hynny hefyd yn cael ei dderbyn? A ddylwn i ysgrifennu casgliad byr o dan bob erthygl?
Felly dewison ni Rhwydwaith clos y tu mewn i'r DC, gan ein bod yn disgwyl llawer o draffig Dwyrain-Gorllewin ac eisiau ECMP.
Rhannwyd y rhwydwaith yn ffisegol (ishaen) a rhithwir (troshaen). Ar yr un pryd, mae'r troshaen yn cychwyn o'r gwesteiwr - a thrwy hynny symleiddio'r gofynion ar gyfer yr isgarth.
Dewisasom BGP fel y protocol llwybro ar gyfer rhwydweithiau rhwydwaith oherwydd ei allu i dyfu a hyblygrwydd polisi.
Bydd gennym nodau ar wahân ar gyfer trefnu DCI - Edge-leaf.
Bydd gan yr asgwrn cefn OSPF+CDLl.
Bydd DCI yn cael ei weithredu yn seiliedig ar MPLS L3VPN.
Ar gyfer cysylltiadau P2P, byddwn yn cyfrifo cyfeiriadau IP yn algorithmig yn seiliedig ar enwau dyfeisiau.
Byddwn yn neilltuo dolenni yn ôl rôl y dyfeisiau a'u lleoliad yn ddilyniannol.
Rhagddodiaid Underlay - dim ond ar switshis Leaf yn ddilyniannol yn seiliedig ar eu lleoliad.
Gadewch i ni dybio nad oes gennym yr offer wedi'i osod eto ar hyn o bryd.
Felly, ein camau nesaf fydd eu hychwanegu at y systemau (IPAM, rhestr eiddo), trefnu mynediad, cynhyrchu cyfluniad a'i ddefnyddio.
Yn yr erthygl nesaf byddwn yn delio â Netbox - rhestr eiddo a system reoli ar gyfer gofod IP mewn DC.
Diolch
- Andrey Glazkov aka @glazgoo ar gyfer prawfddarllen a chywiriadau
- Alexander Klimenko aka @v00lk ar gyfer prawfddarllen a golygiadau
- Artyom Chernobay ar gyfer KDPV
Ffynhonnell: hab.com