Preparazione › Note di rilascio › Problemi noti › Note importanti

Note importanti

1. L'ALD non viene più utilizzato per installare/aggiornare le griglie e per importare cataloghi e applicazioni. Backbone Fabric Controller (BFC) ha preso il suo posto. BFC è un'applicazione GUI intuitiva basata sul Web che viene utilizzata per creare e gestire tutte le griglie di CA AppLogic all'interno di un'unica backbone. Consultare la documentazione di BFC per informazioni sulle modalità di download e installazione di BFC e per il suo utilizzo per la gestione delle griglie di CA AppLogic. Per importare cataloghi e applicazioni nella griglia (ovvero, "system_ms" fornito con CA AppLogic), copiare il catalogo/applicazione sul volume impex della griglia e utilizzare i comandi "cat import" e "app import" di CA AppLogic.
2. Oltre a Xen, CA AppLogic 3.x supporta ora anche l'hypervisor VMware ESX. Se da un lato CA AppLogic 3.x mantiene tutte le caratteristiche e le funzionalità di entrambi gli hypervisor, occorre considerare alcuni importanti aspetti quando si utilizza VMware ESX con CA AppLogic:
   • L'elenco di compatibilità hardware (HCL) di ESX è più restrittivo rispetto a quello di Xen. Si raccomanda di verificare che i propri server siano indicati nell'elenco di compatibilità hardware di ESX prima di utilizzare CA AppLogic 3.x. L'hardware selezionato per la griglia basata su ESX deve essere verificato confrontandolo con gli HCL di ESX, CA AppLogic-Xen (specificati nella sezione Compatibilità dell'hardware riportata sopra) e CentOS 5.5.
   • Quando le griglie sono sottoposte a un carico eccessivo, quelle che utilizzano ESX eseguono alcune operazioni più lentamente rispetto a quelle che utilizzano Xen. Ciò è dovuto al fatto che CA AppLogic utilizza le API di ESX per controllare le macchine virtuali presenti su ogni server. Tali API sono più lente rispetto a quelle di Xen. Le operazioni in cui è più facile osservare una certa lentezza sono le seguenti:
     • Avvio di un'applicazione: l'avvio delle appliance può richiedere 1-2 minuti in più quando le griglie sono sottoposte a un carico eccessivo
     • grid info, srv list, srv info: questi comandi potrebbero richiedere diversi secondi o 1-2 minuti in più, quando le griglie sono sottoposte a un carico eccessivo
   • ESX ha un overhead di memoria superiore rispetto a Xen. Un'applicazione distribuita su due server su una griglia basata su Xen può superare la disponibilità di due server identici in esecuzione su una griglia di CA AppLogic basata su ESX. Per questo motivo è consigliabile che i server basati su ESX dispongano di almeno 4-8 GB di memoria.
   • Appliance che supportano ESX:
     • Gli strumenti VMware devono essere installati su tutte le appliance (per impostazione predefinita tutte le appliance fornite in dotazione con CA AppLogic 3.x dispongono degli strumenti VMware). Gli strumenti VMware garantiscono che la console grafica funzioni correttamente e che la chiusura dell'appliance non richieda un tempo eccessivo. Se gli strumenti VMware non vengono installati, la console grafica risulta molto difficile da utilizzare (è difficile controllare il cursore del mouse) e la chiusura dell'appliance richiede 15 minuti.
     • Quando si utilizza un'appliance di Windows, questa deve avere la corretta impostazione esx_os_name nella stringa delle opzioni di virtualizzazione che è memorizzata nel descrittore dell'appliance. È possibile aggiornare l'impostazione per l'appliance di Windows. Se si installa una nuova appliance Windows mediante iso2class, esiste un parametro obbligatorio della riga di comando che viene utilizzato per impostare correttamente esx_os_name per la nuova appliance.
     • Per riavviare un'appliance, utilizzare comp restart o riavviare l'applicazione. Se l'appliance viene riavviata dall'interno della appliance stessa, si genererà un errore di avvio (l'appliance non sarà in grado di recuperare la propria configurazione da CA AppLogic).
     • La modalità di configurazione volfix non funziona in appliance eseguite su ESX. L'appliance deve essere convertita in modo da utilizzare la modalità di configurazione DHCP. Questo influisce soltanto sulle appliance precedenti a CA AppLogic 2.1 e le release precedenti. È possibile convertire l'appliance (Modalità di aggiornamento delle applicazioni per utilizzare il nuovo kit di appliance (APK), Aggiornamento di un'appliance per l'utilizzo della modalità di configurazione DHCP) per utilizzare la modalità di configurazione dhcp. Consultare la Guida per gli sviluppatori di appliance nella sezione Kit per l'appliance per informazioni su come convertire l'appliance in modo che utilizzi la modalità di configurazione dhcp.
3. CA AppLogic 3.x introduce i controlli di accesso basato sui ruoli (RBAC, Role-based Access Control). RBAC offre la possibilità di concedere autorizzazioni relative a un oggetto (template dell'applicazione, istanza applicazione, catalogo o griglia), esercitando un controllo su di esso. Per impostazione predefinita, quando si crea un nuovo utente su una griglia, questi dispone di un accesso limitato agli oggetti della griglia. L'utente non dispone, ad esempio, delle autorizzazioni di accesso alla griglia per impostazione predefinita. È necessario configurare i diritti di accesso (Amministrazione di utenti e gruppi, Panoramica di RBAC) appropriati per gli utenti che accedono alle griglie.
4. Quando si utilizza l'API Web per accedere alla griglia di CA AppLogic 3.x, l'applicazione dell'API Web deve essere configurata in modo che l'utente disponga dei diritti di accesso completo alla griglia (accesso di tipo amministratore).
5. In CA AppLogic 3.x il supporto del sistema operativo da parte delle appliance non è così ampio come nelle precedenti versioni di CA AppLogic. In 3.x, Solaris 10 non è del tutto supportato. OpenSolaris è supportato solo per Xen. Si noti che la produzione di OpenSolaris e di Solaris 10 è stata interrotta da Oracle e sostituita con Solaris Express e Solaris 11.

   Nota: tutte le appliance basate su Solaris sono state eliminate dalla release CA AppLogic 3.5, eccetto il file server di Solaris. Contattare il CA Support se si richiedono tali appliance.

6. CA AppLogic funziona in modo indipendente dal sistema operativo ed è stato progettato per essere utilizzato con sistemi operativi diversi. La sua architettura prevede che tutte le operazioni relative ai volumi (crea/formatta, copia, ridimensiona, controlla/ripristina file system, gestisci) vengano eseguite all'interno di applicazioni di CA AppLogic denominate file e non più dal controller di griglia di CA AppLogic, come nelle versioni precedenti di CA AppLogic. Queste nuove applicazioni denominate file server utilizzano risorse della griglia come qualunque altra applicazione di CA AppLogic. Occorre dunque che la griglia disponga di risorse sufficienti per eseguire una qualunque delle operazioni di volume di CA AppLogic. Si noti che le applicazioni file server non sono utilizzate per volumi raw o per copie di volumi a livello di blocco.
7. Il controller di griglia utilizza il 10% del core (sia nei server basati su ESX che nei server basati su Xen).
8. Poiché tutte le operazioni relative ai volumi vengono ora eseguite mediante applicazioni file server, tali operazioni risultano più lente rispetto a quanto avveniva nelle versioni precedenti di CA AppLogic, dal momento che le applicazioni file server devono essere avviate e interrotte come parte delle operazioni di volume. In genere le operazioni di volume basate su Linux presentano un overhead di 20 secondi, mentre le operazioni di volume basate su Solaris un overhead di 130 secondi.
9. I criteri per l'utilizzo della larghezza di banda di rete vengono applicati a tutte le appliance. Un'appliance non può utilizzare una larghezza di banda superiore a quella configurata per tutti i suoi terminali (la larghezza di banda assegnata comprende tutti i terminali). Assicurarsi che la larghezza di banda configurata per le proprie appliance e applicazioni sia adeguata alle proprie esigenze (in caso contrario le applicazioni potrebbero funzionare a una velocità di rete molto bassa). La larghezza di banda massima per i server di CA AppLogic è 2 GB.
10. Nelle appliance che trasmettono traffico di rete, come i gateway, le utilità di bilanciamento del carico e gli switch con porte, la larghezza di banda risulta in realtà la metà di quella nominale. Ad esempio, una utilità di bilanciamento del carico alla quale siano stati assegnati 100 M di larghezza di banda arriva a utilizzare solo 50 M (a causa del traffico di rete in entrata e in uscita dall'appliance).
11. Prima di accedere alla GUI di CA AppLogic su una griglia di CA AppLogic appena installata o aggiornata, l'utente deve cancellare la cache del browser. In caso contrario la GUI di CA AppLogic potrebbe non funzionare correttamente.
12. È possibile accedere alla shell della griglia tramite un browser Web o utilizzando un client SSH. Per assicurare una maggiore protezione, non sono supportati accessi SSH basati su password eccetto durante l'installazione della griglia.

    Importante: È fortemente consigliato di utilizzare la shell Web fornita con la GUI di CA AppLogic.

13. Quando si accede alla griglia tramite SSH, il nome utente di accesso è sempre root, indipendentemente da quello stabilito per CA AppLogic. Per quanto riguarda gli accessi SSH, gli utenti e i loro ruoli sono identificati in modo univoco dalle chiavi pubbliche SSH.
14. Per poter utilizzare l'interfaccia utente grafica basata sul Web (dashboard, editor e documentazione) è necessario abilitare JavaScript del browser Web e i popup
15. Gli utenti sono responsabili dell'allocazione, dell'assegnazione e dell'utilizzo di indirizzi IP visibili dall'esterno per le applicazioni, mentre CA AppLogic si occupa di tutte le assegnazioni di rete interne
16. BFC imposta tutti i server e i controller della griglia con firewall attentamente preconfigurati e disattiva i servizi di rete non necessari. Dal canto loro, gli utenti e i gestori sono tenuti a verificare le impostazioni di protezione dei loro sistemi.
17. Le prestazioni di rete dei server della rete privata utilizzata per il volume e le comunicazioni tra le appliance vengono misurate in circa 900 Mbps. La prestazioni di rete TCP misurate tra appliance che risiedono in server differenti raggiungono 720-900 Mbps. Quando è in esecuzione Windows, le prestazioni di rete TCP sono circa 940 Mbps, mentre le prestazioni di rete UDP 500-700 Mbps.
18. I limiti relativi alle risorse hardware delle appliance vengono applicati in modo diverso a seconda del tipo di risorsa (CPU, memoria, larghezza di banda). La CPU è "no less than" (non meno di), la memoria è "exactly that much" (esattamente identica a) (incluso l'overhead del computer virtuale), la larghezza di banda è "exactly that much". Il limite delle risorse della CPU può essere convertito in "exactly that much", utilizzando la nuova opzione --cap_cpu durante l'avvio dell'applicazione.
19. Quando si avvia un'applicazione a cui è stata assegnata una quantità minima di CPU, non si può essere certi che tale applicazione riceverà esattamente la quantità di CPU specificata. Se, ad esempio, l'applicazione è stata avviata con cpu=2, è possibile che essa riceva 1.97 CPU, come si osserva sommando le CPU assegnate a tutti i componenti dell'applicazione. Questo fenomeno è dovuto all'arrotondamento degli errori che si verificano durante il tentativo di assegnare CPU a ogni singolo componente.
20. Quando si verifica un errore durante l'avvio di un'applicazione, è possibile che nella shell non vengano visualizzati tutti i messaggi di errore. Per reperire ulteriori informazioni, controllare il log della griglia servendosi del comando list log n=20.
21. Le griglie che devono garantire una scalabilità lineare delle prestazioni devono essere costruite utilizzando server il più possibile uniformi per quanto riguarda il tipo e la velocità della CPU, le dimensioni della memoria e la capacità del disco. CA AppLogic funziona correttamente anche in griglie assemblate con server dotati di quantità diverse di risorse hardware; è tuttavia possibile che tali griglie presentino prestazioni non lineari.
22. Non è prevista alcuna visibilità utente durante il riavvio di un controller di griglia causato da un errore della macchina virtuale del controller di griglia. Se la macchina virtuale del controller di griglia genera un errore e viene riavviata da CA AppLogic, non è prevista alcuna visibilità utente durante il riavvio del controller. Occorrono in genere 1-2 minuti per il riavvio automatico del controller di griglia. Se il controller di griglia non è disponibile per più di 5 minuti, contattare il CA Support.
23. La creazione di un volume NTFS03 produce sempre un volume NTFS08. I volumi NTFS08 possono essere utilizzati con Windows 2003 Server.
24. Il comando net_discover per griglie e server non è supportato in griglie/server basati su ESX.
25. Quando si utilizza una SAN con le griglie di CA AppLogic, assicurarsi che vi siano almeno 500 GB di spazio libero per ogni griglia che utilizza la condivisione di NFS configurata. Ad esempio, se la condivisione di NFS viene utilizzata per 5 griglie diverse, la condivisione dovrà avere 2,5 TB di spazio libero su disco.
26. Quando si utilizza una SAN con le griglie di CA AppLogic, se la condivisione di SAN o NFS passa su offline per un certo periodo, alcuni dei volumi che erano in uso potrebbero essere corrotti. Se la corruzione impedisce l'esecuzione del controller di griglia o impedisce l'avvio delle applicazioni (o altra instabilità della griglia o dell'applicazione), contattare immediatamente il CA Support.
27. Per utilizzare le appliance di CA AppLogic basate sulle ultime distribuzioni del sistema operativo (come Fedora Core, Ubuntu, Debian e CentOS), configurare il nuovo codice di progettazione di campo di 128 sul limite delle appliance. Questo nuovo codice di progettazione di campo istruisce CA AppLogic a utilizzare uno stile di nome di periferica più recente per i volumi di appliance che sono utilizzati specificatamente da tali distribuzioni più recenti. Se non viene specificato un codice di progettazione di campo di 128, le appliance basate su queste nuove distribuzioni non avranno esito.
28. Se il database BFC principale o di replica viene perso o corrotto, è possibile recuperarlo tramite un backup automatico che viene sempre eseguito a partire dalla versione 3.1 di BFC. In realtà, questi backup sono conservati in una sottodirectory del database primario in modo da non costituire una sostituzione della configurazione di una replica (questi backup vengono scritti anche in una sottodirectory della replica se configurata). Per ripristinare dal backup più recente:
    • Attendere un paio di minuti dopo il completamento delle operazioni di tutte le griglie attive per assicurarsi che il backup sia aggiornato.
    • Effettuare l'accesso al sistema BFC come root.
    • Eseguire /bin/db_restore (per impostazione predefinita sarà /opt/bfc/bin/db_restore). L'utilità db_restore interromperà BFC (se ancora in esecuzione), ripristinerà il database dal backup più recente, quindi riavvierà BFC.