Журнал о компьютерных сетях и телекоммуникационных технологиях
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК:
    Домой
 
   
АРХИВ ЖУРНАЛА
   

2008: 1 2 3 4 5 6 7 8 9 10 11 12 13
2007: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2006: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2005: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2004: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2003: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2002: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2001: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2000: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
1999: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
1998: 1 2 3 4 5 6 7 8 9 10 11 12
1997: 1 2 3 4 5 6 7 8 9 10 11 12
1996: 1 2 3 4 5 6 7 8 9 10


Rambler's Top100

  

«Вытягиваем» производительность виртуальных машин

Майкл Кейтон

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

Во время нашего тестирования пакета VMware Infrastructure 3 компании VMware нагрузка, вносимая сервером VMware ESX Server, которая в обычных условиях составляла менее 10%, подскакивала аж на 20%. Это отнюдь не означает, что использование VMware помешает работе ваших систем, ведь по большому счету технология виртуализации упрощает консолидирование серверов, тем самым экономя полезную площадь центра обработки данных (ЦОД) и снижая потребление электроэнергии. А двухзначного (в процентах) снижения производительности можно избежать за счет правильного планирования. Но в любом случае некоторого падения производительности вам не избежать.

Тесты, проведенные в нашей лаборатории, позволили выяснить, что главная выгода от ESX Server, как и следовало ожидать, состоит в максимизации использования аппаратных ресурсов за счет возможности запуска на имеющихся серверах большего числа приложений. Дело доходит до того, что эффект от виртуализации может стать неприятным сюрпризом для поставщиков серверов: согласно заключению аналитического агентства Gartner, имеется определенная вероятность, что к 2010 г. эта технология снизит совокупный годовой доход поставщиков Intel-серверов на 0,6%.

Но, как ни странно, когда мы ради шутки спрашивали наших читателей, какие модные технические словечки им надоели больше всего, то вторым по распространенности ответом стала виртуализация (сразу же после SOA). Каждый четвертый респондент не скрывал, что может нанести легкие увечья очередному торговому агенту, который ее упомянет, а 20% заявили, что не понимают, какая им от нее будет выгода.

Как бы то ни было, но виртуализация серверов уже вошла в нашу жизнь, и это хорошо, несмотря на явные проблемы с ее репутацией. Используете ли вы ПО Microsoft Virtual Server, VMware, Xen или любой другой пакет, виртуализация предоставит вам массу выгод, от лучшего использования физических ресурсов до усовершенствованного управления приложениями и возможности разделения ресурсов между компьютерами. За счет использования ВМ можно уменьшить число физических серверов, переводя старые приложения с устаревшего оборудования на более новые системы, которые менее подвержены аппаратным отказам и проще в обслуживании. Мы нашли способы получения максимальной пользы от технологии виртуализации, а наши тесты выявили те области, где потери в производительности при внедрении виртуализации будут наименее ощутимыми.

Полную версию данной статьи смотрите в 12-ом номере журнала за 2007 год.

Типовые применения ВМ

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

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

Что же касается системного управления, то обеспечиваемый виртуализацией уровень мобильности снизит нагрузку на ИТ-персонал в той части, что касается обслуживания оборудования, а также позволит улучшить управление производительностью приложений. Благодаря средствам Vmware виртуализированная среда обеспечивает свое собственное виртуальное оборудование и BIOS, на которые инсталлированы ОС и приложения. Это значительно упрощает для администраторов перевод приложений на другую систему, а сами приложения становятся менее подверженными проблемам совместимости с оборудованием, поскольку виртуальное оборудование остается всегда одним и тем же.

Все это упрощает рутинное техническое обслуживание. Если сервер нужно выключить, то вы просто переводите все ВМ с данного сервера на другие, работающие в среде виртуализации. И доступность приложений при этом не нарушается. Кроме того, если поставщик ПО поддерживает работу своего приложения в виртуальной среде, это позволяет справиться с проблемами аппаратной совместимости, хотя полностью их исключить не удастся из-за необходимости обращения к таким консолидированным устройствам хранения, как подсистемы iSCSI и SAN (Storage Area Network). Здесь по-прежнему требуются специальные драйверы.

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

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

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

Хотя производительность будет колебаться в зависимости от приложения и типа необходимых ему ресурсов — дискового пространства, оперативной памяти, мощности процессора — тут можно дать некоторые рекомендации. Заранее учитывайте издержки виртуализации. Не ожидайте, что виртуальные аппаратные ресурсы дадут вам большую производительность, чем реальное оборудование. Группируйте на одном оборудовании приложения с разными требованиями к ресурсам. Используйте утилиты VMware и средства сторонних поставщиков, облегчающие перевод ВМ на другое оборудование.

Выбирайте с умом

Виртуализация уже по своей природе вносит из-держки в процесс вычислений, и, если сравнивать приложения, работающие на базовом оборудовании, и те, которые запущены на ВМ, разница сразу бросается в глаза. В наших тестах это падение производительности варьировалось от приложения к приложению, но в среднем колебалось около 10% (с минимумом в 6% и максимумом в 20).

Мы провели ряд тестов с приложениями на двух серверах Dell PowerEdge 2850. Обе системы были сконфигурированы одинаково, имели два двухъядерных процессора Intel Xeon, 2-Гбайт ОЗУ и RAID-массив с тремя дисками. Процессоры Xeon поддерживали технологию Intel VT (Virtualization Technology), обеспечивающую микропрограммную оптимизацию для виртуализации ЦПУ. Мы провели базовый набор тестов для трех приложений: Exchange Server 2003, SQL Server 2005 и IIS (Internet Information Server) компании Microsoft, используя комбинацию из бесплатных и коммерческих средств эмуляции нагрузки. Это были утилиты Exchange Server 2003 Load Simulator (LoadSim) и SQLIOSim компании Microsoft, а также SilkPerformer 2006 R2 компании Borland.

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

Воздействие виртуализации на производительность можно рассматривать исходя из двух основных предположений: либо ИТ-подразделение намеревается использовать виртуализацию для максимально полного использования серверов, уже имеющихся у компании, либо оно стремится консолидировать приложения на новом оборудовании. Для базового тестирования мы воспользовались первым предположением о максимизации использования ресурсов серверов.

В этом сценарии (полного использования) системный администратор стремится распределить неэкономно расходуемую память между несколькими ВМ. Предположим, вы заметили, что приложение, работающее на выделенном оборудовании, использует только часть памяти и процессорных ресурсов данного сервера, скажем, 512 Мбайт из 2 Гбайт и 25% мощности 2,8-ГГц процессора. Перевод этого приложения на ESX Server от VMware позволит вам выделить этому приложению 512 Мбайт и 700 МГц и у вас еще останется свободная память и процессорные ресурсы. Поэтому в наших тестах мы делили 2 Гбайт памяти, исходя из нужд приложений, работающих на отдельных экземплярах ВМ. Например, для SQL Server требуется, как минимум, 1 Гбайт ОЗУ, а серверу Exchange Server 2003 достаточно и 512 Мбайт.

У VMware есть технология постраничного разделения памяти, позволяющая администратору распределять между ВМ память, превосходящую суммарную физическую память серверов. Эта технология постраничного разделения памяти позволяет ПО VMware Infrastructure 3 выделять по меньшей мере в три раза больше виртуальной памяти, чем имеется физической памяти, при работе тех же самых ОС (в среде АМ) на том же оборудовании. Это очень полезно в тех случаях, когда вы хотите консолидировать несколько редко используемых приложений, таких, как файловые сервисы и сервисы печати, размещенные на отдельных серверах. На одном сервере может работать дюжина ВМ, поскольку маловероятно, что всем этим системам одновременно потребуется полная процессорная мощность и вся память, и даже если спрос превысит имеющиеся ресурсы, то снижение их производительности не станет проблемой.

С архитектурной точки зрения ESX Server 2.0 использует «пустую» ОС Linux для хостирования ВМ, затем абстрагирует оборудование ВМ через общий виртуальный BIOS и виртуальные драйверы устройств. В наших первоначальных тестах мы измеряли падение производительности на этих двух уровнях, учитывая уменьшение памяти, доступной каждой ВМ; сам ESX Server требует примерно 200 Мбайт памяти.

Хотелось бы отметить, что VMware проделала отличную работу, создав среду, позволяющую приложениям работать с высоким уровнем производительности при невысоких накладных расходах, благодаря общим драйверам устройств и среде хостинга ВМ на базе Linux. Мы могли работать с относительно требовательными приложениями, такими, как Exchange Server 2003 и SQL Server 2005, и при этом наблюдалось лишь 6%-ное падение производительности. В обоих тестах —SQLIOSim для SQL Server (рис. 1) и LoadSim для Exchange (рис. 2) — на загрузку сильно влияли операции чтения и записи на жесткий диск. Таким образом, чтобы минимизировать падение производительности таких приложений, нужно исключить конкуренцию между ВМ за доступ к дисковой памяти.

Но где мы увидели существенное снижение производительности, так это в нашем тесте с интрасетью, в котором использовался инструментарий Silk-Performer 2006 для тестирования производительности IIS. Мы наблюдали падение производительности на 18% (если измерять в количестве запросов в секунду) или на 20% (если измерять в килобайтах в секунду — рис. 3). В отличие от тестов с SQL Server и Exchange здесь мы увидели реальную «плату» за переход из реальной системы с 2 Гбайт ОЗУ на ВМ с 512 Мбайт. При меньшей памяти производительность системы здесь пострадала значительно сильнее, чем в тестах, более связанных с дисковыми операциями.

Добавление ресурсов

Как и ожидалось, мы смогли улучшить производительность за счет добавления памяти ВМ, используемой в нашем тесте с интрасетью (см. рис. 3). Увеличение памяти с 512 Мбайт до 1 Гбайт повысило пропускную способность на 10% и уменьшило падение производительности по сравнению с базовой аппаратной системой с 20 до 12%, из чего можно сделать вывод, что приложения с высокими требованиями к объему памяти выиграют от выделения ВМ максимально возможной физической памяти.

В процессе тестирования мы также пытались понять, как на системную производительность повлияет добавление второго виртуального сетевого адаптера, но никакого улучшения не заметили. Аналогично и в наших тестах с SQL Server мы не увидели никакого повышения производительности от увеличения системной памяти, поскольку здесь основную роль играли операции с диском.

В нашем базовом тесте оборудования участвовали два двухъядерных 64-разрядных процессора Xeon с частотой 2,7 ГГц. ESX Server позволил нам выделять их только как 32-разрядный процессор, и хотя ESX Server может выполнять 64-разрядный код для управления самой средой ВМ, но внутри этих ВМ мы запускали только 32-разрядные ОС и приложения. (Впрочем, для ясности надо отметить, что ESX Server все же поддерживает 64-разрядные ОС, а значит, вы можете развертывать под управлением VMware и 64-разрядные приложения.)

Доступные для распределения ресурсы включали в себя и тактовую частоту ЦПУ в мегагерцах, ведь, поскольку теоретически работа процессора делится на циклы, он может поделить их между ВМ. Число процессоров тоже настраиваемый ресурс: мы могли создать машины с числом процессоров более четырех, используя при этом два двухъядерных процессора нашего сервера.

Хотя мы могли добавить сетевые платы к ВМ, но ESX Server не поддерживает динамического выделения системе дискового пространства, если только вы не используете автономное устройство хранения. С практической точки зрения это было самым проблематичным в нашем тестировании. Размер образа ВМ, включающего дисковое пространство, может стать решающим фактором при принятии решения о числе ВМ, которые могут работать в данной системе. По умолчанию ESX Server выделяет каждой ВМ 4 Гбайт дискового пространства. В нашей тестовой системе мы выделяли им, как минимум, по 10 Гбайт, чтобы быть уверенными, что у нас будет достаточно места для инсталляции приложений и будущих обновлений. Таким образом, наша система, располагающая 128 Гбайт дискового пространства, имела достаточно места для десяти ВМ.

Однако, если по какой-либо причине вам потребуется перенести экземпляр ВМ с данного сервера, освободившееся дисковое пространство нельзя будет перераспределить между другими ВМ.

Судя по результатам нашего тестирования, справедливо утверждать, что не следует ожидать превосходной производительности от приложений, когда на одном и том же сервере работает множество приложений с высокой дисковой нагрузкой, если только каждое из них не имеет выделенной подсистемы хранения данных, такой, как SAN. Например, мы заставили две ВМ с загруженными на них серверами Exchange Server 2003 и SQL Server 2005 компании Microsoft работать на одном и том же оборудовании и увидели, что результаты тестов, когда оба приложения нагружали дисковые подсистемы, резко отличались от аналогичных результатов, когда Exchange нагружал дисковую подсистему, а SQL Server работал главным образом в памяти.

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

Распределение нагрузки

Серьезным вопросом, с которым, по всей видимости, придется столкнуться вашему ИТ-отделу при переходе на ESX Server, станет то, как развернуть критически важные приложения при помощи ВМ-технологии таким образом, чтобы при этом не слишком пострадала их производительность. К счастью, у ESX Server есть средства, позволяющие решить этот вопрос с помощью приоритизации производительности приложений за счет сегментирования аппаратных ресурсов между ВМ. В наших тестах мы убедились, что эта возможность может помочь в обеспечении заданного уровня обслуживания.

Мы использовали SQLIOSim для измерения производительности системы при обычной нагрузке и нагрузке в условиях приоритизации, а LoadSim — для генерации конкурирующей нагрузки. Сначала мы измеряли производительность при двух ВМ, разделяющих между собой доступные 4,7 ГГц процессорной мощности. В этой конфигурации в тесте с интенсивной нагрузкой на память падение производительности колебалось между 4 и 7%. Затем мы выделили 3 ГГц процессорной мощности системе SQLIOSim, а оставшиеся 1,7 ГГц — тестовой системе LoadSim. Производительность вернулась к уровню, который мы наблюдали при работе SQLIOSim без всякой конкуренции за ресурсы. ESX Server использует тот же интерфейс и соглашения о выделении мощности ЦПУ и системной памяти через интерфейс Virtual Infrastructure Client. Мы могли задавать производительность ЦПУ в процентах от доступной тактовой частоты или как конкретное число в мегагерцах, а также просто задать число доступных процессоров. Что же касается выделения памяти, тут мы могли задавать процент от доступной памяти или конкретный объем памяти в мегабайтах для данной ВМ.

Планируйте хорошенько

Хотя VMware предоставляет средства, помогающие управлять производительностью приложений, полностью автоматизировать этот процесс, исключив из него человека, пока не удается. Прежде чем переходить на ESX Server, выделите время для определения профилей производительности, чтобы быть уверенным, что пользователи не сильно потеряют в производительности приложений после такого перехода. И учитывайте объем доступных ресурсов, требуемых данному приложению не только в обычных условиях, но и при пиковой нагрузке.

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

Консоль Virtual Infrastructure Client, используемая для управления образами ВМ, имеет набор средств для мониторинга производительности ВМ, единственное, чего ей не хватает, так это возможности адаптивно назначать ресурсы на базе пороговых значений загрузки. Так, чтобы если использование ЦПУ какой-то ВМ вдруг превысило определенный уровень, то ESX Server мог бы автоматически выделить ей больше ресурсов за счет менее критичных ВМ.

Одной из трудных задач, которую перед вами поставит технология ВМ, станет обеспечение адекватной реакции на меняющуюся нагрузку со стороны пользователей на одно из приложений. Некоторые приложения будут временами становиться более важными и испытывать повышение нагрузки, тогда как другие — терять «популярность», что будет сопровождаться снижением нагрузки. Что является явным достоинством пакета VMware Infrastructure 3, так это возможность переводить ВМ на другое оборудование по мере изменения требований.

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

Итак, технология виртуализации на базе ПО ESX Server в пакете VMware Infrastructure 3 позволяет максимизировать использование серверного оборудования при условии, что вы найдете время для анализа производительности приложений. Используйте технологию ВМ, не забывая при этом анализировать профили производительности приложений при запуске их ВМ на одном оборудовании, чтобы те не конкурировали за дефицитные ресурсы. Одним из самых узких мест в плане производительности станет для ВМ доступ к жестким дискам, поэтому используйте такие технологии хранения, как iSCSI и SAN, чтобы переместить запросы на сохранение файлов с оборудования ВМ на устройства, выделенные конкретному приложению.

Примите во внимание, что использование самой по себе среды ESX Server влечет падение производительности по меньшей мере на 6–10%. А в принципе, производительность может упасть и на все 20%. И учитывайте в своих планах, что каждая дополнительная ВМ «съест» еще 6–10% от общей производительности, даже если приложения на этой ВМ используются мало..

  
12 '2007
СОДЕРЖАНИЕ

инфраструктура

• Стандарт 802.11r для безопасной Wi-Fi-мобильности

• Отвод тепла от стоичного оборудования в ЦОДах

• Удаленное управление по дополнительному каналу

сети связи

• Качество речи в IP-сетях

• Гладкий межсетевой роуминг-почти реальность

кабельные системы

• Оптические инфраструктуры: волокна и кабели

• Кабельные каналы для сетей 10-Gigabit Ethernet

• Прокладка кабелей в ЦОДе: под фальшполом или у потолка?

информационные системы

• Здравствуй бизнес-интеллект!

• "Вытягиваем" производительность виртуальных машин

защита данных

• Контроль за безопасностью приложений Ajax

новые продукты

• MetroScope - комплексное решение для тестирования сетей Ethernet/IP;ИБП серии ITYS компании Socomec UPS


• Калейдоскоп


Реклама:
 Copyright © 1996-2008 ООО "Сети и Системы Связи". вверх