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 следит за устройствами и через нейронную сеть решает как лучше сформировать луч к устройству.

Tuesday, July 25, 2017

Create wagon for netconf

On separate centos machine(if you use centos as base for cloudify manager).
Prepare external python packages:
  • sudo yum install -y epel-release
  • sudo yum install -y python-pip python-setuptools python-pip python-wheel python-setuptools python-virtualenv

Install packages for lxml dependencies:
  • sudo yum install -y python-devel gcc-c++ gcc libxslt-devel libxml2-devel zlib-devel libffi-devel openssl-devel

Install wagon environment:
  • mkdir wagon
  • virtualenv wagon
  • cd wagon
  • . bin/activate
  • pip install --upgrade pip
  • pip install wagon

Create wagon:

On Manager:
  • sudo yum install -y openssl libxml2 libxslt

Saturday, May 27, 2017

In fastboot we trust. Part 3

Сборка прошивки для LG G3s(jag3gds):
  • Скачиваем исходники основной прошивки:
    $ repo init -u https://github.com/LineageOS/android.git -b cm-14.1
  • Обновляем исходники:
    $ repo sync -j 4
  • Обновляем переменные окружения:
    $ . build/envsetup.sh
  • Подготавливаем специфичные для устройства каталоги:
    $ breakfast jag3gds
  • Дописываем project name="TheMuppets/proprietary_vendor_lge" path="vendor/lge" remote="github" в .repo/local_manifests/roomservice.xml для добавления блобов
  • Запускаем сборку:
    $ brunch jag3gds

Monday, May 8, 2017

In fastboot we trust. Part 2

Некоторые устройства содержат нестандартные протоколы загрузки или неполные реализации стандартных протоколов. В случае LG G3s(jag3gds) мы имеем 4 способа загрузки:
  • стандартный загрузочный сектор(boot), загружается при обычном нажатии кнопки Power;
  • загрузчик для стандартной системы обновления прошивки(laf), поддерживает только стандартный протокол LG для установки прошивок, для входа нужно выключить телефон подождать с десяток секунд, нажать Volume UP и подключить usb или adb reboot bootloader;
  • если стереть laf то aboot не найдя laf входит в режим fastboot, реализовано только часть протокола - можно только отформатировать разделы или перегрузить телефон(поддержки команды boot нет);
  • раздел с recovery - загрузиться можно только с основного раздела через adb reboot recovery.
Решением могло бы быть реализация fastboot или использование uboot. Но можно использовать наработки efidroid минимальный lk образ содержит поддержку fastboot. Для сборки можно использовать такую последовательность команд:
  • $ source build/envsetup.sh
  • $ lunch
  • # select Device name == lge/jag3gds and build type == debug
  • $ make -j6 lk
  • $ adb push out/device/lge/jag3gds/lk.img /sdcard/Download/lk.img
  • $ adb root
  • $ adb shell
  • # dd if=/sdcard/Download/lk.img of=/dev/block/platform/msm_sdcc.1/by-name/laf
  • # exit
  • $ adb reboot bootloader # boot to laf
Если хочется использовать полный образ нужно заменить lk на uefi.

В текущей реализации в uefi образе содержится ошибка и нужно применить такое исправление в uefiapi/target/msm8226.c заменить:
pdata = cb(pdata, MSM_IOMAP_BASE, (MSM_IOMAP_END - MSM_IOMAP_BASE), LKAPI_MMAP_RANGEFLAG_RESERVED, 
на:
pdata = cb(pdata, MSM_IOMAP_BASE, 1*MB, LKAPI_MMAP_RANGEFLAG_RESERVED,.

Saturday, May 6, 2017

Сборка NSX wagon

Для offline установки на инфраструктуру без доступа к внешнему миру, нужно создать пакет содержащий все зависимости, cloudify использует wagon как формат пакетов установки. Для создания подобного пакета на основе CentOS можно использовать такую последовательность команд:
  • sudo yum install epel-release
  • sudo yum install python-pip python-setuptools python-pip python-wheel python-setuptools python-virtualenv
  • mkdir wagon
  • virtualenv wagon
  • cd wagon
  • . bin/activate
  • pip install --upgrade pip
  • pip install wagon
  • wagon create -t tar.gz https://github.com/cloudify-cosmo/cloudify-nsx-plugin/archive/1.0-build.zip
Последовательность команд может отличаться для других дистрибутивов и каждый пакет содержит версию дистрибутива для которого он создан.

Tuesday, May 2, 2017

In fastboot we trust. Part 1

Или обновление ядра android на официальное ядро с kernel.org

Все современные ядра для android, хоть и до сих пор базируются на 3.4, но все же перешли на device tree, поэтому напрямую использовать их на старых устройствах(до 2011 года) скорее всего не получиться, так как они рассчитаны на загрузку используя atags, поддержку которого благополучно сломали в процессе обновления, есть ещё и вторая потенциальная проблема, на мобильных телефонах размер подобных atags может быть очень большой, для примера там может быть прошивка для Wi-Fi и калибровка для камеры и получается размер под 64 килобайта. Если немного пройтись по тому как оно работает получается такое поведение: в идеале на новых загрузчиках ядру передается как один из параметров ссылка на devicetree, который представляет собой упакованное дерево с описанием устройств и их настроек доступных на аппаратном уровне, каждый узел подобного дерева содержит список совместимости, где перечислен список типов устройство потенциально совместимых с доступными на аппаратном уровне, для примера может быть указано что мы имеем какой-то телефон или платформу и указано что также у нас система базирующаяся на каком-то чипе, если ядро не в курсе нашей платформы оно может попытаться задействовать код поддержки от чипа, этого должно быть достаточно для поддержки 99 процентов устройств, так как все устройства внутри soc обычно совпадают для того же процессора, а отличие только в описании и настройке линий ввода/вывода. Данная технология изначально была придумана для power и используется широко на данный момент в официальном ядре для реализации поддержку различных платформ одним ядром одновременно, как следствие можно загрузиться на одном ядре Qualcomm msm и Samsung Exynos устройство сообщив ему путь к device tree.

В случае atags все немного попроще и не так универсально, а теги представляют собой список структур в каждой такой структуре есть длина этой записи и ее тип, последняя структура содержит все поля с нулями. Значения численные значения типов частично стандартизированы и каждый производитель волен их дополнять как ему удобно. В качестве стандартных обычно выступают размер памяти и размер initrd образа.

Новый загрузчик под android понимает образы которые содержат 3 секции: само ядро, device tree, initrd. Старые загрузчики игнорируют DT секцию и для того чтобы можно было загрузиться ядру с поддержкой DT, придуманы такие обходные маневры: в конец образа ядра записывается DT и в ядре выбирается опция, что нужно искать DT после образа ядра и опция конвертации atags в DT во время загрузки, в результате ядро загрузить DT и прочитав atags перепишет используя эти значения DT.