Jump to content


Vitalishe

Established Members
  • Posts

    1
  • Joined

  • Last visited

Vitalishe's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. Hello dear colleagues. I got a huge problem i decribed here http://social.techne...b1-122d672dde6a I need you help to understand: what can be a main cause of so high sql traffic to remote management server. Situation describtion: There're many articles being written about work of RMS and MS with agents and SQL databases in SCOM 2007 R2 CU6. About how agents are sending data to the MS or GW and then how it gets to SQL. But... But, I can found nothing about following scenario (A part of customer's infrastructure): Let's take two offices to simplify: HQ and branch connected by VPN (WAN); An inbound traffic from SQL to remote MS is 2.7 GB per 20 hours; An outbound traffic is equals to nothing, up to 100 Mb per 24 hours. I checked - all traffic is generated by MS SQL to remote Management Server (Look at the attachment Architecture.bmp) I know that MS can take from SQL: MPs cache; Discovery Data (Computer and Objects to monitor); Extra rules or overrides; My questions are: What can generate such large amount of traffic? What components remote MS can request from SQL except components I wrote before? Can MPs renewal process generate such amount of traffic (Or possible rules or monitors change)? By the way. I know well about concepts of planning architecture of SCOM, I know that an architecture I described - is wrong. Never the less, I can't find a good explanation about such high inbound traffic from SQL to remote MS (If it was vise-versa - at least it had logical explanation). My customer got 16 remote MSs, and only 5 of them show such traffic. Each of them has from 5 to 18 agents assigned. We talk about SCOM 2007 R2. As I know SCOM Console needs the SDK service to be available on the management server to make connection to the server. In SCOM 2007 R2 only RMS has SDK service enabled and only one RMS can be available in one management group at a time. http://technet.micro...y/bb735400.aspx So, as I suppose it's not an option. Event 21025 appears quite unregular: It can appear several times in 24 hours (in a period of 2-4 hours); It can appear once in 8 hours or more. Of course we're talking about process that delivers new management group configuration to the MS. By the way, I measured traffic - server gets approximately 24-30 Mb per this cycle (inbound traffic from SQL) on servers that have large amount of traffic. But in this management group 16 management servers are present and large number of them don't get more then 30-100 Mb per 20 hours, less number gets from 100 mb to 400 mb per 20 hours. 5 five of them are getting all. There's an example: First screenshot was made on a server that downloaded from sql 2,7 Gb - 15 agents are assigned to this MS; (look at the attachement high traffic server.bmp) The second screenshot from a server that got only ~35 Mb - 8 agents assigned to this MS; (look at the attachement 21025 event low traffic server.bmp) There's no great difference! All servers are different in: Number of assigned agents; And some of them different in a list of services they are monitored; An example: I got two management servers. 2-nd one has 6 agents assigned. 1-st one has 8 agents. 1-st MS gets ~30 - 35 Mb per 20 Hours, 2-nd one gets 1.6 Gb per 20 Hours. List of Serices that monitored: (look at the attachement MPs comparation.bmp) I think that there's no depence on a number of agents in this case. Possible the situation depence on a sevices that are monitored. But I guess in this case a traffic should be outbound from branch management server to RMS and SQL, but not inbound from SQL to the branch management server. I guess I missing smth. in understanding how SCOM should work. Assist please. 21025 event low traffic server.bmp high traffic server.bmp MPs comparation.bmp
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.