STO8165, John Nicholson (@Lost_Signal)
VSAN Networking Deepdive
* Используйте мультикаст флад только для выделенных под VSAN VLANов
* Если у вас несколько кластеров VSAN в одном VLAN - поменяйте им мультикаст адреса, чтобы каждый кластер имел свой уникальный. Или разнесите по разным VLAN
* Не делайте VSAN поверх L3 если не уверены зачем это делаете
* Для больших и нагруженных кластеров VSAN очень чувствителен к степени переподписки аплинков. В качестве средней температуры можно взять 4 к 1, но для каждого случая надо смотреть конкретнее
* Идеальный вариант коммутаторов для VSAN - со связями запад-восток. Осторожнее с Cisco FEX - там все через аплинк
* Jumbo frames не имеют большого значения для VSAN
* Локализация ввода-вывода (data locality) не имеет большого смысла для VSAN, ведь каждая запись должна все равно идти через сеть. /* Nutanix смотрит на это утверждение с удивлением.
* Начиная с 6.5 поддерживаются микрокластеры из двух узлов с прямым подключением между узлами (кросс-кабелем).
* Растянутый кластер требует VSAN Enterprise и поддерживается с сетями 10G 5ms RTT. 1 Гбит в целом поддерживается, но не рекомендуется.
* Для растянутого кластера требуется cluster witness. Он может быть виртуальной машиной или ESXi хостом (для него не требуется лицензия). Сетевое подключение - не менее 100 мегабит. /* Nutanix снова смотрит с удивлением, обходясь 2 мегабитами.
* Дедупликация идет фиксированными блоками 4 кб для All-Flash. Гибридный VSAN не поддерживает дедупликацию. /* Nutanix махнул рукой, ушел
INF8701, Brett Guarino
vSphere Core 4 Performance Troubleshooting and Root Cause Analysis, Part 2: Disk and Network
* VMXNET драйвер работает в ring 1, E1000 - ring 2
* Почти все сводится к esxtop
* Хотите при помощи esxtop анализировать сеть? Купите БОЛЬШОЙ монитор
* Ключевые показатели при анализе сети в vSphere
- используемые физические аплинки для каждого vmnic
- фактическая скорость на vmnic
- счетчик пакетов и средний размер пакета на vmnic
- отброшенные пакеты на vmnic
- фактическая скорость на физическом интерфейсе
- счетчик пакетов и средний размер пакета на физическом интерфейсе
- отброшенные пакеты на физическом интерфейсе
* Исследование дисковой системы - это куда больше веселья, чем сети :)
* Ключевые показатели - IOPS, задержки и фактическая скорость в мегабайтах в секунду
* Ситуации с DAVG/KAVG:
- низкий/низкий - идеально
- низкий/высокий - перегруженный хост
- высокий/низкий - перегруженная СХД
- высокий/высокий - проблема и там, и там. Но иногда слишком перегруженная СХД ведем к перегрузке дискового стека хоста.
** остаток доклада по дисковой системе фактически повторяет мою презентацию на VMUG 2014 в упрощенном виде. (http://blog.vadmin.ru/2014/06/vmug-2014.html)
VIRT8530, Rob Girard, Shawn Meyers
Deep Dive on pNUMA and vNUMA - Save Your SQL VMs from Certain DoomA!
* SQL не очень работает на AMD NUMA. Ставьте Intel. /* речь, разумеется, о широких SQL
* Неправильная конфигурация NUMA может вести к падению производительности до 40%
* По умолчанию vNUMA включается только при 9+ vCPU ВМ.
- Если у вас 4 или 6-ядерные процессоры и ВМ с большим количеством vCPU, чем ядер на процессоре - у вас будут проблемы с NUMA
- Можно исправить при помощи numa.min.vcpu для ВМ
* Лучший сайзинг ВМ - это много сокетов по 1 ядру. В этом случае автоматика отработает и ситуация будет близка к идеальной
- как только вы измените количество ядер на отличное от 1, конфигурация vNUMA зафиксируется
- vSphere определит топологию NUMA на первой загрузке. Это фиксируется в .vmx
- Используйте более одного ядра на сокет только для приложений с лицензированием по сокетам
- Если вы уверены в том, что делаете - сделайте сайзинг по границам узлов
* Идеальный сайзинг ВМ по vCPU - число, кратное одному узлу NUMA. Т.е. для 12-ядерного узла это 1, 2, 3, 4, 6, 12. На практике 3 vCPU ВМ работает на 6-ядерном процессоре лучше, чем 4vCPU.
* vSphere 6.5 позволяет сделать двойной финт - обмануть приложение по лицензированию, и при этом технически использовать автосайзинг NUMA
- numa.vcpu.followcorespersocket = 0 (по умолчанию)
- если установить в 1, то вернется старое поведение
* Расширенные настройки. !!! Опасно !!! Только если вы действительно понимаете что делаете
- numa.vcpu.maxPerVirtualNode = 8 (по умолчанию) - для расширения ВМ на дополнительные NUMA узлы
- numa.vcpu.preferHT = False (по умолчанию) - использовать потоки HT вместо дополнительных узлов NUMA. Для некоторых нагрузок важнее остаться в пределах одного узла.
- numa.vcpu.min = 9 (по умолчанию) - когда vNUMA начинает использоваться
- numa.autosize = False (по умолчанию) - пересчитывать топологию NUMA каждый раз при загрузке ВМ. Рекомендуется в True.
- numa.autosize.once = True (по умолчанию) - рассчитывать топологию NUMA при первой загрузке ВМ. Рекомендуется в False.
- numa.autosize.cookie = [автогенерируемое] - автоконфигурация vNUMA. 160001 = 16 сокетов, 1 ядро
- numa.autosize.vcpu.maxPerVirtualNode = [автогенерируемое] - сколько ядер на каждый узел NUMA при автосайзинге.
* Если в .vmx присутствуют numa.autosize.vcpu.maxPerVirtualNode или cpuid.coresPerSocket - автосайзинг не используется
* CPU HotAdd для виртуальной машины отключает vNUMA
* Memory HotAdd работает по разному
- HW ver 8-10 добавляет память в vNUMA node 0, что приводит к дисбалансу
- HW ver 11 балансирует память между vNUMA узлами
* Настройки vNUMA на уровне хоста в абсолютном большинстве случаев НЕ НАДО трогать.
* Перед тем как винить vNUMA проверьте все остальное.
* Не делайте 4-сокетную ВМ на 2-сокетном сервере.
VSAN Networking Deepdive
* Используйте мультикаст флад только для выделенных под VSAN VLANов
* Если у вас несколько кластеров VSAN в одном VLAN - поменяйте им мультикаст адреса, чтобы каждый кластер имел свой уникальный. Или разнесите по разным VLAN
* Не делайте VSAN поверх L3 если не уверены зачем это делаете
* Для больших и нагруженных кластеров VSAN очень чувствителен к степени переподписки аплинков. В качестве средней температуры можно взять 4 к 1, но для каждого случая надо смотреть конкретнее
* Идеальный вариант коммутаторов для VSAN - со связями запад-восток. Осторожнее с Cisco FEX - там все через аплинк
* Jumbo frames не имеют большого значения для VSAN
* Локализация ввода-вывода (data locality) не имеет большого смысла для VSAN, ведь каждая запись должна все равно идти через сеть. /* Nutanix смотрит на это утверждение с удивлением.
* Начиная с 6.5 поддерживаются микрокластеры из двух узлов с прямым подключением между узлами (кросс-кабелем).
* Растянутый кластер требует VSAN Enterprise и поддерживается с сетями 10G 5ms RTT. 1 Гбит в целом поддерживается, но не рекомендуется.
* Для растянутого кластера требуется cluster witness. Он может быть виртуальной машиной или ESXi хостом (для него не требуется лицензия). Сетевое подключение - не менее 100 мегабит. /* Nutanix снова смотрит с удивлением, обходясь 2 мегабитами.
* Дедупликация идет фиксированными блоками 4 кб для All-Flash. Гибридный VSAN не поддерживает дедупликацию. /* Nutanix махнул рукой, ушел
INF8701, Brett Guarino
vSphere Core 4 Performance Troubleshooting and Root Cause Analysis, Part 2: Disk and Network
* VMXNET драйвер работает в ring 1, E1000 - ring 2
* Почти все сводится к esxtop
* Хотите при помощи esxtop анализировать сеть? Купите БОЛЬШОЙ монитор
* Ключевые показатели при анализе сети в vSphere
- используемые физические аплинки для каждого vmnic
- фактическая скорость на vmnic
- счетчик пакетов и средний размер пакета на vmnic
- отброшенные пакеты на vmnic
- фактическая скорость на физическом интерфейсе
- счетчик пакетов и средний размер пакета на физическом интерфейсе
- отброшенные пакеты на физическом интерфейсе
* Исследование дисковой системы - это куда больше веселья, чем сети :)
* Ключевые показатели - IOPS, задержки и фактическая скорость в мегабайтах в секунду
* Ситуации с DAVG/KAVG:
- низкий/низкий - идеально
- низкий/высокий - перегруженный хост
- высокий/низкий - перегруженная СХД
- высокий/высокий - проблема и там, и там. Но иногда слишком перегруженная СХД ведем к перегрузке дискового стека хоста.
** остаток доклада по дисковой системе фактически повторяет мою презентацию на VMUG 2014 в упрощенном виде. (http://blog.vadmin.ru/2014/06/vmug-2014.html)
VIRT8530, Rob Girard, Shawn Meyers
Deep Dive on pNUMA and vNUMA - Save Your SQL VMs from Certain DoomA!
* SQL не очень работает на AMD NUMA. Ставьте Intel. /* речь, разумеется, о широких SQL
* Неправильная конфигурация NUMA может вести к падению производительности до 40%
* По умолчанию vNUMA включается только при 9+ vCPU ВМ.
- Если у вас 4 или 6-ядерные процессоры и ВМ с большим количеством vCPU, чем ядер на процессоре - у вас будут проблемы с NUMA
- Можно исправить при помощи numa.min.vcpu для ВМ
* Лучший сайзинг ВМ - это много сокетов по 1 ядру. В этом случае автоматика отработает и ситуация будет близка к идеальной
- как только вы измените количество ядер на отличное от 1, конфигурация vNUMA зафиксируется
- vSphere определит топологию NUMA на первой загрузке. Это фиксируется в .vmx
- Используйте более одного ядра на сокет только для приложений с лицензированием по сокетам
- Если вы уверены в том, что делаете - сделайте сайзинг по границам узлов
* Идеальный сайзинг ВМ по vCPU - число, кратное одному узлу NUMA. Т.е. для 12-ядерного узла это 1, 2, 3, 4, 6, 12. На практике 3 vCPU ВМ работает на 6-ядерном процессоре лучше, чем 4vCPU.
* vSphere 6.5 позволяет сделать двойной финт - обмануть приложение по лицензированию, и при этом технически использовать автосайзинг NUMA
- numa.vcpu.followcorespersocket = 0 (по умолчанию)
- если установить в 1, то вернется старое поведение
* Расширенные настройки. !!! Опасно !!! Только если вы действительно понимаете что делаете
- numa.vcpu.maxPerVirtualNode = 8 (по умолчанию) - для расширения ВМ на дополнительные NUMA узлы
- numa.vcpu.preferHT = False (по умолчанию) - использовать потоки HT вместо дополнительных узлов NUMA. Для некоторых нагрузок важнее остаться в пределах одного узла.
- numa.vcpu.min = 9 (по умолчанию) - когда vNUMA начинает использоваться
- numa.autosize = False (по умолчанию) - пересчитывать топологию NUMA каждый раз при загрузке ВМ. Рекомендуется в True.
- numa.autosize.once = True (по умолчанию) - рассчитывать топологию NUMA при первой загрузке ВМ. Рекомендуется в False.
- numa.autosize.cookie = [автогенерируемое] - автоконфигурация vNUMA. 160001 = 16 сокетов, 1 ядро
- numa.autosize.vcpu.maxPerVirtualNode = [автогенерируемое] - сколько ядер на каждый узел NUMA при автосайзинге.
* Если в .vmx присутствуют numa.autosize.vcpu.maxPerVirtualNode или cpuid.coresPerSocket - автосайзинг не используется
* CPU HotAdd для виртуальной машины отключает vNUMA
* Memory HotAdd работает по разному
- HW ver 8-10 добавляет память в vNUMA node 0, что приводит к дисбалансу
- HW ver 11 балансирует память между vNUMA узлами
* Настройки vNUMA на уровне хоста в абсолютном большинстве случаев НЕ НАДО трогать.
* Перед тем как винить vNUMA проверьте все остальное.
* Не делайте 4-сокетную ВМ на 2-сокетном сервере.
Сообщения
