Первый VMUG Belarus
7 декабря в городе Минск пройдет первый VMUG Belarus.
Время и место: 10-00 гостиница Орбита.
Что это ? неофициальное, некоммерческое мероприятие, посвященное продуктам VMware и смежным технологиям.
Зачем ? это отличная возможность поделиться опытом, узнать ответы на технические вопросы, послушать доклады представителей EMC, VMware и других профильных компаний. И все это в неформальной обстановке.
Для кого ? системные администраторы, инженеры поддержки, руководители IT отделов, IT аналитики и все кто не равнодушен к технологиям виртуализации.
Программа:
1. Возможности EMC Avamar для резервного копирования сред VMware. (Дмитрий Лицов .EMC)
2. vSphere 5.1: Что нового? (Константин Введенский. VMUG UA)
3. Симбиоз Citrix XenAPP и VMware vSphere (Сергей Горлинский. VMUG BY)
4. VMware vSphere Reolication Technical Deepdive (Евгений Гарбузов. VMUG UA)
5. Как сделать, чтобы дисковая система не стала узким местом инфраструктуры (Антон Жбанков. EMC)
6. Владислав Кирилин. VMware - тема доклада в разработке =)
Регистрация
Есть вопросы по мероприятию - пишите: sergey.gorlinsky@gmail.com
Битва за performance CPU
В продолжении заметки о доступных к мониторингу счетчиках хотелось бы уменьшить список счетчиков на которые необходимо в первую очередь обращать внимание при troubleshooting.
- Первое что стоит понимать количество ядер процессора физического сервера будет меньше суммарного количества vCPU виртуальных машин "находящихся" на этом сервере, от этого я возникает ряд специфических для виртуализации проблем с производительностью.
- 1 vCPU = 1 vCore = 1 Core
- Для большинства случаев на серверах стоит включать hyper-threading.
- Включайте поддержку MMU Virtualization (Intel EPT and AMD RVI) - это позволит уменьшить накладные расходы связанные с необходимостью поддержания согласованного представления памяти для нескольких vCPU.
- Выделяйте для виртуальной машины минимальное число vCPU. В случае с vCPU принцип чем больше чем лучше и быстрее - не работает. Выделение неиспользуемых ресурсов ведет к росту накладных расходов и снижению эффективности использования ресурсов. "Лишние" ресурсы выделенные виртуальной машине, не только могут не ускорить ее саму, но и привести к падению производительности виртуальных машин разделяющих с ней одни физические ресурсы. Планировщик гостевой ОС может выполнять миграцию однопоточной нагрузки между vCPU, что также снизит производительность.
- Отключите все неиспользуемые устройсва: COM, LPT порты, USB контроллеры, Floppy, CD, DVD устройства, сетевые карты, дисковые контроллеры. USB контроллеры потребляют ресурсы CPU, PCI - резервируют под себя ресурсы памяти - это общая рекомендация, не относящаяся только к ресурсам CPU.
- Чтобы использовать ресурсы несколько vCPU приложение должно поддерживать работу в многопоточном режиме.
После миграции из физического мира или создания новой виртуальной машины за ней стоит "присмотреть". Конечно если это не типовый сервис, для которого у Вас уже есть собственный бест-практис.
Не стоит полность, без оглядки доверять и выполнять требования (по выделению ресурсов) производителей прикладного ПО. Зачастую эти требования сильно завышены.
Счетчики которые стоит отслеживать для оптимизации производительности или первичного выявления проблем с производительностью. Названия счетчиков приведены в виде представленном в esxtop.
%RDY>10 - виртуальной машине не хватает ресурсов процессора, выстроилась очередь к ресурсам процессора. Вариантов может быть несколько: ресурсов действительно физического процессора действительно не хватает, ресурсов физического сервера хватает, но гипервизор не дает их виртуальной машине (машине надо русурсы 2-х Core, а у нее только 1 vCPU), использование Limit для данной машины. Узнать точную причину такого поведения можно используя другие счетчики:
%CSTP>3 - накладные расходы на многопроцессорную машину. Машина ждет освобождения нескольких vCPU для одновременного исполнения операций. Необходимо уменьшить число vCPU.
%MLMTD>0 - машина уперлась в Limit. Естественно, необходимо убрать ограничения по CPU.
%SWPWT>5 - машина ожидает чтения из файла подкачки. Необходимо увеличить выделенную память.
%VMWAIT - высокие значения этого параметра, говорят о проблемах с производительсностью других ресурсов: нехваткой памяти, медленной работой CXД и т.п.
В общем, все что сможет для обеспечения максимальной производительности сделает CPU Scheduler ESXi, а все остальное в руках администраторов.
В качестве источника использовался Performance Best Practices, настоятельно рекомендованный к вдумчивому прочтению.
- Первое что стоит понимать количество ядер процессора физического сервера будет меньше суммарного количества vCPU виртуальных машин "находящихся" на этом сервере, от этого я возникает ряд специфических для виртуализации проблем с производительностью.
- 1 vCPU = 1 vCore = 1 Core
- Для большинства случаев на серверах стоит включать hyper-threading.
- Включайте поддержку MMU Virtualization (Intel EPT and AMD RVI) - это позволит уменьшить накладные расходы связанные с необходимостью поддержания согласованного представления памяти для нескольких vCPU.
- Выделяйте для виртуальной машины минимальное число vCPU. В случае с vCPU принцип чем больше чем лучше и быстрее - не работает. Выделение неиспользуемых ресурсов ведет к росту накладных расходов и снижению эффективности использования ресурсов. "Лишние" ресурсы выделенные виртуальной машине, не только могут не ускорить ее саму, но и привести к падению производительности виртуальных машин разделяющих с ней одни физические ресурсы. Планировщик гостевой ОС может выполнять миграцию однопоточной нагрузки между vCPU, что также снизит производительность.
- Отключите все неиспользуемые устройсва: COM, LPT порты, USB контроллеры, Floppy, CD, DVD устройства, сетевые карты, дисковые контроллеры. USB контроллеры потребляют ресурсы CPU, PCI - резервируют под себя ресурсы памяти - это общая рекомендация, не относящаяся только к ресурсам CPU.
- Чтобы использовать ресурсы несколько vCPU приложение должно поддерживать работу в многопоточном режиме.
После миграции из физического мира или создания новой виртуальной машины за ней стоит "присмотреть". Конечно если это не типовый сервис, для которого у Вас уже есть собственный бест-практис.
Не стоит полность, без оглядки доверять и выполнять требования (по выделению ресурсов) производителей прикладного ПО. Зачастую эти требования сильно завышены.
Счетчики которые стоит отслеживать для оптимизации производительности или первичного выявления проблем с производительностью. Названия счетчиков приведены в виде представленном в esxtop.
%RDY>10 - виртуальной машине не хватает ресурсов процессора, выстроилась очередь к ресурсам процессора. Вариантов может быть несколько: ресурсов действительно физического процессора действительно не хватает, ресурсов физического сервера хватает, но гипервизор не дает их виртуальной машине (машине надо русурсы 2-х Core, а у нее только 1 vCPU), использование Limit для данной машины. Узнать точную причину такого поведения можно используя другие счетчики:
%CSTP>3 - накладные расходы на многопроцессорную машину. Машина ждет освобождения нескольких vCPU для одновременного исполнения операций. Необходимо уменьшить число vCPU.
%MLMTD>0 - машина уперлась в Limit. Естественно, необходимо убрать ограничения по CPU.
%SWPWT>5 - машина ожидает чтения из файла подкачки. Необходимо увеличить выделенную память.
%VMWAIT - высокие значения этого параметра, говорят о проблемах с производительсностью других ресурсов: нехваткой памяти, медленной работой CXД и т.п.
В общем, все что сможет для обеспечения максимальной производительности сделает CPU Scheduler ESXi, а все остальное в руках администраторов.
В качестве источника использовался Performance Best Practices, настоятельно рекомендованный к вдумчивому прочтению.
audit ESXi config
Одним из требований стандарта PCI DSS является постоянный аудит настроек хоста ESXi.
Аудит, как мера обеспечения безопасности, основан на подробном знании конфигураций сервера и возможности сравнения текущих настроек с эталонными, принятыми как безопасные. Эталонные настройки обычно согласовываются с отделом IT безопасности, если Вам не повезло и у Вас такой отдел есть.
Аудит настроек может быть полезен и администраторам виртуальной платформы в случае траблшутинга или поиска отличий рабочей конфигурации от нерабочей, услужливо предоставленной коллегой.
Как это сделать встроенными средствами ниже и в картинках.
Аудит, как мера обеспечения безопасности, основан на подробном знании конфигураций сервера и возможности сравнения текущих настроек с эталонными, принятыми как безопасные. Эталонные настройки обычно согласовываются с отделом IT безопасности, если Вам не повезло и у Вас такой отдел есть.
Аудит настроек может быть полезен и администраторам виртуальной платформы в случае траблшутинга или поиска отличий рабочей конфигурации от нерабочей, услужливо предоставленной коллегой.
Как это сделать встроенными средствами ниже и в картинках.
vpxuser
Система взаимодействия администратора (пользователя с любыми ролевыми правами) основана на сопоставлении учетной записи Windows, роли имеющей права на определенные объекты инфраструктуры и самих объектов инфраструктуры.
Получая доступ для выполнения действий с ESXi через vCenter администратор не регистрируется непосредственно и не выполняет действий непосредственно на самом хосте ESXi.
На стадии создания задания на vCenter происходит сопоставление роли для учетной записи и объектов инфраструктуры на которые данная роль имеет права.
vCenter взаимодействует с ESXi и виртуальными машинами (опрос хоста, передача задачи) используя учетную запись vpxuser.
Пароль vpxuser состоит из 32 случайно сгенерированных символов. В зашифрованном (SHA1) виде хранится на хосте ESXi и базе данных vCenter. Для каждого хоста управляемого одним vCenter пароль уникален.
Знание пароля от vpxuser Вам ничего не даст, использовать эту комбинацию для подключения к хосту и любых других целей невозможно.
Попытки сменить пароль на учетную запись, применить к ней политики безопасности и т.п. могут привести только к нарушению взаимодействия vCenter и ESXi.
Получая доступ для выполнения действий с ESXi через vCenter администратор не регистрируется непосредственно и не выполняет действий непосредственно на самом хосте ESXi.
На стадии создания задания на vCenter происходит сопоставление роли для учетной записи и объектов инфраструктуры на которые данная роль имеет права.
vCenter взаимодействует с ESXi и виртуальными машинами (опрос хоста, передача задачи) используя учетную запись vpxuser.
Пароль vpxuser состоит из 32 случайно сгенерированных символов. В зашифрованном (SHA1) виде хранится на хосте ESXi и базе данных vCenter. Для каждого хоста управляемого одним vCenter пароль уникален.
Знание пароля от vpxuser Вам ничего не даст, использовать эту комбинацию для подключения к хосту и любых других целей невозможно.
Попытки сменить пароль на учетную запись, применить к ней политики безопасности и т.п. могут привести только к нарушению взаимодействия vCenter и ESXi.
Тип ресурсов, счетчики и объекты.
Доступные счетчики для мониторинга ресурсов остальных объектов иерархии выглядят так:
CPU
Memory
Подписаться на:
Сообщения (Atom)