Reclaiming WordPress Multisite

Lauren Brumfield already announced that we’re officially rolling out WordPress Multisite (WPMS) hosting at Reclaim. What’s more, she created an online calculator that provides transparent pricing going forward, which is a big part of why we’re finally announcing something we have done for years. While we’ve been pretty laser-focused on shared hosting and Domain of One’s Own for the last four years, we’ve still picked up more than a few WPMS instances. In fact, we jumped in at the deep-end of the pool when we started hosting the colossus that is VCU’s Rampages. As a result Tim was able to really fine-tune high demand WPMS environments like Rampages, and we’re in a situation where we can comfortably manage just about anything out there in higher ed.

It’s fun for me because I cut my teeth on WordPress Multiuser (even before it was multisite), and when Tim came onboard at UMW the first thing we asked him was how he felt about managing UMW Blogs. The rest is Reclaim history, he proved an insanely quick study and went from UMW Blogs to Hippie Hosting to Domain of One’s Own to Reclaim Hosting in two short years. That’s a resume!

back to the future, we really weren’t comfortable with announcing WPMS at Reclaim too early because we were experimenting with different setups across various data centers like AWS, Linode, and Digital Ocean, so things were always custom based on several factors which meant the pricing varied. But when Digital Ocean recently announced their new plans and pricing model, we were sure we had a solid setup through Digital Ocean that would allow us to stabilize our WPMS offerings as well as making them extremely competitive when it comes to pricing.

Before we could announce anything we had to reach out to all existing customers we and let them know of the new setup, for many of them this meant a significant savings. Once took care of that, we figured it was high time to officially announce that we are in the WPMS hosting business. So if you have a WPMS site you want to offload to external hosting, let’s talk. Pricing is simple: server, backups, and software licensing (Bitninja, cPanel, etc) at cost, whereas our monthly maintenance and management fees starts at $250 per month. This model finally allows us to decouple server and software costs from management demands, and establishes a baseline for what our time is worth to ensure you get the service we’re known for. It also makes clear that what you pay us for is not the hardware or software, but the peace of mind that tried and true experts are on the job. I mean let’s be honest here, this isn’t some hack outfit working from a ramshackle UMW office in duPont Hall trying to duct tape together some kind of chitty-chitty-bang-bang syndication solution, we’re professionals—and for that you must pay!

Installing and Customizing a Scalable WordPress Multisite with Linode’s StackScripts

I’ve been on a server admin crash course over the last 8 months or so, and I’ve been thoroughly enjoying myself. I have been fortunate to have the most patient and generous teacher I’ve ever studied under: the great Tim Owens. I truly have a deep respect for how much he has taught himself over the last 4 years, and trying to catch up with him gives me an even deeper appreciation of his mad skills. One of the turning points for Reclaim Hosting this semester has been taking on large-scale WordPress Multisite instances for institutions. We jumped in with both feet when we took over the hosting of VCU’s Ram Pages—a beast I have written about recently. Tim did a brilliant job scaling this extremely resource intensive WordPress Multisite, and I was eager to try my hand at the setup. Luckily Reclaim has no shortage of opportunities, and recently the University of North Carolina, Asheville was interested in experimenting with a pilot of WordPress Multisite, so I got my chance to work through the setup with a brand new install. Continue reading "Installing and Customizing a Scalable WordPress Multisite with Linode’s StackScripts"

Hosting VCU’s Ram Pages

Reclaim Hosting has been hosting VCU’s Ram Pages as of the beginning of the Spring semester. It reinforces for me there is nothing Tim Owens can’t do, another yet another example of the powerful ripple effects of #ds106 on edtech. We’ve been loath to proclaim victory too soon given what a beast Ram Pages is. And I thought we had a blogging revolution at UMW! In two short years Ram Pages has been home to over 16,000 blogs for 15,500 users. That’s nothing short of mind boggling. Tom Woodward—in his quiet, self-defacing way—has built and managed a blog empire at VCU’s ALT Lab, and over the last 6-8 months Tim and I have been trying to figure out how the hell we would migrate it cleanly given it can grow at intervals of 1000 users any given week.

Hosting VCU’s Ram Pages

We (royal for Tim) moved it over Christmas vacation on to a beefy Linode instance running Ubuntu, Varnish, and Nginx after sharding the database to 256. Yesterday we finally got the second backup solution working, which in addition to nightly snapshots we now have file-level, off-site backups through R1Soft Licenses (more on that in another post). This may be one of the largest, most active academic blogging systems in higher ed, and it is a real source of pride that we’re hosting it. And I saying this knowing full-well it is a total jinx [crosses fingers]….it’s been rock solid so far. Don’t ever question the power of Reclaiming!

Abstractions: Running WordPress Multi-Site using AWS, Docker, and BTSync

Heads up: this is not a technical run through, but more of a conceptual overview. Apologies if you came here looking for a how-to. Hopefully we will have just that in the next few months.

But enough about the past, let’s talk about the future!

aws_wpms_setup

This past week Tim Owens and I went down to VCU’s ALT Lab to meet with Tom Woodward, Jon Becker, and Mark Luetke about the work they’re doing with Ram Pages. I already blogged about a couple of plugins they created for making syndication-based course sites dead simple. We also got to talking about some of the ways we have been using Amazon Web Services (AWS)to scale UMW Blogs. At this point Tim took us to school on the whiteboard explaining a possible setup he has been imagining, which is still fairly experimental.

Don’t let Tim fool you, he is DevOps #4life now. He can be found in his spare time watching presentations about load balancing a site for a billion users or scaling infrastructure for small services like Netflix. I’m becoming more and more interested in infrastructure discussions because they highlight interesting trends in the shifting nature of tech that deeply effects edtech, such as virtualization, containers, and APIs.

image

Anyway, the image above is a look at a potential setup for a large WordPress Multisite instance on AWS. It has a couple of elements worth discussing in some detail because I want to try and get my head around each of them. The first is a load balancer that runs in its own EC2 instance.

loadbalancer

What the load balancer does is direct traffic to the Ec2 instance running the WordPress core files with the least load. So if you have four EC2 instances each running WordPress’s core files, the one with the least usage get the next request. Additionally, if all the instances have too great a load another could, theoretically, be spun up to meet the demand. That’s one of the core ideas behind elastic computing. The load balancer Tim used for UMW Blogs was HAProxy.

image

As mentioned above, you can setup a series of instances of EC2 on AWS with the core WordPress files save the wp-content directory, which is the only directory folks write to. But you will notice in the fourth instances Tim switched things up. He suggested here that we could have an EC2 instance running Docker that could then run several WordPress instances within it. What’s the difference? And this is where I am still struggling a bit, but from what I understand this allows you to spin up new instances quicker, isolate instances from each other for more security, and upgrade and switch out instances seamlessly. It effectively makes WordPress upgrades in a large environment trivial.

image

We have yet another EC2 instance that is the Network File Storage, this holds the wp-content files. The uploads, plugins, themes, upgrades, etc.  And each of the above instances share this instance. The all write to this, but one of the issues here is that this can be a single point of failure, kinda like the load balancer. So, Tim suggested there is BitTorrent Sync (BTSync), which I still don’t totally understand but sounds awesome. It’s basically technology that synchs files from your computer to spot on the internet, or between spaces in the internet, etc. So, what if we had several bucket where the various instances of WordPress core files were writing the upload files, themes, plugins, etc, and those buckets used BTSync to share between them almost immediately. So then you wouldn’t have a single point of failure, you would have the various instances writing to various buckets of files that would be constantly synching using the technology behind BitTorrent. Far out, right?

btsynch
BTSync provide ability to immediately copy and synch files across several buckets of the same files that get written to regularly.

Another option, and I think this was before we started talking about BTSync, but not sure if this would be in possible in addition to BTync, is have the blogs.dir folder for a WordPress Multisite that handle all the individual site files uploaded be sent to S3, Amazon’s file storage service.

image

You get the sense that part of what’s happening when you move an application like WordPress Multisite onto AWS, or some other cloud-based, virtualized server environment, is each element is abstracted out to it basic functions. Core files that are read-only are separate from anything that is written to, whether that be themes, plugins, or uploads. Additionally, the database is also abstracted out, and you can run an EC2 instance on AWS with Docker containers each running MySQL (with a sharDB or HyberDB to further break up load) that can also replicate various writes and calls using BTSync? No single point of failure, and you greatly reduce the load on a WPMS which is completely I’m out of my depth here, but if I I accomplished anything here it might be giving you an insight to my confusion, which is also my excitement about figuring out the possibilities.

imageI have no idea if this makes sense, and I would really love any feedback from anyone who knows what they are talking about because I’m admittedly writing this to try and understand it. Regardless, it was pretty awesome hearing Tim lay it out because it certainly provides a pretty impressive solution to running large, resource intensive WordPress Multisite instance.