Компания Rackspace и космическое агентство NASA анонсировали (http://openstack.org/press/rackspace-openstack-7-19-2010/) новый свободный проект OpenStack (http://www.openstack.org/community/), предназначенный для поддержания работы инфраструктуры cloud-вычислений. Созданный в рамках инициативы OpenStack код распространяется под лицензией Apache 2.0. Платформа нацелена на создание как публичных cloud-сервисов, подобных Amazon EC2, так и приватных (локальные) cloud-окружений, полностью подконтрольных и работающих только для обеспечения нужд компании.Предпосылкой к созданию проекта послужило отсутствие на рынке высокомасштабируемых открытых решений, способных обслуживать инфраструктуру виртуальных серверов больших хостинг-компаний, подобных Rackspace (100 тыс. виртуальных серверов клиентов). Пытаясь создать оптимальное для своих задач решение, компания Rackspace скооперировалось с агентством NASA, которое также пыталось создать средство для управления большими наборами данных и т...
URL: http://openstack.org/blog/
Новость: http://www.opennet.me/opennews/art.shtml?num=27370
Rackspace и NASA представили открытый стек для обеспечения работы cloud-инфраструктуры
------------
не cloud,а vps. Почувствуйте разницу (ц)
На сайте OpenStack про VPS ни слова, зато в каждом предложении упоминается cloud.cloud - это более широкое понятие, чем VPS. Грубо говоря cloud это куча серверов, на которых организуется работа VPS, при том, что эти сервера рассматриваются как нечто абстрактное, т.е. запущенный VPS плавает где-то в "облаке", а не на фиксированном сервере. По идее - это верный подход, когда не нужно заботиться о том как и где будет работать VPS, все само автоматически организуется и балансируется по требованиям к выделяемым VPS ресурсам. Если сгорит сервер, ничего страшного, VPS автоматом мигрирует на другой хост, пользователь даже не заметит миллисекунд простоя.
если сгорит сервер - пользователь еще как заметит :), если конечно нет дублирования памяти
>т.е. запущенный VPS плавает где-то в "облаке", а не на фиксированном сервереРаспространенное заблуждение. Выполняется, как раз, на одной ноде. Но, действительно, нет смысла узнавать, на какой ноде из пула.
cloud, на самом деле, другое. То, что Вы перечислили, это доступно на любом не low-cost VPS-сервисе с дисками на SAN. Cloud, в данном случае(Amazone) означает то, что VPS "резиновые" :)
Насколько VPS в облаке "резиновые"? Так понимаю больше одной ноды и ее ресурсов оно не займет? Или можно объединить ноды в облаке в один супер-vps?
Правильно понимаете, за исключением дисковой подсистемы, которая маштабируется гораздо лучше.
Только у дисковой есть свой недостаток: практически нигде не предоставляется регламентированное количество i/o, соотвественно, Вы их получаете столько, сколько получаете.
Эта проблема особенно касается дешевых VPS с локальной дисковой подсистемой(raid-массивом), хотя и для Amazone тоже характерна, и еще больше Xen/Hyper-V VPS на локальном raid, так как у них большой оверхед на i/o, и без SAN (а это уже совсем другая стоимость услуг VPS) Вы получаете просто очень медленную дисковую. В OVZ/PVC VPS с дисковой, если хостер не экономит, и не продает безвоздушные, неосязаемые мегагерцы (которые вечно будут в iowait) с SAS-дисками ситуация чуть по-лучше.Но вообще, непреодолимых технических препятствий сделать SMP на несколько машин, с учетом существования шины InfiniBand, нет. Только вот дешевые "резиновые" VPS сейчас на таком оборудовании, наверное, продавать нереально.
ScaleMP позволяет объединить нескольких серверов в один гораздо более мощный, с возможностью использования поверх него KVM и Xen. Правда решение проприетарное. http://blog.trinitygroup.ru/search/label/ScaleMP
Если останется чему мигрировать... Уж явно не миллисекунды. Не верю.
>Если останется чему мигрировать... Уж явно не миллисекунды. Не верю.Если общее хранилище, после смерти ноды обычно перезапускают VPS на новой. Даунтайм составляет:
1. Время реакции управляющего ПО кластера
2. "Подсечка" упавшей ноды (обычно, 1-2 секунды через UPS/IPMI), что бы с блокировками на кластерной ФС(clvm, и т д) разобраться
3. Время загрузки VPS с нуля. Эффект будет аналогичен нажатой кнопке "резет", и загрузке через несколько секунд на железном сервере. Данные будут актуальны, и не побьются при наличии журналируемой ФС, и лога базы данных.Так же есть решения у VmWare и для Xen, для того, что бы и ребута не было, так как память VPS дублируется на другие машины кластера (то есть, после небольшой паузы в обслуживании возобновляется работа), но это чревато очень большой деградацией производительности.
кошка, А Вы уже и в облачных вычислениях крутитесь?С.
>кошка, А Вы уже и в облачных вычислениях крутитесь?HA-доступность VPS для кластера нод под виртуализацию имеет весьма, имхо, отдаленное отношение к непосредственно "облакам".
Облака же, если продаются в виде VPS, на самом деле, ничем технически не отличаются от обычного кластера с виртуалками, только:
1. Тарифные планы не маркетойдные, а "резиновые"
2. Предоставляется API для управления своими заказнными параметрами тарифных планов
>HA-доступность VPS для кластера нод под виртуализацию имеет весьма, имхо, отдаленное отношение
>к непосредственно "облакам".
>
>Облака же, если продаются в виде VPS, на самом деле, ничем технически
>не отличаются от обычного кластера с виртуалками, только:
>
>1. Тарифные планы не маркетойдные, а "резиновые"
>2. Предоставляется API для управления своими заказнными параметрами тарифных плановвот, полностью поддерживаю. Панельку для VPS-ок выдавать за облако, это просто маркетинг уровнем чуть выше :)))
Рекомендую пройтись по всем OS-облакам или облакам с комунити лицензией. Я просмотрел их 12. Все они - менеджмент VPS. Да-да-да. Вы работаете с теми самыми VPS, у которых есть минимальные и максимальные MHz, GB и т.п.
Т.е. чтобы было так, что ставим на облако какую-либо считалку и она автоматом бы получала столько ресурсов, сколько ей надо в данный момент - ни одна система не предоставляет.Вот я и пишу, что облака эти - маркетинговые. И про миграции можете тут не писать. Если вы пользователю дадите ноду (VPS) в у неё "мама" откажет, дать ему другую проблем не будет. Проблемы начнутся, когда ему выделенных 500MHz не хватит.
>[оверквотинг удален]
>теми самыми VPS, у которых есть минимальные и максимальные MHz, GB
>и т.п.
>Т.е. чтобы было так, что ставим на облако какую-либо считалку и она
>автоматом бы получала столько ресурсов, сколько ей надо в данный момент
>- ни одна система не предоставляет.
>
>Вот я и пишу, что облака эти - маркетинговые. И про миграции
>можете тут не писать. Если вы пользователю дадите ноду (VPS) в
>у неё "мама" откажет, дать ему другую проблем не будет. Проблемы
>начнутся, когда ему выделенных 500MHz не хватит.Вообще-то можно технически просто не ставить верхий лимит на CPUusage, а продавать кванты времени CPU, они же приоритеты. "минимальные мегагерцы" это маркетинг, который не имеет, на самом деле, никакого отношения к тому, что Вы получаете технически.
выдача определенного количества квантов CPU без проблем делается в Xen и VZ (на котором, конечно, пока облаков особенно не видно, но, имхо, препятствий существенных нет, зато дисковое место будет дешевле)
Стоит понимать, что железная нода всегда прогружена на 70-80 процентов CPU (иначе предоставление сервиса невыгодно), поэтому есть смысл покупать больше (или меньше) CPU, а что касается обратной связи, это, извините, дело конечного пользователя.
Если не предоставляется API по изменению потребления ресурсов, это уже не облако. Если же оно предоставляется, за пол-часа пишется баш-скрипт, который вешается в крон, который будет определять то, как работают Apache, Postfix, телефония, CRM/ERP система, терминалка под Wine@etersoft, и т д, что используется на "облачном" VPS, а дальше этим скриптом можно брать автоматически нужные ресурсы.
Следует понимать, что VPS это и определенная отвесвенность: если у потенциального клиента облчных VPS нет опыта/знаний, то он его и настроить не сможет, ему нужно заказать услуги тех, кто поможет развернуть сервис в облаках, не только написать скрипты для реакции на нехватку ресурсов, но и для их "обрубления". Подумайте сами: ту же память ночью, например, для Апача без уменьшения скриптом же количества воркеров не уменьшишь, и так по дизайну самой идеи VPS (так как это "резиновый" VPS)
Вы не понимаете. Есть три основные задачи: хранилище (тут есть прогресс, причем железный и все довольны), БД, вэб/приложения (оба - мимо).Вот как вы эти кванты выделите, например, сайту с посещаемостью в 100к уников, если на сайт в какой-то момент времени зайдет 10к? А никак! С БД аналогично. Вы всегда упретесь в 1-4 проца, которые вы максимум можете выделить одной VPS. Т.е. опять те же самые распределенные системы, репликации и извраты программистов, делающие поддержку кода и решения довольно дорогим удовольствием.
Облако (в моем понимании) - это когда есть столько ресурсов, сколько необходимо приложению ___сейчас___, а не столько, сколько ему кто-то там сверху выделил, чем совершил очередную в своей жизни ошибку. Вот поэтому эти все "облака" и маркетинговые, по-крайней мере до тех пор, пока не появятся решения вроде гугловских, когда выделяются не кванты, а реальная туча, х.з. как устроенная, но не заставляющая приложения согласовываться из VPS через интернет/сеть с другими VPS.
>Вы не понимаете. Есть три основные задачи: хранилище (тут есть прогресс, причем
>железный и все довольны), БД, вэб/приложения (оба - мимо).
>
>Вот как вы эти кванты выделите, например, сайту с посещаемостью в 100к
>уников, если на сайт в какой-то момент времени зайдет 10к? А
>никак! С БД аналогично. Вы всегда упретесь в 1-4 проца, которые
>вы максимум можете выделить одной VPS.Вообще-то, люди на "железных" кластерах всегда стараются делать горизонтально маштабируемую систему.
Обычно, "облачные" VPS предоставляют API и для быстрого разворачивания новых нод. Так что, проблема надуманна: нужно просто строить изначально кластерную систему. Это же все-таки именно VPS=аналог железного сервера, а не нечто выдуманно-виртуальное, как у Google или MS.
Засчет этой специфики Вы получаете гораздо большую гибкость, ограниченную у того же мс или гугла, API.
Гибкость в чем? Я не знаю сколько мне GHz понадобится. Сейчас 1, через полчаса 10, завтра в праймтайм 100. Вы же предлагаете мне ноды фиксированной ограниченной мощности, без малейшего представления о том, сколько мне может потребоваться. А разбивать приложения и базы по нодам я могу и сам. И без вашего расфуфыренного "облака". Как заметили выше - чисто панелька управления нодами.
>Гибкость в чем? Я не знаю сколько мне GHz понадобится. Сейчас 1,
>через полчаса 10, завтра в праймтайм 100.Вот скриптом и разворачивайте типовые ноды :) В чем проблема-то? Когда не нужны, удаляйте.
> А разбивать приложения и базы по нодам я могу
>и сам. И без вашего расфуфыренного "облака".Вы не сможете ночью взять 1/1000 от железной ноды, а в прайм-тайм 30 железных нод. Облака, конечно, в большей степени маркетинг: раньше никто не додумывался строить продажи на гибких тарифных планах, не продавая конечному пользователю в нагрузку тот функционал, который он все равно не будет использовать.
Только что плохого в _этом_ маркетинге? Особенно, если в его рамках Вам не предоставляется псевдо-API к какому-то closed source кластеру с жестким вендор-локом, как GoogleApps или Azure?
> Как заметили выше -
>чисто панелька управления нодами.Фу, это пошло :) В панельку нужно тыкать мышкой, и это неудобно, в конце концов. А вот скрипт, который будет мониторить Ваши приложения, и их реальные потребности, и по ним заказывать через API новые ресурсы (или отказываться от старых) это реальность в том же Амазоне уже сейчас.