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

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

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

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

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

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

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

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

    http://blog.vadmin.ru

    • Виртуализация серверов с использованием Paragon Virtualization Manager

      virt_plat_in2_ab39f  Виртуализация физических серверов в корпоративных средах обеспечивает несколько важных преимуществ, таких как повышение надежности и доступности IT-сервисов, более эффективное использование мощных физических серверов, снижение затрат на содержание оборудования, и т.п. На рынок решений для виртуализации, главным образом, представленный Microsoft Hyper-V и VMware Converter, готовится выйти новый продукт от компании Paragon – Paragon Virtualization Manager, который будет описан в этой статье. Paragon Virtualization Manager представляет собой законченное и самостоятельное решение для выполнения различных сценариев виртуализации, которое может быть интересно как корпорациям, так и домашним пользователям.

    • Главная Virtualization, Новое Hyper-V, Virtualization, Windows 2008 R2
      • Windows Server 2008 R2 Hyper-V: Часто задаваемые вопросы

        virtual

        Перевод Михаила Даньшина “white paper” от Microsoft, посвященной часто задаваемым вопросам по новой версии Hyper-V в Windows Server 2008 R2.

      • Главная Virtualization, Новое Virtualization, VMware
        • Встреча VMware User Group Russia

          • Рубрика: Virtualization,Новое
          • Автор: Алексей Тараненко
          • Дата: Wednesday 03 Jun 2009

          VMwareLogo Господа и, надеюсь, дамы!

          26го июня (предварительная дата) состоится встреча российских пользователей VMware. Пока планируется на вторую половину дня, но если наберется достаточно докладов, то возможно и на целый день.

        • Главная Virtualization, Новое Hyper-V, Virtualization
          • Вкратце об MS Hyper-V Server 2008 R2

            • Рубрика: Virtualization,Новое
            • Автор: Александр Косивченко
            • Дата: Monday 01 Jun 2009

            image В этой статье я попытаюсь дать краткий обзор возможностей нового продукта – Microsoft Hyper-V Server R2, и рассказать, что это за зверь и с чем его едят. Как известно, множество ИТ-специалистов по возможности старается придерживаться традиционной идеологии: на каждый сервис выделять отдельный сервер: отдельно – DNS, отдельно – контроллер домена, отдельно – интернет-шлюз. С одной стороны – это правильно: каждый сервер работает независимо, и маловероятно, что падение одного  приведет к падению всех остальных, в отличие от «хранения всех яиц в одной корзине». Но, в то же время выделять под каждую задачу отдельный сервер – не всегда целесообразно.

            К примеру – контроллер домена AD и интернет-шлюз все “Best Practice” настоятельно рекомендуют размещать на разных серверах. Это в принципе логично: например, при хакерской атаке первым подвергается нападению именно интернет-шлюз. При успешной атаке, если на том же сервере будет размещен и контроллер домена – в руки хакерам может попасть и база данных AD, содержащая имена пользователей, хеши паролей, e-mail-адреса и прочие конфиденциальные данные. По той же причине, к примеру, файл-сервер с коммерческой информацией тоже нужно выносить на отдельный сервер. Но тут становится другая проблема: каждая из этих задач сама по себе, за редким исключением, требует совсем немного аппаратных ресурсов для своей работы, процентов 15-20 в крайнем случае. А вот каждый сервер стоит денег, и не малых. А платят-то за все 100% мощности каждого сервера. Получается настоящее расточительство. Помните анекдот про «нового русского», который каждую неделю покупал себе новый «Мерседес» – из-за того, что у старого забивалась пепельница? Ну а серверов при этом в итоге становится так много, что серверная будет достойна раздела «Ужасы» на nag.ru. А админить их все будет так “легко и удобно”, что поговорка «Если админ в 9 утра на работе – значит он там ночевал» обретет реальный смысл.

            Что же делать? Последнее время в IT стало очень модным слово «виртуализация». В принципе, ничего особенного в ней нет, этому термину 100 лет в обед исполнится.

            Тем не менее, виртуализация позволит:

            •    Рациональнее использовать аппаратные ресурсы серверов
            •    Экономить место в стойке и в серверной в целом
            •    Экономить электроэнергию
            •    Значительно повысить удобство администрирования
            •    Повысить надежность засчет кластеризации хостов и более легкого резервного копирования и восстановления виртуальных машин.

            В принципе – что есть виртуализация, и для чего она нужна – вы можете прочитать в предыдущей моей статье, «Для чего нужна виртуализация?».
            Вернемся от космических кораблей, бороздящих просторы Большого Театра, к нашим баранам – то есть, к продукту Hyper-V Server R2.

            Что же это такое?

            Hyper-V Server – это stand-alone-платформа для виртуализации серверов от Microsoft. Наиболее близкий аналог – VMWare ESX Server. Hyper-V Server основан на операционной системе MS Windows Server 2008, Hyper-V Server R2 – соответственно, на базе Windows Server 2008 R2. Hyper-V Server R2, как и Windows Server 2008 R2 пока находится в состоянии Release Candidate. Фактически, он представляет собой максимально урезанную версию WS2008 – режим Server Core, из ролей – только Hyper-V.

            Hyper-V Server – абсолютно бесплатен, не требует никаких лицензий. Тем не менее, в полноценные версии Windows Server 2008 входит определенное количество бесплатных лицензий на гостевые ОС (1 – в Standard, до 4 – в Enterprise, и не ограничено в пределах 1 CPU – в Datacenter). Как уже было сказано, распространяется Hyper-V Server бесплатно. Можно скачать с сайта Microsoft.com как предыдущую версию Hyper-V Server, так и Release Candidate Hyper-V Server R2.

            Основные возможности Hyper-V Server R2 и различия с предыдущей версией Hyper-V Server и виртуализацией на базе полноценного на базе Windows Server 2008 приведены в таблице:

            tabl

            Как известно, для работы гипервизора Hyper-V необходим 64-битный процессор с поддержкой технологий аппаратной виртуализации (Intel VT или AMD-V) и аппаратной DEP (NX-bit). На иных типах процессоров Hyper-V работать не будет. По своим возможностям, в отличие от предыдущей версии, Hyper-V Server 2008 R2 приблизился к Enterprise-версии Windows Server 2008: поддержка до 8 процессоров, до 1TB оперативной памяти, поддерживает кластеризацию и технологии Live/Quick Migration. Кстати, в отличие от VMWare ESXi, использование всех этих фич не требует покупки лицензий. У VMWare же лицензия требуется на каждый чих, что мне не очень нравится (хотя, возможно, нравится сейлам).

            Системные требования у Hyper-V Server – вполне божеские. Во-первых, как я уже говорил – 64-битный CPU с аппаратной поддержкой виртуализации и DEP. Минимально – тактовая частота 1.4GHz, 1GB RAM, 4.8GB свободного дискового пространства. Рекомендуется – 2 и более GHz, 2 и более GB RAM. В настоящее время найти в продаже сервер, не удовлетворяющий этим требованиям – весьма непросто, разве что б/у. Вообще же, не рекомендую смотреть на минимальные и рекомендованные требования, а прикинуть, сколько будет запущено на сервере виртуальных машин, сколько каждой из них потребуется процессорного времени, памяти, места на диске – и уже из этих данных прикидывать необходимую конфигурацию.

            Процесс инсталляции Hyper-V Server R2 достаточно прост, как, в принципе, и инсталляция самого Windows Server 2008. Необходимо скачать ISO-образ, «прожечь» его на DVD-болванку и загрузить с нее сервер.
            После загрузки надо выбрать язык (русского языка нет, во всяком случае в RC), выбрать раздел диска, на который будет идти установка, и, собственно, запустить сам процесс инсталляции.

            image

            Как я уже говорил, устанавливается продукт в режиме Server Core. Это значит, как утверждают разработчики, что управление ведется только через командную строку (на радость бородатым юниксоидам), графический интерфейс отсутствует. Я скажу, что это не совсем так: графический интерфейс таки есть. Тем не менее, оболочки с меню и иконками нет, есть лишь два окошка – командная строка (cmd) и текстовая конфигурационная утилита. Примерно как в Linux, если запустить X, и в качестве оболочки выбрать Xterm. Это в принципе понятно: во-первых, в Windows графика является частью ядра, в отличие от unix-like OS, а во-вторых – некоторые программы требуют для инсталляции и работы графический интерфейс. Тем не менее, режим Server Core позволяет сэкономить ресурсы сервера, и уменьшить объем обновлений – так как меньше кода, меньше и патчей.
            Первоначальная настройка осуществляется через текстовую конфигурационную утилиту. Она представляет собой меню. Выбор пунктов осучествляется путем ввода номера нужного пункта меню. Здесь можно сделать самые первичные настройки системы: сетевые настройки, ввод в домен, включение удаленного управления.

            image

            Все остальные настройки делаются удаленно с рабочей станции администратора, с помощью пакета RSAT (Remote Server Administration Tools).
            RSAT – набор утилит, фактически – MMC-шных оснасток, для удаленного управления серверами. Аналог пакета adminpak.msi в Windows Server 200-2003. RSAT можно бесплатно скачать с сайта Microsoft. Есть версии RSAT для Windows Vista, и недавно вышла – для Windows 7. Версии для XP, к превеликому сожалению, нет и не ожидается. По-видимому, MS окончательно ее «похоронили».
            Для того, чтобы удаленно управлять сервером – необходимо, вначале, это самое удаленное управление разрешить на самом сервере. Делается это в конфигурационной утилите (4й пункт меню). Затем надо разрешить управление MMC (включить нужные правила в фаерволле) – пункт 1, установить PowerShell –пункт 2 (потребует перезагрузки, необходимо будет перезагрузиться для следующего пункта) и разрешить управление через Server Manager – пункт 3. Кстати говоря, этим версия R2 выгодно отличается от предыдущей версии Hyper-V Server: в ней все операции по включению удаленного управления приходилось делать вручную через командную строку, что само по себе является не совсем тривиальной задачей, особенно для тех, кто не сталкивался с командной строкой со времен DOS. Кто знаком с синтаксисом команды netsh – тот меня поймет.

            Затем, на рабочей станции администратора нужно установить пакет RSAT. Установка проходит по методу Next-Next-Next, так что подробно останавливаться не буду. После установки, тем не менее, в отличие от Windows Server 2003, мы не видим новых оснасток в меню «Administrative Tools». Чтобы они появились, нам нужно включить соответствующие фичи Windows. Делается это через Control Panel – Programs and Features – Turn Windows Features On or Off. В открывшемся дереве папок надо раскрыть Remote Server Administration Tools. Необходимая нам оснастка, Hyper-V Manager, находится в подпапке Role Administration Tools (Hyper-V Tools). После выбора нужных фич жмем ОК, и оснастки появляются в Administrative Tools.

            После запуска нужной оснастки (например Hyper-V Manager) нужно выбрать Connect to Server…, далее выбрать Remote Server и набрать сетевое имя нашего Hyper-V Server’a. Все, мы подключились. Теперь можно полноценно управлять сервером, например – создавать виртуальные машины.

            Более подробно ознакомиться с материалом статьи, а так же увидеть «в живую» процесс инсталляции, настройки и управления Hyper-V Server R2 можно в моем вебкасте: http://www.techdays.ru/videos/1346.html

            В следующей статье я планирую рассказать о создании отказоустойчивой инфраструктуры на базе кластеров Hyper-V Server 2008 R2. Спасибо за внимание!

            Косивченко Александр

          • Главная Virtualization, Новое Hyper-V, Virtualization
            • Виртуальные машины и сети

              • Рубрика: Virtualization,Новое
              • Автор: Александр Косивченко
              • Дата: Monday 13 Apr 2009

              vn-4Для грамотного управления виртуальной инфраструктурой необходимо иметь представление о том, как организуется сетевое взаимодействие виртуальных машин между собой, с хостовой ОС (parent partition в терминологии MS), и с самой локальной сетью. В этой статье я постараюсь объяснить в меру своих возможностей тонкости работы виртуальных машин с сетью. Тем, кто уже работал с другими платформами виртуализации (VMWare, Virtual Server, etc.) все, о чем я буду писать, скорее всего, уже известно, тем не менее, на уровне терминологии вполне возможны некие различия.

            • Главная Virtualization, Новое Virtualization
              • Эксперимент: Виртуализация и виртуальные жесткие диски

                • Рубрика: Virtualization,Новое
                • Автор: Александр Косивченко
                • Дата: Wednesday 01 Apr 2009

                Безымянный  Довольно часто, в системе “слабым местом” оказывается дисковая подсистема, что вполне понятно: ведь быстродействие жесткого диска всегда намного меньше, чем оперативной памяти или процессора. При виртуализации же, когда несколько виртуальных машин используют один и тот же жесткий диск (или массив) – вопрос быстродействия встает особенно остро.

                Заметнее всего падение быстродействия – при виртуализации серверов, очень активно обращающихся к жестким дискам: например – серверов баз данных, почтовых серверов. Здесь уже приходится идти на хитрости ради того, чтобы выиграть пару-тройку лишних IOps’ов.

                Рассмотрим работу с жесткими дисками в среде Hyper-V.

                1. VHD-файлы

                Наиболее известный способ, выбираемый по дефолту: использование в качестве дисков для виртуальной машины – файлов *.vhd (Virtual Hard Disk). Этот способ имеет три преимущества:

                • VHD-файлы могут храниться где угодно и могут быть легко перемещены;
                • Удобство создания резервных копий: копирование одного большого файла – намного легче и быстрее, чем копирование всего содержимого жесткого диска (VHD-файл может быть легко скопирован средствами VSS, без остановки самой виртуальной машины, а в случае бэкапа содержимого физического диска – может потребоваться перезагрузка как минимум гостевой ОС);
                • Рациональное использование дискового пространства: на одном физическом диске может храниться множество VHD-файлов, и каждой виртуальной машине можно отвести ровно столько дискового пространства, сколько ей необходимо

                Минус – один: меньшее быстродействие по сравнению с прямой работой с диском. Далее будет показано наглядно.

                2. Прямое обращение к физическому диску

                Hyper-V, помимо использования VHD-файлов – предоставляет возможность использования виртуальной машиной физических дисков. Плюс тут один: более высокое быстродействие в сравнении с VHD-файлами. Минусов же больше:

                • Немного сложнее создавать резервные копии и переносить информацию в другое место;
                • Менее рациональное использование дискового пространства (весь объем диска используется одной виртуальной машиной, не может регулироваться динамически и распределяться между несколькими виртуалками);

                Ну а теперь – перейдем от теории к практике.

                Эксперимент.

                В качестве экспериментального стенда использовался сервер HP ML150G5, снабженный четырёхъядерным процессором Intel® Xeon® E5420 2,5 ГГц и 4Гб оперативной памяти. Дисковая подсистема представлена двумя дисками объемом 72Гб с интерфейсом SAS, объединенными в массив RAID1 и двумя SATA-дисками объемом 250Гб, так же объединенными в RAID1. На сервере установлена ОС Microsoft Windows Server 2008 Std. 64bit с поддержкой Hyper-V. Других задач, помимо виртуализации у него нет. Далее – все эксперименты, о которых я буду писать в этом блоге – будут проводиться именно на этом сервере.

                Для чистоты эксперимента все действующие ВМ были остановлены, и создана новая ВМ с 512Мб ОЗУ и двумя жесткими дисками: один – для установки гостевой ОС, другой – для эксперимена. На ВМ была установлена ОС Microsoft Windows Server 2003 32bit, были установлены компоненты интеграции. Для создания нагрузки на диски и измерения параметров быстродействия была использована бесплатная утилита IOMeter. Параметры доступа к диску в IOMeter были заданы следующие:

                • Объем страницы: 64Кб;
                • 75% – случайный доступ, 25% – линейный;
                • 75% – чтение, 25% – запись.

                Опыт первый: VHD-файл.

                Как я уже писал выше, экспериментальная ВМ имеет два виртуальных жестких диска: на один устанавливается ОС, другой – используется для измерения быстродействия. В первом моем опыте я использовал VHD-файл фиксированного размера 10Гб. Файл размещался на зеркале из двух 250Гб SATA-дисков. Я получил следующие результаты:

                • Total I/O per sec: 111,5
                • Total MB per sec: 6,92
                • Average I/O Response Time: 9,0152 ms
                • Maximum I/O Response Time: 526,0630 ms

                Результаты сильно удручают: 7Мбайт в секунду – это очень и очень мало. Для примера, в хостовой ОС, копирование файла с одного массива на другой показывало скорость порядка 37-40Мбайт/c. Правда, это показания самой ОС, которые могут и не соответствовать действительности. Увы, судя по сайту разработчиков – последняя версия IOMeter’а вышла 27 июля 2006 года, так что не удивительно, что под Windows Server 2008 она хоть и запустилась, но корректно не работала: она просто не “видела” жесткие диски. Если кто-нибудь посоветует мне более новую утилиту, аналогичную IOMeter и нормально работающую под Windows Server 2008 – с меня пиво 🙂

                Время отклика – тоже очень и очень плохое: 9 миллисекунд в среднем, и 526 миллисекунд (просто вдумайтесь в это: больше, чем пол-секунды!) максимум. Вобщем – для, к примеру, веб-сервера вполне бы сгодилось, но устанавливать с таким быстродействием, к примеру, сервер БД какой-нибудь ERP-системы я бы не рискнул.

                Опыт второй: прямое обращение к диску.

                Теперь я удалил злосчастный VHD-файл и перевел наш 250Гб массив в режим Offline через консоль Computer Management (это – необходимое условие, чтобы Hyper-V “увидела” наш диск и его можно было бы подключить к ВМ). После этого – в свойствах тестовой ВМ вместо VHD-файла был подключен наш физический диск и так же – запущен IOMeter c теми же параметрами. Результаты получились следующие:

                • Total I/O per sec: 126,7
                • Total MB per sec: 7,9
                • Average I/O Response Time: 7,9362 ms
                • Maximum I/O Response Time: 96,1755 ms

                Сказать честно – результаты меня удивили. Я не ожидал такой маленькой разницы в iops и в mbps. Чем это вызвано – самому интересно. Вполне возможно, что здесь мы уперлись в потолок быстродействия SATA-дисков. А вот время отклика уже – намного лучше: 8 миллисекунд в среднем и 96 в максимуме, против 9 и 526 соответственно. Как видно, среднее время отклика улучшилось ненамного, возможно, что не улучшилось и вовсе: одна миллисекунда вполне укладывается в погрешность измерения. А вот максимальное время отклика – уменьшилось почти в 60 раз, что не может не радовать.

                Вывод.

                Из всего этого напрашивается следующий вывод: если планируется виртуализировать какие-либо задачи, требующие активного доступа к дискам – нужно использовать прямой доступ к диску. Во всех же остальных случаях я настоятельно рекомендую использовать, как и обычно, VHD. В случае, если использование прямого доступа необходимо – “соломоновым решением”, наверное, будет использование двух виртуальных дисков у одной ВМ: один – в виде VHD – для установки ОС и приложений, а другой – с использованием прямого доступа – для хранения данных.

                P.S. У меня имеются подозрения, что на эксперимент сильно повлиял потолок быстродействия SATA-дисков. Недавно у нас в распоряжении оказалась дисковая полка HP MSA2000 с интерфейсом SAS. Завтра – попробую подключить эту полку к серверу, собрать на ней RAID10 и повторить эксперимент. О результатах – обязательно отпишусь. Оставайтесь на канале!

                Александр Косивченко

              • Главная Virtualization, Новое Virtualization
                • Зачем же нужна виртуализация?

                  • Рубрика: Virtualization,Новое
                  • Автор: Александр Косивченко
                  • Дата: Sunday 29 Mar 2009

                  General Раз уж мы говорим о виртуализации – наверняка у кого-то возникает вполне резонный вопрос: а для чего же это вообще нужно? Оговорюсь, что далее речь пойдет о виртуализации серверов. О виртуализации представлений и приложений – возможно, напишу чуть позже.

                  Я, признаться честно, являюсь технарем "до мозга костей", и модные аббревиатуры вроде TCO, ROI, etc., которыми очень любят оперировать господа маркетологи – для меня являются "китайской грамотой". Соответственно – буду писать о том, что я вижу как технарь.

                  Наверняка у многих сисадминов в хозяйстве имеется несколько серверов. И обычно это оправданно: многие задачи рекомендуется разносить по разным серверам. К примеру, Microsoft настоятельно не рекомендует совмещать контроллер домена Active Directory и интернет-шлюз на одном физическом сервере. Это создает серьезную угрозу безопасности: в случае атаки на вашу сеть каких-нибудь хакеров или вирусов – первым примет на себя удар, как Брестская Крепость, интернет-шлюз. В случае, если на нем размещался еще и контроллер домена – существует вероятность, что базы AD будут повреждены, либо, что еще хуже – окажутся в руках хакеров. В первом случае понадобится тратить время на восстановление из бэкапов, во втором – очень высокая вероятность дальнейших и более продуманных атак, с использованием логинов и паролей действующих пользователей сети. Ну или просто попадание e-mail адресов пользователей компании в базы спамеров – тоже приятного мало. Одна старая пословица говорит: "Не клади все яйца в одну корзину".

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

                  Но тут возникает новая проблема: каждый отдельный сервер – стоит денег, причем не малых (если речь идет о брэндовых серверах). Каждый отдельный сервер потребляет электроэнергию, и занимает место на столе либо в стойке. Возможно, кому-то это покажется не особо актуальным, тем не менее – это является важным преимуществом. Особенно, если сервера размещаются в стороннем датацентре, где взымают плату за занимаемые юниты в стойках и энергопотребление строго ограничивается. К тому же, в европейских странах существует некий налог, который напрямую зависит от объемов электроэнергии, потребляемых компанией. Не помню, как этот налог называется – что-то связанное с экологией и выбросом CO2.

                  Кроме этого, каждое из приложений редко потребляет много системных ресурсов: те же контроллеры доменов и интернет-шлюзы – на них редко загрузка процессора превышает 10%. Использование под каждую такую задачу отдельного сервера выглядит нерационально. Совмещать все на одном сервере – как мы уже выяснили, не правильно с точки зрения безопасности. Где же золотая середина? Как же сделать, чтобы и волки были сыты, и овцы целы (и пастуху – вечная память! :)) Ответ дает как раз технология виртуализации.

                  Что же такое виртуализация? Виртуализация (а именно – виртуализация серверов) – это технология программной эмуляции аппаратного обеспечения компьютера. Причем, на одной физической машине может быть запущено несколько таких виртуальных "компьютеров". На такие виртуальные машины можно ставить операционную систему и приложения, и работать с ними, как с отдельными физическими машинами. Каждая виртуальная машина использует для своей работы какую-то часть аппаратных ресурсов физической машины. Причем, как правило, объем аппаратных ресурсов, выдаваемых отдельным виртуальным машинам можно регулировать – как жестко (статически), так и динамически. Таким образом, аппаратные ресурсы используются намного более рационально.

                  Простой пример: если у нас есть два приложения, которым для работы необходимо 128Мб оперативной памяти, и которые нельзя устанавливать на один физический сервер, можно:

                  • 1) Купить два сервера с 128M RAM;
                  • 2) Купить один сервер с 256M RAM (плюс еще какое-то количество "про запас" и для запуска хостовой ОС) и запустить оба приложения в отдельных виртуальных машинах.

                  Как видно, во втором случае ресурсы сервера (в частности, CPU) используется более рационально, и стоимость р
                  ешения гораздо ниже, т.к. один сервер с чуть большим объемом RAM всегда дешевле двух серверов.

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

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

                  Еще важный момент: виртуализация (если речь идет о решении от Microsoft) поможет сэкономить на лицензиях. К примеру, лицензия на Windows Server 2008 Standard позволяет бесплатно запускать внутри одну виртуальную машину, Enterprise – до 4, а Datacenter – вообще неограниченно (в пределах одного физического хоста).

                  Системные администраторы, кстати говоря, оценят и другие удобства виртуализации: быстрота развертывания виртуальных машин и простота резервного копирования.

                  Как известно, развертывание нового сервера занимает определенное время. Это – установка ОС, установка драйверов, установка приложений и т.п. Да, конечно, все параметры установки ОС можно задать в файле ответов автоматической установки, драйвера можно интегрировать в дистрибутив, приложения установить, например, через RunOnce, но все равно установка занимает время. Даже если создать полный образ системы – во-первых, его развертывание все равно займет порядка 10-15 минут просто из-за его объема и скорости чтения из сети или с DVD-ROM, во-вторых – для создания такого образа, как правило, необходимо прибегать к помощи стороннего ПО. С виртуальными же машинами все намного проще: можно создавать абсолютно идентичные "клоны" виртуальной машины за пару кликов мышью, и процесс займет порядка нескольких минут – ведь скорость работы дисковой подсистемы сервера намного выше, чем пропускная способность сети или скорость чтения DVD-ROM.

                  Приведу пример из собственного опыта. Контора, где я однажды работал, занималась, помимо прочего, и разработкой ПО. Естественно, разработчикам было необходимо где-то тестировать и отлаживать свои программы. Как нельзя лучше для этого подходили виртуальные машины. Благодаря клонированию – удалось создать эталонный образ, в результате которого развертывание новой виртуальной машины занимало порядка 3 минут. А у нас было целых два сервера, на каждом из которых работало примерно по 20 виртуальных машин. К слову сказать – использовался VMWare ESX Server, было просто два отдельных сервера – без VMotion и кластеров. Правда, для управления использовался Virtual Center.

                  Еще одна головная боль любого сисадмина – резервные копии. Как утверждает пословица: "Есть два типа сисадминов: те, которые еще не делают бэкапы, и те, которые уже делают". Резервное копирование – на первый взгляд, возможно, кажется бесполезной процедурой, но как только жареный петух куда-нить клюнет – тот, кто не делал бэкапы – начинает рвать на себе волосы, кусать локти и развертывать все заново. Если на сервере уже были какие-то важные данные – это то еще удовольствие. А если там была, например, база данных, содержащая бухгалтерию предприятия за последние 10 лет – то это просто смерти подобно. Не говоря уже, опять же, о простое – который может обернуться серьезными убытками. Ну не поймут клиенты, если им будут говорить "Подождите пожалуйста, у нас сервер не работает!" – они просто пойдут и купят у кого-то другого. Директор, естественно, админа за такое дело по головке не погладит.

                  Даже если делается бэкап, то не всегда можно дать 100% гарантию, что из него можно будет восстановить ОС на "голом железе", и она будет работать без ошибок. Особенно – если конфигурация аппаратного обеспечения будет немно
                  го отличаться от предыдущей. Близкую к 100%-ной гарантию дают системы резервного копирования, имеющие функцию "Bare Metal Restore" – например, Symantec BackupExec, CA ArcServe, IBM Tivoli Storage Manager, HP Data Protector. Но само это ПО стоит вполне приличных денег, и за функцию "Bare Metal Restore" придется заплатить отдельно: для ее использования, как правило, необходима отдельная лицензия.

                  С виртуальными же машинами намного проще: все "железо" там стандартное, ибо эмулируемое, и для полного бэкапа достаточно просто скопировать один или несколько файлов. Всё. Для восстановления достаточно просто скопировать файл(ы) на новый сервер, где уже установлена хостовая ОС со средой виртуализации, и "подцепить" их – и виртуальная машина будет работать как ни в чем не бывало.

                  Еще необходимо упомянуть так называемые моментальные снимки (snapshots): это – грубо говоря – бэкап виртуальной машины, хранящийся внутри нее самой. При необходимости можно просто "откатить" виртуалку на момент снятия моментального снимка – и она будет работать, как будто с того момента ничего не изменилось. Причем, у одной виртуальной машины может быть много таких snapshot’ов, и они могут образовывать древовидную структуру. Это позволяет "откатывать" систему ровно к необходимому моменту. Такой функцией могут пользоваться, к примеру, системные администраторы, делая snapshot до и после каких-либо важных изменений, и, если понадобиться, к примеру – откатиться до момента изменений. Или еще раньше. А потом, если надо – позже. И не нужно развертывать систему с нуля и снова повторять все свои действия. Наши разработчики, кстати, по достоинству оценили такую возможность: раньше, когда они использовали VirtualPC на своих рабочих станциях – делать такие "откаты" было затруднительно, часто приходилось создавать машину заново с эталонного образа.

                  Итак, подводя итог, вкратце – почему все же виртуализация серверов – это гуд:

                  • Рациональное использование аппаратных ресурсов серверов;
                  • Экономия денег на покупке новых серверов, экономия электроэнергии и физического пространства;
                  • Экономия лицензий на виртуальные ОС (если речь о Microsoft);
                  • Простота администрирования: легкость перемещения виртуальных машин с одного физического сервера на другой, быстрота развертывания новой машины из эталонного образа, простота создания резервной копии и восстановления из нее, использование "моментальных снимков".

                  Собственно, на этом хотелось бы завершить данную статью.

                  Александр Косивченко