Skip to end of metadata
Go to start of metadata

On this page:

Your Rating:
Results:
PatheticBadOKGoodOutstanding!
16 rates
You can manually deploy the Controller to AWS. Manually deploying allows you to set custom configurations.

The following steps walk you through the procedure for deploying the AppDynamics Controller to an AWS environment. In these steps, you manually set up security groups, database parameter groups, Amazon Relational Database Service (RDS). Aurora DB instance, EC2 instance, Elastic Network Interface (ENI) for the Controller, DNS CNAMEs, and listeners for your load balancer. Afterward, you install the Enterprise Console. You then use the Enterprise Console to install the Controller and configure it for the AWS environment. 

A replacement EC2 instance for the Controller can be provisioned as needed, based on the Amazon Machine Image (AMI).

If you need guidance on your deployment, reach out to your AppDynamics account, sales, or professional services representative.

Before Starting

Aurora DB Regions

Amazon offers Aurora DB in most, but not all, regions. Please check the AWS Region Table in the AWS documentation to see if the Amazon Aurora - MySQL-compatible service is available in your region.

Amazon RDS Password Requirements

There are some naming constraints in the Amazon Relational Database Service (RDS). The master password for Aurora DB can be any printable ASCII character except "/", """, or "@", and must contain 8 to 41 characters. Master password constraints differ for each database engine.

You can find details of the naming constraints in Amazon RDS in the AWS documentation.

Deploy the Controller on AWS

Manually deploying the Controller on AWS involves the following steps:

Create Security Groups 

security group acts as a virtual firewall for your instance to control inbound and outbound traffic. For each security group, you add rules that control the inbound traffic to instances, and a separate set of rules that control the outbound traffic. 

At a minimum, we recommend creating the following security groups when deploying AppDynamics in AWS using Aurora DB.

You can create the following or additional security groups to align with your organization's standards


Required Security Groups 

Create the following security groups using the instructions provided in the AWS security groups documentation.

Security group for the AppDynamics Enterprise Console

Security group name: appd-ec-security-group

Inbound rules: Allow all inbound TCP traffic on ports 22 and 9191

Outbound rules: 

  • Allow outbound TCP traffic to appd-appserver-security-group on port 22
  • Allow outbound TCP traffic to appd-db-security-group on port 3388
Security group for the AppDynamics Controller Appserver

Security group name: appd-appserver-security-group

Inbound rules: 

  • Allow all inbound TCP traffic on port 22
  • Allow inbound TCP traffic on ports 8090-8097 from appd-elb-security-group

Outbound rules: Allow outbound TCP traffic to appd-db-security-group on port 3388

Security group for AppDynamics database instances

Security group name: appd-db-security-group

Inbound rules: Allow inbound traffic on port 3388 from appd-appserver-security-group and appd-ec-security-group

Outbound rules: No outbound access allowed

Security group for load balancer in front of the AppDynamics Controller

Security group name: appd-elb-security-group

Inbound rules: Allow all inbound HTTPS traffic on port 443

Outbound rules: Allow outbound TCP traffic to appd-appserver-security-group on ports 8090-8097


Create Custom DB Parameter Groups 

You need to modify some of the parameters for your database instance: 

ParameterRecommended Value
innodb_file_formatBarracuda
innodb_large_prefix1 (0 for Aurora 5.6)
innodb_lock_wait_timeout180
innodb_max_dirty_pages_pct20
lock_wait_timeout180
log_bin_trust_function_creators1
max_allowed_packet104857600
max_heap_table_size1610612736
query_cache_type0
sql_mode0
tmp_table_size67108864
wait_timeout31536000

Any parameters that are not modified will retain their default values.


You can do this by creating custom DB parameter groups:

  1. Navigate to the Parameter groups page on the Amazon RDS in the AWS console.
  2. Click Create parameter group on the top right of the page.
  3. Enter the group details.
  4. Modify the values of the following parameters in this group as follows: 
  5. Then, create a custom DB cluster parameter group.
  6. Modify the values of the following parameters in this group as follows:

    ParameterRecommended Value
    character_set_clientutf8
    character_set_connectionutf8
    character_set_databaseutf8
    character_set_filesystembinary
    character_set_resultsutf8
    character_set_serverutf8
    collation_connectionutf8_general_ci
    collation_serverutf8_unicode_ci
    innodb_default_row_formatDYNAMIC
    innodb_file_per_table1
    lower_case_table_names1

Launch an Amazon RDS Aurora DB Instance

  1. Launch a new Amazon RDS DB instance from the AWS console. Select Aurora with the MySQL 5.7-compatible option. 
  2. Select the desired DB Instance class. See Prepare the AWS Machine for the Controller for instance sizing information.
  3. Select Create Replica in Different Zone to have Amazon RDS maintain a synchronous standby replica in a different Availability Zone than the DB instance. Amazon RDS will automatically failover to the standby replica in the case of a planned or unplanned outage of the primary.
  4. Enter an identifier for the DB instance. The master username must be admin.  
  5. Select the Default VPC and subnet group. The DB should not be accessible publicly, so select No for this option.  
  6. For the security group, select the appd-db-security-group we created earlier. 
  7. For the database options, there is no need to specify the DB cluster identifier, nor is there a need to enter a database name since the installer will create the necessary databases for you. 
  8. Use the default database port of 3388
  9. Ensure you specify the custom parameter groups you created earlier. 
  10. Enabling encryption for data at rest is recommended.
  11. Use the default options for the remaining settings.
  12. Click Launch DB Instance, and your new database will be available for use within a few minutes.

Create Database User for Controller

During installation, AppDynamics needs to create additional databases and users in the Aurora database strictly for the AppDynamics Controller application to interact with the Aurora database server. 

To create the Aurora database:

  1. Create the Aurora database using admin as the master username. 
  2. After the Aurora database instance is created successfully, log in to the ec2 instance as admin:

    mysql -u admin -h <rds-aurora-endpoint> -P 3388 -p
  3. To create a new 'root' user, enter:

    CREATE USER 'root'@'%' IDENTIFIED BY 'controller';


  4. To check for the grants of the master username (admin), enter:

    mysql> SHOW GRANTS FOR admin;
     ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    Grants for admin@%
    ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER, LOAD FROM S3, SELECT INTO S3, INVOKE LAMBDA ON . TO 'admin'@'%' WITH GRANT OPTION
    ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
     1 row in set (0.00 sec)


  5. Apply the above grants for the new root user that you created in Step 1. The root user will have the same grants same as the admin user.

    mysql> GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER, LOAD FROM S3, SELECT INTO S3, INVOKE LAMBDA ON . TO 'root'@'%' WITH GRANT OPTION;
     Query OK, 0 rows affected (0.01 sec)
  6. Once the root user has the same privileges as the master username admin, verify that you can log in to the database as root, and then continue with the installation.

  • If you do not have users "root@x.x.x.x" and "root@ip-x-x-x-x.ec2.internal", you can ignore these users and continue to work with the root@%.
  • If you have users "root@x.x.x.x" and "root@ip-x-x-x-x.ec2.internal", then instead of using the previous GRANT command, you can use the following GRANT command:

    mysql> GRANT ALL ON `%`.* TO 'root'@'ip-x-x-x-x.ec2.internal' identified by 'controller' WITH GRANT OPTION;
    mysql> GRANT ALL ON `%`.* TO 'root'@'x.x.x.x' identified by 'controller' WITH GRANT OPTION;
    mysql> GRANT RELOAD ON . TO 'root'@'ip-x-x-x-x.ec2.internal' identified by 'controller' WITH GRANT OPTION;
    mysql> GRANT RELOAD ON . TO 'root'@'x.x.x.x' identified by 'controller' WITH GRANT OPTION;

After installation, you can revoke the master-level privileges from the Aurora root user without interfering with the functioning of the Controller. However, master-level privileges for Aurora root user are required prior to upgrading the Controller.

Launch an EC2 Instance for the Controller

The example steps below use the following AMI, which is provided by AWS: Amazon Linux AMI 2017.09.1 (HVM), SSD Volume Type - ami-f63b1193

The Amazon Linux AMI is an EBS-backed, AWS-supported image. The default image includes AWS command-line tools, Python, Ruby, Perl, and Java. The repositories include Docker, PHP, MySQL, PostgreSQL, and other packages.

  1. Select the desired instance type.
  2. Use the default instance settings.
  3. Bump up the storage, from the default 8 GB to 32 GB.

    You will need considerably more space on a larger server.

  4. Assign the instance to the appd-appserver-security-group you created earlier.

Prepare the Instance

To launch the instance, you will need to specify a key pair. If you are using an existing key pair, ensure you have access to the private key file. Otherwise, generate a new key pair and download it from the AWS console. The private key file is required to connect to the instance using SSH.

The new instance should be available after a few minutes. You can verify the status using the AWS console.

Once the instance is available, connect to it via ssh using the following command:

ssh -i "<private key file>.pem" ec2-user@ec2-18-222-75-189.us-east-2.compute.amazonaws.com

Substitute the appropriate path and filename for your private key file. 

Create the ENI for the Controller

You need to introduce an ENI, which acts as a secondary network interface that can be attached and detached from the Controller EC2 instance. You then have to tie the AppDynamics license file to the MAC address of this network interface, rather than the MAC of the underlying EC2 instance. 

Attach the new network interface to the Controller EC2 instance.

Create DNS CNAMEs

We recommend that you create aliases to use for connecting to the Aurora database instance and Controller EC2 instance. For example: 

appdcontroller.mydomain.com → appdcontrollerdb.cxylwiexaqo2.us-east-2.rds.amazonaws.com (DNS name for the Aurora DB instance)

appd-database.mydomain.com → ip-172-31-22-161.us-east-2.compute.internal (private DNS name for the ENI attached to the Controller)


These aliases should be used when installing the Controller via the Enterprise Console, as explained in detail below. Using aliases prevents you from tightly coupling the Enterprise Console with the specific Aurora DB instance or EC2 instance hosting the Controller. 

For example, if the database were to fail completely, and needed to be restored from a snapshot, then you would have a new DNS name for the Aurora DB instance. Pointing the Enterprise Console at an alias, instead of the DNS name for the Aurora DB instance itself, allows you to only update the DNS alias, and leave the Enterprise Console configuration unchanged. 

Similarly, if you need to move the Controller to a different EC2 instance, which resides in another Availability Zone (AZ), you can just update the DNS alias to point to the ENI in the new AZ. 

For purposes of testing an AWS configuration, it may not be possible to crease DNS aliases. In this case, you can just add entries to the /etc/hosts file on both the Enterprise Console and Controller EC2 instances. For example: 

172.31.17.84 appdcontroller 
172.31.25.80 appd-database

Install the Enterprise Console

This section explains how the Enterprise Console can be installed in an AWS environment, using an EC2 instance. The Enterprise Console is then used to install the Controller on a separate EC2 instance, using Aurora DB as the backend. 

Launch the EC2 Instance

For this example, we will use the following AMI, which is provided by AWS: Amazon Linux AMI 2017.09.1 (HVM), SSD Volume Type - ami-f63b1193

The Amazon Linux AMI is an EBS-backed, AWS-supported image. The default image includes AWS command-line tools, Python, Ruby, Perl, and Java. The repositories include Docker, PHP, MySQL, PostgreSQL, and other packages.

  1. Select the desired Instance type. The Enterprise Console has only modest requirements. You can, therefore, utilize the t2.medium instance type.
  2. Use the default instance settings.
  3. Bump up the storage, from the default 8 GB to 32 GB.
  4. Assign the instance to the appd-ec-security-group you created earlier.

Prepare the Instance

To launch the instance, you will need to specify a key pair. If you are using an existing key pair, ensure you have access to the private key file. Otherwise, generate a new key pair and download it from the AWS console. The private key file is required to connect to the instance using SSH. 

The new instance should be available after a few minutes. You can verify the status using the AWS console. 

Once the instance is available, connect to it via ssh using the following command: 

ssh -i "<private key file>.pem" ec2-user@ec2-18-222-75-189.us-east-2.compute.amazonaws.com

Substitute the appropriate path and filename for your private key file. 

Install the Enterprise Console

Use scp to transfer the Enterprise Console installer binary to your EC2 instance using the following command: 

scp -i "<private key file>.pem" platform_setup.sh ec2-user@ec2-18-222-75-189.us-east-2.compute.amazonaws.com:/data

SSH to your EC2 instance, then run the installer to install Enterprise Console:


cd /data
chmod 700 platform_setup.sh 
./platform_setup.sh -c

While installing the Enterprise Console, you will be prompted to choose a database port or accept the default port, 3377. Do not use port 3388 because it conflicts with the Controller database port which you will encounter in the subsequent steps.

You must have write access to the Enterprise Console installation directory you choose.

When installing one Controller in the AWS environment, it is simpler to install both the Controller and Enterprise Console on the same host. However, you should install Enterprise Console and the Controller on separate hosts if you are planning to install multiple Controllers and want to manage them via a single Enterprise Console instance.

Follow the instructions to complete the installation of Enterprise Console, and make a note of any passwords specified during the installation process.

Install the Controller in AWS Using Aurora

This section explains how to install the Controller in an AWS environment, using an EC2 instance for the Controller Appserver, and an AWS RDS Aurora instance for the database. This section uses the Enterprise Console that you previously installed in an earlier step. 

Before you install the Controller using Aurora as the database, you must adjust the time zone of the Aurora database to match the time zone of the Controller server. By default, AWS sets the time zone equal to the UTC time zone. For more information, click updating the Aurora RDS time zone.

Create a Platform

On the Enterprise Console instance, create a new platform: 

cd ./appdynamics/platform/platform-admin/bin
./platform-admin.sh create-platform --name <platform_name> --installation-dir /data/appdynamics/platform/product


Add a Host

Add a new host to the platform. This command installs the Controller on the same host as the Enterprise Console.


./platform-admin.sh add-hosts --platform-name testplatform --hosts localhost


Install the Controller

Install the Controller using Aurora as the database. Substitute the appropriate values for the admin user name, passwords, and Controller host and port. Ensure that databaseType is set to Aurora, and remember to use the private DNS name of the network interface attached to the Controller EC2 instance, rather than the DNS name for the EC2 instance itself. 

./platform-admin.sh submit-job --platform-name testplatform --service controller --job install --args controllerProfile=<profile_size> controllerPrimaryHost=<network_interface_private_DNS_name> controllerTenancyMode=single controllerRootUserPassword="<password>" mysqlRootPassword="<password>" controllerAdminUsername="admin" controllerAdminPassword="<password>" databaseType=Aurora controllerDBPort=3388 controllerDBHost="<auroraHost>"

The installer will connect to the Aurora DB instance and create the necessary databases, tables, and other objects. 

After a few minutes, the Controller should be installed and ready to go.


Apply Controller Optimizations

To enable SSL termination via the Enterprise Console UI:

  1. From the Enterprise Console, navigate to Configurations > Basic.
  2. At the bottom of the Basic page, check the Enable Mixed SLL channel checkbox.

To enable mixed channel termination from the CLI

From the command-line interface (CLI), enter the following:

./platform-admin.sh submit-job --service controller --job update-configs --args mixedSslChannel=true


Glassfish Configuration

The domain protocols, network listeners, transports, and thread pools should also be configured using the Enterprise Console UI. You can edit them on the AppServer Configurations page by choosing the platform, and navigating to Configurations > Controller Settings > Appserver Configurations. The following files contain sample content for each of these profiles: 

domain protocols.txt

domain network listeners

domain transports.txt

domain thread pools.txt

The Enterprise Console restarts the Controller after you submit your configurations.

Configure Load Balancer

You can configure a load balancer after the controller has been installed and is running in EC2. The load balancer distributes traffic across multiple ports on the Controller.   

If using HTTPS, An SSL certificate should be available. For testing, a self-signed certificate may be generated using Open SSL as described here. You can then import the certificate using AWS Certificate Manager (ACM). 

You can create the following load balancer to align with your organization's standards.

Create Load Balancer

To create a load balancer:

  1. Navigate to the Load Balancers page on the EC2 Dashboard in the AWS console.
  2. Click Create Load Balancer at the top left of the page.
  3. Select Application Load Balancer as the load balancer type, since you want to terminate SSL at the ELB.

  4. Provide a name for the new load balancer, and select HTTPS (Secure HTTP) as the load balancer protocol to accept HTTPS traffic only.

  5. Select the availability zones to enable for the new load balancer. It should include the availability zone in which the Controller Appserver EC2 instance resides.

  6. Choose the certificate that was imported to the ACM.

  7. Specify the security group.

  8. For the initial configuration, set the load balancer to route all traffic to port 8090 using HTTP, and define the standard health check for the Controller.

  9. Add the Controller EC2 instance as a registered target.

  10. Launch the new load balancer. It may take a few minutes before the load balance is required.
  11. Verify that you can access the Controller UI via the load balancer.

    If your SSL cert is self-signed, you will get a browser warning. For the purposes of testing the UI, you can ignore it. But for agent traffic, you need a valid cert that is trusted by the agent.

Set External Load Balancer URL

The Controller configuration should be updated using the Enterprise Console GUI to specify the external load balancer URL.

To do so:

  1. Open a browser and navigate to the GUI: 

    http://<hostname>:<port>

    9191 is the default port.

  2. Navigate to AppServer Configurations by choosing the platform, Configurations > Controller Settings > Appserver Configurations.
  3. Enter the external load balancer URL in the appropriate field, and click Save.
You should create an AMI after you are done applying your optimizations.

Configure Additional Listeners

The rules that you define for your listener determine how the load balancer routes requests to the targets in one or more target groups.

You can configure the following additional listeners if the host is not responding to the existing listeners.


Configure Listener Rules

You can define additional rules, to route traffic to various ports on the Controller, depending on the type of request. The following table defines the rules that users typically define for the load balancer:


Pool Name

URL Pattern

Port Number

Description

metrics-thread-pool

/controller/instance/*/metrics
/controller/instance/*/metrics*

8091

Agent metric data upload

config-thread-pool

/controller/instance/*/applicationConfiguration*

8092

Agent configuration requests

agent-thread-pool

/controller/instance/*

8093

Other Agent requests

status-thread-pool

/controller/rest/serverstatus

8094

Server status ping by load balancer

http-thread-pool

Default / User Traffic

8090

Default thread pool for all other traffic

restui-default-thread-pool

/controller/restui/*

8095

Default thread pool for all restui traffic

restui-analytics-thread-pool

/controller/restui/analytics/*

8096

Thread pool traffic for analytics traffic

Create Target Groups

You need to create a target group for each of the rules listed above, with the exception of the default http-thread-pool rule, for which you can use the default target group.

For example, you would create a target group for the metrics-thread-pool as follows: 

The same health check path can be utilized for all of the target groups, though you may want to decrease the frequency, as performing the same check on all ports every 30 seconds is not required. 

Register Targets

  1. You will then need to associate each target group with the EC2 instance.

    The full list of target groups should appear as follows: 

  2. Now that the target groups are in place, you need to add new listener rules, to map the traffic to the appropriate target group, based on the path requested.

    The order of the rules is essential here, as some paths may match multiple rules.

Troubleshooting the Installation

Controller EC2 Instance Stops

If the Controller EC2 instance stops almost immediately after installing the Controller, you may have an issue with your EBS devices. AWS may report that it is not able to boot from the volumes. If the EC2 machine stops, check and update your EC2 volumes so that they are mounted correctly.

  • No labels