DR Test con AWS – Parte II: DB server Oracle
Martedì 09 Marzo 2010 09:25

Questa sezione dell’articolo deve essere considerata come una traccia per la creazione di una AMI Windows da usare per la fase di test di una procedura di Disaster Recovey di un Oracle Database Server inserito in una architettura multi-tier in ambiente Windows 2003.

Collegarsi alla console di AWS per l’esecuzione dell’istanza Microsoft Windows Server 2003 ricordandosi di selezionare la regione europea per evitare fastidiose penalizzazioni di prestazioni (vedi risultato grafico di un test da AWS a http://www.newits.it – sito Italiano).

Poiché lo storage locale all’istanza è volatile (in caso di ripartenza viene riallocato) è necessario allocare anche un volume EBS su cui creare la banca dati Oracle; la capacità del volume deve essere pari a quella del sito primario e quindi allochiamo 150GB. Usare sempre la console per allocare e collegare il volume all’istanza.

Configurare le regole per il firewall creando un nuovo gruppo di sicurezza (DATABASE):

Application

Transport

Port

Source Network/CIDR 

Note

RDP

TCP

3389

Domain client external IP/32

Remote desktop – accessibile solo da IP cliente

HTTPS

TCP

1150

Local Security Group (FRONTEND)

Oracle Database Console – accessibile solo da front-end.

Sql*Net

TCP

1521

Local Security Group (FRONTEND)

Oracle Sql*Net – accessibile solo da front-end.

 

Collegarsi all’istanza via “Remote Desktop”. Su AMI Windows, per minimizzare i tempi di startup che normalmente sono molto alti, assegnare un nome al computer (es. DBSERVER01) e modificare la configurazione del servizio EC2Config in modo da essere certi che Ec2SetComputerName e Ec2InitializeDrives siano disabilitati.

Formattare il volume EBS (via “Disk Management” assegnando possibilmente la stessa lettera/e di unità usata sul sito primario),  scaricare da Oracle Technet ed installare Oracle 10G (per i database server a base Linux esiste una AMI con Oracle pre-installato fornito direttamente da Oracle Corp. e scaricabile da Technet) come su un qualsiasi server Windows 2003 e ripristinare l’ultimo backup totale salvato su R3; ripristinare in sequenza tutti i backup incrementali successivi al “totale”.  Per il ripristino usare lo stesso strumento con cui si è eseguito il salvataggio; nel nostro caso viene usato uno script RMAN che ripristina in modalità non presidiata il backup totale e gli incrementali; ricordarsi si ripristinare la banca dati sul volume EBS. L’operazione di restore dura circa un’ora per una banca dati da 95GB.

In relazione al tema degli IP dinamici, per la configurazione di Oracle Listener  è utile seguire le indicazioni riportate in http://forums.oracle.com/forums/thread.jspa?threadID=719939&tstart=0. Visto che va a finire nel repository di Enteprise Manager, se si usa DB Console, è fondamentale mantenere fisso il nome del computer (Ec2SetComputerName disabled) come indicato in precedenza.

Il database server è pronto; l’immagine dell’istanza con Oracle pre-installato  va salvata per le partenze successive. Trattandosi di una immagine Windows è necessario valutare se salvarla su S3 oppure su un ulteriore volume EBS. Se l’istanza occupa più di 10GB è obbligatorio salvarla su EBS; in caso contrario entrambe le opzioni sono percorribili tenendo presente che le immagini partono molto più rapidamente da EBS (questione di secondi contro minuti) ma che sono più costose perché viene addebitato anche il carico di input-output sul volume. Le immagini basate su EBS hanno anche altri vantaggi e svantaggi ma non è questo il punto in cui discuterne. Nel nostro caso l’immagine occupa circa 6GB e quindi la strada S3 è percorribile.

Il salvataggio può essere fatto da console AWS oppure via linea di comando mediante gli “AWS EC2 tools” (comandi ec2-bundle-vol e ec2-upload-bundle); l’immagine salvata su S3 diventa l’AMI da utilizzare per le partenze successive. Visto che questo salvataggio deve essere ripetuto dopo ogni applicazione di patch al sistema operativo e ad Oracle allora ritorna estremamente utile la scrittura di uno script che esegua l’intera operazione di salvataggio; volendo tenere copia delle immagini precedenti è possibile mantenere uno storico delle immagini salvandole con nomi differenti che includono, ad esempio, data e ora. L’operazione non è necessaria per le immagini memorizzate su EBS perché sono sempre persistenti; tuttavia è necessario ricordarsi che è buona norma implementare una procedura di backup per i volumi EBS (es. via snapshot).

Prima di eseguire il salvataggio è necessario predisporre l’istanza per gli aggiornamenti successivi mediante la scrittura di un paio di script per:

1)      Montaggio automatico del volume EBS dei dati prima dell’attivazione dei servizi Oracle; mettere i servizi Oracle in modalità di startup “Manuale” ed attivarli dallo script di mount; collegare lo script di mount ad un servizio Windows in modalità di startup “Automatico”.

2)      Ripristino dei dati (banca dati compresa) dai backup su S3; attivare manualmente via collegamento sul desktop dell’amministratore.

L’AMI memorizzata su S3 è pronta e può essere attivata da console AWS; lo stato della banca dati è quello dell’ultimo backup ripristinato. E’ possibile ricreare un nuovo clone della banca dati collegandosi all’istanza via RDP ed usando il collegamento allo script di ripristino predisposto sul desktop dell’amministratore.

Costi AWS

  • Per l’installazione ed il primo test Amazon Web Services ci ha addebitato 21.48€.
  • Lo spazio disco del volume EBS dei dati costa circa 12.5€/mese in funzione del cambio Euro/Dollaro. Questo costo potrebbe essere eliminato ricreando il volume ad ogni test.
  • L’AMI archiviata con due copie storiche costa circa 1,5€/mese.
  • Ogni test costa circa 24,5€ comprensivi degli addebiti mensili per il volume EBS. Il test include: attivazione dell’istanza per circa 10 ore, patching Windows 2003 e Oracle, aggiornamento AMI, restore dati, validazione dei dati e delle procedure.

Costo delle licenze Oracle

La politica di gestione delle licenze del database Oracle non prevede esplicitamente una situazione di questo genere in cui il server di backup non fa parte di un cluster ed è attivo solo saltuariamente. Oracle prevede una situazione analoga per i sistemi appartenenti a configurazioni cosidette in Failover Cluster; le configurazioni in Standby Cluster basate su DataGuard seguono politiche diverse. I sistemi appartenenti ad un Failover Cluster che rimangono inattivi o spenti in attesa di una caduta del server primario non richiedono l'acquisto di ulteriori licenze di Database a condizione che l'istanza secondaria non venga accesa per più di 10 giorni l'anno. Ne consegue che se si eseguono meno di 10 test l'anno non servono ulteriori licenze Oracle anche in questo caso. Cfr: http://www.oraclelicensestore.com/images/documents/sig.pdf (Failover environments. In this type of environment, Oracle permits licensed Oracle customers to run some Technology Programs on an unlicensed spare computer for up to a total of ten separate days in any given calendar year). Verificare con il fornitore delle licenze Oracle.

 


Altri articoli: