Newsgroup: it.comp.os.linux.sys
Titolo: Ancora Xen &HA

Come avrete notato, questa è l'ora degli esperimenti teorici e delle
s&ghe mentali :D
Supponendo di avere un nodo xen senza storage condiviso, come posso
creare due VM con dentro apache e pescare i dati da un terzo posto?
Quello che vorrei ottenere è la possibilità di migarre i domini da una
VM all'altra senza dover spostare i dati.
Praticamente solo ricaricare la config di apache. Mi permetterebbe di
fare manutenzione ad una VM senza nascondere i siti in essa contenuti.
Pensavo ad una terza VM con NFS che esporti i dati presenti su un
volume LVM (tutto in locale per il momento).
Così facendo però mi ritroverei con un NFS che deve esportare un
volume con all'interno mille mila domini.
E' consigliabile?
Che sia il caso di suddividere X domini su Y volumi LVM? Se devo
spegnere la VM1, potrei montare tale volume sul secondo nodo. Però
così facendo avrei due problemi:
1) devo obbligatoriamente spostare tutti i siti del nodo 1 sul nodo 2
(ovvero tutto il volume), non posso fare migrazioni selettive
2) sul nodo2 dovrei montare il secondo volume LVM in una posizione
differente dal primo. ad esempio uno in /www e l'altro in /www2. Un
bel casino!
Usando nfs, non devo fare assolutamente nulla, solo spostare la config
di apache da una VS all'altra (e per come son strutturato io
attualmente, devo solo cambiare 1 ip nel database)
Tutto questo assurdo casino deve essere fatto in previsione di:
1) SAN
2) secondo nodo su cui suddividere i server (web1 nodo1, web2 nodo2,
web3 nodo1, web4 nodo2 e così via)
Forse la soluzione con nfs è la più rapida ed indolore, quando avrò
uno storage condiviso, bastarà far pescare i dati da san anzichè da
locale, e devo solo riconfigurare il nodo nfs. (che potrà essere
ridondato, bla bla bla).
Inoltre, mi permette di fare anche un cluster di bilanciamento, con
vari nodi apache che leggono gli stessi domini dallo stesso NFS
Non mi convince il fatto di esportare 10k domini tutti in una volta.
Se però mi dite che è "normale", no problem, anche perchè non vedo
soluzioni alternative.
Altro problema con NFS: se avessi il server FTP su una macchina
differente da quella di apache? Come gestisce NFS le letture da 1 nodo
(apache) e le scritture da un altro (ftp) in simultanea? Riesce a
farlo? Il problema è solo con doppia scrittura?

 E' consigliabile?
seghe mentali sKDJ930fj99032qra BUFFER OVERFLOW!
sinceramente, mi sembra una valanga di seghe mentali.
se metti tutte le vm su un nodo fisico solo non ha senso

 se metti tutte le vm su un nodo fisico solo non ha senso
In parte hai ragione.
Configurare due VM sullo stesso nodo fisico ha 1 vantaggio: se devo
fare manutenzione ad una VM, mi basta semplicemente
migrare le configurazioni di apache dalla vecchia VM alla nuova.
Nessuna interruzione di servizio e potrei spegnere benissimo
la vecchia VM. (ad esempio metti che devo fare un upgrade di apache o
del kernel, migro tutto, lavoro, poi rimetto tutto a posto)
Per fare questo, le due VM devono poter pescare i dati dallo stesso
posto, e da qui salta fuori l'idea di una VM con NFS.
Inoltre, la struttura attuale è temporanea, ci sarà (spero a breve)
una SAN. Ovvero: intanto strutturo tutte le VM facendole già
predisposte a pescare i dati da storage condivisi, così appena arriva
la SAN devo solo fare qualche piccolo cambiamento ma
la baracca già funziona.
Fare senza storage condiviso (anche se sullo stesso nodo) non mi
permetterebbe ne di migrare i domini al volo, ne di spostare tutto
su SAN in maniera quasi indolore: dovrei ristrutturare varie cose.
Diciamo che voglio fare la predisposizione, in modo da dover lavorare
il meno possibile in futuro.
(non mi sembra tanto strana una soluzione con doppia VM apache + VM
NFS anche se tutto sta sullo stesso nodo fisico)

 creare due VM con dentro apache e pescare i dati da un terzo posto?
E se ti facessi una SAN con un target iSCSI Linux? (FreeNAS sarebbe 
OT).
Non ho mai usato una simile configurazione in produzione per roba 
seria,
ma magari qualcuno qui ha qualche esperienza in piu'.
... e saresti anche pronto a migrare al volo quando arrivera' la SAN 
:-)
Ciao
Fabio

 ... e saresti anche pronto a migrare al volo quando arrivera' la SAN
Benissimo, quindi installo OpenFiler in una VM ad-hoc.
Ma (e tra un po sia Skull che Zipman mi menano) io non ho capito
se posso condividere una LUN tra due VM differenti.
Ovvero: se voglio fare la VM1 con X siti e la VM2 con Y siti, entrambi
appoggiati
su una lun esportata iscsi da openfiler, come devo fare? Devo
esportare due lun.
Ma così facendo, perdo la migrazione a caldo semplicemente cambiando
le config
di apache, dovrei per forza di cose attaccare la seconda lun alla
seconda VM.
In altre parole: o migro tutti i domini o nisba.
Con nfs, non migro niente, sposto solo le config.
E poi, è un calcio alle performance esportare in iscsi sulla macchina
locale no?
Anche perchè la san sarà quasi sicuramente in fibra, per cui iscsi è
solo una complicazione
in più presumo, quando arriverà la san dovrò comunque riconfigurare
tutto. Tanto vale tenere
nfs e riconfigurare quando arriva la san. Non so se mi spiego....

 
sarà che a forza di pensare soluzioni parecchio più grandi e ridondate
ho acquisito il senso "americano" del piccolo...
comunque ti conviene mettere 2 vm apache e 2 vm nfs e separare il
carico. non per avere più banda, ma per avere ridondanza

 carico. non per avere più banda, ma per avere ridondanza
Scusa, e io che ho detto di voler fare? :-)
2 VM apache + NFS per avere ridondanza, chi ha mai parlato di banda?
Poi ovvio che non farò eseguire gli stessi siti da entrambe le VPS ma
in condizioni normali splitto il carico.
Vorrei ottenere una soluzione il più scalabile possibile, con il minor
intervento umano.
Da quel poco che son riuscito a progettare, si tratterebbe di fare una
VM con NFS che esporta tutti i mille mila domini
più X vm con sopra apache che leggono tutti dallo stesso share nfs. la
vm con apache1 avrà configurato solo alcuni virtualhost,
la vm con apache2 avrà configurati solo altri virtualhost. In caso di
manutenzione, sposto alcuni virtualhost da una vm all'altra
semplicemente cambiando un ip (i miei virtualhost son dinamici, non
esiste il file di configurazione ma vengono pescati da db
in fase di start/graceful di apache).
Se un giorno volessi aggiungere una terza macchina mi basta solamente
clonare una di quelle esistenti e cambiare hostname ed ip.
Fine. La terza macchina prenderà i suoi virtualhost da db basandosi
sul suo ip.
Per un server FTP esterno posso fare in maniera analoga: creo una VM
adhoc e scrivo dritto nella share NFS. (o forse meglio far
scrivere direttamente nel filesystem da parte dell'ftp senza passare
da nfs? Scrivere diretto però potrebbe essere un problema da
gestire....)
Diciamo che vorrei progettare una soluzione che scali in orizzontale
nella maniera più assoluta. Parlando di web e ftp, non dovrebbe
essere affatto difficile con delle VPS, basta copiarle seguendo il
modo di cui sopra.
E' corretto? Non mi convince solo il fatto di usare nfs per esportare
i dati. boh....

 fare manutenzione ad una VM senza nascondere i siti in essa contenuti.
A che tipo di manutenzione ti riferisci?
-- 
ValeRyo
CBR600F "Cerbero" - 
http://www.slimmit.com/go.asp?6YT
GamerTag: 
http://card.mygamercard.net/IT/nxe/ValeRyo76.png
 

 A che tipo di manutenzione ti riferisci?
Ad un banale aggiornamento kernel, per esempio.
Ad un update di apache o al cambio di una configurazione
non andata a buon fine.
Avendo due nodi ed uno storage condiviso, con una singola riga di
query
sql posso migrare uno o più domini da un nodo all'altro.
Inoltre, potrei benissimo spostare i siti maggiormente trafficati dal
nodo sovraccarico a quello meno carico anche in automatico usando
monit o semplici controlli in bash...
E, sopratutto, mi permette di avere già le basi della futura
infrastruttura con
san, ovvero con i nodi web che pescano i dati via rete senza che in
futuro debba
riconfigurare niente. Mi basterebbe solo spostare il server nfs, i
nodi web rimangono
invariati e possono essere creati/distrutti a piacere e secondo
necessità, essendo
una configurazione totalmente automatica.

 monit o semplici controlli in bash...
Certo, anche se essendo entrambe le macchine virtuali sullo
stesso server fai prima ad allocare piů risorse.


 stesso server fai prima ad allocare più risorse.
non proprio perchè
a) allocare più risorse alla stessa macchina porta anche a problemi
di troppi file aperti, apache deve forkare più child e così via.
Faccio prima a
configurare una nuova vps, ci metto meno tempo una volta fatta la
struttura.
b) se dovessi fare manutenzione alla vps, mi van giù 1000 siti anzichè
100.
Fare 10 vps da 100 siti l'una anzichè 1 vps da 1000 siti ha anche il
vantaggio
che in caso di problemi, sono 100 utenti sono compromessi. E posso
sempre
spostare i virtualhost da una vps alle altre con 1 riga di sql.

 spostare i virtualhost da una vps alle altre con 1 riga di sql.
Ma la domanda è:
come bypassare le varie cache dns?
Se migro i virtualhost da una vps all'altra, avrò sempre alcuni minuti/
ore
di disservizio, a causa della cache dns dei vari utenti.
Piazzo due vps che facciano da reverse proxy e cambio il puntamento
da dentro esse? Il dns sarebbe sempre lo stesso in tal caso, ma questi
reverse proxy dovrebbero gestire una mole folle di traffico...
Metto il TTL a 5 minuti (o meno) nei record A dei domini web?

 Metto il TTL a 5 minuti (o meno) nei record A dei domini web?
IMHO fai soffrire i dns.


 In che modo potrei utilizzare gli snapshot?
Provo ad inventare:
- macchina 1 con siti in /www1 (per dom0 /dev/siti/m1)
- macchina 2 con siti in /www2 (per dom0 /dev/siti/m2)
Devi fare un assistenza a macchina1.
Stop m1, creazione di snapshot in /dev/siti/m1-s e assegnazione a m2,
lo monti in /www1 e attacchi a httpd.conf l'include con i domini di m1 (che
magari č proprio in /www1/conf), aggiungi l'ip di m1 e riavvii apache.
A questo punto abbiamo i siti su e possiamo lavorare piů tranquillamente:
avviamo m1 con la scheda di rete esterna disattivata e facciamo ciň che
dobbiamo. Al termine facciamo le operazioni di prima all'inverso.
Se invece vuoi fare un test di installazione, la prima volta lo snapshot lo
assegni a m1 (oppure crei un ulteriore snapshot per m1), cosě se qualcosa
non va bene puoi sempre tornare indietro.
Lo svantaggio č che gli utenti non possono fare modifiche mentre i domini
di m1 sono assegnati a m2, a meno che tu non assegni il source volume a
m2, che se contiene solo dati e non programmi va pure bene: basta che
aggiungi anche la configurazione del server ftp.


 aggiungi anche la configurazione del server ftp.
Appunto.
Con NFS nessuno si accorgerebbero di nulla perchè lo storage non
cambia.
Diciamo che voglio evitare di andare a smuovere mari e monti
modificando
lo storage in caso di manutenzione. Una volta attivato NFS (o i server
nfs)
quelli così sono e così restano. In caso di san, NFS pescherà i dati
da una LUN
esportata in qualche modo anzichè pescare i dati da un volume in
locale.
(pianifico uno spegnimento un sabato in piena notte magari un festivo
e nessuno dirà nulla)
Ma sui vari apache (che facendo 80-100 siti per vm diventeranno nel
giro di 1 mese circa 20)
non devo modificare nulla. Proprio zero. Faccio un template con nfs
montato in /www
(montato da tutti sempre nello stesso posto) e quando creo la VM
(magari dinamicamente in
base al carico degli altri serverini) non devo fare nulla.
In caso di secondo nodo virtuale, le VPS sono già configurate, le
copio sul secondo nodo e sono
a posto. Ed il dump/restore della VPS (che va fatto a vps spenta dato
che devo spostare anche il relativo volume lvm
non avendo storage condiviso) la posso fare in pieno giorno, perchè
spegnendo la VPS posso comunque migrare
i siti su una di quelle rimaste attive.
Ti faccio un esempio:
database dei virtualhost con due colonne (esempio brutale e banale)
dominio | hostname
www.pippo.it
 | web1.esempio.tld
www.ciccio.com
 | web2.esempio.tld
ogni virtualmachine creata avrà come hostname webX.esempio.tld.
Su tale vm le configurazioni di apache son gestite mediante mod_perl
ovvero
in fase di startup/graceful mod_perl va a leggere tutte le vm
associate al proprio
server in base al suo hostname.
Le config sono identiche per tutti i server del clusterone. (le config
stesse son prese
da db, non solo i singoli virtualhost)
Cambia solo l'hostname e l'ip che saranno assegnati in fase di
creazione VPS.
Muore una VPS o voglio fare manutenzione:
# update tabella set hostname = 'web2.esempio.tld' where dominio =
'
www.pippo.it
'
# update tabella_dns set data = 'web2.esempio.tld.' where zone =
'
pippo.it
' and record_a = 'www'
# ssh ute...@web2.esempio.tld -c ' apachectl graceful'
fine delle operazioni di manutenzione. fine di tutto. Il dominio è
migrato.
Resta appunto da gestire il TTL dei dns.
E' vero che genero un carico inutile (considera che a causa di
manutenzione perenne ho il TTL impostato a 300 secondi
da circa 2 anni su tutti i domini) ma con i server attuali ed il loro
costo (450 euro per un QuadCore dell) nulla vieta di mettere
due server fisici (per evitare di sovraccaricare i nodi del cluster
virtuale) con tanta ram per fare da dns.
La banda per un dns è alquanto trascurabile, non mi si aggiorna
nemmeno il grafico MRTG per intenderci. Non vedo 'la curva'

 in posti differenti potrebbe essere una complicazione inutile.
Potresti montarli in /www/$HOSTNAME, visto che comunque poi usi
il nome host per altri casi.
Considerando comunque che la tua è una soluzione temporanea in
attesa di una SAN, la soluzione che hai scelto mi sembra valida.


 attesa di una SAN, la soluzione che hai scelto mi sembra valida.
Temporanea, ma anche con SAN sono per continuare ad esportare via
NFS. Solo che con la SAN prendo i dati direttamente dalla LUN
esportata
anzichè da un volume LVM in locale

 PATH nei loro file php per cui č impraticabile questa soluzione.
E' vero, ma avere tutti i dati di cosě tanti domini in un unico filesystem 
non
mi convince...


 mi convince...
Già, se altri guru passassero di qui a dare qualche consiglio......

 ha scritto nel messaggio
news:ffe01b95-2780-482f...@e18g2000yqo.googlegroups.com

Eppure credevo fosse un argomento interessante :-)
Sul fatto del filesystem, tu che FS useresti?


 Sul fatto del filesystem, tu che FS useresti?
A boh.
XFS? JFS?
Ext3 non so come si comporterebbe con (stimato molto ipotetico) 10k
directory.
Preferirei usare ext3, ben collaudato (da me) con il quale non ho
avuto troppi problemi, ma
ho paura per le performance con tutte quelle directory sullo stesso
livello.
La struttura del filesystem sarà così:
/www/codice_utente/dominio/htdocs
per cui, i domini saranno accorpati in base al cliente, ed avrò 1
directory per ogni cliente.
i 10k di cui sopra, sono moooolto ipotetici, corrisponderebbero a 10k
clienti.
Ovviamente /www è il mountpoint della shere NFS, non è presente sul
filesystem di storage.
Sto valutando di aggiungere uno o due livelli aggiuntivi, in base al
primo e secondo carattere degli utenti
Ad esempio, supponendo che l'utente sia "pippo" la struttura potrebbe
essere:
/www/p/pi/pippo/dominio/htdocs
Una struttura del genere non è la prima volta che la vedo, ed ha senso
solo se si hanno
una infinità di file/directory nello stesso livello, per cui potrebbe
essere anche un ulteriore
supporto alla mia modalità di implementazione tutto con un volume NFS.
Di certo il cambio di FS in corsa non è una strada percorribile, per
cui, meglio prevedere prima.

 Di certo il cambio di FS in corsa non è una strada percorribile,
convertfs :)
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.

 /www/p/pi/pippo/dominio/htdocs
Adotterei comunque una suddivisione del genere, se non altro per avere 
insiemi di dati meglio gestibili, per esempio in script di analisi o di 
backup o per gestione via web, che avrebbero meno dati da gestire di volta 
in volta.
Sto pensando, per esempio, a un "ls *" o a una pagina web che permetta di 
navigare nel fs.
Bye.

 convertfs :)
Pauuuuura... O_o
-- 
http://bofhskull.wordpress.com/

 /www/p/pi/pippo/dominio/htdocs
Aggiungo una cosa:
ext3 ha un limite di 32k sotto-directory per ciascuna directory.
Il mountpoint /www, viene considerato "directory"? Spero di no,
altrimenti potrei aver problemi
sul server NFS che monta la /www dato che si ritroverebbe un intero
filesystem sottostante.
Se così non fosse, facendo la struttura a 3 livelli dovrei riuscire ad
ottenere 32k sottodirectory
per ciascun 'carattere' di utente....

 Pauuuuura... O_o
Però ho convertito un FS da 60GB con 10GB liberi da reiserfs a ext3 ed ha 
funzionato... (non potevo spegnere la macchina in quel momento, ma i dati 
non erano importanti e c'era il backup di tutto).


 Il mountpoint /www, viene considerato "directory"?
Maieutica:
/ è una directory o no?
-- 
http://bofhskull.wordpress.com/

 /www/${codice_utente:1:2}/${codice_utente}/dominio/htdocs
$utilityPerGestireGliUtentiConLdapCheNonRicordoComeSiChiama, 
sourceforge.net
 ....
Se non sbaglio loro (SF) fanno anche qualcosa tipo
/users/n/nomep/nomeprogetto
Enrico

 convertfs :)
Neanche sotto tortura cinese.
Non voglio mettere il culo davanti alle pedate.
Piuttosto, una struttura con server NFS centralizzato,
nel caso di apache e VPS creabili on-demand può aver senso?
Ci sono soluzioni migliori?

 navigare nel fs.
Mi riferivo anche io ad un banale "ls".
se devo fare della manutenzione, a volte mi capita di fare un "ls"
nella directory
con i domini e non mi va di impiegare 40 minuti prima di vederne
l'output.
Per la struttura, anche io sarei per adottarla, bisogna vedere se gli
attuali
siti hanno problemi ad essere spostati di document_root.
Ho siti vecchi di decine di anni, va a capire come son fatti.
Sarei più per una struttura a 3 caratteri anzichè due.
Il codice utente ha quasi sempre il primo carattere in comune ed il
secondo carattere spesso e volentieri è un numero predefinito
(il codice viene generato con alcuni algoritmi) e rischierei di fare
una suddivisione pressochè inutile con il 95% degli utenti dentro
la stessa directory. Usando 3 caratteri, dovrei riuscire a fare
una suddivisione più capillare.
Ma è tutto da verificare.

 ...le mie maildir... <g>
Be, io le ho semplicemente accorpate per dominio, le maildir
non crescono 'orizzontalmente' così tanto come un sito web che magari
ha 40 sottodirectory....

 / è una directory o no?
Si, ma pensavo che avendo dentro un filesystem differente il /www
fosse considerato "extra". In pratica essendo il limite per filesystem
/www avrebbe il suo limite di 32k directory, ma al suo interno ci
sarebbe
un secondo filesystem con ulteriore limite di 32k che però parte dal
suo
mountpoint, ovvero da dentro /www
insomma, mi son spiegato male. vabbè.

 
sourceforge.net
 ....
Non conosco LDAP, ma in questo caso, come può essermi utile.
I dati devono comunque essere scritti su Fs...

 I dati devono comunque essere scritti su Fs...
Intendevo che ci sono un sacco di tool, tra cui quel coso in ldap, che 
"realizzavano" strutture del tipo che abbiamo citato sopra...
Enrico

 non crescono 'orizzontalmente' cosě tanto come un sito web che magari
Dipende da che domini ti aspetti di poter gestire. Se vuoi poter gestire 
domini di migliaia di utenti, č decisamente il caso che introduci 
hashing sul nome dell'utente...
/mail/dominio.tld/u/us/user1
-- 
http://bofhskull.wordpress.com/

 livello.
Se prevedi davvero una tale quantità di directory allo stesso livello, ti
conviene fare come hai detto poi.


 /mail/dominio.tld/u/us/user1
No, non arrivo a tali cifre, per un singolo dominio.
Tu hai domini con migliaia di utenti senza un server dedicato ad essi?

 insomma, mi son spiegato male. vabbè.
Credo semplicemente che tu stia facendo un po' di casino con il 
significato di quel limite di 32K.
Il limite è relativo a quante sottodirectory possono essere create 
dentro una singola directory, ed è dovuto al fatto che c'è un limite al 
numero di link che possono puntare ad un dato inode.
Si parla, quindi, di relazioni di *parentela diretta*. Per capirci:
dirA - dir1
      \ dir2
      \ dir3
dirA è puntata 5 volte (dir1-3, . e ..)
dirA - dir1
      \ dir2
      \ dir3 - dir0x00
             \ dir0x01
             \ dir0x02
             \ dir0x03
             \ dir0x04
dirA è *sempre* puntata 5 volte. dira/dir3 è invece puntata 7 volte.
Che dirA sia o meno la root del filesystem che la contiene oppure ne sia 
figlia non sposta nulla.
-- 
http://bofhskull.wordpress.com/

 Tu hai domini con migliaia di utenti senza un server dedicato ad essi?
Di domini con migliaia di utenti in effetti solo uno. Con centinaia di 
utenti più di qualcuno.
Però, dato che la locazione della maildir è memorizzata centralmente per 
tutti i sistemi, tantovale avere hashing per tutti e togliersi il 
pensiero, anzichè dover mantenere poi sistemi tra loro diversi solo per 
miopia progettuale.
Almeno, se sei un ISP e quel servizio lo vuoi rivendere...
-- 
http://bofhskull.wordpress.com/

 dirA è *sempre* puntata 5 volte. dira/dir3 è invece puntata 7 volte.
Aaaa ma quindi il 32k è relativo alla directory subito sopra, e non a
tutto
l'albero.
Per cui
/www/co/codiceutente/dominio/htdocs
dentro htdocs posso creare 32k directory, dentro dominio altre 32k,
dentro codiceutente altre 32 e così via?
Ovvero, ogni directory può essere puntata fino a 32k volte dal primo
livello di sottodirectory.
Banalmente, una struttura come quella sopra mi consentirebbe di creare
fino a
32k sottodirectory con le prime 2 iniziali del codice utente
(impossibile, arriverei a massimo 26*26 directory, dato
che il codice utente è composto da sole lettere), 32k directory con il
codice utente completo il che si traducerebbe
in 32k directory per ogni combinazione di lettere (32k utenti con AA,
32k utenti con AB e così via), 32k domini per ogni utente e bla bla
bla bla bla
Allora può bastare un ext3 come fs....

 Andrebbe come tutti gli altri :)
Non mi pare, ad occhio XFS mi sembra piu` veloce nel listare una
directory con 32000 sottodirectory (ma stiamo parlando di sensazioni
soggettive). Posso comunque confermare che non vi sono grossi problemi
nel tenere un numero cosi` alto di sottodirectory in quanto, a lavoro, a
causa di una gestione ad minchiam[1] della creazione e della
cancellazione di directory temporanee, mi sono ritrovato a dover
gestire circa 27000 sottodirectory su di una macchina virtuale senza
troppi problemi (il listing via mc era sull'ordine dei 3 secondi)
Enrico
[1] una delle giustificazioni che mi sono sentito dare al problema e`
"Ma tanto al riavvio la cartella tempoanea viene svuotata"

 funzionato...
Personalmente condivido i timori di Skull. Piuttosto preferisco fare un
backup della partizione, formattare e ripristinare il backup
Enrico

 troppi problemi (il listing via mc era sull'ordine dei 3 secondi)
Il problema non è tanto il listing, quanto l'ottimizzazione
in lettura/scrittura dei vari webserver. Secondo voi avere 100
directory o averne 32k può impattare in qualche modo le performance
di lettura/scrittura di apache ed ftp?
Considerate che nessuno avrà l'accesso a tutto il filesystem.
Gli utenti saranno limitati alla loro homedir via FTP ed il web
sa già dove accedere in base alla documentroot, non deve fare il
listing di tutto il FS...
Ma a parte questo (bene o male una soluzione si trova, visto che
il limite dei 32k livelli non è di tutto il filesystem ma solo della
directory subito sopra, come posso gestire la migrazione di un dominio
da un server all'altro? Non posso cambiare gli IP, perchè parte dei
domini rimarrebbero sul vecchio server, per cui devo cambiare il
puntamento dns, però entrano in gioco le varie cache ed i vari TTL.
Metto TTL a 300 secondi o meno?
Imposto un TTL pari a (per dire) 2 ore e mi tengo due ore di margine?
Non mi pare una grande idea, se dovessi fare manutenzione ad uno o più
virtualhost dovrei attendere sempre 2 ore per avere la certezza che
tutti stiano accedendo al server nuovo.
Metto un proxy? Mi pare una complicazione in più... Preferirei evitare.
Inoltre tale proxy deve poter reggere tutto il traffico generato da
tutti i vari server web, alla lunga serve un bel macchinone corazzato..

 backup della partizione, formattare e ripristinare il backup
Ovviamente anch'io nel caso in oggetto (la faccina indicava quello).
Nel mio caso però mi ha risparmiato diversi grattacapi ed è comunque una 
strada percorribile in caso di necessità.
Ha anche altri difetti che andrebbero valutati e che ne sconsigliano l'uso 
per certi ambienti, ma certamente quel tool è una piccola perla :-)


 macchinone corazzato..
Concordo, e poi aggiungeresti un altro anello da controllare.


 Concordo, e poi aggiungeresti un altro anello da controllare.
Si, ma non più di tanto.
Tutta l'infrastruttura in futuro sarà ridondata su due o più nodi
virtualizzatori.
Un reverse proxy una volta impostato non si cambia. Una seconda,
terza, quarta
macchina si configurano clonando la prima e cambiando solo l'ip.
Poi si può banalmente bilanciare in roundrobin le varie macchine.
(bilanciamento un po stupido....se va giù un nodo, il roundrobin non
se ne
accorge e metà delle richieste vanno a vuoto)

 macchina si configurano clonando la prima e cambiando solo l'ip.
Ok, ma cerco sempre di pensare che quello che non c'è non si rompe
e non ha bisogno di manutenzione.
Tipicamente un disco si riempie il 24/12 alle 22.00 e un servizio
s'interrompe il 15/08 alle 12.00...


 s'interrompe il 15/08 alle 12.00...
A questo è fuori discussione.
Infatti ne sto parlando qui sul gruppo, ma sembra più una chat tra
me e te, le grandi teste son tutte fuggite??? :)
Sulla carta mi pare un buon progetto, ma ci vorrebbe un consiglio
da chi magari ha già implementato una soluzione simile, per evitare
di fare gli stessi errori.

 semplicemente
Personalmente punterei su una coppia di reverse proxy, magari con nginx che 
è più leggero di apache e/o squid e/o lighttpd.


 che è più leggero di apache e/o squid e/o lighttpd.
Però torniamo punto a capo:
devo aggiungere due server e di conseguenza più roba che si
può rompere e che posso rompere.
Il "peso" di apache o squid non mi importa, non credo che
con le macchine attuali faccia la differenza, dopotutto non
devo lavorare su delle appliance embedded ma sono server
veri... Per il momento il traffico generato complessivamente
da tutti i miei server è bassissimo, un 486 riuscirebbe a
gestire perfettamente tutto.... Però, meno roba c'è in
giro, meglio è....

 che è più leggero di apache e/o squid e/o lighttpd.
Altra cosa non banale.
Chi spiega a X clienti che tutti i loro siti han lo stesso IP
pubblico?
Son terrorizzati da come si potrebbe comportare google nel caso
veda 10k siti sutti sullo stesso IP (quello del proxy)
Mah...

 di fare gli stessi errori.
Mi sembra un VMware Infrastructure implementato a mano :-)
La discussione è comunque molto interessante e mi sta dando parecchi
spunti per dei prossimi test.


 giro, meglio è....
Non è meglio quando c'è poco, è meglio quando c'è il giusto.
Se ti servono le feature offerte da un sistema con reverse proxy, il giusto 
è mettere i reverse proxy. Ricordati sempre che le soluzioni accrocchiate 
prima o poi porteranno sempre problemi, quindi le soluzioni si devono fare 
corrette sin da subito. Valuta quel che ti serve e implementalo correttamente.
Per esempio il TTL dei dns basso va benissimo quando devi fare 
occasionalmente delle modifiche agli IP, ma non è che sia il massimo averlo 
costantemente a 300 (traffico e query inutili da gestire).


 Mi sembra un VMware Infrastructure implementato a mano :-)
Ni.
Sicuramente ho preso spunto da li. Ma V.I. se non erro gestisce
le VPS, io sono un livello sotto: gestire il contenuto delle VPS.
La migrazione in toto della VPS in stile VI si fa in pochi minuti
con heartbeat, monit o qualunque altra cosa in grado di monitorare 
disponibilità del server con un banale ping ed il carico degli stessi 
con una interrogazione alle API... (e non posso farlo adesso, non
avendo un secondo nodo, non avrei nulla su cui spostare le VPS)
Il problema è migrare il contenuto di una VPS dentro un'altra VPS...

 Chi spiega a X clienti che tutti i loro siti han lo stesso IP pubblico?
E questo dove sta scritto?
Io, ad esempio, sto usando pound e posso bindare istanze differenti
a ip differenti, ma puoi fare la stessa cosa anche con altri reverse.

 averlo costantemente a 300 (traffico e query inutili da gestire).
Ok, vada per il proxy, ma come spiego ai clienti che ci son
10k siti con lo stesso IP? Si guardano in cagnesco tra di loro qui...

 a ip differenti, ma puoi fare la stessa cosa anche con altri reverse.
Spiega un po?
Tu dici di mettere X istanze del reverse proxy su X ip differenti
sulla stessa macchina? Ok, benissimo, ma a parte risolvermi
il problema con i clienti, che utilità potrebbe avere in condizioni
normali?

 te, le grandi teste son tutte fuggite???
Io non sono una grande testa e non uso xen, ma vmware; il tipo di servizi
che offriamo è decisamente differente dal tipico mass hosting; facciamo
più ASP che altro.
Io, di solito, se devo far manutenzione del ferro, migro la macchina 
virtuale su un altro ferro e senza interruzione alcuna del servizio.
Fossi in te, valuterei più attentamente l'ipotesi reverse proxy o LVS...

 10k siti con lo stesso IP? Si guardano in cagnesco tra di loro qui...
Offrigli l'IP dedicato a 1000 euro in più all'anno e saranno felicissimi di 
condividere l'IP con gli altri...


 normali?
Praticamente nulla :-)


 Fossi in te, valuterei più attentamente l'ipotesi reverse proxy o LVS...
LVS se non erro serve per fare bilanciamento ed attualmente non posso
farlo ne è previsto in futuro. Devo implementare questo sistemino
per avere ridondanza e margini di manovra, non per bilanciare il carico
che comporterebbe anche una struttura un differente da quella a
cui sto lavorando.

 di quest'ultima. Prendo le prime 2 righe e migro i rispettivi vhost
Personalmente una cosa così la farei con LVS/ldirectord. Tutte le macchine 
web le tengo attive contemporaneamente e gestisco il bilanciamento/failover 
a livello di networking, distribuendo le connessioni in base all'IP ed 
eventualmente variando il "peso" delle macchine di backend in relazione al 
loro carico. Molto più semplice e funzionale. Oltretutto ha anche il 
vantaggio non indifferente che puoi usare i bilanciatori anche per altri 
servizi (
p.es
. SMTP).
Poi si possono anche combinare le funzioni di reverse proxy e bilanciamento 
per fare cose più complesse.


 di condividere l'IP con gli altri...
Sai bene che la risposta sarebbe:
Ok grazie, vado da Aruba, 20 euro ed ho l'ip condiviso da meno
persone anzichè 10k domini.

 usare i bilanciatori anche per altri servizi (
p.es
. SMTP).
(premessa: non conosco LVS)
Con LVS non bisogna impostare un cluster verso il quale reinoltrare
le richieste? Ovvero 2 VPS con gli stessi vhost sopra bilanciati
tra loro.
Oppure posso usare LVS anche nel caso di 2 VPS con vhost differenti
e quindi non bilanciabili tra loro? Insomma, devo far puntare i domini
staticamente. vhost1 -> vps1; vhost2 -> vps2 e non bilanciati....
in caso di problemi, riconfiguro apache e cambio puntamento al proxy.

 persone anzichč 10k domini.
Vabbé, puoi ben permetterti di metterne 100/200 per IP. Ti allochi una /26 o 
una /27 per quello scopo e poi assegni i clienti in base alle loro preferenze.


 preferenze.
E' già così....
Secondo te adesso ho 1 server per ogni cliente o 1 ip per ogni cliente?
:-)
Il problema era non metterne 10k sullo stesso, ma anche se fossero 
500-1000 non ci sarebbe problema, anzi, sarebbe la norma....

 in caso di problemi, riconfiguro apache e cambio puntamento al proxy.
Con ldirectord puoi impostare dei check (anche applicativi) e quando 
falliscono esclude il nodo fallito.


 livello 4, non a livello 7.
Non voglio bilanciare i vhost per cui L3-4 van bene.
Eventualmente se volessi bilanciare a L7 metto due proxy, bilancio i
proxy a L3 ed i proxy bilanciano a l7 i vhost.
Ma č troppo incasinato, preferivo qualcosa di piů semplice.

 di vhost (ed anche i problemi di cui sopra: troppi file, etc etc)
Con un bilanciatore LVS puoi fare un po' quel che vuoi.
Per esempio sui backend puoi fare ascoltare pool di vhosts su porte distinte 
e quindi bilanciare gli indirizzi IP di frontend su porte differenti.
Chessò, per esempio potresti mettere 1000 vhosts su 6 macchine di backend, 
500 su un pool di 3 macchine (pool 1) e 500 sulle altre 3 (pool 2). Poi su 
ciascun host metti 5 istanze di apache in ascolto su 5 porte tcp diverse 
(dalla 8001 alla 8005), ciascuna che gestisce 100 vhosts.
Sui bilanciatori poi metti 10 IP così configurati:
IP .1 => pool 1 porta 8001
IP .2 => pool 2 porta 8001
IP .3 => pool 1 porta 8002
IP .4 => pool 2 porta 8002
IP .5 => pool 1 porta 8003
IP .6 => pool 2 porta 8003
IP .7 => pool 1 porta 8004
IP .8 => pool 2 porta 8004
IP .9 => pool 1 porta 8005
IP .10 => pool 2 porta 8005
Ovviamente il limite è solo la fantasia :-D


 in maniera più o meno automatica i vhost tra di esse.
Però tante vps = tante macchine da tenere aggiornate e in sicurezza.
Non dico di no a prescindere, ma ne hai davvero la necessità?


 IP .10 => pool 2 porta 8005
Ottima idea mi permetterebbe di avere 1000 vhost, suddivisi in 6
server a gruppi di 3
(quindi si devono spaccare 2 server per ciascun pool prima di vedere i
siti down) ed
allo stesso tempo 100 vhost per siti, che fan felici i clienti.
Lavorando sulle porte però mi pregiudico la possibilità di utilizzare
i server web in
caso di guasto ai bilanciatori, e con una configurazione simile
sommata a Murphy, la
prima cosa che si spacca sono entrambi i bilanciatori durante il
pranzo di Natale.
Lavorerò quindi sugli IP, metto 10 ip nel bilanciatore ed altrettanti
ip singoli (e pubblici)
sui nodi, se butta male, mi basta cambiare i record dns e farli
puntare direttamente ad uno
degli ip associato al nodo web bypassando il bilanciatore.
Con le porte avrei meno spreco di ip (chissene... :D ) ma se mi si
spacca il bilanciatore per
far navigare la gente sui siti dovrei fare il routing sul firewall e
con la panza piena il giorno
di Natale non ho voglia, preferisco lavorare sul dns che è sotto
database.

 Non dico di no a prescindere, ma ne hai davvero la necessità?
Per come ho in mente io no.
Gli aggiornamente semplicemente non esistono.
Effettivamente il metodo di Zipman è ottimo, parto da due pool con 3
VM ciascuno
e bilancio il carico.
Parto da una debian installata con deboostrap, viene fuori un sistema
di 200mb al quale
devo aggiungere apache php e perl (per leggere le configurazioni da
db). Fine della macchina virtuale.
Gli aggiornamenti non li faccio, creo una macchina ex-novo
(debootstrap scarica ogni volta la versione
aggiornata) e la inserisco nel cluster, poi butto via le macchine
vecchie non aggiornate.
Avendo le config di apache su mysql compreso quelle di php con le
rispettive openbasedir,
non devo configurare nulla sui nodi appena creati. In 2 minuti posso
aggiungere un nodo al cluster.
Ecco il perchè di tutto questo lunghissimo post.....

 caso di guasto ai bilanciatori,
Non necessariamente, il server non può ascoltare su entrambe le porte?
Oppure una regoletta di iptables e via?


 degli ip associato al nodo web bypassando il bilanciatore.
Piuttosto preparati una semplice macchina da attivare al posto dei balancer 
che non bilanci nulla ma che faccia staticamente le giuste redirezioni con 
iptables. Perdi il bilanciamento dinamico ma almeno non perdi funzionalità.
Considera che comunque i balancer sono due in cluster; è ben dura che cadano 
entrambi.


 cadano entrambi.
Che cadano si, ma che io riesca a cannare la configurazione su di uno
e che poi la replico sull'altro invece è più probabile, conoscendomi.
La struttura mi pare sia stata ben definita:
2 vps bilanciatori che bilanciano 2 cluster composti da 3 vps ciascuno.
Per ora tutto su una singola macchina, appena arriva la seconda mi basta
spostare metà delle VPS ed il gioco è fatto.
Mi restano solo 3 dubbi:
1) i due bilanciatori sono in HA o sono bilanciati a loro volta? 
(presumo siano in HA con hot-standby, per cui quando avrò due nodi, uno
dei nodi sarà sempre coninvolto a causa del bilanciatore, il quale 
bilancia anche sull'altro nodo)
2) le vps di questo tipo, che fanno pochissimo uso di disco (se non 
nullo, dato che i log sono su server esterni e che i dati sono via nfs)
conviene crearle con delle immagini su file? LVM credo sia solo una 
complicazione, ed il calo di performance dato dai file non dovrebbe
essere così sensibile, alla fin fine, in locale non pesca niente. Tutto
gira in ram. Per i backup sarebbe più semplice, basta copiare il file...
3) nfs è la soluzione giusta? Non è la prima volta che sento una
soluzione simile in giro per internet... Avendo tutto in un unico
volume mi permette di bilanciare e muovere le vps a piacere senza
riconfigurare alcunchè...

 due classi IP diverse e farle ruotare.
Boh. Io mi trovo splendidamente con il direct-routing: è molto pià 
leggero (posto che per flussi mno che smodati è irrilevante) e non mi 
costringe a subnettare e/o a trattare con le eventuali beghe del NAT...
Inoltre, ha il vantaggio che in caso di casini cambiare IP ad un worker 
per assegnargli direttamente il VIP è un attimo...
Posto che non lo uso per il web, al momento...
-- 
http://bofhskull.wordpress.com/

 per assegnargli direttamente il VIP è un attimo...
Ben appunto...
Però anche come ha detto Zipman, implementare una VPS di emergenza
ci vuole un secondo... (il più è tenerla aggiornata man mano che
aumentano gli IP pubblici del frontend in modo da fare la mappatura
1:1 con il backend, ma nulla vieta di prendere gli IP dinamicamente
da db in fase di startup della vps così quando parte ha già gli
ip corretti)

 Pensavo non si potesse fare per problemi tecnici.
Basta far nascondere l'arp agli host reali.


 Basta far nascondere l'arp agli host reali.
Stavo facendo delle prove su carta in questo momento:
un bel casino, si fa prima ad usare meno IP pubblici e
condivirderli di più tra i nodi.
Ad esempio, supponendo di avere due cluster gestiti dai
due bilanciatori.
Sui bilanciatori metto gli IP pubblici, 1 per cluster, ovvero
1.1.1.10 e 1.1.1.20
Ciascun cluster bilancia tra i 3 nodi, che avranno i seguenti ip
1.1.1.11, 1.1.12, 1.1.1.13 per il primo cluster
e
1.1.1.21, 1.1.22, 1.1.1,23 per il secondo cluster.
ciascun cluster gestirà X siti, ad esempio 500, e questi 500 siti
avranno in comune lo stesso IP, come se fosse un tradizionale
server per hosting.
Meno casini, meno problemi.
Dato che ciascun nodo avrà i 500 siti sempre configurati, se si spaccano
entrambi i bilanciatori (che sfiga!) mi basta cambiare il dns dei vhost
facendoli puntare agli ip dei singoli nodi.
Così facendo non ci dovrebbe essere alcun routing di mezzo, nessuna
arp da disattivare e nient'altro. Dovrebbe fare tutto il director
mappando l'ip sorgente con uno degli ip di destinazione.

 clienti, che utilità potrebbe avere in condizioni normali?
Io l'ho usato in contesti vari.
Uno, possono fare da balancer, controllando lo stato dei vari backend, facendo
il tracking delle singole sessioni eccetera.
Due, mi servono a dare capacità https a server legacy dove andare a mettere
le zampe con SSL potrebbe avere esiti disastrosi.
Tre, m'è servito in situazioni in cui a un unico indirizzo ip pubblico corrispondevano
differenti web server con *differenti* ip privati: puoi smistare su un backend piuttosto
che su un altro a seconda dell'intestazione HTPP 1.1 "Host:"

 o dover riavviare la VPS per installare determinate cose.
Se è un server http statico, uso un clone da mettere online mentre 
operi le modifiche su quella originale, messa temporaneamente offline, 
oppure uso lo snapshotting.

 caso di guasto ai bilanciatori
I bilanciatori dovrebbero essere sempre almeno due in HA.
Se se ne fottono due contemporaneamente, beh, hai bisogno
di un buon esorcista. :-)

 di un buon esorcista. :-)
Be certo, ma come ho scritto, la mia è una struttura
temporanea, diciamo che devo preparare X virtual machine
ridondate tra loro, ma al momento girerà tutto su un singolo
nodo. Mi serve per poter avviare la struttura, poi quando
arriverà il secondo nodo dovrò semplicemente spostare le VM
da un server all'altro, senza dover reimplementare tutto.
Ma i due bilanciatori, come LVS, lavorano in HA o in bilanciamento
tra di loro? Uno sta li a fare da avvoltoio in attesa che il fratello
muoia o 'lavora' ?
A sto punto, bilanciando IP con IP (1 ip pubblico che bilancia verso
3-4 IP pubblici) resta da capire se usare LVS o il programmino che
hai indicato te. Forse meglio LVS, dal momento che parto, tanto vale
partire come si deve e se non erro LVS bilancia automaticamente anche
in base al carico e non esclusivamente in round-robin.

 muoia o 'lavora' ?
Lavorano in HA.
Basta leggere sul sito :)

 in base al carico e non esclusivamente in round-robin.
Ni.
Lui bilancia in base a vari algoritmi, ma non ha cognizione del carico delle 
macchine a meno che esso non sia direttamente proporzionale al numero di 
connessioni o che tu non implementi qualcosa di ad-hoc per rilevarlo e per 
variare il peso degli host a runtime (cosa comunque abbastanza semplice).
               rr - Robin Robin: distributes jobs equally amongst the 
available real servers.
               wrr - Weighted Round Robin: assigns jobs to real servers 
proportionally to  there  real  servers'  weight.  Servers  with
               higher  weights  receive new jobs first and get more jobs 
than servers with lower weights. Servers with equal weights get
               an equal distribution of new jobs.
               lc - Least-Connection: assigns more jobs to real servers with 
fewer active jobs.
               wlc - Weighted Least-Connection: assigns more jobs to servers 
with fewer jobs and relative to the  real  servers'  weight
               (Ci/Wi). This is the default.
               lblc - Locality-Based Least-Connection: assigns jobs destined 
for the same IP address to the same server if the server is
               not overloaded and available; otherwise assign jobs to 
servers with fewer jobs, and keep it for future assignment.
               lblcr - Locality-Based Least-Connection with Replication: 
assigns jobs destined for the same IP address to the least-con-
               nection  node in the server set for the IP address. If all 
the node in the server set are over loaded, it picks up a node
               with fewer jobs in the cluster and adds it in the sever set 
for the target. If the server set has not been  modified  for
               the specified time, the most loaded node is removed from the 
server set, in order to avoid high degree of replication.
               dh  -  Destination Hashing: assigns jobs to servers through 
looking up a statically assigned hash table by their destina-
               tion IP addresses.
               sh - Source Hashing: assigns jobs to servers through looking 
up a statically assigned  hash  table  by  their  source  IP
               addresses.
               sed - Shortest Expected Delay: assigns an incoming job to the 
server with the shortest expected delay. The expected delay
               that the job will experience is (Ci + 1) / Ui if  sent to the 
ith server, in which Ci is the number of jobs  on  the  the
               ith server and Ui is the fixed service rate (weight) of the 
ith server.
               nq  -  Never  Queue: assigns an incoming job to an idle 
server if there is, instead of waiting for a fast one; if all the
               servers are busy, it adopts the Shortest Expected Delay 
policy to assign the job.


> Basta far nascondere l'arp agli host reali.
Io personalmente non lo faccio neanche così. Mi limito a "truccare" i 
nodi con IPtables:
iptables -A PREROUTING -t nat -d ${VIP} -j DNAT --to-destination ${RIP}
Così mi levo anche il mal di testa dell'ARP.
-- 
http://bofhskull.wordpress.com/

 Così mi levo anche il mal di testa dell'ARP.
Quindi tu l'unica cosa che fai è impostare quella
regola iptables su ogni nodo facente parte del cluster?
Oltre, ad assegnare gli ip virtuali alle loopback dei singoli
nodi, giusto?

 nodi, giusto?
Fatta con iptables in quel modo, non c'è alcuna necessità che il nodo 
sia in possesso del VIP...
-- 
http://bofhskull.wordpress.com/

 sia in possesso del VIP...
Ergo: installi vps, metti regola di iptables sul vps, aggiorni la
configurazione sui bilanciatori (per bilanciare anche la nuova vps)
e te ne vai a prendere il caffe bello soddisfatto?

 configurazione sui bilanciatori (per bilanciare anche la nuova vps)
in teoria, non ci sarebbe bisogno di fare nemmeno questo passaggio.
Basterebbe configurare sui bilanciatori un pool con degli ip volutamente
morti, il bilanciatore non li utilizzerebbe e quando serve, basta
assegnare ad una vps uno degli ip fake.
un bel dhcp con ip fissi sul macaddress mi risolverebbe un botto
di problematiche....
In settimana avrò un sacco di cose nuove da testare :-D

 di problematiche....
AAAARRRGGHHHHH!!!! Vade retro, Saragat...


 AAAARRRGGHHHHH!!!! Vade retro, Saragat...
e perché mai?
non vedo lati negativi il dhcp per assegnare necessita del macaddress
impostato nella configurazione per cui non vedo in che modo possa
causare problemi.

 non vedo lati negativi il dhcp per assegnare necessita del macaddress
[...]
Boh, punti di vista.
Io ho sempre ritenuto la sola idea di avere DHCP in funzione in 
datacnter come un modo per andare in cerca di guai....
-- 
http://bofhskull.wordpress.com/


Sarò tradizionalista ma concordo... solo la vlan dei client ha DHCP e RADVD 
abilitati.


 abilitati.
ma se il dhcp sta su una sua vlan e non ha alcun range di ip da poter
assegnare non dovrebbe essere un problema.
però ok, evito di mettere il culo davanti alle pedate