Questa sezione descrive i problemi e le limitazioni attualmente noti.
Ciò significa che un'appliance può comunicare solo con appliance ad essa connesse (oltre che al proprio server e al controller di griglia). Ciononostante è necessario che i protocolli vengano specificati correttamente nelle nuove appliance per garantire l'integrità della progettazione delle applicazioni e la compatibilità con le versioni successive di CA AppLogic.
La quantità totale di spazio disponibile su disco rilevata dal comando grid info è una stima approssimativa e non considera il mirroring del volume. La quantità reale di spazio disponibile su disco corrisponde alla quantità riportata divisa per il numero di mirror (2 per impostazione predefinita). Se, ad esempio, la quantità di spazio disponibile è 1000 GB e la griglia è stata configurata per 2 mirror, lo spazio disponibile su disco sarà 500 GB. Per creare correttamente volumi mirror, è necessario disporre di spazio sufficiente su almeno X server, quando X è il numero dei mirror. Se non vi sono risorse sufficienti per creare un mirror, CA AppLogic non genererà tuttavia un volume errato, ma visualizzerà un messaggio di errore indicante che il mirroring non può essere creato.
Se viene avviata un'applicazione e uno dei server della griglia genera un errore, l'avvio dell'applicazione avrà esito negativo, se una o più appliance dell'applicazione sono state programmate per essere eseguite sul server che ha causato l'errore. In questo caso riavviare semplicemente l'applicazione.
Per caricare file più pesanti sul volume, utilizzare il comando di shell "vol manage". Non dimenticare di specificare le impostazioni IP esterne per questo comando per poter abilitare l'accesso remoto dall'interno del gestore del volume. Per ulteriori informazioni, consultare il riferimento relativo al comando vol manage.
CA AppLogic supporta l'avvio di appliance OpenSolaris da un volume di avvio basato su ZFS. Tenere tuttavia presente che ZFS non è stato verificato da CA e potrebbe non funzionare. Solaris 10 non supporta ZFS.
Attualmente il supporto è limitato a pool ZFS dotati di un'unica periferica. Per sfruttare al massimo le funzionalità di ZFS in CA AppLogic, gli utenti possono assemblare propri pool ZFS all'interno delle loro appliance. Se un pool ZFS deve essere utilizzato per il mirroring, i volumi di CA AppLogic utilizzati nel pool devono essere creati con la funzione di mirroring di CA AppLogic disabilitata (utilizzando l'opzione mirrored=0 durante la creazione dei volumi). Inoltre, un pool ZFS creato utilizzando il file server Solaris di CA AppLogic non funziona in Solaris 10. Consultare RefOsLimitations per avere informazioni su tutti i limiti dei sistemi operativi utilizzati da CA AppLogic.
Se si necessita di uno spazio di archiviazione più ampio, utilizzare un file system diverso.
La nuova modalità di configurazione DHCP non supporta il markup delle proprietà per la configurazione delle appliance. Quando si esegue il passaggio di appliance dalla modalità volfix alla modalità DHCP, la documentazione APK descrive come comportarsi con appliance la cui configurazione dipende dal markup delle proprietà. Per ulteriori informazioni, consultare il Kit per l'appliance (APK).
Per visualizzare i contrassegni di convalida per un'applicazione, aprire l'applicazione in modalità di modifica. I contrassegni di convalida vengono utilizzati per contrassegnare appliance in cui non sono stati configurati correttamente tutti i terminali, i volumi e le proprietà obbligatori.
Per installare un'appliance Solaris 10 è possibile utilizzare iso2class, servendosi della console grafica per il processo di installazione. Al termine dell'installazione, tuttavia, quando l'appliance viene riavviata, la console grafica può essere utilizzata solo in modalità di testo (non è consentito l'accesso al desktop di Solaris 10; l'accesso è esclusivamente basato sul testo). Questo problema è dovuto a un bug della GUI di Solaris 10 (non a un bug di CA AppLogic).
La console grafica non può pertanto essere utilizzata con queste appliance. Questa scelta è intenzionale e ha come fine quello di ridurre il più possibile le dimensioni delle appliance. Utilizzando la nuova utilità iso2class, gli utenti possono creare delle appliance personali che godono di un supporto desktop completo.
Questo errore è dovuto al fatto che CA AppLogic imposta il nome del computer di un'appliance come nome dell'istanza. Pertanto, se su una griglia sono in esecuzione più appliance aventi il medesimo nome di istanza, sulla console grafica di Windows viene visualizzato un errore di nome duplicato. Questo errore è semplicemente un avviso e non influisce sulla griglia o sulle relative operazioni. Se tuttavia si desidera utilizzare Windows come controller di dominio, è necessario impostare i nomi dei computer come nomi univoci per ogni appliance. È possibile utilizzare l'utilità wincfg per impostare il nome del computer nell'appliance.
Testato da CA con Java versione 6 aggiornamento 7 su IE/FF/Chrome/Safari. Se non viene utilizzata la versione più recente di Java, la console grafica potrebbe non funzionare correttamente (potrebbe bloccarsi durante il tentativo di caricamento). Prima di segnalare eventuali errori della console grafica a CA, assicurarsi di utilizzare l'ultima versione di Java (dopo aver aggiornato la versione di Java nel proprio browser, aprire nuovamente il browser per fare in modo che la console grafica funzioni correttamente).
Quando un server secondario subentra come nuovo server primario, se non sono disponibili risorse sufficienti sul server per l'avvio del controller della griglia, CA AppLogic riavvia le appliance che sono in esecuzione sul nuovo server primario su altri server all'interno della griglia, in modo che il controller della griglia possa essere avviato sul nuovo server primario. Si noti che l'operazione può comportare l'interruzione dei gruppi di failover delle appliance. Se CA AppLogic interrompe una di queste appliance, potrebbe non essere in grado di riavviarla su un altro server, poiché non dispone di risorse sufficienti per soddisfare il gruppo di failover.
Tutte le appliance basate su HVM (Solaris 10, Windows e così via) utilizzano una quantità di memoria sul server superiore a quella a loro assegnata. In genere, a seconda della quantità di memoria assegnata a un'appliance basata su HVM, quest'ultima utilizza una quantità di memoria superiore sul server in cui è in esecuzione (tale memoria aggiuntiva serve per far funzionare l'hypervisor di virtualizzazione in esecuzione sui server ed è denominata memoria shadow). È pertanto possibile che, anche se un server dispone di memoria sufficiente rispetto alla quantità assegnata all'appliance, quest'ultima non possa essere eseguita sul server poiché necessita di una memoria shadow aggiuntiva per appliance basate su HVM che non è disponibile sul server. L'utilità di pianificazione di CA AppLogic tiene in considerazione la memoria shadow nella pianificazione delle appliance durante l'avvio dell'applicazione.
Quando si utilizza una backbone da 10 G, la velocità massima che può essere effettivamente raggiunta tra appliance in esecuzione su server diversi è di circa 2 Gbps (probabilmente a causa di una limitazione interna all'hypervisor utilizzato da CA AppLogic).
È possibile utilizzare qualunque tipo di browser.
Le interfacce condivise dovrebbero funzionare con tutti gli altri sistemi operativi.
Segue un elenco dei problemi noti di questa release:
L'utilizzo del Controller HP RAID Smart Array senza la scrittura cache abilitata comporta una riduzione delle prestazioni del 50%. Si tratta di un problema verificato su un server HP DL 580 G7, con Smart Array P410i 256mb. Queste schede richiedono l'installazione di una batteria o di un condensatore per l'abilitazione della cache di scrittura.
Utilizzo di ServerEngines Corp. Schede NIC con CA AppLogic Emulex OneConnect 10Gb (be3) (rev 01): le schede NIC respingono erroneamente i pacchetti se l'opzione SR-IOV di BIOS è abilitata. Questi pacchetti non recapitati modificano la cache di inoltro del bridge, pertanto il bridge ignora tali pacchetti invece di inviarli alla destinazione corretta. Questo comportamento causa instabilità in CA AppLogic, pertanto si verificano errori intermittenti durante l'avvio dell'applicazione. Pertanto, verificare che l'impostazione SR-IOV di BIOS sia disattivata per tutte le schede di interfaccia di rete Emulex a 10G in tutti i server della griglia.
Quando viene utilizzato un backbone a 10G, la velocità effettiva di rete massima che è possibile ottenere tra appliance in esecuzione su server differenti corrisponde circa a 2.5 Gbps (i risultati potrebbero essere diversi in base al tipo di hardware a 10G utilizzato). CA sta studiando diversi tipi di ottimizzazione di rete (come ad esempio l'attivazione di frame jumbo) che potranno essere inclusi nelle versioni future di CA AppLogic per migliorare le prestazioni della rete a 10G.
Può accadere molto raramente che un'applicazione non venga avviata a causa del blocco di montaggio di un volume su uno dei server. CA AppLogic rileva i montaggi di volume bloccati e li segnala all'utente nella griglia del dashboard. Se si osserva questo problema sulla griglia, contattare il CA Support. In alternativa il problema viene risolto disattivando o riavviando il server che presenta il blocco dei montaggi.
Quando si verifica questo problema, il riavvio del server primario ripristina lo stato operativo della griglia.
VDS: vulnerabilità di protezione: configurazione iniziale utente/password
Se si accede alla GUI di CA AppLogic con Microsoft Internet Explorer 6 o 7, la GUI presenta delle perdite di memoria quando vengono aperte le applicazioni per modificarle o quando viene aperta la shell Web (durante ciascuna di queste operazioni vengono persi 5-20 MB di memoria di sistema). Si consiglia di chiudere e riaprire il browser regolarmente dopo alcune ore per recuperare la memoria perduta. Al posto di Internet Explorer è possibile utilizzare Firefox, Chrome o Safari.
Quando il carico di lavoro sul controller di griglia è eccessivo, l'interfaccia utente non disconnette più automaticamente l'utente. Al contrario quest'ultimo riceve un messaggio indicante che si è verificato un errore di rete. In questo caso l'interfaccia utente rimane completamente operativa. Il messaggio di errore di rete viene visualizzato solo quando il controller è sottoposto a un carico eccessivo, ad esempio se vengono avviate 4 applicazioni e viene copiato contemporaneamente un volume di svariati gigabyte. In griglie di grandi dimensioni si consiglia di assegnare al controller un intero CPU di core e 1 GB di RAM.
Se una griglia viene riavviata utilizzando il comando grid reboot, quando la griglia è di nuovo operativa dopo il riavvio, uno o più volumi di sistema potrebbero essere danneggiati. CA AppLogic esegue automaticamente il recupero di questi volumi con priorità assoluta.
Quando si esegue la migrazione di un volume, assicurarsi che almeno uno dei suoi stream sia su un server abilitato. In caso contrario il comando di migrazione non verrà eseguito. Il volume può essere trasferito completamente dall'insieme di server originale eseguendo due volte la migrazione del volume.
Alcuni server fisici possono impiegare molto tempo per riavviarsi, causando un errore durante il recupero automatico della griglia di CA AppLogic. Ne risulta che le applicazioni potrebbero non venire riavviate tutte automaticamente dopo che è stata recuperata la griglia a seguito dell'errore. Questo problema è dovuto al fatto che il controller di griglia attende il riavvio di tutti i server e la loro riconnessione al controller di griglia per un massimo di 10 minuti. Questo tempo potrebbe non essere sufficiente per garantire il riavvio di tutti i server. Una soluzione alternativa consiste nel riavviare manualmente le applicazioni dopo che tutti i server si sono riconnessi al controller di griglia (eseguire "list srv" per garantire che tutti i server siano connessi al controller di griglia - dovrebbero essere tutti nello stato UP). In CA AppLogic 2.1, che prevede un timeout di avvio del server di 10 minuti, questo problema si verifica principalmente se un server non riesce ad avviarsi a causa di un malfunzionamento dell'hardware o del BIOS.
Quando l'operatore riavvia la griglia, lo stato di instabilità della griglia dovrebbe essere reimpostato e sul dashboard dovrebbe essere visualizzato un messaggio indicante che la griglia è stata riavviata intenzionalmente dall'operatore ("La griglia è stata riavviata dall'operatore il..."). Può accadere però che, durante il riavvio della griglia, il file della griglia non sia reimpostato né venga visualizzato il messaggio sul dashboard. L'unico problema che questa anomalia può comportare è che le applicazioni potrebbero non essere riavviate automaticamente a seguito di un successivo errore della griglia (ciò dipende dal numero di volte in cui la griglia produce un errore quando si verifica l'anomalia). Per risolvere questo problema, se dopo un riavvio intenzionale della griglia sul dashboard non viene visualizzato alcun messaggio, contattare il CA Support per reimpostare lo stato di instabilità della griglia.
Il motivo di questa leggera diminuzione delle risorse si spiega con l'allocazione di risorse alle aree di servizio. Per quanto riguarda la memoria, la diminuzione è probabilmente dovuta al fatto che Xen è collegato alla tabella della mappa di memoria per una macchina virtuale. Per quanto riguarda il disco, la diminuzione è dovuta alle normali aree di servizio di file system (come accade normalmente sui server Linux).
Ciò si verifica perché l'editor di CA AppLogic crede erroneamente che un altro utente abbia aperto l'applicazione per eseguire delle modifiche. Se si riscontra questo problema, ignorare semplicemente il blocco dell'applicazione quando viene visualizzato il messaggio dell'editor all'apertura dell'applicazione.
Il rallentamento si riscontra principalmente durante l'apertura di un'applicazione nell'editor dell'applicazione di CA AppLogic.
Se la console grafica è aperta sul client e si perde la connessione a Internet (errore della scheda di rete del client, arresto anomalo del computer client, accesso a Internet non disponibile e così via), sono necessari circa 15 minuti per aprire nuovamente la console grafica.
Il mouse risulta difficile da manovrare quando si utilizza la console grafica di CA AppLogic in Ubuntu. Questo problema è dovuto a un limite del supporto VNC di Xen (l'accelerazione del mouse non è supportata). Alcuni utenti hanno segnalato che il problema si risolve modificando le impostazioni del mouse di Ubuntu. Può inoltre accadere raramente che le battute della tastiera vengano ripetute più volte durante la digitazione di un testo (in questo caso eliminare semplicemente i caratteri visualizzati in eccesso).
Ciò include le password utilizzate per accedere a un'appliance. La console testuale di avvio deve essere utilizzata solamente a fini di debug. La console SSH può essere utilizzata in sua vece per tutti gli altri scopi.
Se un utente riapre la console testuale di avvio per un'appliance dopo che la console è già stata aperta, l'utente deve premere INVIO per visualizzare il prompt di accesso o il prompt dei comandi. Ciò si spiega con il fatto che la console di avvio è in attesa di input da parte dell'utente (informazioni di accesso o comando da eseguire).
Se una griglia ha un'appliance che appartiene a un gruppo di failover in esecuzione su un server secondario in cui il controller di griglia deve essere riavviato, CA AppLogic potrebbe arrestare l'appliance che causa l'interruzione del gruppo di failover
Quando si aggiorna una griglia alla versione più recente, sul dashboard viene registrato un messaggio indicante che la griglia è stata interrotta a causa di un problema di hardware. Questo messaggio può essere ignorato e rimosso dal dashboard.
Attualmente il kit per l'appliance (APK) non funziona con Ubuntu 9.10 o 10.x a causa di alcune incompatibilità con le versioni più recenti di questo sistema operativo. Comunque, ci sono vari post sui forum di CA AppLogic che descrivono come utilizzare alcune delle ultime distribuzioni del sistema operativo con CA AppLogic.
Se si utilizza una configurazione HA di rete con CA AppLogic e si verifica un errore di rete esterna, le applicazioni o appliance che utilizzano interfacce esterne possono diventare inaccessibili per un tempo massimo di 5 minuti. La causa di ciò è probabilmente da rintracciare nel router esterno che memorizza nella cache gli indirizzi MAC. Nell'attesa che il router svuoti la sua cache ARP o tramite l'invio di una risposta ARP con "l'esecuzione dell'arping" dall'operazione di recupero applicazione. Il problema riguarda solo la rete esterna (la rete backbone non viene influenzata).
Solaris 10 non funziona in CA AppLogic 3.x sia su server Xen che su server ESX.
OpenSolaris funziona solamente su server basati su XEN.
La GUI di ripristino funziona solamente su server basati su XEN.
Le interfacce condivise non supportano i contatori di appliance.
Se un utente attiva il ciclo di alimentazione di una griglia, il tempo di attività del sistema non viene reimpostato. Il tempo di attività del sistema dovrebbe essere reimpostato quando la griglia viene riavviata.
Se un utente attiva il ciclo di alimentazione di una griglia servendosi del comando grid power_cycle, è possibile che il server primario non riesca a riavviarsi. Questo errore si verifica solo quando il comando viene eseguito dopo che è stata installata una nuova griglia e la griglia non è ancora stata riavviata. Per evitare il problema è sufficiente riavviare la griglia in qualsiasi momento dopo la sua installazione.
Se la dimensione di condivisione di NFS viene modificata mentre una griglia è eseguita, CA AppLogic non lo rileva fino al riavvio della griglia. Questo problema verrà corretto in una release futura.
Quando si elimina una griglia che utilizzava una SAN, CA AppLogic elimina i contenuti della cartella della griglia sulla SAN ma non rimuove la cartella vuota. Questo problema verrà corretto in una release futura.
Non è possibile utilizzare i server basati su Dell che utilizzano le schede H200 RAID con CA AppLogic. Questo problema verrà corretto in una release futura.
La soluzione alternativa questo problema è abilitare il RAID hardware sul server Dell prima di utilizzarlo per la creazione della griglia.
Le appliance basate su RedHat 5.3 non possono essere installate usando iso2class. Questo problema verrà corretto in una release futura.
Molto raramente, un aggiornamento a 3.5 da 3.0 o da 3.1 non riesce. In questo particolare caso di errore di aggiornamento, i seguenti messaggi sono presenti nel log di stato della griglia cui si accede da BFC (fare clic sullo stato della griglia per aprire il log).
installing the controller image ioctl: LOOP_SET_FD: Device or resource busy installing new controller FAILED, aborting
Se questi messaggi sono presenti nel log, eseguire nuovamente l'aggiornamento e dovrebbe riuscire.
Nota: questo problema è in realtà un bug di CA AppLogic 3.0 e 3.1 e viene risolto in CA AppLogic 3.5.
Il comando di rollback non funziona da 3.5 a 3.1 per una griglia basata su ESX. Tuttavia, come rimedio provvisorio, è possibile eseguire il downgrade del comando (si noti che il downgrade richiede più tempo del rollback). Questo problema verrà corretto in una release futura.
I volumi basati su Ext3-snapshot non funzionano sulle griglie basate si ESX. Comunque tali volumi funzionano sulle griglie basate su XEN. Se si utilizza una griglia basata su ESX ed è necessario utilizzare un volume ext3-snapshot, è possibile aggiungere un nodo basato su XEN e usarlo per creare/gestire i volumi di ext3-snapshot (quando si eseguono i comandi di volume, disabilitare tutti i server ESX in modo che il file server di CA AppLogic verrà eseguito sul nodo basato su XEN). Questo problema verrà corretto in una release futura.
Un tentativo di eseguire la migrazione di uno stream di volume su SAN locale potrebbe non avere esito sulle griglie che sono configurate per l'utilizzo di SAN esterno. Invece di eseguire la migrazione dello stream di volume a SAN locale, CA AppLogic cerca erroneamente di eseguire la migrazione dello stream su SAN esterno. Se si verifica questo errore, utilizzare l'opzione store=local con il comando vol migrate. Questo problema verrà corretto in una release futura.
Quando CA AppLogic viene aggiornato da 3.0.30 a 3.5.x, il controller di griglia si blocca in modo intermittente e il comando 3tshell eseguito restituisce un messaggio di errore di condizione di bassa memoria.
Per risolvere questo problema, riavviare il controller di griglia. Questo problema verrà corretto in una release futura.
Su alcuni nic di Broadcom, e in particolare NetXterme II BCM5709/5716, la velocità di collegamento è segnalata come 100 MB/s o 10 MB/s dal driver di nic. Come risultato, l'installazione di CA AppLogic non ha esito.
Per risolvere questo problema, provare ad eseguire nuovamente l'installazione. Questo problema verrà corretto in una release futura.
La versione di OpenSSH installata sul controller di griglia limita il numero di sessioni di SSH multiplex simultanee a 10. Di conseguenza, se vengono eseguite più di 10 richieste asincrone, esse sono fatte cadere dall'API.
Come soluzione alternativa, distribuire meno di 10 richieste asincrone simultanee all'API. Il problema verrà corretto in una versione successiva.
Se si rinomina un'interfaccia Assemblato o Componente, l'editor di applicazione non viene caricato completamente. Il problema verrà corretto in una versione successiva.
Sui server con questi nic, dopo aver creato una griglia, l'output di srv info srvX -extended mostra lo stato dei nic come active-down. Questo problema è stato identificato come specifico all'hardware. Per risolvere questo problema, collegarsi allo switch rispettivo, chiudere la porta del nic su srvX e abilitarla di nuovo. Lo stato dovrebbe essere indicato come attivo. Questo problema verrà corretto in una release futura.
È stato osservato che sui server Dell PE R710 con nic Broadcom NetXtreme II 57711 (bnx2x) 10 Gbe, BFC non riesce a rilevare i server che causano un errore di installazione. Questo è un problema specifico all'hardware e verrà risolto in una prossima release.
Di seguito vengono riportati i principali problemi noti di questa versione per quanto riguarda le appliance Windows. Per procedure aggiuntive e note, consultare anche il Riferimento per l'installazione di appliance Windows.
Quando si usa il nuovo Windows APK incluso in CA AppLogic 3.5, Windows 2003 Server 64-bit Data Center edition potrebbe avviarsi in modo intermittente quando è utilizzato su una griglia basata su Xen. Se si verifica questo problema, potrebbe essere sufficiente riavviare l'appliance. Questo problema verrà corretto in una release futura.
Il file server Windows può non riuscire a ridimensionare un volume, se il volume di origine contiene una voce o un file di directory danneggiato. La causa principale di questo problema consiste nel fatto che alcune delle installazioni di software Microsoft contengono di proposito delle voci di directory non valide (non sappiamo quale sia il motivo di ciò; questo problema è stato osservato da un utente che aveva installato una versione di Microsoft SQL Server nella sua appliance). Il volume di origine può essersi inoltre danneggiato a seguito della normale usura. È possibile ovviare a questo problema eseguendo un recupero del file system sul volume (vol fsrepair) prima di ridimensionarlo.
È stato calcolato da CA che l'operazione di ridimensionamento del volume NTFS ha esito negativo circa 2 volte su 100. In questi due casi il problema si verifica perché il file server di Windows non riesce ad avviarsi correttamente sulla griglia. Se si riscontra tale problema, ripetere l'operazione di ridimensionamento. Ciò dovrebbe essere sufficiente a risolverlo. Il problema dovrebbe tuttavia essere stato risolto nella presente versione. Se il problema viene ancora riscontrato, contattare il supporto tecnico di CA.
Il file server di Windows utilizza un'utilità Microsoft denominata DiskPart che ha il compito di comunicare con i volumi NTFS Windows. Può succedere che DiskPart non riesca a ottenere le informazioni sul volume o a montare il volume. Questo errore è molto raro e può far sì che i comandi vol create o vol resize non vengano eseguiti su volumi NTFS.
Se l'applicazione di un utente contiene un'appliance Windows e tale applicazione viene modificata, ad esempio perché vengono aggiunte una o più appliance Windows all'applicazione o vengono aggiunti o rimossi terminali dalle appliance Windows, durante il primo avvio dell'applicazione alcune delle appliance Windows potrebbero rilevare indirizzi IP duplicati sulla rete interna (questo problema può verificarsi solo durante il primo avvio dell'applicazione dopo che essa è stata modificata). Questa anomalia non dovrebbe causare alcun problema operativo all'applicazione né richiedere l'intervento dell'utente. Gli indirizzi IP duplicati sono puramente temporanei. Nel caso peggiore, alcune delle comunicazioni di rete che coinvolgono le appliance Windows potrebbero subire un ritardo massimo di 30-60 secondi.
Un tentativo di arrestare un'applicazione Windows è stato completato fino al 99%. L'operazione è scaduta dopo 15 minuti. L'applicazione conteneva 2 istanze di un'appliance Windows 2003 Server DataCenter Edition (WIN03DC). Una delle appliance Windows si è arrestata, mentre l'altra si è bloccata durante l'operazione "comp stop". Questa anomalia è stata riscontrata una volta sola e non può essere riprodotta.
È possibile che vengano registrati come zero i seguenti contatori di input/output del disco per le appliance Windows (anche se viene generato un input/output sostenuto): numero totale di byte in scrittura/lettura, numero di scritture/letture sul volume, tempo trascorso in scrittura/lettura. Questo problema è dovuto a un bug dell'API PerfMon di Windows, poiché i valori zero vengono rilevati dall'API PerfMon di Windows.
Con l'eccezione dell'MSI del file server, la versione localizzata in giapponese di Windows dovrebbe funzionare in CA AppLogic.
Un'appliance Windows non riesce ad avviarsi se è installata la periferica virtuale DVD-ROM MagicISO. Le periferiche virtuali DVD-ROM non sono attualmente supportate in CA AppLogic per le appliance basate su Windows.
Può accadere che Windows impieghi diversi minuti per rilevare nuove NIC all'interno di un'appliance. Ciò si verifica quando l'utente aggiunge o rimuove dei terminali da un'appliance Windows singleton. Il tempo aggiuntivo impiegato per rilevare le nuove NIC può causare dei timeout di avvio dell'appliance. Una soluzione alternativa consiste nell'aumentare il timeout di avvio dell'appliance Windows.
Se un utente dispone di un'appliance Windows su una griglia e trasferisce l'appliance su un'altra griglia dotata di un hardware diverso, l'appliance Windows può richiedere la riattivazione (riattivazione di Microsoft Windows). La riattivazione viene richiesta quando viene riscontrato un determinato numero di cambiamenti nell'hardware (CA non conosce esattamente quali cambiamenti dell'hardware scatenino la richiesta di riattivazione). Si noti che per eseguire la riattivazione può essere necessario accedere a Internet dall'interno dell'appliance Windows. Questo problema è stato riscontrato dopo che sono stati eseguiti il ridimensionamento del volume di avvio dell'appliance Windows e la migrazione dell'appliance in una griglia diversa.
Questo problema riguarda solo Windows 2008 Server a 32 e a 64 bit (Windows 2003 Server funziona normalmente). Quando si accede a un volume Windows 2008 tramite il file server o usando SSH su un'appliance, l'utente potrebbe non essere in grado di effettuare l'accesso o modificare i file a causa di problemi di autorizzazione. Per effettuare l'accesso ai file o modificarli usando la shell dei comandi, effettuare l'accesso tramite la console grafica al desktop di Windows e aprire una shell dei comandi. La shell di comando può essere utilizzata per accedere ai file e per modificarli.
Si verifica un timeout di Windows 2003 Server in occasione del primo avvio durante l'installazione. Assicurarsi di seguire le istruzioni della build di Windows per risolvere questo problema.
Quando si installano driver con valore pianificato Turbogate, al primo avvio dell'appliance (se essa è in esecuzione su un server di griglia basato su Xen) l'utente deve selezionare manualmente, seguendo la procedura guidata di installazione dell'hardware, le opzioni di installazione dei driver con valore pianificato Turbogate per tutti i terminali configurati nell'appliance. In caso contrario sarà impossibile avviare l'appliance.
Quando si crea una nuova appliance a 32/64 bit Windows 2003 Server, questa funzionerà solamente su un server della griglia che utilizza lo stesso hypervisor su cui l'appliance è stata inizialmente creata. In caso contrario l'appliance subirà un arresto anomalo durante l'avvio. Se ad esempio l'appliance è stata creata inizialmente su un server di griglia basato su ESX, essa potrà essere utilizzata solo su un server di griglia basato su ESX (il tentativo di utilizzare l'appliance su un server di griglia basato su Xen avrà esito negativo, poiché l'appliance subirà un arresto anomalo durante l'avvio).
Questo è un problema noto con server di Microsoft Windows 2003. Microsoft ha individuato una soluzione a questo problema con l'appliance di Windows 2003.
I problemi elencati di seguito sono stati riscontrati nelle versioni 2.4-3.x di CA AppLogic ma sono difficilmente riproducibili, poiché sono stati rilevati solo una o due volte. Se si verifica uno di questi problemi sulla griglia, inviare una segnalazione di errori a CA indicando quale problema è stato riscontrato e quali comandi di CA AppLogic hanno causato l'errore.
Un server della griglia ha subito il riavvio automatico a causa di un arresto anomalo del kernel di Linux nel dom0 del server. Questo problema non causa l'arresto dell'intera griglia, come nelle versioni precedenti di CA AppLogic, ma può produrre un tempo di inattività delle applicazioni. In questo caso le appliance che erano in esecuzione sul server che ha prodotto l'errore vengono avviate nuovamente su altri server della griglia. Se viene riscontrato questo problema sulla griglia, contattare il CA Support.
In CA AppLogic 2.4 sono stati riscontrati numerosi casi in cui un server perde la connessione con il controller di griglia e subisce il riavvio. Questo problema fa sì che tutte le appliance in esecuzione sul server vengano ripianificate su altri server della griglia. Ciò può produrre un tempo di inattività delle applicazioni. Non si conosce il motivo per cui un server perde la connessione con il controller di griglia. In CA AppLogic 2.7-3.x, se il server perde la connessione con il controller di griglia, il server tenterà di riconnettersi a quest'ultimo e, in caso di esito positivo, rimarrà operativo senza produrre un tempo di inattività delle applicazioni. Se il server non è in grado di riconnettersi al controller di griglia per 1 minuto, il server verrà riavviato e si verificherà un tempo di inattività. Quando un server perde la connessione con il controller di griglia, viene registrato un messaggio sul dashboard. Se viene riscontrato questo problema, contattare immediatamente il CA Support.
In CA AppLogic 2.7/2.8, il tentativo di ridimensionare contemporaneamente 4 volumi NTFS ha generato un errore per tutte e 4 le operazioni di ridimensionamento del volume. Il problema è stato riscontrato una sola volta.
Durante la replica di un file di 800 MB su un volume da 1 GB, l'appliance NASR ha smesso di rispondere. CA non è in grado di riprodurre il problema. Se il problema viene riscontrato sulla griglia, contattare il supporto tecnico di CA.
L'utente ha aperto più di 6 console grafiche per accedere a diverse appliance Windows in esecuzione sulla griglia (aperte contemporaneamente). All'apertura della settima console grafica uno dei server ha subito il riavvio e si è connesso nuovamente alla griglia. Le appliance in esecuzione sul server che ha prodotto l'errore sono state riavviate su altri server all'interno della griglia. Il problema è stato riscontrato una volta sola.
Abbiamo identificato i seguenti problemi noti con il Backbone Fabric Controller (BFC) in questa release:
su - bfcadmin
Importante: Dopo aver rimosso la dipendenza, il sistema verrà eseguito senza replica. È possibile tornare all'interfaccia utente e definire una nuova replica nella stessa posizione o in un'altra posizione.
Non utilizzare il comando “3t grid shutdown” su una griglia.
Quando si verifica questo errore, fare una “service nfs restart” su BFC dovrebbe risolvere il problema.
Se si legge questo messaggio, basta premere il tasto “Esc” per procedere con l'installazione.
In CA AppLogic 3.5, alcuni NIC di Broadcom Corporation NetXtreme II segnalano erroneamente di essere troppo lenti. Se si verifica questo errore, potrebbe essere utile cercare di rilevare nuovamente il server.
Se BFC esaurisce lo spazio prima che sia in grado di chiudersi, sarà necessario riavviare BFC dopo aver liberato dello spazio in modo che torni a funzionare correttamente.
Se non viene eseguita un'installazione automatica con questa versione del prodotto, la password non può contenere “=”
Se è stato utilizzato VLAN 0 in BFC in AppLogic 3.1, è possibile continuare a utilizzare lo stesso ID VLAN, ma non è possibile assegnare quel VLAN nell'interfaccia utente come nella versione 3.5.
Questo problema potrebbe autorizzare occasionalmente i server nelle griglie che dovrebbero essere bloccate. Se le porte sono configurate correttamente, questo problema non si verifica.
Se è necessario utilizzare più di 256 caratteri, è sufficiente rompere i parametri in più aggiornamenti di griglia.
Quando viene utilizzata l'installazione di Bare Metal per definire una replica sul file system montato su un NFS, si verificherà un problema se la directory non è di proprietà di bfcadmin. Un'opzione consiste nell'aggiungere la replica dopo aver installato l'interfaccia utente. Un'altra opzione è la seguente:
groupadd -g 64869 bfc useradd -u 64870 -g 64869 bfcadmin
chown bfcadmin /mnt/replica chgrp bfc /mnt/replica
(dove /mnt/replica è il percorso alla directory di replica)
Su alcuni server, il conteggio di CPU riportato dal sistema è lo stesso quando Hyper Threading è disabilitato o abilitato. Ciò è stato osservato in alcuni Dell R610.
Questo problema è dovuto al modo in cui i parametri sono scritti nel file di configurazione passato al set aldo. Se l'utente inserisce i dati nell'interfaccia utente introducendo una virgola fra le voci, si potrebbe verificare lo stesso errore. Un'alternativa a questo problema dell'API di BFC è di passare soltanto una stringa singola con un separatore di riga fra le voci.
Ad esempio:
\"additional_config\":[\"ext_dns1=155.35.34.108\next_dns2=141.202.1.108\"]
Invece di:
\"additional_config\":[\"ext_dns1=155.35.34.108\",\"ext_dns2=141.202.1.108\"]
Il problema si verifica quando il protocollo di Spanning Tree (STP) viene abilitato su uno o più switch esterni e il VLAN senza tag sulla porta dello switch che si connette all'interfaccia di server esterna non è lo stesso del VLAN senza tag della porta dello switch che si connette all'interfaccia esterna dei server di BCF. L'impostazione di stp_port sull'interfaccia esterna del server è quindi impostata su unknown e il server è messo in quarantena. Come soluzione alternativa, disabilitare completamente STP su uno o più switch esterni oppure configurare il VLAN senza tag della porta dello switch che si connette all'interfaccia esterna dei server in modo che sia identico al VLAN senza tag della porta connessa all'interfaccia esterna dei server di BCF. Quindi, togliere dalla quarantena il server e riavviare il processo di rilevamento.
Questo problema si verifica perché l'eliminazione di una subnet nella versione 3.1 non riesce correttamente se sono presenti delle griglie negli intervalli di indirizzo IP dell'applicazione che sono nella subnet. Il processo di aggiornamento cerca la subnet mancante sull'aggiornamento e non ha esito perché questa manca. Per una soluzione alternativa, fare riferimento alle istruzioni per l'aggiornamento non riuscito del ripristino dalla precedente installazione di BFC 3.1. Quindi, andare su ogni griglia e rimuovere gli intervalli di indirizzo IP delle applicazioni dalla griglia che non appartiene a una subnet correntemente configurata. In alcuni casi, ad esempio quando la stessa subnet è stata aggiunta successivamente con un nuovo parametro di lunghezza del prefisso CIDR, l'intervallo può essere compreso nei limiti di una subnet corrente, ma il componente di subnet sottostante sarà errato e continuerà a causare un errore di aggiornamento. Occorre confermare che la subnet in BFC corrisponde ai parametri dell'intervallo di indirizzo IP dell'applicazione nel controller di griglia dell'interfaccia utente.
Il parametro -o di isotool non mostra correttamente le periferiche USB associate al computer (Casella CentOS 5.5). Si tratta di un problema noto di CentOS 5.5. Per risolvere questo problema, occorre pubblicare il seguente comando di shell come root dell'utente:
riavvio di haldaemon di servizio
| Copyright © 2012 CA. Tutti i diritti riservati. |
|