Newsgroup: it.comp.os.linux.sys
Titolo: Re: Distribuire il carico server web...

 carne al fuoco...
 
Gi�... ^_^
E poi l� � pi� rognosa :-P

 Dici, eh...?
 
S�...
 
 

 Metterlo in failover? O:-)
 
Uhm, come? Ad occhio mi viene in mente un approccio via DNS (ovvero, due 
reverse proxy su due macchine pubbliche e due record A che puntano ai due 
indirizzi ip pubblici), ma oltre che non saprei come vengono "digerite" 
eventuali eventuali sessioni utente (e.g. viene eseguita una 
autenticazione), sarei curioso di conoscere altri approcci
 
Enrico


Due reverse proxy distribuisce (circa) il carico, ma se uno va gi� non �
che ti dia alcuna ridondanza: il 50% delle sessioni va kaputt...
 

 che ti dia alcuna ridondanza: il 50% delle sessioni va kaputt...
 
Uhm, allora l'unica che mi viene in mente e` mettere in piedi un sistema con 
DRBD (seriamente, ho sempre riflettuto sull'argomento ma non ho mai avuto il 
tempo di implementare qualcosa del genere)
 
Enrico


In linea di massima, mantieni le sessioni utente lato webserver in
locazione condivisa (quindi appoggi i files di sessione su
NFS/DRBD/memcached/database/whatever), in modo che, dal punto di vista
dell'utente, non vi sia alcuna differenza tra l'uno e l'altro.
 
Se lo fai, quale proxy "ti gestisca" diviene altrettanto ininfluente
(indipendentemente da dove "ti manda", c'è la stessa roba), sicchè non
hai necessità che i proxy mantengano alcuno stato, e tutto ciò che hai
bisogno di replicare è la configurazione (e per quello basta un cronjob).
 
A quel punto, ridondare i proxy è banale: heartbeat/VRRP/DNS/whatever.
 
 
Se invece le sessioni condivise non le puoi fare, allora i proxy devono
mantenere lo stato dei visitatori. Ma anche in questo caso non c'è di
fatto necessità di *condividere* uno stato tra i proxy: possono
semplicemente usare algoritmi univoci (es: scegli il backend in base
all'IP sorgente della richiesta: i pari qui, i dispari lì; sicchè a meno
che l'utente non cambia IP a metà navigazione, finisce sempre sullo
stesso webserver) oppure spostare la tracciatura delle sessioni
direttamente all'interno delle sessioni stesse (es: basi l'instradamento
sul cookie di sessione, facendo in modo che il proxy possa discernere
tra le sessioni create dall'uno e dall'altro realserver).
 
 
Ma occhio che, di fatto, stai solo spostando il problema: in caso di
morte di un webserver, gli utenti ivi serviti verranno dirottati sui
superstiti, perdendo in tal modo i loro dati di sessione e riportandoti
al punto di partenza...
 

 servizi, dall'altro sulla loro distribuzione.
 
Mai sentito parlare di Cloud?
 
Siamo quasi nel 2014, ancora parliamo di NAS, NFS e proxy?
 
Che sia il caso di farsi un giro dalle parti di Amazon AWS?

 Mai sentito parlare di Cloud?
 
Mai pensato che possono esserci ottime ragioni per non voler mettere la
propria roba su infrastrutture altrui?
 
Non ho niente contro AWS e lo uso per diverse cose, ma gestisco anche
diversi sistemi che non metterei mai l� sopra...
 
 

 Mai sentito parlare di Cloud?
 
Saro` io, ma ultimamente mi viene da associare la parola "cloud" ad 
"incompetenza"...
 
Enrico

 "incompetenza"...
 
Ai bei tempi si diceva "vaporware", adesso si dice "cloud" e fa molto
piï¿œ fico.
 
nuvole di saluti
-- 
Dignitï¿œ e moneta:
http://dottormistero.blogspot.it/2013/04/dignita-e-moneta.html
 

 più fico.
 
No, perche` il cloud e` qualcosa di vero ed usabile, il vaporware e` 
tutt'altro (e.g. Duke Nukem For... ah, no, e` uscito!)
 
Enrico

 Mai sentito parlare di Cloud?
 
Ah si, la parolina magica.
LOL.
 
E in ogni caso: io ho chiesto pere e mi stai rispondendo che son
meglio le mele.
Non lo metto in dubbio ma non hai comunque risposto alla mia domanda.
 
Saluti.
 
-- 
Giocare col mondo, facendolo a pezzi...
Bambini che il sole, ha ridotto gia'... vecchi.

Il 14/12/13 15:26, Enrico 'Henryx' Bianchi ha scritto:

No, quello � il cloud all'italiana.. in server farm che vanno a fuoco.
 

 diversi sistemi che non metterei mai l� sopra...
 
Vabb�.. risposta alquanto fumosa, un esempio concreto di sistemi non 
compatibili con AWS?
 

 Non lo metto in dubbio ma non hai comunque risposto alla mia domanda.
 
Basterebbe provare l'infrastruttura AWS e leggersi i relativi manuali 
per capire che la domanda di cui sopra appare un po come "meglio l'Amiga 
o il Commodor 64?" nel 2014 direi ne l'uno ne l'altro, semplicemente la 
domanda ï¿œ fuori tempo massimo.
 
Oggi sono disponibili Amazon Route 53, l'Elastic Load Balancing, 
l'Elastic Block Store e l'Amazon Relational Database Service.
 
La descrizione dei suddetti ï¿œ disponibile presso il sito 
http://aws.amazon.com
 
 
Questo ï¿œ il nuovo standard a livello internazionale nel cloud computing, 
utilizzato dalle piï¿œ grandi aziende.
 
 
 
 

 compatibili con AWS?
 
Genericamente e semplicemente, qualsiasi dato che debba restare
riservato e non accessibile a terzi. Se lo metti su AWS (o quasiasi
altro "cloud", FWIW), allora devi rivedere la tua definizione di
"riservato" e di "terzi".
 
 

 utilizzato dalle piï¿œ grandi aziende.
 
Ma guarda, mi sembra che tu stia sparando un colpo un po' fuori bersaglio...
 
 
Ribadisco, non ho niente contro i servizi di cui sopra. Li uso, e alcuni
di questi (al pari di alcuni che non citi) mi han salvato il culo in
momenti critici, quindi figuriamoci se posso aver qualcosa contro di essi.
 
 
Ma non ï¿œ che funzionino per una qualche magia. Funzionano perchï¿œ sono
stati ingegnerizzati sulla base di ben definiti ragionamenti e approcci,
che non sono affatto diversi da quelli che si discutevano qui.
 
Approcciare il problema da te (realizzandoti cache proxy, bilanciatori,
realserver, filesystem condivisi) ti permette una padronanza decisamente
di un altro livello.
 
 
Di capire i problemi di scalabilitï¿œ che potresti incontrare, anche
quando progetti le tue strutture affidandoti a soluzioni cloud.
 
Di realizzare infrastrutture scalabili e ridondanti anche liddove le
esigenze (di qualsiasi genere) non ti consentano di appoggiarti a
soluzioni cloud precotte.
 
Di imparare -vuoimai!- un mestiere che ti puï¿œ tornare utile: quello del
sistemista che sa progettare e mettere in piedi infrastruttura e non
semplicemente comperare il prodotto X che fa giï¿œ da sï¿œ quasipermaggia.
 
Perchï¿œ non ï¿œ che gli ingegneri che in Amazon progettano quella roba li
abbiano assunti ad Hogwarts. E' gente che quella roba la sa fare perchï¿œ
l'ha fatta, l'ha studiata, l'ha capita.
 
 
Poi magari la tua massima aspirazione come sistemista ï¿œ minimizzare il
lavoro e i problemi connessi, spostandoli il piï¿œ possibile su qualcun
altro, e il fatto che AWS faccia per te quel che non vuoi fare ï¿œ un
sollievo.
 
La mia, fin da quando iniziai (ormai troppi anni fa) ï¿œ -ecco- un po'
diversa.
 
 
Non significa che la mia sia migliore della tua, eh. Ma non venire a
cercare di convincermi che a imparare a farsi le cose (foss'anche la
pasta fatta in casa) si sbaglia.
 
Perchï¿œ se vogliamo andare a vedere, escludendo tematiche fiscali e
congiunture economiche, il problema grosso che vedo io, nelle realtï¿œ
tecnologiche qui in Italia (dove vivo ma non lavoro -di fatto- da un po'
di tempo) ï¿œ proprio l'assenza di intraprendenza ("Ma tanto lo fa giï¿œ XXX").
 
Che, nella migliore delle ipotesi, spinge la gente con testa e idee a
cercare altrove.
 
Certo non il contrario.

compatibili con AWS?
 
Per esempio sistemi che gestiscano dati riservati sanitari. Per legge, quei
dati non puoi esportarli all'estero e devi avere sempre il totale controllo
- non solo su carta, ma in pratica. Se i dati sono su una VM che non sta in
casa tua, questo controllo non ce l'hai.
 
Tanta altra roba sul cloud ci sta benissimo, ma dire "tutta" non va.
 
Poi, personalmente, se volessi mettere su - che so - un ecommerce che possa
in qualche modo paragonarsi ad Amazon, mettere i dati di fatturazione, e di
fornitura, magazzino, ecc., sul cloud di Amazon mi sembrerebbe una cosa non
educata: guasi una mancanza di rispetto, per quanto criptati fossero :-)
 
Leonardo
 
-- 
 
Then felt I like some watcher of the skies, when a new planet swims into his ken;
Or like stout Cortez when with eagle eyes, he star'd at the Pacific; and all his men
Look'd at each other with a wild surmise - silent, upon a peak in Darien.

 bersaglio...
 
"92 minuti di applausi!"
 
Enrico

 Certo non il contrario.
 
+92 ulteriori minuti di applausi. Sei a 184, per ora!
 
:-D
 

 No, quello è il cloud all'italiana.. in server farm che vanno a fuoco.
 
Perche`, giustamente, Amazon e` antitutto, tanto che la distruzione di una 
macchina virtuale che hostavo da loro e` dovuta non al fatto che hanno 
spento il ferro su cui girava, ma all'intervento dei gremlins
 
Enrico
P.S. ad onor del vero, Amazon mi ha avvertito n giorni prima. Il motivo per 
cui la macchina virtuale e` andata distrutta e` solo perche` era una istanza 
"usa e getta", altrimenti avrei dovuto provvedere manualmente ad una sua 
rilocazione da un'altra parte del datacenter

 No, quello è il cloud all'italiana.. in server farm che vanno a fuoco.
 
Tra l'altro, se tu ti affidi ad un hosting che e` notoriamente considerato 
inaffidabile (fino ad un certo punto, pero`, che se le macchine da loro 
attive funzionano tutt'ora, allora non possono essere considerati cosi` 
inaffidabili), noi non ci possiamo fare molto
 
Enrico

Il 15/12/13 10:37, Skull ha scritto:

Naturalmente, tenere i dati riservati sul proprio server in ufficio 
connesso tramite ADSL ed aggiornato nel 2008 � moolto pi� sicuro.
 
Ho lavorato 10 anni con aziende e pubbliche amministrazioni italiane 
grandi e piccole e di sicuro non hanno assolutamente nulla, manco i 
bilanci figuriamoci i server.
 
 
 

 bilanci figuriamoci i server.
 
...e quindi...?
 

connesso tramite ADSL ed aggiornato nel 2008 è moolto più sicuro.
 
Anche quello e' illegale in vari scenari (per es. proprio sistemi con
"dati sensibili afferenti alla sfera della salute"). Server con tutte
le certificazioni, aggiornato, password variate mi pare ogni 60gg - o
90, non rammento - antivirus, firewall, quant'altro. Altrimenti si va
sul civile (o nel penale, a seconda della sfiga).
 
Poi, okay: se uno parte dal presupposto "Ma, per mia comodita', trovo
conveniente violare la legge" oppure "Ma tanto lo fanno tutti" allora
senz'altro e' meglio un cloud che non il serverino nel sottoscala.


 :-D
 
...con i miei vai a 276. ;-)

 connesso tramite ADSL ed aggiornato nel 2008 è moolto più sicuro.
 
Stai parlando di due cose differenti. Se quel server soddisfa le mie 
esigenze di riservatezza, allora puo` essere acceso anche dal 1998 senza 
aggiornamenti. Ma se devo tenerci dati sensibili, allora o mi adeguo alla 
legge, o faccio prima ad emigrare
 
Enrico
P.S. per inciso, una istanza EC2 non si aggiorna da sola...

 grandi e piccole
 
Ecco ma queste cose non sono dettagli per incasellare il tuo pensiero e modo 
di lavorare.
 

 di un altro livello.
 
Francamente non vedo come si possa paragonare un filesystem condiviso 
fatto in casa con un paio di server con un infrastruttura Cray Sonexion.
 
Immaginiamo AWS come un "consorzio agrario" in grado di fornire trattori 
per arare e seminare, mietitrebbie, camion per il trasporto, silos per 
lo stoccaggio, ed un sistema di vendita del prodotto sui mercati 
internazionali.
 
Ora, dato che i proprietari terrieri sono i titolari dei domini..
 
Al nostro sysadmin con una funzione prettamente di "consulente esperto" 
o "manager" se preferite, non resta che decidere come coltivare i 
suddetti terreni.
 
Mi metto a studiare come funziona una mietitrebbia? o faccio la patente 
per guidare il camion? o mi preoccupo di come funziona esattamente il 
silos di stoccaggio del grano? o di come funzionano le borse delle 
commodities?
 
Ognuna di queste cose ï¿œ certamente interessante e sicuramente il team di 
AWS ï¿œ preparatissimo in ognuno di questi settori dato che saranno stati 
scelti a suo tempo tra i migliori in circolazione nei rispettivi incarichi.
 
Ma il punto ï¿œ capire come il "tentare" di specializzarsi oggi in ognuno 
di questi campi possa portare un "valore aggiunto" per il proprietario 
del terreno (o dominio che dir si voglia).
 
Lo scopo finale di chi paga ï¿œ sempre quello di trarre profitto 
ovviamente, e la teoria Marxista che il valore sia determinato dalla 
quantitï¿œ di lavoro contenuto nelle merci/servizi (lavoro incorporato) ï¿œ 
palesemente una gran boiata!
 
Il valore lo da il mercato punto!
Ed al mercato non gliene frega un cazzo se per coltivare il vostro grano 
ci avete messo amore, passione, sudore e fatica spingendo un aratro 
trainato da buoi o se vi siete appoggiati al suddetto consorzio di cui 
sopra.
 
Vi resta solo da capire quale delle due soluzioni sia piï¿œ conveniente 
per i vostri clienti e di conseguenza anche per voi.
 
Io piï¿œ che "assenza di intraprendenza" nelle aziende italiane vedo 
pressapochismo e "fai da te", accrocchi tecnologigi messi assieme alla 
bell e meglio negli anni ecc..
 
Ogni tanto un giro in discarica non fa male anzi...
 
 
 
 
 
 
 
 

 Cosa ci possa essere di sbagliato in questo non lo so :-)
 
Non temere, con il tempo lo imparerai.. a tue spese ovviamente ;-)
 
Porsi degli obbiettivi e cercare di raggiungerli.. l'obbiettivo � 
imparere come funziona una mietitrebbia o mietere il grano?
 
Per cosa viene pagato un sysadmin? rammentamelo..
 

sopra.
 
Sicuramente no. Ti paga sempre 100 nello stesso modo.
 
Tuttavia, decidere cosa seminare (e dove) [sapendo che i camion consumano in
rapporto alla distanza percorsa, per dire] puo' fare la differenza fra avere
un incasso di 150 - di cui 50 girati al consorzio per le spese - ed avere un
incasso di soli 135 - di cui 25 girati al consorzio.
 
L'esempio piu' banale che mi viene in mente: Amazon RDS, MySQL in locale, od
un mix dei due? Il costo finale e' dato da una formula complicata con dentro
numero di transazioni per tipo, costo sistemistico, impegno di CPU, eccetera
eccetera. La soluzione "100% RDS" e' una delle soluzioni, e la piu' semplice
per molti versi. A volte e' pure la migliore. Ma "100% RDS sempre" rimane un
approccio semplicistico.


 un approccio semplicistico.
 
Piccolo aneddoto a tal proposito. Database di produzione Oracle su RDS. Per 
uso interno, ogni tot giorni dobbiamo fare un export di alcuni schemi di 
produzione e portarli internamente nel nostro ufficio. Ora, per come 
funziona Oracle, l'unico modo per fare quest'operazione e` praticamente 
"aggirando" i limiti imposti da Amazon tramite barbatrucchi, in quanto non 
e` possibile esportare direttamente da remoto alla propria macchina ed 
essere sicuri che il risultato sia quello atteso. In altre parole, quella 
che sulla carta ci sembrava una soluzione pulita, nella realta` ci tarpa 
abbastanza le ali, visto che non ci permette la flessibilita` che 
effettivamente ci serve
 
Enrico
P.S. no, Oracle exp (utility Oracle per fare gli export) e` stata eprecata, 
e Oracle Data Pump (sistema di Oracle per fare gli export) non e` 
direttamente utilizzabile in quanto il file risultante risiede sul server in 
una directory dedicata non esposta all'utente (l'alternativa e` eseguire il 
data pump nella directory dedicata e poi estrarlo tramite un package che 
permette di scrivere sul file system dall'interno di Oracle)