A volte capita di dover tamponare situazioni impreviste o una pessima analisi e progettazione di un sistema con qualche pezza.

Prendiamo ad esempio una directory temporanea dove qualche servizio va a scrivere quantità industriali di file, il buon senso vorrebbe che questi file fossero scritti su un volume ad-hoc, in modo che non vadano ad saturare tutto lo storage disponibile su un volume condiviso creando problemi anche su altri servizi che nulla hanno a che fare con quei file.

Se vi trovate ad affrontare una di queste situazioni su un server linux le soluzioni sono molteplici, una di queste è la creazione di un filesystem virtuale dedicato.
Questa soluzione non è certo la più elegante (un logical volume  LVM è preferibile dal mio punto di vista) ma è quella che offre una flessibilità tale da essere implementabile pressochè in qualsiasi condizione, non necessità di nuovo storage, non richiede fermi, si implementa a caldo, non comporta operazioni invasive sui dispositivi esistenti.

Prima di tutto create un file che fungerà da device, per farlo utilizzate il comando touch

A questo punto utilizzate il comando dd per creare il dispositivo, per rimanere aderenti ai dispositivi utilizzati generalmente suggerisco di utilizzare una dimensione di blocchi pari a 4k (bs=4096), il numero di blocchi dipende dalla dimensione del dispositivo che volete configurare; nell’esempio tale dimensione è pari a 1GB (262144 blocchi * 4096 = 1073741824 byte, ovvero 1GB).

Create il filesystem con il consueto comando mkfs

Ora create una directory dove montare il nuovo filesystem e montatelo

Et voilà! Il filesystem virtuale è servito!

Esaurito lo storage su guest linux vmware?
Rimpiangete quel buon vecchio controller IBM ServeRAID con il quale bastava lanciare il comando hot_add per vedere spuntare nuove lun?

Anche con vmware  tutto questo è possibile e anzi molto semplice, dopo aver aggiunto il nuovo disco virtuale (o raw mapping a scelta) basta aprire il terminale e digitare:

echo "- - -" > /sys/class/scsi_host/host#/scan

Chiaramente host# dev’essere sostituito con il valore del vostro device.

Verificando i log del kernel è possibile vedere l’effetto del comando precedente, es:

Vendor: VMware Model: Virtual disk Rev: 1.0
 Type: Direct-Access ANSI SCSI revision: 02
SCSI device sdd: 104857600 512-byte hdwr sectors (53687 MB)
sdd: cache data unavailable
sdd: assuming drive cache: write through
SCSI device sdd: 104857600 512-byte hdwr sectors (53687 MB)
sdd: cache data unavailable
sdd: assuming drive cache: write through
 sdd: unknown partition table
Attached scsi disk sdd at scsi0, channel 0, id 3, lun 0

Per esigenze lavorative sono dovuto intervenire su un cluster vmware vsphere 4.1 mentre sul mio fido ThinkPad da battaglia era già installata la versione 2.5 del client vmware infrastructure (utilizzata in precedenza per accedere ad un cluster vmware esx 3.5).

Fiducioso nella bontà dei prodotti vmware mi connesso alla console web, scarico il setup del client vsphere e seguo fedelmente la procedura di installazione.

Fin quando mi sono dovuto connettere al cluster vsphere 4.1 tutto è filato liscio come l’olio, collegandomi invece al cluster esx 3.5 ho notato una spiacevole sorpresa, al posto della console ha fatto capolino sul mio display una triste e poco esplicativa schermata bianca :(

Cercando in rete ho trovato una soluzione al problema, che pare sia dovuto alle features di Data Execution Prevention (DEP) implementate in Windows 7.

La soluzione è alquanto semplice, settare le policy DEP di windows al valore “AlwaysOff”, per fare questo occorre:

• lanciare la console di windows in modalità amministrativa
  Start –> Tutti i programmi –>  Accessori –> click destro su “Prompt dei comandi” –> Esegui come amministratore
• da console di sistema lanciare il comando: bcdedit.exe /set nx AlwaysOff 
• disinstallare ogni client vmware
• riavviare Windows
• reinstallare i client vmware infrastructure e vsphere

Fatto questo le console sono tornate visibili per le virtual machines di entrambi i cluster.

Windows riesce sempre a sorprenderti, quando pensi di aver raggiunto una livello di esperienza professionale tale da poter dire con fare soddisfatto “ho visto sfighe che voi uomini non potete immaginare…”, ecco che in quel momento ti capita tra capo e collo un cluster Windows claudicante da riportare sulla retta via.

Personalmente non ho mai visto di buon occhio questa tecnologia, ho installato e configurato alcuni cluster active/passive su distribuzioni RedHat, ma su Windows mi ha sempre indispettito questo alone di mistero che si frappone tra utente e risorse del cluster, oppure il fatto che fosse necessario un dominio Active Directory per fare qualcosa che una banale RedHat fa con un file xml editabile con vi.

La situazione di partenza è la seguente:

• OS Windows Server 2003 Enterprise
• storage su SAN FC definito come risorsa di cluster
• server disconnesso dal dominio Active Directory con indirizzi e hostname differenti rispetto alla condizione di normale funzionamento del cluster

L’obbiettivo è riportare il server ad essere un sistema stand-alone con risorse indipendenti (in particolare lo storage) dal cluster Windows.

A tal proposito Microsoft viene in soccorso con il seguente articolo; se siete fortunati vi basterà lanciare il comando che segue ottenendo il risultato sperato:

C:\>cluster node /forcecleanup
Attemping to clean up node 'clustest01' ...
Clean up successfully completed.

Tornate dal vostro manager e bullatevi di fronte ai colleghi (che ovviamente ignoreranno ogni dettaglio riguardante il problema e vi guarderanno come il tipico nerd alieno :\ )

Se invece siete sfortunati come il sottoscritto e quando attraversate la strada anche i gatti neri “si toccano” invece otterrete:

C:\>cluster node /forcecleanup
Attemping to clean up node 'clustest01' ...

System error -2147352567 has occuerred (0x80020009).
Exception occurred.

A questo punto non fatevi prendere dal panico e verificate quanto segue:

• log del servizio di clustering nel percorso C:\WINDOWS\system32\LogFiles\Cluster
• aprite il registro di sistema lanciando il comando regedit e verificate che il valore della chiave di registro
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\Currentversion\Cluster Server\ClusterInstallationState sia settato a ‘2’
  Nel caso non lo fosse modificatela in modo che abbia quel valore, riavviate e riprovate a lanciare il comando di forcecleanup

Nel caso in cui la modifica della chiave di registro ClusterInstallationState non abbia sortito gli effetti sperati non vi resta che passare alla soluzione radicale…
NO FERMI! Lasciate stare il cd di installazione! Reinstallare il sistema operativo per un problema ad un servizio è da noob :)

Procedete in questo modo:

1. utilizzando regedit effettuate il backup delle chiavi di registro:
   – HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ClusNet
   – HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ClusSvc
   – HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ClusDisk\Parameters
   – HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ClusDisk\Enum
2. backup dei file/directory:
   – C:\WINDOWS\Cluster\MSCS\
   – C:\WINDOWS\Cluster\CLUSDB
3. utilizzando regedit cancellare le chiavi di registro indicate al punto 1 e i file/directory indicati al punto 2
4. modificate la chiave di registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\Currentversion\Cluster Server\ClusterInstallationState settando il valore a ‘1’
5. riavviate il sistema operativo
6. rilanciate il comando “cluster node /forcecleanup”, ora l’esecuzione dovrebbe essere andata a buon fine e le risorse di storage dovrebbero essere tornate accessibili come lun indipendenti.
7. YEPPA!

Come qualunque sistemista potrà confermarvi i log sono l’essenza stessa di questo lavoro.
Il log sono la fonte di conoscenza suprema, sono la chiave di volta del processo di problem solving, i log sono la luce in fondo al tunnel :)

Lotus Domino di default ha il brutto vizio di scrivere i log in un database (solitamente log.nsf) ruotando i log stessi in differenti documenti, un sistema che per certi versi può risultare comodo e funzionale, per altri una fonte inesauribile di mal di testa e maledizioni.
Esistono apposite opzioni per far loggare il servizio in append ad un file di testo su filesystem, nella vita però si sa che “la fortuna è cieca ma la sfiga vede anche i raggi gamma” (cit) e non sempre è possibile modificare la configurazione per abilitare queste features.

Per chi dovesse trovarsi in questa situazione segnalo un semplice agente Lotuscript in grado di esportare in un file di testo (c:\temp\out.txt) il body dei documenti selezionati da una vista del database log.nsf

Sub Initialize
    Dim session As NotesSession
    Dim db As NotesDatabase
    Dim dc As NotesDocumentCollection
    Dim doc As NotesDocument
    Dim stream As NotesStream

    Set session = New NotesSession
    Set db = session.CurrentDatabase
    Set dc = db.UnprocessedDocuments
    Set doc = dc.GetFirstDocument

    Set outStream = session.CreateStream
    If Not outStream.Open("c:\temp\out.txt", "binary") Then
        Messagebox outPath,, "Open failed"
        Exit Sub
    End If
    If outStream.Bytes <> 0 Then
        Messagebox outPath,, "File exists and has content"
        Exit Sub
    End If

    While Not(doc Is Nothing)
        Forall voce In doc.EventList
            Call outStream.WriteText(voce )
            Call outStream.WriteText(Chr(13) & Chr(10))
        End Forall

        Set doc = dc.GetNextDocument(doc)
    Wend
End Sub