Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 13497 сообщений
Cообщения с меткой

linux - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

IP unnumbered в Debian или раздаем адреса экономно

Среда, 26 Июля 2017 г. 13:53 (ссылка)

Когда мы получили блок IP-адресов для новой технической площадки в Варшаве, автоматически возник вопрос о том, как им распорядиться экономнее — адресов никогда не бывает много, даже у свежеиспеченного LIR.



При проектировании сети в новом месте хотелось новых плюшек:




  • В некоторой степени изолировать серверы клиентов от чужого трафика;

  • Не дать недобросовестным клиентам повесить себе на интерфейс адреса добросовестных;

  • При необходимости иметь возможность без особой нагрузки порезать трафик;

  • Иметь возможность дать клиенту любое количество IP-адресов.



Теоретически, все эти моменты решаются с помощью обычных VLAN. Однако, возникает проблема с перерасходом адресов — все же жалко клиенту, заказавшему сервер с одним адресом, отдавать сеть /30 и терять три адреса впустую. Также жалко адреса и в обратной ситуации — клиенту надо 6 доступных адресов, а в сеть /29 он уже не поместится, приходится выдавать сеть /28 и терять 7 штук.



Тут на помощь приходит технология IP unnumbered. С ее помощью можно клиенту выдать хоть один адрес, хоть 6, хоть 99. На Хабре о ней уже писали, однако, статья уже довольно старая и в чистом виде нам не подошла — с той конфигурацией isc-dhcpd не слушает клиентские интерфейсы. Нам же хотелось сделать сетевую загрузку.



Итак, на входе у нас есть:




  • Сеть большого размера, например, 99.111.222.129/25

  • Маршрутизатор на базе Linux Debian 8/9

  • Layer-2 коммутатор, например, Cisco/Juniper

  • Три клиента, которым надо выдать 1, 2 и 3 IP-адреса

  • DHCP-сервер, который должен слушать клиентские виланы



Сначала создадим технический VLAN, на котором будет большая сеть. Добавляем в /etc/network/interfaces:



# Base interface for IP Unnumbered

auto eth1.3000

iface eth1.3000 inet static

address 99.111.222.129

netmask 255.255.255.128




И поднимаем сам интерфейс:



ifup eth1.3000



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



Дальше добавляем клиентские интерфейсы в /etc/network/interfaces:



# Клиент 1

auto eth1.3111

iface eth1.3111 inet static

address 10.31.11.1

netmask 255.255.255.0

up ip ro add 99.111.222.130 dev eth1.3111 src 99.111.222.129

down ip ro del 99.111.222.130 dev eth1.3111 src 99.111.222.129



# Клиент 2

auto eth1.3112

iface eth1.3112 inet static

address 10.31.12.1

netmask 255.255.255.0

up ip ro add 99.111.222.131 dev eth1.3112 src 99.111.222.129

up ip ro add 99.111.222.132 dev eth1.3112 src 99.111.222.129

down ip ro del 99.111.222.131 dev eth1.3112 src 99.111.222.129

down ip ro del 99.111.222.132 dev eth1.3112 src 99.111.222.129



# Клиент 3

auto eth1.3113

iface eth1.3113 inet static

address 10.31.13.1

netmask 255.255.255.0

up ip ro add 99.111.222.133 dev eth1.3113 src 99.111.222.129

up ip ro add 99.111.222.134 dev eth1.3113 src 99.111.222.129

up ip ro add 99.111.222.135 dev eth1.3113 src 99.111.222.129

down ip ro del 99.111.222.133 dev eth1.3113 src 99.111.222.129

down ip ro del 99.111.222.134 dev eth1.3113 src 99.111.222.129

down ip ro del 99.111.222.135 dev eth1.3113 src 99.111.222.129





И поднимаем их:



ifup eth1.3111

ifup eth1.3112

ifup eth1.3113




Адреса вида 10.31.11.1 на интерфейсах нужны с одной целью — чтобы dhcp-демон слушал эти интерфейсы. Больше они нигде не фигурируют и клиент о них не знает.



Чтобы на клиентских интерфейсах работал isc-dhcpd, добавляем в /etc/dhcp/dhcpd.conf:



subnet 10.31.11.0 netmask 255.255.255.0 {}

subnet 10.31.12.0 netmask 255.255.255.0 {}

subnet 10.31.13.0 netmask 255.255.255.0 {}




Также, чтобы не править его каждый раз при добавлении клиента, в /etc/default/isc-dhcp-server комментируем опцию



#INTERFACES=...



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



Если клиентские машины должны друг друга видеть — добавляем в /etc/sysctl.conf:



net.ipv4.conf.all.proxy_arp=1



И применяем это на лету:



sysctl -w net.ipv4.conf.all.proxy_arp=1



Дальше осталось сконфигурировать коммутаторы.



Пример для Juniper
set vlans vlan3111 vlan-id 3111

set vlans vlan3112 vlan-id 3112

set vlans vlan3113 vlan-id 3113

set interfaces xe-0/1/0 unit 0 family ethernet-switching port-mode trunk

set interfaces xe-0/1/0 unit 0 family ethernet-switching vlan members 3111-3113

set interfaces ge-0/0/0 unit 0 family ethernet-switching port-mode access

set interfaces ge-0/0/1 unit 0 family ethernet-switching port-mode access

set interfaces ge-0/0/2 unit 0 family ethernet-switching port-mode access

set interfaces ge-0/0/0 unit 0 family ethernet-switching vlan members 3111

set interfaces ge-0/0/1 unit 0 family ethernet-switching vlan members 3112

set interfaces ge-0/0/2 unit 0 family ethernet-switching vlan members 3113



Здесь порт xe-0/1/0 смотрит на наш маршрутизатор, а на портах ge-0/0/0 — ge-0/0/2 живут клиенты.



Пример для Cisco
vlan 3111

name vlan3111

vlan 3112

name vlan3112

vlan 3113

name vlan3113

interface GigabitEthernet0/48

switchport mode trunk

switchport trunk allowed vlan add 3111-3113

interface GigabitEthernet0/1

switchport mode access

switchport access vlan 3111

interface GigabitEthernet0/2

switchport mode access

switchport access vlan 3112

interface GigabitEthernet0/3

switchport mode access

switchport access vlan 3113


Здесь порт GigabitEthernet0/48 смотрит на наш маршрутизатор, а на портах GigabitEthernet0/1 — GigabitEthernet0/3 живут клиенты.



Все, теперь клиент может на своем сетевом интерфейсе прописать обычные настройки вида



auto eth0

iface eth0 inet static

address 99.111.222.130

netmask 255.255.255.128

gateway 99.111.222.129



И получит только выделенные ему адреса, остальные просто не будут работать, что бы он не вешал на свой интерфейс. А мы потратили из своей сети ровно то количество адресов, которые клиент заказал.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334124/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Опыт использования FPGA платы DE10-Standard и DMA PL330

Среда, 26 Июля 2017 г. 11:07 (ссылка)





Получил в свое распоряжение плату Terasic DE10-Standard. На ней много всего интересного: встроенный JTAG программатор, светодиоды, переключатели, кнопки, разъемы Audio / VGA / USB / Ethernet. Думаю, что нет особой необходимости перечислять все ее возможности, ведь каждый желающий может прочитать спецификацию платы на сайте производителя.



Для меня важно, что на плате стоит FPGA чип Cyclone V SX – 5CSXFC6D6F31C6N. Эта микросхема содержит два процессора ARM Cortex-A9 и 110K логических элементов FPGA. Это уже настоящая SoC HPS: System-On-Chip, Hard Processor System. С такими ресурсами можно пробовать делать довольно сложные проекты. Далее расскажу о своем опыте использования платы.



Очень просто скачать образ Linux с сайта терасика и подготовить загрузочную SD карту для платы DE10-Standard. ОС Linux загружается с SD, плата оживает и демонстрирует свои возможности.







Как только загрузился Linux, на рабочем столе можно отыскать иконку тестового приложения. Это тестовое GUI приложение позволяет включать и выключать отдельные светодиоды платы, смотреть состояние переключателей и кнопок, устанавливать значения на 7-сегментных индикаторах и так далее. Там много чего интересного. Когда поигрался с этой программой думаешь, что вот и сам сейчас быстро сможешь сделать свой проект и быстро его запустить.



Я не считаю себя новичком-разработчиком ПЛИС. Я делал проекты с софт процессорами и представляю себе, что такое Linux kernel. Я и сам участвую в разработке плат разработчиков с ПЛИС Altera/Intel. Однако, честно говоря, это мой первый опыт работы с SoC HPS-FPGA. Когда я начал делать свой собственный проект для этой платы, именно для этой ПЛИС, я понял, что на самом деле будет не просто.







Конечно, плата DE10-Standard сама по себе не виновата.

Есть некоторая иллюзия легкости разработки: вот есть образ SD карты от терасика, есть исходники примера проекта для ПЛИС и сишные исходники для тестовых программ. Казалось бы, бери адаптируй под свои нужды и будет все работать. Но, нет.



Нужно понять, что первое впечатление легкости разработки — оно обманчиво. Что видно с первого взгляда — это всего лишь вершина айсберга.



Пришлось очень много читать и изучать, например:

1. К плате прилагается диск DE10-Standard_v.1.2.0_SystemCD и он содержит 38 PDF файлов различной документации, схем и руководств.



2. Просто техническое описание от компании Интел “Cyclone V Hard Processor System Technical Reference Manual” www.altera.com/en_US/pdfs/literature/hb/cyclone-v/cv_5v4.pdf содержит 3536 страниц.



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



Есть еще хороший ресурс: https://rocketboards.org/, который содержит еще больше документации, исходников примеров и даже форум. Это делает жизнь с одной стороны легче, а с другой — еще сложнее, ведь придется читать и впитывать еще больше информации… К сожалению даже на форуме rocketboard, не всегда удается найти ответы на свои вопросы.



Таким образом, разработка проекта получается довольно сложной, потому, что сам предмет разработки SoC HPS является сложным.







Представьте себе часовой механизм с множеством шестеренок. Каждая шестеренка должна в точности подходить к следующей — иначе ничего не будет крутиться. То же самое и в случае с системой HPS-FPGA. Система состоит из очень многих программных и аппаратных компонентов: Preloader, U-BOOT, Linux kernel и драйвера, DTB файл генерируется из DTS файла, затем еще нужно создать RootFS и, конечно, разработать саму аппаратную систему в ПЛИС: FPGA SoC проект будет содержать несколько IP блоков, аппаратные регистры отображаемые в память, тактовые частоты и домены, сигналы ввода/вывода и прочее и прочее…



Я предполагаю, что знаю, как создать проект для FPGA для моей SoC, и я думаю, что должно работать ну где-то на 80% так как я не вижу очевидных ошибок в проекте. Так же я думаю, что примерно знаю, как написать DTS файл, который описывает мою аппаратную платформу. Предположим, я уверен, что я написал DTS файл правильно на 80%. Из DTS файла генерируется DTB файл. Потом, к своей аппаратуре ПЛИС я должен написать kernel driver. Это не просто, но я умею писать драйвера. Надеюсь я там не наделал много ошибок? Надеюсь мой драйвер корректен ну хотя бы на 80%. Но что там насчет Preloader? Preloader – это первая программа, которая будет считана и запущена с SD карты и она должна запрограммировать нужные аппаратные конфигурационные регистры системы на кристалле. Сделал ли я Preloader правильно? Ну допустим, я уверен на 80%. Теперь если подумать, то какова вероятность, что моя система заработает? Я думаю, что где-то вот так: 0.8*0.8*0.8*0.8=0.4096… Чем больше компонентов в системе, тем хуже. Если что-то не работает или не работает вообще ничего (например, kernel panic), то довольно трудно понять где проблема — она может быть везде.



Цель моей работы была сделать проект HPS-FPGA который использует DMA транзакции для переноса данных из системной памяти в ПЛИС и обратно из ПЛИС в системную память. Использование DMA должно разгрузить процессор. На хабре уже была статья про реализацию DMA в FPGA Cyclone V, однако, мне не хотелось идти путем создания собственного контроллера, как это сделал Des333… Я хотел использовать уже имеющийся в системе контроллер PL330.



Работая с платой DE10-Standard Board некоторое время я получил бесценный опыт. Если позволите, хочу дать несколько советов тем, кто решится заняться разработкой SoC HPS в ПЛИС.



Подготовьте плату к разработке.



Вероятно это совет из разряда очевидных. Существует образ SD карты, который содержит нужные файлы для старта системы: образ FPGA, файл DTB, U-BOOT и Linux kernel zImage. Дополнительные разделы содержат Preloader и RootFS. Если я разрабатываю SoC HPS проект для ПЛИС, я его компилирую в среде САПР Quartus Prime и результат (RBF, Raw Binary File) должен записать на SD карту. Потом я компилирую Linux kernel и мой драйвер в составе ядра. Мне так же нужно записать получившиеся файлы на SD Card.



Нет никакого смысла вытаскивать SD карту из платы, вставлять в кардридер компьютера или ноутбука, чтобы записать файлы на карту. Это может занимать слишком много времени. К тому же, частый plug/unplug может привести к поломке разъема SD карты в плате или ноутбуке. Я рекомендую сконфигурировать U-BOOT таким образом, чтобы нужные файлы скачивались из сети с TFTP сервера.



Плата имеет разъем UART-to-USB для ее подключения через USB кабель к компьютеру разработчика. Открываю программу терминала, например, PUTTY, и включаю плату. Сразу видно, как в терминале побежали сообщения из U-BOOT. Загрузку можно прервать, если сразу нажать любую клавишу в терминале.



Я добавил несколько переменных в окружение U-BOOT:



ethaddr=fe:cd:12:34:56:67

ipaddr=10.8.0.97

serverip=10.8.0.36

xfpga=tftpboot 100 socfpga.rbf; fpga load 0 100 $filesize; run bridge_enable_handoff; tftpboot 100 socfpga.dtb

xload=run xfpga; tftpboot 8000 zImage; bootz 8000 – 100




На компьютере разработчика IP 10.8.0.36 я установил сервер TFTP. В папке /tftpboot я храню socfpga.rbf (Raw Binary File) – результат компиляции проекта SoC FPGA в среде Quartus Prime. Кроме того, там же в папке храню socfpga.dtb – соответствующий Device Tree Blob и Linux kernel zImage файл.



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

>run xload



По этой команде U-BOOT загружает нужные файлы из TFTP сервера, инициализирует FPGA последним скомпилированным образом проекта и загружает мой последний zImage. Быстро и просто. Когда делаю изменение в проекте ПЛИС, компилирую проект квартусом, результат копирую в папку /tftpboot. Точно так же, компилирую ядро Linux, результат компиляции копирую в папку /ftfpboot. Перезагружаю плату, делаю “run xload” и вот уже можно пробовать вести отладку новой системы.



2. Постарайтесь найти opensource пример проекта SoC-HPS максимально похожий на то, что вы собираетесь делать.



Капитан очевидность. Конечно, грамотный инженер может сделать все сам с нуля. Тем не менее, можно сэкономить немного времени, если найти исходники проекта, похожего на тот, что вы собираетесь делать.



Изначально DE10-Standard_v.1.2.0_SystemCD содержит два примера проектов для HPS-FPGA. Первый проект — это DE10_Standard_GHRD, представляет собой минимальные возможности, Linux console, простую отображаемую в память периферию вроде портов ввода вывода для светодиодов, кнопочек и переключателей. Второй пример, DE10_Standard_FB, — сложнее. Здесь уже в FPGA реализован framebuffer, видеоконтроллер, устройство захвата и декодирования видеосигнала и ряд других возможностей. Это позволяет запустить полноценный десктопный Linux. Если вас устраивают эти примеры — тогда все нормально, берите и пользуйтесь.



Лично мне хотелось найти пример с использованием DMA контроллера, так как я хотел разгрузить CPU во время передачи данных из системной памяти в FPGA и назад из FPGA в системную память. Я поискал такой пример и нашел его на сайте rocketboards: https://rocketboards.org/foswiki/view/Documentation/SampleDmaQuartusProjectForFpgaDmaCInTheKernel313



Пример вообще-то не очень, но хоть что-то, можно пробовать что-то сделать. Cyclone V HPS имеет встроенный DMA контроллер PL330 и я хотел бы попытаться использовать его. Я взял IP корку из проекта примера Loopback_FIFO и вставил его с помощью Quartus Prime QSYS в мой клон проекта DE10_Standard_GHRD. К сожалению, я потратил очень много времени на написание правильного DTS файла к моему проекту, DTS файла не было в архиве примера. Так же, я не сразу понял, что в Linux kernel уже есть пример DMA драйвера в arch/arm/mach-socfpga/fpga-dma.c. Я понял это слишком поздно, когда уже почти написал свой собственный драйвер.



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



3. Используйте исходники Linux kernel как документацию.



С FPGA Cyclone V HPS я разрабатываю новую аппаратную платформу. С большой вероятностью мне придется писать свой собственный драйвер к новой аппаратуре в ПЛИС. В интернете очень много статей как писать драйвера уровня ядра Linux. Но учтите, что очень многие из этих статей уже давным давно устарели, содержат не верные примеры, вызывают старый kernel API.



Если выбрать конкретную версию ядра Linux для проекта, то всю информацию о том, как писать драйвера можно почерпнуть конкретно из исходников этой версии ядра и это будет самая актуальная информация. Примеры драйверов в папке ./drivers, дествующая документация в папке ./Documentation, примеры написания *.DTS файлов в папке ./arch/arm/boot/dts



В моем случае для моего проекта с DMA контроллером документация о написании драйверов DMA получена из файлов ./Documentation/dmaengine/*.



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



Как я понял, теоретически разработка должна идти вот так:


  1. Разрабатываем аппаратную систему в среде САПР Quartus Prime QSYS, настраиваем параметры HPS, добавляем в систему компоненты и IP ядра, соединяем компоненты. Генерируем систему с помощью QSYS и получаем результат soc_system.qsys и soc_system.sopsinfo файлы.

  2. Создаем DTS файл из *.sopsinfo файла используя командную строку:

    >sopc2dts --input soc_system.sopcinfo --output socfpga.dts --board soc_system_board_info.xml --board hps_clock_info.xml


  3. Создаем DTB из DTS файла:

    >dtc -I dts -O dtb -o socfpga.dtb socfpga.dts




Я прочитал такую инструкцию на страницах рокетбоардс, но этот метод как-то не очень работает (совсем не работает). Для себя я понял, что единственно работающий метод — это вручную исправлять существующий пример DTS файла адаптируя его под свой аппаратный проект.



Как я уже писал, исходники ядра могут помочь в написании DTS файла. Я правда сам не сразу понял это, но когда понял, то дело пошло быстрее. Нужно использовать исходники ядра как документацию!



Дайвайте посмотрим пример DMA драйвера из ./driver/dma/fpga-dma.c



Драйвер вызывает API функцию platform_driver_probe() и передает в качестве аргумента указатель на структуру:

#ifdef CONFIG_OF
static const struct of_device_id fpga_dma_of_match[] = {
{.compatible = "altr,fpga-dma",},
{},
};

MODULE_DEVICE_TABLE(of, fpga_dma_of_match);
#endif

static struct platform_driver fpga_dma_driver = {
.probe = fpga_dma_probe,
.remove = fpga_dma_remove,
.driver = {
.name = "fpga_dma",
.owner = THIS_MODULE,
.of_match_table = of_match_ptr(fpga_dma_of_match),
},
};

static int __init fpga_dma_init(void)
{
return platform_driver_probe(&fpga_dma_driver, fpga_dma_probe);
}




Это значит, что в DTS файле должна быть соответствующая секция с совместимым именем устройства:

fpga_dma: fpga_dma@0x10033000 {

compatible = "altr,fpga-dma";




То есть, видимо функция platform_driver_probe будет просматривать DTB файл искать устройство с именем fpga-dma от производителя altr.



Если драйвер вызывает функции

csr_reg  = platform_get_resource_byname(pdev, IORESOURCE_MEM, "csr");
data_reg = platform_get_resource_byname(pdev, IORESOURCE_MEM, "data");


то это значит, что DTS файл должен содержать именованные регистры с такими же точно именами “csr” и “data”. В противном случае драйвер не сможет стартовать.



Точно так же, драйвер ядра может запрашивать каналы DMA по имени:



static int fpga_dma_dma_init(struct fpga_dma_pdata *pdata)
{
struct platform_device *pdev = pdata->pdev;

pdata->txchan = dma_request_slave_channel(&pdev->dev, "tx");
if (pdata->txchan)
dev_dbg(&pdev->dev, "TX channel %s %d selected\n",
dma_chan_name(pdata->txchan), pdata->txchan->chan_id);
else
dev_err(&pdev->dev, "could not get TX dma channel\n");

pdata->rxchan = dma_request_slave_channel(&pdev->dev, "rx");
if (pdata->rxchan)




А вот соответствующий фрагмент DTS файла, который отображает кореляцию исходников драйвера ядра и DTS файла:



fpga_dma: fpga_dma@0x10033000 {

compatible = "altr,fpga-dma";

reg = <0x00000001 0x00033000 0x00000020>,

<0x00000000 0x00034000 0x00000010>;

reg-names = "csr", "data";

dmas = <&hps_0_dma 0 &hps_0_dma 1>;

dma-names = "rx", "tx";




Таким образом, DTS файл должен быть написан с учетом того, как драйвер запрашивает из него ресурсы. Если используются именованные регистры и канала DMA, то имена должны совпадать и в исходнике ядра и в DTS файле. Только так две шестереночки системы: драйвер ядра и DTS/DTB могут работать вместе.



4. Помните, что ваши исходники могут быть не самыми свежими.



Мне нужен был компилятор и исходники Linux kernel, чтобы я смог начать разрабатывать свой драйвер и компилировать ядро для моей FPGA системы. Именно поэтому я выкачал последний (на тот момент) Intel SoC FPGA Embedded Development Suite v17.0 и установил его.



После полной установки я увидел новую папку ~/intelFPGA/17.0/embedded/embeddedsw/sources, где лежал скрипт git_clone.sh. Я запустил этот скрипт и получил исходники ядра вот здесь ~/intelFPGA/17.0/embedded/embeddedsw/sources/linux-sources.



Git branch получился вот такой: sockfpga-4.1.22-ltsi-16.1-release. Версия ядра 4.1.22 — ну пусть.



Я принял версию 4.1.22 как данность и начал работать с этой веткой над этими исходниками. Я собрал ядро и нашел, что есть драйвер DMA, называемый fpga-dma, и этот драйвер в общем-то работает с моим LoopbackFIFO IP core в моем FPGA проекте. Однако, я заметил, что производительность по передаче данных из памяти системы в FPGA и назад очень мала — передача осуществляется одиночными передачами, по одному слову за несколько тактов. Я перепроверил мой FPGA проект сотню раз, и я перепроверил fpga-dma.c драйвер сотню раз, но я так и не мог понять почему на шине не происходит burst transfers. Я уже было начал разбираться с исходниками самого драйвера DMA контроллера PL330. Так же, мне пришлось таки читать Cyclone V Hard Processor System Technical Reference Manual про HPS PL330 DMA контроллер. Этот DMA контроллер очень сложный, у него у самого есть свой набор инструкций, к нему нужно писать свою программу. Программа на языке ассемблера для PL330 DMA контроллера может выглядеть вот так:



DMAMOV CCR, SB4 SS64 DB4 DS64

DMAMOV SAR, 0x1000

DMAMOV DAR, 0x4000

DMALP 16

DMALD

DMAST

DMALPEND

DMAEND




В результате всех моих изыскания я понял, что драйвер ./drivers/dma/pl330.c никогда не инициализирует регистр CCR контроллера DMA для burst передачи. Я не понимал, что же мне делать, но позже я обнаружил, что более новые версии ядра уже содержат исправление этого недоразумения: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=848e9776fee424b9368c72377de5d3509b17937c



Я вручную добавил патч на исходники DMA драйвера и получил burst transfers! Вот здесь снимок с экрана SignalTap, где я захватываю DMA Mem-to-Device transfer:







Таким образом, если однажды вы столкнетесь с технической проблемой, которую не знаете, как решить, перепроверьте: вдруг к вашей проблеме уже есть исправление в более свежих исходниках ядра Linux? Какя понял, проблема с блочной передачей DMA контроллера PL330 решена в ядре 4.6.



5. Внимательно относитесь к отдельным деталям системы.



Конечно, разработка FPGA SoC системы требует специфических знаний. Сейчас я не хочу касаться особенностей и методов разработки IP ядер или синтаксиса Verilog / VHDL. Конечно, разработчик должен многое знать. Однако, я хочу обратить внимание, что заставить все части системы работать вместе — это не очень простая задача. Слишком много шестеренок, которые должны синхронно вращаться.



Попробую привести пример и моей практики.

Я пытался заставить работать драйвер контроллера PL330 DMA с моим IP core. Я встретил такую проблему: операции записи в устройство проходят успешно, а вот операции чтения всегда завершаются таймаутом. Я пытался найти решение в интернете и видел, что многие разработчики так же спрашивают про эту проблему, но решения нет. В системном логе я вижу сообщение из драйвера fpga-dma “Timeout waiting for RX DMA!”. Но в чем проблема? — не понятно. Почему с TX передачей все нормально, а с RX передачей — нет? Я поменял местами каналы RX и TX в FPGA проекте, и получил наоборот “Timeout waiting for TX DMA!”. Что же не правильного в моем втором канале DMA?



Я использую Quartus Prime Qsys для редактирования моей SoC. Один из наиболее важных компонентов системы SoC это hps_0, “Arria V / Cyclone V Hard Processor System”. Я отредактировал свойства этого компонента и убедился, что оба канала DMA у меня включены, и RX и TX:







Достаточно ли этого? На самом деле, конечно, нет! Qsys генерирует компоненты системы soc_system для Quartus Prime, но так же он создает программные компоненты в папке ./hps_isw_handoff/soc_system_hps_0.



Тут есть файл hps.xml в котором видно следующее:












Это значит, что позже я должен сгенерировать компонент Preloader, и для его компиляции используется этот XML файл. Скомпилированный Preloader должен быть записан в специальный раздел SD карты. Когда стартует система стартует и Preloader. Именно он включает все необходимые компоненты системы делая нужные записи в специальные аппаратные регистры.



Регистры Cyclone V HPS Reset Manager расположены по физическому адресу 0xFFD05000 (Cyclone V Hard Processor System Technical Reference Manual). Некоторые биты в регистрах Reset Manager, должны быть сброшены, чтобы включить DMA на отдельных каналах.



Ну хорошо. Я изменяю свойства компонента hps_0 в Qsys и теперь я знаю, что вероятно я должен перекомпилировать Preloader и записать его на SD.



Но и это еще не вся история!

Если я использую два канала DMA, то мне нужно и два прерывания для этих двух каналов и их еще нужно вручную объявить в DTS файле.

hps_0_dma: dma@0xffe01000 {

compatible = "arm,pl330-16.1", "arm,pl330", "arm,primecell";

reg = <0xffe01000 0x00001000>;

interrupt-parent = <&hps_0_arm_gic_0>;

interrupts = <0 104 4>, <0 105 4>;

clocks = <&l4_main_clk>;




Откуда такие странные числа 104 и 105?

Пришлось читать Cyclone V HPS Reference Manual. Я вижу, что Generic Interrupt Controller имеет зарезервированные линии запросов DMA IRQ 136 and 137:







Однако, почему-то нумерация начинается “32”. Таким образом я решаю, что 136-32=104 и 137-32=105 — это правильные числа. Вот такие магические подсчеты дают правильные значения для DTS файла в секции interrupts. Без объявления второго IRQs для PL330 в DTS файле второй канал DMA всегда получал ошибку таймаута в драйвере ядра… Получается, что я изменяю в Qsys свойства HPS и из-за этого мне может потребоваться одновременное изменение и Preloader и DTS файла — и об этом нужно все время помнить.



Заключение.



У меня был исходный проект с примером DMA проекта, который я нашел на страницах сайта rocketboard. Однако, я адаптировал его и заставил работать на DE10-Standard board и с ядром Linux 4.1.

Вероятно, это не очень большое достижение, однако:

  1. Я написал DTS файл, которого не было в исходном проекте. Это было довольно трудно.

  2. Понял, что требуется делать патч ядра, чтобы получить блочную передачу (burst transfer).

  3. Подключил анализатор SignalTap к FPGA проекту и теперь могу видеть сигналы на шине в момент DMA передачи

  4. Научился писать DMA драйвер ядра

  5. Надеюсь, что понял весь road-map разработчика для Cyclone V HPS





Если кто-то захочет поэкспериментировать с DMA в SoC я рекомендую начинать эксперименты с альтеровского драйвера fpga-dma. Он использует DebugFS, это позволяет использовать прямо в консоли терминала простые команды “cat”, “echo” для выполнения транзакций в DMA канале:







Надеюсь эта статья окажется полезной тем, кто только начинает работы с FPGA SoC HPS Cyclone V.



Посмотреть исходники проекта можно здесь: https://github.com/marsohod4you/DE10_Standard_GHRD_w_FIFO
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334154/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Из песочницы] Вынос локального сервера в сеть с помощью другого внешнего сервера

Понедельник, 24 Июля 2017 г. 15:21 (ссылка)

Добрый день, хабровчане! История такова: сколько себя помню, всегда дома висел какой-нибудь сервер, который очень хотелось вывести во всеми нами любимый Интернет.

«Ну и что тут сложного? Практически любой провайдер предоставляет статический белый IP за небольшую плату!», – скажите Вы и будете абсолютно правы. Но это платно, да и вообще хотелось попробовать чего-нибудь более оригинального. Основная проблема доступа к моему серверу – NAT. Если вдруг кто не знает, что это, ниже оставил пояснение из Википедии.



NAT
NAT (от англ. Network Address Translation — «преобразование сетевых адресов») — это механизм в сетях TCP/IP, позволяющий преобразовывать IP-адреса транзитных пакетов. Также имеет названия IP Masquerading, Network Masquerading и Native Address Translation.

Преобразование адреса методом NAT может производиться почти любым маршрутизирующим устройством — маршрутизатором, сервером доступа, межсетевым экраном. Наиболее популярным является SNAT, суть механизма которого состоит в замене адреса источника (англ. source) при прохождении пакета в одну сторону и обратной замене адреса назначения (англ. destination) в ответном пакете. Наряду с адресами источник/назначение могут также заменяться номера портов источника и назначения.



Принимая пакет от локального компьютера, роутер смотрит на IP-адрес назначения. Если это локальный адрес, то пакет пересылается другому локальному компьютеру. Если нет, то пакет надо переслать наружу в интернет. Но ведь обратным адресом в пакете указан локальный адрес компьютера, который из интернета будет недоступен. Поэтому роутер «на лету» транслирует (подменяет) обратный IP-адрес пакета на свой внешний (видимый из интернета) IP-адрес и меняет номер порта (чтобы различать ответные пакеты, адресованные разным локальным компьютерам). Комбинацию, нужную для обратной подстановки, роутер сохраняет у себя во временной таблице. Через некоторое время после того, как клиент и сервер закончат обмениваться пакетами, роутер сотрет у себя в таблице запись о n-ом порте за сроком давности.



Если своими словами, это внешний маршрутизатор, позволяющий Вам отправлять запросы в интернет, но не позволяющий Вам их получать. Ответ-то из Интернета Вы получаете, а значит уже не все потеряно. Мне вспомнилась старая программа LogMeIn Hamach, она же позволяла нам обмениваться пакетами данных при том, что ВСЕ клиенты были в закрытой NAT'ом сети. А что, если реализовать что-нибудь подобное:







Что здесь нарисовано? OPI – это моя Orange Pi PC, которая выполняет роль сервера, NAT – это, как несложно догадаться, маршрутизатор моего оператора (он может быть не один, но сути это не меняет), KVM – внешний сервер товарища, CLI – клиент. Возможно, у вас возник вопрос: «По какой причине ты не мог просто выкинуть все свои сервисы на сервер товарища?». Ответ прост: не хочу. В конце концов и дисковое пространство пришлось бы использовать чужое, а меня это не устраивает. Не говоря уже об усложнении администрирования и обслуживания сервера…



OPI подключается к KVM и между ними устанавливается VPN канал. А далее клиент подключается к KVM, и эта машина в свою очередь отправляет запрос через VPN к OPI.

Почему KVM? Сервер товарища – обычный VDS(Virtual Dedicated Server). Обычно это либо KVM (Kernel-based Virtual Machine), либо OVZ (OpenVZ). OVZ в нашем случае не подходит, так как iptables там работают как-то не так, да и вообще штука очень странная.



Настройка сервера



В теории это звучит все здорово, но теперь надо реализовывать на практике. Нужно выбрать протокол для VPN. Изначально, я был склонен к OpenVPN, но после череды проб, ошибок, неудач, пришел к выводу, что это не лучший протокол для таких действий. В конце концов он использует сложные алгоритмы шифрования, которые еще и будут неслабо грузить процессор OPI и внешнего сервера, поэтому мой выбор пал на протокол PPTP.



Первым делом надо установить сам PPTP демон на сервере:



apt install pptpd


Следующим шагом его надо настроить. Откроем его конфиг файл /etc/pptpd.conf и укажем IP адрес сервера и диапазон IP адресов клиентов:



localip 10.0.0.1
remoteip 10.0.0.100-200


Теперь нужно создать учетные записи VPN клиентов. Их список находится в файле /etc/ppp/chap-secrets



# client server secret IP addresses
orange pptpd pass123 10.0.0.100


Мы создали клиента orange с паролем pass123 и IP адресом 10.0.0.100. Если вместо IP адреса указать *, то клиент получит любой свободный IP адрес из диапазона, указанного в remoteip. Нам рандома явно не надо. Теперь еще пару штрихов с настройками PPTPD. Добавим DNS сервера в файле /etc/ppp/pptpd-options



ms-dns 8.8.8.8
ms-dns 8.8.4.4


И перезагрузим PPTPD:



service pptpd restart


Очень важный шаг – включение IP форвардинга. Это позволит Вам пересылать пакеты между публичным IP и приватными IP, которые Вы настроили при помощи PPTP. Редактируем файл /etc/sysctl.conf и раскомментируем строку:



net.ipv4.ip_forward = 1


Отлично, теперь можно начинать колдовать с ipatables.

Для начала узнаем название нашего сетевого интерфейса:



~$ ifconfig
ens3 Link encap:Ethernet HWaddr 52:54:00:f8:0c:4a
inet addr:31.148.99.234 Bcast:31.148.99.255 Mask:255.255.255.0
inet6 addr: fe80::5054:ff:fef8:c4a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:8808733 errors:0 dropped:0 overruns:0 frame:0
TX packets:3300625 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3511383831 (3.5 GB) TX bytes:3245380453 (3.2 GB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:216 errors:0 dropped:0 overruns:0 frame:0
TX packets:216 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:16618 (16.6 KB) TX bytes:16618 (16.6 KB)


У меня он называется ens3. Однако, чаще всего он называется eth0.



Создаем правило iptables:



iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE && iptables-save


Не забудьте заменить интерфейс на свой. Если вы планируете в будущем использовать VPN для своих нужд, можете прописать правила, чтобы клиенты VPN сети могли взаимодействовать:



iptables --table nat --append POSTROUTING --out-interface ppp0 -j MASQUERADE
iptables -I INPUT -s 10.0.0.0/8 -i ppp0 -j ACCEPT
iptables --append FORWARD --in-interface ens3 -j ACCEPT


ppp0 – виртуальный интерфейс сети.



Настройка локального сервера



Далее нужно подключить нашего первого клиента – Orange PI. На этом моменте я засел надолго, так как все инструкции в интернете говорили одно и то же, и все они не работали.



Первым делом на Orange PI установим PPTP клиент:



apt install pptp-linux


Создадим файл /etc/ppp/peers/pptpserver и впишем следующее:



pty "pptp 31.148.99.234 --nolaunchpppd"
name orange
password pass123
remotename PPTP
require-mppe-128


Не забудьте поменять IP адрес сервера и прочие данные на свои.



Далее закомментируем все строки в файле /etc/ppp/options вставкой символа #

Файл /etc/ppp/options.pptp нужно привести к следующему виду:



lock
noauth
nobsdcomp
nodeflate
defaultroute
replacedefaultroute
mtu 1400
persist
maxfail 0
lcp-echo-interval 20
lcp-echo-failure 3


И, наконец, пробуем подключиться:



pon pptpserver


Если все получилось, попробуем посмотреть на наш виртуальный интерфейс:



~$ ifconfig ppp0
ppp0 Link encap:Point-to-Point Protocol
inet addr:10.0.0.100 P-t-P:10.0.0.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1496 Metric:1
RX packets:1075 errors:0 dropped:0 overruns:0 frame:0
TX packets:959 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:154176 (154.1 KB) TX bytes:194499 (194.4 KB)


Попробуем пропинговать Orange PI с внешнего сервера:



~$ ping 10.0.0.100
PING 10.0.0.100 (10.0.0.100) 56(84) bytes of data.
64 bytes from 10.0.0.100: icmp_seq=1 ttl=64 time=8.91 ms
64 bytes from 10.0.0.100: icmp_seq=2 ttl=64 time=8.80 ms
64 bytes from 10.0.0.100: icmp_seq=3 ttl=64 time=8.93 ms
64 bytes from 10.0.0.100: icmp_seq=4 ttl=64 time=9.00 ms


Работает!



Проброс портов



Теперь самая малость: перенаправление пакетов с сервера на Orange PI. Тут уже способы могут быть разными, но так как на этом сервере 80 и 443 порт не используются вообще, мы можем просто попросить сервер все пакеты для этих портов перенаправлять на OPI



iptables -t nat -A PREROUTING -p tcp -d 31.148.99.234 --dport 80 -j DNAT --to-destination 10.0.0.100:80
iptables -A FORWARD -i ppp0 -d 10.0.0.100 -p tcp --dport 80 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp -d 31.148.99.234 --dport 443 -j DNAT --to-destination 10.0.0.100:443
iptables -A FORWARD -i ppp0 -d 10.0.0.100 -p tcp --dport 443 -j ACCEPT


На забудьте поменять IP адреса на свои. Проверим, что все работает:







Здорово! Цель достигнута!



Маленькие доработки



Но вдруг в здании, где располагается Orange PI выключается свет и… После перезагрузки никто опять не может получить доступ к нашему апельсину. Почему? Потому что сам по себе Orange PI к VPN не подключится. Напишем простой скрипт на bash, который будет вциклически выполняться, проверяя, установлено ли соединение:



#!/bin/sh
while [ 0 ]
do
if ifconfig ppp0>>/dev/null
then
sleep 7
else
pon pptpserver
if $?
then
echo $(date) Connected
else
echo $(date) Connection error
fi
fi
sleep 3
done


Теперь добавим его в автозагрузку. В файл /etc/rc.local впишем строку с расположением скрипта. В моем случае это:



/root/scripts/ppp.sh


Не забываем дать скрипту права на исполнение:



chmod +x /root/scripts/ppp.sh


Внимательный пользователь мог заметить, что в скрипте есть команды echo, но ведь им некуда делать вывод! Изначально, я планировал сделать в виде сервиса, чтобы вывод удобно капал туда, но в итоге банально поленился, работает же. Кстати, а работает ли? Перезагружаем наш апельсин и видим, что интерфейс ppp0 успешно поднялся, а наши сервисы доступны из интернета. Цель достигнута, господа!



Итог



Все это сделано исключительно в развлекательных и учебных целях. Практической пользы это почти не несет, так как нам все равно необходим внешний сервер, да и нагрузка не его сеть удваивается, ибо ему приходиться принимать пакеты и сразу же передавать их дальше. Однако, у этого метода есть преимущества, т.к. реальный IP нашего сервера будет скрыт, этот внешний сервер сможет лучше противостоять DDoS атакам, а также сможет выводить беспокойным пользователям страницу о технических работах, если Orange PI будет недоступен. Конечно же, для этого нужно будет еще серьезно постараться, но разве не в самом пути к цели все удовольствие, товарищи?



Ссылки на используемые ресурсы



1. Как настроить VPN с помощью PPTP

2. Проброс портов через NAT
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/333996/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Из песочницы] Релизный цикл для Infrastructure as Code

Суббота, 23 Июля 2017 г. 00:00 (ссылка)

https://habrahabr.ru/post/333922/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[recovery mode] Openstack. Детективная история или куда пропадает связь? Часть третья

Пятница, 21 Июля 2017 г. 17:47 (ссылка)



«Кто так строит?!»



Какой адрес у маршрутизатора должен быть по-умолчанию в сети – это большой вопрос. На самом деле ничто не мешает ему быть любым адресом из подсети. И сочинители OpenStack тоже решили – давайте будет первый, что мучиться?



В итоге ты опомниться не успеваешь, как всё падает. Почему? Потому что неожиданно для всех default gw оказывается не на роутере, как ему положено, а на твоём опенстеке. Клиенты звонят, шеф лютует. А ты ищешь очередную причину падения. Просто коллега отцепил существующий адрес с целью замены, а опенстек оказался хитрее…



Жизнь продолжается



В некоторых случаях проблема возникает сразу, в некоторых – нет. Напомню: старая проблема состояла в том, что периодически начинались пропадания части IP-пакетов.



Попытаюсь немного оправдаться. – часто наши проблемы совпадали с наличием внешних атак. При этом во многих случаях казалось, что проблемы именно в перегруженных каналах. В каких-то случаях мы превышали лимит каналов и пакеты действительно дропались. Это усугублялось наличием заражённых машин в платформе, которые генерировали неимоверный объём внутреннего трафика. Плюс неисправности сетевого оборудования, в котором, из-за ошибок программистов тоже убивались не те пакеты. Кроме того, конфигурационные файлы просто огромны.



Я не робот и не волшебник – понять функционал опций можно при вдумчивом чтении, но нужны ли они в конкретном контексте – было совершенно не ясно. Пришлось интуитивно угадывать, проверяя самые разумные предположения на практике.



Поэтому мне с коллегами сложно было отделить и выявить проблему. Хуже того – в созданной вновь ферме проблема не возникала. Мы сгенерировали триста машин, и всё работало, как часы. Конечно мы тут же мы стали готовить её в «продакшн». Это подразумевало введение «рваных» диапазонов ip адресов. Мы очистили ферму, убрав эти самые триста машин. И вдруг, при наличии всего трёх тестовых виртуальных машин случилось то же, что и на старой ферме – стали пропадать пакеты, в большом количестве. Так мы определились, что проблема где-то в глубине OpenStack.



Странные временные решения



В старой ферме мы нашли относительно простой способ эту проблему обходить. Это делалось отрыванием внутреннего IP адреса и назначением его из другой подсети – нам при этом приходилось часто добавлять новые подсети. Проблема на какое-то время уходила. Часть машин при этом работала хорошо.



Решение где-то рядом



В ходе долго расследования, прерываемые на проектные работы, отвлекаемые проблемами от VIPов, мы всё-таки смогли выявить несколько ошибок. Кроме того, эти самые файлы различаются, если вы используете контроллер в качестве вычислительного узла, и если не используете. В одной из первых удачных конфигураций, мы его использовали. Затем от этого отказались. Часть настроек –осталась. Таким образом в двух из девяти машин были неправильные настройки (на вычислительные узлы попал параметр не dvr, а dvr-snat). В конце концов я нашёл правильный параметр и поставил на место.



Без понимания того, как работает виртуальный роутер – где же он берёт настройки, пришлось настраивать и его. Он, по идее, должен быть с одним адресом и, соответственно, с одним мак-адресом. Логично? Мы так рассуждали и соответственно настраивали с коллегой.



В какой-то момент при расследовании проблем с DHCP (см. часть 2) я нашёл задваивающиеся мак-адреса. Не один, два, а гораздо больше. Вот это номер!



Было принято решение сменить параметры настройки base_mac и dvr_base_mac. Теперь в каждой вычислительной машине и в каждом контроллере эти параметры разные.



Мы с самого начала ещё не включили l2population – ну просто руки не доходили. А в новой ферме включили. И гляди, после всех таких изменений – заработало! Мало того – пинги перестали пропадать от слова «вообще»! Раньше нет-нет, да и пропадёт пакетик просто так – 0,1% и мы считали, что это вообще неплохо. Потому что гораздо хуже, когда пропадала четверть, а то и половина.



Настройки, которые сделали нам хорошо - neutron.conf для controller node
root@mama:~# cat /etc/neutron/neutron.conf |grep -v "^#.*"|strings

[DEFAULT]

bind_host = 192.168.1.4

auth_strategy = keystone

core_plugin = ml2

allow_overlapping_ips = True

service_plugins = router

base_mac = fa:17:a1:00:00:00

notify_nova_on_port_status_changes = true

notify_nova_on_port_data_changes = true

advertise_mtu = true

allow_automatic_dhcp_failover = true

dhcp_agents_per_network = 3

dvr_base_mac = fa:17:b1:00:00:00

router_distributed = true

allow_automatic_l3agent_failover = true

l3_ha = true

max_l3_agents_per_router = 3

rpc_backend = rabbit

[agent]

root_helper = sudo /usr/bin/neutron-rootwrap /etc/neutron/rootwrap.conf

[database]

connection = mysql+pymysql://neutron:ZPASSWORDZ@mama/neutron

[keystone_authtoken]

auth_uri = mama:5000

auth_url = mama:35357

memcached_servers = mama:11230

auth_plugin = password

project_domain_name = default

user_domain_name = default

project_name = service

username = neutron

password = ZPASSWORDZ

[nova]

auth_url = mama:35357

auth_plugin = password

project_domain_name = default

user_domain_name = default

region_name = RegionOne

project_name = service

username = nova

password = ZPASSWORDZ

[oslo_messaging_rabbit]

rabbit_userid = openstack

rabbit_password = ZPASSWORDZ

rabbit_durable_queues = true

rabbit_hosts = mama:5673

rabbit_retry_interval = 1

rabbit_retry_backoff = 2

rabbit_max_retries = 0

rabbit_ha_queues = false

[quotas]

quota_network = 100

quota_subnet = 200

quota_port = -1

quota_router = 100

quota_floatingip = -1

quota_security_group = -1

quota_security_group_rule = -1



Настройки, которые сделали нам хорошо - neutron.conf для compute node
root@baby:~# cat /etc/neutron/neutron.conf |grep -v "^#.*"|strings

[DEFAULT]

bind_host = 192.168.1.7

bind_port = 9696

auth_strategy = keystone

core_plugin = ml2

allow_overlapping_ips = True

service_plugins = router

base_mac = fa:17:c1:00:00:00

notify_nova_on_port_status_changes = true

notify_nova_on_port_data_changes = true

allow_automatic_dhcp_failover = true

dhcp_agents_per_network = 3

dvr_base_mac = fa:17:d1:00:00:00

router_distributed = true

allow_automatic_l3agent_failover = true

l3_ha = true

max_l3_agents_per_router = 3

rpc_backend = rabbit

[agent]

root_helper = sudo /usr/bin/neutron-rootwrap /etc/neutron/rootwrap.conf

[database]

connection = mysql+pymysql://neutron:ZPASSWORDZ@mama/neutron

[keystone_authtoken]

auth_uri = mama:5000

auth_url = mama:35357

memcached_servers = mama:11230

auth_plugin = password

project_domain_name = default

user_domain_name = default

project_name = service

username = neutron

password = ZPASSWORDZ

[nova]

auth_url = mama:35357

auth_plugin = password

project_domain_name = default

user_domain_name = default

region_name = RegionOne

project_name = service

username = nova

password = ZPASSWORDZ

[oslo_messaging_rabbit]

rabbit_hosts = mama:5673

rabbit_userid = openstack

rabbit_password = ZPASSWORDZ

rabbit_durable_queues = true

rabbit_retry_interval = 1

rabbit_retry_backoff = 2

rabbit_max_retries = 0

rabbit_ha_queues = true



Сутки терпеливо выждав (а ведь хотелось бегать, с криками «всё заработало!»), мы применили подобные изменения и в старой ферме. Вторая неделя – полёт нормальный.



Вывод



Вывод: конечно же, всего этого не случилось бы, если бы мы настраивали не вручную, а через автоматизированный инсталлятор. Однако полученный опыт бесценен.


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/333872/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Что такое DevOps: подход, который может изменить всё

Среда, 19 Июля 2017 г. 10:15 (ссылка)

Официальной датой рождения термина DevOps принято считать 2009 год, когда в Бельгии впервые прошла конференция “Devopsdays”. Год спустя желающих наберется уже на 4 подобных события. В 2017 году — 47 конференций по всему миру, в том числе в Москве. Так что такое DevOps?



DevOps это не профессия, а культура, философия, метод — набор практик, объединяющий вместе разработчиков программного обеспечения, тестировщиков и людей, отвечающих за его обслуживание. Отсюда название — акроним от “development” и “operations”. Основная цель — уменьшение разрыва между работой всех IT- подразделений компании, оптимизация ответственности за задачи «на стыке» разработки и эксплуатации, повышение производительности, снижение количества ошибок, и, как следствие, удовлетворение потребностей бизнеса и клиента.



Стандартный процесс делится на 5 этапов:

• анализ требований к проекту;

• проектирование;

• реализация;

• тестирование продукта;

• внедрение и поддержка.



При этом взаимодействие, как правило, осуществляется в лучшем случае между соседними. Таким образом, если после выпуска ПО в нём обнаруживаются ошибки, в первую очередь рассматриваются вопросы к железу и системным администраторам, потом к тестировщикам, и лишь потом дело доходит до разработчиков и планировщиков. Когда у вас один релиз в год — ничего страшного, но в современных компаниях производительность достигает десятков выпусков в день. Найти быстрое решение или хотя бы виновника в такой ситуации почти невозможно. Остается только два решения:

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



DevOps — современное решение данной проблемы. Он меняет указанный подход на циклический и, в тоже время, сквозной. В таком производственном процессе все этапы взаимосвязаны, требуют четкой организации и контроля. То есть разработчики, помимо основной деятельности, должны участвовать в деплое, системщики — в разработке, тестировщики — в настройке и т.д. Реализация методологии DevOps — задача сложная и кропотливая, реализуемая, как при помощи инструментов, так и специалистов. В этом, кстати, ее главное отличие от Agile, где достаточно лишь изменить образ мышления, организацию труда, не обязательно внедряя дополнительный персонал или программные системы.



До России практика внедрения DevOps начала доходить около 5 лет назад, поэтому потребность в DevOps — инженерах неуклонно растет, конкуренция пока еще низкая, а спрос на специалистов еще не сформировался и так же находится на стадии постоянного роста.



Ещё один плюс изучения DevOps — отсутствие фундаментальной подготовки кадров. Несмотря на привлекательность методологии, многие специалисты — бывшие разработчики, желающие расширить фронт работ. Но куда чаще в DevOps идут системщики, которым мало работы с кодом в shell и bash. В целом, для того, чтобы овладеть этой методологией, не надо иметь серьезного бэкграунда. Достаточно иметь опыт работы на одной из степеней жизни ПО и знать хотя бы в теории смежные дисциплины.



Практической стороне вопроса как раз и посвящен наш курс. Программа разбита на 5 логических уровней. На первом акцентируем внимание на базовых вещах DevOps — чаты, системы контроля версий и задач, визуализация рабочего процесса, облачные сервисы, безопасное удалённое подключение. В общем, всё то, без чего сложно представить современное коллективное программирование. Из продуктов познакомимся поближе с Google Cloud Platform, Packer, Slack, HipChat, Rocketchat и конечно же Git.



После того, как заложим основы разработки и администрирования, переходим на второй уровень, где обсудим настройки и конфигурирование инфраструктуры. На примере утилиты Terraform научимся создавать, изменять и присваивать версии компонентам нашей системы и поработаем с remote backends. Кроме того, на первых двух уровнях рассмотрим модель BSA (Base-Service-App): от базового уровня до применения конфигурацией при помощи Ansible.



На третьем уровне начнём работу с Docker — системой для автоматизации и развёртывания приложений, в частности с Dockerfile,

Hub, Compose. Здесь же рассмотрим понятия непрерывной интеграции и автоматизированного конвейера поставки, немного затронем тестирование контейнеров. Тем самым уже на этом этапе мы заложим правильную организацию выпуска ПО согласно методологии DevOps.



Уровень четвёртый посвящен такой важной процедуре в жизни каждого изделия, как мониторинг с последующим выявлением и записью ошибок. Для этого сначала определимся, что надо отслеживать, рассмотрим наиболее популярные системы мониторинга, алертинга и логирования. Разумеется, на практике узнаем, как их установить, настроить и поработаем с ними.



На последнем пятом уровне, дойдём до вершины DevOps-мастерства — оркестрированию и стратегии деплоя и масштабирования. Для этого нам потребуются Docker Swarm, Service Discovery, Kubernetes и Gitlab CI.



В нашем курсе мы постарались максимально цельно продемонстрировать именно практику организации производства ПО согласно DevOps, ведь именно здесь, возникает наибольшее количество вопросов. Поэтому если вы заинтересовались этой темой и хотите на практике познакомиться с “правильным” циклом разработки и деплоя ПО, самое время приобщиться к культуре DevOps — добро пожаловать на наш курс.



До старта курса осталось меньше месяца!

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/333684/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

С/С++ на Linux в Visual Studio Code для начинающих

Среда, 19 Июля 2017 г. 09:37 (ссылка)

Давайте начистоту, мало кто использует отладчик GDB на Linux в консольном варианте. Но что, если добавить в него красивый интерфейс? Под катом вы найдёте пошаговую инструкцию отладки кода С/С++ на Linux в Visual Studio Code.







Передаю слово автору.



Относительно недавно я переехал на Linux. Разрабатывать на Windows, конечно, удобнее и приятнее, но и здесь я нашел эффективный способ легко и быстро отлаживать код на С/С++, не прибегая к таким методам как «printf-стайл отладки» и так далее.



Итак приступим. Писать в sublime (или gedit/kate/emacs), а запускать в терминале — так себе решение, ошибку при работе с динамическим распределением памяти вряд ли найдёшь с первого раза. А если проект трудоёмкий? У меня есть более удобное решение. Да и ещё поддержка Git в редакторе, одни плюсы.



Сегодня мы поговорим про Visual Studio Code.



Установка



Ubuntu/Debian


  1. Качаем версию пакета VS Code с расширением .deb

  2. Переходим в папку, куда скачался пакет (cd ~/Загрузки или cd ~/Downloads)

  3. Пишем, где (имя пакета).deb — название файла, который вы только что скачали:

    sudo dpkg -i (имя пакета).deb
    sudo apt-get install -f



OpenSUSE/SLE Based distrs


  1. Установим репозиторий:

    sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc
    sudo sh -c 'echo -e "[code]\nname=Visual Studio Code\nbaseurl=https://packages.microsoft.com/yumrepos/VScode\nenabled=1\ntype=rpm-md\ngpgcheck=1\ngpgkey=https://packages.microsoft.com/keys/microsoft.asc" > /etc/zypp/repos.d/VScode.repo'

  2. Обновим пакеты и установим VS Code:

    sudo zypper refresh
    sudo zypper install code



Расширения для С/С++



Чтобы VS Code полностью сопровождал нас при работе с файлами С/С++, нужно установить расширение «cpptools». Также полезным будет поставить один из наборов сниппетов.







Настоятельно рекомендую включить автосохранение редактируемых файлов, это поможет нам в дальнейшем.







Идём дальше. Открываем любую папку (новую или нет, неважно).







У меня в этой папке уже есть пара файлов для работы с C/C++. Вы можете скопировать одну из своих наработок сюда или создать новый файл.







Осталось всего ничего. Настроить компиляцию в одну клавишу и научиться отлаживать без printf.



Шаг 1. Открываем файл .c/.cpp, который (обязательно) лежит в вашей папке.



Шаг 2. Нажимаем Ctrl+Shift+B. VS Code вам мягко намекнет, что он не знает как собирать ваш проект.





Шаг 3. Поэтому дальше настраиваем задачу сборки: выбираем «Настроить задачу сборки» -> «Others».



Шаг 4. Прописываем конфигурацию в соответствии с образцом. По сути мы пишем скрипт для консоли, так что всем кто имел дело с ней будет понятно дальнейшее. Прошу заметить, что для сборки исходников в системе должен стоять сам компилятор (gcc или другой, отличаться будет только значение поля command). Поэтому для компиляции .cpp, понадобится в поле command указать g++ или c++, а для .c gcc.



Шаг 5. В args прописываем аргументы, которые будут переданы на вход вашему компилятору. Напоминаю, что порядок должен быть примерно таким: -g, <имя файла>.



Внимание: Если в вашей программе используется несколько файлов с исходным кодом, то укажите их в разных аргументах через запятую. Также обязательным является ключ -g(а лучше даже -g3). Иначе вы не сможете отладить программу.



Если в проекте для сборки вы используете makefile, то в поле command введите make, а в качестве аргумента передайте директиву для сборки.





Шаг 6. Далее возвращаемся обратно к нашему исходнику. И нажимаем F5 и выбираем C++.







Шаг 7. Осталось только написать путь к файлу программы. По умолчанию это ${workspaceRoot}/a.out, но я в своем файле сборки указал флаг -o и переименовал файл скомпилированной программы, поэтому у меня путь до программы: ${workspaceRoot}/main.





Шаг 8. Всё, больше нам не нужно ничего для начала использования всех благ VS Code. Переходим к основному проекту.



Отладка



Для начала скомпилируем программу (нет, нет, убери терминал, теперь это делается по нажатию Ctrl+Shift+B).







Как вы видите в проводнике появился main, значит все в порядке и сборка прошла без ошибок. У меня не слишком большая программа, но выполняется она моментально. Одним словом, провал чистой воды, потому что отладка идет в отдельном терминале, который закрывается после того, как программа дошла в main() до "return 0;".





Пришло время для брейкпоинтов. Выберем строчку с "return 0;" и нажимаем F9.





Строчка, помеченная красной точкой слева — место, где остановится программа, при выполнении.



Далее нажимаем F5.







Как я и сказал, программа остановила выполнение. Обратите внимание на окно с локальными переменными.







Удобненько. Также при остановке можно наводить мышкой на переменные и структуры в коде и смотреть их значения.





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



Также есть случаи, когда считать выражение очень муторно вручную, но для отладки вам нужно знать, например, значение суммы трех элементов массива, или значение большого логического выражения. Для этого существуют контрольные значения. Все это и многое другое могут показать вам Контрольные значения (или «watch»).







Важно:


  1. Для каждой папки вам нужно отдельно настроить файлы сборки и путь к программе.

  2. VS Code не решит ваших проблем, но поможет быстрее с ними разобраться. Причем в разы.

  3. После каждого изменения программы, ее нужно компилировать заново, нажимая Ctrl+Shift+B.



Полезные шорткаты можно посмотреть здесь.



Об авторе





Максимилиан Спиридонов — разработчик C#, студент МАИ, Microsoft Student Partner. В профессиональную разработку на .NET пришёл ещё в школе. Около года работал с реальными проектами на WPF(MVVM)+C#, MySQL, более 4-х лет разрабатывал на C#. Основная сфера интересов сейчас — это мобильная разработка на Xamarin. Также, по воле случая в сфере интересов оказались С/С++ и Linux.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/333680/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<linux - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda