Beste svaret
Det kan hjelpe å tenke på forskjellene i perspektiv. Det vil si at hvis du ser på om det fra datamaskinens «perspektiv» kontra lagringsperspektivet «, kan det faktisk være fornuftig.
I den ene enden av en logisk databehandlingsmetafor har du datamaskinen (også kalt en «vert», «initiator» eller til og med bare «CPU» noen ganger. På den andre har du det fysiske mediet (også kalt et «mål», «stasjon», «HDD» eller «SSD , «osv.).
Verter trenger volumer, så disse volumene må bestå av noe som til slutt sitter på en ekte, fysisk stasjon (enten det er snurrende stasjoner eller SSD-er osv.).
Se på det forenklede diagrammet nedenfor. Fra «ovenfra og ned» ser en vert et volum. Det volumet må i sin tur bestå av noe som igjen kan være tolket (til slutt av fysiske medier). Fra lagringsperspektivet er det fysiske mediet brutt ned fra en fysisk enhet (den faktiske stasjonen), til en logisk enhet, og får et nummer (derav «Logisk enhetsnummer», eller LUN).
I mellomtiden en det er en veldig viktig programvare som gjør en oversettelse mellom den LUN og det verten kan se som et Volume, kalt Volume Manager.
Hvorfor gå gjennom alt dette arbeidet?
Når lagringskravene vokser, øker også behovet for å legge til metoder for beskyttelse, skala, ytelse og andre smarte funksjoner. I tillegg må det også være rom for nettverksfunksjoner. Disse evnene må gå et sted, og det å ha ett stort monolitisk system fungerer ikke så bra.
Mange moderne systemer som er i bruk i dag har et forhold mellom volum og LUN som ser slik ut:
Med tanke nedenfra og opp er mediet plassert inne i en slags lagringsskap, og er ofte samlet i en logisk format via et system kalt RAID (RAID, avhengig av metodene som brukes, kan forbedre ytelsen og elastisiteten).
Den poolen er i sin tur hugget opp i LUNs – nøyaktig samme type LUN som vi brukte i vårt enkle eksempel ovenfor. Disse LUN-ene blir deretter klargjort til vertene. Mange ganger er det et 1: 1 forhold mellom LUNs og Volumes, men det trenger ikke være slik. Volumadministratorer er i stand til å ta mer enn en LUN og logisk kombinere dem i en enkelt enhet for å presentere for verten som et individuelt volum.
Så, LUNs og Volumes kan være det samme, og de er relatert, men (spesielt i SAN), er det vanligvis ikke.
Svar
Vel, la oss forstå dette med et enkelt eksempel.
Tenk på et scenario hvor du driver et lite selskap og du har koblet til i xyz-avdelingen (LAN1). Nå hvis gjestebesøk hos firmaet ditt og ønsker å bruke nettverket, så det er veldig rett frem, vil du ikke la dem forstyrre deg i ditt nåværende nettverk, dvs. LAN1.
Så her har du to alternativer:
- Få en ny bryter dvs. Switch 2 in ditt selskap for gjestebruker og opprett et eget nettverk for dem, la oss si LAN2. Men husk dette vil definitivt slå kostnadene og hektiske for distribusjon.
- Lag et Virtual LAN (VLocal Area Network). I VLAN er den grunnleggende ideen å bruke den samme enheten og isolere flere nettverk. Så for scenariet ovenfor kan du ha to eller flere forskjellige nettverk helt isolert med hverandre på en enkelt bryter og ha full kontroll over sikkerhetsadgangen.
La oss nå komme til spørsmålet. nå:
- Så VLAN bruker ID på 12 bit som er lagt til pakken for nettverksidentifikasjon, dvs. på hvilken VLAN-bestemt pakke skulle rute. Så til slutt kan totalt 4095 unike VLAN «opprettes i VLAN.
- VxLAN (Virtual Extensible Local Area Network) som navnet antyder, er den utvidbare versjonen av VLAN som brukes til å utføre den samme oppgaven. I VxLAN har vi VNI (VxLAN Network Identifier) som blir lagt til pakkene som ovenfor og som er på totalt 24 bits lengder og har muligheten til å lage ca. div id = «7eb020ac02″>