А объясните мне про консолидацию серверов
1. Правильно ли я понимаю суть проблемы и решение - как я описал выше?1. Почти правильно. К решению присовокупи ещё нездоровый впаривательный ажиотаж маркетологов. Он и является тем перпетум-мобиле, на котором держится процесс консолидации серверов в крупных кампаниях.
2. VM Ware - как я понимаю это программа эмулятор - и работает она под какой то осью?
3. В чем фишка использования виртуальных машин - почему нельзя "просто запустить несколько процессов" под "обычной" системой. Ведь наверняка же и сейчас например такие штуки как dns и dhcp и всякие шлюзы - реально выполняет один комп без множества виртуальных машин на нем на которых запущено по одному серверу
2. VMWare - не эмулятор, это паравиртуализатор. Для эффективной работы необходима поддержка паравиртуализации на уровне процессора, но даже современные десктопные, не говоря о серверных, это умеют. Она работает под (редхат) гну линуксом. Поставляется вместе с оным линуксом, так что настраивается только vmware, а линукс уже подогнан под него (редакция ESX сервер). Самостоятельные поделки виртуализации на базе известных решений (virtualbox OSE, KVM) и настроенного линукса консолидацией не являются, поскольку лишены отличительной особенности номер один (нездоровой впаривательной активности)
3. Фишка в том, что админов, готовых настроить фейлсейф архитектуру на одном линуксе с обеспечением независимости работы сервисов, хороших бекапов, слишком мало. Это сложнее, чем кажется на первый взгляд. Опыт домашнего сервера тут явно не достаточен, поскольку не подразумевает высокого уровня надёжности, снижения простоя до часа в год, скажем.
Поэтому используются решения на базе виратуальных машин, благодаря чему к администрированию можно привлекать куда более дешёвых индусов.
Откуда упрощение?
Во-первых, добавляется новый уровень, некое ядро, которое уже отлажено VMWare и обеспечивает бесперебойную надёжную работу без дополнительных настроек.
Во-вторых, в виртуальные машины выделяются отдельные функциональности и зоны ответственности, благодаря чему индусы не рискуют ошибиться всей системой а только её частью, могут смело экспериментировать на тренировочных, не боевых, серверах.
В-третьих, обеспечивается разделение ресурсов, которые тоже, конечно, можно сделать на голом линуксе, но сложнее.
В общем, процессорное время жертвуется в пользу админского времени и некомпетентности. По вполне сносной цене.
В общем, процессорное время жертвуется в пользу админского времени и некомпетентности. По вполне сносной цене.ну
это конечно как правило
но не всегда же
вот надо например запустить какуюнить довольно архаичную прогу требующую архаичную ос (или требующую чтобы ее не запускали с какойнить другой прогой отдновременно)
варианты: купить под нее отдельный комп, который большую часть времени будет простаивать или поставить ее в виртуалку
1. Суть проблемы - на большей части серверов CPU простаивает. Ну и с помощью виртуализации добиваются более полной загрузки(оно пришло с мэйнфреймов ещё). Но при этом требования по ОЗУ и I/O не снижаются - поэтому эти подсистемы должны соответствовать (много памяти, несколько сетевых адаптеров, мощные СХД и т. д.).
2. В редакции ESX Server сначала грузится линух со своим ядром и как один из сервисов запускается vmkernel, после чего линух становится одной из виртуальных машин - так называемой сервисной консолью.
3. Сервисы могут требовать разные ОС, разные сетевые адаптеры - не выводить же на сервер 2 адаптера из DMZ и внутренней сети? Контроллёр домена AD, например, не любит более одного сетвого адаптера. Многие сервисы желательно не совмещать с чем-либо. Требования безопасности и разграничения прав опять же.
Вообще, сейчас, с ростом производительности x86, виртуализация становится всё более часто используемой.
Кстати, далеко не все архаичные ОС запустятся под вмварью - полуось так и не пустили, к примеру.
Самостоятельные поделки не подходят для более-менее серьёзной конторы именно в силу того, чем они являются - самостоятельными поделками
2. В редакции ESX Server сначала грузится линух со своим ядром и как один из сервисов запускается vmkernel, после чего линух становится одной из виртуальных машин - так называемой сервисной консолью.
3. Сервисы могут требовать разные ОС, разные сетевые адаптеры - не выводить же на сервер 2 адаптера из DMZ и внутренней сети? Контроллёр домена AD, например, не любит более одного сетвого адаптера. Многие сервисы желательно не совмещать с чем-либо. Требования безопасности и разграничения прав опять же.
Вообще, сейчас, с ростом производительности x86, виртуализация становится всё более часто используемой.
Кстати, далеко не все архаичные ОС запустятся под вмварью - полуось так и не пустили, к примеру.
Самостоятельные поделки виртуализации на базе известных решений (virtualbox OSE, KVM) и настроенного линукса консолидацией не являются, поскольку лишены отличительной особенности номер один (нездоровой впаривательной активности)
Самостоятельные поделки не подходят для более-менее серьёзной конторы именно в силу того, чем они являются - самостоятельными поделками
Самостоятельные поделки не подходят для более-менее серьёзной конторы именно в силу того, чем они являются - самостоятельными поделкамитолько с точки зрения финансовых директоров. Настроить фейлсейф можно и самостоятельно. Всё необходимое есть.
файлсейф - может быть.
Как у этих решений обстоят дела с аналогами VMWare-ных "опций" V-Motion и Storage V-Motion - перемещение виртуальных машин с хоста на хост "на живую" без остановки предоставления сервиса для потребителей? Эти опции ОЧЕНЬ полезны, когда бизнес требует для каких-то серверов определённых KPI.
Как у этих решений обстоят дела с аналогами VMWare-ных "опций" V-Motion и Storage V-Motion - перемещение виртуальных машин с хоста на хост "на живую" без остановки предоставления сервиса для потребителей? Эти опции ОЧЕНЬ полезны, когда бизнес требует для каких-то серверов определённых KPI.
во-первых, тот же motion не идеален, он работает только если обе точки имеют доступ к одному файлохрану, где и лежит виртуалка.
во-вторых, один линукс, много приложений - это подход на уровне приложений, а не виртуалок, он априрори более гибкий. Для большинства приложений можно разработать скрипт, позволяющий перевести его работу на другой хост.
во-вторых, один линукс, много приложений - это подход на уровне приложений, а не виртуалок, он априрори более гибкий. Для большинства приложений можно разработать скрипт, позволяющий перевести его работу на другой хост.
к одному файлохрану
http://www.vmware.com/ru/products/vi/storage_vmotion_overvie...
один линукс, много приложений
как это поможет в случае Microsoft Dynamix AX? Ну или поставим вопрос так - у Axapta есть аналоги под Linux, чтобы сказать бизнесу - "да в дупу этот хвалёный майкрософт - ща поставим ИМЯРЁК из репозитория и всё будет отлично"?
можно разработать скрипт
Скрипты - это отлично! Когда есть время их писать и отлаживать. VMWare/Hyper-V позволяют достичь HA "здесь и сейчас".
только с точки зрения финансовых директоров. Настроить фейлсейф можно и самостоятельно. Всё необходимое есть.Угу, поддерживать и обновлять тоже придётся самостоятельно. А ставить рабочий процесс в зависимость от одного человека - не айс как-то. Хотя, к примеру, против Red Hat Cluster Suite мугамбо не имеет ничего против
.
во-первых, тот же motion не идеален, он работает только если обе точки имеют доступ к одному файлохрану, где и лежит виртуалка.
Отказоустйчивый кластер на VSphere по-любому потребует shared storage.
Для большинства приложений можно разработать скрипт, позволяющий перевести его работу на другой хост.
Эк сказал - "для большинства". А кто его считал, то большинство-то? И что делать, если не входит нужное приложение в это большинство?
Кто будет поддерживать разработанный скрипт, тестить на совместимость с обновлениями?
как это поможет в случае Microsoft Dynamix AX?совсем упустил из виду. Если вы уже сидите на проприетарных продуктах, то, чтобы получать по-прежнему удобный севрис, вам нужно тратить и тратить на другие проприетарные технологии. В том весь смысл проприетарщины - за коготок утащить всю птичку. В этом случае, разумеется, выбора нет.
VMWare - не эмулятор, это паравиртуализаторVMWare это гипервизор. И паравиртуализацию оно, кстате, не использует. Гостевые ОС под него специально готовить не надо.
и в самом деле. Когда-то вики под паравиртуализацией подразумевала то, что ты назвал сейчас гипервизором, теперь вот название сменилось.
Существуется несколько способов виртуализации и большое количество решений. Выбор варианта виртуализации зависит от первоначальных требований.
На мой взгляд, одними из основных факторов являются:
-типы используемых ОС
-необходимость масштабирования
-необходимость быстрого переноса сервисов на другой физический сервер
Особенности реализации являются вторичными.
По ссылке приведены данные сравнительного тестирования различных виртуальных машин:
http://ru.wikipedia.org/wiki/Сравнение_виртуальных_машин
На мой взгляд, одними из основных факторов являются:
-типы используемых ОС
-необходимость масштабирования
-необходимость быстрого переноса сервисов на другой физический сервер
Особенности реализации являются вторичными.
По ссылке приведены данные сравнительного тестирования различных виртуальных машин:
http://ru.wikipedia.org/wiki/Сравнение_виртуальных_машин
Вики такая вики.
VMware Server — существенные потери и ограничения.
Virtual PC 2007 — практически без потерь, если используются расширения Virtual Machine additions.
Если вкратце, kvm/vbox - поделия, дальше десктопа места определенно не заслуживающие, виртуалбокс по сути для серверов не предназначен, квм крив и неудобен в серверной среде. Вмваре - гнилое проприетарное говно с аццким оверхедом, впрочем, мегаудобное и не требующее ничего, кроме дежурной обезьяны. Для виртхостинга есть поделие от параллельсов и замечательный опенвз, оба прекрасно удовлетворяют задачам класса "напихать стопицот слабеньких контейнеров с ламп на тачку". Для энтерпрайзной виртуализации - citrix xenserver, для наколенной энтерпрайзной виртуализации - xen, в первом все уже есть из коробки, второй проще подпилить под свои нужды. У ксена нет никакого оверхеда на дисковых операциях в паравиртуализованных доменах, в отличие от вмвари, есть адекватная миграция, в четверке масса вкусностей появилась.. Кто-нибудь с анлимными ресурсами, возможно, выберет esx, но это все уг - закрыто и нельзя что-то поправить, в случае появления серьезной проблемы.
Кто-нибудь с анлимными ресурсами, возможно, выберет esxНу или вообще не x86, а Integrity VM, IBM PowerVM или z/VM.
VMWare - не эмулятор, это паравиртуализатор. Для эффективной работы необходима поддержка паравиртуализации на уровне процессора, но даже современные десктопные, не говоря о серверных, это умеют. Она работает под (редхат) гну линуксом. Поставляется вместе с оным линуксом, так что настраивается только vmware, а линукс уже подогнан под него (редакция ESX сервер). Самостоятельные поделки виртуализации на базе известных решений (virtualbox OSE, KVM) и настроенного линукса консолидацией не являются, поскольку лишены отличительной особенности номер один (нездоровой впаривательной активности)Вообще-то VMWare не продукт, а компания. Соответственно, продуктов имеется несколько. В том числе:
VMWare Workstation - устанавливается на базе существующей ОС и позволяет внутри себя запускать виртуальные машины с другими ОС. Т.к. тоже самое, что и VirtualBox.
VMWare Server - нечто аналогичное Workstation, но уже снимаемое с поддержки и умирающее. Промежуточный продукт между Worstation и ESX(i).
VMWare ESX(i) - программный гипервизор. НЕ базируется на Linux. Является полностью проприетарным закрыми продуктом. Linux в нём используется как консоль управления в случае ESX. ESXi обходится без этой консоли и программным кодом мало отличается от старшего брата.
во-первых, тот же motion не идеален, он работает только если обе точки имеют доступ к одному файлохрану, где и лежит виртуалкаДобавлю, что ранее vmotion (онлайн миграция виртуальных машин с одного визического сервера на другой) и storage vmotion (перемещение файлов виртуальной машины между томами СХД) различались - теперь слились в одно и команда migrate в vCenter позволяет делать и то и другое, правда одновременная смена сервера и тома возможна только для выключенной ВМ, а по отдельности можно и онлайн.
VMWare активно разивает свой продукт и текущая 4-ая версия ESX vSphere имеет богатый набор API для интеграции со сторонним железом и софтом. В частности, ПО резервного копирования и API для работы с СХД. В сумме vAPI позволяют весьма существенно ускорить и упростить многие задачи.
НЕ базируется на Linux.то что запущено ядро линукса - не достаточно?
кстати, такой вот вопрос. Представим, что виндра работает поверх vmware на линуксе. Каждая операционная система имеет определённую сервисную IO активность: свопинг, кэширование, и собственно нормальную файловую активность. Как объяснить шедулеру винды, что он должен учитывать, что он не один, а поверх линукса? Что кешировать бесполезно - пусть лучше этим хостовая система займётся, что своп опять-таки лучше юзать хостовый и пореже. Как это обходят в случае массовой виртуализации, когда забить уже не получается из-за оверхеда?
Netware 6.5 видел? Хочешь сказать, оно тоже основано на MS-DOS?
то что запущено ядро линукса - не достаточно?Я не уверен, что там используется ядро линукса - иначе бы пришлось открывать исходники
. Линукс крутиться в отдельной сервисной ВМ для предоставления консольного доступа.кстати, такой вот вопрос. Представим, что виндра работает поверх vmware на линуксе. Каждая операционная система имеет определённую сервисную IO активность: свопинг, кэширование, и собственно нормальную файловую активность. Как объяснить шедулеру винды, что он должен учитывать, что он не один, а поверх линукса? Что кешировать бесполезно - пусть лучше этим хостовая система займётся, что своп опять-таки лучше юзать хостовый и пореже. Как это обходят в случае массовой виртуализации, когда забить уже не получается из-за оверхеда?
ОС внутри виртуальной машины принципиально не знает о том, что она такова. Поэтому её работа ничем не отличается от работы на обычном железе. Суть работы VMWare Workastation как раз в том, чтобы запросы виртуальной машины встроить в очередь запросов ОС, под которой сам Workstation крутиться. В случае ESX подход несколько иной.
3. В чем фишка использования виртуальных машин - почему нельзя "просто запустить несколько процессов" под "обычной" системой. Ведь наверняка же и сейчас например такие штуки как dns и dhcp и всякие шлюзы - реально выполняет один комп без множества виртуальных машин на нем на которых запущено по одному серверуНекоторые задачи принципиально не могут сосуществовать в пределах одной ОС. Особенно, если используется широкий парк ПО. Чтобы исключить взаимовлияние различных программных продуктов можно использовать и виртуализацию. Разнесение почтовых серверов, серверов БД, серверов резервного копирования, серверов телекоммуникаций и прочего - стандартная практика. Для отказоустойчивости каждый из них дублируется.В итогое количество железа становится слишком большим. Виртуализация становится неплохим решением.
Для задача разработки и тестирования виртуализация тоже хороший выход.
Как пример, у нас в лаборатории установлены 4 блейд-сервера, на которых живёт порядка 100 виртуалок (преимущественно Windows). Это позволяет нам демонстрировать на одном и том же железе порядка 30 различных стендов одновременно и без взаимного влияния друг на друга.
Т.е. на этих 4 физических серверах существуют одновременно порядка 4 различных доменов AD, пара-тройках независимых Exchange разных версий и куча различного софта, каждый со своей ОС.
Плюс мы делаем снэпшоты виртуальных машин перед серьёзной модификацией онных, что позволяет быстро откатываться, не восстанавливаясь из резервной копии.
то что запущено ядро линукса - не достаточно?
Architecture
VMware states that the ESX product runs on "bare metal".In contrast to other VMware products, it does not run atop a third-party operating system, but instead includes its own kernel. Up through the current ESX version 4.0, a Linux kernel is started first, and is used to load a variety of specialized virtualization components, including VMware's 'vmkernel' component. This previously-booted Linux kernel then becomes the first running virtual machine and is called the service console. Thus, at normal run-time, the vmkernel is running on the bare computer and the Linux-based service console runs as the first virtual machine.
The vmkernel itself, which VMware says is a microkernel,[6] has three interfaces to the outside world:
hardware
guest systems
service console (Console OS)
Source
ОС внутри виртуальной машины принципиально не знает о том, что она такова. Поэтому её работа ничем не отличается от работы на обычном железе.и что теперь, позволить её тормозить, потому что она путает реальное и виртуальное железо? Должны же быть какие-то настройки шедулера чтобы кастомизировать его поведение в правильном направлении
Плюс мы делаем снэпшоты виртуальных машин перед серьёзной модификацией онных, что позволяет быстро откатываться, не восстанавливаясь из резервной копии.снапшотить можно и через lvm. Приэтом unionfs позволяет в одном корне собрать несколько разных дисков (в соответствии с сервисами) и снапшотить по-отдельности эти диски. Другое дело, что идеальное решение, но недостижимое, не весь софт ещё есть под линукс, нет и нормальных методов управления линуксом. Но я верю, что когда-нибудь подходящий для такой работы дистрибутив появится.
клёво. Раньше линукс юзался для работы с реальным девайсами. Сейчас видимо продвинулось дело до того, что линукс работает только с виртуальным железом.
VMWare Server - нечто аналогичное Workstation, но уже снимаемое с поддержки и умирающее.Откуда дровишки?
Блин. Спасибо. Да, на офсайте тоже есть инфа.
Гартнер о виртуализации:
Представим, что виндра работает поверх vmware на линуксе.
Как объяснить шедулеру винды, что он должен учитывать, что он не один, а поверх линукса?
А что он такого делает, чтобы учитывать? Сторонний шедулер опять же не запрещается.
Что кешировать бесполезно
Это же всё можно выключить в винде.
что своп опять-таки лучше юзать хостовый и пореже
Так тогда вообще своп в виртуальной оси надо выключить, а памяти выставить с запасом (виртуалка ведь наверняка умеет выделать память динамически под реально используемое виртуальной осью значение, а лучше, если она вообще будет выставлять для виртуальной оси памяти пропорционально её потребностям). Ну или сделать для свапа отдельный рамдиск.
Некоторые задачи принципиально не могут сосуществовать в пределах одной ОС. Особенно, если используется широкий парк ПО. Чтобы исключить взаимовлияние различных программных продуктов можно использовать и виртуализацию.
Мне всегда казалось, что прежде всего виртуализация придумана для проприетарном ПО. Например SAP одно время принципиально не уживалось на одном сервере с 1С, при чём службы сопровождения обеих компаний делали большие глаза и валили всё на конкурентов.
К тому же некоторые версии успешно внедрённых проприетарных продуктов работают ислючительно под NT 4 или даже под Novell и DOS. Держать для этих приложений старый жрущий электричество и физически устаревший сервер не очень то рационально.
Мне всегда казалось, что прежде всего виртуализация придумана для проприетарном ПО.New-Penny.
Оставить комментарий
PaLbI4
на основе использованию продукта от VM Wareя как понимаю, например: есть большая компания с развитой сетью (сервера хранения данных, принт серверы, серверы управляющие самой сетью, почтовый сервер и все такое - что там еще бывает?)
В итоге физически серверов скапливается довольно много.
Теперь закупаются более мощные машины и на них запускается несколько виртуальных машин - каждая работает по отдельности как самостоятельный сервер, хотя физически машина одна.
Собственно вопросы:
1. Правильно ли я понимаю суть проблемы и решение - как я описал выше?
2. VM Ware - как я понимаю это программа эмулятор - и работает она под какой то осью?
3. В чем фишка использования виртуальных машин - почему нельзя "просто запустить несколько процессов" под "обычной" системой. Ведь наверняка же и сейчас например такие штуки как dns и dhcp и всякие шлюзы - реально выполняет один комп без множества виртуальных машин на нем на которых запущено по одному серверу