Облака и RCCPA

Мы сделали это!

В России создана Russian Cloud Computing Professional Association (RCCPA) – первое профессиональное объединение независимых экспертов, работающих в области создания, развития и внедрения «облачных» технологий и сервисов. Ассоциация создана в марте 2012 года группой активистов «облачного» рынка. Наши основные цели - выработка единых подходов к формированию развития «облачных» вычислений в России и формирование экспертной площадки для развития российских “облачных” проектов на международных рынках. В планах ассоциации – регулярное проведение встреч, семинаров и конференций, в рамках которых члены ассоциации смогут обмениваться опытом по профильным вопросам.  Мы открыты для сотрудничества, членство и участие в мероприятиях ассоциации бесплатно.

Ждем вас в ассоциации - специалистов по дизайну виртуализованных инфраструктур, превращению железа в облако и продажам облачных услуг. Приходите на CloudConf 2012, где мы будем вручать первую в России премию за достижения в облачных вычислениях - Cloud Award 2012. Ну а я буду участвовать в зажигательном круглом столе "Облачная жесть как она есть" и рассказывать об особенностях облачного хранения данных.

А в этом блоге появляется новая тематика: облака :)

И в качестве начала новых, облачных дискуссий, предлагаю вашему вниманию перевод стандарта NIST по облачным вычислениям. Замечания и критика приветствуются!

Что лучше: Etherchannel и IP Hash или Load Based Teaming?

Споры что лучше - Etherchannel или LBT ведутся с тех пор, как последний механизм балансировки нагрузки появился в vSphere 4.1. Основная причина споров состоит в том, что администраторы или не знают о существовании LBT, или же думают, что сетевой стек у vSphere работает как и у физических серверов - один интерфейс активен, а все остальные простаивают до момент выхода активного из строя.

Варианты тиминга сетевых интерфейсов в vSphere

С самого начала хочу отметить, что vNetwork Distributed Switch (vDS) поддерживает пять разных режимов тиминга, но не поддерживает  LACP (802.3ad) или же Dynamic Etherchannel, поддерживается только Static Etherchannel. Для использования LACP необходимо использовать Cisco Nexus 1000V или какой-либо другой сторонний vDS.

Итак, vSphere поддерживает следующие режимы работы:

Использование одного Storage DRS кластера c несколькими DRS кластерами

Во-первых, такая конфигурация полностью поддерживается VMware. Во время создания ВМ администратор выбирает в каком DRS кластере будет работать ВМ, а Storage DRS кластер, в свою очередь, сервер который может предоставить наибольшее количество ресурсов для виртуальной машины в данном кластере. Рекомендованные миграции, генерированные Storage DRS, не мигрируют ВМ на уровне физического хоста, так как виртуальная машина не может быть перемещена между DRS кластерами по запросу от Storage DRS кластера.

При таком дизайне также необходимо учитывать максимумы конфигураций: в Storage DRS кластер может входить до 32 датасторов, к одному датастору может быть подключено до 64 хостов одновременно, а максимальное количество LUN подключённых к хосту - 255 или же 1024 пути, при использовании multipathing.

Также рекомендуется использовать СХД с поддержкой VAAI или же включать данную технологию, если она поддерживается, так как один из примитивов - Hardware assisted locking или Test and Set (ATS) заменяет SCSI-2 резервирование, что позволяет значительно увеличить скорость работы. Разница между SCSI-2 резервированием и ATS состоит в том, что первый метод блокирует весь LUN при обновлении метаданных или увеличении размера файла, а второй только требуемые сектора, таким образом, позволяя другим хостам использовать данный LUN не ожидая пока будет снято резервирование. Дополнительную информацию о резервировании вы можете найти в КВ 1021976.

При использовании IO Metric для всех датасторов в кластере автоматически включается SIOC (Storage IO Control). Storage DRS использует IO инжектор SIOC для определения производительности СХД, а SIOC используется для равномерного распределения нагрузки в периоды нехватки ресурсов.

SIOC использует доли (shares) дисков виртуальных машин для распределения ресурсов и работает на уровне всего датастора. Если быть более точным, то SIOC это серверный модуль, который собирает данные о задержках доступа наблюдаемых от сервера к СХД. Если задержки превышают пороговый предел, то все хосты изменяют настройку количества очереди запросов к LUN согласно общему количеству долей виртуальных машин, работающих на данном хосте.

Оригинал: http://frankdenneman.nl/

Cравнение протоколов доступа к СХД

	iSCSI	NFS	FC	FCoE
Описание	Протокол блочного уровня. Все SCSI команды инкапсулируются в TCP/IP пакеты и передаются на СХД	Протокол файлового уровня. NFS массив предоставляет доступ ESX хосту к своей локальной файловой системе. ESX хост же обращается к метаданным и файлам используя протокол основанный на RPC. В данный момент поддерживается NFS v3 поверх TCP/IP	Протокол блочного уровня. Все SCSI команды инкапсулируются в FC фреймы	Протокол блочного уровня. Все SCSI команды инкапсулируются в Ethernet фреймы. Во многом схож с Fibre Channel. Поддерживается с vSphere 5
Возможности реализации	1. vSphere vmkernel (обычная сетевая карта) 2. Dependent iSCSI Initiator (сетевая карта с функциями SCSI Offload+vmkernel) 3. Independent iSCSI Initiator (отдельный HBA адаптер)	vSphere vmkernel (обычная сетевая карта)	Выделенный HBA адаптер. Для отказоустойчивости и поддержки multipathing требуется минимум 2 адаптера	1. Hardware Converged Network Adapter (CNA) 2. Software FCoE инициатор (требуется сетевая карта с поддержкой FCoE)
Производительность	1. Поддерживается 1Gbit\10Gbit Ethernet. 2. Несколько соединений могут быть объединены в одну сессию. 3. Поддержка Jumbo Frames. 4. Более высокая нагрузка на ЦПУ за счёт инкапсуляции трафика	1. Поддерживается 1Gbit\10Gbit Ethernet. 2. Не смотря на возможность использования UDP, VMware её не поддерживает. 3. Поддержка Jumbo Frames. 4. Более высокая нагрузка на ЦПУ за счёт инкапсуляции трафика	1. Поддерживается 1/2/4/8 и 16Gb HBA, но последние в vSphere 5 должны работать в режиме 8Gb. 2. Buffer-to-Buffer и End-to-End кредиты гарантируют сеть без потери пакетов. 3. Низкая нагрузка на ЦПУ, так как HBA инкапсулирует весь трафик	1. Требует 10Gb Ethernet. 2. Требует поддержки Jumbo Frames (стандартный размер пакета FC – 2.2KB, а не 1.5 как у Ethernet). 3. Меньшая нагрузка на сеть, по сравнению с iSCSI и NFS, так как нету инкапсуляции SCSI в TCP\IP
Балансировка нагрузки	VMware Pluggable Storage Architecture (PSA)поддерживает Round-Robin для распределения нагрузки между путями. Лучше использовать с большим количеством LUN	В данный момент такой возможности не существует, так как используется только одна сессия. Агрегация каналов может быть достигнута путём подключения по разным путям	VMware Pluggable Storage Architecture (PSA)поддерживает Round-Robin для распределения нагрузки между путями. Лучше использовать с большим количеством LUN	VMware Pluggable Storage Architecture (PSA)поддерживает Round-Robin для распределения нагрузки между путями. Лучше использовать с большим количеством LUN
Отказоустойчивость	Отказоустойчивость обеспечивается с помощью Storage Array Type Plugin (SATP) для всех поддерживаемых iSCSI массивов	NIC Teaming. Хотя данный метод не защищает от сбоев на стороне хранилища	Отказоустойчивость обеспечивается с помощью Storage Array Type Plugin (SATP) для всех поддерживаемых FC массивов	Отказоустойчивость обеспечивается с помощью Storage Array Type Plugin (SATP) для всех поддерживаемых FCoE массивов
Проверка на наличие ошибок	Протокол использует TCP, который пересылает пакеты в случае потери пакетов	Протокол использует TCP, который пересылает пакеты в случае потери пакетов	FC является сетью с гарантией сохранности данных. Обеспечивается благодаря Buffer-to-Buffer и End-to-End кредитам и регулированием полосы пропускания в случае нехватки ресурсов	FCoE требует использования сети с гарантией сохранности данных. Достигается использованием механизма Pause Frame в случае нехватки ресурсов
Безопасность	Авторизация, в том числе и двусторонняя, обеспечивается протоколом Challenge Handshake Authentication Protocol (CHAP). Рекомендуется использовать VLAN или выделенные сети для разделения трафика	Рекомендуется использовать VLAN или выделенные сети для разделения трафика	Некоторые свитчи поддерживают VSAN, являющуюся аналогом VLAN. Также рекомендуется использовать зонинг между массивов и хостами	Некоторые свитчи поддерживают VSAN, являющуюся аналогом VLAN. Также рекомендуется использовать зонинг между массивов и хостами
Поддержка Virtual API for Array Integration	Поддержка определённых примитивов зависит от производителя. Всего доступны следующие примитивы: Atomic Test/Set, Full Copy, Block Zero, Thin Provisioning, Unmap. Все они интегрированы в ESXi и не требуют установки дополнительных элементов	Поддержка определённых примитивов зависит от производителя. Всего доступны следующие примитивы:Full Copy (не поддерживается для Storage vMotion, только для холодной миграции), Write Zeros, Clone Offload. Требуется плагин для ESXi от производителя массива	Поддержка определённых примитивов зависит от производителя. Всего доступны следующие примитивы: Atomic Test/Set, Full Copy, Block Zero, Thin Provisioning, Unmap. Все они интегрированы в ESXi и не требуют установки дополнительных элементов	Поддержка определённых примитивов зависит от производителя. Всего доступны следующие примитивы: Atomic Test/Set, Full Copy, Block Zero, Thin Provisioning, Unmap. Все они интегрированы в ESXi и не требуют установки дополнительных элементов
Загрузка ESXi с СХД	Да	Нет	Да	Да для CNA, нет для software initiator
Поддержка Raw Device Mapping	Да	Нет	Да	Да
Максимальный размер datastore	64ТБ	Зависит от производителя массива	64ТБ	64ТБ
Максимальное количество устройств	256	по умолчанию 8, максимально 256	256	256
Прямое подключение СХД в ВМ	Да, с помощью инициатора в ВМ	Да, с помощью клиента в ВМ	Нет, но FC устройства могут быть подключены к ВМ с помощью NPIV. Требует предварительного подключения RDM и поддержки NPIV со стороны оборудования	Нет
Поддержка Storage vMotion	Да	Да	Да	Да
Поддержка Storage DRS	Да	Да	Да	Да
Поддержка Storage I/O Control	Да, с vSphere 4.1	Да, с vSphere 5.0	Да, с vSphere 4.1	Да, с vSphere 5.0
Поддержка MSCS в ВМ	VMware не поддерживает такую конфигурацию, если ВМ хранятся на iSCSI массиве. Если iSCSI LUN подключён напрямую в ВМ, то такая конфигурация поддерживается Microsoft.	Нет	Да	Нет
Сложность настройки	Средняя. Необходимо знать FQDN или IP адрес массива. Может быть необходима настройка подключений инициатора со стороны массива. Сразу после обнаружения LUN доступен для форматирования под VMFS или подключения как RDM	Низкая. Необходимо знать FQDN или IP адрес массива и точка монтирования. Сразу после обнаружения массив доступен для работы	Высокая. Включает в себя зонирование со стороны свитча и маскирование LUN со стороны хоста. Сразу после обнаружения LUN доступен для форматирования под VMFS или подключения как RDM	Высокая. Включает в себя зонирование со стороны свитча и маскирование LUN со стороны хоста. Сразу после обнаружения LUN доступен для форматирования под VMFS или подключения как RDM
Преимущества	Не требует использования дополнительного оборудования, можно построить используя существующие ресурсы. Хорошо известный и зрелый протокол. Администраторы с небольшими знаниями о сетях смогут без проблем подключить массив. Проблемы решаются использованием стандартных инструментов типа Wireshark	Не требует использования дополнительного оборудования, можно построить используя существующие ресурсы. Хорошо известный и зрелый протокол. Администраторы с небольшими знаниями о сетях смогут без проблем подключить массив. Проблемы решаются использованием стандартных инструментов типа Wireshark	Хорошо известный и зрелый протокол. Используется в большинстве критически важных инфраструктур	Позволяет строить конвергированные сети, консолидируя трафик разных в одной сети, используя CNA. Благодаря использованию протокола DCB (Data Center Bridging ) FCoE является протоколом без потери пакетов не смотря на то, что работает поверх Ethernet.
Недостатки	Невозможность маршрутизации при использовании iSCSI Binding. Возможны проблемы с безопасностью из-за отсутствия встроенных механизмов шифрования, необходимость использовать VLAN. Software iSCSI инициатор повышает нагрузку на ЦПУ. TCP повышает задержки	Так как используется только одна сессия на подключение, настройка при использовании multipathing требует аккуратности и внимания. Нету PSA multipathing. Возможны проблемы с безопасностью из-за отсутствия встроенных механизмов шифрования, необходимость использовать VLAN. VMware все еще использует NFS v3, хотя доступны v4 и v4.1. NFS повышает нагрузку на ЦПУ. TCP повышает задержки	Не поддерживается FC 16Gb. Необходимо дополнительное оборудование - свитчи, HBA и т.д. Сложность в поддержке. Сложность в решении проблем.	Новый протокол, и не такой зрелый, как остальные. Требует lossless 10Gb Ethernet. Для маршрутизации используются не механизмы IP, а свой протокол - FIP (FCoE Initialization Protocol). Возможны сложности в решении проблемы из-за использования одного канала для всех видов трафика

В таблицу специально не включён протокол AoE (ATA over Ethernet) из-за своей непопулярности и небольшого количества реализаций.  

Кастомизируем образ ESXi и скриптуем инсталлляцию ESXi от EMC Proven

Канал EMCProvenSolutions радует новым видео.

VMware vSphere 5 - Using Image Builder To Create Custom ISO

Scripted ESXi Installation

Дед vAdmin

Перед Новым годом, как вы помните, я решил побыть Дедом vAdmin'ом и подарить немного подарков вместе с Iomega.

Iomega® ScreenPlay® MX получил Идрис Кубатаев.

Wireless iConnect Station отправилась в Киев к Кириллу Сухоставскому.

Поздравляем!

В чем разница между CPU Ready и %RDY?

Самым важным ресурсом для виртуальной машины является ЦПУ. И если администратор сталкивается с падением производительности у какой-либо ВМ, то для тонкого траблшутинга производительности очень удобно пользоваться командной утилитой esxtop, которая все значения показывает в процентном соотношении.

В vSphere Client же, в свою очередь, показывает значения в миллисекундах. И если из документации известно, что значение %RDY не должно превышать 10, то соответствующее значение CPU Ready очень легко посчитать.

Итак, и esxtop и vClient собирают данные в реальном времени, и обновляют их каждые 20 секунд  - 20 000 миллисекунд. Таким образом, если CPU Ready за эти 20 000 мс составил 500 мс, то мы делим 500 на 20 000, и получаем значение %RDY около 3, что является прекрасным показателем. Если же CPU Ready составил 7 500, то деление 7 500 на 20 000 даст около 37.5% RDY, что ужасно для однопроцессорной виртуальной машины.

Здесь важно отметить «для однопроцессорной виртуальной машины», так как значение %RDY является суммой значений для всех ядер ВМ. То есть, если в esxtop у 4-ёх ядерной ВМ значение %RDY 20 – то для каждого отдельного vCPU оно составляет в среднем 5.

vClient же, в отличие от esxtop, позволяет просматривать значение CPU Ready как в целом, так и для каждого отдельного вЦПУ.

Оригинал: Jason Boche