четверг, 9 февраля 2017 г.

OpenStack как религиозная секта

После 14 лет работы с виртуальными машинами, и 10 лет работы с промышленными платформами виртуализации я решил разобраться в OpenStack. Вокруг только и разговоров о нем. VMware больше не нужна, VMware скоро умрет и останется только OpenStack. Но по мере знакомства со всем стеком и с сообществом все больше у меня появлялась убежденность, что я имею дело с сектой.

OpenStack - технология, перечеркивающая и противопоставляющая себя привычным подходам и продуктам. Для всего изобретается свой, особый, православный подход. Зачастую (причем скорее как правило) деятели, связанные с OpenStack - люди достаточно асоциальные даже по меркам обычных ИТ-шников. В абсолютном большинстве случаев поклонник OpenStack видит лишь один правильный путь - OpenStack. Остальные пути и технологии считаются заведомо недостойными изучения ересями.

В рамках OpenStack существует свой, отдельный язык. Забудьте про сеть - это Neutron. Забудьте про систему хранения - это Cinder. Вся индустрия уже многие годы использует примерно устоявшиеся термины, и после VMware начать изучать Hyper-V не составит значительного труда. В случае с OpenStack надо начать с изучения нового языка, что еще раз подчеркивает раскол между "обычными" и "просветленными".

В рамках проектов по OpenStack приверженцы технологии неспособны к самокритике и здравой оценке ситуации. Провальные проекты - это всегда вина недостаточно веровавших в них заказчиков. Пропало несколько тысяч виртуальных машин - OpenStack не может быть виноват. Всегда виноват конечный потребитель.

При разговоре речь идет не о технологиях, она ведет о вере. "Ты должен верить" - прямая цитата одного из известных на рынке деятелей.

HP увольняет команду разработки OpenStack, Мирантис сокращает треть сотрудников. Ну и что, это же не имеет отношения к вере в.

Встречая любителя OpenStack на любом форуме, задумайтесь о его аргументации. Она сбивчивая, постоянная апелляция к неведомому "прогрессивному" человечеству и полное игнорирование реалий индустрии. TCO? Риски? Стоимость поддержки? Из всех аргументов можно услышать только "бесплатно" и "зато я могу допилить под себя". Ему не нужны успешные проекты, ему не нужны реальные результаты, это просто вербовка новых адептов в новую, измененную реальность.

Основа сообщества OpenStack - преимущественно "техногики", люди, которые слабо разбираются в глубоких технических моментах, но очень любят модную технологическую шумиху и обожают рассуждать/вариться в ней. Техногики сейчас практически везде и именно им надо сказать спасибо за проталкивание маркетинговых идей, которые не выдерживают никаких технических аргументов. Собственную техническую неграмотность техногики прикрывают лозунгом о мифической силе «сообщества» и миллионами глаз, которые теоретически найдут ошибку в открытых кодах.

К вниманию также предлагаются перлы докладчиков с OpenStack Day в 2015.

четверг, 2 февраля 2017 г.

Highload 2016. Что уже умеют промышленные СХД. Видео


Друзья, по многочисленным просьбам выкладываю видеозапись доклада, скажем спасибо за нее организаторам!



среда, 7 декабря 2016 г.

nBeers Engineers 2016-1

Коллеги, мы решили сделать маленькое теплое и ламповое мероприятие в неформальном стиле.

nBeers Engineers - чтобы ИТ-инженеры, архитекторы и мастера на все руки могли пообщаться за кружечкой пива.
А мы в процессе заодно расскажем и даже покажем нашу новую версию Nutanix OS 5.0 Asterix.

13 декабря с 18-30 в баре "Пес Борода" (метро Трубная, ул. Трубная 15)

Поскольку мероприятие будет только для своих и бар полностью закроется для обычных посетителей, большая просьба заранее зарегистрироваться.

Регистрация закрыта.

вторник, 18 октября 2016 г.

VMworld EU 2016

STO8165, John Nicholson (@Lost_Signal)
VSAN Networking Deepdive

* Используйте мультикаст флад только для выделенных под VSAN VLANов
* Если у вас несколько кластеров VSAN в одном VLAN - поменяйте им мультикаст адреса, чтобы каждый кластер имел свой уникальный. Или разнесите по разным VLAN
* Не делайте VSAN поверх L3 если не уверены зачем это делаете
* Для больших и нагруженных кластеров VSAN очень чувствителен к степени переподписки аплинков. В качестве средней температуры можно взять 4 к 1, но для каждого случая надо смотреть конкретнее
* Идеальный вариант коммутаторов для VSAN - со связями запад-восток. Осторожнее с Cisco FEX - там все через аплинк
* Jumbo frames не имеют большого значения для VSAN
* Локализация ввода-вывода (data locality) не имеет большого смысла для VSAN, ведь каждая запись должна все равно идти через сеть. /* Nutanix смотрит на это утверждение с удивлением.
* Начиная с 6.5 поддерживаются микрокластеры из двух узлов с прямым подключением между узлами (кросс-кабелем).
* Растянутый кластер требует VSAN Enterprise и поддерживается с сетями 10G 5ms RTT. 1 Гбит в целом поддерживается, но не рекомендуется.
* Для растянутого кластера требуется cluster witness. Он может быть виртуальной машиной или ESXi хостом (для него не требуется лицензия). Сетевое подключение - не менее 100 мегабит. /* Nutanix снова смотрит с удивлением, обходясь 2 мегабитами.
* Дедупликация идет фиксированными блоками 4 кб для All-Flash. Гибридный VSAN не поддерживает дедупликацию. /* Nutanix махнул рукой, ушел

INF8701, Brett Guarino
vSphere Core 4 Performance Troubleshooting and Root Cause Analysis, Part 2: Disk and Network

* VMXNET драйвер работает в ring 1, E1000 - ring 2
* Почти все сводится к esxtop
* Хотите при помощи esxtop анализировать сеть? Купите БОЛЬШОЙ монитор
* Ключевые показатели при анализе сети в vSphere
- используемые физические аплинки для каждого vmnic
- фактическая скорость на vmnic
- счетчик пакетов и средний размер пакета на vmnic
- отброшенные пакеты на vmnic
- фактическая скорость на физическом интерфейсе
- счетчик пакетов и средний размер пакета на физическом интерфейсе
- отброшенные пакеты на физическом интерфейсе
* Исследование дисковой системы - это куда больше веселья, чем сети :)
* Ключевые показатели - IOPS, задержки и фактическая скорость в мегабайтах в секунду
* Ситуации с DAVG/KAVG:
- низкий/низкий - идеально
- низкий/высокий - перегруженный хост
- высокий/низкий - перегруженная СХД
- высокий/высокий - проблема и там, и там. Но иногда слишком перегруженная СХД ведем к перегрузке дискового стека хоста.
** остаток доклада по дисковой системе фактически повторяет мою презентацию на VMUG 2014 в упрощенном виде. (http://blog.vadmin.ru/2014/06/vmug-2014.html)


VIRT8530, Rob Girard, Shawn Meyers
Deep Dive on pNUMA and vNUMA - Save Your SQL VMs from Certain DoomA!

* SQL не очень работает на AMD NUMA. Ставьте Intel. /* речь, разумеется, о широких SQL
* Неправильная конфигурация NUMA может вести к падению производительности до 40%
* По умолчанию vNUMA включается только при 9+ vCPU ВМ.
- Если у вас 4 или 6-ядерные процессоры и ВМ с большим количеством vCPU, чем ядер на процессоре - у вас будут проблемы с NUMA
- Можно исправить при помощи numa.min.vcpu для ВМ
* Лучший сайзинг ВМ - это много сокетов по 1 ядру. В этом случае автоматика отработает и ситуация будет близка к идеальной
- как только вы измените количество ядер на отличное от 1, конфигурация vNUMA зафиксируется
- vSphere определит топологию NUMA на первой загрузке. Это фиксируется в .vmx
- Используйте более одного ядра на сокет только для приложений с лицензированием по сокетам
- Если вы уверены в том, что делаете - сделайте сайзинг по границам узлов
* Идеальный сайзинг ВМ по vCPU - число, кратное одному узлу NUMA. Т.е. для 12-ядерного узла это 1, 2, 3, 4, 6, 12. На практике 3 vCPU ВМ работает на 6-ядерном процессоре лучше, чем 4vCPU.
* vSphere 6.5 позволяет сделать двойной финт - обмануть приложение по лицензированию, и при этом технически использовать автосайзинг NUMA
- numa.vcpu.followcorespersocket = 0 (по умолчанию)
- если установить в 1, то вернется старое поведение
* Расширенные настройки. !!! Опасно !!! Только если вы действительно понимаете что делаете
- numa.vcpu.maxPerVirtualNode = 8 (по умолчанию) - для расширения ВМ на дополнительные NUMA узлы
- numa.vcpu.preferHT = False (по умолчанию) - использовать потоки HT вместо дополнительных узлов NUMA. Для некоторых нагрузок важнее остаться в пределах одного узла.
- numa.vcpu.min = 9 (по умолчанию) - когда vNUMA начинает использоваться
- numa.autosize = False (по умолчанию) - пересчитывать топологию NUMA каждый раз при загрузке ВМ. Рекомендуется в True.
- numa.autosize.once = True (по умолчанию) - рассчитывать топологию NUMA при первой загрузке ВМ. Рекомендуется в False.
- numa.autosize.cookie = [автогенерируемое] - автоконфигурация vNUMA. 160001 = 16 сокетов, 1 ядро
- numa.autosize.vcpu.maxPerVirtualNode = [автогенерируемое] - сколько ядер на каждый узел NUMA при автосайзинге.
* Если в .vmx присутствуют numa.autosize.vcpu.maxPerVirtualNode или cpuid.coresPerSocket - автосайзинг не используется
* CPU HotAdd для виртуальной машины отключает vNUMA
* Memory HotAdd работает по разному
- HW ver 8-10 добавляет память в vNUMA node 0, что приводит к дисбалансу
- HW ver 11 балансирует память между vNUMA узлами
* Настройки vNUMA на уровне хоста в абсолютном большинстве случаев НЕ НАДО трогать.
* Перед тем как винить vNUMA проверьте все остальное.
* Не делайте 4-сокетную ВМ на 2-сокетном сервере. 

понедельник, 4 июля 2016 г.

What will virtualization look like in 10 years?

Let's define "virtualization" for the start. Virtualization is abstraction from hardware itself, hardware microarchitecture. So, when we talk about virtualizion - it's not just about server hypervisors and VMware virtual machines. Software defined storage, containers, even remote desktops and application streaming - all of these are virtualization technologies.

As of today, mid of 2016, server virtualization is almost stalled in progress. No breakthroughs for last several years. Honing hypervisors for perfection, challengers follow the lead and difference is less and less with each year. So vendors fight now in the ecosystem - management, orchestrators, monitoring tools and subsystems integration. We are now surprised when someone wants to buy a physical server and install Windows on it instead of hypervisor. Virtual machines are no longer an IT toys, it's an industrial standard. Unfortunately sensible defense
scheme (from backups to virtualization-aware firewalls) is not yet standard feature.

Software Defined Everything, or we can say Virtualized Everything, grow enormously. Most of the corporate level storage systems are almost indistinguishable from standard x86 servers except of form factor. Vendors do not use special CPUs or ASICs anymore, putting powerful multicore Xeons in controllers instead. Storage system of today is actually just a standard server with standard hardware, just with a lot if disks and some specialized software. All the storage logic, RAIDs, replication and journaling is in software now. We blur the storage/server border even more with smart cache drivers and server side flash caches. Where the server ends and storage begins?

From other side we see pure software storage systems, never sold as hardware, which do not have hardware storage heritage and architecture traits. Take any server, put some disks and RAM as you please, install an application and voila! You lack space, performance or availability? Take another server, and another and maybe a couple more. It begins to look even more interesting when we install storage software in virtual machine or even make it a hypervisor module. There are no servers and storage apart - this is a computing/storage unified system. Hyperconverged infrastructure we call it. Virtual machines are running inside, virtual desktops and servers. More than that, users can not tell if they're in dedicated VM or terminal server session or is just a streamed application. But who cares when you can connect from MacDonalds just across a globe?

Today we talk about containers, but it's not a technological breakthrough. We knew about them for years, especially ISPs and hosting providers. What will happen in near future - is a merge of traditional full virtualization and containers in a single unified hypervisor. Docker and their rivals are not yet ready for production level corporate workloads. Still a lot of questions in security and QoS, but I bet it's just a matter of couple of years. Well, maybe more than a couple, but 10 is more than enough. Where was VMware 10 years ago and where are we now in terms of server virtualization?
Network control plane is shifting more and more towards software, access level switching blurs more and more. Where is your access level when you have 100 VMs switching inside a hypervisor never reaching physical ports? The only part really left for specialized hardware is high speed core switches or ultra-low latency networks like Infiniband. But still, this is just a data plane, control plane lives in the Cloud.

Everything is moving towards the death of general OS as we know them. We don't really need an OS actually, we only need it to run applications. And applications are more and more shifting from installable to portable containers. We'll see hypervisor 2.0 as new general OS and further blur between desktop, laptop, tablet and smartphone. We still install applications, but we already store our data in the cloud. In 10 years container with application will be moving between desktop, smartphone and server infrastructure as easy as we move now virtual machines.

Some years ago we had to park floppy drive heads after we're finished, teenagers of today live with cloud, teenagers of tomorrow will have to work hard to realize what is application/data link to hardware.

понедельник, 27 июня 2016 г.

Что ждет средства виртуализации через 10 лет?

Для начала хочется определить понятие «средства виртуализации». Виртуализация по сути представляет собой абстрагирование от аппаратных средств, от их микроархитектуры. Поэтому говоря о средствах виртуализации, следует понимать, что это далеко не только серверная виртуализация и виртуальные машины VMware. Программно-определяемые СХД, контейнерные технологии, удаленные рабочие столы и потоковая доставка приложений – это тоже виртуализация.

В середине 2016 года серверная виртуализация практически остановилась в развитии. Никаких прорывных технологий уже не ожидается, постепенно уравниваются по возможностям гипервизоры. Битва между поставщиками происходит уже в средствах мониторинга и управления, интеграции со смежными подсистемами. Покупка физических серверов и установка на них скажем Windows уже вызывает удивление, это редкость. Мы уже привыкли к виртуальным машинам, это уже индустриальный стандарт. К сожалению пока еще не является индустриальным стандартом продуманная концепция защиты - начиная от правильно построенной системы резервного копирования и заканчивая умным антивирусом и файрволлами, понимающими про виртуализацию.

Все более набирает обороты концепция Software Defined Everything, программно-определяемое все или, по сути, виртуализованное все. Большинство корпоративных СХД уже практически ничем не отличаются от серверов, кроме форм-фактора исполнения. Производители уже отказались от специальных процессоров, все крутится на x86. Все больше производителей отказываются от сопроцесоров и специализированных ASIC'ов, перекладывая задачи на могучие Intel Xeon последних поколений. Современная СХД корпоративного класса уже по сути является стандартным сервером со стандартным оборудованием, просто с большим количеством жестких дисков. Вся логика в программном обеспечении. Граница между серверами и СХД размывается еще сильнее при помощи умных драйверов, управляющих содержимым кэш-памяти, и флэш-кэшами, устанавливаемыми в серверы. Где кончается сервер-потребитель и начинается СХД?

С другой стороны наступают чисто программные СХД, не имеющие архитектурного наследства аппаратных. Возьми любой сервер стандартной архитектуры, поставь столько дисков и памяти, сколько считаешь нужным, а дальше просто поставь софт в качестве обычного приложения. Не хватает производительности, пространства, отказоустойчивости? Добавь еще один сервер, потом еще один, и сколько тебе нужно. Еще интереснее становится, когда этот софт мы устанавливаем в виртуальные машины или делаем частью гипервизора. Вычислительная система и система хранения теперь неразличимы, они одно целое - гиперконвергентная система. А внутри работают виртуальные серверы и виртуальные десктопы. Причем пользователи сами не понимают, работают они в выделенной виртуальной машине или в сессии терминального сервера. На виртуальные десктопы доставляются потоковые приложения, к десктопу можно подключаться с планшета из МакДональдса или из пробки на дороге через мобильный интернет, или из гостиницы через половину земного шара.

Идет постепенное принятие всей индустрией ИТ давно известной среди хостинг-провайдеров технологии контейнерной виртуализации. В дальнейшем мы будем наблюдать слияние в единой системе и платформе как полной виртуализации, так и контейнерной. Новые и модные контейнеры Docker и сопутствующие им не готовы для работы в корпоративном секторе – недостаточно проработаны вопросы обеспечения качества обслуживания, информационной безопасности, но нет никаких сомнений в их готовности через 10 лет.
Уровень управления сетью все больше перемещается в программный, размывается сетевой уровень доступа – ну а что ему еще делать при коммутации внутри гипервизора под сотню ВМ? Единственным прибежищем аппаратных специализированных архитектур будут оставаться высокоскоростные терабитные коммутаторы уровня ядра сети или специализированные коммутаторы со сверхнизкими задержками, как например Infiniband. Но и у тех останется уровень данных и сверхскоростные матрицы коммутации, в то время как уровень управления будет жить в облаке.

Все идет к смерти ОС общего назначения, как мы их знаем. Ведь по сути нам не нужна ОС, нам нужны лишь приложения, а они все больше и больше виртуализуются и упаковываются в контейнеры. Вместо ОС нас ждет гипервизор нового поколения. Что в конечном итоге выльется в полное размытие понятия «персональный компьютер» - это будет и планшет, и десктоп, и даже смартфон. Сегодня мы все еще устанавливаем приложение и привязываем его к ОС, хотя данные все чаще храним в облаке. Но через 10 лет можно быть уверенным, что контейнер с приложением будет просто мигрировать между этими устройствами так же легко, как сейчас между серверами переезжает виртуальная машина.

Мы когда то парковали головки флоппи-дисководов после работы, сегодняшние школьники работают с облаками. Завтрашние школьники не будут понимать – как это, есть привязка приложения и данных к устройству.