Autore: Domenico Caldarelli
L’informatica è fatta di standard, soprattutto il networking. Siamo abituati a lavorare utilizzandoli nel modo più redditizio possibile pur di raggiungere i nostri scopi ma, in alcuni casi, questi standard potrebbero non funzionare. Ad esempio: dopo aver creato una virtual machine, su Azure, è obbligatorio utilizzare la configurazione delle schede di rete impostata su DHCP. Se si configura un IP statico non sarà più possibile raggiungere il server.
L’unico modo per recuperare il server è il seguente:
- Selezionare, dalla dashboard su Azure, la macchina in questione
- Selezionare, nella bottom bar, cancella
- Scegliere di conservare il disco della macchina
- Attendere qualche minuto che il disco venga inserito automaticamente nella lista dei VHD conservati
- Ricreare la macchina selezionando il VHD invece dei template degli OS messi a disposizione, con lo stesso nome, affinity group, ecc…
Al termine della nuova installazione, la macchina virtuale sarà nuovamente raggiungibile poiché le interfacce di rete saranno in DHCP.
Inoltre, per diverse motivazioni quali problemi hardware, di rete o semplice manutenzione, Azure potrebbe spostare l’ubicazione fisica della VM. Questa operazione non compromette le funzionalità del server e, se accade, potrebbe determinare la creazione di una nuova interfaccia di rete a discapito di quella precedentemente utilizzata. Questa operazione comporta la perdita di tutte le configurazioni fatte sulla specifica interfaccia.
Questo è un esempio di configurazione totalmente fuori standard: quanti di voi utilizzano server, in ambito enterprise, in DHCP? Eppure è possibile utilizzare Azure in modo che sia completamente affidabile.
Azure garantisce che ogni VM ottenga sempre lo stesso IP, grazie alle funzionalità di un proprio DHCP Server, purché la macchina non venga spenta e, quindi, deallocata. In fase di provisioning, ogni macchina riceverà un IP partendo dal .4.
Questo se utilizziamo la Dashboard, tuttavia è possibile, allo stesso tempo, fare in modo che il DHCP rilasci uno specifico DNS ed uno specifico IP e per fare ciò è necessario utilizzare PowerShell.
Per iniziare è necessario installare Windows Azure PowerShell. E’ possibile scaricarlo qui: http://go.microsoft.com/fwlink/p/?linkid=320376&clcid=0x409
Terminata l’installazione dobbiamo agganciare la nostra sottoscrizione.
Avviare PowerShell ISE e lanciare il seguente comando: Add-AzureAccount
Nella finestra che si aprirà digitare l’account utilizzato e confermare. Per controllare che l’operazione sia andata a buon fine, utilizzare il comando: Get-AzureSubscription
A questo punto dobbiamo effettuare due configurazioni: creare un Affinity Group ed una Network. Fare riferimento a questo link: http://www.azurecommunity.it/2013/11/19/creare-un-ambiente-iaas-in-windows-azure/
Dopo aver creato una Subnet ed un Affinity Group, lanciare il seguente comando (Inserire il nome della subscription ricavato dall’esecuzione del comando precedente): Set-AzureSubscription -SubscriptionName “<NOME_SUBSCRIPTION>” ` -CurrentStorageAccountName (Get-AzureStorageAccount).Label –PassThru
Adesso possiamo creare la prima macchina virtuale:
$DNS = New-AzureDns -Name “dns” -IPAddress “1.2.3.4”
New-AzureVMConfig -name ProvaPS_Lab -InstanceSize Small -ImageName a699494373c04fc0bc8f2bb1389d6106__Windows-Server-2012-Datacenter-201403.01-en.us-127GB.vhd | Add-AzureProvisioningConfig -Windows -AdminUserName <UTENTE> -Password <PASSWORD> -NoWinRMEndpoint -TimeZone “W. Europe Standard Time” | Set-AzureSubnet -SubnetNames “LocalLan” |Set-AzureStaticVNetIP -IPAddress “192.168.0.25” | New-AzureVM -DNSSettings $dns -ServiceName ProvaCloudService -AffinityGroup “MyCloudDomain” -Vnetname “AzureNetwork” –WaitForBoot
Con questo comando abbiamo creato un nuovo Cloud Service (in questo caso ProvaCloudService) e lo abbiamo agganciato all’affinity group creato in precedenza; inoltre, abbiamo specificato un DNS ed un IP in fase di creazione della macchina.
A differenza di quanto accadeva qualche tempo fa, anche nel caso in cui la macchina venga deallocata, l’associazione nome macchina/IP persiste, quindi la macchina avrà sempre lo stesso IP.
Con questo tipo di configurazione siamo in grado di prevenire che una qualsiasi attività svolta su Azure comprometta le funzionalità dei nostri ambienti poiché tutte le nostre VM otterranno, in DHCP, le configurazioni desiderate.