Monday, October 9, 2017

LibVirt плагин или дешевая виртуализация

Цели?
Добавить поддержку libVirt как плагин к cloudify. Это позволит добавить поддержку низкоуровневых провайдеров виртуализации без удаленного доступа, таких как:
  • KVM,
  • QEMU,
  • Xen
  • Virtuozzo
  • VMWare ESX
  • LXC
  • и BHyve.
Почему дешевая?
  • Мы можем запустить на любом оборудовании, даже самом дешевом, кластер не нужен.
  • Поддерживает что угодно где возможен запуск QEmu и можно запустить на arm/x86/powerPC/… или на чем угодно, что нужно в данный момент?
  • Или LXC? Без эмуляции или виртуализации…
  • Не нужна дорогая лицензия на VMWare vSphere/vCloud Director, только минимальная esx лицензия.
Изначальный план.
Создать для каждого libVirt объекта свой тип, например для pci устройства, интерфейса или домена.

А если немного подумать?
Не, в таком виде не взлетит. Только потратим время с подобным планом, так как нужно будет предоставить полную документации для всех типов в новом виде, и обосновать почему такое представление гораздо лучше стандартного. Поэтому новый план такой:
  • Поддержка на уровне xml шаблона для верхнего уровня описаний объектов в libvirt, который будет распространяться вместе с плагином, пользователю нужно будет только предоставить значения для подстановки в шаблон.
  • Реализовать простейший пример с несколькими виртуальными машинами объединенными в одной сети.
  • Реализовать в каком-то виде получение адресов машин для подключения через ssh.
  • Проверить идею с каким нибудь провайдером отличающимся от qemu.
Почему реализовывать именно ввиде плагина для cloudify?
Это наиболее знакомый мне продукт для оркестрации виртуальных окружений. Основные его достоинства возможность применения для управления и мониторинга любых систем начиная от систем IoT(internet of things) до крупных промышленных объектов. В базовой поставке есть примеры от управления классической инфраструктурой облаков до телекоммуникационной инфраструктуры, как SDN(software defined networks) когда работаем с виртуализированными сетями и соединениями до NS(Network Service, сервисы предоставленные инфраструктурой) и VNF(virtualized network functions, сервисы предоставленные через отдельные виртуальные машины запущенные на инфраструктуре), когда мы переходим на следующий уровень где каждый объект представляет собой уже сложный функционал, такой как интроспекция трафика, антивирусные продукты или управление высокоуровневый маршрутизацией и адресацией(MPLS/BGP или классический dhcp), когда нужно предоставить полный пакет сервисов для конечного клиента определенный по базовым шаблонам с возможностью широкого изменения в зависимости от потребностей клиента. Как пример подобных низкоуровневых протоколов может служить netconf или загрузка на устройство конфигурации через классический ssh доступ. Продукт представлен двумя версиями: полностью свободной open source(apache2) версией которая содержит полностью работоспособную минимальную установку, позволяющую использовать весь функционал, предоставляет возможность управлять инфраструктурой и получать все метрики с инфраструктуры и предоставляющая RestApi для работы с управления и мониторинга. И платная версия предоставляющая расширенные возможности управления и управления правами доступа и объединения нескольких серверов менеджмента в кластер, дополнительные плагины и дополнительные функции и web ui. Более подробно о различиях и предоставляемых дополнениях лучше уточнять на сайте.

Для управления не большими инфраструктурами достаточно и функционала доступного в open source версии, api достаточно простой и можно реализовать клиента который удовлетворяет всем потребностям необходимым для того чтобы попробовать и оценить технологию.

В классическом виде существует два вида установок:
  • Распределённая когда существует выделенный сервер с которого выполняются все установки, и возможно выполнение одновременно нескольких независимых установок.
  • И более простой вариант, когда используя полностью те же описания установки, можно запустить все с текущего хоста, так мы теряем возможность выполнять сразу несколько установок и использовать функционал вида масштабирования и восстановления, но позволяющий отследить все процессы происходящие в системе.
А теперь термины используемые в продукте:
  • Blueprint - описание установки, в универсальном варианте не содержит никаких паролей и настроек конечных компонентов, только их типы и взаимосвязи. Используется yaml в формате Tosca, по-сути это список входных данных(inputs), результирующие данные(outputs), которые содержат информацию необходимую для обслуживания, например автоматически сгенерированные пароли и адреса элементов в инфраструктуре, и список объектов для которых указан их тип и зависимости. Для каждого типа через плагин реализовать необходимы инфраструктурных действия(создать машину или сеть, загрузить машины и выполнить скрипты инициализации cloudinit), или указать какой скрипт нужно выполнить(Bash/Python/PowerShell) на текущем хосте или удаленном. Реализованы плагины для всех коммерческих инфраструктур: Aws, OpenStack, vCenter, и плагины для запуска скриптов/команд на удаленном хосте.
  • Deployment - полное описание того что мы хотим получить с заполненными пробелами в желаемой конфигурации, такими как пароли и при желании изначальное количество компонентов каждого типа.
  • Execution - когда мы уже получили полные данные о состоянии нужной нам инфраструктуры, мы можем вызывать install execution для создания нужной нам инфраструктуры(до этого было только описание без реального исполнения). После завершения которой продукт начинает автоматически мониторить состояние инфраструктуры до момента когда мы вызовем uninstall, когда все будет откачено до первоначального состояния. Между циклами install/uninstall система автоматически если это описано в blueprint масштабирует и восстанавливает компоненты при сбоях. При желании все эти действия можно выполнить принудительно или вызывать вами описанные действия, например вы описали процесс перевода в режим пониженного использования ресурсов и хотите по какому-то внешнему событию выполнить его.
Как следствие нам нужно реализовать наш собственный плагин/дополнение которое будет описывать действия по созданию домена и сети в рамках libVirt. Можно конечно обойтись скриптами, но в таком случае нам нужно будет таскать с собой все скрипты преобразующие конфигурацию компонента в рамках cloudify в конфигурацию понятную libvirt, и в рамках плагина мы вынесем весь универсальный код в плагин, а вот действия специфичные под наши текущие нужды мы выполним через скрипты. И как результат в скрипты мы перенесен код загрузки исходных образов с интернета и клонирования образа под каждую виртуальную машину с генерацией уникального сетевого адреса. А в плагине оставим код для создания виртуальной машины(и сети) с образа, где мы используем результаты ранее указанных скриптов.

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

Теперь немного уточним почему идея когда мы описываем полную структуру компонента в blueprint может оказаться не удобна при использовании: для сложных и больших структур пользователю не нужно контролировать все элементы компонента. И когда мы преобразуем yaml blueprint ->python dictionary -> xml, пользователю нужно учитывать каждый шаг преобразования и ему будет удобнее сразу использовать XML, если он хочет использовать описание libvirt XML format, или ему удобнее указать минимальные параметры на которые он хочет влиять, подобные объёму памяти и списку подключенных сетей с дисками. Но совершенно не жаждет указывать тип системных часов или расположение в пространстве PCI устройств видеокарты.

Это все :-) Всем спасибо кто дочитал до сего момента

Ссылки:

Sunday, October 8, 2017

Впечатление от презентации GooglePixel2

и немного других продуктов. 

Гугл решил перестать мерятся аппаратными решениями и никаких терагерц процессоров и терабайт хранилищ на устройствах не будет, и камеры впечатлять числами мегапикселей уже тоже не будут. Так же всяких гибких без рамочных штук тоже не будет. 

Гугл решил что нейронные сети ответ на все вопросы, и главное пользовательское ощущение от продукта. Как результат, если сравнивать с другими флагманами кажется, что ничего выдающегося там нет. И в момент когда ставишь кастомную прошивку пол цены как и не бывало. Но все же стоит топовый процессор, достаточное количество памяти (для ближайших пары релизов андроида должно хватить) и качественная камера.
Особенности реализованы программно через нейронные сети или специфично для официальной прошивки: 
  • фотографии с обоих камер - как будто снято со сдвоенных камер или профессиональной камеры, все за счет нейронных сетей, достигается через использование через сдвоенные пиксели, только в отличии от самсунг который использует эти пиксели только для улучшенного фокуса, гугл через нейросеть хочет еще получать более точные данные о глубине и направлении пришедшего света. Также камера содержит аппаратную стабилизацию изображение в добавок к программной;
  • улучшенный ассистент все время слушает и больше фич; 
  • полная оффлайн база слепков музыки и без соединения на заблокированном экране показывает музыку которая сейчас слышна;
  • одна карточка виртуальная и одна физическая SIM карта.

Разницы в аппаратной части между обычной и XL версией нет, только размер экрана и в топовой версии углы экрана надкусаны. 

И относительно sdcard и 3,5 разъема для наушников, гарантировать скорость общения с внешней картой сложно и встроенная emmc все же на порядок быстрее. И разъем для наушников это скорее атавизм, тоже можно получить через usb-C разъем и тогда DAC будет именно в наушниках и каната вместо провода больше не нужно. 

Ну и микробы переводчики больше тоже не нужны, гугл предлагает наушники переводчики. 
И ноутбук тоже теперь обладает достаточным объемом диска (512Gb SSD) чтобы считаться ноутбуком, правда он больше какой-то трансформер и его можно вывернуть и получить планшет. А google home следит за устройствами и через нейронную сеть решает как лучше сформировать луч к устройству.