Author: buildbot
Date: Sun Jan 10 19:22:19 2016
New Revision: 977435
Log:
Staging update by buildbot for slider
Modified:
websites/staging/slider/trunk/content/ (props changed)
websites/staging/slider/trunk/content/docs/placement.html
Propchange: websites/staging/slider/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Sun Jan 10 19:22:19 2016
@@ -1 +1 @@
-1723951
+1723954
Modified: websites/staging/slider/trunk/content/docs/placement.html
==============================================================================
--- websites/staging/slider/trunk/content/docs/placement.html (original)
+++ websites/staging/slider/trunk/content/docs/placement.html Sun Jan 10
19:22:19 2016
@@ -214,7 +214,7 @@ the cluster. For details on the implemen
<h2 id="introduction">Introduction<a class="headerlink" href="#introduction"
title="Permanent link">¶</a></h2>
<p>A Slider Application Instance consists of the Application Master
âSlider's codeâ and
the components requested in the <code>resources.json</code> file. For each
component,
-Slider requests a new YARN Container, which is then allocated in the Hadoo
cluster
+Slider requests a new YARN Container, which is then allocated in the Hadoop
cluster
by YARN. The Slider application starts the component within the container,
and monitors its lifecycle.</p>
<p>The choice of where a container is created is something in which YARN and
@@ -236,7 +236,7 @@ there is no capacity on nodes with the l
</li>
<li>
<p><strong>Named Nodes/Racks</strong>. Slider lists the explicit hosts and
racks upon which
-a component can be allocated. If there is no capacity in these nodes locations,
+a component can be allocated. If there is no capacity in these locations,
the request will be unsatisfied âeven if there is space elsewhere.</p>
</li>
<li>
@@ -278,7 +278,7 @@ placement ensures that there is no confl
prevent any conflict across component types, or between Slider/YARN
applications.</p>
</li>
</ul>
-<p>Anothe need is history-based placement: re-instantiating component
instances on
+<p>Another need is history-based placement: re-instantiating component
instances on
the machine(s) on which they last ran.
This can deliver performance and startup advantages, or, for
some applications, essential to recover data persisted on the server.
@@ -307,13 +307,13 @@ which instances were created, rather tha
Servers were previously running on Node 17". On restart Slider can simply
request
one instance of a Region Server on a specific node, leaving the other instance
to be arbitrarily deployed by YARN. This strategy should help reduce the
affinity
-in the component deployment, so increase their resilience to failure.</p>
+in the component deployment, increasing their resilience to failure.</p>
</li>
<li>
<p>There is no need to make sophisticated choices on which nodes to request
re-assignment âsuch as recording the amount of data persisted by a previous
instance and prioritizing nodes based on such data. More succinctly 'the
-only priority needed when asking for nodes is <em>ask for the most recently
used</em>.</p>
+only priority needed when asking for nodes is <em>ask for the most recently
used</em>'.</p>
</li>
<li>
<p>If a component instance fails on a specific node, asking for a new
container on
@@ -324,12 +324,14 @@ that same node is a valid first attempt
<h3 id="placement-policies">Placement policies<a class="headerlink"
href="#placement-policies" title="Permanent link">¶</a></h3>
<p>The policy for placing a component can be set in the resources.json file,
via the <code>yarn.component.placement.policy</code> field.</p>
-<p>Here are the currently supported placement policies, with their</p>
-<p>Note that
-1. These are orthogonal to labels: when "anywhere" is used, it means
-"anywhere that the label expression permits".
-1. The numbers are (currently) part of a bit-mask. Other combinations may
-be chosen, in which case the outcome is "undefined".</p>
+<p>Here are the currently supported placement policies</p>
+<p>Note that</p>
+<ol>
+<li>These are orthogonal to labels: when "anywhere" is used, it means
+"anywhere that the label expression permits".</li>
+<li>The numbers are (currently) part of a bit-mask. Other combinations may
+be chosen, in which case the outcome is "undefined".</li>
+</ol>
<h4 id="normal-0">"Normal" (0)<a class="headerlink" href="#normal-0"
title="Permanent link">¶</a></h4>
<p>Slider remembers the hosts on which containers were requested, and makes
relaxed-placement requests for new instances on those hosts on
@@ -351,7 +353,7 @@ request will ever take place. If a host
failed, then the request will never be satisifed: it will remain
outstanding.</p>
<p>New instances (i.e. ones for which there is no historical placement)
will be requested anywhere.</p>
-<p>Note: As of Jan 2016 tThere is no anti-affinity placement when expanding
+<p>Note: As of Jan 2016, there is no anti-affinity placement when expanding
strict placements <a
href="https://issues.apache.org/jira/browse/SLIDER-980";>SLIDER-980</a>.
It's possible to work around this by requesting the initial set of instances
using anti-affinity, then editing resources.json to switch to strict placements
