История началась год назад, когда к нам пришёл наш друг, коллега и большой эксперт по энтерпрайз стораджам со словами: «Парни, у меня тут завалялась шикарная хранилка со всеми модными фичами. 90Tb». Особой необходимости мы в ней не видели, но, естественно, отказываться не стали. Настроили туда пару бекапов и на какое-то время благополучно забыли.

Периодически возникали задачи типа переброса больших файлов между хостами, сборка WAL для реплик Postgre и т. д. Постепенно мы начали перекладывать в этот холодильник всё разбросанное добро, так или иначе связанное с нашим проектом. Настроили ротейт, оповещения об успешных и не очень попытках выполнения бекапа. За год эта хранилка стала одним из важных элементов нашей инфраструктуры в группе эксплуатации.

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

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

Из множества вариантов наш взгляд особенно зацепил Глустер, Гластер. Всё равно, как называть. Лишь бы результат был. Поэтому мы начали над ним измываться.

Над большой тестовой инсталляцией, на которой крутился сторадж на базе ScaleIO от Dell EMC, мы издевались всяческим образом пару лет точно, а то и больше. Внесли огромное количество исправлений и допилили наконец-то продукт под нашу облачную инфраструктуру. Сторадж заполняет у нас крайне востребованную нишу между обычным медленным хранилищем на базе HDD и скоростным решением на all-flash массивах. Более того, в силу своей Software Defined специфики он позволяет собирать отказоустойчивые стораджи чуть ли не из палок с ветками. Только учтите, что совсем экономить на железе смысла нет, стоимость лицензии перевесит выгоды от экономии.

Короче говоря, сегодня я расскажу вам, как мы внедряли ScaleIO и ходили по граблям с закрытыми глазами. Про архитектурные особенности стораджа и его интеграцию в Облако. И, конечно, будет про нагрузочное тестирование. За подробностями — добро пожаловать под кат.

В QEMU есть несколько способов подключить блочное устройство для виртуальной машины. Изначально это было реализовано следующим способом:

 -hda /dev/sda1

Таким образом виртуальные диски подключались в давние дни виртуализации. Его можно использовать и сегодня, если мы просто хотим протестировать некоторые liveCD. К сожалению, он имеет свои недостатки

Кто-то скоро упадёт

Потому что СХД хранит святая святых — данные. Если данные стали недоступны, очень скоро запахнет жареным. Или если вдруг место закончилось — тоже неприятный сюрприз. Поэтому мониторинг должен быть обязательно, и он должен покрывать СХД.

Есть два основных подхода к мониторингу хранилок. Либо использовать универсальную систему мониторинга наподобие Nagios, Icinga, которая будет собирать инфу по протоколу SNMP, либо купить узкоспециализированный софт от производителей самих СХД. Само собой, второй вариант обеспечивает более глубокий анализ состояния железа, показывает специфические вещи наподобие состояния кэша, iops, hit rate, загрузку контроллеров и т. д. Именно такой вариант и выбирали чаще всего наши заказчики, у которых в строю стоят крупные и дорогостоящие массивы.

Но к слову сказать, не всё так гладко с коммерческим ПО для мониторинга. В подробностях я расскажу дальше. Это будет, так сказать, опыт из первых рук. В своё время я почти 2 года допиливал одну такую систему за много тысяч зелёных бумажек от именитого вендора. И расковырял её так, что даже поддержка вендора со мной стала советоваться. Но одни проблемы софта сменялись другими, равно как одни индусы из поддержки сменялись новыми индусами — и тогда-то мне и пришла мысль, а не поступить ли вообще радикально… В общем, с этого всё и началось.

Поднявшаяся в этом топике дискуссия о криптостойкости многократного применения хеша над паролем (проскальзывавшая, кстати, и в других форумах), подтолкнула меня к этому немного математическому топику. Суть проблемы возникает из идеи многократной (1.000 и более раз) обработки пароля перед хранением каким-либо криптостойким алгоритмом (чаще всего хеш-функцией) с целью получить медленный алгоритм проверки, тем самым эффективно противостоящий brute force-у в случае перехвата или кражи злоумышленником этого значения. Как совершенно верно отметили хабрапользователи Scratch (автор первой статьи), mrThe и IlyaPodkopaev, идея не нова и ею пользуются разработчики оборудования Cisco, архиватора RAR и многие другие. Но, поскольку хеширование – операция сжимающая множество значений, возникает вполне закономерный вопрос – а не навредим ли мы стойкости системы? Попытка дать ответ на этот вопрос –

Довольно часто разработчики ядер под Android устройства сталкиваются с тем, что собранное из исходников ядро просто напросто не работает. И при этом часто разработчик, собравший ядро, не имеет никаких специальных средств для отладки. В данной ситуации без kmsg логов довольно трудно что либо сделать. Конечно же в Linux ядре уже имеется несколько способов копирования содержимого kmsg буфера в специальную область памяти, но если вам интересно узнать ещё об одном способе, то прошу под кат.

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

Сегодня хочу поделиться с сообществом своим текущим опытом на реальном примере zabbix и его связке с block stat.

О радостях и трудностях первого знакомства с STM32 после AVR. Как я реализовывал простейшую задачу — передачу данных на ПК.

Третья часть (первая и вторая) про то как я делаю осциллограф из отладочной платы ценой менее $3. Демонстрационное видео работы:

А описание некоторых ключевых особенностей под катом.

Продолжение статьи. На этот раз попробуем подключить USB без падения частоты измерений и соберём одноканальную аналоговую часть.

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

С некоторых пор фирма Segger предлагает технологию Real Time Terminal (RTT) для своих JTAG адаптеров J-Link. Суть ее в том, что программа на микроконтроллере может выводить и принимать отладочную информацию из JTAG/SWJ-DP порта, как это обычно делается через UART. И тогда нам больше не нужен реальный отладочный UART. Далее чуть подробнее о возможностях этой технологии.

В конце декабря 2016 года мы опубликовали на Хабре материал по выступлению экспертов Positive Technologies на Chaos Communication Congress (33C3) в Гамбурге. Максим Горячий и Марк Ермолов рассказали о том, что современные процессоры Intel позволяют использовать отладочный интерфейс JTAG через доступный на многих платформах порт USB 3.0 для получения полного контроля над системой.

Начиная с процессоров семейства Skylake, запущенных в производство в 2015 году, компания Intel внедрила технологию Direct Connect Interface (DCI), которая предоставляет доступ к JTAG через популярный порт USB 3.0. При этом на целевом компьютере не требуется каких-либо программных или аппаратных агентов − необходимо лишь, чтобы интерфейс DCI был активирован. Таким образом возможность использовать возможности JTAG на оборудовании, доступном в широкой продаже, появилась у рядовых разработчиков

Продолжая тему практического применения микросхемы FTDI FT232H, затронутую мной в предыдущей статье, хотелось бы рассказать об использовании отладочной платы на ней в качестве дешевого и почти универсального JTAG-адаптера с интерфейсом USB и поддержкой множества микроконтроллеров различных архитектур и производителей. Я намеренно не называю этот адаптер «JTAG-отладчиком», т.к. далеко не все устройства с JTAG TAP поддерживают отладку, но обычными пользователями JTAG-адаптер используется в большинстве случаев именно для прошивки и отладки своего кода на МК. В этой статье я опишу только собственный опыт использования FT232H в качестве JTAG-адаптера, чтобы не давать ссылок на непроверенные решения, поэтому предлагаю читателям поделиться своими (или чужими) способами использования этой микросхемы в комментариях. Уверен, что способов этих найдется намного больше, чем здесь описано.
Заинтересовавшихся прошу под кат.

В этой статье мы поделимся практическим опытом в использовании периферийного (граничного) сканирования JTAG и расскажем про особенности и преимущества внедрения этой технологии на этапе тестирования опытных образцов. Особое внимание будет уделено типичным ошибкам, выявленным с помощью JTAG с использованием программного пакета Provision для тестирования различных узлов и микросхем платы.

Напомним, что периферийное сканирование (boundary scan) — это структурное тестирование печатной платы с установленными компонентами, которое основано на применении стандартов IEEE 1149.x. Результат сканирования — информация о наличии в электроцепях типичных неисправностей, возникающих в процессе производства печатных плат: коротких замыканий (bridges), непропаек (opens), западаний на 0 или 1 (stuck at 0, stuck at 1), обрывов дорожек.

Инструменты отладки нужны каждому разработчику. Однако, не существует универсальных решений, подходящих и тем, кто создаёт приложения пользовательского уровня, и тем, кто пишет низкоуровневые программы, вроде драйверов оборудования. Чем ближе к «железу» — тем больше хардкора в отладке и тестировании.

Из этого материала вы узнаете о том, как отлаживать код и анализировать исключения на уровне ядра Linux ОС Android в системах, основанных на архитектуре Intel. А именно, мы рассмотрим отладочный инструмент JTAG Debugger, который является частью пакета Intel System Studio Ultimate Edition. Мы расскажем о стандарте JTAG, о вышеупомянутом JTAG-отладчике Intel, об обработке исключений. В качестве примера мы будем использовать мини-компьютер MinnowBoard MAX с Intel Atom на борту.

Если ваша клавиатура размечена под латиницу или кириллицу, а вам приходится набирать тексты на другом языке, особенно, используя сложные, неалфавитные письменности, то данная заметка о системах ввода в Linux (упрощенно "клавиатурных раскладках") может вас заинтересовать.

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

«Закон масштабирования Деннарда и закон Мура мертвы, что теперь?» — пьеса в четырёх действиях от Дэвида Паттерсона

«Мы сжигаем мосты, по которым сюда мчимся, не имея других доказательств своего движения, кроме воспоминаний о запахе дыма и предположения, что он вызывал слёзы» — «Розенкранц и Гильденштерн мертвы», абсурдистская пьеса Тома Стоппарда

15 марта д-р Дэвид Паттерсон выступил перед аудиторией из примерно 200 наевшихся пиццы инженеров. Доктор вкратце изложил им полувековую историю конструирования компьютеров с трибуны в большом конференц-зале здания E в кампусе Texas Instruments в Санта-Кларе во время лекции IEEE под названием «50 лет компьютерной архитектуры: от центральных процессоров до DNN TPU и Open RISC-V». Это история случайных взлётов и падений, провалов и чёрных дыр, поглотивших целые архитектуры.

Паттерсон начал с 1960-х годов и новаторского проекта IBM System/360, основанного на ранних работах Мориса Уилкса по микропрограммированию 1951 года. По меркам IT это было давным-давно… Ближе к концу выступления Паттерсон показал потрясающую диаграмму. Она наглядно демонстрирует, как именно смерть закона масштабирования Деннарда, за которой следует смерть закона Мура, полностью изменили методы проектирования компьютерных систем. В конце он объяснил посмертные технологические последствия этих потрясений.

[Этот пост является переводом статьи от Сабины Хоссенфельдер]

«Краткая история времени» Стивена Хокинга была одна из первых научно-популярных книг, прочитанных мною, и я ее возненавидела. Возненавидела, потому что не понимала. Фрустрация от этой книги стала одной из основных причин, почему я стала физиком — ну, по крайней мере, я знаю, кого винить в этом.

Вместо вступления

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