Bästa svaret
Det kan hjälpa att tänka på skillnaderna i perspektiv. Om du tittar på om från datorns ”perspektiv” kontra lagringsperspektivet ”kan det faktiskt vara vettigt.
I ena änden av en logisk datametafor har du datorn (även kallad ”värd”, ”initiator” eller till och med bara ”CPU” ibland. På den andra har du det fysiska mediet (även kallat ”mål”, ”enhet”, ”hårddisk” eller ”SSD , ”etc.).
Värdar behöver volymer, så dessa volymer måste bestå av något som så småningom sitter på en riktig, fysisk enhet (oavsett om det är snurrande enheter eller SSD, etc.).
Titta på det förenklade diagrammet nedan. Från ”uppifrån och ner” ser en värd en volym. Den volymen måste i sin tur bestå av något som i sin tur kan vara tolkas (så småningom av fysiska medier). Ur lagringsperspektivet delas det fysiska mediet upp från en fysisk enhet (den faktiska enheten), till en logisk enhet och ges ett nummer (därav ”Logiskt enhetsnummer”, eller LUN).
I betw en det finns en mycket viktig programvara som gör en översättning mellan den LUN och vad värden kan se som en volym, kallad Volymhanteraren.
Varför gå igenom allt detta arbete?
När lagringskraven växer ökar behovet av att lägga till metoder för skydd, skala, prestanda och andra smidiga funktioner. Dessutom måste det finnas utrymme för nätverksfunktioner också. Dessa möjligheter måste gå någonstans, och att ha ett stort monolitiskt system fungerar inte så bra.
Många moderna system som används idag har en relation mellan volymer och LUN som ser ut så här:
Med tanke nedifrån och upp ligger mediet inuti någon form av lagringshölje och samlas ofta i en logiskt format via ett system som kallas RAID (RAID, beroende på vilka metoder som används, kan förbättra prestanda och motståndskraft).
Den poolen är i sin tur huggen upp i LUN – exakt samma typ av LUN som vi använde i vårt enkla exempel ovan. Dessa LUN-enheter tillhandahålls sedan till värdar. Många gånger finns det ett 1: 1-förhållande mellan LUNs och Volumes, men det behöver inte vara så. Volymhanterare kan ta mer än en LUN och logiskt kombinera dem i en enda enhet för att presentera för värden som en individuell volym.
Så, LUNs och Volumes kan vara samma sak, och de är relaterade, men (särskilt i SAN) är de vanligtvis inte.
Svar
Nå, låt oss förstå detta med ett enkelt exempel.
Tänk på ett scenario där du driver ett litet företag och du har switch ansluten i xyz-avdelningen (LAN1). Nu om gästbesök till ditt företag och vill använda nätverket, så det är väldigt enkelt kommer du inte att låta dem störa ditt nuvarande nätverk, dvs. LAN1.
Så här har du två alternativ:
- Skaffa en ny switch dvs. Switch 2 in ditt företag för gästanvändare och skapa ett separat nätverk för dem, låt oss säga LAN2. Men kom ihåg att detta definitivt kommer att drabbas av kostnaden och hektiskt för distributionen.
- Skapa ett Virtual LAN (VLocal Area Network). I VLAN är grundidén att använda samma enhet och isolera flera nätverk. Så för ovanstående scenario kan du ha två eller flera olika nätverk helt isolerade med varandra på en enda switch och ha full kontroll över dess säkerhetsåtkomst.
Låt oss nu komma till frågan nu:
- Så VLAN använder ID på 12 bitar som läggs till paketet för nätverksidentifiering dvs på vilket VLAN-specifikt paket borde rutt. Så äntligen kan totalt 4095 unika VLAN ”skapas i VLAN.
- VxLAN (Virtual Extensible Local Area Network) som namnet antyder är det den utdragbara versionen av VLAN som används för att utföra samma uppgift. I VxLAN har vi VNI (VxLAN Network Identifier) som läggs till i paketen enligt ovan och som är totalt 24 bitar långa och har förmågan att skapa ca 16 miljoner Vlan på en enda enhet.
Det här är en av skillnaderna där ute, men för enkel förståelse kan du hänvisa detta.
Så i princip upptäcktes VxLAN för att hantera det skalbarhetsproblem som VLAN står inför.