Come scegliere tra ripristino peer delle transazioni automatizzato e manuale
Il tipo di file system è il fattore dominante nel decidere quale tipo di ripristino peer della transazione utilizzare. I diversi file system hanno comportamenti differenti e il comportamento di blocco dei file in particolare è importante quando si sceglie tra il ripristino peer automatico e manuale.
Il supporto HA (High Availability) di WebSphere® Application Server utilizza un meccanismo heartbeat per stabilire se i server sono ancora in esecuzione. I server vengono considerati non riusciti se smettono di rispondere alle richieste heartbeat. Alcuni scenari, come il sovraccarico del sistema e il partizionamento di rete (spiegato altrove in questo argomento), possono far sì che i server smettano di rispondere agli heartbeat, anche se i server sono ancora in esecuzione. WebSphere Application Server utilizza la tecnologia di blocco dei file per impedire che tali eventi causino l'accesso simultaneo ai log di ripristino delle transazioni, poich ' l'accesso a un log di ripristino da parte di pi - di un server pu causare la perdita dell'integrit ... dei dati.
Tuttavia, non tutti i file system forniscono la semantica di blocco file necessaria, in particolare i blocchi file vengono rilasciati quando si verifica un malfunzionamento di un server. Ad esempio, Network File System Versione 4 (NFSv4) fornisce questo comportamento di rilascio, mentre Network File System Versione 3 (NFSv3) non lo fa.
È possibile verificare se un file system condiviso può supportare il failover dei log di transazione eseguendo il test del protocollo di blocco del file system per WebSphere Application Server. Per eseguire il test, vedere http://www-01.ibm.com/support/docview.wss?uid=swg24010222.
NFSv4 rilascia i blocchi mantenuti per conto di un host nel caso in cui l'host abbia esito negativo. Il ripristino peer può verificarsi automaticamente senza riavviare l'hardware malfunzionante. Pertanto, questa versione di NFS è più adatta per l'utilizzo con il ripristino peer automatizzato.
NFSv3 conserva i blocchi di file per conto di un host malfunzionante fino a quando tale host può essere riavviato. In questo contesto, l'host è la macchina fisica su cui è in esecuzione il server delle applicazioni che ha richiesto il blocco ed è il riavvio dell'host, non il server delle applicazioni, che alla fine attiva i blocchi da rilasciare.
- Il server H è in esecuzione sull'host H e detiene un blocco file esclusivo per i propri file di log di ripristino.
- Il server P è in esecuzione sull'host P e detiene un blocco file esclusivo per i propri file di log di ripristino.
- L'host H ha esito negativo, portando con sé il server H. Il gestore blocchi NFS sul server di file conserva i blocchi concessi al server H per suo conto.
- Un evento di ripristino peer viene attivato nel server P per il server H da WebSphere Application Server.
- Il server P tenta di ottenere un blocco file esclusivo per questo log di ripristino peer, ma non è in grado di farlo in quanto è detenuto per conto del server H. Il processo di ripristino peer è bloccato.
- In un momento non specificato, l'host H viene riavviato. I blocchi tenuti per suo conto vengono rilasciati.
- Il processo di ripristino peer nel server P viene sbloccato e vengono concessi i blocchi file esclusivi necessari per eseguire il recupero peer.
- Il ripristino peer avviene nel server P per il server H.
- Il server H è stato riavviato.
- Se il ripristino peer è ancora in corso nel server P, il ripristino viene interrotto.
- Il server P rilascia il blocco esclusivo sui log di ripristino e restituisce la proprietà dei log di ripristino al server H.
- Il server H ottiene il blocco esclusivo e può ora eseguire la registrazione delle transazioni standard.
Per questo motivo, su NFSv3 è necessario disabilitare il blocco file per utilizzare il ripristino peer automatizzato. La disabilitazione del blocco dei file può portare ad un accesso simultaneo ai log di recupero, quindi è fondamentale proteggere il sistema dal sovraccarico del sistema e dal partizionamento di rete. In alternativa, è possibile configurare il ripristino peer manuale, in cui si impedisce l'accesso simultaneo attivando manualmente l'elaborazione del ripristino peer solo per i server che hanno avuto esito negativo.
- Sovraccarico del sistema
- Il sovraccarico del sistema si verifica quando una macchina diventa molto caricata in modo tale che i tempi di risposta sono estremamente scarsi e le richieste iniziano a andare in timeout. Esistono diverse cause potenziali di tale sovraccarico, tra cui:
- Il server è sottopotenziato e non è in grado di gestire il workload.
- Il server ha ricevuto un sovraccarico temporaneo di richieste.
- La memoria fisica disponibile è insufficiente. Di conseguenza, il sistema operativo è troppo occupato per fornire al server delle applicazioni il tempo CPU necessario.
- Partizionamento di rete
- Il partizionamento di rete si verifica quando un errore di comunicazione in una rete risulta in due reti più piccole indipendenti e non in grado di contattarsi.
Durante l'esecuzione normale, due server sulla rete si scambiano gli heartbeat. Durante il sovraccarico del sistema, le operazioni heartbeat sono in timeout, dando l'aspetto di un errore server. Dopo il partizionamento di rete, ogni server si trova in una rete separata e gli heartbeat non possono passare tra loro, dando anche l'aspetto di un errore del server.