По данным (http://www.serverwatch.com/server-trends/survey-51-of-x86-se...) отчёта, опубликованного сервисом 451 Research TheInfoPro, в среднем 51% серверов на базе архитектуры x86, используемых принявшими участие в опросе средними и крупными компаниями США и Европы, работают с использованием средств виртуализации. Год назад данный показатель был на 13% меньше.
URL: http://www.serverwatch.com/server-trends/survey-51-of-x86-se...
Новость: https://www.opennet.ru/opennews/art.shtml?num=35880
Ну, кто там вопил что виртуализация - "не нyжна"?
Курение тоже не нужно, от него рак лёгких. Тем не менее, N%% взрослого населения курит. Тут то же самое. Можно, молодёжно.
Кроме моды и молодежности, оно еще и ...
1) Позволяет полнее прогрузить мощный сервер, почти не в ущерб изоляции. PROFIT.
2) Упрощает разворачивание конфигурации и повышает гибкость маневрирования.
3) Позволяет балансировать нагрузку в больших конфигурациях. Если некий сервак зашивается, а некие другие недогружены, перетащить между ними виртуалку - фигня вопрос. В идеальном случае это будет прозрачно и без остановки сервера.
4) Есть такая хорошая штука - снапшоты. Очень удобно когда можно в случае факапа вернуть все в вид как было. Замечательная вещь для системокрушильных экспериментов: даже после полного дестроя все возвращается "как было" за считанные секунды. На реальной железке - лезем за "бутявкой" и тратим в ..цать раз больше времени.
5) При необходимости выключить некий сервер (на обслуживание, etc) можно избежать длительного даунтайма для того что там на нем работало. В идеале - машины прозрачно мигрируют на соседние хосты и никто ничего вообще не замечает.
+1
Да, для экспериментов виртуалка - незаменимая вещь.
Да, если бы еще все горе-одмины это понимали. А то на виртуализацию (КВМ, если кому интересно) искоса смотрят, тихонько желая чтобы оно сдохло все в один момент. Причина проста: сложно и непонятно. Бриджи, вланы, ЛВМ, снапшоты и, о Боже, ЛИНУКС!
Гнать таких надо. Ссаными тряпками и ср@ной метлой. Не думаю что в 2013 году есть огромная проблема найти желающих админить именно так и такое. Правда есть риск нарваться на бокланов которые на виртуализацию смотрят только потому что "это типа круто, Вася так сказал". Уровень понимания предмета такими гражданами предсказуем.
> Не думаю что в 2013 году есть огромная проблема найти желающих админить именно так и такоеВ Минске, например, крайне сложно найти хорошего админа :).
> В Минске, например, крайне сложно найти хорошего админа :).Сдается мне что это далеко не единственная проблема в Минске.
>> В Минске, например, крайне сложно найти хорошего админа :).
> Сдается мне что это далеко не единственная проблема в Минске.В России не лучше.
> В России не лучше.ИМХО все-таки получше. Хотя спору нет, до идеала - как до пекина раком.
Это везде проблема... Всякие хероку не на ровном месте возникли... Это типичный аутсорс администраторских услуг... )
VirtualPC же!
> VirtualPC же!Слоупоки же. Это скуплено на корню мелкомякотью и превращено в hyper-v. Средства управления коего таковы что даже врагу не пожелаешь.
6) Позволяет про.ирать скорости доступа к винтам на сетевых фс.
>Кроме моды и молодежности, оно еще и ...Звучит как реклама.
А если серьезно - все яйца в одной карзине, это как-то с точки зрения надежности ущербно, не находите? Особенно если учесть что "СЕРВЕРЫ"(а не десктопы), в соседнем магазине не чинятся.
Ну и "МОЩЬНЫЙ СЕРВЕР" это сколько? Насколько мошьный? У меня вот например 24Гб памяти, два проца ксеоновских, 4х ядерных, по 3Ггц и зеркало на SAS-е, полностью сьедает сайт и портал на Битриксе. А еще два i7х компа сьедают терминалы. Третий i7й комп у меня сьедает MS SQL. И.т.п.
Т.е. получается, что очень мошьные серверы обычно под облака, хостинг и вычисления, а остальным и не надо.
> точки зрения надежности ущербно, не находите? Особенно если учесть что "СЕРВЕРЫ"(а
> не десктопы), в соседнем магазине не чинятся.При нормальном сервисном контракте заменяются в течение 48/24/12/6 часов (в зависимости от контракта) с локального склада.
> Ну и "МОЩЬНЫЙ СЕРВЕР" это сколько? Насколько мошьный? У меня вот например
> 24Гб памяти, два проца ксеоновских, 4х ядерных, по 3Ггц и зеркало
> на SAS-е, полностью сьедает сайт и портал на Битриксе.А вы побольше битрикс юзайте :)
> А вы побольше битрикс юзайте :)Вообще не понимаю - что всех как мух на это г-но тянет? Ну отстойная же дрянь. Стоит конских бабок, саппорт при том поганый, код слова доброго не стоит, и вообще кривое насквозь. Зачем вляпываться в ЭТО? Может быть хоть один обдадатель этого крапа объяснит - зачем им именно эта дрянь?
Таки нету совершенно никакой альтернативы, запиленной под реалии этой страны.
> Таки нету совершенно никакой альтернативы, запиленной под реалии этой страны.А какие-такие особенные реалии у этой страны в плане того что умеет битрикс? Довольно дерьмовенькая CMSка вроде. Или вы намекаете что раз у нас в стране г@вна и идиотизмов много - то и CMS должна быть под стать? oO
>> Таки нету совершенно никакой альтернативы, запиленной под реалии этой страны.
> А какие-такие особенные реалии у этой страны в плане того что умеет
> битрикс? Довольно дерьмовенькая CMSка вроде. Или вы намекаете что раз у
> нас в стране г@вна и идиотизмов много - то и CMS
> должна быть под стать? oOТаки вы предложили вполне интересный вариант, хотя я говорил скорее про такие штуки, как например, интеграция с 1С.
> штуки, как например, интеграция с 1С.Такие штуки тоже неплохо вписываются в эту парадигму, кстати.
Чтобы интегрировать CMS с 1с нужен программист для веб и для 1с буквально на 1-3 дня, зависит от задачи. Мы на работе вообще заказами разу в 1с управляли и контент оттуда же выгружали сайт.
> Чтобы интегрировать CMS с 1с нужен программист для веб и для 1с
> буквально на 1-3 дня, зависит от задачи. Мы на работе вообще
> заказами разу в 1с управляли и контент оттуда же выгружали сайт.А стоимость такого решени? Сопровождаемость? Качество? Сроки опять же ориентировочные и могут различаться от раза к разу, так что будь я на месте бизнесмена, которому это нужно сделать быстро, предпочел бы купить коробочное решение, особенно, в случае если в штате сотрудников программистов нету.
> заказами разу в 1с управляли и контент оттуда же выгружали сайт.И получается в результате очередное глючное и неудобное угробище. Знаем мы это дело.
Имхо, главная причина такова: сайты обычно делают не хозяева, а студии. Студии имеют долю от продажи Битрикса клиенту и хотят иметь эти деньги. Многое из того, что клиент хочет, кое-как реализовано в Битриксе, для того, чтобы продать клиенту решение, этого достаточно. Для того, чтобы сделать его таким, какое на самом деле нужно клиенту, придется потрудиться, но оплачивать этот труд опять же клиенту - куда он, подсев на Битрикс, денется?
> имеют долю от продажи Битрикса клиенту и хотят иметь эти деньги.А что им мешает делать сайты на базе бесплатных CMS и вообще не делиться с какими-то левыми крокодилами? Ну, кроме собственного кретинизма? :)
Вы, видимо, не менеджер и не понимаете разницы между "тупо продать" и "сделать и продать", а также между "навариться на дорогом товаре" и "втюхать за деньги бесплатное".Я же говорю - успех Битрикса не в инженерной составляющей, а в интересах {нае}бизнеса.
> Вы, видимо, не менеджер и не понимаете разницы между "тупо продать" и
> "сделать и продать", а также между "навариться на дорогом товаре" и
> "втюхать за деньги бесплатное".Почему же, я вижу как граждане продают черти-что вплоть до самописного наколенного крапа за какие-то совершенно конские бабки. Вот я и не понимаю - зачем какие-то дебилы в этом процессе хотят делиться с какими-то левыми прихлебателями? Дорогой продукт бывает и без них.
> При нормальном сервисном контракте заменяются в течение 48/24/12/6 часовДумаете, у обладателя тазиков на i7 есть хоть какой-то "сервисный контракт"? Судя по описанию оно собрано из г-на и палок "уж как вышло" :)
>А если серьезно - все яйца в одной карзине, это как-то
>с точки зрения надежности ущербно, не находите?
>Особенно если учесть что "СЕРВЕРЫ"(а не десктопы), в соседнем магазине не чинятся.Для этого придумали кластеризацию. Каждое яйцо в двух коризинах. И надёжно и много "яиц".
На прошлой работе было порядка 512 "яиц" на каждых двух серверах.
> Звучит как реклама.Заковывка в том что я не продаю виртуализаторы или что либо относящееся к ним. Я вообще не имею какого либо прямого профита от каких либо виртуализаторов. А вот косвенный в виде повышения моего удобства и упрощения ряда операций - почему бы и нет? Если это и реклама - то только удобства эксплуатации. Не вижу ничего зазорного в "рекламе" технологий которые делают жизнь удобнее.
> А если серьезно - все яйца в одной карзине
Так делают только бакланы. У нормальных людей есть несколько серверов и бэкапы, так что отвал башки на 1 сервере приведет лишь к минимальному даунтайму (if any) и некоторому росту нагрузки на другие хосты из-за перераспределения виртуалок на них. В лучшем случае - если мониторинг показывает что "кулер заглох", "smart полагает что винт скоро умрет" и прочая, что не фатально вот прямща, но при игнорировании станет проблемой - можно вообще все виртуалки сдвинуть с сервака, который надо выключить и чинить его сколько влезет. А те кто пользовался услугами сервисов в виртуалках вообще ничего и не заметят даже в лучшем случае. Т.к. есть такая черная магия как "live миграция".
> Ну и "МОЩЬНЫЙ СЕРВЕР" это сколько? Насколько мошьный?
Любой сервак, который по данным мониторинга имеет достаточно большой idle time, свободную память, неозадаченный I/O и прочая. Т.е. по сути любой недогруженный сервак - хороший кандидат на получение профита за счет виртуализации. Как оно там будет в лично вашей конфигурации - не мои проблемы.
> а остальным и не надо.
Как видим из сабжа - надо. И даже перечисленные вами тазики довольно сложно загрузить на 100% что скулем, что битриксом. Ну разве что вы или обслуживаете чуть ли не полпланеты и это реально нагруженные серваки, или админ у вас на редкость ж@порукий (ну или как вариант программеры, если там какой-то кастомный код).
> У меня вот например
> 24Гб памяти, два проца ксеоновских, 4х ядерных, по 3Ггц и зеркало
> на SAS-е, полностью сьедает сайт и портал на Битриксе.Вы не поверите, насколько можно снизить потребление железа в вашем случае, если перейти на nginx+php-fpm.
Ну а чем загрузить сервер, это как максимальная цена на товар - ей нет предела.
>>Кроме моды и молодежности, оно еще и ...
> Звучит как реклама.
> А если серьезно - все яйца в одной карзине, это как-то с
> точки зрения надежности ущербно, не находите? Особенно если учесть что "СЕРВЕРЫ"(а
> не десктопы), в соседнем магазине не чинятся.Для этого берется два "мощных" сервера, либо один плюс один послабее на подхват. В зависимости от критичности сервисов.
> Ну и "МОЩЬНЫЙ СЕРВЕР" это сколько? Насколько мошьный? меня вот например
> 24Гб памяти, два проца ксеоновских, 4х ядерных, по 3Ггц и зеркало
> на SAS-е, полностью сьедает сайт и портал на Битриксе. А еще
> два i7х компа сьедают терминалы.Ну, что тут еще скажешь. Руки на наковальню, и пудовым молотом... Больше никак.
> 1) Позволяет полнее прогрузить мощный сервер, почти не в ущерб изоляции. PROFIT.И давно unix перестали быть многопользовательскими, многозадачными системами?
> 2) Упрощает разворачивание конфигурации и повышает гибкость маневрирования.
Руки вынь из... Ну, ты понел.
"Упростить" виртуализация разворачивание конфигурации может только в одном случае - когда эта самая конфигурация представляет собою полный бардак. Взрослые люди используют для подобных вещей штуки типа puppet и не говорят чепухи...
> 3) Позволяет балансировать нагрузку в больших конфигурациях. Если некий сервак зашивается, а некие другие недогружены, перетащить между ними виртуалку - фигня вопрос.
А если немного подумать головой - можно ничуть не сложнее "перетащить" то, что реально создает нагрузку (аккаунты сервисов, сайты, etc). Без никакой виртуализации. И, соответственно, без оверхеда из надцати систем на одном железе.
> 4) Есть такая хорошая штука - снапшоты. ... Замечательная вещь для системокрушильных экспериментов: даже после полного дестроя все возвращается "как было" за считанные секунды. ...
Без виртуализации - тоже есть снапшоты (LVM, некоторые файловые системы). Нет никаких причин не использовать их с умом на "реальной железке".
> 5) При необходимости выключить некий сервер (на обслуживание, etc) можно избежать длительного даунтайма для того что там на нем работало.
В принципе, ничто не мешает смигрировать все и без виртуализации. Руки?
PS: Ни разу не против виртуализации, но в ваших устах ее защита - полностью оправдывает эпитеты "модно, молодежно"...
> И давно unix перестали быть многопользовательскими, многозадачными системами?Это всего лишь следующий уровень в плане управления инфраструктурой. С выносом сервисов в отдельный контейнер вместо отдельного сервера, но по прежнему с персональной конфигурацией того что хочется персонализировать: настройки ОС и ее ядра, юзермода и самого сервиса - все как на реальной железке. Хорошо в этом плане то что атомарной сущностью выступает нечто логически завершенное и самостоятельное, т.е. VM обладающая почти всеми свойствами железной машины и администряемая аналогично таковой. При ее перемещении проблемы с отъездом конфигурации мигрируемого сервиса не возникнут - он со своим окружением целиком мигрируется, проблемам вылезти просто неоткуда. Самый безграбельный маршрут.
Это просто иной подход к инфраструктуре: более-менее универсальная среда - "вычислительные ресурсы". И "сервисы" - то что претендует на ресурсы. Претендент получает ресурсы по запросам (или за сколько уплачено, если хостинг). Нормальный и логичный подход. Приватные клауды - опять же, логичное развитие куда-то в ту же сторону.
Теоретики что-то такое пророчили уже давно. Как обычно в сферически-конском виде. Они называли это процессом-странником. И дизайнили какие-то крейзанутые операционки под это дело. Инженеры повертели пальцем у виска, но общую идею на вооружение взяли. И сделали почти то же самое из более привычных вещей. Потому что персональный ракетоплан - это круто, но обычно всем хватит персонального автомобиля.
>> 2) Упрощает разворачивание конфигурации и повышает гибкость маневрирования.
> Руки вынь из... Ну, ты понел.Да я уже давно понял что громче всех в таком стиле кудахтают те у кого в ОС виртуализации нет. В виртуалке если я допустим снесу бутлоадер - откат снапшота вернет все на место за 10 секунд. Т.к. при желаниии - снапшотится "блочный девайс вообще". А вот вы в этом случае таки будете мудохаться с заковыриванием бутлоадера на место. Явно дольше. И спасибо если без посещения тазика лично или юзания ремотного интерфейса менеджмента непонятной степени кривизны.
> для подобных вещей штуки типа puppet и не говорят чепухи...
Вы не поняли. Штуки типа puppet не заменяют а дополняют. В общем случае скопировать и запустить образ виртуалки проще и быстрее чем затолкать даже образ диска на физическую машину. Только и всего.
>> 3) Позволяет балансировать нагрузку в больших конфигурациях. Если некий сервак
>> зашивается, а некие другие недогружены, перетащить между ними виртуалку - фигня вопрос.
> А если немного подумать головой - можно ничуть не сложнее "перетащить" то,
> что реально создает нагрузку (аккаунты сервисов, сайты, etc). Без никакой
> виртуализации. И, соответственно, без оверхеда из надцати систем на одном железе.Можно и в владивосток из москвы пешком сходить, теоретически ничему не противоречит. Но на самолете - явно проще и быстрее. Вот то что предлагаете вы - чесать пешком. А то что я (т.е. атомарно передвинуть виртуалку с сервисом и всей его конфигурацией) - самолет. Ну так, в плане соотношений затрат сил и времени.
> Без виртуализации - тоже есть снапшоты (LVM, некоторые файловые системы).
Есть. Но это довольно урезанное понимание снапшота. Снапшот VM может быть и например с полным снапшотом блочного девайса, включая служебные области. Образом RAM VM и прочая. Все это дает кучу дополнительных возможностей. Которые в конечном итоге служат простой цели - атомарно переместить нечто целиком без отвалов башки. Простой, быстрой и удобной операцией. Без педально-весельных закатов солнца вручную.
> Нет никаких причин не использовать их с умом на "реальной железке".
Нет никаких причин не пользоваться виртуализацией в XXI веке. Абстрагировав вычислительные ресурсы от претендентов на таковые.
> В принципе, ничто не мешает смигрировать все и без виртуализации. Руки?
Миграция VMа целиком - гарантирует простоту процесса и то что в процессе заведомо ничего не отвалится. Т.к. исключено на уровне организации процесса миграции. Независимость от конкретики конфигурации ОС хоста и прочая. Это удобно.
> PS: Ни разу не против виртуализации, но в ваших устах ее защита
> - полностью оправдывает эпитеты "модно, молодежно"...А также просто, быстро, снижает затраты на администреж и снижает риск факапов. И правда, зачем какие-то дураки летают самолетами? Можно же ходить пешком!
> Хорошо в этом плане то что атомарной сущностью выступает нечто логически завершенное и
> самостоятельное, т.е. VM обладающая почти всеми свойствами железной машины и администряемая
> аналогично таковой.Что вам запрещает считать логически завершенным и самостоятельным - группу процессов, выполняющих определенные задачи?
И причем здесь вообще свойства "железной машины"? :D Абсолютно никто в реальном продакшене железки не эмулирует, за редкими специализированными исключениями. Кстати, запуск legacy-софта - как раз таки разумный пример использования виртуализации. Для пропиерастов, конечно.
> При ее перемещении проблемы с отъездом конфигурации мигрируемого сервиса
> не возникнут - он со своим окружением целиком мигрируется, проблемам вылезти
> просто неоткуда.Ох уже эти "теоретики"...
> Нормальный и логичный подход.
Чем "ненормален и нелогичен" - подход с разделением ресурсов обычными средствами ОС? Как вы сами упомянули - многозадачные ОС появились давным давно, ресурсы делить тоже не вчера научились. Может, кто-то просто не вкурсе?
> Теоретики что-то такое пророчили уже давно. Как обычно в сферически-конском виде. Они
> называли это процессом-странником.И правильно делали. Именно в этом направлении идет развитие того, что включают в Linux (см., к примеру в сторону CRIU). А OpenVZ - дорога в никуда.
> Да я уже давно понял что громче всех в таком стиле кудахтают
> те у кого в ОС виртуализации нет.???!
> В виртуалке если я допустим снесу бутлоадер - откат снапшота вернет все на место за
> 10 секунд. Т.к. при желаниии - снапшотится "блочный девайс вообще". А
> вот вы в этом случае таки будете мудохаться с заковыриванием бутлоадера
> на место.Не буду. Просто потому что сервер загрузится дальше. Не с этого диска - так с другого.
Понимаете, да? Задачу можно решить разными способами.
>> для подобных вещей штуки типа puppet и не говорят чепухи...
> Вы не поняли. Штуки типа puppet не заменяют а дополняют.Не заменяют и не дополняют - просто это пример разумного управления конфигурациями. А не бардака с "скопировать и запустить".
> Можно и в владивосток из москвы пешком сходить, теоретически ничему не противоречит.
> Но на самолете - явно проще и быстрее. Вот то что предлагаете вы - чесать пешком.Отнюдь. Просто подобное решение нельзя получить привычным многим локалхост-админам копипастом из какого-нибудь говноблога. Иными словами - здесь нет универсальных решений. Их нет и в вашем случае: в зависимости от характера сервиса(ов) виртуалки, размера данных, нагрузки - вас поджидают разного рода засады... Удачи - у вас еще столько впереди!...
>> Без виртуализации - тоже есть снапшоты (LVM, некоторые файловые системы).
> Есть. Но это довольно урезанное понимание снапшота. Снапшот VM может быть и
> например с полным снапшотом блочного девайса, включая служебные области.Вы про MBR? :) Выше было поставлено под вопрос - насколько это может оказаться полезным.
> Образом RAM VM и прочая.
Это верно, конечно. Но конкретно в вашем примере (быстро откатить здорово поломанное) - ничего такого особо и не нужно.
>> Нет никаких причин не использовать их с умом на "реальной железке".
> Нет никаких причин не пользоваться виртуализацией в XXI веке.С умом - вполне можно.
> Абстрагировав вычислительные ресурсы от претендентов на таковые.
Moar абстрахций! А многозадачность, процессы, потоки - все это зачем по-вашему?
>> В принципе, ничто не мешает смигрировать все и без виртуализации. Руки?
> Миграция VMа целиком - гарантирует простоту процесса и то что в процессе
> заведомо ничего не отвалится.Прямые руки и знания - вот что в реальности гарантируют декларированное вами.
> Что вам запрещает считать логически завершенным и самостоятельным - группу процессов, выполняющих
> определенные задачи?Например, то что в принципе они и их работа могут зависеть от ОС, либ в ней, конкретики ее настройки. А тут оно вместе с ОС и кочует - заведомо рабочее, без отвалов башки.
> И причем здесь вообще свойства "железной машины"? :D
При том что удобно админить логически законченную самодостаточную сущность - ОС и сервис(ы) в ней. Так что при перемещениях оно не поломается. VMы и продвинутые формы контейнеров как раз это и обеспечивают. Но с контейнерами уже ряд оговорок. Например, что если набор модулей разный, а проги зависели от неких модулей ядра? В VM данной проблемы не стоит как класса. А чем дальше от VM с OS и ближе к chroot, тем больше грабель такого плана. Которые надо учитывать и которые дополнительный риск.
> Абсолютно никто в реальном продакшене железки не эмулирует,
Так никому и не уперлось что-то "эмулировать". Уперлось абстрагировать и развязать сущности друг от друга, чтобы стало возможным простое перемещение.
> за редкими специализированными исключениями.
Скорее уж реальные PCI-девайсы пробрасывают, etc. По соображениям скорости работы всего этого. Именно софтварная эмуляция да и просто сколь-нибудь масштабная софтварная обработка - медленно все-таки.
> Кстати, запуск legacy-софта - как раз таки разумный пример использования
> виртуализации. Для пропиерастов, конечно.Это разумный вариант, но любителей настолько хардкорно кактусом давиться в природе не очень много.
>> просто неоткуда.
> Ох уже эти "теоретики"..."Теоретики", btw, виртуализацию и контейнеры уже годков наверное ~7 юзают в том или ином виде.
>> Нормальный и логичный подход.
> Чем "ненормален и нелогичен" - подход с разделением ресурсов обычными средствами ОС?Тем что оно не будет самодостаточным - при мигрировании на другой сервер более вероятен отвал башки, в зависимости от конфигурации ОС и тамошнего юзермода. А вот это никому не надо. Ну то-есть, в принципе контейнеры - есть, используются, имеют право на жизнь. Но у мигрируемой целиком виртуалки в этом плане есть определенный плюс - она все свое притащит с собой. Меньше допущений о конфигурации хоста.
> Как вы сами упомянули - многозадачные ОС появились давным давно,
> ресурсы делить тоже не вчера научились. Может, кто-то просто не вкурсе?Они научились, но несколько не в том виде котором было на самом деле надо. Т.е. полная глухая изоляция всех от всех - по дефолту, полисовка ресурсов - достаточно дуракоустойчивая, с учетом нужд хостеров и подобных, etc. Миграция - сразу всего окружения со всеми прибамбасами. Чтобы юзер например хостинга мог переехать на иную железку и у него ничего не отпало не дай боже. Иначе он обозлится и покажет фак такому хостеру.
> И правильно делали. Именно в этом направлении идет развитие того, что включают
> в Linux (см., к примеру в сторону CRIU). А OpenVZ - дорога в никуда.OpenVZ во многом базируется на LXC. Который JFYI в майнлайн включен, только расширяет и дополняет его. Основным недостатком является по сути то что оно не в майнлайне. Основным достоинством за это являются приличные управляторы и набор фич удобный для хостеров. Кстати с не удивлюсь если они будут работать через CRIU как раз для живой миграции.
Но с юзермодом все несколько сложнее. А что если мы хотим мигрировать машину, а на том хосте - тадам! - нет нужного модуля ядра? От которого вот эта машина что-то хотела? В полновесной виртуализации такая проблема просто не стоит: ядро и модули тоже свои притащут. А от хоста требуется только совсем низкоуровневый арбитраж ресурсов. По каким-то таким причинам виртуализаторы расцветают бурным цветом. Ну то-есть на самом деле всем надо именно вот это. Они формируют спрос. Ну и предложение появляется.
> ???!
Да есть тут некоторые.
>> вот вы в этом случае таки будете мудохаться с заковыриванием бутлоадера на место.
> Не буду. Просто потому что сервер загрузится дальше. Не с этого диска - так с другого.Опять какие-то рояли в кустах, да еще с целым оркестром допущений в комплекте. А у виртуалок один рояль только - снапшот должен быть. Если он есть - можно отмотать. А если снапшот на ФС - как минимум ОС должна быть жива настолько чтобы загрузиться и осилить его отмотать назад. У полного виртуализатора таких допущений нет - можно вообще все снести в ноль и потом вернуть в вид как было. Просто потому что снапшотинг целиком блочного девайса - более полная и низкоуровневая штука. И достаточно простая чтобы это отпедалил виртуализатор, без помощи операционки в гуесте.
> Понимаете, да? Задачу можно решить разными способами.
Да, а еще я понимаю что есть допустим хостер. Он хочет клиента перекинуть на соседнюю железку, т.к. с старой например проблемы намечаются. Дрюкаться с выяснением какой там у задач клмента был файл исполняемого, где конфиги, что там ему надо и прочая - совершенно левый гемор, который никому нафиг не упал. Ни хостерам, ни клиентам. Да и в ынтырпрайзе с кучей машин и сервисов - тоже. Правда просто? Ну вот опенвза это в первом приближении может.
>> Вы не поняли. Штуки типа puppet не заменяют а дополняют.
> Не заменяют и не дополняют - просто это пример разумного управления конфигурациями.Администрежка виртуалок через подобные средства совершенно ничему не противоречит.
> А не бардака с "скопировать и запустить".
Ну да, лично вы у нас тут знаете только один правильный вариант как надо и как лучше, во всех 100% случаев. А всех несогласных с вами наверное надо бы расстрелять. Если вы такой деревянный и не поняли - обычно никто не копирует виртуалки самолично, ручками. И никакого особого бардака не возникает. В ынтырпрайзятине обычно это выглядит так: виртуализатору сообщают "мы тут хотим машину такую-то". Он сам ее лепит. Все, конец истории. Опенвза сие тоже до некоторой степени умеет.
>> Но на самолете - явно проще и быстрее. Вот то что предлагаете вы - чесать пешком.
> Отнюдь. Просто подобное решение нельзя получить привычным многим локалхост-админам
> копипастом из какого-нибудь гoвноблога.Понимаете ли, ни ынтырпрайзников ни хостеров не прельщает дрюкаться с фигурным выпиливанием лобзиком. У них вообще-то конвейер. И они не могут позволить себе роскошь фигурно лобзиком два дня пилять. Надо чтобы захотели -> бабах -> готово. А вот свой апломб неплохо бы строить иногда. А то тоже мне, пальцы веером, кожа шифером. А сам поди админ какого-нибудь зачуханного локалхоста или спасибо если пары серверов Рога & Копыта, инк.
> Иными словами - здесь нет универсальных решений.
А вот хостеры и энтерпрайзы хотят более-менее generic управление такими вещами и готовы за это платить звонкой монетой. Теперь я думаю вы начнете догадываться почему мир выглядит таким какой он есть, а не таким каким бы лично вам хотелось его видеть.
> Их нет и в вашем случае: в зависимости от характера сервиса(ов) виртуалки,
> размера данных, нагрузки - вас поджидают разного рода засады...Понимаете, указанные требования в общем то предъявляю не лично я а вообще индустрия в целом. Хостеры, ынтырпрайзы. И софт резонно движется в ту сторону, ибо спрос рождает предложение. И реалии таковы что например хостеру надо возможность сдвинуть клиента целиком, со всем хламом, без отвалов башки на иную железку, например. Да и ынтырпрайзы что-то такое в конечном итоге хотят. Вот потому и процветают упомянутые дизайны виртуализаторов и контейнеров. Это так сложно осознать?
> Удачи - у вас еще столько впереди!...
Угу, поучите меня виртуализаторы использовать. В ынтырпрайз из-за парты? Ну так, судя по количеству апломба и распальцов с вашей стороны.
>> например с полным снапшотом блочного девайса, включая служебные области.
> Вы про MBR? :)Про все. MBR, bootloader, kernel и критичное для взлета ОС окружение. В случае полного виртуализатора он вообще никаких допущений не делает и откатывает снапшоты сам, не прибегая к услугам guest OS которая может быть вытерта хоть вообще в ноль.
> Выше было поставлено под вопрос - насколько это может оказаться полезным.
Выше кто-то дешевенько отмазался и фигурно повилял задом на неудобную тему, предположив не то что рояль, а целый оркестр в кустах.
>> Образом RAM VM и прочая.
> Это верно, конечно. Но конкретно в вашем примере (быстро откатить здорово
> поломанное) - ничего такого особо и не нужно.Зато это более точное восстановление в прошлое состояние. Ну или точный трансфер состояния VM на другую железяку, если это же самое применяется при миграции.
> С умом - вполне можно.
Дык. Это работает. И достаточно хорошо. А вот апломб немного строить надо, да.
>> Абстрагировав вычислительные ресурсы от претендентов на таковые.
> Moar абстрахций! А многозадачность, процессы, потоки - все это зачем по-вашему?Так исторически сложилось. Но упомянутым выше субъектам данные концепции в сыром виде неудобны для взаимодействия (чего ради хостер должен париться вопросом какие у меня процессы или где и какие файлы им нужны, например?). Удобнее чтобы юнитом взаимодействия было виртуальное окружение со всеми потрохами. Ну, VE опенвзы или VM виртуализатра. Правда сюрприз? :)
> Прямые руки и знания - вот что в реальности гарантируют декларированное вами.
Немеряный апломб на форуме - еще не гарантия пряморукости индивида.
>> Что вам запрещает считать логически завершенным и самостоятельным - группу процессов, выполняющих
>> определенные задачи?
> Например, то что в принципе они и их работа могут зависеть от
> ОС, либ в ней, конкретики ее настройки.Ну сделайте так, чтобы зависимости не было. Система, вместе с "либами" - стандартная. Или вы предпочитаете гетерогенный бардак? Да, сделать такой сильно виртуализация поможет - только нужно-ли?
>> И причем здесь вообще свойства "железной машины"? :D
> При том что удобно админить логически законченную самодостаточную сущность - ОС и
> сервис(ы) в ней. Так что при перемещениях оно не поломается.Вполне самодостаточная сущность - сервис. Без проблем можно перемещать. И?
>> за редкими специализированными исключениями.
> Скорее уж реальные PCI-девайсы пробрасывают, etc.Да нет. Имелось в виду - разработка, тестирование.
>>> просто неоткуда.
>> Ох уже эти "теоретики"...
> "Теоретики", btw, виртуализацию и контейнеры уже годков наверное ~7 юзают в том
> или ином виде.Если б использовали - испытали бы на себе не раз те или иные грабли миграции и молчали бы в тряпочку...
>>> Нормальный и логичный подход.
>> Чем "ненормален и нелогичен" - подход с разделением ресурсов обычными средствами ОС?
> Тем что оно не будет самодостаточным - при мигрировании на другой сервер
> более вероятен отвал башки, в зависимости от конфигурации ОС и тамошнего юзермода.Решается просто - увольнением локалхост админа и наймом профессионалов, которые бардака не устраивают.
>> Как вы сами упомянули - многозадачные ОС появились давным давно,
>> ресурсы делить тоже не вчера научились. Может, кто-то просто не вкурсе?
> Они научились, но несколько не в том виде котором было на самом
> деле надо. Т.е. полная глухая изоляция всех от всех - по
> дефолту, полисовка ресурсов... А по факту - дикий оверселлинг, как и раньше. Поделить же рессурсы справедливо - были средства и раньше. Приятно, конечно, что они совершенствуются. Но виртуализация тут сильно сбоку...
> Миграция - сразу всего окружения со всеми прибамбасами. Чтобы
> юзер например хостинга мог переехать на иную железку и у него
> ничего не отпало не дай боже.Без проблем. "У нас все работает" (ц) Ну не нужна для этого виртуализация, не нужна... "Юзеров хостинга" - гоняли спокойно между железками еще в 90-х :D
>>> вот вы в этом случае таки будете мудохаться с заковыриванием бутлоадера на место.
>> Не буду. Просто потому что сервер загрузится дальше. Не с этого диска - так с другого.
> Опять какие-то рояли в кустах, да еще с целым оркестром допущений в
> комплекте. А у виртуалок один рояль только - снапшот должен быть.Рояль в кустах только один - системный администратор с головой на плечах.
>> А не бардака с "скопировать и запустить".
> Ну да, лично вы у нас тут знаете только один правильный вариант
> как надо и как лучше, во всех 100% случаев. А всех
> несогласных с вами наверное надо бы расстрелять.Нет. Просто против щенячьих восторгов из-за виртуализации. Повсеместное использование ее - глупость. Приблизительно такая же, как хвалиться возможностью устроить гетерогенный бардак.
>>> Но на самолете - явно проще и быстрее. Вот то что предлагаете вы - чесать пешком.
>> Отнюдь. Просто подобное решение нельзя получить привычным многим локалхост-админам
>> копипастом из какого-нибудь гoвноблога.
> Понимаете ли, ни ынтырпрайзников ни хостеров не прельщает дрюкаться с фигурным выпиливанием
> лобзиком. У них вообще-то конвейер. И они не могут позволить себе
> роскошь фигурно лобзиком два дня пилять.Зато они замечательно могуть позволить себе сдизайнить решение один раз и хорошо.
>> Иными словами - здесь нет универсальных решений.
> А вот хостеры и энтерпрайзы хотят более-менее generic управление такими вещами и
> готовы за это платить звонкой монетой.VPS-хостеры - далеко даже не весь спектр услуг хостинга. Ы? Что у вас там под ынтырпрайзом - я не берусь судить. 1C+windows+аникей - угадал?
>> Их нет и в вашем случае: в зависимости от характера сервиса(ов) виртуалки,
>> размера данных, нагрузки - вас поджидают разного рода засады...
> Понимаете, указанные требования в общем то предъявляю не лично я а вообще
> индустрия в целом. Хостеры, ынтырпрайзы.Ну, куда мне спорить со всем миром... Хорошо, что есть афторитеты, умеющие говорить за все мировое IT без тени сумнения...
>>> Абстрагировав вычислительные ресурсы от претендентов на таковые.
>> Moar абстрахций! А многозадачность, процессы, потоки - все это зачем по-вашему?
> Так исторически сложилось.Сказал - как отрезал. Все малыш - в школу. Ать-два.
> Но упомянутым выше субъектам данные концепции в сыром виде
> неудобны для взаимодействия (чего ради хостер должен париться вопросом какие у
> меня процессы или где и какие файлы им нужны, например?).Потому например, что на говнохостинге мир не заканчивается. Я *знаю* какие и где у данного проекта крутятся процессы и зачем. Как, куда и в какой последовательности можно осуществлять перенос или масштабирование системы. Без перерывов обслуживания.
И для всего этого в ОС полно удобных абстракций, без всякой виртуализации. Не рассказывайте мне как будет хорошо из-за того, что я тупо впустую потрачу ресурсы.
>> ОС, либ в ней, конкретики ее настройки.
> Ну сделайте так, чтобы зависимости не было. Система, вместе с "либами"Одно дело если другие за вас нечто делают и совсем иной вопрос если это надо делать самому. А нафига лишняя возня кому-то сдастся? И что, вы уже умеете живую миграцию групп процессов без отвала у них башки? Чтобы прямо вся группа синхронно?
> Вполне самодостаточная сущность - сервис. Без проблем можно перемещать. И?
В теории - да. На практике - проще юзать виртуализаторы.
>>> за редкими специализированными исключениями.
>> Скорее уж реальные PCI-девайсы пробрасывают, etc.
> Да нет. Имелось в виду - разработка, тестирование.Да, прикольно думать что вон тот 51% дураки и только вы - умный.
> Если б использовали - испытали бы на себе не раз те или иные грабли миграции и молчали
> бы в тряпочку...Грабли бывают в любых технологиях. Это не повод ими совсем не пользоваться. Скажите, а вы не пользуетесь автомобилями потому что ДТП? Самолетами - потому что падают? Поездами - из-за риска крушения? Что же вы - пешком все время ходите? А как же риск свалиться в канализационный люк или нарваться на маньяка?
> Решается просто - увольнением локалхост админа и наймом профессионалов, которые бардака не устраивают.
Почему-то в ваших решениях всегда оказываются дополнительные условия, допущения, требования и оговорки. А оно кому-то надо - лишняя возня на ровном месте? Ну вот и пользуются виртуализацией.
> ... А по факту - дикий оверселлинг, как и раньше.
Виртуализация - лишь средство. Политику она не меняет, ясен фиг. И не должна. Если кто-то хочет оверселлить - он будет оверселлить. С виртуализацией ли, без. Какая разница?
> Поделить же рессурсы справедливо - были средства и раньше. Приятно,
> конечно, что они совершенствуются. Но виртуализация тут сильно сбоку...Как видим - активно используется. Как раз для этого.
> Без проблем. "У нас все работает" (ц) Ну не нужна для этого виртуализация,
> не нужна... "Юзеров хостинга" - гоняли спокойно между железками еще в 90-х :DВот только это были или шаред-какашки, не администряемые со стороны юзера полноценно, или архидорогие дедики. Виртуализаторы и контейнеры успешно заполнили недостающее звено: дешевле чем дедик, а админится с точки зрения юзера как именно отдельная машина. Так что не надо зависеить от хостеровских причуд ("а есть ли такая программа, модуль ядра, либа, ..."). Виртуализация обеспечила удобный стык между клиентами и хостерами. Да и не только между ними.
> Рояль в кустах только один - системный администратор с головой на плечах.
Не вижу как например хостер сможет это делать удобным для себя и клиентуры. Да и в энтерпрайзах все эти ваши рояли и допущения никому нафиг не упали.
> Нет. Просто против щенячьих восторгов из-за виртуализации. Повсеместное использование
> ее - глупость. Приблизительно такая же, как хвалиться возможностью устроить гетерогенный бардак.У кучи хостеров именно такой гетерогенный бардак. Потому что все клиенты хотят разного. Да и в энтерпрайзах - сервисы бывают разные. Возможность рулить инфраструктурой унифицированно, отвязав сервисы от оборудования там где возможно и оправданно - штука хорошая.
>> лобзиком. У них вообще-то конвейер. И они не могут позволить себе
>> роскошь фигурно лобзиком два дня пилять.
> Зато они замечательно могуть позволить себе сдизайнить решение один раз и хорошо.Ну и пусть себе дизайнят. А другие участники рынка выбирают виртуализацию. Потому что она позволит им не предполагать что правила выбиты в камне и гибко маневрировать при желании.
> VPS-хостеры - далеко даже не весь спектр услуг хостинга. Ы?
Не весь. Но достаточно большая ниша, удачно заполнившая пропасть между отстойными шаредами и дорогими дедиками. Не замечать это может только полный дуб.
> Что у вас там под ынтырпрайзом - я не берусь судить.
И тут же занимаетесь гаданием. Ха-ха.
> 1C+windows+аникей - угадал?
Нет, разумеется. Я про любые достаточно большие конторы у которых относительно много инфраструктуры и сервисов.
> Ну, куда мне спорить со всем миром... Хорошо, что есть афторитеты,
> умеющие говорить за все мировое IT без тени сумнения...Вот и я не понимаю - статистика говорит сама за себя, и только myhand зачем-то ссыт против ветра. Ну, ссыте, дело хозяйское :)
> Сказал - как отрезал. Все малыш - в школу. Ать-два.
Я так смотрю, у вас прямо какие-то комплексы насчет возраста. Что, недавно из-за парты, в контору "рога и копыта"? Ну, бывает. Для таких вообще характерно продр@чивать ресурсы на изобретение великов вместо того чтобы взять уже готовый.
> Потому например, что на гoвнохостинге мир не заканчивается. Я *знаю* какие
> и где у данного проекта крутятся процессы и зачем.Да кого колышет ваш долбаный проект кроме вас? Вот на нем мир действительно не заканчивается. А в инфраструктуре на 500 серваков и кучей сервисов им под стать у админов бошка вспухнет знать где какие процессы крутятся. Вот виртуализаторы позволяют совершенно этой дребеденью не заморачиваться. Оперируя понятиями вида "есть ресурсы/нет ресурсов". Окучивать локалхост до поросячьего визга - прерогатива пионерии.
> Как, куда и в какой последовательности можно осуществлять перенос или масштабирование системы.
> Без перерывов обслуживания.Проблема только в том что это какой-то очень частный случай. Который никому кроме лично вас вообще нафиг не упал.
> И для всего этого в ОС полно удобных абстракций, без всякой виртуализации.
Для конкретно вашего случая, когда вам не лень переизобретать велик - может быть. А остальным обломно лишний раз заморачиваться - вот и юзают виртуализацию.
> Не рассказывайте мне как будет хорошо из-за того, что я тупо впустую потрачу ресурсы.
В конкретно вашем случае - может и не будет. А у других - бывает, как видите. Кстати облака в нормальном виде - это всего лишь виртуализатор и автоматическая ребалансировка нагрузки, по большому счету. С учетом потребностей сервисов в ресурсах. Ну и может быть тарификацией оных, если это хостинг.
> И что, вы уже умеете живую миграцию групп процессов без отвала
> у них башки? Чтобы прямо вся группа синхронно?По-хорошему - пока нет. Но дело к этому идет (criu и т.п.). А с минимальным даунтаймом - пожалуйста.
>> Вполне самодостаточная сущность - сервис. Без проблем можно перемещать. И?
> В теории - да. На практике - проще юзать виртуализаторы.Если за душей нет готовых, отлаженных и давно используемых решений. Повторяю - для хостинга подобные вещи давно не новы.
>>>> за редкими специализированными исключениями.
>>> Скорее уж реальные PCI-девайсы пробрасывают, etc.
>> Да нет. Имелось в виду - разработка, тестирование.
> Да, прикольно думать что вон тот 51% дураки и только вы - умный.Где я такое написал?
>> Если б использовали - испытали бы на себе не раз те или иные грабли миграции и молчали
>> бы в тряпочку...
> Грабли бывают в любых технологиях. Это не повод ими совсем не пользоваться.Повод, если выигрыш от них - невелик.
> Скажите, а вы не пользуетесь автомобилями потому что ДТП? Самолетами -
> потому что падают?Ну, в магазин за продуктами - я тоже не летаю на вертолете...
>> Решается просто - увольнением локалхост админа и наймом профессионалов, которые бардака не устраивают.
> Почему-то в ваших решениях всегда оказываются дополнительные условия, допущения, требования
> и оговорки. А оно кому-то надо - лишняя возня на ровном месте?А оно кому надо - потом лишние проблемы на ровном месте? Каждый выбирает сам.
>> ... А по факту - дикий оверселлинг, как и раньше.
> Виртуализация - лишь средство. Политику она не меняет, ясен фиг. И не
> должна. Если кто-то хочет оверселлить - он будет оверселлить. С виртуализацией
> ли, без. Какая разница?Действительно, разницы никакой. Так что в достоинства виртуализации - тут нечего записать.
>> Поделить же рессурсы справедливо - были средства и раньше. Приятно,
>> конечно, что они совершенствуются. Но виртуализация тут сильно сбоку...
> Как видим - активно используется. Как раз для этого.Увы, хостинга это не затрагивает.
>> Без проблем. "У нас все работает" (ц) Ну не нужна для этого виртуализация,
>> не нужна... "Юзеров хостинга" - гоняли спокойно между железками еще в 90-х :D
> Вот только это были или шаред-какашки, не администряемые со стороны юзера полноценно,
> или архидорогие дедики. Виртуализаторы и контейнеры успешно заполнили недостающее звено:
> дешевле чем дедик, а админится с точки зрения юзера как
> именно отдельная машина.Угу. "Как отдельная машина" - т.е. никак. Догоним и перегоним ПК секретуток в обеспечении популяции ботнетов...
> Виртуализация обеспечила удобный стык между клиентами и хостерами.
Больше пока похоже на очередную приманку для лохов.
>> Рояль в кустах только один - системный администратор с головой на плечах.
> Не вижу как например хостер сможет это делать удобным для себя и клиентуры.Ты - не видишь. А он есть!
>> Нет. Просто против щенячьих восторгов из-за виртуализации. Повсеместное использование
>> ее - глупость. Приблизительно такая же, как хвалиться возможностью устроить гетерогенный бардак.
> У кучи хостеров именно такой гетерогенный бардак.Что время от времени - выходит боком даже клиентам. Не говоря уже о самом хостере... Незачем глупостями хвалиться.
>>> лобзиком. У них вообще-то конвейер. И они не могут позволить себе
>>> роскошь фигурно лобзиком два дня пилять.
>> Зато они замечательно могуть позволить себе сдизайнить решение один раз и хорошо.
> Ну и пусть себе дизайнят. А другие участники рынка выбирают виртуализацию.А еще - они выбирают виндовс. И чо?
>> VPS-хостеры - далеко даже не весь спектр услуг хостинга. Ы?
> Не весь. Но достаточно большая ниша, удачно заполнившая пропасть между отстойными шаредами
> и дорогими дедиками.Я бы сказал иначе: успешно свалившая шареды в еще большую отстойность. И наполовину занявшее их место с худшим качеством. Глупо такими достижениями хвалиться.
> Вот и я не понимаю - статистика говорит сама за себя
И чо, если "статистика говорит", что больше половины мужской популяции носят "брюки клеш" - мне бежать выкидывать джинсы? Люди принимают глупые решения, люди следуют моде. Статистика "говорит" мне об этом, почему нет?
>> Потому например, что на гoвнохостинге мир не заканчивается. Я *знаю* какие
>> и где у данного проекта крутятся процессы и зачем.
> Да кого колышет ваш долбаный проект кроме вас? Вот на нем мир
> действительно не заканчивается. А в инфраструктуре на 500 серваков и кучей
> сервисов им под стать у админов бошка вспухнет знать где какие
> процессы крутятся.Замечательно. Их уволят - и наймут тех, кто в состоянии упорядочить инфраструктуру, чтобы можно было "знать". Необходимость этого знания - не исчезает, вне зависимости от числа тазиков в вашей "инфраструктуре".
>> Как, куда и в какой последовательности можно осуществлять перенос или масштабирование системы.
>> Без перерывов обслуживания.
> Проблема только в том что это какой-то очень частный случай. Который никому
> кроме лично вас вообще нафиг не упал.Не ходи больше в google - он тебе нафиг не упал.
>> Не рассказывайте мне как будет хорошо из-за того, что я тупо впустую потрачу ресурсы.
> В конкретно вашем случае - может и не будет. А у других - бывает, как видите.В данной теме - я "вижу" только статистику. "Бывает" - пока не особо видно, совсем наоборот.
Да, походу представляешь типичного российского хостера :)Дядя, тебе рассказать, почему 90% клиентов сбежали за рубеж?
Потому что вместо того, чтобы внедрять простые "железные" решения - перемещают сервисы лопатой. В частности. Это образно - я имею в виду весь набор подходов.
> Дядя, тебе рассказать, почему 90% клиентов сбежали за рубеж?Меня никак не колышат клиенты, которые куда-то сбежали от тебя.
> Меня никак не колышат клиенты, которые куда-то сбежали от тебя.Чудик - не от меня, а от хостеров, которые действуют описанными тобой подходами.
> не от меня, а от хостеров...Ну или от знакомых тебе "хостеров" Васи и Пети, фирма "Рога и Копыта"...
> OpenVZ во многом базируется на LXCА парни из паралелз и не знали...
>> OpenVZ во многом базируется на LXC
> А парни из паралелз и не знали...Знали. Гляньте объем патча до и после появления LXC в ядрах. Что на чем базируется изначально - вопрос вопросов - наверняка в LXC есть какие-то идеи из OpenVZ. Но вот то, что патч OpenVZ начал опираться на функции LXC в ядре - это 100%. Более того - есть сейчас вообще экспериментальный вариант vzctl без патча OpenVZ - исключительно для LXC.
>>> OpenVZ во многом базируется на LXCНаоборот.
>> А парни из паралелз и не знали...
> Знали.http://lwn.net/Articles/321979/ (не совсем то, что искал, но тоже)
> Гляньте объем патча до и после появления LXC в ядрах.
Вполне естественно при upstream merge.
> Что на чем базируется изначально - вопрос вопросов
https://www.opennet.ru/openforum/vsluhforumID3/77225.html#55
6) Позволяет абстрагироваться от железа.Виндовые серверы на старом, или умирающем железе - очень веселая штука.
7) Позволяет увеличивать мощность сервера в виртуалке в 2 клика.
8) Позволяет очень быстро создавать новые виртуалки на основе существующей.
> 6) Позволяет абстрагироваться от железа.В вакууме запускаете виртуалки?
> Виндовые серверы на старом, или умирающем железе - очень веселая штука.
Они и на новом - не менее "веселая". Не используйте "виндовые сервера". Но нет - как маленькие, тащат всякую гадость...
> 7) Позволяет увеличивать мощность сервера в виртуалке в 2 клика.
Из пустоты...
> 8) Позволяет очень быстро создавать новые виртуалки на основе существующей.
Зашибись. Moar виртуализации! Быстро, молодежно...
> В вакууме запускаете виртуалки?Просто происходит расщепление на вычислительные ресурсы и сервисы претендующие на них. Мало зависящие друг от друга. Виртуалке не принципиально, выполнит ее этот сервак или какой-то из его соседей. И всегда можно переместить оную на соседний сервак, если он мало нагружен а текущий сервак зашивается.
В идеале оно вообще прозрачно для всех + самомасштабируется путем доустановки еще +эн серваков если это стало надо. С нулевыми усилиями по переконфигурации чего либо. В конечном итоге облака в основном о чем-то подобном и есть, если выжать маркетинговую воду и оставить лишь рациональное зерно.
> Но нет - как маленькие, тащат всякую гадость...
Изврат, не отнять.
>> 7) Позволяет увеличивать мощность сервера в виртуалке в 2 клика.
> Из пустоты...Из довольно-таки generic сущности "вычислительные ресурсы". Понятный фиг - они подперты каким-то железом. Просто виртуалки этот вопрос ни разу не колышет. А сервера мало колышет вопрос что именно на них будут выполнять. Это упрощает жизнь хостерам и админам.
>> 8) Позволяет очень быстро создавать новые виртуалки на основе существующей.
> Зашибись. Moar виртуализации! Быстро, молодежно...Ну а что, удобно же - можно слепить тестовое окружение за несколько минут, присоседиться куда-то, не мешая остальным, проверить, словить факап, понять в чем он, вернуть все в исходный вид, проверить что более факап не происходит, прибить VM к чертям и забыть о том что оно существовало. А сколько вы такое на реальном железе будете делать? На VM это обычно вопрос единиц минут или даже скольких-то секунд.
>> В вакууме запускаете виртуалки?
> Просто происходит расщепление на вычислительные ресурсы и сервисы претендующие на них.Почитайте про процессы, потоки...
> И всегда можно переместить оную
> на соседний сервак, если он мало нагружен а текущий сервак зашивается.Что вам запрещает так же перемещать отдельные сервисы?
> В идеале оно вообще прозрачно для всех
В идеале всегда зашибись.
>>> 7) Позволяет увеличивать мощность сервера в виртуалке в 2 клика.
>> Из пустоты...
> Из довольно-таки generic сущности "вычислительные ресурсы".Вы будете способны выделить ресурсов сервису больше чем на самой мощной вашей ноде? Ах нет... Тогда увы, все это давно можно было сделать без виртуализации. Увы, малыш.
>>> 8) Позволяет очень быстро создавать новые виртуалки на основе существующей.
>> Зашибись. Moar виртуализации! Быстро, молодежно...
> Ну а что, удобно же - можно слепить тестовое окружение за несколько минутА причем здесь "тестовое окружение"? Для подобных задач действительно оправдано использование виртуализации, по крайней мере иногда и/или на некоторых этапах.
Но в общем случае - задача развертывания и управления конфигурациями решается просто и без виртуализации (puppet, cfengine, etc).
> Почитайте про процессы, потоки...Вот практическая задача: хочет хостер подвинуть клиента на иной сервак. И чтобы ничего не отпало. Что ему почитать про процессы или потоки, ась? И да, не может хостер два дня лобзиком выпиливать этого клиента. Ему надо чтобы такое атомарно отстрелялось одной операцией и ничего не факапнулось.
> Что вам запрещает так же перемещать отдельные сервисы?
То что на данном пути возможно намного бОльшее число грабель + потенциально надо что-то там знать о какой-то там анатомии сервиса. Что никому нафиг не упало в условиях мало-мальски крупных продакшнов в промышленных масштабах. В этом месте до вас должно бы уже доползти почему опенвз сделан именно так, а виртуализаторы еще более приближаются к идеалу в этом плане.
> В идеале всегда зашибись.
Ну да, а виртуализаторы стремятся к оному, под напором клиентуры которая желает чтобы им в их задачах было именно зашибись. Нормальный рабочий процесс.
>> Из довольно-таки generic сущности "вычислительные ресурсы".
> Вы будете способны выделить ресурсов сервису больше чем на самой мощной вашей ноде? Ах нет..."А если рельсу?" (с) анекдот. Кстати, облака в том числе частично и об этом.
> Тогда увы, все это давно можно было сделать без виртуализации.
Так я и говорю - можно и пешком в владивосток, без всяких самолетов. Правда вот 10 000 километров таким макаром - долго, однако.
> Увы, малыш.
Что, какие-то комплексы насчет возраста долбят? Шкoлoло надежно детектируется по комплексам такого типа. Взрослые люди такой фигней просто не занимаются.
>> Ну а что, удобно же - можно слепить тестовое окружение за несколько минут
> А причем здесь "тестовое окружение"?При том что виртуализация нормально относится и к такому. А тестовую виртуалку можно вкатить на общий ресурсный пул. Который один фиг есть.
> Для подобных задач действительно оправдано использование
> виртуализации, по крайней мере иногда и/или на некоторых этапах.Оно не только для таких задач оправдано.
> Но в общем случае - задача развертывания и управления конфигурациями решается просто
> и без виртуализации (puppet, cfengine, etc).Как бы это сказать? Я не понимаю почему данные сущности надо противопоставлять виртуализаторам. Это примерно как противопоставлять легковой автомобиль моторной лодке. Ну то-есть оба в принципе могут решить задачу доставки груза из пункта А в пункт Б но как-то уж сильно по разному. А пересекается и конкурирует оно только очень уж местами. Скорее чаще одно другое дополняет.
>> Почитайте про процессы, потоки...
> Вот практическая задача: хочет хостер подвинуть клиента на иной сервак. И чтобы
> ничего не отпало. Что ему почитать про процессы или потоки, ась?
> И да, не может хостер два дня лобзиком выпиливать этого клиента.
> Ему надо чтобы такое атомарно отстрелялось одной операцией и ничего не
> факапнулось.Вы хостер? Нет? Тогда сидите со своими практическими задачами сами знаете где.
Мы, банально, даже закрывая глаза на все остальное, не наберем столько ипв4-адресов, что бы каждому выдавать, увы-увы.
Перенос осуществляется весьма тривиально: уменьшили ттл в зонах, сделали бекап, перенесли, распаковали, повернули днс-записи на старом месте на новое место, если нужно (изменились нс-ы) - переделегировали домен(ы). через пару дней вернули ттл-ы и удалили юзера на старом месте. все.
и не нужно мне рассказывать про кнопку: "сделать хорошо" - такого не бывает, практически всегда одно решается в ущерб другого.
по остальным, нижележащим пунктам - подобная же ситуация.
> Мы, банально, даже закрывая глаза на все остальное, не наберем столько ипв4-адресов,
> что бы каждому выдавать, увы-увы.Тем хуже для вас. Значит деньги получит тот кто наберет. Такие есть.
> Перенос осуществляется весьма тривиально: уменьшили ттл в зонах, сделали бекап, перенесли,
> распаковали, повернули днс-записи на старом месте на новое место,...попрыгали с бубном, покурили трубку мира, сгоняли на гору Арарат с пудовой гирей, ... А тем у кого виртуализация - весь этот прыг с бубном не упал. Они просто двигают виртуалку на другую железку парой команд виртуализатору (может быть даже через гламурную ынтырпрайзную мордочку). Все, конец истории.
> если нужно (изменились нс-ы) - переделегировали домен(ы). через пару дней
> вернули ттл-ы и удалили юзера на старом месте. все.Ну да, подумаешь, действий раз в 20 больше чем в случае виртуалок. Я не спорю - можно и пехом в владивосток, на 10 000 км.
> бывает, практически всегда одно решается в ущерб другого.
Да, на своих двоих можно 10 000 км нахаляву отшлепать, а за билет на самолет бабла желают. Во гады то!
>> Перенос осуществляется весьма тривиально: уменьшили ттл в зонах, сделали бекап, перенесли,
>> распаковали, повернули днс-записи на старом месте на новое место,
> ...попрыгали с бубном, покурили трубку мира, сгоняли на гору Арарат с пудовой
> гирей, ... А тем у кого виртуализация - весь этот прыг
> с бубном не упал. Они просто двигают виртуалку на другую железку
> парой команд виртуализатору (может быть даже через гламурную ынтырпрайзную мордочку).
> Все, конец истории.
> Ну да, подумаешь, действий раз в 20 больше чем в случае виртуалок.
> Я не спорю - можно и пехом в владивосток, на 10
> 000 км.Эта, давай ты про кактус будешь рассказывать своим маркетологам, они тебя поддержат и поймут. А я видел и как "заклинивали" виртуалки, что решалось только ребутом сервера, видели как они не поднимаются после нового ядра на хост-системе, видели много всего непонятного и необъяснимого. Конечно, когда у тебя три тазика с десятком ВМ, может оно и нормально и глюков не видно, а ты попользуй в пром. масштабах их попользовать - вот так действительно бубен нужен.
То, что ты называешь: "попрыгали с бубном, покурили трубку мира", это давно отработанные методы, которые: а. должен уметь делать любой админ. б. давно заскриптованные и проблем не вызывающие.
> Эта, давай ты про кактус будешь рассказывать своим маркетологам,Проблемка только в том что у меня никаких маркетологов нет.
> они тебя поддержат и поймут.
Осталось только их найти.
> А я видел и как "заклинивали" виртуалки, что решалось только ребутом сервера,
А некоторые так и вовсе авиакатастрофы видели. Хотя отношение к безопасности в авиации - огого какое. Следует ли отсюда что летать самолетами - опасно?
> видели как они не поднимаются после нового ядра на хост-системе,
Ну так в больших инсталляциях апдейты тестируют до того как вываливать на все сервера.
> глюков не видно, а ты попользуй в пром. масштабах их попользовать
Сабж как раз об этом и есть. Если 51% серверов использует. А массовых воплей нет. Да, вы правы в том что в очень большой инсталляции что-то где-то ломаться будет так или иначе. По куче причин. И отказ железа, и сбои софта и что там еще. Иногда разбиваются самолеты. Иногда тонут корабли. Иногда ломаются автомобили. Нет, не потому что они все такое ненадежное г@вно. Просто если чего-то много - хоть один экспонат из миллиона но таки сломается. Даже при низкой вероятности поломки. Низкая вероятность успешно компенсируется количеством. Ну и тут так же.
> - вот так действительно бубен нужен.
В большой инсталляции он по любому понадобится. Там всегда будет что-то портиться. Но именно виртуализатор - с ТАКОЙ популярностью обречен стать довольно вылизанной и стабильной штукой. Просто потому что на все сколь-нибудь мешающие жить баги наступит орава народа. И в целом виртуализаторы достаточно стабильные штуки в данный момент. Ну ясен пень там где они не первый год уже. Если брать какую-то совсем новую, экзотичную или явно недопиленную хрень - получите то что заслужили.
> То, что ты называешь: "попрыгали с бубном, покурили трубку мира", это давно
> отработанные методы, которые: а. должен уметь делать любой админ. б. давно
> заскриптованные и проблем не вызывающие.Просто с виртуалками это все в разы проще. А кто кому что там должен - решает рынок. И он как видим решил, забыв у вас спросить что вы думаете на этот счет.
> Просто с виртуалками это все в разы проще. А кто кому что
> там должен - решает рынок. И он как видим решил, забыв
> у вас спросить что вы думаете на этот счет.вода-вода-вода...
а еще рынок решил, что windows лучше, давайте переходить на windows.
> а еще рынок решил, что windows лучше, давайте переходить на windows.Он это решил только в каком-то частном сегменте и не без помощи некоторых вендоров.
>> Что вам запрещает так же перемещать отдельные сервисы?
> То что на данном пути возможно намного бОльшее число грабель + потенциально
> надо что-то там знать о какой-то там анатомии сервиса.Большее число грабель - пока только ваши слова. А знание о "анатомии сервиса" - рутинная необходимость для администратора.
> Что никому
> нафиг не упало в условиях мало-мальски крупных продакшнов в промышленных масштабах.Не путайте говнохостинг vps с промышленными масштабами. Это лишь одно специфическое приложение.
> Ну да, а виртуализаторы стремятся к оному, под напором клиентуры которая желает чтобы им в их задачах было именно зашибись.
Мода, маркетинг. Существенно больше половины ваших хостеров - представляют собой впечатляющий факап сей концепции. Справедливое разделение ресурсов - выродилось в новый вариант оверселлинг. Зашибись - в проблемы с доступностью сервисов при переездах.
>> Но в общем случае - задача развертывания и управления конфигурациями решается просто
>> и без виртуализации (puppet, cfengine, etc).
> Как бы это сказать? Я не понимаю почему данные сущности надо противопоставлять
> виртуализаторам.Их не противопоставляют. Вам просто указали на то, что некоторым декларированным "достоинствам" есть лучшие аналоги, не использующие никакой виртуализации вовсе.
> Это примерно как противопоставлять легковой автомобиль моторной лодке.
Нет, не как. Это примерно как если вы не поняли что вам пытались сказать. Надеюсь, я это пояснил еще раз. А с идиотскими аналогиями - завязывайте.
> Большее число грабель - пока только ваши слова.Это элементарная прикидка точек отказа и вообще оценка всего что может обломаться в процессе операции. С пониманием что самое ненадежное звено любой системы - как раз человек.
> А знание о "анатомии сервиса" - рутинная необходимость для администратора.
Если можно исключить human factor из управления - его нужно исключить. В целях повышения надежности и предсказуемости. Человек - самое ненадежное звено системы. В случае всяких крупных инфраструктур понимаешь это особенно отчетливо. Редкая программа косячит столько же сколько живой персонал. Ну не выспался чувак - и криво отпедалил свою часть рутины. А оно клиенту надо - выкусывать результат головотяпства? А когда оно двигается атомарно, со всеми потрохами - облажаться толком негде. Шансы на успех операции многократно возрастают, т.к. самый стремный фактор (человеческий) - выпал из рассмотрения.
>> Что никому нафиг не упало в условиях мало-мальски крупных продакшнов в промышленных масштабах.
> Не путайте гoвнoхостинг vps с промышленными масштабами. Это лишь одно специфическое приложение.51% - это таки не просто промышленные масштабы, это еще и большинство к тому же. Это дофига применений там и тут, на фоне которых вы и ваша сраная кош^W^W горбатый ынтырпрайз - так, какая-то незначительная блоха на фоне целого стада слонов.
> Мода, маркетинг.
А также, если отбросить маркетинговую воду (которую, безусловно, маркетологи развели от души), это еще и перечисленные в верхнем сообщении преимущества. Просто у некоторых вырабатывается неконструктивная аллергия на маркетинг вообще. А некоторые учатся фильтровать информацию и выделять рациональные зерна из общего гвалта маркетолухов.
> Существенно больше половины ваших хостеров - представляют собой впечатляющий
> факап сей концепции. Справедливое разделение ресурсов - выродилось в новый
> вариант оверселлинг. Зашибись - в проблемы с доступностью сервисов при переездах.Просто некоторые никак не поймут что принцип "как заплачено так и захреначено" еще не отменяли. А какой-нибудь ср@ный шаред при заходе на пагу больше двух анонимусов в час вообще перекроет кислород и устроит форменный шантаж, за то что ваш сайт грузит их тормозной опач, видите ли. И, конечно же, такой лохоразвод - совсем не оверселлинг, ну конечно. Ведь мы разглядим соринку в глазу виртуализаторов, а бревна в глазах других - пусть остаются :)
>> Как бы это сказать? Я не понимаю почему данные сущности надо противопоставлять виртуализаторам.
> Их не противопоставляют. Вам просто указали на то, что некоторым декларированным
> "достоинствам" есть лучшие аналоги, не использующие никакой виртуализации вовсе.Насчет лучшести - можно поспорить. В сумме же рынок решил что виртуалки - как раз то что надо. Сабж как раз про это. Понимаете, что там более лучшее - решаете не лично вы а рынок. Он решил. Какие проблемы? :)
> А с идиотскими аналогиями - завязывайте.
Как только вы завяжете - так и я. Попытка противопоставить puppet и подобные по смыслу системы виртуализаторам - вообще бред. Они к тому же весьма прилично работают в паре. Они дополняют друг друга а не заменяют.
>> Большее число грабель - пока только ваши слова.
> Это элементарная прикидка точек отказа и вообще оценка всего что может обломаться
> в процессе операции.Прикидку в студию.
> С пониманием что самое ненадежное звено любой системы
> - как раз человек.Рад что вы это понимаете. Непонятно только, почему из этого не делаете естественного вывода: если вместо одной системы наплодить 10 - администрирование не обязательно упростится...
>> А знание о "анатомии сервиса" - рутинная необходимость для администратора.
> Если можно исключить human factor из управления - его нужно исключить. В
> целях повышения надежности и предсказуемости.Скажу больше - увольнять надо такие "факторы".
> Ну не выспался чувак -
> и криво отпедалил свою часть рутины.Причем здесь рутина вообще - хз. Автоматизировать решения можно по-разному. Это простая мысль вам доступна?
> 51% - это таки не просто промышленные масштабы, это еще и большинство
> к тому же.Это даже не больше половины. Больше половины это - в конкретной выборке, которая упоминается в статье.
>> Мода, маркетинг.
> А также, если отбросить маркетинговую воду (которую, безусловно, маркетологи развели от
> души), это еще и перечисленные в верхнем сообщении преимущества. Просто у
> некоторых вырабатывается неконструктивная аллергия на маркетинг вообще.Нет. Именно на ваши "рациональные зерна". Откровенный маркетоидный бред уж совсем не замечаешь - как рекламу...
> Просто некоторые никак не поймут что принцип "как заплачено так и захреначено"
> еще не отменяли.Это "значит" - ровно то, что я озвучил выше. Факап и полное несоответствие нашей реальности вашим радужным мечтам о миграции vps без простоя и разделении ресурсов. Извините, я живу в реальном мире.
>> Их не противопоставляют. Вам просто указали на то, что некоторым декларированным
>> "достоинствам" есть лучшие аналоги, не использующие никакой виртуализации вовсе.
> Насчет лучшести - можно поспорить. В сумме же рынок решил что виртуалки
> - как раз то что надо. Сабж как раз про это.Н**рать что там решил рынок. Доля Windows-систем ~ 51%, по прошлогодним данным некоторых аналитеков: https://www.opennet.ru/opennews/art.shtml?num=35476
Молитесь сами на подобные цифры. Совершенно не обязательно они отражают какие-то реальные технические достоинства.
>> А с идиотскими аналогиями - завязывайте.
> Как только вы завяжете - так и я. Попытка противопоставить puppet и
> подобные по смыслу системы виртуализаторам - вообще бред.А я-то тут причем? Не противопоставляйте - и не приписывайте подобных бредней другим.
> Прикидку в студию.Я уже прикинул вон там выше что хостеру удобнее всего клиента подвинуть не вникая в то какие там сервисы с риском их факапнуть случайно. Виртуализаторы или хотя-бы контейнеры все это обеспечивают. Кроме того, в больших инфраструктурах у энтерпрайзов тоже много хостов и сервисов. И потому там тоже предпочитают не допускать возможности лишний раз накосячить при элементарнейших операциях ребалансировки ресурсов. В идеале даже саму ребалансировку осуществляет автомат. Получается облако, некая среда которая относительно эластична по отношению к потребителям ресурсов. Т.е. если некто хочет больше ресурсов - ему попытаются выкроить, не в ущерб остальным. Возможно перебалансировав что-то куда-то. Нормальный подход совершенно.
>> С пониманием что самое ненадежное звено любой системы - как раз человек.
> Рад что вы это понимаете. Непонятно только, почему из этого не
> делаете естественного вывода: если вместо одной системы наплодить
> 10 - администрирование не обязательно упростится...Потому что администрировать эти системы будет многократно проще. Передвинуть виртуалку на другой хост может совершенно заурядный лабух, ничего не знающий о сервисах в виртуалках. А ему и не надо - когда двигается все ОС целиком, облажаться просто негде. В идеальном случае такие вещи вообще рюхает автомат - получается облако. А человек вообще вмешивается только в каких-то эксклюзивных случаях.
>> Если можно исключить human factor из управления - его нужно исключить. В
>> целях повышения надежности и предсказуемости.
> Скажу больше - увольнять надо такие "факторы".Да, вот ща, хостеры виртуалок и клаудов побегут разучивать что там у кого из клиентов крутится и изучать анатомию этого. Вот делать им больше нефига.
>> Ну не выспался чувак - и криво отпедалил свою часть рутины.
> Причем здесь рутина вообще - хз. Автоматизировать решения можно по-разному.
> Это простая мысль вам доступна?Ну вот мир в целом выбрал логичное решение - абстракцию железа до уровня группы вычислителей предоставляющих ресурсы и сервисов со всеми потрохами вплоть до операционки потребной им для работы. Плюс-минус 1 велосипедист типа вас, желающий изобрести свой велик и непременно с квадратными колесами, зато своими - ничего не решает.
>> 51% - это таки не просто промышленные масштабы, это еще и большинство к тому же.
> Это даже не больше половины. Больше половины это - в конкретной выборке, которая упоминается в статье.Учитывая что х86 весьма массовая штука - тут может идти речь и о большинстве, пожалуй. Нет, есть всякая экзотика, но ее процент достаточно скромный. И кстати никаких гарантий что там нет виртуализации. IIRC, айбиэмеры например юзают виртуализацию на майнфреймах с незапамятных времен.
> Нет. Именно на ваши "рациональные зерна". Откровенный маркетоидный бред уж
> совсем не замечаешь - как рекламу...Да при чем тут маркетоидный бред? Вы просто думаете что мир крутится вокруг вас и вашего сервиса, а это совсем не так.
>> Просто некоторые никак не поймут что принцип "как заплачено так и захреначено" еще не отменяли.
> Это "значит" - ровно то, что я озвучил выше. Факап и полное несоответствие
> нашей реальности вашим радужным мечтам о миграции vps без простоя и разделении ресурсов.Кому надо - у тех как ни странно работает и живая миграция и снапшоты и что там еще. И факапов минимум. Нет, завалить можно все, даже амазоновское облако разок упало. Но в целом - появляется уйма шансов минимизировать простои и сделать все прозрачно и не требуя дикой квалификации персонала (что никому нафиг не упало - не должен быть хрен жмущий кнопки на пульте реактора академиком - не хватит академиков на всех).
> Извините, я живу в реальном мире.
Извините, но вы не видите дальше своего носа, не более того.
> Н**рать что там решил рынок.
Так что вы тогда делаете в этой новости? :)
> Молитесь сами на подобные цифры. Совершенно не обязательно они отражают какие-то
> реальные технические достоинства.Они отражают что в сумме решение имеет право на жизнь и предоставляет ряд определенных удобств. Правда просто?
>> подобные по смыслу системы виртуализаторам - вообще бред.
> А я-то тут причем? Не противопоставляйте - и не приписывайте подобных бредней другим.При том что вы почему-то судя по всему пытаетесь это делать. Хотя они логично дополняют друг друга.
>> 6) Позволяет абстрагироваться от железа.
> В вакууме запускаете виртуалки?Да нет. Просто могу перетащить какую-нибудь виртуалочку с боевого Xeon допустим на времянку на i7 на время плановых работ. Или спокойно поставить новый навороченный сервер с SAN, и перетащить на него все виртуалки со старенького сервака с DAS. Они даже не заметят изменений :)
>>> 6) Позволяет абстрагироваться от железа.
>> В вакууме запускаете виртуалки?
> Да нет. Просто могу перетащить какую-нибудь виртуалочку с боевого Xeon допустим на
> времянку на i7 на время плановых работ.Будто что-то запрещает просто перетащить сервисы... Вы не из параллельного мира? - в моей Вселенной такого ограничения в природе нет.
> Будто что-то запрещает просто перетащить сервисы... Вы не из параллельного мира?
> - в моей Вселенной такого ограничения в природе нет.Ограничение простое: административный оверхед. Хостер знать ничего не желает об устройстве клиентских виртуалок и сервисов в них, например. Да и ынтырпрайзному админу лишний раз загаживать свою голову такими сакральными знаняими в общем то ни к чему.
Представляете себе хостера который два дня вдупляет как выпилить сервисы "вон того юзера" лобзиком, чтобы ничего не отвалилось? Ну вот и я как-то так же...
>> Будто что-то запрещает просто перетащить сервисы... Вы не из параллельного мира?
>> - в моей Вселенной такого ограничения в природе нет.
> Ограничение простое: административный оверхед. Хостер знать ничего не желает об устройстве
> клиентских виртуалок и сервисов в них, например. Да и ынтырпрайзному админу
> лишний раз загаживать свою голову такими сакральными знаняими в общем то
> ни к чему.Если у клиента свой сервер (вдс,впс) - хостеру незачем знать, если он конечно не админит этот сервер, что там и как. если у клиента шаред, то неизвестных сервисов там нет в принципе.
> Представляете себе хостера который два дня вдупляет как выпилить сервисы "вон того
> юзера" лобзиком, чтобы ничего не отвалилось? Ну вот и я как-то
> так же...юзер294, хватит фантазировать, иди учись, дорогой.
> Если у клиента свой сервер (вдс,впс) - хостеру незачем знать, если он
> конечно не админит этот сервер, что там и как.А даже если и админит, атомарно сдвинуть сущность "виртуалка" ему проще чем вкуривать что и как там у клиента сделано.
> если у клиента шаред, то неизвестных сервисов там нет в принципе.
Я про нормальные хостинги и ынтырпрайзы. А не этих мамонтов из каменного века.
> юзер294, хватит фантазировать, иди учись, дорогой.
У-тю-тю, апломба то. Вечно школие (или в лучшем случае студентота) по себе все измеряет. И то, студентота уже начинает обычно избавляться от таких привычек.
>> Если у клиента свой сервер (вдс,впс) - хостеру незачем знать, если он
>> конечно не админит этот сервер, что там и как.
> А даже если и админит, атомарно сдвинуть сущность "виртуалка" ему проще чем
> вкуривать что и как там у клиента сделано.Я тебе расскажу что еще проще - перенести винты в более мощную машину.
>> если у клиента шаред, то неизвестных сервисов там нет в принципе.
> Я про нормальные хостинги и ынтырпрайзы. А не этих мамонтов из каменного
> века.нормально - это субъективная оценка, если что...
> Я тебе расскажу что еще проще - перенести винты в более мощную
> машину.Ну давай, угу, успехов. С HP/CCISS на LSI, например. Или, для полного кайфа - с SAS на FCoE...
И еще при этом потом всякие lm_sensors, ipmi, модули ядра и прочее апгрейдить за@...ся.
А если это _клиентский_ сервер - то там еще и конфиги менять без согласования может быть нельзя. Приплыли? Приплыли. А с виртуалкой клиент переноса не заметит в принципе.
>> Я тебе расскажу что еще проще - перенести винты в более мощную
>> машину.
> Ну давай, угу, успехов. С HP/CCISS на LSI, например. Или, для полного
> кайфа - с SAS на FCoE...железо нужно выбирать головой, а не тем, что вместо нее.
> железо нужно выбирать головой, а не тем, что вместо нее.Ну вот, аргументы кончились. Начались ограничения, понты и отмазки. А с ESXi мне в сущности пофиг, какое там железо :) Преимущество. Явное и очевидное.
>> железо нужно выбирать головой, а не тем, что вместо нее.
> Ну вот, аргументы кончились. Начались ограничения, понты и отмазки. А с ESXi
> мне в сущности пофиг, какое там железо :) Преимущество. Явное и
> очевидное.Аргументы давно кончились у сторонников: запихай все в ВМ и сделай по ВМ на каждый чих.
Я конечно безмерно рад, что вам там пофиг на железо, но: а. хост-систему нужно тоже еще подготовить; б. лайф-миграции не будет, если нету nas-а, а его не будет при некоторых требуемых tps.
> Я конечно безмерно рад, что вам там пофиг на железо, но: а.
> хост-систему нужно тоже еще подготовить; б. лайф-миграции не будет, если нету
> nas-а, а его не будет при некоторых требуемых tps.1. Хост-систему "готовить" в реальности менее часа при наличии типовых конфигураций.
2. NAS -> SAN (FC/FCoE/IB), и TPS может быть достигнут вполне нормально.
> Я тебе расскажу что еще проще - перенести винты в более мощную машину.И сколько при этом будет даунтайм? А у тех кто это делает нормально - нулевой. Догадываетесь что с точки зрения клиента лучше? Вот за счет такого отношения к клиентуре народ и драпает на забугорные хостинги. Там по крайней мере понимают что клиентов факапать не надо. А наши понимают только когда жрать становится нечего.
>> Я тебе расскажу что еще проще - перенести винты в более мощную машину.
> И сколько при этом будет даунтайм?<15 минут. остановил систему, выдернул винты из хотсвопов, воткнул в хотсвопы новой железки, запустил.
> <15 минут. остановил систему, выдернул винты из хотсвопов, воткнул в хотсвопы новой
> железки, запустил.А на железке иной дисковый контроллер или вообще иная схема работы с дисками (DAS->iSCSI, к примеру). Далее начинается трах ручками...
Или предлагаете под железку 5-летней давности новое железо подгонять, теряя производительность, управляемость и прочее?
>> <15 минут. остановил систему, выдернул винты из хотсвопов, воткнул в хотсвопы новой
>> железки, запустил.
> А на железке иной дисковый контроллер или вообще иная схема работы с
> дисками (DAS->iSCSI, к примеру). Далее начинается трах ручками...надо будет в nas-е менять схему работы с дисками, что делать будете?
кто же отрицает, что ВМ хороши в некоторых аспектах, но не всегда и не везде, да и в данном случае, железо меняется не часто, раз в три-пять лет, переживали смену ide->sata->sas->ssd, где-то еще со скази на сас, обычно много проблем не это доставляло.
> надо будет в nas-е менять схему работы с дисками, что делать будете?Зачем, простите?
>> <15 минут. остановил систему, выдернул винты из хотсвопов, воткнул в хотсвопы новой
>> железки, запустил.
> А на железке иной дисковый контроллер или вообще иная схема работы с
> дисками (DAS->iSCSI, к примеру). Далее начинается трах ручками...Нет, не начинается. Буратин, которые такие вещи допускают - в приличных местах уволили раньше.
> Нет, не начинается. Буратин, которые такие вещи допускают - в приличных
> местах уволили раньше.В приличных местах увольняют буратин которые "а вот если так изогнуться", "а вот если персонал заменить", "железо правильное", и вообще, "да фиг с ним, клиент 15 минут как-нибудь подождет". Вот таких надо гнать ссаными тряпками. Если хочется предоставлять клиентам адекватный сервис.
> Ограничение простое: административный оверхед. Хостер знать ничего не желает об устройстве
> клиентских виртуалок и сервисов в них, например.Вас удивит если я скажу, что больше половины хостеров - просто *не имеет* клиентских виртуалок? Что, до вашей виртуализации клиентов между серверами не таскали? Окститесь!
Вообще, фейерический бред: технологию, *уже* использующую виртуализацию приводить в качестве довода необходимости виртуализации.
> Да и ынтырпрайзному админу
> лишний раз загаживать свою голову такими сакральными знаняими в общем то ни к чему.А виртуалку кто администрировать будет? Вася Пупкин из отдела маркетоидов? Тогда факап придет к вам, ждите.
Знание о том, что администрирует человек - никогда вредными не были. Это необходимость. Обычно - администратор является просто частью команды, которая все это разрабатывает/собирает.
> Представляете себе хостера который два дня вдупляет как выпилить сервисы "вон того
> юзера" лобзиком, чтобы ничего не отвалилось?Я представляю себе, что мир не заканчивается на VPS-хостинге.
> Вас удивит если я скажу, что больше половины хостеров - просто *не имеет*
> клиентских виртуалок?Попробуйте перечитать сабж и подумать о том что ваши сведения попросту протухли. Если лично у вас что-то там не используется - это еще не значит что у всех так же.
> А виртуалку кто администрировать будет? Вася Пупкин из отдела маркетоидов?
А виртуалку будет админить или сам клиент, или тот кому он за это заплатит. Ну т.е. сторонний админ или даже сам хостер (ряд хостеров предлагают подобные услуги за отдельную мзду). Как раз на все запросы клиентов есть ответ.
> Тогда факап придет к вам, ждите.
Странно, не вижу никаких факапов. Если клиент вызвался что-то сам админить и факапнул все - это у него факап, хостеры за это не отвечают.
> Знание о том, что администрирует человек - никогда вредными не были.
(switching to client mode) Как клиент я вообще не желаю чтобы хостер рылся в моих виртуалках. Там всякая интеллектуальная собственность, конфиденциальные данные и прочая. Вы кто вообще такое, чтобы там копаться? И да, найти хостера который не будет втюхивать услуги полудурошных красноглазых кульсисопов типа вас - совершенно не проблема в XXI веке. Как клиент я в гробу видал админиа типа вас на моей виртуалке, скажем прямо. А вот даунтаймы меня очень напрягают, например. Все что мне надо - чтобы хостер предоставил мощности и получил бабло. Остальное я сам сделаю. И да, мне со стороны клиента тоже удобно если всякие левые личности не будут колупаться грязными руками в виртуалке а просто подвинут сие всем скопом на соседний сервак при явном перегрузе текущего. Без прерывания сервиса и какой либо мануальщины, чреватой факапами. Лучше всего если даже двигать будет автомат, на основе анализа загрузки хостов. Риск факапа еще ниже. Все-таки любая мануальщина - чревата. Машины реже ошибаются чем красноглазые ДЛБ с горящими глазами.
> Это необходимость. Обычно - администратор является просто частью команды, которая
> все это разрабатывает/собирает.В случае ынтырпрайзов - еще может быть. И то - унифицировать все до состояния "вычислительные ресурсы" + "виртуалки-сервисы" достаточно соблазнительно даже там.
> Я представляю себе, что мир не заканчивается на VPS-хостинге.
Я тоже. И вижу что туева хуча ынтырпрайзов тоже юзает виртуалки. Потому что им так удобно. Я их в этом прекрасно понимаю. И?
>> Вас удивит если я скажу, что больше половины хостеров - просто *не имеет*
>> клиентских виртуалок?
> Попробуйте перечитать сабж и подумать о том что ваши сведения попросту протухли.В "сабже" - с натяжкой больше половины серверов *в конкретной выборке* используют виртуализацию. Причем тут хостинг вообще и кто еще тут "протух"?
> А виртуалку будет админить или сам клиент, или тот кому он за
> это заплатит.VPS-хостинг - мертворожденная отрасль для лохов. Так понятно?
В реальности "ынтырпрайза" - клиент "виртуалки" тот же самый, что и владелец физического сервера. И еще кучи того, что вокруг стоит. Босс ваш, короче.
Осмыслите эту простую вещь и попытайтесь заново ответить на вопрос. Удачи.
>> Тогда факап придет к вам, ждите.
> Странно, не вижу никаких факапов.Ну какие там на говнохостингах факапы, полноте.
>> Знание о том, что администрирует человек - никогда вредными не были.
> (switching to client mode) Как клиент я вообще не желаю чтобы хостер
> рылся в моих виртуалках.(устало) Говнохостингом не кончается мир. Представьте на минутку, что железо и проект, который на нем крутится - принадлежит Васе. Вы и куча программистов - работаете на этого Васю. Вася - ваш клиент. Это реалии любого highload проекта.
>> Я представляю себе, что мир не заканчивается на VPS-хостинге.
> Я тоже. И вижу что туева хуча ынтырпрайзов тоже юзает виртуалки. Потому
> что им так удобно. Я их в этом прекрасно понимаю. И?Подрастете - может еще что поймете.
> В "сабже" - с натяжкой больше половины серверов *в конкретной выборке* используют
> виртуализацию. Причем тут хостинг вообще и кто еще тут "протух"?Да, и эта конкретная выборка в виде х86 - львиная доля рынка, между прочим. Остальные в основном занимают сильно нишевые сегменты и массовостью не отличаются.
> VPS-хостинг - мертворожденная отрасль для лохов. Так понятно?
VPS хостинг - это логичное заполнение ниши между морально устаревшим отстоем типа шаредов и дорогущими дедиками. Туда же и все облака, только у тех еще потенциально возможность масштабироваться на автомате под задачи (в случае хостинга - с оплатой по фактически потребленным ресурсам).
> В реальности "ынтырпрайза" - клиент "виртуалки" тот же самый, что и владелец
> физического сервера. И еще кучи того, что вокруг стоит. Босс ваш, короче.Да, и им тоже удобно когда сервисы отвязаны от железа. А вот возиться с поиском суперадмина которых один на миллиард им нифига не удобно. В лучшем случае ребаланс нагрузки по этому поводу вообще автоматический - такое развитие виртуализаторов называется облаками.
> Осмыслите эту простую вещь и попытайтесь заново ответить на вопрос. Удачи.
Я уже осмыслил что виртуализаторы очень хорошо укладываются в хотелки многих энтерпрайзов. С очень большим числом хостов. Которые в силу числа хостов просто не могут въезжать что там на каждом конкретном из них крутится.
Ну да, я жду когда вы покажете всяким амазонам и рэкспейсам какие они там лохи и уделаете их по объему предоставляемых услуг, капитализации, и вообще.
> Ну какие там на гoвнохостингах факапы, полноте.
Я вообще не являюсь хостингом. Может быть зря. Но факт.
> (устало) Гoвнохостингом не кончается мир. Представьте на минутку, что железо и
> проект, который на нем крутится - принадлежит Васе. Вы и
> куча программистов - работаете на этого Васю. Вася - ваш
> клиент. Это реалии любого highload проекта.Проекты бывают разные. Бывают ынтырпрайзы на сотни железных хостов, с кучами разнородных сервисов всех мастей, так что произвольно взятый админ опухнет въезжать в особенности всех сервисов. Вот таким виртуализация очень удобна - за счет унификации и возможности кантовать как юнит виртуалку со всей начинкой. Так заведомо ничего не отвалится.
> Подрастете - может еще что поймете.
Вы уже достали вашими комплексами насчет возраста. Подрастете - поймете насколько же по идиотски это выглядит со стороны. Очередной пионер в 1 шарашке рога и копыта пытается всем доказать что его шарага - самая правильная. И раз там нет виртуализации то и весь мир должен так же. Бывают же смешные пионеры на свете.
> Будто что-то запрещает просто перетащить сервисы... Вы не из параллельного мира?
> - в моей Вселенной такого ограничения в природе нет.Ну, если вас не напрягает совмещать конфигурации, зависимости, подстраивать все под допустим схему каталогов другого сервера, где-то выкраивать место, перенарезать права, переконфигурить IP и прочее-прочее - пожалуйста. Вот только вы к этой операции будете готовиться неделю (в случае сложного сервиса), а я - менее суток (+ ждать окна работ). И вся разница. Да и шанс ошибки в переконфигурации при переносе виртуалки - близок к нулю, а в вашем случае человеческий фактор играет огромную роль. Т.е. разница в надежности, и немалая.
>> Будто что-то запрещает просто перетащить сервисы... Вы не из параллельного мира?
>> - в моей Вселенной такого ограничения в природе нет.
> Ну, если вас не напрягает совмещать конфигурации, зависимости, подстраивать все под допустим
> схему каталогов другого сервера, где-то выкраивать место, перенарезать права, переконфигурить
> IP и прочее-прочее - пожалуйста. Вот только вы к этой операции
> будете готовиться неделю (в случае сложного сервиса), а я - менее
> суток (+ ждать окна работ). И вся разница. Да и шанс
> ошибки в переконфигурации при переносе виртуалки - близок к нулю, а
> в вашем случае человеческий фактор играет огромную роль. Т.е. разница в
> надежности, и немалая.1. все должно быть максимально унифицировано и построено, по возможности, по одной схеме. не должно быть зоопарков.
2. все что не может быть унифицировано и выбивается из общей концепции должно находиться на отдельном железе, или, если это возможно (имеет смысл), в контейнерах и ВМ.
3. софт (и система туда же) должен регулярно обновляться, что бы не было проблем с зависимостями.
> 1. все должно быть максимально унифицировано и построено, по возможности, по одной
> схеме. не должно быть зоопарков.Ну давайте, унифицируйте мне шаредхостинги допустим на ISPConfig и ZPanel. В пределах одной системы, без чрутов и серьезных модификаций той и другой.
> 2. все что не может быть унифицировано и выбивается из общей концепции
> должно находиться на отдельном железе, или, если это возможно (имеет смысл),
> в контейнерах и ВМ.Вот! Именно для этого VM и нужны!
>> 1. все должно быть максимально унифицировано и построено, по возможности, по одной
>> схеме. не должно быть зоопарков.
> Ну давайте, унифицируйте мне шаредхостинги допустим на ISPConfig и ZPanel. В пределах
> одной системы, без чрутов и серьезных модификаций той и другой.Есть конфигурашки с одной панелью, есть с другой, какие проблемы? У меня три таких разных конфигуряшки, на трех панелях. Перенос с панели на панель - жопа. Перенос с сервера на сервер с одинаковой панелью - нет проблем.
Унифицировать, это не значит сделать все абсолютно одинаково везде.
Проблем никаких. Просто расщепление на "вычислительные ресурсы" и "сервисы на оных" - это абсолютная унификация и есть. Виртуалки и облака - как раз об этом самом, если отбросить маркетинговый шит.
> Проблем никаких. Просто расщепление на "вычислительные ресурсы" и "сервисы на оных" -
> это абсолютная унификация и есть. Виртуалки и облака - как раз
> об этом самом, если отбросить маркетинговый шит.и? что упрощается? то что вы загнали в виртуалку обе ваши конфигурашки и добавили третью: хост-систему?
> и? что упрощается?Все. Можно передвинуть виртуалку "с хостпанелью такой-то", совершенно не сношая себе мозг вопросом что там на хосте куда эта виртуалка задвигается.
> Ну, если вас не напрягает совмещать конфигурации, зависимостиКонфигурации - несколько стандартных. Дополнительные зависимости - автоматически разрешаются при переносе (тем же puppet).
> подстраивать все под допустим схему каталогов другого сервера
такого бардака просто нет.
> где-то выкраивать место
А у вас оно автомагически появится на сервере? Все просто: где нет места - туда не несем. Где есть - ничего выкраивать не нужно. Можно подрастить lvm-тома, в случае нужды.
> перенарезать права, переконфигурить IP и прочее-прочее
мсье - любитель извращений?!!
> Да и шанс
> ошибки в переконфигурации при переносе виртуалки - близок к нулю, а
> в вашем случае человеческий фактор играет огромную роль.В вашем случае - человеческий фактор спокойно аукнется в другом месте. Из-за получившегося (судя по необходимым вам "напрягающим" пунктам переноса) бардака конфигурации, к примеру.
> Конфигурации - несколько стандартных. Дополнительные зависимости - автоматически
> разрешаются при переносе (тем же puppet).Несомненно, можно изобрести велик с квадратными колесами и потом доказывать что это лучше обычных. А то что трясет и педали крутить сложнее - да и фиг с ним. Особо прокачанный спортсмен myhand на таком может катить даже в гору!
> В вашем случае - человеческий фактор спокойно аукнется в другом месте.
В случае виртуализатора он может вообще отсутствовать - когда ресурсы распределяет железный канцлер, в окончательном варианте группа хостов + виртуализатор = облако. И таки устраняется важный фактор - нужда админов греть голову над интимными особенностями конфигураций.
>> Конфигурации - несколько стандартных. Дополнительные зависимости - автоматически
>> разрешаются при переносе (тем же puppet).
> Несомненно, можно изобрести велик с квадратными колесами и потом доказывать что это лучше обычных.Или можно просто нести вашу чушь "с великами", притворяясь что она как-то касается вопроса.
>> В вашем случае - человеческий фактор спокойно аукнется в другом месте.
> В случае виртуализатора он может вообще отсутствоватьЯ *написал* где конкретно он присутствует. Прямо в продолжении цитированной фразы. Просто одна форумная школота - выкинула неудобную ей часть и пошла 100500-й раз продолжать нести пургу про облака...
Гуляй, Вася.
>> 6) Позволяет абстрагироваться от железа.
> В вакууме запускаете виртуалки?
>> Виндовые серверы на старом, или умирающем железе - очень веселая штука.
> Они и на новом - не менее "веселая". Не используйте "виндовые
> сервера". Но нет - как маленькие, тащат всякую гадость...Отличная логика.
Не делайте этого, не делайте того.
Лишь бы не появился профит от виртуализации.>> 7) Позволяет увеличивать мощность сервера в виртуалке в 2 клика.
> Из пустоты...Из ресурсов сервера виртуализации.
Если из 80 гиг заняты 30, какой-то виртуалке можно добавить оперативку.
Причем, не нужно ехать в дата центр.
Но вы можете по старинке:)>> 8) Позволяет очень быстро создавать новые виртуалки на основе существующей.
> Зашибись. Moar виртуализации! Быстро, молодежно...Никогда не практиковали отдельные виртуалки для разработчиков?
Попробуйте, очень удобно.
> Отличная логика.
> Не делайте этого, не делайте того.
> Лишь бы не появился профит от виртуализации.От винды - профит не появится, несмотря на любые виртуализации.
>>> 7) Позволяет увеличивать мощность сервера в виртуалке в 2 клика.
>> Из пустоты...
> Из ресурсов сервера виртуализации.
> Если из 80 гиг заняты 30, какой-то виртуалке можно добавить оперативку.Ну так и ничего нового, значит. Точно также можно перенести любой сервис на простаивающий подходящий сервер. Причем ишшо в 90-х, малыш.
>>> 8) Позволяет очень быстро создавать новые виртуалки на основе существующей.
>> Зашибись. Moar виртуализации! Быстро, молодежно...
> Никогда не практиковали отдельные виртуалки для разработчиков?Я много для чего использую виртуализацию. Просто не писаю кипятком от этого и знаю о других решениях.
>> Отличная логика.
>> Не делайте этого, не делайте того.
>> Лишь бы не появился профит от виртуализации.
> От винды - профит не появится, несмотря на любые виртуализации.Это уже другой вопрос, скорее религии, чем бизнеса.
>>>> 7) Позволяет увеличивать мощность сервера в виртуалке в 2 клика.
>>> Из пустоты...
>> Из ресурсов сервера виртуализации.
>> Если из 80 гиг заняты 30, какой-то виртуалке можно добавить оперативку.
> Ну так и ничего нового, значит. Точно также можно перенести любой
> сервис на простаивающий подходящий сервер. Причем ишшо в 90-х, малыш.Классно, у вас много простаивающих серверов.
Тогда вам и правда не нужна виртуализация.
А ваш директор в курсе, что у вас куча лишних серверов?)>>>> 8) Позволяет очень быстро создавать новые виртуалки на основе существующей.
>>> Зашибись. Moar виртуализации! Быстро, молодежно...
>> Никогда не практиковали отдельные виртуалки для разработчиков?
> Я много для чего использую виртуализацию. Просто не писаю кипятком от
> этого и знаю о других решениях.Я тоже не писаю.
Но, мне кажется, вы настроены категорично против виртуализации.
Что угодно, лишь бы её не использовать.
>> От винды - профит не появится, несмотря на любые виртуализации.
> Это уже другой вопрос, скорее религии, чем бизнеса.Да нет. Самое что ни на есть техническое утверждение. Будете с этим спорить?
>> Ну так и ничего нового, значит. Точно также можно перенести любой
>> сервис на простаивающий подходящий сервер. Причем ишшо в 90-х, малыш.
> Классно, у вас много простаивающих серверов.Попал пальцем в небо, телепат. Выражусь иначе: на менее загруженный сервер. Стало легче?
> Но, мне кажется, вы настроены категорично против виртуализации.
Когда кажется... Ну, ты понел.
> Да нет. Самое что ни на есть техническое утверждение. Будете
> с этим спорить?Есть много ПО, которое ставится только на windows.
Причем стоимость лицензии windows там составляет 1-10% от стоимости этого ПО.
Или ПО, которое держать на windows проще.
Например, попробуйте подержать на linux те же Crystal Reports/Business Objects.
Это вы на форуме можете писать "венда не нужна!!!".
А у руководства все просто: нужно, значит должно стоять.>> Но, мне кажется, вы настроены категорично против виртуализации.
> Когда кажется... Ну, ты понел.Понел - это пять)
А смысл вам категорически приводить доводы против виртуализации, если вы не против неё?
> А у руководства все просто: нужно, значит должно стоять.Когда руководство начинает принимать технические решения - действительно, все просто. Найдите хорошую работу.
> А смысл вам категорически приводить доводы против виртуализации, если вы не против неё?
Не люблю всяческих "фанатов".
Мне уже интересно - а что, у виртуализации есть минусы? Я пока только плюсы видел.
> Мне уже интересно - а что, у виртуализации есть минусы? Я
> пока только плюсы видел.Есть, но все они относятся к минусам реализации, а не идеи или ДНК .
На Z/9 вон вообще по другому не работают уже 40 лет как со времeн OS/360
винда на virtualbox работает быстрее, чем вне коробки
два чаю этому господину. ни за что не поверил бы, если бы не попробовал.
> два чаю этому господину. ни за что не поверил бы, если бы не попробовал.А что там не верить то? Виртуалбокс читерит и преобразует синхронную запись в асинхронную. Что чревато некислым факапом если например питание слетит или что там еще.
>...винда на virtualbox...Это ты ещё, наверное, на Hyper-V не пробовал...
а что, сильно серьёзная штука?
> а что, сильно серьёзная штука?Сильно гиморная скорее. Для этой пакости нет ни 1 вменяемого управлятора. Нет, майкрософт конечно их выпускает, но это такого качества что если у вас есть враги - смело им рекомендуйте. У их админов сразу добавится тонна проблем на ровном месте.
> винда на virtualbox работает быстрее, чем вне коробкиВиртуалбокс поди кладет болт на синхронную запись и делает ее асинхронно. Все бы ничего, только при внеплановом шатдауне есть неиллюзорный риск факапа. С которым журналящая ФС не справится, поскольку уповала на честную синхронность записи, т.е. что запись физически сливается на диск когда это запросили. А виртуалбокс - известный звездун в этом плане.
Виртуалбокс кагбе не ынтырпрайзно. Просто по той причине что держать в такой коробке сервера просто неудобно с точки зрения админства этой коробки.Ну а воркстэйшн вендовозный в коробке это из серии "- товарищ миллиционер, а если у вас автомат случайно выстрелит ? - ну хер с ним, перезаряжу..."
> а что, у виртуализации есть минусы?Да, есть. Оверхед от виртуализатора, например. Вполне ощутим на вещах типа дискового I/O.
>> а что, у виртуализации есть минусы?
> Да, есть. Оверхед от виртуализатора, например. Вполне ощутим на вещах типа дискового
> I/O.Этот оверхед кстати часто вполне себе компенсируется более равномерной утилизацией дисковой подсистемы, в том числе за счет elevator seeking (а позиционирование зачастую медленнее чтения/записи). Поэтому время random access read/write на виртуализированном сторадже на круг резко падает (так как оно вовсе не суммируется для всех ВМ). Это как раз тот случай когда 9 женщин вынашивают одного ребенка за месяц.
вы прослушали админа локал хоста...То то при серьезных нагрузках прокидывают sas контролер прямо в виртуалку как pci устройство...
А мужики то не знали что так будет проще..PS. когда у тебя будут скорости выше 3GB/s с raid6 рейда - приходи поговорим.. ext4 отдельный тормоз на этих скоростях..
вы прослушали админа локалхоста...При серьезных нагрузках юзают нормальные NAS и multipath FC/FCoE/IB.
вообще-то SAN, но верно.
> вообще-то SAN, но верно.Да, SAN.
вообще-то и SAN, и NAS
>PS. когда у тебя будут скорости выше 3GB/s с raid6 рейда - приходи поговорим.. ext4 отдельный тормоз на этих скоростях..гуглу расскажи.
зыж
ха, «скорости выше 3GB/s с raid6»! да ты такого количества винтов то ещё не виделзыж
ззыж
модераторы, често надоело уже враньё этого перца.
Нормальные пацаны пользуются паравиртуальными драйверами (если виртуалка работает в HVM) или ядрами (если PV) в системах виртуализации и не греют себе голову.Кстати, откройте великую тайну нам, админам локалхоста, с каких пор контроллер сам разучился делать elevator seeking ? А то он оно что в мире творится, а пацаны то и не знают. И заодно уж сразу вторую, как хотя-бы с точки зрения секьюрити расшарить между двумя VM один контроллер прокинутый как "pci устройство" ?
> вы прослушали админа локал хоста...
> То то при серьезных нагрузках прокидывают sas контролер прямо в виртуалку как
> pci устройство...
> А мужики то не знали что так будет проще..
> PS. когда у тебя будут скорости выше 3GB/s с raid6 рейда -
> приходи поговорим.. ext4 отдельный тормоз на этих скоростях..raid6 - это понт такой?)
> Этот оверхед кстати часто вполне себе компенсируется...забивоном на синхронность I/O умниками типа виртуалбокса, после чего надежность работы ФС, БД и прочая в виртуалке, полагающихся на синхронность I/O для фиксации транзакций - начинает оставлять желать, ага. А так - оверхед есть, сам по себе скомпенсироваться он не сможет. Например читает некто файл. Большой. Линейно. В случае с 1 виртуалкой и доступом к файлу будет некая просадка. А если несколько виртуалок да еще и seek начнется - просадка будет неиллюзорная весьма.
Есть, как ни странно.1. Оверхед на разделение ресурсов (небольшой по CPU, серьезный по памяти, еще более серьезный - по диску).
2. Если падает железо - страдает многое. Даже имея shared storage и онлайн-миграцию - все равно получаем несбалансированную загрузку на нодах, т.е. желательно держать как минимум N+1 площадку, а в случае больших инсталляций - и N+M.
3. Бывают грабли в самих виртуализаторах. Выливается в эпические баги на дисковых подсистемах (ESXi+DAS любит "болеть"), либо в п.2.
4. Несколько неудобно, когда нужно отдать виртуалку клиенту с овербукингом - например забывает клиент поставить ballooning driver - и всё, имеем его кеш, сожравший память.Это навскидку. Удобства и плюшек не отменяет - пользовались, пользуемся и будем пользоваться в широком спектре задач.
"у виртуализации есть минусы?"Конечно. Например берем VMWARE ESX за много-много $$$$. Ставлю туда CentOS, сеть не работает. Нужно какие-то корявые модули компилировать, подгружать. Есть риск, что после апгрейда CentOS-а на следующую ветку, всё накроется медным тазиком.
Ну и по производительности. Железный есть сервак с 16ГБ ОЗУ (с виндовсом :) ), он по производительности просто вдребезги разносит любую виртуалку.
Вот вам и модно, молодежно :)
p.s. С вышеперечисленными плюсами, в общем-то согласен. Но везде лепить виртуализацию - это гон.
> Конечно. Например берем VMWARE ESX за много-много $$$$. Ставлю туда CentOS, сеть
> не работает. Нужно какие-то корявые модули компилировать, подгружать. Есть риск, что
> после апгрейда CentOS-а на следующую ветку, всё накроется медным тазиком.Странный у вас ESX и CentOS. Несколько лет работают инсталляции, никаких проблем. vmxnet уже давно в ядре, да и можно e1000 отделаться. Просто вы, видимо, поиграться ставили.
>Ну и по производительности. Железный есть сервак с 16ГБ ОЗУ (с виндовсом :) ), он по производительности просто вдребезги разносит любую виртуалку.Нагрузите этот сервак штатным для вашей конторы набором сервисов и когда один из них упадет, утащив за собой половину остальных, вам будет сугубо не до производительности.
> не до производительности.А еще - прикольно же, если вам пионер хакнул допустим, форум, а заодно попал на внутреннй сайт, почтарь, dns-сервак, сиквел и что там у вас еще. Вот виртуализация основательно ограничивает вред от дестроя со стороны некоего сервиса, его багов, ошибок админа или тех кто сие похакал. Хотя обладатели серваков на винде обычно понимают лишь когда с ними обойдутся так же как comodohacker с diginotar-ом.
> :) ), он по производительности просто вдребезги разносит любую виртуалку.Обычно виртуалки делают по одной простой причине: стоит сервак, производительности настолько дофига что то что там стоит - юзает его на 5%. А еще 95% - груши околачивают. Получается что 95% бабла отгроханного на сервер просто нифиганеделает. Понимаете, никому нафиг не упали рекорды. Производительности или хватает или нет. А то что оно могло бы еще в 20 раз больше народа обслужить чем есть сейчас - так это, оно актуально только если эти "в 20 раз" могут появиться. А если не могут - сервак просто неэффективно используется, простаивая большую часть времени.
>> :) ), он по производительности просто вдребезги разносит любую виртуалку.
> Обычно виртуалки делают по одной простой причине: стоит сервак, производительности настолько
> дофига что то что там стоит - юзает его на 5%.
> А еще 95% - груши околачивают. Получается что 95% бабла отгроханного
> на сервер просто нифиганеделает. Понимаете, никому нафиг не упали рекорды. Производительности
> или хватает или нет. А то что оно могло бы еще
> в 20 раз больше народа обслужить чем есть сейчас - так
> это, оно актуально только если эти "в 20 раз" могут появиться.
> А если не могут - сервак просто неэффективно используется, простаивая большую
> часть времени.А просто выбирать железо под задачу, а не лихорадочно искать, чем бы, откатив конских денег, занять конский сервер, нах... не нужный под данную конкретную задачу здась и сейчас?
> А просто выбирать железо под задачу, а не лихорадочно искать, чем бы,
> откатив конских денег, занять конский сервер, нах... не нужный под данную
> конкретную задачу здась и сейчас?Итак, задача: DNS-сервер на 500 пользователей. DHCP-сервер на те же 500 пользователей. Файл-сервер на пару терабайт. Надо каждого по два, с нормальным серверным контрактом (тазики отлетают). Принцип "1 платформа - 1 задача", как обязательное условие. Варианты? Логично юзать виртуализацию, а не 6 физических сервачков.
Дядя ты дурак? Поставь че нить на атоме - и то за глаза хватит.
> Дядя ты дурак? Поставь че нить на атоме - и то за глаза хватит.Дядя, ты дурак? С виртуализацией на кучу VMов мощностью с атом можно попилить уже существующий сервант. Даром. А атомы отдельно покупать надо. Баксов по 200 штучка (да, у интеля кроме всего прочего конские цены).
С одной стороны вы правильно заметили что сервера нынче вымахали до таких махин что столько многим и не надо. С другой - атомы даже не есть лобовые конкуренты VMам. Хотя-бы за счет своей конской стоимости. ARMы какие-нибудь уже могут поинтереснее смотреться, но врядли это прямая замена VM.
>> Дядя ты дурак? Поставь че нить на атоме - и то за глаза хватит.
> Дядя, ты дурак? С виртуализацией на кучу VMов мощностью с атом можно
> попилить уже существующий сервант. Даром. А атомы отдельно покупать надо. Баксов
> по 200 штучка (да, у интеля кроме всего прочего конские цены).и все эти ВМ-ы, со всеми вашими сервисами будут дружно ложиться при падении машинки.
> и все эти ВМ-ы, со всеми вашими сервисами будут дружно ложиться при падении машинки.Так по условиям задачи AlexAT - их два. Ну, один лег - второй работает. И да, неплохо сдуть 5 (или более) серваков в всего 2. С уровнем изоляции почти на уровне того как если бы было 5 железяк.
>> и все эти ВМ-ы, со всеми вашими сервисами будут дружно ложиться при падении машинки.
> Так по условиям задачи AlexAT - их два. Ну, один лег -
> второй работает.по условиям задачи у вас большие iops-ы для системы хранения данных.
> И да, неплохо сдуть 5 (или более) серваков в
> всего 2. С уровнем изоляции почти на уровне того как если
> бы было 5 железяк.это только если от них нет большой нагрузки и не критично падение или ребут пяти ВМ.
> по условиям задачи у вас большие iops-ы для системы хранения данных.Ну знаете, атом тоже большие иопсы не потянет :P.
> это только если от них нет большой нагрузки и не критично падение или ребут пяти ВМ.
Ну так в условиях от AlexAT - серваков будет два. И даже если один умрет, второй продолжит работу.
>Принцип "1 платформа - 1 задача", как обязательное условие.Что этим принципом желаете решить?
> Что этим принципом желаете решить?Довольно много всего
- Просто админить.
- Просто мониторить и анализировать.
- Просто балансировать ресурсы.
- Улучшение изоляции между сервисами - взломы будут зачастую наносить меньший урон чем могли бы.
> - Просто админить.что проще администь: 5-ть систем в каждой по сервису и хост-систему или одну систему и пять сервисов?
> - Просто мониторить и анализировать.
а какие сложности в мониторинге и анализе не в ВМ?
> - Просто балансировать ресурсы.
это перетягивать с сервера на сервер? т.е. для начала прос.ать i/o дисков, потом еще поддерживать какой-то nas, это проще чем просто грамотно ограничить сервисы на одной системе?
> - Улучшение изоляции между сервисами - взломы будут зачастую наносить меньший урон
> чем могли бы.единственное, что может быть, но еще под вопросом. лишний код - лишние баги.
> что проще администь: 5-ть систем в каждой по сервису и хост-систему или
> одну систему и пять сервисов?Ясен пень 5 систем по 1 сервису. Например на сервере перегруз по ресурсам. Двигаем тяжелый VM куда-то еще. Знаний о том что там за сервис жил и какая у него конфигурация нам не надо. И вообще, все прозрачно, ничего не отвалится и прочая, т.к. оно со своим окружением целиком съехало. В монстре с 5 сервисами - придется вдуплять кто из сервисов, как его выколупать, что может отвалиться при переезде и прочая. Вот уж гемор на ровном месте + повышенный риск факапа. Как известно, самое слабое место системы - это человек.
>> - Просто мониторить и анализировать.
> а какие сложности в мониторинге и анализе не в ВМ?В том что больше барахла на машине и поведение машины в целом становится менее очевидным. Сложно, знаете ли, из какофонии суммарных сигналов отдельные составляющие выделять.
>> - Просто балансировать ресурсы.
> это перетягивать с сервера на сервер? т.е. для начала прос.ать i/o дисков,
> потом еще поддерживать какой-то nas, это проще чем просто грамотно ограничить
> сервисы на одной системе?То-есть, просто балансировать использование ресурсов. В идеале - автоматически. Если кто-то перегружен, а кто-то недогружен - свалить часть нагрузки на него. С виртуалками это норма жизни. Даже на автомате такое бывает. С кантованием сервисов вы за....сь это делать. Вот и получается что виртуализация повышает гибкость управления ресурсами. Просто ребалансировать загруженность хостов.
> единственное, что может быть, но еще под вопросом. лишний код - лишние баги.
Вот это может быть. И бывает. Но в силу массовой внедрежки сколь-нибудь заметные баги как вы понимаете отпадают.
>>> - Просто мониторить и анализировать.
>> а какие сложности в мониторинге и анализе не в ВМ?
> В том что больше барахла на машине и поведение машины в целом
> становится менее очевидным.Больше??! Пардон. Был один физический сервер с X сервисами и окружением. Стал - минимум один физический сервер + X виртуальных, в каждом сервис + окружение.
Чего и где стало больше - вы с устным счетом вообще дружите?
> То-есть, просто балансировать использование ресурсов. В идеале - автоматически. Если кто-то
> перегружен, а кто-то недогружен - свалить часть нагрузки на него. С
> виртуалками это норма жизни.Пока не уволят такого "свалятора". И наймут тех, кто решает задачу правильными средствами: масштабированием системы, поиском узких мест и их устранением и т.п.
> Например на сервере перегруз по
> ресурсам. Двигаем тяжелый VM куда-то еще. Знаний о том что там
> за сервис жил и какая у него конфигурация нам не надо.Если есть перегруз, то разбираться нужно _В_ЛЮБОМ_ случае. Это может оказаться и ддос и глюки ПО и поиск узких мест хаукром и мало ли что еще.
Ну и до кучи, есть перегруз по диску, куда двигаете ВМ?>>> - Просто мониторить и анализировать.
>> а какие сложности в мониторинге и анализе не в ВМ?
> В том что больше барахла на машине и поведение машины в целом
> становится менее очевидным. Сложно, знаете ли, из какофонии суммарных сигналов отдельные
> составляющие выделять.То ли вы не админ, то ли я не знаю... у вас консольку отобрали?
Гм. Про работу Centos с гипервизорами вам ответили уже.
А про обновление расскажите поподробнее, какие такие были проблемы? Ну если вы конечно не пытались центос 5 до 6 версии обновить, что самими разработчиками Red Hat/Centos категорически не приветствуется, а приветствуется миграция.
> "у виртуализации есть минусы?"
> Конечно. Например берем VMWARE ESX за много-много $$$$.Очень рекомендую xen.
Можно взять suse, там при установке можно выбрать профиль - сервер виртуализации.
>> "у виртуализации есть минусы?"
>> Конечно. Например берем VMWARE ESX за много-много $$$$.
> Очень рекомендую xen.
> Можно взять suse, там при установке можно выбрать профиль - сервер виртуализации.только не забыть обновить sort, uniq и пр.
Я даже на своём ноуте для некоторых задач пользуюсь виртуальными машинами. Например, поднять тестовый веб-сервер.
Так что познавай силу виртуализации, юный падаван.
>Я даже на своём ноуте для некоторых задач пользуюсь виртуальными машинами. Например, поднять тестовый веб-сервер.
>Так что познавай силу виртуализации, юный падаван.А бреетесь вы, случайно, не деревообрабатывающим станком?
python -m SimpleHTTPServer
или
python -m http.server 8000
спасет отца русской демократии.
> спасет отца русской демократии.Вот уж нафиг - пародия на вебсервак от питонистов, при том что из репов настоящий сервак вкатить - 10 секунд занимает. Оно еще и с скриптами для старта сервиса при взлете машины, более-менее разумным и безопасным дефолтным конфигом и прочая.
"Нафига нужны велосипеды, мотороллеры, автомобили и прочие грузовики? Смотрите как по этому шоссе можно замечательно топать пешком!"
Я в своем вузе вообще практикую правило "каждому студенту it-специальности - по VPS на OpenVZ". Для меня - очень удобно: развертывание мгновенно, работа - 24/7, полный контроль над тем, кто чем занимается (или не занимается). Для студентов - не менее удобно, кроме, понятно, раздолбаев и дубов.P.S. кстати, мой вуз доблестное минобразование признало "неэффективным". Значит, в "эффективных" вузах каждому студенту должны как минимум физический сервер в пользование предоставлять. И зачем им тогда виртуализация?
> по VPS на OpenVZЧто вам бедные студенты сделали?
А что не так с OpenVZ?
> А что не так с OpenVZ?ну подумаешь под нагрузкой - виснут процессы... когда возникает конфликт на одном мьютексе и сработало ограничение на CPU...
>> А что не так с OpenVZ?
> ну подумаешь под нагрузкой - виснут процессы... когда возникает конфликт на одном
> мьютексе и сработало ограничение на CPU...пруф?
> пруф?А вы на его ник посмотрите. Вот вам и "пруф" его "нейтральной, непредвзятой" точки зрения. При том данный индивид почти наверняка не сможет предложить более-менее равноценной замены OpenVZ.
> При том данный индивид почти наверняка не сможет
> предложить более-менее равноценной замены OpenVZ.Джейлы. Дешего и сердито, с минимальнейшим оверхедом.
> Джейлы. Дешего и сердито, с минимальнейшим оверхедом."Тюнить конструктор-недоделку" vs "развернуть и работать" - замечательная альтернатива.
>> При том данный индивид почти наверняка не сможет
>> предложить более-менее равноценной замены OpenVZ.
> Джейлы. Дешего и сердито, с минимальнейшим оверхедом.Ага, ни одно сообщество кагбе не сподобилось написать вменяемый resource management. :))))))))))
> Джейлы. Дешего и сердито, с минимальнейшим оверхедом.У опенвзы тоже оверхед минмальный. Потому что по сути - сильно заапгрейженная версия контейнера и есть. Хотя бсдоида сразу видно - до последнего жрет кривой кактус. Ну и что что в ущерб эффективности решения задачи. Зато свое - не пахнет.
кстати, еще вариант - solaris zones
> кстати, еще вариант - solaris zonesТолько вот политика оракла и ко не сильно дружественна к таким применениям. А линь чо, его забесплатно можно воткнуть. Врядли у того гражданина найдется баблишка на продукты от оракла.
>> кстати, еще вариант - solaris zones
> Только вот политика оракла и ко не сильно дружественна к таким применениям.
> А линь чо, его забесплатно можно воткнуть. Врядли у того гражданина
> найдется баблишка на продукты от оракла.ой, вылез: слышал звон да не знаю где он.
> ой, вылез: слышал звон да не знаю где он.Так вы за это скажите спасибо своему раклу. Его политика как-то совершенно не способствует желанию знакомиться с их поделиями.
>> ой, вылез: слышал звон да не знаю где он.
> Так вы за это скажите спасибо своему раклу. Его политика как-то совершенно
> не способствует желанию знакомиться с их поделиями.
Трупики на википедии - это круто. А смысл? Оно практически околело и не развивается. Пусть на это закладываются те кому острых ощущений пониже спины хочется.
> Трупики на википедии - это круто. А смысл? Оно практически околело и
> не развивается. Пусть на это закладываются те кому острых ощущений пониже
> спины хочется.294-ый, ты странный перец и с логикой у тебя явный проблемы, по которым тебя и отличают от других анонимов:
- скажи "а"
- а
- скажи "б"
- б
- а почему ты не сказал "е"?
> 294-ый, ты странный перец и с логикой у тебя явный проблемы,Это у вас с логикой проблемы.
- Юзайте соляру!
- А чем лучше линя?
- А ничем, но мне нравится соляра!
- А мне не нравится что там на выбор или вендорлок на оракла или копание в трупах!
- Ничего не знаю, мне нравится соляра! Пользуйте соляру!
- На свою ж? Не, спасибо!
> ну подумаешь под нагрузкой - виснут процессы...Ох ты ж блин, а толпы хостеров пользуются и не в курсах. Лично видел граждан у которых аптайм в год набрался и ничего не висло почему-то. Хотя с вашим ником понятный фиг сто сведения будут из разряда ОБС.
> Хотя с вашим ником понятный фиг сто сведения будут из разряда ОБС.Оплачено Баллмером Студенту ;)
> Ох ты ж блин, а толпы хостеров пользуются и не в курсах.Хостеры может и пользуются, но клиенты, попробовав это УГ, больше на такой VPS не вернутся.
Тормозящий IO и постоянные OOM — визитная карточка OpenVZ.
> Тормозящий IO и постоянные OOM — визитная карточка OpenVZ.Вот что-что, а в опенвзе ничего не тормозит. Это контейнер, а не виртуализатор - тормозить в нем тупо нечему, т.к. это довольно тонкий слой над ядром, ничего такого принципиально не меняющий особо. Если полисовка ресурсов позволяет - оно >=95% от bare metal выжимает запросто. Оверхед минимален. А если хостер политику I/O завинтил - так оно для того и надо чтобы поделить сервант на ораву народа так чтобы каждому что-то досталось, а не так что один умник ставит раком диск(и), а остальные смотрят как у них встали колом их виртуалки.
У полных виртуализаторов (xen, kvm, или кто там что предпочитает) просадка I/O намного больше и может достигать десятков процентов.
Обычно винтят так, что никому ничего не достаётся. Ксены сотоварищи просто не позволяют такой лютый оверселлинг сделать.
> Обычно винтят так, что никому ничего не достаётся.Обычно - это наверное местные, которые и на остальных виртуализаторах такой трэш и содомию устраивают что просто диву даешься. Ну дык нормальных хостеров надо использовать. И не забывать что принцип "как заплачено, так и захреначено" никто не отменял.
OpenVZ на хостингах живёт ровно по доной причине - на нормальных виртуалках невыйдет так люто продавать одни и те же ресурсы куче клиентов. Зато дёшево. А что оно потом еле ворочается и имеет кучу весёлых ограничений (на количество процессов, например, в котороеколичество потоков входит) - это ж мелочи...Не, я верю,что есть граждане, которым везёт - ну там, сервак не нагнули оверселлингом, или стоит пустой контейнер, на котором крутится какой-нибудь нгинкс да пара потоков php-fpm, и заходят полтора человека.
Впрочем, именно для студенческих виртуалок - решение вполне приемлемое, наверняка позволяет сильно на памяти сэкономить.
> OpenVZ на хостингах живёт ровно по доной причине - на нормальных виртуалках
> невыйдет так люто продавать одни и те же ресурсы куче клиентов.На самом деле потому что у него низкий оверхед. Он не таскает отдельную копию ядра в памяти, не использует тяжелую полную виртуализацию и прочая. Поэтому на один и тот же сервак лезет больше контейнеров при прочих равных. А степень оверселлинга - на своести конкретного хостера. Гогнохостинг с жутким оверселлом бывает и на xen/kvm. Как будто есть какая-то фундаментальная разница что оверселлить. В конечном итоге ресурсов или хватает, или нет. А сколько вы получите - определяется ToS'ом. И обещанные минимальные гарантии опенвза вполне себе может обеспечить. Вот по оным и понятно за кого вас держит хостер. Да, если обещали златые горы а гарантированные ресурсы с мышь - вас держат за лоха, так и знайте. Но опенвз в этом не виноват. С ним есть и вполне приличные хостеры.
Синдром бога у таварища. Часто встречается у начинающих админов. А в вузах им раздолье.
А виртуализация это способ раздуть штат, т.к. еденица обслуживания у 1го админа это операционка. То есть если один админ может обслуживать 3-7 нагруженых серверов, то для обслуживания 100 виртуалок на 10-20 серверах (потому что эти 3-7 придется нарастить до 10-20) тут уже нужен главный админ, 2 неглавных, 4 в смену дежурных и начальник. Поэтому менеджеры ее очень любят и поэтому же от нее никуда не деться.
>>Синдром бога у таварища. Часто встречается у начинающих админов. А в вузах им раздолье.А виртуализация это способ раздуть штат, т.к. еденица обслуживания у 1го админа это операционка.Экие сказки. Вы явно не встречались с суровой замкадовской действительностью.
> Синдром бога у таварища. Часто встречается у начинающих админов.Да, им вообще свойственно найти священную корову и онанировать на неё до посинения конечностей. Виртуализация, один православный дистрибутив, одна православная лицензия, один православный почтовик, одна православная контора (Ред Хат, Каноникл, МС, не важно), одна контора, которая во всём виновата (Ред Хат, Каноникл, МС, не важно), языки программирования и всё такое.
Свойственно для начинающих, но у некоторых не проходит.> То есть если один админ может обслуживать 3-7 нагруженых серверов, то для обслуживания 100 виртуалок на 10-20 серверах (потому что эти 3-7 придется нарастить до 10-20)
Проще говоря вместо 1 операционки для n сервисов, используем n+1 операционок для n сервисов. Соответственно больше админов, больше менеджеров, больше железа, больше лицензий. В разы. Это ещё без учёта административного и ресурсного оверхеда на виртуализацию, репликацию и всё такое. А если все операционки ещё и плКороче все довольны.
А когда говоришь, что виртуализация переоценена и её не надо использовать везде подряд, начинают вопить "кто сказал, что виртуализация не нужна!!!111" и перечислять по пунктам ближайшую трендовую статью.
>[оверквотинг удален]
> Свойственно для начинающих, но у некоторых не проходит.
>> То есть если один админ может обслуживать 3-7 нагруженых серверов, то для обслуживания 100 виртуалок на 10-20 серверах (потому что эти 3-7 придется нарастить до 10-20)
> Проще говоря вместо 1 операционки для n сервисов, используем n+1 операционок для
> n сервисов. Соответственно больше админов, больше менеджеров, больше железа, больше лицензий.
> В разы. Это ещё без учёта административного и ресурсного оверхеда на
> виртуализацию, репликацию и всё такое. А если все операционки ещё и
> плКороче все довольны.
> А когда говоришь, что виртуализация переоценена и её не надо использовать везде
> подряд, начинают вопить "кто сказал, что виртуализация не нужна!!!111" и перечислять
> по пунктам ближайшую трендовую статью.критично... что-бы увеличить отношение кол-ва инсталяций/админ, нужно: остановиться на одной ОС, что вы, почему-то, осуждаете; неданагружать сервера, что бы был запас как минимум в 25%; следить постоянно за мониторингом и оперативно реагировать на проблемы; должно быть централизованное обновление системы и софта; строго отведенный коридор времени работы с железом; админ должен иметь управляемые розетки и ip-kvm, что бы минимизировать общение с железом и пр.
так, у нас получается примерно 30 железных серверов на брата, и если считать вирталки, то что-то около 65. кроме того, я не считаю различные свитчи, квм, управляемые розетки, которые иногда так же ломаются...
Вот не первый раз читаю каменты в этом треде и такое ощущение, что у вас виртуалки в эфире плавают, а не на серверах установлены. Типа заменили сервера на виртуалки, а сервера выкинули за ненадобностью =), или оставили 2 штуки, чтобы мигрировать с одного на другой. =)
> Вот не первый раз читаю каменты в этом треде и такое ощущение,
> что у вас виртуалки в эфире плавают, а не на серверах
> установлены. Типа заменили сервера на виртуалки, а сервера выкинули за ненадобностью
> =), или оставили 2 штуки, чтобы мигрировать с одного на другой.
> =)ну коль тут отделяют железки от виртуалок, то и я отделил для наглядности, а так мы считаем только железки, большой разницы нет сколько виртуалок. но нет и пихать виртуалки на все сервера подряд.
Администрирование с ней удешевляется не только за счёт меньшего количества железа. Хотя бы потому,что взаимные влияния разных сервисом минимизированы, соответственно, думать для каждой виртуалки приходится только о чём-то одном. В результате - более простые политики - хоть бэкапа, хоть обновлений, хоть чего.
>>А когда говоришь, что виртуализация переоценена и её не надо использовать везде подряд, начинают вопить "кто сказал, что виртуализация не нужна!!!111" и перечислять по пунктам ближайшую трендовую статью.На сегодня в моей зоне ответственности 99 виртуалок на openvz, 2 на kvm, 1 на hyperv, плюс 4 физических ноды, на которых все это хозяйство вертится. Были физические отвалы серверов и устройств, смены дистрибутивов, хаки отдельных виртуалок. Да у меня виртуалка с интернет-шлюзом уже лет шесть живет и побывала на трех физических серверах. И шаблоны виртуалок наштампованы, от нулевого сервера с единственным ssh, до всяких веб-порталов с БД и медиасерверов, которые за 10 минут развертываешь и встраиваешь в инфраструктуру. И на исправление проблем у меня уходит раз в десять меньше времени, чем в "старые добрые времена".
Поэтому любой "эффективный менеджер", с апломбом заявляющий "что виртуализация переоценена", будет послан лесом, если попытается применить свои фантазии к моей работе.
По моим наблюдениям орут о том что виртуализация "не нyжна" в основном клоуны которые ей ни разу не пользовались.
> По моим наблюдениям орут о том что виртуализация "не нyжна" в основном
> клоуны которые ей ни разу не пользовались.по моим наблюдениям везде пихают виртуалки только школьники с промытыми мозгами.
>[оверквотинг удален]
> kvm, 1 на hyperv, плюс 4 физических ноды, на которых все
> это хозяйство вертится. Были физические отвалы серверов и устройств, смены дистрибутивов,
> хаки отдельных виртуалок. Да у меня виртуалка с интернет-шлюзом уже лет
> шесть живет и побывала на трех физических серверах. И шаблоны виртуалок
> наштампованы, от нулевого сервера с единственным ssh, до всяких
> веб-порталов с БД и медиасерверов, которые за 10 минут развертываешь и
> встраиваешь в инфраструктуру. И на исправление проблем у меня уходит раз
> в десять меньше времени, чем в "старые добрые времена".
> Поэтому любой "эффективный менеджер", с апломбом заявляющий "что виртуализация переоценена",
> будет послан лесом, если попытается применить свои фантазии к моей работе.Ага, именно тот пример священной коровы. Критерием успеха считаем количество виртуалок, а не полезную нагрузку и функции, которые они выполняют.
Вот ничего не имею против контейнеров, как и виртуалок, но виртуализация головного мозга ― это болезнь.
> А виртуализация это способ раздуть штат,Или сократить, т.к. меньше эникеев потребуется для беготни между серверами.
> т.к. еденица обслуживания у 1го админа
School ^^^^^ analytic FAIL. За русский у вас точно должна стоять едИница. В аттестате.
>> А виртуализация это способ раздуть штат,
> Или сократить, т.к. меньше эникеев потребуется для беготни между серверами.1. Серверов будет больше в большинстве случаев.
2. Эникеям между ними бегать не нужно, кроме внештатных ситуаций, которых тоже будет больше, так как усложняется система.
> 2. Эникеям между ними бегать не нужно, кроме внештатных ситуаций, которых тоже
> будет больше, так как усложняется система.Не согласен. Виртуализация очень часто используется для реализации принципа "1 сервер - 1 задача", что упрощает, а не усложняет систему.
>> 2. Эникеям между ними бегать не нужно, кроме внештатных ситуаций, которых тоже
>> будет больше, так как усложняется система.
> Не согласен. Виртуализация очень часто используется для реализации принципа "1 сервер -
> 1 задача", что упрощает, а не усложняет систему.Усложняется конструкция, потому что добавляются прослойки, весьма навороченные и чреватые граблями. Кое-что конечно проще с виртуалками. Никто же не говорит на самом деле, что они не нужны. Кому-то, мне например, нужны, но не везде.
> Усложняется конструкция,Частично есть такой момент. Но зато есть расщепление на ресурсы и задачи. При том в случае виртуалок - VM это такая логичеки завершенная задача. С всей конфигурацией и всем что там ей было надо для работы. Очень удобный в кантовке юнит.
Почему бы и нет, вопрос в цене.
Что вообще Вам даёт принцип "1 сервер - 1 задача"? И чем простой chroot хуже OpenVZ? Ведь сервера, хоть и виртуальные требуют периодического отдельного администрирования, что усложняет, а не упрощает задачу.
Даёт минимизацию связей между различными задачами. Грубо говоря, есть у меня два сервиса. Одному предпочтительны такие натсройки ядра, другому - эдакие. Один можно в случае чего снести и поднять со снапшота, потому что он работает с удалённой базой, у другого нужнырегулрные бэкапыкаких-то частей ФС. Понятно, что ибез пиртуализации всё этом ожно решить обычно, но с ней - куда проще, потому что вместо сложных индивидуальных комбинаций вы получаете простые стандартные решения.А администрирование в той части,в которой виртуалки одинаковы, никак не усложняется, на то паппеты и есть.
> Что вообще Вам даёт принцип "1 сервер - 1 задача"?1) Достаточно хорошую изоляцию между задачами. Так что факап на форуме от хакера Васи не поставит под удар DNS, почтовик или dhcp сервер. Даже если Вася заапгрейдит права до рута.
2) Индивидуальную конфигурацию ОС и окружения.
3) Удобство администрирования. Каждая сущность сама по себе - проста и предсказуема.> И чем простой chroot хуже OpenVZ?
Тем что чрут не создан для секурити. И для полисовки ресурсов. В openvz контейнер - по сути копия юзермода той или иной системы. С своей конфигурацией. И своим рутовым пользователем (который на хосте никто) и прочая. Админится как нормальная отдельная копия операционки. Без костылей и подпорок. Если надо - ресурсы полисуются. Так что васе столько, а пете столько. Так что вася и петя не особо мешают друг другу.
> Ведь сервера, хоть и виртуальные требуют периодического
> отдельного администрирования, что усложняет, а не упрощает задачу.Админить несколько простых сущностей проще чем меньше, но супернавороченных и суперзасранных.
>> Что вообще Вам даёт принцип "1 сервер - 1 задача"?
> 1) Достаточно хорошую изоляцию между задачами. Так что факап на форуме от
> хакера Васи не поставит под удар DNS, почтовик или dhcp сервер.
> Даже если Вася заапгрейдит права до рута.т.е. поимев у вас виртуалку вы считаете, что Вася-хакер не поимел хост-систему - с вами все ясно, проходите мимо.
> - с вами все ясно, проходите мимо.У-тю-тю, сколько апломба. Уговорили, пройду мимо таких снобов. Можете пихать все на 1 сервак и насдаждаться тем что хакерье при минимальном факапе унесло вообще все, или городить кучи отдельных железных серверов, если баблишко и неленивость админов все это позволяет. А какие еще варианты есть, по большому счету?
> т.е. поимев у вас виртуалку вы считаете, что Вася-хакер не поимел хост-систему
> - с вами все ясно, проходите мимо.Если Вася поимел DNS-сервер в виртуалке - КАК он поимел хост-систему? Бугага?
>> т.е. поимев у вас виртуалку вы считаете, что Вася-хакер не поимел хост-систему
>> - с вами все ясно, проходите мимо.
> Если Вася поимел DNS-сервер в виртуалке - КАК он поимел хост-систему? Бугага?самоуверенность - первый порок безопасника.
https://www.opennet.ru/opennews/art.shtml?num=34771
https://www.opennet.ru/opennews/art.shtml?num=35493
еще поискать или сами справитесь?
> еще поискатьДа, чего-нибудь реально эксплуатабельного, для KVM пожалуйста.
>> еще поискать
> Да, чего-нибудь реально эксплуатабельного, для KVM пожалуйста.ДНС имеют не с целью поиметь хост. Плюс доступ в локалку уже у Васи есть.
Аналогично Вася поимел ДНС сервер в чруте под ограниченным юзером без шела и других няшек, на отдельном хосте в DMZ, что дальше? Аналогично приветствуется реально эксплуатабельное.
> Что вообще Вам даёт принцип "1 сервер - 1 задача"?Пример: ломанули DNS-сервер ремотно. Получили рута. В случае "1 сервер - много задач" они получают доступ ко всем данным всех задач. В случае "1 сервер - 1 задача" хрен они куда с подводной лодки денутся.
>> Что вообще Вам даёт принцип "1 сервер - 1 задача"?
> Пример: ломанули DNS-сервер ремотно. Получили рута.Вышли за приделы контейнера и имеют все задачи подряд...
Вопрос такой: сломали у меня сервер, я поколупался в причинах, нашел - не нашел, переставил его и запустил по новой. У вас сломали одну виртуалку, что делаете вы: чихаете, переставляете только ее или еще десяток и базовую сисему?
> Вышли за приделы контейнера и имеют все задачи подряд...Это как? Выйти за пределы контейнера достаточно сложно даже в контейнерных виртуалках, не говоря уже о полных. Дыры бывают везде, конечно, но шанс настолько мал, что достаточно проанализировать логи виртуализатора - были попытки что-то с площадкой сделать или нет.
> Вопрос такой: сломали у меня сервер, я поколупался в причинах, нашел -
> не нашел, переставил его и запустил по новой. У вас сломали
> одну виртуалку, что делаете выАнализирую логи виртуалки и собственно базовой площадки. Если вторжения на базовую площадку не фиксируется - значит определяю вектор атаки, закрываю аналогичные (не точно те же самые, а именно аналогичные по вектору атаки) дыры на остатке платформ, и переустанавливаю одну виртуалку с закрытой дырой.
>> Вышли за приделы контейнера и имеют все задачи подряд...
> Это как?как-то так:
https://www.opennet.ru/opennews/art.shtml?num=34771
https://www.opennet.ru/opennews/art.shtml?num=35493> Выйти за пределы контейнера достаточно сложно даже в контейнерных виртуалках,
> не говоря уже о полных. Дыры бывают везде, конечно, но шанс
> настолько мал, что достаточно проанализировать логи виртуализатора - были попытки что-то
> с площадкой сделать или нет.логи виртуализатора вам дают 100% гарантию, что хост-система не сломана?
> Анализирую логи виртуалки и собственно базовой площадки. Если вторжения на базовую площадку
> не фиксируется - значит определяю вектор атаки, закрываю аналогичные (не точно
> те же самые, а именно аналогичные по вектору атаки) дыры на
> остатке платформ, и переустанавливаю одну виртуалку с закрытой дырой.как вы зафиксируете вторжение на хост-систему, по логам? а если они подконтрольны злоумышленнику?
> как-то так:
> https://www.opennet.ru/opennews/art.shtml?num=34771
> https://www.opennet.ru/opennews/art.shtml?num=35493Покажите для ESXi и OpenVZ. Xen не рассматривался в принципе, поскольку IMNSHO быдляцкая какая-то поделка. Тот же KVM интереснее.
>> как-то так:
>> https://www.opennet.ru/opennews/art.shtml?num=34771
>> https://www.opennet.ru/opennews/art.shtml?num=35493
> Покажите для ESXi и OpenVZ. Xen не рассматривался в принципе, поскольку IMNSHO
> быдляцкая какая-то поделка. Тот же KVM интереснее.Если уязвимость не была найдена в самом контейнере, то это не значит, что нельзя выйти за приделы контейнера: https://www.opennet.ru/opennews/art.shtml?num=32703
> что нельзя выйти за приделы контейнера:В ряде случаев - можно, но планка поднимается достаточно существенно. Всякая автоматика завязнет вообще, по крайней мере пока ее не доработают. Да и потом придется дорабатывать по мере фикса багов. Это создает лишние препятствия. Чем больше препятствий - тем меньше взломщиков доползет до финиша.
>> что нельзя выйти за приделы контейнера:
> В ряде случаев - можно, но планка поднимается достаточно существенно. Всякая автоматика
> завязнет вообще, по крайней мере пока ее не доработают. Да и
> потом придется дорабатывать по мере фикса багов. Это создает лишние препятствия.
> Чем больше препятствий - тем меньше взломщиков доползет до финиша.Само собой, но закрывать глаза на это не стоит. Не нужно думать как блондинки: да кому я нужен, кто меня ломать будет...
> Само собой, но закрывать глаза на это не стоит. Не нужно думать
> как блондинки: да кому я нужен, кто меня ломать будет...Логично, но чем больше препятствий тем вероятнее что автоматическая атака обломается, а при ручной хакер наследит, вызовет алерт мониторинга и прочая. Ну, снять с ним снапшот в виртуалке для разбора полетов да и выключить ее нафиг. А после разбора полетов - можно вернуть к заведомо чистому снапшоту. Опять же - подход "1 сервис на VM" упростит мониторинг и анализ активности VM и понимание того насколько оно легитимно.
> Само собой, но закрывать глаза на это не стоит. Не нужно думать
> как блондинки: да кому я нужен, кто меня ломать будет...Дадада. Лучше заранее выключите питание, потому что абсолютно безопасных систем не бывает. А чтобы не включили и не слили вашу инфу при физическом доступе - дополнительно положите несколько кг взрывчатки в сервер и активируйте. Потому что абсолютно безопасной защиты от физического доступа тоже не бывает.
>> Само собой, но закрывать глаза на это не стоит. Не нужно думать
>> как блондинки: да кому я нужен, кто меня ломать будет...
> Дадада. Лучше заранее выключите питание, потому что абсолютно безопасных систем не бывает.
> А чтобы не включили и не слили вашу инфу при физическом
> доступе - дополнительно положите несколько кг взрывчатки в сервер и активируйте.
> Потому что абсолютно безопасной защиты от физического доступа тоже не бывает.по-этому вы живете скрестя пальцы в надежде что вас пронесет?
> по-этому вы живете скрестя пальцы в надежде что вас пронесет?Да нет, я предпочитаю баланс и удобство.
> Если уязвимость не была найдена в самом контейнере, то это не значит,
> что нельзя выйти за приделы контейнера: https://www.opennet.ru/opennews/art.shtml?num=32703Мойте руки перед едой и не пускайте идиотов в системы. Эта "дыра" требует проброса разделов в гостевые окружения, небезопасного by design, и пойдёт на оное только круглый идиот.
>> Если уязвимость не была найдена в самом контейнере, то это не значит,
>> что нельзя выйти за приделы контейнера: https://www.opennet.ru/opennews/art.shtml?num=32703
> Мойте руки перед едой и не пускайте идиотов в системы. Эта "дыра"
> требует проброса разделов в гостевые окружения, небезопасного by design, и пойдёт
> на оное только круглый идиот.тадам. вашей виртуалке не хватает производительности nas-а, что вы будете делать с виртуалкой?
> тадам. вашей виртуалке не хватает производительности nas-а, что вы будете делать с
> виртуалкой?Вообще-то производительность надо планировать головой, а не тем местом, которым над унитазом трясете :)
>> тадам. вашей виртуалке не хватает производительности nas-а, что вы будете делать с
>> виртуалкой?
> Вообще-то производительность надо планировать головой, а не тем местом, которым над унитазом
> трясете :)Ну сути это не меняет, вот выросли потребности и чего? А при стремлении леммингов все запихать в виртуалку - это тем более интересно.
> Ну сути это не меняет, вот выросли потребности и чего?А того, что надо производительность NAS увеличивать, а не пробрасывать железо в окружения.
>> Ну сути это не меняет, вот выросли потребности и чего?
> А того, что надо производительность NAS увеличивать, а не пробрасывать железо в
> окружения.ни разу не попадались задачи, которым время отклика nas-а мало?
> ни разу не попадались задачи, которым время отклика nas-а мало?А кеширование на SSD давно отменили? В конце концов, можно юзать DAS между несколькими серверами.
> В случае "1 сервер - много задач" они получают доступ ко всем данным всех задач. В случае
> "1 сервер - 1 задача" хрен они куда с подводной лодки денутся.До тех пор, пока не "ломанут" систему дальше...
> До тех пор, пока не "ломанут" систему дальше...Ну если так рассуждать, а еще завтра на датацентр может метеорит упасть. Давайте выключим по этому поводу все сервера заранее, чтоли?
>> До тех пор, пока не "ломанут" систему дальше...
> Ну если так рассуждать, а еще завтра на датацентр может метеорит упасть.
> Давайте выключим по этому поводу все сервера заранее, чтоли?статистику падения метеоритов на ДЦ и выход за приделы виртуалки вы осилите найти сами?
> статистику падения метеоритов на ДЦ и выход за приделы виртуалки вы осилите найти сами?Врядли - не самая простая в поиске информация. Можете доказать обратное. Ну например статистика по взломам с выходом из KVM у вас есть? А для xen? Было бы интересно сравнить но вот так сходу я такого не нашел.
>> статистику падения метеоритов на ДЦ и выход за приделы виртуалки вы осилите найти сами?
> Врядли - не самая простая в поиске информация. Можете доказать обратное. Ну
> например статистика по взломам с выходом из KVM у вас есть?
> А для xen? Было бы интересно сравнить но вот так сходу
> я такого не нашел.тут даже конкретной статистики не нужно, достаточно вероятностей.
вот одна из вероятностей: http://lenta.ru/news/2009/06/10/lxlabs/
и то что вы чего-то не нашли, это не значит, что этого нет. зачастую уязвимостями пользуются по несколько лет, прежде чем о них становится известно общественности.
>> До тех пор, пока не "ломанут" систему дальше...
> Ну если так рассуждать, а еще завтра на датацентр может метеорит упасть.Про метеориты, упавшие на ДЦ - я не слыхал. А дырки в системах виртуализации уже обнаруживали не раз.
> До тех пор, пока не "ломанут" систему дальше...При условии, что _аналогичных_ дыр нет - это достаточно долгий и нудный процесс, даже при попадании во внутреннюю сеть - как минимум нужно брутфорсить пароли или снифать трафик (а это вряд ли возможно, опять же при условии "1 задача"). Спуфить через взломанную допустим DNS'ку - сильно заметно. Т.е. до "дальше" вторжение скорее всего будет обнаружено.
> 1. Серверов будет больше в большинстве случаев.В случае виртуализации - меньше. Ибо некоторые вещи по соображениям стабильности и безопасности должны жить на изолированных друг от друга окружениях. А вот ставить для изоляции оных отдельные физические серваки - дорого. И не факт что они жрут много ресурсов. Ну вон AlexAT пример привел. Как сделать из 6 серваков нечто типа 2. При том как я понимаю - в его случае отвал 1 сервака не будет фатален, т.к. "всего по 2".
Здравый смысл подсказывает что если на 1 сервере живет несколько виртуалок (если это не так то нафига там виртуализация?) - физических хостов стало меньше. Т.к. виртуальная машина - то же самое что и физическая, только окончательно абстрагированная от железа и делящая ресурсы с кем-то еще. Сам подход "несколько VM на 1 хосте" подразумевает что число хостов меньше чем число VMов. Т.е. сокращение парка серверов налицо.
> 2. Эникеям между ними бегать не нужно, кроме внештатных ситуаций, которых тоже
> будет больше, так как усложняется система.Как бы манипуляции с виртуалками в общем случае проще и быстрее чем манипуляции с железками.
>> 1. Серверов будет больше в большинстве случаев.
> В случае виртуализации - меньше. Ибо некоторые вещи по соображениям стабильности и
> безопасности должны жить на изолированных друг от друга окружениях.Этих вещей не так и много, 1-2, ну пусть будет 5 на сеть из десятков серверов. Ну да их можно в виртуалки засунуть. Но не всегда, некоторым вещам виртуалки противопоказаны по соображениям производительности и рилтаймности. Для этого в основном виртуалки и использую, для софта который друг с другом не дружит, а целого сервера 24/7 для них жалко.
И да, "по соображениям безопасности" не совсем верно, или даже совсем не верно, в зависимости от ситуации. Если поимеют машину с виртуалками, будет ататат, fail badly.>Как сделать из 6 серваков нечто типа 2.
Без виртуализации я из 10 сделал 2. И? С контейнерами можно из сотен сделать 2.
>> 2. Эникеям между ними бегать не нужно, кроме внештатных ситуаций, которых тоже
>> будет больше, так как усложняется система.
> Как бы манипуляции с виртуалками в общем случае проще и быстрее чем
> манипуляции с железками.Как бы железки никуда не деваются. Если рейд-контроллер издох, или мышка перегрызла оптику, работа эникея по их замене одинакова и на нём не сэкономишь, внезапно. Работа админа конечно будет отличаться. По наличию забавной выборочной логики вангую, что общаюсь с 294. =)
Хм, обычно наоборот - большинство отдельных машин будут недогружены. А уж если хочется иметь стандартный парк (а хочется, конечно - обслуживать проще) - то тем более. Ну и насчёт реалтаймовости не знаю - а в случае производительности - те копейки,что теряются но толковой вируталке, вполне окупаются удобством администрирования - от тех самых миграций до гарантированной возможности что-то сделать с виртуалкой из более удобной среды, чем IP-KVM.Контейнер - это не та степень изоляции. К примеру, разные настройки ядра уже не сделаешь.
Железок становится меньше - меньше аппаратных проблем.
> те копейки,что теряются но толковой вируталке, вполне окупаются удобством администрированияКопейки это сколько и как считать? Репликация дисков и сетевой оверхед (читал, что до 80%) учитывался? А производительность в сразу нескольких нагруженных виртуалках, как там с переключениями контекстов?
А добиться одновременно и сравнимой с хостовым железом производительности и скажем так QoS удалось? Имеется в виду если жестко квотировать CPU и память, max performance будет не больше n% от хоста. Если не квотировать, то одна VM может захватить все ресурсы. С процессами на одной операционке это достаточно гибко управляется скедулерами и найсами.> Железок становится меньше - меньше аппаратных проблем.
Железок только больше и требования к ним жёстче, кроме вышеобсуждённых частных случаев.
> Контейнер - это не та степень изоляции. К примеру, разные настройки ядра
> уже не сделаешь.давай ты перечислишь разные ядра (типы, задачи) которые используются у тебя? а я перечислю тебе свои:
1. универсальное, где включено практически все, что может потребоваться, при этом не выключена подгрузка модулей. применение на 90% серверов наших и клиентских.
2. виртуализатор.
3. балансеры.
4. спецефичное ядро, с нашими патчами, для кластера.причем 1 и 3 объединить - не сложно, но структура сборки и распространения ядер сложилась давно, все работает и времени не просит, по-этому так вот и висит.
при всем при этом, спецефичные задачи, которые решаются ядрами 2,3,4, не разместишь в ВМ.
> при всем при этом, спецефичные задачи, которые решаются ядрами 2,3,4, не разместишь в ВМ.Не знаю насчет 4, а вот...
- Пункт 1 хостеры делают на промышленной основе. Если вы так не можете - кому хуже то?
- Пункт 2 вообще-то может быть и на виртуализаторе, ибо nested virtualization еще не отменяли. Насколько оно оптимально - другой вопрос. Но чисто технически это можно.
- Пункт 3 - опять же не понятно что помещает этому крутиться на виртуализаторе при условии что укладывается по производительности. Вы делали замеры на виртуализаторах и они показали что в желаемую производительность не укладывается? Или чего?
> Этих вещей не так и много,Сабж тем не менее доступно говорит о том что достаточно.
> Но не всегда, некоторым вещам виртуалки противопоказаны по соображениям
> производительности и рилтаймности.Бывает и такое, спору нет.
> И да, "по соображениям безопасности" не совсем верно, или даже совсем не
> верно, в зависимости от ситуации. Если поимеют машину с виртуалками, будет ататат, fail badly.Будет, однако ататат уже давно случается когда на машине с кучей сервисов проламывают сервис - страдает куча всего. Ибо ставить на все и вся по отдельному серванту - бабла не напасешься, даже если забыть что сервера жрут, топят воздух, занимают место и прочая. Виртуалки при прочих равных повышают уровень изоляции. Т.е. в дополнение к поимению сервиса и тамошней ОС придется прошибать еще и виртуализатор. Что заметно поднимает планку и повышает шанс что взлом будет обнаружен до того как ататат.
> Без виртуализации я из 10 сделал 2. И? С контейнерами можно из сотен сделать 2.
Контейнеры в полной реализации (т.е. администреж оного как отдельной копии ос) - по сути некая лайт форма виртуализации, выделяемая в отдельный подвид.
>> Как бы манипуляции с виртуалками в общем случае проще и быстрее чем
>> манипуляции с железками.
> Как бы железки никуда не деваются. Если рейд-контроллер издох, или мышка перегрызла
> оптику, работа эникея по их замене одинакова и на нём не
> сэкономишь, внезапно.Не сэкономишь. Но теорвер говорит нам что если у вас 20 серверов то факапы будут чаще чем в случае если их допустим, 4. Допустим, сервак отказывает за год работы с вероятностью 10%. Тогда для 4 серваков вероятность закончить год без происшествий 0.9^4 ~= 0,66, а для 20 уже 0.9^20 ~= 0.122. В среднем стало быть во втором случае эникей будет бегать чинить сервера в 5 раз чаще чем "4 сервака по 5 виртуалок на каждом".
> Работа админа конечно будет отличаться. По наличию забавной выборочной
> логики вангую, что общаюсь с 294. =)Логика самая обычная, элементарное знание теорвера. Гласящее что чем меньше оборудования тем оно меньше ломается. А эн виртуалок на сервер должно бы навести на мысль что кто-то почти в эн раз сократил парк серверов.
Как то вы странно применяете теорию вероятностей. Или ПО которого тонны, у вас идеально? Проблемы с железом они конечно бываю фатальны. Но время простоя в основном это проблемы с ПО, и если брать ваши же расчеты, виртуализация круто сольет на ответственных задачах.
> Не сэкономишь. Но теорвер говорит нам что если у вас 20 серверов то факапы будут чаще чем в случае если их допустим, 4. Допустим, сервак отказывает за год работы с вероятностью 10%. Тогда для 4 серваков вероятность закончить год без происшествий 0.9^4 ~= 0,66, а для 20 уже 0.9^20 ~= 0.122. В среднем стало быть во втором случае эникей будет бегать чинить сервера в 5 раз чаще чем "4 сервака по 5 виртуалок на каждом".Теорвер это замечательно, но закон сохранения энергии пока он не отменяет. Задачи, для которых требуется производительность 20-ти железных серверов не может быть решена меньшим количеством серверов с виртуалками.
А то у тебя получается как у жабистов, у которых байткод в их JVM быстрее нативного в 5 раз.Ну и выше замечено насчёт ПО. Походив по граблям в различных виртуальных инфраструктурах, трудно не заметить, что случаются они не реже железячных отказов.
> Задачи, для которых требуется производительность 20-ти железных серверовЛогично. Но бывает так что 20 серверов стоят по соображениям изоляции и администрирования. Тем паче что современные сервера столь мощны что полностью их загрузить могут далеко не в любой конторе.
>> Задачи, для которых требуется производительность 20-ти железных серверов
> Логично. Но бывает так что 20 серверов стоят по соображениям изоляции и
> администрирования. Тем паче что современные сервера столь мощны что полностью их
> загрузить могут далеко не в любой конторе.по соображениям администрирования? это как?
> по соображениям администрирования? это как?Ну вот так. Админить систему с простысм устройством и 1 сервис в ней удобнее и проще чем переростка где в одной системе 20 разных сервисов заколупано. С железными серверами так выходит довольно дорого. С виртуалками - без проблем.
>> по соображениям администрирования? это как?
> Ну вот так. Админить систему с простысм устройством и 1 сервис в
> ней удобнее и проще чем переростка где в одной системе 20
> разных сервисов заколупано.Опять 25. Та же логика, только теперь 20 к 1.
Правильно: админить 20 систем с 1 сервисом в каждой и 1 систему(хост) с очень непростым управлением и распределением ресурсов VS админить 1 систему с 20 сервисами.Как ни крути, дешевле не получается. Ибо с какого перепугу должна быть выгода от запуска избыточных операционок? (закон сохранения опять)
>> по VPS на OpenVZ
> Что вам бедные студенты сделали?Выпускники не жалуются. Плачут только отчисленные.
[black humor on]Просто некому жаловаться?
[black humor off]
> [black humor on]
> Просто некому жаловаться?
> [black humor off]51%
На самом деле 100%, просто никто не терморектально криптоанализировал прошивки всевозможных китайских BMC и прочих обвесов, сидящих на шине с прямым доступом к CPU.
> китайских BMCBMC к виртуализации не относится сам по себе.
>> китайских BMC
> BMC к виртуализации не относится сам по себе.Тю? А к чему он относится? К тому, к чему подключен, не?
> Тю? А к чему он относится? К тому, к чему подключен, не?Тютю. Каким местом BMC относится к именно виртуализации? Что он, собственно, виртуализует? :)
- BHyVe
- jail
- virtualbox
- Virtio, уже используем 10.0
- xen к 10-11тке обещают в Dom0 допилить
Математик смотрит на пожарный кран: "о, решени есть!". И отправляется спать дальше.
Кто сказал, что возможность быстрой миграции - это однозначный плюс? Среди рисков информационной безопасности "потеря информации" и "кража информации" стоЯт как минимум на одной ступеньке, а иногда не допустить кражу ещё важнее.
С виртуалками это на порядок сложнее, надеюсь все это понимают? Точнее, как минимум 51% не понимает.Про хостинг в виртуалке я вообще молчу. Сегодня он ваш, завтра не ваш. Кроме сайта-визитки в виртуальных окружениях провайдера что-то размещать - это маразм.
> Про хостинг в виртуалке я вообще молчу. Сегодня он ваш, завтра не ваш.Какая разница, отожмут у вас сервер в ДЦ или виртуалку? В случае сервера вы еще и дорогущим железом рискуете а наихучших раскладах.