Skip navigation

YAVB

4 posts

Tutti i produttori di storage negli ultimi anni hanno ovviamente dovuto introdurre i "dischi" (le virgolette sono d'obbligo perché non c'è più correlazione fra il nome e la struttura fisica...) a stato solido.

Ovviamente l'implementazione più estrema e semplice è quella di usare gli SSD al posto dei dischi rotanti. Ma visto il costo di questi i produttori cercano di andare verso soluzioni miste in cui pochi dischi SSD aiutino quelli tradizionali, che siano SAS o SATA.

 

NetApp ha da qualche tempo in listino la soluzione FlashPool: in breve si usano pochi dischi SSD per creare degli aggregati ibridi. Da qualche settimana ci è arrivato il primo 2240-2 che ha 24 dischi SAS 900GB 10k (i 15 k non esistono più) dentro la macchina più 4 SSD da 200 ciascuno dentro uno shelf esterno.

Questa soluzione era una novità totale per me e anche abbastanza nuova per la persona -molto esperta- che è venuta a fare la "messa in moto": dopo aver creato l'aggregato ibrido su una delle due teste abbiamo creato un volume con il wizard "provision Storage for VMware" e l'abbiamo montato (per NetApp io uso solo NFS) sugli host del cluster. Dopo aver caricato le VM su questo datastore notavo che le prestazioni, soprattutto la latenza, non era "bella" come mi aspettavo.

Con l'OnCommand System Manager c'è una pagina in cui viene mostrato in tempo reale quante sono le read e write hits rispetto alle requests: mi diceva in modo evidente che le read hits erano costantemente a 0 e le write hits rarissime.

 

Non ci sono grandi possibilità di configurare le policy con cui la macchina utilizza la FlashPool. Purtroppo googlando con parole chiave come "neatpp flashpool vmware best practices" non si trovano molti aiuti.

Però andando alla fonte e consultando il paper TR-4070 di NetApp ("Flash Pool Design and Implementation Guide") si apprende che le policy in lettura sono

  1. read-cache=meta la cache è usata per i metadati
  2. read-cache=random-read che è quella di default
  3. read-cache=random-read-write
  4. read-cache=none


non mi dilungo in spiegazioni dettagliate che si trovano nel documento: in sintesi bisogna impostare la policy random-read-write per ogni volume su cui avete un datastore. Pochi istanti dopo averlo fatto le read hits hanno iniziato a crescere inesorabilmente verso il 100%.

Per quel che riguarda la policy di write quella di default (random-write) è quella che mi da i risultati migliori.

 

Ecco un esempio visivo di come lavora dopo questa facile ottimizzazione:

 

fp.jpg

 

I comandi da dare sono

 

FAS3240-ONTAP-FP> priv set advanced

Warning: These advanced commands are potentially dangerous; use

them only when directed to do so by NetApp

personnel.

FAS3240-ONTAP-FP*> priority hybrid-cache set vol1 read-cache=random-read-write

FAS3240-ONTAP-FP*> Sun May 6 14:00:25 EST [FAS3240-ONTAP-FP:wafl.hya.rcache.policy:info]: Read caching policy on volume 'vol1' has been modified to 'random-read-write'.

FAS3240-ONTAP-FP> priv set admin

 

N.B.: questo l'ho testato su un datastore NFS: in caso di iSCSI o FCP potrebbe essere migliore una policy differente.

Salve a tutti,

 

oggi ho verificato che mi erano scadute le password dei due utenti (uno l'admin creato di default più uno creato da me) perché, come sapevo, dopo un anno scadono.

 

La brutta sorpresa è che sia la procedura per il cambio della password, sia quella per resettarle, mi falliscono

 

quella per cambiare la password è qui VMware KB:    Resetting an expired password in vCenter Single Sign-On (SSO) 

ma mi restituisce un errore SslHandshakeFailed prima ancora di chiedermi le password.

 

Allora ho tentato quella per resettare: VMware KB:    Unlocking and resetting the vCenter Single Sign-On (SSO) administrator password 

qui mi viene chiesta la "master password" (quella che è stata assegnata ad Admin@System-Domain all'installazione), che digito e riconosce, poi la nuova password da assegnare, che digito due volte, ma ottengo questo errore:
ERROR: Key [com.rsa.db.msserverinstance] is not defined

 

Tutto ciò mi succede in maniera identica sia su un vCenter che tengo "per esperimenti" sia su quello buono. Che cosa sto sbagliando?

 

Se aggiornassi alla 5.5? Quasi quasi ci provo sul vCenter scratch per vedere cosa succede...

provando l'upgrade sono incorso nel warning (che, ignorato, ha portato al fallimento dell'aggiornamento con "Error: 87") che è descritto

qui http://www.virten.net/2013/11/warning-25000-at-vcenter-5-5-update-how-to-handle/

 

come suggerito ho verificato che i miei certificati autogenerati sono ancora validi.

Vediamo se anche il mio errore può essere quello descritto

qui http://www.virten.net/2013/11/upgrade-vcenter-5-1-to-5-5-error-the-existing-ssl-certificate-is-invalid/

 

Seguendo i passi ho editato il registro (nel mio caso il campo era vuoto) ma non ho rimosso la directory "CIS" in quanto non era presente. Dopo il riavvio (intero del server) rilanciando l'upgrade ho nuovamente visto il warning 25000

 

errore25000.jpg

 

però andando avanti è comparsa una spunta verde che prima non c'era (l'ultima)

 

unapiu.jpg

 

infatti proseguendo l'upgrade dell'SSO, questo è andato a buon fine.

La procedura mi aveva chiesto una nuova password per administrator@vsphere.local: aggiornando il Web Client mi è stata chiesta e riconosciuta.

 

Procedendo con l'Inventory Service tutto ok, passando a vCenter.... l'aggiornamento è fallito, ma credo si sia trattato di un diverso problema: anche installando un vCenter completamente nuovo su un DB pulito mi trovo davanti lo stesso messaggio:

 

vc.jpg

dal digest della community di Veeam domenica sera (per noi italiani) è arrivato un warning molto importante che riguarda Windows server 2012

 

POSSIBLE DATA CORRUPTION ISSUE, MUST READ! Sorry for starting this way, but this is a big deal, and I wanted to make sure you catch this when scanning through the weekend spam. Apparently, VMware issued a support KB article on this issue a few weeks ago, but it totally flew under the radar (I have not seen a single tweet or blog about this). In short, any data flowing through the VM network stack may get corrupted - including but not limited to file copies, database interactions with remote clients, and so on.

The scariest part is that the scope of this issue is very significant. In fact, we might as well be facing the biggest data corruption issue in the history of virtualization. The issue may occur on any Windows Server 2012 VM with the default (E1000E) vNIC adaptor running on ESXi 5.0 and 5.1, which is probably around 20% of all VMs in the world as a conservative estimate. The easiest workaround is to change the vNIC type to VMXNET3 or E1000 (you should be able to apply this change in bulk with a PowerCLI script), or disable TCP Segmentation Offload in the guest operating system. Keep in mind that changing vNIC type may result in change of DHCP address, because the OS will see that as the new adaptor – so this may affect some applications. As such, disabling TCP Segmentation Offload might sometimes be a better choice, however keep in mind this will increase VM CPU usage.

Specifically to your backups, even if some of your backup infrastructure components are running in a Windows Server 2012 VM, you should be safe if you are using Veeam Backup & Replication 6.1 or later. This was when we added inline network traffic validation (and remediation) to work around some other data corruption issues involving faulty network equipment, I had a big story about this in a weekly digest over one year ago. However, unfortunately your actual production data may be corrupted, and unless you have backups going all the way back to your vSphere 5.x or Windows Server 2012 upgrade, this might be one of those cases of unrecoverable data loss...

As per VMware support KB, the investigation is still on-going, so I would not yet jump to a conclusion that this is a bug with VMware. For example, we did see one mysterious data corruption issue during weeks of automated stress testing of our Windows Server 2012 support. We called it “10 bad bits mystery” internally, and it was affecting network transfers on both physical and virtual hardware. Unfortunately, the issue was impossible to reproduce reliably, so our investigation with Microsoft went nowhere (and we have it covered with our network traffic validation anyway). But, if anyone from VMware R&D or support are reading this, feel free to reach out to me to discuss the corruption pattern and factors facilitating the issue surfacing – as this could be the same issue.

Tinto1970 Master

Server Blade.... perché?

Posted by Tinto1970 Jun 23, 2013

Avevo notato questa possibilità di creare un blog, data dalla nuova interfaccia delle community di vmware, e una cosa che mi ha fatto arrabbiare un bel po' mi da lo spunto per uno sfogo

 

Nel piccolo datacenter dove lavoro abbiamo, da settembre 2010, un Blade Dell che al suo arrivo era riempito circa al 50%, con due server fisici, due host per un cluster vSphere, uno per il vCenter fisico (considerando che siamo partiti con la 4.1... no comment). Negli anni seguenti si sono aggiunte altre 4 "lame", una ad affiancare i due precedenti per ampliare il cluster a 3 nodi, altre 3 per un nuovo cluster vSphere. Tutte le lame nuove sono state montate senza problemi, pensando "come è comodo, niente più cavi da stendere, ordinare, fatica, etc etc". A giugno 2011, in occasione di un giro di aggiornamenti, porto tutti i bios, idrac e varie amenità alla versione ultima.

 

Ora, nel 2013, nel giro di un paio di mesi sono stati fatti due di acquisti che mi hanno gradualmente indotto dei dubbi, poi .... bruscamente chiariti.

 

A maggio si acquista un server rack 19'' 2U per spostarci sopra il nodo locale dag di exchange 2010 liberando spazio e risorse sullo storage centralizzato: i tempi sono di magra e siccome i dischi dentro un server costano molto meno che dentro uno storage si è deciso così. Arriva il server, una mattina se ne va con i cablaggi e montaggio, qualche dito schiacciato, alcune imprecazioni, pensando "come sono comodi i blade.....". Nel pomeriggio si installa ESXi, si configura e a fine giornata la macchina è già produttiva.

 

A giugno bisogna espandere uno dei due cluster vSphere dentro il blade, con una certa fretta perché il cluster è un po' a tappo. Gli M710HD non esistono più ma mi propongono una M520 spiegandomi che non servirà neanche abilitare l'EVC etc etc.

Bene, però accidenti: mi costa poco meno del server 19'', ha una cpu in più ma zero storage interno, niente controller con 1 GB di cache, solo 4 nic... mica tanto conveniente! Vabbè pazienza: almeno è tanto comodo da installare....

Arriva il nuovo blade, lo scarto pensando "entro poche ore sarà al lavoro!". Però legata al "tappo" da rimuovere prima dell'inserimento nell'enclosure trovo un'etichetta. Quelle che quando sei giovane e spensierato butti senza neanche guardare, tanto di solito contengono avvisi tipo "si ricorda che nessun componente di questo server è commestibile" e così via. Purtroppo non sono più giovane e la leggo. Dice in modo netto che prima di montare la lama bisogna aggiornare il firmware del blade almeno alla 4.1. Accidenti!!! Io sono rimasto alla versione 2.3, anche perché un tecnico Dell nel 2011 mi aveva riferito che l'aggiornamento del "CMC" in alcuni casi di suoi clienti aveva fatto un disastro, con le lame che neanche più si accendevano.

 

Trattengo le imprecazioni che mi vengono per la mente (proprio in quell'istante si scatena il terremoto del 21/06/2013: forse era meglio se mi sfogavo verbalmente...) e inizio a recuperare informazioni aggiornate in giro, capito su un forum Dell, e posto una domanda che essenzialmente chiede "è rischioso aggiornare il CMC?". La risposta, gentile tanto quanto celere, è più o meno "aggiornare il CMC è a basso rischio, ma è raccomandato farla durante una manutenzione programmata".

E' chiaro, non possono sbilanciarsi per evitare potenziali richieste danni, dicono che l'operazione presenta un minimo rischio ed è meglio farla con tutte le lame spente. Parlerò col supporto per cercare di capire quale sia il margine di rischio. Però una cosa è chiara: un minimo rischio c'è e, per essere tranquilli, dovrei trovare un momento per fermare le macchine di 3 aziende, che producono in orari diversi coprendo quasi le 24 ore. Questo è un costo sia per l'interruzione del servizio, sia per gli operatori che devono fare un lavoro fuori del normale orario.

 

A questo punto i dubbi sono chiariti: i blade consentono un certo risparmio di spazio, sono più puliti da vedere ma, in futuro, li eviterò tutte le volte che potrò.