none
WSUS su Win2012R2 - dimensionamento e scelte corrette RRS feed

  • Domanda

  • Buongiorno a tutti,
    premetto che ho diverse installazioni di WSUS funzionanti presso diversi clienti e che in un solo caso riscontro i problemi che vi espongo potandomi a credere che il tutto sia solo un problema di dimensionamento corretto.

    la realtà che devo andare a gestire prevede circa 2500 tra client e server su circa 15 sedi geografiche separate. la gestione degli aggiornamenti deve essere fatta attraverso il WSUS.

    dopo aver installato e attivato il servizio funziona tutto regolarmente per qualche giorno, dopodiché inizio a ricevere con estrema frequenza errori di timeout di connessione al DB la la classica richiesta di resettare il nodo (per estrema frequenza intendo quasi ad ogni approvazione o modifica di distribuzione di un aggiornamento, per non parlare delle operazioni di manutenzione pulizia che vanno regolarmente in blocco).

    la macchina è dedicata a questo ruolo ha 4 CPU e 10 Gb di ram.

    ho fatto diverse installazioni per una soluzione ma il problema l'ho riscontrato in egual modo con il DB interno, con un sql express 2005 installato sulla stessa macchina  e anche con un sql 2008r2 montato su una seconda macchina.

    nei primi 2 casi ( db interno e sql express) notavo che la cpu della macchina non oltrepassava mail il 25% di 4 cpu ovvero il 100% su singola CPU, credo di aver capito che questo è un comportamento by design.

    ora la mia domanda è questa: come mi consigliate di configurare questo server?
    CPU?
    RAM?
    Tipo di DB?

    devo trovare un modo per farlo funzionare...
    grazie a tutti.

    ciao.


    • Modificato Dario Bonini lunedì 23 giugno 2014 08:40 dettagli
    lunedì 23 giugno 2014 08:37

Risposte

Tutte le risposte

  • ecco un classico errore:

    The WSUS administration console was unable to connect to the WSUS Server Database.
        
    Verify that SQL server is running on the WSUS Server. If the problem persists, try restarting SQL.
        
    
    System.Data.SqlClient.SqlException -- XML document could not be created because server memory is low. Use sp_xml_removedocument to release XML documents.
    invalid parameter eventFilterXml
    
    Source
    .Net SqlClient Data Provider
    
    Stack Trace:
       at Microsoft.UpdateServices.Internal.ClassFactory.CallStaticMethod(Type type, String methodName, Object[] args)
       at Microsoft.UpdateServices.Internal.BaseApi.Subscription.GetSynchronizationHistory(DateTime fromDate, DateTime toDate)
       at Microsoft.UpdateServices.Internal.BaseApi.Subscription.GetLastSynchronizationInfo()
       at Microsoft.UpdateServices.UI.SnapIn.Scope.SyncResultsListScopeNode.RefreshActionsPaneActions()
       at Microsoft.UpdateServices.UI.SnapIn.Scope.SyncResultsListScopeNode..ctor(ServerTools serverTools)
       at Microsoft.UpdateServices.UI.SnapIn.Scope.ServerSummaryScopeNode.AddChildNodes()
       at Microsoft.UpdateServices.UI.SnapIn.Scope.ServerSummaryScopeNode.ConnectToServerAndPopulateNode(Boolean connectingServerToConsole)
       at Microsoft.UpdateServices.UI.SnapIn.Scope.ServerSummaryScopeNode.ResetScopeNode()

    lunedì 23 giugno 2014 09:05
  • Non so, forse per così tanti client preferirei segmentare un po' l'infrastruttura. Creare cioè un server WSUS padre sul tuo server attuale e poi creare, almeno nelle sedi un po' più grandi, dei server figlio che si sincronizzano. Per ogni sede utilizzerai poi Group policy con il puntamento verso il server locale.

    In questo modo puoi distribuire meglio il carico tra le varie richieste ed evitare colli di bottiglia dovuti alla connettività di rete tra sedi.


    lunedì 23 giugno 2014 10:02
    Moderatore
  • Ciao, vista la non totale gestibilità degli aggiornamento sotto WSUS ed un ambiente multi-site potresti optare per una gestione differente. Per esempio server distribuiti su vari site.

    Di seguito alcuni esempi di distribuzione:

    Qualche spunto di implementazione la potresti trovare sul WSUS Product Team Blog.

    Saluti
    Nino


    ...esistono i motori di ricerca, facci un salto e troverai molte delle risposte che ti darò io.

    • Contrassegnato come risposta Anca Popa lunedì 30 giugno 2014 09:45
    lunedì 23 giugno 2014 10:25
    Moderatore
  • ciao,

    le sedi remote ospitano pochi client rispetto alla sede principale e in ogni caso non ci sono le risorse per montari in remoto.

    il server o i server devono stare nella sede principale.

    lunedì 23 giugno 2014 10:39
  • In tal caso potrebbero esserti utili queste pagine:

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

    Per il database consiglio ovviamente di optare per un'installazione di SQL Server completa:

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

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

    Comunque assicurati che la connettività della rete principale sia sufficiente anche per il passaggio di aggiornamenti nelle VPN delle sedi, altrimenti rischi di avere problemi (non solo per quanto riguarda la distribuzione di aggiornamenti).

    • Contrassegnato come risposta Anca Popa lunedì 30 giugno 2014 09:45
    lunedì 23 giugno 2014 11:48
    Moderatore