CSA: Server applicazioni, cluster, messaggi multicast e utilità di bilanciamento del carico (solo On Premise)

ccppmop1591
È possibile impostare i messaggi multicast, le utilità di bilanciamento del carico e la persistenza della sessione (sessioni permanenti). CSA consente inoltre di scalare, condividere dischi, distribuire file su server e gestire più istanze dell'applicazione o del servizio in background. È inoltre possibile configurare i database di reporting, nonché eseguire il clustering dei database Oracle e regolare i computer virtuali Java HotSpot di Sun.
2
Scala di
Classic PPM
Con il termine
scala
si fa riferimento alla complessa attività di determinazione dei servizi da eseguire e dei computer da utilizzare. In fase di scala, l'obiettivo è bilanciare prestazioni e affidabilità. Anche le installazioni più piccole di
Classic PPM
comprendono più computer. Ad esempio, un'installazione è dotata in genere della seguente configurazione:
  • Un server per il database e un altro per il resto, o
  • Un computer per
    Classic PPM
    , collegato a un data center di proprietà di un gruppo che effettua la gestione del database esternamente.
Le installazioni medio-grandi di
Classic PPM
, a seconda dei requisiti di prestazioni e affidabilità, di solito presentano servizi ridondanti in esecuzione su più computer dedicati.
Messaggi multicast
Classic PPM
fa ampio uso dei messaggi multicast nei cluster. Beacon è un servizio di bootstrap in esecuzione su tutti i computer gestiti in un cluster. Il Beacon viene utilizzato per gestire e monitorare i servizi di
Classic PPM
su ciascun server. Viene inoltre utilizzato per applicare le patch e gli aggiornamenti rilasciati dal server applicazioni di
Classic PPM
.
I servizi Beacon impiegano un meccanismo di rilevamento dinamico mediante multicast. Ciascun servizio Beacon invia un messaggio di rilevamento ogni 5 secondi per indicare la sua presenza ai nodi in ascolto nel cluster. L'Amministrazione di sistema di
Classic PPM
ascolta questi messaggi beacon di rilevamento e li utilizza per registrare i nodi cluster attivi. Alla ricezione di un messaggio di rilevamento Beacon, l'Amministrazione di sistema di
Classic PPM
confronta la propria password con quella del servizio Beacon. Se la verifica ha esito positivo, l'Amministrazione di sistema di
Classic PPM
aggiunge il server al proprio elenco di server.
L'Amministrazione di sistema di
Classic PPM
esegue inoltre il ping di ciascun servizio beacon direttamente ogni dieci (10) secondi per determinare se tale servizio è attivo. Il ping consiste nell'invio di un messaggio TCP (unicast) sulla rete per ogni servizio Beacon registrato. Il multicast risulta vantaggioso poiché il messaggio viene inviato una sola volta sulla rete e ricevuto più volte dalle parti interessate. Trattandosi di un messaggio UDP, non TCP, è anche meno pesante. Il messaggio unicast, invece, deve essere inviato sulla rete una volta per ogni parte interessata. Perciò, il multicast è perfetto per applicazioni di rilevamento e controllo dinamici come Beacon.
Il servizio Beacon non è l'unico a utilizzare il multicasting. Oltre ai servizi Beacon, quelli di gestione della cache nei server applicazioni e in background trasmettono i propri messaggi per gestire la coerenza della cache. Questi messaggi non contengono dati effettivi, ma informano solo i server remoti quando i dati residenti sono obsoleti ed è necessario ricaricarli dal database. Questo processo viene definito scaricamento della cache. Ogni volta che la cache viene scaricata su un determinato server in un cluster, viene inviato un messaggio sulla rete. Tutti gli altri servizi app e bg ricevono il messaggio che indica di svuotare le rispettive cache dei dati.
Classic PPM
utilizza un thread di monitoraggio della sessione per evitare il timeout imprevisto delle sessioni sui server diversi. Questo thread viene trasmesso ogni 5 minuti con un messaggio più lungo che contiene gli ID delle sessioni attive. Quando una sessione non è più attiva su un server, viene scaricata da tutti i server. Quando una sessione rimane attiva, viene contrassegnata come tale su tutti gli altri server per impedire la disconnessione dell'utente.
I server in un cluster di
Classic PPM
devono essere in grado di inviare e ricevere messaggi multicast. In una subnet normale, questa attività è consentita per impostazione predefinita.
Si consiglia di mantenere tutti i server nella stessa subnet. Se è obbligatorio utilizzare server in posizioni diverse con subnet differenti, creare un bridge multicast tra di essi.
Questa procedura sembra creare traffico UDP extra. Tuttavia, quando si confronta la quantità di dati che viaggiano tra il database, il server di report, i server applicazioni e i client, i messaggi nel cluster non sono rilevanti. Il traffico extra rappresenta una piccola percentuale del traffico di rete complessivo. Spesso, al concetto di broadcast si associa l'idea di sovraccarico delle reti. In realtà, tutto il traffico di rete è in broadcast. Tutti i messaggi TCP (unicast) su una subnet raggiungono ogni nodo nella stessa, proprio come i messaggi UDP (multicast). La differenza è che i messaggi TCP sono grandi il doppio o il triplo dei messaggi UDP. Poiché l'arrivo a destinazione dei messaggi TCP è garantito, sono richiesti molti handshake per pacchetto. Per questo motivo le dimensioni dei messaggi TCP sono maggiori. Inoltre, questi messaggi multicast in
Classic PPM
sono minuscoli rispetto alla richiesta di database media. Con più server applicazioni, di background o di report su un sistema ad elevate prestazioni, si eseguono centinaia di richieste di database per secondo. I compatti messaggi UDP attivati per server ogni 5 secondi non sono niente in confronto.
Clarity
ha introdotto JGroups nell'architettura per il controllo dei messaggi multicast a livello di applicazione. È possibile eseguire il livello di applicazione senza dover attivare precedentemente il multicasting. Tuttavia, esso riguarda in particolare il motore del processo e quello in background. È possibile che questi due servizi non funzionino come previsto.
Clarity
14.x e le release successive richiedono l'attivazione del multicasting a livello di router, affinché i servizi cluster di
Clarity
possano comunicare correttamente.
Utilità di bilanciamento del carico e persistenza della sessione (sessioni permanenti)
Classic PPM
supporta le utilità di bilanciamento del carico hardware o software.
Classic PPM
è senza stato e progettato per funzionare con un modello round robin e altri modelli di distribuzione. Tuttavia, è maggiormente efficiente in termini di memoria e prestazioni quando la sessione utente rimane su un server. L'aggiunta di più server applicazioni offre un aumento delle prestazioni.
La persistenza della sessione è richiesta in un ambiente con bilanciamento del carico. La persistenza è necessaria indipendentemente dall'algoritmo utilizzato o dal numero di risorse contenute sul server.
Considerare un algoritmo di bilanciamento del carico che distribuisce le singole richieste per una singola sessione utente su cinque server applicazioni. In tal caso, ciascun server carica e memorizza in cache i dati di quella sessione utente. La memoria utilizzata risulta cinque volte superiore rispetto alla quantità che verrebbe utilizzata se la persistenza della sessione fosse abilitata e la sessione utente restasse solo su un server.
Si consiglia di abilitare l'opzione per la persistenza della sessione sull'utilità di bilanciamento del carico.
Configurare l'utilità di bilanciamento del carico per utilizzare la persistenza di sessione provvisoria. In questo modo, le richieste verrebbero inviate dalla stessa sessione utente allo stesso server. Se il server è sovraccarico mentre un altro è inattivo, la permanenza viene spostata dal server sovraccarico a quello inattivo. Poiché
Classic PPM
è senza stato, supporta completamente questo processo. Inoltre, se il server sovraccarico viene disattivato, le sessioni non vengono perse. Supponendo che l'utilità di bilanciamento del carico individui correttamente il server disattivato e reindirizzi le richieste a un altro, quelle sessioni utente sono pienamente disponibili sul nuovo server.
Condivisione dei dischi
In un cluster di
Classic PPM
, è necessario che più servizi app e bg utilizzino lo stesso disco per l'indicizzazione di ricerca. I servizi devono inoltre utilizzare lo stesso disco per l'archiviazione dei documenti, eccetto se i file vengono archiviati nel database. Nell'Amministrazione di sistema di
Classic PPM
, verificare che ogni server con servizi di applicazione o di background punti la proprietà Ricerca nella directory di indici allo stesso disco condiviso. Salvo per i file archiviati nel database, anche la proprietà Directory dell'archivio di file deve puntare allo stesso disco condiviso.
La condivisione dei dischi può essere più efficace con una soluzione SAN (Storage Area Network) o NAS (Network Attached Storage). È ammessa anche la condivisione di file di Windows o Unix NFS.
Distribuzione di file ai server nel cluster
Distribuire i file aggiornati a tutti i server nel cluster. I file aggiornati includono quelli aggiornati sul server applicazioni tramite personalizzazione dei temi di interfaccia utente o tramite l'installazione di correzioni rapide, patch o aggiornamenti.
È inoltre possibile visualizzare lo stato della distribuzione facendo clic su NSA Logs (Registri NSA) e selezionando nsa-ca.log. Al termine, la finestra di stato si chiude e viene visualizzata la pagina dell'elemento padre. La pagina di distribuzione mostra la data e la versione dell'ultima distribuzione.
Procedere come descritto di seguito:
  1. Accedere ad Amministrazione sistema
    Classic PPM
    (CSA).
  2. Aprire la sezione Distribuzione, quindi fare clic su Distribuisci tutto.
    Questa opzione consente di distribuire tutti i file aggiornati nella directory principale di
    Classic PPM
    .
  3. Selezionare uno o più server e fare clic su Distribuisci.
Istanze multiple di servizi di applicazione o di background
Se si utilizzano mainframe con grandi quantità di memoria fisica disponibile, eseguire più istanze dei servizi app e bg su tali computer. Dal punto di vista di
Classic PPM
, non cambia nulla rispetto all'esecuzione dei servizi su due computer differenti. È possibile utilizzare un computer al massimo, con il vantaggio di maggiori prestazioni e affidabilità derivate dai servizi multipli.
CSA facilita le istanze multiple grazie all'azione Clona. L'azione consente di creare una copia del servizio app o bg desiderato con un maggior numero di porte e nomi servizi disponibili per evitare conflitti.
Dopo avere clonato un servizio, è possibile avviare, interrompere e altrimenti gestire le nuove istanze del servizio come l'originale.
Procedere come descritto di seguito:
  1. Accedere a CSA.
  2. Aprire Pagina iniziale e fare clic su Tutti i servizi.
  3. Selezionare la casella di controllo per il tipo di servizio che si desidera clonare, quindi fare clic su Clona.
  4. Se necessario, accedere al server in cui è stato creato il servizio e modificare le impostazioni clonate.
Configurazione di un'origine dati esterna dedicata
È possibile configurare
Classic PPM
affinché utilizzi un database secondario per l'esecuzione dei report. Verificare che il database secondario sia sincronizzato con il database di produzione di
Classic PPM
. Quando il database di reporting è troppo in ritardo il database di produzione, si possono riscontrare dei problemi. Ad esempio, i dati utente o di istanza da includere nel report non esistono nel database di reporting.
Se configurato come illustrato nella seguente procedura, il report viene eseguito soltanto rispetto al database di reporting. È necessario sincronizzare tutte le tabelle richieste dal report, incluse le tabelle utente e di protezione. Se si sincronizza un sottoinsieme delle tabelle del database di produzione, selezionare le tabelle corrette per supportare i report.
Procedere come descritto di seguito:
  1. Accedere a CSA e da Pagina iniziale fare clic su server.
  2. Fare clic sull'icona Proprietà del server che si desidera configurare.
  3. Fare clic sulla scheda secondaria Database.
  4. Nella sezione Connessione interna: Niku fare clic su Nuova connessione esterna.
  5. Completare le proprietà adeguate per il database di report:
    • ID
      Definisce l'ID utilizzato per identificare questa connessione in seguito.
    • Nome servizio
      Fa riferimento a una voce TNS valida (Oracle) o a una voce ODBC (MS SQL Server) sul server di report.
  6. Salvare le modifiche.
  7. Fare clic sulla scheda secondaria Reporting.
  8. Compilare il seguente campo:
    • ID database
      L'ID del database di
      Classic PPM
      viene utilizzato per recuperare le informazioni di database durante l'esecuzione dei report. Questo ID corrisponde agli ID delle connessioni di database definite nella pagina
      Server: Proprietà
      del database.
      Valori
      : Niku e Sistema
      Valore predefinito
      : Niku
      Obbligatorio:
      No
  9. Salvare le modifiche.
  10. Ripetere le fasi precedenti per tutti i server nel cluster di
    Classic PPM
    .
  11. Riavviare tutti i servizi Applicazione (app)
    Classic PPM
    e Background (bg)
    Classic PPM
    nel cluster.
  12. Su ciascun server di report nel cluster:
    1. Creare una voce TNS (Oracle) oppure ODBC (SQL Server) con le proprietà di connessione adeguate per puntare al server di database di reporting dedicato.
    2. Verificare che il nome scelto corrisponda al nome di servizio della connessione esterna in Amministrazione di sistema
      Classic PPM
      .
  13. Installare i report.
Nella release 14.4 e nelle versioni precedenti, era possibile utilizzare questi passaggi per installare i report, l'universo di
Classic PPM
e altri contenuti di reporting sul server di report BusinessObjects Enterprise. Nella release 15.1 e versioni più recenti, è possibile utilizzare questi passaggi per configurare un database transazionale parallelo per l'esecuzione dei report in sostituzione o in aggiunta all'utilizzo dello schema del data warehouse. I passaggi son validi per l'aggiunta di qualsiasi altra origine dati nelle versioni On-Premise di
Clarity
. Ad esempio, aggiungere uno schema di transazione replicato, data warehouse esterno o qualsiasi schema di applicazioni di terze parti allocato in un database Oracle o MS SQL.
Clustering di database Oracle
Classic PPM
supporta l'utilizzo della funzione di clustering Oracle per ottenere scalabilità, ridondanza e failover più elevati rispetto a quanto possibile con un singolo server Oracle.
Procedere come descritto di seguito:
  1. Se necessario, esportare il database Oracle esistente su server singolo dall'istanza di nodo singolo e importarlo nel cluster.
  2. Accedere a CSA.
  3. Aprire Pagina iniziale, quindi fare clic su Server.
  4. Fare clic sull'icona Proprietà del server per il quale si desidera modificare le proprietà.
  5. Selezionare la scheda secondaria Database.
  6. Modificare le proprietà seguenti per la connessione di database:
    • Specifica URL
      Selezione:
    • URL JDBC
      URL JDBC per un cluster di Oracle completo. Questo URL è un prefisso jdbc seguito dalla specificazione TNS completa.
      Gli URL JDBC devono contenere il parametro ServiceName che fa riferimento a una voce TNS sull'host di Oracle specificato con la configurazione RAC desiderata.
      Ad esempio:
      jdbc:clarity:oracle://server:1521;ServiceName=serviceTNS;BatchPerformanceWorkaround=true;InsensitiveResultSetBufferSize=0;ServerType=dedicated;supportLinks=true
      Esempi alternativi:
      Integrare i server RAC nell'URL stesso con la sintassi DataDirect seguente:
      jdbc:clarity:oracle://server1:1521;ServiceName=serviceTNS;BatchPerformanceWorkaround=true;InsensitiveResultSetBufferSize=0;ServerType=dedicated;supportLinks=true;AlternateServers=(server2:1521;server3:1521);LoadBalancing=true
      Server Oracle RAC con listener SCAN:
      jdbc:clarity:oracle://oracscan:1521;ServiceName=serviceTNS;BatchPerformanceWorkaround=true;InsensitiveResultSetBufferSize=0;ServerType=dedicated;supportLinks=true;AlternateServers=(oracscan:1521);FailoverMode=Select;ConnectionRetryCount=20;ConnectionRetryDelay=15;LoadBalancing=true"
      Oracle DataGuard:
      jdbc:clarity:oracle://PRIMARY_SERVER:1521;ServiceName=CLARITY_RW;AlternateServers=(PHYSICAL_STANDBY_SERVER:1521);ConnectionRetryCount=20;ConnectionRetryDelay=15;;BatchPerformanceWorkaround=true;InsensitiveResultSetBufferSize=0;ServerType=dedicated;supportLinks=true
      Per ulteriori informazioni, consultare le seguenti risorse:
      Documentazione di Oracle per la configurazione di RAC, DataGuard, SCAN e per l'impostazione dei servizi.
      Sito Web di DataDirect. Cercare informazioni sull'utilizzo di DataDirect Connect per JDBC con Oracle Real Application Clusters (RAC).
  7. Salvare le modifiche.
  8. Per convalidare le impostazioni del database, eseguire un report sullo stato di sistema per ciascun server. Consultare la sezione Esecuzione di un report sullo stato.
  9. Nel caso di server applicazioni Apache Tomcat, riavviare tutti i servizi in Amministrazione di sistema
    Classic PPM
    .
Regolazione del computer virtuale Java HotSpot di Sun
Queste informazioni sono valide solo per gli ambienti con computer virtuali Java HotSpot di Sun.
Una corretta regolazione dei computer virtuali Java HotSpot di Sun è importante durante la configurazione e la manutenzione di
Classic PPM
. Mentre una corretta regolazione è importante per il servizio di background, è ancora più importante per qualsiasi servizio di applicazione eseguito nel cluster. Questa sezione si concentra sull'applicazione.
Consultare la documentazione relativa a tutte queste impostazioni nel sito Web di Oracle. È inoltre possibile consultare i partner dei Broadcom Services per ricevere assistenza con il ridimensionamento dell'heap JVM in base all'implementazione in uso.
Sono disponibili molte opzioni per regolare un ambiente di computer virtuale Java HotSpot.
Procedura consigliata:
utilizzare almeno i valori seguenti:
  • Maximum Heap
    -Xmx<size>m
    L'impostazione di heap massimo determina la maggior parte di memoria che il sistema operativo locale assegna al computer virtuale Java. Il sistema operativo locale non alloca immediatamente molta memoria all'avvio, ma può farlo durante l'esecuzione del processo. Come procedura ottimale, si consiglia di impostare questo valore almeno su 2048m (2 GB), anche per le installazioni di piccole dimensioni. Per migliorare le prestazioni e ridurre gli errori relativi all'esaurimento della memoria, impostare questo valore a 4 o 8 GB per i set di dati di maggiori dimensioni. Ad esempio,-Xms1024m -Xmx4096m.
  • Minimum Heap
    -Xms<size>m
    L'impostazione di heap minimo è importante per evitare al computer virtuale uno sforzo inutile durante l'espansione dell'heap man mano che l'applicazione viene potenziata. Specificare l'heap minimo il più possibile vicino a valori reali. Se l'applicazione utilizza solitamente 1,2 GB di RAM, impostare l'heap minimo su 1200m. È possibile impostare le dimensioni di heap minimo e massimo in modo da farle coincidere. Si tratta di un'attività più semplice per garbage collector del computer virtuale. Con queste impostazioni, inoltre, il processo JVM alloca l'heap massimo completo dal sistema operativo all'avvio, che è più uniforme. Questo processo richiede all'utente di misurare i requisiti di allocazione di memoria effettiva sul server.
  • Parallel Garbage Collector
    -XX:+UseParallelGC
    Il garbage collector parallelo è consigliato per qualsiasi server con due o più CPU. Il garbage collector parallelo può essere installato su tutti i server. I server con meno di due CPU ignorano questa impostazione.
  • New Ratio
    -XX:NewRatio=<size>
    Il computer virtuale HotSpot separa gli oggetti in spazi nuovi e vecchi basati sulle età di oggetti in memoria. Gli oggetti di breve durata tendono a rimanere nello spazio nuovo (o Eden) e vengono raccolti prima di spostarsi altrove. Per gli oggetti di lunga durata viene eseguita la migrazione nello spazio vecchio (o Tenured). L'impostazione New Ratio in realtà non definisce la dimensione esplicita dello spazio nuovo, ma piuttosto un rapporto tra lo spazio vecchio e il nuovo. Un'impostazione -XX:NewRatio=3 si traduce in un rapporto di 1 a 3, in cui la nuova generazione è pari a 1/3 della dimensione della vecchia generazione. Le applicazioni che creano ed eliminano rapidamente molti oggetti temporanei di breve durata, come ad esempio le applicazioni sul lato server come
    Classic PPM
    , richiedono un nuovo spazio più ampio della media. In caso contrario, il nuovo spazio è eccessivamente pieno, mentre lo spazio vecchio è poco popolato. L'impostazione predefinita per New Ratio varia in base alla piattaforma. Per evitare l'insorgere di problemi in
    Classic PPM
    , indipendentemente dalla piattaforma, impostare New Ratio su un valore da 1 a 2, ossia
    XX:NewRatio=2
    .
  • Maximum Permanent Size
    -XX:MaxPermSize=<size>m
    Oltre agli spazi nuovi e vecchi, c'è un terzo spazio denominato Permanent. In questo spazio risiedono gli oggetti permanenti, essenzialmente le definizioni di classe Java. Questo spazio non cresce con l'uso dell'applicazione, ma con le dimensioni. Più classi vengono caricate nell'applicazione, maggiore sarà la dimensione permanente. L'impostazione predefinita di 64m si è rivelata troppo piccola. In Apache Tomcat, l'impostazione predefinita di
    Classic PPM
    per questo spazio è 256m.