Рис.9. Распределение процессорного времени между ВМ.
-
Проведение экспериментов (тестирования системы) на стенде облачной системы
-
Описание экспериментов
Существует сервер, а также две виртуальные машины с одинаковыми параметрами, конфигурации которых были указаны в предыдущем разделе. Они соединены между собой в локальную сеть, а также имеется доступ в интернет. Ко всем файлам на виртуальных машинах и некоторым на сервере открыт общий доступ, а так же на сервере создан сетевой диск, доступ к которому может получить любой клиент системы. На каждой ВМ (Виртуальной машине) установлен некоторый набор приложений, таких как MS Office, средства работы с виртуальными дисковыми накопителями, средства для просмотра аудио/видео файлов, и базовые программы, входящие в состав ОС.
Сначала мы протестируем, как облачная система будет работать в условиях различной нагрузки на неё.
-
Инструменты для тестирования
Для тестирования нагрузки будут использоваться:
Для тестирования нагрузки на систему используются следующие инструменты: Монитор ресурсов Windows [37,39], системный монитор Windows, диспетчер задач Windows, Диспетчер Hyper-V, продукция компании Veeam ONE, Windows power shell [36, 45], планировщик задач ОС.
На сервере – Veeam ONE Monitor для слежения за процессором, памятью и дисками в режиме реального времени. Так же с помощью встроенной в ОС программы «Системный монитор» мы будем записывать логи производительности сервера для последующего анализа нагрузки на оборудование.
Диспетчер Hyper-V и монитор ресурсов будут вспомогательными приложениями, с помощью которых мы будем также наблюдать за состоянием облачной системы, и сравнивать результаты с полученными из других программ.
На виртуальных машинах также будет использован системный монитор для записи логов производительности каждой машины в отдельности.
Также будет произведен математический расчет по модели гипервизора Microsoft Client Hyper-V.
Для полной картины нагрузки будут использоваться команды модуля Hyper-V [36, 37] в Windows PowerShell [36,45].
-
Этапы тестирования
-
Создание тестов производительности
-
Выполнение тестов
-
Анализ результатов тестов производительности
-
Проведение расчетов по математической модели
-
Оптимизация параметров гипервизора с учетом результатов экспериментов
-
Создание тестов производительности
Для тестов используется созданный файл с расширением .bat, при исполнении которого, происходит запуск заданного числа программ с интервалом во времени. На каждой из ВМ создан свой файл с различными инструкциями запуска приложений. Файлы тестирования .bat на двух ВМ различаются интервалом запуска процессов и временем жизни процессов. Оба файла запускаются одновременно с помощью планировщика задач Windows. Вместе с началом выполнения сценариев, запрограммированных в файлах тестирования, начинается сбор сведений о производительности и нагрузке на системы с помощью сборщиков данных системного монитора Windows. Сбор сведений для анализа производится как на ВМ, так и на сервере. Вместе с этим, программа Veeam ONE Monitor, запущенная на сервере, анализирует сведения о нагрузке на сам сервер, а также на гостевые ВМ (т. е. на облачную систему в комплексе). Данное приложение с помощью графиков показывает изменения, происходящие в «облаке» в режиме реального времени.
Для полноты тестирования, оно проводится несколько раз с различными параметрами и величиной нагрузки.
Для того, чтобы выяснить, как будет реагировать система в целом, а также клиентские машины в отдельности, моделируется нагрузка в различных ситуациях. В файлах .bat для каждой ситуации задается различное время жизни запущенных приложений (процессов) и различный интервал выполнения приложений.
Тесты:
-
На 1 ВМ запускаются 11 приложений с интервалом в 1 секунду, на 2 ВМ – 12 приложений. Срок жизни процесса – бессрочно в обоих случаях.
-
На 1 ВМ запускаются 5 приложений с интервалом 5 секунд, срок жизни – 1 минута у каждого. На 2 ВМ – 10 приложений с интервалом 5 секунд, срок жизни – бессрочно.
-
На 1 ВМ запускаются 5 приложений с интервалом 30 секунд, срок жизни каждого приложения – 1 минута, на 2 ВМ – 10 приложений с интервалом 30 секунд, срок жизни – бессрочно.
-
На 1 ВМ запускается 9 приложений с интервалом 1 минута, срок жизни каждого процесса 1 минута, на 2 ВМ – 10 приложений с интервалом в 1 минуту, срок жизни – бессрочно.
-
На 1 ВМ запускается 10 приложений с интервалом в 5 минут, срок жизни каждого приложения – 1 минута, на 2 ВМ – 10 приложений с интервалом 100 секунд, срок жизни – бессрочно.
В каждом случае запуск файлов .bat начинается одновременно с помощью планировщика задач, чтобы проанализировать, как система реагирует на одновременную загрузку клиентских машин, и как ресурсы будут распределяться между ними в процессе работы. Цель данных тестов – анализ механизма распределения имеющихся физических ресурсов между виртуальными машинами в зависимости от ситуации. Например, как будет себя вести система в случае, если несколько клиентов начнут одновременное выполнение ресурсоемких задач, и как ресурсы будут распределяться в зависимости от освобождения или нехватки в определенный момент времени. Это нужно для оптимизации имеющихся ресурсов с целью повышения производительности системы.
Пример содержания файла .bat для случая когда приложения открываются с интервалом в 1 секунду:
@Echo Off
start "" "C:\Program Files (x86)\Microsoft Office\Office12\excel.exe"
ping -n 1 localhost>nul
start "" "C:\Program Files (x86)\Microsoft Office\Office12\winword.exe"
ping -n 1 localhost>nul
start "" "C:\Program Files (x86)\Microsoft Office\Office12\msaccess.exe"
ping -n 1 localhost>nul
start "" "C:\Program Files (x86)\Microsoft Office\Office12\powerpnt.exe"
ping -n 1 localhost>nul
start "" "C:\Program Files (x86)\Microsoft Office\Office12\outlook.exe"
ping -n 1 localhost>nul
start "" "C:\Program Files (x86)\Mozilla Firefox\firefox.exe"
ping -n 1 localhost>nul
start "" "C:\Program Files (x86)\Internet Explorer\iexplore.exe"
ping -n 1 localhost>nul
start "" "C:\Program Files (x86)\Windows Media Player\wmplayer.exe"
ping -n 1 localhost>nul
start "" "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe"
ping -n 1 localhost>nul
start "" "C:\Program Files (x86)\Alcohol Soft\Alcohol 120\alcohol.exe"
ping -n 1 localhost>nul
start "" "C:\Program Files\Microsoft Games\Solitaire\solitaire.exe"
ping -n 1 localhost>nul
start "" "C:\Program Files\Microsoft Games\MineSweeper\MineSweeper.exe"
exit
Для изменения интервалов запуска процессов используется команда ping, которая задает задержку во времени между выполнением команды запуска приложений.
-
Выполнение тестов производительности
В результате тестов было выявлено, что быстродействие системы выше, когда приложения запускаются с наибольшим интервалом во времени, а также начиная с интервалом в больше минуты. Данные результаты говорят о том, что ресурсы, а особенно память, возвращаются гипервизору не сразу после завершения работы процесса, а после некоторого промежутка времени, в течение которого виртуальная машина удерживает их у себя в распоряжении для дальнейшего использования. Данный момент обусловлен тем, что виртуальная машина рассчитывает, что ресурсы могут понадобиться в небольшой промежуток времени после выполнения задачи, и, чтобы не произошло ситуации, когда ресурсы отданы обратно гипервизору для дальнейшего распределения, в то время как виртуальной машине они снова понадобились.
В процессе экспериментов было замечено, что больше всего высокой нагрузке подвергаются память и жесткий диск. Данная проблема возникает потому, что память является самым часто используемым ресурсом, плюс многие приложения резервируют для себя память, не выгружая её из своего распоряжения. В случае, когда в системе заканчивается доступная память, виртуальные машины начинают использовать файл подкачки, расположенный на жестком диске, в результате чего происходит превышение нагрузки на виртуальные машины и систему.
В случае, когда на обе виртуальные машины была высокая нагрузка, производительность как системы, так и виртуальных машин существенно снижалась, однако это не привело к остановке работы системы.(Рис.10 и Рис.11).
Рис.10. Высокая нагрузка на систему. Win7_2
Рис.10. Высокая нагрузка на систему. Win 7.
Как видно из Рис.10 и Рис.11, при высокой интенсивности запросов пользователей системы, на виртуальных машинах перегрузке подвергаются ОЗУ и диск. Как было сказано выше, несмотря на эти факторы, системы остается в работоспособном состоянии.
Далее, в соответствии с разработанными тестами, следуют результаты работы системы для каждого из тестов. Поведение системы и виртуальных машин в отдельности можно наблюдать на рис. 11 – рис. 31. Изображения с результатами разбиты по категориям, каждая из которых соответствует аналогичному тесту.
-
Память.
-
Тест 1 Sec.
Рис.11. Win 7 – память, тест 1 sec
Рис.11.1. Win 7_2 – память, тест 1 sec
Рис.11.2. Win 7_2 – память, тест 1sec
Рис.11.3. Win 7 – память, тест 1 sec
Рис.11.4. Win 7 – общая статистика, тест 1 sec
Рис.11.5. Win 7_2 – общая статистика, тест 1 sec
Из рисунков видно, что в случае, когда задачи запускаются с интервалом в одну секунду одновременно на обеих ВМ, тогда, как виртуальные машины, так и система в целом испытывают на себе высокую нагрузку.
-
Тест 5 sec
Рис.12. Win 7 - память, тест 5sec
Рис.12.1. Win 7 - память, тест 5sec
Рис.12.2. Win 7_2 - память, тест 5sec
Рис.12.3. Win 7_2 - память, тест 5sec
-
Тест 30 sec
Рис.13. Win 7_2 - память, тест 30 sec
Рис.13.1. Win 7_2 - память, тест 30 sec
Рис.13.2. Win 7 - память, тест 30 sec
Рис.13.3. Win 7- память, тест 30 sec
Так как при данном тесте на виртуальной машине Win 7 приложения запускались с интервалом в 30 секунд и временем жизни 1 минута, а на виртуальной машине Win7_2 с интервалом 1 секунда и бессрочным сроком существования, нагрузка на Win 7 отказалась существенно меньше, что мы можем наблюдать на рисунках выше.
-
Тест 1 min
Рис.14. Win 7 - память, тест 1 min
Рис.14.1. Win 7 - память, тест 1 min
Ситуация примерно такая же, как и в случае с 30 секундами. Существенных различий не наблюдается, так как виртуальная машина Win7_2 забирает свободные ресурсы для своих задач. Отображаемая нагрузка на Win 7 не совсем корректна, так как в ней учитывается отданная доля другой виртуальной машине.
-
Тест 5 min
Рис.15. Win 7 - память, тест 5 min
Рис.15.1. Win 7_2 - память, тест 5 min
В процессе данного теста была выявлена наименьшая нагрузка как на виртуальные машины, так и на систему в целом. Данные результаты показывают, что когда одна из виртуальных машин почти не использует ресурсов, вторая виртуальная машина забирает свободные ресурсы для себя. В результате, система испытывает минимальную нагрузку.
-
Процессор
-
Тест 1 sec
Рис.16. Win 7 - процессор, тест 1 sec
Рис.16.1. Win 7_2 - процессор, тест 1 sec
Рис.16.2. Win 7_2 - процессор, тест 1 sec
Рис.16.3. Win 7 - процессор, тест 1 sec
Даже при высокой интенсивности запросов к виртуальным машинам, процессор функционирует в нормальном режиме и нагрузка не превышает 40%, что является очень хорошим результатом.
-
Тест 5 sec
Рис.17. Win 7 - процессор, тест 5 sec
Рис.17. Win 7_2 - процессор, тест 5 sec
При незначительном увеличении временного интервала запросов, нагрузка на процессор снизилась в несколько раз.
-
Тест 30 sec
Рис.18. Win 7 - процессор, тест 30 sec
Рис.18.1. Win 7 - процессор, тест 30 sec
Рис.18.2. Win 7_2 - процессор, тест 30 sec
Рис.18.3. Win 7_2 - процессор, тест 30 sec
Скачок нагрузки на процессор в данном случае обусловлен тем, что виртуальная машина Win7_2 забрала часть процессорных ресурсов для своих нужд. В целом, когда непредвиденная ситуация завершилась, загрузка процессора уменьшилась до 1-2%.
-
Тест 1 min
Рис.19. Win 7 - процессор, тест 1 min
Рис.19.1. Win 7_2 - процессор, тест 1 min
Как и предполагалось, виртуальная машина Win 7 почти не потребляет процессорных ресурсов, ввиду большого интервала выполнения задач и малого срока жизни.
-
Тест 5 min
Рис.20. Win 7 - процессор, тест 5 min
Рис.20.1. Win 7_2 - процессор, тест 5 min
Нагрузка на виртуальный процессор Win 7 находится на уровне 1-2% на всем протяжении текущего эксперимента, что очевидно при малой интенсивности потока запросов. Win7_2 выполняет задачи на процессоре в штатном режиме и потери быстродействия обнаружено не было.
-
Диск
-
Тест 5 sec
Рис.21. Win 7 – диск, тест 5 sec
Рис.21.1. Win 7 – диск, тест 5 sec
Диск является одним из самых загруженных элементов системы наравне с памятью. Основная потеря быстродействия виртуальных машин происходит из-за активного использования файла подкачки виртуальными машинами. Именно эту ситуацию мы наблюдаем при высокой интенсивности потока запросов в систему.
-
Тест 30 sec
Рис.22. Win 7 – диск, тест 30 sec
Рис.22.1. Win 7_2 – диск, тест 30 sec
Как и в предыдущем случае, нагрузка на диск до сих пор велика несмотря на снижение интенсивности потока запросов в систему. Однако, работоспособность системы находится на нормальном уровне.
-
Тест 1 min
Рис.23. Win 7 – диск, тест 1 min
Рис.23.1. Win 7_2 – диск, тест 1 min
Нагрузка на жесткий диск является самым труднооптимизируемым параметром системы. Решением данной проблемы может стать увеличения физической оперативной памяти сервера, а также установка дополнительных жестких дисков.
-
Тест 5 min
Рис.24. Win 7 – диск, тест 5 min
Рис.24.1. Win 7_2 – диск, тест 5 min
Как видно из рисунков, при интервале запросов 5 минут на виртуальной машине Win 7, нагрузка на жесткий диск относительно стабильна. Суть проблемы в том, что виртуальные машины используют виртуальные жесткие диски, расположенные на одном физическом.
-
Общая нагрузка
-
Тест 1 sec
Рис.25. Win 7_2 – общие показатели, тест 1 sec
Рис.25.1. Win 7 – общие показатели, тест 1 sec
Нагрузка на сервер (память)
Рис.26. Сервер – память, тест 1 sec
Нагрузка на сервер (Процессор)
Рис.26.1. Сервер - процессор, тест 1 sec
Рис.27. Общие показатели, тест 1 sec
-
Тест 5 sec
Рис.28. Общие показатели, тест 5 sec
Рис.28.1. Win 7 - Общие показатели, тест 5 sec
Рис.28.2. Win 7_2 - Общие показатели, тест 5 sec
-
Тест 30 sec
Рис.29. Win 7 - Общие показатели, тест 30 sec
Рис.29.1. Win 7_2 - Общие показатели, тест 30 sec
Рис.29.2. Win 7 - Общие показатели, тест 30 sec
Рис.29.3. Win 7_2 - Общие показатели, тест 30 sec
Рис.29.4. Общие показатели, тест 30 sec
-
1 min
Рис.30. Win 7 - Общие показатели, тест 1 min
Значение 102% нагрузки на память, как говорилось ранее, не является реальным, а учитывает отданные другой ВМ ресурсы.
Рис.30.1. Win 7_2 - Общие показатели, тест 1 min
Рис.30.2. Общие показатели, тест 1 min
-
Тест 5 min
Рис.31. Win 7 - Общие показатели, тест 5 min
Рис.31.1. Win 7_2 - Общие показатели, тест 5 min
Рис.31.2. Общие показатели, тест 5 min
Рис.31.3. Общие показатели, тест 5 min
Рис.31.4 Win 7 - Общие показатели, тест 5 min
Рис.31.5. Win 7_2 - Общие показатели, тест 5 min
Из графиков (рис.11 – рис.31.) видно, что процессор в течении тестирования не удалось загрузить на максимальные значения, однако свободной памяти почти не осталось и виртуальные машины встали в очередь за ресурсами, которые гипервизор выделял в процессе освобождения. Так же можно наблюдать, что самым загруженным компонентом системы является виртуальный жесткий диск, так как при достижении предела выделенной физической памяти, виртуальные машины начинают активно использовать файл подкачки. После снижения интенсивности нагрузки на виртуальные машины, виртуальные машины стали функционировать в обычном режиме (Рис.32. и Рис.32.1.).
Рис.32. Снижение интенсивности нагрузки, память
Рис.32.1 Снижение интенсивности нагрузки, процессор
Важно отметить, что первоначально ресурсы сервера, доступные обеим виртуальным машинам, не были ограничены совсем. В данном случае, виртуальные машины не испытывали проблем с быстродействием, но сервер получал ощутимую нагрузку, вследствие чего производительность системы в целом была удовлетворительная.
Так же на начальном этапе тестирования не были заданы веса ресурсов для всех виртуальных машин. Это приводило к тому, что при нехватке ресурсов, гипервизор не перераспределял ресурсы между виртуальными машинами, а предоставлял их за счет мощностей сервера. Данный механизм нам совершенно не подходит из-за чрезмерной нагрузки на сервер, которой в свою очередь должен выполнять собственные задачи, помимо поддержания работоспособности в нашей облачной системе. Вследствие этого, гипервизор был настроен на ограничение использования ресурсов сервера виртуальными машинами. Подробнее о последующих конфигурациях облачной системы будет описано в следующих разделах.
Стоит заметить, что в условиях реального использовании системы клиентами, не происходит столь активного использования приложений на виртуальных машинах. Так что, с учетом этого, система не должна получать столь значительных нагрузок. Но целью наших тестов было выяснить, как ведет себя гипервизор и гостевые ОС в ситуации перегрузок.
В процессе тестирования механизма распределения ресурсов гипервизора был проведен тест, при котором запускалось по 3-4 приложения на каждой машине с различными интервалами во времени. В условиях столь низкой нагрузки, виртуальные машины использовали всего лишь 30% имеющихся в их распоряжении ресурсов. В момент, когда количество приложений и интенсивность их использования и запуска существенно увеличивалась, каждая из виртуальных машин была загружена на 95%. Эти цифры не означают, что система зависала и переставала работать. В этом случае быстродействие понижалось, но функционирование системы не было нарушено. Процессы просто ожидали освобождения ресурсов, и выполнялись когда таковые были выделены гипервизором. Важно уточнить, что помимо пользовательских приложений, виртуальная машина требует ресурсов для своего функционирования – запуска и поддержания работы операционной системы, системных служб и фоновых приложений. Затраты мощностей на данные задачи в нашем случае (ОС windows 7 - требует 512 МБ для запуска и примерно 400 МБ в процессе функционирования в зависимости от количества включенных служб и фоновых системных приложений) составляют примерно 30% от выделенных ей ресурсов. Далее приведено изображение нагрузки на виртуальную машину Win 7 при больших интервалах запуска приложений (Рис.33.).
Рис.33. Малая нагрузка на виртуальную машину
Как видно из изображения, виртуальный процессор работает всего на 1% от имеющейся мощности, а память используется всего на 50% (550/1000 МБ). Отображаемый 101% нагрузки не является реальной нагрузкой на данную ВМ. В данном случае, приложения, функционирующие на Win 7 резервируют память «на запас», а то время как на самом деле, не являются активными и ресурсы им не требуются. В это время на виртуальной машине Win7_2 происходит выполнение нескольких программ, и гипервизор перераспределил ресурсы виртуальных машин в сторону Win7_2. После завершения работы приложений на Win7_2, ОС на Win7_2 выгрузила ненужные ей ресурсы и отдала их под управление гипервизора (Рис.34).
Рис.34. Приватизация ресурсов виртуальной машиной. Сравнить с Рис.33.
В процессе работы выкокой нагрузки на виртуальный коммутатор и сеть выявлено не было.
Данные тесты позволили проверить механизм управления виртуальной системой гипервизором.
-
Анализ результатов тестов производительности
Управление и организация работы Hyper-V проводилась с помощью инструментов Windows PowerShell, в том числе установленного дополнительно модуля команд для гипервизора PS Hyper-V R2 [5,6]. Дополнительно к этому использовалась среда отладки и выполнения команд Windows Power Shell ISE, в которой описаны все возможные команды, их аргументы и параметры. Данный программный модуль позволил быстро и точно задать нужные параметры для виртуальных машин, сервера, и ресурсов. Так же для этих целей использовался Hyper-V Manager, однако удобство графического интерфейса настройки гипервизора и системы ограничено отсутствием некоторых настроек, доступных только из командной строки.
В ходе экспериментов были выявлены такие проблемы как потеря производительности виртуальных машин, уменьшение быстродействия сервера. Далее о каждой проблеме будет описано подробнее.
На начальном этапе, ресурсы, доступные виртуальным машинам ограничены не были. Это приводило к высокой нагрузке на сервер, вследствие чего были выставлены некоторые ограничения.
Различные веса ресурсов для виртуальных машин были выставлены с целью изучения механизма распределения ресурсов и дальнейшей оптимизации системы.
-
Память
Для win 7 вес памяти - высокий , win7_2 - ниже среднего. Буфер памяти в обоих случаях – 10%.
-
Процессор
Для Win 7 резерв ресурсов процессора - 5% от общих системных ресурсов, вес ресурсов - 150, для Win7_2 – аналогичные параметры, однако вес ресурсов установлен 100. Предел использования ресурсов процессора – 30% от мощности сервера для каждой из ВМ.
Данные изменения привели к тому, что система стала работать быстрее, а также мы смогли проанализировать взаимодействие виртуальных машин.
После изменений параметров гипервизора снова были проведены те же тесты, которые показали следующий результат:
Результаты повторного тестирования для некоторых параметров системы приведены на рис.35. и рис.36.
Рис.35. Результат оптимизации работы гипервизора, Win 7, тест 1 sec
Win7_2, 1 sec интервал
Рис.35.1. Результат оптимизации работы гипервизора, Win 7_2, 1 sec
Рис.36. Результат оптимизации работы гипервизора, Win 7, тест 5 min
Win7_2, 5 min интервал
Рис.36.1. Результат оптимизации работы гипервизора, Win 7_2, тест 5 min
В ходе тестирования было выявлено, что виртуальная машина Win 7 имеющая более высокий вес ресурсов, получает их быстрее и выгрузка ресурсов из неё происходит медленнее. Также Win 7 в несколько раз больше проводит времени в привилегированном режиме работы. Это означает, что она чаще получает контроль над элементами управления системой облачных вычислений для выполнения требуемых операций.
В то же время, если у Win 7 освобождаются ресурсы, которые требуются другой виртуальной машине, она отдает их гипервизору, который в свою очередь, решает куда перенаправить их дальше.
Во время тестирования было выявлено, что в процессе работы виртуальных машин, при больших нагрузках на них, происходит перегрузка жесткого диска на сервере, так как виртуальные машины и сам сервер используют помимо физической памяти, виртуальную. Виртуальные машины при недостатке выделенной памяти начинают активно использовать файл подкачки, расположенный на виртуальных жестких дисках, связанных с физическим на сервере. Скорость доступа к диску и обработка данных на нем существенно меньше скорости оперативной памяти. Вследствие этого, система теряет своё быстродействие в несколько раз, как видно на рис.37.
Рис.37. Перегрузка жесткого диска на виртуальной машине
Для решения данной проблемы пришлось ограничить файл подкачки на виртуальных машинах почти в 2 раза. На обоих ВМ его размер составил 512 мб.
Также для увеличения быстродействия виртуальных машин было задано соответствие между самой машиной и виртуальными процессорами. Каждая из ВМ получила в своё распоряжение по 2 различных логических процессора сервера.
-
Сервер
Для сервера было зарезервировано 500 МБ оперативной памяти, доступ к которой не могут получить виртуальные машины. Данное ограничение задано для того, чтобы сервер мог корректно функционировать при высокой нагрузке на систему, так как виртуальные машины могут забрать нужные серверу ресурсы для корректной работы. Для этого в разделе реестра:
HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Virtualization создан резерв памяти (ключ типа DWORD с названием MemoryReserve)
-
Жесткие диски
Жесткие диски на ВМ заданы в формате .vhdx – динамически расширяемые жесткие диски. Размер 20гб. и 30гб. для двух разных виртуальных машин. Особенность данного формата в том, что при создании жесткого диска, в виртуальной машине он отображается как обычный жесткий диск с фиксированным размером, а в на физическом жестком диске занимает фактических размер ( который сейчас занят, не предельный заданный). Это помогает сэкономить место на оборудовании. Скорости работы статического виртуального жесткого диска и динамического почти одинаковые, поэтому мы используем более удобный второй вариант.
-
Сеть.
При построении сети использовался виртуальный коммутатор и тип сети определен как внешняя. В нашем случае доступ в интернет предоставляется серверу через беспроводные сети Wi-fi. Виртуальный коммутатор полностью «занимает» физическую сетевую карту сервера и занимается сетевым взаимодействием между виртуальными машинами, сервером и внешней сетью. В данном случае виртуальные машины могут свободно взаимодействовать с хостовой ОС. Между ВМ и серверам была организована локальная сеть. Также выставлена защита маршрутизатора для защиты от сообщений и перенаправлений от несанкционированных виртуальных машин которые выдают себя за марщрутизаторы.
Возможность построения сети с помощью беспроводного адаптера Wi-Fi является несомненным плюсом гипервизора Client Hyper-V. Изначально, сеть на сервере была настроена через сетевую карту Ethernet и кабеля типа витая пара. В дальнейшем сеть была перенастроена с помощью адаптера Wi-Fi. При этом уменьшение быстродействия сети не наблюдалось. При условии высокой скорости передачи данных по сети, использование Wi-Fi при развертывании облачной системы с помощью Client Hyper-V является отличным решением.
Для взаимодействия виртуальных машин, а в особенности обмена данными по локальной сети, была организована домашняя группа с общим доступом к файлам на каждой из ВМ, а так же общее использование принтеров и других инструментов.
-
Общее
В процессе тестирования было выявлено, что при грамотном распределении ресурсов сервера, хостовая операционная система Windows 8 не испытывает проблем с быстродействием даже при большой нагрузке на виртуальные машины (облачную систему). В случае, если гипервизор, работающий на родительской ОС, не настроен на ограничение распределения ресурсов, облачная система забирает почти все имеющиеся у сервера ресурсы и в системе возникают перегрузки.
В случае, если в системе отключается динамическая память и задается статическая, гипервизор начинает использовать технологию неоднородного доступа к памяти NUMA. Она заключается в том, что при многопроцессорной архитектуре процессоров n-ое количество (в нашем случае – два), а память одна. Таким образом, часть процессоров простаивает, в ожидании, пока они смогут обратиться к памяти. NUMA выделяет каждому процессору свою память. Между узлами данной памяти прокладывается быстрая шина, через которую процессор может обращаться к «чужой» для его памяти своих соседей. Получается ситуация, когда память физически распределена, но логически общедоступна. Недостатком данного метода является то, что обмен данными между узлами NUMA [40] меньше скорости обмена процессоров и памяти в обычном режиме.
В процессе тестирования было замечено, что в случае, когда ядер в процессоре n
При наличии на сервере большего количества виртуальных машин чем логических процессоров сервера, производительность системы незначительно падает, но при условии наличия большого количества оперативной памяти на оборудовании сервера, быстродействие почти не страдает, так как современные процессоры могут обрабатывать огромное количество операций в секунду. Опытным путем было выявлено, что при текущей конфигурации сервера, при наличии не двух, а шести виртуальных машин, ощущается потеря быстродействия системы из-за нехватки памяти на 50%. Быстродействие процессора в то же время упало всего на 20%. Также потеря быстродействия ощущается из-за всего одного доступного физического жесткого диска, так как вся система, в том числе и сервер, используют виртуальную память и файл подкачки. При наличии нескольких жестких дисков и большего объема оперативной памяти, быстродействие системы значительно повышается.
- 4>
|