3. Имелось ввиду использование старых полок с данными под новыми головами. Такой возможности по прежнему нет, т.е. для миграции нужно хранилище «посредник» + перенастройка
Про остальное уже ответили выше, лучше прокомментируйте лучше вот это
Выглядит это так, словно не из «хорошей» системы сделали «отличную», а совсем наоборот — старая система была так плоха (архитектурно), что понадобился полный редизайн. Ну не суть.
Насколько я понял, при включении блочной дедупликации LUN автоматически становится thin. На старых VNX это приводило к значительной потери производительности. А помимо потери производительности, приводило еще и к фрагментации. Добавление поверх этого дела дедупликации так же должно повысить фрагментацию при высвобождении блоков во время постпроцессинга. В общем что там с производительностью будет — непонятно. И что с файловыми томами? Компрессия?
А актив актив полноценный? Т.е. он только на «просто» RAID или на пулы тоже? В старых VNX переключить пул было проблемой.
Какая-то хвалебная ода получилась. И везде софт софт софт.
1. Так и не понял, увеличение производительности получено благодаря аппаратному масштабированию (новые процы, больше ядер) или оптимизацией софта?
2. А владельцы старых VNX получат плюшки нового софта? Если нет, то почему?
3. А старые VNX можно как-то относительно просто обновить до новых? Хотя бы полки с дисками?
4. Размер блока при дедупликации какой?
Именно консистентный и подходит, поскольку основная цель этого типа снапшота — подготовка ВМ к резервному копированию, а значит обеспечение последующего корректного восстановления.
Ага, я понял, в принципе задумка интересная, короб с входным и выходным отверстием? А до гриля не довели потому что хотели чтобы БП поток воздуха захватывал? Наверное стоит все же перегородить полностью корпус пополам (исключая дырку от кулера). Тогда сосать будет спереди и сзади (гриль, продувка БП), а выдувать в щели сверху корпуса и вторую часть гриля (хотя верхнюю я бы закрыл)
Не ясно как вы изначально хотели распределили потоки (горячий, холодный). Как я понимаю, в реализованной версии кулер одним своим краем заползает на щель внизу корпуса (кстати, почему без пылезащиты?). Оттуда подсасывается воздух и, пройдя сквозь ребра, распределяется по материнской плате, причем его часть подмешивается во входящий поток. Существующий объем воздуха продолжает циркулировать внутри корпуса (кулер сосет его обратно с большой скоростью, т.к. рядом с его ребрами крышка, скорость потока велика, подсос будет неизбежен имхо), постепенно нагреваясь. Исход нагретого воздуха обеспечивается в основном нагнетанием избыточного давления. Т.е. конвекция здесь почти не работает.
В новой редакции должно получится лучше, хотя может быть стоит еще прикрыть гриль. Не пробовали провести испытания с дымом в акриловом корпусе? Т.е. нарезать склеить прототип (можно из оргстекла) и повтыкать?
И чем по вашему «разделение пользовательских пространств» или их «изоляция» не простейший пример контейнеризации?
Это отличный пример подмены понятий. Вместо того, чтобы взять определение объекта и подобрать подходящие объекты, вы поступаете ровно наоборот. Берете произвольное множество объектов и пытаетесь подогнать под него уже принятое определение.
Про дедупликацию даже комментировать не хочется, вы там уже не просто за уши факты притягиваете, вы эти уши уже оторвали и на ногу намотали.
А давайте, мы с вами, если уж на то пошло, придем к единому знаменателю уже в ЛС и резюмируем его здесь? Честно, устал уже.
А какой смысл в ЛС? Я не пытаюсь вас исправить, поздно уже. Да и какой смысл искать компромисс между фактом и вымыслом?
В двумерном мире нет земли. И Земли тоже. Это вполне себе реальные объекты реального мира. Вы можете фантазировать на тему проекции шара на плоскость или тому подобного, но не можете говорить «земля бывает плоской». Потому что 1) вы говорите о грунте (верхний обычно плодородный слой планеты Земля); 2) или планете Земля (третья от Солнца планета). В первом случае, в 2D мире нет слоев. Во втором случае, речь о планете, которая суть — «шар». Категоричность и строгость рассуждений — очень разные вещи. Когда вы подменяете понятия, пытаясь найти аналогию или пошутить, сама ценность мысли испаряется, вы путаете сам себя. Это хороший совет, который сильно облегчит общение с серьезными Заказчиками, особенно с гоской.
Терминальный сервер к контейнерам не имеет никакого отношения. Потому что отсутствует ключевой момент — изоляция. Потоковая доставка приложений (ThinApp, часть XenApp, и т.п.) не является терминальной службой, но иногда входит в состав комплекса доставки приложений (тот же XenApp). Вот она, зачастую, изоляцию обеспечивает.
Дедупликация способствует уплотнению ресурсов и в отрыве от виртуализации. Т.е. преимуществом не является. Про VMware TPS рассказывать не надо, а то я вас расстрою.
:) Я за мир, конечно, и за качество контента в блоге уважаемой компании :)
Шапка не совсем корректна, согласен. Да и по тексту достаточно эмоциональных высказываний и недоговариваний (как про ресурсы колл-центра). Но все же топик про конкретный пример, отсюда и все нестыковки.
Плоская земля не бывает. И Земля. Вы как-то вообще очень вольно пишете. От контейнеров легко перепрыгиваете к терминальным серверам, дедупликацию причисляете к свойствам виртуализации, в общем вот как раз таким некорректным текстом и рождаете несознательных троллей вроде gandjustas. Без обид.
Виртуализация — да, позволяет экономить на железе (в том числе «кусочная»). См. выше.
Частное облако — способ предоставлять «ресурсы как сервис» и брать за это деньги (прозрачно для потребителя). Ресурсами могут быть и аппаратные серверы, и даже преднастроенные кучки оборудования. Вообще без использования серверной виртуализации в принципе.
Тут надо смотреть на конкретные приложения и считать. Но это НЕУДОБНО. А вот закупить железа с запасом раза в 3, а потом виртуализацией нарезать отдельные машины УДОБНО, но не очень эффективно по деньгам
Неудобно, простите, шубу в трусы заправлять. А считать нужно всегда.
Нормальные проекты по виртуализации чего-либо проходят с предварительной оценкой требуемых ресурсов. Погрешность 10-20% в большую сторону. Не в три раза. Читайте про VMware Capacity Planer, например. Про шаринг ресурсов, активную и неактивную память, компрессию и т.п. я вам даже не буду пытаться рассказывать.
—
Об этом я писал
Вот о чем вы писали:
Частное облако для экономии ресурсов — фейк. Даже наоборот, все эти потуги с виртуализацией увеличивают требования к железу, по сравнению с обычным размещением
1) Купить 120 физических серверов или шесть, на которых будут 120 виртуальных? Это по вашему не экономия на железе? Поверьте опыту, такая степень консолидации — далеко не предел. И вы не об этом писали совсем.
3) У меня ощущение возникает, что я сейчас пытаюсь рассказать о преимуществах самобеглой повозки перед гужевым транспортом. Нет, разумеется, есть такие сценарии, когда лошадка будет лучше. Но большая часть потребителей уже предпочла «грузовик».
1) Экономия в эффективности использования оборудования и в прозрачности затрат. Без виртуализации поднимая множество приложений на одном физическом сервере в рамках одной ОС вы очень быстро столкнетесь с проблемами совместимости, влиянием приложений друг на друга (без возможности развести их по потреблению ресурсов), отказ сразу множества приложений при глюке одного из них и т.д. и т.п. Виртуализация решает эти проблемы за счет изоляции приложений на уровне ОС, плюс к этому уменьшает время простоя за счет защиты HA на уровне кластера.
3) Вы как то очень примитивно все понимаете. Однородность — это не одинаковые серваки (кстати, в случае виртуализации, одинаковые серваки в принципе не обязательны). Однородность, это сохранение правил игры для пользователей и обслуживающего персонала. Т.е. вне зависимости от конкретного железа управление инфраструктурой и ее использование требует того же самого опыта.
1) Частное облако/виртуализация экономит не ресурсы, а деньги. Уже закупленные ресурсы никак не сэкономишь (если только в аренду сдавать), а вот эффективно их использовать и закупать — можно. Про требования к железу посмотрите ссылочку. Виртуализация, конечно, увеличивает требования к железу, но на такие копейки, что даже не интересно разговаривать.
2) Это «учитывание» — палка о двух концах. Причем хороших концов существенно больше.
3) «масштабирование» это не просто наращивание инстансов (как в примере с веб-серверами), а гораздо более широкое понятие. Как правило, это означает возможность увеличивать мощности (ресурсы) инфраструктуры при сохранении ее однородности.
В топике дан конкретный сценарий, в котором «частное облако» хорошо работает. Так что ваши контр-примеры (вполне разумные, для сферического коня в вакууме) здесь не подходят.
Обратите внимание, речь идет о внутренней лаборатории в компании интеграторе. Ребята поступили очень грамотно, и в итоге первоначальные инвестиции окупают именно те подразделения, которым лаборатория нужна. Это полезно и для самих подразделений (стенды не застаиваются, ресурсы экономятся), и для руководства (прозрачность затрат, можно посчитать сроки окупаемости, понять ставку маржинальности).
Есть и другие подобные сценарии, уже внутри обычных коммерсантов. Как правило это компании, в которых департамент ИТ выделен в отдельное «хозрасчетное» подразделение.
А на остальные вопросы ответить забыли?
Про остальное уже ответили выше, лучше прокомментируйте лучше вот это
Насколько я понял, при включении блочной дедупликации LUN автоматически становится thin. На старых VNX это приводило к значительной потери производительности. А помимо потери производительности, приводило еще и к фрагментации. Добавление поверх этого дела дедупликации так же должно повысить фрагментацию при высвобождении блоков во время постпроцессинга. В общем что там с производительностью будет — непонятно. И что с файловыми томами? Компрессия?
А актив актив полноценный? Т.е. он только на «просто» RAID или на пулы тоже? В старых VNX переключить пул было проблемой.
1. Так и не понял, увеличение производительности получено благодаря аппаратному масштабированию (новые процы, больше ядер) или оптимизацией софта?
2. А владельцы старых VNX получат плюшки нового софта? Если нет, то почему?
3. А старые VNX можно как-то относительно просто обновить до новых? Хотя бы полки с дисками?
4. Размер блока при дедупликации какой?
В новой редакции должно получится лучше, хотя может быть стоит еще прикрыть гриль. Не пробовали провести испытания с дымом в акриловом корпусе? Т.е. нарезать склеить прототип (можно из оргстекла) и повтыкать?
Это отличный пример подмены понятий. Вместо того, чтобы взять определение объекта и подобрать подходящие объекты, вы поступаете ровно наоборот. Берете произвольное множество объектов и пытаетесь подогнать под него уже принятое определение.
Про дедупликацию даже комментировать не хочется, вы там уже не просто за уши факты притягиваете, вы эти уши уже оторвали и на ногу намотали.
А какой смысл в ЛС? Я не пытаюсь вас исправить, поздно уже. Да и какой смысл искать компромисс между фактом и вымыслом?
Терминальный сервер к контейнерам не имеет никакого отношения. Потому что отсутствует ключевой момент — изоляция. Потоковая доставка приложений (ThinApp, часть XenApp, и т.п.) не является терминальной службой, но иногда входит в состав комплекса доставки приложений (тот же XenApp). Вот она, зачастую, изоляцию обеспечивает.
Дедупликация способствует уплотнению ресурсов и в отрыве от виртуализации. Т.е. преимуществом не является. Про VMware TPS рассказывать не надо, а то я вас расстрою.
:) Я за мир, конечно, и за качество контента в блоге уважаемой компании :)
Виртуализация — да, позволяет экономить на железе (в том числе «кусочная»). См. выше.
Частное облако — способ предоставлять «ресурсы как сервис» и брать за это деньги (прозрачно для потребителя). Ресурсами могут быть и аппаратные серверы, и даже преднастроенные кучки оборудования. Вообще без использования серверной виртуализации в принципе.
Таки могут. Называется это контейнерная виртуализация. Пример: Parallels Virtuozo Containers
Неудобно, простите, шубу в трусы заправлять. А считать нужно всегда.
Нормальные проекты по виртуализации чего-либо проходят с предварительной оценкой требуемых ресурсов. Погрешность 10-20% в большую сторону. Не в три раза. Читайте про VMware Capacity Planer, например. Про шаринг ресурсов, активную и неактивную память, компрессию и т.п. я вам даже не буду пытаться рассказывать.
—
Вот о чем вы писали:
Это полная ерунда.
3) У меня ощущение возникает, что я сейчас пытаюсь рассказать о преимуществах самобеглой повозки перед гужевым транспортом. Нет, разумеется, есть такие сценарии, когда лошадка будет лучше. Но большая часть потребителей уже предпочла «грузовик».
3) Вы как то очень примитивно все понимаете. Однородность — это не одинаковые серваки (кстати, в случае виртуализации, одинаковые серваки в принципе не обязательны). Однородность, это сохранение правил игры для пользователей и обслуживающего персонала. Т.е. вне зависимости от конкретного железа управление инфраструктурой и ее использование требует того же самого опыта.
2) Это «учитывание» — палка о двух концах. Причем хороших концов существенно больше.
3) «масштабирование» это не просто наращивание инстансов (как в примере с веб-серверами), а гораздо более широкое понятие. Как правило, это означает возможность увеличивать мощности (ресурсы) инфраструктуры при сохранении ее однородности.
Обратите внимание, речь идет о внутренней лаборатории в компании интеграторе. Ребята поступили очень грамотно, и в итоге первоначальные инвестиции окупают именно те подразделения, которым лаборатория нужна. Это полезно и для самих подразделений (стенды не застаиваются, ресурсы экономятся), и для руководства (прозрачность затрат, можно посчитать сроки окупаемости, понять ставку маржинальности).
Есть и другие подобные сценарии, уже внутри обычных коммерсантов. Как правило это компании, в которых департамент ИТ выделен в отдельное «хозрасчетное» подразделение.