Allarme Uc-suite "Address already in use"

[Lucky]

Ciao a tutti, su un LX V3_R3.4.0_003 virtualizzato (sles 11 sp1)
ricevo un allarme che non riesco ad interpretare:
[ 09:53:47.350669][IN][runlevel1_start                         ][3064710896] Database connection is established
[ 09:53:47.351667][DB][VSConnectionServer::Initialize          ][3064710896]     Could not retrieve GeneralServerHost () from DB, trying AdminReceiver ...
[ 09:53:47.355340][DB][VSConnectionServer::Initialize          ][3064710896]     Starting TPConnection Server on port 8779, host = 192.168.0.201
[ 09:53:47.355456][ER][VSConnectionServer::Initialize          ][3064710896]     Failed to open port 8779: Address already in use
[ 09:53:47.355486][CT][runlevel1_start                         ][3064710896] Could not Initialize() the ConnectionServer object
Nelle righe leggo: "Address already in use" ma non credo intenda l' indirizzo ip.
A qualcuno è già capitato o sa indicarmi dove recuperare documentazioni degli allarmi via e-mail del uc-suite?
 
ciao

[Kimera]

La porta 8779 (UDP ed anche TCP) non è utilizzata nell'OSO per permettere agli utenti la connessione al myPortal dagli host client (in UDP per l'Auto-Discovery del Server)? 192.168.0.201 è l'IP Address dell'OSO LX? sembrerebbe come se la porta fosse già utilizzata (Bound).

Da quanto lo fa? non è che puoi verificare se accade anche con (almeno) OSO LX V3 R3.5.0 (G.A.)?

Saluti, Kimera.

[Lucky]

Si, l' indirizzo é del lx.
Quindi secondo te non dovrebbe essere "address..." ma "port already in use".

Strano, come può essere che la porta venga usata da un altro servizio di linux ( non essendo standard) senza averla impostata appositamente?

Potrebbe dipendere forse dall' mx (gateway)?

[Kimera]

Calma...l'estratto dei Log appartiene all'OSO LX? se "Sì" non vedo cosa possa centrare l'OSO MX (soprattutto se la 8779 è usata per il myPortal offerto dall'OSO LX ai Clients).

La frase topica secondo me è: "Could not retrieve GeneralServerHost () from DB, trying AdminReceiver ..."

Chissà cosa si aspetta di ottenere la funzione GeneralServerHost()? ...l'indirizzo IP dell'OSO LX (localhost o l'IP assegnato alla ethx)? ...la connessione al DB pare OK (established).

Saluti, Kimera.

Edit: una lista (forse non esaustiva) dei UC Suite System Errors inviabili via E-Mail (come da aggiunte all'ultima versione - Last Changes - della documentazione tecnica OSO V3 al 21/06/2013 "OpenScape Office V3 Letzte Änderungen"):

NULL monitor
Could not notify CallHandler
Terminate call failed
Unable to load VM Structure from file
Alsa stuck
Alsa cancel failed
MEN CallID 0
NULL alsa handle
Database connection failed
Rules engine logic failure
Config schema format failure
90% Disk usage mark
Main: Could not connect to the database !
Main: Could not load the configuration from the database!
Main: Could not open configuration file !
Main: Could not read the settings from the configuration file !
A segmentation fault was detected.
Database logic error
Database schema error
ConnectionServer failed to start
MultisiteSync failed to start
Multisite failed to start
TransferManager failed to start
IPC failed to start
ConferenceManager failed to start
CallManager failed to start
MediaProcessing failed to start
Queues failed to start
Import failed to start
DataClient failed to start
DirectoryClient failed to start
DirectoryServer failed to start
FV failed to start
IM failed to start
Switch failed to start
No Switches
Exchange Integration failed to start
Outbound Fax failed to start
SQL connection pool failed to start
Task scheduler failed to start
Trunks failed to start
Unknown switch type
Users failed to start
MEB has been disconnected
MEB ACK timeout
Switch Hearbeat timeout

[Lucky]

Dalle tue indicazioni, si potrebbe desumere che non recuperando l' indirizzo ( tra le parentesi non c' è scritto nulla) lo interpreta come qualsiasi indirizzo o nessun indirizzo e quindi collide per forza, ecco perchè address already in use.
Dato che il datastore utilizzato sembra avere problemi, suppongo che ci siano problemi di lettura disco (ad esempio latenze eccessive indicate dai log del server stesso),  quindi non recuperando il dato necessario non riesce ad interpretarlo e lo indica come indirizzo assente.
Bah!
Grazie per il supporto, ma suppongo che dovro' ricreare il tutto e passare su un nuovo server più stabile e performante.
Ciao

[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.

[Lucky]

Credo di non averti capito, secondo te thick o thin, quindi preallocated o no?

[Kimera]

Preallocated.

Ho scritto male, corretto viene:

"La cosa migliore, soprattutto in ambienti dove la densità di VM e lo spazio disponibile nella NAS/SAN non sia così problematico (o costoso), è utilizzare "Preallocated" (zeroed on demand) o, al massimo, in seconda battuta "eagerZeroedThick" se hohai dei dubbi sullao qualità dello spazio di storage che ti viene offerto."

Vedi qui.

Comunque un conto sono il Dischi Virtuali ed un altro è lo storage fisico ed in che modo si accede a quest'ultimo. Sembrerà assurdo ma se si vuole stare sul semplice si può evitare di (ab)usare del concetto di Virtualizzazione spazzando via tutte le problematiche - e il tempo che ti fanno perdere - che si possono incontrare se la si architetta sottovalutando dal principio tutti gli aspetti che andrebbero invece considerati...ritornando al caso di una semplice macchina fisica.

Saluti, Kimera.