Проект Debian подчеркнул (http://www.debian.org/News/2012/20120425) опасности, связанные с развёртыванием систем во внешних облачных сервисах. Так как инфраструктура, обеспечивающая выполнение виртуальных машин, в таких сервисах обслуживается сторонней компанией и неподконтрольна клиенту, не исключена угроза утечки данных. Например, пользователь не может контролировать обеспечение безопасности и своевременное применение обновлений для управляющей инфраструктуры, а также не может поручиться в порядочности сотрудников компании, владеющей облачным сервисом.
В связи с этим проект Debian призывает развёртывать облачные системы на собственных локальных мощностях, полностью подконтрольных предприятию. Для упрощения развёртывания собственных облачных инфраструктур в состав будущего релиза Debian 7.0 "Wheezy" будут включены пакеты, позволяющие с минимальными затратами установить и настроить системы на базе платформ OpenStack (https://www.opennet.ru/opennews/art.shtml?num=33551) и XCP (https://www.opennet.ru/opennews/art.shtml?num=32022) (Xen Cloud Platform).Если OpenStack изначально развивается с оглядкой на Debian/Ubuntu, то XCP является свободным ответвлением от продукта Citrix XenServer и ранее поставлялся только в виде обособленного дистрибутива на основе CentOS. Выполненная в прошлом году работа (https://www.opennet.ru/opennews/art.shtml?num=31278) по портированию инструментария XenAPI для Debian, дала возможность создавать работающие поверх обычных версий Debian серверы виртуализации, полностью функционально эквивалентные стандартному дистрибутиву XCP.
Несмотря на то, что релиз Debian 7.0 ожидается ближе к осени, пакеты с OpenStack и XCP уже можно установить, используя ветку "testing". Разработчики Debian призывают заинтересованных пользователей принять участие в тестировании данных пакетов. Для упрощения развёртывания OpenStack подготовлена специальная инструкция (http://wiki.debian.org/OpenStackHowto), описывающая создание простого двухузлового кластера. Информацию об установке пакетов с XCP (http://packages.debian.org/wheezy/xcp-xapi) можно найти во входящем в состав данных пакетов файле README.Debian. Протестировать средства интеграции XCP с OpenStack можно установив пакет nova-xcp-plugins (http://packages.debian.org/wheezy/nova-xcp-plugins) на сервере XCP и следуя инструкциям, изложенным в файле README.xcp_and_OpenStack.URL: http://www.debian.org/News/2012/20120425
Новость: https://www.opennet.ru/opennews/art.shtml?num=33701
Все конкретно заморочились облаками.
Нанотехнологии нынче уже не модно. Сейчас новый тренд, клоуд.
Сами по себе облака всего лишь логичное дальнейшее развитие идей виртуализации. Другое дело что маркетолухи как обычно решили всех втравливать в зависимость от своих конторок :)
Ну я о том же. Куча людей которые вообще не хрена не понимают, что это такое.
Зато орут на каждом углу. Например большая часть считает, что гость в облаке может быть быстрее хоста.
>Например большая часть считает, что гость в облаке может быть быстрее хоста.А почему нет?
А как?
Подтверждаю.
Только вот хз как, сам не знаю.
Но я на KVM уже хренову кучу виртуалок с Win2008R2 установил и меня поражает скорость установки: с начала создания виртуальной машины и до логина в винду проходит ровно 15 минут. И это на обычном компьютере с 2ГГц зеоном.
Хотя, должно быть какое-то логическое объяснение :-)
Виртуальный ЖД винды кешируктся кешами линукса-хоста. Там памяти больше, кеши гуще, наверное?
> Виртуальный ЖД винды кешируктся кешами линукса-хоста. Там памяти больше, кеши гуще, наверное?Не только, в виртуалке инициализация "железа" стоит дешевле.
Ей не нужно ждать когда закончит инициализацию какой либо контроллер.
Особенно это заметно как раз при установке, где не мало времени уходит на поиск железа и установку дров к ним.
> Не только, в виртуалке инициализация "железа" стоит дешевле.
> Ей не нужно ждать когда закончит инициализацию какой либо контроллер.Учитывая что в конечном итоге тот же самый физический контроллер всяко будет педалить ту же самую операцию ибо кто-то должен сделать "физическое" действо наконец, это намекает разве что на то что драйвера у некоторых написаны настолько субоптимально что такая черезгопная гейтовка виртуального железа умудряется поднять скорость работы.
>> Не только, в виртуалке инициализация "железа" стоит дешевле.
>> Ей не нужно ждать когда закончит инициализацию какой либо контроллер.
> Учитывая что в конечном итоге тот же самый физический контроллер всяко будет
> педалить ту же самую операцию ибо кто-то должен сделать "физическое" действо
> наконец, это намекает разве что на то что драйвера у некоторых
> написаны настолько субоптимально что такая черезгопная гейтовка виртуального железа умудряется
> поднять скорость работы.Опять теряем нит треда, мы обсуждали почему винда ставится быстрее на виртуалку.
То что в итоге скорость будет хоть немного но ниже, это факт.
> Подтверждаю.Только вот хз как, сам не знаю.
Но я на KVM уже хренову кучу виртуалок с Win2008R2 установил и меня поражает скорость установки: с начала создания виртуальной машины и до логина в винду проходит ровно 15 минут. И это на обычном компьютере с 2ГГц зеоном.
Хотя, должно быть какое-то логическое объяснение :-)Виртуализация вычислений все равно сливает по производительности. Сложный дисковый IO тоже не фонтан.
Это же элементарно - скорость чтения из образа на харде в разы больше, чем скорость чтения с CD/DVD. Тупо файлы быстрее читаются...
Кластер
> КластерОтлично, кластер из гостей?
Ваше сообщение №4.7 весьма самокритично
https://www.opennet.ru/openforum/vsluhforumID3/84295.html#7
ну просвети меня как гость может быть быстрее хоста.
> ну просвети меня как гость может быть быстрее хоста.Ну, во-первых, sqlite в qemu же!
А во-вторых, они все про _распараллеленную специально-отдельно задачу не нескольких (~медленных) виртуалках, а не про specint или bogomips-ы на одном заоблачном ядре. Кончай _тупить!!
А где я говорил про "_распараллеленную специально-отдельно задачу не нескольких (~медленных) виртуалках"?Я говорю про очень частое заблуждение:
У нас тормозит 1Ц,ура решение всех наших проблем это облако! Оно там САМО ускорится. А куле щас влепим 100500 ядер и 64Тб рамы! Ну там ведь кластер, он сам все распаралелит.Только опять же, что такое кластер (в рамках виртуализации) опять имеем слабое представление.
Если из 3х машин поднять облако, можно ли будет создать 1 виртуалку которая будет использовать ресурсы всех 3х машин?
> Если из 3х машин поднять облако, можно ли будет создать 1 виртуалку
> которая будет использовать ресурсы всех 3х машин?Типа 3х кратный прирост CPU и памяти? Виртуака видит все в три раза больше?
Нет нельзя. Даже не всегда срабатывает живая миграция, если например идет большой поток работы с памятью. Не всегда успевает реплицироватся память.
> Если из 3х машин поднять облако, можно ли будет создать 1 виртуалку
> которая будет использовать ресурсы всех 3х машин?можно, но потребуется дорогое железо. и это будет уже не облако из 3-х машин, а грубо говоря, облако из одной машины в трех корпусах.
> можно, но потребуется дорогое железо. и это будет уже не облако из
> 3-х машин, а грубо говоря, облако из одной машины в трех корпусах.Маразм. Нормальный подход - просто оперировать некими самодостаточными потоками или процессами ("экземплярами сервиса") и увеличивать или уменьшать их количество в зависимости от нагрузки. При этом катит самое обычное железо и можно прозрачно отмасштабировать. В идеале прозрачно для сервиса, которому вообще не надо бы знать о том кто, как и сколько "воркеров" ему пустил.
отмасштабируйте мне прозрачно оракловый инстанс, пожалуйста.
> отмасштабируйте мне прозрачно оракловый инстанс, пожалуйста.Сразу после того как вы для меня запустите в космос вон тот паровоз.
Какая лапочка. На словах он Дональд Кнут, а как намекнули про стейтфул сервисы, сразу про космос заговорил.
>Я говорю про очень частое заблуждение:
>У нас тормозит 1Ц,ура решение всех наших проблем это облако! Оно там САМО ускорится. А куле щас влепим 100500 ядер и 64Тб рамы! Ну там ведь кластер, он сам все распаралелит.1C + Венда + Облачные технологии? ...Издеваетесь?
>>Я говорю про очень частое заблуждение:
>>У нас тормозит 1Ц,ура решение всех наших проблем это облако! Оно там САМО ускорится. А куле щас влепим 100500 ядер и 64Тб рамы! Ну там ведь кластер, он сам все распаралелит.
> 1C + Венда + Облачные технологии? ...Издеваетесь?Я? Не в коем разе, читаете выше. Я уже писал, что клоуд с роди с нано-технологиями.
Все о них говорят, но мало кто понимает, что это такое. Про 1Ц я привел практически то, что я сам слышал ушами.
> 1C + Венда + Облачные технологии? ...Издеваетесь?Паровая машина куда проволокой примотали реактивный двигатель :)
> ну просвети меня как гость может быть быстрее хоста.Например, хост может подкешировать густу диск и забить на (f)sync и подобные запросы, так что для гуеста такие вызовы будут в виртуалке (в отличие от железной машины) заканчиваться моментально. Ибо хост врет гуесту что слил буфера, хотя на самом деле слил их только в виртуальном представлении, а физически на диск ничего не писал.
Так можно немеряно разогнать синхронные транзакционные операции. До скорости... асинхронных, не обеспеченных транзакциями примерно. Угадаете почему? Правильно, потому что синхронность послали лесом уровнем выше. Чем это чревато - угадайте с 3 раз :)
>> ну просвети меня как гость может быть быстрее хоста.
> Например, хост может подкешировать густу диск и забить на (f)sync и подобные
> запросы, так что для гуеста такие вызовы будут в виртуалке (в
> отличие от железной машины) заканчиваться моментально. Ибо хост врет гуесту что
> слил буфера, хотя на самом деле слил их только в виртуальном
> представлении, а физически на диск ничего не писал.
> Так можно немеряно разогнать синхронные транзакционные операции. До скорости... асинхронных,
> не обеспеченных транзакциями примерно. Угадаете почему? Правильно, потому что синхронность
> послали лесом уровнем выше. Чем это чревато - угадайте с 3
> раз :)Чем это черевато и гадать не стоит. Помести данные на рамраздел, будет еще быстрее.
А кэши, можно и без виртуализации выкрутить по максимуму. Но это уже вопрос о тюненге.
> Чем это черевато и гадать не стоит. Помести данные на рамраздел, будет еще быстрее.Ну да. Только при слете питания факап будет еще убедительнее.
> А кэши, можно и без виртуализации выкрутить по максимуму.
В случае синхронных запросов если их честно разруливать, в кещ может не успевать налиться много (клинический случай: много мелких синхронных транзакций). При этом не важно какой размер у кеша: налиться много может и не успеть до очередного запроса на flush.
Вот только чудес не бывает. Или сброс буферов уважен (и занимает некое время) или на него положено (и тогда он время не занимает). Во втором случае при крахе любая журнальная механика уповавшая на честность синхронных операций окажется в обломе и может словить неожиданный FAIL.
> Но это уже вопрос о тюненге.
Это скорее к честности слива буферов на диск.
Да, но за это же канделябрами бить положено :)
> Да, но за это же канделябрами бить положено :)Что не мешает кажется виртуалбоксу так поступать иногда...
Облака позволяют качественнее утилизировать технику, что благо. А также линейно масштабировать приложения написанные под облачные инфраструктуры, что еще большее благо.Минусы - сложнее развернуть начинающему админу. А приложения требуется дописывать для поддержки "облачного" хранилища.
> Облака позволяют качественнее утилизировать технику, что благо.Да, запускаешь на воздушном шарике старый системник - хрен потом найдешь. Утилизировано на ура :)
> Минусы - сложнее развернуть начинающему админуТак именно для этого проект Debian и представил в Wheezy эти средства...
И каждый под "облаком" понимает, что ему хочется. У одного быстрее хоста ничего не работает, у другого - линейно масштабируется. Хотя в контексте новости юзер Bragin прав
> И каждый под "облаком" понимает, что ему хочется.В нормальном понимании - это группа машин, которая может представлять задачам ресурсы гибко масштабирующиеся под запросы. Грубо говоря, если есть эн сервисов и эм машин, какому-то сервису стало нужно больше ресурсов и они физически еще есть, облако должно взять и предоставить эти ресурсы запрашивающему их сервису. В идеале - прозрачно для сервиса, так что он не должен париться вопросом откуда это взято и как. Так что при нехватке ресурсов - просто добавил пару машин в группу и ... все.
> сервису стало нужно больше ресурсов и они физически еще есть, облако должно взять и предоставить эти ресурсы запрашивающему их сервисутолько это так не работает, ну может за исключением диска, который можно растягивать пока есть место в хранилище, остальное (цп, озу) ограниченно "размерами" конечных серверов, а не суммой свободных ресурсов на серверах
> конечных серверов, а не суммой свободных ресурсов на серверахТеоретически - совсем не обязано быть ограничено. Т.е. запускать треды сервиса по куче хостов и агрегировать это - ничему особо не противоречит, задирая число потоков при росте нагрузки и снижая при уменьшении.
Это только в теоретически.
На практике как все это синхронизировать?
Можно конечно присобачить высоко производительные шины на подобие InfiniBand.
Но это уже совсем другая сказка.
> На практике как все это синхронизировать?Неким диспетчером который агрегирует результаты от воркеров, ясен пень.
> Можно конечно присобачить высоко производительные шины на подобие InfiniBand.
А это вообще нахрена? Не всем сервисам надо гонять дофига данных между потоками. Яркий хоть и синтетический пример сервиса где сие совсем не так: майнинг биткоинов с пулом который как раз выступает агрегатором-синхронизатором и клиенты-воркеры рюхающие задачи в меру своих физических возможностей. Если задача не такая безразмерная как генереж биткоинов, а запуск воркеров автоматизирован - как раз получится вон то самое. Собственно масштабируемые многопроцессные/многопоточные бэкэнды нынче не редкость.
>Собственно масштабируемые многопроцессные/многопоточные
> бэкэнды нынче не редкость.Местные эксперты, похоже, понимают облако исключительно как набор физических серверов с виртуалками + сетевая фс + веб-мордочка.
А кто те сказал, что сетевая FS нужна?
---И кстати, обляка могут быть SAAS, PAAS и ещё какие-то там As A Service.
И под разные надо курить свой бамбук, в иных ФС даже не нужна, все данные
можно разрулить в базе данных.
> А кто те сказал, что сетевая FS нужна?Очень даже не обязательно, просто пример.
OpenMosix не решал эти задачи?
> OpenMosix не решал эти задачи?Разные технологии но вот клоуд часто путают с тем что делал OpenMosix.
Из практики, хоть и не юзаем облачную платформу а напрямую из virt-manager создаем виртуалки: 3-4 win2008 по 8 гектар памяти и по два-четыре проца на ВМ и запущенные вместе суммарно хавают памяти 10-15 Гб. Если софт требует больше памяти - конечно увеличивается, но ситуация похожа на виртуальный жесткий с динамическим размером. В любой момент времени съедается столько сколько требуется, а не сколько выделено изначально каждой ВМ. Поэтому в зависимости от задачи можно гибко комбинировать на каждый сервер виндовые ВМ и линуксовые. Которые комфортно живут и на 256 Мб. Если задача мелкая, и пару Гб если более высокая нагрузка. А так как в наличии есть не одна железка, причем разных поколений, разных архитектур, то здесь очень выгодна миграция между ними если вдруг на одной железке становится ВМ-кам неуютно. Причем без всяких переустановок, перенастроек. Миграция позволяет вводить в общий пул серверов совершенно разнообразные железяки. В том числе делать кластера из совершенно простых и недорогих, относительно, железяк. И гибко перемещать прожорливые ВМ в одно место, не жадные - в другое. Для любой компании с числом серверных железок больше 2-3 - это самое то. Один раз настроенная ВМ может работать там куда ее приткнут - это одна из прелестей.
Про скорость гостя выше хоста - не скажу, бенчмарки не проводили, т.к. это решение куда более комплексное.
Кроме того не забываем, что установив любую ОС, к примеру, на 12 ядерный сервер с 64 Гб памяти вы не получите супер-пупер мега сетевой сервис, только из-за ускорения роста оверхеда и других накладных расходов только даже на переключение контекста между сотнями и тысячами потоков которые будут там подниматься при множестве коннектов. Есть верхние ограничения у количества открытых файлов, на кол-во коннектов, хоть и снимаемые настройкой, но всё равно не бесконечные. Да и портов на одну ОС - 65535. А как обслуживать миллион входящих? Приходится разбивать одно железо на серию серверов из ВМ. Делать балансировку нагрузки, разводить одни и те же сервисы на разные железки, для увеличения процента доступности и т.д. и т.п. Облако снимает лишь серию ограничений в которые уткнулись компании, предоставляющие высоконагруженые сетевые сервисы.
Вы описываете обычные прелести виртуализации.Про проблему портов не совсем понятно, так как каждая гостевая ось имеет чаще всего собственный IP, со всеми вытекающими (а часто и собственный mac, в зависимости от софта виртуализации).
Если смотреть со стороны кластера, то там своя внутренняя подсеть и общий IP, который распределяет входящую нагрузку (либо это делается средствами DNS). В общем, вариантов масса и никогда при виртуализации-кластеризации не было проблемой количество портов. Миллион входящих - один ко многим - как-то ведь живут веб-сервера :)Да, облако - следующая ступень обычной виртуализации. И использоваться должно не ради имени, а если сопровождение виртуализации становится гемморойным. Гемморойно оно либо на больших объемах - "облако как сервис", либо при повышенной отказоустойчивости и более гибкого распределения нагрузки - для определенного среза компаний.
То, что до тиражирования облаков доросли компании-гиганты и начинают крутить рекламу для повышения окупаемости проекта, остальным, видимо, пудрит мозги.