Objective 3.3 – Create and Configure VMFS and NFS Datastores

Vedere anche questi post (in inglese): Objective 3.3 – Create and Configure VMFS and NFS Datastores e Objective 3.3 – Create and Configure VMFS and NFS Datastores.

Identify VMFS and NFS Datastore properties (similar as vSphere 4.x)

Vedere la vSphere Storage Guide (pag. 21). I datastore NFS hanno praticamente le stesse funzioni di quelli VMFS (in vSphere 5 anche l’accelerazione hardware è supportata per alcuni storage), ma alcuni limiti rimangono, come ad esempio che non possono implementare un RDM disk, e quindi non sono adatti per realizzare una soluzione di failover clustering a livello del sistema operativo delle VM (come ad esempio il Microsoft MSCS).

Identify VMFS5 capabilities (new in vSphere 5)

Vedere la vSphere Storage Guide (pag. 114) e il blog vSphere 5.0 Storage Features Part 1 – VMFS-5.

VMFS5 introduce numerosi miglioramenti in scalabilità e prestazioni:

  • Utilizzo della tabella delle partizioni di tipo GPT (vedere anche vSphere 5.0 Storage Features Part 7 – VMFS-5 & GPT) per le nuove partizioni (per i datastore VMFS5 creati da zero).
  • Dimensione del blocco standard e fisso (1MB per i datastore VMFS5 formattati da zero), a differenza delle precedenti versioni di VMFS che usavano blocchi da 1,2,4 o 8MB .
  • Dimensione maggiore di un singolo volume: in precedenza ogni singolo volume o extent VMFS poteva essere grande al massimo 2TB-512B. Con VMFS-5 questo limite è stato increamentato a circa 60TB.
  • Possibilità di realizzare un upgrade on-line e in-place.
  • Maggiore stabilità e migiornamenti vari in VAAI e ATS.
  • Incremento di alcune risorse quali filedescriptor e file count, sub-Block più piccoli e supporto per file di piccole dimensioni.
  • Mount e Unmount workflow nel vSphere Client.

Le differenze tra un VMFS5 nuovo (creato formattando un disco) o di uno aggiornato da VMFS3 sono:

  • Datastore VMFS-5 aggiornati da VMFS-3 mantengono il precedente block size, che potrebbe anche essere maggiore di 1MB.
  • Datastore VMFS-5 aggiornati da VMFS-3 continuano ad usare i sub-block da 64KB  e non quelli nuovi da 8K.
  • Datastore VMFS-5 aggiornati da VMFS-3 mantengono il loro file limit di 30720 invece di quello nuovo (> 100000).
  • Datastore VMFS-5 aggiornati da VMFS-3 utilizzano lo schema di partizioni MBR (Master Boot Record) ; quando perà il volume supera i 2 TB di dimensione passerà automaticamente allo schema di tipo GPT (GUID Partition Table) senza impattare le VM in esecuzione.
  • Datastore VMFS-5 aggiornati da VMFS-3 hanno la partizione che inizia al settore 128 (per l’allineamento ); quelli creati da zero l’hanno a partire dal settore 2048.

Per i dischi di tipo RDM ( Raw Device Mappings):

  • Dischi RDM in passthru (physical mode) possono arrivare ai ~ 60TB.
  • Sia sui nuovi VMFS-5 che su quelli aggiorni si possono usare i passthru RDM di grandi dimensioni.

Notare che:

  • La dimensione massima di un VMDK anche in VMFS-5 rimane di  2TB -512 byte.
  • La dimensione massima di un non-passthru (virtual) RDM rimane di 2TB -512 byte.
  • Il numero massimo di LUN supportato in ESXi 5.0 rimane di 256.

Create/Rename/Delete/Unmount a VMFS Datastore (same as vSphere 4.x)

Vedere la vSphere Storage Guide (pag. 115, 129, 123 e 131).

Mount/Unmount an NFS Datastore (same as vSphere 4.x)

Vedere la vSphere Storage Guide (pag. 128).

Extend/Expand VMFS Datastores (same as vSphere 4.x)

Vedere la vSphere Storage Guide (pag. 119). Da notare che vi sono due metodi possibili per ingrandire un datastore VMFS (sono gli stessi presenti anche in vSphere 4.x):

  • Aggiungere un nuovo extent (come avveniva anche in VI 3.x): an extent is a partition on a storage device, or LUN. You can add up to 32 new extents of the same storage type to an existing VMFS datastore. The spanned VMFS datastore can use any of allits extents at any time. It does not need to fill up a particular extent before using the next one.
  • Espandere il datastore con la funzione grow (introdotta in vSphere 4.0) che estende la partizione VMFS sfruttando lo spazio libero adiacente alla partizione stessa. Only extents with free space immediately after them are expandable.

Upgrade a VMFS3 Datastore to VMFS5 (new in vSphere 5)

Vedere la vSphere Storage Guide (pag. 121). Per i datastore VMFS3 la procedura di upgrade può essere svolta “live” con le VM in funzione (molto differente rispetto alla procedura di aggiornamento da VMFS2 a VMFS3). Naturalmente gli host che accederanno a datastore VMFS5 devono supportarlo e quindi essere tutti ESXi 5.

Place a VMFS Datastore in Maintenance Mode (new in vSphere 5)

Vedere la vSphere Resource Management Guide (pag. 83). La modalità “maintenance mode” dei datastore è una nuova funzione di vSphere disponibile per all’interno di un datastore cluster abilitato allo Storage DRS (SDRS). I datastore standalone non possono essere posti in maintenance mode.

Select the Preferred Path for a VMFS Datastore (similar as vSphere 4.x)

Vedere la vSphere Storage Guide (pag. 158).

Disable a path to a VMFS Datastore (similar as vSphere 4.x)

Vedere la vSphere Storage Guide (pag. 163).

Determine use case for multiple VMFS/NFS Datastores (similar as vSphere 4.x)

Gli attuali limiti dei datastore NFS sono oramai pochi (vedere nel punto precedente per il limite del cluster), ma vi sono anche alcuni vantaggi (come ad esempio una migliore gestione del file locking). Per maggiori informazione vedere il seguente sito (in inglese): http://technodrone.blogspot.com/2010/01/vmfs-or-nfs.html.

Determine appropriate Path Selection Policy for a given VMFS Datastore (similar as vSphere 4.x)

Vedere la vSphere Storage Guide (pag. 159).

Objective 3.2 – Configure the Storage Virtual Appliance for vSphere

Questo punto è tutto specifico di un nuovo prodotto: VMware Storage Virtual Appliance 1.0 (indicato nel blueprint con SVA, ma spesso invece indicato con VSA) for vSphere 5. Da notare che questo prodotto non è parte integrale di vSphere ma un prodotto a parte, con un suo specifico licensing e prezzo (vedere il sito VMware per maggiori dettagli).

Per realizzare un ambiente di laboratorio con l’obiettivo di testare VSA vedere questo blog:  Getting the VMware VSA running in a nested ESXi environment.

Vedere anche questo post (in inglese): Objective 3.2 – Configure the Storage Virtual Appliance for vSphere.

Define SVA architecture

Vedere la vSphere Storage Appliance 1.0 Installation and Configuration Guide (pag. 9), il documento VMware vSphere Storage Appliance Technical Whitepaper (pag. 3) e il blog vSphere Storage Appliance (VSA) – Introduction.

Un VSA storage cluster è composto da due o tre nodi ESXi 5 ciascuno con storage locale un appliance VSA (è una VM con caratteristiche particolari, quali ad esempio che non può essere migrata). Lo spazio locale di ciascun host viene convertito un un datastore NFS (con opportuna replica tra i diversi VSA) a sua volta ri-presentato agli host ESXi.

Configure ESXi hosts as SVA hosts

Come descritto in precenza una soluzione VSA può essere implementata con due diverse configurazioni:

  • 3 host VMware ESXi 5.0
  • 2 host VMware ESXi 5.0

Le due diverse configurazioni sono di fatto identiche, almeno nel modo di presentare lo storage. La principale differenza è nel modo di gestire e coordinare i membri del cluster VSA storage cluster; con soli 2 nodi serve un meccanismo di maggioranza che viene implementato da un servizio speciale (VSA cluster service), in esecuzione sul VMware vCenter Server. Quest servizio simula un ulteriore nodo per garantire la maggioranza and caso di failure, ma non esiste alcuno storage associato a questo servizi.

Configure the storage network for the SVA

Vedere la vSphere Storage Appliance 1.0 Installation and Configuration Guide (pag. 21). Da notare che sono richiesti due reti differenti (front-end and back-end network):

Deploy/Configure the SVA Manager

Un’installazione di VSA deve iniziare dall’installazione del VSA manager, una componente software che viene installata nella stessa macchina del VMware vCenter Server. Una volta completa l’installazione, nel vSphere client sarà disponibile il plug-in del VSA manager, che permetterà di accedere al tab relativo di gestione del cluster.

Da notare che, in questa release 1.0, un’instanza di vCenter Server 5.0 può solo gestire un solo VSA storage cluster.

Administer SVA storage resources

Vedere la vSphere Storage Appliance 1.0 Administration.

Determine use case for deploying the SVA

VSA permette di usufruire di varie funzionalità di vSphere (incluse VMware HA, vMotion, DRS, …) senza la necessità di comprare uno storage fisico condiviso. Per questa ragione VMware ritiene la soluzione molto cost-effective (personalmente, anche nel caso del bundle con l’Essential+, ritengo comunque il prodotto non troppo “economico”) e particolarmente indicata per il mercato SMB/PMI.

Il deploy di VSA è particolarmente seplificato, visto che molte delle attività di configurazione (come la configurazione della rete e di vSphere HA) sono svolte direttamente dall’installer. Secondo VMware anche un utente che non conosce in dettaglio vSphere può essere in grado di implementare VSA.

Un aspetto invece importante di VSA è la sua resilienza: se un host ESXi fallisce (con la sua parte relativa di VSA) o un singolo membro del cluster VSA fallisce, il datastore NFS verrà automaticamente cambiato sul relativo VSA di replica.

Determine appropriate ESXi host resources for the SVA

Per calcoare la capacità di un cluster VSA vedere la vSphere Storage Appliance 1.0 Installation and Configuration Guide (pag. 15).

Per quanto riguarda i requisti degli host vedere la vSphere Storage Appliance 1.0 Installation and Configuration Guide (pag. 17). Da notare che l’attuale HCL è veramente risicata e che nella versione 1.0 l’unica configurazione RAID supportata è la RAID10.

Objective 3.1 – Configure Shared Storage for vSphere

Vedere anche questi post (in inglese): Objective 3.1 – Configure Shared Storage for vSphere e Objective 3.1 – Configure Shared Storage for vSphere

Identify storage adapters and devices (similar as vSphere 4.x)

Vedere la vSphere Storage Guide (pag. 10). Gli storage adapter forniscono la connecttività tra un host ESXi e uno specifico storage (di tipo a blocchi).
ESXi supporta differenti tipi di adattatori che includono SCSI, SAS, SATA, iSCSI, Fibre Channel, Fibre Channel over Ethernet (FCoE). ESXi accede a questi adattatori direttamente attraverso i device driver implementati nel VMkernel.

Da notare che gli storage a blocchi possono essere locali (tipicamente SCSI, SAS o SATA) o di tipo SAN (iSCSI, FC, FCoE). Storage di tipo locali possono anche essere shared (come il caso degli storage con tecnologia LSI), mentre gli storage SAN sono per loro natura già di tipo shared. Per poter usufruire di molte delle funzionalità di vSphere (come vMotion, HA, DRS, DPM, …) uno dei principali requisiti è disporre di uno storage di tipo condiviso.

Le funzionalità di RAID devono essere sempre implementate in hardware (VMware non supporta né RAID software né “fake” RAID): o nel controller dell’host (per storage locale non condiviso) o nello storage stesso.

Identify storage naming conventions (similar as vSphere 4.x)

Vedere la vSphere Storage Guide (pag. 17). Ogni dispositivo di storage, o LUN, è identificato con differenti nomi:

  • Device Identifiers: SCSI INQUIRY identifier (naa.number, t10.number, eui.number) or Path-based identifier (mpx.path)
  • Legacy identifier (vml.number)
  • Runtime Name

Identify hardware/dependent hardware/software iSCSI initiator requirements (similar as vSphere 4.1)

Vedere la vSphere Storage Guide (pag. 63) e anche http://vinfrastructure.it/vdesign/vstorage-software-vs-hardware-iscsi/

Compare and contrast array thin provisioning and virtual disk thin provisioning (similar as vSphere 4.x)

Vedere la vSphere Storage Guide (pag. 183). Con ESXi sono supportati due diversi modelli di thin provisioning: array-level (se previsto dallo storage) e virtual disk-level (utilizzato il formato dei vmdk di tipo thin, introdotto per la prima volta con VI 3.5).

Il principale problema nell’uso del thin provisioning a livello di storage array era che, nelle versioni precedenti, vSphere non era in grado di conoscere il tipo di provisioning della LUN e che lo storage non era in grado di tracciare il reale utilizzo della LUN (e oltretutto il reclaim dello spazio libero era spesso impossibile). Con le nuove primitive di Thin Provisioning del VAAI e anche con le nuove API per il VASA, questo problema è stato risolto.

Describe zoning and LUN masking practices (same as vSphere 4.x)

Vedere la vSphere Storage Guide (pag. 32). Lo zoning definisce le regole di accesso in una rete SAN (banalizzando si potrebbe paragonare alle regole di commutazione degli switch della rete SAN). Tramite lo zoning si definisce quali HBA possono collegarsi a quali interfacce degli storage. Tipicamente si applica solo alle reti SAN di tipo FC.

Gli effetti dello zoning sono:

  • Controllo dei percorsi di una fabric.
  • Può aumentare la sicurezza (di default dovrebbe essere “tutto chiuso”).
  • Può essere utilizzato per creare ambienti differenti (come ad esempio produzione e test).

Invece il LUN masking è un modo di “nascondere” alcune LUN agli host e si può applicare sia a livello di storage (soluzione tipicamente consigliata) o a livello degli host. Il risultato è una diminuzione del numero di target e LUN, con ,ad esempio, il vantaggio in un minor tempo di boot o di rescan dell’host.

Scan/Rescan storage (same as vSphere 4.x)

Vedere la vSphere Storage Guide (pag. 124). Per ogni host è disponibile la funzione rescan (sotto storage adapter), ma volendo è anche possibile richiedere un rescan per tutti gli host gestiti da vCenter Server: basta un right-click a livello di datacenter, cluster o un folder che contiene gli host, selezionando “Rescan for Datastores”.

Da notare che, di default, il VMkernel effettua una scansione alla ricerca delle LUN dal numero 0 al 255, per ogni target (per un totale di 256 LUN). Per velocizzare la scansione è possibile usare il LUN masking e/o ridurre il numero di LUN scansionate (cambiando il parametro Disk.MaxLUN).

Identify use cases for FCoE (new in vSphere 5)

Vedere la vSphere Storage Guide (pag. 21 e 37). Il protocollo Fibre Channel over Ethernet (FCoE) permette di incapsulare pacchetti Fibre Channel in trame Ethernet. In questo modo è possibile evitare una rete SAN FC e utilizzare al suo posto una rete 10Gbit lossless Ethernet.

In vSphere 5 possono essere utilizzati due tipi diversi di adattatori: Converged Network Adapter (hardware FCoE, simile ad un hardware independent iSCSI adapter) oppure NIC with FCoE support (software FCoE, simile ad un hardware dependent iSCSI adapter).

Create an NFS share for use with vSphere (same as vSphere 4.x)

Vedere la vSphere Storage Guide (pag. 128).

Connect to a NAS device (same as vSphere 4.x)

Vedere la vSphere Storage Guide (pag. 128).

Note: da notare che vSphere 5 introduce anche la funzione di Hardware Acceleration per i  NAS Devices (che però deve essere fornita dal vendor dello storage). I datastore NFS con questa funzione supportano le policy di provisioning dei dischi dei datastore VMFS : Flat disk (il vecchio zeroedthick format), Thick Provision (il vecchio eagerzeroedthick) e Thin Provisioning. Nei datastore NFS che non supportano la funzione di Hardware Acceleration, è disponibile solo il formato thin.

Enable/Configure/Disable vCenter Server storage filters (same as vSphere 4.x)

Vedere la vSphere Storage Guide (pag. 126). Si utilizzano gli advanced settings del vCenter Server: config.vpxd.filter.vmfsFilter, config.vpxd.filter.rdm, …

Configure/Edit hardware/dependent hardware initiators (similar as vSphere 4.1)

Vedere la vSphere Storage Guide (pag. 70).

Enable/Disable software iSCSI initiator (same as vSphere 4.x)

Vedere la vSphere Storage Guide (pag. 72).

Configure/Edit software iSCSI initiator settings (same as vSphere 4.x)

Vedere la vSphere Storage Guide (pag. 72).

Configure iSCSI port binding (new in vSphere 5)

Vedere la vSphere Storage Guide (pag. 78). Questa particolare configurazione è richiesta da alcuni storage iSCSI e, nelle versioni precedenti, era possibile configurare il binding solo tramite la command line. In vSphere 5 è possibile configurarlo anche tramite vSphere Client.

Enable/Configure/Disable iSCSI CHAP (same as vSphere 4.x)

Vedere la vSphere Storage Guide (pag. 83).

Determine use case for hardware/dependent hardware/software iSCSI initiator (similar as vSphere 4.1)

Vedere la vSphere Storage Guide (pag. 63) e anche http://vinfrastructure.it/vdesign/vstorage-software-vs-hardware-iscsi/

Determine use case for and configure array thin provisioning (similar as vSphere 4.x)

Vedere il punto precedente sul thin provisioning.

In questa pagina sono descritti i diversi tipi di iSCSI inititator supportati in VMware vSphere e alcuni possibili criteri di scelta:
http://vinfrastructure.it/vdesign/vstorage-software-vs-hardware-iscsi/

Benché ancora non vi siano informazioni sulla certificazione VCDX5 (del resto vi sono ancora poche informazioni sia sul VCAP5-DCA che sul VCAP5-DCD), volevo segnalare alcune interessanti discussioni riguardo al programma VCDX:

Oltre alle solite FAQ disponibili sul sito VMware, esiste un bel podcast relativo al programma VCDX con alcune domande (e risposte) molto originali e interessanti.Podcast #134: http://www.talkshoe.com/talkshoe/web/talkCast.jsp?masterId=19367

Benché non sia ancora completa, la versione del VCP5 Blueprint con note è disponibile con i primi due obiettivi. Rimanete sintonizzati per i prossimi aggiornamenti!

Per vedere lo stato attuale del blueprint, vedere: http://vinfrastructure.it/certifications-on-virtualization/vcp/vcp5/

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: http://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.

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)

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).

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…

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.

© 2017 © 2013 vInfrastructure Blog | Hosted by Assyrus