Questa funzionalità è molto utile in quelle situazioni in cui il dominio di risorse (per usare un termine noto a chi viene da Windows NT 3.51 Advanced Server ) è un dominio di produzione in cui è meglio tenere alla larga gli utenti.

Ovviamente quest’ultima affermazione è in palese contrasto con la indispensabile riduzione di utenze e di dominii al fine di contenere il più possibile i costi di gestione.

La selective trust è una funzionalità che consente di scegliere esplicitamente, attraverso le funzioni di security avanzate in Active Directory quali utenti o gruppi del dominio Trusted hanno “Allow to authenticate” sul singolo server.

La cosa si complica un pochino quando il server su cui permettere l’accesso al security principal è un cluster Windows Server 2008.

Nell’ultima, robustissima, versione di Windows Server la casa di Redmond ha introdotto numerose modifiche sulla funzionalità Cluster di Failover astraendo tutta l’impostazione delle risorse in modo che sia possibile creare ruoli come File Server piuttosto che un Resource Group con dentro le risorse necessarie per fare file share.

Creando un File Server su un cluster di failover di Windows Server 2008 questo ha la buona educazione di registrarsi nei Computer in Active Directory il che implica il permesso di Allow to authenticate per le identità che si vuole autorizzare all’accesso sia sui server fisici (i nodi del cluster) che sul File Server virtuale.

Un piccolo prezzo da pagare rispetto alla comodità della Selective Trust sia per la gestione che per la sicurezza delle vostre risorse.

Ovviamente do per scontati due requisiti di base perché le istruzioni che sto per scrivere abbiano qualche valore aggiunto: dovete conoscere i rudimenti del cluster Microsoft e conoscere Oracle 10g ed in particolare quel diabolico cappello che fa girare il database server in modalità cluster su Windows senza usare il famoso, fortissimo e bellissimo ma costosissimo RAC (Real Application Cluster)

Se, come il sottoscritto, venite da anni (o decenni…) di conoscenza (anche molto di dettaglio) e lavoro sulle piattaforme Microsoft è giusto avvisarvi che l’installazione di Oracle 10g (ma anche l’11g è così) assomiglierà drammaticamente alla draconiana installazione che bisognava fare per far funzionare SQL Server 7 in cluster.

Innanzitutto è necessario installare, a regola d’arte, il cluster di Windows Server 2003 seguendo la checklist presente già nell’help di Windows o le varie guide che Microsoft ha sul TechNet.

Se il vostro cluster group fa failover (e failback) correttamente tra i nodi, è raggiungibile tramite DNS senza problemi e la rete è configurata correttamente (occhio all’ordine delle schede di rete!) bhé, complimenti avete un cluster Windows Server x64!

Da questo momento in poi dimenticatevi dell’ìnstallazione cluster-aware di SQL Server 2005 (o già 2000) e iniziate il ping pong dell’installazioni su entrambi i nodi.

Infatti sul disco locale di ogni nodo del cluster andranno installati:

1. Oracle 10g v. 10.2.0.1 (per la x64 non sono riuscito a trovare una versione più recente anche se la 32bit mi risulta alla 10.2.0.4..)
2. Oracle Fail Safe 3.3.4
3. Oracle Enterprise Manager Agent (non vorrete mica amministrare il cluster da SQLPLUS…) ci vuole il Grid Control per andare con l’interfaccia grafica dell’ enterprise manager

L’installazione di Oracle 10g

L’installazione di 10g è piuttosto standard e simile a quella che fareste su un normale server stand-alone con l’accortenza di non lanciare la creazione di nessun db e, se avete già disponibili i dischi clusterizzati sul nodo, facendo attenzione a dove l’installer mette la oracle home. Almeno per quanto mi riguarda ha avuto un comportamento abbastanza bizzarro visto che, stranamente, voleva mettere la ORACLE_HOME su uno dei dischi shared del cluster…

L’installazione su entrambi i nodi deve essere speculare senza alcuna differnza sia nei percorsi che nei componenti installati. Insomma, a voler essere maligni, si tratta di fare gli stessi passi necessari anni fa per l’installazione di SQL Server 7 in cluster.

Alla fine dell’installazione è necessario controllare che i PATH della oracle_home siano correttamente aggiunti a quelli di sistema.

Non avendo creato nessun database l’installazione di Oracle non è particolarmente complessa e priva di qualunque sfida tecnica legata all’installazione clusterizzata tranne quella di inserire l’utente con cui gira il servizio cluster services nel gruppo locale di ogni nodo Ora_dba.

Se la versione che state installando non è già l’ultima disponibile oppure dovete applicare un patchset è questo il momento migliore per farlo.

Purtroppo una volta clusterizzate le istanze di Oracle non possono essere patchate senza de-clusterizzare (e non mi dite che non è robba da SQL Server 7.0…)

L’installazione di Oracle Fail Safe 3.3.4

In realtà OFS è l’unico software Cluster Aware ed è solo grazie a lui che, senza spendere la vagonata di soldi necessari per un RAC, riusciamo ad avere un minimo di alta disponibilità su Oracle.

L’installazione è abbastanza banale se il sistema su cui volete creare il cluster è un normale 32bit. Se invece avete intenzione di superare il limite di 4GB (si, è diventato un limite..) e volete usare sistema operativo e software a 64bit le cose si complicano un pochino.

Infatti è necessario installare il Fail Safe Manager  su una macchina a 32 bit ed installare invece OFS su entrambi i nodi del cluster Windows. Con questa azione si registra la resource DLL che si occupa di clusterizzare i database StandAlone che sono il punto di partenza per creare un’istanza clusterizzata di Oracle.

A questo punto parte quella che, secondo me, è l’installazione volutamente peggio realizzata di tutti i software su Cluster Microsoft che abbia visto in 12 anni di attività del mondo enterprise.

Non tanto per la procedura, che non è poi così’ male rispetto al panorama della clusterizzazione, ma per la totale assenza di pulizia architetturale che traspare da quello che sto per dirvi.

La creazione di una istanza clusterizzata si basa sull’utilizzo di un template di database appositamente aggiunto dall’installazione di OFS in DBCA ovvero Oracle Failsafe Sample Database, Oracle_Fail_Safe_Sample_102.dbc.

Tutto fila liscio se non volete aggiornare Oracle ad un patchset più recente….

.. nel caso, quasi inevitabile, di applicazione di una patchset, come ad esempio l’upgrade alla 10.2.0.4, l’accrocco si mostra in tutta la sua approssimazione e astrusità.

Infatti, per installare il patchset è necessario de-clusterizzare, e per patchare è necessario lanciare una procedura di aggiornamento del Database che, in alcuni casi, è preferibile non far passare i propri dati nel “tricarne” di una procedura simile.

Dunque scegliete di effettuare l’export del db e mettere i vostri dati da qualche parte anche per sfruttare l’occasione di ricompattare le tabelle.

Quello che vi rimane sono quindi due DB Oracle completamente vuoti su cui l’aggiornamento sarà una passeggiata.

Così’ è per la quanto riguarda l’applicazione del patchset, peccato che il database usato come template dal failsafe non viene aggiornato e la conseguenza di questo è l’impossibilità di procedere alla creazione di una nuova risorsa stand-alone da inserire successivamente in una istanza clusterizzata.

Il database Oracle Failsafe Sample Database, “Oracle_Fail_Safe_Sample_102.dbc” non viene aggiornato e per questo qualunque tentativo di utilizzarlo come base per un nuovo database failsafe.

Non trovando nulla sul Metalink e avendo un sistema di produzione down ho iniziato a cercare nei files una qualche indicazione che dicesse a dbca che quel db non era aggiornato.

In realtà cambiamndo alcuni file di configurazione dei template di creazione ed in particolare sostituendo

<initParam name="compatible" value="10.2.0.3.0"/>

<Location>C:\oracle\product\10.2.0\db_1\assistants\dbca\templates\Seed_Database.dfb</Location>

In modo da usare il Seed_Database.dfb (che è l’originale di Oracle_Fail_Safe_Sample_102.dfb).

Con questi piccoli trucchi il wizard crea il maledetto sample database con cui è possibile terminare la clusterizzazione di una istanza oracle senza ricorrere a script o procedure manuali da anni 70.

(sono quasi commosso visto che ho impiegato quasi 6 mesi per completare questo post… forse è uscito oracle 12 nel frattempo..)

Per Windows Server 2003 si utilizza una piccola utility (MMCV.exe) ed il terminal server.

Per quanto riguarda l’amministrazione di una istanza MSMQ Clusterizzata vi rimando alla KB 898701 in cui viene illustrato il funzionamento dell’utility all’interno di una configurazione clusterizzata.

I passi fondamentali sono:

1. Collegarsi via terminal server al network name dell’istanza clusterizzata di MSMQ
2. Dal commando prompt lanciare
   mmvc.exe –s <NetBiosNameIstanzaMSMQ>
3. Comparirà la classica finestra di computer management in cui espandendo i servizi troverete MSMQ in cluster

Non è proprio il massimo ma funziona.

Come da suggerimento ho effettuato il doveroso riallineamento a SP2 di SQL Server 2005 Enterprise Edition e immediatamente dopo ho applicato il Cumulative Update 7 di SQL Server.

Dopo questo tot di aggiornamenti la build di SQLServer dovrebbe essere la 3239.

Appena fatto sul primo cluster, però, tutte e 4 le istanze mostrano uno strano comportamento di SQL Server Agent.
Dopo alcuni restart la risorsa sul Cluster si mette in failed e scatta il panico.

A questo punto il dubbio mi assale: ho utilizzato la mia user.. vuoi che abbia fatto qualche casino con le permission durante gli aggiornamenti.

Infatti è buona norma, per essere sicuri che tutto si svolga al meglio, di utilizzare sempre la stessa identity con cui gira il servizio che si sta aggiornando. Almeno questa era la golden rule per Windows 2000 quando ho costruito la vecchia farm.

Dopo qualche ragionamento ho capito che non poteva essere così: finito il giro di Windows Update sui due nodi dell’altro Cluster, già SP2, ho installato la CU7. Stesso identico problema.

Attimi di panico, appena qualcuno, comunque presenti.

Poi inizio il classico metodo che i tempi moderni ci permettono:

1. Google (è il modo più efficace per cercare anche dentro la KB di Microsoft;
2. Direttamente la KB
3. Il sito premier (supporto gold di Microsoft)

Niente. Quando è così mi chiedo sempre se la domanda che ho fatto a Internet è quella giusta e, solitamente, ripensando e sistemando la query qualcosa viene sempre fuori.

Allora vado sull’Event Viewer è prendo il testo esatto della query:

“cannot start SQL Server Agent failover cluster”.

La risposta è l’articolo KB943525 che parla esattamente del problema che stavo vivendo. La certezza che si trattasse dello stesso caso è data dalla verifica sul file sqlagent.out che si trova nella cartella logfiles di ogni singola istanza creata sul server.

Questo quello che conteneva (tra le altre cose):

SQLServer Error: 22022, CryptUnprotectData() returned error -2146892987, ‘The requested operation cannot be completed. The computer must be trusted for delegation and the current user account must be configured to allow delegation.’ [SQLSTATE 42000]
ConnConnectAndSetCryptoForXpstar failed (0).

E’ un problema di sicurezza! (come la gran parte dei problemi in una complessa installazione di Windows fatta a regola d’arte…)

La soluzione è molto semplice nel mio caso: ho la necessità di utilizzare un account di dominio per SQL Server Agent.

In questo modo l’accesso alle risorse nel dominio di ogni cosa eseguita dall’agente di Sql Server può essere controllata ed identificata dalla sua user id.

Per fare questo l’identity del Sql Server Service deve essere Trusted for delegation selezionando l’apposito check nel tab account nel riguardo opzioni.

Senza effettuare nessun restart del servizio di SQL Server questa volta il Bring on-line della risorsa clusterizzata di SQL Server Agent service viene su che è una bellezza.

SQL Server non faceva fare il logon al servizio dell’Agent in quanto il suo account non era in grado di eseguire la sp_sqlagent_notify per un errore in una chiamata alle API della crittografia.

La delega di autenticazione è spiegata in questo link di Technet.

Tutto è bene quel che finisce bene. Inoltre ho imparato 3 cose:

• partire dalla ricerca dal testo dell’errore anche se generico
• SQLAgent ha un file che si chiama SQLAgent.out in cui scrive il suo bel log (fico!)
• la sicurezza di Windows è, e rimane, una cosa complessa ed assai poco sfruttata come funzionalità. Questa la rende la causa di molti comportamenti strani.