iSCSI Target spariti

[nushuth]

Sono semplicemente disperato.

Ho un NAS (synology 413J) che utilizzo come iSCSI datastore in VMWARE con DSM 5.2

succede che c'è stato un problma elettrico e dopo il riavvio i target iSCSI e le LUN sono coompletamente sparite, ma collegandomi in SSH vedo che i file delle LUN sono integri. semplicemente non riesco a rimetterli "online".

Andimo con ordine, vi spiego cosa succede.

Al riavvio, il NAS non partiva correttamente. Utilizzo synology assistant, e mi dice che è attivo, ma "configuration lost". eseguo il ripristino caricando l'ultima versione del DSM disponibile mentre scrivo (6.x) senza naturalmente formattare la data partition. tutto ok, il sistema riparte, e gli share di rete sono disponibili e contengono tutti i dati.

Le iSCSI LUN e gli iSCSI target invece, nemmeno l'ombra. nella gui non sono visibili, come se non esistessero.
mi collego in SSH, vado nella directory /volume1/\@iSCSITrg/ e vedo che le mie due LUN file.based sono li, integre, e con tutti i dati presenti.

Come posso "riagganciarle" e presentarle di nuovo al mio VMWare?

[burghy86]

apri un ticket con synology che si collega e ti rimette in piedi le lun

Inviato dal mio SM-G930F utilizzando Tapatalk

[nushuth]

Grazie per il consiglio e per la risposta!

in realtà avevo aperto il ticket in synology prima ancora di scrivere qui sul forum.

E' che purtroppo il supporto synology non è proprio un fulmine di guerra nel rispondere ai ticket... non sarebbe male se synology offrisse un supporto express a pagamento, ci sono situazioni, coom questa, in cui si paga volentieri...

Comunque credo di aver sviluppato una soluzione. Ha funzionato in un ambiente di test creato ad hoc, sto facendo un backup dei files con le LUN originali e poi provo ad applicare la solution nell'ambiente di pproduzione.

In pratica, comunque, ho creato una nuova LUN, della stessa identica dimensione rispetto a quella defunta. fermo il servizio iSCSI, e tramite SSH sostituisco i file della LUN nuova con quelli della LUN defunta. dopo il riavvio dei servizi (o del sistema) i dati *dovrebbero essere* di nuovo accessibili.

Aggiorno non appena testo la soluzione....

[nushuth]

UPDATE:

funziona!! sono riuscito a ripristinare la LUN fcendo quanto indicato sopra.
se pensi che possa essere utile, posso scrivere istruzioni dettagliate... anche se sono sempre un'arma a doppio taglio.

[burghy86]

Sicuramente è una cosa da scrivere. Anche per i posteri

Inviato dal mio SM-G800F utilizzando Tapatalk

[nushuth]

DISCLAIMER:

La soluzione che segue, non è in alcun modo da considerarsi una “official solution” e non gode di alcun supporto da parte di synology, che invece offre un ottimo servizio di assistenza remota, che però comporta qualche giorno di downtime.
Si presuppone sempre che tu stia adottando tutte le “best practices” per salvaguardare i tuoi dati, che comprendono (ma non sono limitate a) le tre regole base dell’informatica:

• 1) Fare i backup
  2) Fare i backup
  3) Hai fatto i backup?

Dunque si presume che esista un backup dei dati ma, dal momento che un restore richiederebbe molte ore, si voglia tentare una soluzione che permetta il ripristinare LUN e relativi datastore in pochi minuti, ben consapevoli che in caso di fallimento esiste sempre il backup da cui fare il ripristino.
Per queste ragioni, non mi assumo nessuna responsabilità circa l’integrità dei tuoi dati cosi come non posso essere ritenuto respnsabile di guasti al tuo hardware, ne posso offrirti garanzie che questa procedura funzioni.
TU sei l’unico responsabile dei tuoi dati e delle tue decisioni. Se questi dati sono di importanza VITALE, attendi l’intervento di un tecnico specializzato synology.


PREREQUISITI:

E’ richiesta una buona conoscenza con il sistema operativo DSM di synology, e una certa dimestichezza con le sue funzioni e la sua GUI.
E’ necessario anche saper padroneggiare una shell linux, essere in grado di navigare le directory, copiare e spostare file da riga di comando.
Sicuramente è superfluo, ma è necessario anche conoscere i termini utilizzati in questa guida (come iSCSI LUN, Target, UUID; immagino che non saresti qui a leggere se non sapessi di cosa si sta parlando.
Alcuni passaggi non verranno descritti nel dettaglio. Proprio perché si danno per assunte determinate conoscenze, “spostare il file X nella directory Y” deve fare gia parte del tuo bagaglio di conoscenze, per questo non troverai il comando da copia-incollare. E’ una precisa scelta che ha lo scopo di proteggere i tuoi dati da eventuali danni accidentali che potresti causare se non sei sufficientemente esperto. Se non sei in grado di eseguire una operazione come questa, attendi il supporto synology, o rischi di perdere tutti i tuoi dati.

Ora che ti ho terrorizzato a sufficienza, possiamo procedere cn l descrizione dello scenario


SCENARIO:

A seguito del verificarsi di una qualche particolare condizione (vedremo poi cosa è successo nel nostro “case study”) , il NAS ha perso totalmente la configurazione del sistema, ma non i dati contenuti nei volumi di archiviazione. In questa situazione il NAS è in grado di ripristinare una parte della configurazione ma non tutto. Ad esempio, tutti gli share di rete disponibili vengono ripristinati con tutti i dati all’interno. Sono invece completamente persi gli utenti, i gruppi, le permission, le APP e relative configurazioni. In questa situazione vengono anche perse tutte le informazioni relative alle LUN iSCSI e relativi target. I dati contenuti invece sono conservati in file all’interno del volume. Sono ancora li, semplicemente non sono piu disponibili.


CASE STUDY

Nel caso che ho preso in esame, la configurazione era la seguente:
NAS Synolgy DS413J (4 bay);
3x WD-RED da 3TB ciascuno;
DSM 5.2;
1 volume di archiviazione SHR occupante tutto lo spazio disponibile;
1 bay vuoto che a brevissimo avrebbe dovuto ospitare uno spare disk;
Network: IP Statico (IP facente parte della lista di esclusione sul DHCP server);
DHCP server è esterno, un domain controller windows server 2008R2;


Succede che dopo una interruzione di energia durata diverse ore al ripristino il NAS era in errore e non rispondeva al consueto indirizzo IP.
Viene rilevato tramite synology assistant, possiede un indirizzo IP ottenuto tramite DHCP, risulta DSM 5.2 installato ma lo sato viene indicato con “configuration lost”.
Collegandomi via web all’IP indicato dall’assistant, invece della pagina di login presenta la pagina di installazione DSM, la stessa di quando si installa per la prima volta, con dischi vuoti.
Seguendo alcuni tutorial synology, ho scaricato e installato l’ultima versione di DSM (6.1.3). In questa particolare situazione, dove i dischi non sono vuoti, l’installazione del DSM non procede con la formattazione della data partition, ma si comorta similmente a un upgrade, in modo da preservare i dati (a meno che non siano andati persi per altre cause).
Dopo il primo riavvio, scopro che un disco nello è stato “failure” e dunque il volume in stato “degraded”. Non si comprende come questo abbia causato la perdita della configurazione. Sostituito il disco guasto con uno nuovo, lasciato ricostruire il volume, al termine mi riitrovo nella situazione descritta in “scenario”.


ANALISI

Le unità iSCSI LUN vengono conservate sul synology sotto forma di file, di numero e di dimensioni piu o meno grandi a seconda non solo della dimensione totale della LUN, ma anche dei successivi "incrementi” di dimensioni effettuati in tempi successivi alla prima creazione della LUN (vedi piu avanti, "LUN COMPOSTA DA PIU FILE" per maggiori dettagli). Quindi è fondamentale come prima cosa scoprire dove è archiviata la nostra LUN orfana. Per fare questo collegati al synology mediante SSH, dopo aver abilitato il servizio, assicurati di lavorare come utente ROOT

DSM5.x
Su DSM 5.x le LUN vengono archiviate in

Codice: Seleziona tutto

/volumeX/\@iSCSITrg

Dove “volumeX” è il volume su cui hai scelto di archiviare la LUN in fase di creazione. Nel mio esempio ho un solo volume, di conseguenza sarà “volume1”. Dentro a questa directory trovi i file delle tue LUN, tutti insieme.

DSM 6.x
Su DSM6 non è possibile accedere direttamente come root e devi accedere come utente “admin”. Tuttavia questo utente non ha i diritti per navigare le directory che ci interessa, e devi naturalmente elevarti a privilegi di root. Ci sono diversi tutorial che spiegano come fare, io mi limito a usare “sudo bash”
Su DSM 6.x la struttura della directory è leggermente piu complessa. Vengono infatti archiviate in

Codice: Seleziona tutto

/volumeX/\@iSCSI/LUN/TIPO_LUN/$UUID/

Dove per “TIPO_LUN” si intende:
THIN: se l’allocazione dello spazio è di tipo THIN
FILE: se la dimensione dello spazio è di tipo PREALLOCATED

Mentre lo UUID è ‘identificatore univoco assegnato alla LUN “orfana” dal sistema precedente.
Quindi, per venire al caso pratico, nel mio DSM6 una LUN di tipo THIN è archiviata in

Codice: Seleziona tutto

/volume1/@iSCSI/LUN/THIN/c76dc71c-5502-4039-96d8-ec5102c1f141

Importante: è possibile che pur utilizzando DSM6.x, sul tuo dispositivo le LUN siano archiviate con il “metodo” DSM5. Questo perche hai creato le LUN quando usavi DSM5, e poi a forza di successivi aggiornamenti sei giunto ad aggiornare a DSM6. In questo caso le LUN rimangono nella directory “vecchia”.


SOLUZIONE:

Una volta identificata la cartella con la LUN, l’elenco dei file contenuti si presenta come questo:

Codice: Seleziona tutto

-rw-r--r-- 1 root root 1099511627776 Aug  3 07:23 OrphanedLUN_00000

Per semplificare la comprensione, al momento supponiamo ch la LUN sia composta da un solo file. Se la tua LUN è composta da piu file (hanno lo stesso nome ma il numero finale è progressivo) prosegui la lettura perché successivamente mi occuperò di questo caso, tutt’altro che particolare.
Io procedo con lo spostare tutti i file delle mie LUN da recuperare in una directory temporanea, ad esempio

Codice: Seleziona tutto

/volume1/OldLUN

In questo modo evito confusioni e riduco il rischio di fare dei danni. Approfittane anche per prendere nota anche della dimensione del file, in questo caso 1099511627776 BYTE. Usa poi un convertitore anche online per convertire in GB questo valore. Nel mio esempio, equivalgono esattamente a 1024GB.

Spostati nella GUI web di DSM, gestione archiviazione, iSCSI LUN. qui naturalmente è tutto vuoto, procedi con la creazione di una nuova LUN, di tipo THIN (indipendentemente da quale che fosse il tipo originale) che io in questa guida chiamo TestLUN. Le dimensioni devono corrispondere esattamente a quanto calcolato al punto precedente, quindi 1024GB. Procedi anche con la creazione di un target, che io ho chiamato (indovina un po?) TestTarget

1- iSCSI LUN.jpg (106.7 KiB) Visto 2788 volte

2- iSCSI TARGET.jpg (172.13 KiB) Visto 2788 volte

(i piu attenti, avranno notato che nella foto la LUN è di 1,95TB e non di 1TB soltanto. il motivo? ho eseguito lo screenshot al termine delle operazioni, con una LUN totale da 2000GB. piu avanti spiego perchè)

Adesso torna sulla shell SSH: devi trovare il percorso in cui DSM ha creato la nuova LUN “TestLUN”.
Il procedimento è identico a quanto gia visto per trovare quella “orfana”. In caso di DSM5 si troverà in/volume1/\@iSCSITrg mentre invece in caso di DSM6 si troverà in

Codice: Seleziona tutto

/volume1/\@iSCSI/LUN/THIN/

Attenzione perche in questo caso con tutta probabilità cambia lo UUID (rispetto allo UUID che aveva la LUN orfana) e dunque anche la sottocartella di archiviazione. Adesso che hai individuato la cartella, elencando i file contenuti dovresti trovarti questo file:

Codice: Seleziona tutto

-rw-r--r-- 1 root root 1099511627776 Aug  6 15:23 TestLUN_00000

Notare come le dimensioni dei due file (vecchio e nuovo) sono identiche.

IMPORTANTE!! Prima di procedere, devi disattivare il LUN target appena creato. Vai su Gestore archiviazione, iSCSI Target, e clicca su “Disattiva” fino a vederlo indicato come “Offline”

offline.jpg (130.44 KiB) Visto 2788 volte

Ci siamo quasi. Tornando sulla shell SSH, occorre spostare e rinominare
OrphanedLUN_00000 in TestLUN_00000 e spostarlo nella cartella relativa, quella dove DSM aveva creato TestLUN_00000.
Aspetta a riattivare il target, prima assicurati di riavviare la diskstation. Solo dopo il riavvio, puoi riattivare l’iSCSI Target che avevi disattivato. Mi raccomand questo passaggio: se non riavvii la diskstation, quando tenti di utilizzare la LUN viene presentata come unità RAW, vuota e da formattare. Devi riavviare la diskstation se vuoi accedere al contenuto vecchio.
Una volta riavviata la DS, e riattivato il target, aggancialo con il tuo client abituale (nel mio caso un VMWare ESXi) e ritroverai i tuoi volumi, con tutto il contenuto.



LUN COMPOSTE DA PIU FILE

Questo caso è tutt’altro che particolare. Infatti le iSCSI LUN hanno la particolarità di poter essere aumentate di dimensioni nel corso del tempo, con l’aumentare delle necessità. E’ dunque possibile che la situazione si presenti In questo modo:

Codice: Seleziona tutto

-rw-r--r-- 1 root root 1099511627776 Sep  8 17:20 OrphanedLUN_00000
-rw-r--r-- 1 root root 1047972020224 Dec  3 07:23 OrphanedLUN_00001

Si tratta di due file con nome sequenziale, di dimensioni che possono anche essere diverse. Dipende da quante volte nel corso del tempo hai aumentato la dimensione della LUN. Nell’esempio qui sopra, il giorno 8 settembre è stata creata la LUN da zero, di dimensioni come indicato (sappiamo che si tratta di 1GB). Il giorno 3 dicembre però, la dimensione è stata aumentata di 1047972020224 byte. Usando sempre il convertitore, corrispondono a 976GB.
Cosa è successo? Che il giorno 3 dicembre la dimensione della LUn è stata AUMENTATA di 976GB passando quindi da 1024 a 2000GB.

Cosa succede se io creo la LUN nuova (TestLUN) di 2000GB in un colpo solo? Che mi crea un singolo file da 2000GB. E allora, per risolvere il problema, ricreo la LUN di test rifacendo gli stessi passaggi effettuati.
Creo dapprima TestLUN di 1024GB (prendo le dimensioni dal file 00000) ppoi la aumento di 976GB (prendo le dimensioni dal file 00001 e proseguo fintanto che esistono file sequenziali.
Al termine, disattivo il target, sostituisco tutti i file, riavvio ed il gioco è fatto.


CONCLUSIONE

Quest’ultimo esempio è esattamente quanto accaduto nel “case study” su cui si basa questa guida. A parte i nomi dei file, che sono stati modificati per migliorare la comprensione, ne caso reale il NAS presentava DUE LUN, tutte e due frammentate esattamente come indicato sopra. Anche le dimensioni dei frammenti sono reali, dunque nel mio caso i file totali erano 4.