Azure Files-adatredundancia

Az Azure Files mindig több másolatot tárol az adatokról, hogy védve legyen a tervezett és nem tervezett eseményektől, beleértve az átmeneti hardverhibákat, a hálózati vagy áramkimaradásokat és a természeti katasztrófákat. A redundancia biztosítja, hogy a tárfiók a hibák esetén is megfeleljen a rendelkezésre állási és tartóssági céloknak.

Amikor eldönti, hogy melyik redundancialehetőség a legjobb a forgatókönyvhöz, vegye figyelembe az alacsonyabb költségek és a magasabb rendelkezésre állás közötti kompromisszumot. Azok a tényezők, amelyek segítenek meghatározni, hogy melyik redundáns lehetőséget válassza:

Hogyan vannak az adatok replikálva az elsődleges régióban.
Az adatok replikálása az elsődleges régiótól földrajzilag távoli második régióba a regionális katasztrófák (georedundancia) elleni védelem érdekében.

A Microsoft.Storage-erőforrás-szolgáltatóval létrehozott klasszikus Azure-fájlmegosztások kezelése egy közös Azure-erőforráson, egy tárfiókon keresztül történik. A tárfiók egy megosztott tárkészletet jelöl, amely a fájlmegosztások üzembe helyezéséhez használható. További információ a tárfiókokról: Tárfiókok áttekintése.

Tárfiók létrehozásakor egy redundanciabeállítást kell választania ahhoz a tárfiókhoz, amely az adott fiók által közzétett összes társzolgáltatáshoz meg van osztva. Ezért az ugyanabban a tárfiókban üzembe helyezett összes fájlmegosztás ugyanazzal a redundanciával rendelkezik. Előfordulhat, hogy külön tárfiókokban szeretné elkülöníteni a fájlmegosztásokat, ha eltérő redundanciára vonatkozó követelményekkel rendelkeznek.

Redundancia az elsődleges régióban

Az Azure Storage-fiók adatainak replikálása mindig háromszor történik az elsődleges régióban. Az Azure Files két lehetőséget kínál az adatok replikálásáról az elsődleges régióban:

A helyileg redundáns tárolás (LRS) a tárfiókokban lévő adatokat egy vagy több rendelkezésre állási zónába replikálja, amely a választott elsődleges régióban található. Az LRS a legkevésbé költséges replikációs lehetőség, de magas rendelkezésre állást vagy tartósságot igénylő alkalmazások esetében nem ajánlott.
A zónaredundáns tárolás (ZRS) szinkronizálva másolja az adatokat az elsődleges régió három Azure rendelkezésre állási zónájában . A magas rendelkezésre állást igénylő alkalmazások esetében a földrajzi zónaredundáns tárolás (GZRS) használatát javasoljuk, amely ZRS-t használ az elsődleges régióban, és georeplikációval egy másodlagos régióba replikálja az adatokat.

Helyileg redundáns tárolás

A helyileg redundáns tárolás (LRS) a tárfiókokban lévő adatokat egy vagy több, a választott elsődleges régióban található Azure rendelkezésre állási zónába replikálja. Bár nem választhatod ki a kívánt elérhetőségi zónát, az Azure áthelyezheti vagy bővítheti az LRS fiókokat zónák között, hogy javítsa a terheléselosztást. Az LRS legalább 99,9999999999% (11 db 9-es) tartósságot biztosít az objektumok számára egy adott évre vetítve. További információért lásd: Mik azok az Azure elérhetőségi zónák.

Az LRS a legalacsonyabb költségű redundancia lehetőség, és a többi lehetőséghez képest a legkevésbé tartósságot biztosítja. Az LRS védi az adatokat a kiszolgáló állvány- és meghajtóhibáitól. Ha azonban olyan katasztrófa történik, mint a tűz vagy az áradás az adatközpontban, egy LRS-t használó tárfiók összes replikája elveszhet vagy helyreállíthatatlanná válhat. A kockázat csökkentése érdekében a ZRS, GRS vagy GZRS használatát javasoljuk.

Az LRS-t használó tárfiókra irányuló írási kérések szinkron módon történnek. Az írási művelet csak az adatok mindhárom replikára való írása után tér vissza sikeresen.

Az alábbi diagram bemutatja, hogyan replikálja az adatokat egyetlen adatközpontban az LRS használatával:

A rendelkezésre állási zónákban lévő adatok LRS-sel való replikálási módját bemutató ábra.

Az LRS a következő forgatókönyvekhez jó választás:

Ha az alkalmazás olyan adatokat tárol, amelyek könnyen rekonstruálhatók adatvesztés esetén.
Ha az alkalmazás az adatszabályozási követelmények miatt csak egy országon vagy régión belüli adatok replikálására korlátozódik. Bizonyos esetekben előfordulhat, hogy a párosított régiók, amelyeken az adatok georeplikáltak, egy másik országban vagy régióban lehetnek. További információ: Azure régiópárok és párosítatlan régiók.

Az LRS minden Azure-régióban támogatott a HDD (standard) fájlmegosztásokhoz. Az SSD-fájlmegosztásokhoz (prémium szintű) LRS-t támogató régiók listáját az SSD-fájlmegosztások LRS-támogatásával kapcsolatban találja.

Zónák közötti redundáns tárolás

A zónaredundáns tárolás (ZRS) a tárfiókokban lévő adatokat három vagy több, az Ön által választott elsődleges régióban található Azure rendelkezésre állási zónába replikálja. Minden rendelkezésreállási zóna egy fizikailag elkülönített, független áramforrással, hűtéssel és hálózatkezelési megoldással rendelkező hely. A ZRS legalább 99,9999999999999999%-os (12 9-es) tárolási erőforrások tartósságát biztosítja egy adott évben. További információért lásd: Mik azok az Azure elérhetőségi zónák.

A ZRS használatával az adatok akkor is elérhetők olvasási és írási műveletekhez, ha egy zóna elérhetetlenné válik. Ha egy zóna elérhetetlenné válik, az Azure hálózati frissítéseket végez, például DNS-átirányítást. Ezek a frissítések befolyásolhatják az alkalmazásodat, ha a frissítések befejezése előtt hozzáférsz az adatokhoz. A ZRS-alkalmazások tervezésekor kövesse az átmeneti hibakezelés gyakorlatát, beleértve az újrapróbálkozási szabályzatok exponenciális visszakapcsolással történő implementálását is.

A ZRS-t használó tárfiókra irányuló írási kérések szinkron módon történnek. Az írási művelet csak akkor lesz sikeres, ha az adatok a három rendelkezésre állási zónában lévő összes replikához meg lesznek írva.

A ZRS Azure Files-számítási feladatokhoz való használatának egyik előnye, hogy ha egy zóna elérhetetlenné válik, nincs szükség az Azure-fájlmegosztások újracsatlakoztatására a csatlakoztatott ügyfelekről. Javasoljuk, hogy az elsődleges régióban használja a ZRS-t olyan forgatókönyvekhez, amelyek magas rendelkezésre állást igényelnek. Azt is javasoljuk, hogy a ZRS korlátozza az adatok egy adott országba vagy régióba történő replikálását az adatszabályozási követelményeknek való megfelelés érdekében.

Megjegyzés:

Az Azure File Sync minden régióban zónaredundáns, ahol támogatják a rendelkezésre állási zónákat, kivéve az USA Gov Virginia államot. A legtöbb esetben azt javasoljuk, hogy az Azure File Sync felhasználói konfigurálják a tárfiókokat A ZRS vagy a GZRS használatára.

Az alábbi ábra bemutatja, hogyan replikálja az adatokat az elsődleges régió rendelkezésre állási zónái között a ZRS használatával:

Ábra az adatok ZRS-sel való replikálásáról az elsődleges régióban.

A ZRS kiváló teljesítményt, alacsony késést és rugalmasságot biztosít az adatok számára, ha az ideiglenesen elérhetetlenné válik. Előfordulhat azonban, hogy a ZRS önmagában nem védi az adatokat egy olyan regionális katasztrófa ellen, amely több zónát érint véglegesen. A regionális katasztrófák elleni védelem érdekében javasoljuk a GZRS használatát.

ZRS-támogatás régiónként

A ZRS SSD- és HDD-fájlmegosztások esetén is támogatott. Annak megtekintéséhez, hogy mely régiók támogatják a ZRS-t az egyes médiarétegekhez, tekintse meg a következő erőforrásokat:

HDD-fájlmegosztások: Tekintse meg a rendelkezésre állási zóna támogatási oszlopát az Azure-régiók listájában.
SSD-fájlmegosztások: Lásd az SSD-fájlmegosztások ZRS-támogatását.

Redundancia egy másodlagos régióban

Az SMB-fájlmegosztásokhoz magas tartósságot igénylő alkalmazások esetében a georedundáns tárolást választva a tárfiókban lévő adatokat egy másodlagos régióba másolhatja, amely több száz kilométerre van az elsődleges régiótól. Ha a tárfiókot egy másodlagos régióba másolja, akkor az adatok akkor is tartósak lesznek, ha teljes regionális kimaradás vagy olyan katasztrófa történik, amelyben az elsődleges régió nem állítható helyre.

Fontos

Az Azure Files csak HDD-fájlmegosztásokhoz támogatja a georedundanciát (GRS vagy GZRS). Az SSD-fájlmegosztásoknak LRS-t vagy ZRS-t kell használniuk. Emellett más Azure Storage-szolgáltatásokkal ellentétben az Azure Files nem biztosít olvasási hozzáférést a másodlagos régióban lévő adatokhoz feladatátvétel kezdeményezése nélkül. A RA-GRS és a RA-GZRS nem támogatottak. Ha egy tárolófiókot úgy konfigurálsz, hogy RA-GRS vagy RA-GZRS használja, akkor a fájlmegosztások automatikusan GRS-ként vagy GZRS-ként kezelhetők.

Tárfiók létrehozásakor kiválaszthatja a fiók elsődleges régióját. A párosított másodlagos régió az elsődleges régió alapján van meghatározva, és nem módosítható. Az Azure által támogatott régiókkal kapcsolatos további információkért tekintse meg az Azure-régiók listáját.

Az Azure Files két lehetőséget kínál az adatok másodlagos régióba való másolására. A georedundáns tárolási lehetőségek csak HDD SMB fájlmegosztásokhoz állnak rendelkezésre.

A georedundáns tárolás (GRS) az elsődleges régióban LRS használatával replikálja az adatokat, majd aszinkron módon másolja azokat egy másodlagos régióba. Lásd : Georedundáns tárolás.
A geo-zóna-redundáns tárolás (GZRS) az elsődleges régióban ZRS-t használva replikálja az adatokat, majd aszinkron módon másolja egy másodlagos régióba. Lásd: Geo-zóna-redundáns tárolás.

Georedundáns tárolás

A GRS legalább 99,99999999999999%-os (16 darab 9-es) tartósságot biztosít egy adott év alatt.

Az írási művelet először az elsődleges helyre kerül, és az LRS használatával replikálódik. Ezt követően a rendszer aszinkron módon replikálja a frissítést a másodlagos régióba. Ha az adatok a másodlagos helyre kerülnek, az LRS használatával ezen a helyen is replikálódik.

Az alábbi diagram bemutatja, hogyan replikálja az adatokat a GRS:

Diagram az adatok GRS-sel való replikálásáról.

Zóna- és georedundáns tárolás

A geozónaredundáns tárolás (GZRS) egyesíti a rendelkezésre állási zónák közötti redundancia által biztosított magas rendelkezésre állást a georeplikálás által biztosított regionális kimaradások elleni védelemmel. A GZRS-tárfiókban lévő adatok az elsődleges régió három Azure-rendelkezésre állási zónájában lesznek átmásolva, és egy másodlagos földrajzi régióba is replikálódnak a regionális katasztrófák elleni védelem érdekében. Javasoljuk, hogy a GZRS-t olyan alkalmazásokhoz használja, amelyek maximális konzisztenciát, tartósságot és rendelkezésre állást, kiváló teljesítményt és rugalmasságot igényelnek a vészhelyreállításhoz.

GZRS-tárfiókkal továbbra is olvashat és írhat adatokat, ha egy rendelkezésre állási zóna elérhetetlenné válik vagy helyreállíthatatlanná válik. Emellett az adatok tartósak is egy teljes regionális kimaradás vagy katasztrófa esetén, amelyben az elsődleges régió nem állítható helyre. A GZRS-t úgy tervezték, hogy legalább 99,9999999999999999999%-os (16 9's) tartósságot biztosítson egy adott évben.

Az alábbi ábra bemutatja, hogyan replikálja az adatokat a GZRS:

Diagram az adatok GZRS-sel való replikálásáról.

Annak megállapításához, hogy egy régió támogatja-e a GZRS-t, tekintse meg az Azure-régiók listáját. A GZRS támogatásához a régiónak támogatnia kell a rendelkezésre állási zónákat, és párosított régióval kell rendelkeznie.

Georedundáns pillanatkép és szinkron frekvencia

Annak érdekében, hogy a geo-redundáns és geo-zóna-redundáns fájlmegosztások következetes állapotban legyenek a failover esetén, az elsődleges régió 15 percenként létrehoz egy rendszerképet, majd azt a másodlagos régióba replikálja. Amikor feladatátvétel történik a másodlagos régióban, a megosztási állapot a másodlagos régió legújabb rendszerpillanatképén alapul. Georedundáns késés vagy egyéb problémák miatt előfordulhat, hogy a másodlagos régió legújabb rendszerpillanatképe 15 percnél régebbi lehet.

A tárfiók Utolsó szinkronizálási idő (LST) tulajdonsága azt jelzi, hogy az elsődleges régióból származó adatok utoljára sikeresen meg lettek írva a másodlagos régióba. Az Azure Files esetében az utolsó szinkronizálási idő a másodlagos régió legújabb rendszerpillanatképén alapul. A PowerShell vagy az Azure CLI használatával ellenőrizheti a tárfiók utolsó szinkronizálási idejét .

Fontos, hogy megértse az alábbiakat a Legutóbbi szinkronizálási idő tulajdonságról:

A tárfiók "Utolsó szinkronizálási ideje" tulajdonsága azon szolgáltatás alapján van meghatározva (Fájlok, Blobok, Táblák, Üzenetsorok), amelyik szinkronizációban legjobban le van maradva.
Az utolsó szinkronizálási idő nem frissül, ha nem történt módosítás a tárfiókon.
Az utolsó szinkronizálási idő számítása időtúllépést okozhat, ha a fájlmegosztások száma tárfiókonként meghaladja a 100-t. Tárfiókonként kevesebb mint 100 fájlmegosztás ajánlott.

A georedundáns tárolás feladatátvételi szempontjai

GRS vagy GZRS esetén a fájlmegosztások csak akkor lesznek elérhetők a másodlagos régióban, ha átállás történik. Ha az elsődleges régió elérhetetlenné válik, választhatja a másodlagos régióra történő átváltást. A feladatátvételi folyamat frissíti az Azure Files által biztosított DNS-bejegyzést, hogy a másodlagos végpont legyen a tárfiók új elsődleges végpontja. A feladatátvételi folyamat során az adatok nem érhetők el. A feladatátvétel befejezése után az adatok olvasása és írása az új elsődleges régióban történhet. A feladatátvétel befejezése után a másodlagos régió lesz az elsődleges régió, és ismét olvashat és írhat adatokat. További információ: Azure Files vészhelyreállítás és feladatátvétel.

Fontos

Az Azure Files nem támogatja az olvasási hozzáférésű georedundáns tárolást (RA-GRS) vagy az olvasási hozzáférésű földrajzi zóna szerinti redundáns tárolást (RA-GZRS). Ha egy tárfiók RA-GRS vagy RA-GZRS használatára van konfigurálva, a fájlmegosztások GRS vagy GZRS néven lesznek konfigurálva és számlázva.

A következő elemek befolyásolhatják a másodlagos régióba történő átváltást:

A tárfiók feladatátvétele le lesz tiltva, ha a rendszer pillanatképe nem létezik a másodlagos régióban.
A tárfiók átállása blokkolva van, ha a tárfiók több mint 100 000 fájlmegosztást tartalmaz. A tárfiók átkapcsolásához nyisson meg egy támogatási kérést.
A fájl foglalatok és a bérletek nem maradnak megőrizve feladatátvételkor, az ügyfeleknek pedig le kell csatolniuk és újra csatlakoztatniuk a fájlmegosztásokat.
A fájlmegosztási kvóta a feladatátvétel után változhat. A másodlagos régió fájlmegosztási kvótája a rendszer pillanatképének az elsődleges régióban való létrehozásakor konfigurált kvótán alapul.
Átálláskor a folyamatban lévő másolási műveletek megszakadnak. Amikor a másodlagos régióba történő feladatátvétel befejeződött, próbálkozzon újra a másolási művelettel.

Tárolófiók feladatátvitelének elvégzéséhez tekintse meg a következőt: fiók feladatátvitelének kezdeményezése.

Figyelmeztetés

Ha georedundáns tárolással használja az Azure Filest, a címtárlekérdezések nagyobb késést tapasztalhatnak a feladatátvétel után. Ez az elsődleges és a másodlagos tároló közötti szinkronizálás során fordulhat elő, különösen a sok fájllal rendelkező könyvtárak vagy a több pillanatképet tartalmazó megosztások esetében. Ha a gyorsítótár könyvtárában számos fájl található, előfordulhat, hogy a szinkronizálás befejeződéséig némi teljesítménycsökkenés figyelhető meg. Bizonyos esetekben a teljesítményre gyakorolt hatás a szinkronizálás után is megmaradhat.

Georedundancia SSD-fájlmegosztásokhoz

Ahogy korábban említettük, a georedundáns beállítások (GRS és GZRS) nem támogatottak az SSD-fájlmegosztások esetében. A georedundancia azonban más módokon is megvalósítható.

Azure File Sync-forgatókönyvek esetén szinkronizálhatja az Azure-fájlmegosztást (a felhővégpontot), a helyszíni Windows-fájlkiszolgálót és egy csatlakoztatott fájlmegosztást, amely egy másik Azure-régióban lévő virtuális gépen fut (a kiszolgáló végpontja vészhelyreállítás céljából). Le kell tiltania a felhőbeli rétegzést, hogy minden adat helyileg legyen jelen, és elegendő tárterületet építhessen ki az Azure-beli virtuális gépen a teljes adatkészlet tárolásához. Annak érdekében, hogy a módosítások gyorsan replikálódjanak a másodlagos régióba, a fájlokat csak a kiszolgálóvégponton szabad elérni és módosítani, nem pedig az Azure-ban.

Létrehozhat saját szkriptet is, amellyel adatokat másolhat egy másodlagos régióban lévő tárfiókba olyan eszközökkel, mint az AzCopy (a 10.4-es vagy újabb verzió használata az ACL-ek és időbélyegek megőrzéséhez).

A redundancia beállításainak összegzése

A következő szakaszokban található táblázatok az Azure Fileshoz elérhető redundancialehetőségeket összegzik.

Azure Files tartóssági és elérhetőségi paraméterei

Az alábbi táblázat az egyes redundancialehetőségek fő paramétereit ismerteti:

Paraméter	LRS	ZRS	GRS	GZRS
Az adott évre vonatkozó tartósság százalékos aránya	legalább 99,99999999999% (11 darab 9-es)	legalább 99,9999999999999% (12 9-ből)	legalább 99,99999999999999% (ebből 16 darab 9-es)	legalább 99,99999999999999% (ebből 16 darab 9-es)
Olvasási kérelmek rendelkezésre állása	Legalább 99,9% (ritka elérésű szint esetén 99%)	Legalább 99,9% (ritka elérésű szint esetén 99%)	Legalább 99,9% (ritka elérésű szint esetén 99%)	Legalább 99,9% (ritka elérésű szint esetén 99%)
Írási kérelmek rendelkezésre állása	Legalább 99,9% (ritka elérésű szint esetén 99%)	Legalább 99,9% (ritka elérésű szint esetén 99%)	Legalább 99,9% (ritka elérésű szint esetén 99%)	Legalább 99,9% (ritka elérésű szint esetén 99%)
A különálló csomópontokon tárolt adatok másolatainak száma	Három példány egy vagy több rendelkezésre állási zónában egy régión belül	Három példány különálló rendelkezésre állási zónák között egyetlen régión belül	Összesen hat példány, köztük három az elsődleges régióban és három a másodlagos régióban	Összesen hat példány, köztük három különböző rendelkezésre állási zónában az elsődleges régióban és három helyileg redundáns másolat a másodlagos régióban

További információt a tárfiókok SLA-jában talál.

Azure Files tartóssága és elérhetősége kiesés forgatókönyv szerint

Az alábbi táblázat azt jelzi, hogy az adatok tartósak-e és elérhetők-e egy adott forgatókönyvben attól függően, hogy milyen típusú redundancia van érvényben a tárfiókban. Az Azure Files nem támogatja a másodlagos régió olvasási hozzáférését, ha az elsődleges régió elérhetetlenné válik, kivéve, ha feladatátvétel történik.

Üzemkimaradási forgatókönyv	LRS	ZRS	GRS	GZRS
Egy adatközponton belüli csomópont elérhetetlenné válik	Igen	Igen	Igen	Igen
Egy teljes adatközpont (zonális vagy nem zonális) elérhetetlenné válik	Nem	Igen	Igen¹	Igen
Régiószintű kimaradás történik az elsődleges régióban	Nem	Nem	Igen¹	Igen¹

¹ Fiók átvitele szükséges az írási lehetőség visszaállításához, ha az elsődleges régió elérhetetlenné válik.

Az egyes redundancialehetőségekre vonatkozó díjszabási információkért tekintse meg az Azure Files díjszabását.

Régiók támogatottsága különböző számlázási modellek alapján

Az alábbi parancsokkal ellenőrizheti a régiók támogatottságát a különböző számlázási modellek esetében.

A régiók különböző számlázási modelleken alapuló támogatásának megtekintéséhez használja az Azure PowerShellt vagy az Azure CLI-t.

# Login
Connect-AzAccount
# (Optional but recommended if you have multiple subs)
# Set-AzContext -Subscription $subscriptionID

$subscriptionID = "your-subscription-id-number"

# Get token (output is now SecureString by default, see https://learn.microsoft.com/powershell/module/az.accounts/get-azaccesstoken)
$secureToken = (Get-AzAccessToken).Token  # SecureString now

# Convert SecureString -> plaintext (Az 14 migration pattern)
$ssPtr = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($secureToken)
try {
    $plainToken = [System.Runtime.InteropServices.Marshal]::PtrToStringBSTR($ssPtr)
}
finally {
    [System.Runtime.InteropServices.Marshal]::ZeroFreeBSTR($ssPtr)
}

# Call List SKUs
$uri = "https://management.azure.com/subscriptions/$subscriptionID/providers/Microsoft.Storage/skus?api-version=2025-08-01"
$headers = @{ Authorization = "Bearer $plainToken" }

$result = Invoke-RestMethod -Method Get -Uri $uri -Headers $headers

$filteredResult = $result | `
    Select-Object -ExpandProperty value | `
    Where-Object {
        $_.resourceType -eq "storageAccounts" -and
        # Filter based on your needs. FileStorage account kind includes Pv2 and Pv1 file share, where StorageV2 kind includes PayGO file shares.
        $_.kind -in @("FileStorage", "StorageV2") -and
        # Filter based on your needs. "Standard_" for PayGO file share, "StandardV2_" for Pv2 file share, "Premium_" for Pv1 file shares.
        # $_.name.StartsWith("StandardV2_") -and
        # Change region based on your need to see if the region is currently supported (all lowercase, no space in between).
        # $_.locations -eq "italynorth" -and
        $_.name -notin @("Standard_RAGRS", "Standard_RAGZRS")
    }

if ($filteredResult.Count -eq 0) {
    Write-Output "No results found."
} else {
    $filteredResult | `
        Select-Object `
            -Property `
                @{
                    Name = "sku";
                    Expression = { $_.name }
                }, `
                kind, `
                @{
                    Name = "mediaTier";
                    Expression = {
                        if ($_.tier -eq "Premium") {
                            "SSD"
                        } elseif ($_.tier -eq "Standard") {
                            "HDD"
                        } else {
                            "Unknown"
                        }
                    }
                }, `
                @{
                    Name = "billingModel";
                    Expression = {
                        if ($_.name.StartsWith("StandardV2_") -or
                            $_.name.StartsWith("PremiumV2_")
                        ) {
                            "ProvisionedV2"
                        } elseif ($_.name.StartsWith("Premium_")) {
                            "ProvisionedV1"
                        } else {
                            "PayAsYouGo"
                        }
                    }
                }, `
                @{
                    Name = "location";
                    Expression = { $_.locations | Select-Object -First 1 }
                } | ft sku, kind, mediaTier, billingModel, location
}

Ez a szkript jq-t, egy parancssori JSON-processzort használ. A letöltéshez látogasson el a https://jqlang.org/download/

# Login to Azure account
az login

# Track down the subscription ID in GUID format and set subscription ID
subscriptionID="your-subscription-id-number"

# Get Token
token=$(az account get-access-token --query accessToken --output tsv)

# Invoke SRP list SKU API, and get the returned SKU list
result=$(az rest --method get --uri "https://management.azure.com/subscriptions/$subscriptionID/providers/Microsoft.Storage/skus?api-version=2025-08-01" --headers "Authorization=Bearer $token")

# Filter the SKU list to get the required information, customization required here to get the best result.
filteredResult=$(echo $result | jq '.value[] | select(.resourceType == "storageAccounts" and (.kind == "FileStorage" or .kind == "StorageV2") and (.name | test("^(?!Standard_RAGRS|Standard_RAGZRS)")))' )

if [ -z "$filteredResult" ]; then
    echo "No results found."
else
    # Print the table header
    printf "%-30s %-15s %-10s %-20s %-15s\n" "SKU" "Kind" "MediaTier" "BillingModel" "Location"
    # Print the filtered results
    echo $filteredResult | jq -r '. | "\(.name)\t\(.kind)\t\(.tier | if . == "Premium" then "SSD" elif . == "Standard" then "HDD" else "Unknown" end)\t\(.name | if test("^StandardV2_|^PremiumV2_") then "ProvisionedV2" elif test("^Premium_") then "ProvisionedV1" else "PayAsYouGo" end)\t\(.locations)"' | while IFS=$'\t' read -r sku kind mediaTier billingModel location; do
        printf "%-30s %-15s %-10s %-20s %-15s\n" "$sku" "$kind" "$mediaTier" "$billingModel" "$location"
    done
fi

Lásd még

Visszajelzés

Hasznosnak találta ezt az oldalt?

Utolsó frissítés időpontja: 2026-07-17