Clustering e applicazioni personalizzate

0

Quindi diciamo che abbiamo una configurazione di ambiente cluster. Abbiamo un cluster SQL Server (non so esattamente come sia fatto ma lascia solo dire che è stato fatto per il gusto di argomentare). Ora se un sito Web o un'applicazione sta tentando di accedere a quel database per lettura / scrittura (ad esempio un'app ASP.NET o un'app di Winforms C #) e durante tale periodo SQL si interrompe, sono necessari un paio di minuti affinché il failover del cluster abbia effetto per passare a un altro nodo. Cosa succede durante questo tempo?

Penso che scadrà / non riuscirà a connettersi. MA c'è un modo per posizionare la richiesta in alcune pipeline, quindi quando il nodo del cluster viene sottoposto a backup / commutazione continuerà come normale?

    
posta Ahmed ilyas 21.11.2012 - 23:21
fonte

1 risposta

2

la risposta della prima domanda è, come hai detto, che si interromperà o otterrà dei messaggi di errore dal server. dipende da come progetta il tuo programma.

Suppongo che alcuni dei nodi nel cluster stiano funzionando come server API in quanto è una configurazione ragionevole. Se non si dispone di un server API nel cluster, credo che sia necessario configurarlo da qualche altra parte. altrimenti, non penso che tu sia in grado di condurre le tue richieste.

una volta che hai macchine in grado di funzionare per il tuo lavoro di pipeline, penso che ci siano due modi per completare il tuo compito.

il primo:

crea un altro server db indipendente (chiamiamo il server db che stai usando A e questo server isolato B) che memorizza le informazioni delle richieste e scrivi una funzione (chiamiamola funzione C) che continua a interrogare B nel tuo server api (chiamiamo questa azione come 'polling'). naturalmente, è possibile impostare l'intervallo di query in C per migliorare le prestazioni. la durata dell'intervallo dovrebbe dipendere dalla tua situazione.

Una volta che il nodo API riceve la richiesta da B, interrogherà A per ottenere informazioni relative e svolgere l'attività relativa. Se l'attività è completata come aspettativa, C chiederà a B di eliminare la richiesta. D'altra parte, se A non è disponibile, C non farà nulla. Pertanto, questa richiesta non verrà eliminata da B e C riceverà nuovamente la stessa richiesta quando interroga B la prossima volta.

il secondo:

configurare un server di messaggi in coda. tutte le richieste dal lato client verranno inviate a questo server mq.

il compito di questo server mq è continuare a chiedere al server api di funzionare. se api funziona senza problemi, allora il server mq dovrebbe inserire la richiesta. altrimenti, il server mq dovrebbe mantenere la richiesta e chiedere al server api di funzionare di nuovo dopo un intervallo.

RabbitMQ con STOMP può essere una buona scelta.

è ovvio che la prima via è inefficiente. devi scrivere, leggere ed eliminare ogni richiesta. tutte queste azioni richiedono molto tempo e possono essere il collo di bottiglia se il tuo servizio deve gestire un sacco di richieste. Tuttavia, se non si desidera utilizzare un nuovo framework, questa potrebbe essere un'opzione adatta. In realtà, attualmente sto lavorando a un sistema di cloud computing, e questo è il modo in cui usiamo.

il secondo modo è molto più efficiente, ma devi installare un nuovo framework, che potrebbe essere un problema di mantenimento in futuro.

    
risposta data 27.11.2012 - 02:33
fonte

Leggi altre domande sui tag