Storage ALLFLASH - E' tutto oro quello che luccica?

Che il futuro degli storage sia ALL-FLASH ormai è noto a tutti, che la strada sia spianata, la caratteristica di essere "super veloci", "super efficenti", "super qualunque altra cosa" altrettanto... Si riscontra quotidianamente sul campo una fortissima spinta commerciale come da anni non vedevo... Nel mondo IT-Storage si parla quasi esclusivamente di questo... Gli eventi sono ormai monotematici...

MA...

Adoro cercare i "MA"..

FileServer o WebServer, questo è il dilemma...

Recentemente ho eseguito un interessante progetto in merito alla fattibilità ed analisi dei costi per la migrazione di un vetusto, se pur ancora mediocremente funzionante, FileServer.

Avete presente i buoni vecchi tower pieni di dischi dimenticati “da qualche parte in qualche sgabuzzino”?

Ecco, proprio uno di quelli.

L'as-is si compone di una sede principale e tre branch office, dislocati nel territorio emiliano, magliati in MPLS ed un ottima connettività internet. Nella sede principale avevamo il nostro bel serverone che condivideva cartelle e file per gli utenti di dominio della sede principale e di tutte le sedi remote.

Orbene…

Oltre alla necessità di rinnovare l' HW, il cliente lamentava grossi problemi, da parte degli utenti delle sedi remote, a fruire dei contenuti/files presenti sul FileServer della sede principale.

Fatti subito due conti, il costo dell' eventuale aumento della banda MPLS non poteva essere preso in considerazione per motivi di budget mentre un eventuale, se necessario, upgrade della banda internet era cosa da poco ( paragonando i due costi…). 

Ulteriore dettaglio non trascurabile era il fatto che il cliente non voleva acquistare HW ma “metterlo in CLOUD” ( quante volte ve lo siete sentiti dire? ) e voleva spendere nulla o quasi ( vedesi l’ormai famoso connubio tutto-subito-costapoco )

Da dove sono partito..

Poichè il System Integrator per cui lavoro eroga da tempo servizi a valore, ho pensato di prendere come base uno in particolare, il drive.for.you, adeguato opportunamente al fine di giungere allo scopo finale.

Di cosa stiamo parlando?

Molto “semplicemente” di creare una piattaforma LAMP, nel mio specifico caso ho scelto Ubuntu 16.04LTS, Apache2.4, MySQL e Php7, di implementare, customizzandolo, il set di istruzioni WebDAV ("Web-based Distributed Authoring and Versioning" ) e renderlo fruibile e sicuro.

La scelta, in questo particolare caso, è ricaduta su WebDAV poiché, tra le sue caratteristiche, ha quella di essere gratuito, permette la creazione/eliminazione, la modifica e lo spostamento di file situati in un webserver, include un sistema di blocco (ovvero protezione dalla sovrascrittura dei file), di proprietà (creazione, rimozione e richieste di informazioni riguardo all'autore, alla data di modifica, ecc..) ed è accedibile in maniera semplice, sicura ed affidabile.

L’ambiente viene poi connesso in VPN all’ AD del cliente tale da garantire l’accesso al fileserver in SSO. 

Gli utenti, siano essi interni che in mobilità, possono crearsi un percorso di rete personalizzato puntando al path del servizio WebDAV. 
Esistono sul mercato vari client oppure, come in questo caso, l'OS dei PC del cliente aveva già integrato tale protocollo ( click destro, aggiungi percorso di rete personalizzato,  https://webserver/condivisione )

In LAB è stato realizzato in davvero poco tempo e devo dire che ha soddisfatto in pieno le richieste del cliente.

Semplice, veloce ed efficace…

E il costo?

Qualche ora di sviluppo/customizzazione, il pay-as-you-grow del SaaS e il relativo servizio di assistenza.

VMware - Does corespersocket Affect Performance?

by Mark Achtemichuk

There is a lot of outdated information regarding the use of a vSphere feature that changes the presentation of logical processors for a virtual machine, into a specific socket and core configuration. This advanced setting is commonly known as corespersocket.
It was originally intended to address licensing issues where some operating systems had limitations on the number of sockets that could be used, but did not limit core count.
KB Reference: http://kb.vmware.com/kb/1010184
It’s often been said that this change of processor presentation does not affect performance, but it may impact performance by influencing the sizing and presentation of virtual NUMA to the guest operating system.
Reference Performance Best Practices for VMware vSphere 5.5 (page 44): http://www.vmware.com/pdf/Perf_Best_Practices_vSphere5.5.pdf

Recommended Practices

#1 When creating a virtual machine, by default, vSphere will create as many virtual sockets as you’ve requested vCPUs and the cores per socket is equal to one. I think of this configuration as “wide” and “flat.” This will enable vNUMA to select and present the best virtual NUMA topology to the guest operating system, which will be optimal on the underlying physical topology.
#2 When you must change the cores per socket though, commonly due to licensing constraints, ensure you mirror physical server’s NUMA topology. This is because when a virtual machine is no longer configured by default as “wide” and “flat,” vNUMA will not automatically pick the best NUMA configuration based on the physical server, but will instead honor your configuration – right or wrong – potentially leading to a topology mismatch that does affect performance.
To demonstrate this, the following experiment was performed. Special thanks to Seongbeom for this test and the results.

Test Bed

Dell R815 AMD Opteron 6174 based server with 4x physical sockets by 12x cores per processor = 48x logical processors.

The AMD Opteron 6174 (aka Magny-Cours) processor is essentially two 6 core Istanbul processors assembled into a single socket. This architecture means that each physical socket is actually two NUMA nodes. So this server actually has 8x NUMA nodes and not four, as some may incorrectly assume.
Within esxtop, we can validate the total number of physical NUMA nodes that vSphere detects.

Test VM Configuration #1 – 24 sockets by 1 core per socket (“Wide” and “Flat”)

Since this virtual machine requires 24 logical processors, vNUMA automatically creates the smallest topology to support this requirement being 24 cores, which means 2 physical sockets, and therefore a total of 4 physical NUMA nodes.
Within the Linux based virtual machine used for our testing, we can validate what vNUMA presented to the guest operating system by using: numactl –hardware

Next, we ran an in-house micro-benchmark, which exercises processors and memory. For this configuration we see a total execution time of 45 seconds.

Next let’s alter the virtual sockets and cores per socket of this virtual machine to generate another result for comparison.
Test VM Configuration #2 – 2 sockets by 12 cores per socket

In this configuration, while the virtual machine is still configured have a total of 24 logical processors, we manually intervened and configured 2 virtual sockets by 12 cores per socket. vNUMA will no longer automatically create the topology it thinks is best, but instead will respect this specific configuration and present only two virtual NUMA nodes as defined by our virtual socket count.
Within the Linux based virtual machine, we can validate what vNUMA presented to the guest operating system by using: numactl –hardware

Re-running the exact same micro-benchmark we get an execution time of 54 seconds.

This configuration, which resulted in a non-optimal virtual NUMA topology, incurred a 17% increase in execution time.
Test VM Configuration #3 – 1 socket by 24 cores per socket

In this configuration, while the virtual machine is again still configured have a total of 24 logical processors, we manually intervene and configured 1 virtual socket by 24 cores per socket. Again, vNUMA will no longer automatically create the topology it thinks is best, but instead will respect this specific configuration and present only one NUMA node as defined by our virtual socket count.
Within the Linux based virtual machine, we can validate what vNUMA presented to the guest operating system by using: numactl –hardware

Re-running the micro-benchmark one more time we get an execution time of 65 seconds.

This configuration, with yet a different non-optimal virtual NUMA topology, incurred a 31% increase in execution time.
To summarize, this test demonstrates that changing the corespersocket configuration of a virtual machine does indeed have an impact on performance in the case when the manually configured virtual NUMA topology does not optimally match the physical NUMA topology.

The Takeaway

Always spend a few minutes to understand your physical servers NUMA topology and leverage that when rightsizing your virtual machines.
Other Great References:
The CPU Scheduler in VMware vSphere 5.1
Check out VSCS4811 Extreme Performance Series: Monster Virtual Machines in VMworld Barcelona

This entry was posted in ESXi, Performance, vSphere and tagged corespersocket, Performance, vCPU on October 2, 2013 by Mark Achtemichuk.

Node Interleaving: Enable or Disable?

by Frank Denneman ·

There seems to be a lot of confusion about this BIOS setting, I receive lots of questions on whether to enable or disable Node interleaving. I guess the term “enable” make people think it some sort of performance enhancement. Unfortunately the opposite is true and it is strongly recommended to keep the default setting and leave Node Interleaving disabled.
Node interleaving option only on NUMA architectures
The node interleaving option exists on servers with a non-uniform memory access (NUMA) system architecture. The Intel Nehalem and AMD Opteron are both NUMA architectures. In a NUMA architecture multiple nodes exists. Each node contains a CPU and memory and is connected via a NUMA interconnect. A pCPU will use its onboard memory controller to access its own “local” memory and connects to the remaining “remote” memory via an interconnect. As a result of the different locations memory can exists, this system experiences “non-uniform” memory access time.
Node interleaving disabled equals NUMA
By using the default setting of Node Interleaving (disabled), the system will build a System Resource Allocation Table (SRAT). ESX uses the SRAT to understand which memory bank is local to a pCPU and tries* to allocate local memory to each vCPU of the virtual machine. By using local memory, the CPU can use its own memory controller and does not have to compete for access to the shared interconnect (bandwidth) and reduce the amount of hops to access memory (latency)

* If the local memory is full, ESX will resort in storing memory on remote memory because this will always be faster than swapping it out to disk.
Node interleaving enabled equals UMA
If Node interleaving is enabled, no SRAT will be built by the system and ESX will be unaware of the underlying physical architecture.

ESX will treat the server as a uniform memory access (UMA) system and perceives the available memory as one contiguous area. Introducing the possibility of storing memory pages in remote memory, forcing the pCPU to transfer data over the NUMA interconnect each time the virtual machine wants to access memory.
By leaving the setting Node Interleaving to disabled, ESX can use System Resource Allocation Table to the select the most optimal placement of memory pages for the virtual machines. Therefore it’s recommended to leave this setting to disabled even when it does sound that you are preventing the system to run more optimally.
Get notification of these blogs postings and more DRS and Storage DRS information by following me on Twitter: @frankdenneman

Excursus sul Mail-Archiving

Prima di addentrarci nei tecnicismi occorre comprendere la sostanziale differenza tra backup di un dato e archiviazione di una mail.

Il backup è una "copia" dei dati in un preciso momento al fine di consentirne il ripristino in situazioni di perdita causata da errori, guasti, ecc... Questa procedura consente il ripristino dei dati, ad esempio, di un ambiente virtuale e/o server fisico aggiornati ad un determinato momento.

L'archiviazione è la memorizzazione e conservazione a lungo termine dei messaggi e-mail. Questa procedura consente di recuperare le singole mail e allegati nel caso in cui il server mail sia irrecuperabile, l'utente abbia perso il proprio archivio personale o abbia erroneamente cancellato una o più mail.

Quali sono le principali caratteristiche che deve avere un servizio di mail-archiving?

1) Ridurre i requisiti di storage del server mail senza intaccare la  produttività degli utenti

La possibilità di spostare le e-mail storiche, allegati compresi, dal server di posta al mail-archiver alleggerisce il server stesso migliorandone le prestazioni e la scalabilità.
Molte soluzioni offrono inoltre un accesso web, tramite app o plug-in di client di posta migliorando l'accesso al servizio senza intaccare la granularità delle mail.  
 

2) Rispetto dei requisiti di legge e tutela in caso di controversie giuridiche
Le imprese si trovano ad affrontare la sfida posta dal crescente numero di normative sulla conformità della posta elettronica, eDiscovery e altri regolamenti.

L'archiviazione delle email consente alle aziende di tutelarsi contro i rischi legali generici. L'archiviazione delle email permette infatti di utilizzare la posta elettronica come prova durante procedimenti giudiziari e consente che i reclami da parte dei clienti siano trattati con maggiori informazioni disponibili fin dall'inizio.


3) Riduzione del rischio

E' importante avere la tranquillità di sapere che le e-mail archiviate sono "autentiche" e non sono state manomesse da alcuno.

Gartner stima che più del 40% dei messaggi di posta elettronica di un’organizzazione siano di grande valore, in quanto legate a un progetto, un’iniziativa o considerate un atto pubblico. È fondamentale proteggere questo "bene", non solo per preservare la conoscenza istituzionale contro il turnover aziendale, ma per garantire che le email non possano essere accidentalmente (o deliberatamente) eliminate dai dipendenti.    



4) Funzioni di ricerca avanzata

E' importante avere la possibilità di ricercare le mail tramite criteri di ricerca multi-tier e filtri come ad esempio "parole chiave", wildcards,  tags, contenuti della mail, ecc..
Maggiore è la granularità di ricerca più efficente sarà la ricerca stessa e l'eventuale possibilità di salvare le ricerche migliora l'efficacia delle successive analisi.


5) Risparmio economico

Grazie allo spostamento delle e-mail storiche nell’archivio e-mail si otterrà l' aumento delle prestazioni del server di posta elettronica, la riduzione dei requisiti di memorizzazione (anche tramite strumenti di compressione e deduplica) con l'effetto di ridurre dei costi .
Altra primaria conseguenza è che otterremo una sostanziale riduzione dei tempi di backup e di ripristino del server stesso.



Oggi esistono moltissimi software e appliance che assolvono tali funzioni ma, come spesso accade, non esiste la soluzione definitiva che vada bene per tutti.

Occorre quindi valutare bene il prodotto partendo dalle proprie necessità e facendosi consigliare da esperti nel settore.


Marco C.

Perchè dovrei "mettere in piedi" un Datacenter?

Bella domanda...

Per trovare la risposta, innanzitutto, comincerei col cercare di descrivere cos'è un Datacenter...( e per i meno tecnologici, a cosa serve..)

Nel senso più generale del termine si intende un ambiente sufficientemente ampio, convenientemente condizionato, adeguatamente alimentato e proporzionatamente sicuro per contenere apparecchiature e sistemi atti al rendere disponibili dati e/o informazioni.

Le apparecchiature e i sistemi possono essere riassunti in equipaggiamenti, tecnologie e applicazioni idonee a supportare servizi intranet/internet, business service e altre soluzioni.

Il DC deve inoltre garantire la business continuity, le applicazioni critiche e deve essere una soluzione flessibile per essere in grado di gestire le future richieste proteggendo l'investimento.

Ora vediamone le origini:

Negli anni 90 avevamo una soluzione centralizzata riscontrabile nei mainframe, macchinoni enorrrrrrrrrrrrrrmi che contenevano tutti i dati e vari terminali "a bassa intelligenza" che usufruivano delle informazioni.

Col progressivo diminuire del costo dei componenti, verso la fine del secolo scorso, si è passati ad acquistare un PC per ogni utente e un SERVER per ciascun servizio aziendale (posta, web, db, ambiente di test, ecc...). Questo ha portato al cosidetto server sprawling, ovvero ad avere, in talune situazioni,  un numero di server superiore al numero di dipendenti...

I difetti di questa soluzione erano vari; la perdita di tutti i dati contenuti nel pc dell’utente in caso di guasto, il costo dell' energia elettrica per alimentare tutti i server, il relativo condizionamento, ecc...

Il passaggio successivo, determinato dalla sempre maggior potenza di calcolo delle CPU e dalla adeguata tecnologia, è stato quello di consolidare, ovvero unificare varie risorse e virtualizzarle. Tutto ciò si traduce con l’ "avvento” delle cosidette VirtualMachine: i vari servizi vengono appunto “virtualizzati” all’interno di server (appliance o blade che siano) ben carrozzati.

e ora?
ora, stiamo uscendo dalla fase di CONSOLIDATION per entrare nel CLOUD...
ma non rilassatevi..
nei peggiori bar di Caracas si sta già parlando di FOG


Come lo si progetta un Datacenter?
Uno tra i vendor più famosi al mondo ha creato un calzante acronimo

PPDIOO (sembra un'offesa ma vi assicuro che non lo è..)

Ovvero:
PREPARE - ascoltare per bene le necessità del cliente e cercare di capire con quale soluzione posso migliorare il suo business. Nel caso in cui fosse già dotato di un DC è opportuno un site survey ed un assessment cercando di raccoglere tutte le informazioni possibili.

PLAN - sulla base delle informazioni ricevute e ricavate si può creare e pianificare il datacenter tenendo conto di molteplici aspetti, tra cui le tempistiche di delivery, programmazione, deployment ed eventualmente della corretta integrazione della soluzione all'interno del DC già presente.
Nella fase di studio vanno tenuti in considerazione due aspetti fondamentali..
n.b. Qui introduciamo due concetti rivoluzionari :-)

Il primo detto anche LAYER 8 della scala ISO-OSI:

IL BUDGET
tradotto in:
è inutile progettare un datacenter da mille e una notte se il cliente ha due soldi...non lo comprerà mai...

Il secondo è chiamato LAYER 9 della scala ISO-OSI:

LE POLICY-POLITICS
in Italia è tradotto in:
è inutile che prevedo di fornire dispositivi del vendor A quando per politica aziendale nella azienda X installano solo apparati del vendor B, come è altrettanto inutile prevedere dispositivi del vendor A quando il cugino (ad esempio..) del CEO della azienda X è uno dei capi (o simil posizione) del vendor B
Concordate?

DESIGN - Identificare le necessità del cliente (verificando anche come si muovono i suoi concorrenti), caratterizzare la rete del cliente, eseguire due tipologie di disegno, una versione High Level ( architettura concettuale) e una Low Level (entro nel dettaglio dei dispositivi hardware e software), si crea la BOM ovvero la "lista della spesa"e si vanno a descrivere nel dettaglio i requisiti.

IMPLEMENT - ovvero l'installazione di quanto proposto e fornito

OPERATE - si verifica che quello che è stato implementato funzioni correttamente e come previsto, monitorandolo con appositi tool.

OPTIMIZE - poichè la perfezione non esiste, in questa fase vengono apportate le dovute correzioni al sistema.

Fin qui tutto bene..ma...non abbiamo ancora risposto alla fatidica domanda...

Perchè dovrei mettere in piedi un datacenter?

ovvio...

PER ACCELERARE IL MIO BUSINESS

E come posso accelerare il mio business spendendo soldi, in un periodo di vacche magre, dove è faticoso reperire finanziamenti, ecc..ecc... ?

La maggior parte delle persone è portata a pensare che spendere poco nell'acquisto ( il famosissimo CapEx ) sia vantaggioso...

Eh...NO...NIENTE DI PIU' ERRATO...

Durante un acquisto bisogna sempre spendere IL GIUSTO.
Non un euro in più, non un euro in meno, tenendo conto del fatto che il costo più elevato l'avrete nelle spese di mantenimento ( il meno famoso OpEx), negli oneri di gestione, nel deploy di nuove applicazioni e nella creazione di ambienti di test, ecc...

come gestire tutto ciò?
esiste una risposta che vada bene per tutti?

secondo me ...
NO...
O almeno io non ce l'ho..

Ritengo non esista una soluzione giusta per tutti in quanto ho sempre pensato che sia come farsi fare un vestito dal sarto, ognuno ha le sue "misure" ( o meglio ed in gergo meramente tecnico "ognuno porta le sue mutande" ), ciascuno ha le proprie necessità e desideri.


Marco Carini