| |
| 2.2, Bragin (ok), 11:09, 26/04/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Нанотехнологии нынче уже не модно. Сейчас новый тренд, клоуд.
| | |
| |
| 3.5, Аноним (-), 11:16, 26/04/2012 [^] [^^] [^^^] [ответить]
| +2 +/– |
Сами по себе облака всего лишь логичное дальнейшее развитие идей виртуализации. Другое дело что маркетолухи как обычно решили всех втравливать в зависимость от своих конторок :)
| | |
| |
| 4.7, Bragin (ok), 11:25, 26/04/2012 [^] [^^] [^^^] [ответить]
| +2 +/– |
Ну я о том же. Куча людей которые вообще не хрена не понимают, что это такое.
Зато орут на каждом углу. Например большая часть считает, что гость в облаке может быть быстрее хоста.
| | |
| |
| 5.8, Аноним (-), 12:04, 26/04/2012 [^] [^^] [^^^] [ответить]
| +/– | |
>Например большая часть считает, что гость в облаке может быть быстрее хоста.
А почему нет?
| | |
| |
| |
| 7.10, docent (??), 12:13, 26/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
Подтверждаю.
Только вот хз как, сам не знаю.
Но я на KVM уже хренову кучу виртуалок с Win2008R2 установил и меня поражает скорость установки: с начала создания виртуальной машины и до логина в винду проходит ровно 15 минут. И это на обычном компьютере с 2ГГц зеоном.
Хотя, должно быть какое-то логическое объяснение :-)
| | |
| |
| |
| 9.20, Bragin (ok), 13:47, 26/04/2012 [^] [^^] [^^^] [ответить] | +/– | Не только, в виртуалке инициализация железа стоит дешевле Ей не нужно ждать к... текст свёрнут, показать | | |
| |
| 10.23, Аноним (-), 14:38, 26/04/2012 [^] [^^] [^^^] [ответить] | –1 +/– | Учитывая что в конечном итоге тот же самый физический контроллер всяко будет пед... текст свёрнут, показать | | |
|
|
| 8.40, I am (??), 15:46, 26/04/2012 [^] [^^] [^^^] [ответить] | +/– | Только вот хз как, сам не знаю Но я на KVM уже хренову кучу виртуалок с Win2008... текст свёрнут, показать | | |
| 8.52, Хзкто (?), 09:40, 28/04/2012 [^] [^^] [^^^] [ответить] | +/– | Это же элементарно - скорость чтения из образа на харде в разы больше, чем скоро... текст свёрнут, показать | | |
|
| |
| |
| |
| |
| |
| 12.18, Bragin (ok), 13:26, 26/04/2012 [^] [^^] [^^^] [ответить] | –1 +/– | А где я говорил про _распараллеленную специально-отдельно задачу не нескольких ... текст свёрнут, показать | | |
| |
| |
| 14.26, Bragin (ok), 14:43, 26/04/2012 [^] [^^] [^^^] [ответить] | –1 +/– | Я Не в коем разе, читаете выше Я уже писал, что клоуд с роди с нано-технология... текст свёрнут, показать | | |
|
|
|
| |
| |
| 13.34, Аноним (-), 15:14, 26/04/2012 [^] [^^] [^^^] [ответить] | +/– | Ну да Только при слете питания факап будет еще убедительнее В случае синхронн... большой текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
|
|
|
| 2.3, VoDA (ok), 11:12, 26/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
 Облака позволяют качественнее утилизировать технику, что благо. А также линейно масштабировать приложения написанные под облачные инфраструктуры, что еще большее благо.
Минусы - сложнее развернуть начинающему админу. А приложения требуется дописывать для поддержки "облачного" хранилища.
| | |
| |
| 3.25, Аноним (-), 14:42, 26/04/2012 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Облака позволяют качественнее утилизировать технику, что благо.
Да, запускаешь на воздушном шарике старый системник - хрен потом найдешь. Утилизировано на ура :)
| | |
| 3.27, бедный буратино (ok), 14:46, 26/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
 > Минусы - сложнее развернуть начинающему админу
Так именно для этого проект Debian и представил в Wheezy эти средства...
| | |
|
|
| 1.11, анон (?), 12:16, 26/04/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
И каждый под "облаком" понимает, что ему хочется. У одного быстрее хоста ничего не работает, у другого - линейно масштабируется. Хотя в контексте новости юзер Bragin прав
| | |
| |
| 2.29, Аноним (-), 14:49, 26/04/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> И каждый под "облаком" понимает, что ему хочется.
В нормальном понимании - это группа машин, которая может представлять задачам ресурсы гибко масштабирующиеся под запросы. Грубо говоря, если есть эн сервисов и эм машин, какому-то сервису стало нужно больше ресурсов и они физически еще есть, облако должно взять и предоставить эти ресурсы запрашивающему их сервису. В идеале - прозрачно для сервиса, так что он не должен париться вопросом откуда это взято и как. Так что при нехватке ресурсов - просто добавил пару машин в группу и ... все.
| | |
| |
| 3.32, koblin (ok), 15:06, 26/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
 > сервису стало нужно больше ресурсов и они физически еще есть, облако должно взять и предоставить эти ресурсы запрашивающему их сервису
только это так не работает, ну может за исключением диска, который можно растягивать пока есть место в хранилище, остальное (цп, озу) ограниченно "размерами" конечных серверов, а не суммой свободных ресурсов на серверах
| | |
| |
| 4.37, Аноним (-), 15:30, 26/04/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> конечных серверов, а не суммой свободных ресурсов на серверах
Теоретически - совсем не обязано быть ограничено. Т.е. запускать треды сервиса по куче хостов и агрегировать это - ничему особо не противоречит, задирая число потоков при росте нагрузки и снижая при уменьшении.
| | |
| |
| 5.39, Bragin (ok), 15:45, 26/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
Это только в теоретически.
На практике как все это синхронизировать?
Можно конечно присобачить высоко производительные шины на подобие InfiniBand.
Но это уже совсем другая сказка.
| | |
| |
| 6.44, Аноним (-), 15:56, 26/04/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> На практике как все это синхронизировать?
Неким диспетчером который агрегирует результаты от воркеров, ясен пень.
> Можно конечно присобачить высоко производительные шины на подобие InfiniBand.
А это вообще нахрена? Не всем сервисам надо гонять дофига данных между потоками. Яркий хоть и синтетический пример сервиса где сие совсем не так: майнинг биткоинов с пулом который как раз выступает агрегатором-синхронизатором и клиенты-воркеры рюхающие задачи в меру своих физических возможностей. Если задача не такая безразмерная как генереж биткоинов, а запуск воркеров автоматизирован - как раз получится вон то самое. Собственно масштабируемые многопроцессные/многопоточные бэкэнды нынче не редкость.
| | |
| |
| 7.47, Аноним (-), 19:57, 26/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
>Собственно масштабируемые многопроцессные/многопоточные
> бэкэнды нынче не редкость.
Местные эксперты, похоже, понимают облако исключительно как набор физических серверов с виртуалками + сетевая фс + веб-мордочка.
| | |
|
|
|
|
| |
| 4.42, Bragin (ok), 15:47, 26/04/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> OpenMosix не решал эти задачи?
Разные технологии но вот клоуд часто путают с тем что делал OpenMosix.
| | |
|
|
|
| |
| 2.51, stimpack (ok), 13:52, 27/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
 Вы описываете обычные прелести виртуализации.
Про проблему портов не совсем понятно, так как каждая гостевая ось имеет чаще всего собственный IP, со всеми вытекающими (а часто и собственный mac, в зависимости от софта виртуализации).
Если смотреть со стороны кластера, то там своя внутренняя подсеть и общий IP, который распределяет входящую нагрузку (либо это делается средствами DNS). В общем, вариантов масса и никогда при виртуализации-кластеризации не было проблемой количество портов. Миллион входящих - один ко многим - как-то ведь живут веб-сервера :)
Да, облако - следующая ступень обычной виртуализации. И использоваться должно не ради имени, а если сопровождение виртуализации становится гемморойным. Гемморойно оно либо на больших объемах - "облако как сервис", либо при повышенной отказоустойчивости и более гибкого распределения нагрузки - для определенного среза компаний.
То, что до тиражирования облаков доросли компании-гиганты и начинают крутить рекламу для повышения окупаемости проекта, остальным, видимо, пудрит мозги.
| | |
|
|
