OpenScape > OpenScape - Office (OSO MX/LX/HX)

Allarme Uc-suite "Address already in use"

<< < (2/3) > >>

Alessandro - Telcom:
Si magari fai prima così...ma una scansione con nMap? giusto per capire se la porta è davvero in uso o no.

Lucky:
Sembra che il problema sia di performance/stabilità degli storage.
Prima di rifare il tutto il sisgtemista ha voluto clonare il sistema e trasferirlo su un altra macchina con altri storage e sembra che i problemi precedenti siano spariti.
Ovviamente dovremo migrare le licenze, ma attendiamo i test.
Ho un dubbio sul parametro hpet dato che avevamo installato sles 11 sp1.
Se impostarlo o meno e dove inserirlo, qualcuno ha già provato e ha notato differenze?
 

Kimera:
Che indenti per storage? lo storage dove risiede la macchina virtuale oppure il filesystem della macchina virtuale stessa (dove, tra le altre cose, risiede il DB di OSO)?

La virtualizzazione non è una cosa poi così banale (intendo: una buona architettura sottostante al sistema di virtualizzazione...)...tra un pò sentiremo di VMware che viene fatto girare sul PC di casa con la pretesa di avere prestazioni ed affidabilità che si ottengono in sala server (fatta a modo)!

Ti conviene partire con un LX V3 R3.5.1 (019)...sono stati risolti parecchi problemini rispetto alla R3.4.0 (003) in questi 6 mesi; ovviamente sempre utilizzando SLES 11 SP1 (con gli updates forniti da Siemens) come OS ospite (virtualizzato o meno).

Saluti, Kimera.

Lucky:
Come storage intendo dove risiede il file system, ossia non nella stessa macchina e addirittura in un armadio di rete remoto.
Ho proposto la reimplementazione totale dato che a mio parere la parte di virtualizzazione è stata presa sottogamba, ma il sistemista interno ha deciso di gestire lui una migrazione su un altra macchina senza ricreare il tutto.
Ho una nota per quanto riguarda il provvisioning dei dischi:
Nel manuale (siemens installazione linux) specificano thin provvisioning, mentre vmware per default propone thick, se non ho capito male per le performace sarebbe meglio thick (avendo le risorse) dato che la dimensione disco viene allocata subito alla creazione, mentre con thin dovendo variarla in base alle esigenze impegnerebbe le risorse della macchina diminuendo così le performance (lascando perdere la parte di zeroing).
A mio parere la migliore configurazione per performance dovrebbe essere: "eager zeroed thick". Che ne dite?
In effetti il sistemista ha clonato la macchina ma al posto di thin che era in precedenza l' ha creata come thick e il server sembra molto più reattivo e stabile.
 
Ciao
 

Kimera:
Io sicuramente non userei "Thick" che, in un certo senso, è sconsigliabile rispetto a "Thin" provisioning. La cosa migliore, soprattutto in ambienti dove la densità di VM e lo spazio disponibile nella NAS/SAN non sia così problematico (o costoso) useri sicuramente "Preallocated" (zeroed on demand) o, al massimo, in seconda battuta "eagerZeroedThick" se ho dei dubbi sullo storage.

Tutto dipende da come l'Hypervisor accede allo Storage Pool, dall'Hypervisor stesso (c'è differenza) e da come quest'ultimo è stato architettato (NAS? SAN? protocollo iSCSI?), da come vengono configurati i dischi virtuali...e da com'è lo storage fisico sul quale, alla fine, converge tutto (Hypervisor a parte)

Magari ai sistemisti basta la parola VMWare ma, secondo me, c'è molta più carne al fuoco quando vai a guardare come architettare nel dettaglio un sistema di virtualizzazione ed il sistema di storage fisico sul quale si appoggia.

Saluti, Kimera.

Navigation

[0] Message Index

[#] Next page

[*] Previous page