Attività


Disaster Recovery

pubblicato 5 mar 2014, 05:56 da Davide Zanfi


Cablatura Posteriore host esx nel DR


Dall'alto:

  • Infoblox (DNS, DHCP)
  • Nuovo Firewall juniper
  • Router fastweb
 

Switch HP procurve 8212 DR


dall'alto:

  • Controller Cisco WiFi
  • Firewall perimetrale e concentratore VPN sedi remote
  • Firewall Interno


Host esx e Centralino VOIP Cisco

Netapp Upgrade

pubblicato 5 mar 2014, 05:45 da Davide Zanfi   [ aggiornato in data 10 mar 2014, 03:06 ]


Inserimento dei 3 Cassetti nuovi nella sede DR


Il 3240 prima della rimozione, ma dopo aver spostato i cassetti per lasciare lo spazio


dopo l'inserimento del 6220, in vasso i 3 cassetti nuovi (1 SSD)



Migrazione Dominio ADMT e scenario VDI

pubblicato 25 feb 2014, 08:33 da Davide Zanfi   [ aggiornato in data 4 mar 2014, 03:24 ]

Nuovo Dominio

Attenendosi alle Istruzioni di Milano è stato creato per la sede di Baggiovara, l’infrastruttura di Dominio nuova, all’interno della nuova foresta.

A questo scopo si è costruito un network in classe c con servizi di DHCP e DNS configurato sulla coppia di apparati infoblox e routing sugli switch HP core, cambiando il suffisso DNS 

E’ stato quindi installato il Domain Controller, in base al criterio di denominazione , sono stati configurati i siti e servizi in Active Directory, ed associate le correte subnet ai siti.

Per risolvere i problemi di replica Active Directory si sono dovute escludere dalle ottimizzazioni degli apparati riverbed il traffico dalla nuova network al network di Milano dove era presente l’altro Domain Controller

Si sono quindi eseguiti test di join di vari client al dominio, creati account per i servizi e per gli utenti amministrativi

Netapp è stato configurato come file server per offrire performance tenG, replica sincrona tra siti (Metrocluster), Versione precedenti (orarie, giornaliere, settimanali), deduplica, caching (flexcache).

Creata la share redirect, per redirigere desktop e documenti degli utenti. Creata il DFS operations.ga.local\mo a cui è stata linkata la share redirect, di seguito le permission NTFS della cartella:

•             CREATOR OWNER - Full Control      (Apply onto: Subfolders and Files Only)

•             System - Full Control      (Apply onto: This Folder, Subfolders and Files)

•             Domain Admins - Full Control      (Apply onto: This Folder, Subfolders and Files)

•             Authenticated Users - Create Folder/Append Data      (Apply onto: This Folder Only)

•             Authenticated Users      - List Folder/Read Data      (Apply onto: This Folder Only)

•             Authenticated Users      - Read Attributes      (Apply onto: This Folder Only)

•             Authenticated Users      - Traverse Folder/Execute File      (Apply onto: This Folder Only)

Purtroppo i client XP non sono in grado di supportare il percorso DFS sui server 2012

Sono state create le relazione di trust con i domini vecchi, è stata abilita la SID history e disabilitato sid filtering.

Per la risoluzione dei nomi DNS nei domini vecchi è stata creata un policy (dnssuffix) che aggiunge come suffisso DNS i vecchi domini ai client del nuova OU di Modena

Leostream

Nell’attesa dell’implementazione di vmaware view, è stato aggiunto a leostream l’autenticazione ldap al dominio nuovo con l’utente nuovodominio\leostream, in testa a tutte le altre regole.

Con questo scenario è possibile sfruttare l’ambiente VDI (wyse, leostream), per la struttura del nuovo Dominio

Infoblox

LA struttura DNS è integrata in Active directory, ma il resolver DNS è l’apparato infoblox che contiene una copia secondaria della zona di dominio e della relativa subnet

Per le risoluzioni della foresta , infoblox è secondario della zona ospitata sul DC della foresta

Sono inoltre state create le zone forward geografiche: US, china…., brazil……, Australia…., ecc in quanto le query ricorsive non funzionavano dall’apparato infoblox, ma solo dal nostro DC 

 

 

Vmware view

Per la struttura Vmware View sono stati installati i seguenti server

Composer

Connection Server

Connection Server backup

thin client

t410 - T5565Z:

per togliere warning certificato sul thin client administrative mode poi edit connection

I Client dipendono da HP device Manager, da cui caricano tramite profile.xml gli aggiornamenti e le configurazioni, per l’upgrade firmware doppio click accensione con usb key (T410).

Posizionando in autoupdate/image il firmware è possibile aggiornare via rete il sistema operativo, se non è il file corretto si corrompe il thinclient………….

T310

Management da web console: no password, Controllare fuso orario, Language

Dal Client – impostazione utente – non verificare Certificati,

T510

Client windows

T5740

Tasto shift logoff, Administrator come user e password

Disable filter per cambiare configurazioni,

wyse

Le opzioni del wyse dipendono in prima istanza da opzioni dhcp

le configurazioni di infoblox globali leggono il vendor-id wyse-1000 ed assegnano il connection broker leostream come opzione dhcp

per passare a view è necessario configurare la option vdi broker in modo da sovrascrivere questa opzione

option 188 https://connectione server

impostando poi la option 162 a view, viene letto il file dhcpserver\view\wyse\wnos\wnos.ini

impostando la option 162 a test, viene aggiornato il wtos. A volte è necessario disabilitare il bootp per caricare le opzioni correttamente

Per la vlan specifiche sono state applicate queste option, ma non viene applicata ConnectionBroker se non forzandola come reservation


Per le configurazioni dei 10 terminali INCAS, non utilizziamo nessun connection Broker, ma le personalizzazioni fatte in ftp://dhscserver/incas/wyse/wnos/wnos.ini e ftp://dhcpserver/incas/wyse/wnos/inc per la login di ogni teminale

ADMT

Creato un server:

admt

netdom trust vecchiodominio  /domain:nuovodominio /enableSIDhistory:yes /usero:administrator /passwordo:password

creato nei vecchi domini local security group ADMT

aggiunto  domain admins del nuovo dominio

policy ADMT - restricted group - ADMT member of administrators linkata dove sono presenti PC da migrare

aggiunto nuovodominio\domain admins a builtin\administrator nei vecchi domini

Sono poi stati condotti vari test di migrazione su machine fisiche e virtuali alla ricerca del risultato che consentisse alla nuova login dell’utente di ritrovare identica configurazione desktop applicazioni.

Problemi riscontrati:

·         risoluzione del nomi dns prima e dopo la migrazione da parte del server ADMT

·         firewall windows o kaspersky che non consentono la migrazione

·         dipendenze patch in windows XP

Dopo la risoluzione di questi problemi tramite applicazione patch e policy nei domini di origine, si è passati alla migrazione degli utenti reali.

Le problematiche riscontrate sono state:

·         Autorizzazione driver stampanti

·         Credenziali ldap server uniflow

·         Redirect folder XP non funzionante con percorso DFS

·         Mappature unità

Sono state correte via policy le problematiche driver, aggiunte alla routine di migrazioni srv-uniflow, costruiti 2 gruppi diversi per utenti XP e 7 per i diversi percorsi del folder redirect.

Sono state create policy per collegamenti a preferiti al posto delle mappature per i client 7

Si è costruito un server di Stampa  per le stampanti di magazzino e policy per assegnazione

Un foglio di lavoro condiviso documenta le migrazione effettuate

 

Virtualizzazione Fondtech

pubblicato 25 feb 2014, 06:07 da Davide Zanfi

introduzione



Il progetto di virtualizzazione è stato discusso a tavolino durante un colloquio in cui si sono analizzati requisiti e fattibilità dell’operazione durante il weekend successivo.

Il Cliente aveva già ricevuto tutto l’hardware necessario e si è reso disponibile ad iniziare l’installazione per accorciare i tempi di migrazione necessari nel weekend.


hardware


2 Server Dell PowerEdge R710

2 Switch HP Procurve 2510 24 porte

1 SAN EqualLogic PS4100XV


Realizzazione


L’infrastruttura è stata installata nello spazio libero di un armadio rack

Per prima cosa si sono indirizzati gli switch con un indirizzamento compatibile con l’infrastruttura esistente, ma in modo isolato.

Le ultime porte 2 porte (23-24) sono state aggregate per raddoppiare la banda disponibile (2 gbit/s)

si è poi provveduto alla configurazione degli apparati in modo da isolare il traffico di Storage su una vlan dedicata (Storage) e alla creazione di altre 2 vlan: isolated per rete di testing per le VM e DMZ da utilizzare un server FTP da virtualizzare.

Ogni porta dello Switch è stata “etichettata” nel file di configurazione (interface 1   name "esx1nic1",interface 2   name "esx2nic1", interface 3   name "esx1nic3" interface 4   name "esx2nic3", interface 5   name "eqlgc-eth2down", interface 13   name "eqlgceth1up"

, interface 14   name "eqlgceth0down", interface 15   name "esx1nic5", interface 16   name "esx2nic5", interface 23   name "tr", interface 24   name "tr" ).

Le 6 schede di rete del server sono state divisi in 3 coppie e cablate su entrambi gli switch per ottenere la ridondanza a livello di scheda e di apparato. Le 3 coppie sono poi state configurate rispettivamente per il traffico di Console, Storage, VM.

L’installazione dei server ESX 5 è stata fatta facendo il boot da CD ed abilitando da BIOS il supporto per la virtualizzazione delle CPU.

Per il vcenter si è deciso di utilizzare la virtual appliance linux fornita da vmware.

I 2 host ESX sono poi stati aggiunti alla console di vcenter e configurati in cluster, impostati DNS, NTP

La configurazione della SAN Equallogic è stata fatta isolando il traffico ISCI dello storage sull’apposita Vlan secondo le indicazione del white paper “Configuring iSCSI Connectivity with VMware vSphere 5 and Dell EqualLogic PS Series Storage”.

Testato l’accesso ISCI allo storage condiviso la nuova infrastruttura è stata connessa a quella in produzione ed abbiamo iniziato le operazioni di migrazione avvalendovi di una workstation con installato il Vmware stand alone Converter.


1-4 of 4