Лучше день потерять, но потом за пять минут долететь (с)

Привет коллеги.
Хочу поделиться с вами соображениями о том, чем отличаются фреймворки Hive и Pig, входящие в экосистему Hadoop. По сути, это два очень похожих продукта, цель у которых одна — взять на себя всю техническую реализацию MapReduce, предоставив взамен возможность описывать процесс обработки данных на более абстрактном уровне. В этой статье мы увидим как выглядят выборки в этих двух системах, и попытаемся понять, в каких случаях надо использовать то или иное решение.

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


(часть фотографий, присланных в течение недели)

В данной статье я бы не хотел заострять внимание на принципе работы сборщика мусора — об этом прекрасно и наглядно описано здесь: habrahabr.ru/post/112676. Хочется больше перейти к практическим основам и количественным характеристикам по настройке Garbage Collection в JVM — и попытаться понять насколько это может быть эффективным.

Количественные характеристики оценки эффективности GC

Рассмотрим следующие показатели:

• Пропускная способность Мера, определяющая способность приложения работать в пиковой нагрузке не зависимо от пауз во время сборки и размера необходимой памяти
• Время отклика Мера GC, определяющая способность приложения справляться с числом остановок и флуктуаций работы GC
• Размер используемой памяти Размер памяти, который необходим для эффективной работы GC

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

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

Для обработки данных в Hadoop используется технология MapReduce.

Официальный учебный курс «Введение в Linux» от Linux Foundation, который ранее стоил 2400 долларов, будет доступен бесплатно на платформе онлайн-обучения EdX. Записаться на курс можно уже сейчас. Платформа массового онлайн-обучения EdX была создана Массачусетским технологическим институтом совместно с Гарвардским университетом. На ней представлены уже больше 30 университетов. Теперь и Linux Foundation станет официальным партнёром EdX. Курсу присвоен код LFS101x. Он рассчитан на 40 — 60 часов обучения. Занятия начнутся в 3-м квартале 2014 года.

Аннотация

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

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

Я очень надеюсь, что вы найдете для себя несколько полезных идей и все-таки научитесь на чужих ошибках. Помните: система стоит не столько, сколько вы заплатили за железо, а сколько вы вложите потом времени и сил в тестирование и эксплуатацию.
Если не хотите читать — посмотрите ссылки и выводы в конце; может, и передумаете.

DISCLAIMER

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

Благодарности

Респект Андрею Александровичу Бахметьеву, инженеру и изобретателю. Я горд, что Андрей Александрович преподавал для меня в институте! Желаю ему всяческих успехов в его проектах!

Задача

Итак, есть малый бизнес-стартап, генерирующий порядка 50Гб файлов в неделю, с необходимостью их архивного хранения в течение нескольких лет. Файлы крупные (порядка 10-20 Мб каждый), обычными алгоритмами не сжимаемые. Начальный объем данных порядка 2Тб. Совсем старые данные можно хранить в оффлайне, подключая по требованию.
Нужно уложиться в весьма скромный начальный бюджет решения 500 евро (в ценах лета 2013) и двухнедельный срок на сборку и тестирование.

За эти деньги нужно построить систему, которая позволит работать с файлами небольшой группе в одной локальной сети с разных платформ (Windows, Mac OS). Требуется длительная работа без сисадмина на площадке, защита от отказов и базовые функции управления правами доступа.

Традиционные пути

Безусловно, можно купить сетевое хранилище: их делают NetApp, QNAP, Synology и другие игроки, и притом делают неплохо даже для малого бизнеса. Но наши 500 евро – это только начало разговора для пустой коробки, без самих дисков. Если у вас есть 1000-2000 евро, лучше купите готовое изделие, а мы попробуем максимально заплатить знаниями и минимально — временем и деньгами.

UPD (спойлер ред. 2 от 2014-03-08):


А как же облачное хранение, спросите вы? На момент написания этой статьи популярные облачные хранилища для наших объемов выглядят дороже, чем хотелось бы. Например, стоимость хранения неограниченного объема данных 36 месяцев на известном сервисе Брось Бокс обойдется в пару тысяч долларов с лишним, хотя и выплачивать их можно постепенно. Конечно, есть сервисы вроде Amazon Glacier (благодарю А.М. за подсказку) или Ажурных Окон, но, во-первых, они тарифицируют не только хранение, но и обращение (как его априорно подсчитать?), а во-вторых не будем забывать, что бизнес сидит на Интернет-аплинке 10Мбит, и маневры терабайтами потребуют не только определенных усилий по управлению процессами, но и будут весьма утомительными для пользователей.

Обычно в таких случаях берут старый компьютер, докупают большие диски, ставят Linux (не обязательно, кто-то ухитряется и Windows 7), делают массив RAID5. Отлично. Всё работает хорошо примерно полгода-год, но одним солнечным утром сервер вдруг пропадает из сети без всякого предупреждения. Конечно, сисадмин уже давно работает в другой фирме (текучка кадров), резервной копии нет (объемы слишком велики), а новый сисадмин починить систему не может (при этом на чем свет стоит ругает старого сисадмина и диалект Linux YYY, ведь надо было использовать Linux ZZZ, тогда проблем бы точно не было). Все эти истории повторяются давно и одинаково, меняются только версии ОС и растут объемы данных.

Отраслевые мифы

Миф о RAID5

Самый распространенный миф, в который я и сам верил до недавнего времени – это то, что второго подряд отказа в массиве на практике не может быть по теории вероятности. А вот и может, да еще как! Смоделируем реальную ситуацию: сервер проработал пару лет, после чего в массиве отказывает диск. Пока ничего страшного, ставим новый диск, и что происходит? Ага, реконструкция массива, т.е. длительная максимальная нагрузка на уже порядком изношенные диски. В такой ситуации отказы очень даже возможны и происходят.
Но это не все. Есть еще заложенная производителем методическая вероятность ошибки чтения, которая при определенных обстоятельствах сейчас уже практически гарантирует, что RAID5 после отказа диска обратно не соберется.

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




Bid Data как понятие у всех на слуху уже не первый год. Но точное представление о том, что же представляет собой это понятие, есть далеко не у всех, особенно это касается людей за пределами IT-сферы. Проще всего несведущему человеку объяснить это на практическом примере.

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

Буквально вчера читал статью ValdikSS «Linux Botnet «BillGates»» и после прочтения захотелось рассказать, откуда он взялся.

Отступление

На днях начальница пригнала своего сынишку поучиться уму-разуму, а так как дарование впервые видит серверную ОС, то решение учить пацана выпало на старый ubunt-овский сервер с LAMP-ом на борту (Linux + Apache + MySQL + PHP). Благо на нем тестируют проекты перед показом в свет.

После вводных лекций и кучи выданной макулатуры на сервере был создан новый недо юзер, который благополучно был добавлен к зоопарку SSH, и присвоен стандартный пароль в виде «Thispasswordiscrypt». В процессе обучения недоюзеру надоело вводить длинный пароль и он без ведома сменил его на «fack_off». В то время мы проходили бэкапы БД и выборочно сервера, но по каким-то богу известным причинам под его учеткой не завелось восстановление БД. Не сильно парясь, я добавил ему повышенные привилегии. Теперь все ОК, начальница в ажуре. Так как мама рядом, и курить нельзя, то на перекур хожу только я, а он грызет гранит науки.

Написал мне вчера lfatal1ty, говорит, домашний роутер на x86 с CentOS как-то странно себя ведет, грузит канал под гигабит, и какой-то странный процесс «atddd» загружает процессор. Решил я залезть и посмотреть, что же там творится, и сразу понял, что кто-то пробрался на сервер и совершает с ним непотребства всякие. В процессах висели wget-ы на домен dgnfd564sdf.com и процессы atddd, cupsdd, cupsddh, ksapdd, kysapdd, skysapdd и xfsdxd, запущенные из /etc:

Начальный анализ

Сначала я полез смотреть, что же вообще происходит и насколько серьезно была скомпрометирована система. Первое, что мне пришло в голову проверить — /etc/rc.local. Там было следующее:

cd /etc;./ksapdd
cd /etc;./kysapdd
cd /etc;./atddd
cd /etc;./ksapdd
cd /etc;./skysapdd
cd /etc;./xfsdxd

«Хмм, ладно», подумал я. Полез в root'овский crontab

Всем привет!
Решил описать основные моменты настройки отказоустойчивого (HA) кластера БД PostgreSQL в IaaS среде от Amazon — AWS.

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

Введение

При достаточно большой и распределенной инфраструктуре, использующей DFS в качестве единой точки доступа к данным и DFSR для репликации данных между ЦОД и серверами филиалов, возникает вопрос мониторинга состояния этой репликации.
Так совпало, что почти сразу после начала использования DFSR, мы начали внедрение Zabbix с целью заменить существующий зоопарк различных инструментов и привести мониторинг инфраструктуры к более информативному, полному и логичному виду. Об использовании Zabbix для наблюдения за репликацией DFS и пойдет речь.

Первым делом, нам нужно определиться, какие данные о репликации DFS нужно получать для контроля за ее состоянием. Наиболее актуальный индикатор — backlog. В него попадают файлы, которые не были синхронизированы с другими членами группы репликации. Посмотреть его размер можно утилитой dfsrdiag, устанавливающейся вместе с ролью DFSR. В нормальном состоянии репликации, размер backlog должен стремиться к нулю. Соответственно, большие значения количества файлов в backlog свидетельствуют о проблемах с репликацией.

Теперь о практической стороне вопроса.

В использовании у меня получилось довольно много устройств — одних только ноутбуков три штуки, а еще комп на работе и смартфон. В какой-то момент я понял, что адресную книгу вот так в разброс хранить неудобно, и календарь тоже бы хотелось вести как-то единообразно. Синхронизировать такое количество устройств между собой как-то очень уж неудобно получается. Вот тут и пришло время придумать, как из этого всего выпутаться. Решил я посмотреть в сторону caldav и carddav серверов.
Требования для них у меня были максимально простые — учетки брать или из LDAP, или по IMAP и наличие веб-интерфейса для просмотра календаря и адресной книги.
Под рассмотрение попали три таких реализации:

Будучи высококвалифицированным исследователем, я потратил немало времени на продвижение науки вперёд. Но я родился на Юге и искренне убеждён, что прогресс — это выдумка, и что нужно готовиться к Судному дню, к жатве того, что мы посеяли и к появлению быстрых зомби, медленных зомби, и даже вежливых зомби, которые обращаются к вам «сэр» или «мадам», но в итоге пытаются съесть ваш мозг дабы заполучить ваши навыки. Когда нагрянет революция, нужно быть готовым; поэтому в моменты тишины и покоя, когда я не произвожу очередной прорыв в науке, я размышляю над тем, что же я буду делать, когда прогноз погоды изменится на «РЕКИ КРОВИ ЦЕЛЫЙ ДЕНЬ ДО СКОНЧАНИЯ ВРЕМЁН».

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

Но! Но… Самым важным членом моей банды будет системный программист, ибо в гоббсовском кошмаре невероятных масштабов умеющему отладить драйвер устройства или распредёленную систему человеку можно доверять; системный программист видел ужасы Вселенной и понимает безысходность бытия. Системный программист писал драйверы для устройств, прошивку которых создавал то ли пьяный ребёнок, то ли трезвый карась. Системный программист отлавливал проблему с сетью через восемь машин, три часовых пояса и с дружеским визитом в Омск, откуда ее перенаправили в левое переднее копыто той лошади, что избавила Трою от перенаселения.¹ Системный программист читал исходники ядра для лучшего понимания процессов мироздания и видел комментарий «И ЭТО РАБОТАЕТ ЛОЛ» в коде планировщика, и не смеялся он, но плакал; и отправил он патч ядра для восстановления баланса Силы и устранения инверсии приоритетов, что приводила к зависанию MySQL. Системный программист знает, что делать, когда общество падёт, потому что он уже живет в мире, где царит беззаконие.

О SELinux на Хабре уже писали, однако, не так много опубликовано подробных мануалов по данной системе. Сегодня мы публикуем именно такой, подробный мануал по SELinux, начиная от информации по системе, и заканчивая гибкой настройкой политик.
Для того, чтобы не превращать пост в «простыню», сложную для понимания, мы решили разделить мануал на две части. Первая будет рассказывать о самой системе, и некоторых ее особенностях. Вторая – о настройке политик. Сейчас публикуем первую часть, чуть позже будет опубликована и вторая часть.

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

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



Лекции читает Олег Викторович Сухорослов, старший научный сотрудник Центра грид-технологий и распределенных вычислений ИСА РАН. Доцент кафедры распределенных вычислений ФИВТ МФТИ. Кандидат технических наук.

В данной статье будет по шагам разобран процесс создания небольшого кластера Hadoop для опытов.

Несмотря на то, что в интернете на иностранных ресурсах есть полно материала про настройку/развертывание Hadoop, большинство из них либо описывают настройку ранних версий (0.X.X и 1.X.X), либо описывают только настройку в режиме single mode/pseudo distributed mode и лишь частично fully distributed mode. На русском языке материала практически нет вовсе.

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

Всем кому интересно, прошу пожаловать по кат.

История

Внедрение Linux в ПриватБанке началось в 2007 году. За это время был пройден большой путь и хотелось бы поделиться с сообществом своим опытом внедрения. На данный момент мы достигли следующих показателей: более 36500 рабочих мест с ОС Linux в 4000 отделений, расположенных в 5 странах.
В 2007 году за основу был взят ASPLinux 11.2. Со временем для альтернативы были выбраны другие дистрибутивы — Fedora, openSUSE, Ubuntu. Позже стала очевидной необходимость создания собственного дистрибутива и системы управления рабочими станциями. Разработка началась в январе 2012 года. Для основы был выбран Ubuntu 12.04 LTS с рабочим окружением Gnome Classic (no effect). Основные аргументы: Ubuntu — самый распространённый десктопный дистрибутив последних лет; обширное комьюнити, где проще найти решение возникающих проблем; именно его в качестве основы внедрения выбрал Google, много примеров внедрения в государственных и муниципальных учреждениях Германии, Франции. Выбор системы управления остановился на Puppet.
В июне 2012 года стартовал переход и к январю 2013 на корпоративную ОС были переведены уже около 95% ПК. Такая скорость перехода обусловлена тем, что сотрудники уже имели опыт работы в Linux.

Основные задачи, которые удалось решить благодаря текущему внедрению:

• cущественная экономия ресурсов при поддержке ОС на рабочих местах сотрудников;
• поддержание программного обеспечения в актуальном состоянии;
• возможность оперативного применения критических обновлений (до 1 часа на всех ПК);
• cбор и анализ статистической информации о парке ПК и периферии;
• создание системы проактивной реакции на сбои (Event Manager).

Дальше более детальное описание компонентов нашей реализации.

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

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

В работе мне помогает музыка, обычно это открытый таб с плейлистом Youtube. Так вот этот таб в просессе работы съедает до 500MB (!) и даже больше (Google Chrome).

Такое положение дел вынудило написать bash-скрипт, который на входе получает ID плейлиста, на выходе – mp3 файлы, которые можно слушать в любимом плеере, например, в MOC:

Всем привет! Надеюсь этот пост будет полезным для тех, кто хочет сдавать сертификацию по безопасности на основе IOS.
Так уже повелось, что для прежнего экзамена CCNA или как сейчас он называется CCNA Routing&Switching хватает софта из Cisco Networking Academy (Diccovery and Exploration) Cisco Packet Tracer, однако для отраслевых сертификаций он уже не подойдет. В этом случае, если, конечно, у Вас нет под рукой физического стенда, подойдет GNS3. Взглянем на темы экзамена CCNA Security. Понимаем что вопросами исключительно по IOS дело не обойдется: CCP, ASA, IPS. Что нужно? Правильно сконфигурированный стенд!
Итак, в одну корзинку кладем:

• PC host — CCP, ASDM, Kali — virual_box образы
• IOS Switch — в GNS не реализован, поэтому используем образ cisco 3745 с модулем NM-16ESW. В этом случае он будет функционировать как Switch L3 (Catalyst 3560)
• Router с функционалом Zone-based Firewall — образ IOS c3725-adventerprisek9-mz124-15.bin
• Cisco ASA — asa842 (kernel и initrd)
• Cisco IPS

Вот что-то такое должно быть…