To enable Azure repositories, you have first to define your azure storage settings as secure settings, before starting up the node:

bin/elasticsearch-keystore add azure.client.default.account
bin/elasticsearch-keystore add azure.client.default.key

Where account is the azure account name and key the azure secret key. Instead of an azure secret key under key, you can alternatively define a shared access signatures (SAS) token under sas_token to use for authentication instead. When using an SAS token instead of an account key, the SAS token must have read (r), write (w), list (l), and delete (d) permissions for the repository base path and all its contents. These permissions need to be granted for the blob service (b) and apply to resource types service (s), container (c), and object (o). These settings are used by the repository’s internal azure client.

Note that you can also define more than one account:

bin/elasticsearch-keystore add azure.client.default.account
bin/elasticsearch-keystore add azure.client.default.key
bin/elasticsearch-keystore add azure.client.secondary.account
bin/elasticsearch-keystore add azure.client.secondary.sas_token

default is the default account name which will be used by a repository, unless you set an explicit one in the repository settings.

The account, key, and sas_token storage settings are reloadable. After you reload the settings, the internal azure clients, which are used to transfer the snapshot, will utilize the latest settings from the keystore.

In progress snapshot/restore jobs will not be preempted by a reload of the storage secure settings. They will complete using the client as it was built when the operation started.

You can set the client side timeout to use when making any single request. It can be defined globally, per account or both. It’s not set by default which means that Elasticsearch is using the default value set by the azure client (known as 5 minutes).

max_retries can help to control the exponential backoff policy. It will fix the number of retries in case of failures before considering the snapshot is failing. Defaults to 3 retries. The initial backoff period is defined by Azure SDK as 30s. Which means 30s of wait time before retrying after a first timeout or failure. The maximum backoff period is defined by Azure SDK as 90s.

endpoint_suffix can be used to specify Azure endpoint suffix explicitly. Defaults to core.windows.net.

azure.client.default.timeout: 10s
azure.client.default.max_retries: 7
azure.client.default.endpoint_suffix: core.chinacloudapi.cn
azure.client.secondary.timeout: 30s

In this example, timeout will be 10s per try for default with 7 retries before failing and endpoint suffix will be core.chinacloudapi.cn and 30s per try for secondary with 3 retries.

Supported Azure Storage Account types

The Azure Repository plugin works with all Standard storage accounts

• Standard Locally Redundant Storage - Standard_LRS
• Standard Zone-Redundant Storage - Standard_ZRS
• Standard Geo-Redundant Storage - Standard_GRS
• Standard Read Access Geo-Redundant Storage - Standard_RAGRS

Premium Locally Redundant Storage (Premium_LRS) is not supported as it is only usable as VM disk storage, not as general storage.

You can register a proxy per client using the following settings:

azure.client.default.proxy.host: proxy.host
azure.client.default.proxy.port: 8888
azure.client.default.proxy.type: http

Supported values for proxy.type are direct (default), http or socks. When proxy.type is set to http or socks, proxy.host and proxy.port must be provided.