кластер виртуализации что это
Что такое кластер на VMware
Есть бизнес, в котором простои в работе сервиса являются недопустимыми. Например, поломка сервера у сотового оператора или интернет-провайдера приведет к остановке биллинговой системы, а это грозит отсутствием связи у сотен тысяч абонентов. И у многих владельцев подобных компаний возникает закономерное желание создать отказоустойчивую инфраструктуру, которая будет функционировать даже в случае непредвиденных ситуаций. Одним из вариантов «подстраховки» является использование кластера, сегодня он чаще всего создается на базе VMware.
Существует несколько способов организации подобных кластеров, каждый из них имеет особенности и «подводные камни». Мы рассмотрим основы создания систем и основные сложности, с которыми можно столкнуться в процессе организации.
Как достигается бесперебойный доступ
Постоянная работа инфраструктуры возможна только при постоянном наличии точной копии существующего сервера, на котором запущены аналогичные процессы и сервисы. То есть, если создавать реплику уже после отказа оборудования, то это потребует времени, а значит, приведет к простоям и перебоям в предоставлении услуг.
Реализация бесперебойности осуществляется аппаратным и программным способом:
Концепция и реализация
Кластеры на VMware – это изолированная группа хостов (то есть физических серверов), которые связываются между собой общей сетью и управляются общим сервером. То есть это некая целостная система, которая создается для выполнения определенных функций.
Платформа VMware является одним из популярных способов виртуализации. И все чаще при использовании такого решения создаются отдельные кластеры, позволяющие решать конкретные бизнес-задачи и упростить процесс управления сервисом.
На базе VMware – а точнее, с помощью системы vSphere – возможно построение двух разновидностей кластеров: HA (High-availability) и DRS (Distributed Resource Scheduler). Они оба функционируют на уровне виртуальных машин:
Что касается популярного HPC-кластера, то его нельзя построить на базе VMware. То есть сразу стоит учитывать, что платформа не позволит создать единый мощный компьютер из нескольких физических хостов.
Особенности архитектуры
Кластер VMware организуется на базе из двух или более серверов. Максимальное количество используемых физических хостов не может превышать 32. Управление всеми серверами производится при помощи VMware vCenter.
Для создания кластера потребуется наличие единого хранилища, то есть системы для хранения данных. На ней хранятся разделы, которые доступны для чтения или записи сразу всеми серверами кластера. Например, в этих разделах находятся файлы ВМ (виртуальные диски, параметры конфигурации и пр.).
В результате виртуальные машины полностью независимы от физического хостинга, а это позволяет добиться высокой отказоустойчивости системы и быстрого перемещения или восстановления данных.
Последовательность создания
Создание каждого типа кластера имеет особенности, мы рассмотрим все процессы на примере HA:
При организации кластера на VMware обязательным условием является нахождение всех виртуальных машин и их данных в едином хранилище. Именно это позволит мгновенно переключаться между ВМ. Внимания требует и настройка доступа к сетям, используемой памяти и ресурсам.
Дополнительные параметры
В ряде случаев (например, при развертывании кластера из двух и более серверов ESXi), потребуется использование централизованного управления vCenter Server. Конечно же, создать виртуальные машины можно и на одном сервере за счет наличия гипервизора VMware ESXi. Однако такое решение не позволяет получить все возможности HA и DRS. То есть, при недоступности одного из хостов, недоступны будут и остальные. По этой причине vSphere является практически обязательным. С помощью такой платформы возможно управлять ESXi-хостами и СХД.
Обязательным условием для грамотной работы кластера серверов на VMware является единая система хранения данных. Мы уже упомянули этот момент, но не лишним будет добавить, что при отсутствии такой системы не удастся добиться полной независимости ВМ от физической платформы.
Что важно понимать при развертывании кластера. Технология достаточно сложная, поэтому потребует больших материальных затрат. Не стоит забывать и о последующих затратах времени на настройку и администрирование. По этим причинам методику чаще всего выбирают для крупных проектов. Однако благодаря кластеру вы сможете добиться высокой отказоустойчивости и надежности ИТ-инфраструктуры.
Самостоятельное создание кластеров в большинстве случаев является нецелесообразным, поэтому для инфраструктуры компании лучше выбирать услугу аренды виртуальных хостов в дата-центре.
Если у вас остались вопросы о развертывании кластера VMware или вы хотите узнать, подойдет ли подобное решение для вашей компании, то обращайтесь за помощью к специалистам Xelent. При необходимости мы подберем для вас другое решение для организации безотказной инфраструктуры.
Типовые решения от компании ОЛЛИ ИТ (Часть 2)
Продолжаем статьи посвященные нашим решениям, которые смогут помочь вам в выборе оборудования, программного обеспечения необходимого для решения ваших задач.
Отказоустойчивый кластер под виртуализацию
Серверный комплекс – программно-аппаратный комплекс, основанный на высокотехнологичном оборудовании, предназначенный для выполнения специализированных задач в режиме круглосуточной работы. Необходимость использования двух и более серверов заключается в достижении отказоустойчивости системы, если один сервер выходит из строя, второй берет на себя функцию обоих серверов.
Система хранения данных – оборудование для хранения данных компании, к которому организован постоянный бесперебойный доступ. В зависимости от нужд компании подбираются диски для хранения информации. Различные комплексы программного обеспечения помогут повысить уровень доступности данным.
Кластер виртуализации используется для переноса существующих ролей физических серверов в виртуальную среду или создания новой виртуальной инфраструктуры с ноля. Такая организация уменьшает расходы на техническую поддержку и обслуживание серверной части. Помимо этого, использование СХД увеличивает отказоустойчивость хранения данных и быструю работу с ними. Существует несколько вариантов подключения СХД к серверам: FC (Fibre Channel), iSCSI, SAS. В использованном нами решении использован протокол FC, что дает возможность масштабирования системы и высокую скорость передачи данных.
Для описания решения организации связи СХД и серверной части к локальной сети рассмотрим частный случай подключения. Список оборудования для данного решения:
1) СХД IBM Storwize V3700
2) Два сервера IBM System x3550
3) Два 24-х портовых коммутатора Cisco Catalyst 3850
Оборудование было взято исходя из нужд небольшой компании, не требующей высокой производительности.
Рис. 2 – Типичная схема подключения системы хранения данных и серверов к локальной сети.
Данное решение описывает систему виртуализации серверов, столь популярную в наши дни. Технологии виртуализации позволяют консолидировать несколько физических систем в виртуальных машинах на одной аппаратной платформе. Благодаря консолидации оборудования Ваша организация сможет повысить коэффициент использования оборудования с 5% до 80%. А за счет сокращения количества серверов в ЦОД можно снизить потребление электроэнергии.
Для подключения к СХД на серверах System x3550 M4 используются два Fibre Channel адаптера с пропускной способностью 8 Гбит/с на порт. Каждому физическому серверу доступно 2 пути к системе хранения данных. Для балансировки и отработки отказа пути используется механизм резервирования каналов данных.
Каждый из серверов IBM System x3550 M4 подключен двумя путями (для отказоустойчивости) к дублированному контроллеру СХД IBM Storwize V3700 оптическими кабелями.
Высокую производительность и отказоустойчивость сетевой среды обеспечивают два коммутатора (уровень ядра сети и уровень распределения) Cisco Catalyst 3850, объединенные в стек с помощью технологии Cisco StackWise. Серверы подключаются к стеку коммутаторов с помощью четырех гигабитных сетевых портов каждый — таким образом обеспечивается надежное производительное соединение между виртуальными машинами и остальной сетью компании.
Ниже представлена спецификация подобного решения. С учетом требований Вашей компании часть позиций спецификации могут меняться. Наши специалисты смогут полностью оптимизировать данное решение под Ваши нужды.
x3550 M4, Xeon 6C E5-2630v2 80W 2.6GHz/1600MHz/15MB, 1x8GB, O/Bay 2.5in HS
SAS/SATA, SR M5110, 550W p/s, Rack
Intel Xeon 6C Processor Model E5-2630v2 80W 2.6GHz/1600MHz/15MB
8GB (1x8GB, 1Rx4, 1.35V) PC3L-12800 CL11 ECC DDR3 1600MHz LP RDIMM
IBM 300GB 2.5in SFF G2HS 10K 6Gbps SAS HDD
QLogic 8Gb FC Single-port HBA for IBM System x
IBM System x 550W High Efficiency Platinum AC Power Supply
VMware vSph5 Ess Plus Kit for 3 hosts Lic and 3 Year Subs
3 Year Onsite Repair 24×7 24 Hour Committed Service (CS)
IBM UltraSlim Enhanced SATA Multi-Burner
IBM Integrated Management Module Advanced Upgrade
IBM Storwize V3700 SFF Dual Control Enclosure
900GB 2.5In 10K rpm 6Gb SAS HDD
8Gb FC 4 Port Host Interface Card
3 Year Onsite Repair 9×5 Same Business Day
Cisco Catalyst 3850 24 Port Data LAN Base
SMARTNET 8X5XNBD Cisco Catalyst 3850 24 Port Data LAN Bas
Виртуализация и кластеризация
В условиях серьёзных нагрузок на сетевое оборудование (сервера и системы хранения данных) всегда существует риск выхода из строя одного из узлов, что непременно приведёт к остановке бизнес процессов, связанных с ИТ сферой. Создание и внедрение виртуальных серверов может частично или полностью решить данную проблему.
Виртуализация и кластеризация серверов – что это?
Исходя из названия, можно сделать вывод, что виртуализация сервера – это перенос его возможностей с «железного» агрегата в программную среду. Другими словами, эта среда может служить основой для нескольких приложений и даже операционных систем одновременно, не привязываясь к конкретным параметрам фактического железа.
Понятие «кластеризация» более комплексное. По сути это набор определённых устройств (например, серверов), объединённых в одну систему и работающих на обеспечение бесперебойного функционирования кластера. Подобный принцип нашёл применение на крупных предприятиях и в местах, где информационная безопасность превыше всего.
Кому и зачем это нужно?
И виртуализация, и кластеризация имеют одну очень важную особенность – возможность ограничения определённых опций с сервера. Это повышает уровень безопасности и конфиденциальности информации. Поэтому использование таких технологий вполне оправдано на местах, где свободный доступ к определённым данным не слишком желателен. Кластеризация вдобавок к этому даёт ещё и ощущение высокой стабильности, ведь даже если одно из устройств вышло из строя, остальные продолжат работать в штатном режиме, не нарушая процесс.
Второй вариант использования средств виртуализации – отсутствие в необходимости многозадачности рабочего места. Так, например, администратору в кафе не нужен широкий набор функций компьютера, а достаточно лишь нескольких специальных программ. Соответственно, в мощном железе необходимости нет, а вся полезная информация доступна с виртуального сервера.
Выгода системы виртуализации и кластеризации
Она вытекает из свойств и особенностей работы. Виртуальные сервера не требуют серьёзных мощностей на рабочих местах, что значительно экономит средства, затрачиваемые на оборудование. Второй плюс – возможность запуска нескольких программ, которые на обычных компьютерах конфликтуют между собой. Такое преимущество может стать полезным при тестировании нового ПО перед масштабным запуском в систему. Виртуальный сервер имеет собственную рабочую среду, где можно запускать всё, что угодно без риска потери информации и внешних утечек.
Естественно, без определённых навыков и специальных технологий организовать работу виртуальной сети невозможно. Наша компания использует только проверенное программное обеспечение, не конфликтующее с «железом» и выдающее максимальную производительность…
Проверенные поставщики, антикризисные цены, сервис высокого уровня и гарантия качества – вот почему следует отдать предпочтение нашей компании.
Обзор вариантов реализации отказоустойчивых кластеров: Stratus, VMware, VMmanager Cloud
Есть разновидности бизнеса, где перерывы в предоставлении сервиса недопустимы. Например, если у сотового оператора из-за поломки сервера остановится биллинговая система, абоненты останутся без связи. От осознания возможных последствий этого события возникает резонное желание подстраховаться.
Мы расскажем какие есть способы защиты от сбоев серверов и какие архитектуры используют при внедрении VMmanager Cloud: продукта, который предназначен для создания кластера высокой доступности.
Предисловие
В области защиты от сбоев на кластерах терминология в Интернете различается от сайта к сайту. Для того чтобы избежать путаницы, мы обозначим термины и определения, которые будут использоваться в этой статье.
На первый взгляд самый привлекательный вариант для бизнеса тот, когда в случае сбоя обслуживание пользователей не прерывается, то есть кластер непрерывной доступности. Без КНД никак не обойтись как минимум в задачах уже упомянутого биллинга абонентов и при автоматизации непрерывных производственных процессов. Однако наряду с положительными чертами такого подхода есть и “подводные камни”. О них следующий раздел статьи.
Continuous availability / непрерывная доступность
Бесперебойное обслуживание клиента возможно только в случае наличия в любой момент времени точной копии сервера (физического или виртуального), на котором запущен сервис. Если создавать копию уже после отказа оборудования, то на это потребуется время, а значит, будет перебой в предоставлении услуги. Кроме этого, после поломки невозможно будет получить содержимое оперативной памяти с проблемной машины, а значит находившаяся там информация будет потеряна.
Для реализации CA существует два способа: аппаратный и программный. Расскажем о каждом из них чуть подробнее.
Программный способ.
На момент написания статьи самый популярный инструмент для развёртывания кластера непрерывной доступности — vSphere от VMware. Технология обеспечения Continuous Availability в этом продукте имеет название “Fault Tolerance”.
В отличие от аппаратного способа данный вариант имеет ограничения в использовании. Перечислим основные:
Мы не стали расписывать конкретные конфигурации нод: состав комплектующих в серверах всегда зависит от задач кластера. Сетевое оборудование описывать также смысла не имеет: во всех случаях набор будет одинаковым. Поэтому в данной статье мы решили считать только то, что точно будет различаться: стоимость лицензий.
Стоит упомянуть и о тех продуктах, разработка которых остановилась.
Есть Remus на базе Xen, бесплатное решение с открытым исходным кодом. Проект использует технологию микроснэпшотов. К сожалению, документация давно не обновлялась; например, установка описана для Ubuntu 12.10, поддержка которой прекращена в 2014 году. И как ни странно, даже Гугл не нашёл ни одной компании, применившей Remus в своей деятельности.
Предпринимались попытки доработки QEMU с целью добавить возможность создания continuous availability кластера. На момент написания статьи существует два таких проекта.
Первый — Kemari, продукт с открытым исходным кодом, которым руководит Yoshiaki Tamura. Предполагается использовать механизмы живой миграции QEMU. Однако тот факт, что последний коммит был сделан в феврале 2011 года говорит о том, что скорее всего разработка зашла в тупик и не возобновится.
Второй — Micro Checkpointing, основанный Michael Hines, тоже open source. К сожалению, уже год в репозитории нет никакой активности. Похоже, что ситуация сложилась аналогично проекту Kemari.
Таким образом, реализации continuous availability на базе виртуализации KVM в данный момент нет.
Итак, практика показывает, что несмотря на преимущества систем непрерывной доступности, есть немало трудностей при внедрении и эксплуатации таких решений. Однако существуют ситуации, когда отказоустойчивость требуется, но нет жёстких требований к непрерывности сервиса. В таких случаях можно применить кластеры высокой доступности, КВД.
High availability / высокая доступность
В контексте КВД отказоустойчивость обеспечивается за счёт автоматического определения отказа оборудования и последующего запуска сервиса на исправном узле кластера.
В КВД не выполняется синхронизация запущенных на нодах процессов и не всегда выполняется синхронизация локальных дисков машин. Стало быть, использующиеся узлами носители должны быть на отдельном независимом хранилище, например, на сетевом хранилище данных. Причина очевидна: в случае отказа ноды пропадёт связь с ней, а значит, не будет возможности получить доступ к информации на её накопителе. Естественно, что СХД тоже должно быть отказоустойчивым, иначе КВД не получится по определению.
Таким образом, кластер высокой доступности делится на два подкластера:
VMmanager Cloud
Наше решение VMmanager Cloud использует виртуализацию QEMU-KVM. Мы сделали выбор в пользу этой технологии, поскольку она активно разрабатывается и поддерживается, а также позволяет установить любую операционную систему на виртуальную машину. В качестве инструмента для выявления отказов в кластере используется Corosync. Если выходит из строя один из серверов, VMmanager поочерёдно распределяет работавшие на нём виртуальные машины по оставшимся нодам.
В упрощённой форме алгоритм такой:
Практика показывает, что лучше выделить одну или несколько нод под аварийные ситуации и не развёртывать на них ВМ в период штатной работы. Такой подход исключает ситуацию, когда на “живых” нодах в кластере не хватает ресурсов, чтобы разместить все виртуальные машины с “умершей”. В случае с одним запасным сервером схема резервирования носит название “N+1”.
Рассмотрим по каким схемам пользователи VMmanager Cloud реализовывали кластеры высокой доступности.
FirstByte
Компания FirstByte начала предоставлять облачный хостинг в феврале 2016 года. Изначально кластер работал под управлением OpenStack. Однако отсутствие доступных специалистов по этой системе (как по наличию так и по цене) побудило к поиску другого решения. К новому инструменту для управления КВД предъявлялись следующие требования:
Отличительные черты кластера:
Данная конфигурация подходит для хостинга сайтов с высокой посещаемостью, для размещения игровых серверов и баз данных с нагрузкой от средней до высокой.
FirstVDS
Компания FirstVDS предоставляет услуги отказоустойчивого хостинга, запуск продукта состоялся в сентябре 2015 года.
К использованию VMmanager Cloud компания пришла из следующих соображений:
В случае общего отказа Infiniband-сети связь между хранилищем дисков ВМ и вычислительными серверами выполняется через Ethernet-сеть, которая развёрнута на оборудовании Juniper. “Подхват” происходит автоматически.
Благодаря высокой скорости взаимодействия с хранилищем такой кластер подходит для размещения сайтов со сверхвысокой посещаемостью, видеохостинга с потоковым воспроизведением контента, а также для выполнения операций с большими объёмами данных.
Эпилог
Подведём итог статьи. Если каждая секунда простоя сервиса приносит значительные убытки — не обойтись без кластера непрерывной доступности.
Однако если обстоятельства позволяют подождать 5 минут пока виртуальные машины разворачиваются на резервной ноде, можно взглянуть в сторону КВД. Это даст экономию в стоимости лицензий и оборудования.
Кроме этого не можем не напомнить, что единственное средство повышения отказоустойчивости — избыточность. Обеспечив резервирование серверов, не забудьте зарезервировать линии и оборудование передачи данных, каналы доступа в Интернет, электропитание. Всё что только можно зарезервировать — резервируйте. Такие меры исключают единую точку отказа, тонкое место, из-за неисправности в котором прекращает работать вся система. Приняв все вышеописанные меры, вы получите отказоустойчивый кластер, который действительно трудно вывести из строя.
Если вы решили, что для ваших задач больше подходит схема высокой доступности и выбрали VMmanager Cloud как инструмент для её реализации, к вашим услугам инструкция по установке и документация, которая поможет подробно ознакомиться с системой. Желаем вам бесперебойной работы!
P. S. Если у вас в организации есть аппаратные CA-серверы — напишите, пожалуйста, в комментариях кто вы и для чего вы их используете. Нам действительно интересно услышать для каких проектов использование такого оборудование экономически целесообразно 🙂
Физические и виртуальные кластеры
Кластеризация — эффективный метод обеспечения высокой доступности. Она значительно эффективнее, гибче и экономичнее, если ее объединить с технологией виртуализации. Виртуальные кластеры создаются из виртуальных машин (ВМ), установленных на распределенных серверах одного или нескольких физических кластеров. Виртуальные машины в виртуальном кластере логически связаны виртуальной сеть на основе нескольких физических сетей.
Виртуальные кластеры создаются на базе физических машин или ВМ, размещенных на нескольких физических кластерах. Включение ВМ в виртуальный кластер выполняет динамически для реализации следующих условий:
Нужно эффективно управлять виртуальными машинами, установленными на многих физических вычислительных узлах (которые тоже называют виртуальными кластерами) в высокопроизводительной виртуализованной вычислительной среде. Это предусматривает разворачивание, мониторинг и управление виртуальными кластерами в рамках крупных кластеров. Нужно также применять планирование ресурсов, балансировку нагрузки, консолидацию серверов, отказоустойчивость и другие методы. В виртуальной кластерной системе важно эффективно хранить большое число образов ВМ.
Для большинства пользователей и приложений можно создать стандартные экземпляры, такие как библиотеки программирования на уровне ОС или пользователя. Можно заранее установить эти пакеты приложений как шаблоны (которые тоже называются виртуальными машинами). С помощью этих шаблонов пользователи могут строить собственные наборы программ. Они могут также копировать новые экземпляры ВМ, используя шаблоны. Можно также создавать пользовательские компоненты, такие как библиотеки программ и приложений, заранее установленных на этих экземплярах.
Физические (хосты) и виртуальные (гостевые) машины могут работать под управлением разных операционных систем. Можно устанавливать отдельные ВМ на удаленных серверах или реплицировать на несколько серверов, состоящих в том же или другом физическом кластере. Граница виртуального кластера может меняться по мере добавления, удаления или динамической миграции ВМ со временем.
Быстрое разворачивание и эффективное планирование
Виртуальная среда должна поддерживать быстрое развертывание. В данном случае развертывание означает две вещи: максимально быстрое создание и распространение программных наборов (операционных систем, библиотек и приложений) на физическом узле в кластере и быстрое переключение среды выполнения с одного виртуального кластера на другой. Если пользователь прекращает работать с системой, соответствующий виртуальный кластер должен выключаться или быстро переходить в спящий режим, чтобы освободить ресурсы для виртуальных машин других пользователей.
В последнее время стал очень популярным принцип «зеленых вычислений». Однако ранее он ориентировался на экономию энергии на отдельной рабочей станции. Не хватало широты видения. Соответственно зачастую это не приводило к снижению потребления энергии в рамках кластера.
Применять технологии экономии энергии в рамках всего кластера можно только в средах с однородными рабочими станциями и определенными приложениями. Оперативная миграция ВМ позволяет переносить рабочую нагрузку между узлами. Однако это не обязательно гарантирует произвольную миграцию между виртуальными машинами.
Нельзя игнорировать дополнительную нагрузку, связанную с живой миграцией ВМ. Она может оказывать серьезное отрицательное влияние на уровень использования, пропускную способность и качество сервисов кластера. Поэтому задача заключается в определении, как спроектировать стратегии миграции для реализации зеленых вычислений, не снижая производительность кластера.
Другое преимущество кластеризации на основе виртуализации — балансировка нагрузки между приложениями виртуального кластера. Для получения информации для балансировки нагрузки можно использовать индекс нагрузки или количество входов пользователей. На основе этой модели можно реализовать автоматические механизмы горизонтального и вертикального масштабирования виртуального кластера.
Соответственно вы можете увеличить уровень использования ресурсов и сократить время отклика системы. Назначение виртуальным машинам наиболее подходящих физических узлов должно способствовать повышению производительности. Динамическая корректировка нагрузки между узлами за счет миграции ВМ полезна в случае разбалансировки нагрузки среди узлов кластера.
Высокопроизводительное виртуальное хранилище
При пользовательской настройке виртуальной машины шаблон ВМ можно распределить среди нескольких физических хостов в кластере. Для сокращения времени пользовательской настройки можно использовать существующие программные пакеты. Важно эффективно управлять пространством на диске, на котором хранится шаблонное ПО. Можно спроектировать архитектуру хранилища так, чтобы снизить дублирующие блоки в распределенных файловых системах или виртуальных кластерах и использовать хеши для сравнения содержимого блоков данных.
У ваших пользователей будут собственные профили, хранящие идентификационную информацию о блоках данных в соответствующих ВМ в пользовательском виртуальном кластере. При изменении данных создаются новые блоки данных. Вновь созданные блоки идентифицируются в профилях пользователей.
По сути развертывание группы виртуальных машин в кластере состоит из четырех шагов:
Во многих системах для упрощения процесса подготовки образа диска используются шаблоны. Шаблон представляет собой образ диска, который содержит предустановленную ОС, при этом он дополнительно может содержать определенные программы. Пользователи выбирают шаблон, соответствующий их требованиям, и делают дубликат, получая собственный образ диска.
Шаблоны могут быть в формате COW (Copy on Write). Файл нового COW-архива очень маленький, и его просто создавать и переносить. Поэтому вопрос дискового пространства стоит не так остро. Это также позволяет сократить время развертывания ВМ, делая его намного более эффективным, чем копирование всего файла образа.
Каждой ВМ назначается имя, образ диска, сетевые параметры, выделенные процессорные ресурсы и память. Конфигурации всех ВМ надо фиксировать в файле. Впрочем, это не эффективно при управлении большим числом виртуальных машин. Для упрощения процесса на виртуальных машинах с одинаковыми конфигурациями можно применять готовые профили. Система будет конфигурировать эти ВМ в соответствии с выбранным профилем.
В большинстве конфигураций используются одинаковые параметры. Некоторые из них, такие как UUID, имя и IP-адрес ВМ, вычисляются и назначаются автоматически. Обычно пользователей не интересует, на каком узле работает их ВМ.
При анализе стратегии размещения ВМ на хостах надо помнить основной принцип развертывания, который заключается не только в удовлетворении потребностей в виртуальных машинах, но и в разумной балансировке нагрузки в сети. Таким образом, вы сможете добиться эффективного баланса между имеющимися ресурсами и имеющейся рабочей нагрузкой.