[Linuxtrent] Re: Consiglio Cluster Proxmox su Fibre Channel
- From: Gianni Caldonazzi <gianni.caldonazzi@xxxxxxxxx>
- To: linuxtrent@xxxxxxxxxxxxx
- Date: Wed, 18 Apr 2012 09:45:56 +0200
Ho timore "reverenziale" nel rispondere, vista la preparazione di ZipMan... :-),
ma come ha detto Roberto: "Cerchiamo di imparare dall'esperienza di tutti".
Beh questo me lo ha detto a voce....
Il 18 aprile 2012 08:44, Roberto Resoli <roberto.resoli@xxxxxxxxx> ha scritto:
> Il 18 aprile 2012 01:25, Flavio Visentin <THe_ZiPMaN@xxxxxxxxx> ha scritto:
>> On 04/17/2012 09:04 PM, Francesco Gabriele wrote:
>>> Forse mi sono spiegato male lo storage è in fibra ottica, io l'ultima
>>> volta che ho fatto un cluster con hardware simile ho usato proxmox 1.9 e
>>> come filesystem condiviso OCFS2 (di solito lo uso su i cluster oracle)
>>> Volevo sapere voi di solito che filesystem condiviso consigliate per una
>>> config del genere.
>>
>> Nessun filesystem condiviso.
[...]
Tutto ciò che ho tagliato è valido, aggiungo solo che tu crei su SAN
il Logical Volume (block device) e lo dai in pasto a tutti i nodi del
cluster PVE.
Va ora configurato il multipath e riletta la catena scsi, per ogni nodo.
Poi creato, io lo faccio dal master node, il PV con il nuovo VG e a
questo punto va presentato a proxmox come contenitore LVM per le
virtual machine.
>> Tutto funziona out-of-the-box con proxmox; è importante però che
>> configuri correttamente il fencing dei nodi, e nel tuo caso lo puoi fare
>> attraverso la ILO dei server che ti consiglio vivamente di connettere ad
>> uno switch dedicato (cerca "proxmox ilo fence" su google e trovi un
>> howto in proposito).
>>
Questo me lo devo leggere. Ho trovato un sacco di link, se passi
appena puoi quello che intendi meglio ancora.
>> Un altro consiglio che ti do, ma questo è valido in generale, è di porre
>> attenzione a come configuri lo storage. Una corretta configurazione può
>> migliorare le performance (anche raddoppiarle) senza alcun costo aggiuntivo.
>>
>> In particolare:
>>
>> - se usi raid 5 crea volumi da 5 dischi (4+1) o da 9 dischi (8+1) per
>> ottimizzare l'accesso ed ottenere un full-stripe-access. 5 dischi sono
>> preferibili in quanto la ricostruzione è più veloce in caso di guasto di
>> un disco, e le probabilità di rottura di un secondo disco non sono
>> nulle. Se usi il raid 10 crealo con 4, 8 o 16 dischi sempre per
>> ottimizzare l'accesso. Il full stripe access permette di guadagnare fino
>> al 20% in alcuni scenari.
>
> Naturalmente questo dipende dal tipo di storage che utilizzi; sulla EVA 4400
> che usiamo qui la gestione del raid è diversa, non categorizzabile con
> i livelli classici.
> Non so se sia lo stesso per MSA 2000.
>
Credo di ricordare che anche in MSA1000 la gestione degli array disco
era trasparente per gli host. Era solo più rigida la configurazione
dei Volumi Logici.
>> - Crea sempre almeno due array distinti, e se puoi sempre in numero
>> pari, in modo che siano assegnati ad entrambi i controller. Dato che un
>> array è gestito sempre da un solo controller per volta in questo modo
>> bilanci il carico di lavoro e aumentano le performance. In particolare
>> ti raddoppia la banda disponibile verso gli host e sfrutti la cache di
>> entrambi i controller.
>
Mi ricordo che su MSA1000 i due controller erano Attivo-Passivo, non
so se nella sua evoluzione entrambi i controller siano attivi.
> Ulteriori considerazioni si possono fare sulla configurazione del
> multipath/failover
> lato host (di solito di usano almeno due host bus adapter).
> Purtroppo non abbiamo esperienza su MSA 2000 (abbiamo avuto MSA 1000
> in passato, ma mai con dischi presentati a macchine linux).
>
Anche in questo caso la configurazione multipath cambia se è attivo-passivo.
Se non ricordo male quando un host cambiava percorso rendeva attivo
l'altro controller e costringeva tutti gli host a cambiare hba.
>>
>> - Tenta di distribuire l'accesso agli array in modo uniforme,
>> distribuendo i volumi delle VM sui vari array e le macchine tra i vari
>> host in modo da ridurre i conflitti di accesso. Se per esempio hai due
>> DB con un pattern di utilizzo analogo mettine uno su un array e uno
>> sull'altro in modo che non si contendano l'accesso all'array.
>
> Si, il numero di array (in terminologia EVA sono i "Virtual Disks") va
> valutato
> per ottimizzare le prestazioni; noi tendiamo a creare un solo VG (cioè
> storage PVE) per
> ogni disco SAN, e poi ad usarlo per non più di 3 macchine virtuali,
> lasciando un po'di spazio per le
> snapshots. Probabilmente questo condice ad un numero di dischi SAN
> troppo elevato; se ci sono consigli,
> sono bene accetti!
>
La mia pensata è stata di mettere tre vm-LV su ogni VG, perchè abbiamo tre nodi.
Vorrei distribuire l'accesso al VG in contemporanea sui tre HBA
diversi dei virtualizzatori.
Per problemi contingenti dovuti alla gestione dei backup, per ora
abbiamo assegnato le tre vm di uno stesso VG allo stesso nodo.
>> - Accertati che lo zoning degli switch FC sia fatto correttamente, con
>> zone che includono unicamente il WWN della scheda di un host e i WWN dei
>> due controller ad essa connessi. Uno zoning fatto male può ridurre le
>> perfomance sensibilmente in certi contesti.
>
> Questo coincide con la regola di base che è stata insegnata anche a
> noi; includere una zona
> solo gli endpoint minimi che debbono vedersi. Dato che nella nostra
> architettura abbiamo anche
> gli switch fibra, anche le porte di questi entrano nel gioco.
>
Qui c'è una imprecisione, ma solo perchè le zone le ho fatte io e
Roberto le ha viste poco, poi non mi lascia nemmeno il tempo di
scrivere.... :-D
Lo zoning è come se creassi delle VLAN, forse abbiamo tutti più
dimestichezza a capire questo parallelo.
La zona va creata assegnando le porte dello switch a cui sono
collegati i controller della SAN e l'HBA dell'host.
Vanno create più zone per compiti specifici, esempio:
Ho una SAN, un host per i salvataggi e una libreria nastri fibra per
salvare su cassetta.
Posso creare due zone distinte:
1. SAN+host
2. host+libreria
Quindi ogni host collegato alla SAN avrà la sua zona distinta.
Jan
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx
Other related posts:
