Как сделать облачный (кластерный) хостинг за пару копеек*

[Rolex]

Классический пример кластера c аппаратной избыточностью, но никак не облака. :)

[Andrey_Rogovsky]

Почему?
При необходимости несколько серверов будут работать как один, когда нагрузка спадет — все вернется как и было раньше.
Это ли не принцип облака?

[ikoev]

Five essential characteristics of cloud technology:
On-demand self-service
Broad network access
Resource pooling
Rapid elasticity
Measured service

[Andrey_Rogovsky]

Отмечаем по пунктам:
1) Создание/удаление виртуалок происходит автоматом? Да.
2) Это требует дополнительной расшифровки
3) Пул под виртуалки я делал? Делал.
4) Мониторинг по smb есть? Есть, хоть раз в секунду запускай.
5) Опять-же трафик считаем nginx, а дополнительные виртуалки — через скрипт их создания/удаления

Итого 4 из 5, причем один пункт требует расшифровки.

[leave]

4 — вы уверены, что правильно понимаете, что такое «Rapid elasticity»?

[Andrey_Rogovsky]

Более того, я даже не всегда понимаю, что такое «правильно», так как все относительно.
Так что — больше конкретики.

[leave]

Каким боком «мониторинг по smb» до «ресурсы по запросу — здесь и сейчас»?

[Andrey_Rogovsky]

Очень просто
Если мы видим, что на виртуалке большая нагрузка — делаем ее клон и распределяем нагрузку.

[twi]

On-demand self-service
захотелось — подрочил. Да.

[ikoev]

смешно, да ;)

по всем вышеприведенным терминам найдите определение и поймете, что вы немного другое сделали, а не облако ;)

[Andrey_Rogovsky]

Это облачный хостинг, а не просто облако, да.
Ну так я и писал про это в заголовке.

[IgorStepin]

Для пользователей виртуалок вполне облако: 150 виртуалок достаточно большое число, если хотя бы 20 свободны для динамического расширения, то для большинста LAMP-сайтов вполне хватит. Никто же не спорит, что Amazon EC2 — это облако? А тут еще и автоматическое масштабирование (там только ручное без сторонних сервисов или скриптов).

[egorF]

На EC2 уже оч. давно есть автоматическое масштабирвание, чуть ли не с самого начала. Это одна из важнейших фич EC2.

[braindamaged]

>> Результатом их работы стал так называемый API, который умел находить соседей широковещательным запросом, синхронизироваться до актуального состояния и информировать соседей о всех изменениях с базой.

Это как? Ручная репликация на php, что ли?

[Andrey_Rogovsky]

Да, именно она самая.

[mitnlag]

Именно поэтому данное решение стоит намного дешевле брендов. Бренд подходит для большого круга задач, а Ваше — только для конкретно этой.

[Andrey_Rogovsky]

Вполне, например — компилацию на нем не ускорить, OCR тоже.
Для хостинга — вполне себе решение.

[braindamaged]

И сколько у вас инстансов БД? И каждый DML/SML запускается по очереди на каждой БД?
Я чего-то не понял, видимо…

[Andrey_Rogovsky]

Каждая виртуалка содержит в себе копию БД и всегда синхронизируется с остальными.
Выделенные виртуалки под БД разработчики не захотели использовать.

[braindamaged]

А как вы тогда выцепляете запросы, которые внутри выполняются, и отправляете их на другие виртуалки?

[Andrey_Rogovsky]

Это решали разработчики, правя код. Как я и говорил — надо использовать MySQL-Proxy+Lua, и тогда все это будет работать нативно без правок кода.

[Goodkat]

Распишите подробней про синхронизацию данных, от скриптов до БД.

[Andrey_Rogovsky]

Синхронизация данных на файловом уровне:
lvcreate -L 10G -s -n instance01 /dev/volgroup/instance01template

Синхронизация БД — скрипт на php, у меня он не сохранился. Логика очень простая: Если идет запрос на изменение данных, то он выполняется на всех клонах виртуалки.

Будут более конкретные вопросы — будут более подробные ответы.

[Tonik]

Такое решение синхронизации БД конечно говорит не в пользу разработчиков. :) Мне кажется проще было изучить Lua чем городить такой велосипед. Но это явно вопрос не к вам.

Спасибо большое за статью — вы дали пару очень интересных идей. И показали что «облако» это просто :)

Скажите, а что делалось если причиной нагрузки был сам код? ну скажем с новым релизом кто в коде делал интенсивную работу с диском. получается что такое приложение забивало все свободные «слоты» под виртуалки?

[Andrey_Rogovsky]

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

[Goodkat]

ну вот загружает пользователь фоточку, как она синхронизируется по разным машинам?
или генерирует скрипт pdf-документ, делает запись в БД, кладёт файлик в папку /download, как этот файлик раскидывается по виртуалкам?

[Andrey_Rogovsky]

С помощью этого, а крутилось все на паре виртуалок и синхронизировалось через rsync

[Andrey_Rogovsky]

I/O всегда есть узкое место

[black_crown]

Хорошо, что еще есть люди на этой планете, которые пишут сноски (*) такого же размера шрифта, как и основной текст))

[bondbig]

вижу слова «облачный» и «виртуализация» — кастую amarao в тред.
Автору спасибо за статью, полезная, ушла в избранное. После долгого отсутствия, Андрей Роговский вернулся и начал снова писать нормальные технические статьи а не оффтопик про политику и мозг.

[zeehond]

занятно, но на cloud не тянет никак

внедрённое и поддерживаемое нами рабочее HA/LB решение для LAMP-хостинга (не претендуя на громкое слово cloud) выглядело так

фронтенд:
2 мастер-хоста веб-фронтенд — DRBD active-active репликация
для избежания split brain, разумеется, fencing
N (в перспективе до бесконечности) вторичных хостов веб-фронтенда — реплицируются с мастеров rsync-ом
все изменения делаются на любом из мастер-хостов, далее сами расползаются по кластеру

DNS-round-robin load balancing — дешёво и сердито
IP адрес внезапно умершей ноды перехватывает соседняя по кластеру нода
пользовательские сессии реплицируются по кластеру через memcache

база данных:
1 активный мастер MySQL
1 спящий мастер, репликация файловой системы DRBD active -> passive на несмонтированный раздел
при умирании активного мастера спящий просыпается, перехватывает IP активного на себя, монтирует раздел, поднимает серверный процесс
ну и N (опять же до бесконечности) слейвов, которые реплицируются с мастеров

доступ PHP-кода через базу работает через класс, который все INSERT/UPDATE/DELETE гонит на мастера, все SELECT — на слейвов (случайно выбирая ноду)

HA выполняется полностью — при отказе _любой_ ноды система работает как ни в чём ни бывало, т.е. no single point of failure
LB выполняется везде, за исключением MySQL-мастера — но он со своими 32 гигами, 4х4 головыми Xeon-ами и SAS-дисками старается вовсю

в дальнейшем были сделаны некоторые улучшения, типа frontend-ноды берут весь контент не с локального диска, а с файлового сервера из двух связанных по infiniband NAS-серверов с DRBD active-active, добавлены сервера для кэширования и отдачи статического контента

в среднем всё это вместе держит нагрузку в 200-300, местами до 1000, запросов страниц в секунду

[Tonik]

Тоже интересный вариант. А можно подробней при помощи чего именно перехватывались IP умирающих машин?

[Andrey_Rogovsky]

Это я тоже делал в свое время, немного иначе правда. Даже презентация на видео есть :)

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

[Andrey_Rogovsky]

Как давно это было?

[AccessD]

А присутствует ли в вашем «облаке» присущая облакам гибкость по распределению ресурсов?

[Andrey_Rogovsky]

Смотря что считать за ресурс.
У меня он был один — это трафик, точнее его обработка.

[AccessD]

На отечественном хостинге трафик как раз не ресурс. Куда важнее предоставляемые мощности и место. Облако подразумевает, что вы получаете именно столько, сколько вам надо и вы имеете возможность управлять полученными ресурсами, наращивая и снижая их по мере необходимости.

[Andrey_Rogovsky]

Трафик — это ресурс. Это посетители, которые приносят доход.
Про то, как выделялись ресурсы по необходимости — я уже написал.

[AccessD]

Это ресурс с точки зрения бизнес-модели, а сейчас речь о ресурсах этой карусели как платформы. И в данном случае трафик не в счёт, потому что в нормальных местах вы за него не платите при соблюдении определённого отношения отданного к принятому. Так что ваш кластер называть облаком, ИМХО, несколько некорректно, ибо тут нет той гибкости, которая подразумевается облаками.

[Andrey_Rogovsky]

И какой конкретно гибкости нехватает?

[professor_kuvalda]

> На заполнение стойки хватит суммы с четырьмя нулями

за 100,00 рублей что ли?

[Andrey_Rogovsky]

Нет, блин, за 10 000 зимбабвийских фантиков.

[LIAL]

копейки в нули не считаются
Думаю человек имел ввиду 10к$

[FreeLSD]

Роговский — профессиональный IT тролль.
Кластер с избыточностью можно сделать на связке XEN+DRBD+LustreFS используя Live Migration, но у меня эти Xen с Lustre так и не заработал

[Andrey_Rogovsky]

Как я и писал выше — у меня был выбор OVZ/XEN.

[phasma]

Во-первых, есть еще kvm. Во-вторых, есть уже готовый дистрибутив Proxmox, очень удобный для разворачивания виртуалок

[Andrey_Rogovsky]

Значит три года назад этого еще небыло или было в нестабильном состоянии.

[schors]

Я только не понял одного — а зачем ты это всё сделал? Практиковался в написании скриптов удалённого вызова команд? Какую задачу ты решил, какую нельзя было бы решить отрезав вот этот лишний слой абстракции с поднятием/опусканием VDS? Где сравнительная характеристика «до» и «после» и резюме «позволило»?

[sply]

основная задача — меньше работат руками, быстрее стартовать/останавливать инстансы

[schors]

А прости, зачем их стартовать/запускать? :) Что в данном примере выигранно? Цена этой статьи:
ssh host su root -c 'start/stop'? :)

[sply]

Вот это я не знаю, из статьи тоже не понятно, мутно как-то. Мне другое еще не понятно — зачем сначала нарезать физическую машину на мелкие вдски и потом запускать много мелких инстансов этих вдс — тут огромная потеря производительности впустую. Ладно бы если продавали каждый инстанс как амазон. Но ведь просто сайты хостились. Может быть и правда, чисто из-за красоты идеи.

[schors]

Я это собственно и хотел сказать :)

[Andrey_Rogovsky]

Потому что проектов было больше, чем физических серверов. Это раз.
У проектов были свои требования к софту — кому-то первый апач, кому-то второй, про PHP я вообще молчу. Это два.

[Andrey_Rogovsky]

Затем, что при большой нагрузке на один сайт работало 2-5 серверов одновременно. Причем полностью автоматически.
До этого один сайт на одном сервере смог обрабатывать 1000 паралельных запросов, после сайт выдерживал 5000 паралельных запросов.

[happybyte]

Странная цена на стойку с шестью нолями. Бренды как-то в последнее время сильно подешевели. В 4 ноля можно вложиться. Просто первая цифра не 1.

[Andrey_Rogovsky]

Цены 3-х летней давности. Сколько сейчас стоит набить стойку — не считал.

[stanly]

Андрей, а каким образом Вы определяли, на какой HN какой VE создавать?
Допустим (исходя из описания задачи), все HN имели одинаковую конфигурацию — CPU/MEM/HDD (если имели разную, мой вопрос усложняется).
Каким образом осуществлялся мониторинг overuse ресурсов на каждой HN, чтобы (не дай Бог) на определённой HN не создалось N к-во VE, которые суммарно превышали бы возможности самой HN? ;)

PS: сокращения HN и VE взяты сугубо согласно документации OpenVZ, чтобы большинство читателей при надобности могли бы вникнуть в суть вопроса.
(если называть их общепринятыми среди админов именами, я бы выразился иначе)

[Andrey_Rogovsky]

Это определял не я а скрипты, по состоянию наименьшего LA на HN.
Оверюза небыло — в скрипте были забиты лимиты VE на HN.

[Andrey_Rogovsky]

Хранить в mysql