Överväganden för enhetssymmetri för Azure Local- och Windows Server-kluster

Azure Local- och Windows Server-kluster fungerar bäst när varje server har exakt samma enheter.

I verkligheten inser vi att detta inte alltid är praktiskt. Idag kan du köpa rymliga 3 TB hårddiskar; nästa år kan det bli omöjligt att hitta så små enheter. Därför förväntas och stöds en viss mängd blandning och matchning. Tänk dock på att mer symmetri alltid är bättre.

Lagringsdirigering är den underliggande lagringsvirtualiseringstekniken bakom Azure Local och Windows Server. Den här artikeln förklarar begränsningarna och innehåller exempel på konfigurationer som stöds och inte stöds i Lagringsdirigering.

Constraints

I det här avsnittet beskrivs begränsningar när det gäller enhetstyp, modell, storlek och antal enheter.

Type

Alla servrar ska ha samma typer av enheter.

Om en server till exempel har NVMe bör alla ha NVMe.

Number

Alla servrar ska ha samma antal enheter av varje typ.

Om en server till exempel har sex SSD bör alla ha sex SSD.

Model

Vi rekommenderar att du använder enheter av samma modell och version av inbyggd programvara när det är möjligt. Om du inte kan, bör du noggrant välja enheter som är så lika som möjligt. Vi avråder från att blanda och matcha enheter av samma typ med kraftigt olika prestanda- eller uthållighetsegenskaper (såvida inte den ena är cache och den andra är kapacitet) eftersom Storage Spaces Direct fördelar I/O jämnt och inte diskriminerar baserat på modell.

Size

Vi rekommenderar att du använder enheter av samma storlek när det är möjligt. Om du använder kapacitetsenheter av olika storlekar kan det leda till en del oanvändbar kapacitet, och att använda cacheenheter av olika storlekar kanske inte förbättrar cacheprestandan. Mer information finns i nästa avsnitt.

Förstå: obalans i kapacitet

Storage Spaces Direct är så pass robust att det kan hantera kapacitetsobalans mellan enheter och servrar. Även om obalansen är allvarlig fortsätter allt att fungera. Beroende på flera faktorer kan det dock hända att kapacitet som inte är tillgänglig på varje server inte kan användas.

Tänk på följande förenklade bild för att se varför detta händer. Varje färgad ruta representerar en kopia av speglade data. Till exempel är rutorna märkta A, A och A tre kopior av samma data. För att uppfylla serverns feltolerans måste dessa kopior lagras på olika servrar.

Strandad kapacitet

Enligt ritning är Server 1 (10 TB) och Server 2 (10 TB) fulla. Server 3 har större enheter, därför är dess totala kapacitet större (15 TB). Men för att lagra fler trevägsspeglingsdata på Server 3 krävs kopior på Server 1 och Server 2 också, som redan är fulla. Återstående kapacitet på 5 TB på Server 3 kan inte användas – det är en strandad kapacitet.

Optimal placering

Med fyra servrar med kapacitet på 10 TB, 10 TB, 10 TB och 15 TB och trevägsspegling är det däremot möjligt att på ett giltigt sätt placera kopior så att all tillgänglig kapacitet utnyttjas, som illustrerat. När detta är möjligt hittar och använder Storage Spaces Direct allokeraren den optimala placeringen och lämnar ingen strandsatt kapacitet.

Antalet servrar, återhämtning, kapacitetsobalansens allvarlighetsgrad och andra faktorer påverkar om det finns en strandad kapacitet. Den mest försiktiga allmänna regeln är att anta att endast kapacitet som är tillgänglig på varje server garanteras vara användbar.

Förstå: obalans i cacheminnet

Storage Spaces Direct kan också motstå en cacheobalans mellan enheter och mellan servrar. Även om obalansen är allvarlig fortsätter allt att fungera. Dessutom använder den alltid all tillgänglig cache till fullo.

Att använda cacheenheter av olika storlekar kanske inte förbättrar cacheprestandan enhetligt eller förutsägbart: endast I/O för att köra bindningar med större cacheenheter kan få bättre prestanda. Storage Spaces Direct distribuerar I/O jämnt över bindningar och diskriminerar inte baserat på förhållandet cache-till-lagringskapacitet.

Exempelkonfigurationer

Här följer några konfigurationer som stöds och som inte stöds:

Stöds: olika modeller mellan servrar

De två första servrarna använder NVMe-modellen "X" men den tredje servern använder NVMe-modellen "Z", vilket är mycket likt.

Detta stöds.

Stöds: olika modeller inom servern

Varje server använder en annan blandning av HDD-modeller "Y" och "Z", som är mycket lika. Varje server har totalt 10 HDD.

Detta stöds.

stöds: olika storlekar mellan servrar

De två första servrarna använder 4 TB HDD, men den tredje servern använder liknande 6 TB HDD.

Detta stöds, även om det resulterar i strandad kapacitet.

Stöds: olika storlekar inom servern

Varje server använder en viss blandning av 1,2 TB och liknande 1,6 TB SSD. Varje server har totalt 4 SSD.

Detta stöds.

Stöds inte: olika typer av enheter mellan servrar

Server 1 har NVMe, men de andra har det inte.

Detta stöds inte. Typerna av enheter ska vara desamma på alla servrar.

Stöds inte: olika antal av varje typ mellan servrar

Server 3 har fler enheter än de andra.

Detta stöds inte. Antalet enheter av varje typ ska vara detsamma på varje server.

Stöds inte: endast HDD-enheter

Alla servrar har endast hdd-enheter anslutna.

Detta stöds inte. Du måste lägga till minst två cacheenheter (NvME eller SSD) som är anslutna till var och en av servrarna.

Summary

För att sammanfatta bör varje server i klustret ha samma typer av enheter och samma antal av varje typ. Det är möjligt att blanda och matcha enhetsmodeller och enhetsstorlekar efter behov, med hänsyn till ovanstående överväganden.

Nästa steg

Relaterad information finns också:

• Välj enheter