net-op: traffic loads as the result of patching
So, maybe an operational question. What are people seeing as far as network traffic loads due to WMF patching activity, e.g. auto-update and manual downloads? Microsoft has used several CDNs in addition to its own servers to distribute the load in the past.
Sean Donelan wrote:
So, maybe an operational question.
What are people seeing as far as network traffic loads due to WMF patching activity, e.g. auto-update and manual downloads? Microsoft has used several CDNs in addition to its own servers to distribute the load in the past.
Most organizations use from one to quite a few of their own distribution points. It would be interesting to know what the stats are at broadband providers... Although proxying may make the results a bit "nicer" in some places. Gadi.
Sean Donelan wrote:
So, maybe an operational question.
What are people seeing as far as network traffic loads due to WMF patching activity, e.g. auto-update and manual downloads? Microsoft has used several CDNs in addition to its own servers to distribute the load in the past.
WSUS servers are being pounded right now. Usually 5 to 7% CPU now 72% -- http://www.digitalrage.org/ The Information Technology News Center
Elijah Savage wrote:
Sean Donelan wrote:
So, maybe an operational question.
What are people seeing as far as network traffic loads due to WMF patching activity, e.g. auto-update and manual downloads? Microsoft has used several CDNs in addition to its own servers to distribute the load in the past.
WSUS servers are being pounded right now. Usually 5 to 7% CPU now 72%
On usual Black Tuesdays though, there is quite a rush as well. Thing is this patch is alone while then there are a few. I believe it might even itself out in statistics. Gadi.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hmm..I thought (correct me if I wrong) wsus followed a mirror (distributed) model say if a group of servers were pegged the update process would provide remote clients access to the closet and min latency host(s) in order to distribute the load prevent bandwidth saturation. regards, /virendra Elijah Savage wrote:
Sean Donelan wrote:
So, maybe an operational question.
What are people seeing as far as network traffic loads due to WMF patching activity, e.g. auto-update and manual downloads? Microsoft has used several CDNs in addition to its own servers to distribute the load in the past.
WSUS servers are being pounded right now. Usually 5 to 7% CPU now 72%
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDvqLlpbZvCIJx1bcRAoF4AJ9pi/xlNkX8mSMT4ogZcVccrJ9ijACg854X JhwaWYg6bEmVf4yHVmY6mQI= =3oZt -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
hmm..I thought (correct me if I wrong) wsus followed a mirror (distributed) model say if a group of servers were pegged the update process would provide remote clients access to the closet and min latency host(s) in order to distribute the load prevent bandwidth saturation.
regards, /virendra
Elijah Savage wrote:
Sean Donelan wrote:
So, maybe an operational question.
What are people seeing as far as network traffic loads due to WMF patching activity, e.g. auto-update and manual downloads? Microsoft has used several CDNs in addition to its own servers to distribute the load in the past. WSUS servers are being pounded right now. Usually 5 to 7% CPU now 72%
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDvqLlpbZvCIJx1bcRAoF4AJ9pi/xlNkX8mSMT4ogZcVccrJ9ijACg854X JhwaWYg6bEmVf4yHVmY6mQI= =3oZt -----END PGP SIGNATURE----- You are correct and with BITS2.0 or really any version of BITS which any updated system should have BITS2.0 it will use only the available bandwidth given. So say you are using 70% of your bandwidth, BITS on XP will only use the other 30%. So Bandwidth should not be an issue, but what I have noticed with WSUS is multiple clients connecting to the server will drive cpu utilization up only in peak form though like on initial connection. For us this is one service that was not built redundant because if for some reason like maintenance and our server is down the clients will then failover to Micro$ofts servers to get them
Vicky Røde wrote: directly. -- http://www.digitalrage.org/ The Information Technology News Center
You are correct and with BITS2.0 or really any version of BITS which any updated system should have BITS2.0 it will use only the available bandwidth given. So say you are using 70% of your bandwidth, BITS on XP will only use the other 30%. So Bandwidth should not be an issue, but what I have noticed with WSUS is multiple clients connecting to the server will drive cpu utilization up only in peak form though like on initial connection. For us this is one service that was not built redundant because if for some reason like maintenance and our server is down the clients will then failover to Micro$ofts servers to get them directly.
I can't, and don't, speak for Sean, but I think he meant carrier side. I didn't know WSUS was a local update server, but I do now. I think in terms of Internet operations it's irrelevant how a WSUS is fairing since that is completely under the control of the person operating it i.e. get more memory, disk, or allocate more b/w if you have too .. and it's that important. MS did the right thing and made it free after all. I cant see that anyone is seeing anything other than the "same o". MS patches all the time and has a lot of experience in capacity management so I would think that they would've said something if it was to be different than other patches. I've been monitoring IX stats and I am not seeing much including small anomalies. In one of the European IX's I saw what looked like the botnet itself operating. There was a delta on the patch release and the anomaly dropped, but I can't confirm it was related to the worm. Speculation, but a fair one. I didn't contact the IX since it dropped off and don't plan to. I think that this is just another day on the Internet. Unfortunately. -M<
participants (5)
-
Elijah Savage -
Gadi Evron -
Martin Hannigan -
Sean Donelan -
Vicky Røde