Newsgroup: it.comp.os.linux.sys
Titolo: Grossi problemi con LDAP, NFS e client Linux...

Abbiamo appena messo in piedi due  laboratori, 60 PC in tutto, con Linux
(Fedora 7)  e Windows  XP sotto  VirtualBox, il tutto  un po'  in fretta
causa  ritardi negli acquisti  dei suddetti  PC, e  questo ora  ci causa
problemi per mancanza di opportuno testing in periodo piu` tranquillo, e
invece  sono iniziate  le lezioni,  con quasi  400 matricole  che devono
usare i laboratori...
I problemi principali  che mi ritrovo sono due: LDAP  e NFS, col secondo
che probabilmente dipende almeno in parte dal primo.
I client sono configurati per  autenticarsi via LDAP e usare l'automount
per le home  directory: il tutto funziona, ma il  carico sul server LDAP
e` micidiale: *centinaia* di connessioni aperte ogni momento sul server,
anche  oltre  1000 in  certi  momenti, con  ogni  client  con un  utente
collegato che ne ha da 20 a 40 aperte in media.
Risultato:  dopo un po'  il server  si inginocchia,  non per  pregare (o
forse si`...), e bisogna  riavviare OpenLDAP e l'automounter (che altri-
menti non risponde piu`).  Oppure tiene botta, ma si assiste a dei "con-
gelamenti" di svariati secondi -- da 10 a 30, piu` o meno -- dei client,
con  gli utenti  che  si incavolano  e  magari resettano  o spengono  le
macchine di brutto.
NFS va  dietro LDAP con  rallentamenti, ora meno  pronunciati, probabil-
mente legati al carico su LDAP.  Anche il KDE sui client si comporta er-
raticamente  all'avvio, quando  carica da  rete  la home  e il  relativo
contenuto (400  file per il template di  KDE! Mi sa che  devo trovare un
desktop manager meno esoso... purtroppo, come detto, tempo per fare test
con calma non ce n'e`  stato): spesso "il protocollo media|file e` morto
inaspettatamente" e  mezzo KDE  non funziona piu`  come deve;  anche qui
sospetto il carico su LDAP/NFS.
Vi risulta che  sia normale avere tutte quelle connessioni  LDAP ? E che
riescano a far  sedere un server con uno  Xeon da 2.8 GHz, 4  GB di RAM,
dual GBit  Ethernet e  dischi Ultra360  SCSI in RAID  5 (software)  ? Lo
stesso server che ha installato  le 60 macchine con Systemimager in meno
di 4 ore (a lotti di 20), sparando quasi 20 GB per macchina ?
Suggerimenti ? Parametri "magici" per LDAP, NFS o il kernel ? Mettere un
proxy LDAP  (sto guardando ora  cosa c'e` in  giro) su ogni client  e in
ldap.conf mettere come server 127.0.0.1 ? Tornare a Windows e Samba ?
Per ora  ho abbassato timeout e  idle time in ldap.conf  a livelli quasi
"pericolosi" e aumentato la cache e  idlcache per bdb in slapd.conf e in
DB_CONFIG. Ho  perfino ricostruito ex-novo e  reindicizzato il database:
qualcosa e` migliorato, ma non molto. Mi sembra strano che bastino 60 PC
e  un loro uso  normale per  inchiodare OpenLDAP:  diamine, NIS+  su una
vetusta  SparcStation 10  (36  MHz CPU,  64  MB RAM,  Solaris 7:  ancora
attiva, per inciso) reggeva 30 macchine senza nemmeno mostrare un carico
superiore a 0.10...
Sono "bafflato"...
Saluti,
Luca Polo.
-- 
Luca...@gest.unipd.it
 --- 
http://www.gest.unipd.it/~jake
----------------------------------------------------------
One Ping to rule them all. One Ping to find them.
One Ping to bring down them all.
And in the darkness crash them.         [The Lord of the Pings]

 ?
# echo idletimeout 30 >> /etc/ldap/slapd.conf 
# /etc/init.d/slapd restart
con questo trucchetto (ma io ho kerberos per le password) non ho
problemi con 85 utenti collegati, home in nfs sul server e Debian sarge
dappertutto (il sistema è su dal 5 febbraio 2006), ah il mio server è
uno Xeon 2.4 1 GB ram e due dischi sata in raid 1 software, il tuo mi
pare un po'tanto sovradimensionato, ma ripeto, ho Debian...
Ciao, Micky
-- 
What's this hash prompt on my terminal mean?
Micky Del Favero  -  System Manager  &  BOFH

--> "M" == Micky  <mi...@fcnz.zrfvan.arg> writes:
M> # echo idletimeout 30 >> /etc/ldap/slapd.conf 
Questa mi  mancava... pensavo fosse un'opzione solo  per ldap.conf (dove
infatti  c'e`...) ora  ci  ho provato  e  vediamo se  magari era  questa
boiata. [[  aggiornamento a qualche minuto  dopo: si`, ora  il carico e`
MOLTO meno pronunciato -- thanks a lot!! ]]
In contemporanea  ho provato a  configurare OpenLDAP in  modalita` proxy
sulla macchina prototipo, dove per  caso c'era gia` il server installato
(non chiedermi perche': avro` cliccato su un checkbox in piu` in fase di
installazione),  e  di bello  c'e`  che ora  sul  server  c'e` solo  una
connessione aperta  (e sul client 3  o 4... ohibo': dove  sono finite le
altre 20 o  30 di prima ?).  Opzione da tenere in conto  anche per altre
situazioni nel caso serva.
M> dappertutto (il sistema è su dal 5 febbraio 2006), ah il mio server è
M> uno Xeon 2.4 1 GB ram e due dischi sata in raid 1 software, il tuo mi
M> pare un po'tanto sovradimensionato, ma ripeto, ho Debian...
Era (e`) previsto anche per ospitare una o due macchine virtuali a scopo
di backup  degli altri  due server (che  devo aggiornare: uno  ha ancora
Fedora Core 1 !) e/o per  ospitare un paio di altre macchine virtuali da
usare in RDP (terminali di ricerca in biblioteca, da blindare al massimo
e restringere  alla rete di  Ateneo, o andiamo  in mezzo a rogne  con la
legge Pisanu...).   Inoltre ci sono  altri 120-150 PC  che in un  modo o
nell'altro si appoggiano a questo.
Comunque  ora   sembra  andare  molto  meglio:   le  connessioni  attive
contemporaneamente sono  al massimo poche  decine. Ora posso  provare ad
ottimizzare  qualche altro parametro  (threads, idlcachesize,  ecc.) con
piu` calma.
Di nuovo grazie.


 Di nuovo grazie.
Di niente, ciao, Micky


> ancora Fedora Core 1 !) e/o per ospitare un paio di altre macchine
M> metti Debian, ti farai un grande piacere.
Non mi ha  mai attirato troppo: non  mi si adatta, in un  certo senso, e
con RedHat/Fedora ho molta piu'  pratica e confidenza (prima usavo SuSE,
un paio di  Mandrake sul mio PC, piu'  indietro ancora... Oddio, andiamo
alla Slackware  0.99... OK, in mezzo  c'era SOlaris e  SunOS). Magari ci
riprovo un'altra volta piu' avanti.


Mandi! Luca Polo
  In chel dì si favelave...
LP> proxy LDAP  (sto guardando ora  cosa c'e` in  giro) su ogni client  e in
LP> ldap.conf mettere come server 127.0.0.1 ? Tornare a Windows e Samba ?
nscd è installato sui client? Sostanzialmente serve a quello...
-- 
  Dai diamanti non nasce niente
  dal letame nascono i fior				(F. De Andre`)

 writes:
MG> nscd è installato sui client? Sostanzialmente serve a quello...
Si`, comunque il problema si  e` risolto: uno stupido parametro mancante
in slapd.conf,  che ero  convinto andasse solo  in ldap.conf (e`  ora di
ripassarsi OpenLDAP, insomma...).


 sopravvive lo stesso: intanto matureranno gli altri fichi :-).
nemmeno kvm ce la ha, per cui metto tutto su un volume drbd, o ce la ha
e non me ne ero accorto?
Ciao, Micky


--> "M" == Micky  <mi...@fcnz.zrfvan.arg> writes:
M> Ma devi virtualizzare sono linux? Perché non provi vserver? È una mia
M> curiosità, non una critica, eh.
Tempo e opportunita`: Xen, KVM/QEMU,  VMWare e VirtualBox sono incluse o
facilmente aggiungibili  ad una distribuzione "standard"  (le prime due,
ad es., arrivano di default  con Fedora), mentre VServer richiede kernel
modificati ad  hoc (come Xen, peraltro)  e un altro tipo  di approccio e
know-how, che bisogna crearsi e non abbiamo risorse hardware e umane per
farlo (siamo in due, e 1600 studenti  + 60-70 afferenti + 200 e rotti PC
danno  il loro  bel da  fare,  specialmente come  numero di  "interrupt"
quando vorresti poterti concentrare  in tranquillita`; ah, ci sono anche
i telefoni e i cellulari), per  cui piu` di tanto non posso sperimentare
(al  massimo ho  "tenuto indietro"  per qualche  mese il  server  di cui
parlavo in precedenza, invece di  trasferire subito le home, proprio per
poter fare qualche prova di virtualizzazione)
M> nemmeno kvm ce la ha, per cui metto tutto su un volume drbd, o ce la ha
M> e non me ne ero accorto?
C'e` nelle ultime versioni, anche se non l'ho provata (non ho server con
VT,  anzi: finora  avevo solo  un  PC col  VT e  disponibile per  test):
http://kvm.qumranet.com/kvmwiki/Migration


 ripassarsi OpenLDAP, insomma...)
Ti conviene dare un'occhiata anche a FedoraDS, da quello che sento in giro
non e` per niente male (anche io uso OpenLDAP, soprattutto perche` e`
l'unico server LDAP presente nei repository Debian)
Enrico

 maturare  ancora e  Xen ha  il problema  del kernel  modificato  ad hoc.
Personalmente sono passato con soddisfazione all'accoppiata KVM/QEMU da un
po' senza particolari problemi (il primo lo uso sui server che supportano
VT, il secondo sui client che non hanno VT, ma che uso con l'apposito
modulo kernel). In cosa li hai trovati carenti?
Enrico

 writes:
EB> Ti conviene dare un'occhiata anche a FedoraDS, 
E' in  coda tra le  cose da provare;  da una prima, veloce  occhiata usa
schemi sensibilmente diversi  da quelli di OpenLDAP, per  cui migrare un
database non  e` una semplice questione  di dump dal OpenLDAP  su LDIF e
ricaricare  su  FDS,  per  cui  ho rimandato  a  tempi  piu`  tranquilli
(l'inizio dell'anno accademico NON ricade in questa categoria...).


 writes:
EB> Personalmente sono passato con soddisfazione all'accoppiata KVM/QEMU
EB> da un po' senza particolari problemi (il primo lo uso sui server che
EB> supportano VT, il secondo sui client che non hanno VT, ma che uso
EB> con l'apposito modulo kernel). In cosa li hai trovati carenti?
Inizialmente QEMU senza  il modulo kqemu era assai  poco utilizzabile in
produzione (troppo  lento); con la  "liberazione" di kqemu le  cose sono
migliorate decisamente.  In generale, pero`,  QEMU (con KVM o  kqemu che
sia) deve  ancora migliorare le prestazioni  a livello di  rete, disco e
video: stanno lavorando sulla paravirtualizzazione di questi componenti,
per cui spero che tra qualche mese o un anno le cose si sistemino.
Anche  le interfacce  di  controllo della  macchina virtuale  richiedono
ancora parecchio lavoro:  sui nuovi PC dei laboratori  (BTW, qui ci sono
alcune foto ricordo di come erano belli i laboratori nel "giorno zero" e
di come non lo saranno mai  piu` dopo la calata dei barb... er, l'arrivo
delle matricole:  
http://www.gest.unipd.it/~jake/labinf_2007/
) ho rinun-
ciato a KVM  in favore di VirtualBox proprio per  le performance video e
rete  e per  la migliore  interfaccia di  gestione delle  periferiche di
quest'ultimo (cfr. montare  una penna USB con KVM/QEM  o con VirtualBox:
il meccanismo sottostante e` circa lo stesso, ma l'interfaccia...).
Xen l'ho messo da parte perche' su una macchina senza VT non mi consente
di installare Windows (uno o  due server, purtroppo, mi servono: ci sono
dei software di licenza, l'antivirus  e un altro paio di applicazioni di
controllo remoto che funzionano solo sotto Windows).
Alla fine e`  meglio scegliere un solo ambiente  e non disperdere troppo
le energie in  direzioni diverse per tenere in  piedi tecnologie diverse
(i test sono un'altra faccenda: qui intendo "in produzione").
