ЗАДНИЙ ПЛАН
Мы рассматриваем возможность создания хоста виртуальной машины для тестирования QA. Наша основная цель - иметь возможность легко настроить набор виртуальных машин в автономной среде, которая будет имитировать основные машины на нашем предприятии. Скорее всего, у нас будет компьютер с базой данных, сервер приложений, веб-сервер и одна или две клиентские машины в каждой среде.
Мы хотели бы иметь от двух до четырех сред, активных одновременно (то есть до двадцати виртуальных машин одновременно) с дисковым пространством, чтобы, возможно, еще 4 среды были отключены.
Для этого потребуется много лошадиных сил. Мы не собираемся тестировать производительность в этих средах, в основном это будет автоматическое функциональное и интеграционное тестирование и, возможно, ручное тестирование, выполняемое реальными людьми. Виртуальным машинам не нужно вести себя так, как будто у них есть быстрые процессоры, но мы бы предпочли, чтобы они не зависали из-за медленной задержки диска.
ВОПРОС
Учитывая эти цели, что, по вашему мнению, нам следует учитывать с точки зрения оборудования? Стоит ли разделить это на несколько «меньших» машин, а не на одну огромную большую?
Задержка жесткого диска будет проблемой, потому что каждый сервер будет иметь разный шаблон доступа и может скрыть ошибки синхронизации, потому что диск заставляет всех идти в определенном порядке (в зависимости от времени получения запроса), и постепенно все идет вниз.
Я бы выбрал полосатый зеркальный массив очень быстрых дисков, чтобы ограничить вашу подверженность этой проблеме. Он по-прежнему скроет проблемы (в частности, определенные условия гонки), но не так сильно.
Загрузите сервер с памятью (16-32 ГБ - это не перебор) и выберите 8-ядерную машину или две четырехъядерные машины по 8-16 ГБ каждая.
-Адам
Память, вероятно, будет вашим самым большим ограничением. Проверьте свою виртуальную среду, чтобы узнать, может ли она совместно использовать неиспользуемую память (т. Е. Можно ли выделить более 100% доступной памяти)
У нас есть здоровенный 8-ядерный хост с объемом памяти 16 ГБ, на котором будет работать около 20 виртуальных машин. Я думаю, что было бы более экономичным, универсальным и избыточным иметь 2 хоста вдвое меньшего размера. Однако при наличии всего 20 виртуальных машин управление чем-либо, кроме 4 хостов, вероятно, станет затруднительным.
Если вам нужна еще большая универсальность, разместите виртуальные машины в SAN или другом общем хранилище, чтобы их можно было запускать на любом / любом хосте.
Вы рассматривали возможность использования для этого блейд-шасси? Все наши системы VMware в моей компании работают в блейд-шасси, что дает нам большую гибкость и избыточность с точки зрения оборудования. У вас даже может быть лезвие «горячего резерва», а также возможность добавлять дополнительные лезвия или заменять лезвия на более мощные на досуге.
В частности, VMWare даже имеет встроенную поддержку некоторых расширенных функций в фирменных блейд-шасси HP.
Механизмы виртуализации, с которыми я работал, требовали статического выделения памяти для виртуальных хостов, поэтому вам, вероятно, понадобится довольно много оперативной памяти на серверах.
Что касается меньшего количества больших сигнальных машин по сравнению с большим количеством не очень сигнальных машин, стоит иметь в виду, что в контексте виртуализации физический хост фактически является единой точкой отказа для всех виртуальных хостов.