Behind The Scenes At My Spacecom

706 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
706
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Behind The Scenes At My Spacecom

  1. 1. Behind the Scenes at  MySpace.com Dan Farino Chief Systems Architect dan@myspace.com Friday, November 21, 2008 1
  2. 2. Topics Architecture overview and  • history • The stuff I get to work on (in  the Windows world) Monitoring • AdministraGon • 2 Friday, November 21, 2008 2
  3. 3. Topics Windows?! • It’s a good server (now leave me  • alone.) However, the selecGon of tools for  • large‐scale management is a bit  sparse... 3 Friday, November 21, 2008 3
  4. 4. Where we started  Friday, November 21, 2008 4
  5. 5. Where we started The ideal growth scenario • Plan • Implement • Test • Go live • Monitor and collect ops data • Repeat • 5 Friday, November 21, 2008 5
  6. 6. Where we started Our growth scenario: • Implement • Go live • And while those are happening  • over and over: Reboot servers • Throw hardware at performance issues • “Shotgun debugging” • 6 Friday, November 21, 2008 6
  7. 7. Where we started “Shotgun debugging”: Shotgun debugging is a process of  making relaGvely undirected changes  to soVware in the hope that a bug  will be perturbed out of existence. 7 Friday, November 21, 2008 7
  8. 8. Where we started Why would anyone “shotgun  • debug”? Don’t really know how to analyze  • and debug a problem Need to resolve the problem now  • and collecGng data for analysis  would take too long 8 Friday, November 21, 2008 8
  9. 9. Where we started Web servers • Windows 2000 Server • IIS 5.0 • ColdFusion 5 • Database servers • Windows 2000 Server • SQL Server 2000 • 9 Friday, November 21, 2008 9
  10. 10. Where we were OperaGonally • Batch files and robocopy for code  • deployment “psexec” for remote admin script  • execuGon Windows Performance Monitor for  • monitoring 10 Friday, November 21, 2008 10
  11. 11. Where we were Any sort of formal, automated  • QA process? No. • 11 Friday, November 21, 2008 11
  12. 12. Current architecture Friday, November 21, 2008 12
  13. 13. Current architecture 4,500+ web servers • Windows 2003/IIS 6.0/ASP.NET • 1,200+ “cache” servers • 64‐bit Windows 2003 • 500+ database servers • 64‐bit Windows 2003 • SQL Server 2005 • 13 Friday, November 21, 2008 13
  14. 14. QA today Unit tests/automated tesGng • • We sGll don’t “fuzz” the site  nearly as thoroughly as our  users do though • There are sGll problems that  happen only in producGon 14 Friday, November 21, 2008 14
  15. 15. QA today We need beher operaGonal  • data collecGon so that we  know what cases we’re not  tesGng 15 Friday, November 21, 2008 15
  16. 16. OperaGonal Data  CollecGon Friday, November 21, 2008 16
  17. 17. Ops Data CollecGon Two general types of systems: • StaGc • Collect, store and alert based on pre‐ • configured rules Dynamic • Write an ad‐hoc script or applicaGon to  • collect data for an immediate or one‐off  need 17 Friday, November 21, 2008 17
  18. 18. Ops Data CollecGon Our current “staGc” Windows  • Performance counter monitor: Friday, November 21, 2008 18
  19. 19. Ops Data CollecGon Cons of staGc system: • RelaGvely central configuraGon  • managed by a small number of  administrators Bad for one‐off requests: change  • the config, apply, wait for data Developer’s quesGons usually go  • unanswered 19 Friday, November 21, 2008 19
  20. 20. Ops Data CollecGon Developers looking at  • producGon?! Developers like to see their  • creaGons come to life (I know I do) The more a developer can see once  • their code goes live, the more  they’re going to know for V2 20 Friday, November 21, 2008 20
  21. 21. Ops Data CollecGon Cons of the dynamic system: • It’s not really a “system” at all...it’s  • an administrator running a script Is a privileged operaGon: scripts  • are powerful and can potenGally  make changes to the system Even run as a limited user, bad  • scripts can sGll DoS the system 21 Friday, November 21, 2008 21
  22. 22. Ops Data CollecGon Cons of the dynamic system: • One‐shot data collecGon is possible  • but learning about deltas takes a  lot more code (and polling, yuck) Different custom‐data collecGon  • tools that request the same data  point cause duplicated network  traffic 22 Friday, November 21, 2008 22
  23. 23. Ops Data CollecGon A recent example of an ad‐hoc  • task using our current  “dynamic” system: get‐adservers | run‐agent ps /e  • 'quot;Version: $(gcm F:file.dll | % {$_.FileVersionInfo.FileVersion} )quot;' | select Host, Message 23 Friday, November 21, 2008 23
  24. 24. Ops Data CollecGon Ideally, all operaGonal data  • available in the enGre server  farm should be able to  queried: Safely • Instantly • With change‐noGficaGon • 24 Friday, November 21, 2008 24
  25. 25. Ops Data CollecGon I’d like to be able to do  • something like this: SELECT CpuTime.*,  • ExceptionsPerSecond WHERE WebService.Status = ‘UP’ AND serving =  ‘profile.myspace.com’ OR serving = ‘home.myspace.com’ 25 Friday, November 21, 2008 25
  26. 26. Ops Data CollecGon I’d also to be able to leave that  query “hanging” and be noGfied  of changes like: A selected field has changed for a  • known data point A new server has come online and  • meets the criteria (or vice‐versa) 26 Friday, November 21, 2008 26
  27. 27. Our new operaGonal  data collecGon plalorm Friday, November 21, 2008 27
  28. 28. Ops Data CollecGon Our new operaGonal data‐ • subscripGon plalorm: On‐demand • Supports both “one‐shot” and  • “persistent” modes Can be used by non‐privileged  • users 28 Friday, November 21, 2008 28
  29. 29. Ops Data CollecGon Our new operaGonal data‐ • subscripGon plalorm: Eliminates the need for the  • consumer to poll for changes If a data source requires polling,  • that operaGon is pushed as close to  the source as possible 29 Friday, November 21, 2008 29
  30. 30. Ops Data CollecGon A Client makes one TCP  • connecGon to a “Collector” server Can receive data related to  • thousands of servers via this one  connecGon As long as the connecGon is up,  • the client is kept up‐to‐date 30 Friday, November 21, 2008 30
  31. 31. Ops Data CollecGon A lihle bit like: • Having all of the servers in a chat  • room and being able to talk to a  selected subset of them at any  Gme (over one connecGon) IniGal idea came from looking at  • using XMPP+ejabberd for  command and control 31 Friday, November 21, 2008 31
  32. 32. Ops Data CollecGon Agent Agent Agent One lazily-established TCP connection per Agent Collector Server Preferably one TCP connection per Client, Client Client although more than one is allowed (but frowned upon) 32 Friday, November 21, 2008 32
  33. 33. Ops Data CollecGon Provides: • Windows Performance Counters • WMI objects • Event logs • Hardware data • Custom WMI objects published from out‐ • of‐process Log file contents • 33 Friday, November 21, 2008 33
  34. 34. Ops Data CollecGon Provides: • On Linux, plans are to hook into  • something like D‐Bus so that  processes can provide operaGonal  data to the Agent in a loosely‐ connected manner 34 Friday, November 21, 2008 34
  35. 35. Ops Data CollecGon The Collector service: • A Windows Service in C# • Completely async I/O (never blocks  • a thread) Uses MicrosoV’s “Concurrency and  • CoordinaGon RunGme” An Agent running on each host  • 35 Friday, November 21, 2008 35
  36. 36. Ops Data CollecGon Wire protocol is Google’s  • Protocol Buffers • Clients and Agents can be  easily wrihen in any of the  languages for which there is a  PB implementaGon 36 Friday, November 21, 2008 36
  37. 37. Ops Data CollecGon Why not use XMPP+ejabberd? • Wanted to use Protocol Buffers  • instead of XML Wanted lazily‐established TCP  • connecGons to the Agents Wanted to see if C#+CCR could  • handle the load (yes it can) 37 Friday, November 21, 2008 37
  38. 38. Why develop a whole  new plalorm? Friday, November 21, 2008 38
  39. 39. Ops Data CollecGon Why develop something new? • There doesn’t seem to be anything  • out there right now that fits the  need And my requirements also include  • free and open source... 39 Friday, November 21, 2008 39
  40. 40. Ops Data CollecGon To do it properly, you really  • need to be using 100% async I/O. • Libraries that make this easy  are relaGvely new CCR, Twisted, GTask, Erlang • 40 Friday, November 21, 2008 40
  41. 41. Ops Data CollecGon Most established products  • were wrihen before the mulG‐core/async craze 41 Friday, November 21, 2008 41
  42. 42. Ops Data CollecGon What does it enable? • The individual that is actually  • interested in the data can gather it  himself No central config, no need to  • involve an administrator This includes developers • 42 Friday, November 21, 2008 42
  43. 43. Ops Data CollecGon What does it enable? • There is a very low “barrier to  • entry” It’s almost like exploring a database  • with some ad‐hoc SQL queries “I wonder...” quesGons are easily  • answered without a lot of work 43 Friday, November 21, 2008 43
  44. 44. Ops Data CollecGon What does it enable? • CharGng/alerGng/data‐archiving  • systems no longer concern  themselves with the data‐collecGon intricacies. We can spend Gme wriGng the  • valuable code instead of rewriGng  the same plumbing every Gme 44 Friday, November 21, 2008 44
  45. 45. Ops Data CollecGon What does it provide? • Abstracts physical server‐farm from  • the user If you know machine names, great.  • But you can also say “all servers  serving ‘profile.myspace.com’” or  “all cache servers in Los Angeles” 45 Friday, November 21, 2008 45
  46. 46. Ops Data CollecGon What does it provide? • Guaranteed to keep you • “up‐to‐date” Get your iniGal set of data and then  • just wait for the deltas Pushes polling as close to the  • source as possible 46 Friday, November 21, 2008 46
  47. 47. Ops Data CollecGon What does it provide? • Eliminates duplicate requests • Hundreds of clients can be  • monitoring the “% Processor Time”  for a server and it will only be sent  from that server once when it  changes 47 Friday, November 21, 2008 47
  48. 48. Ops Data CollecGon What does it provide? • Only collects data that someone is  • currently asking for This is how we avoid having explicit  • configuraGon on the server 48 Friday, November 21, 2008 48
  49. 49. Ops Data CollecGon Is this really a good way to do  • things? Having too much data pushed at  • you is a bad thing Being able to pull from a large  • selecGon of data points is a good  thing 49 Friday, November 21, 2008 49
  50. 50. Ops Data CollecGon For developers, knowing that  • they will have access to  instrumentaGon data even in  produc4on encourages more  detailed instrumentaGon 50 Friday, November 21, 2008 50
  51. 51. Ops Data CollecGon Beher instrumentaGon = more  • data available = more detailed  feedback to QA and  developers 51 Friday, November 21, 2008 51
  52. 52. Ops Data CollecGon Ease‐of‐use is a very high  • priority • Easy and fun APIs encourage  adopGon 52 Friday, November 21, 2008 52
  53. 53. Ops Data CollecGon LINQ via C#: • var collector = new Collector(...); var counters = from server in collector where server.subdomain = “www.myspace.com” select server.WindowsPerfCounter into counters where counters.category = “Processor” select server.Name, counters.Instance, counters.Value 53 Friday, November 21, 2008 53
  54. 54. Ops Data CollecGon LINQ via C# and CLINQ  • (“ConGnuous LINQ”) = instant  monitoring app (in about 10  lines of code): var counters = ... MainWpfWindow.MainGrid = counters; // Go grab a beer 54 Friday, November 21, 2008 54
  55. 55. Ops Data CollecGon Tail a file across thousands of  • servers With the filtering expression being  • run on the remote machines At the same Gme as someone else  • is (with no duplicate lines being  sent over the network) 55 Friday, November 21, 2008 55
  56. 56. Ops Data CollecGon Open source? • Hopefully! • Other implementaGons? • I may write a GTask or Erlang  • version as a “weekend” project 56 Friday, November 21, 2008 56
  57. 57. Thank you! Friday, November 21, 2008 57

×