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

Все меньше времени остается до 8го декабря.
Место проведения Best Western Vega Hotel & Convention Center, Москва.
Начало регистрации 10-00, начало мероприятия 10-30

• "Docker в виртуальной среде VMware”, Андрей Коновалов, Инфосистемы Джет, vExpert
• "Правила хорошего тона при дизайне виртуализованного датацентра”, Антон Жбанков, vExpert, Cloud Architect.
• "Работа с инженерной графикой в VMware Horizon View”, Алексей Худяков, Гипрогазочистка, зам. генерального директора
• "Secured Horizon View Architecture" Edward Haletky, vExpert, Cloud Security Architect
• "VMware VSAN как она есть." Николай Куликов, VMware
• vПроекты 2015 года. Накопленный опыт и практические советы. Владислав Кирилин, VMware PSO, Consultant.
• “Встроенные средства обеспечения безопасности VMware vSphere. Сухо и комфортно.” Антон Жбанков, vExpert, Cloud Architect.
• "Плюсы и минусы архитектуры Horizon Cloud Pod." Николай Куликов, VMware
• "Наши самые интересные проекты. Байки из склепа" круглый стол

Регистрация обязательна.

VMware Online Technology Forum

Не пропустите технологический форум VMware Online Technology Forum 25 ноября 12:00 – 16:30 по московскому времени. Это бесплатное online мероприятие, где мы расскажем о новых разработках для единого гибридного облака и других технологических новинках, которые при помощи программно-определяемых технологий позволяют вам ускорить внедрение новых приложений и услуг. Мы расскажем обо всех последних решениях и технологиях, включая продукты NSX, vCloud Air и EVO:RAIL. Кроме того, наши эксперты всегда готовы ответить на ваши вопросы в режиме онлайн.
Зарегистрируйтесь сейчас и получите доступ к общению с партнерами в рамках технологических сессий и практических лабораторных занятий. Технические эксперты VMware, среди которых Джо Багли (VP & CTO, EMEA), Дункан Эппинг (главный технолог), Майк Лаверик (архитектор по интеграции продуктов), Дэвид Хилл (старший архитектор по техническому маркетингу vCloud Air) и Питер Бьорк (главный системный инженер), будут рады ответить на ваши вопросы.


Технологические сессии будут посвящены следующим темам:

Гибридное облако: продвинутые сетевые услуги vCloud Air

Мобильность бизнеса: VMware Horizon – улучшение работы Citrix

Программно-определяемый ЦОД: Инфраструктура: управление центром обработки и хранения данных с помощью vRealize Operations Insight 6.1

Программно-определяемый ЦОД: Новые услуги: облачные приложения и контейнеры

Программно-конфигурируемые сети: использование NSX для расширения сети с участием множественных ЦОД

Зарегистрируйтесь сейчас чтобы услышать:
• Аудиодискуссии с экспертами VMware в режиме реального времени с возможностью задавать вопросы и получать ответы
• Наиболее интересные моменты лабораторных с участием создавших их экспертов VMworld
• Технологические сессии, которые вы выберете сами

Присоединяйтесь к нам в среду, 25 ноября!

Virtual DataCenter Design. Host Sizing. 1

Hyper-Threading

A lot of times I see two contradictory approaches on how to include HyperThreading to sizing. You can just ignore HT at all, and calculate CPU power based on “real” cores, or you can double CPU power because you see twice as much logical CPUs. Unfortunately they’re both wrong. In general you can safely assume HT as +25% CPU, but with some ifs. The main IF is that HT makes most of the efficiency on workloads with a lots of small VMs. Let’s assume we have a dual-way host with 12-core CPUs. That means 24 “real” cores, or 30 “effective” cores. But 24 vCPUs would still be the widest VM you should place on that host.

1 or 2 or 4

Should we choose 2-way or 4-way servers for virtualization? Pretty common problem. So how to solve it?

Target workload is the answer 100% of the cases, and fault domain size. Fault domain in this case is one host. Let’s assume we have a target workload of 200 VMs that can be handled by 10 dual-way hosts with 256GB of RAM each. It’s not a rocket science to deduct that 5 4-way hosts with 512 GB of RAM can handle this workload as well. But! In case of HA event we’ll have double number of VMs affected with services, double number of VMs to restart, increased load on SAN. We have 20% of resources gone from cluster instead of 10% for dual-way servers. And that’ not all, for the planned maintenance we have to evacuate twice as much VMs which leads us to 2-2,5 times more evacuation time.

Latest improvements in CPU design bring us unprecedented number of cores per single socket, making 2-way vs 4-way quarrel even more complicated. Why the hell not 1-way servers with 16-18 cores CPU?

Conclusion. 4-way servers should be used in such cases as:
- Need to use Xeon E7 CPUs instead of E5. But still we can use 4 way servers with 2 sockets filled.
- Need for ultra-wide VMs size of full 2-way server or more, without possibility of application level clustering to split the load.

CPU choice

How to choose CPU in the family – that’s the question. You can try to stick your finger in the sky, use the coin or even a prophecy. But still most of the choices are made without real thinking. Let’s take a view on some basic aspects.
- NUMA. All the current x86 CPUs have the NUMA architecture. So each CPU has it’s own memory instead of globally shared. You have to access another CPU’s memory through the owner which is slower. But that’s not actually the problem, it’s just an issue to consider. Real problem is that you cannot install only half of maximum memory if you don’t install second CPU on 2-way server.
- CPU price, and price per core.
- Software licenses cost.

Let’s assume we chose Intel R1304WT2GS as basic platform for virtualization. So now we should to decide number of CPU to achieve maximum performance / cost efficiency. We are planning to install vSphere Standard ($1940), Windows 2012R2 Datacenter for VMs ($6155 / 2 CPUs) and Veeam Backup Standard ($1116).
Hardware costs $7970 for 1 socket configuration (E5-2670v3 12c + 192 GB), and we need licenses for 1 socket, which would be another $6133 resulting in approx. $14100 total.
2 socket configuration with the very same performance characteristics would cost $6890 (dual E5-2620v3 6с + 192 GB), but software costs double and result is $19160. So with the very same performance characteristics 1-way server is cheaper and a little bit faster due to just 1 NUMA node. Disclaimer – this is not 100% correct calculation, but a mere example of way to calculate.

So why do we need 2-way or even 4-way systems?
- 2 way servers have twice as much maximum memory.
- Single CPU is not enough for really highly loaded applications.
- As a general rule the more cores CPU have – the less is frequency. For an application with core-based licensing such as Oracle DB that can be an issue. For example, 2*E5-2637 v3 (4с, 3.50 GHz) and 1*E5-2667 v3 (8с, 3.20 GHz) have 10% difference in peak performance (28GHz vs 25,6GHz) while core-based licenses would remain the same.

General recommendations:
- Multi-core CPUs are well suited for loads with a lot of lightly to medium loaded VMs. More cores are better.
- The wider VMs are used – the better they perform.
- If you have only a few VMs with applications known for their love for MHz instead of good parallel procession – stick to higher frequency CPUs with less cores.
- Always start you design with single CPU servers. Add second CPU only after a minimum of 5 hosts reached (except of vSphere Essentials) or when you really need more memory that single CPU can support. Or leave second socket for a future upgrade.

Дизайн VDC. Сайзинг хостов. 1

Hyper Threading

Часто встречаются два противоположных и неверных утверждения – HT не надо учитывать, и учитывать надо как полные ядра, т.е. умножать на два.
HT при сайзинге следует учитывать как +25% процессорной мощности. Хост с 2 процессорами по 12 ядер и HyperThreading имеет 24 ядра или 48 потоков, что с указанным коэффициентом дает мощность, эквивалентную 30 ядрам.
Следует отдельно отметить, что максимальный размер ВМ в этом случае должен быть не более 24 vCPU. Hyper-Threading дает максимальный эффект на большом количестве ВМ с малым количеством vCPU.

1 или 2 или 4

Выбор между 2х или 4х процессорными серверами под виртуализацию следует делать исходя из типа нагрузки, планируемой для данного конкретного кластера. Ключевой показатель – это размер домена отказа. Т.е. насколько виртуальная ферма и продуктивная нагрузка пострадает от отказа единичного сервера. Предположим, под 200 продуктивных ВМ нам требуется 10 2х-процессорных серверов с 256 ГБ памяти. Очевидно, что их можно заменить 5ю 4х-процессорными серверами с 512 ГБ памяти без потери производительности. Однако это означает удвоенное количество ВМ на сервер, и соотв. двойной объем памяти ВМ в нагрузке. При выходе одного хоста из строя и срабатывании HA мы имеем разницу в два раза по количеству ВМ и продуктивных сервисов в рестарте, увеличенную нагрузку на СХД при рестарте ВМ. А также выход двойного объема ресурсов из кластера – 20% (4х) против 10% (2х). При запланированном простое хоста (под регламентные работы) двойное количество ВМ требуют миграции, что в 2-2.5 раза увеличивает время самой миграции.

С учетом роста количества ядер в процессорах для 2х процессорных серверов, возникает смысл в переходе даже на 1-процессорные серверы.

Итого. 4х процессорные серверы под виртуализацию рекомендуются в следующих случаях:
- необходимость использования иного семейства процессоров (Xeon E7, а не E5) под продуктивную нагрузку. В этом случае 4х процессорный сервер может быть с 2мя установленными процессорами.
- необходимость в размещении сверхшироких ВМ, шириной в полный двухпроцессорный физический сервер или более, при невозможности или экономической неэффективности кластеризации приложения с разделением нагрузки на ВМ меньшей ширины.

Выбор процессора

Выбор процессора внутри семейства затрагивает сразу несколько параметров, которые необходимо рассмотреть.
- NUMA. Все современные x86 процессоры имеют архитектуру NUMA. Т.е. у каждого процессора в сервере есть своя память, и обращение к чужой памяти напрямую невозможно. Иными словами, если в 2х процессорном сервере установлен 1 процессор, то памяти можно установить только половину от максимально возможной.
- Стоимость самого процессора и стоимость в расчете на ядро.
- Стоимость лицензий на системное и прикладное ПО и модель лицензирования.

Предположим, что в качестве платформы выбран сервер Intel R1304WT2GS, и теперь стоит вопрос сколько и каких процессоров в него установить для максимальной экономической эффективности. В качестве ПО предполагается vSphere Standard ($1940), Windows 2012 R2 Datacenter ($6155 / 2 CPU), Veeam Backup Standard ($1116).
Итак, для конфигурации 1xE5-2670v3 (12c) и 192 GB сервер будет стоить в сборе $7970 и потребует по 1 лицензии ПО (лицензирование по сокетам), что дает $6133 за софт или $14100 за сервер.
При выборе варианта с 2мя процессорами E5-2620v3 (6с) стоимость самого сервера уменьшается до $6890, однако стоимость лицензий удваивается и дает $19160. /* расчет не является 100% корректным и призван лишь проиллюстрировать сам принцип
При равной мощности и объеме памяти двухпроцессорный сервер обладает большей ценой (спасибо лицензиям) и потенциально меньшей производительностью за счет 2х узлов NUMA.

Так зачем же нам нужны двухпроцессорные и, тем более, четырехпроцессорные серверы?
- В двухпроцессорном сервере вдвое больше максимальный объем памяти.
- Одного, даже топового, процессора может не хватать по вычислительной мощности.
- Многоядерные процессоры не всегда имеют высокую тактовую частоту, а стоимость лицензий на системное ПО значительно ниже стоимости прикладного ПО, лицензируемого по ядрам. Например 2*E5-2637 v3 (4с, 3.50 GHz) и 1*E5-2667 v3 (8с, 3.20 GHz) имеют 10% разницу в пиковой производительности (28GHz vs 25,6GHz), что может стать решающим фактором для выбора процессоров для нагруженной Oracle DB.

Общие рекомендации:
- Многоядерные процессоры хорошо подходят для большого количества ВМ малой или средней загрузки.
- Чем более широкие ВМ используются – тем лучше они работают на многоядерных процессорах.
- Если машин немного и прикладное ПО плохо работает с параллельными потоками, предпочитая частоту, то выбор должен осуществляться в пользу процессоров с большей частотой в ущерб количеству ядер.
- Надо всегда начинать с варианта с одним процессором, и добавлять второй только при нехватке памяти, или оставлять второй процессор как опцию под будущий апгрейд виртуальной фермы.

VMware User Group Russia - Winter 2015 Регистрация

Друзья, рад сообщить о новой встрече русскоязычного сообщества VMware в Москве 8го декабря.
Программа мероприятия в процессе подготовки. И в этот раз у нас будет еще больше отличных докладов без маркетинга, чем обычно. Желающие рассказать о своем опыте и граблях, или напротив, о счастье и невыносимой легкости с VMware - у вас есть все шансы!



Включайтесь в нашу онлайн-группу в Facebook: VMUG.RU

Что такое Big Data и с чем ее едят?

CNews Big Data from Anton Zhbankov

VDI Fails

VDI Fail 1. Никто не понимает как лицензируется Microsoft.
Поговорите с 10 людьми в Microsoft как лицензировать VDI - получите 11 разных ответов.
VDI Fail 2. Не тот продукт по неправильной причине.
На основе чего вы выбираете платформу VDI? Только лишь потому что кто-то дал вам бесплатных лицензий или потому что гипервизор от того же вендора?
VDI Fail 3. Недостаточно экспертизы, чтобы проект взлетел.
Хватит ли у вас экспертизы по всем подсистемам, задействованным в проекте, или он завалится как колосс на глиняных ногах?
VDI Fail 4. VDI как решение проблемы планшетов.
Если планшеты только как почти бесплатная опция вдобавок, то почему бы и нет? Но приложения для мыши и клавиатуры могут очень плохо работать на тач-интерфейсе.
VDI Fail 5. Покупка на будущее.
Будете ли вы покупать мини-вэн на большую семью, если вам 20 лет? К моменту, когда он реально понадобится, может пройти 5, 10 лет. А он может и не понадобиться вовсе.
VDI Fail 6. Плохие привычки из прошлого.
Прошлые привычки в новом окружении способны похоронить весь проект.
VDI Fail 7. Плохое исследование текущей ситуации.
Нет ничего хуже, чем в разгар миграции обнаружить, что половина пользователей не может использовать критически важные приложения, о которых вы были даже не в курсе.
VDI Fail 8. Не знать когда остановиться.
Не всем нужны VDI машины. Они нужны почти любой компании с числом пользователей более 50, но какой доле этих пользователей они нужны, 5%? 10%?

Brian Madden. The VDI Delusion.

3D и VDI

Horizon 6.1 поддерживает несколько режимов работы с ускорением 3D графики в виртуальных машинах:

Soft 3D
Не требует аппаратного ускорителя, задействуется мощность центральных процессоров. В ВМ устанавливается драйвер виртуального 3D ускорителя. Поддерживаются DirectX 9.0c и OpenGL 2.1.

vSGA
Virtual Shared Graphics Acceleration - режим разделения аппаратного ускорителя между множеством ВМ. Используется тот же драйвер, что и в Soft 3D. Более того, если режим ускорения для ВМ выставлен в Automatic, то возможно автоматическое переключение работы между Soft 3D и vSGA, например при живой миграции на хост без аппаратного ускорителя. В этом случае пользователь, разумеется, может заметить значительно снижение производительности 3D.

Рассчитать максимальное количество ВМ на ускоритель довольно просто. Например, установлен ускоритель с 16ГБ памяти, а для ВМ выделяется 512МБ видео памяти. Из 512 половина, т.е. 256 резервируется в памяти видеоускорителя. 16384 / 256 = 64.
Машины обслуживаются по принципу "кто первый встал - того и тапки". Т.е. 65я и остальные ВМ будут автоматически переключены в режим Soft 3D (Automatic), или не будут включены вовсе (Hardware).

Как vSGA, так и vDGA поддерживают до 8 ускорителей на хост.

vDGA
Virtual Dedicated Graphics Acceleration - режим прямого проброса графического ядра в ВМ. В отличие от предыдущих двух режимов используется драйвер от производителя ускорителя (на сегодня только карты nVidia). Поддерживаются DirectX 9, 10, 11, OpenGL 2.1, 3.x, 4.1x, CUDA.
В данном режиме графическое ядро целиком выделяется в ВМ и не разделяется между ВМ. Количество ВМ в режиме vDGA определяется количеством графических ядер в установленных ускорителях. Также в силу прямого проброса аппаратных ресурсов ВМ лишаются возможности vMotion.

nVidia GRID vGPU
Отдельной пунктом идет фирменная технология nVidia vGPU, представляющая собой гибрид vSGA и vDGA, но только на картах nVidia Grid. Так же, как и в vDGA требуется нативный драйвер nVidia, но так же как в vSGA идет разделение ядер между ВМ. Каждое ядро Grid может быть поделено на макс 8 ВМ. vGPU предлагает возможности CUDA и Direct X / OpenGL, но значительно дешевле на пользователя. Т.е. vDGA с 100% выделенным на пользователя ядром будет нужна High End пользователям со значительными потребностями, как например проектирование и видеомонтаж, а vGPU поможет дизайнерам за счет использования аппаратного ускорения работы с графикой. Отдельное требование vGPU - vSphere 6, в то время как vDGA может быть использована в 5й версии.

"IT vs Private Cloud" Paradox

Many years we speak of cloud computing, and I have been selling private cloud for a long time. But we’re still in very early stages of private cloud adoption. Why?

Answer was a surprise even for me. Private cloud is not something IT department need.

Every commercial company is a manufacturer. Yes, I’m not mistaken. Even small nail salon is a manufacturer. They produce profit. Just for argument simplicity let’s talk about profit as income minus costs (capital expenses and operational expenses including salaries). As we know dollar saved is dollar earned and therefore we’re driving costs down.
But where does cloud part come in you ask? Just wait for it.

Let’s take a look at allegedly most interested in cloud employees – IT department. Department includes IT management and administrators / specialists, IT assets in both hardware and software. And budget. As a rule, IT budget looks like some kind of financial black hole actively consuming sums with many zeroes. It’s almost impossible to understand financial flows and how it reflects on actual IT services. Here comes private cloud with financial visibility, service catalogs and measured service – so we can actually say how much one mailbox costs. We’re in CFO dream now.

But IT department says: NO!
RLY? WTF?

Ok, let’s take another look on IT department, completely unrelated to technology – motivation.

What average IT admin wants? Pretty simple answer: high-tech toys, arcane techno mage status and significance. Who should choose new servers/storage system? Of course ME, it’s MINE! No, it’s not. It’s a tool, not a toy, and cloud brings us standards for systems. More than that, cloud makes admin interchangeable, the role does not bear any arcane knowledge anymore. Cloud admin is highly qualified in several areas – yes, but I don’t really see a lot of admins after 30 who really want to study something new and adapt. People want stability and “expert” title. What they do not want is to remain students till grandchildren.

What does IT management want if we skip part with kickbacks and gray schemes on procurement? Pretty the same – influence and significance. Which directly translates to number of employees and total systems cost. Plus a budget to control themselves, with no one looking over the shoulder. Each new new employee reporting bring costs, and each new admin add NO to the cloud question.

What cloud makes with IT budget? Black hole splits into separate services with measured costs, and CFO can now compare internal services with available on the open market. Which can be not in internal services favor. Cloud brings financial visibility to financial management and line business managers as well as how to spend budget in accordance with company targets.

-       What, board will be able to see how I spend my budget?! – direct quote from one CIO I met.

It’s not a paradox, we now understand why IT don’t like cloud. But what should we do? I don’t have that answer.

Департамент ИТ против частного облака

Департамент ИТ против частного облака from Anton Zhbankov

Транспортные протоколы резервного копирования VMware

Для резервного копирования виртуальных машин используется несколько транспортных протоколов – NBD, SAN, HotAdd. 

NBD (Network Block Device) является наиболее универсальным и доступным для любых видов СХД и окружений. При его использовании поток данных с СХД проходит через гипервизор ESXi и направляется на сервер резервного копирования по локальной сети. На практике его не рекомендуют использовать, если есть возможность работы с протоколами SAN и HotAdd, превосходящими его по разным отзывам от двух до десяти и более раз по скорости передачи данных.

SAN – используется при прямом подключении сервера резервного копирования в сеть хранения данных. Для его использования серверу РК необходим прямой доступ к томам с VMFS, что накладывает требования на конфигурирование хоста и ограничение доступа к нему. Для Windows необходимо отключить автоматическую инициализацию дисков во избежание перетирания сигнатур и метаданных VMFS. И разумеется никто не хочет, чтобы чьи-то неумелые или напротив, опытные, но зловредные потерли сами данные. Возможно предварительно их утащив.

В случае с Fiber Channel сетью сервер РК должен быть физическим и физически подключен в оптическую фабрику. В процессе резервного копирования гипервизор сообщает какие блоки необходимо забирать с тома VMFS и сервер РК читает их с СХД самостоятельно. Скорость резервного копирования ограничена лишь нагрузкой на СХД и способностью сервера РК справиться с потоком данных. Влияние гипервизора в данном случае минимально.

Несмотря на очевидное преимущество SAN протокола, не все так просто. Идеальным вариантом он является только при восстановлении толстых (thick) дисков, но наихудшим для тонких из-за постоянных вызовов API дискового менеджера (AllocateBlock, ClearLazyZero). В случае восстановления тонких дисков предпочтительно использовать NBD.

Также при восстановлении по SAN необходимо отключать CBT. Также не поддерживается запись в redo логи (снапшоты), восстановление идет только базовых дисков.
Особая тонкость в том, что размер диска должен быть точно кратен размеру блоку VMFS, иначе последний блок не сможет быть записан и весь процесс упадет с ошибкой "Invalid Argument". Для обхода этой проблемы софт резервного копирования должен дописать в конец блока недостающие нули.

HotAdd – способ, при котором к специальной виртуальной машине-прокси на горячую подключаются виртуальные диски целевой виртуальной машины, после чего прокси машина пересылает данные по локальной сети на сервер РК. Прокси может выполнять компрессию и дедупликацию данных при пересылке, в зависимости от используемого продукта РК. Роль прокси и сервера РК может быть также совмещена. Несмотря на использование дискового стека гипервизора для доступа к данным, скорость на практике практически равна варианту SAN.

В случае VMFS3 располагайте прокси на томах с большим размером блока VMFS, чтобы быть в состоянии бэкапить и восстанавливать очень большие файлы. Для VMFS5 размер блока унифицирован и эта рекомендация более неактуальна.

Поскольку при работе HotAdd создаются redo логи, не удаляйте подключенную ВМ пока не завершится процесс резервного копирования. Иначе гипервизор потом не сможет правильно обработать redo логи и диски от прокси придется отключать вручную. (!) Не удаляйте снапшоты до окончания резервного копирования (!).

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

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

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

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

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

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

VMware User Group 2015

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

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

vVNX Community Edition

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

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

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

Техническое описание 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