Аллилуйя! Огромнейший поток жалоб на новую модель лицензирования был услышан в компании VMware. Хотя стоит поправиться — клиенты VMware были возмущены не столько самой новой моделью лицензирования, сколько теми низкими объемами разрешенного vRAM на одну лицензию. В принципе подобное подозрение возникло почти сразу после релиза vSphere 5. Я знаю, что буквально через пару дней после того как в VMware поняли, что просчитались, они начали масштабный опрос клиентов по соотношению физической памяти на хостах, количества виртуальных машин и назначенной им vRAM. На сегодня это как бы слухи, но уже подтвержденные из авторитетных источников и я им лично доверяю. Итак, что у нас уже известно:

Сегодня мне хотелось бы немного отвлечься от vSphere 5 лихорадки и вспомнить основы стандартного vSwitch-а, а в частности каким образом он обходится без Spanning Tree Protocol.

Я предполагаю, что вы уже обладаете простейшими знаниями коммутации и знаете что такое vlan, switching loop, spanning tree протокол и некоторые виды link aggregation протоколов. Я постараюсь кратко пробежаться по основным возможностям стандартного vSwitch-а, делая акцент на фактах, которые показались мне интересными или же которые были не очень очевидны в официальной документации, по крайней мере для меня. Отсюда же вытекает и некоторая сумбурность нижеизложенного.

Основная цель стандартного vSwitch-а (или же vNetworking Standard Switch aka vSS) — это обеспечение связи между виртуальными машинами и физической сетевой инфраструктурой. В дополнение, он обеспечивает логическое разделение виртуальных машин используя Port Groups, предлагает различные алгоритмы балансирования в случае если у вас есть более чем один аплинк на одном ESXi хосте, обеспечивает шейпинг исходящего трафика от виртуальных машин к vSS, ну и наконец, позволяет обнаруживать сбой аплинка и автоматическое переключать трафик на оставшиеся аплинки.

В одном из комментариев к моему посту о новом функционале vSphere 5 коллега Omnimod скептически высказался о Virtual Storage Appliance (VSA). Мне, честно говоря, самому был очень интересен этот новый функционал и поэтому я решил убедиться насколько оправдан скептицизм более опытного товарища.

Итак, давайте коротко пройдемся по VSA.

Основной целью VSA является предоставление SMB компаниям полноценного функционала общедоступного NFS хранилища, используя локальные диски ESXi хостов. То есть используя VSA в удаленном офисе, при 2 -3 ESXi хостах вам не нужно будет покупать NAS или SAN.

Вот так выглядит VSA при установке на 3 хоста.

Очень сложно конкурировать в описании vSphere 5 с более опытными блогерами, особенно теми, кто уже имел предварительный доступ к бета версии и к презентационным ресурсам VMware. Но я настолько сильно подсел в последнее время на продукты VMware, что не могу удержаться от того, чтобы не выложить свои короткие записи, которые я набросал вчера ночью во время онлайн презентации vSphere 5.

• На сегодняшний день 40% серверной нагрузки приходится на виртуальные сервера. В среднем в год наблюдается 10% рост виртуализации
• Основной темой первой части презентации было движение к облачной модели. Не важно будете ли вы строить частное облако только для нужд вашей компании, или же вы будете предоставлять облако внешним клиентм — вы все это можете легко сделать с помощью новых продуктов VMware. Клиенты должны легко и удобно выбирать виртуальные машины под свои нужды в точности так же, как люди покупают компьютер в онлайн магазине, имея возможность настроить покупку под свои требования. Вобщем, классическая модель IT as a Service.

Эта статья по логике должна была появиться первой, перед статьей про 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.

Я думаю, многие уже успели заглянуть и прочитать эту статью на английском в моем блоге, но для тех кому все таки комфортней читать на родном языке, нежели иностранном (как сказали бы на dirty.ru – на анти-монгольском), я перевожу очередную свою статью.

Вы уже наверняка знаете, что NUMA это неравномерный доступ к памяти. В настоящий момент эта технология представлена в процессорах Intel Nehalem и AMD Opteron. Честно говоря, я, как практикующий по большей части сетевик, всегда был уверен, что все процессоры равномерно борются за доступ к памяти между собой, однако в случае с NUMA процессорами мое представление сильно устарело.

Случайным образом пару недель назад я наткнулся на прошлогоднюю статью товарища 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.