MediaWiki / Amazon ELB / CloudFlare – IP Addresses

Using an out-of-the-box MediaWiki installation in the Amazon EC2 environment behind an Elastic Load Balancer and CloudFlare as a DNS provider, every user’s IP address will show as the load balancer’s IP address.  For obvious reasons, this is not ideal, but is easy to remedy.

First, add $wgUsedPrivateIPs = true; to your LocalSettings.php if not already present.

Then, the TrustedXFF MediaWiki extension needs to be installed, and the CloudFlare IP addresses should be added to the trusted-hosts.txt document.  The extension handles the IP range syntax used by CloudFlare, so a direct copy of the IPv4 text file is sufficient.  In addition, add your elastic load balancer IP address/range so that proxy will also be whitelisted.

Edit generate.php – find the location where a “Range too big” error could be thrown.  On the line above this, change the 8192 limit to 132192.  This will ensure all CloudFlare IP addresses are added.  If you run into performance problems later, start removing the lesser-used ISPs from the bottom of the trusted-hosts.txt document.

If your server is not live, add the require_once line to your LocalSettings.php.  Then, run the generate.php script that came with the extension.

If your server is live, you will need to specify the installation location on the command line (mediawiki_directory/cache/trusted-xff.cdb by default).

The generate.php file will create a database of IP addresses that will be used as trusted proxies.  Since you added CloudFlare’s IP addresses, you should now see the actual IP address of the user.

You may consider running generate.php periodically to receive updated IP addresses.

The procedure above allows you to get the actual IP address of the user without modifying core MediaWiki code, as the CloudFlare FAQ suggests.

Read More

Amazon Elastic Load Balancer on a root domain

Over the past few months, Hollow Developers has migrated servers into the Amazon EC2 environment. As part of this setup, a load balancer redirects traffic to a number of individual EC2 web server instances.  A limitation to this, however, is that Amazon’s load balancers don’t work on root domains (for example, http://hollowdevelopers.com/, no www in front).  The reason that these load balancers don’t work on root domains is because the DNS record must be a CNAME record, and not an A record.  And, root domains at most DNS providers only allow A records.

CNAME and A Records: CNAME entries allow domains to create subdomains like ‘webmail.hollowdevelopers.com’, which can act as an alternative address to something like ‘google.com/a/hollowdevelopers.com’ – the CNAME record makes that long URL at another domain easy to remember.  A records only allow IP addresses.  Amazon Load Balancers require an entry like ‘hollowdevelopers-load-balancer.ec2.amazon.com’, so a CNAME entry is required.

So, this ultimately requires websites to use ‘www’ or something similar in front of their domain, since the ‘www’ record can be a CNAME record.  As part of their sales pitch for their Route 53 DNS service, Amazon mentions that Route 53 allows you to place CNAME-type records into your root domain.  However, we have always been happy with our DNS provider, CloudFlare.  So, what is an easy way to ensure that all traffic goes through our load balancer?

On first glance, Hollow Developers was OK – our web servers automatically redirect users from the root domain to the www domain, primarily for consistency for search engine crawlers.  However, in order for this to happen, the user would have already hit our server on the root domain.  We wanted all traffic to go through the load balancer, regardless of the small number of hits that may come in through the root domain.  This is where CloudFlare’s page rules came in.

CloudFlare page rules allow website owners to write redirect rules, allowing all traffic from the root domain to redirect to the www domain.  Best of all, even free CloudFlare accounts allow a few page rules, meaning that anyone can use this trick for a free alternative to Amazon’s Route 53.  Just a few rules will get you up and running:

  • Forward http://hollowdevelopers.com/* to http://www.hollowdevelopers.com/$1
  • Forward http://hollowdevelopers.com/ to http://www.hollowdevelopers.com/

The first rule will forward all pages on the domain to the exact same page on www.  The second rule forwards the ‘naked’ root domain to the www domain.  For more information on the syntax used, consult the CloudFlare documentation on the Page Rules interface.

There are numerous alternatives to this approach – including the use of Amazon’s Route 53 DNS service.  However, we wanted to keep CloudFlare’s security and DDOS prevention features, so this was not an option we wanted to take.  Have other alternatives?  We would love to hear your comments/questions.

Read More

Cross-Region EC2 AMI Copy Comes to Amazon Web Services

Cloud GraphicThe recent shutdown of GoDaddy’s cloud product shows how hard it can be for even a well-funded cloud infrastructure start-up to compete against the behemoth that is Amazon Web Services (AWS). From the biggest names in tech (Netflix, Reddit) to some of the smallest, companies depend on AWS to power their cloud server infrastructure. However, even as Amazon dominates the market, they are not resting on their laurels, introducing new features and price drops nearly every week.

Amazon’s latest announcement is the ability to copy EC2 AMIs across different AWS regions, allowing server administrators to store these server images in different regions. Why is this important? Take the recent outage that took down Netflix and several other large websites. The outage affected Amazon’s US-East region, but many other regions exist across the world, and those regions were still online.

For the small guys that can’t afford a full sys ops team, keeping EC2 AMI images on standby in other regions can allow for a quick failover with minimal cost. You only pay for the size of your AMI images, and can bring servers online only if they are needed. (Databases are another story, and may require some multi-master replication strategies, but that’s another blog post.)

At Hollow Developers, our mission-critical applications are hosted on AWS with a hot backup waiting to go online at a separate hosting company in case of an AWS failure. As AWS offerings continue to increase as prices decrease, the choice of hosting the hot backup in a different AWS region is tempting.  For instance, it is much easier and cheaper to interact in one ecosystem rather than multiple. However, as rare as it may be, an entire ecosystem could get knocked offline/hacked/etc. As always, it will be interesting to watch the cloud infrastructure competitors duke it out over the next few years & hopefully provide even better solutions that can help websites experience the optimal 100% uptime.

Read More

GoDaddy Instant DataCenter vs. Rackspace Cloud Servers Part 2

Last year, we posted about GoDaddy’s alternative to Rackspace’s cloud servers.  We delivered a mixed verdict on both products, siding with GoDaddy primarily for price and ease of use, while Rackspace won the reputation, documentation, and API control.

Starting today, however, we can definitely recommend Rackspace over GoDaddy.  Not only for their SOPA stance, or hours-long outage a while ago, but due to the fact that they are shutting down the product.  It was a great step for beginners into the world of cloud computing, but it seems that their low price and tarnished reputation drove them out of the market.  In a memo that we received late last week, the company announced that Cloud Servers would be discontinued, giving customers until mid-April 2013 to move away from the platform.

As a rule, Hollow Developers always maintains our primary servers on one web host in one city, as well as backup servers on a different web host in a different city.  Every provider is going to experience downtime, and we want to make sure that we are always online.  Look forward to another host vs. Rackspace article in the near future, as we move our servers away from GoDaddy and find a new home.

Here is the bulk of GoDaddy’s memo to existing customers:

Go Daddy appreciates your business with us – we know you have many choices when choosing a business partner online. We continually strive to deliver you the best products and the best support in the industry. After careful review, we have decided that the best way to bring cloud hosting to our customers is by integrating it with our Web Hosting and Virtual Private Server products. As such, we will be discontinuing Cloud Servers as a stand-alone product.

We know you have invested your time building your business on top of our Cloud Servers product, and we want to work with you to take the next step. We will be giving our Cloud Server customers until April 15, 2013 to migrate their data and processes to a new platform.

Our customer care representatives will be reaching out to you over the next week to help you make this transition. We have several alternative products to meet your hosting needs, including:

• VPS (Virtual Private Servers) offer flexible capacity with guaranteed RAM and storage availability.

• Dedicated Server plans that give you your own lightning-fast processor, up to core i7, with up to 20TB of bandwidth.

• Go Daddy Web hosting is an option for those who need reliable hosting in a clustered, multi-server environment.

If you are still interested in GoDaddy, they still offer some products – find out more about their Dedicated Servers at GoDaddy.com.

Read More

Rackspace Cloud Load Balancing

At Hollow Developers, we use Rackspace Cloud for this website, and have started to move over our gaming and education websites to this host.  Today, they have announced public availability of their Rackspace Cloud Load Balancing API.  We have been waiting for this since November when they first announced a public beta, and are even more excited about what this means for our clients in the future.

What is Load Balancing?

Load balancing allows websites to split up the work of hosting pages and images to multiple machines.  Take a site like Amazon.  There’s no way that one server would be able to keep up with all those visitors!  So, Amazon tells some of its customers to use Server A, and some of its customers to use Server B (in reality, there’s probably thousands of machines at Amazon).

There are a few benefits to this.  First, with multiple machines, you have redundancy – your data is stored in multiple locations, and in case one server goes down, your website can still stay online.  Second, suppose one server is being overloaded with a very complex request.  With load balancing, the other server can pick up the slack until the resource-intensive task is complete.  Load balancing also allows you to take servers out of the rotation and perform maintenance, without bringing down your website.  The wikipedia article has a long list of other benefits.

Load Balancing For Small Businesses

In the past, load balancing has been out of reach for many small businesses.  If  your dedicated server that hosted your website went down, your customers would be met with a dreaded 404 page.  However, with load balancing coming soon to the Rackspace Cloud Control Panel, this is going to get much easier very soon.  Starting at $20/month, Rackspace’s solution is poised to be one of the first easy-to-use and inexpensive cloud load balancers.

Interested in getting your site on Rackspace Cloud?  Contact Hollow Developers for a consultation.

Read More