Первый 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
eLearning
Если раньше на портале обучения VMware были курсы только на одном понятном языке, то теперь на двух:
1. Основы работы с VMware vCenter Operations Manager
2. Виртуализация важных бизнес-приложений [V5.X]
3. Планирование аварийного восстановления и непрерывности бизнеса [V5.X]
Добавление курсов на русском языке будет продолжаться. Весь список приведен здесь.
1. Основы работы с VMware vCenter Operations Manager
2. Виртуализация важных бизнес-приложений [V5.X]
3. Планирование аварийного восстановления и непрерывности бизнеса [V5.X]
Добавление курсов на русском языке будет продолжаться. Весь список приведен здесь.
VMware poster
Обновились некоторые постеры от VMware и опубликовала новые. Качаем, чепятаем и вешаем:
VMware ESXi 5.1 Reference Poster
2 октября. Семинар в Минске.
2 октября 2012 компания Softline проведет в Минске семинар "Новые решения VMware для построения и управления виртуальной ИТ-Инфраструктурой". Будут ребята из VMware и, вероятно, много разговоров о 5.1. В виду полного отсутствия в РБ мероприятий по виртуализации не стоит пренебрегать и этим.
Мероприятие, от "препродажников", но пообщаться на технические темы в кофе паузах думаю удастся.
Мероприятие, от "препродажников", но пообщаться на технические темы в кофе паузах думаю удастся.
VMware toolbar
У VMware есть toolbar для разных там браузеров. Хранится он тут. Выглядит так:
Насколько он полезен, удобен и юзабилен - вопрос очень личный =)
Агрегатор канала VMware на youtube с проверкой обновлений, удобный поиск по базе знаний и документации, твитер, новости, facebook.
Насколько он полезен, удобен и юзабилен - вопрос очень личный =)
Агрегатор канала VMware на youtube с проверкой обновлений, удобный поиск по базе знаний и документации, твитер, новости, facebook.
VMUG Belarus
В начале октября в городе Минске будет проведена первая в РБ встреча VMware User Group. Точная дата и программа будут опубликованы в ближайшее время.
Список докладчиков еще открыт. Так что, если у Вас есть желание + о чем рассказать, будем рады предоставить такую возможность.
VMUG - хорошая возможность поделиться опытом, пообщаться в неформальной обстановке с коллегами, представителями VMware и других профильных компаний.
На VMUG говорят о технологиях, никакого маркетинга, продаж и т.п.
Список докладчиков еще открыт. Так что, если у Вас есть желание + о чем рассказать, будем рады предоставить такую возможность.
VMUG - хорошая возможность поделиться опытом, пообщаться в неформальной обстановке с коллегами, представителями VMware и других профильных компаний.
На VMUG говорят о технологиях, никакого маркетинга, продаж и т.п.
Basic Troubleshooting
У VMware есть неплохая схема по траблшутингу. При возникновении проблем с производительностью VMware рекомендует проверить ряд параметров. Параметры сгруппированы по величине их вклада в производительность, точнее в ухудшение этой самой производительности.
симбиоз Citrix XenApp и VMware vSphere
Про PCI DSS пока перерыв, а пока о том, как я "дружил" Citrix XenApp и VMware vSphere, зачем мне это было надо и что из этого получилось.
Citrix XenApp - решение для доставки приложений Windows, позволяющее осуществлять виртуализацию, централизацию, управление из центра обработки данных и доставку приложений по запросу на любое пользовательское устройство вне зависимости от его местоположения.
Реализуется это все достаточно просто: создается ферма терминальных серверов, на которых "публикуются" приложения для пользователей. На устройствах пользователей устанавливается клиентская часть, которая предоставляет пользователю доступ к приложениям на серверах фермы. Для обеспечения отказоустойчивости и балансировки нагрузки одинаковые каждое приложение публикуется на нескольких серверах. Приложения выполняются на серверах, пользователь получает картинку.
Фермы терминальных серверов Citrix XenApp отлично масштабируется добавлением дополнительных мощностей (серверов) и размазыванием пула пользователей по большему количеству ресурсов, что, естественно, приводит к уменьшению нагрузки на каждый сервер.
В процессе администрирования я столкнулся с рядом "неудобств":
- сервера, ОС имеют свойство ломаться. Как показывает мой опыт администрирования Citrix сервера с XenApp ломаются чаще, чем без него. Конечно, если в вашей ферму полсотни серверов и приложения разнесены по всем бестпрактисам обеспечения отказоустойчивости и производительности - потеря одного сервера не становится глобальной проблемой. Но вот повторное добавление сервера в ферму после ремонта процедура совершенно неинтересная и малопривлекательная, а чтобы восстановиться до исходного состояния все должно быть хорошо задокументировано. Бэкапить физические сервера процедура неудобная, а с учетом динамики изменения настроек серверов Citrix XenApp для поддержания актуального бэкапа - эти неудобства придется терпеть очень часто.
- различные требования публикуемых приложений к CPU и RAM. Казалось бы это не проблема: публикуй на каждом сервере приложение требовательное к CPU и приложение требовательное к RAM и будут задействованы все ресурсы. Все это хорошо "сайзится" на десятке приложений. Когда приложений ставятся сотни + территориальная разнесенность офисов (генерирование специфических нагрузок в разное время суток) + востребованность некоторых приложений в определенные дни месяца - и вот задача эффективного использования доступных ресурсов становится совсем не тривиальной.
- требования безопасников к изоляции приложений на серверах. Зачастую приходится выделять целый сервер под одно приложение + еще один для отказоустойчивости. А приложением может использовать всего пара пользователей...
-требования IT подразделений занимающихся тестированием и отладкой приложений. Обычно, эти ребята тоже хотят под каждое тестируемое приложение отдельный сервер. Это позволяет избежать "воздействия сторонних факторов создаваемых инородными приложениями". А с учетом того, что тестирование это процесс идущий по графику час тестирую, день не тестирую, то неэффективное использование ресурсов увеличивается.
Решить эти неудобства я попытался с помощью приживления Citrix XenApp в инфраструктуру VMware vSphere:
с реализацией все понятно из схемы, а вот про плюсы и минусы стоит поговорить.
Минусы:
- это дорого, точнее дороже чем первый вариант. Citrix XenApp лицензируется конкурентными пользовательскими лицензиями, а вот на лицензии ОС и vSphere придется потратиться. Простая истина о том, что нельзя получить отказоустойчиво, удобно, быстро и "задешева" работает.
- накладные расходы: как может показаться с первого взгляда расход гигагерцев и гигабайтов физических серверов на нужды ESXi и большее количество ОС Windows будем достаточно большим. Но при реализации осознанного подхода к разнесению приложений по серверам потери будут соизмеримы с потерями при "сайзинге" первой схемы.
Плюсы:
-восстановление после аварии. тут все очевидно: о удобстве резервного копирования и восстановления виртуальных машин написано уже достаточно, повторятся нет смысла. Делая бэкапы виртуальных машин с Citrix XenApp каждую ночь мы получаем при востановлении полностью эквивалентные по настройкам сервера, а если посмотреть на бэкап сотни виртуальных серверов с Citrix XenApp сквозь призму дедупликации, то на выходе мы получаем еще и небольшой по размеру бэкап большой инфраструктуры.
- проблема "сайзинга" решена. Выделяйте виртуальным машинам ресурсы согласно потребностям опубликованных на них приложений. Падкое на быстрые гигагерцы приложение публикуйте на виртуальных серверах которым выданы эти гигагерцы, на толстые гигабайты - на серверах с толстыми гигабайтами. А нехватку ресурсов всегда можно мониторить и компенсировать.
- желания и требования любителей схемы одно приложение = один сервер тоже решена.
- траблшутинг ошибок Citrix XenApp исчез как вид. Большинство проблем устраняется восстановлением всей виртуальной машины.
Citrix XenApp - решение для доставки приложений Windows, позволяющее осуществлять виртуализацию, централизацию, управление из центра обработки данных и доставку приложений по запросу на любое пользовательское устройство вне зависимости от его местоположения.
Реализуется это все достаточно просто: создается ферма терминальных серверов, на которых "публикуются" приложения для пользователей. На устройствах пользователей устанавливается клиентская часть, которая предоставляет пользователю доступ к приложениям на серверах фермы. Для обеспечения отказоустойчивости и балансировки нагрузки одинаковые каждое приложение публикуется на нескольких серверах. Приложения выполняются на серверах, пользователь получает картинку.
Фермы терминальных серверов Citrix XenApp отлично масштабируется добавлением дополнительных мощностей (серверов) и размазыванием пула пользователей по большему количеству ресурсов, что, естественно, приводит к уменьшению нагрузки на каждый сервер.
В процессе администрирования я столкнулся с рядом "неудобств":
- сервера, ОС имеют свойство ломаться. Как показывает мой опыт администрирования Citrix сервера с XenApp ломаются чаще, чем без него. Конечно, если в вашей ферму полсотни серверов и приложения разнесены по всем бестпрактисам обеспечения отказоустойчивости и производительности - потеря одного сервера не становится глобальной проблемой. Но вот повторное добавление сервера в ферму после ремонта процедура совершенно неинтересная и малопривлекательная, а чтобы восстановиться до исходного состояния все должно быть хорошо задокументировано. Бэкапить физические сервера процедура неудобная, а с учетом динамики изменения настроек серверов Citrix XenApp для поддержания актуального бэкапа - эти неудобства придется терпеть очень часто.
- различные требования публикуемых приложений к CPU и RAM. Казалось бы это не проблема: публикуй на каждом сервере приложение требовательное к CPU и приложение требовательное к RAM и будут задействованы все ресурсы. Все это хорошо "сайзится" на десятке приложений. Когда приложений ставятся сотни + территориальная разнесенность офисов (генерирование специфических нагрузок в разное время суток) + востребованность некоторых приложений в определенные дни месяца - и вот задача эффективного использования доступных ресурсов становится совсем не тривиальной.
- требования безопасников к изоляции приложений на серверах. Зачастую приходится выделять целый сервер под одно приложение + еще один для отказоустойчивости. А приложением может использовать всего пара пользователей...
-требования IT подразделений занимающихся тестированием и отладкой приложений. Обычно, эти ребята тоже хотят под каждое тестируемое приложение отдельный сервер. Это позволяет избежать "воздействия сторонних факторов создаваемых инородными приложениями". А с учетом того, что тестирование это процесс идущий по графику час тестирую, день не тестирую, то неэффективное использование ресурсов увеличивается.
Решить эти неудобства я попытался с помощью приживления Citrix XenApp в инфраструктуру VMware vSphere:
с реализацией все понятно из схемы, а вот про плюсы и минусы стоит поговорить.
Минусы:
- это дорого, точнее дороже чем первый вариант. Citrix XenApp лицензируется конкурентными пользовательскими лицензиями, а вот на лицензии ОС и vSphere придется потратиться. Простая истина о том, что нельзя получить отказоустойчиво, удобно, быстро и "задешева" работает.
- накладные расходы: как может показаться с первого взгляда расход гигагерцев и гигабайтов физических серверов на нужды ESXi и большее количество ОС Windows будем достаточно большим. Но при реализации осознанного подхода к разнесению приложений по серверам потери будут соизмеримы с потерями при "сайзинге" первой схемы.
Плюсы:
-восстановление после аварии. тут все очевидно: о удобстве резервного копирования и восстановления виртуальных машин написано уже достаточно, повторятся нет смысла. Делая бэкапы виртуальных машин с Citrix XenApp каждую ночь мы получаем при востановлении полностью эквивалентные по настройкам сервера, а если посмотреть на бэкап сотни виртуальных серверов с Citrix XenApp сквозь призму дедупликации, то на выходе мы получаем еще и небольшой по размеру бэкап большой инфраструктуры.
- проблема "сайзинга" решена. Выделяйте виртуальным машинам ресурсы согласно потребностям опубликованных на них приложений. Падкое на быстрые гигагерцы приложение публикуйте на виртуальных серверах которым выданы эти гигагерцы, на толстые гигабайты - на серверах с толстыми гигабайтами. А нехватку ресурсов всегда можно мониторить и компенсировать.
- желания и требования любителей схемы одно приложение = один сервер тоже решена.
- траблшутинг ошибок Citrix XenApp исчез как вид. Большинство проблем устраняется восстановлением всей виртуальной машины.
PCI DSS vs VMware part 4-2
- Запрет контроля устройств ESXi-сервера со стороны виртуальных машин. В общем, чтобы пользователи не отсоединяли\присоединяли CD-ROM, сетевые адаптеры и не меняли их параметры (включить\выключить) это надо запретить. Запрещается на уровне vm. Т.к. в моей тестовой инфраструктуре только две vm, буду делать вручную, не заморачиваясь на автоматизации. Можно править вручную *.vmx, а можно через vSphere Client:
- Предотвращение шпионажа других пользователей на администраторских удаленных консолях. По сути, защита от "подглядывания", технически - ограничение подключений удаленной консоли. Идем проверенным в предыдущем пункте способом:
- Настройка безопасности для виртуальных коммутаторов. К сожалению, полноценно выполнить все требования данного пункта в моей тестовой среде я не могу. Флаг "Соответствует" я не получу :(. А суть требования заключается в:
- изоляции трафика: управления, vMotion, IP трафика файловых хранилищ.
- контроль за доступом к сети управления.
- запрет смешанного режима работы для виртуального коммутатора.
- запрет на смену MAC адресов.
- запрет существования неиспользуемых портов в группах портов виртуальных коммутаторов
- запрет на установку у групп портов значений VLAN в native VLAN.
- запрет на использование 4095 VLAN
- запрет на использование в виртуальном коммутаторе VLAN зарезервированных физическими коммутаторами
- Документирование всех VLAN и их назначения и т.п..
Большая часть этих параметров описана в бестпрактисах по настройка сети в виртуальной инфраструктуре и предварительно учитываются при построении "идейно правильных" архитектур.
- Отключение Direct Conlole User Interface. Выполнить это требование не сложно, но стоит ли ? Может пора прибегнуть к пункту "оценить риски и выработать компенсационные меры" в виде строго контроля за доступом к группе "localadmin", члены которой могут получать доступ к DCUI. А отключение делается так:
>chkconfig DCUI off
- Запрет подключения съемных устройств на ESXi-сервере. Этот пункт обсуждался, когда разговор шел про USB. Делаем так:
floppyX.present = "false"
serialX.present = "false"
parallelX.present = "false"
usb.present = "false"
ideX:Y.present = "false"
- Отключение Tech Support Mode. Насколько я понимаю в ESXi 5 это равносильно отключению ESXi Shell (эта KB как бы намекает на это). Поэтому просто останавливаем ESXi Shell:
- Запрет операций с буфером обмена. Действуем по старой схеме:
isolations.tools.copy.disable = "TRUE"
isolation.tools.paste.disable = "TRUE"
isolation.tools.dnd.disable= "TRUE"
isolation.tools.setGUIOptions.enable= "FALSE"
- Установка и поддержка целостности файловой системы. Честно говоря я не придумал доступного решения этой задачи без кастомизации ESXi. Буду просто проверять SHA1 суммы перед установкой ESXi и обновлений.
- Синхронизация времени. Настраиваем синхронизацию с DC или какой-нибудь Cisco, где поднят NTP сервер.
Я попробовал выполнить все требования для "Соответствия" PCI DSS описанные в vGate Compliance Checker. В следующий раз рассмотрим чем соответствие PCI DSS у vGate Compliance Checker отличается от требований VMware Compliance Checker for vSphere.
- Предотвращение шпионажа других пользователей на администраторских удаленных консолях. По сути, защита от "подглядывания", технически - ограничение подключений удаленной консоли. Идем проверенным в предыдущем пункте способом:
- Настройка безопасности для виртуальных коммутаторов. К сожалению, полноценно выполнить все требования данного пункта в моей тестовой среде я не могу. Флаг "Соответствует" я не получу :(. А суть требования заключается в:
- изоляции трафика: управления, vMotion, IP трафика файловых хранилищ.
- контроль за доступом к сети управления.
- запрет смешанного режима работы для виртуального коммутатора.
- запрет на смену MAC адресов.
- запрет существования неиспользуемых портов в группах портов виртуальных коммутаторов
- запрет на установку у групп портов значений VLAN в native VLAN.
- запрет на использование 4095 VLAN
- запрет на использование в виртуальном коммутаторе VLAN зарезервированных физическими коммутаторами
- Документирование всех VLAN и их назначения и т.п..
Большая часть этих параметров описана в бестпрактисах по настройка сети в виртуальной инфраструктуре и предварительно учитываются при построении "идейно правильных" архитектур.
- Отключение Direct Conlole User Interface. Выполнить это требование не сложно, но стоит ли ? Может пора прибегнуть к пункту "оценить риски и выработать компенсационные меры" в виде строго контроля за доступом к группе "localadmin", члены которой могут получать доступ к DCUI. А отключение делается так:
>chkconfig DCUI off
- Запрет подключения съемных устройств на ESXi-сервере. Этот пункт обсуждался, когда разговор шел про USB. Делаем так:
floppyX.present = "false"
serialX.present = "false"
parallelX.present = "false"
usb.present = "false"
ideX:Y.present = "false"
- Отключение Tech Support Mode. Насколько я понимаю в ESXi 5 это равносильно отключению ESXi Shell (эта KB как бы намекает на это). Поэтому просто останавливаем ESXi Shell:
- Запрет операций с буфером обмена. Действуем по старой схеме:
isolations.tools.copy.disable = "TRUE"
isolation.tools.paste.disable = "TRUE"
isolation.tools.dnd.disable= "TRUE"
isolation.tools.setGUIOptions.enable= "FALSE"
- Установка и поддержка целостности файловой системы. Честно говоря я не придумал доступного решения этой задачи без кастомизации ESXi. Буду просто проверять SHA1 суммы перед установкой ESXi и обновлений.
- Синхронизация времени. Настраиваем синхронизацию с DC или какой-нибудь Cisco, где поднят NTP сервер.
Я попробовал выполнить все требования для "Соответствия" PCI DSS описанные в vGate Compliance Checker. В следующий раз рассмотрим чем соответствие PCI DSS у vGate Compliance Checker отличается от требований VMware Compliance Checker for vSphere.
PCI DSS vs VMware part 4
Ниже я опишу как получить "чистый" скан в vGate Compliance Checker и VMware Compliance Checker for vSphere для инфраструктуры установленной по принципу next->next->next. Не совсем типичный случай, но наиболее полно отражающий несоответствие стандарту PCI DSS.
Исследуемая инфраструктура: ESXi 5.0.0, vCenter server установлен вместе с MS SQL Server 2k8 R2 на MS Windows 2k3 st. R2 x64. Предварительно настроена только доменная авторизация.
Результат скана vGate Compliance Checker:
Добавляем сервер ESXi, вводим имя учетной записи, пароль, запускаем скан:
| ||||||||
| ||||||||
|
| ||
Результаты политик для VMware 4.1 и CIS for ESX 4 нам пока не интересны.
PCI DSS наш сервер, естественно не соответствует. Для устранения уязвимостей буду использовать ESXi Shell (предварительно придется в services запустить ESXi Shell и SSH server) и PowerCLI.
- Запрет использования Managed Object Browser. Устранение этой уязвимости оставим напоследок, после ее устранения vGate Compliance Checker "ломается" (перестает получать данные от ESXi хоста)
>vim-cmd proxysvc/remove_service "/mob" "httpsWithRedirect"
- Настройка логирования виртуальных машин на ESXi сервере.
Я внес изменения в каждый *.vmx
logging = "true"
log.rotateSize = "100000"
log.keepOld = "10"
с первыми тремя параметрами все понятно, ограничения для "исключения возможности отказа в обслуживании при переполнении хранилища данных".
log.fileName = "/vmfs/volumes/datalog01/logvm/vmname.log"
этот параметр связан с моим личным "загоном": хранить, даже ограниченные, логи на продакшин системе считаю не совсем верным. Поэтому по мне так проще и удобнее при дальнейшем анализе и траблшутинге использовать отдельный datastore для хранения логов.
- Отсылка событий сервера виртуализации на syslog-сервер. Тут все совсем просто: перенаправляете логи ESXi на VMware Syslog Collector или любой другой централизованный сервер сбора логов, используемый в Вашей инфраструктуре.
- Запрет подключения USB-носителей к ESX/ESXi-серверу. Требование совершенно непонятно. Очень часто сервера используют всякие Token и прочие key. Вероятно авторы требования считают что ключи будут использоваться с помощью всяких USB over TCP/IP подключаясь через Cisco ASA.
Я трактую этот пункт как: исключите возможность подключения различных не авторизованных устройств: USB, CD-ROM, floppy. Например:
floppy.present = "false"
Для остальных проводите проверку и инвентаризацию с помощью PowerCLI:
Get-VM | Get-USBDevice
Если такой вариант не устраивает, то отключите USB в BIOS, на BIOS поставьте пароль, состоящий из двух частей записанных на четыре листика, спрятанных в сейфы.
По остальным пунктам продолжу в следующей части.
Подписаться на:
Сообщения (Atom)