VMware vSphere 5.5 – улучшенные возможности и новые проблемы

Новые возможности

VMware vSphere 5.5 характерна множественными изменениями и новыми возможностями о которых можно было бы написать целую статью. В данном разделе коснусь только тех, что показались мне наиболее интересными. Кроме некоторых улучшений в работе гипервизора, а так же традиционного увеличения количества поддерживаемой памяти, процессоров, NUMA-узлов, теперь полноценно поддерживаются FC-адаптеры, с пропускной способностью в 16 Гбит/с (ранее до 8 Гбит/с). Подобные положительные изменения затронули и бесплатную версию ESXi. Здесь наконец то сняты ограничения на объем оперативной памяти. Ранее использовалось только 32 Гб. 

К основным улучшениям виртуальных машин можно отнести обновление виртуального железа до версии 10. Пожалуй, самым примечательным в этом обновлении стал новый виртуальный SATA-контроллер позволяющий подключить к одной ВМ до 120 дисковых устройств. Правда, найти практическое применение такому новшеству, кажется не просто.

Расширена поддержка vGPU. Теперь допустимо использование графических адаптеров от AMD. Ранее возможно было применение только карт от NVIDIA. Полный список поддерживаемых моделей.
Как и в предыдущей версии платформы возможны три техники графического ускорения трехмерной графики:

Soft 3D - рендеринг 3D-картинки вообще без использования адаптера на основе программных алгоритмов с использованием дополнительной памяти сервера. Тут хочется отметить, что ожидать производительности от такого рендеренга не стоит. Даже при выделении максимально допустимых 512 Мб оперативной памяти на его нужды, интерфейс Win­dows Aero тормозит и дергается. Объем памяти выделяемый на обработку 3D настраивается только в параметрах пула виртуальных машин в менеджере VMware Hori­son View Admin­is­tra­tor (Рис №1). Если же продукты виртуализации рабочих станций не используются то средствами vSphere web-client возможно только включение поддержки 3d и выбор, аппаратного или программно рендеренга.

vDGA — монопольное выделение графического адаптера (GPU) конкретной виртуальной машине. В таком режиме, не поддерживаются динамические сервисы(vMotion, HA, DRS) для этой ВМ.

vSGA - использование несколькими виртуальными машинами одного, общего графического адаптера.

Рис №1. Параметры выделения памяти для программного 3D рендеренга.

Касательно версии vSphere 5.5 примечательно, что 3D ускорение поддерживаются не только в Win­dows 7/8, но и в популярных дистрибутивах Linux таких как Fedora 17, Ubuntu 12, Red­Hat 7 а так же в более новых версиях этих ОС. Указаны очень старые версии, может написать Fedora 17+. Очень старые? Red­Hat 7 и Ubuntu 12 – текущие версии да и Fedora 17 не особо старая. Тут указанны минимальные планки и сказано о поддержке более новых. При этом возможно применение миграции ВМ (VMware vMo­tion) между хостами с графическими адаптерами разных вендоров. В случае если возникнут какие-либо проблемы совместимости или же на целевом хосте, вовсе не окажется графического адаптера, будет задействовано программное 3D-ускорение. Читать далее >>

Mininet - эмулятор компьютерной сети

Работая над статьей, посвященной Open vSwitch, проходя по различным ссылкам в поисках хоть какой-нибудь полезной информации, открыл для себя проект под названием mininet. Будучи активным читателем технической и компьютерной литературы, журналов и новостей, думал, что все самое интересное я уже изучил и попробовал.  Но, этот проект меня искренне удивил. Я не уверен в практической ценности данного решения для большинства читателей, но мой личный интерес к нему подтолкнул к написанию статьи.

Mininet - это эмулятор компьютерной сети. Под компьютерной сетью подразумеваются простые компьютеры - хосты, коммутаторы, а так же OpenFlow-контроллеры. С помощью простейшего синтаксиса в примитивном интерпретаторе команд можно разворачивать сети из произвольного количества хостов, коммутаторов в различных топологиях и все это в рамках одной виртуальной машины(ВМ). На всех хостах можно изменять сетевую конфигурацию, пользоваться стандартными утилитами(ipconfig, ping) и даже получать доступ к терминалу. На коммутаторы можно добавлять различные правила и маршрутизировать трафик. В общем, получается довольно интересная вещь, позволяющая познакомиться с устройством и функционированием компьютерных сетей без необходимости использования какого либо сетевого оборудования. Вся статья

Citrix XenApp - Цикл статей

Материалы опубликованы в журнале журнале "Системный Администратор"

В статьях рассмотрена архитектура и особенности наиболее популярной сегодня платформы для виртуализации и доставки приложений Cit­rix XenApp 6.5

 

Часть №1. Введение
Часть №2. Архитектура
Часть №3. Фермы, Зоны, Группы
Часть №4. Изоляция приложений
Часть №5. Доставка приложений
Часть №6. Доступ к приложениям и разграничение прав
Часть №7. Балансировка нагрузки и отказоустойчивость

Open vSwitch. Цикл статей

Обзор возможностей виртуального коммутатора Open vSwitch:

 

Open vSwitch часть №1. Зачем и для чего
Open vSwitch часть №2. Развертывание
Open vSwitch часть №3. Архитектура
Open vSwitch часть №4. Создаем коммутатор и добавляем порты
Open vSwitch часть №5. Тонкости конфигурирования
Open vSwitch часть №6. Организовываем виртуальные сети (VLAN)
Open vSwitch часть №7. Агрегируем физические интерфейсы
Open vSwitch часть №8. Интерфейс управления хост-ситемой
Open vSwitch часть №9. Сопоставление портов и ВМ
Open vSwitch часть №10. Зеркалирование портов
Open vSwitch часть №11. GRE туннелирование
Open vSwitch часть №12. Заключение
Cit­rix Dis­trib­uted vSwitch con­troller. Концепция SDN

Материалы опубликованы в журнале "Системный Администратор"

Multipath I/O в Linux для программного iSCSI

Mul­ti­path I/O - технология, позволяющая задействовать нескольких контроллеров или шин для доступа к одному устройству хранения данных. Например, один SCSI диск может быть подсоединён к двум SCSI контроллерам. В случае отказа одного из них, операционная система будет продолжать работать по другому.  Это дает возможность повысить производительность и отказоустойчивость среды передачи данных.
 

В случае с iSCSI, принципиальная схема не меняется т.к. подключенные по сети блочные устройства (iSCSI-Target) для операционной системы не чем не отличаются от локальных устройств хранения данных. Единственное, что вместо SCSI контроллеров и шлейфов, используются компоненты обычного Eth­er­net - сетевые карты, медные или оптические кабеля. В продуктах VMware и Cit­rix данную технологию можно встретить под именем Multipathing.

Device-Mapper Mul­ti­path (DM Mul­ti­path, множественное связывание устройств) - название реализации технологии Mul­ti­path I/O в Linux доступной во всех современных дистрибутивах. Реализован в виде модуля ядра. Прозрачно для приложений, представляет массив, доступный по нескольким путям, в виде одного мета-устройства.

Использование DM Mul­ti­path позволяет достичь следующего:

•    Отказоустойчивость  - в случае сбоя любого маршрута (кабеля, контроллера или коммутатора) DM-Multipath начнет использовать альтернативный путь из числа не активных.
•    Балансировка нагрузки – запросы ввода и вывода распределяюся между путями по очереди, что равномерно загружает все доступные сетевые контроллеры и каналы. Вся статья

CloudStack 4. Создание и запуск виртуальных машин

После того как выполнена установка и базовая настройка облака под управлением Cloud­Stack самое время посмотреть на него в работе запустив парочку другую виртуальных машин(далее ВМ) и понаблюдать за их работой.

Cloud­Stack, это высокоуровневая система управления гетерогенной виртуальной инфраструктурой, которая разработана для удобного управления средами с большим количеством различных гипервизоров, предоставляя удобные механизмы управления.  Архитектура Cloud­Sack, изначально сделана многоуровневой и масштабируемой по этому даже для запуска всего одной ВМ необходимо иметь сконфигурированную Зону(Zone), Стойку(Pod), Кластер(Cluster), хотя бы один Хост(Host) в кластере а так же по одному Первичному(Primary) и Вторичному(Secondary) хранилищу.

Перед тем как будет создан и запущен первый instace(ВМ в терминологии Cloud­Stack), стоит отметить, что если все было сделано как в предыдущей статье, то в вашем облаке уже работает несколько ВМ. Эти ВМ-призраки которые не отображаются в разделе Instance являются служебными и увидеть их можно в разделе Infra­struc­ture пункт Sys­tem VMs. Скорей всего, будут доступны две ВМ тип(Type) у которых будет Con­sole Proxy VM и Sec­ondary Stor­age VM. Эти служебные ВМ разворачиваются CloudStack'ом из служебного шаблона Sys­temVM Template(доступен в разделе Tem­plates) по мере необходимости для выполнения тех или иных служебных и фоновых задач. Например ВМ Sec­ondary Stor­age VM обслуживает все операции связанные с Вторичным хранилищем(Secondary stor­age) и непосредственно участвует при загрузки новых шаблонов и ISO-образов в Cloud­Stack. Что либо делать с системными ВМ не рекомендуется. Cloud­Stack сам принимает решение когда какая то из ВМ не нужна или наоборот необходимо несколько. Убедитесь, что Sec­ondary Stor­age VM работает(в сотоянии Run­ning) т. к. без нее загрузка шаблонов и ISO-образов будет не возможной! Далее

CloudStack 4. Собираем облако

После установки и прежде чем будет запущена первая ВМ нужно сконфигурировать минимально необходимые для работы Cloud­Stack структурные элементы (Zone, Pods, Clus­ters), подключить системы хранения и хотя бы один хост (обычно KVM, Xen или VMware).

Все необходимые структурные элементы(Zone, Pod, Clus­ter, Host а также Pri­mary и Sec­ondary стораджи) будет предложено настроить с помощью простенького мастера запускающегося сразу после первого входа в веб-консоль Cloud­Stack. На мой взгляд, мастер первичной настройки слишком упрощенный. Например нет возможности в качестве Pri­mary стораджа использовать iSCSI хранилище. По этому, создание первой зоны(Zone) и всех ее составляющих я выполнял с помощью более детализованных мастеров настройки, доступных в веб-консоле Cloud­Stack отказавшись воспользоваться мастером первичной настройки. Читать дальше