RAD Lab - Recent changes [en]

Cleaning Days

2009-11-23T21:36:31Z

/* Thursday 12.3.09, 11:00am */

Revision as of 21:36, 23 November 2009		Current revision
Line 27:		Line 27:

	* Everyone, clean your work space, wipe down your desk, dust your desk: Everyone		* Everyone, clean your work space, wipe down your desk, dust your desk: Everyone
-	* Clean out [get rid of old food and wipe down] Refrigerator and Freezer:	+	* Clean out [get rid of old food and wipe down] Refrigerator and Freezer: Michael
	* Swiffer Kitchen floor:		* Swiffer Kitchen floor:
	* Vacuum conference rooms, lounge area and hallway carpets (2 people): Kristal, Rean		* Vacuum conference rooms, lounge area and hallway carpets (2 people): Kristal, Rean

Cleaning Days

2009-11-23T19:06:12Z

/* Thursday 12.3.09, 11:00am */

Revision as of 19:06, 23 November 2009		Current revision
Line 29:		Line 29:
	* Clean out [get rid of old food and wipe down] Refrigerator and Freezer:		* Clean out [get rid of old food and wipe down] Refrigerator and Freezer:
	* Swiffer Kitchen floor:		* Swiffer Kitchen floor:
-	* Vacuum conference rooms, lounge area and hallway carpets (2 people): Kristal	+	* Vacuum conference rooms, lounge area and hallway carpets (2 people): Kristal, Rean
	* Organize and Wipe down all book shelves (2 people):		* Organize and Wipe down all book shelves (2 people):
	* Clean off and wipe down meeting tables, coffee tables, award cabinets, counters (2 people):		* Clean off and wipe down meeting tables, coffee tables, award cabinets, counters (2 people):

Cleaning Days

2009-11-23T18:28:02Z

/* Thursday 12.3.09, 11:00am */

Revision as of 18:28, 23 November 2009		Current revision
Line 29:		Line 29:
	* Clean out [get rid of old food and wipe down] Refrigerator and Freezer:		* Clean out [get rid of old food and wipe down] Refrigerator and Freezer:
	* Swiffer Kitchen floor:		* Swiffer Kitchen floor:
-	* Vacuum conference rooms, lounge area and hallway carpets (2 people):	+	* Vacuum conference rooms, lounge area and hallway carpets (2 people): Kristal
	* Organize and Wipe down all book shelves (2 people):		* Organize and Wipe down all book shelves (2 people):
	* Clean off and wipe down meeting tables, coffee tables, award cabinets, counters (2 people):		* Clean off and wipe down meeting tables, coffee tables, award cabinets, counters (2 people):

Cleaning Days

2009-11-23T18:23:27Z

/* Thursday 12.3.09, 11:00am */

Revision as of 18:23, 23 November 2009		Current revision
Line 32:		Line 32:
	* Organize and Wipe down all book shelves (2 people):		* Organize and Wipe down all book shelves (2 people):
	* Clean off and wipe down meeting tables, coffee tables, award cabinets, counters (2 people):		* Clean off and wipe down meeting tables, coffee tables, award cabinets, counters (2 people):
-	* Clean all white boards [with water]:	+	* Clean all white boards [with water]: Ari Rabkin
	* Clean and organize video game area:		* Clean and organize video game area:
	* Clean/organize bicycle area:		* Clean/organize bicycle area:
	* Clean up Printer areas (recycle old papers):		* Clean up Printer areas (recycle old papers):
	* Clean empty or out for the summer cubicles, including wiping down surfaces:		* Clean empty or out for the summer cubicles, including wiping down surfaces:

Cleaning Days

2009-11-23T18:18:14Z

Projects/SCADSDirector

2009-11-23T17:36:25Z

/* Performance-Safe Scaling in the Cloud: The SCADS Storage Director */

Revision as of 17:36, 23 November 2009		Current revision
Line 20:		Line 20:
	If this were a stateless system, such as the web server tier, the operators could handle load increase by simply statically overprovisioning the system by adding 25% more servers, and uniformly distributing the workload across all the servers.		If this were a stateless system, such as the web server tier, the operators could handle load increase by simply statically overprovisioning the system by adding 25% more servers, and uniformly distributing the workload across all the servers.
	However, in a stateful system, such as a storage system, this workload spike would be directed to a single server storing Michael Jackson's page.		However, in a stateful system, such as a storage system, this workload spike would be directed to a single server storing Michael Jackson's page.
-	Assuming a storage system with ten nodes, an attempt to overprovision it for this spike would require each server to be overprovisioned by 250%, since the location of a potential hotspot would be unknown before it occurs. The Director framework avoid the need for static overprovisioning by automatically adding more servers and partitioning data.	+	Assuming a storage system with ten nodes, an attempt to overprovision it for this spike would require each server to be overprovisioned by 250%, since the location of a potential hotspot would be unknown before it occurs. The Director framework obviates the need for static overprovisioning by automatically adding more servers and partitioning data.

	= Related publications =		= Related publications =

Projects/SCADSDirector

2009-11-23T17:22:06Z

/* Performance-Safe Scaling in the Cloud: The SCADS Storage Director */

Revision as of 17:22, 23 November 2009		Current revision
Line 3:		Line 3:
	* Peter Bodik http://govirtual.org/people/bodikp		* Peter Bodik http://govirtual.org/people/bodikp
	* Beth Trushkowsky http://govirtual.org/people/trush		* Beth Trushkowsky http://govirtual.org/people/trush
-	* Kristal Curtis	+	* Kristal Curtis http://www.govirtual.org/people/kristal.curtis

	Physical data independence protects a database application from having to change its conceptual schema when its physical storage is altered, allowing that application's storage strategy to evolve over time.		Physical data independence protects a database application from having to change its conceptual schema when its physical storage is altered, allowing that application's storage strategy to evolve over time.

Projects/SCADSDirector

2009-11-22T20:51:16Z

New page

== Performance-Safe Scaling in the Cloud: The SCADS Storage Director ==

* Peter Bodik http://govirtual.org/people/bodikp
* Beth Trushkowsky http://govirtual.org/people/trush
* Kristal Curtis

Physical data independence protects a database application from having to change its conceptual schema when its physical storage is altered, allowing that application's storage strategy to evolve over time.
Cloud computing introduces an additional dynamism: hardware resources can be scaled both up and down as computing needs change.
For interactive web application developers, this elasticity supports incremental growth as their website gains popularity.
Therefore, the cloud motivates a need for scale independence, where changes in workload volume or data hotspots require no modifications to the application or manual tuning of the underlying storage. Without scale independence, websites may face the fate of eBay.com, which had to rewrite its code-base multiple times and manually partition its databases to deal with the website's workload growth.
The hardware resources and data layout should be automatically reconfigured in real time to handle the new workload while maintaining the performance service-level agreements (SLAs) of the queries.

Providing scale independence is one goal of SCADS, a storage system designed for interactive web applications that provides eventual consistency.
SCADS allows developers to specify per-query latency and consistency SLAs that are decomposed into SLAs on the physical operations performed at the storage layer.
The Director control framework is an important component of SCADS scale independence that automatically reconfigures the storage layer in response to changes in workload to maintain the storage-layer latency SLAs.
These SLAs determine when we need to partition or replicate hot data across additional servers during a workload spike, and automatically coalesce servers when workload decreases.
Compared to traditional distributed storage systems (such as Dynamo) whose goal is to minimize latency by uniformly distributing the data among the servers, in the cloud environment the objective is to minimize the cost of running the system while avoiding SLA violations.

To highlight the importance of automatic scaling for stateful systems, consider the 25\% increase in aggregate workload on Wikipedia that occurred after the death of Michael Jackson.
If this were a stateless system, such as the web server tier, the operators could handle load increase by simply statically overprovisioning the system by adding 25% more servers, and uniformly distributing the workload across all the servers.
However, in a stateful system, such as a storage system, this workload spike would be directed to a single server storing Michael Jackson's page.
Assuming a storage system with ten nodes, an attempt to overprovision it for this spike would require each server to be overprovisioned by 250%, since the location of a potential hotspot would be unknown before it occurs. The Director framework avoid the need for static overprovisioning by automatically adding more servers and partitioning data.

= Related publications =

Statistical Machine Learning Makes Automatic Control Practical for Internet Datacenters, Peter Bodik, Rean Griffith, Charles Sutton, Armando Fox, Michael I. Jordan, David A. Patterson. In Workshop on Hot Topics in Cloud Computing (HotCloud '09), San Diego, CA, June 2009. [http://www.cs.berkeley.edu/~bodikp/publications/HotCloud09.pdf pdf]

Automatic Exploration of Datacenter Performance Regimes, Peter Bodik, Rean Griffith, Charles Sutton, Armando Fox, Michael I. Jordan, David A. Patterson. In First Workshop on Automated Control for Datacenters and Clouds (ACDC '09), Barcelona, Spain, June 2009. [http://www.cs.berkeley.edu/~bodikp/publications/ACDC09.pdf pdf]

Projects

2009-11-22T20:33:11Z

Revision as of 20:33, 22 November 2009		Current revision
Line 17:		Line 17:
	* [[Monitoring Hadoop\|Monitoring Hadoop using X-Trace]]		* [[Monitoring Hadoop\|Monitoring Hadoop using X-Trace]]
	* [[Projects/SCADS\|SCADS: Scaleable Consistency Adjustable Data Storage]]		* [[Projects/SCADS\|SCADS: Scaleable Consistency Adjustable Data Storage]]
		+	* [[Projects/SCADSDirector\|SCADS Director]]
	* [[Projects/Cloudstone\|Cloudstone: Multi-Platform, Multi-Language Measurement Tools for Web 2.0 and Cloud Computing]]		* [[Projects/Cloudstone\|Cloudstone: Multi-Platform, Multi-Language Measurement Tools for Web 2.0 and Cloud Computing]]
	* [[Projects/Director\|Director: Managing a Datacenter]]		* [[Projects/Director\|Director: Managing a Datacenter]]

Distributed Hadoop Master

2009-11-18T08:25:07Z

Revision as of 08:25, 18 November 2009		Current revision
Line 1:		Line 1:
-	http://www.cloudera.com/blog/2009/07/22/hadoop-ha-configuration/	+	http://www.cloudera.com/blog/2009/07/22/hadoop-ha-configuration/ - A blog article that was posted on Cloudera's website, written by Paul George who works for [http://contextweb.com ContextWeb], a company that does online advertising, about how they approach namenode High Availability.

	http://www.slideshare.net/cloudera/hw09-production-deep-dive-with-high-availability		http://www.slideshare.net/cloudera/hw09-production-deep-dive-with-high-availability
		+	A web slideshow that I think may come from a presentation at a Hadoop event by the same contextweb fellows

	<hr>		<hr>
Line 16:		Line 17:
	<hr>		<hr>

-	http://issues.apache.org/jira/browse/MAPREDUCE-737 The most recent major discussion thread about HA in JT.	+	http://issues.apache.org/jira/browse/HADOOP-3245 This issue is pretty important to us. It was the patch that changed the JT to persist its state so that it could be restarted and all jobs would not be lost when it crashed.

	<hr>		<hr>

-	http://issues.apache.org/jira/browse/MAPREDUCE-225 An older ticket, the original main discussion around how to approach HA for the Hadoop JT.	+	http://issues.apache.org/jira/browse/MAPREDUCE-737 The most recent major discussion thread about high availability in the JobTracker.
		+
		+	<hr>
		+
		+	http://issues.apache.org/jira/browse/MAPREDUCE-225 A slightly older independent thread about how to approach HA for the Hadoop JT.
		+
		+	* Created by a masters student from University of Bologna.
		+	* He used Jgroups to distribute Hadoop master
		+	* Last activity in June 09

	<hr>		<hr>
Line 28:		Line 37:
	<hr>		<hr>

-	http://issues.apache.org/jira/browse/HADOOP-3245 This issue is pretty important to us. It was the patch that changed the JT to persist its state so that it could be restarted and all jobs would not be lost when it crashed.	+	<b>Bookkeeper</b>
		+
		+	Unfortunately, Bookkeeper is still poorly documented.
		+
		+	* https://issues.apache.org/jira/browse/ZOOKEEPER-276 - the short apache JIRA with the discussion surrounding the commit of the bookkeeper patch to zookeeper. According to one of the contributors of bookkeeper in this thread: "We are still to document it in detail."
		+	* http://hadoop.apache.org/zookeeper/docs/current/bookkeeperStarted.html - what little documentation does exist for bookkeeper is here.

	<hr>		<hr>
Line 40:		Line 54:
	This query was referred to our local HA expert, Paul Murray, former developer of HP ServiceGuard and author of the Anubis HA tuple space. His response was that the internal state of the HA system is not something you normally want to expose to the callers, who normally care only whether the combined HA service is available or not, and not the details of how it is actually delivering the functionality. Furthermore, the state machines of individual HA nodes are very complex, as they depend upon the perceived state of the peer systems -and that it is easier to model using variables in the classes.		This query was referred to our local HA expert, Paul Murray, former developer of HP ServiceGuard and author of the Anubis HA tuple space. His response was that the internal state of the HA system is not something you normally want to expose to the callers, who normally care only whether the combined HA service is available or not, and not the details of how it is actually delivering the functionality. Furthermore, the state machines of individual HA nodes are very complex, as they depend upon the perceived state of the peer systems -and that it is easier to model using variables in the classes.
	The issue about whether to expose/hide the state of the service clearly depends upon who is looking at the service -there's a clear need exposed in the WS management protocols to expose all the inn		The issue about whether to expose/hide the state of the service clearly depends upon who is looking at the service -there's a clear need exposed in the WS management protocols to expose all the inn
-
-	<hr>
-
-	http://www.mail-archive.com/common-user@hadoop.apache.org/msg00565.html
-	- A short email thread which links to two discussion threads about HA in Hadoop JT

Special:Log/restrict

2009-11-18T08:11:36Z

restricted [[RELATED WORK of Hadoop High Availability through Metadata Replication]]

RELATED WORK of Hadoop High Availability through Metadata Replication

2009-11-18T08:11:31Z

New page

Here is the related work section from paper <i>Hadoop High Availability through Metadata Replication</i>.

5. RELATED WORKS

High availability is an emerging topic in Hadoop community [2].To our best known, there is no solution to improve the availability of Hadoop effectively.

Hadoop provides a secondary namenode [1, 4], which unfortunately does not act as a hot backup daemon for namenode. Instead, it is mainly used for periodically merging the metadata contained in namenode to prevent the data size from becoming too large.

A subproject of Hadoop, named Zookeeper [7], supports replication among a set of servers and provides a coordination mechanism for leader election among the servers, but it focuses on providing a coordination service for distributed applications instead of a high availability solution.

ContextWeb experiments a high availability solution of Cloudera Hadoop [8]. The solution primarily makes use of DRBD from LINBIT and Heartbeat from Linux-HA project, but it is not optimized for availability and performance of Hadoop, e.g. several unnecessary data have to be replicated.

Replication plays an important role in our Hadoop high availability solution. Although quite a few replication mechanisms are available in mission-critical applications especially the database applications, these mechanisms are not suitable for Hadoop high availability.

E. Sorensen adds hot standby replication functionality to the Apache Derby [9], but it does not support multi-threading to deliver replication messages. So, the solution cannot be used for parallel processing of large scale data in Hadoop.

Berkeley DB [10] has a well-defined replication mechanism, but it targets at the database management system only. Users have to spend a lot of time redesigning the replication framework if they would like to use Berkeley DB replication for applications otherthan database.

MySQL [11] presents several replication solutions used in many different environments for a range of purposes, but it cannot reconfigure replication process dynamically. Moreover, MySQLhas no official solution for failover.

IBM DB2 HADR (High Availability Disaster Recover) [12] is capable of adjusting configuration of replication process for better performance at runtime. The runtime configuration depends on asimulator to estimate the performance of replication happened before. It is not an effective approach to tune replication process according to the actual execution scenario.

Distributed Hadoop Master

2009-11-18T08:10:53Z

New page

http://www.cloudera.com/blog/2009/07/22/hadoop-ha-configuration/

http://www.slideshare.net/cloudera/hw09-production-deep-dive-with-high-availability

<hr>

Paper at Cloud Data Management (CloudDB2009) Nov 2, 2009: Hadoop High Availability through Metadata Replication
Researchers at IBM China: Feng Wang, Jie Qiu, Jie Yang, Bo Dong, Xinhui Li, Ying Li

No online version currently, but if you google for "Hadoop High Availability through Metadata Replication" you can see it used to be available, and google still has a cached html version of the paper that you can view.

the reference is: paper #5 at http://www.clouddb.org/CloudDB09/program.html#papers

I copied and pasted the related works section here: [[RELATED WORK of Hadoop High Availability through Metadata Replication]]

<hr>

http://issues.apache.org/jira/browse/MAPREDUCE-737 The most recent major discussion thread about HA in JT.

<hr>

http://issues.apache.org/jira/browse/MAPREDUCE-225 An older ticket, the original main discussion around how to approach HA for the Hadoop JT.

<hr>

http://issues.apache.org/jira/browse/MAPREDUCE-65 This issue is about what happens if you change the IP address of the JT (basically, TTs can't get back in touch with the new JT).

<hr>

http://issues.apache.org/jira/browse/HADOOP-3245 This issue is pretty important to us. It was the patch that changed the JT to persist its state so that it could be restarted and all jobs would not be lost when it crashed.

<hr>

http://issues.apache.org/jira/secure/attachment/12419194/hadoop-lifecycle.pdf

Steve Loughran had some interesting comments about Highly Available (HA) hadoop in this design doc.

3.1 Design Issue: Expose a full HA state model?
One issue that has been raised is "could the state model contain and expose a full High Availability service, with the various states of the backup nodes, failover and the like"
This query was referred to our local HA expert, Paul Murray, former developer of HP ServiceGuard and author of the Anubis HA tuple space. His response was that the internal state of the HA system is not something you normally want to expose to the callers, who normally care only whether the combined HA service is available or not, and not the details of how it is actually delivering the functionality. Furthermore, the state machines of individual HA nodes are very complex, as they depend upon the perceived state of the peer systems -and that it is easier to model using variables in the classes.
The issue about whether to expose/hide the state of the service clearly depends upon who is looking at the service -there's a clear need exposed in the WS management protocols to expose all the inn

<hr>

http://www.mail-archive.com/common-user@hadoop.apache.org/msg00565.html
- A short email thread which links to two discussion threads about HA in Hadoop JT

Special:Log/restrict

2009-11-18T02:58:15Z

restricted [[User:Andyk/Advisor Meetings]]

Revision as of 20:33, 22 November 2009		Current revision
Line 17:		Line 17:
	* [[Monitoring Hadoop\|Monitoring Hadoop using X-Trace]]		* [[Monitoring Hadoop\|Monitoring Hadoop using X-Trace]]
	* [[Projects/SCADS\|SCADS: Scaleable Consistency Adjustable Data Storage]]		* [[Projects/SCADS\|SCADS: Scaleable Consistency Adjustable Data Storage]]
		+	* [[Projects/SCADSDirector\|SCADS Director]]
	* [[Projects/Cloudstone\|Cloudstone: Multi-Platform, Multi-Language Measurement Tools for Web 2.0 and Cloud Computing]]		* [[Projects/Cloudstone\|Cloudstone: Multi-Platform, Multi-Language Measurement Tools for Web 2.0 and Cloud Computing]]
	* [[Projects/Director\|Director: Managing a Datacenter]]		* [[Projects/Director\|Director: Managing a Datacenter]]

Revision as of 18:18, 23 November 2009		Current revision
Line 13:		Line 13:
	== Cleaning Day Assignments ==		== Cleaning Day Assignments ==

-	===Tuesday 9.22.09, 11:00am===	+	===Thursday 12.3.09, 11:00am===

	(Fill in your name for an assignment)		(Fill in your name for an assignment)
Line 29:		Line 29:
	* Clean out [get rid of old food and wipe down] Refrigerator and Freezer:		* Clean out [get rid of old food and wipe down] Refrigerator and Freezer:
	* Swiffer Kitchen floor:		* Swiffer Kitchen floor:
-	* Vacuum conference rooms, lounge area and hallway carpets (2 people): Kristal, Rean	+	* Vacuum conference rooms, lounge area and hallway carpets (2 people):
-	* Organize and Wipe down all book shelves (2 people): Archana, Igor	+	* Organize and Wipe down all book shelves (2 people):
-	* Clean off and wipe down meeting tables, coffee tables, award cabinets, counters (2 people): Kattt	+	* Clean off and wipe down meeting tables, coffee tables, award cabinets, counters (2 people):
-	* Clean all white boards [with water]: Igor, Junda,Ari	+	* Clean all white boards [with water]:
-	* Clean and organize video game area: Junda	+	* Clean and organize video game area:
	* Clean/organize bicycle area:		* Clean/organize bicycle area:
-	* Clean up Printer areas (recycle old papers): Archana	+	* Clean up Printer areas (recycle old papers):
-	* Clean empty or out for the summer cubicles, including wiping down surfaces: Ari?	+	* Clean empty or out for the summer cubicles, including wiping down surfaces: