Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 95
Технологии intel и amd слегка различаются, amd предлагает возможность программировать контроллер памяти (на процессоре) для снижения вычислительной нагрузки на виртуализацию (nested pages), интел (насколько я знаю) все вычисления перекладывает на ПО.
У Intel это называется EPT.
Существуют следующие методы управления памятью
Забыли упомянуть SWAP на уровне гипервизора.
В настоящий момент разработана довольно интересная система — open vSwitch
У VMware начиная с vSphere 4 есть Distributed vSwitches, позволяющие, помимо всего прочего, разграничивать полосу пропускания для отдельных типов трафика (ВМ, управляющий, iSCSI).
У VMWare анонсирована замечательная возможность контролировать количество операций ввода-вывода, обеспечивая малую задержку в обслуживании всех гостей, притормаживая самых жрущих из них.
У VMware это уже есть в vSphere 4.1.
Идут работы по стандартизации взаимодействия между гипервизорами. Например, предложен XVA формат, как независимый от платформы формат для экспорта/импорта виртуальных машин.
.ovf вполне платформонезависим. :)
Некоторые предоставляют возможность точного аккаунтинга потреблённых ресурсов в виде абсолютного числа тиков, иопов, мегабайт, сетевых пакетов и т.д.
В Hyper-V есть Performance Monitor, который предоставляет необходимую информацию. В VMware аналогично + некоторые консольные утилиты.
swap на уровне гипервизора? Это openvz, ещё кто-то?
Open flow это несколько иная штука, это возможность железному коммутатору использовать софтовый контроллер. Я статью в вики переводил: ru.wikipedia.org/wiki/Openflow.
Hyper-V'шный perfmon позволяет видеть абсолютные цифры? Последний раз, когда я его видел, речь шла про показатели загрузки, но не про суммарное потребление.
Open flow это несколько иная штука, это возможность железному коммутатору использовать софтовый контроллер. Я статью в вики переводил: ru.wikipedia.org/wiki/Openflow.
Hyper-V'шный perfmon позволяет видеть абсолютные цифры? Последний раз, когда я его видел, речь шла про показатели загрузки, но не про суммарное потребление.
насчёт EPT поправил.
Подскажите, а как в VMware можно посмотреть статистику сетевого трафика и потребления процессора?
В VMware <что>? VMware делает очень много продуктов.
Давайте начнём с VMware Server 2.0.
Если там нет — то в каких продуктах есть? Я как-то на сайте vmware.com не смог разобраться с этим. :-(
Если там нет — то в каких продуктах есть? Я как-то на сайте vmware.com не смог разобраться с этим. :-(
Там с этим вообще тяжело, если я правильно помню.
В vSphere с этим все просто, есть встроенные счетчики всего. + сторонние утилиты, которые все собирают, агрегируют дают подробные отчеты. Вплоть до того, сколько IOPS генерит конкретная виртуалка на конкретный датастор, который к тому же может быть размазан.
В vSphere с этим все просто, есть встроенные счетчики всего. + сторонние утилиты, которые все собирают, агрегируют дают подробные отчеты. Вплоть до того, сколько IOPS генерит конкретная виртуалка на конкретный датастор, который к тому же может быть размазан.
Давайте так, можете ли вы сказать, сколько вот указанная машина съела машинного времени (за время, хотя бы с начала загрузки, или с момента создания). То же касается иопсов (не генерирует, а сумму).
Я потратил примерно месяц на Xen'е, пока расковырял где это можно читать (два шага до hypercall'ов, статистка же по ядрам — только если вызовы ручками править). XCP, например, штатно показывает циферки только текущего потребления…
Я потратил примерно месяц на Xen'е, пока расковырял где это можно читать (два шага до hypercall'ов, статистка же по ядрам — только если вызовы ручками править). XCP, например, штатно показывает циферки только текущего потребления…
В стандартном комплекте таких инструментов агрегирования и анализа нет. Есть показатели загрузки, которые пишутся в базу каждые 20 секунд и хранятся там некоторое время.
При этом можно повеситься на vCenter и снимать интересующую статистику самостоятельно, после чего ее агрегировать для расчета «потребленных ресурсов».
Есть собственный продукт VMware для биллинга — vCenter ChargeBack, и еще пачка 3rd party продуктов.
При этом можно повеситься на vCenter и снимать интересующую статистику самостоятельно, после чего ее агрегировать для расчета «потребленных ресурсов».
Есть собственный продукт VMware для биллинга — vCenter ChargeBack, и еще пачка 3rd party продуктов.
т.е. в потрохах гипервизора оно где-то считается. Ясно.
Разумеется считается :)
Вы зря смайлик ставите. Xen, например, вообще ничего про дисковые и сетевые операции не знает, и считаются они (иопы/пакеты) в dom0 backend'е.
Ну это из-за различия в архитектуре гипервизоров. Был бы у ESX Parent Partition/dom0, было бы по другому.
Кстати, у VMWare гипервизор занимается сетью\дисками? Я её продукты видел много меньше, чем зен (с которым я по 18 часов в сутки вожусь), и мне как-то странно слышать, что гипервизор занимается такими низменными вопросами…
У ESX/ESXi монолитная архитектура (в отличии от Xen, Hyper-V), там просто больше некому, кроме гипервизора этим заниматься.
Странно. Я от людей, которые юзают ESX, слышал, что там внутри куцый линукс. (возможно, я что-то перепутал).
Он не внутри, а чуть сверху.
Ну, примерно как dom0 в XCP. Куцый, сирый, заставляющий мечтать о нормальном aptitud'е…
Впрочем, обратно к теме. в этот «чуть-чуть сверху» обслуживание устройств для виртуалок не вынесено?
Впрочем, обратно к теме. в этот «чуть-чуть сверху» обслуживание устройств для виртуалок не вынесено?
Нет, все устройства обслуживаются напрямую гипервизором. Смерть Service Console (куцего линукса) не влияет на включенные виртуальные машины. Мигрировать их уже не удастся, но можно будет дождаться off-hours, выключить корректно и перезапустить на живом ESX.
Считать за преимущество мы это можем только если предположим, что в коде, обслуживающим диски и сеть нет ошибок. В этом случае смерть гипервизора будет не менее приятной, чем падение ядра в dom0 у зена.
Кстати, в зене сейчас новая идея носится в умах — разделить обслуживание каждого устройства (класса устройств) по доменам. Упал домен с сетью? Зато диски работают, домен с сетью перезапустился и всё хорошо. Упал домен с дисками? Хуже. Но сеть хотя бы есть. Упал dom0? Перезапустился, но машины работают…
Но это пока прожекты.
Кстати, в зене сейчас новая идея носится в умах — разделить обслуживание каждого устройства (класса устройств) по доменам. Упал домен с сетью? Зато диски работают, домен с сетью перезапустился и всё хорошо. Упал домен с дисками? Хуже. Но сеть хотя бы есть. Упал dom0? Перезапустился, но машины работают…
Но это пока прожекты.
А вот в Hyper-V вынесено, кстати.
Мне кажется, они вняли объяснениям зеновцев, что чем меньше в гипервизоре кода, тем меньше ему падать.
Ну хорошо, гипервизор остался работать. Упал родительский раздел — драйверы-то все используются 3rd party, обычные драйверы для 2008 винды. И все, ни сети, ни дисков. На кой ляд такая система нужна?
ESX поддерживает меньшее количество железа, хотя строго говоря, практически любой сервер крупных вендоров полностью поддерживается, но драйверы оттестированы во все дыры и вылизаны. Для наколенных систем от дядюшки Ляо и софтовых псевдо RAID контроллеров это неприятность, конечно.
ESX поддерживает меньшее количество железа, хотя строго говоря, практически любой сервер крупных вендоров полностью поддерживается, но драйверы оттестированы во все дыры и вылизаны. Для наколенных систем от дядюшки Ляо и софтовых псевдо RAID контроллеров это неприятность, конечно.
Значит, дорога одна, к vSphere… Спасибо большое за ответы!
VMWare, как 1С, едина во многих лицах :)
Насколько я понимаю, оставляя в стороне мишуру, у VMWare два основных продукта — один работает как сервер (Workstation, Server), второй как гипервизор (ESX, Sphere). Дальше на них фенечки накручиваются, получаются разные продукты… Если нет, расскажите, будет интересно. Только, если можно, именно про сердцевину, продажа того же самого под особыми соусами не интересна.
Насколько я понимаю, оставляя в стороне мишуру, у VMWare два основных продукта — один работает как сервер (Workstation, Server), второй как гипервизор (ESX, Sphere). Дальше на них фенечки накручиваются, получаются разные продукты… Если нет, расскажите, будет интересно. Только, если можно, именно про сердцевину, продажа того же самого под особыми соусами не интересна.
У VMware есть много продуктов.
1) Workstation / Player — десктопная платформа для PC (Win + Lin), Fusion — Mac
2) Server — бесплатная серверная платформа, гипервизор 2го типа (Win + Lin)
3) ESX / ESXi — гипервизор первого типа
4) vCenter Server — сервер централизованного управления ESX/ESXi серверами
Практически все остальные продукты направлены на обслуживание 3+4 (Общее продуктовое название vSphere) и добавляют различный функционал к
5) View — VDI платформа
6) Lab Manager — для компаний-разработчиков ПО. Направленность — управление гигантским количеством снапшотов для отладки и тестирования
7) Lifecycle Manager — управление жизненным циклом ВМ
8) Application Discovery Manager — безагентный дискаверинг приложений
9) ThinApp — виртуализация приложений
10) Site Recovery Manager — средство автоматизации восстановления при падении сайта целиком
11) Converter — p2v&v2v средство
12) Chargeback — биллинг виртуальной инфраструктуры
13) AppSpeed — дискаверинг приложений и контроль за соблюдением SLA на vSphere
14) CapacityIQ — контроль мощностей
15) Service Manager — ITSM Ж)
16) Configuration Manager — контроль конфигураций
Помимо этого есть встроенные / полувстроенные продукты, идущие в комплекте с vSphere
17) Update Manager — централизованный патчинг серверов ESX/ESXi и Windows ВМ. Для Linux поддерживается только контроль патчей, без их установки
18) Orchestrator — средство для автоматизации на основе workflow (идет в комплекте с vCenter), позволяетделать интерфейсы самообслуживания для сотрудников, у которых нет прямого доступа к vSphere
19) vShield Zones — appliance (ВМ) с файрволлом для защиты других ВМ
20) Data Recovery — appliance для бэкапа ВМ
21) AutoDeploy (еще не зарелизили в GA) — appliance для деплоймента ESXi по PXE
Помимо этого VMware купила так же Zimbra и SpingSource (Java)
1) Workstation / Player — десктопная платформа для PC (Win + Lin), Fusion — Mac
2) Server — бесплатная серверная платформа, гипервизор 2го типа (Win + Lin)
3) ESX / ESXi — гипервизор первого типа
4) vCenter Server — сервер централизованного управления ESX/ESXi серверами
Практически все остальные продукты направлены на обслуживание 3+4 (Общее продуктовое название vSphere) и добавляют различный функционал к
5) View — VDI платформа
6) Lab Manager — для компаний-разработчиков ПО. Направленность — управление гигантским количеством снапшотов для отладки и тестирования
7) Lifecycle Manager — управление жизненным циклом ВМ
8) Application Discovery Manager — безагентный дискаверинг приложений
9) ThinApp — виртуализация приложений
10) Site Recovery Manager — средство автоматизации восстановления при падении сайта целиком
11) Converter — p2v&v2v средство
12) Chargeback — биллинг виртуальной инфраструктуры
13) AppSpeed — дискаверинг приложений и контроль за соблюдением SLA на vSphere
14) CapacityIQ — контроль мощностей
15) Service Manager — ITSM Ж)
16) Configuration Manager — контроль конфигураций
Помимо этого есть встроенные / полувстроенные продукты, идущие в комплекте с vSphere
17) Update Manager — централизованный патчинг серверов ESX/ESXi и Windows ВМ. Для Linux поддерживается только контроль патчей, без их установки
18) Orchestrator — средство для автоматизации на основе workflow (идет в комплекте с vCenter), позволяетделать интерфейсы самообслуживания для сотрудников, у которых нет прямого доступа к vSphere
19) vShield Zones — appliance (ВМ) с файрволлом для защиты других ВМ
20) Data Recovery — appliance для бэкапа ВМ
21) AutoDeploy (еще не зарелизили в GA) — appliance для деплоймента ESXi по PXE
Помимо этого VMware купила так же Zimbra и SpingSource (Java)
Забыл vCenter Server HeartBeat — кластеризация vCenter Server, лицензирован у Neverfail.
Собственно, я про это и говорил: «гипервизор второго типа» (workstation, server), «гипервизор первого типа» (baremetall). Всё остальное — сервисные рюшечки вокруг него. Т.е. для тех, кто продаёт это важно. Если говорить в вопросах основного фунционала — то нет.
Что считать основным фукнционалом, а что дополнительным и рюшечками?
Если подразумевается сам запуск ВМ и основные операции с ними, то минимальный комплект — это минимум 2 ESX/ESXi + vCenter.
Если подразумевается сам запуск ВМ и основные операции с ними, то минимальный комплект — это минимум 2 ESX/ESXi + vCenter.
Ну вы как с покупателем в магазине разговариваете. Основной функционал — это гипервизор. Приложение, загружающееся до операционных систем и контролирующее их доступ к ресурсам процессора, памяти, периферийных устройств.
Его возможности определяют то, что можно на них накрутить дальше. А всякие гуёвые списочки машин, и даже совсем не гуёвые виртуальные коммутаторы — это уже второстепенное. Конечно, важное, но второстепенное. Примерно в таком же соотношении, как ядро ОС VS прикладной софт для администрирования этой ОС.
Его возможности определяют то, что можно на них накрутить дальше. А всякие гуёвые списочки машин, и даже совсем не гуёвые виртуальные коммутаторы — это уже второстепенное. Конечно, важное, но второстепенное. Примерно в таком же соотношении, как ядро ОС VS прикладной софт для администрирования этой ОС.
С точки зрения кого? Инженера, копающегося в коде гипервизора — возможно.
А с точки зрения скажем ИТ директора уже неинтересны ни hypercall'ы, ни особенности проброса USB. ИТ директору важны показатели доступности сервисов и время простоя, и соблюдение SLA.
А с точки зрения скажем ИТ директора уже неинтересны ни hypercall'ы, ни особенности проброса USB. ИТ директору важны показатели доступности сервисов и время простоя, и соблюдение SLA.
А с точки зрения бухгалтера там важны не гипервизоры, а выделение НДС и наличие заполненной ГТД. У каждого свой взгляд на ПО.
Я — технический гик, и для меня архитектурные особенности важны (потому что именно они, а не желание маркетологов в итоге определяют что же собственно будет, а чего нет).
(Быстрый пример: именно ограничения гипервизора не позволяют реализовать эмуляцию SMP из нескольких хостов, но никак не решение маркетолога «это не нужно»).
Я — технический гик, и для меня архитектурные особенности важны (потому что именно они, а не желание маркетологов в итоге определяют что же собственно будет, а чего нет).
(Быстрый пример: именно ограничения гипервизора не позволяют реализовать эмуляцию SMP из нескольких хостов, но никак не решение маркетолога «это не нужно»).
Почему же только ограничения гипервизора? Организовать эмуляцию можно, но очень дорого и нафиг не нужно, потому что слишком большие задержки получаются из-за необходимости синхронизации и эмуляции обычной монолитной машины.
Доступ к памяти — порядок наносекунд, доступ к внешней памяти даже по Infiniband уже в 1000 раз медленнее, не считая времени на обработку сетевых пакетов процессором.
Доступ к памяти — порядок наносекунд, доступ к внешней памяти даже по Infiniband уже в 1000 раз медленнее, не считая времени на обработку сетевых пакетов процессором.
Вот я про это — ограничение технологии. И если хочешь знать, что такое на самом деле продукт — должен знать, что там внутри происходит.
PS Мне кажется, что разделение по SMP имеет смысл делать по отдельным группам процессов с ограниченным IPC — в этом случае объём взаимодействия будет меньше и вполне будет выживать в «дорогом IPC».
PS Мне кажется, что разделение по SMP имеет смысл делать по отдельным группам процессов с ограниченным IPC — в этом случае объём взаимодействия будет меньше и вполне будет выживать в «дорогом IPC».
Тогда это никак не SMP, это NUMA.
NUMA — это доступ к памяти. А я говорю про возможность сплитить task queue (насколько я знаю, даже сейчас у линукса есть правило — стараться поменьше таскать процессы с ядра на ядро) и выполнять каждую из queue раздельно, предоставляя немодифицированному юзерспейсу иллюзию тысячеглавости.
Планировщик на настоящих NUMA системах так и делает: потоки одного процесса пытается выполнять в пределах одного NUMA узла.
А зачем отдельным процессам иметь иллюзию большой машины? Общая память нужна только там, где она необходима программе.
А зачем отдельным процессам иметь иллюзию большой машины? Общая память нужна только там, где она необходима программе.
Ровно за тем же, зачем нужна виртуализация — решать проблемы кривых конфигураций внешними средствами.
Ответ не понятен. Можно конкретнее?
Ответ конкретнее — у человека толстый сервер из пачки приложений, который не влазит на один хост. Пилить на части дорого. Проще сделать подобие сверхтолстого сервера.
Проще разложить пачку приложений по разным ВМ.
Ситуация, описанная Вами есть, но сейчас практически не составляет проблем либо дать пинка программиздам, чтобы переделали код (зачастую ускорение кода может составить несколько раз), либо купить многоголовый многоядерный физ сервер под задачу.
Ситуация, описанная Вами есть, но сейчас практически не составляет проблем либо дать пинка программиздам, чтобы переделали код (зачастую ускорение кода может составить несколько раз), либо купить многоголовый многоядерный физ сервер под задачу.
То же самое можно сказать про виртуализацию. Никто же не мешает осуществлять консолидацию серверов методом переноса всех приложений на один сервер. Однако, выясняется множество причин, когда всё это проще порезать категориями «серверов» и виртуализировать.
Аналогично может быть и с жирным софтом — возможно, например, он настолько туп, что не хочет работать по сети. Или ещё какие-то кривости.
Сама технология виртуализации появилась из-за необходимости изолировать софт друг от друга (т.е. как аварийное железобетонное средство, которое работает всегда).
Аналогично может быть и с жирным софтом — возможно, например, он настолько туп, что не хочет работать по сети. Или ещё какие-то кривости.
Сама технология виртуализации появилась из-за необходимости изолировать софт друг от друга (т.е. как аварийное железобетонное средство, которое работает всегда).
5, 9, 15 — совершенно отдельные продукты, которые могут использоваться без vSphere.
Сейчас православнее говорить не VMware ESXi, а VMware Hypervisor :-)
Дополнил список и написал отдельным постом — blog.vadmin.ru/2010/08/vmware-workstation.html
Или я что-то не то рассказал? Уточните.
Хорошая обзорная статья по основным технологиям
в статье столько жаргонизмов
что приходится переводить с русского на русский
автору минус
что приходится переводить с русского на русский
автору минус
А вы хотите, чтобы я вместо «снапшот» писал его ближайший аналог на русский? Уверены, что вы бы после этого поняли о чём речь?
VMware
>binary rewriting. Этот подход использует VMWare и Connectix Virtual PC (куплен microsoft)
Данный подход используют все гипервизоры второго типа aka мониторы виртуальных машин, исполняющиеся поверх основой ОС. VMware Server (ex-GSX Server), VMware Player, VMware Workstation, Microsoft Virtual PC (ex-Connectix), Microsoft Virtual Server, Oracle Virtual Box (ex-Sun, ex-Innotek).
>HyperV (?)
Без вопросительного знака. Hyper-V работает с аппаратной виртуализацией.
>В реальности реализуется с помощью suspend на одной машине и resume на другой c некоторой оптимизацией процесса переноса данных
Не совсем так. Данные не сохраняются на диск, а передаются просто по сети, и машина «замораживается» только в самом конце, когда все данные переданы и нужно переключить исполнение на другой аппаратный сервер.
Также миграция бывает не с сервера на сервер, а с хранилища на хранилище — изменение местоположения файлов с ВМ. Бывает так же оффлайновой, и онлайновой (без выключения ВМ).
>ballooning. Общепринятый механизм (как минимум, xen и hyperv, вроде, есть у VMWare)
Как раз ровно наоборот. Есть и был придуман VMware, есть у Xen и судя по всему есть/будет у Hyper-V, хотя Microsoft надувает щеки и пытается придумать новые названия для общепринятых терминов.
>•Memory hot-plug. Добавление памяти на ходу. Поддерживается в hyper-v в будущих sp для windows server (в релизе пока нет), в xen 4.1 (в linux 2.6.32).
И в VMware vSphere 4.0 / 4.1 с мая 2009. В качестве гостевой необходима Windows 2003 SP1 и выше, Windows Vista / 7, и некоторые Linux (RHEL 5 точно есть).
Секция сетевых устройств написана словно автор знает только настольные платформы. Есть еще один вариант, который не совсем бриджинг. В частности используется VMware и частично Hyper-V (насчет Xen и KVM не знаю). Создается виртуальный L2 коммутатор, который может иметь, а может и не иметь физические аплинки (физические порты), а в этот коммутатор подключаются своими виртуальными сетевыми картами ВМ.
Open vSwitch — это инициатива по разработке аналога Distributed vSwitch, появившегося в VMware vSphere 4.0. Distributed vSwitch — логически объединенный коммутатор, физически распредленный по нескольким хостам. Этим отличается от Standard vSwitch, работающего только в пределах одного хоста.
>Заодно поддерживается и простейший fault-tolerance (при использовании совместного сетевого хранилища) — если один хозяин с пачкой виртуальных машин умер, то виртуальные машины будут запущены на других хозяевах, входящих в инфраструктуру.
Это называется High Availability у VMware или Failover Clustering у Microsoft. У VMware есть встроенная функция Fault Tolerance — зеркалирование работающей виртуальной машины и моментальное переключение на зеркало без даунтайма. Аналог — сторонний продукт Marathon EverRun.
>binary rewriting. Этот подход использует VMWare и Connectix Virtual PC (куплен microsoft)
Данный подход используют все гипервизоры второго типа aka мониторы виртуальных машин, исполняющиеся поверх основой ОС. VMware Server (ex-GSX Server), VMware Player, VMware Workstation, Microsoft Virtual PC (ex-Connectix), Microsoft Virtual Server, Oracle Virtual Box (ex-Sun, ex-Innotek).
>HyperV (?)
Без вопросительного знака. Hyper-V работает с аппаратной виртуализацией.
>В реальности реализуется с помощью suspend на одной машине и resume на другой c некоторой оптимизацией процесса переноса данных
Не совсем так. Данные не сохраняются на диск, а передаются просто по сети, и машина «замораживается» только в самом конце, когда все данные переданы и нужно переключить исполнение на другой аппаратный сервер.
Также миграция бывает не с сервера на сервер, а с хранилища на хранилище — изменение местоположения файлов с ВМ. Бывает так же оффлайновой, и онлайновой (без выключения ВМ).
>ballooning. Общепринятый механизм (как минимум, xen и hyperv, вроде, есть у VMWare)
Как раз ровно наоборот. Есть и был придуман VMware, есть у Xen и судя по всему есть/будет у Hyper-V, хотя Microsoft надувает щеки и пытается придумать новые названия для общепринятых терминов.
>•Memory hot-plug. Добавление памяти на ходу. Поддерживается в hyper-v в будущих sp для windows server (в релизе пока нет), в xen 4.1 (в linux 2.6.32).
И в VMware vSphere 4.0 / 4.1 с мая 2009. В качестве гостевой необходима Windows 2003 SP1 и выше, Windows Vista / 7, и некоторые Linux (RHEL 5 точно есть).
Секция сетевых устройств написана словно автор знает только настольные платформы. Есть еще один вариант, который не совсем бриджинг. В частности используется VMware и частично Hyper-V (насчет Xen и KVM не знаю). Создается виртуальный L2 коммутатор, который может иметь, а может и не иметь физические аплинки (физические порты), а в этот коммутатор подключаются своими виртуальными сетевыми картами ВМ.
Open vSwitch — это инициатива по разработке аналога Distributed vSwitch, появившегося в VMware vSphere 4.0. Distributed vSwitch — логически объединенный коммутатор, физически распредленный по нескольким хостам. Этим отличается от Standard vSwitch, работающего только в пределах одного хоста.
>Заодно поддерживается и простейший fault-tolerance (при использовании совместного сетевого хранилища) — если один хозяин с пачкой виртуальных машин умер, то виртуальные машины будут запущены на других хозяевах, входящих в инфраструктуру.
Это называется High Availability у VMware или Failover Clustering у Microsoft. У VMware есть встроенная функция Fault Tolerance — зеркалирование работающей виртуальной машины и моментальное переключение на зеркало без даунтайма. Аналог — сторонний продукт Marathon EverRun.
HyperV использует binary rewriting или нет? Если он использует ТОЛЬКО аппаратную виртуализацию, то он не использует binary rewriting.
Кто первый придумал ballooning вопрос очень интересный. Дело в том, что в архитектуре PV в зене баллунинг на самом деле — это отдача памяти гипервизору. Просто объективная отдача (соответствующий syscall говорит гипервизору «эта страница не нужна»). И это часть более общего механизма обмена страницами памяти… Она слишком глубоко внутри зена, чтобы быть заимствованной.
Секция про сеть как раз про этот «виртуальный коммутатор» и говорит. По сути — это обычный бриджинг, после чего с виртуальными интерфейсами можно делать что угодно — хоть туннелировать, хоть в витуальный же коммутатор включать. Просто VMWare и остальные проприентарщики пытаются на связку «бридж+софт в dom0» навесить всякие клёвые ярлыки. У зена же наоборот, «вот тебе соска, куда хочешь, туда и пристраивай». В XCP используется open vSwitch, в большинстве случаев же достаточно brctl.
Насчёт F/T у MS спасибо, не знал. У зена это называется remus.
Кто первый придумал ballooning вопрос очень интересный. Дело в том, что в архитектуре PV в зене баллунинг на самом деле — это отдача памяти гипервизору. Просто объективная отдача (соответствующий syscall говорит гипервизору «эта страница не нужна»). И это часть более общего механизма обмена страницами памяти… Она слишком глубоко внутри зена, чтобы быть заимствованной.
Секция про сеть как раз про этот «виртуальный коммутатор» и говорит. По сути — это обычный бриджинг, после чего с виртуальными интерфейсами можно делать что угодно — хоть туннелировать, хоть в витуальный же коммутатор включать. Просто VMWare и остальные проприентарщики пытаются на связку «бридж+софт в dom0» навесить всякие клёвые ярлыки. У зена же наоборот, «вот тебе соска, куда хочешь, туда и пристраивай». В XCP используется open vSwitch, в большинстве случаев же достаточно brctl.
Насчёт F/T у MS спасибо, не знал. У зена это называется remus.
> Если он использует ТОЛЬКО аппаратную виртуализацию, то он не использует binary rewriting.
А что, я где-то написал, что он использует binary rewrite?
>Она слишком глубоко внутри зена, чтобы быть заимствованной.
Xen появился в 2003, ESX — в 2001. А может идея просто витала в воздухе и была реализована и там и там.
>По сути — это обычный бриджинг, после чего с виртуальными интерфейсами можно делать что угодно — хоть туннелировать, хоть в витуальный же коммутатор включать.
В каком месте это бриджинг, если
1) в виртуальном коммутаторе может не быть аплинков
2) он работает строго на L2.
Хотя конечно у Вас что понятие облака, что понятие сети какое-то свое.
А что, я где-то написал, что он использует binary rewrite?
>Она слишком глубоко внутри зена, чтобы быть заимствованной.
Xen появился в 2003, ESX — в 2001. А может идея просто витала в воздухе и была реализована и там и там.
>По сути — это обычный бриджинг, после чего с виртуальными интерфейсами можно делать что угодно — хоть туннелировать, хоть в витуальный же коммутатор включать.
В каком месте это бриджинг, если
1) в виртуальном коммутаторе может не быть аплинков
2) он работает строго на L2.
Хотя конечно у Вас что понятие облака, что понятие сети какое-то свое.
Это я написал hyper-v с знаком вопроса в разделе про binary rewriting. Если точно известно, что нет, сейчас уберу.
Извините, понятие бриджа у меня такое же, как в линуксе. Виртуальный коммутатор, в который можно втыкать любые порты — аппаратные, виртуальные…
Выглядит это так:
eth0 Link encap:Ethernet HWaddr 00:30:48:F2:7A:D8
eth1 Link encap:Ethernet HWaddr 00:30:48:F2:7A:D9
eth2 Link encap:Ethernet HWaddr 00:25:90:06:E2:E0
eth3 Link encap:Ethernet HWaddr 00:25:90:06:E2:E1
lo Link encap:Local Loopback
vif1.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
vif2.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
vif3.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
vif6.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
vif7.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
vif11.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
vif28.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
vif28.1 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
vif33.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
vif36.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
vif42.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
xenbr0 Link encap:Ethernet HWaddr 00:30:48:F2:7A:D8
xenbr1 Link encap:Ethernet HWaddr 00:30:48:F2:7A:D9
xenbr2 Link encap:Ethernet HWaddr 00:25:90:06:E2:E0
xenbr3 Link encap:Ethernet HWaddr 00:25:90:06:E2:E1
В состав xenbr можно включать любую комбинацию интерфейсов. А можно не включать. А можно сделать свой (на dom0) виртуальный интерфейс в бридж и включить маршрутизацию\NAT.
Возможно, в некоторых интерфейсах есть логическое разделение между «бридж с одним физическим интерфейсом в эксклюзивное пользование» и между «воткнуться в виртуальную сеть». В зене первое — частный случай второго.
Извините, понятие бриджа у меня такое же, как в линуксе. Виртуальный коммутатор, в который можно втыкать любые порты — аппаратные, виртуальные…
Выглядит это так:
eth0 Link encap:Ethernet HWaddr 00:30:48:F2:7A:D8
eth1 Link encap:Ethernet HWaddr 00:30:48:F2:7A:D9
eth2 Link encap:Ethernet HWaddr 00:25:90:06:E2:E0
eth3 Link encap:Ethernet HWaddr 00:25:90:06:E2:E1
lo Link encap:Local Loopback
vif1.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
vif2.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
vif3.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
vif6.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
vif7.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
vif11.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
vif28.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
vif28.1 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
vif33.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
vif36.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
vif42.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
xenbr0 Link encap:Ethernet HWaddr 00:30:48:F2:7A:D8
xenbr1 Link encap:Ethernet HWaddr 00:30:48:F2:7A:D9
xenbr2 Link encap:Ethernet HWaddr 00:25:90:06:E2:E0
xenbr3 Link encap:Ethernet HWaddr 00:25:90:06:E2:E1
В состав xenbr можно включать любую комбинацию интерфейсов. А можно не включать. А можно сделать свой (на dom0) виртуальный интерфейс в бридж и включить маршрутизацию\NAT.
Возможно, в некоторых интерфейсах есть логическое разделение между «бридж с одним физическим интерфейсом в эксклюзивное пользование» и между «воткнуться в виртуальную сеть». В зене первое — частный случай второго.
Так Вы про общие технологии виртуализации в общепринятых терминах или про Xen в своих собственных? Это и к вопросу о NUMA.
Я про то, что могут делать системы виртуализации. Насколько я понимаю, чем ближе к краю, тем меньше там общепринятных терминов. Что с NUMA смущает?
PS Дописал замечание про разделение режима «бриджинга с физ.интерфейсом» и «виртуального коммутатора».
PS Дописал замечание про разделение режима «бриджинга с физ.интерфейсом» и «виртуального коммутатора».
Не написано ЧТО такое NUMA и чем отличается от обычных систем. То, что написано — лишь интересная теоретическая возможность для узкой ниши задач. В рамках традиционных систем, не допускающих использования внешней RAM, это пока никому не нужно.
В .config для 2.6.32 (34) уже есть что-то про NUMA. Умеет ли MS — не имею представления.
Вообще, глубоко не копал, пишу по теоретически прочитанному в defenitive guide to xen.
Вообще, глубоко не копал, пишу по теоретически прочитанному в defenitive guide to xen.
MS умеет работать с NUMA, но для локальной памяти, а не внешней.
NUMA — это все Opteron, и Xeon'ы начиная с Nehalem.
К вопросу о ядрах. RHEL 5.5 до сих пор 2.6.18, в SLES вроде тоже примерно такое же ядро. А это две основные Linux системы класса Enterprise.
NUMA — это все Opteron, и Xeon'ы начиная с Nehalem.
К вопросу о ядрах. RHEL 5.5 до сих пор 2.6.18, в SLES вроде тоже примерно такое же ядро. А это две основные Linux системы класса Enterprise.
Про SLES не знаю, а SUSE'шное ядро (2.6.34) офигенно с зеном работает. Относительно «энтерпрайза»… Мне трудно сказать, я работаю с дебианом (там стабильное ядро — 2.6.26, .32 ушло во фриз для сквизи). Но ядра для паравиртуализации всё равно лучше использовать свои, а не «универсальные». Универсальные тащат за собой огромный кусок саппорта того, чего в PV нет и никогда не будет (разница в размере pure-PV и универсального — раз в 5). А ведь это не только размер, но и скорость, и стабильность (чем больше функционала в ядре, тем выше вероятность стать принудительным багтестером).
Признаю свою неправоту:
Joel H. Schopp Keir Fraser Resizing Memory With Balloons and Hotplug //2006 Linux Symposium, Volume Two page 308
In 2002 Waldspurger[5] introduced the concept of ballooning as it was implemented in the VMware ESX Server. In 2003 this concept was adopted by the Xen team[6] to support their memory management needs.
Joel H. Schopp Keir Fraser Resizing Memory With Balloons and Hotplug //2006 Linux Symposium, Volume Two page 308
NUMA — возможность расширять память вируальной машины в объёме большем, чем есть на сервере. Технология сырая и не совсем мейнстримовая (я глубоко не копал, так что подробнее не расскажу)
Хммм… Неужели википедия врет?
NUMA (Non-Uniform Memory Access — «неравномерный доступ к памяти» или Non-Uniform Memory Architecture — «Архитектура с неравномерной памятью») — схема реализации компьютерной памяти, используемая в микропроцессорах, когда время доступа к памяти определяется её расположением по отношению к процессору.
Технология, позволяющая «расширять память вируальной машины в объёме большем, чем есть на сервере» — называется «memory overcommitment», а за «сырая и не совсем мейнстримовая» поклонники VMware будут больно бить. Возможно даже ногами.
На NUMA основывается возможность юзать память с неровным временем доступа. В частности, в зене она запилена для возможности подключить память с чужого хоста. Когда я писал «сырая» я имел в виду, что не видел продакт-системы, в которой бы она использовала как штатную фичу. Если знаете, говорите.
Overcommitment это не «расширение памяти за пределы хоста», это декларация, что памяти больше, чем есть. Между декларацией и реальным использованием есть некоторая разница, нэ?
Overcommitment это не «расширение памяти за пределы хоста», это декларация, что памяти больше, чем есть. Между декларацией и реальным использованием есть некоторая разница, нэ?
>Между декларацией и реальным использованием есть некоторая разница, нэ?
В терминах VMware
Memory Overcommitment = Sum (VM Memory Configured) > Physical Memory
В силу того, что память в ВМ не занята постоянно на 100%, можно сделать вид, что памяти на самом деле больше и перераспределять физическую память между машинам по мере того, как потребности изменяются.
У VMware и Red Hat (в последней версии) этому так же помогает дедупликация памяти.
В терминах VMware
Memory Overcommitment = Sum (VM Memory Configured) > Physical Memory
В силу того, что память в ВМ не занята постоянно на 100%, можно сделать вид, что памяти на самом деле больше и перераспределять физическую память между машинам по мере того, как потребности изменяются.
У VMware и Red Hat (в последней версии) этому так же помогает дедупликация памяти.
Это понятно. Но это не та вещь, про которую я говорю. Декларировать много неиспользуемой памяти можно. Но это не соответствует тому, для чего NUMA может применяться.
Как только закончу разбираться с тонкостями hypercall при управлении памятью, начинаю заниматься NUMA и REMUS более плотно. Пока руки никак не доходят.
Как только закончу разбираться с тонкостями hypercall при управлении памятью, начинаю заниматься NUMA и REMUS более плотно. Пока руки никак не доходят.
Кстати говоря, совершенно не рассмотрена контейнерная виртуализация.
Представители — Parallels Virtuozzo, Sun Solaris Containers, HP Integrity VM
Представители — Parallels Virtuozzo, Sun Solaris Containers, HP Integrity VM
openvz, упомянута. virtuozzo — лишь нашлёпка поверх openvz (как там в виндах не знаю).
Впрочем, да, в управлении кодом не написано. Сейчас допишу.
Впрочем, да, в управлении кодом не написано. Сейчас допишу.
IBM PowerVM туда же.
Увы, в глаза не видел. Что умеет, чем известна? (Или это из IBM world?)
Особо глубоко не ковырялся, но видеть воочию пришлось.
Виртуализирует только AIX 5+, RHEL 5.1+, SLES 10+; здорово интегрирована со стеком IBM (Tivolli, Director); LPARы (местные контейнеры) можно перекидывать между физическими машинами без даунтайма; есть что-то для отказоустойчивости, но это не использовали, не знаю; память, когда я на это смотрел, точно нельзя было никак перераспределять, но было много хитрых настроек использования процессора.
Скорее всего, из статьи там ничего нет, ибо все плотно завязано на бимеровое железо/софт. Ну и надежность: неожиданностей, кроме как с сетью, от что-то-под-OS/370 -> 2xPOWER5 -> POWER6, за много-много лет никто из ИТ-отдела припомнить не мог.
Виртуализирует только AIX 5+, RHEL 5.1+, SLES 10+; здорово интегрирована со стеком IBM (Tivolli, Director); LPARы (местные контейнеры) можно перекидывать между физическими машинами без даунтайма; есть что-то для отказоустойчивости, но это не использовали, не знаю; память, когда я на это смотрел, точно нельзя было никак перераспределять, но было много хитрых настроек использования процессора.
Скорее всего, из статьи там ничего нет, ибо все плотно завязано на бимеровое железо/софт. Ну и надежность: неожиданностей, кроме как с сетью, от что-то-под-OS/370 -> 2xPOWER5 -> POWER6, за много-много лет никто из ИТ-отдела припомнить не мог.
VMware кстати поправьте :) Название компании пишется именно так :)
А кто-нибудь может написать конкретно как работает ESXi 4.2 c процессорами. 4 vCPU должны раскладываться на 8 физических (в моем случае). Я такого не заметил. Винда нагружает только те 4 проца, которые видит. Сегодня в 1С 8.1 делал проведение с начала года. Загружает вообще один проц (многопоточность поправили в 8.2) и считает дольше чем на локальной тачке с процом 2-х ядерным но с большей герцовкой. Оставил винде 1 vSMP. Результат тот-же. 1С нагружает его на 100 процентов (2000 мГц) и соответственно те-же грабли. Как добиться чтоб нагрузка раскладывалась на 8 физических CPU c 4 или даже с 1 vCPU?
Кстати vSphere (ESX/ESXi) 4.2 безболезненно пробрасывает USB внутрь гостя.
Кстати vSphere (ESX/ESXi) 4.2 безболезненно пробрасывает USB внутрь гостя.
ESXi 4.2 не существует, есть только 4.0u2 и 4.1
>4 vCPU должны раскладываться на 8 физических
Нет. 1 vCPU = 1 ядро, много vCPU от *разных* ВМ могут делить одно физическое ядро, но 1 vCPU никогда не размазывается по разным ядрам. Переключить ESXi исполнение этого vCPU на другой ядро может, но объединить и запустить в параллель — нет.
> Как добиться чтоб нагрузка раскладывалась на 8 физических CPU c 4 или даже с 1 vCPU?
Никак, это невозможно.
>4 vCPU должны раскладываться на 8 физических
Нет. 1 vCPU = 1 ядро, много vCPU от *разных* ВМ могут делить одно физическое ядро, но 1 vCPU никогда не размазывается по разным ядрам. Переключить ESXi исполнение этого vCPU на другой ядро может, но объединить и запустить в параллель — нет.
> Как добиться чтоб нагрузка раскладывалась на 8 физических CPU c 4 или даже с 1 vCPU?
Никак, это невозможно.
Обшибся, конечно 4.1! Значит и частоту на vCPU повысить нельзя??? Мда. Вот это ппц. Меня убеждали в обратном, что варя размажет нагрузку по процам. И ЗДЕСЬ меня убедили в этом.
… однако, я не видел ни одной системы живой миграции, которая бы позволила на ходу мигрировать машину между разными системами
По-вашему, существует необходимость в подобных системах?
Конечно, если не рассматривать довольно редкие случаи полной смены платформы виртуализации, что в большинстве своём решается существующими «офлайновыми» конвертерами.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Современные возможности виртуализации