Тестирование производительности гиперконвергентных систем и SDS своими руками

- Штурман, приборы!
- 36!
- Что 36?
- А что приборы?

Примерно так на сегодня выглядит большинство синтетических тестов систем хранения данных. Почему так?

До относительно недавнего времени большинство СХД были плоскими с равномерным доступом. Что это означает?
Общее доступное дисковое пространство было собрано из дисков с одинаковыми характеристиками. Например 300 дисков 15k. И производительность была одинаковой по всему пространству. С появлением технологии многоуровневого хранения, СХД стали неплоскими - производительность различается внутри одного дискового пространства. Причем не просто различается, а еще и непредсказуемо, в зависимости от алгоритмов и возможностей конкретной модели СХД.
И все было бы не так интересно, не появись гиперконвергентные системы с локализацией данных. Помимо неравномерности самого дискового пространства появляется еще и неравномерность доступа к нему - в зависимости от того, на локальных дисках узла лежит одна из копий данных или за ней необходимо обращаться по сети.
Привычные синтетические тесты резко дают маху, цифры от этих нагрузок потеряли практический смысл. Единственный способ всерьез оценить подходит ли система - это пилотная инсталляция с перенесением продуктива. Но что делать, если на перенос продуктива не дает добро безопасность или это просто слишком долго / трудоемко. Есть ли способ оценки?


Сделаем вид, что мы продуктивная нагрузка, и нагрузим весь гиперконвергентный кластер. Смело вычеркиваем "100% random по всему объему" - этот тест не покажет ровным счетом ничего, кроме производительности самых нижних дисков. Т.е. 150-300 IOPS на узел (2-4 SATA).

Что для этого требуется?

1. Минимум по 1 машине с генератором нагрузки на узел.
2. Профили нагрузки, приближенные к продуктиву.

Для массовых нагрузок типа VDI необходимо создание репрезентативного количества машин. В идеале конечно полного, но поскольку большинство демо-систем - это 3-4 узла, то 3000-4000 ВМ на них конечно никак не запустить.

В моих цепких лапах оказался кластер Nutanix NX-3460G4, но тест применим к любой платформе, доступной на рынке. Более того, те же самые тесты можно проводить и для классических СХД, технология никак не меняется.



В качестве генератора нагрузки я взял FIO под управлением CentOS 7. Профили нагрузок от Nutanix XRay 2.2. Почему CentOS? Был дистрибутив под рукой, можно использовать любой другой Linux по вкусу.
Делаем несколько шаблонов ВМ под разный тип нагрузки.

1. Управляющая FIO - 1 vCPU, 2GB RAM, 20GB OS
2. DB - 1 vCPU, 2GB RAM, 20GB OS, 2*2 GB Log, 4*28 GB Data
3. VDI - 1 vCPU, 2GB RAM, 20GB OS, 10 GB Data

Создаем управляющую FIO. Ставим CentOS в минимальной установке на 20GB диск, остальные не трогаем.

После минимальной установки CentOS ставим FIO
# yum install wget
# wget http://dl.fedoraproject.org/pub/epel/testing/7/x86_64/Packages/f/fio-3.1-1.el7.x86_64.rpm
# yum install fio-3.1-1.el7.x86_64.rpm

Повторяем то же самое для машин шаблонов нагрузки. И прописываем FIO в автозагрузку на них.
Создаем файл /etc/systemd/system/fio.service

[Unit]
Description=FIO server
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/fio --server
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

# systemctl daemon-reload
# systemctl enable fio.service
# systemctl start fio.service
# firewall-cmd --zone=public --permanent --add-port=8765/tcp

Инфраструктура готова. Теперь нужна нагрузка.
Создадим список серверов FIO.
10.52.8.2 - 10.52.9.146

Удобно использовать для этого Excel.



Загружаем этот список на управляющую машину. На нее же загружаем конфиг-файлы FIO c нагрузкой.

fio-vdi.cfg

[global]
ioengine=libaio
direct=1
norandommap
time_based
group_reporting
disk_util=0
continue_on_error=all
rate_process=poisson
runtime=3600

[vdi-read]
filename=/dev/sdb
bssplit=8k/90:32k/10,8k/90:32k/10
size=8G
rw=randread
rate_iops=13
iodepth=8
percentage_random=80

[vdi-write]
filename=/dev/sdb
bs=32k
size=2G
offset=8G
rw=randwrite
rate_iops=10
percentage_random=20

fio-oltp.cfg

[global]
ioengine=libaio
direct=1
time_based
norandommap
group_reporting
disk_util=0
continue_on_error=all
rate_process=poisson
runtime=10000

[db-oltp1]
bssplit=8k/90:32k/10,8k/90:32k/10
size=28G
filename=/dev/sdd
rw=randrw
iodepth=8
rate_iops=500,500

[db-oltp2]
bssplit=8k/90:32k/10,8k/90:32k/10
size=28G
filename=/dev/sde
rw=randrw
iodepth=8
rate_iops=500,500

[db-oltp3]
bssplit=8k/90:32k/10,8k/90:32k/10
size=28G
filename=/dev/sdf
rw=randrw
iodepth=8
rate_iops=500,500

[db-oltp4]
bssplit=8k/90:32k/10,8k/90:32k/10
size=28G
filename=/dev/sdg
rw=randrw
iodepth=8
rate_iops=500,500

[db-log1]
bs=32k
size=2G
filename=/dev/sdb
rw=randwrite
percentage_random=10
iodepth=1
iodepth_batch=1
rate_iops=100

[db-log2]
bs=32k
size=2G
filename=/dev/sdc
rw=randwrite
percentage_random=10
iodepth=1
iodepth_batch=1
rate_iops=100

Запустим FIO в для проверки правильности настроек и первичного прогрева дисков.

На управляющей ВМ

# fio --client vdi.cfg

Минуты через 2-3 можно нажать Ctrl-C, иначе FIO отработает полный цикл из конфига - 2 часа.

Теперь подготовим площадку под массовое развертывание VDI нагрузки. Я создал совершенно непересекающуюся сеть с IPAM - гипервизор AHV перехватывает DHCP и выдает адреса сам.



Поскольку AHV выдает адреса не по порядку, сделаем пул размером ровно под планируемую нагрузку - 400 ВМ (по 100 на хост).



Создаем нагрузочные 400 машин VDI.





В принципе только создание сразу 400 машин уже интересный тест любой системы.
Как у нас справился немолодой уже кластер Nutanix?



2 минуты. Мне кажется, отличный результат.

Теперь включаем машины.

На Nutanix CVM
# acli vm.on fio-vdi-*

Ну и теперь самое время врубить полный газ!
С управляющей FIO
# fio --client vdi.list vdi.cfg

Примерно так ваша СХД будет себя чувствовать под 400 ВМ со средней офисной VDI нагрузкой.

Так же в статье указаны профили для средней OLTP и DSS БД. Их, конечно не по 400, но штук 6-8 можно запустить и попробовать. Например для 8 OLTP и 2 DSS нам потребуется 10 машин из тех, что имеют по 6 дополнительных дисков.

С двух терминалов сразу
1. # fio --client oltp.list fio-oltp.cfg
2. # fio --client dss.list fio-dss.cfg

Казалось бы, все идет хорошо. Каждая система показывает себя неплохо, и ничего не предвещает беды. Сделаем беду сами!



Теперь наблюдаем как под нагрузкой система будет перестраиваться и как это изменит показатели. Особое внимание обратите на "умные" системы, которые откладывают перестроение и восстановление отказоустойчивости на час и более. Не, ну а что такого? А вдруг это ничего страшного нет, подумаешь узел вылетел. Зато на тестах красивые цифры останутся. Если не читать то, что мелким шрифтом в глубинах документации.
Nutanix начинает процесс восстановления автоматически, через 30 секунд после недоступности CVM. Даже если это легитимная операция как например перезагрузка при обновлении.

При помощи подобного нехитрого руководства можно попробовать - а подходит ли вам предлагаемая вендором / интегратором система.
Ну или конечно, вы можете просто скачать Nutanix XRay, которая сделает все это в автоматическом режиме с красивыми графиками для платформ Nutanix AHV и VMware! :)

Meltdown and Spectre

В России все еще продолжаются праздники, но весь мир уже третий день будоражит известие о новых уязвимостях, которым подвержены большинство современных CPU.

Как всегда, подобные известия создают множество слухов, провокаций и откровенно глупостей.

Пока, реально оценить угрозу и все произошедшее мало кто может. Давайте не поддаваться панике, внимательно читать первоисточники и принимать разумные решения.


"Официальный" сайт с описанием найденных уязвимостей: https://meltdownattack.com

Проект Project Zero с подробным техническим описанием уязвимостей: https://googleprojectzero.blogspot.ru/2018/01/reading-privileged-memory-with-side.html

Еще технические детали от Google: https://security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html

Многие вендоры уже выпустили свои информационные бюллетени, ищем их на сайте уязвимости, внизу страницы есть ссылки: https://meltdownattack.com

Список ссылок на информационные бюллетени вендоров также есть на reddit:
https://www.reddit.com/r/networking/comments/7o4y40/meltdownspectre_vulnerability_tracker/

Что касается VMware

Используем только проверенные источники/первоисточники, на сайте VMware раздел с описание уязвимостей: https://www.vmware.com/security/advisories.html

Согласно VMSA-2018-0002 патчи для ESXi были выпущены еще 19 декабря 2017, их нужно устанавливать: https://www.vmware.com/us/security/advisories/VMSA-2018-0002.html

Гостевые ОС также подвержены уязвимостям, следим за новостями у производителей ОС, ссылки есть здесь: https://meltdownattack.com

Следим за блогом VMware Security & Compliance Blog. Например, сегодня появилась информация о vRealize Operations for Horizon, vRealize Operations for Published Applications, Workstation, Horizon View Client and Tools: https://blogs.vmware.com/security

VMware выпустили статью с описанием уязвимостей в Virtual Appliances: https://kb.vmware.com/s/article/52264

И еще раз, будем внимательны, следим за официальными источниками информации, не "ведемся" на слухи и провокации, осознав прочитанное принимаемся за работу.

Всем успехов!


UPD. История продолжается, прилетели новые обновления для ESXi и vCenter: https://www.vmware.com/us/security/advisories/VMSA-2018-0004.html

UPD. Патчи из VMSA-2018-0004 пока лучше не ставить:
https://kb.vmware.com/s/article/52345

UPD. Вышел новый эпизод:
https://www.vmware.com/us/security/advisories/VMSA-2018-0004.html

Nutanix User Group Russia 2017

Друзья, рад объявить о проведении Nutanix User Group Russia (sponsored by Intel).

Уже зарегистрировалось более 100 человек.

Будет проходить в Москве 20-го декабря. С 14-00 и до упора.
Место проведения - HopHead, Москва.

Будет много интересного - покажем Nutanix 5.5 (включая микросегментацию), будут доклады партнеров, заливное море крафтового пива, вкусная еда и прочие приятности.

Выступления партнеров:
Intel - Новинки Intel для гиперконвергентных сред (Xeon Scalable, Optane, 3D Nand, Ethernet)
Citrix - "Как размножаются ёжики - MCS vs PVS для VDI"
BitDefender - Защита данных в виртуальных средах
Arista - Сеть в эпоху гиперконвергентности

Восстанавливаем файловую систему загрузочного диска ESXi

Столкнулся с проблемой установки/обновления VMware Tools на машинах, работающих на одном из хостов в кластере:



С машинами, работающими на других хостах кластера такой проблемы нет, можно без ошибок установить/обновить VMware Tools.
После прочтения, предложенного в сообщении об ошибке KB Installing and upgrading the latest version of VMware Tools on existing hosts, подключился по SSH к проблемному хосту и обнаружил следующую картину:



Файловая система раздела, содержащего VMware Tools разрушена.
Первая мысль переустанавливать ESXi с нуля, но подумав пару минут, пришло осознание, ESXi все-таки Linux и должен быть путь «починить» файловую систему раздела без полной переустановки ESXi.

Возможно, данная проблема связана с KB High frequency of read operations on VMware Tools image may cause SD card corruption.
Начиная с ESXi 6.0 U3 появился дополнительный параметр, который позволяет при загрузке ESXi создать RAM диск, содержащий образы VMware Tools. Это снизит нагрузку на загрузочный диск при многократной установке VMware Tools.

Итак, первым делом выводим хост в Maintenance Mode.
Далее, нужно понять какой раздел смонтирован в папку /store (locker – это ссылка на store). Для это этого выполним команду:

vmkfstools -P /store

Обычно это 8 раздел загрузочного устройства (почему 8 раздел можно прочитать в статье Загрузка ESXi c USB/SD и что меняется, когда появляется vSAN):



Запускаем проверку диска для 8 раздела загрузочного диска:

dosfsck -a -w /dev/disks/mpx.vmhba32:C0:T0:L0:8

Бывает, что требуется ручное исправление ошибок на диске, тогда:

dosfsck -v -w -r /dev/disks/mpx.vmhba32:C0:T0:L0:8

Далее, удаляем содержимое папки /store и перезагружаем проблемный хост:

rm -r /store/*

При загрузке ESXi восстановит необходимые файлы и папки в store, но vib пакет с VMware Tools нам придется восстановить руками, можно это сделать, например, через Update Manager:




К сожалению, я сталкивался с ситуациями, когда USB/SD карты выходили из строя или «ломались» партиции на них. Вообщем, разбираться и «чинить» точно бы заняло кучу времени.
На этот случай есть возможность создания резервной копии конфигурации ESXi и последующего восстановления из нее. Все это описано в KB How to back up ESXi host configuration. Данная процедура работает и для хостов с VMware vSAN без необходимости эвакуировать данные с проблемного хоста.

Делаем резервную копию конфигурации, например, через PowerCLI:

Connect-VIServer -Server host_ip
Get-VMHostFirmware -VMHost host_ip -BackupConfiguration -DestinationPath C:\Temp

Переустанавливаем ESXi с нуля. И восстанавливаем настройки из резервной копии:

Connect-VIServer -Server host_ip
Set-VMHost -VMHost -State 'Maintenance'
Set-VMHostFirmware -VMHost host_ip -Restore -SourcePath C:\Temp\configBundle host_ip.tgz -HostUser root -HostPassword Password

Перезапуск Management agents в ESXi и терпение

Бывает такое, что ESXi отключается от vCenter, но виртуальные машины, запущенные на нем, продолжают работать, это означает, что проблема в сервисах гипервизора, отвечающих за коммуникацию с vCenter'ом (Troubleshooting an ESXi/ESX host in non responding state).



Самое очевидное решение, просто их перезапустить, но как раз в этом то может и крыться проблема.
Перезапустить hostd и vpxa (а именно эти сервисы отвечают за связь ESXi и vCenter), согласно Restarting the Management agents in ESXi, можно через Host Client (https://<esxihost>/ui/), подключившись к хосту через SSH или DCUI.
Как все легко, но обычно, когда есть проблемы с hostd и vpxa, то и Host Client перестает работать и выглядит вот так:



При этом по умолчанию SSH на ESXi хостах выключен. И соответственно остается только DCUI - радуемся, что у нас есть iDRAC, iLO, etc. или бежим к серверу.

Ну и здесь все не без проблем. Нажав F2 в DCUI и введя пароль нас ожидает новая проблема, ничего дальше не происходит, окошко логина висит, а в меню мы попасть не можем. Тут нам поможет только терпение, в таком состоянии логин может идти несколько минут, а бывает, что и 15-20 минут. Ждем.
Дождавшись входа на нужно найти пункт меню Troubleshooting Options и выбрать Restart Management Agents:



К сожалению, это не всегда помогает, иногда нужно подключится по SSH, почитать логи и выполнить какие-нибудь команды. Проще простого.
Для это нам нужно включить SSH через DCUI, выбираем пункт меню Troubleshooting Options и Enable SSH. Вот здесь нас снова ожидает большой сюрприз, DCUI перестает реагировать на клавиатуру. Это может продолжаться полчаса, а может и несколько часов. Терпение, ждем и SSH включен. Дело за малым, подключиться по SSH и выполнить команды:

/etc/init.d/hostd restart
/etc/init.d/vpxa restart

Загрузка ESXi c USB/SD и что меняется, когда появляется vSAN

Я уверен, что каждый из вас устанавливал ESXi тысячи раз, установка настолько простая, что, я думаю, вы даже не успевали задуматься, а что же на самом деле происходит в этот момент.

В этой статье я предлагаю разобраться подробнее, что же происходит во время установки ESXi. Начнем с того, что согласно документации ESXi Hardware Requirements ESXi можно установить на устройство размером минимум 1GB, это может быть USB stick, SD card, локальный диск, SAN/iSCSI LUN и набирающий популярность, но еще достаточно дрогой вариант – SATADOM, возможно применение vSphere Auto Deploy.

Лично мне варианты загрузки SAN/iSCSI LUN и vSphere Auto Deploy не нравятся. При проблемах с сетью хост даже не сможет загрузится, что еще сильнее усложнит поиск проблемы. Я не буду рассматривать эти варианты.

Как было сказано выше для установки ESXi достаточно накопителя объемом 1GB и если мы выберем такой накопитель и посмотрим на разделы, созданные при установке ESXi, то мы увидим следующую картину. Пять обязательных раздела (Начиная с ESXi 4.x MBR был заменен на GPT).

• Раздел #1. Самый маленький раздел, в нем находится загрузчик.
• Раздел #5. Содержит образ операционной системы гипервизора.
• Раздел #6. Содержит альтернативный образ операционной системы гипервизора.
• Раздел #7. Предназначен для сохранения coredump в случае PSOD (Pink Screen of Death).
• Раздел #8. Содержит образы VMware Tools и Floppy Images.

Все, вроде, очевидно кроме раздела #5 и раздела #6.

Основное отличие от традиционной операционной системы в ESXi - это то, что все файлы, необходимые гипервизору, хранятся в разделе фиксированного объема (Primary Boot Bank - 250 МБ). Альтернативный Boot Bank такого же размера необходим на случай отката к предыдущей версии ESXi вне зависимости от того был ли произведен Update (накатывание патчей) или Upgrade (накатывание новой версии ESXi). При обновлении ESXi не перезаписывает предыдущую версию, а создает новый образ операционной системы гипервизора и сохраняет возможность «откатиться» в случае неудачного обновления.

Нажав «SHIFT+R» при загрузке гипервизора мы можем выбрать версию для загрузки.

Что же хранится в этих разделах? Образ гипервизора – это файл сжатый файл s.v00, который разжимается при загрузке и содержит операционную систему гипервизора. Корневой раздел (/etc, /lib и т.д.) появляется в результате распаковки образа, таким образом, корневой раздел располагается только в оперативной памяти хоста. Возникает резонный вопрос, а как сохраняются настройки? При плановом выключении все конфиги запаковываются в файл state.tgz, который сохраняется рядом с образом гипервизора. При каждой загрузке настройки читаются из этого файла. Если завершить работу гипервизора некорректно, то все несохраненные изменения в настройках гипервизора будут утеряны. (UPD. не совсем так, см. комментарий).

Что же изменится, если мы возьмем для установки диск объемом более 1GB (~5.2GB)?

Мы увидим, что появятся два дополнительных раздела:

• Раздел #2. Раздел Scratch, содержащий разнообразные log файлы vmkernel и других компонент гипервизора.
• Раздел #3. Весь оставшийся объем будет выделен под VMFS раздел. Он будет виден как Local Storage в vSphere Client и на нем можно будет размещать файлы виртуальных машин.

И последнее про разделы. Начиная с ESXi 5.5 был добавлен второй раздел для coredump. Самое интересное, что, если вы обновлялись до версии 5.5, то вы не найдете этот раздел, он не будет существовать. Он будет создан только при чистой установке ESXi (Two coredump partitions in ESXi 5.5?).

Связано это с тем, что объем оперативной памяти, установленный в сервера растет, и раздел объемом 110MB уже не способен уместить coredump современного сервера.

Все это мы можем увидеть и подключившись к гипервизору по SSH. Мы видим все 8 разделов на диске, размеры этих разделов соответствуют написанному выше.

Так же мы можем увидеть, что разделы altbootbank, bootbank, scratch и store смонтированы в соответствующие папки файловой системы.

Все вышесказанное справедливо для установки на локальный диск или SATADOM достаточного объема. Подключившись по SSH к ESXi серверу, мы можем увидеть, что ID разделов соответствуют ID смонтированных томов.

Если мы установили ESXi на USB stick или SD card поведение гипервизора меняется. Связано это с тем, что «живучесть» (endurance) USB stick или SD card очень низкая и,, если гипервизор начнет писать свои логи на них, то он выведет их из строя очень быстро.

При установке ESXi определяет тип загрузочного устройства и, если это USB stick или SD card, установщик не будет создавать Раздел #2 (Scratch), а папка Scratch будет ссылаться на /tmp/scratch. Подключившись к хосту через vSphere Client, мы увидим предупреждения, что логи сервера сохраняются на non-persistent хранилище и будут потеряны при перезагрузке.

Если в системе появится локальный Storage, то при очередной перезагрузке гипервизор увидит, что логи можно писать на него. В раздел scratch будет смонтирована папка .locker, находящаяся на этом локальном Storage, а предупреждение пропадет.

Как я уже писал выше, гипервизор при загрузке «живет» в памяти. Для этого используются RAM диски. RAM диск – это раздел или хранилище, находящиеся в оперативной памяти сервера, важно помнить, что при перезагрузке, все данные из RAM диска будет потеряны. Примером использования RAM диска является монтирование scratch в /tmp/scratch. С помощью команды esxcli system visorfs ramdisk list можно увидеть список всех RAM дисков.

Что же такое scratch и почему я уделил так много времени ему?

Это раздел, в который гипервизор пишет все свои логи, а в случае проблем и обращении в техническую поддержку VMware, логи очень важны!

Я настоятельно рекомендую разобраться с хранение логов в вашей системе и принять меры для надежного и понятного их хранения. Для этого можно ознакомиться с KB Creating a persistent scratch location for ESXi. Приведу здесь только скриншот алгоритма выбора гипервизором места хранения логов.

Отличным вариантом является использование Syslog сервера для сбора логов. Возможно у вас уже есть Syslog сервер для другого оборудования, если нет, то это хороший повод начать его использовать Configuring syslog on ESXi. Например, можно использовать VMware Log Insight. Если у вас куплен vCenter, то для небольшой инфраструктуры его можно использовать бесплатно.

С логами мы разобрались. Перейдем к coredump

Coredump как и логи является очень важным источником информации, необходимым для работы технической поддержки при расследовании инцидентов. В coredump записывается состояние системы при PSOD (при «падении» системы).

Как я писал выше, начиная с ESXi 5.5 таких раздела два, мы можем увидеть это на скриншоте ниже. 

Настоятель рекомендую проверить coredump разделы на ваших гипервизорах и в случае необходимости внести изменения Configuring a diagnostic coredump partition on an ESXi 5.x/6.x host и Configuring ESXi coredump to file instead of partition.

Важно заметить, что если вы используете в своей инфраструктуре ESXi хосты с объемом RAM памяти больше 512GB (и vSAN), то вам следует ознакомится с еще одной статьей из KB Extending an ESXi diagnostic coredump partition on a vSAN node. Дело в том, что стандартный раздел для coredump (2.5GB) может не вместить дамп и этот раздел нужно будет увеличить.

Появляется vSAN

vSAN приносит в нашу систему еще один набор логов - vSAN traces:

• vSAN traces help VMware support and engineering to understand what is going on internally with vSAN.
• It should be noted that these traces are *not* part of syslog.
• So if you setup a syslog server to capture VMkernel logs, you will not capture vSAN traces.
• vSAN trace files are not persisted with syslog because the bandwidth requirements are too high.  (Although with vSAN 6.2, we now persist just the “most important” traces along with syslog https://kb.vmware.com/kb/2145556).

И теперь необходимо заботиться о сохранности еще одного набора логов.

Что важно для нас, что vSAN traces ведут сябя аналогично scratch и если мы установили гипервизор на USB stick или SD card, то traces будут писаться в RAM диск и пропадут при перезагрузке.

Так как vSAN traces очень важны для восстановления данных при сбое, то при штатной перезагрузки наиболее важные из них записываются на персистентное хранилище:

Здесь должны быть выводы

1. У вас должен (обязан) быть syslog сервер и чем больше на него будет перенаправлено логов, тем легче будет увидеть корреляцию при сбоях. Отличной практикой является перенаправлять логи и серверов и сетевого оборудования и СХД на один syslog сервер. Это позволит вам сразу увидеть, что, например, сбой коммутатора повлек проблемы на виртуальной платформе.
2. Нужно быть внимательным с выбором загрузочного устройства для ESXi и помнить, что не все устройства одинаково полезны.
3. Еще раз перепроверить, что логи записываются на какое-то постоянное хранилище и к ним можно получить доступ.
4. Аналогично про coredump, перепроверить, что раздел для записи дампа существует, и он подходящего для хоста объема.
5. И раз я писал про vSAN, не могу не упомянуть, что все оборудование хоста должно быть в VMware Compatibility Guide, включая версии firmware и версии драйверов.

Ограничивать ли пользователей по ресурсам?

Сколько я занимаюсь ИТ - столько я слышу от админов "больно жирно будет пользователям, обрежем им трафик / объем почтового ящика / файловую шару / заблокируем сайт / подставить по вкусу". И ровно столько же у меня возникает вопрос: какое ваше дело?
Давайте забудем, что мы ИТ-шники и управляем клевыми СХД, фермами серверов, поточвыми серверами и посмотрим на всю это катавасию отстраненно. Рассмотрим коммерческую структуру.

1. Чем занимается ваша компания?

Забудьте про производство туалетной бумаги, штанов или даже авиадвигателей.
Правильный ответ: она производит деньги. Причем так, чтобы произведенных денег получалось больше, ченм потраченных.

2. Кто производит деньги?

А их производят те самые "тупые юзвери", которые просят нажать any key великого и могучего техномага. Даром что техномаг настолько велик, что не может читать инструкции на английском (рабочем языке ИТ), а для русского он и так слишком велик.

3. При помощи чего они производят деньги?

Деньги производятся в том числе при помощи ИТ сервисов, включая почтовые серверы для коммуникации с клиентами, интернета, систем учета, бухгалтерии и т.д. В процессе производства денег ИТ сервисы потребляют ИТ ресурсы - сырые мощности (процессоры / ОЗУ / СХД), лицензии, каналы.

4. Кому принадлежит ИТ инфраструктура и ресурсы?

Вот здесь раз от раза я натыкаюсь на то, что администраторы начинают считать серверы, СХД и коммутаторы "своими". Даже немного, и начинают относиться к ним соответственным образом.

Правильный ответ: они принадлежат компании (владельцу компании) и должны исполнять свою задачу по генерации денег.

5. И теперь - кто должен решать, сколько ресурсов может потребить сотрудник бизнес подразделения?

Как мне кажется, это абсолютно точно не должен быть ИТ админ. Просто потому что он понятия не имеет о том, как эти ресурсы приносят деньги.
Потребление ресурсов должно быть неограниченным со стороны ИТ, с практически нулевым весом ИТ в принятии решения о выделении ресурсов на ИТ инфраструктуре. Кроме разве что моментов, когда внезапный рост потребления может положить всю инфраструктуру целиком.

Необходима система внутреннего биллинга, которая вместо ограничения потребления попросту присылает в конце месяца счет начальнику отдела и фин. директору о том, кто сколько и каких ресурсов потребил. В рублях. Просто потому что именно эти два человека понимают какую доли прибыли генерирует данный сотрудник и сколько ему надо ресурсов для генерации этой прибыли.

Вы конечно можете возразить сразу по нескольким пунктам. Давайте их рассмотрим.

1. Если не ограничивать соц. сети, то вместо работы все будут только во вконтактике сидеть.

Может быть. Но разве это ваша сфера ответственности и знаний? У сотрудника есть начальник, который оценивает качество его работы. Может быть, конечно, именно начальник попросит обрезать Ивану Ивановичу Иванову доступ к соц. сетям - но это его сфера принятия решения. Может быть это будет политика ИБ, но опять же, это не решение админа.

2. Они безмозглые и ничего не понимают в ИТ. И совсем не думают, что их смешные картинки и видюшки в почтовых вложениях полностью съедят СХД под почту.

Ну на то и есть вы, мозглые и понимающие. Только вот есть снова интересный момент, ничего не воспитывает человека так быстро и эффективно, как воздействие на его кошелек. Один раз остаться всем отделу маркетинга без премии потому что они 90% потребленного пространства в почте потратили на картинки - и их компьютерная грамотность / здравый смысл резко повысятся. А самое главное, стимулировать их повышение будет родными и понятными методами начальник отдела, оставшийся без премии. Вся их премия уйдет на расширение СХД.

3. У нас в ИТ ограниченный бюджет и мы не можем позволить им есть ресурсов сколько они хотят.

Позвольте, но это классический пример "административная проблема техническими средствами не решается". Проблема с планированием бюджета / экономическим обоснованием закупок в классической модели - это административная проблема на уровне директората, а не админа. Более того, при помощи биллинга вопрос обоснования бюджетов решается сильно проще.
Есть и другая сторона ограничения ресурсов. Вы перестаете контролировать что происходит в компании. Пользователи начинают удалять важную на самом деле почту, потому что новую не могут получить. Важные документы оказываются в облаках, переписка перемещается с корпоративной почты в Яндекс и Мейл.ру. Иными словами, именно слепой репрессивный метод является создателем "теневого ИТ".

И да, это все я рассказываю с 2014 года. "Департамент ИТ против частного облака"