Com crear una SAN iSCSI barata, barata

A vegades per fer proves va bé tenir una SAN disponible pel VMWARE. Així podem fer proves de balanceig, etc.

Podem crear aquesta SAN mitjançant eines gratuïtes (per a ús personal) com el StarWind, de la companyia RocketDivision.

El trobem a: http://www.rocketdivision.com/download_starwind.html 

Només cal instal·lar aquest servei en qualsevol PC amb prou disc per les nostres proves i assignar-li uns quants giges a la unitat iSCSI.

Aleshores després de configurar el VMkernel per l’iSCSI, al fer un Rescan de la IP del nostre PC apareixerà el volum de dades compartit.

Hi ha més eines, però aquesta l’he provat i va bé.

Està clar que el rendiment que obtindrem amb aquesta eina i un PC amb un disc IDE o SATA no és per despentinar-se, però es vàlid per un entorn de test.

Virtual CPU (vCPU) i SMP en VMWARE ESX

VMWARE ens permet assignar més d’una CPU virtual a les màquines virtuals. Aquesta asignació pot portar a equívocs, ja que el seu ús pot ser una mica enganyós.

Apareixen les següents qüestions:

• Al posar 1 CPU virtual en una màquina vol dir que el nostre sistema no aprofitarà les altres CPUs físiques?
• Si tenim una màquina crítica, aumentarà el rendiment si li posem 4 vCPUs?
• Podem passar d’1 a 2 o 4 CPUs en una màquina ja instal·lada?
• Ens quins casos cal posar més d’una CPU?

Intentaré respondré a aquestes qüestions i donaré les recomanacions al final de l’article.

Primer cal tenir en compte que els sistemes SMP (Simmetrical Multiprocessing) que disposen de més d’una CPU mai multipliquen el rendiment. M’explico. Un sistema de 2 CPUs mai rendirà exactament el doble que una de 1 CPU. Això és així perquè si tenim 2 CPUs cal tota una lògica de bloqueig entre CPUs per no solapar-se i no tenir una corrupció de dades. Com a exemple bàsic si tenim una suma i després una multiplicació amb el resultat, si fem les dues coses a la vegada en CPUs diferents, caldrà que la multiplicació esperi al resultat de la suma, perquè sinó la operació no té sentit.

Si tenim una màquina virtual amb una vCPU en un sistema de 8 CPUs, aquesta aprofitará tots els recursos de la màquina física. És a dir, si la màquina virtual va a tope amb la seva vCPU , fará servir més d’una CPU física de l’entorn virtual.

Per altra banda, si tenim un sistema amb 2 vCPUs i el software no ha estat dissenyat per utilitzar dues CPUs, estem malgastant els recursos de la máquina física al tenir reservades dues CPUs, ja que la segona CPU mai es farà servir.

Per tant, si tenim una màquina ofegada amb 1 vCPU, passar a 4 vCPUs no sempre ens millorarà el rendiment. Es possible fins i tot que afecti al rendiment de les altres màquines de l’entorn virtual.

 Així doncs a l’hora de assignar CPUs cal que tinguem en compte les recomanacions del fabricant del software que haguém instal·lat.

Està recomanat disposar de 2 CPUs en casos de Microsoft Exchange, de SQL Server, etc. També Citrix XenApp corre millor en màquines de 2 CPUs.

En canvi, XenApp no aprofita tant 4 CPUs com dos sistemes de 2 CPUs.

Per això cal consultar les documentacions dels fabricants o dels laboratoris de tercers on es mostra el rendiment obtingut amb configuracions de 1, 2 o 4 CPUs abans de decidir què posarem en el nostre escenari.

Com a norma, si la màquina no està molt carregada, o bé no tenim cap recomanació del fabricant, sempre es posa 1 vCPU. En casos de creixement o de aplicacions expressament recomanades, doncs posarem 2 o 4 vCPUs.

I responent a la pregunta, si disposem d’una màquina monoprocessador, podem passar a màquina multiprocessador sense masses problemes en el que respecta al sistema operatiu (sempre fent un snapshot per si les pantalles blaves). Una altra cosa es que l’aplicatiu s’hagi configurat per una CPU i presenti problemes d’inestabilitat si passem a dues. Potser en algún cas caldrà reinstal·lar l’aplicatiu.

Així, com a cas general, millor posar 1 vCPU. Si la màquina té molta càrrega, o el fabricant ho recomana de manera explícita, doncs posem 2 o 4. I si es pot fer un pilot amb una simulació, doncs sempre millor.

Com sempre adjunto link per poder contrastar el que posem aquí:

Best Practices using VMWARE Virtual SMP

http://www.vmware.com/pdf/vsmp_best_practices.pdf

VMWARE Converter 3.0.1 runtime error!

Sembla que el VMWARE Converter 3.0.1 encara té algun error per solucionar.

 Aquest concretament es soluciona així:

1. Crear una carpeta c:\TEMP 
2.  canviar la variable d’entorn TMP i TEMP a C:\TEMP (a Mi PC / avanzado / Variables de entorno)
3. Ja funciona!

Es una mica trist, però sembla que VMWARE Converter no suporta la ruta customitzada en castellà.

 El meu escenari era Windows 2000 SP4 Spanish contra Windows 2000 SP4 Spanish. També m’ha fallat en un Windows 2003 enterprise en castellà.

* Actualització: Sembla que la versió de les imatges realitzades amb el Symantec Ghost Backup Exec Recovery Edition 7 no són compatibles amb VMWare Converter.

Com habilitar el NTP al VMWARE ESX 3.x

A diferencia dels servidors 2.x, el servei ja ve configurat. Només cal activar-lo.

 Treiem el firewall pel servei NTP:

esxcfg-firewall –enableService ntpClient

Resetejem el servei:

service ntpd restart

L’habilitem per arrencar a l’inici:

chkconfig –level 345 ntpd on

Sincronitzem el rellotge hardware amb el servei NTP:

hwclock –systohc

Controlem que sincronitzi correctament amb un servidor NTP:

ntpdate -q

I ja està funcionant.

Blue Screen en VMWARE al actualitzar de NT 4.0 a Windows 2003

Al fer l’upgrade d’una màquina de VMWARE en NT 4.0 a Windows 2003 apareix una pantalla blava amb l’error stop ID 0×0000007B.

Això és degut al tipus de controlador SCSI que incorpora el sistema operatiu.

 Windows NT 4.0 (igual que Windows 2000 i XP) incorpora el driver de BUSLogic, mentre que Windows 2003 incorpora només el driver de LSILogic.

 Es per això que al crear una màquina per Windows NT 4.0/Windows 2000 o XP cal especificar que el driver SCSI és BUSLogic, i si la màquina és per Windows 2003, caldrà especificar que es LSILogic.

 El mateix assistent del VMWare ja incorpora aquests canvis, però si fem upgrade de la màquina a Windows 2003, el driver no està inclòs al sistema operatiu, i el Windows mostra l’error INACCESSIBLE_BOOT_DEVICE.

 Per seguir amb la instalació del Windows 2003 cal que retoquem l’arxiu .VMX i afegim aquesta línia:

scsi0.virtualDev = “lsilogic”

Amb això podrem continuar amb la instal·lació normalment.

Muntar un MSCS Cluster sobre VMWARE Server

Només cal disposar de dos nodes virtuals amb Windows 2003 Enterprise

Es crea un HDD d’1 Gb a l’SCSI1:1 i un HDD del que faci falta al SCSI2:1 des de la configuració del primer node.

Aleshores es va al segon node i s’afegeixen els mateixos discs al mateix bus SCSI.

Un cop creats, anem a l’arxiu de configuració .VMX i afegim la línia

disk.locking = “FALSE”

Alguns forums també comenten posar:

scsi1.shared = “TRUE”

Però això últim no se si es necessari en la versió server, sembla que només era per la antiga GSX.

Aleshores es creen dues tarjes de xarxa, i es segueix el procediment habitual per muntar un cluster MSCS

Instal·lació de Citrix Access Gateway 4.2.1 sobre VMWARE

Pas 1: REQUISITS

1: Baixar VMWARE Server Beta (cal el codi de producte)

http://www.vmware.com

2: Baixar CD de Citrix Access Gateway 4.2.1

http://www.mycitrix.com

3: Baixar el arxiu de llicència

http://ww.mycitrix.com

- Cal demanar un número de sèrie de Citrix Access Gateway.

- Posar aquest número al activador de llicències.

- Introduïr el nom extern del host (nom DNS en minúscules)

- Baixar arxiu .lic al PC client.

3: Aconseguir el redireccionador de PIPE

Named Pipe TCP Proxy:

http://shvechkov.tripod.com/nptp.html

4: Necessitem un PC amb dues tarjes de xarxa, una connectada a la LAN, i l’altra a la DMZ. Per evitar problemes de seguretat desconnectem el TCP/IP de la tarja DMZ.

Pas 2: INSTAL·LACIÓ

1: Crear màquina virtual de VMWARE server

- Tipus: Other

- Disc IDE recomanat 40.0 Gb (pot ser dinàmic)

- 2 tarjes Ethernet (Bridged contra la tarja física de la DMZ)

- 1 COM1 redireccionat a \\.\pipe\com1v

2: Modificar el arxiu .vmx

- Cal afegir

ethernet0.virtualDev = e1000

ethernet1.virtualDev = e1000

per convertir les tarjes Ethernet en una Intel E1000

2: Carregar ISO de CAG 4.2.1 al CD Virtual de la maquina virtual.

3: Arrencar el Named Pipes TCP Proxy. Definir el nom \\.\pipe\com1v. Definir el port 567

4: Fer un ‘telnet localhost 567′

5: Arrenquem la màquina virtual

6: Revisem la instal·lació. Apareix una barra d’estat del 0 ……. 100. Triga uns 20 minuts.

7: Desconnectem el CDROM virtual

8: Reiniciem el servidor

PAS 3: CONFIGURACIÓ

1: Arrenca la màquina virtual amb el CAG instal·lat.

2: A la finestra del Telnet, entrem com a root / rootadmin. (es probable que el Return no funcioni correctament. Cal fer Ctrl+return per validar i Ctrl+Backspace per borrar)

3: fem la opció 0 “express Setup” i definim una adreça IP de la nostra DMZ, també la mascara i el gateway.

4: Guardem els canvis

5: Ja podem connectar-nos a https://:9001 per la gestió del appliance virtual

6: Baixem el client d’administració (access gateway administration tool)

7: Anem a “this Gateway” / licensing i pujem el arxiu de llicències.

8: A general networking posem el External Public FQDN, que ha de coincidir amb el nom del arxiu .lic