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-хостов) никто не запрещает, хотя это может привести к рассинхронизации конфигурации в разных консолях.Читать дальше

CloudStack 4. Архитектура, особенности и недостатки

К сожалению, многие не видят принципиального отличия виртуализированного дата-центра от облака и зачастую не понимают, где заканчивается одно и начинается другое.

По сути, современные платформы виртуализации – это связка физических серверов, гипервизора, дополнительных компонентов и удобных средств развертки, настройки и управления программно-аппаратной виртуальной инфраструктурой. Под средствами управления и настройки я понимаю программное обеспечение типа VMware vSphere Client и VMware vCen­ter Server для централизованного управления ESX/ESXi, Cit­rix Xen­Cen­ter для XenServer и т.д.

Нужно понимать, что существующие сегодня платформы виртуализации типа VMware vSphere, Cit­rix XenServer, RHEV (Red­Hat Enter­prise Vir­tu­al­iza­tion) и т. д. а так же различные системы хранения данных являются базовыми блоками для облачной инфраструктуры. А инструментарий администрирования входящий в состав перечисленных выше продуктов ориентирован более на инженеров и обслуживающий персонал нежели на пользователей или возможных клиентов. Кроме того, практически все поставщики продуктов серверной виртуализации ставят ставку на один тип гипервизора (чаще всего свой собственный) и не позволяют используя одни и те же средства управления, применить несколько гипервизоров в одной среде.
Платформы для построения облака, такие как Cloud­Stack, Open­Neb­ula, Eucalip­tus и набирающей ход Open­Stack предоставляют нам дополнительный уровень иерархии позволяя абстрагироваться не только от физического оборудования, но и от различных гипервизоров совместно используемых в единой инфраструктуре. Облачные платформы не отменяют и не заменяют полностью, привычные средства управления, а вводят новые понятия и предоставляют более гибкие возможности, делая работу с огромными инфраструктурами проще и логичнее не только для администраторов, но и для простых пользователей которые являются неотъемлемой частью концепции облаков. Читать далее

Бюджетная виртуализация. Оптимизация NFS и iSCSI

Основная часть материалов, посвященная виртуализации, ориентирована в основном на крупные и средние инфраструктуры. О внедрениях виртуализации в масштабах 10-20 ВМ на нескольких серверах сегодня почти никто не говорит. А на самом деле, сред, в которых работает не большее число ВМ, на проложенном в далеком прошлом Eth­er­net и самосборных сетевые хранилищах, достаточно. И ситуация эта особенно характерна для СНГ, где на развитие ИТ-отдела и на внедрение новых технологий порой выделяют столько средств, что трудно не заплакать.
В этой статье, хочется уделить внимание возможным путям оптимизации сетевой подсистемы, как на аппаратном уровне, так и на программном, для повышения производительности имеющегося оборудования и каналов связи.
В данной статье, под каналами связи везде, где не указанно обратное, подразумевается доступный даже в самых бюджетных организациях Giga­bit Ethernet. Читать далее

Бюджетная виртуализация. NFS vs iSCSI, что выбрать?

Безусловно лучшим решением для построения высокопроизводительных и надежных сетей хранения данных(далее СХД) для любых задач, является использование оптических каналов и Fibre Chan­nel Prototocol(FCP).
FCP инкапсулирующий SCSI команды, изначально разрабатывался с учетом всех тонкостей блочного обмена данными. В нем отсутствуют основные недостатки классических сетевых протоколов типа TCP/UDP, в которых данные могут теряться или приходить не последовательно, что не приемлемо для SCSI. Заголовок пакета FCP минимален в отличии от того же iSCSI, что значительно сокращает накладные расходы. Аппаратные контроллеры FC - HBA(Host Bus Adapter) полностью берут на себя генерацию заголовков пакетов снимая тем самым нагрузку с центральных процессоров. А высокопроизводительные оптические каналы (2Gb/4Gb/8Gb и выше) обеспечивают надежную передачу данных на большие расстояния.

О FC и сетях хранения, построенных с его применением, написаны целые книги и перечислять его достоинства можно долго, но хочется сказать о его главном недостатке.
Высокая стоимость отдельных компонентов FC(HBA, коммутаторы и тому подобное) и суммарная стоимость конечной реализации, пожалуй, является определяющим фактором заставляющим отказаться от сетей хранения на базе FC. Так же далеко не каждая инфраструктура, в том числе и виртуальная, нуждается в FC. Например для полноценной работы нескольких десятков виртуальных машин(ВМ) не обязательно строить дорогостоящую систему хранения. А все технологии, присущие виртуализации (живая миграция ВМ, высокая доступность и так далее) так же реализуемы на iSCSI или NFS. Более того, некоторые платформы виртуализации, например такие как Prox­moxVE  или Cloud­Stack и вовсе не умеют работать с FC, тогда использование как iSCSi и NFS доступно на всех платформах. В общем, можно сказать однозначно, что NFS и iSCSI — быть! А вот, что и где эффективнее использовать, поговорим далее.

Эффективность дедупликации хранилища на примере StarWind iSCSI SAN

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

Во времена стремительного развития технологий виртуализации достаточно широко рассматриваются вопросы эффективности использования ресурсов выделяемых под нужды виртуальных серверов и рабочих станций. Одним из важных направлений на сегодняшний день является оптимизация использования дискового пространства на системах хранения занимаемого виртуальными машинами (далее ВМ). Сегодня уже существуют хорошо зарекомендовавшие форматы «тонких дисков» (Thin pro­vi­sion­ing) которые увеличиваются в объеме по мере заполнения данными. При виртуализации рабочих станций применяется технология «золотого образа» позволяющая использовать один единственный виртуальный диск как основу для множества ВМ, сохраняя для каждой лишь отличия от «золотого» образа.

 Но особой популярностью в последнее время пользуется технология дедупликации данных. Сама по себе технология не молода[1], но на сцену виртуализации вышла не так давно, хорошо зарекомендовав себя в системах резервного копирования. Дедупликация работает на уровне блоков данных абсолютно не взирая на типы файлов и их содержимое. Поток данных, разделяется на блоки определенного размера, после чего выполняется их сравнение с уже записанными блоками. Сравнение блоков выполняется специальными алгоритмами исключающими коллизии стандартных-хеш функций, способных привести в последствии к разрушению данных. Фактически, на диск записываются только уникальные блоки данных, а там где они повторяются просто создаются на них ссылки. Читать далее