Да, так и есть. В нашем случае и администраторы были перегружены типовыми операциями по созданию ВМ, и конфигурированию ОС и приложений. Но и без ручных процессов согласования не обходилось. Сейчас облачная платформа полностью взяла на себя создание и конфигурирование ВМ и приложений. Согласования остались но в формате одной нотификации администратору платформы, все остальное согласовано и принято как стандарт на этапе внедрения облака.
Можно использовать ПО VMware View Planner — www.vmware.com/go/download-viewplanner
Из коробки в нем уже есть набор тестов: работа в веб-браузере, с MS Office, c PDF-файлами и т.д. Также можно написать свои тесты для повышения соответствия сценариям работы ваших пользователей или для каких-то специальных приложений.
Мы обычно стараемся убедить наших заказчиков отказаться от использования локальной периферии там, где это возможно, и использовать сетевые устройства (МФУ, принтеры, сканеры). Но иногда приходится иметь дело с зоопарком устройств со средним возрастом 7+ лет, вот тогда и начинаются проблемы
А JPEG компрессия работает замечательно!
Для генерации и измерения нагрузки используем ПО VMware View Planner — www.vmware.com/go/download-viewplanner
Он бесплатный и вполне хорошо справляется со своей задачей.
Опять же согласен с awsswa59 :) Делать резервные копии для всех виртуальных рабочих станций не нужно. В зависимости от развертывания нужно бэкапить следующее:
1. Инфраструктурные компоненты.
2. Шаблоны виртуальных рабочих станций (для Linked Clone и Instant Clone).
3. Сами виртуальные рабочие станции (для Full Clone).
4. Данные пользователей переправленные на файловый сервер.
Да, и дедупликация отлично работает для VDI-сценариев.
Если возможности провести пилот и нагрузочное тестирование нет, то можно ориентироваться на опыт подобных развертываний. По нашему опыту, для офисных пользователей (судя по описанию сценария использования, это как раз ваш случай) для комфортной работы на Windows 10 вполне достаточно следующих характеристик: 2 vCPU и 6 ГБ оперативной памяти. По коэффициенту переподписки vCPU на физическое ядро лучше ориентироваться на 4 к 1. По оперативной памяти лучше не заполнять более 80% объема в сервере.
В вашем случае получается:
Количество пользователей по процессорам — 20 ядер * 4 (коэффициент переподписки 4 к 1) / 2 vCPU у виртуальной рабочей станции = 40 виртуальных рабочих станций.
Количество пользователей по памяти — 380 ГБ в сервере * 0,8 / 6 ГБ у виртуальной рабочей станции = 50
Выбираем наименьшее значение. Это, конечно, грубый расчет, но на него можно ориентироваться.
И совершенно согласен с awsswa59, если вы хотите, чтобы пользователи сохранили работоспособность после выхода из строя сервера, то нужно всегда использовать схему N+1, чтобы как минимум один сервер всегда был в резерве.
Без all-flash СХД можно обойтись, просто виртуальные рабочие станции будут медленнее работать.
Спасибо, получилась очень интересная статья. Безусловно, для онлайн процессинга и БД в целом требования по задержкам дисковой подсистемы значительно выше. Но для значительной части корпоративных приложений, инфраструктурных служб, по нашему опыту, задержки в 10-15 мс не сильно влияют на производительность, а, например, для виртуализации рабочих станций (VDI) задержки в 25-30 мс практически не заметны пользователю и, соответсвенно, никак не влияют на его работу.
Наличие диска в списке совместимости гарантирует его корректную работу c vSAN, а если возникнут какие-либо проблемы, том можно будет обратиться в техническую поддержку VMware за помощью. При этом отсутсвие диска в списке совместимости не означает, что он не будет работать. В моем понимании, большинство современных дисков работать будет, но лучше тестировать пред покупкой.
Относительно вложенной виртуализации, да, это возможно, но ожидать от такой конфигурации производительности не стоит. У меня был успешный опыт с вложенными ESXi, Hyper-V и KVM.
Если говорить про NUC и другие компактные решения, то основным ограничениям можно отнести отсутсвие сетевых интерфейсов 10 GbE (который нужен, если мы рассчитываем на хорошую производительность) и относительно маленькое количество дисков, которое можно установить в подобное решение.
Что касается дисков, то vSAN может работать с любыми дисками которые доступны гипервизору ESXi. В том числе, и с дисками для потребительского рынка, но их ресурс и производительность могут быть меньше, чем у корпоративных. Но ключевым, с точки зрения производительности и надежности инфраструктуры vSAN, является дисковый контроллер, который как раз и делает установленные в сервер диски доступными ESXi. Крайне желательно, чтобы дисковый контроллер поддерживал режим Host Bus Adapter, который на прямую подключает диски, минуя необходимость создавать RAID0 для каждого.
В этой статье мы сделали фокус на vSAN, как на SDS решение. Но в реальной жизни рассматривать vSAN в отрыве от платформы виртуализации vSphere и гиперконвергентного сценария не стоит.
Спорный аргумент на мой взгляд. Современные СХД — 3U, минимум для SDS — 3 ноды по 1U.
Верно, если говорить об использовании SDS как отдельно стоящего решения, аналогично традиционным СХД. Но если говорить про гиперконвергентные решения, где на одном сервере объединяются вычислительные мощности для ВМ и дисковые ресурсы для SDS, то здесь экономия мест на лицо — вообще не нужно место для СХД, только для серверов.
Так же на мой взгляд спорно, ввиду того, что традиционные схд давно работают по iSCSI.
Использование iSCSI с традиционными СХД позволяет сэкономить, в сравнении с Fiber Channel, за счет отказа от специализированного FC-оборудования и использования Ethernet.
Кстати, если есть необходимость предоставить ресурсы хранения vSAN серверам работающим не под управлением гипервизора ESXi — это можно сделать также через iSCSI.
В рамках нашего небольшого кластера vSAN на 1 GbE сети производительность вполне приемлемая. Единственное, при развертывании больших OVA упираемся в физическую пропускную способность сети.
Идея отличная! Думаю, сейчас еще рано говорить о полноценном программно-определяемом ЦОД на Raspberry/Orange Pi, но для таких задач, как исполнение множества экземпляров приложения на множестве устройств в SDN-сети, уже, наверное, годится. Например, веб-приложения. Единственное — нужно посчитать, будет ли экономически оправдано.
Если рассматривать вариант с 2-4 сетевыми портами, то без дополнительного PCI-E сетевого адаптера уже не обойтись. Соответсвенно, нужен PCI-E разъем на материнской плате и слот в корпусе. А это уже другой форм-фактор: микро-сервер, мини-tower и т.д.
Мы изначально хотели построить SDDC на стеке продуктов VMware. Сейчас планируем добавить KVM+oVirt+CEPH+NSX-T и сделать наш SDDC гетерогенным. На ESXi nested виртуализация тоже работает.
Согласен и, думаю, что Proxmox заведется без проблем. Кстати, в планах сделать гетерогенный SDDS — добавить еще 2-3 NUC, развернуть на них KVM+oVirt+CEPH, заменить NSX-V на NSX-T для единообразного управления SDN-сетями на обоих платформах.
В реальных проектах под каждый случай мы считаем цены отдельно, а это по сути RnD, в реальной жизни такую штуку бы никто не собирал. Но если посмотреть на цены на сайте VMware — www.vmware.com/ru/products/vsphere.html, они считаются по физическим процессорам, стоимость лицензий превышает стоимость NUX в разы.
У нас в центре решений Intel два NUC, используемых для digital signage замурованы «в пристенке» за пластиковой фальшпанелью, вообще без вентиляции. Корпуса теплые, но не слишком. Что будет при 100% утилизации, не знаю, но при средних нагрузках теплообмена хватает. Скорее всего, летом в ящике хорошего дубового стола им всё же будет нехорошо.
Из коробки в нем уже есть набор тестов: работа в веб-браузере, с MS Office, c PDF-файлами и т.д. Также можно написать свои тесты для повышения соответствия сценариям работы ваших пользователей или для каких-то специальных приложений.
А JPEG компрессия работает замечательно!
Он бесплатный и вполне хорошо справляется со своей задачей.
1. Инфраструктурные компоненты.
2. Шаблоны виртуальных рабочих станций (для Linked Clone и Instant Clone).
3. Сами виртуальные рабочие станции (для Full Clone).
4. Данные пользователей переправленные на файловый сервер.
Да, и дедупликация отлично работает для VDI-сценариев.
В вашем случае получается:
Количество пользователей по процессорам — 20 ядер * 4 (коэффициент переподписки 4 к 1) / 2 vCPU у виртуальной рабочей станции = 40 виртуальных рабочих станций.
Количество пользователей по памяти — 380 ГБ в сервере * 0,8 / 6 ГБ у виртуальной рабочей станции = 50
Выбираем наименьшее значение. Это, конечно, грубый расчет, но на него можно ориентироваться.
И совершенно согласен с awsswa59, если вы хотите, чтобы пользователи сохранили работоспособность после выхода из строя сервера, то нужно всегда использовать схему N+1, чтобы как минимум один сервер всегда был в резерве.
Без all-flash СХД можно обойтись, просто виртуальные рабочие станции будут медленнее работать.
В HCL указывается не только поддерживается диск или нет, но и сведения о версии ESXi, драйвера, прошивки и для каких задач его можно использовать (кэширование и/или хранение).
Вот пример сведений о диске, который мы использовали под кэш, в HCL — www.vmware.com/resources/compatibility/detail.php?deviceCategory=ssd&productid=40177&deviceCategory=ssd&details=1&vsan_type=vsanssd&keyword=PM1725&vsanrncomp=true&page=3&display_interval=10&sortColumn=Partner&sortOrder=Asc
Относительно вложенной виртуализации, да, это возможно, но ожидать от такой конфигурации производительности не стоит. У меня был успешный опыт с вложенными ESXi, Hyper-V и KVM.
Что касается дисков, то vSAN может работать с любыми дисками которые доступны гипервизору ESXi. В том числе, и с дисками для потребительского рынка, но их ресурс и производительность могут быть меньше, чем у корпоративных. Но ключевым, с точки зрения производительности и надежности инфраструктуры vSAN, является дисковый контроллер, который как раз и делает установленные в сервер диски доступными ESXi. Крайне желательно, чтобы дисковый контроллер поддерживал режим Host Bus Adapter, который на прямую подключает диски, минуя необходимость создавать RAID0 для каждого.
Верно, если говорить об использовании SDS как отдельно стоящего решения, аналогично традиционным СХД. Но если говорить про гиперконвергентные решения, где на одном сервере объединяются вычислительные мощности для ВМ и дисковые ресурсы для SDS, то здесь экономия мест на лицо — вообще не нужно место для СХД, только для серверов.