Comments 64
Классический пример кластера c аппаратной избыточностью, но никак не облака. :)
Почему?
При необходимости несколько серверов будут работать как один, когда нагрузка спадет — все вернется как и было раньше.
Это ли не принцип облака?
При необходимости несколько серверов будут работать как один, когда нагрузка спадет — все вернется как и было раньше.
Это ли не принцип облака?
Five essential characteristics of cloud technology:
On-demand self-service
Broad network access
Resource pooling
Rapid elasticity
Measured service
On-demand self-service
Broad network access
Resource pooling
Rapid elasticity
Measured service
Отмечаем по пунктам:
1) Создание/удаление виртуалок происходит автоматом? Да.
2) Это требует дополнительной расшифровки
3) Пул под виртуалки я делал? Делал.
4) Мониторинг по smb есть? Есть, хоть раз в секунду запускай.
5) Опять-же трафик считаем nginx, а дополнительные виртуалки — через скрипт их создания/удаления
Итого 4 из 5, причем один пункт требует расшифровки.
1) Создание/удаление виртуалок происходит автоматом? Да.
2) Это требует дополнительной расшифровки
3) Пул под виртуалки я делал? Делал.
4) Мониторинг по smb есть? Есть, хоть раз в секунду запускай.
5) Опять-же трафик считаем nginx, а дополнительные виртуалки — через скрипт их создания/удаления
Итого 4 из 5, причем один пункт требует расшифровки.
Для пользователей виртуалок вполне облако: 150 виртуалок достаточно большое число, если хотя бы 20 свободны для динамического расширения, то для большинста LAMP-сайтов вполне хватит. Никто же не спорит, что Amazon EC2 — это облако? А тут еще и автоматическое масштабирование (там только ручное без сторонних сервисов или скриптов).
>> Результатом их работы стал так называемый API, который умел находить соседей широковещательным запросом, синхронизироваться до актуального состояния и информировать соседей о всех изменениях с базой.
Это как? Ручная репликация на php, что ли?
Это как? Ручная репликация на php, что ли?
Да, именно она самая.
Именно поэтому данное решение стоит намного дешевле брендов. Бренд подходит для большого круга задач, а Ваше — только для конкретно этой.
И сколько у вас инстансов БД? И каждый DML/SML запускается по очереди на каждой БД?
Я чего-то не понял, видимо…
Я чего-то не понял, видимо…
Распишите подробней про синхронизацию данных, от скриптов до БД.
Синхронизация данных на файловом уровне:
lvcreate -L 10G -s -n instance01 /dev/volgroup/instance01template
Синхронизация БД — скрипт на php, у меня он не сохранился. Логика очень простая: Если идет запрос на изменение данных, то он выполняется на всех клонах виртуалки.
Будут более конкретные вопросы — будут более подробные ответы.
lvcreate -L 10G -s -n instance01 /dev/volgroup/instance01template
Синхронизация БД — скрипт на php, у меня он не сохранился. Логика очень простая: Если идет запрос на изменение данных, то он выполняется на всех клонах виртуалки.
Будут более конкретные вопросы — будут более подробные ответы.
Такое решение синхронизации БД конечно говорит не в пользу разработчиков. :) Мне кажется проще было изучить Lua чем городить такой велосипед. Но это явно вопрос не к вам.
Спасибо большое за статью — вы дали пару очень интересных идей. И показали что «облако» это просто :)
Скажите, а что делалось если причиной нагрузки был сам код? ну скажем с новым релизом кто в коде делал интенсивную работу с диском. получается что такое приложение забивало все свободные «слоты» под виртуалки?
Спасибо большое за статью — вы дали пару очень интересных идей. И показали что «облако» это просто :)
Скажите, а что делалось если причиной нагрузки был сам код? ну скажем с новым релизом кто в коде делал интенсивную работу с диском. получается что такое приложение забивало все свободные «слоты» под виртуалки?
ну вот загружает пользователь фоточку, как она синхронизируется по разным машинам?
или генерирует скрипт pdf-документ, делает запись в БД, кладёт файлик в папку /download, как этот файлик раскидывается по виртуалкам?
или генерирует скрипт pdf-документ, делает запись в БД, кладёт файлик в папку /download, как этот файлик раскидывается по виртуалкам?
С помощью этого, а крутилось все на паре виртуалок и синхронизировалось через rsync
Хорошо, что еще есть люди на этой планете, которые пишут сноски (*) такого же размера шрифта, как и основной текст))
вижу слова «облачный» и «виртуализация» — кастую amarao в тред.
Автору спасибо за статью, полезная, ушла в избранное. После долгого отсутствия, Андрей Роговский вернулся и начал снова писать нормальные технические статьи а не оффтопик про политику и мозг.
Автору спасибо за статью, полезная, ушла в избранное. После долгого отсутствия, Андрей Роговский вернулся и начал снова писать нормальные технические статьи а не оффтопик про политику и мозг.
занятно, но на 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, запросов страниц в секунду
внедрённое и поддерживаемое нами рабочее 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, запросов страниц в секунду
Тоже интересный вариант. А можно подробней при помощи чего именно перехватывались IP умирающих машин?
Это я тоже делал в свое время, немного иначе правда. Даже презентация на видео есть :)
Тут ведь дело в том, что у меня сайты — не клиентские а корпоративные, и у каждого разработчика свои требования по версиям софта, так что без виртуалок не обойтись.
Тут ведь дело в том, что у меня сайты — не клиентские а корпоративные, и у каждого разработчика свои требования по версиям софта, так что без виртуалок не обойтись.
А присутствует ли в вашем «облаке» присущая облакам гибкость по распределению ресурсов?
Смотря что считать за ресурс.
У меня он был один — это трафик, точнее его обработка.
У меня он был один — это трафик, точнее его обработка.
На отечественном хостинге трафик как раз не ресурс. Куда важнее предоставляемые мощности и место. Облако подразумевает, что вы получаете именно столько, сколько вам надо и вы имеете возможность управлять полученными ресурсами, наращивая и снижая их по мере необходимости.
Трафик — это ресурс. Это посетители, которые приносят доход.
Про то, как выделялись ресурсы по необходимости — я уже написал.
Про то, как выделялись ресурсы по необходимости — я уже написал.
Это ресурс с точки зрения бизнес-модели, а сейчас речь о ресурсах этой карусели как платформы. И в данном случае трафик не в счёт, потому что в нормальных местах вы за него не платите при соблюдении определённого отношения отданного к принятому. Так что ваш кластер называть облаком, ИМХО, несколько некорректно, ибо тут нет той гибкости, которая подразумевается облаками.
> На заполнение стойки хватит суммы с четырьмя нулями
за 100,00 рублей что ли?
за 100,00 рублей что ли?
копейки в нули не считаются
Думаю человек имел ввиду 10к$
Думаю человек имел ввиду 10к$
Роговский — профессиональный IT тролль.
Кластер с избыточностью можно сделать на связке XEN+DRBD+LustreFS используя Live Migration, но у меня эти Xen с Lustre так и не заработал
Кластер с избыточностью можно сделать на связке XEN+DRBD+LustreFS используя Live Migration, но у меня эти Xen с Lustre так и не заработал
Во-первых, есть еще kvm. Во-вторых, есть уже готовый дистрибутив Proxmox, очень удобный для разворачивания виртуалок
Я только не понял одного — а зачем ты это всё сделал? Практиковался в написании скриптов удалённого вызова команд? Какую задачу ты решил, какую нельзя было бы решить отрезав вот этот лишний слой абстракции с поднятием/опусканием VDS? Где сравнительная характеристика «до» и «после» и резюме «позволило»?
основная задача — меньше работат руками, быстрее стартовать/останавливать инстансы
А прости, зачем их стартовать/запускать? :) Что в данном примере выигранно? Цена этой статьи:
ssh host su root -c 'start/stop'? :)
ssh host su root -c 'start/stop'? :)
Вот это я не знаю, из статьи тоже не понятно, мутно как-то. Мне другое еще не понятно — зачем сначала нарезать физическую машину на мелкие вдски и потом запускать много мелких инстансов этих вдс — тут огромная потеря производительности впустую. Ладно бы если продавали каждый инстанс как амазон. Но ведь просто сайты хостились. Может быть и правда, чисто из-за красоты идеи.
Затем, что при большой нагрузке на один сайт работало 2-5 серверов одновременно. Причем полностью автоматически.
До этого один сайт на одном сервере смог обрабатывать 1000 паралельных запросов, после сайт выдерживал 5000 паралельных запросов.
До этого один сайт на одном сервере смог обрабатывать 1000 паралельных запросов, после сайт выдерживал 5000 паралельных запросов.
Странная цена на стойку с шестью нолями. Бренды как-то в последнее время сильно подешевели. В 4 ноля можно вложиться. Просто первая цифра не 1.
Андрей, а каким образом Вы определяли, на какой HN какой VE создавать?
Допустим (исходя из описания задачи), все HN имели одинаковую конфигурацию — CPU/MEM/HDD (если имели разную, мой вопрос усложняется).
Каким образом осуществлялся мониторинг overuse ресурсов на каждой HN, чтобы (не дай Бог) на определённой HN не создалось N к-во VE, которые суммарно превышали бы возможности самой HN? ;)
PS: сокращения HN и VE взяты сугубо согласно документации OpenVZ, чтобы большинство читателей при надобности могли бы вникнуть в суть вопроса.
(если называть их общепринятыми среди админов именами, я бы выразился иначе)
Допустим (исходя из описания задачи), все HN имели одинаковую конфигурацию — CPU/MEM/HDD (если имели разную, мой вопрос усложняется).
Каким образом осуществлялся мониторинг overuse ресурсов на каждой HN, чтобы (не дай Бог) на определённой HN не создалось N к-во VE, которые суммарно превышали бы возможности самой HN? ;)
PS: сокращения HN и VE взяты сугубо согласно документации OpenVZ, чтобы большинство читателей при надобности могли бы вникнуть в суть вопроса.
(если называть их общепринятыми среди админов именами, я бы выразился иначе)
Sign up to leave a comment.
Как сделать облачный (кластерный) хостинг за пару копеек*