NoLabNoPartY.com » sql

Errore in vSphere 4.1 “Transaction log for database VIM_VCDB is full”

P@olo — Mon, 13 Sep 2010 06:25:28 +0000

Dopo aver avviato vSphere Client per la connessione a vCenter Server, compare un messaggio di Connection Error. Noto che questa non è la prima volta che capita dopo aver effettuato la migrazione a vSphere 4.1.

Il controllo quotidiano di vCenter Server fa parte delle attività di verifica per assicurare che la struttura virtuale sia perfettamente funzionante. Al presentarsi di un qualche problema può cambiare improvvisamente lo scenario del tipo di giornata che ci attende.

L’errore che si presenta è illustrato nella figura seguente.

A questo punto, dopo aver notato che il servizio VMware VirtualCenter Server non era avviato ho controllato i log di Windows per scoprire cosa fosse successo.

Il messaggio riportato indirizza immediatamente l’attenzione sul database MS-SQL. Ed è proprio qui che si deve operare per risolvere il problema.

1. PROCEDURA
Inanzitutto bisogna lanciare il Management Studio per accedere all’interfaccia di amministrazione di MS-SQL.

Per gestire la dimensione del Transaction Log in MS-SQL, bisogna agire sulla modalità di Recovery Model e sulla dimensione massima del Transaction Log nelle impostazioni del parametro di Autogrowth. Dal Management Studio fare click col tasto destro del mouse sul database VIM_VCDB e selezionare Properties.

Individuare l’opzione Recovery model e impostare il valore a Simple. Questo permette di poter effettuare lo shrink del Transaction Log.

Verificare la dimensione massima del file assegnata al parametro di Autogrowth. Per accedere a questo parametro, sempre dalla schermata Database Properties, selezionare la pagina Files e selezionare VIM_VCDB_log. Cliccare sul campo Autogrowth.

Se viene mantenuto come Recovery Model il valore Full può essere utile impostare il campo Restricted File Growth (MB) a 2048 per avere un certo margine.

A questo punto procedere con l’operazione di Shrink per liberare spazio nel Transaction Log file. Selezionare il DB, fare click col tasto destro e selezionare Tasks –> Shrink –> Files.

Come File Type selezionare Log e come Shrink action impostare l’opzione Release unused space. Click su OK. La dimensione del file di log viene così notevolmente rimpicciolita.

A questo punto avviando il servizio Windows VMware VirtualCenter Server è possibile collegarsi correttamente a vCenter tramite vSphere Client.

Ora che il file di log è di dimensioni accettabili, è possibile reimpostare il Model Recovery del database a Full per ripristinare la funzionalità del Transaction Log. VMware consiglia di lasciare il parametro Recovery Model settato a Simple per il database di vCenter server.

3. CAUSA
Analizzata la procedura per risolvere il problema, il motivo principale per cui si verifica la saturazione del file di log è dovuto alle impostazioni della raccolta delle statistiche da parte di vCenter.

Per accedere alla configurazione della raccolta statistiche, una volta connessi al vCenter Server cliccare su Administration –> vCenter Server Settings.

Cliccare su Statistics. Nella parte destra sono visualizzate le impostazioni. Il parametro che va verificato è Statistic Level che determina la quantità di informazioni raccolte.

Selezionando un valore nel campo Interval Duration e cliccando su Edit, si accede al livello di raccolta statistiche con valori che vanno da 1 a 4. Attenzione ad impostare il valore a 4 poichè imposta la raccolta delle statistiche a tutti i parametri disponibili a sistema con la conseguente ripercussione sul file di log.

4. CONCLUSIONE
Il Transaction Log del database VIM_VCDB è quindi influenzato da tre fattori principali:

MS-SQL Database – Recovery Model
Transaction Log – Restricted File Growth size
vCenter Server - Statistics Level

Agendo sulle impostazioni di queste tre opzioni, la dimensione del file di log è tenuta sotto controllo.

Hai già letto questi articoli?

Configurare WSUS in modalità NLB

P@olo — Mon, 01 Dec 2008 14:00:29 +0000

Con il periodo nero dell’economia mondiale, le aziende stanno facendo un massiccio “cost saving” per arginare i bilanci sempre più critici. Purtroppo il settore IT è quello che più ne fa le spese con pesanti tagli sul budget di investimento informatico.

Le nuove soluzioni da proporre al management per la gestione e implementazione dei sistemi IT sono per il momento da tenere nel cassetto in attesa di tempi migliori… che fare allora? E’ qui che sta anche la bravura dei sistemisti… trovare soluzioni funzionali risparmiando drasticamente sui costi.

Ed ecco che si riafferma, soprattutto per le PMI, una tecnologia per la gestione clients che, onestamente, ho sempre ritenuto efficace: WSUS. Tecnologia Microsoft, WSUS è una soluzione molto valida per la gestione dei sistemi di rete che permette di mantenere un parco macchine aggiornato limitando notevolmente i costi di implementazione e amministrazione poichè non prevede nessuna licenza di utilizzo.

1. DEFINIRE L’AMBIENTE OPERATIVO
Naturalmente per avere questo servizio con determinati standard funzionali, WSUS deve essere opportunatamente configurato in modo da garantire la continuità del servizio (cluster) e prestazioni di rete adeguate (Network Load Balancing) per meglio distribuire il carico del server destinato a svolgere questo ruolo. Per evitare confusione è bene specificare che WSUS in modalità cluster non ha molto senso… è ben più utile per SQL ed Exchange invece.

Prima di procedere con l’installazione di WSUS, bisogna definire l’ambiente operativo per rispettare i termini di continuità e di prestazioni del servizio. Per fare in modo che il servizio sia fault tolerant e per evitare l’overload del server, il database di WSUS (SUSDB) viene “appoggiato” ad un server SQL configurato in modalità cluster mentre WSUS viene installato su un server in modalità NLB. Oggi giorno quasi tutte le aziende sono dotate di uno storage SAN dedicato ai sistemi “core” come Exchange e SQL. Quindi una valida soluzione può essere l’utilizzo di un LUN dedicato del SAN per rendere accessibili in remoto gli aggiornamenti di WSUS.

2. REQUISITI
WSUS richiede per la sua installazione i seguenti requisiti:

IIS 6.0
Microsoft .NET Framework v2.0 Redistributable Package
Microsoft Report Viewer Redistributable 2005
WSUS SP1

3. CONFIGURARE SQL SERVER 2005 PER WSUS
Prima di procedere con l’installazione, è necessario configurare il cluster SQL in modo da operare correttamente con quanto richiesto da WSUS.

L’utente utilizzato per l’installazione di WSUS ha i diritti di amministratore sul Server SQL.
L’opzione Nested Triggers è attiva (default).
- Per verificare, aprire SQL Server Management Studio, fare click col tasto destro sul server nell’Object Explorer e selezionare Properties.
- In Advanced, impostare l’opzione Allow Triggers to Fire Others come True (default) o False.
Windows Authentication deve essere utilizzata in SQL. WSUS supporta solo questa modalità.
Il servizio Remote SQL Connections deve essere impostato come TCP/IP only.

Ricordarsi di specificare come Remote computer da configurare il nome del server virtuale SQL (sqlcluster nella figura) poichè è configurato come cluster.

L’account utilizzato per installare il database utilizzato da WSUS (SUSDB) in SQL deve essere presente in Security -> Login.

4. REGISTRAZIONE SPN
Un parametro fondamentale per il corretto funzionamento dell’accesso remoto al database SQL è la registrazione del service principal name (SPN) per questo server. Senza questa impostazione, si avranno problemi di autenticazione Kerberos e quindi WSUS non riuscirà a stabilire la connessione con il database e i clients non riusciranno a connettersi.

Per effettuare la registrazione di SPN è necessario il tool setSPN.exe che è presente nei Support Tools di Windows Server 2003. Procedere in questo modo:

Installare i Support Tools in un qualsiasi server di dominio e logarsi come Domain Admin.
Dal command prompt eseguire:
- setspn -A MSSQLSvc/
- es. setspn -A MSSQLSvc/sqlcluster sqlservice
Dal command prompt eseguire:
- setspn -A MSSQLSvc/: (port: normalmente è la 1433)
- es. setspn -A MSSQLSvc/sqlcluster:1433 sqlservice
Riavviare il server SQL dopo che la replica AD è stata effettuata.

Per verificare che SPN è stato correttamente registrato, dal command prompt eseguire:

setspn -L

E’ possibile verificare o editare questo parametro utilizzando ADSI Editor che è sempre presente nei Support Tools.

Per verificare che SQL stia effettivamente funzionando con l’autenticazione Kerberos, eseguire la seguente query nel server SQL:

select auth_scheme from sys.dm_exec_connections where session_id=@@spid

Il risultato deve riportare KERBEROS, come illustrato nella figura.

5. INSTALLAZIONE DI WSUS
Installare il primo WSUS server in modo da creare il database SUSDB nel server SQL. Dal command prompt eseguire il programma di installazione:

WsusSetup.exe SQLINSTANCE_NAME=server\instance

Se viene utilizzata l’istanza di default di SQL, specificare solo il nome del server. Per installare altri WSUS front-end servers, eseguire dal command prompt:

WsusSetup.exe /q FRONTEND_SETUP=1 SQLINSTANCE_NAME=server\instance CREATE_DATABASE=0 DEFAULT_WEBSITE=0

Viene installato solo il front-end di WSUS connesso al database SUSDB (precedentemente creato) nel cluster SQL con la porta web impostata su 8530. Una volta terminata l’installazione, l’applicazione richiede la definizione dei parametri operativi (proxy, prodotti, etc.).

Configurare l’area di sharing
Poichè più front-end devono accedere gli stessi contenuti, una buona soluzione può essere l’utilizzo di un LUN dedicato dello storage SAN per salvare i contenuti di WSUS. Naturalmente una qualsiasi area condivisa (Network Share, DFS) è adatta allo scopo.

Appoggiandosi ad un SAN, è necessario installare Microsoft iSCSI nei servers utilizzati per WSUS NLB per assegnare l’area condivisa definendo il disco dedicato (nella figura è indicato come W:\).

Spostare il contenuto di WSUS nell’area di share
Per spostare il contenuto delle directory di sistema di WSUS nell’area di share (SAN in questo caso), è necessario spostare il contenuto dalle directory locali tramite il comando:

cd \Program Files\Update Services\Tools\
wsusutil movecontent sharename logfilename (es. wsusutil movecontent W:\ movelogresult)

Il risultato, come illustrato nella figura, è la creazione delle directory con gli aggiornamenti di WSUS.

6. CONFIGURARE IIS PER I SERVER FRONT-END
Per accedere agli aggiornamenti nell’area condivisa, i server WSUS front-end devono avere IIS configurata opportunamente per permettere l’accesso remoto.

Tramite IIS Manager, impostare l’accesso all’area condivisa.

7. CONFIGURARE NLB
A questo punto è finalmente possibile configurare NLB. Poichè la documentazione in Internet su come implementare NLB è ampia e facilmente reperibile, non viene illustrata in questo articolo.

Terminata la procedura, effettuiamo un check per verificare che NLB sta funzionando. Dal command prompt eseguire il comando nlb query.

Verificati che gli host coinvolti in NLB hanno uno stato CONVERGED, il cluster NLB è operativo e funzionante.

8. CONFIGURARE WSUS CLIENTS
Poichè i clients sono generalmente configurati tramite GPO, il parametro utilizzato per identificare l’Intranet update service location deve essere l’indirizzo del Web virtuale (nlbcluster). nlbcluster è il DNS name del cluster NLB.

9. TESTARE WSUS
Naturalmente prima di mettere in produzione il servizio WSUS con questa configurazione, è opportuno testare il tutto con pochi clients o meglio in un ambiente di LAB per evitare spiacevoli sorprese e forti mal di testa.

Hai già letto questi articoli?

Windows SBS 2003: Allocated Memory Alert

P@olo — Sun, 05 Oct 2008 11:48:00 +0000

Da qualche giorno uno dei server Windows SBS 2003 notificava un “Critical Alert” inerente ad un uso eccessivo di memoria da parte di un qualche processo.

Naturalmente il metodo più immediato per cercare di capire quale sia la causa del problema è l’attenta analisi dei log.

L’alert riportava il seguente messaggio:

“A large amount of memory is committed to applications and processes. Consistently high memory usage can cause performance problems.
To determine which processes and applications are using the most memory, use Task Manager. Monitor the activity of these resources over a few days. If they continue to use a high level of memory and are less critical processes or services, try stopping and then restarting them.
You can disable this alert or change its threshold by using the Change Alert Notifications task in the Server Management Monitoring and Reporting taskpad.“

Analizzando il Task Manager, ho notato dei processi sqlservr.exe che hanno attirato la mia attenzione. Abilitando la visualizzazione del PID (non visibile da default), ho preso nota dei numeri associati a questi processi.

Per verificare quale istanza SQL fosse la causa dell’uso eccessivo di memoria, ho identificato tramite il comando tasklist /svc eseguito dal command prompt l’istanza associata ai PID precedentemente annotati.

In questo caso, il PID 1888 associato all’istanza MSSQL$SBSMONITORING è la causa che genera questo alert. Per ridefinire la quantità massima di memoria utilizzabile dall’istanza, dal command prompt ho eseguito questi comandi:

C:\> osql -E -S nomeserver\SBSMONITORING
1> sp_configure ‘show advanced options’,1
2> reconfigure with override
3> go
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Configuration option ‘show advanced options’ changed from 0 to 1. Run the RECONFIGURE statement to install.
1> sp_configure ‘max server memory’,100
2> reconfigure with override
3> go
Technorati Tags: allocation,memory,sbs,sql,windows
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Configuration option ‘max server memory (MB)’ changed from 2147483647 to 100. Run the RECONFIGURE statement to install.
1>

Una volta terminata la procedura, tramite il Task Manager ho verificato l’utilizzo di memoria del processo “incriminato” (PID 1888) e il valore si era ridotto alla soglia impostata.

Dopo questo intervento, l’alert non è più comparso.

Hai già letto questi articoli?

Rights Management Service: gestione del servizio

P@olo — Fri, 18 Jul 2008 10:52:48 +0000

Una volta implementato il servizio RMS, è fondamentale che tutte le componenti siano pienamente funzionanti per limitare al minimo il rischio di failure del sistema e quindi di accesso ai documenti protetti.

Il recupero dei documenti protetti infatti può rivelarsi impossibile dovuto ad una errata configurazione. Un’attenta pianificazione seguita da un’accurata fase di test è quindi fortemente consigliata.

1. CONFIGURAZIONE
Per un funzionamento ottimale di RMS, seguire alcune semplici regole può evitare dei forti mal di testa.

Il servizio RMS non dovrebbe risiedere su domain controller o Exchange server onde evitare il workload dei sistemi con conseguenti rallentamenti dei servizi svolti.
Nel DNS, è opportuno creare un CNAME alias dell’URL definito nell’SCP (Service Connection Point) anzichè il nome del server perchè nel caso di una sostituzione del server o cambio dell’IP del server stesso, il servizio continua a funzionare e non viene interrotto (in configurazione cluster). Si possono utilizzare più CNAME dello stesso url che puntano su diversi server.

Utilizzare un servizio web (IIS) dedicato solo per RMS.
I certificati per la protezione dei documenti vengono emessi basandosi sull’indirizzo e-mail dell’account. Verificare che ad ogni account venga attribuito un indirizzo e-mail.
Per generare il certificato è meglio utilizzare il nome del cluster.
E’ fortemente consigliato che il servizio RMS e il database SQL risiedano fisicamente su due server diversi. Un server SQL generalmente dovrebbe essere configurato in maniera da garantire tempi minimi di ripristino in caso di crash (cluster, backup). Da non dimenticare che tutte le info, certificati e configurazioni risiedono nel database SQL.
Per attivare SCP (registrare l’url in Active Directory) sono richiesti i diritti di Enterprise Admin. Se l’SCP è stato precedentemente registrato e devo re-installare da zero il servizio RMS, SCP va rimosso.

2. RIMUOVERE SCP
Per rimuovere l’SCP, si può procedere tramite la console grafica Windows RMS Administration.

Un altro metodo per effettuare l’operazione è tramite lo snap-in ADSIEDIT.MSC (si trova nei Support Tools in W2K3) connettendosi alla Configuration naming context. Aprire il nodo cn=Services e cancellare il nodo cn=RightManagementService che rimuoverà il Service Connection Point. Attenzione ad utilizzare questo tool.

Come alternativa è possibile utilizzare il DRM Toolkit lanciando il comando:

ADSCPRegister:ADSCPRegister unregisterscp https://my_domain/_wmcs/Certification

Il comando ADSCPRegister permette la registrazione dell’SCP in Active Directory. E’ utile nel caso non si abbiano sufficienti diritti in AD: mando l’istruzione all’Enterprise Admin per farla eseguire ed effettuare quindi la registrazione. Evito inoltre che altri accedano al server.

3. SOSTITUIRE IL SERVER RMS
Se ci troviamo nella situazione di dover sostituire un server impiegato per il servizio RMS (hardware obsoleto, upgrade, etc.), l’operazione è semplice in quanto è sufficiente installare un nuovo server nel cluster e rimuovere il vecchio.

Una volta configurato il nuovo server, questo deve essere aggiunto nel cluster.
Nel vecchio server da rimuovere deve essere fatta l’operazione di unprovisioning (riduzione del numero dei servers nel cluster) che ne azzera la configurazione.
Il CNAME precedentemente impostato nel DNS deve essere aggiornato per far puntare l’URL al nuovo server.
Aggiornare l’eventuale load balancing se impostato.

4. RIMUOVERE IL SERVIZIO RMS
Se spengo il server RMS, tutti i documenti protetti non sono più accessibili. Per la corretta rimozione del servizio RMS deve essere effettuata l’operazione di decommisioning per ripristinare l’accesso ai documenti. Tutti i servers coinvolti devono essere messi in questo stato.

Quando il server è in uno stato di decommissioning, solo le use licenses vengono fornite. Per rimuovere tutte le protezioni è quindi sufficiente aprire il documento protetto e poi salvarlo.

Questa procedura è utile nel caso il progetto pilota non venga approvato.

5. BACKUP E DISASTER RECOVERY
Tutte le informazioni, configurazioni e licenze (chiave pubblica e privata) di RMS risiedono nel database SQL, quindi il backup del database è fondamentale. SQL dovrebbe garantire un sistema di fault tolerance (cluster) per evitare blocchi del servizio e naturalmente una strategia di backup adeguata in base all’utilizzo del servizio.

Stesso discorso vale per il server RMS il quale deve essere adeguatamente protetto contro potenziali failures. Per questo scopo possono essere utilizzati sistemi di ripristino come Ghost, Symantec BackupExec o altri per effettuare un veloce ripristino del server.

L’utilizzo di una configurazione cluster (2 front-end) evita il blocco del servizio a patto che il database sia sempre accessibile e funzionante.

Hai già letto questi articoli?

Rights Management Service: introduzione

P@olo — Tue, 08 Jul 2008 10:26:11 +0000

L’aspetto della sicurezza dei dati aziendali è ormai recepito come un fattore vitale per il business svolto anche dalle persone predisposte ad autorizzare “spese informatiche” che spesso non hanno un bagaglio tecnico adeguato alle spalle. La sicurezza di una rete non deve essere curata solo ed unicamente per le intrusioni dall’esterno, ma la protezione dei documenti da chiunque non sia autorizzato all’uso è un aspetto generale.

Nel mercato sono presenti diverse tecnologie per la protezione dei documenti più o meno efficienti, più o meno complesse e più o meno costose. Cosa adottare per l’azienda dipende principalmente dalle esigenze specifiche e anche dalle risorse tecnico/finanziarie disponibili.

Già sul mercato da qualche hanno, Microsoft ha introdotto una soluzione per rafforzare la sicurezza della rete mirata alla protezione dei documenti tramite il servizio Rights Management Service (RMS). RMS introdotto per la versione Windows Server 2003, è una tecnologia per la protezione dei documenti ed e-mail con applicazioni abilitate al servizio RMS per favorire la salvaguardia delle informazioni digitali da un uso non autorizzato.

In Windows Server 2008, RMS è già incluso ed è stato rinominato in Active Directory Rights Management Services per riflettere un più alto livello di integrazione con Active Directory.

1. PERCHE’ RMS

Sistemi basati su ACL ed Encryption come EFS, ad esempio, non sono efficaci se il file viene spostato dalla partizione NTFS (copiato su un floppy, CD, USB pen).
Documenti protetti con password possono essere facilmente craccati.
Se assegno i diritti READ ONLY ad un documento, l’operazione di copia & incolla del contenuto in un altro documento non può essere bloccata.
Se il dispositivo che contiene i documenti viene perso o rubato, il contenuto può essere accessibile a chiunque.
RMS rende lo scambio della documentazione interna ad un’azienda più sicura.
RMS è FIPS compliant.
E’ un service che non necessita costi aggiuntivi per la licenza.

2. COSA FA RMS

Tutti i documenti ed e-mail che si appoggiano a RMS sono criptati.
La crittografia rimane allegata al file mentre sistemi come EFS proteggono i documenti solo se fisicamente salvati sulla partizione NTFS.
A differenza di EFS, RMS lavora anche con i gruppi AD per l’assegnazione dei diritti.
E’ possibile assegnare diverse tipologie di protezione a documenti ed e-mails: read only, modify, copy, print, forwarding, etc.

3. I LIMITI DI RMS

In termini di sicurezza, il solo RMS non garantisce il grado più alto di protezione rispetto alla tecnologia PKI, ma scoraggia e rende più complicati eventuali tentativi di intrusione.
Non protegge i documenti da foto, registrazioni vocali e screen capturing tools diversi da Microsoft.

4. I REQUISITI
Per il funzionamento di RMS server sono richiesti i seguenti componenti:

Windows Server 2003
Active Directory
SQL server 200x
ASP.Net
Message Queuing
IIS
RMS server SP2 (solo per la versione 2003, nella versione 2008 è già incluso)

Per il funzionamento di RMS client i requisiti sono i seguenti:

Office 2003, 2007 Professional – per pubblicare i documenti (publish)
Office 2003, 2007 Standard – per accedere documenti (consume)
RMS client SP2 (solo per Office 2003)
RMS add-on (solo per Internet Explorer 6.0) – permette di accedere ai documenti protetti senza avere Office installato.

La distribuzione dell’RMS client può essere effettuata tramite GPOs, SMS o manualmente.

5. LA TOPOLOGIA RMS
Il core system è composto da un server RMS (licensing server) che gestisce le licenze per effettuare il publishing e consuming (protezione e accesso) dei documenti e un server SQL che gestisce i tre database creati da RMS: Configuration, Directory Services e Logging.

La perdita del licensing server non compromette la funzionalità del servizio RMS mentre la perdita o danneggiamento del database RMS comporta un danno talvolta irreversibile nel recupero dei documenti. Per questo motivo è fortemente consigliabile tenere l’RMS e il database SQL su server diversi .

A seconda della struttura di rete, i licensing server possono essere distribuiti su varie locazioni nel caso di linee lente, un workload eccessivo, etc.

RMS è implementato a livello di forest nell’AD quindi tutti i domini membri possono beneficiare di questo servizio. Due forest possono utilizzare lo stesso servizio RMS stabilendo una trust relationship.

6. NOTE
RMS è molto funzionale, relativamente semplice da implementare e soprattutto è un servizio aggiuntivo che non comporta nessun costo in termini di licenze.

Per affermare un progetto di questo tipo presso un’azienda o al management dove implica un “piccolo” stravolgimento della rete presente non sempre è un’impresa semplice. La presentazione deve fare leva sugli aspetti chiave della sicurezza e deve essere supportata da una demo ben fatta in modo da mostrare l’utilizzo pratico e i benefici per l’azienda anche a chi tecnicamente non è ferrato. Far cambiare certe abitudini può a volte essere più complicato che implementare un sistema come RMS:-)…