EZ
хм, а что говорит сфера если у конкретно этой машины открыть vsan performance?
Size: a a a
2020 April 19
EZ
Индийские гайды нужно применять, когда понимаешь, что внутри системы и к чему это приведёт.
Окей, каждый остается при своем мнении.
T
Нет своего мнения, есть система у человека в администрировании, и есть сомнительные советы, основанные на сомнительном понимании характера i/o в системе.
EZ
Ок, Вы, очевидно, в курсе характера io в системе - дебажьте.
EZ
@Dunyashov а вы требования bigbluebutton и freeswitch выполнили? Там есть очень четкие указания на конфигурацию для core.db
N
Так. Мы сейчас зайдем слишком далеко. Механизм траблшутинга vsan простой:
N
Шаг 0. Открываем кейс.
Шаг 1. Смотрим latency на ВМ из гостя. Если она большая, то начинаем определять где она возникает. Для этого:
А.) открываем vm -> monitor -> vsan performance.
Б) смотрим на каких хостах/dg/дисках лежит vmdk.
B) открываем Хост, где работает ВМ и где лежат данные. Monitor --> vsan performance -> front-end. На хостах с данными -> backend.
Г) смотрим latency на всех DG с данными.
Д) смотрим latency на физических cache и capacity дисках, где есть жанне.
Шаг 1. Смотрим latency на ВМ из гостя. Если она большая, то начинаем определять где она возникает. Для этого:
А.) открываем vm -> monitor -> vsan performance.
Б) смотрим на каких хостах/dg/дисках лежит vmdk.
B) открываем Хост, где работает ВМ и где лежат данные. Monitor --> vsan performance -> front-end. На хостах с данными -> backend.
Г) смотрим latency на всех DG с данными.
Д) смотрим latency на физических cache и capacity дисках, где есть жанне.
N
Остановится имеет смысл, когда найдёте, где она растёт. Например, если в vsan client она низкая, то смотреть дальше в сеть и диски нет никакого смысла
N
Смотрим esxtop, где davg - vSAN, проверяем, что kavg мало. Если это так, то лезем в гостя и максимум виртуальные адаптеры вм
N
Если на клиенте все плохо, а на бекенде хорошо - смотри сеть
N
Ну и так далее
N
Последний момент, что говорить о latency имеет смысл, когда есть хоть какая-то нагрузка. На 1-10 iops слишком велико влияне буферов на всех уровнях + толком задержку и посчитать не получится
N
Ну и чтобы не делать все это руками - используйте vRops c агентами в ос.
EZ
а vrops свои собственные данные собирает? А то вон у человека внутри vrops лейтенси тоже не шибко маленькая
N
Хотя Observer/monitoring for support тоже вариант
N
а vrops свои собственные данные собирает? А то вон у человека внутри vrops лейтенси тоже не шибко маленькая
Насколько я помню, из коробки, агентов на ос мониторинг в самом appliance нет
N
Но моя основная мысль, что если, например, на уровне vsan DOM client все хорошо, то проверять сеть или hba смысла большого нет (особенно, если все железо и драйвера поддерживаются). Это значит, что vsan отдал IO в стораджовый стек хоста нормально и надо смотреть выше по стеку
2020 April 21
GP
Скажу честно, это было нелегко, продолжение истории про планировщик K8s в VMware vSphere 7 (от Frank Denneman): https://medium.com/@pryalukhin/scheduling-vsphere-pods-682ffb793b28
2020 April 22
VK
