В качестве распределенного хостинга возьмем классический пример — создание блогосервиса на основе 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 можете писать мне в комментарии — достаточно много собак было скушано под этим делом ;)
Задача — при ограниченном бюджете собрать отказоустойчивую (насколько это возможно) геораспределенную систему. Соответственно все оборудование берется в аредну в различных Дата-Центрах.
И тут следует сказать что не все Дата-Центры одинаково полезны. Высококачественные сдают сервер за 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 можете писать мне в комментарии — достаточно много собак было скушано под этим делом ;)
