Skip to end of metadata
Go to start of metadata

FAQ

General Questions

1. How do I get started using AppNexus?

The fastest way to learn how to reserve a server and launch an instance is to follow our Tutorial.

2. I need a key pair to get started in the AppNexus cloud.  How do I generate one?

AppNexus uses public-key cryptography and SSH for authentication, and that requires a key pair.  If you're on a Mac or Linux OS, you can generate one via the ssh-keygen command.  On Windows you can download a tool such as PuTTYgen.  More detailed instructions can be found in http://github.com/guides/providing-your-ssh-key or elsewhere on the web.

3. I tried to SSH to a new instance and I got a warning message about "known hosts."  What do I do?

SSH stores known fingerprints of hosts in .ssh/known_hosts.  This can tell you if someone is doing a "man in the middle" attack that hijacks your session and is pretending to be the other host.  When you destroy an instance the IP address of that instance is recycled.  When it is assigned to a new instance, the instance has a new fingerprint and conflicts the one previously stored in the .ssh/known_hosts file.

To solve this, use the command rm .ssh/known_hosts.

4. I know my management instance is used to start/stop/manage instances.  But can I also use it to run other applications?

The management instance has no unique specifications; it's simply a way to get started building your environment.  We recommend keeping a separate management instance just to keep things neat, but there's no obligation to do that.  You can reuse your management instance for another purpose or replace it with a new management instance.  We DO, however, suggest that you use the rest of the resources on the management server to launch other instances.  This will not affect your management instance as long as resources are not overallocated.

Likewise, AppNexus command-line tools are not unique to your management instance—they are available as an RPM, and you can install them together with dependencies on any other instance you have running.

5. I have servers in both NYM1 and LAX1 datacenters.  Do I need a separate management instance for each?

No.  One management instance in either datacenter allows you to control all of your AppNexus infrastructure no matter where it is.  For example, the "manage-server list" command will list servers in both NYM1 and LAX1.

6. Our certificate was expired, so we tried uploading a new one to the pool and we got this error: this object has custom modifications and cannot be changed via API

Pools that have custom modifications cannot currently be managed by the API anymore.  Support can attach your certificate to the pool manually.

7. Can I run DHCP on my instances?

Not currently, because your DHCP server will conflict with AppNexus DHCP server, and thus it can lead to unavailable instances.

8. In our web server logs it appears that all requests to our load balanced web servers come from a single IP address.

It may appear that all requests to your load balanced applications come from the IP address of the AppNexus F5 load balancer.  Information on the real client IP address will come in an X-Forwarded-For header by default.  To extract this IP data, please see these short instructions from F5: http://devcentral.f5.com/weblogs/macvittie/archive/2008/06/02/3323.aspx.

9. Do I need to use NTP (Network Time Protocol) on my instances?

It depends on what kernel your instance is running.

  • If the instance is running a pvops kernel, you are encouraged to run NTP on the instance to keep time in sync. Without NTP, the instance will sync time with the hypervisor host at boot time; then its clock runs freely afterwards.
  • If the instance is running a Xen kernel, you are encouraged to run NTP only if /proc/sys/xen/independent_wallclock is set to 1. If the kernel parameter is set to 1, the instance syncs time with the hypervisor host on boot, then its clock runs freely. If the kernel parameter is set to 0, the instance syncs time with the hypervisor host at boot, then tries to stay in sync with the hypervisor host via the kernel.
  • If you are running the standard CentOS 6.6 public image from AppNexus without modifications, your instance is running a pvops kernel. If you are running your own custom image, check to see if the aforementioned kernel parameter exists on your instance. Existence of the parameter indicates it is running a Xen kernel, and thus allows you to manipulate it.
10. Can I SSH to an instance using a hostname instead of an IP address?

AppNexus assigns hostnames to servers (for example 021.webb.nym1.appnexus.net) but not to instances.  If you'd like to refer to your instances by a fully qualified domain name, instead of only by IP, you can set up your own DNS record the same way you would assign a hostname to your office workstations.  We can, however, assign PTR records to any IP.

11. When I transfer files between the NYM1 and LAX1 datacenters, I'm seeing about a Megabit per second throughput.  Is that expected for data transfers between east and west coast?

Yes.  We do not have any private channel between LAX1 and NYM1, and all traffic between them travels unencrypted through the Internet.  A transfer speed of 1.0 – 1.1 MB/s is typical, but it depends on several factors including protocol (FTP, SCP, etc.), network load, and file type (compressed, not compressed).  We are planning to setup our own dedicated channel between datacenters in the future and will alert customers when that is available.

Virtualization Questions

12. Does virtualization cause a performance hit when compared with running an OS on "bare metal"?

It's negligible.  Hypervisor technologies have evolved to a point where most applications have a performance hit of only a couple of percent.  In the worst case scenario it can be up to 10 or 12 percent for applications with extremely heavy disk input/output.

The benefits of virtualization over bare-metal applications include flexibility and maximization of resources.  If you don't have to stick to the one-application-one-server model, you need fewer servers, and less space, power, cooling, and maintenance staff.

13. I just launched an instance on a 4-core server that already had 4 cores in use…  how is this possible?

The number of cores you assign to your instance is not a mandatory resource dedicated to this instance—it's just a limit of the maximum cores the instance is able to use.  If you assign more cores than actually exist on the server and your instances have many idle cycles, then each of them will receive CPU up to their limit.  If they all become busy at once, then they will get portions of the CPU resources proportional to the limits you've set.  You can take advantage of this through the way you arrange your instances.

As a sidenote: the underlying Xen hypervisor layer hypothetically allows you to assign fractions of a core to an instance.  In practice, our customers generally don't require this, so we don't support fractional core assignments in our API/CLI.

14. What happens to my data when I shut down or restart an instance?

Our API is designed to keep all instance data when an instance is either intentionally shut down or restarted from a running state, or restarted after a software or hardware failure.  The old image and data will be automatically available when the server/instance restarts.  This is opposed to "manage-instance delete" where all data belonging to the instance is wiped out.  Instance data is only lost if there is a failure on the drive that causes corruption of the actual data.  Even if there is a failure on another area of the box we can always pull the drives out and start them up on a different physical host.

Note that when you run "manage-instance shutdown", the API will first try to gracefully shut down the instance.  After a certain timeout (it's currently hardcoded as 10 minutes—we'll give customers control of it in a future API/CLI release), if the API doesn't receive notification that instance was shut down, it will forcefully halt the instance.  At this point some data loss is possible, as the logical volume could be not properly unmounted (or other process finishes under abnormal conditions).

15. We noticed that if one of the instances starts doing a lot of disk I/O, it affects the performance of the other instances on the server.  Is Xen supposed to limit one instance's effect on another?

On the CPU side Xen can easily limit a process to a single core and hence limit any "resource hogging" on the box, but this is harder when it comes to a disk.  If two instances are trying to read from the same disk platter there is a basic "seek" time hit; there is only disk head on the platter and every time it switches to reading for one instances to another it needs to "seek" the location of the new file on the disk.  There's not much that virtualization can do to solve this problem.

This is one reason we think it is important to have control over the entire server: so you can avoid resource contention!

16. What version of Xen is my server running?

SSV stands for Server Software Version, which refers to the version of Xen/firmware/drivers running each physical server.  The SSV version is available on the Customer Portal.  Occasional SSV upgrades are performed by AppNexus support, but require the customer to reboot the server at their convenience.  With SSV 1.1 and later, all known IO issues on the instances are resolved.  It takes 5 to 15 minutes for "manage-server restart" to cycle through instance shutdown, server restart, and instance startup.  "manage-server restart" displays "[SUCCESS]" after server restart is finished; each instance startup takes an extra minute or so.  Note that once a server is rebooted, there is a delay in the SSV information upgrade: if a server was running version 0.9 or 1.0, the changes will be reflected on the customer portal within an hour; if server was running SSV 1.1 or newer, changes will be reflected within a day.

Security Questions

17. Do I get my own private VLAN?

Yes.  Your servers are on their own private network that is separate from the public network and from the VLANs of other clients.  Please see Security for more information.

18. Is communication between the load balancer and your instances private?  E.g. is it the same as instance-to-instance communication in a VLAN?

Yes.  The first 7 IPs and last 1 IP of your VLAN are reserved for network equipment, network address, and broadcast address, so both load balancers have an IP address local to your VLAN.  There is no way anybody can snoop or spoof traffic.

19. Why do you use ACLs instead of a stateful firewall?

Stateful inspection is most useful for protecting outbound traffic, but with hosting, the servers tend to receive traffic instead of initiate it.  Also, because we are dealing with an unknown amount of traffic, the ability to scale is very important.  Stateful inspection is a resource-expensive task for a device to perform and therefore subject to strict capacity limitations (we're talking sub Gigabit for most firewalls).  On the other hand, Cisco routers perform ACL packet filtering at line rate with absolutely no performance hit.  So, while stateful inspection is appropriate for small, stable amounts of outbound traffic or for protecting niche pieces of the network, (like e-commerce databases), ACLs are more scalable and efficient for protecting inbound traffic to servers.  If a customer still desires a stateful firewall, we can add it for a fee.

20. What are the security implementations at each relevant layer of the OSI Reference Model?
  • Layer 1 – (Physical Layer) All your network gear and servers are protected in secure, locked colocation facilities.
  • Layer 2 – (Data Link Layer) Extensive use of VLANs provides segregation of each customer's traffic from AppNexus traffic and other customers' traffic.
  • Layer 3 – (Network Layer) Bi-directional ACLs are applied on every routing interface with a Default Deny policy, meaning only explicitly permitted traffic is allowed to pass.
  • Layer 4 – (Transport Layer) The use of TCP-based protocols provides connection reliability and allows for session protection via ACLs and host firewalling.
  • Layer 7 – (Application Layer) There is extensive use of encryption (SSH, SSL-VPN) throughout the network.
21. How do you detect, prevent, and manage DDoS attacks and application-level attacks?

Preemptive protection against DDoS attacks is difficult, because we have no way of knowing when, where, or what type to expect.  Also, please note that AppNexus does not manage nor monitor the customer's applications (even their OS).  That said, in the event of an attack the use of Cisco ACLs allows us to apply deny statements for the source of the attack without affecting performance of the rest of the network.  Also, we highly recommend that our customers utilize the F5 server load balancing technology for front-ending their web applications, as the F5s provide built-in DDoS protection when it performs full-proxy session offload.

22. Are egress and ingress filters installed on all border routers to prevent impersonation with a spoofed IP address?

Yes.  We have a standard inbound filter on all ISP uplinks.  We also have filters applied at each customer's routing interface to assure that they are only using the IP address block that was assigned to them.