Azureリポジトリ

Azure Blobストレージをスナップショット/復元のリポジトリとして使用できます。

セットアップ

Azureリポジトリを有効にするには、最初にAzureストレージ設定をセキュア設定として定義する必要があります。

ノードが起動する前にこれらの設定を定義するか、設定が定義された後にノードのセキュア設定再読み込みAPIを呼び出して、実行中のノードに適用できます。 

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

複数のアカウントを定義することもできることに注意してください: 

  1. bin/elasticsearch-keystore add azure.client.default.account
  2. bin/elasticsearch-keystore add azure.client.default.key
  3. bin/elasticsearch-keystore add azure.client.secondary.account
  4. bin/elasticsearch-keystore add azure.client.secondary.sas_token

これらの設定に関する詳細については、クライアント設定を参照してください。

サポートされているAzureストレージアカウントタイプ

Azureリポジトリタイプはすべての標準ストレージアカウントで動作します

  • 標準ローカル冗長ストレージ - Standard_LRS
  • 標準ゾーン冗長ストレージ - Standard_ZRS
  • 標準地理冗長ストレージ - Standard_GRS
  • 標準読み取りアクセス地理冗長ストレージ - Standard_RAGRS

プレミアムローカル冗長ストレージ (Premium_LRS)は、VMディスクストレージとしてのみ使用可能であり、一般的なストレージとしてはサポートされていません。

クライアント設定

Azureに接続するために使用するクライアントには、いくつかの設定が用意されています。設定はazure.client.CLIENT_NAME.SETTING_NAMEの形式を持ちます。デフォルトでは、azureリポジトリはdefaultという名前のクライアントを使用しますが、これはリポジトリ設定clientを使用して変更できます。例えば:

Python

  1. resp = client.snapshot.create_repository(
  2.    name="my_backup",
  3.    repository={
  4.    "type": "azure",
  5.    "settings": {
  6.    "client": "secondary"
  7.    }
  8.    },
  9. )
  10. print(resp)

Js

  1. const response = await client.snapshot.createRepository({
  2.   name: "my_backup",
  3.   repository: {
  4.    type: "azure",
  5.    settings: {
  6.    client: "secondary",
  7.    },
  8.   },
  9. });
  10. console.log(response);

コンソール

  1. PUT _snapshot/my_backup
  2. {
  3.   "type": "azure",
  4.   "settings": {
  5.    "client": "secondary"
  6.   }
  7. }

ほとんどのクライアント設定はelasticsearch.yml構成ファイルに追加できます。例えば:

Yaml

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

この例では、クライアント側のタイムアウトは10sごとにdefaultアカウントに対して7回のリトライで失敗します。エンドポイントサフィックスはcore.chinacloudapi.cnで、30sごとにsecondaryアカウントに対して3回のリトライがあります。 

  2. 進行中のスナップショットまたは復元ジョブは、ストレージセキュア設定の**再読み込み**によって中断されることはありません。操作が開始されたときに構築されたクライアントを使用して完了します。  
  4. 以下のリストには、利用可能なクライアント設定が含まれています。キーストアに保存する必要があるものは「セキュア」とマークされており、他の設定は`````elasticsearch.yml`````ファイルに属します。  
  6. -   `````account````` ([セキュア](https://www.elastic.co/guide/en/elasticsearch/reference/8.15/secure-settings.html)、[再読み込み可能](https://www.elastic.co/guide/en/elasticsearch/reference/8.15/secure-settings.html#reloadable-secure-settings))   
  7. -  リポジトリの内部Azureクライアントによって使用されるAzureアカウント名。  
  8. -   `````endpoint_suffix
  • 接続するためのAzureエンドポイントサフィックス。デフォルト値はcore.windows.netです。
  • key (セキュア、再読み込み可能)
  • リポジトリの内部Azureクライアントによって使用されるAzure秘密鍵。代わりにsas_tokenを使用します。
  • max_retries
  • Azureリクエストが失敗したときに使用するリトライの数。この設定は指数バックオフポリシーを制御するのに役立ちます。スナップショットが失敗する前に発生する必要があるリトライの数を指定します。デフォルト値は3です。初期バックオフ期間はAzure SDKによって30sとして定義されています。したがって、最初のタイムアウトまたは失敗の後に再試行する前に30sの待機時間があります。最大バックオフ期間はAzure SDKによって90sとして定義されています。
  • proxy.host
  • Azureを介して接続するためのプロキシのホスト名。例えば: azure.client.default.proxy.host: proxy.host。
  • proxy.port
  • Azureを介して接続するためのプロキシのポート。例えば、azure.client.default.proxy.port: 8888。
  • proxy.type
  • クライアントのためのプロキシタイプを登録します。サポートされている値はdirect、http、およびsocksです。例えば: azure.client.default.proxy.type: http。proxy.typeがhttpまたはsocksに設定されている場合、proxy.hostとproxy.portも提供する必要があります。デフォルト値はdirectです。
  • sas_token (セキュア、再読み込み可能)
  • リポジトリの内部Azureクライアントが認証に使用する共有アクセス署名（SAS）トークン。SASトークンは、リポジトリのベースパスおよびそのすべてのコンテンツに対して読み取り（r）、書き込み（w）、リスト（l）、および削除（d）権限を持っている必要があります。これらの権限は、Blobサービス（b）に対して付与され、リソースタイプサービス（s）、コンテナ（c）、およびオブジェクト（o）に適用されます。代わりにkeyを使用します。
  • timeout
  • Azureへの単一リクエストのクライアント側タイムアウト。値は時間単位を指定する必要があります。例えば、5sの値は5秒のタイムアウトを指定します。デフォルト値はなく、ElasticsearchはAzureクライアントによって設定されたデフォルト値（5分として知られています）を使用します。この設定は、グローバルに、アカウントごとに、またはその両方で定義できます。
  • endpoint
  • 接続するためのAzureエンドポイント。Azureに接続するために使用されるプロトコルを含める必要があります。
  • secondary_endpoint
  • 接続するためのAzureセカンダリエンドポイント。Azureに接続するために使用されるプロトコルを含める必要があります。

リポジトリ設定

Azureリポジトリは次の設定をサポートしています:

  • client
  • 使用するAzure名付きクライアント。デフォルトはdefaultです。
  • container
  • コンテナ名。リポジトリを作成する前にAzureコンテナを作成する必要があります。デフォルトはelasticsearch-snapshotsです。
  • base_path
  • リポジトリデータ内のコンテナ内のパスを指定します。デフォルトは空（ルートディレクトリ）です。
    Elastic Cloud Enterpriseのスナップショットリポジトリを構成する際にbase_pathを設定しないでください。Elastic Cloud Enterpriseは、複数のデプロイメントが同じバケットを共有できるように、各デプロイメントのためにbase_pathを自動的に生成します。
  • chunk_size
  • 大きなファイルは、スナップショット作成中にBlobストア内の複数の小さなBlobに分割できます。この値をデフォルトから変更することは推奨されません。リポジトリ内のBlobのサイズを制限する明確な理由がない限り、デフォルトよりも小さい値を設定すると、スナップショット作成や復元操作中にAzure BlobストアへのAPI呼び出しの数が増加し、両方の操作が遅くなり、コストがかかる可能性があります。チャンクサイズを値と単位として指定します。例えば: 10MB、5KB、500B。デフォルトはAzure Blobストア内のBlobの最大サイズで、5TBです。
  • compress
  • trueに設定されている場合、メタデータファイルは圧縮形式で保存されます。この設定は、デフォルトで圧縮されているインデックスファイルには影響しません。デフォルトはtrueです。
  • max_restore_bytes_per_sec
  • （オプション、バイト値）ノードごとの最大スナップショット復元率。デフォルトは無制限です。復元はリカバリ設定を通じても制限されることに注意してください。
  • max_snapshot_bytes_per_sec

  • （オプション、バイト値）ノードごとの最大スナップショット作成率。デフォルトは40mb毎秒です。管理サービスのリカバリ設定が設定されている場合、デフォルトは無制限になり、レートはリカバリ設定を通じてさらに制限されます。

  • readonly

  • （オプション、ブール値）trueの場合、リポジトリは読み取り専用です。クラスターはリポジトリからスナップショットを取得および復元できますが、リポジトリに書き込んだり、スナップショットを作成したりすることはできません。
    書き込みアクセス権を持つクラスターのみがリポジトリにスナップショットを作成できます。リポジトリに接続されている他のすべてのクラスターは、readonlyパラメータをtrueに設定する必要があります。
    falseの場合、クラスターはリポジトリに書き込み、スナップショットを作成できます。デフォルトはfalseです。
    同じスナップショットリポジトリを複数のクラスターで登録する場合、1つのクラスターのみがリポジトリに書き込みアクセス権を持つべきです。複数のクラスターが同時にリポジトリに書き込むと、リポジトリの内容が破損するリスクがあります。
  • location_mode
  • primary_onlyまたはsecondary_only。デフォルトはprimary_onlyです。secondary_onlyに設定した場合、readonlyをtrueに強制します。

スクリプトを使用したいくつかの例:

コンソール

  3. # 最もシンプルなもの
  5. PUT _snapshot/my_backup1
  6. {
  7.   "type": "azure"
  8. }
  11. # いくつかの設定を使用して
  13. PUT _snapshot/my_backup2
  14. {
  15.   "type": "azure",
  16.   "settings": {
  17.    "container": "backup-container",
  18.    "base_path": "backups",
  19.    "chunk_size": "32MB",
  20.    "compress": true
  21.   }
  22. }
  25. # elasticsearch.ymlに定義された2つのアカウント（my_account1とmy_account2）を使用して
  27. PUT _snapshot/my_backup3
  28. {
  29.   "type": "azure",
  30.   "settings": {
  31.    "client": "secondary"
  32.   }
  33. }
  34. PUT _snapshot/my_backup4
  35. {
  36.   "type": "azure",
  37.   "settings": {
  38.    "client": "secondary",
  39.    "location_mode": "primary_only"
  40.   }
  41. }

Javaを使用した例:

Java

  1. client.admin().cluster().preparePutRepository("my_backup_java1")
  2.    .setType("azure").setSettings(Settings.builder()
  3.    .put(Storage.CONTAINER, "backup-container")
  4.    .put(Storage.CHUNK_SIZE, new ByteSizeValue(32, ByteSizeUnit.MB))
  5.    ).get();

リポジトリ検証ルール

コンテナ名ガイドによると、コンテナ名は有効なDNS名でなければならず、次の命名ルールに従う必要があります:

  • コンテナ名は文字または数字で始まり、文字、数字、およびダッシュ（-）文字のみを含むことができます。
  • 各ダッシュ（-）文字は、文字または数字の直前および直後に存在しなければならず、連続するダッシュはコンテナ名に許可されていません。
  • コンテナ名のすべての文字は小文字でなければなりません。
  • コンテナ名は3文字から63文字の長さでなければなりません。

線形レジスタの実装

Azureリポジトリの線形レジスタ実装は、Azureの強い一貫性のあるリースのサポートに基づいています。各リースは、同時に単一のノードによってのみ保持されることができます。ノードは、保護されたBlobに対して読み取りまたは書き込み操作を行う際にリースを提示します。リースが無効または期限切れの場合、リース保護された操作は失敗します。レジスタに対して比較交換操作を実行するために、Elasticsearchは最初にBlobのリースを取得し、次にリースの下でBlobの内容を読み取り、最後に同じリースの下で更新されたBlobをアップロードします。このプロセスは、読み取りおよび書き込み操作が原子的に行われることを保証します。