Traffic Server Administration

Installing Traffic Server

  1. Build the Traffic Server RPM. The best way to do this is to follow the Apache Traffic Server documentation.

  2. Build the astats RPM using the appropriate version number - ours are built here

    Note

    The astats plugin is bundled as a part of Apache Traffic Server as of version 7.2.

  3. Install Traffic Server and astats

    #43 Apache Traffic Server Installation Using yum(8)
    yum -y install trafficserver-*.rpm astats_over_http*.rpm
    
  4. Add the server using the Traffic Portal UI:

    1. Go to Configure ‣ Servers

    2. Click on the + button at the top of the page.

    3. Complete the form. Be sure to fill out all fields marked ‘Required’

      • Set ‘Interface Name’ to the name of the network interface device from which Apache Traffic Server delivers content.
      • Set ‘Type’ to ‘MID’ or ‘EDGE’.
      • If you wish for the server to immediately be polled by the Health Protocol, set ‘Status’ to ‘REPORTED’.
    4. Click on the Create button to submit the form.

    5. Verify that the server status is now listed as Reported

  5. Install the ORT script and run it in ‘BADASS’ mode to create the initial configuration

  6. Start ATS

    #44 Starting ATS with systemd(1)
    systemctl start trafficserver
    
  7. (Optional) Configure ATS to start automatically when the system powers on

    #45 Configuring ATS to Start Automatically Using systemd(1)
    systemctl enable trafficserver
    
  8. Verify that the installation is working

    1. Make sure that the service is running

      #46 Checking that ATS is Running Using systemd(1)
      systemctl status trafficserver
      
    2. Assuming a Traffic Monitor is already installed somewhere, check the “Cache States” table in its Web UI to verify that the ATS server appears.

Configuring Traffic Server

All of the ATS application configuration files are generated by Traffic Ops and installed by ORT. The traffic_ops_ort.pl file should be installed on all cache servers (See Installing the ORT Script), usually in /opt/ort. It is used to do the initial install of the configuration files when the cache server is being deployed, and to keep the configuration files up-to-date when the cache server is already in service.

ORT Config File Generation

In the past, ATS config files were generated by Traffic Ops. Traffic Control is in the process of moving ATS config file generation to a library for generic use, and to an application which uses the library and resides on the cache.

The library, lib/go-atscfg, allows users to write their own applications and servers, if they wish to generate ATS configuration files and deploy them to caches via other means. For example, if you wish to generate config files with an additional service, or continue generating config files on Traffic Ops itself via a plugin or local service.

The app, atstccfg, is installed by the traffic_ops_ort RPM alongside the ORT script. This app makes standard API calls to Traffic Ops, and uses their data to build the ATS config files. The ORT script now requests all config through the app, which generates config files it has, and requests directly from Traffic Ops the files it doesn’t recognize.

This provides several benefits. Primarily, reduces the overhead and risk of the monolithic Traffic Ops installation and upgrade process, and allows operators to canary-test config changes one cache at a time, and in the event of an error, only rolling back a few canary caches rather than the entire Traffic Ops instance.

In order to see which config files are generated by a given ORT or atstccfg version, run /opt/ort/atstccfg --print-generated-files.

Installing the ORT Script

  1. Build the ORT script RPM by following the instructions in Building Traffic Control and install it with rpm(8) or yum(8).

  2. Install modules required by ORT if needed

    #47 Example Installation of Perl Packages Occasionally Missing from Install
    yum install -y perl-JSON perl-Crypt-SSLeay
    
  3. For initial configuration or when major changes (like a Profile change) need to be made, run the script in “BADASS”. All required RPM packages will be installed, all ATS configuration files will be fetched and installed, and (if needed) the ATS service will be restarted.

    Note

    The first run gives a lot of state errors that are expected. The “BADASS” mode fixes these issues. If you run it a second time, this should be cleaner. Also, note that many “ERROR” messages emitted by ORT are actually information messages. Do not panic.

  4. Create a cron(8) entry for running ORT in “SYNCDS” mode every 15 minutes. This makes Traffic Control check periodically if the server has updates pending, and if so get the updated configuration.

    Note

    By default, running ORT on an Edge-tier cache server will cause it to first wait for its parents (usually Mid-tier cache server s) to download their configuration before downloading its own configuration. Because of this, scheduling ORT for running every 15 minutes (with 5 minutes default dispersion) means that it might take up to ~35 minutes for queued updates to affect all cache server s. To customize this dispersion time, use the command line option --dispersion=x where x is the number of seconds for the dispersion period. Servers will select a random number from within this dispersion period to being downloading configuration files from Traffic Ops. Another option, --login_dispersion=x can be used to create a dispersion period after the job begins during which ORT will wait before logging in and checking Traffic Ops for updates to the server. This defaults to 0. If use_reval_pending, a.k.a. “Rapid Revalidate” is enabled, Edge-tier cache servers will not wait for their parents to download their configuration before downloading their own.

    Note

    In “SYNCDS” mode, the ORT script updates only configurations that might be changed as part of normal operations, such as:

    • Delivery Services
    • SSL certificates
    • Traffic Monitor IP addresses
    • Logging configuration
    • Revalidation requests (By default - if “Rapid Revalidate” is enabled, this will only be checked by using a separate revalidate command in ORT)
  5. If “Rapid Revalidate” is enabled in Traffic Ops, create a second cron(8) job for revalidation checks by running ORT in “REVALIDATE” mode. ORT will not check revalidation files if “Rapid Revalidate” is enabled. This setting allows for a separate check to be performed every 60 seconds to verify if a revalidation update has been made.