allocation_awareness.asciidoc 4.4 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101
  1. [[shard-allocation-awareness]]
  2. ==== Shard allocation awareness
  3. You can use custom node attributes as _awareness attributes_ to enable {es}
  4. to take your physical hardware configuration into account when allocating shards.
  5. If {es} knows which nodes are on the same physical server, in the same rack, or
  6. in the same zone, it can distribute the primary shard and its replica shards to
  7. minimise the risk of losing all shard copies in the event of a failure.
  8. When shard allocation awareness is enabled with the
  9. <<dynamic-cluster-setting,dynamic>>
  10. `cluster.routing.allocation.awareness.attributes` setting, shards are only
  11. allocated to nodes that have values set for the specified awareness attributes.
  12. If you use multiple awareness attributes, {es} considers each attribute
  13. separately when allocating shards.
  14. NOTE: The number of attribute values determines how many shard copies are
  15. allocated in each location. If the number of nodes in each location is
  16. unbalanced and there are a lot of replicas, replica shards might be left
  17. unassigned.
  18. [[enabling-awareness]]
  19. ===== Enabling shard allocation awareness
  20. To enable shard allocation awareness:
  21. . Specify the location of each node with a custom node attribute. For example,
  22. if you want Elasticsearch to distribute shards across different racks, you might
  23. set an awareness attribute called `rack_id` in each node's `elasticsearch.yml`
  24. config file.
  25. +
  26. [source,yaml]
  27. --------------------------------------------------------
  28. node.attr.rack_id: rack_one
  29. --------------------------------------------------------
  30. +
  31. You can also set custom attributes when you start a node:
  32. +
  33. [source,sh]
  34. --------------------------------------------------------
  35. ./bin/elasticsearch -Enode.attr.rack_id=rack_one
  36. --------------------------------------------------------
  37. . Tell {es} to take one or more awareness attributes into account when
  38. allocating shards by setting
  39. `cluster.routing.allocation.awareness.attributes` in *every* master-eligible
  40. node's `elasticsearch.yml` config file.
  41. +
  42. --
  43. [source,yaml]
  44. --------------------------------------------------------
  45. cluster.routing.allocation.awareness.attributes: rack_id <1>
  46. --------------------------------------------------------
  47. <1> Specify multiple attributes as a comma-separated list.
  48. --
  49. +
  50. You can also use the
  51. <<cluster-update-settings,cluster-update-settings>> API to set or update
  52. a cluster's awareness attributes.
  53. With this example configuration, if you start two nodes with
  54. `node.attr.rack_id` set to `rack_one` and create an index with 5 primary
  55. shards and 1 replica of each primary, all primaries and replicas are
  56. allocated across the two nodes.
  57. If you add two nodes with `node.attr.rack_id` set to `rack_two`,
  58. {es} moves shards to the new nodes, ensuring (if possible)
  59. that no two copies of the same shard are in the same rack.
  60. If `rack_two` fails and takes down both its nodes, by default {es}
  61. allocates the lost shard copies to nodes in `rack_one`. To prevent multiple
  62. copies of a particular shard from being allocated in the same location, you can
  63. enable forced awareness.
  64. [[forced-awareness]]
  65. ===== Forced awareness
  66. By default, if one location fails, Elasticsearch assigns all of the missing
  67. replica shards to the remaining locations. While you might have sufficient
  68. resources across all locations to host your primary and replica shards, a single
  69. location might be unable to host *ALL* of the shards.
  70. To prevent a single location from being overloaded in the event of a failure,
  71. you can set `cluster.routing.allocation.awareness.force` so no replicas are
  72. allocated until nodes are available in another location.
  73. For example, if you have an awareness attribute called `zone` and configure nodes
  74. in `zone1` and `zone2`, you can use forced awareness to prevent Elasticsearch
  75. from allocating replicas if only one zone is available:
  76. [source,yaml]
  77. -------------------------------------------------------------------
  78. cluster.routing.allocation.awareness.attributes: zone
  79. cluster.routing.allocation.awareness.force.zone.values: zone1,zone2 <1>
  80. -------------------------------------------------------------------
  81. <1> Specify all possible values for the awareness attribute.
  82. With this example configuration, if you start two nodes with `node.attr.zone` set
  83. to `zone1` and create an index with 5 shards and 1 replica, Elasticsearch creates
  84. the index and allocates the 5 primary shards but no replicas. Replicas are
  85. only allocated once nodes with `node.attr.zone` set to `zone2` are available.