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

How Rackspace Can Turn It Around

Rackspace reported their first quarter earnings Wednesday, and the market did not like what it reported.  At market close Thursday, the stock had suffered nearly a 25% loss.  At the same time, there was some good news in that revenue is up 20%.

Hollow Developers has always been a great fan of Rackspace, and we use their cloud server products as our failover systems.  However, we were forced to other cloud server providers for our everyday hosting needs primarily due to cost.  Amazon Web Services (AWS) has the hefty weight of Amazon behind it, allowing AWS to adopt Amazon’s aggressive pricing models, undercutting prices of competitors by a fairly substantial margin.  There has always been a premium cost to do business with Rackspace, and this premium is definitely worth it for their ‘fanatical’ customer service.  However, there are some businesses that cannot afford that premium, or don’t depend on the customer service enough in order to rationalize paying the premium.  In our case, interaction with customer service is so limited that a monthly premium doesn’t make sense.

So, how does Rackspace turn things around?

First, place benchmarks on their cloud servers instead of relying on third-party websites to compare their CPUs against Amazon’s.  In our experience, AWS virtual machines don’t have the CPU horsepower that some would expect.  If Rackspace doesn’t exceed Amazon’s performance for comparably priced servers, bump up virtual machine resources until they do.  This metric is the most important for many websites that rely heavily on dynamic pages, and can become a deciding factor in choosing one service over another.  It is not immediately apparent that Rackspace’s entry-level server actually outperforms Amazon’s closest alternative when comparing CPU and price.

Second, allow more administrative actions to be performed via the Rackspace control panel.  A Scalr-like setup for auto-scaling and easier cross-region deployments would be a huge value-add to the product.  With Scalr running $100/month, some basic built-in scaling could be a deciding factor in using Rackspace versus a competitor.  Alternatively, partner with Scalr to provide some sort of discount to the service.  Rackspace customers already receive discounts at a number of other websites, and placing a cheaper Scalr monthly cost on to the table may be a deciding factor for those wanting to grow their cloud footprint.

Finally, take a page out of Amazon’s book and add a free or nearly-free tier to Cloud Servers.  Allowing people to sample the product, even for a few months, would invariably lead to some people remaining on the platform instead of seeking out competitors.  Pairing this with a Scalr partnership would make Rackspace that much more attractive.

Surely, there are other things that Rackspace could do to regain the confidence of investors, but these seem to be the most important among small businesses with small but expanding cloud footprints like ours.

* Disclaimer – Hollow Developers is a small investor, customer, and former affiliate of Rackspace.

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