Главная Virtualization, Без рубрики, Новое Виртуализация: рекомендации ведущих собаководов
  • Виртуализация: рекомендации ведущих собаководов

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

    Начнем с хоста

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

    • Процессор
    • Память
    • Дисковая подсистема
    • Сетевая подсистема

    В этой главе мы опишем, как выявлять «узкие места» по всем четырем направлениям и как с ними бороться, и самое главное – как их можно избежать.

    Процессор – сердце компьютера

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

    Нам необходимо получить ответы на следующие ключевые вопросы:

    • Сколько ставить процессоров?
    • Сколько нужно ядер?
    • Их скоростные характеристики?

    Ответить на эти вопросы не так просто, как кажется. Простой пример: какую систему использовать – двухпроцессорную или четырехпроцессорную? По цене двухпроцессорные системы в безусловном выигрыше: цена одного четырехпроцессорного сервера примерно равна трем двухпроцессорным. Казалось бы, в таком случае наилучшее решение – купить три двухпроцессорных сервера и объединить их в Failover-кластер – и можно получить более высокопроизводительное и отказоустойчивое решение. Но с другой стороны, при таких делах… Появляется множество новых затрат:

    1. Требуется больше лицензий на ПО – как на сами ОС, так и на ПО управления (SCVMM, SCCM, SCOM, etc.)
    2. Возрастают затраты на администрирование – три сервера вместо одного
    3. Три сервера потребляют больше энергии, а значит – выделяют больше тепла, и занимают больше места в стойке, чем один сервер, пусть и более мощный.

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

    Тем не менее, производительность системы в целом может зависеть не только и не столько от процессоров. Возьмем, для примера, СУБД. В некоторых случаях требования к процессору могут быть не слишком высокими, зато дисковая подсистема может использоваться очень активно. А если в этой СУБД активно используется бизнес-логика и аналитика (OLAP, отчеты) – то наоборот, требования к процессору и памяти могут быть намного выше, чем к дисковой подсистеме.

    Чтобы определить, является ли процессор «узким местом» в системе – нужно узнать, насколько сильно он загружен. Для этого могут использоваться разные системные утилиты. К примеру, многие системные администраторы привыкли пользоваться стандартным Windows Task Manager. К сожалению, из-за особенностей архитектуры Hyper-V этот самый Task Manager покажет не погоду в Гондурасе, и не курс зимбабвийского доллара, но всего-лишь навсего загрузку процессора хостовой ОС. Виртуальные машины при этом учитываться не будут – поскольку хостовая ОС, точно так же, как и все виртуальные машины – работает в своем изолированном разделе. Поэтому нужно использовать оснастку Perfmon. Многие администраторы, особенно те, кто сдавал экзамены MCSA, об этой утилите знают. Для тех, кто все же не знает – запускается она достаточно легко: Start – Administrative Tools – Reliability and Performance. Из этой оснастки нам нужна ветка Monitoring Tools – Performance Monitor.

    С помощью этой утилиты можно видеть значения практически любых системных параметров, а так же наблюдать их изменение на графике. По умолчанию добавлен всего один параметр (в терминах Perfmon – «счетчик» или «counter») – «% Processor Time». Этот счетчик показывает то же самое, что и Task Manager – загрузку процессора хостовой ОС. Поэтому этот счетчик можно удалить.

    Перейдем к добавлению счетчиков. В Perfmon имеется множество счетчиков, связанных с Hyper-V. Из них нас на данный момент интересуют два:

    • Hyper-V Hypervisor Virtual Processor, % Total Run Time – этот счетчик отображает загрузку виртуальных процессоров. Можно задать отображение суммарной загрузки всех процессоров для запущенных виртуальных машин, а можно выбрать конкретный виртуальный процессор конкретной виртуальной машины.
    • Hyper-V Hypervisor Root Virtual Processor, % Total Run Time – а этот счетчик показывает загрузку выбранных логических процессоров задачами, не связанными с Hyper-V.

    Примечание: Что же такое логический процессор? Проще всего это понять на примерах. Допустим, если у вас есть один процессор с одним ядром – у вас будет один логический процессор. Если процессор будет двухъядерным – то логических процессоров станет уже два. А если он будет поддерживать Hyper-Threading – то их будет уже четыре.

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

    Памяти много не бывает

    Мощный процессор – это хорошо, но при недостатке памяти система начинает использовать файлы подкачки, и производительность начинает падать едва ли не экспоненциально. Как говорят в интернете – «512 мегабайт – это не память, это маразм».

    К сожалению (а скорее всего – к счастью) в Hyper-V невозможно выделить виртуальным машинам больше памяти, чем физически присутствует в системе. Это то, что называют «memory overcommit», и чем с такой радостью играет маркетинг других вендоров решений виртуализации. Хорошо это или плохо – это тема отдельной статьи, и об эту тему было сломано уже не мало виртуальных копий.

    В связи с этим возникает вопрос: а сколько памяти нам в итоге необходимо? Ответ зависит от разных факторов:

    • Сколько виртуальных машин будет запущено, и сколько памяти им понадобится? Объем памяти, необходимый каждой виртуальной машине зависит от задач, которые она будет выполнять. Подход тот же самый, что и для обычных серверов, но память виртуальным машинам можно выделять более гибко – не 1024 Мб, а, к примеру, 900 Мб.
    • Хостовой ОС тоже нужна память. Рекомендуется оставлять как минимум 512 Мб свободной памяти на нужды гипервизора и самой хостовой ОС. Если объем свободной памяти опустится ниже 32 Мб – система не даст запустить больше ни одной виртуальной машины, пока память не освободится. Кроме этого, в хостовой ОС могут выполняться какие-то другие задачи, помимо виртуализации. Хотя это и крайне не рекомендуется, но факт все же имеет место быть, и это необходимо учитывать.
    • Другие виртуальные машины (для сценариев Live Migration). Если инфраструктура планируется на базе отказоустойчивого кластера, то необходимо на каждом из хостов предусмотреть дополнительные объемы памяти. Дело в том, что виртуальные машины могут перемещаться с одного хоста на другой в случае ручного перемещения (Live Migration), или же в случае отказа одного из хостов. Если на хосте будет недостаточно памяти для запуска перемещаемых виртуальных машин – то они попросту не смогут на нем запуститься. Поэтому на этапе проектирования надо предусмотреть «неприкосновенный запас» в размере 50-100% от необходимого объема памяти. Возможно, ситуация немного улучшится с выходом Windows Server 2008 R2 SP1, в который входят технологии динамического распределения памяти, но точно я смогу сказать лишь тогда, когда сам это протестирую.

    Как же нам посмотреть, что происходит с памятью? К счастью, можно посмотреть через любимый Task Manager – в отличие от загрузки процессора, он покажет использование памяти достаточно правдиво. А можно (и даже нужно) прибегнуть к уже знакомому Perfmon и его счетчикам Memory/Available Mbytes и Memory/Pages/Sec.

    Жесткие диски: сколько их надо?

    Как правило, достаточно трудно предсказать, сколько дискового пространства потребуется виртуальным машинам для работы. И потому ситуации, когда дискового пространства не хватает, или же наоборот – когда его слишком много и диски простаивают – встречаются довольно часто.

    Помимо объема, есть еще одна очень важная характеристика – быстродействие дисковой подсистемы. 2 Тб дискового пространства – это конечно же хорошо, но если это два SATA-диска, не объединенных в RAID-массив – то пропускной способности может попросту не хватить, и это сильно скажется на быстродействии системы.

    Планирование подсистемы хранения данных включает в себя следующие аспекты:

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

    Тип дисков. Жесткие диски, помимо объема, имеют множество других характеристик, о которых нельзя забывать. Это и тип интерфейса (IDE, SATA, SCSI, SAS), и скорость вращения шпинделя (7200, 10000, 15000 об/мин), и объем кэш-памяти самого жесткого диска. Разница, к примеру, между диском на 7200 и 10000, а тем более – 15000 об/мин, или между 8 и 32 Мб кэш-памяти – для таких высоконагруженных систем, как хосты виртуализации – достаточно высока.

    Количество дисков и тип RAID-массива. Как уже было сказано, иногда, для достижения более высокой производительности, и надежности, наилучшим решением станет не установка одного диска большого объема, а объединение нескольких дисков меньшего объема в RAID-массив. Есть несколько типов RAID-массивов:

    • RAID 0 – «массив с чередованием». Информация пишется блоками («страйпами») одновременно на несколько дисков. Благодаря этому чтение и запись больших объемов информации происходит значительно быстрее, чем с одного диска, и тем быстрее, чем больше дисков в массиве. Но есть один большой недостаток: низкая надежность. Выход из строя любого из дисков приведет к полной потере информации. Поэтому на практике RAID 0 используется достаточно редко. Один из примеров – промежуточное хранилище резервных копий в модели «Disk-to-disk-to-tape», когда надежность не так важна, как быстродействие.
    • RAID 1 – «зеркалирование». При такой модели информация записывается одновременно на несколько дисков, причем содержимое всех дисков абсолютно идентично. Скорость записи и чтения не выше, чем для одиночного диска, но намного выше надежность: выход из строя одного диска не приведет к потере информации. Недостаток лишь один: высокая стоимость – там, где хватает и одного диска – приходится ставить два и более. Смысл имеет в тех случаях, когда надежность имеет решающее значение.
    • RAID 4 и RAID 5 – «чередование с контролем четности». Предстваляет собой некую «золотую середину» между RAID 0 и RAID 1. Смысл состоит в том, что информация хранится на дисках как и в случае RAID 0 –  блоками с чередованием, но помимо этого вычисляются контрольные суммы хранимых данных . В случае отказа одного из дисков – недостающие данные автоматически вычисляются по имеющимся данным и контрольным суммам. Разумеется, это приводит к снижению производительности, но в то же время данные не теряются, и при замене сбойного диска вся информация восстанавливается (этот процесс называется перестройкой массива). Потеря данных произойдет только при отказе двух и более дисков. Такие массивы отличаются тем, что скорость записи у них значительно ниже, чем скорость чтения. Происходит так из-за того, что при записи блока данных происходит вычисление контрольной суммы и запись ее на диск. RAID 4 и RAID 5 отличаются тем, что в RAID 4 контрольные суммы записываются на отдельный диск, а в RAID 5 – хранятся на всех дисках массива вместе с данными. В любом случае, для организации такого массива нужно N дисков для хранения данных плюс один диск. В отличие от RAID 1 и RAID 10, где количество дисков просто удваивается.
    • RAID 6 – он же RAID DP, double-parity, двойная четность. То же самое, что и RAID 5, но контрольные суммы вычисляются два раза, с использованием различных алгоритмов. Хотя дисков здесь требуется уже не N+1, как с RAID 5, а N+2, зато такой массив может пережить даже одновременный отказ двух дисков. Встречается относительно редко, как правило – в системах хранения данных Enterprise-уровня, к примеру – NetApp.
    • RAID 10 – «гибрид» RAID 0 и RAID 1. Представляет собой RAID 0 из нескольких RAID 1 (и тогда называется RAID 0+1) или наоборот – RAID 1 из нескольких RAID 0 (RAID 1+0). Отличается наивысшей производительностью, как по записи, так и по чтению, но в то же время отличается и высокой стоимостью – так как дисков требуется в 2 раза больше, чем необходимо для хранения данных.

    Как видно, выбор дисков – достаточно непростая задача, поэтому выбирать нужно, исходя не только из требований к дисковому пространству, но и требований к производительности, и разумеется – из выделенных бюджетов. Иногда будет более оправданно использование внешней системы хранения данных, к примеру – когда речь идет о больших объемах и/или высокой производительности, которые невозможно достичь, используя внутренние диски. А когда планируется инфраструктура с высокой отказоустойчивостью – то тут уж точно никуда не деться от внешней СХД. Внешние СХД нужно выбирать, руководствуясь теми же принципами, что и внутренние диски: пропускная способность интерфейсов, количество дисков, тип дисков, поддерживаемые RAID-массивы, дополнительные функции – такие, как изменение объемов виртуальных дисков (LUN’ов) «на лету», возможность использования моментальных снимков (snapshots), и т.д.

    А что же насчет измерений? Есть несколько счетчиков, связанных с производительностью дисковой подсистемы. Интерес представляют следующие:

    • Physical Disk, % Disk Read Time
    • Physical Disk, % Disk Write Time
    • Physical Disk, % Idle Time

    Эти счетчики показывают, какой процент времени идет чтение, запись на диск и, соответственно – процент простоя. Если их значения поднимаются выше 75% на длительные промежутки времени – это значит, что производительность дисковой подсистемы недостаточно высока.

    Кроме этого, есть еще два счетчика:

    • Physical Disk, Avg. Disk Read Queue Length
    • Physical Disk, Avg. Disk Write Queue Length

    Эти два счетчика показывают среднюю длину очереди диска – соответственно, на чтение и на запись. Высокие значения этих параметров (выше 2) на небольшие промежутки времени («пики») вполне допустимы, и, к примеру, для СУБД или серверов MS Exchange вполне характерны, но длительные превышения говорят о том, что дисковая подсистема, вероятно, является «узким местом».

    Сетевая подсистема

    Сетевая подсистема бывает «узким местом» намного реже, чем процессор, память и жесткий диск, но тем не менее – о ней не стоит забывать.

    Как и со всеми остальными компонентами – имеется несколько вопросов, на которые неплохо было бы получить ответы еще на этапе планирования:

    • Сколько виртуальных машин будет запущено одновременно, и какова будет нагрузка на сеть?
    • Какова пропускная способность сети?
    • Используются ли системы хранения данных с интерфейсом iSCSI?
    • Есть ли у сервера аппаратные средства удаленного управления, не зависимые от установленной ОС (к примеру – HP iLO или Dell DRAC)?

    В зависимости от ответов возможны разные сценарии настройки сетевой подсистемы. Предположим, что у нас есть всего один сервер. Сетевых интерфейсов у него ровно 4. Запущено всего три виртуальных машины. Out-of-band-management-контроллера у сервера нет, а значит – если случится что плохое – придется бежать в серверную (которая находится на другом конце города).

    На уровне хоста

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

    Кроме этого, на уровне хоста прямо таки необходимо установить как можно более «свежие» драйверы для сетевых адаптеров. Это нужно для того, чтобы воспользоваться специальными функциями сетевых адаптеров – VLAN, Teaming, TCP Offloading, VMQ (при условии, что сами сетевые адаптеры это поддерживают – как правило, это специализированные серверные сетевые адаптеры).

    Сетевые нагрузки

    Предположим, что наши три виртуальные машины какое-то время уже поработали, и анализ трафика показал, что две из них не особо сильно нагружают сетевой интерфейс, а вот третья генерирует очень большие объемы трафика. Наилучшим решением будет «выпустить в мир» виртуальную машину, генерирующую большой объем трафика, через отдельный сетевой интерфейс. Для этого можно создать две виртуальные сети типа External: одну – для тех виртуальных машин, которые не нагружают сеть, и отдельную – для третьей виртуальной машины.

    Кроме этого, можно создавать виртуальную сеть с выходом «наружу», при этом не создавая виртуальный сетевой адаптер в родительской партиции. Делается это с помощью скриптов. В подробности я вдаваться не буду, а просто дам ссылку: http://blogs.msdn.com/b/robertvi/archive/2008/08/27/howto-create-a-virtual-swich-for-external-without-creating-a-virtual-nic-on-the-root.aspx

    iSCSI

    Если планируется использовать системы хранения данных с интерфейсом iSCSI – крайне рекомендуется выделить для работы iSCSI отдельный сетевой интерфейс, а то и два – для работы MPIO. Если LUN’ы будут монтироваться в хостовой ОС – то нужно просто оставить один или два интерфейса не привязанными к виртуальным сетям. Если же iSCSI-инициаторы будут работать внутри виртуальных машин – для них нужно создать одну или две отдельных виртуальных сети, которые будут использоваться исключительно для трафика iSCSI.

    VLAN-тегирование

    VLAN-тегирование (IEEE 802.1q) означает «маркировку» сетевых пакетов специальным маркером (тегом), благодаря которому пакет может быть ассоциирован с определенной виртуальной сетью (VLAN). При этом хосты, принадлежащие к разным VLAN, будут находиться в разных широковещательных доменах, хотя и подключаться физически к одному и тому же оборудованию. Виртуальные сетевые адаптеры в Hyper-V так же поддерживают тегирование VLAN. Для этого нужно зайти в свойства виртуального адаптера в настройках виртуальной машины и прописать там соответствующий VLAN ID.

    Активное оборудование

    До сих пор мы говорили о сетевых интерфейсах и виртуальных сетевых адаптерах в пределах хоста. Но необходимо так же учитывать и пропускную способность активного оборудования – к примеру, коммутаторов, к которым наши хосты будут подключаться. Простой пример: если имеется 8-портовый коммутатор 1Gbps, и каждый из портов утилизирует весь 1Gbps пропускной способности – то 1Gbps-аплинк физически не сможет пропускать такие объемы трафика, что приведет к падению производительности. Особенно это приходится учитывать при использовании iSCSI – нагрузки там могут быть высоки, а задержки пакетов могут быть достаточно критичны для производительности. Поэтому при использовании iSCSI крайне рекомендуется пускать iSCSI-трафик через отдельные коммутаторы.

    Рекомендации для хостовой ОС

    Теперь перейдем к рекомендациям по ОС хоста. Как известно, ОС Windows Server 2008 R2 может быть установлена в двух разных режимах: Full и Server Core. С точки зрения работы гипервизора эти режимы ничем не отличаются. Хотя режим Server Core на первый взгляд кажется сложнее (особенно для малоопытных администраторов), рекомендуется использовать именно этот режим. Установка ОС в режиме Server Core имеет следующие преимущества по сравнению с полной установкой:

    • Меньший объем обновлений
    • Меньшая поверхность атаки для потенциальных злоумышленников
    • Меньшая нагрузка на процессор и память в родительской партиции

    Запуск других приложений в хостовой ОС

    Запуск в гостевой ОС сторонних (не имеющих отношения к Hyper-V) приложений, а так же установка других серверных ролей помимо Hyper-V может привести к сильному падению производительности, а так же к снижению стабильности. Дело в том, что из-за особенностей архитектуры Hyper-V, все взаимодействие виртуальных машин с устройствами проходит через родительскую партицию. Поэтому высокие нагрузки или «падение в синий экран» в родительской партиции обязательно приведут к падению производительности или просто к «падению» всех запущенных виртуальных машин. Сюда же можно (и нужно) отнести антивирусное ПО. Нужно ли оно вообще на хосте, который не будет заниматься ничем, кроме, собственно, виртуализации – это, конечно, тот еще вопрос. Тем не менее, если антивирус все же установлен – первое, что необходимо сделать – исключить из списка проверки все папки, где могут находиться файлы виртуальных машин. В противном случае, при сканировании может замедлиться производительность, а если в каком-нибудь VHD-файле обнаружится что-то похожее на вирус – то при попытке лечения антивирусный пакет может испортить сам VHD. Подобные случаи наблюдались и с базами MS Exchange, и потому первая рекомендация – не ставить вообще на серверах Exchange файловые антивирусы, а если и ставить – то добавить папки с базами в исключения.

    Рекомендации для виртуальных машин

    Шаги, которые необходимы предпринять для повышения производительности самих виртуальных машин – зависят от приложений, которые будут на них выполняться. У Microsoft имеются рекомендации (best practices) для каждого из приложений – Exchange, SQL Server, IIS, и других. Аналогичные рекомендации существуют для ПО других вендоров. Здесь я дам лишь общие рекомендации, не зависящие от конкретного ПО.

    Зачем нужно устанавливать Integration Services в гостевой ОС, как упростить развертывание новых виртуальных машин с помощью библиотеки VHD, и как поддерживать эти VHD в актуальном состоянии с выпуском новых патчей – об этом я и расскажу дальше.

    Сервисы интеграции

    Сервисы интеграции – это набор драйверов, работающих внутри гостевой ОС. Они должны быть установлены сразу после установки ОС. На данный момент список поддерживаемых ОС следующий:

    • Windows 2000 Server SP4
    • Windows Server 2003 SP2
    • Windows Server 2008
    • Windows XP SP2, SP3
    • Windows Vista SP1
    • SUSE Linux Enterprise Server 10 SP3 / 11
    • Red Hat Enterprise Linux 5.2 – 5.5

    ОС Windows 7 и Windows Server 2008 R2 содержат сервисы интеграции в инсталляционном пакете, поэтому на эти ОС их не нужно устанавливать дополнительно.

    Установка интеграционных сервисов позволяет использовать синтетические устройства, имеющие более высокую производительность по сравнению с эмулируемых. Подробнее о разнице между эмулируемыми и синтетическими устройствами – в моей статье об архитектуре Hyper-V.

    Вот список драйверов, входящих в Integration Services:

    • IDE-контроллер – заменяет собой эмулируемый IDE-контроллер, что повышает скорость доступа к дискам
    • SCSI-контроллер – является полностью синтетическим устройством и требует для работы обязательной установки интеграционных сервисов. К каждому SCSI-контроллеру можно подключить до 64 дисков, самих контроллеров может быть до 4 на каждую виртуальную машину.
    • Сетевой адаптер – имеет более высокую производительность, чем эмулируемый (Legacy Network Adapter), и поддерживает особые функции, такие, как VMQ.
    • Видео и мышь – повышают удобство управления виртуальной машиной через ее консоль.

    Помимо перечисленных драйверов, при установке сервисов интеграции поддерживаются следующие функции:

    • Operating System Shutdown – возможность корректного завершения работы гостевой ОС без логина в нее. Аналогично нажатию кнопки Power на корпусе ATX.
    • Time Synchronization – ясно из названия – синхронизация системного времени между хостовой и гостевой ОС.
    • Data Exchange – обмен ключами реестра между гостевой и хостовой ОС. Таким образом, к примеру, гостевая ОС может определить имя хоста, на котором она запущена. Эта возможность доступна только для гостевых ОС семейства MS Windows.
    • Heartbeat – специальный сервис, периодически отправляющий специальные сигналы, означающие, что с виртуальной машиной все в порядке. Если гостевая ОС по какой-то причине, например, зависнет – она перестанет отправлять Heartbeat, и это может служить сигналом, к примеру, для автоматической перезагрузки.
    • Online Backup – представляет из себя VSS Writer, позволяющий в любой момент получить консистентную резервную копию данных виртуальной машины. При запуске резервного копирования через VSS приложения, запущенные на виртуальной машине автоматически сбрасывают данные на диск, и потому бэкап получается консистентным.

    Для установки интеграционных сервисов в ОС Windows нужно выбрать Action – Integration Services Setup. При этом к виртуальной машине автоматически подмонтируется ISO-образ с файлами установки, и запустится процесс инсталляции. Если в гостевой системе отключен запуск Autorun, то процесс инсталляции придется запустить вручную.

    Интеграционные компоненты для Linux не включены в дистрибутив Windows Server – их необходимо загрузить с сайта Microsoft.

    Sysprep: создаем мастер-образ

    Если у вас имеется достаточно большая инфраструктура, и вам приходится часто создавать новые виртуальные машины и устанавливать на них ОС –набор готовых «мастер-образов» виртуальных жестких дисков поможет сильно сэкономить время. Такой «мастер-образ», хранящийся в виде VHD-файла, можно скопировать, а затем создать новую виртуальную машину с использованием VHD в качестве жесткого диска. При этом на нем уже будет установлена ОС и некоторый необходимый набор ПО (в частности – сервисы интеграции).

    Для создания такого мастер-образа необходимо:

    1. Создать новую виртуальную машину
    2. Произвести установку ОС, сервисов интеграции, всех доступных обновлений системы и дополнительного ПО, если таковое необходимо
    3. Подготовить установленную ОС с помощью утилиты Sysprep, которая удалит информацию о пользователе, ключе продукта и уникальный идентификатор (SID).

    При первой загрузке виртуальной машины с такого образа запустится процедура, именуемая «mini-setup». При этом будет предложено заново ввести имя компьютера, пароль администратора, и некоторые другие данные.

    Оффлайн-установка обновлений

    Мы создали мастер-образ, и он будет храниться у нас в течение длительного времени. И все бы ничего, но есть одна небольшая проблема: периодически выходят обновления системы, и при развертывании виртуальной машины с мастер-образа придется установить все обновления, вышедшие с момента создания мастер-образа. Если образ был создан, скажем, год или два тому назад – объем обновлений может быть достаточно большим. Кроме того, сразу после подключения к сети ОС без последних обновлений подвержена всевозможным угрозам безопасности, в том числе – и вирусам. Есть прекрасный инструмент, позволяющий устанавливать обновления прямо на мастер-образы виртуальных машин – он называется «Offline Virtual Machine Servicing Tool». Для его использования необходимо развернуть System Center Virtual Machine Manager (SVMM), а так же иметь развернутый сервер WSUS или SCCM, откуда, собственно говоря, обновления и будут подтягиваться. Принцип его действия следующий:

    1. Виртуальная машина разворачивается на специальном, выбираемом с помощью SCVMM, хосте – так называемый maintenance host.
    2. Виртуальная машина запускается, и на ней производится установка всех необходимых обновлений.
    3. Виртуальная машина останавливается, и VHD-файл возвращается в библиотеку уже с установленными обновлениями.

    Offline Virtual Machine Servicing Tool распространяется бесплатно. Чтобы больше узнать об этом инструменте и скачать его – можно зайти на официальный сайт: http://www.microsoft.com/solutionaccelerators.

    Заключение

    Я дал некоторые рекомендации по настройке хостов и самих виртуальных машин, позволяющей достичь оптимального уровня производительности. Буду надеяться, что для кого-то эта информация окажется полезной.

Комментарии

  1. Статья отличная, спасибо!
    В конце нашёл описку – “Для его использования необходимо развернуть System Center Virtual Machine Manager (SCCM)” – вместо SCCM надо писать SCVMM.

  2. Огромное спасибо, ачипятку пофиксил 🙂

  3. Большое спасибо за статью! С удовольствием дочитал до конца.

  4. Спасибо! С интересом прочитал. Полезно.
    Александр, если вдруг будет время/возможность/желание хотелось бы развернуть тему про внешние СХД.

  5. Александр, спасибо большое, отличная статья!

  6. @СергейК
    А что именно интересует? Тема настолько многогранна, что хватит “Войну и Мир” написать.

  7. Нормальная такая статья, однако генерация нововго сида, актуальность свою потеряла – Руссинович сказал такая функция будет удалена из следующих sysprep-ов

  8. >Сетевая подсистема бывает «узким местом» намного реже, чем процессор, память и жесткий диск

    Можно узнать, откуда взята статистика?

  9. Антон, я кстати с этим согласен – мой теоретический опыт об этом тоже говорит.

  10. @Alexandr
    Ну, кое-кто не то, что от 2003 Server, а даже от XP еще отказаться не может (или не хочет) – так что будет актуально еще лет эдак несколько.

    @Anton Zhbankov
    Из жизни.

  11. @Александр Косивченко
    Про внешние СХД мне интересны начальные бюджетные решения.
    А также кто и как в реальности их начинает использовать.
    Поясню: вот мы небольшая развивающаяся компания.
    Парк 150 комп.+7-8 серверов (из них 6 терминальные для 1с).
    Сейчас смотрю в сторону простой(бесплатной) виртуализации (типа VMware ESXi).
    Хочу её использовать для более легкого переноса серверов с железки на железку- т.е. как бы отделить ПО от железа. Так вот встает вопрос во внешних каких то устройствах хранения для более легкого перемещения/переключения между разными серверами(железками).
    Пока рассматриваю вариант внешнего контейнера для 2-4xHDD в RAID1/5 с eSATA.

  12. @СергейК

    Ну, если бюджетные решения – то есть у HP полка, раньше она называлась MSA2000, сейчас – вроде как-то по-другому. Эта полка вмещает в себя 12 дисков SATA или SAS, и поддерживает установку до 2 контроллеров с интерфейсами SAS, iSCSI или FC.
    Плюс имеется возможность “наращивания” емкости дополнительными, более дешевыми полками (дешевле они потому, что не имеют собственных контроллеров на борту).
    Если совсем-совсем бюджетно – можно взять iSCSI. Минус такого решения в относительно низкой скорости – 1Гбит/с против 3 у SAS и 4 или 8 у FC. Зато дешево и сердито, поскольку в качестве среды используется ethernet. Можно, конечно, попробовать iSCSI через 10GbE, но ХЗ, поддерживают ли его полки, да и свитчи под 10GbE стоят дороговато – вполне сравнимо с FC. Оптимальным решением будет SAS.
    Для построения СХД понадобится: полка с дисками и двумя контроллерами, два SAS-свитча, внешние SAS-кабели и HBA-карточки в сервера (по две на каждый). Два контроллера, свитча и карточки – для отказоустойчивости, чтобы не потерять LUN при падении одного из линков или сгорании какой-нить из железок. Если это не критично – можно взять по 1.
    По точным ценам не скажу, ибо прайсов под рукой сейчас не имею. Можно позвонить в конторы, торгующие серверным железом, на худой конец, чтобы прикинуть порядок цен – посмотреть на яндекс.маркете.

  13. Сейчас она называется HP StorageWorks P2000 G3 Modular Smart Array.
    Полка вмещает 12 3.5″ диска или 24 2.5″, До 8 полок с 3.5″ дисками суммарно или 6 с 2.5″, но не более 149 дисков.

  14. @Александр Косивченко @Anton Zhbankov
    Спасибо за направление.
    Но я так дум. все это минимум от 50-80 тыс.руб., не считая винтов.
    Дороговато для экспериментов. Сейчас у меня на серверах просто RAID1 (на ICH7/8/9R) из пар WD Raptor + 2шт. SCSI 15k. Простой до 1ч. не оч критичен. Из реальности за 1 год – 1 раз 1 винт умер неожиданно. Время восстановления 1 час (и то сами немного ступили).Такой простой за 1 год не критичен. Рук-во считает допустимо. Вот дум. при достаточной надежности/производительности просто хочу их вынести из сервера.
    Итожу: хочу попробовать такое решение:
    (VMWare ESXi)+(поверх W2k,W2k3)
    + 2шт.хВнешний контейнер для 2-4xHDD под RAID1/5 на SATA-II/eSATA
    подключенные просто к каналам SATA-II
    Позволит ли мне такая конфигурация при сбое сервера быстро (ну мин.20-40) перезапустить на другом железе мой сервер? Ну типа контейнеры переподключаем, ESXi с флешки – сервер работает!? 🙂

  15. @СергейК
    Хм.. А есть примеры внешних контейнеров, поддерживаемые ESXi?

  16. @Evg
    Главное, чтобы Host Bus Adapter ESXi поддерживал. А уж какая полка к нему будет подключаться – дело десятое.

  17. @Evg
    Честно говоря я был немного оптимистичен.
    Я не могу пока найти в доступности недорогие контейнеры с eSATA.
    Из того что могло бы подойти на “недорого попробовать” нет в наличии
    Например:ViPowER VPMA-75211R,2 x SATA RAID
    А с поддержкой ESXi не могу сказать, конечно, т.к. только собираюсь попробовать. Но от обратного: если контейнер “выглядит” для мат.платы как SATA диск, то наверное в ESXi достаточно поддержки чипсетного SATA контроллера. Я не прав?
    Но тут другая “засада”. Все RAID внешние контейнеры требуют поддержки SATA Port Multiplier, что есть не везде. Не выяснен вопрос, если нет этой поддержки, совсем не будет видно контейнера, или только конфигурировать будет нельзя. Например подключить к другой машине, настроить RAID1 и воткнуть куда нужно. Минус: даже если и будет работать, пропадет диагностика: вдруг 1 винт уже умер.
    Поэтому начинаю смотреть в сторону бюджетного iSCSI. Спасибо Anton Zhbankov за статью: http://itband.ru/2010/05/cheap-shared-storage-vmware/

  18. я совсем туплю? RAID-контроллер в этом внешнем контейнере должен быть в HCL?
    @СергейК
    Есть еще вариаты типа: http://www.vm4.ru/2010/07/synology-ds1010.html , но они неоправданно дороги имхо.

  19. Александр, раз уж упомянули про счетчики то пожалуйста распишите подробнее простым языком что они означают и какие должны быть их характеристики.
    Memory – что такое available, что такое free? Что означает показатель Pages/Sec какая должна быть норма.
    Physical Disk – Тоже самое с показателем Queue Length, какая должна быть норма и как зависит от количества шпинделей, и что такое шпиндель диск или одна из его пластин? Как определить какая из виртуалок занимает все ресурсы диска и как по отдельности посмотреть сколько ресурсов “едят” виртуалки?
    А где счетчики на сетевые интерфейсы? Как определять какая из виртуалок занимает всю сеть?

    Относительно дисков: есть же разные типы VHD? Какая между ними разница и как они по производительности? Как получается снапшот, как делается испектирование диска и можно ли “смержить” два в один либо разделить из одного в несколько?

    Относительно Hyper-V: следовало бы указать на обновления, потому как очень много ошибок и исправлений имеется http://technet.microsoft.com/en-us/library/ff394763(WS.10).aspx

  20. Если писать “подробно” – можно написать не статью, а целую книгу, поскольку счетчиков существует не одна сотня. По поводу того, какие счетчики существуют, и какие у них должны быть пороговые значения – информация вполне доступна. В частности, мне часто попадолись в вопросах на экзаменах MCSA.

  21. Поймите правильно, я читатель :-), когда читаю и понимаю что не хватает информации возникают закономерные вопросы. И я не прошу писать про все счетчики подробно, я указал на счетчики которые Вы упомянули в своей статье, при этом некоторые вы расписали подробнее, а другие (которые требуют большего понимания) просто сказали что они есть и они чего то меряют. Уверен что если расписать их подробнее то статься увеличится примерно на 1 страницу, но читатею станет гораздо понятнее о чем идет речь.
    Опять же даете совет выделить “загруженную” виртуалку на отдельный интерфейс но не даете читателям понять как определять какая именно грузит, как определить какая грузит интерфейс, и как определить какая грузит диск?

  22. Хорошая обзорная статья, для начинающих, респект за потраченное время, думаю многие коллеги будут рады почитать.

  23. Клаву заглючило, еще раз убеждаюсь что данный ресурс очень полезен для агрегации такой информации, даже по прошествии определенного времени можно нати нужную информацию, сегодня данная статья очень пригодилась в написании обоснования.

  24. Спасибо, Денис!

    P.S. Ты куда пропал? Написал пару фундаментальных статей про AzMan – и все, не видать тебя…

  25. Запуск других приложений в хостовой ОС

    Запуск в _гостевой_ ОС сторонних (не имеющих отношения к Hyper-V)…
    ———-
    Я правильно понял что подчеркнутое слово должно быть “хостовой”?