Главная 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);
        • Простота администрирования: легкость перемещения виртуальных машин с одного физического сервера на другой, быстрота развертывания новой машины из эталонного образа, простота создания резервной копии и восстановления из нее, использование "моментальных снимков".

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

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