Comments 31
Вы описали крутую штуку! Спасибо!
Биллинг ресурсов виртуалок самописный, правильно понимаю? Вы его не продаёте, случаем?
Можете вкратце описать как платформа управления HP цепляется к гипервизорам сторонних производителей (я так понимаю vmware)?
Биллинг ресурсов виртуалок самописный, правильно понимаю? Вы его не продаёте, случаем?
Можете вкратце описать как платформа управления HP цепляется к гипервизорам сторонних производителей (я так понимаю vmware)?
Биллинг ресурсов виртуальной платформы VMWare разработан HP и является коробочным решением.
Если мы говорим о сборе информации по использованию виртуальных ресурсов, в частности для платформы VMWare, то возможно два варианта:
1. Разработка собственных скриптов, которые вытягивают информацию уже собранную VMWare Chargeback Manger (через API VMWare).
2. Использование коробочного продукта HP Performance Virtualization Viewer который посредством подключения к vCenter сам собирает информацию по использованию виртуальных ресурсов.
Если мы говорим о сборе информации по использованию виртуальных ресурсов, в частности для платформы VMWare, то возможно два варианта:
1. Разработка собственных скриптов, которые вытягивают информацию уже собранную VMWare Chargeback Manger (через API VMWare).
2. Использование коробочного продукта HP Performance Virtualization Viewer который посредством подключения к vCenter сам собирает информацию по использованию виртуальных ресурсов.
Решение задач автоматизации распределения ресурсов, их учёта и прогнозирования, это важно, и полезно. И тут приводятся частично вполне уместные аргументы. Но зачем пытаться выдумать какие-то странные причины, чтобы продать клиентам то, что им и без них нужно?
Это позволяет отнюдь не только облако. Даже виртуализация для этого не обязательна. Особенно, если требования проектов не меняются каждую минуту. А они, обычно, всё же довольно предсказуемы.
Но это ладно, Действительно управлять единым целым проще, чем набором серверов/виртуалок отдельных проектов, но какого перепугу, у вас в облаке волшебным образом вдруг утроятся ресурсы? Чёрт, это явный маркетологический бред, почему не 10? Не 100? Нет, естественно, определённые часть мощностей можно будет перераспределить, но чтобы разница была аж в 3 раза, это как безграмотно всё должно быть распределено до того? Как то не похоже на типичный случай.
И опять передёргивание. Ресурсы виртуальные из неоткуда не возьмутся, т.е. необходимое для обслуживания пика запросов железо, всё же должно быть в наличии. Или придётся подвинуть другие сервисы/отделы/проекты. А это возможно далеко не всегда. Так что откуда тут взяться экономии?
И что — высвобождаются временно мощности. И она, на самом деле, не бесплатны. И далеко не всегда найдётся применение им в другом месте.
Поэтому точность этой оценки очень идеализирована, как мне кажется.
Экономия на железе: «облако» позволяет крутить сотни проектов на одном наборе железа, когда как без такой инфраструктуры железа потребовалось бы минимум втрое больше. Ну и в будущем нет проблем с заменой железа
Это позволяет отнюдь не только облако. Даже виртуализация для этого не обязательна. Особенно, если требования проектов не меняются каждую минуту. А они, обычно, всё же довольно предсказуемы.
Но это ладно, Действительно управлять единым целым проще, чем набором серверов/виртуалок отдельных проектов, но какого перепугу, у вас в облаке волшебным образом вдруг утроятся ресурсы? Чёрт, это явный маркетологический бред, почему не 10? Не 100? Нет, естественно, определённые часть мощностей можно будет перераспределить, но чтобы разница была аж в 3 раза, это как безграмотно всё должно быть распределено до того? Как то не похоже на типичный случай.
Отдельный вопрос — мощность для масштабирования. Например, для колл-центра с ярко выраженными сезонными пиками (туристического или, например, имеющего пик под Новый Год) логично не закупать массу железа и лицензий ради двух недель работы в году — они используют виртуальные ресурсы, которые очень легко масштабируются.
И опять передёргивание. Ресурсы виртуальные из неоткуда не возьмутся, т.е. необходимое для обслуживания пика запросов железо, всё же должно быть в наличии. Или придётся подвинуть другие сервисы/отделы/проекты. А это возможно далеко не всегда. Так что откуда тут взяться экономии?
Волшебный 152-ФЗ и ряд других нормативов: пока не всегда можно отдавать свои ПД на обработку кому-то третьему, требуется разворачивать фермы у себя.Ну а это-то как вообще к облакам относится? Наоборот бы, изолировать логично.
Затраты конкретного стенда сейчас автоматически, благодаря внутренней системе биллинга, падают на конкретный проект. С точностью до копейки. Не больше, не меньше. Причем с учетом простоя, то есть если ты останавливаешь виртуалку на какое-то время, то и не платишь.
И что — высвобождаются временно мощности. И она, на самом деле, не бесплатны. И далеко не всегда найдётся применение им в другом месте.
Поэтому точность этой оценки очень идеализирована, как мне кажется.
В топике дан конкретный сценарий, в котором «частное облако» хорошо работает. Так что ваши контр-примеры (вполне разумные, для сферического коня в вакууме) здесь не подходят.
Обратите внимание, речь идет о внутренней лаборатории в компании интеграторе. Ребята поступили очень грамотно, и в итоге первоначальные инвестиции окупают именно те подразделения, которым лаборатория нужна. Это полезно и для самих подразделений (стенды не застаиваются, ресурсы экономятся), и для руководства (прозрачность затрат, можно посчитать сроки окупаемости, понять ставку маржинальности).
Есть и другие подобные сценарии, уже внутри обычных коммерсантов. Как правило это компании, в которых департамент ИТ выделен в отдельное «хозрасчетное» подразделение.
Обратите внимание, речь идет о внутренней лаборатории в компании интеграторе. Ребята поступили очень грамотно, и в итоге первоначальные инвестиции окупают именно те подразделения, которым лаборатория нужна. Это полезно и для самих подразделений (стенды не застаиваются, ресурсы экономятся), и для руководства (прозрачность затрат, можно посчитать сроки окупаемости, понять ставку маржинальности).
Есть и другие подобные сценарии, уже внутри обычных коммерсантов. Как правило это компании, в которых департамент ИТ выделен в отдельное «хозрасчетное» подразделение.
Обратите внимание — пункты перечисленные в начале, и которые мы обсуждаем, относились не к конкретному кейсу, а к причинам, зачем потенциальному клиенту нужно облако, а ни чем оно хорошо в каком-то конкретном кейсе. И в этом разрезе совершенно не выдерживают критики.
Шапка не совсем корректна, согласен. Да и по тексту достаточно эмоциональных высказываний и недоговариваний (как про ресурсы колл-центра). Но все же топик про конкретный пример, отсюда и все нестыковки.
Волшебный 152-ФЗ и ряд других нормативов: пока не всегда можно отдавать свои ПД на обработку кому-то третьему, требуется разворачивать фермы у себя.
Ну а это-то как вообще к облакам относится? Наоборот бы, изолировать логично.
если я верно понял, то как раз развёрывание облака в компании, в случае если данный закон затрагивается. Иначе облако можно и в удаленном датацентре развернуть.
Так что, тут идёт изолирование в локальном облаке.
Основные моменты которые вы не учитываете в своих рассуждениях – это технология оркестровки и бюджеты использования ресурсов.
1. Оркестровка — это автоматизация сквозных комплексных процессов управления виртуальной средой. Данное решение позволяет высвобождать ресурсы остановленных виртуальных машин и возвращать их в пул свободных ресурсов за считанные минуты. Это существенно повышает утилизацию виртуальных ресурсов. Нужно так же учитывать, что высвобожденные ресурсы — прежде всего CPU и оперативная память, использование которых универсально для любых “других мест”. Важным аспектом также является высвобождение лицензий, например для ОС Microsoft в разрезе автоматического освобождения и регистрации в центре лицензий Microsoft. Увеличение ресурсов в ~ 3 раза доcтигаеться как раз за счет автоматизации. Безграмотность организации тут совсем не причем. И, естественно, это экспертная оценка для конкретного кейса, а не сферической абстракции.
2. Распределение стоимости потребления ресурсов на проекты выполняется на основе потребления. Причем с детализацией до часа, что мотивирует ответственных менеджеров следить за освобождением неиспользуемых ресурсов, так как бюджеты для проектов имеют ограничения. Если бы не было детального учета потребления и счета выставлялись бы на месячной основе, то, естественно, менеджеры не занимались более детальным контролем потребления. Переход на почасовую оценку или на оценку по объему потребления имеет смысл именно при наличии платформы управления облаком, которая автоматизирует процессы предбиллинга, сбора использования ресурсов и высвобождения ресурсов. В противном случае такой подход не будет работать.
3. Про изоляцию — так частное облако и является изолированной средой. Другое дело, если мы говорим о гетерогенном облаке, когда могут использоваться ресурсы как частного облака, так и публичного (например Амазона).
1. Оркестровка — это автоматизация сквозных комплексных процессов управления виртуальной средой. Данное решение позволяет высвобождать ресурсы остановленных виртуальных машин и возвращать их в пул свободных ресурсов за считанные минуты. Это существенно повышает утилизацию виртуальных ресурсов. Нужно так же учитывать, что высвобожденные ресурсы — прежде всего CPU и оперативная память, использование которых универсально для любых “других мест”. Важным аспектом также является высвобождение лицензий, например для ОС Microsoft в разрезе автоматического освобождения и регистрации в центре лицензий Microsoft. Увеличение ресурсов в ~ 3 раза доcтигаеться как раз за счет автоматизации. Безграмотность организации тут совсем не причем. И, естественно, это экспертная оценка для конкретного кейса, а не сферической абстракции.
2. Распределение стоимости потребления ресурсов на проекты выполняется на основе потребления. Причем с детализацией до часа, что мотивирует ответственных менеджеров следить за освобождением неиспользуемых ресурсов, так как бюджеты для проектов имеют ограничения. Если бы не было детального учета потребления и счета выставлялись бы на месячной основе, то, естественно, менеджеры не занимались более детальным контролем потребления. Переход на почасовую оценку или на оценку по объему потребления имеет смысл именно при наличии платформы управления облаком, которая автоматизирует процессы предбиллинга, сбора использования ресурсов и высвобождения ресурсов. В противном случае такой подход не будет работать.
3. Про изоляцию — так частное облако и является изолированной средой. Другое дело, если мы говорим о гетерогенном облаке, когда могут использоваться ресурсы как частного облака, так и публичного (например Амазона).
1. Почему же, как раз учитываю, и писал об этом, но чтобы разница была в три раза, надо, чтобы в среднем 3/4 ресурсов простаивало в одном месте, и в то же время была необходима в других местах, и это должно быть устойчивой ситуацией. Очень странный кейс. Либо вы некорректно оцениваете эту разницу всё же, либо Организация распределения ресурсов до облака была всё же отвратительной.
А с экономией лицензий я и не спорил — если возможно их освобождать, и они не оплачиваются какое-то время, то это конечно выгодно.
Мне тут вообще не о чем спорить, т.к. я не в курсе, как производится лицензирование продуктов Microsoft. =)
2. С точки зрения повышения ответственности в расходовании ресурсов да полезно, согласен.
3. Это не изоляция. В данном случае — увеличивается количество пресонала, который теоретически может получить доступ к этим данным, даже если не рассматривать техническую сторону вопроса. Изоляция будет если всё это будет варится в рамках отдельного отдела и отдельных серверов.
А с экономией лицензий я и не спорил — если возможно их освобождать, и они не оплачиваются какое-то время, то это конечно выгодно.
Мне тут вообще не о чем спорить, т.к. я не в курсе, как производится лицензирование продуктов Microsoft. =)
2. С точки зрения повышения ответственности в расходовании ресурсов да полезно, согласен.
3. Это не изоляция. В данном случае — увеличивается количество пресонала, который теоретически может получить доступ к этим данным, даже если не рассматривать техническую сторону вопроса. Изоляция будет если всё это будет варится в рамках отдельного отдела и отдельных серверов.
1. Почему же, как раз учитываю, и писал об этом, но чтобы разница была в три раза, надо, чтобы в среднем 3/4 ресурсов простаивало в одном месте, и в то же время была необходима в других местах, и это должно быть устойчивой ситуацией. Очень странный кейс. Либо вы некорректно оцениваете эту разницу всё же, либо Организация распределения ресурсов до облака была всё же отвратительной.
Скорее всего " Организация распределения ресурсов до облака была всё же отвратительной". Но, ИМХО, это может зависеть не только от кривости рук администраторов, но и от множества «политических» составляющих. Использование же облака позволяет нивелировать многие вопросы.
теоретически может получить доступ к этим данным
Теоретически можно получить доступ хоть к серверам Пентагона, но это же теоретически.
1) Частное облако для экономии ресурсов — фейк. Даже наоборот, все эти потуги с виртуализацией увеличивают требования к железу, по сравнению с обычным размещением. Другое дело, что управление всем зоопарком при виртуализации гораздо удобнее, но об этом как раз и не написано.
2) Лицензирование почти у всех вендоров сейчас учитывает виртуализацию. А вообще может оказаться даже дороже из-за overcommit ядер, как например для MS SQL Server.
3) «масштабирование без боли» требует большого резерва мощностей, которые стоят денег и греют воздух. Это особенно касается тестовых сред.
Реальная польза виртуализации получается когда приложения знают об этой самой виртуализацией и могут автоматически подстривать потребление ресурссов под профиль использования.
На примере с порталом — в рабочее время поднимать больше виртуалок с веб-серверами для облуживания запросов, а в нерабочее время поднимать backend серверы для обхода и построения поискового индекса.
Увы готовых таких решений для private cloud я пока еще не видел.
2) Лицензирование почти у всех вендоров сейчас учитывает виртуализацию. А вообще может оказаться даже дороже из-за overcommit ядер, как например для MS SQL Server.
3) «масштабирование без боли» требует большого резерва мощностей, которые стоят денег и греют воздух. Это особенно касается тестовых сред.
Реальная польза виртуализации получается когда приложения знают об этой самой виртуализацией и могут автоматически подстривать потребление ресурссов под профиль использования.
На примере с порталом — в рабочее время поднимать больше виртуалок с веб-серверами для облуживания запросов, а в нерабочее время поднимать backend серверы для обхода и построения поискового индекса.
Увы готовых таких решений для private cloud я пока еще не видел.
1) Частное облако/виртуализация экономит не ресурсы, а деньги. Уже закупленные ресурсы никак не сэкономишь (если только в аренду сдавать), а вот эффективно их использовать и закупать — можно. Про требования к железу посмотрите ссылочку. Виртуализация, конечно, увеличивает требования к железу, но на такие копейки, что даже не интересно разговаривать.
2) Это «учитывание» — палка о двух концах. Причем хороших концов существенно больше.
3) «масштабирование» это не просто наращивание инстансов (как в примере с веб-серверами), а гораздо более широкое понятие. Как правило, это означает возможность увеличивать мощности (ресурсы) инфраструктуры при сохранении ее однородности.
2) Это «учитывание» — палка о двух концах. Причем хороших концов существенно больше.
3) «масштабирование» это не просто наращивание инстансов (как в примере с веб-серверами), а гораздо более широкое понятие. Как правило, это означает возможность увеличивать мощности (ресурсы) инфраструктуры при сохранении ее однородности.
1) Если ресурсов нет, то надо закупать. Если ресурсы есть, то можно и без виртуализации поднимать приложения на серверах. Где экономия?
3) Покупайте одинаковые серваки и будет вам однородность. Тем более, из пункта 1 мы понимаем что серваки уже закуплены. Какую проблему тут решает виртуализация?
3) Покупайте одинаковые серваки и будет вам однородность. Тем более, из пункта 1 мы понимаем что серваки уже закуплены. Какую проблему тут решает виртуализация?
1) Экономия в эффективности использования оборудования и в прозрачности затрат. Без виртуализации поднимая множество приложений на одном физическом сервере в рамках одной ОС вы очень быстро столкнетесь с проблемами совместимости, влиянием приложений друг на друга (без возможности развести их по потреблению ресурсов), отказ сразу множества приложений при глюке одного из них и т.д. и т.п. Виртуализация решает эти проблемы за счет изоляции приложений на уровне ОС, плюс к этому уменьшает время простоя за счет защиты HA на уровне кластера.
3) Вы как то очень примитивно все понимаете. Однородность — это не одинаковые серваки (кстати, в случае виртуализации, одинаковые серваки в принципе не обязательны). Однородность, это сохранение правил игры для пользователей и обслуживающего персонала. Т.е. вне зависимости от конкретного железа управление инфраструктурой и ее использование требует того же самого опыта.
3) Вы как то очень примитивно все понимаете. Однородность — это не одинаковые серваки (кстати, в случае виртуализации, одинаковые серваки в принципе не обязательны). Однородность, это сохранение правил игры для пользователей и обслуживающего персонала. Т.е. вне зависимости от конкретного железа управление инфраструктурой и ее использование требует того же самого опыта.
1) Я об этом и писал. Но вот в статье п1 — экономия на железе. А по факту не на железе, а на удобстве.
3) Без конкретной прикладной задачи слова ни о чем. А с конкретной задачей уже надо считать имеет смысл виртуализировать или нет.
3) Без конкретной прикладной задачи слова ни о чем. А с конкретной задачей уже надо считать имеет смысл виртуализировать или нет.
1) Купить 120 физических серверов или шесть, на которых будут 120 виртуальных? Это по вашему не экономия на железе? Поверьте опыту, такая степень консолидации — далеко не предел. И вы не об этом писали совсем.
3) У меня ощущение возникает, что я сейчас пытаюсь рассказать о преимуществах самобеглой повозки перед гужевым транспортом. Нет, разумеется, есть такие сценарии, когда лошадка будет лучше. Но большая часть потребителей уже предпочла «грузовик».
3) У меня ощущение возникает, что я сейчас пытаюсь рассказать о преимуществах самобеглой повозки перед гужевым транспортом. Нет, разумеется, есть такие сценарии, когда лошадка будет лучше. Но большая часть потребителей уже предпочла «грузовик».
Проблема то не в самих серверах, а в том что не все приложения смогут захоститься на одном сервере. Хостить несколько приложений на одном сервере выгоднее чем хостить несколько виртуалок, не находите? Тут надо смотреть на конкретные приложения и считать. Но это НЕУДОБНО. А вот закупить железа с запасом раза в 3, а потом виртуализацией нарезать отдельные машины УДОБНО, но не очень эффективно по деньгам. Об этом я писал, а не о том, о чем вы думаете ;)
Проблема то не в самих серверах, а в том что не все приложения смогут захоститься на одном сервере.
Таки могут. Называется это контейнерная виртуализация. Пример: Parallels Virtuozo Containers
Тут надо смотреть на конкретные приложения и считать. Но это НЕУДОБНО. А вот закупить железа с запасом раза в 3, а потом виртуализацией нарезать отдельные машины УДОБНО, но не очень эффективно по деньгам
Неудобно, простите, шубу в трусы заправлять. А считать нужно всегда.
Нормальные проекты по виртуализации чего-либо проходят с предварительной оценкой требуемых ресурсов. Погрешность 10-20% в большую сторону. Не в три раза. Читайте про VMware Capacity Planer, например. Про шаринг ресурсов, активную и неактивную память, компрессию и т.п. я вам даже не буду пытаться рассказывать.
—
Об этом я писал
Вот о чем вы писали:
Частное облако для экономии ресурсов — фейк. Даже наоборот, все эти потуги с виртуализацией увеличивают требования к железу, по сравнению с обычным размещением
Это полная ерунда.
То есть вы таки утверждаете что переход от кусочной виртуализации (как оно обычно бывает) к private cloud позволит что-то сэкономить на железе? За счет чего?
Где, интересно, я это утверждаю?
Виртуализация — да, позволяет экономить на железе (в том числе «кусочная»). См. выше.
Частное облако — способ предоставлять «ресурсы как сервис» и брать за это деньги (прозрачно для потребителя). Ресурсами могут быть и аппаратные серверы, и даже преднастроенные кучки оборудования. Вообще без использования серверной виртуализации в принципе.
Виртуализация — да, позволяет экономить на железе (в том числе «кусочная»). См. выше.
Частное облако — способ предоставлять «ресурсы как сервис» и брать за это деньги (прозрачно для потребителя). Ресурсами могут быть и аппаратные серверы, и даже преднастроенные кучки оборудования. Вообще без использования серверной виртуализации в принципе.
Коллеги, мне кажется, в пылу беседы, вы немного подзабыли про такие важные вещи, которые сейчас вовсю используются в виртуализации, как механизмы дедупликации данных: области оперативной памяти и жесткого диска, которые содержат одинаковые участки данных, при нехватке ресурсов бъются на более мелкие и вместо того, чтобы хранить одни и те же участки несколько раз, создаются ссылки. Таким образом, используя простую виртуализацию(даже без облачных «докруток» сверху), мы получаем довольно внушительную экономию ресурсов. На счет контейнеров: хотя разработчики делают все, чтобы максимально приблизить среду исполнения к той, что имеется в родной ОС, не все ПО совместимо с технологиями контейнеризации — это все нужно тестировать и проверять. Могу сказать, что, например, не каждое ПО будет успешно работать под тем же виндовым терминальником. Тут то нам, как раз, и приходит на помощь виртуализация со своими «преферансом и куртизанками»(я про дедупликацию и перераспределение ресурсов без прерывания сервиса). Ситуаций, когда такой подход наиболее оптимален море: переходить на другой софт, который будет работать с вашей средой — это не только затраты на лицензии и внедрение, у вас еще и пользователи будут страдать, пока не привыкнут, а это, в свою очередь, хотя и трудноизмеряемые, но убытки. Или же у вас дорогущее специализированное ПО, производитель которого канул в лету вместе со всем саппортом… В этом случае,(как минимум) пока вы не найдете иного решения, вашу систему, находящуюся на издыхании и от которой зависит серьезная доля выручки вашей компании, спасет, с большой долей вероятности, только виртуализация. В общем: про преимущества виртуализации было сказано, а еще больше сделано немало начинаю с того же продукта VMware Server. Если не верится, что земля круглая — дело ваше. Да, согласен, что она бывает плоской, но это в очень редких случаях, когда, например, мы рассматриваем пространство состоящее всего из двух измерений(это не сарказм — в жизни бывают разные ситуации).
А я то как под эту раздачу попал? :)
Как то оказались вы в одной ветке камментов =)
Просто я как бы верю, что земля ээ шарообразная и про все остальное тоже в курсе.
Не принимайте на свой счет. А земля, как я написал, иногда бывает и плоская;)
Плоская земля не бывает. И Земля. Вы как-то вообще очень вольно пишете. От контейнеров легко перепрыгиваете к терминальным серверам, дедупликацию причисляете к свойствам виртуализации, в общем вот как раз таким некорректным текстом и рождаете несознательных троллей вроде gandjustas. Без обид.
Земля бывает плоской. В двухмерном мире. Просто, я человек не особо любящий категоричность и старающийся смотреть на вещи под разными углами. Живя в нашей чудесной стране, я понял что словосочетание «не бывает» довольно редко соответствует действительности, поэтому, извините, позволяю себе иногда такие вольности. ЕМНИП, терминальный сервер это тоже некий вид контейнеризации(если утрировать). А дедупликация — это дедупликация. Ничьим свойством она не является, но ее использование в виртуализации значительно способствует уплотнению ресурсов. А тролли… «Если что-то может быть понято неверно — оно будет понято неверно» — одна из мудрых вариаций на тему законов Мерфи. Обид никаких, да и изначально в споре я был на вашей стороне, просто мой комментарий был не совсем верно сформулирован/воспринят(нужное подчеркнуть). Так что, поддерживаю ваше чаяние разойтись с миром)
В двумерном мире нет земли. И Земли тоже. Это вполне себе реальные объекты реального мира. Вы можете фантазировать на тему проекции шара на плоскость или тому подобного, но не можете говорить «земля бывает плоской». Потому что 1) вы говорите о грунте (верхний обычно плодородный слой планеты Земля); 2) или планете Земля (третья от Солнца планета). В первом случае, в 2D мире нет слоев. Во втором случае, речь о планете, которая суть — «шар». Категоричность и строгость рассуждений — очень разные вещи. Когда вы подменяете понятия, пытаясь найти аналогию или пошутить, сама ценность мысли испаряется, вы путаете сам себя. Это хороший совет, который сильно облегчит общение с серьезными Заказчиками, особенно с гоской.
Терминальный сервер к контейнерам не имеет никакого отношения. Потому что отсутствует ключевой момент — изоляция. Потоковая доставка приложений (ThinApp, часть XenApp, и т.п.) не является терминальной службой, но иногда входит в состав комплекса доставки приложений (тот же XenApp). Вот она, зачастую, изоляцию обеспечивает.
Дедупликация способствует уплотнению ресурсов и в отрыве от виртуализации. Т.е. преимуществом не является. Про VMware TPS рассказывать не надо, а то я вас расстрою.
:) Я за мир, конечно, и за качество контента в блоге уважаемой компании :)
Терминальный сервер к контейнерам не имеет никакого отношения. Потому что отсутствует ключевой момент — изоляция. Потоковая доставка приложений (ThinApp, часть XenApp, и т.п.) не является терминальной службой, но иногда входит в состав комплекса доставки приложений (тот же XenApp). Вот она, зачастую, изоляцию обеспечивает.
Дедупликация способствует уплотнению ресурсов и в отрыве от виртуализации. Т.е. преимуществом не является. Про VMware TPS рассказывать не надо, а то я вас расстрою.
:) Я за мир, конечно, и за качество контента в блоге уважаемой компании :)
Земля(ну, извините, что из-за невнимательности не поставил заглавную букву), приплюснута с полюсов — поэтому, это даже не шар. Ладно, тут зацепились за мою вольную интерпретацию фактов. Ок, убедили — не плоская. А изоляция нынче даже в десктопных осях присутствует(в виде контейнеризации и виртуализации). И чем по вашему «разделение пользовательских пространств» или их «изоляция» не простейший пример контейнеризации? Тут уже все сводится даже не к определениям, а маркетинговым ярлыкам. А про «отрыв от виртуализации» вообще не понятно… Я понимаю, что виртуализация и дедупликация — разные вещи, но, в основном, они идут рука об руку. Про нее я написал, потому что в обсуждении была мысль о перерасходе ресурсов при использовании виртуализации(накладные расходы) и, кстати, поддерживал вашу мысль о том, что они «копеечны». TPS не панацея, но бывают сценарии при которых экономиться до 40% оперативы. Да и не TPSом единым… Не зря VMware купили малоизвестную для нашего обывателя контору под названием Virstro — чтобы еще больше уплотнить ресурсы(тут уже не ОЗУ, а СХД)…
А давайте, мы с вами, если уж на то пошло, придем к единому знаменателю уже в ЛС и резюмируем его здесь? Честно, устал уже.
А давайте, мы с вами, если уж на то пошло, придем к единому знаменателю уже в ЛС и резюмируем его здесь? Честно, устал уже.
Ок, с плоской Землей разобрались.
Это отличный пример подмены понятий. Вместо того, чтобы взять определение объекта и подобрать подходящие объекты, вы поступаете ровно наоборот. Берете произвольное множество объектов и пытаетесь подогнать под него уже принятое определение.
Про дедупликацию даже комментировать не хочется, вы там уже не просто за уши факты притягиваете, вы эти уши уже оторвали и на ногу намотали.
А какой смысл в ЛС? Я не пытаюсь вас исправить, поздно уже. Да и какой смысл искать компромисс между фактом и вымыслом?
И чем по вашему «разделение пользовательских пространств» или их «изоляция» не простейший пример контейнеризации?
Это отличный пример подмены понятий. Вместо того, чтобы взять определение объекта и подобрать подходящие объекты, вы поступаете ровно наоборот. Берете произвольное множество объектов и пытаетесь подогнать под него уже принятое определение.
Про дедупликацию даже комментировать не хочется, вы там уже не просто за уши факты притягиваете, вы эти уши уже оторвали и на ногу намотали.
А давайте, мы с вами, если уж на то пошло, придем к единому знаменателю уже в ЛС и резюмируем его здесь? Честно, устал уже.
А какой смысл в ЛС? Я не пытаюсь вас исправить, поздно уже. Да и какой смысл искать компромисс между фактом и вымыслом?
windows detected!
Sign up to leave a comment.
Про частные «облака»: что и как обычно делается в России, ликбез и основные проблемы