| Thick | ZeroedThick | EagerZeroedThick | Thin | |
| Время создания | Быстро | Как Thick | Очень медленно, время прямо пропорционально размеру | Очень быстро |
| Выделение блоков | Полностью при создании | Как Thick | Как Thick | Выделение при запросе к блоку виртуального диска, нулевой размер при создании |
| Расположение блоков | В связи с полным выделением блоков при создании, вероятнее всего блоки будут располагаться последовательно | Как Thick | Как Thick | Блок выделяется при обращении, поэтому расположение блоков может быть любым |
| Очистка выделенных блоков | Нет | Блоки очищаются при первом обращении | Блоки очищаются при создании диска | Блоки очищаются при выделении |
| Скорость | Максимальная всегда | Вначале сниженная ввиду очистки блоков при первом обращении | Как Thick | Снижена чуть больше, чем у ZeroedThick ввиду выделения и очистки блоков при первом обращении |
| Безопасность | Небезопасен, ВМ может получить доступ к данным, располагавшимся ранее на месте диска | Безопасен | Безопасен | Безопасен |
вторник, 27 октября 2009 г.
Сводная таблица по виртуальным дискам VMware
понедельник, 26 октября 2009 г.
Использование non-persistent дисков
Проблемы безопасности, связанные с использованием непостоянных (non-persistent) дисков, заключаются в том, что злоумышленник может откатить выполненные действия или скрыть следы своего присутствия простым выключением машины. При этом уязвимость обнаруженная злоумышленником в виртуальной машине останется и может быть использована повторно в произвольный момент времени по его усмотрению. Угроза же заключается в том, что администратор может и не узнать, что машина попала под контроль злоумышленника.
Использование виртуальных машин с этим типом дисков может привести к затруднению проведения расследований инцидентов в следующих случаях:
1. Ошибочные или некомпетентные действия пользователя в процессе эксплуатации виртуальной машины (не носящие злого умысла).
2. Проникновение на виртуальную машину вредоносного кода, не детектируемого средствами антивирусной защиты вследствие его новизны или заказного характера, с последующим выполнением вредоносной активности.
3. Умышленные злонамеренные действия пользователей, возможно, не обладающих достаточным уровнем для уничтожения всех следов своей деятельности в случае использования обычных дисков (persistent, по умолчанию).
Во всех случаях реализации угрозы после выключения виртуальной машины, использующей диски без сохранения состояния, признаки и следы вредоносного воздействия на саму виртуальную машину и/или информационную среду, на которую осуществлялись атаки с этой машины (за исключением аномалий, обнаруженных сетевыми и хостовыми IPS), будут безвозвратно уничтожены, что затруднит анализ событий и предотвращение их повторения в будущем.
Поэтому рекомендуется полный отказ от использования непостоянных дисков, или использование их только в тестовых средах или средах разработки (эта мера так же рекомендована вендором - стр 6. VMware Security Hardening).
Использование виртуальных машин с этим типом дисков может привести к затруднению проведения расследований инцидентов в следующих случаях:
1. Ошибочные или некомпетентные действия пользователя в процессе эксплуатации виртуальной машины (не носящие злого умысла).
2. Проникновение на виртуальную машину вредоносного кода, не детектируемого средствами антивирусной защиты вследствие его новизны или заказного характера, с последующим выполнением вредоносной активности.
3. Умышленные злонамеренные действия пользователей, возможно, не обладающих достаточным уровнем для уничтожения всех следов своей деятельности в случае использования обычных дисков (persistent, по умолчанию).
Во всех случаях реализации угрозы после выключения виртуальной машины, использующей диски без сохранения состояния, признаки и следы вредоносного воздействия на саму виртуальную машину и/или информационную среду, на которую осуществлялись атаки с этой машины (за исключением аномалий, обнаруженных сетевыми и хостовыми IPS), будут безвозвратно уничтожены, что затруднит анализ событий и предотвращение их повторения в будущем.
Поэтому рекомендуется полный отказ от использования непостоянных дисков, или использование их только в тестовых средах или средах разработки (эта мера так же рекомендована вендором - стр 6. VMware Security Hardening).
пятница, 16 октября 2009 г.
HA Deepdive: Slots
Многие, пожалуй, встречались с ситуацией, когда в HA-кластере ресурсов на первый взгляд предостаточно, а HA ругается на нехватку ресурсов.
Это происходит по причине того, что у HA своя собственная арифметика, основанная на слотах.
Что такое слот? Слот - это место под условную машину, и возможное количество ВМ в кластере определяется количеством слотов под них. HA берет самый большой резерв по процессорам и памяти в кластере и устанавливает в качестве размера слота (память + overhead). Если нет резервов, то процессорная мощность в слоте устанавливается в 256 MHz, а память в слоте считается по размеру наибольшего overhead.
Как определяется колчиство слотов на хосте? Делением. При этом, если количество процессорных слотов получается 25, но только 5 слотов по памяти, то считается, что слотов на хосте 5. А далее слоты всех хостов просто суммируются - в итоге мы имеем емкость HA кластера.
Что в этом случае происходит с несбалансированными кластерами? Несбалансированным кластером, например, является кластер из 5 хостов, в котором на 4х хостах по 16ГБ памяти, а на 5м - 32.
Одна из ВМ сконфигурирована с 4 vCPU / 4 GB, и поскольку резервов нет, то слоты памяти рассчитываются по оверхеду данной машины - 325 MB.
Что в итоге дает по 50 слотов для esx01 - esx04, и 100 для esx05. При включенном Admission Control берется худший сценарий и рассчитывается все на случай падения самых мощных хостов. Т.е. при установленном "Host failures cluster tolerates: 1" мы получаем 200 слотов в кластере. В случае 5и хостов по 16ГБ результат был бы тот же самый - "5*50 - 1*50 = 200".
Если включаете Admission Control, то балансируйте ваши кластеры.
Есть в расширенных настройках такие параметры как das.slotCpuInMHz и das.slotMemInMB для принудительной установки размера слота. Эти параметры могут очень помочь, если у нескольких ВМ в кластере высокие значения резервов, однако здесь тоже есть свои нюансы.
Размер слота памяти установлен в 1024 MB, а VM24 имеет резерв в 4 GB. Как можно заметить, ни у одного из хостов нет 4х свободных слотов, и хотя по сумме слотов требования HA выполняются, есть вероятность, что HA не сможет рестартовать VM24.
Оригинал - Duncan Epping
Это происходит по причине того, что у HA своя собственная арифметика, основанная на слотах.
Что такое слот? Слот - это место под условную машину, и возможное количество ВМ в кластере определяется количеством слотов под них. HA берет самый большой резерв по процессорам и памяти в кластере и устанавливает в качестве размера слота (память + overhead). Если нет резервов, то процессорная мощность в слоте устанавливается в 256 MHz, а память в слоте считается по размеру наибольшего overhead.
Как определяется колчиство слотов на хосте? Делением. При этом, если количество процессорных слотов получается 25, но только 5 слотов по памяти, то считается, что слотов на хосте 5. А далее слоты всех хостов просто суммируются - в итоге мы имеем емкость HA кластера.
Что в этом случае происходит с несбалансированными кластерами? Несбалансированным кластером, например, является кластер из 5 хостов, в котором на 4х хостах по 16ГБ памяти, а на 5м - 32.
Одна из ВМ сконфигурирована с 4 vCPU / 4 GB, и поскольку резервов нет, то слоты памяти рассчитываются по оверхеду данной машины - 325 MB.
Что в итоге дает по 50 слотов для esx01 - esx04, и 100 для esx05. При включенном Admission Control берется худший сценарий и рассчитывается все на случай падения самых мощных хостов. Т.е. при установленном "Host failures cluster tolerates: 1" мы получаем 200 слотов в кластере. В случае 5и хостов по 16ГБ результат был бы тот же самый - "5*50 - 1*50 = 200".
Если включаете Admission Control, то балансируйте ваши кластеры.
Есть в расширенных настройках такие параметры как das.slotCpuInMHz и das.slotMemInMB для принудительной установки размера слота. Эти параметры могут очень помочь, если у нескольких ВМ в кластере высокие значения резервов, однако здесь тоже есть свои нюансы.
Размер слота памяти установлен в 1024 MB, а VM24 имеет резерв в 4 GB. Как можно заметить, ни у одного из хостов нет 4х свободных слотов, и хотя по сумме слотов требования HA выполняются, есть вероятность, что HA не сможет рестартовать VM24.
Оригинал - Duncan Epping
вторник, 13 октября 2009 г.
Обзор докладов на встрече VMUG - осень 2009
Михаил Михеев выложил у себя презентации и обзор докладов, прозвучавших на встрече.
Дмитрий Блейзер, Veeam, рассказал о грядущем Veeam Backup 4.0
Дмитрий Филимонов и Константин Введенский из Starwind Software представили программный iSCSI Target собственной разработки
Сергей Щадных поделился опытом внедрения виртуализации в крупной компании с большим количеством филиалов
Денис Батурин подробно объяснил, что же такое и как работает распределенный коммутатор, и в частности зачем нужен Cisco Nexus 1000v
Мария Сидорова раскрывала вопросы информационной безопасности виртуальной инфраструктуры
Константин Пичугов, "Код Безопасности", представил продукт, который вам наверняка потребуется, если собираетесь обрабатывать в виртуальных машинах персональные данные
Дмитрий Блейзер, Veeam, рассказал о грядущем Veeam Backup 4.0
Дмитрий Филимонов и Константин Введенский из Starwind Software представили программный iSCSI Target собственной разработки
Сергей Щадных поделился опытом внедрения виртуализации в крупной компании с большим количеством филиалов
Денис Батурин подробно объяснил, что же такое и как работает распределенный коммутатор, и в частности зачем нужен Cisco Nexus 1000v
Мария Сидорова раскрывала вопросы информационной безопасности виртуальной инфраструктуры
Константин Пичугов, "Код Безопасности", представил продукт, который вам наверняка потребуется, если собираетесь обрабатывать в виртуальных машинах персональные данные
понедельник, 12 октября 2009 г.
VMware vs Microsoft: Desktop virtualization
Сегодня, наконец, переехал на новую рабочую машинку, водрузив туда Windows 7. И, разумеется, озаботился сразу проблемой совместимости vSphere клиента и Windows 7.
Решений очевидных было два: терминальный доступ или локальный.
VDI доступ отмел как неизящный, тем более, что моя вторая рабочая машина, виртуальная, тоже под Windows 7, а плодить десяток не хотелось. Поднял Windows 2008 с RemoteApp и опубликовал vSphere Client. Работает, да... Но как-то отвратно, слишком медленный отклик - тяжеловат vSphere Client для такого.
Итак? Desktop.
Первая попытка была с использованием XP Mode RC - и тут же нещадно обломалась. Поставил Windows Virtual PC RC, XP Mode RC и получил сообщение, что мой процессор, E2160 не поддерживает аппаратную виртуализацию. Проверил на сайте Intel - действительно, не поддерживает. Напомню, что XP Mode - это, по сути, виртуальная машина с XP и бесшовной интеграцией в ОС, так что приложения XP выглядят приложениями Windows 7.
Убил XP Mode из системы, поставил VMware Workstation 7 RC, в нее XP Pro, в нее кучу разных .Net и vSphere Client. Переключил в режим Unity, и ... Заработало!!!
Время отклика однозначно меньше варианта с терминальным доступом, но дает 600-700 MB нагрузки на машину, в отличие от терминала. Хуже, чем в нативном режиме, конечно, но вполне можно потерпеть месяцок-другой, пока VMware не сделает vSphere клиента совместимым с Windows 7.
Жив еще binary translation, курилка!
Да, почему все-таки VMware vs Microsoft - на мой взгляд, Microsoft поторопилась отказываться от binary translation в пользу аппаратной виртуализации с XP Mode, разом потеряв часть "переходных" систем - на базе весьма производительных двухядерных 64битных процессоров, но без VT, а также большинство ноутбуков. Это теперь клиенты VMware. Снизила бы только VMware цены на Workstation...
Решений очевидных было два: терминальный доступ или локальный.
VDI доступ отмел как неизящный, тем более, что моя вторая рабочая машина, виртуальная, тоже под Windows 7, а плодить десяток не хотелось. Поднял Windows 2008 с RemoteApp и опубликовал vSphere Client. Работает, да... Но как-то отвратно, слишком медленный отклик - тяжеловат vSphere Client для такого.
Итак? Desktop.
Первая попытка была с использованием XP Mode RC - и тут же нещадно обломалась. Поставил Windows Virtual PC RC, XP Mode RC и получил сообщение, что мой процессор, E2160 не поддерживает аппаратную виртуализацию. Проверил на сайте Intel - действительно, не поддерживает. Напомню, что XP Mode - это, по сути, виртуальная машина с XP и бесшовной интеграцией в ОС, так что приложения XP выглядят приложениями Windows 7.
Убил XP Mode из системы, поставил VMware Workstation 7 RC, в нее XP Pro, в нее кучу разных .Net и vSphere Client. Переключил в режим Unity, и ... Заработало!!!
Время отклика однозначно меньше варианта с терминальным доступом, но дает 600-700 MB нагрузки на машину, в отличие от терминала. Хуже, чем в нативном режиме, конечно, но вполне можно потерпеть месяцок-другой, пока VMware не сделает vSphere клиента совместимым с Windows 7.
Жив еще binary translation, курилка!
Да, почему все-таки VMware vs Microsoft - на мой взгляд, Microsoft поторопилась отказываться от binary translation в пользу аппаратной виртуализации с XP Mode, разом потеряв часть "переходных" систем - на базе весьма производительных двухядерных 64битных процессоров, но без VT, а также большинство ноутбуков. Это теперь клиенты VMware. Снизила бы только VMware цены на Workstation...
HA Deepdive: Primary nodes
HA кластер состоит из максимум 32 узлов, которые в свою очередь подразделяются на Primary и Secondary. Primary узлы являются "управляющими" и держат у себя информацию о конфигурации и состоянии кластера, синхронизируя между собой.
Primary узлы посылают хартбиты (heartbeat) только Primary узлам, Secondary узлы посылают хартбиты тоже только Primary узлам. По умолчанию 1 хартбит в секунду, но это конфигурируемый параметр: das.failuredetectioninterval.
Первые 5 узлов, включенные в HA кластер автоматически становятся Primary, а все остальные Secondary. Но если производится действие "Reconfigure for HA", то узлы назначаются Primary и Secondary случайным образом. vSphere клиент не показывает, является ли выбранный узел Primary или Secondary, есть только одна возможность это увидеть - из сервис-консоли:
Распространена ошибка, что при падении Primary узла происходят перевыборы. Не в этом случае. Перевыборы Primary (выдвижение Secondary узла на Primary роль) происходят только при введении Primary узла в Maintenance Mode, отключении от кластера (disconnect) или удалении из кластера.
Если же все 5 Primary узлов упали одновременно, то рестарта виртуальных машин не произойдет, HA требует наличия хотя бы одного Primary узла для работы. Именно поэтому максимум 4 хоста могут выйти из строя в HA кластере.
Это правило, примененное к блейд-серверам, модифицируется следующим образом: разделяйте блейды из одного кластера по разным корзинам и не включайте в HA-кластер более 4х блейдов из одной корзины.
Один из Primary узлом получает роль Fail-over coordinator или Active Primary. Именно он управляет рестартом виртуальных машин при выходе узлов из строя. Если падает Active Primary, то эту роль берет на себя один из оставшихся Primary узлов.
Оригинал - Duncan Epping.
Primary узлы посылают хартбиты (heartbeat) только Primary узлам, Secondary узлы посылают хартбиты тоже только Primary узлам. По умолчанию 1 хартбит в секунду, но это конфигурируемый параметр: das.failuredetectioninterval.
Первые 5 узлов, включенные в HA кластер автоматически становятся Primary, а все остальные Secondary. Но если производится действие "Reconfigure for HA", то узлы назначаются Primary и Secondary случайным образом. vSphere клиент не показывает, является ли выбранный узел Primary или Secondary, есть только одна возможность это увидеть - из сервис-консоли:
cat /var/log/vmware/aam/aam_config_util_listnodes.log
или
/opt/vmware/aam/bin/Cli (ftcli on earlier versions)
AAM> ln
Распространена ошибка, что при падении Primary узла происходят перевыборы. Не в этом случае. Перевыборы Primary (выдвижение Secondary узла на Primary роль) происходят только при введении Primary узла в Maintenance Mode, отключении от кластера (disconnect) или удалении из кластера.
Если же все 5 Primary узлов упали одновременно, то рестарта виртуальных машин не произойдет, HA требует наличия хотя бы одного Primary узла для работы. Именно поэтому максимум 4 хоста могут выйти из строя в HA кластере.
Это правило, примененное к блейд-серверам, модифицируется следующим образом: разделяйте блейды из одного кластера по разным корзинам и не включайте в HA-кластер более 4х блейдов из одной корзины.
Один из Primary узлом получает роль Fail-over coordinator или Active Primary. Именно он управляет рестартом виртуальных машин при выходе узлов из строя. Если падает Active Primary, то эту роль берет на себя один из оставшихся Primary узлов.
Оригинал - Duncan Epping.
понедельник, 5 октября 2009 г.
VMware View Open Client 4.0.0 beta1
Буквально только что был опубликован VMware View Open Client 4.0.0 beta1
Что умеет этот клиент:
* Ability to create a secure tunnel using SSL
* Support for two factor authentication with RSA SecurID
* Novell SLETC Add-On RPM package
* Full command line interface
Ну и что он пока НЕ умеет:
* USB redirection
* Multiple desktop sessions
* Multimedia redirection
Как вы уже, наверное, догадались, это клиент View для Linux
Что умеет этот клиент:
* Ability to create a secure tunnel using SSL
* Support for two factor authentication with RSA SecurID
* Novell SLETC Add-On RPM package
* Full command line interface
Ну и что он пока НЕ умеет:
* USB redirection
* Multiple desktop sessions
* Multimedia redirection
Как вы уже, наверное, догадались, это клиент View для Linux
Подписаться на:
Сообщения (Atom)
Сообщения
