NOTE: You are looking at documentation for an older release. For the latest information, see the current release documentation.
Azure Repository
editAzure Repository
editTo 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.
cloud.azure.storage.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.