четверг, 16 июля 2015 г.

Какой же язык программирования самый облачный?

Данный пост навеян обсуждением в Фейсбуке, начавшимся с "на JS и PHP написаны все говнооблака спорить не буду. А что потом? Так вот, за F# будущее".
В процессе обсуждения была высказана интересная мысль, даже смелая: "Облако - это новая вычислительная среда. Она устроена действительно по-иному нежели привычные нам персоналки".
И вот в чем вся соль: оба этих утверждения неверны.

Облако - это прежде всего самообслуживание и биллинг, это непременные атрибуты XaaS. Внизу облачный сервис состоит из множества маленьких сервисов, подсервисов и подсистем, каждая из которых может быть написана на любом языке или даже смеси языков. На некоторых языках программирования удобнее писать определенный вид сервисов. И то, если у вас есть команда разработчиков, хорошо владеющих данным языком и всей обвязкой к нему в виде библиотек и импортируемых модулей.
Я лично назвал бы только два с половиной языка, на которых можно написать полный стек облачного сервиса - это C, C++ и Java. Во всех остальных случаях придется использовать несколько языков. Но удивительное дело, ни один из них не нов и ни разу не облачен.

Вернемся ко второму утверждению о принципиально новом устройстве облачной среды с точки зрения программирования.
Как только мы отбрасываем биллинг и самообслуживание в PaaS, то оказываемся в совершенно традиционной среде, существовавшей задолго до облаков, хотя может быть и не столько популярной. И называется она Grid. Ничего нового облака нам снова не принесли, кроме значительной популяризации архитектуры грида. Возьми любое популярное PaaS облако, как например AWS или Azure - это не более чем набор очень больших гридов на каждый сервис и API к ним. API, кстати, тоже совсем не облачное изобретение.
Впрочем, есть пожалуй одна из архитектурных концепций, зародившихся примерно одновременно с облаками. Хотя я бы поставил ее как основу облаков, а не их следствие. Архитектура, построенная по принципу Design To Fail, или по-русски рассчитанная на отказ. Классическая привычная нам архитектура монолитных систем высокой доступности не может масштабироваться, и по сути ограничена сверху размером хоста. Для Scale-Out, неограниченно масштабируемой горизонтально системы, требуется не высокая доступность, а способность переживать отказ части узлов грида с минимальными последствиями для жизни всей системы.

Итого:
1. Нет никаких "облачных" языков, есть лишь универсальные и специализированные. Облако может быть построено на любом универсальном или любом миксе специализированных языков программирования.
2. Облака ничем не отличаются по архитектуре от дооблачных сервисов, несмотря на значительное развитие и появление новых сервисов в облачную эпоху.

вторник, 7 июля 2015 г.

VMware User Group 2015 - Программа

10 июля, Москва
Регистрация начинается в 9-30.

Владислав Кирилин (VMware), Сергей Горлинский (ActiveCloud) "Грузим грабли камазами"

Виктор Владимиров (VMware) "Horizon - плюсы и минусы из реальной практики внедрения"

Александр Серебряков (F5) "Построение отказоустойчивой платформы Horizon View"

Владимир Ескин (Veeam) "Veeam + VMware = Love"

Максим Шапошников (Nutanix) "Новости гиперковергентных инфраструктур"

Андрей Бешков (Microsoft) "Рекомендации по безопасности виртуальных инфраструктур"

Антон Жбанков (Step Logic), Сергей Груздов (Монт) "Демо-стенд на 1000ВМ. Только практика"

Константин Введенский (VMware) "Что такое vVols и с чем их едят"

Место проведения: Best Western Plus Vega Hotel & Convention Center

понедельник, 29 июня 2015 г.

VMware User Group 2015

Друзья, рад объявить о проведении встречи VMware User Group 2015 10го июля в Москве. как всегда будет много очень технических докладов о реальной жизни и реальных проблемах.

Регистрация: ЗАКРЫТА

вторник, 5 мая 2015 г.

vVNX Community Edition

EMC опубликовала бесплатный полнофункциональный виртуальный VNX с ограничением до 4ТБ емкости. Поддерживается функционал vVols - соотв. это отличный способ попробовать их на практике.

Фактически это код от VNXe 3200, доступен в формате OVA и требует среду VMware.

http://www.emc.com/products-solutions/trial-software-download/vvnx.htm

вторник, 10 февраля 2015 г.

Техническое описание VVol

Первое что хотелось бы отметить - технология называется VVol, не vVol, Vvol и прочее (от переводчика).


Традиционные системы хранения данных имеют следующие недостатки:
  • Специализированное и дорогое железо - не общедоступное, стандартное оборудование, низкая утилизация и переподписка (overprovisioning);
  • Архитектуру от устройства - статические уровни предоставления качества, стандартизированное выделение ресурсов, невозможность гранулярного контроля;
  • Сложные процессы - недостаточность автоматизации, затратные по времени процессы, медленная скорость реакции на запросы.
Гипервизор позволяет реализовать автоматизацию СХД от приложения, так как:
  • Знает все требования приложений в реальном времени;
  • Является элементом пути в операции ввода-вывода;
  • Видит все нижележащие СХД;
  • Может динамически настраивать СХД;
  • Независим от аппаратного обеспечения.
Традиционная модель - длительные циклы предоставления ресурсов, управление LUN, сложные и частые миграции данных.

Автоматизация от приложения - динамическое предоставление ресурсов СХД по мере необходимости. Контроль уровня предоставления сервиса на уровне отдельной ВМ. Общее управление разными устройствами.


vSphere Virtual Volumes
  • Виртуализирует SAN и NAS устройства;
  • Виртуальные диски нативно предоставляются массиву;
  • Позволяют выполнять операции на уровне отдельной ВМ используя функции СХД;
  • Управление хранилище на основе политик (SPBM, Storage policy-based management) позволяет автоматизировать потребление ресурсов при масштабировании;
  • Широкая поддержка основнымит производителями СХД;
  • Поставляется с vSphere.
Что такое VVol?
  • Пять типов объектов VVols: Config, Data, MEM, SWAP, Other;
  • Отсутствие необходимости использования СХД (VMFS отходит в историю);
  • Объекты виртуальной машины хранятся нативно на СХД;
Контейнер массива (Storage Container)
  • Логическая конструкция массива для группирования виртуальных томов;
  • Обычно определяется администратором СХД на самом массиве для определения ёмкости массива и его ограничений;
  • Ёмкость определяется физической ёмкостью массива.
Разница между контейнерами массива и LUN
  • Размер контейнера основан на ёмкости массива;
  • Максимальное количество контейнеров зависит от массива;
  • Размер контейнера может быть расширен;
  • LUN требует файловой системы, стандартизация размера LUN требует большего их количества.
Протокол конечной точки (Protocol End Points)
  • Точка доступа реализовывающая коммуникацию между ESXi и СХД;
  • На данный момент поддерживаются: iSCSI, NFS v3, FC, FCoE;
  • Для каждой конечной точки единовременно поддерживается какой-то один обозначенный протокол;
  • Конечная точка получает SCSI либо NFS команды;
  • Контейнера массива - для большого количества метаданных и данных ВМ.
Панель управления
  • VASA Provider (VP) - разрабатывается поставщиком СХД;
  • Один VP может управлять несколькими массивами;
  • VASA Provider может быть реализован как внутри массива, так и в виде внешней ВМ;
  • Внеполосной (out of band) обмен сообщениями;
  • ESXi и vCenter Server подключаются к VASA Provider.
Возможности массива и политики хранения ВМ (Storage Capabilities и VM Storage Policies)
  • Являются функциями массива и требованиями ВМ к этим функциям, соответственно. Требования могут быть удовлетворены возможностями, предоставляемыми массивом;
  • Возможности массива определяют что может предоставить массив в ответ на требования ВМ;
  • Политики хранения ВМ являются компонентом хранилища на основе политик
  • Представленные возможности - функции и сервисы массива, предоставленные гипервизору через VASA API;
  • Управляются на уровне виртуального диска ВМ
  • Используют концепцию соответствия для контроля предоставляемого уровня сервиса.
Сценарии операций
  • Разгрузка операций: разворачивание, удаление, клонирование (полное и связанных), снепшоты;
  • Снепшоты: управляемые ESXi или массивом.
В данной версии SRM не поддерживает VVol, но будет в следующей.

В будущих версиях VVol позволит пулу массива распространяться между физическими массивами.

Статья написана на основе доклада Роулинсона Риверы (Rawlinson Rivera) с VMware PEX 2015.
Оригинал: VVol Technical Overview

среда, 17 сентября 2014 г.

Software Defined XXX

В последнее время стала наблюдаться путаница в терминологии, в особенности подогреваемая различными маркетинговыми публикациями. Software Defined XXX, XaaS, Internet of things и так далее. Попробуем с этим разобраться.

XaaS - X-as-a-Service, что-то как услуга. Стандартный термин для облачных услуг (соответствующих определению NIST). X - конкретная услуга или класс услуг.
Software Defined XXX - программно определяемое XXX. Смысл термина - подчеркнуть отказ от специализированного оборудования в пользу стандартных серверов. Весь функционал продукта определяется не аппаратной начинкой и специальными процессорами, а исключительно залитым софтом.

В частности, есть понятие Software Defined Storage (SDS). Т.е. система хранения данных, построенная на стандартных компонентах, которые можно купить условно в любом магазине.

С другой стороны интеграция различных компонентов позволила появиться конвергентным решениям. Например, объединение трафика Fiber Channel и Ethernet в Cisco UCS и передача его по одному совмещенному каналу. При дальнейшей интеграции появились конвергентные решения - все-в-1, объединяющие в себе ресурсы хранения, сети передачи данных и вычислительные мощности. Пример - VCE Vblock, FlexPod и другие.
На границе Software Defined и конвергентных решений появился новый класс - гиперконвергентные решения, внутри которых используется только стандартное commodity оборудование, и все определяется системным ПО. Примеры - Nutanix, Simplivity, VMware EVO:RAIL.

И здесь есть определенный тонкий момент - внутри этих систем применяется Software Defined Storage для агрегации сырых ресурсов с физических дисков в логические пулы, но сама гиперконвергентная система не является SDS. Отличительная особенность - SDS построена для того, чтобы экспортировать ресурсы хранения до клиента. Гиперконвергентная система наоборот, потребляет эти ресурсы, предоставляя клиенту возможность обработки информации.

Иными словами, Nutanix не является Software Defined Storage.

вторник, 26 августа 2014 г.

EMC RecoverPoint для виртуальных машин

EMC представила RecoverPoint for VMs специально для приложений, работающих в облаках на базе vSphere. RPVM управляется при помощи vCenter plug-in, разворачивается как виртуальный модуль (virtual appliance). Так же, как и старший брат, использует сплиттеры, но в этом случае не на уровне СХД или коммутации, а прямо в ядре ESXi. В силу чего работает с вообще любой СХД, вне зависимости от того SAN, NAS это или DAS. В том числе поддерживается и VMware VSAN.

 

RP4VMs-3

RecoverPoint for VMs может работать в режимах локальной и удаленной репликации вместе с постоянной защитой данных с гранулярностью 1 ВМ. RecoverPoint for VMs использует журнал дисковых операций для отслеживания всех изменений с ВМ, и может откатить состояние ВМ на любую точку во времени как видеомагнитофон.

RecoverPoint for VMs рассчитан на инсталляцию инженерами заказчика через простой и понятный мастер. Сплиттер содержится в маленьком VIB файле и поддерживает vSpeher 5.1u1 и 5.5. Разумеется, VIB должен быть установлен на всех хостах, где может обитать защищаемая ВМ. 

RP4VMs-1

В больших средах RecoverPoint for VMs дает возможность автоматически защищать ВМ через использование политик. RecoverPoint for VMs так же интегрируется с базой данных vCenter для содания реплицированных ВМ на второй площадке. В том числе, если резервная площадка находится в облаке.

RP4VMs-2

Оригинал: Nick Fritsch