Kötetek megtervezése Azure Stack HCI-benPlan volumes in Azure Stack HCI

A következőkre vonatkozik: Azure Stack HCI, Version 20H2; Windows Server 2019Applies to: Azure Stack HCI, version 20H2; Windows Server 2019

Ez a témakör útmutatást nyújt a kötetek Azure Stack HCI-ben történő megtervezéséhez, hogy megfeleljenek a számítási feladatok teljesítményének és kapacitásának, például a fájlrendszer, a rugalmasság típusa és a méret kiválasztásával.This topic provides guidance for how to plan volumes in Azure Stack HCI to meet the performance and capacity needs of your workloads, including choosing their filesystem, resiliency type, and size.

Áttekintés: Mik a kötetek?Review: What are volumes

A köteteken a számítási feladatok szükségesek, például VHD-vagy VHDX-fájlok a Hyper-V virtuális gépekhez.Volumes are where you put the files your workloads need, such as VHD or VHDX files for Hyper-V virtual machines. A kötetek egyesítik a Storage-készlet meghajtóit, hogy bevezessék a hibatűrést, a méretezhetőséget és a közvetlen tárolóhelyekteljesítményének előnyeit, valamint a Azure stack HCI mögötti szoftver által meghatározott tárolási technológiát.Volumes combine the drives in the storage pool to introduce the fault tolerance, scalability, and performance benefits of Storage Spaces Direct, the software-defined storage technology behind Azure Stack HCI.

Megjegyzés

A Közvetlen tárolóhelyek dokumentációjában a "kötet" kifejezést használjuk, hogy közösen hivatkozzon a kötetre és a virtuális lemezre, beleértve a más beépített Windows-funkciók, például a fürt megosztott kötetei (CSV) és a ReFS által nyújtott funkciókat is.Throughout documentation for Storage Spaces Direct, we use term "volume" to refer jointly to the volume and the virtual disk under it, including functionality provided by other built-in Windows features such as Cluster Shared Volumes (CSV) and ReFS. A megvalósítási szintű különbségtétel nem szükséges a Közvetlen tárolóhelyek sikeres tervezéséhez és üzembe helyezéséhez.Understanding these implementation-level distinctions is not necessary to plan and deploy Storage Spaces Direct successfully.

A diagram három olyan mappát mutat be, amelyek kötetként címkézett virtuális lemezzel vannak társítva, amelyek mindegyike egy közös tárolóeszközhöz van társítva.

Minden kötet a fürt összes kiszolgálója számára elérhető.All volumes are accessible by all servers in the cluster at the same time. A létrehozás után a **C:\ClusterStorage \ ** az összes kiszolgálón megjelennek.Once created, they show up at C:\ClusterStorage\ on all servers.

A képernyőfelvételen egy ClusterStorage nevű fájlkezelő ablak látható, amely a Volume1, a indítása kötet2 és a Volume3 nevű köteteket tartalmazza.

A létrehozandó kötetek számának kiválasztásaChoosing how many volumes to create

Azt javasoljuk, hogy a kötetek számát a fürtben lévő kiszolgálók számának többszörösére állítsa.We recommend making the number of volumes a multiple of the number of servers in your cluster. Ha például 4 kiszolgálóval rendelkezik, akkor a 4 teljes kötettel konzisztens teljesítményt fog tapasztalni, mint 3 vagy 5.For example, if you have 4 servers, you will experience more consistent performance with 4 total volumes than with 3 or 5. Ez lehetővé teszi a fürt számára, hogy a "tulajdonos" kötetet (az egyik kiszolgáló kezeli az egyes kötetek metaadat-összehangolása) egyenletesen a kiszolgálók között.This allows the cluster to distribute volume "ownership" (one server handles metadata orchestration for each volume) evenly among servers.

Azt javasoljuk, hogy fürtre korlátozza a kötetek teljes számát 64 kötetre.We recommend limiting the total number of volumes to 64 volumes per cluster.

A fájlrendszer kiválasztásaChoosing the filesystem

Javasoljuk, hogy az új, rugalmas fájlrendszert (ReFS) használja a közvetlen tárolóhelyekhoz.We recommend using the new Resilient File System (ReFS) for Storage Spaces Direct. A ReFS a Premier fájlrendszer, amely a virtualizáció számára készült, és számos előnnyel jár, többek között a drámai teljesítmény-gyorsítás és az adatsérülés elleni beépített védelem.ReFS is the premier filesystem purpose-built for virtualization and offers many advantages, including dramatic performance accelerations and built-in protection against data corruption. Szinte minden fontos NTFS-funkciót támogat, beleértve a Windows Server 1709-es és újabb verzióiban az demásolást is.It supports nearly all key NTFS features, including Data Deduplication in Windows Server version 1709 and later. A részletekért tekintse meg a ReFS funkcióinak összehasonlító táblázatát .See the ReFS feature comparison table for details.

Ha a számítási feladathoz olyan szolgáltatásra van szükség, amelyet a ReFS még nem támogat, használhat NTFS helyet.If your workload requires a feature that ReFS doesn't support yet, you can use NTFS instead.

Tipp

A különböző fájlrendszerrel rendelkező kötetek ugyanabban a fürtben is létezhetnek.Volumes with different file systems can coexist in the same cluster.

A rugalmasság típusának kiválasztásaChoosing the resiliency type

A Közvetlen tárolóhelyekban lévő kötetek rugalmasságot biztosítanak a hardveres problémák, például a meghajtó-vagy kiszolgálói hibák elleni védelemhez, valamint a folyamatos rendelkezésre állás engedélyezéséhez a kiszolgáló karbantartása, például a szoftverfrissítések terén.Volumes in Storage Spaces Direct provide resiliency to protect against hardware problems, such as drive or server failures, and to enable continuous availability throughout server maintenance, such as software updates.

Megjegyzés

A választható rugalmassági típusok függetlenek egymástól, hogy milyen típusú meghajtókat használ.Which resiliency types you can choose is independent of which types of drives you have.

Két kiszolgálóvalWith two servers

A fürt két kiszolgálójának használatával kétirányú tükrözést használhat, vagy használhat beágyazott rugalmasságot is.With two servers in the cluster, you can use two-way mirroring or you can use nested resiliency.

A kétirányú tükrözés az összes adattal két példányt tart, egy példányt az egyes kiszolgálókon lévő meghajtókon.Two-way mirroring keeps two copies of all data, one copy on the drives in each server. A tároló hatékonysága 50%; 1 TB-nyi adat írásához legalább 2 TB fizikai tárolási kapacitásra van szükség a Storage-készletben.Its storage efficiency is 50 percent; to write 1 TB of data, you need at least 2 TB of physical storage capacity in the storage pool. A kétirányú tükrözések biztonságosan tolerálják az egyik hardverhiba (egy kiszolgáló vagy meghajtó) számára.Two-way mirroring can safely tolerate one hardware failure at a time (one server or drive).

A diagramon látható, hogy az adatmennyiség és a másolás körkörös nyíllal történt, és mindkét kötet társítva van a kiszolgálók egyik bankjának a kötetei közé.

A beágyazott rugalmasság biztosítja az adatrugalmasságot a kiszolgálók között kétirányú tükrözéssel, majd rugalmasságot biztosít a kiszolgálón a kétirányú tükrözéssel vagy a tükrözött gyorsítású paritással.Nested resiliency provides data resiliency between servers with two-way mirroring, then adds resiliency within a server with two-way mirroring or mirror-accelerated parity. A beágyazás az adatrugalmasságot is biztosítja, még akkor is, ha az egyik kiszolgáló újraindul vagy elérhetetlenné válik.Nesting provides data resilience even when one server is restarting or unavailable. A tároló hatékonysága 25%, beágyazott, kétutas tükrözéssel és körülbelül 35-40%-kal a beágyazott tükrözött felgyorsított paritáson.Its storage efficiency is 25 percent with nested two-way mirroring and around 35-40 percent for nested mirror-accelerated parity. A beágyazott rugalmasság a két hardverhiba (két meghajtó, a kiszolgáló és a megmaradt kiszolgáló meghajtója) esetében képes biztonságosan tolerálni.Nested resiliency can safely tolerate two hardware failures at a time (two drives, or a server and a drive on the remaining server). A hozzáadott adatrugalmasság miatt javasoljuk, hogy beágyazott rugalmasságot használjon két kiszolgálóból álló fürtök éles üzembe helyezéséhez.Because of this added data resilience, we recommend using nested resiliency on production deployments of two-server clusters. További információ: beágyazott rugalmasság.For more info, see Nested resiliency.

A diagram a beágyazott tükrözött felgyorsított paritást jeleníti meg, kétirányú tükrözéssel az egyes kiszolgálókon belül az egyes kiszolgálók paritási rétegéhez tartozó kétirányú tükrözéssel.

Három kiszolgálóvalWith three servers

Három kiszolgáló esetén a jobb hibatűrés és teljesítmény érdekében háromutas tükrözést kell használni.With three servers, you should use three-way mirroring for better fault tolerance and performance. A háromutas tükrözés az összes adattal három példányt tart, egy példányt az egyes kiszolgálókon található meghajtókon.Three-way mirroring keeps three copies of all data, one copy on the drives in each server. A tárterület hatékonysága 33,3 százalék – 1 TB adat írásához legalább 3 TB fizikai tárolási kapacitásra van szükség a Storage-készletben.Its storage efficiency is 33.3 percent – to write 1 TB of data, you need at least 3 TB of physical storage capacity in the storage pool. A háromutas tükrözés képes biztonságosan elviselni legalább két hardveres problémát (meghajtó vagy kiszolgáló)egyszerre.Three-way mirroring can safely tolerate at least two hardware problems (drive or server) at a time. Ha 2 csomópont elérhetetlenné válik, a tároló elveszíti a kvórumot, mivel a lemezek 2/3 nem érhető el, és a virtuális lemezek nem lesznek elérhetők.If 2 nodes become unavailable the storage pool will lose quorum, since 2/3 of the disks are not available, and the virtual disks will be unaccessible. A csomópontok azonban leállíthatók, és egy vagy több lemez egy másik csomóponton meghiúsulhat, és a virtuális lemezek online állapotban maradnak.However, a node can be down and one or more disks on another node can fail and the virtual disks will remain online. Ha például egy kiszolgáló újraindításakor hirtelen egy másik meghajtó vagy kiszolgáló meghibásodik, az összes adat biztonságban és folyamatosan elérhető marad.For example, if you're rebooting one server when suddenly another drive or server fails, all data remains safe and continuously accessible.

A diagramon egy, a fizikai lemezeket tartalmazó kiszolgálóhoz társított minden kötethez tartozó, a kötet címkével ellátott és a két címkével ellátott másolat látható.

Négy vagy több kiszolgálóvalWith four or more servers

Négy vagy több kiszolgáló esetén az egyes kötetek esetében választhat, hogy a háromutas tükrözést, a kettős paritást (más néven "törlési kódolást") használja-e, vagy a kettőt a tükrözött gyorsítású paritással keveri.With four or more servers, you can choose for each volume whether to use three-way mirroring, dual parity (often called "erasure coding"), or mix the two with mirror-accelerated parity.

A kettős paritás ugyanolyan hibatűrést biztosít, mint a háromutas tükrözés, de a jobb tárolási hatékonyságot.Dual parity provides the same fault tolerance as three-way mirroring but with better storage efficiency. Négy kiszolgáló esetén a tároló hatékonysága 50,0%; 2 TB-nyi adat tárolásához a Storage-készletben 4 TB fizikai tárolókapacitás szükséges.With four servers, its storage efficiency is 50.0 percent; to store 2 TB of data, you need 4 TB of physical storage capacity in the storage pool. Ez 66,7 százalékkal növeli a tárolási hatékonyságot hét kiszolgálóval, és akár 80,0%-os tárolási hatékonyságot is biztosít.This increases to 66.7 percent storage efficiency with seven servers, and continues up to 80.0 percent storage efficiency. A kompromisszum az, hogy a paritásos kódolás nagyobb számítási igényű, ami korlátozhatja a teljesítményét.The tradeoff is that parity encoding is more compute-intensive, which can limit its performance.

A diagramon két, a fizikai lemezeket tartalmazó kiszolgálóhoz társított kötettel rendelkező, két kötet címkézett adatai és két címkézett paritás látható.

A használni kívánt rugalmassági típus a munkaterhelés igényeitől függ.Which resiliency type to use depends on the needs of your workload. Az alábbi táblázat összefoglalja, hogy mely számítási feladatok alkalmasak minden rugalmassági típushoz, valamint az egyes rugalmassági típusok teljesítményének és tárolásának hatékonyságát.Here's a table that summarizes which workloads are a good fit for each resiliency type, as well as the performance and storage efficiency of each resiliency type.

Rugalmasság típusaResiliency type Kapacitás hatékonyságaCapacity efficiency SebességSpeed Számítási feladatokWorkloads
TükrözöttMirror A tárterület hatékonysága 33%-ot mutat
Háromutas tükrözés: 33%Three-way mirror: 33%
Kétirányú tükrözés: 50%Two-way-mirror: 50%
Teljesítmény, amely a 100%-ot mutatja
Legmagasabb teljesítményHighest performance
Virtualizált munkaterhelésekVirtualized workloads
AdatbázisokDatabases
Egyéb nagy teljesítményű számítási feladatokOther high performance workloads
Tükrözött, gyorsított paritásMirror-accelerated parity A tárolási hatékonyság mintegy 50%-ot mutat
A tükrözés és a paritás arányának függvényeDepends on proportion of mirror and parity
Körülbelül 20%-os teljesítmény
Sokkal lassabb, mint a tükrözés, de akár kétszer is gyorsabb a kettős paritásMuch slower than mirror, but up to twice as fast as dual-parity
A legjobb nagy sorszámú írási és olvasási műveletekhezBest for large sequential writes and reads
Archiválás és biztonsági mentésArchival and backup
Virtualizált asztali infrastruktúraVirtualized desktop infrastructure
Kettős paritásúDual-parity A tárolási hatékonyság mintegy 80%-ot mutat
4 kiszolgáló: 50%4 servers: 50%
16 kiszolgáló: legfeljebb 80%16 servers: up to 80%
Körülbelül 10%-os teljesítmény
Maximális I/O-késés & CPU-használat az írásokbanHighest I/O latency & CPU usage on writes
A legjobb nagy sorszámú írási és olvasási műveletekhezBest for large sequential writes and reads
Archiválás és biztonsági mentésArchival and backup
Virtualizált asztali infrastruktúraVirtualized desktop infrastructure

Ha a teljesítménnyel kapcsolatos kérdések többségeWhen performance matters most

A szigorú késési követelményekkel rendelkező vagy nagy mennyiségű kevert véletlenszerű IOPS igénylő munkaterhelések, például SQL Server adatbázisok vagy a teljesítményre érzékeny Hyper-V virtuális gépek, a tükrözést használó köteteken futnak a teljesítmény maximalizálása érdekében.Workloads that have strict latency requirements or that need lots of mixed random IOPS, such as SQL Server databases or performance-sensitive Hyper-V virtual machines, should run on volumes that use mirroring to maximize performance.

Tipp

A tükrözés gyorsabb, mint bármely más rugalmassági típus.Mirroring is faster than any other resiliency type. Tükrözést használunk szinte minden teljesítménybeli példához.We use mirroring for nearly all our performance examples.

A kapacitással kapcsolatos kérdésekWhen capacity matters most

A ritkábban, például adattárházak vagy "hideg" tárolást igénylő munkaterhelések a tárolás hatékonyságának maximalizálása érdekében a kettős paritást használó köteteken futnak.Workloads that write infrequently, such as data warehouses or "cold" storage, should run on volumes that use dual parity to maximize storage efficiency. Bizonyos egyéb munkaterhelések, például a hagyományos fájlkiszolgálók, a virtuális asztali infrastruktúra (VDI) vagy mások, amelyek nem hoznak létre nagy mennyiségű, gyorsan sodródó, véletlenszerű IO-forgalmat és/vagy nem igénylik a legjobb teljesítményt, akár kettős paritást is használhatnak.Certain other workloads, such as traditional file servers, virtual desktop infrastructure (VDI), or others that don't create lots of fast-drifting random IO traffic and/or don't require the best performance may also use dual parity, at your discretion. A paritás elkerülhetetlenül növeli a CPU-kihasználtságot és az i/o-késést, különösen az írások esetében, a tükrözéshez képest.Parity inevitably increases CPU utilization and IO latency, particularly on writes, compared to mirroring.

Az adatmennyiség tömeges írásaWhen data is written in bulk

Az olyan számítási feladatok, amelyek nagy mennyiségű, szekvenciális (például archiválási vagy biztonsági mentési) műveletekre írnak, egy másik lehetőséggel rendelkeznek: az egyik kötet tükröző és kettős paritást is tartalmazhat.Workloads that write in large, sequential passes, such as archival or backup targets, have another option: one volume can mix mirroring and dual parity. Először a tükrözött részbe írja a földet, és később fokozatosan áthelyezi a paritási részbe.Writes land first in the mirrored portion and are gradually moved into the parity portion later. Ez felgyorsítja a betöltést, és csökkenti az erőforrás-használatot, ha a nagyméretű írások megérkeznek, így a nagy számítási igényű paritásos kódolás hosszabb idő alatt megtörténik.This accelerates ingestion and reduces resource utilization when large writes arrive by allowing the compute-intensive parity encoding to happen over a longer time. A részek méretezése során vegye figyelembe, hogy az egyszerre megjelenő írási mennyiség (például egy napi biztonsági mentés) kényelmesen illeszkedik a tükrözési részhez.When sizing the portions, consider that the quantity of writes that happen at once (such as one daily backup) should comfortably fit in the mirror portion. Ha például naponta egyszer betölti a 100 GB-ot, vegye fontolóra a tükrözést az 150 GB-ról 200 GB-ra, a REST-hez pedig kettős paritást használjon.For example, if you ingest 100 GB once daily, consider using mirroring for 150 GB to 200 GB, and dual parity for the rest.

Az eredményül kapott tárolási hatékonyság a választott aránytól függ.The resulting storage efficiency depends on the proportions you choose. Ebben a bemutatóban talál néhány példát.See this demo for some examples.

Tipp

Ha az írás teljesítményének hirtelen csökkenését tapasztalja az adatok betöltésének partway keresztül, akkor azt jelezheti, hogy a tükrözött rész nem elég nagy, vagy hogy a tükrözött gyorsítású paritás nem megfelelő a használati esethez.If you observe an abrupt decrease in write performance partway through data ingestion, it may indicate that the mirror portion is not large enough or that mirror-accelerated parity isn't well suited for your use case. Ha például az írási teljesítmény 400 MB/s-ról 40 MB/s-ra csökken, érdemes lehet kibővíteni a tükrözési részt, vagy váltani a háromutas tükrözésre.As an example, if write performance decreases from 400 MB/s to 40 MB/s, consider expanding the mirror portion or switching to three-way mirror.

NVMe-, SSD-és HDD-alapú telepítésekAbout deployments with NVMe, SSD, and HDD

A kétféle meghajtóval üzemelő példányok esetében a gyorsabb meghajtók biztosítják a gyorsítótárazást, miközben a lassabb meghajtók kapacitást biztosítanak.In deployments with two types of drives, the faster drives provide caching while the slower drives provide capacity. Ez automatikusan megtörténik – további információért lásd: a gyorsítótár megismerése közvetlen tárolóhelyekban.This happens automatically – for more information, see Understanding the cache in Storage Spaces Direct. Ilyen központi telepítések esetén az összes kötet ugyanazon típusú meghajtókon, a kapacitás-meghajtókon található.In such deployments, all volumes ultimately reside on the same type of drives – the capacity drives.

Az üzemelő példányok mindhárom típusú meghajtóval csak a leggyorsabb meghajtókon (NVMe) biztosítanak gyorsítótárazást, így a kapacitás biztosításához két típusú meghajtó (SSD és HDD) is rendelkezésre áll.In deployments with all three types of drives, only the fastest drives (NVMe) provide caching, leaving two types of drives (SSD and HDD) to provide capacity. Minden kötet esetében kiválaszthatja, hogy a teljes egészében az SSD-rétegen, teljes egészében a HDD-szinten található-e, vagy a kettőre terjed ki.For each volume, you can choose whether it resides entirely on the SSD tier, entirely on the HDD tier, or whether it spans the two.

Fontos

Javasoljuk, hogy az SSD-réteg használatával helyezze el a legtöbb teljesítményre érzékeny munkaterhelést az összes flash-meghajtón.We recommend using the SSD tier to place your most performance-sensitive workloads on all-flash.

A kötetek méretének kiválasztásaChoosing the size of volumes

Javasoljuk, hogy az egyes kötetek méretét 64 TB-ra korlátozza a Windows Server 2019-ben.We recommend limiting the size of each volume to 64 TB in Windows Server 2019.

Tipp

Ha olyan biztonsági mentési megoldást használ, amely a Kötet árnyékmásolata szolgáltatás (VSS) és a VolSnap szoftver szolgáltatóján alapul – akárcsak a Fájlkiszolgálói munkaterhelések esetében –, a kötet méretének 10 TB-ra való korlátozása növeli a teljesítményt és a megbízhatóságot.If you use a backup solution that relies on the Volume Shadow Copy service (VSS) and the Volsnap software provider—as is common with file server workloads—limiting the volume size to 10 TB will improve performance and reliability. A Hyper-V RCT API-t és/vagy ReFS-blokkoló és/vagy a natív SQL backup API-kat használó biztonsági mentési megoldások 32 TB-os és újabb rendszereken is elvégezhetők.Backup solutions that use the newer Hyper-V RCT API and/or ReFS block cloning and/or the native SQL backup APIs perform well up to 32 TB and beyond.

LábnyomFootprint

A kötetek mérete a felhasználható kapacitásra, az általa tárolt adatmennyiségre utal.The size of a volume refers to its usable capacity, the amount of data it can store. Ezt a New-Volume parancsmag -size paraméter adja meg, majd a Size (méret ) tulajdonságban jelenik meg, amikor futtatja a Get-Volume parancsmagot.This is provided by the -Size parameter of the New-Volume cmdlet and then appears in the Size property when you run the Get-Volume cmdlet.

A méret különbözik a kötet lábnyomával, a tárterület teljes fizikai tárolási kapacitásával.Size is distinct from volume's footprint, the total physical storage capacity it occupies on the storage pool. A lábnyom a rugalmasság típusától függ.The footprint depends on its resiliency type. A háromutas tükrözést használó kötetek esetében például a méretük háromszorosa a lábnyomnak.For example, volumes that use three-way mirroring have a footprint three times their size.

A kötetek lábnyomait el kell helyezni a tárolóban.The footprints of your volumes need to fit in the storage pool.

A diagram egy 2 TB-os kötetet mutat be a Storage-készletben lévő 6 TB-os adatforgalomhoz képest, három megadott szorzóval.

Kapacitás foglalásaReserve capacity

Ha a tárolóban lévő egyes kapacitások nem vannak lefoglalva, a meghajtók meghibásodása után a kötetek lemezterületet biztosítanak a "helyben" javításához, ami javítja az adatbiztonságot és a teljesítményt.Leaving some capacity in the storage pool unallocated gives volumes space to repair "in-place" after drives fail, improving data safety and performance. Ha elegendő kapacitás áll rendelkezésre, azonnali, helyi, párhuzamos javítással a kötetek teljes rugalmassága állítható vissza, még a hibás meghajtók lecserélése előtt is.If there is sufficient capacity, an immediate, in-place, parallel repair can restore volumes to full resiliency even before the failed drives are replaced. Ez automatikusan megtörténik.This happens automatically.

Javasoljuk, hogy kiszolgálóként, legfeljebb 4 meghajtón egy kapacitású meghajtó megfelelőjét őrizze meg.We recommend reserving the equivalent of one capacity drive per server, up to 4 drives. Saját belátása szerint továbbra is fenntarthatja magát, de ez a minimális javaslat azonnali, helyi, párhuzamos javítást tesz elérhetővé a meghajtó meghibásodása után.You may reserve more at your discretion, but this minimum recommendation guarantees an immediate, in-place, parallel repair can succeed after the failure of any drive.

A diagram egy tárolóban található több lemezhez társított kötetet, valamint a tartalékként megjelölt nem társított lemezeket jeleníti meg.

Ha például 2 kiszolgálóval rendelkezik, és 1 TB kapacitású meghajtókat használ, a készletbe 2 x 1 = 2 TB-ot kell kivonni tartalékként.For example, if you have 2 servers and you are using 1 TB capacity drives, set aside 2 x 1 = 2 TB of the pool as reserve. Ha 3 kiszolgálóval és 1 TB kapacitású meghajtóval rendelkezik, állítsa 3 x 1 = 3 TB tartalékként.If you have 3 servers and 1 TB capacity drives, set aside 3 x 1 = 3 TB as reserve. Ha 4 vagy több kiszolgálóval és 1 TB kapacitású meghajtóval rendelkezik, állítsa be a 4 x 1 = 4 TB-ot tartalékként.If you have 4 or more servers and 1 TB capacity drives, set aside 4 x 1 = 4 TB as reserve.

Megjegyzés

A mindhárom típusú (NVMe + SSD + HDD) meghajtóval rendelkező fürtök esetében javasoljuk, hogy kiszolgálóként egy SSD-t és egy HDD-t, vagy akár 4 meghajtót is kiszolgáljon.In clusters with drives of all three types (NVMe + SSD + HDD), we recommend reserving the equivalent of one SSD plus one HDD per server, up to 4 drives of each.

Példa: kapacitás megtervezéseExample: Capacity planning

Gondolja át a 1 4-Server fürtöt.Consider one four-server cluster. Mindegyik kiszolgálón van néhány gyorsítótár-meghajtó, valamint 16 TB-os meghajtó a kapacitáshoz.Each server has some cache drives plus sixteen 2 TB drives for capacity.

4 servers x 16 drives each x 2 TB each = 128 TB

Ebből a 128 TB-ból a tárolóban négy meghajtót vagy 8 TB-ot állítottunk fel, így a helyi javítások a meghibásodások nélkül is megtörténhetnek, és nem kell lecserélniük a meghajtókat.From this 128 TB in the storage pool, we set aside four drives, or 8 TB, so that in-place repairs can happen without any rush to replace drives after they fail. Ez 120 TB-nyi fizikai tárolási kapacitást hagy a készletben, amelyből kötetek hozhatók létre.This leaves 120 TB of physical storage capacity in the pool with which we can create volumes.

128 TB – (4 x 2 TB) = 120 TB

Tegyük fel, hogy üzembe helyezésünk néhány nagy teljesítményű Hyper-V virtuális gép üzemeltetésére van szükség, de a sok hideg tárterület – a régi fájlok és a biztonsági mentések is megmaradnak.Suppose we need our deployment to host some highly active Hyper-V virtual machines, but we also have lots of cold storage – old files and backups we need to retain. Mivel négy kiszolgálónk van, hozzunk létre négy kötetet.Because we have four servers, let's create four volumes.

Helyezzük a virtuális gépeket az első két kötetre, a Volume1 és a indítása kötet2.Let's put the virtual machines on the first two volumes, Volume1 and Volume2. A teljesítmény maximalizálása érdekében a ReFS-t (a gyorsabb létrehozás és az ellenőrzőpontok esetében) és a kétirányú tükrözést is választjuk.We choose ReFS as the filesystem (for the faster creation and checkpoints) and three-way mirroring for resiliency to maximize performance. Helyezze a hideg tárolót a másik két kötetre, a 3. kötetre és a 4. kötetre.Let's put the cold storage on the other two volumes, Volume 3 and Volume 4. Az NTFS fájlrendszert (az deduplikálás esetében) és a kettős paritás rugalmasságát a kapacitás maximalizálása érdekében választjuk.We choose NTFS as the filesystem (for Data Deduplication) and dual parity for resiliency to maximize capacity.

Nem szükséges, hogy az összes kötet azonos méretű legyen, de az egyszerűség kedvéért tegyük fel, hogy mind a 12 TB-ot.We aren't required to make all volumes the same size, but for simplicity, let's – for example, we can make them all 12 TB.

A Volume1 és a indítása KÖTET2 a 12 TB x 33,3 százalékos hatékonyságot = 36 TB fizikai tárolókapacitást foglalja maguk után.Volume1 and Volume2 will each occupy 12 TB x 33.3 percent efficiency = 36 TB of physical storage capacity.

A Volume3 és a VOLUME4 egyaránt 12 TB x 50,0 százalékos hatékonyságot foglalnak magukban: 24 TB fizikai tárolási kapacitással.Volume3 and Volume4 will each occupy 12 TB x 50.0 percent efficiency = 24 TB of physical storage capacity.

36 TB + 36 TB + 24 TB + 24 TB = 120 TB

A négy kötet pontosan illeszkedik a készletben elérhető fizikai tárolási kapacitáshoz.The four volumes fit exactly on the physical storage capacity available in our pool. Tökéletes!Perfect!

A diagramon a 2 12 TB-os háromutas tükrözött kötetek láthatók 120, amelyek mindegyike a 36 TB tárterülethez és a 2 12 TB-os kettős paritású kötetekhez kapcsolódik, amelyek mindegyike 24 TB-ra van társítva.

Tipp

Nem kell azonnal létrehoznia az összes kötetet.You don't need to create all the volumes right away. Később bármikor kiterjesztheti a köteteket, vagy új köteteket hozhat létre.You can always extend volumes or create new volumes later.

Az egyszerűség kedvéért ez a példa decimális (Base-10) egységeket használ az egészben, ami azt jelenti, hogy 1 TB = 1 000 000 000 000 bájt.For simplicity, this example uses decimal (base-10) units throughout, meaning 1 TB = 1,000,000,000,000 bytes. A Windows tárolási mennyiségei azonban bináris (Base-2) egységben jelennek meg.However, storage quantities in Windows appear in binary (base-2) units. A 2 TB-os meghajtó például 1,82 TiB-ként fog megjelenni a Windows rendszerben.For example, each 2 TB drive would appear as 1.82 TiB in Windows. Hasonlóképpen, az 128 TB-os tárolási készlet a 116,41 TiB-ként fog megjelenni.Likewise, the 128 TB storage pool would appear as 116.41 TiB. Ez a várható eredmény.This is expected.

HasználatUsage

Lásd: kötetek létrehozása Azure stack HCI-ben.See Creating volumes in Azure Stack HCI.

További lépésekNext steps

További információért lásd még:For more information, see also: