Farming hadoop in_the_cloud
5 likes•2,640 views
The document discusses running Hadoop clusters in the cloud and the challenges that presents. It introduces CloudFarmer, a tool that allows defining roles for VMs and dynamically allocating VMs to roles. This allows building agile Hadoop clusters in the cloud that can adapt as needs change without static configurations. CloudFarmer provides a web UI to manage roles and hosts.
Farming hadoop in_the_cloud
- 1. FARMING HADOOP IN THE CLOUD Steve Loughran HP Laboratories June 2010
- 2. ABOUT ME Researcher at HP Laboratories Bristol, England
- 3. Datacentre-scale apps & IaaS
- 5. Committer: Ant, Hadoop-common, HDFS, MapReduce
- 6. Author: Ant in Action
- 7. Somewhat obsessive about testing
- 8. CLOUD ELIMINATES Buying hardware based on predicted load
- 9. 2+ week lead time on new hardware, storage
- 11. Homogeneity
- 12. Static machine names, addresses and capabilities
- 13. Stable machines
- 14. A fast private network
- 15. Someone in the datacentre who cares about you
- 16. APPLICATIONS MUST BE AGILE Directory, database or CM service to configure
- 17. Applications to handle moving services
- 18. Use dynamic DNS services; don’t cache IPAddrs
- 19. Don’t expect HDD content to last on a single disk
- 20. Restart VMs on any app failure Nothing is static. Nothing lasts .
- 21. CLASSIC TEAM ROLES Business Development Architecture Operations Development
- 22. Business Development Architecture Operations Development BEFORE Design Code Test Staging Live
- 23. RESPONSIBILITIES Work Architects design the application
- 24. Developers code and test on local machines
- 25. Operations buy and configure production machines Blame Developers get blame for things not working
- 26. Operations get blame for security & availability problems
- 27. Getting predictions of demand wrong can kill your project
- 28. Architecture Development Business Development EVERYTHING BLURS Design Code Test Live Staging Operations
- 29. Role Task Tooling Cloud Architect Design App structure Text editor (?)) Powerpoint (? Cloud Operations Build VMs, set parameters Manage production Text under SCM Web & Command line Developers Request test VMs Web, IDE, build tools Biz Dev Worry about money Web & Spreadsheet DIFFERENT ROLES - DIFFERENT TOOLS
- 30. Hadoop's datamining services are needed by the developers, biz-dev, operations and infrastructure teams
- 31. HADOOP’S ASSUMPTIONS Hadoop is not agile Master nodes don’t move
- 32. Workers can spin for them
- 33. Failed workers get blacklisted
- 35. Cache all DNS entries
- 36. Disks don't move between hosts
- 37. CLOUDFARMER Role-driven VM allocation UI split by team role
- 38. ROLE SPECIFICATION worker extends HadoopVMRole { description "A Hadoop Worker"; vmPrefix "vm"; bootAutoVol "vol-0-1-47"; min 0; recommendedMin 3; deploy "worker.sf" links extends HadoopServlets { hdfs DFS_DATANODE_HTTP_DEFAULT_PORT; "Hadoop DFS" ["http", hdfs, "/"]; "Hadoop DFS metrics" ["http", hdfs, METRICS]; "Hadoop DFS stacks" ["http", hdfs, STACKS]; "Hadoop DFS conf" ["http", hdfs, CONF]; "Hadoop DFS conf JSON" ["http", hdfs, CONF_JSON]; } }
- 39. WEBAPP LISTS AVAILABLE ROLES VMs with post-deployment actions
- 40. HADOOP CLUSTER: MASTER + WORKER Webapp does the binding and cluster config
- 42. LIST HOSTS IN A ROLE Actions: Add a worker, delete all in role “worker”
- 43. LIST ALL HOSTS
- 44. VIEW A HOST
- 46. GRAPH VIEW
- 47. BENEFITS Infrastructure can do late-binding install/deploy
- 48. Feeds into the UI
- 49. Web, IDE, build tools, ...
- 50. “ Role” CPU/network history can aid placement
- 51. Other templates: network, aggregate clusters
- 52. TODO VM Placement based on (data, user, VM role)
- 53. What is the right cloud UIs for biz dev?
- 54. Collecting, analysing test runs
- 55. Collect, analyse VM histories
- 56. Hadoop: lifecycle patches in
- 57. Hadoop: make agile against NN & JT
- 58. Hadoop: more job monitoring
- 59. Q&A
Editor's Notes
- #2: 6 June 2010 HP Confidential
- #4: What does all this mean? You don’t need to predict your customer load in advance, though you had better hope your supplier can offer a service to match You don’ t have to wait a few weeks for some order of hardware to get delivered. You can’t buy HA kit: RAID, L7 routers, other nice things, to address availability. You need to design these in You can’t be sure your machines will stay around, that when they come back their names and IP Addresses may change You don’t have someone with a pager in the room who will track down network problems for you 6 June 2010 HP Confidential
- #5: We really need to rethink how to design apps in this world, the old ways don’t. When a VM goes, so does any transient HDD. When a machine gets terminated and re-instantiated, it can have different hostname and address. Nor can that server deal with machines moving around. Which is a pity as the simplest way to deal with app trouble is to reset the VM. No need to worry about what its previous state June 6, 2010 HP Confidential
- #6: Here are some of the classic roles of back-end projects. There’s also graphic designers, marketing, content generation, etc. But this is the code side. Everyone’s job is hard. Biz dev: make sure the idea is good, predict demand , get the ops team to work with Arch and Finance to get machines to meet the demand Architecture: design something that works in the machines that ops will bring up Developers: code and test the app, produce something that works 6 June 2010 HP Confidential
- #7: This is how things were built -at best- if you had a static set of machines as your target. Even if you design/code/test in a cycle, going live creates problems. Different systems, different networks, etc. Staging is meant to simplify this with a setup that mimics production, but it still has different users . June 6, 2010 HP Confidential
- #8: This is how things are today. Set up for conflict. The big one is developers "ship code that is functional" and ops "run secure services". 6 June 2010 HP Confidential
- #9: Once you stop needing a physical cluster of machines to test on, you can give every developer a virtual cluster which mimics that in production. You can bring up a staging site on the public server farm, let third parties play with it, switch it over when you are happy (ignoring data issues) 6 June 2010 HP Confidential
- #10: Developers shouldn’t be creating the machine configurations; that’s a job for the architect and ops Ops have to move beyond the pager when a machine fails to getting an overall statistical view of what works, doesn't work, and look at the total, perceived picture. No more panicing when a machine goes down, but do worry when all the machines start to fail too often. Solution: monitoring and statistics. Datamining. Hadoop. Biz dev/management need to keep an eye on costs and revenue. Costs: machines. Revenue, things like why people are switching from free to premium, where customers are coming from. Statistics.Datamining. Hadoop. June 6, 2010 HP Confidential
- #11: At this scale, datamining and statistics becomes an essential background activity Test result collection and analysis Application and VM log file capture, analysis: chukwa Application load analysis - feed into VM create/destroy User/paying customer mining -when do people pay, when do they leave? Infrastructure: how do people and their VMs behave? 6 June 2010 HP Confidential
- #12: These are where Hadoop contains assumptions that are valid in the physical datacentre, but which don't work in a virtual world. 6 June 2010 HP Confidential
- #15: This for everyone to create machines. You can only create machines in roles you have the right to. This is more than a constrained image, much more of the config is locked down: VM, networking, dynamic options. June 6, 2010 HP Confidential
- #16: I’ve cheated and added some Hadoop-specificness in the web front end; you can create Hadoop workers and it knows to create the Master first, and passes the master hostname down so that the workers bond properly. This use case needs to be made generic June 6, 2010 HP Confidential
- #17: This is a fairly weak Web UI but it’s designed to feed into portals. It also happens to test easily. 6 June 2010 HP Confidential
- #25: 6 June 2010 HP Confidential