• Встреча VMware User Group Russia 2010-1

    VMware logo Коллеги, многие из вас были или читали (http://vsphere.vm4.ru/vmug) о таком мероприятии как встреча российской VMware User Group, VMUG.
    Само мероприятие представляет из себя встречу технических специалистов, которым интересна тема серверной и десктопной виртуализации во всевозможных ее проявлениях, но как понятно из названия, прежде всего в исполнении VMware 🙂
    Интересно оно, прежде всего, возможностью пообщаться на профессиональную тему с опытными людьми – как то так сложилось, что с этим на наших встречах все хорошо.
    Костяк же мероприятия составляет серия докладов.

    Инициативная группа в лице Антона Жбанкова и Михаила Михеева начинает организацию очередной встречи VMUG.

    Встреча пройдет в Москве 19 марта 2010 года. Программа встречи:

    9:20 Регистрация, кофе
    9:50 Открытие
    10:00 “Облачные вычисления” Антон Жбанков
    10:25 “Cisco Unified Computing System” Cisco
    11:10 “Сравнение гипервизоров” Денис Батурин
    11:40 “Как работает VMFS” Антон Жбанков
    12:15 обед
    13:15 “Решения IBM в области виртуализации” IBM
    14:00 “Доступность и безопасность виртуальной инфраструктуры – практическое руководство” Антон Жбанков, Сергей Щадных
    14:35 “Обеспечение отказоустойчивости виртуальных систем без разделяемых хранилищ” Сергей Щадных, Владимир Гуляев
    15:10 Кофе-брейк
    15:25 “Обзор Veeam Business View и Veeam Reporter” Veeam
    16:05 “Оптимизация продуктов Citrix под VMware” Денис Гундарев
    16:40 “Защита виртуальных сред” TrendMicro
    17:20 “Обзор VMware Orchestrator” Михаил Михеев
    17:50 Закрытие

    Регистрация на мероприятие здесь: http://www.vm4.ru/2010/02/vmug-2010.html
    Участие бесплатное.

  • Главная Virtualization, Windows, Без рубрики Virtualization, VMware, Windows 7, виртуализация
    • Как упаковать IE6 в ThinApp для запуска под Win7

      256px-VMware_ThinApp_logo_01_svg Peter Bjork опубликовал долгожданное многими руководство по упаковке IE6 в ThinApp пакет для Windows 7.

      Этот пакет использует Mozilla Firefox и адд-он "IE Tab", в такой конфигурации вы можете указать какие страницы нужно отображать с помощью IE6.

    • Главная Virtualization, Без рубрики Security, Virtualization, VMware, виртуализация
      • vShield Zones

        imagesCA7KEZJ2 vShield Zones – это система файрволлов на каждом ESX + управляющая консоль. Файрволлы (vShield), как и консоль (vShield Manager), являются просто виртуальными машинами.

        Принцип работы очень прост, у каждой vShield три сетевых интерфейса: mgmt, unprot и prot, которые подключены в соотв. портгруппы. Для коммуникации с vShield Manager используется mgmt интерфейс, обладающий собственным IP, unprot ловит все пакеты, проходящие через vSwitch, а после обработки пакеты отдаются во второй vSwitch (не имеющий физических аплинков) через prot интерфейс. В данном случае VMware не стала изобретать велосипед и просто купила компанию, специализирующуюся на таких решениях – BlueLane.

        Установка проходит при минимальном уровне участия администратора, все сетевые изменения проводятся автоматически. Сами же машины vShield и vShield Manager все ближе к черным ящикам. Хоть там и стоит какой-то дистрибутив Linux, но стандартной консоли просто нет, доступно лишь небольшое количество команд для конфигурирования и траблшутинга, причем при развертывании vShield машины из шаблона vShield Manager конфигурирует ее самостоятельно.

        Скриншот сетевых настроек ESX после установки vShield, на котором все прекрасно видно:

        В данном случае приведена картинка для традиционной схемы vSwitch’ей, но vShield работает и с vNetwork Distributed Switch.
        Почему сделана работа с двумя vSwitch’ами? Машины принудительно подключаются (или переключаются при установке) во второй vSwitch, не имеющий физических аплинков и соотв. изначально весь трафик пойдет только и исключительно через vShield.
        Огромный плюс vShield Zones в том, что не требуется никакого изменения сетевых настроек или адресации в гостевых системах, vShield полностью прозрачный файрволл.

        В итоге мы имеем центральную консоль управления, встраивающуюся в vCenter, хотя можно управлять ей и просто через браузер. В этой консоли, например, можно посмотреть подробную статистику сетевой активности одной ВМ, хоста, кластера и вплоть до всего датацентра (если на всех без исключения хостах установлены vShield). В качестве примера приведена статистика для контроллера домена тестовой зоны:

        Ну или в цифрах:

        Буквально двумя кликами дальше можно создать правило для любого протокола:

        Общее впечатление достаточно приятное. Интеграция пока немножко страдает, но BlueLane была приобретена всего в октябре 2008, в будущем шероховатости сгладятся. Настройки файрволла достаточно разветвленные и позволяют серьезно повысить уровень безопасности виртуальных машин в сети.

        vShield Zones включена в комплект начиная с редакции vSphere Advanced, т.е. эту функциональность получают также и все Enterprise пользователи VI3. Если, конечно, у них была активная поддержка 🙂

        Антон Жбанков

        http://blog.vadmin.ru

      • Главная Virtualization, Новое Hyper-V, Virtualization, VMware, виртуализация
        • Так ли бесплатен Hyper-V и так ли дорога vSphere?

          DCvsStreetFighter1 Не утихают споры о нужности / ненужности Memory Overcommitment. Сторонники Hyper-V утверждают, что все эти модные штучки с памятью не нужны, цена лицензии VMware выше, чем стоимость памяти, которая сейчас стоит "like a trash".

          Лично мне захотелось посчитать и получить цифры, которые не вешают лапшу на уши как маркетинг.

        • Главная Virtualization, Новое Virtualization, VMware, виртуализация
          • VMware HA: глубокое погружение

            vmware-logo-new-2009-400-300x481. Slots & Primary nodes
            2. Isolation

            Многие, пожалуй, встречались с ситуацией, когда в HA-кластере ресурсов на первый взгляд предостаточно, а HA ругается на нехватку ресурсов. Это происходит по причине того, что у HA своя собственная арифметика, основанная на слотах.

          • Главная Security, Virtualization, Без рубрики Security, Virtualization, виртуализация
            • Роли, которые мы выбираем…

              VMware Представьте себе ситуацию, кабинет Гиммлера, в него врывается Мюллер и начинает рыскать по шкафам, хватает папку с документами и убегает. Возможно ли такое при правильном сценарии?

              Используй то, что под рукой и не ищи себе другое.

            • Главная Virtualization, Без рубрики Virtualization, виртуализация
              • "Композитная" виртуальная машина

                future-computers_1 Один из часто задаваемых вопросов касается "композитной" виртуальной машины. "Можно ли сделать так, чтобы ресурсы двух хостов объединить в одну виртуальную машину?"

                Нет, нельзя. Почему?

                Кластерные суперкомпьютеры, которые позволяют "объединять" ресурсы множества узлов, строятся под задачи. ПО для работы на этих суперкомпьютерах разрабатывается специально, с учетом всех их особенностей.

                Виртуальные машины в общем случае – это универсальное и неспециализированное ПО, которое даже понятия не имеет, что работает не на физическом железе. И ведет себя соответствующим образом.
                Даже при использовании специальных высокоскоростных сетей, разработанных для суперкомпьютеров, задержки доступа составляют порядка микросекунды, в то время как задержка доступа к локальной памяти несколько наносекунд, т.е. объединение памяти физических машин в одну "композитную" выльется в 1000-кратное замедление скорости работы. Про процессорные шины и говорить не приходится. Да, пожалуй, если задаться подобной целью, то мы сможем в конечном итоге реализовать проект, который позволит на железе стоимостью сотни тысяч долларов создать виртуальную машину с производительностью на уровне 386 процессора. Извините, 32-процессорной машины с 386 процессорами.

                Почему же все тогда говорят про "облако" и ресурсы по заказу? Все очень просто. Мы действительно может давать ресурсы по заказу и относиться к большому Fully automated DRS кластеру ESX как к облаку. Но при одном условии – каждая ВМ требует ресурсов, значительно меньших, чем ресурсы одного хоста. Как только уровень ресурсов становится сравним, облако рассеивается на отдельно стоящие хосты.

                Виртуальные машины могут многое, и избавляют нас от многих забот, но они могут не все. И даже при всей автоматизации управления виртуальной инфраструктурой, не следует забывать то, что в первую очередь виртуальные машины – это консолидация серверов, деление ресурсов очень мощного хоста между виртуальными машинами. Если нам надо больше ресурсов для ВМ, чем есть у хоста, то вывод может быть только один – виртуализация здесь не нужна и проблемы с правильным проектированием, а не с недостатком возможностей платформы виртуализации.

                Антон Жбанков

                http://blog.vadmin.ru

              • Главная Virtualization, Без рубрики Virtualization, виртуализация
                • “Композитная” виртуальная машина

                  future-computers_1 Один из часто задаваемых вопросов касается "композитной" виртуальной машины. "Можно ли сделать так, чтобы ресурсы двух хостов объединить в одну виртуальную машину?"

                  Нет, нельзя. Почему?

                  Кластерные суперкомпьютеры, которые позволяют "объединять" ресурсы множества узлов, строятся под задачи. ПО для работы на этих суперкомпьютерах разрабатывается специально, с учетом всех их особенностей.

                  Виртуальные машины в общем случае – это универсальное и неспециализированное ПО, которое даже понятия не имеет, что работает не на физическом железе. И ведет себя соответствующим образом.
                  Даже при использовании специальных высокоскоростных сетей, разработанных для суперкомпьютеров, задержки доступа составляют порядка микросекунды, в то время как задержка доступа к локальной памяти несколько наносекунд, т.е. объединение памяти физических машин в одну "композитную" выльется в 1000-кратное замедление скорости работы. Про процессорные шины и говорить не приходится. Да, пожалуй, если задаться подобной целью, то мы сможем в конечном итоге реализовать проект, который позволит на железе стоимостью сотни тысяч долларов создать виртуальную машину с производительностью на уровне 386 процессора. Извините, 32-процессорной машины с 386 процессорами.

                  Почему же все тогда говорят про "облако" и ресурсы по заказу? Все очень просто. Мы действительно может давать ресурсы по заказу и относиться к большому Fully automated DRS кластеру ESX как к облаку. Но при одном условии – каждая ВМ требует ресурсов, значительно меньших, чем ресурсы одного хоста. Как только уровень ресурсов становится сравним, облако рассеивается на отдельно стоящие хосты.

                  Виртуальные машины могут многое, и избавляют нас от многих забот, но они могут не все. И даже при всей автоматизации управления виртуальной инфраструктурой, не следует забывать то, что в первую очередь виртуальные машины – это консолидация серверов, деление ресурсов очень мощного хоста между виртуальными машинами. Если нам надо больше ресурсов для ВМ, чем есть у хоста, то вывод может быть только один – виртуализация здесь не нужна и проблемы с правильным проектированием, а не с недостатком возможностей платформы виртуализации.

                  Антон Жбанков

                  http://blog.vadmin.ru