Apis Networks

Building Your Next Hosting Platform

Hey folks,

We’re hard at work building the next generation hosting platform to migrate all clients (including those on Apollo) within the next few months. I want to let you know what features everyone will have access to, what is changing, and what is improving.

First, our platform will be built using filesystem layering introduced in the Apollo platform. This has exceeded our expectations to provide clients with easy access to system updates to make sure your accounts are secure. Best of all, we have yet to encounter performance limitations – in fact, performance is 4x better than our older server fleet introduced in 2007. Performance will improve even more in the coming months with Helios.

Helios is built around Redhat Enterprise Linux 6.2, stuffed with some of the most recent software, including: Linux kernel 3.2bash 4, MySQL 5.5, and Apache 2.4. We have selected this software to provide clients with the most efficient shared hosting environment achievable. Your sites will continue to work the same, but be faster. Our storage platform will also make use of a 6x 15k SAS array in a RAID 1+0 configuration. IO throughput is approximately 2.8x faster than before. Learning from past mistakes, the OS will finally be 64-bit. This decision comes after experimentation on Apollo, specifically mapping high memory segments into low memory, which is slow and quite limited as we continue to make generous use of RAM to improve cache responsiveness of HTTP and MySQL.

Our patches that unify every service, like e-mail and FTP, into our account lookups are being rewritten to make use of the latest software too. Software like Dovecot 2.1, victim of a major API overhaul since 1.3, require more cautious planning to ensure our new patches work identical to our present setup. These patches take some time to write and adequately test.

Helios should be ready in time for this Summer. Let me know if you have any feature requests or questions pertaining software changes on Helios. Until then, look forward to more postings as we draw closer to finalizing the next big leap in hosting.

` Matt

Comments

 

Dec 22: Apollo CPU upgrade, Borel hardware maintenance

Apollo and Borel will undergo hardware changes on Thursday, December 22 at 12 AM EST (-0500 GMT). Servers will be down for ~20 minutes each to make changes.

Apollo will receive a dual-core to quad-core upgrade to further assess our new hosting platform capabilities. Apollo has in extreme situations become CPU bound – exceeding the processing capabilities of its current dual-core arrangement. Processor speed will be upgraded from 2x 2 GHz dual-core Xeon processors to 2x 3 GHz quad-core Xeon processors.

Borel has been reporting SCSI I/O timeouts despite disk consistency checks passing. This behavior is typical of a faulty backplane cable that will be replaced on Thursday.

Comments off

 

Apollo Kernel v3.1 Upgrade 11/17, Filesystem Improvements

Apollo will undergo a kernel upgrade on Thursday at 12 AM EST (-0500 GMT) to improve filesystem performance. After local testing, we are pleased to announce that Apollo will continue to provide an innovative hosting platform by using v3 of the Linux kernel. v3 introduces several optimizations and stability improvements over v2.6.35 released in August 2010 that has been used on Apollo since last year.

During this time too, aufs, which provides our filesystem technology will undergo a couple changes. First, direct branch access detection will be disabled to reduce time taken to access a file on a client’s writeable branch. Second, path traversal calculations have been traditionally calculated within the kernel-space instead of user-space to resolve crashes inside directories containing a large number of inodes. Since deploying Apollo in 2009, this problem is no longer reproducible.

This outage is expected to last 30 – 45 minutes during which time the proposed changes will be verified to ensure no complications arise. Maintenance should conclude around 1 AM EST after which time load averages will be monitored to ensure I/O wait spikes dissipate that occur as aufs’ cache is filled then expunged in v2.6.35.

Comments (1)