GlusterFS - новый класс хранилищ данных

Высокопроизводительные и надежные хранилища данных были и остаются дорогим удовольствием, которое не всем по карману. Полноценное использование технологий виртуализации зачастую невозможно из-за отсутствия именно этого компонента инфраструктуры. И здесь кстати мнения расходятся. Кто то считает, что замены промышленным СХД быть не может. Я же уверен, что существуют значительно более дешевые альтернативы. Более того, мне кажется, что за подобными решениями будущее и современная тенденция, кажется, к этому все и склоняет. Ниже я расскажу и покажу что из себя представляет одна из альтернатив под названием Glus­terFS — а выбор, естественно, за вами.

Glus­terFS часть 1. Что за зверь?
Glus­terFS часть 2. Архитектура
Glus­terFS часть 3. Установка
Glus­terFS часть 4. Типы томов
Glus­terFS часть 5. Создание томов
Glus­terFS часть 6. Монтирование томов
Glus­terFS часть 7. Glus­terFS и oVirt
Glus­terFS часть 8. Тонкая настройка
Glus­terFS часть 9. Квоты

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

oVirt - Цикл статей

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

oVirt часть 1. Введение
oVirt часть 2. Компоненты платформы
oVirt часть 3. Установка
oVirt часть 4. Настройка инфраструктуры
oVirt часть 5. Подключение общего хранилища
oVirt часть 6. Создание ВМ
oVirt часть 7. Интеграция с LDAP

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

Развертывание VMware vCloud Suite

Материал посвящен набору продуктов VMvare vCloud Suite. Рассматривается процесс установки главного компонента VMware vCloud а так же этапы построение вокруг него остальной инфраструктуры необходимой для создания облачных сред.

VMware vCloud Suite. Разворачиваем vCloud Direc­tor
VMware vCloud Suite. Собираем облако

OpenVZ. Цикл статей

Цикл посвящен техническим особенностям, наиболее популярной платформы для контейнерной виртуализации - OpenVZ. Рассматриваются теоретические основы, установка, настройка, обсуждаются сильные стороны а так же проблемы.

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

OpenVZ часть 1. Введение
OpenVZ часть 2. OpenVZ vs LXC
OpenVZ часть 3. Установка
OpenVZ часть 4. Шаблоны контейнеров
OpenVZ часть 5. Управление контейнерами
OpenVZ часть 6. Управление ресурсами контейнеров
OpenVZ часть 7. Сетевой стек
OpenVZ часть 8. Миграция контейнеров между хостами
OpenVZ часть 9. Готовые сборки и панели управления

LXC - Linux Containers. Цыкл статей

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

В этой работе, речь пойдет о наборе компонентов и функций ядра Linux, под названием LXC (Linux Con­tain­ers). 

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

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

Linux Con­tain­ers часть №1. Базовая теория
Linux Con­tain­ers часть №2. Установка
Linux Con­tain­ers часть №3. Базовые действия
Linux Con­tain­ers часть №4. Шаблоны контейнеров
Linux Con­tain­ers часть №5. Хранилище контейнеров, снимки, клоны
Linux Con­tain­ers часть №6. Сетевое взаимодействие
Linux Con­tain­ers часть №7. Обмен данных с контейнером
Linux Con­tain­ers часть №8. Безопасность
Linux Con­tain­ers часть №9. Ограничение ресурсов
Linux Con­tain­ers часть №10. Панели управления

ZEN Load balancer - теория и практика балансировки нагрузки

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

 

ZEN Load bal­ancer часть №1. Теория балансировки нагрузки
ZEN Load bal­ancer часть №2. Немного про Zen LB
ZEN Load bal­ancer часть №3. Практика

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

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

Пробуем 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], но на сцену виртуализации вышла не так давно, хорошо зарекомендовав себя в системах резервного копирования. Дедупликация работает на уровне блоков данных абсолютно не взирая на типы файлов и их содержимое. Поток данных, разделяется на блоки определенного размера, после чего выполняется их сравнение с уже записанными блоками. Сравнение блоков выполняется специальными алгоритмами исключающими коллизии стандартных-хеш функций, способных привести в последствии к разрушению данных. Фактически, на диск записываются только уникальные блоки данных, а там где они повторяются просто создаются на них ссылки. Читать далее