Stationsfirmware bijwerken

Het bijwerken van de firmware voor schijven was altijd een omslachtige taak met de mogelijkheid van downtime. Daarom verbeteren we Opslagruimten, Windows Server en Windows 10, versie 1703 en hoger. Als u stations hebt die ondersteuning bieden voor het nieuwe firmware-updatemechanisme dat is opgenomen in Windows, kunt u de stationsfirmware van stations in productie bijwerken zonder uitvaltijd. Als u echter de firmware van een productiestation gaat bijwerken, lees dan onze tips over het minimaliseren van het risico tijdens het gebruik van deze krachtige nieuwe functionaliteit.

Warning

Firmware-updates zijn een potentieel riskante onderhoudsbewerking en u moet ze alleen toepassen na grondig testen van de nieuwe firmware-installatiekopie. Het is mogelijk dat nieuwe firmware op niet-ondersteunde hardware de betrouwbaarheid en stabiliteit negatief kan beïnvloeden of zelfs gegevensverlies kan veroorzaken. Beheerders moeten de releaseopmerkingen lezen waarmee een bepaalde update wordt geleverd om de impact en toepasselijkheid ervan te bepalen.

Stationscompatibiliteit

Als u Windows Server wilt gebruiken om stationsfirmware bij te werken, moet u ondersteunde stations hebben. Om veelvoorkomend apparaatgedrag te garanderen, hebben we nieuwe en - voor Windows 10- en Windows Server 2016 - optionele HLK-vereisten (Hardware Lab Kit) voor SAS-, SATA- en NVMe-apparaten gedefinieerd. Deze vereisten geven aan welke opdrachten een SATA-, SAS- of NVMe-apparaat moet ondersteunen om firmware te kunnen bijwerken met behulp van deze nieuwe, Windows-native PowerShell-opdrachten. Ter ondersteuning van deze vereisten is er een nieuwe HLK-test om te controleren of leveranciersproducten de juiste opdrachten ondersteunen en deze in toekomstige revisies implementeren.

Neem contact op met de leverancier van uw oplossing voor informatie over of uw hardware ondersteuning biedt voor Het bijwerken van de stationsfirmware door Windows. Hier volgen koppelingen naar de verschillende vereisten:

PowerShellcmdlets

De twee cmdlets die aan Windows zijn toegevoegd, zijn:

  • Get-StorageFirmwareInformation
  • Update-StorageFirmware

De eerste cmdlet biedt gedetailleerde informatie over de mogelijkheden van het apparaat, firmware-bestanden en revisies. In dit geval bevat de machine slechts één SATA SSD met 1 firmwaresleuf. Hier is een voorbeeld:

Get-PhysicalDisk | Get-StorageFirmwareInformation

SupportsUpdate        : True
NumberOfSlots         : 1
ActiveSlotNumber      : 0
SlotNumber            : {0}
IsSlotWritable        : {True}
FirmwareVersionInSlot : {J3E16101}

Houd er rekening mee dat SAS-apparaten altijd 'SupportsUpdate' rapporteren als 'True', omdat er geen manier is om expliciet een query uit te voeren op het apparaat voor ondersteuning van deze opdrachten.

Met de tweede cmdlet Update-StorageFirmware kunnen beheerders de stationsfirmware bijwerken met een installatiekopieënbestand als het station het nieuwe firmware-updatemechanisme ondersteunt. U moet dit installatiekopieënbestand rechtstreeks bij de OEM- of schijfleverancier verkrijgen.

Note

Voordat u een productiehardware bijwerkt, test u de installatiekopieën van de specifieke firmware op identieke hardware in een testomgeving.

De schijf laadt eerst het nieuwe firmware-image naar een intern tijdelijk opslaggebied. Terwijl dit gebeurt, gaat de I/O meestal door. De afbeelding wordt geactiveerd na het downloaden. Gedurende deze tijd kan de schijf niet reageren op I/O-opdrachten terwijl er een interne reset plaatsvindt. Dit betekent dat deze schijf tijdens de activering geen gegevens levert. Een toepassing die toegang tot gegevens op deze schijf wil hebben, moet wachten op een reactie totdat de firmwareactivering is voltooid. Hier volgt een voorbeeld van de cmdlet in actie:

$pd | Update-StorageFirmware -ImagePath C:\Firmware\J3E160@3.enc -SlotNumber 0
$pd | Get-StorageFirmwareInformation

SupportsUpdate        : True
NumberOfSlots         : 1
ActiveSlotNumber      : 0
SlotNumber            : {0}
IsSlotWritable        : {True}
FirmwareVersionInSlot : {J3E160@3}

Schijven voltooien doorgaans geen I/O-aanvragen wanneer ze een nieuwe firmware-afbeelding activeren. Hoe lang het duurt voordat een station wordt geactiveerd, is afhankelijk van het ontwerp en het type firmware dat u bijwerkt. Er zijn updatetijden waargenomen van minder dan 5 seconden tot meer dan 30 seconden.

Dit station heeft de firmware-update binnen ~5,8 seconden uitgevoerd, zoals hier wordt weergegeven:

Measure-Command {$pd | Update-StorageFirmware -ImagePath C:\\Firmware\\J3E16101.enc -SlotNumber 0}

 Days : 0
 Hours : 0
 Minutes : 0
 Seconds : 5
 Milliseconds : 791
 Ticks : 57913910
 TotalDays : 6.70299884259259E-05
 TotalHours : 0.00160871972222222
 TotalMinutes : 0.0965231833333333
 TotalSeconds : 5.791391
 TotalMilliseconds : 5791.391

Productieschijven bijwerken

Voordat u een server in productie plaatst, raden we u ten zeerste aan de firmware van uw stations bij te werken naar de firmware die wordt aanbevolen door de hardwareleverancier of OEM die uw oplossing heeft verkocht en ondersteunt (opslagbehuizingen, stations en servers).

Zodra een server in productie is, is het een goed idee om zo weinig wijzigingen aan te brengen in de server als praktisch. Het kan echter voorkomen dat de leverancier van uw oplossing u informeert over een cruciale firmware-update voor uw schijven. Als dit het geval is, zijn hier enkele goede praktijken om te volgen voordat u schijffirmware-updates toepast:

  1. Bekijk de opmerkingen bij de firmwarerelease en controleer of met de update problemen worden opgelost die van invloed kunnen zijn op uw omgeving en of de firmware geen bekende problemen bevat die u nadelig kunnen beïnvloeden.

  2. Installeer de firmware op een server in uw lab met identieke stations (inclusief de revisie van het station als er meerdere revisies van hetzelfde station zijn) en test het station onder belasting met de nieuwe firmware. Zie Prestaties van opslagruimten testen met synthetische workloads voor informatie over het uitvoeren van synthetische belastingstests.

Automatische firmware-updates met Opslagruimten Direct

Windows Server 2016 bevat een Health Service voor Storage Spaces Direct-implementaties (inclusief Microsoft Azure Stack-oplossingen). Het belangrijkste doel van de Health Service is om het bewaken en beheren van uw hardware-implementatie eenvoudiger te maken. Als onderdeel van zijn beheercapaciteiten heeft het de mogelijkheid om schijf-firmware over een heel cluster uit te rollen, zonder werkbelastingen offline te halen of downtime te veroorzaken. Deze mogelijkheid is op beleid gebaseerd, met het besturingselement in handen van de beheerder.

Het gebruik van Health Service voor het implementeren van firmware in een cluster is zeer eenvoudig en omvat de volgende stappen:

  • Bepaal welke HDD- en SSD-stations u verwacht deel uit te maken van uw Opslagruimten Direct-cluster en of de stations ondersteuning bieden voor Windows die firmware-updates uitvoeren
  • Deze stations weergeven in het XML-bestand Ondersteunde onderdelen
  • Identificeer de firmwareversies die u verwacht dat deze stations hebben in de XML van ondersteunde componenten, met inbegrip van de locatiepaden van de firmwarebestanden.
  • Het XML-bestand uploaden naar de clusterdatabase

Op dit moment controleert en parseert Health Service de XML en identificeert alle stations waarop de gewenste firmwareversie niet is geïmplementeerd. Vervolgens wordt de I/O omgeleid van de betrokken stations, knooppunt per knooppunt, en wordt de firmware op die stations bijgewerkt. Een Storage Spaces Direct-cluster bereikt veerkracht door gegevens te spreiden over meerdere serverknooppunten. Het is mogelijk dat de Health Service een volledig knooppunt met schijven kan isoleren voor updates. Zodra een knooppunt is bijgewerkt, wordt er een herstel gestart in Opslagruimten, waardoor alle kopieën van gegevens in het cluster weer gesynchroniseerd zijn met elkaar, voordat u verdergaat met het volgende knooppunt. Het wordt verwacht en normaal dat Opslagruimten overschakelen naar een 'gedegradeerde' bewerkingsmodus terwijl firmware wordt uitgerold.

Om een stabiele implementatie en voldoende validatietijd van een nieuw firmware-image te verzekeren, bestaat er een aanzienlijke vertraging tussen de updates van verschillende servers. De Health Service wacht standaard 7 dagen voordat de2e server wordt bijgewerkt. Elke volgende server (3rd,4e, ...) wordt bijgewerkt met een vertraging van 1 dag. Als een beheerder de firmware instabiel of anderszins ongewenst vindt, kan ze op elk gewenst moment stoppen met de implementatie door de health-service. Als de firmware eerder is gevalideerd en een snellere implementatie gewenst is, kunnen deze standaardwaarden van dagen tot uren of minuten worden gewijzigd.

Hier volgt een voorbeeld van de xml van ondersteunde onderdelen voor een algemeen Storage Spaces Direct-cluster:

 <Components>
     <Disks>
        <Disk>
            <Manufacturer>Contoso</Manufacturer>
            <Model>XYZ9000</Model>
            <AllowedFirmware>
              <Version>2.0</Version>
              <Version>2.1>/Version>
              <Version>2.2</Version>
            </AllowedFirmware>
            <TargetFirmware>
              <Version>2.2</Version>
              <BinaryPath>\\path\to\image.bin</BinaryPath>
            </TargetFirmware>
        </Disk>
        ...
        ...
    </Disks>
 </Components>

Als u de implementatie van de nieuwe firmware in dit Opslagruimten Direct-cluster wilt starten, uploadt u de .xml naar de clusterdatabase:

$SpacesDirect = Get-StorageSubSystem Clus*

$CurrentDoc = $SpacesDirect | Get-StorageHealthSetting -Name "System.Storage.SupportedComponents.Document"

$CurrentDoc.Value | Out-File <Path>

Bewerk het bestand in uw favoriete editor, zoals Visual Studio Code of Notepad, en sla het vervolgens op.

$NewDoc = Get-Content <Path> | Out-String

$SpacesDirect | Set-StorageHealthSetting -Name "System.Storage.SupportedComponents.Document" -Value $NewDoc

Veelgestelde vragen

Zie ook Problemen met firmware-updates van stations oplossen.

Werkt dit op elk opslagapparaat

Dit werkt op opslagapparaten die de juiste opdrachten in hun firmware implementeren. De Get-StorageFirmwareInformation-cmdlet geeft aan of de firmware van een station inderdaad de juiste opdrachten ondersteunt (voor SATA/NVMe) en de HLK-test stelt leveranciers en OEM's in staat dit gedrag te testen.

Nadat ik een SATA-station heb bijgewerkt, wordt gerapporteerd dat het updatemechanisme niet meer wordt ondersteund. Is er iets mis met de schijf

Nee, het station is prima, tenzij de nieuwe firmware geen updates meer toelaat. Je ervaart een bekend probleem waarbij een in de cache opgeslagen versie van de mogelijkheden van de schijf onjuist is. Als u 'Update-StorageProviderCache -DiscoveryLevel Volledig' uitvoert, worden de mogelijkheden van de schijf heropgesomd en wordt de gecachete kopie bijgewerkt. Als tijdelijke oplossing raden we u aan de bovenstaande opdracht eenmaal uit te voeren voordat u een firmware-update start of de implementatie op een Spaces Direct-cluster voltooit.

Kan ik firmware op mijn SAN bijwerken via dit mechanisme

Nee: SAN's hebben meestal hun eigen hulpprogramma's en interfaces voor dergelijke onderhoudsbewerkingen. Dit nieuwe mechanisme is bedoeld voor rechtstreeks gekoppelde opslag, zoals SATA-, SAS- of NVMe-apparaten.

Vanaf waar krijg ik de firmware-installatiekopieën?

U moet altijd firmware rechtstreeks bij uw OEM, oplossingsleverancier of schijfleverancier verkrijgen en deze niet van andere partijen downloaden. Windows biedt het mechanisme om de afbeelding naar de schijf te brengen, maar kan de integriteit ervan niet verifiëren.

Werkt dit op geclusterde schijven

De cmdlets kunnen ook hun functie uitvoeren op geclusterde stations, maar houd er rekening mee dat de Health Service-indeling de I/O-impact op actieve workloads beperkt. Als de cmdlets rechtstreeks op geclusterde stations worden gebruikt, kan I/O waarschijnlijk vastlopen. Over het algemeen is het een beste praktijk om firmware-updates voor schijven uit te voeren wanneer er geen of slechts een minimale werkbelasting op de onderliggende schijven is.

Wat gebeurt er wanneer ik firmware bijwerk in Opslagruimten

In Windows Server 2016 met de Health Service die is geïmplementeerd in Storage Spaces Direct, kunt u deze bewerking uitvoeren zonder dat uw workloads offline worden gehaald, mits de schijven ondersteuning bieden voor Windows Server om de firmware bij te werken.

Wat gebeurt er als de update mislukt

De update kan om verschillende redenen mislukken, sommige daarvan zijn: 1) De schijf biedt geen ondersteuning voor de juiste opdrachten om de firmware door Windows te laten bijwerken. In dit geval wordt de nieuwe firmware-image nooit geactiveerd en werkt de schijf verder met de oude image. 2) Het imagebestand kan niet worden gedownload naar of toegepast op dit station (versievergissing, beschadigd imagebestand, ...). In dit geval slaagt het station er niet in om de activeringsopdracht uit te voeren. Nogmaals, de oude firmware-installatiekopieën blijven werken.

Als de schijf helemaal niet reageert na een firmware-update, heeft u waarschijnlijk te maken met een bug in de firmware van de schijf zelf. Test alle firmware-updates in een testomgeving voordat u ze in productie plaatst. Het enige herstel kan mogelijk zijn om de schijf te vervangen.

Voor meer informatie, zie Problemen oplossen met stationsfirmware-updates.

Hoe stop ik een actieve firmware-implementatie?

Schakel de implementatie uit in PowerShell via:

Get-StorageSubSystem Cluster* | Set-StorageHealthSetting -Name "System.Storage.PhysicalDisk.AutoFirmwareUpdate.RollOut.Enabled" -Value false

Ik zie een foutbericht dat toegang is geweigerd of dat het pad niet is gevonden tijdens de implementatie. Hoe kan ik dit oplossen?

Zorg ervoor dat de firmware-installatiekopieën die u voor de update wilt gebruiken, toegankelijk zijn voor alle clusterknooppunten. De eenvoudigste manier om dit te controleren, is door deze op een gedeeld clustervolume te plaatsen.

  • Last updated on