If you have an account with AppNexus, this tutorial will walk you through launching an instance and setting up a basic web application. If you do not yet have an account, please contact us at: email@example.com.
The building blocks of an AppNexus configuration are: the server, the instance, the image, and the pool.
Servers are actual physical machines sitting in datacenters with all of the usual components: CPUs, memory, disk, network cards, and so on. On each server, AppNexus runs a Xen virtualization layer. This virtualization layer allows you to install multiple operating systems that each think they're running on their own server.
Instances are individual operating systems that run on top of a virtualization layer. Each instance has its own IP address (assigned from the customer's private VLAN), and gets a share of the CPU, memory, disk, and other resources of the underlying server. You can install as few or as many instances on a server as you want. The operating system won't know the difference.
Images are files that contain all of the information needed to start an instance---basically a snapshot of a hard drive running a particular operating system. AppNexus provides a base images for CentOS (based on Red Hat Enterprise Linux), or you can create your own.
Pools are sets of instances that share an external address for load balancing. The load-balancing hardware will take incoming requests and hand them off to the instances in the pool based on criteria you set: round robin, least connections, and so on. If an instance in the pool should go down for any reason (maintenance, hardware crash, software bug), the load balancer will remove it temporarily from the pool, sending more requests to the other instances.
In this quick start guide, we will use the AppNexus command-line tools to reserve a server, launch some instances, and create a pool to load balance traffic between them.
Step 1: Log in to your management instance
Initially you filled out a customer questionnaire that included VLAN settings and a public key from a public-private key pair. For more information on key pair authentication please see this page.
Then you received a welcome email that included information about your management instance. This management instance is your initial entry point into your AppNexus environment. From this instance, you can upload images, launch instances, and set up your environment. Please note that your management instance takes up minimal resources on a server. We recommend you use the rest of the server's resources for other instances. This will not affect your management instance.
To log in to your management instance, SSH to the address specified in your welcome email. You will use your private key for authentication.
The AppNexus command-line tools (CLI) have been installed in
/usr/bin. These have been configured with your ssh keys, so you can use them without any further configuration.
Step 2: Reserve a Server
Since each physical AppNexus server is dedicated to a particular customer, you need to reserve servers before launching instances. Your management instance is running on a server that's already reserved for you.
To see what servers you already have reserved, use the
list option on the
that you have to authenticate yourself in order to use the API/CLI commands. Authentication can be done either by specifying your login in the command line or by placing your credentials into the CLI configuration file 'rpc.cfg'. Refer to API and CLI Documentation for details.
This says that we have already reserved the server NYM1:39 with the server specification "webb" in rack 01-12, with a quad-core CPU, 7192MB of memory, and 630GB of available disk space. (Some resources are taken up by the management instance.) You can get even more information about this server with the
manage-server list --reserved --verbose. This will, for example, include status, cpu_speed, total_memory, total_disk, and ip_address. Of special importance in the verbose listing is the lease_expires_on column which shows the date when you will need to release the server back to the pool of available servers. If you would like to see where a rack is located in the datacenter, see our Datacenters page.
Let's see what servers are available to reserve at the moment.
As you can see, there are a variety of servers available. Let's reserve a basic "webb" box. To do so, chose the ID of a box from the list of available servers. ID is in the form <datacenter>:<server ID>
If we list our reserved servers again, we'll now see both our management server and the server we just reserved.
- manage-server documentation
- Server Specifications
- For the location of specific racks within a datacenter, please see Network Architecture Map
Step 3: Launch your first instances
The next step is to launch new instances on our servers. First we need to choose an image to run. For now, we'll use CentOS (the open source version of RedHat). For convenience, AppNexus provides a pre-built version of CentOS, which we can access by looking in the
images directory on the public Network Attached Storage share, which has been mounted on your management instance.
When we start an instance, we can decide which of the resources of the server to give it. By assigning limited resources, we can share the server across multiple functions, which can be very cost efficient. Let's start a small instance on each of our servers. We'll assign each one 10000MB of disk, 1GB of memory, and 1 CPU core. For now we will let the API assign the first available IP address from our VLAN.
If you have more than one user and more than one key pair for authentication, or if you are launching an instance on behalf of another user, you may want to use the "
--authorized-keys" option to add extra public keys when launching an instance. If no keys are added to the instance in this step, the instance will not be accessible. For more information, see Key Pair Authentication
When an image is launched, it takes a couple of minutes to copy over the image file and start the operating system. We can use the
list command to watch the process:
After a few minutes, we note the state changes from "starting" to "running":
Now all we need to do is log in to the instances! Each instance has your base SSH key installed, so logging in is easy:
Step 4: Configure your application
Now that the instance has started, let's poke around a bit. Let's check out the CPU:
That's good---the operating system only sees one core. Let's take a look at memory:
As expected, the operating system sees 1GB of RAM. How about disk?
Let's check out what packages are installed in our CentOS image:
OK, lots of packages. Is Apache installed?
If it isn't installed, you can install it with:
Great! We're ready to launch a web site. Let's start apache, and have it start automatically on reboot.
We'll install a dummy web page on the server so that we know our installation worked:
Excellent! Let's repeat these steps from our other instance:
Let's make sure everything works from our management instance:
Step 5: Load Balancing Our Instances
Before we can create a load-balancing pool, we need to reserve a virtual IP to assign to the pool. The reason we use a VIP is because we can use an IP across multiple LB pools (as long as each uses a separate port!).
We reserve a LB VIP just like we reserve servers. Make sure you use an IP located in the same datacenter as your load-balancing pool.
With a load-balancer VIP in hand, let's create our first pool. Although there are various options for directing traffic, we are going to stick to the default, which is round robin. Please see Configuring Local Load Balancing for details on more advanced options.
Next we add our two instances to the pool. If you've forgotten the IPs, just use the
manage-instance command to look them up:
Repeat with any other nodes you would like to add. Let's add node 188.8.131.52.
Next let's check to see if the load balancer can properly load our instances by using the
Let's check the LB-VIP to see if we get a hello world:
And we're done! We have successfully set up two load-balanced instances. Note that when you curl the load balancer repeatedly you may very well continually hit the same instance even though the selected method is "round robin." Our load-balancing hardware reuses TCP connections to limit the number of open connections to open nodes.
Global Load Balancing
You can increase redundancy and availability for your applications, balancing your traffic globally between Los Angeles and New York datacenters. Please find more about DNS-based global server load balancing (GSLB) at Global Load Balancing Documentation and Global Load Balancing wiki pages.
- Please use our documentation wiki to learn about other features such as Load Balancing Overview and Network Attached Storage.
- You set initial ACLs in your customer questionnaire. To change them at any time, please see How to Set Firewall Rules.
As always, please create a ticket at https://portal.appnexus.com/ or contact us at firstname.lastname@example.org if you have any questions or concerns.