Vpxuser vmware что это
Vpxuser vmware что это
Имеется сервер exsi 5.5, который развёрнут на HP Proliant, подключаюсь через vSphere, vCenter отсутствует.
В порыве параноидального подозрения о взломе поменял пароли у учётных записей администратора в том числе и у vpxuser. После этого работал в vSphere без каких-либо намёков на ошибки. Вчера понадобилось подключиться к консоли сервера, но при вводе логина пароля выпадает ошибка «Call «ServiceInstance.RetrieveContent» for object «ServiceInstance» on Server «ip_address» failed». Курение гуглов на данную тему привело к необходимости подключения к командной строке сервера или локально или по ssh. По умолчанию он на сервере отключен. При логине в локальной консоли exsi сервер принимат логин/пароль (на неверную пару ругается) и консоль задумывается часа на полтора. После логина и длительного ожидания включил ssh и залогинился через него без всяких ожиданий.
На текущий момент виртуальные машины на этом сервере работают исправно, доступ по ssh к командной строке есть, веб-морда сервера открывается, просмотр датастора из браузера кроме запроса логина/пароля браузера не работает, поключиться при помощи vShpere не удаётся, локальная консоль функционирует, но тупит. ILO сервера говорит что железо полностью исправно.
Есть подозрения, что проблема именно в смене пароля к системной записи vpxuser. Т.е. нужно как-то вернуть ей дефолтный пароль. Для решения проблемы рекомендуют удалить эту учётную запись, чтобы сам хост exsi его пересоздал с дефолтным паролем.
В связи с этим возникло несколько вопросов:
Извиняюсь за долгое отсутствие.
Кстати. exsi даёт подключаться к себе через vShpere при помощи vpxuser, хотя везде пишут обратное.
>>Возможно, вы провели еще какие-то манипуляции, о которых забыли упомянуть?
В том-то и дело что мною были только поменяны пароли на системные учётные записи.
У меня всё больше подозрений на взлом/саботаж от предыдущих сотрудников (расставались не очень мирно). Т.к. поводом для смены паролей послужила слёгшая виртуальная машина в момент моего отпуска.
На текущий момент управление проблемным хостом exsi самопроизвольно восстановилось. С причины этого глюка я так и не понял. Может быть что-то просто «отглючило».
The vpxuser account is created by VirtualCenter when an ESX host is added. Do not manipulate this account.
Но раз такая ситуация произошла, то можно попробовать сбросить настройки vpxuser к дефолтным, однако, сомневаюсь что это поможет. Еще раз: наличие пароля от vpxuser ничего не даст злоумышленнику, использовать его для подключения к хосту невозможно. Как указано в статье, линк на которую я дал выше, не стоит вообще трогать эту учетную запись, это вероятнее всего приведет к нарушению связи vcenter-ESXi.
Способ вернуться к дефолту vpxuser приведен, но с использованием vsphere клиента, и я уверен на 99% что из cli ESXi резетнуть или удалить/создать vpxuser нельзя (просто удалить можно), т.к. эта операция выполняется vcenter`ом.
Манипуляция с этой учетной записью не повлияет на работу vm. Я бы поступил следующим обазом:
1. Убедился что есть бэкапы моих vm (манипуляция с vpxuser не повлияет на работу машин, но доступ мы можем и не восстановить).
2. Оформил бы триал на vcenter + vsphere.
3. Установил бы vcenter (можно все по дефолту).
Мысль по поводу триального vCentre достаточно интерестна, но есть опасения что на сервере стоит версия с лицензией free, которая не позволяет управление через vCentre. Уверенно сказать не могу, т.к. сервера достались в наследство без какой-либо документации. В любом случае буду пробовать.
Не даёт покоя вопрос: действительно ли ошибка «Call «ServiceInstance.RetrieveContent» for object «ServiceInstance» on Server «ip_address» failed» при подключении через vSphere вызвана из-за смены пароля? Или могут быть какие-то другие причины, к примеру заканчивающееся место на системном рейде?
Все релевантные ответы по указанной вами ошибке ссылаются на проблемы подключения к ESXi именно под управлением vCenter и лечатся обычно статьей, приведенной мной в первом ответе, либо рестартом management service + минорные обновления, и учитывая что vpxuser вообще существует, я уверен на 99%, что vCenter как минимум был, а может и сейчас есть. Раньше при подключении к ESXi vSphere client`ом не выдавалось сообщение о том, что этот сервер управляется vcenter`ом?
Трудно сказать, что могло вызвать пропадание доступа, но учитывая что это произошло после смены паролей, то это и есть наиболее вероятная причина, сомневаюсь что в это же время у вас закончилось место на волюме. К тому же случись такое, вы, скорее всего, получили бы psod.
p.s. а на каких именно учетных записях меняли пароли?
> >Раньше при подключении к ESXi vSphere client`ом не выдавалось сообщение о том, что этот сервер управляется vcenter`ом?
>>p.s. а на каких именно учетных записях меняли пароли?
Менял на учётной записи root, vpxuser, dcui. На какой-то из этих записях ругнулось на невозможность смены пароля, но не помню на конкретно((.
Я уже писал, чтобы хост был управляемым нужно оформить триал и на vSphere и подкинуть этот ключ гипервизору:
В таком случае могу предложить 2 решения:
1. Решит проблему с вероятностью 90% (вообще, я более чем уверен что решит). Быстрый.
Update2: Я все же был не полностью не прав. В старых релизах ESX/ESXi действительно по умолчанию не существовало vpxuser, пока хост не был включен в vCenter, но в новых релизах (6 и 5.5 точно) этот пользователь предустановлен. Вот мой тред Re: vpxuser on standalone ESXi. Также я провел тест: сменил пароль vpxuser и dcui и после этого даже перезагрузил ESXi и доступ не потерял ни через vSphere клиент, ни по ssh, ни в dcui. Возможно, вы провели еще какие-то манипуляции, о которых забыли упомянуть?
Немного о vpxuser
Общая информация
Вот то, что известно всем: vpxuser – учетная запись, используемая vCenter`ом для управления ESXi хостами (опрос гипервизора, отправка задачи), которые в него включены. Т.е. учетная запись root (ESXi) не имеет отношения к связи vCenter – ESXi (за исключением того нюанса, что она нужна для включения ESXi в vCenter).
Vpxuser имеет права администратора ESXi. Таким образом, администратор vCenter`а может выполнять практически все те же самые манипуляции с хостом, что и root (ESXi), кроме создания/удаления/изменения локальных пользователей и групп самого ESXi хоста.
Управлять учетной записью vpxuser с помощью службы каталогов AD нельзя.
Пароль vpxuser хранится в зашифрованном виде и на ESXi и в базе vCenter (логично, не правда ли?) и для каждого ESXi этот пароль уникален.
Подключение к ESXi с помощью VPXUSER
В некоторых источниках я видел утверждения вроде этого: «Знание пароля от vpxuser Вам ничего не даст, использовать эту комбинацию для подключения к хосту и любых других целей невозможно». Однако, зная пароль vpxuser, можно подключиться к ESXi и управлять им (опробовано на Standalone ESXi 5.5 u1 и на ESXi 5.5 u1 под управлением vCenter 5.5, и не только на них).
Изменение пароля VPXUSER
В документации можно обнаружить предупреждение, которое в вольном (моем) переводе выглядит так:
ВНИМАНИЕ: проводите манипуляции с учетной записью vpxuser на свой страх и риск, это может повлечь за собой нарушение связи vCenter – ESXi. При включенном lockdown mode на хосте, управление хостом может быть потеряно безвозвратно.
Это действительно так. Опробовав в лаборатории, могу сказать, что после смены пароля vpxuser на ESXi, vCenter теряет с ним связь. НО не сразу. В моем случае это произошло через 18-20 часов. Самое интересное то, что после смены пароля vpxuser на ESXi, я сразу перезагрузил vCenter Service (но не машину, на которой этот сервис развернут), т.е. установленная сессия должна была дропнуться, и креденшиалы, гипотетически бывшие в кэше (а может и не бывшие, а может и не в кэше), должны были очиститься. Но этого не произошло. Тех. поддержка VMware никак не прокомментировала такое поведение, сказав, что не отвечает на вопросы по архитектурным особенностям платформы.
Интересно и другое: далее в этой статье есть информация о политике паролей vpxuser, и по умолчанию длина его пароля 32 символа. Если менять его пароль вручную на ESXi, например с помощью “passwd”, то можно задать пароль намного короче. Видимо, связано это с тем, что политику паролей поддерживает vCenter, а поскольку меняется пароль vpxuser тоже vCenter`ом, то, как говорится «Я своей смешною рожей сам себя и веселю». Т.е. сменить-то пароль можно, и задать его несоответствующим политике можно, но связь с ESXi в итоге будет утеряна.
Потеря связи вполне логична, ведь при ручной смене пароля vpxuser, его пароль в базе vCenter`а не меняется.
Вывод: не меняйте пароль на vpxuser сами, пусть этим занимается vCenter. Если вы изменили пароль vpxuser руками, то с вероятностю 99% рано или поздно vCenter потеряет связь с ESXi. 1% я оставляю на магическое вмешательство.
Устранение проблем
Если все-таки изменения в vpxuser были внесены (например, изменен пароль) и это повлекло недоступность ESXi из vCenter (обычно сопровождается ошибкой: «Call «ServiceInstance.RetrieveContent» for object «ServiceInstance» on Server «ip_address» failed«), то можно поступить следующим образом (если lockdown mode не включен и есть доступ к хосту по SSH):
Здесь стоит обратить внимание на фразу «если не включен lockdown mode». Если пароль vpxuser был изменен и vCenter потерял связь с ESXi и при этом lockdown mode включен, т.е. доступ к хосту ESXi запрещен всем кроме vCenter, то официальная позиция VMware на этот счет однозначна: «переустанавливайте ESXi».
Политика паролей для vpxuser
Время действия пароля
По умолчанию пароль vpxuser обновляется каждые 30 дней, но это можно изменить:
1. В vSphere Client → Administration.
2. vCenter Server Settings… → Advanced Settings.
3. Выбрать параметр VirtualCenter.VimPasswordExpirationInDays, установить нужное значение.
4. Перезагрузить службу vCenter.
Изменять этот параметр VMware не рекомендует. VMware вообще много чего не рекомендует делать, жить вредно, от этого умирают.
Сложность пароля
@-<> и др.), цифры (1-9), большие буквы (латиница) и строчные буквы (латиница).
В документации указано, что для изменения длины пароля vpxuser можно изменить значение параметра vpxd.hostPasswordLength в файле конфигурации на vCenter:
Т.е. внутрь vpxd, но не внутрь какого-либо другого вложенного тега.
Вывод: зачем вообще менять политику паролей для vpxuser? Да незачем, VMware не рекомендует заниматься подобной ерундой.
Некоторые замечания на тему VMware vSphere Security Permissions
Что-то я в последнее время всё о детях. Надо разбавить тенденцию, плеснув немного хардкорной ИТ-тематики. Вернёмся к теме виртуализации и VMware vSphere. В данный момент для меня стала актуальной тема назначения прав доступа.
Для предоставления доступа различным категориям пользователей к их виртуальным машинам, как правило, используется представление VM and Templates и система папок, на которые, собственно, и назначаются права. Однако, в некоторых случаях этого бывает недостаточно, поскольку для некоторых действий пользователь должен иметь права и на объекты среды, отсутствующие в отображении VM and Templates. Например, для добавления виртуального жёсткого диска или клонирования ВМ нужны права Datastore.Allocate Space или роль Datastore Consumer на объект Datastore или Datastore Cluster. А для возможности изменения сетевого интерфейса — права Network.Assign Network или роль Network Administrator на соответствующие портгруппы. Далее детальнее об этом и других нюансах назначения прав доступа в vSphere. Информация актуальна для версий vSphere 5.1 и 5.5.
Ввиду наличия различных представлений объектов инфраструктуры виртуализации, права доступа к некоторым объектам (VM, vApps) могут наследоваться от нескольких предков (например, VM folder и Resource Pool). что стоит иметь ввиду. Общая схема наследования представлена на рисунке:
Соответственно, если кого-то нужно в правах ограничить, нужно убедиться, что отнятые в одном месте права не наследуются из другого объекта.
Помимо этого, можно столкнуться на практике, что человек, имеющий полномочия администратора на уровне рута, вдруг оказывается ограниченным пользовательскими правами на уровне конкретной папки. Дело в особенностях выбора действующих прав в ситуации наложения ролей. При предоставлении полномочий следует иметь их ввиду.
1) Права, выданные дочерним объектам игнорируют наследованные. Другими словами, если пользователь входит в группы vSphereAdmins и CitrixAdmins, при этом первая имеет права админа на уровне root, а вторая — VM User на уровне папки Citrix, то как раз получим ситуацию, описанную в вышеприведённом абзаце.
2) Права выданные на конкретного пользователя преобладают над правами, выданными на группу (если и те и другие выданы на один объект и пользователь входит в группу).
3) Если используются пользователи из AD или иных источников, отличных от встроенного каталога vCenter SSO, vCenter периодически проверяет наличие учётной записи поиском по имени. И если после назначения прав в vCenter, учётка была переименована или удалена, соответствующие ей права из vCenter удаляются. И если в случае удалённой учётки это даже хорошо, то в случае, если кто-то переименовал группу (группы), например в соответствие с новыми политиками именования в организации, это может привести к неблагоприятным последствиям.
4) vCenter SSO не наследует права вложенных групп, если их участники не входят в Identity Sources. Например, если домен AD не добавлен в Identity Sources, то группа Domain Admins этого домена не будет иметь никаких полномочий на vCenter, даже с учётом того, что она входит в local\Administrators сервера vCenter.
А теперь немного рекомендаций лучших собаководов Best Practices по теме предоставления прав доступа.
Напоследок упомяну о специализированных пользователях хостов ESXi. Спровоцировано тем, что коллега однажды решил убедиться, что сотрудники ИТ в некоторых регионах не наделали себе лазеек в инфраструктуре, и чуть было не вычистил ESXi-хосты от пользователя vpxuser.
vpxuser — специализированный пользователь, который создаётся при подключении хоста к vCenter и используется им для администрирования. Имеет, соответственно, административные права на хост и ни в коем случае не должен модернизироваться (не менять ни права ни пароль).
dcui user — ещё один специфичный пользователь, используемый в качестве агента при работе через Direct Console User Interface режиме lockdown mode хоста (в этом режиме любые подключения к хосту запрещены, кроме управления с помощью vCenter).
В качестве заключения хочу заметить, что никогда я настолько не осознавал значимости и актуальности AGDLP-подхода при назначении прав доступа к системе, как при разработке политики назначения прав на объекты vCenter. Ввиду вышеприведённых особенностей и большого количества ветвлений элементов иерархий.
Некоторые замечания на тему VMware vSphere Security Permissions
Для предоставления доступа различным категориям пользователей к их виртуальным машинам, как правило, используется представление VM and Templates и система папок, на которые, собственно, и назначаются права. Однако, в некоторых случаях этого бывает недостаточно, поскольку для некоторых действий пользователь должен иметь права и на объекты среды, отсутствующие в отображении VM and Templates. Например, для добавления виртуального жёсткого диска или клонирования ВМ нужны права Datastore.Allocate Space или роль Datastore Consumer на объект Datastore или Datastore Cluster. А для возможности изменения сетевого интерфейса — права Network.Assign Network или роль Network Administrator на соответствующие портгруппы. Далее детальнее об этом и других нюансах назначения прав доступа в vSphere. Информация актуальна для версий vSphere 5.1 и 5.5.
Ввиду наличия различных представлений объектов инфраструктуры виртуализации, права доступа к некоторым объектам (VM, vApps) могут наследоваться от нескольких предков (например, VM folder и Resource Pool). что стоит иметь ввиду. Общая схема наследования представлена на рисунке:
Соответственно, если кого-то нужно в правах ограничить, нужно убедиться, что отнятые в одном месте права не наследуются из другого объекта.
Помимо этого, можно столкнуться на практике, что человек, имеющий полномочия администратора на уровне рута, вдруг оказывается ограниченным пользовательскими правами на уровне конкретной папки. Дело в особенностях выбора действующих прав в ситуации наложения ролей. При предоставлении полномочий следует иметь их ввиду.
1) Права, выданные дочерним объектам игнорируют наследованные. Другими словами, если пользователь входит в группы vSphereAdmins и CitrixAdmins, при этом первая имеет права админа на уровне root, а вторая — VM User на уровне папки Citrix, то как раз получим ситуацию, описанную в вышеприведённом абзаце.
2) Права выданные на конкретного пользователя преобладают над правами, выданными на группу (если и те и другие выданы на один объект и пользователь входит в группу).
3) Если используются пользователи из AD или иных источников, отличных от встроенного каталога vCenter SSO, vCenter периодически проверяет наличие учётной записи поиском по имени. И если после назначения прав в vCenter, учётка была переименована или удалена, соответствующие ей права из vCenter удаляются. И если в случае удалённой учётки это даже хорошо, то в случае, если кто-то переименовал группу (группы), например в соответствие с новыми политиками именования в организации, это может привести к неблагоприятным последствиям.
4) vCenter SSO не наследует права вложенных групп, если их участники не входят в Identity Sources. Например, если домен AD не добавлен в Identity Sources, то группа Domain Admins этого домена не будет иметь никаких полномочий на vCenter, даже с учётом того, что она входит в local\Administrators сервера vCenter.
Немного рекомендаций лучших собаководов Best Practices по теме предоставления прав доступа.
Напоследок упомяну о специализированных пользователях хостов ESXi. Спровоцировано тем, что коллега однажды решил убедиться, что сотрудники ИТ в некоторых регионах не наделали себе лазеек в инфраструктуре, и чуть было не вычистил ESXi-хосты от пользователя vpxuser.
vpxuser — специализированный пользователь, который создаётся при подключении хоста к vCenter и используется им для администрирования. Имеет, соответственно, административные права на хост и ни в коем случае не должен модернизироваться (не менять ни права ни пароль).
dcui user — ещё один специфичный пользователь, используемый в качестве агента при работе через Direct Console User Interface режиме lockdown mode хоста (в этом режиме любые подключения к хосту запрещены, кроме управления с помощью vCenter).
В качестве заключения хочу заметить, что никогда я настолько не осознавал значимости и актуальности AGDLP-подхода при назначении прав доступа к системе, как при разработке политики назначения прав на объекты vCenter. Ввиду вышеприведённых особенностей и большого количества ветвлений элементов иерархий.
Что такое VMware и почему важна ее совместимость с SSD-накопителями
Привет, Хабр! Сегодня мы поговорим о виртуальных машинах, программном обеспечении VMware и накопителях Kingston, конечно же. В частности, разберем вопросы на тему “зачем нужна сертификация VMware Ready, какие из SSD-решений получают статус VMware Ready for Storage, и о чем это говорит?”. Начнем с самого банального.
Безусловно, аудитории Хабра знакома компания VMware, которая занимается разработкой программного обеспечения для виртуализации и организации облачных вычислений. Продукты VMware включают в себя средства виртуализации, управления сетью и безопасностью, программное обеспечение для ЦОД и хранения данных.
Первым таким продуктом стала программа VMware Workstation, которая позволяла любому пользователю установить на своем ПК одну или несколько виртуальных машин: то бишь имитацию аппаратной начинки компьютера в лице процессора, видеокарты, накопителей, оптических приводов и т.д. Эдакий компьютер в компьютере.
В рамках серверной среды VMware Workstation вкупе с установленным гипервизором VMware ESX позволяет запускать несколько виртуальных машин на одном физическом сервере, при этом каждая из ВМ может работать со своей операционной системой. Следовательно — на одном сервере могут быть активными сразу несколько разных ОС.
При этом все установленные ВМ совместно используют доступные ресурсы (сетевую карту и оперативную память), но работают независимо друг от друга. Основными продуктами в этом направлении является платформа VMware vSphere, гипервизор VMware ESX и VMware ESXi, VMware Server и vCenter Server. Впрочем, серверная виртуализация — не единственный тип абстрагирования от аппаратной реализации.
Типы виртуализации VMware
Все программы для виртуализации можно разделить на пять типов: серверная виртуализация, виртуализация десктопов, сетевая виртуализация, виртуализация хранилищ и ПО для управления облачными средами. О виртуализации в серверной среде мы уже немного рассказали выше, а вот что подразумевается под остальными типами?
Виртуализация десктопов и облачные среды
Виртуализация десктопов, которую иногда называют инфраструктурой виртуальных десктопов (VDI), — это такой тип виртуализации, при котором ОС настольных ПК работает как виртуальная машина на физическом сервере с другими виртуальными десктопами. Обработка нескольких виртуальных рабочих мест происходит на одном или нескольких физических серверах, обычно – в централизованном ЦОД. Копия ОС и приложений, которые использует каждый конечный пользователь, обычно кэшируется в памяти, как один образ на физическом сервере.
Пакет VMware Horizon позволяет организациям запускать рабочие столы Windows в центре обработки данных или в облачных сервисах на базе VMware Cloud, что устраняет необходимость размещения и управления десктопами с офисного рабочего места, централизует управление пользовательской средой и обеспечивает ее безопасность.
При развертывании данного типа виртуализации используется ПО для выполнения сетевых функций путем отделения виртуальных сетей от базового сетевого оборудования. Как только вы начнете использовать виртуализацию сети, физическая сеть будет использоваться только для пересылки пакетов, поэтому все управление осуществляется с помощью виртуальных или программных коммутаторов. Поставщиками сетевой виртуализации являются внутренние виртуальные коммутаторы гипервизора. Кроме того, сторонние поставщики, такие как Cisco и IBM, разработали виртуальные коммутаторы, которые могут использоваться гипервизорами, такими как ESXi.
Как мы уже отмечали, для каждого типа виртуализации компания VMware предлагает определенный набор софта. Например, если мы говорим о хранении данных, то следует принимать во внимание такие решения, как VMware vSAN и VMware Site Recovery Manager (SRM). VMware vSAN — программная функция хранения, встроенная в гипервизор ESXi и интегрированная с vSphere. Она объединяет дисковое пространство от нескольких хостов ESXi и выделяет его с помощью интеллектуальных политик, таких как ограничения защиты, тонкое выделение ресурсов и кодирование стирания. А еще эта опция интегрируется с функцией vSphere High Availability, обеспечивая повышенную производительность вычислений и самого хранилища.
VMware Site Recovery Manager (SRM) предназначен для управления аварийным восстановлением, что позволяет администраторам создавать планы восстановления, которые автоматически выполняются в случае сбоя, а также автоматически организовывать аварийное переключение и восстановление виртуальных машин. SRM также интегрируется с VMware NSX (инструмент управления сетевыми операциями) для сохранения сетевых политик и политик безопасности на виртуальных машинах, перемещенных на новые физические сервера.
Зачем нужна сертификация VMware Ready
Начнем с того, что сертификация VMware Ready означает высокий уровень одобрения для продуктов, созданных партнерами компании VMware. Нетрудно догадаться, что Kingston Digital входит в их число: в частности, является членом “Партнерского технологического альянса VMware”. Участники этого альянса разрабатывают свои устройства в соответствии со стандартами VMware и предоставляют их техническим специалистам компании, которые проводят различные сертификационные тесты.
По итогам проверок, сервера, компьютеры, устройства хранения и другие устройства, отвечающие сертификационным требованиям, получают заветный логотип VMware Ready. Кроме того, в дальнейшем эти продукты поддерживаются как со стороны компании-партнера, так и со стороны VMware. Подробную информацию о твердотельных накопителях Kingston из линейки, которые прошли сертификацию VMware можно найти и на портале VMware Solution Exchange (VSX). Там же размещаются обновления ПО для пользователей “железа” сертифицированного VMware.
Возвращаясь к “Партнерскому технологическому альянсу VMware”, стоит упомянуть о том, что участие в нем позволяет клиентам быстро находить сертифицированное оборудование партнеров, не занимаясь точечным и индивидуальным подбором компонентов, которые в итоге могут не обеспечить ожидаемую производительность. Не в последнюю очередь это способствует росту продаж накопителей Kingston. Только за первое полугодие 2019 года компании удалось реализовать более 13,3 миллиона твердотельных накопителей (по исследованиям TrendFocus). Если говорить о глобальных поставках, хорошие продажи обеспечили Kingston третье место в списке лидеров по реализации SSD-накопителей после Samsung и Western Digital.
Какие SSD-накопители обладают статусом VMware Ready
Применительно к накопителям Kingston серверного класса, сертификацию VMware Ready for Storage имеют твердотельные SATA-накопители Kingston DC500R и Kingston DC500M, рекомендованные для использования в ЦОД. Как мы уже отметили выше, присвоенный данным SSD-решениям статус говорит о том, что DC500R и DC500M получили полное одобрение от специалистов VMware, успешно пройдя все тесты.
Именно эта сертификация позволяет представителям Kingston Digital говорить о том, что при использовании SSD DC500R и DC500M в среде vSAN и серверах vSphere можно ожидать высокой производительности при выполнении большого количества операций чтения данных и смешанных нагрузках. К слову, для прохождения сертификации серверные накопители настраиваются в соответствии с требованиями от VMware и в итоге обеспечивают высокую пропускную способность, кол-во IPOS, а также минимальную задержку в 99% сценариев.
Как итог: сертифицированные SSD Kingston с чистой совестью можно отнести к классу высокопроизводительных ускорителей для виртуализированных рабочих нагрузок смешанного типа в рамках серверной среды. Также они позволяют облачным службам работать с максимальной эффективностью и предоставляют пользователям очень быстрый доступ к данным. Собственно, от них это и требуется.
Для получения дополнительной информации о продуктах Kingston Technology обращайтесь на официальный сайт компании.