Added diagrams for 410_Scaling

410_Scaling/15_Shard.asciidoc

@@ -36,6 +36,10 @@ _replica_ shards later on in <<replica-shards>>.
 One glorious day, the Internet discovers us, and a single node just can't keep up with
 the traffic.  We decide to add a second node.  What happens?
 
+[[img-one-shard]]
+.An index with one shard has no scale factor
+image::images/410_15_one_shard.png["An index with one shard has no scale factor"]
+
 The answer is: nothing.  Because we have only one shard, there is nothing to
 put on the second node. We can't increase the number of shards in the index,
 because the number of shards is an important element in the algorithm used to

410_Scaling/20_Overallocation.asciidoc

@@ -21,6 +21,10 @@ point of view of our application, everything functions as it did before.  The
 application communicates with the index, not the shards, and there is still
 only one index.
 
+[[img-two-shard]]
+.An index with two shards can take advantage of a second node
+image::images/410_20_two_shards.png["An index with two shards can take advantage of a second node"]
+
 This time, when we add a second node, Elasticsearch will automatically move
 one shard from the first node to the second node and, once the relocation has
 finished, each shard will have access to twice the computing power that it had

410_Scaling/35_Replica_shards.asciidoc

@@ -31,6 +31,10 @@ POST /my_index/_settings
 Having two primary shards, plus a replica of each primary, would give us a
 total of four shards: one for each node.
 
+[[img-four-nodes]]
+.An index with two primary shards and one replica can scale out across four nodes
+image::images/410_35_four_nodes.png["An index with two primary shards and one replica can scale out across four nodes"]
+
 ==== Balancing load with replicas
 
 Search performance depends on the response times of the slowest node, so it is a good idea to try to balance out the load across all nodes. If we had
@@ -51,6 +55,10 @@ POST /my_index/_settings
 As a bonus, we have also increased our availability.  We can now afford to
 lose two nodes and still have a copy of all of our data.
 
+[[img-three-nodes]]
+.Adjust the number of replicas to balance the load between nodes
+image::images/410_35_three_nodes.png["Adjust the number of replicas to balance the load between nodes"]
+
 NOTE: The fact that node 3 holds two replicas and no primaries is not
 important.  Replicas and primaries do the same amount of work, they just play
 slightly different roles.  There is no need to ensure that primaries are