|
DR Test con AWS – Parte III: Frontend applicativo |
|
Mercoledì 10 Marzo 2010 09:30 |
|
Collegarsi alla console di AWS per l’esecuzione dell’istanza Microsoft Windows Server 2003 ricordandosi di selezionare la regione europea.
- Configurare le regole per il firewall creando un nuovo gruppo di sicurezza (FRONTEND):
|
Application
|
Transport
|
Port
|
Source Network/CIDR
|
Note
|
|
RDP
|
TCP
|
3389
|
Domain client external IP/32
|
Remote Desktop – accessibile solo dal dominio cliente. La configurazione di VPC per il collegamento degli utenti da internet viene descritta a parte.
|
|
IPsec
|
Vari
|
Varie
|
Client firewall IP/32
|
Collegamento IPsec con il sito primario
|
- Attivare l’istanza e collegarvisi via Remote Desktop.
- Installare e configurare il collegamento VPN IPsec con il sito primario. Applicazione specifica del cliente in oggetto.
- Assegnare un nome al computer (es. FRONTEND01) e modificare la configurazione del servizio EC2Config in modo da essere certi che Ec2SetComputerName e Ec2InitializeDrives siano disabilitati.
- Configurare l’istanza con i ruoli server: Active Directory (aggiungere al dominio del sito primario come controller di dominio secondario), DNS (prerequisito di AD), Terminal Server (non è necessario installare licenze, in caso di disastro gli utenti potranno accedere per 90 giorni con licenze temporanee, eventuali licenze definitive dovranno essere installate entro tale limite). Considerare l’istanza EC2 come un sito remoto e configurarla secondo le indicazioni contenute in: Preparing an Existing Domain Controller for Shipping and Long-Term Disconnection. AD verrà sincronizzato ad ogni ripartenza dell’istanza. Se il periodo di inattività dell’istanza superasse il parametro “tombstone lifetime” (default 60 giorni) procedere come indicato in: Reconnecting a Domain Controller After a Long-Term Disconnection. Prima di ogni test attendere la sincronizzazione di AD. In caso di disastro ripristinare dal backup del “System State”. In ogni caso potranno essere utilizzati i profili utente del sito primario.
- Installare l’ultima versione degli applicativi. Eseguire l’operazione tramite script attivabile mediante un collegamento posizionato sul desktop dell’amministratore. Opzioni possibili:
- Installare da package di installazione (msi o simili). Operazione da ripetere dopo ogni aggiornamento applicativo.
- Restore da file di backup. Nel nostro caso si utilizza questa procedura visto che le applicazioni .Net in uso sul site primario sono installabili via copia di files.
Per queste prime soluzioni si possono far transitare gli aggiornamenti da un bucket S3 e non applicati all’istanza sino al successivo test od in caso di disastro o ad intervalli programmati.
- Implementare una qualsiasi tecnologia di sincronizzazione di cartelle tra computer remoti. Le mie preferenze vanno ai framework basati su rsync vista la possibilità di utilizzazione multipiattaforma. Se si implementano questi framework installare la componente server sull’istanza in fase di configurazione e lanciare la sincronizzazione ad intervalli regolari e comunque dopo ogni aggiornamento applicativo. La sincronizzazione ovviamente richiede che l’istanza sia attiva.
- Salvare l’immagine dell’istanza EC2 su S3. Come per il database server predisporre uno script per eseguire l’operazione dopo ogni sessione di patching/reinstallazione del sistema operativo e delle applicazioni.
L’AMI memorizzata su S3 è pronta e può essere attivata da console AWS; lo stato dell’applicazione è quello dell’ultimo backup ripristinato. E’ possibile ricreare un nuovo clone 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 10.9€.
- L’AMI archiviata con due copie storiche costa circa 1,5€/mese.
- Ogni test costa circa 9.5€. Il test include: attivazione dell’istanza per circa 10 ore, patching Windows 2003, restore dell’applicazione, aggiornamento AMI, restore dati, validazione dei dati e delle procedure.
|