Versions Compared

    Key

    • This line was added.
    • This line was removed.
    • Formatting was changed.
    Comment: Published by Scroll Versions from this space and version 20.7
    Sv translation
    languageen
    Appd tocbox
    Width410px

    Related pages:

    This page introduces you to the tasks involved with deploying AppDynamics to its operating environment, including host preparation and Controller installation.

    The system resources of the machine that hosts the Controller in a live environment must be able to support the expected workload.

    Anchor
    deploymentconsids
    deploymentconsids
    Deployment Overview

    Installing AppDynamics to a test or evaluation setting typically involves verifying system requirements, preparing the host, and then performing the Controller installation. These topics are described in Prepare the Controller Host and Install the Controller Using the Enterprise Console.  

    Deploying the Controller to its production operating environment normally introduces additional requirements and considerations. Security, availability, scalability, and performance all play an important role in production deployment planning. The following section lists the tasks related to deploying the Controller. 

    Deployment Tasks

    Depending on your specific requirements and environment, deployment tasks may include:  

    • Ensure that target systems meet the Controller System Requirements for the Controller's expected workload. 
    • For high volume environments, tune the OS and Controller settings for the high workload. 
    • Implement Controller High Availability to ensure service continuity in the event of a failure of the Controller server.   
    • Configure the network environment. If deploying the Controller with a reverse proxy, configure passthrough of Controller traffic. Also, note other Network Requirements for the deployment environment. 
    • Implement security requirements for your environment. If clients will connect to the Controller by HTTPS, install your custom SSL server certificate on the Controller.  
    • Generate a password management strategy for the built-in system accounts in the Controller and platform.  
    • Make sure the mail server is properly configured for the Controller in the target environment and define your alerting strategy.
    • Devise your backup strategy.  A typical backup strategy consists of frequent partial backups with intermittent full backups.
    • Plan your configuration maintenance and enhancement strategy. Changes to the configuration should be staged in a non-critical environment, and rolled into the live environment only after thorough testing. The AppDynamics UI and REST API offer the ability to export and import configuration settings from various contexts.   
    • Deploying App Agents is likely to be an ongoing task, especially in dynamic environments where monitored systems are regularly taken down and new ones brought up. There are two basic strategies for deploying large numbers of App Agents across a managed environment:
      1. Deploy the agents independently of the application inside the application server. This method ensures that re-deployments of the application do not overwrite the agent deployment.
      2. Integrate deployment of AppDynamics agents into the deployment of applications. This more sophisticated approach requires modifying the existing application deployment automation scripts.
      For details, see:

    Anchor
    networkrequirements
    networkrequirements
    Network Requirements 

    Deploying the Controller often calls for configuration changes to existing network components, such as to firewalls or load balancers in the network. If the Controller will reside behind a load balancer or reverse proxy, you need to set up traffic forwarding for the Controller. You may also need to open ports used by AppDynamics on firewalls or any other device through which traffic must traverse.  

    The following are general considerations for the environment in which you deploy AppDynamics. See 2020-05-12_18-16-01_AppDynamics Quick Start for other network configuration requirements. 

    Correlation HTTP Header

    AppDynamics adds a custom header to traffic in the monitored environment named singularityheader. This header enables AppDynamics to correlate traffic across tiers. It's important to ensure that any load balancer, proxy or firewall in the network between monitored tiers or between the tiers and the Controller preserves the header added by AppDynamics. 

    Clock Management

    To ensure consistent event time reporting across the AppDynamics deployment, App Agents attempt to synchronize their time with the Controller time.

    They do so by retrieving the time from the Controller every five minutes. App Agents then compare the Controller's time to its own local machine's clock time. If the times are different, whether ahead or behind, it applies a time skew based on the difference to the timestamps for the metrics it reports to the Controller.

    If, despite the agent's attempt to report metrics based on the Controller time, the Controller receives metrics that are time-stamped ahead of its own time, the Controller rejects the metrics. To avoid this possibility, AppDynamics recommends maintaining clock-time consistency throughout your monitored environment. 

    Admin Accounts Created at Installation

    During the installation process, you need to configure several accounts for the Controller. These include the embedded MySQL database account, a root user account in the Controller and an administrator in the Controller. 

    Usernames and passwords should not include the & or ! characters. If a user account needs to access the Controller REST API, additional limitations on the use of special characters in usernames apply. See Manage Users and Groups for more information.  

    About Controller Tenancy Mode

    In most installations, the Controller operates in single-tenant mode. In multi-tenant mode, the Controller UI context is divided into separate accounts. Each account has its own set of users, agents reporting to it, and application monitoring configuration. 

    You choose the tenancy mode at installation time. You can switch the tenancy mode from single-tenant to multi-tenant mode later. It is not possible to switch from multi-tenant to single-tenant mode.

    Having a single tenancy Controller is suitable for most installations. Only very large installations or installations that have very distinct sets of users may require multi-tenancy.

    A summary of the differences between the modes follows:

    • In multi-tenant mode:
      • You can create multiple accounts (tenants) in the Controller. 
      • Each account will have its own set of users and applications. 
      • The Controller login page includes an additional field where users need to choose an account to log in to. 
      • Essentially, multi-tenant mode allows you to partition users and access to application data in a logical, secure way. 
    • In single-tenant mode:
      • There is only one account (tenant) in the Controller system. 
      • All users and applications are part of this single built-in account, so all users have access to all monitored Applications in this mode.
      • The account is not exposed to users in the Controller UI. The account field in the login page is omitted for single-tenant mode.
      • AppDynamics recommends single-tenant mode for most installations.

    For more information, see Controller Accounts (Multi-Tenancy)

    Self-Monitoring the Controller

    You can use the system account to self-monitor the Controller.  When your system experiences noticeable performance issues with the Controller, you can log in to the system account to access and review the memory utilization trend for the last few hours.  

    Info

    Only the internal Java Agent bundled in the path: <Controller_home>//appserver/glassfish/domains/domain1/appagent(-javaagent:${com.sun.aas.instanceRoot}/appagent/javaagent.jar) with the controller application is supported for self-monitoring. Using a custom Java Agent from a different path is not supported for self-monitoring.

    To self-monitor the Controller using the system account: 

    1. If you are already logged in to the Controller from your Browser, you must first log out as a non-administrative user of the Controller.
    2. Log back in to the Controller using the following credentials:
      • Account: system
      • User: root
      • password: <root password>
    3. Select Appdynamics Controller application.
    4. Select Tiers and Nodes >  Node1 > Memory to review the memory trend for the past 24 hours and locate the time when the performance issues occurred. 


    Sv translation
    languageja
    Appd tocbox
    Width410px

    On this page:

    Table of Contents
    maxLevel2
    minLevel2

    Related pages:

    このトピックでは、AppDynamicsの稼働環境へのデプロイに関連するタスクを紹介します。これには、ホストの準備とコントローラのインストールが含まれます。

    本番環境でコントローラをホストするマシンのシステムリソースで、予測されるワークロードに対応できる必要があります。

    Anchor
    deploymentconsids
    deploymentconsids
    デプロイ概要

    通常、AppDynamics をテストまたは評価設定にインストールする場合、システム要件が確認され、ホストが準備されてから、コントローラのインストールが実行されます。これらのトピックについては、「Prepare the Controller Host」および「Enterprise Console を使用するコントローラのインストール」で説明されています。  

    コントローラをその実稼働運用環境にデプロイすると、通常は追加の要件および考慮事項が発生します。運用環境デプロイプランでは、安全性、可用性、スケーラビリティ、パフォーマンスすべてが重要な役割を果たします。次のセクションでは、コントローラのデプロイに関連するタスクが一覧にされています。 

    デプロイタスク

    個別の要件と環境によって、デプロイタスクには以下が含まれる場合があります。

    • 対象のシステムが、コントローラの予測されるワークロードに対して Controller System Requirements を満たしていることを確認する。 
    • 高容量環境の場合、高いワークロードに合わせて OS とコントローラ設定の調整を行う。 
    • Controller High Availabilityを実装して、コントローラサーバの失敗時にサービスを継続させる。   
    • ネットワーク環境を構成する。リバースプロキシを使用してコントローラをデプロイする場合、コントローラトラフィックのパススルーを構成する。デプロイ環境については、他のネットワーク要件も参照。 
    • 環境のセキュリティ要件を実装する。クライアントが HTTPS によりコントローラに接続している場合は、コントローラ上にカスタム SSL サーバ証明書をインストールする。  
    • コントローラとプラットフォームでビルトイン システム アカウントのパスワード管理戦略を生成する。  
    • 対象の環境のコントローラに対して、メールサーバが適切に構成されていることを確認し、アラート戦略を定義する。
    • バックアップ戦略を工夫する。通常のバックアップ戦略は、頻繁に行われる部分的なバックアップと断続的なフルバックアップで構成されている。
    • 構成メンテナンスとエンハンスメント戦略を計画する。構成の変更は、重要ではない環境でステージングし、徹底的なテストを行った後でのみ実稼働環境にロールオーバーする。AppDynamics UI および REST API には、さまざまなコンテキストから構成設定をエクスポートおよびインポートする機能が備わっている。   
    • アプリエージェントのデプロイは、特に監視されているシステムを定期的に停止し、新しいシステムを立ち上げる動的な環境では、継続的なタスクであることが多くなる。管理された環境で多数のアプリエージェントをデプロイするための基本戦略は 2 つある。
      1. デプロイアプリケーションサーバー内のアプリケーションのエージェントを個別にデプロイする。この方法なら、アプリケーションの再デプロイによってエージェントのデプロイが上書きされなくなる。
      2. AppDynamicsエージェントのデプロイをアプリケーションのデプロイに統合する。この細かなアプローチを行うには、既存のアプリケーションデプロイの自動化スクリプトを変更する必要がある。
      詳しくは、以下を参照。

    Anchor
    networkrequirements
    networkrequirements
    ネットワーク要件

    コントローラのデプロイでは、ネットワークのファイアウォールやロードバランサなど、既存のネットワークコンポーネントの構成変更が必要になることがよくあります。コントローラがロードバランサまたはリバースプロキシの背後に存在する場合、コントローラのためにトラフィック転送を設定する必要があります。また、トラフィックが横断しなければならないファイアウォールまたはその他のデバイスで AppDynamics が使用するポートを開く必要があります。  

    以下は、AppDynamics をデプロイする環境に関する一般的な考慮事項です。他のネットワーク構成要件については、「2020-05-12_18-16-01_AppDynamics Quick Start」を参照してください。 

    相関HTTPヘッダー

    AppDynamicsは、監視されている環境のトラフィックにsingularityheaderという名前のカスタムヘッダーを追加します。このヘッダーにより、AppDynamicsはティア全体でトラフィックを関連付けることができます。監視されているティア、またはティアとコントローラ間のネットワークにあるロードバランサ、プロキシ、またはファイアウォールが AppDynamics により追加されたヘッダーを保護していることを必ず確認してください。 

    クロック管理

    AppDynamicsのデプロイでイベント時間レポートの一貫性を確保するために、アプリケーションエージェントがイベント時間とコントローラ時間の同期を試みます。

    そのために、5分毎にコントローラから時間を取得します。それから、コントローラの時間を自身のローカルマシンのクロックタイムと比較します。時間にずれがあれば、コントローラに報告するメトリックのタイムスタンプとの違いに基づいて、タイムスキューを適用します。

    エージェントがコントローラの時間に基づいてメトリックの報告を試みているにもかかわらず、コントローラが自身の時間より先のタイムスタンプを持つメトリックを受け取った場合、コントローラはそのメトリックを拒否します。これを防ぐために、AppDynamics は監視環境全体でクロックタイムを一貫させることを推奨します。 

    インストール時に作成される管理アカウント

    インストールプロセスで、コントローラに対する複数のユーザを構成する必要があります。これには、埋め込み MySQL データベースアカウント、コントローラのルートユーザアカウント、コントローラの管理者などが含まれます。 

    ユーザ名とパスワードに「 &」および「!」を使用することはできません。ユーザアカウントがコントローラ REST API にアクセスする必要がある場合、ユーザ名における特殊文字の使用に関する追加制限が適用されることに注意してください。詳細については、「Manage Users and Groups」を参照してください。  

    コントローラテナンシーモードについて

    ほとんどのインストール環境では、コントローラはシングルテナントモードで動作します。マルチテナントモードでは、コントローラUIのコンテキストが個別のアカウントに分割されます。各アカウントにはそれ自体のユーザーセット、それにレポートするエージェント、およびアプリケーションモニタリング構成が含まれています。 

    テナントモードはインストール時に選択します。後からテナントモードをシングルテナントモードからマルチテナントモードに切り替えることができます。マルチテナントモードからシングルテナントモードに切り替えることはできません。

    シングルテナントのコントローラはほとんどのインストールに適性があります。非常に大きなインストールまたは大きく異なるユーザーグループを持つインストールの場合のみ、マルチテナントが必要になる場合があります。

    モード間の違いの概要は、次のとおりです。

    • マルチテナントモードの場合:
      • アカウントコントローラで複数のアカウント(テナント)を作成できる。 
      • 各アカウントが独自のユーザとアプリケーションを持つ。 
      • コントローラのログインページに、ユーザがログインするためのアカウントを選択する必要のある追加のフィールドがある。 
      • 基本的にマルチテナントモードでは、論理的かつ安全な方法でユーザを分割し、アプリケーションデータへのアクセスを可能にする。 
    • シングルテナントモードの場合:
      • コントローラシステムにあるアカウント(テナント)は 1 つのみである。 
      • すべてのユーザーとアプリケーションは、この単一の組み込みアカウントの一部であるため、このモードではすべてのユーザーが監視対象の全アプリケーションにアクセスできる。
      • アカウントはコントローラUIでユーザーに公開されない。シングルテナントモードでは、ログインページのアカウントフィールドが省略されている。
      • AppDynamicsでは、大部分のインストールにおいてシングルテナントモードを推奨。

    詳細については、「Controller Accounts (Multi-Tenancy)」を参照してください。