Давно собирался написать этот пост, но что-то руки не доходили. Вот, взял себя за шкирку и пишу :) Правда, по хорошему его надо писать слегка по другому - не только в теории (как я это делаю сейчас), но и практики добавить - но время, время... Напишу как есть, а будет время попрактикуюсь и еще напишу. Итак - вСфера и безопасность. Благодаря хозяйке virtualizationsecuritygroup.ru я узнал, что существует довольно много решений, содержащих в своем описании "VMware vSphere" и "Security" одновременно. они в чем-то сильно похожи, но и нюансов хватает. ну и узнал немного подробностей про некоторые из них. Введение Для начала частично процитирую один из своих старых постов. Есть вот такая картинка: Семейство продуктов vShield Это - продукты и функции VMware vSphere, имеющие отношение к безопасности. Интерфейс vShield Manager, управлялки ко всему остальному Во-первых - есть продукт vShield Zones. Это - межсетевой экран, позволяющий контролировать обмен трафиком, притом даже...

[content]

В свете обновления на пятерку интересные подробности про обновление VMFS. ESX(i) 4 использует VMFS версии 3. ESXi 5 использует VMFS версии 5, но VMFS версии 3 тоже поддерживает. Возможен апгрейд раздела VMFS 3 -> VMFS 5, притом даже без прерывания работы ВМ, располагающихся на нем(!) Получается, у нас есть три возможности: 1) Оставить разделы VMFS 3 как есть - ESXi 5 спокойно продолжит с ними работать. 2) Обновить VMFS 3 -> VMFS 5. 3) Пересоздать VMFS 5 с нуля. Забегая вперед - третий вариант самый правильный, хотя в какой-то инфраструктуре разница не будет заметна. Вариант 1 не позволит пользоваться плюшками нового VMFS. Это LUN до 64 ТБ, это новые возможности VAAI, это pRDM до 64 ТБ. В принципе, вполне можно допустить что в конкретном случае это нам не нужно. Вариант 2 хуже варианта 3 по одной причине: раздел, обновленный до VMFS 5 отличается от раздела где VMFS 5 создана с нуля. Отличия  - в размере блока. Обновленный раздел унаследует блок в 1, 2,...

[content]

Компания ActiveState хорошо известна разработчикам. Они довольно активно продвигают свои сборки Perl (ActivePerl), Python (ActivePython), Tcl (ActiveTcl) (Раньше был еще ActivePHP, но сейчас его нет). У них есть отличный Komodo IDE и его урезанная бесплатная версия Komodo Edit. И недавно компания предприняла шаги к входу на рынок модных сейчас облачных технологии, но не со стороны создания своих облачных сервисов, а со стороны создания своей софтверной платформы. [Честно говоря, не совсем своей, но об этом далее :-)] Так появилась Stackato — «первая облачная платформа для создания private PaaS с поддержкой Python, Perl, Ruby, Node.js и Java».
Если интересно как создать свое «облачное» Perl приложение, прошу под кат.

Эта статья по логике должна была появиться первой, перед статьей про Transparent Page Sharing, так как это база, с которой должно начинаться погружение в управление ресурсами памяти в vSphere 4.1.

В моем англоязычном блоге, когда я только начинал изучать эту тему, я разбил ее на две части — мне самому было так легче воспринимать совершенно новую для меня информацию. Но так как публика на хабре серьезная и бывалая, то я решил объединить материал в одну статью.

Начнем мы с самого основного элемента, который называется Memory Page. Ему дается следующее определение — непрерывный блок данных фиксированного размера, используемый для распределения памяти. Как правило размер страницы может быть 4 Кбайта (Small Page) или 2 Мбайта (Large Page). Каждому приложению ОС выделяет 2 Гбайта виртуальной памяти, которая принадлежит только этому приложению. Чтобы ОС могла знать какой странице физической памяти (Physical Address — PA) соответствует определенная страница виртуальной памяти (Virtual Address — VA) ОС ведет учет всех страниц памяти с помощью Page Table. Именно там хранятся все соответствия между VA и PA.

Случайным образом пару недель назад я наткнулся на прошлогоднюю статью товарища System32 про Transparent Page Sharing, что собственно и подтолкнуло меня нарушить свой график подготовки к VCAP-DCA и совершить глубокое погружение в совершенно незнакомую для меня доселе технологию управления памяти в vSphere, а если быть более точным — в TPS. Коллега System32 очень толково изложил общие принципы работы с памятью, алгоритм работы TPS, но при этом сделал не совсем верные выводы. Еще больше меня раззадорили вопросы в комментариях, на которые никто не ответил, касательно высоких значений SHRD памяти в esxtop, при том, что согласно этой же статье при использовании Large Pages технология TPS попросту не будет работать. Вообщем обнаружились серьезные противоречия между красивой теорией и практикой.

После 4-5 дней копания в форумах Vmware, чтения Вики, западных блогеров, у меня кое что отложилось в голове и я смог наконец то ответить на вопросы из комментариев. Чтобы как-то упорядочить свежие знания я решил написать несколько статей на эту тему в своем англоязычном блоге. Я также пошерстил Хабр на предмет новых статей на эту тему, но к моему удивлению с 2010 года ничего нового не обнаружил. Поэтому и решил ради постоянно читаемого Хабра и возможности активно участвовать в комментариях перевести свою же статью про Transparent Page Sharing и нюансы его использования на системах с процессорами семейства Nehalem/Opteron и с установленной ESX(i) 4.1.