форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
Сообщение от opennews (ok) on 26-Апр-12, 11:02
Проект Debian подчеркнул (http://www.debian.org/News/2012/20120425) опасности, связанные с развёртыванием систем во внешних облачных сервисах. Так как инфраструктура, обеспечивающая выполнение виртуальных машин, в таких сервисах обслуживается сторонней компанией и неподконтрольна клиенту, не исключена угроза утечки данных. Например, пользователь не может контролировать обеспечение безопасности и своевременное применение обновлений для управляющей инфраструктуры, а также не может поручиться в порядочности сотрудников компании, владеющей облачным сервисом. В связи с этим проект Debian призывает развёртывать облачные системы на собственных локальных мощностях, полностью подконтрольных предприятию. Для упрощения развёртывания собственных облачных инфраструктур в состав будущего релиза Debian 7.0 "Wheezy" будут включены пакеты, позволяющие с минимальными затратами установить и настроить системы на базе платформ OpenStack (http://www.opennet.me/opennews/art.shtml?num=33551) и XCP (http://www.opennet.me/opennews/art.shtml?num=32022) (Xen Cloud Platform). Если OpenStack изначально развивается с оглядкой на Debian/Ubuntu, то XCP является свободным ответвлением от продукта Citrix XenServer и ранее поставлялся только в виде обособленного дистрибутива на основе CentOS. Выполненная в прошлом году работа (http://www.opennet.me/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 Новость: http://www.opennet.me/opennews/art.shtml?num=33701
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
Сообщение от SubGun (ok) on 26-Апр-12, 11:02
Все конкретно заморочились облаками.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+1 +/–
	Сообщение от Bragin (ok) on 26-Апр-12, 11:09
	Нанотехнологии нынче уже не модно. Сейчас новый тренд, клоуд.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	5. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+2 +/–
	Сообщение от Аноним (??) on 26-Апр-12, 11:16
	Сами по себе облака всего лишь логичное дальнейшее развитие идей виртуализации. Другое дело что маркетолухи как обычно решили всех втравливать в зависимость от своих конторок :)
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	7. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+2 +/–
	Сообщение от Bragin (ok) on 26-Апр-12, 11:25
	Ну я о том же. Куча людей которые вообще не хрена не понимают, что это такое. Зато орут на каждом углу. Например большая часть считает, что гость в облаке может быть быстрее хоста.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	8. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
	Сообщение от Аноним (??) on 26-Апр-12, 12:04
	>Например большая часть считает, что гость в облаке может быть быстрее хоста. А почему нет?
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	9. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
	Сообщение от Bragin (ok) on 26-Апр-12, 12:05
	А как?
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	10. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
	Сообщение от docent (??) on 26-Апр-12, 12:13
	Подтверждаю. Только вот хз как, сам не знаю. Но я на KVM уже хренову кучу виртуалок с Win2008R2 установил и меня поражает скорость установки: с начала создания виртуальной машины и до логина в винду проходит ровно 15 минут. И это на обычном компьютере с 2ГГц зеоном. Хотя, должно быть какое-то логическое объяснение :-)
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	13. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
	Сообщение от Andrey Mitrofanov on 26-Апр-12, 12:58
	Виртуальный ЖД винды кешируктся кешами линукса-хоста. Там памяти больше, кеши гуще, наверное?
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	20. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
	Сообщение от Bragin (ok) on 26-Апр-12, 13:47
	> Виртуальный ЖД винды кешируктся кешами линукса-хоста. Там памяти больше, кеши гуще, наверное? Не только, в виртуалке инициализация "железа" стоит дешевле. Ей не нужно ждать когда закончит инициализацию какой либо контроллер. Особенно это заметно как раз при установке, где не мало времени уходит на поиск железа и установку дров к ним.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	23. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	–1 +/–
	Сообщение от Аноним (??) on 26-Апр-12, 14:38
	> Не только, в виртуалке инициализация "железа" стоит дешевле. > Ей не нужно ждать когда закончит инициализацию какой либо контроллер. Учитывая что в конечном итоге тот же самый физический контроллер всяко будет педалить ту же самую операцию ибо кто-то должен сделать "физическое" действо наконец, это намекает разве что на то что драйвера у некоторых написаны настолько субоптимально что такая черезгопная гейтовка виртуального железа умудряется поднять скорость работы.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	30. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
	Сообщение от Bragin (ok) on 26-Апр-12, 14:50
	>> Не только, в виртуалке инициализация "железа" стоит дешевле. >> Ей не нужно ждать когда закончит инициализацию какой либо контроллер. > Учитывая что в конечном итоге тот же самый физический контроллер всяко будет > педалить ту же самую операцию ибо кто-то должен сделать "физическое" действо > наконец, это намекает разве что на то что драйвера у некоторых > написаны настолько субоптимально что такая черезгопная гейтовка виртуального железа умудряется > поднять скорость работы. Опять теряем нит треда, мы обсуждали почему винда ставится быстрее на виртуалку. То что в итоге скорость будет хоть немного но ниже, это факт.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	40. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
	Сообщение от I am (??) on 26-Апр-12, 15:46
	> Подтверждаю. Только вот хз как, сам не знаю. Но я на KVM уже хренову кучу виртуалок с Win2008R2 установил и меня поражает скорость установки: с начала создания виртуальной машины и до логина в винду проходит ровно 15 минут. И это на обычном компьютере с 2ГГц зеоном. Хотя, должно быть какое-то логическое объяснение :-) Виртуализация вычислений все равно сливает по производительности. Сложный дисковый IO тоже не фонтан.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	52. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
	Сообщение от Хзкто on 28-Апр-12, 09:40
	Это же элементарно - скорость чтения из образа на харде в разы больше, чем скорость чтения с CD/DVD. Тупо файлы быстрее читаются...
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	12. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	–1 +/–
	Сообщение от Аноним (??) on 26-Апр-12, 12:17
	Кластер
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	14. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
	Сообщение от Bragin (ok) on 26-Апр-12, 12:59
	> Кластер Отлично, кластер из гостей?
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	15. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	–1 +/–
	Сообщение от filosofem (ok) on 26-Апр-12, 13:06
	Ваше сообщение №4.7 весьма самокритично http://www.opennet.me/openforum/vsluhforumID3/84295.html#7
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	16. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
	Сообщение от Bragin (ok) on 26-Апр-12, 13:08
	ну просвети меня как гость может быть быстрее хоста.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	17. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
	Сообщение от Andrey Mitrofanov on 26-Апр-12, 13:13
	> ну просвети меня как гость может быть быстрее хоста. Ну, во-первых, sqlite в qemu же! А во-вторых, они все про _распараллеленную специально-отдельно задачу не нескольких (~медленных) виртуалках, а не про specint или bogomips-ы на одном заоблачном ядре. Кончай _тупить!!
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	18. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	–1 +/–
	Сообщение от Bragin (ok) on 26-Апр-12, 13:26
	А где я говорил про "_распараллеленную специально-отдельно задачу не нескольких (~медленных) виртуалках"? Я говорю про очень частое заблуждение: У нас тормозит 1Ц,ура решение всех наших проблем это облако! Оно там САМО ускорится. А куле щас влепим 100500 ядер и 64Тб рамы! Ну там ведь кластер, он сам все распаралелит. Только опять же, что такое кластер (в рамках виртуализации) опять имеем слабое представление.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	19. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
	Сообщение от Аноним (??) on 26-Апр-12, 13:45
	Если из 3х машин поднять облако, можно ли будет создать 1 виртуалку которая будет использовать ресурсы всех 3х машин?
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	21. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
	Сообщение от Bragin (ok) on 26-Апр-12, 13:53
	> Если из 3х машин поднять облако, можно ли будет создать 1 виртуалку > которая будет использовать ресурсы всех 3х машин? Типа 3х кратный прирост CPU и памяти? Виртуака видит все в три раза больше? Нет нельзя. Даже не всегда срабатывает живая миграция, если например идет большой поток работы с памятью. Не всегда успевает реплицироватся память.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	33. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	–1 +/–
	Сообщение от Михрютка on 26-Апр-12, 15:10
	> Если из 3х машин поднять облако, можно ли будет создать 1 виртуалку > которая будет использовать ресурсы всех 3х машин? можно, но потребуется дорогое железо. и это будет уже не облако из 3-х машин, а грубо говоря, облако из одной машины в трех корпусах.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	41. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
	Сообщение от Аноним (??) on 26-Апр-12, 15:47
	> можно, но потребуется дорогое железо. и это будет уже не облако из > 3-х машин, а грубо говоря, облако из одной машины в трех корпусах. Маразм. Нормальный подход - просто оперировать некими самодостаточными потоками или процессами ("экземплярами сервиса") и увеличивать или уменьшать их количество в зависимости от нагрузки. При этом катит самое обычное железо и можно прозрачно отмасштабировать. В идеале прозрачно для сервиса, которому вообще не надо бы знать о том кто, как и сколько "воркеров" ему пустил.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	43. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+1 +/–
	Сообщение от Михрютка on 26-Апр-12, 15:54
	отмасштабируйте мне прозрачно оракловый инстанс, пожалуйста.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	45. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
	Сообщение от Аноним (??) on 26-Апр-12, 16:02
	> отмасштабируйте мне прозрачно оракловый инстанс, пожалуйста. Сразу после того как вы для меня запустите в космос вон тот паровоз.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	46. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
	Сообщение от Михрютка on 26-Апр-12, 17:36
	Какая лапочка. На словах он Дональд Кнут, а как намекнули про стейтфул сервисы, сразу про космос заговорил.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	22. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
	Сообщение от filosofem (ok) on 26-Апр-12, 14:23
	>Я говорю про очень частое заблуждение: >У нас тормозит 1Ц,ура решение всех наших проблем это облако! Оно там САМО ускорится. А куле щас влепим 100500 ядер и 64Тб рамы! Ну там ведь кластер, он сам все распаралелит. 1C + Венда + Облачные технологии? ...Издеваетесь?
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	26. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	–1 +/–
	Сообщение от Bragin (ok) on 26-Апр-12, 14:43
	>>Я говорю про очень частое заблуждение: >>У нас тормозит 1Ц,ура решение всех наших проблем это облако! Оно там САМО ускорится. А куле щас влепим 100500 ядер и 64Тб рамы! Ну там ведь кластер, он сам все распаралелит. > 1C + Венда + Облачные технологии? ...Издеваетесь? Я? Не в коем разе, читаете выше. Я уже писал, что клоуд с роди с нано-технологиями. Все о них говорят, но мало кто понимает, что это такое. Про 1Ц я привел практически то, что я сам слышал ушами.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	38. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
	Сообщение от Аноним (??) on 26-Апр-12, 15:31
	> 1C + Венда + Облачные технологии? ...Издеваетесь? Паровая машина куда проволокой примотали реактивный двигатель :)
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	24. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
	Сообщение от Аноним (??) on 26-Апр-12, 14:41
	> ну просвети меня как гость может быть быстрее хоста. Например, хост может подкешировать густу диск и забить на (f)sync и подобные запросы, так что для гуеста такие вызовы будут в виртуалке (в отличие от железной машины) заканчиваться моментально. Ибо хост врет гуесту что слил буфера, хотя на самом деле слил их только в виртуальном представлении, а физически на диск ничего не писал. Так можно немеряно разогнать синхронные транзакционные операции. До скорости... асинхронных, не обеспеченных транзакциями примерно. Угадаете почему? Правильно, потому что синхронность послали лесом уровнем выше. Чем это чревато - угадайте с 3 раз :)
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	28. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
	Сообщение от Bragin (ok) on 26-Апр-12, 14:47
	>> ну просвети меня как гость может быть быстрее хоста. > Например, хост может подкешировать густу диск и забить на (f)sync и подобные > запросы, так что для гуеста такие вызовы будут в виртуалке (в > отличие от железной машины) заканчиваться моментально. Ибо хост врет гуесту что > слил буфера, хотя на самом деле слил их только в виртуальном > представлении, а физически на диск ничего не писал. > Так можно немеряно разогнать синхронные транзакционные операции. До скорости... асинхронных, > не обеспеченных транзакциями примерно. Угадаете почему? Правильно, потому что синхронность > послали лесом уровнем выше. Чем это чревато - угадайте с 3 > раз :) Чем это черевато и гадать не стоит. Помести данные на рамраздел, будет еще быстрее. А кэши, можно и без виртуализации выкрутить по максимуму. Но это уже вопрос о тюненге.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	34. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
	Сообщение от Аноним (??) on 26-Апр-12, 15:14
	> Чем это черевато и гадать не стоит. Помести данные на рамраздел, будет еще быстрее. Ну да. Только при слете питания факап будет еще убедительнее. > А кэши, можно и без виртуализации выкрутить по максимуму. В случае синхронных запросов если их честно разруливать, в кещ может не успевать налиться много (клинический случай: много мелких синхронных транзакций). При этом не важно какой размер у кеша: налиться много может и не успеть до очередного запроса на flush. Вот только чудес не бывает. Или сброс буферов уважен (и занимает некое время) или на него положено (и тогда он время не занимает). Во втором случае при крахе любая журнальная механика уповавшая на честность синхронных операций окажется в обломе и может словить неожиданный FAIL. > Но это уже вопрос о тюненге. Это скорее к честности слива буферов на диск.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	31. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
	Сообщение от Михрютка on 26-Апр-12, 15:00
	Да, но за это же канделябрами бить положено :)
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	35. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
	Сообщение от Аноним (??) on 26-Апр-12, 15:14
	> Да, но за это же канделябрами бить положено :) Что не мешает кажется виртуалбоксу так поступать иногда...
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	3. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
	Сообщение от VoDA (ok) on 26-Апр-12, 11:12
	Облака позволяют качественнее утилизировать технику, что благо. А также линейно масштабировать приложения написанные под облачные инфраструктуры, что еще большее благо. Минусы - сложнее развернуть начинающему админу. А приложения требуется дописывать для поддержки "облачного" хранилища.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	25. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+1 +/–
	Сообщение от Аноним (??) on 26-Апр-12, 14:42
	> Облака позволяют качественнее утилизировать технику, что благо. Да, запускаешь на воздушном шарике старый системник - хрен потом найдешь. Утилизировано на ура :)
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	27. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
	Сообщение от бедный буратино (ok) on 26-Апр-12, 14:46
	> Минусы - сложнее развернуть начинающему админу Так именно для этого проект Debian и представил в Wheezy эти средства...
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

11. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
Сообщение от анон on 26-Апр-12, 12:16
И каждый под "облаком" понимает, что ему хочется. У одного быстрее хоста ничего не работает, у другого - линейно масштабируется. Хотя в контексте новости юзер Bragin прав
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	29. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
	Сообщение от Аноним (??) on 26-Апр-12, 14:49
	> И каждый под "облаком" понимает, что ему хочется. В нормальном понимании - это группа машин, которая может представлять задачам ресурсы гибко масштабирующиеся под запросы. Грубо говоря, если есть эн сервисов и эм машин, какому-то сервису стало нужно больше ресурсов и они физически еще есть, облако должно взять и предоставить эти ресурсы запрашивающему их сервису. В идеале - прозрачно для сервиса, так что он не должен париться вопросом откуда это взято и как. Так что при нехватке ресурсов - просто добавил пару машин в группу и ... все.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	32. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
	Сообщение от koblin (ok) on 26-Апр-12, 15:06
	> сервису стало нужно больше ресурсов и они физически еще есть, облако должно взять и предоставить эти ресурсы запрашивающему их сервису только это так не работает, ну может за исключением диска, который можно растягивать пока есть место в хранилище, остальное (цп, озу) ограниченно "размерами" конечных серверов, а не суммой свободных ресурсов на серверах
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	37. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
	Сообщение от Аноним (??) on 26-Апр-12, 15:30
	> конечных серверов, а не суммой свободных ресурсов на серверах Теоретически - совсем не обязано быть ограничено. Т.е. запускать треды сервиса по куче хостов и агрегировать это - ничему особо не противоречит, задирая число потоков при росте нагрузки и снижая при уменьшении.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	39. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
	Сообщение от Bragin (ok) on 26-Апр-12, 15:45
	Это только в теоретически. На практике как все это синхронизировать? Можно конечно присобачить высоко производительные шины на подобие InfiniBand. Но это уже совсем другая сказка.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	44. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
	Сообщение от Аноним (??) on 26-Апр-12, 15:56
	> На практике как все это синхронизировать? Неким диспетчером который агрегирует результаты от воркеров, ясен пень. > Можно конечно присобачить высоко производительные шины на подобие InfiniBand. А это вообще нахрена? Не всем сервисам надо гонять дофига данных между потоками. Яркий хоть и синтетический пример сервиса где сие совсем не так: майнинг биткоинов с пулом который как раз выступает агрегатором-синхронизатором и клиенты-воркеры рюхающие задачи в меру своих физических возможностей. Если задача не такая безразмерная как генереж биткоинов, а запуск воркеров автоматизирован - как раз получится вон то самое. Собственно масштабируемые многопроцессные/многопоточные бэкэнды нынче не редкость.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	47. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
	Сообщение от Аноним (??) on 26-Апр-12, 19:57
	>Собственно масштабируемые многопроцессные/многопоточные > бэкэнды нынче не редкость. Местные эксперты, похоже, понимают облако исключительно как набор физических серверов с виртуалками + сетевая фс + веб-мордочка.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	48. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
	Сообщение от pavlinux (ok) on 26-Апр-12, 20:34
	А кто те сказал, что сетевая FS нужна? --- И кстати, обляка могут быть SAAS, PAAS и ещё какие-то там As A Service. И под разные надо курить свой бамбук, в иных ФС даже не нужна, все данные можно разрулить в базе данных.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	49. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
	Сообщение от Аноним (??) on 26-Апр-12, 21:11
	> А кто те сказал, что сетевая FS нужна? Очень даже не обязательно, просто пример.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	36. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
	Сообщение от umbr (ok) on 26-Апр-12, 15:18
	OpenMosix не решал эти задачи?
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	42. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
	Сообщение от Bragin (ok) on 26-Апр-12, 15:47
	> OpenMosix не решал эти задачи? Разные технологии но вот клоуд часто путают с тем что делал OpenMosix.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

50. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
Сообщение от hummermania (ok) on 27-Апр-12, 10:18
Из практики, хоть и не юзаем облачную платформу а напрямую из virt-manager создаем виртуалки: 3-4 win2008 по 8 гектар памяти и по два-четыре проца на ВМ и запущенные вместе суммарно хавают памяти 10-15 Гб. Если софт требует больше памяти - конечно увеличивается, но ситуация похожа на виртуальный жесткий с динамическим размером. В любой момент времени съедается столько сколько требуется, а не сколько выделено изначально каждой ВМ. Поэтому в зависимости от задачи можно гибко комбинировать на каждый сервер виндовые ВМ и линуксовые. Которые комфортно живут и на 256 Мб. Если задача мелкая, и пару Гб если более высокая нагрузка. А так как в наличии есть не одна железка, причем разных поколений, разных архитектур, то здесь очень выгодна миграция между ними если вдруг на одной железке становится ВМ-кам неуютно. Причем без всяких переустановок, перенастроек. Миграция позволяет вводить в общий пул серверов совершенно разнообразные железяки. В том числе делать кластера из совершенно простых и недорогих, относительно, железяк. И гибко перемещать прожорливые ВМ в одно место, не жадные - в другое. Для любой компании с числом серверных железок больше 2-3 - это самое то. Один раз настроенная ВМ может работать там куда ее приткнут - это одна из прелестей. Про скорость гостя выше хоста - не скажу, бенчмарки не проводили, т.к. это решение куда более комплексное. Кроме того не забываем, что установив любую ОС, к примеру, на 12 ядерный сервер с 64 Гб памяти вы не получите супер-пупер мега сетевой сервис, только из-за ускорения роста оверхеда и других накладных расходов только даже на переключение контекста между сотнями и тысячами потоков которые будут там подниматься при множестве коннектов. Есть верхние ограничения у количества открытых файлов, на кол-во коннектов, хоть и снимаемые настройкой, но всё равно не бесконечные. Да и портов на одну ОС - 65535. А как обслуживать миллион входящих? Приходится разбивать одно железо на серию серверов из ВМ. Делать балансировку нагрузки, разводить одни и те же сервисы на разные железки, для увеличения процента доступности и т.д. и т.п. Облако снимает лишь серию ограничений в которые уткнулись компании, предоставляющие высоконагруженые сетевые сервисы.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	51. "Проект Debian представил ожидаемые в Wheezy средства для упр..."	+/–
	Сообщение от stimpack (ok) on 27-Апр-12, 13:52
	Вы описываете обычные прелести виртуализации. Про проблему портов не совсем понятно, так как каждая гостевая ось имеет чаще всего собственный IP, со всеми вытекающими (а часто и собственный mac, в зависимости от софта виртуализации). Если смотреть со стороны кластера, то там своя внутренняя подсеть и общий IP, который распределяет входящую нагрузку (либо это делается средствами DNS). В общем, вариантов масса и никогда при виртуализации-кластеризации не было проблемой количество портов. Миллион входящих - один ко многим - как-то ведь живут веб-сервера :) Да, облако - следующая ступень обычной виртуализации. И использоваться должно не ради имени, а если сопровождение виртуализации становится гемморойным. Гемморойно оно либо на больших объемах - "облако как сервис", либо при повышенной отказоустойчивости и более гибкого распределения нагрузки - для определенного среза компаний. То, что до тиражирования облаков доросли компании-гиганты и начинают крутить рекламу для повышения окупаемости проекта, остальным, видимо, пудрит мозги.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема