Endpoint Protection

 View Only
Expand all | Collapse all

SEPM talking to SQL server

  • 1.  SEPM talking to SQL server

    Posted May 15, 2009 09:02 AM
    In talking with our network and telecom manager the other day, he mentioned that around the beginning of April (when I started creating SEPM servers and upgrading our clients) our network traffic was well above where it should be especially at night. Working with AT&T they were able to narrow it down to my SEPM servers talking the SQL server.

    I've got 6 SEPM servers stretching from East to West coast and the SQL cluster is housed in our Co Lo in California. The biggest offenders are in Pennsylvania and Ohio which are hogging about 20% bandwidth at night when there should be zero to 1% traffic.

    What are the servers doing to use up that kind of bandwidth? The sites have full T1s. Here is how much data they saw moving in a 4 1/2 hour period last night.

    SQL to Ohio server - 175MB
    SQL to PA server- 492MB

    Ohio server to SQL - 13MB
    PA server to SQL - 54MB


  • 2.  RE: SEPM talking to SQL server

    Posted May 15, 2009 09:29 AM
    Are you having the SEMs do backups of the SQL data? That's an option........ and I wonder if you have that set.
    Do you have any groups with assigned packages for updates?


  • 3.  RE: SEPM talking to SQL server

    Posted May 15, 2009 11:17 AM
    I just looked and don't see an option to automatically backup the database. Wouldn't the backup have to be run manually?


  • 4.  RE: SEPM talking to SQL server

    Posted May 15, 2009 12:49 PM
    ouch, so you have a single SQL server over the WAN from 6 sites each with their own SEPM?

    that doesnt sounds right.  you may want to evaluate replication or GUPS for remote sites, depends on how many clients at each site though.

    SEPM is a pretty SQL intense app, the recommendation is to have SQL + SEPM on the same switch or at least in the same datacenter.  Your SEPMs are sending over every log (av, scan, traffic, packet, etc) from every client for entry into the DB or if there is a console open, the SEPM will be grabbing all the reports and data back to the console through SQL.

    With replication this same DB data is sent, but it is compressed and entered all at once on replication.  console sessions would not go over the WAN either in a replication scenario, which will improve performance for them considerably.

    Did you upgrade from SAV?  Topologies that worked well for SAV, don't always carry over to SEP well.


  • 5.  RE: SEPM talking to SQL server

    Posted May 15, 2009 01:09 PM

    rwessen have a good point.

    Just to expand on this, what is the schedule you've setup for sending updates, maintenance, etc?



  • 6.  RE: SEPM talking to SQL server

    Posted May 15, 2009 02:32 PM
    Is there a way to trim down the logs so that only alerts for virus' is sent?


  • 7.  RE: SEPM talking to SQL server

    Posted May 15, 2009 07:25 PM
    I don't think that's an option. Maybe you'd want to create SQL DB locally.


  • 8.  RE: SEPM talking to SQL server

    Posted May 15, 2009 08:23 PM
    This is why we recommend that SQL is located close to SEPM, ideally on at least 100Mbps ethernet - perfect situation is gigabit and on the same switch :-)

    The SEPM's are constantly talking to the databases, refreshing policy, making sure the connection is still up, etc.  I would say that sort of traffic you are seeing is not out of the ordinary for the amount of work the servers are doing (even when idle)

    If you can post more around your numbers of clients, etc. then there may be other ways to do this deployment.


  • 9.  RE: SEPM talking to SQL server

    Posted May 15, 2009 11:56 PM
    See, I asked these kinds of questions when I originally talked to a Symantec tech before starting this project. His response was "Oh no, it's not a problem having servers in those locations. There won't be much traffic." Apparently he left out the part that it won't be a problem as long as they have their own SQL server in that location. Great.

    We'll have close to 1,000 clients total when done.


  • 10.  RE: SEPM talking to SQL server

    Posted May 16, 2009 09:46 AM
    with a maxiumum of 1000 clients you shouldn't need 6 SEPM servers. GUPS can handle this. I would have one or two SEPM's (for DR) at the same site, then use GUPS at the other sites. just my 2 cents.


  • 11.  RE: SEPM talking to SQL server

    Posted May 16, 2009 01:04 PM
    Put your SEPM in the same co-lo rack as your SQL server.  Use a local DC/file/print server as a GUP at each remote site, ditch the separate SEPMs at each site.  It will simplfy management overhead as well as get rid of your SQL bandwidth issue.

    Bump the number of def delta content revisions to keep on the SEPM up to 90 (~30 days worth), this will keep your WAN traffic to a minimum even if the GUP is down or overloaded.  Set the GUP policy to wait for a good amount of time before bypass, let the GUP store as many delta revisions of defs as possible as space allows (content + disk space settings).

    For only 1000 clients, I wouldnt use replication unless 80%+ of your clients are in one location that's separate from your co-lo.  Then you might put a SEPM+SQL there and replicate between that site and the co-lo SEPM+SQL.

    If you want to PM me to discuss details you may not want to post here, go for it.


  • 12.  RE: SEPM talking to SQL server

    Posted May 16, 2009 05:57 PM
    Thanks guys. My boss isn't going to be too happy about the changes but he'll get over it.

    How exactly does the GUP work and is it pretty easy to setup/configure?


  • 13.  RE: SEPM talking to SQL server



  • 14.  RE: SEPM talking to SQL server

    Posted May 18, 2009 04:31 AM
    i had the same problem
    only the day traffic was about 3-4 Gb (((
    i had to reconfigure SEPMs structure to several sites
    you can have one primary site on SQL and replication partners on embedded DB - it will save your channel


  • 15.  RE: SEPM talking to SQL server

    Posted May 19, 2009 09:19 AM
    Viachaslau: I didn't realize you could have SQL and embedded working together. I'm assuming you have one central SEPM server on the same wire as the SQL box but how did you configure the other offsite SEPM servers with embedded DB and get them to replicate the data? That sounds like it might the better option for us.


  • 16.  RE: SEPM talking to SQL server

    Posted May 19, 2009 05:59 PM
    Configuring a GUP is piece of cake, start by creating a LiveUpdate policy in which you'll specify the GUP (IP or FQDN). Assign this policy to both the GUP as the clients it need to serve.
    Once the GUP has downloaded this policy, it will notice it is supposed to act as a GUP (provide new AV defs to SEP clients). What makes it different from a "normal" SEP client, it will load "mini HTTP server code" in order it will listen to requests made by clients.

    As far as replication is concerned; replicating between SQL site and Embedded DB site --> doesn't t give errors on the embedded DB site?

    BadAndy, good luck!

    Dries


  • 17.  RE: SEPM talking to SQL server

    Posted May 20, 2009 01:57 PM
    We're not going to use GUPs.

    I'm going to remove 3 of the SEPM servers (they are app/file servers but LiveUpdate Administrator will still run on them though) that don't have but a few clients connecting to them. Along with our primary SEPM at our co lo that is in the same rack as the SQL server, I'm going to connect the SEPM at our HQ to a SQL box in the same building and the last SEPM which is located in my plant in South Carolina will be connected to a SQL box that I'm about to put together.

    Is that an acceptable configuration? If so, how do I get the 3 SQL databases in sync with each other? The main reason for having the seperate SEPMs was for fail over and for when new versions of SEP are released when can update the clients via the Install Packages tab in the console.


  • 18.  RE: SEPM talking to SQL server

    Posted May 20, 2009 03:13 PM
    BadAndy,

    Why so quick to dismiss the use of GUP's?  Using them will reduce your WAN traffic so your clients do not have to get definition updates from your SEPM's.  It really isn't that hard to implement and once you implement, there's really no maintenance to deal with.


  • 19.  RE: SEPM talking to SQL server

    Posted May 20, 2009 03:23 PM
    They've never received virus defs from the SEPM. I have LiveUpdate Administrator installed on local file servers which had SEPM installed to avoid WAN traffic.