Categories

Archive

Giugno 2025
L M M G V S D
 1
2345678
9101112131415
16171819202122
23242526272829
30  

Most viewed posts

VCP5 Exam Prep – Part 2.3

11 Agosto 2011
Comments off
Reading Time: 3 minutes

Objective 2.3 – Configure vSS and vDS Policies

Vedere anche questu post: Objective 2.3 – Configure vSS and VDS Policies e Objective 2.3 – Configure vSS and vDS Policies

Identify common vSS and vDS policies (similar as vSphere 4.x)

Vedere la vSphere Networking Guide (pag. 43). Le policy possono essere impostate su vSS e vDS e si applicano o a livello di intero switch o a livello di port group (per i vSS) o a livello di singola porta (per i vDS). Le impostazioni a livello di port group o singola porta sovrascrivono quelle a livello di intero switch.

Esistono varie policy descritte successivamente. Da notare che il blueprint non considera le policy di NIOC e Monitor (ma suggerisco di studiarle ugualmente).

Configure dvPort group blocking policies (similar as vSphere 4.x)

Per le policy di sicurezza vedere la parte relativa in: https://vinfrastructure.it/2011/08/vcp5-exam-prep-part-1-4/.

Per le policy di port blocking vedere la vSphere Networking Guide (pag. 59).

Configure load balancing and failover policies (similar as vSphere 4.1)

Vedere la vSphere Networking Guide (pag. 43). Le policy di Load balancing e failover permettono di definire come il traffico viene distribuito tra più adattatori (NIC o uplink) e come modificare il traffico nel caso di malfunzionomenti. Queste policy includono i seguenti parametri:

  • Load Balancing policy: Route based on the originating port oppure Route based on IP hash (richiede che a livello di switch sia configurato l’etherchannel) oppure Route based on source MAC hash oppure Use explicit failover order oppure Route based on physical NIC load (quest’ultimo solo per vDS) .
  • Failover Detection: Link Status oppure Beacon Probing (richiede almeno 3 NIC).
  • Failback: Yes oppure No.
  • Network Adapter Order: Active oppure Standby oppure Unused.

Configure VLAN settings (same as vSphere 4.x)

Vedere la vSphere Networking Guide (pag. 50). Si utilizza il campo VLAN ID di un port group (oppure di un distribuited port group) con un valore tra 1 e 4094 (il valore 0 disabilita il VLAN tagging e il valore 4095 equivale a far passare tutte le VLAN).

Per i vDS esistono anche altre due opzioni: VLAN Trunking (permette di specificare un intervallo di VLAN da far passare) e Private VLAN (per maggiori informazioni vedere: http://kb.vmware.com/kb/1010691)

Configure traffic shaping policies (same as vSphere 4.x)

Vedere la vSphere Networking Guide (pag. 54). Una policy di traffic shaping è definita da tre parametri: average bandwidth, peak bandwidth, and burst size. Le policy possono essere definite a livello di di ogni port group e a livello di ogni porta (solo nel caso dei vDS).

ESXi può gestire il traffico in uscita (sia per vSS che vDS) e il traffico in ingresso (ma solo per i vDS).

Enable TCP Segmentation Offload support for a virtual machine (same as vSphere 4.x)

Vedere la vSphere Networking Guide (pag. 38). Il TCP Segmentation Offload (TSO) è abilitato di default per le interfacce VMkernel, mentre deve essere abilitato per VM (utilizzando opportune vNIC).

Enable Jumbo Frames support on appropriate components (new in vSphere 5)

Vedere la vSphere Networking Guide (pag. 39). In vSphere 5 è possibile configurare il valore di MTU anche dalla GUI sia per i vSS che per le interfacce VMkernel. In vSphere 4.x era possibile solo via CLI (a parte la configurazione dei vDS possibile anche via GUI).

Determine appropriate VLAN configuration for a vSphere implementation (similar as vSphere 4.x)

Vedere la vSphere Networking Guide (pag. 66).  Il VLAN tagging è possibile a livelli differenti: External Switch Tagging (EST), Virtual Switch Tagging (VST) oppureVirtual Guest Tagging (VGT).

Funzioni mancanti

Il blueprint non considera le funzioni di port Mirroring e NetFlow (nuove in vSphere 5)… ma suggerisco di studiarle. Notare che inoltre è stato introdotto un nuovo protocollo standard di discover (LLDP), ma è configurabile solo per i vDS.

Certificazioni, Reti , ,

VCP5 Exam Prep – Part 2.2

10 Agosto 2011
Comments off
Reading Time: 2 minutes

Objective 2.2 – Configure vNetwork Distributed Switches

Vedere anche questi post: Objective 2.2 – Configure vNetwork Distributed Switches e Objective 2.2 – Configure vNetwork Distributed Switches

Identify vNetwork Distributed Switch capabilities (similar as vSphere 4.1)

Dalla pagina ufficiale delle funzionalità dei vDS:

  • Improves visibility into virtual machine traffic through Netflow (New in vDS 5)
  • Enhances monitoring and troubleshooting using SPAN and LLDP (New in vDS 5)
  • Enables the new Network I/O Control (NIOC) feature (now utilizing per VM controls) (New in vDS 5)
  • Simplified provisioning and administration of virtual networking across many hosts and clusters through a centralized interface.
  • Simplified end-to-end physical and virtual network management through third-party virtual switch extensions for the Cisco Nexus 1000V virtual switch.
  • Enhanced provisioning and traffic management capabilities through private VLAN support and bi-directional virtual machine rate-limiting.
  • Enhanced security and monitoring for virtual machines migrated via VMware vMotion through maintenance and migration of port runtime state.
  • Prioritized controls between different traffic types, including virtual machine, vMotion, FT, and IP storage traffic.
  • Load-based teaming for dynamic adjustment of the teaming algorithm so that the load is always balanced across a team of physical adapters on the distributed switch (New in vDS 4.1).

Vedere anche: vSphere 5 new Networking features.

Create/Delete a vNetwork Distributed Switch (same as vSphere 4.x)

Per questo punto e i successivi vedere la vSphere Networking Guide (anche nella versione 4.x) e http://thevirtualheadline.com/2011/07/11/vsphere-vnetwork-distributed-switches/.

Add/Remove ESXi hosts from a vNetwork Distributed Switch (same as vSphere 4.x)

Vedere la vSphere Networking Guide (pag. 21).

Add/Configure/Remove dvPort groups (same as vSphere 4.x)

Vedere la vSphere Networking Guide (pag. 25).

Add/Remove uplink adapters to dvUplink groups (same as vSphere 4.x)

Vedere la vSphere Networking Guide (pag. 29).

Create/Configure/Remove virtual adapters (same as vSphere 4.x)

Vedere la vSphere Networking Guide (pag. 30).

Migrate virtual adapters to/from a vNetwork Standard Switch (same as vSphere 4.x)

Vedere la vSphere Networking Guide (pag. 31) and VMware vNetwork Distributed Switch: Migration and Configuration

Migrate virtual machines to/from a vNetwork Distributed Switch (same as vSphere 4.x)

Vedere la vSphere Networking Guide (pag. 33) and VMware vNetwork Distributed Switch: Migration and Configuration

Determine use case for a vNetwork Distributed Switch (similar as vSphere 4.1)

Certificazioni, Reti, VMware , , ,

VCP5 Exam Prep – Part 2.1

9 Agosto 2011
Comments off
Reading Time: 2 minutes

Objective 2.1 – Configure vNetwork Standard Switches

Vedere anche questi post: Objective 2.1 – Configure vNetwork Standard Switches e Objective 2.1 – Configure vNetwork Standard Switches e Objective 2.1 – Configure vNetwork Standard Switches.

Identify vNetwork Standard Switch capabilities (same as vSphere 4.x)

Per i concetti base di virtual networking vedere VMware Virtual Networking Concepts e VMware Virtual Networking.

Create/Delete a vNetwork Standard Switch (similar as vSphere 4.x)

Vedere la vSphere Networking Guide (nella sezione dei vSS). Da notare che per il VCP5 non è richiesta una conoscenza dettagliata della CLI…

Rispetto alle precedenti versioni è possibile modificare tramite vSphere Client (prima solo tramite command line) le impostazioni di MTU per i vSwitch (ad esempio per abilitare i Jumbo Frame).

Add/Configure/Remove vmnics on a vNetwork Standard Switch (same as vSphere 4.x)

Vedere la vSphere Networking Guide (pag. 16 e 17). Ogni NIC dell’host agisce come un uplink di per un vSwitch.

Configure vmkernel ports for network services (similar as vSphere 4.x)

Vedere la vSphere Networking Guide (pag. 14). I port group di tipo VMkernel possono essere utilizzati per:

  • Management (il portgroup deve avere l’ozione “Management”).
  • vMotion (il portgroup deve avere l’opzione “vMotion”).
  • Management (il portgroup deve avere l’opzione “fault tolerance logging”).
  • IP storage, come iSCSI (nel caso software initiator) o NFS.

Rispetto alle precedenti versioni è possibile modificare tramite vSphere Client (prima solo tramite command line) le impostazioni di MTU per i vmkernel (ad esempio per abilitare i Jumbo Frame).

Add/Edit/Remove port groups on a vNetwork Standard Switch (same as vSphere 4.x)

Vedere la vSphere Networking Guide (pag. 12).

Determine use case for a vNetwork Standard Switch (same as vSphere 4.x)

Sia gli switch standard (vSS) che quelli distribuiti (vDS) possono convivere. Ma i vDS offrono maggiori funzionalità rispetto ai vSS. D’altro canto i vDS richiedono una licenza disponibile solo con l’edizione Enterprise+, rendendo quindi i vSS una scelta obbligatoria per tutte le altre edizioni.

Per ambienti piccoli (con un numero ridotto di host), i vSS sono decisamente più semplici da configurare e gestire: tutto può essere controllato a livello degli host (sotto Configuration-> Networking).

Certificazioni, Reti, VMware , ,

Le notività di vSphere 5 – Storage API

8 Agosto 2011
Comments off
Reading Time: 3 minutes

vStorage API

Introdotte per la prima volta in vSphere 4.0, le vStorage API sono funzioni specifiche che permettono una maggiore integrazione con funzioni esterne di storage evoluti. Da notare che esistono anche altri moduli di integrazione che rientrano nel PSA framework. Per maggiori informazioni sulle novità nello storage vedere (in inglese):

vSphere Storage API – Storage Awareness (VASA)

Questo nuovo set di API, introdotto in vSphere 5.0, permette a VMware vCenter Server di individuare specifiche funzionalità e caratteristiche dello storage e delle LUNs/datastore. In questo modo sarà possibile capire il tipo di tecnologia dei dischi (o il livello di prestazioni offerto), oppure sarà possibile semplificare il processo di troubleshooting. Le storage capability, come il livello del RAID, il tipo di provisioning (thin o thick), lo stato della replica e molti altri, divengono visibili in vCenter Server tramite il descrittore “system-defined capabilities”.

Per altre informazioni (in inglese) vedere: Overview vSphere Storage API for Storage Awareness (VASA) e A Deeper Look at VASA.

continue reading…

Evidenza, Storage none

Soluzioni di alta disponibilità per vCenter Server

5 Agosto 2011
No comments
Reading Time: 4 minutes

Progettare in modo corretto la disponibilità del vCenter Server può essere necessario in molti casi, ma può anche divenire critico in ambienti grossi o dove vi sono molti servizi che dipendono da esso. In ambienti piccoli di solito non è in grosso problema e la criticità è relativamente bassa… questo perché molte funzioni possono funzionare senza vCenter Server (per una lista delle dipendenze vedere  vCenter Server: fisico o virtuale?).

Esistono varie soluzioni per incrementare la disponibilità del vCenter Server:

  • Implementare il vCenter Server in virtuale e usare VMware HA.
  • Utilizzare il prodotto di VMware vCenter Server Heartbeat.
  • Utilizzare una soluzione di clustering come MSCS (opzione non più supportata a partire da vSphere 4.x).
  • Utilizzare VMware FT (opzione non supportata).

Per maggiori informazioni vedere: http://kb.vmware.com/kb/1024051 – Supported vCenter Server high availability options. Inoltre è disponibile un post recente (settembre 2012), su Yellow Bricks (Protecting vCenter Server – HA or Heartbeat?).

VMware HA

Per informazioni sulla tecnologia vedere la pagina ufficiale di VMware HA. Ovviamente questa soluzione è utilizzabile solo se il vCenter Server è in una macchina virtuale e se si dispone della licenza di VMware HA!

Bisogna ricordarsi che VMware HA richiede il vCenter Server solo per la fase iniziale di installazione e configurazione; poi lavora sugli host in modo distribuito senza più la dipendenza da vCenter Server. Per questa ragione VMware HA può gestire anche il riavvio della VM del vCenter Server (nel caso di un problema all’host)… con un disservizio totale di solito di pochi minuti.

Quindi per realtà medio/piccole la soluzione VMware HA può essere quella più semplice, valida ed economica (la licenza è inclusa in tutte le edizioni tranne che la Essential). Al fine di mantenere semplice la configurazione è possibile includere nella stessa VM anche il DB necessario al vCenter, altrimenti si rende necessario trovare una soluzione di HA per il DB stesso..

vCenter Server Heartbeat

Per informazioni sul prodotto vedere il sito ufficiale: http://www.vmware.com/products/vcenter-server-heartbeat/

In questo caso il vCenter Server (primary instance) può essere sia in virtuale che in fisico. La seconda istanza (secondary) invece deve essere in virtuale! Questo prodotto è anche in grado di gestire l’alta disponibilità del database (nel caso sia di tipo SQL Server).

Vedere anche: VMware to tackle vCenter availability with new Server Heartbeat.

MSCS o Failover Cluster

Soluzione non più supportata!

Vedere: http://www.vmware.com/pdf/VC_MSCS.pdf e Reference Implementation: Clustering VirtualCenter 2.5 Using Microsoft Cluster Services.

In questo caso il vCenter Server è una risorsa di un cluster applicativo ed i nodi del cluster possono essere virtuali, fisico o fisico/virtuale. Ovviamente per implementare un cluster Microsoft è richiesta una versione di Windows Server Enterprise o Datacenter.

Da notare che vCenter Server 2.5 è supportato solo su sistemi Windows Server 2003 o Windows Server 2003 R2. Mentre vCenter Server 4.0 è supported also on Windows Server 2008. E vCenter Server 4.1 o 5 richiede un sistema a 64 bit (e supportano anche Windows Server 2008 R2).

Una soluzoine simile è quella di utilizzare altre tecnologie di cluster applicativo, come ad esempio Veritas Cluster: http://searchservervirtualization.techtarget.com/news/article/0,289142,sid94_gci1341780,00.html (ma comunque la soluzione non è supportata).

Note: vCenter Server 4.x e 5 non sono più supportati con soluzioni di cluster di terze parti (rispetto a VMware), come ad esempio Microsoft Clustering Service and Veritas Cluster Services.

VMware FT?

Soluzione non supportata!

Ci si potrebbe chiedere perché non usare VMware FT per aumentare la disponibilità di un vCenter Server virtuale? Semplicemente perché il requisito minimo di processore di vCenter Server 4.0 è di almeno 2 vCPU (e potenzialmente di più al crescere dell’infrastruttura da gestire e se il DB è locale).

Come è noto il limite della versione attuale di VMware FT (anche in vSphere 5.0) è di gestire VM ciascuna con solo 1 vCPU. Quindi i si configura un vCenter Server con una sola vCPU (per ambienti piccoli funziona, ma non sarebbe comunque supportato) o non si usa VMware FT.

Per informazioni sulla tecnologia vedere la pagina ufficiale di VMware FT

Per le varie soluzioni utilizzabili per incrementare la disponibilità del vCenter Server vedere anche questa pagina.

Design, VMware , ,

vCenter Server: fisico o virtuale?

4 Agosto 2011
Comments off
Reading Time: < 1 minute

Fin dalla versione VI 3.x il vCenter Server poteva essere implementato su server fisico o macchina virtuale (entrambe le soluzioni sono supportate da VMware).

In questa pagina analizziamo i pro e contro di una soluzione rispetto all’altra.

Design, VMware , ,

Le novità di vSphere 5 – vRAM Entitlements

3 Agosto 2011
Comments off
Reading Time: 2 minutes

Nota: VMware ha rimosso il concetto vRAM Entitlements, quindi le informazioni di questo post non sono più rilevanti!

Introdotta durante il lancio di vSphere 5, questa novità nella licenza di vSphere (in particolare degli host) è stata rivisitata e migliorata per minimizzare eventuali impatti negativi (il primo a “spoilerare” la possibile notizia è stato Gabrie van Zanten). Non è cambiato il principio, ma i valori e come vengono calcolati. Ecco le novità principali:

  • aumentati i quantitativi di vRAM per tutte le licenze, raddoppiati quelli per le licenze Enterprise e Enterprise Plus;
  • introdotta una soglia massima al quantitativo di vRAM conteggiato per una singola VM (96 GB) così che nessuna VM possa costare più di una licenza Enterprise plus;
  • introdotto un nuovo modello di conteggio, basato sulla media annuale, che non penalizzi gli usi elevati di vRAM per brevi periodi (tipici di ambienti di test e sviluppo ad esempio);
  • aumentato il quantitativo di vRAM della versione free, che era diventata di fatto quasi inutilizzabile: si passa da 8 GB a 32 GB con la limitazione che 32GB sono anche il limite massimo di RAM fisica per il server.
vSphere edition vRAM entitlement precente Nuovo vRAM entitlement
vSphere Desktop Unlimited Unlimited
vSphere Enterprise+ 48 GB 96 GB
vSphere Enterprise 32 GB 64 GB
vSphere Standard 24 GB 32 GB
vSphere Essentials+ 24 GB 32 GB
vSphere Essentials 24 GB 32 GB
Free vSphere Hypervisor 8 GB 32 GB[*]

[*] limite di RAM fisica per ogni server fisico

Vedere anche i post in italiano su:

In inglese vedere:

Design, VMware , ,
© 2025-2011 vInfrastructure Blog | Disclaimer & Copyright