Boot On San

Introduzione

Sto cercando di valutare se sia il caso di effettuare il boot o san on meno. La prima volta che se ne è parlato devo dire che non ho avuto una buona impressione.

wiki di itknowledgeexchange

C'è un articolo qui dove descrive vantaggi e svantaggi.

Vantaggi

  1. Si possono creare gli snapshot delle installazioni delle esxi. In questo modo se si devono installare molti server esxi si hanno tutti i vantaggi di usare le snapshot per creare nuovi server. Il fatto che di server esxi se ne fanno pochi, sono le macchine virtuali che vengono create spesso. Inoltre un server esxi si installa in un attimo. Non mi sembra un gran vantaggio
  2. la guida parla di applicare degli aggiornamenti su una immagine e replicarla sulle altre ma anche qui mi sa che è solo per macchine spente e per snapshot non per istanze accese. Vantaggi di questa cosa veramente esigui.
  3. si risparmiano gli hard disk, perchè con gli stessi hd ci metti gli esxi e le macchine virtuali.
  4. gli hard disk hanno la protezione che fornisce la san. Ci sono funzionalità avanzate che fornisce una san che possono essere applicate.

Svantaggi

  1. molto più complesso fare il boot on san rispetto a quello di hard drive per gli hard disk
  2. ci possono essere problemi di compatibilità per il boot la guida si riferisce a versioni vecchie di vmware quindi secondo me con sistemi recenti non ci saranno problemi

consulenti-ict.it

Quest'articolo invece mi ha convinto un po' di più.

L'articolo parla di boot on san generico a me interessa la parte di vmware dove alcuni di questi vantaggi si annullano però comunque alcuni rimangono.

Riporto la parte più interessante dell'articolo.

Invece di 3 HD da 146/300 GB (2 in mirror e magari 1 di spare), quando comunque il s.o. non occupava mai piu’ di una ventina di GB? ESXi

Bene, ci siamo risparmiati 3 dischi ed il relativo controller RAID, una bella sgomitata al TCO, oltre che al minor costo iniziale di acquisto, considerando la razionalizzazione dello spazio disco utilizzato, ed i minori consumi elettrici diretti ed indiretti.

C’e’ da tener conto che la semplificazione dell’hardware conduce ad una riduzione dei disservizi per rotture di componenti.

Se la S di SAN è uno storage moderno, le sue funzionalità saranno ancora più di ausilio nella gestione della infrastruttura.

Debbo installare una patch critica al s.o.?

Una bella snapshot del volume contenente il s.o. e passa la paura: se la patch si rivela più un problema che un rimedio si può tornare al sistema operativo fotografato appena prima della applicazione della patch.

Posso utilizzare le snapshot come primo livello di backup dei miei server e costruire soluzioni di Disaster Recovery ’spedendole’ ad uno storage nel sito remoto.

Debbo installare un nuovo server con un sistema operativo già presente nella mia server farm?

Se lo storage mi permette di clonare i volumi, ed il mio nuovo server non è troppo diverso da quello che ospita il s.o. già presente, in pochi click sarò pronto per avere una copia del S.O. da un template.

Così facile che sembra di parlare di virtualizzazione.

Già, svincolando l’hardware dal sistema operativo, in caso di rottura irreparabile di un server potrò sostituirlo in pochi minuti senza richiedere re-installazione.

Non dimentichiamo che altre funzionalità garantite da ogni storage moderno quali il thin provisioning e la deduplica concorrono al risparmio di risorse, ai minori consumi ed ad una semplificazione della gestione.

Confronto esxi e esx 4.0

Riporto testualmente da quest'articolo della kb di vmware VMware ESX and ESXi 4.0 Comparison

The installable version of VMware ESXi does not support booting from SAN.

Invece in un articolo della comunity dice che è supportata

Supportato il boot on san su esxi 4.1 update 1

Quest'articolo della comunities dichiara in maniera non chiarissima che invece è supportato il boot. Mi sa utilizzando delle pennine usb

Anche quest'altra nota di aggiornamento alla versione 4.1 diche che il boot su hardware certificato è supportato

Boot from SAN. vSphere 4.1 enables ESXi boot from SAN (BFN). iSCSI, FCoE, and Fibre Channel boot are supported. Refer to the Hardware Compatibility Guide for the latest list of NICs and Converged Adapters that are supported with iSCSI boot. See the iSCSI SAN Configuration Guide and the Fibre Channel SAN Configuration Guide.

vrefernce.com

Questo articolo parla in maniera più in generale di tutti i tipi di installazione di esxi.

Esxi può essere installata come diskless or diskful , e configurata come stateless o stateful. Questo però può portare a fraintendimenti e interpretazioni aperte quindi bisogna capire un po' meglio il backgroud.
Ci sono tre directory che si ha bisogno di decidere per la memorizzazione

  • bootbank: è l'immagine di boot ??? along with the vendor drivers and CIM providers ???
  • locker: questa è dove sono mantenute il vSphere client e i vmware tools e altre cose non essenziali
  • scratch : per lo stato dell'archivio (configuration settings), logs, core dumps, diagnostic bundles.

Il fatto che una esxi sia diskless or diskful e stateless o stateful dipende da dove questi archivi vengono memorizzati.
Quando l'esxi viene eseguita carica l'intera immagine di esecuzione in ram. Usa una combinazione di tardisk, che sono di dimensione fissa e comprendono file statici, e di ramdisk che possono crescere e ridimensionarsi alla richiesta. In aggiunta alla ram si può opzionalmente dischi per il boot, e partizioni scratch di 4 GB VFAT che possono essere affiancati come dischi di boot e memorizzati remotamente.

Un server stateles non significa che il server non ha configurazioni e diskless non vuol dire che non ha dischi. Quindi

  • diskless: esxi ha un solo disco in read-only dopo che il boot è stato compiuto
  • diskful: esxi ha un disco scrivibile dopo che è stato fatto il boot
  • stateless: esxi non mantiene lo stato in maniera attiva tra i reboot
  • stateful: esxi mantiene lo stato tra i boots

Per fare chiarezza diskless non significa necessariamente che il server non ha spinning disks.
Esxi considera il boot-from-SAN, boot-from-USB key/SD card as a diskful.
Un server stateless non significa che non ha nessuna configurazione ma che lo memorizza in una zona volatile e non è responsabile per ricaricarla al boot.

Diskless e staless sono le opzioni nuove nelle installazioni classiche si usa diskful stateful.

  • Diskless: avviene qualcosa di simile al PXE il boot via network. Con la differenza che il PXE fa il caricamento tramite network e poi installa nella macchina. Invece il server boota le immagini direttamente in ram, quindi è facile fare aggiornamenti/rimpiazzamenti facendo un reboot. Se un server diskless è configurato anche come stateles, userà 4 GB di ram per una partizione ramdisk-based scratch. Questo mangia però 4 GB di ram e può essere evitato con una partizione stateful scratch creato su un volume remoto vmfs o nfs. Un vantaggio di avere un diskful server è memorizzare due copie della directory di bootbank ma montarne solo una di loro. La copia offline può essere usata per fare il boot se ci sono problemi con la versione live.
  • Stateless: a un primo sguardo avere un server che può perdere le sue configurazioni dopo un reboot sembra sciocco. La ragione è permettere un uso centralizzato dell'autorità di configurazione. Un tool può fare il push delle configurazioni a tutti gli hosts. In questo modo si può applicare la modifica a livello centralizzato e viene ripetuto su tutti gli hosts. Quello che si perde al reboot sono i logs e i vmcore se non si configura un syslog esterno.

Un diskless server è stateless per default. Ma se si configura un diskful server come stateless (può scrivere sul boot device, ma usa una partizione volatile di scratch) salverà lo stato dell'archivio sul disco di boot ogni 10 minuti. I dischi usb sono i maggiori candidati per questo dipo di setup. L'impatto in questa soluzione è che si perdono i logs e i core dumps (come per tutte le configurazioni stateless), e le configurazioni di startup possono essere differenti per le configurazioni di running. Potenzialmente ogni configurazione fatta negli ultimi 10 minuti può andare persa. Un server stateless può avere lo stato persistente tra i reboot se è diskful perchè copia le info periodicamente.

Quindi a cosa si deve prestare attenzione.

Now usually, unless you plan to run ESXi as diskless, stateless or both, you are most likely to install it and not think about it, assuming it to be both stateful and diskful. Per mantenere lo stato tra i boots salvare i logs e i dump localmente e caricare il s.o. fra un'immagine usb/sd card. Questa frase non si capisce a quale tipo di configurazione si riferisce.

Si può reindirizzare la partizione di scrath a un volume esterno di vmfs o nfs.

Salvo diversa indicazione, il contenuto di questa pagina è sotto licenza Creative Commons Attribution-ShareAlike 3.0 License