понедельник, 30 ноября 2015 г.

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
  • "Наши самые интересные проекты. Байки из склепа" круглый стол


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

среда, 18 ноября 2015 г.

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 ноября!


воскресенье, 15 ноября 2015 г.

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.

пятница, 13 ноября 2015 г.

Дизайн 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.

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