VMAX, PowerMax: Niet-verstorende migratie voor het IBMi Host Platform

Omgeving voor support:
NDM voor IBMi is beschikbaar voor ondersteunde IBMi-hostsystemen die zijn aangesloten op VMAX- of PowerMax-arrays met release 5978.444.444 of hoger van het PowerMaxOS.

Dit is voor IBMi logische partities (LPAR's) die worden uitgevoerd op het IBM Power Server-platform Power6 of hoger en waarop het IBMi-besturingssysteem versie i6.1.1 of hoger wordt uitgevoerd. De algemene e-Lab-supportmatrix voor VMAX of PowerMax bevat informatie en een lijst van de ondersteunde Fibre Channel (FC) IBMi I/O-adapters (IOA's), ook wel Host Bus Adapters (HBA's) genoemd. NDM wordt ook ondersteund wanneer IBMi een client-LPAR is met toegewezen virtuele I/O-bronnen van een IBM Virtual I/O Server (VIOS). Met de functie IBM VIOS/VFC (NPIV) worden virtuele FC-adapters (vFC's) toegewezen aan de client-LPAR's voor verbinding met de storage-array met behulp van ondersteunde SAN-switches.

vFC's fungeren als een pass-through voor de connectiviteit van de hostschijf; Aan de hostzijde is dit volledig transparant en zijn alle ondersteunde functies van de storage-array ook beschikbaar in die gevirtualiseerde adapteropstelling.

Achtergrond- en high-level migratiescenario:
Symmetrix Remote Data Facility (SRDF) werd in het begin van de jaren negentig ontwikkeld als een noodherstel (DR)-replicatietechnologie voor de Dell Enterprise Storage-arrays. Het wordt ook al vele jaren gebruikt om op storage gebaseerde migraties van de ene array naar de andere uit te voeren. Dat wil zeggen, sluit de 'back-to-back' van de OUDE en NIEUWE array aan en kopieer de datavolumes bij het uitvoeren van een technologievernieuwing door een nieuwe storage-array te implementeren. Hoewel het SRDF-kopieerproces van de volumes of logische eenheden (LUN's) transparant is voor de aangesloten hostsystemen, was er traditioneel altijd een kort offline "cut-over"-venster nodig wanneer het kopieerproces werd voltooid vanuit de bronvolumes (R1's). De doelvolumes (R2's) werden ingeschakeld voor lezen/schrijven en de FC-verbindingen van de hostsystemen werden (via SAN-zonering en -maskering) naar de nieuwe array verwezen. 

SRDF/Metro werd geïntroduceerd met de VMAX All Flash storagereeks. SRDF/Metro biedt echte actieve/actieve hosttoegang tot de bron- (R1) en doel- (R2) volumes van beide arrays. SRDF/Metro werkt met ondersteunde hosts met meerdere paden voor schijftoegang. Dit omvat de native IBMi Dynamic Multi Path (DMP)-bescherming voor schijfpaden. IBMi DMP detecteert automatisch of er meerdere FC-paden naar hetzelfde schijfapparaat zijn. Het biedt ook een eenvoudig maar effectief round robin"-werklastverdelingsschema om de schijf-I/O-workload te verdelen over de beschikbare FC-adapterpaden. IBMi DMP biedt automatische pad-failover wanneer verbindingen dreigen te mislukken, door de schijf-I/O-bewerking om te leiden naar een van de resterende actieve paden. Wanneer defecte verbindingen worden hersteld, herstelt IBMi automatisch deze paden en begint het opnieuw met het verzenden van schijf-I/O naar deze paden.

NDM met METRO en precopy-optie is gebaseerd op de onderliggende SRDF/Metro-technologie om gelijktijdige toegang te bieden tot de oude en de nieuwe storageapparaten.

CREATE Phase:
Wanneer een SRDF/Metro-replicatieapparaatpaar (R1>R2) wordt gemaakt, wordt dezelfde R1-apparaatidentiteit gepresenteerd van het R2-apparaat in de doelarray. In wezen worden dezelfde schijfserienummer en apparaat-WWPN van beide apparaten weergegeven. In eerste instantie bevindt het nieuwe R2-apparaat zich in de status AA-NR/DEV-INACT (Active/active-Not Ready/Device Inactive). Zodra het R1>R2-apparaatpaar is gesynchroniseerd, kan het in een actieve/actieve status gaan door lees- en schrijftoegang tot het R2-volume in te schakelen.

READY_TARGET fase:
Wanneer het pad van de IBMi LPAR naar het R2-apparaat nu is ingeschakeld (SAN-zonering is al aanwezig en maskering voor de nieuwe array geactiveerd door de NDM readytgt-opdracht), detecteert de IBMi-host nieuwe FC-paden naar het bestaande schijfapparaat. In een IBMi NDM-scenario worden de actieve/actieve R1 + R2-apparaten weergegeven.

COMMIT-fase:
Door de toegang tot de R1-apparaten te verwijderen, verliest de IBMi-host nu de toegang tot de paden van de oude array, maar blijft deze draaien op de R2-apparaten met behulp van de paden naar de nieuwe array. Zodra dit is gedaan, kan de SAN-zonering naar de oude array worden verwijderd. Het hulpprogramma "reset multipath" op het IBMi-systeem moet worden uitgevoerd om te stoppen met het gebruik van de oude inactieve paden en ook eventuele foutmeldingen te stoppen die zijn gekoppeld aan deze nu "ontbrekende" paden. Er kan een Initial Program Load (IPL) oftewel opnieuw opstarten nodig zijn om de oude inactieve paden en de bijbehorende DMPxxx-schijfhardwarebronnen permanent te verwijderen uit de apparaatconfiguratiedatabase van de IBMi-hosts (IBMi storage management information repository), maar dit is geen verplichte IPL, het kan ook wachten tot de volgende geplande IPL. Voor het verwijderen van deze "verouderde" apparaten: STRSST>Start Service Tool>Hardware Service Manager>mislukt en niet-rapporterende hardware: selecteer alle oude schijfbronnen DMPxxx voor verwijdering met optie 4 en bevestig dat door op Enter te drukken.

Overwegingen bij het gebruik van Dell STM
STM, ook vaak genoemd als de 'storage copy services toolkit' voor IBMi-replicatiebeheer voor VMAX, PowerMax storage wordt uitgevoerd als een native softwaretoepassing op een of meer IBMi-hosts. Het kan externe replicatie beheren voor ondersteunde SRDF-configuraties en lokale replicatie voor SnapVX-snapshots op VMAX- en PowerMax-arrays. STM is er in twee smaken: Standard Features-editie en Extended Features-editie.

STM maakt gebruik van in-band communicatie naar de storage-array over de FC-paden, het maakt gebruik van kleine speciale apparaten, ook wel poortwachters genoemd voor zijn systeemaanroepen. De poortwachters voor IBMi zijn speciale kleine D910 GK-type apparaten die in de sectie niet-geconfigureerde schijfeenheden blijven. Deze poortwachters bieden geen ondersteuning voor meerdere poortpaden. Meerdere poortwachters met één pad worden doorgaans weergegeven op dezelfde redundante set paden die worden gebruikt voor de reguliere ASP1-schijven. Het wordt aanbevolen om minimaal vier poortwachters te gebruiken. Poortwachters maken geen deel uit van het NDM-migratieproces, vandaar dat na de migratie de toegang tot poortwachters van de oude array wordt verwijderd en nieuwe poortwachters van de nieuwe array worden gepresenteerd.

Standaard kenmerken:
Dit wordt gebruikt voor systemen die alleen een *SYSBAS-opslagconfiguratie gebruiken. *SYSBAS betekent het Systeem ASP1 + eventuele extra User-ASP's (ASP 2-32). STM is alleen geïnstalleerd op het bronknooppunt en regelt de replicatieparen voor alle schijven in *SYSBAS als één ondeelbare entiteit.  Wanneer er wijzigingen optreden in de onderliggende schijfconfiguratie; dat wil zeggen wijzigingen in het serienummer van de schijf die worden veroorzaakt door de NDM-bewerking "unspoofing", is het voldoende om de opdracht STM DISCOVER uit te voeren op de IBMi-bronhost. Voer de optie ONTDEKKEN uit wanneer de poortwachters van de nieuwe array worden weergegeven. Dit werkt de lokale symapi-database bij in het Integrated File System (IFS) op de host (location= /var/symapi/db). De STM-schermen geven nu ook de nieuwe serienummers van de schijf weer. In het geval dat er problemen worden waargenomen in de koppeling van het replicatieapparaat binnen STM, is het ook mogelijk om alleen de installatieoptie te gebruiken om te beginnen met een nieuwe configuratie-installatie. Dit heeft geen effect op de configuratie van de replicatiekoppeling die al is geconfigureerd op de VMAX-PowerMax storage-array. Voor een schone scratch-installatie/installatie, documenteert u eerst de bijbehorende PADEN en STAPPEN in de huidige configuratie (GO MAINCTL>1, IMAGES>selecteert optie 2, voor de SYSTEEM-image> maakt u een schermopname voor het PATHS-scherm volgens het onderstaande voorbeeld:

Sluit STM af, verwijder de map /var/symapi en de bijbehorende submappen. Verwijder de EMCCTL-bibliotheek. Voer STM uit en installeer het programma opnieuw. Voer CRTSYMAPI uit. GO MAINCTL, koppel dezelfde PADEN opnieuw als eerder zijn geconfigureerd. STM detecteert en toont nu de status van de actieve replicatiekoppeling van de VMAX-PowerMax storage-array. STM-activiteiten zijn nu klaar om te worden hervat.

Uitgebreide functies:
Deze tabel wordt gebruikt voor systemen die gebruikmaken van een IBMi PowerHA-clusteropstelling met een of meer "schakelbare" iASP (onafhankelijke ASP). In dit scenario wordt alleen de iASP gerepliceerd en kan deze iASP of replica's daarvan worden gepresenteerd aan de knooppunten binnen het PowerHA-cluster. Elk clusterknooppunt is al actief op zijn eigen *SYSBAS (ASP1). De iASP is geconfigureerd als een schakelbare bron binnen het domein van het gedeelde clusterapparaat. Er zijn meestal twee of vier knooppunten in het cluster; Dat is volgens het onderstaande voorbeelddiagram voor een cluster met 4 knooppunten met het productieknooppunt als bron en met een extern DR-doelknooppunt en een SnapVX back-upknooppunt aan beide zijden:

Er is geen IPL van geen enkel knooppunt vereist om de iASP of de replica's ervan te gebruiken. Wanneer de iASP-schijven worden gepresenteerd aan een knooppunt binnen het cluster, is de opdracht VARY ON vereist om de iASP beschikbaar te maken voor dat knooppunt. In een PowerHA-installatie wordt de STM-bronversie geïnstalleerd op het bronknooppunt (in de EMCCTL-bibliotheek). Op alle andere knooppunten (SRDF- of SnapVX-doelreplica's) is de doelversie geïnstalleerd (in EMCCTLC-bibliotheek). Omdat alle knooppunten actief zijn, zijn er afhankelijkheden en checks and balances ingebouwd in STM voor bepaalde bewerkingen in deze opstelling. Het verwijderen van schijftoegang voor een knooppunt is verboden als de iASP nog steeds in de VARY ON-status staat voor dat knooppunt. Voor de communicatie tussen knooppunten wordt een STM-servertaak uitgevoerd in het EMCCTL-subsysteem op alle knooppunten. Deze taak communiceert binnen de knooppunten op de IP-interfaces van het cluster. Typische STM-bewerkingen kunnen worden uitgevoerd vanaf elk knooppunt binnen het cluster. Hiervoor moet op elk knooppunt een set van dezelfde STM-schijf, adapters en padconfiguratiebestanden beschikbaar zijn. Tijdens de initiële installatie van STM voor PowerHA worden deze bestanden geconfigureerd met behulp van MAINCTL optie-16 van het bronknooppunt en dit geeft deze bestanden ook door aan de doelknooppunten, namelijk de IASPS-, ISRCIOA- en IMAGE-bestanden in de STM-installatiebibliotheken EMCCTL en EMCCTLC. Deze bestanden kunnen ook worden weergegeven, dat wil zeggen met DSPPFM EMCCTL/IMAGE. De bestanden bevatten informatie over schijven en schijfadapters die worden gebruikt voor de iASP-configuratie. Adapter-ID's en serienummers van schijven worden opgeslagen in deze bestanden en gebruikt in de STM-bewerkingen.

Beschouw nu eens wat de impact is van een wijziging van het serienummer van een schijf die optreedt wanneer de NDM-depoofingbewerking is uitgevoerd. De STM-configuratiebestanden bevatten nog steeds de serienummers van de oude schijf. De meeste STM-bewerkingen werken niet meer totdat deze configuratiebestanden zijn bijgewerkt. Het bijwerken en verspreiden van deze bestanden kan worden gedaan door hetzelfde proces te volgen als tijdens de eerste STM-installatie wanneer MAINCTL>Option-16 (iASP configureren) wordt uitgevoerd terwijl de iASP-schijven beschikbaar worden gesteld aan de doelknooppunten in de respectieve PATH-STEP. Zodra deze bestanden zijn bijgewerkt, werken STM iASP-bewerkingen weer zoals verwacht. Als er zich problemen voordoen, overweeg dan om alleen een scratch-installatie van STM opnieuw uit te voeren voor de bron- en doelknooppunten, inclusief de optie-16 om de iASP PATH's/STEP's te configureren en de STM-configuratiebestanden te maken of te verspreiden.

Geregistreerde gebruikers met een Dell Support account kunnen de SRDF/TimeFinder Manager voor IBM i bekijken voor meer relevante informatie over deze STM-edities.

Overwegingen voor de volgende IPL na het opnieuw instellen van de apparaatidentiteit, ook wel 'unspoof'-bewerking
genoemdDe NDM-unspoofbewerking verandert de serienummers van de schijf. Dit kan alleen worden gedaan als de IBMi LPAR niet beschikbaar is. Wanneer deze bewerking na de migratie wordt uitgevoerd in een gepland offline onderhoudsslot, zijn er enkele overwegingen. De activering van de IBMi LPAR wordt aangestuurd vanuit de IBM PowerServer Hardware Management Console (HMC), de HMC levert de Hypervisor-functie voor de IBM PowerVM-virtualisatie. Op deze HMC heeft elke LPAR ten minste één LPAR-profiel met details over de LPAR-configuratie, dat wil zeggen CPU/MEM, adapters, enzovoort. Wanneer de LPAR voor het eerst IPL-ed is (IPL = Initial Program Load = opstartvolgorde), worden de configuratiegegevens van het geselecteerde profiel gelezen. Een speciaal tabblad in het profiel heet 'Getagde I/O'.  De getagde I/O-instellingen bepalen waar de LPAR moet zoeken naar de Load Source (LS) (= bootdisk) tijdens een B-type IPL, en naar het "alternatieve herstartapparaat" tijdens een D-type IPL, dat wil zeggen DVD of tape. Als de LPAR voor de eerste keer met succes een IPL heeft uitgevoerd, hoeft deze het profiel niet opnieuw te lezen, omdat de laatste IPL-informatie op de hypervisor wordt opgeslagen. Bij de volgende IPL wordt de standaardinstelling "current configuration" gebruikt, tenzij het LPAR-profiel specifiek opnieuw wordt geselecteerd. Als er tussen de IPL's door specifieke wijzigingen zijn voor de LS-controller of voor de details van de LS-schijf, accepteert de LPAR de gewijzigde LS-schijf niet en mislukt de IPL. Dit gebeurt als: De LPAR wordt geactiveerd met de optie "current configuration" of als de Tagged I/O LS-adapter is ingesteld op "none". De wijziging van het serienummer van de LS-schijf is een zodanige wijziging dat de LPAR deze niet accepteert en waarbij een activering met het juiste geselecteerde profiel vereist is.

De onderstaande schermafbeelding toont de traditionele HMC LPAR-profielweergave met een geldige LS-adapter geselecteerd:

De onderstaande afbeelding toont dezelfde informatie in de moderne versieweergave van de HMC v10 met VIOS 3.x /4.x.

 

Andere nuttige informatie vindt u in de PowerMax en VMAX: Best practices en operationele handleiding

voor niet-verstorende en minimaal verstorende migratie======================================================================================PRAKTISCHE IBMi NDM-procedure

:

#NDM (Non Disruptive Migration) procedure for IBMi host environments.
#From VMAX>>>VMAX, VMAX>>>PMAX, PMAX>>>PMAX
#Written: Q4-2021
#Author: Wopke Hoekstra CSA IBMi Global Practice
#Version: 5
==========================================================================================

# Just for reference: PowerMax OS 5978 Levels:

Name        Release Level/Code  
Elm         5978.144.144
Elm SR      5978.221.221
Foxtail     5978.444.444
Foxtail SR  5978.479.479
Hickory     5978.669.669
Hickory SR  5978.711.711
==========================================================================================
#PREREQS:
# MINIMUM Microcode Requirements: Foxtail (NDM IBMi support and NDM METRO-Mode available)
# MINIMUM of 2 RF directors per array are required
# Central external UniSphere/SE (SymCLI) server required with access to the source and target arrays
# MINIMUM SE version of 9.1
====================================================================================================

#Actual Customer Environment where this procedure was used:
# "OLD" VMAX: SN# ckxxxxxxxxx/ckxxxxxxxxx / 5978.479.479
# "NEW" PMAX: SN# ckxxxxxxxxx/ckxxxxxxxxx / 5978.479.479 

============================================================================================================
#Suggested NDM procedure: METRO NDM with Pre-Copy
#Also refer to the DELL EMC PowerMax NDM Whitepaper: Paragraph 3.2.4 / page 120
============================================================================================================

#PROCEDURE: Metro-based NDM with precopy 
#NOTE: (NDM with precopy allows end users to copy application data from the source array to target array while the application is still running on the source array)

#SAN requirements:
#Existing Host FC IOA ports/WWPN's will be used to also zone to the new target array's FA-ports. NO NEED for additional host FC connections.
#NOTE: The NEW array needs to be connected to the same SAN Fabric's as the OLD array.
#For each zone; add the desired target-array's FA-port WWPN into the existing zone (already containing the host initiator WWPN and OLD array FA-port WWPN)
#Or alternatively create new zones with same initiators to the new target-array's FA-ports

#NOTE: For LPAR's using VIOS/VFC(NPIV) connections and when the environment is setup for Live Partition Mobility, the vFC's secondary WWPN will be included in the zoning/masking.
#The secondary WWPN's will not be active and are not in the source array's Login History Table. NDM does not accept inactive WWPN's to be in the IG of the source host, hence the NDM VALIDATE and CREATE commands will fail.
#WORKAROUND: Temporarily remove the secondary WWPN's from the source LPAR IG. After the migration, simply add these secondary WWPN's back into the new IG on the target array. 

#Setup-phase: 
#symdm –src_sid <SN of Source> -tgt_sid <SN of target> environment -setup
symdm -sid 008 -tgt_sid 661 environment setup
#NDM RDFGroup will be created.

Now modify the SAN zoning to include the target-array FA-ports.
#NOTE: No devices are presented from the target-array yet.
#NOTE: You can already check if the existing initiator-WWPN's are actively logging in to the new array
symaccess -sid 661 list logins -dirport 1d:4

#To check the environment at any time:
#symdm –src_sid <SN of Source> -tgt_sid <SN of target> environment -validate
symdm -src_sid 336 -tgt_sid 662 environment -validate
symdm -src_sid 008 -tgt_sid 661 environment -validate

Other commands to display further details:
symdm -sid 336 -environment list
symcfg -sid 336 list -rdfg all
symcfg -sid 008 list -rdfg all

#NOTE: Take a copy of the source-array's masking database before the activity:
symaccess -sid 336 list view -all -v -detail>masking336_24Nov2021.txt
symaccess -sid 008 list view -all -v -detail>masking008_24Nov2021.txt

#Create Phase (with precopy: (run validation prior to execution))
#This creates an SRDF/Metro session with NDM attributes and puts the SRDF/Metro pair into adaptive copy disk mode. 
#It starts syncing data from R1 to R2. 
#Bias is on the Metro-based NDM source.
#symdm create –src_sid <SN of Source> -tgt_sid <SN of target> -sg <SG to be Migrated> [-tgt_srp <target SRP>] [-tgt_pg <target PG>] -precopy 
#First validate:
symdm create -src_sid 008 -tgt_sid 661 -sg SG_IBMPROD1_1 -precopy -validate
#Then execute:
symdm create -src_sid 008 -tgt_sid 661 -sg SG_IBMPROD1_1 -precopy

#Check NDM status:
#symdm –sid xxx list (-v) (-detail)
#symdm –sid<SN of SRC or TGT> -sg <SG to be Migrated> list –v –pairs_info -detail (shows device pairing)
#symrdf list -sid xxx (-rdfg xxx) (-sg xxx)
#symstat –sid <SRC SN> –rdfg<RDFG of Migration> –type RDF –i xx
symdm -sid 008 list

#ReadyTGT Phase: 
#Moves RDF pair state from adaptive copy mode to Active/Active(in case of witness protection) or Active/Bias (without witness protection).
#Target devices are moved into a read/write mode, It puts the NDM pair in Active/Active or Active/Bias mode
#Masking view is created on the target array using the masking elements created during the create command.
#symdm –sid <SRC or TGT SN> -sg <SG to be Migrated> readytgt
symdm -sid 008 -sg SG_IBMPROD1_1 readytgt

#Check status:
#symdm –sid xxx list (-v) (-detail)
#symrdf list -sid xxx (-rdfg xxx) (-sg xxx)
symdm -sid 008 list

#On the IBMi LPAR, check for new detected FC paths (to the devices on new PowerMax)
#Logon to LPAR, go into System Service Tools: STRSST and go to "work with disks"> "disk configuration"> "9.Disk Paths"
#Let the system discover the paths, this may take a few minutes, just hit F5 to refresh the disk path status screen and verify all disks have the new paths added.

#Commit Phase (this is the actual cutover to the new array):
#symdm –sid <SRC or TGT SN> -sg <SG to be Migrated> commit
symdm -sid 008 -sg SG_IBMPROD1_1 commit

#The masking views will be removed on the old source array.
#On the IBMi LPAR, check for the old paths going into "failed" status (these failing paths are the paths to the old source array)
#Zoning cleanup: Remove the old array's FA-ports from the respective zones for this LPAR.
#Use SST procedure to run MULTIPATH RESETTER macro (this will prevent further error messages being sent to the QSYSOPR MSGQ until the system is IPL-ed)
#After next planned IPL, the path status will be correct again, with only the new active paths listed.

#ONLINE MIGRATION COMPLETED!
============================

#Remove NDM environment (ONLY after last migration is completed):
#symdm -sid xxx -environment -list
#symdm –src_sid <SN of Source> -tgt_sid <SN of target> environment -remove
symdm -sid 008 -tgt_sid 661 environment -remove
============================================================================================================

#Reset Device external Identity (un-Spoof) (Optional OFFLINE operation).
#Resetting the target's device external identity back to the original array-based identity of the NEW array (changes the IBMi disk serial number (= Vol.ID + Array-ID))
#THIS REQUIRES A SHUTDOWN OF THE IBMi LPAR!
#Can be done as planned activity when the IBMi LPAR is doing an offline activity, and will be re-IPL-ed... I.e. for full backup, scheduled IPL, etc.

#NOTE: When STM (SRDF/TimeFinder Manager for IBMi) is used on the migrated LPAR, it requires a reconfiguration or as a minimum a DISCOVER command action, due to the changing of the LPAR's disk serial numbers.
#Refer to KB article 193832 for more info and procedure.

Alleen niet-gemaskeerde apparaten kunnen worden ontmaskerd, dus neem eerst de details van de huidige maskeringsweergave op en sla deze op, verwijder vervolgens de MV, maak de kopie ongedaan en maak de MV opnieuw.

symaccess -sid xxx show view -name xxxxxxxx >masking_xxxxxxxx.txt
symaccess -sid xxx delete view -name xxxxxxxx 

Identiteitsgegevens van schijf weergeven:

symdev -sid xxx list -identity_set
symdev -sid xxx list -identity -sg <sg-name>

Voor één apparaat:

symdev -sid xxx reset -identity -dev xxx -nop

Voor verschillende apparaten:

symdev -sid xxx reset -identity -devs xxx:xxx -nop

symaccess -sid xxx create view -name xxxxxxxx -sg xxxxxxxx -pg xxxxxxxx -ig xxxxxxxx 
symdev -sid xxx list -identity -sg <sg-name>

Controleer aan de hand van de IBM HMC of in het LPAR profiel, op het tabblad "Tagged I/O" -, de LS-controller is ingesteld op de juiste FC-adapter.

Laat de instelling "Tagged I/O" LS-controller NIET leeg terwijl "none" is geselecteerd.

IPL met de optie B-Normal en selecteer het LPAR-profiel voor de IPL, laat deze NIET over aan de standaardoptie 'huidige configuratie'.

IPL nu de LPAR en nadat het systeem weer online is, controleert u de serienummers van de schijf van SST.

De seriële ID's moeten nu de nieuwe arrays, symdev-ID en array-serienummer weerspiegelen.

=== End of Procedure ===