Nuovo server Lotus Domino su Linux e LVM

[Shinobi]

Ciao ragazzi, in azienda stiamo implementando un nuovo server Lotus Domino su Linux e avrei scelto di gestire lo storage con LVM visti tutti i vantaggi annessi, avrei bisogno però di un vostro consiglio visto che non ho molta esperienza con esso.

Premetto che la vm sarà installata su Vmware 5.1 e che le aree di storage principali saranno principalmente 4:

1)La root / su cui installeremo il sistema operativo (Suse server)
2)Lo storage che conterrà lo swap
3)Lo storage che conterrà l'installazione vera e propria di Lotus Domino (che sarà grande circa 500gb e che verrà montata su /lotus
4)Lo storage che conterrà i transaction log di Domino e che verrà montata su /lotustrlogs

Per quanto riguarda le prime 3 utilizzerò un datastore vmware in raid5 mentre per l'ultimo verrà utilizzato un datastore con storage in raid 10.
Il problema ora è come pensare a implementare il tutto in lvm:

-Credete che sia meglio mettere le prime 3 aree in un unico disco virtuale vmdk appartenente al datastore in Raid5, creare poi un VolumeGroup1 e fare poi 3 volumi logici oppure è meglio fare un disco virtuale vmdk per ogni area? In questo secondo caso però sarei costretto (credo) a fare un VG per ogni disco visto che facendone uno comune non vedo vantaggi rispetto alla situazione in cui partirei con un unico virtual disk.
-Per quanto riguarda lo spazio che verrà montato nel datastore in Raid10 essendo su lun diversa e completamente separato potrei creare il disco vmdk, fare un secondo volume group e poi creare al suo interno il disco logico da montare su /lotustrlogs

Avete consigli e/o suggerimenti?

Grazie

[Maui78]

Ciao
Provi a risponderti io, con nozioni puramente teoriche,visto che non conosco così approfonditamente vmware ne linux, ne tantomeno lotus, la cui ultima installazione risale ad almeno 7-8 anni fa.
Personalmente, dando per scontato l'utilizzo dell'lvm, separerei sicuramente la parte dati dall'installazione del sistema operativo. Quella del motore lotus non la reputo così fondamentale. Ne tantomeno poggerei lo swap in un'area dedicata (se abbondi di ram, probabilmente lo swap verrà usato meno che niente). Piuttosto verifica come configurare il sistema in modo da usare lo swap il meno possibile.
In definitiva, 2 volume group distinti:
SO + swap + motore lotus
Dati ed eventualmente log
Questo ti consentirà, a livello di sistema operativo di monitorare meglio le risorse.
Ovviamente, se invece che 2 vg ne crei 4 e separi tutto, non succede nulla di male. In azienda abbiamo server con decine di volume group, il problema lo crei quando restringi, non quando allarghi il numero. L'unico problema in questo caso può essere legato a uno spreco di spazio.
Lato vmware, la logica del datastore dovrebbe essere quella di fare da contenitore per più vm. Nel tuo caso, se usi una san, crearne di diversi, ti riporterà al discorso di cui sopra, cioè un monitoraggio più puntuale nel caso di i/o intensa.

In generale, comuque, mi sento di tranquillizzarti circa la tua scelta. L'una è preferibile all'altra, ma nessuna delle due farà da discriminante a un funzionamento eccelso o pessimo. Se ci saranno comportamenti anomali, sarà probabilmente per problemi software, non certo per come hai separato le unità.

PS: non so su linux come si fa, in ogni caso su altri sistemi su cui normalmente lavoro, è possibile configurare il numero massimo di i/o contemporanee che la lun può ricevere. Il parametro ha normalmente un default basso, ma è quello che realmente fa la differenza in un sistema stressato. Vediamo se passa qualcuno a dirci su suse come si chiama....ammesso esista.


Ciao


EDIT queue depth è il parametro di cui sopra....sembra si chiami così anche sulla suse.

[Tasslehoff]

Ciao, LVM è abbastanza semplice (parte della sua genialità sta anche in questo) in soldoni utilizza 3 oggetti: PV, VG e LV.
Partendo dai dispositivi di storage (/dev/sdX, nel tuo caso i vmdk di Vmware) o da partizioni di essi (/dev/sdXn) crei dei Physical Volumes (PV), utilizzando i PV crei i Volume Groups (VG) che di fatto sono simili a degli storage pools.
Sfruttando lo storage a disposizione in un VG crei dei Logical Volumes (LV), che sono i device su cui poi creerai i filesystem e che monterai nei percorsi che ti serviranno.

In uno scenario del genere io piazzerei root, partizione di boot e swap su sullo stesso volume group (chiamiamolo vgroot per comodità), e su questo VG piazzerei anche la directory con i binari di Domino (durante il setup ti chiederà due differenti percorsi per binari e per la Domino data directory)
Non starei nemmeno a fare il LV dedicato ai binari di Domino dato che non cresceranno quasi mai (solo durante l'installazione di Fixpack, Interim Fix o Language packs, quindi raramente e in misura scarsamente significativa) ma li piazzerei direttamente nel LV della root.
Per lo swap non esagerare, idealmente il sistema non dovrà mai arrivare a fare thrashing (in quel caso diventerà totalmente insusabile), lo swap ti servirà giusto per un po' di swappiness da parte del kernel.
Separare questi LV su differenti VG (e quindi differenti PV) io lo vedo ininfluente per le performance (dato che tutti i PV insisterebbero sullo stesso array fisico rappresentato dal datastore vmware) in questo scenario; teoricamente potrebbe essere utile in futuro in caso di modifica allo storage, trattandosi però di aree di storage a basso impatto prestazionale io scarterei a priori questa possibilità e lascerei tutto su un unico VG.

Sul secondo datastore sull'array raid 10 invece io piazzerei Domino data directory, Domino tranlogs e indici fulltext di Domino (dalla versione 8.5.3 puoi usare il parametro del notes.ini FTBasePath per definire un percorso in cui stiano tutti gli indici fulltext anzichè nelle solite directory .ft poste a livello degli nsf).
Consiglio differenti VG per ciascuno (quindi differenti PV), in questo modo se ti dovessi accorgere che l'array è troppo sollecitato puoi spostare comodamente i vmdk da un datastore all'altro per bilanciare il carico).

Come distribuire il carico dipende tutto dall'utilizzo che farete degli nsf, da che viste ci sono e come vengono refreshate o che fanno gli agenti (quindi I/O sbilanciato sulla data directory), elevato numero di modifiche ai documenti (quindi I/O sbilanciato sui tranlog), tanti indici fulltext con magari allegati e un elevato numero di modifiche (quindi I/O sbilanciato sugli indici fulltext).
Insomma gli scenari sono vari, dato che Domino poi è un prodotto così polivalente è anche difficile fare una previsione a priori.

Un consiglio che ti do è di non creare PV troppo grandi (in modo da rendere eventuali operazioni di manutenzione o spostamenti più snelli), e soprattutto di non usare tutto lo spazio dentro i VG.
Creati LV delle misure giuste (es per OS, boot e binari di Domino 15GB bastano e avanzano) e parti sempre dal presupposto che ingrandire i LV è facile e indolore (si fa a caldo con lvextend seguito poi da resize a caldo del filesystem), ridurli invece è sempre potenzialmente rischioso e sicuramente laborioso.
Tenersi i VG con sempre un po' di spazio libero è anche una buona cosa perchè ti permette di usare comodamente gli snapshot, che sono una gran bella feature di LVM.

Io molto spesso ho molto più spazio free nei VG di quello allocato sui vari LV, non è l'assegnazione di tanto spazio a metterti al sicuro dalla saturazione dei volumi ma il monitoraggio.
Al contrario una volta che hai assegnato tutto lo spazio e devi recuperarlo son dolori di panza, o per lo meno fastidi, down etc etc...

[dennyv]

Originariamente inviato da Tasslehoff

...

Ecco questo post meriterebbe di essere messo in evidenza! Ottima sintesi su LVM.

Hai valutato anche su quale filesystem appoggiarti? XFS, Ext4?

[Tasslehoff]

Originariamente inviato da dennyv

Ecco questo post meriterebbe di essere messo in evidenza! Ottima sintesi su LVM.

Hai valutato anche su quale filesystem appoggiarti? XFS, Ext4?

Ti ringrazio
In merito al filesystem io suggerirei XFS per la data directory (relativamente pochi files in genere di grosse dimensioni, dato che contengono tutto, binari, documenti, agenti, form etc...) mentre userei EXT4 per tranlog, directory con gli indici fulltext e il resto (OS e binari).

[Shinobi]

Cavoli ragazzi avete scritto una bibbia, grazie a tutti!
Sicuramente ci sono tantissime informazioni utili, ora c'è da rimboccarsi le maniche e fare il setup del server