Azure Files-adatredundancia

2025-05-20

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.

Az 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.

A következőkre vonatkozik:

Felügyeleti modell	Számlázási modell	Médiaréteg	Redundancia
Microsoft.Storage	Előre beállított v2	HDD (standard)	Lokális (LRS)
Microsoft.Storage	Előre beállított v2	HDD (standard)	Zóna (ZRS)
Microsoft.Storage	Előre beállított v2	HDD (standard)	Geo (GRS)
Microsoft.Storage	Előre beállított v2	HDD (standard)	Geozone (GZRS)
Microsoft.Storage	Előkészített v1	SSD (prémium)	Lokális (LRS)
Microsoft.Storage	Előkészített v1	SSD (prémium)	Zóna (ZRS)
Microsoft.Storage	Fizetés a használat szerint	HDD (standard)	Lokális (LRS)
Microsoft.Storage	Fizetés a használat szerint	HDD (standard)	Zóna (ZRS)
Microsoft.Storage	Fizetés a használat szerint	HDD (standard)	Geo (GRS)
Microsoft.Storage	Fizetés a használat szerint	HDD (standard)	Geozone (GZRS)

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) háromszor szinkronizálja az adatokat egyetlen fizikai helyen az elsődleges régióban. 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) háromszor replikálja a tárfiókot az elsődleges régió egyetlen adatközpontjában. Az LRS legalább 99,999999999999%-os tartósságot biztosít egy adott évben.

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:

Diagram, amely bemutatja, hogyan replikálja az adatokat egyetlen adatközpontban az LRS használatával.

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-fájlmegosztásokhoz. Az SSD-fájlmegosztások LRS-t támogató régióinak 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) szinkronizálva replikálja a tárfiókot az elsődleges régió három Azure rendelkezésre állási zónájára . 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,9999999999%-os (12 darab 9-es) tartósságot biztosít egy adott évben.

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 elvégzi a hálózati frissítéseket, például a DNS újrapontozását. Ezek a frissítések hatással lehetnek az alkalmazásra, ha a frissítések befejeződése előtt hozzáfér 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

Annak megismeréséhez, hogy mely régiók támogatják a ZRS-t a standard fájlmegosztásokhoz, tekintse meg az Azure-régiók listáját , és tekintse meg a rendelkezésre állási zóna támogatási oszlopát. A ZRS támogatást élvez a standard, általános célú v2-tárfiókokban mind a három standard szint esetében: tranzakcióoptimalizált, forró és hideg.

A ZRS az SSD-fájlmegosztások esetében a tárfiók típusán FileStorage keresztül támogatott. Az SSD-fájlmegosztási fiókok ZRS-t támogató régióinak listáját az SSD-fájlmegosztások ZRS-támogatásában találja.

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.

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 jelenleg csak standard SMB-fájlmegosztásokhoz érhetők el.

A Georedundáns tárolás (GRS) az adatokat szinkron módon, az LRS használatával háromszor másolja le az elsődleges régió egy fizikai helyére. Ezután aszinkron módon másolja át az adatokat a másodlagos régió egy fizikai helyére. A másodlagos régión belül az adatok szinkronizálása háromszor történik az LRS használatával.
A geozónaredundáns tárolás (GZRS) szinkronizálva másolja az adatokat az elsődleges régió három Azure rendelkezésre állási zónájában a ZRS használatával. Ezután aszinkron módon másolja át az adatokat a másodlagos régió egy fizikai helyére. A másodlagos régión belül az adatok szinkronizálása háromszor történik az LRS használatával.

A GRS és a GZRS közötti elsődleges különbség az adatok replikálása az elsődleges régióban. A másodlagos régión belül az adatok szinkronizálása mindig háromszor történik az LRS használatával. A másodlagos régió LRS-jei védik az adatokat a hardverhibáktól.

Georedundáns tárolás

A Georedundáns tárolás (GRS) az adatokat szinkron módon, az LRS használatával háromszor másolja le az elsődleges régió egy fizikai helyére. Ezután aszinkron módon másolja az adatokat egyetlen fizikai helyre egy másodlagos régióban, amely több száz kilométerre van az elsődleges régiótól. 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.

Csak a standard általános célú v2-tárfiókok támogatják a GZRS-t.

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.

Pillanatkép és szinkronizálás gyakorisága

Annak érdekében, hogy a Geo- és GeoZone redundáns fájlmegosztások konzisztens állapotban legyenek feladatátvétel esetén, a rendszer pillanatképe 15 percenként jön létre az elsődleges régióban, és replikálódik a másodlagos régióba. 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 a másodlagos régióban a rendszer legújabb pillanatké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.

Feladatátvételi szempontok

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.

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.

Tartóssági és rendelkezésre állási paraméterek

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

Paraméter	LRS (tanulási rendszer)	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 egyetlen 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.

Tartósság és rendelkezésre állás kimaradás esetén

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 (tanulási rendszer)	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 to Azure account
Connect-AzAccount

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

# Get Token
$token = Get-AzAccessToken

# Invoke SRP list SKU API, and get the returned SKU list
$result = Invoke-RestMethod -Method Get -Uri "https://management.azure.com/subscriptions/$($subscriptionID)/providers/Microsoft.Storage/skus?api-version=2024-01-01" -Headers @{"Authorization" = "Bearer $($token.Token)"}

# Filter the SKU list to get the required information, customization required here to get the best result.
$filteredResult = $result | `
    Select-Object -ExpandProperty value | `
    Where-Object {
        $_.resourceType -eq "storageAccounts" -and
        # Filter based on your needs. FileStorage kind includes pv2, and pv1 file share, where StorageV2 kind include 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 we currently support the region (all small cases, 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 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=2024-01-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

Megosztás a következőn keresztül:

Lásd még