ran markdown linter to fix format issues
Signed-off-by: alicejw <alicejw@amazon.com>
This commit is contained in:
alicejw
parent
5b913181dc
commit
9d5219f82a
|
|
@ -34,14 +34,12 @@ After you assess all these requirements, we recommend you use a benchmark testin
|
|||
|
||||
This page demonstrates how to work with the different node types. It assumes that you have a four-node cluster similar to the preceding illustration.
|
||||
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Before you get started, you must install and configure OpenSearch on all of your nodes. For information about the available options, see [Install and configure OpenSearch]({{site.url}}{{site.baseurl}}/opensearch/install/).
|
||||
|
||||
After you're done, use SSH to connect to each node, then open the `config/opensearch.yml` file. You can set all configurations for your cluster in this file.
|
||||
|
||||
|
||||
## Step 1: Name a cluster
|
||||
|
||||
Specify a unique name for the cluster. If you don't specify a cluster name, it's set to `opensearch` by default. Setting a descriptive cluster name is important, especially if you want to run multiple clusters inside a single network.
|
||||
|
|
@ -60,12 +58,10 @@ cluster.name: opensearch-cluster
|
|||
|
||||
Make the same change on all the nodes to make sure that they'll join to form a cluster.
|
||||
|
||||
|
||||
## Step 2: Set node attributes for each node in a cluster
|
||||
|
||||
After you name the cluster, set node attributes for each node in your cluster.
|
||||
|
||||
|
||||
#### Master node
|
||||
|
||||
Give your master node a name. If you don't specify a name, OpenSearch assigns a machine-generated name that makes the node difficult to monitor and troubleshoot.
|
||||
|
|
@ -80,7 +76,6 @@ You can also explicitly specify that this node is a master node. This is already
|
|||
node.roles: [ master ]
|
||||
```
|
||||
|
||||
|
||||
#### Data nodes
|
||||
|
||||
Change the name of two nodes to `opensearch-d1` and `opensearch-d2`, respectively:
|
||||
|
|
@ -88,6 +83,7 @@ Change the name of two nodes to `opensearch-d1` and `opensearch-d2`, respectivel
|
|||
```yml
|
||||
node.name: opensearch-d1
|
||||
```
|
||||
|
||||
```yml
|
||||
node.name: opensearch-d2
|
||||
```
|
||||
|
|
@ -100,7 +96,6 @@ node.roles: [ data, ingest ]
|
|||
|
||||
You can also specify any other attributes that you'd like to set for the data nodes.
|
||||
|
||||
|
||||
#### Coordinating node
|
||||
|
||||
Change the name of the coordinating node to `opensearch-c1`:
|
||||
|
|
@ -115,7 +110,6 @@ Every node is a coordinating node by default, so to make this node a dedicated c
|
|||
node.roles: []
|
||||
```
|
||||
|
||||
|
||||
## Step 3: Bind a cluster to specific IP addresses
|
||||
|
||||
`network_host` defines the IP address used to bind the node. By default, OpenSearch listens on a local host, which limits the cluster to a single node. You can also use `_local_` and `_site_` to bind to any loopback or site-local address, whether IPv4 or IPv6:
|
||||
|
|
@ -132,7 +126,6 @@ network.host: <IP address of the node>
|
|||
|
||||
Make sure to configure these settings on all of your nodes.
|
||||
|
||||
|
||||
## Step 4: Configure discovery hosts for a cluster
|
||||
|
||||
Now that you've configured the network hosts, you need to configure the discovery hosts.
|
||||
|
|
@ -147,7 +140,6 @@ For example, for `opensearch-master` the line looks something like this:
|
|||
discovery.seed_hosts: ["<private IP of opensearch-d1>", "<private IP of opensearch-d2>", "<private IP of opensearch-c1>"]
|
||||
```
|
||||
|
||||
|
||||
## Step 5: Start the cluster
|
||||
|
||||
After you set the configurations, start OpenSearch on all nodes:
|
||||
|
|
@ -178,7 +170,6 @@ x.x.x.x 23 38 0 0.12 0.07 0.06 md - o
|
|||
|
||||
To better understand and monitor your cluster, use the [cat API]({{site.url}}{{site.baseurl}}/opensearch/catapis/).
|
||||
|
||||
|
||||
## (Advanced) Step 6: Configure shard allocation awareness or forced awareness
|
||||
|
||||
If your nodes are spread across several geographical zones, you can configure shard allocation awareness to allocate all replica shards to a zone that’s different from their primary shard.
|
||||
|
|
@ -190,6 +181,7 @@ To configure shard allocation awareness, add zone attributes to `opensearch-d1`
|
|||
```yml
|
||||
node.attr.zone: zoneA
|
||||
```
|
||||
|
||||
```yml
|
||||
node.attr.zone: zoneB
|
||||
```
|
||||
|
|
@ -230,7 +222,6 @@ If that is not the case, and `opensearch-d1` and `opensearch-d2` do not have the
|
|||
|
||||
Choosing allocation awareness or forced awareness depends on how much space you might need in each zone to balance your primary and replica shards.
|
||||
|
||||
|
||||
## (Advanced) Step 7: Set up a hot-warm architecture
|
||||
|
||||
You can design a hot-warm architecture where you first index your data to hot nodes---fast and expensive---and after a certain period of time move them to warm nodes---slow and cheap.
|
||||
|
|
@ -244,6 +235,7 @@ To configure a hot-warm storage architecture, add `temp` attributes to `opensear
|
|||
```yml
|
||||
node.attr.temp: hot
|
||||
```
|
||||
|
||||
```yml
|
||||
node.attr.temp: warm
|
||||
```
|
||||
|
|
@ -314,7 +306,6 @@ A popular approach is to configure your [index templates]({{site.url}}{{site.bas
|
|||
|
||||
You can then use the [Index State Management (ISM)]({{site.url}}{{site.baseurl}}/im-plugin/) plugin to periodically check the age of an index and specify actions to take on it. For example, when the index reaches a specific age, change the `index.routing.allocation.require.temp` setting to `warm` to automatically move your data from hot nodes to warm nodes.
|
||||
|
||||
|
||||
## Next steps
|
||||
|
||||
If you are using the security plugin, the previous request to `_cat/nodes?v` might have failed with an initialization error. For full guidance around using the security plugin, see [Security configuration]({{site.url}}{{site.baseurl}}/security-plugin/configuration/index/).
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: default
|
||||
title: Mapping
|
||||
nav_order: 14
|
||||
nav_order: 13
|
||||
---
|
||||
|
||||
# About Mappings
|
||||
|
|
@ -68,9 +68,9 @@ If you know exactly what your field data types need to be, you can specify them
|
|||
---
|
||||
## Mapping example usage
|
||||
|
||||
The following example shows how to add the ip_range field and specify `ignore_malformed` parameter to prevent ip addresses that do not conform to your `ip_range` data type.
|
||||
The following example shows how to create a mapping to specify that OpenSearch should ignore any documents with malformed ip addresses that do not conform to the `ip_range` data type. You accomplish this by setting the `ignore_malformed` parameter to `true`.
|
||||
|
||||
### Create an index with ip_range mapping
|
||||
### Create an index with an ip_range mapping
|
||||
|
||||
To create an index, use a PUT request:
|
||||
|
||||
|
|
@ -79,17 +79,17 @@ PUT _index_ip
|
|||
{
|
||||
"mappings": {
|
||||
"dynamic_templates": [
|
||||
{
|
||||
{
|
||||
"ip_range": {
|
||||
"match": "*ip_range",
|
||||
"mapping": {
|
||||
"type": "ip_range",
|
||||
"ignore_malformed": true
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Loading…
Reference in New Issue