За последние несколько недель с VMware происходит нечто странное. Сначала они неожиданным образом изменили схему лицензирования vSphere 5, а потом пересмотрели её, смягчив немного условия. Впрочем, интересна не столько сама новая модель лицензирования, сколько причины такой переменчивости. Под катом я попробую проанализировать текущее состояние и перспективы рынка виртуализации.

Аллилуйя! Огромнейший поток жалоб на новую модель лицензирования был услышан в компании 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 хоста.

Недавно и я стал обладателем сервера HP ProLiant MicroServer N36L. То, что на нем будет стоять Citrix XenServer, было решено заранее, тем более положительный опыт установки на этот сервер имеет место быть. Задачу установки немного усложняло то, что я был в отпуске. Дома, кроме буков и пары мышек, больше компьютерной техники нет. А для установки хотелось бы иметь клавиатуру, которую можно было принести с работы, и монитор. Проблема с монитором решилась просто, на телевизоре оказался VGA-разъем, дома нашелся кабель для него. Решил попробовать установить XenServer в автоматическом режиме, наблюдая за установкой по телевизору. Так как на сервере отсутствует оптический привод, устанавливать будем с флэшки.

Очень сложно конкурировать в описании 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 процессорами мое представление сильно устарело.

В предыдущих сериях публикациях мы рассмотрели с вами вопросы подготовки хост-машины, создания и клонирования виртуальных машин. Сегодня я поведаю о не менее важном вопросе — об ограничении использования ресурсов виртуальными машинами.

Вступление

Proxmox Virtual Environment (Proxmox VE) — система виртуализации с открытым исходным кодом, основанная на Debian GNU/Linux. Разрабатывается австрийской фирмой Proxmox Server Solutions GmbH, спонсируемой Internet Foundation Austria.
В качестве гипервизоров использует KVM и OpenVZ. Соответственно, способна выполнять любые поддерживаемые KVM ОС (Linux, *BSD, Windows и другие) с минимальными потерями производительности и Linux без потерь.
Управление виртуальными машинами и администрирование самого сервера производятся через веб-интерфейс либо через стандартный интерфейс командной строки Linux.
Для создаваемых виртуальных машин доступно множество опций: используемый гипервизор, тип хранилища (файл образа или LVM), тип эмулируемой дисковой подсистемы (IDE, SCSI или VirtIO), тип эмулируемой сетевой карты, количество доступных процессоров и другие.
ru.wikipedia.org/wiki/Proxmox_Virtual_Environment

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

Продолжаем серию статей о виртуализации на базе KVM. В предыдущих статьях было рассказано об инструментарии, о настройке хост-машины и создании виртуальной машины. Сегодня мы поговорим о создании образа виртуальной машины и его клонировании.

Вступление

Как и было обещано в предыдущей статье, сегодня мы поговорим о базовой настройке хост-машины для работы KVM.

Не могу уже через gui...

Примерно так начинался мой разговор с другом которому в течение короткого промежутка времени пришлось несколько раз подряд экспортировать виртуальные машины из Hyper-V. Обычно для этого используется Hyper-V Manager (HVM), который устанавливается вместе с ролью Hyper-V под Windows Server 2008 R2. Я должен признаться что интерфейс этой программы не вызывает у меня каких-либо негативных эмоций. Среди всех программ для управления, которые Microsoft поставляет к Server эта мне кажется наиболее удобной и понятной (сравниваю например с IIS Manager, который вызывает недоумение у новых пользователей и бурное негодование у тех кто использовал IIS 6 в 2003 Server). Однако если нужно экспортировать или импортировать виртуальную машину в количестве N-штук в промежуток t-времени то используя Hyper-V Manager можно сломать кнопку у мыши и жутко возненавидеть Hyper-V. Тут на помощь и приходит PowerShell.

В блоге Open Source-проекта виртуализации Xen появилась заметка, в которой высказывается радость по поводу достижения полной поддержки dom0 и domU в Linux.

Последний необходимый для этого шаг был предпринят на прошлой неделе, когда Линус Торвальдс (Linus Torvalds) добавил xen-blkback в основную ветвь разработки ядра Linux. Таким образом, уже в следующий релиз — Linux 3.0 — войдет изменение, которое обеспечит все, что нужно для функционирования Linux и в качестве управляющей операционной системы («dom0» в терминологии Xen), и в качестве гостя («domU»).

Как резонно отмечается в блоге компании Citrix, поглотившей Xen в 2007 году, «попадание в upstream очень важно, поскольку означает, что у дистрибутивов больше нет необходимости предоставлять различные ядра для обеспечения поддержки Xen».

Весь путь появления полной поддержки Xen в ядре Linux занял более 4 лет.
(nixp.ru)

Как и обещал, начинаю серию статей о том, как мы делали услугу аренды выделенных серверов на базе KVM.

В этой вступительной статье я расскажу вкратце обо всех программных средствах, использованных в процессе разработки услуги. Более подробно о них будет рассказано в следующих статьях.

В последнее время наметились тенденции к переходу в/на облачные вычисления.

Из Wiki: Облачные вычисления (англ. cloud computing) — технология распределённой обработки данных, в которой компьютерные ресурсы и мощности предоставляются пользователю как интернет-сервис.

Одним из самых сложных моментов является перенос приложений в виртуальную среду. Хочу рассказать про решение от компании Microsoft — Application Virtualization for Desktops, оно входит в состав Microsoft Desktop Optimization Pack и весьма успешно «виртуализирует» все то программное обеспечение, к которому Вы привыкли.

Вторая часть краткой, но познавательной повести о комсомольском пути установки и настройки домашнего сервера для различных нужд.

Первая часть тут.

Подарили мне на работе на день рождения HP N36L Microserver за непонятные заслуги, чем весьма меня озадачили вопросом о наилучшем его применении. Так-то я давно мечтал заменить старенький HP DC4200 на что-то более компактное и, главное, с большим количеством места под жёсткие диски. Но больше смотрел на башенные корпуса, в которые можно было бы насовать пару-тройку корзин на пять 3.5”HDD. А тут такая оказия.

Прошерстил интернеты, почитал умных и не очень людей и, как водится у настоящих комсомольцев, решил идти своим путём.

Вступление

Проводя работу по изучению производительности разных задач в виртуальных машинах, я использовал старый проверенный метод для количественного осмысления полученных результатов, а именно бенчмарки. Многие из них довольно хорошо себя зарекомендовали ранее, плюс даже пару своих написал на волне энтузиазма. Собрав уже неплохую статистику, не сильно сомневаясь в полученных результатах, на одном из тестов я случайно заметил, что затраченное на задачу время, о котором радостно отрапортовала программа, в несколько раз больше того, сколько я ждал этого результата. Повторные замеры с секундомером подтвердили мои наблюдения: да, время в виртуальной машине может идти не так, как мы ожидаем. За подробностями и чем нам это грозит прошу под хаброкат.