Как сделать бюджетный геокластерный хостинг

В качестве распределенного хостинга возьмем классический пример — создание блогосервиса на основе mu-Wordpress.
Задача — при ограниченном бюджете собрать отказоустойчивую (насколько это возможно) геораспределенную систему. Соответственно все оборудование берется в аредну в различных Дата-Центрах.
И тут следует сказать что не все Дата-Центры одинаково полезны. Высококачественные сдают сервер за 800$, а у низкокачественных вполне можно взять примерно такой же сервер в аренду уже за 100$. И именно эти особенности надо учитывать при создании геокластера.

Теперь о небольших хаках. По умолчанию в mu-Wordpress функция отдачи загружаемого контента сделана крайне неудачно — через PHP. Соответственно она была заменена на загрузку отдельным сервисом и вставкой загружаемого контента прямой ссылкой на статику.
Вторым хаком была модификация контроля кеширования. Кроме указаний кешировать статичные элементы дизайна был введен еще такой хак, который запрещал кешировать запись на время ее обсуждения (по умолчанию — 14 дней), а уже после она отдавалась с заголовком разрешающим кеширование. Кроме того хитро кешировались фиды RSS.
Финальным хаком стала система синхронизации БД — каждый INSERT/DELETE/UPDATE выполнялся на «соседе». Получился такой себе софт-рейд в контексте MySQL+PHP.



Сначала о DNS. Так как в mu-Wordpress использовался поддомен для каждого блога, то самым разумным решением было использовать услугу Slave DNS от двух независимых регистраторов — серые облака. Это недорого и вполне надежно.

Высококачественный Дата-Центр зеленого цвета, где арендуются два сервера использовался для первичных DNS, службы начальной регистрации и формы заливки загружаемого контента.
Два Дата-Центра среднего качества были использованы как основной «костяк» геокластера. Каждый сервер имел своего соседа и они синхронизировали межу собой всю информацию БД+файлы.

Таким образом удалось существенно сократить расходы уже на этом этапе. Однако через некоторое время произошла серьезная проблема, имя которой — поисковые боты.

Эти боты создавали на каждый сервер 200-300 одновременных соединений, что конечно ни к чему хорошему не приводило — начались таймауты и 50x ошибки. Конечно, можно было бы уменьшить число запросов через robots.txt опцией crawl-delay, но… кому охота чтоб его блог медленно индексировался?

И тут помогли дешевые желтые Дата-Центры + настройка мониторинга и DNS на двух серверах в зеленом Дата-Центре. Как это все работало:

Два желтых Дата-Центра функционировали как первичные (родительские) прокси squid. Остальные три использовали их как родительские, что снижало нагрузку на синий «костяк».
Мониторинг на серверах в зеленом Дата-Центре мониторил доступность желтых и синих, выполняя модификацию DNS в случае сбоя.

Теперь поговорим о отказоустойчивости. Что мы теряли при отключении зеленого, синего или желтого сегментов?

• Зеленый — регистрация и загрузка файлов
• Синий — в случае одного ничего, в случае всех — админка не работала + последние записи вне кеша не отображались.
• Желтый — в случае одного ничего, в случае всех — просто повышенная нагрузка на синие сервера

Таким образом удалось достичь максимальной доступности + сохранению блога в кеше прокси даже при его физическом удалении. Было и такое — один пользователь случайно удалил свой блог — и такая возможность предусмотрена. Вовремя обратившись в поддержку его записи были выдернуты из кеша, распарсены и влиты в вновь созданный блог.

P.S. По вопросам серверной оптимизации под mu-WordPress можете писать мне в комментарии — достаточно много собак было скушано под этим делом ;)