PDFs

On this page:

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

These steps walk you through the alternative procedure for deploying the AppDynamics Controller to an AWS environment. In them, 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. Afterwards, 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).

Before Starting

Aurora DB Regions

Aurora DB is offered in most, but not all, regions. Please check the AWS Region Table 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.

See the Naming Constraints in Amazon RDS for more information.

Deploy the Controller on AWS

Manually deploying the Controller on AWS involves the following steps:

1. Create Security Groups 

A 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, the following security groups are recommended 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 

The following security groups should be created, using the instructions provided in the AWS documentation.

Security Group Name
Purpose
Inbound Rules
Outbound Rules
appd-ec-security-groupSecurity group for the AppDynamics Enterprise ConsoleAllow all inbound TCP traffic on ports 22 and 9191

Allow outbound TCP traffic to appd-appserver-security-group on port 22

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

appd-appserver-security-groupSecurity group for the AppDynamics Controller Appserver

Allow all inbound TCP traffic on port 22

Allow inbound TCP traffic on ports 8090-8097 from appd-elb-security-group

Allow outbound TCP traffic to appd-db-security-group on port 3388
appd-db-security-groupSecurity group for AppDynamics database instancesAllow inbound traffic on port 3388 from appd-appserver-security-group and appd-ec-security-groupNo outbound access allowed
appd-elb-security-groupSecurity group for load balancer in front of the AppDynamics ControllerAllow all inbound HTTPS traffic on port 443Allow outbound TCP traffic to appd-appserver-security-group on ports 8090-8097

 

2. 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 paramter 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

3. 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 fail over to the standby in the case of a planned or unplanned outage of the primary.
  4. Enter an identifier for the DB instance. The master username needs to be root.  
  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 as 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.

4. 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. 

5. 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.

6. Create DNS CNAMEs

It is recommended 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. This 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 Consle at an alias, instead of the DNS name for the Aurora DB instance itself, allows you to simply 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 simply 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 simply 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

7. 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

You need to install the Enterprise Console on a separate directory from the Controller. The Enterprise Console data directory needs to be in a separate folder from the Controller data directory. You also need to avoid port conflicts with the Controller database, which is 3388 by default, whereas the Enterprise Console database is 3377 by default.

The Enterprise Console installation path you choose must be writeable, i.e. the user who installed the Enterprise Console should have write permissions to that directory.

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

 

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

8. Install the Controller in AWS Using Aurora

This section explains how the Controller can be installed in an AWS environment, using an EC2 instance for the Controller Appserver, and an AWS RDS Aurora instance for the database. It will utilize the Enterprise Console that was installed in an earlier step. 

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, using the private DNS name of the secondary network interface that is attached to the Controller EC2 instance, as well as the credentials created earlier:

 

./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 Auroraand 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.

 

9. Apply Controller Optimizations

SSL Termination

Edit the services-config.xml file of the Glassfish server. This file is located at <controller-home>/appserver/glassfish/domains/domain1/applications/controller/controller-web_war/WEB-INF/flex/.

Make a backup copy of services-config.xml before editing it.

Find the channel-definition element with an id value of my-secure-amf. Replace the default value of the class attribute of the endpoint URL element, flex.messaging.endpoints.SecureAMFEndpoint, with a new value of flex.messaging.endpoints.AMFEndpoint. The resulting element should look like this:

 

<channel-definition id="my-secure-amf" class="mx.messaging.channels.SecureAMFChannel">
    <endpoint url="https://<hostname>:<port>/controller/messagebroker/amfsecure" class="flex.messaging.endpoints.AMFEndpoint"/>
        <properties>
        <add-no-cache-headers>false</add-no-cache-headers>
        <connect-timeout-seconds>10</connect-timeout-seconds>
    </properties>
</channel-definition>

 

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 ConfigurationsController Settings, and Appserver Configurations. Sample content for each of these are included in the following files: 

domain protocols.txt

domain network listeners

domain transports.txt

domain thread pools.txt

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

10. 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, as 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 it is required to be used.
  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 simply ignore it. But for agent traffic, you will 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, ConfigurationsController Settings, and 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.

11. 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 are typically defined 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, which you can use the default target group for.

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 important 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 properly.

  • No labels