Вышел пакет обновлений u4 для ESX3.5.
Expanded Support for Enhanced vmxnet Adapter — This version of ESX Server includes an updated version of the VMXNET driver (VMXNET enhanced) for the following guest operating systems:
Microsoft Windows Server 2003, Standard Edition (32-bit)
Microsoft Windows Server 2003, Standard Edition (64-bit)
Microsoft Windows Server 2003, Web Edition
Microsoft Windows Small Business Server 2003
Microsoft Windows XP Professional (32-bit)
The new VMXNET version improves virtual machine networking performance and requires VMware tools upgrade.
Enablement of Intel Xeon Processor 5500 Series — Support for the Xeon processor 5500 series has been added. Support includes Enhanced VMotion capabilities. For additional information on previous processor families supported by Enhanced VMotion, see Enhanced VMotion Compatibility (EVC) processor support (KB 1003212).
QLogic Fibre Channel Adapter Driver Update — The driver and firmware for the QLogic fibre channel adapters have been updated to version 7.08-vm66 and 4.04.06 respectively. This release provides interoperability fixes for QLogic Management Tools for FC Adapters and enhanced NPIV support.
Emulex Fibre Channel Adapter Driver Update — The driver for Emulex Fibre Channel Adapters has been upgraded to version 7.4.0.40. This release provides support for the HBAnyware 4.0 Emulex management suite.
LSI megaraid_sas and mptscsi Storage Controller Driver Update — The drivers for LSI megaraid_sas and mptscsi storage controllers have been updated to version 3.19vmw and 2.6.48.18 vmw respectively. The upgrade improves performance and enhance event handling capabilities for these two drivers.
Newly Supported Guest Operating Systems — Support for the following guest operating systems has been added specifically for this release:
For more complete information about supported guests included in this release, see the Guest Operating System Installation Guide: http://www.vmware.com/pdf/GuestOS_guide.pdf.
SUSE Linux Enterprise Server 11 (32-bit and 64-bit).
SUSE Linux Enterprise Desktop 11 (32-bit and 64-bit).
Ubuntu 8.10 Desktop Edition and Server Edition (32-bit and 64-bit).
Windows Preinstallation Environment 2.0 (32-bit and 64-bit).
Furthermore, pre-built kernel modules (PBMs) were added in this release for the following guests:
Ubuntu 8.10
Ubuntu 8.04.2
Newly Supported Management Agents — Refer to VMware ESX Server Supported Hardware Lifecycle Management Agents for the most up-to-date information on supported management agents.
Newly Supported I/O Devices — in-box support for the following on-board processors, IO devices, and storage subsystems:
SAS Controllers and SATA Controllers:
The following are newly supported SATA Controllers.
PMC 8011 (for SAS and SATA drives)
Intel ICH9
Intel ICH10
CERC 6/I SATA/SAS Integrated RAID Controller (for SAS and SATA drivers)
HP Smart Array P700m Controller
Notes:
Some limitations apply in terms of support for SATA controllers. For more information, see SATA Controller Support in ESX 3.5 (KB 1008673).
Storing VMFS datastores on native SATA drives is not supported.
Network Cards: The following are newly supported network interface cards:
HP NC375i Integrated Quad Port Multifunction Gigabit Server Adapter
HP NC362i Integrated Dual port Gigabit Server Adapter
Intel 82598EB 10 Gigabit AT Network Connection
HP NC360m Dual 1 Gigabit/NC364m Quad 1 Gigabit
Intel Gigabit CT Desktop Adapter
Intel 82574L Gigabit Network Connection
Intel 10 Gigabit XF SR Dual Port Server Adapter
Intel 10 Gigabit XF SR Server Adapter
Intel 10 Gigabit XF LR Server Adapter
Intel 10 Gigabit CX4 Dual Port Server Adapter
Intel 10 Gigabit AF DA Dual Port Server Adapter
Intel 10 Gigabit AT Server Adapter
Intel 82598EB 10 Gigabit AT CX4 Network Connection
NetXtreme BCM5722 Gigabit Ethernet
NetXtreme BCM5755 Gigabit Ethernet
NetXtreme BCM5755M Gigabit Ethernet
NetXtreme BCM5756 Gigabit Ethernet
Expanded Support: The E1000 Intel network interface card (NIC) is now available for NetWare 5 and NetWare 6 guest operating systems.
Onboard Management Processors:
IBM system management processor (iBMC)
Storage Arrays:
SUN StorageTek 2530 SAS Array
Sun Storage 6580 Array
Sun Storage 6780 Array
вторник, 31 марта 2009 г.
понедельник, 30 марта 2009 г.
"Композитная" виртуальная машина
Один из часто задаваемых вопросов касается "композитной" виртуальной машины. "Можно ли сделать так, чтобы ресурсы двух хостов ESX объединить в одну виртуальную машину?"
Нет, нельзя. Почему?
Кластерные суперкомпьютеры, которые позволяют "объединять" ресурсы множества узлов, строятся под задачи. ПО для работы на этих суперкомпьютерах разрабатывается специально, с учетом всех их особенностей.
Виртуальные машины в общем случае - это универсальное и неспециализированное ПО, которое даже понятия не имеет, что работает не на физическом железе. И ведет себя соответствующим образом.
Даже при использовании специальных высокоскоростных сетей, разработанных для суперкомпьютеров, задержки доступа составляют порядка микросекунды, в то время как задержка доступа к локальной памяти несколько наносекунд, т.е. объединение памяти физических машин в одну "композитную" выльется в 1000-кратное замедление скорости работы. Про процессорные шины и говорить не приходится. Да, пожалуй, если задаться подобной целью, то мы сможем в конечном итоге реализовать проект, который позволит на железе стоимостью сотни тысяч долларов создать виртуальную машину с производительностью на уровне 386 процессора. Извините, 32-процессорной машины с 386 процессорами.
Почему же все тогда говорят про "облако" и ресурсы по заказу? Все очень просто. Мы действительно может давать ресурсы по заказу и относиться к большому Fully automated DRS кластеру ESX как к облаку. Но при одном условии - каждая ВМ требует ресурсов, значительно меньших, чем ресурсы одного хоста. Как только уровень ресурсов становится сравним, облако рассеивается на отдельно стоящие хосты.
Виртуальные машины могут многое, и избавляют нас от многих забот, но они могут не все. И даже при всей автоматизации управления виртуальной инфраструктурой, не следует забывать то, что в первую очередь виртуальные машины - это консолидация серверов, деление ресурсов очень мощного хоста между виртуальными машинами. Если нам надо больше ресурсов для ВМ, чем есть у хоста, то вывод может быть только один - виртуализация здесь не нужна и проблемы с правильным проектированием, а не с недостатком возможностей платформы виртуализации.
Нет, нельзя. Почему?
Кластерные суперкомпьютеры, которые позволяют "объединять" ресурсы множества узлов, строятся под задачи. ПО для работы на этих суперкомпьютерах разрабатывается специально, с учетом всех их особенностей.
Виртуальные машины в общем случае - это универсальное и неспециализированное ПО, которое даже понятия не имеет, что работает не на физическом железе. И ведет себя соответствующим образом.
Даже при использовании специальных высокоскоростных сетей, разработанных для суперкомпьютеров, задержки доступа составляют порядка микросекунды, в то время как задержка доступа к локальной памяти несколько наносекунд, т.е. объединение памяти физических машин в одну "композитную" выльется в 1000-кратное замедление скорости работы. Про процессорные шины и говорить не приходится. Да, пожалуй, если задаться подобной целью, то мы сможем в конечном итоге реализовать проект, который позволит на железе стоимостью сотни тысяч долларов создать виртуальную машину с производительностью на уровне 386 процессора. Извините, 32-процессорной машины с 386 процессорами.
Почему же все тогда говорят про "облако" и ресурсы по заказу? Все очень просто. Мы действительно может давать ресурсы по заказу и относиться к большому Fully automated DRS кластеру ESX как к облаку. Но при одном условии - каждая ВМ требует ресурсов, значительно меньших, чем ресурсы одного хоста. Как только уровень ресурсов становится сравним, облако рассеивается на отдельно стоящие хосты.
Виртуальные машины могут многое, и избавляют нас от многих забот, но они могут не все. И даже при всей автоматизации управления виртуальной инфраструктурой, не следует забывать то, что в первую очередь виртуальные машины - это консолидация серверов, деление ресурсов очень мощного хоста между виртуальными машинами. Если нам надо больше ресурсов для ВМ, чем есть у хоста, то вывод может быть только один - виртуализация здесь не нужна и проблемы с правильным проектированием, а не с недостатком возможностей платформы виртуализации.
четверг, 26 марта 2009 г.
Кто такие Евангелисты
Александр Ложечкин, руководитель группы евангелистов Microsoft, прекрасно раскрыл тему.
"Итак, кто же такие евангелисты?
Евангелисты, если отбросить исконное значение этого слова, появились именно в сфере ИТ и это было, по моему мнению, вызвано недостаточной эффективностью работы традиционных методов продвижения продуктов и технологиях на техническую аудиторию. А в те времена в ИТ не было простых пользователей, вся сфера ИТ состояла только из технических профессионалов. Для этой аудитории рекламных листовок и традиционных маркетинговых материалов недостаточно и, чтобы убедить эту аудиторию, нужно без лишней рекламы откровенно рассказывать о достоинствах и недостатках своих продуктов и технологий, быть такими же, как эта аудитория, техническими специалистами, понимать их проблемы и говорить с ними на одном языке. Так и появились евангелисты – люди, работа которых находится на стыке между технологиями и маркетингом. Все технические евангелисты, которых я знаю – люди с большим опытом работы в этой сфере разработчиками, архитекторами, ИТ-профессионалами. Как правило, евангелистами они становятся потому, что им нравится и интересно не только изучать и внедрять современные технологии, но и интересно делиться своими знаниями с другими, выступать на конференциях, писать блоги, публиковать статьи и книги и т.д.
Что делают евангелисты и зачем?
Когда меня спрашивают, что является целью моей работы, то краткий ответ звучит так: моя цель – чтобы каждый разработчик ПО и каждый ИТ-профессионал в России был счастлив. А для достижения этой цели нужно изучать нашу аудиторию, понимать ее проблемы и нужды, нужно придумывать решения проблем и рассказывать о них широким аудиториям. Поскольку я знаю и верю, что технологии Microsoft являются лучшими из того, что сейчас есть на рынке, для достижения своей цели я и мои коллеги продвигаем наши технологии на рынок, но не путем донесения маркетинговых лозунгов, а путем рассказа о возможностях наших продуктов и способах их применения. При этом мы понимаем, что даже если бы у нас работало 100 евангелистов, мы вряд ли бы смогли дотянуться до каждого из сотен тысяч разработчиков и ИТ-профессионалов в России, поэтому помимо перечисленного выше в обязанности евангелиста входит и развитие сообществ пользователей наших продуктов, в которых посредством форумов, блогов, конференций, просто неформальных встреч пользователи наших продуктов могли бы обмениваться опытом их использования, помогать решать проблемы и тем самым, становиться более счастливыми!
Как измеряется успех работы евангелиста?
Для измерения работы евангелиста с учетом перечисленных выше целей используется 2 основных показателя: уровень удовлетворенности целевой аудитории и уровень использования технологий. Для измерения этих показателей используются регулярные социологические исследования. Важно отметить, что продажи не являются способом измерения работы евангелиста. И в Microsoft это сделано совершенно сознательно, чтобы ориентация на продажи не помешала бы евангелисту быть на 100% искренним. Да, возможно, это и негативно влияет на продажи в краткосрочной перспективе, но доверие нашей аудитории, которое мы, надеюсь, завоевываем таким образом, для нас гораздо ценнее. И, что очень важно, доверие пользователей приводит к гораздо большему эффекту в продажах в долгосрочной перспективе. Т.е., конечно евангелисты – не альтруисты."
"Итак, кто же такие евангелисты?
Евангелисты, если отбросить исконное значение этого слова, появились именно в сфере ИТ и это было, по моему мнению, вызвано недостаточной эффективностью работы традиционных методов продвижения продуктов и технологиях на техническую аудиторию. А в те времена в ИТ не было простых пользователей, вся сфера ИТ состояла только из технических профессионалов. Для этой аудитории рекламных листовок и традиционных маркетинговых материалов недостаточно и, чтобы убедить эту аудиторию, нужно без лишней рекламы откровенно рассказывать о достоинствах и недостатках своих продуктов и технологий, быть такими же, как эта аудитория, техническими специалистами, понимать их проблемы и говорить с ними на одном языке. Так и появились евангелисты – люди, работа которых находится на стыке между технологиями и маркетингом. Все технические евангелисты, которых я знаю – люди с большим опытом работы в этой сфере разработчиками, архитекторами, ИТ-профессионалами. Как правило, евангелистами они становятся потому, что им нравится и интересно не только изучать и внедрять современные технологии, но и интересно делиться своими знаниями с другими, выступать на конференциях, писать блоги, публиковать статьи и книги и т.д.
Что делают евангелисты и зачем?
Когда меня спрашивают, что является целью моей работы, то краткий ответ звучит так: моя цель – чтобы каждый разработчик ПО и каждый ИТ-профессионал в России был счастлив. А для достижения этой цели нужно изучать нашу аудиторию, понимать ее проблемы и нужды, нужно придумывать решения проблем и рассказывать о них широким аудиториям. Поскольку я знаю и верю, что технологии Microsoft являются лучшими из того, что сейчас есть на рынке, для достижения своей цели я и мои коллеги продвигаем наши технологии на рынок, но не путем донесения маркетинговых лозунгов, а путем рассказа о возможностях наших продуктов и способах их применения. При этом мы понимаем, что даже если бы у нас работало 100 евангелистов, мы вряд ли бы смогли дотянуться до каждого из сотен тысяч разработчиков и ИТ-профессионалов в России, поэтому помимо перечисленного выше в обязанности евангелиста входит и развитие сообществ пользователей наших продуктов, в которых посредством форумов, блогов, конференций, просто неформальных встреч пользователи наших продуктов могли бы обмениваться опытом их использования, помогать решать проблемы и тем самым, становиться более счастливыми!
Как измеряется успех работы евангелиста?
Для измерения работы евангелиста с учетом перечисленных выше целей используется 2 основных показателя: уровень удовлетворенности целевой аудитории и уровень использования технологий. Для измерения этих показателей используются регулярные социологические исследования. Важно отметить, что продажи не являются способом измерения работы евангелиста. И в Microsoft это сделано совершенно сознательно, чтобы ориентация на продажи не помешала бы евангелисту быть на 100% искренним. Да, возможно, это и негативно влияет на продажи в краткосрочной перспективе, но доверие нашей аудитории, которое мы, надеюсь, завоевываем таким образом, для нас гораздо ценнее. И, что очень важно, доверие пользователей приводит к гораздо большему эффекту в продажах в долгосрочной перспективе. Т.е., конечно евангелисты – не альтруисты."
вторник, 24 марта 2009 г.
Особенности Non-Persistent Pool в View
Исправляю свою старую ошибку относительно Non-Persistent Pool в этом посте.
"Выглядит примерно так же, как и Persistent, только с тем отличием, что все изменения на виртуальных машинах откатываются, а пары логин/машина не запоминаются."
На самом деле изменения никуда не откатываются, это уже дело доменного администратора спланировать архитектуру так, чтобы пользователю было все равно на какой машине работать. Например, за счет использования Roaming Profiles.
Тем не менее, есть опция, которая позволяет гарантировать, что при логине пользователь будет получать девственно чистую машину. Эта опция называется "Delete VM on logoff". При завершении сессии и выходе ВМ удаляется, а на ее место разворачивается новая из шаблона.
"Выглядит примерно так же, как и Persistent, только с тем отличием, что все изменения на виртуальных машинах откатываются, а пары логин/машина не запоминаются."
На самом деле изменения никуда не откатываются, это уже дело доменного администратора спланировать архитектуру так, чтобы пользователю было все равно на какой машине работать. Например, за счет использования Roaming Profiles.
Тем не менее, есть опция, которая позволяет гарантировать, что при логине пользователь будет получать девственно чистую машину. Эта опция называется "Delete VM on logoff". При завершении сессии и выходе ВМ удаляется, а на ее место разворачивается новая из шаблона.
понедельник, 23 марта 2009 г.
Veeam Backup 3
Инженеры компании Veeam зарабатывают на свой хлеб с маслом, выпуская продукты, упрощающие жизнь администратору VMware Virtual Infrastructure. И надо сказать, что очень достойные продукты.
Хочу рассказать об интересных особенностях их нового продукта, Veeam Backup 3.0.
В чем же его отличие от бесплатного VCB?
Прежде всего, это полноценный и удобный GUI, причем совмещен инструмент как резервного копирования, так и восстановления.
Veeam Backup
1) работает с ESXi, включая бесплатный.
2) способен работать как самостоятельно, так и в паре с VCB, снимая дополнительную нагрузку с ESX сервера.
3) поддерживает Microsoft VSS.
4) поддерживается восстановление отдельных файлов для файловых систем FAT & NTFS.
5) Клиент Veeam Backup одновременно является и FastSCP. Или наоборот, кому как нравится :)
Помимо всего прочего, Veeam Backup презентуется как решение с "синтетическим" бэкапом. Чем же синтетический отличается от привычных дифференциального и инкрементального?
Полный бэкап - определение самоочевидно :)
Дифференциальный бэкап - в бэкап записываются данные, измененные со времени последнего полного бэкапа.
Инкрементальный бэкап - в бэкап записываются данные, измененные со времени последнего любого бэкапа.
Преимущества полного бэкапа очевидны - наискорейшее восстановление, но он требует больше всего места. Дифференциальный бэкап требует для восстановления два бэкапа - собственно дифференциальный и полный, что несколько замедляет сам процесс бэкапа, но требует меньше места, чем для полного. Недостаток дифференциального в том, что при нескольких последовательных дифференциальных бэкапах идет расход места под одни и те же изменения, входящие в каждый дифференциальный бэкап. Наименее требователен к месту инкрементальный, но он же самый медленный для восстановления и самый чувствительный к повреждениям резервных копий и вообще их наличию.
Синтетический бэкап, используемый в Veeam Backup - это инкрементальный бэкап наоборот. После первого полного бэкапа остальные идут как инкрементальные, но(!) вместо того, чтобы записывать на диск инкрементальный бэкап, все переворачивается с ног на голову. Инкрементальный бэкап используется для обновления состояния полного бэкапа, а пишутся на диск обратные инкрементальные изменения. Что это дает?
Наиболее востребована только последняя сделанная копия, ибо, что вполне логично, нам требуется наиболее свежее состояние системы. При прямом инкрементальном бэкапе нам надо взять последний полный бэкап и последовательно накатить на него все инкрементальные изменения (или одно дифференциальное). Здесь же, в синтетическом (обратном инкрементальном) бэкапе, последняя актуальная копия всегда является полной. И только если вдруг нам потребуется копия более ранняя, придется накатить на полный бэкап обратные инкременты.
Одно из несомненных достоинств Veeam Backup - дедупликация данных "на лету" при бэкапе, и интегрированный механизм компресии самих файлов бэкапов.
Все это прекрасно, спору нет. Вопрос о цене.
Veeam Backup лицензируется по количеству сокетов обслуживаемой инфраструктуры ESX серверов. Цена лицензии $550 за сокет, поддержка 5*8 на год включена в лицензию, дополнительная поддержка 5*8 стоит 120$ в год за сокет.
Хочу рассказать об интересных особенностях их нового продукта, Veeam Backup 3.0.
В чем же его отличие от бесплатного VCB?
Прежде всего, это полноценный и удобный GUI, причем совмещен инструмент как резервного копирования, так и восстановления.
Veeam Backup
1) работает с ESXi, включая бесплатный.
2) способен работать как самостоятельно, так и в паре с VCB, снимая дополнительную нагрузку с ESX сервера.
3) поддерживает Microsoft VSS.
4) поддерживается восстановление отдельных файлов для файловых систем FAT & NTFS.
5) Клиент Veeam Backup одновременно является и FastSCP. Или наоборот, кому как нравится :)
Помимо всего прочего, Veeam Backup презентуется как решение с "синтетическим" бэкапом. Чем же синтетический отличается от привычных дифференциального и инкрементального?
Полный бэкап - определение самоочевидно :)
Дифференциальный бэкап - в бэкап записываются данные, измененные со времени последнего полного бэкапа.
Инкрементальный бэкап - в бэкап записываются данные, измененные со времени последнего любого бэкапа.
Преимущества полного бэкапа очевидны - наискорейшее восстановление, но он требует больше всего места. Дифференциальный бэкап требует для восстановления два бэкапа - собственно дифференциальный и полный, что несколько замедляет сам процесс бэкапа, но требует меньше места, чем для полного. Недостаток дифференциального в том, что при нескольких последовательных дифференциальных бэкапах идет расход места под одни и те же изменения, входящие в каждый дифференциальный бэкап. Наименее требователен к месту инкрементальный, но он же самый медленный для восстановления и самый чувствительный к повреждениям резервных копий и вообще их наличию.
Синтетический бэкап, используемый в Veeam Backup - это инкрементальный бэкап наоборот. После первого полного бэкапа остальные идут как инкрементальные, но(!) вместо того, чтобы записывать на диск инкрементальный бэкап, все переворачивается с ног на голову. Инкрементальный бэкап используется для обновления состояния полного бэкапа, а пишутся на диск обратные инкрементальные изменения. Что это дает?
Наиболее востребована только последняя сделанная копия, ибо, что вполне логично, нам требуется наиболее свежее состояние системы. При прямом инкрементальном бэкапе нам надо взять последний полный бэкап и последовательно накатить на него все инкрементальные изменения (или одно дифференциальное). Здесь же, в синтетическом (обратном инкрементальном) бэкапе, последняя актуальная копия всегда является полной. И только если вдруг нам потребуется копия более ранняя, придется накатить на полный бэкап обратные инкременты.
Одно из несомненных достоинств Veeam Backup - дедупликация данных "на лету" при бэкапе, и интегрированный механизм компресии самих файлов бэкапов.
Все это прекрасно, спору нет. Вопрос о цене.
Veeam Backup лицензируется по количеству сокетов обслуживаемой инфраструктуры ESX серверов. Цена лицензии $550 за сокет, поддержка 5*8 на год включена в лицензию, дополнительная поддержка 5*8 стоит 120$ в год за сокет.
пятница, 20 марта 2009 г.
Template & Domain
Вопрос: присоединять Windows ВМ к домену перед ее превращением в шаблон или оставить в рабочей группе?
Ответ: Если присоединить ВМ к домену до запуска sysprep, то членство в домене будет потеряно. Если присоединить ВМ к домену после запуска sysprep, то по истечению некоторого срока (30 дней по умолчанию) временные пароли для создания защищенного канала с контроллером домена потеряют актуальность и членство в домене снова будет потеряно.
Поэтому лучше оставить машину в рабочей группе и присоединять к домену во время развертывания из шаблона используя механизм customization.
Ответ: Если присоединить ВМ к домену до запуска sysprep, то членство в домене будет потеряно. Если присоединить ВМ к домену после запуска sysprep, то по истечению некоторого срока (30 дней по умолчанию) временные пароли для создания защищенного канала с контроллером домена потеряют актуальность и членство в домене снова будет потеряно.
Поэтому лучше оставить машину в рабочей группе и присоединять к домену во время развертывания из шаблона используя механизм customization.
четверг, 19 марта 2009 г.
ESX и USB для ВМ
Один из наиболее задаваемых вопросов про ESX(i) - когда VMware сделает возможным использование host USB в ВМ на ESX.
Отвечаю: никогда.
Объясняю: концепция использования ВМ в среде Virtual Infrastructire, т.е. на ESX(i) серверах предполагает, что каждый ESX хост является донором лишь трех возможных ресурсов - времени процессора, мегабайтов оперативной памяти и мегабитов сетевого соединения. Почему только так? Просто потому что VI - это платформа виртуализации, вышедшая из первого поколения (консолидации) довольно давно, и ВМ не привязана к какому-то конкретному хосту. DRS и VMotion + разделяемое хранилище дают прозрачное перемещение ВМ в пределах кластера.
- Где у вас находятся эти виртуальные машины? - (строгий аудит)
- Где-то тут. - (сисадмин обводит рукой стойку с серверами)
- Как, Вы не знаете где они работают?!
- А разве это так важно?
С появлением ESXi Embedded ввод в строй новых хостов еще более упростился и приближается к концепции анонимных хостов. А вся система приближается к модному в этом сезоне термину - "облаку". Нас реально не волнует как там что устроено внутри, оно просто работает.
Почему здесь нет места USB? А просто потому что использование портов хоста жестко привязывает ВМ к хосту. Она больше не может никуда мигрировать. Она даже не перезапустится в HA кластере при смерти хоста, на котором выполнялась - ведь нужный ей порт USB вместе с USB ключом, или что там было подключено, находится на недоступном хосте.
Итог: если Вам действительно нужны USB порты в ВМ, то у Вас есть два возможных варианта при работе с VMware VI. В любом случае Вы добавляете в инфраструктуру отдельный хост и:
1) Устанавливаете на нем VMware Server, который прекрасно работает с хостовым USB, и запускаете серверы лицензий и тому подобные машины с необходимостью наличия USB под VMware Server.
2) Устанавливаете дополнительные USB контроллеры в нужном количестве и запускаете хост-сервис USB-over-IP на этой машине. После чего пробрасываете USB в нужные виртуальные машины по сети. Но в этом случае Вам будет необходимо купить соответствующий продукт, благо их в настоящее время достаточно широкий выбор.
Отвечаю: никогда.
Объясняю: концепция использования ВМ в среде Virtual Infrastructire, т.е. на ESX(i) серверах предполагает, что каждый ESX хост является донором лишь трех возможных ресурсов - времени процессора, мегабайтов оперативной памяти и мегабитов сетевого соединения. Почему только так? Просто потому что VI - это платформа виртуализации, вышедшая из первого поколения (консолидации) довольно давно, и ВМ не привязана к какому-то конкретному хосту. DRS и VMotion + разделяемое хранилище дают прозрачное перемещение ВМ в пределах кластера.
- Где у вас находятся эти виртуальные машины? - (строгий аудит)
- Где-то тут. - (сисадмин обводит рукой стойку с серверами)
- Как, Вы не знаете где они работают?!
- А разве это так важно?
С появлением ESXi Embedded ввод в строй новых хостов еще более упростился и приближается к концепции анонимных хостов. А вся система приближается к модному в этом сезоне термину - "облаку". Нас реально не волнует как там что устроено внутри, оно просто работает.
Почему здесь нет места USB? А просто потому что использование портов хоста жестко привязывает ВМ к хосту. Она больше не может никуда мигрировать. Она даже не перезапустится в HA кластере при смерти хоста, на котором выполнялась - ведь нужный ей порт USB вместе с USB ключом, или что там было подключено, находится на недоступном хосте.
Итог: если Вам действительно нужны USB порты в ВМ, то у Вас есть два возможных варианта при работе с VMware VI. В любом случае Вы добавляете в инфраструктуру отдельный хост и:
1) Устанавливаете на нем VMware Server, который прекрасно работает с хостовым USB, и запускаете серверы лицензий и тому подобные машины с необходимостью наличия USB под VMware Server.
2) Устанавливаете дополнительные USB контроллеры в нужном количестве и запускаете хост-сервис USB-over-IP на этой машине. После чего пробрасываете USB в нужные виртуальные машины по сети. Но в этом случае Вам будет необходимо купить соответствующий продукт, благо их в настоящее время достаточно широкий выбор.
пятница, 13 марта 2009 г.
RTFM: DHCP
По просьбам некоторых трудящихся попробую начать писать о базовых понятиях и сервисах для одминов. Одним из основополагающих сервисов сети является сервис DHCP.
DHCP — это Dynamic host configuration protocol, протокол динамического конфигурирования хостов. Вопреки распространенному мнению, DHCP позволяет конфигурировать гораздо более широкий спектр параметров, чем просто IP-адрес и шлюз по умолчанию: DNS-серверы, WINS-серверы, серверы X-Window по умолчанию, имя хоста и прочее и прочее. Но как же работает основная часть DHCP — та, которая выдает устройству адрес при подключении к сети?
Работа DHCP происходит в несколько этапов:
1. Устройство подключается к сети и отправляет запрос DHCP DISCOVER на широковещательный адрес 255.255.255.255. Этот пакет доставляется всем компьютерам, находящимся в данном сегменте сети, но обрабатывают его только DHCP-серверы.
2. Все DHCP-серверы сети, получившие этот запрос, выдают на него ответ DHCP OFFER, который уже адресуется MAC-адресу устройства, отправившего DHCP DISCOVER. В этом пакете серверы предлагают клиенту возможные варианты IP-адресов.
3. Клиент выбирает наилучший, по его мнению, IP-адрес и посылает широковещательный запрос DHCP REQUEST, запрашивая выбранный IP адрес. Если в сети несколько DHCP серверов, то таким образом информируются серверы, чье предложение отвергнуто.
4. Сервер подтверждает аренду адреса сообщением DHCP ACK, сообщая о том, что отныне этот адрес закрепляется за клиентом на все «время аренды» (lease time). Либо, если адрес более недоступен, DHCP сервер отвечает DHCP NACK и весь процесс повторяется сначала.
5. По истечению половины срока аренды, клиент снова подтверждает использование IP адреса пакетом DHCP REQUEST, но в отличие от пункта 3, в этот раз напрямую DHCP серверу, а не широковещательным. На этот запрос сервер может как согласиться DHCP ACK, так и отказать DHCP NACK. В случае отказа клиент теряет свой адрес и проходит процедуру заново.
Процесс легко запомнить по аббревиатуре DORA: Discover-Offer-Request-Acknowledge
Причем тут виртуальные машины, спросите вы? Виртуальным машинам тоже нужны IP адреса, да и DHCP серверы прекрасно себя чувствуют в виртуальных машинах :)
DHCP — это Dynamic host configuration protocol, протокол динамического конфигурирования хостов. Вопреки распространенному мнению, DHCP позволяет конфигурировать гораздо более широкий спектр параметров, чем просто IP-адрес и шлюз по умолчанию: DNS-серверы, WINS-серверы, серверы X-Window по умолчанию, имя хоста и прочее и прочее. Но как же работает основная часть DHCP — та, которая выдает устройству адрес при подключении к сети?
Работа DHCP происходит в несколько этапов:
1. Устройство подключается к сети и отправляет запрос DHCP DISCOVER на широковещательный адрес 255.255.255.255. Этот пакет доставляется всем компьютерам, находящимся в данном сегменте сети, но обрабатывают его только DHCP-серверы.
2. Все DHCP-серверы сети, получившие этот запрос, выдают на него ответ DHCP OFFER, который уже адресуется MAC-адресу устройства, отправившего DHCP DISCOVER. В этом пакете серверы предлагают клиенту возможные варианты IP-адресов.
3. Клиент выбирает наилучший, по его мнению, IP-адрес и посылает широковещательный запрос DHCP REQUEST, запрашивая выбранный IP адрес. Если в сети несколько DHCP серверов, то таким образом информируются серверы, чье предложение отвергнуто.
4. Сервер подтверждает аренду адреса сообщением DHCP ACK, сообщая о том, что отныне этот адрес закрепляется за клиентом на все «время аренды» (lease time). Либо, если адрес более недоступен, DHCP сервер отвечает DHCP NACK и весь процесс повторяется сначала.
5. По истечению половины срока аренды, клиент снова подтверждает использование IP адреса пакетом DHCP REQUEST, но в отличие от пункта 3, в этот раз напрямую DHCP серверу, а не широковещательным. На этот запрос сервер может как согласиться DHCP ACK, так и отказать DHCP NACK. В случае отказа клиент теряет свой адрес и проходит процедуру заново.
Процесс легко запомнить по аббревиатуре DORA: Discover-Offer-Request-Acknowledge
Причем тут виртуальные машины, спросите вы? Виртуальным машинам тоже нужны IP адреса, да и DHCP серверы прекрасно себя чувствуют в виртуальных машинах :)
среда, 11 марта 2009 г.
ESXi - сохранение и восстановление конфигурации
Иногда надо просто полностью сохранить конфигурацию хоста. Пришлось и мне этим заняться, ибо приехали флэшки на замену в бездисковые ESXi. Заниматься переконфигурированием хостов совсем не хотелось. Использован пакет VMware RCLI.
Бэкап:
C:\Program Files\VMware\VMware VI Remote CLI\bin>vicfg-cfgbackup.pl --server esxN.domain.com --username root --password secretpass -s r:\esxN.cfg
Saving firmware configuration to r:\esxN.cfg...
После этого делаем для хоста disconnect в vCenter
Восстановление:
C:\Program Files\VMware\VMware VI Remote CLI\bin>vicfg-cfgbackup.pl --server esxN.domain.com --username root --password secretpass -l r:\esxN.cfg
The restore operation will reboot the host.
Type 'yes' to continue:
yes
Uploading config bundle to configBundle.tgz ...
Performing restore ...
После того как хост перезагрузится, выполняем connect в vCenter
Перед восстановлением необходимо сконфигурировать Management Network по вполне очевидным причинам. Для бэкапа и восстановления режим Lockdown должен быть отключен!
Бэкап:
C:\Program Files\VMware\VMware VI Remote CLI\bin>vicfg-cfgbackup.pl --server esxN.domain.com --username root --password secretpass -s r:\esxN.cfg
Saving firmware configuration to r:\esxN.cfg...
После этого делаем для хоста disconnect в vCenter
Восстановление:
C:\Program Files\VMware\VMware VI Remote CLI\bin>vicfg-cfgbackup.pl --server esxN.domain.com --username root --password secretpass -l r:\esxN.cfg
The restore operation will reboot the host.
Type 'yes' to continue:
yes
Uploading config bundle to configBundle.tgz ...
Performing restore ...
После того как хост перезагрузится, выполняем connect в vCenter
Перед восстановлением необходимо сконфигурировать Management Network по вполне очевидным причинам. Для бэкапа и восстановления режим Lockdown должен быть отключен!
четверг, 5 марта 2009 г.
Update: Hyper-V R2 & CSV
Уточнил ситуацию с поддержкой CSV у Андрея Бешкова.
Итак, Hyper-V R2 в бесплатной поставке будет поддерживать Failover Clustering и CSV. Довольно суровая штука получается даже в бесплатном варианте в таком случае.
Тем не менее, Citrix уже выпустила бесплатный XenServer5 в аналогичной комплектации (не считая отсутствия кластерной FS). И еще - не забывайте, что сравниваем мы пока продающийся уже несколько лет ESX 3 и Hyper-V R2, который пока даже не вышел, а случится это событие ближе к концу 2009 года. В 2009 же году выйдет и vSphere (VMware VI 4), о которой мы слышали много, но лишь о технологической стороне, цены не озвучивались никем. Так что у VMware еще есть время подумать и достойно ответить.
Итак, Hyper-V R2 в бесплатной поставке будет поддерживать Failover Clustering и CSV. Довольно суровая штука получается даже в бесплатном варианте в таком случае.
Тем не менее, Citrix уже выпустила бесплатный XenServer5 в аналогичной комплектации (не считая отсутствия кластерной FS). И еще - не забывайте, что сравниваем мы пока продающийся уже несколько лет ESX 3 и Hyper-V R2, который пока даже не вышел, а случится это событие ближе к концу 2009 года. В 2009 же году выйдет и vSphere (VMware VI 4), о которой мы слышали много, но лишь о технологической стороне, цены не озвучивались никем. Так что у VMware еще есть время подумать и достойно ответить.
вторник, 3 марта 2009 г.
Про лицензирование и $
Хочется поговорить о лицензировании и платном ПО. Зачастую вендоры делают все возможное, чтобы не дать пользоваться "пиратскими" экземплярами ПО, вынуждая заплатить. И ведь в итоге получается, что даже если ты заплатил и честно купил, то огребешь проблем со сложностью ввода серийников, активации и тому подобного. Доходило вплоть до того, что официальные представители 1С при обращении на тему проблем лицензионных ключей 1С:Предприятия, раздраженно бросали в телефонную трубку - да сломайте вы его и не парьте нам мозг.
У Миши Михеева была небольшая дискуссия в блоге относительно отправления Citrix XenServer в бесплатное плавание, и вопросы цен на лицензии и влияния цен на покупателей тоже были затронуты. Вынесу оттуда свой комментарий и раскрою его.
Я бы не был столь уверен в прогнозах потерь и вообще в экономической оценке действий Citrix, и влиянии этого на VMware. Если в ответ VMware резко удешевит VI Foundation, то это прежде всего ударит не по VMware, а по Microsoft, Citrix и всем остальным, кто грызется за SMB рынок. После долгого использования VMware ESX мало кто захочет мигрировать на конкурентов, предпочтут просто купить лицензии. Тем более, что VMware еще долго будет технологическим флагманом.
Не знаю, прав ли я в оценке действий VMware, но считаю лицензионную политику на WorkStation очень разумной. Как известно, активации не требуется, а кейгены лежат везде и всюду. Ключи не блокируются, алгоритмы расчет ключей тоже не меняются каждый месяц. Почему? Потому что:
1) не надо создавать проблем честным пользователям, купившим лицензию. Каждая загвоздка с лицензиями отвращает от продукта.
2) если человек не хочет покупать лицензию принципиально, то он ее и не купит, а дальше см. пункт 1.
3) если человек не уверен, хочет ли он покупать - то ему надо дать продукт и пусть он его крутит-вертит. Даже если он использует продукт, а именно WS без честной лицензии, то шансы продать ему лицензию рано или поздно на два порядка выше, чем если он изначально не поставил себе продукт из-за сложностей с лицензиями и ушел на конкурентный продукт, либо вообще бесплатный.
Увы, далеко не все менеджеры одинаково полезны для своих компаний. Вероятно, в большинство случаев перевешивает личное желание получить премию за увеличение продаж путем закручивания гаек, а вовсе не желание сохранить компанию лидером и получить достойные, но не не такие большие премиальные прямо сейчас. Любое закручивание гаек и проблемы отвращают конечных пользователей в лапы конкурентов, что в конечном итоге ведет к снижению продаж. Исключения составляют лишь те продукты, конкуренции которым не предвидится, либо стоимость перехода чересчур высока.
***
Содержание данного поста - личное мнение и никаким образом не отражает официальную (или неофициальную) позицию компании VMware.
У Миши Михеева была небольшая дискуссия в блоге относительно отправления Citrix XenServer в бесплатное плавание, и вопросы цен на лицензии и влияния цен на покупателей тоже были затронуты. Вынесу оттуда свой комментарий и раскрою его.
Я бы не был столь уверен в прогнозах потерь и вообще в экономической оценке действий Citrix, и влиянии этого на VMware. Если в ответ VMware резко удешевит VI Foundation, то это прежде всего ударит не по VMware, а по Microsoft, Citrix и всем остальным, кто грызется за SMB рынок. После долгого использования VMware ESX мало кто захочет мигрировать на конкурентов, предпочтут просто купить лицензии. Тем более, что VMware еще долго будет технологическим флагманом.
Не знаю, прав ли я в оценке действий VMware, но считаю лицензионную политику на WorkStation очень разумной. Как известно, активации не требуется, а кейгены лежат везде и всюду. Ключи не блокируются, алгоритмы расчет ключей тоже не меняются каждый месяц. Почему? Потому что:
1) не надо создавать проблем честным пользователям, купившим лицензию. Каждая загвоздка с лицензиями отвращает от продукта.
2) если человек не хочет покупать лицензию принципиально, то он ее и не купит, а дальше см. пункт 1.
3) если человек не уверен, хочет ли он покупать - то ему надо дать продукт и пусть он его крутит-вертит. Даже если он использует продукт, а именно WS без честной лицензии, то шансы продать ему лицензию рано или поздно на два порядка выше, чем если он изначально не поставил себе продукт из-за сложностей с лицензиями и ушел на конкурентный продукт, либо вообще бесплатный.
Увы, далеко не все менеджеры одинаково полезны для своих компаний. Вероятно, в большинство случаев перевешивает личное желание получить премию за увеличение продаж путем закручивания гаек, а вовсе не желание сохранить компанию лидером и получить достойные, но не не такие большие премиальные прямо сейчас. Любое закручивание гаек и проблемы отвращают конечных пользователей в лапы конкурентов, что в конечном итоге ведет к снижению продаж. Исключения составляют лишь те продукты, конкуренции которым не предвидится, либо стоимость перехода чересчур высока.
***
Содержание данного поста - личное мнение и никаким образом не отражает официальную (или неофициальную) позицию компании VMware.
Особенности "национальной" Live Migration
Прдставители Microsoft на всех конференциях рассказывают про обалденную новую фичу, Live Migration и в связи с ней Cluster Shared Volume (CSV). Говорят, Live Migration будет for free :) В конце 2009.
Самое смешное, что по сути for free оно не будет.
1) На весенней конференции Technet Live Migration Александр Шаповал показывал без всяких CSV, просто выделенный на машину LUN переключился на другой хост. Т.е. модель данных та же, что и была - нарезать LUN'ы на каждую машину десятками.
2) CSV будет поставляться как бесплатное расширение Failover Clustering, входящий в комплект Enterprise (ориентировочная цена 4k$ за хост).
Итого, что мы имеем? Live Migration на выделенных LUN'ах начиная с пары десятков машин уже совершенно нам неинтересен, а CSV требует денег. С другой стороны, у VMware VMFS бесплатно идет с ESXi. А вот VMotion надо покупать.
Сотрудники MS в чем-то правы, да, утверждая, что Live Migration нужен далеко не всем. Но вот самое смешное, что именно CSV нужен значительно большему количеству пользователей.
Каков финансовый итог? Считайте сами. Но не забывайте, что если верить громким рекламным заявлениям о бесплатности - платить придется трижды.
Самое смешное, что по сути for free оно не будет.
1) На весенней конференции Technet Live Migration Александр Шаповал показывал без всяких CSV, просто выделенный на машину LUN переключился на другой хост. Т.е. модель данных та же, что и была - нарезать LUN'ы на каждую машину десятками.
2) CSV будет поставляться как бесплатное расширение Failover Clustering, входящий в комплект Enterprise (ориентировочная цена 4k$ за хост).
Итого, что мы имеем? Live Migration на выделенных LUN'ах начиная с пары десятков машин уже совершенно нам неинтересен, а CSV требует денег. С другой стороны, у VMware VMFS бесплатно идет с ESXi. А вот VMotion надо покупать.
Сотрудники MS в чем-то правы, да, утверждая, что Live Migration нужен далеко не всем. Но вот самое смешное, что именно CSV нужен значительно большему количеству пользователей.
Каков финансовый итог? Считайте сами. Но не забывайте, что если верить громким рекламным заявлениям о бесплатности - платить придется трижды.
Подписаться на:
Сообщения (Atom)
Сообщения
