Azure 仮想マシンに Elastic をデプロイする

Azure 仮想マシン (VM) には、Azure ユーザーがクラウド インフラストラクチャに新規および既存の Elastic ワークロードを柔軟にデプロイできる方法が用意されています。 この展開オプションは、アーキテクチャやコンプライアンスの制約を満たすためにインフラストラクチャを最大限に制御する必要があるチーム (ワークロードをAzure テナント内にデプロイする必要があるチームなど) に最適です。

あなたが勤めるスタートアップ小売企業は、現在 Elastic on-premises を使用して販売トランザクションを管理していることを思い出しましょう。 リモート ワーカーやその他の部門のデータ アクセシビリティを向上させ、インフラストラクチャを維持する負担を軽減するために、Azure VM に移行したいと思っています。

ここでは、Azure VM に Elastic ワークロードをデプロイする手順について学習します。 このユニットで参照されているガイダンスへのリンクは、概要の 詳細情報 セクションにあります。

デプロイ責任モデルを選択する

自分が制御するインフラストラクチャ上の独自のAzure サブスクリプションにデプロイするには、Azure Linux VM を作成し、サポートされている Elastic パッケージを使用して Elasticsearch、Kibana、および必要なインジェスト コンポーネントをインストールします。 ゲスト OS とアプリケーションの更新、ネットワーク、証明書、アクセス制御、容量、バックアップ、回復を管理します。 Azureは、基盤となる物理インフラストラクチャを管理します。

Elastic Support Matrix とバージョン ポリシーを使用して、サポートされている OS と保守されている Elastic リリースを選択してください。 新規インストールの場合は、インストール互換性ガイダンスに従って、一致する Elastic Stack バージョンを使用します。 UI の既定値は、リリース サポート ポリシーではありません。

エラスティック運用インフラストラクチャの場合は、Elastic Cloud (Elasticsearch) - Azure Native ISV Service を検討してください。 Cloud Hosted は、Azure 統合および課金を備えたマネージド Elasticsearch と Kibana を提供します。

Azure Native のホスティング境界と Logstash から Elastic Cloud への接続に関するガイダンスを参照してください。

マネージド サービスの代替手段を比較する

次の概要は省略可能です。 VM 演習を完了するためにマネージド サービスを購入する必要はありません。 マネージドサービスの代替案を比較するには、次の手順に従います。

1. サブスクリプション レベルの所有者/共同作成者アクセスや Marketplace の購入資格など、現在のマネージド サービスの前提条件を確認します。 テナントの同意要件に対処する。展開作成者は、必ずしもテナント管理者である必要はありません。 Azure試用版クレジットがこの購入に適用されると思わないでください。
2. 「Elastic アプリケーションを作成」の手順に従います。 この比較にはCloud Hostedを選択し、次にサブスクリプション/リソース グループ、サポートされているリージョン、および適切なプランを指定します。 確認して作成 と 作成 の前に、実際の価格と請求条件を確認してください。
3. 統合を使用してデプロイを開き、Elasticsearch/Kibana アクセスを確認します。 顧客側統合リソースは、テナント内の Elasticsearch VM のセットではありません。 Logstash は、個別に構成された送信元のままです。
4. プライベート アクセスが必要な場合は、プライベート エンドポイント、DNS、エラスティック側接続ポリシーなど、Elastic Azure Private Link ガイダンスに従ってください。 プライベート エンドポイントは、バッキング サービスの所有権や場所ではなく、接続を変更します。 Cloud Hosted の場合、Elastic Cloud-console SSO ではプライベート Kibana エンドポイントを介してサインインできません。そのガイドで説明されているように、サポートされているスタック認証または個別に構成された ID プロバイダーを使用してください。
5. クリーンアップの前に、Elastic 組織内のすべてのデプロイのインベントリを作成し、どの Azure サブスクリプションに請求されるかを確認します。 Azureを使用してAzure作成されたリソースを削除し、エラスティック リソースの削除ガイダンスに従います。 目的のラボデプロイのみを削除します。共有組織の課金を停止するために、関連のない展開を削除しないでください。 Elastic のリソース グループの制限に従います。他のデプロイがそのリソース グループに対して課金されている間は、最初のデプロイのリソース グループを削除しないでください。
6. Marketplace SaaS サブスクリプションとその契約条件を個別に確認してください。 これが専用ラボ SaaS サブスクリプションの場合は、該当する SaaS ライフサイクル手順を使用してキャンセルします。 1 つのリソース グループ、または最後のデプロイであっても削除しても、商用サブスクリプションが取り消されたことを意味するものではありません。

プロビジョニングとインストール

専用リソース グループに VM、永続ストレージ、およびネットワーク コントロールを作成します。 パッケージのインストール用に管理者による接続と明示的なアウトバウンドアクセスを確立します。 Ubuntu では、Elasticsearch の Debian ガイドに従い、次に Kibana の Debian ガイドに従ってください。 オプションの Logstash を個別に構成します。

Azure CLIとAzure PowerShellは、Azureリソースのプロビジョニングを自動化できます。Elasticソフトウェアのインストールと構成も実装する必要があります。 Azure VM のみをプロビジョニングしても、動作する Elasticsearch クラスターは作成されません。

この演習では、意図的に小規模な 4 VM 構成を使用します。内訳は 3 つの Elasticsearch ノードと 1 つの Kibana ホストで、各 VM はそれぞれ 2 つの vCPU、8 GiB の RAM、永続的なマネージド ストレージを備えています。 固定パッケージ バージョン、プライベート アドレス プラン、明示的な NSG 規則、および別のブラウザー証明書が提供されます。 これにより、学習手順が具体的になります。これらのサイズは、運用環境のサイズ設定に関する推奨事項にはなりません。

デプロイのサイズを適切に設定し、回復性を高めます

個別のテスト環境で Rally を使用して、代表的なワークロードを評価します。 Elasticsearch ヒープ、非ヒープ メモリ、ファイルシステム キャッシュ、ストレージ容量/IOPS、および障害対応用の余裕を考慮します。 明確に測定・検証された理由がない限り、既定の自動ヒープ サイズ設定を使用してください。

マスター適格の 3 つのデータ ノードは、妥当な小規模クラスターの開始点です。 通常のインデックスの場合は、少なくとも 1 つのレプリカが割り当てられ、クライアントが複数のノードまたは適切な負荷分散エンドポイントに到達できることを確認します。 このような 3 つのマスター対象ノードは、1 つのノードが故障しても投票の過半数を保持できます。 ノード数だけでは、アベイラビリティーゾーンの耐障害性が確立されたり、スナップショットが置き換えられたりすることはありません。 小規模クラスターの回復性とノード ロールに関するガイダンスを参照してください。

本番環境での Kibana の可用性を確保するために、適切な負荷分散と一貫性のある構成を持つ複数のインスタンスを使用します。

Logstash は省略可能です。 インジェスト設計でその入力、フィルター処理、ルーティング、またはバッファリング機能が必要な場合にデプロイします。 運用環境での可用性を確保するには、2 つのコピーをインストールするだけでなく、負荷分散またはフェールオーバー用の入力の構成、適切な永続キュー、出力認証、TLS の構成が必要です。 Logstash のデプロイとスケーリングのガイダンスに従います。 永続キューは各インスタンスに対してローカルです。インスタンスのペアをレプリケートされた共有キューとして記述しないでください。

ID 情報と暗号化接続を設定する

Elasticsearch には、定義済みの elastic スーパーユーザーが用意されています。 他の組み込みユーザーは、特定のサービスまたは監視の目的を持っています。それらの名前は選べません。 現在の Kibana 登録トークンを使用して、Elasticsearch への Kibana の接続を構成します。 アプリケーション、インジェスト、およびヒューマン アクセス用に適切なスコープの ID または API キーを作成します。 特に、 logstash_system は監視 ID であり、パイプライン出力 ID ではありません。

組み込みユーザー、自動セキュリティ設定とその例外、Kibana HTTPS、Logstash セキュリティに関するガイダンスを参照してください。

このモデルが小売業者に適しているかどうか判断する

顧客が管理するゲスト オペレーティング システムとインフラストラクチャが要件であり、チームがそれらを運用できる場合は、セルフマネージド VM を使用します。 VM を Azure に移動すると、物理ハードウェアの管理は不要になりますが、ゲスト OS、Elastic のアップグレード、スナップショット、証明書、容量に関する責任がなくなるわけではありません。 これらの運用責任を減らすことがより強い要件である場合は、代わりに Elastic Cloud を評価してください。 いずれの場合も、小売業者の既存のワークロードを移動する前に、別のデータ移行計画を準備して確認します。