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 отказавшись воспользоваться мастером первичной настройки. Читать дальше

Пробуем CloudStack 4. Устанавливаем и радуемся его работе

По сути, Cloud­Stack это управляющий сервер(Management Server node) для XenServer и KVM хостов с поддержкой NFS и iSCSI-хранилищ, позволяющий более гибко(по облочному) управлять подконтрольными ему ресурсами(хостами, хранилищами, виртуальными машинами). В отличии от Open­Stack здесь нет кучи различных ролей и базовых компонентов разнесенных(в идеале) по разным серверам. Для своей работы, CloudStack'у необходим только MySQL который может быть установлен на том же сервере(Single Man­age­ment Server node). В случае развертывания нескольких серверов CloudStack(Multiple Man­age­ment Server nodes) MySQL должен быть вынесен на отдельный сервер.
После установки, Cloud­Stack берет управление всей инфраструктурой на себя, при этом управлять хостами с помощью XenCenter(для XenServer) или например Virt-manager, virsh(для KVM-хостов) никто не запрещает, хотя это может привести к рассинхронизации конфигурации в разных консолях.Читать дальше