Весной этого года я узнал о возможности базы данных HP Vertica создавать запросы с матчингом паттернов событий. Так называемый Events Pattern Matching хорошо ложился под задачу анализировать поведение пользователей в продуктах ivi.ru. Мы решили попробовать разобраться с воронками оплаты, с поиском проблемных мест на устройствах, глубже погрузиться в анализ трафика. Нашей команде очень нравится, как реализована аналитика у Mixpanel и Localytics (она как раз основана на событиях и их свойствах), поэтому многие идеи были позаимствованы у них.

Дьявол кроется в деталях – я всегда вспоминаю об этом, когда разбираюсь с чем-то новым. Новый софт или новая железка могут быть какими угодно крутыми и технически, и экономически, но обязательно найдётся такая мелочь, которая вроде бы непринципиальна, но крови пьёт безумно много. Вот про несколько таких ненасытных мелочей в сетевом оборудовании Extreme Networks я и хочу рассказать под катом.

Добрый день, хабраюзер!

Есть у нас задача связывать различные сервисы и существующие системы в управляемые процессы. Скорость нужна не космическая (т.е. не по биржевым котировкам отклик создавать), но зато процессов много и компонент (систем) которые нужно использовать тоже порядочно вырисовывается. Не хочется делать p2p связывание. Хочется чего-то красивого и управляемого.

Просмотрев рынок, было принято решение сделать реплику по мотивам Amazon Simple Workflow, так как использовать его напрямую мы не можем. Свойства фреймворка которые нам подходят:

Многие из нас слышали о Hazelcast. Это удобный продукт, который реализует различные распределенные объекты. В частности: key-value хранилища, очереди, блокировки и т.д. К нему в целом применяются утверждения о распределенности, масштабируемости, отказоустойчивости и другие положительные свойства.

Так ли это применительно к его реализации очередей? Где границы их использования? Это мы и попытаемся выяснить.

На написание этой статьи меня побудило практически полное отсутствие how-to по настройке Астериска, с понятными новичку примерами. В сети можно найти кучу информации по настройке IVR, по настройке авторизации SIP-пользователей через LDAP, мануалов по созданию HA-кластеров с Астерисками внутри, etc., но нет ни одной статьи о том, как завести его с нуля, да и еще с примерами. Практически везде предлагается сразу же использовать все возможности, которые предлагает Астериск, а если убрать часть функционала, предлагаемого в мануале, то в большинстве случаев это приведет к получению неработоспособной конструкции. Эта статья — результат хождения по граблям… чтения мануалов. Если вы находитесь в такой же ситуации, что и я пару лет назад — добро пожаловать под кат.

Говорят, что автомобиль состоит из нескольких (десятков?) тысяч деталей. Задумывались ли вы, как именно происходит синхронизация цепочки поставок в автомобильной промышленности? Кому интересно узнать про разницу между Just-in-Time и Just-in-Sequence, кто и как заносил Toyota Lean Manufacturing Principles в Европу – прошу под кат.

Демон инициализации systemd де-факто уже стал стандартом в современных Linux-системах. На него перешли многие популярные дистрибутивы: Debian, RHEL/CentOS, Ubuntu (начиная с версии 15.04). В systemd используется принципиально иной (по сравнению с традиционным инструментом syslog) подход к логгированию.
В его основе лежит централизация: специализированный компонент journal cобирает все системные сообщения (сообщения ядра, различных служб и приложений). При этом специально настраивать отправку логов не нужно: приложения могут просто писать в stdout и stderr, a journal сохранит эти сообщения автоматически. Работа в таком режиме возможна и с Upstart, но он сохраняет все логи в отдельный файл, тогда как systemd сохраняет их в бинарной базе, что существенно упрощает  систематизацию и поиск.

Хранение логов в бинарных файлах также позволяет избежать сложностей с использованием парсеров для разных видов логов. При необходимости логи можно без проблем переконвертировать в другие форматы (более подробно об этом будет рассказано ниже).
Journal может работать как совместно с syslog, так и полностью заменить его.
Для просмотра логов используется утилита journalctl. Об особенностях и тонкостях работы с ней мы расскажем в этой статье.

Docker — технология, вокруг которой нынче огромное количество хайпа. «Shitstorm» — именно таким словом окрестил в твиттере докеровые войны один из моих немецких знакомых. Ну и конечно, вместе с «Microservices» и «Reactive», слово «Docker» прочно вошло в тройку ведущих айтишных баззвордов последних двух лет.

Неделю назад на московской встрече CodeFreeze Александр aatarasoff Тарасов из Альфа-Лаборатории (подразделение Альфа-банка) рассказал от том, как они внедряли у себя Docker, какой получили профит, какую боль и т.п. Интрига в том, что, с одной стороны, Альфа-банк — это банк, то есть, «кровавый энтерпрайз». С другой стороны… внедрили же.



Под катом — короткое описание того, о чем рассказал нам Александр и видеозапись его выступления.

До сих пор на хабре еще никто не упоминал о такой удобной подсистеме ядра linux, как inotify и использовании ее в автоматизации работы системного администратора. Хотелось бы восполнить этот пробел.

Что такое inotify

Inotify — это подсистема ядра Linux, которая позволяет получать уведомления об изменениях в файловой системе. Т.е. простыми словами — эта штука дает нам информацию о создании или изменении любого файла или директории в используемой файловой системе.
Inotify появилась в ядре аж в версии 2.6.13 и прошла проверку временем. Для ее использования написано несколько утилит, работу с одной из которых мы и рассмотрим.

Мы продолжаем нашу колонку по теме ASP.NET5 публикацией от Виктора Коцюбана ( Gbdrm) — Technical Leader из SoftServe. В этой статье Виктор поделится с вами подробностями нового встроенного функционала внедрений зависимостей в ASP.NET5. Предыдущие статьи из колонки всегда можно прочитать по ссылке #aspnetcolumn — Владимир Юнев

Внедрение зависимости – одна из самых популярных и используемых форм инверсии управления, важного принципа ООП, что позволяет уменьшить сцепление (coupling) – взаимозависимость, взаимосвязанность модулей.

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

В ASP.NET 5 встроена возможность внедрения зависимости. Что она позволяет и чем выделяется среди других таких подходов рассмотрим ниже. А также попробуем использовать ее на практике.

Привет,

я потихоньку сделал версию 2 своего «потустороннего» проекта — vPass. Если интересно, вот тут в комментах интересное обсуждение первой версии.



Вкратце, зачем это все?

• Для каждого сайта нужно придумывать свой уникальный пароль.
• Запомнить по-настоящему уникальные пароли невозможно.
• Проблему решают менеджеры паролей, но они, как правило, только под одну платформу.

vPass берет Ваш мастер-пароль (например, `my_password`) и, как правило, домен текушего сайта (например, `http://accounts.google.com` становится `google`) и создает набор из 12 букв, цифр и символов (например, `0EQu$MwEm?Qt`).

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

Данная статья посвящена новому Эмулятору UNL, с помощью которого вы можете создавать свои собственные виртуальные стенды для подготовки как к экзаменам CCNP/CCIE, так для решения своих инженерных задач.

Что такое UNetLab

UNenLab (Unified Networking Lab, UNL) – это мульти-вендорная и многопользовательская платформа для создания и моделирования самых различных лабораторий и дизайнов, которая позволяет смоделировать виртуальную сеть из маршрутизаторов, коммутаторов, устройств безопасности и др.

Это продолжение того же девелопера, который в своё время создал веб фронтенд для IOU. Теперь разработка iou-web завершена, разрабатывается только UNetLab и является незаменимым инструментом для подготовки к CCIE, сетевого инженеринга, в том числе и Troubleshooting. Это, по сути, убийца GNS, IOU и даже VIRL.

UnetLab – полностью бесплатен. Вы можете запускать столько экземпляров оборудования (роутеров, коммутаторов, устройств безопасности и т.д) сколько вы хотите и какого хотите. Например, в том же Cisco VIRL Personal Edition вы ограничены 15-ю узлами и набор устройств довольно скромный. Например полноценную ASA получить не представляется возможным, равно как и маршрутизатор с Serial-интерфейсом.

Поддержка оборудования в UNetLab очень широкая. Вы можете запускать Cisco IOL-образы, образы из VIRL (vIOS-L2 и vIOS-L3), образы ASA Firewall (как портируемые 8.4(2), 9.1(5), так и официальные ASAv), образ Cisco IPS, образы XRv и CSR1000v, образы dynamips из GNS, образы Cisco vWLC и vWSA, а также образы других вендоров, таких как Juniper, HP, Checkpoint и т.д.

Этом цикле статей «Идеальный www кластер», я хочу передать базовые основы построения высокодоступного и высокопроизводительного www решения для нагруженных web проектов для неподготовленного администратора.
Статья будет содержать пошаговую инструкцию и подойдет любому человеку кто освоил силу copy-paste
Ошибки найденые вами, помогут в работе и мне и тем кто будет читать эту статью позже! Так что любые улучшение и правки приветствуются!

Хочу отметить, что эта инструкция родилась в процессе миграции web-систем компании Acronis в высокодоступный кластер. Надеюсь мои заметки будут полезны и для Вас!.

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

На frontend мы будем использоваться связку из двух службы:

keepalived — реализации протокола VRRP (Virtual Router Redundancy Protocol) для Linux. Демон keepalived следит за работоспособностью машин и в случае обнаружения сбоя — исключает сбойный сервер из списка активных серверов, делегируя его адреса другому серверу.

Другими словами, у нас 2 сервера на которых прописано по одному публичному адресу. Если любой из этих серверов падает, то адрес упавшего подхватывается вторым.
Демоны keepalived общаются по протоколу VRRP, посылая друг другу сообщения на адрес 224.0.0.18.
Если сосед не прислал свое сообщение, то по истечению периода он считается умершим и оба адреса обслуживает оставшаяся нода. Как только упавший сервер начинает слать свои сообщения в сеть, все возвращается на свои места

nginx [engine x] — это HTTP-сервер и обратный прокси-сервер, а также почтовый прокси-сервер, написанный Игорем Сысоевым. Уже длительное время он обслуживает серверы многих высоконагруженных российских сайтов, таких как Яндекс, Mail.Ru, ВКонтакте и Рамблер. Согласно статистике Netcraft nginx обслуживал или проксировал 15.08% самых нагруженных сайтов в октябре 2013 года.

Основная функциональность HTTP-сервера

• Обслуживание статических запросов, индексных файлов, автоматическое создание списка файлов, кэш дескрипторов открытых файлов;
• Акселерированное обратное проксирование с кэшированием, простое распределение нагрузки и отказоустойчивость;
• Акселерированная поддержка FastCGI, uwsgi, SCGI и memcached серверов с кэшированием, простое распределение нагрузки и отказоустойчивость;
• Модульность, фильтры, в том числе сжатие (gzip), byte-ranges (докачка), chunked ответы, XSLT-фильтр, SSI-фильтр, преобразование изображений; несколько подзапросов на одной странице, обрабатываемые в SSI-фильтре через прокси или FastCGI, выполняются параллельно;
• Поддержка SSL и расширения TLS SNI.

Другие возможности HTTP-сервера

• Виртуальные серверы, определяемые по IP-адресу и имени;
• Поддержка keep-alive и pipelined соединений;
• Гибкость конфигурации;
• Изменение настроек и обновление исполняемого файла без перерыва в обслуживании клиентов;
• Настройка форматов логов, буферизованная запись в лог, быстрая ротация логов;
• Специальные страницы для ошибок 3xx-5xx;
• rewrite-модуль: изменение URI с помощью регулярных выражений;
• Выполнение разных функций в зависимости от адреса клиента;
• Ограничение доступа в зависимости от адреса клиента, по паролю (HTTP Basic аутентификация) и по результату подзапроса;
• Проверка HTTP referer;
• Методы PUT, DELETE, MKCOL, COPY и MOVE;
• FLV и MP4 стриминг;
• Ограничение скорости отдачи ответов;
• Ограничение числа одновременных соединений и запросов с одного адреса;
• Встроенный Perl.

• Почему в трейсроуте после узла X идут звездочки?
• Сервис не работает, а трейсроут обрывается на узле X — значит проблема в узле X?
• Почему одинаковые трейсроуты с Windows и Unix показывают разные результаты?
• Почему трейсроут показывает большие задержки на определенном узле?
• Почему трейсроут показывает «серые» адреса при трассировке через интернет?
• Почему маршрутизатор отвечает на трейсроут не тем адресом, каким я хочу?
• Почему трейсроут показывает какие-то «не такие» доменные имена?
• Почему вообще вывод трейсроута отличается от интуитивно ожидаемого чаще, чем хотелось бы?

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

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

Мы уже рассказывали на Хабре про облачную инфраструктуру Яндекса. Сегодня пришёл черёд от слов перейти к делу — мы хотим по шагам показать, как можно развернуть собственное облако на Elliptics и Cocaine.

Схема

Давайте рассмотрим установку небольшого облачка, в котором можно запустить тестовое приложение использующее flask.

Это облачко состоит из следующих элементов:

• cocaine-runtime, запускающий приложения в Docker;
• Docker-registry для хранения образов приложений;
• Elliptics в качестве распределенного хранилища приложений, а также конфигурации облака;
• агрегирующая нода cocaine-runtime — единая точка входа в облако для клиентского кокаинового кода;
• HTTP-frontend как альтернативный способ для доступа к приложениям.

По просьбам трудящихся, а так же учитывая, что есть статья по установке SVN (правда +Trac) под Linux, решил написать краткое описание установки и настройки SVN для Windows.
Ничего нового для людей, хорошо знающих и работающих с SVN, здесь не будет. Цель статьи — помочь некоторому проценту новичков, пребывающих на Хабре, таки осилить изучение этой системы контроля версий.

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

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

Второй заключается в использовании Zabbix агента, который мы будем запускать на наблюдаемой системе. Список наблюдаемых параметров включает в себя как и такие простые вещи, как загрузка процессора, использование памяти, так и более хитрые, такие как чтение текстовых лог-файлов с поддержкой ротации или отслеживание факта изменения любого файла. Можно даже в качестве параметра использовать вывод любой произвольной команды на системе. Возможности Zabbix агента растут от версии к версии.



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

Продолжая тему, описанную здесь habrahabr.ru/post/252973, опять пишу про увеличение дисков виртуальных машин.
Конфигурация следующая:
Гипервизор сервер Supermicro с KVM и libvirt на Ubuntu.
Гости — Ubuntu с LVM2.
Задача:
Увеличить размер системного дисков без выключения/перезагрузки гостевой ОС.

В комментариях к предыдущей статье habrahabr.ru/post/252973/#comment_8330673 farcaller написал:

Системный тоже можно на лету отресайзить. Для этого в libvirt есть команда:
virsh qemu-monitor-command resized-virtual-machine --hmp «block_resize $DRIVENAME $NEWSIZE»

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

На Хабре уже была публикация, посвященная нагрузочному тестированию АС, взаимодействующих по JMS при помощи JMeter. В ней описано применение JMeter как источника нагрузки, внешней системы, инициирующей бизнес-процесс в нашей (тестируемой) системе. Но что делать, если процесс инициируется внутри нашей системы, она отправляет запросы во внешнюю систему и ожидает ответа (то есть нам необходима заглушка внешней системы)?

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