пятница, 4 мая 2012 г.

Облака и RCCPA

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

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

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

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

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

четверг, 3 мая 2012 г.

Что лучше: 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/