none
Problema con MPP (Memory Pressure Protection) ? RRS feed

  • Domanda

  • Ciao a tutti,

    Ho un server 2008 R2 SP1 ENTERPRISE (in lingua inglese) che recentemente smette di funzionare saltuariamente:

    Su tale server sono presenti diversi servizi sviluppati dall'azienda per la quale lavoro che ricevono diverse richieste\connessioni tcp da diversi client.

    Ogni tanto il server "smette" di accettare connessioni in ingresso determinando il blocco delle applicazioni client.

    In questi casi il riavvio dei servizi sul server non ripristina la situazione

    Gli stessi servizi non si fermano (restano in "stopping") , oppure , killando il processo e tentando di riavviarli , restano in stato di "starting" come se non riuscissero più a creare la porta tcp in ascolto o come se non riuscissero più a raggiungere il server Database (SQL) con cui i servizi "lavorano"

    Tutti i log dei miei servizi non vengono più "scritti" ed anche nell'eventviewer di Windows non viene indicato nulla.

    Durante il "blocco" il server database rimane comunque raggiungibile per tutti gli altri server\applicazioni non presenti sul sistema operativo bloccato.

    Il numero di connessioni in ingresso sul server non eccede quasi mai le 2000 , spesso durante i blocchi rilevo numerose connessioni TCP in stato di "Time Waiting". Durante i blocchi l'impegno di CPU e Memoria Ram è inferiore al 50%

    Ho già ipotizzato che il range di porte utilizzate dal server in uscita (16384 se non sbaglio) fosse troppo piccolo e pertanto ho proceduto ad allargare tale range (oltre 50000) senza risolvere il problema.

    Il server attualmente "si pianta" ogni settimana determinando parecchi disagi agli utenti.

     5 giorni fa ho abilitato il firewall di Windows sul server per determinare se ci fossero "attacchi" di qualche genere provenienti dalla rete. Il log ha registrato e bloccato fino al momento dell'ultimo blocco solo traffico di tipo UDP corrispondente a Broadcast NetBIOS e LLNMR. Nel momento dell'ultimo blocco il firewall ha bloccato invece traffico di tipo "TCP" in stato "SYN" (vedi log di seguito)

    ------------------------------------------------------------------------------------------------------------------------------------

    date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path
    2014-05-26 10:23:51 DROP TCP 10.80.65.48 10.80.64.41 4883 139 48 S 922855828 0 65535 - - - RECEIVE
    2014-05-26 10:45:35 DROP TCP 10.80.65.58 10.80.64.41 4136 139 48 S 991463908 0 65535 - - - RECEIVE
    2014-05-26 11:16:35 DROP TCP 10.80.65.48 10.80.64.41 4910 139 48 S 240351606 0 65535 - - - RECEIVE
    2014-05-26 11:16:38 DROP TCP 10.80.65.48 10.80.64.41 4910 139 48 S 240351606 0 65535 - - - RECEIVE
    2014-05-26 12:12:45 DROP TCP 10.80.65.48 10.80.64.41 4947 139 48 S 2741221474 0 65535 - - - RECEIVE
    2014-05-26 12:44:46 DROP TCP 10.80.65.58 10.80.64.41 4221 139 48 S 2431204251 0 65535 - - - RECEIVE

    ------------------------------------------------------------------------------------------------------------------------------------

    Le connessioni che vengono "DROPPATE" inoltre sono sulla porta 139 (Sharing) che non dovrebbero essere tali (le regole sul FW permettono l'uso delle condivisioni)

    L'idea che mi sono fatto io è che il blocco sia stato determinato non tanto dal Firewall ma dall' MPP (Memory Pressure Protection) presente sul controllo dello stack TCP.

    L'infrastruttura server consta di 28 Server Virtuali su VmWare 4.1 e la problematica è presente SOLO sui server che ricevono il maggior numero di richieste dai client.

    La mia "ipotesi" potrebbe essere corretta ?

    Quale è il criterio dell' MPP che determina se bloccare o meno lo stack TCP ?

    Avrebbe senso , nel mio contesto di rete "sicura" e di grande attività sul server , disabilitare l'MPP tramite "NetSH" ?

    Grazie mille a tutti

    Matteo



    • Modificato Matteo E martedì 27 maggio 2014 06:40
    martedì 27 maggio 2014 06:37

Risposte

  • Ho il sospetto che il problema dipenda proprio da VMWare o dal deploy, tra l'altro le altre macchine virtuali che non si bloccano hanno un'attività di rete molto inferiore. Se possibile prova con una nuova macchina virtuale, già il fatto che riscontravate anomalie con la scheda E1000 a mio parere non è molto normale e potrebbe essere un segnale.
    • Contrassegnato come risposta Anca Popa lunedì 2 giugno 2014 07:58
    mercoledì 28 maggio 2014 16:57
    Moderatore

Tutte le risposte

  • qui trovi una descrizione più precisa dell'MPP

    http://support.microsoft.com/kb/974288/it

    ma a me non pare che possa essere questa la causa del blocco a meno che tu non abbia descritto i sintomi in maniera non precisa.


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    martedì 27 maggio 2014 07:59
    Moderatore
  • Visto che si tratta di un'operazione relativamente poco invasiva (non credo che ci sia un'esposizione diretta in internet) potresti comunque disabilitare l'MPP solo sul range di porte utilizzato dall'applicativo:

    http://technet.microsoft.com/it-it/library/cc731258(v=ws.10).aspx

    Ho comunque dei dubbi che si possa trattare di un problema causato da questa funzione, io credo piuttosto che dovresti indagare sull'istanza SQL Server. Come primo test, quando si verifica il problema, prova a riavviare i servizi di SQL Server e a vedere se cambia qualcosa (ad esempio se viene almeno registrato qualche log da parte dell'applicazione).

    Potrebbe comunque anche dipendere dall'host VMWare non configurato correttamente: ad esempio una configurazione di rete non corretta o un sottodimensionamento dell'infrastruttura fisica.

    http://www.extrahop.com/post/blog/extrahop-analysis/vm-virtual-packet-loss/

    martedì 27 maggio 2014 08:16
    Moderatore
  • Ciao,

    innanzitutto grazie per la risposta....

    La configurazione degli Host VmWare è corretta (4 schede in bilanciamento LACP) e altri server presenti sullo stesso host , che però effettuano pochissime connessioni , non hanno problemi.

    Ho alcuni server che utilizzano un'unica scheda e che hanno lo stesso problema. Analisi su VmWare e "sniff" di rete con WireShark non hanno rilevato problemi.

    Gli host hanno risorse relativamente scariche.

    Non rileviamo rallentamenti di rete legati a pacchetti persi e successivamente reinviati.

    Quando il server è funzionante le performance sono nella norma.

    L'istanza SQL è già stata analizzata ed è emerso che al momento del blocco altri server riescono ad accedervi tranquillamente. Non sono presenti nei LOG SQL problemi quali ad esempio Deadlock.... il server "bloccato" , profilando SQL , non esegue neanche il login al database come se la comunicazione si interrompesse prima.

    Perché il firewall ha , al momento del blocco , droppato connessioni relative a servizi di condivisione (share di file) che invece secondo le regole impostate non dovrebbero essere state droppate ?

    Normalmente le condivisioni sono "accessibili" , al momento del blocco non lo erano più.

    Quali sono le condizioni tale per cui l'MPP potrebbe decidere di "droppare" le connessioni o per lo meno di impedire l'uso dello stack tcp ?

    Grazie mille ancora

    Matteo


    • Modificato Matteo E martedì 27 maggio 2014 10:02
    martedì 27 maggio 2014 08:52
  • Vendendo gli indirizzi di origine e di destinazione nella parte di log che hai inserito ho il sospetto che il firewall abbia bloccato le connessioni a causa di un attraversamento in un NAT o un router. In tal caso dovresti modificare le regole per consentire l' "attraversamento confini":

    http://technet.microsoft.com/it-it/library/cc732489(v=ws.10).aspx

    L'MPP invece ha comportamenti differenti a seconda del profilo di rete rilevato: quando è identificata come pubblica ha regole di controllo sicuramente più severe.

    I controlli eseguiti sono solo finalizzati al rilevamento di attacchi DoS, qui trovi qualche informazione aggiuntiva:

    http://support.microsoft.com/default.aspx?scid=kb;en-us;142641&sd=tech


    martedì 27 maggio 2014 11:01
    Moderatore
  • Ok,

    prima del blocco i due client però raggiungevano tranquillamente le condivisioni..... come anche dopo il riavvio del sistema operativo.

    ...sul server non è cambiato nulla (a livello configurazioni) negli ultimi 5 giorni .....

    ...inoltre il "DROP" è a livello SYN della comunicazione TCP che è proprio dove l'MPP ,da quello che ho compreso , agisce...

    E' possibile che le regole FW cambino "da sole" ? (non credo)

    Tieni anche conto che , come indicato nel mio primo messaggio , la problematica è presente da tempo ed il firewall è stato attivato solo qualche giorno fa.

    Ciao e grazie per il tempo dedicato

    M.

    martedì 27 maggio 2014 11:06
  • Non avevo capito che il blocco di pacchetti da quel determinato indirizzo non era costante. Ovviamente le regole del firewall non si modificano da sole, quindi dovresti avere sempre dei blocchi di quel tipo. In ogni caso questo discorso del firewall era solo una possibile spiegazione per il risultato del log che avevi inserito, non credo sia la causa delle problematiche che riscontri.

    Quindi in seguito al blocco hai rilevato anche un mancato accesso dei client alle condivisioni presenti sullo stesso server? Il comportamento si verifica anche con nuovi client che tentano di collegarsi dopo che si è verificato il blocco?

    martedì 27 maggio 2014 11:15
    Moderatore
  • Esattamente , e non solo per accedere alle condivisioni ma anche per comunicare con gli altri servizi....

    ....anche i servizi installati sullo stesso server non riescono più a comunicare con l'esterno....

    Ciao

    M.

    martedì 27 maggio 2014 11:59
  • Il server in questione utilizza interfacce di rete multiple?

    Che tipo di adattatore virtuale hai utilizzato per la macchina virtuale?

    martedì 27 maggio 2014 13:06
    Moderatore
  • La macchina virtuale ha una sola interfaccia di rete (virtuale) di tipo VMXNET a sua volta connessa ad uno virtualswitch da 8 porte.

    Al VirtualSwitch (impostato in Load Balancing con Ip hash) sono collegate 4 schede di rete fisiche broadcom....

    Le 4 schede di rete sono connesse a due switch fisici in stack tra di loro configurati in LACP Statico....

    Grazie

    martedì 27 maggio 2014 13:35
  • Il server è nato già virtuale o proviene da un'installazione fisica? In tal caso assicurati che siano state rimosse eventuali schede di rete fisiche ormai inattive.

    Questa procedura è valida anche per Windows Server 2008 R2: http://support.microsoft.com/kb/315539/it

    Potresti provare anche a creare nuovamente la scheda di rete virtuale o ad aggiornare/reinstallare i componenti di integrazione. La VMXNET è una scheda di rete virtuale pura, quindi è più sensibile ad eventuali problemi presenti con l'installazione dei servizi di integrazione. Inoltre non sono presenti driver nativi del sistema operativo, quindi eventualmente potresti anche provare a cambiare tipologia e a vedere se il comportamento è differente.

    http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1001805

    Con schede VMXNET e configurazioni in load balancing sono stati segnalati spesso problemi simili nella connettività.

    Inoltre la configurazione degli switch è stata controllata?

    martedì 27 maggio 2014 16:55
    Moderatore
  • Ciao e buongiorno,

    il server è il risultato di un "deploy" tramite VmWare ,

    di fatto tutte le macchine virtuali (sia quelle che si bloccano che le altre) sono "figlie" dello stesso "deploy".

    La macchina virtuale inizialmente aveva una scheda di rete di tipo E1000 , a seguito dei ripetuti blocchi identificando "anomalie" riguardanti le comunicazioni via rete , abbiamo sostituito la scheda con una di tipo VMXNET .

    Ho verificato che l'unica scheda inattiva presente è la "vecchia" E1000 che in ogni caso ho provveduto ad eliminare dalle perifieriche....

    La configurazione presente sugli switch è stata verificata ed è corretta.

    mercoledì 28 maggio 2014 07:20
  • Ho il sospetto che il problema dipenda proprio da VMWare o dal deploy, tra l'altro le altre macchine virtuali che non si bloccano hanno un'attività di rete molto inferiore. Se possibile prova con una nuova macchina virtuale, già il fatto che riscontravate anomalie con la scheda E1000 a mio parere non è molto normale e potrebbe essere un segnale.
    • Contrassegnato come risposta Anca Popa lunedì 2 giugno 2014 07:58
    mercoledì 28 maggio 2014 16:57
    Moderatore
  • Ciao Matteo,

    Nel frattempo, ho evidenziato la risposta di Fabrizio (penso che potrebbe essere valida per molti scenari simili).

    Se c'e' un'altra soluzione che vorresti condividere, puoi lasciare il tuo contributo in questo spazio (sarà sicuramente utile per gli altri membri del forum che seguono la discussione).

    Grazie,


    Anca Popa Follow ForumTechNetIt on Twitter

    Microsoft offre questo servizio gratuitamente, per aiutare gli utenti e aumentare il database dei prodotti e delle tecnologie. Il contenuto viene fornito “così come è” e non comporta alcuna responsabilità da parte dell'azienda.

    lunedì 2 giugno 2014 07:59